Pular para o conteúdo principal

Melhores Práticas EKS

Arquitetura​

  • Pense em multilocação, isolamento para ambiente diferente ou carga de trabalho diferente
    • Isolamento no nível da conta usando a organização da AWS
    • Isolamento na camada de rede, ou seja. VPC diferente e cluster diferente
    • Use grupos de nós diferentes (pool de nós) para finalidade/categoria diferente, por exemplo, crie grupos de nós dedicados para ferramentas operacionais, como ferramenta CI/CD, ferramenta de monitoramento, sistema de log centralizado.
    • Namespace separado para carga de trabalho diferente

Confiabilidade | Princípios​

  • Recomendado usar VPC dedicada para EKS
  • Entenda e verifique Cota de serviço do EKS/Fargate e outros serviços relacionados
  • Implemente o Cluster Autoscaler para ajustar automaticamente o tamanho de um cluster EKS para cima e para baixo com base nas demandas de agendamento.
  • Considere o número de nós do trabalhador e a degradação do serviço se houver falha de nó/AZ.
    • Cuide do RTO.
    • Considere ter um nó de buffer.
  • Considere não escolher um tipo de instância muito grande para reduzir o raio de explosão.
  • Habilite o Horizontal Pod Autoscaler para usar a utilização da CPU ou métricas personalizadas para expandir os pods.
  • Use a infraestrutura como código (arquivos e modelos de manifesto do Kubernetes para provisionar clusters/nós do EKS, etc.)
  • Use várias AZs. Distribua as réplicas do aplicativo para diferentes zonas de disponibilidade do nó do trabalhador para redundância
    • Cuidado com seus pods persistentes que usam EBS como PersistentVolume. Use anotação, por exemplo, topology.kubernetes.io/zone=us-east-1c
  • Nós de trabalho altamente disponíveis e escaláveis usando grupos de Auto Scaling, use grupo de nós
    • Considere usar Grupos de nós gerenciados para fácil configuração e alta disponibilidade de nós durante atualizações ou terminação
    • Considere usar o Fargate para não precisar gerenciar nós de trabalho. Mas cuidado com as limitações do Fargate.
  • Considere separar o Node Group para suas funções de aplicativo e utilitário, por exemplo. Banco de dados de log, plano de controle de service mesh
  • Implante aws-node-termination-handler. Ele detecta se o nó ficará indisponível/encerrado, como Interrupção de ponto, em seguida, certifique-se de que nenhum novo trabalho seja agendado lá e, em seguida, drene-o, removendo qualquer trabalho existente. Tutorial | Comunicado
  • Configure Pod Disruption Budgets (PDBs) para limitar o número de pods de um aplicativo replicado que estão inativos simultaneamente de interrupções voluntárias, por exemplo, durante a atualização, implantação contínua e outros casos de uso.
  • Use o AWS Backup para fazer backup de EFS e EBS
  • Use o EFS para classe de armazenamento: o uso do EFS não requer o pré-provisionamento da capacidade e permite migrações de pod mais eficientes entre nós de trabalho (removendo armazenamento anexado ao nó)
  • Instale o Node Problem Detector para fornecer dados acionáveis ​​para curar clusters.
  • Evite erros de configuração, como o uso de antiafinidade, que faz com que o pod não possa ser reprogramado devido a falha do nó.
  • Use sondas de vivacidade e prontidão
  • Pratique a engenharia do caos, use ferramentas disponíveis para automatizar.
    • Mate pods aleatoriamente durante o teste
  • Implementar o gerenciamento de falhas no nível de microsserviço, por exemplo, padrão de disjuntor, controlar e limitar chamadas de repetição (recuo exponencial), limitação, tornar os serviços sem estado sempre que possível
  • Pratique como fazer upgrade do cluster e dos nós do trabalhador para a nova versão.
    • Pratique como drenar os nós do trabalhador.
  • Pratique a engenharia do caos
  • Utilizar ferramentas de CI/CD, automatizar e ter fluxo de processos (aprovação/revisão) para mudanças de infraestrutura. Considere implementar Gitops.
  • Use solução multi-AZ para volume persistente, por exemplo. Thanos+S3 for Prometheus

Eficiência de Desempenho | Princípios​

  • Informe o suporte da AWS se precisar pré-escalar o Plano de Controle (Nó mestre e Etcd) em caso de incremento de carga repentino
  • Escolha o tipo de instância do EC2 correto para seu nó do trabalhador.
    • Entenda os prós e contras de usar muitas instâncias de nós pequenos ou poucas instâncias de nós grandes. Considere a sobrecarga do SO, o tempo necessário para extrair a imagem em uma nova instância quando ela é dimensionada, a sobrecarga do kubelet, a sobrecarga do pod do sistema etc.
    • Entenda a limitação de densidade de pods (número máximo de pods compatível com cada tipo de instância)
  • Use grupos de nós single-AZ, se necessário. Normalmente, uma das melhores práticas é executar um microsserviço no Multi-AZ para disponibilidade, mas para algumas cargas de trabalho (como Spark) que precisam de latência de microssegundos, com alta operação de E/S de rede e transientes, é feito o envio para use single-AZ.
  • Entenda a limitação de desempenho do Fargate. Faça o teste de carga antes de ir para a produção.
  • Certifique-se de que seu pod solicite os recursos necessários. Definir recursos request e limit como CPU, memória
  • Detectar gargalo/latência em um microsserviço com o X-Ray ou outros produtos de rastreamento/APM
  • Escolha o back-end de armazenamento certo. Use o Amazon FSx for Lustre e seu CSI Driver se o seu contêiner persistente precisar de um sistema de arquivos de alto desempenho
  • Monitore o consumo de recursos de pods e nós e o afunilamento de tecnologia. Você pode usar o CloudWatch, CloudWatch Container Insight ou outros produtos
  • Se necessário, inicie instâncias (nós de trabalho) em Placement Groups para aproveitar a baixa latência sem diminuir a velocidade. Você pode usar este modelo do CloudFormation para adicionar novos grupos de nós com conectividade sem bloqueio, sem excesso de assinaturas e totalmente bi-seccional.
  • Se necessário, configure a política de gerenciamento de CPU do Kubernetes como 'static' para alguns pods que precisam CPUs exclusivas

Otimização de custos​

  • Minimize os recursos desperdiçados (não utilizados) ao usar o EC2 como nó do trabalhador.
    • Escolha o tipo de instância do EC2 correto e use o dimensionamento automático de cluster.
    • Considere usar Fargate
    • Considere usar uma ferramenta como kube-resource-report para visualizar o custo de folga e dimensionar corretamente as solicitações para os containers em um pod.
  • Use instâncias spot ou misture sob demanda e spot usando Spot Fleet. Considere usar instâncias spot para ambiente de teste/preparação.
  • Usar instância reservada ou planos de economia
  • Use grupos de nós de AZ único para carga de trabalho com alta operação de E/S de rede (por exemplo, Spark) para reduzir a comunicação entre AZ. Mas, por favor, valide se a execução do Single-AZ não comprometeria a disponibilidade do seu sistema.
  • Considere os serviços gerenciados para ferramentas de suporte, como monitoramento, service mesh, log centralizado, para reduzir o esforço e o custo de sua equipe
  • Marque todos os recursos da AWS quando possível e use rótulos para marcar os recursos do Kubernetes para que você possa analisar facilmente o custo.
  • Considere usar Kubernetes de autogerenciamento (não usando EKS) para cluster sem HA. Você pode configurar usando Kops para seu pequeno cluster k8s.
  • Use Node Affinities usando nodeSelector para pod que requer um tipo de instância EC2 específico.

Operação: Princípios​

Segurança | Princípios​

Packer for AMI build : Configuração do Packer para criar uma AMI EKS personalizada