虽然 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