Plano de dados EKS

Para operar aplicativos de alta disponibilidade e resiliência, você precisa de um plano de dados altamente disponível e resiliente. Um plano de dados elástico garante que o Kubernetes possa escalar e corrigir seus aplicativos automaticamente. Um plano de dados resiliente consiste em dois ou mais nós de trabalho, pode crescer e diminuir com a carga de trabalho e se recuperar automaticamente de falhas.

Você tem várias opções para nós de trabalho com o EKS: nós gerenciados no Modo Automático do EKS, EC2 Instâncias e Fargate.

O EKS Auto Mode oferece o caminho mais fácil para um plano de dados resiliente. O Modo Automático estende o gerenciamento de clusters Kubernetes pela AWS além do próprio cluster, para permitir que a AWS também configure e gerencie a infraestrutura que permite a operação tranquila de suas cargas de trabalho. O Modo Automático aumenta ou diminui automaticamente o plano de dados à medida que o Kubernetes escala os pods e trabalha para garantir continuamente que os nós em seu cluster sejam dimensionados de forma adequada e econômica para as cargas de trabalho em execução no momento.

Se você escolher EC2 instâncias, você mesmo poderá gerenciar os nós de trabalho ou usar grupos de nós gerenciados pelo EKS. Você pode ter um cluster com uma combinação de modo automático, nós de trabalho gerenciados e autogerenciados e Fargate.

O Fargate executa cada pod em um ambiente computacional isolado. Cada pod executado no Fargate tem seu próprio nó de trabalho. O Fargate escala automaticamente o plano de dados à medida que o Kubernetes escala os pods. Você pode escalar o plano de dados e sua carga de trabalho usando o autoescalador horizontal do pod.

A forma preferida de escalar os nós de EC2 trabalho (se não estiver usando o EKS Auto Mode, onde isso é executado automaticamente pela AWS) é usando grupos Karpenter, Kubernetes Cluster Autoscaler ou Auto Scaling. EC2

Recomendações

Distribua os nós de trabalho e as cargas de trabalho em vários AZs

Você pode proteger suas cargas de trabalho contra falhas em uma AZ individual executando nós de trabalho e pods em vários. AZs Você pode controlar a AZ na qual os nós de trabalho são criados usando as sub-redes nas quais você cria os nós.

O método recomendado para distribuir pods AZs é usar restrições de dispersão de topologia para pods. Recursos de escalonamento automático, como o EKS Auto Mode e o Karpenter, estão cientes das restrições de dispersão da topologia e iniciarão automaticamente os Nodes da maneira correta AZs para permitir que suas restrições sejam atendidas.

A implantação abaixo distribui os pods, AZs se possível, permitindo que esses pods funcionem de qualquer maneira, caso contrário:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1

nota

kube-schedulersó conhece os domínios de topologia por meio de nós que existem com esses rótulos. Se a implantação acima for implantada em um cluster com nós somente em uma única zona, todos os pods serão programados nesses nós, pois kube-scheduler não conhece as outras zonas. Para que essa distribuição de topologia funcione conforme o esperado com o agendador, os nós já devem existir em todas as zonas. A minDomains propriedade de restrições de dispersão de topologia é usada para informar o agendador sobre o número de domínios elegíveis, mesmo se houver um Node em execução para evitar esse problema.

Atenção

whenUnsatisfiableDefinir como DoNotSchedule fará com que os pods não sejam programáveis se a restrição de dispersão da topologia não puder ser atendida. Ele só deve ser definido se for preferível que os pods não sejam executados em vez de violar a restrição de dispersão da topologia.

Nas versões mais antigas do Kubernetes, você pode usar regras de antiafinidade de pods para programar pods em vários. AZs O manifesto abaixo informa o programador do Kubernetes a preferir o agendamento de pods de forma distinta. AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx

Atenção

Não exija que os pods sejam programados de AZs forma distinta, caso contrário, o número de pods em uma implantação nunca excederá o número de. AZs

Garanta a capacidade de iniciar nós em cada AZ ao usar volumes do EBS

Se você usa o Amazon EBS para fornecer volumes persistentes, precisará garantir que os pods e o volume associado do EBS estejam localizados na mesma AZ. Um pod não pode acessar volumes persistentes suportados pelo EBS localizados em uma AZ diferente. O programador do Kubernetes sabe em qual AZ um nó de trabalho está localizado a partir dos rótulos que estão no nó e sempre agendará um pod que exija um volume do EBS no mesmo AZ do volume. No entanto, se não houver nós de trabalho disponíveis na AZ em que o volume está localizado, o pod não pode ser programado.

Se estiver usando o EKS Auto Mode ou o Karpenter, você precisará garantir que suas sub-redes sejam NodeClass selecionadas em cada AZ. Se estiver usando grupos de nós gerenciados, você precisa garantir que tenha um grupo de nós em cada AZ.

Um recurso de armazenamento do EBS é incorporado ao EKS Auto Mode, mas se estiver usando Karpenter ou Managed Node Groups, o EBS CSI também precisará ser instalado.

Use o EKS Auto Mode para gerenciar nós de trabalho

O EKS Auto Mode simplifica o gerenciamento do EKS fornecendo clusters prontos para produção com o mínimo de sobrecarga operacional. O modo automático é responsável por aumentar ou diminuir o número de nós, dependendo dos pods em execução no cluster. Os nós são atualizados automaticamente com patches e correções de software, com as atualizações sendo realizadas de acordo com as configurações de NodePoolinterrupção definidas e os orçamentos de interrupção do pod.

Execute o Node Monitoring Agent

O Node Monitoring Agent monitora e reage aos problemas de saúde do Node publicando eventos do Kubernetes e atualizando a condição de status nos Nodes. O agente de monitoramento de nós está incluído nos nós do modo automático do EKS e pode ser instalado como um complemento do EKS para nós que não são gerenciados pelo modo automático.

O EKS Auto Mode, o Managed Node Groups e o Karpenter têm a capacidade de detectar condições fatais de Node relatadas pelo Node Monitoring Agent e reparar esses Nodes automaticamente quando essas condições ocorrerem.

Implemente QoS

Para aplicações críticas, considere definir requests = limits para o contêiner no pod. Isso garantirá que o contêiner não seja eliminado se outro pod solicitar recursos.

É uma prática recomendada implementar limites de CPU e memória para todos os contêineres, pois isso evita que um contêiner consuma inadvertidamente os recursos do sistema e afete a disponibilidade de outros processos co-localizados.

Configurar e dimensionar recursos Requests/Limits para todas as cargas de trabalho

Algumas orientações gerais podem ser aplicadas ao dimensionamento de solicitações de recursos e limites para cargas de trabalho:

• Não especifique limites de recursos na CPU. Na ausência de limites, a solicitação atua como um peso sobre quanto tempo relativo de CPU os contêineres recebem. Isso permite que suas cargas de trabalho usem toda a CPU sem limites artificiais ou inanição.

• Para recursos que não são de CPU, configurar requests = limits fornece o comportamento mais previsível. Serequests! =limits, o contêiner também tem sua QOS reduzida de Garantida para Estável, aumentando a probabilidade de ser despejado em caso de pressão no nó.

• Para recursos que não sejam de CPU, não especifique um limite muito maior do que a solicitação. Quanto maiores limits forem configurados em relação arequests, maior a probabilidade de os nós ficarem sobrecarregados, levando a grandes chances de interrupção da carga de trabalho.

• Solicitações dimensionadas corretamente são particularmente importantes ao usar uma solução de auto-escalonamento de nós, como Karpenter ou Cluster. AutoScaler Essas ferramentas analisam suas solicitações de carga de trabalho para determinar o número e o tamanho dos nós a serem provisionados. Se suas solicitações forem muito pequenas com limites maiores, você poderá descobrir que suas cargas de trabalho foram removidas ou o OOM eliminado se estiverem compactadas em um nó.

Determinar as solicitações de recursos pode ser difícil, mas ferramentas como o Vertical Pod Autoscaler podem ajudar você a “dimensionar corretamente” as solicitações observando o uso dos recursos do contêiner em tempo de execução. Outras ferramentas que podem ser úteis para determinar o tamanho das solicitações incluem:

• Cachinhos Dourados

• Parca

• Perfis

• rsg

Configurar cotas de recursos para namespaces

Namespaces são destinados para o uso em ambientes com muitos usuários distribuídos entre várias equipes ou projetos. Eles fornecem um escopo para nomes e são uma forma de dividir os recursos do cluster entre várias equipes, projetos e cargas de trabalho. Você pode limitar o consumo agregado de recursos em um namespace. O ResourceQuotaobjeto pode limitar a quantidade de objetos que podem ser criados em um namespace por tipo, bem como a quantidade total de recursos computacionais que podem ser consumidos pelos recursos desse projeto. Você pode limitar a soma total dos recursos de and/or computação de armazenamento (CPU e memória) que podem ser solicitados em um determinado namespace.

Se a cota de recursos estiver habilitada para um namespace para recursos computacionais, como CPU e memória, os usuários devem especificar solicitações ou limites para cada contêiner nesse namespace.

Considere configurar cotas para cada namespace. Considere usar LimitRanges para aplicar automaticamente limites pré-configurados aos contêineres em um namespace.

Limitar o uso de recursos do contêiner em um namespace

As cotas de recursos ajudam a limitar a quantidade de recursos que um namespace pode usar. O LimitRangeobjeto pode ajudá-lo a implementar os recursos mínimos e máximos que um contêiner pode solicitar. Usando LimitRange você pode definir uma solicitação e limites padrão para contêineres, o que é útil se definir limites de recursos computacionais não for uma prática padrão em sua organização. Como o nome sugere, LimitRange pode impor o uso mínimo e máximo de recursos computacionais por pod ou contêiner em um namespace. Além disso, imponha a solicitação mínima e máxima de armazenamento PersistentVolumeClaim em um namespace.

Considere usar LimitRange em conjunto com ResourceQuota para impor limites em um nível de contêiner e namespace. Definir esses limites garantirá que um contêiner ou namespace não interfira nos recursos usados por outros locatários no cluster.

Use NodeLocal DNSCache

Você pode melhorar o desempenho do Cluster DNS executando NodeLocalDNSCache. Esse recurso executa um agente de cache de DNS nos nós do cluster como um. DaemonSet Todos os pods usam o agente de cache DNS em execução no nó para resolução de nomes em vez de usar o Service. kube-dns Esse recurso é incluído automaticamente no EKS Auto Mode.

Configurar o CoreDNS de escalonamento automático

Outro método para melhorar o desempenho do Cluster DNS é habilitar o auto-scaling integrado dos pods CoreDNS.

Esse recurso monitora continuamente o estado do cluster, incluindo o número de nós e núcleos de CPU. Com base nessas informações, o controlador adaptará dinamicamente o número de réplicas da implantação do CoreDNS em um cluster EKS.