Hasta ahora hemos decidido qué se ejecuta y cómo se compone cada pod, pero nunca dónde. El kube-scheduler ha ido colocando nuestros pods en los nodos que le han parecido y no nos hemos quejado, porque en un clúster homogéneo de pruebas cualquier sitio vale.

En producción no vale cualquier sitio. postgres-reservas necesita el nodo con disco SSD, porque en un disco mecánico las consultas de ocupación tardan cinco veces más. Las seis réplicas de api-reservas no deberían estar todas en el mismo nodo: si ese nodo se reinicia, la API entera desaparece justo cuando alguien está pagando un billete. Y las cargas de análisis pesadas no deberían competir por CPU con la venta de billetes en un puente festivo.

Todo eso se expresa con tres mecanismos que estudiaremos aquí: afinidad (el pod elige nodo), antiafinidad (el pod evita compañía) y taints con tolerations (el nodo rechaza pods). Al final tendremos el plan de planificación completo de Rutas Norte y sabremos diagnosticar el pod que se queda Pending para siempre.

1. Cómo decide el kube-scheduler: filtrado y puntuación
2. nodeName y nodeSelector: los mecanismos básicos
3. Afinidad de nodo: required frente a preferred
4. Afinidad y antiafinidad entre pods: topologyKey
5. Taints y tolerations: el nodo rechaza
6. Taints automáticos de Kubernetes
7. PriorityClass y preemption
8. topologySpreadConstraints: mención y remisión
9. El plan de planificación de Rutas Norte
10. Diagnóstico del pod eternamente Pending

En la lección 01-02 dijimos que el scheduler "asigna pods a nodos". Ahora vemos cómo.

Cuando un pod se crea, su campo spec.nodeName está vacío. El scheduler observa esos pods sin asignar y, para cada uno, ejecuta un ciclo de dos fases.

Se descartan los nodos que no pueden alojar el pod. Cada comprobación es un veto absoluto: basta una para eliminar al nodo.

Un detalle que conecta con el módulo 5: el filtro VolumeBinding es el que hace funcionar volumeBindingMode: WaitForFirstConsumer. Un PVC ya vinculado a un volumen de la zona eu-west-1a elimina del filtrado todos los nodos de las demás zonas.

Y otro que conecta con el módulo 3: NodeResourcesFit mira requests, no el uso real. Un nodo con 8 CPU donde los pods han reservado 7,8 CPU pero solo usan 0,5 se considera lleno. Por eso unos requests inflados desperdician clúster.

De los nodos viables, cada complemento de puntuación otorga entre 0 y 100 puntos, y se hace una media ponderada.

Gana el de mayor puntuación; si empatan, se elige al azar entre los empatados. El scheduler escribe entonces el nodeName y el kubelet de ese nodo recoge el pod.

Con esto ya se entiende la diferencia esencial entre los dos tipos de regla que veremos: las required actúan en el filtrado (si no se cumplen, el pod no va), y las preferred actúan en la puntuación (si no se cumplen, el pod va igual pero a un nodo peor puntuado).

Salta el scheduler por completo: el kubelet de ese nodo ve un pod con su nombre y lo arranca sin más.

Nunca lo uses en producción. Si el nodo no existe, está lleno o está caído, el pod se queda colgado sin ningún evento útil; si el nodo desaparece, no hay recolocación. Su único uso legítimo es la depuración puntual: forzar un pod a un nodo concreto para investigar un problema local.

El pod solo se programa en nodos que tengan todas esas etiquetas con esos valores exactos. Es una conjunción de igualdades, sin más.

Las etiquetas se ponen sobre los nodos como sobre cualquier objeto:

Kubernetes añade además unas cuantas etiquetas estándar que conviene conocer:

Los límites de nodeSelector son tres, y motivan todo lo que viene después:

1. Solo igualdad exacta. No se puede decir "SSD o NVMe", ni "cualquier nodo que no sea de analítica".
2. Es obligatorio. Si ningún nodo casa, el pod se queda Pending para siempre. No hay forma de expresar una preferencia.
3. No dice nada sobre otros pods. No permite "no me pongas con mis hermanos".

La afinidad de nodo resuelve los dos primeros límites: sintaxis expresiva y la posibilidad de preferir en lugar de exigir.

Se leen en dos mitades:

• requiredDuringScheduling / preferredDuringScheduling: si la regla es obligatoria (filtrado) o deseable (puntuación).
• IgnoredDuringExecution: qué pasa si la etiqueta del nodo cambia mientras el pod ya está corriendo. La respuesta es: nada. El pod sigue donde está.

Ese IgnoredDuringExecution es más importante de lo que parece. Si programas postgres-reservas en un nodo con disco=ssd y alguien cambia esa etiqueta a disco=hdd, el pod no se mueve. La afinidad se evalúa en el momento de programar y nunca más. Existía un RequiredDuringExecution planeado que desalojaría pods al dejar de cumplirse la regla, pero nunca se implementó. Para desalojo por condiciones del nodo, el mecanismo es el efecto NoExecute de los taints (apartado 5).

• nodeSelectorTerms es una lista con semántica OR: basta con que se cumpla un término.
• matchExpressions dentro de un término es una lista con semántica AND: deben cumplirse todas.

Operadores disponibles:

NotIn y DoesNotExist dan la antiafinidad de nodo: no hay un objeto separado para ello, se expresa negando.

Detalle sobre Gt y Lt: comparan como enteros, la lista values debe tener exactamente un elemento, y el valor de la etiqueta del nodo debe parsear como entero. nucleos Gt "15" significa estrictamente mayor que 15, es decir, 16 o más.

Cada regla preferred que se cumpla suma su weight a la puntuación del nodo. Con dos reglas de peso 80 y 20, un nodo que cumpla ambas puntúa 100 en este complemento; uno que solo cumpla la primera, 80. Los pesos son relativos entre sí: lo que importa es la proporción, no el valor absoluto.

Combinación típica y muy recomendable: required para lo que es un requisito real (arquitectura de CPU, presencia de un disco local) y preferred para lo que es una optimización (zona concreta, gama de máquina). Poner en required lo que en realidad era una preferencia es la primera causa de pods Pending innecesarios.

La afinidad de nodo mira etiquetas del nodo. La afinidad entre pods mira qué otros pods hay ya en ese nodo o en esa zona. Es lo que permite decir "quiero estar cerca de la caché" o "no quiero estar con mis hermanas".

Léase: "no me coloques en un nodo (kubernetes.io/hostname) donde ya haya un pod con app=api-reservas y entorno=pro".

topologyKey es una etiqueta del nodo que define el ámbito en el que se aplica la regla. El scheduler agrupa los nodos por el valor de esa etiqueta, y cada grupo es un "dominio topológico".

Elegir bien el topologyKey es elegir contra qué fallo te proteges:

• hostname protege contra el reinicio o la caída de un nodo.
• zone protege contra la caída de un centro de datos entero.
• region protege contra una catástrofe regional, a costa de latencia entre réplicas.

Cuidado con required y hostname: si exiges como mucho una réplica por nodo y tienes 3 nodos, no podrás pasar de 3 réplicas. La cuarta se quedará Pending indefinidamente. Este error aparece a menudo combinado con un autoescalado que intenta subir a 10.

La solución habitual es usar preferred, que reparte pero no bloquea:

Con weight: 100, el scheduler penaliza mucho los nodos que ya alojan una réplica, así que reparte mientras pueda; cuando no queda alternativa, coloca dos juntas en vez de dejar el pod Pending. Para api-reservas, cuya disponibilidad importa más que la perfección del reparto, es la elección correcta.

Nótese el cambio de sintaxis entre las dos variantes: en required la lista contiene directamente los términos; en preferred cada elemento es un objeto con weight y podAffinityTerm.

El caso simétrico: worker-notificaciones consulta mucho redis-cache y le beneficia estar en el mismo nodo, donde el tráfico no cruza la red física.

Usa podAffinity con moderación. Concentrar pods relacionados en el mismo nodo mejora la latencia y empeora la disponibilidad: ese nodo se convierte en un punto único de fallo para dos componentes a la vez. En Rutas Norte lo dejamos en preferred con peso medio y no lo aplicamos a nada crítico.

Esta es una advertencia práctica que la documentación oficial subraya. Para evaluar afinidad entre pods, el scheduler debe, para cada nodo candidato, examinar los pods de todos los nodos de su dominio topológico. La complejidad crece con el producto de nodos por pods, no linealmente.

En un clúster de 10 nodos es imperceptible. En uno de varios cientos, con reglas de afinidad entre pods en muchas cargas de trabajo, el tiempo de decisión por pod puede pasar de milisegundos a segundos, y en un despliegue masivo eso se nota. La documentación desaconseja expresamente estas reglas en clústeres de más de varios cientos de nodos.

Mitigaciones:

• Usa topologyKey: kubernetes.io/hostname (dominios pequeños) antes que zone (dominios grandes).
• Acota el ámbito con namespaceSelector para no evaluar pods de otros namespaces.
• Para el caso concreto de "repartir réplicas de forma equilibrada", topologySpreadConstraints es más eficiente; lo vemos en el apartado 8.

Afinidad y antiafinidad son mecanismos del pod: el pod expresa dónde quiere ir. Los taints son el mecanismo inverso, del nodo: el nodo declara que rechaza pods salvo que estén expresamente autorizados.

La diferencia importa porque resuelve un problema que la afinidad no puede resolver: reservar un grupo de nodos. Con afinidad, para que solo las cargas de análisis vayan a los nodos de análisis, habría que añadir una regla "no vayas ahí" a todos los demás pods del clúster, incluidos los que despliegue alguien mañana. Con un taint, el nodo se protege solo.

Un taint tiene la forma clave=valor:efecto.

NoExecute es el único de los tres que actúa sobre pods en ejecución. Es el mecanismo que sí hace lo que RequiredDuringExecution habría hecho en la afinidad.

Reglas de la sintaxis:

• operator: Equal (el valor por defecto) exige que coincidan key, value y effect.
• operator: Exists exige que coincidan key y effect; no debe llevar value.
• Omitir effect significa "cualquier efecto para esa clave".
• Omitir key con operator: Exists significa "todos los taints". Es lo que usan los DaemonSets de CNI que deben correr pase lo que pase (06-02).

Solo tiene sentido con NoExecute, y expresa cuánto tiempo aguanta el pod en el nodo antes de ser desalojado:

"Si el nodo se vuelve inalcanzable, quédate 5 minutos por si vuelve; si no, desalójame." Es exactamente lo que Kubernetes añade por defecto a todos los pods, como veremos ahora.

Una toleration no atrae al pod: solo evita que lo rechacen.

Un pod con la toleration de dedicado=analitica puede ir a los nodos de analítica, pero también a cualquier otro nodo del clúster, y probablemente acabe en otro. Para reservar nodos de verdad hacen falta las dos piezas:

Taint + toleration = exclusividad. Taint + toleration + afinidad = dedicación.

Kubernetes pone taints por su cuenta cuando un nodo tiene problemas. Conocerlos explica muchos comportamientos que de otro modo parecen mágicos.

Y el más conocido, que no es automático sino que lo pone kubeadm al crear el clúster:

Es el que obligó al DaemonSet de logs de 06-02 a llevar una toleration explícita.

Aquí está el mecanismo real detrás de "si un nodo cae, los pods se recrean en otro sitio":

1. El kubelet deja de enviar latidos.
2. Pasados 40 segundos, el controlador de nodos marca el nodo NotReady y le añade el taint node.kubernetes.io/unreachable:NoExecute.
3. Los pods del nodo no se desalojan de inmediato, porque Kubernetes les añadió automáticamente esta toleration al crearlos:

4. A los 300 segundos (5 minutos) se agota la tolerancia y los pods se marcan para borrado. Sus controladores crean sustitutos en otros nodos.

Eso explica el retardo de unos cinco minutos entre que un nodo se cae y que sus pods reaparecen en otro sitio. Se puede ajustar por pod:

Bajarlo mucho tiene su riesgo: un corte de red transitorio de 40 segundos provocaría un desalojo masivo y una recreación innecesaria. Para postgres-reservas conviene lo contrario: un valor alto, porque recrear la base de datos en otro nodo implica desmontar y volver a montar un volumen, y es mejor esperar a que el nodo vuelva.

Un aviso: los pods de DaemonSet no reciben estas tolerations automáticas con tolerationSeconds; en su lugar toleran esos taints indefinidamente, para que los agentes sigan funcionando en un nodo con problemas.

Cuando el clúster está lleno, ¿qué pasa si llega un pod importante? Sin prioridades, se queda Pending como cualquier otro. Con prioridades, puede desalojar a pods menos importantes para hacerse sitio.

Uso en un pod:

Las PriorityClass son objetos de clúster, no de namespace. Kubernetes trae dos predefinidas para componentes del sistema, system-cluster-critical (2000000000) y system-node-critical (2000001000); esta última es la que usamos en el DaemonSet de logs de 06-02.

Actúa en dos momentos:

1. En la cola del scheduler: los pods pendientes se ordenan por prioridad descendente. Un pod crítico se evalúa antes que uno de lote, aunque llevara menos tiempo esperando.
2. En la preemption: si un pod de alta prioridad no cabe en ningún nodo, el scheduler busca un nodo donde, desalojando pods de menor prioridad, sí cabría. Si lo encuentra, marca esos pods para borrado (con su SIGTERM y su periodo de gracia de 02-01) y programa el pod importante en su lugar.

preemptionPolicy: Never hace que un pod se beneficie de la prioridad en la cola pero nunca desaloje a nadie. Es lo correcto para trabajos por lotes: que se programen pronto si hay hueco, pero que no tiren nada abajo.

Es un mecanismo que se degrada solo si se usa mal:

• La inflación de prioridades. Cada equipo pone su carga en "crítica". Al final todo es crítico y la prioridad deja de discriminar. Define pocas clases (tres bastan) y documenta qué justifica cada una.
• La preemption en cascada. El pod A desaloja al B; el controlador de B lo recrea en otro nodo; ahí desaloja al C… Un clúster al límite con prioridades mal repartidas puede pasar minutos moviendo pods sin estabilizarse.
• Los desalojos no respetan PodDisruptionBudget de forma absoluta. El scheduler intenta respetarlos, pero si no encuentra otra opción, desaloja igualmente. Los PDB son tema de 09-05.
• Los pods con estado sufren mucho. Desalojar postgres-reservas implica cerrar conexiones, desmontar el volumen y volver a montarlo en otro nodo. Ponle prioridad alta y no le pongas preemptionPolicy: PreemptLowerPriority esperando que se recoloque solo: lo que quieres es que no lo toquen.

Regla práctica: usa prioridades para proteger lo importante de ser desalojado, no para conseguir que lo importante desaloje agresivamente.

Existe un tercer mecanismo, más moderno y más eficiente que la antiafinidad para el caso concreto de repartir réplicas de forma equilibrada:

En una frase: "la diferencia entre la zona con más réplicas de api-reservas y la que menos no debe pasar de 1; si no se puede cumplir, prográmalo igual".

Ventajas frente a podAntiAffinity:

Su aplicación completa a la alta disponibilidad —cómo combinarlo con PodDisruptionBudgets para sobrevivir a la pérdida de una zona— es contenido de la lección 09-05. Aquí basta con saber que existe y que, para el caso "reparte mis réplicas", suele ser mejor herramienta que la antiafinidad.

Juntamos todo en un plan coherente para rutas-norte-pro.

Aquí required en la antiafinidad sí es correcto: dos instancias de PostgreSQL en el mismo nodo no aportan nada y sí introducen contención de disco. Y como el StatefulSet tiene una réplica, no hay riesgo de bloqueo.

Dos reglas con pesos distintos: repartir entre nodos importa el doble que repartir entre zonas. El resultado en un despliegue típico:

Seis réplicas en cuatro nodos, lo más repartidas posible. Con required la sexta se habría quedado Pending. tienda-web lleva una configuración equivalente.

El CronJob de 06-03 hace consultas agregadas pesadas. Que corra en el nodo dedicado evita que compita con la venta de billetes:

Las dos piezas juntas, como explicamos en el apartado 5: la toleration le permite entrar donde nadie más puede, y la afinidad le obliga a ir ahí. La prioridad rutasnorte-lote con preemptionPolicy: Never garantiza que un informe nocturno nunca desalojará a nada.

Ya lo escribimos en 06-02, y ahora se entiende del todo:

Sin la segunda toleration, el nodo m06 no tendría recolector y los logs de los informes nocturnos no llegarían a ninguna parte: exactamente los logs que querrías consultar cuando un informe falla a las tres de la madrugada.

Un pod Pending no ha encontrado nodo. El scheduler te dice exactamente por qué, y aprender a leer ese mensaje es la habilidad más rentable de esta lección.

La primera línea da el recuento: de 6 nodos, 0 disponibles. Después, el desglose por motivo, y la suma de los números debe dar 6:

• 1 node(s) had untolerated taint {dedicado: analitica} → el nodo m06 rechazó el pod porque no lleva la toleration. Si el pod era informes-ocupacion, falta la toleration.
• 2 node(s) didn't match Pod's node affinity/selector → dos nodos no cumplen la afinidad required.
• 3 Insufficient cpu → tres nodos no tienen CPU libre suficiente para las requests.

El bloque preemption: explica por qué la prioridad tampoco ayudó: No preemption victims found significa que no hay pods de menor prioridad que, desalojados, dejarían sitio.

Consejo de método: empieza siempre por el evento del scheduler. Es el único sitio donde el sistema te dice, con recuento por motivo, qué descartó cada nodo. Inspeccionar nodos a ojo antes de leerlo es perder el tiempo.

Confundir toleration con afinidad. Es el malentendido más extendido del tema. Una toleration solo evita el rechazo; no lleva el pod a ninguna parte. Para dedicar nodos hacen falta las dos cosas.

required donde bastaba preferred. Cada regla required es un filtro absoluto que puede dejar un pod Pending para siempre. Antes de escribirla, pregúntate: "si no se cumple, ¿prefiero que el pod no se ejecute?". Si la respuesta es no, va en preferred.

Antiafinidad required con topologyKey: hostname y muchas réplicas. Limita las réplicas al número de nodos. Combinado con un HPA que intenta subir a 15 en un pico de puente, produce pods Pending justo cuando más falta hacen.

Esperar que un cambio de etiqueta mueva pods. IgnoredDuringExecution significa exactamente lo que dice. Para mover un pod hay que borrarlo, o usar un taint NoExecute.

Usar nodeName en manifiestos de producción. Salta el scheduler y con él toda la resiliencia. Si el nodo cae, el pod no se recoloca.

Poner operator: Exists con value. La API lo rechaza. Con Exists no se especifica valor.

Olvidar el guion al quitar un taint. kubectl taint node m06 dedicado=analitica:NoSchedule añade; con el guion final quita. Sin el guion se acaba con taints duplicados.

Inflación de PriorityClass. Si todo es crítico, nada lo es. Tres clases bien definidas y documentadas bastan para casi cualquier plataforma.

Preemption sobre cargas con estado. Desalojar postgres-reservas implica desmontar y remontar un volumen en otro nodo. Protégelo con prioridad alta, pero no cuentes con que la preemption lo recoloque limpiamente.

Consejo: kubectl get pods -o wide --sort-by=.spec.nodeName es el comando para verificar de un vistazo que el reparto es el que esperabas.

Consejo: comprueba una regla antes de aplicarla en producción. Aplica el manifiesto en rutas-norte-dev, escala a la cifra que usarías en producción y comprueba que ninguna réplica queda Pending. Una antiafinidad required mal calibrada solo se manifiesta cuando el número de réplicas supera al de nodos.

Consejo: documenta por qué existe cada regla. Un podAntiAffinity sin comentario es indistinguible de un copiar y pegar, y nadie se atreverá a tocarlo dentro de un año. Una línea de comentario con el motivo ahorra mucho.

En tu minikube (perfil rutas-norte, varios nodos), etiqueta un nodo con disco=ssd y otro con disco=hdd. Crea en rutas-norte-dev un Deployment bd-demo de 2 réplicas de nginx:1.27.2-alpine que:

• Exija (required) correr en nodos con disco en [ssd, nvme].
• Prefiera (preferred, peso 70) nodos con gama=alta.

Comprueba dónde se colocan. Después escala a 4 réplicas y observa qué pasa.

Crea un Deployment api-demo de 2 réplicas con antiafinidad required por kubernetes.io/hostname sobre su propia etiqueta app. Verifica que las dos réplicas caen en nodos distintos. Escala a un número mayor que el de nodos disponibles y diagnostica el pod Pending leyendo el evento del scheduler. Corrige el problema pasando a preferred.

Elige un nodo, etiquétalo dedicado=analitica y ponle el taint dedicado=analitica:NoSchedule. Después:

1. Comprueba que un pod normal no se coloca ahí.
2. Crea un Job analitica-demo que sí corra ahí, con toleration y afinidad.
3. Demuestra que solo la toleration no basta: crea un pod con la toleration pero sin afinidad y comprueba dónde acaba.
4. Limpia el taint y las etiquetas.

Solución 1

Las dos réplicas van a m02, el único nodo con disco=ssd. Que además tenga gama=alta le da 70 puntos extra, pero era irrelevante: el filtrado ya había dejado un solo candidato.

Las cuatro en el mismo nodo. La afinidad de nodo dice dónde puede ir un pod, pero no dice nada sobre repartir. Para eso hace falta antiafinidad, que es el ejercicio 2. Si m02 se reinicia, se cae bd-demo entero.

Solución 2

Una por nodo, como se pedía.

El mensaje es explícito: dos nodos ya tienen una réplica y la regla required prohíbe una segunda; el tercero es el plano de control, con su taint. Con antiafinidad required por hostname, el máximo de réplicas es el número de nodos elegibles.

Corrección:

Cuatro réplicas repartidas dos y dos: la preferencia repartió lo mejor posible y, agotadas las alternativas, permitió duplicar en lugar de bloquear.

Solución 3

1. Un pod normal no va ahí:

Acabó en m02, el único sin taint que lo rechace.

2. Job con toleration y afinidad:

3. Solo la toleration no basta:

Podía haber ido a m03 y no fue: la toleration permite pero no atrae. El scheduler eligió m02 por su puntuación. Esto confirma la advertencia del apartado 5: para dedicar nodos hacen falta taint + toleration + afinidad.

4. Limpieza:

El kube-scheduler decide en dos fases: filtra los nodos inviables y puntúa los que quedan. Esa estructura explica toda la lección: las reglas required actúan en el filtrado y pueden dejar un pod Pending; las preferred actúan en la puntuación y solo influyen en la elección.

Hemos recorrido los mecanismos de menos a más expresivo: nodeName (fuerza bruta, solo para depurar), nodeSelector (igualdad simple), afinidad de nodo con sus nodeSelectorTerms en OR, sus matchExpressions en AND y sus operadores In, NotIn, Exists, DoesNotExist, Gt y Lt. El IgnoredDuringExecution de sus nombres largos significa que un cambio en las etiquetas del nodo nunca moverá un pod ya programado.

La afinidad y antiafinidad entre pods miran quién más hay en el dominio que define topologyKey: nodo, zona o región, según de qué fallo quieras protegerte. Su coste de cómputo es real en clústeres grandes, y para el caso concreto de repartir réplicas conviene mirar hacia topologySpreadConstraints, cuyo uso para alta disponibilidad es contenido de 09-05.

Los taints invierten la relación: es el nodo quien rechaza, con tres efectos (NoSchedule, PreferNoSchedule y NoExecute, el único que desaloja pods en marcha). Kubernetes los usa por su cuenta cuando un nodo falla, y las tolerations automáticas con tolerationSeconds: 300 explican el retardo de cinco minutos antes de que los pods de un nodo caído reaparezcan en otro sitio. La regla que hay que grabar: una toleration permite, no atrae; para dedicar nodos hacen falta taint, toleration y afinidad.

Las PriorityClass ordenan la cola y habilitan la preemption, con el riesgo de la inflación de prioridades y de las cascadas de desalojo. Y el evento FailedScheduling, con su recuento de nodos descartados por cada motivo, es la primera y casi siempre la única parada del diagnóstico de un pod Pending.

Con eso, el plan de planificación de Rutas Norte queda completo: postgres-reservas en los nodos con SSD, api-reservas y tienda-web repartidas entre nodos, un nodo de análisis reservado para informes-ocupacion y un DaemonSet de logs que llega a todas partes.

Hasta aquí hemos usado los objetos que Kubernetes trae de fábrica: Pods, Deployments, StatefulSets, Services, PVC, Jobs. Pero en el módulo 4 instalamos cert-manager y empezamos a crear objetos de tipo Certificate e Issuer, y en el módulo 5 creamos VolumeSnapshot. Ninguno de esos tipos forma parte de Kubernetes: alguien los añadió a la API, y el clúster los trata exactamente igual que a los nativos —kubectl get, describe, explain, validación, RBAC—. Cómo se hace eso, y cómo definiríamos nuestro propio tipo RutaProgramada para Rutas Norte, es el tema de la siguiente lección: las Definiciones de Recursos Personalizados.