在Kubernetes中部署生产就绪应用程序的5条技巧

“生产就绪”一词是什么意思？如果您希望部署在生产环境的工作负载的问题数量最少，这是您应该回答的第一个问题。

可以从多个角度讨论该问题的答案：安全性，可维护性，测试，可配置性，稳定性，可升级性，文档等。甚至有些人将可用于生产的解决方案定义为“在生产环境中的生产代码”。

我个人认为，投入生产环境的应用程序应该解决上述所有要素。

在生产环境中部署Kubernetes工作负载时，Kubernetes用户选择开源项目Helm作为事实上的标准选项。我很容易理解这是为什么：Helm带来了与专家建议的方法相匹配的一些好处。它扩展了部署的适应性和可定制性，简化了测试过程，支持进行历史记录和回滚管理等。

两年多来，我为该项目做出了贡献，比如：将各种基础架构应用程序充实到可用的目录(catalog)中、评审pull request，添加功能并参加了支持案例。根据我的经验，如果开发人员想要创建可在生产环境中部署的chart(译注：helm专有术语)，则应注意下面五个要素。

1）通过限制容器操作来确保安全性：运行non-root容器

要部署容器化的应用程序，必须将允许的操作数量限制为所需的最少数量。为确保这一点，请以不同于root用户的随机用户身份启动容器。这些被称为非根容器(non-root)。在某些基于Kubernetes的平台（例如Red Hat的OpenShift）中，这是强制性要求。(Helm)稳定存储库中大约一半的chart已经使用了非根容器，并且该数目正在增加。如果应用程序允许，您可以走得更远：使用完整的只读文件系统或“临时”容器（它们没有任何底层基础操作系统）。

2）限制对集群的访问：实施基于角色的访问控制策略（RBAC）

Kubernetes集群的核心是其API服务器 （kube-apiserver）。通过访问它，您可以获得有关集群当前状态以及部署在集群上的工作负载的详细信息。开发人员正在采用这种方法：当前，有许多支持Kubernetes的应用程序可以访问API服务器以进行诸如自我发现之类的操作。但是，拥有对Kubernetes API服务器完全访问权限的容器可能会损害集群。为了减轻这种风险，您必须确保Pod内的进程只能访问最小的必需数据集。

这就是基于角色的访问控制策略起作用的地方。例如，如果您在名称空间“test”中部署使用kube-apiserver进行自我发现的基础架构应用程序，你可能只需允许该程序对该特定名称空间中的pod对象进行“获取(get)”和“列表(list)”操作。过去，用户向诸如Helm客户端Tiller之类的应用程序被授予集群管理员特权（即，在集群中执行所有操作的特权）。这种做法将可能导致生产上的灾难。

不要忘记确保使用chart部署的应用程序都具有最小的RBAC特权集。

3）实施正确的测试流程，尤其是升级时

在StatefulSet中更新标签可能会导致破坏helm upgrade命令。为了应对这种情况，将管道中的升级测试包括在内是一项优先任务。很显然，你不能假设主要版本间的升级将无需人工干预。但是，确保在次要版本之间进行升级是可行的。

向chart添加功能（默认情况下处于禁用状态）是另一个常见问题。由于默认情况下禁用了这些功能，因此正常的helm安装测试很可能不会检测到任何问题。

这种情况的一个例子是ingress规则。这些参数默认情况下处于禁用状态，因此您可以在日常测试中轻松忘记它们。我可以预见，当Kubernetes 1.20中不推荐使用API Group extensions / v1beta（大多数Ingress API对象使用）时，稳定存储库中的几张chart将如何中断。通过增加具有多个value.yaml文件的chart的测试覆盖范围，可以避免此潜在问题。为此，可以使用诸如kubeval之类的解决方案。

4）不惜一切代价避免滚动标签

您可能已经熟悉了容器镜像，并且有可能至少执行了一次类似docker pull bitnami/redis:latest的命令。此“latest”是滚动标签（即，随着时间的推移将指向不同图像的标签）的示例。

设想以下情形：您想使用最新版本的Redis部署"bitnami/redis" chart。为此，请使用“latest”标签，以便您将在集群中运行Redis 5.0.5。部署chart时，一切都可以无缝进行。现在进一步想象一下，如果在将来的某一天，您需要使用新的Pod扩展Redis集群，这将下载“bitnami/redis:latest”镜像。如果现在最新的Redis是5.0.8，该怎么办？您将拥有运行不同版本的Redis Pod在同一Redis集群中运行。更糟糕的是，如果发布Redis 6.0.0会怎样？您一定会以损坏的Redis集群收尾。

如果要使部署可维护且受控制，请确保chart使用不可变的镜像（例如：“ bitnami/redis：5.0.5-debian-9-r10”）。使用这种方法，每次部署或扩展时，您都知道要使用的镜像。另外，您将保证已使用chart的特定版本对部署的镜像进行了测试，这在使用滚动标签时无法得到保证。

5）监视您的部署

该技巧很容易遵循：如果您希望工作负载可以投入生产，则需要对其进行监视。大多数可用于生产的chart都支持指标导出器，因此可以通过Prometheus和Wavefront之类的工具或BKPR之类的套件来观察您的应用程序状态。同样，重要的是要确保您的工作负载还与日志堆栈（例如ELK）集成，以提高容器化应用程序的可观察性。优点是无数的：早期故障预防，审计，趋势检测，性能分析或调试等。

生产中的Kubernetes是现实的

通过上面的提示，您将涵盖Kubernetes生产就绪的所有基础知识。但是，您还应该探索更多领域，例如稳定性，性能，网络，自动扩展等等。

本文翻译自：5 Tips to Deploy Production-Ready Applications in Kubernetes。

慕课网已开启11.11大促，史无前例4310元大额优惠 对想了解和学习Kubernetes的同学，可以看看我在慕课网的课程：前置免费课：《Kubernetes基础：开启云原生之门》(学时:2h) ； 实战课：《Kubernetes实战 高可用集群搭建,配置,运维与应用》(学时约8h)，有问题欢迎交流。

讲师主页：tonybai_cn
讲师博客: Tony Bai
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》