开源，但有治理

如果是一个封闭的系统，Kubernetes的传播将不会相同。 Kubernetes不仅是开源的，而且还接受来自多家公司的贡献。 这是一个很大的区别，因为它消除了领先支持者的任何分歧，因为许多供应商都为此做出了贡献。 从客户的角度来看，这部分似乎很容易，但从供应商的角度来看，这已成为一个主要问题。 您会从与产品不透明的供应商处转售服务吗? 好吧，在云时代，如果您拥有大品牌，任何公共云供应商都会将您添加到他们的产品目录中。 试想一下在数据库游乐场多年的对抗之后，从Microsoft云出售的MySQL服务。

但是起初Kubernetes并非如此。 开源，透明并向贡献者开放，为公共云供应商提供了一种易于使用的解决方案，使人们可以部署容器。 此外，已经部署了本地部署的人员的市场很小。

这种混合使所有云供应商都对该产品产生了兴趣，并对其进行了推广。

但这还不够。 开源项目不能仅仅因为它是开放的而起作用。 在开源领域工作了16年之后，我对此有所了解。 为了使OSS取得成功，您需要治理和承诺。 对于这样的大型项目，它不可能是一切背后的一个人。 公司是必需的。 在这种情况下，有Google，因此该项目依赖坚实的基础。

简单来说，开源和愿景的独特结合使Kubernetes可以被所有厂商和最终用户采用。

容器化

另一个大话题是容器化。 在过去的几年中，我们看到了重大的发展。 根据CNCF的数据，集装箱在生产中的使用百分比从2016年的23%到2018年的73%。在两年内翻了三倍。 这意味着，如今，基本上所有公司都需要答案来管理容器。

从一开始，当它们被认为是不成熟的或有些差异时，容器就是现在的标准。 经过多年的探索，没有任何问题，大多数保守的IT人士也向集装箱敞开了大门。 但是不久之后，又出现了另一个问题。 那么容器管理呢? 我们可以使用简单的docker部署容器，在很多情况下这已经足够了。 但是在某些情况下，我们希望做好扩展，自动化的准备，也许我们不想花时间在本地安装东西或为此付费。

在这种情况下，Kubernetes是一个令人兴奋的选择。 它是免费的，内部部署的或在云中提供的。 它提供由供应商或设置独立的标准方法。 因此，当您使用容器时，需要一种将其投入生产的方法，该怎么办? 只需将其扔到Kubernetes集群上即可。 如果您认为自己冒烟，请阅读我的教程，从头开始将应用程序部署到Kubernetes。 本教程基于Microsoft Azure，但也可以在Google Cloud上用相同的方法完成。