三年血泪史：工程师亲述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