**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. # Preparar clusters locais do Amazon EKS no AWS Outposts configurado com armazenamento de instância do EC2 para desconexões de rede Se o link do AWS Ouposts que conecta a rede local com a AWS Cloud tiver perdido a conectividade, você pode continuar a usar o cluster local do Amazon EKS em um outpost. Este tópico aborda como você pode preparar o cluster local para desconexões de rede e as considerações relacionadas. + Clusters locais permitem estabilidade e operações contínuas durante desconexões temporárias e não planejadas da rede. AWS O Outposts continua sendo uma oferta totalmente conectada que atua como uma extensão da Nuvem AWS no seu data center. Em caso de desconexão da rede entre o outpost e a AWS Cloud, tente restaurar a conexão. Para obter instruções, consulte [Lista de verificação de solução de problemas de rede de rack do AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) no *Guia do usuário do AWS Outposts*. + Os Outposts emitem uma métrica `ConnectedStatus` que você pode usar para monitorar o estado da conectividade do Outpost. Para obter mais informações, consulte [Outposts Metrics](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) no *Guia do usuário do AWS Outposts*. ## Autenticação durante desconexões de rede Os clusters locais oferecem são compatíveis com vários mecanismos de autenticação. Sua disponibilidade durante desconexões de rede varia: | Mecanismo de autenticação | Disponível durante uma desconexão? | | --- | --- | | AWS IAM (entradas de acesso, ConfigMap do `aws-auth`) | Não. O IAM exige conectividade com a região da AWS. | | OIDC (fornecedor fornecido pelo cliente) | Depende da localização do provedor. Se o provedor OIDC puder ser acessado pela rede local do outpost, a autenticação continuará funcionando. | | Certificados X.509 de cliente | Sim. Os certificados são validados localmente pelo servidor de API do Kubernetes. | | IRSA (perfis do IAM para contas de serviço) | Não. Consulte [IRSA e Identidade de Pods durante desconexões](#eks-outposts-instance-store-network-disconnects-irsa). | | Identidade de Pods do EKS | Não. Consulte [IRSA e Identidade de Pods durante desconexões](#eks-outposts-instance-store-network-disconnects-irsa). | ### Certificados X.509 de cliente Para manter o acesso do `kubectl` durante desconexões de rede, crie um certificado x.509 de cliente antes que a desconexão ocorra. Para criar um certificado de administração: 1. Gere uma chave privada e uma solicitação de assinatura de certificado (CSR): ``` openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Crie um recurso `CertificateSigningRequest` do Kubernetes e aprove-o: ``` cat admin.csr | base64 | tr -d '\n' > admin.csr.b64 ``` ``` apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: signerName: kubernetes.io/kube-apiserver-client usages: - client auth ``` ``` kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr ``` 1. Recupere o certificado assinado: ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Crie um `ClusterRoleBinding` para conceder acesso de administrador: ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Crie uma `kubeconfig` que use o certificado: ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server $APISERVER_ENDPOINT --embed-certs kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` ### Resolução de DNS do endpoint do cluster durante desconexões O endpoint do servidor de API do Kubernetes de um cluster local é hospedado no Amazon Route 53 e resolvido para os endereços IP privados das interfaces de rede elástica (ENIs) entre contas que o Amazon EKS cria nas sub-redes. Essas ENIs têm endereços IP privados estáticos que não mudam durante a operação normal do cluster. Durante uma desconexão de rede, o outpost não consegue acessar o Route 53, então, o nome do host do endpoint do cluster não será resolvido a menos que você tenha preparado um caminho de resolução local. Três categorias de clientes precisam acessar o servidor de API: + **Administradores de cluster** que executam o `kubectl`. + **Nós de processamento** (`kubelet`) enviando os sinais vitais dos nós e extraindo especificações. + **`kube-proxy`** em cada nó, o que configura os IPs de serviço do cluster. #### Opção 1: solução de DNS local (recomendável) A AWS recomenda a implantação de uma solução de DNS local que armazene em cache os registros do endpoint do cluster e os forneça enquanto o outpost estiver desconectado. Você pode executar seu próprio servidor DNS no ambiente on-premises que armazena em cache os registros do endpoint do cluster. Se você usar uma solução de DNS local, recomendamos que aponte o `kubeconfig` e as AMIs do nó de processamento para o nome do host do endpoint do cluster (não para os endereços IP da ENI) para que a resolução seja consistente com a solução de DNS local. #### Opção 2: acesso estático baseado em IP Se não quiser executar uma solução de DNS local, use acesso estático baseado em IP. + **Administradores:** configure o `kubeconfig` para apontar diretamente para o endereço IP privado de uma ENI entre contas. Encontre as ENIs pesquisando interfaces de rede com a descrição `Amazon EKS {{cluster-name}} ` em sua conta da AWS. O endereço IP de cada ENI é estável durante a vida útil do cluster em operação normal. + **Nós de processamento (AMIs otimizadas para o Amazon EKS):** quando você inicia os nós de processamento em uma AMI otimizada para Amazon EKS, o script de bootstrap adiciona o endpoint do cluster `/etc/hosts` com os endereços IP da ENI. Nenhuma configuração adicional é necessária. + **Nós de processamento (AMIs personalizadas):** adicione o nome de host do endpoint do cluster e os endereços IP da ENI a `/etc/hosts` no bootstrap personalizado. Caso contrário, o `kubelet` e o `kube-proxy` não poderão acessar o servidor de API durante uma desconexão. **Importante** Se uma ENI entre contas for excluída ou se seu endereço IP for alterado, por exemplo, se você a excluirou modificar de modo que impeça que o Amazon EKS a reconecte, todos os nó e todos os administradores que usarem acesso baseado em IP estático deverão ser atualizados manualmente. Com uma solução de DNS local, nenhuma intervenção manual é necessária. ### Resolução de DNS de pods durante desconexões Para evitar falhas de DNS durante a operação desconectada, configure o modelo de inicialização de nó de processamento para substituir a configuração `kubelet’s `resolvConf`. Em seus dados de usuário, crie um arquivo personalizado `resolv.conf` (por exemplo, `/etc/kubernetes/resolv.conf`) contendo somente `nameserver 10.0.0.2` (sem o domínio de pesquisa da VPC) e defina a `spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf` na `NodeConfig`. Isso remove o domínio de pesquisa ` {{region-code}}.compute.internal` da configuração de DNS do pod, impedindo que as consultas sejam encaminhadas para o resolvedor de DNS da VPC inacessível durante a desconexão. O seguinte exemplo mostra os dados de usuário do nó de processamento: ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash mkdir -p /etc/kubernetes echo "nameserver [.replaceable]``10.0.0.2``" > /etc/kubernetes/resolv.conf --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster ... kubelet: config: resolvConf: /etc/kubernetes/resolv.conf --BOUNDARY-- ``` ### IRSA e Identidade de Pods durante desconexões **Importante** O IRSA e o Identidade de Pods do EKS dependem do AWS STS na região da AWS. Durante uma desconexão de rede, as workloads que usam o IRSA ou o Identidade de Pods não podem obter novas credenciais. As credenciais existentes expiram depois de um tempo. Não recomendamos levar dependências funcionais ou operacionais de serviços da AWS baseados em região para workloads que devem permanecer disponíveis durante desconexões de rede. ## Comportamento do `etcd` durante as desconexões Durante desconexões de rede, não é possível fazer backup de snapshots do `etcd`. Se mais de uma instância do `etcd` ficar indisponível durante uma desconexão, o `etcd` perde o quórum e as operações de API do Kubernetes não ficam disponíveis até o outpost se reconectar e o quorum do `etcd` ser restaurado. As workloads que já estão em execução continuam operando. ## Registro em log do ambiente de gerenciamento durante desconexões Durante desconexões, os logs do ambiente de gerenciamento são armazenados em cache localmente nas instâncias do ambiente de gerenciamento. Quando a conectividade é restaurada, os logs são enviados para o Amazon CloudWatch Logs na região principal da AWS. Não é necessário instalar nem manter nenhum agente de registro em log no ambiente de gerenciamento. ## Observabilidade local Você pode monitorar o cluster localmente durante desconexões usando o [Prometheus](https://prometheus.io/), o [Grafana](https://grafana.com/) ou outras soluções de terceiros para extrair o endpoint de métricas do servidor de API do Kubernetes. ## Repositório local de imagens Para escalar implantações com réplicas adicionais ou para recuperar de falhas de pod durante desconexões, é necessário ter um repositório local de imagens de contêiner (como um registro do Docker) ou armazenar as imagens em cache no nó antes da desconexão. O Amazon ECR não fica disponível durante desconexões de rede. ## Ajuste do comportamento de failover de pods do Kubernetes Durante uma desconexão de rede, o ambiente de gerenciamento do Kubernetes não pode se comunicar com a região da AWS. Se um node ficar inacessível, o comportamento padrão do Kubernetes é remover os pods após um tempo limite. Você pode ajustar esse comportamento usando tolerâncias e `tolerationSeconds` nas especificações do pod para controlar a velocidade com que os pods são reagendados durante partições. Para obter orientações detalhadas e exemplos, consulte https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html\#*tune\_kubernetes\_pod\_failover\_behavior[Ajuste do comportamento de failover de pods do Kubernetes] no Guia de práticas recomendadas do Amazon EKS*. ## Simular uma desconexão de rede Antes de colocar em produção o cluster local, simule uma desconexão para ter certeza de que poderá acessar o cluster mesmo quando ele estiver desconectado. 1. Aplique regras de firewall nos dispositivos de rede que conectam seu Outpost à região da AWS. Com isso, o link de serviço do Outpost é desconectado. 1. Teste a conexão com o cluster local usando o certificado x.509 que você criou: ``` kubectl --kubeconfig admin.kubeconfig get nodes ``` **nota** Se já tiver serviços em produção no outpost, não simule uma desconexão. Desconectar o link de serviço afeta todos os serviços em execução no outpost.