是时候真正拥抱Kubernetes了？

在考虑是否实施Kubernetes时，可能要问的第一个问题是，您是否真的需要它？

任何技术的重点都不在于技术本身。如果做得正确，Kubernetes可以减少应用程序开发人员的进入门槛，因此他们可以尽快，轻松地将功能从其机器上获取给您的客户。但是，您是否已经有了一个行之有效的解决方案？如果这样做，为什么要更改它？在技​​术上进行如此根本性的改变可能非常危险，那么您的动机是什么？

坚持并改进您已经拥有的解决方案可能会带来更好的成本/收益折衷。容易陷入这样的陷阱：相信仅仅采用Kubernetes这样的新技术就能立即解决您的组织或技术难题，但是，我们知道这很少是真的。

在此博客文章中，我们将分享一些技巧和窍门，以评估您的处境，从而确定Kubernetes是否合适。我们已经从帮助数百名客户采用Kubernetes中学到了这些知识-此外，当有更好的解决方案可用时，我们则没有这样做。我们将看到问题并不是那么容易回答，并且有很多变量需要考虑。在下一篇博客文章中，我们将讨论Kubernetes非常适合的情况以及如何启动您的第一个Kubernetes项目。

请注意，这些博客文章假定您已经对Kubernetes有所了解。如果您刚刚开始学习，那么我们的Kubernetes入门博客系列是一个不错的起点。

Kubernetes是一个用于部署，扩展和管理容器化应用程序的开源系统，目前是演化链中的最后一步，该演化链始于私有数据中心，然后到云虚拟机，再到容器，再到容器协调器。 。如果您希望将应用程序连续交付到云，那么容器是实现此目标的一种好方法，而Kubernetes是负责运行它们的技术。 Kubernetes最初是由Google开发的，此后围绕它发展了一个庞大的社区，远远超出了Google的根基。 1.0版于2015年发布，最新版本于2020年10月发布。

在过去的几年中，Kubernetes变得越来越有可能。在2020年3月6日发布的ZDNet文章“ Kubernetes迅速普及”中，Steven J. Vaughan-Nichols引用了Cloud Native Computing Foundation（CNCF）关于容器和Kubernetes的调查。在做出回应的公司中，有84％使用容器，而在这些公司中，有78％使用Kubernetes对其进行管理。调查还发现，有超过109种工具用于管理容器，其中89％使用了各种版本的Kubernetes。

Kubernetes如此广泛地被采用有几个原因。这里是其中的一些：

可扩展性。虽然Kubernetes附带了大量现有资源，例如Pods和Secrets，但开发人员还可以使用自定义资源定义（CRD）创建自己的资源。他们还可以编写自己的运算符，从而使CRD的管理自动化。

社区支持。 Kubernetes社区很大，并且有许多特殊的兴趣小组。而且，Kubernetes放置在CNCF所提供的与供应商无关的平台上。 CNCF赞助了CloudNativeCon / KubeCon，这是世界上最大的开源活动之一。

第三方供应商支持。也有许多第三方供应商在重新包装Kubernetes。这些称为Kubernetes分布。他们提供了适用于生产的Kubernetes的可靠实现。例如Openshift，Rancher和VMWare Tanzu。

频繁发布。 Kubernetes经常发布，每三到四个月发布一次重要的新发布。每个版本都添加了许多新功能和创新。

鉴于其广泛的流行性，许多功能以及社区的支持，似乎选择Kubernetes是理所当然的。 “其他所有人都在使用它，因此我们公司也应该使用它。”但是是这样吗？在本文的其余部分，我们将提出一些问题，您，您的同事和管理层可以以此为基础进行讨论。这些问题旨在帮助您的组织就Kubernetes做出明智的选择。

要问自己的第一个问题是您的组织是否具有支持大规模Kubernetes实施所需的DNA。 “ DNA”不仅仅意味着技术知识。将Kubernetes纳入组织是一项重大工作，可能会影响许多团队。为了使这项努力取得成功，这些团体之间必须保持良好的沟通，信任和愿意共同应对新挑战的意愿。特别是，应用程序团队和运营团队之间的关系需要保持健康。人们必须愿意放弃竞争和政治，以便彼此协作以实现共同的业务目标。

可以想象，这可能成为热门话题。如果您对社区中的其他人感兴趣，请参考以下两条推文，以帮助您入门：

不要仅仅因为它很有趣就去做kubernetes（尽管很有趣）。这样做是因为它可以解决您遇到的问题。＆＃34; -@bridgetkromhout #SREcon

-Tanya Reilly（@whereistanya）2018年3月27日

询问您的DevOps团队Kubernetes是否适合您。副作用可能包括恶心，体重减轻，无法控制的尖叫，失眠和后悔。

-fraq（@ 0xfraq）2018年7月22日

解决此问题的另一种方法是，问自己在采用DevOps方面您的组织所处的位置。引用2020年DevOps状态报告：

我们仍然看到，大多数组织都在努力将DevOps扩展到成功之外。 DevOps经常无法进一步扩展的原因之一是，大多数企业的结构设计会导致激励措施错位，对应实现的成果缺乏责任感或所有权。

我们已经在拥有实践“云工程”，“ DevOps”，“站点可靠性工程”和/或其他更协作且面向工程的基础架构方法的客户中取得成功的可能性更大。您可能需要评估自己的组织。 DevOps成熟度模型是一个很好的指南。

我们通常出于个人动机做出决策，对于技术和购买哪种汽车都是如此。 Kubernetes现在具有很大的吸引力。它得到了很好的宣传，并且拥有很多云工程信誉的公司（例如Netflix）都在使用它。仅此一项就可以说服一些管理者做出自上而下的采用决定，认为如果适用于Netflix，那么它一定适用于他们自己的公司。有一些教程，YouTube视频和会议都说它们可以使您轻松采用Kubernetes，而Kubernetes方面的专业知识是构建简历的好方法。毫无疑问，领先公司和快速发展的社区的成功案例可带来巨大的好处-但是，仅凭这一点是不够的。就像我们将看到的那样，使用Kubernetes并不容易成功，因此，要做出正确的决定，您需要问自己一些棘手的问题，并更深入地评估使用它是否符合公司的最大利益。

下一个要问的问题是您的公司是否具有支持Kubernetes计划的工程资源。实施Kubernetes非常复杂且需要很长时间。 Netflix等公司的运营部门非常庞大，而其他大多数公司则没有。通常最好先确定一个孤立的项目，然后再将整个农场投注在该项目上，以证明Kubernetes的预期收益。就是说，不要低估即使是这些较小的项目也要付出多少努力，尤其是在加快速度方面。

Kubernetes将需要一个专门致力于其实施和支持的人员团队。实现本身非常复杂。 Kubernetes架构非常复杂，包含许多核心概念，包括执行，安全性和数据模型，用于安装和管理etcd的分布式组件以及位于其上的许多其他层。强大的实现要求对多层体系结构有深入的了解。许多云提供商现在提供的托管服务在某种程度上减轻了这种复杂性，但是了解正在发生的事情仍然很重要。

其次，使用Kubernetes部署某些东西所需的实际接口也很复杂。它可能包含成千上万行YAML，通常需要使用从未设计过使用的机制对它们进行模板化和操纵。看一看为什么我们要模板YAML？征求作者对此事的强烈意见。此外，作为基础架构团队，您几乎肯定会希望为您的应用程序开发人员提供一个更好的界面，以发布代码，而无需学习Kubernetes的复杂部分，包括编写太多的YAML。最终，您需要将CI / CD设置为连续发送。

最后，当出现问题时，您需要由专家解决。因为Kubernetes为您提供了如此高度的抽象性，所以调试起来可能很困难，并且大多数人都不了解引擎盖下发生的事情。您需要在遇到麻烦时真正有知识的人。实际上，您可能需要两个人。如果那个人离开公司，那么你太脆弱了，如果你甚至不让那个人休假，那你就完全不合理。如果您尚未练习可观察性，那么您很快就会想要。

因为您要为Kubernetes奉献几个人，所以您可能会增加其他领域的技术负担。您还有人来处理错误和其他支持问题吗？通过采用主要云供应商提供的托管Kubernetes服务可以大大降低此处的成本，但是机会成本是真实的。

与任何大型迁移一样，从当前系统到Kubernetes的迁移需要谨慎且逐步地进行。您不仅要破坏现有的基础架构。取而代之的是，您可能希望采用并行方式，并逐步移动应用程序。换句话说，在相当长的一段时间内，您需要支持两种基础架构，而不是一种。除了工程时间之外，这还可能花费实际的美元。

归根结底，值得退后一步去问自己，我们要努力实现什么，Kubernetes是否帮助我们实现了这一目标。甚至提出这个问题的动机都包括：我们希望加快公共云的采用（或在内部采用更多类似公共云的技术），我们希望更快地发布，并希望赋予开发人员权力。确实，做得好和做得对，Kubernetes可以实现所有这些目标。但是，单单Kubernetes并不会（不仅需要花更多的钱），而且如果没有Kubernetes的话，这一切都可以很好地实现，有时会更快，更便宜。许多公司，尤其是初创公司，都有着很大的梦想。他们想要一个可以无限扩展的基础架构，例如Kubernetes，以支持其快速增长的未来用户群。抱有远大的梦想并为未来做计划是件好事，但从今天开始使用更简单的解决方案并随着时间的推移逐步发展通常也更好。

例如，也许像Amazon的Elastic Container Service（ECS）这样更简单的本地容器协调器将更易于采用和管理。也许像是Heroku，Google AppEngine或Azure Service Fabric这样的PaaS，固执己见，扩展性较差，但起步和运行起来要简单得多，是更好，更便宜的第一步。如果您具有事件驱动的体系结构，那么许多无服务器计算技术之一可能更适合。

架构必须随着时间的流逝而改变。永远不会只创建一次基础架构，然后完成。无论采用哪种基础架构，都需要能够随着需求的变化和发展而变化和适应。在五年的时间里，谁知道世界会是什么样？在花了很多宝贵的钱部署它之后，过早地在Kubernetes上和过大的规模上赌注这可能是不明智的决定。

这篇博客文章讨论了在深入Kubernetes项目之前要考虑的许多问题。但是，选择Kubernetes部署现代应用程序的原因有很多。请继续关注第2部分，我们将深入探讨该主题。如果您对小型项目的外观感到好奇（使用您喜欢的编程语言，无论是哪种语言），请查看Pulumi的Kubernetes入门和Pulumi Crosswalk for Kubernetes，这些手册具有内置的最佳实践，可以使Kubernetes易于访问。大家。