Operaciones y Administración → Políticas de ejecución y restricciones runtime

Políticas de ejecución y restricciones runtime

1) Asignación

Las políticas de runtime hacen que el comportamiento de los servicios sea predecible, seguro y económico: limitan los «vecinos ruidosos», evitan fugas y sobrecalentamiento, aseguran el cumplimiento y mantienen el SLO cuando aumenta la carga.

Objetivos clave: aislamiento, distribución equitativa de los recursos, degradación controlada, reproducibilidad, auditoría.

2) Alcance

Computación y memoria: CPU, RAM, pausas GC, límites de flujo.
Disco/almacenamiento: IOPS/throughput, cuotas, políticas fs (sólo lectura).
Сеть: egress/ingress, bandwidth shaping, network policies.
Procesos/llamadas del sistema: seccomp, capabilities, ulimit.
Orquestación: Kubernetes QoS, requests/limits, priorities, taints/affinity.
API/gateways: rate-limits, cuotas, temporizadores/retiros, circuit-breakers.
Datos/ETL/streams: batch/stream concurrency, consumer lag budgets.
Seguridad: AppArmor/SELinux, rootless, secretos/cofigs.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.

3) Principios básicos

Fail-safe por defecto: es mejor descartar solicitudes superfluas que caer.
Budget-driven: los temporizadores/retiros se ajustan al presupuesto de tiempo de solicitud y al presupuesto de error de SLO.
Radius pequeño blast: aislamiento por namespace/pool/nodo/shard.
Declarative & auditable: todas las restricciones están en el código/repositorio + registro de cambios.
Fairness multi-tenant: ningún arrendatario/equipo puede «chupar» todo el clúster.

4) Computación y memoria

4. 1 Kubernetes и cgroup v2

requests/limits: las solicitudes garantizan una parte de la CPU/memoria; los límites incluyen throttling/OOM-killer.
Clases QoS: Guaranteed/Burstable/BestEffort - los worcload críticos se mantienen en Guaranteed/Burstable.
CPU: `cpu. shares`, `cpu. max '(throttle), CPuset para pinning.
Memoria: 'memory. max`, `memory. swap. max '(normalmente swap off), oom_score_adj para prioridad.

4. 2 Patrones

Headroom 20-30% en el nodo, anti-affinity para duplicación.
Límites GC: límite de memoria JVM '-Xmx' <k8s; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit: 'nofile', 'nproc',' fsize '- según el perfil del servicio.

5) Disco y almacenamiento

Cuotas IOPS/Throughput para PVC/clúster de almacenamiento; separación de registros/datos.
root FS, tmpfs para archivos temporales, límite de tamaño '/tmp '.
FS-watchdog: alertas de llenado de volúmenes y crecimiento inode.

6) Red y tráfico

NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandwidth limits: tc/egress-policies, QoS/DSCP para hilos críticos.
Controlador de egresos: lista de dominios/subredes permitidos, audit DNS.
mTLS + TLS policies: cifrado y versión forzada del protocolo.

7) Seguridad del proceso

Seccomp (allowlist syscalls), perfiles AppArmor/SELinux.
Drop Linux capabilities (deja un mínimo), 'runAsNonRoot', 'readOnlyRootFilesystem'.
Contenedores rootless, imágenes firmadas y attestations.
Secrets-only via Vault/KMS, tmp-tokens con TTL corto.

8) Políticas de tiempo: temporeros, retiros, presupuestos

Timeout budget: suma de todos los hop's ≤ SLA y tu final.
Retrés con backoff + jitter, máximo de intentos por clase de error.
Circuit-breaker: abierto con error %/timeout p95 por encima del umbral → fallas rápidas.
Bulkheads: conection-pool 's/colas individuales para rutas críticas.
Backpressure: restricción de los productores según el lag de los consumidores.

9) Ratios-límites, cuotas y prioridad

Algoritmos: token/leaky bucket, GCRA; local + distribuido (Redis/Envoy/global).
Granularidad: clave API/usuario/organización/región/endpoint.
Gradientes de prioridad: flujos de «pago/autorización» - oro, analítica - bronce.
Cuotas por día/mes, «burst» y límites «sostenidos»; 429 + Retry-After.

10) Orquestación y planificador

PriorityClass: protección de P1-pods contra el desplazamiento.
PodDisruptionBudget: bordes de downtime durante las actualizaciones.
Taints/Tolerations, (anti) Affinity - Aislation workloads.
RuntimeClass: gVisor/Firecracker/Wasm para sandbox.
Horizontal/Vertical autoscaling con puertas de guardia y max-replicas.

11) Políticas de datos/ETL/streaming

Concurrency per job/topic, max batch size, checkpoint intervalo.
Consumer lag budgets: warning/critical; DLQ y el límite de retraídos.
Freshness SLA para escaparates, pausa de jobs pesados en picos de tráfico prod.

12) Policy-as-Code y control de administración

OPA Gatekeeper/Kyverno: prohibición de pods sin requests/limits, sin 'readOnlyRootFilesystem', con 'hostNetwork', ': latest'.
Conftest para comprobaciones de Helm/K8s/Terraform pre-commit.
Políticas de mutación: autocompresión sidecar (mTLS), anotaciones, 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) Observabilidad y métricas de cumplimiento

Compliance%: proporción de podas con requests/limits/labels correctos.
Seguridad Posture: proporción de pods con seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 temporeros/retraídos, circuito-duración abierta.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.

14) Hojas de cheques

Antes de poner el servicio

• Requests/limits prescritos; QoS ≥ Burstable
• Los taimautas y los retraídos encajan en la SLA de fin a fin
• Circuit-breaker/bulkhead habilitado para dependencias externas
• NetworkPolicy (ingress/egress) и mTLS
• Seccomp/AppArmor, drop capabilities, non-root, read-only FS
• Rate-limits y cuotas en la puerta de enlace/servicio API
• PDB/priority/affinity especificado; autoscaling configurado

• Auditoría de exclusiones de políticas (TTL)
• Revisión de los presupuestos de tiempo/error
• Prueba de degradación (fire-drill): shed/backpressure/circuit-breaker
• Rotación de secretos/certificados

15) Anti-patrones

Sin requests/limits: el «bourst» se come a los vecinos → fallas en cascada.
Retratos globales sin jitter: tormenta en las dependencias.
Tiempos infinitos: connectaciones «colgantes» y agotamiento de las piscinas.
': latest' y etiquetas mutables: ensamblajes runtime impredecibles.
Egresos abiertos: fugas y dependencias no gestionadas.
Sin PDB: las actualizaciones «desactivan» todo el grupo.

16) Mini playbucks

A. Ráfaga de CPU de throttle% en payments-service

1. Compruebe los límites/requests y perfile las vías de acceso.
2. Levante temporalmente las solicitudes, habilite el scale automático por p95 latency.
3. Habilite la caché-follback de límites/cursos, reduzca la complejidad de las solicitudes.
4. Post-fix: desnormalización/índices, revisión de límites.

B. Aumento de 429 y quejas sobre API

1. Informe de claves/organizaciones → quién ha caído en cuota.
2. Introduzca las quotas hierárquicas (per- org→per -key), levante el burst para el oro.
3. Comunicación y guía de backoff; habilitar el límite adaptativo.

B. Sacrificios masivos de OOM

1. Reducir la concurrencia, habilitar el límite heap y el perfilado.
2. Convertir Xmx/GOMEMLIMIT a peak-usage real.
3. Volver a entrenar GC/pools, añadir swap-off y alertas soft-limit.

17) Ejemplos de configuraciones

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) Integración con la gestión de cambios e incidentes

Cualquier relajación de la política es a través de RFC/CAF y una excepción temporal con TTL.
Incidentes de violaciones de políticas → post mortem y actualización de reglas.
Los dashboards de conformidad (compliance) están conectados al calendario de lanzamiento.

19) Resultado

Las políticas de ejecución son una «barandilla» para la plataforma: no impiden ir rápido, no dejan caer. Las restricciones declarativas, la coerción automática, las buenas métricas y la disciplina de las excepciones convierten la operación caótica en un sistema manejable y predecible, con un costo controlado y SLOs sostenibles.