Kubernetes(K8S)最佳实践

从 Kubernetes 官网摘录。
中文网址
 英文网址

大规模集群的注意事项

Kubernetes 旨在适应满足以下所有标准的配置：

每个节点的 Pod 数量不超过 110
节点数不超过 5,000
Pod 总数不超过 150,000
容器总数不超过 300,000

云供应商资源配额

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

请求增加云资源的配额，例如：

计算实例

CPU

存储卷

使用中的 IP 地址

数据包过滤规则集

负载均衡数量

网络子网

日志流
由于某些云供应商限制了创建新实例的速度，因此通过分批启动新节点来控制集群扩展操作，并在各批之间有一个暂停。

控制面组件

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

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

etcd 存储

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

插件资源

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

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

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

运行于多可用区环境

背景

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

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

控制面行为

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

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

节点行为

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

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

如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 Pod 拓扑分布约束来控制如何在你的集群中多个失效域之间分布 Pod。

跨多个区分布节点

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

为 Pod 手动指定区

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

跨区的存储访问

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

网络

Kubernetes 自身不提供与可用区相关的联网配置。你可以使用网络插件来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。

失效恢复

在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何恢复服务。

校验节点设置

节点一致性测试

节点一致性测试是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。测试验证节点是否满足 Kubernetes 的最低要求；通过测试的节点有资格加入 Kubernetes 集群。

节点的前提条件

节点至少应安装以下守护程序：

与 CRI 兼容的容器运行时，例如 Docker、Containerd 和 CRI-O
Kubelet

运行节点一致性测试

bash 复制代码

# $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 \
  registry.k8s.io/node-test:0.2

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

架构	镜像
amd64	node-test-amd64
arm	node-test-arm
arm64	node-test-arm64

运行特定的测试

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

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

注意事项

测试会在节点上遗留一些 Docker 镜像，包括节点一致性测试本身的镜像和功能测试相关的镜像。

测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。

强制实施 Pod 安全性标准

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

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

配置所有集群名字空间

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

拥抱最小特权原则

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

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

采用多种模式的策略

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

第三方替代方案

PKI 证书和要求

Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。

集群是如何使用证书的

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

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

证书存储位置

假如你通过 kubeadm 安装 Kubernetes，大多数证书会被存储在 /etc/kubernetes/pki 中。

手动配置证书

如果你不想通过 kubeadm 生成所需证书，你可以使用一个单根 CA 来创建这些证书，或者直接提供所有证书。

单根 CA

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

Kubernetes(K8S)最佳实践