当前位置： 首页 > news >正文

从Helm到 Operator：Kubernetes应用管理的进化

news 来源：原创 2024/9/20 13:47:09

🧰Helm 的作用

在开始前需要先对 kubernetes  Operator 有个简单的认识。

以为我们在编写部署一些简单 Deployment 的时候只需要自己编写一个 yaml 文件然后 kubectl apply 即可。

apiVersion: apps/v1  
kind: Deployment  
metadata:  labels:  app: k8s-combat  name: k8s-combat  
spec:  replicas: 1  selector:  matchLabels:  app: k8s-combat  template:  metadata:  labels:  app: k8s-combat  spec:  containers:  - name: k8s-combat  image: crossoverjie/k8s-combat:v1  imagePullPolicy: Always  resources:  limits:  cpu: "1"  memory: 300Mi  requests:  cpu: "0.1"  memory: 30Mi
kubectl apply -f deployment.yaml

这对于一些并不复杂的项目来说完全够用了，但组件一多就比较麻烦了。

1cdd7d815f216c0223308038cebbd62d.png这里以 Apache Pulsar 为例：它的核心组件有:

  • Broker

  • Proxy

  • Zookeeper

  • Bookkeeper

  • Prometheus(可选)

  • Grafana(可选) 等组件，每个组件的启动还有这依赖关系。

必须需要等 Zookeeper 和 Bookkeeper 启动之后才能将流量放进来。

此时如何还继续使用 yaml 文件一个个部署就会非常繁琐，好在社区有提供 Helm 一键安装程序，使用它我们只需要在一个同意的 yaml 里简单的配置一些组件，配置就可以由 helm 来部署整个复杂的 Pulsar 系统。

components:  # zookeeper  zookeeper: true  # bookkeeper  bookkeeper: true  # bookkeeper - autorecovery  autorecovery: true  # broker  broker: true  # functions  functions: false  # proxy  proxy: true  # toolset  toolset: true  # pulsar manager  pulsar_manager: false  
monitoring:  # monitoring - prometheus  prometheus: true  # monitoring - grafana  grafana: true  # monitoring - node_exporter  node_exporter: true  # alerting - alert-manager  alert_manager: false

比如在 helm 的 yaml 中我们可以选择使用哪些 components，以及是否启用监控组件。

最后直接使用这个文件进行安装：

helm install pulsar apache/pulsar \--values charts/pulsar/values.yaml \--set namespace=pulsar \--set initialize=true

它就会自动生成各个组件的 yaml 文件，然后统一执行。

所以 helm 的本质上和 kubectl apply yaml 一样的，只是我们在定义 value.yaml 时帮我们处理了许多不需要用户低频修改的参数。

我们可以使用 helm 将要执行的 yaml 输出后人工审核

helm install pulsar apache/pulsar --dry-run --debug > debug.yaml

🤔Operator 是什么

💔Helm 的痛点

Helm 虽然可以帮我们部署或者升级一个大型应用，但他却没法帮我们运维这个应用。

举个例子：比如我希望当 Pulsar Broker 的流量或者内存达到某个阈值后就指定扩容 Broker，闲时再自动回收。

或者某个 Bookkeeper 的磁盘使用率达到阈值后可以自动扩容磁盘，这些仅仅使用 Helm 时都是无法实现的。

以上这些需求我们目前也是通过监控系统发出报警，然后再由人工处理。

其中最大的痛点就是进行升级：

  • 升级ZK

  • 关闭auto recovery

  • 升级Bookkeeper

  • 升级Broker

  • 升级Proxy

  • 开启auto recovery

因为每次升级是有先后顺序的，需要依次观察每个组件运行是否正常才能往后操作。

如果有 Operator 理性情况下下我们只需要更新一下镜像版本，它就可以自动执行以上的所有步骤最后将集群升级完毕。

所以相对于 Helm 来说 Operator 是可以站在一个更高的视角俯视整个应用系统，它能发现系统哪个地方需要它从而直接修复。

💎CRD(Custom Resource Definitions)

而提到 Operator 那就不得不提到 CRD(Custom Resource Definitions)翻译过来就是自定义资源。

这是 kubernetes 提供的一个 API 扩展机制，类似于内置的 Deployment/StatefulSet/Services 资源，CRD 是一种自定义的资源。

这里以我们常用的 prometheus-operator 和 VictoriaMetrics-operator 为例：

Prometheus：

  • **Prometheus**：用于定义 Prometheus 的 Deployment

  • **Alertmanager**：用于定义 Alertmanager

  • **ScrapeConfig**：用于定会抓取规则

apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:name: static-confignamespace: my-namespacelabels:prometheus: system-monitoring-prometheus
spec:staticConfigs:- labels:job: prometheustargets:- prometheus.demo.do.prometheus.io:9090

使用时的一个很大区别就是资源的 kind: ScrapeConfig 为自定义的类型。

VictoriaMetrics 的 CRD：

  • VMPodScrape：Pod 的抓取规则

  • VMCluster：配置 VM 集群

  • VMAlert：配置 VM 的告警规则

  • 等等

# vmcluster.yaml
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMCluster
metadata:name: demo
spec:retentionPeriod: "1"replicationFactor: 2vmstorage:replicaCount: 2storageDataPath: "/vm-data"storage:volumeClaimTemplate:spec:resources:requests:storage: "10Gi"resources:limits:cpu: "1"memory: "1Gi"vmselect:replicaCount: 2cacheMountPath: "/select-cache"storage:volumeClaimTemplate:spec:resources:requests:storage: "1Gi"resources:limits:cpu: "1"memory: "1Gi"requests:cpu: "0.5"memory: "500Mi"vminsert:replicaCount: 2

以上是用于创建一个 VM 集群的 CRD 资源，应用之后就会自动创建一个集群。

Operator 原理

78ddb8ade8e195145eb54915aef8ddc0.pngOperator 通常是运行在 kubernetes API server 的 webhook 之上，简单来说就是在一些内置资源的关键节点 API-server 会调用我们注册的一个 webhook，在这个 webhook 中我们根据我们的 CRD 做一些自定义的操作。

理论上我们可以使用任何语言都可以写 Operator，只需要能处理 api-server 的回调即可。

只是 Go 语言有很多成熟的工具，比如常用的 kubebuilder 和 operator-sdk.

他们内置了许多命令行工具，可以帮我们节省需要工作量。

这里以 operator-sdk 为例：

$ operator-sdk create webhook --group cache --version v1alpha1 --kind Memcached --defaulting --programmatic-validation

会直接帮我们创建好一个标准的 operator 项目:

├── Dockerfile
├── Makefile
├── PROJECT
├── api
│   └── v1alpha1
│       ├── memcached_webhook.go
│       ├── webhook_suite_test.go
├── config
│   ├── certmanager
│   │   ├── certificate.yaml
│   │   ├── kustomization.yaml
│   │   └── kustomizeconfig.yaml
│   ├── default
│   │   ├── manager_webhook_patch.yaml
│   │   └── webhookcainjection_patch.yaml
│   └── webhook
│       ├── kustomization.yaml
│       ├── kustomizeconfig.yaml
│       └── service.yaml
├── go.mod
├── go.sum
└── main.go

其中 Makefile 中包含了开发过程中常用的工具链（包括根据声明的结构体自动生成 CRD 资源、部署k8s 环境测试等等）、Dockerfile 等等。

这样我们就只需要专注于开发业务逻辑即可。

因为我前段时间给 https://github.com/open-telemetry/opentelemetry-operator 贡献过两个 feature，所以就以这个 Operator 为例：

它有一个 CRD: kind: Instrumentation，在这个 CRD 中可以将 OpenTelemetry 的 agent 注入到应用中。

apiVersion: opentelemetry.io/v1alpha1  
kind: Instrumentation  
metadata:  name: instrumentation-test-ordernamespace: test  
spec:  env:  - name: OTEL_SERVICE_NAME  value: orderselector:  matchLabels:  app: order  java:  image: autoinstrumentation-java:2.4.0-release  extensions:  - image: autoinstrumentation-java:2.4.0-release  dir: /extensions  env:  - name: OTEL_RESOURCE_ATTRIBUTES  value: service.name=order  - name: OTEL_INSTRUMENTATION_MESSAGING_EXPERIMENTAL_RECEIVE_TELEMETRY_ENABLED  value: "true"  - name: OTEL_TRACES_EXPORTER  value: otlp  - name: OTEL_METRICS_EXPORTER  value: otlp  - name: OTEL_LOGS_EXPORTER  value: none  - name: OTEL_EXPORTER_OTLP_ENDPOINT  value: http://open-telemetry-opentelemetry-collector.otel.svc.cluster.local:4317  - name: OTEL_EXPORTER_OTLP_COMPRESSION  value: gzip  - name: OTEL_EXPERIMENTAL_EXPORTER_OTLP_RETRY_ENABLED  value: "true"

它的运行规则是当我们的 Pod 在启动过程中会判断 Pod 的注解中是否开启了注入 OpenTelemetry 的配置。

如果开启则会将我们在 CRD 中自定义的镜像里的 javaagent 复制到业务容器中，同时会将下面的那些环境变量也一起加入的业务容器中。

要达到这样的效果就需要我们注册一个回调 endpoint。

mgr.GetWebhookServer().Register("/mutate-v1-pod", &webhook.Admission{  Handler: podmutation.NewWebhookHandler(cfg, ctrl.Log.WithName("pod-webhook"), decoder, mgr.GetClient(),  []podmutation.PodMutator{  sidecar.NewMutator(logger, cfg, mgr.GetClient()),  instrumentation.NewMutator(logger, mgr.GetClient(), mgr.GetEventRecorderFor("opentelemetry-operator"), cfg),  }),})

当 Pod 创建或有新的变更请求时就会回调我们的接口。

func (pm *instPodMutator) Mutate(ctx context.Context, ns corev1.Namespace, pod corev1.Pod) (corev1.Pod, error) {  logger := pm.Logger.WithValues("namespace", pod.Namespace, "name", pod.Name)}

在这个接口中我们就可以拿到 Pod 的信息，然后再获取 CRD Instrumentation 做我们的业务逻辑。

var otelInsts v1alpha1.InstrumentationList  
if err := pm.Client.List(ctx, &otelInsts, client.InNamespace(ns.Name)); err != nil {  return nil, err  
}// 从 CRD 中将数据复制到业务容器中。
pod.Spec.InitContainers = append(pod.Spec.InitContainers, corev1.Container{Name:      javaInitContainerName,Image:     javaSpec.Image,Command:   []string{"cp", "/javaagent.jar", javaInstrMountPath + "/javaagent.jar"},Resources: javaSpec.Resources,VolumeMounts: []corev1.VolumeMount{{Name:      javaVolumeName,MountPath: javaInstrMountPath,}},
})for i, extension := range javaSpec.Extensions {pod.Spec.InitContainers = append(pod.Spec.InitContainers, corev1.Container{Name:      initContainerName + fmt.Sprintf("-extension-%d", i),Image:     extension.Image,Command:   []string{"cp", "-r", extension.Dir + "/.", javaInstrMountPath + "/extensions"},Resources: javaSpec.Resources,VolumeMounts: []corev1.VolumeMount{{Name:      javaVolumeName,MountPath: javaInstrMountPath,}},})
}

不过需要注意的是想要在测试环境中测试 operator 是需要安装一个 cert-manage，这样 webhook 才能正常的回调。

009ba0d3f35f11e361efc7a9bd0b8551.png要使得 CRD 生效，我们还得先将 CRD 安装进 kubernetes 集群中，不过这些 operator-sdk 这类根据已经考虑周到了。

我们只需要定义好 CRD 的结构体：b39292b1a0405ed1763b1ffbc8d34f4b.png

然后使用 Makefile 中的工具 make bundle 就会自动将结构体转换为 CRD。

参考链接：

  • https://github.com/VictoriaMetrics/operator

  • https://github.com/prometheus-operator/prometheus-operator

    往期推荐

    如何找到并快速上手一个开源项目

    OpenTelemetry 深度定制：跨服务追踪的实战技巧

    从 Prometheus 到 OpenTelemetry: 指标监控的演进与实践

    从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅

    实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术

    ab8c94efd5579def0dba183d4ba2f9c4.gif

    点分享

    9b785d96af38ff71a2611c38331dd390.gif

    点收藏

    fb8ca8057dc45a8bdd311d75971abaae.gif

    点点赞

    5147ebc5cc405c49bb6638c7c0d7a4c8.gif

    点在看

相关文章：

  • 北京网站建设多少钱？
  • 辽宁网页制作哪家好_网站建设
  • 高端品牌网站建设_汉中网站制作
  • 二叉苹果树
  • 如何用Vue3和Plotly.js创建交互式表格？
  • 【亲测有效】Linux/Ubuntu远程服务器使用plt.show()没有反应，vscode ssh 远程ubuntu，plt.show不显示图片问题
  • 泰勒公式中拉格朗日余项和佩亚诺余项的区别及具体的应用场景案例
  • Vue3 根据相对路径加载vue组件
  • PostgreSQL 中如何处理数据的并发更新冲突解决？
  • Git 操作总结
  • 移动应用：商城购物类，是最常见的，想出彩或许就差灵犀一指
  • 插入排序算法（C语言版）
  • HTML5使用＜progress＞进度条、＜meter＞刻度条
  • 如何用 Python 绕过 cloudflare（5秒盾） 抓取数据：也不是很难嘛！
  • 红日靶场----（三）漏洞利用
  • Mac平台虚拟机 Parallels Desktop v19.4.1，支持M1/M2/M3芯片组
  • LVS-DR负载均衡
  • gpt-4o看图说话-根据图片回答问题
  • Angular 2 DI - IoC DI - 1
  • Github访问慢解决办法
  • java概述
  • oschina
  • Python代码面试必读 - Data Structures and Algorithms in Python
  • Redis提升并发能力 | 从0开始构建SpringCloud微服务(2)
  • springboot_database项目介绍
  • 大型网站性能监测、分析与优化常见问题QA
  • 关于 Linux 进程的 UID、EUID、GID 和 EGID
  • 利用DataURL技术在网页上显示图片
  • 如何在 Tornado 中实现 Middleware
  • 我的面试准备过程--容器(更新中)
  • 验证码识别技术——15分钟带你突破各种复杂不定长验证码
  • 用Visual Studio开发以太坊智能合约
  • 字符串匹配基础上
  • 资深实践篇 | 基于Kubernetes 1.61的Kubernetes Scheduler 调度详解 ...
  • # MySQL server 层和存储引擎层是怎么交互数据的？
  • ## 基础知识
  • #《AI中文版》V3 第 1 章 概述
  • #php的pecl工具#
  • （9）YOLO-Pose:使用对象关键点相似性损失增强多人姿态估计的增强版YOLO
  • (done) ROC曲线 和 AUC值 分别是什么？
  • （Matalb回归预测）PSO-BP粒子群算法优化BP神经网络的多维回归预测
  • (Matlab)基于蝙蝠算法实现电力系统经济调度
  • （STM32笔记）九、RCC时钟树与时钟 第一部分
  • （附源码）springboot电竞专题网站 毕业设计 641314
  • （论文阅读11/100）Fast R-CNN
  • （南京观海微电子）——I3C协议介绍
  • （十八）三元表达式和列表解析
  • （四）图像的%2线性拉伸
  • （一）Dubbo快速入门、介绍、使用
  • (译) 函数式 JS #1：简介
  • (源码版)2024美国大学生数学建模E题财产保险的可持续模型详解思路+具体代码季节性时序预测SARIMA天气预测建模
  • ..回顾17，展望18
  • .NET 编写一个可以异步等待循环中任何一个部分的 Awaiter
  • .NET值类型变量“活”在哪？
  • /usr/bin/env: node: No such file or directory
  • @在php中起什么作用？
  • [] 与 [[]], -gt 与 ＞ 的比较
  • [ASP]青辰网络考试管理系统NES X3.5