Kubernetes 生产环境最佳实践

众所周知，Kubernetes 很难! 以下是在生产中使用它应遵循的一些最佳实践。遵循这些步骤能够确保更高的安全性和生产效率。

毫无疑问，DevOps 已经走过了一段很长的路! 借助于 Kubernetes 编排平台使得公司比以往更快地发布软件。随着容器用于构建和发布软件的使用量不断增加，Kubernetes 已经成为事实上的容器编排工具标准，在软件企业中非常受欢迎。

Kubernetes 具有优秀的特性，比如：支持可扩展、零停机部署、服务发现、自动重启和回滚功能等。要大规模管理容器部署，Kubernetes 是必须的。它支持灵活地分配资源和工作负载。毫无疑问，生产环境中的 Kubernetes 是一个很好的解决方案，但需要花费一些时间来设置和熟悉这个工具。由于现在许多公司都希望在生产中使用 Kubernetes，因此有必要考虑一些最佳实践。在本文中，我们将讨论一些 Kubernetes 的最佳实践。

生产环境中的 Kubernetes

Kubernetes 是一个复杂并且学习曲线陡峭的编排工具，但它具有丰富的功能。生产操作应尽可能小心谨慎处理。如果您面临内部人才短缺的问题，您可以将其外包给 PaaS 供应商，为您提供所有最佳实践。但假设您在生产中独自管理 Kubernetes。在这种情况下，关注最佳实践是非常重要的，特别是关于可观察性、日志记录、集群监控和安全配置。

我们很多人都知道，在生产环境中运行容器不是一件容易的事情。它需要大量的工作和计算资源等等。市场上有许多编排平台，但 Kubernetes 已经获得了巨大的吸引力和大多数云提供商的支持。

总之——Kubernetes、集装箱化和微服务都是美好的基础设施，但同时带来了安全挑战。Kubernetes Pod 可以在所有基础设施类之间快速切换，从而导致 Pod 之间的内部流量增加，引发安全隐患。此外，Kubernetes 的攻击面通常更大。您必须考虑到 Kubernetes 的高度动态且全新的环境无法与旧版安全工具完美融合的问题。

Gartner 预测，到 2022 年，超过 75%的全球组织将在生产中运行集装箱应用程序，而目前这一比例还不到 30%。到 2025 年，超过 85%的全球组织将在生产中推动集装箱应用，较 2019 年的不到 35%有显著增长。本地云应用程序需要高度的基础设施自动化、DevOps 和专门的操作技能，这些在普通 IT 组织中很难找到这些技能。

所以必须使用 Kubernetes 的一些策略，在安全性、监控、网络、治理、存储、容器生命周期管理和平台选择方面应用最佳实践。下面让我们来看看 Kubernetes 的一些生产最佳实践。

在生产中运行 Kubernetes 并不容易; 有以下几个方面需要注意。

是否使用存活探针和就绪探针进行健康检查？

管理大型分布式系统可能会很复杂，特别是当出现问题时，我们无法及时得到通知。为了确保应用实例正常工作，设置 Kubernetes 健康检查至关重要。

通过创建自定义运行健康检查，可以有效避免分布式系统中僵尸服务运行，具体可以根据环境和需要对其进行调整。

Readiness-就绪探针

就绪探针的目的是让 Kubernetes 知道该应用是否已经准备好为流量服务。Kubernetes 将始终确保准备就绪探针通过之后开始分配服务，将流量发送到 Pod。

Liveness-存活探针

你怎么知道你的应用程序是活的还是死的?存活探针可以让你做到这一点。如果你的应用死了，Kubernetes 会移除旧的 Pod 并用新 Pod 替换它。

Resource Management- 资源管理

为单个容器指定资源请求和限制是一个很好的实践。

另一个好的实践是将 Kubernetes 环境划分为不同团队、部门、应用程序和客户机的独立名称空间。

Kubernetes 资源使用情况

Kubernetes 资源使用指的是容器/pod 在生产中所使用的资源数量。

因此，密切关注 pods 的资源使用情况是非常重要的。一个明显的原因是成本，因为越高的资源利用证明越少的资源浪费。

Resource utilization 资源利用率

Ops 团队通常希望优化和最大化 pods 消耗的资源百分比。资源使用情况是 Kubernetes 环境实际优化程度的指标之一。

您可以认为优化后的 Kubernetes 环境中运行的容器的平均 CPU 等资源利用率是最优的。

启用 RBAC

RBAC 代表基于角色的访问控制。它是一种用于限制系统/网络上的用户和应用程序的访问和准入的方法。

他们从 Kubernetes 1.8 版本引入了 RBAC。使用 rbac.authorization.k8s RBAC 用于创建授权策略。

在 Kubernetes 中，RBAC 用于授权，使用 RBAC，您将能够授予用户、帐户、添加/删除权限、设置规则等权限。因此，它基本上为 Kubernetes 集群添加了额外的安全层。RBAC 限制谁可以访问您的生产环境和集群。

集群置备和负载均衡

生产级 Kubernetes 基础设施通常需要考虑某些关键方面，例如高可用性、多主机、多 etcd Kubernetes 集群等。此类集群的配置通常涉及到 Terraform 或 Ansible 等工具。

一旦集群都设置好了，并且为运行应用程序创建了 pods，这些 pods 就配备了负载平衡器;这些负载均衡器将流量路由到服务。开源的 Kubernetes 项目并不是默认的负载平衡器;因此，它需要与 NGINX Ingress controller 与 HAProxy 或 ELB 等工具集成，或任何其他工具，扩大 Kubernetes 的 Ingress 插件，以提供负载均衡能力。

给 Kubernetes 对象添加标签

标签就像附加到对象上的键/值对，比如 pods。标签是用来标识对象的属性的，这些属性对用户来说是重要的和有意义的。在生产中使用 Kubernetes 时，不能忽视的一个重要问题是标签;标签允许批量查询和操作 Kubernetes 对象。标签的特殊之处在于，它们还可以用于识别 Kubernetes 对象并将其组织成组。这样做的最佳用例之一是根据 pod 所属的应用程序对它们进行分组。在这里，团队可以构建并拥有任意数量的标签约定。

配置网络策略

使用 Kubernetes 时，设置网络策略至关重要。

网络策略只不过是一个对象，它使你能够明确地声明和决定哪些流量是允许的，哪些是不允许的。这样，Kubernetes 将能够阻止所有其他不想要的和不符合规则的流量。在我们的集群中定义和限制网络流量是强烈推荐的基本且必要的安全措施之一。

Kubernetes 中的每个网络策略都定义了一个如上所述的授权连接列表。无论何时创建任何网络策略，它所引用的所有 pod 都有资格建立或接受列出的连接。简单地说，网络策略基本上就是授权和允许连接的白名单——一个连接，无论它是到还是从pod，只有在应用于 pod 的至少一个网络策略允许的情况下才被允许。

集群监控和日志记录

在使用 Kubernetes 时，监控部署是至关重要的。确保配置、性能和流量保持安全更是重要。如果不进行日志记录和监控，就不可能诊断出发生的问题。为了确保合规性，监视和日志记录变得非常重要。

在进行监视时，有必要在体系结构的每一层上设置日志记录功能。生成的日志将帮助我们启用安全工具、审计功能和分析性能。

从无状态应用程序开始

运行无状态应用要比运行有状态应用简单得多，但随着 Kubernetes 运营商的不断增长，这种想法正在改变。对于刚接触 Kubernetes 的团队来说，建议首先使用无状态应用程序。

建议使用无状态后端，这样开发团队就可以确保不存在长时间运行的连接，从而增加了扩展的难度。使用无状态，开发人员还可以更有效地、零停机部署应用程序。

人们普遍认为，无状态应用程序可以方便地根据业务需要进行迁移和扩展。

启动自动扩缩容

Kubernetes 有三种用于部署的自动伸缩功能:水平 pod 自动伸缩(HPA)、垂直 pod 自动伸缩(VPA)和集群自动伸缩。

水平 pod autoscaler 根据感知到的 CPU 利用率自动扩展 deployment、replicationcontroller, replicaset, statefulset 的数量。

Vertical pod autoscaling 为 CPU 和内存请求和限制推荐合适的值，它可以自动更新这些值。

Cluster Autoscaler 扩展和缩小工作节点池的大小。它根据当前的利用率调整 Kubernetes 集群的大小。

控制镜像拉取来源

控制在集群中运行所有容器的镜像源。如果您允许您的 Pod 从公共资源中拉取镜像，您就不知道其中真正运行的是什么。

如果从受信任的注册表中提取它们，则可以在注册表上应用策略以提取安全和经过认证的镜像。

持续学习

不断评估应用程序的状态和设置，以学习和改进。例如，回顾容器的历史内存使用情况可以得出这样的结论:我们可以分配更少的内存，在长期内节省成本。

保护重要服务

使用 Pod 优先级，您可以决定设置不同服务运行的重要性。例如，为了更好的稳定性，你需要确保 RabbitMQ pod 比你的应用 pod 更重要。或者你的入口控制器 pods 比数据处理 pods 更重要，以保持服务对用户可用。

零停机时间

通过在 HA 中运行所有服务，支持集群和服务的零停机升级。这也将保证您的客户获得更高的可用性。

使用 pod 反亲和性来确保在不同的节点上调度一个 pod 的多个副本，从而通过计划中的和计划外的集群节点停机来确保服务可用性。

使用 pod Disruptions 策略，不惜一切代价确保您有最低的 Pod 副本数量!

计划失败

硬件最终会失败，软件最终会运行。--（迈克尔·哈顿）

结论

众所周知，Kubernetes 实际上已经成为 DevOps 领域的编排平台标准。Kubernetes 从可用性、可伸缩性、安全性、弹性、资源管理和监控的角度来应对生产环境产生的风暴。由于许多公司都在生产中使用 Kubernetes，因此必须遵循上面提到的最佳实践，以顺利和可靠地扩展应用程序。