Aller au contenu
learn

Kubernetes — Mission

Je sais construire une image et la lancer ; le cours Conteneurs WSL s’arrête là. Puis quelqu’un dit « déploie-la sur le cluster », et je copie un fichier YAML d’un autre service, je change le nom, et j’espère. Quand un pod redémarre en boucle, ou qu’un Service ne répond rien, j’essaie des choses jusqu’à ce que ça marche, sans savoir laquelle a marché.

Je veux savoir ce que Kubernetes fait de ce que je déclare : quel composant agit dessus, dans quel ordre, et ce que signifie chaque état et chaque événement. Pour écrire des manifestes en connaissance de cause, déployer sans interrompre le service, et trouver ce qui ne va pas à partir des réponses du cluster lui-même.

Vous êtes développeur C# ou Java, et vous avez déjà construit et lancé une image de conteneur. Vous n’avez pas besoin de connaître Kubernetes ni le réseau Linux. Les images viennent de la leçon 4 de Conteneurs WSL ; les leçons sur la CI vous renvoient à GitHub Actions, et la leçon 13 à RabbitMQ pour son opérateur Kubernetes.

Les deux petites API web du cours Conteneurs WSL, une API minimale ASP.NET Core et une API Spring Boot WebFlux, tournent sur un cluster kind d’un seul nœud. Chaque leçon ajoute ce dont un vrai déploiement a besoin : sondes et ressources, mises à jour progressives, adresse stable, configuration, stockage, sécurité, empaquetage.

flowchart LR
client["client<br/>curl, navigateur"] --> gw{{"Gateway<br/>csharp.example.test<br/>java.example.test"}}
gw --> svc1["Service csharp-api"]
gw --> svc2["Service java-reactor-api"]
svc1 --> d1["Deployment csharp-api<br/>3 pods, ASP.NET Core"]
svc2 --> d2["Deployment java-reactor-api<br/>2 pods, Spring Boot"]

Guitar Alchemist tourne sur Docker Compose et .NET Aspire, avec un chantier Kubernetes prévu ; la leçon 2 compare les sondes de son guide de déploiement avec ses images.

  • expliquer ce que le serveur d’API, etcd, l’ordonnanceur, les contrôleurs et le kubelet font chacun d’un manifeste ;
  • lancer un cluster local avec kind, et utiliser kubectl dessus sans toucher à mes autres clusters ;
  • écrire des pods avec les bonnes sondes, requests et limits, et lire leurs conditions et leurs événements ;
  • déployer les API C# et Spring avec des mises à jour progressives, et revenir en arrière après une version ratée ;
  • leur donner une adresse stable dans le cluster et hors du cluster, avec les Services, le DNS, la Gateway API et Ingress ;
  • les configurer, leur donner du stockage, et exécuter des tâches et des agents par nœud ;
  • contrôler où les pods tournent, combien tournent, et ce qu’ils ont le droit de faire ;
  • empaqueter un déploiement avec Helm et Kustomize, et le livrer en GitOps ;
  • dépanner CrashLoopBackOff, ImagePullBackOff, Pending et OOMKilled à partir des informations du cluster lui-même ;
  • savoir ce qui change sur AKS, EKS et GKE.
# Leçon Vous connaissez peut-être
1 Architecture et cluster local docker run, Docker Compose, une politique de redémarrage
2 Pods les health checks d’ASP.NET Core, Spring Boot Actuator, docker logs
3 Deployments les déploiements blue/green, les emplacements de déploiement d’Azure App Service
4 Services et DNS un reverse proxy, YARP, Spring Cloud Gateway, /etc/hosts
5 Configuration : ConfigMaps et Secrets (prochainement) appsettings.json, application.yml, les variables d’environnement
6 Stockage : volumes, PersistentVolumes, StatefulSets les volumes Docker, une base de données dans un conteneur
7 Jobs, CronJobs et DaemonSets BackgroundService, @Scheduled, un service Windows
8 Ordonnancement : affinités, taints, répartition topologique, priorités, budgets de perturbation
9 Mise à l’échelle : HPA, metrics-server, VPA, cluster autoscaler les règles de scale-out d’App Service
10 Sécurité : RBAC, ServiceAccounts, Pod Security Standards, NetworkPolicies les stratégies d’autorisation d’ASP.NET Core, Spring Security
11 Empaquetage : Helm et Kustomize NuGet et Maven, appsettings.Production.json
12 Observabilité et dépannage OpenTelemetry, dotnet-counters, Micrometer
13 Étendre Kubernetes : CRD et opérateurs
14 Livraison continue : GitOps avec Argo CD ou Flux, CI avec GitHub Actions GitHub Actions
15 En production : AKS, EKS, GKE, coûts, mises à jour Azure, AWS ou Google Cloud

Journal : ce que j’ai essayé, ce qui m’a surpris, ce qu’il me reste à vérifier.