Get best of the week

Kubernetes：开源与供应商

嗨，我叫Dmitry Krasnov。五年多来，我一直在管理Kubernetes集群并构建复杂的微服务架构。今年早些时候，我们推出了基于Containerum的Kubernetes集群管理服务。借此机会，我将告诉您Kubernetes是什么，以及与供应商的集成与开源有何不同。

首先，什么是Kubernetes。这是一个用于管理大量主机上的容器的系统。顺便说一句，从希腊语翻译为“飞行员”或“舵手”。最初由Google开发，然后由Cloud Native Computing Foundation（一家国际非营利组织）召集了全球领先的开发人员，最终用户和容器技术提供商，作为技术贡献而转让。



操纵大量容器


现在让我们看看它们是哪种容器。此应用程序及其所有周围环境-主要是程序所依赖的库。所有这些都打包在归档文件中，并以映像的形式呈现，可以在不考虑操作系统，经过测试且不仅限于此的情况下运行。但是存在一个问题-在大量主机上管理容器非常困难。因此，创建了Kubernetes。

容器映像是一个应用程序及其依赖项。应用程序，其依赖项和OS文件系统的映像位于映像的不同部分，即所谓的层。可以将层重新用于不同的容器。例如，Ubuntu基本层可用于公司中的所有应用程序。启动容器时，无需在主机上存储一个基础层的多个副本。这使您可以优化图像的存储和传送。

当我们想从容器启动应用程序时，必要的层相互叠加，并形成一个覆盖文件系统。用于记录的层叠加在顶部，当容器停止时，将其删除。这样可以确保在启动容器时，应用程序始终具有相同的环境，无法更改。这样可确保环境在不同主机操作系统上的可重现性。无论是Ubuntu还是CentOS，环境都将始终相同。此外，使用Linux内核内置的机制将容器与主机隔离。容器中的应用程序看不到文件，主机和相邻容器的进程。应用程序与主机OS的这种隔离提供了额外的安全层。

有许多工具可用于管理主机上的容器。其中最受欢迎的是Docker。它使您可以确保容器的整个生命周期。但是，它仅在一台主机上工作。如果您需要管理多个主机上的容器，则Docker可以将工程师的生活变成地狱。这就是创建Kubernetes的原因。

对Kubernetes的需求正是由于能够将多个主机上的容器组作为某些单个实体进行引导。该系统的普及提供了构建DevOps或开发操作的能力，其中Kubernetes用于启动此DevOps本身的过程。



图1. Kubernetes的工作原理图

全自动化


原则上，DevOps是开发过程的自动化。粗略地说，开发人员编写的代码会注入存储库中。然后，可以将该代码立即自动收集到具有所有库的容器中，进行测试并将其推广到下一个阶段-登台，然后立即进行生产。

通过与Kubernetes一起使用，DevOps可以使该过程自动化，从而使开发人员很少或没有参与就可以进行。因此，由于开发人员不必在他的计算机上执行此操作，因此组装得到了显着加速-他只需要编写一段代码，将代码推送到存储库中，然后管道就会启动，其中可能包括组装，测试和展开过程。每次提交都会发生这种情况，因此测试正在进行中。

同时，使用容器可以确保该程序的整个环境完全按照其测试的形式投入生产。就是说，“在测试中，有一些版本在生产中-其他，但是在设置时-一切都下降了”这一类别将没有问题。从今天起，我们就趋向于微服务体系结构，当不是一个大型应用程序而是数百个小型应用程序时，为了手动管理它们，您将需要大量人员。这就是为什么我们使用Kubernetes。

优点，优点，优点


如果我们谈论Kubernetes作为平台的优势，那么它在管理微服务架构方面具有显着的优势。

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

Kubernetes最适合启动微服务架构。在古典架构中实现系统是可能的，但毫无意义。如果应用程序无法在多个副本中运行，那么区别在Kubernetes中还是没有？

开源Kubernetes


开源Kubernetes是一件好事：它已经安装并且可以工作。您可以在铁服务器上，基础结构上部署向导和工作程序，以便在其中运行所有应用程序。最重要的是-所有这些都是免费的。但是，有细微差别。

  • 首先是管理员和工程师的知识和经验的正确性，他们将部署和伴随所有这些。由于客户在群集中拥有完全的行动自由，因此他对群集的可操作性承担责任。打破这里的一切非常简单。
  • 第二是缺乏整合。如果在没有流行的虚拟化平台的情况下运行Kubernetes，您将无法获得该程序的所有好处。例如使用持久卷和负载平衡器服务。



图2. k8s架构

供应商的Kubernetes


与云提供商的集成提供了两种选择：

  • 首先，一个人可以简单地单击“创建集群”按钮，并获得一个已经配置并准备工作的集群。
  • 其次，供应商本身会建立集群并配置与云的集成。

我们这是怎么回事。启动集群的工程师会指示他需要多少工作人员以及具有哪些参数（例如，5个工作人员，每个工作人员具有10个CPU，16 GB的RAM和100 GB的磁盘）。然后，它可以访问已经形成的群集。同时，将启动负载的工作人员完全交给客户端，但是整个管理平面仍保留在供应商的责任范围内（如果根据托管服务模型提供服务）。

然而，这种方案具有其缺点。由于管理平面仍留在卖方手中，因此卖方无法完全访问客户端，这降低了使用Kubernetes的灵活性。有时会发生客户想要将某些特定功能附加到Kubernetes的情况，例如通过LDAP进行身份验证，并且管理平面配置不允许这样做。



图3.来自云提供商的Kubernetes集群示例

选择什么：开源或供应商


那么，开源的Kubernetes还是供应商？如果我们采用开源的Kubernetes，那么用户想做自己想做的事情。但是，这是一个向腿开枪的好机会。对于供应商，这会变得更加复杂，因为所有事情都需要为公司考虑和配置。开源Kubernetes的最大缺点是需要专家。对于供应商而言，公司可以免于此头疼，但它必须决定是否向专家或供应商付款。





好吧，优点很明显，缺点也很清楚。总是一回事：Kubernetes通过自动管理多个容器解决了许多问题。谁选择，开源还是供应商-每个人都可以自己决定。

本文由提供商#CloudMTS的Containerum服务的首席架构师Dmitry Krasnov编写。

More articles:


All Articles