Introdução
Os laboratórios de implantação anteriores utilizaram manifestos brutos do Kubernetes diretamente. O Helm adiciona uma camada de empacotamento em torno desses manifestos. Um Helm chart armazena modelos (templates) do Kubernetes relacionados, expõe configurações reutilizáveis no arquivo values.yaml e instala os objetos renderizados como um release nomeado.
Neste laboratório, você criará um pequeno chart local em vez de baixar um de um repositório. Você escreverá os metadados do chart, os valores, o template de Deployment e o template de Service, renderizará o chart antes de instalá-lo e, em seguida, atualizará o release alterando os valores. Isso mantém o foco na habilidade exigida pelo CKAD: entender como um chart local se transforma em objetos comuns do Kubernetes.
Preparar um Workspace para o Helm
Nesta etapa, você preparará um namespace e confirmará as ferramentas necessárias para o fluxo de trabalho de um Helm chart local.
Comece em /home/labex/project. Este laboratório mantém o diretório do chart, os manifestos gerados e todos os comandos neste workspace.
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). O chart criará um Service, portanto, os Pods da aplicação precisam de rede no cluster antes que os testes de tráfego sejam significativos.
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-helm e defina-o como o namespace atual:
kubectl create namespace ckad-prep-helm
kubectl config set-context --current --namespace=ckad-prep-helm
Confirme o namespace atual e o cliente Helm. O Helm 3 funciona diretamente com o Kubernetes usando seu kubeconfig atual; não há um componente Tiller separado no lado do servidor.
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
helm version --short
A saída esperada inclui:
ckad-prep-helm
v...
Criar e Renderizar um Chart Local
Nesta etapa, você criará um Helm chart local mínimo e o renderizará antes de instalar qualquer coisa.
Um diretório de chart possui algumas partes importantes. O Chart.yaml descreve o próprio chart. O values.yaml contém as configurações padrão. Os arquivos em templates/ são manifestos do Kubernetes com expressões de template, como {{ .Values.replicaCount }}. O Helm substitui essas expressões por valores concretos ao renderizar ou instalar o chart.
Crie o diretório do chart:
mkdir -p local-web-chart/templates
Escreva o Chart.yaml. O nome do chart não é o mesmo que o nome do release; o nome do release é escolhido posteriormente ao instalar o chart.
cat > local-web-chart/Chart.yaml <<'EOF'
apiVersion: v2
name: local-web
description: A small local chart for CKAD deployment practice
type: application
version: 0.1.0
appVersion: "1.0"
EOF
Escreva o values.yaml. Esses padrões controlam o número de Pods, a imagem do container, as portas do Service e a mensagem exibida pela aplicação.
cat > local-web-chart/values.yaml <<'EOF'
replicaCount: 2
image:
repository: busybox
tag: "1.36"
service:
port: 80
targetPort: 8080
message: helm-v1
EOF
Crie o template de Deployment. O template usa o nome do release nos nomes dos objetos e nos labels, para que o mesmo chart possa ser instalado com diferentes nomes de release.
cat > local-web-chart/templates/deployment.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-web
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
template:
metadata:
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
spec:
terminationGracePeriodSeconds: 0
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- |
mkdir -p /www
echo {{ .Values.message | quote }} > /www/index.html
httpd -f -p {{ .Values.service.targetPort }} -h /www
ports:
- containerPort: {{ .Values.service.targetPort }}
readinessProbe:
httpGet:
path: /
port: {{ .Values.service.targetPort }}
initialDelaySeconds: 1
periodSeconds: 2
EOF
Crie o template de Service. Observe que o seletor do Service usa os mesmos labels que o template do Pod.
cat > local-web-chart/templates/service.yaml <<'EOF'
apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Name }}
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
spec:
selector:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
ports:
- port: {{ .Values.service.port }}
targetPort: {{ .Values.service.targetPort }}
EOF
Execute helm lint para detectar problemas na estrutura do chart e nos templates:
helm lint ./local-web-chart
A saída esperada inclui:
1 chart(s) linted, 0 chart(s) failed
Renderize o chart localmente. O helm template imprime o YAML do Kubernetes que o Helm enviaria ao servidor da API, mas não cria nenhum objeto.
helm template local-web ./local-web-chart | sed -n '1,120p'
A saída esperada inclui um Service chamado local-web e um Deployment chamado local-web-web.
Instalar o Chart como um Release
Nesta etapa, você instalará o chart local no namespace ckad-prep-helm.
A instalação de um chart cria um release do Helm. O nome do release é local-web neste laboratório. O Helm registra os metadados do release e o Kubernetes recebe objetos comuns, como um Deployment e um Service.
Instale o chart:
helm install local-web ./local-web-chart
A saída esperada inclui:
NAME: local-web
STATUS: deployed
Aguarde o Deployment criado pelo chart:
kubectl rollout status deployment/local-web-web --timeout=120s
Saída esperada:
deployment "local-web-web" successfully rolled out
Inspecione o release e os objetos do Kubernetes que ele criou:
helm list
kubectl get deployment,service -l app.kubernetes.io/instance=local-web
A saída esperada inclui:
local-web
deployment.apps/local-web-web
service/local-web
Crie um Pod cliente e envie uma requisição para o Service. Isso confirma que o chart não apenas criou objetos, mas que a aplicação instalada está realmente acessível.
kubectl run chart-client --image=busybox:1.36 --restart=Never --command -- sleep 3600
kubectl wait --for=condition=Ready pod/chart-client --timeout=120s
kubectl exec chart-client -- wget -qO- http://local-web
Saída esperada:
helm-v1
Atualizar o Release com Novos Valores
Nesta etapa, você atualizará o release existente sobrescrevendo os valores do chart.
O chart já contém templates reutilizáveis. Você não precisa editar os arquivos de template para alterar a mensagem ou a contagem de réplicas. O helm upgrade renderiza o mesmo chart novamente com novos valores, atualiza os objetos do Kubernetes e registra uma nova revisão do release.
Atualize o release para que ele exiba helm-v2 a partir de três réplicas:
helm upgrade local-web ./local-web-chart --set message=helm-v2 --set replicaCount=3
A saída esperada inclui:
Release "local-web" has been upgraded.
STATUS: deployed
Aguarde o Deployment atualizado:
kubectl rollout status deployment/local-web-web --timeout=120s
Saída esperada:
deployment "local-web-web" successfully rolled out
Inspecione o histórico do release e os valores atualmente armazenados com ele:
helm history local-web
helm get values local-web
A saída esperada inclui duas revisões e os valores sobrescritos:
REVISION
1
2
message: helm-v2
replicaCount: 3
Verifique o Deployment em execução e a resposta da aplicação:
kubectl get deployment local-web-web
kubectl exec chart-client -- wget -qO- http://local-web
A saída esperada inclui:
3/3
helm-v2
Resumo
Você criou um Helm chart local a partir de metadados, valores padrão e templates do Kubernetes. Você renderizou o chart antes de instalá-lo, instalou-o como um release, testou o Service e atualizou o release sobrescrevendo valores. O conceito principal é que o Helm empacota o trabalho repetível de implantação de aplicações, enquanto ainda produz objetos comuns do Kubernetes que você pode inspecionar com o kubectl.
