Tecnologia e Infraestrutura → Kubernetes clusters e Helm charts

Clusters Kubernetes e lista Helm

1) Papel Kubernetes e Helm

Kubernetes é a base da plataforma de aplicativos: normaliza a localização, rede, configs, segredos e auto-definição. Helm é um gerente de pacotes/modelos que transforma manifestos declaratórios em lançamentos repetíveis com gerenciamento de versões e dependências. Juntos, eles oferecem deplois previsíveis, reversões rápidas e uma única linguagem de infraestrutura.

2) Design de cluster

2. 1 Topologia e resistência a falhas

Multi-AZ: controle de plano e nódulos de pool de trabalho distribuídos por zonas; Para ser uniforme.
Multiregião/DR.: clusters independentes per-region; chamadas inter-regionais - apenas por caminhos «frios» (diretórios/telemetria), «quentes» (carteira) - localmente.
«General», «compute», «io», «spot» (para tarefas de fundo) Destino em nodeSelector/affinity/taints.

2. 2 Espaços de nomes e modelo multiuso

Isolamento namespace por domínios/comandos: 'payments', 'wallet', 'games', 'reporting'.
ResourceQuota + LimitRange: limites básicos de CPU/RAM e o máximo de réplicas; Proteja o cluster contra os aspiradores.
RBAC: papéis padrão read-only, write - apenas CI/CD e on-call.

2. 3 Rede

CNI com suporte a NetworkPolicy (Calico/Cilium): L3/L4 política de namespace/label.
Ingresss → Gateway API: mudança para o modelo 'GatewayClass/Gateway/HTTPRoute' para canarinhos e muita tenência.
Serviço Mesh (opcional): mTLS, retry/breaker, locality-aware; Incluir pontualmente para a fiabilidade entre servidores.

3) Confiabilidade e zoom

3. 1 Skeiling

HPA por métricas personalizadas (RPS/latency/queue depth), não apenas CPU.
VPA na classe de fundo das cargas; Em venda, «recepção only» ou em conjunto com HPA em diferentes métricas.
Cluster Autoscaler: node groups individuais para serviços sensíveis; warm-pool para os picos (torneios/jogos).

3. 2 Recursos e QoS

Cada Pod tem requests/limits; evitar «latest» e contêineres «ilimitados».
PriorityClass: Serviços críticos ('wallet', 'payments') suplantam os serviços não críticos.
PDB: Impede o cluster de «atirar no próprio pé» ao atualizar o nó.

3. 3 Atualizações sem interrupções

RollingUpdate c maxUnavailable=0 em caminhos críticos.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Capacidade para lançamentos rápidos durante os picos - com cuidado.

4) Segurança da plataforma

O Pod Security (Baseline/Restricted) no nível namespace; proibição de 'prived', hostPath, root.
NetworkPolicy: default-deny e listas brancas por porte/label.
Seccomp/AppArmor, non-root users, read-only rootfs.
Segredos: KMS/Vault Provedor (CSI), não guardemos segredos em 'values. yaml 'em aberto.
RBAC-mínimo: as contas de serviço são apenas autorizadas; Os tokens são curtos.
Controle Advision: OPA/Gatekeeper/Kyverno - enforce editoras, limites, violações policiais.

5) Observability

OpenTelemetry: Rastreamento do Origins/Gateway → serviço → BD/dinheiro, editoras obrigatórias de 'service', 'version', 'region', 'parceiro', 'api _ versão'.
Logs: estruturados, sem PII/PAN; rotação em armazenamento centralizado.
Métricas: RED/USE, SLO-dashboard, burn-rate alerts.
Sintética: amostras dos países certos/ASN; perímetro e health-checks internos.

6) GitOps и progressive delivery

Argo CD/Flux: estado desejado armazenado em Git; cada namespace é seu próprio repositório/pasta.
Promoção de artefatos: 'dave estágio' por meio de PR, em vez de 'kubectl apply'.
Canary/Blue-Green: Argo Rollouts/Gateway API; métricas de sucesso - P95/P99, erro-rate, negócios-SLI (CR depósitos).
Desvios: em Helm/Argo - por botão; em listas - versões fixas.

7) Helm: melhores práticas

7. 1 Estrutura de elenco

my-service/
Chart. yaml     # name, version (SemVer), appVersion values. yaml # base values (no secrets)
values-prod. yaml # prod overrides (no secrets)
templates/
_helpers. tpl # naming, common deployment templates. yaml service. yaml hpa. yaml pdb. yaml networkpolicy. yaml serviceaccount. yaml ingress_or_gateway. yaml charts/# dependencies (opcional)

• «version» é uma versão do elenco (SemVer), «appVersion» é uma versão do aplicativo (imagem).
• Os nomes de recursos rigorosos são 'se' fullname". kubernetes. io/`.
• Manifestos obrigatórios: Deployment/StatefulSet, Service, ServiceAccount, HPA (se aplicável), PDB, NetworkPolicy.

7. 2 Values-estratégia

Básico 'values. yaml '- incumprimento, sem segredos ou ambientes específicos.
Owerraydes: 'values-\status' prod a..yaml '+ per-region arquivos.
Segredos: SOPS ('values-prod. sops. yaml ') ou injeção Vault via CSI.
Os parâmetros de recursos e amostras estão em values com default «razoável».

7. 3 Dependências e código geral

Bibliotecas de lista compartilhadas para pattern (protes, annotações, NetworkPolicy).
Dependências ('requiments '/' Chart. yaml ') fique com a versão; Evite «colchonetes» profundas.

7. 4 Modelos e Verificações

Use 'required' e 'fail' em '_ helpers. tpl 'para valores críticos.
Validação do esquema values - 'values. schema. json`.
Testes unit da lista - 'helm unittest'; análise estática - kubeconford/kubeval.
A depuração local é 'helm template' + '--values' + 'kubeconorf'.

7. 5 Lançamentos e armazenamento

Bolas de lista em registros de contêineres OCI; tags por SemVer.
Helmfile/`helmfile. d 'para a orquestração de várias marcas.
Artefactos CI: manifestos gerados + lockfile dependências.

8) Exemplo: Deployment (fragmento do modelo Helm)

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "svc. fullname". }}
labels: {{ include "svc. labels". nindent 4 }}
spec:
replicas: {{.Values. replicas      default 3 }}
strategy:
type: RollingUpdate rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{ include "svc. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{ include "svc. selectorLabels". nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}
spec:
serviceAccountName: {{ include "svc. serviceAccountName". }}
securityContext:
runAsNonRoot: true containers:
- name: app image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports:
- name: http containerPort: {{.Values. ports. http }}
resources:
requests:
cpu: {{.Values. resources. requests. cpu }}
memory: {{.Values. resources. requests. memory }}
limits:
cpu: {{.Values. resources. limits. cpu }}
memory: {{.Values. resources. limits. memory }}
readinessProbe:
httpGet:
path: /healthz port: http periodSeconds: 5 envFrom:
- secretRef:
name: {{ include "svc. secretsName". }}

9) Segredos e configurações

Segredos via CSI (Vault/KMS) ou SOPS no repositório Git (chaves GPG/KMS; proibição de 'kubectl edit').
ConfigMap/Secret checksum anotação para o desencadeador de release rolling.
Não armazenar PAN/PII; usar o torneamento.
Sealed Secret é permitido, mas é preferível a SOPS ou CSI direto.

10) Rede e perímetro

Gateway API para routing L7, canarinhos e blue-green; sessões de sticky apenas quando necessário.
mTLS entre os serviços por mesh/sidecar-less (Cilium) - de forma pontual para o núcleo de pagamento.
Egress: lista controlada de nós externos (PSP/KYC), NAT-IP fixo, timeouts e orçamento de retrações.

11) Serviços e dados estateful

Use serviços de nuvem controlados ou operadores (Postgres/MySQL) em clusters individuais para o OLTP-BD.
PVC/CSI com política de snapshots e bacapes; 'PodAntiAffinity' para réplicas.
Para filas/streaming, soluções controladas ou clusters dedicados; em um cluster de anexos «comum» manter o mínimo de status.

12) C/CD linha de montagem (arbitragem)

1. Build & teste → 2) SCA/Lente → 3) Imagem em maiúscula (SBOM, assinatura) →

2. Geração da lista Helm + 'helm unittest' + kubeconch →

3. Descriptação SOPS em um rentame CD → 6) PR em um repositório GitOps →

4. Argo/Flux aplica → 8) Argo Rollouts canary → 9) Auto Veredicto SLO → 10) Promoção/reversão.

13) Métricas de maturidade da plataforma

Proporção de lançamentos por GitOps (objetivo: 100%).
Tempo de abertura (P95) antes de pronto, MTTR retração.
Revestimento Namespace's Pod Security e NetworkPolicy (objetivo: 100%).
% dos serviços com HPA e requests corretos/limits.
% da lista com 'values. schema. json e testes unit.
Incidentes causados por alterações manuais (objetivo: 0).

14) Folha de cheque de implementação

1. Cluster por zona, pool de nós por perfil; PDB/TopologySpreadConstraints.
2. Modelo Namespace, ResourceQuota/LimitRange, RBAC mínimo.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; controle egress e fixação NAT para provedores.
5. Observabilidade: Trailers OTEL, RED/USE, sintético por geo; O SLO-dashboard.
6. GitOps (Argo/Flux), canary/blue-green, automático por métricas.
7. Padrão Helm: estrutura, schema. json, testes, SOPS/Vault, registros OCI.
8. HPA/VPA, Cluster autoscaler, warm-pool para os picos.
9. Operações de dados CSI snapshots, bacapes, operadoras/managed BD.
10. Regularmente DR./chaos-testes e game-days.

15) Anti-pattern

Um cluster gigante para tudo sem isolamento ou quotas.
Contêineres sem limites de recursos, tags 'latest', sem protes.
Segredos em 'values. yaml 'em forma aberta,' kubectl edit 'em venda.
Releituras em frente, edições manuais de manifestos em um cluster vivo.
A falta de segurança é uma rede plana.
Um único sinal HPA geral por CPU para cargas variadas.
Armazenamento do OLTP-BD dentro de um cluster de aplicativos «compartilhados» sem operador e bacapes.

16) Contexto iGaming/fintech: notas práticas

Webhooks: engress/gateway dedicado e egress apertado para PSP; temporizações rigorosas/retrações; um pool de nós separado.
Tráfego VIP: priorização e rotas individuais; PDB e topology spread para estabilidade.
Torneios/picos: warm-pool nós + HPA preditivo; progressão em dinheiro/conexões.
Relatórios/CDC: um cluster/pool separado para garantir que o ETL não afete a proda.
Regulação: logs imutáveis (WORM), tocenização PII, segmentação de redes.

Resultado

Uma plataforma de Kubernetes forte não é um «monte de YAML», mas padrões: isolamento, política de segurança, recursos gerenciáveis, observabilidade e disciplina GitOps. Helm charts - seu contrato de entrega - lançamentos previsíveis, modelos de teste, trabalho seguro com segredos e rebotes simples. Ao fixar esses princípios, receberá clusters que sobrevivem a picos, aceleram lançamentos e suportam as exigências de negócios e reguladores.