Opérations et gestion des → Stratégies d'exécution et restrictions d'exécution

Stratégies d'exécution et restrictions d'exécution

1) Destination

Les responsables politiques rendent le comportement des services prévisible, sûr et économique : ils limitent les « voisins bruyants », empêchent les fuites et la surchauffe, assurent la conformité et la rétention des SLO lorsque la charge augmente.

Objectifs clés : isolement, répartition équitable des ressources, dégradation contrôlée, reproductibilité, audit.

2) Portée

Calculs et mémoire : CPU, RAM, pauses GC, limites de flux.
Disque/stockage : IOPS/throughput, quotas, stratégies fs (read-only).
Сеть: egress/ingress, bandwidth shaping, network policies.
Processus/appels système : seccomp, capabilities, ulimit.
Orchestration : Kubernetes QoS, demandes/limites, priorités, taints/affinity.
API/passerelles : taux-limites, quotas, délais/retraits, circuits-breakers.
Données/ETL/strim : batch/stream concurrency, consumer lag budgets.
Sécurité : AppArmor/SELinux, rootless, secrets/cofigs.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.

3) Principes de base

Fail-safe par défaut : il est préférable de jeter les requêtes superflues plutôt que de tomber.
Budget-driven : les délais/retraits s'intègrent dans le budget de temps de demande et le budget d'erreur SLO.
Petit blast radius : isolation par namespace/pool/nœud/shard.
Declarative & auditable : toutes les restrictions sont dans le code/référentiel + journal des modifications.
Multi-tenant fairness : aucun locataire/équipe ne peut « aspirer » l'ensemble du cluster.

4) Calcul et mémoire

4. 1 Kubernetes и cgroup v2

requests/limites : requests garantissent la part CPU/mémoire ; les limites incluent throttling/OOM-killer.
Classes QoS : Guaranteed/Burstable/BestEffort - Les workloades critiques sont maintenues à Guaranteed/Burstable.
CPU: `cpu. shares`, `cpu. max '(throttle), CPuset pour pinning.
Mémoire : 'memory. max`, `memory. swap. max '(généralement swap off), oom_score_adj pour la priorité.

4. 2 Modèles

Headroom 20-30 % sur le nœud, anti-affinité pour la duplication.
Limites GC : JVM' -Xmx '<k8s memory limit ; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit : 'nofile', 'nproc', 'fsize' - par profil de service.

5) Disque et stockage

Quotas IOPS/Throughput pour le PVC/cluster de stockage ; séparation des journaux/données.
Read-only root FS, tmpfs pour les fichiers temporaires, limite de taille '/tmp '.
FS-watchdog : alertes pour le remplissage des volumes et la croissance de l'inode.

6) Réseau et trafic

NetworkPolicy (ingress/egress) — zero-trust east-west.
Limites de bandwidth : tc/egress-polices, QoS/DSCP pour les flux critiques.
Contrôleur egress : liste des domaines/sous-réseaux autorisés, audit DNS.
mTLS + TLS polices : cryptage et version forcée du protocole.

7) Sécurité du processus

Seccomp (allowlist syscalls), profils AppArmor/SELinux.
Drop Linux capabilities (laisser un minimum), 'runAsNonRoot', 'readOnlyRootFilesystem'.
Conteneurs rootless, images signées et attestations.
Secret-only via Vault/KMS, tmp-tokens avec TTL court.

8) Politiques du temps : Timaoutes, Retrai, Budgets

Timeout budget : la somme de tous les hop's ≤ SLA & t-end.
Retrai avec backoff + gitter, maximum de tentatives par classe d'erreur.
Circuit-breaker : open à error %/timeout p95 est plus haut que le seuil → les refus rapides.
Bulkheads : connection-pool 's/queues séparées pour les chemins critiques.
Backpressure : limiter les producteurs aux consommateurs.

9) Taux-limites, quotas et priorité

Algorithmes : token/leaky bucket, GCRA ; local + distribué (Redis/Envoy/global).
Granularité : clé API/utilisateur/organisation/région/endpoint.
Gradients de priorité : flux « paiement/autorisation » - or, analyse - bronze.
Quotas par jour/mois, limites « burst » et « sustained » ; 429 + Retry-After.

10) Orchestration et planificateur

PriorityClass : protège les pods P1 contre l'expulsion.
PodDissolutionBudget : limites du downtime lors des mises à jour.
Taints/Tolerations, (anti) Affinity - workloads isolation.
RuntimeClass : gVisor/Firecracker/Wasm pour sandbox.
Horizon/Vertical autoscaling avec seuils de garde et max-replicas.

11) Politiques de données/ETL/strim

Concurrency per job/topic, max batch size, checkpoint intervalle.
Consumer lag budgets: warning/critical; DLQ et limite des retraits.
Freshness SLA pour les vitrines, pause de jobs lourds lors des pics de trafic.

12) Policy-as-Code et admission-contrôle

OPA Gatekeeper/Kyverno : interdiction des pods sans requêtes/limites, sans « readOnlyRootFilesystem », avec « hostNetwork », « : latest ».
Conftest pour les contrôles pré-commit Helm/K8s/Terraform.
Mutation policy : Auto-transfert sidecar (mTLS), annotations, 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) Observabilité et métriques de conformité

Conformité %: proportion de pods avec des demandes correctes/limites/étiquettes.
Security Posture : proportion de pods avec seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 timeouts/rétroactifs, circuit-open duration.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.

14) Chèques-feuilles

Avant de mettre en place le service

• Exigences/limites prescrites ; QoS ≥ Burstable
• Les délais et les retraits s'intègrent dans la SLA
• Circuit-breaker/bulkhead inclus pour les dépendances externes
• NetworkPolicy (ingress/egress) и mTLS
• Seccomp/AppArmor, drop capabilities, non-root, read-only FS
• Taux-limites et quotas sur la passerelle API/service
• PDB/priority/affinity sont spécifiés ; autoscaling mis en place

Mensuelle

• Vérification des exclusions politiques (TTL)
• Révision des budgets temps/erreurs
• Test de dégradation (fire-drill) : shed/backpressure/circuit-breaker
• Rotation des secrets/certificats

15) Anti-modèles

Sans requests/limits : le « burst » bouffe les voisins en cascade → les pannes.
Retraits globaux sans jitter : orage aux dépendances.
Tymautes infinis : connexions « suspendues » et épuisement des pools.
': latest' et les balises mutables : assemblages runtime imprévisibles.
Egress ouvert : fuites et dépendances non gérables.
Absence de PDB : les mises à jour « éliminent » tout le pool.

16) Mini-playbooks

A. Sursaut de CPU throttle % chez payments-service

1. Vérifiez les limites/demandes et profilez les chemins chauds.
2. Soulevez temporairement les demandes, allumez le skate automatique à p95 latency.
3. Activer le cache-folleback des limites/cours, réduire la complexité des demandes.
4. Post-fix : dénormalisation/indices, révision des limites.

B. Taille 429 et plaintes contre l'API

1. Rapport sur les clés/organisations → ont pris dans le quota.
2. Entrez quotas hierarchiques (per- org→per -key), soulevez burst pour gold.
3. Communication et orientation sur le backoff ; activer la limitation adaptative.

Kills OOM massifs

1. Réduire la concurrence, inclure la limite heap et le profilage.
2. Recalculer Xmx/GOMEMLIMIT pour réel peak-utilisation.
3. Réapprendre GC/pools, ajouter swap-off et soft-limit alerts.

17) Exemples de configurations

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) Intégration avec la gestion des changements et des incidents

Tout affaiblissement de la politique est par l'intermédiaire de RFC/BOU et une exception temporaire avec TTL.
Incidents de violation de règles → post-mortem et mise à jour des règles.
Dashboards de conformité (conformité) sont connectés au calendrier de sortie.

19) Résultat

Les politiques d'exécution sont des « balustrades » pour la plate-forme : elles n'empêchent pas d'aller vite, elles ne laissent pas tomber. Les restrictions déclaratives, la coercition automatique, les bonnes mesures et la discipline des exceptions transforment une exploitation chaotique en un système gérable et prévisible - avec un coût contrôlé et des SLO durables.