Technologia i infrastruktura → Kubernetes klastry i mapy Helm

Klastry kubernetes i mapy Helm

1) Rola Kubernetes i Helm

Kubernetes jest podstawą platformy aplikacji: normalizuje walcowanie, tworzenie sieci, konfiguracje, sekrety i samouzdrawianie. Helm jest menedżerem pakietów/szablonów, który zamienia deklaracyjne manifesty w powtarzalne wersje z kontrolą wersji i zależnościami. Razem zapewniają przewidywalne wysyłki, szybkie rolki i jeden język infrastruktury.

2) Projekt klastra

2. 1 Topologia i tolerancja błędów

Multi-AZ: płaszczyzna sterowania i węzły basenu pracownika są strefowane; PDB/TopOgraniczenia dla jednolitości.
Wielobranżowe/DR: niezależne klastry regionalne; połączenia międzyregionalne - tylko na ścieżkach „zimnych” (katalogi/telemetria), „gorących” (portfel) - lokalnie.
Pula pracowników według profilu: 'ogólne', 'compute', 'io', 'spot' (dla zadań w tle). Przypisanie za pośrednictwem węzłSelektor/powinowactwo/tains.

2. 2 Obszary nazw i model dla wielu użytkowników

Izolacja przestrzeni nazw według domen/poleceń: 'payments', 'wallet', 'games', 'reporting'.
Zakres limitów: podstawowe limity CPU/RAM i maksymalne repliki; ochrona klastra przed „odkurzaczami”.
RBAC: domyślnie role tylko do odczytu, zapisz - tylko CI/CD i dyżur.

2. 3 Sieć

CNI z obsługą Polityki (Calico/Cilium): Polityka L3/L4 według obszaru nazw/etykiety.
Ingress → Gateway API: przejdź do modelu 'GatewayClass/Gateway/HTTPRoute' dla kanarków i wielozadaniowości.
Service Mesh (opcjonalnie): mTLS, retry/breaker, locality-aware; włączyć punkt dla niezawodności międzyresortowej.

3) Niezawodność i skalowalność

3. 1 Skalowanie

HPA według mierników użytkownika (głębokość RPS/latency/kolejki), nie tylko procesora.
VPA w klasie obciążenia tła; w produkcie - „tylko rekomendacja” lub razem z HPA na różnych metrykach.
Cluster Autoscaler: oddzielne grupy węzłów dla usług wrażliwych; ciepły basen do wyborów (turnieje/mecze).

3. 2 Zasoby i QoS

Każdy Pod ma żądania/limity; unikać „: najnowszych” i „nieograniczonych” pojemników.
Klasa : usługi krytyczne („portfel”, „płatności”), które nie są krytyczne.
PDB: nie pozwól klastrowi „strzelać w stopę” podczas aktualizacji węzłów.

3. 3 Uaktualnienia bez przestojów

RoleUpdate z maxNiedostępny = 0 na ścieżkach krytycznych.
PodDis Budget + Read Probes (на 'startupProbe' вместа gotowość).
Przepustowość do szybkich zwolnień podczas szczytów - z ostrożnością.

4) Bezpieczeństwo platformy

Bezpieczeństwo Pod (linia podstawowa/ograniczona) na poziomie przestrzeni nazw; 'privileged' disallowing, Na 'Path', root.
Polityka: domyślna odmowa i wybielanie według portu/etykiety.
Seccomp/AppArmor, non-root users, read-only rootfs.
Tajemnice: dostawca KMS/Vault (CSI), nie przechowywać tajemnic w 'values. yaml' w formie otwartej.
Minimum RBAC: wydajemy konta usług tylko niezbędne prawa; krótkotrwałe żetony.
Kontrola wstęp: OPA/Gatekeeper/Kyverno - egzekwować etykiety, limity, naruszenia polityki.

5) Obserwowalność

OpenTelemetry: odwzorowanie z Ingress/Gateway → service → database/cache, mandatory labels 'service', 'version', 'region', 'partner', 'api _ version'.

Kłody: ustrukturyzowane, bez PII/PAN; Routing do scentralizowanego przechowywania

Mierniki: CZERWONE/UŻYJ, deski rozdzielcze SLO, alerty szybkości spalania.
Syntetyka: próbki z odpowiednich krajów/ASN; obwodowe i wewnętrzne kontrole zdrowotne.

6) Dostawa progresywna GitOps

Argo CD/Flux: żądany stan jest przechowywany w Git; każdy obszar nazw ma własne repozytorium/folder.
Promocja artefaktów: 'dev → stage → prod' poprzez PR, nie „kubectl apply”.
Kanaryjski/niebiesko-zielony: Argo Rollouts/Gateway API; wskaźniki sukcesu - P95/P99, wskaźnik błędów, SLI biznesowe (CR depozytów).
Rolki: w Helm/Argo - za pomocą przycisku; w wykresach - wersje są stałe.

7) Helm: najlepsze praktyki

7. 1 Struktura wykresu

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' - wersja mapy (SemVer), 'appVersion' - wersja aplikacji (image).
• Silne nazwy zasobów to '{{include' svc. pełna nazwa. "}} '+ labels' app. kubernetes. io/'.
• Wymagane manifesty: Wdrożenie/Zestaw Stat , Usługa, Konto, HPA (jeśli dotyczy), PDB, Polityka.

7. 2 Wartości-strategia

Podstawowe 'wartości. yaml' - domyślne, bez tajemnic i specyfiki środowiska.
Nadmiar: 'values- {stage' prod} .yaml' + pliki na region.
Sekrety: SOPS ('values-prod. sops. yaml') lub wstrzyknięcie Vault przez CSI.
Parametry zasobów i próbek - w wartościach z „rozsądnymi” standardami.

7. 3 Zależności i wspólny kod

Wspólne biblioteki wykresów dla wzorów (sondy, adnotacje, Polityka).
Zależności ("wymagania "/" Wykres. yaml') naprawić według wersji; unikać głębokich „lalek gniazdowania”.

7. 4 Szablony i kontrole

Użyj 'wymagane' i 'fail' w '_ helpers. tpl' dla wartości krytycznych.
Walidacja wartości - "schemat wartości. schemat. json '.
Badania na wykresie jednostkowym - „najbardziej jednolite sterowanie”; analiza statyczna - kubekonforma/kubeval.
Debugowanie lokalne - 'szablon helm' + '--values' + 'kubeconform'.

7. 5 Uwolnienia i przechowywanie

Wcisnąć wykres do rejestrów kontenerów OCI; tagi przez SemVer.
Helmfile/' helmfile. "dla orkiestry wielomarkowych snopów.
Artefakty CI: generowane manifesty + zależność od lockfile.

8) Przykład: Wdrożenie (fragment szablonu 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) Tajemnice i konfiguracje

Sekrety za pośrednictwem CSI (Vault/KMS) lub SOPS w repozytorium Git (klawisze GPG/KMS; „kubectl edit” jest zabronione).
ConfigMap/Tajne adnotacje kontrolne dla wyzwalacza zwalniania toczenia.
Nie przechowywać leku PAN/PII; używać tokenizacji.
Zamknięte sekrety są dozwolone, ale preferowane jest SOPS lub bezpośrednie CSI.

10) Sieć i obwód

Gateway API dla tras L7, kanarów i niebiesko-zielonych; sesje lepkie tylko wtedy, gdy jest to konieczne.
mTLS między usługami bez oczek/siatki (Cilium) - punkt dla rdzenia płatności.
Egress: kontrolowana lista węzłów zewnętrznych (PSP/KYC), stały budżet NAT-IP, harmonogram i przekaźnik.

11) Usługi i dane o statusie

W przypadku baz danych OLTP użyj zarządzanych usług w chmurze lub operatorów (Postgres/MySQL) w oddzielnych klastrach.
PVC/CSI z migawkami i polityką kopii zapasowych; „Powinowactwo” do replik.
Dla kolejek/streamingu - rozwiązania zarządzane lub dedykowane klastry; w „wspólnym” klastrze aplikacji zachować minimalny stan.

12) przenośnik CI/CD (odniesienie)

1. Build & test → 2) SCA/lint → 3) Obraz w rejestrze (SBOM, podpis) →

2. Generacja map Helm + 'helm unitest' + kubeconform →

3. SOPS odszyfrowanie w CD → 6) PR runtime w repozytorium GitOps →

4. Argo/Flux stosuje → 8) Argo Rollouts canary → 9) SLO Auto Verdict → 10) Promocja/Rollback.

13) Wskaźniki dojrzałości platformy

Udział wydań za pośrednictwem GitOps (cel: 100%).
Czas toczenia (P95) do gotowości, rolka MTTR.
Zasięg Namespace Pod Bezpieczeństwo i Polityka (cel: 100%).
% usług z HPA i poprawne żądania/limity.
% wykres z 'values. schemat. testy Jsona i jednostki.
Incydenty spowodowane „ręcznymi” zmianami (cel: 0).

14) Lista kontrolna wdrażania

1. Skupiska według stref, pula węzłów według profili; Ograniczenia PDB/Top.
2. Model przestrzeni nazw, Limit/Limit Range, minimum RBAC.
3. Pod Security (Restricted), domyślnie denizacja Zasad.
4. Gateway API/Ingress; kontrola wyjścia i utrwalenie NAT dla dostawców.
5. Obserwowalność: szlaki OTel, RED/USE, syntetyki geo; Deski rozdzielcze SLO.
6. GitOps (Argo/Flux), kanaryjski/niebiesko-zielony, auto-promocja przez metryki.
7. Standardy steru: struktura, schemat. json, testy, SOPS/Vault, rejestry OCI.
8. HPA/VPA, Cluster Autoscaler, ciepły basen do szczytów.
9. Operacje danych: migawki CSI, kopie zapasowe ,/zarządzanych operatorów baz danych.
10. Regularne testy DR/chaos i dni gry.

15) Anty-wzory

Jedno „gigantyczne” skupisko dla wszystkiego bez izolacji i kwot.
Kontenery bez ograniczeń zasobów, „najnowsze” znaczniki, brak sond.
Sekrety w 'values. yaml' w jasnym tekście, 'kubectl edit' w prod.
Wypuszcza GitOpy, ręczne edycje manifestów na żywo klastra.
Brak zasad/zabezpieczeń Pod - „płaska” sieć.
Pojedynczy wspólny sygnał HPA w całym procesorze dla różnych rodzajów obciążeń.
Przechowywanie baz danych OLTP w ramach „wspólnego” klastra aplikacji bez operatora i kopii zapasowych.

16) Kontekst iGaming/fintech: uwagi praktyczne

Webhaki płatnicze: dedykowane wejście/brama i wąskie wyjście do PSP; rygorystyczne terminy/przekaźniki; Pula indywidualna.
Ruch VIP: priorytety i trasy indywidualne; PDB i topologia rozprzestrzeniają się dla stabilności.
Turnieje/wybory: węzły ciepłej puli + predykcyjne HPA; podgrzewanie buforów/połączeń.
Raportowanie/CDC: oddzielny klaster/pula, tak aby ETL nie wpływały na Prod.
Regulacja: immutable logs (WORM), tokenizacja PII, segmentacja sieci.

Razem

Silna platforma Kubernetes nie jest „stertą YAML”, ale standardami: izolacja, polityka bezpieczeństwa, zasoby zarządzane, obserwowalność i dyscyplina GitOps. Wykresy Helm - Twój kontrakt na dostawy: Przewidywalne wydania, Sprawdzalne wzory, Bezpieczna tajna obsługa i proste Kickbacks. Konsolidując te zasady, otrzymujesz klastry, które przetrwają szczyty, przyspieszają uwolnienia i wytrzymują wymagania biznesowe i regulacyjne.