Kubernetes是不是意味着DIY时代的结束？

在云技术领域，在开源领域工作通常意味着你有更多更好的选择。如果你的代码是基于开源构建的，那么你可以选择更多平台和云提供商。如果你是开发人员，开源可能意味着你有更多的项目可供选择，甚至有更多的雇主可供选择。

 

 

 

但选择太多并不见得全是好事，一个例子就是Kubernetes。

起源于谷歌的Kubernetes现在超过一半的提交来自谷歌之外。这使得Kubernetes及其周边生态系统的选择激增，其中包括任何云原生或云采用团队需要学习的基本技术集。

从表面上看，Kubernetes的选择越来越多样化。现在几乎可以在任何云上运行相同的代码，而企业和开发人员都有很多选择。

不幸的是，选择太多了。要学的东西太多了，变化太快了，这种高学习曲线会使实施变得复杂并对企业文化产生负面影响。

从宏观上看，你必须决定是投资内部知识库还是审核外部云服务。第一种选择是难以置信的劳动密集型并且难以扩展，而第二种选择伴随着供应商锁定的担忧。

从微观上看，你必须就网络、存储和集群配置做出决策。这些决策是动态的并且通常是相级联的，你应该如何设置负载均衡器、入口控制器和API网关？你是使用Flannel还是Weave实现集群网络，是否添加Calico或Cilium用于策略管理？

存储选择（存储服务或在集群内部配置自己的存储服务）和多租户管理（每个团队一个集群或只有一个集群）可以带来截然不同的后果。当你开始添加pod自动缩放、节点自动缩放和服务网格等功能时，不要在意复杂性。

DIY K8s的问题

如果你的组织正在着手将部分运维迁移到云端，或者开始构建云原生应用程序，那么你得依靠第一个团队——这个团队不仅会证明迁移到云端可行，而且还是一个很好的主意。这支团队需要负责了解云原生技术和构成Kubernetes世界的300多个项目，实在有点疯狂。

然后，这个团队需要熟练掌握Kubernetes生命周期管理的各个方面：搭建集群，维护，网络，存储和跟上新版本的发布。Kubernetes差不多三个月发布一个新版本。他们还将担负着安全的责任——在内部管理这一切意味着承担巨大风险。

雇用合适的人来做这件事并不容易，而且费用昂贵。无法逃避的事实是，在内部完成这一切时，你需要投入资源、时间和金钱来成为整个生态系统的专家。

此外，Kubernetes已经面临着企业采用的障碍。大型传统企业已经投资了成熟技术，其IT团队已经具备管理它们的专业知识。让这些团队关注并开发新技术并不容易，更不用说像Kubernetes一样广泛而复杂的新技术。

管理问题

尽管存在这些问题，Kubernetes仍被认为可以帮助组织实现重要价值。但是如何做到呢？

构建Kubernetes集群，维护它们，网络和存储的挑战使得DIY越来越不可能。Kubernetes托管服务已经出现，为企业提供策划、集成、Kubernetes堆栈、开源Kubernetes认证等服务，减轻了锁定的担忧。

这些托管服务减轻了要成为Kubernetes专家才能用好它的负担，并降低了企业进入的门槛。即使是最先进的Kubernetes早期用户也正在转向这种模式，因为这种模式可以让他们的团队专注于更高层次，去做更重要的工作，实现差异化竞争。

如果你还心存疑惑，可以从小的东西开始，并利用托管服务来减轻加入Kubernetes云原生战争的负担。