共计 4453 个字符，预计需要花费 12 分钟才能阅读完成。
本文翻译自 Jack Roper 的文章 Kubernetes Best Practice。
译者：文章中作者从利用程序开发、治理和集群配置三个方面给出了一些 Kubernetes 的最佳实际，同时翻译过程中也退出了我过往的一些应用教训。有误的中央，也欢送大家斧正。
在这篇文章中，我将介绍一些应用 Kubernetes (K8s) 时的最佳实际。
作为最风行的容器编排零碎，K8s 是古代云工程师把握的事实标准。家喻户晓，不论应用还是保护 K8s 简单的零碎，因而很好地把握它应该做什么和不应该做什么，并晓得什么是可能的，将是一个好的开局。
这些倡议蕴含 3 大类中的常见问题，即利用程序开发、治理和集群配置。
最佳实际目录
- 应用命名空间
- 应用就绪和存活探针（译者注：还有启动探针）
- 应用主动缩放
- 应用资源申请和束缚
- 应用 Deployment、DaemonSet、ReplicaSet 或者 StatefulSet 跨节点部署 Pod
- 应用多节点
- 应用基于角色的访问控制（RBAC）
- 在内部托管 Kubernetes 集群（应用云服务）
- 降级 Kubernetes 版本
- 监控集群资源和审计策略日志
- 应用版本控制系统
- 应用基于 Git 的工作流程（GitOps）
- 放大容器的大小
- 用标签整顿对象（译者注：或了解为资源）
- 应用网络策略
- 应用防火墙
应用命名空间
K8s 中的命名空间对于组织对象、在集群中创立逻辑分区以及平安方面的思考至关重要。默认状况下，K8s 集群中有 3 个命名空间，default、kube-public 和 kube-system。
RBAC 可用于管制对特定命名空间的拜访，以限度组的拜访以管制可能产生的任何谬误的爆炸半径，例如，一组开发人员可能只能拜访名为 dev 的命名空间，并且无法访问 production 命名空间。将不同团队限度在不同命名空间的能力对于防止反复工作或资源抵触可能很有价值。
还能够针对命名空间配置 LimitRange 对象，以定义部署在命名空间中的容器的规范大小。ResourceQuotas 还可用于限度命名空间内所有容器的总资源耗费。能够对命名空间应用网络策略来限度 pod 之间的流量。
应用就绪和存活探针
Readiness（就绪）和 Liveness（存活）探针实质上都是健康检查的类型。这些是在 K8s 中应用的另一个十分重要的概念。
就绪探针确保仅当 pod 筹备好为申请提供服务时，才会将对 pod 的申请定向到它。如果它还没有筹备好，那么申请将被定向到其余中央。为每个容器定义就绪探针很重要，因为在 K8s 中没有为这些设置默认值。例如，如果一个 pod 须要 20 秒能力启动并且短少就绪探测，那么在启动期间定向到该 pod 的任何流量都会导致失败。就绪探针应该是独立的，并且不思考对其余服务的任何依赖，例如后端数据库或缓存服务。
存活探针试应用程序是否正在运行以将其标记为衰弱。例如，能够测试 Web 应用程序的特定门路以确保其响应。如果不是，该 pod 将不会被标记为衰弱，并且探测失败将导致 kubelet 启动一个新的 pod，而后将再次对其进行测试。这种类型的探测用作复原机制，以防过程无响应。
译者：在 Kubernetes 1.18 引入了 StartUp（启动）探针。当容器启动工夫较长（要花较长的工夫实现初始化工作），此时应该应用启动探针。如果启动探针探测不胜利，其余探针则不会失效。
译者：还有一点尽量为 Pod 内的所有容器都定义探针。
应用主动缩放
在适当的状况下，能够应用主动缩放来动静调整 pod 的数量（Pod 程度主动缩放器，HPA）、pod 耗费的资源量（Pod 垂直主动缩放器, VPA）或集群中的节点数量（集群主动缩放器，CA），具体取决于 对资源的需要。
Pod 程度主动扩缩器还能够依据 CPU 需要扩大复制控制器、正本集或有状态集。
应用缩放也带来了一些挑战，例如不在容器的本地文件系统中存储持久数据，因为这会阻止程度主动缩放。相同，能够应用 PersistentVolume。
当集群上存在高度可变的工作负载并且可能依据需要在不同工夫须要不同数量的资源时，集群主动缩放器十分有用。主动删除未应用的节点也是省钱的好办法！
译者：更多主动缩放的内容，能够浏览我之前翻译的 Kubernetes 的主动伸缩你用对了吗？；HPA 除了能够基于 CPU 指标伸缩，还能够基于内存，或者自定义指标，能够浏览 Kubernetes HPA 基于 Prometheus 自定义指标的可控弹性伸缩。
应用资源申请和束缚
应设置资源申请和束缚（可在容器中应用的最小和最大资源量）以防止容器在未调配所需资源的状况下启动，或集群用尽可用资源。
在没有限度的状况下，Pod 能够应用比所需更多的资源，从而导致可用资源总量缩小，这可能会导致集群上的其余应用程序呈现问题。节点可能会解体，并且调度程序可能无奈正确调度新的 pod。
如果没有申请，无奈为应用程序调配足够的资源，它可能会在尝试启动或执行异样时失败。
资源申请和限度以毫核和兆字节为单位定义可用的 CPU 和内存。请留神，如果过程超出内存限度，则该过程将终止，因而在所有状况下都可能不适宜设置此值。如果容器超过 CPU 限度，则过程会受到限制。
应用 Deployment、DaemonSet、ReplicaSet 或者 StatefulSet 跨节点部署 Pod
永远不应该间接应用 Pod 运行。相同，为了进步容错性，Pod 应该始终作为 Deployment、DaemonSet、ReplicaSet 或 StatefulSet 的一部分。而后能够在部署中应用反亲和性规定跨节点部署 pod，以防止所有 pod 调度到同一个节点上运行，如果该节点产生故障可能会导致服务进行。
应用多节点
如果想晋升容错性，在单个节点上运行 K8s 并不是一个好主见。集群中应该应用多个节点，以便能够在它们之间扩散工作负载。
应用基于角色的访问控制（RBAC）
在 K8s 集群中应用 RBAC 对于正确爱护零碎至关重要。能够为用户、组和 service account 调配权限，以在特定命名空间（角色）或整个集群（ClusterRole）上执行容许的操作。每个角色能够有多个权限。要将定义的角色绑定到用户、组或 service account，应用 RoleBinding 或 ClusterRoleBinding 对象。
RBAC 角色授予应设置为应用最小权限准则，即仅授予所需的权限。例如，管理员组可能有权拜访所有资源，而运维人员组可能可能部署，但不能读取 secret。
在内部托管 Kubernetes 集群（应用云服务）
在本人的硬件上托管 K8s 集群可能是一项简单的工作。云服务将 K8s 集群作为平台即服务 (PaaS) 提供，例如 Azure 上的 AKS（Azure Kubernetes 服务）或 Amazon Web Services 上的 EKS（亚马逊弹性 Kubernetes 服务）。利用这一点意味着底层基础设施将由云服务商治理，并且能够更轻松地实现无关扩大集群的工作，例如增加和删除节点，而让工程师治理 K8s 集群上运行的内容自身。
降级 Kubernetes 版本
除了引入新性能外，新的 K8s 版本还包含破绽和平安修复，这使得在集群上运行最新版本的 K8s 十分重要。对旧版本的反对可能不如新版本好。
然而，迁徙到新版本时应审慎看待，因为某些性能可能会被废除，也可能会增加新性能。此外，在降级之前，应查看集群上运行的应用程序是否与较新的指标版本兼容。
监控集群资源和审计策略日志
监控 K8s 管制立体中的组件对于管制资源耗费十分重要。管制立体是 K8s 的外围，这些组件放弃零碎运行，因而对于正确 K8s 操作至关重要。Kubernetes API、kubelet、etcd、controller-manager、kube-proxy 和 kube-dns 组成了管制立体。
管制立体组件能够以最常见的 K8s 监控工具 Prometheus 兼容的格局输入指标。
应该应用主动监控工具而不是手动治理告警。
能够在启动 kube-apiserver 时关上 K8s 中的审计日志记录，以便应用抉择的工具进行更深刻的考察。audit.log 将具体记录向 K8s API 收回的所有申请，并应定期检查集群上可能存在的任何问题。Kubernetes 集群默认策略在 audit-policy.yaml 文件中定义，能够依据须要进行批改。
Azure Monitor 等日志聚合工具可用于将日志从 AKS 发送到日志剖析工作区，以便未来应用 Kusto 查问进行审判。在 AWS Cloudwatch 上能够应用。第三方工具还提供更深刻的监控性能，例如 Dynatrace 和 Datadog。
最初，应该为日志设置一个保留期，通常为 30-45 天左右。
应用版本控制系统
K8s 配置文件应该在版本控制系统 (VCS) 中进行治理。这带来了很多益处，包含进步安全性、启用更改的审计跟踪，并将进步集群的稳定性。应为所做的任何更改设置审批，以便团队能够在将更改提交到主分支之前对其进行评审。
应用基于 Git 的工作流程（GitOps）
K8s 的胜利部署须要思考团队应用的工作流程。应用基于 git 的工作流能够通过应用 CI/CD（继续集成 / 继续交付）管道实现自动化，这将进步应用程序部署效率和速度。CI/CD 还将提供部署的审计跟踪。Git 应该是所有自动化的繁多事实起源，并将实现对 K8s 集群的对立治理。还能够思考应用专用的基础架构交付平台，例如 Spacelift，它最近引入了 Kubernetes 反对。
放大容器的大小
较小的映像大小将有助于放慢构建和部署速度，并缩小容器在 K8s 集群上耗费的资源量。应尽可能删除不必要的软件包，并应优先应用诸如 Alpine 之类的小型操作系统散发映像。较小的图像能够比拟大的图像更快地拉取，并且耗费更少的存储空间。
遵循这种办法还将提供平安劣势，因为歹意行为者的潜在攻打媒介将会缩小。
用标签整顿对象
K8s 标签是附加到对象用来组织集群资源的键值对。标签应该是有意义的元数据，提供一种机制来跟踪 K8s 零碎中不同组件的交互方式。
K8s 官网文档中举荐的 Pod 标签包含名称、实例、版本、组件、局部和管理者。
标签也能够以相似于在云环境中对资源应用标签的形式应用，以跟踪与业务相干的事物，例如对象所有权和对象应属于的环境。
此外，还倡议应用标签来具体阐明平安要求，包含机密性和合规性。
应用网络策略
应该应用网络策略来限度 K8s 集群中对象之间的流量。默认状况下，所有容器都能够在网络中互相通信，如果歹意行为者取得对容器的拜访权限，从而容许他们遍历集群中的对象，这会带来平安危险。网络策略能够在 IP 和端口级别管制流量，相似于云平台中的平安组的概念，以限度对资源的拜访。通常，默认状况下应回绝所有流量，而后应制订容许规定以容许所需流量。
应用防火墙
除了应用网络策略来限度 K8s 集群上的外部流量外，还应该在 K8s 集群后面搁置防火墙，以限度来自外部环境对 API server 的申请。IP 地址应列入白名单并限度凋谢端口。
总结
在设计、运行和保护 Kubernetes 集群时遵循本文中列出的最佳实际将使你在古代应用程序之旅中走上成功之路！
文章对立公布在公众号
云原生指北
