Recomendações para uso de clusters ACK Pro de grande escala - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Guia de leitura

Este tópico destina-se a desenvolvedores e administradores de clusters ACK Pro. Ele apresenta recomendações gerais para o planejamento e uso de clusters de grande escala. Ajuste-as conforme o ambiente real do seu cluster e os requisitos do negócio.

Sob o shared responsibility model , o ACK gerencia a segurança dos componentes do plano de controle do cluster — incluindo os componentes do plano de controle do Kubernetes e o etcd — e a infraestrutura subjacente da Alibaba Cloud. Você é responsável por proteger suas aplicações de negócio e configurar seus recursos na cloud. Para mais detalhes, consulte Shared responsibility model .

Fase de planejamento

Cluster único versus múltiplos clusters

Um único cluster de grande escala reduz a sobrecarga de gerenciamento e melhora a utilização de recursos. No entanto, em alguns cenários de negócio, dividir os services em vários clusters faz mais sentido.

Considere o uso de múltiplos clusters quando:

Consideração	Quando dividir
Isolamento	Para evitar que problemas em um ambiente (por exemplo, testes) afetem a produção. Dividir clusters reduz o raio de impacto das falhas.
Distribuição geográfica	Implante clusters em regiões específicas para atender aos requisitos de disponibilidade e latência dos usuários finais.
Limites de tamanho de cluster único	O plano de controle gerenciado do ACK se adapta a clusters de diferentes escalas por meio de Auto Scaling e otimização de desempenho dos componentes. Contudo, a arquitetura do Kubernetes possui limites de desempenho inerentes, e um cluster superdimensionado pode comprometer a disponibilidade e o desempenho. Antes de planejar um cluster de grande escala, revise os limites de capacidade e os SLOs da comunidade. Em seguida, verifique sua cota no Quota Center. Se seus requisitos excederem os limites da comunidade ou do ACK, divida em múltiplos clusters.

Para gerenciar múltiplos clusters em tarefas como implantação de aplicações, gerenciamento de tráfego, distribuição de jobs e monitoramento, ative o fleet management.

Mantenha os clusters na versão mais recente

Versões mais recentes do Kubernetes incluem melhorias de estabilidade, desempenho e escalabilidade que beneficiam diretamente os clusters de grande escala. Exemplos notáveis:

v1.31: o kube-apiserver atende leituras consistentes para requisições List a partir de seu cache, reduzindo o acesso direto ao etcd e diminuindo a carga sobre ele. Consulte Leituras consistentes do cache.
v1.33: o kube-apiserver utiliza codificação em streaming (StreamingCollectionEncodingToJSON e StreamingCollectionEncodingToProtobuf) para operações List, reduzindo o uso de memória do kube-apiserver em escala. Consulte Respostas List em streaming.
v1.34: o kube-apiserver suporta cache de snapshots de versões históricas de recursos, melhorando o desempenho de leitura e escrita. Consulte Cache de API server com snapshot.

O ACK lança versões suportadas do Kubernetes em sincronia com a comunidade e descontinua o suporte a versões expiradas — incluindo o fim de novos recursos, correções de bugs e patches de segurança — oferecendo apenas suporte técnico limitado para essas versões. Acompanhe os anúncios de lançamento por meio de canais como documentação, avisos no console e mensagens internas, e atualize prontamente para evitar possíveis problemas de segurança e estabilidade no cluster.

Versões suportadas: Version guide
Considerações e procedimentos de atualização: Upgrade clusters
Atualização manual: Manually upgrade an ACK cluster
Atualização automática: Automatically upgrade a cluster

Utilize o plano de controle predefinido do ACK Pro

O plano de controle de um cluster ACK Pro utiliza uma arquitetura de Auto Scaling. Em clusters extremamente grandes ou sob picos repentinos de alta concorrência, a latência de resposta do scale-out elástico pode afetar a continuidade do negócio. O plano de controle predefinido do ACK Pro pré-aloca e fixa os recursos do plano de controle, mantendo a concorrência da API e a capacidade de agendamento de pods em um nível alto garantido. Essa configuração é ideal para treinamento e inferência de IA, clusters extremamente grandes e cargas de trabalho críticas.

Ao fixar os recursos do plano de controle e as configurações de base do API Server, o plano de controle predefinido do ACK Pro elimina a incerteza do scale-out elástico na origem, em vez de depender de mecanismos elásticos para compensar atrasos. Isso mantém o desempenho do plano de controle previsível em todos os momentos.

Para mais informações, consulte ACK Pro preset control plane.

Monitore os limites de recursos do cluster

Mantenha-se dentro dos seguintes limites para preservar a disponibilidade e o desempenho em clusters de grande escala.

Recurso	Limite	Ação
Tamanho do banco de dados etcd (DB Size)	Mantenha abaixo de 8 GB. Um banco de dados etcd superdimensionado degrada o desempenho, aumentando a latência de leitura e escrita de dados, o consumo de recursos do sistema e a latência de eleição. Além disso, torna a recuperação de services e dados mais difícil e demorada.	Mantenha o tamanho total do DB do etcd abaixo de 8 GB: Controle a quantidade total de recursos do cluster e limpe recursos não utilizados prontamente. Para recursos modificados frequentemente, mantenha o tamanho de cada objeto abaixo de 100 KB. Cada atualização de um par chave-valor no etcd gera uma nova versão histórica. Em cenários onde objetos grandes são atualizados com frequência, o etcd consome mais recursos para armazenar as versões históricas.
Dados totais por tipo de recurso no etcd	Mantenha abaixo de 800 MB por tipo. Se o volume total de um tipo de recurso for muito grande, clientes que listam todos os recursos desse tipo consomem recursos significativos do sistema. Em casos graves, o API server ou controladores personalizados podem falhar ao inicializar.	Ao definir um novo CustomResourceDefinition (CRD), estime previamente o número final de custom resources (CRs). Ao implantar charts com Helm, observe que o Helm cria releases para rastrear o status da implantação. Por padrão, o Helm armazena informações de release em Secrets. Em clusters de grande escala, armazenar grandes quantidades de informações de release em Secrets pode exceder o limite do Kubernetes para o tamanho total de Secrets. Use o backend de armazenamento SQL do Helm como alternativa.
Conexões e largura de banda do CLB do API Server	Largura de banda máxima: 5.120 Mbps; consulte CLB instances para limites de conexão. Exceder o limite de conexão ou largura de banda do CLB pode fazer com que os nós entrem no estado Not Ready.	Para clusters com 1.000 ou mais nós, utilize instâncias de Classic Load Balancer (CLB) com pagamento conforme o uso. Utilize o modo de conexão direta ENI (Elastic Network Interface) quando clusters de grande escala acessarem o service Kubernetes no namespace Default. Clusters criados após fevereiro de 2023 com Kubernetes 1.20 ou posterior usam conexão direta ENI por padrão. Consulte Access the API server using an internal endpoint.
Services por namespace	Mantenha abaixo de 5.000	O kubelet injeta informações de service como variáveis de ambiente nos pods. Muitos services por namespace causam lentidão ou falhas na inicialização dos pods. Defina `enableServiceLinks: false` no `podSpec` para desativar esse comportamento. Consulte Acessando o service.
Total de services no cluster	Mantenha abaixo de 10.000 no total; 500 para services do tipo LoadBalancer	O excesso de services aumenta as regras de rede processadas pelo kube-proxy, degradando seu desempenho. Para services do tipo LoadBalancer, o atraso de sincronização com o CLB pode chegar a minutos quando a quantidade é elevada.
Pods de backend por endpoint de service	Mantenha abaixo de 3.000	O kube-proxy em cada nó observa atualizações de Service para renovar as regras de rede locais. Quando um service possui muitos endpoints, seu objeto Endpoints torna-se grande, e cada atualização transfere tráfego significativo entre o API server e o kube-proxy. Quanto maior o cluster, mais pronunciado é o efeito de tempestade. Para resolver isso, o kube-proxy usa EndpointSlices por padrão em clusters v1.19 e posteriores. Utilize EndpointSlices em vez de Endpoints em clusters de grande escala — os EndpointSlices dividem os endpoints em partes menores, reduzindo os dados transmitidos por alteração. Se você usar um controlador personalizado que lê Endpoints diretamente, mantenha a contagem abaixo de 1.000 por objeto Endpoints; acima disso, o objeto é truncado automaticamente. Consulte Endpoints com excesso de capacidade.
Total de endpoints em todos os services	Mantenha abaixo de 64.000	O excesso de endpoints sobrecarrega o API Server e degrada o desempenho da rede.
Pods pendentes	Mantenha abaixo de 10.000	Uma alta contagem de pods pendentes faz com que o scheduler gere eventos repetidos, podendo desencadear tempestades de eventos.
Secrets em clusters com criptografia KMS V1	Mantenha abaixo de 2.000	Com o KMS V1, cada criptografia gera uma nova chave de criptografia de dados (DEK). Na inicialização ou atualização do cluster, todos os secrets são descriptografados sequencialmente. Muitos secrets retardam significativamente a inicialização. Consulte Encryption at rest for secrets using KMS.

Fase de configuração

Configure os parâmetros dos componentes do plano de controle

kube-apiserver

O kube-apiserver limita o tratamento de requisições concorrentes para proteger o plano de controle. Quando o limite é excedido, ele retorna HTTP 429 (Too Many Requests) e instrui os clientes a tentar novamente. Sem limitação no lado do servidor, requisições excessivas podem derrubar o plano de controle.

Mecanismos de limitação

Existem dois mecanismos de limitação dependendo da versão do Kubernetes:

Anterior à v1.18: Apenas limitação de concorrência máxima. Os parâmetros de inicialização --max-requests-inflight e --max-mutating-requests-inflight limitam a concorrência de requisições de leitura e escrita, respectivamente. Não há diferenciação de prioridade — requisições lentas e de baixa prioridade podem bloquear as urgentes. Clusters ACK Pro suportam a personalização desses parâmetros. Consulte Customize the parameters of control plane components.

v1.18 e posterior: A API Priority and Fairness (APF) fornece gerenciamento de tráfego granular. A APF classifica e isola requisições por prioridade, garantindo que as de alta prioridade sejam processadas primeiro, mantendo a justiça. A APF entrou em Beta na v1.20 e está ativada por padrão. Em clusters executando v1.20 ou posterior, a capacidade total de requisições simultâneas equivale à soma de --max-requests-inflight e --max-mutating-requests-inflight. A APF usa dois tipos de CRD para alocar essa capacidade.

PriorityLevelConfiguration: Define níveis de prioridade e a proporção da concorrência total que cada nível recebe.
FlowSchema: Mapeia requisições recebidas para um PriorityLevelConfiguration.

O kube-apiserver mantém esses objetos automaticamente. Para visualizar a configuração atual, consulte o PriorityLevelConfiguration:

O ACK adiciona ack-system-leader-election e ack-default ao FlowSchema para componentes principais do ACK. As demais entradas são consistentes com os padrões da comunidade Kubernetes.

kubectl get PriorityLevelConfiguration
# Expected output
NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
catch-all         Limited   5                          <none>   <none>     <none>             4m20s
exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
global-default    Limited   20                         128      6          50                 4m20s
leader-election   Limited   10                         16       4          50                 4m20s
node-high         Limited   40                         64       6          50                 4m20s
system            Limited   30                         64       6          50                 4m20s
workload-high     Limited   40                         128      6          50                 4m20s
workload-low      Limited   100                        128      6          50                 4m20s

Visualize o FlowSchema:

kubectl get flowschemas
# Expected output
NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
exempt                         exempt            1                    <none>                4d18h   False
probes                         exempt            2                    <none>                4d18h   False
system-leader-election         leader-election   100                  ByUser                4d18h   False
endpoint-controller            workload-high     150                  ByUser                4d18h   False
workload-leader-election       leader-election   200                  ByUser                4d18h   False
system-node-high               node-high         400                  ByUser                4d18h   False
system-nodes                   system            500                  ByUser                4d18h   False
ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
ack-default                    workload-high     800                  ByNamespace           4d18h   False
kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
service-accounts               workload-low      9000                 ByUser                4d18h   False
global-default                 global-default    9900                 ByUser                4d18h   False
catch-all                      catch-all         10000                ByUser                4d18h   False

Respondendo à limitação

Detecte a limitação verificando respostas HTTP 429 ou monitorando a métrica apiserver_flowcontrol_rejected_requests_total. Quando ocorrer limitação:

Utilize o plano de controle predefinido do ACK Pro: Um plano de controle predefinido fixa os recursos de base do API Server e fornece diretamente capacidade de processamento de alta concorrência garantida. Para mais informações, consulte ACK Pro preset control plane.
Ajuste o PriorityLevelConfiguration:
- Para requisições que não devem ser limitadas, crie um novo FlowSchema e mapeie-o para um nível de alta prioridade, como workload-high ou exempt. Use exempt com cautela, pois requisições isentas não são limitadas pela APF. Você também pode criar um novo PriorityLevelConfiguration com maior concorrência para requisições de alta prioridade.
- Para clientes lentos que causam alta carga no API Server, crie um FlowSchema que mapeie essas requisições para um PriorityLevelConfiguration de baixa concorrência.

kube-controller-manager e kube-scheduler

Após atualizar para o plano de controle predefinido do ACK Pro, os parâmetros relacionados a QPS que o kube-controller-manager e o kube-scheduler usam para se comunicar com o API Server são ajustados automaticamente com base no nível selecionado.

kubelet

O valor padrão de kube-api-qps é 5 e o valor padrão de kube-api-burst é 10, suficientes para a maioria dos clusters. Se você observar lentidão nas atualizações de status dos pods, atrasos no agendamento ou montagem lenta de volumes persistentes, aumente esses valores. Consulte Customize kubelet configurations for a node pool.

Importante

Aumentar o QPS do kubelet eleva a taxa de comunicação de cada nó com o API Server. Aumente o valor gradualmente e monitore o desempenho do API Server para evitar sobrecarga no plano de controle.
O ACK limita as atualizações paralelas do kubelet a no máximo 10 nós por lote por pool de nós para proteger a estabilidade do plano de controle durante rollouts.

Planeje cargas de trabalho de grande escala

Desative a montagem automática de tokens de ServiceAccount para pods que não precisam de acesso à API

O kubelet estabelece uma conexão Watch persistente para cada secret montado em um pod. Um grande número de conexões Watch degrada o desempenho do plano de controle.

Antes do Kubernetes v1.22: Quando nenhum ServiceAccount é especificado, o Kubernetes monta automaticamente um secret para o ServiceAccount padrão. Para jobs em lote e pods de aplicação que não acessam o API Server, defina automountServiceAccountToken: false para pular essa montagem. Isso evita a criação desnecessária de secrets e conexões Watch. Consulte Desativar montagem automática de credenciais da API.
Kubernetes v1.22 e posterior: Utilize a API TokenRequest para obter tokens de curta duração e rotação automática, montados como um volume projetado. Isso melhora a segurança e reduz o número de conexões Watch mantidas pelo kubelet. Consulte Use ServiceAccount token volume projection.

Controle a quantidade e o tamanho dos objetos do Kubernetes

Limpe recursos não utilizados — ConfigMaps, Secrets, PVCs — prontamente para reduzir a sobrecarga do sistema e manter o etcd enxuto.

Limite o histórico de implantações: Defina revisionHistoryLimit com um valor menor para controlar quantos ReplicaSets antigos o Kubernetes retém. O padrão é 10. Em clusters com muitas implantações atualizadas frequentemente, uma retenção alta de histórico aumenta a sobrecarga de gerenciamento do kube-controller-manager. Consulte revisionHistoryLimit.
Limpe jobs concluídos automaticamente: Utilize ttlSecondsAfterFinished para excluir jobs concluídos e seus pods após um período especificado. Isso previne o acúmulo de objetos de job em clusters que executam muitos CronJobs. Consulte Controlador TTL para recursos finalizados.

Configure limites de recursos adequados para componentes baseados em informer

Componentes baseados em informer (como controladores e kube-scheduler) mantêm um cache local dos recursos que observam. O uso de memória escala com a quantidade e o tamanho desses recursos.

Em clusters de grande escala, preste atenção especial ao consumo de memória desses componentes para evitar erros de falta de memória (OOM). Quando um componente fica sem memória, ele é encerrado e reiniciado. Cada reinicialização dispara um novo ciclo List-Watch, pressionando adicionalmente o API Server. Reinicializações frequentes criam um ciclo que degrada o plano de controle.

Aumente os limites de memória dos componentes baseados em informer para corresponder à escala real de recursos que eles estão gerenciando.

Configure webhooks e API services adequadamente

Se webhooks ou API services estiverem configurados para o cluster, requisições para recursos específicos passam pelos servidores de webhook e API service. Respostas lentas de servidores personalizados de webhook ou API service fazem com que as requisições se acumulem no API Server, retardando as respostas. Monitore a utilização de recursos dos servidores de webhook e API service e escale-os horizontalmente a tempo.

Fase de execução

Planeje as taxas de dimensionamento

O plano de controle geralmente sofre pouca pressão durante operações estáveis, mesmo em clusters grandes. O risco vem de mudanças rápidas e em grande escala — criar ou excluir muitos recursos de uma vez, ou dimensionar muitos nós simultaneamente.

Por exemplo, um cluster de 5.000 nós executando cargas de trabalho estáveis pode apresentar pouca pressão no plano de controle. Mas um cluster de 1.000 nós que cria 10.000 jobs de curta duração em um minuto, ou escala horizontalmente 2.000 nós simultaneamente, pode levar o plano de controle aos seus limites.

Importante

Os números a seguir são diretrizes de referência, não limites rígidos. Muitos fatores afetam a capacidade do plano de controle. Sempre dimensione gradualmente: aumente a taxa somente após confirmar que o plano de controle está respondendo normalmente.

Dimensionamento de nós:

Para clusters com mais de 2.000 nós, ao dimensionar manualmente através de pools de nós:

Pool de nós único, operação única: no máximo 100 nós
Em múltiplos pools de nós simultaneamente: no máximo 300 nós no total

Dimensionamento de pods:

Quando um pod está associado a um service, cada evento de dimensionamento atualiza os Endpoints ou EndpointSlice e envia essa atualização para todos os nós — criando um evento de propagação de dados em todo o cluster. Em clusters grandes, esse efeito é amplificado.

Para clusters com mais de 5.000 nós:

Pods não associados a um endpoint de service: QPS de atualização ≤ 300/s
Pods associados a um endpoint de service: QPS de atualização ≤ 10/s

Para implantações que utilizam a estratégia Rolling Update, defina valores menores para maxUnavailable e maxSurge para reduzir a taxa de substituição de pods.

Otimize os padrões de acesso do cliente

À medida que a contagem de recursos do cluster cresce, requisições frequentes ao API Server amplificam a carga do plano de controle e podem causar falhas em cascata. Siga estas diretrizes ao construir controladores ou ferramentas que acessam o API Server.

Utilize informers para acesso a dados em cache:

Utilize informers do client-go para ler recursos de um cache local em vez de emitir requisições List diretas ao API Server.
Informers mantêm uma única conexão Watch e atendem requisições de leitura localmente, reduzindo significativamente a carga do API Server.

Otimize requisições diretas ao API Server:

**Defina resourceVersion=0 em requisições List** para ler do cache do API Server em vez de consultar o etcd. Isso reduz as idas e vindas entre API Server e etcd, acelerando as respostas:
```
k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"})
```
Utilize seletores de rótulos e seletores de campos para restringir o escopo das requisições List e reduzir o tamanho do payload de resposta. Nota: o etcd é um armazenamento chave-valor e não consegue filtrar por rótulo ou campo — o API Server realiza essa filtragem a partir de seu cache. Sempre combine seletores com resourceVersion=0 para evitar acessar o etcd diretamente.
Utilize protobuf para recursos não-CRD. O protobuf usa menos memória e largura de banda que JSON. Especifique múltiplos tipos de conteúdo no cabeçalho Accept para retornar ao JSON quando o protobuf não estiver disponível:
```
Accept: application/vnd.kubernetes.protobuf, application/json
```
Consulte Representações alternativas de recursos.

Adote um design de controlador centralizado:

Evite implantar controladores independentes em cada nó que observem todo o estado do cluster. Na inicialização, todos esses controladores emitem requisições List simultâneas para sincronizar o estado, o que pode derrubar o plano de controle.

Em vez disso, execute uma ou um pequeno grupo de instâncias de controladores gerenciados centralmente para todo o cluster. Um controlador centralizado emite uma única requisição List na inicialização e mantém o número mínimo de conexões Watch, reduzindo drasticamente a pressão sobre o API Server.

Fase de observabilidade: monitore métricas do plano de controle

Utilize o painel de monitoramento dos componentes do plano de controle para acompanhar métricas principais e detectar problemas precocemente. Consulte Control plane component monitoring.

Uso de recursos do plano de controle

É possível visualizar o uso de recursos de todos os componentes do plano de controle. As métricas relacionadas estão descritas na tabela a seguir.

Métrica	PromQL	Descrição
Uso de memória	`memory_utilization_byte{container="kube-apiserver"}`	Uso de memória do API Server, em bytes
Uso de CPU	`cpu_utilization_core{container="kube-apiserver"}*1000`	Uso de CPU do API Server, em milicores
Concorrência de requisições da API	`sum(apiserver_flowcontrol_current_executing_seats)`	Concorrência do API Server, em seats
Taxa de agendamento de pods	`rate(scheduler_schedule_attempts_total{result="scheduled"}[2m])`	Taxa de agendamento de pods, em pods/s
Tamanho do banco de dados etcd	`max(etcd_mvcc_db_total_size_in_use_in_bytes)`	Tamanho do banco de dados etcd, em bytes

kube-apiserver

Para a lista completa de métricas e instruções de visualização, consulte kube-apiserver component monitoring metrics.

Contagem de objetos de recurso:

Métrica	PromQL	Observações
Contagem de objetos de recurso	`max by(resource)(apiserver_storage_objects)`	Kubernetes 1.22 e posterior
	`max by(resource)(etcd_object_counts)`	Kubernetes 1.22 e anterior; ambas as métricas coexistem na v1.22 para compatibilidade

Latência de requisição:

Métrica	PromQL	Descrição
Latência de requisição GET	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log	proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))`	Tempo de resposta GET por pod do API Server, recurso e escopo
Latência de requisição LIST	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le))`	Tempo de resposta LIST por pod do API Server, recurso e escopo
Latência de requisição de escrita	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET	WATCH	LIST	CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))`	Tempo de resposta de requisições de mutação por verbo, recurso e escopo

Limitação de requisições:

Métrica	PromQL	Descrição
Taxa de limitação de requisições	`sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)`	Taxa de limitação para requisições de leitura; `No data` ou `0` indica ausência de limitação
	`sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)`	Taxa de limitação para requisições de mutação

kube-scheduler

Para a lista completa de métricas e instruções de visualização, consulte kube-scheduler component monitoring metrics.

Pods pendentes:

Métrica	PromQL	Descrição
Pods pendentes no scheduler	`scheduler_pending_pods{job="ack-scheduler"}`	Detalhamento por tipo: `unschedulable` (não agendável), `backoff` (falhou e aguardando nova tentativa), `active` (pronto para agendar)

Latência de requisição:

Métrica	PromQL	Descrição
Latência de requisição ao kube-apiserver	`histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le))`	Tempo entre o envio da requisição pelo kube-scheduler e o retorno da resposta pelo kube-apiserver, por verbo e URL

kube-controller-manager

Para a lista completa de métricas e instruções de visualização, consulte kube-controller-manager component monitoring metrics.

Workqueue:

Métrica	PromQL	Descrição
Profundidade da workqueue	`sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name)`	Taxa de variação no comprimento da workqueue durante o intervalo especificado
Atraso de processamento da workqueue	`histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le))`	Tempo que os eventos passam aguardando na workqueue

etcd

Para a lista completa de métricas e instruções de visualização, consulte etcd component monitoring metrics.

Contagem de pares chave-valor:

Métrica	PromQL	Descrição
Contagem total de KV	`etcd_debugging_mvcc_keys_total`	Número total de pares chave-valor no cluster etcd

Tamanho do banco de dados:

Métrica	PromQL	Descrição
Tamanho em disco	`etcd_mvcc_db_total_size_in_bytes`	Tamanho total do banco de dados backend do etcd
Uso do banco de dados	`etcd_mvcc_db_total_size_in_use_in_bytes`	Tamanho real em uso do banco de dados backend do etcd

Documentação relacionada

Cotas e limites de cluster: Quotas and limits
Planejamento de rede: Plan CIDR blocks for an ACK managed cluster
Configurações de cargas de trabalho de alta confiabilidade: Recommended workload configurations
Capacidade do plano de controle para clusters de escala extremamente grande: ACK Pro preset control plane pré-aloca e fixa recursos do plano de controle para garantir concorrência de API e capacidade de agendamento de pods determinísticas.
Solução de problemas de cluster: Solução de problemas e FAQ about cluster management