Technologie und Infrastruktur → Kubernetes-Cluster und Helm-Charts

Kubernetes-Cluster und Helm-Charts

1) Die Rolle von Kubernetes und Helm

Kubernetes ist das Rückgrat der Anwendungsplattform: Standardisiert Rolling, Network, Configs, Secrets und Selbstheilung. Helm ist ein Paket-/Template-Manager, der deklarative Manifeste in wiederholbare Releases mit Versionskontrolle und Abhängigkeiten umwandelt. Zusammen liefern sie vorhersehbare Deploys, schnelle Pullbacks und eine einheitliche Infrastruktursprache.

2) Clusterdesign

2. 1 Topologie und Fehlertoleranz

Multi-AZ: Steuerebene und Knoten der Arbeitspools sind über Zonen verteilt; PDB/TopologySpreadConstraints für Gleichmäßigkeit.
Multiregion/DR: unabhängige Cluster pro Region; überregionale Anrufe - nur über „kalte“ Wege (Kataloge/Telemetrie), „heiße“ (Brieftasche) - lokal.
Workerpools nach Profil: 'general', 'compute', 'io', 'spot' (für Hintergrundaufgaben). Zuordnung über nodeSelector/affinity/taints.

2. 2 Namespaces und Mehrbenutzermodell

Namespace-Isolation nach Domains/Befehlen: 'payments', 'wallet', 'games', 'reporting'.
ResourceQuota + LimitRange: CPU/RAM-Basislimits und maximale Replikate; Schutz des Clusters vor „Staubsaugern“.
RBAC: Standardrollen lesen nur, schreiben nur CI/CD und On-Call.

2. 3 Netzwerk

CNI mit Unterstützung für NetworkPolicy (Calico/Cilium): L3/L4 Richtlinien für Namespace/Label.
Ingress → Gateway API: Umstieg auf das Modell 'GatewayClass/Gateway/HTTPRoute' für Kanarienvögel und Vielschichtigkeit.
Service Mesh (optional): mTLS, Retry/Breaker, Locality-Aware; Punkt für Punkt für Service-übergreifende Zuverlässigkeit.

3) Zuverlässigkeit und Skalierung

3. 1 Scaling

HPA nach benutzerdefinierten Metriken (RPS/Latency/Queue Depth), nicht nur CPU.
VPA auf der Hintergrundlastklasse; in der Produktion - „recommendation only“ oder zusammen mit der HPA für verschiedene Metriken.
Cluster Autoscaler: einzelne Node-Gruppen für sensible Dienste; warm-pool zu den Gipfeln (Turniere/Matches).

3. 2 Ressourcen und QoS

Jeder Pod hat Requests/Limits; vermeiden „: neueste“ und „unbegrenzte“ Container.
PriorityClass: Kritische Dienste ('wallet', 'payments') verdrängen unkritische.
PDB: Verhindern Sie, dass sich der Cluster beim Aktualisieren der Knoten in den Fuß schießt.

3. 3 Updates ohne Ausfallzeiten

RollingUpdate c maxUnavailable = 0 auf kritischen Pfaden.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Surge-Kapazität für schnelle Releases während Peaks - mit Vorsicht.

4) Plattformsicherheit

Pod Security (Baseline/Restricted) auf Namespace-Ebene; Verbot von 'privileged', hostPath, root.
NetworkPolicy: default-deny und whitelists nach Port/Label.
Seccomp/AppArmor, non-root users, read-only rootfs.
Geheimnisse: KMS/Vault Provider (CSI), nicht halten Geheimnisse in 'Werte. yaml 'in offener Form.
RBAC-Minimum: Service-Konten geben nur die erforderlichen Rechte; Token sind kurzlebig.
Admission-Kontrolle: OPA/Gatekeeper/Kyverno - enforce Labels, Limits, Policy-Verstöße.

5) Observability

OpenTelemetry: Tracing von Ingress/Gateway → Service → DB/Cache, obligatorische Labels' service', 'version', 'region', 'partner', 'api _ version'.
Protokolle: strukturiert, ohne PII/PAN; Weiterleitung an einen zentralen Speicher.
Metriken: RED/USE, SLO-Dashboards, Burn-Rate-Alerts.
Synthetik: Proben aus den gewünschten Ländern/ASN; Perimeter und interne Gesundheitschecks.

6) GitOps и progressive delivery

Argo CD/Flux: der gewünschte Zustand wird in Git gespeichert; jeder Namespace ist ein eigenes Repository/Ordner.
Förderung von Artefakten: "dev → stage → prod' durch PR, nicht" kubectl apply ".
Canary/Blue-Green: Argo Rollouts/Gateway API; Erfolgsmetriken - P95/P99, Error-Rate, Business-SLI (CR-Einlagen).
Rollbacks: in Helm/Argo - per Button; in den Charts - die Versionen stehen fest.

7) Helm: Best Practices

7. 1 Chartstruktur

my-service/
Chart. yaml     # name, version (SemVer), appVersion values. yaml # base values (no secrets)
values-prod. yaml # prod overrides (no secrets)
templates/
_helpers. tpl # naming, common deployment templates. yaml service. yaml hpa. yaml pdb. yaml networkpolicy. yaml serviceaccount. yaml ingress_or_gateway. yaml charts/# dependencies (opcional)

• 'version' ist die Chartversion (SemVer), 'appVersion' ist die Version der App (Image).
• Strenge Ressourcennamen:'{{include "svc. fullname".}}}'+ labels' app. kubernetes. io/`.
• Erforderliche Manifeste: Deployment/StatefulSet, Service, ServiceAccount, HPA (falls zutreffend), PDB, NetworkPolicy.

7. 2 Werte-Strategie

Basis' Werte. yaml'- Standardwerte, ohne Geheimnisse und Umgebung-Spezifität.
Overrides: 'values- {stage' prod} .yaml'+ per-region Dateien.
Geheimnisse: SOPS ('values-prod. sops. yaml') oder Vault-Injektion über CSI.
Ressourcen- und Probenparameter sind in Werten mit „angemessenen“ Ausfällen.

7. 3 Abhängigkeiten und gemeinsamer Code

Allgemeine Charts-Bibliotheken für Muster (probes, annotations, NetworkPolicy).
Abhängigkeiten ('requirements '/' Chart. yaml') nach Version fixieren; Vermeiden Sie tiefe „Matrjoschkas“.

7. 4 Vorlagen und Prüfungen

Verwenden Sie' required 'und' fail 'in' _ helpers. tpl 'für kritische Werte.
Validierung des Wertschemas - 'Werte. schema. json`.
Einheitstests der Charts - „helm unittest“; statische Analyse - kubeconform/kubeval.
Das lokale Debugging ist 'helm template' + '--values' + 'kubeconform'.

7. 5 Freigaben und Speicherung

Chart-Push in OCI-Register von Containern; Tags von SemVer.
Helmfile/`helmfile. d 'zur Orchestrierung von Mehrchartrollen.
CI-Artefakte: generierte Manifeste + Lockfiles von Abhängigkeiten.

8) Beispiel: Deployment (Fragment einer Helm-Vorlage)

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "svc. fullname". }}
labels: {{ include "svc. labels". nindent 4 }}
spec:
replicas: {{.Values. replicas      default 3 }}
strategy:
type: RollingUpdate rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{ include "svc. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{ include "svc. selectorLabels". nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}
spec:
serviceAccountName: {{ include "svc. serviceAccountName". }}
securityContext:
runAsNonRoot: true containers:
- name: app image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports:
- name: http containerPort: {{.Values. ports. http }}
resources:
requests:
cpu: {{.Values. resources. requests. cpu }}
memory: {{.Values. resources. requests. memory }}
limits:
cpu: {{.Values. resources. limits. cpu }}
memory: {{.Values. resources. limits. memory }}
readinessProbe:
httpGet:
path: /healthz port: http periodSeconds: 5 envFrom:
- secretRef:
name: {{ include "svc. secretsName". }}

9) Geheimnisse und Konfigurationen

Secrets über CSI (Vault/KMS) oder SOPS im Git-Repository (GPG/KMS-Schlüssel; Verbot „kubectl edit“).
ConfigMap/Secret checksum Anmerkungen für Rolling Release Trigger.
PAN/PII nicht aufbewahren; Tokenisierung verwenden.
Versiegelte Geheimnisse sind erlaubt, aber bevorzugt SOPS oder Direct CSI.

10) Netzwerk und Perimeter

Gateway-API für L7-Routing, Kanarienvögel und Blau-Grün; Sticky-Sitzungen nur bei Bedarf.
mTLS zwischen den Diensten über mesh/sidecar-less (Cilium) - Punkt für Punkt für den Zahlungskern.
Egress: kontrollierte Liste externer Knoten (PSP/KYC), feste NAT-IPs, Timeouts und Retraybudget.

11) Stateful-Dienste und Daten

Verwenden Sie für OLTP-Datenbanken Managed Cloud Services oder Operatoren (Postgres/MySQL) in separaten Clustern.
PVC/CSI mit Snapshot- und Backup-Richtlinien; 'PodAntiAffinity' für Replikate.
Für Warteschlangen/Streaming - verwaltete Lösungen oder dedizierte Cluster; im „allgemeinen“ Anwendungscluster ein Minimum des Zustands zu halten.

12) CI/CD-Förderband (Referenz)

1. Build & Test → 2) SCA/Lint → 3) Bild im Register (SBOM, Signatur) →

2. Die Generierung der Helm-Charts + 'helm unittest' + kubeconform →

3. SOPS-Dekripte in CD-Rantyme → 6) PR im GitOps-Repository →

4. Argo/Flux gilt → 8) Argo Rollouts canary → 9) Auto-Urteil auf SLO → 10) Promotion/Rollback.

13) Metriken der Plattformreife

Anteil der Veröffentlichungen über GitOps (Ziel: 100%).
Rollzeit (P95) bis zur Bereitschaft, MTTR Rollback.
Namespace's Pod Security und NetworkPolicy Abdeckung (Ziel: 100%).
% der Dienste mit HPA und korrekten Requests/Limits.
% der Charts mit 'Werten. schema. json 'und Unit-Tests.
Vorfälle durch „manuelle“ Änderungen (Ziel: 0).

14) Checkliste Umsetzung

1. Cluster nach Zonen, Knotenpool nach Profilen; PDB/TopologySpreadConstraints.
2. Namespace-Modell, ResourceQuota/LimitRange, RBAC Minimum.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; egress-Steuerung und NAT-Fixierung an die Anbieter.
5. Observability: OTel Trails, RED/USE, Synthetik durch Geo; SLO-Dashboards.
6. GitOps (Argo/Flux), kanarisch/blau-grün, Autopromotion nach Metriken.
7. Helm-Standards: Struktur, Schema. json, Tests, SOPS/Vault, OCI-Register.
8. HPA/VPA, Cluster Autoscaler, Warmwasser-Pool zu den Spitzen.
9. Datenoperationen: CSI-Snapshots, Backups, Operatoren/Managed DB.
10. Regelmäßige DR/Chaos-Tests und Spieltage.

15) Anti-Muster

Ein „gigantisches“ Cluster für alles ohne Isolation und Quoten.
Container ohne Ressourceneinschränkungen, 'neueste' Tags, keine Probes.
Geheimnisse in 'Werten. yaml 'im Klartext,' kubectl edit 'im Prod.
Veröffentlichungen an GitOps vorbei, manuelle Bearbeitungen von Manifesten auf einem Live-Cluster.
Keine NetworkPolicy/Pod Security - „flaches“ Netzwerk.
Einheitliches gemeinsames HPA-Signal über CPU für unterschiedliche Lasten.
Speicherung der OLTP-DB innerhalb eines „allgemeinen“ Anwendungsclusters ohne Operator und Backups.

16) iGaming/Fintech Kontext: Praktische Hinweise

Payment Webhooks: dedizierter Ingress/Gateway und schmaler Egress zum PSP; strikte Timeouts/Retrays; einen separaten Knotenpool.
VIP-Verkehr: Priorisierung und individuelle Routen; PDB und Topologie Spread für Stabilität.
Turniere/Spitzen: Warm-Pool-Knoten + Predictive HPA; Aufwärmen von Caches/Verbindungen.
Reporting/CDC: separater Cluster/Pool, damit ETL keinen Einfluss auf die prod.
Regulatorisch: Unveränderliche Protokolle (WORM), PII-Tokenisierung, Netzsegmentierung.

Summe

Eine starke Kubernetes-Plattform ist kein „Haufen YAML“, sondern Standards: Isolation, Sicherheitspolitik, verwaltete Ressourcen, Beobachtbarkeit und GitOps-Disziplin. Helm-Charts - Ihr Liefervertrag: planbare Releases, testbare Templates, sicherer Umgang mit Geheimnissen und einfache Pullbacks. Durch die Verankerung dieser Prinzipien erhalten Sie Cluster, die Spitzen überstehen, Releases beschleunigen und den Anforderungen von Unternehmen und Aufsichtsbehörden standhalten.