Aller au contenu
Kubernetes : réseau et exposition

Kubernetes : réseau et exposition

À la fin, vous saurez

  • Expliquer le modèle réseau de Kubernetes et ce que fait un plugin CNI
  • Suivre un paquet d'un pod à un autre, d'un nœud à un autre, et à travers un Service
  • Choisir et régler le mode de kube-proxy, ou le remplacer
  • Comprendre et régler le DNS du cluster
  • Exposer des applications avec Gateway API, TLS automatique et des règles de routage
  • Cloisonner le trafic avec des NetworkPolicies
  • Diagnostiquer méthodiquement un problème réseau dans un cluster

Prérequis

Ce cours prolonge Kubernetes : les fondamentaux, qui a présenté les Services, le DNS et l'exposition par Gateway API au niveau nécessaire pour déployer Signalements. Ici, on ouvre les boîtes : comment un pod obtient son adresse, comment un paquet traverse le cluster, ce que kube-proxy programme vraiment, pourquoi une résolution DNS est lente, comment obtenir des certificats sans y penser, et comment empêcher un pod compromis de parler à toute la base. Il s'adresse aux personnes qui exploitent des clusters ou qui doivent diagnostiquer leurs pannes réseau.

L'approche

Chaque leçon relie un mécanisme de Kubernetes aux notions du cours Le modèle TCP/IP : espaces de noms réseau et paires veth, routage, traduction d'adresses, DNS. Les exemples se font sur le cluster kind du cours précédent, auquel on ajoute Cilium et cert-manager, et le cours signale ce qui diffère sur Kapsule, le Kubernetes managé de Scaleway sur lequel Lyneko exploite ses applications avec Traefik.

Les manifestes sont écrits d'après la documentation de Kubernetes 1.36 et des projets cités, et validés localement ; les leçons ne présentent pas de sortie de commande inventée, et décrivent ce que vous devez observer.

Ce qu'il faut

  • Le cluster kind formation du cours précédent, recréé sans plugin réseau par défaut pour la leçon 2, ou un cluster Kapsule.
  • kubectl 1.36, Helm, et la CLI cilium pour les leçons qui l'utilisent.

Les leçons

  1. Le modèle réseau de Kubernetes
  2. Les plugins CNI
  3. Le chemin d'un paquet
  4. kube-proxy et ses alternatives
  5. Le DNS du cluster
  6. Gateway API en production
  7. TLS et cert-manager
  8. Les NetworkPolicies
  9. IPv6, double pile et maillage de services
  10. Diagnostiquer le réseau d'un cluster

Pour valider : le quiz (niveau 100) et le lab (niveau 200).

Plan du cours

  1. Le modèle réseau de Kubernetes 1 h 10 200 Pratiquer
    Les trois exigences du réseau de Kubernetes (une adresse par pod, des pods qui se joignent sans traduction d'adresse, des agents qui joignent les pods de leur nœud), les plages d'adresses des pods et des Services, ce que Kubernetes délègue au plugin CNI, l'espace de noms réseau partagé d'un pod, et ce que ce modèle plat implique pour la sécurité.
  2. Les plugins CNI 1 h 15 200 Pratiquer
    L'interface CNI et ce qu'un plugin fait quand un pod naît ou meurt (ADD, DEL, CHECK, fichiers de configuration, binaires, IPAM), les trois grandes façons de joindre des pods sur des nœuds différents (routage direct, encapsulation VXLAN ou Geneve, BGP), un panorama de Cilium, Calico, Flannel et kindnet, l'installation de Cilium sur un cluster kind sans plugin, et comment choisir.
  3. Le chemin d'un paquet 1 h 20 300 Concevoir
    Suivre un paquet dans un cluster Kubernetes : pod à pod sur un même nœud (veth, pont ou eBPF), entre nœuds (route ou tunnel), vers un Service (DNAT), au retour (conntrack), vers Internet (masquerade) et depuis l'extérieur (NodePort, LoadBalancer, externalTrafficPolicy Local ou Cluster), avec les commandes pour l'observer.
  4. kube-proxy et ses alternatives 1 h 20 300 Concevoir
    Ce que kube-proxy programme dans chaque nœud : les chaînes iptables KUBE-SERVICES, KUBE-SVC et KUBE-SEP et leurs probabilités, le mode nftables (stable depuis Kubernetes 1.33), ipvs (déprécié), le remplacement complet par Cilium, les pièges de conntrack, l'affinité de session, la distribution topologique du trafic, et comment lire les règles dans un nœud.
  5. Le DNS du cluster 1 h 15 200 Pratiquer
    Comment le DNS d'un cluster Kubernetes fonctionne : CoreDNS et son Corefile (kubernetes, forward, cache, loop, health, ready), les enregistrements des Services et des pods, le resolv.conf d'un pod, ndots:5 et ses requêtes multiples, dnsPolicy et dnsConfig, NodeLocal DNSCache, les timeouts de 5 secondes dus à conntrack, le dimensionnement et les métriques de CoreDNS.
  6. Gateway API en production 1 h 30 300 Concevoir
    Exploiter Gateway API au-delà de la première route : les trois rôles et ce qu'ils possèdent, GatewayClass, Gateway et HTTPRoute en détail, plusieurs listeners et allowedRoutes, ReferenceGrant entre namespaces, correspondances, filtres, répartition pondérée pour un déploiement canari, timeouts et retries (canal standard et expérimental), lecture du statut, Traefik comme implémentation et migration depuis Ingress avec ingress2gateway.
  7. TLS et cert-manager 1 h 15 200 Pratiquer
    Servir Signalements en HTTPS sans jamais renouveler un certificat à la main : terminaison TLS à la Gateway, Secret kubernetes.io/tls, cert-manager (Issuer, ClusterIssuer, Certificate), ACME et Let's Encrypt, défis HTTP-01 et DNS-01 (webhook Scaleway), annotation sur la Gateway, environnement staging et limites de débit, renouvellement et raccourcissement annoncé des durées de vie, TLS jusqu'au pod avec BackendTLSPolicy, mTLS en mention.
  8. Les NetworkPolicies 1 h 30 300 Concevoir
    Cloisonner le trafic d'un cluster : le réseau plat par défaut, la sémantique exacte d'une NetworkPolicy (sélection, ingress et egress, règles additives, refus implicite), le refus par défaut d'un namespace, l'autorisation du DNS en sortie, la chaîne Gateway, Signalements, PostgreSQL, le piège de l'ET et du OU entre namespaceSelector et podSelector, ipBlock, ports et endPort, qui applique les politiques (kindnet, Cilium), CiliumNetworkPolicy et AdminNetworkPolicy en mention, et comment tester.
  9. IPv6, double pile et maillage de services 1 h 20 300 Concevoir
    Deux sujets d'architecture réseau avancés : la double pile IPv4 et IPv6 de Kubernetes (ipFamilies, ipFamilyPolicy, plages des deux familles, kind en double pile, ce que propose Kapsule), puis le maillage de services (mTLS automatique, retries, observabilité L7), ses architectures avec sidecars ou sans, son coût, quand s'en passer, et Gateway API pour le maillage (GAMMA).
  10. Diagnostiquer le réseau d'un cluster 1 h 40 300 Concevoir
    Une méthode couche par couche pour trouver une panne réseau dans Kubernetes : le pod de diagnostic (netshoot, kubectl debug sur un nœud), les six questions dans l'ordre (DNS, Service et EndpointSlices, politique réseau, CNI et routes, MTU, conntrack), les outils (Hubble, cilium connectivity test, tcpdump sur le nœud, nsenter), puis six scénarios corrigés sur Signalements.

Sources