管理 Kubernetes 集群这3年，我踩过的十个坑

作者 | Herve Khg

编译 | 如烟

出品 | 51CTO技术栈（微信号：blog51cto）

Kube.NETes 作为云计算领域的绝对主角，当仁不让地坐上了容器技术领域的“头把交椅”。它的精髓在于，你只要在 YAML 里描述清楚应用的样子，剩下的一切都可以交给它来完成。

但这一切的前提是 K8s 集群的高效管理。

说起我管理 Kubernetes 集群这三年，真可谓是一波三折、跌宕起伏。在这段充满挑战的经历中，我对这项技术有了更加深刻的了解，总结出十条我认为最有价值的经验教训，涵盖的内容包括管理底层基础设施、优化部署流程、确保集群的可扩展性和安全性的最佳实践。

无论你是刚入门 Kubernetes 的新手，还是经验丰富的专家，这些经验都可以为管理 Kubernetes 集群提供更丰富的视角。

1、自己管理 Kubernetes 底层基础设施？真的没必要

花费大量时间管理底层基础设施，或许可以让你成为kube-api、kube-apiserver、kubelet、etcd、kube-proxy 等领域的专家，但这对于业务而言可能是事倍功半。

想要更高效地管理 Kubernetes 集群，只要将这个任务交给合适的云服务厂商就行。

2、使用代码部署 Kubernetes 基础设施

不要在控制台上进行任何集群操作，特别是不要抱着“在操作台修复问题后，我马上就更新代码”的侥幸心理。

3、避免过度使用您无法完全控制的Helm Chart

虽然Helm Chart 提供了一种更加简单的方式来打包和分发 Kubernetes 应用，不需要为了编写 YAML 绞尽脑汁。但也要注意，还是要理解 values.yaml 文件中的每个变量并避免使用默认值。

4、Kubernetes 不适合直接迁移

不要让 Kubernetes 适应你的应用，而是要让应用适应 Kubernetes。所以你需要重新调整旧的应用程序，确保能够与云兼容。如果无法重新编码应用程序，也可以继续使用旧的虚拟机。

5、是否要安装服务网格？

非必要不安装服务网格。那如何判断是否需要安装服务网格呢？可以问自己两个问题：

一是集群中的应用程序可以相互通信吗？

二是集群中的应用程序之间的交换是否需要被保护？

如果这两个问题的答案都是肯定的，那么就需要安装服务网格。

6、不要使用多种工具

Kubernetes 提供了大量的辅助工具，可以帮助你更好地管理集群，包括 argocd, lens, k9s, keda, krew, kubectx, kubens, kAIl等。但不要依赖太多工具，合适的 kubectl 就能满足 90%的需求。

以我的经验来说，一般只选择 kubectx、kubens、k9s 这几种工具，这样管理集群的效率更高。

7、务必定义分配给 pod 的资源限制

这样做可以防止因某些 pod 过于贪婪致使编码或配置不当的应用程序吞噬所有集群资源，最终导致应用程序一个接一个关闭的风险。这也是对 Helm Chart 保持警惕并始终检查完美包装背后的清单源代码的原因之一。

8、避免在 pod 中保留数据

如果确实难以实现，那么最好安装在 NAS上而不是磁盘上。否则你会发现部署中的某些 pod 无权访问持久资源。

因为硬盘只能挂载在一个节点上，所以如果你的 pod 分布在多个节点上，同一节点上的 pod 会看到相同的数据，而其他节点上的 pod 则看不到数据。使用类似 EFS 这样的 NAS 类型安装，就能避免这个问题。

9、配置HPA 

如果你想停止像以前那样工作，并受益于Kubernetes根据需求自动管理资源利用率的能力，就需要在所有应用程序项目上配置HPA（水平 pod 自动缩放器）。

10、不要害怕改变

每四个月就应该升级一次集群版本，一年下来大概要升级三次。有些升级更新是透明的，但通常也会带来一些影响。

为了做好更加充分的更新准备，我觉得你需要重新回顾一下发行说明并多参考一下其他专家的经验。

11、写在最后

本文主要分析了 K8s 集群管理必须要考虑的十大要点，主要包括底层基础设施的部署和管理、Helm Chart 的使用、服务网格的安装、Kubernetes 工具的选择、 定义 pod 的资源限制等。但在实际工作中，往往可能需要同时管理多个集群，情况也更加复杂。所以有些要点在实际操作过程中是可以忽略的，但还有些“坑”是需要自己格外注意的。