作者 | Herve Khg
编译 | 如烟
出品 | 51CTO技术栈（微信号：blog51cto）
Kube.NETes 作为云计算领域的绝对主角，当仁不让地坐上了容器技术领域的“头把交椅”。它的精髓在于，你只要在 YAML 里描述清楚应用的样子，剩下的一切都可以交给它来完成。
但这一切的前提是 K8s 集群的高效管理。
说起我管理 Kubernetes 集群这三年，真可谓是一波三折、跌宕起伏。在这段充满挑战的经历中，我对这项技术有了更加深刻的了解，总结出十条我认为最有价值的经验教训，涵盖的内容包括管理底层基础设施、优化部署流程、确保集群的可扩展性和安全性的最佳实践。
无论你是刚入门 Kubernetes 的新手，还是经验丰富的专家，这些经验都可以为管理 Kubernetes 集群提供更丰富的视角。
花费大量时间管理底层基础设施，或许可以让你成为kube-api、kube-apiserver、kubelet、etcd、kube-proxy 等领域的专家，但这对于业务而言可能是事倍功半。
想要更高效地管理 Kubernetes 集群，只要将这个任务交给合适的云服务厂商就行。
不要在控制台上进行任何集群操作，特别是不要抱着“在操作台修复问题后，我马上就更新代码”的侥幸心理。
虽然Helm Chart 提供了一种更加简单的方式来打包和分发 Kubernetes 应用，不需要为了编写 YAML 绞尽脑汁。但也要注意，还是要理解 values.yaml 文件中的每个变量并避免使用默认值。
不要让 Kubernetes 适应你的应用，而是要让应用适应 Kubernetes。所以你需要重新调整旧的应用程序，确保能够与云兼容。如果无法重新编码应用程序，也可以继续使用旧的虚拟机。
非必要不安装服务网格。那如何判断是否需要安装服务网格呢？可以问自己两个问题：
一是集群中的应用程序可以相互通信吗？
二是集群中的应用程序之间的交换是否需要被保护？
如果这两个问题的答案都是肯定的，那么就需要安装服务网格。
Kubernetes 提供了大量的辅助工具，可以帮助你更好地管理集群，包括 argocd, lens, k9s, keda, krew, kubectx, kubens, kAIl等。但不要依赖太多工具，合适的 kubectl 就能满足 90%的需求。
以我的经验来说，一般只选择 kubectx、kubens、k9s 这几种工具，这样管理集群的效率更高。
这样做可以防止因某些 pod 过于贪婪致使编码或配置不当的应用程序吞噬所有集群资源，最终导致应用程序一个接一个关闭的风险。这也是对 Helm Chart 保持警惕并始终检查完美包装背后的清单源代码的原因之一。
如果确实难以实现，那么最好安装在 NAS上而不是磁盘上。否则你会发现部署中的某些 pod 无权访问持久资源。
因为硬盘只能挂载在一个节点上，所以如果你的 pod 分布在多个节点上，同一节点上的 pod 会看到相同的数据，而其他节点上的 pod 则看不到数据。使用类似 EFS 这样的 NAS 类型安装，就能避免这个问题。
如果你想停止像以前那样工作，并受益于Kubernetes根据需求自动管理资源利用率的能力，就需要在所有应用程序项目上配置HPA（水平 pod 自动缩放器）。
每四个月就应该升级一次集群版本，一年下来大概要升级三次。有些升级更新是透明的，但通常也会带来一些影响。
为了做好更加充分的更新准备，我觉得你需要重新回顾一下发行说明并多参考一下其他专家的经验。
本文主要分析了 K8s 集群管理必须要考虑的十大要点，主要包括底层基础设施的部署和管理、Helm Chart 的使用、服务网格的安装、Kubernetes 工具的选择、 定义 pod 的资源限制等。但在实际工作中，往往可能需要同时管理多个集群，情况也更加复杂。所以有些要点在实际操作过程中是可以忽略的，但还有些“坑”是需要自己格外注意的。
