Torrent Gear

Docker და Kubernetes iGaming: deplo სტრატეგია

1) iGaming კონტექსტი: პლატფორმის მოთხოვნები

Real Time (მსუბუქი თამაშები, ფსონები, ტურნირის მოვლენები) - მკაცრი p95 API/WS.

ტრეფიკის მწვერვალები (ნაკადები/პრომო) - სწრაფი სკეიტი „ცივი დაწყების“ გარეშე.

ფული და შესაბამისობა - კონტურების იზოლაცია, გამოშვებების კვალიფიკაცია, წვდომისა და აუდიტის კონტროლი.

მრავალ იურისდიქცია/ბრენდები (namespaces/projects), ქსელის და რესურსების იზოლაციის პოლიტიკა.

ძირითადი SLO: ლოგინი 99. 9%, ანაბარი 99. 85%, p95 API - 250-400 ms, p95 WS RTT - 120 ms.

2) ძირითადი არქიტექტურა კუბერნეტებზე

ფენები: Ingress/Edge, API/Gateway სერვისები (საფულე, პროფილი, პრომო, ანტიფროდი), რიგები/ნაკადები და საცავი.

იზოლაცია: 'namespace' brand/barket ან „უჯრედი“ (cell) რეგიონში; ცალკეული NodePools (public API/batch/ws რეალობა).

ქსელის პოლიტიკოსები: 'NetworkPolicy' პრინციპით „deny by default“, ცალკეული egress პოლიტიკა PSP/KYC/თამაშების პროვაიდერების მიმართ.

საცავი: 'StorageClass' რეპლიკაციით ზონაში/რეგიონში, ოპერატორები BD/ქეში (Postgres/MySQL, Redis, Kafka).

3) კონტეინერის სურათები: ხარისხი და უსაფრთხოება

Multi-arch (amd64/arm64), distroless ან slim ბაზა, მხოლოდ საჭირო ბინარული.

SBOM და დაუცველების სკანირება, სურათების ხელმოწერა, მიღების პოლიტიკა ('ImagePolicyWebhook ").

Immutable-tagging: გამოშვებები 'sha256'; აკრძალულია „latest“.

Runtime პროფილები: 'readOnlyRootFilesystem', 'runAsNonRoot', 'seccomp/AppArmor', მინიმალური კაპიტალები.

4) გამოშვების სტრატეგიები: როდის და რა უნდა აირჩიოს

RollingUntate (ნაგულისხმევი)

უსაქმურობის გარეშე; API- ს უმეტესობისთვის.

კონტროლი განახლებადი/liveness/startup probes, maxUnavailable/maxSurge.

Blue-Green

პარალელური შუშები ცისფერი და მწვანე; ტრანსპორტის შეცვლა Ingress/Service დონეზე.

კარგია სქემების/ჩამორთმევის ძირითადი ცვლილებებისთვის; სწრაფი rollback.

Canary

ტრაფიკის პროცენტული თანდათანობითი ჩართვა (5-10-25-50-100).

SLO კარიბჭის ტრიგერიმი: p95, error-rate, ანომალიები დეპოზიტებში/განაკვეთებში.

პარამეტრები: Service Mesh (Istio/Linkerd), Ingress კონტროლერი, კანარის პრეზენტაციებით.

A/B и Shadow

Shadow: ჩვენ ვატარებთ ტრაფიკის ნაწილს ახალ გამოშვებაზე, მომხმარებლის უპასუხოდ (სუფთა ტელემეტრია).

A/B: ფუნქციური ექსპერიმენტები დროშებით (feature-flags) და მოთამაშეთა/ბაზრების სეგმენტაციით.

5) GitOps და კონფიგურაციის მენეჯმენტი

GitOps (Argo CD/Flux): მტევნები კითხულობენ სასურველ მდგომარეობას Git- დან; ყველა ცვლილება PR და შურისძიების გზით.

შაბლონები: Helm/Kustomize, გრაფიკის ერთიანი ბიბლიოთეკა.

საიდუმლოებები: გარე მენეჯერები (Vault/Cloud SM), 'ExternalSecrets '/' Secrets Store CSI'; KMS გასაღებები და როტაცია.

Pipline (გამარტივებული):

1. CI აგროვებს ხელმოწერილ გამოსახულებას რეესტრებში.

2. PR ცვლის გამოსახულების/კონფისკაციის ვერსიას, GitOps იყენებს.

3. კანარის rollout SLO კარიბჭეებით - ავტომატური გამოტოვება ან მანქანის-rollback.

6) ავტო სკეილინგი მწვერვალების ქვეშ და WS დატვირთვა

HPA პროგრამის მეტრებში (RPS, p95 ლატენტობა, queue lag) და არა მხოლოდ CPU/RAM.

KEDA ღონისძიების სკეილისთვის (Kafka, RabbitMQ, Redis, HTTP-queue).

VPA მოთხოვნის/ლიმიტის ყოველდღიური კორექტირებისთვის.

Cluster Autoscaler + warm აუზები (pre-provision) პრომო/ტურნირების დროს.

WebSocket სპეციფიკა:

ცალკეული NodePools (მეტი ქსელის აღწერილობა), 'PodDisruption Budget' რბილი განახლებისთვის, sticky-routing (Session Affinity) Ingress/Mesh- ის საშუალებით.

7) Stateful კონტურები: საფულე, BD, რიგები

ოპერატორები (Postgres/MySQL, Redis Sentinel/Cluster, Kafka Operator): დეკლარაციული რეპლიკაცია, 'PITR', ავტომატური ჩანთები.

RPO/RTO პოლიტიკა: სინქრონული რეპლიკაცია ზონაში, ასინქრონული - DR რეგიონებში.

Idempotence/outbox დეპოზიტების/გადახდებისთვის, inbox შაბლონის შაბლონებისთვის PSP და თამაშების პროვაიდერები.

StorageClass სწრაფი IOPS; საფულისთვის - ცალკე კლასი და კვანძები ადგილობრივი SSD (და რეპლიკაცია).

8) ქსელის ფენა და გეითვეი

Ingress (Nginx/Envoy/HAProxy/ALB) mTLS- დან ზურგჩანთებამდე, HTTP/2/3, HSTS, rate-limits.

Service Mesh: კანარის მარშრუტები, retrais/time, circuit-breakers, TLS ნაგულისხმევი კლასტერის შიგნით.

Egress კარიბჭეები: თეთრი სიები PSP/KYC/პროვაიდერებისთვის, DNS და IP კონტროლი.

9) Observability და SLO გამოშვების კარიბჭეები

OpenTelemetry: ტრეკები წინა მხარეს, API - გადახდა/თამაშის პროვაიდერი; შეცდომების 100% და „ნელი“ სპანი.

RED/USE მეტრიკა + ბიზნეს SLI (ანაბრის/განაკვეთის/გამოსვლის წარმატება).

Logs JSON 'trace _ id', WORM აუდიტისთვის.

Release-gates: გამოტოვეთ მხოლოდ იმ შემთხვევაში, თუ SLO მწვანეა ტესტის წილზე.

10) უსაფრთხოება

Policy as Code: OPA/Gatekeeper/Kyverno (აკრძალვა კერძო, მოთხოვნა 'runAsNonRoot', შეზღუდვები, ხელმოწერის პულსის შემოწმება).

საიდუმლოებები და გასაღებები: მხოლოდ საიდუმლო მენეჯერისგან; 'envFrom' შემცირება, საიდუმლოებების ინექცია.

პროვაიდერების Webhooks/webhooks: HMAC ხელმოწერები, idempotence, შესასვლელი egress კარიბჭეზე.

კომპლექტი: გამოშვებების, არტეფაქტების, წვდომის აუდიტი (RBAC/MFA), KUS/ლოგების არტეფაქტების გეო-იზოლირებული შენახვა.

11) მულტფილმის რეგიონი, failover და DR

აქტივი standbay რეგიონებში (მინიმალური საფულე/ლოგინი/გადახდები).

როტინგის ტრაფიკი: GSLB/Anycast; ჯანმრთელობის შემოწმება SLI- სთვის (ლოგინი/ანაბარი/განაკვეთი).

კატასტროფული გადართვა: ღილაკი DR-cutover (freeze writes - promote DB - თბება ქეში - ეტაპობრივი ტრაფიკი).

სავარჯიშოები: კვარტალური GameDay PSP- ის „ვარდნით“, ზონებით, თამაშების პროვაიდერით.

12) კონფიგურაციის კონტროლი და იხვები

Feature-flags (კონფიგურაცია ConfigMap/External Config) - მძიმე ფუნქციების გამორთვა უბედური შემთხვევის დროს.

Versioned კონფისკაციები (hashi, checksum ვიდეოები Pod- ზე), canary კონფისკაცია-როლი.

Runtime overrides Mesh/Ingress დონეზე (დროის გადაღება, რეპეტიციის პოლიტიკა) სურათების გადახედვის გარეშე.

13) ეკონომიკა და პროდუქტიულობა

NodePools დანიშნულებისამებრ: RPS-API, WS რეალითი, batch/ETL.

Spot/Preemptible для batch/ETL с `PodPriority` и `PodDisruptionBudget`.

პაკეტის შედგენა და დათბობა (JIT/შაბლონების ქეში) ცივი სტილის შესამცირებლად.

რესურსების ბიუჯეტები: requests/limits, VPA რეკომენდაციები, BD/PSP კავშირების ლიმიტები, დაკავშირება.

14) მანიფესტის შაბლონები (ფრაგმენტები)

კანარის დეპოზიტი Ingress ინტერფეისის საშუალებით:

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: payments-api spec:
replicas: 6 strategy:
type: RollingUpdate rollingUpdate: {maxSurge: 2, maxUnavailable: 1}
template:
metadata:
labels: {app: payments-api, version: v2}
spec:
securityContext: {runAsNonRoot: true}
containers:
- name: app image: registry/payments@sha256:...
ports: [{containerPort: 8080}]
resources:
requests: {cpu: "300m", memory: "512Mi"}
limits:  {cpu: "1",  memory: "1Gi"}
readinessProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 5

HPA კასტომის მეტრში (RPS/latence Prometheus Adapter- ის საშუალებით):

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: payments-api}
spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: payments-api}
minReplicas: 6 maxReplicas: 60 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"

ქსელის პოლიტიკა (მხოლოდ Ingress gateway და აუცილებელი egress):

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: {name: payments-restrict}
spec:
podSelector: {matchLabels: {app: payments-api}}
policyTypes: ["Ingress","Egress"]
ingress:
- from: [{namespaceSelector: {matchLabels: {gw: ingress}}}]
egress:
- to: [{ipBlock: {cidr: 10. 0. 0. 0/8}] # შიდა სერვისები
- to: [{namespaceSelector: {matchLabels: {svc: psp-egress}}}]

15) გამოცემის ჩეკის სია

ხელი მოეწერა სურათს, შეგროვდა SBOM, დაუცველობა - მისაღები დონეზე.
მანიფესტები ტარდება პოლიტიკის შემოწმებით (Kyverno/OPA), მინიმალური შეღავათებით.
Readiness/Startup probes სწორია; 'PDB' და 'PodPriority' მორგებულია.
კანარის გეგმა: 5% - 10% - 25% - 50% - 100% SLO კარიბჭეებით და ავტო - როლბაკით.
HPA/KEDA + Cluster Autoscaler; warm-pul nod მოვლენის ქვეშ.
საიდუმლოებები Vault/SM- დან; კონფისკაცია განახლებულია; ფიჩის დროშები მზად არიან დეგრადაციისთვის.
e2e კვალი ჩართულია; ალერტები SLI- ზე (ანაბარი/განაკვეთი/გამომავალი).
DR გეგმა და „cutover ღილაკი“ შემოწმებულია სტენდზე; შემოწმებულია bacaps/PITR.
დოკუმენტაცია: როგორ გადავიდეთ, როგორ გადავიტანოთ PSP/თამაშის პროვაიდერი, რომელსაც ღამით ეძახიან.

16) ანტი რეგრესია და ტიპიური ხაფანგები

Grace Reading პერიოდი ძალიან მოკლეა და ადრეული 5xx rollout- ზე.

ერთი BD აუზი ლიმიტის გარეშე არის ნაერთების ზვავის დროს.

საიდუმლოებები ცვლადი გარემოში როტაციის გარეშე - გაჟონვა.

Mesh გარეშე limites/დროის გადაღებები - ჩამოკიდებული პროვაიდერები.

HPA- ს მხოლოდ CPU - WS/API- ს არ აქვს დრო, რომ მასშტაბური იყოს.

რეზიუმე

IGaming- ში გადასახადის სტრატეგია საიმედო კონტეინერის პრაქტიკის ერთობლიობაა (უსაფრთხო სურათები, დაშვების პოლიტიკა), ჭკვიანი გამოშვებები (canary/blue-green c SLO კარიბჭეები), სწორი ავტო სკეიტი (HPA/KEDA + warm nods მწვერვალებისთვის), ოპერატორები სახელმწიფო კონტურების და მრავალ რეგიონალური DR.- სთვის. დაამატეთ GitOps, ბილიკი თამაშის გადახდებისა და პროვაიდერების საშუალებით, ქსელის პოლიტიკოსები და დაზოგეთ სპეციალიზირებული NodePools - და თქვენი გამოშვებები გახდება პროგნოზირებადი, სწრაფი და სწრაფი უსაფრთხოა ფულისთვის და მოთამაშეებისთვის.