用Operators管理多集群Kubernetes.docxVIP

用Operators管理多集群Kubernetes 2021-03-04 早在Kubernetes集群及其他云原生处理方案流行起来之前，我们Kubermatic就一直在挂念客户交付它们。我们挂念客户使用Ansible、Terraform及其他多种非云原生工具来构建集群;我们遇到这些工具的局限性时，挂念客户重建集群。 我们很早就明白了两点： （1）Kubernetes不是单一的大型集群处理方案，而是需要大量的较小集群。 （2）Kubernetes多集群管理需要为声明性、API驱动的世界构建的云原生工具。从那时起，这些想法已基本上被全球各地的众多组织所证明，包括云原生计算基金会、Twitter、《今日美国》、Zalando和阿里巴巴。 我们晓得每家大规模运转Kubernetes的公司都需要有效地管理多集群管理，于是开发了开源Kubermatic Kubernetes平台。本文将引见为什么您需要多集群管理，Kubermatic Kubernetes平台如何利用Kubernetes Operators跨多个集群、云和地区自动管理集群生命周期，以及如何马上开头使用它。 为什么需要多集群管理? Kubernetes缺少使用户、组织或操作人员能够允许不受信任的租户共享基础架构资源或分别软件不同部分的硬多租户(hard multitenancy)功能。这带来了平安和操作问题。 当操作人员试图按类型(敏感数据处理与非敏感数据处理)分别工作负载，或甚至只想分别生产环境与非生产环境时，就无法在集群级别上做到这一点，这带来了平安噩梦。在操作方面，试图将太多的应用程序部署到同一集群中可能会导致版本冲突、配置冲突以及软件生命周期管理问题。 最终，若没有适当的隔离机制，连锁反应式毛病的风险会添加。 在集群内没有硬多租户的情况下，必需使用单独的集群为不同平安要求的工作负载供应有效的隔离。有多个集群将应用程序部署到其中，还可以使操作人员将相像的应用程序部署在一起，同时将具有不同生命周期的应用程序彼此隔离。 部署到同一集群中的应用程序可以一起升级，以减轻操作负担，而需要不同版本、配置和依靠项的应用程序可以在单独的集群中运转，可以自行升级。 假如运转多个集群是满足这些工作负载和基础架构要求的独一处理方案，还必需考虑该模式的操作负担。假如手动完成，运转多个集群是一个巨大的操作挑战。因而，任何考虑大规模运转Kubernetes的操作人员应认真评估其多集群管理战略。我们Kubermatic选择用Kubernetes Operators进行多集群管理。 什么是Kubernetes Operator? Operator是一种软件，它了解如何运转并便于操作另一个软件。CoreOS(自Red Hat收购以来)于2021年引入了Kubernetes Operator，当时描述了这个概念： Operator是一种打包、部署和管理Kubernetes应用程序的方法。Kubernetes应用程序是既部署在Kubernetes上，又使用Kubernetes API和kubectl工具来管理的应用程序。Operator的自定义把握器监视特地为应用程序定义的自定义资源。 这使开发人员可以为需要维护形态的应用程序整理生命周期管理学问，从而使很多日常管理(包括部署、备份、升级、日志和警报)实现自动化。它只需通过监视大事并利用Kubernetes内置的和解循环(reconciliation loop)就能做到这一点。简而言之，细心创建的Operator担任处理容器化软件的整个生命周期。 我们如何使用Kubernetes Operators进行多集群管理? 借助Kubermatic Kubernetes平台，我们将Operators范式扩展到应用程序之外，以管理集群本身。是的，我们使用Kubernetes来操作Kubernetes。这种模式实际上已经被包括阿里巴巴在内的多家组织证明，阿里巴巴使用它来管理成千上万个集群。 从技术上讲，集群形态用“自定义资源定义”定义，然后存储在etcd中。一组把握器及其关联的和解循环监视集群形态的更改或添加，并依据需要进行更新。全部形态都存储在“主集群”中。 定义新的用户集群后，将创建把握平面(API、etcd、调度器和把握器)，作为主集群名称空间中的容器部署。用户集群的worker节点由计算机把握器部署，该把握器实施Cluster API，将声明性创建、配置和管理引入到worker节点。 Operators让Kubermatic不只可以使集群的创建实现自动化，还可以使集群的整个生命周期管理实现自动化。更新把握平面只需对容器部署进行滚动更新，而更新集群中的实际节点也可以以滚动方式声明性完成。 图1 利用Kubernetes Operators还可以在全部