简介您可能经常在公司听说Kubernetes。这种起源于谷歌的容器编排技术现在非常流行。好像不管是DevOps还是CTO，是否完全理解这个技术，都在谈。读这篇文章可能会让你更加困惑，你可能无法完全理解它。有人希望Kubernetes能帮他解决所有问题，但事实并非如此。在本文中，我将重点介绍几个关键因素，以帮助您决定是否采用Kubernetes以及采用何种程度。我还将为您提供Kubernetes的分步评估及其在您的组织中的逐步介绍。Kubernetes是一项伟大的技术，如果使用得当，可以带来巨大的好处。1、从宠物到羊群>过去，服务就像宠物一样，需要管理员一只一只地管理和维护。现在服务器更像羊群。管理员可以通过简单的命令或配置来管理大量的服务器。曾几何时，系统管理员使用主机名和便利贴来管理服务器。今天，我们不知道我们的工作负载在什么类型的服务器上运行，因为这些本应放在机房和数据中心的机器已经让位于亚马逊、微软和谷歌等公共云提供商。系统管理员确实会像命名宠物一样命名在公共云上运行的虚拟机。但在过去，当销售人员需要一台服务器时，系统管理员可能会花数周时间通过电话或电子邮件与销售人员交谈以配置它。但随着高性能虚拟化和公共云API的出现，一个简单的API调用可以在几秒钟内启动一台机器。聪明的技术人员意识到，公共云不仅提供了对计算的快速访问，还提供了通过提供易于使用的RESTfulAPI实现自动化的能力。真的很漂亮。2、代码作为基础设施和DevOps随着Chef、Puppet、Ansible、SaltStack技术的出现，开发和运维之间的界限越来越模糊。过去，系统管理员很少涉足shell脚本以外的语言，而Chef、Puppet、Ansible都是成熟的系统编排框架。Puppet使用领域特定语言（DSL：DomainSpecifiedLanguage）让系统管理员定义其基础设施设置的最终状态，而Chef使用基于Ruby语言的DSL，可以充分发挥Ruby语言定义基础设施的最终状态。这些技术将我们直接带入声明式和命令式架构时代，我们可以通过文件中的代码定义服务器基础架构的最终状态，因此架构可以像源代码一样进行版本控制。这与手动设置服务器并登录安装各种软件和设置硬件资源（如网络、存储等）有很大不同，虽然管理员可能会运行一些脚本来使这个过程更高效，但现在，使用Chef和Puppet可以集中管理系统配置，并通过它们强大的API，可以轻松管理大量的服务器。3.Docker的兴起Docker并不是一种容器技术，它是利用linux原有特性轻松管理和组合容器的强大工具。Linux容器是使用Linux（CGroups是ControlGroups和Namespaces）构建的操作系统的原始特性。Docker只是让构建和管理容器变得容易。使用Docker，可以轻松打包应用程序及其所有依赖项。就像真正的容器一样，“运输”变得容易。然后，此容器可以在任何Linux机器上运行，而无需预安装其依赖项（其中一些可能是特定的Linux发行版）。通过容器技术，我们可以从DebianLinux运行Nginx，从Ubuntu运行PythonFlask框架。同时，我们也可以从Alpine中运行MySQL。这些软件共同构成了用户的应用。所有这些包都在同一个Linux服务器上运行。总而言之，Docker提供了一个以声明方式构建容器的标准，并提供了在Linux服务器上运行和管理容器生命周期的工具，为Linux容器技术的成功掌握提供了极大的便利。尽管Puppet和Chef擅长管理物理机和虚拟机的配置，但Devops更喜欢使用容器来部署应用程序。容器很快成为标准，容器可以包含大量应用程序部署逻辑，使业务流程的其余部分更容易。很简单，是时候采用更现代的以容器为中心的编排系统了。同时，另一种快速的开发方式，让运维人员越来越深入到开发者这个领域。Devops，工程师发现运维人员希望系统稳定，开发人员希望随时发布新功能。这对稳定性提出了巨大挑战。这两个目标相互矛盾，导致团队之间互相打架，直接影响到产品交付的速度。开发团队的人在意识到他们的代码在生产中导致了什么样的问题之前，不会费心去修复它。因为生产环境通常由运维团队负责。为了解决这些问题。团队开始尝试一种新的方式：DevOps，这种方式很简单，谁写了代码，谁负责发布到生产环境。同时，他还将负责后续的轮班工作。如果开发人员想要更频繁地发布新功能，那么他们需要了解运营人员需要做什么来支持发布。云和容器技术及其强大的API和工具链允许将这种方法整合到云操作中。快速移动的DevOps团队构建由微服务组成的大型应用程序，每个微服务都可以独立开发和发布，而不需要测试和发布整个大型应用程序。试验DevOps的团队使用微服务架构，他们喜欢云和容器的可延展性和灵活性，程序员可以通过脚本工具和API轻松控制这些。4.进入Kubernetes当DevOps和微服务遇到容器时，一个新的本地编排框架出现了。Kubernetes受到GoogleBorg系统的启发，是一个开源的容器编排系统，最初由Google工程师构建，现在由CNCF（CloudNativeComputingFoundation，云原生计算基金会）维护。作为容器编排平台，Kubernetes支持自动化应用程序部署、扩展和管理。虽然Docker等系统也可以管理服务器中的容器，但Kubernetes更强大，其主要功能之一是能够管理运行容器的服务器或节点集群。类似的框架包括ApacheMesos和DockerSwarm。但到目前为止，很明显Kubernetes已经成为赢家。现在，选择Kubernetes作为容器编排框架是一个非常稳妥的选择。4.1不仅仅是Docker值得注意的是，Kubernetes可以编排容器，而不仅仅是由Docker管理。它还可以编排由类似Docker的系统（如ContainerD、Cri-O和RktLet）管理的容器。尽管您可以为这些系统创建和管理容器，但在本文中我们将使用“Docker”来指代“容器管理”。现在，让我们来看看Kubernetes的一些最重要的特性。4.2为什么选择Kubernetes想知道Kubernetes为什么如此重要，首先要了解Docker的边界在哪里。虽然Docker可以很方便地管理一个容器在一台服务器中的生命周期，但Kubernetes可以很方便地管理多个运行Docker容器的服务器（即集群）。.另一方面，如今，微服务应用程序通常由多个容器组成。Kubernetes提供了“应用部署”的概念，指的是一组容器组成一个应用，并以分布式的方式运行在集群上。当你想运行一个由一组容器组成的应用程序时，你只需告诉Kubernetes，它就可以找出集群中哪些节点有足够的计算资源来运行容器，并在那里调度它们。Kubernetes会在容器出现故障时重启容器，甚至可以根据某些参数扩展您的应用程序，例如增加容器数量以应对流量激增。这就是Kubernetes的本质，这就是人们所说的“容器编排”。当在集群上运行多个应用程序时，Kubernetes还提供了其他功能来简化管理。它使管理应用程序配置和证书变得更加容易。Kubernetes还管理其他基础设施，例如存储和网络、计算，这是构成任何基础设施的三个基本构建块。4.3是否托管虽然你可以在私有云上从头开始构建Kubernetes，但在扩展kubernetes基础设施之前，你最好选择OpenShift的Kubernetes发行版，它提供付费支持。当然，你也可以选择在AWS、Azure或GCP集群上构建Kubernetes。Kubernetes由多个组件组成，这些组件一起运行一个集群（称为计算节点），每个组件也运行Kubernetes。当你从任何公有云中选择托管的Kubernetes产品时，你可以选择他们提供的任何类型的计算节点来组成一个Kubernetes集群，可以用于容器部署，但Kubernetes的主要主要组件（也称为“控制平面"))由云服务提供商管理。5.您的组织准备好使用Kubernetes了吗？这取决于许多因素。5.1公有云或私有云Kubernetes可以部署在公有云和私有云上。在私有云上，虽然理论上您可以自己安装和维护Kubernetes，但最好运行提供的Kubernetes发行版，例如提供供应商支持的OpenShift。Kubernetes诞生于云端，是所谓的“云原生”技术，是管理计算集群的绝佳选择。事实上，Kubernetes也是管理私有云的绝佳选择。对于AWS、Azure和GCP等公共云，您可以在一组计算节点上运行Kubernetes。例如，您可以使用Kops（一种流行的解决方案）在AWS中的EC2实例上部署Kubernetes。但是，我强烈建议您选择使用托管Kubernetes产品，从而将维护Kubernetes控制平面的工作卸载到云服务提供商，以便您可以专注于如何在Kubernetes上运行您的工作负载。5.2目前在您的项目中采用Docker的程度如何？Kubernetes不是入门级产品，它是一个容器编排平台。如果您计划在Kubernetes上运行的应用程序尚未容器化，您必须首先确保这些应用程序在生产中的Docker上经过良好测试。稍后，我们将介绍如何逐步实施此操作的简单策略。Docker被广泛采用，工具非常成熟，可以说Docker已经过了炒作阶段。无论您的组织的IT策略多么“审慎”，采用Docker都没有太大风险。以正确的方式将Docker与Kubernetes结合起来，确实可以提高服务器的利用率。因此，此事值得考虑。5.3组织中DevOps文化的成熟度如何？强大的DevOps文化意味着开发人员负责运行他们在生产中开发的服务，并且他们将始终寻求一些自动化来提高他们的生产力。尤其是当应用或服务基于微服务架构时，意味着不同的团队需要独立运行不同的微服务，Kubernetes非常适合这种情况，可以在内部快速采用。但另一方面，Kubernetes也可以很好地运行单个工作负载。这里的关键点是，如果你有两个独立的团队，开发和运维，如果运维团队以一种全新的部署方式工作，然后让开发团队尝试适应容器化和应用程序供应系统的构建，那么两者都不是团队可能会付出很多努力来实现它。5.4组织中是否有足够的员工了解Kubernetes学习Kubernetes需要一定的时间，只有学会了容器化才有意义。如果您确信Kubernetes适合您的组织并考虑了上面列出的几点，您可能需要几个有能力并且有信心在生产中使用Kubernetes的支持者。如果你的组织只有Kubernetes的新手，我们会提供一个路径帮助你积累经验，同时降低使用Kubernetes的复现风险。稍后我将展示如何做到这一点。6.Kubernetes陷阱如果有人称Kubernetes为灵丹妙药，那么他们可能仍处于起步阶段。以下是您需要注意的一些事项。6.1ManagedKubernetes不是灵丹妙药Kubernetes是一个由许多软件协同工作的系统。无论是直接管理还是选择托管Kubernetes，都可能会遇到问题。即使使用托管Kubernetes，它的各个组件也可能存在问题。不要仅仅因为Kubernetes控制平面由您的云服务提供商管理就认为它不会出错。您可以在Github上找到几个特定于云提供商的Kubernetes问题。当出现问题时，您可能仍然需要联系支持并进行处理。这可能涉及停机时间。因为控制平面中的Kubernetes组件只创建和监控容器，所以如果它们失败，它们通常不会影响已经运行的容器。但是，控制平面的问题可能会影响诸如创建新容器和自动缩放容器数量之类的事情。6.2Kubernetes上的有状态应用程序仍在不断发展Kubernetes适用于创建和销毁（短期）容器的应用程序。为了应对流量高峰，可以临时创建许多容器，一旦情况恢复正常就会终止。与后台作业运行器相同。这意味着它将是一个非常动态的环境，服务器被视为一个整体而不是个体。这意味着似乎没有考虑像数据库这样的有状态应用程序。其实数据库领域的发展一直很活跃，现在这个功能也比较稳定。然而，Kubernetes的有状态应用的能力仍在快速变化。Kubernetes本身支持在有状态应用程序中使用持久卷。当然，您可以通过云提供商的方式将持久卷分配给有状态的应用程序。如果要使用基础云提供商管理的有状态服务（如RDS、DynamoDB等），需要使用Kubernetes的服务目录（ServiceCatalog），让kubernetes可以消费云提供商托管的服务。6.3Kubernetes升级您可能担心Kubernetes集群升级会带来严重的后果，这让您更愿意保持现有的集群设置。那么最好的方法可能是创建一个与生产集群具有相同版本的Kubernetes和配置的新集群，安装所有关键应用程序并升级该集群，检查一切是否正常，如果是，则升级生产集群。如果你认真对待Kubernetes及其带来的好处，那么集群升级是你无法避免的事情。因此，计划和执行是最好的解决方案。6.4众多灵活的组件说到虚拟化技术，这已经是我们习以为常的抽象技术了。事实上，当有人提到“计算机”或“服务器”时，他们很可能指的是虚拟机。对于应用来说，Kubernetes很有可能成为新的标准底层。新的抽象层次成为新常态。至于虚拟机，由于大多数大型系统都标准化了Linux的KVM技术，它是操作系统层不可或缺的一部分，虽然也有其他组件参与，但都是相当底层的。它与Kubernetes非常不同，Kubernetes有十几个服务在不同机器之间相互通信，在计算、存储、网络和自动缩放方面进行相当复杂的操作。出现问题时，您可能不得不袖手旁观。我们只能在某种程度上假设Kubernetes使用的这些组件的所有不同版本都以某种方式相互兼容。至少云服务提供商希望我们相信这一点。6.5留住Kubernetes人才如果你想采用Kubernetes，但只有一个人支持你，你需要自己承担风险。虽然Kubernetes已经在您的项目中证明了它的价值，但正如我们将要看到的那样，让您的整个DevOps团队接受Kubernetes培训或自学。毕竟，谁想要一个从事热门技术的培训机会？另一方面，你需要一个熟悉Kubernetes的DevOps团队而不是一两个人来维护未来Kubernetes执行的连续性。相信我，随着Kubernetes在您的LinkedIn页面上被列为一项技能，人们很容易跳槽，不能仅仅依靠一两个人来执行任务。7.将Kubernetes引入你的组织此时，如果你确信你可以从在你的组织中部署Kubernetes中获益，你可以按照以下步骤让你的团队了解Kubernetes并采用它来管理生产工作负载。7.1培训或聘请Kubernetes人才您需要DevOps团队中具有Kubernetes知识和实践能力的人员来执行您的计划。鉴于网站上提供的高质量培训材料，他们可以自学或参加更正规的培训计划。您应该咨询您的云提供商，看看他们是否可以为您的组织提供特定培训，或者您的团队可以参加哪些培训。您所在地区可能还有其他付费选项。雇用Kubernetes人才是另一种选择。寻找使用过Kubernetes来运行生产工作负载的人。雇用他们时，您可能想与他们谈谈他们之前在生产中的表现以及在Kubernetes上运行生产工作负载的挑战。询问他们是否运行任何有状态的工作负载。从这些讨论中，您应该能够确定它们是否适合您的项目。7.2将工作负载迁移到Docker首先，您需要将工作负载迁移到Docker，然后从Dodcker迁移到kubernetes。如果你的应用没有跑在docker上，你想直接迁移到Kubernetes，那么遇到问题的时候，你将无法准确定位是build-time、runtime还是configuration的问题。另一方面，如果您的团队花时间将工作负载容器化并使用Docker在生产环境中运行它们，您需要考虑的问题就会减少。7.3在Kubernetes上运行非生产工作负载现在您的工作负载已容器化，您可以将一些非生产工作负载（例如开发和临时工作负载）迁移到Kubernetes。这样，您的大型团队就可以先适应环境，将Kubernetes集成到您的持续部署管道中，等等。7.4将无状态工作负载迁移放在首位将生产工作负载迁移到Kubernetes时，您可以从无状态工作负载开始：无状态工作负载是仅服务于请求但不直接保存任何数据的容器。在Kubernetes上运行有状态工作负载需要更深入的Kubernetes专业知识。对于有状态工作负载，您需要更仔细地规划如何在节点发生故障时进行管理。这对于像Elasticsearch这样的分布式有状态应用程序来说尤其复杂。7.5迁移非关键工作负载首先只将非关键工作负载迁移到Kubernetes上，让您的团队获得在其上运行生产工作负载的经验。例如，在生产中运行工作负载所需的监控、警报和应用程序升级。7.6大跃进从上面的步骤中，我们已经看到了如何在组织中采用Kubernetes以建立专业知识同时降低风险的方式。我们还讨论了如何为容器化做准备，并从工程角度将生产工作负载慢慢引入Kubernetes。你只需要判断什么时候是最好的时机。每个组织的采用率和风险率都不同，因此您应该做出最佳判断。我的建议是您使用Terraform之类的东西来自动部署Kubernetes集群本身。8.结论最好的计划总是考虑最坏的情况，这就是本文的主要思想：告诉你潜在的问题以及如何降低采用Kubernetes的风险。Kubernetes是一项伟大的技术。它肯定会在很多方面帮助你。但是，与您打算用于生产工作负载的任何技术一样，您需要权衡风险以确定收益是否大于风险。查看Kubernetes失败案例有助于找出最常见的问题以及如何解决这些问题。就个人而言，我对Kubernetes和在其上运行生产工作负载感到非常兴奋。Kubernetes提供的编排、自动缩放、提高服务器利用率和自我修复功能提供了真正的好处，所有这些都无需花费您自己的时间即可实现。译者简介：Grace，程序员，毕业于纽约州立大学石溪分校研究生。目前就职于联泰云公司，对容器化技术和数据可视化技术感兴趣。
