在Kubernetes中，pod是基本部署单位。它可以包含一个或多个作为逻辑实体打包和部署的容器。在Kubernetes中运行的云原生应用程序可能包含多个一一映射到每个微服务的pod。pod也是Kubernetes的扩展单位。
下面是在Kubernetes中部署pod之前要遵循的五个最基本的最佳实践。
1） 选择最合适的Kubernetes控制器
虽然部署和运行一个容器镜像（作为一个通用pod）是很有诱惑力的，但是你应该根据工作负载特性选择正确的控制器类型。Kubernetes有一个称为controller的原语，它与工作负载的关键特性相一致。Deployment、StatefulSet和DaemonSet是Kubernetes中最常用的控制器。
部署无状态pod时，请总是使用部署控制器。这通过扩展、部署历史和回滚特性将类似PaaS的功能引入pod。当一个部署配置了最少两个副本计数时，Kubernetes确保至少两个pod始终在运行，这带来了容错性。即使在部署只有一个副本的pod时，也强烈建议你使用部署控制器，而不是普通的pod规范。
对于数据库集群等工作负载，StatefulSet控制器将创建一组具有可预测命名约定的高可用pod。需要高度可用的有状态工作负载（如Cassandra、Kafka、ZooKeeper和SQL Server）在Kubernetes中部署为StatefulSet。
当需要在集群的每个节点上运行pod时，应该使用DaemonSet控制器。由于Kubernetes在新配置的工作节点中自动调度DaemonSet，因此它成为为工作负载配置和准备节点的理想候选。例如，如果你想在部署工作负载之前在节点上安装现有的NFS或GLUSTER文件共享，那么将pod打包并部署为DaemonSet。
在部署pod之前，请确保选择了最合适的控制器类型。
2） 为pod配置健康检查
默认情况下，所有正在运行的pod都将restart策略设置为always，这意味着当容器遇到错误时，在节点内运行的kubelet将自动重启pod。
健康检查通过容器探针的概念扩展了kubelet的这种能力。有三个探针可以为每一个pod配置：readiness、liveness、startup。
你可能会遇到pod处于运行状态但ready列显示0/1的情况。这表示pod尚未准备好接受请求。readiness探针确保在启动pod之前满足先决条件。例如，为机器学习模型提供服务的pod需要在提供推理之前下载模型的最新版本。readiness探针会在将pod移动到就绪状态之前不断检查文件是否存在。类似地，CMS pod中的readiness探针将确保数据存储已安装并可访问。
liveness探针将定期检查容器的健康状况，并向kubelet报告。当此健康检查失败时，pod不会接收流量。服务将忽略此pod，直到liveness探针报告正常状态。例如，MySQL pod可能包含一个liveness探针，它持续检查数据库引擎的状态。
从1.16版开始，startup探针仍然处于alpha中，它允许容器在将健康检查移交给liveness探针之前等待更长的时间。这在将遗留应用程序移植到需要异常启动时间的Kubernetes时非常有用。
以上所有健康检查都可以配置为通过命令、HTTP探针和TCP探针配置。
3） 用Init Container准备pod
在某些情况下，容器在准备就绪之前需要初始化。初始化可以移动到另一个容器，以便在pod移动到就绪状态之前完成基础工作。init container可用于下载文件、创建目录、更改文件权限等。
init container甚至可以用来确保pod是按特定顺序启动的。例如，在启动WordPress pod之前，Init Container将一直等到MySQL pod可用。
一个pod可以包含多个init container，每个容器执行特定的初始化任务。
4） 应用Node/Pod Affinity和Anti-Affinity规则
Kubernetes调度器根据pod的资源需求和集群内的资源消耗，很好地将pod放置在相关节点上。但是，可能需要控制pod在节点上的调度方式。Kubernetes提供了两种机制——node affinity/anti-affinity和pod affinity/anti-affinity.
node affinity扩展了已经很强大的nodeSelector规则来覆盖其他场景。就像Kubernetes注释使label/selector更具表现力和可扩展性一样，node affinity通过附加规则使nodeSelector更具表现力。node affinity将确保在满足特定条件的节点上调度pod。例如，可以强制在连接了SSD的节点上调度有状态数据库pod。类似地，node anti-affinity将有助于避免在可能导致问题的节点上调度pod。
虽然node affinity在pod和节点之间进行匹配，但可能存在需要co-locate pod以获得性能或合规性的场景。pod affinity将帮助我们放置需要共享同一节点的pod。例如，Nginx web服务器pod必须调度在同时有Redis pod的节点上。这将确保web应用程序和缓存之间的低延迟。在其他情况下，你可能希望避免在同一节点上运行两个pod。部署HA工作负载时，你可能希望强制同一pod的两个实例不能在同一节点上运行。pod anti-affinity将强制执行防止这种可能性的规则。
分析工作负载，以评估是否需要使用node和pod affinity策略。
5） 利用Auto Scaler
像AWS、Microsoft Azure和Google Cloud Platform这样的超大规模云平台都有内置的自动伸缩引擎，可以根据平均资源消耗或外部指标来伸缩VM群。
Kubernetes在水平pod自动缩放器（HPA）、垂直pod自动缩放器（VPA）和集群自动缩放的部署中具有类似的自动缩放功能。
水平pod自动缩放器根据观察到的CPU利用率自动缩放复制控制器、部署、副本集或状态集中的pod数。HPA在Kubernetes中表示为一个对象，这意味着可以通过由kubectl CLI控制的YAML文件来声明它。与IaaS自动缩放引擎类似，HPA支持定义CPU阈值、pod的最小和最大实例、冷却周期甚至自定义指标。
垂直pod自动缩放消除了定义pod的CPU和内存配置所涉及的猜测。这个自动缩放器能够为CPU和内存请求和限制推荐适当的值，或者自动更新这些值。自动更新标志将决定是否将删除现有pod还是继续使用旧配置运行。查询VPA对象将通过上下限显示最佳CPU和内存请求。
当HPA和VPA伸缩扩展部署和pod时，Cluster Autoscaler将扩展和缩小工作节点池的大小。它是一个独立的工具，可以根据当前的利用率调整Kubernetes集群的大小。当存在由于资源不足而无法在任何当前节点上调度的pod时，或当添加新节点会增加集群资源的总体可用性时，自动缩放器将增加集群的大小。在幕后，Cluster Autoscaler与底层IaaS provider协商添加或删除节点。HPA与Cluster Autoscaler相结合，提供了工作负载的最大性能和最高可用性。
