Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Tráfico de red de aplicaciones a través de desconexiones de red

Los temas de esta página están relacionados con las redes de clústeres de Kubernetes y el tráfico de aplicaciones durante las desconexiones de red entre los nodos y el plano de control de Kubernetes.

Cilium

Cilium tiene varios modos de administración de direcciones IP (IPAM), encapsulación, equilibrio de carga y enrutamiento de clústeres. Los modos validados en esta guía utilizaron Cluster Scope IPAM, VXLAN overlay, BGP Load Balancing y kube-proxy. Cilium también se usó sin el balanceo de carga de BGP, sustituyéndolo por el balanceo de carga L2 de MetalLB.

La base de la instalación de Cilium consiste en el operador de Cilium y los agentes de Cilium. El operador de Cilium funciona como una implementación y registra las definiciones de recursos personalizadas (CRD) de Cilium, administra el IPAM y sincroniza los objetos del clúster con el servidor de API de Kubernetes, entre otras funciones. https://docs.cilium.io/en/stable/internals/cilium_operator/ Los agentes de Cilium se ejecutan en cada nodo como si fueran programas de eBPF DaemonSet y administran los mismos para controlar las reglas de red aplicables a las cargas de trabajo que se ejecutan en el clúster.

Por lo general, el enrutamiento en el clúster configurado por Cilium permanece disponible y en su lugar durante las desconexiones de la red, lo que se puede confirmar observando los flujos de tráfico del clúster y las reglas de la tabla de IP (iptables) de la red de pods.

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

Sin embargo, durante las desconexiones de la red, el operador de Cilium y los agentes de Cilium se reinician debido a que sus comprobaciones de estado coinciden con el estado de la conexión con el servidor de API de Kubernetes. Se espera ver lo siguiente en los registros del operador de Cilium y de los agentes de Cilium durante las desconexiones de la red. Durante las desconexiones de la red, puede usar herramientas como la crictl CLI para observar los reinicios de estos componentes, incluidos sus registros.

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

Si utilizas la función del plano de control BGP de Cilium para equilibrar la carga de las aplicaciones, es posible que la sesión de BGP de tus pods y servicios se interrumpa durante las desconexiones de la red, ya que la funcionalidad del altavoz BGP está integrada con el agente de Cilium y este se reiniciará continuamente cuando se desconecte del plano de control de Kubernetes. Para obtener más información, consulte la guía de funcionamiento del plano de control BGP de Cilium en la documentación de Cilium. Además, si se produce un error simultáneo durante una desconexión de la red, como un ciclo de alimentación o un reinicio de la máquina, las rutas de Cilium no se conservarán mediante estas acciones, aunque las rutas se recrean cuando el nodo se vuelve a conectar al plano de control de Kubernetes y Cilium se inicia de nuevo.

Calico

Próximamente

Metal B

MetallB tiene dos modos para equilibrar la carga: el modo L2 y el modo BGP. https://metallb.universe.tf/concepts/bgp/ Consulte la documentación de MetallB para obtener detalles sobre cómo funcionan estos modos de equilibrio de carga y sus limitaciones. La validación de esta guía utilizó MetallB en modo L2, donde una máquina del clúster se hace cargo del servicio Kubernetes y usa ARP para IPv4 para que las direcciones IP del balanceador de carga estén accesibles en la red local. Cuando se ejecuta MetallB, hay un controlador que se encarga de la asignación de IP y los altavoces que funcionan en cada nodo se encargan de anunciar los servicios con direcciones IP asignadas. El controlador MetallB funciona como un Deployment y los altavoces MetallB funcionan como un. DaemonSet Durante las desconexiones de la red, el controlador y los altavoces de MetallB no detectan los recursos del clúster en el servidor API de Kubernetes, pero siguen funcionando. Y lo que es más importante, los servicios que utilizan MetallB para la conectividad externa permanecen disponibles y accesibles durante las desconexiones de la red.

kube-proxy

En los clústeres de EKS, kube-proxy se ejecuta como un nodo DaemonSet en cada nodo y es responsable de administrar las reglas de red para permitir la comunicación entre los servicios y los pods mediante la traducción de las direcciones IP de los servicios a las direcciones IP de los pods subyacentes. Las reglas de tablas IP (iptables) configuradas por kube-proxy se mantienen durante las desconexiones de la red, el enrutamiento dentro del clúster sigue funcionando y los pods de kube-proxy siguen ejecutándose.

Puedes observar las reglas de kube-proxy con los siguientes comandos de iptables. El primer comando muestra que los paquetes que pasan por la PREROUTING cadena se dirigen a la cadena. KUBE-SERVICES

iptables -t nat -L PREROUTING

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

Al inspeccionar la KUBE-SERVICES cadena, podemos ver las reglas de los distintos servicios del clúster.

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

Al inspeccionar la cadena del servicio de interfaz de la aplicación, podemos ver las direcciones IP de los módulos que respaldan el servicio.

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

Se esperan los siguientes mensajes de registro de kube-proxy durante las desconexiones de la red, ya que intenta vigilar el servidor de API de Kubernetes para ver si hay actualizaciones en los recursos de nodos y puntos finales.

"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

De forma predeterminada, los pods de los clústeres de EKS utilizan la dirección IP del clúster de CoreDNS como servidor de nombres para las consultas de DNS dentro del clúster. En los clústeres de EKS, CoreDNS se ejecuta como una implementación en los nodos. Con los nodos híbridos, los pods pueden seguir comunicándose con el CoreDNS durante las desconexiones de la red cuando hay réplicas de CoreDNS ejecutándose localmente en los nodos híbridos. Si tiene un clúster de EKS con nodos en la nube y nodos híbridos en su entorno local, se recomienda tener al menos una réplica de CoreDNS en cada entorno. CoreDNS sigue realizando consultas de DNS para los registros que se crearon antes de la desconexión de la red y continúa ejecutándose durante la reconexión de la red para lograr una estabilidad estática.

Se esperan los siguientes mensajes de registro de CoreDNS durante las desconexiones de la red cuando intenta enumerar objetos del servidor API de 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