Kubernetes技术是十分难的，但如果你自己管理这一快速发展的技术，情况就会变得双倍困难。
你在考虑自己管理Kubernetes部署吗？不要这样做。
噢，当然，如果你真的很聪明，可以圆满完成这一工作的话，但考虑到Kubernetes部署的发展速度，你真的想要这么做吗？尤其是考虑到市场上有那么多极其方便的Kubernetes云服务？
不，真的，千万不要这样做
CNCF在2017年12月的一份调查报告显示，大量公司都选择在本地运行Kubernetes（42%）。然而，即使是那些在云端运行它的公司都不一定使用了诸如谷歌的GKE这样的服务：
问题是，为什么会出现这种情况？正如Gravitational的Abraham Ingersoll在近来的一篇博客中所指出的：
运行Kubernetes应用程序最安全的地方仍旧是谷歌的GKE。他们创建了它，并且谷歌的SRE工程师们编写了一本书，讲述如何成功地运行大规模分布式系统。只要使用了GKE和类似的Kuberentes“平台”，你就无法接触到控制集群的大多数有趣的旋钮和按钮，你最终也可能会支付荒谬的公有云带宽出口税。买家要意识到这些情况，但现在去购买它吧。
你可能会被锁定在一个云服务中。然而，另一种选择是完全地被排除在Kubernetes的价值之外。为什么？因为Kubernetes技术是十分难的。
情况可能更糟
“只要有可能，人们都强烈倾向于保持上游项目的灵活性。” Ingersoll写道。这对创新Kubernetes是很好的，但对特定的Kubernetes部署却是十分糟糕的。
据该报告表示，Kubernetes当前发布的结构是这样的：“如果你在去年三月它发布出来之后不久部署了Kubernetes 1.6集群，那么你就很有可能会在大约9个月的时间里升级到1.7，或者等到12月中旬1.9版本发布时，升级到该版本。” 这可能不会让很多Kubernetes大师感到烦恼（尽管CNCF的另一项调查显示，部署的Kubernetes中有很大一是不支持的版本），但是它将会给那些在10年的支持政策中成长起来的企业造成严重的阻滞，即使是在开源的领域中（如红帽企业的Linux）。
再一次，你可以采用这一技术，但是为什么呢？正如Ingersoll所指出的：“Kubernetes平台供应商能够魔法般地处理围绕向后不兼容方面的迁移，或是在上游Kubernetes API中的强迫迁移。”
甚至更好，他说到：“Kubernetes即服务产品，尤其是Google Cloud的Kubernetes引擎（GKE），是目前最稳定、最具生产价值的Kubernetes版本，因而它成为了行业的领头羊。”谷歌首先开发了Kubernetes，因此它最了解如何保持它的运行（因此你就不用自己去做了）。
不仅如此。在与红帽公司负责经营OpenShift业务的Ashesh Badani的谈话中，Badani告诉我，“Kubernetes是应用平台的一个强大的基础，但对于大多数公司来说，它仍然是一项无差别的、沉重的任务，包括整合存储、网络、安全、应用框架等，同时每季度也要对它进行一次更新。”红帽是用OpenShift来提供Kubernetes的；谷歌是通过GKE完成的；亚马逊用EKS来管理它。你为什么要经历这些麻烦？
在不增加其复杂性的情况下，Kubernetes已经足够困难了，此外还有操作上的开支。是的，这可能存在云服务锁定的威胁，但考虑到开源Kubernetes的可用性，最有可能的锁定风险是，一旦你使用过GKE或OpenShift或另一种云计算选项，你就永远不想要自己管理Kubernetes了。
