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á. # Melhores práticas de confiabilidade Esta seção fornece orientação sobre como tornar as cargas de trabalho em execução no EKS resilientes e altamente disponíveis ## Como usar este guia Este guia é destinado a desenvolvedores e arquitetos que desejam desenvolver e operar serviços altamente disponíveis e tolerantes a falhas no EKS. O guia está organizado em diferentes áreas temáticas para facilitar o consumo. Cada tópico começa com uma breve visão geral, seguida por uma lista de recomendações e melhores práticas para a confiabilidade de seus clusters EKS. ## Introdução As melhores práticas de confiabilidade para o EKS foram agrupadas nos seguintes tópicos: + Aplicativos + Plano de controle + Plano de dados O que torna um sistema confiável? Se um sistema pode funcionar de forma consistente e atender às demandas apesar das mudanças em seu ambiente durante um período de tempo, ele pode ser chamado de confiável. Para conseguir isso, o sistema precisa detectar falhas, se curar automaticamente e ter a capacidade de escalar com base na demanda. Os clientes podem usar o Kubernetes como base para operar aplicativos e serviços essenciais de forma confiável. Mas, além de incorporar princípios de design de aplicativos baseados em contêineres, executar cargas de trabalho de forma confiável também requer uma infraestrutura confiável. No Kubernetes, a infraestrutura compreende o plano de controle e o plano de dados. O EKS fornece um plano de controle Kubernetes de nível de produção projetado para ser altamente disponível e tolerante a falhas. No EKS, a AWS é responsável pela confiabilidade do plano de controle do Kubernetes. O EKS executa o plano de controle do Kubernetes em três zonas de disponibilidade em uma região da AWS. Ele gerencia automaticamente a disponibilidade e a escalabilidade dos servidores da API Kubernetes e do cluster etcd. A responsabilidade pela confiabilidade do plano de dados é compartilhada entre você, o cliente e a AWS. O EKS oferece quatro opções de nós de trabalho para implantar o plano de dados do Kubernetes. O [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), que é a opção mais gerenciada, lida com o provisionamento, o dimensionamento e as atualizações do plano de dados, além de fornecer recursos gerenciados de computação, rede e armazenamento. O Modo Automático AMIs é lançado com frequência e os clusters são atualizados automaticamente para a AMI mais recente para implantar correções de CVE e patches de segurança. Você pode controlar quando isso ocorre configurando os [controles de interrupção no Modo](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption) Automático. NodePools O Fargate gerencia o provisionamento e a escalabilidade do plano de dados executando um pod por nó. A terceira opção, grupos de nós gerenciados, gerencia o provisionamento e as atualizações do plano de dados. E, finalmente, os nós autogerenciados são a opção menos gerenciada para o plano de dados. Quanto mais plano de dados gerenciado pela AWS você usa, menos responsabilidade você tem. [Os grupos de nós gerenciados](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) automatizam o provisionamento e o gerenciamento do ciclo de vida dos nós do EC2. Você pode usar a API EKS (usando o console EKS, a API da AWS, a CLI da AWSCloudFormation, o Terraform ou`eksctl`) para criar, escalar e atualizar nós gerenciados. Os nós gerenciados executam instâncias Amazon Linux 2 EC2 otimizadas para EKS em sua conta, e você pode instalar pacotes de software personalizados ativando o acesso SSH. Quando você provisiona nós gerenciados, eles são executados como parte de um grupo de Auto Scaling gerenciado pelo EKS que pode abranger várias zonas de disponibilidade; você controla isso por meio das sub-redes fornecidas ao criar nós gerenciados. O EKS também marca automaticamente os nós gerenciados para que eles possam ser usados com o escalador automático de cluster. O Amazon EKS segue o modelo de responsabilidade compartilhada CVEs e os patches de segurança em grupos de nós gerenciados. Como os nós gerenciados executam o Amazon EKS otimizado, o AMIs Amazon EKS é responsável por criar versões corrigidas deles AMIs quando há correções de bugs. No entanto, você é responsável por implantar essas versões de AMI com patches nos seus grupos de nós gerenciados. O EKS também [gerencia a atualização dos nós](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html), embora você precise iniciar o processo de atualização. O processo de [atualização do nó gerenciado](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) é explicado na documentação do EKS. Se você executa nós autogerenciados, pode usar a [AMI Linux otimizada para Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) para criar nós de trabalho. Você é responsável por aplicar patches e atualizar a AMI e os nós. É uma prática recomendada usar `eksctl` nossa infraestrutura como ferramentas de código para provisionar nós autogerenciados, pois isso facilitará a [atualização de nós autogerenciados](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html). CloudFormation Considere [migrar para novos nós](https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html) ao atualizar os nós de trabalho, pois o processo de migração **contamina** o grupo de nós antigo `NoSchedule` e **drena** os nós depois que uma nova pilha está pronta para aceitar a carga de trabalho existente do pod. No entanto, você também pode realizar uma [atualização local dos nós autogerenciados](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html). **Modelo de responsabilidade compartilhada - Fargate** ![\[Modelo de responsabilidade compartilhada - Fargate\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/reliability/SRM-Fargate.jpeg) **Modelo de Responsabilidade Compartilhada - MNG** ![\[Modelo de Responsabilidade Compartilhada - MNG\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/reliability/SRM-MNG.jpeg) Este guia inclui um conjunto de recomendações que você pode usar para melhorar a confiabilidade do seu plano de dados EKS, dos componentes principais do Kubernetes e dos seus aplicativos. ## Feedback Este guia está sendo lançado GitHub para coletar feedback direto e sugestões da EKS/Kubernetes comunidade em geral. Se você tem uma prática recomendada que acha que devemos incluir no guia, registre um problema ou envie um PR no GitHub repositório. Pretendemos atualizar o guia periodicamente à medida que novos recursos são adicionados ao serviço ou quando uma nova prática recomendada evolui. # Executando aplicativos de alta disponibilidade Seus clientes esperam que seu aplicativo esteja sempre disponível, inclusive quando você está fazendo alterações e especialmente durante picos de tráfego. Uma arquitetura escalável e resiliente mantém seus aplicativos e serviços funcionando sem interrupções, o que mantém seus usuários satisfeitos. Uma infraestrutura escalável cresce e diminui com base nas necessidades da empresa. Eliminar pontos únicos de falha é uma etapa fundamental para melhorar a disponibilidade de um aplicativo e torná-lo resiliente. Com o Kubernetes, você pode operar seus aplicativos e executá-los de forma altamente disponível e resiliente. Seu gerenciamento declarativo garante que, depois de configurar o aplicativo, o Kubernetes tente continuamente [combinar o estado atual com o estado desejado](https://kubernetes.io/docs/concepts/architecture/controller/#desired-vs-current). ## Recomendações ### Configurar orçamentos de interrupção do pod Os [orçamentos de interrupção do pod](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) são usados para limitar a quantidade de interrupções simultâneas que um aplicativo experimentará. Eles devem ser configurados para cargas de trabalho se for importante sempre ter uma parte dessa carga de trabalho disponível. O EKS Auto Mode, o Karpenter e o Cluster Autoscaler conhecem e cumprem os orçamentos configurados de interrupção do pod ao reduzir a escala. O EKS Auto Mode, o Karpenter e os grupos de nós gerenciados também aderem aos orçamentos de interrupção do Pod ao atualizar os nós ### Evite executar pods singleton Se todo o seu aplicativo for executado em um único pod, ele ficará indisponível se esse pod for encerrado. [Em vez de implantar aplicativos usando pods individuais, crie implantações.](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) Se um pod criado por uma implantação falhar ou for encerrado, o [controlador](https://kubernetes.io/docs/concepts/architecture/controller/) de implantação iniciará um novo pod para garantir que o número especificado de pods de réplica esteja sempre em execução. ### Execute várias réplicas A execução de várias réplicas de pods de um aplicativo usando uma implantação ajuda a executá-lo de maneira altamente disponível. Se uma réplica falhar, as réplicas restantes continuarão funcionando, embora com capacidade reduzida, até que o Kubernetes crie outro pod para compensar a perda. Além disso, você pode usar o escalonador [automático do Horizontal Pod para escalar réplicas](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) automaticamente com base na demanda da carga de trabalho. ### Programe réplicas em todos os nós A execução de várias réplicas não será muito útil se todas estiverem em execução no mesmo nó e o nó ficar indisponível. Considere usar a antiafinidade do pod ou as restrições de dispersão da topologia do pod para distribuir réplicas de uma implantação em vários nós de trabalho. Você pode melhorar ainda mais a confiabilidade de um aplicativo típico executando-o em vários AZs. #### Usando as regras de antiafinidade do Pod O manifesto abaixo diz ao programador do Kubernetes que *prefira* colocar pods em nós separados e. AZs Ele não requer nós ou AZ distintos porque, se exigisse, o Kubernetes não conseguiria programar nenhum pod quando houver um pod em execução em cada AZ. Se seu aplicativo exigir apenas três réplicas, você poderá usar `requiredDuringSchedulingIgnoredDuringExecution` for`topologyKey: topology.kubernetes.io/zone`, e o programador do Kubernetes não agendará dois pods na mesma AZ. ``` apiVersion: apps/v1 kind: Deployment metadata: name: spread-host-az 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: topology.kubernetes.io/zone weight: 100 - podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - web-server topologyKey: kubernetes.io/hostname weight: 99 containers: - name: web-app image: nginx:1.16-alpine ``` #### Usando restrições de dispersão da topologia do Pod Semelhantes às regras de antiafinidade do pod, as restrições de dispersão da topologia do pod permitem que você disponibilize seu aplicativo em diferentes domínios de falha (ou topologia), como hosts ou. AZs Essa abordagem funciona muito bem quando você está tentando garantir a tolerância a falhas e a disponibilidade por meio de várias réplicas em cada um dos diferentes domínios de topologia. As regras de antiafinidade de pods, por outro lado, podem facilmente produzir um resultado quando você tem uma única réplica em um domínio de topologia, pois os pods com antiafinidade entre si têm um efeito repelente. Nesses casos, uma única réplica em um nó dedicado não é ideal para tolerância a falhas nem é um bom uso dos recursos. Com as restrições de distribuição de topologia, você tem mais controle sobre a distribuição ou distribuição que o programador deve tentar aplicar nos domínios de topologia. Aqui estão algumas propriedades importantes a serem usadas nessa abordagem: 1. O `maxSkew` é usado para controlar ou determinar o ponto máximo em que as coisas podem ser desiguais nos domínios da topologia. Por exemplo, se um aplicativo tiver 10 réplicas e for implantado em 3 AZs, você não poderá obter uma distribuição uniforme, mas poderá influenciar o quão desigual será a distribuição. Nesse caso, `maxSkew` pode ser qualquer coisa entre 1 e 10. Um valor de 1 significa que você pode potencialmente acabar com um spread como `4,3,3` `3,4,3` ou `3,3,4` entre 3 AZs. Em contraste, um valor de 10 significa que você pode potencialmente acabar com um spread como`10,0,0`, `0,10,0` ou `0,0,10` entre 3 AZs. 1. `topologyKey`É uma chave para um dos rótulos dos nós e define o tipo de domínio de topologia que deve ser usado para a distribuição do pod. Por exemplo, um spread zonal teria o seguinte par de valores-chave: ``` topologyKey: "topology.kubernetes.io/zone" ``` 1. A `whenUnsatisfiable` propriedade é usada para determinar como você deseja que o agendador responda se as restrições desejadas não puderem ser satisfeitas. 1. O `labelSelector` é usado para encontrar pods correspondentes para que o programador possa estar ciente deles ao decidir onde colocar os pods de acordo com as restrições que você especificar. Além dos campos acima, há outros campos sobre os quais você pode ler mais na documentação do [Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). **A topologia do pod distribui as restrições em 3 AZs** ![\[Pod topology spread constraints across 3 AZs\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/reliability/pod-topology-spread-constraints.jpg) ``` apiVersion: apps/v1 kind: Deployment metadata: name: spread-host-az labels: app: web-server spec: replicas: 10 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: express-test containers: - name: web-app image: nginx:1.16-alpine ``` ### Execute o Kubernetes Metrics Server Instale o [servidor de métricas](https://github.com/kubernetes-sigs/metrics-server) do Kubernetes para ajudar a escalar seus aplicativos. Os complementos do autoescalador do Kubernetes, como [HPA e [VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), precisam rastrear as métricas dos aplicativos para escalá-los. O servidor de métricas coleta métricas de recursos que podem ser usadas para tomar decisões de escalabilidade. As métricas são coletadas dos kubelets e veiculadas no formato da [API Metrics](https://github.com/kubernetes/metrics). O servidor de métricas não retém nenhum dado e não é uma solução de monitoramento. Seu objetivo é expor as métricas de uso da CPU e da memória a outros sistemas. Se você quiser acompanhar o estado do seu aplicativo ao longo do tempo, precisará de uma ferramenta de monitoramento como o Prometheus ou o Amazon. CloudWatch Siga a [documentação do EKS](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html) para instalar o metrics-server em seu cluster EKS. ## Autoescalador horizontal de cápsulas (HPA) A HPA pode escalar automaticamente seu aplicativo em resposta à demanda e ajudá-lo a evitar o impacto de seus clientes durante o pico de tráfego. Ele é implementado como um loop de controle no Kubernetes que consulta periodicamente métricas APIs que fornecem métricas de recursos. O HPA pode recuperar métricas do seguinte APIs: 1. `metrics.k8s.io`também conhecida como Resource Metrics API — fornece uso de CPU e memória para pods 2. `custom.metrics.k8s.io` — Fornece métricas de outros coletores de métricas, como o Prometheus; essas métricas **são** internas ao seu cluster Kubernetes. 3. `external.metrics.k8s.io` — Fornece métricas **externas** ao seu cluster Kubernetes (por exemplo, profundidade de fila do SQS, latência do ELB). Você deve usar um desses três APIs para fornecer a métrica para escalar seu aplicativo. ### Dimensionamento de aplicativos com base em métricas personalizadas ou externas Você pode usar métricas personalizadas ou externas para escalar seu aplicativo em métricas diferentes da utilização da CPU ou da memória. Os servidores da API [Custom Metrics](https://github.com/kubernetes-sigs/custom-metrics-apiserver) fornecem a `custom-metrics.k8s.io` API que a HPA pode usar para escalar aplicativos automaticamente. Você pode usar o [adaptador Prometheus para métricas do Kubernetes para coletar métricas](https://github.com/directxman12/k8s-prometheus-adapter) do Prometheus e usá-las APIs com o HPA. [Nesse caso, o adaptador Prometheus exporá as métricas do Prometheus no formato da API Metrics.](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/types.go) Depois de implantar o adaptador Prometheus, você pode consultar métricas personalizadas usando kubectl. `kubectl get —raw /apis/custom.metrics.k8s.io/v1beta1/` As métricas externas, como o nome sugere, fornecem ao Horizontal Pod Autoscaler a capacidade de escalar implantações usando métricas externas ao cluster Kubernetes. Por exemplo, em cargas de trabalho de processamento em lote, é comum escalar o número de réplicas com base no número de trabalhos em andamento em uma fila do SQS. Para escalonar automaticamente as cargas de trabalho do Kubernetes, você pode usar o KEDA (Kubernetes Event-driven Autoscaling), um projeto de código aberto que pode impulsionar o escalonamento de contêineres com base em vários eventos personalizados. Este [blog da AWS](https://aws.amazon.com/blogs/mt/autoscaling-kubernetes-workloads-with-keda-using-amazon-managed-service-for-prometheus-metrics/) descreve como usar o Amazon Managed Service for Prometheus para o auto-scaling da carga de trabalho do Kubernetes. ## Autoescalador vertical de pods (VPA) O VPA ajusta automaticamente a reserva de CPU e memória dos seus pods para ajudá-lo a “dimensionar corretamente” seus aplicativos. Para aplicativos que precisam ser escalados verticalmente, o que é feito aumentando a alocação de recursos, você pode usar o [VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) para escalar automaticamente as réplicas do pod ou fornecer recomendações de escalabilidade. Seu aplicativo pode ficar temporariamente indisponível se o VPA precisar escalá-lo, pois a implementação atual do VPA não realiza ajustes locais nos pods; em vez disso, ele recriará o pod que precisa ser escalado. A [documentação do EKS](https://docs.aws.amazon.com/eks/latest/userguide/vertical-pod-autoscaler.html) inclui um passo a passo para configurar o VPA. O projeto [Fairwinds Goldilocks](https://github.com/FairwindsOps/goldilocks/) fornece um painel para visualizar as recomendações do VPA para solicitações e limites de CPU e memória. Seu modo de atualização do VPA permite que você escale automaticamente os pods com base nas recomendações do VPA. ## Atualizar aplicativos As aplicações modernas exigem inovação rápida com alto grau de estabilidade e disponibilidade. O Kubernetes oferece as ferramentas para atualizar seus aplicativos continuamente sem interromper seus clientes. Vejamos algumas das melhores práticas que possibilitam a rápida implantação de mudanças sem sacrificar a disponibilidade. ### Tenha um mecanismo para realizar reversões Ter um botão de desfazer pode evitar desastres. É uma prática recomendada testar as implantações em um ambiente inferior separado (ambiente de teste ou desenvolvimento) antes de atualizar o cluster de produção. Usar um pipeline de CI/CD pode ajudá-lo a automatizar e testar implantações. Com um pipeline de implantação contínua, você pode reverter rapidamente para a versão mais antiga se a atualização estiver com defeito. Você pode usar Deployments para atualizar um aplicativo em execução. Isso geralmente é feito atualizando a imagem do contêiner. Você pode usar `kubectl` para atualizar uma implantação como esta: ``` kubectl --record deployment.apps/nginx-deployment set image nginx-deployment nginx=nginx:1.16.1 ``` O `--record` argumento registra as alterações na implantação e ajuda você se você precisar realizar uma reversão. `kubectl rollout history deployment`mostra as alterações registradas nas implantações em seu cluster. Você pode reverter uma alteração usando. `kubectl rollout undo deployment ` Por padrão, quando você atualiza uma implantação que exige a recriação de pods, a implantação realiza uma atualização [contínua](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). Em outras palavras, o Kubernetes atualizará apenas uma parte dos pods em execução em uma implantação e não todos os pods de uma vez. Você pode controlar como o Kubernetes realiza atualizações contínuas por meio da propriedade. `RollingUpdateStrategy` Ao realizar uma *atualização contínua* de uma implantação, você pode usar a [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable)propriedade para especificar o número máximo de pods que podem ficar indisponíveis durante a atualização. A `Max Surge` propriedade de Deployment permite que você defina o número máximo de pods que podem ser criados acima do número desejado de pods. Considere `max unavailable` fazer ajustes para garantir que um lançamento não atrapalhe seus clientes. Por exemplo, o Kubernetes define 25% `max unavailable` por padrão, o que significa que, se você tiver 100 pods, poderá ter apenas 75 pods trabalhando ativamente durante uma implantação. Se seu aplicativo precisar de um mínimo de 80 pods, esse lançamento pode causar interrupções. Em vez disso, você pode definir 20% `max unavailable` para garantir que haja pelo menos 80 pods funcionais durante o lançamento. ### Use blue/green implantações As mudanças são inerentemente arriscadas, mas mudanças que não podem ser desfeitas podem ser potencialmente catastróficas. Os procedimentos de alteração que permitem que você efetivamente volte no tempo por meio de uma *reversão* tornam os aprimoramentos e a experimentação mais seguros. Blue/green as implantações oferecem um método para retrair rapidamente as alterações se as coisas derem errado. Nessa estratégia de implantação, você cria um ambiente para a nova versão. Esse ambiente é idêntico à versão atual do aplicativo que está sendo atualizado. Depois que o novo ambiente é provisionado, o tráfego é roteado para o novo ambiente. Se a nova versão produzir os resultados desejados sem gerar erros, o ambiente antigo será encerrado. Caso contrário, o tráfego será restaurado para a versão antiga. Você pode realizar blue/green implantações no Kubernetes criando uma nova implantação idêntica à implantação da versão existente. Depois de verificar se os pods na nova implantação estão sendo executados sem erros, você pode começar a enviar tráfego para a nova implantação alterando a `selector` especificação no serviço que direciona o tráfego para os pods do seu aplicativo. Muitas ferramentas de integração contínua, como [Flux](https://fluxcd.io), [Jenkins](https://www.jenkins.io) e [Spinnaker](https://spinnaker.io), permitem automatizar implantações. blue/green O blog de contêineres da AWS inclui um passo a passo usando o AWS Load Balancer Controller: [Usando o AWS Load Balancer Controller blue/green para](https://aws.amazon.com/blogs/containers/using-aws-load-balancer-controller-for-blue-green-deployment-canary-deployment-and-a-b-testing/) implantação, implantação canária e teste A/B ### Use implantações do Canary As implantações do Canary são uma variante das blue/green implantações que podem remover significativamente os riscos das mudanças. Nessa estratégia de implantação, você cria uma nova implantação com menos pods junto com a implantação antiga e desvia uma pequena porcentagem do tráfego para a nova implantação. Se as métricas indicarem que a nova versão está funcionando tão bem ou melhor do que a versão existente, você aumenta progressivamente o tráfego para a nova implantação enquanto o expande até que todo o tráfego seja desviado para a nova implantação. Se houver algum problema, você pode rotear todo o tráfego para a implantação antiga e parar de enviar tráfego para a nova implantação. [https://github.com/weaveworks/flagger](https://github.com/weaveworks/flagger) ## Exames de saúde e autocura Nenhum software está livre de bugs, mas o Kubernetes pode ajudar você a minimizar o impacto das falhas de software. No passado, se um aplicativo falhasse, alguém precisava remediar a situação reiniciando o aplicativo manualmente. O Kubernetes permite detectar falhas de software em seus pods e substituí-las automaticamente por novas réplicas. Com o Kubernetes, você pode monitorar a integridade de seus aplicativos e substituir automaticamente as instâncias não íntegras. [O Kubernetes oferece suporte a três tipos de verificações de integridade:](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 1. Sonda de vivacidade 1. Sonda de inicialização (compatível com o Kubernetes versão 1.16\$1) 1. Sonda de prontidão O [Kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), o agente do Kubernetes, é responsável por executar todas as verificações mencionadas acima. O Kubelet pode verificar a integridade de um Pods de três maneiras: o kubelet pode executar um comando shell dentro do contêiner de um Pod, enviar uma solicitação HTTP GET para o contêiner ou abrir um soquete TCP em uma porta especificada. Se você escolher um teste `exec` baseado, que executa um script de shell dentro de um contêiner, certifique-se de que o comando shell saia *antes* que o `timeoutSeconds` valor expire. Caso contrário, seu nó terá `` processos, levando à falha do nó. ## Recomendações ### Use o Liveness Probe para remover frutos não saudáveis A sonda Liveness pode detectar condições de *impasse* em que o processo continua em execução, mas o aplicativo deixa de responder. Por exemplo, se você estiver executando um serviço web que escuta na porta 80, você pode configurar uma sonda Liveness para enviar uma solicitação HTTP GET na porta 80 do Pod. O Kubelet enviará periodicamente uma solicitação GET ao pod e esperará uma resposta; se o pod responder entre 200 e 399, o kubelet considerará que o pod está íntegro; caso contrário, o pod será marcado como não íntegro. Se um pod falhar continuamente nas verificações de integridade, o kubelet o encerrará. Você pode usar `initialDelaySeconds` para atrasar a primeira sonda. Ao usar o Liveness Probe, certifique-se de que seu aplicativo não se depare com uma situação em que todos os pods falhem simultaneamente no Liveness Probe, pois o Kubernetes tentará substituir todos os seus pods, o que deixará seu aplicativo offline. Além disso, o Kubernetes continuará criando novos pods que também falharão no Liveness Probes, sobrecarregando desnecessariamente o plano de controle. Evite configurar o Liveness Probe para depender de um fator externo ao seu pod, por exemplo, um banco de dados externo. Em outras palavras, um external-to-your-Pod banco de dados não responsivo não deve fazer com que seus pods falhem em suas sondas de vida. O post [LIVENESS PROBES ARE DANGEROUS](https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html), de Sandor Szücs, descreve problemas que podem ser causados por sondas mal configuradas. ### Use o Startup Probe para aplicativos que demoram mais para iniciar Quando seu aplicativo precisar de mais tempo para inicializar, você pode usar o Startup Probe para atrasar o Liveness and Readiness Probe. Por exemplo, um aplicativo Java que precisa hidratar o cache de um banco de dados pode precisar de até dois minutos antes de estar totalmente funcional. Qualquer sonda de vivacidade ou prontidão até que se torne totalmente funcional pode falhar. A configuração de um Startup Probe permitirá que o aplicativo Java fique *saudável* antes que o Liveness ou o Readiness Probe sejam executados. Até que a sonda de inicialização seja bem-sucedida, todas as outras sondas serão desativadas. Você pode definir o tempo máximo que o Kubernetes deve esperar pela inicialização do aplicativo. Se, após o tempo máximo configurado, o pod ainda falhar no Startup Probes, ele será encerrado e um novo pod será criado. O Startup Probe é semelhante ao Liveness Probe — se eles falharem, o Pod será recriado. Como Ricardo A. explica em seu post [Fantastic Probes And How To Configure Them](https://medium.com/swlh/fantastic-probes-and-how-to-configure-them-fef7e030bd2f), Startup Probes deve ser usado quando o tempo de inicialização de um aplicativo é imprevisível. Se você sabe que seu aplicativo precisa de dez segundos para iniciar, use o Liveness/Readiness Probe em vez disso. `initialDelaySeconds` ### Use o Readiness Probe para detectar indisponibilidade parcial *Enquanto a sonda Liveness detecta falhas em um aplicativo que são resolvidas ao encerrar o pod (portanto, reiniciando o aplicativo), o Readiness Probe detecta condições em que o aplicativo pode estar temporariamente indisponível.* Nessas situações, o aplicativo pode ficar temporariamente sem resposta; no entanto, espera-se que ele volte a funcionar quando a operação for concluída. Por exemplo, durante I/O operações intensas de disco, os aplicativos podem ficar temporariamente indisponíveis para lidar com solicitações. Aqui, encerrar o pod do aplicativo não é uma solução; ao mesmo tempo, solicitações adicionais enviadas ao pod podem falhar. Você pode usar o Readiness Probe para detectar a indisponibilidade temporária em seu aplicativo e parar de enviar solicitações ao pod até que ele volte a funcionar. *Ao contrário do Liveness Probe, em que uma falha resultaria na recriação do Pod, um Readiness Probe com falha significaria que o Pod não receberia nenhum* tráfego do Kubernetes Service. Quando o Readiness Probe for bem-sucedido, o Pod retomará o recebimento do tráfego do Service. Assim como o Liveness Probe, evite configurar sondas de prontidão que dependam de um recurso externo ao pod (como um banco de dados). Aqui está um cenário em que uma prontidão mal configurada pode tornar o aplicativo não funcional: se o teste de prontidão do pod falhar quando o banco de dados do aplicativo estiver inacessível, outras réplicas do pod também falharão simultaneamente, pois compartilham os mesmos critérios de verificação de integridade. *Configurar o teste dessa forma garantirá que, sempre que o banco de dados estiver indisponível, os testes de prontidão do pod falhem e o Kubernetes pare de enviar tráfego para todos os pods.* Um efeito colateral do uso de sondas de prontidão é que elas podem aumentar o tempo necessário para atualizar as implantações. As novas réplicas não receberão tráfego, a menos que as sondas de prontidão sejam bem-sucedidas; até lá, as réplicas antigas continuarão recebendo tráfego. ## Lidando com interrupções Os pods têm uma vida útil finita. Mesmo se você tiver pods de longa duração, é prudente garantir que os pods terminem corretamente quando chegar a hora. Dependendo da sua estratégia de upgrade, os upgrades de cluster do Kubernetes podem exigir a criação de novos nós de trabalho, o que exige que todos os pods sejam recriados em nós mais novos. O tratamento adequado da rescisão e os orçamentos de interrupção do pod podem ajudar você a evitar interrupções no serviço, pois os pods são removidos dos nós mais antigos e recriados nos nós mais novos. A forma preferida de atualizar os nós de trabalho é criando novos nós de trabalho e encerrando os antigos. Antes de encerrar os nós de trabalho, você deve fazer `drain` isso. Quando um nódulo de trabalho é drenado, todos os seus frutos são despejados *com segurança*. Segurança é uma palavra-chave aqui; quando as cápsulas de um trabalhador são despejadas, elas não recebem simplesmente um sinal. `SIGKILL` Em vez disso, um `SIGTERM` sinal é enviado para o processo principal (PID 1) de cada contêiner nos pods que estão sendo despejados. Depois que o `SIGTERM` sinal for enviado, o Kubernetes dará ao processo algum tempo (período de carência) antes que o `SIGKILL` sinal seja enviado. Esse período de carência é de 30 segundos por padrão; você pode substituir o padrão usando `grace-period` flag em kubectl ou declare `terminationGracePeriodSeconds` em seu Podspec. `kubectl delete pod —grace-period=` É comum ter contêineres nos quais o processo principal não tenha PID 1. Considere este contêiner de amostra baseado em Python: ``` $ kubectl exec python-app -it ps PID USER TIME COMMAND 1 root 0:00 {script.sh} /bin/sh ./script.sh 5 root 0:00 python app.py ``` Neste exemplo, o script de shell recebe`SIGTERM`, o processo principal, que por acaso é um aplicativo Python neste exemplo, não recebe um `SIGTERM` sinal. Quando o Pod for encerrado, o aplicativo Python será encerrado abruptamente. Isso pode ser corrigido alterando o [https://docs.docker.com/engine/reference/builder/#entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)contêiner para iniciar o aplicativo Python. Como alternativa, você pode usar uma ferramenta como o [dumb-init](https://github.com/Yelp/dumb-init) para garantir que seu aplicativo possa lidar com sinais. Você também pode usar [ganchos de contêiner](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) para executar um script ou uma solicitação HTTP no início ou na parada do contêiner. A ação do `PreStop` gancho é executada antes que o contêiner receba um `SIGTERM` sinal e deve ser concluída antes que esse sinal seja enviado. O `terminationGracePeriodSeconds` valor se aplica a partir do momento em que a ação do `PreStop` gancho começa a ser executada, não quando o `SIGTERM` sinal é enviado. ## Recomendações ### Proteja a carga de trabalho crítica com o Pod Disruption Budgets O Pod Disruption Budget ou o PDB podem interromper temporariamente o processo de despejo se o número de réplicas de um aplicativo ficar abaixo do limite declarado. O processo de despejo continuará quando o número de réplicas disponíveis ultrapassar o limite. Você pode usar o PDB para declarar o `maxUnavailable` número `minAvailable` e o número de réplicas. Por exemplo, se você quiser que pelo menos três cópias do seu aplicativo estejam disponíveis, você pode criar um PDB. ``` apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: name: my-svc-pdb spec: minAvailable: 3 selector: matchLabels: app: my-svc ``` A política de PDB acima diz ao Kubernetes que interrompa o processo de despejo até que três ou mais réplicas estejam disponíveis. `PodDisruptionBudgets`Respeita a drenagem do nódulo. Durante uma atualização do grupo de nós gerenciados pelo EKS, [os nós são drenados com um tempo limite de quinze minutos](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html). Depois de quinze minutos, se a atualização não for forçada (a opção se chama Atualização contínua no console EKS), a atualização falhará. Se a atualização for forçada, os pods serão excluídos. [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html) Ele usa a API Kubernetes para isolar o nó para garantir que nenhum novo pods seja programado e, em seguida, o drena, encerrando todos os pods em execução. Você pode usar a anti-afinidade do Pod para programar os pods de uma implantação em nós diferentes e evitar atrasos relacionados ao PDB durante as atualizações dos nós. ### Pratique engenharia do caos A Engenharia do Caos é a disciplina de fazer experiências em um sistema distribuído para criar confiança na capacidade do sistema de suportar condições turbulentas na produção. Em seu blog, Dominik Tornow explica que o [Kubernetes é um sistema declarativo](https://medium.com/@dominik.tornow/the-mechanics-of-kubernetes-ac8112eaa302) em que "*o usuário fornece uma representação do estado desejado do sistema ao sistema. O sistema então considera o estado atual e o estado desejado para determinar a sequência de comandos para fazer a transição do estado atual para o estado desejado.* “ Isso significa que o Kubernetes sempre armazena o *estado desejado* e, se o sistema se desviar, o Kubernetes tomará medidas para restaurar o estado. Por exemplo, se um nó de trabalho ficar indisponível, o Kubernetes reprogramará os pods em outro nó de trabalho. Da mesma forma, se um `replica` travar, o [Deployment Controller](https://kubernetes.io/docs/concepts/architecture/controller/#design) criará um novo. `replica` Dessa forma, os controladores do Kubernetes corrigem automaticamente as falhas. Ferramentas de engenharia de caos, como o [Gremlin](https://www.gremlin.com), ajudam você a testar a resiliência do seu cluster Kubernetes e a identificar pontos únicos de falha. Ferramentas que introduzem o caos artificial em seu cluster (e além) podem revelar pontos fracos sistêmicos, apresentar uma oportunidade de identificar gargalos e configurações incorretas e corrigir problemas em um ambiente controlado. A filosofia da Chaos Engineering defende quebrar as coisas propositalmente e testar a infraestrutura de estresse para minimizar o tempo de inatividade imprevisto. ### Use um Service Mesh Você pode usar uma malha de serviços para melhorar a resiliência do seu aplicativo. As malhas de serviços permitem a service-to-service comunicação e aumentam a observabilidade da sua rede de microsserviços. A maioria dos produtos de service mesh funciona com um pequeno proxy de rede executado ao lado de cada serviço que intercepta e inspeciona o tráfego de rede do aplicativo. Você pode colocar seu aplicativo em uma malha sem modificá-lo. Usando os recursos integrados do proxy de serviço, você pode fazer com que ele gere estatísticas de rede, crie registros de acesso e adicione cabeçalhos HTTP às solicitações de saída para rastreamento distribuído. Uma malha de serviços pode ajudar você a tornar seus microsserviços mais resilientes com recursos como novas tentativas automáticas de solicitações, tempos limite, interrupção de circuitos e limitação de taxa. Se você opera vários clusters, pode usar uma malha de serviços para permitir a service-to-service comunicação entre clusters. ### Malhas de serviço + [Istio](https://istio.io) + [ID vinculado](http://linkerd.io) + [Cônsul](https://www.consul.io) ## Observabilidade Observabilidade é um termo abrangente que inclui monitoramento, registro e rastreamento. Os aplicativos baseados em microsserviços são distribuídos por natureza. Ao contrário dos aplicativos monolíticos em que monitorar um único sistema é suficiente, em uma arquitetura de aplicativos distribuídos, você precisa monitorar o desempenho de cada componente. Você pode usar sistemas de monitoramento, registro e rastreamento distribuído em nível de cluster para identificar problemas em seu cluster antes que eles interrompam seus clientes. As ferramentas integradas do Kubernetes para solução de problemas e monitoramento são limitadas. O servidor de métricas coleta métricas de recursos e as armazena na memória, mas não as persiste. Você pode ver os registros de um pod usando kubectl, mas o Kubernetes não retém automaticamente os registros. E a implementação do rastreamento distribuído é feita no nível do código do aplicativo ou usando malhas de serviços. A extensibilidade do Kubernetes brilha aqui. O Kubernetes permite que você traga sua solução centralizada preferida de monitoramento, registro e rastreamento. ## Recomendações ### Monitore seus aplicativos O número de métricas que você precisa monitorar em aplicativos modernos está crescendo continuamente. Ajuda se você tiver uma forma automatizada de rastrear seus aplicativos para que possa se concentrar na solução dos desafios de seus clientes. Ferramentas de monitoramento em todo o cluster, como [Prometheus](https://prometheus.io) ou [CloudWatchContainer Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html), podem monitorar seu cluster e sua carga de trabalho e fornecer sinais quando, ou de preferência, antes que as coisas dêem errado. As ferramentas de monitoramento permitem que você crie alertas que sua equipe de operações pode assinar. Considere regras para ativar alarmes para eventos que podem, quando exacerbados, levar a uma interrupção ou afetar o desempenho do aplicativo. Se você não tiver certeza de quais métricas deve monitorar, pode se inspirar nesses métodos: + [Método RED](https://www.weave.works/blog/a-practical-guide-from-instrumenting-code-to-specifying-alerts-with-the-red-method). Significa solicitações, erros e duração. + [Método USE](http://www.brendangregg.com/usemethod.html). Significa utilização, saturação e erros. A postagem de Sysdig sobre [as melhores práticas para alertas no Kubernetes](https://sysdig.com/blog/alerting-kubernetes/) inclui uma lista abrangente de componentes que podem afetar a disponibilidade de seus aplicativos. ### Use a biblioteca de cliente Prometheus para expor as métricas do aplicativo Além de monitorar o estado do aplicativo e agregar métricas padrão, você também pode usar a biblioteca [cliente Prometheus](https://prometheus.io/docs/instrumenting/clientlibs/) para expor métricas personalizadas específicas do aplicativo para melhorar a observabilidade do aplicativo. ### Use ferramentas de registro centralizadas para coletar e manter registros O registro no EKS se enquadra em duas categorias: registros do plano de controle e registros do aplicativo. O registro do plano de controle do EKS fornece registros de auditoria e diagnóstico diretamente do plano de controle para CloudWatch os registros em sua conta. Os registros do aplicativo são registros produzidos por pods executados dentro do seu cluster. Os registros de aplicativos incluem registros produzidos por pods que executam os aplicativos de lógica de negócios e os componentes do sistema Kubernetes, como CoreDNS, Cluster Autoscaler, Prometheus etc. O [EKS fornece cinco tipos de registros do plano de controle](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html): 1. Registros de componentes do servidor da API Kubernetes 1. Auditoria 1. Autenticador 1. Gerenciador de controladores 1. Agendador Os registros do gerenciador do controlador e do agendador podem ajudar a diagnosticar problemas no plano de controle, como gargalos e erros. Por padrão, os registros do plano de controle EKS não são enviados para CloudWatch Logs. Você pode ativar o registro do plano de controle e selecionar os tipos de registros do plano de controle do EKS que você gostaria de capturar para cada cluster em sua conta. A coleta de registros de aplicativos requer a instalação de uma ferramenta agregadora de registros como [Fluent Bit](http://fluentbit.io), [Fluentd](https://www.fluentd.org) ou [CloudWatchContainer Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) em seu cluster. As ferramentas agregadoras de registros do Kubernetes são executadas como DaemonSets e extraem registros de contêineres dos nós. Os registros do aplicativo são então enviados para um destino centralizado para armazenamento. Por exemplo, o CloudWatch Container Insights pode usar o Fluent Bit ou o Fluentd para coletar registros e enviá-los ao CloudWatch Logs para armazenamento. O Fluent Bit e o Fluentd oferecem suporte a muitos sistemas populares de análise de registros, como Elasticsearch e InfluxDB, oferecendo a capacidade de alterar o back-end de armazenamento de seus registros modificando o Fluentbit ou a configuração de log do Fluentd. ### Use um sistema de rastreamento distribuído para identificar gargalos Um aplicativo moderno típico tem componentes distribuídos pela rede e sua confiabilidade depende do funcionamento adequado de cada um dos componentes que compõem o aplicativo. Você pode usar uma solução de rastreamento distribuído para entender como as solicitações fluem e como os sistemas se comunicam. Os rastreamentos podem mostrar onde existem gargalos na sua rede de aplicativos e evitar problemas que podem causar falhas em cascata. Você tem duas opções para implementar o rastreamento em seus aplicativos: você pode implementar o rastreamento distribuído no nível do código usando bibliotecas compartilhadas ou usar uma malha de serviços. Implementar o rastreamento no nível do código pode ser desvantajoso. Nesse método, você precisa fazer alterações no seu código. Isso é ainda mais complicado se você tiver aplicativos poliglotas. Você também é responsável por manter outra biblioteca em todos os seus serviços. Os Service Meshes, como o [LinkerD](http://linkerd.io) e o [Istio](http://istio.io), podem ser usados para implementar o rastreamento distribuído em seu aplicativo com alterações mínimas no código do aplicativo. Você pode usar o service mesh para padronizar a geração, o registro e o rastreamento de métricas. Ferramentas de rastreamento como [AWS X-Ray](https://aws.amazon.com/xray/) e [Jaeger](https://www.jaegertracing.io) oferecem suporte a implementações de bibliotecas compartilhadas e service mesh. Considere usar uma ferramenta de rastreamento, como o [AWS X-Ray](https://aws.amazon.com/xray/) ou o [Jaeger](https://www.jaegertracing.io), que ofereça suporte a ambas as implementações (biblioteca compartilhada e malha de serviços), para que você não precise trocar de ferramenta se adotar o service mesh posteriormente. # Plano de controle EKS **dica** [Explore as](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) melhores práticas por meio de workshops do Amazon EKS. O Amazon Elastic Kubernetes Service (EKS) é um serviço gerenciado de Kubernetes que facilita a execução do Kubernetes na AWS sem precisar instalar, operar e manter seu próprio plano de controle do Kubernetes ou nós de trabalho. Ele executa o Kubernetes upstream e é certificado em conformidade com o Kubernetes. Essa conformidade garante que o EKS ofereça suporte às APIs do Kubernetes, assim como a versão de código aberto da comunidade que você pode instalar no EC2 ou localmente. Os aplicativos existentes em execução no Kubernetes upstream são compatíveis com o Amazon EKS. O EKS gerencia automaticamente a disponibilidade e a escalabilidade dos nós do plano de controle do Kubernetes e substitui automaticamente os nós não íntegros do plano de controle. ## Arquitetura EKS A arquitetura EKS foi projetada para eliminar qualquer ponto único de falha que possa comprometer a disponibilidade e a durabilidade do plano de controle do Kubernetes. O plano de controle do Kubernetes gerenciado pelo EKS é executado dentro de uma VPC gerenciada pelo EKS. O plano de controle do EKS compreende os nós do servidor da API Kubernetes, o cluster etcd. Nós de servidor da API Kubernetes que executam componentes como o servidor da API, o agendador e são executados `kube-controller-manager` em um grupo de auto-scaling. O EKS executa no mínimo dois nós de servidor de API em zonas de disponibilidade distintas (AZs) dentro da região da AWS. Da mesma forma, para maior durabilidade, os nós do servidor etcd também são executados em um grupo de auto-scaling que abrange três. AZs O EKS executa um NAT Gateway em cada AZ, e os servidores API e etcd são executados em uma sub-rede privada. Essa arquitetura garante que um evento em uma única AZ não afete a disponibilidade do cluster EKS. Quando você cria um novo cluster, o Amazon EKS cria um endpoint altamente disponível para o servidor gerenciado da API Kubernetes que você usa para se comunicar com seu cluster (usando ferramentas como). `kubectl` O endpoint gerenciado usa o NLB para balancear a carga dos servidores da API Kubernetes. O EKS também provisiona dois [ENIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) diferentes AZs para facilitar a comunicação com seus nós de trabalho. Conectividade de rede do plano de dados EKS ![\[Conectividade\]](http://docs.aws.amazon.com/pt_br/eks/latest/best-practices/images/reliability/eks-data-plane-connectivity.jpeg) Você pode [configurar se o servidor de API do seu cluster Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) pode ser acessado pela Internet pública (usando o endpoint público) ou por meio de sua VPC (usando o EKS gerenciado) ou ambos. ENIs Independentemente de os usuários e os nós de trabalho se conectarem ao servidor da API usando o endpoint público ou o ENI gerenciado pelo EKS, há caminhos redundantes para conexão. ## Recomendações Analise as recomendações a seguir. ## Monitore as métricas do plano de controle O monitoramento das métricas da API Kubernetes pode fornecer informações sobre o desempenho do plano de controle e identificar problemas. Um plano de controle não íntegro pode comprometer a disponibilidade das cargas de trabalho em execução dentro do cluster. Por exemplo, controladores mal escritos podem sobrecarregar os servidores da API, afetando a disponibilidade do seu aplicativo. O Kubernetes expõe as métricas do plano de controle no endpoint. `/metrics` Você pode ver as métricas expostas usando`kubectl`: ``` kubectl get --raw /metrics ``` Essas métricas são representadas em um formato de texto do [Prometheus](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md). Você pode usar o Prometheus para coletar e armazenar essas métricas. Em maio de 2020, CloudWatch foi adicionado suporte para monitorar as métricas CloudWatch do Prometheus no Container Insights. Portanto, você também pode usar CloudWatch a Amazon para monitorar o plano de controle do EKS. Você pode usar o [Tutorial para adicionar um novo Prometheus Scrape Target: Prometheus KPI](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) Server Metrics para coletar métricas CloudWatch e criar um painel para monitorar o plano de controle do seu cluster. [Você pode encontrar as métricas do servidor da API Kubernetes aqui.](https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go) Por exemplo, `apiserver_request_duration_seconds` pode indicar quanto tempo as solicitações de API estão demorando para serem executadas. Considere monitorar essas métricas do plano de controle: ### Servidor da API | Métrica | Description | | --- | --- | | `apiserver_request_total` | Contador de solicitações do apiserver divididas para cada verbo, valor de simulação, grupo, versão, recurso, escopo, componente e código de resposta HTTP. | | `apiserver_request_duration_seconds*` | Histograma de latência de resposta em segundos para cada verbo, valor de execução seca, grupo, versão, recurso, sub-recurso, escopo e componente. | | `apiserver_admission_controller_admission_duration_seconds*` | Histograma de latência do controlador de admissão em segundos, identificado por nome e dividido para cada operação e recurso e tipo de API (validar ou admitir). | | `apiserver_admission_webhook_rejection_count` | Contagem de rejeições de webhook de admissão. Identificado por nome, operação, código\$1de rejeição, tipo (validando ou admitido), tipo\$1erro (calling\$1webhook\$1error, apiserver\$1internal\$1error, no\$1error) | | `rest_client_request_duration_seconds*` | Solicite o histograma de latência em segundos. Dividido por verbo e URL. | | `rest_client_requests_total` | Número de solicitações HTTP, particionadas por código de status, método e host. | + As métricas do histograma incluem os sufixos \$1bucket, \$1sum e \$1count. ### etcd | Métrica | Description | | --- | --- | | `etcd_request_duration_seconds*` | Histograma de latência da solicitação Etcd em segundos para cada operação e tipo de objeto. | | `apiserver_storage_db_total_size_in_bytes`ou `apiserver_storage_size_bytes` (começando com EKS v1.28) | Tamanho do banco de dados Etcd. | + As métricas do histograma incluem os sufixos \$1bucket, \$1sum e \$1count. Considere usar o [Painel de Visão Geral do Monitoramento do Kubernetes](https://grafana.com/grafana/dashboards/14623) para visualizar e monitorar as solicitações do servidor da API Kubernetes e as métricas de latência e latência etcd. **Importante** Quando o limite de tamanho do banco de dados é excedido, o etcd emite um alarme sem espaço e para de receber mais solicitações de gravação. Em outras palavras, o cluster se torna somente para leitura e todas as solicitações para alterar objetos, como criar novos pods, escalar implantações etc., serão rejeitadas pelo servidor de API do cluster. ## autenticação de cluster Atualmente, o EKS oferece suporte a dois tipos de autenticação: [tokens de portador/conta de serviço](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) e autenticação IAM, que usa autenticação de token de [webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). Quando os usuários chamam a API Kubernetes, um webhook passa um token de autenticação incluído na solicitação para o IAM. O token, uma URL assinada de base 64, é gerado pela AWS Command Line Interface ([AWS CLI](https://aws.amazon.com/cli/)). O usuário ou a função do IAM que cria o EKS Cluster obtém automaticamente acesso total ao cluster. Você pode gerenciar o acesso ao cluster EKS editando o configmap [aws-auth](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html). Se você configurar incorretamente o `aws-auth` configmap e perder o acesso ao cluster, ainda poderá usar o usuário ou a função do criador do cluster para acessar seu cluster EKS. No caso improvável de você não poder usar o serviço IAM na região da AWS, você também pode usar o token portador da conta de serviço do Kubernetes para gerenciar o cluster. Crie uma `super-admin` conta que tenha permissão para realizar todas as ações no cluster: ``` kubectl -n kube-system create serviceaccount super-admin ``` Crie uma associação de função que dê ao superadmin o papel cluster-admin: ``` kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin ``` Veja o segredo da conta de serviço: ``` SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'` ``` Obtenha o token associado ao segredo: ``` TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode` ``` Adicione conta de serviço e token a`kubeconfig`: ``` kubectl config set-credentials super-admin --token=$TOKEN ``` Defina o contexto atual `kubeconfig` para usar a conta de superadministrador: ``` kubectl config set-context --current --user=super-admin ``` A final `kubeconfig` deve ficar assim: ``` apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https://.gr7.us-west-2.eks.amazonaws.com name: arn:aws:eks:us-west-2::cluster/ contexts: - context: cluster: arn:aws:eks:us-west-2::cluster/ user: super-admin name: arn:aws:eks:us-west-2::cluster/ current-context: arn:aws:eks:us-west-2::cluster/ kind: Config preferences: {} users: #- name: arn:aws:eks:us-west-2::cluster/ # user: # exec: # apiVersion: client.authentication.k8s.io/v1beta1 # args: # - --region # - us-west-2 # - eks # - get-token # - --cluster-name # - <> # command: aws # env: null - name: super-admin user: token: <> ``` ## Webhooks de admissão O Kubernetes tem dois tipos de webhooks de admissão: webhooks de admissão de [validação e webhooks de admissão mutantes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers). Isso permite que um usuário estenda a API kubernetes e valide ou altere objetos antes que eles sejam aceitos pela API. Configurações inadequadas desses webhooks podem desestabilizar o plano de controle do EKS ao bloquear as operações críticas do cluster. Para evitar o impacto das operações críticas do cluster, evite configurar webhooks “abrangentes”, como os seguintes: ``` - name: "pod-policy.example.com" rules: - apiGroups: ["*"] apiVersions: ["*"] operations: ["*"] resources: ["*"] scope: "*" ``` Ou certifique-se de que o webhook tenha uma política de abertura de falhas com um tempo limite inferior a 30 segundos para garantir que, se o webhook não estiver disponível, ele não prejudique as cargas de trabalho críticas do cluster. ### Bloqueie pods com opções inseguras `sysctls` `Sysctl`é um utilitário Linux que permite aos usuários modificar os parâmetros do kernel durante o tempo de execução. Esses parâmetros do kernel controlam vários aspectos do comportamento do sistema operacional, como rede, sistema de arquivos, memória virtual e gerenciamento de processos. O Kubernetes permite atribuir `sysctl` perfis para pods. O Kubernetes é classificado `systcls` como seguro e inseguro. Os Safe `sysctls` têm namespaces no contêiner ou no pod, e configurá-los não afeta outros pods no nó ou no próprio nó. Por outro lado, os sysctls inseguros são desativados por padrão, pois podem potencialmente interromper outros pods ou tornar o nó instável. Como os inseguros `sysctls` estão desativados por padrão, o kubelet não criará um pod com perfil inseguro. `sysctl` Se você criar um pod desse tipo, o programador atribuirá repetidamente esses pods aos nós, enquanto o nó não conseguirá iniciá-lo. Esse loop infinito acaba sobrecarregando o plano de controle do cluster, tornando o cluster instável. Considere usar o [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper-library/blob/377cb915dba2db10702c25ef1ee374b4aa8d347a/src/pod-security-policy/forbidden-sysctls/constraint.tmpl) ou o [Kyverno para rejeitar pods](https://kyverno.io/policies/pod-security/baseline/restrict-sysctls/restrict-sysctls/) inseguros. `sysctls` ## Lidando com atualizações de clusters Desde abril de 2021, o ciclo de lançamento do Kubernetes foi alterado de quatro lançamentos por ano (uma vez por trimestre) para três lançamentos por ano. Uma nova versão secundária (como 1. **21** ou 1. **22**) é lançado aproximadamente a [cada quinze semanas.](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/#what-s-changing-and-when) A partir do Kubernetes 1.19, cada versão secundária é suportada por aproximadamente doze meses após seu lançamento. Com o advento do Kubernetes v1.28, a distorção de compatibilidade entre o plano de controle e os nós de trabalho se expandiu de n-2 para n-3 versões secundárias. Para saber mais, consulte [Melhores práticas para atualizações de clusters](cluster-upgrades.md). ## Conectividade de endpoint de cluster Ao trabalhar com o Amazon EKS (Elastic Kubernetes Service), você pode encontrar tempos limite de conexão ou erros durante eventos como escalabilidade ou aplicação de patches no plano de controle do Kubernetes. Esses eventos podem fazer com que as instâncias do kube-apiserver sejam substituídas, resultando potencialmente no retorno de endereços IP diferentes ao resolver o FQDN. Este documento descreve as melhores práticas para os consumidores da Kubernetes API manterem uma conectividade confiável. **nota** A implementação dessas melhores práticas pode exigir atualizações nas configurações ou scripts do cliente para lidar com novas estratégias de reresolução e repetição de DNS de forma eficaz. O principal problema decorre do cache do lado do cliente do DNS e do potencial de endereços IP obsoletos do endpoint EKS - *NLB público para endpoint público ou X-ENI para* endpoint privado. Quando as instâncias do kube-apiserver são substituídas, o nome de domínio totalmente qualificado (FQDN) pode ser resolvido para novos endereços IP. No entanto, devido às configurações de DNS Time to Live (TTL), que são definidas para 60 segundos na zona do Route 53 gerenciada pela AWS, os clientes podem continuar usando endereços IP desatualizados por um curto período de tempo. Para mitigar esses problemas, os consumidores da API Kubernetes (como kubectl, CI/CD pipelines e aplicativos personalizados) devem implementar as seguintes práticas recomendadas: + Implemente a reresolução de DNS + Implemente novas tentativas com Backoff e Jitter. Por exemplo, veja [este artigo intitulado Falhas acontecem](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) + Implemente tempos limite do cliente. Defina tempos limite apropriados para evitar que solicitações de longa duração bloqueiem seu aplicativo. Lembre-se de que algumas bibliotecas de cliente do Kubernetes, especialmente aquelas geradas por geradores OpenAPI, podem não permitir a configuração fácil de tempos limite personalizados. + Exemplo 1 com kubectl: ``` kubectl get pods --request-timeout 10s # default: no timeout ``` + Exemplo 2 com Python: o cliente [Kubernetes](https://github.com/kubernetes-client/python/blob/release-30.0/kubernetes/client/api_client.py#L120) fornece um parâmetro \$1request\$1timeout Ao implementar essas melhores práticas, você pode melhorar significativamente a confiabilidade e a resiliência de seus aplicativos ao interagir com a API Kubernetes. Lembre-se de testar essas implementações minuciosamente, especialmente sob condições de falha simuladas, para garantir que elas se comportem conforme o esperado durante eventos reais de escalabilidade ou correção. ## Executando grandes clusters O EKS monitora ativamente a carga nas instâncias do plano de controle e as dimensiona automaticamente para garantir alto desempenho. No entanto, você deve considerar possíveis problemas e limites de desempenho no Kubernetes e nas cotas nos serviços da AWS ao executar grandes clusters. + Clusters com mais de 1000 serviços podem apresentar latência de rede com o uso `kube-proxy` no `iptables` modo de acordo com os [testes realizados pela ProjectCalico equipe](https://www.projectcalico.org/comparing-kube-proxy-modes-iptables-or-ipvs/). A solução é mudar para o [`ipvs`modo `kube-proxy` de execução](ipvs.md). + Você também pode experimentar a [limitação de solicitações da API EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) se a CNI precisar solicitar endereços IP para pods ou se você precisar criar novas instâncias do EC2 com frequência. Você pode reduzir as chamadas da API EC2 configurando a CNI para armazenar endereços IP em cache. Você pode usar tipos maiores de instância do EC2 para reduzir os eventos de escalabilidade do EC2. ## Recursos adicionais: + [Desmistificando a rede de clusters para nós de trabalho do Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/) + [Controle de acesso ao endpoint do cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) + [AWS re:Invent 2019: Amazon EKS nos bastidores (-R1) CON421](https://www.youtube.com/watch?v=7vxDWDD2YnM) # 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.