在公司，你不可能没有听到过有关Kubernetes的信息，来自谷歌的red hot容器编排技术通常是大家茶余饭后的聊天话题。

很少有一种技术可以让从DevOps实习生到首席技术官(CTO)都能轻松的理解，Kubernetes也不例外，阅读有关Kubernets的文章反而会让你比以前更困惑，无法理解这些文章到底在讲些什么。当然，也有许多人认为Kubernetes是神级存在，但如果你想很好的使用Kubernetes并充分发挥它的作用，这取决于很多因素，我打算解释其中一些关键因素。

在本文中我还将为你提供一种渐进式评估Kubernetes并将其引入公司的方法。Kubernetes是一项伟大的技术，如果使用得当，它将带来巨大的好处。

1. 从一个到一群

曾几何时，服务器被系统管理员亲切地命名并贴上便利贴。而现在，我们真的不知道运行我们工作任务的服务器是什么类型的，因为那些位于冷服务器室和数据中心的灰色机架上的盒子已经让位于由Amazon、Microsoft和谷歌运行的公共云。系统管理员也会继续给运行在公共云上的虚拟机命名，就像给他们的宠物命名一样。过去，如果需要服务器，可能需要几周的时间，通过电话或电子邮件与销售人员沟通，才能最终获得我们所需的服务。但是随着高性能虚拟化和公共云的出现，出现了API。一个简单的API调用可以在几秒钟内启动一台机器。而在过去，需要花上几周的时间跟销售人员沟通。因为这样，很快，聪明的技术人员意识到，公共云不仅可以提供对计算的快速访问，还有通过简单易用的RESTful API提供自动化的潜力。这是相当有含金量的事情。

2. 作为代码和DevOps的基础设施

之后我们看到了像Chef、Puppet、Ansible和SaltStack这样的技术。有了这些，开发和运维之间的界限开始变得模糊。虽然系统管理员很少会冒险修改shell脚本，但是像Chef、Puppet和Ansible这样的系统都是成熟的系统编排框架。Puppet使用领域特定的语言或DSL来让系统管理员定义基础设施设置的最终状态，而Chef使用基于Ruby语言的DSL，该DSL充分利用Ruby的表现力来定义基础设施的最终状态。这些技术使我们完全进入了声明式和命令式基础设施的时代，在这个时代，可以使用文件中的代码定义服务器基础设施的最终状态，然后可以像常规源代码一样对其进行版本控制。这与系统管理员手动设置服务器，然后登录到服务器上设置各种软件服务和硬件资源（如存储或网络）非常不同。虽然他们所能做的仅仅是运行shell脚本，但是Chef和Puppet提供了对系统配置的集中管理，以及非常强大的API接口，使管理大量服务器变得不那么麻烦。

3.Docker的崛起

随后，另一项强大的技术将使用Linux原语组合和管理容器变得非常容易：Docker。并不像通常被认为的那样，Docker并不是一种容器技术。Linux容器是使用Linux的操作系统原语（CGroups或Control group和 Namespaces）构建的。Docker使构建和管理容器变得很容易。Docker有一篇介绍自己的文章/视频，但那是之后的事了。使用Docker，可以很容易地打包应用程序及其所有依赖项，并对其进行容器化。就像一个真正的集装箱一样，“运输”变得非常容易。然后，这个容器可以在任何Linux机器上运行，而不必首先安装它的所有依赖项，这些依赖项可能是特定于Linux发行版的。这使得在Debian Linux上运行Nginx、在Ubuntu上使用Python Flask框架以及在alpine上使用MySQL都变得很容易——这些包被封装在一起，都运行在同一台Linux服务器上。总之，Docker成为以声明方式构建容器的标准方法，然后在Linux服务器上运行和管理它们的生命周期，利用Linux的底层容器技术并提供巨大的实用程序。这也就可以理解为什么当Docker第一次出现时就引起了大家的兴趣。

虽然Chef和Puppet等技术擅长管理物理和虚拟机的配置，但是容器很快就成为DevOps工程师部署应用程序的标准方式。此外，容器封装了应用程序部署逻辑的大部分，使编排的其余部分简单得多。现在正是采用更现代的以容器为中心的编排系统的时候。

然而，与此同时，还有另一种快速发展的方法将ops越来越多地转移到开发人员的领域：DevOps。工程师们已经发现，虽然ops的人想要稳定，但开发人员却一直想要发布新特性，这对ops所追求的稳定提出了挑战。这些相互冲突的目标，常常使团队陷入矛盾，甚至直接影响产品的发货速度。此外，当产品开发人员没有意识到他们编写的代码在生产环境中引起的所有问题时，他们往往不会花精力去修复它。这是因为生产环境原则上是ops团队的职责范围。为了解决这些问题，团队开始尝试一种新的方法，DevOps。想法很简单：让编写代码的人在生产环境中运行代码。这样他们就需要对自己发布的代码负责任了。如果他们想要更频繁地发布新特性，他们需要在ops方面保证正常。云和容器等技术及其API和工具使得将软件工程方法引入云操作成为可能。快速迭代的DevOps团队正在构建大型应用程序，这些应用程序通常由独立开发和发布的微服务组成，而不需要更改、测试和发布一个大型的单一应用程序。使用微服务体系结构实践DevOps的团队喜欢云和容器的易塑弹性，它们可以被可伸缩的工具和API轻松控制。

4. 进入Kubernetes时代

在DevOps和微服务与容器衔接的地方，一个新的、更本机的编排系统更有意义。Kubernetes受谷歌的Borg系统启发，是一个开源的容器编排系统，最初由谷歌的工程师构建，现在由云计算基金会CNCF维护。作为一个容器编制平台，Kubernetes可以帮助自动化应用程序部署、扩展和管理。像Docker这样的系统管理服务器内的容器，Kubernetes做的更多，但是它的主要功能之一是管理服务器集群或可以运行容器的节点。与Kubernetes类似的系统有Apache Mesos和Docker Swarm。尽管关于哪一种制度会成为行业标准存在争议，但到目前为止，很明显，Kubernetes已成为赢家。在你的容器编排策略上押注Kubernetes是一个非常明智的决定。

不仅仅是Docker

值得注意的是，Kubernetes不仅可以编排Docker管理的容器。它还可以编排由类似于Docker的系统（如ContainerD、crio和RktLet）管理的容器。虽然你可以使用任何这些系统创建和管理容器，但是由于本文/视频的初衷，我们将用“Docker”表示“容器管理”。下面，我们一起来看看Kubernetes的一些最重要的特性。

为什么需要Kubernetes

要理解为什么像Kubernetes这样的系统很重要，最好思考一下Docker的功能局限在哪里。
Docker使管理服务器内容器的生命周期变得很容易，而Kubernetes使管理运行Docker容器的服务器集群变得很容易。此外，现代的基于微服务的应用程序通常由几个容器组成。Kubernetes提供了一个“应用程序部署”的概念，它本质上是一组组成应用程序的容器，在集群上以分布式方式运行。当你想要一个由一堆容器组成的应用程序运行时，你只需告诉Kubernetes它的相关信息，它就可以找出集群中的哪个节点具有足够的计算资源来运行容器，并将其调度到那里。它还可以在容器失败时重新启动容器，甚至根据一些参数扩展应用程序，通过运行更多容器来应对流量激增。这就是Kubernetes的精髓，这就是人们所说的“容器编排”。

当在一个集群上运行多个应用程序时，还有一些很好的特性可以帮助简化管理。Kubernetes具有使管理应用程序配置和凭证更容易的特性。Kubernetes还管理着其他一些基础设施，比如存储和网络。除了计算，这是构成任何基础设施的最基本的三个组件的另外两块。

管理与否

虽然可以通过从头开始在私有云上运行Kubernetes，但更明智的做法是选择像OpenShift这样的Kubernetes发行版，它有些功能可以付费支持——至少在你扩展Kubernetes基础设施之前。也可以在AWS、Azure或GCP上的机器集群上安装Kubernetes，但是所有这些公共云也提供托管Kubernetes产品。Kubernetes由多个组件组成。它们协同工作，帮助运行称为计算节点的计算机集群。仍然会有Kubernetes组件在每个计算节点上运行。当你选择任何公共云供应商提供的托管Kubernetes产品时，他们通常会要求你从它们的计算产品中选择一定类型的节点，然后这些计算产品将成为Kubernetes集群的一部分。这些节点将部署你的容器化工作任务。Kubernetes的主组件（也称为“控制平面”）由云提供商管理。

5. 你的公司准备好使用Kubernetes了吗?

这并不取决于一个因素，而是一系列因素。我们详细讨论一下这些因素。

你使用的是私有云还是公共云?

Kubernetes可以部署在公共和私有云上。在私有云上，虽然理论上可以自己安装和维护Kubernetes，但是最好运行一个Kubernetes发行版，比如OpenShift，它可以获得供应商支持。虽然Kubernetes诞生于云中，是一种被称为“云原生”的技术，但是它是管理计算集群的一个很好的选择。如果你运行它是为了管理私有云，这也没关系。事实上，可以认为Kubernetes是管理私有云的一个很好的选择。

对于AWS、Azure或GCP等公共云，你可以通过自己设置Kubernetes来在一组计算节点上运行它。例如，Kops是一种流行的解决方案，它允许你在AWS上运行的一组EC2实例上部署Kubernetes。但是，我强烈建议你将维护Kubernetes控制平面的工作交给云提供商，选择使用托管Kubernetes提供的服务，这样你就可以专注于在Kubernetes上运行工作任务的机制。

你目前使用Docker的情况如何?

如果你想在Kubernetes上运行的应用程序没有被封装，那么它就不会启动。Kubernetes是一个容器编制平台，你必须确保要在Kubernetes上运行的应用程序在生产中的Docker上经过了良好的测试。在稍后的时间里，我们将讨论一个简单的策略，即如何一步一步地推出它。Docker被广泛使用，工具非常成熟，可以肯定地说，Docker已经远远超过了炒作阶段。无论你的公司采用的IT策略多么“谨慎”，都不应该怀疑使用Docker带来的风险问题。另一个真正的优势是，当Docker与Kubernetes正确实施时，可以真正提高服务器的利用率。这是值得考虑的。

你的DevOps文化成熟度如何?

强大的DevOps文化的存在意味着devs负责运行他们在生产中开发的服务。他们总是通过在操作方面寻找自动化的方法来提高自己的生产效率。如果你的应用程序或服务基于微服务体系结构，这很棒，这意味着有许多移动部件和拥有不同微服务的团队需要彼此独立运行。如果这种文化存在，Kubernetes对你们就再合适不过了，你们应该尽快使用它。Kubernetes可以很好地运行单片工作任务。这里的重点是，如果有两个不同的团队，开发和运维，运维团队使用全新的部署方式，开发团队致力于采用容器化构建系统和应用程序的配置方式，然后让这两个团队进行密切的配合就有点异想天开了。

Kubernetes人才储备

Kubernetes可能需要一段时间来学习，只有当学习它的人已经在努力学习容器化时，它才有意义。现在市面上提到Docker的书不一定很多。但如果你确信Kubernetes适合你们，并且考虑了上文中提到的几点因素，那么你就需要更多的同事参与其中了，他们能够并且有信心在Kubernetes上运行生产工作任务。如果公司中员工对Kubernetes仅有初步的了解，那么我们将帮助你们在此基础上构建经验，同时降低风险，并为将来在Kubernetes上运行生产工作任务构建一条道路。下面我们来看具体怎么做。

6. Kubernetes陷阱

如果有人把Kubernetes称为万能药方，那么他们并没有对Kubernetes进行客观的认识。下面是一些需要注意的事情。

被Kubernetes管理也并不能保证万全

Kubernetes是一个由许多协同工作的软件组成的系统。不管你是直接管理还是选择管理Kubernetes，事情都可能会出错。被管理下的Kubernetes在其各种组成部分中出现问题并不罕见。不要仅仅因为Kubernetes控制平面是由云提供商管理的，就认为什么都不会出错。你可以在Github上找几个云提供商提供的Kubernetes问题看看。当出现问题时，你可能仍然需要联系支持人员，以便解决问题。这可能会导致停机。因为控制平面中的Kubernetes组件只创建和监视容器，如果它们出现问题，通常不会影响已经运行的容器。对于一架由Kubernetes控制的飞机来说，带着所有的集装箱一起坠落是非常罕见的。但是，会导致不能创建新的容器和自动伸缩等问题。

Kubernetes上的有状态应用程序仍在演变

Kubernetes的用途是创建和销毁像短命昆虫一样的容器。可以创建许多容器来响应通信量的激增，并在恢复正常后销毁这些容器。这意味着这将是一个非常动态的环境，在这里，服务器被真正地进行集群处理——这与用类似于宠物的方式亲切地命名服务器的时代相去甚远。从这个意义上说，Kubernetes对数据库等有状态的应用程序的支持似乎是有点马后炮的。这是一个活跃的开发领域，并且现在相当稳定，但是如果与其他领域相比，假如Kubernetes下的有状态应用程序的工作方式继续发生相对快速的变化，人们不应该感到惊讶。

可以以云提供商中立的方式分配持久性卷，以便在Kubernetes本地支持的有状态应用程序中使用。

如果你想使用底层云提供商管理的有状态服务( 比如： RDS、DynamoDB等)，可以使用Kubernetes提供的原生方法Service Catalog，这使得使用云提供商的托管服务变得更容易。

Kubernetes升级

通过web搜索引擎应该会找到很多关于Kubernetes集群升级的恐怖故事，使你放弃更新并继续使用现有的集群设置。其实最好的方法可能是重新创建一个具有与生产集群相同版本的集群，并在其中安装关键应用程序，然后升级这个集群，在继续升级到生产集群上的新版本Kubernetes之前，检查是否一切正常。还是面对现实吧——如果你认真对待Kubernetes及其带来的好处，那么集群升级是不可避免的。所以，做好计划并执行。

可移动组件

虚拟化。这是一个我们现在认为很常见的抽象概念，一个我们经常使用的抽象产品。事实上，当有人提到“机器”或“服务器”时，他们很可能指的是虚拟机。对于应用来说，Kubernetes极有可能成为新的标准基片。一个新的抽象层次，将成为新的常态。然而，对于虚拟机，由于大多数大型系统都标准化于Linux的KVM技术，它在很大程度上是操作系统层的一部分。尽管涉及到其他组件，但它们的级别相当低。它与Kubernetes非常不同，Kubernetes中有十几个服务在一组机器之间相互通信，处理相当复杂的计算、存储、网络和自动伸缩功能。

当问题出现时，有时我们往往会深入研究Kubernetes去搞明白出了什么问题。其实我们只需要在某种程度上假设Kubernetes使用的所有这些组件的不同版本在某种程度上是相互协调的。至少这是云提供商给我们做了保障的。

留住Kubernetes人才

如果你渴望大力使用Kubernetes，但可用人力却很少，那么你这样做就是有风险的。对于你的项目Kubernetes是有价值的，所以让你的整个DevOps团队在Kubernetes上进行培训或自我培训是非常有必要的。毕竟，大家都希望通过培训的机会，掌握一项炙手可热的技术。从安全的角度来讲，重要的是不要只有一两个DevOps人员，而是要有一个能够很好地处理Kubernetes的团队，这样，如果你唯一的Kubernetes员工离开了，那么你的Kubernetes项目才能保持连续性。这种事经常发生——相信我，由于Kubernetes在他们的LinkedIn页面上被列为一项技能，招聘人员不会花太长时间就会打电话给他们。

7. 将Kubernetes引入公司

至此，如果你确信使用Kubernetes可以让你的公司从中获益，那么你可以参考下以下一些步骤，以一种能够让你充分地理解Kubernetes以及运行它来管理生产工作任务的方式引入它。

培训或雇用Kubernetes人才

你需要从DevOps团队中选择具有Kubernetes实践经验的人员来执行你的计划。有了高质量的在线培训材料，他们可以进行自我培训，也可以参加更正式的培训项目。你还可以咨询云供应商，看他们是否可以为你公司提供专门的培训，或者他们是否可以给你的团队提供一些相关活动。你也可以选择一些其他的付费项目。

聘用Kubernetes人才是另一种途径。寻找有Kubernetes运行经验的人员。雇用他们之前，你可以跟他们讨论实施Kubernetes的工作步骤，以及他们在Kubernetes上运行生产工作任务时所面临的一些挑战。询问他们是否运行过任何有状态的工作任务。基于此讨论，你应该能够确定他们是否适合你的项目。

将工作任务转移到Docker

如果你想要迁移到Kubernetes的工作任务还没有在Docker上的生产环境运行过，那么通过直接将这些工作任务迁移到Kubernetes会使困难度有所增加。如果你遇到任何问题，你将无法准确判断它是由构建时、运行时还是配置问题引起的。另一方面，如果你的团队已经将工作任务进行了容器化，并且使用Docker在生产环境中运行了这些工作任务，那么在遇到问题时，需要处理的事情就会更少。

在Kubernetes上运行非生产工作任务

现在你的工作任务已经封装完成，你还可以将一些非生产工作任务（比如那些在开发中或临时性的任务）转移到Kubernetes。这样，你的大型团队就可以适应新的环境，将Kubernetes顺利地集成到你持续部署的管道中了。

无状态工作任务优先

在将生产工作任务迁移到Kubernetes时，最好先从无状态工作任务开始：容器只服务于应用程序请求，而不直接持久化任何数据。在Kubernetes上运行有状态工作任务需要更深入的Kubernetes专业知识，你可以在公司中先通过运行无状态工作任务构建它。例如，对于有状态工作任务，你需要更详细地规划如何在节点宕机时进行管理。这对于像Elasticsearch这样的分布式有状态应用程序尤其复杂。

移动非关键工作任务

将非关键工作任务先转移到Kubernetes上，并让你的团队积累在其上运行生产工作任务的经验，这也是一个不错的办法。在生产环境中运行工作任务还需要考虑其他因素，例如监视、警报和应用程序升级等。

实现飞跃

我们了解了如何在公司中实施Kubernetes，从而在构建专业知识的同时降低风险。我们还讨论了如何从工程的角度准备好将生产工作任务封装到Kubernetes中，并慢慢地将其引入Kubernetes。你是决策的关键者，知道什么时间点开始做这个事情。每个公司使用新产品的风险是不同的，要自动部署Kubernetes集群，我的建议是使用Terraform之类的工具。

8. 总结

一份好的计划会充分考虑清楚风险。这就是本文的主要思想：告诉你风险所在，以及如何在Kubernetes策略中避免这些风险。Kubernetes是一项伟大的技术，在很多领域，它肯定会对你有所帮助。但是，与你打算在其上运行生产工作任务的其它技术一样，你需要权衡风险，并评估收益是否大于风险。Kubernetes有很多失败的案例资源，这对于找出最常见的问题，甚至如何解决这些问题都很有帮助。

就我个人而言，我对Kubernetes感到非常满意，Kubernetes提供的编排、自动伸缩、服务器利用率和自修复功能有很多有用之处，完全可以取代我们自己的构建。

原文链接：

https://unixism.net/2019/08/a-managers-guide-to-kubernetes-adoption/

创作场景

用了就会更好吗？小心 Kubernetes 陷阱