View a markdown version of this page

Solução de problemas do modo de saída do ambiente de gerenciamento - Amazon EKS

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Solução de problemas do modo de saída do ambiente de gerenciamento

Ao usar o modo de saída do ambiente de gerenciamento CUSTOMER_ROUTED, você é responsável pela conectividade de rede das ENIs do ambiente de gerenciamento. Esta página cobre problemas comuns e suas soluções.

Detectar uma falha no webhook

Quando o ambiente de gerenciamento não consegue acessar um servidor de webhook ou provedor OIDC, o sintoma geralmente aparece como um tempo limite de webhook. Para confirmar, crie ou modifique um recurso que aciona o webhook e verifique o erro:

kubectl apply -f my-resource.yaml

Normalmente, uma falha de conectividade ou de DNS retorna um erro semelhante ao seguinte:

Error from server (InternalError): error when creating "my-resource.yaml": Internal error occurred: failed calling webhook "my-webhook.example.com": failed to call webhook: Post "https://my-webhook.example.com/validate?timeout=10s": context deadline exceeded

Você também pode verificar se há erros de webhook em eventos recentes em todo o cluster:

kubectl get events --all-namespaces --field-selector reason=FailedCreate

Nenhuma rota de saída para os endpoints necessários

Sintomas:

  • Os webhooks de admissão expiram.

  • A descoberta do provedor OIDC falha.

  • A criação ou atualização do cluster é interrompida.

Causa:

As sub-redes da interface de rede do ambiente de gerenciamento não têm uma rota funcional para os endpoints que o ambiente de gerenciamento precisa acessar. Geralmente, a tabela de rotas de sub-rede não tem uma rota padrão para um dispositivo de saída. Como alternativa, esse dispositivo está configurado incorretamente. O dispositivo de saída geralmente é um gateway NAT. No entanto, pode ser uma instância NAT, um dispositivo de firewall ou proxy ou um gateway de trânsito para uma VPC de saída centralizada.

Solução:

  1. Identifique as sub-redes que seu cluster usa para interfaces de rede do ambiente de gerenciamento:

    aws eks describe-cluster --name my-cluster \ --query "cluster.resourcesVpcConfig.subnetIds"
  2. Para cada sub-rede, verifique a tabela de rotas associada:

    aws ec2 describe-route-tables \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1"
  3. Verifique se existe uma rota para 0.0.0.0/0 (ou uma rota que abranja o endpoint) apontando para seu dispositivo de saída. Se não houver, adicione a rota. O exemplo a seguir adiciona uma rota de gateway NAT; substitua seu próprio destino de saída (por exemplo, um gateway de trânsito ou uma interface de rede):

    aws ec2 create-route \ --route-table-id rtb-ExampleID \ --destination-cidr-block 0.0.0.0/0 \ --nat-gateway-id nat-ExampleID

NACLs bloqueando o webhook ou o tráfego do ambiente de gerenciamento

Sintomas:

  • Tempo limite de chamadas do webhook de admissão (erro: failed calling webhook).

  • Falhas intermitentes ao criar ou modificar recursos do Kubernetes que usam webhooks de mutação ou validação.

Causa:

As ACLs de rede nas sub-redes da ENI do ambiente de gerenciamento bloqueiam o tráfego de saída para os endpoints do webhook ou bloqueiam o tráfego de retorno da porta efêmera de entrada.

Solução:

  1. Identifique as NACLs associadas às sub-redes do seu ambiente de gerenciamento:

    aws ec2 describe-network-acls \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1"
  2. Verifique a existência das seguintes regras:

    Direction Protocolo Intervalo de portas Destino/Origem Ação

    Saída

    TCP

    443

    0.0.0.0/0 (ou CIDR do webhook)

    Permitir

    Saída

    TCP

    10250

    CIDR da VPC

    Permitir

    Entrada

    TCP

    1024–65535

    0.0.0.0/0

    Permitir (tráfego de retorno efêmero)

    nota

    As NACLs são sem estado. Você deve permitir explicitamente o tráfego de retorno em portas efêmeras (1024–65535) nas regras de entrada.

    Essas regras abrangem dois caminhos diferentes. A regra da porta 443 é para tráfego de saída para o webhook e endpoints do OIDC, que saem da VPC pelo seu dispositivo de saída. A regra da porta 10250 é para a API do kubelet, que permanece na sua VPC entre o ambiente de gerenciamento e seus nós. Um dispositivo de saída ausente não afeta a porta 10250, mas uma ACL de rede restritiva pode bloqueá-la.

Grupos de segurança que impedem o acesso

Sintomas:

  • As chamadas de webhook falham.

  • O ambiente de gerenciamento não consegue acessar a API do kubelet nos nós (porta 10250).

  • O kubectl exec, kubectl logs ou kubectl port-forward falha.

Causa:

O grupo de segurança anexado às ENIs do ambiente de gerenciamento (o grupo de segurança do cluster) não permite tráfego de saída nas portas necessárias.

Solução:

  1. Identificar o grupo de segurança do cluster:

    aws eks describe-cluster --name my-cluster \ --query "cluster.resourcesVpcConfig.clusterSecurityGroupId"
  2. Verifique se as regras de saída permitem:

    Protocolo Porta Destino

    TCP

    443

    0.0.0.0/0 (endpoints de webhook, provedores OIDC)

    TCP

    10250

    Grupo de segurança de nós ou CIDR da VPC (API do kubelet)

  3. Se as regras de saída forem restritivas, adicione regras para o tráfego necessário:

    aws ec2 authorize-security-group-egress \ --group-id sg-ExampleClusterSG \ --protocol tcp \ --port 443 \ --cidr 0.0.0.0/0
    nota

    Se você tiver requisitos de saída rígidos e souber os intervalos de IP do seu webhook e dos endpoints do OIDC, poderá definir o escopo da regra da porta 443 para esses CIDRs específicos em vez de 0.0.0.0/0. A regra da porta 10250 (API do kubelet) é interna da VPC; defina o escopo para o grupo de segurança do nó ou para o CIDR da VPC, e não para a internet.

Falha na atualização do conjunto de opções do DHCP

Sintomas:

  • A resolução do DNS falha no ambiente de gerenciamento.

  • As operações de cluster que exigem pesquisas de DNS (descoberta do OIDC, resolução de webhook) falham.

  • O problema aparece depois que as opções do DHCP da VPC são alteradas ou após uma atualização do ambiente de gerenciamento.

Causa:

O conjunto de opções do DHCP da VPC foi alterado. Como alternativa, ele não inclui AmazonProvidedDNS em seus servidores de nomes de domínio. Pode também faltar outro resolvedor capaz de resolver os nomes de que o ambiente de gerenciamento precisa. O ambiente de gerenciamento detecta automaticamente as alterações do conjunto de opções do DHCP e aplica as novas configurações de DNS, geralmente em uma hora. O ambiente de gerenciamento só pode fazer isso quando o perfil do IAM do cluster concede as permissões de leitura necessárias do Amazon EC2.

Solução:

  1. Verifique a configuração das opções do DHCP da sua VPC:

    aws ec2 describe-vpcs --vpc-ids vpc-ExampleID \ --query "Vpcs[0].DhcpOptionsId" \ --region region-code
    aws ec2 describe-dhcp-options --dhcp-options-ids dopt-ExampleID --region region-code
  2. Confirme se domain-name-servers inclui AmazonProvidedDNS (o resolvedor de DNS fornecido pela Amazon, que é a base do seu CIDR IPv4 da VPC mais dois) ou outro resolvedor que possa resolver os nomes de que o ambiente de gerenciamento precisa.

  3. Confirme se o perfil do IAM do cluster concede ec2:DescribeVpcs e ec2:DescribeDhcpOptions. Sem essas permissões, o ambiente de gerenciamento não consegue ler as opções do DHCP atualizadas e não pode atualizar suas configurações de DNS. Para obter mais informações, consulte Perfil do IAM do cluster do Amazon EKS.

  4. Depois que as opções de DHCP forem alteradas, aguarde até uma hora para que o ambiente de gerenciamento detecte e aplique as novas configurações automaticamente. Nenhuma atualização de cluster ou substituição de instância é necessária. Se a resolução de DNS ainda falhar após uma hora e as permissões acima estiverem em vigor, entre em contato com o AWS Support.

Problemas de roteamento IPv6

Sintomas:

  • Os clusters IPv6 não conseguem acessar endpoints externos de OIDC ou webhook.

  • O registro de nós funciona em IPv4, mas os serviços em IPv6 falham.

Causa:

A tabela de rotas de sub-rede não tem uma rota ::/0 para um gateway da internet somente de saída, ou os grupos de segurança/NACLs não permitem tráfego IPv6.

Solução:

  1. Verifique se existe um gateway da internet somente de saída e se está anexado à VPC:

    aws ec2 describe-egress-only-internet-gateways \ --filters "Name=attachment.vpc-id,Values=vpc-ExampleID"
  2. Verifique se a tabela de rotas das sub-redes do ambiente de gerenciamento tem uma rota ::/0:

    aws ec2 describe-route-tables \ --filters "Name=association.subnet-id,Values=subnet-ExampleID1" \ --query "RouteTables[0].Routes[?DestinationIpv6CidrBlock=='::/0']"
  3. Se não houver, adicione a rota:

    aws ec2 create-route \ --route-table-id rtb-ExampleID \ --destination-ipv6-cidr-block ::/0 \ --egress-only-internet-gateway-id eigw-ExampleID
  4. Certifique-se de que as NACLs e os grupos de segurança permitam o tráfego de saída IPv6 na porta 443 e portas efêmeras de entrada.

Provedor OIDC inacessível

Sintomas:

  • IAM roles for service accounts (IRSA) falha: os pods não podem assumir perfis.

  • Os eventos de cluster mostram erros de descoberta do OIDC.

Causa:

O ambiente de gerenciamento não pode acessar o endpoint do provedor OIDC (por exemplo, oidc.eks.region-code.amazonaws.com) porque a saída está bloqueada.

Solução:

  1. Verifique se o caminho de saída e a tabela de rotas permitem tráfego HTTPS de saída. Para etapas de solução de problemas quando a rota de saída está ausente ou configurada incorretamente, consulte Nenhuma rota de saída para os endpoints necessários.

  2. Verifique se o grupo de segurança do cluster permite TCP 443 de saída para 0.0.0.0/0 (consulte Grupos de segurança que impedem o acesso).

📝 Editar esta página no GitHub