🧰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
這對於一些並不複雜的專案來說完全夠用了,但元件一多就比較麻煩了。
這裡以 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 的 DeploymentAlertmanager
:用於定義Alertmanager
ScrapeConfig
:用於定會抓取規則
apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
name: static-config
namespace: my-namespace
labels:
prometheus: system-monitoring-prometheus
spec:
staticConfigs:
- labels:
job: prometheus
targets:
- 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: 2
vmstorage:
replicaCount: 2
storageDataPath: "/vm-data"
storage:
volumeClaimTemplate:
spec:
resources:
requests:
storage: "10Gi"
resources:
limits:
cpu: "1"
memory: "1Gi"
vmselect:
replicaCount: 2
cacheMountPath: "/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 原理
Operator 通常是執行在 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-order
namespace: test
spec:
env:
- name: OTEL_SERVICE_NAME
value: order
selector:
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
才能正常的回撥。
要使得 CRD 生效,我們還得先將 CRD 安裝進 kubernetes 叢集中,不過這些 operator-sdk 這類根據已經考慮周到了。
我們只需要定義好 CRD 的結構體:
然後使用 Makefile 中的工具 make bundle
就會自動將結構體轉換為 CRD。
參考連結:
- https://github.com/VictoriaMetrics/operator
- https://github.com/prometheus-operator/prometheus-operator