Den 3 on Eriks training corner

ConfigMapy a Secrety

Mon, 01 Jan 0001 00:00:00 +0000

ConfigMapy a Secrety

Konfigurace žije v prostředí, ne v image. Stejný image běží ve vývoji i v produkci – liší se jen ConfigMapa.

apiVersion: v1
kind: ConfigMap
metadata:
 name: app-cfg
data:
 DATACENTER: dc01
 app.properties: |
 color=blue

Dva způsoby spotřeby:

env: # 1 – jeden klíč jako proměnná
 - name: DATACENTER
 valueFrom:
 configMapKeyRef: { name: app-cfg, key: DATACENTER }

volumes: # 2 – celá ConfigMapa jako soubory
 - name: cfg
 configMap: { name: app-cfg }

Připojené soubory se aktualizují samy (zhruba do minuty, až kubelet synchronizuje). Proměnné prostředí ne – nastaví se jednou při startu kontejneru, takže pod se musí restartovat: kubectl rollout restart deploy/….

Perzistentní úložiště

Mon, 01 Jan 0001 00:00:00 +0000

Perzistentní úložiště

Zapisovatelná vrstva kontejneru umírá s kontejnerem a emptyDir s podem. Cokoli, co má přežít přeplánování, musí přijít zvenčí.

Tři objekty

graph LR PV[PersistentVolume skutečné úložiště cluster-scoped] --- B((vazba)) PVC[PersistentVolumeClaim požadavek na úložiště v namespace] --- B POD[Pod připojuje claim] --> PVC SC[StorageClass vytváří PV na požádání] -.volitelně.-> PV

PersistentVolume (PV) – kus úložiště, který existuje. Cluster-scoped.
PersistentVolumeClaim (PVC) – „potřebuji 1 GiB, ReadWriteOnce“. V namespace. Pod odkazuje na claim, nikdy na volume.
StorageClass – továrna, která PV vytváří automaticky (dynamické provisioning).

Tenhle cluster je dodaný bez StorageClass a bez CSI driveru, takže se zpočátku nic nevytvoří samo: PV napíšete vy a ukážete jím na jeden z NFS exportů na support01 (/storage1, /storage2, /storage3). Přesně takhle vypadá on-premise realita, kterou cloud skrývá – a druhá polovina labu 18 to napraví instalací driveru.

StatefulSets

Mon, 01 Jan 0001 00:00:00 +0000

StatefulSets

Deployment bere pody jako zaměnitelné: náhodná jména, náhodné pořadí startu, jedna společná Service. Databáze a clustery potřebují pravý opak.

graph TB SS[StatefulSet db] --> P0[db-0 PVC data-db-0] SS --> P1[db-1 PVC data-db-1] SS --> P2[db-2 PVC data-db-2] H[Headless Service db clusterIP: None] -.-> P0 H -.-> P1 H -.-> P2

Co dostanete navíc oproti Deploymentu:

Vlastnost	Význam
Stabilní identita	pody jsou `db-0`, `db-1`, `db-2` – jméno přežije restart
Stabilní síťové jméno	`db-0.db.default.svc.cluster.local` přes headless Service
Vlastní úložiště	`volumeClaimTemplates` vytvoří jeden PVC na každý pod a nechá ho
Řízené pořadí	start 0,1,2; ukončení 2,1,0; rolling update v opačném pořadí

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: web-headless  # headless Service, povinné
 replicas: 3
 selector:
 matchLabels: { app: web }
 template:
 metadata:
 labels: { app: web }
 spec:
 containers:
 - name: web
 image: nginx:1.27
 volumeMounts:
 - name: data
 mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: "" # dynamické provisioning tu není
 resources:
 requests:
 storage: 1Gi

Bez StorageClass v tomhle clusteru zůstane volumeClaimTemplates v Pending, dokud nebude existovat odpovídající PV pro každou repliku – tři repliky potřebují tři PV. Právě proto lab nejdřív vytvoří /storage1..3 jako tři PV.

Základy Helmu

Mon, 01 Jan 0001 00:00:00 +0000

Základy Helmu

Skutečná aplikace je tucet manifestů, které je potřeba nasadit ve správném pořadí a s odpovídajícími hodnotami. Helm je zabalí.

Pojem	Význam
Chart	balíček – šablony plus výchozí hodnoty. Obdoba RPM nebo DEB
Repozitář	web server s charty; veřejné indexuje Artifact Hub
Release	jedna instalace chartu v clusteru, s unikátním jménem
Revize	jedna verze release; každý upgrade přidá další

graph LR R[(Repozitář)] --> CH[Chart + values.yaml] V[vaše -f values.yaml / --set] --> H[helm] CH --> H H -->|vyrenderuje šablony| M[Kubernetes manifesty] M --> K[Cluster: release revize N]

Jeden chart, mnoho release: nainstalujte stejný chart třikrát pod třemi jmény a dostanete tři nezávislé instance.

Helm charty

Mon, 01 Jan 0001 00:00:00 +0000

Psaní vlastního chartu

helm create myapp

myapp/
Chart.yaml # metadata: name, version, appVersion (povinné)
values.yaml # výchozí hodnoty (povinné)
charts/ # závislé charty
crds/ # CRD, instalují se jako první
templates/ # manifesty ve formě Go šablon
_helpers.tpl # znovupoužitelná makra

version je verze chartu (SemVer 2, promítne se do myapp-0.1.0.tgz), appVersion je verze software uvnitř.

Šablony

Jmenný prostor	Zdroj
`.Values`	`values.yaml`, přebito přes `-f` a `--set`
`.Chart`	`Chart.yaml`
`.Release`	`.Release.Name`, `.Namespace`, `.Revision` – vzniká při instalaci

metadata:
 name: {{ include "myapp.fullname" . }}
spec:
 replicas: {{ .Values.replicaCount }}
 template:
 spec:
 containers:
 - name: {{ .Chart.Name }}
 image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

Užitečné: default, quote, required "zpráva" .Values.x, {{- … -}} pro ořezání bílých znaků, {{ if }} / {{ range }} a include pro makra.

CRD a operátory

Mon, 01 Jan 0001 00:00:00 +0000

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í.