配置最佳实践
本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
这是一份不断改进的文件。 如果您认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
一般配置提示
- 定义配置时，请指定最新的稳定 API 版本。
- 在推送到集群之前，配置文件应存储在版本控制中。 这允许您在必要时快速回滚配置更改。 它还有助于集群重新创建和恢复。
- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
- 只要有意义，就将相关对象分组到一个文件中。 一个文件通常比几个文件更容易管理。 请参阅guestbook-all-in-one.yaml 文件作为此语法的示例。
- 另请注意，可以在目录上调用许多
kubectl命令。 例如，你可以在配置文件的目录中调用kubectl apply。
- 除非必要，否则不指定默认值：简单的最小配置会降低错误的可能性。
- 将对象描述放在注释中，以便更好地进行内省。
“Naked” Pods 与 ReplicaSet，Deployment 和 Jobs
- 如果可能，不要使用独立的 Pods（即，未绑定到 ReplicaSet 或 Deployment 的 Pod）。 如果节点发生故障，将不会重新调度独立的 Pods。
Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如
RollingUpdate）。
除了一些显式的 restartPolicy: Never
场景外，Deployment 通常比直接创建 Pod 要好得多。Job 也可能是合适的选择。
服务
-
在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 服务。 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为
foo的服务，则所有容器将在其初始环境中获得以下变量。FOO_SERVICE_HOST=<the host the Service is running on> FOO_SERVICE_PORT=<the port the Service is running on>
这确实意味着在顺序上的要求 - 必须在 Pod 本身被创建之前创建 Pod 想要访问的任何 Service，
否则将环境变量不会生效。DNS 没有此限制。
- 一个可选（尽管强烈推荐）的集群插件
是 DNS 服务器。DNS 服务器为新的
Services监视 Kubernetes API，并为每个创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有Pods应该能够自动对Services进行名称解析。
- 除非绝对必要，否则不要为 Pod 指定
hostPort。 将 Pod 绑定到hostPort时，它会限制 Pod 可以调度的位置数，因为每个<hostIP, hostPort, protocol>组合必须是唯一的。 如果您没有明确指定hostIP和protocol，Kubernetes 将使用0.0.0.0作为默认hostIP和TCP作为默认protocol。
如果您只需要访问端口以进行调试，则可以使用
apiserver proxy或
kubectl port-forward。
如果您明确需要在节点上公开 Pod 的端口，请在使用 hostPort 之前考虑使用
NodePort 服务。
- 避免使用
hostNetwork，原因与hostPort相同。
- 当您不需要
kube-proxy负载均衡时，使用 无头服务
(ClusterIP被设置为None)以便于服务发现。
使用标签
- 定义并使用标签来识别应用程序
或 Deployment 的 语义属性，例如
{ app: myapp, tier: frontend, phase: test, deployment: v3 }。 你可以使用这些标签为其他资源选择合适的 Pod； 例如，一个选择所有tier: frontendPod 的服务，或者app: myapp的所有phase: test组件。 有关此方法的示例，请参阅guestbook 。
通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 当你需要不停机的情况下更新正在运行的服务，可以使用Deployment。
Deployment 描述了对象的期望状态，并且如果对该规范的更改被成功应用， 则 Deployment 控制器以受控速率将实际状态改变为期望状态。
- 对于常见场景，应使用 Kubernetes 通用标签。
这些标准化的标签丰富了对象的元数据，使得包括
kubectl和 仪表板（Dashboard） 这些工具能够以可互操作的方式工作。
- 您可以操纵标签进行调试。
由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod，
从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。
这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。
要以交互方式删除或添加标签，请使用
kubectl label。
容器镜像
imagePullPolicy和镜像标签会影响 kubelet 何时尝试拉取指定的镜像。
imagePullPolicy: IfNotPresent：仅当镜像在本地不存在时才被拉取。imagePullPolicy: Always：每次启动 Pod 的时候都会拉取镜像。imagePullPolicy省略时，镜像标签为:latest或不存在，其值自动被设置为Always。注意，如果镜像标签的值发生改变，imagePullPolicy的值不会被更新为IfNotPresent。imagePullPolicy省略时，指定镜像标签并且不是:latest，其值自动被设置为IfNotPresent。注意，如果镜像标签的值之后被移除或者修改为latest，imagePullPolicy的值不会被更新为Always。imagePullPolicy: Never：假设镜像已经存在本地，不会尝试拉取镜像。
说明： 要确保容器始终使用相同版本的镜像，你可以指定其 摘要， 例如sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2。 摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。
说明： 在生产中部署容器时应避免使用:latest标记，因为这样更难跟踪正在运行的镜像版本，并且更难以正确回滚。
说明： 只要镜像仓库是可访问的，底层镜像驱动程序的缓存语义能够使即便imagePullPolicy: Always的配置也很高效。 例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要下载。
使用 kubectl
- 使用
kubectl apply -f <directory>。 它在<directory>中的所有.yaml、.yml和.json文件中查找 Kubernetes 配置，并将其传递给apply。
- 使用
kubectl run和kubectl expose来快速创建单容器部署和服务。 有关示例，请参阅使用服务访问集群中的应用程序。