Operationen und Verwaltung → Ausführungsrichtlinien und Laufzeitbeschränkungen
Ausführungsrichtlinien und Laufzeitbeschränkungen
1) Ernennung
Runtime-Richtlinien machen das Verhalten von Diensten vorhersehbar, sicher und wirtschaftlich: Begrenzen Sie „laute Nachbarn“, verhindern Sie Leckagen und Überhitzung, stellen Sie die Einhaltung und Beibehaltung von SLOs sicher, wenn die Last steigt.
Die Hauptziele sind: Isolation, gerechte Verteilung der Ressourcen, kontrollierte Degradation, Reproduzierbarkeit, Audit.
2) Geltungsbereich
Berechnungen und Speicher: CPU, RAM, GC-Pausen, Thread-Limits.
Laufwerk/Speicher: IOPS/throughput, Kontingente, fs-Richtlinien (nur lesen).
Сеть: egress/ingress, bandwidth shaping, network policies.
Prozesse/Systemaufrufe: seccomp, capabilities, ulimit.
Orchestrierung: Kubernetes QoS, requests/limits, priorities, taints/affinity.
APIs/Gateways: Rate-Limits, Kontingente, Timeouts/Retrays, Circuit-Breakers.
Daten/ETL/Streams: batch/stream concurrency, consumer lag budgets.
Sicherheit: AppArmor/SELinux, rootless, secrets/cofigi.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.
3) Grundprinzipien
Fail-safe default: Es ist besser, überflüssige Anfragen zu verwerfen, als zu fallen.
Budgetgetrieben: Timeouts/Retrays passen in das Zeitbudget der Anfrage und das Fehlerbudget des SLO.
Kleiner Blastenradius: Isolation nach Namespace/Pool/Node/Shard.
Declarative & auditable: Alle Einschränkungen sind im Code/Repository + Änderungsprotokoll.
Multi-Tenant Fairness: Kein Mieter/Team kann den gesamten Cluster „aussaugen“.
4) Berechnungen und Speicher
4. 1 Kubernetes и cgroup v2
requests/limits: requests garantieren einen Anteil an CPU/Speicher; limits umfassen throttling/OOM-killer.
QoS-Klassen: Garantiert/Burstable/BestEffort - Kritische Workloads halten wir in Garantiert/Burstable.
CPU: `cpu. shares`, `cpu. max'(throttle), CPuset für Pinning.
Speicher: 'Speicher. max`, `memory. swap. max'(in der Regel swap off), oom_score_adj für die Priorität.
4. 2 Muster
Headroom 20-30% auf dem Knoten, Anti-Affinität zu duplizieren.
GC-Limits: JVM '-Xmx' <k8s memory limit; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit: 'nofile', 'nproc', 'fsize' - nach Dienstprofil.
5) Festplatte und Speicher
IOPS/Throughput-Quoten für PVC/Cluster-Speicher; Trennung von Protokollen/Daten.
Read-only root FS, tmpfs für temporäre Dateien, Größenbeschränkung '/tmp'.
FS-Watchdog: Warnungen für Volume-Filling und Inode-Wachstum.
6) Netzwerk und Verkehr
NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandbreiten: tc/egress-policies, QoS/DSCP für kritische Threads.
Egress-Controller: Liste der zulässigen Domänen/Subnetze, DNS-Audit.
mTLS + TLS-Richtlinien: Verschlüsselung und Erzwingung der Protokollversion.
7) Prozesssicherheit
Seccomp (allowlist syscalls), AppArmor/SELinux-Profile.
Drop Linux capabilities (Minimum verlassen), 'runAsNonRoot', 'readOnlyRootFilesystem'.
Rootless Container, signierte Bilder und attestations.
Secrets-only via Vault/KMS, tmp-Token mit kurzer TTL.
8) Zeitpolitiken: Timeouts, Retrays, Budgets
Timeout-Budget: Die Summe aller Hop's ≤ SLA und Tu-End.
Retrays mit Backoff + Jitter, maximale Versuche nach Fehlerklasse.
Circuit-breaker: offen bei error %/timeout p95 über Schwelle → schnelle Ausfälle.
Bulkheads: Separate Verbindungspools/Warteschlangen für kritische Pfade.
Backpressure: Beschränkung der Produzenten auf Verbraucherverzug.
9) Rate-Limits, Quoten und Priorität
Algorithmen: Token/Leaky Bucket, GCRA; lokal + verteilt (Redis/Envoy/global).
Granularität: API-Schlüssel/Benutzer/Organisation/Region/Endpunkt.
Prioritätsgradienten: „Zahlungs-/Autorisierungsströme“ - Gold, Analytik - Bronze.
Kontingente pro Tag/Monat, „burst“ und „sustained“ Limits; 429 + Retry-After.
10) Orchestrierung und Planer
PriorityClass: schützt P1-Pods vor Verdrängung.
PodDisruptionBudget: Downtime-Grenzen bei Updates.
Taints/Tolerations, (anti) Affinity - Isolierung von Workloads.
RuntimeClass: gVisor/Firecracker/Wasm für Sandboxes.
Horizontal/Vertical autoscaling mit Schwellen und max-replicas.
11) Daten-/ETL-/Stream-Richtlinien
Concurrency per job/topic, max batch size, checkpoint intervall.
Consumer lag budgets: warning/critical; DLQ und Retraylimit.
Freshness SLA für Schaufenster, Pause von schweren Jobs während der Spitzen des Prod-Verkehrs.
12) Policy-as-Code und Zulassungs-Kontrolle
OPA Gatekeeper/Kyverno: Verbot von Pods ohne requests/limits, ohne' readOnlyRootFilesystem', mit 'hostNetwork',': latest'.
Conftest für Pre-Commit-Prüfungen Helm/K8s/Terraform.
Mutationsrichtlinien: Auto-Build-Sidecar (mTLS), Anmerkungen, seccompProfile.
yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: require-resources spec:
validationFailureAction: Enforce rules:
- name: check-limits match:
resources:
kinds: ["Pod"]
validate:
message: "We need resources. requests/limits for CPU and memory"
pattern:
spec:
containers:
- resources:
requests:
cpu: "?"
memory: "?"
limits:
cpu: "?"
memory: "?"
Beispiel OPA (Rego) - Timeouts ≤ 800 ms:
rego package policy. timeout
deny[msg] {
input. kind == "ServiceConfig"
input. timeout_ms> 800 msg: = sprintf ("timeout% dms exceeds budget 800ms," [input. timeout_ms])
}
13) Beobachtbarkeit und Compliance-Metriken
Compliance%: Anteil der Pods mit korrekten Requests/Limits/Labels.
Security Posture: Anteil der Pods mit seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 timeouts/retrays, circuit-open duration.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.
14) Checklisten
Vor dem Service
- Requests/Limits sind vorgeschrieben; QoS ≥ Burstable
- Timeouts und Retrays passen in ein End-to-End SLA
- Circuit-breaker/bulkhead für externe Abhängigkeiten aktiviert
- NetworkPolicy (ingress/egress) и mTLS
- Seccomp/AppArmor, drop capabilities, non-root, read-only FS
- Raten-Limits und Quoten auf dem API-Gateway/Dienst
- PDB/Priorität/Affinität angegeben; Autoscaling konfiguriert
Monatlich
- Policy-Exception-Audit (TTL)
- Überarbeitung der Zeit-/Fehlerbudgets
- Degradationstest (fire-drill): shed/backpressure/circuit-breaker
- Rotation von Geheimnissen/Zertifikaten
15) Anti-Muster
Ohne Requests/Limits: „Burst“ frisst Nachbarn → Kaskadenausfälle.
Globale Retrays ohne Jitter: Sturm auf Abhängigkeiten.
Endlose Timeouts: „hängende“ Anschlüsse und Erschöpfung von Pools.
': latest' und mutable Tags: unvorhersehbare Runtime-Builds.
Offener Egress: Lecks und nicht verwaltete Abhängigkeiten.
Keine PDB: Updates „klopfen“ den gesamten Pool.
16) Mini-Playbooks
A. Anstieg der CPU throttle% bei payments-service
1. Limits/Requests prüfen und heiße Pfade profilieren.
2. Vorübergehend Requests anheben, Autoscale auf p95 latency aktivieren.
3. Aktivieren Sie den Cache-Vollback von Limits/Kursen, reduzieren Sie die Komplexität von Abfragen.
4. Post-Fix: Denormalisierung/Indizes, Revision der Limits.
B. 429 Wachstum und API-Beschwerden
1. Bericht über Schlüssel/Organisationen → die auf der Quote ruhten.
2. Geben Sie hierarchical quotas (per- org→per -key), heben Sie burst für gold.
3. Kommunikation und Führung auf Backoff; adaptive Begrenzung aktivieren.
B. Massenoom-Kills
1. Reduzieren Sie die Konzentration, aktivieren Sie Heap-Limit und Profiling.
2. Berechnen Sie Xmx/GOMEMLIMIT für echte Peak-Usage.
3. Trainieren Sie GC/Pools neu, fügen Sie Swap-Off und Soft-Limit Alerts hinzu.
17) Beispiele für Konfigurationen
K8s Container mit sicheren Einstellungen (Fragment):yaml securityContext:
runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities:
drop: ["ALL"]
Envoy rate-limit (Fragment konzeptionell):
yaml rate_limit_policy:
actions:
- request_headers:
header_name: "x-api-key"
descriptor_key: "api_key"
Nginx ingress - Timeouts und Einschränkungen:
yaml nginx. ingress. kubernetes. io/proxy-connect-timeout: "2s"
nginx. ingress. kubernetes. io/proxy-read-timeout: "1s"
nginx. ingress. kubernetes. io/limit-rps: "50"
18) Integration mit Change- und Incident Management
Jede Lockerung der Politik ist durch RFC/CAB und eine vorübergehende Ausnahme mit TTL.
Vorfälle von Verstößen gegen die Richtlinien → Post-Mortem und Aktualisierung der Regeln.
Die Compliance Dashboards sind mit dem Releasekalender verbunden.
19) Das Ergebnis
Ausführungspolitiken sind ein „Geländer“ für die Plattform: Sie hindern nicht daran, schnell zu fahren, sie lassen nicht fallen. Deklarative Beschränkungen, automatischer Zwang, gute Metriken und die Disziplin der Ausnahmen verwandeln chaotische Ausbeutung in ein kontrollierbares und vorhersehbares System - mit kontrollierbarem Wert und nachhaltigen SLOs.