Introdução
Um ConfigMap armazena configurações não sensíveis separadamente da imagem do contêiner. Isso permite que você reutilize a mesma imagem de aplicação com diferentes definições, como modo de desenvolvimento, nível de log, sinalizadores de recursos (feature flags) ou nomes de endpoints.
Neste laboratório, você criará um ConfigMap, inspecionará seus dados, usará o objeto para configurar um Pod, atualizará o ConfigMap e recriará o Pod para que ele utilize os novos valores. Laboratórios futuros aprofundarão o uso de variáveis de ambiente específicas e arquivos de configuração montados; este laboratório foca no objeto ConfigMap e no fluxo de trabalho fundamental de configuração de aplicações.
Preparar um Namespace para o ConfigMap
Nesta etapa, você preparará um namespace limpo para praticar com ConfigMaps.
Comece em /home/labex/project. Você escreverá um manifesto de Pod neste diretório.
mkdir -p /home/labex/project
cd /home/labex/project
Verifique se o servidor da API do Kubernetes está acessível. Se a VM acabou de iniciar e o nó ainda não está pronto, aguarde alguns segundos e execute o comando novamente.
kubectl get nodes --request-timeout=5s
A saída esperada inclui:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Aguarde até que o Pod de rede do cluster esteja pronto (Ready) antes de criar objetos de aplicação.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Saída esperada:
pod/calico-node-... condition met
Crie um namespace chamado ckad-prep-configmaps:
kubectl create namespace ckad-prep-configmaps
Defina este namespace como o namespace do contexto atual:
kubectl config set-context --current --namespace=ckad-prep-configmaps
Confirme o namespace atual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Saída esperada:
ckad-prep-configmaps
Criar e Inspecionar um ConfigMap
Nesta etapa, você criará um ConfigMap que contém configurações simples de aplicação.
O comando kubectl create configmap pode criar um ConfigMap diretamente a partir de pares chave-valor literais. Cada flag --from-literal adiciona uma entrada no campo data do ConfigMap.
kubectl create configmap app-settings \
--from-literal=APP_MODE=dev \
--from-literal=LOG_LEVEL=debug \
--from-literal=FEATURE_BANNER=enabled
Saída esperada:
configmap/app-settings created
Inspecione o resumo do ConfigMap:
kubectl get configmap app-settings
Saída esperada:
NAME DATA AGE
app-settings 3 ...
Leia os valores armazenados. O jsonpath exibe campos selecionados sem mostrar o objeto completo.
kubectl get configmap app-settings -o 'jsonpath={.data.APP_MODE}{" "}{.data.LOG_LEVEL}{" "}{.data.FEATURE_BANNER}{"\n"}'
Saída esperada:
dev debug enabled
Você também pode visualizar o ConfigMap como YAML para ver onde as chaves residem no objeto.
kubectl get configmap app-settings -o yaml
A saída esperada inclui:
data:
APP_MODE: dev
FEATURE_BANNER: enabled
LOG_LEVEL: debug
Configurar um Pod a partir do ConfigMap
Nesta etapa, você iniciará um Pod que lê os valores do ConfigMap como variáveis de ambiente.
O campo envFrom.configMapRef importa todas as chaves de um ConfigMap para o ambiente do contêiner. Esta é uma maneira compacta de conectar um pequeno conjunto de configurações não sensíveis a uma aplicação.
Crie o arquivo config-reader-pod.yaml:
cat > config-reader-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: config-reader
labels:
app: config-reader
spec:
terminationGracePeriodSeconds: 0
containers:
- name: reader
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo mode=${APP_MODE}; echo level=${LOG_LEVEL}; echo banner=${FEATURE_BANNER}; sleep 3600'
envFrom:
- configMapRef:
name: app-settings
EOF
Aplique o manifesto do Pod:
kubectl apply -f config-reader-pod.yaml
Saída esperada:
pod/config-reader created
Aguarde até que o Pod esteja pronto (Ready):
kubectl wait --for=condition=Ready pod/config-reader --timeout=120s
Saída esperada:
pod/config-reader condition met
Leia os logs do Pod. A aplicação imprime os valores que vieram do ConfigMap.
kubectl logs config-reader -c reader
Saída esperada:
mode=dev
level=debug
banner=enabled
Atualizar o ConfigMap e Recriar o Pod
Nesta etapa, você atualizará o ConfigMap e recriará o Pod para que o contêiner receba os novos valores.
Quando um ConfigMap é usado como variáveis de ambiente, o contêiner em execução não altera automaticamente seu ambiente. Um novo contêiner deve ser iniciado para ler os valores atualizados. Este é um detalhe importante para o CKAD, pois você pode precisar atualizar a configuração e, em seguida, reiniciar ou recriar a carga de trabalho.
Aplique um patch no ConfigMap:
kubectl patch configmap app-settings --type merge --patch '{"data":{"APP_MODE":"prod","LOG_LEVEL":"warn","FEATURE_BANNER":"disabled"}}'
Saída esperada:
configmap/app-settings patched
Confirme os novos valores do ConfigMap:
kubectl get configmap app-settings -o 'jsonpath={.data.APP_MODE}{" "}{.data.LOG_LEVEL}{" "}{.data.FEATURE_BANNER}{"\n"}'
Saída esperada:
prod warn disabled
Exclua o Pod antigo:
kubectl delete pod config-reader
A saída esperada inclui:
pod "config-reader" deleted
Recrie o Pod a partir do mesmo manifesto e aguarde até que ele esteja pronto:
kubectl apply -f config-reader-pod.yaml
kubectl wait --for=condition=Ready pod/config-reader --timeout=120s
Saída esperada:
pod/config-reader created
pod/config-reader condition met
Leia os logs novamente. O novo Pod agora vê os valores atualizados do ConfigMap.
kubectl logs config-reader -c reader
Saída esperada:
mode=prod
level=warn
banner=disabled
Resumo
Você criou um ConfigMap, inspecionou seus dados, conectou-o a um Pod de aplicação, atualizou o ConfigMap e recriou o Pod para que o contêiner aplicasse os novos valores. Isso fornece o fluxo de trabalho fundamental de ConfigMap antes de avançar para padrões mais detalhados de variáveis de ambiente e montagem de arquivos em laboratórios futuros.
