在过去的三年里，我经历了管理 Kubernetes 集群的有时波涛汹涌的水域。这段充满挑战和发现的旅程让我对这项尖端技术及其方方面面有了深刻的了解。在本文中，我希望与您分享我作为 Kubernetes 集群管理器学到的十个最有价值的经验教训。
这些课程涵盖一系列主题，从管理底层基础设施到优化部署流程，并包括确保集群可扩展性和安全性的最佳实践。无论您是 Kubernetes 世界的新手还是经验丰富的专家，这些见解都将为您提供关于如何有效管理 Kubernetes 集群的丰富视角。
让我们一起深入了解这些教导，这是三年经验、成功和克服挑战的成果。
第 1 课：在云中使用 Kubernetes
除非有极端的限制，否则没有必要自己管理 Kubernetes 的底层基础设施。您将花费时间来调试不会为您的业务增加价值的问题。成为 kube-api、kube-apiserver、kubelet、etcd、kube-proxy 等领域的专家固然很棒，但每天自己维护这些并不能增加价值。您无需成为这些概念的专家即可有效管理集群。将此低级任务委托给比您做得更好的云服务提供商（AWS、Azure、GCP、OVH 等）。
第 2 课：使用代码部署整个 Kubernetes 相关基础设施。
集群的任何部分都不应该在控制台上手动完成，甚至一个简单的标签也不应该。尤其要避免“我在控制台上很快修复了它，稍后我会更新代码”的心态。误区：你永远不会这么做。
第 3 课：避免过度使用您无法完全控制的Helm Chart。
是的，它们很棒，工作速度很快，而且您不必为编写 YAML 而绞尽脑汁，除非更新破坏了一切。如果您真的很懒或时间不够，至少要努力理解values.yaml 文件中的每个变量并避免使用默认值。在 HK-Tech，规则不是 Helm Chart；而是没有 Helm Chart。最坏的情况是，我们检索模板。
第 4 课：Kubernetes 不喜欢直接迁移。
因此，您需要亲自动手处理旧应用程序，将它们重新设计为与云兼容。不是由 Kube 来适应你的应用，而是由应用来适应K8S。如果您无法重新编码您的应用程序，也许可以继续使用旧的虚拟机。
第五课：网格化还是不网格化？
如果不需要，请不要安装服务网格。如何知道您是否需要它？问自己两个问题：集群中的应用程序可以相互通信吗？我的集群中的应用程序之间的交换是否需要受到保护？如果两者的答案都是肯定的，那么安装服务网格可能会很有用。我没有具体的建议；一般来说，它们都是相似的。
第六课：避免使用多种工具。
Kubernetes 提供了大量的辅助工具，可以带来巨大的奇迹，可以更好地管理集群：argocd、lens、k9s、keda、krew、kubectx、kubens、kail…避免将它们堆叠起来，kubectl 可以满足 90% 的需求。就我个人而言，我将自己限制在 kubectx、kubens、k9s 上，以便在管理集群方面获得真正的收益。
第 7 课：您必须始终定义分配给 pod 的资源限制（内存和 CPU）。
它将防止因某些 Pod 过于贪婪而导致编码或配置不当的应用程序吞噬所有集群资源并相继关闭应用程序的风险。这也是对 Helm Chart 保持警惕并始终检查漂亮包装背后的清单源代码的原因之一。
第 8 课：慎重选择stateless。
理想情况下，最好避免在 pod 中保留数据。如果由于某种原因无法以其他方式实现，那么最好安装在 NAS 上而不是磁盘上。否则，您会惊讶地发现部署中的某些 Pod 无权访问持久资源。是的，硬盘只能挂载在一个节点上，所以如果你的 Pod 分布在多个节点上，同一节点上的 Pod 会看到相同的数据，而其他节点上的 Pod 则看不到。使用像 EFS 这样的 NAS 类型安装，您将避免这个问题。
第 9 课：配置 HPA（水平 Pod 自动缩放器）。
如果您想停止像旧世界一样工作并受益于 Kubernetes 根据需求自动管理资源利用率的能力，您将需要在所有应用程序项目上配置 HPA。（Helm Chart的另一个限制，不幸的是它经常缺失）。
第十课：不要害怕改变。
平均而言，您应该计划每年对集群进行三个版本升级，大约每四个月更新一次。有些更新是透明的，但通常会发生具有影响的更改。为了更好地为这些更新做好准备，我建议您阅读、重新阅读并重新访问发行说明以及在您之前更新过的人的经验。我建议以及我们在 HK-TECH 实施的始终是最新版本以下的一个版本（除非有安全更改）。
