最佳实践

• 1: 运行于多可用区环境
• 2: 大规模集群的注意事项
• 3: 校验节点设置
• 4: PKI 证书和要求
• 5: 强制实施 Pod 安全性标准

1 - 运行于多可用区环境

本页描述如何跨多个区（Zone）中运行集群。

背景

Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行， 通常这些区位于某个称作 区域（region） 逻辑分组中。 主要的云提供商都将区域定义为一组失效区的集合（也称作 可用区（Availability Zones））， 能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。

典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。

控制面行为

所有的控制面组件 都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。

当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。 如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个 控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本， 跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将 该组件跨所选的三个失效区来部署。

节点行为

Kubernetes 自动为负载资源（如Deployment 或 StatefulSet)） 跨集群中不同节点来部署其 Pods。 这种分布逻辑有助于降低失效带来的影响。

节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象 添加 标签。 这些标签可能包含区信息。

如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 Pod 拓扑分布约束 来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是 地理区域、可用区甚至是特定节点。 这些提示信息使得调度器 能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载 带来的风险。

例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在 不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束， 而不需要显式指定每个工作负载使用哪些可用区。

跨多个区分布节点

Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用 类似 Cluster API 这类工具来替你管理节点。

使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群 工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。

为 Pods 手动指定区

你可以应用节点选择算符约束 到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源 中的 Pod 模板设置此类约束。

跨区的存储访问

当创建持久卷时，PersistentVolumeLabel 准入控制器 会自动向那些链接到特定区的 PersistentVolume 添加区标签。 调度器通过其 NoVolumeZoneConflict 断言确保申领给定 PersistentVolume 的 Pods 只会 被调度到该卷所在的可用区。

你可以为 PersistentVolumeClaim 指定StorageClass 以设置该类中的存储可以使用的失效域（区）。 要了解如何配置能够感知失效域或区的 StorageClass，请参阅 可用的拓扑逻辑。

网络

Kubernetes 自身不提供与可用区相关的联网配置。 你可以使用网络插件 来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。 例如，如果你的云提供商支持 type=LoadBalancer 的 Service，则负载均衡器 可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。 请查阅云提供商的文档了解详细信息。

对于自定义的或本地集群部署，也可以考虑这些因素 Service Ingress 的行为， 包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。

失效恢复

在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何 恢复服务。例如，你是否要求在某个区中至少有一个节点能够运行 Pod？ 请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。 例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job， 该 Job 要设置特定的容忍度 以便修复操作能够至少将一个节点恢复为可用状态。

Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。

接下来

要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅 调度与驱逐。

2 - 大规模集群的注意事项

集群是运行 Kubernetes 代理的、 由控制平面管理的一组 节点（物理机或虚拟机）。 Kubernetes v1.23 支持的最大节点数为 5000。 更具体地说，Kubernetes旨在适应满足以下所有标准的配置：

• 每个节点的 Pod 数量不超过 110
• 节点数不超过 5000
• Pod 总数不超过 150000
• 容器总数不超过 300000

你可以通过添加或删除节点来扩展集群。集群扩缩的方式取决于集群的部署方式。

云供应商资源配额

为避免遇到云供应商配额问题，在创建具有大规模节点的集群时，请考虑以下事项：

• 请求增加云资源的配额，例如：
  • 计算实例
  • CPUs
  • 存储卷
  • 使用中的 IP 地址
  • 数据包过滤规则集
  • 负载均衡数量
  • 网络子网
  • 日志流
• 由于某些云供应商限制了创建新实例的速度，因此通过分批启动新节点来控制集群扩展操作，并在各批之间有一个暂停。

控制面组件

对于大型集群，你需要一个具有足够计算能力和其他资源的控制平面。

通常，你将在每个故障区域运行一个或两个控制平面实例， 先垂直缩放这些实例，然后在到达下降点（垂直）后再水平缩放。

你应该在每个故障区域至少应运行一个实例，以提供容错能力。 Kubernetes 节点不会自动将流量引向相同故障区域中的控制平面端点。 但是，你的云供应商可能有自己的机制来执行此操作。

例如，使用托管的负载均衡器时，你可以配置负载均衡器发送源自故障区域 A 中的 kubelet 和 Pod 的流量， 并将该流量仅定向到也位于区域 A 中的控制平面主机。 如果单个控制平面主机或端点故障区域 A 脱机，则意味着区域 A 中的节点的所有控制平面流量现在都在区域之间发送。 在每个区域中运行多个控制平面主机能降低出现这种结果的可能性。

etcd 存储

为了提高大规模集群的性能，你可以将事件对象存储在单独的专用 etcd 实例中。

在创建集群时，你可以（使用自定义工具）：

• 启动并配置额外的 etcd 实例
• 配置 API 服务器，将它用于存储事件

有关为大型集群配置和管理 etcd 的详细信息，请参阅 为 Kubernetes 运行 etcd 集群 和使用 kubeadm 创建一个高可用 etcd 集群。

插件资源

Kubernetes 资源限制 有助于最大程度地减少内存泄漏的影响以及 Pod 和容器可能对其他组件的其他方式的影响。 这些资源限制适用于插件资源， 就像它们适用于应用程序工作负载一样。

例如，你可以对日志组件设置 CPU 和内存限制

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

插件的默认限制通常基于从中小规模 Kubernetes 集群上运行每个插件的经验收集的数据。 插件在大规模集群上运行时，某些资源消耗常常比其默认限制更多。 如果在不调整这些值的情况下部署了大规模集群，则插件可能会不断被杀死，因为它们不断达到内存限制。 或者，插件可能会运行，但由于 CPU 时间片的限制而导致性能不佳。

为避免遇到集群插件资源问题，在创建大规模集群时，请考虑以下事项：

• 部分垂直扩展插件 —— 总有一个插件副本服务于整个集群或服务于整个故障区域。 对于这些附加组件，请在扩大集群时加大资源请求和资源限制。
• 许多水平扩展插件 —— 你可以通过运行更多的 Pod 来增加容量——但是在大规模集群下， 可能还需要稍微提高 CPU 或内存限制。 VerticalPodAutoscaler 可以在 recommender 模式下运行， 以提供有关请求和限制的建议数字。
• 一些插件在每个节点上运行一个副本，并由 DaemonSet 控制： 例如，节点级日志聚合器。与水平扩展插件的情况类似， 你可能还需要稍微提高 CPU 或内存限制。

接下来

VerticalPodAutoscaler 是一种自定义资源，你可以将其部署到集群中，帮助你管理资源请求和 Pod 的限制。 访问 Vertical Pod Autoscaler 以了解有关 VerticalPodAutoscaler 的更多信息， 以及如何使用它来扩展集群组件（包括对集群至关重要的插件）的信息。

集群自动扩缩器 与许多云供应商集成在一起，帮助你在你的集群中，按照资源需求级别运行正确数量的节点。

addon resizer 可帮助你在集群规模变化时自动调整插件的大小。

3 - 校验节点设置

节点一致性测试

节点一致性测试 是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。

该测试主要检测节点是否满足 Kubernetes 的最低要求，通过检测的节点有资格加入 Kubernetes 集群。

节点的前提条件

要运行节点一致性测试，节点必须满足与标准 Kubernetes 节点相同的前提条件。节点至少应安装以下守护程序：

• 容器运行时 (Docker)
• Kubelet

运行节点一致性测试

要运行节点一致性测试，请执行以下步骤：

1. 得出 kubelet 的 --kubeconfig 的值；例如：--kubeconfig=/var/lib/kubelet/config.yaml. 由于测试框架启动了本地控制平面来测试 kubelet， 因此使用 http://localhost:8080 作为API 服务器的 URL。 一些其他的 kubelet 命令行参数可能会被用到：
   • --pod-cidr： 如果使用 kubenet， 需要为 Kubelet 任意指定一个 CIDR， 例如 --pod-cidr=10.180.0.0/24。
   • --cloud-provider： 如果使用 --cloud-provider=gce，需要移除这个参数 来运行测试。

2. 使用以下命令运行节点一致性测试：

   # $CONFIG_DIR 是您 Kubelet 的 pod manifest 路径。
   # $LOG_DIR 是测试的输出路径。
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     k8s.gcr.io/node-test:0.2
   

针对其他硬件体系结构运行节点一致性测试

Kubernetes 也为其他硬件体系结构的系统提供了节点一致性测试的 Docker 镜像：

运行特定的测试

要运行特定测试，请使用您希望运行的测试的特定表达式覆盖环境变量 FOCUS。

sudo docker run -it --rm --privileged --net=host \
   -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
   -e FOCUS=MirrorPod \ # Only run MirrorPod test
k8s.gcr.io/node-test:0.2

要跳过特定的测试，请使用您希望跳过的测试的常规表达式覆盖环境变量 SKIP。

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # 运行除 MirrorPod 测试外的所有一致性测试内容
k8s.gcr.io/node-test:0.2

节点一致性测试是节点端到端测试的容器化版本。

默认情况下，它会运行所有一致性测试。

理论上，只要合理地配置容器和挂载所需的卷，就可以运行任何的节点端到端测试用例。 但是这里强烈建议只运行一致性测试，因为运行非一致性测试需要很多复杂的配置。

注意

• 测试会在节点上遗留一些 Docker 镜像， 包括节点一致性测试本身的镜像和功能测试相关的镜像。
• 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。

4 - PKI 证书和要求

Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用 kubeadm 安装的 Kubernetes， 则会自动生成集群所需的证书。你还可以生成自己的证书。 例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。

集群是如何使用证书的

Kubernetes 需要 PKI 才能执行以下操作：

• Kubelet 的客户端证书，用于 API 服务器身份验证
• API 服务器端点的证书
• 集群管理员的客户端证书，用于 API 服务器身份认证
• API 服务器的客户端证书，用于和 Kubelet 的会话
• API 服务器的客户端证书，用于和 etcd 的会话
• 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话
• 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话
• 前端代理 的客户端及服务端证书

etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。

证书存放的位置

如果你是通过 kubeadm 安装的 Kubernetes，所有证书都存放在 /etc/kubernetes/pki 目录下。本文所有相关的路径都是基于该路径的相对路径。

手动配置证书

如果你不想通过 kubeadm 生成这些必需的证书，你可以通过下面两种方式之一来手动创建他们。

单根 CA

你可以创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。

需要这些 CA：

上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 sa.key 和 sa.pub。

所有的证书

如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。

需要这些证书：

[1]: 用来连接到集群的不同 IP 或 DNS 名 （就像 kubeadm 为负载均衡所使用的固定 IP 或 DNS 名，kubernetes、kubernetes.default、kubernetes.default.svc、 kubernetes.default.svc.cluster、kubernetes.default.svc.cluster.local）。

其中，kind 对应一种或多种类型的 x509 密钥用途：

证书路径

证书应放置在建议的路径中（以便 kubeadm使用）。无论使用什么位置，都应使用给定的参数指定路径。

注意事项同样适用于服务帐户密钥对：

为用户帐户配置证书

你必须手动配置以下管理员帐户和服务帐户：

1. 对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。

2. 为每个配置运行下面的 kubectl 命令：

KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system

这些文件用途如下：

5 - 强制实施 Pod 安全性标准

本页提供实施 Pod 安全标准（Pod Security Standards） 时的一些最佳实践。

使用内置的 Pod 安全性准入控制器

Pod 安全性准入控制器 尝试替换已被废弃的 PodSecurityPolicies。

配置所有集群名字空间

完全未经配置的名字空间应该被视为集群安全模型中的重大缺陷。 我们建议花一些时间来分析在每个名字空间中执行的负载的类型， 并通过引用 Pod 安全性标准来确定每个负载的合适级别。 未设置标签的名字空间应该视为尚未被评估。

针对所有名字空间中的所有负载都具有相同的安全性需求的场景， 我们提供了一个示例 用来展示如何批量应用 Pod 安全性标签。

拥抱最小特权原则

在一个理想环境中，每个名字空间中的每个 Pod 都会满足 restricted 策略的需求。 不过，这既不可能也不现实，某些负载会因为合理的原因而需要特权上的提升。

• 允许 privileged 负载的名字空间需要建立并实施适当的访问控制机制。
• 对于运行在特权宽松的名字空间中的负载，需要维护其独特安全性需求的文档。 如果可能的话，要考虑如何进一步约束这些需求。

采用多种模式的策略

Pod 安全性标准准入控制器的 audit 和 warn 模式（mode） 能够在不影响现有负载的前提下，让该控制器更方便地收集关于 Pod 的重要的安全信息。

针对所有名字空间启用这些模式是一种好的实践，将它们设置为你最终打算 enforce 的 期望的 级别和版本。这一阶段中所生成的警告和审计注解信息可以帮助你到达这一状态。 如果你期望负载的作者能够作出变更以便适应期望的级别，可以启用 warn 模式。 如果你希望使用审计日志了监控和驱动变更，以便负载能够适应期望的级别，可以启用 audit 模式。

当你将 enforce 模式设置为期望的取值时，这些模式在不同的场合下仍然是有用的：

• 通过将 warn 设置为 enforce 相同的级别，客户可以在尝试创建无法通过合法检查的 Pod （或者包含 Pod 模板的资源）时收到警告信息。这些信息会帮助于更新资源使其合规。
• 在将 enforce 锁定到特定的非最新版本的名字空间中，将 audit 和 warn 模式设置为 enforce 一样的级别而非 latest 版本， 这样可以方便看到之前版本所允许但当前最佳实践中被禁止的设置。

第三方替代方案

Kubernetes 生态系统中也有一些其他强制实施安全设置的替代方案处于开发状态中：

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

采用 内置的 方案（例如 PodSecurity 准入控制器）还是第三方工具， 这一决策完全取决于你自己的情况。在评估任何解决方案时，对供应链的信任都是至关重要的。 最终，使用前述方案中的 任何 一种都好过放任自流。