Quiz : Kubernetes, réseau et exposition

Chaque pod a sa propre adresse ; tous les pods se joignent sans traduction d'adresse ; les agents d'un nœud joignent les pods de ce nœud. Kubernetes décrit ce résultat, le plugin CNI le réalise (interfaces, adresses, routes). Leçons 1 et 2.

L'encapsulation ajoute environ 50 octets d'en-têtes à chaque paquet entre nœuds. Si la MTU des interfaces des pods n'est pas réduite d'autant, les gros paquets dépassent la MTU du réseau physique et sont fragmentés ou perdus, avec les symptômes classiques du trou noir PMTU. Leçons 2 et 10.

Avec kube-proxy, par une traduction d'adresse de destination dans le noyau du nœud de départ, avant le routage (chaînes PREROUTING ou OUTPUT), retenue par conntrack pour réécrire la réponse. Avec Cilium sans kube-proxy, dès l'appel connect() de la socket, par un programme eBPF : le paquet part directement vers l'adresse du pod. Leçons 3 et 4.

On préserve l'adresse source du client (pas de traduction vers l'adresse d'un nœud) et l'on évite un saut supplémentaire. En contrepartie, un nœud ne sert que ses propres pods : le répartiteur doit éviter les nœuds sans pod de l'application, grâce au port de vérification de santé (healthCheckNodePort), sinon des requêtes sont perdues. Leçons 3 et 10.

Non, pas tout de suite : kube-proxy n'est sur le chemin d'aucun paquet, il programme le noyau. Les règles déjà en place continuent de fonctionner ; ce sont les changements (nouveaux pods, Services) qui ne sont plus pris en compte sur ce nœud. Leçon 4.

Avec ndots:5, un nom qui contient moins de cinq points est d'abord essayé avec chacun des domaines de recherche du cluster (signalements.svc.cluster.local, etc.), en A et en AAAA, avant le nom tel quel. On écrit le nom complet avec un point final (api.exemple-partenaire.fr.), ou l'on réduit ndots par dnsConfig. Leçon 5.

Une course dans conntrack entre les requêtes A et AAAA envoyées en même temps en UDP depuis la même socket : l'une est perdue, et le client attend son délai de 5 secondes avant de réessayer. Le remède de fond est NodeLocal DNSCache ; des options du résolveur peuvent aussi l'atténuer. Leçon 5.

Une ReferenceGrant dans le namespace de la cible, qui autorise les HTTPRoute du namespace signalements à référencer ses Services. Une référence entre namespaces doit être acceptée des deux côtés. Leçon 6.

Avec deux backendRefs pondérés dans la règle de la HTTPRoute (par exemple weight: 90 vers la version stable, weight: 10 vers la nouvelle), que l'on fait évoluer. La répartition se fait par requête. Leçon 6.

HTTP-01 prouve le contrôle du domaine en servant un jeton sur le port 80 : simple, mais il faut que le domaine pointe déjà vers le cluster et que le port 80 soit joignable, et il ne permet pas de certificat joker. DNS-01 publie un enregistrement TXT dans la zone : il fonctionne sans exposition et permet les jokers, mais il faut donner à cert-manager un accès en écriture à la zone (webhook pour Scaleway), à restreindre. Leçon 7.

Le DNS : les pods ne peuvent plus joindre CoreDNS (port 53 en UDP et TCP vers kube-system), donc aucun nom ne se résout. Il faut une règle de sortie qui l'autorise explicitement. Leçons 5 et 8.

Dans un même élément, les deux sélecteurs se combinent en ET : seuls les pods choisis dans les namespaces choisis. Dans deux éléments, ils se combinent en OU : tous les pods des namespaces choisis, plus les pods choisis du namespace de la politique. Un tiret de trop dans le YAML ouvre tout un namespace. Leçon 8.

Les deux côtés, s'ils sont sélectionnés par des politiques : la sortie de A et l'entrée de B. Le trafic de retour suit automatiquement. Les politiques s'additionnent : il n'existe pas de règle de refus dans les NetworkPolicies standard. Leçon 8.

Quand beaucoup de services et plusieurs équipes ont besoin de mTLS automatique, d'autorisation par identité, de résilience (réessais, délais) et d'observabilité L7 uniformes. Il coûte des ressources, de la latence et de la complexité. Pour une application comme Signalements, TLS à l'entrée, NetworkPolicies et métriques suffisent. Leçon 9.

Appeler par le nom (DNS compris), par l'adresse du Service (sans DNS), puis par l'adresse d'un pod (sans Service). Le premier qui réussit borne la panne : DNS si seul le nom échoue, Service ou EndpointSlices si l'adresse du pod répond mais pas celle du Service, application, politique ou réseau si même le pod ne répond pas. Leçon 10.