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

本文将介绍5个最佳实践技巧帮助你在Kubernetes中更好地部署Pod。即使有其他配置可以采用，但万变不离其宗，这5个技巧都是最基本最核心的操作。

1、选择最合适的Kubernetes Controller

虽然可能很像将容器镜像作为通用的Pod部署和运行，但是你需要根据工作负载的特性选择正确的controller类型。在Kubernetes中有一类称为controller的原语（Primitive），它需要与工作负载的关键特性兼容。Deployment、StatefulSet和DaemonSet是Kubernetes中最常用的Controller。

当部署无状态的Pod时，通常需要使用deployment controller 。这一controller中的扩展、部署历史记录以及回滚功能使得Pod也具备类似PaaS的功能。当Deployment配置的最小副本数为2时，Kubernetes能够确保始终至少有两个Pod处于运行状态，这使得容器具有容错能力。即使仅使用一个副本来部署Pod，也强烈建议你使用Deployment Controller，而不是普通的通用Pod规范。

对于诸如数据库集群等工作负载来说，StatefulSet controller将创建一组具有可预测的命名规范的高可用Pod。 需要高可用有状态的工作负载（如Cassandra、Kafka、ZooKeeper和SQL Server）作为StatefulSet部署在Kubernetes中。

当你需要在集群的每个节点上运行一个pod，你应该使用DaemonSet controller。 由于Kubernetes会自动在新配置的worker节点中调度DaemonSet，因此它是配置和准备工作负载节点的理想选择。举个例子，如果你想在部署工作负载之前在节点上挂载一个现有的NFS或Gluster共享文件，那么你需要打包并将pod部署为DaemonSet。

因此，最后强调一下，在部署Pod之前确认你选择的是最合适的controller类型。

2、为Pod配置健康检查

默认状态下，所有正在运行的pod都会一直启用重启策略，这意味着当容器遇到错误时，在节点内运行的kubelet将自动重启Pod。

基于容器探针（Probe）的机制，kubelet的健康检查功能大大增强。 可以为每个Pod配置3类探针——Readiness、liveness以及startup。

你可能会遇到Pod处于运行状态，但ready列显示0/1的情况。这表明pod没有准备好接收请求。而 readiness探针可以确保在启动pod之前前期准备已经完成。 例如，服务于机器学习模型的pod需要在机器开始推理之前下载该模型的最新版本。Readiness探针会在pod处于准备状态之前，不断检查文件是否存在。同样，CMS pod中的readiness探针将确保已经安装好并能够访问到数据库。

Liveness探针将会预先检查容器的健康状态并报告给kubelet。 当健康检查失败，那么pod将不会接收流量。服务也会忽略该pod，直到liveness探针检测到积极状态。例如，一个MySQL pod可能包含了一个不断检查数据库引擎状态的liveness探针。

以上健康检查可以使用命令、HTTP探针以及TCP探针进行配置。

具体的配置步骤，请参阅Kubernetes官方文档：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

3、利用Init容器来准备Pod

在几个场景中容器需要在处于准备状态之前初始化。可以将初始化操作移动到另一个容器中，以便在Pod处于准备状态之前进行一些基础工作。 Init容器可用于下载文件、创建目录、更改文件权限等。

一个init容器甚至可以确保pod以特定的顺序启动。例如，在启动WordPress pod之前，Init容器可以一直等待直到MySQL Pod可用。

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

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

基于资源对Pod的需求情况以及集群中资源的消耗情况，Kubernetes scheduler可以合理地将pod分配到相关地节点上。然而，这可能需要控制在节点上调度Pod的方式。Kubernetes为此提供了两种机制—— 节点亲和性/反亲和性以及pod亲和性/反亲和性。

节点亲和性增强了本身已经十分强大的nodeSelector规则，以覆盖其他场景。就像Kubernetes annotation使label/selector更具表现力和可扩展性的方式一样，节点亲和性通过附加规则使nodeSelector更具表现力。 节点亲和性可以确保pod会被调度到符合特定条件的节点上。 例如，一个有状态的数据库Pod会被强制调度到已连接SSD的节点上。类似地，节点反亲和性可以避免将Pod调度到可能会引起问题的节点上。

尽管节点亲和性确实可以在Pod和节点之间进行匹配，但是在某些情况下，你可能需要将pod放在同一位置以提高性能或合规性。此时，Pod亲和性规则就适时登场了。 Pod亲和性可以帮助我们放置需要共享同一节点的pod。 例如，Nginx web server pod必须调度到和Redis Pod相同的节点上，因为这可以保证web应用程序和缓存之间的低延迟。在其他场景中，你可能想要避免在同一个节点上运行两个pod，pod反亲和性规则可以满足这一需求。当部署HA工作负载时，你可能不想在同一节点上运行同一个Pod的两个实例。Pod反亲和性可以避免这一情况的发生。

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

5、利用自动伸缩

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

Kubernetes中有类似的自动弹性伸缩功能，譬如水平Pod自动伸缩（HPA）、垂直Pod自动伸缩（VPA）以及集群自动伸缩。

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

VPA消除了pod的CPU和内存配置的不确定性。 该自动缩放器能够为CPU和内存请求和限制推荐适当的值，或者能够自动更新这些值。Auto-update的标志将决定是否驱逐现有的pod或者继续使用旧的配置运行。查询VPA对象将显示最合适的CPU和内存请求区间。

虽然HPA和VPA可以缩放deployment和Pod，Cluster Autoscaler也能扩展和缩小worker节点池的规模。它是一个独立工具，可以根据当前的使用率来调整Kubernetes集群大小。当由于资源不足而无法在任何当前节点上调度Pod时，或当添加新节点会增加集群资源的整体可用性时，Cluster Autoscaler会增加集群的规模。在后台，Cluster Autosacler与底层laaS进行协商以添加或删除节点。如果将HPA与Cluster Autoscaler结合使用，那么它们可以提高性能和工作负载的可用性。

创作场景

5 大基本技巧！祝你在生产上顺利部署 K8S Pod