As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Tráfego de rede de aplicativos por meio de desconexões de rede Os tópicos desta página estão relacionados à rede de cluster do Kubernetes e ao tráfego do aplicativo durante as desconexões de rede entre os nós e o plano de controle do Kubernetes. ## Cilium O Cilium tem vários modos para gerenciamento de endereços IP (IPAM), encapsulamento, balanceamento de carga e roteamento de clusters. Os modos validados neste guia usaram Cluster Scope IPAM, VXLAN overlay, balanceamento de carga BGP e kube-proxy. O Cilium também foi usado sem balanceamento de carga BGP, substituindo-o pelo balanceamento de carga MetalLB L2. A base da instalação do Cilium consiste no operador Cilium e nos agentes Cilium. [O operador Cilium é executado como uma implantação e registra as definições de recursos personalizados do Cilium (CRDs), gerencia o IPAM e sincroniza objetos de cluster com o servidor da API Kubernetes, entre outros recursos.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Os agentes Cilium são executados em cada nó como um DaemonSet e gerenciam os programas eBPF para controlar as regras de rede para cargas de trabalho em execução no cluster. Geralmente, o roteamento no cluster configurado pelo Cilium permanece disponível e no local durante as desconexões da rede, o que pode ser confirmado observando os fluxos de tráfego no cluster e as regras da tabela IP (iptables) para a rede do 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 ... ``` No entanto, durante as desconexões da rede, o operador do Cilium e os agentes do Cilium são reiniciados devido ao acoplamento de suas verificações de saúde com a integridade da conexão com o servidor da API Kubernetes. Espera-se ver o seguinte nos registros do operador Cilium e dos agentes do Cilium durante as desconexões da rede. Durante as desconexões da rede, você pode usar ferramentas como a `crictl` CLI para observar as reinicializações desses componentes, incluindo seus registros. ``` 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 ``` Se você estiver usando o recurso BGP Control Plane do Cilium para balanceamento de carga de aplicativos, a sessão BGP de seus pods e serviços poderá ficar inativa durante as desconexões da rede porque a funcionalidade do alto-falante BGP está integrada ao agente Cilium, e o agente Cilium será reiniciado continuamente quando desconectado do plano de controle do Kubernetes. Para obter mais informações, consulte o Guia de operação do plano de controle Cilium BGP na documentação do Cilium. Além disso, se você tiver uma falha simultânea durante uma desconexão de rede, como um ciclo de energia ou reinicialização da máquina, as rotas do Cilium não serão preservadas por meio dessas ações, embora as rotas sejam recriadas quando o nó se reconectar ao plano de controle do Kubernetes e o Cilium for reiniciado. ## Calico *Em breve* ## Metal B [O MetalLB tem dois modos para balanceamento de carga: modo [L2 e modo](https://metallb.universe.tf/concepts/layer2/) BGP.](https://metallb.universe.tf/concepts/bgp/) Consulte a documentação do MetalLB para obter detalhes sobre como esses modos de balanceamento de carga funcionam e suas limitações. A validação deste guia usou o MetalLB no modo L2, em que uma máquina no cluster assume a propriedade do Kubernetes Service e usa o ARP IPv4 para tornar os endereços IP do balanceador de carga acessíveis na rede local. Ao executar o MetalLB, há um controlador responsável pela atribuição de IP e alto-falantes executados em cada nó, responsáveis por serviços de publicidade com endereços IP atribuídos. O controlador MetalLB funciona como um Deployment e os alto-falantes MetalLB funcionam como um. DaemonSet Durante as desconexões da rede, o controlador e os alto-falantes MetalLB não conseguem monitorar o servidor da API Kubernetes em busca de recursos de cluster, mas continuam em execução. Mais importante ainda, os Serviços que estão usando o MetalLB para conectividade externa permanecem disponíveis e acessíveis durante as desconexões da rede. ## kube-proxy Nos clusters EKS, o kube-proxy é executado como um DaemonSet em cada nó e é responsável por gerenciar as regras de rede para permitir a comunicação entre serviços e pods, traduzindo os endereços IP do serviço para os endereços IP dos pods subjacentes. As regras de tabelas IP (iptables) configuradas pelo kube-proxy são mantidas durante as desconexões da rede, o roteamento no cluster continua funcionando e os pods kube-proxy continuam em execução. Você pode observar as regras do kube-proxy com os seguintes comandos iptables. O primeiro comando mostra que os pacotes que passam pela `PREROUTING` cadeia são direcionados para a `KUBE-SERVICES` cadeia. ``` iptables -t nat -L PREROUTING ``` ``` Chain PREROUTING (policy ACCEPT) target prot opt source destination KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */ ``` Inspecionando a `KUBE-SERVICES` cadeia, podemos ver as regras para os vários serviços de 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 */ ``` Inspecionando a cadeia do serviço de front-end do aplicativo, podemos ver os endereços IP do pod que sustentam o serviço. ``` 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 */ ``` As seguintes mensagens de log do kube-proxy são esperadas durante as desconexões da rede, enquanto ele tenta observar o servidor da API Kubernetes em busca de atualizações nos recursos de nós e endpoints. ``` "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 Por padrão, os pods em clusters EKS usam o endereço IP do cluster CoreDNS como servidor de nomes para consultas de DNS no cluster. Em clusters EKS, o CoreDNS é executado como uma implantação em nós. Com os nós híbridos, os pods podem continuar se comunicando com o CoreDNS durante as desconexões da rede quando há réplicas do CoreDNS em execução local nos nós híbridos. Se você tiver um cluster EKS com nós na nuvem e nós híbridos em seu ambiente local, é recomendável ter pelo menos uma réplica do CoreDNS em cada ambiente. O CoreDNS continua atendendo consultas de DNS para registros que foram criados antes da desconexão da rede e continua executando a reconexão da rede para estabilidade estática. As seguintes mensagens de log do CoreDNS são esperadas durante as desconexões de rede, à medida que ele tenta listar objetos do servidor da 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 ```