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á. # Melhores práticas para implantações híbridas Este guia fornece orientação sobre como executar implantações em ambientes locais ou periféricos com EKS Hybrid Nodes ou EKS Anywhere. Atualmente, publicamos guias para os seguintes tópicos: + [Melhores práticas para nós híbridos EKS e desconexões de rede](hybrid-nodes-network-disconnections.md) # Nodos híbridos EKS e desconexões de rede A arquitetura EKS Hybrid Nodes pode ser nova para clientes que estão acostumados a executar clusters Kubernetes locais inteiramente em seus próprios data centers ou locais periféricos. Com os EKS Hybrid Nodes, o plano de controle do Kubernetes é executado em uma região da AWS e somente os nós são executados localmente, resultando em uma arquitetura de cluster Kubernetes “ampliada” ou “estendida”. Isso leva a uma pergunta comum: “O que acontece se meus nós forem desconectados do plano de controle do Kubernetes?” Neste guia, respondemos a essa pergunta por meio de uma análise dos tópicos a seguir. É recomendável validar a estabilidade e a confiabilidade de seus aplicativos por meio de desconexões de rede, pois cada aplicativo pode se comportar de forma diferente com base em suas dependências, configuração e ambiente. Consulte o eks-hybrid-examples GitHub aws-samples/repo para ver a configuração, os procedimentos e os resultados dos testes que você pode consultar para testar desconexões de rede com os EKS Hybrid Nodes e seus próprios aplicativos. O GitHub repositório também contém detalhes adicionais dos testes usados para validar o comportamento explicado neste guia. + [Melhores práticas para estabilidade por meio de desconexões de rede](hybrid-nodes-network-disconnection-best-practices.md) + [Comportamento de failover do pod Kubernetes por meio de desconexões de rede](hybrid-nodes-kubernetes-pod-failover.md) + [Tráfego de rede de aplicativos por meio de desconexões de rede](hybrid-nodes-app-network-traffic.md) + [Credenciais do host por meio de desconexões de rede](hybrid-nodes-host-creds.md) # Melhores práticas para estabilidade por meio de desconexões de rede ## Rede de alta disponibilidade A melhor abordagem para evitar desconexões de rede entre os nós híbridos e o plano de controle do Kubernetes é usar conexões redundantes e resilientes do seu ambiente local de e para a AWS. Consulte o [kit de ferramentas de resiliência do AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) e a [documentação do AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) para obter mais informações sobre a arquitetura de redes híbridas altamente disponíveis com essas soluções. ## Aplicativos altamente disponíveis Ao arquitetar aplicativos, considere seus domínios de falha e os efeitos dos diferentes tipos de interrupções. O Kubernetes fornece mecanismos integrados para implantar e manter réplicas de aplicativos em domínios de nós, zonas e regiões. O uso desses mecanismos depende da arquitetura do aplicativo, dos ambientes e dos requisitos de disponibilidade. Por exemplo, aplicativos sem estado geralmente podem ser implantados com várias réplicas e podem se mover entre hosts arbitrários e capacidade de infraestrutura, e você pode usar seletores de nós e restrições de distribuição de topologia para executar instâncias do aplicativo em diferentes domínios. [Para obter detalhes sobre técnicas em nível de aplicativo para criar aplicativos resilientes no Kubernetes, consulte o Guia de melhores práticas do EKS.](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/) O Kubernetes avalia as informações zonais dos nós que estão desconectados do plano de controle do Kubernetes ao determinar se os pods devem ser movidos para outros nós. Se todos os nós em uma zona estiverem inacessíveis, o Kubernetes cancelará os despejos de pod dos nós dessa zona. Como prática recomendada, se você tiver uma implantação com nós em execução em vários data centers ou locais físicos, atribua uma zona a cada nó com base em seu data center ou localização física. Quando você executa o EKS com nós na nuvem, esse rótulo de zona é aplicado automaticamente pela AWS cloud-controller-manager. No entanto, a não cloud-controller-manager é usado com nós híbridos, então você pode passar essas informações por meio da configuração do kubelet. Um exemplo de como configurar uma zona em sua configuração de nó para nós híbridos é mostrado abaixo. A configuração é passada quando você conecta seus nós híbridos ao seu cluster com os nós híbridos CLI ()`nodeadm`. Para obter mais informações sobre o `topology.kubernetes.io/zone` rótulo, consulte a documentação do [Kubernetes](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone). Para obter mais informações sobre a CLI de nós híbridos, consulte a referência [nodeadm de nós híbridos](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html). ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster region: my-region kubelet: flags: - --node-labels=topology.kubernetes.io/zone=dc1 hybrid: ... ``` ## Monitoramento de rede Se você usa o AWS Direct Connect ou o AWS Site-to-Site VPN para sua conectividade híbrida, você pode aproveitar CloudWatch os alarmes, registros e métricas para observar o estado da sua conexão híbrida e diagnosticar problemas. Para obter mais informações, consulte [Monitoramento de recursos do AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) e [Monitorar uma conexão Site-to-Site VPN da AWS](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html). É recomendável criar alarmes para `NodeNotReady` eventos relatados pela node-lifecycle-controller execução no plano de controle EKS, o que indica que um nó híbrido pode estar passando por uma desconexão de rede. Você pode criar esse alarme ativando o registro do plano de controle EKS para o Controller Manager e criando um filtro métrico CloudWatch para a mensagem “Gravando mensagem de evento de alteração de status para nó” com o status = “NodeNotReady”. Depois de criar um filtro métrico, você pode criar um alarme para esse filtro com base nos limites desejados. Para obter mais informações, consulte [Alarmes para registros na CloudWatch documentação](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html). Você pode usar as métricas integradas do Transit Gateway (TGW) e do Virtual Private Gateway (VGW) para observar o tráfego de rede que entra e sai do seu TGW ou VGW. Você pode criar alarmes para essas métricas para detectar cenários em que o tráfego de rede cai abaixo dos níveis normais, indicando um possível problema de rede entre os nós híbridos e o plano de controle do EKS. As métricas TGW e VGW estão descritas na tabela a seguir. | Gateway | Métrica | Description | | --- | --- | --- | | Gateway de trânsito | BytesIn | Os bytes recebidos pelo TGW do anexo (plano de controle EKS para nós híbridos) | | Gateway de trânsito | BytesOut | Os bytes enviados do TGW para o anexo (nós híbridos para o plano de controle EKS) | | Gateway privado virtual | TunnelDataIn | Os bytes enviados do lado AWS da conexão através do túnel VPN até o gateway do cliente (plano de controle EKS para nós híbridos) | | Gateway privado virtual | TunnelDataOut | Os bytes recebidos no lado AWS da conexão por meio do túnel VPN do gateway do cliente (nós híbridos para o plano de controle EKS) | Você também pode usar o [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) para obter uma visão mais profunda de suas conexões híbridas para reduzir o tempo médio de recuperação e determinar se os problemas de rede se originam na AWS ou no seu ambiente. CloudWatch O Network Monitor pode ser usado para visualizar a perda e a latência de pacotes em suas conexões de rede híbrida, definir alertas e limites e, em seguida, tomar medidas para melhorar o desempenho da rede. Para obter mais informações, consulte [Usando o Amazon CloudWatch Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html). O EKS oferece várias opções para monitorar a integridade de seus clusters e aplicativos. Para a integridade do cluster, você pode usar o painel de observabilidade no console do EKS para detectar, solucionar problemas e remediar problemas rapidamente. Você também pode usar o Amazon Managed Service para Prometheus, o AWS Distro for Open Telemetry (ADOT) e para monitoramento de clusters CloudWatch , aplicativos e infraestrutura. Para obter mais informações sobre as opções de observabilidade do EKS, consulte [Monitore o desempenho do seu cluster e visualize os registros](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html). ## Solução de problemas local Para se preparar para desconexões de rede entre os nós híbridos e o plano de controle do EKS, você pode configurar back-ends secundários de monitoramento e registro para manter a observabilidade dos aplicativos quando os serviços regionais da AWS não estiverem acessíveis. Por exemplo, você pode configurar o coletor AWS Distro for Open Telemetry (ADOT) para enviar métricas e registros para vários back-ends. Você também pode usar ferramentas locais, como a `crictl` CLI, para interagir localmente com pods e contêineres como substituto `kubectl` ou outros clientes compatíveis com a API Kubernetes que normalmente consultam o endpoint do servidor da API Kubernetes. Para obter mais informações`crictl`, consulte a [`crictl`documentação](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) nas ferramentas GitHub cri-. Alguns `crictl` comandos úteis estão listados abaixo. Liste os pods em execução no host: ``` crictl pods ``` Liste os contêineres em execução no host: ``` crictl ps ``` Listar imagens em execução no host: ``` crictl images ``` Obtenha registros de um contêiner em execução no host: ``` crictl logs CONTAINER_NAME ``` Obtenha estatísticas dos pods em execução no host: ``` crictl statsp ``` ## Tráfego de rede de aplicativos Ao usar nós híbridos, é importante considerar e compreender os fluxos de rede do tráfego do seu aplicativo e as tecnologias que você usa para expor seus aplicativos externamente ao seu cluster. Diferentes tecnologias para balanceamento de carga e entrada de aplicativos se comportam de forma diferente durante as desconexões da rede. Por exemplo, 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. Isso acontece 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. O motivo da reinicialização é devido à falha na verificação de integridade do Cilium, pois sua integridade está associada ao acesso ao plano de controle do Kubernetes (consulte [CFP: \$131702](https://github.com/cilium/cilium/issues/31702) com uma melhoria opcional no Cilium v1.17). Da mesma forma, se você estiver usando Application Load Balancers (ALB) ou Network Load Balancers (NLB) para tráfego de aplicativos originado na região da AWS, esse tráfego poderá ficar temporariamente inativo se seu ambiente local perder a conectividade com a região da AWS. É recomendável validar se as tecnologias que você usa para balanceamento de carga e entrada permanecem estáveis durante as desconexões da rede antes da implantação na produção. O exemplo no [eks-hybrid-examples GitHub aws-samples/repo](https://github.com/aws-samples/eks-hybrid-examples) usa o MetalLB para balanceamento de carga no [modo L2](https://metallb.universe.tf/concepts/layer2/), que permanece estável durante as desconexões de rede entre os nós híbridos e o plano de controle EKS. ## Analise as dependências em serviços remotos da AWS Ao usar nós híbridos, esteja ciente das dependências que você assume nos serviços regionais da AWS que são externos ao seu ambiente local ou de borda. Os exemplos incluem acessar o Amazon S3 ou o Amazon RDS para obter dados de aplicativos, usar o Amazon Managed Service para Prometheus ou para métricas e logs, usar balanceadores de carga de aplicativos e de rede CloudWatch para tráfego originado na região e retirar contêineres do Amazon Elastic Container Registry. Esses serviços não estarão acessíveis durante as desconexões de rede entre seu ambiente local e a AWS. Se seu ambiente local estiver propenso a desconexões de rede com a AWS, analise seu uso dos serviços da AWS e garanta que a perda de uma conexão com esses serviços não comprometa a estabilidade estática de seus aplicativos. ## Ajuste o comportamento de failover do pod Kubernetes Há opções para ajustar o comportamento de failover de pod durante desconexões de rede para aplicativos que não são portáteis entre hosts ou para ambientes com recursos limitados que não têm capacidade disponível para failover de pod. Geralmente, é importante considerar os requisitos de recursos de seus aplicativos e ter capacidade suficiente para que uma ou mais instâncias do aplicativo passem para um host diferente se um nó falhar. + Opção 1 - Uso DaemonSets: essa opção se aplica a aplicativos que podem e devem ser executados em todos os nós do cluster. DaemonSets são configurados automaticamente para tolerar a contaminação inacessível, que mantém os DaemonSet pods vinculados a seus nós por meio de desconexões de rede. + Opção 2 - Ajuste `tolerationSeconds` para manchas inacessíveis: você pode ajustar a quantidade de tempo que seus pods permanecem vinculados aos nós durante as desconexões da rede. Faça isso configurando os pods de aplicativos para tolerar a contaminação inacessível com o `NoExecute` efeito por um período especificado (`tolerationSeconds`na especificação do aplicativo). Com essa opção, quando há desconexões de rede, seus pods de aplicativos permanecem vinculados aos nós até `tolerationSeconds` expirarem. Considere isso com cuidado, `tolerationSeconds` pois aumentar a contaminação inacessível `NoExecute` significa que os grupos que funcionam em hospedeiros inacessíveis podem levar mais tempo para serem transferidos para outros hospedeiros saudáveis e acessíveis. + Opção 3: Controlador personalizado: você pode criar e executar um controlador personalizado (ou outro software) que monitore o Kubernetes em busca da contaminação inacessível causada pelo efeito. `NoExecute` Quando essa contaminação é detectada, o controlador personalizado pode verificar as métricas específicas do aplicativo para avaliar a integridade do aplicativo. Se o aplicativo estiver íntegro, o controlador personalizado poderá remover a mancha inacessível, impedindo o despejo de pods dos nós durante as desconexões da rede. Um exemplo de como configurar uma implantação com `tolerationSeconds` for the unreachable taint é mostrado abaixo. No exemplo, `tolerationSeconds` está definido como `1800` (30 minutos), o que significa que os pods executados em nós inacessíveis só serão removidos se a desconexão da rede durar mais de 30 minutos. ``` apiVersion: apps/v1 kind: Deployment metadata: ... spec: ... tolerations: - key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 1800 ``` # Failover do pod Kubernetes por meio de desconexões de rede Começamos com uma revisão dos principais conceitos, componentes e configurações que influenciam o comportamento do Kubernetes durante as desconexões de rede entre os nós e o plano de controle do Kubernetes. O EKS está em conformidade com o Kubernetes upstream, então todos os conceitos, componentes e configurações do Kubernetes descritos aqui se aplicam às implantações de EKS e EKS Hybrid Nodes. Foram feitas melhorias no EKS especificamente para melhorar o comportamento de failover do pod durante desconexões de rede. Para obter mais informações, consulte os GitHub problemas [\$1131294](https://github.com/kubernetes/kubernetes/pull/131294) e [\$1131481](https://github.com/kubernetes/kubernetes/issues/131481) no repositório upstream do Kubernetes. ## Conceitos Contaminações e tolerações: manchas e tolerações são usadas no Kubernetes para controlar o agendamento de pods em nós. As manchas são definidas pelo node-lifecycle-controller para indicar que os nós não são elegíveis para agendamento ou que os pods desses nós devem ser despejados. Quando os nós estão inacessíveis devido a uma desconexão de rede, aplica-se o node.kubernetes. node-lifecycle-controller io/unreachable taint with a NoSchedule effect, and with a NoExecute effect if certain conditions are met. The node.kubernetes.io/unreachableA mancha corresponde ao NodeCondition Pronto ser Desconhecido. Os usuários podem especificar tolerâncias para manchas no nível da aplicação no. PodSpec + NoSchedule: Não há novos pods programados no nó contaminado, a menos que tenham uma tolerância equivalente. Os pods que já estão em execução no node não são despejados. + NoExecute: Os frutos que não toleram a contaminação são despejados imediatamente. Os pods que toleram a mancha (sem especificar tolerationSeconds) permanecem vinculados para sempre. Os pods que toleram a contaminação com uma tolerância especificada. Os segundos permanecem limitados pelo tempo especificado. Depois de decorrido esse tempo, o controlador do ciclo de vida do nó expulsa os pods do nó. Locações de nós: o Kubernetes usa a API Lease para comunicar os heartbeats do kubelet node ao servidor da API Kubernetes. Para cada nó, há um objeto Lease com um nome correspondente. Internamente, cada pulsação do kubelet atualiza o campo spec.renewTime do objeto Lease. O plano de controle do Kubernetes usa o timestamp desse campo para determinar a disponibilidade do nó. Se os nós estiverem desconectados do plano de controle do Kubernetes, eles não poderão atualizar spec.renewTime para sua locação, e o plano de controle interpreta isso como Pronto sendo desconhecido. NodeCondition ## Componentes ![\[Componentes do Kubernetes envolvidos no comportamento de failover do pod\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png) | Componente | Subcomponente | Description | | --- | --- | --- | | Plano de controle do Kubernetes | kube-api-server | O servidor da API é um componente principal do plano de controle do Kubernetes que expõe a API do Kubernetes. | | Plano de controle do Kubernetes | node-lifecycle-controller | Um dos controladores que ele kube-controller-manager executa. Ele é responsável por detectar e responder aos problemas dos nós. | | Plano de controle do Kubernetes | programador de cubos | Um componente do plano de controle que observa os pods recém-criados sem nenhum nó atribuído e seleciona um nó no qual eles serão executados. | | Nó do Kubernetes | kubelet | Um agente que é executado em cada nó do cluster. O kubelet observa PodSpecs e garante que os contêineres descritos neles PodSpecs estejam funcionando e saudáveis. | ## Definições de configuração | Componente | Configuração | Description | Padrão do K8s | Padrão EKS | Configurável no EKS | | --- | --- | --- | --- | --- | --- | | kube-api-server | default-unreachable-toleration-seconds | Indica se a tolerância `unreachable:NoExecute` que é adicionada por padrão a cada cápsula que ainda não tem essa tolerância. `tolerationSeconds` | 300 | 300 | Não | | node-lifecycle-controller | node-monitor-grace-period | A quantidade de tempo que um nó pode ficar sem responder antes de ser marcado como não íntegro. Deve ser N vezes maior que o do kubelet`nodeStatusUpdateFrequency`, onde N é o número de novas tentativas permitidas para que o kubelet publique o status do nó. | 40 | 40 | Não | | node-lifecycle-controller | large-cluster-size-threshold | O número de nós nos quais o cluster é node-lifecycle-controller tratado como grande para a lógica de despejo. `--secondary-node-eviction-rate`é substituído por 0 para clusters desse tamanho ou menores. | 50 | 100.000 | Não | | node-lifecycle-controller | unhealthy-zone-threshold | A porcentagem de nós em uma zona que não deve estar pronta para que essa zona seja tratada como não íntegra. | 55% | 55% | Não | | kubelet | node-status-update-frequency | Com que frequência o kubelet publica o status do nó no plano de controle. Deve ser compatível com `nodeMonitorGracePeriod` in node-lifecycle-controller. | 10 | 10 | Sim | | kubelet | rótulos de nós | Etiquetas a serem adicionadas ao registrar o nó no cluster. O rótulo `topology.kubernetes.io/zone` pode ser especificado com nós híbridos para agrupar nós em zonas. | Nenhum | Nenhum | Sim | ## Failover do pod Kubernetes por meio de desconexões de rede O comportamento descrito aqui pressupõe que os pods estejam sendo executados como implantações do Kubernetes com configurações padrão e que o EKS seja usado como provedor do Kubernetes. O comportamento real pode ser diferente com base no ambiente, no tipo de desconexão da rede, nos aplicativos, nas dependências e na configuração do cluster. O conteúdo deste guia foi validado usando um aplicativo específico, uma configuração de cluster e um subconjunto de plug-ins. É altamente recomendável testar o comportamento em seu próprio ambiente e com seus próprios aplicativos antes de passar para a produção. Quando há desconexões de rede entre os nós e o plano de controle do Kubernetes, o kubelet em cada nó desconectado não pode se comunicar com o plano de controle do Kubernetes. Consequentemente, o kubelet não pode despejar pods nesses nós até que a conexão seja restaurada. Isso significa que os pods executados nesses nós antes da desconexão da rede continuam funcionando durante a desconexão, supondo que nenhuma outra falha faça com que eles sejam desligados. Em resumo, você pode obter estabilidade estática durante as desconexões de rede entre os nós e o plano de controle do Kubernetes, mas não pode realizar operações de mutação em seus nós ou cargas de trabalho até que a conexão seja restaurada. Há cinco cenários principais que produzem diferentes comportamentos de failover do pod com base na natureza da desconexão da rede. Em todos os cenários, o cluster fica saudável novamente sem a intervenção do operador quando os nós se reconectam ao plano de controle do Kubernetes. Os cenários abaixo descrevem os resultados esperados com base em nossas observações, mas esses resultados podem não se aplicar a todas as configurações possíveis de aplicativos e clusters. ### Cenário 1: interrupção total do cluster **Resultado esperado**: os pods em nós inacessíveis não são despejados e continuam sendo executados nesses nós. Uma interrupção total do cluster significa que todos os nós do cluster estão desconectados do plano de controle do Kubernetes. Nesse cenário, o node-lifecycle-controller no plano de controle detecta que todos os nós do cluster estão inacessíveis e cancela qualquer despejo de pod. Os administradores do cluster verão todos os nós com status `Not Ready` durante a desconexão. O status do pod não muda e nenhum novo pod é programado em nenhum nó durante a desconexão e a reconexão subsequente. ### Cenário 2: interrupção total da zona **Resultado esperado**: os pods em nós inacessíveis não são despejados e continuam sendo executados nesses nós. Uma interrupção completa da zona significa que todos os nós na zona estão desconectados do plano de controle do Kubernetes. Nesse cenário, o node-lifecycle-controller no plano de controle detecta que todos os nós na zona estão inacessíveis e cancela qualquer despejo do pod. Os administradores do cluster verão todos os nós com status `Not Ready` durante a desconexão. O status do pod não muda e nenhum novo pod é programado em nenhum nó durante a desconexão e a reconexão subsequente. ### Cenário 3: interrupção da zona majoritária **Resultado esperado**: os pods em nós inacessíveis não são despejados e continuam sendo executados nesses nós. Uma interrupção de zona majoritária significa que a maioria dos nós em uma determinada zona está desconectada do plano de controle do Kubernetes. As zonas no Kubernetes são definidas por nós com o mesmo rótulo. `topology.kubernetes.io/zone` Se nenhuma zona for definida no cluster, uma interrupção majoritária significa que a maioria dos nós em todo o cluster está desconectada. Por padrão, a maioria é definida pelo node-lifecycle-controller s`unhealthy-zone-threshold`, que é definido como 55% no Kubernetes e no EKS. Como `large-cluster-size-threshold` está definido como 100.000 no EKS, se 55% ou mais dos nós em uma zona estiverem inacessíveis, os despejos de pod serão cancelados (já que a maioria dos clusters é muito menor do que 100.000 nós). Os administradores de cluster verão a maioria dos nós na zona com status `Not Ready` durante a desconexão, mas o status dos pods não mudará e eles não serão reprogramados em outros nós. Observe que o comportamento acima se aplica somente a clusters maiores que três nós. Em grupos de três nós ou menos, os pods em nós inacessíveis são programados para serem despejados e os novos pods são programados em nós saudáveis. Durante os testes, observamos ocasionalmente que os pods foram removidos de exatamente um nó inacessível durante as desconexões da rede, mesmo quando a maioria dos nós da zona estava inacessível. Ainda estamos investigando uma possível condição de corrida no Kubernetes node-lifecycle-controller como a causa desse comportamento. ### Cenário 4: interrupção da zona minoritária **Resultado esperado**: os pods são despejados de nós inacessíveis e novos pods são programados nos nós disponíveis e elegíveis. Uma interrupção minoritária significa que uma porcentagem menor de nós em uma zona está desconectada do plano de controle do Kubernetes. Se nenhuma zona for definida no cluster, uma interrupção minoritária significa que a minoria de nós em todo o cluster está desconectada. Conforme declarado, a minoria é definida pela `unhealthy-zone-threshold` configuração de node-lifecycle-controller, que é 55% por padrão. Nesse cenário, se a desconexão da rede durar mais do que `default-unreachable-toleration-seconds` (5 minutos) e `node-monitor-grace-period` (40 segundos) e menos de 55% dos nós em uma zona estiverem inacessíveis, novos pods serão programados em nós saudáveis, enquanto os pods em nós inacessíveis serão marcados para remoção. Os administradores de cluster verão novos pods criados em nós saudáveis, e os pods em nós desconectados serão exibidos como. `Terminating` Lembre-se de que, embora os pods nos nós desconectados tenham um `Terminating` status, eles não são totalmente removidos até que o nó se reconecte ao plano de controle do Kubernetes. ## Cenário 5: reinicialização do nó durante interrupção da rede **Resultado esperado**: os pods em nós inacessíveis não são iniciados até que os nós se reconectem ao plano de controle do Kubernetes. O failover do pod segue a lógica descrita nos Cenários 1—3, dependendo do número de nós inacessíveis. A reinicialização do nó durante a interrupção da rede significa que outra falha (como ciclo de alimentação, out-of-memory evento ou outro problema) ocorreu em um nó ao mesmo tempo que a desconexão da rede. Os pods que estavam em execução nesse nó quando a desconexão da rede começou não são reiniciados automaticamente durante a desconexão se o kubelet também tiver sido reiniciado. O kubelet consulta o servidor da API Kubernetes durante a inicialização para saber quais pods ele deve executar. Se o kubelet não conseguir acessar o servidor da API devido a uma desconexão de rede, ele não poderá recuperar as informações necessárias para iniciar os pods. Nesse cenário, ferramentas locais de solução de problemas, como a `crictl` CLI, não podem ser usadas para iniciar os pods manualmente como uma medida de “quebra de vidro”. O Kubernetes normalmente remove pods com falha e cria novos em vez de reiniciar os pods existentes (consulte \$110213 [no](https://github.com/containerd/containerd/pull/10213) repositório containerd para obter detalhes). GitHub Os pods estáticos são o único objeto de carga de trabalho do Kubernetes que são controlados pelo kubelet e podem ser reiniciados durante esses cenários. No entanto, geralmente não é recomendável usar pods estáticos para implantações de aplicativos. Em vez disso, implante várias réplicas em diferentes hosts para garantir a disponibilidade do aplicativo no caso de várias falhas simultâneas, como uma falha de nó mais uma desconexão de rede entre seus nós e o plano de controle do Kubernetes. # 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 ``` # Credenciais do host por meio de desconexões de rede O EKS Hybrid Nodes é integrado às ativações híbridas do AWS Systems Manager (SSM) e ao AWS IAM Roles Anywhere para credenciais temporárias do IAM que são usadas para autenticar o nó com o plano de controle do EKS. Tanto o SSM quanto o IAM Roles Anywhere atualizam automaticamente as credenciais temporárias que eles gerenciam nos hosts locais. É recomendável usar um único provedor de credenciais nos nós híbridos do seu cluster: ativações híbridas de SSM ou IAM Roles Anywhere, mas não ambas. ## Ativações híbridas SSM As credenciais temporárias fornecidas pelo SSM são válidas por uma hora. Você não pode alterar a duração da validade da credencial ao usar o SSM como seu provedor de credenciais. As credenciais temporárias são alternadas automaticamente pelo SSM antes de expirarem, e a rotação não afeta o status de seus nós ou aplicativos. No entanto, quando há desconexões de rede entre o agente SSM e o endpoint regional do SSM, o SSM não consegue atualizar as credenciais e elas podem expirar. O SSM usa o backoff exponencial para novas tentativas de atualização de credenciais se não conseguir se conectar aos endpoints regionais do SSM. Na versão do agente SSM `3.3.808.0` e posterior (lançada em agosto de 2024), o recuo exponencial é limitado a 30 minutos. Dependendo da duração da desconexão da rede, pode levar até 30 minutos para o SSM atualizar as credenciais, e os nós híbridos não se reconectarão ao plano de controle do EKS até que as credenciais sejam atualizadas. Nesse cenário, você pode reiniciar o agente SSM para forçar uma atualização de credencial. Como efeito colateral do comportamento atual de atualização de credenciais do SSM, os nós podem se reconectar em momentos diferentes, dependendo de quando o agente do SSM em cada nó consegue atualizar suas credenciais. Por causa disso, você pode ver o failover do pod de nós que ainda não estão reconectados a nós que já estão reconectados. Obtenha a versão do agente SSM. Você também pode verificar a seção Fleet Manager do console SSM: ``` # AL2023, RHEL yum info amazon-ssm-agent # Ubuntu snap list amazon-ssm-agent ``` Reinicie o agente SSM: ``` # AL2023, RHEL systemctl restart amazon-ssm-agent # Ubuntu systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent ``` Veja os registros do agente SSM: ``` tail -f /var/log/amazon/ssm/amazon-ssm-agent.log ``` Mensagens de log esperadas durante desconexões de rede: ``` INFO [CredentialRefresher] Credentials ready INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials ``` ## IAM Roles Anywhere As credenciais temporárias provisionadas pelo IAM Roles Anywhere são válidas por uma hora por padrão. Você pode configurar a duração da validade da credencial com o IAM Roles Anywhere por meio do [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object)campo em seu perfil do IAM Roles Anywhere. A duração máxima da validade da credencial é de 12 horas. A [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html)configuração na função do IAM do Hybrid Nodes deve ser maior do que a `durationSeconds` configuração no perfil do IAM Roles Anywhere. Ao usar o IAM Roles Anywhere como provedor de credenciais para seus nós híbridos, a reconexão com o plano de controle do EKS após as desconexões da rede normalmente ocorre alguns segundos após a restauração da rede, porque o kubelet liga `aws_signing_helper credential-process` para obter credenciais sob demanda. Embora não esteja diretamente relacionado a nós híbridos ou desconexões de rede, você pode configurar notificações e alertas para a expiração do certificado ao usar o IAM Roles Anywhere. Para obter mais informações, consulte [Personalizar as configurações de notificação no IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html).