Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
Configuração avançada do ambiente de gerenciamento do Kubernetes
Visão geral
O Amazon EKS gerencia o ambiente de gerenciamento do Kubernetes para seu cluster, incluindo o servidor de API, o agendador e o gerenciador de controladores. O EKS executa esses componentes com as configurações upstream padrão do Kubernetes que funcionam bem para a maioria das workloads, e você não precisa alterá-las para a maioria dos clusters. Porém, algumas wokloads se beneficiam de diferentes configurações do ambiente de gerenciamento. Talvez você queira que o agendador empacote pods em menos nós para reduzir os custos de computação, reter eventos do Kubernetes por um período mais curto para limitar o crescimento do banco de dados do cluster (etcd) ou avaliar as decisões de escalonamento automático com mais frequência.
Com a configuração avançada do ambiente de gerenciamento do Kubernetes, você define esses parâmetros diretamente no seu cluster. O EKS os aplica ao ambiente de gerenciamento, e seu cluster continua operando com as mesmas características de disponibilidade e desempenho.
Essas são configurações avançadas. Cada parâmetro de configuração muda a forma como um componente principal do ambiente de gerenciamento do Kubernetes se comporta para as workloads em execução no cluster, e o valor correto depende da sua workload. Antes de alterar um parâmetro, leia as considerações sobre ele nas seções a seguir e teste a alteração em um cluster que não seja de produção.
Você pode definir parâmetros avançados de configuração do ambiente de gerenciamento ao criar um cluster ou atualizá-los em um cluster existente a qualquer momento. Esse recurso usa as operações existentes CreateCluster e UpdateClusterConfig com novos parâmetros, para que você possa configurá-lo por meio do Console de gerenciamento da AWS, da AWS CLI, dos AWS SDKs ou do AWS CloudFormation. O EKS valida cada configuração antes de aplicá-la e registra as alterações no AWS CloudTrail.
Os parâmetros avançados do ambiente de gerenciamento se aplicam a todo o cluster e a todas as workloads em execução nele. Você não pode definir seus escopos para namespaces ou workloads individuais. O EKS restringe cada parâmetro a um intervalo validado. Os valores com suporte para cada parâmetro estão listados com esse parâmetro na seção a seguir.
Parâmetros do ambiente de gerenciamento do Kubernetes com suporte
O Amazon EKS oferece suporte aos parâmetros a seguir. Cada parâmetro pertence a um componente do ambiente de gerenciamento e é definido por meio do campo de configuração desse componente: kubeSchedulerConfig, kubeControllerManagerConfig ou kubeApiServerConfig.
| Componente | Parâmetro | Valores compatíveis | Padrão | Requer ambiente de gerenciamento provisionado |
|---|---|---|---|---|
|
kube-scheduler |
|
|
|
Não |
|
kube-controller-manager |
|
|
|
Sim |
|
kube-controller-manager |
|
|
|
Sim |
|
kube-apiserver |
|
|
|
Não |
|
kube-apiserver |
|
|
|
Não |
Os valores padrão e compatíveis neste tópico se aplicam à versão do Kubernetes (EKS v1.31 e superior) disponível na publicação e podem mudar em versões posteriores. A operação DescribeClusterVersions relata os valores padrão e compatíveis atuais para cada parâmetro e versão do Kubernetes. Portanto, use-a como fonte confiável se você gerencia clusters em várias versões ou automatiza a configuração de clusters. Para obter mais informações, consulte Configurar parâmetros avançados do ambiente de gerenciamento do Kubernetes.
As seções a seguir descrevem cada parâmetro, quando alterá-lo e o que considerar antes de fazer isso.
Agendador: ajuste dos recursos do nó
O agendador atribui pods aos nós em duas fases. Primeiro, ele filtra os nós que podem executar um pod, depois classifica os candidatos restantes e coloca o pod no nó de maior pontuação. O plug-in nodeResourcesFit verifica se um nó tem os recursos que um pod solicita e classifica os nós de acordo com uma estratégia de pontuação.
| Campo | Descrição | Valores compatíveis | Padrão |
|---|---|---|---|
|
|
A estratégia usada para pontuar os nós por alocação de recursos. |
|
|
|
|
Os recursos considerados na pontuação, cada um com um peso relativo. |
|
|
LeastAllocated favorece os nós com menor alocação de recursos, o que distribui os pods pelos nós do seu cluster e deixa espaço livre em cada nó. Esse é o comportamento padrão do Kubernetes e é uma boa opção quando você quer capacidade disponível em cada nó para absorver o crescimento dos pods existentes.
MostAllocated favorece os nós que já têm maior alocação de recursos, o que agrupa os pods em menos nós. Como suas workloads ocupam menos capacidade total, você pode executá-las em um número menor de nós e reduzir os gastos com computação. Com o tempo, esse comportamento de empacotamento mantém os nós pouco usados livres de novas workloads, de modo que os pools de nós que oferecem suporte à consolidação possam removê-los.
O EKS oferece suporte às estratégias LeastAllocated e MostAllocated. A estratégia RequestedToCapacityRatio upstream do Kubernetes não tem suporte.
Pesos dos recursos
Opcionalmente, você pode especificar uma matriz de resources com pesos personalizados para influenciar quais recursos são mais importantes nas decisões de pontuação. Isso é útil quando um recurso específico é a restrição em seu cluster. Por exemplo, em clusters em que os aceleradores (GPU) são o recurso escasso, a ponderação de nvidia.com/gpu acima da CPU e da memória concentra os pods que solicitam aceleradores em nós que já estão parcialmente ocupados.
Os pesos são relativos, não absolutos. Configurar cpu: 100 e memory: 1 não faz com que o agendador ignore a memória. Ele pondera a CPU 100 vezes mais do que a memória na fórmula de pontuação. Se cada nó candidato tiver disponibilidade de CPU idêntica, a CPU não os distingue mais e a pontuação recai efetivamente sobre a memória.
Omitir um recurso é diferente de atribuir-lhe um peso baixo. Quando você especifica uma matriz de resources, somente os recursos listados são pontuados. Um recurso que você omite é totalmente excluído do cálculo. Por exemplo, cpu: 100 sem entrada memory pontua os nós somente na CPU, e a disponibilidade de memória não tem influência no resultado. Para manter um recurso no cálculo e, ao mesmo tempo, reduzir sua influência, liste-o com um peso baixo em vez de omiti-lo.
A ponderação de um recurso acelerador, como nvidia.com/gpu, afeta apenas a pontuação dos pods que realmente declaram resources.requests para esse recurso. Os pods que não solicitam aceleradores não são influenciados pelo peso do acelerador.
Os três recursos do acelerador são recursos estendidos do Kubernetes, ou seja, recursos em nível de nó anunciados ao Kubernetes por meio de um plug-in em vez de incorporados. Eles são pontuados somente quando um plug-in do dispositivo os anuncia no kubelet por meio da API do plug-in do dispositivo. Os recursos disponibilizados em um nó apenas por um driver de dispositivo não são visíveis para o plug-in nodeResourcesFit e não são pontuados. Os recursos gerenciados por meio da Alocação Dinâmica de Recursos (DRA) são programados por um plug-in separado e não fazem parte da pontuação nodeResourcesFit; portanto, habilitar o DRA não altera o comportamento desse parâmetro. Para obter mais informações sobre como configurar plug-ins de dispositivos NVIDIA, consulte NVIDIA DRA and device plugin. Para obter mais informações sobre como configurar dispositivos Neuron, consulte Neuron device management.
A estratégia de pontuação é uma das várias entradas que o agendador usa para calcular uma pontuação para cada nó. Para obter mais informações sobre como o agendador filtra e pontua os nós, consulte Scheduling Framework
Considerações sobre a estratégia de pontuação
-
Os pods em execução não são movidos. O agendador do Kubernetes nunca realoca um pod que já está em execução. A alteração da estratégia de pontuação afeta apenas as decisões futuras de agendamento, e o posicionamento existente do pod é permanente. Para reequilibrar os pods que já estão em execução, remova-os ou reinicie-os.
-
O comportamento de filtragem não muda. A estratégia de pontuação afeta apenas a fase de pontuação, na qual o agendador classifica os nós por preferência. A fase de filtragem, que determina se um pod pode ser executado em um nó, permanece inalterada. Um pod que não cabe em um nó ainda não é agendado nele em nenhuma das estratégias.
-
MostAllocatedconcentra o raio de explosão. Empacotar workloads em menos nós significa que mais pods são afetados ao mesmo tempo se um nó perder a integridade, uma instância for desativada ou uma zona de disponibilidade for interrompida. Com alta rotatividade de pods, os nós densamente compactados também ficam cheios mais rapidamente, o que pode deixar os pods no estadoPendingenquanto a nova capacidade é provisionada. -
O agendador e o gerenciamento de nós operam em camadas diferentes. A estratégia de pontuação influencia onde os pods são colocados entre os nós que já podem executá-los. Isso não muda a forma como o Modo Automático do EKS ou o Karpenter provisionam ou removem os nós. Valide o comportamento combinado da sua workload antes de alterar a configuração.
Gerenciador do controlador: período de sincronização do Horizontal Pod Autoscaler
O gerenciador do controlador executa os controladores Kubernetes que direcionam o estado do cluster para o estado desejado, incluindo o controlador Horizontal Pod Autoscaler (HPA). Em cada ciclo, o controlador HPA recupera métricas para cada objeto HorizontalPodAutoscaler, calcula a contagem de réplicas desejada e atualiza a workload de destino se a contagem for alterada.
| Campo | Descrição | Valores compatíveis | Padrão |
|---|---|---|---|
|
|
Com que frequência o controlador HPA avalia as decisões de escalabilidade. |
|
|
Reduzir o período de sincronização significa que suas workloads escalam mais cedo após o aumento da carga, em vez de esperar um ciclo completo antes de adicionar capacidade.
Para configurar esse parâmetro, seu cluster deve estar no ambiente de gerenciamento provisionado do Amazon EKS. Reduzir o intervalo aumenta a taxa na qual o controlador HPA reconcilia cada objeto HorizontalPodAutoscaler no cluster, o que gera mais solicitações de API. Cada reconciliação consome pelo menos uma solicitação de API, e uma reconciliação que altera a contagem de réplicas consome mais duas. Os clusters do ambiente de gerenciamento provisionado realizam a pré-alocação da capacidade do ambiente de gerenciamento, que está sempre pronta para workloads exigentes; portanto, são dimensionados para absorver essa carga adicional. Para obter mais informações, consulte Ambiente de gerenciamento provisionado do Amazon EKS.
Efeito no número de objetos HPA que seu cluster suporta
-
Reduzir o período de sincronização reduz o número de objetos
HorizontalPodAutoscalerque seu ambiente de gerenciamento pode reconciliar dentro do cronograma, porque o controlador tem menos tempo para trabalhar na mesma fila. Reduzir o período de15spara10sdiminui a contagem de objetos suportados em aproximadamente um terço. Antes de reduzir o período de sincronização, conte os objetosHorizontalPodAutoscalerem seu cluster e confirme se o período mais curto ainda suporta essa contagem em seu nível de escalabilidade:kubectl get hpa --all-namespaces --no-headers | wc -l -
O EKS não valida o período de sincronização em relação à sua contagem de objetos HPA. A alteração na configuração é bem-sucedida mesmo que seu cluster já tenha mais objetos
HorizontalPodAutoscalerdo que o período mais curto suporta. Verifique você mesmo a contagem antes de fazer a alteração. -
Exceder a contagem suportada degrada silenciosamente o dimensionamento automático. Se o controlador não conseguir trabalhar com todos os objetos dentro do período, alguns objetos não serão reconciliados dentro do cronograma. O EKS não emite um alarme ou um evento do Kubernetes para essa condição, e o sintoma é o dimensionamento automático que responde mais lentamente do que o esperado, ou seja, o oposto do efeito pretendido. Se você observar um atraso no dimensionamento após reduzir o período de sincronização, retorne o parâmetro ao padrão de
15s. -
O período de sincronização se aplica a todos os objetos HPA no cluster. Você não pode definir períodos de sincronização diferentes para objetos ou namespaces diferentes.
Gerenciador de controladores: limite da coleta de resíduos de pods encerrados
O gerenciador do controlador executa o coletor de resíduos do pod encerrado (o controlador do pod GC). Esse controlador exclui os pods encerrados (pods na fase Succeeded ou Failed) depois que o número de pods encerrados no cluster excede um limite. O parâmetro terminatedPodGcThreshold define esse limite.
| Campo | Descrição | Valores compatíveis | Padrão |
|---|---|---|---|
|
|
O número de pods encerrados que podem existir antes que o coletor de resíduos de pods encerrados comece a excluir os pods encerrados. |
|
|
O coletor de resíduos funciona em um ciclo fixo de 20 segundos. Quando você diminui o limite, o coletor começa a excluir à força os pods encerrados mais antigos no próximo ciclo até que a contagem atinja o novo limite.
Para configurar esse parâmetro, seu cluster deve estar no ambiente de gerenciamento provisionado do Amazon EKS. Reduzir o limite aumenta o trabalho de coleta de resíduos que o controlador executa no banco de dados do cluster (etcd). Cada passe de coleta se torna elegível para consultar, processar e excluir mais pods encerrados. Os clusters do ambiente de gerenciamento provisionado realizam a pré-alocação da capacidade do ambiente de gerenciamento, que está sempre pronta para workloads exigentes, para que possam absorver essa carga adicional. Para obter mais informações, consulte Ambiente de gerenciamento provisionado do Amazon EKS.
Considerações sobre o limite da coleta de resíduos de pods encerrados
-
Reduzir o limite exclui imediatamente o excesso de pods encerrados. Se você diminuir o limite (por exemplo, de
12500para10000), o controlador de coleta de resíduos começará a excluir à força os pods encerrados mais antigos no próximo ciclo. O controlador continua até que a contagem de pods encerrados atinja o novo limite. A redução não é gradual. -
O limite se aplica a todos os pods encerrados, independentemente do proprietário. Isso afeta os pods na fase
SucceededouFailed, independentemente de serem de propriedade de um Job, CronJob ou implantação, ou serem independentes. Na prática, os pods Job e CronJob são os contribuidores mais comuns para a contagem de pods encerrados. -
Reduzir o limite reduz a janela de depuração. Os pods concluídos e com falha desaparecem de
kubectl get podsekubectl logsmais cedo. A automação que inspeciona códigos de saída ou logs de pods de Job concluídos tem uma janela menor para operar. -
O limite é uma configuração de cluster global. Você não pode configurá-lo por namespace ou por Job. Para controlar o ciclo de vida dos pods de um Job individual, use
ttlSecondsAfterFinishednesse Job.
Servidor de API: retenção de eventos
O servidor de API é o front-end do ambiente de gerenciamento do Kubernetes. Ele serve a API do Kubernetes e persiste o estado do cluster no banco de dados do cluster (etcd). O Kubernetes registra eventos para descrever o que está acontecendo no seu cluster, como decisões de agendamento de pods, extração de imagens, falhas na verificação de integridade e ações de escalabilidade.
| Campo | Descrição | Valores compatíveis | Padrão |
|---|---|---|---|
|
|
Por quanto tempo o servidor de API retém os eventos do Kubernetes antes de excluí-los. |
|
|
Clusters que executam workloads de alta rotatividade, como trabalhos em lote em grande escala, workloads de IA, pipelines de CI/CD e CronJobs frequentes, acumulam milhares de eventos rapidamente. Cada evento retido consome espaço no banco de dados do cluster que concorre com os objetos que seu cluster precisa executar, e uma grande coleção de eventos torna as operações de lista do servidor de API mais caras de servir.
A redução da retenção de eventos elimina esses dados de diagnóstico de curta duração mais cedo, o que reduz a pressão de armazenamento do banco de dados do cluster e melhora os tempos de resposta do servidor de API para consultas com muitos eventos.
Um período de retenção mais curto é uma boa opção quando:
-
Seu cluster executa workloads em lote, CI/CD, IA ou CronJob que geram um grande volume de eventos.
-
Você observa o armazenamento do banco de dados do cluster crescendo até o limite.
-
Você depende de um sistema externo para capturar eventos de forma durável e não depende de
kubectl get eventspara depuração histórica.
Considerações para retenção de eventos
-
Uma alteração se aplica somente a novos eventos. O Kubernetes define a expiração de um evento quando o evento é criado. Os eventos que já existem mantêm o período de retenção que estava em vigor quando foram criados e expiram nesse cronograma. A redução de
eventTtlnão reduz a vida útil dos eventos que já estão no banco de dados do cluster; então, a redução no armazenamento entra em vigor gradualmente à medida que os eventos existentes se esgotam. -
Eventos excluídos não podem ser recuperados. Depois que o Kubernetes remove um evento, ele desaparece permanentemente. Se você encurtar a retenção além do pretendido e perder o histórico de eventos, não há como restaurá-lo. Verifique se tudo de que você depende para solucionar problemas foi capturado fora do cluster antes de reduzir esse valor.
-
Os eventos podem persistir um pouco além do período configurado. Sob algumas condições, a expiração de um evento pode ser estendida além do valor que você configurou devido à renovação do lease do etcd que pode ocorrer durante a eleição do líder do ambiente de gerenciamento.
-
Janela de depuração reduzida. Um período de retenção mais curto restringe a janela mostrada por
kubectl get eventsekubectl describe. As ferramentas de monitoramento que extraem eventos do cluster têm menos dados disponíveis. Escolha um valor que equilibre a eficiência do armazenamento com seu fluxo de trabalho de depuração. -
A configuração abrange todo o cluster. A retenção se aplica a todos os eventos, incluindo agendamento de pods, condições de nós e eventos de escalabilidade, em todos os namespaces. Você não pode definir períodos de retenção diferentes por namespace.
Servidor de API: intervalo de portas do nó de serviço
O Kubernetes aloca uma porta desse intervalo em cada nó para cada serviço que precisa de uma. Isso inclui serviços do tipo NodePort e, por padrão, serviços do tipo LoadBalancer.
| Campo | Descrição | Valores compatíveis | Padrão |
|---|---|---|---|
|
|
A porta mais baixa no intervalo. |
|
|
|
|
A porta mais alta no intervalo. |
|
|
minPort deve ser menor ou igual a maxPort. O Amazon EKS rejeita uma configuração em que minPort é maior que maxPort.
Ao alterar o intervalo, você pode alinhar a alocação de portas de nós com as políticas de rede e firewall que sua organização já aplica. Ampliar o intervalo também aumenta o número de serviços que um único cluster pode suportar. Esse parâmetro é particularmente útil durante as migrações. Os aplicativos migrados para o Amazon EKS e os clientes que os chamam geralmente esperam serviços em portas fixas específicas. Quando essas portas estão fora do intervalo padrão, as opções usuais são modificar o aplicativo ou colocar um proxy na frente dele. Alinhar o intervalo com as portas que seus aplicativos já usam elimina esse trabalho; então, você pode mover workloads para o EKS sem reescrevê-las ou adicionar componentes de rede para manutenção.
Por que o intervalo é limitado em 10260 e 32767
O limite inferior de 10260 mantém a alocação de NodePort livre de portas que os componentes do sistema Kubernetes em seus nós já usam, incluindo a porta de integridade do kubelet (10248) e a porta de verificação de integridade do kube-proxy (10256).
O limite superior de 32767 mantém o intervalo livre do intervalo de portas efêmeras do Linux, que normalmente começa em 32768. Se NodePort estivesse dentro da faixa efêmera, o kernel poderia selecionar essa porta para uma conexão de saída do nó e entrar em conflito com o serviço.
Considerações sobre o intervalo de portas do nó de serviço
-
Os serviços existentes mantêm suas portas atribuídas. Se você restringir o intervalo, os serviços que já possuem uma porta fora do novo intervalo continuarão funcionando e o kube-proxy continuará roteando o tráfego para eles. O Amazon EKS não reatribui portas para serviços existentes quando o intervalo muda.
-
Recriar um serviço realoca sua porta. Se um serviço contendo uma porta fora do intervalo for excluído e recriado, essa porta não poderá mais ser atribuída. Planeje isso antes de restringir um intervalo do qual os serviços existentes dependem, especialmente se o processo de implantação recriar serviços em vez de atualizá-los.
-
Novas alocações fora do intervalo são rejeitadas. A criação ou atualização de um serviço que exige uma porta fora do intervalo configurado falha com um erro de validação do servidor da API.
-
As portas especificadas explicitamente também são validadas. Se um serviço especificar um valor
nodePortdiretamente em vez de permitir que o Kubernetes atribua um, essa porta deverá estar dentro do intervalo configurado. Uma solicitação de porta estática fora do intervalo é rejeitada, mesmo que a mesma porta fosse válida em um intervalo maior que você configurou anteriormente. -
O intervalo abrange todo o cluster. Você não pode configurar intervalos diferentes para namespaces diferentes.
Antes de alterar esse parâmetro, confirme se seus grupos de segurança e ACLs de rede permitem tráfego no novo intervalo e se o intervalo não está em conflito com as portas usadas por outros softwares em seus nós.
Considerações
Revise o seguinte antes de configurar os parâmetros avançados do ambiente de gerenciamento.
-
Escopo de todo o cluster: os parâmetros do ambiente de gerenciamento se aplicam a todo o cluster e a todas as workloads em execução nele. Você não pode definir seus escopos para namespaces ou workloads individuais. Teste as alterações nos parâmetros em um cluster de não produção antes de aplicá-las à produção.
-
Ambiente de gerenciamento provisionado necessário para o período de sincronização do Horizontal Pod Autoscaler e o limite de coleta de resíduos de pods encerrados: os parâmetros
horizontalPodAutoscalerSyncPeriodeterminatedPodGcThresholdsó estão disponíveis em clusters que usam o ambiente de gerenciamento provisionado do Amazon EKS. O Amazon EKS restringe os parâmetros que aumentam materialmente o consumo de recursos do ambiente de gerenciamento a clusters com capacidade de ambiente de gerenciamento pré-alocada. A configuração de qualquer um dos parâmetros em um cluster no modo de ambiente de gerenciamento padrão falha. Para usá-los, primeiro mova seu cluster para um nível de escalabilidade do ambiente de gerenciamento provisionado. Para obter mais informações, consulte Ambiente de gerenciamento provisionado do Amazon EKS. -
Restrição de saída para o período de sincronização do Horizontal Pod Autoscaler e o limite de coleta de resíduos de pods encerrados: se
horizontalPodAutoscalerSyncPeriodouterminatedPodGcThresholdestiver definido com um valor diferente do padrão, você não poderá mover o ambiente de gerenciamento do cluster do modo Provisionado de volta para o modo Padrão. Para retornar ao modo Padrão, primeiro redefina os dois parâmetros para seus padrões (15se12500) e, em seguida, altere o nível de escalabilidade do ambiente de gerenciamento parastandard. -
Retornando aos valores padrão: o Amazon EKS não fornece uma operação de redefinição dedicada, e omitir um campo de uma atualização mantém seu valor atual em vez de apagá-lo. Para retornar um parâmetro ao padrão, defina-o explicitamente com o valor padrão. Recupere o valor padrão com
DescribeClusterVersionspara a versão do Kubernetes que seu cluster executa. Para obter mais informações, consulte Configurar parâmetros avançados do ambiente de gerenciamento do Kubernetes. -
Semântica de atualização: as atualizações se mesclam com sua configuração existente. Somente os campos que você especifica são alterados e os campos que você omite mantêm seus valores atuais. Isso se aplica tanto em todos os componentes quanto em um único componente. Por exemplo, uma atualização que especifica somente a configuração do agendador deixa o gerenciador de controladores e a configuração do servidor de API inalterados.
-
Visualizando a configuração atual: a operação
describe-clusterretorna a configuração completa em execução no seu ambiente de gerenciamento, incluindo parâmetros que você não personalizou e seus valores padrão. -
Os padrões e os valores compatíveis podem mudar entre as versões do Kubernetes: os valores documentados neste tópico se aplicam às versões do Kubernetes disponíveis na publicação. Use
DescribeClusterVersionspara recuperar os valores atuais padrão e compatíveis para cada parâmetro e versão do Kubernetes. Consulte Configurar parâmetros avançados do ambiente de gerenciamento do Kubernetes. -
Os clusters existentes permanecem inalterados: o Amazon EKS não altera o comportamento dos clusters existentes. Todos os clusters continuam sendo executados com valores de parâmetros padrão até que você defina explicitamente um parâmetro.
-
As alterações não são aplicadas instantaneamente: uma alteração na configuração não está em vigor quando
UpdateClusterConfigretorna. O Amazon EKS aplica a nova configuração por meio de uma atualização contínua do seu ambiente de gerenciamento; portanto, aguarde alguns minutos para que a alteração entre em pleno vigor. O cluster retorna ao statusACTIVEquando a atualização estiver concluída. Você pode acompanhar o progresso usando a operação DescribeUpdate ou bloquear até que a alteração seja concluída usandoaws eks wait cluster-active. -
Auditabilidade: o EKS valida cada configuração antes de aplicá-la e registra as alterações no AWS CloudTrail.
-
Suporte de ferramentas: a configuração avançada do ambiente de gerenciamento do Kubernetes está disponível por meio do Console de gerenciamento da AWS, eksctl, AWS CLI, API Amazon EKS, AWS CloudFormation e AWS CDK na inicialização. O suporte para AWS Controllers for Kubernetes (ACK) e Terraform será lançado em breve.
-
Suporte à versão do Kubernetes: a configuração avançada do ambiente de gerenciamento do Kubernetes é compatível com clusters novos e existentes que executam o Kubernetes versão 1.31 ou posterior.
-
Suporte à Região da AWS: a configuração avançada do ambiente de gerenciamento do Kubernetes está disponível em todas as regiões comerciais da AWS, regiões do AWS GovCloud (EUA) e regiões da AWS China onde o Amazon EKS está disponível.
-
Preços: não há cobrança adicional pela configuração dos parâmetros do ambiente de gerenciamento. O uso de
horizontalPodAutoscalerSyncPeriodrequer um ambiente de gerenciamento provisionado, que é cobrado de acordo com a taxa horária do seu nível de escalabilidade. Para obter mais informações, consulte Preços do Amazon EKS.
Próximas etapas
-
Configurar parâmetros avançados do ambiente de gerenciamento do Kubernetes: definir e visualizar parâmetros do ambiente de gerenciamento usando aAWS CLI e o Console de gerenciamento da AWS.
-
Ambiente de gerenciamento provisionado do Amazon EKS: pré-alocar a capacidade do ambiente de gerenciamento para um alto desempenho previsível.
