As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# 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 do EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), [instâncias EC2](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) e [Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html).
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 instâncias EC2, poderá gerenciar os nós de trabalho sozinho ou usar [grupos de nós gerenciados pelo EKS](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html). 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](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html).
[A forma preferida de escalar os nós de trabalho do EC2 (se não estiver usando o EKS Auto Mode, onde isso é executado automaticamente pela AWS) é usando os grupos [Karpenter](https://karpenter.sh/), [Kubernetes Cluster Autoscaler ou EC2 Auto Scaling](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)
## 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](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#spread-constraints-for-pods) 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-scheduler`só 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**
`whenUnsatisfiable`Definir 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](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) 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](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) 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 [NodePool](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption)interrupção definidas e os orçamentos de interrupção do pod.
### Execute o Node Monitoring Agent
O [Node Monitoring Agent](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html) 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run). 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. Se`requests`\$1 [=`limits`, o contêiner também tem sua [QOS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes) reduzida de Garantida para Estável, aumentando a probabilidade de ser despejado em caso de pressão no nó.](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+ 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 a`requests`, 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](https://aws.github.io/aws-eks-best-practices/karpenter/) Karpenter ou Cluster. AutoScaler](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/) 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](https://github.com/kubernetes/autoscaler/tree/master/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](https://github.com/FairwindsOps/goldilocks)
+ [Parca](https://www.parca.dev/)
+ [Perfis](https://prodfiler.com/)
+ [rsg](https://mhausenblas.info/right-size-guide/)
### 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 [https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/)objeto 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 [`LimitRange`objeto](https://kubernetes.io/docs/concepts/policy/limit-range/) 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](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/). 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](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html).
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 do EKS.