作者 | Herve Khg
编译 | 如烟
出品 | 技术栈(微信号:blog51cto)
Kubernetes 作为云计算领域的绝对主角,当仁不让地坐上了容器技术领域的“头把交椅”。它的精髓在于,你只要在 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 的资源限制等。但在实际工作中,往往可能需要同时管理多个集群,情况也更加复杂。所以有些要点在实际操作过程中是可以忽略的,但还有些“坑”是需要自己格外注意的。
网站名称:管理Kubernetes集群这3年,我踩过的十个坑
本文URL:http://www.shufengxianlan.com/qtweb/news42/368642.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联