GH GambleHub

Containerisierung und Orchestrierung

1) Warum Container und K8s in iGaming

Änderungsrate: vorhersagbare Bilder, eine einzige CI/CD-Pipeline.
Nachhaltigkeit: Auto-Neustarts, Horizontal-Scale, Self-Healing.
Isolierung von Daten/Regionen: Neymspaces/Cluster unter Jurisdiktion.
Betriebsstandards: Ressourcenrichtlinien, einheitliches Protokoll/Metriken/Traces.

Wenn es nicht nötig ist: kleines Team, 2-3 Services, seltene Releases - Start mit PaaS/modularem Monolith.

2) Bilder und Register (OCI/Docker)

2. 1 Bildmontage - Prinzipien

Multi-Stage: Build → Rantime (subtile Grundbilder von 'Distroless', 'Alpine' mit Vorsicht).
Wiederholbarkeit: fix Versionen/sha256, 'COPY --chown', '--mount = type = cache' im BuildKit.
SBOM und Unterschrift: 'cosign sign/verify', 'slsa provenance', Richtlinie' nur unterzeichnet'.
Slim-down: dev-tools entfernen, 'USER nonroot', 'readOnlyRootFilesystem' einschalten.

Beispiel 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 Register und Richtlinien

Private Registry + Geo-Repliken (EU/NA) zur Verringerung der Latenz und Einhaltung der DSGVO.
Retention/immutability: Verhindert das Überschreiben von Tags durch Aufwärmen des Cache im PoP.
Admission-Control: nur signierte/scanfreie Images (cosign + Trivy/Grype).

3) Orchestrierung: Kubernetes Grundmuster

3. 1 Primitive

Deployment - stateless-Dienste (Lobby, API).
StatefulSet - Wallet/Queues/Storage (Fix-Name, stabile Volumes).
DaemonSet - Logagenten/Netzwerkkomponenten.
Job/CronJob - Migrationen, Berichte, ETL.

3. 2 Ressourcen und QoS

Geben Sie' requests/limits' (CPU/Memory) → QoS-Klassen und vorhersagbare Planung an.
Burstable nur dort, wo es bewusst ist; kritisch - garantiert.
Kritische Payment PODs auf dedizierten Pools platzieren (Taints/Tolerations, Node-Affinity).

3. 3 Nachhaltigkeit und Freigaben

Probes: 'startup', 'liveness', 'readiness' (mit Timeouts und Perioden).
Rollout: `maxSurge/maxUnavailable`, canary через вес в Ingress/Gateway/Service Mesh.
PDB (PodDisruptionBudget) + graceful shutdown (PreStop hook, `terminationGracePeriodSeconds`).
Drain/Cordon Nod bei Upgrades.

4) Netzwerk: CNI, Dienste, Eingangsverkehr

4. 1 CNI-Schicht

Calico/Cilium/Weave - Netzwerkrichtlinie (NetworkPolicy), eBPF für Leistung.
Internamespace-Regeln: Minimal notwendige egress/ingress.

4. 2 Dienste und Eingang

Service: `ClusterIP/NodePort/LoadBalancer`.
Ingress oder Gateway API für L7: Routen auf Pfad/Header/Host, TLS, Kanariengewichte.
mTLS innerhalb des Clusters: über Service Mesh (Istio/Linkerd) - Abfangen von TLS und Richtlinien.

Beispiel HTTPRoute (Gateway API, Kanariengewicht)

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) Speicher: CSI/PV/PVC, Volumenklassen

CSI-Treiber des Anbieters (EBS/PD/Premium SSD) + 'storageClass' mit Leistungsparametern.
RWX für Sharing (NFS/FSx/Filestore) - Vorsicht bei Sperren.
Backup/restore: Velero/Kasten, periodische Schnappschüsse, Wiederherstellungsprüfung.
Verschlüsselung: auf Festplattenebene und auf DB-Ebene (KMS).

6) Auto-Skalierung: HPA/VPA/KEDA

HPA (durch CPU/RAM/kundenspezifische Metriken - RPS, p95): für API/Lobby.
VPA (Empfehlungen/Auto) - für stabile Worker.
KEDA (event-driven) - Skalierung nach Kafka/SQS/Redis Warteschlangen, Cron-Schedula.
Cluster Autoscaler - Knoten nach Last; Warm-Pools für Peaks (Turniere/Streams).

7) Service-Mesh (bei Bedarf)

mTLS/ servis↔servis-Richtlinien, Identitätsautorisierung (SPIFFE).
Circuit-breaker/timeout/retry, outlier-ejection, Spiegelung (Schatten).
Tele-Metrie aus der Box: einheitliche Metriken und Tracks.
Verwenden Sie dort, wo Sie ein schlankes Traffic-Management benötigen (Zahlungen, Spieleanbieter).

8) Sicherheit: Geheimnisse, Politik, Compliance

Geheimnisse: Externer Manager (AWS/GCP/Azure KMS, Externe Geheimnisse), Rotation.
Policy-as-code: OPA/Gatekeeper/Kyverno - Verbot von': latest', root-USER, hostPath, Privilegien.
Eskalation der Rechte: Namespaces + RBAC, Trennung Dev/Stage/Prod, Audit.
Bildsicherheit: Scan in CI/CD, Signieren (cosign), Admission per Signatur.
mTLS und JWT im Inneren (Mesh), WAF/Rate-Limit am Eingang (Ingress/Gateway).

9) Beobachtbarkeit und SLO

Metrics: Prometheus/OpenTelemetry, p50/95/99, 4xx/5xx, saturations.
Logs: Strukturelles JSON → Loki/Elastic, PII/PAN/IBAN Masking.
Traces: OTLP → Tempo/Jaeger; 'trace _ id' kommt vom Gateway.
SLO: z.B. 'Deposit p95 ≤ 300 ms, Erfolg ≥ 98. 5%', Alert Burn-Rate.
Proaktiv: Per-Service/Per-Route-Dashboards, DLQ-Watchdog und Warteschlangenverzögerungen.

10) CI/CD, Helm, GitOps

CI: Linter, Tests (Einheit/Vertrag/Integration), SAST/DAST, SBOM.
Helm/Jsonnet/Kustomize: deklarative Charts mit 'Werten' auf der Umgebung.
GitOps (ArgoCD/Flux): Single-Source-of-Truth, PR-Revue der Manifeste, Rollback-Button.
Strategien: blau-grün, kanarisch, Schatten; Schemamigrationen - expand-and-contract.

Fragment von Werten. yaml (Ressourcen/Proben)

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) Planung und Isolation

NodePools: Trennen Sie Zahlungen/Wallet auf „Low-Noise“ Knoten mit einem schnellen Laufwerk.
Taints/Tolerations: geschützte Pools für kritische Lasten.
(Anti-) Affinität: Verwischen Sie Replikate nach Zonen/Knoten (HA).
ResourceQuota/LimitRange auf Nijmspaces - Schutz vor „lauten Nachbarn“.

12) Multicluster, Multiregion, DR

Aufteilung nach Jurisdiktionen: EU/LatAm/ROW-Cluster; Daten der Bewohner - lokal.
GSLB/Anycast am Eingang, Per-Clast-Observability und Alerts.

DR-Ebenen:
  • Warm standby (empfohlen): Synh-Replik kritischer DBs, periodische Failover-Prüfungen.
  • Aktiv-aktiv für Lesungen/regionales Routing.
  • Reservierung: Sicherungen (Velero), rehearsal Wiederherstellung.

13) iGaming-Spezifität

Zahlungen/Wallet: p95 ≤ 300-500 ms, separate Pools und strenge PDBs; canary 1→5→10%.
Lobby/Inhalt: Aggressive HPA durch RPS/INP, erwärmte Bilder/Vektorcache.
Live-Spiele/Streams: LC/Minimum Retrays, lange Socket-Timeouts, Sticky auf Verbindung.
Compliance: Neuspaces mit harten Richtlinien, Secrets via KMS, Audit von Helm-Releases-Änderungen.
Verantwortungsvolles Spielen: Limit/Lock-Service - Priority Traffic (Fail-Open/Close nach Richtlinie).

14) Checklisten

Vor dem Service

  • Multi-stage image, USER nonroot, Signatur cosign, Scan bestanden.
  • Requests/limits, probes, env/secret von einem externen Manager.
  • PDB, `maxUnavailable ≤ 1`, graceful shutdown.
  • SLO/Warnmeldungen, Trace von Gateway zu DB.
  • Kanarienschema und Rollback-Plan.
  • OPA/Kyverno-Richtlinien werden verabschiedet (kein root, kein hostPath, kein: letzter).

Cluster/Plattform

  • CNI und NetworkPolicy enthalten; mTLS (Mesh) wo benötigt.
  • StorageClass/retention, backup/restore geprüft.
  • HPA/VPA/KEDA konfiguriert; Cluster Autoscaler и warm-pool.
  • Der RBAC ist minimal, das Audit ist aktiviert, die Geheimnisse sind aus dem KMS.
  • GitOps: Charts/Manifeste im Repository, PR-Review ist Pflicht.

15) Anti-Muster

„Neueste“ Bilder, Root-Benutzer, „dicke“ Basisebenen.
Es gibt keine' requests/limits' → eviction/trottling.
Bereitschaft = Lebendigkeit (flapende Restarts).
Mischen von Stateful/Stateless auf einem Pool ohne Taints.
Migrationen von Schemata „frontal“ ohne Expand-and-Contract.
Das einzige Cluster „für alle Märkte“ ohne regionale Isolation.
Logs mit PII/PAN, Geheimnisse in ConfigMap.
Das Fehlen von PDB/Drainage → Brüche in Peaks und Upgrades.

16) Plattform-Metriken (Minimum)

Кластер: CPU/mem requests vs allocatable, pod-churn, node-pressure.
Netzwerk: p95 per-route, 4xx/5xx, reset/timeout, retry-rate, mTLS-Fehler.
Speicher: IOPS/Latenz, Queue-Tiefe, CSI-Fehler.
Autoscale: HPA-Entscheidungen, CA-Ereignisse, Aufwärmzeit.
Geschäft: TTP, TtW, FTD-Erfolg, Ausfall von Zahlungen nach Anbieter.
Sicherheit: OPA-Inkonsistenzen, nicht signierte Bilder, abgelaufene Geheimnisse.

17) Beispiele für Manifeste

Deployment (API, Kanarienzeichen)

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 (Wallet)

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

HPA (per RPS über custom-metrics)

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) Umsetzungsprozess (nach Sprints)

1. Image-Build und Sicherheit: Multi-Stage, SBOM, Signaturen, Admission-Richtlinie.
2. k8s Basisplattform: CNI, Ingress/Gateway, Monitoring/Logs/Trails, StorageClass.
3. CI/CD und GitOps: Helm-Charts, Environments, Canary/Rollback, Schemamigrationen.
4. Scale und Nachhaltigkeit: HPA/VPA/KEDA, PDB, Node-Pools, Taints/Affinity, DR-Plan.

Abschließender Spickzettel

Subtile, signierte Bilder + Zulassungspolitik = Sicherheitsgrundlage.
Proben, Ressourcen, PDB, drain = Nachhaltigkeit von Releases.
HPA/VPA/KEDA + Tuning Pools = Skala ohne „Drawdowns“.
Gateway/Ingress + mTLS/OPA = sicherer Perimeter und interne Kommunikation.
Observability + SLO + GitOps = gesteuerte Änderungen.
Regionale Isolation und DR = Compliance und Fehlertoleranz.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.