管理 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、是否要安装服务网格? 
非必要不安装服务网格 。那如何判断是否需要安装服务网格呢?可以问自己两个问题:
 
【管理 Kubernetes 集群这3年,我踩过的十个坑】一是集群中的应用程序可以相互通信吗?
二是集群中的应用程序之间的交换是否需要被保护?
 
如果这两个问题的答案都是肯定的,那么就需要安装服务网格 。
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 的资源限制等 。但在实际工作中,往往可能需要同时管理多个集群,情况也更加复杂 。所以有些要点在实际操作过程中是可以忽略的,但还有些“坑”是需要自己格外注意的 。


推荐阅读