Introdução
As aplicações modernas geralmente são empacotadas em contêineres. Um contêiner reúne uma aplicação com as bibliotecas e configurações de que ela precisa, facilitando sua execução de maneira consistente. Executar um único contêiner é simples. Executar muitos contêineres de forma confiável é mais difícil: é preciso decidir onde serão executados, reiniciar contêineres que falharem, conectar as aplicações entre si e distribuir alterações com segurança.
O Kubernetes é um sistema de orquestração de contêineres que cuida dessas responsabilidades no nível do cluster. Você descreve o estado desejado — por exemplo, “execute três cópias desta aplicação web” — e o Kubernetes trabalha continuamente para fazer com que o estado real corresponda ao estado desejado.
Um cluster Kubernetes é composto por uma ou mais máquinas chamadas nós. O plano de controle gerencia o cluster, enquanto os nós fornecem CPU, memória, rede e o runtime de contêineres usado pelas aplicações. As aplicações são executadas em objetos do Kubernetes, como Pods, Deployments e Services.
Neste primeiro laboratório, você ainda não implantará uma aplicação. Primeiro, aprenderá a se orientar em um cluster real:
- Identificar as ferramentas, o cluster ativo, a versão do Kubernetes e a integridade dos nós.
- Localizar os componentes do plano de controle e dos nós que fazem o Kubernetes funcionar.
- Inspecionar os endpoints do cluster e informações detalhadas dos nós.
- Explorar Pods, Deployments e Services em diferentes namespaces.
O ambiente já está preparado para que você possa se concentrar nos conceitos do Kubernetes, sem precisar lidar com a instalação. Ele utiliza o Minikube v1.38.1 com um perfil chamado labex-v135, executando o Kubernetes v1.35.5. O Minikube executa um cluster Kubernetes completo dentro de um contêiner Docker na VM do LabEx. Este é um ambiente de aprendizagem com um único nó, mas os comandos e conceitos praticados também se aplicam a clusters maiores.
Você trabalhará exclusivamente no terminal. Leia as explicações antes de executar cada comando e compare a saída real com as evidências descritas. Idades exatas, contagens de reinicializações e nomes gerados podem variar; isso é normal em um sistema ativo.
Verificar o cluster pré-configurado
Inicialização do ambiente: Este laboratório inicia um cluster Kubernetes completo para você. A configuração do plano de controle, do nó e dos componentes de rede normalmente leva 2–3 minutos. Aguarde pacientemente até que o ambiente termine de carregar antes de começar.
Nesta etapa, você aprenderá como as ferramentas do terminal se conectam ao Kubernetes, identificará as versões de software fornecidas e confirmará que o cluster está pronto. Antes de alterar um cluster, um administrador deve sempre saber qual cluster está ativo e se ele está saudável.
Entender as ferramentas
Você usará duas ferramentas de linha de comando relacionadas:
minikubecria e gerencia clusters Kubernetes locais. Um ambiente Minikube identificado por um nome é chamado de perfil. Este laboratório utiliza o perfillabex-v135.kubectlé o cliente de linha de comando padrão do Kubernetes. Ele envia solicitações ao servidor da API do Kubernetes para listar, criar, atualizar e excluir objetos.
O cluster já está em execução. Não execute minikube start: isso é desnecessário e pode fazer você esperar enquanto o Minikube verifica novamente o ambiente existente.
Entrar no diretório de trabalho
Mude para o diretório do projeto, onde os próximos laboratórios armazenarão manifestos e outros arquivos criados por você:
cd /home/labex/project
O comando cd altera o diretório atual do shell. Normalmente, ele não exibe nenhuma saída quando é executado com sucesso.
Verificar a versão do Minikube
Exiba a versão instalada do Minikube. Uma opção iniciada por -- altera o comportamento do comando. Neste caso, --short solicita apenas o número da versão.
minikube version --short
v1.38.1
Esta é a versão da ferramenta de gerenciamento do cluster, não a versão do Kubernetes. Minikube e Kubernetes são projetos distintos e possuem números de versão próprios.
Verificar as versões do cliente e do servidor
Solicite informações de versão ao kubectl. Essa operação entra em contato com o cluster, verificando tanto o cliente local quanto o servidor remoto da API:
kubectl version
Client Version: v1.35.5
Kustomize Version: ...
Server Version: v1.35.5
Client Version é a versão do kubectl instalado; Server Version é informada pelo servidor da API do Kubernetes. A presença da linha do servidor comprova que o kubectl conseguiu acessar um cluster. Kustomize é um recurso integrado para personalização de manifestos e não será necessário neste laboratório.
Confirmar o contexto ativo
Um computador pode armazenar informações de acesso a vários clusters em um arquivo kubeconfig. Um contexto do kubeconfig seleciona um cluster, as credenciais de um usuário e um namespace padrão. Verificar o contexto evita trabalhar acidentalmente no cluster errado.
kubectl config current-context
labex-v135
Esse é o perfil Kubernetes v1.35 preparado para o laboratório.
Listar e selecionar contextos
Arquivos kubeconfig reais frequentemente contêm mais de um contexto. Liste-os antes de alternar para não precisar adivinhar um nome:
kubectl config get-contexts
A coluna NAME contém os nomes dos contextos, e a coluna CURRENT marca o contexto ativo com *. O cluster, as informações de autenticação e o namespace padrão associados a cada contexto aparecem nas outras colunas.
Use use-context quando precisar selecionar um desses nomes. Selecionar labex-v135 novamente é seguro, mesmo que ele já esteja ativo, e permite praticar o fluxo exato de troca de contexto:
kubectl config use-context labex-v135
Switched to context "labex-v135".
current-context responde “qual contexto está selecionado?”, get-contexts responde “quais opções existem?” e use-context NAME altera a seleção. Esses comandos modificam apenas a escolha do cliente local; eles não iniciam, interrompem nem alteram um cluster.
Verificar o perfil do Minikube
Solicite ao Minikube o status desse perfil. A opção curta -p significa profile e é seguida pelo nome do perfil.
minikube status -p labex-v135
labex-v135
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
host indica que o contêiner do nó do Minikube está em execução. kubelet é o agente do nó. apiserver é o endpoint da API do Kubernetes. kubeconfig: Configured significa que a configuração do cliente local aponta para este cluster. Todos esses componentes devem estar saudáveis.
Listar os nós
A maioria dos comandos do kubectl segue o formato kubectl <verb> <resource>. Aqui, get lê objetos e nodes é o tipo de recurso:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35.5
NAME identifica o nó. STATUS=Ready significa que ele pode executar cargas de trabalho. ROLES mostra que ele hospeda o plano de controle. AGE pode ser mais antigo que esta sessão porque a imagem restaura um snapshot preparado. VERSION é a versão do kubelet.
Este laboratório possui um nó que desempenha funções de plano de controle e de execução de cargas de trabalho. Em clusters de produção, essas funções normalmente são distribuídas entre várias máquinas.
Ponto de verificação da etapa
Você confirmou que o kubectl alcança o cluster correto, labex-v135, e que seu nó está Ready no Kubernetes v1.35.5. Essa é uma rotina útil de orientação sempre que você acessa um cluster desconhecido.
Identificar os componentes da arquitetura do Kubernetes
Nesta etapa, você relacionará o modelo de arquitetura do Kubernetes aos componentes reais. Nomes como servidor da API, scheduler e kubelet ficam mais fáceis de memorizar quando você observa os Pods correspondentes em execução.
Acompanhar uma solicitação pelo Kubernetes
Imagine que você peça ao Kubernetes para executar uma aplicação web. Primeiro, o kubectl envia a solicitação ao kube-apiserver, que a valida e armazena o estado desejado no etcd.
Em seguida, o kube-scheduler escolhe um nó para cada novo Pod. O kube-controller-manager observa o cluster e trabalha para fazer o estado real corresponder ao estado desejado.
Por fim, o kubelet do nó selecionado solicita ao runtime de contêineres que inicie os contêineres do Pod. Os componentes de rede permitem a comunicação entre Pods e Services.
Essa comparação contínua entre o estado desejado e o estado real é chamada de reconciliação. Se um Deployment solicitar três Pods, mas apenas dois existirem, um controlador criará o Pod ausente.
Entender Pods e namespaces do sistema
Um Pod é a menor unidade implantável do Kubernetes. Ele agrupa um ou mais contêineres estreitamente relacionados e fornece a eles um contexto compartilhado de rede e armazenamento.
Um namespace fornece um escopo lógico para objetos que pertencem a namespaces. kube-system contém a infraestrutura do cluster. A opção -n kube-system informa ao kubectl para pesquisar nesse namespace, em vez de usar o namespace padrão. A forma equivalente mais longa é --namespace=kube-system; ambas selecionam o mesmo escopo.
O Minikube executa os componentes do plano de controle como Pods estáticos. O kubelet os cria diretamente a partir de arquivos do nó, permitindo que o plano de controle seja iniciado antes que o agendamento comum esteja disponível.
Listar o plano de controle
Os objetos podem conter labels, metadados no formato chave-valor usados para agrupamento e seleção. Use -l tier=control-plane para selecionar Pods com essa label:
kubectl get pods -n kube-system -l tier=control-plane
NAME READY STATUS RESTARTS AGE
etcd-labex-v135 1/1 Running ... ...
kube-apiserver-labex-v135 1/1 Running ... ...
kube-controller-manager-labex-v135 1/1 Running ... ...
kube-scheduler-labex-v135 1/1 Running ... ...
O servidor da API é a porta de entrada do Kubernetes. O etcd armazena o estado do cluster. O scheduler escolhe onde os Pods serão executados. O gerenciador de controladores executa os controladores de reconciliação.
READY=1/1 significa que o único contêiner do Pod está pronto. Componentes de longa duração devem estar com STATUS=Running. RESTARTS pode ser diferente de zero após a retomada do cluster salvo. AGE indica a idade do objeto, não o tempo transcorrido neste laboratório.
Inspecionar as labels
Exiba as labels em uma coluna adicional:
kubectl get pods -n kube-system -l tier=control-plane --show-labels
Procure por component=kube-apiserver e tier=control-plane. A primeira identifica um componente; a segunda agrupa todos os Pods do plano de controle. As labels identificam objetos, e os seletores localizam objetos correspondentes.
Inspecionar os componentes de rede dos nós
Use um seletor baseado em conjuntos, indicando que k8s-app deve ser kube-proxy ou calico-node. As aspas impedem que o shell interprete os parênteses.
kubectl get pods -n kube-system -l 'k8s-app in (kube-proxy,calico-node)'
NAME READY STATUS RESTARTS AGE
calico-node-... 1/1 Running ... ...
kube-proxy-... 1/1 Running ... ...
O Calico configura a rede dos Pods. O kube-proxy mantém regras no nó que ajudam os Services a direcionar o tráfego para os Pods. O kubelet não aparece nessa lista porque é o agente do host responsável por operar os Pods; portanto, ele é executado como um serviço do host, e não como um Pod comum gerenciado por ele mesmo.
Ponto de verificação da etapa
O servidor da API aceita solicitações, o etcd armazena o estado, o scheduler escolhe onde os Pods serão executados, os controladores reconciliam o estado, o kubelet opera o nó, e o Calico junto com o kube-proxy dá suporte à rede.
Inspecionar detalhes do cluster e dos nós
Nesta etapa, você passará de uma simples verificação de integridade para uma inspeção detalhada. O Kubernetes oferece visões resumidas em formato de lista e descrições detalhadas; saber quando usar cada uma é um hábito essencial para solucionar problemas.
Localizar os endpoints do cluster
kubectl cluster-info é um comando criado especificamente para orientação. Diferentemente de kubectl get, ele não lista um tipo de recurso; solicita ao cluster ativo os endereços de serviços importantes, como o servidor da API e o CoreDNS.
kubectl cluster-info
Kubernetes control plane is running at https://...
CoreDNS is running at https://...
A URL do plano de controle é o endpoint do servidor da API. O CoreDNS fornece descoberta de serviços por DNS, permitindo que as cargas de trabalho encontrem Services pelo nome, em vez de acompanhar endereços IP que podem mudar. Os endereços variam, portanto concentre-se em is running, que indica que o servidor da API retornou informações. Isso não comprova que todas as cargas de trabalho estejam saudáveis.
Ampliar a lista de nós
Adicione -o wide para solicitar colunas adicionais:
kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP ... OS-IMAGE
labex-v135 Ready control-plane ... v1.35.5 192.168.49.2 ... Debian GNU/Linux 12 (bookworm)
INTERNAL-IP é o endereço do nó na rede do cluster. EXTERNAL-IP=<none> significa que ele não possui um endereço público gerenciado pelo Kubernetes. OS-IMAGE, KERNEL-VERSION e CONTAINER-RUNTIME descrevem o software do nó.
O backend do LabEx usa Ubuntu 22.04, enquanto o Minikube representa o nó Kubernetes com um contêiner Docker baseado em Debian. Portanto, é esperado ver Debian aqui.
Descrever o nó
Use describe quando uma linha da lista não fornecer detalhes suficientes. O formato é kubectl describe <resource-type> <name>; neste caso, o tipo de recurso é node e o nome do objeto é labex-v135:
kubectl describe node labex-v135
Próximo ao início da saída, examine a identidade e o agendamento:
Name: labex-v135
Roles: control-plane
Taints: <none>
Unschedulable: false
Taints podem impedir o agendamento de Pods que não as toleram. <none> significa que este nó de aprendizagem não possui nenhuma. Unschedulable: false significa que o Kubernetes pode colocar cargas de trabalho nele.
Localize a tabela Conditions:
Type Status ... Reason
NetworkUnavailable False ... CalicoIsUp
MemoryPressure False ... KubeletHasSufficientMemory
DiskPressure False ... KubeletHasNoDiskPressure
PIDPressure False ... KubeletHasSufficientPID
Ready True ... KubeletReady
Para as condições de pressão e indisponibilidade, False indica um estado saudável, pois o problema está ausente. Para Ready, True indica um estado saudável. Sempre interprete o nome da condição junto com seu valor.
Capacity representa o total de recursos reportados pelo nó. Allocatable representa os recursos que o Kubernetes pode oferecer aos Pods depois das reservas do sistema. System Info informa detalhes do runtime e do kubelet. As seções posteriores listam Pods, solicitações e limites alocados e eventos. Valores exatos e horários podem variar.
Ponto de verificação da etapa
Use get para obter uma tabela rápida, get -o wide para exibir colunas adicionais e describe para consultar condições, capacidade, detalhes do runtime e eventos de um objeto específico.
Inspecionar recursos em diferentes namespaces
Nesta etapa, você criará um mapa introdutório dos objetos mais comuns: Namespaces organizam recursos, Pods executam contêineres, Deployments gerenciam Pods e Services fornecem acesso de rede estável.
Entender as relações entre os objetos
- Um Pod é a menor unidade implantável e contém um ou mais contêineres.
- Um Deployment declara quantas cópias de uma aplicação sem estado devem ser executadas e gerencia os Pods por meio de um ReplicaSet.
- Um Service fornece aos Pods selecionados um IP virtual estável e um nome DNS, pois os IPs substituíveis dos Pods podem mudar.
- Um Namespace agrupa objetos pertencentes a namespaces e permite o uso do mesmo nome em diferentes escopos.
De forma simplificada: um Deployment gerencia Pods, enquanto um Service seleciona esses Pods e fornece aos clientes um endpoint estável. Nem todo objeto pertence a um namespace; os Nodes pertencem ao cluster inteiro.
Listar Pods em todos os namespaces
Sem uma opção de namespace, kubectl get pods pesquisa apenas o namespace atual. -A significa --all-namespaces:
kubectl get pods -A
NAMESPACE é o escopo lógico. NAME identifica o Pod dentro desse escopo. READY indica a quantidade de contêineres prontos dividida pelo total de contêineres. STATUS representa a fase do ciclo de vida. RESTARTS contabiliza as reinicializações e AGE indica a idade do objeto.
A infraestrutura de longa duração deve estar com STATUS=Running. Alguns Pods de admissão do ingress aparecem como Completed com prontidão 0/1, pois executaram Jobs únicos e foram encerrados com sucesso. A integridade deve ser interpretada de acordo com a finalidade da carga de trabalho.
Listar Deployments
O nome de recurso no plural, deployments, solicita os objetos Deployment. Mantenha -A, pois os Deployments do sistema ficam fora do namespace atual default:
kubectl get deployments -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
ingress-nginx ingress-nginx-controller 1/1 1 1 ...
kube-system calico-kube-controllers 1/1 1 1 ...
kube-system coredns 1/1 1 1 ...
kube-system metrics-server 1/1 1 1 ...
READY é o número de réplicas prontas dividido pelo número desejado de réplicas. UP-TO-DATE contabiliza as réplicas que usam o template atual do Pod. AVAILABLE contabiliza as réplicas disponíveis para sua finalidade. O Pod coredns-... visto anteriormente é mantido pelo Deployment coredns.
Listar Services
Como os Pods podem ser substituídos, os clientes não devem depender do IP de um Pod. Liste os endpoints estáveis dos Services:
kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP ...
kube-system kube-dns ClusterIP 10.96.0.10 <none> ... ...
ingress-nginx ingress-nginx-controller NodePort ... <none> ... ...
TYPE descreve como o Service é exposto. ClusterIP pode ser acessado dentro do cluster; NodePort também abre uma porta no nó. CLUSTER-IP é o endereço virtual estável. EXTERNAL-IP=<none> significa que nenhum endereço externo foi atribuído. PORT(S) lista os protocolos e as portas expostos.
O Service kubernetes expõe a API para acesso dentro do cluster. kube-dns fornece acesso estável ao CoreDNS. Os Services do Ingress dão suporte à entrada de tráfego HTTP e HTTPS.
Criar uma visão combinada
Quando você ainda não sabe qual tipo de carga de trabalho comum está presente, kubectl get all fornece uma visão geral combinada. Adicionar -A repete o escopo de todos os namespaces usado anteriormente:
kubectl get all -A
Esse comando agrupa recursos comuns, como Pods, Services, DaemonSets, Deployments, ReplicaSets e Jobs. Um mesmo componente pode aparecer em vários níveis: Deployment, ReplicaSet e Pod.
Apesar do nome, get all não retorna todos os recursos. ConfigMaps, Secrets, NetworkPolicies e muitos outros são omitidos. Use-o para obter uma visão geral e, em seguida, solicite o tipo exato de recurso.
Ponto de verificação da etapa
Namespaces fornecem escopo, Pods executam contêineres, Deployments mantêm o número desejado de réplicas de Pods e Services fornecem acesso de rede estável a Pods que podem ser substituídos.
Resumo
Você concluiu sua primeira exploração guiada de um cluster Kubernetes. Aprendeu que o Kubernetes gerencia o estado desejado entre os nós e que o kubectl se comunica com o servidor da API usando o contexto ativo do kubeconfig.
Você praticou como distinguir as versões do Minikube, do Kubernetes e do kubectl; confirmar o contexto e a prontidão dos nós; identificar componentes do plano de controle, dos nós e da rede; usar labels e seletores; escolher entre get, get -o wide e describe; interpretar condições e capacidade dos nós; e relacionar Namespaces, Pods, Deployments e Services.
O principal hábito para iniciantes é inspecionar antes de alterar qualquer coisa: confirme o contexto, verifique a integridade dos nós, identifique o namespace e o tipo de recurso relevantes e leia atentamente o estado informado. Os próximos laboratórios desenvolverão esse modelo à medida que você criar suas próprias cargas de trabalho.
