Introdução
O kubectl é a ferramenta de linha de comando que você utilizará durante todo o seu trabalho com Kubernetes no estilo CKAD. Antes de criar Pods, Deployments, Services ou objetos de configuração, você precisa saber com qual cluster o kubectl está se comunicando e qual namespace seus comandos utilizam por padrão.
Neste laboratório, você irá inspecionar o contexto ativo do Kubernetes, listar namespaces, definir um namespace de prática como o atual e criar um pequeno ConfigMap para observar como objetos com escopo de namespace são isolados. As verificações focam no estado principal do Kubernetes que você cria, e não na formatação exata da saída dos comandos.
Confirmar o acesso ao kubectl
Nesta etapa, você confirmará que o kubectl consegue alcançar o cluster Kubernetes preparado e identificará o contexto que seus comandos estão utilizando.
Comece em /home/labex/project. O comando mkdir -p cria o diretório caso ele não exista e não causa problemas caso já exista. Este curso mantém o trabalho do aluno nesse diretório para que laboratórios futuros possam criar manifestos e arquivos auxiliares em um local previsível.
mkdir -p /home/labex/project
cd /home/labex/project
Um contexto do Kubernetes é uma escolha de conexão salva no seu kubeconfig. Ele informa ao kubectl qual cluster, credenciais de usuário e namespace padrão utilizar. Verifique o contexto ativo antes de executar qualquer comando que altere objetos.
kubectl config current-context
Você deverá ver o nome do perfil do LabEx Kubernetes preparado:
labex-v135
Para um ponto de partida previsível, defina o namespace do contexto atual como default. Você não está criando um objeto aqui; está apenas informando ao kubectl qual namespace utilizar quando um comando posterior omitir a flag --namespace.
kubectl config set-context --current --namespace=default
A saída deve confirmar que o contexto atual foi atualizado:
Context "labex-v135" modified.
O perfil do Kubernetes pode precisar de um breve momento para terminar de iniciar após a exibição da VM. Liste os nós do cluster primeiro. Se este comando informar que o servidor da API ainda não está pronto, aguarde alguns segundos e execute o mesmo comando novamente até ver um nó com status Ready.
kubectl get nodes --request-timeout=5s
A saída esperada incluirá um nó pronto e a versão do Kubernetes:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Agora, solicite ao servidor da API informações básicas sobre o cluster. Isso prova que seu terminal não está apenas encontrando o binário kubectl, mas que ele está autenticado em um cluster em execução.
kubectl cluster-info
A saída deve mencionar um endpoint do plano de controle do Kubernetes:
Kubernetes control plane is running at ...
...
Ler Namespaces
Nesta etapa, você inspecionará os namespaces do Kubernetes e verificará qual namespace seu contexto atual utiliza por padrão.
Namespaces são uma forma de dividir objetos do Kubernetes em escopos separados dentro do mesmo cluster. Muitos recursos de aplicação, como Pods, Deployments, Services, Secrets e ConfigMaps, residem dentro de exatamente um namespace.
Liste os namespaces que já existem no cluster:
kubectl get namespaces
Você deverá ver namespaces do sistema, como kube-system, e o namespace de aplicação comum default:
NAME STATUS AGE
default Active ...
kube-system Active ...
...
Seu contexto também pode armazenar um namespace padrão. Quando você executa um comando que utiliza namespaces sem a flag --namespace, o kubectl usa esse namespace padrão. A opção --minify mostra apenas o contexto ativo, e a expressão jsonpath imprime apenas o campo do namespace.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Como você definiu o namespace do contexto na etapa anterior, isso imprimirá default:
default
Você sempre pode sobrescrever o namespace atual para um único comando usando --namespace. Por exemplo, inspecione os Pods no namespace do sistema Kubernetes sem alterar seu contexto:
kubectl get pods --namespace kube-system
Os nomes exatos dos Pods podem variar, mas o comando deve retornar Pods do sistema, como CoreDNS, rede ou componentes de armazenamento:
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
Selecionar um Namespace de Prática
Nesta etapa, você criará um namespace para este laboratório e o tornará o namespace padrão para comandos futuros.
Crie um namespace chamado ckad-prep-contexts. Nomes de namespaces fazem parte da identidade do objeto: um ConfigMap chamado app-settings em um namespace é diferente de um ConfigMap com o mesmo nome em outro namespace.
kubectl create namespace ckad-prep-contexts
O comando de criação deve confirmar o novo namespace:
namespace/ckad-prep-contexts created
Agora, atualize apenas o contexto atual para que comandos sem --namespace tenham como alvo o ckad-prep-contexts. A opção --current significa "modificar o contexto que estou usando agora" em vez de nomear um contexto manualmente.
kubectl config set-context --current --namespace=ckad-prep-contexts
A saída confirma que o contexto foi modificado:
Context "labex-v135" modified.
Verifique novamente o namespace armazenado no contexto ativo:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Agora ele deve imprimir:
ckad-prep-contexts
Execute uma listagem simples de Pods sem a flag --namespace. Como o namespace atual agora é ckad-prep-contexts, este comando procura dentro do seu namespace de prática. É normal que o namespace esteja vazio.
kubectl get pods
Saída esperada:
No resources found in ckad-prep-contexts namespace.
Observar o escopo de Namespaces
Nesta etapa, você criará um pequeno ConfigMap e o usará para observar como o namespace atual afeta a busca de objetos.
Um ConfigMap armazena dados de configuração não sensíveis para aplicações. Ele é leve, rápido de criar e possui escopo de namespace, o que o torna útil para praticar o comportamento de namespaces antes de começar a implantar aplicações reais.
Crie um ConfigMap chamado app-settings sem passar a flag --namespace. Como você selecionou ckad-prep-contexts na etapa anterior, o Kubernetes o cria nesse namespace.
kubectl create configmap app-settings --from-literal=mode=prep
O comando deve informar:
configmap/app-settings created
Liste o ConfigMap sem uma flag de namespace. Isso utiliza o namespace do contexto atual.
kubectl get configmap app-settings
Saída esperada:
NAME DATA AGE
app-settings 1 ...
Agora, solicite o mesmo objeto com um namespace explícito. Isso deve retornar o mesmo ConfigMap, pois ckad-prep-contexts é onde você o criou.
kubectl get configmap app-settings --namespace ckad-prep-contexts
Por fim, verifique o namespace default. A opção --ignore-not-found faz com que o kubectl encerre com sucesso e não imprima nada quando o objeto não existe, o que é útil para um laboratório guiado, pois a ausência é o resultado esperado aqui.
kubectl get configmap app-settings --namespace default --ignore-not-found
Nenhuma saída significa que o ConfigMap não foi criado no default. Você agora viu o efeito prático de definir o namespace no seu contexto atual.
Resumo
Você confirmou que o kubectl consegue alcançar o cluster Kubernetes preparado, identificou o contexto ativo, inspecionou namespaces existentes, alterou o namespace do contexto atual e criou um ConfigMap para observar o escopo de namespaces. Esses conceitos básicos são a base para os laboratórios de preparação para o CKAD, onde você criará objetos de aplicação e precisará saber exatamente onde cada objeto está sendo criado e inspecionado.
