你好，我的名字是德米特里·克拉斯诺夫。 五年多来，我一直在管理 Kubernetes 集群并构建复杂的微服务架构。 今年年初，我们推出了基于Containerum管理Kubernetes集群的服务。 借此机会，我将告诉您 Kubernetes 是什么以及与供应商的集成与开源有何不同。
首先，什么是 。 这是一个用于管理大量主机上的容器的系统。 顺便说一句，它从希腊语被翻译为“飞行员”或“舵手”。 最初由 Google 开发，然后作为技术贡献捐赠给云原生计算基金会，这是一个国际非营利组织，汇集了世界领先的开发人员、最终用户和容器技术提供商。
管理大量容器
现在让我们弄清楚这些是什么类型的容器。 这是一个具有整个环境的应用程序 - 主要是程序所依赖的库。 所有这些都打包在档案中并以映像的形式呈现，无论操作系统如何，都可以运行、经过测试等。 但有一个问题——管理大量主机上的容器非常困难。 这就是创建 Kubernetes 的原因。
容器镜像代表一个应用程序及其依赖项。 应用程序、其依赖项和操作系统文件系统映像位于映像的不同部分，即所谓的层。 层可以重复用于不同的容器。 例如，公司中的所有应用程序可能都使用 Ubuntu 基础层。 运行容器时，无需在主机上存储单个基础层的多个副本。 这使您可以优化图像存储和交付。
当我们想要从容器运行应用程序时，必要的层会相互叠加并形成覆盖文件系统。 记录层放置在顶部，当容器停止时将其移除。 这确保了容器运行时，应用程序始终具有相同的环境，且无法更改。 这保证了不同主机操作系统上环境的再现性。 无论是Ubuntu还是CentOS，环境总是一样的。 此外，容器使用 Linux 内核内置的机制与主机隔离。 容器中的应用程序看不到主机和相邻容器的文件、进程。 应用程序与主机操作系统的这种隔离提供了额外的安全层。
有许多工具可用于管理主机上的容器。 其中最受欢迎的是 Docker。 它允许您提供容器的完整生命周期。 但是，它只能在一台主机上运行。 如果您需要跨多个主机管理容器，Docker 可能会让工程师们陷入地狱。 这就是创建 Kubernetes 的原因。
对 Kubernetes 的需求正是由于能够将多个主机上的容器组作为某种单一实体进行管理。 该系统的流行提供了构建 DevOps 或开发运营的机会，其中 Kubernetes 用于运行这种 DevOps 的流程。
图 1. Kubernetes 工作原理示意图
全自动化
DevOps 基本上是开发过程的自动化。 粗略地说，开发人员编写上传到存储库的代码。 然后，该代码可以立即自动收集到包含所有库的容器中，进行测试并“推出”到下一阶段 - 暂存，然后立即进入生产。
与 Kubernetes 一起，DevOps 允许您自动执行此过程，因此几乎无需开发人员本身参与即可完成该过程。 因此，构建速度显着加快，因为开发人员不必在自己的计算机上执行此操作 - 他只需编写一段代码，将代码推送到存储库，然后启动管道，其中可以包括进程构建、测试和推出。 每次提交都会发生这种情况，因此测试会持续进行。
同时，使用容器可以确保该程序的整个环境将以测试时的形式完全发布到生产环境中。 也就是说，不会出现“有一些版本在测试中，其他版本在生产中，但当我们安装它们时，一切都崩溃了”之类的问题。 由于今天我们有一种微服务架构的趋势，当不再是一个巨大的应用程序时，而是数百个小应用程序，为了手动管理它们，将需要大量的员工。 这就是我们使用 Kubernetes 的原因。
优点，优点，优点
如果我们谈论 Kubernetes 作为平台的优势，那么从管理微服务架构的角度来看，它具有显着的优势。
- 管理多个副本。 最重要的是跨多个主机管理容器。 更重要的是，将容器中的多个应用程序副本作为单个实体进行管理。 因此，工程师不必担心每个单独的容器。 如果其中一个容器崩溃，Kubernetes 将看到这一情况并重新启动它。
- 集群网络。 Kubernetes 还有一个所谓的集群网络，拥有自己的地址空间。 因此，每个 Pod 都有自己的地址。 subpod被理解为集群中直接启动容器的最小结构单元。 此外，Kubernetes 还具有结合负载均衡器和服务发现的功能。 这使您可以摆脱手动 IP 地址管理并将此任务委托给 Kubernetes。 自动运行状况检查将有助于检测问题并将流量重定向到工作 Pod。
- 配置管理。 当管理大量应用程序时，管理应用程序配置变得很困难。 为此，Kubernetes 有特殊的 ConfigMap 资源。 它们允许您集中存储配置并在运行应用程序时将它们公开给 pod。 这种机制使我们能够保证至少十个或一百个应用程序副本中配置的一致性。
- 持久卷。 容器本质上是不可变的，当容器停止时，写入文件系统的所有数据都将被销毁。 但有些应用程序直接将数据存储在磁盘上。 为了解决这个问题，Kubernetes 有一个磁盘存储管理功能——Persistent Volumes。 该机制使用外部存储来存储数据，并且可以将持久存储（块或文件）传输到容器中。 该解决方案允许您将数据与工作人员分开存储，这样可以在这些工作人员发生故障时保存数据。
- 负载均衡器。 尽管在 Kubernetes 中我们管理 Deployment、StatefulSet 等抽象实体，但最终容器还是在常规虚拟机或硬件服务器上运行。 它们并不完美，随时都有可能倒下。 Kubernetes 将看到这一点并将内部流量重定向到其他副本。 但是如何处理来自外部的流量呢？ 如果您只是将流量定向到其中一名工作人员，那么如果它崩溃，服务将变得不可用。 为了解决这个问题，Kubernetes 提供了负载均衡器等服务。 它们旨在为集群中的所有工作人员自动配置外部云平衡器。 该外部平衡器将外部流量引导至工作人员并自行监控其状态。 如果一名或多名工作人员无法工作，流量将被重定向到其他人。 这允许您使用 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 撰写
来源： habr.com