Rancher

作者简介王海龙，Rancher 中国社区技术经理，Linux Foundation APAC Evangelist，负责 Rancher 中国技术社区的保护和经营。领有 9 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。容器化和云原生利用疾速倒退，K3s 成为了备受瞩目的轻量级 Kubernetes 发行版。在生产环境中，单点故障可能导致整个集群的不可用，高可用对用户至关重要。 K3s 自身能够主动实现管制立体的高可用，但短少一个具备高可用的访问控制立体入口；毕竟，用户不想依附一个繁多的节点来拜访 Kubernetes 集群的 API。对此，用户能够借助 kube-vip 工具来实现 K3s 管制立体的高可用，从而确保 K3s 集群在面临故障时仍能提供稳固牢靠的服务。本文将对此进行具体介绍。 什么是 kube-vipkube-vip 是一个功能强大的工具，它能够通过虚构 IP（VIP）来实现 Kubernetes 集群的高可用。它能够监控集群中的 Master 节点，并在主节点故障时主动切换到备用节点，以确保集群的继续可用性。 kube-vip 有两种应用模式：ARP 模式和 BGP 模式。这两种模式都可用于在 Kubernetes 集群中创立和治理高可用虚构 IP 地址。 ARP 模式：在 ARP 模式下，kube-vip 应用 ARP（地址解析协定）来实现 IP 转发。它通过在集群中的节点之间发送 ARP 申请和响应来实现负载平衡和故障转移。当一个节点接管到 ARP 申请时，它会答复申请并接管 IP 地址。这种模式简略且易于配置，不须要任何其余的内部依赖。BGP 模式：在 BGP 模式下，kube-vip 应用 BGP（边界网关协定）来实现 IP 转发。BGP 是一种用于在不同自治零碎（AS）之间替换路由信息的路由协定。在 BGP 模式中，kube-vip 在 Kubernetes 集群外部模仿了一个 BGP 路由器，各个节点通过 BGP 会话将路由信息替换给 kube-vip，并由 kube-vip 将流量导向适当的节点。这种模式通常在须要与内部网络进行互连或实现更高级的路由策略时应用，它须要额定的配置和与网络设备（如路由器）的集成。抉择哪种模式取决于集群的需要和网络环境。ARP 模式简略易用，适宜于较小规模的集群或在没有简单网络配置的状况下。BGP 模式则实用于更大规模的集群，须要与内部网络进行交互或实现高级路由策略的状况下。 ...

本文将介绍如何在示例我的项目中应用网络策略，并解释它在 K3s 中的工作原理，从而帮忙用户进步部署的安全性。 对于 K3s 对网络策略的反对存在一个广泛的误会，因为 K3s 默认应用 Flannel CNI，而 Flannel CNI 不反对网络策略。其实，K3s 应用 Kube-router 网络策略控制器为网络策略提供反对，所以网络策略也能够在 K3s 中应用，就像在其余 Kubernetes 发行版中一样。 失常的 Pod 互相通信默认状况下，在 K3s 中，一个特定命名空间中的所有 services/Pod 都能够被任何其余命名空间中的所有其余 Pod 拜访。 为了举例说明 Pod 如何互相通信，让咱们在两个不同的命名空间（sample1 和 sample2）中应用简略的 nginx deployment 和 service 来测试，如下所示： nginx.yaml apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: ngnix-servicespec: selector: app: nginx type: ClusterIP ports: - protocol: TCP port: 80 targetPort: 80创立测试命名空间并将 nginx 部署到对应命名空间中： ...

介 绍最后在 Kubernetes v1.21 中被弃用的 PodSecurityPolicy API，曾经在 Kubernetes v1.25 中被齐全删除。因为 API 被移除，你无奈在 Kubernetes v1.25 集群中创立、编辑或查问 PodSecurityPolicy 资源。此外，因为其准入控制器已被移除，所以你的集群无奈再强制执行在 Kubernetes v1.24 及之前版本中创立的任何 PodSecurityPolicy 规定。因而，你必须将工作负载平安迁徙到新的 Pod Security Admission 控制器、补充策略引擎或两者的组合中。 本文将探讨如何将 Rancher 治理的上游集群降级到 Kubernetes v1.25，包含如何应用 Rancher 特定的机制来利用 Pod Security Admission 配置，以及如何从 Rancher 保护的工作负载中删除 PodSecurityPolicies。本文是一个示例教程，倡议先在非生产环境中运行这些步骤来相熟流程，而后再决定你的生产环境须要如何操作。 要 求将集群降级到 Kubernetes v1.25 之前，请确保： 你正在运行 Rancher v2.7.2 或更高版本。你的上游集群正在运行 Kubernetes v1.24。你已实现了 Kubernetes 文档中概述的从 PodSecurityPolicies 迁徙到内置的 Pod Security Admission 控制器的步骤，将 PodSecurityPolicies 映射到 Pod Security Admission 配置或 Pod Security Standard 标签中。你曾经评估过 Pod Security Admission 是否满足你的需要。在本文最初有一些对于补充策略引擎的资源，如果 Pod Security Admission 不足以满足你的应用需要，你可能须要将它增加到你的集群中。配置 Pod Security Admission 控制器第一步是配置新的 Pod Security Admission 控制器。在 Kubernetes v1.24 中，这个准入控制器曾经在 kube-apiserver 中默认启用。有几种办法能够配置这个准入控制器，其中一种抉择是通过 kube-apiserver 命令行参数部署集群范畴的 AdmissionConfiguration。从 2.7.2 版本开始，Rancher 提供了两个开箱即用的 AdmissionConfigurations，或者你也能够通过 Rancher UI 创立本人的 Pod Security Admission 配置。上面将更具体地介绍这些性能。 ...

“多云”通过不同的云厂商散发应用程序进步了弹性，可能帮忙企业强化本身的竞争力。此外，多云还升高了被云厂商锁定的可能性，让企业防止过于依赖某个云厂商。 尽管多云的劣势很多，然而治理多云 Kubernetes 的艰难还是让人望而生畏。部署多个集群，将它们作为一个单元应用并监控整个集群是十分艰巨的工作。企业须要一种办法来继续实现受权、可观测性和平安的最佳实际。 Rancher 是一个开源的企业级 Kubernetes 治理平台，可能实现 Kubernetes 集群在混合云和本地数据中心的集中部署与治理。它解决了多云 Kubernetes 部署的挑战，例如查看工作负载运行地位以及集中进行身份认证和访问控制。 本文将具体介绍如何通过 Rancher 在多云场景中轻松应用 Kubernetes。 Rancher 和多云部署Rancher 的劣势之一是让用户在应用多个环境时取得统一的体验。无论集群位于云端还是本地，你都能够治理所有集群的整个生命周期。它还形象出 Kubernetes 实现之间的差别，创立了用于监控部署的对立界面。 Rancher 非常灵活，能够与新旧集群一起工作，并且反对通过以下三种形式连贯集群： 应用云 Kubernetes 服务配置新集群：Rancher 能够创立新的 Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS) 、Google Kubernetes Engine (GKE) 、阿里云 ACK、腾讯云 TKE 和华为云 CCE 集群。该过程在 Rancher UI 中能够齐全自动化。此外，还能够导入现有集群。在独立的云基础设施上配置新集群：Rancher 能够通过在你的云服务商上配置新的计算节点来部署 RKE、RKE2 或 K3s 集群。此选项反对 Amazon Elastic Compute Cloud (EC2)、Microsoft Azure、DigitalOcean、Harvester、Linode 和 VMware vSphere。应用你本人的集群：反对手动连贯在本地或其余云环境中运行的 Kubernetes 集群。这样，你能够在混合部署的状况下联合应用本地和私有云基础设施的多项性能。 增加了多星散群后，就能够应用 Rancher 无缝治理这些集群。 对立的仪表板多云最大的难题之一是跟踪部署的内容、地位以及运行状况。Rancher 为你提供了对立的仪表板，显示了每个集群，包含集群的云环境及其资源利用率： ...

王海龙，Rancher 中国社区技术经理，Linux Foundation APAC Evangelist，负责 Rancher 中国技术社区的保护和经营。领有 9 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。Kubernetes 已成为容器编排的事实标准，扭转了咱们的开发流程。十年前，咱们只须要将代码打包成 war/jar 包，而后启动利用即可。然而，当初面向 Kubernetes 的开发，交付的产物有可能是 Helm Chart、Workload Yaml、Dockerfile 或者容器镜像，最初由运维将这些交付物部署到 Kubernetes 集群中。 Kubernetes 的学习老本较高，它有一个平缓的学习曲线。对于没有 Kubernetes 教训的开发者，如何将利用部署到 Kubernetes 集群上是一个大挑战。这时，一个可能将源代码主动部署到 Kubernetes 集群中的工具就变得至关重要。 什么是 EpinioEpinio 是一个由 Kubernetes 驱动的利用开发引擎，由 SUSE 推出。只有将 Epinio 增加到你的集群中，就能够创立本人的平台即服务（PaaS）解决方案，能够在其中部署应用程序，而无需本人建设基础设施。 Epinio 形象出 Kubernetes 的复杂性，因而你能够只关注编写代码自身。应用程序通过将其源代码间接推送到平台来启动，打消了简单的 CD 管道和 Kubernetes YAML 文件。最初，你能够通过一个由 ingress controller 凋谢的 URL 来拜访你的应用程序。 应用 Epinio 来运行你的应用程序，能够让你专一于业务性能逻辑，而非繁琐的配置容器和 Kubernetes 对象。Epinio 会自动识别你应用的编程语言，应用 Paketo Buildpack 构建一个适合的镜像，并在 Kubernetes 集群中启动容器。如果你曾经有了一个可用的镜像，也能够抉择应用本人的镜像。 ...

当初，软件开发的范例是将容器化应用程序部署到 Pod 上，而后通过 Kubernetes 进行治理。Kubernetes 能够管理应用程序的部署、复制、HA、指标和其余性能，这样应用程序就能够专一于本职工作。 要将应用程序容器化，你须要应用镜像，而镜像通常是基于语言的（Golang、Python、Rust、.NET 等）。镜像提供商有很多，包含将镜像提交到镜像仓库的集体贡献者，以及企业级镜像提供商等。你也能够在开发中应用基于操作系统的镜像。 但在应用镜像过程中，咱们往往会遇到一些问题。 软件工程问题安全性：如何确保应用的版本没有受到 CVE 或其余破绽的影响？从新散发：须要部署应用程序，然而不理解底层主机、架构或编排技术。仓库和工具：有时我须要应用一些工具（Git、编译器、库等），但大多数镜像不提供能够获取这些工具和包的牢靠仓库。可用性：开源贡献者和企业软件工程师都须要基于多种平台和架构（ARM、x86_64 等）制作软件。镜像不仅要适应架构，还要实用于不同语言标准。有没有牢靠的镜像仓库能够作为获取最新镜像的繁多参考点，以便保护镜像的标签历史？反对和生命周期：在大多数状况下，不受反对的镜像对于企业级软件来说是有效的，因而须要有供应商为用来创立或容器化应用程序的根底提供反对，ISV/IHV 须要更多反对。此外，镜像必须在生命周期内进行更新、修复安全漏洞和进步性能。应用 BCI 解决这些问题SUSE 公布了 BCI（Base Container Image），BCI 是专一于安全性、可用性、敏捷性和开发者体验的企业级容器镜像。BCI 不仅基于操作系统，还包含语言包、busybox、base 和 minimal。因而，BCI 是应答各类开发（包含社区我的项目和生产级应用程序）挑战的现实抉择。 BCI 能帮忙你解决以下问题： 平安没有人违心应用受 CVE 影响的软件来构建应用程序。作为开发人员，应用平安镜像能够确保开发的应用程序是牢靠的。以下是一些例子： Trivy 是一款镜像扫描软件，可用于查看破绽。 ➜ ~ trivy image registry.suse.com/bci/bci-base2022-10-09T03:47:42.403+0200 INFO Need to update DB2022-10-09T03:47:42.404+0200 INFO DB Repository: ghcr.io/aquasecurity/trivy-db2022-10-09T03:47:42.404+0200 INFO Downloading DB...34.35 MiB / 34.35 MiB [-------------------------------------------------------------------------------------------------------] 100.00% 23.13 MiB p/s 1.7s2022-10-09T03:47:45.503+0200 INFO Vulnerability scanning is enabled2022-10-09T03:47:45.503+0200 INFO Secret scanning is enabled2022-10-09T03:47:45.503+0200 INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning2022-10-09T03:47:45.503+0200 INFO Please see also https://aquasecurity.github.io/trivy/v0.32/docs/secret/scanning/#recommendation for faster secret detection2022-10-09T03:47:45.528+0200 INFO Detected OS: suse linux enterprise server2022-10-09T03:47:45.528+0200 INFO Detecting SUSE vulnerabilities...2022-10-09T03:47:45.528+0200 INFO Number of language-specific files: 0registry.suse.com/bci/bci-base (suse linux enterprise server 15.4)Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)bci-micro、bci-minimal、buxybox 和 init 上的后果也是一样的。 ...

作者简介张应罗，SUSE 资深架构师，领有 16 年架构征询工作教训，专一于 SUSE Enterprise Container Management 相干的产品落地计划及征询方案设计。平台工程“DevOps 已死，平台工程才是将来!” 去年，出名软件工程师兼 DevOps 评论员 Sid Palas 在推特上收回呐喊。 他的外围观点是：开发者不想跟基础设施打交道，企业在倒退过程中又须要管制本人的基础设施；只有平台工程，能将这两个互相矛盾的命题对立起来。这一观点引发了开发者们的强烈探讨，平台工程正在崛起。 简略为大家介绍一下平台工程（Platform Engineering）的概念。 平台工程的倒退背景软件在一直演进过程中将运维技能从开发技能中剥离进去，造成了两个不同的职业，但后果证实适度拆散的两个职业无奈满足软件疾速迭代的需要，因而 DevOps 呈现了，咱们用它来对立运维及开发。开发周期是一个企业最稀缺的资源，因而应该将尽可能多的资源放在外围产品开发上。开发人员应该可能端到端地部署和运行他们的利用。“谁构建，谁运行”才是真正的 DevOps，但并不是所有的公司都是 Google、亚马逊、微软，大多数公司都没有像他们那样的人才库，也不会仅仅为了优化开发工作流和体验而像他们那样投入资源。在过来，有的工程师写代码，有的工程师跑代码。而当初，工程师不仅编写代码，还要运行他们编写的代码。这让软件工程师感觉他们必须对所有事件都一目了然，大大增加了认知累赘。这迫使许多团队从新在自动化带来的自在与认知累赘之间权衡利弊，平台工程也因而越来越受关注和热议。Gartner 在 2022 年 8 月公布的软件工程成熟度曲线中增加了“平台工程”。 平台工程的定义“平台工程”社区次要贡献者及 Humanitec 产品负责人 Luca Galante 在《什么是平台工程》的文章里指出：平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流能够为云原生时代的软件工程组织提供自助服务性能。平台工程师提供集成化产品，通常称为“外部开发人员平台”，能够涵盖应用程序整个生命周期的所有操作需要。外部开发人员平台由平台工程团队构建，用于铺好坦途以此来反对开发人员自助服务。外部开发人员平台由许多不同的技术和工具组成，以一种升高开发人员认知累赘的形式组合在一起，无需形象出上下文和底层技术。平台工程团队将他们的平台视为一种产品，依据用户钻研对其构建，并一直保护和改良。Kubernetes 在平台工程中表演的角色无论外部开发人员平台的工具链有如许丰盛，在云原生时代，Kubernetes 未然成为利用落地部署的最优抉择。平台工程承载了利用迭代和部署验证的重任，须要建设提供面向 Kubernetes 的弹性能力。Rancher Prime 为平台工程体系提供强有力撑持Rancher Prime 的混合云 K8s 治理能力Rancher Prime 研发之初的核心理念就是多云治理，因而，产品进化至今，在历经近上千个 release 后，Rancher Prime 在多云多 K8s 集群治理畛域未然遥遥领先，能够随时随地治理和部署任意地位的 K8s 集群。 Rancher Prime Rancher Prime 反对对国内头部私有云厂商的 K8s 发行版进行全生命周期治理，包含阿里云 ACK、腾讯云 TKE、华为云 CCE。Rancher Prime 反对对国内头部私有云厂商的 K8s 发行版进行全生命周期治理，包含 AWS EKS（Global Region 及 China Region）、Azure AKS（Global Region及China Region）、Google GKE。在公有数据中心场景下，Rancher Prime 能够创立通过 CNCF一致性认证的 K8s 发行版 RKE 和 RKE2，帮忙客户疾速落地生产级别的 K8s 集群。在边缘计算场景下，Rancher Prime 能够创立轻量级 K8s 发行版 K3s，并且反对 X86 和 ARM 两种架构。Rancher Prime 面向多集群的中心化多租户体系Rancher Prime 具备一套成熟的面向多集群的中心化多租户体系，能够轻松形象用户拜访权限。这为平台工程内的开发人员提供了良好的隔离环境，让他们能够灵便应用本人的开发环境，而不影响其余开发人员。 ...

作者简介涂家英，SUSE 资深架构师，专一 Cloud-Native 相干产品和解决方案设计，在企业级云原生平台建设畛域领有丰盛的教训。数字时代下的容器云治理平台数字时代，市场竞争加剧，业务需要突飞猛进，敏态 IT 建设被越来越多的企业纳入重点倒退布局，以容器、Kubernetes 为外围的云原生是目前敏态 IT 中最热门的技术架构。 CNCF 把云原生划分为多个畛域，包含基础设施、利用开发与部署、服务公布与治理、运行时、网络、存储、观测与剖析、平安与合规等，每个畛域中都有十分丰盛的开源我的项目。从技术视角来看，云原生建设就是在各畛域中找到可能满足本身需要的技术，并组合起来，为咱们所用。在这个过程中，咱们直面的问题包含：如何抉择适合的技术？如何对这一技术组合进行对立治理？如何调整和优化这些技术以实现高效、稳固的运行？ 对此，容器云治理平台的概念应运而生，简略地说就是提供一系列开箱即用的性能，并围绕 Kubernetes 提供更多的扩大和翻新。容器云治理平台是一个两头态的产品，对下可能实现集群的生命周期治理，对上可能实现对 Kubernetes 上运行的利用的生命周期治理，同时还需具备企业所需的性能，如租户治理、平安治理、用户认证以及权限治理等。 目前，国内有不少厂商专一于这个畛域，提供了很多优良的解决方案，面对目不暇接的产品，咱们该如何抉择？ 平台选型在日常与企业客户的交换中我不难们发现，大家在建设云原生平台过程中，探讨最多的就是布局和选型问题。如果把选型过程比作通关游戏，那么咱们会遇到性质思考、模式思考和能力思考三个关卡。 性质思考从企业理论利用场景来看，容器云治理平台是一个跨部门平台，至多会波及基础设施部门、研发部门、安全部门；当然，不同企业对部门的划分可能会更粗疏。而且，容器云治理平台和业务利用又有着严密的关联性，会影响业务利用的构建公布流程和运行运维形式，所以从整体看来容器云治理平台具备了 2 个特点：技术上的确定性和能力上的特异性。 技术上的确定性：在建设容器云治理平台时，相干的技术栈根本是确定的，例如容器编排调度引擎应用 Kubernetes，监控应用 Prometheus，日志应用 ELK 或者 Loki，模板商店应用 Helm 等，还有像容器运行时、网络、存储等也都有很清晰的抉择范畴。能力上的特异性：每个企业 IT 部门都有本人的工作形式、流程、组织架构和外部环境，对容器云治理平台建设都有本人的认识。有些企业的容器云治理平台绝对独立；有些可能须要与外部的其余零碎做集成和联动，如与外部监控集成造成对立环境监控，与外部日志平台集成造成对立认证，与外部用户认证平台集成实现 sso 单点登录，须要与组织架构绝对应的多租户能力等，这就须要不同的能力反对。从这个角度来讲，齐全依照本身需要，自研一套容器云治理平台是企业的最优抉择。然而自研的门槛比拟高，须要肯定的团队和技术实力，大多数企业都不具备这样的能力。商用是更求实的抉择，有很多厂商提供了相应的平台产品，但也有不少挑战。尽管平台都基于 Kubernetes 搭建，然而不同的产品理念，可能造就了不同的性能侧重点，以及将来不同的倒退和延长路线；还有一些产品存在不同水平的捆绑，一旦选错可能将深陷泥淖。 综合来看，抉择开源的、兼容性好的商用产品可能在肯定水平上实现自研和商用的均衡。一方面，企业能够通过标准化的产品能力和厂商的业余技术支持及赋能，疾速造就和晋升本身团队对云原生的认知和技术水平。另一方面，在团队能力达标，且标准化的能力曾经无奈满足外部需要时，企业能够基于开源产品更便捷地进行二次开发。实际上，在团队实力达标的状况下，咱们也不太倡议一开始就齐全自研平台，因为从 0-1 的建设可能会踩很多坑，遇到很多问题，一些性能间接复用开源产品造好的轮子会事倍功半。同时，应用开源产品确保了技术的延续性，在购买商业反对后，能够大幅缩小人力老本收入，晋升工作效率，有更多的工夫专一于本身的主营业务。 模式思考在明确了性质抉择后，咱们转角就遇到了第二个选型问题：应该抉择全功能模式还是组合性能模式？ 以后，各种容器云治理平台产品丰盛，大抵能够分为两类：性能全面型和凋谢兼容型。 性能全面型：平台中性能根本笼罩了云原生所有元素，如包含了 Kubernetes 集群治理、利用治理、DevOps、微服务治理、中间件等各大板块能力，并且高度封装。凋谢兼容型：平台中性能以保有外围能力为主，如 Kubernetes 集群治理、利用治理，其余能力以开箱即用的插件形式提供，具备高度的可替换性。 性能全面的容器云治理平台可能屏蔽掉很多技术细节，企业能够拿来即用；凋谢兼容型产品能够提供更灵便的组合形式。 在晚期，容器和 Kubernetes 技术还不是那么遍及，性能全面型的产品是比拟好的抉择，企业能够借助其全面的能力疾速构建，屏蔽掉一些技术门槛，预研云原生技术和带来的价值；当今，容器和 Kubernetes 技术曾经比拟遍及，整个 CNCF 生态也进入了凋敝期间，云原生的建设更多是积木式、集成式的组合。 “业余的事件交给业余的人去做”，大而全平台的问题在于整体性能都是内聚的、相互依赖的、标准化的。用户往往在应用时发现，很多中央并不能很好地符合本身需要，还须要替换功能模块。然而在高内聚的布局下，模块的剥离和替换往往难以实现，或者老本很高。所以，越来越多的用户会抉择凋谢兼容性好的产品，在须要替换平台中的某些功能模块时，只须要敞开相应模块，间接进行替换或者集成即可。 同时咱们也看到，越来越多功能全面的平台也开始化整为零，固化必备的根底能力，周边能力则以模块插件形式提供，不便用户进行替换。 能力思考走到这一步，选型的思路就比拟清晰了。咱们遇到的最初一个问题是：除了性质和模式，还须要思考哪些因素呢？ 基于与泛滥客户的接触，咱们提炼出两点： 积淀蕴含很多方面，比方产品的迭代历史、应用人数、行业落地案例等。这些积淀能够很好地反映产品的成熟度和稳定性，毕竟大家都不想在生产环境中做第一个吃螃蟹的人，更心愿有一个胜利的参照物能够借鉴。翻新是一个企业的灵魂，云原生就像是一列飞驰的高铁，好的产品提供者应该能紧跟技术倒退，并一直新陈代谢。企业在应用容器云治理平台的同时，在不同的阶段总会呈现不同的需要场景和问题，能不能走在用户后面引领用户，并陪伴用户成长，也是选型思考的一个重要因素。通过以上三个关卡，想必大家曾经有了选型的初步想法。上面让咱们从利用场景登程，再对产品选型能力指标做一些考量。 场 景多集群及环境对立治理企业中不同类型的 Kubernetes 集群越来越多，混合治理的需要一劳永逸。咱们在与客户聊集群布局的时候常常听到： 咱们须要在不同的环境建设 Kubernetes 集群，包含开发、测试、UAT、生产。这些利用比拟重要，须要独自的集群撑持，不便重点运维。咱们 X 利用是外采的，它的底座也是 Kubernetes 集群，要把平台治理起来。咱们之前 X 部门走的比拟靠前，过后用开源工具部署了一个 Kubernetes，当初须要临时治理起来，后续再思考新建集群并迁徙。咱们除了公有云以外，某私有云上也应用了 Kubernetes 集群（也想在私有云上应用 Kubernetes 集群），是否不便地实现混合云治理。咱们当初容器和 VM 是共存的状态，整体利用蕴含了容器运行局部和 VM 运行局部，有没有能对立治理容器和 VM 的形式……在云原生时代，随着企业的一直倒退，多云混合云的场景变得越来越广泛。以某批发企业为例，其 APP 商城平时运行在公有数据中心，在晚期业务量不大的时候，即便在大促时也齐全能够承载和撑持。但随着企业的一直倒退，大促带来的拜访压力曾经到了本地无奈撑持的水平，然而为了应答大促而去扩充公有数据中心规模的做法又不够经济，这会造成平时大量的资源闲置。 ...

作者简介张志龙，SUSE 大中华区资深解决方案架构师，CNCF 官网认证的 CKA&CKAD 工程师，深耕以 Kubernetes 为代表的云原生畛域，具备丰盛的架构设计、业务容器化革新和我的项目落地实践经验。据 Gartner 预测，到 2025 年，50% 以上由企业治理的数据都将在数据中心和云之外创立和解决。Linux Foundation 钻研发现，到 2025 年，边缘计算的规模将比云大 4 倍，其生成的数据量将占寰球所有数据的 75%。随着以 K8s 为代表的云原生技术的成熟，越来越多的用户冀望将 K8s 的能力使用到边缘计算场景中。 在边缘运行 K8s 面临诸多挑战然而，在边缘侧运行 K8s 集群也面临诸多挑战。数据中心具备稳固的运行环境、高带宽的网络、高配置的服务器等成熟的 K8s 运行条件，且有大量企业级厂商提供相干的解决方案。与数据中心不同，通常状况下，边缘侧的运行环境比拟顽劣，网络难以保障、硬件配置低，在这样严苛的条件下运行 K8s 将面临极大的挑战： 硬件设施难以撑持 K8s 运行硬件配置低：边缘侧设施的 cpu、内存等计算资源配置通常较低，为个位数级别，次要用于利用本身，难以调配更多资源供诸如 K8s 的中间层平台应用。网络不稳固：运行环境恶劣，与核心之间的网络随时可能中断，无奈提供稳固牢靠的网络，难以保障 K8s 本身的稳固运行。非生产就绪：尽管社区有轻量化的 K8s，但多为单节点架构，并非是为了运行多节点的生产级环境而设计的，难以提供生产级的高可用服务。减少技术竖井：如果云端采纳 K8s，边缘场景应用其余技术栈，云边环境的不统一将导致无奈应用雷同技术栈进行治理，减少技术竖井。边缘场景下 K8s 难以治理保护设施扩散：边缘场景的一大特点是设施扩散在各个区域，难以通过对立的界面对其上的 K8s 服务和业务利用进行集中式治理。而且在海量的边缘设施中部署、更新编排引擎和业务利用也是一大难题。K8s 架构简单：原生 K8s 蕴含多个外围的组件服务，高可用架构更为简单，在边缘侧间接部署原生 K8s 时，其复杂性会扩散到各个设施上。难以对立治理：个别应用层、容器层、操作系统层由不同的厂商提供，须要分层治理保护，不足对立的生命周期管理手段。边缘场景下 K8s 难以满足平安需要安全性：边缘设施不足业余的平安防护组件，存在被入侵、攻打的危险。合规性：在边缘设施上解决数据波及到企业的生产和经营流动，难以合乎所在行业内的特定准则。边缘侧 K8s 集群应具备的能力可能在边缘场景中安稳运行 K8s轻量化：保障 K8s 性能残缺的前提下，简化原生 K8s 的外围组件服务，升高架构复杂性，缩小用户所需治理的过程和服务数量。升高 K8s 资源耗费，可在低配置设施上运行，预留足够资源运行业务利用。可用性：按需反对多节点组成高可用集群，外围组件也为高可用架构，升高因软硬件故障导致增员带来的影响。集群节点故障或停机保护时，其余节点仍可对外提供服务。自治性：边缘 K8s 集群应具备残缺的自治性，不依赖云端管控即可自行失常运行；在单节点故障时，仍可失常运行，且可对故障节点上的利用进行故障转移和复原。实现对边缘场景中 K8s 的对立治理全面笼罩：通过云端管控平台应用对立的规范，治理所有边缘设施的次要层级，包含操作系统层、容器编排层、业务应用层。云边协同治理：反对通过云端管控平台对扩散的所有边缘设施进行对立治理，包含装置 K8s、部署利用、更新/回退、备份复原等。批量化治理：反对针对所有边缘 K8s 集群的批量化运维治理操作，包含操作系统、容器编排、业务利用的 OTA 更新，缩小人工干预和重复性工作。解决边缘场景中的平安问题全面平安防护：应用层、容器层、操作系统层具备欠缺的平安防护能力，可阻止异样拜访、入侵、攻打；可监测平台的实时平安状态、破绽等；可阻止敏感数据的传输和透露。 ...

作者简介涂家英，SUSE 资深架构师，专一 Cloud-Native 相干产品和解决方案设计，在企业级云原生平台建设畛域领有丰盛的教训。NeuVector 是 SUSE 开源的端到端的全生命周期容器平安治理平台，目前 NeuVector 默认只在平台内对安全事件进行提醒，并没有直观的对外输入口。站在告警角度来说短少主动性，本文将介绍如何通过 Rancher 的监控性能实现 NeuVector 安全事件的监控和告警。 监控及展现整体流程是通过 exporter 采集指标数据，而后通过 ServiceMonitor 实现数据的关联，最初通过 Grafana 和 AlertManager 实现数据的展现和告警： Rancher 平台中开启监控并装置 NeuVector 服务，Rancher 从 2.6.5 版本开始将 NeuVector 集成在平台中，用户能够在集群工具中间接部署应用： NeuVector 原生提供了相应的 exporter 服务来采集相应的指标，镜像为：neuvector/prometheus-exporter，端口为：8068，咱们能够间接通过 Rancher 的 UI 部署到集群system我的项目下的cattle-neuvector-system命名空间中： 部署实现后，咱们须要在主动生成的 service 中增加一个 Label，便于 ServiceMonitor 进行关联： 在监控中配置相干的 ServiceMonitor： 具体 Yaml 内容如下： <pre data-tool="mdnice编辑器" style="margin: 10px 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; border-radius: 5px; box-shadow: rgba(0, 0, 0, 0.55) 0px 2px 10px;">`apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata:  labels:    app: rancher-monitoring-prometheus # 配置一个prometheus服务的label，能够通过Rancher UI查问    nv: exporter # 倡议和svc的label统一  name: nv-exporter # 名称倡议和svc统一  namespace: cattle-neuvector-system #命名空间和svc的统一spec:  endpoints:  - interval: 10s # 数据同步周期    path: / # nv exporte的指标门路    port: 8068tcp # endpoints中的port名称统一  namespaceSelector: # 匹配svc的namespace    matchNames:    - cattle-neuvector-system  selector: # 匹配svc的label    matchLabels:      nv: exporter` </pre>配置实现后，能够通过 Rancher 进入 prometheus 的页面中查看 target 是否生成： ...

始终以来，在泛滥 Kubernetes 开源治理平台选项中，Rancher 深受社区用户的青眼。SUSE 在确保开源产品继续灵便演进的同时，也致力于满足企业用户的应用场景，为此 SUSE 正式推出 Rancher Prime。Rancher Prime 是 Rancher 的一种散发版，外围性能代码均来自 Rancher 社区版，但更加器重平安方面的建设，并面向企业用户强化了相干性能和服务。 Rancher Prime 为企业用户提供可信的镜像仓库，以获取外围装置介质。SUSE 不仅优化减速了国内的下载链路，还将继续治理各个依赖组件镜像的 CVE，从容器镜像角度晋升软件供应链平安。这得益于 SUSE 在 Linux 和容器畛域长期的工程化积攒，简直所有的 Rancher Prime 组件都基于 SUSE BCI（Base Container Image）进行构建。BCI 提供了规范的 Linux Container Image 和 Language Container Image，并在镜像源头进行平安治理。在容器运行时方面，更有 SUSE NeuVector 进行产品级的整合，进一步晋升 Rancher Prime 的综合平安能力。 Rancher Prime 引入了 UI Extension 性能，提供了灵便的 UI 扩大形式。企业用户通常会有一些 UI 扩大需要，但又不心愿影响其追随 Rancher 主线版本进行演进，UI Extension 机制能够很好地解决这一问题。 用户能够更新 Extension 的版本，并利用在不同阶段的 Rancher Prime 版本上，让 Kubernetes 治理平台和其余外部服务更好地交融，对立外围性能与扩大性能的操作体验。 SUSE 中国始终奉行产品本地化的治理准则，面向国内企业的利用场景，Rancher Prime 也更具劣势。不仅减少了高性能容器网络、审计日志、GPU 治理、Harbor 对接等性能，在生态兼容方面也有很多加强。 ...

作者简介邓宇星，SUSE Rancher 中国区软件架构师，6 年云原生畛域教训，参加 Rancher 1.x 到 Rancher 2.x 版本迭代，目前负责 Rancher For openEuler(RFO) 我的项目开发。最近咱们关注到一个对于 containerd 运行时的 issue，该问题在 containerd v1.6.9/v1.5.15 被引入。呈现的问题是，当 containerd 重启后，在其中运行的 Pod 元数据中对于网络相干的数据（如 pod ip）失落，外围起因在于局部数据没有落盘。   受影响的版本： v1.6.9 ~ v1.6.14，问题在 v1.6.15 版本中被修复。v1.5.15 ~ v1.5.16，问题在 v1.5.17 版本中被修复。通过以下步骤，能够疾速重现该问题，并验证该问题的修复状况。 本文应用 rke2 为例进行演示，版本为 rke2 v1.24.9+rke2r1，该版本应用了 k3s-containerd v1.6.12-k3s1，受该 containerd 问题影响。 在 containerd 的默认行为中，重启 containerd 服务不会影响正在运行的业务容器，并在启动容器时，通过将容器父过程绑定 Pid 1 的形式进行体现。即便应用 systemctl 对服务进行重启，也不会影响到曾经在运行的容器状态。 问题重现# 配置rke2应用国内镜像仓库下载镜像mkdir -p /etc/rancher/rke2echo "system-default-registry: registry.cn-hangzhou.aliyuncs.com" > /etc/rancher/rke2/config.yaml# 应用命令装置 rke2，以下命令应用了咱们在国内保护的 rke2 装置镜像脚本，会从aliyun OSS下载RKE2资源curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/rke2/install.sh | INSTALL_RKE2_MIRROR=cn INSTALL_RKE2_VERSION=v1.24.9+rke2r1 sh -# [INFO] using v1.24.9-rke2r1 as release# [INFO] downloading checksums at https://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/sha256sum-amd64.txt# [INFO] downloading tarball at https://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/rke2.linux-amd64.tar.gz# [INFO] verifying tarball# [INFO] unpacking tarball file to /usr/local# 启动 rke2 服务，并期待服务启动胜利systemctl start rke2-server# 配置 rke2 相干的 PATH 门路以及 kube-config 门路export KUBECONFIG=/etc/rancher/rke2/rke2.yamlexport PATH=/var/lib/rancher/rke2/bin:$PATH# 应用 kubectl 查问以后集群状态kubectl get po -A | grep rke2-metrics-server-5b987d776b-gqxv9# kube-system rke2-metrics-server-5b987d776b-gqxv9 1/1 Running 0 15m至此，rke2 单节点服务启动实现，但咱们的指标是 containerd，接下来持续操作： ...

作者简介张智博，SUSE Rancher 大中华区研发总监，始终沉闷在研发一线，经验了 OpenStack 到 Kubernetes 的技术改革，在底层操作系统 Linux、虚拟化 KVM 和 Docker 容器技术畛域都有丰盛的研发和实践经验。以 Rancher 为外围的 SUSE 企业容器业务，在 2022 年经验了疾速倒退的一年。咱们在寰球的客户数量进一步增长，并持续放弃高水平的续约率。借助精准的产品定位和开源的继续深耕，Rancher 依然是业界宽泛采纳的容器治理平台。 让咱们疾速回顾 2022 年的要害主题，同时理解一些 2023 年的产品打算。 多云采纳比例持续上升放心被繁多云厂商技术锁定，新经济局势下的 FinOps 需要，试图加强本身的议价权等等，这些变动促使越来越多的企业采纳多云策略。然而，多云也带来了新的技术妨碍，如何应答多云的差异性？ 面向多云部署利用，应用 Kubernetes 作为基础设施，很大水平上解决了其中的局部问题，关键在于Kubernetes API 在肯定水平上屏蔽了多云带来的差别。在所有的 Kubernetes 落地形式中，私有云的 Kubernetes 托管服务曾经占据了最大的市场份额。而 Rancher 最为外围的理念，就是致力于多云多 Kubernetes 集群治理，从诞生之初至今从未波动。 平安成为焦点容器治理市场在 2022 年趋于成熟，容器平安成为了焦点。企业用户和开源社区愈发依赖混合云、多云和边缘基础设施，这也带来了肯定的平安危险。 在这一畛域，NeuVector 是咱们的要害，它专一于解决 Kubernetes 集群的平安问题，冀望给用户带来零信赖的应用体验。从收买 NeuVector 到 100% 开源，SUSE 践行了始终如一的开源价值观，也通过开源的形式推动了平安技术的倒退。 在平安畛域，咱们也在扩大新的幅员： Kubewarden：咱们将其捐献给了 CNCF，它当初是一个 CNCF 沙箱我的项目，是一套可用于 Kubernetes 的策略引擎。用户可依靠 Kubewarden 治理 Kubernetes 集群的策略，从而升高危险。Rancher Prime：这是基于 Rancher 社区版构建的商业产品，它更适宜企业用户。除了性能扩大外，也为企业用户建设了可信的镜像仓库，并继续治理 Rancher 依赖组件的 CVE。ARM 反对迈入企业级简直所有的云厂商都推出了 ARM 实例，并踊跃将本身根底服务向 ARM 迁徙，这一趋势推动了 ARM 的遍及。整个 Kubernetes 生态都在积极响应这种变动，SUSE 也在其中，并致力于让本身产品的 ARM 反对迈入企业级赛道。 ...

很快乐可能以 Longhorn 1.4 的最新版开启新的一年。该版本蕴含了许多新性能和加强性能，让云原生企业存储更简略，更容易被云原生社区承受。对于 Longhorn 的现有用户，这个最新版本的重点是帮忙您在整个存储策略中构建更高的价值和弹性。 Longhorn 1.4 是一个次要版本，包含 16 个全新的加强性能、51 个现有性能改良和 96 个 bug 修复，以下是一些亮点。 ReadWriteMany Support GA首先，咱们有两个重要的性能变为广泛可用 (GA)：ReadWriteMany 反对和 ARM64 反对。自 2019 年 Longhorn GA 以来，ReadWriteMany (RWX) 反对是 Longhorn 最受欢迎的性能之一。通过在同一平台中联合对块和文件的本地反对，Longhorn 当初能够反对组织内日益多样化的存储场景。 ARM64 Support GA从 Longhorn v1.1.0 开始，ARM64 始终是试验性的。在收到了许多用户反馈，并通过大量测试后，ARM64 反对曾经稳固，合乎咱们定期回归测试的要求，咱们发表 ARM64 反对正式 GA！ 正如用户反馈的那样，无论是在数据中心还是在边缘，基于 ARM 的基础设施都变得越来越重要。随着对边缘计算的需要一直减少，在硬件对环境功率和温度敏感的状况下，ARM 的体现十分好。 总之，Longhorn 对 ARM 的反对是一种架构和设计，它将存储和计算交融在一起，而不是传统的存储阵列办法，这使它成为下一代存储用例的现实抉择。 Volume Bit-rot 爱护随着存储系统的增长和老化，Bit-rot 和数据损坏让大家十分放心。为了解决这个问题，Longhorn 团队引入了快照校验和性能，能够验证存储系统中不同数据正本的完整性。Bit-rot 爱护性能还能够定期计算和查看卷快照的校验和，确认是否有正本产生了损坏。如果发现损坏，则从已知的良好正本中重建该正本。 TRIM 反对TRIM 反对对卷占用的主机文件系统进行修剪。传统文件系统的设计是心愿反对它的物理介质不会放大。引入 TRIM 是为了容许文件系统告知块设施：一个块当初未应用并且能够重复使用。就 Longhorn 我的项目而言，当初能够回收以前无奈应用的空间，即便它代表的文件已被删除。 例如，如果您向一个 Longhorn 卷写了 100MB，而后删除了 98MB，即便您的文件系统会疏忽这些被删除的字节，但在文件系统下 Longhorn 也不会晓得这些块被“疏忽”了，还会持续复制和保护它们。当初有了这个新性能，Longhorn 能够开释这些块，减小快照大小，并容许其余卷应用它们。 ...

K3s 和 RKE2 是 SUSE Rancher 容器平台的两个 Kubernetes 发行版，都能够运行生产就绪的集群，然而它们实用的用例不同，两者都有独特的性能。 本文将介绍这两个我的项目的相同点和差异性，帮您理解如何正当选用 RKE2 和 K3s，来满足容器化工作负载的安全性和合规性。 K3s 和 RKE2K3s 仅应用一个不到 70MB 的二进制文件来提供生产就绪的 Kubernetes 集群。K3s 十分笨重，很适宜在边缘 IoT 设施、低功耗服务器和开发工作站上运行 Kubernetes。 RKE2 也能运行生产就绪的集群。它与 K3s 一样简略易用，而且重视安全性和合规性。RKE2 是从 RKE 我的项目演变而来的，也称为 RKE Government，这个名称也反映了它实用于要求最刻薄的畛域。但它的利用范畴不仅限于政府机构，而是所有器重安全性和合规性的组织的现实抉择，因而咱们将其倒退成了当初的 RKE2。 K3s 和 RKE2 的相似之处K3s 和 RKE2 都由 Rancher 齐全反对，都是云原生计算基金会 (CNCF) 认证的 Kubernetes 发行版。尽管二者的指标用例不同，但它们的启动和操作形式相似，都能够通过 Rancher Manager 部署，而且都能应用行业标准的 containerd 运行时运行容器。 可用性K3s 和 RKE2 的装置十分不便，而且启动速度都十分快。 只需应用一条命令并期待大概 30 秒，就能够在新主机上启动 K3s 集群：   $ curl -sfL https://get.k3s.io | sudo sh -该服务已注册并启动，能够立刻运行 kubectl 命令与集群进行交互：  $ k3s kubectl get podsRKE2 也相似，能够应用一个简略的装置脚本来下载其二进制文件：  $ curl -sfL https://get.rke2.io | sudo sh -RKE2 默认不启动服务。能够运行以下命令，从而在 server（control plane）模式下启动 RKE2： ...

Rancher RFO GARFO 是 Rancher For openEuler 的缩写，旨在面向 openEuler 打造 Rancher 根底平台。其中最外围的工作是打造一款面向 openEuler 生态的 Kubernetes 发行版。它基于上游 RKE2 的技术栈，构建物采纳 openEuler base image，致力于满足国内更加重视的平安合规规范，对 openEuler LTS 版本领有优良的兼容性。 SUSE 在欧拉开源社区中成立了 RFO SIG（https://www.openeuler.org/zh/sig/sig-detail/?name=sig-rfo），以社区合作形式运作产品迭代，并将 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 的上游版本演进。 ...

作者：王海龙，SUSE Rancher 中国社区技术经理，Linux Foundation APAC Evangelist，负责 Rancher 中国技术社区的保护和经营。领有 8 年的云计算畛域教训，经验了 OpenStack 到 Kubernetes 的技术改革，无论底层操作系统 Linux，还是虚拟化 KVM 或是 Docker 容器技术都有丰盛的运维和实践经验。近期，常常有小伙伴在 K3s 社区中征询对于应用国内资源装置 K3s 的问题，本文将对此进行具体介绍。 K3s 装置和启动流程K3s 是一个轻量级的 Kubernetes 发行版，非常简单易用而且轻量。只须要一个简略的装置脚本即可把 K3s 装置到主机。 以下是应用官网装置脚本的执行过程： # curl -sfL https://get.k3s.io | sh -[INFO] Finding release for channel stable[INFO] Using v1.25.3+k3s1 as release[INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.25.3+k3s1/sha256sum-amd64.txt[INFO] Downloading binary https://github.com/k3s-io/k3s/releases/download/v1.25.3+k3s1/k3s[INFO] Verifying binary download......[INFO] systemd: Starting k3s如果从国内环境装置 K3s 可能会遇到装置速度特地迟缓或者 time out 的状况，从以上的装置过程能够剖析出以下几个起因： K3s 的装置脚本  存储在国外的服务器，从国内环境拜访可能呈现无法访问的状况。K3s 默认装置 stable 版本，stable 对应的具体 K3s 版本是通过 https://update.k3s.io/v1-rele... 解析来的，而这个地址也是运行在一个国外的服务器上。当通过 channel 解析出对应 K3s 的版本为：v1.25.3+k3s1，此时须要到 github 上拉取对应的 K3s 二进制文件。尽管这个二进制文件才几十兆，但国内环境拜访 github 常常会呈现无法访问的状况。# kubectl get pods -ANAMESPACE NAME READY STATUS RESTARTS AGEkube-system helm-install-traefik-crd-7k9rw 0/1 ContainerCreating 0 10mkube-system helm-install-traefik-8q69g 0/1 ContainerCreating 0 10mkube-system coredns-75fc8f8fff-hlx2w 0/1 ContainerCreating 0 10mkube-system metrics-server-5c8978b444-xz6vx 0/1 ContainerCreating 0 10mkube-system local-path-provisioner-5b5579c644-8g2kn 0/1 ImagePullBackOff 0 10m另外，要残缺运行 K3s，还依赖一些零碎的服务，这些零碎服务(例如：coredns、traefik)都是以容器的形式运行；而这些零碎服务依赖的零碎镜像默认是从 DockerHub 去拉取。同样从国内拜访偶然会呈现无法访问或拉取镜像迟缓的状况。 ...

linux装置和应用RancherRancher介绍请看如下博客 arm架构装置Rancher并导入k8s集群解决Error: no objects passed to apply 华为云arm架构装置k8s(kubernetes)") linux下装置RancherRancher部署======监控k8s集群状态等,比Dashboard插件弱小====== 提前装置好K8S 在master上执行#如果您应用的 Rancher 2.5.x 及更新版本，须要开启特权模式装置 Rancher，请执行以下命令：docker run -d --privileged --restart=unless-stopped \ -p 80:80 -p 443:443 \ --privileged \ rancher/rancher:latestdocker run -d --privileged --restart=unless-stopped \ -p 81:80 -p 443:443 \ --privileged \ rancher/rancher:v2.5.8拜访:https://192.168.3.100/ 设置admin的明码比方: admin 右下方抉择语言:简体中文 增加集群---应用现有的 Kubernetes 集群--导入 输出集群名称: kubeedge 执行导入命令,报错:证书有效kubectl apply -f https://192.168.3.100/v3/import/csn5rw4m8t7ns5l5wmgz7srnkstwbrcfqxcxsrwss8s6ztz2jcthl2.yaml抉择最初一个导入命令,绕过证书查看curl --insecure -sfL https://192.168.3.100/v3/import/csn5rw4m8t7ns5l5wmgz7srnkstwbrcfqxcxsrwss8s6ztz2jcthl2.yaml | kubectl apply -f -报错: Error: no objects passed to apply 在执行一次 ...

作者：涂家英，SUSE 资深架构师，专一 Cloud-Native 相干产品和解决方案设计，在企业级云原生平台建设畛域领有丰盛的教训。写在后面k3s 是 SUSE 推出的为物联网和边缘计算构建的通过认证的 Kubernetes 发行版，它能够帮忙用户在资源受限的场景下应用 kubernetes，并联合 SUSE Rancher 实现云边协同。 将 k3s 与微软开源的 kubernetes 边缘我的项目 Akri 联合应用，用户就领有了在边缘环境发现和应用各种 IOT 设施的能力。 架构Akri 目前是 CNCF 的一个开源我的项目，其性能简略地说就是能够依据配置主动地寻找到相应的 iot 设施，为其创立关联的工作负载，并且通过一直地检测实现工作负载的动态变化。援用一句官网的形容为：You name it, Akri finds it, you use it. 架构如下： 蕴含了 Controller 服务、Agent 服务和 Discovery Handlers 服务以及两个 CRD 资源。 具体的组件解析能够查看官网文档：https://docs.akri.sh/architec... 上面咱们通过一个示例来更好地了解 Akri 的工作形式。 体验示例应用了官网提供的一个 OPC UA 温度计 Demo，OPC UA 是当初应用比拟宽泛的工业自动化通信协议，咱们能够通过 Akri 主动发现应用 OPU CA 协定的温度计设施，并为其创立工作负载，采集和应用其产生的温度数据。 示例中体现的大抵工作流程如下： 首先须要模拟出两台 OPC UA 的服务设施，而后在 k3s 集群上部署 Akri 服务，根底工作实现后： ...

作者万绍远，CNCF 基金会官网认证 Kubernetes CKA&CKS 工程师，云原生解决方案架构师。对 ceph、Openstack、Kubernetes、prometheus 技术和其余云原生相干技术有较深刻的钻研。参加设计并施行过多个金融、保险、制造业等多个行业 IaaS 和 PaaS 平台设计和利用云原生革新领导。“大航海”时代，国内企业纷纷在出海赛道上扬帆起航。随同着业务出海，零碎也要做全球化部署，私有云成为了出海企业的首选。 然而，Kubernetes 在企业落地过程中依然面临诸多挑战： 须要经验丰富的 IT 人员对 Kubernetes 集群进行部署、降级、监控， 确保系统可靠性。多个 Kubernetes 集群如何进行对立策略管理、平安管控，实现集中式的可视化管控和一致性运维 ?如何利用 Kubernetes 和周边生态技术栈，更高效地迭代和交付业务利用 ?Rancher 就是一款很好的工具，可能通过其多集群治理能力和 Kubernetes 生命周期平安反对，帮忙出海业务进步部署效率，升高运维老本。 多集群对立纳管 业务出海须要重点评估平滑迁徙老本。容器是十分好的利用载体，诸多企业思考在海内私有云应用 Kubernetes。那么应该抉择私有云的虚拟机自建 Kubernetes？还是间接应用私有云厂商的 Kubernetes 发行版，例如 AWS EKS 或者 Azure AKS 呢？ 倡议企业应用私有云的 Kubernetes 发行版，因为它间接与私有云的基础设施进行了集成，能够更好地利用云上资源，进步部署效率，升高运维老本。以 AWS EKS 为例，应用 EKS 创立 Loadblance 类型的 Service 会主动在 AWS 中创立 ELB 负载均衡器，存储主动对接了 EBS 和 EFS。相比自建 Kubernetes 来说，升高了手动对接的操作过程。 Rancher 反对国内外支流的私有云 Kubernetes 发行版，如 EKS、GKE、ACK、CCE、TKE、AKS……用户可通过 Rancher 一键创立并纳管这些云供应商的 Kubernetes 发行版。 ...

作者简介张应罗，SUSE 资深架构师，领有 15 年架构征询工作教训，专一于 SUSE Cloud-native 相干的产品落地计划及征询方案设计。客户背景客户为国内当先的基金公司之一，领有近 8000 万客户，治理基金规模近 2 万亿元，领有国内公募和私募资管产品治理全资格、三大支柱养老金投资治理业务全资质，领有涵盖公募私募证券投资、境内与跨境投资的牌照，是业内构建产品线最迅速、产品种类最多的公司之一。 业务现状与面临的挑战以后，客户以开发、测试、运维团队各司其职的形式，保障各个业务零碎的开发、上线、运行。业务零碎采纳外购与自研的模式，其中自研利用多基于 SpringBoot 架构。在测试环境中，业务零碎次要采纳脚本式流水线的形式进行继续集成和继续交付，准生产和生产环境采纳手工形式。大部分业务零碎间接运行在 Linux 虚拟机中，个别业务零碎以 Docker 容器的模式运行。现有应用 GPU 资源的业务利用间接部署在独立的物理机上。 客户面临的次要挑战包含：工夫长：一次零碎上线，须要开发测试、准生产、生产环境中反复搭建，且存在配置不统一的状况。效率低：从开发测试到生产上线、运维整个流程中，存在大量跨部门合作，以及大量的手工操作，未实现端到端的交付和一体化治理。迭代慢：软件的架构适宜整体迭代，不适宜进行模块化的疾速更新，新性能、新个性难以疾速投入生产。观测弱：业务服务之间的通信，如调用关系、服务响应工夫、失败率等重要指标，需利用自行解决。资源利用率低：每个应用 GPU 的利用独自占用一台物理机，GPU 资源使用率长期处于低水位，无奈共享应用。客户需要客户亟需通过新技术降本增效、助力业务翻新。在进行一系列技术摸索之后，客户打算构建一套以 Kubernetes、DevOps、服务网格为外围的 PaaS 平台来改善现状： 以容器为外围，疾速提供统一的开发测试、准生产和生产环境，反对业务疾速在 K8s 中部署和运行，同时由 K8s 解决 GPU 资源的共享问题。以 CI/CD 流程为外围，实现开发、测试、生产全流程交付，并确保利用信息、介质等的一致性，缩短开发测试阶段和生产阶段的上线工夫。以微服务为外围，实现服务之间的流量治理、可观测性、平安、灰度公布等性能。SUSE 的解决方案容器治理平台客户将以 SUSE Rancher 为外围的容器治理平台作为 PaaS 平台的底座，根据网络安全区域划分为开发测试、准生产和生产环境，在 SUSE Linux 12 SP5 服务器上别离构建了三个 K8s 集群和一个应用 GPU 的 K8s 集群。在 K8s 集群外部 Istio 服务网格，提供了针对服务的流量管控、指标观测、认证鉴权、灰度公布等能力。 GPU 共享调度客户通过 SUSE Rancher，在具备 GPU 显卡的物理机上创立 K8s 集群，在其上部署应用 GPU 资源的业务利用，利用 SUSE Rancher 提供的 GPU 共享调度能力，实现了多个利用同时应用一块 GPU 显卡的性能，等同硬件资源可承载更多业务利用。 ...

作者：刘研，SUSE UI 工程师介绍Rancher Dashboard UI， 又名 Cluster Explorer， 是应用 Vue.js 和 NuxtJS 构建的 Rancher API 的 ”无状态” 客户端。它通常被构建和打包为动态 HTML/CSS/JS 文件，这些文件捆绑到 Rancher 发行版中。 登录用户能够治理所有被受权拜访的 k8s 集群资源，并能够对大部分类型资源以表单的形式进行编辑，而不是编辑 YAML。 概述Rancher Dashboard UI 团队非常重视前端用户的应用体验，每次发版都会让 Rancher Dashboard UI 的性能进一步优化，让 Rancher Dashboard UI 操作更加晦涩，资源显示更加疾速，资源占用进一步缩小。 随着集群规模一直变大，资源数量越来越多，局部用户开始发现 Rancher Dashboard UI 页面显示速度变得迟缓，长时间停留在 loading 页面，针对这个问题 Rancher Dashboard UI 从 v2.6.7 版本开始将这部分优化设置裸露进去，给用户更多的自主权。本文将介绍两种改善页面显示速度、进步 UI 响应性能的设置。 一、增量加载Rancher Dashboard UI v2.6.7 版本开始反对启用或禁用增量加载数据性能，并可设置对应的阈值，如果资源数量超出阈值，则进行增量加载数据。预计在 v2.6.9 版本中将默认启用该性能。 启用资源增量加载后： 大数据量下，进入相干资源页面不必再期待所有数据都返回后再显示页面，即用户不必再长时间面对 loading 页面了，能够更快地进入页面看到数据。增量加载数据，进度可视化。能够看到以后加载进度(每个版本升级都可能对加载进度 UI 进行改善，留神关注)。 增量加载资源阈值可配。用户能够依据理论状况，比方网络速度、资源总量等状况，设置资源在大于多少数量时，启用增量加载。 启用增量加载后，前端会分页加载资源，防止一次申请加载过多资源，让前端用户长时间期待，同时防止减少后端服务的内存压力和网络压力，两全其美。 ...

作者：Vishal Ghariwala，SUSE 亚太及大中华区 CTO超交融是服务器虚拟化和 VSAN 存储的必然倒退后果。通过将存储、计算和网络这三大因素相集成，实践上数据中心对基础设施的控制能力能够有限扩大。这与超大规模运营商的倒退指标高度符合，可能满足他们越来越多的需要，并实现基础设施的现代化，从而放弃充沛的灵活性。 超交融基础设施 (HCI) 具备杰出的灵活性和可扩展性，可依据应用状况弹性匹配不同客户的业务需要，使其可能实现多种应用程序和服务的部署。 对于 HCI 须要留神的是：领有能有限扩大的控制能力诚然令人向往，但它始终受限于一些基础设施的细节，比方本地存储资源的欠缺，以及速度迟缓的网络硬件限度了输出/输入的数据量。而且，HCI 供应商设置的一些限定条件会限度虚拟机监控程序的性能，或者导致满足认证套件运行需要的硬件抉择变少。 很显然，超交融基础设施齐全是在云层面实现的。现在的技术倒退速度整个科技领域引人注目，以 Kubernetes 为代表的云原生技术曾经展示了在云、数据中心和边缘环境中的弱小性能和发展潜力。HCI 的概念在问世之初曾被当作是一项数据中心技术，在过后只有领有独立设施的宏大组织才有能力进行部署。这些设施形成了高效的数据闭环，但受限于实体资源。 当今的超大规模基础设施服务提供商曾经可能以十分经济的价格，为远比从前更加宽泛的市场提供云基础设施服务。在将来几年内，预计HCI 解决方案的市场将大幅增长，年均增幅可达近 30%[1]。 供应商纷纷通过升高设施售价和许可证层级来抢占中端市场，并将超交融技术与混合云和多云模式相结合。后者是适应客户需要的后果。毕竟如果有 IT 团队心愿通过合并堆栈来提高效率和简化治理，那么在合并时本地硬件、容器、多云和边缘设施等所有资源都必须包含在内。这种能力也体现了其内在的灵活性，并且借助代理服务器，也能在肯定水平上满足将来的需要。 基于容器的相干云原生技术绝非过眼云烟。CNCF 2021 年度调研[2]显示，容器和 Kubernetes 曾经成为支流技术。曾经采纳或正在评估 Kubernetes 的组织占比高达 96%。另外，93% 的受访者示意其目前已将容器利用于生产环境或者具备这方面的打算。便携、可扩大、运行平台不受限的容器势必会成为虚拟化技术接下来的倒退方向。CI/CD 工作流程正在越来越多地通过其外围外部的微服务实现。 那么在一直演变的计算环境中，超交融有着怎么的前景？HCI 解决方案如何解决现代化的云原生工作负载以及依靠于分布式基础设施的泛滥虚拟机 (VM)？尽管能够通过“传统的”超交融模式实现，但这种针对性的专属解决方案会产生昂扬的费用。 SUSE 推出的 Harvester[3]是一款完全免费的现代化超交融基础设施开源解决方案，它以 Kubernetes、Longhorn 和 Kubevirt 等云原生解决方案作为构建根底。 Harvester 立足于 Kubernetes 之上，为传统 HCI 软件和古代云原生生态系统搭建了桥梁。它能将运行云原生工作负载的虚拟机进行全面整合，并为组织提供一个创立、监控和管制整个计算-存储-网络堆栈的对立节点。 因为容器能够在从 SOC ARM 开发板到超级计算集群的任何环境下运行，因而对于工作负载遍布于数据中心、私有云和边缘地位的组织来说，Harvester 堪称绝佳抉择。它占用的空间很小，这一点非常适合边缘环境，而且配合 SUSE Rancher 可能实现对边缘地位的所有虚拟机和容器工作负载的集中管理。 在将 IT 服务向全新环境扩大时，虚拟机、容器和 HCI 都是极为重要的技术。Harvester 采纳与现代化云原生 CI/CD 生产线无缝对接的企业级开源软件，可能助力组织实现上述关键性技术的交融，并在无需专门闭合解决方案的状况下实现 HCI 的部署。

介绍以平安、麻利且高效的形式治理资源始终是一个难题，因而，Openstack 和 Harvester 等解决方案将硬件基础设施作为本地云基础设施来解决，让用户更灵便地治理存储、计算和网络资源，而不是仅在单个硬件上部署应用程序。 Openstack 和 Harvester 都有本人的用例。本文从基础设施治理、资源管理、部署和可用性这几个维度剖析了 OpenStack 和 Harvester 的区别，旨在帮您找到满足需要的最佳计划。 云治理指的是如何治理数据中心资源（存储、计算和网络资源）。Openstack 提供了治理这些资源的办法，并为管理员提供了用于创立虚拟机的仪表板以及管理网络和存储层的其它工具。 尽管 Harvester 和 OpenStack 都用于创立云环境，然而本文探讨的是二者的不同之处。 依据 OpenStack 产品文档，OpenStack[1]是一个云操作系统，它能通过仪表板治理整个数据中心的大量计算、存储和网络资源，管理员可能管制该仪表板，同时能让用户通过 Web 界面配置资源。 Harvester 是专为古代云原生环境设计的下一代开源超交融基础架构（HCI）解决方案，应用 KubeVirt [2]技术来提供具备 Kubernetes 劣势的云治理能力。Harvester 能帮忙操作人员整合和简化 Kubernetes 集群的虚拟机工作负载。 架构OpenStack 提供用来创立 controlplane 和配置基础设施的服务，而 Harvester 则应用以下技术提供所需的堆栈： Harvester 通过 ISO 或 PXE 作为节点操作系统装置，它应用 RKE2 作为 SUSE Linux Enterprise Server 上的容器编排器，提供 Longhorn 分布式存储和 KubeVirt 虚拟化性能。 API无论是生产环境还是测试环境，API 的应用对编程交互、自动化和新性能实现的影响都是十分大的。 Openstack 在每个服务中都为性能提供了多个 API，用于在内部提供存储、治理、身份验证等性能。文档[3]的逻辑架构概述了 API 的实现： 您能够在上图加粗局部看到生产环境中 Openstack 提供的 API。 尽管 OpenStack 很简单，然而它反对高级别的自定义设置。 ...

作者姚灿武，SUSE Rancher 研发工程师，领有 6 年云计算畛域教训，热衷开源技术，在云原生相干技术畛域领有丰盛的开发和实践经验。本文整顿自姚灿武在 SUSECON 北京 2022 开源技术峰会上的主题演讲。本文将通过 BMW 的边缘案例，从边缘的角度为大家介绍 Harvester，并分享 SUSE Rancher 中国团队对于边缘基础设施的一些思考。 边缘场景分类边缘这个概念往往比拟含糊，分类能够帮忙咱们清晰地界定和了解咱们所面对的问题，从而给出更失当的解决方案。SUSE 将边缘场景分为三类，别离是： Near Edge: 次要是指电信、媒体和通信畛域，凑近外围数据中心，数量比拟少，个别就是在 10 ~ 100 之间；Far Edge：指商超、工产生产车间以及公共部门等场景，间隔外围数据中心较远，个别数量在 100 ~ 10,000 之间；Tiny Edge: 指各种各样的终端设备，比如说汽车、工厂里的机械手臂等，通常与 Far Edge 部署在同一个空间。 BMW 边缘需要与计划BMW 边缘场景是一个典型的 FAR Edge 例子，次要蕴含以下三点需要： 环境部署：要求部署在边缘数据中心（车辆制造厂、测试站等）的裸金属服务器上；扩展性和容错性：要求可能扩大到几台甚至数十台服务器上以及特地关注容错性和利用高可用；对立治理：心愿在同一平台上治理虚拟机和容器利用。咱们为 BMW 提供的解决方案如下： 这个计划次要的思路是： 在裸金属服务器上安装 Harvester，满足环境部署要求以及扩展性要求；在 Harvester 之上启动传统虚拟机和 Kubernetes（人造满足利用高可用） ，用于部署虚拟机和容器利用；Harvester 集成到 Rancher 中，使 Rancher 成为对立治理平台。对于 Harvester从上图能够看出，Harvester 是上述计划的重要组成，接下来给大家具体介绍一下 Harvester。 一句话概括，咱们能够说： Harvester 是云原生时代的开源 HCI 软件解决方案如果用三句话，咱们能够说： 首先，Harvester 是基于云原生技术构建的 HCI 开源软件计划；其次，Harvester 应用了定制化的容器操作系统；最初， Harvester 与 Rancher 深度集成能够带来对立的治理体验。这三点中，第一点立根云原生生态是外围，第二点和第三点是对云原生技术的深度应用和延长。 ...

What?SUSE BCISUSE BCI（Base Container Image）提供了一个基于 SUSE Linux Enterprise Server 的、通过测试和认证的容器镜像仓库，仓库中的容器镜像能够在企业生产环境中应用。 SUSE 的容器镜像和应用程序开发工具是真正凋谢、灵便和平安的。SUSE 会定期维护这些镜像，应用最新的安全补丁更新镜像，它们的性能与根本操作系统版本统一，开发人员、集成商和操作人员能够随时应用。 用户能够从 SUSE Container Registry 获取 BCI 镜像，并依据 EULA 自行进行复制、应用和散发。 Rancher 2.6 公布后，SUSE 发表齐全集成 Rancher 和 BCI，并且确保合乎最新的平安规范。 BCI 蕴含什么？BCI 蕴含两组容器镜像： 单纯基于 SLE 的容器，容器具备最小软件包集，其中一个带有 Zypper，一个不带 Zypper 但带有 RPM，另一个不带 Zypper 和 RPM，这减少了开发环境的灵活性，删除了不必要的包，并放慢了应用程序的部署和编排。语言堆栈容器镜像，其根底环境能用于 Python、Node.js、Ruby、.NET、ASP.Net、Java（基于 OpenJDK）、Go 和 Rust 等编程语言。应用程序堆栈容器镜像，能提供现成的容器化应用程序（如 RMT 和 PostgreSQL）。BCI 的劣势是什么？可用性：BCI 可用于 x86-64、arch64、s390x 和 ppc64le。安全性：容器镜像更平安，能缩小容器破绽扫描程序的告诉数量。BCI 用例是什么？BCI 提供了一个稳固、平安和凋谢的生态系统，用户能够在轻量灵便的环境中开发和部署应用程序，还能利用 SLES（SUSE Linux Enterprise Server）操作系统的稳定性和安全性。 另一方面，BCI 提供了以下机会： Rancher 用户：①让 Rancher 可能应用稳固、牢靠、平安和认证的企业组件进行构建。②利用 SUSE 外部操作系统常识，同时将应用程序容器化。这是因为工具是雷同的，不须要迁徙门路（例如，因为 BCI 会作为容器根底，因而用户能够将 Zypper 转为其它包管理器）。开发者：①如果用户不想为云原生环境进行付费订阅，则能够抉择收费的 BCI。②BCI 能够部署在任何操作系统中，能帮忙用户在多云厂商生态系统内迁徙并防止云厂商锁定。ISV（Independent Software Vendor）：①应用稳固、牢靠、平安且通过认证的企业级操作系统来容器化应用程序。②应用收费的 Linux 来构建应用程序，无需在链中提供反对和平安服务。③容器化时进行导航（软件、工具、文档、征询）。④在各种主机上运行应用程序。BCI 中提供了哪些软件包和库？SUSE 提供了多种 BCI，开发人员能够随时抉择合乎需要的 BCI。同时，开发人员能够应用出名的工具和库，如编译器、加密库以及多种操作系统工具等，如下： ...

前言前文搭建了高可用的Kubernetes集群，原本布局持续摸索理论中的利用部署以及如何革新现有的技术架构使Kubernetes初步落地。不过在搭建完集群后，还是不可遏制的想找寻一款图形化管理工具，毕竟我的关注点更多在于如何把现有技术架构和流程向云原生做落地，过于繁琐和简单的命令行运维形式目前并不适宜我。 于是发现了Rancher。通过初步的信息检索，不管从Rancher的技术方向、知名度、社区活跃度、以及平台技术能力都算得上优良和支流，所以交叉了这部分的内容的学习。 Rancher次要的知识点起源自官网文档，官网文档还算八面玲珑和具体，英文好的也能够对照英文文档，轻微上还是有些小差异。 整体架构那么对于应用Rancher自身以及被治理集群架构，我画了一张架构图 Rancher高可用装置首先咱们须要做的是Rancher的装置，Rancher反对多种装置形式，最简略的就是单机装置，应用docker跑个镜像就行。我应用的是高可用装置形式。最新版本的2.5曾经反对了将Rancher装置在各种Kubernetes集群上，比方现有的Kubernetes集群，或者RKE、K3s、Amazon EKS等等。并且官网倡议为了性能，最好将该Kubernetes集群专门用于运行Rancher。 通过简略的比照，最终决定应用Rancher自家推出的K3s来部署Rancher利用。Kubernetes 和 K3S 是什么关系呢，官网原话： k3s 旨在成为齐全兼容的 Kubernetes 发行版，相比 k8s 次要更改如下： 旧的、Alpha 版本的、非默认性能都曾经删除。删除了大多数外部云提供商和存储插件，能够用插件替换。新增 SQLite3 作为默认存储机制，etcd3 依然无效，然而不再是默认项。封装在简略的启动器中，能够解决大量 LTS 复杂性和选项。最小化到没有操作系统依赖，只须要一个内核和 cgroup 挂载。并且K3s是一个符合标准的、已获CNCF官网认证的Kubernetes发行版，在开发环境或者轻量级需要时劣势显著。 筹备工作Mysql内部数据库 K3s应用 etcd 以外的数据存储运行 Kubernetes，使得某种意义上更加灵便，咱们能够应用现成的数据库，例如Mysql，这里须要创立一个Mysql数据库。 负载平衡 当咱们的Rancher节点运行在K3s上时，须要一个负载均衡器将流量疏导到多个节点上。官网示例应用nginx做L4负载平衡，配置文件如下： worker_processes 4;worker_rlimit_nofile 40000;events { worker_connections 8192;}stream { upstream rancher_servers_http { least_conn; server 10.128.2.53:80 max_fails=3 fail_timeout=5s; ##rancher节点 server 10.128.2.52:80 max_fails=3 fail_timeout=5s; } server { listen 80; proxy_pass rancher_servers_http; } upstream rancher_servers_https { least_conn; server 10.128.2.53:443 max_fails=3 fail_timeout=5s; server 10.128.2.52:443 max_fails=3 fail_timeout=5s; } server { listen 443; proxy_pass rancher_servers_https; }}启动nginx时须要开启stream模块。 ...

kubectl负责master和节点（node）之间的通信、交互和数据上报 到master的apiserver 整体来讲 的职责是1、Node治理 2、pod治理 3、容器健康检查4、容器监控5、资源清理6、和容器运行时交互(docker 、rkt、Virtlet等等) 个别状况下kubectl会裸露 10250端口 用于和apiserver 交互罕用的查问APIGET /pods/stats/summary/metrics/healthz 拜访形式：docker exec -it kubelet curl -k https://localhost:10250/healthz --header "Authorization: Bearer kubeconfig-user-mtxnk.c-gfv2c:h86t2zzpjcq8lksd82l24l6ld7pkdwsh4264thvbfxldntkmdmf2c8" kube-proxy内部通过NodePort、ClusterIP等形式拜访服务。 kube-proxy 运行在每个Node 上，负责Pod网络代理, 保护网络规定和四层负载平衡工作 kube-controller-manager在master中。 kube-controller-manager负责节点治理、pod复制和endpoint创立. 监控集群中各种资源的状态使之和定义的状态保持一致,. 如:节点控制器（Node Controller）: 负责在节点呈现故障时进行告诉和响应。 正本控制器（Replication Controller）: 负责为零碎中的每个正本控制器对象保护正确数量的 Pod。(当初是Deployment Controller+Replication Set) apiVersion: apps/v1kind: Deploymentmetadata: name: myngx namespace: mywebspec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginxtest image: nginx:1.18-alpine # 只有镜像不存在时进行镜像拉取 imagePullPolicy: IfNotPresent ports: # Pod 端口 - containerPort: 80kubectl create -f ngx.yaml ...