DEV Community

Celso Nery
Celso Nery

Posted on

Kubernetes: Instalando o Metrics Server para Monitorar Nós e Pods

#kubernetes #k8s #monitoring #devops

🇺🇸 English version here.

Comandos como kubectl top nodes ou kubectl top pods não funcionam por padrão em um cluster Kubernetes recém-criado — e o autoscaler horizontal (HPA), usado para escalar aplicações automaticamente com base em CPU, também depende de uma fonte de métricas para funcionar. O componente responsável por fornecer esses dados é o Metrics Server.

Neste artigo, mostro como instalar o Metrics Server e, principalmente, como resolver o problema mais comum ao instalá-lo em clusters on-premise: a falta de certificados TLS válidos entre os nós.

Instalando o Metrics Server

A instalação padrão é feita aplicando o manifesto oficial do projeto diretamente no cluster:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Enter fullscreen mode Exit fullscreen mode

Isso cria um Deployment na namespace kube-system, responsável por coletar periodicamente métricas de uso de CPU e memória de todos os nós e pods do cluster.

Verificando se está funcionando

Primeiro, confirme que o pod do Metrics Server subiu corretamente:

kubectl get pods --all-namespaces
Enter fullscreen mode Exit fullscreen mode

Procure por um pod com nome parecido com metrics-server-xxxxxxxxxx-xxxxx e confira se o status está Running.

Depois, teste os comandos que dependem dele:

kubectl top nodes
Enter fullscreen mode Exit fullscreen mode

Ou:

kubectl top pods --all-namespaces
Enter fullscreen mode Exit fullscreen mode

Se ambos retornarem dados de uso de CPU e memória, está tudo funcionando.

Quando não funciona: o problema do TLS em clusters on-premise

Em clusters gerenciados na nuvem, os nós geralmente têm certificados válidos reconhecidos pelo Metrics Server. Mas em ambientes on-premise, é comum o Metrics Server não conseguir se comunicar com o kubelet de cada nó, ficando preso em erro (o pod fica Running, mas os comandos top retornam erro ou "não encontrado").

Isso acontece porque, por padrão, o Metrics Server tenta validar o certificado TLS do kubelet — e, sem uma cadeia de certificação configurada corretamente entre os nós, essa validação falha.

Corrigindo manualmente o manifesto

Para contornar isso, baixe o manifesto localmente em vez de aplicá-lo direto pela URL:

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Enter fullscreen mode Exit fullscreen mode

Edite o arquivo:

vim components.yaml
Enter fullscreen mode Exit fullscreen mode

E ajuste os argumentos do container metrics-server, adicionando a flag --kubelet-insecure-tls (que desativa a validação estrita do certificado do kubelet) e outras flags de compatibilidade:

      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=10250
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls
        image: registry.k8s.io/metrics-server/metrics-server:v0.7.2
        imagePullPolicy: IfNotPresent
Enter fullscreen mode Exit fullscreen mode

⚠️ A flag --kubelet-insecure-tls desativa a verificação do certificado do kubelet — uma solução aceitável para ambientes internos e de laboratório, mas que reduz a segurança da comunicação. Para produção, o ideal é configurar corretamente a cadeia de certificados do cluster em vez de contornar a validação.

Depois de editar, aplique o manifesto atualizado:

kubectl apply -f components.yaml
Enter fullscreen mode Exit fullscreen mode

E teste novamente:

kubectl top nodes
kubectl top pods --all-namespaces
Enter fullscreen mode Exit fullscreen mode

Por que isso importa

Além de facilitar o diagnóstico manual do cluster (ver rapidamente quais nós ou pods estão consumindo mais recursos), o Metrics Server é um pré-requisito para o funcionamento do Horizontal Pod Autoscaler (HPA) — recurso que permite escalar automaticamente o número de réplicas de uma aplicação com base no uso de CPU, como vimos ao configurar o autoscale de um Deployment em artigos anteriores desta jornada com Kubernetes. Sem o Metrics Server funcionando, o comando kubectl get hpa mostra o uso de recursos como <unknown>, e o autoscaler simplesmente não escala nada.

Top comments (0)