Servidor de Métricas do Kubernetes

Ao ativar o complemento de cluster do Kubernetes Metrics Server, você pode informar os seguintes pares de chave/valor como argumentos

Observe que, para usar o Kubernetes Metrics Server como um complemento de cluster, você também precisa implantar o cert-manager (como um produto autônomo ou como um complemento de cluster). Se você implantar o cert-manager como um produto independente, defina o argumento de configuração skipAddonDependenciesCheck como true.

Argumentos de Configuração Comuns à maioria dos Complementos de Cluster


Chave (API e CLI)	Nome para Exibição da Chave (Console)	Descrição	Obrigatório/Opcional	Valor Padrão	Valor de Exemplo
`affinity`	afinidade	Um grupo de regras de programação de afinidade. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Operador de GPU Nvidia Possíveis equivalentes: Descoberta de Recursos do Nó, use `master.affinity` Operador de Rede NVIDIA, use `operator.affinity` Driver SMB CSI, use `contoller.affinity` Operador de GPU AMD, use `controllerManager.affinity`	Opcional	nulo	nulo
`nodeSelectors`	seletores de nó	Você pode usar seletores de nó e labels de nó para controlar os nós de trabalho nos quais os pods complementares são executados. Para que um pod seja executado em um nó, o seletor de nós do pod deve ter a mesma chave/valor do label do nó. Defina `nodeSelectors` como um par de chave/valor que corresponda ao seletor de nós do pod e ao label do nó de trabalho. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Operador de GPU NVIDIA SMB do Driver CSI Possíveis equivalentes: Descoberta de Recursos do Nó, use `worker.nodeSelector` Operador de Rede NVIDIA, use `operator.nodeSelectors` Operador de GPU AMD, use `selector` ou `controllerManager.nodeSelector`	Opcional	nulo	`{"foo":"bar", "foo2": "bar2"}` O pod só será executado em nós que tenham o label `foo=bar` ou `foo2=bar2`.
`numOfReplicas`	numOfReplicas	O número de réplicas da implantação do complemento. Não utilizado por: Plug-in de GPU AMD Operador de GPU NVIDIA Operador de Rede NVIDIA SMB do Driver CSI Possíveis equivalentes: CoreDNS, use `nodesPerReplica` Descoberta de Recursos do Nó, use `master.replicaCount` Operador de GPU AMD, use `controllerManager.replicas`	Obrigatório	`1` Cria uma réplica da implantação do complemento por cluster.	`2` Cria duas réplicas da implantação do complemento por cluster.
`rollingUpdate`	rollingUpdate	Controla o comportamento desejado de atualização incremental por maxSurge e maxUnavailable. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Descoberta de Recurso do Nó Operador de Rede NVIDIA SMB do Driver CSI Possíveis equivalentes: Operador de GPU NVIDIA, use `daemonsets.rollingUpdate.maxUnavailable` Operador de GPU AMD, use `upgradePolicy` em `devicePlugin`, `metricsExporter`, `testRunner`, `configManager` ou `draDriver`	Opcional	nulo	nulo
`tolerations`	tolerâncias	Você pode usar taints e tolerations para controlar os nós de trabalho nos quais os pods complementares são executados. Para que um pod seja executado em um nó que tenha uma taint, o pod deve ter uma tolerância correspondente. Defina `tolerations` como um par de chave/valor que corresponda à tolerância do pod e à mancha do nó de trabalho. Formato JSON em texto simples ou codificado em Base64. Possíveis equivalentes: Descoberta de Recursos do Nó, use `master.tolerations` e/ou `worker.tolerations` Operador de GPU NVIDIA, use `daemonsets.tolerations` Operador de Rede NVIDIA, use `operator.tolerations` Driver SMB CSI, use `controller.tolerations` Operador de GPU AMD, usar tolerações em `devicePlugin`, `metricsExporter`, `testRunner`, `configManager`, `draDriver` ou `controllerManager`	Opcional	nulo	`[{"key":"tolerationKeyFoo", "value":"tolerationValBar", "effect":"noSchedule", "operator":"exists"}]` Somente pods que têm essa tolerância podem ser executados em nós de trabalho que têm a mancha `tolerationKeyFoo=tolerationValBar:noSchedule`.
`topologySpreadConstraints`	topologySpreadConstraints	Como distribuir pods correspondentes entre a topologia fornecida. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Descoberta de Recurso do Nó Operador de GPU NVIDIA Operador de Rede NVIDIA SMB do Driver CSI AMD GPU Operator	Opcional	nulo	nulo

Argumentos de Configuração Específicos para esta Extensão de Cluster


Chave (API e CLI)	Nome para Exibição da Chave (Console)	Descrição	Obrigatório/Opcional	Valor Padrão	Valor de Exemplo
`metrics-server.ContainerResources`	recursos de contêiner de métricas-servidor	Você pode especificar as quantidades de recursos solicitadas pelos contêineres de complementos e definir limites de uso de recursos que os contêineres de complementos não podem exceder. Formato JSON em texto simples ou codificado em Base64.	Opcional	nulo	`{"limits": {"cpu": "500m", "memory": "200Mi" }, "requests": {"cpu": "100m", "memory": "100Mi"}}` Crie contêineres complementares que solicitem 100 mililitros de CPU e 100 mebibytes de memória. Limite os contêineres complementares a 500 milicores de CPU e 200 mebibytes de memória.
`skipAddonDependenciesCheck`	skipAddonDependenciesCheck	Verificar se outros complementos necessários foram implantados (como o complemento cert-manager).	Opcional	nulo	`true`

Considerações sobre Clusters Grandes

A tabela a seguir descreve considerações para configurar este complemento de cluster em clusters grandes.


Nome do Argumento	Número wrt de Atribuições dos Nós	Descrição	À medida que o tamanho do cluster aumenta	Riscos	Recomendação
`metrics-server.ContainerResources`	S	Define solicitações e limites de CPU e memória para o pod do Metrics Server.	As operações de raspagem aumentam linearmente porque o Metrics Server coleta métricas de cada nó. O uso da CPU aumenta para coleta e processamento de métricas. O uso da memória aumenta para manter métricas agregadas. As métricas podem demorar mais para ficar disponíveis.	Se os recursos forem subdimensionados: O pod do Metrics Server pode ser encerrado porque excede seu limite de memória. A limitação da CPU pode causar sucatas lentas ou perdidas. A API de Métricas pode fornecer dados obsoletos ou ficar indisponível. As decisões do Horizontal Pod Autoscaler podem ser atrasadas ou imprecisas.	Aumente os recursos de CPU e memória na proporção do número de nós. Aumente a CPU para suportar raspagem e processamento de métricas. Aumente a memória para suportar agregação de métricas. Valide o dimensionamento de recursos por meio de testes de carga para clusters com mais de 5.000 nós.
`numOfReplicas`	N	Controla o número de pods do Servidor de Métricas.	Cada réplica raspa cada nó. O Metrics Server não divide a carga de trabalho de raspagem entre réplicas, portanto, réplicas adicionais fornecem alta disponibilidade em vez de capacidade de processamento adicional.	Réplicas adicionais geram tráfego de raspagem duplicado. Aumentar o número de réplicas não melhora o throughput de raspagem.	Use duas ou três réplicas para fornecer alta disponibilidade. Não aumente o número de réplicas para melhorar o desempenho.
`affinity` / `nodeSelectors` / `tolerations`	N	Controlar o posicionamento dos pods do Metrics Server.	Metrics Server é um componente crítico do plano de controle. Seu posicionamento afeta a estabilidade do serviço e a disponibilidade de métricas de recursos.	Se esses argumentos não forem configurados adequadamente: Os pods podem ser executados em nós instáveis ou com restrição de recursos. Os pods podem ser reiniciados. O desempenho pode ser reduzido. Falhas intermitentes podem ocorrer na disponibilidade da métrica.	Execute o Metrics Server em nós estáveis com baixa rotatividade e recursos suficientes. Preferem infraestrutura dedicada ou pools de nós do sistema. Configure tolerações quando os nós de destino estiverem contaminados.
`rollingUpdate`	N	Controla a estratégia de atualização de implantação do Metrics Server.	O tempo de inatividade do Metrics Server torna a API de Métricas indisponível, impede que o Horizontal Pod Autoscaler opere corretamente e faz com que os comandos `kubectl top` falhem.	Se este argumento não estiver configurado corretamente: Todas as réplicas podem ser reiniciadas ao mesmo tempo. O pipeline de métricas pode ficar temporariamente indisponível.	Configure `maxUnavailable` com cuidado. Certifique-se de que pelo menos uma réplica do Metrics Server permaneça ativa durante uma atualização. Use uma estratégia de implementação gradual.
`topologySpreadConstraints`	N	Controla como os pods do Metrics Server são distribuídos entre nós, domínios de disponibilidade e outros domínios de falha.	Impede que todas as réplicas sejam executadas no mesmo nó ou no mesmo domínio de disponibilidade. Melhora a resiliência a falhas de nó e domínio de disponibilidade. Adiciona uma pequena quantidade de complexidade de programação.	Se as restrições de distribuição de topologia não estiverem configuradas: Todas as réplicas podem ser executadas no mesmo nó ou no mesmo domínio de disponibilidade. Uma única falha pode causar uma interrupção completa das métricas.	Distribua réplicas entre domínios de disponibilidade sempre que possível. Execute réplicas em nós diferentes. Mantenha uma distribuição uniforme para fornecer alta disponibilidade.
`skipAddonDependenciesCheck`	N	Controla se a validação de dependência é ignorada durante a instalação da extensão.	Esse argumento não tem impacto direto no desempenho ou na escalabilidade, mas afeta a confiabilidade da implantação. No OKE, o Servidor de Métricas depende de componentes como o Gerenciador de Certificados.	Se a validação de dependência for ignorada: A extensão pode ser instalada sem as dependências necessárias. Talvez o pipeline de métricas não funcione. Podem ocorrer falhas de runtime. A solução de problemas pode ser mais difícil em um cluster grande.	Mantenha a validação de dependência ativada. Ignore a validação somente em ambientes controlados ou de teste ou quando todas as dependências tiverem sido validadas manualmente.

Documentação do Oracle Cloud Infrastructure

Servidor de Métricas do Kubernetes