Kubernetes: Klastry i mapy Helm

Kubernetes: Klastry i mapy Helm

1) Architektura klastra - Top View

Płaszczyzna sterowania: 'kube-apiserver', 'etcd',' kube-scheduler ',' kube-controller-manager '(część jest ukryta w kontrolowanych chmurach).
Pracownik: 'kubelet', runtime CRI (containerd/CRI-O), wtyczka CNI, kube-proxy/ebpf-proxy.

Sieć intraclusterowa: Pod-to-Pod, Service-VIP/ClusterIP, DNS

Przechowywanie: sterowniki CSI, dynamiczne dostarczanie PVC → PV ( Class).
Granice awarii: węzeł/AZ/region. Umieść repliki w podziale na strefy (Top/anty-powinowactwo).

Typowe role

Polecenie platformy: tworzy/uaktualnia klastry, CNI/CSI/Ingress, zasady i GitOps.
Zespoły produktów: wykresy/wydania depozytów, przestrzegaj zasad bezpieczeństwa i zasobów.

2) Cykl życia klastra

Tworzenie: Kops, kubeadm, Rancher, EKS/AKS/GKE. Włącz uwierzytelnianie i audyt OIDC od razu.
Aktualizacje: drobne wersje z kolei (płaszczyzna sterowania → węzły), kontrolowane przez maxNiedostępne, testy na etapie.
Dodatki (wszystkie za pośrednictwem Helm/GitOps): CNI (Calico/Cilium), sterownik CSI, kontroler Ingress (NGINX/Gateway API/Contour/Traefik), Metrics-Server, Cluster-Auto oscaler, Node-Local DNS, logging/metrics/trace.
Kopie zapasowe: etcd snapshot (jeśli self-managed), Velero dla przestrzeni nazw/PVC.

3) Sieci, usługi i ingress

CNI: Calico, Cilium (eBPF/servicemesh-била).
Usługa: „ClusterIP”, „NodePort”, „LoadBalancer” (równoważenie chmury L4), „Nazwa użytkownika”.
Ingress/Gateway API: L7 routing, TLS, rate-limit/WAF historia na obwodzie.
• Zasady: Deeny-all + explicit allow by namespace/label domyślnie.
Usługa bezgłowa ('clusterIP: None') dla programu Stat Set i service discovery.

4) Składowanie (CSI) i stany

„Klasa”: „Polityka odzyskiwania”, „Tryb ” („WaitForاConsumer” dla lepszego umieszczenia).
Stat Set: stabilne nazwy/woluminy ('Szablony'), 'pod Zasady: Równoległe' dla szybkich skanów.
Czytelnia Wielu: używać pliku rozproszonego (EFS/Filestore) ostrożnie - ocenić opóźnienia.
Migawki: 'SnapshotClass' + kopie zapasowe cron.

5) Wielozatrudnienie i polityka

Przestrzenie nazw według produktu/środowiska.
RBAC: minimalne role, oddzielne konta usług, „Rola ”/„ Wiązanie” zamiast „Rola klastra” w miarę możliwości.
PSA (Pod Security Admission): tryby „baseline ”/„ restricted” (zastąpienie PSP).
Limit/Limit Range: мотолка CPU/Memory/PVC/LoadBalancer.
OPA Gatekeeper/Kyverno: polityka przyjmowania (np. zakaz „: najnowszy”, wymaganie „zasoby”, „czytelnieRootFilesystem”).
ImagePolicy/webhooks: weryfikacja podpisu obrazu (cosign/policy-controller).

6) Obserwowalność i działanie

Wskaźniki: stos Prometeusza, kube-state-metrics, eksporterzy węzłów.
Dzienniki: Fluent Bit/Vector → object/ES/OpenSearch, obrót w węzłach.
Szlaki: OpenTelemetry Collector.
Deski rozdzielcze SLO: model RED w zakresie wnikania i kluczowych usług.
Autoskale: HPA (według mierników aplikacji), VPA dla tła, Cluster-Autoscaler dla węzłów.

7) Manifest wzorów (oszukać arkusz)

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: api, labels: { app: api } }
spec:
replicas: 3 strategy: { type: RollingUpdate, rollingUpdate: { maxUnavailable: 0, maxSurge: 1 } }
selector: { matchLabels: { app: api } }
template:
metadata:
labels: { app: api }
spec:
serviceAccountName: api-sa securityContext: { runAsNonRoot: true, fsGroup: 2000 }
containers:
- name: api image: registry. example. com/api:1. 2. 3 ports: [{ containerPort: 8080 }]
resources: { requests: { cpu: "200m", memory: "256Mi" }, limits: { cpu: "1", memory: "512Mi" } }
readinessProbe: { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez,  port: 8080 }, initialDelaySeconds: 20 }

yaml apiVersion: apps/v1 kind: StatefulSet metadata: { name: db }
spec:
serviceName: db replicas: 3 podManagementPolicy: Parallel selector: { matchLabels: { app: db } }
template:
metadata: { labels: { app: db } }
spec:
containers:
- name: db image: postgres:16-alpine volumeMounts: [{ name: data, mountPath: /var/lib/postgresql/data }]
volumeClaimTemplates:
- metadata: { name: data }
spec:
accessModes: ["ReadWriteOnce"]
resources: { requests: { storage: 100Gi } }
storageClassName: fast-ssd

yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: { name: api-pdb }
spec:
minAvailable: 2 selector: { matchLabels: { app: api } }

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api annotations:
nginx. ingress. kubernetes. io/proxy-read-timeout: "30"
spec:
tls: [{ hosts: ["api. example. com"], secretName: api-tls }]
rules:
- host: api. example. com http:
paths:
- path: /
pathType: Prefix backend: { service: { name: api, port: { number: 80 } } }

8) Helm v3 - podstawy i struktura

Wykres = szablony + wartości + metadane.

mychart/
Chart. yaml     # name, version (semver), type (application/library), dependencies values. yaml # default values. schema. json # (recommended) validation values templates/# .yaml. gotmpl (Deployment, Service, Ingress, …)
templates/tests/  # helm tests (smoke)
charts/# local dependencies (or OCI dependencies)

yaml apiVersion: v2 name: api description: API service type: application version: 1. 4. 0 # chart version (semver)
appVersion: "1. 2. 3" # dependencies application version:
- name: redis version: 17. x.x repository: "oci://registry. example. com/charts"

9) Szablony Helm - Praktyki

Użyj pomocników w '_ helpers. tpl' dla nazw/etykiet/adnotacji.
Wszędzie należy określić „zasoby”, „ Context”, „gotowość/aktywność”.
Generowanie etykiet zgodnie ze znormalizowanym schematem ('app. kubernetes. io/').
Opcjonalne funkcje poprzez 'values' (ingress/hpa/pdb/servicemonitor).
W tym 'values. schemat. json '- stop from incorrect configs.
Dla danych wrażliwych - Tajemnice przed zewnętrznymi operatorami (Tajemnice zewnętrzne, SOPS), a nie przechowywać w wartościach.

gotmpl
{{- define "api. fullname" -}}
{{- printf "%s-%s".Chart. Name. Release. Name      trunc 63      trimSuffix "-" -}}
{{- end -}}

gotmpl apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "api. fullname". }}
labels: {{- include "api. labels". nindent 4 }}
spec:
replicas: {{.Values. replicaCount }}
strategy:
rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{- include "api. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{- include "api. selectorLabels". nindent 8 }}
spec:
serviceAccountName: {{ include "api. serviceAccountName". }}
securityContext: {{- toYaml. Values. podSecurityContext      nindent 8 }}
containers:
- name: {{.Chart. Name }}
image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports: [{ containerPort: {{.Values. service. port }} }]
resources: {{- toYaml. Values. resources      nindent 10 }}
envFrom:
- secretRef: { name: {{.Values. secretsRef }} }

10) Zależności, repozytoria i OCI

Helm v3 obsługuje rejestry OCI: 'oci ://registry/org/charts'.
Wersje zależności blokady ('^ 1. 2. 0`, `~1. 2 ") i uruchomić" budowę zależności sterowej ".
Podpisz wykres (np.), przechowuj artefakty w repozytorium artefaktów CI.
Wykresy biblioteki: ogólne szablony (ingress/servicemonitor) do ponownego użycia.

11) Haczyki, CRD i porządek operacji

Haczyki: 'pre-install', 'post-install', 'pre-upgrade', 'post-upgrade', 'test'. Dodaj politykę („przed-hook-creation”, „hook-succeeded”).
CRD: umieścić w 'crds/' (ustawić na szablony), unikać aktualizacji CRD na muchę - migrować oddzielnie.
Migracja/inicjalizacja bazy danych - hak pracy z idempotencją i terminami.

12) Badanie wykresu i CI

„helm lint” + zatwierdzenie programu.
Helm unitest (unit), chart-testing (ct) - montaż/montaż w rodzaju/minikube w CI.
Migawki testy szablonów ('szablon helm' → porównaj z szablonem).
Badania dymu "test sterowy" (podnieść "Pod 'z kontroli).

13) GitOps (Argo CD/Flux)

Źródłem prawdy jest repozytorium. Wykres jest przechowywany jako HelmRelease/HelmChart (Flux) lub Application (Argo).
Polityka zlewu: automatyczna synchronizacja z suszonym/samouzdrowionym, statusami i kontrolą zdrowia.
Wersje promocyjne: tag-bots/semver-range, PR-flow.
Podziel repo na aplikacje (wykresy) i wy (nadrzędne/wartości).
Tajne zarządzanie: SOPS (age/KMS), Tajemnice zewnętrzne.

14) Bezpieczeństwo: wymagane minimum

Ograniczony PSA: brak uprawnień, brak Ścieżka, ograniczone możliwości, korzenie tylko do odczytu.
ImagePolicy - tylko zdjęcia podpisane/zaufane.
Polityka: „domyślnie zablokowana”.
RBAC: konto usługi na aplikację, „Rola ”/„ Oprawa” w obszarze nazw.
Kontrola wstępu: Gatekeeper/Kyverno (zasoby/limity, etykiety, brak najnowszych).
Tajemnice: SOPS/Tajemnice zewnętrzne; nie umieszczać tajemnic w wartościach/zwykłym Git.

15) Anty-wzory

„: najnowsze” na wykresach i obrazach; brak 'wartości. schemat. json '.
Jeden ogromny wykres „za wszystko” zamiast modułowego.
CRD są aktualizowane z szablonami w 'szablony/' → chaos na aktualizacjach.
Nazwy twarde/port/obszar nazw w szablonach.
Brak zasobów/limitów i próbek → opóźnienie dryfu i niestabilność.
Brak PDB → zero przestojów nie jest możliwe z drenażem/uaktualnieniami.
Sekrety w Git bez szyfrowania; manifestuje się bez polityki kontroli.

16) Lista kontrolna wdrażania (0-45 dni)

0-10 dni

Utwórz podstawowy szkielet wykresu z '_ helpers. tpl', etykiety, sondy, zasoby, opcjonalnie PDB/Ingress.

Вкла бита PSA restricted,,,,,,,,,,,,,,,,

Konfiguracja GitOps (Argo/Flux), prywatny rejestr, sygnatura obrazu/wykresu.

11-25 dni

Podziel wykres na moduły/zależności, dodaj 'values. schemat. json ", badania (" helm lint ", jednostka, ct).
Podłączyć obserwowalność (• Monitor/PodMonitor), środki logarytmiczne, OTel.
Wprowadź proces uaktualniania: ustawianie → kanarka → prod, hak migracji z rollback.

26-45 dni

Zautomatyzuj aktualizacje zależności (boty/semver-ranges + PR).
Dodaj zasady i raporty polityki Gatekeeper/Kyverno do CI.
Dokumentacja uruchamiania aktualizacji klastra, procedury DR (migawka Velero/etcd).

17) Wskaźniki zapadalności

100% aplikacji jest zubożonych poprzez Helm/GitOps, bez 'kubectl apply' manally.
Wszystkie wykresy mają 'wartości. schemat. json ', testy, podpis i wersje uzależnienia.
We wszystkich obszarach nazw jest włączona ograniczona/Regulacja PSA.
PDB i HPA są obecne we wszystkich usługach krytycznych.
SOPS/Tajemnice zewnętrzne, brak najnowszych zasad, podpis obrazu.
Aktualizacje klastra i wykresu są wykonywane bez przestoju (kanaryjski/niebiesko-zielony), testy przywracania są regularne.

18) Wniosek

Strong Kubernetes foundation = solidna architektura klastra + ścisła polityka + przemysłowa jakość map Helm zarządzanych przez GitOps. Standaryzuj szablony, zabezpiecz środowisko PSA/اPolicy/RBAC, zatwierdzaj wartości i zautomatyzuj testy, podpisywanie i promocję. Następnie aktualizacje i wydania staną się przewidywalne, a platforma stanie się stabilna i wygodna dla zespołów produktów.