三年血泪史:工程师亲述Kubernetes实在太难

虽然 Kubernetes很火,但这家公司却用三年时间亲证:部署Kubernetes太难了,且很可能不建议其他人尝试。

事件经过

Atlassian是一家位于澳大利亚悉尼的企业,这家企业最初没有销售团队,不靠融资就做到了市值百亿美元,两位创始者本来也是开发者出身,这家企业的技术实力起初就不弱,但却在尝试了Kubernetes三年后公开表示:“过去三年,部署Kubernetes的过程非常艰难,并且不推荐大家尝试”

众所周知,Kubernetes是谷歌开源的容器编排引擎,支持自动化部署、大规模可伸缩、应用容器化管理,很多细节不需要运维人员进行复杂的手工配置和处理,这是现在非常流行的容器管理和编排工具,几乎好评如潮。这样一款让部署容器化应用更加简单高效的工具,为什么会让这家企业给出如此评价呢?

这一切要从Atlassian的Kubernetes团队首席工程师Nick Young近日接受媒体采访说起。

不久前,Nick Young曾在采访中表示,虽然当初选择Kubernetes的战略是正确的(至少到现在也没有发现其他可能的选择),解决了现阶段遇到的许多问题,但部署过程异常艰辛。

三年前,Kubernetes还是一种非常新的技术,Atlassian希望在PaaS平台做一些工作,重点在于让开发人员不必关心底层应用部署细节,只需想好要什么即可,比如要一个Docker镜像和PostgreSQL,PaaS团队将所有内容通过翻译转换为Kubernetes事务,编写内容并生成PostgreSQL,确保Postgres字符串和详细信息都连接到Kubernetes的pod,最终达到使用体验尽可能接近笔记本电脑上运行内容的体验。

准备阶段

在决定使用Kubernetes之后,这家公司就开始进入准备阶段,包括基础知识储备和团队建设等。

子集管理

团队建设工作并没有耗费太多精力,由于整个团队之前具备容器化经验,因此在基础知识学习方面相对轻松。在设计Kubernetes时,整个团队首先将关注点放在基础设施之上,考虑到未来业务增长的可能,整个团队建议如果希望管理一个完整堆栈,那么子集管理是非常重要的,这可以确保在某些需求出现时,只针对局部进行修改即可。

隔离

如果希望各层之间的修改和运行互不干扰,就需要保证层之间具有非常明确的边界,也就是通常所说的隔离性,这也被列入整个团队的准备工作之中。

过程受阻

在实际搭建中,Atlassian遇到了各种问题。目前,该公司运行了大约20个Kubernetes集群,最大集群约有14,000个vCPU和50TB左右RAM,运行了一大堆内部CI工具 。

问题1:etcd限制

etcd是Kubernetes提供的默认存储系统,保存所有集群数据,使用时需要为etcd数据提供备份计划。在这个过程中,Atlassian首先遇到了etcd大小限制问题,etcd存储了每个Kubernetes集群配置和其他数据关键组件。如果etcd数据库大小达到2.1GB,那么集群将转为只读模式。基本上,8万命名空间100%将占用2.1GB内存。

事实上,当命名空间达到5万时,etcd就开始放慢速度。最终,整个团队的解决方法是将流量转移到另一个集群,好在转移过程相对比较顺利。

问题2:安全

Kubernetes就像多年前的数据库,如果没有几年最佳实践经验,恐怕难以部署到位。Nick Young表示,解决安全问题非常重要且非常难,虽然Kubernetes有很多功能可供选择,但默认设置不是很安全。

事实上,Kubernetes系统提供三种认证方式:CA认证、Token认证和Base认证。双向认证配置是最为严格和安全的集群安全配置方式,但这种方式在保证系统不受攻击的情况下会带来额外的性能损耗,因此一般都建议用非安全方式访问API Server,这种方式效率更高。所以,企业通常需要在安全和性能之间找到一个很好的平衡点。

建议

不要完全DIY

回顾整个搭建过程,这家公司发现有很多工具可以代替曾经那些痛苦的过程。如今,主流云供应商提供非常棒的管理和运维工具。在确保安全的前提下,企业可以考虑这些现成工具,这可以大大简化整个搭建过程。

如果技术实力尚可,也有很多开源工具可以选择,完全的DIY设计需要投入大量精力和资金,因此不建议完全自主搭建。

查验失败

除此之外,在Kubernetes的部署中,我们经常可以碰到容器镜像没有更新、集群资源不足、校验错误、持久化卷挂载失败等问题,开发人员可以使用一些简单命令进行快速定位,比如,kubectl describe deployment/;kubectl describe replicaset/;kubectl get pods;kubectl describe pod/;kubectl logs --previous等命令可以被用来定位常见的大部分失败问题。

如果技术能力允许,也可以自己编写一些bash脚本,自动化查验失败原因,显示一些问题相关的Kubernetes信息,帮助开发者迅速定位问题原因。

总结

虽然Kubernetes部署很难,但只要开始就很难放弃,这家公司最终决定继续使用Kubernetes,并持续优化建设。

参考链接:https://www.itnews.com.au/news/atlassian-admits-it-did-kubernetes-the-hard-way-517984

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章