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á.
Cluster local EKS em Outposts
Quando há desconexões do link de serviço do Outposts da região principal, pode haver desafios com serviços como o EKS Extended Cluster, onde o plano de controle reside na região. Entre os desafios está a perda de comunicação entre o plano de controle EKS e os nós do trabalhador PODs e. Embora os nós de trabalho PODs possam continuar operando e atendendo aplicativos que residem localmente nos Outposts, o plano de controle do Kubernetes pode considerá-los insalubres e agendar sua substituição quando a conexão com o plano de controle for recuperada. Isso pode levar a períodos de inatividade do aplicativo quando a conectividade for restaurada.
Para simplificar isso, existe a opção de hospedar todo o seu cluster EKS no Outposts. Nessa configuração, tanto o plano de controle do Kubernetes quanto seus nós de trabalho são executados localmente no local, na capacidade computacional do Outposts. Dessa forma, seu cluster continua operando mesmo no caso de uma queda temporária na conexão do link de serviço e depois que ela for restaurada.
Cluster local Amazon EKS em Outposts
Considerações sobre o EKS Local Cluster on Outposts
Há algumas considerações quando um cluster local EKS é implantado no Outposts:
-
Durante uma desconexão, não há opções para executar nenhuma alteração no próprio cluster que exija adicionar novos nós de trabalho ou escalar automaticamente um grupo de nós, desde que isso EC2 dependa das chamadas da API ASG para a AWS região principal.
-
• Há um conjunto de recursos não suportados em clusters locais listados no suporte ao eksctl AWS Outposts
. .
