Operações e Gerenciamento de → Políticas de execução e restrições runtime

Políticas de execução e restrições runtime

1) Destino

Políticas Runtime tornam o comportamento dos serviços previsível, seguro e econômico, limitando «vizinhos ruidosos», prevenindo vazamentos e superaquecimento, fornecendo complicações e retenção de SLO quando a carga aumenta.

Objetivos essenciais: isolamento, distribuição justa de recursos, degradação controlada, reprodução, auditoria.

2) Área de alcance

Computação e memória: CPU, RAM, pausas GC, limites de fluxo.
Disco/armazenamento: IOPS/throughput, quotas, políticas fs (read-only).
Сеть: egress/ingress, bandwidth shaping, network policies.
Processos/chamadas de sistema: seccomp, capabilities, ulimit.
Orquestra: Kubernetes QoS, requests/limits, prioridades, taants/affinity.
API/gateway: rate-limits, quotas, temporizações/retrações, circuito-breakers.
Dados/ETL/striptease: batch/stream concurrency, consumer lag budgets.
Segurança: AppArmor/SELinux, rootless, segredos/cafigs.
Policy-as-Code: OPA/Gatekeeper, Kyverno, Conftest.

3) Princípios básicos

Fail-safe padrão: É melhor descartar pedidos extras do que cair.
Budet-driven: Os temporizadores/retrações se encaixam no orçamento de tempo de consulta e no orçamento de erros SLO.
Small blast radius: isolamento por namespace/pool/nó/chard.
Declarative & Auditable: todas as limitações estão no código/repositório + registro de alterações.
Multi-tenant fairness: Nenhum locator/comando pode «sugar» o cluster inteiro.

4) Computação e memória

4. 1 Kubernetes и cgroup v2

requests/limits: requests garantem uma proporção de CPU/memória; limits incluem throttling/OU-billy.
Classes QoS: Guaranteed/Burstable/ BestEffort - Vozes críticas mantidas em Guaranteed/Burstable.
CPU: `cpu. shares`, `cpu. max '(throttle), CPuset para pinning.
Memória: 'memory. max`, `memory. swap. max '(normalmente swap off), oom _ score _ adj para prioridade.

4. 2 Patternes

Headroom 20-30% no nó, anti-affinity para duplicação.
Limites GC: JVM '-Xmx' <k8s memory limit; Go: `GOMEMLIMIT`; Node: `--max-old-space-size`.
ulimit: 'nofile', 'nproc', 'fsize' - pelo perfil do serviço.

5) Disco e armazenamento

O IOPS/Throughput tem quotas de armazenamento PVC/cluster; Separação de registros/dados.
Read-only root FS, tmpfs para arquivos temporários, limite de tamanho '/tmp '.
FS-watchdog: alertas para preenchimento de volumes e crescimento inode.

6) Rede e tráfego

NetworkPolicy (ingress/egress) — zero-trust east-west.
Bandwidth limits: tc/egress-policies, QoS/DSCP para fluxos críticos.
Controlador Egress: Lista de domínios/subsetores permitidos, auditoria DNS.
mTLS + TLS policies: criptografia e versão compulsória do protocolo.

7) Segurança do processo

Seccomp (allowlist syscalls), AppArmor/SELinux os perfis.
Drop Linux capabilities (deixar o mínimo), 'runAsNonRoot', 'readOnlyRootFilesystem'.
Contêineres Rootless, imagens assinadas e atestações.
Secret-only via Vault/KMS, tmp-tocens com TTL curto.

8) Políticas de tempo: timeouts, retais, orçamentos

Timeout budet: soma de todos os hop's ≤ SLA-to-end.
Retrai com backoff + jitter, máximo de tentativas por classe de erro.
Circuito-breaker: aberto a um erro %/timeout p95 acima do limite → falhas rápidas.
Bolkheads: conexion-pool 's/filas individuais para caminhos críticos.
Backpressure: restrição de produtores por lag consumidores.

9) Rate-limits, quotas e prioridade

Algoritmos: tocen/leaky bucket, GCRA; locais + distribuídos (Redis/Envoy/global).
Granularidade: chave API/usuário/organização/região/endpoint.
Gradiente de prioridade: fluxo de pagamento/autorreferência - gold, analista - bronze.
Quotas por dia/mês, «burst» e «sustained» limites; 429 + Retry-After.

10) Orquestra e planeador

Proteja os P1 contra a expulsão.
PodDisruptionBudget: limites de downthame nas atualizações.
Taints/Tolerações, (anti) Affinity - isolamento workloads.
RuntimeClass, um gVisor/Firecracker/Wasm de areia.
Horizontal/Vertical autoscaling com liminares de guard e max-replicas.

11) Políticas de dados/ETL/striptease

Concurrency per job/topic, max batch size, checkpoint intervalo.
Consumer lag budgets: warning/critical; DLQ e limite de retais.
Freshness SLA para vitrines, paragem de jobs pesados em picos de tráfego de prod.

12) Policy-as-Code e controle admissional

OPA Gatekeeper/Kyverno: proibição de poda sem requests/limits, sem 'readOnlyRootFilesystem', com 'hostNetwork', 'latest'.
Conftest para inspeções pré-commit Helm/K8s/Terraform.
Mutation policies: sensor automático de sidecar (mTLS), anotações, 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) Observabilidade e métricas de conformidade

Compliance%: proporção de ferramentas com requests corretos/limits/labels.
Segurança Posture: proporção de seccomp/AppArmor/rootless.
Rate-limit hit%, shed%, throttle%, 429 share.
p95 temporizadores/retrações, circuito-open duration.
OOM kills/evictions, CPU throttle seconds.
Network egress denied events, egress allowlist misses.

14) Folhas de cheque

Antes de postar o serviço

• Requerimentos/limits; QoS ≥ Burstable
• Os temporizadores e os retais se encaixam em end-to-end SLA
• Circuito-breaker/bulkhead incluídos para dependências externas
• NetworkPolicy (ingress/egress) и mTLS
• Seccomp/AppArmor, drop capabilities, non-root, read-only FS
• Rate-limits e quotas de entrada/serviço API
• PDB/priority/affinity definidos; autoscaling configurado

Mensalmente

• Auditoria de exceções policy (TTL)
• Revisão dos orçamentos de tempo/erro
• Teste de degradação (fire-drill): shed/backpressure/circuito-breaker
• Rotação de segredos/certificados

15) Anti-pattern

Sem requests/limits: «burst» come os vizinhos → falhas em cascata.
Retraias globais sem jitter, tempestade nas dependências.
Tempo infinito, conectórios «pendurados» e pool esgotado.
': latest' e tags mutável: montagens runtime imprevisíveis.
Egress aberto: fugas e dependências não controladas.
Falta de PDB: atualizações «quebram» todo o pool.

16) Mini playbooks

A. Aumento de CPU throttle% em payments-service

1. Verificar limits/requests e perfilar caminhos quentes.
2. Levantar os requests temporariamente, ativar o scail automático de p95 latency.
3. Incluir os limites/cursos em dinheiro e reduzir a complexidade das consultas.
4. Pós-fix: denormalização/índices, revisão limits.

B. Crescimento 429 e queixas de API

1. Um relatório sobre as chaves/organizações → quem ficou na cota.
2. Digite hierarchical quotas (per- org→per -key), levante burst para gold.
3. Comunicação e orientance por backoff; ativar o adaptativo limiting.

B. OOM kills em massa

1. Reduzir concurrency, incluir limite heap e perfis.
2. Refogue o Xmx/GOMEMLIMIT para um peak-usage real.
3. Reaproveitar GC/pula, adicionar swap-off e soft-limit alerts.

17) Exemplos de configuração

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) Integração com gerenciamento de mudanças e incidentes

Qualquer enfraquecimento da política é através de RFC/FAB e exclusão temporária da TTL.
Incidentes de violação de políticas pós-mortem e renovação de regras.
Os dashboards de conformidade (compliance) estão ligados ao calendário de lançamento.

19) Resultado

As políticas de execução são «corrimões» para a plataforma, não impedem uma viagem rápida, não deixam cair. Restrições declaratórias, coerção automática, boas métricas e disciplina de exceções transformam a operação caótica em um sistema controlado e previsível - com um custo controlado e SLO sustentável.