CKA · Módulo 3 K8s v1.34 parte de Cluster Arch 25%

Helm, Kustomize y CRDs

Las tres formas de manejar aplicaciones y extender Kubernetes: paquetes con plantillas (Helm), personalización sin plantillas (Kustomize), y cómo el cluster aprende recursos nuevos (CRDs y Operators).

Duración60 min

ContenidoNuevo en CKA

DificultadMedia

EnfoqueUso, no autoría

Este módulo cubre tres herramientas que agregaron al CKA en las versiones recientes. La buena noticia: te piden usarlas, no ser un experto. Con Helm vas a instalar/actualizar/desinstalar charts; con Kustomize vas a aplicar overlays; y con CRDs vas a entender cómo se extiende Kubernetes con recursos propios. El objetivo es reconocer qué es cada una y ejecutar las operaciones básicas rápido.

3.1

Helm

El "gestor de paquetes" de K8s. install, upgrade, rollback, values.

3.2

Kustomize

Personalizar manifiestos sin plantillas. bases + overlays.

3.3

CRDs y Operators

Enseñarle recursos nuevos al cluster. El patrón operator.

3.1

Gestor de paquetes · 25 min

Helm

Si apt instala paquetes en Linux, Helm instala aplicaciones en Kubernetes.

Práctica · Comandos

Repos: de dónde salen los charts

# Agregar un repo
helm repo add bitnami https://charts.bitnami.com/bitnami

# Actualizar el índice de repos
helm repo update

# Buscar un chart
helm search repo nginx

Instalar / listar / desinstalar

# Instalar un chart como un "release" con nombre
helm install miweb bitnami/nginx

# Listar releases instalados
helm list
helm list -A          # todos los namespaces

# Desinstalar
helm uninstall miweb

Values: personalizar la instalación

# Ver los values por defecto de un chart
helm show values bitnami/nginx

# Instalar sobreescribiendo un value
helm install miweb bitnami/nginx \
  --set replicaCount=3

# O con un archivo de values propio
helm install miweb bitnami/nginx -f myvalues.yaml

Upgrade y rollback

# Actualizar un release (cambiar values o versión)
helm upgrade miweb bitnami/nginx --set replicaCount=5

# Ver el historial de revisiones
helm history miweb

# Volver a una revisión anterior
helm rollback miweb 1

★

Comando útil de examen: helm install --dry-run --debug renderiza los manifiestos SIN instalarlos. Sirve para ver qué YAML va a generar el chart antes de aplicarlo, o para debug.

Teoría · Conceptos

El vocabulario de Helm

Término	Qué es
Chart	El "paquete": plantillas + valores por defecto
Release	Una instalación con nombre de un chart
Values	Parámetros que personalizan el chart
Repo	Colección de charts (como un repo apt)
Revision	Cada versión de un release (para rollback)

La analogía con apt

repo add ≈ agregar un repo apt
chart ≈ un paquete .deb
install ≈ apt install
values ≈ opciones de configuración
release ≈ el paquete ya instalado y corriendo

Por qué existe Helm

Una app real son muchos manifiestos (deployment, service, configmap, ingress...). Helm los empaqueta con plantillas parametrizables, así instalás todo con un comando y personalizás con values, en vez de editar 10 YAMLs a mano.

★

Un release recuerda sus revisiones. Cada upgrade crea una revisión nueva; el rollback vuelve a una anterior. Es como el historial de un deployment, pero a nivel de toda la app.

3.2

Personalización sin plantillas · 20 min

Kustomize

Adaptar manifiestos por entorno (dev/prod) sin plantillas ni variables.

Práctica · Estructura y comandos

La estructura base + overlays

# Estructura típica:
# base/
#   kustomization.yaml
#   deployment.yaml
#   service.yaml
# overlays/
#   dev/   kustomization.yaml
#   prod/  kustomization.yaml

El kustomization.yaml de la base

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

Un overlay que personaliza la base

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
replicas:
  - name: miapp
    count: 5
images:
  - name: nginx
    newTag: 1.27

Aplicar con kubectl (built-in)

# Ver el resultado renderizado (sin aplicar)
k kustomize overlays/prod

# Aplicar directamente (el -k activa kustomize)
k apply -k overlays/prod

# Borrar lo aplicado
k delete -k overlays/prod

★

Lo clave para el examen: kubectl apply -k <dir>. La -k le dice a kubectl "esto es un directorio kustomize, no un archivo". Kustomize ya viene integrado en kubectl, no instalás nada.

Teoría · La idea central

Base + Overlay

base: los manifiestos "genéricos" comunes a todos los entornos
overlay: los cambios específicos por entorno (más réplicas en prod, otra imagen en dev...)

El overlay referencia la base y le aplica parches encima. No copiás los manifiestos; los reutilizás.

Kustomize vs Helm

Kustomize	Helm
Sin plantillas	Con plantillas
Parches sobre YAML real	Variables en templates
Integrado en kubectl	Herramienta aparte
Bueno para variantes	Bueno para empaquetar/distribuir

★

Kustomize NO usa plantillas ni variables. Trabaja sobre YAML válido de verdad, aplicándole parches. Por eso los archivos base son manifiestos normales que también podés kubectl apply -f solos.

3.3

Extender Kubernetes · 15 min

CRDs y Operators

Cómo el cluster aprende tipos de recursos que no vienen de fábrica.

Práctica · Ver y usar

Ver los CRDs instalados

# Listar todos los CRDs del cluster
k get crds

# Ver un CRD en detalle
k describe crd <nombre>

# Recordá: Calico instaló varios CRDs en tu cluster
k get crds | grep calico

Anatomía de un CRD (simplificado)

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.miempresa.com
spec:
  group: miempresa.com
  names:
    kind: Backup
    plural: backups
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true

Usar el recurso nuevo (una vez instalado el CRD)

# Ahora 'Backup' es un tipo válido, como si fuera nativo
k get backups
k apply -f mi-backup.yaml

★

En el examen probablemente te pidan k get crds o instalar un CRD desde un manifiesto dado y luego crear un recurso de ese tipo. No te van a pedir escribir un CRD desde cero.

Teoría · El concepto

Qué es un CRD

Un Custom Resource Definition le enseña al API server un tipo de recurso nuevo. Después de instalarlo, podés crear objetos de ese tipo (kubectl get/apply) como si fueran nativos (pods, services).

CRD vs Custom Resource

CRD: la definición del tipo nuevo (el "molde")
CR: una instancia de ese tipo (el objeto concreto)

Igual que un Deployment (tipo) vs "mi-deployment" (instancia).

Qué es un Operator

Un Operator = CRD + un controller que lo vigila. El controller observa los CR de ese tipo y actúa (crea pods, hace backups, lo que sea). Automatiza tareas operativas que haría un humano.

★

El patrón operator lleva la lógica de "estado deseado" (Módulo 1) a recursos custom: definís un Backup, y el operator se encarga de que ese backup realmente ocurra, igual que el deployment controller mantiene tus réplicas.

★

Cierre del módulo

Lo que te llevás del Módulo 3

Resumen · Comandos clave

Para tu agenda

# HELM
helm repo add NAME URL && helm repo update
helm install RELEASE repo/chart --set key=val
helm list -A
helm upgrade RELEASE repo/chart -f values.yaml
helm rollback RELEASE REVISION
helm uninstall RELEASE

# KUSTOMIZE
k kustomize DIR        # ver renderizado
k apply -k DIR         # aplicar

# CRDs
k get crds
k apply -f crd.yaml && k get <nuevo-tipo>

Teoría · Lo esencial

Las 3 ideas que no se negocian

Helm = gestor de paquetes. Chart (paquete) → Release (instalación). install/upgrade/rollback/uninstall.
Kustomize = base + overlays, sin plantillas. kubectl apply -k. Ya viene en kubectl.
CRD = tipo de recurso nuevo. CR = instancia. Operator = CRD + controller que actúa.

★

Para el examen: Helm y Kustomize son sobre ejecutar operaciones (instalar, actualizar, aplicar overlays). CRDs es sobre reconocer y usar tipos custom. Nada de autoría compleja.

Checkpoint Módulo 3: Helm (install/upgrade/rollback), Kustomize (apply -k), y CRDs/Operators entendidos. Cierra el dominio Cluster Architecture (25%). Siguiente: Módulo 4 — Workloads & Scheduling.

Módulo 3 completado · Cierra Cluster Architecture (25% del examen) · Siguiente: Workloads & Scheduling