背景

　　在过去的三年里，我穿越了管理Kubernetes集群的时而波澜起伏的领域。这段充满挑战和发现的旅程让我深刻理解了这一尖端的技术，以及众多的其他方面。在这篇文章中，我想与您分享我作为Kubernetes集群管理员所学到的十个最有价值的教训。

　　这些教训涵盖了各种主题，从管理底层基础设施到优化部署流程，包括确保集群可扩展性和安全性的优秀实践。无论您是初次接触Kubernetes的新手，还是经验丰富的专家，这些建议都将为您提供如何有效管理Kubernetes集群的丰富视角。

　　让我们一起深入探讨这些教训，这是三年经验、成功和挑战的结晶。

　　教训1：使用云里的Kubernetes

　　除非有极端的约束，否则自己不要去管理Kubernetes底层基础设施。您会花费时间调试那些对您的业务毫无价值的问题。成为kube-api、kube-apiserver、kubelet、etcd、kube-proxy等方面的专家是很棒的，但每天都要自己维护这些并不会创造任何业务价值。您无需成为这些概念的专家就能有效地管理集群。将这个低级任务委托给云服务提供商（AWS、Azure、GCP、OVH等），他们比您做得更好。在HK-TECH，我们选择了AWS和EKS集群（注意ECS不是Kubernetes！）。

　　教训2：使用代码部署所有与Kubernetes相关的基础设施

　　集群的任何部分都不应该在控制台上手动完成，甚至连一个简单的标签都不要加。特别是要避免“我先在控制台上快速修复了一下，稍后我就会更新代码”的思维方式。迷思：其实您永远不会这样做。

　　教训3：避免过度使用您无法完全控制的Helm Charts

　　是的，它们很棒，工作迅速，您不必为编写您自己的YAML而烦恼，除非有一天更新会导致一切都崩溃。如果您真的很懒或时间很紧，至少努力理解values.yaml文件中的每个变量，并避免使用默认值。在HK-Tech，规则是不使用Helm Chart；在最坏的情况下，我们会仅获取模板。

　　教训4：Kubernetes不喜欢“lift and shift”

　　因此，为了使用到 k8s，你需要从旧应用程序的云迁移适配开始着手。不是让K8s来适应您的应用程序，而是由应用程序适配 k8s。如果您没有重新编写应用程序的能力，也许最好还是坚持使用旧的虚拟机运行的模式。

　　教训5：Mesh还是不Mesh？

　　如果不需要，就不要安装服务网格。那么你怎么才知道是否需要它？问自己两个问题：我的集群中的应用程序是否相互通信？我的集群中的应用程序之间的交换是否需要安全策略？如果两者的答案都是肯定的，那么安装服务网格可能是有用的。我没有具体的建议；通常各种 Mash 技术之间都很相似。

　　教训 6：避免使用过多的工具

　　Kubernetes提供了大量的辅助工具，承诺为更好地管理您的集群提供山寨和奇迹：argocd、lens、k9s、keda、krew、kubectx、kubens、kail等等。避免将它们像集邮一般的收集起来，老实说：用kubectl就能满足90%的需求。就个人而言，我仅限于使用到了kubectx、kubens和k9s，它们在集群管理上是有收益的。

　　教训 7 ：必须为Pod定义资源限制（内存和CPU）

　　这将防止糟糕编码或错误配置的应用程序吞噬掉您集群的所有资源，并由于一些贪婪的Pod而导致其他应用程序一个接一个地崩溃。这也是对Helm Chat保持警惕，并始终详细检查封装背后的清单源代码的原因之一。

　　教训 8：考虑无状态

　　理想情况下，最好避免在Pod中存储数据。如果由于某种原因无法避免，则最好使用NAS而不是磁盘直接挂载。否则，您可能会惊讶地发现部署中的一些Pod无法访问持久资源。是的，硬盘只能在一个节点上挂载，因此如果您的Pod分布在多个节点上，同一节点上的Pod将看到相同的数据，但其他节点上的Pod将看不到。使用像EFS这样的NAS类型挂载，您就将能避免这个问题。

　　教训 9：配置HPA（水平Pod自动缩放）

　　如果您既想停留在旧的工作方式中，又想从Kubernetes的强大之处中受益，那就需要根据需求自动的管理资源利用率，需要在所有应用程序项目上配置HPA。（Helm Chat的另一个限制，很不幸通常非常缺）。

　　教训 10：不要害怕变革

　　平均而言，您应该计划每年对集群进行三次版本升级，大约每四个月进行一次更新。某些更新是透明的，但通常会有带来影响的变更。为了更好地准备这些更新，我建议阅读、再阅读和重新阅读版本发布说明，以及那些在您之前进行过版本更新的人的经验。我建议，而且我们在HK-TECH已经实施的是：始终保持在最新版本的上一个版本（除非有安全补丁）。

　　祝您度过愉快的Kubernetes之旅！