配置最佳实践
本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
这是一份活文件。 如果您认为某些内容不在此列表中但可能对其他人有用,请不要犹豫,提交问题或提交 PR。
一般配置提示
- 定义配置时,请指定最新的稳定 API 版本。
- 在推送到集群之前,配置文件应存储在版本控制中。 这允许您在必要时快速回滚配置更改。 它还有助于集群重新创建和恢复。
- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用,但 YAML 往往更加用户友好。
- 只要有意义,就将相关对象分组到一个文件中。 一个文件通常比几个文件更容易管理。 请参阅guestbook-all-in-one.yaml 文件作为此语法的示例。
- 另请注意,可以在目录上调用许多
kubectl
命令。 例如,你可以在配置文件的目录中调用kubectl apply
。
- 不要不必要地指定默认值:简单的最小配置会降低错误的可能性。
- 将对象描述放在注释中,以便更好地进行内省。
“Naked”Pods 与 ReplicaSet,Deployment 和 Jobs
- 如果您能避免,不要使用 naked Pods(即,Pod 未绑定到ReplicaSet 或Deployment)。 如果节点发生故障,将不会重新安排 Naked Pods。
部署,它创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用,并指定替换 Pod 的策略(例如 RollingUpdate),除了一些显式的restartPolicy: Never
场景之外,几乎总是优先考虑直接创建 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没有此限制。
- 一个可选(尽管强烈推荐)cluster add-on是 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
负载平衡时,使用 无头服务 (具有None
的ClusterIP
)以便于服务发现。
使用标签
- 定义并使用标签来识别应用程序或部署的semantic attributes,例如
{ app: myapp, tier: frontend, phase: test, deployment: v3 }
。 您可以使用这些标签为其他资源选择合适的 Pod;例如,一个选择所有tier: frontend
Pod 的服务,或者app: myapp
的所有phase: test
组件。 有关此方法的示例,请参阅留言板 。
通过从选择器中省略特定发行版的标签,可以使服务跨越多个部署。 部署可以在不停机的情况下轻松更新正在运行的服务。
部署描述了对象的期望状态,并且如果对该规范的更改是_applied_,则部署控制器以受控速率将实际状态改变为期望状态。
- 您可以操纵标签进行调试。
- 由于 Kubernetes 控制器(例如 ReplicaSet)和服务使用选择器标签与 Pod 匹配,因此从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
如果删除现有 Pod 的标签,其控制器将创建一个新的 Pod 来取代它。
这是在”隔离”环境中调试先前”实时”Pod 的有用方法。
要以交互方式删除或添加标签,请使用
kubectl label
。
容器镜像
当 kubelet尝试拉取指定的镜像时,imagePullPolicy和镜像的标签会生效。
imagePullPolicy: IfNotPresent
:仅当镜像在本地不存在时镜像才被拉取。
imagePullPolicy: Always
:每次启动 pod 的时候都会拉取镜像。
- 省略
imagePullPolicy
,镜像标签为:latest
或被省略,Always
被应用。
imagePullPolicy
被省略,并且镜像的标签被指定且不是:latest
,IfNotPresent
被应用。
imagePullPolicy: Never
:镜像被假设存在于本地。 没有尝试拉取镜像。
注意: 要确保容器始终使用相同版本的镜像,你可以指定其 摘要, 例如sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
。 摘要唯一地标识出镜像的指定版本,因此除非您更改摘要值,否则 Kubernetes 永远不会更新它。
注意: 在生产中部署容器时应避免使用:latest
标记,因为更难跟踪正在运行的镜像版本,并且更难以正确回滚。
注意: 底层镜像提供程序的缓存语义甚至使imagePullPolicy: Always
变得高效。 例如,对于 Docker,如果镜像已经存在,则拉取尝试很快,因为镜像层都被缓存并且不需要镜像下载。
使用 kubectl
- 使用
kubectl apply -f <directory>
。 它在<directory>
中的所有.yaml
,.yml
和.json
文件中查找 Kubernetes 配置,并将其传递给apply
。
- 使用标签选择器进行
get
和delete
操作,而不是特定的对象名称。 - 请参阅标签选择器和[有效使用标签]部分(/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)。
- 使用
kubectl run
和kubectl expose
来快速创建单容器部署和服务。 有关示例,请参阅使用服务访问集群中的应用程序。
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.