Technologies et infrastructures → Kubernetes-clusters et Helm-charts

Kubernetes-clusters et Helm-charts

1) Le rôle de Kubernetes et Helm

Kubernetes est la base de la plate-forme d'application : standardise le déroulement, le réseau, les configues, les secrets et l'auto-récupération. Helm est un gestionnaire de packages/modèles qui transforme les manifestes déclaratifs en versions reproductibles avec gestion des versions et des dépendances. Ensemble, ils donnent des déployages prévisibles, des reculs rapides et un langage d'infrastructure unique.

2) Conception de cluster

2. 1 Topologie et tolérance aux pannes

Multi-AZ : plane de contrôle et les noeuds des pools de travail sont répartis dans les zones ; PDB/TopologySpreadConstraints pour l'uniformité.
Multiregion/DR : clusters per-region indépendants ; appels interrégionaux - uniquement sur les voies « froides » (catalogues/télémétrie), « chaudes » (porte-monnaie) - localement.
Pools Worker par profils : 'general', 'compute', 'io', 'spot' (pour les tâches d'arrière-plan). Affectation via nodeSelector/affinity/taints.

2. 2 Espaces de noms et modèle multijoueur

Isolation namespace par domaine/commande : 'payments', 'wallet', 'games', 'reporting'.
ResourceQuota + LimitRange : limites de base CPU/RAM et un maximum de répliques ; protection de la grappe contre les « aspirateurs ».
RBAC : rôles read-only par défaut, write - uniquement CI/CD et on-call.

2. 3 Réseau

CNI avec prise en charge de NetworkPolicy (Calico/Cilium) : L3/L4 des politiques sur namespace/label.
Ingress → Gateway API : passage au modèle 'GatewayClass/Gateway/HTTPRoute' pour les canaries et beaucoup de ténacité.
Service Mesh (en option) : mTLS, retry/breaker, locality-aware ; inclure des points pour la fiabilité interservices.

3) Fiabilité et mise à l'échelle

3. 1 Skaling

HPA par métriques utilisateur (RPS/latency/queue depth) et pas seulement CPU.
VPA dans la classe de charge de fond ; dans la vente - « recommandation only » ou en collaboration avec HPA sur différentes mesures.
Cluster Autoscaler : groupes de node distincts pour les services sensibles ; warm-pool aux pics (tournois/matchs).

3. 2 Ressources et QoS

Chaque Pod a des demandes/limites ; éviter ': latest' et les conteneurs « illimités ».
PrioritéClasse : les services critiques (« wallet », « payments ») remplacent les services non critiques.
PDB : ne laissons pas le cluster « tirer dans la jambe » lors du renouvellement des nodules.

3. 3 Mises à jour sans interruption

RollingUpdate c maxUnavailable = 0 sur les chemins critiques.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Capacité de Surge pour des sorties rapides pendant les pics - avec soin.

4) Sécurité de la plate-forme

Pod Security (Baseline/Restreinte) au niveau namespace ; interdiction de 'privilégieged', hostPath, root.
NetworkPolicy : default-deny et listes blanches par port/label.
Seccomp/AppArmor, non-root users, read-only rootfs.
Secrets : Fournisseur de KMS/Vault (CSI), ne gardons pas de secrets dans 'values. yaml'en ouvert.
RBAC-minimum : les comptes de service ne délivrent que les droits nécessaires ; les jetons sont de courte durée.
Admission-contrôle : OPA/Gatekeeper/Kyverno - étiquettes enforce, limites, violations des politiques.

5) Observability

OpenTelemetry : Tracing by Ingress/Gateway → service → BD/cache, labels obligatoires « service », « version », « région », « partner », « api _ version ».
Logs : structurés, sans PII/PAN ; le routage vers le stockage centralisé.
Métriques : RED/USE, SLO-dashboards, burn-rate alert.
Synthétique : échantillons provenant des bons pays/ASN ; périmètre et contrôles de santé internes.

6) GitOps и progressive delivery

Argo CD/Flux : l'état désiré est stocké dans Git ; chaque namespace est son propre référentiel/dossier.
Promotion d'artefacts : "dev → stage → prod'via PR et non" kubectl apply ".
Canary/Blue-Green: Argo Rollouts/Gateway API; les métriques du succès sont le P95/P99, le taux d'erreur, le SLI des affaires (CR dépôts).
Retouches : en Helm/Argo - par bouton ; dans les charts - les versions sont fixes.

7) Helm : meilleures pratiques

7. 1 Structure de la charte

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 'est une version chart (BouVer),' appVersion 'est une version de l'application (image).
• Noms de ressources stricts : '{{include' svc. fullname".}}' + labels' app. kubernetes. io/`.
• Manifestes obligatoires : Deployment/StatefulSet, Service, ServiceAccount, HPA (le cas échéant), PDB, NetworkPolicy.

7. 2 Valeurs-stratégie

Valeurs de base. yaml 'est un défaut, sans secrets et encerclement spécifique.
Overrides : 'values- {stage' prod} .yaml' + fichiers par région.
Secrets : SOPS ('values-prod. sops. yaml ') ou Vault-injection par CSI.
Les paramètres des ressources et des échantillons sont en valeurs avec des défauts « raisonnables ».

7. 3 dépendances et code commun

Cartes-bibliothèques générales pour les patterns (probes, annotations, NetworkPolicy).
Dépendances ('requirements '/' Chart. yaml') fixer selon la version ; évitez les « matelas » profonds.

7. 4 Modèles et vérifications

Utilisez 'required' et 'fail' dans '_ helpers. tpl 'pour les valeurs critiques.
Validation du schéma values - 'values. schema. json`.
Les tests unitaires sont « helm unittest » ; l'analyse statique est kubeconform/kubeval.
Le débogage local est 'helm template' + '--values' + 'kubeconform'.

7. 5 Sorties et stockage

Tableau push dans les registres OCI des conteneurs ; tags par BouVer.
Helmfile/`helmfile. d'pour l'orchestration de lames polynomiales.
Artefacts CI : manifestes générés + dépendances lockfile.

8) Exemple : Deployment (fragment de modèle 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) Secrets et configurations

Secrets via CSI (Vault/KMS) ou SOPS dans le référentiel Git (clés GPG/KMS ; interdiction de « kubectl edit »).
BouMap/Secret checksum annotation pour le déclencheur rolling-release.
Ne pas conserver le PAN/PII ; utiliser la tokenisation.
Sealed Secrets est autorisé, mais préférable à SOPS ou CSI direct.

10) Réseau et périmètre

API Gateway pour L7-routing, Canaries et bleu-vert ; sticky-session uniquement lorsque nécessaire.
mTLS entre les services via mesh/sidecar-less (Cilium) - point pour le noyau de paiement.
Egress : liste contrôlée des nœuds externes (PSP/KYC), NAT-IP fixes, temporisation et budget des retraits.

11) Services et données de Stateful

Pour les bases de données OLTP, utilisez des services cloud gérés ou des opérateurs (Postgres/MySQL) dans des clusters distincts.
PVC/CSI avec la politique des snapshots et des backups ; 'PodAntiAffinity' pour les répliques.
Pour les files d'attente/streaming - solutions gérées ou clusters dédiés ; dans un cluster d'applications « général », garder un minimum d'état.

12) convoyeur CI/CD (référence)

1. Build & test → 2) SCA/lint → 3) Image dans le registre (SBOM, signature) →

2. Génération de la carte Helm + 'helm unittest' + kubeconform →

3. SOPS-decript dans le classement CD → 6) PR dans le dépôt GitOps →

4. Argo/Flux applique → 8) Argo Rollouts canary → 9) Auto-verdict sur SLO → 10) Promotion/retour.

13) Métriques de la maturité de la plateforme

Part des sorties via GitOps (objectif : 100 %).
Temps de déroulement (P95) jusqu'à la disponibilité, MTTR de retour.
Couverture Namespace des Pod Security et NetworkPolicy (objectif : 100 %).
% des services avec HPA et requests/limites corrects.
% chart avec 'values. schema. json 'et les tests unitaires.
Incidents causés par des modifications « manuelles » (objectif : 0).

14) Chèque de mise en œuvre

1. Clusters par zone, pool de nœuds par profil ; PDB/TopologySpreadConstraints.
2. Modèle Namespace, ResourceQuota/LimitRange, RBAC minimum.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; contrôle egress et fixation NAT aux fournisseurs.
5. Observability : OTel tracés, RED/USE, synthétiques par géo ; SLO-dashboards.
6. GitOps (Argo/Flux), canary/blue-green, auto-mesure.
7. Normes Helm : structure, schema. json, tests, SOPS/Vault, registres OCI.
8. HPA/VPA, Cluster Autoscaler, warm-pool aux pics.
9. Opérations de données : snapshots CSI, backups, opérateurs/bases de données gérées.
10. Des tests de DR/chaos réguliers et des journées de jeu.

15) Anti-modèles

Un cluster « géant » pour tout sans isolement ni quotas.
Conteneurs sans limite de ressources, balises 'latest', pas de probes.
Les secrets dans 'values. yaml 'en ouvert,' kubectl edit 'en vente.
Les versions sont passées par GitOps, les modifications manuelles des manifestes sur le cluster en direct.
L'absence de NetworkPolicy/Pod Security est un réseau « plat ».
Signal HPA commun unique par CPU pour les charges variées.
Stockez une base de données OLTP dans un cluster d'applications « partagé » sans opérateur ni backup.

16) Contexte iGaming/fintech : notes pratiques

Webhooks de paiement : ingress/gateway dédié et egress étroit à PSP ; des délais/retraits stricts ; un pool de nœuds séparé.
Trafic VIP : hiérarchisation et itinéraires séparés ; PDB et spread topology pour la stabilité.
Tournois/pics : noeuds warm-pool + HPA prédictif ; chauffage des caches/connexions.
Reporting/CDC : cluster/pool séparé afin que l'ETL n'affecte pas la prod.
Régulation : Logs immuables (WORM), Tokenization PII, segmentation des réseaux.

Résultat

Une plate-forme Kubernetes forte n'est pas un « tas de YAML », mais des normes : isolation, politique de sécurité, ressources gérées, observabilité et discipline GitOps. Helm-charts est votre contrat de livraison : versions prévisibles, modèles testables, travail sécurisé avec des secrets et des retraits simples. En consolidant ces principes, vous obtiendrez des grappes qui connaissent des pics, accélèrent les sorties et résistent aux exigences des entreprises et des régulateurs.