Ir para o conteúdo

Kubernetes

Abrir na plataforma

Página dedicada para acompanhar clusters Kubernetes. Diferente de Docker, onde a unidade monitorada é o host que roda o engine, aqui a unidade é o cluster inteiro: o monitoramento entende workloads, deployments, pods e nós como parte de um mesmo objeto lógico.

A navegação, a aba Configuração e a aba Alertas seguem o mesmo modelo de Hosts. O que muda é o cadastro (que envolve instalar um Helm chart no cluster) e o conteúdo dos painéis de métricas.

A lista

Lista de clusters Kubernetes com um cluster cadastrado

Acessada por Infraestrutura → Kubernetes. Mostra os clusters cadastrados no tenant, com colunas:

Coluna O que mostra
Tipo Distro do cluster (vanilla, EKS, AKS, GKE, OpenShift).
Nome do Cluster Como aparece na plataforma.
Tags Etiquetas atribuídas ao cluster.
Endpoint URL da API do Kubernetes que a plataforma consulta.
Disponibilidade Indicador da última checagem de saúde.
Status Estado geral consolidado.
Ações Menu de operações rápidas.

Em um tenant novo a lista vem vazia. Use Adicionar Cluster no topo para começar (veja Adicionar um cluster).

Adicionar um cluster

Diferente de Docker, aqui o monitoramento é feito por um Helm chart instalado dentro do cluster, que abre a coleta e devolve um token que você cola na plataforma. O fluxo todo cabe em sete passos.

Pré-requisitos

Antes de começar, garanta que você tem:

  • Acesso administrativo ao cluster Kubernetes (permissão para criar namespace, ServiceAccount, ClusterRole e ClusterRoleBinding).
  • kubectl configurado e apontando para o cluster (kubectl get nodes deve responder).
  • Helm 3.x instalado na máquina onde você vai rodar a instalação.
  • Rede entre cluster e SpecialOne funcionando, seja porque a plataforma alcança o kube-apiserver, seja porque o coletor da SpecialOne está em uma rede com acesso a ele.

Passo a passo

Modal Adicionar Cluster com campos e instruções do Helm chart

1. Abrir o cadastro na plataforma

Em Infraestrutura → Kubernetes, clique em Adicionar Cluster.

2. Preencher Nome do Cluster

Como você quer ver o cluster na plataforma. Use um nome que dê contexto rápido, por exemplo prod-eks-sa-east-1 ou homolog-rancher-cliente-x.

3. Preencher API Endpoint

URL da API do Kubernetes. Você tem duas opções:

  • Endpoint interno (https://kubernetes.default.svc.cluster.local:443): se a SpecialOne tem coletor dentro do mesmo cluster ou em um cluster vizinho com acesso à rede do kube-apiserver. Mais rápido e dispensa expor o control plane.
  • Endpoint externo do control plane: se o coletor está em outra rede. Precisa estar acessível e ter o certificado correto.

4. Baixar o Helm chart

Na própria modal há o botão Baixar Helm Chart que entrega um .tgz (ex: specialone-helm-chart-1.3.4.tgz).

5. Instalar o chart no cluster

Abra o terminal na máquina com kubectl e helm apontando para o cluster, vá até a pasta onde o .tgz foi salvo e rode:

helm install specialone ./specialone-helm-chart-1.3.4.tgz \
  -n specialone \
  --create-namespace

O chart cria o namespace specialone, uma ServiceAccount com permissões de leitura, e os pods que coletam métricas e eventos do cluster. Verifique se subiu:

kubectl get pods -n specialone

Os pods devem estar Running.

Modal de instruções com pré-requisitos e comandos

A modal Instruções de Instalação do Helm Chart (acessível pelo botão Instruções Completas na tela de cadastro) traz esses mesmos comandos prontos para copiar.

6. Recuperar o Service Account Token

Ainda no cluster, rode:

kubectl get secret -n specialone specialone-token \
  -o jsonpath='{.data.token}' | base64 -d

O comando devolve uma string longa (o token). Copie tudo.

7. Voltar à plataforma, colar o token e salvar

Cole no campo Service Account Token da modal de cadastro e clique em Adicionar Cluster.

Após salvar

O cluster aparece na lista da página de Kubernetes. Nos próximos minutos:

  • A coluna Disponibilidade vira verde quando a plataforma confirma comunicação com o kube-apiserver.
  • A coluna Status muda para refletir o estado consolidado.
  • As métricas do cluster começam a popular e os alertas configurados pelo perfil padrão (CrashLoopBackOff, NotReady, etc) ficam ativos.

Reinstalar o chart com nova versão

Quando a SpecialOne liberar uma versão nova do chart, o caminho recomendado é baixar o novo .tgz pela própria modal de cadastro e rodar helm upgrade specialone ./specialone-helm-chart-X.Y.Z.tgz -n specialone. O cluster continua aparecendo na lista, sem precisar refazer cadastro.

O detalhe do cluster

Ao clicar em um cluster cadastrado você entra no detalhe com abas no mesmo formato de Docker e Hosts: Métricas, Workloads, Alertas e Configuração. O conteúdo das duas primeiras é específico de Kubernetes:

  • Métricas: saúde geral do cluster (nós ready, capacidade total de CPU e memória, pods em estado anormal, restart count global) e gráficos por namespace.
  • Workloads: lista de deployments, statefulsets, daemonsets e jobs, com estado (replicas desejadas/atuais), idade e namespace. É a entrada natural para investigar "qual app está com pod travado".

Aba Alertas e aba Configuração

As duas seguem o mesmo modelo de qualquer recurso na plataforma. Para evitar repetir, consulte a página de Hosts:

  • Aba Configuração: atributos do cluster, perfis de monitoramento aplicados, métricas coletadas e alertas configurados.
  • Editar um alerta no host: como funciona a cópia personalizada quando você ajusta um alerta herdado de perfil.

A diferença prática é só o conjunto de perfis aplicáveis. Tipicamente um cluster recebe perfis pensados para o control plane, os componentes de rede e os recursos por namespace.

Alertas típicos de cluster

Os perfis padrão da plataforma cobrem situações comuns que você vai ver na aba Alertas Configurados do cluster:

  • Pods em CrashLoopBackOff ou ImagePullBackOff em um namespace.
  • Deployments com réplicas abaixo do desejado por tempo prolongado.
  • Nó não-ready (NotReady ou MemoryPressure).
  • Capacidade de CPU/memória próxima do limite no cluster.
  • PersistentVolumeClaims pendentes sem provisionamento.
  • Certificados de API próximos do vencimento.

Como qualquer alerta, eles são roteados pelas suas regras de notificação e podem ser silenciados via manutenção durante deploys planejados.

Próximos passos

  • Docker

    Para nós e swarms sem orquestração Kubernetes, veja a página de Docker.

    Página de Docker

  • Como funcionam os alertas

    Da definição do alerta ao canal de notificação: vocabulário completo.

    Ver Conceitos