Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede - Amazon EKS
Autenticar no cluster local durante uma desconexão de rede

Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede

Se a sua rede local tiver perdido a conectividade com o AWS Cloud, você poderá 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 o AWS Cloud, recomendamos tentar restaurar a conexão. Para obter instruções, consulte a lista de verificação de solução de problemas da rede do rack doAWS 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 do Amazon EKS em 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 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 poderão ser criados ou excluídos se o AWS Outposts não puder acessar as APIs relevantes da região do AWS (como as APIs do Amazon EBS ou do Amazon S3).

  • Ao integrar o ALB (Ingress) com o AWS Certificate Manager (ACM), os certificados são enviados e armazenados na memória da instância do AWS Outposts ALB Compute. A terminação TLS atual continuará a funcionar no caso de uma desconexão da região 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 certificados gerenciados 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 para o CloudWatch Logs na região da AWS principal. Você pode usar o Prometheus, o Grafana ou as soluções de parceiros do Amazon EKS para monitorar o cluster localmente usando o endpoint de métricas do servidor de API Kubernetes ou usando 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. O novo Pods criado durante as desconexões de rede não recebe tráfego até que o Outpost seja reconectado à Nuvem AWS. Considere a possibilidade de definir a contagem de réplicas para suas aplicações enquanto estiver conectado ao AWS Cloud para acomodar suas necessidades de dimensionamento durante as 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 do plug-in no GitHub. Para obter uma lista do número máximo de Pods que é suportado por 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.

  1. Crie uma solicitação de assinatura do certificado.

    1. 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"

    2. 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

  2. Crie uma solicitação de assinatura do certificado usando o kubectl.

    kubectl create -f admin-csr.yaml

  3. 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.

  4. Aprove a solicitação de assinatura do certificado.

    kubectl certificate approve admin-csr

  5. 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

  6. Recupere e verifique o certificado.

    1. Recupere o certificado.

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

    2. Verifique o certificado.

      cat admin.crt

  7. 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

  8. 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

  9. Visualize o arquivo kubeconfig.

    kubectl get nodes --kubeconfig admin.kubeconfig

  10. 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 seu 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 em execução no momento perdem a conectividade com a região 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.