|
|
|
|
公众号矩阵

用Operators管理多集群Kubernetes

早在Kubernetes集群及其他云原生解决方案流行起来之前,我们Kubermatic就一直在帮助客户交付它们。我们帮助客户使用Ansible、Terraform及其他多种非云原生工具来构建集群;我们遇到这些工具的局限性时,帮助客户重建集群。

作者:布加迪编译来源:51CTO|2021-02-07 08:00

【51CTO.com快译】早在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收购以来)于2016年引入了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还可以在所有基础架构提供商之间提供一致的抽象。无需为每家提供商重新发明轮子,而是可以将同一套工具从一家提供商轻松移植到下一家提供商(包括混合云和多云),以及集成本地基础架构(虚拟化和裸机)。

图2

Operators让我们的用户可以做什么?

开发一种优雅的方案以解决棘手的技术问题是个令人兴奋的过程,也是一次学习机会,但最令人欣慰的是看到它每天给我们的用户带来的影响。作为帮助用户踏上云原生之旅的合作伙伴,我们很乐意看到自己的软件发挥其价值。

SysEleven是柏林的一家托管服务提供商,也是我们的第一个生产级用户。该公司的工程师希望能够向其客户提供Kubernetes即服务,但他们无法通过人员扩展运营规模。于是他们选择了Kubermatic Kubernetes平台改而通过软件进行扩展,用于生产环境至今已有近三年。由于Kubermatic Kubernetes平台背后的Kubernetes Operators可以自动执行许多操作任务(包括典型的“关闭并重新开启”操作),因此他们仅用一名专职员工就可以运行和管理数百个集群。这使他们的Kubernetes团队可以专注于客户需求,并交付赖以成名的高质量服务。

除了云原生之旅外,Operators还让我们可以将久经考验的原则和流程适应于边缘。在不久的将来,我们将提供体现上面所探讨原则的边缘功能。

原文标题:Manage Multicluster Kubernetes with Operators,作者:Sascha Haase

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

【编辑推荐】

  1. MySQL MGR组复制技术集群高可用实战视频教程
  2. 如何从0到1构建一个稳定、高性能的Redis集群?(附16张图解)
  3. 聊聊什么是云原生?
  4. 三种Kubernetes资源类型的使用指南
  5. MyCAT集群在线扩容的场景小结
【责任编辑:华轩 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

5人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

31人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

217人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微