Tecnología e Infraestructura → clústeres de Kubernetes y listas de Helm

Clústeres de Kubernetes y listas de ayuda

1) El papel de Kubernetes y Helm

Kubernetes es la base de la plataforma de aplicaciones: estandariza el rodamiento, la red, las confecciones, los secretos y la auto-recuperación. Helm es un gestor de paquetes/plantillas que convierte los manifiestos declarativos en lanzamientos repetibles con control de versiones y dependencias. Juntos, proporcionan predecibles desployas, retrocesos rápidos y un lenguaje de infraestructura unificado.

2) Diseño del clúster

2. 1 Topología y tolerancia a fallas

Multi-AZ: el plan de control y los nodos de grupos de trabajo se distribuyen por zonas; PDB/TopologySpreadConstraints para la uniformidad.
Multirregión/DR: clústeres independientes por región; llamadas interregionales - sólo por vías «frías» (catálogos/telemetría), «calientes» (billetera) - localmente.
Grupos de trabajo por perfiles: 'general', 'compute', 'io', 'spot' (para tareas de fondo). Asignación a través de nodeSelector/affinity/taints.

2. 2 Espacios de nombres y modelo multijugador

Aislamiento de namespace por dominios/comandos: 'payments', 'wallet', 'games', 'reporting'.
ResourceQuota + LimitRange: límites básicos de CPU/RAM y máximo de réplicas; protección del clúster contra «aspiradoras».
RBAC: roles de lectura por defecto, escritura - sólo CI/CD y on-call.

2. 3 Red

CNI con soporte de NetworkPolicy (Calico/Cilium): L3/L4 de políticas sobre namespace/label.
Ingeniería → Gateway API: cambio al modelo 'GatewayClass/Gateway/HTTPoute' para Canarias y mucha tenencia.
Mesh de servicio (opcional): mTLS, retry/breaker, locality-aware; incluir punto a punto para la fiabilidad interservicios.

3) Fiabilidad y escalabilidad

3. 1 Skaling

HPA por métricas personalizadas (RPS/latency/queue depth), no sólo CPU.
VPA en la clase de carga de fondo; en venta - «recommendation only» o en conjunto con HPA según diferentes métricas.
Cluster Autoscaler: grupos de nodo individuales para servicios sensibles; warm-pool a los picos (torneos/partidos).

3. 2 Recursos y QoS

Cada Pod tiene requests/limits; evitar ': latest' y contenedores «ilimitados».
PriorityClass: los servicios críticos ('wallet', 'payments') desplazan a los no críticos.
PDB: no dejamos que el clúster «se dispare en la pierna» cuando se actualiza el nodo.

3. 3 Actualizaciones sin tiempo de inactividad

RollingUpdate c maxUnavailable = 0 en rutas críticas.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Capacidad de Surge para lanzamientos rápidos durante picos - con precaución.

4) Seguridad de la plataforma

Pod Security (Baseline/Restricted) en el nivel namespace; prohibición de 'privileged', hostPath, root.
NetworkPolicy: por default-deny y listas blancas por puerto/etiqueta.
Seccomp/AppArmor, non-root users, read-only rootfs.
Secrets: Proveedor de KMS/Vault (CSI), no guardamos secretos en 'valores. yaml 'en abierto.
RBAC-mínimo: las cuentas de servicio sólo emiten los derechos necesarios; los tokens son de corta vida.
Control de administración: OPA/Gatekeeper/Kyverno - enforce etiquetas, límites, infracciones de política.

5) Observability

OpenTelemetry: tracking de Ingress/Gateway → servicio → BD/caché, etiquetas obligatorias 'service', 'version', 'region', 'partner', 'api _ version'.
Registros: estructurados, sin PII/PAN; enrutamiento a almacenamiento centralizado.
Métricas: alertas RED/USE, SLO-dashboards, burn-rate.
Sintética: muestras de los países deseados/ASN; perímetro y cheques de salud internos.

6) GitOps и progressive delivery

Argo CD/Flux: el estado deseado se almacena en Git; Cada namespace es su propio repositorio/carpeta.
Promoción de artefactos: 'dev → stage → prod' a través de PR, no «kubectl apply».
Canary/Blue-Green: Argo Rollouts/Gateway API; las métricas de éxito son P95/P99, error-rate, SLI de negocios (CR de depósitos).
Giros: en Helm/Argo - en el botón; en las listas - las versiones son fijas.

7) Ayuda: mejores prácticas

7. 1 Estructura de la lista

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' es una versión de la lista (SemVer), 'appVersion' es una versión de la aplicación (imagen).
• Nombres de recursos estrictos: '{{include "svc. fullname".}}' + etiquetas' app. kubernetes. io/`.
• Manifiestos obligatorios: Deployment/StatefulSet, Service, ServiceAccount, HPA (si corresponde), PDB, NetworkPolicy.

7. 2 Values-estrategia

Básico 'valores. yaml' - impagos, sin secretos y entorno-especificidad.
Override: 'values- {stage' prod} .yaml' + archivos por región.
Secretos: SOPS ('valores-prod. sops. yaml ') o inyección de Vault a través de CSI.
Los parámetros de recursos y muestras están en valores con impagos «razonables».

7. 3 Dependencias y código común

Listas de bibliotecas compartidas para patrones (probes, annotations, NetworkPolicy).
Dependencias ('requirements '/' Chart. yaml ') fijar por versión; evite las «matreshkas» profundas.

7. 4 Plantillas y validación

Utilice 'required' y 'fail' en '_ helpers'. tpl 'para valores críticos.
Validación del esquema values - 'valores. schema. json`.
Las pruebas unitarias de la lista son 'helm unittest'; análisis estático - kubeconform/kubeval.
La depuración local es 'helm template' + '--values' + 'kubeconform'.

7. 5 Lanzamientos y almacenamiento

Push Chart en los registros de OCI de contenedores; etiquetas por SemVer.
Helmfile/`helmfile. d 'para orquestar divisiones multichart.
Artefactos CI: manifiestos generados + lockfile de dependencias.

8) Ejemplo: Deployment (fragmento de plantilla 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) Secretos y configuraciones

Secrets a través de CSI (Vault/KMS) o SOPS en el repositorio Git (claves GPG/KMS; prohibición de 'kubectl edit').
ConfigMap/Secret checksum anotaciones para el disparador de lanzamiento de rolling.
No almacenar PAN/PII; utilizar la tokenización.
Secrets sellados están permitidos, pero son preferibles a SOPS o CSI directo.

10) Red y perímetro

Gateway API para L7 routing, canarios y blue-green; sesiones sticky sólo cuando sea necesario.
mTLS entre servicios a través de mesh/sidecar-less (Cilium) - punto para el núcleo de pago.
Egress: lista controlada de nodos externos (PSP/KYC), NAT-IP fijo, temporizadores y presupuesto de retrés.

11) Servicios y datos de Stateful

Para OLTP-DB, utilice servicios de nube administrados o operadores (Postgres/MySQL) en clústeres individuales.
PVC/CSI con política de snapshots y backups; 'PodAntiAffinity' para réplicas.
Para colas/streaming: soluciones administradas o clústeres dedicados; en un clúster de aplicaciones «general», mantener un mínimo de estado.

12) CI/CD transportador (referencia)

1. Build & test → 2) SCA/lint → 3) Imagen en registro (SBOM, firma) →

2. Generación de Helm-chart + 'helm unittest' + kubeconform →

3. SOPS-decript en el CD rantime → 6) PR en el repositorio GitOps →

4. Argo/Flux aplica → 8) Argo Rollouts canario → 9) Auto veredicto por SLO → 10) Promoción/retroceso.

13) Métricas de madurez de plataforma

Porcentaje de lanzamientos a través de GitOps (objetivo: 100%).
Tiempo de laminación (P95) antes de la preparación, reversión MTTR.
Cobertura de Namespace's Pod Security y NetworkPolicy (objetivo: 100%).
% de los servicios con HPA y requests/limits correctos.
% de la lista con 'valores. schema. json 'y pruebas de unidad.
Incidentes causados por cambios «manuales» (objetivo: 0).

14) Lista de verificación de implementación

1. Clústeres por zona, grupo de nodos por perfil; PDB/TopologySpreadConstraints.
2. Modelo Namespace, ResourceQuota/LimitRange, RBAC mínimo.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; el control egress y la fijación NAT a los proveedores.
5. Observabilidad: Tracks OTel, RED/USE, sintéticos geo; SLO-dashboards.
6. GitOps (Argo/Flux), canario/azul-verde, promoción automática por métricas.
7. Estándares Helm: estructura, schema. json, pruebas, SOPS/Vault, registros OCI.
8. HPA/VPA, Cluster Autoscaler, warm-pool a los picos.
9. Operaciones de datos: snapshots CSI, backups, operadores/managed DB.
10. Pruebas regulares de DR/chaos y días de juego.

15) Anti-patrones

Un clúster «gigante» para todo sin aislamiento ni cuotas.
Contenedores sin restricciones de recursos, etiquetas 'latest', sin probes.
Secretos en 'valores. yaml 'en abierto,' kubectl edit 'en venta.
Lanzamientos cerca de GitOps, edición manual de manifiestos en un clúster en vivo.
La ausencia de NetworkPolicy/Pod Security es una red «plana».
Una sola señal HPA común por CPU para cargas de varios tipos.
Almacenar una BD OLTP dentro de un clúster de aplicaciones «compartido» sin operador ni respaldo.

16) Contexto iGaming/Fintech: notas prácticas

Webhooks de pago: dedicado ingress/gateway y estrecho egress a PSP; temporizadores/retraídos estrictos; una agrupación de nodos separada.
Tráfico VIP: priorización y rutas individuales; PDB y topology spread para la estabilidad.
Torneos/picos: warm-pool nodos + HPA predictivo; calentamiento de cachés/conexiones.
Informes/CDC: un clúster/grupo separado para que la ETL no afecte al plug-in.
Regulación: registros inmutables (WORM), tokenización PII, segmentación de redes.

Resultado

Una plataforma Kubernetes fuerte no es una «pila YAML», sino estándares: aislamiento, política de seguridad, recursos gestionados, observabilidad y disciplina GitOps. Las listas de ayuda son su contrato de suministro: lanzamientos predecibles, plantillas probadas, trabajo seguro con secretos y revisiones simples. Al consolidar estos principios, obtendrá clústeres que experimentan picos, aceleran las liberaciones y resisten los requerimientos del negocio y los reguladores.