Kubernetes

一、环境介绍k8s版本：v1.22.2dashboard版本：v2.5.1装置前留神k8s的版本与将要装置的dashbaord版本是否兼容，具体查看https://github.com/kubernetes... 二、dashbord装置下载官网yaml文件并且进行部署 root@master01:~/dashboard# wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.1/aio/deploy/recommended.yaml--2023-01-03 20:51:21-- https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.1/aio/deploy/recommended.yamlResolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.110.133, ...Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected.HTTP request sent, awaiting response... 200 OKLength: 7621 (7.4K) [text/plain]Saving to: ‘recommended.yaml’recommended.yaml 100%[=================================================================================================>] 7.44K --.-KB/s in 0.004s 2023-01-03 20:51:22 (1.95 MB/s) - ‘recommended.yaml’ saved [7621/7621]批改其网络为NodePort模式，不便宿主机进行拜访，留神其40行与44行地位内容的变更。 30 --- 31 32 kind: Service 33 apiVersion: v1 34 metadata: 35 labels: 36 k8s-app: kubernetes-dashboard 37 name: kubernetes-dashboard 38 namespace: kubernetes-dashboard 39 spec: 40 type: NodePort 41 ports: 42 - port: 443 43 targetPort: 8443 44 nodePort: 30001 45 selector: 46 k8s-app: kubernetes-dashboard 47 48 ---部署dashboardroot@master01:~/dashboard# kubectl apply -f recommended.yaml namespace/kubernetes-dashboard createdserviceaccount/kubernetes-dashboard createdservice/kubernetes-dashboard createdsecret/kubernetes-dashboard-certs createdsecret/kubernetes-dashboard-csrf createdsecret/kubernetes-dashboard-key-holder createdconfigmap/kubernetes-dashboard-settings createdrole.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrole.rbac.authorization.k8s.io/kubernetes-dashboard createdrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createdclusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard createddeployment.apps/kubernetes-dashboard createdservice/dashboard-metrics-scraper createddeployment.apps/dashboard-metrics-scraper created查看dashbaord相干pod状态 ...

问题形容：本环境k8s版本为：v1.22.2 在部署k8s集群的时候抉择装置了NodeLocal DNSCache服务以便减速各个节点POD的DNS解析速度，然而因为某些起因须要删除DNSCache服务，在应用部署NodeLocal DNSCache的yaml文件删除DnsCache相干的POD后再次新建的POD还是会或取到之前配置的NodeLocal DNSCache的地址。导致在删除NodeLocal DNSCache相干的POD后无奈失常解析域名。 问题景象：在删除NodeLocal DNSCache相干POD后依然获取的是169.254.20.10的地址，导致无奈失常解析集群内域名。 root@master01:~# kubectl run --iamge=busybox busybox -- tail -f /etc/hostsroot@master01:~# kubectl exec -it busybox -- /bin/sh/ # cat /etc/resolv.confnameserver 169.254.20.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5解决办法：通过查阅材料发现在集群中新建POD所获取的DNS地址是由各个node节点上的kubelet进行管制的，批改各个节点kubelet相干配置文件（如图为kubelet配置文件的地位） 确定coredns的service的地址为10.100.0.2. root@master01:~# kubectl get svc -ANAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdefault kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 5h38mkube-system kube-dns ClusterIP 10.100.0.2 <none> 53/UDP,53/TCP,9153/TCP 5h32mkube-system metrics-server ClusterIP 10.100.181.165 <none> 443/TCP 3h12m批改kubelet配置文件中的clusterDNS字段为coredns的service的地址。 root@node02:~# cat /var/lib/kubelet/config.yaml kind: KubeletConfigurationapiVersion: kubelet.config.k8s.io/v1beta1address: 192.168.10.102authentication: anonymous: enabled: false webhook: cacheTTL: 2m0s enabled: true x509: clientCAFile: /etc/kubernetes/ssl/ca.pemauthorization: mode: Webhook webhook: cacheAuthorizedTTL: 5m0s cacheUnauthorizedTTL: 30scgroupDriver: systemd cgroupsPerQOS: trueclusterDNS:- 10.100.0.2重启kubelet ...

一、环境介绍默认状况下，Harbor 不附带证书。能够在没有平安爱护的状况下部署 Harbor，以便您能够通过 HTTP 连贯到它。在生产环境中，举荐始终应用 HTTPS。要配置 HTTPS，必须创立 SSL 证书。能够应用由受信赖的第三方 CA 签名的证书，也能够应用自签名证书。本文以自签名证书为例。 应用到的各个软件版本 操作系统版本：ubuntu 20.04harbor版本：v2.5.3-797c3536docker版本：20.10.8kubernetets版本：1.22.2harbor地址：192.168.10.112 域名：harbor.snow.commaster01地址：192.168.10.100 二、仓库部署配置主机名与hosts文件 root@harbor:~# cat /etc/hosts127.0.0.1 localhost192.168.10.112 harbor.snow.com批改主机名root@barbor:~# hostnamectl set-hostname harborroot@harbor:~# bashroot@harbor:~# hostnameharbor下载harbor安装包 root@harbor:~#wget https://github.com/goharbor/harbor/releases/download/v2.5.3/harbor-offline-installer-v2.5.3.tgz解压harbor安装包root@harbor:~# tar xf harbor-offline-installer-v2.5.3.tgz -C /usr/local/src/装置docker-composeroot@harbor:~# curl -SL https://github.com/docker/compose/releases/download/v2.7.0/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose生成证书颁发机构证书及私钥 root@harbor:/usr/local/src/harbor/certs# openssl genrsa -out ca.key 4096Generating RSA private key, 4096 bit long modulus (2 primes)............................++++............................................++++e is 65537 (0x010001)root@harbor:/usr/local/src/harbor/certs# openssl req -x509 -new -nodes -sha512 -days 3650 \> -subj "/C=CN/ST=Shanghai/L=Shanghai/O=SmartX/OU=Lab/CN=harbor.snow.com" \> -key ca.key \> -out ca.crtroot@harbor:/usr/local/src/harbor/certs# lsca.crt ca.key生成服务器私钥及证书签名申请（CSR） ...

软件产品只有交付到用户手中才有价值，自己在面向政府等 ToG 场景的软件交付畛域具备数年的工作教训，深知其中痛点。明天借助这篇文章，分享这些痛点以及我的解决之道。 提出问题自己供职的公司，其次要客户群体是省内的政府部门，所开发的业务零碎是服务于政府内网之中的挪动APP。作为交付负责人，我始终苦恼于如何将一套基于 Spring Cloud 框架开发而来的服务端业务零碎交付给我的客户。实现软件系统的交付只是万里长征第一步，如何解决前期的运维工作也是必须面对的问题。政府场景的特殊性，为我的工作平添了许多不利因素，这些 ToG 场景交付的痛点，且听我娓娓道来。 离线环境交付 与公网环境隔离，与公司网络隔离，齐全的离线场景是政府交付工作中的标配特色，也是 ToG 交付最大的痛点。置信离线环境交付是所有的交付工程师都不想面对的场景，这意味着所有的交付物必须在当时筹备好，交付过程中一旦呈现任何脱漏和谬误，都意味着今天必须再来现场一次。 交付环境不对立 如果你从事过面向政府的交付工作，那多半会遭逢过交付环境不对立的状况。因为各级政府部门的 IT 建设脚步不一样，同样一套业务零碎，在交付到市级部门时，失去的硬件设施可能是一台物理服务器，而到了省级部门时，则可能失去了公有云提供的数台虚拟机。值得庆幸，物理机与虚拟机的差别并不大。然而近年来政府的 IT 建设始终在向国产自主可控的方向后退，当省级部门要求应用鲲鹏Arm架构CPU，亦或是应用国产麒麟操作系统进行交付时，和市级部门交付环境的差别就曾经十分大了。我甚至不得不将同一套业务零碎在两级部门的交付当作齐全不同的两个我的项目来看待。这体现出不同交付环境之间的差别，而当我转身看向公司开发环境时，开发环境与交付环境的差别，曾经开始让我听到本人头发落到高空的声音了。我很难确定当时筹备好的交付资源，在甲方环境部署时会否遭逢操作系统以及硬件设施差别所导致的依赖性抵触问题。这种问题在离线环境下又被放大，我甚至不具备连贯公网装置软件包来调试解决依赖性抵触问题的能力。 不足自动化运维能力 将软件交付到客户环境中，只是最高级的指标，在合同期内保护软件系统稳固运行是对交付品质更高层次的考验。按照集体教训，在一个软件交付我的项目中，交付部署的工作量，不迭前期运维工作量的一半。咱们是不心愿所有的软件问题都须要工程师亲自到达现场解决的，一来无奈保障 SLA 服务协定中的工夫承诺，其次也会消磨工程师的工作激情。在离线环境下如何构建起一套具备自动化运维能力的软件运行环境，变得尤为重要。依附自动化运维能力，让一些软件故障得以自愈，在肯定水平上升高了政府交付场景中的运维难度。但抉择任何一种技术实现自动化运维的指标都是须要付出代价的，这意味着我须要在软件系统交付之前，后行在交付环境中组装一套稳固牢靠的自动化运维平台。 适度依赖外围人员 在离线化的政府交付场景中，经常面临如下问题：一是交付环境难以对立时，其中非凡之处只被多数全程参加我的项目交付的工程师所理解，而理论教训通知咱们，这些非凡之处往往是一些异常情况的本源；二是离线的工作环境使得工程师通过查问材料来解决问题变成一种奢望，反向进步了对于工程师的教训和技能的技术要求，因而，“合格”的驻场运维工程师很难招到。以上问题造成了一些运维工作过分地依赖某些外围技术人员的场面，一旦外围技术人员到职或者调岗，对以后的业务连续性将会造成较大影响。所有的这些对人的依赖，都在某个靠谱的驻场工程师心愿另谋高就，向我提出辞职申请时痛击我的脑神经。 继续交付艰难 软件交付并非一次性工作。从项目管理的角度来说，用户很难在一开始就提出具体且可落实的需要，具体的我的项目范畴会随着我的项目的推动逐步确定，这是一个渐进明细的过程。而在软件产品交付的过程中，这种渐进明细体现在交付的产品会通过屡次迭代，每次降级后的产品，都间隔用户的最终需要更近一步。而这个继续交付的过程，在离线环境中，所遭逢的难处并不亚于首次交付，甚至会在某些须要回滚的场景中更加简单。在微服务时代，一套残缺的业务零碎往往蕴含了几十个独立的组件，组件数量也为继续交付增加了复杂性。 驻场开发难 驻场开发是一种在政府交付场景中常见的需要。规范的软件产品往往是不能间接满足甲方需要的，这就须要咱们的开发人员能够在甲方办公室间接定制开发指定的几个组件，并疾速更新到线上环境中去，供甲方验证。在理论场景中，少数微服务性能是固定的，只有一两个 jar 包须要频繁更替。 以往的经验我经验了公司软件产品交付的残缺改革流程。从最开始的 jar 包交付，继而引入容器化技术交付镜像，到起初采纳 Kubernetes 容器编排技术，咱们始终围绕着简单的离线环境进行软件产品的交付工作。每个阶段或多或少的解决了上述各种痛点，所付出的代价也不尽相同。最终咱们拥抱了云原生技术，将业务零碎整体作为新的对象实际了较为简单牢靠的离线环境交付，同时兼顾了以往各种痛点。 Jar 包交付得益于 Java 开发语言，咱们能够将代码打包成为仅依赖 JDK 运行环境的二进制交付产物——Jar 包。彼时咱们的软件产品还处于初级阶段，业务零碎由10个 Jar 包、Mysql数据库、Redis 缓存、前端Nginx组成。 一次交付工作中，首先要搭建起根底运行环境，实现 JDK 的装置。Mysql、Redis 等中间件依附很原始的 rpm 包进行装置，这个过程常常会遭逢包依赖抵触问题。最初将所有的 Jar 包运行起来，启动之前免不得进行一系列的人工配置工作。 这种交付形式比拟原始，咱们会写一些脚本来达成肯定水平上的自动化，然而这只在肯定水平上晋升部署效率，自动化运维能力根本为零。中间件的装置部署对操作系统的绑定水平很高，一旦服务器的操作系统和咱们事后理解的稍有偏差，都可能导致依赖抵触，导致装置失败。而配置过程对人工依赖过重，这在高可用部署的环境中体现的尤为突出，配置各种 IP 很容易出错。 做一个总结，这个阶段咱们实现了简略业务零碎的离线交付，然而没有解决其余任何一个 ToG 场景交付痛点。 引入容器化技术为了抹平交付环境不对立所带来的复杂度，咱们开始引入容器化技术，通过将所有组件容器化，咱们只须要确保客户的服务器可能运行 Docker 容器，就不须要再放心底层操作系统的问题了。官网提供动态编译版本的 docker 二进制文件，咱们再也不必和软件依赖打交道了。这个阶段，咱们的业务零碎也开始扩大，组件的数量上涨到了几十个，这导致咱们不得不同时引入 docker-compose 以及 docker-swarm 技术来解决单机或高可用场景下的组件编排问题。这些技术同时提供了较低水平的故障自愈能力，间隔真正的生产可用还有间隔。 ...

思考 Q1 k8s的默认调度器是在哪个环节过滤满足这个pod资源的节点的？如果问你是否理解k8s的调度原理，大家预计都会滔滔不绝说一通然而是否真正的理解其中的细节预计就不好说了上面是我浏览k8s调度器的源码剖析的全过程我的23个课程举荐k8s零根底入门运维课程k8s零根底入门运维课程，计算存储网络和常见的集群相干操作k8s纯源码解读教程(3个课程内容合成一个大课程)k8s底层原理和源码解说之精髓篇k8s底层原理和源码解说之进阶篇k8s纯源码解读课程，助力你变成k8s专家k8s运维进阶调优课程k8s运维巨匠课程k8s治理运维平台实战k8s治理运维平台实战前端vue后端golangk8s二次开发课程k8s二次开发之基于实在负载的调度器k8s-operator和crd实战开发 助你成为k8s专家cicd 课程tekton全流水线实战和pipeline运行原理源码解读prometheus全组件的教程01_prometheus零根底入门，grafana根底操作，支流exporter采集配置02_prometheus全组件配置应用、底层原理解析、高可用实战03_prometheus-thanos应用和源码解读04_kube-prometheus和prometheus-operator实战和原理介绍05_prometheus源码解说和二次开发06_prometheus监控k8s的实战配置和原理解说，写go我的项目裸露业务指标go语言课程golang根底课程golang实战课，一天编写一个工作执行零碎，客户端和服务端架构golang运维开发我的项目之k8s网络探测实战golang运维平台实战，服务树,日志监控，工作执行，分布式探测golang运维开发实战课程之k8s巡检平台直播答疑sre职业倒退布局k8s-prometheus课程答疑和运维开发职业倒退布局官网调度框架文档地址https://kubernetes.io/zh-cn/d...01 默认调度器何时 依据pod的容器 资源request量筛选节点默认调度器的源码地位 D:\go_path\src\github.com\kubernetes\kubernetes\pkg\scheduler\scheduler.go由调度 一个pod的办法入口 ,其中sched.Algorithm.Schedule代表算法调度func (sched *Scheduler) scheduleOne(ctx context.Context) { scheduleResult, err := sched.Algorithm.Schedule(schedulingCycleCtx, sched.Extenders, fwk, state, pod)}剖析 Schedule办法默认调度Schedule办法的源码地位 D:\go_path\src\github.com\kubernetes\kubernetes\pkg\scheduler\generic_scheduler.go从它的办法正文能够看到 // Schedule tries to schedule the given pod to one of the nodes in the node list.// If it succeeds, it will return the name of the node.// If it fails, it will return a FitError error with reasons.翻译过去就是Schedule办法 尝试从给出的节点列表中抉择一个调度这个pod如果胜利，会返回节点的名称如果失败，会返回谬误来剖析一下 这个办法的返回值这个ScheduleResult构造体他的字段定义的很清晰一看就晓得干啥的(result ScheduleResult, err error)type ScheduleResult struct { // Name of the scheduler suggest host SuggestedHost string 后果节点 // Number of nodes scheduler evaluated on one pod scheduled EvaluatedNodes int 参加计算的节点数 // Number of feasible nodes on one pod scheduled FeasibleNodes int 适合的节点数}再剖析一下这个办法的 参数(ctx context.Context, extenders []framework.Extender, fwk framework.Framework, state framework.CycleState, pod v1.Pod)ctx 上下文extenders 应该是扩大的调度插件？fwk为内置的调度框架对象state应该是 调度的后果缓存pod就是待调度的指标pod其中外围的内容就是 findNodesThatFitPod代码如 feasibleNodes, diagnosis, err := g.findNodesThatFitPod(ctx, extenders, fwk, state, pod)findNodesThatFitPod 就是执行filter插件列表中的插件step01 执行prefilter插件们 // Run "prefilter" plugins. s := fwk.RunPreFilterPlugins(ctx, state, pod) allNodes, err := g.nodeInfoSnapshot.NodeInfos().List() if err != nil { return nil, diagnosis, err }遍历执行的代码如下 ...

先看下 node 的 ip 地址 ╰─➤ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIMEminikube Ready control-plane,master 4d21h v1.23.9 192.168.49.2 <none> Ubuntu 20.04.5 LTS 5.15.0-56-generic docker://20.10.20然而间接登录 docker node 会失败！ ╰─➤ ssh docker@192.168.49.2 130 ↵The authenticity of host '192.168.49.2 (192.168.49.2)' can't be established.ED25519 key fingerprint is SHA256:ro33I63Xaq6BtyS/kfcVpinWBDH8Tx7kNm2NWSNnMoM.This key is not known by any other namesAre you sure you want to continue connecting (yes/no/[fingerprint])? yesWarning: Permanently added '192.168.49.2' (ED25519) to the list of known hosts.docker@192.168.49.2's password: Permission denied, please try again.docker@192.168.49.2's password: Permission denied, please try again.docker@192.168.49.2's password: docker@192.168.49.2: Permission denied (publickey,password).查了一下，能够不必账号密码，而是密钥对登录 ...

应用 kubespray 在 Vagrant + VirtualBox 的几个虚拟机上初始化一个 K8S 集群。 <!--more--> 装置 Vagrant宿主机是 Ubuntu 20.04，装置参考 Install Vagrant： wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpgecho "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.listsudo apt update && sudo apt install vagrant筹备 Vagrant Box一开始应用的是 自制 Centos7 Box初始化虚拟机筹备 kubespray初始化 K8S 集群文章阐明原文地址: 应用虚拟机初始化 K8S 集群，转载请表明起源。 本文由 Articli 工具主动公布。

Kubernetes （K8s）是古代云原生世界中的容器治理平台。它实现了灵便、可扩大地开发、部署和治理微服务。K8s 可能与各种云提供商、容器运行时接口、身份验证提供商和可扩大集成点一起工作。然而 K8s 的集成办法能够在任何基础设施上运行任何容器化应用程序，这使得围绕 K8s 和其上的应用程序堆栈创立整体安全性面临挑战。依据 Red Hat 的 2022 年 K8s 平安报告，在过来 12 个月的过程中，简直所有参加钻研的 K8s 用户都经验过至多一次安全事件。因而，能够说 K8s 环境在默认状况下并不平安，并且容易面临危险。  本文将探讨 10 大 K8s 平安危险，并就如何防止这些危险给出提醒。  1. K8s SecretSecret 是 K8s 的外围构建块之一，用于存储明码、证书或令牌等敏感数据，并在容器内应用它们。与 K8s Secret 相干的三个关键问题： Secrets 将敏感数据存储为 base-64 编码字符串，但默认状况下不加密。K8s 的确提供了存储资源的加密，但用户须要对其进行配置。此外，对于秘密的最大威逼是同一命名空间中的任何 pod，以及在 pod 内运行的任何应用程序都能够拜访和读取它们。基于角色的访问控制（RBAC）管制谁有权拜访 K8s 资源。用户须要正确配置 RBAC 规定，以便只有相干人员和应用程序能力拜访秘密。Secrets 和 ConfigMaps 是将数据传递给正在运行的容器的两种办法。如果有旧的和未应用的 Secrets 或 ConfigMap 资源，会造成凌乱并透露易受攻击的数据。例如，如果用户删除了后端应用程序部署但遗记删除蕴含的数据库明码的秘密，那么未来任何歹意 pod 都能够应用这些敏感数据。 2. 存在破绽的容器镜像K8s 是一个容器编排平台，在工作节点上散发和运行容器。然而它不会查看容器的内容是否存在安全漏洞或裸露。因而，须要在部署前对镜像进行扫描，以确保只有来自可信镜像仓库且没有重大破绽（如近程代码执行）的镜像才会在集群上运行。容器镜像扫描也应该集成到 CI/CD 零碎中，以实现自动化和更早地检测问题和缺点。  3. 运行时威逼K8s 工作负载（即容器）在工作节点上运行，容器在运行时由主机操作系统管制。如果存在宽松政策或存在破绽的容器镜像，可能会为整个集群关上后门。因而，须要操作系统级别的运行时爱护来增强运行时的安全性，而针对运行时威逼和破绽的最重要的爱护，在整个 K8s 中实现最小特权准则。  4. 集群谬误配置和默认配置K8s API 及其组件由一组简单的资源定义和配置选项组成。因而，K8s 为其大部分配置参数提供了默认值，并试图打消创立长 YAML 文件的累赘。然而，用户须要留神与集群和资源配置相干的三个关键问题： ...

在K8s中，Pod作为工作负载的运行载体，是最为外围的一个资源对象。Pod具备简单的生命周期，在其生命周期的每一个阶段，可能产生多种不同的异常情况。K8s作为一个简单零碎，异样诊断往往要求弱小的常识和教训储备。联合实战经验以及EDAS用户实在场景的演绎，咱们总结了K8s Pod的13种常见异样场景，给出各个场景的常见谬误状态，剖析其起因和排查思路。 本文篇幅超过7千字，通读全文大略须要20分钟。文章内容源自大量实在场景的积淀和剖析，倡议珍藏，以供查阅。Pod生命周期在整个生命周期中，Pod会呈现5种阶段（Phase）。 Pending：Pod被K8s创立进去后，起始于Pending阶段。在Pending阶段，Pod将通过调度，被调配至指标节点开始拉取镜像、加载依赖项、创立容器。Running：当Pod所有容器都已被创立，且至多一个容器曾经在运行中，Pod将进入Running阶段。Succeeded：当Pod中的所有容器都执行实现后终止，并且不会再重启，Pod将进入Succeeded阶段。Failed：若Pod中的所有容器都已终止，并且至多有一个容器是因为失败终止，也就是说容器以非0状态异样退出或被零碎终止，Pod将进入Failed阶段。Unkonwn：因为某些起因无奈获得 Pod 状态，这种状况Pod将被置为Unkonwn状态。一般来说，对于Job类型的负载，Pod在胜利执行完工作之后将会以Succeeded状态为终态。而对于Deployment等负载，个别冀望Pod可能继续提供服务，直到Pod因删除隐没，或者因异样退出/被零碎终止而进入Failed阶段。 Pod的5个阶段是 Pod 在其生命周期中所处地位的简略宏观概述，并不是对容器或 Pod 状态的综合汇总。Pod有一些细分状态（ PodConditions ），例如Ready/NotReady、Initialized、 PodScheduled/Unschedulable等。这些细分状态形容造成Pod所处阶段的具体成因是什么。比方，Pod 以后阶段是Pending，对应的细分状态是 Unschedulable，这就意味着Pod调度呈现了问题。 容器也有其生命周期状态（State）：Waiting、Running和 Terminated。并且也有其对应的状态起因（Reason），例如ContainerCreating、Error、OOMKilled、CrashLoopBackOff、Completed等。而对于产生过重启或终止的容器，上一个状态（LastState）字段不仅蕴含状态起因，还蕴含上一次退出的状态码（Exit Code）。例如容器上一次退出状态码是137，状态起因是OOMKilled，阐明容器是因为OOM被零碎强行终止。在异样诊断过程中，容器的退出状态是至关重要的信息。 除了必要的集群和利用监控，个别还须要通过kubectl命令收集异样状态信息。 // 获取Pod以后对象形容文件kubectl get pod <podName> -n <namespace> -o yaml // 获取Pod信息和事件（Events）kubectl describe pod <podName> -n <namespace>// 获取Pod容器日志kubectl logs <podName> <containerName> -n <namespace>// 在容器中执行命令kubectl exec <podName> -n <namespace> -c <containerName> -- <CMD> <ARGS>Pod异样场景Pod在其生命周期的许多工夫点可能产生不同的异样，依照Pod容器是否运行为标志点，咱们将异样场景大抵分为两类： 在Pod进行调度并创立容器过程中产生异样，此时Pod将卡在Pending阶段。Pod容器运行中产生异样，此时Pod依照具体场景处在不同阶段。下文将对这具体的13种场景进行形容和剖析。 调度失败常见谬误状态：UnschedulablePod被创立后进入调度阶段，K8s调度器根据Pod申明的资源申请量和调度规定，为Pod筛选一个适宜运行的节点。当集群节点均不满足Pod调度需要时，Pod将会处于Pending状态。造成调度失败的典型起因如下： 节点资源有余K8s将节点资源（CPU、内存、磁盘等）进行数值量化，定义出节点资源容量（Capacity）和节点资源可调配额（Allocatable）。资源容量是指 Kubelet 获取的计算节点以后的资源信息，而资源可调配额是Pod可用的资源。Pod容器有两种资源额度概念：申请值Request和限度值Limit，容器至多能获取申请值大小、至少能获取限度值的资源量。Pod 的资源申请量是Pod中所有容器的资源申请之和，Pod的资源限度量是Pod中所有容器的资源限度之和。K8s默认调度器依照较小的申请值作为调度根据，保障可调度节点的资源可调配额肯定不小于Pod资源申请值。当集群没有一个节点满足Pod的资源申请量，则Pod将卡在Pending状态。 Pod因为无奈满足资源需要而被Pending，可能是因为集群资源有余，须要进行扩容，也有可能是集群碎片导致。以一个典型场景为例，用户集群有10几个4c8g的节点，整个集群资源使用率在60%左右，每个节点都有碎片，但因为碎片太小导致扩不进去一个2c4g的Pod。一般来说，小节点集群会更容易产生资源碎片，而碎片资源无奈供Pod调度应用。如果想最大限度地缩小资源节约，应用更大的节点可能会带来更好的后果。 超过Namespace资源配额K8s用户能够通过资源配额（Resource Quota）对Namespace进行资源使用量限度，包含两个维度： 限定某个对象类型（如Pod）可创建对象的总数。限定某个对象类型可耗费的资源总数。如果在创立或更新Pod时申请的资源超过了资源配额，则Pod将调度失败。此时须要查看Namespace资源配额状态，做出适当调整。 不满足 NodeSelector节点选择器Pod通过NodeSelector节点选择器指定调度到带有特定Label的节点，若不存在满足 NodeSelector的可用节点，Pod将无奈被调度，须要对NodeSelector或节点Label进行正当调整。 不满足亲和性节点亲和性（Affinity）和反亲和性（Anti-Affinity）用于束缚Pod调度到哪些节点，而亲和性又细分为软亲和（Preferred）和硬亲和（Required）。对于软亲和规定，K8s调度器会尝试寻找满足对应规定的节点，如果找不到匹配的节点，调度器依然会调度该 Pod。而当硬亲和规定不被满足时，Pod将无奈被调度，须要查看Pod调度规定和指标节点状态，对调度规定或节点进行正当调整。 ...

问题提出流量有损是在利用公布时的常见问题，其景象通常会反馈到流量监控上，如下图所示，公布过程中服务RT忽然升高，造成局部业务响应变慢，给用户的最直观体验就是卡顿；或是申请的500谬误数突增，在用户侧可能感触到服务降级或服务不可用，从而影响用户体验。 因为利用发布会随同流量有损，所以咱们往往须要将公布打算移到业务低谷期，并严格限度利用公布的持续时间，尽管如此，还是不能完全避免公布带来的危险，有时甚至不得不抉择停机公布。EDAS作为一个通用利用管理系统，利用公布是其最根本的性能之一，而K8s 利用是EDAS中最广泛的利用的状态，下文将通过对EDAS客户实在场景的演绎，从K8s的流量门路动手，剖析有损公布产生的起因，并提供实用的解决方案。 流量路径分析K8s中，流量通常能够从以下几种门路进入到利用Pod中，每条门路天壤之别，流量损失的起因各不相同。咱们将分状况探索每种门路的路由机制，以及Pod变更对流量门路的影响。 LB Service流量 通过LoadBalancer类型Service拜访利用时，流量门路中外围组件是LoadBalancer和ipvs/iptables。LoadBalancer负责接管K8s集群内部流量并转发到Node节点上，ipvs/iptables负责将节点接管到的流量转发到Pod中。外围组件的动作由CCM（cloud-controller-manager）和kube-proxy驱动，别离负责更新LoadBalancer后端和ipvs/iptables规定。 在利用公布时，就绪的Pod会被增加到Endpoint后端，Terminating状态的Pod会从Endpoint中移除。kube-proxy组件会更新各节点的ipvs/iptables规定，CCM组件监听到了Endpoint的变更后会调用云厂商API更新负载均衡器后端，将Node IP和端口更新到后端列表中。流量进入后，会依据负载均衡器配置的监听后端列表转发到对应的节点，再由节点ipvs/iptables转发到理论Pod。 Service反对设置externalTrafficPolicy，依据该参数的不同，节点kube-proxy组件更新ipvs/iptables列表及CCM更新负载均衡器后端的行为会有所不同： Local模式：CCM 仅会将指标服务所在节点增加入负载平衡后端地址列表。流量达到该节点后仅会转发到本节点的Pod中。Cluster模式：CCM会将所有节点都增加到负载平衡后端地址列表。流量达到该节点后容许被转发到其余节点的Pod中。Nginx Ingress流量 通过Nginx Ingress提供的SLB拜访利用时，流量门路外围组件为Ingress Controller，它岂但作为代理服务器负责将流量转发到后端服务的Pod中，还负责依据Endpoint更新网关代理的路由规定。 在利用公布时，Ingress Controller会监听Endpoint的变动，并更新Ingress网关路由后端，流量进入后会依据流量特色转发到匹配规定上游，并依据上游后端列表抉择一个后端将申请转发过来。 默认状况下，Controller在监听到Service的Endpoint变更后，会调用Nginx中的动静配置后端接口，更新Nginx网关上游后端列表为服务Endpoint列表，即Pod的IP和端口列表。因而，流量进入Ingress Controller后会被间接转发到后端Pod IP和端口。 微服务流量 应用微服务形式拜访利用时，外围组件为注册核心。Provider启动后会将服务注册到注册核心，Consumer会订阅注册核心中服务的地址列表。 在利用公布时，Provider启动后会将Pod IP和端口注册到注册核心，下线的Pod会从注册核心移除。服务端列表的变更会被消费者订阅，并更新缓存的服务后端Pod IP和端口列表。流量进入后，消费者会依据服务地址列表由客户端负载平衡转发到对应的Provider Pod中。 起因剖析与通用解决方案利用公布过程其实是新Pod上线和旧Pod下线的过程，当流量路由规定的更新与利用Pod高低线配合呈现问题时，就会呈现流量损失。咱们能够将利用公布中造成的流量损失归类为上线有损和下线有损，总的来看，上线和下线有损的起因如下，后文将分状况做更深刻探讨： 上线有损：新Pod上线后过早被退出路由后端，流量被过早路由到了未筹备好的Pod。下线有损：旧Pod下线后路由规定没有及时将后端移除，流量仍路由到了进行中的Pod。上线有损剖析与对策K8s中Pod上线流程如下图所示： 如果在Pod上线时，不对Pod中服务进行可用性查看，这会使得Pod启动后过早被增加到Endpoint后端，后被其余网关控制器增加到网关路由规定中，那么流量被转发到该Pod后就会呈现连贯被回绝的谬误。因而，健康检查尤为重要，咱们须要确保Pod启动实现再让其摊派线上流量，防止流量损失。K8s为Pod提供了readinessProbe用于校验新Pod是否就绪，设置正当的就绪探针对利用理论的启动状态进行查看，进而可能管制其在Service后端Endpoint中上线的机会。 基于Endpoint流量场景对于基于Endpoint管制流量门路的场景，如LB Service流量和Nginx Ingress流量，配置适合的就绪探针查看就可能保障服务健康检查通过后，才将其增加到Endpoint后端摊派流量，以防止流量损失。例如，在Spring Boot 2.3.0以上版本中减少了健康检查接口/actuator/health/readiness和/actuator/health/liveness以反对配置利用部署在K8S环境下的就绪探针和存活探针配置： readinessProbe: ... httpGet: path: /actuator/health/readiness port: ${server.port}微服务流量场景对于微服务利用，服务的注册和发现由注册核心治理，而注册核心并没有如K8s就绪探针的查看机制。并且因为JAVA利用通常启动较慢，服务注册胜利后所需资源均依然可能在初始化中，比方数据库连接池、线程池、JIT编译等。如果此时有大量微服务申请涌入，那么很可能造成申请RT过高或超时等异样。 针对上述问题，Dubbo提供了提早注册、服务预热的解决方案，性能概述如下： 提早注册性能容许用户指定一段时长，程序在启动后，会先实现设定的期待，再将服务公布到注册核心，在期待期间，程序有机会实现初始化，防止了服务申请的涌入。服务预热性能容许用户设定预热时长，Provider在向注册中⼼注册服务时，将⾃身的预热时⻓、服务启动工夫通过元数据的模式注册到注册中⼼中，Consumer在注册中⼼订阅相干服务实例列表，依据实例的预热时长，联合Provider启动工夫计算调用权重，以管制刚启动实例调配更少的流量。通过小流量预热，可能让程序在较低负载的状况下实现类加载、JIT编译等操作，以反对预热完结后让新实例稳固均摊流量。咱们能够通过为程序减少如下配置来开启提早注册和服务预热性能： dubbo: provider: warmup: 120000 delay: 5000配置以上参数后，咱们通过为Provider利用扩容一个Pod，来查看新Pod启动过程中的QPS曲线以验证流量预热成果。QPS数据如下图所示： 依据Pod接管流量的QPS曲线能够看出，在Pod启动后没有间接均摊线上的流量，而是在设定的预热时长120秒内，每秒解决的流量呈线性增长趋势，并在120秒后趋于稳定，合乎流量预热的预期成果。 下线有损剖析与对策在K8s中，Pod下线流程如下图所示： 从图中咱们能够看到，Pod被删除后，状态被endpoint-controller和kubelet订阅，并别离执行移除Endpoint和删除Pod操作。而这两个组件的操作是同时进行的，并非咱们预期的按程序先移除Endpoint后再删除Pod，因而有可能会呈现在Pod曾经接管到了SIGTERM信号，但依然有流量进入的状况。 K8s在Pod下线流程中提供了preStop Hook机制，能够让kubelet在发现Pod状态为Terminating时，不立刻向容器发送SIGTERM信号，而容许其做一些进行前操作。对于上述问题的通用计划，能够在preStop中设置sleep一段时间，让SIGTERM提早一段时间再发送到利用中，能够防止在这段时间内流入的流量损失。此外，也能容许已被Pod接管的流量持续解决实现。 下面介绍了在变更时，因为Pod下线和Endpoint更新机会不合乎预期程序可能会导致的流量有损问题，在利用接入了多种类型网关后，流量门路的复杂度减少了，在其余路由环节也会呈现流量损失的可能。 LB Service流量场景在应用LoadBalancer类型Service拜访利用时，配置Local模式的externalTrafficPolicy能够防止流量被二次转发并且可能保留申请包源IP地址。 利用公布过程中，Pod下线并且曾经从节点的ipvs列表中删除，然而由CCM监听Endpoint变更并调用云厂商API更新负载均衡器后端的操作可能会存在提早。如果新Pod被调度到了其余的节点，且原节点不存在可用Pod时，若负载均衡器路由规定没有及时更新，那么负载均衡器依然会将流量转发到原节点上，而这条门路没有可用后端，导致流量有损。 此时，在Pod的preStop中配置sleep尽管可能让Pod在LoadBalancer后端更新前失常运行一段时间，但却无奈保障kube-proxy在CCM移除LoadBalancer后端前不删除节点中ipvs/iptables规定的。场景如上图所示，在Pod下线过程中，申请门路2曾经删除，而申请门路1还没有及时更新，即便sleep可能让Pod持续提供一段时间服务，但因为转发规定的不残缺，流量没有被转发到Pod就曾经被抛弃了。 解决方案： 设置externalTrafficPolicy为Cluster可能防止流量下线损失。因为Cluster模式下集群所有节点均被退出负载均衡器后端，且节点中ipvs保护了集群所有可用Pod列表，当本节点中不存在可用Pod时，能够二次转发到其余节点上的Pod中，然而会导致二次转发损耗，并且无奈保留源IP地址。设置Pod原地降级，通过为Node打特定标签的形式，设置新Pod依然被调度到本节点上。那么该流程无需调用云厂商API进行负载均衡器后端更新，流量进入后会转发到新Pod中。 Nginx Ingress流量场景对于Nginx Ingress，默认状况下流量是通过网关间接转发到后端PodIP而非Service的ClusterIP。在利用公布过程中，Pod下线，并由Ingress Controller监听Endpoint变更并更新到Nginx网关的操作存在提早，流量进入后依然可能被转发到已下线的Pod，此时就会呈现流量损失。 ...

前言云计算带来的劣势之一便是弹性能力，云原生场景下Kubernetes提供了程度弹性扩容能力（HPA），让利用能够随着实时指标进行扩/缩。然而HPA的理论工作状况可能和咱们直观料想的状况是不一样的，这外面存在一些认知误区。本文总结了一下 EDAS 用户在应用 HPA 时常遇到的三个认知误区，具体如下： 误区一：HPA存在扩容死区景象：当Request=Limit时，冀望利用率超过90%时，无奈失常扩容。 起因分析：HPA中存在容忍度（默认为10%），指标变动幅度小于容忍度时，HPA会疏忽本次扩/缩动作。若当冀望利用率为90%时，则理论利用率在81%-99%之间，都会被HPA疏忽。 避坑指南：当Request=Limit时，防止设置过高的冀望利用率，一来防止扩容死区；二来被动扩容有肯定的通畅工夫，留下更多的缓冲余量以应答突增流量。 误区二：误会利用率计算方法，HPA扩容与预期使用量不符景象：当Limit > Request时，配置50%的利用率，使用量未达到Limit的50%便扩容。 起因分析：HPA计算利用率是基于Request计算，当Limit > Request时，理论利用率是能够超过100%。 避坑指南：对于较为重要的利用，该当设置Request=Limit保障资源的独占。对于能够容忍资源共享的利用，对应的冀望利用率也不应设置的过高，在集群资源缓和时，超量应用资源的Pod很有可能会被杀死，从而造成服务中断。 误区三：弹性行为总是滞后的，扩缩行为与心理预期不符景象：指标突增时，HPA不会立即扩容，且扩容可能是分屡次进行，最终稳固时的实例数也与预期不同。 起因分析：HPA的设计架构决定了，HPA扩/缩容总是滞后的，且扩/缩容收到弹性行为（behavior）与容忍度独特作用。其中弹性行为限度了扩/缩容速率，不会一口气扩/缩到冀望实例数。而容忍度会疏忽指标的小幅度变动，从而导致在屡次扩容的场景下，最终计算的实例数可能与一开始计算出的实例数不同。 避坑指南：浏览下文理解一下HPA工作原理，配置正当的弹性行为（behavior）。 HPA工作机理在突破认知误区前，咱们有必要梳理一下HPA的工作机理 如图所示，HPA控制器执行弹性性能次要分为四个步骤：监听HPA资源，一旦生成HPA资源或者是更改HPA配置，HPA控制器能及时感知并调整。从Metrics API获取对应的指标数据，这里的Metrics Server又能够分为三类Kubernetes MetricServer：提供容器级别CPU/内存使用量Custom MetricServer：提供来自Kubernetes集群自定义资源的指标数据External MetricServer：提供来自Kubernetes集群外的指标数据每个指标项独自计算冀望实例数，最初取所有冀望实例数中的最大值，作为当前工作负载的冀望实例数调整对应的工作负载其中步骤2-4约每15秒执行一次，如需扭转工夫周期，能够调整KCM的配置参数--horizontal-pod-autoscaler-sync-period。 数据源 如上图所示，HPA目前提供了五种指标起源，以及三种指标服务（MetricsServer），简略介绍如下： Resource：提供Pod级别的CPU/内存使用量ContainerResource：提供容器级别的CPU/内存使用量Object：提供Kubernetes集群内任意资源的相干指标Pods：提供Kubernetes集群内pod相干的指标External：提供Kubernetes集群外的指标数据值得一提的是，在自建Kubernetes场景下，这三种MetricsServer都须要额定装置，它们均运行于KCM之外。下表列举了几种Kubernetes集群MetricsServer的部署状况。 指标计算方法HPA提供了三种期望值类型 总量（Value）均匀量（AverageValue）= 总量 / 以后实例数利用率（Utilization）= 均匀量 / Request值得一提的是，利用率是基于Request进行计算的，所以没有设置Request的场景下，HPA可能无奈失常工作。 下图介绍了五种指标起源反对的冀望类型，不难看出所有指标起源都反对均匀量。 对于单个指标的冀望实例数计算规定如下： 这外面引入了容忍度的概念，即认为在期望值左近小范畴的抖动是能够容忍疏忽的。这个参数的起源是因为指标值是一个始终在抖动变动的值，如果不疏忽渺小的变动，那么很有可能造成利用一直的扩容缩容，进而影响整个零碎的稳定性。 如下图所示，当指标值落入粉色区域内（容忍度范畴）时，冀望实例数等于以后实例数。粉色区域（容忍度范畴）的上上限别离是0.9倍期望值与1.1倍期望值。 对于配置了多条指标规定，最终冀望实例数计算规定如下： 用一句话简要概括计算方法：单个指标稳定小时忽略不计，多个指标之间取最大值，最终实例数会落在上限和下限之间。 扩缩行为在某些状况下，指标数据会有一个频繁且大幅度的抖动。如下图所示的一段CPU指标数据，存在一些指标抖动或间歇流量降落导致利用率降落，指标的变动范畴曾经超出了容忍度的范畴。此时，从利用稳定性角度来看，咱们不冀望利用缩容。为了解决这个问题，HPA引入了配置来管制扩缩容，即扩缩行为（behavior），它是在HPA（autoscaling/v2beta2）中引入，要求Kubernetes集群版本>=1.18。 HPA的弹性行分为扩容行为和缩容行为。行为具体由以下三局部组成： 稳固窗口：稳固窗口会参考过来一段时间计算出的冀望实例数，选取极值作为最终后果，从而保证系统在一段时间窗口内是稳固的。对于扩容取极小值，对于缩容取极大值。步长策略：限度一段时间内实例变动的范畴。由步长类型、步长值、工夫周期三个局部组成。值得一提的是工夫周期这个概念与上述的稳固窗口是两回事，此处的工夫周期定义了回溯多长历史工夫，计算实例数变动状况。抉择策略：用于选取多个步长策略计算后的后果，反对 取最大值、取最小值、敞开 这三种策略。 回顾与总结至此，咱们曾经大抵理解了HPA的工作机理。正当利用HPA能够无效晋升资源利用率，在这之中咱们总结了一些注意事项，熟记这些点能够在应用HPA时“无效避坑”。 HPA的设计架构导致了HPA只能被动响应指标进行弹性扩缩，这种模式下，弹性滞后是肯定存在的。目前阿里云容器服务推出了带预测能力的AHPA，能够无效缩小弹性通畅。HPA的利用率计算方法是基于Request，理论利用率/冀望利用率超过100%是失常的，配置较高的冀望利用率须要正当布局集群资源和扫视相应危险。HPA中的容忍度概念能缓解指标稳定带来的零碎震荡问题，但与此同时引入的扩容死区问题须要运维人员避开。HPA的设计架构容许扩大各种类型指标，须要开发/装置相应的MetricsServer，如EDAS则为用户提供了微服务RT和QPS指标。HPA中存在扩缩容行为，即便不配置相应参数也有默认行为，扩容行为的稳固窗口默认是0，如果利用常因噪声数据造成扩容，能够设置一个较短的扩容稳固窗口躲避尖利噪声。单个HPA反对配置多个指标进行弹性，切勿对单个利用配置多个HPA，会相互影响，导致利用震荡。云原生场景下弹性能力更为丰盛，可供弹性的指标也更具备业务定制能力。利用 PaaS 平台（如企业级分布式应用服务 EDAS）能联合云厂商在计算、存储、网络上的技术根底能力，能让应用云的老本更低。然而这里对于业务利用会提出一点点挑战（如：无状态/配置代码解耦等等）。从更广的侧面来看，这是云原生时代利用架构面临的挑战。不过利用越来越原生的话，云的技术红利也会离咱们越来越近。 原文链接 本文为阿里云原创内容，未经容许不得转载。

Rancher RFO GARFO 是 Rancher For openEuler 的缩写，旨在面向 openEuler 打造 Rancher 根底平台。其中最外围的工作是打造一款面向 openEuler 生态的 Kubernetes 发行版。它基于上游 RKE2 的技术栈，构建物采纳 openEuler base image，致力于满足国内更加重视的平安合规规范，对 openEuler LTS 版本领有优良的兼容性。 SUSE 在欧拉开源社区中成立了 RFO SIG，以社区合作形式运作产品迭代，并将 RFO 发行版的工作成绩进行开源（https://gitee.com/rfolabs/rfo）。 RFO 发行版的次要愿景如下： 残缺可溯源的工程化。确保外围组件的构建记录和端到端测试后果均可溯源。产品化开箱即用。确保 RFO 的装置部署能够疾速上手，并反对从 Rancher Prime 配置部署。充沛依靠 openEuler 生态。确保外围组件的构建应用 openEuler 生态体系，依靠 openEuler container image 进行最终打包。软件供应链平安与合规。确保外围组件的散发产物不可篡改，并致力于提供等保加固的 Kubernetes 集群环境。多样性算力反对。提供面向 AMD64 和 ARM64 以及 RISC-V 等多样性算力的 Kubernetes 基础设施。RFO SIG 于 2022 年 9 月初在欧拉开源社区成立，历经 3 个月的工程迭代，咱们正式推出 RFO 发行版的 GA 版本，欢送试用并在 Rancher 社区和欧拉开源社区进行反馈。目前有以下已测试的版本可供使用：v1.23.14+rfor1/v1.24.8+rfor1/v1.25.4+rfor1 ，后续咱们也会长期跟踪 Kubernetes 的上游版本演进。 ...

前言Traefik是一个古代的HTTP反向代理和负载均衡器，使部署微服务变得容易。 Traefik能够与现有的多种基础设施组件（Docker、Swarm模式、Kubernetes、Marathon、Consul、Etcd、Rancher、Amazon ECS...）集成，并主动和动静地配置本人。 系列文章: 《基于 Traefik 的激进 TLS 平安配置实际》明天咱们基于 Traefik on K8S 来具体阐明如何通过 BasicAuth MiddleWare 实现认证性能 应用 Basic Auth 的起因很简略, 比方咱们想要将一个无认证的页面放到公网, 然而出于平安思考又心愿只有账号密码的用户能力拜访. 比方: 放开 Prometheus UI/AlertManager UI 到公网就能够加上 Basic Auth. 创立 BasicAuth MiddleWare创立 yaml 文件: (如正文中所述, users base64 串能够间接通过 htpasswd 生成) # 申明 `users` 所在的secretapiVersion: traefik.containo.us/v1alpha1kind: Middlewaremetadata: name: basic-auth namespace: kube-systemspec: basicAuth: secret: authsecret---# Note: 在kubernetes的secret中，字符串（例如由htpasswd生成的）必须首先进行base64编码。# 要创立一个encoded 的 user:password 对，能够应用以下命令:# htpasswd -nb user password | openssl base64apiVersion: v1kind: Secretmetadata: name: authsecret namespace: kube-systemdata: users: |2 dGVzdDokYXByMSRINnVza2trVyRJZ1hMUDZld1RyU3VCa1RycUU4d2ovCnRlc3QyOiRhcHIxJGQ5 aHI5SEJCJDRIeHdnVWlyM0hQNEVzZ2dQL1FObzAK创立基于 BasicAuth MiddleWare 的 IngressRoute如下所示, 在 middlewares 中援用了 basic-auth: ...

1、portport是k8s集群外部(node节点)拜访service的端口，即通过clusterIP: port能够拜访到某个service。 2、nodePortnodePort是内部拜访k8s集群中service的端口，通过nodeIP: nodePort能够从内部(浏览器/其余集群)拜访到某个service。 3、targetPorttargetPort是pod的端口，从port和nodePort来的流量通过kube-proxy流入到后端pod的targetPort上，最初进入容器(一个pod中能够有多个容器)。 4、containerPortcontainerPort是pod外部容器的端口，targetPort映射到containerPort。 port、nodePort、targetPort是在service中配置。 containerPort是在pod中配置

作者：郝建伟 背景面对更多我的项目现场交付，偶而会遇到客户环境不具备公网条件，齐全内网部署，这就须要有一套欠缺且高效的离线部署计划。 系统资源编号主机名称IP资源类型CPU内存磁盘01k8s-master110.132.10.91CentOS-74c8g40g02k8s-master110.132.10.92CentOS-74c8g40g03k8s-master110.132.10.93CentOS-74c8g40g04k8s-worker110.132.10.94CentOS-78c16g200g05k8s-worker210.132.10.95CentOS-78c16g200g06k8s-worker310.132.10.96CentOS-78c16g200g07k8s-worker410.132.10.97CentOS-78c16g200g08k8s-worker510.132.10.98CentOS-78c16g200g09k8s-worker610.132.10.99CentOS-78c16g200g10k8s-harbor&deploy10.132.10.100CentOS-74c8g500g11k8s-nfs10.132.10.101CentOS-72c4g2000g12k8s-lb10.132.10.120lb内网2c4g40g参数配置注：在全副节点执行以下操作 零碎根底设置工作、日志及数据存储目录设定 $ mkdir -p /export/servers$ mkdir -p /export/logs$ mkdir -p /export/data$ mkdir -p /export/upload内核及网络参数优化 $ vim /etc/sysctl.conf# 设置以下内容fs.file-max = 1048576net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_fin_timeout = 5net.ipv4.neigh.default.gc_stale_time = 120net.ipv4.conf.default.rp_filter = 0net.ipv4.conf.all.rp_filter = 0net.ipv4.conf.all.arp_announce = 2net.ipv4.conf.lo.arp_announce = 2 vm.max_map_count = 262144# 及时失效sysctl -w vm.max_map_count=262144ulimit优化$ vim /etc/security/limits.conf # 设置以下内容* soft memlock unlimited* hard memlock unlimited* soft nproc 102400* hard nproc 102400* soft nofile 1048576* hard nofile 1048576根底环境筹备ansible装置1. 环境阐明名称阐明操作系统CentOS Linux release 7.8.2003ansible2.9.27节点deploy2. 部署阐明物联治理平台机器数量繁多，须要ansible进行批量操作机器，节省时间，须要从部署节点至其余节点root免密。 ...

请在文中支付你的充电券 2022年行将迎来倒计时，在这和煦的一年比特熊在【比特熊故事汇】【登程吧！比特熊】还有大大小小的社区活动中与开发者、技术爱好者还有比特熊的粉丝们密切互动、高兴交换，一起制作和实现了许多难忘霎时！ 在新的一年到来之前，比特熊再为大家补充一剂能量棒，【比特熊直播间】最新技术系列——【比特熊充电栈】。 【比特熊充电栈】Bits Learn【比特熊充电栈】是【比特熊直播间】以技术为导向的直播栏目。直播邀请微软外部工程师、微软 MVP 团队、微软技术合作伙伴一起剖析热门技术并提供“手把手”演示教学。 直播内容依照技术分类划分系列，为大家设计与产品和技术利用相干的本地化课程。【比特熊充电栈】仍然采取真直播的模式，输入内容是正在“热度中”的产品更新和技术亮点，细分课程针对不同学习需要的技术入门者和教训开发人。概念科普、零碎带练双输入，直播解说、实时发问高效获取。 【比特熊充电栈】首发系列——Kubernetes。本系列嘉宾“众星星散”，在接下来的四期课程中咱们邀请到了来自微软外部的工程师、微软 MVP 团队的沉闷成员以及英特尔的特地专家，多维度畅谈技术。 ✦ 12.20 基于微软 AKS 搭建集体 CloudIDE ✦ 12.27 Intel 在云原生里的技术倒退和瞻望 & Dapr 的前世今生 ✦ 12.29 深刻 Kubernetes 调度器 ✦ 1.5 Kubernetes 多集群治理概述 【比特熊充电栈】的每期课程都通过精心设计，只为给你播种满满的学习体验。快来获取你的“充电券”，退出咱们的直播！如果你有其它想理解的技术，欢送向比特熊投稿，让它成为下一个充电系列，还有可能失去比特熊送出的特地惊喜哦！ 【比特熊充电栈】12月20日起，开启你的技术充电之旅 扫描比特熊个熊微信二维码退出【比特熊粉丝后援会】与开发者一起嗨聊，期待成为你的好友~ 点我预约直播~

在系列上一篇文章 https://my.oschina.net/u/4724... 中，咱们介绍了如何应用 KCL 编写并治理 Kubernetes 配置并将配置下发到集群，这一篇咱们通过 KCL 与其余 Kubernetes 配置管理工具的对比方 Kustomize 进一步介绍 KCL 在 Kubernetes 配置管理场景中的用法。 简介KCL 是一个开源的基于束缚的记录及函数语言。KCL 通过成熟的编程语言技术和实际来改良对大量繁冗配置的编写，致力于构建围绕配置的更好的模块化、扩展性和稳定性，更简略的逻辑编写，以及更快的自动化集成和良好的生态延展性。 KCL 冀望在 Kubernetes YAML 资源管理层面解决如下问题： 用生产级高性能编程语言以编写代码的形式晋升配置的灵便度，比方条件语句、循环、函数、包治理等个性晋升配置重用的能力在代码层面晋升配置语义验证的能力，比方字段可选 / 必选、类型、范畴等配置查看能力提供配置分块编写、组合和形象的能力，比方构造定义、构造继承、束缚定义等能力本篇文章是 KCL 能够做什么系列文章第二篇，重点讲述 KCL 语言一些进阶用法以及与 Kustomize 工具的区别，后续会继续更新和分享 KCL 的一系列特点、应用场景和其余 Kubernetes 配置管理工具的异同，大家敬请期待！ KCL 和 Kustomize 的区别Kustomize 提供了一种无需模板和即可自定义 Kubernetes 资源根底配置和差异化配置的解决方案，通过文件级的 YAML 配置形式实现配置合并或笼罩。在 Kustomize 中用户须要更具体地理解将要产生更改的内容和地位，对于简单递归过深的根底 YAML 可能不太容易通过选择器来匹配 Kustomize 文件。 而在 KCL 中，用户能够间接把对应代码须要批改的配置书写在对应的中央，免去了浏览根底 YAML 的老本，同时可能通过代码的形式复用配置片段，防止 YAML 配置的大量复制粘贴，信息密度更高，更不容易出错。 上面以一个经典的 Kustomize 多环境配置管理例子具体阐明 Kustomize 和 KCL 在 Kubernetes 资源配置管理上的区别。 KustomizeKustomize 有 base 和 overlay 的概念，bases 和 overlays 个别是一个蕴含 kustomization.yaml 文件的目录，一个 base 能够被多个 overlay 应用 ...

Kubernetes 作为资源调度和利用编排的开源零碎，正在成为云计算和古代 IT 基础架构的通用平台。JuiceFS CSI Driver 实现了容器编排零碎的存储接口，使得用户能够在 Kubernetes 中以原生的形式应用 JuiceFS。 因为 Kubernetes 本身的复杂性，用户反馈在部署和应用 JuiceFS CSI Driver 时，会遇到不少疑难问题。本文将为大家介绍JuiceFS CSI Driver架构、常见问题排查思路。 1. JuiceFS CSI Driver 架构介绍组件JuiceFS CSI Driver 的架构如下图，共有两个组件： Controller Service：以 PV id 为名在 JuiceFS 文件系统中创立子目录。 Node Service：创立 Mount Pod（JuiceFS 客户端），并挂载利用 Pod。 CSI Node 的工作机制如下图，次要将 JuiceFS 客户端放在独自的 pod 中运行，这样做有如下好处： 多个 Pod 共用 PV 时，不会新建 Mount Pod，而是对已有的 Mount Pod 做援用计数，计数归零时删除 Mount Pod。CSI 驱动组件与客户端解耦，不便 CSI 驱动本身的降级。 创立 PV 和应用的流程动态创建 PV（不应用 StorageClass 的跳过此步骤）： ...

文｜王发康 （花名：毅松 ） 蚂蚁团体技术专家、MOSN 我的项目外围开发者 深耕于高性能网络服务器研发，目前专一于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相干畛域。 本文 5574 字 浏览 14 分钟 前言从单体到分布式，解决了日益增长的业务在单体架构下的零碎臃肿问题；从分布式到微服务，解决了服务化后的服务治理问题；从微服务到服务网格，解决了利用和基础设施耦合下的研发效力及稳定性问题。 从微服务架构的演进历史来看，任何架构都不是变化无穷，总是随着利用在不同阶段的痛点以及周边技术的倒退而继续演进，而服务网格 （ServiceMesh） 概念从提出到生产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声音 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文次要介绍蚂蚁在这方面的摸索和实际，最终如何帮业务降本增效，晋升平安保障水位。 一、 问题及挑战谈起 ServiceMesh，大家的脑海中应该会呈现出上面这幅图，即 ServiceMesh 的 Sidecar 状态，它十分好的解决了利用和基础设施耦合下的系列问题，为业务的提效及稳定性等方面然禹功不可没。 然而随着 ServiceMesh 的规模化增大，Sidecar 架构也随之裸露了一些劣势，譬如利用和 Sidecar 资源耦合导致互相抢占、生命周期绑定，导致利用扩缩容波及额定 Sidecar 容器的创立及销毁开销、Sidecar 数量随着利用 Pod 数等比减少，导致其资源无奈充沛复用等。 援用 redhat.com/architect/why-when-service-mesh 1.1 资源耦合Sidecar 状态尽管从代码维度是解耦了基础设施与利用的耦合，然而在资源方面目前依然是和利用 Pod 绑定在一起，这就导致其资源管理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源管理[2] 进行改善，解决了初期的资源分配及治理。但随着业务的倒退也裸露一些隐患，一方面 Sidecar 和利用互相抢占 CPU 可能导致引发时延毛刺问题，另一方面固定的 1/4 内存资源可能无奈满足机房规模增大引发的网络连接数收缩等系列问题。 1.2 生命周期绑定Sidecar 和利用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行治理的。这导致利用在扩缩容操作时会波及额定 Sidecar 容器的创立及销毁开销，而 Sidecar 中的过程是基础设施软件本不应该随着利用的销毁而销毁。 ...

作者：郝建伟 k3s 简介官网文档：k3s 什么是k3sk3s 是一个轻量级的 Kubernetes 发行版它针对边缘计算、物联网等场景进行了高度优化。k3s 有以下加强性能：打包为单个二进制文件。应用基于 sqlite3 的轻量级存储后端作为默认存储机制。同时反对应用 etcd3、MySQL 和 PostgreSQL 作为存储机制。封装在简略的启动程序中，通过该启动程序处理很多简单的 TLS 和选项。默认状况下是平安的，对轻量级环境有正当的默认值。增加了简略但功能强大的batteries-included性能，例如：本地存储提供程序，服务负载均衡器，Helm controller 和 Traefik Ingress controller。所有 Kubernetes control-plane 组件的操作都封装在单个二进制文件和过程中，使 k3s 具备自动化和治理包含证书散发在内的简单集群操作的能力。最大水平加重了内部依赖性，k3s 仅须要 kernel 和 cgroup 挂载。 k3s 软件包须要的依赖项包含： containerdFlannelCoreDNSCNI主机实用程序（iptables、socat 等）Ingress controller（Traefik）嵌入式服务负载均衡器（service load balancer）嵌入式网络策略控制器（network policy controller）为什么叫 k3s?k3s内存占用是k8s的一半kubernetes是一个10个字母的单词，简写为k8skubenetes的一半是5个字母，简写为k3s实用场景k3s 实用于以下场景： 边缘计算-Edge物联网-IoTCIDevelopmentARM嵌入 k8s因为运行 k3s 所需的资源绝对较少，所以 k3s 也实用于开发和测试场景。在这些场景中，如果开发或测试人员须要对某些性能进行验证，或对某些问题进行重现，那么应用 k3s 不仅可能缩短启动集群的工夫，还可能缩小集群须要耗费的资源。架构介绍k3s server 是运行k3s server命令的机器（裸机或虚拟机），而 k3s worker 节点是运行 k3s worker命令的机器单节点架构k3s 单节点集群的架构如下图所示，该集群有一个内嵌 SQLite 数据库的单节点 k3s server。在这种配置中，每个 worker 节点都注册到同一个 server 节点。k3s 用户能够通过调用 server 节点上的 k3s API 来操作 Kubernetes 资源。 ...

在开发之前，你须要在本地装置各种开发工具和服务，比方：Mysql、Redis、Nacos 等等，咱们都晓得在个人电脑上装置这些服务相当的繁琐，可能会遇到很多问题，环境问题、依赖问题等等。 在须要团队合作业务联调的时候，因为共事们的操作系统不对立，有 Mac、Win、Linux，可能还会遇到操作系统依赖、字符集等问题。 在上线之前，你在本地开发调试都齐全没问题，部署到服务器就不能用了。经典再现：我本地好好的，咋到你部署就不能用了。 应用 Rainbond 本地开发的益处部署不便 在对于新的我的项目或者新的团队时，都须要搭建新的开发环境，这个过程须要进行几个小时，而且还会遇到奇奇怪怪的问题。在团队合作时，来了新人后，同样还是须要破费几个小时去搭建环境。应用 Rainbond 将根底环境打好包，新我的项目、新人来了装置即用，让咱们尽量避免在搭建环境上浪费时间。 对立环境 对于中小企业来说，没有太多的老本反对搭建专用的开发环境。那么就应用 Rainbond 对立开发环境，不论是 Windows、Mac 都能够装置 Rainbond，同时如果测试、生产环境也应用 Rainbond，能够间接导出利用包在测试、生产环境运行。 在本地部署 Rainbond无论是 Windows、Mac 都能够很轻松疾速的部署 Rainbond，只须要你的环境有 Docker Desktop 即可。 Mac 反对在 Mac x86、M1 上部署curl -o install.sh https://get.rainbond.com && bash ./install.shWindows docker run --privileged -d -p 7070:7070 -p 80:80 -p 443:443 -p 6060:6060 -p 8443:8443 ^--name=rainbond-allinone --restart=on-failure ^-v rainbond-data:/app/data ^-v rainbond-opt:/opt/rainbond ^-e EIP=<你的IP地址> ^registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond:v5.10.0-dind-allinone资源占用在本地搭建这样一个云原生平台，最关怀的当然是资源占用。因为本地的配置通常都不是很高，我的配置是 M1Pro 16G，部署 Rainbond 后在 Docker Desktop 中查看资源占用状况如下图，整体占用不大，CPU占用 ≈ 10%、内存占用 1.1GB。 ...

一、Ubunt环境1. 测试环境机器布局角色主机名IP地址mastertest-b-k8s-master192.168.11.13nodetest-b-k8s-node01192.168.11.14nodetest-b-k8s-node02192.168.11.152. 软件环境版本软件版本OSUbuntu 20.04.5 focalDockerDocker version 20.10.21Kubernetesv1.25.43. 初始化配置（所有节点）批改阿里apt源 sudo vi /etc/apt/sources.listdeb https://mirrors.aliyun.com/ubuntu/ focal main restricted universe multiversedeb-src https://mirrors.aliyun.com/ubuntu/ focal main restricted universe multiversedeb https://mirrors.aliyun.com/ubuntu/ focal-security main restricted universe multiversedeb-src https://mirrors.aliyun.com/ubuntu/ focal-security main restricted universe multiversedeb https://mirrors.aliyun.com/ubuntu/ focal-updates main restricted universe multiversedeb-src https://mirrors.aliyun.com/ubuntu/ focal-updates main restricted universe multiverse# deb https://mirrors.aliyun.com/ubuntu/ focal-proposed main restricted universe multiverse# deb-src https://mirrors.aliyun.com/ubuntu/ focal-proposed main restricted universe multiversedeb https://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiversedeb-src https://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiversesudo apt-get update -y敞开防火墙 sudo ufw disable敞开selinux 略...我装置的ubuntu20默认没有selinux这货色，因而不波及敞开敞开swap sudo swapoff -a # 长期sudo sed -ri 's/.*swap.*/#&/' /etc/fstab # 永恒增加hosts sudo vi /etc/hosts192.168.11.13 test-b-k8s-master192.168.11.14 test-b-k8s-node01192.168.11.15 test-b-k8s-node02将桥接的IPv4流量传递到iptables的链 sudo vi /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1sudo sysctl --system工夫同步 sudo apt install ntpdatesudo ntpdate time.windows.com4. 装置Docker/cri-dockerd/kubeadm/kubelet/kubectl（所有节点）装置Docker-ce sudo apt-get -y install apt-transport-https ca-certificates software-properties-commonsudo curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -sudo add-apt-repository "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"sudo apt-get -y update && sudo apt-get -y install docker-ce# 配置镜像下载加速器sudo vi /etc/docker/daemon.json{  "registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"],  "exec-opts": ["native.cgroupdriver=systemd"]}sudo systemctl daemon-reload && sudo systemctl restart docker && sudo docker info装置cri-dockerd wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.6/cri-dockerd_0.2.6.3-0.ubuntu-focal_amd64.debsudo dpkg -i cri-dockerd_0.2.6.3-0.ubuntu-focal_amd64.deb# 指定依赖镜像地址sudo vi /usr/lib/systemd/system/cri-docker.serviceExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd:// --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:latestsudo systemctl daemon-reload && sudo systemctl enable cri-docker && sudo systemctl restart cri-docker装置kubeadm，kubelet和kubectl # 增加k8s的阿里云apt源sudo apt-get install -y apt-transport-https ca-certificatessudo vi /etc/apt/sources.list.d/kubernetes.listdeb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial mainsudo curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -# 开始装置sudo apt-get update -y && sudo apt-get install -y kubelet kubeadm kubectl && sudo systemctl enable kubelet.service5. 部署Kubernetes Master在192.168.11.13（Master）执行sudo kubeadm init \  --apiserver-advertise-address=192.168.11.13 \  --image-repository registry.aliyuncs.com/google_containers \  --kubernetes-version v1.25.4 \  --service-cidr=10.96.0.0/12 \  --pod-network-cidr=10.244.0.0/16 \  --cri-socket=unix:///var/run/cri-dockerd.sock \  --ignore-preflight-errors=all配置kubectl应用的连贯k8s认证文件 # 普通用户mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config# 管理员（可加到环境变量）export KUBECONFIG=/etc/kubernetes/admin.conf6. 退出节点在2台node节点上执行 sudo kubeadm join 192.168.11.13:6443 --token o37091.z858bts6jmth9irz \--discovery-token-ca-cert-hash sha256:628a5b50227c93e465adc1ca380cf335e8f639c15c8a92892f9d22b71ac6c2ac \--cri-socket=unix:///var/run/cri-dockerd.sock下面用到的token，默认token有效期为24小时，当过期之后，该token就不可用了。这时就须要从新创立token，能够间接应用命令快捷生成：sudo kubeadm token create --print-join-command退出后在master查看工作节点 tantianran@test-b-k8s-master:~$ kubectl get nodesNAME                STATUS     ROLES           AGE     VERSIONtest-b-k8s-master   NotReady   control-plane   7m57s   v1.25.4test-b-k8s-node01   NotReady   <none>          14s     v1.25.4test-b-k8s-node02   NotReady   <none>          8s      v1.25.4tantianran@test-b-k8s-master:~$ 目前工作节点的状态为NotReady，是因为还没有部署网络插件，等部署完就会处于Ready。7. 部署容器网络接口（CNI）CalicoCalico是一个纯三层的数据中心网络计划，是目前Kubernetes支流的网络计划。上面开始部署Calico，在master上进行部署操作。下载calico的YAML: wget https://docs.projectcalico.org/manifests/calico.yaml下载完后还须要批改外面定义Pod网络（CALICO_IPV4POOL_CIDR），与后面kubeadm init的 --pod-network-cidr指定的一样。calico.yaml中CALICO_IPV4POOL_CIDR默认的配置如下： # - name: CALICO_IPV4POOL_CIDR#   value: "192.168.0.0/16"勾销正文，并批改成与后面kubeadm init的 --pod-network-cidr（10.244.0.0/16）指定的一样。 - name: CALICO_IPV4POOL_CIDRvalue: "10.244.0.0/16"批改完后文件后，开始部署： # 部署calicokubectl apply -f calico.yaml接下来就是比拟漫长的期待，期待多久取决于你的网速，如果网络的好的话，就会更快一点，因为它还要拉镜像，而且是3台节点都要拉取相干镜像，上面能够在master上查看位于kube-system命名空间下的pod tantianran@test-b-k8s-master:~$ kubectl get pods -n kube-systemNAME                                        READY   STATUS     RESTARTS   AGEcalico-kube-controllers-798cc86c47-sg65n    0/1     Pending    0          111scalico-node-9d2gz                           0/1     Init:0/3   0          111scalico-node-csnwt                           0/1     Init:0/3   0          111scalico-node-g7rk2                           0/1     Init:0/3   0          111scoredns-c676cc86f-p2sgs                     0/1     Pending    0          19mcoredns-c676cc86f-pn5zk                     0/1     Pending    0          19metcd-test-b-k8s-master                      1/1     Running    0          19mkube-apiserver-test-b-k8s-master            1/1     Running    0          19mkube-controller-manager-test-b-k8s-master   1/1     Running    0          19mkube-proxy-6bdwl                            1/1     Running    0          12mkube-proxy-d8xgk                            1/1     Running    0          19mkube-proxy-lcw2n                            1/1     Running    0          11mkube-scheduler-test-b-k8s-master            1/1     Running    0          19mtantianran@test-b-k8s-master:~$ 等calico的全副pod状态都为Running的时候，就胜利了。到时候你再去查看node的状态，应该也会为Ready了。方才提到，在部署calico的过程中3台节点都须要拉取相干镜像，能够到其中1台Node上查看有没有镜像了： tantianran@test-b-k8s-node02:~$ sudo docker imagesREPOSITORY                                           TAG       IMAGE ID       CREATED       SIZEregistry.aliyuncs.com/google_containers/kube-proxy   v1.25.4   2c2bc1864279   2 weeks ago   61.7MBcalico/cni                                           v3.24.5   628dd7088041   2 weeks ago   198MBcalico/node                                          v3.24.5   54637cb36d4a   2 weeks ago   226MBregistry.aliyuncs.com/google_containers/pause        latest    350b164e7ae1   8 years ago   240kBtantianran@test-b-k8s-node02:~$ 通过一小段时间期待后，calico相干的pod曾经都为Running了 tantianran@test-b-k8s-master:~$ kubectl get pods -n kube-systemNAME                                        READY   STATUS    RESTARTS   AGEcalico-kube-controllers-798cc86c47-sg65n    1/1     Running   0          7m45scalico-node-9d2gz                           1/1     Running   0          7m45scalico-node-csnwt                           1/1     Running   0          7m45scalico-node-g7rk2                           1/1     Running   0          7m45scoredns-c676cc86f-p2sgs                     1/1     Running   0          25mcoredns-c676cc86f-pn5zk                     1/1     Running   0          25metcd-test-b-k8s-master                      1/1     Running   0          25mkube-apiserver-test-b-k8s-master            1/1     Running   0          25mkube-controller-manager-test-b-k8s-master   1/1     Running   0          25mkube-proxy-6bdwl                            1/1     Running   0          17mkube-proxy-d8xgk                            1/1     Running   0          25mkube-proxy-lcw2n                            1/1     Running   0          17mkube-scheduler-test-b-k8s-master            1/1     Running   0          25mtantianran@test-b-k8s-master:~$ 持续查看工作节点的状态，也是Ready状态了 tantianran@test-b-k8s-master:~$ kubectl get nodesNAME                STATUS   ROLES           AGE   VERSIONtest-b-k8s-master   Ready    control-plane   26m   v1.25.4test-b-k8s-node01   Ready    <none>          19m   v1.25.4test-b-k8s-node02   Ready    <none>          19m   v1.25.4tantianran@test-b-k8s-master:~$ 到此为止！CNI网络插件calico就曾经实现部署啦！ 8. 部署DashboardDashboard是官网提供的一个UI，可用于根本治理K8s资源，也是在master上进行部署操作。github我的项目地址：https://github.com/kubernetes...YAML下载地址： wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml默认Dashboard只能集群外部拜访，下载yaml文件后，批改Service为NodePort类型，裸露到内部： kind: ServiceapiVersion: v1metadata:  labels:    k8s-app: kubernetes-dashboard  name: kubernetes-dashboard  namespace: kubernetes-dashboardspec:  ports:    - port: 443      targetPort: 8443      nodePort: 30001 # 减少这个（等会咱们拜访UI的端口）  selector:    k8s-app: kubernetes-dashboard  type: NodePort # 减少这个（让每个节点都可拜访）开始部署 kubectl apply -f recommended.yaml这时候，也是须要期待到dashboard相干的pod为Running的状态，它也是要拉镜像，可查看命名空间kubernetes-dashboard下的pod： tantianran@test-b-k8s-master:~$ kubectl get pods -n kubernetes-dashboardNAME                                         READY   STATUS              RESTARTS   AGEdashboard-metrics-scraper-64bcc67c9c-nnzqv   0/1     ContainerCreating   0          17skubernetes-dashboard-5c8bd6b59-blpgm         0/1     ContainerCreating   0          17stantianran@test-b-k8s-master:~$ 期待后，再次查看，dashboard相干的pod曾经为Running的状态，阐明曾经部署好 tantianran@test-b-k8s-master:~$ kubectl get pods -n kubernetes-dashboardNAME                                         READY   STATUS    RESTARTS   AGEdashboard-metrics-scraper-64bcc67c9c-nnzqv   1/1     Running   0          2mkubernetes-dashboard-5c8bd6b59-blpgm         1/1     Running   0          2m接下来就能够拜访任意节点的30001端口拜访UI，记得是用https哦 https://192.168.11.13:30001/#...https://192.168.11.14:30001/#...https://192.168.11.15:30001/#...创立登录UI的token kubectl create serviceaccount dashboard-admin -n kubernetes-dashboardkubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-adminkubectl create token dashboard-admin -n kubernetes-dashboard将创立好的token复制进去即可实现登录 最初阐明一下，当前所有yaml文件都只在Master节点执行（部署操作），切记！二、CentOS7环境1. 测试环境机器布局角色主机名IP地址mastertest-a-k8s-master192.168.11.10nodetest-a-k8s-node01192.168.11.11nodetest-a-k8s-node02192.168.11.122. 软件环境版本软件版本OSCentOS Linux release 7.9.2009DockerDocker version 20.10.21Kubernetesv1.25.43. 操作系统初始化配置（所有节点）3.1 敞开防火墙 systemctl stop firewalldsystemctl disable firewalld3.2 敞开selinux sed -i 's/enforcing/disabled/' /etc/selinux/config  # 永恒setenforce 0  # 长期3.3 敞开swap swapoff -a  # 长期sed -ri 's/.*swap.*/#&/' /etc/fstab    # 永恒3.4 依据布局设置主机名 hostnamectl set-hostname <hostname>3.5 在master增加hosts cat >> /etc/hosts << EOF192.168.11.10 test-a-k8s-master192.168.11.11 test-a-k8s-node01192.168.11.12 test-a-k8s-node02EOF3.6 将桥接的IPv4流量传递到iptables的链 cat > /etc/sysctl.d/k8s.conf << EOFnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsysctl --system  # 失效3.7 工夫同步 ...

Q 2 | Schedule Pod on Master NodeTask weight：3 % 利用 image httpd:2.4.41-alpine在default Namespace 创立一个Pod。这个Pod 的名称应该是pod1，container 应该命名为 pod1-container。 这个Pod应该被部署在Master节点， 不要在Pod上减少label。 请简略形容一下为什么默认状况下为什么不能把Pod部署在master node， 而后把起因写到文件/opt/course/2/master_schedule_reason中。 解析： 通常来说 Master 节点默认是不能够部署 Pod 的。这个咱们能够通过以下命令来查看： 首先咱们来查看 Master 节点 taints 相干信息: $ kubectl get node # find master node$ kubectl describe node cluster1-master1 | grep Taint # get master node taints$ kubectl describe node cluster1-master1 | grep Labels -A 10 # get master node labels$ kubectl get node cluster1-master1 --show-labels # OR: get master node labels接下来咱们创立 Pod template: ...

练习筹备这是 Kubernetes CKA 认证的模拟考试，大家不要错过哦。 在模拟考试开始之前建议您先设置一下以下命令： $ alias k=kubectl$ export do="--dry-run=client -o yaml" # like short for dry output. use whatever you like设置代码补全kubectl 的 Bash 补全脚本能够用命令 kubectl completion bash 生成。在 Shell 中导入（Sourcing）补全脚本，将启用 kubectl 主动补全性能。 然而，补全脚本依赖于工具 bash-completion，所以要先装置它（能够用命令 type _init_completion 查看 bash-completion 是否已装置）。 装置 bash-completion很多包管理工具均反对 bash-completion（参见这里）。能够通过 apt-get install bash-completion 或 yum install bash-completion 等命令来装置它。 上述命令将创立文件 /usr/share/bash-completion/bash_completion，它是 bash-completion 的主脚本。根据包管理工具的理论状况，你须要在 ~/.bashrc 文件中手工导入此文件。 要查看后果，请从新加载你的 Shell，并运行命令 type _init_completion。如果命令执行胜利，则设置实现，否则将上面内容增加到文件 ~/.bashrc 中： source /usr/share/bash-completion/bash_completion从新加载 Shell，再输出命令 type _init_completion 来验证 bash-completion 的装置状态。 ...

AHPA介绍背景Kubernetes 中利用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。应用最多的是固定实例数，然而很多业务都存在波峰波谷，如果采纳固定实例数的形式会造成较大的资源节约。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，缩小资源节约。CronHPA 是用户设定定时规定，在固定工夫进行实例数伸缩。然而设定定时规定较为简单，如果定时距离设置较大就会造成资源节约。HPA 能够依据利用实时负载设置实例数量，当利用负载高时扩容，当利用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载曾经比拟高时才会触发扩容，但此时业务曾经处在高负载中因而业务局部流量呈现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，咱们提出了一种智能化弹性伸缩计划 AHPA，能够依据历史时序数据进行被动预测，提前扩容，防止弹性滞后。同时，会依据实时数据动静调整被动预测后果，兼容周期变动等场景。 图 1 各种弹性伸缩策略比照图AHPA 架构 图 2 AHPA 框架图AHPA 整体架构 如图 2 所示，分为数据采集、预测及弹性伸缩三大部分。 Data CollectionData Collection 模块负责从数据源收集数据并将数据转为对立的格局传入给 Prediction 模块。数据源反对如 Prometheus、Metrics Serve、Log Service 以及其余自定义的监控平台。 指标蕴含 CPU、Memory、GPU 等资源指标，也包含 QPS、RT 等业务指标，同时也反对其余用户自定义指标。Adapter 模块负责将从多个数据源收集的各类指标转为对立的格局输出给 Prediction 模块。 PredictionPrediction 模块负责依据输出指标预测所需的 Pod 数量。Preprocessing 负责数据预处理，如过滤非 Running 状态的 Pod 利用率、解决缺失数据等。实现预处理后将时序数据传递给 RobustScaler[1]算法模块。该模块将在第二局部具体介绍。 Revise 模块负责对 RobustScaler 模块给出的预测 Pod 数量进行修改。RobustScaler 分为 Proactive 和 Reactive 两种模式，用户也会为利用 Pod 数量设置上上限。为保障利用安稳运行，咱们采取尽快扩，迟缓缩的策略，因而 Revise 模块会取 Proactive、Reactive 及用户设置的上上限中最大值作为预测的 Pod 数量。 ...

在利用的公布过程中数据库的构造变更始终是最简单也是危险最大的环节，而 Bytebase 能够对这一过程进行全生命周期的治理。在 Rainbond 中装置 Bytebase，轻松治理部署在 Rainbond 上的所有数据库。 Bytebase 是什么？Bytebase 是一个开源的数据库 CI/CD 工具，补救了 GitLab 所不足的数据库变更治理能力。它为 DBA 和开发人员提供了一个基于 Web 的合作平台，以平安高效地治理数据库变更。 Rainbond 是什么？Rainbond 是一个云原生利用治理平台，应用简略，遵循 以利用为核心 的设计理念，对立封装容器、Kubernetes和底层基础设施相干技术，让使用者专一于业务自身, 防止在业务以外技术上破费大量学习和治理精力。 疾速部署 BytebaseBytebase 已公布到 Rainbond 开源利用商店，你能够在开源利用商店中搜寻 Bytebase 一键装置。 装置后，能够通过 Rainbond 默认提供的域名拜访 Bytebase。 Rainbond 应用 --external-url 提供 Bytebase 的内部拜访。如需自定义内部URL，能够到Bytebase组件 -> 环境配置，批改 EXTERNAL_URL 环境变量。 Bytebase 疾速体验反对支流开源数据库Bytebase 反对对接多种数据库，例如 Mysql、PostgreSQL、TiDB、Snowflake、ClickHouse等。 工单驱动的变更治理Bytebase 反对以工单的模式对变更申请进行治理，提供多环境流水公布、批量公布等能力应答简单的变更场景，同时实现了与代码仓库集成，容许通过提交 PR/MR 主动生成工单 SQL 主动审核Bytebase 反对数据变更的主动审核，目前已笼罩业界常见标准，同时能够将审核能力与代码仓库进行集成，在 PR/MR 中主动审核 SQL 脚本。 在线 SQL 编辑器Bytebase 反对在线的 SQL 编辑器，你能够查看数据、表构造，共享 SQL 脚本等等。 ...

在k8s装置CICD-devtron先前条件《kubernetes(k8s) 存储动静挂载》参考我之前的文档进行部署https://www.oiox.cn/index.php/archives/32/ 装置helm工具root@cby:~# curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3root@cby:~# chmod 700 get_helm.shroot@cby:~# ./get_helm.shDownloading https://get.helm.sh/helm-v3.10.2-linux-amd64.tar.gzVerifying checksum... Done.Preparing to install helm into /usr/local/binhelm installed into /usr/local/bin/helmroot@cby:~# 应用 helm 装置root@cby:~# helm repo add devtron https://helm.devtron.ai"devtron" has been added to your repositoriesroot@cby:~# root@cby:~# root@cby:~# root@cby:~# helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd --set installer.modules={cicd}NAME: devtronLAST DEPLOYED: Fri Nov 18 05:22:13 2022NAMESPACE: devtroncdSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:1. Run the following command to get the password for the default admin user: kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d2. Run the following command to get the dashboard URL for the service type: LoadBalancer kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'3. To track the progress of Devtron microservices installation, run the following command: kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'root@cby:~# 查看验证root@cby:~# kubectl get pod -n devtroncdNAME READY STATUS RESTARTS AGEapp-sync-cronjob-27815700-lz565 0/1 Completed 0 2d5happ-sync-cronjob-27817140-6wsj6 0/1 Completed 0 29happ-sync-cronjob-27818580-kzjdb 0/1 Completed 0 5h33margo-rollouts-68dc6f5b75-949x9 1/1 Running 2 (152m ago) 4d10hargocd-application-controller-0 1/1 Running 2 (152m ago) 4d9hargocd-dex-server-54c8d7cbdf-nfjj2 1/1 Running 2 (153m ago) 4d10hargocd-redis-7967b6b9f7-6c69j 1/1 Running 2 (152m ago) 4d9hargocd-repo-server-6f9d65d87f-9p9p8 1/1 Running 2 (152m ago) 4d9hargocd-server-7cf98cdffb-4qxgm 1/1 Running 2 (152m ago) 4d9hclair-8cd58cdd9-nhglm 1/1 Running 46 (152m ago) 4d9hdashboard-777c9bb5f9-zz4b5 1/1 Running 2 (152m ago) 4d10hdevtron-d74cf8958-2x7sb 1/1 Running 4 (151m ago) 4d8hdevtron-grafana-6657cbc8f9-9j7fp 2/2 Running 2 (153m ago) 4d8hdevtron-grafana-test 0/1 Completed 6 4d8hdevtron-housekeeping-qp59k 0/1 Completed 0 4d10hdevtron-nats-0 3/3 Running 6 (152m ago) 4d10hdevtron-nats-test-request-reply 0/1 Completed 0 4d10hgit-sensor-0 1/1 Running 6 (152m ago) 4d10hgrafana-org-job-jgzjp 0/1 Completed 0 4d8himage-scanner-8679b48b66-t7bd2 1/1 Running 8 (151m ago) 4d9hinception-846694f944-5hjtq 1/1 Running 2 (152m ago) 4d10hkubelink-67985f58d5-xmds2 1/1 Running 2 (152m ago) 4d10hkubewatch-655f8669dd-xrx5q 1/1 Running 8 (152m ago) 4d10hlens-6c86975478-vwpq2 1/1 Running 9 (151m ago) 4d10hnotifier-5b4b48b677-dkcls 1/1 Running 1 (152m ago) 4d8hpostgresql-migrate-casbin-2lz42 0/1 Completed 0 4d10hpostgresql-migrate-casbin-bnzdb-954p6 0/1 Completed 0 4d8hpostgresql-migrate-devtron-t2w25 0/1 Completed 0 4d10hpostgresql-migrate-devtron-vlym3-jnvmf 0/1 Completed 0 4d8hpostgresql-migrate-gitsensor-sxpcr 0/1 Completed 0 4d10hpostgresql-migrate-lens-tmvt5 0/1 Completed 0 4d10hpostgresql-postgresql-0 2/2 Running 4 (152m ago) 4d10hroot@cby:~# root@cby:~# kubectl get svc -n devtroncdNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEargo-rollouts-metrics ClusterIP 10.98.113.34 <none> 8090/TCP 4d10hargocd-application-controller ClusterIP 10.107.155.128 <none> 8082/TCP 4d9hargocd-dex-server ClusterIP 10.97.14.200 <none> 5556/TCP,5557/TCP,5558/TCP 4d10hargocd-redis ClusterIP 10.102.166.243 <none> 6379/TCP 4d9hargocd-repo-server ClusterIP 10.111.245.9 <none> 8081/TCP 4d9hargocd-server ClusterIP 10.106.6.25 <none> 80/TCP,443/TCP 4d9hclair ClusterIP 10.109.97.107 <none> 6060/TCP,6061/TCP 4d9hdashboard-service ClusterIP 10.110.239.18 <none> 80/TCP 4d10hdevtron-grafana ClusterIP 10.111.200.165 <none> 80/TCP 4d8hdevtron-nats ClusterIP None <none> 4222/TCP,6222/TCP,8222/TCP,7777/TCP,7422/TCP,7522/TCP 4d10hdevtron-service LoadBalancer 10.100.28.2 <pending> 80:32489/TCP 4d10hgit-sensor-service ClusterIP 10.99.53.176 <none> 80/TCP 4d10himage-scanner-service ClusterIP 10.103.97.46 <none> 80/TCP 4d9hkubelink-service ClusterIP 10.97.172.63 <none> 50051/TCP 4d10hlens-service ClusterIP 10.100.239.205 <none> 80/TCP 4d10hnotifier-service ClusterIP 10.102.67.212 <none> 80/TCP 4d8hpostgresql-postgresql ClusterIP 10.104.194.12 <none> 5432/TCP 4d10hpostgresql-postgresql-headless ClusterIP None <none> 5432/TCP 4d10hpostgresql-postgresql-metrics ClusterIP 10.103.17.122 <none> 9187/TCP 4d10hroot@cby:~# 拜访测试# 应用用户名：admin和上面提到的明码运行命令。root@cby:~# kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -dQn7GuI26j4HcuVW2# 拜访地址http://192.168.8.61:32489/# 用户名：admin# 明码：Qn7GuI26j4HcuVW2123 ...

在k8s上装置Harbor先前条件《kubernetes(k8s) 存储动静挂载》《在k8s（kubernetes）上装置 ingress V1.1.3》 参考我之前的文档进行部署https://www.oiox.cn/index.php/archives/32/https://www.oiox.cn/index.php/archives/142/ 我用到的批量将dockerhub导入阿里云#!/bin/bashfor((i=0;i<n;i++)); do echo "${i}"doneexport docker_images="goharbor/harbor-db:v2.6.2 goharbor/harbor-jobservice:v2.6.2 goharbor/harbor-portal:v2.6.2 goharbor/harbor-registryctl:v2.6.2 goharbor/notary-server-photon:v2.6.2 goharbor/notary-signer-photon:v2.6.2 goharbor/redis-photon:v2.6.2 goharbor/registry-photon:v2.6.2 goharbor/trivy-adapter-photon:v2.6.2"export aliyun_image="registry.cn-hangzhou.aliyuncs.com/chenby/"for images in $docker_images;do export end_image=`echo "$images" | awk -F "/" '{print $NF}'` docker pull "$images" docker tag "$images" "$aliyun_image""$end_image" docker push "$aliyun_image""$end_image" docker rmi "$images" docker rmi "$aliyun_image""$end_image"done装置helm工具# 装置helm工具curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3chmod 700 get_helm.sh./get_helm.sh增加Harbor 官网Helm Chart仓库# 增加Harbor 官网Helm Chart仓库root@cby:~# helm repo add harbor https://helm.goharbor.ioWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config"harbor" has been added to your repositories查看源列表# 查看源列表root@cby:~# helm repo listWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configNAME URL devtron https://helm.devtron.ai harbor https://helm.goharbor.ioroot@cby:~# 列出最新版本的包# 列出最新版本的包 root@cby:~# helm search repo harbor -l | grep harbor/harbor | head -4WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configharbor/harbor 1.10.2 2.6.2 An open source trusted cloud native registry th...harbor/harbor 1.10.1 2.6.1 An open source trusted cloud native registry th...harbor/harbor 1.10.0 2.6.0 An open source trusted cloud native registry th...harbor/harbor 1.9.4 2.5.4 An open source trusted cloud native registry th...root@cby:~# 下载Chart包到本地# 下载Chart包到本地root@cby:~# helm pull harbor/harbor --version 1.10.2WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configroot@cby:~# root@cby:~# ls harbor-1.10.2.tgz harbor-1.10.2.tgzroot@cby:~# root@cby:~# tar zxvf harbor-1.10.2.tgzroot@cby:~# cd harbor/root@cby:~/harbor# lltotal 276drwxr-xr-x 5 root root 4096 Nov 22 10:35 ./drwx------ 12 root root 4096 Nov 22 10:35 ../drwxr-xr-x 2 root root 4096 Nov 22 10:35 cert/-rw-r--r-- 1 root root 567 Nov 10 09:08 Chart.yamldrwxr-xr-x 2 root root 4096 Nov 22 10:35 conf/-rw-r--r-- 1 root root 57 Nov 10 09:08 .helmignore-rw-r--r-- 1 root root 11357 Nov 10 09:08 LICENSE-rw-r--r-- 1 root root 202142 Nov 10 09:08 README.mddrwxr-xr-x 16 root root 4096 Nov 22 10:35 templates/-rw-r--r-- 1 root root 33779 Nov 10 09:08 values.yamlroot@cby:~/harbor# 批改values.yaml配置# 批改values.yaml配置root@cby:~/harbor# sed -i "s#harbor.domain#oiox.cn#g" values.yaml# 设置为我的阿里云仓库root@cby:~/harbor# sed -i "s#repository: goharbor#repository: registry.cn-hangzhou.aliyuncs.com/chenby#g" values.yaml# 批改字段 externalURL # 留神 30785 是我的ingress端口，各位的端口应该和我的不一样root@cby:~/harbor# vim values.yamlexternalURL: https://core.oiox.cn:30785# debug看看配置与本人的环境是否匹配，是否须要批改root@cby:~/harbor# helm install harbor ./ --dry-run | grep oiox.cnWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config EXT_ENDPOINT: "https://core.oiox.cn:30785" - core.oiox.cn host: core.oiox.cn - notary.oiox.cn host: notary.oiox.cnThen you should be able to visit the Harbor portal at https://core.oiox.cn:30785root@cby:~/harbor# 装置# 创立命名空间root@cby:~/harbor# kubectl create namespace harbornamespace/harbor createdroot@cby:~/harbor# # 进行装置root@cby:~/harbor# helm install harbor . -n harborWARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/configWARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/configNAME: harborLAST DEPLOYED: Tue Nov 22 10:56:50 2022NAMESPACE: harborSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:Please wait for several minutes for Harbor deployment to complete.Then you should be able to visit the Harbor portal at https://core.oiox.cnFor more details, please visit https://github.com/goharbor/harborroot@cby:~/harbor# 编辑ingress配置root@cby:~# kubectl edit ingress -n harbor harbor-ingressroot@cby:~# kubectl edit ingress -n harbor harbor-ingress-notary# 增加字段 ingressClassName: nginxspec: ingressClassName: nginx rules: - host: core.oiox.cn http:# 查看root@cby:~# kubectl get ingress -n harbor harbor-ingress -o yamlapiVersion: networking.k8s.io/v1kind: Ingressmetadata: annotations: ingress.kubernetes.io/proxy-body-size: "0" ingress.kubernetes.io/ssl-redirect: "true" meta.helm.sh/release-name: harbor meta.helm.sh/release-namespace: harbor nginx.ingress.kubernetes.io/proxy-body-size: "0" nginx.ingress.kubernetes.io/ssl-redirect: "true" creationTimestamp: "2022-11-22T15:21:35Z" generation: 3 labels: app: harbor app.kubernetes.io/managed-by: Helm chart: harbor heritage: Helm release: harbor name: harbor-ingress namespace: harbor resourceVersion: "2070090" uid: def0b549-3a00-49a4-8ece-b5ce18205427spec: ingressClassName: nginx rules: - host: core.oiox.cn http: paths: - backend: service: name: harbor-core port: number: 80 path: /api/ pathType: Prefix - backend: service: name: harbor-core port: number: 80 path: /service/ pathType: Prefix - backend: service: name: harbor-core port: number: 80 path: /v2/ pathType: Prefix - backend: service: name: harbor-core port: number: 80 path: /chartrepo/ pathType: Prefix - backend: service: name: harbor-core port: number: 80 path: /c/ pathType: Prefix - backend: service: name: harbor-portal port: number: 80 path: / pathType: Prefix tls: - hosts: - core.oiox.cn secretName: harbor-ingressstatus: loadBalancer: ingress: - ip: 192.168.8.65root@cby:~# root@cby:~# kubectl get ingress -n harbor NAME CLASS HOSTS ADDRESS PORTS AGEharbor-ingress nginx core.oiox.cn 192.168.8.65 80, 443 9m8sharbor-ingress-notary nginx notary.oiox.cn 192.168.8.65 80, 443 9m8sroot@cby:~# 拜访测试# 查看管理员明码root@cby:~# kubectl get secret -n harbor harbor-core -o jsonpath='{.data.HARBOR_ADMIN_PASSWORD}'|base64 --decodeHarbor12345# 写入本地hosts配置root@cby:~# echo "192.168.8.65 core.oiox.cn" >> /etc/hostsroot@cby:~# sudo mkdir -p /etc/dockerroot@cby:~# sudo tee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": [ "https://hub-mirror.c.163.com", "https://mirror.baidubce.com" ], "insecure-registries": [ "hb.oiox.cn", "core.oiox.cn:30785" ], "exec-opts": ["native.cgroupdriver=systemd"]}EOFroot@cby:~# sudo systemctl daemon-reloadroot@cby:~# sudo systemctl restart dockerroot@cby:~# docker login -uadmin -pHarbor12345 core.oiox.cn:30785WARNING! Using --password via the CLI is insecure. Use --password-stdin.WARNING! Your password will be stored unencrypted in /root/.docker/config.json.Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-storeLogin Succeeded对于 ...

本文基于kubernetes1.25.4版本，所有代码援用为了简洁都去掉了日志打印相干的代码，尽量只保留有价值的内容。 首先，咱们先看看官网对 device-plugins 的定义是什么？Starting in version 1.8, Kubernetes provides a device plugin framework for vendors to advertise their resources to the kubelet without changing Kubernetes core code. Instead of writing custom Kubernetes code, vendors can implement a device plugin that can be deployed manually or as a DaemonSet. The targeted devices include GPUs, High-performance NICs, FPGAs, InfiniBand, and other similar computing resources that may require vendor specific initialization and setup. ...

因为数据隐衷和网络安全的思考，大多数toB场景的客户须要私有化利用交付，也就是须要交付到客户的环境里，这样的客户有政府、金融、军工、公安、大型企业、特色行业等，这些私有化场景限度很多，如何进步私有化利用交付的效率是个难题，本文将介绍，私有化利用交付有哪些技术？他们都各自有什么特点？私有化利用交付的倒退历程。 toB利用私有化交付的艰难点环境网络限度，影响交付效率 交付施行过程中不能不便查找材料；在交付过程中，交付人员须要跟公司的开发进行沟通，网络限度会影响合作工具的应用，有些客户环境甚至不能带手机，会影响解决问题的效率，环境越简单影响越大；在离线环境内，装置软件包也没方法间接下载，咱们须要将安装文件或配置文件打包成离线包，在客户环境导入。因为业务的复杂性会导致镜像很多且很大，只能有交付人员带移动硬盘到客户现场导入，导致在导入离线包就会破费较多工夫。甚至有些环境只能刻录光盘在客户环境导入，光盘自身存不了太大的包，只能分多个光盘刻录；客户基础设施差别，须要适配过程 在私有化场景，不同客户的装置环境也不一样，有些应用物理服务器，有些应用虚拟机，不同的虚拟机厂商也有差别。操作系统也各有不同，例如常见的操作系统有 CentOS/Debian/Ubuntu/Redhat，以后还有很多国产化操作系统。CPU 架构也可能不同，有 X86、ARM 等；资源筹备周期长，须要审批流程；交付的利用须要很重的适配过程，要么在公司适配，要么在客户现场适配；因为环境差别很大，利用交付完须要残缺测试和验证，须要大量的人力和工夫投入；交付人员的技术门槛高 交付人员须要懂底层硬件和网络；交付人员须要懂操作系统和零碎运维，须要懂服务治理、高可用、平安、性能剖析、备份复原、交付开发等等；交付人员要能独立排查交付利用的问题，须要很强的技术根底；定制化交付迭代效率低 在定制化交付场景，客户会参加到开发过程中，客户须要看到成果后反馈问题，再继续迭代，直到客户称心，过程中须要频繁降级产品；如果开发人员在公司定制开发，降级过程简单，沟通低效；如果开发人员在客户现场，没有好的开发工具和环境，开发效率低，人力投入大；前期保护难度大 利用交付实现后，前期须要保障利用运行的稳定性，离线环境近程没方法运维，报警没方法收回来，运维的难度大；产品有Bug、一些预期内的变更或产品升级都须要出差客户现场，反对的老本比拟高；传统利用交付传统的利用交付是间接交付二进制的可执行文件或软件包： 二进制的可执行文件： Java 的 Jar，Linux 的可执行文件，Windows的 EXE 等。软件包： CentOS 应用 RPM 包，Debian 应用 DEB 包，Java Web 应用 WAR 包。装置他们都须要先装置依赖的环境和根底软件，YUM 和 DEB 有本人的治理依赖的软件源，但离线环境用不了，如果客户的操作系统不同，还须要另外想方法解决，运行这类服务为了解决启动和主动重启的问题，还须要通过 Systemd 或 Supervisor 的形式来治理。如果交付单体架构的利用传统利用交付形式还能胜任，但如果是简单的微服务架构，传统利用交付形式将难以胜任。 在传统利用交付过程中，治理这些运行环境和操作系统差别是一个痛点，容器的呈现解决了这个问题。 以后云原生技术利用交付云原生利用交付次要应用的容器和 Kubernetes 相干技术。 Docker 镜像交付Docker 将业务和依赖的库一起打包成 Docker 镜像，在这个镜像中蕴含所有环境和利用，这样就能够达成一处打包、到处应用，咱们能够将该镜像在任何反对 Docker 的操作系统上运行。Docker 的个性确实解决了很多开发、交付以及其余许多问题，因而 Docker 容器概念迅速的被遍及。 在微服务架构场景，须要多个服务或利用一起交付，服务之间有依赖，还有简单的配置，DockerCompose 解决了这个问题。 Docker-Compose利用交付DockerCompose 将多个服务或利用应用 YAML 的形式治理，能够利用 DockerCompose 命令装置部署和治理，对于一个微服务架构的利用，利用 DockerCompose 命令就能够在任何操作系统实现一键装置和运行，当然前提是须要装置好 Docker 和 DockerCompose。 对于单机场景 DockerCompose 能够实用，当利用须要高可用或多节点分布式部署，DockerCompose 就不能胜任，Kubernetes 的呈现解决了容器的高可用和散布式调度问题。 Kubernetes YAML利用交付在 Kubernetes 中部署业务咱们须要定义 Deployment Statefulset Service 等资源类型，通过调整正本的形式 Kubernetes 会主动调度到多个节点实现业务高可用，在交付时咱们只须要将这些 YAML 资源和 Image 导出，在客户的 Kubernetes 环境中部署并交付给客户。这种交付形式须要客户环境有 Kubernetes 或在客户环境装置 Kubernetes。 ...

Traefik Hub 简介️Reference: 你的云原生网络平台 --公布和加固你的容器从未如此简略。Traefik Hub 为您在 Kubernetes 或其余容器平台上运行的服务提供一个网关。 Traefik Hub 定位： 云原生网络平台它有 2 大外围性能，我这次体验感觉也是如此： （易于）公布（以网站域名的模式公布容器服务）（易于）加固 (HTTPS + 认证）Traefik Hub 次要性能公布部署 Hub 容器，抉择你的服务，并在几秒钟内取得对你的容器的平安公共拜访。 平安加固通过平安的隧道拜访你的容器，部署行业标准的认证，并自动化 TLS 证书治理。 可伸缩从繁多的 Kubernetes 或 Docker 集群开始，在你的集中式 Hub 仪表板上（将 Traefik Hub Agent) 无缝扩大到多个集群。 Traefik Hub 工作原理 在你本人的 Kubernetes 或 Docker 集群中，装置 2 个 Traefik Hub 相干组件： TraefikTraefik Hub Agent（实际上是 3 个组件） Hub Agent Auth ServerHub Agent ControllerHub Agent Tunnel当你对外公布服务的时候，Traefik Hub 会给你的服务调配一个惟一的域名 (DNS) 你须要拜访该域名的 HTTPS 协定而后 Traefik Hub 接管到申请，将申请通过 Traefik Hub 与你本人的 Traefik Hub Agent 之间建设的平安隧道，将申请转发给 Traefik Hub AgentTraefik Hub Agent 再将申请转发给 Traefik, 最初流转到具体的服务Traefik Hub 的关联性能️一键服务公布在边缘的任何中央进行拜访从未如此简略。对于每个公布的服务，Traefik Hub 提供了一个惟一的 DNS 名称，能够立刻用于从互联网的任何中央拜访该容器。 ...

概述通常咱们要 silence 某个 AlertManager 的 alert 时，须要通过 UI 界面操作，如下图： 效率有点低，而且不够自动化，那么是否能够有一种方法疾速创立 AlertManager silence 呢？ -- 有的，通过 API. API Payloadv1如下： { "matchers": [ { "name": "alername1", "value": ".*", "isRegex": true } ], "startsAt": "2022-04-29T22:12:33.533Z", "endsAt": "2022-04-29T23:11:44.603Z", "createdBy": "api", "comment": "Silence", "status": { "state": "active" }}v2{ "matchers": [ { "name": "service", "value": "rancher", "isRegex": false, "isEqual": true }, { "name": "alertname", "value": "TargetDown", "isRegex": false, "isEqual": true } ], "startsAt": "2022-04-29T10:11:35.656Z", "endsAt": "2022-04-29T12:11:35.656Z", "createdBy": "Casey Cui", "comment": "配置谬误导致的误报", "id": null}具体实现curl 实现 Notes: ...

Kubernetes 是当今许多公司采纳的容器编排平台，它的施行须要对其生态系统有肯定的理解，以便部署一个筹备好用于生产的集群。然而从原则上来说，Kubernetes 并不是一个平安的平台，因为它不足解决大多数与平安相干工作的本地工具。 因而，Kubernetes 的施行工作原理或工具至关重要，这个过程也须要包含运维、开发、平安等团队的独特单干，从而可能在短时间内以最快的速度发现异常，并进步编排器及其资源的安全级别。在本文中，咱们将会一起探讨爱护集群的平安准则。  Pre-Commit HooksDevSecOps 的次要指标就是通过尽早在继续集成流水线中增加自动化流程，从最大水平上缩小对生产的影响，这也是当下公认的 DevSecOps 准则。因而，企业也开始引入“平安左移”的做法，来促成开发、平安和经营团队之间的独特合作，通过将平安和测试过程转移到软件开发生命周期的左侧。从增加预提交（Pre-commit）开始，在开发周期的晚期确保应用程序平安。  最近几年呈现了几种工具来促成这种集成，以实现以下工作： 格式化 YAML 文件代码检测 Kubernetes 资源配置中的异样强制利用配置和安全策略以保障良好的开发实际在提交任何源代码之前检测敏感数据 以下是管制 YAML 定义文件的三个不错的工具示例： YAML lintCheckovK8svalidate 继续集成查看预提交测试（Pre-commit test）通常被用来促成团队单干，然而 DevSecOps 团队很少会强制执行预提交测试。在某些状况下，pre-commit 工作的实现可能很麻烦，尤其是对于大型团队而言。不过这些测试依然是必要的，因而必须在继续集成过程中推动。Pre-commit 工作能够分为两个局部，首先对代码进行格式化，而后对代码进行扫描来验证配置文件的一致性。   镜像扫描因为许多人认为官网镜像是百分之百平安的，因而在部署之前往往会疏忽扫描镜像这个步骤，但扫描镜像很重要，因为新的破绽层出不穷。同时更新任何具备安全漏洞的零碎来限度歹意攻击者的攻打范畴同样也很重要。   这些扫描工作须要在容器生命周期的不同阶段执行： 在将镜像公布到近程镜像仓库之前，确保相干镜像在部署之前就合乎平安规定在容器运行期间，尽快确定须要重建的镜像来纠正新发现的破绽  集群扫描对 Kubernetes 集群的爱护取决于公司的平安治理。利用的政策必须思考到可拜访性、保护、数据管理等。此外，更重要的是要恪守社区确定的一些规定，来确保在装置集群后立刻取得良好的根本安全级别。还倡议定期扫描 Kubernetes 集群，以便在其运行时辨认任何与配置相干的已知异样。   平安上下文Kubernetes 平安上下文遵循最小权限准则：对应人员该当只取得执行工作所需的权限。平安上下文是一种容许管理员依据每个资源定义平安相干参数的工具，它容许每个资源取得拜访主机服务器上的资源所需的特定权限，同时回绝拜访它不特地须要的资源。在 Kubernetes 上下文中，平安上下文定义了 pod 中各个容器的权限。   治理平安上下文须要对集群及其装置和生态系统进行高级治理和了解，只管它们的实现很简单，但这些措施依然是限度任何 pod 或容器操作的十分无效的办法。  基于角色的访问控制利用 Kubernetes 基于角色的拜访治理 (RBAC) 是爱护在平台上运行的集群和应用程序的根本第一步。RBAC 准则非常简单：依据用户身份定义谁能够拜访什么。  Kubernetes 有一个无效的粒度来治理对不同资源的拜访： 用户拜访应用程序拜访用于定义权限的角色仅限于单个命名空间的资源集群角色以利用集群级别的限度  这种粒度与内部身份提供者（如 Okta、Gmail 等）相结合，能够对拜访进行十分精密的治理，从而确保对资源的管制以及可审计性。   网络政策网络安全策略管理也是“平安左移”概念的一部分。Kubernetes 网络策略容许管理员和开发人员应用规定限度容许哪些网络流量，“左移”准则容许开发人员在不理解低级网络概念的状况下平安地拜访和拜访他们的应用程序。  DevOps 团队能够强制执行默认策略，开发人员能够治理特定的拜访权限，从而使他们在管理应用程序方面具备肯定的自主权。网络策略由部署在集群上的容器网络接口 (CNI) 管制。几个 CNI 提供了此性能，但这里有两个值得特地留神： Calico可能是 Kubernetes 生态系统中最驰名和应用最宽泛的 CNI。在收费版本中，Calico 能够将这些网络规定治理到 OSI 模型的第 3 级。Cilium 是一个很好的代替计划或附加组件，在 OSI 模型上提供了许多收费性能。  政策执行Kubernetes 是一个次要基于 API 的应用程序。这种办法使得开发对这些不同资源的访问控制工具得以使用，以便对其进行审计和爱护。准入控制器（Admission Controller）是 Kubernetes 客户端（例如 Kubectl）收回的所有申请的入口点。在此阶段增加检查点能够在执行所有查问之前对其进行验证，从而避免任何偏离公司平安治理的行为。   ...

什么是 cgroup️Reference: control groups(控制组)，通常被称为cgroup，是Linux内核的一项性能。它容许将过程组织成分层的组，而后限度和监控各种资源的应用。 内核的cgroup接口是通过一个叫做cgroupfs的伪文件系统提供的。 分组是在外围的cgroup内核代码中实现的，而资源跟踪和限度是在一组每个资源类型的子系统中实现的（内存、CPU等等）。 cgroup 是容器和云原生的底层技术栈. kubelet 和 CRI 都须要对接 cgroup 来强制执行为 Pod 和容器治理资源，即: requests/limits 和 cpu/memory。 Linux 中有两个 cgroup 版本：cgroup v1 和 cgroup v2。cgroup v2 是新一代的 cgroup API。 Kubernetes 自 v1.25 起 cgroup2 个性正式 stable. cgroup v2 有哪些劣势️Reference: cgroup v2 提供了一个具备加强资源管理能力的对立控制系统。 cgroup v2 对 cgroup v1 进行了多项改良，例如： API 中单个对立的层次结构设计更平安的子树委派给容器更新的性能个性， 例如压力阻塞信息（Pressure Stall Information，PSI）跨多个资源的加强资源分配治理和隔离 对立核算不同类型的内存调配（网络内存、内核内存等）思考非即时资源变动，例如页面缓存回写一些 Kubernetes 个性专门应用 cgroup v2 来加强资源管理和隔离。 例如，MemoryQoS 个性改良了内存 QoS 并依赖于 cgroup v2 原语。 应用 cgroup v2 前提️Reference: ...

minikube image load xxx:xx参考 https://minikube.sigs.k8s.io/...https://juejin.cn/post/707831...

apiVersion解释: 以后所有可用的API版本罕用的apiVersion: v1： Kubernetes API的稳固版本，蕴含很多外围对象：pod、service等。apps/v1： 蕴含一些通用的应用层的api组合，如：Deployments, RollingUpdates, and ReplicaSets。batch/v1： 蕴含与批处理和相似作业的工作相干的对象，如：job、cronjob。autoscaling/v1： 容许依据不同的资源应用指标主动调整容器。networking.k8s.io/v1： 用于Ingress。rbac.authorization.k8s.io/v1：用于RBAC$ kubectl api-versionsadmissionregistration.k8s.io/v1apiextensions.k8s.io/v1apiregistration.k8s.io/v1apps/v1authentication.k8s.io/v1authorization.k8s.io/v1autoscaling/v1autoscaling/v2autoscaling/v2beta1autoscaling/v2beta2batch/v1batch/v1beta1certificates.k8s.io/v1coordination.k8s.io/v1discovery.k8s.io/v1discovery.k8s.io/v1beta1events.k8s.io/v1events.k8s.io/v1beta1flowcontrol.apiserver.k8s.io/v1beta1flowcontrol.apiserver.k8s.io/v1beta2networking.k8s.io/v1node.k8s.io/v1node.k8s.io/v1beta1openebs.io/v1alpha1policy/v1policy/v1beta1rbac.authorization.k8s.io/v1scheduling.k8s.io/v1storage.k8s.io/v1storage.k8s.io/v1beta1v1kind解释: 资源对象的类型如 pod、deployment、statefulset、job、cronjobmetadata罕用的配置项有 name,namespacename配置资源对象显示的名字namespace配置归属的命名空间spec解释: 资源对象的具体资源清单// 以pod为例apiVersion: v1 #必选，版本号，例如v1kind: Pod #必选，Pod metadata: #必选，元数据 name: nginx #必选，Pod名称 labels: #自定义标签 app: nginx #自定义标签名字 spec: #必选，Pod中容器的具体定义 containers: #必选，Pod中容器列表，一个pod里会有多个容器 - name: nginx #必选，容器名称 image: nginx #必选，容器的镜像名称 imagePullPolicy: IfNotPresent # [Always | Never | IfNotPresent] #获取镜像的策略 Alawys示意下载镜像 IfnotPresent示意优先应用本地镜像，否则下载镜像，Nerver示意仅应用本地镜像 ports: #须要裸露的端口库号列表 - containerPort: 80 #容器须要监听的端口号 restartPolicy: Always # [Always | Never | OnFailure]#Pod的重启策略，Always示意一旦不论以何种形式终止运行，kubelet都将重启，OnFailure示意只有Pod以非0退出码退出才重启，Nerver示意不再重启该Pod // 以Service为例apiVersion: v1kind: Servicemetadata: name: service-hello labels: name: service-hellospec: type: NodePort #这里代表是NodePort类型的,另外还有ingress,LoadBalancer ports: - port: 80 #这里的端口和clusterIP(kubectl describe service service-hello中的IP的port)对应，即在集群中所有机器上curl 10.98.166.242:80可拜访公布的应用服务。 targetPort: 8080 #端口肯定要和container裸露进去的端口对应，nodejs裸露进去的端口是8081，所以这里也应是8081 protocol: TCP # 反对TCP UDP SCTP nodePort: 31111 # 所有的节点都会凋谢此端口30000--32767，此端口供内部调用。 selector: run: hello #这里选择器肯定要抉择容器的标签，之前写name:kube-node是错的。portclusterIp：k8s集群外部拜访service的端口，即通过clusterIP: port能够拜访到某个servicenodePort：k8s集群内部拜访service的端口，通过nodeIP: nodePort能够从内部拜访到某个service。targetPort：pod的端口，从port和nodePort来的流量通过kube-proxy流入到后端pod的targetPort上，最初进入容器。containerPort：containerPort是pod外部容器的端口，targetPort映射到containerPort

装置长久化存储# https://github.com/openebs/openebs/blob/main/translations/README.zh.mdkubectl apply -f https://openebs.github.io/charts/openebs-operator.yaml# 查看集群的StorageClasskubectl get sc # 将 openebs-hostpath 设置为 defaultkubectl patch storageclass openebs-hostpath -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'创立命名空间kubectl create namespace devops部署redis创立pvc # 创立redis-pvc.yamlapiVersion: v1kind: PersistentVolumeClaimmetadata: name: redis-pvc namespace: devopsspec: accessModes: - ReadWriteOnce # 这里指定应用的 OpenEBS 的 sc storageClassName: openebs-hostpath resources: requests: storage: 5Gi# 执行创立命令kubectl apply -f redis-pvc.yaml# 查看刚刚创立的pvckubectl get pvc -n devops redis-pvc创立Deployment # 创立redis-deploy.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: redis namespace: devops labels: name: redisspec: replicas: 1 selector: matchLabels: name: redis template: metadata: name: redis labels: name: redis spec: containers: - name: redis image: sameersbn/redis imagePullPolicy: IfNotPresent ports: - name: redis containerPort: 6379 volumeMounts: - mountPath: /var/lib/redis name: data livenessProbe: exec: command: - redis-cli - ping initialDelaySeconds: 30 timeoutSeconds: 5 readinessProbe: exec: command: - redis-cli - ping initialDelaySeconds: 5 timeoutSeconds: 1 volumes: - name: data persistentVolumeClaim: claimName: redis-pvc# 执行创立命令kubectl apply -f redis-deploy.yaml# 查看刚刚创立的deploymentkubectl get pod -n devops创立Service ...

kubernetes 的TCP 数据包可视化介绍k8spacket是用 Golang 编写的工具，它应用gopacket第三方库来嗅探工作负载（传入和传出）上的 TCP 数据包。它在运行的容器网络接口上创立 TCP 侦听器。当 Kubernetes 创立一个新容器时，CNI 插件负责提供与其余容器进行通信的可能性。最常见的办法是用linux namespace隔离网络并用veth pair连贯隔离的 namespace 与网桥。除了bridge 类型，CNI 插件还能够应用其余类型（vlan, ipvlan,macvlan)，但都为容器创立了一个网络接口，它是k8spacket嗅探器的次要句柄。 k8spacket有助于理解 Kubernetes 集群中的 TCP 数据包流量： 显示集群中工作负载之间的流量告诉流量在集群外路由到哪里显示无关连贯敞开套接字的信息显示工作负载发送/接管的字节数计算建设连贯的工夫显示整个集群中工作负载之间的网络连接拓扑k8spacket是一个 Kubernetes API 客户端，能够将嗅探到的工作负载解析为可视化上可见的集群资源名称（Pods和Services）。它作为DaemonSet Pod启动，应用 hostNetwork，并监听节点上的网络接口。 k8spacket 收集 TCP 流、解决数据，应用 Node Graph API Grafana 数据源插件（详情请查看 Node Graph API 插件），通过 API 展现在Grafana面板。 要装置k8spacket，须要同时装置 Grafana。上面将在Kind装置的 k8s 集群上做演示。 增加 k8spacket 的helm源[[email protected] ~]# helm repo add k8spacket https://k8spacket.github.io/k8spacket-helm-chart"k8spacket" has been added to your repositories[[email protected] ~]#[[email protected] ~]#[[email protected] ~]#[[email protected] ~]# helm install k8spacket --namespace k8spacket k8spacket/k8spacket --create-namespaceNAME: k8spacketLAST DEPLOYED: Thu Oct 27 18:48:30 2022NAMESPACE: k8spacketSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:1. Get the application URL by running these commands: export NODE_PORT=$(kubectl get --namespace k8spacket -o jsonpath="{.spec.ports[0].nodePort}" services k8spacket) export NODE_IP=$(kubectl get nodes --namespace k8spacket -o jsonpath="{.items[0].status.addresses[0].address}") echo http://$NODE_IP:$NODE_PORT[[email protected] ~]#查看 pod 信息[email protected]:~# kubectl get pod -n k8spacketNAME READY STATUS RESTARTS AGEk8spacket-46587 0/1 CrashLoopBackOff 2 (23s ago) 2m24sk8spacket-9wb5q 0/1 CrashLoopBackOff 1 (6s ago) 2m24sk8spacket-grh7k 0/1 ImagePullBackOff 0 2m24sk8spacket-hcgg4 0/1 CrashLoopBackOff 1 (4s ago) 2m24sk8spacket-ng99p 0/1 CrashLoopBackOff 1 (3s ago) 2m24sk8spacket-p7hgb 0/1 CrashLoopBackOff 1 (4s ago) 2m24sk8spacket-pk4zt 0/1 CrashLoopBackOff 1 (4s ago) 2m24sk8spacket-tcksl 0/1 CrashLoopBackOff 1 (6s ago) 2m24sk8spacket-tkzcc 0/1 CrashLoopBackOff 1 (8s ago) 2m24sk8spacket-w8r5r 0/1 CrashLoopBackOff 3 (11s ago) 2m24s[email protected]:~#查看报错为 tunl0 问题[[email protected] ~]# kubectl logs -n k8spacket k8spacket-465872022/10/27 13:35:36 Serving requests on port 66762022/10/27 13:35:36 Refreshing interfaces for capturing...2022/10/27 13:35:36 Starting capture on interface "cilium_host"2022/10/27 13:35:36 Starting capture on interface "tunl0"2022/10/27 13:35:36 Starting capture on interface "lxc_health"2022/10/27 13:35:36 Starting capture on interface "cilium_net"2022/10/27 13:35:36 Starting capture on interface "lxcaaf84592af2d"2022/10/27 13:35:36 Starting capture on interface "lxcc06519232b44"2022/10/27 13:35:36 reading in packets2022/10/27 13:35:36 reading in packets2022/10/27 13:35:36 error opening pcap handle: tunl0: That device is not up[[email protected] ~]#批改配置# 将 charts 包拉取到本地 在进行批改信息[[email protected] ~]# cd /tmp/[[email protected] tmp]# helm fetch k8spacket/k8spacket[[email protected] tmp]# tar -zxf k8spacket-0.1.3.tgz [[email protected] tmp]# cd k8spacket# 设置配置为 command: "ip address | grep @ | grep -v tunl0 | sed -E 's/.* (\\w+)@.*/\\1/' | tr '\\n' ',' | sed 's/.$//'"# 残缺配置如下[[email protected] k8spacket]# vim values.yaml[[email protected] k8spacket]# cat values.yamlreplicaCount: 1affinity: {}image: repository: docker.io/k8spacket/k8spacket pullPolicy: IfNotPresentserviceAccount: create: true # Annotations to add to the service account annotations: {}clusterRole: create: truenodeSelector: {}podAnnotations: {}priorityClassName: ""podSecurityContext: runAsUser: 1000securityContext: allowPrivilegeEscalation: true capabilities: add: [ "NET_ADMIN", "NET_RAW" ]service: type: ClusterIP port: 8080 nodePort:resources: requests: memory: "1000Mi" cpu: "250m" limits: memory: "1500Mi" cpu: "500m"tolerations: []k8sPacket: metrics: ## Hide source port when 'true' (set to string value 'dynamic' instead of decimal real source port) for Prometheus metrics cardinality reasons hideSourcePort: true reverseLookup: ## Reverse lookup db file based on GeoLite2 Free Geolocation Data ## See: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data?lang=en geoipDBPath: "/home/k8spacket/GeoLite2-City.mmdb" ## Whois result match regexp whoisRegexp: "(?:OrgName:|org-name:)\\s*(.*)" tcp: listener: port: 6676 interfaces: ## Command to achieve containers network interfaces command: "ip address | grep @ | grep -v tunl0 | sed -E 's/.* (\\w+)@.*/\\1/' | tr '\\n' ',' | sed 's/.$//'" ## How often refresh the list of network interfaces to listen refreshPeriod: "10s" assembler: ## See: https://pkg.go.dev/github.com/google/gopacket/tcpassembly#AssemblerOptions maxPagesPerConnection: 50 maxPagesTotal: 50 ## Every (periodDuration) seconds, flush connections that haven't seen activity in the past (closeOlderThanDuration) seconds. flushing: periodDuration: "10s" closeOlderThanDuration: "20s"[[email protected] k8spacket]#重新安装 k8spacket[[email protected] k8spacket]# helm uninstall k8spacket -n k8spacket[[email protected] k8spacket]# helm install k8spacket --namespace k8spacket . --create-namespaceNAME: k8spacketLAST DEPLOYED: Thu Oct 27 21:47:38 2022NAMESPACE: k8spacketSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:1. Get the application URL by running these commands: export NODE_PORT=$(kubectl get --namespace k8spacket -o jsonpath="{.spec.ports[0].nodePort}" services k8spacket) export NODE_IP=$(kubectl get nodes --namespace k8spacket -o jsonpath="{.items[0].status.addresses[0].address}") echo http://$NODE_IP:$NODE_PORT[[email protected] k8spacket]#查看验证[[email protected] ~]# kubectl get pod -n k8spacket -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESk8spacket-8kxnx 1/1 Running 0 4m27s 192.168.1.66 k8s-node-3 <none> <none>k8spacket-cqpks 1/1 Running 0 4m27s 192.168.1.70 k8s-node-6 <none> <none>k8spacket-h72fc 1/1 Running 0 4m27s 192.168.1.67 k8s-node-4 <none> <none>k8spacket-jkxg9 1/1 Running 0 4m27s 192.168.1.75 k8s-node-7 <none> <none>k8spacket-kgpql 1/1 Running 0 4m27s 192.168.1.62 k8s-master-2 <none> <none>k8spacket-lf9br 1/1 Running 0 4m27s 192.168.1.61 k8s-master-1 <none> <none>k8spacket-mcbv5 1/1 Running 0 4m27s 192.168.1.68 k8s-node-5 <none> <none>k8spacket-ndlzt 1/1 Running 0 4m27s 192.168.1.64 k8s-node-1 <none> <none>k8spacket-vfg2x 1/1 Running 0 4m27s 192.168.1.63 k8s-master-3 <none> <none>k8spacket-vvwtr 1/1 Running 0 4m27s 192.168.1.65 k8s-node-2 <none> <none>[[email protected] ~]#[[email protected] ~]# kubectl get svc -n k8spacket -o wideNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTORk8spacket ClusterIP 10.110.30.53 <none> 8080/TCP 4m31s app.kubernetes.io/instance=k8spacket,app.kubernetes.io/name=k8spacket[[email protected] ~]#拜访验证[[email protected] ~]# curl 10.110.30.53:8080/metrics装置 dashboards 配置[[email protected] ~]# cd /tmp/[[email protected] tmp]#[[email protected] tmp]# wget https://github.com/k8spacket/k8spacket/archive/refs/heads/master.zip[[email protected] tmp]# unzip master.zip[[email protected] tmp]#[[email protected] tmp]# cd k8spacket-master[[email protected] k8spacket-master]# [[email protected] k8spacket-master]# kubectl apply -f ./dashboards/configmap/k8spacket-logs-dashboard createdconfigmap/k8spacket-metrics-dashboard createdconfigmap/k8spacket-node-graph-dashboard created[[email protected] k8spacket-master]#装置 Grafana[[email protected] tmp]# helm repo add grafana https://grafana.github.io/helm-charts"grafana" has been added to your repositories[[email protected] tmp]# helm fetch grafana/grafana[[email protected] tmp]#[[email protected] tmp]# tar -zxf grafana-6.43.1.tgz 批改Grafana配置内容[[email protected] tmp]# cd grafana/[[email protected] grafana]#[[email protected] grafana]# vim values.yaml批改以下配置内容persistence: type: pvc enabled: true env: GF_INSTALL_PLUGINS: hamedkarbasi93-nodegraphapi-datasource dashboardProviders: dashboardproviders.yaml: apiVersion: 1 providers: - name: 'default' orgId: 1 folder: '' type: file disableDeletion: false editable: true options: path: /var/lib/grafana/dashboards/default dashboardsConfigMaps: default: k8spacket-node-graph-dashboard datasources: nodegraphapi-plugin-datasource.yaml: apiVersion: 1 datasources: - name: "Node Graph API" jsonData: url: "http://k8spacket.k8spacket.svc.cluster.local:8080" access: "proxy" basicAuth: false isDefault: false readOnly: false type: "hamedkarbasi93-nodegraphapi-datasource" typeLogoUrl: "public/plugins/hamedkarbasi93-nodegraphapi-datasource/img/logo.svg" typeName: "node-graph-plugin" orgId: 1 version: 1装置Grafana[[email protected] grafana]# helm install grafana -f values.yaml ./NAME: grafanaLAST DEPLOYED: Thu Oct 27 22:11:27 2022NAMESPACE: defaultSTATUS: deployedREVISION: 1NOTES:1. Get your 'admin' user password by running: kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo2. The Grafana server can be accessed via port 80 on the following DNS name from within your cluster: grafana.default.svc.cluster.local Get the Grafana URL to visit by running these commands in the same shell: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=grafana,app.kubernetes.io/instance=grafana" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace default port-forward $POD_NAME 30003. Login with the password from step 1 and the username: admin[[email protected] grafana]# 批改为NodePort[[email protected] grafana]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEecho-a ClusterIP 10.108.160.226 <none> 8080/TCP 6d9hecho-b NodePort 10.108.200.169 <none> 8080:31414/TCP 6d9hecho-b-headless ClusterIP None <none> 8080/TCP 6d9hecho-b-host-headless ClusterIP None <none> <none> 6d9hgrafana ClusterIP 10.101.109.183 <none> 80/TCP 4mkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d9h[[email protected] grafana]#[[email protected] grafana]# kubectl edit svc grafanaservice/grafana edited[[email protected] grafana]#[[email protected] grafana]# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEecho-a ClusterIP 10.108.160.226 <none> 8080/TCP 6d9hecho-b NodePort 10.108.200.169 <none> 8080:31414/TCP 6d9hecho-b-headless ClusterIP None <none> 8080/TCP 6d9hecho-b-host-headless ClusterIP None <none> <none> 6d9hgrafana NodePort 10.101.109.183 <none> 80:30973/TCP 4m37skubernetes ClusterIP 10.96.0.1 <none> 443/TCP 6d9h[[email protected] grafana]# 查看Grafana明码[[email protected] grafana]# kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo9O1Hd9LOqJ6LKUjZTlEWAGeXRitr0CZd4p6fr00J[[email protected] grafana]# 拜访地址拜访http://192.168.1.61:30973/增加 Node Graph API 插件http://192.168.1.61:30973/plugins查看 Node Graph API 数据收集源http://192.168.1.61:30973/datasources对于 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 Apache APISIX Ingress v1.5.0 公布目前 Apache APISIX Ingress controller 我的项目曾经进入了 v1.5 的公布窗口，之前曾经公布了 1.5.0-rc1 版本，现在发现的一些 bug 曾经失去修改，咱们曾经打算公布 v1.5.0 的正式版本了。待投票流程完结后，将会有正式的布告和对应的 Release 公布。 间隔上一个个性版本 v1.4.0 公布曾经过来了将近 7 个月的工夫，这期间咱们进行了大量的开发工作，有 155 次提交和 32 位贡献者参加，感激大家的参加让这个版本有了很大的不同。这里我列一些次要的变动，后续还会有专门的发版布告和个性解读文章等。 在这个版本中，正式将所有 CRD 资源的 API version 降级到了 v2 stable ，这也标记着用户应用起来会更加的不便和对立，同时这些资源也曾经过多个版本迭代和用户在生产环境的应用，达到了足够稳固的级别。 此外，在这个版本中提供了对 Gateway API 的反对，不过此个性目前尚处于试验性质，默认不开启，用户能够通过为它传递 enable_gateway_api=true 的配置项来开启此能力。在下个版本中咱们将引入 Gateway API 我的项目的一致性测试，来保障咱们的实现与 Gateway API 我的项目的一致性。这样做的益处在于但凡通过了 Gateway API 一致性校验的实现，均可进行相互替换，不会存在锁定的状况。而且在迁徙的过程中，也能够保障配置的兼容性。 Apache APISIX Ingress controller 我的项目是反对多种配置形式的，无论应用 CRD 的形式，或者应用 Kubernetes 中原生的 Ingress 资源都是能够的。但在之前版本中，对于 Ingress 资源来说，想要应用 APISIX 提供的 plugin 能力，就必须先实现一个对应的 annotation，这种形式可扩大能力很差。在这个版本中，咱们为 Ingress 资源提供了一个新的 annotation 容许所有的 Ingress 资源能够间接应用 APISIX 所提供的 70+ 种 plugin 的能力，这对于一些应用开源的仅反对配置 Ingress 资源的用户而言，是十分有用的。 ...

同类型，支流的有上面四个： minikubekindmicrok8sk3s因为 minikube 是谷歌官网出品，所以一开始想用 minikube，然而这玩意，基本装不上，只能寻求其余替代品了

一、环境筹备1.1 硬件要求序号硬件硬件1CPU至多2核2内存至多2G3磁盘至多50G1.2 集群节点主机名主机IPk8s-master0110.211.55.15k8s-node0110.211.55.16k8s-node0210.211.55.17k8s-node0310.211.55.18二、下载 centoscentos下载地址： http://mirrors.aliyun.com/centos/7/isos/x86_64/举荐大家应用 centos7.6 以上版本 查看 centos 零碎版本命令： cat /etc/centos-release配置阿里云 yum 源： # 1.下载安装wget yum install -y wget # 2.备份默认的yum mv /etc/yum.repos.d /etc/yum.repos.d.backup # 3.设置新的yum目录 mkdir -p /etc/yum.repos.d # 4.下载阿里yum配置到该目录中，抉择对应版本 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo # 5.更新epel源为阿里云epel源 mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup mv /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel- testing.repo.backupwget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel- 7.repo# 6.重建缓存 yum clean all yum makecache # 7.看一下yum仓库有多少包 yum repolist yum update降级零碎内核 rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm yum --enablerepo=elrepo-kernel install -y kernel-lt grep initrd16 /boot/grub2/grub.cfg grub2-set-default 0reboot查看centos零碎内核命令： ...

K8S INTERNAL 系列容器编排之争在 Kubernetes 一统天下场面造成后，K8S 成为了云原生时代的新一代操作系统。K8S 让所有变得简略了，但本身逐步变得越来越简单。【K8S Internals 系列专栏】围绕 K8S 生态的诸多方面，将由博云容器云研发团队定期分享无关调度、平安、网络、性能、存储、利用场景等热点话题。心愿大家在享受 K8S 带来的高效便当的同时，又能够如庖丁解牛般领略其内核运行机制的魅力。 本文将为大家介绍一个 K8S 故障排错新伎俩：kubectl debug。 一、kubectl debug 起源开发者喜爱在生产部署中应用极致精简的容器镜像，这也是容器技术中的一个最佳实际。这种精简主义有很多益处，而且在大多数状况下运行良好，然而一旦须要在生产中排除一些故障时，这就变得很艰难了，因为精简后的容器广泛缺失罕用的排障工具，有些甚至连 bash/sh 解释器都没有。 过来几年，K8S 社区就始终有一个声音，如果有一种办法能够为正在运行的 Pod 启用某种调试模式，再附加一套调试工具能在容器中执行，那就最好不过了。这种新的调试模式波及的改变面很广，从 16 年就呈现了相干的 Issue Support for troubleshooting distroless containers 开始，直至 K8S1.23 版本，kubectl debug 这项性能才逐步成熟。 kubectl debug 是一款 k8s pod 诊断工具，可能帮忙进行 Pod 的排障诊断。在 k8s v1.16 ~ v1.22 中是 Alpha 状态，默认敞开。从 v1.23 开始成为 Beta 状态，默认开启。 二、kubectl debug 工作原理咱们晓得，容器实质上是带有 cgroup 资源限度和 namespace 隔离的一组过程。因而，咱们只有启动一个过程，并且让这个过程退出到指标容器的各种 namespace 中，这个过程就能 “进入容器外部”（留神引号），与容器中的过程 “看到” 雷同的根文件系统、虚构网卡、过程空间了 —— 这也正是 docker exec 和 kubectl exec 等命令的运行形式。 ...

背景k8s官网部署装置集群的是应用kubeadm形式，然而该形式比较复杂繁琐，所以产生了一些新的部署装置集群形式，比方k3s和rke2等新形式 k3s有着十分宏大的社区反对，部署装置也非常简单，设计为轻量级的k8s，能够很好的运行在物联网设施或者边缘计算设施下面 据rke2官网文档形容说该部署是继承了k3s的可用性、易操作性和部署模式，继承了与上游 Kubernetes 的严密一致性，在一些中央，K3s 与上游的 Kubernetes 有一致(k3s魔改了一些k8s组件)，以便为边缘部署进行优化，rke2同时也预设了平安配置，合乎各项平安测试标准，然而部署形式上比k3s更简单一些 整体来看抉择k3s和rke2都是能够用于生产环境的抉择，如果更重视安全性，能够抉择rke2 硬件资源3台Ubuntu服务器，零碎版本22.04，二核4G IP是192.168.100.136（治理节点）,192.168.100.137(agent节点),192.168.100.138(agent节点) 3台机器能够互相ping通 执行命令过程当中须要sudo权限或者切换为root用户 治理节点配置节点IP是192.168.100.136 获取rke2安装程序 $ curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/rke2/install.sh | INSTALL_RKE2_MIRROR=cn sh -创立自定义配置文件 $ mkdir -p /etc/rancher/rke2$ vim /etc/rancher/rke2/config.yaml写入内容如下 自定义一个token配置节点名，该名称是全局惟一的，用于dns路由TLS证书上增加额定的主机名或IPv4/IPv6地址作为备用名称，此处填写本机IP配置国内镜像token: demo-servernode-name: demo-server-nodetls-san: 192.168.100.136system-default-registry: "registry.cn-hangzhou.aliyuncs.com"启动服务（rke2-server是采纳systemd治理，确保节点重启后或过程解体或被杀时主动重启） $ systemctl start rke2-server$ systemctl enable rke2-server查看装置的二进制执行文件，rke2默认是装置到/var/lib/rancher/rke2/bin/门路上面，然而该门路是不被$PATH所蕴含的 $ ll /var/lib/rancher/rke2/bin/total 300396drwxr-xr-x 2 root root 4096 Oct 8 08:41 ./drwxr-xr-x 4 root root 4096 Oct 8 08:41 ../-rwxr-xr-x 1 root root 57352072 Oct 8 08:41 containerd*-rwxr-xr-x 1 root root 7381616 Oct 8 08:41 containerd-shim*-rwxr-xr-x 1 root root 11606088 Oct 8 08:41 containerd-shim-runc-v1*-rwxr-xr-x 1 root root 11626984 Oct 8 08:41 containerd-shim-runc-v2*-rwxr-xr-x 1 root root 24838144 Oct 8 08:41 crictl*-rwxr-xr-x 1 root root 20586248 Oct 8 08:41 ctr*-rwxr-xr-x 1 root root 48570656 Oct 8 08:41 kubectl*-rwxr-xr-x 1 root root 114644328 Oct 8 08:41 kubelet*-rwxr-xr-x 1 root root 10973592 Oct 8 08:41 runc*批改全局PATH ...

作者王海龙，SUSE Rancher 中国社区技术经理，Linux Foundation APAC Evangelist，负责 Rancher 中国技术社区的保护和经营。领有 8 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。 本文整顿自王海龙在 SUSECON 北京 2022 开源技术峰会上的主题演讲。 本文次要介绍如何通过 Kubernetes 在边缘设施上部署和治理操作系统，而后将这些边缘设备组建成一个 Kubernetes 集群，最初对立接入到 Rancher 中进行治理。 云原生技术的根底定义 云原生置信大家曾经十分理解了，上图是 CNCF 对云原生的定义，也列出了云原生的代表技术，其中容器、服务网格、微服务、申明式 API 这些技术，置信大家都曾经十分相熟。 其中一项叫不可变基础设施，这个概念并不常见，用起来和咱们传统形式有些抵触，有时候大家可能会感觉顺当，咱们就从不可变基础设施谈起。 Mutable vs Immutable 先来比照一下可变和不可变，也就是 Mutable 和 Immutable。 从基础设施角度来看，Mutable 更偏向于咱们传统的运维视角，其实就是一个 update in-place，即在原地更新这样的理念，比方：您原来的主机上安装了 apache2，下面部署了业务，想换成 nginx，须要先卸载掉 apache2 服务，而后再重新安装一个 nginx，可能也须要重启服务或者零碎来让这次变更失效。这个过程，您的基础设施为了满足业务需要，进行了一次或者屡次变更，实际上它就是一个可变的基础设施。 Immutable 的核心思想是任何基础设施的实例一旦创立之后变成为只读状态，如需批改和降级，则应用新的实例进行替换。如果您有新的变更需要，就应该去筹备（provision）一个新的基础设施，而不是说在原来的根底上做一个本地的更新。 最大的区别，就是原来的 Mutable 人工干预的比拟多，须要靠人工去操作系统里进行各种更改。Immutable 的话，更偏差自动化，您曾经事后把基础设施及其依赖都定义好了，这时只须要去触发新的变更就能够实现变更。这里并不波及到去更改原始的基础设施，这对于基础设施来说，就变成不可变的了。 介绍完这两种理念，大家应该立即想到了容器技术。您能够构建一个镜像，而后在镜像的根底下来部署业务。如果呈现问题，咱们不会去容器里去做变更，而是从容器构建阶段去解决问题。所以从容器的角度，镜像就是一个不可变的基础设施。容器技术呈现后，Immutable 就变得十分直观，也呈现了相似 OCI Image 这样的标准。 Immutable 不只存在于容器畛域，也逐步下沉到了操作系统的层面，Immutable OS 也借助 Container 的理念，造成了许多 Container OS，比方：RancherOS，K3os，CoreOS。这些 OS 的理念，都是从这个角度衍生进去的。 ...

k8s kubeedge装置metrics-server监控节点cpu内存应用状况官网装置地址: https://kubeedge.io/en/docs/a... k8s的master节点上装置metrics-server#在k8s的master节点上执行#创立目录mkdir metrics-server #下载deploy文件wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.0/components.yaml -O deploy.yaml#批改配置如下,能够参考官网的配置vim deploy.yaml spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/master operator: Exists tolerations: - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule hostNetwork: true containers: - args: - --kubelet-insecure-tls - --cert-dir=/tmp - --secure-port=4443#deploy里的镜像须要翻墙下载docker pull k8s.gcr.io/metrics-server/metrics-server:v0.4.0#我先本地翻墙,把镜像下载下来而后导过来的docker save -o metrics-server-image.tar k8s.gcr.io/metrics-server/metrics-server:v0.4.0docker load -i metrics-server-image.tar #大家能够在docker hub下载我推上去的镜像docker push beyondyinjl/metrics-server:v0.4.0#而后批改镜像名docker tag beyondyinjl/metrics-server:v0.4.0 k8s.gcr.io/metrics-server/metrics-server:v0.4.0#利用kubectl apply -f deploy.yaml#过一会,等启动胜利后,应用命令查看内存CPU状况kubectl top node#回显如下:NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% edge-node-1 2100m 52% 1579Mi 42% k8s-master 1404m 35% 12325Mi 78% ...

Pod 的 DNS 策略有如下几个： Default: Pod 从运行所在的节点继承名称解析配置。ClusterFirst: 与配置的集群域后缀不匹配的任何 DNS 查问（例如 "www.kubernetes.io"） 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额定的存根域和上游 DNS 服务器。ClusterFirstWithHostNet：对于以 hostNetwork 形式运行的 Pod，应显式设置其 DNS 策略 "ClusterFirstWithHostNet"。None: 此设置容许 Pod 疏忽 Kubernetes 环境中的 DNS 设置。Pod 会应用其 dnsConfig 字段 所提供的 DNS 设置。留神，这里有个坑可能会搞错： 乍一看大家可能都容易认为 Default 是默认值。然而这里 `Default 不是默认值`！！！`默认值是 ClusterFirst` ！！！即 如果未明确指定 dnsPolicy，则应用 "ClusterFirst"。对于这一点的阐明能够参照官网：https://kubernetes.io/zh-cn/d... 如果胆怯记错，也能够这么去了解： 通常来说对于默认配置，个别不须要应用显示应用“Default”字样来注明，而是应用一个“见文知意”词而后阐明它就是默认配置并且实现了怎么的默认性能即可。而一旦显示应用“Default”字样，就要特地小心它可能不是咱们下意识认为的“默认配置”。同时，针对 dnsPolicy 的 default 策略该怎么了解记忆呢？也简略。设置为 default，就阐明 Pod 不具备明确的 DNS 配置。没有那咋办呢？继承呗！咋继承？子承父业呗！即 `Pod 运行在哪个宿主机上，就应用哪个宿主机的 DNS 来实现解析`。

最近因为工作须要，须要找一个功能完善的云原生利用平台，通过本人筛选和敌人举荐，剩下 KubeSphere和Rainbond ，这两个产品都是基于 Kubernetes 之上构建的云原生利用平台，性能都十分弱小，但产品定位和性能偏重不同，本文将介绍我在选型过程中从各维度比照两款产品的过程记录。 产品定位比照KubeSphere 是在 Kubernetes 之上构建的面向云原生利用的分布式操作系统，齐全开源，反对多云与多集群治理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。作为全栈的多租户容器平台，KubeSphere 提供了运维敌对的向导式操作界面，帮忙企业疾速构建一个弱小和功能丰富的容器云平台。KubeSphere 为用户提供构建企业级 Kubernetes 环境所需的多项性能，例如多云与多集群治理、Kubernetes 资源管理、DevOps、利用生命周期治理、微服务治理（服务网格）、日志查问与收集、服务与网络、多租户治理、监控告警、事件与审计查问、存储管理、拜访权限管制、GPU 反对、网络策略、镜像仓库治理以及平安治理等。 Rainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，反对治理多个Kubernetes集群，和治理企业应用全生命周期。次要性能包含利用开发环境、利用市场、微服务架构、利用交付、利用运维、利用级多云治理等。Rainbond 遵循 以利用为核心的设计理念，对立封装容器、Kubernetes和底层基础设施相干技术，让使用者专一于业务自身, 防止在业务以外技术上破费大量学习和治理精力。 KubeSphereRainbondSlogan面向云原生利用的混合云平台云原生多云利用治理平台形象容器和K8s概念和形象为主，利用级形象为辅利用级形象定位面向懂K8s相干技术的运维和开发面向所有运维和开发，平台治理须要懂K8s因为产品形象不同，体现进去的概念和流程也有很大差别，KubeSphere次要是Kubernetes相干概念和形象，应用和治理都须要懂Kubernetes相干体系常识，懂Kubernetes的人能疾速上手，Rainbond利用级形象，应用门槛很低，面向不懂Kubernetes的一般开发人员，平台治理跟KubeSphere一样都须要懂Kubernetes。 开源社区活跃度比照 KubeSphereRainbond社区活跃度论坛、微信群都沉闷微信 钉钉沉闷Stars110033451文档成熟度很全面很全面版本迭代近一年迭代了4个版本近一年迭代了8个版本开源100% 开源100% 开源KubeSphere 社区更加沉闷些，毕竟是万星开源我的项目，用户遍布国内外。Rainbond 社区用户根本都是国内用户，Star上差了些不过Github、社区群也蛮沉闷的。 装置体验比照KubeSphere 反对通过一条命令在 Linux 上疾速装置 KubeSphere。 ./kk create cluster --with-kubernetes v1.22.10 --with-kubesphere v3.3.0 Rainbond 反对通过一条命令在 Mac、Win、Linux 上疾速装置 Rainbond。 docker run --privileged -d -p 7070:7070 -p 80:80 -p 6060:6060 rainbond/rainbond:v5.8.1-dind-allinone KubeSphereRainbondDocker Desktop and ARM不反对反对Linux反对反对Kubernetes反对反对私有云、托管Kubernetes反对反对装置后组件数量启动所有可拔插组件后 Pod 大略 55 个左右大略 15 个 PodKubeSphere和Rainbond装置都很简略。 KubeSphere 自研的 KubeKey 装置工具，在服务上装置 K8s 和 KubeSphere 很不便。KubeSphere 的可拔插组件这个设计还蛮好的，Allinone装置之后有 5 个 Pod 左右，能满足根本运行需要，须要其余性能就通过可拔插开启，开启所有组件后 Pod 大略 60 个左右。Rainbond 能反对在 Mac M1 Docker Desktop 上装置，这个装置体验还蛮好的能够在本地开发，Rainbond 启动后 Pod 大略15个左右，内存占用1G 左右。 ...

开发人员与运维人员是 IT 畛域很重要的两大人群，他们都会参加到各种业务零碎的建设过程中去。DevOps 是近年间火爆起来的一种新理念，这种理念被很多人谬误的解读为“由开发人员（Dev）学习一大堆新的技能，从而把握运维人员（Ops）该解决的事件”。然而能力越大，责任越大，当维持生产环境稳固为要位的运维责任落到开发人员的肩头时，少数程序员收回了 扯淡的DevOps，咱们开发者基本不想做运维! 的吆喝。那么在云原生时代，到底应该怎么达成 DevOps 的体验呢？我的观点是由平台工程来连接这两大人群，各自做好各自畛域的事件。令人“讨厌”的DevOps首先，我十分心愿你能先看一看引言中提到的 扯淡的DevOps，咱们开发者基本不想做运维! 这篇文章。这篇文章从亚马逊云科技社区参加负责人 Emily Freeman 的一条推特动手，察看了很多留言后，得出了文章题目这种相似怒吼个别的论断。从绝大多数回复这条推特的 IT 从业者的口中，我听到了对于将运维职责强加给开发人员这种 DevOps 体验疾恶如仇。 开发人员对于 “谁构建，谁运行” 这种正气凛然的话示意无感，对于学习运维畛域的新技能，亦或是将本人退出轮班反对人员的行列都感觉力不从心；运维人员的本职工作被剥离之后，则对本业余的前景惶惶不安，会胆怯运维团队的从新洗牌。 开发与运维，的的确确是两个不同的工种，有着相似“车床工与管道工”的区别。 开发人员运维人员专业技能开发语言、开发框架、中间件、数据库硬件、操作系统、网络、存储、虚拟化日常工作了解需要、开发文档写作、开发代码装置部署、监控、日志、问题排查、变更文化标签自在、发明激进、责任一些公司认为从表格中把大量的运维人员管辖的工作，一股脑的“左移”给开发人员就是 DevOps。在专业技能和日常工作畛域带来的缺口，能够通过开发人员的勤奋学习加以补足，然而在文化标签畛域的抵触，将会是导致开发人员讨厌这种 DevOps 体验的根本原因。 DevOps 的真意与平台工程在我看来，DevOps 的真意是利用软件工程思维，解决简单且沉重的运维问题。真正适宜做 DevOps 工作的人，是具备肯定软件工程能力的运维专家，在这里，对运维能力的要求更重要。 DevOps 工程师，能够通过设计或抉择一款平台产品，来将简单的运维工作形象为产品化的运维特色。从这个角度上讲，开发人员将会是这个平台产品的用户，他们可能在不理解简单基础设施的状况下，操作并保护应用程序。DevOps 工程师，应该是更懂开发人员需要的运维工程师。 在追根溯源，找到了这条推特之后，我理解到了更多 IT 业内人士对 DevOps 的认识，从中找到了很多和我有共鸣的声音。 To me that's a sign we haven't made ops intuitive/easy enough for most devs to be able to handle it. 对我来说，这表明咱们还没有让运维变得足够直观/简略，以至于大多数开发人员都无奈解决它。 —— @Liz Fong-Jones (方禮真) The "platform" should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform. Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform. ...

Kubernetes产生背景一个利用运行所须要依赖的环境资源 CPU 执行具体的指令内存 保留执行代码和长期变量磁盘 保留利用须要读取和写入的文件网卡 传输网络数据供给用拜访内部资源或被拜访...利用部署 过来形式: 部署在一台机器上，以一个过程的形式运行古代形式: 一个应用服务会用多个实例去撑持，以实现流量均摊和高可用云原生时代: 主动依据流量拜访和机器资源 治理应用服务 多实例载要解决的问题 资源调度, 即一个利用要部署在一群机器外面的那些机器上依据机器的残余资源来调度, 即CPU 内存 利用拜访规定 域名 域名转发规定外围定义一个用来治理 跨机器的容器化的利用，提供利用部署、运维、扩大等性能的开源零碎容器化利用能够了解为一个镜像，蕴含应用服务自身和其依赖的环境资源，跨机器部署时可无需再反复下依赖的过程基于容器化技术，k8s主动对应用服务进行 扩、缩容以实现 资源服务 的 最大化 治理调度根本架构 master 零碎的大脑外围服务: Kube-APIServer，Kube-Scheduler，Kube-Controller-ManagerKube-APIServer次要提供了 Kubernetes 零碎对外的接口，接口的模式是基于 HTTP 协定的。因为大部分状况下，咱们会在部署 Kubernetes 的时候采纳 HTTPS 的部署形式，所以这个接口真正应用的时候所采纳的就是 HTTPS 协定。咱们整个课程的大部分内容都是间接和这个服务进行交互。通过 Kubernetes 的 Go SDK 向这个服务发送申请进行资源的操作Kube-Scheduler如果说 Master 所在的机器是从内部看 Kubernetes 时的大脑，那么 Scheduler 服务就是从外部看 Kubernetes 时的大脑。咱们刚刚说到的对于利用部署相干的细节都是由 Scheduler 服务来思考的。例如：对于利用 CPU 和内存资源的需要来说，Scheduler 须要综合考量整体可用 CPU 和内存资源的状况以决定将利用部署到哪些 Nodes 下面；或者是对于软件或者硬件层面的策略限度的考量（比方某些利用须要 GPU 资源）；另外还有一些诸如 CPU 亲和性相干的考量等等Kube-Controller-Manager刚刚说过，当咱们深刻到 Kubernetes 架构外部看时，Scheduler 服务是整个 Kubernetes 的大脑，那么 Controller-Manager 就是具体的执行者。这个 Controller-Manager 是一组 Controller 的汇合。这些 Controller 的次要工作是让 Kubernetes 的零碎状态达到冀望的零碎状态。所谓冀望的零碎状态，举个例子如冀望的利用所需的 CPU 配额和限额或者是实例部署的数量等等。当你发送 API 申请去创立、批改、删除利用资源的时候，所做的操作就是设置一个利用部署的期望值。而这些 Controller 就是一直地查看这些部署的实时状态让零碎达到利用所冀望的状态。在目前的 Kubernetes 的版本中，这组 Controller 别离为 Replication Controller，Endpoints Controller，Namespace Controller 和 ServiceAccount Controller。别离负责：利用数量的扩容和伸缩；集群服务和后端利用所在 Pod 之间的动静关系的保护；命名空间的治理和 ServiceAccount 的治理Nodes ...

作者：Vishal Ghariwala，SUSE 亚太及大中华区 CTO现在，在边缘环境部署成千盈百互联设施曾经不再离奇。在工厂和工程设施中，自从微芯片问世以来，PLC 就接管了工业设施的监控工作，并且始终在简化相应的工作流程。而今的不同在于，网络节点的形成以及其中包容的互联设施数量始终在疾速变动。 无论您是否违心承受，元宇宙和 Web 3.0 将在将来数年内走进咱们的生存。在 Web 2.0 时代，用户能够通过键盘/触控板、耳机和网络/手机摄像头彼此交互，而 Web 3.0 将为咱们出现全新的交互维度，比方提供一些去中心化的虚构 3D 世界和体验。一些新的设施也将应运而生，比方能在元宇宙世界里取得物体实在触感的触觉手套。依靠边缘设施和应用程序，这些都将成为可能。 依照现在的发展趋势，配置成千上万设施的边缘环境将变得无处不在。随之而来的新问题是，如何平安、稳固、间断地治理和运行这些设施？毕竟谁也不愿看到触觉手套在元宇宙呈现错乱，或者主动驾驶汽车传感器被恶意软件攻陷。 边缘运行零碎随着联网设施数量的减少，相干的治理和平安防护将成为管理人员的重中之重。对于具备不可变个性的 Linux 操作系统——甚至是一些生产电子产品，很多人赞成将零碎和应用程序的部署空间彼此隔离。而对于小规模边缘设施，相似的部署策略则需借助容器化架构来实现。操作系统须要在速度、安全性和不可变性方面进行优化，并为可互操作且部署平台彼此独立的边缘设施和应用程序提供良好的根底环境。 SUSE Linux Enterprise Micro (SLE Micro) 正是这样一款为边缘环境中的容器化工作负载量身打造的轻量级操作系统。它安全可靠、无需保护，可能使更新、回滚和还原等简略而重要的边缘设施治理工作实现自动化运行；它占用的资源很少，能够确保设施电池续航更长时间。开发人员也可能基于 SLE Micro 疾速实现测试和编程，构建涵盖可穿戴设施、智慧城市、交通运输等泛滥畛域的各类应用程序。 边缘计算边缘设施和应用程序将生成大量须要实时处理和剖析的数据，以便为最终用户提供现实的体验。例如，现场工程师能够借助数字孪生虚拟化技术实现近程监控，能够通过加强事实眼镜采集传感器数据，并以数据流的模式传回总部，获取实时的近程批示。 对于这类状况，咱们须要将边缘计算资源部署在更凑近现场的地位（例如去中心化的 3D 世界），以满足升高提早的需要。边缘基础设施也须要具备灵活性、可靠性和容错能力。Kubernetes 是一项十分实用的技术，它领有杰出的可扩展性和自我修复能力。作为一款安全可靠的轻量级 Kubernetes 解决方案，通过多项规范认证的 SUSE Edge 堪称边缘地位的现实抉择 。 边缘代码平安防护对于无意进军元宇宙的软件，其开发人员的一项要务就是确保代码能在边缘设施和计算基础设施上平安运行。为此，必须继续扫描代码中的破绽，监控实时流量中的可疑行为，爱护敏感数据，并建设自动化的平安防护策略。SUSE NeuVector 正是一款具备上述所有性能的网络安全平台，可在从开发到质量保证 (QA)、再到投入生产环境运行的各个阶段为边缘应用程序提供全方位的爱护。 边缘计算与元宇宙相辅相成。它们彼此成就、相互支持，独特为咱们出现有数令人叹为观止的全新可能。低提早、自动化保护、无间断运行和安全性等要害层面的用户体验可为用户业务胜利和全面推广提供牢靠的反对。咱们须要采取新策略来部署数据中心，对软件进行保护、治理和平安防护。以 SUSE 为代表的技术合作伙伴提供的翻新开源解决方案可能充沛满足这些方面的边缘计算需要。深刻理解 SUSE 边缘计算解决方案，请下载《SUSE云原生边缘计算指南》。

k8s 提供了 top 命令可用于统计资源应用状况，它蕴含有 node 和 pod 两个⼦命令，别离显⽰ node 节点和 Pod 对象的资源使⽤信息。 kubectl top 命令依赖于 metrics 接口。k8s 零碎默认未装置该接口，须要独自部署： [[email protected] k8s-install]# kubectl top poderror: Metrics API not available装置过程一、下载部署文件下载 metrics 接口的部署文件 metrics-server-components.yaml [[email protected] k8s-install]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml--2022-10-11 00:13:01-- https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml正在解析主机 github.com (github.com)... 20.205.243.166正在连接 github.com (github.com)|20.205.243.166|:443... 已连贯。已收回 HTTP 申请，正在期待回应... 302 Found地位：https://github.com/kubernetes-sigs/metrics-server/releases/download/metrics-server-helm-chart-3.8.2/components.yaml [追随至新的 URL]--2022-10-11 00:13:01-- https://github.com/kubernetes-sigs/metrics-server/releases/download/metrics-server-helm-chart-3.8.2/components.yaml再次应用存在的到 github.com:443 的连贯。已收回 HTTP 申请，正在期待回应... 302 Found地位：https://objects.githubusercontent.com/github-production-release-asset-2e65be/92132038/d85e100a-2404-4c5e-b6a9-f3814ad4e6e5?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221010%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221010T161303Z&X-Amz-Expires=300&X-Amz-Signature=efa1ff5dd16b6cd86b6186adb3b4c72afed8197bdf08e2bffcd71b9118137831&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=92132038&response-content-disposition=attachment%3B%20filename%3Dcomponents.yaml&response-content-type=application%2Foctet-stream [追随至新的 URL]--2022-10-11 00:13:02-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/92132038/d85e100a-2404-4c5e-b6a9-f3814ad4e6e5?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20221010%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221010T161303Z&X-Amz-Expires=300&X-Amz-Signature=efa1ff5dd16b6cd86b6186adb3b4c72afed8197bdf08e2bffcd71b9118137831&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=92132038&response-content-disposition=attachment%3B%20filename%3Dcomponents.yaml&response-content-type=application%2Foctet-stream正在解析主机 objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.109.133, 185.199.111.133, 185.199.108.133, ...正在连接 objects.githubusercontent.com (objects.githubusercontent.com)|185.199.109.133|:443... 已连贯。已收回 HTTP 申请，正在期待回应... 200 OK长度：4181 (4.1K) [application/octet-stream]正在保留至: “metrics-server-components.yaml”100%[============================================================================================================================>] 4,181 --.-K/s 用时 0.01s 2022-10-11 00:13:10 (385 KB/s) - 已保留 “metrics-server-components.yaml” [4181/4181])二、批改镜像地址将部署文件中镜像地址批改为国内的地址。大略在部署文件的第 140 行。 ...

1. 问题形容应用 kubeadm 部署 k8s 集群的时候不晓得哪个步骤出了错，导致 kubelet 10250 端口运行的协定、地址出了问题，如下所示： [[email protected] ~]# netstat -ntpl | grep 10250 tcp 0 0 127.0.0.1:10250 0.0.0.0:* LISTEN 52577/kubelet查看 kubelet 服务也能看到端口运行在 127.0.0.1 上： [[email protected] ~]# systemctl status kubelet● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/kubelet.service.d └─10-kubeadm.conf, 20-etcd-service-manager.conf Active: active (running) since 二 2022-10-04 15:04:47 CST; 4 days ago Docs: https://kubernetes.io/docs/ Main PID: 52577 (kubelet) Tasks: 16 Memory: 51.4M CGroup: /system.slice/kubelet.service └─52577 /usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --network-plugin=cni --pod-infra-cont...10月 05 08:46:43 k8s-slave2 kubelet[52577]: I1005 08:46:43.352978 52577 topology_manager.go:200] "Topology Admit Handler"10月 05 08:46:43 k8s-slave2 kubelet[52577]: I1005 08:46:43.514029 52577 reconciler.go:221] "operationExecutor.VerifyControllerAttachedVolume started for volume ...10月 05 08:46:44 k8s-slave2 kubelet[52577]: map[string]interface {}{"cniVersion":"0.3.1", "hairpinMode":true, "ipMasq":false, "ipam":map[string]interface {}{"rang...10月 05 11:13:17 k8s-slave2 kubelet[52577]: {"cniVersion":"0.3.1","hairpinMode":true,"ipMasq":false,"ipam":{"ranges":[[{"subnet":"10.244.1.0/24"}]],"routes":[{"ds...10月 05 11:13:17 k8s-slave2 kubelet[52577]: I1005 11:13:17.399294 52577 reconciler.go:221] "operationExecutor.VerifyControllerAttachedVolume started for volume ...10月 05 11:13:17 k8s-slave2 kubelet[52577]: I1005 11:13:17.979964 52577 pod_container_deletor.go:79] "Container not found in pod's containers" contain...d0cda5a59"10月 05 11:13:18 k8s-slave2 kubelet[52577]: map[string]interface {}{"cniVersion":"0.3.1", "hairpinMode":true, "ipMasq":false, "ipam":map[string]interface {}{"rang...10月 07 09:51:53 k8s-slave2 kubelet[52577]: {"cniVersion":"0.3.1","hairpinMode":true,"ipMasq":false,"ipam":{"ranges":[[{"subnet":"10.244.1.0/24"}]],"rou...go:187] fa10月 07 09:51:56 k8s-slave2 kubelet[52577]: E1007 09:51:56.391455 52577 kubelet_node_status.go:460] "Error updating node status, will retry" err="error getting ...10月 07 09:51:57 k8s-slave2 kubelet[52577]: E1007 09:51:57.185843 52577 controller.go:187] failed to update lease, error: Operation cannot be fulfille... try againHint: Some lines were ellipsized, use -l to show in full.而部署失常的集群，kubelet 的 10250 端口运行状况应该是这样的： ...

本文由吴某人 吴某人の博客 公布！本文由吴某人 吴某人の博客 公布！<p>本次测试的所有问题都必须在指定的cluster配置环境中实现。为尽量减少切换，零碎已对问题进行分组，同一cluster内的所有问题将间断显示。</p><img src="https://s2.loli.net/2022/02/17/ecP2IraJRGdDUKz.png" alt="file" /><h2>开启TAB补全</h2><p>做题前先配置k8s主动补齐性能，否则无奈TAB补全命令：</p><ol><li>登陆治理节点</li><li>kubectl --help | grep bash,此步是为了找关键词completion<img src="https://s2.loli.net/2022/02/17/SokKF3NZmrta9QO.png" alt="file" /></li><li>sudo vim /etc/profile</li><li>增加source <(kubectl completion bash)<img src="https://s2.loli.net/2022/02/17/KOgmhyZtC1o2T4P.png" alt="file" />5.保留退出，source /etc/profile</li></ol><h2>1.4% k8s</h2><pre>- 设置配置环境 kubectl config use-context k8s Context 为部署管道创立一个新的 ClusterRole 并将其绑定到范畴为特定 namespace 的特定 ServiceAccount</pre><ul><li>创立一个名字为 deployment-clusterrole 且仅容许创立以下资源类型的新ClusterRole：<ul><li>Deployment</li><li>StatefulSet</li><li>DaemonSet </li></ul></li><li>在现有的 namespace app-team1 中创立有个名为 cicd-token 的新 ServiceAccount。 </li><li>限 于 namespace app-team1 ， 将 新 的 ClusterRole deployment-clusterrole 绑 定 到 新 的 ServiceAccount cicd-token。 </li></ul><h3>解答：</h3><pre>1.kubectl create clusterrole deployment-clusterrole --verb=create --resource=Deployment,StatefulSet,DaemonSet2.kubectl create serviceaccount cicd-token -n app-team13.kubectl create rolebinding xxx(轻易起名字) --clusterrole=deployment-clusterrole --serviceaccount=cicd-token:app-team1 -n app-team1</pre><h2>2.4% ek8s</h2><pre>- 设置配置环境 kubectl config use-context ek8s将名为 ek8s-node-0 (vms25)的 node 设置为不可用，并从新调度该 node 上所有运行的 pods </pre><h3>解答：</h3>kubectl drain vms25.rhce.cc --ignore-daemonsets<img src="https://s2.loli.net/2022/02/17/Ehn6KwV7oDc4Sbs.png" alt="file" /><h2>3.7% mk8s</h2><pre>- 设置配置环境 kubectl config use-context mk8s现有的 kubernetes 集群正在运行的版本是 1.21.0。仅将主节点上的所有 kubernetes 管制立体 和节点组件降级到版本 1.21.1。另外，在主节点上降级 kubelet 和 kubectl。 [start-plane type="4"]确保在降级前 drain 主节点，并在降级后 uncordon 主节点。请不要降级工作节点,etcd,container管理器,CNI 插件,DNS服务或任何其余插件。[/start-plane]--etcd-upgrade=false kubeadm upgrade apply 1.21.1 --etcd-upgrade=false </pre><h3>解答：</h3>1.登陆官网k8s.io，能够右上角更换语言,点击Learn Kubernetes Basics2.搜寻upgrade<img src="https://s2.loli.net/2022/02/17/RtyJhlKGDdg6UqN.png" alt="file" />3.开始降级,步骤官网文档中都有步骤，步骤如下：<pre>kubectl config use-context mk8skubectl get nodesssh vms28(28为mk8s的管制立体节点)sudo su - (需用root用户执行下方命令)</pre>apt-get update && \ apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00 （装置kubeadm包） <pre>kubeadm upgrade apply v1.21.1 –etcd-upgrade=false(题中提醒etcd不被降级，所以加前面的参数)kubectl drain vms28.rhce.cc --ignore-daemonsets (降级kubelet和kubectl前凌空节点，官网文档中流程都有，看着批改就好)</pre>apt-get update && \ apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00（装置kubelet和kubectl包）<pre>systemctl daemon-reloadsystemctl restart kubeletkubectl uncordon vms28.rhce.cc</pre><h2>4.7%</h2><ul><li>此我的项目无需更改配置环境</li><li>首 先 为 运 行 在 https://127.0.0.1:2379 上 的 现 有 etcd 实 例 创 建 快 照 并 将 快 照 保 存 到 /srv/data/etcd-snapshot.db。</li><li>为给定实例创立快照预计能在几秒钟内实现。如果该操作仿佛挂起，则命令可能有问题。用 ctrl+c 来勾销操作，而后重试。</li><li>而后还原位于/srv/data/etcd-snapshot-previous.db 的现有先前快照.</li></ul> 提供了一下 TLS 证书和密钥，以通过 etcdctl 连贯到服务器。 CA 证书：/opt/KUIN00601/ca.crt 客户端证书: /opt/KUIN00601/etcd-client.crt 客户端密钥:/opt/KUIN00601/etcd-client.key <h3>解答：</h3><h4>应用root账户操作</h4>etcdctl –help 查看是否有snapshot命令，有是版本3有为版本2<h4>若是2.则手动导入3</h4>export ETCDCTL_API=3不晓得命令怎么写能够etcdctl snapshot save --help次要三个参数为：-–cacert，--cert，--key,--endpoints<h4>1.保留etcd实例快照：</h4>考试环境：<pre>#etcdctl snapshot save -–cacert=”/opt/KUIN00601/ca.crt” --cert=” /opt/KUIN00601/etcd-client.crt” --key=”/opt/KUIN00601/etcd-client.key” --endpoints="https://127.0.0.1:2379&quot; -- /srv/data/etcd-snapshot.db</pre>练习环境：<pre>#etcdctl snapshot save --endpoints="https://127.0.0.1:2379&quot; /srv/data/etcd-snapshot.db</pre><h4>2.还原快照</h4>考试环境：<pre>#etcdctl snapshot restore –cacert=”/opt/KUIN00601/ca.crt” --cert=” /opt/KUIN00601/etcd-client.crt” --key=”/opt/KUIN00601/etcd-client.key” /srv/data/etcd-snapshot.db</pre>练习环境：<pre>#etcdctl snapshot restore /srv/data/etcd-snapshot.db</pre><h2>5.7% k8s</h2><ul><li>设置配置环境 kubectl config use-context k8s<ul><li>在 internal 命名空间创立一个名为 allow-port-from-namespace 的确保新的 NetworkPolicy 允 许 namespace internal 中的 Pods 来连贯到 namespace big-corp 中的端口 9200。 </li><li>确保新的 NetworkPolicy：</li><li>不容许对没有在监听端口 9200 的 pods 拜访</li><li>不容许不来自 namespace internal 的 pods 的拜访</li></ul></li></ul><h3>解答：</h3>1.先创立题中的命名空间（Namespace）<pre>kubectl configuse-context k8skubectl get namespacekubectl create namespace internalkubectl create namespace big-corpkubectl label namespace big-corp name=big-corp</pre>2.关上官网，搜寻ingress或egress或networkpolicy，而后第一个网络策略<img src="https://s2.loli.net/2022/02/17/AIL8mTv5fEOYZKz.png" alt="file" /><img src="https://s2.loli.net/2022/02/17/cE4WFh3qJL7oQnD.png" alt="file" />3.复制上方yaml代码，新建yaml文件，例如networkpolicy.yaml，名字随便起4.将复制的代码依照题意改为下图所示：<img src="https://s2.loli.net/2022/02/17/eub7g963qHIFJvL.png" alt="file" /><pre>kubectl apply -f networkpolicy.yamlkubectl get networkpolicies.networking.k8s.io -n internal</pre><img src="https://s2.loli.net/2022/02/17/3LiAzDSYZPjbcOU.png" alt="file" /><h2>6.7% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>请重新配置现有的部署 front-end 以及增加名为 http 的端口标准来公开现有容器 nginx 的端 口 80/tcp。 </li><li>创立一个名为 front-end-svc 的新服务，以公开容器端口 http。 配置此服务，以通过在排定的节点上的 NodePort 来公开各个 pods。</li></ul><h3>解答：</h3><pre>kubectl config use-context k8skubectl get deployments.appskubectl edit deployments.apps front-end （edit编辑时只能应用空格，不要TAB否则保留不了）</pre><img src="https://s2.loli.net/2022/02/18/4Xlqp7GiE1NwtyB.png" alt="file" /><pre>ports:name: httpcontainePort: 80protocol: TCP创立front-end-svc服务：kubectl expose –-name=front-end-svc deployment front-end -–port=80 –-target-port=80 –-type=NodePort</pre><h2>7.7% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s</li><li>如下创立一个新的 nginx ingress 资源： </li><li>名称：pong </li><li>namespace： ing-internal </li><li>应用服务端口 5678 在门路/hello 上公开服务 hello </li><li>能够应用一下命令查看服务 hello 的可用性，该命令返回 hello： curl -kL < INTERNAL_IP>/hello/</li></ul><h3>解答：</h3><pre>1.kubectl config use-context k8s2.关上官网文档，搜寻ingress,抉择第一个后果即可，进入后复制yaml模板并新建一个yaml文件3.vim ingress.yaml</pre><img src="https://ae05.alicdn.com/kf/Hf18fccf94ea54a3bad6b9f8612aa5bf7G.png" alt="file" /><pre>4.kubectl apply -f 7-ing.yaml5.kubectl get ing -n ing-internal </pre><h2>8.4% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s</li><li>将 deployment 从 webserver 扩大至 6pods</li></ul><h3>解答：</h3><pre>kubectl config use-context k8skubectl get deploykubectl scale deployment webserver –-replicas=6kubectl get deploy</pre><h2>9.4% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>按如下要求调度一个 pod：</li><li>名称：nginx-kusc00401 </li><li>image: nginx </li><li>Node selector: disk=ssd</li></ul><h3>解答：</h3><pre>kubectl run nginx-kusc00401 --image=nginx --image-pull-policy=IfNotPresent --dry-run=client -o yaml > 9-pod.yaml退出如下标红代码</pre><img src="https://s2.loli.net/2022/02/18/chTHrLpswCZAQV9.png" alt="file" /><pre>kubectl apply -f 9-pod.yamlkubectl get pods</pre><h2>10.4% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s</li><li>查看有多少个 worker nodes 已准备就绪（不包含被打上 Taint: NoSchedule 的节点），并将数 量写入/opt/KUSC00402/kusc00402.txt</li></ul><h3>解答：</h3><pre>Kubectl get nodes查看节点是否有污点kubectl describe nodes vms22.rhce.cc | grep Taintkubectl describe nodes vms23.rhce.cc | grep Taintecho 1 > /opt/KUSC00402/kusc00402.txt</pre><img src="https://s2.loli.net/2022/02/18/UsQowTXqFLBbktD.png" alt="file" /><h2>11.4% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>创立一个名字为kucc4的pod，在pod外面别离为以下每个images独自运行一个app container （可能会有 1-4 个 images)：</li><li>nginx+redis+memcached+consul</li></ul><h3>解答：</h3><pre>kubectl run kucc4 1–image=nginx –1image-pull-policy=IfNotPresent –1dry-run=client -o yaml > 11-pod.yamlvim 11-pod.yaml(将图中标红项复制3次并批改pod名字即可)</pre><img src="https://s2.loli.net/2022/02/18/oH9CVEuO1h6gtZm.png" alt="file" /><pre>kubectl apply -f 11-pod.yamlkubectl get pod</pre><h2>12.4% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>创立名为 app-data 的 persistent volume，容量为 1Gi，拜访模式为 ReadWriteMany。volume 类型为 hostPath，位于/srv/app-data</li></ul><h3>解答：</h3>1.官网文档中搜寻persistent volume，第一个案例即可<img src="https://s2.loli.net/2022/02/18/C3oAlTf9vgiXc5U.png" alt="file" />2.vim 12-pv.yaml,依照题意批改<img src="https://s2.loli.net/2022/02/18/Kh2Pg35SZlJNpaC.png" alt="file" />3.kubectl apply -f 12-pv.yaml4.kubectl get pv<h2>13.7% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s</li><li>创立一个新的 PersistentVolumeClaim：<ul><li>名称：pvvolume </li><li>class：csi-hostpath-sc</li><li>容量：10Mi</li></ul></li><li>创立一个新的 pod，此 pod 将作为 volume 挂载到PersistentVolumeClaim： <ul><li>名称：web-server </li><li>image: nginx </li><li>挂载门路: /usr/share/nginx/html </li><li>配置新的 pod，以对 volume 具备 ReadWriteOnce 权限。 </li><li>最初，应用 kubectl edit 或者 kubectl patch 将 PersistentVolumeClaim 的容量扩大为 70Mi，并 记录此次更改。</li></ul></li></ul><h3>解答：</h3>kubectl config use-context k8s持续在上题中的官网文档中找到下方案例：<img src="https://s2.loli.net/2022/02/18/fQNVU2iEuAIwMgO.png" alt="file" /><h5>vim 13-pvc.yaml,讲案例复制，留神更改标红项，其余项删除（此步目标：创立新的 PersistentVolumeClaim）</h5><img src="https://s2.loli.net/2022/02/18/ZFaf4vGr1QN7o5L.png" alt="file" />kubectl apply -f 13-pvc.yaml持续在上题的官网文档中下滑找到下方案例：<img src="https://s2.loli.net/2022/02/18/NOPu3XYefUvSD8z.png" alt="file" /><h5>vim 13-pvc-pod.yaml,将案例复制（此步目标：创立一个新的 pod，此 pod并挂载到PersistentVolumeClaim）</h5><img src="https://s2.loli.net/2022/02/18/QTiKyeprAfu41na.png" alt="file" />kubectl apply -f 13-pvc-pod.yaml<img src="https://s2.loli.net/2022/02/18/XCK97M1rYeGDLTx.png" alt="file" /><h5>kubectl edit pvc pvvolume –-record，将10Mi改为70Mi（--record目标为记录此次更改，不加--record的话第三小题没有分数）</h5><img src="https://s2.loli.net/2022/02/18/ZNHDVgbmF4fScKW.png" alt="file" /><h2>14.5% k8s √</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>监控 pod foo 的日志并：<ul><li>提取与谬误 unable-to-access-website 绝对应的日志行 </li><li>将这些日志行写入到/opt/KUTR00101/foo</li></ul></li></ul><h3>解答：</h3><pre>$ kubectl config use-context k8s$ kubectl logs foo | grpe unable-to-access-website > /opt/KUTR00101/foo</pre><h2>15.7% k8s</h2><ul><li>设置配置环境 kubectl config use-context k8s<ul><li>在不更改其现有容器的状况下，须要将一个现有的 pod 集成到 kubernetes 的内置日志记录 体系结构中（例如 kubectl logs）。增加 streamimg sidecar 容器是实现此要求的一种好办法。 </li><li>将一个 busybox sidecar 容器增加到现有的 pod legacy-app。新的 sidecar 容器必须运行一下命令：/bin/sh -c tail -n+1 -f /var/log/legacy-app.log </li><li>应用名为 logs 的 volume mount 来让文件/var/log/legacy-app.log 可用于 sidecar 容器。不要更改现有容器。不要批改日志文件的门路，两个容器必须通过/var/log/legacy-app.log 来拜访该文件</li></ul></li></ul><h3>解答：</h3>kubectl config use-context k8skubectl get pod legacy-app -o yaml > 15-pod.yamlvim 15-pod.yaml1.增加pod及vomuleMount挂载点<img src="https://s2.loli.net/2022/02/18/jW4G1a65ZqtNz3B.png" alt="file" />2.增加volumes<img src="https://s2.loli.net/2022/02/18/CyXHYi2WrUGcNJB.png" alt="file" />3.批改挂载目录及名称<img src="https://s2.loli.net/2022/02/18/7wIxAoKgSQV4iqC.png" alt="file" />4.kubectl apply -f 15-pod.yaml5.删除legacy-app，否则再运行yaml时会提醒legacy-app已存在kubectl delete pod legacy-app -–force<img src="https://s2.loli.net/2022/02/18/PfDqCSJ1syaYIp5.png" alt="file" /><h2>16.5% k8s√</h2><ul><li>设置配置环境 kubectl config use-context k8s </li><li>通过 pod label name=cpu-user，找到运行时占用大量 CPU 的 pod，并将占用 CPU 最高的 pod 名称写入到文件/opt/KUTR000401/KUTR00401.txt（已存在）</li></ul><h3>解答：</h3>kubectl top pods -l name=cpu-userecho "占比最高的机器名" > /opt/KUTR000401/KUTR00401.txt<h2>17.13% ek8s</h2><ul><li>设置配置环境 kubectl config use-context ek8s </li><li>名为wk8s-node-0(练习环境应用 vms26.rhce.cc)的 kubernetes worker node 处于 Not Ready状态。考察产生这种状况的起因，并采取相应措施将 node 复原为Ready状态，确保所做的任何更改永恒失效。</li><li>可应用以下命令通过ssh连贯到故障node： <ul><li>ssh wk8s-node-0 （vms26.rhce.cc） </li></ul></li><li>可应用以下命令在该node上获取更高权限：<ul><li>sudo -i</li></ul></li></ul><h3>解答：</h3><pre>kubectl get nodesssh vms26.rhce.ccsudo -isystemctl start kubelet ; systemctl enable kubectlExit退出$kubectl get nodes</pre> ...

运行KubeEdge官网示例_Counter Demo 计数器KubeEdge Counter Demo 计数器是一个伪设施，用户无需任何额定的物理设施即可运行此演示。计数器在边缘侧运行，用户能够从云侧在 Web 中对其进行管制，也能够从云侧在 Web 中取得计数器值,原理图如下: 先装置好kubeedgeLinux装置kubeedge_亲测胜利 kubeedge边缘节点装置 #在k8s-master 上执行,查看节点kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-master Ready master 34h v1.19.2k8s-node-1 Ready agent,edge 79m v1.19.3-kubeedge-v1.5.0云端操作 在k8s-master 上执行#下载示例代码git clone https://github.com/kubeedge/examples.git $GOPATH/src/github.com/kubeedge/examples#应用官网的示例仓库github会比较慢，这里能够应用我的减速仓库git clone https://gitee.com/iot-kubeedge/kubeedge-examples.git $GOPATH/src/github.com/kubeedge/examples#创立 device modelcd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/crds#创立modelkubectl create -f kubeedge-counter-model.yaml#创立devicecd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/crds#依据你的理论状况批改matchExpressions：vim kubeedge-counter-instance.yaml#次要批改的中央- key: 'kubernetes.io/hostname' values: - k8s-node-1 #这里是节点名称#运行yamlkubectl create -f kubeedge-counter-instance.yaml#部署云端利用#云端利用web-controller-app用来管制边缘端的pi-counter-app利用，该程序默认监听的端口号为80，此处批改为8089cd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/web-controller-appvim main.gobeego.Run(":8089")#构建镜像make allmake docker#部署web-controller-appcd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/crdskubectl apply -f kubeedge-web-controller-app.yaml#部署边缘端利用#边缘端的pi-counter-app利用受云端利用管制，次要与mqtt服务器通信，进行简略的计数性能。#批改代码与构建镜像#须要将Makefile中的GOARCH批改为amd64能力运行该容器。默认是arm架构的cd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/counter-mappervim MakefileGOARCH=amd64 go build -o pi-counter-app main.go#构建镜像make allmake docker#部署Pi Counter Appcd $GOPATH/src/github.com/kubeedge/examples/kubeedge-counter-demo/crdskubectl apply -f kubeedge-pi-counter-app.yaml#阐明：为了避免Pod的部署卡在`ContainerCreating`，这里间接通过docker save、scp和docker load命令将镜像公布到边缘端#因为边缘端没有这个镜像,只能手动弄过来,或者先上传到公有镜像仓库, 边缘端配置公有仓库地址,就能够间接从公有仓库下载#这里就手动弄到边缘端docker save -o kubeedge-pi-counter.tar kubeedge/kubeedge-pi-counter:v1.0.0#传到边缘端scp kubeedge-pi-counter.tar [email protected]:/data/#在边缘端执行docker load -i kubeedge-pi-counter.tar#在边缘端查看容器启动日志,有没有报错docker logs -f counter-container-iddocker logs -f 8e2359446752体验demoKubeEdge Demo的云端局部和边缘端的局部都曾经部署结束 ...

删除kubeedge边缘节点和k8s节点_卸载kubeedgeLinux装置kubeedge_亲测胜利 kubeedge边缘节点装置 删除kubeedge边缘节点#k8s的master节点上执行 #查看节点kubectl get node #删除节点名为:edge-node-4kubectl delete node edge-node-4#删除更多节点#k8s-master 节点上执行 移除k8s-node-1 k8s-node-2节点kubectl get nodekubectl drain node k8s-node-1 --delete-local-data --force --ignore-daemonsets kubectl delete node k8s-node-1kubectl drain node k8s-node-2 --delete-local-data --force --ignore-daemonsets kubectl delete node k8s-node-2卸载kubeedge#在边缘节点上执行./keadm reset 按提醒输出: y#或者强制卸载 --force./keadm reset --force#删除相干文件rm -rf /etc/systemd/system/edgecore.servicerm -rf /usr/lib/systemd/system/edgecore.servicerm -rf /etc/kubeedge#进行服务systemctl stop edgecore.servicesystemctl daemon-reloadps aux|grep edgecore卸载k8s节点#在k8s节点上执行kubeadm reset 按提醒输出:y

作者简介吴硕，SUSE Senior Software Development Engineer，已为 Longhorn 我的项目工作近四年，是我的项目 maintainer 之一。本文将介绍 Longhorn 的基本功能和架构，replica 和 backup 这两个最重要的个性以及应用案例，帮忙大家理解 Longhorn 的价值所在以及应用办法。 Longhorn 介绍Longhorn 是一个轻量的、牢靠易用的、为 Kubernetes 设计的分布式存储系统，100% 开源，现已成为 CNCF 孵化我的项目。 Longhorn 作为存储系统，最重要、最根本的性能就是为 Kubernetes 的工作负载提供长久存储，咱们称为 Longhorn volume。它利用集群工作节点自身的存储设备实现存储，这种超聚合的形式是 Longhorn 的设计理念之一，也能够很好地和 SUSE 另外一个我的项目——Harvester 集成。 为了保障高可用性，Longhorn 首先反对跨节点或跨可用区（AZ）的数据复制，即 Replication。如果整个集群或者恰好 volume 的所有 replica 都忽然不可用，就须要将数据进一步备份(backup)到集群内部了。 Longhorn 反对将数据上传到 NFS 或者 S3 compatible 的存储计划。利用内部的备份数据，Longhorn 能够做集群级别的容灾复原。对于数据备份自身，用户不可能每次手动发动申请，所以 Longhorn 反对周期性的 backup 和 snapshot，这个性能个别称为 cron job 或者 recurring job。 对于 Longhorn 降级，咱们的要求是不可能影响用户或者曾经运行的 volume 读写，所以每次 Longhorn 版本升级都是无中断降级。 往年 Longhorn 面向 VM 推出了新性能 backing image。如果用户想要起数十个或者上百个 VM，为每个 VM 独自下载一份截然不同的 SLES 或 Ubuntu 等 image，是十分浪费时间和空间的。在这一场景下，客户只需下载一份 image 作为只读的底层文件，并让所有 VM 共用即可。 ...

Kubernetes 是一个弱小的容器编排平台，用于自动化简单应用程序的部署、治理和扩大。它通常带有kubectl客户端工具，容许用户应用 CLI（命令行界面）与 Kubernetes 集群进行交互。 多年来，kubectl始终与开源社区开发的工具相结合，以改善用户体验。咱们将在这里列出五种与 Kubernetes 一起工作的最弱小和最无效的工具。 要测试以下工具，我建议您应用kind构建一个 Kubernetes 游乐场。这是一种在本地应用集群并在实现后进行清理的简略办法。# install kind brew install kind # create cluster kind create cluster --name playground --image kindest/node:v1.21.141. K9s一个十分有用的终端 UI，K9s相对是我的首选。十分易于应用，直观，它会继续监督集群，并容许您通过命名空间、服务、部署等轻松摸索 pod。单击即可进入 pod、查看日志、形容、编辑或端口转发。我将它与我 kubectl 照常运行的另一个 shell 联合应用，以便我能够从两个接口中取得最大收益。 brew install k9s 2. Popeye用于清理 Kubernetes 集群的黑白工具，Popeye是一个开源工具，可查找任何不统一、生成报告并对集群进行评级。 # Installbrew install derailed/popeye/popeye# Runpopeye 3. Kube-benchKube-bench 是另一个不便的工具，能够查看您的 Kubernetes 集群是否已平安部署。您能够这里找到我的项目存储库。 # Run kube-bench as a job and inspect the logscurl https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml | kubectl apply -f -# get the logs, replace <kube-bench-95cf7> with your pod idkubectl logs kube-bench-95cf7 -f运行后，只需抉择 pod 并查看日志。同样，您能够在解决集群时应用 K9s 疾速察看集群。 ...

背景：最近就想体验各种多集群互联（基于wireguard），而后就深感网络划分的重要性，开始网络设计的杂七乱八的。想互联了都各种问题了，网络重叠了怎么办？集群扩容IP资源不够了杂整？还有就是默认的每个node节点的subset都默认是24？我一台机器下面也跑不了那么多Pod阿......恩 默认的 SUBNET都是24，举个例子：我的kubernetes集群初始化配置文件networking局部如下：节约ip 资源阿 我一台服务器跑不了那么多 200 多个pod........，而且这样算下来除去service的地址，集群只能包容12个工作节点（包含master节点） 对于节点pod ip布局与集群包容更多节点腾讯云tke的例子正好看到腾讯云tke创立集群的时候能够看到能够限度但节点的pod数量上线和service的数量：他们怎么搞的呢？参照：k8s-flannel网络Node下限冲破255 apiVersion: kubeadm.k8s.io/v1beta2kind: ClusterConfigurationetcd: local: dataDir: "/var/lib/etcd"networking: serviceSubnet: "10.96.0.0/16" podSubnet: "10.244.0.0/16" dnsDomain: "cluster.local"kubernetesVersion: "v1.18.0"controlPlaneEndpoint: "11.167.124.4:6443"controllerManager: extraArgs: allocate-node-cidrs: 'true' node-cidr-mask-size: '28'apiServer: extraArgs: authorization-mode: "Node,RBAC" certSANs: - "11.167.124.4" timeoutForControlPlane: 4m0simageRepository: "registry.aliyuncs.com/google_containers"对于controllerManager extraArgs配置： allocate-node-cidrs: 'true' node-cidr-mask-size: '28'参照：https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-Networking我的kubernets初始化配置文件是这样的： apiVersion: kubeadm.k8s.io/v1beta3bootstrapTokens:- groups: - system:bootstrappers:kubeadm:default-node-token token: abcdef.0123456789abcdef ttl: 24h0m0s usages: - signing - authenticationkind: InitConfigurationlocalAPIEndpoint: advertiseAddress: 10.0.2.28 bindPort: 6443nodeRegistration: criSocket: unix:///var/run/containerd/containerd.sock imagePullPolicy: IfNotPresent name: sh-master-01 taints: - effect: NoSchedule key: node-role.kubernetes.io/master---apiServer: timeoutForControlPlane: 4m0sapiVersion: kubeadm.k8s.io/v1beta3certificatesDir: /etc/kubernetes/pkiclusterName: kubernetescontrollerManager: extraArgs: allocate-node-cidrs: 'true' node-cidr-mask-size: '26'dns: {}etcd: local: dataDir: /var/lib/etcdimageRepository: registry.aliyuncs.com/google_containerskind: ClusterConfigurationkubernetesVersion: 1.25.0networking: dnsDomain: cluster.local serviceSubnet: 172.21.12.0/22 podSubnet: 172.21.0.0/20scheduler: {}注：环境基于kubeadm搭建！node-cidr-mask-size: '26' 能够承载多少个地址呢？2^(32-26)-1=2^6-1=63个地址满够用了(其实还应该去除一个flannel.1网卡占用的地址，还有子网地址cni0地址？应该是61个？） ...

K8S Internals 系列第五期容器编排之争在 Kubernetes 一统天下场面造成后，K8S 成为了云原生时代的新一代操作系统。K8S 让所有变得简略了，但本身逐步变得越来越简单。【K8S Internals 系列专栏】围绕 K8S 生态的诸多方面，将由博云容器云研发团队定期分享无关调度、平安、网络、性能、存储、利用场景等热点话题。心愿大家在享受 K8S 带来的高效便当的同时，又能够如庖丁解牛般领略其内核运行机制的魅力。 本文将联合CNCF社区中面向多集群治理的Cluster API我的项目，来和大家谈谈 K8S 集群的治理形式。 1. 为什么抉择Cluster API？Kubernetes曾经成为云原生容器平台的事实标准，越来越多不同行业的企事业单位开始将业务从传统的物理机、虚拟机迁徙过去。利用Kubernetes让利用治理变得既快又稳，同时降低成本。在这个过程中，一个企业外部建设了数量不少的K8S集群，这些集群的部署形式、版本、配置参数、业务部署都不尽相同。能够说，在K8S带来便捷高效的同时，如何治理这些K8S集群也成为了不可疏忽的问题，例如：如何装置部署Kubernetes集群、如何治理多个Kubernetes集群、异构集群如何治理、集群如何降级扩容、集群的配置参数如何标准的变更？一系列灵魂提问成了不少企业的痛楚。 联合CNCF社区中面向多集群治理的Cluster API我的项目，咱们来和大家谈谈社区的解决方案。 Cluster API由Kubernetes特地兴趣小组Cluster Lifecycle发动，旨在提供K8S即服务能力。用Kubernetes的能力治理Kubernetes，用Kubernetes的形式提供Kubernetes集群生命周期治理，并且反对治理集群相干的基础设施（虚拟机、网络、负载均衡器、VPC 等）。通过以上种种形式，让K8S基础设施的生命周期治理也变得十分云原生化。 看到这里，相熟Kubernetes的小伙伴们必定心想：用cluster API我的项目，是不是只用提交一个yaml就好了？没错就是这样。Cluster API提供了申明式的集群治理形式。那么比照之前集群的部署形式又有什么区别呢？以应用Kubernetes的官网部署工具kubeadm为例，请看下图。 应用或部署过Kubernetes集群的小伙伴们晓得，Kubernetes集群依赖于几个组件协同工作能力失常运行，对这些组件的部署往往吓退了很多人，kubeadm的呈现很大水平加重了这一痛楚，并且对集群反复部署的问题也给出了一个很好的答案。不过正如上图所示，简直每一步都须要人工手动操作，部署人员辗转多台服务器之间反复着雷同的操作。同时面对日益增长的集群环境，kubeadm并没有解决如何对本人已部署的集群进行治理。 除此之外还包含以下问题： 如何针对异构集群统一地配置机器、负载均衡器、VPC 等？如何自动化治理集群生命周期，包含降级和集群删除？如何扩大并治理任意数量的集群？Cluster API给出了答案，通过申明式的构建具备Kubernetes格调的API，实现诸如集群主动创立、配置和治理等性能。同时反对您应用不同的基础设施提供商以及疏导程序提供商来构建治理您的集群。 2. Cluster API 架构（图源 Cluster API官方网站） Management ClusterCluster API工作的集群，该集群往往通过kind等工具生成，在该集群上运行着一个或多个基础设施提供程序，并保留着Cluster API相干的CRD资源。是负责管理工作集群生命周期的集群。 Target Cluster工作集群，由治理集群创立并治理其生命周期。 Infrastructure provider基础设施提供商，工作集群基础设施的理论提供者（如 AWS、Azure 和 Google等），由各大厂商实现，但须要遵循Cluster API的标准去实现相应的接口和逻辑。 Control plane provider管制立体提供者，负责Target Cluster管制立体的节点生成，Cluster API 默认应用kubeadm疏导管制立体。对于不同厂商可实现适配本人的管制立体疏导程序。 Bootstrap Provider疏导程序提供者，负责集群证书生成，初始化管制立体，并管制其余节点（管制立体和工作节点）退出集群。Cluster API默认应用基于 kubeadm 的疏导程序。对于不同厂商可实现适配本人的节点疏导程序。 Custom Resources自定义资源，Cluster API 提供并依赖于几个自定义资源：Machine、MachineDeployment、MachineSet、Cluster。作为厂商，在实现本人的provider时该当遵循这些自定义资源标准。 3. Cluster API资源介绍咱们以kubeadm-control-plane-provider（Control plane provider）、kubeadm-bootstrap-provider（bootstrap-provider）以及cluster-api-provider-docker（Infrastructure Provider）组件，资源版本v1beta1为例，梳理一下Cluster API的自定义资源关系图。 ...

本文整顿自 SUSE 平安产品策略副总裁黄飞在 SUSECON 北京 2022 开源技术峰会上的主题演讲。 一直放大的平安“边界”应用软件倒退平台倒退线路很清晰，从最早的物理机倒退到起初的虚拟机，能够运行多个操作系统在物理机上；2014 年开始，以 Docker 为首的容器厂商把容器技术推向公众，也带动了微服务的高速倒退；到明天越来越多的企业客户甚至政府机关，开始在多云环境下部署分布式的集群服务。 从平安角度来看。在物理机时代咱们爱护一些平安的边界，这个边界能够是一个网关，能够是一个笔记本电脑，能够是个台式机，能够是个数据库，咱们在入口地位部署相应的平安性能，基本上能满足平安的需要。 在虚拟机时代，原来基于物理机的平安计划已无奈满足需要，虚拟机的平安技术计划应运而出，包含虚构网络、负载平衡、数据中心的平安、虚拟存储的平安。 微服务的呈现让平安零碎再一次面临新的挑战。具备代表性的是容器网络的扭转。容器网络是在传统的虚构网络上又加了一层虚构的容器网络，等于是网络屡次虚拟化；同时所有原来基于过程之间的通信逐步变成了所谓的服务，服务组件变成了网络上的一个节点。同时微服务节点之间的通信，甚至呈现了 sidecar 这种比拟高级的微服务利用，它的内部通信、外部通信，包含所有的数据服务都变成了一些被虚拟化了的数据服务。 一些新技术层出不穷，比方服务网格技术、多集群之间的通信、多云和混合云的技术、甚至 Serverless，这些都对平安边界提出了越来越多的要求。 我集体认为平安的边界其实是逐步减小的，从原来爱护一个微小的物理机到爱护一个虚拟机，到爱护一个小小的容器，再到爱护一个 serveless function，平安边界越来越小，甚至会逐步消失掉。 云原生环境下的平安挑战 云原生环境下的平安挑战体现在 3 个方面： 容器环境的疾速倒退。容器变动十分快，K8s、Docker 等很多容器的生命周期可能只有几十分钟甚至几分钟工夫，这段时间之内它的版本 1 的容器要不要爱护？怎么爱护？如果依然用传统办法爱护，还没有来得及制订好策略，新版本就迭代下来了。这是一个很大的平安挑战：它太快了！ 传统平安工具无奈适应新的云环境。例如，有的网络防火墙架在端口地位，它无奈了解如果跨集群、跨云，所有的通信曾经加密，在底层网关节点上齐全没有方法无效感知到任何的 contacts，没法无效地爱护它。 另外传统的一些 agent based solution 会在所有节点上装 agent，然而咱们已经也看到有的厂商试图把 agent 装到所有的容器里，这仿佛是能够实现一些平安性能，然而容器作为微服务，装 agent 就与主机没有差异了。这个齐全跟容器倒退、微服务的倒退南辕北辙，从技术角度来看，我认为这是一个谬误的零碎构架。 K8s 大量采纳虚拟化技术，把数据、网络、计算全副虚拟化之后，对应用程序层来讲十分好用。基本上放一个容器下来，不须要关怀底层的构架和平台网络，就全副能够主动跑起来。然而对于平安人员的挑战就是没有可见性，不晓得这个容器到底是不是在做它应该做的事件，即虚拟化技术自身对平安管控造成了肯定的屏障。 基于 CNCF 云原生零碎构架剖析平安性能的构建 CNCF 把云原生零碎分为三大块： 底层根底层，是整个云的根底构架，包含 compute resource、存储、网络、底层的操作系统和编排零碎，底层零碎当初曾经有十分成熟的平安解决方案。应用程序生命周期。当初云原生应用程序基本上从开发到提交代码、到流程管道里会主动进行代码查看、测试、包装，包装成容器而后公布，到最初的安全策略造成，整个一套是全自动化的，这个应用程序的生命周期须要有很强的平安管控。例如所谓的 supply chain，很重要的一块就是管道平安，所有安全检查须要产生在生命周期里，每个环节都要有肯定的性能。运行时的平安。咱们把应用程序和数据生产化了当前，才是真正面对挑战的时候。此时，因为程序曾经在私有云、公有云上跑了，端口曾经关上，这就意味着曾经公布于众。所有好的、坏的连贯就会产生，首先是从网络层面会试图攻打你的端口扫描、网络端口，试着去取得非法受权，试着去攻打整个云环境，试着管制运行时的容器。一旦取得了某些提权之后，就可能有一些非法拜访，比方挖矿。在云环境下，如果没有很好的运行时的监控和阻挡办法，会造成十分重大的损失，这样的例子不可胜数。CNCF 把运行时的环境画的非常复杂，每一层都由非常复杂的模块组成，包含整个云的环境、整个云的配置。各个方面都须要做到安全检查，比如说一些 Access、存储系统的加密、明码权限要切分得十分清晰、云节点之间的安全策略、节点和节点之间的网络安全策略。 在这之上有 workload orchestration，比方 K8s 平台、Rancher 平台，这个平台应用大量的技术和性能。怎么保障你拉下来的镜像是平安的，是通过安全检查的？ 再往上是应用层。云厂商没有方法治理，因为这些利用和服务是你本人开发的，或者是第三方开发的，须要你本人去治理、去运行，它是你整个企业业务最重要的服务工具，它的数据也是企业最重要的资产。云平台被攻克了还能够疾速复原，然而本人的数据被锁死、加密了，损失是十分大的。所以基本上分成这三层来构架。 平安模式的进化——零信赖私有云疾速倒退，大家始终在探讨平安的界线到底在哪里，谁应该负责哪一块的平安。一开始，很多客户认为私有云的平安应该交给供私有云厂商，然而真实情况并非如此。 这是 AWS 对外颁布的 Security Responsibility Model，即私有云厂商只提供根底服务，只保障在它下面的数据全副加密，保障保留好所有平台的日志，以供剖析，然而并不保障你的应用程序和数据安全。 ...

概述官方网站：KubeKey (kubesphere.com.cn) KubeKey（由 Go 语言开发）是一种全新的装置工具，代替了以前应用的基于 ansible 的安装程序。KubeKey 为您提供灵便的装置抉择，您能够仅装置 Kubernetes，也能够同时装置 Kubernetes 和 KubeSphere。 KubeSphere 是 GitHub上的一个开源我的项目，是成千上万名社区用户的聚集地。很多用户都在应用 KubeSphere 运行工作负载。对于在 Linux 上的装置，KubeSphere 既能够部署在云端，也能够部署在本地环境中，例如 AWS EC2、Azure VM 和裸机等。 KubeKey 的几种应用场景： 仅装置 Kubernetes；应用一个命令同时装置 Kubernetes 和 KubeSphere；扩缩集群；降级集群；装置 Kubernetes 相干的插件（Chart 或 YAML）。咱们利用其装置Kubernetes 装置步骤下载KubeKey运行以下命令，以确保您从正确的区域下载 KubeKey。 export KKZONE=cn 运行以下命令来下载 KubeKey： curl -sfL https://get-kk.kubesphere.io | VERSION=v2.2.2 sh - KubeKey 的最新版本 (v2.2.2)，能够更改命令中的版本号来下载特定的版本 筹备Linux 主机零碎要求 零碎最低要求（每个节点）Ubuntu 16.04，18.04，20.04， 22.04CPU：2 核，内存：4 G，硬盘：40 GDebian Buster，StretchCPU：2 核，内存：4 G，硬盘：40 GCentOS 7.xCPU：2 核，内存：4 G，硬盘：40 GRed Hat Enterprise Linux 7CPU：2 核，内存：4 G，硬盘：40 GSUSE Linux Enterprise Server 15 /openSUSE Leap 15.2CPU：2 核，内存：4 G，硬盘：40 G节点要求 ...

Mac下golang装置MacBook Linux 树莓派raspberrypi装置Golang环境 留神:版本应用 go1.12.14go versiongo version go1.12.14 darwin/amd64Mac下kubeedge装置获取KubeEdge的形式有两种，一种是间接从 官网(https://github.com/kubeedge/k...) 中下载（本试验版本为kubeedge-v1.1.0.tar.gz）；另一种办法是通过源码编译失去。 Kubeedge官网没有提供MacBook的安装包, 这里介绍一下源码编译的办法 #下载源代码git clone https://github.com/kubeedge/kubeedge.git $GOPATH/src/github.com/kubeedge/kubeedge#检测gcc是否装置, 如果没有，则自行装置。gcc --version#在编译的时候遇到了第一个坑，就是版本的问题。因为最新clone下来的版本曾经不是v1.1.0了，所以，咱们须要把代码切回到v1.1.0版本#切换对应版本git taggit checkout v1.1.0 编译kubeedge云端cd $GOPATH/src/github.com/kubeedge/kubeedge/make all WHAT=cloudcore#生成二进制 cloudcore 文件位于 cloud 目录。拷贝 cloudcore 和同一目录的配置文件（conf目录）到部署工程目录：cp -a cloud/cloudcore $GOPATH/cloud/cp -a cloud/conf/ $GOPATH/cloud/cp -a cloud/cloudcore ../../../kubeedgecloud cp -a cloud/conf ../../../kubeedgecloud 编译kubeedge边缘端cd $GOPATH/src/github.com/kubeedge/kubeedge/make all WHAT=edgecore#报错pkg/edged/edged.go:92:2: build constraints exclude all Go files in /Users/liang/ideaWorkspace/go/src/github.com/kubeedge/kubeedge/edge/pkg/edged/cadvisormake[1]: *** [edgecore] Error 1make: *** [all] Error 2#找到这个文件关上/Users/liang/ideaWorkspace/go/src/github.com/kubeedge/kubeedge/edge/pkg/edged/cadvisor// +build cgo,linux#这是go的条件编译导致的,具体的办法是在go文件的第一行正文写 // +build linux 表明这个文件在linux平台能力编译.#参考看https://segmentfault.com/q/1010000022152781https://www.gitdig.com/post/2019-07-08-go-comment/论断: Mac下编译不反对,只能换虚拟机linux搞,下个博客介绍Linux下编译 ...

作者：Adam Bergh, Solutions Architect, Cloud Native Technical Partnerships, Kasten by Veeam Terry Smith, Global Partner Solutions Director, SUSE Gerson Guevara, IHV Solutions Architect, SUSE 1.简介1.1 用处当初，企业在逐步向云原生转移（例如应用容器化工作负载和 SUSE Rancher 等 Kubernetes 治理平台）。企业的指标是进步灵活性、规模和弹性，来减速翻新并疾速适应动静条件。在这种永远在线的 IT 环境中，应用程序的可移植性和数据保护就非常要害。 Kasten K10 by Veeam® 数据管理平台为企业经营团队提供了一个易于应用、可扩大且平安的零碎，用于云原生应用程序的备份和复原、劫难复原和迁徙。 1.2 范畴本指南概述了在 SUSE Rancher Kubernetes 环境中装置和设置 Kasten K10 by Veeam，以及执行应用程序的简略备份和复原的步骤。 1.3 受众本文档实用于 IT 经营团队、备份管理员、DevOps 和 DevSecOps 团队，以及负责云原生环境的业务连续性、劫难复原、勒索软件和威逼管制以及应用程序迁徙的其余人员。 2.技术概述Kasten K10 by Veeam® 数据管理平台与 SUSE Rancher 深度集成，并提供了跨 Kubernetes 发行版和云平台的生态系统反对，这为企业经营团队提供了灵便的部署环境选项（本地、私有云和混合云）。K10 是由策略驱动并可扩大的。它提供了很多企业性能，例如全局一致性、数据库集成、主动应用程序发现、多云迁徙和弱小的 Web UI。 ...

先装置好k8s,kubeedge的cloudcore端Linux装置kubeedge_亲测胜利 下载keadm工具官网github下载kubeedge地址 留神:下载对应的版本和架构keadm-v1.6.1-linux-amd64.tar.gz 如果github拜访不了,或者太慢,能够给我留言或评论,我发给大家 边缘节点执行退出kubeedge治理--cloudcore-ipport=192.168.0.123:10000 cloudcore端的IP和端口 --edgenode-name=testing123 边缘节点的名称,不带此参数,默认应用hostname --kubeedge-version=1.6.1 kubeedge的版本,会去下载指定版本的kubeedge包 --token 在cloudcore端应用命令获取:keadm gettoken #解压keadmtar -zxvf keadm-v1.6.1-linux-amd64.tar.gz#退出kubeedge./keadm-v1.6.1-linux-amd64/keadm/keadm join --cloudcore-ipport=192.168.0.123:10000 --cgroupdriver=systemd --edgenode-name=testing123 --kubeedge-version=1.6.1 --token=3ccaxxxxxxxxxxxxx228136.eyJhbxxxxxxxxxxxxGcTB9.fFbUkVvK2GLxxxxxxxxxDYBuu5N7w#须要在线装置mosquitto mqtt要一点工夫, 也能够手动提前去装置,前期会解说install MQTT service successfully.#提醒装置MQTT胜利#而后会去下载kubeedge-v1.6.1-linux-amd64.tar.gz包和checksum校验文件#执行完后#查看mqtt启动状况ps aux|grep mosquitto#查看mqtt版本mosquitto -v#查看mqtt是否开机启动systemctl is-enabled mosquitto#查看edgecore启动状况ps aux|grep edgecore#查看日志journalctl -u edgecore.service -b journalctl -u edgecore.service -f#edge端创立的表相干日志create table `device` -- -------------------------------------------------- -- Table Structure for `github.com/kubeedge/kubeedge/edge/pkg/devicetwin/dtclient.Device` -- -------------------------------------------------- CREATE TABLE IF NOT EXISTS `device` ( `id` varchar(64) NOT NULL PRIMARY KEY, `name` text, `description` text, `state` text,`last_online` text ); create table `device_attr` -- -------------------------------------------------- -- Table Structure for `github.com/kubeedge/kubeedge/edge/pkg/devicetwin/dtclient.DeviceAttr` -- -------------------------------------------------- CREATE TABLE IF NOT EXISTS `device_attr` ( `id` integer NOT NULL PRIMARY KEY AUTOINCREMENT, `deviceid` text, `name` text, `description` text, `value` text, `optional` bool, `attr_type` text, `metadata` text ); create table `device_twin` -- -------------------------------------------------- -- Table Structure for `github.com/kubeedge/kubeedge/edge/pkg/devicetwin/dtclient.DeviceTwin` -- -------------------------------------------------- CREATE TABLE IF NOT EXISTS `device_twin` ( `id` integer NOT NULL PRIMARY KEY AUTOINCREMENT, `deviceid` text, `name` text, `description` text, `expected` text, `actual` text, `expected_meta` text, `actual_meta` text, `expected_version` text, `actual_version` text, `optional` bool, `attr_type` text, `metadata` text ); create table `meta` -- -------------------------------------------------- -- Table Structure for `github.com/kubeedge/kubeedge/edge/pkg/metamanager/dao.Meta` -- -------------------------------------------------- CREATE TABLE IF NOT EXISTS `meta` ( `key` varchar(256) NOT NULL PRIMARY KEY, `type` varchar(32) NOT NULL DEFAULT '' , `value` text ); token过期报错#报错,token曾经过期了testing123 edgecore[2023]: F0510 03:42:38.908203 2023 certmanager.go:91] Error: failed to get edge certificate from the cloudcore, error: Invalid authorization token#重置kubeedgekeadm reset --force#从新获取最新token,而后从新keadm joinsqlite3数据库edge端应用sqlite3数据库 ...

作者：imuxin 灵雀云后端工程师 kubectl-watch：一个能够监听 kubernetes 资源的变更信息的 kubectl 插件。其中变更的内容通过应用 delta 或 difftastic 工具提供丑陋的终端界面展现。应用 delta 概览应用 difftastic 概览装置阐明【举荐】 形式一：应用 Docker 镜像您须要在环境里事后装置好 Docker，参考 官网；或者装置 containerd，参考 装置教程 和 nerdctl 命令行工具。拷贝 script 目录下的 kubectl-watch 脚本到环境的 $PATH 其中的一个目录下，比方 /usr/local/bin。 cp script/kubectl-watch /usr/local/bin/chmod +x /usr/local/bin/kubectl-watch形式二：从 release assets 下载可执行制品。形式三：应用 Cargo进行源码编译装置。cargo install kubectl-watch --lockedCmd 帮忙USAGE: kubectl-watch [OPTIONS] [ARGS]ARGS: <RESOURCE> Support resource 'plural', 'kind' and 'shortname' <NAME> Resource name, optionalOPTIONS: -A, --all If present, list the requested object(s) across all namespaces --diff-tool <DIFF_TOOL> Diff tool to analyze delta changes [default: delta] [possible values: delta, difft] --export <EXPORT> A path, where all watched resources will be strored -h, --help Print help information --include-managed-fields Set ture to show managed fields delta changes -l, --selector <SELECTOR> Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2) -n, --namespace <NAMESPACE> If present, the namespace scope for this CLI request -s, --skip-delta Skip show delta changes view --use-tls Use tls to request api-server -V, --version Print version information参考实例监听所有命名空间下的 deployment 资源 ...

随着企业对软件开发的安全意识进步，开发和运维环节中各个团队也开始将平安嵌入他们正在应用或解决的平台或应用程序架构中。不同于各团队把对平安的关注放在本人所解决的环节，首席信息安全官（CISO）须要把握和负责从基础架构团队到应用程序团队等企业外部的所有平安问题。 浏览本文，将带您理解 CISO 须要思考施行的五项 Kubernetes 安全措施。 牢靠的身份验证解决方案在创立一个 Kubernetes 集群或创立 500 个 Kubernetes 集群的时候，每个 CISO 想到的第一个问题是“工程师和用户将如何对这个 Kubernetes 集群进行身份验证？”。现成可用的解决方案有 RBAC 角色和权限，对用户和零碎组件（如服务帐户）进行身份验证，以容许拜访特定的 Kubernetes 资源。当然这样做可能还不够，企业须要思考一些其余因素，比方 Kubernetes 的 oAuth 和 SSO。 依据企业部署 Kubernetes 的地位，有局部解决方案能够在本地运行，而其余解决方案则须要单另施行。举例来说，Azure Kubernetes Service (AKS) 等基于云的 Kubernetes 服务中，工程师可能取得开箱即用的 Azure Active Directory，从而在整个组织的所有 AKS 集群中启用和施行。Active Directory 是一种久经考验的用户身份验证办法，它能够在 AKS 上运行的所有 Kubernetes 集群中良好利用。 如果应用的 Kubernetes 环境没有像 Active Directory 这样的本机解决方案，能够思考反对 OpenID Connect (OIDC) 的选项。例如，Okta 和 AuthO 曾经集成了可用的 Kubernetes 身份验证解决方案。 施行 Kubernetes 时的平安习惯在首次施行 Kubernetes 时，有很多平安习惯能够帮忙缓解大量平安危险。 第一个是单租户和多租户集群。从 Kubernetes 的角度思考单租户或多租户时，通常会思考有多少用户能够拜访集群以及集群上运行的应用程序的内容。而从用户的角度来看，则更多关注 Kubernetes 集群是不是被设置为只有一个用户可能拜访，也就是说每个用户都能够领有本人的 Kubernetes 集群，从而升高多租户危险。如果须要多租户（很多状况都是如此），那么为用户设置适当的 RBAC 权限至关重要。这样以来，用户就只能拜访他们基于本身角色所须要的内容。 ...

编辑 作者：林静 职务：资深架构师 公司：F5 为何要进行 Egress 流量策略管控 2021 年 CNCF 考察显示，寰球将 kubernetes 用在生产环境的用户占比已达 59.77%，欧洲用户更是达到了 68.98%。用户正越来越多的将生产业务迁徙到 kubernetes 环境下。《Gartner 2021 Hype Cycle for Cloud Security》也显示了容器与 Kubernetes 平安已处在“slope of Enlightenment ”阶段。 这阐明爱护 kubernetes 里的应用服务正变的越来越重要。当咱们去扫视运行在 kubernetes 中的大量微服务时，咱们能够看到微服务平安具备典型的微边界以及须要进行持续性安全工程的特点。 咱们须要以每个微服务为边界进行爱护，无论是其运行时，还是南北和货色流量。须要每个微服务单元在编码之初就开始着手平安思考，进行平安左移，平安的防护设施、办法、策略应与开发者和 kubernetes 平台运维者适配。 还须要有能力洞察所有的流量事件，采集所有运行时日志、事件等数据，通过持续性的安全工程系统对这些数据进行剖析，聚合出规定并反馈到平安的策略设定中。 kubernetes 里的微服务不会只在集群外部关闭运行，它须要拜访集群内部利用、数据库、第三方 API 服务、互联网服务等。出向流量里可能蕴含业务须要的内部拜访，开源组件更新的拜访，甚至可能是被入侵的利用向 C2 连贯的流量。因而，必须对 kubernetes 中的微服务被动外出流量进行管控，确保其平安合规。 在以云原生架构为核心技术驱动的数字化转型下，企业会大量采纳开源技术，而这可能是最容易引入平安危险的中央，无论是否有明确的开源准入机制，企业都应足够器重这些开源产品可能的被动外访服务，将其管控好，确保安全。 治理 kubernetes 中的出向流量策略，看似简略的需要，要想做好却并不是一件容易的事。本文将和您一起剖析 kubernetes 出向策略的挑战，并针对以后常见解决方案的优缺点进行剖析，思考企业应如何做好 kubernetes 出向流量策略管控。 存在的挑战 动静 从技术角度看，这是第一个存在的挑战。在 kubernetes 环境下，微服务单元的 pods 将是高度动静的、扩散的。IP、网段和物理地位将会随时发生变化。因而间接采纳 IP 等特色进行动态化策略设定将是一件不可能的事件。策略必须依赖于其它形象的利用标签、服务名或命名空间等进行，并能做到动静感知变动。 粒度 传统应用环境下，对一个利用出向流量策略的管控一般来说只须要对该利用所波及的大量部署进行策略设定即可。然而在微服务加容器化的环境下，一个利用可能会有许多的微服务组成，而一个微服务又蕴含许多 pods。不同的微服务单元会须要不同的出向策略规定，比方 payment 须要连贯第三方内部接口，而评论服务则不须要被动拜访第三方服务。 这意味着策略设定的粒度须要精密到每个微服务单元，并确保管控了所有相干的 pods。能够看出，策略管控粒度更细、工作量更大、复杂性更高。 协同 当咱们要为不同的微服务单元部署出向策略时候，谁应该为此负责，利用开发部门？利用部署与运维部门？kubernetes 的 platformOps 部门？或是安全部门？咱们以平安左移的思维去对待这件事时，显然利用部门应该思考他的微服务是否须要被动外访，须要拜访哪些内部服务。 然而，如果由利用开发人员负责，是不是平台或安全部门就能够放手不管？显然不是，利用开发人员最多是为其所负责的利用设定安全策略，与利用无关的全局性根底安全策略，如何疾速补救利用开发人员设定的谬误策略，这些仍然须要由其余团队来负责。 而要想开发部门可能践行平安左移的思维，那么 PlatformOps 或安全部门则必须提供敌对的工具并将安全策略的设定集成到 DevSecOps 的 pipeline 当中，如果工具或办法导致开发效率降落，开发人员将不乐意去应用。所以，这不是某一个部门的独立工作，须要多团队的合作来确保安全。 ...

先装置k8slinux装置部署k8s(kubernetes)和解决遇到的坑和解决遇到的坑") 下载kubeedge须要的软件官网github下载kubeedge地址 cloudcore.service文件下载地址 留神:下载对应的版本和架构keadm-v1.5.0-linux-amd64.tar.gz上面的2个文件能够不必下载,装置kubeedge时也会主动去下载到/etc/kubeedge/目录,我这里在线github下载很慢,所以提前下载好kubeedge-v1.6.1-linux-amd64.tar.gzcloudcore.service 如果github拜访不了,或者太慢,能够给我留言或评论,我发给大家 #创立文件夹mkdir /etc/kubeedge/#把下载的软件复制到/etc/kubeedge/目录,能够不下载这2个文件,装置时会主动从github上在线下载到/etc/kubeedge/目录#因为拜访github很慢,我提前下载好cp kubeedge-v1.6.1-linux-amd64.tar.gz /etc/kubeedge/cp cloudcore.service /etc/kubeedge/ 装置kubeedge的cloudcore--advertise-address="192.168.0.123" kubeedge的cloudcore的IP,edge边缘节点能拜访的IP,如果公网拜访,倡议应用外网IP--kubeedge-version=1.6.1 kubeedge的版本,会去下载指定版本的kubeedge包 #解压keadmtar -zxvf keadm-v1.6.1-linux-amd64.tar.gz#初始化装置kubeedge的cloudcore./keadm-v1.6.1-linux-amd64/keadm/keadm init --advertise-address="192.168.0.123" --kubeedge-version=1.6.1#输入如下信息胜利:version=1.6.1Kubernetes version verification passed, KubeEdge installation will start...W0511 14:35:30.146678 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.154102 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.159650 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.164732 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionExpected or Default KubeEdge version 1.6.1 is already downloaded and will checksum for it. kubeedge-v1.6.1-linux-amd64.tar.gz checksum: checksum_kubeedge-v1.6.1-linux-amd64.tar.gz.txt content: Expected or Default KubeEdge version 1.6.1 is already downloaded[Run as service] start to download service file for cloudcore[Run as service] success to download service file for cloudcorekubeedge-v1.6.1-linux-amd64/kubeedge-v1.6.1-linux-amd64/edge/kubeedge-v1.6.1-linux-amd64/edge/edgecorekubeedge-v1.6.1-linux-amd64/cloud/kubeedge-v1.6.1-linux-amd64/cloud/csidriver/kubeedge-v1.6.1-linux-amd64/cloud/csidriver/csidriverkubeedge-v1.6.1-linux-amd64/cloud/admission/kubeedge-v1.6.1-linux-amd64/cloud/admission/admissionkubeedge-v1.6.1-linux-amd64/cloud/cloudcore/kubeedge-v1.6.1-linux-amd64/cloud/cloudcore/cloudcorekubeedge-v1.6.1-linux-amd64/versionKubeEdge cloudcore is running, For logs visit: /var/log/kubeedge/cloudcore.logCloudCore started#查看cloudcore的日志vim /var/log/kubeedge/cloudcore.log配置cloudcore开机自启动服务#查看cloudcore启动状况ps aux|grep cloudcore#输入如下示意启动:root 23498 0.1 0.3 1012544 48640 ? Ssl May12 13:11 /usr/local/bin/cloudcore#查看端口 10000 10002 端口都有了#没有netstat命令,装置:yum install net-tools -ynetstat -tpnl#如下:tcp6 0 0 :::10000 :::* LISTEN 23498/cloudcore tcp6 0 0 :::10002 :::* LISTEN 23498/cloudcore #查看cloudcore启动状态systemctl status cloudcore#如果没有设置开机启动服务则设置 复制开启自启动服务文件cp /etc/kubeedge/cloudcore.service /etc/systemd/system/cloudcore.service#增加文件权限chmod +x /etc/systemd/system/cloudcore.service#从新加载配置文件systemctl daemon-reload#查看cloudcore启动的过程id,而后杀掉ps aux|grep cloudcore#输入如下:root 23498 0.1 0.3 1012544 48640 ? Ssl May12 13:12 /usr/local/bin/cloudcore#杀掉kill -9 23498#启动cloudcoresystemctl start cloudcore#设置开机自启动systemctl enable cloudcore.service#查看cloudcore开机启动状态 enabled:开启, disabled:敞开systemctl is-enabled cloudcore.service获取kubeedge的token./keadm-v1.6.1-linux-amd64/keadm/keadm gettoken

运维目前3大外围方向 想成为和我一样的专家么 教训分享给你目前运维的3个炽热的方向 : k8s、监控、cicd剖析视频链接无论是否间接保护开发这3大类工具，都必须要求咱们对这些比拟相熟为什么当初k8s相干岗位炽热，给钱多-因为k8s的呈现给公司省钱 大幅升高公司的机器老本和开发效率老本所以市场上对k8s人才的需要是微小的到这里咱们能够失去1个论断就是对运维来说k8s曾经是必备技能 而非加分项剖析视频链接同时监控和cicd能够作为k8s的从属我的项目那么作为运维的咱们 怎么进阶到这3大外围方向呢听我给你们布局一个残缺的学习路线k8s要先入门 会运维操作入门课程链接入门课程链接大抵蕴含上面几局部01 集群装置和意识集群组件02 装置必要的控制台/监控/日志等组件03 kubectl 常见操作04 容器相干操作如exec 查看日志等05 常见控制器(dep/ds/sts/job)的操作06 k8s 存储对象源码解读07 k8s网络相干Service和ingress而后这时候老板让你帮忙 业务上云 上k8s，所以你须要学习一下怎么做cicd，怎么写dockerFile ，怎么部署到k8s集群中cicd实战学习方向剖析进阶视频备注01_tekton全流水线实战和pipeline运行原理源码解读地址 在保护了一段时间k8s集群后发现 prometheus监控的根底并不可靠须要从根底到进阶好好学习一下prometheusprometheus监控从入门到专家之路学习方向剖析进阶视频备注01_prometheus零根底入门，grafana根底操作，支流exporter采集配置地址 02_prometheus全组件配置应用、底层原理解析、高可用实战地址 03_kube-prometheus和prometheus-operator实战和原理介绍地址 04_prometheus-thanos应用和源码解读地址 05_prometheus源码解说和二次开发地址 而后发现不足对k8s源码的理解 导致排查不了简单的问题：所以必须要恶补一下go语言常识golang运维开发之从0根底到运维平台学习方向剖析进阶视频备注01_golang根底课程地址 02_golang运维平台实战，服务树,日志监控，工作执行，分布式探测地址 03_golang运维开发实战课程之k8s巡检平台地址 有了go根底之后就能够 畅快的浏览k8s源码k8s从零根底入门到专家到运维巨匠学习方向剖析进阶视频备注01_k8s零根底入门实战地址 02_k8s纯源码解读课程，助力你变成k8s专家地址 03_k8s底层原理和源码解说之精髓篇地址 04_k8s底层原理和源码解说之进阶篇地址 有了k8s源码的根底的你，这时候开始跃跃欲试 想做一些k8s开发工作了k8s 开发篇学习方向剖析进阶视频备注01_k8s运维巨匠课程地址 02_k8s-operator和crd实战开发 助你成为k8s专家地址 02_k8s二次开发之基于实在负载的调度器地址 如果全副学习实现之后就会发现 能够无障碍浏览许多k8s周边的go 开源我的项目了并且能够 批改其中源码进行二次开发，或者借鉴其中的逻辑自在的开发组件了

k8s根底 巡检 cicd 超卖![上传中...]()

Kubernetes 作为根底平台，提供了弱小的容器编排能力。然而在其上部署业务和服务治理上，依然会面对一些复杂性和局限性。在服务治理上，曾经有许多成熟的 ServiceMesh 框架用于裁减其能力，如 Istio、Linkerd、Dapr 等。本文将次要介绍如何应用 Istio 裁减 Kubernetes 灰度公布的能力。 而在部署上，则会利用开源我的项目 Rainbond 作为根底平台来进行实际。Rainbond 是一个云原生利用治理平台，它应用以利用为核心的设计模式。基于这一设计模式形象出了标准化的利用模型。从应用的体验上不须要学习和编写YAML，即可实现业务利用的全生命周期治理。因而应用它简化业务的部署和治理。同时 Rainbond 反对 ServiceMesh 框架的替换，使咱们能够按需抉择与业务最匹配的 ServiceMesh 框架进行服务治理。 Kubernetes 中如何实现灰度公布当你在 Kubernetes 集群中部署业务时，能够利用 Kubernetes 原生提供的灰度公布的形式去上线业务。这种形式是通过在旧版本和新版本的服务之间，定义一个差异化的 Label，依据不同版本之间的公共 Label 负载流量到后端 Pod，最终实现依据 Pod 的正本数管制流量的百分比。 如下图所示：用户定义了两个 Deployment 对象，其中旧版本名为 frontend-stable，有3个正本。新版本为 frontend-canary，有1个正本。此时定义了一个 Service 对象，应用它们之间公共的 Label 进行抉择。这就使得用户拜访 frontend 这个 Service 时，能以 3:1 的比例同时拜访到两个版本。并且还能够通过调整正本数继续管制流量比例，最终达到残缺上线。 Kubernetes 默认的实现形式在简略的部署场景下很无效，然而在一些简单场景中，依然会有较大的局限，如： 业务配置主动伸缩后，会间接影响灰度公布的流量比例低百分比的流量管制占用资源高，如 1 % 的流量达到新版本，则至多须要 100 个正本准确的流量散发管制，使拜访到新版本中的用户始终是同一批，而不是某个用户拜访时随机切换Istio 灰度公布简述因为 Kubernetes 提供的灰度公布形式的局限性，在一些简单场景下，咱们就须要应用 Istio 来实现更精密的灰度公布策略。在应用 Istio 进行灰度公布时，咱们须要理解两个重要概念： Virtual services: 虚构服务定义了申请到服务的门路。能够蕴含一组路由规定，使匹配到对应规定的申请能达到指定指标。Destination rules: 指标规定能够治理达到该指标的流量，如对服务后端所对应的实例池进行分组，再联合 Virtual services 定义的路由规定，最终将流量转发到正确的实例上。如下图所示，以 istio 官网提供的 Bookinfo 示例程序为例，给出了 virtual services 和 destination rules 的次要定义。其中 virtual services 次要分为两块，主机名和路由规定。主机名是客户端向服务发送申请时应用的一个或多个地址。当申请达到 virtual services 时，则会依据其定义的路由规定匹配。图中就定义了邮箱以 gmail.com 结尾的用户流量只会达到 v3 版本的实例上。而其余用户则以 1:9 的比例别离拜访到 v1 和 v2 版本的服务。这种形式实现了准确的流量散发管制。 ...

云原生的实质和最终成果要明确什么是云原生，就要先弄明确云计算是什么有什么问题，云计算将计算资源、网络、存储等基础设施对立治理，通过资源规模化和自动化治理，实现升高资源的老本和进步资源的管理效率，云计算实质上解决的是资源的自动化治理问题，但数字化和信息化的要害在利用，云计算没有解决利用的治理问题，利用的治理和运维是难题，对人依赖度很高，云原生的呈现就是为了解决利用的治理问题，利用治理比资源管理简单很多，波及到利用开发、利用架构、利用交付和利用运维等应用层的治理，还要配合利用解决资源自动化治理问题，云原生实质就是解决利用的自动化治理问题。 从成果来看，云原生的最终目标是让开发者聚焦本人的业务，业务之外（基础设施、利用架构、利用运维）的事件不必关怀，只须要懂业务就能发明出本人想要的利用，并能按需交付客户。 应用 Kubernetes 落地云原生困难重重以后云原生相干的技术很多，其中最要害是容器、微服务架构、Kubernetes ，他们颠覆式的解决了利用治理自动化问题。 容器技术解决了利用打包和部署自动化问题，通过容器打包保障了利用根底环境的一致性，实现了一次打包，处处运行。同时容器能够定义利用运行资源，部署时按需占用资源，实现从利用角度解决资源管理自动化。微服务架构解决了简单利用的解耦和治理问题，当业务越大越简单，微服务架构将业务拆分和解耦成多个模块，并通过服务治理实现微服务运行和治理的自动化。Kubernetes解决了利用编排和调度自动化问题，它是利用自动化治理最要害的拼图，底层基于容器、SDN、SDS，能实现各类型利用和微服务部署和运维过程自动化。为了实现利用治理自动化，还有很多云原生相干的技术，像SDN（网络自动化治理）、SDS（存储自动化治理）、Helm（简单利用交付自动化）、Service Mesh（无侵入扩大服务治理能力）、Monitoring（监控自动化）、Logging（日志自动化）、Tracing（性能剖析自动化）、Chaos engineering（容错自动化）、Gateway（网关自动化）、SPIFFE （利用拜访平安自动化）等等，这些技术能够跟Kubernetes联合起来应用，解决利用各个运维特色的治理自动化问题。 下面这些技术次要围绕着Kubernetes，所以落地过程次要是Kubernetes落地，Kubernetes落地过程个别分为两局部，Kubernetes的搭建和Kubernetes的应用。对于Kubernetes搭建，基于以上技术自主搭建残缺的Kubernetes集群非常复杂，既要学习这些技术还要理解他们的原理，最艰难的是要把他们有机的组装起来。不过大多公司有专职的保护工程师，能够抽出大把工夫来学习和尝试。或者，抉择私有云厂商提供的Kubernetes商业服务，所以，搭建Kubernetes是有门路落地的。 相比搭建Kubernetes，Kubernetes的应用个别是开发人员，开发人员人数泛滥，应用习惯和学习门槛决定了开发人员的接受度，而云原生平台的应用不仅要扭转开发习惯，还要学习很多新技术，落地过程困难重重。 须要学习很多新概念和技术。 云原生相干的技术和概念有很多，光 Kubernetes就有很多新的概念和形象，像Workload、Pod、Service、Ingress、ConfigMap、PV等，如果要用好还须要学习Kubernetes周边的很多概念和技术。已有利用须要革新，开发习惯须要扭转。 已有的利用要运行在 Kubernetes上，须要会写 Dockerfile 和 YAML，如果要革新成微服务架构，还须要依照框架的SDK革新代码，跟之前的开发习惯会有很大变动。如何将利用高效交付给客户，Kubernetes及下面这些技术并没有解决。 利用只有交付给客户能力产出价值，以后交付客户的自动化水平不高，Kubernetes并没有解决交付过程自动化的问题。在 To C的场景，业务频繁迭代，交付的频率很高，须要保质保量。在To B场景，交付更加简单，不同的客户有不同的要求，须要针对不同客户有不同的交付模式，比方SaaS、公有交付、离线交付、个性化交付等，交付也是老本里的大头。利用形象模型是云原生可落地的要害（实现思路）云原生落地的难点在应用，如果能将云原生底层简单的技术包装成开发者相熟的应用层属性和动作，开发者就不必学习新的概念和技术；如果能将业务跟运维能力解耦，跟微服务框架解耦，就能实现开发者按需扩大运维能力和切换微服务框架，实现对业务按需赋能；如果能实现依据不同客户类型，自定义交付流程和自动化交付，就能大大降低交付老本，晋升客户满意度；当以上三点都能解决，就能够让开发者聚焦在业务自身，业务之外的事件不必关怀，有更多精力关注客户价值输入。 基于以上思考，通过利用形象模型是个解决思路，对利用整体进行包装和形象，蕴含利用运行所需的全副运行定义，与底层技术和概念隔离。向上用户不须要再学习和理解零碎级概念和技术，利用外部把业务和扩大能力解耦，应用利用级概念开发和治理，须要扩大服务治理、运维、平安等能力时按需开启插件。向下则包装Kubernetes的概念和形象，屏蔽掉底层基础设施的差别，实现利用形象模型能够运行在各类基础设施上。 利用形象模版外围设计在三方面： 利用级形象架构充沛解耦应用利用模版交付利用级形象能简化了解和应用利用级形象是“以利用为外围”的形象模型，对用户裸露利用级的概念、属性和动作，底层Kubernetes和零碎级的概念和技术，要么齐全实现自动化，要么包装成利用级的属性和动作。 为了实现灵便的利用编排和自动化调度，Kubernetes 定义了很多概念，提供丰盛的扩大机制，并以YAML的形式跟它交互，Kubernetes的这些可编程的体验，对治理和扩大Kubernetes的人来说，是十分好的个性，但对于一般开发者，门槛太高，并且很多概念和技术跟本人开发的业务并没有间接关系，所以对于一般开发者来说须要更加敌对的操作体验，不须要学习就能应用。 利用级形象和Kubernetes概念 粗粒度的对应关系： 利用级属性Kubernetes概念利用运行环境Containers利用运行属性Workload利用网络属性SDN利用存储属性SDS利用对外服务属性Ingress利用对内服务属性Service利用插件Pod利用配置ConfigMap利用级形象并不是要将Kubernetes概念全副暗藏起来，而是对于不同的使用者，职责不同展示不同的交互界面。 对一般开发者职责是开发业务，只须要关怀利用级的概念，提供利用级的操作界面。但对于云原生平台的管理人员，除了关怀利用级的概念，还要关怀Kubernetes的治理和保护，有能力的话还能够扩大平台的能力，所以对于平台管理人员，提供高级的裸露Kubernetes概念的操作界面，或者间接操作Kubernetes也能够治理平台上的利用，通过这种形式也躲避了，因为包装概念产生的“黑箱”导致对平台的可观测性和可掌控性有余。 架构充沛解耦，依据应用场景按需组合基于利用级的形象，利用模型通过规范的Kubernetes API实现跟基础设施的解耦，所有符合标准Kubernetes API 的基础设施都能够实现对接和部署，比方各私有云厂商的Kubernetes实现、K3s、KubeEdge等，通过这样的解耦，开发者只须要关怀业务和能力扩大，不必在关怀基础设施的差别，对接利用模型的利用不须要改变就能通明部署到私有云、公有云和边缘设施上，实现了利用级多云。 通常在利用里，还会包含一些跟业务无关的性能，他们的作用是为了让利用更好的运行，比方：服务治理、微服务框架、运维工具、平安工具等，这些能力跟利用有强耦合关系的，须要改代码扩大能力，将这部分能力解耦，利用就只须要关注在业务了，而且扩大的能力有很强的复用性，其余利用也须要。 利用中扩大能力的解耦应用 Kubernetes 的 Pod，Pod中蕴含一个或多个容器，所有容器共享网络、存储，利用运行在一个容器，扩大的能力通过扩大容器的形式运行，通过共享的网络和存储实现了利用和扩大能力的解耦，这种解耦形式对业务齐全无侵入，扩大的能力用插件的模式包装，就能够实现利用按需装置和启动插件，依据网络流向和容器启动程序能够定义几种类型插件： 插件类型阐明入口网络插件网络流量先到入口网络插件，而后到业务容器。例如：网关、WAF、平安工具、限流进口网络插件网络流量先到业务容器，而后到插件容器。例如：负载平衡、断路器、加密拜访出入网络插件网络流量先到插件容器，再到业务容器，再回到插件容器。例如：Service Mesh proxy旁路插件网络上旁路运行。例如：性能剖析、监控 、调用链分析、日志治理初始化 插件Pod的Init容器，Pod启动先启动Init容器。例如：数据库初始化 依照Pod机制实现的插件只能扩大单个业务容器的能力，而要对利用扩大微服务架构能力，须要对每一个业务容器扩大服务治理的插件，这跟Service Mesh的实现机制统一，Service Mesh的Data Plane须要对每个业务容器注入Proxy，对于残缺利用就是扩大Service Mesh能力，对残缺利用扩大的能力是利用级插件，依据注入Proxy的差别能够反对多种类型的Service Mesh 实现，比方：Istio、Linkerd、Dapr，利用能够按需开启Service Mesh 能力，或更换实现框架。当利用跟微服务架构解耦，每一个业务容器不再受微服务框架和开发语言限度，每个业务容器只须要专一业务自身，业务容器之间也同步实现理解耦。 通过将架构充沛的解耦，解耦后的业务、插件、对接多云的能力都能实现随便组合，开发者抉择喜爱的开发语言开发业务组件，依据业务契约编排依赖关系，依据服务治理和运行稳定性要求，按需开启Service Mesh插件和其余运维插件，运行的基础设施环境，也依据理论须要主动对接。 利用模版成为能力复用和利用交付的载体利用模型以利用模版的模式具象化展示和存储，利用由源码、容器镜像和插件拼装而成，而后一键导出成利用模版，利用模版设计次要围绕使用者，让使用者能用起来，让利用交付并产出价值，从而拉动利用的迭代和开发。从应用体验上，利用模版能够一键装置和一键降级，通过“利落拽”的形式实现业务拼装。利用模版有很强灵活性，利用模版反对不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还能够继续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。利用模版能够交付到兼容Kubernetes API的分支版本，实现一键装置和降级，或将利用模版寄存到利用市场，实现即点即用的成果。 利用模版须要具备四个特点： 模块化，能够造成可复用的能力单元，按需拼装应用场景。自治，自力更生，能够独立装置、降级和治理，确保组合的灵活性。可编排，模版和模版能够拼装出新模版，具备有限拼装能力。可发现，通过外部服务和内部服务两种形式体现，可供业务和技术、开发者和其余利用拜访。通过利用模版实现可复用模块和能力的打包。 利用的架构充沛解耦后，业务组件和扩大插件实践上能够复制到其余利用中，但间接复制代码或镜像十分低效，而且还有很多运行环境相干的配置须要思考，将业务组件和扩大插件打包成利用模版，并将利用模版公布到利用市场供其他人应用，能够最大水平实现模块和能力的复用，缩小反复造轮子。 通过利用模版实现SaaS、私有化和离线环境的自动化交付，和个性化场景模块拼装。 利用模板中蕴含利用运行态所需的全副资源，对接到客户运行环境，就能够实现一键装置和运行，屏蔽了客户环境差别，一套产品模版能够交付所有类型客户，对于离线环境，利用模版以文件的模式导出，到客户离线环境再导入运行即可。对于性能须要个性化的场景，利用利用模版对业务模版打包的能力，先拼装曾经模块化的能力，而后再定制化开发，新开发的性能，如果可复用还能够持续公布成利用模版，供后续复用。 不懂 Kubernetes 实现云原生的体验基于以上的设计思路，让开发者专一于业务自身，回到用户成果和价值体现的原点上，不必关怀底层简单的技术和不相干的概念，全面实现利用自动化。 ...

二进制装置Kubernetes（k8s） v1.25.0 IPv4/IPv6双栈Kubernetes 开源不易，帮忙点个star，谢谢了 介绍kubernetes（k8s）二进制高可用装置部署，反对IPv4+IPv6双栈。 我应用IPV6的目标是在公网进行拜访，所以我配置了IPV6动态地址。 若您没有IPV6环境，或者不想应用IPv6，不对主机进行配置IPv6地址即可。 不配置IPV6，不影响后续，不过集群仍旧是反对IPv6的。为前期留有扩大可能性。 若不要IPv6 ，不给网卡配置IPv6即可，不要对IPv6相干配置删除或操作，否则会出问题。 https://github.com/cby-chen/K... 手动我的项目地址：https://github.com/cby-chen/K... 脚本我的项目地址：https://github.com/cby-chen/B... 强烈建议在Github上查看文档。Github出问题会更新文档，并且后续尽可能第一工夫更新新版本文档。 1.21.13 和 1.22.10 和 1.23.3 和 1.23.4 和 1.23.5 和 1.23.6 和 1.23.7 和 1.24.0 和 1.24.1 和 1.24.2 和 1.24.3 和 1.25.0 文档以及安装包已生成。 1.环境主机名称IP地址阐明软件Master01192.168.1.61master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalivedMaster02192.168.1.62master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalivedMaster03192.168.1.63master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-client、haproxy、keepalivedNode01192.168.1.64node节点kubelet、kube-proxy、nfs-clientNode02192.168.1.65node节点kubelet、kube-proxy、nfs-client 192.168.1.66VIP 软件版本kernel5.18.0-1.el8CentOS 8v8 或者 v7kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxyv1.25.0etcdv3.5.4containerdv1.6.8dockerv20.10.17cfsslv1.6.2cniv1.1.1crictlv1.25.0haproxyv1.8.27keepalivedv2.1.5网段 物理主机：192.168.1.0/24 service：10.96.0.0/12 pod：172.16.0.0/12 安装包曾经整顿好：https://github.com/cby-chen/K... 1.1.k8s根底零碎环境配置1.2.配置IPssh root@192.168.1.11 "nmcli con mod ens160 ipv4.addresses 192.168.1.61/24; nmcli con mod ens160 ipv4.gateway 192.168.1.1; nmcli con mod ens160 ipv4.method manual; nmcli con mod ens160 ipv4.dns "8.8.8.8"; nmcli con up ens160"ssh root@192.168.1.13 "nmcli con mod ens160 ipv4.addresses 192.168.1.62/24; nmcli con mod ens160 ipv4.gateway 192.168.1.1; nmcli con mod ens160 ipv4.method manual; nmcli con mod ens160 ipv4.dns "8.8.8.8"; nmcli con up ens160"ssh root@192.168.1.14 "nmcli con mod ens160 ipv4.addresses 192.168.1.63/24; nmcli con mod ens160 ipv4.gateway 192.168.1.1; nmcli con mod ens160 ipv4.method manual; nmcli con mod ens160 ipv4.dns "8.8.8.8"; nmcli con up ens160"ssh root@192.168.1.15 "nmcli con mod ens160 ipv4.addresses 192.168.1.64/24; nmcli con mod ens160 ipv4.gateway 192.168.1.1; nmcli con mod ens160 ipv4.method manual; nmcli con mod ens160 ipv4.dns "8.8.8.8"; nmcli con up ens160"ssh root@192.168.1.16 "nmcli con mod ens160 ipv4.addresses 192.168.1.65/24; nmcli con mod ens160 ipv4.gateway 192.168.1.1; nmcli con mod ens160 ipv4.method manual; nmcli con mod ens160 ipv4.dns "8.8.8.8"; nmcli con up ens160"# 没有IPv6抉择不配置即可ssh root@192.168.1.61 "nmcli con mod ens160 ipv6.addresses 2409:8a10:9e15:b8a0::10; nmcli con mod ens160 ipv6.gateway 2409:8a10:9e15:b8a0::; nmcli con mod ens160 ipv6.method manual; nmcli con mod ens160 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens160"ssh root@192.168.1.62 "nmcli con mod ens160 ipv6.addresses 2409:8a10:9e15:b8a0::20; nmcli con mod ens160 ipv6.gateway 2409:8a10:9e15:b8a0::; nmcli con mod ens160 ipv6.method manual; nmcli con mod ens160 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens160"ssh root@192.168.1.63 "nmcli con mod ens160 ipv6.addresses 2409:8a10:9e15:b8a0::30; nmcli con mod ens160 ipv6.gateway 2409:8a10:9e15:b8a0::; nmcli con mod ens160 ipv6.method manual; nmcli con mod ens160 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens160"ssh root@192.168.1.64 "nmcli con mod ens160 ipv6.addresses 2409:8a10:9e15:b8a0::40; nmcli con mod ens160 ipv6.gateway 2409:8a10:9e15:b8a0::; nmcli con mod ens160 ipv6.method manual; nmcli con mod ens160 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens160"ssh root@192.168.1.65 "nmcli con mod ens160 ipv6.addresses 2409:8a10:9e15:b8a0::50; nmcli con mod ens160 ipv6.gateway 2409:8a10:9e15:b8a0::; nmcli con mod ens160 ipv6.method manual; nmcli con mod ens160 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens160"1.3.设置主机名hostnamectl set-hostname k8s-master01hostnamectl set-hostname k8s-master02hostnamectl set-hostname k8s-master03hostnamectl set-hostname k8s-node01hostnamectl set-hostname k8s-node021.4.配置yum源# 对于 CentOS 7sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.tuna.tsinghua.edu.cn|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于 CentOS 8sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org/$contentdir|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于公有仓库sed -e 's|^mirrorlist=|#mirrorlist=|g' -e 's|^#baseurl=http://mirror.centos.org/\$contentdir|baseurl=http://192.168.1.123/centos|g' -i.bak /etc/yum.repos.d/CentOS-*.repo1.5.装置一些必备工具yum update -y && yum -y install wget jq psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git network-scripts tar curl -y1.6.选择性下载须要工具1.下载kubernetes1.25.+的二进制包github二进制包下载地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.mdwget https://dl.k8s.io/v1.25.0/kubernetes-server-linux-amd64.tar.gz2.下载etcdctl二进制包github二进制包下载地址：https://github.com/etcd-io/etcd/releaseswget https://github.com/etcd-io/etcd/releases/download/v3.5.4/etcd-v3.5.4-linux-amd64.tar.gz3.containerd二进制包下载github下载地址：https://github.com/containerd/containerd/releases4.containerd下载时下载带cni插件的二进制包。wget https://github.com/containerd/containerd/releases/download/v1.6.8/cri-containerd-cni-1.6.8-linux-amd64.tar.gz5.下载cfssl二进制包github二进制包下载地址：https://github.com/cloudflare/cfssl/releaseswget https://github.com/cloudflare/cfssl/releases/download/v1.6.2/cfssl_1.6.2_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.6.2/cfssljson_1.6.2_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.6.2/cfssl-certinfo_1.6.2_linux_amd646.cni插件下载github下载地址：https://github.com/containernetworking/plugins/releaseswget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-amd64-v1.1.1.tgz7.crictl客户端二进制下载github下载：https://github.com/kubernetes-sigs/cri-tools/releaseswget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.25.0/crictl-v1.25.0-linux-amd64.tar.gz1.7.敞开防火墙systemctl disable --now firewalld1.8.敞开SELinuxsetenforce 0sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config1.9.敞开替换分区sed -ri 's/.*swap.*/#&/' /etc/fstabswapoff -a && sysctl -w vm.swappiness=0cat /etc/fstab# /dev/mapper/centos-swap swap swap defaults 0 01.10.网络配置（俩种形式二选一）# 形式一# systemctl disable --now NetworkManager# systemctl start network && systemctl enable network# 形式二cat > /etc/NetworkManager/conf.d/calico.conf << EOF [keyfile]unmanaged-devices=interface-name:cali*;interface-name:tunl*EOFsystemctl restart NetworkManager1.11.进行工夫同步# 服务端yum install chrony -ycat > /etc/chrony.conf << EOF pool ntp.aliyun.com iburstdriftfile /var/lib/chrony/driftmakestep 1.0 3rtcsyncallow 192.168.1.0/24local stratum 10keyfile /etc/chrony.keysleapsectz right/UTClogdir /var/log/chronyEOFsystemctl restart chronyd ; systemctl enable chronyd# 客户端yum install chrony -ycat > /etc/chrony.conf << EOF pool 192.168.1.61 iburstdriftfile /var/lib/chrony/driftmakestep 1.0 3rtcsynckeyfile /etc/chrony.keysleapsectz right/UTClogdir /var/log/chronyEOFsystemctl restart chronyd ; systemctl enable chronyd#应用客户端进行验证chronyc sources -v1.12.配置ulimitulimit -SHn 65535cat >> /etc/security/limits.conf <<EOF* soft nofile 655360* hard nofile 131072* soft nproc 655350* hard nproc 655350* seft memlock unlimited* hard memlock unlimiteddEOF1.13.配置免密登录yum install -y sshpassssh-keygen -f /root/.ssh/id_rsa -P ''export IP="192.168.1.61 192.168.1.62 192.168.1.63 192.168.1.64 192.168.1.65"export SSHPASS=123123for HOST in $IP;do sshpass -e ssh-copy-id -o StrictHostKeyChecking=no $HOSTdone1.14.增加启用源# 为 RHEL-8或 CentOS-8配置源yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm -y sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo # 为 RHEL-7 SL-7 或 CentOS-7 装置 ELRepo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm -y sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo # 查看可用安装包yum --disablerepo="*" --enablerepo="elrepo-kernel" list available1.15.降级内核至4.18版本以上# 装置最新的内核# 我这里抉择的是稳定版kernel-ml 如需更新长期保护版本kernel-lt yum --enablerepo=elrepo-kernel install kernel-ml# 查看已装置那些内核rpm -qa | grep kernelkernel-core-4.18.0-358.el8.x86_64kernel-tools-4.18.0-358.el8.x86_64kernel-ml-core-5.16.7-1.el8.elrepo.x86_64kernel-ml-5.16.7-1.el8.elrepo.x86_64kernel-modules-4.18.0-358.el8.x86_64kernel-4.18.0-358.el8.x86_64kernel-tools-libs-4.18.0-358.el8.x86_64kernel-ml-modules-5.16.7-1.el8.elrepo.x86_64# 查看默认内核grubby --default-kernel/boot/vmlinuz-5.16.7-1.el8.elrepo.x86_64# 若不是最新的应用命令设置grubby --set-default /boot/vmlinuz-「您的内核版本」.x86_64# 重启失效reboot# v8 整合命令为：yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm -y ; sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo ; sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo ; yum --disablerepo="*" --enablerepo="elrepo-kernel" list available -y ; yum --enablerepo=elrepo-kernel install kernel-ml -y ; grubby --default-kernel ; reboot # v7 整合命令为：yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm -y ; sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo ; sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo ; yum --disablerepo="*" --enablerepo="elrepo-kernel" list available -y ; yum --enablerepo=elrepo-kernel install kernel-ml -y ; grubby --set-default $(ls /boot/vmlinuz-* | grep elrepo) ; grubby --default-kernel ; reboot 1.16.装置ipvsadmyum install ipvsadm ipset sysstat conntrack libseccomp -ycat >> /etc/modules-load.d/ipvs.conf <<EOF ip_vsip_vs_rrip_vs_wrrip_vs_shnf_conntrackip_tablesip_setxt_setipt_setipt_rpfilteript_REJECTipipEOFsystemctl restart systemd-modules-load.servicelsmod | grep -e ip_vs -e nf_conntrackip_vs_sh 16384 0ip_vs_wrr 16384 0ip_vs_rr 16384 0ip_vs 180224 6 ip_vs_rr,ip_vs_sh,ip_vs_wrrnf_conntrack 176128 1 ip_vsnf_defrag_ipv6 24576 2 nf_conntrack,ip_vsnf_defrag_ipv4 16384 1 nf_conntracklibcrc32c 16384 3 nf_conntrack,xfs,ip_vs1.17.批改内核参数cat <<EOF > /etc/sysctl.d/k8s.confnet.ipv4.ip_forward = 1net.bridge.bridge-nf-call-iptables = 1fs.may_detach_mounts = 1vm.overcommit_memory=1vm.panic_on_oom=0fs.inotify.max_user_watches=89100fs.file-max=52706963fs.nr_open=52706963net.netfilter.nf_conntrack_max=2310720net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_keepalive_intvl =15net.ipv4.tcp_max_tw_buckets = 36000net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_max_orphans = 327680net.ipv4.tcp_orphan_retries = 3net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 16384net.ipv4.ip_conntrack_max = 65536net.ipv4.tcp_max_syn_backlog = 16384net.ipv4.tcp_timestamps = 0net.core.somaxconn = 16384net.ipv6.conf.all.disable_ipv6 = 0net.ipv6.conf.default.disable_ipv6 = 0net.ipv6.conf.lo.disable_ipv6 = 0net.ipv6.conf.all.forwarding = 1EOFsysctl --system1.18.所有节点配置hosts本地解析cat > /etc/hosts <<EOF127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6# 没有IPv6抉择不配置即可2409:8a10:9e15:b8a0::10 k8s-master012409:8a10:9e15:b8a0::20 k8s-master022409:8a10:9e15:b8a0::30 k8s-master032409:8a10:9e15:b8a0::40 k8s-node012409:8a10:9e15:b8a0::50 k8s-node02192.168.1.61 k8s-master01192.168.1.62 k8s-master02192.168.1.63 k8s-master03192.168.1.64 k8s-node01192.168.1.65 k8s-node02192.168.1.66 lb-vipEOF2.k8s根本组件装置留神 ： 2.1 和 2.2 二选其一即可 ...

在Kubernetes部署GitLab前置条件已装置Helm工具已部署NFS主动创立PVC 应用HELM装置[root@k8s-master01 ~]# helm repo add gitlab https://charts.gitlab.io/"gitlab" has been added to your repositories[root@k8s-master01 ~]# helm repo updateHang tight while we grab the latest from your chart repositories......Successfully got an update from the "gitlab" chart repository...Successfully got an update from the "cilium" chart repositoryUpdate Complete. ⎈Happy Helming!⎈[root@k8s-master01 ~]# helm upgrade --install gitlab gitlab/gitlab \ --timeout 600s \ --set global.hosts.domain=git.oiox.cn \ --set global.hosts.externalIP=192.168.1.61 \ --set certmanager-issuer.email=cby@chenby.cn NAME: gitlabLAST DEPLOYED: Mon Sep 12 19:49:30 2022NAMESPACE: defaultSTATUS: deployedREVISION: 1NOTES:=== NOTICEThe minimum required version of PostgreSQL is now 12. See https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/doc/installation/upgrade.md for more details.=== NOTICEYou've installed GitLab Runner without the ability to use 'docker in docker'.The GitLab Runner chart (gitlab/gitlab-runner) is deployed without the `privileged` flag by default for security purposes. This can be changed by setting `gitlab-runner.runners.privileged` to `true`. Before doing so, please read the GitLab Runner chart's documentation on why wechose not to enable this by default. See https://docs.gitlab.com/runner/install/kubernetes.html#running-docker-in-docker-containers-with-gitlab-runnersHelp us improve the installation experience, let us know how we did with a 1 minute survey:https://gitlab.fra1.qualtrics.com/jfe/form/SV_6kVqZANThUQ1bZb?installation=helm&release=15-3=== NOTICEThe in-chart NGINX Ingress Controller has the following requirements: - Kubernetes version must be 1.19 or newer. - Ingress objects must be in group/version `networking.k8s.io/v1`.[root@k8s-master01 ~]# 查看POD状况[root@k8s-master01 ~]# kubectl get pod -ANAMESPACE NAME READY STATUS RESTARTS AGEcilium-monitoring grafana-59957b9549-6zzqh 1/1 Running 1 (6m28s ago) 8hcilium-monitoring prometheus-7c8c9684bb-4v9cl 1/1 Running 1 (4m49s ago) 8hdefault chenby-75b5d7fbfb-7zjsr 1/1 Running 1 (6m15s ago) 35hdefault chenby-75b5d7fbfb-hbvr8 1/1 Running 1 (5m27s ago) 35hdefault chenby-75b5d7fbfb-ppbzg 1/1 Running 1 (5m57s ago) 35hdefault cm-acme-http-solver-8b6lg 1/1 Running 1 (4m49s ago) 11mdefault cm-acme-http-solver-9sd7r 1/1 Running 1 (4m49s ago) 11mdefault cm-acme-http-solver-tx5x2 1/1 Running 1 (5m27s ago) 11mdefault cm-acme-http-solver-w74zd 1/1 Running 1 (4m49s ago) 11mdefault echo-a-6799dff547-pnx6w 1/1 Running 1 (6m28s ago) 8hdefault echo-b-fc47b659c-4bdg9 1/1 Running 1 (4m49s ago) 8hdefault echo-b-host-67fcfd59b7-28r9s 1/1 Running 1 (4m49s ago) 8hdefault gitlab-certmanager-7cb7797848-fgdff 1/1 Running 1 (5m27s ago) 12mdefault gitlab-certmanager-cainjector-5968cb88f9-qw4d7 1/1 Running 2 (5m57s ago) 12mdefault gitlab-certmanager-webhook-797bcff548-t266p 1/1 Running 1 (6m15s ago) 12mdefault gitlab-gitaly-0 1/1 Running 1 (6m28s ago) 12mdefault gitlab-gitlab-exporter-58fc5779d7-lbl4s 1/1 Running 1 (5m27s ago) 12mdefault gitlab-gitlab-runner-5484688b78-d5gmt 0/1 Running 3 (2m8s ago) 12mdefault gitlab-gitlab-shell-7578c56d55-p5fvp 1/1 Running 1 (5m27s ago) 12mdefault gitlab-gitlab-shell-7578c56d55-vzbrb 1/1 Running 1 (4m49s ago) 12mdefault gitlab-issuer-1-sw7nm 0/1 Completed 0 12mdefault gitlab-kas-85f677867b-sjxqv 1/1 Running 1 (4m49s ago) 12mdefault gitlab-kas-85f677867b-wwlsl 1/1 Running 1 (6m28s ago) 12mdefault gitlab-migrations-1-hpsc8 0/1 Completed 2 12mdefault gitlab-minio-74467697bb-76xcb 1/1 Running 1 (4m49s ago) 12mdefault gitlab-minio-create-buckets-1-nwzh2 0/1 Completed 0 12mdefault gitlab-nginx-ingress-controller-77589fdd6f-7rk5f 1/1 Running 1 (5m27s ago) 12mdefault gitlab-nginx-ingress-controller-77589fdd6f-lk96x 1/1 Running 1 (4m49s ago) 12mdefault gitlab-postgresql-0 2/2 Running 2 (5m27s ago) 12mdefault gitlab-prometheus-server-6bf4fffc55-ww59q 2/2 Running 2 (6m14s ago) 12mdefault gitlab-redis-master-0 2/2 Running 2 (4m49s ago) 12mdefault gitlab-registry-54899b8c96-gkmm2 1/1 Running 1 (5m27s ago) 12mdefault gitlab-registry-54899b8c96-pzxcd 1/1 Running 1 (5m57s ago) 12mdefault gitlab-sidekiq-all-in-1-v2-64cbbc8cd8-4pmm9 1/1 Running 1 (5m57s ago) 12mdefault gitlab-sidekiq-all-in-1-v2-64cbbc8cd8-fr2wn 1/1 Running 0 81sdefault gitlab-sidekiq-all-in-1-v2-64cbbc8cd8-sx8b6 1/1 Running 0 81sdefault gitlab-toolbox-746c98d8f6-cxwl9 1/1 Running 1 (5m27s ago) 12mdefault gitlab-webservice-default-6998494449-9hrtc 2/2 Running 1 (6m28s ago) 12mdefault gitlab-webservice-default-6998494449-kdbbq 2/2 Running 2 (6m14s ago) 12mdefault host-to-b-multi-node-clusterip-69c57975d6-z4j2z 1/1 Running 3 (4m6s ago) 8hdefault host-to-b-multi-node-headless-865899f7bb-frrmc 1/1 Running 2 (4m16s ago) 8hdefault nfs-client-provisioner-665598d599-4xwmf 1/1 Running 3 (5m57s ago) 52mdefault pod-to-a-allowed-cnp-5f9d7d4b9d-hcd8x 1/1 Running 4 (3m54s ago) 8hdefault pod-to-a-denied-cnp-65cc5ff97b-2rzb8 1/1 Running 1 (6m28s ago) 8hdefault pod-to-a-dfc64f564-p7xcn 1/1 Running 3 (4m6s ago) 8hdefault pod-to-b-intra-node-nodeport-677868746b-trk2l 1/1 Running 1 (4m49s ago) 8hdefault pod-to-b-multi-node-clusterip-76bbbc677b-knfq2 1/1 Running 2 (4m2s ago) 8hdefault pod-to-b-multi-node-headless-698c6579fd-mmvd7 1/1 Running 2 (4m48s ago) 8hdefault pod-to-b-multi-node-nodeport-5dc4b8cfd6-8dxmz 1/1 Running 2 (4m48s ago) 8hdefault pod-to-external-1111-8459965778-pjt9b 1/1 Running 13 (5m57s ago) 8hdefault pod-to-external-fqdn-allow-google-cnp-64df9fb89b-l9l4q 1/1 Running 15 (4m39s ago) 8hkube-system cilium-7rfj6 1/1 Running 1 (5m27s ago) 8hkube-system cilium-d4cch 1/1 Running 1 (6m28s ago) 8hkube-system cilium-h5x8r 1/1 Running 1 (5m57s ago) 8hkube-system cilium-operator-5dbddb6dbf-flpl5 1/1 Running 1 (6m28s ago) 8hkube-system cilium-operator-5dbddb6dbf-gcznc 1/1 Running 2 (4m49s ago) 8hkube-system cilium-t2xlz 1/1 Running 1 (4m49s ago) 8hkube-system cilium-z65z7 1/1 Running 1 (6m15s ago) 8hkube-system coredns-665475b9f8-jkqn8 1/1 Running 2 (4m49s ago) 44hkube-system hubble-relay-59d8575-9pl9z 1/1 Running 1 (6m28s ago) 8hkube-system hubble-ui-64d4995d57-nsv9j 2/2 Running 2 (6m28s ago) 8hkube-system metrics-server-776f58c94b-c6zgs 1/1 Running 2 (6m14s ago) 45h[root@k8s-master01 ~]# 查看INGRESS状况[root@k8s-master01 ~]# kubectl get svc -A | grep ingressdefault gitlab-nginx-ingress-controller LoadBalancer 10.111.0.148 <pending> 80:32002/TCP,443:31390/TCP,22:30887/TCP 26mdefault gitlab-nginx-ingress-controller-metrics ClusterIP 10.104.165.192 <none> 10254/TCP 26m# 批改为NodePort[root@k8s-master01 ~]# kubectl edit svc gitlab-nginx-ingress-controllerservice/gitlab-nginx-ingress-controller edited[root@k8s-master01 ~]# [root@k8s-master01 ~]# kubectl get svc -A | grep ingressdefault gitlab-nginx-ingress-controller NodePort 10.111.0.148 <none> 80:32002/TCP,443:31390/TCP,22:30887/TCP 26mdefault gitlab-nginx-ingress-controller-metrics ClusterIP 10.104.165.192 <none> 10254/TCP 26m[root@k8s-master01 ~]# [root@k8s-master01 ~]# # 查看有哪些域名[root@k8s-master01 ~]# kubectl get ingressNAME CLASS HOSTS ADDRESS PORTS AGEcm-acme-http-solver-84tql gitlab-nginx minio.git.oiox.cn 10.111.0.148 80 25mcm-acme-http-solver-c4n6s gitlab-nginx kas.git.oiox.cn 10.111.0.148 80 25mcm-acme-http-solver-vwn4s gitlab-nginx gitlab.git.oiox.cn 10.111.0.148 80 25mcm-acme-http-solver-zccvm gitlab-nginx registry.git.oiox.cn 10.111.0.148 80 25mgitlab-kas gitlab-nginx kas.git.oiox.cn 10.111.0.148 80, 443 27mgitlab-minio gitlab-nginx minio.git.oiox.cn 10.111.0.148 80, 443 27mgitlab-registry gitlab-nginx registry.git.oiox.cn 10.111.0.148 80, 443 27mgitlab-webservice-default gitlab-nginx gitlab.git.oiox.cn 10.111.0.148 80, 443 27m[root@k8s-master01 ~]# 本地写入域名[root@k8s-master01 ~]# cat /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6# 没有IPv6抉择不配置即可2409:8a10:9e10:8700::10 k8s-master012409:8a10:9e10:8700::20 k8s-master022409:8a10:9e10:8700::30 k8s-master032409:8a10:9e10:8700::40 k8s-node012409:8a10:9e10:8700::50 k8s-node02192.168.1.61 k8s-master01192.168.1.62 k8s-master02192.168.1.63 k8s-master03192.168.1.64 k8s-node01192.168.1.65 k8s-node02192.168.1.66 lb-vip192.168.1.61 kas.git.oiox.cn192.168.1.61 minio.git.oiox.cn192.168.1.61 registry.git.oiox.cn192.168.1.61 gitlab.git.oiox.cn[root@k8s-master01 ~]# 测试拜访# 查看明码[root@k8s-master01 ~]# kubectl get secret gitlab-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echoHh7EjzH01T7DJw7TutWG6ynAU8yoGYcxNcV0cADCIpRCPeuFA5DBTC1I5V4T4gz4[root@k8s-master01 ~]# # 拜访https://gitlab.git.oiox.cn:31390/123 ...

kubernetes 装置ciliumCilium介绍Cilium是一个开源软件，用于通明地提供和爱护应用Kubernetes，Docker和Mesos等Linux容器治理平台部署的应用程序服务之间的网络和API连贯。 Cilium基于一种名为BPF的新Linux内核技术，它能够在Linux外部动静插入弱小的安全性，可见性和网络管制逻辑。 除了提供传统的网络级安全性之外，BPF的灵活性还能够在API和过程级别上实现安全性，以爱护容器或容器内的通信。因为BPF在Linux内核中运行，因而能够利用和更新Cilium安全策略，而无需对利用程序代码或容器配置进行任何更改。 1 装置helm[root@k8s-master01 ~]# curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3[root@k8s-master01 ~]# chmod 700 get_helm.sh[root@k8s-master01 ~]# ./get_helm.sh2 装置cilium[root@k8s-master01 ~]# helm repo add cilium https://helm.cilium.io[root@k8s-master01 ~]# helm install cilium cilium/cilium --namespace kube-system --set hubble.relay.enabled=true --set hubble.ui.enabled=true --set prometheus.enabled=true --set operator.prometheus.enabled=true --set hubble.enabled=true --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,http}"NAME: ciliumLAST DEPLOYED: Sun Sep 11 00:04:30 2022NAMESPACE: kube-systemSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:You have successfully installed Cilium with Hubble.Your release version is 1.12.1.For any further help, visit https://docs.cilium.io/en/v1.12/gettinghelp[root@k8s-master01 ~]#3 查看[root@k8s-master01 ~]# kubectl get pod -A | grep cilkube-system cilium-gmr6c 1/1 Running 0 5m3skube-system cilium-kzgdj 1/1 Running 0 5m3skube-system cilium-operator-69b677f97c-6pw4k 1/1 Running 0 5m3skube-system cilium-operator-69b677f97c-xzzdk 1/1 Running 0 5m3skube-system cilium-q2rnr 1/1 Running 0 5m3skube-system cilium-smx5v 1/1 Running 0 5m3skube-system cilium-tdjq4 1/1 Running 0 5m3s[root@k8s-master01 ~]#4 下载专属监控面板[root@k8s-master01 yaml]# wget https://raw.githubusercontent.com/cilium/cilium/1.12.1/examples/kubernetes/addons/prometheus/monitoring-example.yaml[root@k8s-master01 yaml]#[root@k8s-master01 yaml]# kubectl apply -f monitoring-example.yamlnamespace/cilium-monitoring createdserviceaccount/prometheus-k8s createdconfigmap/grafana-config createdconfigmap/grafana-cilium-dashboard createdconfigmap/grafana-cilium-operator-dashboard createdconfigmap/grafana-hubble-dashboard createdconfigmap/prometheus createdclusterrole.rbac.authorization.k8s.io/prometheus createdclusterrolebinding.rbac.authorization.k8s.io/prometheus createdservice/grafana createdservice/prometheus createddeployment.apps/grafana createddeployment.apps/prometheus created[root@k8s-master01 yaml]#5 下载部署测试用例[root@k8s-master01 yaml]# wget https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/connectivity-check/connectivity-check.yaml[root@k8s-master01 yaml]# sed -i "s#google.com#oiox.cn#g" connectivity-check.yaml[root@k8s-master01 yaml]# kubectl apply -f connectivity-check.yamldeployment.apps/echo-a createddeployment.apps/echo-b createddeployment.apps/echo-b-host createddeployment.apps/pod-to-a createddeployment.apps/pod-to-external-1111 createddeployment.apps/pod-to-a-denied-cnp createddeployment.apps/pod-to-a-allowed-cnp createddeployment.apps/pod-to-external-fqdn-allow-google-cnp createddeployment.apps/pod-to-b-multi-node-clusterip createddeployment.apps/pod-to-b-multi-node-headless createddeployment.apps/host-to-b-multi-node-clusterip createddeployment.apps/host-to-b-multi-node-headless createddeployment.apps/pod-to-b-multi-node-nodeport createddeployment.apps/pod-to-b-intra-node-nodeport createdservice/echo-a createdservice/echo-b createdservice/echo-b-headless createdservice/echo-b-host-headless createdciliumnetworkpolicy.cilium.io/pod-to-a-denied-cnp createdciliumnetworkpolicy.cilium.io/pod-to-a-allowed-cnp createdciliumnetworkpolicy.cilium.io/pod-to-external-fqdn-allow-google-cnp created[root@k8s-master01 yaml]#6 查看pod[root@k8s-master01 yaml]# kubectl get pod -ANAMESPACE NAME READY STATUS RESTARTS AGEcilium-monitoring grafana-59957b9549-6zzqh 1/1 Running 0 10mcilium-monitoring prometheus-7c8c9684bb-4v9cl 1/1 Running 0 10mdefault chenby-75b5d7fbfb-7zjsr 1/1 Running 0 27hdefault chenby-75b5d7fbfb-hbvr8 1/1 Running 0 27hdefault chenby-75b5d7fbfb-ppbzg 1/1 Running 0 27hdefault echo-a-6799dff547-pnx6w 1/1 Running 0 10mdefault echo-b-fc47b659c-4bdg9 1/1 Running 0 10mdefault echo-b-host-67fcfd59b7-28r9s 1/1 Running 0 10mdefault host-to-b-multi-node-clusterip-69c57975d6-z4j2z 1/1 Running 0 10mdefault host-to-b-multi-node-headless-865899f7bb-frrmc 1/1 Running 0 10mdefault pod-to-a-allowed-cnp-5f9d7d4b9d-hcd8x 1/1 Running 0 10mdefault pod-to-a-denied-cnp-65cc5ff97b-2rzb8 1/1 Running 0 10mdefault pod-to-a-dfc64f564-p7xcn 1/1 Running 0 10mdefault pod-to-b-intra-node-nodeport-677868746b-trk2l 1/1 Running 0 10mdefault pod-to-b-multi-node-clusterip-76bbbc677b-knfq2 1/1 Running 0 10mdefault pod-to-b-multi-node-headless-698c6579fd-mmvd7 1/1 Running 0 10mdefault pod-to-b-multi-node-nodeport-5dc4b8cfd6-8dxmz 1/1 Running 0 10mdefault pod-to-external-1111-8459965778-pjt9b 1/1 Running 0 10mdefault pod-to-external-fqdn-allow-google-cnp-64df9fb89b-l9l4q 1/1 Running 0 10mkube-system cilium-7rfj6 1/1 Running 0 56skube-system cilium-d4cch 1/1 Running 0 56skube-system cilium-h5x8r 1/1 Running 0 56skube-system cilium-operator-5dbddb6dbf-flpl5 1/1 Running 0 56skube-system cilium-operator-5dbddb6dbf-gcznc 1/1 Running 0 56skube-system cilium-t2xlz 1/1 Running 0 56skube-system cilium-z65z7 1/1 Running 0 56skube-system coredns-665475b9f8-jkqn8 1/1 Running 1 (36h ago) 36hkube-system hubble-relay-59d8575-9pl9z 1/1 Running 0 56skube-system hubble-ui-64d4995d57-nsv9j 2/2 Running 0 56skube-system metrics-server-776f58c94b-c6zgs 1/1 Running 1 (36h ago) 37h[root@k8s-master01 yaml]#7 批改为NodePort[root@k8s-master01 yaml]# kubectl edit svc -n kube-system hubble-uiservice/hubble-ui edited[root@k8s-master01 yaml]#[root@k8s-master01 yaml]# kubectl edit svc -n cilium-monitoring grafanaservice/grafana edited[root@k8s-master01 yaml]#[root@k8s-master01 yaml]# kubectl edit svc -n cilium-monitoring prometheusservice/prometheus edited[root@k8s-master01 yaml]#type: NodePort8 查看端口[root@k8s-master01 yaml]# kubectl get svc -A | grep monitcilium-monitoring grafana NodePort 10.100.250.17 <none> 3000:30707/TCP 15mcilium-monitoring prometheus NodePort 10.100.131.243 <none> 9090:31155/TCP 15m[root@k8s-master01 yaml]#[root@k8s-master01 yaml]# kubectl get svc -A | grep hubblekube-system hubble-metrics ClusterIP None <none> 9965/TCP 5m12skube-system hubble-peer ClusterIP 10.100.150.29 <none> 443/TCP 5m12skube-system hubble-relay ClusterIP 10.109.251.34 <none> 80/TCP 5m12skube-system hubble-ui NodePort 10.102.253.59 <none> 80:31219/TCP 5m12s[root@k8s-master01 yaml]#9 拜访http://192.168.1.61:30707http://192.168.1.61:31155http://192.168.1.61:31219对于 ...

官网：https://kubernetes.io/ 文档：https://kubernetes.io/zh-cn/d... 根底环境部署后期筹备（所有节点）1、批改主机名和配置 hosts 先部署 1master 和 2node 节点，前面再加一个 master 节点 # 在192.168.0.113执行hostnamectl set-hostname k8s-master-168-0-113# 在192.168.0.114执行hostnamectl set-hostname k8s-node1-168-0-114# 在192.168.0.115执行hostnamectl set-hostname k8s-node2-168-0-115配置 hosts cat >> /etc/hosts<<EOF192.168.0.113 k8s-master-168-0-113192.168.0.114 k8s-node1-168-0-114192.168.0.115 k8s-node2-168-0-115EOF2、配置 ssh 互信 # 间接始终回车就行ssh-keygenssh-copy-id -i ~/.ssh/id_rsa.pub root@k8s-master-168-0-113ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8s-node1-168-0-114ssh-copy-id -i ~/.ssh/id_rsa.pub root@k8s-node2-168-0-1153、工夫同步 yum install chrony -ysystemctl start chronydsystemctl enable chronydchronyc sources4、敞开防火墙 systemctl stop firewalldsystemctl disable firewalld5、敞开 swap # 长期敞开；敞开swap次要是为了性能思考swapoff -a# 能够通过这个命令查看swap是否敞开了free# 永恒敞开sed -ri 's/.*swap.*/#&/' /etc/fstab6、禁用 SELinux # 长期敞开setenforce 0# 永恒禁用sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config7、容许 iptables 查看桥接流量（可选，所有节点） ...

别再放心线上 Java 业务出问题怎么办了，Arthas 帮忙你解决以下常见问题： 这个类从哪个 jar 包加载的？为什么会报各种类相干的 Exception？我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？遇到问题无奈在线上 debug，难道只能通过加日志再从新公布吗？线上遇到某个用户的数据处理有问题，但线上同样无奈 debug，线下无奈重现！是否有一个全局视角来查看零碎的运行状况？有什么方法能够监控到 JVM 的实时运行状态？怎么疾速定位利用的热点，生成火焰图？怎么间接从 JVM 内查找某个类的实例？Arthas（阿尔萨斯）是一款线上监控诊断产品，通过全局视角实时查看利用 load、内存、gc、线程的状态信息，并能在不批改利用代码的状况下，对业务问题进行诊断，包含查看办法调用的出入参、异样，监测办法执行耗时，类加载信息等，大大晋升线上问题排查效率。 Arthas 采纳命令行交互模式，同时提供丰盛的 Tab 主动补全性能，进一步不便进行问题的定位和诊断。 同时 Arthas 也反对通过 Web Console 进入命令行交互模式，这实用于开发人员没有服务器权限时通过 Arthas Web Console 诊断业务。 Arthas 在 Rainbond 上集成1. 插件集成 通过 Rainbond 插件的机制，从 Rainbond 开源利用商店一键装置 Arthas 插件并在组件中开明，组件启动时会主动下载 arthas-agent.jar 联合环境变量配置应用 javaagent 形式启动。 2. Arthas Tunnel 集成 当咱们的微服务业务有 10+，这时通过 Arthas 去诊断就会比拟麻烦，开发人员没有服务器的权限并且通过 Web Console 拜访的话也会因为拜访地址太多导致特地凌乱。这时就须要通过 Arthas Tunnel Server/Client 来远程管理/连贯多个 Agent。 Arthas Agent 会通过 WS 注册到 Arthas Tunnel 中，实现对立治理。 ...

tekton的长处联合k8s的诸多特点：整体上设计的非常奇妙hub中有丰盛的 task 供咱们封装本人的pipeline我在通读它的源码后感叹其平凡之初瞎话说在k8s中还在玩jenkins的就比拟掉队了作为k8s和cicd专家的我 在tekton实战中 开发或者须要留神的点tekton全流水线实战和pipeline运行原理源码解读01 封装几种常见的流水线01 build-push ：只构建并推送镜像02 auth-clone-build-push-apply：新服务 or 同时调整镜像和yaml ，构建+部署yaml+替换image03 auth-set-image：只须要更新镜像版本，测试环境测好的镜像部署到线上04 auth-apply-yaml-image：只须要部署yaml，需替换IMAGE_HOLDER， 比方yaml的日志采集等字段更新了，或者configMap参数变更05 apply一个git仓库中的yaml文件，无需替换IMAGE_HOLDER06 apply-yaml-dir：apply一个git仓库中的目录，目录中有多个yaml文件07 apply一个内部的url对应的yaml文件，如装github上的开源组件08 auth-apply-yaml-image-var : 给须要传额定参数的流水线02 对于镜像的随机标签问题应研发需要，为了避免镜像被净化，在镜像标签中增加工夫和commit字符串增加规定如下: 如果GIT_REVISION为空，分支或tag信息则为master如果GIT_REVISION不为空，分支或tag信息则为对应的传参加分钟级别工夫加commit字符串{IMAGE_BASE_PATH}:{GIT_REVISION}-{date}-{commitid}举例 xxx/web/nignx:v1.2.3-20220512-10-55-c8873a524举例 xxx/web/nignx:master-20220512-11-08-a47ac5b8c03 对应代码仓库须要做的革新应该尽可能的少deployment部署的yaml模板在git仓库中常常须要变更镜像版本的中央 用IMAGE_HOLDER做占位符apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: IMAGE_HOLDER ports: - containerPort: 8004 在cd时应该限度往在线k8s集群公布的权限在须要部署到k8s集群的流水线中增加鉴权步骤，逻辑如下用户须要传参USER_TOKEN如果是部署的指标集群名字中蕴含live，去校验接口验证USER_TOKEN 胜利则放行失败则流水线进行校验接口每隔一段时间生成随机token随机token请找对应的SRE索要：目标就是研发公布的时候要告诉SRE，大家都晓得要往在线集群公布了，防止私下公布或误公布应用admintoken能够通过接口获取随机token，而后填入USER_TOKEN校验即可其它注意事项就不开展了，有问题请购买课程后再答疑对于golang我的项目 go mod 援用公司内其余公有仓库的问题对于habor镜像仓库权限的问题等k8s纯源码解读教程(3个课程内容合成一个大课程)k8s底层原理和源码解说之精髓篇k8s底层原理和源码解说之进阶篇k8s纯源码解读课程，助力你变成k8s专家k8s运维进阶调优课程k8s运维巨匠课程tekton全流水线实战和pipeline运行原理源码解读k8s二次开发课程k8s二次开发之基于实在负载的调度器k8s-operator和crd实战开发 助你成为k8s专家prometheus全组件的教程01_prometheus全组件配置应用、底层原理解析、高可用实战02_prometheus-thanos应用和源码解读03_kube-prometheus和prometheus-operator实战和原理介绍04_prometheus源码解说和二次开发go语言课程golang根底课程golang运维平台实战，服务树,日志监控，工作执行，分布式探测golang运维开发实战课程之k8s巡检平台直播答疑sre职业倒退布局k8s-prometheus课程答疑和运维开发职业倒退布局

大家好，我是张晋涛。 Kubernetes 正式公布了，蕴含了 40 我的项目加强更新。 本次 LOGO 的次要表白的意思是 尊重合作和凋谢的精力 ，这种精力将咱们凝聚到一起转变为能扭转世界的力量。 其实我每期的 「k8s生态周报」都有一个叫上游停顿的局部，所以很多值得关注的内容在之前的文章中曾经发过了。 这篇中我会再额定介绍一些之前未涵盖的，和之前介绍过的值得关注的内容。 core CSI Migration 达到 StableKubernetes 对 CSI 的反对是自 v1.9 开始引入的，到 2019 年的 v1.13 时曾经正式 GA 。最近几个版本中，社区正在将本来的 in-tree 插件逐渐废除或删除，并迁徙至应用 CSI 驱动的形式。 迁徙至应用 CSI 的益处在于，能进步可维护性，并缩小因 in-tree 代码导致的破绽或者谬误的产生。 然而迁徙也并不是间接替换，社区思考到用户的迁徙老本，于是提出了一种解决方案：CSI Migration ，这个计划是将 in-tree API 转换为等效 CSI API，并将操作委托给 CSI 驱动程序的性能。目前该性能达到 GA，in-tree 的迁徙也有很多停顿。 deprecate GlusterFS plugin from available in-tree drivers. by humblec · Pull Request #111485 · kubernetes/kubernetes在这个 PR 中废除了 in-tree 的 GlusterFS 的 plugin，这其实是最早的 dynamic provisioner ，自 Kubernetes v1.4 版本开始引入。 ...

Kubernetes 将本身边界内的事物都形象为资源。其中的次要局部，是以 Deployment、StatefulSet 为代表的 workload 工作负载控制器，其余各类资源都围绕这些次要的资源工作。这些资源合并起来，能够为 IT 技术工作者展现出一个以 workload 为核心的模型。Kubernetes 中所有的资源，都通过申明式配置文件来编辑形容，一条条的 Yaml 字段定义，给了 IT 技术人员最大的自由度的同时，也对技术人员的能力提出了极高的要求。 通过利用模型简化Kubernetes治理当你的团队曾经应用原生的 Kubernetes 一段时间，你多半会发现，并非每个 IT 技术人员都善于编写简单的 Kubernetes 申明式配置文件（YAML）。特地是对于开发人员他们的主要职责是业务开发，学习和编写YAML会减少他们的累赘，甚至会冲突应用。 开源我的项目Rainbond 是一个 云原生利用治理平台，它应用 以利用为核心 的设计模式。基于这一设计模式从新形象出了比 workload 更高层次的利用模型。从应用的体验上不须要学习和编写YAML，实现业务利用的全生命周期治理。利用对应一个残缺的业务零碎，由若干个能够独自治理的服务组件组成，部署业务组件能够从源代码和容器镜像，通过“利落拽”的形式编辑服务调用关系。每一个服务组件，能够基于图形化界面定义应用常见的一些运维特色。在此基础之上，用户还能够利用利用模型这一外围概念，做出更多高级操作，如将整个业务零碎以利用模板的模式公布进去，业务零碎能够基于该模板一键装置/降级。在软件交付这个畛域，这种能力非常有用，无论最终交付环境在线或离线，都能够基于利用模板进行疾速交付，甚至个性化交付。 Rainbond 应用的利用模型，让开发人员关注利用和业务自身，更易于被人所承受。对裁剪后保留下来的运维特色通过图形界面展现和交互，极大的升高了应用的难度，通过利用模版绝大多数开发者不用编辑简单申明式配置文件就能够顺畅应用 Kubernetes 了。 将Kubernetes的YAML转换成利用模型整个转化的过程，能够概括为三个步骤： 对于开发人员最罕用Workload，能够从源码和容器镜像向导式的主动生成，或导入已有YAML和运行利用，导入过程自动识别所有可转化的 Workload 类型资源，包含 Deployment、StatefulSet， Job、CronJob 类型。这些资源会被转化成利用模型，转化后会以服务组件的模式运行。导入生成的服务组件后，根本的Workload属性通过界面就能够查看和编辑，如环境变量、镜像地址等。转化过程中会将辨认到的高级Workload 属性增加给服务组件，以Key/Value 或 Yaml 模式查看和治理。非 Workload 的资源类型，如 Secret、ServiceAccount、Role 等资源，会被分类辨认和加载到利用界面的 k8s资源 页面中，供操作人员以交互体验形式进行编辑。可被纳管和转化的 高级Workload 属性包含： 属性名称作用nodeSelector节点选择器：指定某种类型节点调度时应用。labels标签：用于为服务组件自定义标签以被选择器应用。volumes存储卷：用于定义不被 Rainbond 治理的卷类型的挂载。volumeMounts挂载卷：与 volumes 搭配应用，将卷挂载给容器。affinity亲和性：更高级的调度形式，包含节点亲和性和Pod亲和性。tolerations容忍度：与节点污点搭配应用，具备指定容忍度的Pod才能够调度到指定节点上。serviceAccountName服务账户名：为服务组件指定某个已存在的SA，使对应的Pod具备某些权限。privileged特权模式：货真价实的配置，非必要不开启。env环境变量：用于定义不被 Rainbond 治理的环境变量，反对援用操作。值得注意的是，扩大后的 RAM 模型，仍然可能公布为利用模板，供后续一键装置/降级/交付整套业务零碎之用。 导入已有Kubernetes利用的测试和实际以下测试是基于Rainbond v5.8进行的，为了测试 Kubernetes 已有利用导入，我打算应用曾经在 wp 命名空间中部署实现的 Wordpress 建站零碎来进行一次导入测试。这套零碎由以下资源组成： ...

背景业务开发须要批改pod的内核参数，这些参数被认为是 unsafe 的参数，须要批改kubelet 的 --allowed-unsafe-sysctls 中才能够用，同时要把pod指定调度到这些kubelet被批改过的节点。 在遗记设置节点亲和性或者nodeSelector的状况下，间接批改deployment，会造成什么样的问题。上面通过试验复现一遍。 试验自 k8s 1.12 起，sysctls 个性 beta 并默认开启，容许用户在 pod 的 securityContext 中设置内核参数 apiVersion: apps/v1kind: Deploymentmetadata: name: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: securityContext: sysctls: - name: net.core.somaxconn value: "1024" containers: - name: nginx image: nginx创立deplyemnt后，过五分钟后查看，集群创立了上千个pod $ kubectl get podsNAME READY STATUS RESTARTS AGEnginx-7fbbcfcc7d-4gmrg 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-6dfpm 0/1 SysctlForbidden 0 17snginx-7fbbcfcc7d-6jkdn 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-6mf6z 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-6p2hs 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-cd759 0/1 SysctlForbidden 0 12snginx-7fbbcfcc7d-ckqbl 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-gtvq4 0/1 SysctlForbidden 0 16snginx-7fbbcfcc7d-jbv2p 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-jdh84 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-kmd9p 0/1 SysctlForbidden 0 20snginx-7fbbcfcc7d-lcp6k 0/1 SysctlForbidden 0 15snginx-7fbbcfcc7d-lsdlx 0/1 SysctlForbidden 0 15snginx-7fbbcfcc7d-mbd74 0/1 SysctlForbidden 0 19snginx-7fbbcfcc7d-mbjnf 0/1 SysctlForbidden 0 18snginx-7fbbcfcc7d-mmbj7 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-n2ndn 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-rhjmp 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-rznhl 0/1 SysctlForbidden 0 13snginx-7fbbcfcc7d-sfrl9 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-t9bkk 0/1 SysctlForbidden 0 19snginx-7fbbcfcc7d-vd6x8 0/1 SysctlForbidden 0 17snginx-7fbbcfcc7d-vt2jh 0/1 SysctlForbidden 0 21snginx-7fbbcfcc7d-w4l7n 0/1 SysctlForbidden 0 20snginx-7fbbcfcc7d-w5sgq 0/1 SysctlForbidden 0 14snginx-7fbbcfcc7d-wlf2c 0/1 SysctlForbidden 0 13snginx-7fbbcfcc7d-xh22t 0/1 SysctlForbidden 0 21s解决办法 ...

用过 GitLab 的同学必定也对 GitLab CI/CD 不生疏，GitLab CI/CD 是一个内置在 GitLab 中的工具，它能够帮忙咱们在每次代码推送时运行一系列脚本来构建、测试和验证代码的更改以及部署。 Rainbond 自身默认集成了 CI/CD 的整套流程，用户只需提供源代码，后续构建、运行齐全交给 Rainbond 解决，整个过程是由 Rainbond 定义的，无需用户干涉。这样无利也有弊，利就是简化用户的操作和无需学习 CI/CD 相干常识；弊是用户无奈在 CI/CD 过程中自定义，比方想集成代码检测或运行个脚本，这在 Rainbond 的源码构建流程中是不可自定义的。 本文给大家讲述如何应用 GitLab CI/CD 构建、测试、部署 Spring Boot 利用，将产物运行在 Rainbond 上。 GitLab CI 介绍应用 GitLab CI 须要在仓库根目录下创立 .gitlab-ci.yml 文件。在这个文件中，你能够定义须要运行的编译、测试、部署脚本。 在增加了 .gitlab-ci.yml 文件后，当推送代码时，GitLab Runner 主动执行你定义的 Pipeline，并在 GitLab CI 页面上展现 CI 过程以及后果。 GitLab CI 的根本流程如下： 开发人员推送代码触发 GitLab CI 启动runner 执行预约义脚本 GitLab CI/CD 疾速开始部署 GitLab 和 Runner通过开源利用商店一键部署 GitLab 和 Runner ，新增 -> 基于利用商店创立组件 -> 在开源利用商店中搜寻 GitLab 顺次装置 GitLab 和 Runner 到指定利用中。 ...

装置Minikube并启动一个Kubernetes环境装置docker# 更新源信息sudo apt-get update# 装置必要软件sudo apt-get install ca-certificates curl gnupg lsb-release # 创立keysudo mkdir -p /etc/apt/keyrings# 导入key证书curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg# 写入docker源信息echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null# 设置为国内源sed -i s#download.docker.com#mirrors.ustc.edu.cn/docker-ce#g /etc/apt/sources.list.d/docker.list# 更新源信息并进行装置sudo apt-get updatesudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin# 配置加速器sudo mkdir -p /etc/dockersudo tee /etc/docker/daemon.json <<-'EOF'{ "registry-mirrors": ["https://ted9wxpi.mirror.aliyuncs.com"], "exec-opts": ["native.cgroupdriver=systemd"]}EOFsudo systemctl daemon-reloadsudo systemctl restart docker装置cri-docker# 因为1.24以及更高版本不反对docker所以装置cri-docker# 下载cri-docker wget https://ghproxy.com/https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.5/cri-dockerd-0.2.5.amd64.tgz# 解压cri-dockertar xvf cri-dockerd-0.2.5.amd64.tgz cp cri-dockerd/cri-dockerd /usr/bin/# 写入启动配置文件cat > /usr/lib/systemd/system/cri-docker.service <<EOF[Unit]Description=CRI Interface for Docker Application Container EngineDocumentation=https://docs.mirantis.comAfter=network-online.target firewalld.service docker.serviceWants=network-online.targetRequires=cri-docker.socket[Service]Type=notifyExecStart=/usr/bin/cri-dockerd --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.7ExecReload=/bin/kill -s HUP $MAINPIDTimeoutSec=0RestartSec=2Restart=alwaysStartLimitBurst=3StartLimitInterval=60sLimitNOFILE=infinityLimitNPROC=infinityLimitCORE=infinityTasksMax=infinityDelegate=yesKillMode=process[Install]WantedBy=multi-user.targetEOF# 写入socket配置文件cat > /usr/lib/systemd/system/cri-docker.socket <<EOF[Unit]Description=CRI Docker Socket for the APIPartOf=cri-docker.service[Socket]ListenStream=%t/cri-dockerd.sockSocketMode=0660SocketUser=rootSocketGroup=docker[Install]WantedBy=sockets.targetEOF# 进行启动cri-dockersystemctl daemon-reload ; systemctl enable cri-docker --now装置nimikuber# 下载最新版本kuberctlcurl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl# 下载指定版本kubectlcurl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.0/bin/linux/amd64/kubectl# 设置执行权限chmod +x ./kubectlsudo mv ./kubectl /usr/local/bin/kubectl# 查看版本kubectl version# 下载安装 minikubercurl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube# 装置nimikubersudo mkdir -p /usr/local/bin/sudo install minikube /usr/local/bin/# 配置免密ssh-keygen -t rsassh-copy-id 192.168.1.94# 启动minikuberoot@cby:~# minikube start --driver=docker --container-runtime=containerd --image-mirror-country=cn --force* minikube v1.26.1 on Ubuntu 22.04! minikube skips various validations when --force is supplied; this may lead to unexpected behavior* Using the docker driver based on user configuration* The "docker" driver should not be used with root privileges. If you wish to continue as root, use --force.* If you are running minikube within a VM, consider using --driver=none:* https://minikube.sigs.k8s.io/docs/reference/drivers/none/* Using image repository registry.cn-hangzhou.aliyuncs.com/google_containers* Using Docker driver with root privileges* Starting control plane node minikube in cluster minikube* Pulling base image ... > registry.cn-hangzhou.aliyun...: 386.60 MiB / 386.61 MiB 100.00% 1.37 Mi > registry.cn-hangzhou.aliyun...: 0 B [____________________] ?% ? p/s 4m9s* Creating docker container (CPUs=2, Memory=2200MB) ...* Preparing Kubernetes v1.24.3 on containerd 1.6.6 ... > kubelet.sha256: 64 B / 64 B [-------------------------] 100.00% ? p/s 0s > kubectl.sha256: 64 B / 64 B [-------------------------] 100.00% ? p/s 0s > kubeadm.sha256: 64 B / 64 B [-------------------------] 100.00% ? p/s 0s > kubeadm: 42.32 MiB / 42.32 MiB [--------------] 100.00% 1.36 MiB p/s 31s > kubectl: 43.59 MiB / 43.59 MiB [--------------] 100.00% 1.02 MiB p/s 43s > kubelet: 110.64 MiB / 110.64 MiB [----------] 100.00% 1.36 MiB p/s 1m22s - Generating certificates and keys ... - Booting up control plane ... - Configuring RBAC rules ...* Configuring CNI (Container Networking Interface) ...* Verifying Kubernetes components... - Using image registry.cn-hangzhou.aliyuncs.com/google_containers/storage-provisioner:v5* Enabled addons: storage-provisioner, default-storageclass* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaultroot@cby:~# 验证root@cby:~# kubectl get nodeNAME STATUS ROLES AGE VERSIONminikube Ready control-plane 43s v1.24.3root@cby:~# root@cby:~# kubectl get pod -ANAMESPACE NAME READY STATUS RESTARTS AGEkube-system coredns-7f74c56694-znvr4 1/1 Running 0 31skube-system etcd-minikube 1/1 Running 0 43skube-system kindnet-nt8nf 1/1 Running 0 31skube-system kube-apiserver-minikube 1/1 Running 0 43skube-system kube-controller-manager-minikube 1/1 Running 0 43skube-system kube-proxy-ztq87 1/1 Running 0 31skube-system kube-scheduler-minikube 1/1 Running 0 43skube-system storage-provisioner 1/1 Running 0 41sroot@cby:~# 附录# 若呈现谬误能够做如下操作minikube deleterm -rf .minikube/对于 ...

背景随着云原生技术的风行，越来越多的利用抉择容器化，容器化的话题天然离不开 Kubernetes 。Pod 是 Kubernetes 中创立和治理的、最小的可部署的计算单元，一个 Pod 中有多个容器，容器是一组过程的汇合。当然，容器实质上是 Linux 的 Namespace 和 Ggroups 技术的利用，Namespace 负责资源隔离，Cgroups 负责资源限度。 在应用 Kubernetes 部署利用的过程中，是否有产生这样的疑难：为什么有的pod删除很快，有的pod删除要等很久？容器退出时，认为过程会收到 SIGTERM 信号做优雅退出，后果反而被 SIGKILL 给杀死了？这也是本文想和大家探讨的几个问题。 环境Ubuntu 20.04.2、Kernel 5.4.0-73-generic 、Kubernetes 1.20.7 试验试验代码如下: main.go package mainimport ( "fmt" "os" "os/signal" "syscall")func main() { fmt.Println("app running...") sc := make(chan os.Signal, 1) signal.Notify(sc, syscall.SIGTERM) sig := <-sc fmt.Printf("接管到信号[%s]\n", sig.String()) switch sig { case syscall.SIGTERM: // 开释资源 fmt.Println("优雅退出") }}编译生成二进制用于上面例子中的Dockerfile CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o demoapp main.gostart.sh ...

背景形容 8.25上午10点55分左右，业务反馈测试环境容器平台无法访问，11点17分左右服务复原，查问网关日志，发现容器服务呈现大量504： 网关上游是容器集群ingress，ingress谬误日志有什么线索吗？ 局部业务存在常态化超时状况，临时排除再外不关注。剖析域名发现，不止容器服务超时，还有其余几个服务存在超时景象，谬误日志显示是在建设连贯阶段就超时了（"while connecting to upstream"）。 为什么这些服务忽然大量超时呢？难道是ingress异样了？ 另外，同一时刻还发现间接在节点上执行kubectl命令响应也十分慢，apiserver服务为什么会这么慢呢？依赖的etcd或者本身异样了？容器平台也强依赖apiserver服务，是apiserver的慢导致的容器平台超时吗？那其余几个服务怎么解释呢？ 初步排查 既然kubectl命令响应都十分慢，那先看看apiserver的监控以及日志吧。发现apiserver根本指标cpu、内存、网络等失常，一项指标十分合乎： 留神时区问题，横坐标工夫点+8小时。 指标名称"Work Queue Latency"，提早？是这个问题吗？再看看apiserver的日志，发现居然也存在大量的超时日志： {"log":"E0825 10:56:05.015507 1 controller.go:114] loading OpenAPI spec for \"v1alpha1.proxies.clusternet.io\" failed with: failed to retrieve openAPI spec, http error: ResponseCode: 503, Body: Error trying to reach service: 'dial tcp 10.100.100.223:443: connect: connection timed out', Header: map[Content-Type:[text/plain; charset=utf-8] X-Content-Type-Options:[nosniff]]\n","stream":"stderr","time":"2022-08-25T02:56:05.015718744Z"} 10.x.x.223这个节点是什么呢？貌似是一个serviceip，后端对应哪个服务呢？经查问发现是clusternet-hub，是这个服务导致的吗？ 这里须要阐明下，测试环境容器集群总共有3个master，10.x.x.21/10.x.x.22/10.x.x.23，而且监控显示的指标，以及谬误日志，只存在22、23两个节点。为什么这两个节点有异样，21节点的apiserver却没有任何异样呢？ 另外发现，clusternet-hub只有一个pod，就在10.x.x.21节点。服务依赖如下所示： 感觉特地像是10.x.x.21节点网络故障?这里网络搭档不背锅，不要查不进去就说是网络起因。 ...

二进制装置Kubernetes（k8s） v1.25.0 IPv4/IPv6双栈Kubernetes 开源不易，帮忙点个star，谢谢了 介绍kubernetes（k8s）二进制高可用装置部署，反对IPv4+IPv6双栈。 我应用IPV6的目标是在公网进行拜访，所以我配置了IPV6动态地址。 若您没有IPV6环境，或者不想应用IPv6，不对主机进行配置IPv6地址即可。 不配置IPV6，不影响后续，不过集群仍旧是反对IPv6的。为前期留有扩大可能性。 若不要IPv6 ，不给网卡配置IPv6即可，不要对IPv6相干配置删除或操作，否则会出问题。 https://github.com/cby-chen/K... 手动我的项目地址：https://github.com/cby-chen/K... 脚本我的项目地址：https://github.com/cby-chen/B... 强烈建议在Github上查看文档。Github出问题会更新文档，并且后续尽可能第一工夫更新新版本文档。 1.21.13 和 1.22.10 和 1.23.3 和 1.23.4 和 1.23.5 和 1.23.6 和 1.23.7 和 1.24.0 和 1.24.1 和 1.24.2 和 1.24.3 和 1.25.0 文档以及安装包已生成。 1.环境主机名称IP地址阐明软件Master01192.168.1.61master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-clientMaster02192.168.1.62master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-clientMaster03192.168.1.63master节点kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、kube-proxy、nfs-clientNode01192.168.1.64node节点kubelet、kube-proxy、nfs-clientNode02192.168.1.65node节点kubelet、kube-proxy、nfs-clientNode03192.168.1.66node节点kubelet、kube-proxy、nfs-clientNode04192.168.1.67node节点kubelet、kube-proxy、nfs-clientNode05192.168.1.68node节点kubelet、kube-proxy、nfs-clientLb01192.168.1.70Lb01节点haproxy、keepalivedLb02192.168.1.75Lb02节点haproxy、keepalived 192.168.1.69VIP 软件版本kernel5.18.0-1.el8CentOS 8v8 或者 v7kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxyv1.25.0etcdv3.5.4containerdv1.6.8cfsslv1.6.1cniv1.1.1crictlv1.24.2haproxyv1.8.27keepalivedv2.1.5网段 物理主机：192.168.1.0/24 service：10.96.0.0/12 pod：172.16.0.0/12 安装包曾经整顿好：https://github.com/cby-chen/K... 1.1.k8s根底零碎环境配置1.2.配置IPssh root@192.168.1.100 "nmcli con mod ens18 ipv4.addresses 192.168.1.61/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.106 "nmcli con mod ens18 ipv4.addresses 192.168.1.62/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.110 "nmcli con mod ens18 ipv4.addresses 192.168.1.63/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.114 "nmcli con mod ens18 ipv4.addresses 192.168.1.64/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.115 "nmcli con mod ens18 ipv4.addresses 192.168.1.65/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.116 "nmcli con mod ens18 ipv4.addresses 192.168.1.66/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.117 "nmcli con mod ens18 ipv4.addresses 192.168.1.67/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.118 "nmcli con mod ens18 ipv4.addresses 192.168.1.68/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.156 "nmcli con mod ens18 ipv4.addresses 192.168.1.70/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"ssh root@192.168.1.160 "nmcli con mod ens18 ipv4.addresses 192.168.1.75/24; nmcli con mod ens18 ipv4.gateway 192.168.1.1; nmcli con mod ens18 ipv4.method manual; nmcli con mod ens18 ipv4.dns "8.8.8.8"; nmcli con up ens18"# 没有IPv6抉择不配置即可ssh root@192.168.1.61 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::10; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.62 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::20; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.63 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::30; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.64 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::40; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.65 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::50; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.66 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::60; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.67 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::70; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.68 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::80; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.70 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::90; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"ssh root@192.168.1.75 "nmcli con mod ens18 ipv6.addresses 2408:8207:78cc:5cc1:181c::100; nmcli con mod ens18 ipv6.gateway fe80::2e2:69ff:fe3f:b198; nmcli con mod ens18 ipv6.method manual; nmcli con mod ens18 ipv6.dns "2001:4860:4860::8888"; nmcli con up ens18"1.3.设置主机名hostnamectl set-hostname k8s-master01hostnamectl set-hostname k8s-master02hostnamectl set-hostname k8s-master03hostnamectl set-hostname k8s-node01hostnamectl set-hostname k8s-node02hostnamectl set-hostname k8s-node03hostnamectl set-hostname k8s-node04hostnamectl set-hostname k8s-node05hostnamectl set-hostname lb01hostnamectl set-hostname lb021.4.配置yum源# 对于 CentOS 7sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org|baseurl=https://mirrors.tuna.tsinghua.edu.cn|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于 CentOS 8sudo sed -e 's|^mirrorlist=|#mirrorlist=|g' \ -e 's|^#baseurl=http://mirror.centos.org/$contentdir|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos|g' \ -i.bak \ /etc/yum.repos.d/CentOS-*.repo# 对于公有仓库sed -e 's|^mirrorlist=|#mirrorlist=|g' -e 's|^#baseurl=http://mirror.centos.org/\$contentdir|baseurl=http://192.168.1.123/centos|g' -i.bak /etc/yum.repos.d/CentOS-*.repo1.5.装置一些必备工具yum -y install wget jq psmisc vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 git network-scripts tar curl -y1.6.选择性下载须要工具1.下载kubernetes1.25.+的二进制包github二进制包下载地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.mdwget https://dl.k8s.io/v1.25.0/kubernetes-server-linux-amd64.tar.gz2.下载etcdctl二进制包github二进制包下载地址：https://github.com/etcd-io/etcd/releaseswget https://github.com/etcd-io/etcd/releases/download/v3.5.4/etcd-v3.5.4-linux-amd64.tar.gz3.containerd二进制包下载github下载地址：https://github.com/containerd/containerd/releases4.containerd下载时下载带cni插件的二进制包。wget https://github.com/containerd/containerd/releases/download/v1.6.8/cri-containerd-cni-1.6.8-linux-amd64.tar.gz5.下载cfssl二进制包github二进制包下载地址：https://github.com/cloudflare/cfssl/releaseswget https://github.com/cloudflare/cfssl/releases/download/v1.6.1/cfssl_1.6.1_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.6.1/cfssljson_1.6.1_linux_amd64wget https://github.com/cloudflare/cfssl/releases/download/v1.6.1/cfssl-certinfo_1.6.1_linux_amd646.cni插件下载github下载地址：https://github.com/containernetworking/plugins/releaseswget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-amd64-v1.1.1.tgz7.crictl客户端二进制下载github下载：https://github.com/kubernetes-sigs/cri-tools/releaseswget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.24.2/crictl-v1.24.2-linux-amd64.tar.gz1.7.敞开防火墙systemctl disable --now firewalld1.8.敞开SELinuxsetenforce 0sed -i 's#SELINUX=enforcing#SELINUX=disabled#g' /etc/selinux/config1.9.敞开替换分区sed -ri 's/.*swap.*/#&/' /etc/fstabswapoff -a && sysctl -w vm.swappiness=0cat /etc/fstab# /dev/mapper/centos-swap swap swap defaults 0 01.10.网络配置（俩种形式二选一）# 形式一# systemctl disable --now NetworkManager# systemctl start network && systemctl enable network# 形式二cat > /etc/NetworkManager/conf.d/calico.conf << EOF [keyfile]unmanaged-devices=interface-name:cali*;interface-name:tunl*EOFsystemctl restart NetworkManager1.11.进行工夫同步 (lb除外)# 服务端yum install chrony -ycat > /etc/chrony.conf << EOF pool ntp.aliyun.com iburstdriftfile /var/lib/chrony/driftmakestep 1.0 3rtcsyncallow 10.0.0.0/24local stratum 10keyfile /etc/chrony.keysleapsectz right/UTClogdir /var/log/chronyEOFsystemctl restart chronyd ; systemctl enable chronyd# 客户端yum install chrony -ycat > /etc/chrony.conf << EOF pool 192.168.1.61 iburstdriftfile /var/lib/chrony/driftmakestep 1.0 3rtcsynckeyfile /etc/chrony.keysleapsectz right/UTClogdir /var/log/chronyEOFsystemctl restart chronyd ; systemctl enable chronyd#应用客户端进行验证chronyc sources -v1.12.配置ulimitulimit -SHn 65535cat >> /etc/security/limits.conf <<EOF* soft nofile 655360* hard nofile 131072* soft nproc 655350* hard nproc 655350* seft memlock unlimited* hard memlock unlimiteddEOF1.13.配置免密登录yum install -y sshpassssh-keygen -f /root/.ssh/id_rsa -P ''export IP="192.168.1.61 192.168.1.62 192.168.1.63 192.168.1.64 192.168.1.65 192.168.1.66 192.168.1.67 192.168.1.68 192.168.1.70 192.168.1.75"export SSHPASS=123123for HOST in $IP;do sshpass -e ssh-copy-id -o StrictHostKeyChecking=no $HOSTdone1.14.增加启用源 (lb除外)# 为 RHEL-8或 CentOS-8配置源yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm -y sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo # 为 RHEL-7 SL-7 或 CentOS-7 装置 ELRepo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm -y sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo # 查看可用安装包yum --disablerepo="*" --enablerepo="elrepo-kernel" list available1.15.降级内核至4.18版本以上 (lb除外)# 装置最新的内核# 我这里抉择的是稳定版kernel-ml 如需更新长期保护版本kernel-lt yum --enablerepo=elrepo-kernel install kernel-ml# 查看已装置那些内核rpm -qa | grep kernelkernel-core-4.18.0-358.el8.x86_64kernel-tools-4.18.0-358.el8.x86_64kernel-ml-core-5.16.7-1.el8.elrepo.x86_64kernel-ml-5.16.7-1.el8.elrepo.x86_64kernel-modules-4.18.0-358.el8.x86_64kernel-4.18.0-358.el8.x86_64kernel-tools-libs-4.18.0-358.el8.x86_64kernel-ml-modules-5.16.7-1.el8.elrepo.x86_64# 查看默认内核grubby --default-kernel/boot/vmlinuz-5.16.7-1.el8.elrepo.x86_64# 若不是最新的应用命令设置grubby --set-default /boot/vmlinuz-「您的内核版本」.x86_64# 重启失效reboot# v8 整合命令为：yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm -y ; sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo ; sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo ; yum --disablerepo="*" --enablerepo="elrepo-kernel" list available -y ; yum --enablerepo=elrepo-kernel install kernel-ml -y ; grubby --default-kernel ; reboot # v7 整合命令为：yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm -y ; sed -i "s@mirrorlist@#mirrorlist@g" /etc/yum.repos.d/elrepo.repo ; sed -i "s@elrepo.org/linux@mirrors.tuna.tsinghua.edu.cn/elrepo@g" /etc/yum.repos.d/elrepo.repo ; yum --disablerepo="*" --enablerepo="elrepo-kernel" list available -y ; yum --enablerepo=elrepo-kernel install kernel-ml -y ; grubby --set-default $(ls /boot/vmlinuz-* | grep elrepo) ; grubby --default-kernel ; reboot 1.16.装置ipvsadm (lb除外)yum install ipvsadm ipset sysstat conntrack libseccomp -ycat >> /etc/modules-load.d/ipvs.conf <<EOF ip_vsip_vs_rrip_vs_wrrip_vs_shnf_conntrackip_tablesip_setxt_setipt_setipt_rpfilteript_REJECTipipEOFsystemctl restart systemd-modules-load.servicelsmod | grep -e ip_vs -e nf_conntrackip_vs_sh 16384 0ip_vs_wrr 16384 0ip_vs_rr 16384 0ip_vs 180224 6 ip_vs_rr,ip_vs_sh,ip_vs_wrrnf_conntrack 176128 1 ip_vsnf_defrag_ipv6 24576 2 nf_conntrack,ip_vsnf_defrag_ipv4 16384 1 nf_conntracklibcrc32c 16384 3 nf_conntrack,xfs,ip_vs1.17.批改内核参数 (lb除外)cat <<EOF > /etc/sysctl.d/k8s.confnet.ipv4.ip_forward = 1net.bridge.bridge-nf-call-iptables = 1fs.may_detach_mounts = 1vm.overcommit_memory=1vm.panic_on_oom=0fs.inotify.max_user_watches=89100fs.file-max=52706963fs.nr_open=52706963net.netfilter.nf_conntrack_max=2310720net.ipv4.tcp_keepalive_time = 600net.ipv4.tcp_keepalive_probes = 3net.ipv4.tcp_keepalive_intvl =15net.ipv4.tcp_max_tw_buckets = 36000net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_max_orphans = 327680net.ipv4.tcp_orphan_retries = 3net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 16384net.ipv4.ip_conntrack_max = 65536net.ipv4.tcp_max_syn_backlog = 16384net.ipv4.tcp_timestamps = 0net.core.somaxconn = 16384net.ipv6.conf.all.disable_ipv6 = 0net.ipv6.conf.default.disable_ipv6 = 0net.ipv6.conf.lo.disable_ipv6 = 0net.ipv6.conf.all.forwarding = 1EOFsysctl --system1.18.所有节点配置hosts本地解析cat > /etc/hosts <<EOF127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6# 没有IPv6抉择不配置即可2408:8207:78cc:5cc1:181c::10 k8s-master012408:8207:78cc:5cc1:181c::20 k8s-master022408:8207:78cc:5cc1:181c::30 k8s-master032408:8207:78cc:5cc1:181c::40 k8s-node012408:8207:78cc:5cc1:181c::50 k8s-node022408:8207:78cc:5cc1:181c::60 k8s-node032408:8207:78cc:5cc1:181c::70 k8s-node042408:8207:78cc:5cc1:181c::80 k8s-node052408:8207:78cc:5cc1:181c::90 lb012408:8207:78cc:5cc1:181c::100 lb02192.168.1.61 k8s-master01192.168.1.62 k8s-master02192.168.1.63 k8s-master03192.168.1.64 k8s-node01192.168.1.65 k8s-node02192.168.1.66 k8s-node03192.168.1.67 k8s-node04192.168.1.68 k8s-node05192.168.1.70 lb01192.168.1.75 lb02192.168.1.69 lb-vipEOF2.k8s根本组件装置2.1.所有k8s节点装置Containerd作为Runtime# wget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-amd64-v1.1.1.tgz#创立cni插件所需目录mkdir -p /etc/cni/net.d /opt/cni/bin #解压cni二进制包tar xf cni-plugins-linux-amd64-v1.1.1.tgz -C /opt/cni/bin/# wget https://github.com/containerd/containerd/releases/download/v1.6.6/cri-containerd-cni-1.6.6-linux-amd64.tar.gz#解压tar -xzf cri-containerd-cni-1.6.8-linux-amd64.tar.gz -C /#创立服务启动文件cat > /etc/systemd/system/containerd.service <<EOF[Unit]Description=containerd container runtimeDocumentation=https://containerd.ioAfter=network.target local-fs.target[Service]ExecStartPre=-/sbin/modprobe overlayExecStart=/usr/local/bin/containerdType=notifyDelegate=yesKillMode=processRestart=alwaysRestartSec=5LimitNPROC=infinityLimitCORE=infinityLimitNOFILE=infinityTasksMax=infinityOOMScoreAdjust=-999[Install]WantedBy=multi-user.targetEOF2.1.1配置Containerd所需的模块cat <<EOF | sudo tee /etc/modules-load.d/containerd.confoverlaybr_netfilterEOF2.1.2加载模块systemctl restart systemd-modules-load.service2.1.3配置Containerd所需的内核cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.confnet.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward = 1net.bridge.bridge-nf-call-ip6tables = 1EOF# 加载内核sysctl --system2.1.4创立Containerd的配置文件# 创立默认配置文件mkdir -p /etc/containerdcontainerd config default | tee /etc/containerd/config.toml# 批改Containerd的配置文件sed -i "s#SystemdCgroup\ \=\ false#SystemdCgroup\ \=\ true#g" /etc/containerd/config.tomlcat /etc/containerd/config.toml | grep SystemdCgroupsed -i "s#k8s.gcr.io#registry.cn-hangzhou.aliyuncs.com/chenby#g" /etc/containerd/config.tomlcat /etc/containerd/config.toml | grep sandbox_image2.1.5启动并设置为开机启动systemctl daemon-reloadsystemctl enable --now containerd2.1.6配置crictl客户端连贯的运行时地位# wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.24.2/crictl-v1.24.2-linux-amd64.tar.gz#解压tar xf crictl-v1.24.2-linux-amd64.tar.gz -C /usr/bin/#生成配置文件cat > /etc/crictl.yaml <<EOFruntime-endpoint: unix:///run/containerd/containerd.sockimage-endpoint: unix:///run/containerd/containerd.socktimeout: 10debug: falseEOF#测试systemctl restart containerdcrictl info2.2.k8s与etcd下载及装置（仅在master01操作）2.2.1解压k8s安装包# 下载安装包# wget https://dl.k8s.io/v1.24.2/kubernetes-server-linux-amd64.tar.gz# wget https://github.com/etcd-io/etcd/releases/download/v3.5.4/etcd-v3.5.4-linux-amd64.tar.gz# 解压k8s安装文件cd cbytar -xf kubernetes-server-linux-amd64.tar.gz --strip-components=3 -C /usr/local/bin kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}# 解压etcd安装文件tar -xf etcd*.tar.gz && mv etcd-*/etcd /usr/local/bin/ && mv etcd-*/etcdctl /usr/local/bin/# 查看/usr/local/bin下内容ls /usr/local/bin/containerd containerd-shim-runc-v1 containerd-stress critest ctr etcdctl kube-controller-manager kubelet kube-scheduler containerd-shim containerd-shim-runc-v2 crictl ctd-decoder etcd kube-apiserver kubectl kube-proxy2.2.2查看版本[root@k8s-master01 ~]# kubelet --versionKubernetes v1.25.0[root@k8s-master01 ~]# etcdctl versionetcdctl version: 3.5.4API version: 3.5[root@k8s-master01 ~]# 2.2.3将组件发送至其余k8s节点Master='k8s-master02 k8s-master03'Work='k8s-node01 k8s-node02 k8s-node03 k8s-node04 k8s-node05'for NODE in $Master; do echo $NODE; scp /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} $NODE:/usr/local/bin/; scp /usr/local/bin/etcd* $NODE:/usr/local/bin/; donefor NODE in $Work; do scp /usr/local/bin/kube{let,-proxy} $NODE:/usr/local/bin/ ; donemkdir -p /opt/cni/bin2.3创立证书相干文件mkdir pkicd pkicat > admin-csr.json << EOF { "CN": "admin", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:masters", "OU": "Kubernetes-manual" } ]}EOFcat > ca-config.json << EOF { "signing": { "default": { "expiry": "876000h" }, "profiles": { "kubernetes": { "usages": [ "signing", "key encipherment", "server auth", "client auth" ], "expiry": "876000h" } } }}EOFcat > etcd-ca-csr.json << EOF { "CN": "etcd", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "etcd", "OU": "Etcd Security" } ], "ca": { "expiry": "876000h" }}EOFcat > front-proxy-ca-csr.json << EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "ca": { "expiry": "876000h" }}EOFcat > kubelet-csr.json << EOF { "CN": "system:node:\$NODE", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "L": "Beijing", "ST": "Beijing", "O": "system:nodes", "OU": "Kubernetes-manual" } ]}EOFcat > manager-csr.json << EOF { "CN": "system:kube-controller-manager", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:kube-controller-manager", "OU": "Kubernetes-manual" } ]}EOFcat > apiserver-csr.json << EOF { "CN": "kube-apiserver", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "Kubernetes", "OU": "Kubernetes-manual" } ]}EOFcat > ca-csr.json << EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "Kubernetes", "OU": "Kubernetes-manual" } ], "ca": { "expiry": "876000h" }}EOFcat > etcd-csr.json << EOF { "CN": "etcd", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "etcd", "OU": "Etcd Security" } ]}EOFcat > front-proxy-client-csr.json << EOF { "CN": "front-proxy-client", "key": { "algo": "rsa", "size": 2048 }}EOFcat > kube-proxy-csr.json << EOF { "CN": "system:kube-proxy", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:kube-proxy", "OU": "Kubernetes-manual" } ]}EOFcat > scheduler-csr.json << EOF { "CN": "system:kube-scheduler", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:kube-scheduler", "OU": "Kubernetes-manual" } ]}EOFcd ..mkdir bootstrapcd bootstrapcat > bootstrap.secret.yaml << EOF apiVersion: v1kind: Secretmetadata: name: bootstrap-token-c8ad9c namespace: kube-systemtype: bootstrap.kubernetes.io/tokenstringData: description: "The default bootstrap token generated by 'kubelet '." token-id: c8ad9c token-secret: 2e4d610cf3e7426e usage-bootstrap-authentication: "true" usage-bootstrap-signing: "true" auth-extra-groups: system:bootstrappers:default-node-token,system:bootstrappers:worker,system:bootstrappers:ingress ---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubelet-bootstraproleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:node-bootstrappersubjects:- apiGroup: rbac.authorization.k8s.io kind: Group name: system:bootstrappers:default-node-token---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: node-autoapprove-bootstraproleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:certificates.k8s.io:certificatesigningrequests:nodeclientsubjects:- apiGroup: rbac.authorization.k8s.io kind: Group name: system:bootstrappers:default-node-token---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: node-autoapprove-certificate-rotationroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclientsubjects:- apiGroup: rbac.authorization.k8s.io kind: Group name: system:nodes---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-apiserver-to-kubeletrules: - apiGroups: - "" resources: - nodes/proxy - nodes/stats - nodes/log - nodes/spec - nodes/metrics verbs: - "*"---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: system:kube-apiserver namespace: ""roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:kube-apiserver-to-kubeletsubjects: - apiGroup: rbac.authorization.k8s.io kind: User name: kube-apiserverEOFcd ..mkdir corednscd corednscat > coredns.yaml << EOF apiVersion: v1kind: ServiceAccountmetadata: name: coredns namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: kubernetes.io/bootstrapping: rbac-defaults name: system:corednsrules: - apiGroups: - "" resources: - endpoints - services - pods - namespaces verbs: - list - watch - apiGroups: - discovery.k8s.io resources: - endpointslices verbs: - list - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:corednsroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:corednssubjects:- kind: ServiceAccount name: coredns namespace: kube-system---apiVersion: v1kind: ConfigMapmetadata: name: coredns namespace: kube-systemdata: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop reload loadbalance }---apiVersion: apps/v1kind: Deploymentmetadata: name: coredns namespace: kube-system labels: k8s-app: kube-dns kubernetes.io/name: "CoreDNS"spec: # replicas: not specified here: # 1. Default is 1. # 2. Will be tuned in real time if DNS horizontal auto-scaling is turned on. strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 selector: matchLabels: k8s-app: kube-dns template: metadata: labels: k8s-app: kube-dns spec: priorityClassName: system-cluster-critical serviceAccountName: coredns tolerations: - key: "CriticalAddonsOnly" operator: "Exists" nodeSelector: kubernetes.io/os: linux affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: ["kube-dns"] topologyKey: kubernetes.io/hostname containers: - name: coredns image: registry.cn-beijing.aliyuncs.com/dotbalo/coredns:1.8.6 imagePullPolicy: IfNotPresent resources: limits: memory: 170Mi requests: cpu: 100m memory: 70Mi args: [ "-conf", "/etc/coredns/Corefile" ] volumeMounts: - name: config-volume mountPath: /etc/coredns readOnly: true ports: - containerPort: 53 name: dns protocol: UDP - containerPort: 53 name: dns-tcp protocol: TCP - containerPort: 9153 name: metrics protocol: TCP securityContext: allowPrivilegeEscalation: false capabilities: add: - NET_BIND_SERVICE drop: - all readOnlyRootFilesystem: true livenessProbe: httpGet: path: /health port: 8080 scheme: HTTP initialDelaySeconds: 60 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 readinessProbe: httpGet: path: /ready port: 8181 scheme: HTTP dnsPolicy: Default volumes: - name: config-volume configMap: name: coredns items: - key: Corefile path: Corefile---apiVersion: v1kind: Servicemetadata: name: kube-dns namespace: kube-system annotations: prometheus.io/port: "9153" prometheus.io/scrape: "true" labels: k8s-app: kube-dns kubernetes.io/cluster-service: "true" kubernetes.io/name: "CoreDNS"spec: selector: k8s-app: kube-dns clusterIP: 10.96.0.10 ports: - name: dns port: 53 protocol: UDP - name: dns-tcp port: 53 protocol: TCP - name: metrics port: 9153 protocol: TCPEOFcd ..mkdir metrics-servercd metrics-servercat > metrics-server.yaml << EOF apiVersion: v1kind: ServiceAccountmetadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: k8s-app: metrics-server rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-view: "true" name: system:aggregated-metrics-readerrules:- apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: labels: k8s-app: metrics-server name: system:metrics-serverrules:- apiGroups: - "" resources: - pods - nodes - nodes/stats - namespaces - configmaps verbs: - get - list - watch---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: labels: k8s-app: metrics-server name: metrics-server-auth-reader namespace: kube-systemroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-readersubjects:- kind: ServiceAccount name: metrics-server namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: labels: k8s-app: metrics-server name: metrics-server:system:auth-delegatorroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegatorsubjects:- kind: ServiceAccount name: metrics-server namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: labels: k8s-app: metrics-server name: system:metrics-serverroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:metrics-serversubjects:- kind: ServiceAccount name: metrics-server namespace: kube-system---apiVersion: v1kind: Servicemetadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-systemspec: ports: - name: https port: 443 protocol: TCP targetPort: https selector: k8s-app: metrics-server---apiVersion: apps/v1kind: Deploymentmetadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-systemspec: selector: matchLabels: k8s-app: metrics-server strategy: rollingUpdate: maxUnavailable: 0 template: metadata: labels: k8s-app: metrics-server spec: containers: - args: - --cert-dir=/tmp - --secure-port=4443 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --kubelet-use-node-status-port - --metric-resolution=15s - --kubelet-insecure-tls - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem # change to front-proxy-ca.crt for kubeadm - --requestheader-username-headers=X-Remote-User - --requestheader-group-headers=X-Remote-Group - --requestheader-extra-headers-prefix=X-Remote-Extra- image: registry.cn-beijing.aliyuncs.com/dotbalo/metrics-server:0.5.0 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 3 httpGet: path: /livez port: https scheme: HTTPS periodSeconds: 10 name: metrics-server ports: - containerPort: 4443 name: https protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /readyz port: https scheme: HTTPS initialDelaySeconds: 20 periodSeconds: 10 resources: requests: cpu: 100m memory: 200Mi securityContext: readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 volumeMounts: - mountPath: /tmp name: tmp-dir - name: ca-ssl mountPath: /etc/kubernetes/pki nodeSelector: kubernetes.io/os: linux priorityClassName: system-cluster-critical serviceAccountName: metrics-server volumes: - emptyDir: {} name: tmp-dir - name: ca-ssl hostPath: path: /etc/kubernetes/pki---apiVersion: apiregistration.k8s.io/v1kind: APIServicemetadata: labels: k8s-app: metrics-server name: v1beta1.metrics.k8s.iospec: group: metrics.k8s.io groupPriorityMinimum: 100 insecureSkipTLSVerify: true service: name: metrics-server namespace: kube-system version: v1beta1 versionPriority: 100EOF3.相干证书生成# master01节点下载证书生成工具# wget "https://github.com/cloudflare/cfssl/releases/download/v1.6.1/cfssl_1.6.1_linux_amd64" -O /usr/local/bin/cfssl# wget "https://github.com/cloudflare/cfssl/releases/download/v1.6.1/cfssljson_1.6.1_linux_amd64" -O /usr/local/bin/cfssljson# 软件包内有cp cfssl_1.6.1_linux_amd64 /usr/local/bin/cfsslcp cfssljson_1.6.1_linux_amd64 /usr/local/bin/cfssljsonchmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson3.1.生成etcd证书特地阐明除外，以下操作在所有master节点操作 ...

在云原生趋势下，容器和 Kubernetes 堪称是妇孺皆知，许多企业外部的研发团队都在应用 Kubernetes 打造 DevOps 平台。从最早的容器概念到 Kubernetes 再到 DevOps/GitOps 整个技术链十分宏大，Kubernetes 的劣势也不言而喻 可挪动 可扩大 自修复 等，但有一个劣势点就是技术门槛太高，对于开发者来说单单一个 Kubernetes 就够咱们学习一段时间了。 通常咱们在 Kubernetes 中部署利用须要用 Dockerfile 将业务打成镜像，而后编写 Kubernetes 的 Yaml 部署利用，再联合 Jenkins 的 Pipeline 实现 CI/CD。对于不懂容器的开发者来说，要学习 Dockerfile 语法、K8s Yaml 语法、 Jenkins Pipeline 语法，学习老本有点高。"我还要 Coding 呢！" 本文将别离介绍 如何在 Kubernetes 中部署利用 和 如何在 Rainbond 中部署利用。 在 Kubernetes 中部署利用在 Kubernetes 中部署一个 Nginx 并通过 NodePort 拜访和通过 Ingress 拜访。 创立 nginx-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80创立 nginx-service.yaml，并设置 Service 类型为 NodePortapiVersion: v1kind: Servicemetadata: name: nginx-servicespec: type: NodePort selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30080创立 Nginx Deployment 和 Nginx Service$ kubectl apply -f nginx-deployment.yaml$ kubectl apply -f nginx-service.yaml创立 Ingress 策略apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: nginx-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /spec: ingressClassName: nginx-example rules: - http: paths: - path: / pathType: Prefix backend: service: name: nginx-service port: number: 80kubectl apply -f nginx-ingress.yaml以上就是在 Kubernetes 中部署一个 Nginx 并开启 Nodeport 拜访和 Ingress 拜访的简略示例，这个过程须要了解 K8s 的资源类型 Deployment Service Ingress，以及资源类型之间如何绑定的等等。这仅仅是冰山一角，对于简单的业务须要写多个这样的 Yaml 以及理分明业务之间的依赖关系等。 ...

前言 在本次案例中，咱们的中台技术工程师遇到了来自客户提出的突破k8s产品性能限度的非凡需要，面对这个极具挑战的工作，攻城狮最终是否克服了重重困难，帮忙客户完满实现了需要？且看本期K8S技术案例分享！（情谊提醒：文章篇幅较长，倡议各位看官先珍藏再浏览，同时在浏览过程中留神劳逸结合，放弃身心健康！） 第一局部：“颇有共性”的需要 某日，咱们的技术中台工程师接到了客户的求助。客户在云上环境应用了托管K8S集群产品部署测试集群。因业务须要，研发共事须要在办公网环境能间接拜访K8S集群的clueterIP类型的service和后端的pod。通常K8S的pod只能在集群内通过其余pod或者集群node拜访，不能间接在集群外进行拜访。而pod对集群内外提供服务时须要通过service对外裸露拜访地址和端口，service除了起到pod利用拜访入口的作用，还会对pod的相应端口进行探活，实现健康检查。同时当后端有多个Pod时，service还将依据调度算法将客户端申请转发至不同的pod，实现负载平衡的作用。罕用的service类型有如下几种： clusterIP类型，创立service时如果不指定类型的话的默认会创立该类型service： service类型简介 clusterIP类型创立service时如果不指定类型的话的默认会创立该类型service，clusterIP类型的service只能在集群内通过cluster IP被pod和node拜访，集群外无法访问。通常像K8S集群零碎服务kubernetes等不须要对集群外提供服务，只须要在集群外部进行拜访的service会应用这种类型； nodeport类型为了解决集群内部对service的拜访需要，设计了nodeport类型，将service的端口映射至集群每个节点的端口上。当集群外拜访service时，通过对节点IP和指定端口的拜访，将申请转发至后端pod；loadbalancer类型该类型通常须要调用云厂商的API接口，在云平台上创立负载平衡产品，并依据设置创立监听器。在K8S外部，loadbalancer类型服务实际上还是和nodeport类型一样将服务端口映射至每个节点的固定端口上。而后将节点设置为负载平衡的后端，监听器将客户端申请转发至后端节点上的服务映射端口，申请达到节点端口后，再转发至后端pod。Loadbalancer类型的service补救了nodeport类型有多个节点时客户端须要拜访多个节点IP地址的有余，只有对立拜访LB的IP即可。同时应用LB类型的service对外提供服务，K8S节点无需绑定公网IP，只须要给LB绑定公网IP即可，晋升了节点安全性，也节约了公网IP资源。利用LB对后端节点的健康检查性能，可实现服务高可用。防止某个K8S节点故障导致服务无法访问。小结 通过对K8S集群service类型的理解，咱们能够晓得客户想在集群外对service进行拜访，首先举荐应用的是LB类型的service。因为目前K8S集群产品的节点还不反对绑定公网IP，因而应用nodeport类型的service无奈实现通过公网拜访，除非客户应用专线连贯或者IPSEC将本人的办公网与云上网络买通，能力拜访nodeport类型的service。而对于pod，只能在集群外部应用其余pod或者集群节点进行拜访。同时K8S集群的clusterIP和pod设计为不容许集群内部拜访，也是出于进步安全性的思考。如果将拜访限度突破，可能会导致平安问题产生。所以咱们的倡议客户还是应用LB类型的service对外裸露服务，或者从办公网连贯K8S集群的NAT主机，而后通过NAT主机能够连贯至K8S节点，再拜访clusterIP类型的service，或者拜访后端pod。 客户示意目前测试集群的clusterIP类型服务有上百个，如果都革新成LB类型的service就要创立上百个LB实例，绑定上百个公网IP，这显然是不事实的，而都革新成Nodeport类型的service的工作量也非常微小。同时如果通过NAT主机跳转登录至集群节点，就须要给研发共事给出NAT主机和集群节点的零碎明码，不利于运维治理，从操作便利性上也不如研发能够间接通过网络拜访service和pod简便。 第二局部：办法总比艰难多？ 尽管客户的拜访形式违反了K8S集群的设计逻辑，显得有些“非主流”，然而对于客户的应用场景来说也是无可奈何的强需要。作为技术中台的攻城狮，咱们要尽最大致力帮忙客户解决技术问题！因而咱们依据客户的需要和场景架构，来布局实现计划。 既然是网络买通，首先要从客户的办公网和云上K8S集群网络架构剖析。客户办公网有对立的公网进口设施，而云上K8S集群的网络架构如下，K8S集群master节点对用户不可见，用户创立K8S集群后，会在用户选定的VPC网络下创立三个子网。别离是用于K8S节点通信的node子网，用于部署NAT主机和LB类型serivce创立的负载平衡实例的NAT与LB子网，以及用于pod通信的pod子网。K8S集群的节点搭建在云主机上，node子网拜访公网地址的路由下一跳指向NAT主机，也就是说集群节点不能绑定公网IP，应用NAT主机作为对立的公网拜访进口，做SNAT，实现公网拜访。因为NAT主机只有SNAT性能，没有DNAT性能，因而也就无奈从集群外通过NAT主机拜访node节点。 对于pod子网的布局目标，首先要介绍下pod在节点上的网络架构。如下图所示： 在节点上，pod中的容器通过veth对与docker0设施连通，而docker0与节点的网卡之间通过自研CNI网络插件连通。为了实现集群管制流量与数据流量的拆散，进步网络性能，集群在每个节点上独自绑定弹性网卡，专门供pod通信应用。创立pod时，会在弹性网卡上为Pod调配IP地址。每个弹性网卡最多能够调配21个IP，当一张弹性网卡上的IP调配满后，会再绑定一张新的网卡供后续新建的pod应用。弹性网卡所属的子网就是pod子网，基于这样的架构，能够升高节点eth0主网卡的负载压力，实现管制流量与数据流量拆散，同时pod的IP在VPC网络中有理论对应的网络接口和IP，可实现VPC网络内对pod地址的路由。 你须要理解的买通形式理解完两端的网络架构后咱们来抉择买通形式。通常将云下网络和云上网络买通，有专线产品连贯形式，或者用户自建VPN连贯形式。专线产品连贯须要布设从客户办公网到云上机房的网络专线，而后在客户办公网侧的网络进口设施和云上网络侧的bgw边界网关配置到彼此对端的路由。如下图所示： 基于现有专线产品BGW的性能限度，云上一侧的路由只能指向K8S集群所在的VPC，无奈指向具体的某个K8S节点。而想要拜访clusterIP类型service和pod，必须在集群内的节点和pod拜访。因而拜访service和pod的路由下一跳，必须是某个集群节点。所以应用专线产品显然是无奈满足需要的。 咱们来看自建VPN形式，自建VPN在客户办公网和云上网络各有一个有公网IP的端点设施，两个设施之间建设加密通信隧道，理论底层还是基于公网通信。如果应用该计划，云上的端点咱们能够抉择和集群节点在同一VPC的不同子网下的有公网IP的云主机。办公网侧对service和pod的拜访数据包通过VPN隧道发送至云主机后，能够通过配置云主机所在子网路由，将数据包路由至某个集群节点，而后在集群节点所在子网配置到客户端的路由下一跳指向端点云主机，同时须要在pod子网也做雷同的路由配置。至于VPN的实现形式，通过和客户沟通，咱们选取ipsec隧道形式。 确定了计划，咱们须要在测试环境实施方案验证可行性。因为咱们没有云下环境，因而选取和K8S集群不同地区的云主机代替客户的办公网端点设施。在华东上海地区创立云主机office-ipsec-sh模仿客户办公网客户端，在华北北京地区的K8S集群K8S-BJTEST01所在VPC的NAT/LB子网创立一个有公网IP的云主机K8S-ipsec-bj，模仿客户场景下的ipsec云上端点，与华东上海云主机office-ipsec-sh建设ipsec隧道。设置NAT/LB子网的路由表，增加到service网段的路由下一跳指向K8S集群节点k8s-node-vmlppp-bs9jq8pua，以下简称node A。因为pod子网和NAT/LB子网同属于一个VPC，所以无需配置到pod网段的路由，拜访pod时会间接匹配local路由，转发至对应的弹性网卡上。为了实现数据包的返回，在node子网和pod子网别离配置到上海云主机office-ipsec-sh的路由，下一跳指向K8S-ipsec-bj。残缺架构如下图所示： 第三局部：实际出“问题” 既然确定了计划，咱们就开始搭建环境了。首先在K8S集群的NAT/LB子网创立k8s-ipsec-bj云主机，并绑定公网IP。而后与上海云主机office-ipsec-sh建设ipsec隧道。对于ipsec局部的配置办法网络上有很多文档，在此不做具体叙述，有趣味的童鞋能够参照文档本人实际下。隧道建设后，在两端互ping对端的内网IP，如果能够ping通的话，证实ipsec工作失常。依照布局配置好NAT/LB子网和node子网以及pod子网的路由。咱们在k8s集群的serivce中，抉择一个名为nginx的serivce，clusterIP为10.0.58.158，如图所示： 该服务后端的pod是10.0.0.13，部署nginx默认页面，并监听80端口。在上海云主机上测试ping service的IP 10.0.58.158，能够ping通，同时应用paping工具ping服务的80端口，也能够ping通！ 应用curl http://10.0.58.158进行http申请，也能够胜利！ 再测试间接拜访后端pod，也没有问题:) 正当攻城狮心里美滋滋，认为所有都功败垂成的时候，测试拜访另一个service的后果犹如一盆冷水泼来。咱们接着选取了mysql这个service，测试拜访3306端口。该serivce的clusterIP是10.0.60.80，后端pod的IP是10.0.0.14 在上海云主机间接ping service的clusterIP，没有问题。然而paping 3306端口的时候，竟然不通了！ 而后咱们测试间接拜访serivce的后端pod，诡异的是，后端pod无论是ping IP还是paping 3306端口，都是能够连通的！ 肿么回事？这是肿么回事？ 通过攻城狮一番比照剖析，发现两个serivce惟一的不同是，能够连通nginx服务的后端pod 10.0.0.13就部署在客户端申请转发到的node A上。而不能连通的mysql服务的后端pod不在node A上，在另一个节点上。 为了验证问题起因是否就在于此，咱们独自批改NAT/LB子网路由，到mysql服务的下一跳指向后端pod所在的节点。而后再次测试。果然！当初能够拜访mysql服务的3306端口了！ **探索起因第四局部：三个为什么？** 此时此刻，攻城狮的心中有三个疑难：（1）为什么申请转发至service后端pod所在的节点时能够连通？（2）为什么申请转发至service后端pod不在的节点时不能连通？（3）为什么不论转发至哪个节点，service的IP都能够ping通？ 深入分析，打消问号为了打消咱们心中的小问号，咱们就要深入分析，理解导致问题的起因，而后再隔靴搔痒。既然要排查网络问题，当然还是要祭出经典法宝——tcpdump抓包工具。为了把焦点集中，咱们对测试环境的架构进行了调整。上海到北京的ipsec局部维持现有架构不变，咱们对K8S集群节点进行扩容，新建一个没有任何pod的空节点k8s-node-vmcrm9-bst9jq8pua，以下简称node B，该节点只做申请转发。批改NAT/LB子网路由，拜访service地址的路由下一跳指向该节点。测试的service咱们选取之前应用的nginx服务10.0.58.158和后端pod 10.0.0.13，如下图所示： 当须要测试申请转发至pod所在节点的场景时，咱们将service路由下一跳批改为k8s-node-A即可。 万事俱备，让咱们开启解惑之旅！Go Go Go! 首先探索疑难1场景，咱们在k8s-node-A上执行命令抓取与上海云主机172.16.0.50的包，命令如下：tcpdump -i any host 172.16.0.50 -w /tmp/dst-node-client.cap 各位童鞋是否还记得咱们之前提到过，在托管K8S集群中，所有pod的数据流量均通过节点的弹性网卡收发？ ...

sealos 是一款云操作系统发行版，能够非常简单的治理 kubernetes 的生命周期，以及像应用 win11 一样应用云，最近写 sealos cloud 的领取模块，发现能够通过命令行做微信领取，十分有意思，当初和大家分享一下如何做到的。 输出一条命令，终端会输入二维码，间接微信扫一扫就能够付钱，这对于极客来说真是福音，对于一个蔑视应用 GUI 的人来说岂不是很香？为了站在鄙视链顶端（API 鄙视 as code 鄙视 CLI 鄙视 GUI）岂能不反对这么酷的个性～ 应用场景： 想想你充爱奇艺会员的时候咔敲个命令，扫一扫搞定，女朋友在旁边不得亚麻呆住？想想当初很多屎山一样的前端页面，半天都找不到按钮在哪，一条命令充值岂不是很酸爽？想想你执行一个命令忽然提醒欠费蹦出个二维码让你充值执行想想数据库备份日志显示一个二维码，扫码持续备份上面开始教程： 应用微信 native 领取形式native 领取会向微信领取服务发送一条申请，微信领取会返回一个 codeurl, 间接把这个 codeurl 转化成二维码，即可用微信扫描领取。 咱们本人服务端写一个获取 code-url 的接口： ws.Route(ws.GET("/wechat/code-url").To(u.getCodeURL)func (u Payment) getCodeURL(request *restful.Request, response *restful.Response) {amount := request.QueryParameter("amount") user := request.QueryParameter("user") a, err := strconv.Atoi(amount) codeURL, err := WechatPay(int64(a), user, "", "", os.Getenv(CallbackURL)) _, err = response.Write([]byte(codeURL))}这里获取谁（user）充值多少 (amout) 钱, (省去了非核心逻辑) 领取申请实现： func WechatPay(amount int64, user, tradeNO, describe, callback string) (string, error) { mchID := os.Getenv(MchID) // 商户号 mchCertificateSerialNumber := os.Getenv(MchCertificateSerialNumber) // 商户证书序列号 mchAPIv3Key := os.Getenv(MchAPIv3Key) // 商户APIv3密钥 mchPrivateKey, err := utils.LoadPrivateKey(os.Getenv(WechatPrivateKey)) ctx := context.Background() opts := []core.ClientOption{ option.WithWechatPayAutoAuthCipher(mchID, mchCertificateSerialNumber, mchPrivateKey, mchAPIv3Key), } client, err := core.NewClient(ctx, opts...) svc := native.NativeApiService{Client: client} resp, _, err := svc.Prepay(ctx, native.PrepayRequest{ Appid: core.String(os.Getenv(AppID)), Mchid: core.String(os.Getenv(MchID)), Description: core.String(describe), OutTradeNo: core.String(tradeNO), TimeExpire: core.Time(time.Now()), Attach: core.String(user), NotifyUrl: core.String(callback), GoodsTag: core.String("sealos recharge"), SupportFapiao: core.Bool(false), Amount: &native.Amount{ Currency: core.String("CNY"), Total: core.Int64(amount), }, Detail: &native.Detail{ CostPrice: core.Int64(608800), GoodsDetail: []native.GoodsDetail{ { GoodsName: core.String("sealos cloud recharge"), MerchantGoodsId: core.String("ABC"), Quantity: core.Int64(1), UnitPrice: core.Int64(828800), WechatpayGoodsId: core.String("1001"), }}, }, SettleInfo: &native.SettleInfo{ ProfitSharing: core.Bool(false), }, }, ) return *resp.CodeUrl, nil}此接口会返回这样的一个字符串，也就是咱们须要转化成二维码的： ...

降级二进制kubernetes集群背景介绍最近因为工夫有余，临时无奈对小版本更新第一工夫出新的文档。若须要降级集群版本，能够参考此文档进行操作，每个节点一个一个的更新。大版本更新请各位继续关注我的Github我的项目仓库。后续更新会在仓库继续更新。感激各位小伙伴始终以来的反对。 此文档基于我的二进制装置仓库 https://github.com/cby-chen/K... 根底操作查看以后版本信息[root@k8s-master01 ~]# kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-master01 Ready <none> 57d v1.23.6k8s-master02 Ready <none> 57d v1.23.6k8s-master03 Ready <none> 57d v1.23.6k8s-node01 Ready <none> 57d v1.23.6k8s-node02 Ready <none> 57d v1.23.6[root@k8s-master01 ~]#主机域名以及IP地址[root@k8s-master01 ~]# cat /etc/hosts | grep k8s192.168.1.230 k8s-master01192.168.1.231 k8s-master02192.168.1.232 k8s-master03192.168.1.233 k8s-node01192.168.1.234 k8s-node02[root@k8s-master01 ~]#下载二进制安装包[root@k8s-master01 ~]# wget https://dl.k8s.io/v1.23.9/kubernetes-server-linux-amd64.tar.gz[root@k8s-master01 ~]#解压二进制安装包[root@k8s-master01 ~]# tar xf kubernetes-server-linux-amd64.tar.gz[root@k8s-master01 ~]# 降级Maser降级三台主节点上的客户端[root@k8s-master01 ~]# scp kubernetes/server/bin/kubectl root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kubectl root@192.168.1.231:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kubectl root@192.168.1.232:/usr/local/bin/[root@k8s-master01 ~]#降级三台主节点api组件[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl stop kube-apiserver"[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kube-apiserver root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl start kube-apiserver"[root@k8s-master01 ~]#[root@k8s-master01 ~]# kube-apiserver --versionKubernetes v1.23.9[root@k8s-master01 ~]#降级三台主节点控制器组件[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl stop kube-controller-manager"[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kube-controller-manager root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl start kube-controller-manager"[root@k8s-master01 ~]#降级三台主节点选择器组件[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl stop kube-scheduler"[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kube-scheduler root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl start kube-scheduler"[root@k8s-master01 ~]#降级Worker每一台机器都要降级kubelet[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl stop kubelet"[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kubelet root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl start kubelet"[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "kubelet --version"Kubernetes v1.23.9[root@k8s-master01 ~]#每一台机器都要降级kube-proxy[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl stop kube-proxy"[root@k8s-master01 ~]#[root@k8s-master01 ~]# scp kubernetes/server/bin/kube-proxy root@192.168.1.230:/usr/local/bin/[root@k8s-master01 ~]#[root@k8s-master01 ~]# ssh root@192.168.1.230 "systemctl start kube-proxy"[root@k8s-master01 ~]#验证[root@k8s-master01 ~]# kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-master01 Ready <none> 57d v1.23.9k8s-master02 Ready <none> 57d v1.23.9k8s-master03 Ready <none> 57d v1.23.9k8s-node01 Ready <none> 57d v1.23.9k8s-node02 Ready <none> 57d v1.23.9[root@k8s-master01 ~]#[root@k8s-master01 ~]# kubectl versionClient Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.9", GitCommit:"c1de2d70269039fe55efb98e737d9a29f9155246", GitTreeState:"clean", BuildDate:"2022-07-13T14:26:51Z", GoVersion:"go1.17.11", Compiler:"gc", Platform:"linux/amd64"}Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.9", GitCommit:"c1de2d70269039fe55efb98e737d9a29f9155246", GitTreeState:"clean", BuildDate:"2022-07-13T14:19:57Z", GoVersion:"go1.17.11", Compiler:"gc", Platform:"linux/amd64"}[root@k8s-master01 ~]#对于 ...

什么是 Kubernetes?Kubernetes 是一个可移植、可扩大的开源平台，用于治理容器化工作负载和服务，有助于申明式配置和自动化。它领有宏大且疾速倒退的生态系统。Kubernetes 服务、反对和工具宽泛可用。 Kubernetes 这个名字来源于希腊语，意思是舵手或飞行员。K8s 作为一个缩写，是通过计算“K”和“s”之间的八个字母得出的。Google 于 2014 年开源了 Kubernetes 我的项目。当初各大厂商都在进行容器化革新，那么为什么抉择kubernetes，那它能做什么呢？有什么用呢？上面详解： 为什么须要 Kubernetes 以及它能够做什么容器是捆绑和运行应用程序的好办法。在生产环境中，您须要治理运行应用程序的容器并确保没有停机。例如，如果一个容器呈现故障，则须要启动另一个容器。如果这种行为由零碎解决，会不会更容易？ 这就是 Kubernetes 来救济的形式！Kubernetes 为您提供了一个框架来弹性地运行分布式系统。它负责您的应用程序的扩大和故障转移，提供部署模式等等。例如，Kubernetes 能够轻松地为您的系统管理金丝雀部署。 Kubernetes： 服务发现和负载平衡 Kubernetes 能够应用 DNS 名称或应用本人的 IP 地址公开容器。如果容器的流量很高，Kubernetes 可能负载平衡和调配网络流量，从而使部署稳固。主动推出和回滚 您能够应用 Kubernetes 形容已部署容器的所需状态，它能够以受控的速率将理论状态更改为所需状态。例如，您能够自动化 Kubernetes 为您的部署创立新容器、删除现有容器并将其所有资源用于新容器。存储编排 Kubernetes 容许您主动挂载您抉择的存储系统，例如本地存储、公共云提供商等。主动装箱 你为 Kubernetes 提供了一个节点集群，它能够用来运行容器化的工作。你通知 Kubernetes 每个容器须要多少 CPU 和内存 (RAM)。Kubernetes 能够将容器装置到您的节点上，以充分利用您的资源。自我修复 Kubernetes 会重新启动失败的容器、替换容器、杀死不响应用户定义的健康检查的容器，并且在它们筹备好服务之前不会将它们通告给客户端。机密和配置管理 Kubernetes 容许您存储和治理敏感信息，例如明码、OAuth 令牌和 SSH 密钥。您能够部署和更新秘密和应用程序配置，而无需从新构建容器映像，也无需在堆栈配置中公开秘密。Kubenetes的架构图一个kubernetes集群都至多由一个Master节点和若干个Node节点组成。 Master节点是集群管制节点，负责整个集群的治理和管制，基本上Kubernetes所有的管制命令都是发给它，它来负责具体的执行过程。 因为Master节点的重要性，它通常会独占一个物理机或虚拟机。 Master节点外的其它机器被称为Node节点，Node节点是集群中的工作负载节点，每个Node都会被Master调配一些工作负载（如Docker容器），当某个Node宕机时，其工作负载会被Master主动转移到其余节点上。 Kubernetes术语理念Mashi ter节点组件提供整个集群的控制面板： kube-apiserver: 裸露API操作接口，是kubernetes外面所有资源增，删，改，查等操作的惟一入口；也是集群管制的入口。etcd: 集群的主数据库，集群外面的所有数据都存储于此。kube-controller-manager: kubernetes里所有资源对象的自动化控制中心， 控制器的大管家。kube-scheduler: 负责资源调度（Pod调度）的过程，为新创建的Pod调配Node节点去运行。Node节点组件维持Pods的运行： kubelet: 负责Pod对应容器的创立，启动，进行等工作； 同时与Master节点密切协作，实现集群治理的基本功能。kube-proxy: 实现Service的通信和负载平衡机制的重要组件。docker: docker引擎，负责本节点的容器创立和管理工作。supervisord: 过程监控，放弃kubelet和docker的失常运行。fluentd: 日志收集 kubernetes集群中的对象或资源 ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 本周事件比拟多，闲暇工夫根本都在关注上游的停顿，没折腾其余的货色。Kubernetes v1.25 失常状况下会在本月公布正式版本。 我来介绍一些本周关注到比拟值得注意的内容： 上游停顿deprecate GlusterFS plugin from available in-tree drivers. by humblec · Pull Request #111485 · kubernetes/kubernetes在这个 PR 中废除了 in-tree 的 GlusterFS 的 plugin，这其实是最早的 dynamic provisioner ，自 Kubernetes v1.4 版本开始引入。 在起初 CSI 驱动呈现的时候，社区中也立即呈现了对应的驱动实现 https://github.com/gluster/gl... ，只不过该我的项目并没有踊跃的进行保护。当初还有另一个比拟举荐的代替计划，能够思考应用 https://github.com/kadalu/kad... 此我的项目最新的版本为 v0.8.15 。 通过社区之前的探讨，还是决定在 v1.25 版本开始将 in-tree 的 GlusterFS plugin 标记为废除，并在后续的版本中进行移除。 如果有正在应用此插件的小伙伴，我倡议能够尽早的评估 kadalu 的可行性 & 迁徙老本。 此外， 这个批改属于齐全删除 in-tree 卷插件的一部分，无论你在应用哪种 in-tree 的卷插件，倡议尽早迁徙至应用 CSI 驱动的模式。 Add shell completion for new --subresource flag by marckhouzam · Pull Request #109070 · kubernetes/kubernetes在 Kubernetes v1.24 中，给 kubectl 减少了 subresource 的反对（指 status 和 scale），这样就能够很不便的间接对 subresource 进行操作了，而不须要每次都 -o yaml 之类的间接进行查看，或者通过 curl 之类的调用 API 来实现其余操作。应用了此个性后，能够有如下成果： ...

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。大家好，我是张晋涛。 本周同样是繁忙的一周，一个教训分享给大家，优先答复问题而非解释细节。这也就是为什么我常常在文章的结尾都会先阐明下文章次要涵盖的内容，这样有助于节省时间。 我本周闲暇工夫根本都在关注上游的停顿，没空折腾其余的货色。Kubernetes v1.25.0-rc.0 已于本周公布，失常状况下会在本月公布正式版本。 我来介绍一些本周关注到比拟值得注意的内容： 上游停顿Add support for user namespaces phase 1 (KEP 127) by rata · Pull Request #111090 · kubernetes/kubernetes这个 PR 实现了 KEP127 的第一阶段，KEP127 旨在为 Pod 增加 user namespaces 的反对。对 user namespaces 不太熟悉的小伙伴，能够看看我之前的系列文章：《搞懂容器技术的基石： namespace （上）》 和 《搞懂容器技术的基石： namespace （下）》 。 在 Kubernetes 中反对应用 user namespaces 的益处在于，能够在与主机有不同 UID/GID 的 Pod 中运行过程，这样在 Pod 内的特权过程理论是作为主机中的一般过程运行的。这样，假如 Pod 内的特权过程因为安全漏洞被攻破，对主机的影响也能够降到比拟低。 间接相干的破绽，比方 CVE-2019-5736 ，我也曾在 2019 年的文章 《runc 1.0-rc7 公布之际》 专门介绍过，感兴趣的小伙伴能够到该文章中理解详情。 ...

先装置k8s华为云arm架构装置k8s(kubernetes)") 下载kubeedge须要的软件官网github下载kubeedge地址 cloudcore.service文件下载地址 留神:下载对应的版本和arm架构keadm-v1.6.1-linux-arm64.tar.gz上面的2个文件能够不必下载,装置kubeedge时也会主动去下载到/etc/kubeedge/目录,我这里在线github下载很慢,所以提前下载好kubeedge-v1.6.1-linux-arm64.tar.gzcloudcore.service 如果github拜访不了,或者太慢,应用上面我下载好的地址去下载:百度网盘下载地址链接: https://pan.baidu.com/s/11186... 明码: q72v #查看Linux内核版本uname -r 4.18.0-80.7.2.el7.aarch64#或者应用 uname -a#创立文件夹mkdir /etc/kubeedge/#把下载的软件复制到/etc/kubeedge/目录,能够不下载这2个文件,装置时会主动从github上下载到/etc/kubeedge/目录cp kubeedge-v1.6.1-linux-arm64.tar.gz /etc/kubeedge/cp cloudcore.service /etc/kubeedge/ 装置kubeedge的cloudcore--advertise-address="116.0.0.123" kubeedge的cloudcore的IP,edge边缘节点能拜访的IP,如果公网拜访,倡议应用外网IP--kubeedge-version=1.6.1 kubeedge的版本,会去下载指定版本的kubeedge包 #解压keadmtar -zxvf keadm-v1.6.1-linux-arm64.tar.gz#初始化装置kubeedge的cloudcore./keadm-v1.6.1-linux-arm64/keadm/keadm init --advertise-address="116.0.0.123" --kubeedge-version=1.6.1#输入如下信息胜利:version=1.6.1Kubernetes version verification passed, KubeEdge installation will start...W0511 14:35:30.146678 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.154102 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.159650 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionW0511 14:35:30.164732 3524 warnings.go:67] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionExpected or Default KubeEdge version 1.6.1 is already downloaded and will checksum for it. kubeedge-v1.6.1-linux-arm64.tar.gz checksum: checksum_kubeedge-v1.6.1-linux-arm64.tar.gz.txt content: Expected or Default KubeEdge version 1.6.1 is already downloaded[Run as service] start to download service file for cloudcore[Run as service] success to download service file for cloudcorekubeedge-v1.6.1-linux-arm64/kubeedge-v1.6.1-linux-arm64/edge/kubeedge-v1.6.1-linux-arm64/edge/edgecorekubeedge-v1.6.1-linux-arm64/cloud/kubeedge-v1.6.1-linux-arm64/cloud/csidriver/kubeedge-v1.6.1-linux-arm64/cloud/csidriver/csidriverkubeedge-v1.6.1-linux-arm64/cloud/admission/kubeedge-v1.6.1-linux-arm64/cloud/admission/admissionkubeedge-v1.6.1-linux-arm64/cloud/cloudcore/kubeedge-v1.6.1-linux-arm64/cloud/cloudcore/cloudcorekubeedge-v1.6.1-linux-arm64/versionKubeEdge cloudcore is running, For logs visit: /var/log/kubeedge/cloudcore.logCloudCore started#查看cloudcore的日志vim /var/log/kubeedge/cloudcore.log配置cloudcore开机自启动服务#查看cloudcore启动状况ps aux|grep cloudcore#输入如下示意启动:root 23498 0.1 0.3 1012544 48640 ? Ssl May12 13:11 /usr/local/bin/cloudcore#查看端口 10000 10002 端口都有了netstat -tpnl#如下:tcp6 0 0 :::10000 :::* LISTEN 23498/cloudcore tcp6 0 0 :::10002 :::* LISTEN 23498/cloudcore #查看cloudcore启动状态systemctl status cloudcore#如果没有设置开机启动服务则设置 复制开启自启动服务文件cp /etc/kubeedge/cloudcore.service /etc/systemd/system/cloudcore.service#增加文件权限chmod +x /etc/systemd/system/cloudcore.service#从新加载配置文件systemctl daemon-reload#查看cloudcore启动的过程id,而后杀掉ps aux|grep cloudcore#输入如下:root 23498 0.1 0.3 1012544 48640 ? Ssl May12 13:12 /usr/local/bin/cloudcore#杀掉kill -9 23498#启动cloudcoresystemctl start cloudcore#设置开机自启动systemctl enable cloudcore.service#查看cloudcore开机启动状态 enabled:开启, disabled:敞开systemctl is-enabled cloudcore.service获取kubeedge的token./keadm-v1.6.1-linux-arm64/keadm/keadm gettoken

先装置Docker华为云arm架构装置Docker 设置主机名称#查看Linux内核版本uname -r 4.18.0-80.7.2.el7.aarch64#或者应用 uname -a#设置主机名称为k8s-master,从新连贯显示失效hostnamectl --static set-hostname k8s-master#查看主机名称hostname配置k8s的yum源 arm64的源cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF#革除缓存yum clean all#把服务器的包信息下载到本地电脑缓存起来，makecache建设一个缓存yum makecache#列出kubectl可用的版本yum list kubectl --showduplicates | sort -r#列出信息如下:Loading mirror speeds from cached hostfileLoaded plugins: fastestmirrorkubectl.aarch64 1.9.9-0 kubernetes kubectl.aarch64 1.9.8-0 kubernetes kubectl.aarch64 1.9.7-0 kubernetes kubectl.aarch64 1.9.6-0 kubernetes kubectl.aarch64 1.9.5-0 kubernetes kubectl.aarch64 1.9.4-0 kubernetes kubectl.aarch64 1.9.3-0 kubernetes kubectl.aarch64 1.9.2-0 kubernetes kubectl.aarch64 1.9.11-0 kubernetes kubectl.aarch64 1.9.1-0 kubernetes kubectl.aarch64 1.9.10-0 kubernetes kubectl.aarch64 1.9.0-0 kubernetes kubectl.aarch64 1.8.9-0 kubernetes kubectl.aarch64 1.8.8-0 kubernetes kubectl.aarch64 1.8.7-0 kubernetes kubectl.aarch64 1.8.6-0 kubernetes kubectl.aarch64 1.8.5-0 kubernetes kubectl.aarch64 1.8.4-0 kubernetes kubectl.aarch64 1.8.3-0 kubernetes kubectl.aarch64 1.8.2-0 kubernetes kubectl.aarch64 1.8.15-0 kubernetes kubectl.aarch64 1.8.14-0 kubernetes kubectl.aarch64 1.8.13-0 kubernetes kubectl.aarch64 1.8.12-0 kubernetes kubectl.aarch64 1.8.11-0 kubernetes kubectl.aarch64 1.8.1-0 kubernetes kubectl.aarch64 1.8.10-0 kubernetes kubectl.aarch64 1.8.0-0 kubernetes kubectl.aarch64 1.7.9-0 kubernetes kubectl.aarch64 1.7.8-1 kubernetes kubectl.aarch64 1.7.7-1 kubernetes kubectl.aarch64 1.7.6-1 kubernetes kubectl.aarch64 1.7.5-0 kubernetes kubectl.aarch64 1.7.4-0 kubernetes kubectl.aarch64 1.7.3-1 kubernetes kubectl.aarch64 1.7.2-0 kubernetes 配置iptablescat <<EOF > /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1vm.swappiness=0EOF#让上述配置命令失效sysctl --system#或者这样去设置echo "1" >/proc/sys/net/bridge/bridge-nf-call-iptablesecho "1" >/proc/sys/net/bridge/bridge-nf-call-ip6tables#保障输入的都是1cat /proc/sys/net/bridge/bridge-nf-call-ip6tablescat /proc/sys/net/bridge/bridge-nf-call-iptables装置kubelet,kubeadm,kubectl#装置最新版本,也可装置指定版本yum install -y kubelet kubeadm kubectl#装置指定版本的kubelet,kubeadm,kubectlyum install -y kubelet-1.19.3-0 kubeadm-1.19.3-0 kubectl-1.19.3-0#查看kubelet版本kubelet --version#版本如下:Kubernetes v1.19.3#查看kubeadm版本kubeadm version#版本信息如下:kubeadm version: &version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:47:53Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/arm64"}启动kubelet并设置开机启动服务#从新加载配置文件systemctl daemon-reload#启动kubeletsystemctl start kubelet#查看kubelet启动状态systemctl status kubelet#没启动胜利,报错先不论,前面的kubeadm init会拉起#设置开机自启动systemctl enable kubelet#查看kubelet开机启动状态 enabled:开启, disabled:敞开systemctl is-enabled kubelet#查看日志journalctl -xefu kubelet初始化k8s集群Master--apiserver-advertise-address=192.168.0.5 为Master的IP--image-repository registry.aliyuncs.com/google_containers 指定镜像仓库,如果不指定默认是k8s.gcr.io,国内须要翻墙能力下载镜像 ...

K8s对于kubelet宕机迁徙的解决在不同的版本有不同的演进，所以网上很多文章对于如何放慢这个工夫的说法并不统一，甚至有些检索进去没什么用途。 晚期搜寻到一些文章，指定了一个要害参数 pod-eviction-timeout ，驱赶pod的等待时间，可是发现批改该参数有效，通过浏览源码，发现并没有应用到这个参数，狐疑是一个废除的参数，通过翻阅很多材料后，发现不同的版本，是有不同的驱赶逻辑的。 <小于1.13版本： 没有启用污点管理器个性时，Pod的迁徙由以下四个参数决定， node-status-update-frequency, 节点上报频率，默认为10snode-monitor-period , node控制器每隔多长时间监控一次node状态，默认为5snode-monitor-grace-period， node控制器距离多长时间后会将Node设置为 Not Ready ， 默认为40spod-eviction-timeout, node控制器距离多长时间后开始驱赶Pod版本大于等于1.14小于1.18： 默认启用污点管理器个性，通过污点管理器的机制驱赶Pod版本大于1.18：必须启动污点管理器，其实旧的代码曾经没有意义了污点机制介绍官网文档 节点亲和性 是 Pod 的一种属性，它使 Pod 被吸引到一类特定的节点 （这可能出于一种偏好，也可能是硬性要求）。 污点（Taint） 则相同——它使节点可能排挤一类特定的 Pod。 容忍度（Toleration） 是利用于 Pod 上的。容忍度容许调度器调度带有对应污点的节点。 容忍度容许调度但并不保障调度：作为其性能的一部分， 调度器也会评估其余参数。 污点和容忍度（Toleration）相互配合，能够用来防止 Pod 被调配到不适合的节点上。 每个节点上都能够利用一个或多个污点，这示意对于那些不能容忍这些污点的 Pod， 是不会被该节点承受的。 简略来说，依照污点和容忍的机制思考，所有对于Pod的驱赶，都能够实用这套机制，包含因为kubelet故障导致的。 源码剖析1. 将node设置为Not ReadyNode控制器会周期性查看node的状态，如果发现有心跳工夫超过了 node-monitor-grace-period的，就认为是不可达了，将给该节点赋予Taint. # node_lifecycle_controller.gomonitorNodeHealth() // 1. 获取所有的node --> nodes, err := nc.nodeLister.List(labels.Everything()) // 2. 依据心跳工夫判断是否呈现了Not Ready --> gracePeriod, observedReadyCondition, currentReadyCondition, err = nc.tryUpdateNodeHealth(node) // 3. 为node设置taint --> nc.processTaintBaseEviction(node, &observedReadyCondition)2. 监听Node更新事件，触发驱赶 ...

Kubernetes实战高可用集群搭建，配置，运维与利用内附材料文档下载地址：百度网盘从零开始自己动手写自旋锁咱们在写并发程序的时候，一个非常常见的需要就是保障在某一个时刻只有一个线程执行某段代码，像这种代码叫做临界区，而通常保障一个时刻只有一个线程执行临界区的代码的方法就是锁。在本篇文章当中咱们将会认真分析和学习自旋锁，所谓自旋锁就是通过while循环实现的，让拿到锁的线程进入临界区执行代码，让没有拿到锁的线程一直进行while死循环，这其实就是线程自己“旋”在while循环了，因而这种锁就叫做自旋锁。原子性在谈自旋锁之前就不得不谈原子性了。所谓原子性简略说来就是一个一个操作要么不做要么全做，全做的意义就是在操作的过程当中不能够被中断，比方说对变量data进行加一操作，有以下三个步骤： 将data从内存加载到寄存器。将data这个值加一。将失去的后果写回内存。 原子性就示意一个线程在进行加一操作的时候，不能够被其余线程中断，只有这个线程执行完这三个过程的时候其余线程才能够操作数据data。咱们现在用代码体验一下，在Java当中咱们可能使用AtomicInteger进行对整型数据的原子操作：import java.util.concurrent.atomic.AtomicInteger; public class AtomicDemo { public static void main(String[] args) throws InterruptedException { AtomicInteger data = new AtomicInteger();data.set(0); // 将数据初始化位0Thread t1 = new Thread(() -> { for (int i = 0; i < 100000; i++) { data.addAndGet(1); // 对数据 data 进行原子加1操作 }});Thread t2 = new Thread(() -> { for (int i = 0; i < 100000; i++) { data.addAndGet(1);// 对数据 data 进行原子加1操作 }});// 启动两个线程t1.start();t2.start();// 等待两个线程执行实现t1.join();t2.join();// 打印最终的后果System.out.println(data); // 200000}} ...

一.什么是k8s：全名kubenetes，容器编排工具，分布式的架构，可能对docker以及其余容器进行主动部署，弹性伸缩和治理二.k8s的架构：分布式的，一个master节点（属于是主节点）和多个node节点（计算节点），master就是领导不干理论的计算工作而是负责整体把关，node属于就是worker节点，承受指令干活的。1、master节点包含五个大部分：（1）kubectl：在cmd命令行操作指令的都是这个，属于是输出kubectl命令的入口都有啥命令呢： 第一个命令 kubectl --help而后就会显示都有啥命令如下：Basic Commands (Beginner): create Create a resource from a file or from stdin. expose Take a replication controller, service, deployment or pod and expose it as a new Kubernetes Service run Run a particular image on the cluster set Set specific features on objectsBasic Commands (Intermediate): explain Documentation of resources get Display one or many resources edit Edit a resource on the server delete Delete resources by filenames, stdin, resources and names, or by resources and label selectorDeploy Commands: rollout Manage the rollout of a resource scale Set a new size for a Deployment, ReplicaSet or Replication Controller autoscale Auto-scale a Deployment, ReplicaSet, or ReplicationControllerCluster Management Commands: certificate Modify certificate resources. cluster-info Display cluster info top Display Resource (CPU/Memory/Storage) usage. cordon Mark node as unschedulable uncordon Mark node as schedulable drain Drain node in preparation for maintenance taint Update the taints on one or more nodesTroubleshooting and Debugging Commands: describe Show details of a specific resource or group of resources logs Print the logs for a container in a pod attach Attach to a running container exec Execute a command in a container port-forward Forward one or more local ports to a pod proxy Run a proxy to the Kubernetes API server cp Copy files and directories to and from containers. auth Inspect authorizationAdvanced Commands: diff Diff live version against would-be applied version apply Apply a configuration to a resource by filename or stdin patch Update field(s) of a resource using strategic merge patch replace Replace a resource by filename or stdin wait Experimental: Wait for a specific condition on one or many resources. convert Convert config files between different API versions kustomize Build a kustomization target from a directory or a remote url.Settings Commands: label Update the labels on a resource annotate Update the annotations on a resource completion Output shell completion code for the specified shell (bash or zsh)Other Commands: alpha Commands for features in alpha api-resources Print the supported API resources on the server api-versions Print the supported API versions on the server, in the form of "group/version" config Modify kubeconfig files plugin Provides utilities for interacting with plugins. version Print the client and server version information一样一样来，先看最简略的-------比方查看的命令： ...

背景：上一节（Operator3-设计一个operator）做完发现一个问题 我创立了jan 利用jan-sample，子资源包含deployment，service.ingress,pod(其中pod是deployment治理的) 手动删除Pod.因为Deployment rc控制器。Pod资源能够主动重建。然而我删除deployment能不能主动重建呢？失常的deployment service ingress子资源的生命周期，我应该是靠jan利用去维系的，试一试： [zhangpeng@zhangpeng jan]$ kubectl delete deployment jan-sampledeployment.apps "jan-sample" deleted[zhangpeng@zhangpeng jan]$ kubectl get deploymentNo resources found in default namespace.到这里才发现没有思考周全......删除deployment资源并不能重建，失常创立利用应该要考虑一下jan资源上面资源的重建.搜了一下他人写的operator貌似的能够加一下Owns，尝试一下！ Deployment Ingress Service对于Owns的应用Deploymentfunc (r *JanReconciler) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&janv1.Jan{}). Owns(&appsv1.Deployment{}). Complete(r)}Deployment delete尝试make run develop-operator我的项目，并尝试delete deployment jan-sample查看是否重建： [zhangpeng@zhangpeng develop-operator]$ kubectl get Jan[zhangpeng@zhangpeng develop-operator]$ kubectl get all [zhangpeng@zhangpeng develop-operator]$ kubectl delete deployment jan-sample[zhangpeng@zhangpeng develop-operator]$ kubectl get deployment恩发现deployment利用能够主动重建了！ Ingress and Service资源简略增加一下Owns？but其余资源是否能够呢？是不是也偷懒一下增加Owns？ func (r *JanReconciler) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&janv1.Jan{}). Owns(&appsv1.Deployment{}). Owns(&corev1.Service{}). Owns(&v1.Ingress{}). Complete(r)}尝试了一下不失效的，然而这种形式思路是对的至于为什么不失效呢？deploy申明了&appv1.Deployment,然而service,ingress是没有创立变量申明的！ ...

对代码进行动态扫描是一种十分常见的代码质量保证伎俩，这种扫描不仅仅能够查看到代码中的缺点，利用各种业界最佳实际，也能够查看出平安方面的破绽，给予我的项目代码全方位的晋升。在各种代码扫描计划之中，SonarQube 最为人熟知，利用最为宽泛。各种继续集成计划都有本人的形式融入 SonarQube 进行代码的动态扫描工作。 明天介绍一种基于 SonarScanner 在 Rainbond 源码构建过程中，对 Java Maven 我的项目进行动态扫描的办法。 SonarScanner For Maven 简介应用 SonarScanner for Maven 对 Maven 我的项目进行代码动态扫描，是 SonarQube 官网举荐的默认扫描器。只须要在 mvn 命令中退出指定的参数，就能够集成该扫描器，并在构建的过程中剖析代码破绽。 示例命令： mvn clean verify sonar:sonar -Dsonar.login=myAuthenticationToken在理论执行过程中， myAuthenticationToken 会被代替成为 SonarQube 中，某个理论用户本人生成的令牌。 融入继续集成链条理解 SonarScanner for Maven 的工作形式之后，咱们就能够尝试将代码扫描这个过程，融入到 Rainbond 的自动化继续集成链条之中。咱们心愿最终达成的成果，是在代码提交后主动触发我的项目的构建，在构建过程中进行代码的扫描剖析，并生成相应的报告。 整个流程能够概括为如下几个阶段： 开发人员向代码仓库提交代码，触发整个继续集成链条。代码仓库利用 Webhook 调用 Rainbond 的 Openapi 接口，触发对应的服务组件构建本身。Rainbond 主动构建对应服务组件的同时，触发 SonarScanner 扫描工作，并将扫描后果发送给 SonarQube 服务。SonarQube 服务剖析扫描后果，生成代码检测报告。开发人员读取代码检测报告，获悉改良点。开发人员依据报告欠缺代码，并再次提交，回到步骤1，造成继续集成的闭环。接下来，将会从实际操作的角度登程，基于 Rainbond 一点点实现上述继续集成链条。 前提条件本文中介绍的包含了代码扫描的继续集成链条，都是基于 Rainbond 云原生治理平台实现的。所以须要用户自行筹备可用的 Rainbond 环境，该环境须要连贯公网，为应用开源利用商店做筹备。 搭建 SonarQube除了 Rainbond 云原生利用治理平台，还须要筹备代码仓库和 SonarQube 服务。前者咱们抉择应用 Gitlab ，而 SonarQube 服务则能够间接基于开源利用商店装置。目前开源利用商店提供了 8.9.9 （lts）版本的 SonarQube ，供用户一键装置。 ...