ტექნოლოგიები და ინფრასტრუქტურა Kubernetes მტევანი და Helm ჩარტები

Kubernetes მტევანი და Helm ჩარტები

1) Kubernetes და Helm როლი

Kubernetes არის განაცხადის პლატფორმის საფუძველი: სტანდარტიზებულია განლაგება, ქსელი, კონფისკაცია, საიდუმლოებები და თვითგანადგურება. Helm არის პაკეტების/შაბლონების მენეჯერი, რომელიც დეკლარაციულ მანიფესტებს განმეორებით გამოშვებად აქცევს ვერსიებსა და დამოკიდებულებებს. ერთად, ისინი იძლევიან პროგნოზირებულ დეპოზიტებს, სწრაფ გამოტოვებას და ინფრასტრუქტურის ერთ ენას.

2) კლასტერის დიზაინი

2. 1 ტოპოლოგია და წინააღმდეგობა

Multi-AZ: საკონტროლო თვითმფრინავი და სამუშაო ტყვიების კვანძები ნაწილდება ზონების მიხედვით; PDB/TopologySpreadConstraints ერთგვაროვნებისთვის.
მულტირეგიონი/DR: დამოუკიდებელი მტევანი per-region; ინტერრეგიონალური ზარები - მხოლოდ „ცივი“ მარშრუტების გასწვრივ (კატალოგები/ტელემეტრია), „ცხელი“ (საფულე) - ადგილობრივად.
სამუშაო აუზები პროფილებში: 'general', 'compute', 'io', 'spot (ფონის დავალებებისთვის). დანიშვნა nodeSelector/affinity/taints- ის საშუალებით.

2. 2 სახელების სივრცე და მულტიპლიკერის მოდელი

Namespace იზოლაცია დომენებზე/ბრძანებებზე: 'payments', 'wallet', 'games', 'reporting'.
ResourceÜta + LimitRange: ძირითადი limites CPU/RAM და მაქსიმალური შენიშვნები; მტვერსასრუტი დაცვა მტვერსასრუტებისგან.
RBAC: read-only როლები სტანდარტულად, write - მხოლოდ CI/CD და on-call.

2. 3 ქსელი

CNI ქსელის პოლიტიკის მხარდაჭერით: L3/L4 namespace/label პოლიტიკა.
Ingress - Gateway API: გადასვლა 'GatewayClass/Gateway/HTTPRoote' მოდელზე კანარებისა და მრავალი ტენიანობისთვის.
Service Mesh (სურვილისამებრ): mTLS, retry/breaker, ადგილმდებარეობა; ჩართეთ წერტილოვანი საიმედოობისთვის.

3) საიმედოობა და სკალირება

3. 1 სკეილინგი

HPA მომხმარებლის მეტრებში (RPS/latency/queue depth) და არა მხოლოდ CPU.
VPA ფონის დატვირთვის კლასში; გაყიდვაში - „recommendation მხოლოდ“ ან HPA- სთან ერთად სხვადასხვა მეტრებში.
Cluster Autoscaler: ცალკეული node groups მგრძნობიარე მომსახურებისთვის; warm-pool მწვერვალებისთვის (ტურნირები/მატჩები).

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

თითოეულ Pod- ს აქვს requests/limits; თავიდან აიცილოთ 'latest' და „შეუზღუდავი“ კონტეინერები.
PriorityClass: კრიტიკული სერვისები ('wallet', 'payments') არაკრიტიკულია.
PDB: ჩვენ არ ვაძლევთ კლასტერს „ფეხი დაარტყა“, როდესაც ნოდის განახლება ხდება.

3. 3 განახლებები

RollingUntrate c maxUnavailable = 0 კრიტიკულ გზაზე.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Surge კონტეინერი სწრაფი გამოშვებისთვის მწვერვალების დროს - სიფრთხილით.

4) პლატფორმის უსაფრთხოება

Pod Security (Baseline/Restricted) namespace დონეზე; აკრძალვა 'privileged', hostPath, ოთახი.
ქსელის პოლიტიკა: default-deny და თეთრი სიები პორტებში/label.
Seccomp/AppArmor, non-root users, read-only rootfs.
საიდუმლოებები: KMS/Vault პროვაიდერი (CSI), ჩვენ საიდუმლოებას არ ვატარებთ „ვალებში“. yaml 'ღია ფორმით.
RBAC მინიმუმი: ჩვენ ვაძლევთ მხოლოდ საჭირო უფლებებს მომსახურების ანგარიშებზე; მოკლე ნიშნები.
Admission კონტროლი: OPA/Gatekeeper/Kyverno - ეტიკეტების, ლიმიტების, პოლიტიკის დარღვევების დასასრული.

5) Observability

OpenTelemetry: ტრეკინგი Ingress/Gateway - სერვისი BD/ქეში, სავალდებულო ეტიკეტები 'სერვისის', 'ვერსიის', 'region', 'partner', 'app_ ვერსია'.
ლოგოები: სტრუქტურირებული, PII/PAN გარეშე; მარშრუტიზაცია ცენტრალიზებულ საცავში.
მეტრიკი: RED/USE, SLO Dashbords, burn-rate ალერტები.
სინთეზური: ნიმუშები საჭირო ქვეყნებიდან/ASN; პერიმეტრი და შინაგანი ჯანმრთელობის შემოწმებები.

6) GitOps и progressive delivery

Argo CD/Flux: სასურველი მდგომარეობა ინახება Git- ში; თითოეული namespace არის საკუთარი საცავი/საქაღალდე.
არტეფაქტების პოპულარიზაცია: 'dev - stage' PR- ის მეშვეობით და არა „kubectl apply“.
Canary/Blue-Green: Argo Rollouts/Gateway API; წარმატების მეტრებია P95/P99, error-rate, ბიზნეს SLI (CR ანაბრები).
გამოტოვება: Helm/Argo- ში - ღილაკზე; ჩარტებში - ფიქსირდება ვერსიები.

7) ჰელმი: საუკეთესო პრაქტიკა

7. 1 სქემის სტრუქტურა

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)

• 'ვერსია' - გრაფიკის ვერსია (SemVer), 'AppVersion' - განაცხადის ვერსია (გამოსახულება).
• რესურსების მკაცრი სახელები: '{include "svc. fullname".}' + ეტიკეტები' app. kubernetes. io/`.
• სავალდებულო მანიფესტები: Deployment/StatefulSet, Service, Count Account, HPA (თუ გამოიყენება), PDB, NetworkPolicy.

7. 2 Values სტრატეგია

საბაზო 'values. yaml '- ნაგულისხმევი, საიდუმლოებებისა და სპეციფიკური გარემოს გარეშე.
Overraids: 'values- {stage' stage} .yaml '+ per-region ფაილები.
საიდუმლოებები: SOPS ('values-merry. sops. yaml ') ან Vault ინექცია CSI- ს მეშვეობით.
რესურსებისა და ნიმუშების პარამეტრები - „გონივრული“ ნაგულისხმევი.

7. 3 დამოკიდებულება და საერთო კოდი

ზოგადი ბიბლიოთეკის სქემები შაბლონებისთვის (probes, annotations, NetworkPolicy).
დამოკიდებულება ('requirements '/' გრაფიკი. yaml ') ჩაწერეთ ვერსიით; მოერიდეთ ღრმა „მატრიოშკებს“.

7. 4 შაბლონები და შემოწმებები

გამოიყენეთ 'required' და 'fail' in '_ helpers. tpl 'კრიტიკული მნიშვნელობებისთვის.
values სქემის შესაბამისობა - 'values. schema. json`.
სქემის ერთეულის ტესტები - 'helm unittest'; სტატიკური ანალიზია kubeconform/kubeval.
ადგილობრივი გამართვა არის 'helm template' + '-values' + 'kubeconform'.

7. 5 გამოშვებები და შენახვა

ცხრილი კონტეინერების OCI რეესტრებში; SemVer ჭდეები.
Helmfile/`helmfile. დ 'მრავალსართულიანი განლაგების ორკესტრისთვის.
CI არტეფაქტები: წარმოქმნილი მანიფესტები + ლოკფილის დამოკიდებულებები.

8) მაგალითი: Deployment (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) საიდუმლოებები და კონფიგურაცია

საიდუმლოებები CSI (Vault/KMS) ან SOPS მეშვეობით Git საცავებში (GPG/KMS გასაღებები; აკრძალვა 'kubectl edit').
ConfigMap/Secret checksum განცხადებები rolling გამოშვების ტრიგერის შესახებ.
არ შეინახოთ PAN/PII; გამოიყენეთ ტოკენიზაცია.
ნებადართულია Sealed Secrets, მაგრამ სასურველია SOPS ან სწორი CSI.

10) ქსელი და პერიმეტრი

Gateway API L7-routing, canares და blue-green; sticky სესიები მხოლოდ საჭიროებისამებრ.
mTLS სერვისებს შორის mesh/sidecar-less (Cilium) - წერტილოვანი გადახდის ბირთვის.
Egress: გარე კვანძების კონტროლირებადი სია (PSP/KYC), ფიქსირებული NAT-IP, ტაიმაუტები და რეტრაუსის ბიუჯეტი.

11) Stateful სერვისები და მონაცემები

OLTP-BD- სთვის გამოიყენეთ კონტროლირებადი ღრუბლის სერვისები ან ოპერატორები (Postgres/MySQL) ცალკეულ მტევნებში.
PVC/CSI სნაიპერების და ბეკების პოლიტიკით; „PodAntiAffinity“ რეპლიკებისთვის.
რიგებისთვის/სტრიმინგისთვის - კონტროლირებადი გადაწყვეტილებები ან გამოყოფილი კლასტერები; „ზოგადი“ გამოყენებითი კლასტერში შეინარჩუნეთ მინიმალური მდგომარეობა.

12) CI/CD კონვეიერი (რეფერენდუმი)

1. Build & test (2) SCA/linth-3) სურათი რეესტრში (SBOM, ხელმოწერა)

2. Helm გრაფიკის წარმოება + 'helm unittest' + kubeconform

3. SOPS დეკრიპტი rantime CD-6) PR GitOps საცავებში

4. Argo/Flux იყენებს 8) Argo Rollouts canary (9) Auto განაჩენი Promotion/Promotion.

13) პლატფორმის სიმწიფის მეტრიკა

GitOps- ის საშუალებით გამოშვების წილი (მიზანი: 100%).
დალაგების დრო (P95) მზადყოფნამდე, MTTR გამოტოვება.
Namespace's Pod Security და NetworkPolicy (მიზანი: 100%).
% მომსახურება HPA და სწორი requests/limits.
% გრაფიკი 'values. schema. json 'და ერთეული ტესტები.
„სახელმძღვანელო“ ცვლილებებით გამოწვეული ინციდენტები (მიზანი: 0).

14) განხორციელების სია

1. კლასტერები ზონებში, აუზის კვანძები პროფილების მიხედვით; PDB/TopologySpreadConstraints.
2. Namespace მოდელი, ResourceÈta/LimitRange, RBAC მინიმალური.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; egress კონტროლი და NAT ფიქსაცია პროვაიდერებზე.
5. Observability: OTel ტრეისი, RED/USE, სინთეზური გეო; SLO დაშბორდები.
6. GitOps (Argo/Flux), canary/blue-green, მეტრიკის ავტო ინდუსტრია.
7. Helm სტანდარტები: სტრუქტურა, სქემა. json, ტესტები, SOPS/Vault, OCI რეესტრები.
8. HPA/VPA, Cluster Autoscaler, warm-pool მწვერვალებისთვის.
9. მონაცემთა ოპერაციები: CSI Snaphots, bacaps, ოპერატორები/მართვადი BD.
10. რეგულარული DR/chaos ტესტები და თამაშის დღეები.

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

ერთი „გიგანტური“ მტევანი ყველაფრისთვის იზოლაციისა და კვოტების გარეშე.
კონტეინერები რესურსების შეზღუდვების გარეშე, 'latest' tags, probes- ის ნაკლებობა.
საიდუმლოებები ვალუებში. yaml 'ღია ფორმით,' kubectl edit 'გაყიდვაში.
GitOps- ის გამოშვებები, მანიფესტების ხელით რედაქტირება ცოცხალ კლასტერზე.
ქსელის პოლიტიკის/Pod უსაფრთხოების არარსებობა - „ბრტყელი“ ქსელი.
ერთჯერადი ზოგადი HPA სიგნალი CPU- სთვის მრავალფეროვანი დატვირთვისთვის.
OLTP-BD- ის შენახვა „ზოგადი“ პროგრამის კლასტერში ოპერატორისა და ბეკების გარეშე.

16) iGaming/fintech კონტექსტი: პრაქტიკული ნოტები

გადახდის ვებ ჰუკები: გამოყოფილი ingress/gateway და ვიწრო egress PSP- სთვის; მკაცრი ტაიმაუტი/რეტრაი; ცალკე აუზის კვანძები.
VIP ტრაფიკი: პრიორიტეტული და ინდივიდუალური მარშრუტები; PDB და topology spread სტაბილურობისთვის.
ტურნირები/მწვერვალები: warm-pool კვანძები + პრედიკატური HPA; ქეში/ნაერთების დათბობა.
ანგარიში/CDC: ცალკეული მტევანი/აუზი ისე, რომ ETL არ იმოქმედებს პროდზე.
მარეგულირებელი: უცვლელი ლოგოები (WORM), tockenization PII, ქსელების სეგმენტი.

შედეგი

ძლიერი Kubernetes პლატფორმა არ არის YAML თაიგული, არამედ სტანდარტები: იზოლაცია, უსაფრთხოების პოლიტიკა, კონტროლირებადი რესურსები, დაკვირვება და GitOps დისციპლინა. Helm ჩარტები თქვენი მიწოდების კონტრაქტია: პროგნოზირებადი გამოშვებები, ტესტირების შაბლონები, უსაფრთხო საიდუმლოებები და მარტივი გამოტოვება. ამ პრინციპების კონსოლიდაციით, თქვენ მიიღებთ კლასტერს, რომელიც განიცდის მწვერვალებს, აჩქარებს გამოშვებებს და გაუძლებს ბიზნესისა და რეგულატორების მოთხოვნებს.