En 10-02 montamos un clúster con kubeadm y descubrimos todo lo que implica: preparar máquinas, configurar containerd, generar certificados que caducan al año, mantener el quórum de etcd, ensayar restauraciones y actualizar nodo a nodo. Terminamos con una advertencia clara: operar eso en producción exige un equipo dedicado con guardia.

En 10-05 montamos GitOps, y ahora todo el estado de la plataforma Rutas Norte vive en Git. Eso plantea una pregunta natural: si el clúster es reemplazable y se reconstruye solo, ¿por qué íbamos a mantenerlo nosotros?

Esta lección responde a esa pregunta. Veremos qué gestiona el proveedor y qué sigue siendo tuyo, compararemos EKS, AKS y GKE en los criterios que de verdad deciden, cerraremos la federación de identidad que dejamos pendiente en 03-06, aprovecharemos las instancias interrumpibles para las cargas tolerantes de Rutas Norte, y terminaremos con una recomendación razonada.

1. El modelo de responsabilidad compartida
2. Comparación de EKS, AKS y GKE
3. Identidad: IRSA y Workload Identity
4. Nodos: grupos gestionados, plantillas e instancias interrumpibles
5. Qué cambia en lo que ya sabes
6. Actualización de versión de un clúster gestionado
7. Coste real y palancas de ahorro
8. Portabilidad y dependencia del proveedor
9. La decisión para Rutas Norte
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Un clúster gestionado no es "Kubernetes sin trabajo". Es una frontera distinta entre lo que hace el proveedor y lo que haces tú.

El plano de control desaparece de tus preocupaciones. Los certificados que caducan al año, el quórum de etcd, los snapshots, el HAProxy delante de los tres nodos de control: todo eso se va. Es aproximadamente la mitad de la lección 10-02.

Todo lo demás sigue igual. Los nodos siguen siendo tuyos, con su sistema operativo que hay que parchear. El RBAC sigue siendo tuyo. Las NetworkPolicies siguen siendo tuyas. Y si postgres-reservas pierde datos, es tu problema, no el del proveedor.

Un error muy frecuente: "está gestionado, así que las copias están hechas". Falso. El proveedor respalda etcd (la definición de los objetos), no los volúmenes de tus aplicaciones. Los datos de clientes de postgres-reservas los respaldas tú con Velero o con los snapshots del proveedor. Lo vimos en 05-06 y sigue siendo así.

La regla de oro: un clúster gestionado te quita la mitad del trabajo de operación de Kubernetes. La otra mitad, la que has estudiado en los módulos 2 a 9, sigue siendo íntegramente tuya.

Con tres entornos separados en clústeres distintos, eso son unos 220 $/mes solo por existir. Es una de las razones por las que muchas empresas separan entornos por namespace dentro de un clúster (como hace Rutas Norte) en vez de por clúster.

Aviso: el nivel gratuito de AKS no tiene SLA financiero. Para rutas-norte-pro eso puede ser inaceptable, y entonces el coste se iguala.

El sistema de canales de GKE es una diferencia real de operación: eliges "estable" y Google mantiene el clúster en una versión probada, actualizándolo en la ventana de mantenimiento que le indiques. Es lo más cerca que se está de no pensar en versiones.

En EKS y AKS, el ciclo es más manual. Y si dejas caducar la versión, ambos acaban forzando la actualización, lo que es peor que planificarla.

Esta es la diferencia técnica más importante y menos conocida, y la que provoca sorpresas serias en producción.

El problema que esto causa en la práctica: en EKS, cada pod consume una IP real de tu VPC. Una instancia t3.medium admite 3 interfaces de red con 6 IP cada una: 17 pods máximo, independientemente de que tenga CPU y memoria libres. Si tu subred es un /24 (254 direcciones), te quedas sin IP para pods mucho antes de quedarte sin CPU.

Y el síntoma cuando se agota:

Un pod Pending sin que falte CPU ni memoria. Desconcertante si no conoces el modelo.

Mitigaciones en EKS: activar el modo de prefijos delegados (ENABLE_PREFIX_DELEGATION), que multiplica por 16 las IP disponibles por interfaz; usar instancias más grandes; o planificar rangos de VPC generosos desde el principio (un /16, no un /24).

En AKS con Azure CNI clásico, hay que reservar por adelantado maxPods × número de nodos direcciones. Si planificas mal, no puedes escalar. La variante "superposición" (Azure CNI Overlay) resuelve esto y es la recomendada hoy.

En GKE con nativo de VPC, se usan rangos secundarios de IP alias, lo que separa el direccionamiento de pods del de nodos. Es el modelo más limpio de los tres.

Los tres han convergido en el mismo mecanismo: OIDC. Lo detallamos en el apartado 3.

GKE Autopilot merece mención aparte: es un modo en el que no hay nodos en absoluto desde tu punto de vista. Declaras pods con sus requests y pagas exactamente por eso. No hay nodos que parchear ni que dimensionar, no hay DaemonSets propios, no hay hostPath ni privilegios. Es Kubernetes reducido a su interfaz de cargas de trabajo.

• A favor: cero operación de nodos, facturación exacta por lo solicitado, seguridad reforzada por defecto.
• En contra: restricciones fuertes (no puedes ejecutar Falco de 08-06 tal cual, ni ciertos DaemonSets), coste por unidad mayor si tus pods están mal dimensionados, menos control.

AWS Fargate es similar pero más limitado: no admite DaemonSets en absoluto, no admite almacenamiento persistente en bloque, ni privileged. Para worker-notificaciones puede encajar; para postgres-reservas, no.

Recordando 09-03: Karpenter no trabaja con grupos de nodos predefinidos, sino que elige el tipo de instancia óptimo para los pods pendientes. Si informes-ocupacion necesita 8 CPU una vez por noche, Karpenter levanta la instancia justa, la usa y la retira. Es una diferencia notable de coste y de velocidad.

Conclusión honesta: la mejor elección casi siempre es la nube donde ya está el resto de tu infraestructura. La diferencia técnica entre los tres es menor que el coste de operar en dos nubes a la vez. Si empiezas de cero y solo miras Kubernetes, GKE es el más pulido; si tu empresa ya vive en AWS, EKS con Karpenter es excelente; si tu empresa es un entorno Microsoft, AKS se integra sin fricción.

Cerramos aquí lo que quedó anunciado en 03-06.

api-reservas necesita leer un fichero de tarifas de un bucket de almacenamiento y publicar mensajes en una cola. La forma tradicional:

Problemas: la credencial es permanente, hay que rotarla a mano, está en un Secret (base64, no cifrado, 03-02), y si se filtra sirve desde cualquier sitio del mundo.

Los tres proveedores convergen en el mismo mecanismo. El clúster expone un emisor OIDC; el kubelet proyecta en el pod un token firmado de corta duración con la identidad de la ServiceAccount; el proveedor de nube confía en ese emisor y canjea el token por credenciales temporales.

Ninguna credencial permanente. Nada que rotar. El token se renueva solo y solo sirve para esa ServiceAccount en ese clúster.

La magia está en la política de confianza del rol, cuya condición limita quién puede asumirlo:

Fíjate en sub: solo la ServiceAccount api-reservas del namespace rutas-norte-pro puede asumir este rol. Ni otra SA, ni la misma SA en otro namespace.

En el Deployment basta con serviceAccountName: api-reservas: sin variables de credenciales, porque el SDK del proveedor detecta el token proyectado automáticamente. Puedes verificarlo con kubectl exec ... -- ls /var/run/secrets/eks.amazonaws.com/serviceaccount/.

Nota: AWS ha introducido EKS Pod Identity, más sencillo (una asociación en la API de EKS, sin proveedor OIDC ni anotación). Es la opción recomendada para clústeres nuevos; IRSA sigue siendo necesaria si la carga corre fuera de EKS.

El mecanismo es el mismo; cambian las órdenes y la anotación.

Lo importante para ti: en los tres casos, el manifiesto que va a Git contiene una anotación con un identificador, nunca un secreto. Es exactamente el modelo que buscábamos en 03-06 y que encaja perfectamente con GitOps (10-05).

Un grupo de nodos gestionado es un conjunto de máquinas homogéneas que el proveedor mantiene: las crea, las une al clúster, las actualiza de forma gradual y las sustituye si fallan.

Fíjate en instanceTypes con cuatro tipos en el grupo interrumpible: cuantos más tipos aceptas, menor es la probabilidad de que el proveedor no tenga capacidad y te interrumpa todo a la vez.

Son capacidad sobrante del proveedor a un 60-90 % de descuento, con una contrapartida: el proveedor puede reclamarla con un aviso de 2 minutos (AWS), 30 segundos (Azure) o 30 segundos (GCP).

Los manifiestos, con lo aprendido en 06-05 y 09-05 (el detalle completo está en la solución del ejercicio 1):

Y un PDB con minAvailable: 1, porque aunque sean interrumpibles, no queremos que caigan todos a la vez (09-05).

Matiz importante sobre el PDB: un PodDisruptionBudget protege frente a interrupciones voluntarias (drenaje de un nodo para actualizarlo). Una interrupción de una instancia spot es involuntaria: el proveedor se lleva la máquina, con PDB o sin él. El PDB ayuda porque los gestores de terminación (AWS Node Termination Handler, o el manejo nativo de Karpenter) cordonan y drenan el nodo al recibir el aviso, y ese drenaje sí respeta el PDB.

informes-ocupacion, al ser un CronJob nocturno (06-03), es un caso todavía más claro: además de la toleration puede llevar un nodeSelector duro sobre rutasnorte.example/interrumpible: "true" —si no hay capacidad, esperar es aceptable— y un backoffLimit: 6 generoso, porque la interrupción es esperable.

En lugar de definir grupos con tipos fijos, declaras restricciones y Karpenter elige:

Diferencias con el Cluster Autoscaler (09-03):

Este apartado repasa las lecciones anteriores del curso y señala qué es distinto en la nube.

En minikube usábamos standard, un directorio del nodo. En la nube:

El error clásico: postgres-reservas con volumeBindingMode: Immediate crea el disco en eu-west-1a; el planificador coloca el pod en eu-west-1c; el pod se queda Pending para siempre con volume node affinity conflict. Solución: WaitForFirstConsumer, que es el valor que traen por defecto las StorageClass de los tres proveedores.

En local se quedaba en <pending> y hacía falta minikube tunnel. En la nube funciona de verdad:

Cosas que aprender:

• Cada Service de tipo LoadBalancer cuesta dinero (unos 20-25 $/mes más el tráfico). Por eso se usa uno solo para el controlador de Ingress y todo lo demás va por reglas de Ingress (04-04).
• Las anotaciones son específicas de cada proveedor. Son la parte menos portable de tus manifiestos (apartado 8).
• Borrar el Service borra el balanceador. Y si el balanceador tiene un registro DNS apuntando, se rompe.
• externalTrafficPolicy: Local conserva la IP del cliente pero requiere que haya un pod en cada nodo con endpoints; si no, el tráfico a ese nodo se descarta.

Los tres proveedores ofrecen además un controlador de Ingress gestionado (AWS Load Balancer Controller, Application Gateway Ingress Controller, GKE Ingress) que crea un balanceador de capa 7 directamente desde el objeto Ingress. Es cómodo, pero te ata más al proveedor que ingress-nginx.

La ventaja práctica: desaparece el imagePullSecrets. El nodo se autentica con su identidad de nube. Un Secret menos que gestionar.

Y se integra con lo de 08-05: la firma con Cosign y la política de admisión funcionan igual, con la ventaja de que los tres registros ofrecen escaneo automático que alimenta lo aprendido en 08-06.

Consejo pragmático: mantener Prometheus (07-03) para las métricas de las aplicaciones, porque tus alertas y paneles son portables, y usar el servicio del proveedor para los registros (07-05), porque operar EFK a escala es caro y doloroso, y el coste del servicio gestionado suele salir a cuenta. Es la combinación que elige la mayoría de equipos.

Cuidado con el coste de los registros: api-reservas con LOG_LEVEL=debug en producción puede generar cientos de GB al mes. Los tres proveedores cobran por ingesta.

Comparado con el procedimiento de kubeadm (10-02), esto es un paseo. Pero sigue exigiendo planificación, y quien lo trata como un botón se lleva un disgusto.

1. Las APIs eliminadas siguen siendo tu problema. Si un manifiesto de k8s/base usa una API que desaparece en 1.31, el clúster se actualiza y tu aplicación deja de desplegarse.

2. Los complementos de terceros tienen sus propias matrices de compatibilidad. cert-manager, ingress-nginx, KEDA, Prometheus Operator, el controlador CSI: cada uno soporta un rango de versiones. Una actualización del clúster sin actualizarlos puede romperlos.

3. La actualización de los nodos reinicia todos los pods. El proveedor drena cada nodo por turnos. Eso ejercita:

• Tus PodDisruptionBudgets (09-05): si están mal configurados, el drenaje se bloquea o, peor, se salta con --force.
• Tus sondas de readiness (07-01): si api-reservas tarda 45 segundos en estar listo y el drenaje va rápido, hay corte.
• Tu terminationGracePeriodSeconds y tu hook preStop.
• Tu capacidad de absorber la pérdida temporal de un nodo: si el clúster está al 95 % de ocupación, drenar un nodo deja pods Pending.

4. El plano de control y los nodos se actualizan por separado, y hay que respetar el desfase de versiones (10-02): nodos como mucho 3 menores por debajo del apiserver, y nunca por encima.

Ese último punto cierra el círculo con la primera lección del módulo: el entorno local debe seguir a producción.

Una sorpresa habitual: el tráfico entre zonas de disponibilidad se cobra. Si api-reservas está en la zona A y postgres-reservas en la zona B, cada consulta cruza una frontera facturada. Con volumen alto, eso son cientos de euros al mes. Es un argumento a favor de la afinidad de zona... que choca con la alta disponibilidad de 09-05. Es un compromiso real que hay que decidir conscientemente.

1. Dimensionar bien (lo aprendido en 09-02). Es la palanca con mejor relación esfuerzo/ahorro, y casi nadie la usa. El patrón típico: alguien puso requests: {cpu: 1, memory: 2Gi} "por si acaso" y el pod usa 80m y 200Mi. El planificador reserva lo pedido, así que estás pagando 12 veces lo que usas.

Ajustar requests a la recomendación en toda la plataforma suele reducir la factura de cómputo entre un 30 y un 50 %.

2. Autoescalado real (09-01 y 09-03). Con el HPA ajustando pods y Karpenter o el Cluster Autoscaler ajustando nodos, pagas por la carga real y no por el pico anual. Rutas Norte tiene picos en los puentes: sin autoescalado, o dimensionas para el puente todo el año, o te caes en el puente.

3. Instancias interrumpibles. 60-90 % de descuento en worker-notificaciones e informes-ocupacion.

4. Apagar los entornos que no se usan de noche. rutas-norte-dev no hace nada de las 20:00 a las 8:00 ni los fines de semana. Eso son 128 de 168 horas semanales: un 76 % de ahorro en ese entorno.

Atención con GitOps: si Argo CD tiene selfHeal activo en rutas-norte-dev, revertirá el escalado a cero en tres minutos. Por eso en la solución del ejercicio 1 de 10-05 dejamos selfHeal: false en dev. La alternativa limpia es escalar el grupo de nodos en vez de los Deployments, o usar una ventana de sincronización del AppProject.

5. Compromisos de uso. Los tres proveedores descuentan un 30-55 % a cambio de comprometer un gasto o una capacidad durante 1 o 3 años (Savings Plans y Reserved Instances en AWS, Reservations en Azure, Committed Use Discounts en GCP).

Estrategia recomendada: comprometer solo la base estable (los nodos que están encendidos siempre), dejar el pico en bajo demanda y las cargas tolerantes en spot.

6. Visibilidad del coste por equipo. Herramientas como OpenCost o Kubecost reparten el gasto por namespace, etiqueta o equipo. Sin eso, nadie sabe que informes-ocupacion cuesta 400 €/mes y nadie tiene incentivo para arreglarlo. Las etiquetas de 02-07 (app.kubernetes.io/part-of, entorno) son la base de ese reparto.

Todo esto vale de poco si dentro de dos años quieres cambiar de nube y no puedes. Vamos a ser precisos sobre qué es portable en Rutas Norte.

El patrón evidente: lo que está dentro de Kubernetes es portable; lo que está fuera no lo es. La dependencia del proveedor no viene de EKS, AKS o GKE, sino de los servicios que rodean al clúster.

1. Aísla lo no portable en las superposiciones de Kustomize. Ya lo tienes montado desde 10-04:

Cambiar de nube es cambiar una línea en components:. La base no se toca.

2. Usa ingress-nginx en vez del controlador del proveedor. Es una capa de abstracción que cuesta algo de rendimiento y ahorra una migración entera. Las reglas de Ingress y las anotaciones de nginx funcionan igual en las tres nubes.

3. Usa Prometheus para las métricas. Tus alertas y paneles son el conocimiento operativo acumulado de años. En PromQL son portables; en el lenguaje de consulta del proveedor, no.

4. Terraform en vez de la herramienta nativa. No hace la infraestructura portable, pero sí el modelo mental y los flujos de trabajo.

5. Decide conscientemente sobre las bases de datos. Ejecutar postgres-reservas como StatefulSet con un operador (06-01, 06-07) es portable; usar el servicio gestionado del proveedor es más cómodo y menos portable. Ambas son decisiones defendibles; lo que no vale es tomarla sin darse cuenta.

6. Sé realista. La portabilidad total cuesta dinero y complejidad, y muchas empresas nunca cambian de nube. Un objetivo sensato: "podríamos migrar en tres meses con esfuerzo, no en tres días". Eso te da poder de negociación y te protege de un cambio de precios abusivo, sin pagar el impuesto de la abstracción total.

• Empresa pequeña: dos personas en plataforma, seis en desarrollo, tres en soporte.
• Ninguna cobertura de guardia 24×7.
• Tráfico con picos fuertes y previsibles: puentes y vacaciones, 8-10 veces la carga base.
• Datos personales de clientes en postgres-reservas: exigencias del RGPD sobre localización y cifrado.
• Presupuesto ajustado.
• Ya usa almacenamiento de objetos y correo transaccional de AWS para otras cosas.

Con dos personas en plataforma y sin guardia, kubeadm (10-02) queda descartado. La pregunta decisiva es: ¿quién restaura etcd un domingo a las 4 de la mañana? Si la respuesta es "esperamos al lunes", no se puede operar rutas-norte-pro con un clúster propio. El ahorro del plano de control (unos 220 €/mes con tres clústeres) no compensa ni de lejos el riesgo.

Si Rutas Norte no usara ya AWS, la recomendación sería GKE: el modelo de red más limpio, Workload Identity más sencilla, canales de versión que reducen el trabajo de actualización, y Autopilot como opción para los entornos no productivos.

Dos clústeres, no tres. Separar pro del resto es una frontera de seguridad real; separar dev de pre no lo justifica: los namespaces con cuotas (03-04) y NetworkPolicies (04-06) son suficientes, y ahorran 73 $/mes más la operación.

Sin las palancas de ahorro (todo bajo demanda, sin spot, sin apagado nocturno, sin compromisos, con requests sobredimensionadas) la misma plataforma costaría del orden de 1.400-1.600 $/mes. Las palancas del apartado 7 no son teoría: son más de la mitad de la factura.

Un clúster gestionado no es más barato que uno propio en coste de infraestructura pura. Es más barato en coste total, porque incluye el trabajo que no tienes que hacer y el riesgo que no asumes. Para Rutas Norte S.L., con dos personas en plataforma y sin guardia, es la única opción defendible.

Y hay una simetría que conviene notar: gracias a GitOps (10-05), la decisión es reversible. Todo el estado de la plataforma está en Git. Si mañana hay una razón para cambiar de nube o para montar un clúster propio, se levanta el clúster nuevo, se instala Argo CD, se aplica la Application raíz y en veinte minutos la plataforma está de pie. Los datos se migran aparte, que es la parte difícil, pero la plataforma se reconstruye sola.

1. Creer que "gestionado" incluye las copias de tus datos. El proveedor respalda etcd, no tus volúmenes. postgres-reservas es tu responsabilidad: Velero (05-06) y snapshots, con restauración ensayada.

2. No planificar el direccionamiento IP. En EKS con VPC CNI, cada pod consume una IP real de la VPC. Un /24 se agota enseguida y el síntoma (FailedCreatePodSandBox) no menciona las IP de forma obvia. Planifica rangos generosos y activa la delegación de prefijos.

3. Un Service de tipo LoadBalancer por aplicación. Cada uno cuesta 20-25 $/mes. Usa uno para el controlador de Ingress y enruta con reglas de Ingress (04-04).

4. StorageClass con volumeBindingMode: Immediate en un clúster multizona. El disco se crea en una zona, el pod se planifica en otra, y el pod nunca arranca. Usa WaitForFirstConsumer.

5. Poner cargas con estado en instancias interrumpibles. postgres-reservas en spot es una receta para perder datos. Solo cargas que toleren morir sin aviso, con terminationGracePeriodSeconds y hook preStop adecuados.

6. Un solo tipo de instancia en el grupo interrumpible. Si el proveedor se queda sin ese tipo, se lleva todos tus nodos a la vez. Declara 4-6 tipos equivalentes.

7. Seguir usando credenciales estáticas en Secrets. IRSA, Workload Identity y su equivalente en Azure eliminan las credenciales permanentes. Es de las mejoras de seguridad con mejor relación coste/beneficio que existen.

8. Actualizar la versión sin comprobar las APIs eliminadas ni los complementos. El clúster se actualiza sin problema y tu aplicación deja de desplegarse, o ingress-nginx deja de arrancar. kubent y las matrices de compatibilidad, antes de tocar nada.

9. requests sobredimensionadas "por si acaso". Es la principal causa de sobrecoste en Kubernetes. El VPA en modo Off (09-02) te da los números reales en una semana.

10. Ignorar el tráfico entre zonas. En aplicaciones muy habladoras puede ser una partida importante. Mídelo antes de decidir; es un compromiso real con la alta disponibilidad de 09-05.

11. No etiquetar para el reparto de costes. Sin entorno, app.kubernetes.io/part-of y una etiqueta de equipo, la factura es un número global que nadie puede reducir. Las etiquetas de 02-07 son la base de OpenCost o Kubecost.

12. Adoptar Autopilot o Fargate sin comprobar las restricciones. Falco (08-06), algunos DaemonSets de red y todo lo que necesite privilegios pueden no funcionar. Prueba primero en un entorno no productivo.

13. Confundir "menos operación" con "sin operación". Sigues siendo responsable de los nodos, del RBAC, de las políticas, de los secretos, de la observabilidad y del coste. Los módulos 2 a 9 de este curso siguen siendo enteramente aplicables.

Escribe el conjunto completo de manifiestos que permite ejecutar worker-notificaciones en un grupo de nodos interrumpibles marcado con el taint rutasnorte.example/interrumpible=true:NoSchedule, sin dejar de funcionar si no hay capacidad spot. Debe incluir: tolerations, afinidad de nodo preferente, distribución topológica, terminationGracePeriodSeconds con hook preStop, un PDB y un ScaledObject de KEDA. Explica por qué usas afinidad preferente y no nodeSelector, y qué protege realmente el PDB frente a una interrupción de spot.

Diseña el componente k8s/componentes/proveedor-aws/ que contenga todo lo específico de AWS que Rutas Norte necesita: la StorageClass rutas-norte-ssd con EBS gp3 cifrado, un parche que añada la anotación de IRSA a las ServiceAccounts de api-reservas y worker-notificaciones, y un parche que añada las anotaciones de balanceador de red al Service del controlador de Ingress. Explica cómo se activaría desde la superposición de pro y qué habría que cambiar para migrar a Azure.

La factura de rutas-norte-pro es de 1.450 $/mes: 980 $ de cómputo, 180 $ de almacenamiento, 120 $ de balanceadores (5 Services de tipo LoadBalancer), 90 $ de tráfico y 80 $ de registros. Todos los pods tienen requests: {cpu: 500m, memory: 1Gi} y kubectl top muestra un uso medio de 90m y 220Mi. No hay instancias interrumpibles ni compromisos. Propón un plan priorizado con las órdenes de diagnóstico, el ahorro estimado de cada medida y el riesgo asociado.

Solución 1

Afinidad preferente y no nodeSelector: nodeSelector es una restricción dura. Si no hay capacidad spot en la región —cosa que ocurre precisamente en los picos, cuando más falta hace— los pods se quedarían Pending indefinidamente. Con preferredDuringScheduling, el planificador intenta el nodo interrumpible y, si no hay, usa uno bajo demanda: se paga más, pero el servicio no se detiene.

Qué protege el PDB: nada frente a la interrupción en sí (el proveedor se lleva la máquina). Protege durante el drenaje que el manejador de terminación (o Karpenter) ejecuta al recibir el aviso de 2 minutos: ese drenaje respeta el PDB, así que no se vacían dos nodos simultáneamente dejando la cola sin consumidores.

Solución 2

storageclass.yaml es el del apartado 5 (provisioner ebs.csi.aws.com, gp3 cifrado, WaitForFirstConsumer). Los dos parches son fusiones estratégicas mínimas; el target se encarga de a quién se aplican, así que el metadata.name del parche es irrelevante:

Migrar a Azure: crear k8s/componentes/proveedor-azure/ con provisioner: disk.csi.azure.com, la anotación azure.workload.identity/client-id (más la etiqueta azure.workload.identity/use: "true" en los pods) y las anotaciones de balanceador de Azure. Después, cambiar esa única línea. k8s/base/ no se toca en absoluto.

Solución 3

Orden y riesgo: se empieza por el ajuste de requests porque es el de mayor ahorro y menor riesgo, aplicándolo primero en pre, verificando con k6 (09-06) y luego en pro componente a componente. El compromiso de uso va el último a propósito: solo tiene sentido comprometerse a una capacidad después de haberla reducido, o estarías pagando por adelantado el sobredimensionamiento.

Cierra aquí el módulo 10. Lo esencial de esta lección:

• El modelo de responsabilidad compartida te quita el plano de control entero —etcd, certificados, quórum, actualizaciones, alta disponibilidad—, es decir, aproximadamente la mitad del trabajo de 10-02. Todo lo demás, incluidos los nodos, el RBAC, las políticas, los secretos, la observabilidad, las copias de tus datos y el coste, sigue siendo tuyo.
• EKS, AKS y GKE son más parecidos que distintos. Las diferencias que de verdad deciden son el modelo de red y la asignación de IP a los pods, el ciclo de versiones, el autoescalado (Karpenter destaca) y los modos automáticos (Autopilot destaca). Y por encima de todo: la nube donde ya está tu infraestructura.
• La federación de identidad —IRSA, Workload Identity y su equivalente en Azure— elimina las credenciales permanentes de los Secrets. El manifiesto que va a Git lleva una anotación, no un secreto. Cierra lo prometido en 03-06.
• Las instancias interrumpibles son ahorro real para worker-notificaciones e informes-ocupacion, si se acompañan de tolerations, afinidad preferente, distribución topológica, preStop y PDB.
• Lo que ya sabías cambia de forma concreta: la StorageClass es del proveedor y necesita WaitForFirstConsumer, el LoadBalancer por fin obtiene IP (y factura), el registro se autentica con la identidad del nodo, y las métricas y registros se pueden delegar.
• La actualización sigue exigiendo planificación: APIs eliminadas, matrices de compatibilidad de los complementos, PDB que permitan drenar y sondas que aguanten el reinicio.
• El coste se domina con seis palancas, y las dos primeras —ajustar requests con el VPA y apagar lo que no se usa— son las de mejor relación esfuerzo/beneficio.
• Y la portabilidad depende de lo que pongas fuera de Kubernetes, no de qué gestionado elijas. Aislar lo específico del proveedor en un componente de Kustomize deja la base 100 % portable.

Para Rutas Norte S.L., la recomendación es EKS en eu-west-1, con dos clústeres, Karpenter, instancias interrumpibles para las cargas tolerantes y las palancas de ahorro aplicadas desde el primer día. Y gracias a GitOps, esa decisión es reversible.

Con esto termina el recorrido por el ecosistema. Ya tienes todas las piezas: clústeres locales y propios, empaquetado con Helm, superposiciones con Kustomize, despliegue continuo con GitOps y una plataforma gestionada donde apoyarlo todo. Sumadas a los nueve módulos anteriores —pods, servicios, configuración, red, almacenamiento, patrones avanzados, observabilidad, seguridad y escalado—, ya conoces todas las piezas por separado.

Lo que falta es verlas funcionar juntas. En el Módulo 11: Estudios de Caso y Aplicaciones del Mundo Real recorreremos escenarios completos de principio a fin: el despliegue de una aplicación web desde cero, la ejecución de aplicaciones con estado, una canalización de CI/CD completa, las estrategias de despliegue blue-green y canary, la gestión multi-clúster y, para cerrar, la operación en producción de verdad: incidencias, runbooks y control de costes. Ahí es donde el conocimiento se convierte en criterio.