Introdução
Em Kubernetes para iniciantes, você usou kubectl get, describe e rótulos para verificar se uma aplicação estava funcionando. Clusters reais contêm muitos objetos, portanto a próxima habilidade é fazer perguntas mais específicas e extrair apenas as evidências necessárias.
Neste laboratório, você implantará uma pequena carga de trabalho de uma loja virtual e a inspecionará de vários ângulos: namespace, rótulos, campos estruturados, propriedade do controlador e eventos. Ao final, você terá um comando compacto que relaciona um Deployment aos Pods que ele gerencia.
Não é necessário memorizar todos os formatos de saída. Em vez disso, pratique transformar uma pergunta em uma consulta específica: “Quais objetos existem?”, “Quais Pods correspondem a este Service?”, “Quem é o proprietário deste Pod?” ou “O que aconteceu mais recentemente?”. Cada etapa adiciona uma ferramenta a esse fluxo de inspeção.
Crie um espaço de trabalho dedicado
Nesta etapa, você criará um namespace e implantará nele os recursos preparados. Um namespace restringe o escopo das consultas posteriores e evita confundir objetos com nomes semelhantes.
Acesse o diretório de trabalho do laboratório e inspecione o contexto atual antes de alterar o estado do cluster. cd altera o diretório de trabalho do shell, portanto nomes de arquivos relativos posteriores, como storefront.yaml, apontarão para o espaço de trabalho preparado.
cd /home/labex/project/resource-inspection
kubectl config current-context
A saída deve ser labex-v135. Crie o namespace e aplique o manifesto preparado com vários documentos:
kubectl create namespace practice-observe
kubectl apply -f storefront.yaml
kubectl rollout status deployment/storefront -n practice-observe --timeout=60s
As linhas finais devem ser semelhantes às seguintes. Enquanto os dois Pods são iniciados, podem aparecer mensagens intermediárias do processo de implantação:
namespace/practice-observe created
deployment.apps/storefront created
service/storefront created
deployment "storefront" successfully rolled out
-n practice-observe restringe o comando a esse namespace. O comando de rollout aguarda até que as duas réplicas do Deployment estejam disponíveis, em vez de depender de uma espera arbitrária.
Você usará -n practice-observe repetidamente. Caso contrário, os comandos do Kubernetes usarão o namespace configurado no contexto atual — normalmente default — e um objeto saudável poderá parecer “ausente” simplesmente porque a consulta foi feita no escopo errado.
Descubra os recursos e seus escopos
Nesta etapa, você usará a descoberta da API antes de consultar objetos. kubectl api-resources lista os nomes de recursos que o servidor de API atual conhece, juntamente com os nomes abreviados e a indicação de que cada recurso pertence ou não a um namespace. O pipe para head limita a listagem inicial aos dez primeiros itens, evitando inundar o terminal.
kubectl api-resources | head
kubectl api-resources --namespaced=true | grep -E 'pods|deployments|services'
O pipe encaminha a lista de recursos para grep. -E habilita a alternância com |, permitindo que um único comando corresponda a vários nomes de recursos. Observe que Pods, Deployments e Services pertencem a namespaces.
Liste os objetos da aplicação usando os nomes completos e repita a consulta com os nomes abreviados comuns:
kubectl get pods,deployments,services -n practice-observe
kubectl get po,deploy,svc -n practice-observe
Os dois comandos consultam os mesmos recursos da API. Os nomes abreviados economizam digitação, mas os nomes completos são mais claros em scripts e na documentação.
Procure um Deployment, dois Pods gerados e um Service. A lista de recursos separada por vírgulas é apenas uma conveniência de consulta; esses objetos continuam tendo funções e esquemas de API diferentes.
Os prefixos dos tipos facilitam a interpretação da saída combinada. Sufixos gerados, endereços e idades variarão:
NAME READY STATUS RESTARTS AGE
pod/storefront-... 1/1 Running 0 ...
pod/storefront-... 1/1 Running 0 ...
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/storefront 2/2 2 2 ...
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/storefront ClusterIP ... <none> 80/TCP ...
Filtre usando rótulos e seletores
Nesta etapa, você usará rótulos como metadados pesquisáveis. --show-labels exibe todos os rótulos, enquanto -l seleciona apenas os objetos cujos rótulos correspondem a uma expressão.
kubectl get pods -n practice-observe --show-labels
kubectl get pods -n practice-observe -l app=storefront
kubectl get pods -n practice-observe -l 'app=storefront,tier=web'
Uma vírgula entre requisitos do seletor representa uma condição lógica E. Portanto, a última consulta retorna os Pods que possuem ambos os rótulos.
Compare o seletor do Service com os rótulos dos Pods selecionados:
kubectl get service storefront -n practice-observe -o jsonpath='Service selector: {.spec.selector.app}{"\n"}'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='NAME:.metadata.name,TIER:.metadata.labels.tier,IP:.status.podIP,READY:.status.containerStatuses[0].ready'
kubectl get endpointslices -n practice-observe -l kubernetes.io/service-name=storefront
JSONPath extrai um campo do Service. -o custom-columns produz uma tabela compacta a partir de vários campos dos Pods. Isso é mais confiável do que procurar visualmente em um documento YAML extenso.
O comando final solicita os EndpointSlices cujo rótulo gerenciado automaticamente kubernetes.io/service-name pertence a storefront. Um EndpointSlice registra os endpoints de rede selecionados para um Service. Uma coluna ENDPOINTS não vazia confirma que os rótulos correspondentes produziram backends acessíveis pela rede.
O seletor do Service deve exibir storefront, e as duas linhas da tabela de Pods devem conter tier=web. Esse rótulo app correspondente é a ligação: um Service descobre Pods por meio de rótulos, não por meio da propriedade do Deployment.
Service selector: storefront
NAME TIER IP READY
storefront-... web 10.244... true
storefront-... web 10.244... true
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
storefront-... IPv4 80 10.244...,10.244... ...
Rastreie a propriedade entre controladores
Nesta etapa, você acompanhará a cadeia de propriedade do Kubernetes do Deployment ao ReplicaSet e aos Pods. Os controladores adicionam ownerReferences para que o Kubernetes saiba qual objeto de nível superior gerencia cada objeto dependente.
kubectl get replicasets -n practice-observe -l app=storefront
kubectl get replicasets -n practice-observe -l app=storefront -o custom-columns='REPLICASET:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='POD:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
O proprietário do ReplicaSet deve ser o Deployment storefront. O proprietário de cada Pod é o ReplicaSet gerado, e não o Deployment diretamente:
Deployment/storefront -> ReplicaSet/storefront-... -> Pod/storefront-...
Use kubectl describe quando precisar consultar essa relação juntamente com as condições e os eventos recentes:
kubectl describe deployment storefront -n practice-observe
Não leia a saída de describe do início ao fim todas as vezes. Para esta pergunta, concentre-se em Selector, nas contagens de réplicas, nas condições e nos eventos. O melhor comando de inspeção é aquele que responde à pergunta atual com o mínimo de ruído.
Leia os eventos como uma linha do tempo
Nesta etapa, você inspecionará os eventos como evidências ordenadas no tempo. Os eventos descrevem ações de agendamento, imagens, contêineres e controladores, mas são diagnósticos temporários, não registros permanentes de auditoria.
kubectl get events -n practice-observe --sort-by=.metadata.creationTimestamp
--sort-by ordena os objetos usando um caminho de campo. Restrinja a linha do tempo primeiro ao Deployment e depois a um Pod selecionado:
kubectl events -n practice-observe --for deployment/storefront
POD_NAME=$(kubectl get pods -n practice-observe -l app=storefront -o jsonpath='{.items[0].metadata.name}')
echo "$POD_NAME"
kubectl events -n practice-observe --for "pod/${POD_NAME}"
$(...) é uma substituição de comando: o shell executa o comando interno e armazena sua saída em POD_NAME. Agora você tem um caminho de inspeção repetível: restringir o namespace, selecionar por rótulos, extrair campos, acompanhar os proprietários e finalizar com a linha do tempo de eventos relevante.
Os nomes dos Pods gerados pelos controladores mudam quando eles são substituídos. Por isso, selecionar o nome atual por rótulo é mais seguro do que copiar um valor antigo. Esse padrão reaparecerá ao longo dos laboratórios de solução de problemas.
O ciclo de vida bem-sucedido normalmente inclui Scheduled, Pulled, Created e Started. Um cluster local iniciado recentemente também pode manter um aviso anterior, como FailedCreatePodSandBox, enquanto o Calico fica pronto. Não conclua que a aplicação continua com problemas apenas por causa de um aviso antigo: compare o carimbo de data e hora dele com os eventos normais posteriores e confirme o estado atual de READY do Pod. Os carimbos de data e hora e os nomes gerados dos Pods são omitidos intencionalmente, pois mudam a cada execução.
Resumo
Você inspecionou uma aplicação Kubernetes sem examinar objetos não relacionados. Combinou namespaces, rótulos, JSONPath, colunas personalizadas, referências de propriedade e eventos para passar de um inventário amplo a evidências operacionais precisas. No próximo laboratório, esse fluxo de inspeção será aplicado a Pods e contêineres com falhas.
