配置最佳实践

本文档重点介绍并整合了用户指南、入门文档和示例中介绍的配置最佳实践。

这是一个动态文档。如果你想到此列表中没有但可能对其他人有用的内容，请随时提交问题或提交 PR。

通用配置技巧

• 定义配置时，请指定最新的稳定 API 版本。

• 配置文件应在推送到集群之前存储在版本控制中。 如果需要，这允许您快速回滚配置更改。 它还有助于集群的重新创建和恢复。

• 使用 YAML 而不是 JSON 编写配置文件。 虽然这些格式在几乎所有场景中都可以互换使用，但 YAML 往往对用户更友好。

• 在合理的情况下，将相关对象分组到一个文件中。 一个文件通常比多个文件更容易管理。 请参阅 guestbook-all-in-one.yaml 文件作为此语法的示例。

• 另请注意，许多 kubectl 命令可以在目录上调用。 例如，您可以在配置文件目录上调用 kubectl apply。

• 不要不必要地指定默认值：简单、最小化的配置将减少错误的发生。

• 将对象描述放在注释中，以允许更好的自省。

“裸” Pod 与 ReplicaSet、Deployment 和 Job

• 如果可以避免，请不要使用裸 Pod（即未绑定到 ReplicaSet 或 Deployment 的 Pod）。 如果节点发生故障，则不会重新调度裸 Pod。

  Deployment，它既创建 ReplicaSet 以确保始终提供所需数量的 Pod，又指定替换 Pod 的策略（例如 RollingUpdate），几乎总是比直接创建 Pod 更可取，除非某些显式 restartPolicy: Never 场景。 Job 也可能适合。

服务

• 在其对应的后端工作负载（Deployment 或 ReplicaSet）之前，以及任何需要访问它的工作负载之前，创建一个 Service。 当 Kubernetes 启动容器时，它会提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为 foo 的服务，则所有容器都会在其初始环境中获得以下变量

  FOO_SERVICE_HOST=<the host the Service is running on>
  FOO_SERVICE_PORT=<the port the Service is running on>
  

  这确实暗示了排序要求 - Pod 想要访问的任何 Service 都必须在 Pod 本身之前创建，否则不会填充环境变量。 DNS 没有此限制。

• 一个可选（但强烈推荐）的 集群插件 是 DNS 服务器。 DNS 服务器会监视 Kubernetes API 中的新 Services，并为每个服务创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有 Pods 都应该能够自动对 Services 进行名称解析。

• 除非绝对必要，否则不要为 Pod 指定 hostPort。 当您将 Pod 绑定到 hostPort 时，它会限制可以调度 Pod 的位置数量，因为每个 <hostIP、hostPort、protocol> 组合必须是唯一的。 如果您未显式指定 hostIP 和 protocol，Kubernetes 将使用 0.0.0.0 作为默认 hostIP，并使用 TCP 作为默认 protocol。

  如果您只需要出于调试目的访问端口，则可以使用 apiserver 代理 或 kubectl port-forward。

  如果您明确需要在节点上公开 Pod 的端口，请考虑在求助于 hostPort 之前使用 NodePort Service。

• 避免使用 hostNetwork，原因与 hostPort 相同。

• 当您不需要 kube-proxy 负载平衡时，请使用 无头服务（其 ClusterIP 为 None）进行服务发现。

使用标签

• 定义和使用 标签，这些标签标识应用程序或 Deployment 的语义属性，例如 { app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }。 您可以使用这些标签来选择其他资源的相应 Pod； 例如，选择所有 tier: frontend Pod 的 Service，或 app.kubernetes.io/name: MyApp 的所有 phase: test 组件。 有关此方法的示例，请参见 guestbook 应用。

  通过从其选择器中省略特定于版本的标签，可以使 Service 跨越多个 Deployment。 当您需要更新正在运行的服务而无需停机时，请使用 Deployment。

  对象的期望状态由 Deployment 描述，如果将对该规范的更改应用，则 Deployment 控制器会以受控的速率将实际状态更改为期望状态。

• 对于常见用例，请使用 Kubernetes 通用标签。 这些标准化的标签以一种允许工具（包括 kubectl 和 仪表板）以可互操作的方式工作的方式丰富了元数据。

• 您可以操作标签进行调试。 由于 Kubernetes 控制器（例如 ReplicaSet）和 Service 使用选择器标签与 Pod 匹配，因此从 Pod 中删除相关标签将阻止控制器考虑它或阻止 Service 提供流量。 如果您删除了现有 Pod 的标签，则其控制器将创建一个新 Pod 来代替它。 这是一种在“隔离”环境中调试先前“活动”的 Pod 的有用方法。 要以交互方式删除或添加标签，请使用 kubectl label。

使用 kubectl

• 使用 kubectl apply -f <目录>。这会在 <目录> 中的所有 .yaml、.yml 和 .json 文件中查找 Kubernetes 配置，并将其传递给 apply。

• 对于 get 和 delete 操作，请使用标签选择器而不是特定的对象名称。请参阅关于标签选择器和有效使用标签的章节。

• 使用 kubectl create deployment 和 kubectl expose 来快速创建单容器 Deployment 和 Service。有关示例，请参阅使用 Service 在集群中访问应用程序。