GH GambleHub

კონტეინერი და ორკესტრი

1) რატომ კონტეინერები და k8s iGaming- ში

ცვლილებების სიჩქარე: პროგნოზირებადი გამოსახულებები, ერთი pline CI/CD.
სტაბილურობა: გადატვირთვა, ჰორიზონტალური სკეიტი, სელფი.
მონაცემთა/რეგიონების იზოლაცია: ნეიმსპასი/მტევანი იურისდიქციის ქვეშ.
ოპერაციული სტანდარტები: რესურსების პოლიტიკა, ერთი ჟურნალი/მეტრიკა/ტრეისი.

როდესაც არ გჭირდებათ: პატარა გუნდი, 2-3 მომსახურება, იშვიათი გამოშვებები - დაიწყეთ PaaS/მოდულური მონოლითიდან.

2) სურათები და რეესტრები (OCI/Docker)

2. 1 სურათების შეკრება - პრინციპები

Multi-stage: ბილეთი rantime (თხელი ძირითადი სურათები 'distroless', 'alpine' სიფრთხილით).
განმეორება: ჩაწერეთ ვერსიები/sha256, 'COPY --chown', '-mount = ტიპი = cache' BuildKit- ში.
SBOM და ხელმოწერა: 'cosign sign/verify', 'slsa provenance', პოლიტიკა „მხოლოდ ხელმოწერილი“.
Slim-down: წაშალეთ dev-tools, ჩართეთ 'USER nonroot', 'readOnlyRootFilesystem'.

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 რეესტრები და პოლიტიკოსები

პირადი რეგისტრის + გეო რეპლიკები (EU/NA) ლატენტობის შესამცირებლად და GDPR შესაბამისობის შესამცირებლად.
Retention/immutability: აკრძალვა ტეგების გადაწერა, PoP- ში ქეში დათბობა.
ადმისიის კონტროლი: მხოლოდ ხელმოწერილი/სკანირების სუფთა სურათები (cosign + Trivy/Grype).

3) ორკესტრი: ძირითადი ნიმუშები Kubernetes

3. 1 პრიმიტივები

დეპოზიტი - სტატუსის სერვისები (ლობი, API).
StatefulSet - საფულე/ხაზი/საცავი (ფიქსირებული სახელი, სტაბილური ტომი).
DaemonSet არის ლოგოების/ქსელის კომპონენტების აგენტები.
Job/CronJob - მიგრაცია, მოხსენებები, ETL.

3. 2 რესურსები და QoS

მიუთითეთ 'requests/limits' (CPU/Memory) QoS კლასები და პროგნოზირებადი დაგეგმვა.
Burstable მხოლოდ იქ, სადაც ის შეგნებულია; კრიტიკული - Guaranteed.
მოათავსეთ კრიტიკული გადახდის POD- ები გამოყოფილი აუზებისთვის (taints/tolerations, node-affinity).

3. 3 სტაბილურობა და გამოშვებები

Probes: 'startup', 'liveness', 'readiness' (ტაიმაუტებითა და პერიოდებით).
Rollout: `maxSurge/maxUnavailable`, canary через вес в Ingress/Gateway/Service Mesh.
PDB (PodDisruptionBudget) + graceful shutdown (PreStop hook, `terminationGracePeriodSeconds`).
Drain/cordon nod განახლება.

4) ქსელი: CNI, მომსახურება, შეყვანის ტრაფიკი

4. 1 CNI ფენა

Calico/Cilium/Weave - ქსელის პოლიტიკა (ქსელის პოლიტიკა), eBPF პროდუქტიულობისთვის.
interneimspase წესები: მინიმალური აუცილებელი egress/ingress.

4. 2 მომსახურება და შესასვლელი

Service: `ClusterIP/NodePort/LoadBalancer`.
Ingress ან Gateway API L7- ისთვის: მარშრუტები გზის გასწვრივ/ჰედერი/მასპინძელი, TLS, კანარის წონა.
mTLS კლასტერის შიგნით: მესის სერვისის საშუალებით (Istio/Linkerd) - TLS და პოლიტიკის ჩარევა.

მაგალითი HTTPRoote (Gateway API, კანარის წონა)

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) შენახვა: CSI/PV/PVC, ტომების კლასები

CSI პროვაიდერის დრაივერები (EBS/PD/Premium SSD) + 'storageClass' შესრულების პარამეტრებით.
RWX Sharing (NFS/FSx/Filestore) - ფრთხილად საკეტებით.
Backup/restore: Velero/Kasten, პერიოდული Snapshots, აღდგენის შემოწმება.
დაშიფვრა: დისკის დონეზე და BD დონეზე (KMS).

6) მანქანის სკალირება: HPA/VPA/KEDA

HPA (CPU/RAM/კასტომის მეტრიკის მიხედვით - RPS, p95): API/ლობისთვის.
VPA (რეკომენდაციები/მანქანები) - სტაბილური ვორკერებისთვის.
KEDA (event-driven) - მასშტაბები Kafka/SQS/Redis- ის რიგებში, Cron Chedis.
Cluster Autoscaler - დატვირთული კვანძები; warm აუზები მწვერვალებისთვის (ტურნირები/ნაკადები).

7) მომსახურება-მესა (საჭიროების შემთხვევაში)

mTLS/პოლიტიკის მომსახურება - მომსახურება, პირადობის მოწმობა (SPIFFE).
Circuit-breaker/timeout/retry, outlier-ejection, მარცვლეული (shadow).
ყუთიდან სატელევიზიო მეტრია: ერთი მეტრიკა და ბილიკები.
გამოიყენეთ იქ, სადაც საჭიროა თხელი ტრაფიკის მენეჯმენტი (გადახდები, თამაშების პროვაიდერები).

8) უსაფრთხოება: საიდუმლოებები, პოლიტიკა, შესაბამისობა

საიდუმლოებები: გარე მენეჯერი (AWS/GCP/Azure KMS, External Secrets), როტაცია.
Policy-as-code: OPA/Gatekeeper/Kyverno - აკრძალვა ': latest', root-USER, hostPath, პრივილეგიები.
უფლებების ესკალაცია: Namespaces + RBAC, Dev/Stage/Stage გამიჯვნა, აუდიტი.
სურათის უსაფრთხოება: სკანი CI/CD- ში, ხელმოწერა (კოდი), ხელმოწერის განყოფილება.
MTLS და JWT შიგნით (mesh), WAF/Rate-limit შესასვლელში (Ingress/Gateway).

9) დაკვირვება და SLO

Metrics: Prometheus/OpenTelemetry, p50/95/99, 4xx/5xx, saturations.
ლოგები: სტრუქტურული JSON - Loki/Elastic, შენიღბვა PII/PAN/IBAN.
Traces: OTLP - Tempo/Jaeger; 'trace _ id' მოდის კარიბჭედან.
SLO: მაგალითად, 'Deposit p95-300 ms, success - 98. 5% ', burn-rate ალერტები.
პროაქტიულობა: dashbords per service/per-route, watchdog DLQ- ზე და რიგების ლაგამი.

10) CI/CD, Helm, GitOps

CI: ლინტერი, ტესტები (unit/contract/integration), SAST/DAST, SBOM.
Helm/Jsonnet/Kustomize: დეკლარაციული ჩარტები 'values.' გარემოთი.
GitOps (ArgoCD/Flux): single-source-of-truth, მანიფესტების PR მიმოხილვა, rollback ღილაკი.
სტრატეგიები: ცისფერი მწვანე, კანარი, shadow; სქემების მიგრაცია - გაფართოება და კონტრაქტი.

ფრაგმენტი values. yaml (რესურსები/ტესტები)

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) დაგეგმვა და იზოლაცია

NodePools: გამოყავით გადახდები/საფულე „დაბალი ხმაურის“ კვანძებზე სწრაფი დისკით.
Taints/Tolerations: დაცული აუზები კრიტიკული დატვირთვისთვის.
(Anti-) Affinity: გაითვალისწინეთ შენიშვნები ზონების/კვანძების მიხედვით (HA).
ResourceÜta/LimitRange ნეიმსპეისებისთვის - დაცვა „ხმაურიანი მეზობლებისგან“.

12) მულტიკლასტერი, მულტფილმის რეგიონი, DR

დაყოფა იურისდიქციებში: მტევანი EU/LatAm/ROW; რეზიდენტების მონაცემები ადგილობრივად.
GSLB/Anycast შესასვლელში, per-clast დაკვირვება და ალერტები.

DR დონე:
  • Warm standby (რეკომენდებულია): კრიტიკული მონაცემთა ბაზის სინქრონული რეპლიკა, failover- ის პერიოდული შემოწმება.
  • აქტიური კითხვისთვის/რეგიონალური მარშრუტიზაციისთვის.
  • სარეზერვო: Velero, rehearsal აღდგენა.

13) iGaming სპეციფიკა

გადახდა/საფულე: p95-300-500 ms, ინდივიდუალური აუზები და მკაცრი PDB; canary 1→5→10%.
ლობი/შინაარსი: აგრესიული HPA RPS/INP, გაცხელებული სურათები/ვექტორული ქეში.
მსუბუქი თამაშები/ნაკადები: LC/მინიმალური retrais, გრძელი Taimauts სოკეტები, კავშირი.
შესაბამისობა: ნეიმსპასი მკაცრი პოლიტიკით, KMS- ის საიდუმლოებები, Helm რელიზების ცვლილებების აუდიტი.
საპასუხისმგებლო თამაში: ლიმიტის/ბლოკირების სერვისი - პრიორიტეტული ტრაფიკი (fail-Open/close პოლიტიკა).

14) ჩეკის ფურცლები

მომსახურების გაანგარიშებამდე

  • მრავალფუნქციური სურათი, USER nonroot, cosign ხელმოწერა, სკანირება დასრულდა.
  • Requests/limits, probes, env/secret გარე მენეჯერისგან.
  • PDB, `maxUnavailable ≤ 1`, graceful shutdown.
  • SLO/alerty, კვალი საკეტიდან BD- მდე.
  • კანარის სქემა და დაბრუნების გეგმა.
  • პოლიტიკოსები OPA/Kyverno გადის (no root, no hostPath, no: latest).

მტევანი/პლატფორმა

  • CNI და ქსელის პოლიტიკა შედის; mTLS (mesh) სად არის საჭირო.
  • შემოწმებულია StorageClass/retenshn, becap/restore.
  • HPA/VPA/KEDA მორგებულია; Cluster Autoscaler и warm-pool.
  • RBAC მინიმალურია, აუდიტი შედის, საიდუმლოებები - KMS- დან.
  • GitOps: ცხრილები/მანიფესტები საცავში, PR მიმოხილვა სავალდებულოა.

15) ანტი შაბლონები

სურათები 'latest', root მომხმარებელი, „სქელი“ ძირითადი ფენები.
არა 'requests/limits' eviction/trottling.
Readiness = liveness (მფრინავი restarts).
Steitful/stateless ნაზავი ერთ აუზზე taints- ის გარეშე.
სქემების მიგრაცია შუბლზე, ექსპანსიისა და კონტრაქტის გარეშე.
ერთადერთი მტევანი „ყველა ბაზარზე“ რეგიონალური იზოლაციის გარეშე.
ლოგოები PII/PAN, საიდუმლოებები ConfigMap- ში.
PDB/დრენაჟის არარსებობა - კლდეები მწვერვალებში და განახლება.

16) პლატფორმის მეტრიკა (მინიმალური)

Кластер: CPU/mem requests vs allocatable, pod-churn, node-pressure.
ქსელი: p95 per-route, 4xx/5xx, reset/timeout, retry-rate, mTLS შეცდომები.
საცავი: IOPS/latence, queue-depth, CSI შეცდომები.
Autoskale: HPA decions, CA events, დათბობის დრო.
ბიზნესი: TTP, TtW, FTD-success, პროვაიდერის გადახდების უარყოფა.
უსაფრთხოება: OPA- ს შეუსაბამობები, ხელმოწერილი სურათები, ვადაგასული საიდუმლოებები.

17) მანიფესტების მაგალითები

Deployment (API, კანარის ლაბელი)

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 (საფულე)

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

HPA (RPS- ის საშუალებით 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) განხორციელების პროცესი (სპრინტებზე)

1. სურათების ასამბლეა და უსაფრთხოება: მრავალჯერადი ეტაპი, SBOM, ხელმოწერები, ადმისიის პოლიტიკა.
2. ძირითადი k8s პლატფორმა: CNI, Ingress/Gateway, მონიტორინგი/ლოგოები/ტრეისი, StorageClass.
3. CI/CD და GitOps: Helm გრაფიკები, ოთხშაბათს, კანარი/rollback, სქემების მიგრაცია.
4. Skale და სტაბილურობა: HPA/VPA/KEDA, PDB, node-puls, taints/affinity, DR გეგმა.

საბოლოო ყალბი ფურცელი

თხელი, ხელმოწერილი სურათები + დაშვების პოლიტიკა = უსაფრთხოების საფუძველი.
ნიმუშები, რესურსები, PDB, დრამი = გამოშვებების სტაბილურობა.
HPA/VPA/KEDA + ტყვიის tuning = მასშტაბები „დაშლის“ გარეშე.
Gateway/Ingress + mTLS/OPA = უსაფრთხო პერიმეტრი და შიდა კომუნიკაცია.
Observability + SLO + GitOps = კონტროლირებადი ცვლილებები.
რეგიონალური იზოლაცია და DR = შესაბამისობა და წინააღმდეგობა.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

Telegram
@Gamble_GC
ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.