View a markdown version of this page

Netzwerkverkehr der Anwendung 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 der Anwendung durch Netzwerkunterbrechungen

Die Themen auf dieser Seite beziehen sich auf Kubernetes-Cluster-Netzwerke und den Anwendungsverkehr bei Netzwerkunterbrechungen zwischen Knoten und der Kubernetes-Steuerungsebene.

Cilium

Cilium verfügt über mehrere Modi für die IP-Adressverwaltung (IPAM), die Kapselung, den Lastenausgleich und das Cluster-Routing. Die in diesem Handbuch validierten Modi verwendeten Cluster Scope IPAM, VXLAN-Overlay, BGP-Load-Balancing und Kube-Proxy. Cilium wurde auch ohne BGP-Load-Balancing 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. https://docs.cilium.io/en/stable/internals/cilium_operator/ 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 Cluster-Routing auch bei Netzwerkunterbrechungen verfügbar und an Ort und Stelle. Dies kann durch die Einhaltung der Cluster-internen Verkehrsflü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 Zustandsprüfungen mit dem Zustand der Verbindung zum Kubernetes-API-Server verknüpft sind. Es wird erwartet, dass in den Protokollen des Cilium-Betreibers und der Cilium-Agenten bei Netzwerkunterbrechungen Folgendes zu sehen ist. 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 Anwendungslastenausgleich verwenden, ist die BGP-Sitzung für Ihre Pods und Dienste während der Netzwerkunterbrechung möglicherweise ausgefallen, da die BGP-Lautsprecherfunktion in den Cilium-Agenten integriert ist und der Cilium-Agent kontinuierlich neu gestartet wird, wenn er von der Kubernetes-Steuerebene getrennt wird. Weitere Informationen finden Sie in der Cilium BGP Control Plane Operation Guide in der Cilium-Dokumentation. Wenn Sie außerdem während einer Netzwerkunterbrechung, z. B. bei einem Stromzyklus oder einem Computerneustart, einen gleichzeitigen Ausfall feststellen, bleiben die Cilium-Routen durch diese Aktionen nicht erhalten, obwohl die Routen neu erstellt werden, wenn der Knoten wieder eine Verbindung zur Kubernetes-Steuerungsebene herstellt und Cilium erneut gestartet wird.

Calico

Kommt bald

Metall B

MetaLB hat zwei Modi für den Lastausgleich: den L2-Modus und den BGP-Modus. Einzelheiten zur Funktionsweise dieser Load-Balancing-Modi und zu ihren Einschränkungen finden Sie in der MetalLB-Dokumentation. Bei der Validierung dieses Handbuchs wurde MetalLB im L2-Modus verwendet, in dem eine Maschine im Cluster die Verantwortung für den Kubernetes-Dienst übernimmt und ARP für IPv4 verwendet, um die IP-Adressen des Load Balancers im lokalen Netzwerk erreichbar zu machen. Beim Betrieb von MetalLB gibt es einen Controller, der für die IP-Zuweisung verantwortlich ist, und auf jedem Knoten laufen Lautsprecher, die für die Werbung von Diensten mit zugewiesenen IP-Adressen verantwortlich sind. Der MetalLB-Controller läuft als Deployment und die MetalLB-Lautsprecher laufen als. DaemonSet Während der Netzwerkunterbrechung überwachen der MetalLB-Controller und die Lautsprecher den Kubernetes-API-Server nicht nach Cluster-Ressourcen, laufen aber weiter. Am wichtigsten ist, dass die Dienste, die MetalLB für externe Konnektivität verwenden, auch bei Netzwerkunterbrechungen verfügbar und zugänglich bleiben.

kube-proxy

In EKS-Clustern läuft Kube-Proxy DaemonSet auf jedem Knoten und ist für die Verwaltung der Netzwerkregeln verantwortlich, um die Kommunikation zwischen Diensten und Pods zu ermöglichen, indem die 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. Das Cluster-Routing 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 die KUBE-SERVICES Kette untersuchen, 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, da versucht wird, den Kubernetes-API-Server auf Aktualisierungen der Knoten- und Endpunktressourcen zu überwachen.

"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 innerhalb des Clusters. In EKS-Clustern wird CoreDNS als Deployment auf Knoten ausgeführt. Bei Hybridknoten können Pods auch 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 verwenden. CoreDNS verarbeitet weiterhin DNS-Abfragen für Datensätze, die vor dem Trennen der Netzwerkverbindung erstellt wurden, und setzt die Wiederverbindung des Netzwerks fort, um die statische Stabilität zu gewährleisten.

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