最近一个朋友问我关于EKS的升级问题:
场景:
如果我有 100 个 EKS 集群需要升级,那么所有集群都安装了安全插件。由于我不想在升级后手动在每个EKS中重复安装此插件,如何实现EKS升级后自动安装这个安全插件?
答案有多种方法,AWS CLI , shell command。这些方法都可以实现此任务,但是它们并没有充分发挥kubernetes的优势,我们可不可以通过Kubernetes Operator来实现此任务?回答此问题之前,我们先回顾一下它的定义。
什么是 Kubernetes Operator?
Operator 概念由 CoreOS Linux(后来的 Container Linux)开发团队于 2016 年提出。
Kubernetes 项目对“Operator”的定义很简单:“Operator 是使用自定义资源来管理应用程序及其组件的软件扩展”。换句话说,使用 Operator 使我们能够将应用程序视为一个单一对象,该对象仅公开对应用程序有意义的调整,而不是一组原语(例如 Pod、Deployment、Service 或 ConfigMap)。
此外,Operator 实际上允许在 Kubernetes 集群中运行的软件自动执行典型的初始任务(安装、配置等)和后续任务(重新配置、升级、备份、故障转移、恢复等),并与 Kubernetes 概念和 API 原生集成。
这就是为什么它们被称为“原生 Kubernetes 应用程序”,并且这个定义也可以从另一个更具操作性的角度来看待。 K8s Operator 是用于在 Kubernetes 上打包、管理和部署应用程序的控制器。为了实现这些功能,Operator 使用自定义资源 (CR),通过自定义资源定义 (CRD) 定义特定应用程序所需的配置和状态。
Operator 的作用是使用控制循环将应用程序的实际状态与 CRD 所需的状态进行协调,从而自动扩展、更新或重启应用程序。实际上,Kubernetes 提供了一些基本命令和原语,Operator 可以使用它们来定义更复杂的操作。
最终,Operator 是运行在集群中并通过 Kubernetes API 交互的实际程序,用于自动执行比 Kubernetes 原生处理的功能更复杂的功能。
Operator 非常有用,因为它们是特定于应用程序的控制器,可以扩展 Kubernetes API 的功能。换句话说,Operator 教会了 Kubernetes 一些新技巧。但它们具体有哪些好处呢?让我们来看看它们的主要优势。
- Operator 使得 Kubernetes 的功能不仅仅限于无状态应用程序,还可以扩展到有状态应用程序。仅凭这一点就足以说明它的重要性,因为有状态的云应用程序和服务的管理比无状态应用程序复杂得多。一些有状态的 Operator 包括:用于监控解决方案的 Prometheus Operator 和用于管理高可用性 PostgreSQL 数据库集群的 Postgres Operator。
- Operator 标准化了手动操作,并创建了通用且一致的自动化方法。
- Operator 可以轻松地从一个环境迁移到另一个环境,从一个项目迁移到另一个项目。这使得一个包含更多通用 Operator 的生态系统得以形成,这些 Operator 可以下载、配置并用于不同的项目,而无需内部开发。
Kubernetes Operator 示例
Operator 模式已被广泛采用。许多流行的开源项目都提供了官方或社区主导的 Operator,这使得在您的堆栈中部署常用的软件组件变得更加容易。让我们来看看另外三个更突出的示例。
Postgres Operator
例如,Postgres Operator 允许您应用以下清单来启动一个 Postgres 部署,该部署包含 1 Gi 的持久存储、自动服务发现和预配置的数据库用户帐户:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: postgres-cluster
spec:
volume:
size: 1Gi
numberOfInstances: 3
users:
demo-user:
- superuser
- createdb
databases:
demo-user: demo-db
postgresql:
version: "15"
Operator 会在部署中创建 StatefulSet、Service 和 Volume,但人工管理员无需了解这些细节。他们只需提供相关参数来配置 Postgres 实例即可。
MySQL Operator
MySQL Operator for Kubernetes 是用于在 Kubernetes 中部署 MySQL 的官方解决方案。与上面显示的 Postgres Operator 类似,它允许您通过向集群添加 InnoDBCluster 对象来配置新的 MySQL 数据库实例。
Operator 通过创建适当的 Kubernetes 对象(例如 StatefulSet 和服务)自动管理数据持久化、网络发现和流量路由。它旨在适应整个数据库生命周期,包括未来的 MySQL 升级和到外部对象存储系统的计划备份。
安装 Operator 后,您可以通过将三行 YAML 清单应用于集群来部署新的 MySQL 实例:
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
name: demo-db
spec:
secretName: mysql-creds
tlsUseSelfSigned: true
instances: 3
router:
instances: 1
在使用此示例之前,您应该按照文档中的指导使用数据库用户名和密码创建 mysql-creds 密钥。
datadog operator
kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
name: datadog
spec:
global:
site: us5.datadoghq.com
credentials:
apiSecret:
secretName: datadog-secret
keyName: api-key
appSecret:
secretName: datadog-secret
keyName: app-key
override:
clusterAgent:
image:
name: gcr.io/datadoghq/cluster-agent:latest
nodeAgent:
image:
name: gcr.io/datadoghq/agent:latest
在使用此示例之前,您应该按照文档中的指导使用api-key和app-key创建 datadog-secret密钥。
Kubernetes Operator:一些示例
目前,有两个官方应用程序可以轻松搜索现有的 Operator:
Artifact HUB – 我们在这里可以找到 Operator 和 Helm Chart(CNCF 项目)
Operator Hub – 专为 Operator 打造(Redhat 项目)
Operator 使我们能够找到各种不同问题的解决方案。我们不会列出所有 Operator,而是从一些需要解决的情况开始,并给出一些示例。
您想监控您的集群吗?
kube-prometheus 技术栈为您提供了一个高效的 Kubernetes 集群端到端监控解决方案。它包含 Kubernetes 清单、Grafana 仪表板、Prometheus 规则以及文档和脚本,并利用 Prometheus Operator 提供用户友好的监控体验。
您想自动化 TLS 证书管理吗?
在这种情况下,我们可以使用 Kubernetes Cert-manager Operator,它允许我们获取由集群中配置的一系列证书颁发机构颁发的 SSL 证书。此解决方案允许我们动态地从每个颁发机构请求新证书,并在服务生命周期中自动使用它们。
您想自动化基于 ISTIO 的服务网格管理吗?
使用 Istio Operator,我们可以自动安装、更新和排查 Istio 冲突。此 Operator 的先决条件很少(实际上只需要 istioctl),并且允许安装和验证所有 API。
当在 DevOps 和 SRE 场景中使用时,此 Operator 可以从一开始就自动化 Kubernetes 集群中使用的微服务的网格管理:管理、编排、安全、通信和监控。之后,可以以非侵入式的方式完善此初始实现。
在公有云上自动创建资源
Crossplane 是一个 Kubernetes Operator,它通过将由 crossplane 提供商提供的一组 CRD 映射到特定供应商提供的云服务,从而可以使用 Kubernetes 声明式语法创建和管理云资源。它旨在供应用程序团队使用,无需编写任何代码即可使用。它的主要功能是自动在公有云上创建资源。
该项目是 CNFC 的一部分,正如其作者所解释的那样:“我们创建 Crossplane 是为了帮助组织像云提供商那样创建自己的云:使用控制平面。”
如何在我们的集群中管理 Elastic Cloud
Elastic Kubernetes Operator(由 Elastic 项目正式实现)能够实现 Elastic Search 和 Kibana 在 Kubernetes 上的自动化,并大大简化部署配置并简化管理。该操作员支持更大存储的 Frozen Indices 和 Kibana Spaces、Canvas 和 Elastic Maps,以及 Kubernetes 基础设施的监控部分。
结论
正如我们所说,到目前为止我们所看到的 Operator 只是几个例子。还有很多其他的 Operator:从 KNative 到 Kubernetes 上的 Cloud Foundry,再到 Azure Spring Cloud。当然,还有许多其他最流行的服务和应用程序类型的 Operator:Grafana、Jaeger、ArgoCD、MongoDB 和 RBAC(基于角色的访问控制模型)。
尽管所有这些案例都大相径庭,但相同的原则始终适用。Operator 的优势在于扩展了 Kubernetes 的自动化可能性。广泛的 K8s Operator 生态系统使得我们能够为大多数用途找到现成的解决方案。
回到最初的问题,我们也可以通过创建一个operator来自动安装安全插件。