Netzwerkverkehr von Anwendungen durch Netzwerkunterbrechungen - Amazon EKS
CiliumCalicoMetall Bkube-proxyCoreDNS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Netzwerkverkehr von Anwendungen durch Netzwerkunterbrechungen

Die Themen auf dieser Seite beziehen sich auf Kubernetes-Clusternetzwerke und den Anwendungsdatenverkehr bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerebene.

Cilium

Cilium bietet mehrere Modi für IP-Adressverwaltung (IPAM), Kapselung, Lastenausgleich und Cluster-Routing. Die in diesem Handbuch validierten Modi verwendeten Cluster Scope IPAM, VXLAN-Overlay, BGP-Loadbalancing und Kube-Proxy. Cilium wurde auch ohne BGP-Loadbalancing verwendet und durch MetalLB L2-Load Balancing ersetzt.

Die Basis der Cilium-Installation besteht aus dem Cilium-Operator und den Cilium-Agenten. Der Cilium-Operator wird als Deployment ausgeführt und registriert die Cilium Custom Resource Definitions (CRDs), verwaltet IPAM und synchronisiert Cluster-Objekte unter anderem mit dem Kubernetes-API-Server. Die Cilium-Agenten laufen auf jedem Knoten als DaemonSet und verwalten die eBPF-Programme, um die Netzwerkregeln für Workloads zu kontrollieren, die auf dem Cluster ausgeführt werden.

Im Allgemeinen bleibt das von Cilium konfigurierte In-Cluster-Routing auch bei Netzwerkunterbrechungen verfügbar und an Ort und Stelle. Dies kann anhand der Cluster-Datenflüsse und der IP-Tabellenregeln (iptables) für das Pod-Netzwerk bestätigt werden.

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
...

Bei Netzwerkunterbrechungen werden der Cilium-Operator und die Cilium-Agenten jedoch neu gestartet, da ihre Integritätsprüfungen mit dem Zustand der Verbindung mit dem Kubernetes-API-Server verknüpft sind. Bei Netzwerkunterbrechungen wird in den Protokollen des Cilium-Operators und der Cilium-Agenten voraussichtlich Folgendes angezeigt: Während der Netzwerkunterbrechungen können Sie Tools wie die crictl CLI verwenden, um die Neustarts dieser Komponenten einschließlich ihrer Protokolle zu beobachten.

msg="Started gops server" address="127.0.0.1:9890" subsys=gops
msg="Establishing connection to apiserver" host="https://<k8s-cluster-ip>:443" subsys=k8s-client
msg="Establishing connection to apiserver" host="https://<k8s-cluster-ip>:443" subsys=k8s-client
msg="Unable to contact k8s api-server" error="Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout" ipAddr="https://<k8s-cluster-ip>:443" subsys=k8s-client
msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"
msg="Start failed" error="Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>: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://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout" subsys=daemon

Wenn Sie die BGP Control Plane-Funktion von Cilium für den Lastenausgleich von Anwendungen verwenden, kann es sein, dass die BGP-Sitzung für Ihre Pods und Dienste während Netzwerkunterbrechungen unterbrochen wird, da die BGP-Lautsprecherfunktion in den Cilium-Agent integriert ist und der Cilium-Agent kontinuierlich neu gestartet wird, wenn die Verbindung zur Kubernetes-Steuerebene getrennt wird. Weitere Informationen finden Sie im Cilium BGP Control Plane Operation Guide in der Cilium-Dokumentation. Außerdem werden die Cilium-Routen bei diesen Aktionen nicht beibehalten, wenn während einer Netzwerkunterbrechung, z. B. bei einem Netzwechsel oder einem Maschinenneustart, gleichzeitig ein Fehler auftritt. Die Routen werden jedoch neu erstellt, wenn der Knoten wieder eine Verbindung zur Kubernetes-Steuerebene herstellt und Cilium erneut gestartet wird.

Calico

Kommt bald

Metall B

MetalLB hat zwei Modi für den Lastenausgleich: den L2-Modus und den BGP-Modus. Einzelheiten zur Funktionsweise dieser Lastenausgleichsmodi und zu ihren Einschränkungen finden Sie in der MetalLB-Dokumentation. Bei der Validierung dieses Handbuchs wurde MetalLB im L2-Modus verwendet, wobei ein Computer im Cluster den Besitz des Kubernetes-Dienstes übernimmt und ARP verwendet, um die IP-Adressen des Load Balancers im lokalen Netzwerk erreichbar IPv4 zu machen. Bei der Ausführung von MetalB gibt es einen Controller, der für die IP-Zuweisung verantwortlich ist, und Lautsprecher, die auf jedem Knoten laufen und für die Werbung von Diensten mit zugewiesenen IP-Adressen verantwortlich sind. Der MetalB-Controller läuft als Deployment und die MetalB-Lautsprecher laufen als. DaemonSet Bei Netzwerkunterbrechungen können der MetalB-Controller und die Lautsprecher den Kubernetes-API-Server nicht nach Cluster-Ressourcen durchsuchen, sondern laufen weiter. Am wichtigsten ist, dass die Dienste, die MetalB für externe Konnektivität verwenden, auch bei Netzwerkunterbrechungen verfügbar und zugänglich bleiben.

kube-proxy

In EKS-Clustern wird Kube-Proxy DaemonSet auf jedem Knoten als a ausgeführt und ist für die Verwaltung von Netzwerkregeln verantwortlich, um die Kommunikation zwischen Diensten und Pods zu ermöglichen, indem Dienst-IP-Adressen in die IP-Adressen der zugrunde liegenden Pods übersetzt werden. Die von kube-proxy konfigurierten Regeln für IP-Tabellen (iptables) werden bei Netzwerkunterbrechungen beibehalten, und das Routing innerhalb des Clusters funktioniert weiterhin und die Kube-Proxy-Pods werden weiterhin ausgeführt.

Sie können die Kube-Proxy-Regeln mit den folgenden iptables-Befehlen einhalten. Der erste Befehl zeigt, dass Pakete, die die Kette durchlaufen, an die PREROUTING Kette weitergeleitet werden. KUBE-SERVICES

iptables -t nat -L PREROUTING
Chain PREROUTING (policy ACCEPT)
target         prot opt source      destination
KUBE-SERVICES  all  --  anywhere    anywhere      /* kubernetes service portals */

Wenn wir uns die KUBE-SERVICES Kette ansehen, können wir die Regeln für die verschiedenen Clusterdienste sehen.

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    <LB-IP>    / 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 */

Wenn wir die Kette des Frontend-Dienstes für die Anwendung untersuchen, können wir die Pod-IP-Adressen sehen, die den Dienst unterstützen.

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 */

Die folgenden Kube-Proxy-Protokollmeldungen werden bei Netzwerkunterbrechungen erwartet, wenn versucht wird, den Kubernetes-API-Server auf Aktualisierungen der Knoten- und Endpunktressourcen zu überprüfen.

"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https://<k8s-endpoint>/api/v1/nodes?fieldSelector=metadata.name%3D<node-name>&resourceVersion=2241908\": dial tcp <k8s-ip>: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://<k8s-endpoint>/apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp <k8s-ip>:443: i/o timeout" logger="UnhandledError"

CoreDNS

Standardmäßig verwenden Pods in EKS-Clustern die CoreDNS-Cluster-IP-Adresse als Nameserver für DNS-Abfragen im Cluster. In EKS-Clustern wird CoreDNS als Deployment auf Knoten ausgeführt. Mit Hybridknoten können Pods bei Netzwerkunterbrechungen weiterhin mit dem CoreDNS kommunizieren, wenn CoreDNS-Replikate lokal auf Hybridknoten ausgeführt werden. Wenn Sie einen EKS-Cluster mit Knoten in der Cloud und Hybridknoten in Ihrer lokalen Umgebung haben, wird empfohlen, in jeder Umgebung mindestens ein CoreDNS-Replikat zu haben. CoreDNS bedient weiterhin DNS-Abfragen für Datensätze, die vor der Netzwerkunterbrechung erstellt wurden, und führt aus Gründen der statischen Stabilität weiterhin die Netzwerkwiederverbindung durch.

Die folgenden CoreDNS-Protokollmeldungen werden bei Netzwerkunterbrechungen erwartet, wenn versucht wird, Objekte vom Kubernetes-API-Server aufzulisten.

Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://<k8s-cluster-ip>:443/api/v1/namespaces?resourceVersion=2263964": dial tcp <k8s-cluster-ip>:443: i/o timeout
Failed to watch *v1.Service: failed to list *v1.Service: Get "https://<k8s-cluster-ip>:443/api/v1/services?resourceVersion=2263966": dial tcp <k8s-cluster-ip>:443: i/o timeout
Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://<k8s-cluster-ip>:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp <k8s-cluster-ip>: i/o timeout