Questões — Você entendeu Helm e o projeto 13?

Projeto projet13-kubernetes-helm-tp · 36 perguntas de autoavaliação

Estas perguntas incidem precisamente sobre ESTE projeto (chart/, values.yaml, values-dev.yaml, _helpers.tpl, apps/portail, as três avarias). Responda antes de abrir a correção. As respostas certas estão distribuídas entre A, B, C e D.

Índice

---

A — Helm: ideias de base

1. Numa frase, o que faz o Helm?

• A) Substitui o Kubernetes: já não precisa de kubectl
• B) Gera manifestos Kubernetes a partir de templates e de valores, e depois aplica-os como uma unidade versionada
• C) Constrói as imagens Docker no lugar de docker build
• D) Serve apenas para instalar aplicações a partir da Internet

Correção

B. O Helm renderiza templates YAML com variáveis (values.yaml) e depois aplica o resultado no cluster sob o nome de uma release. O kubectl continua indispensável para observar o cluster.

2. O que é uma release Helm?

• A) Uma nova versão do código Python da aplicação
• B) Um ficheiro Chart.yaml assinado
• C) Uma instalação concreta de um Chart, identificada por um nome (hedge-dev, hedge-staging, hedge-prod)
• D) Um namespace Kubernetes

Correção

C. O mesmo Chart pode ser instalado várias vezes. Cada instalação é uma release. O namespace é o local de isolamento; a release é o objeto Helm.

3. Neste projeto, qual afirmação é verdadeira?

• A) {{ .Chart.Name }} muda em cada helm install, {{ .Release.Name }} permanece idêntico
• B) {{ .Release.Name }} muda em cada helm install, {{ .Chart.Name }} permanece idêntico
• C) Os dois permanecem idênticos
• D) Os dois mudam em cada helm upgrade

Correção

B. O Chart chama-se sempre hedge. O nome da release (hedge-dev, hedge-staging, hedge-prod) muda em cada instalação. É este contraste que permite o multiambiente.

4. Qual comando produz o YAML sem implantar nada no cluster?

• A) helm install
• B) helm upgrade
• C) helm lint
• D) helm template

Correção

D. helm template é uma renderização seca. helm lint verifica a sintaxe, mas não mostra os manifestos. install e upgrade tocam no cluster.

5. Para que serve um ficheiro cujo nome começa por _ em templates/ (exemplo: _helpers.tpl)?

• A) O Helm aplica-o em primeiro lugar, antes de todos os outros
• B) Produz um manifesto Kubernetes chamado _helpers
• C) Não produz nenhum manifesto: define funções reutilizáveis (define / include)
• D) É ignorado completamente pelo Helm

Correção

C. O prefixo _ significa «apenas helper». As funções chamam-se depois com {{ include "hedge.labels" ... }}.

6. Em Chart.yaml, qual é a diferença entre version e appVersion?

• A) Nenhuma: são dois alias do mesmo campo
• B) version é a versão do Chart (embalagem Helm); appVersion é a versão da aplicação implantada
• C) version é o número de revisão Helm; appVersion é a tag Docker
• D) version serve ao Kubernetes; appVersion serve ao Helm

Correção

B. Pode mudar version (por exemplo 0.1.0 para 0.2.0) sem mudar o código da aplicação, e inversamente. Não é o número de revisão (helm history), nem automaticamente a tag da imagem.

---

B — Anatomia do Chart hedge

7. Neste projeto, o que contém a pasta apps/?

• A) Os templates Helm a completar
• B) O código Python do portail e da api, a não modificar
• C) Os três ficheiros values-<env>.yaml
• D) O script valider.ps1

Correção

B. Você é o DevOps: o código da aplicação já está escrito. Modificar apps/ é proibido pelo regulamento do TP.

8. Por que a pasta chart/casses/ não está dentro de chart/templates/?

• A) O Helm recusa ficheiros cujo nome começa por casse-
• B) Para que o Helm não os carregue automaticamente: você copia-os um a um para templates/ a fim de observar o erro
• C) O Kubernetes não aceita mais de 5 ficheiros em templates/
• D) Estes ficheiros são imagens Docker, não templates

Correção

B. O Helm renderiza todos os ficheiros de templates/ (exceto os prefixados por _). Deixar as avarias em casses/ evita partir o Chart antes da missão 6.

9. Em values.yaml deste projeto, em que porta o contentor portail escuta?

• A) 80
• B) 30130
• C) 5000
• D) 8000

Correção

C. portail.service.targetPort: 5000 (é a porta Flask). port: 80 é a porta do Service. nodePort: 30130 é a porta exposta na máquina (DEV). 8000 é o targetPort da api.

10. Neste projeto, que tipo de Service está previsto para a api em values.yaml?

• A) NodePort
• B) LoadBalancer
• C) ExternalName
• D) ClusterIP

Correção

D. A api permanece interna ao cluster. O portal chama-a por DNS (http://hedge-dev-api). Só o portal está em NodePort para o navegador.

11. Quantas imagens Docker deve construir uma única vez antes de implantar os três ambientes?

• A) Uma só (hedge:1.0)
• B) Duas (hedge-portail:1.0 e hedge-api:1.0)
• C) Três (uma por ambiente)
• D) Seis (duas imagens × três ambientes)

Correção

B. Os três ambientes reutilizam as mesmas imagens. O que muda são os valores injetados (cor, replicas, mensagem), não o código.

12. O portal mostra um bandeau colorido e uma mensagem. De onde vêm estas informações?

• A) Estão escritas em concreto em apps/portail/app.py
• B) Vêm de variáveis de ambiente injetadas pelo Helm a partir dos Values
• C) São lidas num ficheiro couleur.txt montado em volume
• D) São escolhidas ao acaso pelo Flask no arranque

Correção

B. app.py lê THEME_COLOR, BANNIERE_MESSAGE, ENVIRONMENT, etc. O mesmo código adapta-se a DEV / STAGING / PROD sem alteração.

---

C — Templates, Values e helpers

13. O que renderiza {{ .Values.portail.replicas }} se values-prod.yaml contém portail.replicas: 3 e você instala com -f values-prod.yaml?

• A) 1 (o valor de values.yaml ganha sempre)
• B) 3 (o ficheiro passado com -f sobrepõe values.yaml)
• C) Um erro: não se pode ter a mesma chave duas vezes
• D) default

Correção

B. values.yaml fornece os valores por omissão. Cada values-<env>.yaml sobrepõe apenas o que muda. É o próprio princípio do multiambiente.

14. Por que um ficheiro values-prod.yaml que redefine portail.image.repository é um erro pedagógico neste projeto?

• A) Porque o campo repository não existe
• B) Porque a imagem é idêntica nos três ambientes: esta chave não tem razão para ser recopiada
• C) Porque o Helm recusa mais de 10 chaves num ficheiro de valores
• D) Porque o repository deve ser definido apenas em Chart.yaml

Correção

B. Recopia-se em values-<env>.yaml apenas o que distingue o ambiente (replicas, nodePort, cor, mensagem, environment). Recopiar o resto é voltar ao copiar-colar que o Helm deveria substituir.

15. Neste projeto, o helper hedge.fullname deve produzir, para a release hedge-dev e o componente portail:

• A) hedge-portail
• B) portail-hedge-dev
• C) hedge-dev-portail
• D) hedge

Correção

C. Formato <release>-<composant>. É este prefixo que evita as colisões de nomes entre DEV, STAGING e PROD (e até no mesmo namespace).

16. Quais labels devem apenas figurar em hedge.selectorLabels?

• A) name, instance, component — os três que nunca mudarão para esta instância
• B) Todos os labels de hedge.labels, incluindo version e hedge/environment
• C) Unicamente hedge/environment
• D) Unicamente helm.sh/chart

Correção

A. spec.selector.matchLabels é imutável. Colocar aí version, helm.sh/chart ou hedge/environment fará falhar o primeiro helm upgrade que mude estes valores.

17. Por que BACKEND_URL do portal não pode valer http://api em concreto?

• A) Porque o Flask recusa URLs sem número de porta
• B) Porque o Service chama-se hedge-<release>-api (ex. hedge-dev-api): o nome DNS depende da release
• C) Porque a api não tem Service
• D) Porque o portal nunca chama a api

Correção

B. O helper hedge.fullname constrói hedge-dev-api, hedge-staging-api, hedge-prod-api. Um nome em concreto api não resolve nada no namespace.

18. O que faz {{ .Values.environment | quote }}?

• A) Converte o valor em inteiro
• B) Acrescenta aspas à volta do valor renderizado (indispensável para uma string YAML)
• C) Mostra o valor em maiúsculas
• D) Ignora o valor se estiver vazio

Correção

B. quote produz "dev" em vez de dev. Sem aspas, certos valores YAML (cores hexadecimais, mensagens) podem partir o manifesto.

19. Por que replicas: "{{ .Values.portail.replicas }}" (com aspas à volta de todo o template) é perigoso?

• A) O Helm recusa aspas num Deployment
• B) O Kubernetes espera um inteiro; a renderização torna-se a cadeia "1", que a API recusa
• C) O valor será sempre 0
• D) As aspas multiplicam o número de replicas por dois

Correção

B. Nunca colocar aspas num inteiro. Escreve-se replicas: {{ .Values.portail.replicas }}, não replicas: "{{ ... }}".

20. Para que serve nindent 4 em {{ include "hedge.labels" ... | nindent 4 }}?

• A) Para limitar o helper a 4 labels
• B) Para indentar corretamente o YAML renderizado (senão o manifesto fica ilegível ou inválido)
• C) Para criar 4 replicas
• D) Para esperar 4 segundos antes da renderização

Correção

B. O Helm injeta um bloco de várias linhas. Sem nindent, a indentação YAML parte e obtém error converting YAML to JSON.

---

D — Os três ambientes

21. Neste projeto, que nodePort está reservado ao STAGING?

• A) 30130
• B) 30131
• C) 30132
• D) 30500

Correção

B. DEV = 30130, STAGING = 30131, PROD = 30132. O 30500 é o portal do projeto 12, não deste.

22. Quantas replicas portail + api deve ter em PROD depois de o Chart estar corretamente implantado?

• A) 1 + 1
• B) 2 + 2
• C) 3 + 3
• D) 5 + 1

Correção

C. PROD: 3 portais e 3 apis. DEV: 1+1. STAGING: 2+2. No total, 12 Pods de aplicação lado a lado.

23. Que cor de bandeau corresponde ao ambiente DEV?

• A) Laranja #ea580c
• B) Verde #16a34a
• C) Cinzento #64748b
• D) Azul #2563eb

Correção

D. Azul = DEV, laranja = STAGING, verde = PROD. O cinzento #64748b é a cor por omissão de values.yaml (ambiente default), não a de um dos três ficheiros de ambiente.

24. Por que implantar cada ambiente no seu próprio namespace (hedge-dev, hedge-staging, hedge-prod)?

• A) O Helm recusa duas releases no mesmo namespace, mesmo com nomes diferentes
• B) Para isolar os objetos, evitar colisões de NodePort internas e alinhar com a realidade de uma empresa (um namespace por ambiente)
• C) Porque o Docker Desktop só autoriza um namespace
• D) Porque values.yaml o impõe

Correção

B. O Helm autoriza várias releases no mesmo namespace (é aliás a armadilha da avaria 1 se os nomes estiverem em concreto). Os namespaces continuam a ser a boa prática: isolamento, quotas, RBAC, clareza.

25. Que comando instala corretamente o ambiente DEV deste projeto?

• A) kubectl apply -f chart/environments/values-dev.yaml
• B) helm install hedge-dev .\chart -f .\chart\environments\values-dev.yaml -n hedge-dev --create-namespace
• C) helm template hedge-dev .\chart
• D) docker compose up -d

Correção

B. Aponta-se para o Chart (.\chart), sobrepõe-se com -f values-dev.yaml, nomeia-se a release hedge-dev, cria-se o namespace. helm template não implanta nada. values-dev.yaml não é um manifesto kubectl.

26. Se abrir http://localhost:30132 e o bandeau estiver verde, o que vê necessariamente no JSON /api-json?

• A) "env": "dev"
• B) "env": "staging"
• C) "env": "prod" e "backend": "ok" se a api do mesmo namespace responder
• D) "env": "default"

Correção

C. A porta 30132 é a de PROD. O campo env vem de .Values.environment. backend: ok prova que BACKEND_URL aponta mesmo para o Service api desta release.

---

E — install, upgrade, rollback

27. Depois de helm install hedge-dev ... e depois helm upgrade hedge-dev ... --set portail.replicas=5, o que mostra helm history hedge-dev -n hedge-dev?

• A) Uma só revisão: o Helm apaga o histórico
• B) Pelo menos duas revisões: 1 = Install, 2 = Upgrade
• C) Zero revisões: o histórico só existe depois de um rollback
• D) Unicamente a revisão 5, porque replicas vale 5

Correção

B. Cada install / upgrade / rollback cria uma revisão. É este diário que torna possível o retorno atrás.

28. helm rollback hedge-dev 1 -n hedge-dev faz o quê?

• A) Apaga a release
• B) Reaplica o estado da revisão 1 e cria uma nova revisão (muitas vezes n.º 3) descrita como Rollback to 1
• C) Volta ao código Git do primeiro commit
• D) Repõe values.yaml a zero no disco

Correção

B. O rollback não apaga o histórico: acrescenta uma revisão. values-dev.yaml no seu disco não muda.

29. Qual é a diferença fundamental entre helm upgrade --set portail.replicas=5 e kubectl scale deploy/hedge-dev-portail --replicas=5?

• A) Nenhuma: os dois fazem exatamente a mesma coisa
• B) kubectl scale é mais lento
• C) helm upgrade é rastreado e anulável pelo Helm; kubectl scale sai do controlo do Helm e será substituído no próximo upgrade sem --set
• D) kubectl scale é proibido pelo Kubernetes num objeto criado pelo Helm

Correção

C. O Helm reconverge para os Values no próximo upgrade. Uma alteração manual (scale, edit) é uma dívida invisível. É a questão de reflexão da missão 5.

30. helm uninstall hedge-dev -n hedge-dev apaga o namespace hedge-dev?

• A) Sim, sempre
• B) Não: retira os objetos da release, não o namespace (salvo se o apagar depois com kubectl delete namespace)
• C) Sim, mas só se o namespace estiver vazio
• D) Não, e os Deployments permanecem no sítio

Correção

B. uninstall retira Deployment, Service, etc. da release. O namespace sobrevive. Daí o comando de limpeza do README: kubectl delete namespace hedge-dev ....

31. O que acontece se fizer kubectl delete pod hedge-dev-portail-xxxxx -n hedge-dev num Pod criado pelo Deployment Helm?

• A) O Pod desaparece definitivamente; o Helm mostra um erro
• B) O Deployment recria imediatamente um Pod; o Helm não tem de «saber» nada: gere o Deployment, não cada Pod
• C) Todos os Pods do namespace são mortos
• D) O Helm lança automaticamente um rollback

Correção

B. O Helm declara o Deployment. O Kubernetes mantém o número de replicas. Apagar um Pod é o gesto pedagógico de autorreparação, não uma avaria Helm.

---

F — As três avarias do projeto

32. Avaria 1 (casse-1-configmap.yaml): por que a segunda release no mesmo namespace falha?

• A) Porque o Helm só autoriza uma release por cluster
• B) Porque metadata.name: hedge-config é um nome estático: as duas releases disputam o mesmo objeto
• C) Porque o ConfigMap não tem data
• D) Porque values-staging.yaml é inválido

Correção

B. A correção é prefixar o nome com a release: {{ include "hedge.fullname" (dict "root" . "composant" "config") }} produz hedge-dev-config e hedge-staging-config.

33. Avaria 2 (casse-2-worker-deployment.yaml): que mensagem Kubernetes vê no helm upgrade --set environment=recette?

• A) nil pointer evaluating interface {}.replicas
• B) ConfigMap "hedge-config" exists and cannot be imported
• C) spec.selector: Invalid value: ...: field is immutable
• D) ImagePullBackOff

Correção

C. hedge/environment está em matchLabels. Mudar environment muda o seletor, o que o Kubernetes recusa. A e B são os sintomas das avarias 3 e 1.

34. Num Deployment, onde se tem o direito de colocar o label hedge/environment?

• A) Unicamente em spec.selector.matchLabels
• B) Nos labels do Pod (template.metadata.labels) e nos labels do objeto, não em matchLabels
• C) Em lado nenhum: este label é proibido pelo Kubernetes
• D) Unicamente em Chart.yaml

Correção

B. Os labels do Pod podem ser ricos e variáveis. O seletor deve permanecer um subconjunto estável. É toda a distinção hedge.labels vs hedge.selectorLabels.

35. Avaria 3 (casse-3-cache-deployment.yaml): o que significa o erro nil pointer evaluating interface {}.replicas em .Values.portal.replicas?

• A) O cluster já não tem RAM
• B) O caminho está errado: values.yaml define portail (com um i), não portal — o Helm avalia nil.replicas
• C) É preciso escrever .Release.portal.replicas
• D) O campo replicas é proibido num Deployment criado pelo Helm

Correção

B. Uma só letra a mais. Primeiro reflexo: helm template --debug e ler o caminho na mensagem de erro.

36. Precisa de acrescentar amanhã um 4.º ambiente pre-prod. Que ficheiros cria, quais não toca?

• A) Duplica toda a pasta chart/ e muda o nome do Chart
• B) Cria apenas chart/environments/values-preprod.yaml (e um helm install + namespace); os templates e values.yaml permanecem inalterados
• C) Acrescenta um 4.º Deployment em concreto em templates/
• D) Modifica apps/portail/app.py para reconhecer pre-prod

Correção

B. É a promessa do Helm: um Chart, N ficheiros de valores. Se tiver de tocar nos templates para um novo ambiente, o Chart está mal concebido.

---

Correção recapitulativa

Pontuação indicativa: 30/36 ou mais = consegue explicar o projeto a um colega. Abaixo de 24/36, releia as secções «Conceitos essenciais», «Missão 3» e «Missão 6» de 00-ENONCE.md.

---

Curso criado pelo Dr. Haythem REHOUMA — Desenvolvimento e implantação de soluções de dados