在生产环境中配置Kubernetes Pod的5种最佳实践

Kubernetes中的Pod代表基本部署单元。它可能包含一个或多个作为逻辑实体打包和部署的容器。在Kubernetes中运行的云原生应用程序可能包含映射到每个微服务的多个Pod。Pod也是Kubernetes中用于伸缩扩展的基本单位。

在Kubernetes中部署Pod之前，请遵循以下五个最佳实践。即使可以应用其他配置，这五个实践也是保证云原生应用程序的基本健康水平的最基本的做法。

1）选择最合适的Kubernetes控制器(controller)

虽然可能将一个容器镜像作为通用Pod部署和运行，但是您应该根据工作负载特征选择正确的控制器类型。Kubernetes有一个称为控制器的原语，它与工作负载的关键特征保持一致。Deployment、StatefulSet和DaemonSet是Kubernetes中最常用的控制器。

部署无状态Pod时，请始终使用Deployment控制器。通过扩展，部署历史记录和回滚功能，这将为你带来类似于PaaS的功能。当Deployment配置的最小副本数为2时，Kubernetes确保始终至少有两个Pod处于运行状态，这带来了容错能力。即使仅使用一个副本来部署Pod，也强烈建议您使用Deployment控制器，而不是普通的Pod规范。

对于数据库集群等工作负载，StatefulSet控制器将创建一组具有可预测的命名约定的高可用Pod。需要高可用性的有状态工作负载（例如Cassandra，Kafka，ZooKeeper和SQL Server）需用StatefulSet控制器部署在Kubernetes中。

当需要在集群的每个节点上运行Pod时，应使用DaemonSet控制器。由于Kubernetes会在新配置的工作程序节点中自动调度DaemonSet，因此它成为配置和准备工作负载节点的理想选择。例如，如果要在部署工作负载之前在节点上安装现有的NFS或Gluster文件共享，则将Pod打包并部署为DaemonSet。

部署Pod之前，请确保选择最合适的控制器类型。

2）为Pod配置健康检查

默认情况下，所有正在运行的Pod都将重新启动策略设置为”always“，这意味着在容器中遇到错误时，在节点内运行的kubelet将自动重新启动Pod。

健康检查通过容器探针的概念扩展了kubelet的这种功能。可以为每个Pod配置三个探针-Readiness、liveness和startup。

您可能会遇到Pod处于运行状态，但ready列显示0/1的情况。这表明Pod尚未准备好接受请求。Readiness探针可确保在启动Pod之前满足先决条件。例如，服务于机器学习模型的Pod需要在提供推理之前下载模型的最新版本。Readiness探针在将Pod移至就绪状态之前，将不断检查文件是否存在。同样，CMS Pod中的“readiness”探针将确保数据存储已经挂载并可访问。

liveness探针将定期检查容器的健康状况，并向kubelet报告。如果此运行状况检查失败，则Pod将不会再接收流量。该服务将忽略容器，直到liveness探针报告为肯定状态为止。例如，MySQL pod可以包括一个liveness探针，该探针可以连续检查数据库引擎的状态。

从1.16版开始，startup探针仍处于Alpha状态，允许容器等待更长的时间，然后再将运行状况检查移交给liveness探针。将旧版的启动时间较长的应用程序移植到Kubernetes时，这很有用。

所有上述健康状况监测即可配置为使用命令，也可以配置为使用HTTP探针和TCP探针。

请参阅Kubernetes 文档中有关配置运行状况检查的步骤。

3）使用初始化容器(init container)准备Pod

在某些情况下，容器需要在初始化之前进行初始化。可以将初始化工作交给另一个容器，以便在Pod变为就绪状态之前进行一些基础工作。一个初始化容器可用于下载文件，创建目录，更改文件权限，等等。

甚至可以使用一个初始化容器来确保Pod按特定顺序启动。例如，在启动WordPress Pod之前，初始化容器将等到MySQL Pod变为可用状态为止。

容器可以包含多个初始化容器，每个容器执行特定的初始化任务。

4）应用节点/Pod亲和性和反亲和性规则

Kubernetes调度程序可以根据Pod的资源需求和集群内的资源消耗，将Pod放置在关联的节点上。但是，我们也可能需要控制在节点上调度Pod的方式。Kubernetes提供了两种机制- 节点亲和性/反亲和性和pod亲和性/反亲和性。

节点亲和性是对已经很强大的nodeSelector规则进行的扩展以涵盖其他场景，就像Kubernetes anotation使标签/选择器更具表现力和可扩展性的方式一样，节点亲和性通过附加规则使nodeSelector更具表现力。节点亲和性将确保在满足特定条件的节点上调度Pod。例如，可以强制在附有SSD的节点上安排有状态数据库容器。同样，节点反亲和性将有助于避免在节点上安排可能导致问题的Pod。

尽管节点亲和性确实可以在Pod和节点之间进行匹配，但是在某些可能需要将Pod一起放置以提高性能或遵从性的场景下，Pod亲和性将帮助我们放置需要共享同一节点的Pod。例如，必须在具有Redis Pod的同一节点上调度Nginx Web服务器Pod。这将确保Web应用程序与缓存之间的低延迟。在其他情况下，您可能要避免在同一节点上运行两个Pod。部署HA工作负载时，您可能要强制在同一节点上不运行同一Pod的两个实例。Pod反亲和性将强制执行防止这种可能性的规则。

分析您的工作负载，以评估是否需要在部署中使用节点和容器亲和性策略。

5）利用自动缩放机制(auto scaler)

诸如Amazon Web Services，Microsoft Azure和Google Cloud Platform之类的超大规模云平台具有内置的自动扩展引擎，可以根据平均资源消耗或外部指标来伸或缩一组VM。

Kubernetes具有用于部署的类似自动缩放功能，包括水平容器自动缩放器（HPA），垂直容器自动缩放器（VPA）和集群自动缩放。

水平Pod自动缩放器(HPA)会根据观察到的CPU使用情况自动缩放Replication controler、deployment，replica set或stateful set中的容器数量。HPA在Kubernetes中表示为一个对象，这意味着可以通过kubectl CLI控制的YAML文件声明它。与IaaS自动缩放引擎类似，HPA支持定义CPU阈值，Pod的最小和最大实例，冷却时间甚至自定义指标。

垂直Pod自动缩放功能(VPA)消除了定义Pod的CPU和内存配置所涉及的估算。该自动缩放器可以为CPU和内存request和limit推荐适当的值，或者可以自动更新这些值。自动更新标志将决定是否驱逐现有的Pod或继续使用旧配置运行。查询VPA对象将通过上下限显示最佳的CPU和内存请求。

在HPA和VPA扩展deployment和Pod的同时，Cluster Autoscaler将扩展和缩小worker节点池的大小。它是一个独立的工具，可以根据当前利用率调整Kubernetes集群的大小。当由于资源不足而无法在当前节点上调度任何Pod时，或者当添加新节点会增加群集资源的整体可用性时，Cluster Autoscaler会增加群集的大小。在后台，Cluster Autoscaler与底层IaaS提供程序进行协商以添加或删除节点。将HPA与Cluster Autoscaler结合使用可提供最高的性能和工作负载的可用性。

本文翻译自文章“5 Best Practices for Configuring Kubernetes Pods Running in Production”。

讲师主页：tonybai_cn
讲师博客: Tony Bai
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》