Introdução
O Kubernetes pode ser estendido com novos tipos de recursos. Uma CustomResourceDefinition, geralmente chamada de CRD, registra um novo recurso de API no servidor de API do Kubernetes. Após isso, você pode usar os comandos familiares do kubectl para criar, obter, descrever, rotular e aplicar patches em objetos desse novo tipo.
Neste laboratório, você criará um pequeno CRD com escopo de namespace chamado AppProfile, descobrirá o recurso com comandos de descoberta da API do Kubernetes, criará recursos personalizados a partir de YAML e os atualizará como objetos comuns do Kubernetes. Nenhum controlador é necessário para este laboratório; o foco é entender como os tipos de recursos personalizados aparecem e como trabalhar com seus objetos.
Preparar um Namespace para Recursos Personalizados
Nesta etapa, você preparará um namespace limpo para praticar com recursos personalizados.
Comece em /home/labex/project. Você escreverá os manifestos do CRD e do recurso personalizado neste diretório.
mkdir -p /home/labex/project
cd /home/labex/project
Verifique se o servidor de 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-customresources:
kubectl create namespace ckad-prep-customresources
Defina este namespace como o namespace do contexto atual:
kubectl config set-context --current --namespace=ckad-prep-customresources
Confirme o namespace atual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Saída esperada:
ckad-prep-customresources
Registrar um Novo Tipo de Recurso com um CRD
Nesta etapa, você criará uma CustomResourceDefinition chamada AppProfile.
Um CRD possui duas camadas importantes de nomenclatura. O metadata.name é o nome do recurso no plural mais o grupo da API, como appprofiles.training.labex.io. A seção spec.names define como as pessoas se referirão ao recurso: kind: AppProfile, plural: appprofiles, singular: appprofile e um nome curto appprof.
Crie o arquivo app-profile-crd.yaml:
cat > app-profile-crd.yaml <<'EOF'
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: appprofiles.training.labex.io
spec:
group: training.labex.io
scope: Namespaced
names:
plural: appprofiles
singular: appprofile
kind: AppProfile
shortNames:
- appprof
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
required:
- image
- replicas
properties:
image:
type: string
replicas:
type: integer
minimum: 1
tier:
type: string
EOF
Aplique o CRD:
kubectl apply -f app-profile-crd.yaml
Saída esperada:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io created
Aguarde até que o servidor de API informe que o CRD foi estabelecido:
kubectl wait --for=condition=Established crd/appprofiles.training.labex.io --timeout=120s
Saída esperada:
customresourcedefinition.apiextensions.k8s.io/appprofiles.training.labex.io condition met
Inspecione os nomes e o escopo do CRD:
kubectl get crd appprofiles.training.labex.io -o 'jsonpath={.spec.names.kind}{" "}{.spec.names.plural}{" "}{.spec.scope}{"\n"}'
Saída esperada:
AppProfile appprofiles Namespaced
Descobrir e Criar Recursos Personalizados
Nesta etapa, você descobrirá o novo tipo de recurso e criará seu primeiro AppProfile.
O comando kubectl api-resources lista os tipos de recursos conhecidos pelo servidor de API. Após um CRD ser estabelecido, ele aparece nesta saída de descoberta ao lado dos tipos de recursos nativos.
kubectl api-resources --api-group=training.labex.io
A saída esperada inclui:
NAME SHORTNAMES APIVERSION NAMESPACED KIND
appprofiles appprof training.labex.io/v1 true AppProfile
Use o kubectl explain para ler o esquema que o Kubernetes aprendeu a partir do CRD. O campo spec é onde as configurações específicas da aplicação residem.
kubectl explain appprofile.spec
A saída esperada inclui:
GROUP: training.labex.io
KIND: AppProfile
VERSION: v1
FIELD: spec <Object>
Crie o arquivo frontend-profile.yaml:
cat > frontend-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: frontend
labels:
app.kubernetes.io/part-of: storefront
tier: web
spec:
image: nginx:1.27
replicas: 2
tier: web
EOF
Aplique o recurso personalizado:
kubectl apply -f frontend-profile.yaml
Saída esperada:
appprofile.training.labex.io/frontend created
Liste os recursos personalizados usando o nome no plural:
kubectl get appprofiles
A saída esperada inclui:
NAME AGE
frontend ...
Leia os campos do recurso personalizado com jsonpath:
kubectl get appprofile frontend -o 'jsonpath={.spec.image}{" "}{.spec.replicas}{" "}{.spec.tier}{"\n"}'
Saída esperada:
nginx:1.27 2 web
Atualizar e Selecionar Recursos Personalizados
Nesta etapa, você gerenciará recursos personalizados com os mesmos padrões do kubectl que você já utiliza para objetos nativos.
Aplique um patch no recurso personalizado frontend para alterar sua contagem de réplicas desejada. A opção --type=merge instrui o Kubernetes a mesclar seu objeto JSON no objeto existente, em vez de substituir todo o recurso.
kubectl patch appprofile frontend --type=merge -p '{"spec":{"replicas":3}}'
Saída esperada:
appprofile.training.labex.io/frontend patched
Confirme o valor atualizado:
kubectl get appprofile frontend -o 'jsonpath={.spec.replicas}{"\n"}'
Saída esperada:
3
Crie um segundo recurso personalizado chamado worker:
cat > worker-profile.yaml <<'EOF'
apiVersion: training.labex.io/v1
kind: AppProfile
metadata:
name: worker
labels:
app.kubernetes.io/part-of: storefront
tier: worker
spec:
image: busybox:1.36
replicas: 1
tier: worker
EOF
kubectl apply -f worker-profile.yaml
Saída esperada:
appprofile.training.labex.io/worker created
Liste apenas os recursos personalizados que pertencem à aplicação storefront. Isso funciona porque os recursos personalizados suportam rótulos (labels) normais do Kubernetes.
kubectl get appprofiles -l app.kubernetes.io/part-of=storefront
A saída esperada inclui:
NAME AGE
frontend ...
worker ...
Use o nome curto appprof para imprimir o nome de cada recurso e a contagem de réplicas:
kubectl get appprof -o 'jsonpath={range .items[*]}{.metadata.name}{"="}{.spec.replicas}{"\n"}{end}'
A saída esperada inclui:
frontend=3
worker=1
Resumo
Você criou um CRD, aguardou até que ele fosse estabelecido, descobriu o novo recurso de API com kubectl api-resources e kubectl explain, criou recursos personalizados, aplicou um patch em um recurso personalizado, selecionou-os por rótulo e utilizou um nome curto. Estas são as mesmas habilidades operacionais que você usará quando as tarefas do CKAD envolverem recursos instalados por um operador, controlador ou extensão de plataforma.
