O Kubernetes tem recursos nativos que permitem que você torne suas aplicações mais resilientes a eventos como a degradação da integridade ou a deficiência de uma zona de disponibilidade (AZ). Ao executar suas workloads em um cluster do Amazon EKS, você pode melhorar ainda mais a tolerância a falhas e a recuperação de aplicações do seu ambiente de aplicações usando a mudança de zona ou a mudança de zona automática do Amazon Application Recovery Controller (ARC). A mudança de zona do ARC foi projetada para ser uma medida temporária que permite mover o tráfego de um recurso para longe de uma AZ afetada até que a mudança de zona expire ou seja cancelada. Você pode estender a mudança de zona, se necessário.
É possível iniciar uma mudança de zona para um cluster do EKS ou permitir que a AWS faça isso por você, habilitando a mudança automática de zona. Essa mudança atualiza o fluxo do tráfego de rede leste-oeste em seu cluster para considerar apenas os endpoints de rede para Pods em execução em nós de processamento em AZs íntegras. Além disso, qualquer ALB ou NLB que lide com o tráfego de entrada para aplicações no seu cluster do EKS encaminhará automaticamente o tráfego para destinos nas AZs íntegras. Para os clientes que buscam as metas de disponibilidade mais altas, no caso de uma AZ ser prejudicada, pode ser importante poder desviar todo o tráfego da AZ afetada até que ela se recupere. Para isso, você também pode habilitar um ALB ou NLB com mudança de zona do ARC.
Entendendo o fluxo de tráfego de rede leste-oeste entre pods
O diagrama a seguir ilustra dois exemplos de workloads: Pedidos e Produtos. O objetivo desse exemplo é mostrar como as workloads e os pods em diferentes AZs se comunicam.
-
Para que Pedidos se comunique com o Produtos, ela deve primeiro resolver o nome DNS do serviço de destino. Os pedidos se comunicarão com o CoreDNS para obter o endereço IP virtual (IP de Cluster) para esse serviço. Quando Pedido resolve o nome do serviço Produtos, ele envia o tráfego para esse IP de destino.
-
O kube-proxy é executado em todos os nós do cluster e observa continuamente o EndpointSlices
para Serviços. Quando um serviço é criado, um EndpointSlice é criado e gerenciado em segundo plano pelo controlador EndpointSlice. Cada EndpointSlice tem uma lista ou tabela de endpoints que contém um subconjunto de endereços de pods juntamente com os nós em que estão sendo executados. O kube-proxy configura regras de roteamento para cada um desses endpoints de Pod usando iptables
nos nós. O kube-proxy também é responsável por uma forma básica de balanceamento de carga, redirecionando o tráfego destinado ao IP do cluster de um serviço para ser enviado diretamente ao endereço IP de um pod. O kube-proxy faz isso reescrevendo o IP de destino na conexão de saída. -
Em seguida, os pacotes de rede são enviados ao pod de produtos na AZ 2 por meio das ENIs nos respectivos nós (conforme ilustrado no diagrama acima).
Entender a mudança de zona do ARC no EKS
Caso haja uma deficiência de AZ no seu ambiente, você pode iniciar uma mudança de zona para o ambiente de cluster do EKS. Como alternativa, você pode permitir que o AWS gerencie isso para você com a mudança de zona automática. Com a mudança de zona automática, o AWS monitorará a integridade geral da AZ e responderá a uma possível deficiência da AZ, desviando automaticamente o tráfego da AZ afetada no seu ambiente de cluster.
Depois que a mudança de zona do cluster do EKS estiver habilitada com o ARC, você poderá acionar uma mudança de zona ou ativar a mudança de zona automática usando o Console do ARC, a AWS CLI ou as APIs de mudança de zona e mudança de zona automática. Durante uma mudança de zona do EKS, ocorrerá automaticamente o seguinte:
-
Todos os nós na AZ afetada serão isolados. Isso impedirá que o Kubernetes Scheduler agende novos pods para os nós na AZ não íntegra.
-
Se você estiver usando grupos de nós gerenciados, o Rebalanceamento da zona de disponibilidade será suspenso e seu grupo do Auto Scaling (ASG) será atualizado para garantir que os novos nós do plano de dados do EKS sejam lançados somente nas AZs íntegras.
-
Os nós na AZ não íntegros não serão encerrados, e os pods não serão despejados desses nós. Isso é para garantir que, quando uma mudança de zona expirar ou for cancelada, seu tráfego possa ser devolvido com segurança à AZ que ainda tem capacidade total
-
O controlador EndpointSlice localizará todos os endpoints de pod na AZ afetada e os removerá dos EndpointSlices relevantes. Isso garantirá que somente os endpoints Pod em AZs íntegras sejam direcionados para receber tráfego de rede. Quando uma mudança de zona for cancelada ou expirar, o controlador EndpointSlice atualizará o EndpointSlices para incluir os endpoints na AZ restaurada.
Os diagramas abaixo mostram um fluxo de alto nível de como a mudança de zona do EKS garante que somente os endpoints de PODs íntegros sejam direcionados em seu ambiente de cluster.
Requisitos de mudança de zona do EKS
Para que a mudança de zona funcione com êxito no EKS, é necessário configurar o ambiente do cluster para que ele seja resiliente a uma deficiência da AZ com antecedência. Veja abaixo uma lista das etapas que você deve seguir.
-
Provisionar os nós de processamento do seu cluster em várias AZs
-
Provisionar capacidade de computação suficiente para suportar a remoção de uma única AZ
-
Pré-escalonar seus pods (incluindo CoreDNS) em cada AZ
-
Espalhe várias réplicas de pods em todas as AZs para garantir que a mudança de uma única AZ lhe deixará com capacidade suficiente
-
Co-localizar Pods interdependentes ou relacionados na mesma AZ
-
Teste se o seu ambiente de cluster funcionaria conforme o esperado com uma AZ a menos, iniciando manualmente uma mudança de zona. Como alternativa, você pode habilitar a mudança de zona automática e responder às execuções de prática de mudança automática Isso não é necessário para que a mudança de zona funcione no EKS, mas é altamente recomendável.
Provisione seus nós de processamento EKS em várias AZs
As regiões da AWS têm vários locais separados com data centers físicos, conhecidos como Zonas de disponibilidade (AZs). As AZs são projetadas para serem fisicamente isoladas umas das outras a fim de evitar impactos simultâneos que possam afetar toda uma região. Ao provisionar um cluster do EKS, você deve implantar os nós de processamento em várias AZs em uma região. Isso tornará seu ambiente de cluster mais resistente à deficiência de uma única AZ e permitirá que manter a alta disponibilidade (HA) das suas aplicações em execução nas outras AZs. Quando você iniciar uma mudança de zona longe da AZ afetada, a rede no cluster do seu ambiente EKS será atualizada automaticamente para usar apenas AZs íntegras, mantendo uma postura de alta disponibilidade para o cluster.
Garantir que você tenha uma configuração multi-AZ para o seu ambiente EKS aumentará a confiabilidade geral do seu sistema. Porém, os ambientes multi-AZ podem desempenhar um papel significativo na forma como os dados da aplicação são transferidos e processados, o que, por sua vez, terá um impacto sobre as tarifas de rede do seu ambiente. Em particular, o tráfego frequente de saída entre zonas (tráfego distribuído entre AZs) pode ter um grande impacto nos custos relacionados à rede. É possível aplicar estratégias diferentes para controlar a quantidade de tráfego entre zonas entre os pods no cluster do EKS e reduzir os custos associados. Consulte este guia de práticas recomendadas
O diagrama abaixo mostra um ambiente EKS altamente disponível com 3 AZs íntegras.
O diagrama abaixo mostra como um ambiente do EKS com 3 AZs é resiliente a uma deficiência de AZ e permanece altamente disponível por causa das outras 2 AZs íntegras.
Provisão de capacidade de computação suficiente para suportar a remoção de uma única AZ
Para otimizar a utilização de recursos e os custos de sua infraestrutura de computação no plano de dados do EKS, é uma prática recomendada alinhar a capacidade de computação aos requisitos da sua workload. Porém, se todos os seus nós de processamento estiverem com capacidade total, isso fará com que você dependa da adição de novos nós de processamento ao plano de dados do EKS antes que novos pods possam ser agendados. Ao executar workloads críticas, geralmente é sempre uma boa prática executar com capacidade redundante online para lidar com eventualidades, como aumentos repentinos de carga, problemas de integridade do nó etc. Se você planeja usar a mudança de zona, está planejando remover uma AZ inteira de capacidade, portanto, precisa ajustar a capacidade de computação redundante para que seja suficiente para lidar com a carga, mesmo com uma AZ offline.
Ao dimensionar sua computação, o processo de adição de novos nós ao plano de dados do EKS levará algum tempo, o que pode ter implicações no desempenho em tempo real e na disponibilidade das suas aplicações, especialmente no caso de uma deficiência de zona. Seu ambiente do EKS deve ser resiliente para absorver a carga da perda de uma AZ para evitar uma experiência degradada para seus usuários finais ou clientes. Isso significa minimizar ou eliminar qualquer atraso entre o momento em que um novo pod é necessário e quando ele é realmente agendado em um nó de processamento.
Além disso, no caso de uma deficiência de zona, você deve atenuar o risco de uma possível restrição da capacidade de computação, o que impediria que os novos nós necessários fossem adicionados ao plano de dados do EKS nas AZs íntegras.
Para conseguir isso, você deve provisionar em excesso a capacidade de computação em alguns dos nós de processamento em cada um dos AZs para que o Kubernetes Scheduler tenha capacidade pré-existente disponível para novos posicionamentos de pod, especialmente quando você tiver uma AZ a menos no seu ambiente.
Execute e espalhe várias réplicas de pod em AZs
O Kubernetes permite que você pré-escale suas workloads executando várias instâncias (réplicas de pod) de uma única aplicação. A execução de várias réplicas de pods para uma aplicação elimina um único ponto de falha e aumenta seu desempenho geral ao reduzir a tensão de recursos em uma única réplica. Porém, para ter alta disponibilidade e melhor tolerância a falhas para suas aplicações, você deve executar e distribuir várias réplicas de uma aplicação em diferentes domínios de falha (também chamados de domínios de topologia), neste caso, AZs. Com as restrições de propagação de topologia
O diagrama abaixo mostra um ambiente do EKS com fluxo de tráfego leste-oeste quando todas as AZs estão íntegras.
O diagrama abaixo mostra um ambiente do EKS com fluxo de tráfego leste-oeste quando uma única AZ falha e você inicia uma mudança de zona.
O trecho de código abaixo é um exemplo de como configurar sua workload com esse recurso do Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
O mais importante é que você execute várias réplicas do seu software de servidor DNS (CoreDNS/kube-dns) e aplique restrições semelhantes de propagação de topologia se elas ainda não estiverem configuradas por padrão. Isso ajudará a garantir que você tenha pods de DNS suficientes em AZs íntegras para continuar lidando com solicitações de descoberta de serviço para outros pods de comunicação no cluster se houver uma única deficiência de AZs. O complemento CoreDNS EKS tem configurações padrão para que os pods do CoreDNS sejam distribuídos pelas zonas de disponibilidade do cluster se houver nós em várias AZs disponíveis. Você também pode substituir essas configurações padrão por suas próprias configurações personalizadas.
Ao instalar o CoreDNS com o HelmreplicaCount
no arquivo values.yamltopologySpreadConstraints
no mesmo arquivo values.yaml. O trecho de código abaixo demonstra como configurar o CoreDNS para isso.
CoreDNS Helm values.yaml
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
No caso de uma deficiência da AZ, você pode absorver o aumento da carga nos pods do CoreDNS usando um sistema de dimensionamento automático para o CoreDNS. O número de instâncias de DNS necessárias dependerá do número de workloads em execução em seu cluster. O CoreDNS é vinculado à CPU, o que permite que ele seja dimensionado com base na CPU usando o HPA (Horizontal Pod Autoscaler)
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
Como alternativa, o EKS pode gerenciar o dimensionamento automático da implantação do CoreDNS na versão complementar do EKS do CoreDNS. Esse autoscaler do CoreDNS 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.
Para ativar a configuração de dimensionamento automático no complemento CoreDNS EKS, você deve adicionar as seguintes definições de configuração opcionais:
{
"autoScaling": {
"enabled": true
}
}
Você também pode usar o DNS NodeLocal
Colocar pods interdependentes na mesma AZ
Na maioria dos casos, você pode estar executando workloads distintas que precisam se comunicar entre si para a execução bem-sucedida de um processo de ponta a ponta. Se as aplicações distintas estiverem espalhadas por diferentes AZs, mas não estiverem localizadas na mesma AZ, uma única deficiência na AZ poderá afetar o processo subjacente de ponta a ponta. Por exemplo, se o Aplicação A tiver várias réplicas na AZ 1 e na AZ 2, mas a Aplicação B tiver todas as suas réplicas na AZ 3, a perda da AZ 3 afetará todos os processos de ponta a ponta entre essas duas workloads (Aplicação A e B). A combinação de restrições de propagação de topologia com afinidade de pods pode aprimorar a resiliência da sua aplicação, distribuindo os pods por todas as AZs, bem como configurando uma relação entre determinados pods para garantir que eles sejam colocados juntos.
Com regras de afinidade de pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
O diagrama abaixo mostra pods que foram colocados no mesmo nó usando regras de afinidade de pods.
Teste se o seu ambiente de cluster pode lidar com a perda de uma AZ
Depois de atender aos requisitos acima, a próxima etapa importante é testar se você tem capacidade suficiente de computação e workload para lidar com a perda de uma AZ. Você pode fazer isso acionando manualmente uma mudança de zona no EKS. Como alternativa, você pode habilitar a mudança de zona automática e configurar execuções práticas para testar se as suas aplicações funcionam conforme o esperado com uma AZ a menos no ambiente de cluster.
Perguntas frequentes
Por que devo usar esse recurso?
Ao usar a mudança de zona do ARC ou a mudança de zona automática no cluster do EKS, você pode manter melhor a disponibilidade das aplicações Kubernetes automatizando o processo de recuperação rápida de deslocamento do tráfego de rede no cluster para longe de uma AZ afetada. Com o ARC, é possível evitar etapas longas e complicadas que geralmente resultam em a um período de recuperação prolongado durante eventos na AZ afetada.
Como esse recurso funciona com outros serviços do AWS?
O EKS integra-se ao ARC, que fornece a interface principal para que você realize operações de recuperação no AWS. Para garantir que o tráfego no cluster seja roteado adequadamente para longe de uma AZ afetada, são feitas modificações na lista de endpoints de rede para Pods em execução no plano de dados do Kubernetes. Se estiver usando balanceadores de carga da AWS para rotear o tráfego externo para o cluster, você já poderá registrar seus balanceadores de carga no ARC e acionar uma mudança de zona neles para evitar que o tráfego flua para a zona degradada. Esse recurso também interage com os grupos do Amazon EC2 Auto Scaling (ASG) que são criados pelos grupos de nós gerenciados (MNG) do EKS. Para evitar que uma AZ afetada seja usada para novos pods do Kubernetes ou inicializações de nós, o EKS remove a AZ prejudicada do ASG.
Como esse recurso é diferente das proteções padrão do Kubernetes?
Esse recurso funciona em conjunto com várias proteções integradas nativas do Kubernetes que ajudam os clientes a se manter resilientes. Você pode configurar a prontidão do pod e as sondas de atividade que decidem quando um pod deve receber tráfego. Quando essas sondas falham, o Kubernetes remove esses pods como alvos de um serviço, e o tráfego deixar de ser enviado ao pod. Embora isso seja útil, não é comum que os clientes configurem essas verificações de integridade e, portanto, é certeza que elas falharão quando uma zona estiver degradada. O recurso de mudança de zona do ARC oferece uma rede de segurança adicional que ajuda a isolar totalmente uma AZ degradada quando as proteções nativas do Kubernetes não são suficientes. Ele também oferece uma maneira fácil de testar a prontidão operacional e a resiliência da sua arquitetura.
O AWS pode acionar uma mudança de zona em meu nome?
Sim, se você quiser uma maneira totalmente automatizada de usar a mudança de zona do ARC, poderá habilitar a mudança de zona automática do ARC. Com a mudança de zona automática, você pode contar com a AWS para monitorar a integridade dos AZs do cluster EKS e acionar automaticamente uma mudança quando for detectada uma deficiência no AZ.
O que acontecerá se eu usar esse recurso e meus nós de processamento e workloads não forem pré-escalonados?
Se você não estiver em pré-escala e depender do provisionamento de nós ou pods adicionais durante uma mudança de zona, corre o risco de ter uma recuperação atrasada. O processo de adição de novos nós ao plano de dados do Kubernetes levará algum tempo, o que pode ter implicações no desempenho em tempo real e na disponibilidade das suas aplicações, especialmente no caso de uma deficiência de zona. Além disso, no caso de uma deficiência de zona, você pode encontrar uma possível restrição de capacidade de computação que impediria a adição de novos nós necessários às AZs íntegras.
Se as suas workloads não forem pré-escalonadas e distribuídas em todas as AZs do cluster, uma deficiência de zona poderá afetar a disponibilidade de uma aplicação que esteja sendo executada apenas em nós de processamento em uma AZ afetada. Para reduzir o risco de uma interrupção completa da disponibilidade da sua aplicação, o EKS tem uma proteção contra falhas para que o tráfego seja enviado aos endpoints do Pod em uma zona afetada se essa workload tiver todos os seus endpoints na AZ não íntegra. Porém, é altamente recomendável fazer uma pré-escala e distribuir as aplicações em todas as AZs para manter a disponibilidade no caso de um problema de zona.
O que acontecerá se eu estiver executando uma aplicação com reconhecimento de estado?
Se você estiver executando uma aplicação com reconhecimento de estado, precisará avaliar sua tolerância a falhas, dependendo do caso de uso e da arquitetura. Se você tiver uma arquitetura ou padrão ativo/em espera, pode haver casos em que o ativo está em uma AZ afetada. No nível da aplicação, se a espera não estiver ativada, você poderá ter problemas com a aplicação. Você também pode ter problemas quando novos pods do Kubernetes forem iniciados em AZs íntegras, pois eles não poderão ser anexados aos volumes persistentes vinculados à AZ afetada.
Esse recurso funciona com o Karpenter?
No momento, o suporte ao Karpenter não está disponível com a mudança de zona do ARC e a mudança de zona automática no EKS. Se uma AZ for afetada, você poderá ajustar a configuração relevante do Karpenter NodePool removendo a AZ não íntegra para que os novos nós de processamento sejam iniciados somente nas AZs íntegras.
Esse recurso funciona com o EKS Fargate?
Esse recurso não funciona com o EKS Fargate. Por padrão, quando o EKS Fargate reconhecer um evento de integridade de zona, os pods preferirão ser executados nas outras AZs.
O ambiente de gerenciamento do Kubernetes gerenciado pelo EKS será afetado?
Não, por padrão, o Amazon EKS executa e dimensiona o ambiente de gerenciamento do Kubernetes em várias AZs para garantir alta disponibilidade. A mudança de zona do ARC e a mudança de zona automática atuarão apenas no plano de dados do Kubernetes.
Há algum custo associado a esse novo recurso?
Você pode usar a mudança de zona do ARC e a mudança de zona automática no seu cluster do EKS sem custo adicional. Porém, você continuará pagando pelas instâncias provisionadas e é altamente recomendável pré-escalar seu plano de dados do Kubernetes antes de usar esse recurso. Você deve considerar o equilíbrio certo entre custo e disponibilidade da aplicação.