CRD a operátory
CRD a operátory
Custom Resource Definitions
CRD naučí API server nový druh objektu. Jakmile ho nasadíte, kubectl get,
describe, explain, RBAC a všechno ostatní na něm funguje úplně stejně jako
na podech – pro API server v tom není rozdíl.
kubectl get crd
kubectl api-resources | grep -v -E 'v1$|apps/v1' # co není jádro Kubernetes
kubectl explain cluster.spec # funguje i na CRD
Samotné CRD jen ukládá data a nic s nimi nedělá. Je to tabulka s validací.
Operátor = CRD + kontroler
Operátor je CRD plus pod s kontrolerem, který běží ve stejné reconciliation smyčce jako vestavěné objekty – jen jeho doménová znalost je o vaší aplikaci.
Přestanete psát „StatefulSet se třemi replikami, headless Service, Secret
s heslem, init job spouštějící initdb a CronJob na zálohy“. Napíšete:
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pgtest
spec:
instances: 3
storage:
size: 1Gi
Operátor to všechno vytvoří – a na rozdíl od Helm chartu to dál obsluhuje: při pádu primárního uzlu povýší repliku, starý primár zase připojí, rotuje přihlašovací údaje a spouští zálohy. Helm instaluje; operátor provozuje.
Co používá lab
CloudNativePG – operátor pro PostgreSQL. Jeho CRD
zahrnují Cluster, Backup a ScheduledBackup. Operátor nainstalujete Helmem,
vytvoříte Cluster, uvidíte, jak z něj vznikne sada podů s PVC, a pak smažete
primární pod a budete sledovat failover, který proběhne bez vás.
Odkud operátory brát
OperatorHub.io a Artifact Hub. Většina se instaluje
Helm chartem nebo jedním manifestem a většina má stejný tvar: namespace
*-system, Deployment s kontrolerem, sada CRD a RBAC.
Než nějaký nasadíte, posuďte ho: kdo ho udržuje, řeší upgrady a zálohy, a co se stane s daty, když operátor smažete (obvykle nic – CR a PVC přežijí, jen je nikdo nereconciluje).