GH GambleHub

Containerización y orquestación

1) Por qué contenedores y k8s en iGaming

Velocidad de cambio: imágenes predecibles, una sola pipeline CI/CD.
Estabilidad: auto-reinicio, skale horizontal, self hiling.
Aislamiento de Datos/Regiones: No contextos/clústeres bajo jurisdicción.
Estándares operativos: políticas de recursos, registro único/métricas/tracks.

Cuando no sea necesario: equipo pequeño, 2-3 servicios, lanzamientos raros - comience con PaaS/monolito modular.

2) Imágenes y registros (OCI/Docker)

2. 1 Conjunto de imágenes - Principios

Multi-stage: build → rantime (imágenes de base delgada 'distroless', 'alpine' con precaución).
Repetibilidad: captura las versiones/sha256, 'COPY --chown', '--mount = type = cache' en BuildKit.
SBOM y firma: 'cosign sign/verify', 'slsa provence', política 'sólo firmada'.
Slim-down: elimina dev-tools, activa 'USER nonroot', 'readOnlyRootFilesystem'.

Ejemplo de Dockerfile (Node. js)

dockerfile build
FROM node:22-bookworm AS build
WORKDIR /app
COPY package. json./
RUN npm ci --omit=dev
COPY..
RUN npm run build

runtime (distroless)
FROM gcr. io/distroless/nodejs22
WORKDIR /srv
COPY --from=build /app/dist./dist
COPY --from=build /app/node_modules./node_modules
USER 10001
ENV NODE_ENV=production
CMD ["dist/server. js"]

2. 2 Registros y políticas

Registro privado + réplicas geo (EU/NA) para reducir la latencia y el cumplimiento del RGPD.
Retention/immutability: prohibición de sobrescribir etiquetas, calentamiento de caché en PoP.
Control de administración: sólo imágenes firmadas/escaneadas (cosign + Trivy/Grype).

3) Orquestación: patrones básicos de Kubernetes

3. 1 Primitivos

Deployment - Servicios estateless (lobby, API).
StatefulSet: monedero/colas/almacenes (nombre de archivo, volúmenes estables).
DaemonSet: agentes de registro/componentes de red.
Job/CronJob - migraciones, informes, ETL.

3. 2 Recursos y QoS

Especifique 'requests/limits' (CPU/Memory) → clases de QoS y planificación predecible.
Burstable sólo donde es consciente; crítico - Guaranteed.
Los PODs de pago críticos se colocan en grupos dedicados (taints/tolerations, node-affinity).

3. 3 Sostenibilidad y lanzamientos

Probes: 'startup', 'liveness', 'readiness' (con tiempos y períodos).
Rollout: `maxSurge/maxUnavailable`, canary через вес в Ingress/Gateway/Service Mesh.
PDB (PodDisruptionBudget) + graceful shutdown (PreStop hook, `terminationGracePeriodSeconds`).
Drain/cordon nod en actualizaciones.

4) Red: CNI, servicios, tráfico de entrada

4. 1 capa CNI

Calico/Cilium/Weave - Política de red (NetworkPolicy), eBPF para el rendimiento.
Reglas interneo-espaciales: egresos/ingresos mínimos necesarios.

4. 2 Servicios y entrada

Service: `ClusterIP/NodePort/LoadBalancer`.
Ingress o Gateway API para L7: rutas en ruta/header/host, TLS, pesos canarios.
mTLS dentro del clúster: a través del servicio mesh (Istio/Linkerd) - intercepción de TLS y políticas.

Ejemplo HTTPoute (API de Gateway, peso canario)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- backendRefs:
- name: lobby-v1 weight: 90 port: 8080
- name: lobby-v2 weight: 10 port: 8080

5) Almacenamiento: CSI/PV/PVC, clases de volúmenes

Controladores CSI del proveedor (EBS/PD/SSD Premium) + 'storageClass' con parámetros de rendimiento.
RWX para sharing (NFS/FSx/Filestore) - cuidado con los bloqueos.
Backup/restore: Velero/Kasten, snapshots periódicos, verificación de recuperación.
Cifrado: a nivel de disco y a nivel de BD (KMS).

6) Escala automática: HPA/VPA/KEDA

HPA (por CPU/RAM/métricas personalizadas - RPS, p95): para API/lobby.
VPA (recomendaciones/auto) - para workers estables.
KEDA (event-driven) - Escala de las colas Kafka/SQS/Redis, Cron-shedules.
Cluster Autoscaler: nodos de carga; pools warm para picos (torneos/streams).

7) Servicio de mesh (según sea necesario)

mTLS/Políticas de servis↔servis, Autorización de Identidad (SPIFFE).
Circuit-breaker/timeout/retry, outlier-ejection, espejado (shadow).
Tele-métrica fuera de la caja: métricas y pistas uniformes.
Use donde necesite administración de tráfico sutil (pagos, proveedores de juegos).

8) Seguridad: secretos, política, cumplimiento

Secretos: administrador externo (AWS/GCP/Azure KMS, Secrets externos), rotación.
Policy-as-code: OPA/Gatekeeper/Kyverno - prohibición ': latest', root-USER, hostPath, privilegios.
Derechos de escalamiento: Namespaces + RBAC, división Dev/Stage/Prod, auditoría.
Seguridad de imagen: escaneado en CI/CD, firma (cosign), admision por firma.
mTLS y JWT en el interior (mesh), WAF/Rate-limit en la entrada (Ingress/Gateway).

9) Observabilidad y SLO

Metrics: Prometheus/OpenTelemetry, p50/95/99, 4xx/5xx, saturations.
Logs: JSON estructural → Loki/Elastic, enmascaramiento PII/PAN/IBAN.
Traces: OTLP → Tempo/Jaeger; 'trace _ id' va de gateway.
SLO: por ejemplo, 'Depósito p95 ≤ 300 ms, éxito ≥ 98. 5% ', alertas burn-rate.
Proactividad: dashboards per-service/per-route, watchdog por DLQ y lags de colas.

10) CI/CD, Helm, GitOps

CI: linternas, pruebas (unidad/contrato/integración), SAST/DAST, SBOM.
Helm/Jsonnet/Kustomize: listas declarativas con 'valores.' en los alrededores.
GitOps (ArgoCD/Flux): un solo source-of-truth, un rugido PR de manifiestos, un botón rollback.
Estrategias: azul-verde, canario, sombreado; migraciones de esquemas - expand-and-contract.

Fragmento de valores. yaml (recursos/muestras)

yaml resources:
requests: { cpu: "200m", memory: "256Mi" }
limits:  { cpu: "500m", memory: "512Mi" }
livenessProbe: { httpGet: { path: /healthz, port: 8080 }, initialDelaySeconds: 20, periodSeconds: 10 }
readinessProbe: { httpGet: { path: /readyz, port: 8080 }, initialDelaySeconds: 5, periodSeconds: 5 }

11) Planificación y aislamiento

NodePools: separe los pagos/la cartera en nodos de «bajo ruido» con un disco rápido.
Taints/Tolerations: pools protegidos para cargas críticas.
(Anti-) Affinity: desenfoque las réplicas por zonas/nodos (HA).
ResourceQuota/LimitRange para los terceros - protección contra «vecinos ruidosos».

12) Multiclaster, multi-región, DR

División por jurisdicciones: agrupaciones UE/LatAm/ROW; Los datos de los residentes son locales.
GSLB/Anycast en la entrada, pere-clost-observabilidad y alertas.

Niveles de DR:
  • Warm standby (recomendado): réplica sinh de BD críticos, comprobaciones periódicas de failover.
  • Active-active para lectura/enrutamiento regional.
  • Redundancia: backups (Velero), restore rehearsal.

13) iGaming-especificidad

Pagos/billetera: p95 ≤ 300-500 ms, grupos separados y PDB estrictos; canary 1→5→10%.
Lobby/contenido: HPA agresivo por RPS/INP, imágenes calientes/caché vectorial.
Juegos en vivo/streams: LC/mínimo retraídas, timeouts largos de socket, sticky por conexión.
Compliance: Neymspace con Política rígida, secretos a través de KMS, auditoría de cambios en los lanzamientos de Helm.
Juego responsable: servicio de límites/bloqueos - tráfico prioritario (fail-open/close por política).

14) Hojas de cheques

Antes de poner el servicio

  • Imagen de escenario múltiple, USUARIO nonroot, firma cosign, escaneado.
  • Requests/limits, probes, env/secret de un gestor externo.
  • PDB, `maxUnavailable ≤ 1`, graceful shutdown.
  • SLO/alertas, seguimiento desde la pasarela hasta la base de datos.
  • Esquema canario y plan de retroceso.
  • Las políticas OPA/Kyverno pasan (no root, no hostPath, no: latest).

Clúster/plataforma

  • CNI y NetworkPolicy están incluidos; mTLS (mecha) donde sea necesario.
  • StorageClass/Reten, back-up/restore verificados.
  • HPA/VPA/KEDA están configurados; Cluster Autoscaler и warm-pool.
  • RBAC mínimo, auditoría habilitada, secretos - de KMS.
  • GitOps: listas/manifiestos en el repositorio, la revisión de PR es obligatoria.

15) Anti-patrones

Imágenes 'latest', usuario raíz, capas base 'gruesa'.
No hay 'requests/limits' → eviction/trottling.
Readiness = liveness (restarts de flaping).
Mezcla de stateful/stateless en una piscina sin taints.
Migraciones de esquemas «de frente» sin expand-and-contract.
El único clúster «a todos los mercados» sin aislamiento regional.
Registros con PII/PAN, secretos en ConfigMap.
La ausencia de PDB/Dranage → acantilados en los picos y en las actualizaciones.

16) Métricas de plataforma (mínimo)

Кластер: CPU/mem requests vs allocatable, pod-churn, node-pressure.
Red: p95 per-route, 4xx/5xx, reset/timeout, retry-rate, errores mTLS.
Almacenamiento: IOPS/latency, queue-depth, errores CSI.
Auto Scale: HPA decisions, CA events, tiempo de calentamiento.
Negocios: TTP, TtW, FTD-éxito, pagos fallidos del proveedor.
Seguridad: inconsistencias de OPA, imágenes no firmadas, secretos caducados.

17) Ejemplos de manifiestos

Deployment (API, etiqueta canaria)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: wallet-api, labels: { app: wallet, track: stable } }
spec:
replicas: 4 strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 1 } }
selector: { matchLabels: { app: wallet, track: stable } }
template:
metadata: { labels: { app: wallet, track: stable } }
spec:
serviceAccountName: wallet-sa containers:
- name: api image: registry. local/wallet/api@sha256:...
ports: [{ containerPort: 8080 }]
resources:
requests: { cpu: "250m", memory: "256Mi" }
limits:  { cpu: "500m", memory: "512Mi" }
readinessProbe: { httpGet: { path: /readyz, port: 8080 }, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /healthz, port: 8080 }, initialDelaySeconds: 20 }
securityContext:
runAsNonRoot: true readOnlyRootFilesystem: true

PDB (cartera)

yaml apiVersion: policy/v1 kind: PodDisruptionBudget spec:
minAvailable: 3 selector: { matchLabels: { app: wallet } }

HPA (por RPS a través de metrics personalizados)

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
minReplicas: 4 maxReplicas: 40 metrics:
- type: Pods pods:
metric:
name: http_requests_per_second target:
type: AverageValue averageValue: "50"

18) Proceso de implementación (por sprints)

1. Construcción y seguridad de imágenes: multi-stage, SBOM, firmas, política de administración.
2. Plataforma base k8s: CNI, Ingress/Gateway, monitoreo/logs/tracks, StorageClass.
3. CI/CD y GitOps: listas de ayuda, entornos, canario/rollback, migración de circuitos.
4. Skale y sostenibilidad: HPA/VPA/KEDA, PDB, node pools, taints/affinity, plan DR.

Parche final

Imágenes delgadas y firmadas + política de tolerancia = base de seguridad.
Muestras, recursos, PDB, drain = sostenibilidad de lanzamientos.
HPA/VPA/KEDA + afinación de agrupaciones = escala sin «reducciones».
Gateway/Ingress + mTLS/OPA = perímetro seguro y comunicación interna.
Observabilidad + SLO + GitOps = cambios gestionados.
Aislamiento regional y DR = cumplimiento y tolerancia a fallas.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.