Preguntas — ¿Comprendiste Helm y el proyecto 13?

Proyecto projet13-kubernetes-helm-tp · 36 preguntas de autoevaluación

Estas preguntas tratan precisamente de ESTE proyecto (chart/, values.yaml, values-dev.yaml, _helpers.tpl, apps/portail, las tres averías). Responde antes de desplegar la corrección. Las respuestas correctas están repartidas entre A, B, C y D.

Tabla de contenidos

---

A — Helm: ideas de base

1. En una frase, ¿qué hace Helm?

• A) Sustituye a Kubernetes: ya no hace falta kubectl
• B) Genera manifiestos Kubernetes a partir de templates y de valores, y luego los aplica como una unidad versionada
• C) Construye las imágenes Docker en lugar de docker build
• D) Solo sirve para instalar aplicaciones desde Internet

Corrección

B. Helm renderiza templates YAML con variables (values.yaml) y luego aplica el resultado en el clúster bajo el nombre de una release. kubectl sigue siendo imprescindible para observar el clúster.

2. ¿Qué es una release Helm?

• A) Una nueva versión del código Python de la aplicación
• B) Un archivo Chart.yaml firmado
• C) Una instalación concreta de un Chart, identificada por un nombre (hedge-dev, hedge-staging, hedge-prod)
• D) Un namespace Kubernetes

Corrección

C. Un mismo Chart puede instalarse varias veces. Cada instalación es una release. El namespace es el lugar de aislamiento; la release es el objeto Helm.

3. En este proyecto, ¿qué afirmación es cierta?

• A) {{ .Chart.Name }} cambia en cada helm install, {{ .Release.Name }} se queda idéntico
• B) {{ .Release.Name }} cambia en cada helm install, {{ .Chart.Name }} se queda idéntico
• C) Los dos se quedan idénticos
• D) Los dos cambian en cada helm upgrade

Corrección

B. El Chart se llama siempre hedge. El nombre de release (hedge-dev, hedge-staging, hedge-prod) cambia en cada instalación. Ese contraste es el que permite el multi-entorno.

4. ¿Qué comando produce el YAML sin desplegar nada en el clúster?

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

Corrección

D. helm template es un render seco. helm lint verifica la sintaxis, pero no muestra los manifiestos. install y upgrade tocan el clúster.

5. ¿Para qué sirve un archivo cuyo nombre empieza por _ en templates/ (ejemplo: _helpers.tpl)?

• A) Helm lo aplica primero, antes que todos los demás
• B) Produce un manifiesto Kubernetes llamado _helpers
• C) No produce ningún manifiesto: define funciones reutilizables (define / include)
• D) Helm lo ignora por completo

Corrección

C. El prefijo _ significa «solo helper». Las funciones se llaman después con {{ include "hedge.labels" ... }}.

6. En Chart.yaml, ¿cuál es la diferencia entre version y appVersion?

• A) Ninguna: son dos alias del mismo campo
• B) version es la versión del Chart (empaquetado Helm); appVersion es la versión de la aplicación desplegada
• C) version es el número de revisión Helm; appVersion es el tag Docker
• D) version sirve a Kubernetes; appVersion sirve a Helm

Corrección

B. Se puede cambiar version (por ejemplo 0.1.0 a 0.2.0) sin cambiar el código de la aplicación, e inversamente. No es el número de revisión (helm history), ni automáticamente el tag de imagen.

---

B — Anatomía del Chart hedge

7. En este proyecto, ¿qué contiene la carpeta apps/?

• A) Los templates Helm a completar
• B) El código Python del portail y de la api, que no hay que modificar
• C) Los tres archivos values-<env>.yaml
• D) El script valider.ps1

Corrección

B. Tú eres el DevOps: el código de la aplicación ya está escrito. Modificar apps/ está prohibido por el reglamento del TP.

8. ¿Por qué la carpeta chart/casses/ no está dentro de chart/templates/?

• A) Helm rechaza los archivos cuyo nombre empieza por casse-
• B) Para que Helm no los cargue automáticamente: los copias uno a uno en templates/ para observar el bug
• C) Kubernetes no acepta más de 5 archivos en templates/
• D) Esos archivos son imágenes Docker, no templates

Corrección

B. Helm renderiza todos los archivos de templates/ (salvo los prefijados por _). Dejar las averías en casses/ evita romper el Chart antes de la misión 6.

9. En el values.yaml de este proyecto, ¿en qué puerto escucha el contenedor portail?

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

Corrección

C. portail.service.targetPort: 5000 (es el puerto Flask). port: 80 es el puerto del Service. nodePort: 30130 es el puerto expuesto en la máquina (DEV). 8000 es el targetPort de la api.

10. En este proyecto, ¿qué tipo de Service está previsto para la api en values.yaml?

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

Corrección

D. La api se queda interna al clúster. El portal la llama por DNS (http://hedge-dev-api). Solo el portal está en NodePort para el navegador.

11. ¿Cuántas imágenes Docker debes construir una sola vez antes de desplegar los tres entornos?

• A) Una sola (hedge:1.0)
• B) Dos (hedge-portail:1.0 y hedge-api:1.0)
• C) Tres (una por entorno)
• D) Seis (dos imágenes × tres entornos)

Corrección

B. Los tres entornos reutilizan las mismas imágenes. Lo que cambia son los valores inyectados (color, replicas, mensaje), no el código.

12. El portal muestra una franja de color y un mensaje. ¿De dónde vienen esas informaciones?

• A) Están codificadas a pelo en apps/portail/app.py
• B) Vienen de variables de entorno inyectadas por Helm desde las Values
• C) Se leen en un archivo couleur.txt montado en volumen
• D) Flask las elige al azar al arrancar

Corrección

B. app.py lee THEME_COLOR, BANNIERE_MESSAGE, ENVIRONMENT, etc. El mismo código se adapta a DEV / STAGING / PROD sin modificación.

---

C — Templates, Values y helpers

13. ¿Qué renderiza {{ .Values.portail.replicas }} si values-prod.yaml contiene portail.replicas: 3 y lo instalas con -f values-prod.yaml?

• A) 1 (el valor de values.yaml gana siempre)
• B) 3 (el archivo pasado con -f sobrescribe values.yaml)
• C) Un error: no se puede tener la misma clave dos veces
• D) default

Corrección

B. values.yaml da los valores por defecto. Cada values-<env>.yaml sobrescribe solo lo que cambia. Es el principio mismo del multi-entorno.

14. ¿Por qué un archivo values-prod.yaml que redefine portail.image.repository es un error pedagógico en este proyecto?

• A) Porque el campo repository no existe
• B) Porque la imagen es idéntica en los tres entornos: esa clave no tiene razón de copiarse
• C) Porque Helm rechaza más de 10 claves en un archivo de valores
• D) Porque el repository debe definirse solo en Chart.yaml

Corrección

B. En values-<env>.yaml solo se recopia lo que distingue el entorno (replicas, nodePort, color, mensaje, environment). Recopiar el resto es volver al copiar-pegar que Helm debía sustituir.

15. En este proyecto, el helper hedge.fullname debe producir, para la release hedge-dev y el componente portail:

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

Corrección

C. Formato <release>-<composant>. Ese prefijo es el que evita las colisiones de nombres entre DEV, STAGING y PROD (e incluso en un mismo namespace).

16. ¿Qué labels deben figurar solas en hedge.selectorLabels?

• A) name, instance, component — las tres que no cambiarán nunca para esta instancia
• B) Todas las labels de hedge.labels, incluidas version y hedge/environment
• C) Solo hedge/environment
• D) Solo helm.sh/chart

Corrección

A. spec.selector.matchLabels es inmutable. Poner ahí version, helm.sh/chart o hedge/environment hará fallar el primer helm upgrade que cambie esos valores.

17. ¿Por qué BACKEND_URL del portal no puede valer http://api a pelo?

• A) Porque Flask rechaza las URL sin número de puerto
• B) Porque el Service se llama hedge-<release>-api (p. ej. hedge-dev-api): el nombre DNS depende de la release
• C) Porque la api no tiene Service
• D) Porque el portal nunca llama a la api

Corrección

B. El helper hedge.fullname construye hedge-dev-api, hedge-staging-api, hedge-prod-api. Un nombre a pelo api no resuelve nada en el namespace.

18. ¿Qué hace {{ .Values.environment | quote }}?

• A) Convierte el valor en entero
• B) Añade comillas alrededor del valor renderizado (imprescindible para una string YAML)
• C) Muestra el valor en mayúsculas
• D) Ignora el valor si está vacío

Corrección

B. quote produce "dev" en vez de dev. Sin comillas, ciertos valores YAML (colores hexadecimales, mensajes) pueden romper el manifiesto.

19. ¿Por qué replicas: "{{ .Values.portail.replicas }}" (con comillas alrededor de todo el template) es peligroso?

• A) Helm rechaza las comillas en un Deployment
• B) Kubernetes espera un entero; el renderizado se convierte en la cadena "1", que la API rechaza
• C) El valor será siempre 0
• D) Las comillas multiplican el número de replicas por dos

Corrección

B. Nunca pongas comillas a un entero. Se escribe replicas: {{ .Values.portail.replicas }}, no replicas: "{{ ... }}".

20. ¿Para qué sirve nindent 4 en {{ include "hedge.labels" ... | nindent 4 }}?

• A) Para limitar el helper a 4 labels
• B) Para indentar correctamente el YAML renderizado (si no, el manifiesto es ilegible o inválido)
• C) Para crear 4 replicas
• D) Para esperar 4 segundos antes del renderizado

Corrección

B. Helm inyecta un bloque de varias líneas. Sin nindent, la indentación YAML se rompe y obtienes error converting YAML to JSON.

---

D — Los tres entornos

21. En este proyecto, ¿qué nodePort está reservado a STAGING?

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

Corrección

B. DEV = 30130, STAGING = 30131, PROD = 30132. El 30500 es el portal del proyecto 12, no de este.

22. ¿Cuántas replicas portail + api debes tener en PROD una vez el Chart correctamente desplegado?

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

Corrección

C. PROD: 3 portales y 3 apis. DEV: 1+1. STAGING: 2+2. En total, 12 Pods de aplicación lado a lado.

23. ¿Qué color de franja corresponde al entorno DEV?

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

Corrección

D. Azul = DEV, naranja = STAGING, verde = PROD. El gris #64748b es el color por defecto de values.yaml (entorno default), no el de uno de los tres archivos de entorno.

24. ¿Por qué desplegar cada entorno en su propio namespace (hedge-dev, hedge-staging, hedge-prod)?

• A) Helm rechaza dos releases en el mismo namespace, aunque tengan nombres distintos
• B) Para aislar los objetos, evitar colisiones de NodePort internas y pegarse a la realidad de una empresa (un namespace por entorno)
• C) Porque Docker Desktop solo autoriza un namespace
• D) Porque values.yaml lo impone

Corrección

B. Helm autoriza varias releases en un mismo namespace (es precisamente la trampa de la avería 1 si los nombres van a pelo). Los namespaces siguen siendo la buena práctica: aislamiento, quotas, RBAC, claridad.

25. ¿Qué comando instala correctamente el entorno DEV de este proyecto?

• 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

Corrección

B. Se apunta al Chart (.\chart), se sobrescribe con -f values-dev.yaml, se nombra la release hedge-dev, se crea el namespace. helm template no despliega nada. values-dev.yaml no es un manifiesto kubectl.

26. Si abres http://localhost:30132 y la franja es verde, ¿qué ves necesariamente en el JSON /api-json?

• A) "env": "dev"
• B) "env": "staging"
• C) "env": "prod" y "backend": "ok" si la api del mismo namespace responde
• D) "env": "default"

Corrección

C. El puerto 30132 es el de PROD. El campo env viene de .Values.environment. backend: ok prueba que BACKEND_URL apunta bien al Service api de esta release.

---

E — install, upgrade, rollback

27. Después de helm install hedge-dev ... y luego helm upgrade hedge-dev ... --set portail.replicas=5, ¿qué muestra helm history hedge-dev -n hedge-dev?

• A) Una sola revisión: Helm borra el historial
• B) Al menos dos revisiones: 1 = Install, 2 = Upgrade
• C) Cero revisiones: el historial solo existe después de un rollback
• D) Solo la revisión 5, porque replicas vale 5

Corrección

B. Cada install / upgrade / rollback crea una revisión. Ese diario es el que hace posible la vuelta atrás.

28. ¿Qué hace helm rollback hedge-dev 1 -n hedge-dev?

• A) Elimina la release
• B) Vuelve a aplicar el estado de la revisión 1 y crea una nueva revisión (a menudo n.º 3) descrita como Rollback to 1
• C) Vuelve al código Git del primer commit
• D) Pone values.yaml a cero en el disco

Corrección

B. El rollback no borra el historial: añade una revisión. values-dev.yaml en tu disco no cambia.

29. ¿Cuál es la diferencia fundamental entre helm upgrade --set portail.replicas=5 y kubectl scale deploy/hedge-dev-portail --replicas=5?

• A) Ninguna: los dos hacen exactamente lo mismo
• B) kubectl scale es más lento
• C) helm upgrade queda trazado y anulable por Helm; kubectl scale sale del control de Helm y será pisado en el próximo upgrade sin --set
• D) Kubernetes prohíbe kubectl scale sobre un objeto creado por Helm

Corrección

C. Helm reconverge hacia las Values en el próximo upgrade. Una modificación manual (scale, edit) es una deuda invisible. Es la pregunta de reflexión de la misión 5.

30. ¿helm uninstall hedge-dev -n hedge-dev elimina el namespace hedge-dev?

• A) Sí, siempre
• B) No: retira los objetos de la release, no el namespace (salvo si lo eliminas después con kubectl delete namespace)
• C) Sí, pero solo si el namespace está vacío
• D) No, y los Deployments se quedan en su sitio

Corrección

B. uninstall quita Deployment, Service, etc. de la release. El namespace sobrevive. De ahí el comando de limpieza del README: kubectl delete namespace hedge-dev ....

31. ¿Qué ocurre si haces kubectl delete pod hedge-dev-portail-xxxxx -n hedge-dev sobre un Pod creado por el Deployment Helm?

• A) El Pod desaparece para siempre; Helm muestra un error
• B) El Deployment recrea de inmediato un Pod; Helm no tiene nada que «saber»: gestiona el Deployment, no cada Pod
• C) Se matan todos los Pods del namespace
• D) Helm lanza automáticamente un rollback

Corrección

B. Helm declara el Deployment. Kubernetes mantiene el número de replicas. Eliminar un Pod es el gesto pedagógico de autorreparación, no una avería Helm.

---

F — Las tres averías del proyecto

32. Avería 1 (casse-1-configmap.yaml): ¿por qué falla la segunda release en el mismo namespace?

• A) Porque Helm solo autoriza una release por clúster
• B) Porque metadata.name: hedge-config es un nombre estático: las dos releases se disputan el mismo objeto
• C) Porque el ConfigMap no tiene data
• D) Porque values-staging.yaml es inválido

Corrección

B. El correctivo es prefijar el nombre con la release: {{ include "hedge.fullname" (dict "root" . "composant" "config") }} produce hedge-dev-config y hedge-staging-config.

33. Avería 2 (casse-2-worker-deployment.yaml): ¿qué mensaje Kubernetes ves en el 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

Corrección

C. hedge/environment está en matchLabels. Cambiar environment cambia el selector, cosa que Kubernetes rechaza. A y B son los síntomas de las averías 3 y 1.

34. En un Deployment, ¿dónde se tiene derecho a poner la label hedge/environment?

• A) Solo en spec.selector.matchLabels
• B) En las labels del Pod (template.metadata.labels) y las labels del objeto, no en matchLabels
• C) En ningún sitio: Kubernetes prohíbe esta label
• D) Solo en Chart.yaml

Corrección

B. Las labels del Pod pueden ser ricas y variables. El selector debe seguir siendo un subconjunto estable. Esa es toda la distinción hedge.labels vs hedge.selectorLabels.

35. Avería 3 (casse-3-cache-deployment.yaml): ¿qué significa el error nil pointer evaluating interface {}.replicas sobre .Values.portal.replicas?

• A) El clúster ya no tiene RAM
• B) El path es falso: values.yaml define portail (con una i), no portal — Helm evalúa nil.replicas
• C) Hay que escribir .Release.portal.replicas
• D) El campo replicas está prohibido en un Deployment creado por Helm

Corrección

B. Una sola letra de más. Primer reflejo: helm template --debug y leer el path en el mensaje de error.

36. Mañana debes añadir un 4.º entorno pre-prod. ¿Qué archivos creas, cuáles no tocas?

• A) Duplicas toda la carpeta chart/ y renombras el Chart
• B) Creas únicamente chart/environments/values-preprod.yaml (y un helm install + namespace); los templates y values.yaml se quedan iguales
• C) Añades un 4.º Deployment a pelo en templates/
• D) Modificas apps/portail/app.py para reconocer pre-prod

Corrección

B. Es la promesa de Helm: un Chart, N archivos de valores. Si tienes que tocar los templates para un entorno nuevo, el Chart está mal diseñado.

---

Corrección recapitulativa

Puntuación indicativa: 30/36 o más = puedes explicar el proyecto a un compañero. Por debajo de 24/36, reléelas secciones «Conceptos esenciales», «Misión 3» y «Misión 6» de 00-ENONCE.md.

---

Curso creado por el Dr. Haythem REHOUMA — Desarrollo y despliegue de soluciones de datos