Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Trafic réseau des applications via des déconnexions réseau
Les rubriques de cette page sont liées à la mise en réseau des clusters Kubernetes et au trafic des applications lors des déconnexions réseau entre les nœuds et le plan de contrôle Kubernetes.
## Cilium
Cilium dispose de plusieurs modes de gestion des adresses IP (IPAM), d'encapsulation, d'équilibrage de charge et de routage de clusters. Les modes validés dans ce guide utilisaient Cluster Scope IPAM, la superposition VXLAN, l'équilibrage de charge BGP et le kube-proxy. Le cilium a également été utilisé sans équilibrage de charge BGP, en le remplaçant par un équilibrage de charge MetalLB L2.
La base de l'installation Cilium comprend l'opérateur Cilium et les agents Cilium. [L'opérateur Cilium s'exécute en tant que déploiement et enregistre les définitions de ressources personnalisées (CRD) Cilium, gère l'IPAM et synchronise les objets du cluster avec le serveur d'API Kubernetes, entre autres fonctionnalités.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Les agents Cilium s'exécutent sur chaque nœud en tant que DaemonSet et gèrent les programmes eBPF afin de contrôler les règles réseau applicables aux charges de travail exécutées sur le cluster.
En général, le routage intégré au cluster configuré par Cilium reste disponible et en place pendant les déconnexions du réseau, ce qui peut être confirmé en observant les flux de trafic internes au cluster et les règles de table IP (iptables) pour le réseau du pod.
```
ip route show table all | grep cilium
```
```
10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16
10.86.3.16 dev cilium_host proto kernel scope link
...
```
Cependant, lors des déconnexions du réseau, l'opérateur Cilium et les agents Cilium redémarrent en raison du couplage de leurs bilans de santé avec l'état de la connexion avec le serveur API Kubernetes. On s'attend à voir ce qui suit dans les journaux de l'opérateur Cilium et des agents Cilium lors des déconnexions du réseau. Pendant les déconnexions du réseau, vous pouvez utiliser des outils tels que la `crictl` CLI pour observer les redémarrages de ces composants, y compris leurs journaux.
```
msg="Started gops server" address="127.0.0.1:9890" subsys=gops
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client
msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s
msg=Stopping
msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops
msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon
```
Si vous utilisez la fonctionnalité du plan de contrôle BGP de Cilium pour l'équilibrage de charge des applications, la session BGP pour vos pods et services peut être interrompue lors des déconnexions réseau car la fonctionnalité des haut-parleurs BGP est intégrée à l'agent Cilium, et l'agent Cilium redémarre en permanence lorsqu'il est déconnecté du plan de contrôle Kubernetes. Pour plus d'informations, consultez le guide d'utilisation du plan de contrôle Cilium BGP dans la documentation de Cilium. En outre, si vous rencontrez une panne simultanée lors d'une déconnexion du réseau, telle qu'un cycle d'alimentation ou un redémarrage de machine, les routes Cilium ne seront pas préservées grâce à ces actions, bien qu'elles soient recréées lorsque le nœud se reconnecte au plan de contrôle Kubernetes et que Cilium redémarre.
## Calico
*Prochainement*
## Métal B
[MetalLB dispose de deux modes d'équilibrage de charge : le mode [L2 et le mode](https://metallb.universe.tf/concepts/layer2/) BGP.](https://metallb.universe.tf/concepts/bgp/) Consultez la documentation de MetalLB pour plus de détails sur le fonctionnement de ces modes d'équilibrage de charge et leurs limites. La validation de ce guide a utilisé MetalLB en mode L2, où une machine du cluster prend possession du service Kubernetes et utilise ARP pour IPv4 pour rendre les adresses IP de l'équilibreur de charge accessibles sur le réseau local. Lors de l'exécution de MetalLB, un contrôleur est responsable de l'attribution des adresses IP et des haut-parleurs exécutés sur chaque nœud sont responsables des services publicitaires auxquels les adresses IP sont attribuées. Le contrôleur MetalLB fonctionne en tant que déploiement et les haut-parleurs MetalLB fonctionnent en tant que. DaemonSet Lors des déconnexions réseau, le contrôleur MetalLB et les haut-parleurs ne surveillent pas les ressources du cluster sur le serveur d'API Kubernetes, mais continuent de fonctionner. Plus important encore, les Services qui utilisent MetalLB pour la connectivité externe restent disponibles et accessibles pendant les déconnexions du réseau.
## kube-proxy
Dans les clusters EKS, kube-proxy s'exécute DaemonSet sur chaque nœud et est chargé de gérer les règles du réseau afin de permettre la communication entre les services et les pods en traduisant les adresses IP des services en adresses IP des pods sous-jacents. Les règles des tables IP (iptables) configurées par kube-proxy sont maintenues pendant les déconnexions du réseau, le routage au sein du cluster continue de fonctionner et les pods kube-proxy continuent de fonctionner.
Vous pouvez observer les règles de kube-proxy avec les commandes iptables suivantes. La première commande montre que les paquets passant par la `PREROUTING` chaîne sont dirigés vers la `KUBE-SERVICES` chaîne.
```
iptables -t nat -L PREROUTING
```
```
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
```
En inspectant la `KUBE-SERVICES` chaîne, nous pouvons voir les règles des différents services du cluster.
```
Chain KUBE-SERVICES (2 references)
target prot opt source destination
KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP /
KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP /
KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP /
KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP /
KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP /
KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP /
KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP /
KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP /
KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP /
KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP /
KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP /
KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */
```
En inspectant la chaîne du service frontal de l'application, nous pouvons voir les adresses IP des pods qui soutiennent le service.
```
iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q
```
```
Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references)
target prot opt source destination
KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349
KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000
KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */
```
Les messages du journal kube-proxy suivants sont attendus lors des déconnexions du réseau lorsqu'il tente de surveiller le serveur d'API Kubernetes pour détecter les mises à jour des ressources des nœuds et des points de terminaison.
```
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError"
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError"
```
## CoreDNS
Par défaut, les pods des clusters EKS utilisent l'adresse IP du cluster CoreDNS comme serveur de noms pour les requêtes DNS internes au cluster. Dans les clusters EKS, CoreDNS s'exécute en tant que déploiement sur des nœuds. Avec les nœuds hybrides, les pods peuvent continuer à communiquer avec le CoreDNS pendant les déconnexions du réseau lorsque des répliques de CoreDNS s'exécutent localement sur des nœuds hybrides. Si vous avez un cluster EKS avec des nœuds dans le cloud et des nœuds hybrides dans votre environnement sur site, il est recommandé de disposer d'au moins une réplique CoreDNS dans chaque environnement. CoreDNS continue de répondre aux requêtes DNS pour les enregistrements créés avant la déconnexion du réseau et continue à exécuter la reconnexion réseau pour garantir une stabilité statique.
Les messages de journal CoreDNS suivants sont attendus lors des déconnexions du réseau lorsqu'il tente de répertorier des objets depuis le serveur d'API Kubernetes.
```
Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout
Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout
Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout
```