Pod & Wahl der Workload-Resource
Deployment: stateless, rolling, austauschbare
Replicas. StatefulSet: ordinale Namen
(web-0…N), stabile Netz-IDs, geordneter
Start/Stop, eigene PVCs.
DaemonSet: ein Pod je Node (CNI, Log-Shipper,
Node-Exporter). Job / CronJob:
einmalig/periodisch, completions +
parallelism, backoffLimit.
Sidecar: initContainers[] mit
restartPolicy: Always (GA 1.33), startet vor der App,
endet nach ihr, blockiert Job-Ende nicht. Pod direkt
nur für Debug.
Deployment: Rolling Update
strategy.rollingUpdate.maxUnavailable +
maxSurge steuern Tempo. Default 25 % / 25 %.
Für Singletons: strategy.type: Recreate. Pause:
kubectl rollout pause, dann mehrere Patches, dann
resume.
apiVersion: apps/v1
kind: Deployment
metadata: {name: api}
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate: {maxUnavailable: 0, maxSurge: 1}
selector: {matchLabels: {app: api}}
template:
metadata: {labels: {app: api}}
spec:
containers:
- name: api
image: ghcr.io/acme/api:1.4.2
resources:
requests: {cpu: 100m, memory: 128Mi}
limits: {memory: 256Mi}
readinessProbe:
httpGet: {path: /readyz, port: 8080}
periodSeconds: 5
StatefulSet: Eigenheiten
serviceName = Headless-Service
(clusterIP: None), DNS pro Pod:
web-0.<svc>.<ns>.svc.cluster.local.
volumeClaimTemplates legt PVC pro Replica an, per Default
bleibt es auch bei Scale-down und Löschen;
persistentVolumeClaimRetentionPolicy
(whenDeleted/whenScaled:
Retain | Delete, GA 1.32).
podManagementPolicy: Parallel bricht Ordnung auf,
schneller bei zustandslosen Workloads, die StatefulSet nur wegen
stabiler DNS brauchen.
updateStrategy.rollingUpdate.maxUnavailable (Beta, seit
1.37 per Default an) rollt mehrere Replicas gleichzeitig, bei
OrderedReady erst, wenn das Set voll hochskaliert ist.
Job-Pattern
completions: N, parallelism: M, N Tasks,
M parallel. activeDeadlineSeconds hartes Timeout
(Pod-Kill). ttlSecondsAfterFinished, Aufräumen
ohne Cron.
CronJob concurrencyPolicy:
Forbid | Replace | Allow,
startingDeadlineSeconds gegen Backlog nach
Cluster-Pause. timeZone: Europe/Berlin (GA 1.27), sonst
gilt die Zeitzone des kube-controller-managers.