Cilium Calico Metallo B kube-proxy CoreDNS

Traffico di rete delle applicazioni tramite disconnessioni di rete

Gli argomenti di questa pagina riguardano il networking dei cluster Kubernetes e il traffico delle applicazioni durante le disconnessioni di rete tra i nodi e il piano di controllo di Kubernetes.

Cilium

Cilium ha diverse modalità per la gestione degli indirizzi IP (IPAM), l'incapsulamento, il bilanciamento del carico e il routing dei cluster. Le modalità convalidate in questa guida utilizzavano Cluster Scope IPAM, VXLAN overlay, BGP load balancing e kube-proxy. Cilium è stato utilizzato anche senza il bilanciamento del carico BGP, sostituendolo con il bilanciamento del carico MetallB L2.

La base dell'installazione Cilium è costituita dall'operatore Cilium e dagli agenti Cilium. L'operatore Cilium viene eseguito come Deployment e registra le Cilium Custom Resource Definitions (CRD), gestisce IPAM e sincronizza gli oggetti del cluster con il server API Kubernetes, tra le altre funzionalità. https://docs.cilium.io/en/stable/internals/cilium_operator/ Gli agenti Cilium vengono eseguiti su ciascun nodo come un DaemonSet e gestiscono i programmi eBPF per controllare le regole di rete per i carichi di lavoro in esecuzione sul cluster.

In genere, il routing interno al cluster configurato da Cilium rimane disponibile e attivo durante le disconnessioni di rete, il che può essere confermato osservando i flussi di traffico all'interno del cluster e le regole della tabella IP (iptables) per la rete 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
...

Tuttavia, durante le disconnessioni di rete, l'operatore Cilium e gli agenti Cilium si riavviano grazie all'abbinamento dei controlli di integrità con lo stato della connessione con il server API Kubernetes. Si prevede di vedere quanto segue nei log dell'operatore Cilium e degli agenti Cilium durante le disconnessioni di rete. Durante le disconnessioni di rete, è possibile utilizzare strumenti come la crictl CLI per osservare i riavvii di questi componenti, inclusi i relativi registri.


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

Se utilizzi la funzionalità BGP Control Plane di Cilium per il bilanciamento del carico delle applicazioni, la sessione BGP per i tuoi pod e servizi potrebbe essere inattiva durante le disconnessioni di rete perché la funzionalità degli altoparlanti BGP è integrata con l'agente Cilium e l'agente Cilium si riavvierà continuamente quando viene disconnesso dal piano di controllo di Kubernetes. Per ulteriori informazioni, consulta la Cilium BGP Control Plane Operation Guide nella documentazione di Cilium. Inoltre, se si verifica un errore simultaneo durante una disconnessione della rete, ad esempio un ciclo di alimentazione o un riavvio della macchina, le rotte Cilium non verranno preservate tramite queste azioni, sebbene le rotte vengano ricreate quando il nodo si riconnette al piano di controllo di Kubernetes e Cilium si riavvia.

Calico

Prossimamente

Metallo B

MetaLB ha due modalità per il bilanciamento del carico: modalità L2 e modalità BGP. https://metallb.universe.tf/concepts/bgp/ Fai riferimento alla documentazione MetaLB per i dettagli su come funzionano queste modalità di bilanciamento del carico e sulle loro limitazioni. La convalida di questa guida ha utilizzato MetallB in modalità L2, in cui una macchina del cluster assume la proprietà del servizio Kubernetes e utilizza ARP per IPv4 per rendere gli indirizzi IP del load balancer raggiungibili sulla rete locale. Quando si esegue MetallB c'è un controller responsabile dell'assegnazione degli IP e degli altoparlanti in esecuzione su ciascun nodo che sono responsabili della pubblicità dei servizi con indirizzi IP assegnati. Il controller MetallB funziona come Deployment e gli altoparlanti MetallB funzionano come. DaemonSet Durante le disconnessioni di rete, il controller e gli altoparlanti MetallB non riescono a controllare il server API Kubernetes alla ricerca di risorse del cluster, ma continuano a funzionare. Soprattutto, i Servizi che utilizzano MetallB per la connettività esterna rimangono disponibili e accessibili durante le disconnessioni di rete.

kube-proxy

Nei cluster EKS, kube-proxy viene eseguito come un proxy DaemonSet su ciascun nodo ed è responsabile della gestione delle regole di rete per consentire la comunicazione tra servizi e pod traducendo gli indirizzi IP dei servizi negli indirizzi IP dei pod sottostanti. Le regole delle tabelle IP (iptables) configurate da kube-proxy vengono mantenute durante le disconnessioni di rete e il routing all'interno del cluster continua a funzionare e i pod kube-proxy continuano a funzionare.

Puoi osservare le regole di kube-proxy con i seguenti comandi iptables. Il primo comando mostra che i pacchetti che attraversano la catena vengono indirizzati alla PREROUTING catena. KUBE-SERVICES


iptables -t nat -L PREROUTING


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

Ispezionando la KUBE-SERVICES catena possiamo vedere le regole per i vari servizi del 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    <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 */

Ispezionando la catena del servizio frontend dell'applicazione possiamo vedere gli indirizzi IP dei pod che supportano il servizio.


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

I seguenti messaggi di log di kube-proxy sono attesi durante le disconnessioni di rete mentre tenta di controllare il server API Kubernetes per gli aggiornamenti alle risorse dei nodi e degli endpoint.


"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

Per impostazione predefinita, i pod nei cluster EKS utilizzano l'indirizzo IP del cluster CoreDNS come server dei nomi per le query DNS all'interno del cluster. Nei cluster EKS, CoreDNS viene eseguito come distribuzione sui nodi. Con i nodi ibridi, i pod sono in grado di continuare a comunicare con il CoreDNS durante le disconnessioni di rete quando ci sono repliche CoreDNS in esecuzione localmente su nodi ibridi. Se disponi di un cluster EKS con nodi nel cloud e nodi ibridi nell'ambiente locale, è consigliabile avere almeno una replica CoreDNS in ogni ambiente. CoreDNS continua a fornire le query DNS per i record creati prima della disconnessione dalla rete e continua a eseguire la riconnessione di rete per garantire la stabilità statica.

I seguenti messaggi di log di CoreDNS sono attesi durante le disconnessioni di rete mentre tenta di elencare gli oggetti dal server API Kubernetes.


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

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Failover del pod Kubernetes

Credenziali dell'host