Tehnologie și infrastructură → clustere Kubernetes și diagrame Helm

Clustere de kubernete și diagrame Helm

1) Rolul Kubernetes și Helm

Kubernetes este baza platformei de aplicații: standardizează rularea, rețeaua, configurațiile, secretele și auto-vindecarea. Helm este un manager de pachete/șabloane care transformă manifestele declarative în versiuni repetabile cu controlul versiunii și dependențe. Împreună, acestea oferă expedieri previzibile, rollback-uri rapide și un singur limbaj de infrastructură.

2) Proiectarea clusterului

2. 1 Topologie și toleranță la erori

Multi-AZ: planul de control și nodurile piscinei lucrătorilor sunt zonate; PDB/TopologySpreadConstrângeri pentru uniformitate.
Multi-regiune/DR: grupuri independente per regiune; apeluri interregionale - numai pe căi „reci” (directoare/telemetrie), „fierbinte” (portofel) - local.
Grupurile de lucrători după profil: „general”, „calcul”, „io”, „la fața locului” (pentru sarcinile de fundal). Atribuire prin nodeSelector/afinitate/cauciucuri.

2. 2 Namespaces și modelul multi-utilizator

Namespace-izolare pe domenii/comenzi: „plăți”, „portofel”, „jocuri”, „raportare”.
ResourceCota + LimitRange: limite de bază CPU/RAM și replici maxime; protecția clusterului împotriva „aspiratoarelor”.
RBAC: roluri read-only în mod implicit, scrie - numai CI/CD și de gardă.

2. 3 Rețea

CNI cu suport NetworkPolicy (Calico/Cilium): Politica L3/L4 de namespace/etichetă.
Ingress → Gateway API: treceți la modelul 'GatewayClass/Gateway/HTTPRoute' pentru canari și multi-chirie.
Service Mesh (opțional): mTLS, încercați din nou/întrerupător, conștient de localitate; activați punctul pentru fiabilitatea inter-service.

3) Fiabilitate și scalabilitate

3. 1 Scalare

HPA după indicatorii utilizatorului (RPS/latență/adâncime coadă), nu doar CPU.
VPA pe clasa de sarcină de fundal; în produs - „recomandare numai” sau împreună cu HPA pe diferite valori.
Cluster Autoscaler: grupuri de noduri separate pentru servicii sensibile; warm-pool la pronosticuri (turnee/meciuri).

3. 2 Resurse și QoS

Fiecare Pod are cereri/limite; evitați „: cele mai recente” și „nelimitat” containere.
PriorityClass: serviciile critice („portofel”, „plăți”) le înlocuiesc pe cele non-critice.
PDB: nu lăsați clusterul „trage-te în picior” atunci când actualizarea nodurilor.

3. 3 Upgrade-uri fără downtime

RollingUpdate cu maxIndisponibil = 0 pe căile critice.
PodDisruptionBudget + ReadinessSones (не 'startupProbe' вместо pregătire).
Capacitate de supratensiune pentru eliberări rapide în timpul vârfurilor - cu precauție.

4) Securitatea platformei

Pod Security (Baseline/Restricted) la nivel de namespace; 'privileged' disallowing, hostPath, root.
NetworkPolicy: default-deny și whitelisting prin port/etichetă.
Seccomp/AppArmor, utilizatori non-root, rootfs read-only.
Secretele: furnizorul KMS/Vault (CSI), nu păstrați secrete în valori. yaml' în formă deschisă.
RBAC minim: emitem conturi de servicii numai drepturile necesare; jetoane de scurtă durată.
Controlul admiterii: OPA/Gatekeeper/Kyverno - aplică etichete, limite, încălcări ale politicilor.

5) Observabilitate

OpenTelemetry: urmărire de la serviciul Ingress/Gateway → → bază de date/memorie cache, etichete obligatorii „service”, „versiune”, „regiune”, „partener”, „api _ version”.

Busteni: structurat, fara PII/PAN; Rutare la stocare centralizată

Valori: RED/USE, tablouri de bord SLO, alerte arde-rate.
Sintetice: eșantioane din țările potrivite/ASN; perimetrul și controalele interne de sănătate.

6) GitOps и livrare progresivă

Argo CD/Flux: starea dorită este stocată în Git; fiecare namespace are propriul depozit/dosar.
Promovarea artefactelor: "dev → stage → prod' prin PR, nu" kubectl apply ".
Canare/Albastru-Verde: Argo Rollouts/Gateway API; valori de succes - P95/P99, rata de eroare, SLI de afaceri (CR de depozite).
Rollbacks: în Helm/Argo - prin buton; în diagrame - versiunile sunt fixe.

7) Helm: cele mai bune practici

7. 1 Structura diagramei

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)

• 'version' - versiune diagramă (SemVer), 'appVersion' - versiune aplicație (imagine).
• Numele resurselor puternice sunt "{{include 'svc. nume complet. "}}" + etichete "app. Kubernetes. io/'.
• Manifestări necesare: Implementare/StatefulSet, Service, ServiceAccount, HPA (dacă este cazul), PDB, NetworkPolicy.

7. 2 Strategia valorilor

Basic 'values. yaml' - implicite, fără secrete și specificul mediului.
Suprascrie: 'values- {stage' prod} .yaml '+ per-region files.
Secrete: SOPS ("valori-prod. sops. yaml') sau Vault injecţie prin intermediul CSI.
Parametrii resurselor și eșantioanelor - în valori cu valori „rezonabile” implicite.

7. 3 Dependențe și cod comun

Grafice comune biblioteci pentru modele (sonde, adnotări, NetworkPolicy).
Dependențe ("cerințe "/" Diagramă. yaml') fixați după versiune; evitați „păpuși adânci de cuibărit”.

7. 4 Șabloane și verificări

Utilizați 'required' și' fail 'în' _ helpers. tpl' pentru valorile critice.
Validarea valorilor - schema de valori. schema. Json '.
Unity chart tests - 'helm unittest'; analiza statică - kubeconform/kubeval.
Depanare locală - 'șablon de cârmă' + '--valori' + 'kubeconform'.

7. 5 Versiuni și stocare

Împingeți graficul la registrele de containere OCI; Etichete de SemVer.
Helmfile/' helmfile. d' pentru orchestrarea de sheaves multi-chart.
Artefacte CI: manifestele generate + dependențele lockfile.

8) Exemplu: Implementare (fragment șablon 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) Secrete și configurații

Secrete prin CSI (Vault/KMS) sau SOPS în depozitul Git (chei GPG/KMS; „kubectl edit” este interzis).
ConfigMap/Adnotări ale sumei de control secrete pentru declanșarea lansării.
A nu se păstra PAN/PII; utilizați tokenization.
Secretele sigilate sunt permise, dar este preferat SOPS sau CSI direct.

10) Rețea și perimetru

Gateway API pentru rutare L7, canari și albastru-verde; sesiuni lipicioase numai atunci când este necesar.
mTLS între servicii prin mesh/sidecar-less (Cilium) - punct pentru nucleul de plată.
Ieșire: listă controlată de noduri externe (PSP/KYC), fixe NAT-IP, timeout-uri și buget retray.

11) Servicii de stat și date

Pentru bazele de date OLTP, utilizați servicii cloud gestionate sau operatori (Postgres/MySQL) în clustere separate.
PVC/CSI cu instantanee și politica de backup; „PodAntiAffinity” pentru replici.
Pentru cozi/streaming - solutii gestionate sau clustere dedicate; într-un cluster de aplicații „comune”, păstrați un minim de stare.

12) CI/CD transportor (referință)

1. Build & test → 2) SCA/scame → 3) Imagine în registru (SBOM, semnătură) →

2. Helm chart generation + 'helm unittest' + kubeconform →

3. Decriptarea SOPS în CD → 6) runtime PR în depozitul GitOps →

4. Argo/Flux se aplică → 8) Argo Rollouts canar → 9) SLO Auto Verdict → 10) Promotion/Rollback.

13) Măsurători ale maturității platformei

Cota de versiuni prin intermediul GitOps (țintă: 100%).
Timp de rulare (P95) până când este gata, MTTR rollback.
Acoperirea Namespace Pod Security and NetworkPolicy (obiectiv: 100%).
% din serviciile cu HPA și solicitări/limite corecte.
% diagramă cu 'valori. schema. Json 'şi testele unităţilor.
Incidente cauzate de modificările „manuale” (țintă: 0).

14) Lista de verificare a implementării

1. Clustere pe zone, bazin de noduri pe profile; PDB/TopologySpreadConstrângeri.
2. Namespace model, ResourceCote/LimitRange, RBAC minim.
3. Pod Security (Restricționat) и implicit-nega NetworkPolicy.
4. Gateway API/Ingress; controlul de ieșire și fixarea NAT la furnizori.
5. Observabilitate: trasee OTel, RED/USE, geo sintetice; Tablouri de bord SLO.
6. GitOps (Argo/Flux), canar/albastru-verde, auto-promovare prin metrică.
7. Standarde de cârmă: structură, schemă. json, teste, registre SOPS/Vault, OCI.
8. HPA/VPA, Cluster Autoscaler, warm-pool la vârfuri.
9. Operațiuni de date: instantanee CSI, backup-uri ,/operatori de baze de date gestionate.
10. Teste regulate DR/haos și zile de joc.

15) Anti-modele

Un grup „gigant” pentru orice, fără izolare și cote.
Containere fără restricţii de resurse, „ultimele” etichete, fără sonde.
Secrete în valori. yaml' în text clar, „kubectl edit” în prod.
Eliberează trecut GitOps, manual manifesta editări pe un cluster live.
Lipsa NetworkPolicy/Pod Security - rețea „plat”.
Un singur semnal HPA comun în procesor pentru diferite tipuri de sarcini.
Stocarea bazelor de date OLTP într-un cluster de aplicații „comune” fără operator și copii de rezervă.

16) context iGaming/fintech: note practice

Carti web de plata: intrare/gateway dedicat si iesire ingusta la PSP; termene stricte/retribuții; Piscină gazdă individuală.
Trafic VIP: prioritizare și rute individuale; PDB și topologie răspândit pentru stabilitate.
Turnee/pronosticuri: noduri calde + HPA predictiv; încălzirea cache-urilor/conexiunilor.
Raportare/CDC: cluster/pool separat, astfel încât ETL să nu afecteze Prod.
Reglementare: jurnale imuabile (WORM), tokenizare PII, segmentare rețea.

Total

O platformă Kubernetes puternică nu este un „heap YAML”, ci standarde: izolare, politică de securitate, resurse gestionate, observabilitate și disciplină GitOps. Helm Charts - Contractul dvs. de aprovizionare: versiuni previzibile, modele testabile, manipulare secretă sigură și kickback-uri simple. Prin consolidarea acestor principii, obțineți clustere care supraviețuiesc vârfurilor, accelerează eliberările și rezistă cerințelor de afaceri și de reglementare.