Operazioni e Gestione → Criteri di esecuzione e vincoli runtime

Criteri di esecuzione e vincoli runtime

1) Destinazione

Le politiche runtime rendono prevedibile, sicuro ed economico il comportamento dei servizi, limitando i «vicini rumorosi», impedendo fughe e surriscaldamenti, garantendo la compliance e il mantenimento di SLO durante l'aumento del carico di lavoro.

Obiettivi chiave: isolamento, equa distribuzione delle risorse, degrado controllato, riproduzione, verifica.

2) Ambito di copertura

Calcolo e memoria: CPU, RAM, pause GC, limiti di flusso.
Unità/storage: iOPS/throughput, quote, fs-regole (read-only).
Сеть: egress/ingress, bandwidth shaping, network policies.
Processi/chiamate di sistema: seccomp, capabilities, ulimit.
Orchestrazione: Kubernets, richiesti/limits, priorità, taints/affinity.
API/gateway: rate-limits, quote, timeout/retrai, circuito-breakers.
Dati/ETL/striam: batch/stream concertency, consumer lag budget.
Sicurezza: AppArmor/SELinux, rootless, segreti/cofighi.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.

3) Principi di base

Fail-safe predefinito: è meglio ignorare le richieste in eccesso che cadere.
Budget-driven - Timeout/retrai si inseriscono nel bilancio del tempo di query e nel bilancio degli errori SLO.
Small blast radius - Isolamento per namespace/pool/nodo/shard.
Declarative & auditable: tutti i vincoli sono nel codice/repository + registro delle modifiche.
Multi-tenant fairness: nessun inquilino/comando può «risucchiare» l'intero cluster.

4) Calcoli e memoria

4. 1 Kubernetes и cgroup v2

richiesti/limits: richiesti garantiscono una quota di CPU/memoria; limits includono throttling/OOM-killer.
classi QoS: Guaranteed/Burstable/ BestEffort - worcload critici tenuti in Guaranteed/Burstable.
CPU: `cpu. shares`, `cpu. max '(throttle), CPuset per il pinning.
Memoria, memory. max`, `memory. swap. max '(solitamente swap off), o _ score _ adj per la priorità.

4. 2 Pattern

Headroom 20-30% sul nodo, anti-affinity per duplicazione.
Limiti GC: JVM '-Xmx' <k8s memory limit; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit: «nofile», «nproc», «fsize» è il profilo del servizio.

5) Unità e storage

Quote IOPS/Throughput per PVC/cluster-storage Separazione dei registri/dati.
Read-only root FS, tmpfs per i file temporanei, limite di dimensione '/tmp '.
FS-watchdog: alert per riempire volumi e crescita inode.

6) Rete e traffico

NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandwidth limits: tc/egress-policies, QoS/DSCP per flussi critici.
Egress Controller: elenco dei domini/subnet consentiti, auditDNS.
mTLS + TLS policies: crittografia e versione obbligatoria del protocollo.

7) Sicurezza del processo

Seccomp (allowlist syscalls), AppArmor/SELinux i profili.
Drop Linux capabilities, runAsNonRoot, readOnlyRootFilesystem.
contenitori Rootless, immagini firmate e attrazioni.
Secret-only via Vault/KMS, tmp-tokens con TTL breve.

8) Regole del tempo: timeout, retrai, budget

Timeout budget: la somma di tutti gli HOP e-to-end.
Retrai con backoff + jitter, massimo tentativi per classe di errori.
Circuito-breaker: aperto con un errore %/timeout p95 sopra la soglia di errore rapido.
Bullkheads: connection-pool's/code per percorsi critici.
Backpressure: limitazione dei produttori per lag consumer.

9) Rate-limits, quote e priorità

Algoritmi: token/leaky bucket, GCRA; locali + distribuiti (Redis/Avvoy/global).
Granularità: chiave API/utente/organizzazione/regione/endpoint.
Le sfumature di priorità sono i flussi di pagamento/autosufficienza - gold, l'analista - bronze.
Quote al giorno/mese, limiti «burst» e «sustained»; 429 + Retry-After.

10) Orchestrazione e pianificazione

PriorityClass - Protegge i P1-pod dall'espulsione.
PodDisruptionBudget - Limite di downtime per gli aggiornamenti.
Tainti/Tolerations, (anti) Affinity - Isolamento workloads.
, per i ini di sabbia.
Orizzontal/Vertical autoscaling con soglie di guardia e max-replica.

11) Criteri dati/ETL/striam

Concurrency per job/topic, max batch size, checkpoint intervallo.
Consumer lag budgets: warning/critical; DLQ e limite di retrai.
Freshness SLA per le vetrine, la pausa dei giubbotti pesanti ai picchi di traffico prod.

12) Policy-as-Code e controllo admissi

OPA Gatekeeper/Kyverno - Disattiva i sottopassaggi senza richiesti/limits, senza "readOnlyRootFilesystem", con "hostNetwork", 'latest ".
Conftest per i controlli pre-commit Helm/K8s/Terraform.
Mutation policies: uscita automatica sidecar (mTLS), annotazioni, 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: "?"

rego package policy. timeout

deny[msg] {
input. kind == "ServiceConfig"
input. timeout_ms> 800 msg: = sprintf ("timeout% dms exceeds budget 800ms," [input. timeout_ms])
}

13) Osservabilità e metriche di conformità

Compliance% - Percentuale di sotto con richiesti corretti/limits/labels.
Sicurezza Posture - Quota sottovuoto con seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 timeout/retrai, circuito-open duration.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.

14) Assegno fogli

Prima di inviare il servizio

• Sono stati prescritti i richiesti/limits; QoS ≥ Burstable
• Timeout e retrai si adattano a end-to-end SLA
• Circuito-breaker/bullkhead abilitati per dipendenze esterne
• NetworkPolicy (ingress/egress) и mTLS
• Seccomp/AppArmor, drop capabilities, non-root, read-only FS
• Rate-limits e quote sul gateway API/servizio
• PDB/priority/affinity impostati; autoscaling configurato

Mensilmente

• Controllo delle eccezioni policy (TTL)
• Revisione dei budget temporali/errori
• Test di degrado (fire-drill): shed/backpressure/circuito-breaker
• Rotazione di segreti/certificati

15) Anti-pattern

Senza richiesti/limits, il «burst» mangia i vicini per i guasti a cascata.
Retrai globali senza jitter, tempesta alle dipendenze.
I timeout infiniti, i connettori appesi e l'esaurimento dei pool.
'- latest'e i tag mutabili sono assiemi runtime imprevedibili.
Eguress aperto: fughe e dipendenze non controllate.
Nessun PDB: gli aggiornamenti eliminano l'intero pool.

16) Mini playbook

A picco CPU throttle% al payments-service

1. Controlla limits/sollests e profila i percorsi hot.
2. Alzare temporaneamente i richiesti, attivare lo scale automatico su p95 latency.
3. Abilita la cache follback dei limiti/corsi e riduce la complessità delle richieste.
4. Post-fix: denormalizzazione/indici, revisione limits.

B. Altezza 429 e reclami per API

1. Il resoconto delle chiavi/organizzazioni dice chi è entrato in quota.
2. Immettere le quote hierarchiche (per- -key), sollevare il burst per il gold.
3. Comunicazione e guidance per backoff; abilitare l'adattativo limiting.

B. OOM kills di massa

1. Riduzione di concurrency, abilitare il limite heap e la profilassi.
2. Ricalca Xmx/GOMEMLIMIT in peak-usage reali.
3. Ridisegnare GC/pool, aggiungere swap-off e soft-limit alert.

17) Esempi di configurazione

yaml securityContext:
runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities:
drop: ["ALL"]

yaml rate_limit_policy:
actions:
- request_headers:
header_name: "x-api-key"
descriptor_key: "api_key"

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) Integrazione con la gestione dei cambiamenti e degli incidenti

Qualsiasi indebolimento della politica è tramite RFC/CAV e l'esclusione temporanea da TTL.
Incidenti per violazioni di policy, post mortem e aggiornamento delle regole.
I dashboard di corrispondenza (compliance) sono collegati al calendario di lancio.

19) Totale

La politica di esecuzione è una ringhiera per la piattaforma, non impediscono di andare veloce, non fanno cadere. I vincoli dichiarativi, la coercizione automatica, le buone metriche e la disciplina delle eccezioni trasformano un funzionamento caotico in un sistema gestibile e prevedibile, con un costo controllato e SLO sostenibile.