Preparar-se para desconexões de rede

Se a rede local tiver perdido a conectividade com a Nuvem AWS, 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.

Considerações ao preparar o cluster local para uma desconexão de rede:

Os clusters locais permitem estabilidade e operações contínuas durante desconexões temporárias e não planejadas da rede. O AWS Outposts continua a ser uma oferta totalmente conectada que atua como uma extensão da Nuvem AWS no seu datacenter. No caso de desconexões de rede entre o Outpost e a Nuvem AWS, recomendamos que você tente restaurar a conexão. Para obter instruções, consulte a Lista de verificação da solução de problemas da rede de racks do AWS Outposts no Guia do usuário do AWS Outposts. Para obter informações sobre como solucionar problemas de clusters locais, consulte Solucionar problemas de clusters locais para o Amazon EKS no 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 Métricas do Outposts no Guia do usuário do AWS Outposts.
Os clusters locais usam o IAM como mecanismo de autenticação padrão usando o Autenticador do AWS Identity and Access Management para Kubernetes. O IAM não está disponível durante desconexões de rede. Assim, os clusters locais são compatíveis com um mecanismo de autenticação alternativo usando certificados x.509 que você pode usar para se conectar ao cluster durante desconexões de rede. Para obter informações sobre como obter e usar um certificado x.509 para o cluster, consulte Autenticar no cluster local durante uma desconexão de rede.
Caso não você consiga acessar o Route 53 durante desconexões de rede, considere o uso de servidores DNS locais no ambiente on-premises. As instâncias do ambiente de gerenciamento do Kubernetes usam endereços IP estáticos. Você pode configurar os hosts que usa para se conectar ao cluster com o nome do host do endpoint e os endereços IP como uma alternativa ao uso de servidores DNS locais. Para obter mais informações, consulte DNS no Guia do usuário do AWS Outposts.
Se você esperar aumentos no tráfego das aplicações durante desconexões de rede, pode provisionar capacidade computacional adicional no cluster quando estiver conectado à nuvem. As instâncias do Amazon EC2 estão incluídas no preço do AWS Outposts. Portanto, a execução de instâncias adicionais não afeta o custo de uso da AWS.
Durante desconexões de rede para permitir operações de criação, atualização e escalação de workloads, as imagens de contêiner da aplicação devem estar acessíveis pela rede local e o cluster deve ter capacidade suficiente. Os clusters locais não hospedam um registro de contêiner para você. Se os Pods foram executados anteriormente nesses nós, as imagens de contêiners serão armazenadas em cache nos nós. Se você normalmente extrair imagens de contêiner da aplicação do Amazon ECR na nuvem, considere executar um cache ou registro local. Um cache ou registro local será útil se você precisar de operações de criação, atualização e escalação para recursos de workload durante desconexões de rede.
Os clusters locais usam o Amazon EBS como a classe de armazenamento padrão para volumes persistentes e o driver da CSI do Amazon EBS para gerenciar o ciclo de vida dos volumes persistentes do Amazon EBS. Durante desconexões de rede, os Pods que são baseados no Amazon EBS não podem ser criados, atualizados nem escalados. Isso porque essas operações exigem chamadas para a API do Amazon EBS na nuvem. Se você estiver implantando workloads com estado em clusters locais e precisar de operações de criação, atualização ou escalabilidade durante desconexões de rede, considere usar um mecanismo de armazenamento alternativo.
Os snapshots do Amazon EBS não podem ser criados ou excluídos se o AWS Outposts não puder acessar as APIs relevantes da AWS dentro da região (como as APIs do Amazon EBS ou do Amazon S3).
Ao integrar o ALB (entrada) com o AWS Certificate Manager (ACM), os certificados são enviados e armazenados na memória da instância de computação do ALB do AWS Outposts. A terminação TLS atual continuará operando no caso de uma desconexão do Região da AWS. As operações de mutação nesse contexto falharão (como novas definições de entrada, novas operações de API de certificados baseados em ACM, escala de computação do ALB ou rotação de certificados). Para obter mais informações, consulte Solução de problemas de renovação de certificado gerenciado no Guia do usuário do AWS Certificate Manager.
Os logs do ambiente de gerenciamento do Amazon EKS são armazenados em cache localmente nas instâncias do ambiente de gerenciamento do Kubernetes durante desconexões de rede. Após a reconexão, os logs são enviados ao CloudWatch Logs na Região da AWS pai. Você pode usar soluções de parceiros do Prometheus, do Grafana ou do Amazon EKS para monitorar o cluster localmente usando o endpoint de métricas do servidor de API do Kubernetes ou usando o Fluent Bit para logs.
Se você estiver usando o AWS Load Balancer Controller no Outposts para tráfego das aplicações, os Pods existentes fronteados pelo AWS Load Balancer Controller continuarão a receber tráfego durante desconexões de rede. Novos Pods criados durante desconexões de rede só receberão tráfego quando o Outpost for reconectado à Nuvem AWS. Considere definir a contagem de réplicas das suas aplicações durante a conexão com a Nuvem AWS para acomodar suas necessidades de escalabilidade durante desconexões de rede.
O Amazon VPC CNI plugin for Kubernetes assume o modo IP secundário por padrão. Ele é configurado com WARM_ENI_TARGET = 1, o que permite que o plug-in mantenha disponível “uma interface de rede totalmente elástica” de endereços IP. Considere mudar os valores WARM_ENI_TARGET,WARM_IP_TARGET e MINIMUM_IP_TARGET de acordo com suas necessidades de escalonamento durante um estado desconectado. Para obter mais informações , consulte o arquivo readme no GitHub. Para obter uma lista do número máximo de Pods compatível com cada tipo de instância, consulte o arquivo eni-max-pods.txt no GitHub.

Autenticar no cluster local durante uma desconexão de rede

O AWS Identity and Access Management (IAM) não está disponível durante desconexões de rede. Você não pode autenticar no cluster local usando credenciais do IAM enquanto está desconectado. Porém, você pode se conectar ao cluster pela rede local usando certificados x509 quando estiver desconectado. Você precisa baixar e armazenar o certificado X509 de um cliente para usar durante as desconexões. Neste tópico, você aprenderá a criar e usar o certificado para autenticação no cluster quando ele está em um estado desconectado.

Crie uma solicitação de assinatura do certificado.

Gere uma solicitação de assinatura do certificado.


openssl req -new -newkey rsa:4096 -nodes -days 365 \
    -keyout admin.key -out admin.csr -subj "/CN=admin"

Crie uma solicitação de assinatura do certificado no Kubernetes.


BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: admin-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  request: ${BASE64_CSR}
  usages:
  - client auth
EOF

Crie uma solicitação de assinatura do certificado usando o kubectl.
```
kubectl create -f admin-csr.yaml
```
Verifique o status da solicitação de assinatura do certificado.
```
kubectl get csr admin-csr
```
Veja um exemplo de saída abaixo.
```
NAME       AGE   REQUESTOR                       CONDITION
admin-csr  11m   kubernetes-admin                Pending
```
O Kubernetes criou a solicitação de assinatura do certificado.
Aprove a solicitação de assinatura do certificado.
```
kubectl certificate approve admin-csr
```

Verifique novamente o status da solicitação de assinatura do certificado para aprovação.


kubectl get csr admin-csr

Veja um exemplo de saída abaixo.


NAME       AGE   REQUESTOR                     CONDITION
admin-csr  11m   kubernetes-admin              Approved

Recupere e verifique o certificado.

Recupere o certificado.


kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt

Verifique o certificado.
```
cat admin.crt
```

Crie uma vinculação de função de cluster para um usuário admin.


kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
    --user=admin --group=system:masters

Gere um kubeconfig com escopo de usuário para um estado desconectado.

Você pode gerar um arquivo kubeconfig usando os certificados admin baixados. Substitua my-cluster e apiserver-endpoint nos comandos a seguir.


aws eks describe-cluster --name my-cluster \
    --query "cluster.certificateAuthority" \
    --output text | base64 --decode > ca.crt


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

Visualize o arquivo kubeconfig.


kubectl get nodes --kubeconfig admin.kubeconfig

Se você já tiver serviços em produção no Outpost, pule esta etapa. Se o Amazon EKS for o único serviço em execução no Outpost e o Outpost não estiver em produção no momento, você poderá simular uma desconexão de rede. Antes de entrar em produção com o cluster local, simule uma desconexão para ter certeza de que pode acessar o cluster mesmo quando ele está no estado desconectado.
1. Aplique regras de firewall nos dispositivos de rede que conectam o Outpost à Região da AWS. Com isso, o link de serviço do Outpost é desconectado. Você não pode criar novas instâncias. As instâncias atualmente em execução perdem conectividade com a Região da AWS e a Internet.
2. Você pode testar a conexão com o cluster local enquanto estiver desconectado usando o certificado x509. Certifique-se de alterar o kubeconfig para o admin.kubeconfig que você criou em uma etapa anterior. Substitua my-cluster pelo nome do cluster local.
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
Se você notar algum problema com os clusters locais enquanto eles estiverem no estado desconectado, será recomendável abrir um tíquete de suporte.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Requisitos para sub-rede e VPC

Considerações sobre a capacidade