AlpinaShop ya construye, despliega y se observa sola. El módulo 7 empieza por la parte que el curso ha ido esquivando: hay sistemas de AlpinaShop que no están en Google Cloud y no van a estarlo. En la tienda física de Sabadell hay un servidor con un ERP en MySQL que gestiona el inventario, la caja y las facturas; y en el almacén hay un terminal de radiofrecuencia que habla con ese ERP por la red local. Nadie los ha migrado, nadie tiene previsto migrarlos este año, y sin embargo la tienda online necesita saber el stock real.

Eso es una arquitectura híbrida, aunque nadie la haya llamado así. Y no es un caso raro: es la situación normal de casi cualquier empresa con más de cinco años de historia. Esta lección trata de cómo Google Cloud aborda ese escenario, y del producto que durante años lo representó: Anthos.

Con una advertencia de honestidad por delante, porque marca el tono de todo el módulo: al final de la lección, AlpinaShop no va a adoptar Anthos. Y entender por qué es tan valioso como saber configurarlo, porque la habilidad que separa a un buen arquitecto de nube de un buen recitador de servicios es saber cuándo no hace falta la herramienta grande. Vas a aprender qué es, cómo funciona, qué problemas resuelve de verdad y cuánto cuesta —y con esos tres datos vas a poder tomar la decisión tú, en tu empresa, con criterio propio.

Una nota previa sobre nombres, porque este es el producto de Google Cloud que más veces ha cambiado de nombre y la documentación que encontrarás está repartida entre todos ellos. Se detalla en el apartado 5.

1. Qué significan exactamente "híbrido" y "multinube"
2. Los motivos reales para no estar solo en una nube
3. Los costes ocultos que el folleto no menciona
4. El caso de AlpinaShop: Sabadell, el ERP y el terminal del almacén
5. Qué es Anthos y en qué se ha convertido
6. La flota (fleet): la unidad de gestión
7. Los componentes, uno a uno
8. Config Sync: la configuración como código con GitOps
9. Policy Controller: las políticas como código
10. Ejemplo práctico: registrar alpinashop-cluster y aplicar una política
11. El mallado de servicios explicado sin humo
12. Binary Authorization y la cadena de confianza
13. Observabilidad unificada de la flota
14. Modelo de licencia y coste: lo que decide en la práctica
15. Alternativas más ligeras al híbrido completo
16. Cuándo sí y cuándo no: la tabla de decisión
17. DA-004: la decisión honesta de AlpinaShop

Los dos términos se usan como sinónimos y no lo son. La diferencia importa porque los problemas que plantean son distintos.

Y una cuarta categoría que casi nadie nombra pero que es la más frecuente:

• Multinube accidental: la empresa está en GCP, pero además tiene un CRM en Salesforce, el correo en Microsoft 365, la facturación en un SaaS y un par de máquinas en un proveedor barato que alguien contrató en 2019. Nadie lo decidió; ocurrió. Y sin embargo hay que integrarlo, protegerlo y pagarlo.

AlpinaShop, sin haberlo decidido nunca, ya es híbrida y ya es multinube accidental. El trabajo de arquitectura no consiste en evitarlo, sino en gestionarlo con intención.

Las presentaciones comerciales dan siempre los mismos cinco motivos. Son ciertos, pero cada uno tiene una versión honesta que conviene conocer.

El motivo de folleto: "aprovecha tu inversión existente".

La versión real: si hace dieciocho meses la empresa compró servidores con una amortización a cinco años, el director financiero no va a firmar tirarlos a la basura, y tiene razón. El coste de esos servidores ya está pagado: apagarlos no devuelve el dinero, solo ahorra la electricidad y el mantenimiento. Migrar antes de que se amorticen significa pagar dos veces la misma capacidad.

Es el motivo más común y el más legítimo, y también el que caduca solo: dentro de tres años esa inversión ya no existe y la conversación es distinta. Por eso muchas arquitecturas híbridas son en realidad migraciones lentas disfrazadas de estrategia permanente.

El motivo de folleto: "procesa los datos donde se generan".

La versión real: hay procesos donde 30 milisegundos importan y otros donde no. Un terminal de almacén escaneando códigos de barras contra un servidor local responde en 2 ms; contra europe-west1 responderá en 15-25 ms desde Sabadell. Para escanear un paquete, ninguna de las dos molesta. Para el brazo robótico de una línea de producción que ajusta su posición mil veces por segundo, la nube no es una opción a ninguna latencia.

La pregunta correcta no es "¿hay latencia?" —siempre la hay— sino "¿qué pasa si el enlace se cae durante dos horas?". Si la respuesta es "la tienda no puede cobrar", el sistema tiene que poder funcionar sin conexión, y eso obliga a tener cómputo local. Ese, y no los milisegundos, es el argumento fuerte.

El motivo de folleto: "cumple con la normativa".

La versión real: hay tres niveles muy distintos que se confunden constantemente:

La inmensa mayoría de las empresas españolas que dicen "no podemos ir a la nube por la ley" están en el nivel 1, que se resuelve eligiendo región. El RGPD no prohíbe la nube pública: exige un tratamiento adecuado, un encargado del tratamiento con contrato, medidas técnicas y control de las transferencias internacionales. Solo sectores concretos —defensa, ciertas administraciones, sanidad en algunos supuestos— llegan al nivel 3.

Aviso. La interpretación de los requisitos regulatorios que apliquen a tus datos no es una decisión técnica. Cualquier diseño que trate datos personales, sanitarios o financieros debe revisarlo un profesional de seguridad y de cumplimiento normativo antes de ir a producción.

El motivo de folleto: "no te ates a un fabricante".

La versión real, y es la más malinterpretada de las cinco: la dependencia no es binaria, tiene grados, y evitarla del todo cuesta más de lo que ahorra.

La estrategia sensata no es "usar solo lo portable", porque eso significa renunciar a BigQuery, que es probablemente el mejor motivo para estar en Google Cloud. La estrategia sensata es saber en qué nivel estás en cada pieza y que sea una decisión consciente. AlpinaShop está muy acoplada en analítica (BigQuery) y muy poco en la aplicación (contenedores). Está bien: la analítica se reharía en seis meses si hiciera falta, la tienda se movería en dos semanas.

Y un dato incómodo: la mayoría de empresas que montan una arquitectura multinube "para no depender de nadie" acaban dependiendo de la capa que unifica ambas nubes —que suele ser otro proveedor— y añadiendo una dependencia en lugar de quitarla.

El motivo de folleto: "si una nube se cae, sigues funcionando".

La versión real: las caídas totales de un proveedor son extraordinariamente raras; las caídas de una región son mucho más frecuentes, y para eso no hace falta otra nube: basta otra región. Montar multinube activo-activo para resistir una caída global de Google es pagar el doble de complejidad todo el año para cubrir un evento que quizá no ocurra nunca. Se trata con detalle en 07-06, con RTO y RPO.

Cada modelo tiene un coste que no aparece en la comparativa de precios.

El coste oculto más caro de todos es humano. AlpinaShop tiene una persona de infraestructura. Un modelo híbrido gestionado de verdad —con su malla de servicios, sus políticas replicadas y su enlace redundante— requiere que esa persona sea experta en Kubernetes, en redes empresariales, en el hardware local y en Google Cloud, y que además esté disponible cuando falle a las tres de la madrugada. Ese es el motivo por el que la mayoría de arquitecturas híbridas de pyme fracasan, y no tiene nada que ver con la tecnología.

Pongamos el caso concreto sobre la mesa, con los datos que Marta reunió.

Lo que la tienda online necesita de todo eso es mucho menos de lo que parece:

1. El stock real cada pocos minutos, para no vender lo que ya no hay.
2. Los pedidos web volcados al ERP, para que la contabilidad cuadre.
3. Nada más. Ni el catálogo de proveedores, ni las nóminas, ni el histórico de 2012.

Y esa es la observación que decide la lección entera: no hace falta unificar dos plataformas para mover dos flujos de datos. Si el requisito fuera "ejecutar las mismas aplicaciones contenedorizadas en la tienda y en la nube, con las mismas políticas y la misma malla", Anthos sería la respuesta. El requisito real es "sincronizar dos tablas y enviar unos pedidos", y eso se resuelve con un túnel y un proceso programado.

Aun así, vamos a estudiar Anthos a fondo. Porque la decisión de no usarlo solo vale si se toma sabiendo lo que se descarta.

Anthos se presentó en 2019 como la plataforma de aplicaciones de Google para entornos híbridos y multinube. Su idea central era potente y sigue siéndolo:

Si tus aplicaciones se ejecutan en Kubernetes, el sitio físico donde se ejecuta ese Kubernetes deja de importar. Google te da un plano de control único para gestionarlos todos —en GCP, en tu centro de datos, en AWS o en Azure— con la misma configuración, las mismas políticas y la misma observabilidad.

Kubernetes como denominador común. Esa es toda la tesis.

Aquí está la parte que confunde a todo el mundo. El nombre "Anthos" se ha ido retirando y la oferta se ha reorganizado en dos familias:

La forma práctica de recordarlo:

• Si hablas de gestionar clústeres de forma unificada, el nombre actual es GKE Enterprise.
• Si hablas de hardware o software de Google corriendo fuera de Google, el nombre actual es Google Distributed Cloud.
• Si alguien dice "Anthos", se refiere a alguna de las dos y probablemente aprendió el tema antes de 2023.

En esta lección usaremos la nomenclatura actual, señalando el nombre antiguo cuando ayude a buscar documentación.

El concepto que hay que entender antes que ningún otro es la flota.

Una flota es un grupo lógico de clústeres de Kubernetes que se gestionan juntos y que confían entre sí.

Una flota:

• Pertenece a un proyecto, llamado proyecto anfitrión de la flota (fleet host project).
• Puede contener clústeres de GKE, de GKE on-prem, de GKE Multi-Cloud, de EKS, de AKS, o cualquier clúster de Kubernetes conforme registrado con el agente gke-connect.
• Es la frontera de aplicación de las políticas, de la identidad y de la configuración.

La consecuencia más importante y menos evidente es la de los espacios de nombres de flota (fleet namespaces):

En una flota, el espacio de nombres tienda significa lo mismo en todos los clústeres. Es "el equipo de la tienda", no "una carpeta dentro de un clúster concreto".

Esto se llama igualdad de espacios de nombres (namespace sameness) y tiene efectos prácticos enormes:

• Un permiso concedido sobre el espacio tienda a nivel de flota aplica en los diez clústeres.
• Un servicio catalogo en el espacio tienda puede ser descubierto desde cualquier clúster de la flota.
• Nadie puede crear un espacio tienda en otro clúster para "otra cosa": el nombre está reservado a ese equipo en toda la flota.

Sin flota, cada clúster es una isla con su propio RBAC, sus propias políticas y su propio criterio. Con flota, hay un modelo mental compartido. Ese es el valor real del producto, más que cualquier característica concreta.

GKE Enterprise no es un servicio: es un conjunto de piezas que se activan por separado. Estas son, con su función exacta.

De todos ellos, los dos que la gente adopta primero —y con razón— son Config Sync y Policy Controller. Y son también los dos que se pueden aprovechar en un solo clúster, sin híbrido de por medio.

Config Sync es un agente que corre dentro del clúster y hace una sola cosa, muy bien:

Vigila un repositorio Git y garantiza que el estado del clúster coincide con lo que hay en ese repositorio. Si alguien cambia algo a mano, lo revierte.

Eso es GitOps, y merece la pena entender por qué es distinto de un pipeline de despliegue como el que AlpinaShop montó en 06-01.

La ventaja decisiva en un escenario híbrido es la tercera columna de la primera fila: el clúster de la tienda de Sabadell no necesita ser accesible desde internet. Sale él hacia Google, lee su configuración y se aplica. No hay que abrir puertos entrantes hacia la tienda, que es exactamente lo que uno no quiere hacer.

La estructura típica del repositorio, que en AlpinaShop viviría en alpinashop-infra:

Dos carpetas clave: cluster/ para lo que aplica a todos, y namespaces/<nombre>/ para lo que aplica a un espacio de nombres concreto en todos los clústeres de la flota. La igualdad de espacios de nombres del apartado 6 se materializa aquí.

Policy Controller es la implementación gestionada de Gatekeeper, que a su vez se apoya en OPA (Open Policy Agent). Funciona como un webhook de admisión: cada vez que alguien intenta crear o modificar un recurso en el clúster, la petición pasa por él y puede ser rechazada.

Tiene dos objetos:

• ConstraintTemplate: la plantilla de la regla, escrita en un lenguaje llamado Rego. Define el tipo de comprobación.
• Constraint: la instancia de esa plantilla con parámetros concretos y su ámbito.

Google publica una biblioteca de plantillas con más de cien reglas listas, así que en la práctica casi nunca hay que escribir Rego. Ejemplos de la biblioteca:

Y tiene un mecanismo que hay que usar siempre al principio:

El patrón correcto es el mismo que ya se usó con Cloud Armor en 03-05: dryrun primero, se mide una semana, y solo entonces deny. Activar una política en deny sin medir es la forma más rápida de que el equipo de desarrollo no pueda desplegar un viernes por la tarde y de que Policy Controller se desinstale el lunes.

Vamos a hacerlo de verdad sobre el clúster que AlpinaShop ya tiene desde 02-05. Es un ejercicio útil incluso si nunca adoptas GKE Enterprise, porque Config Sync y Policy Controller funcionan en un único clúster de GKE Autopilot y aportan valor por sí solos.

• gkehub.googleapis.com es la API de flotas. "Hub" era el nombre interno original y ha quedado en la API.
• anthosconfigmanagement.googleapis.com gestiona Config Sync y Policy Controller (nótese el nombre antiguo, que sobrevive en la API aunque el producto se llame de otro modo).
• gkeconnect.googleapis.com es el canal de conexión saliente de los clústeres registrados.

Un clúster de GKE en el mismo proyecto que la flota se registra con una sola orden:

Explicado pieza a pieza:

• memberships register crea una pertenencia (membership): el objeto que representa a ese clúster dentro de la flota.
• alpinashop-cluster es el nombre de la pertenencia. Conviene que coincida con el del clúster para no volverse loco.
• --gke-cluster=REGION/NOMBRE identifica un clúster de GKE. Para un clúster externo se usaría --kubeconfig y --context.
• --enable-workload-identity es lo que permite que los pods obtengan credenciales de Google sin ficheros de clave, exactamente igual que en 03-04. En un clúster de Autopilot ya está activo; el registro lo integra con la flota.

Comprobación:

La configuración de la característica se declara en un fichero y se aplica a la flota:

Campo por campo:

• sourceFormat: unstructured permite organizar el repositorio como quieras. La alternativa, hierarchy, impone la estructura estricta que se vio en el apartado 8. Para empezar, unstructured da menos disgustos.
• syncRepo / syncBranch / policyDir: repositorio, rama y subdirectorio a partir del cual se sincroniza. Todo lo que esté fuera de config-flota se ignora.
• secretType: token indica cómo se autentica contra GitHub. En producción se usaría una app de GitHub o, mejor, gcpserviceaccount contra un repositorio alojado en GCP.
• syncWait: 30 son los segundos entre comprobaciones. Treinta segundos es un buen equilibrio; bajarlo mucho solo genera llamadas a la API.
• templateLibraryInstalled: true instala las más de cien plantillas de la biblioteca de Google. Sin esto, hay que escribir el Rego a mano.
• auditIntervalSeconds: 60 es cada cuánto Policy Controller revisa los recursos que ya existían antes de la política. Esto importa: el webhook solo ve lo nuevo; la auditoría periódica es la que descubre lo viejo que incumple.

Se aplica así:

Y el estado se consulta con:

Last_Synced_Token es el hash del commit aplicado. Ese dato responde en un segundo a la pregunta "¿qué versión de la configuración está corriendo en este clúster?", que en un modelo de empuje suele requerir arqueología en los logs del pipeline.

AlpinaShop quiere garantizar algo que hasta ahora dependía de la buena voluntad: en el clúster solo se ejecutan imágenes de su Artifact Registry. Nada de docker.io/loquesea:latest.

El fichero se añade al repositorio alpinashop-infra, en config-flota/cluster/politicas/:

Los detalles que importan:

• enforcementAction: dryrun: durante una semana registra violaciones sin bloquear nada.
• excludedNamespaces: los espacios de nombres del sistema usan imágenes de Google. Si no los excluyes, rompes el clúster. Este es el error número uno con Policy Controller.
• parameters.repos acepta prefijos. La barra final importa: sin ella, .../alpinashop-malicioso también pasaría.

Y una segunda política, esta de las etiquetas que AlpinaShop lleva usando desde 01-04:

Obsérvese que allowedRegex no solo exige la etiqueta: exige que su valor sea uno de los válidos. Sin eso, alguien pone equipo: varios y la asignación de costes de 07-05 vuelve a ser inútil.

Tras una semana, se consultan las violaciones registradas:

Dos hallazgos reales, y ninguno es un ataque: son dos imágenes públicas legítimas que alguien desplegó sin pensarlo. La respuesta correcta no es rendirse y quitar la política, sino:

1. Copiar esas dos imágenes al Artifact Registry propio (que además es lo correcto por disponibilidad y por escaneo de vulnerabilidades, como se verá en 07-04).
2. Actualizar los despliegues.
3. Ahora sí, cambiar dryrun por deny, hacer commit y dejar que Config Sync lo propague.

En menos de un minuto, el clúster rechaza cualquier pod con una imagen ajena. Y lo importante: el cambio está en un pull request revisado, no en la memoria de nadie.

La malla de servicios (service mesh) es la parte de GKE Enterprise que más se vende y peor se entiende. Vamos con la explicación honesta.

Se inyecta un proxy (Envoy) junto a cada contenedor de la aplicación —el patrón sidecar— o en cada nodo (ambient, el modo más reciente que evita el sidecar). Todo el tráfico entre servicios pasa por esos proxies. Como el proxy ve todo el tráfico y lo controla un plano de control central, se pueden hacer cosas que la aplicación no sabe hacer.

Los dos valores realmente difíciles de replicar son el mTLS automático con identidades por servicio y la telemetría uniforme sin tocar el código. El resto se consigue de otras formas, a menudo más simples.

Y aquí la parte que las presentaciones omiten:

• Duplicas los contenedores. Cada pod pasa a tener dos procesos. Consumo de CPU y memoria adicional del 10-30 %, y en Autopilot eso es factura directa.
• Añades un salto de red a cada llamada. Latencia adicional de entre 0,5 y 3 ms por salto, que se multiplica por la profundidad de la cadena de llamadas.
• Depuras el doble. Cuando algo falla, la pregunta pasa a ser "¿es la aplicación o es el proxy?". Los códigos de error de Envoy (UF, UO, NR, URX) hay que aprendérselos.
• Introduces conceptos nuevos: VirtualService, DestinationRule, PeerAuthentication, AuthorizationPolicy, Gateway, Sidecar. Son seis objetos más que dominar, y su interacción no es obvia.
• El orden de arranque importa. Un contenedor que llama a la red antes de que su proxy esté listo falla de formas desconcertantes.
• Actualizarla es una operación delicada, porque toca el camino del tráfico de todo lo que corre en el clúster.

La regla honesta: una malla de servicios empieza a compensar a partir de, aproximadamente, veinte servicios que se llaman entre sí, mantenidos por más de tres equipos, en más de un lenguaje. Por debajo de eso, el coste de operarla supera lo que aporta.

AlpinaShop tiene un servicio de catálogo, una función de imágenes y unos cuantos procesos por lotes. Poner una malla ahí es como montar un aeropuerto para un carril bici. No es que sea mala tecnología: es que no hay problema que resolver.

Binary Authorization responde a otra pregunta: ¿esta imagen concreta tiene permiso para ejecutarse en este entorno? Funciona también como control de admisión, pero en lugar de mirar la forma del recurso, comprueba firmas criptográficas.

El flujo es:

1. Cloud Build construye la imagen y la publica en Artifact Registry (06-01).
2. Un proceso de verificación —el escaneo de vulnerabilidades, o el paso manual de aprobación de Marta— crea un atestado (attestation): una firma que dice "esta imagen, identificada por su digest, ha pasado este control".
3. Al desplegar, Binary Authorization comprueba que existen los atestados exigidos por la política. Si no, rechaza el pod.

Detalles importantes:

• ENFORCED_BLOCK_AND_AUDIT_LOG bloquea y registra. Existe DRYRUN_AUDIT_LOG_ONLY, que es por donde hay que empezar, igual que con Policy Controller.
• admissionWhitelistPatterns es una lista de excepciones por patrón de nombre. Úsala con cuidado: cada excepción es un agujero permanente.
• Binary Authorization no está limitado a GKE Enterprise: funciona en GKE estándar y también en Cloud Run, lo que lo hace relevante para AlpinaShop aunque descarte la flota. Se retoma en 07-04 como pieza de la cadena de suministro.

Los clústeres registrados envían sus métricas y logs a Cloud Monitoring y Cloud Logging del proyecto de la flota, incluidos los que están fuera de Google Cloud. Esto significa que el panel de campaña que AlpinaShop construyó en 06-04 podría mostrar, en la misma pantalla, la latencia del catálogo en europe-west1 y la del proceso que corre en la trastienda de Sabadell.

Es una ventaja real y a menudo subestimada: en un híbrido mal montado, el 80 % del tiempo de un incidente se va en abrir tres herramientas distintas y comparar relojes que no están sincronizados.

La consola de GKE Enterprise añade además una vista de flota con:

• Estado de sincronización de cada clúster (el Last_Synced_Token del apartado 10).
• Porcentaje de cumplimiento de políticas y lista de violaciones.
• Versiones de Kubernetes y avisos de fin de soporte por clúster.
• Coste estimado agrupado por equipo, si las etiquetas están bien puestas.

Aquí es donde se toman las decisiones reales, y donde conviene ser muy claro.

GKE Enterprise no se factura por consumo puntual como una VM: se factura como una edición de GKE, con un precio por vCPU de los nodos de los clústeres incluidos en la flota, mensual o con compromiso anual. Google publica los precios y cambian; el orden de magnitud que hay que tener en la cabeza es:

Verifica siempre los precios en la documentación oficial y con la calculadora de precios. Las cifras de arriba son órdenes de magnitud para razonar, no cotizaciones.

Hagamos la cuenta para AlpinaShop, que es lo que decide:

• El clúster alpinashop-cluster es Autopilot y sostiene el catálogo con el equivalente a unas 8 vCPU en horario normal.
• Un recargo del orden de 5 € por vCPU y mes son unos 40 € al mes solo de licencia, sin contar el cómputo.
• A eso habría que sumar el consumo extra de los sidecars de la malla (10-30 % más de CPU y memoria) y, si de verdad se quisiera híbrido, un clúster en Sabadell con su hardware, su suscripción y su mantenimiento.

Cuarenta euros al mes no arruinan a nadie. El problema no es el dinero: es que se paga por capacidades que no se van a usar. Y hay un coste mucho mayor escondido detrás: las horas de Marta aprendiendo, operando y depurando seis objetos nuevos de Istio para un único servicio.

Entre "no hacer nada" y "adoptar GKE Enterprise" hay un espectro. Estas son las opciones intermedias, ordenadas de menor a mayor compromiso.

Dos apuntes:

• "Cloud Run for Anthos", que aparece en documentación y exámenes antiguos, permitía ejecutar la API de Cloud Run sobre un clúster propio mediante Knative. Ha quedado en desuso a favor de Cloud Run sin más (07-02) y de la malla gestionada. Si lo ves en un temario de certificación, ya sabes de qué se hablaba.
• Config Connector merece una consideración honesta: es una alternativa real a Terraform si —y solo si— tu equipo ya trabaja íntegramente en Kubernetes. Para AlpinaShop, que acaba de invertir el módulo 6 en Terraform, añadir un segundo sistema para lo mismo sería un retroceso.

Esta es la tabla que se lleva uno de la lección.

Y la pregunta única que resuelve la mayoría de los casos:

¿Tengo cargas de trabajo ejecutándose fuera de Google Cloud que necesitan la misma gestión que las de dentro?

Si la respuesta es "no, solo necesito hablar con un sistema de fuera", no necesitas Anthos: necesitas red.

Marta, Dani y Lucía se sentaron con esta información y escribieron la decisión, siguiendo el mismo formato que DA-001, DA-002 y DA-003. Está en el README de alpinashop-infra, como manda la disciplina de 06-02.

DA-004 — Estrategia híbrida e integración con la tienda de Sabadell Fecha: 2026-08-05 · Autores: Marta (infraestructura), Dani (backend) · Estado: aceptada

1. Contexto. La tienda física de Sabadell ejecuta un ERP con MySQL 5.7 en un servidor local, con un terminal de radiofrecuencia y un TPV atados a él por la red local. El ERP no puede migrar este año por licenciamiento del fabricante y presupuesto. La tienda online necesita del ERP dos cosas: leer el stock cada pocos minutos y volcar los pedidos web. El equipo de infraestructura es de una persona.

2. Opciones consideradas.

3. Decisión. AlpinaShop no adopta GKE Enterprise ni Google Distributed Cloud. Se establece conectividad privada con la tienda mediante Cloud VPN HA (dos túneles con BGP sobre Cloud Router, detallado en 07-03) y la integración se resuelve así:

• Stock: un trabajo programado con Cloud Scheduler + Workflows (04-06) lee cada 10 minutos las tablas de existencias del MySQL de Sabadell a través del túnel y actualiza el catálogo.
• Pedidos: cada pedido web publica en el topic pedidos-nuevos (04-04); un consumidor los inserta en el ERP. Si el enlace está caído, los mensajes esperan en la suscripción y se procesan al volver — la tienda online no se detiene porque Sabadell no esté disponible.
• Sin conexión: el TPV y el terminal siguen funcionando contra el ERP local exactamente igual que hoy. No se introduce ninguna dependencia nueva de la nube en la operación de la tienda física.

4. Consecuencias.

• Positivas: coste marginal (el de dos túneles VPN); ninguna tecnología nueva que aprender; el desacoplamiento por Pub/Sub hace que un corte del enlace sea un retraso, no una caída.
• Negativas: la gestión sigue siendo doble —el ERP se parchea a mano en Sabadell— y no hay políticas uniformes entre ambos lados. Se acepta: es un servidor, no una flota.
• Se adopta parcialmente una pieza: Policy Controller en modo dryrun sobre alpinashop-cluster mientras el catálogo siga ahí, porque aporta valor con un solo clúster y sin licencia Enterprise en su nivel básico. Se revisará cuando el catálogo se mueva a Cloud Run en 07-02.

5. Revisión. Esta decisión se revisa si ocurre cualquiera de estas tres cosas: se abren dos tiendas físicas más, el ERP migra a la nube, o el número de servicios que se llaman entre sí supera la decena.

• Confundir "híbrido" con "tener una VPN". Tener conectividad privada con un sistema local no te convierte en una arquitectura híbrida gestionada. Es bueno saberlo: probablemente no necesitas la plataforma grande.
• Adoptar la malla de servicios "porque es la buena práctica". Es una buena práctica a partir de cierta escala. Por debajo, es sobrecarga operativa pura.
• Activar Policy Controller directamente en deny. Bloquearás despliegues legítimos el primer día. dryrun una semana, mides, corriges, y entonces deny.
• Olvidar excludedNamespaces en las políticas. Si la política aplica a kube-system, el clúster deja de funcionar. Siempre excluye kube-system, gke-system, gatekeeper-system y config-management-system.
• Buscar documentación por el nombre antiguo y quedarse con instrucciones obsoletas. "Anthos Service Mesh" y "Cloud Service Mesh" son el mismo producto en dos épocas, y los comandos han cambiado. Comprueba siempre la fecha de la página.
• Creer que multinube reduce el bloqueo por proveedor. A menudo lo aumenta: añade una capa de abstracción que también es de alguien, y obliga a usar el mínimo común denominador de ambas nubes.
• Ignorar el egress entre nubes. Mover datos de GCP a AWS y viceversa se paga por gigabyte en las dos direcciones. Una arquitectura multinube "elegante" que cruce datos constantemente puede duplicar la factura. Se trata en 07-05.
• Registrar clústeres en la flota sin --enable-workload-identity. Acabarás repartiendo claves JSON, exactamente lo que 03-04 enseñó a evitar.
• Consejo: usa Config Sync aunque no vayas a ser híbrido. GitOps sobre un solo clúster ya elimina la deriva de configuración, y es de las mejoras con mejor relación valor/esfuerzo del catálogo.
• Consejo: si dudas entre híbrido y migrar, calcula la fecha de amortización del hardware. Muchas veces la respuesta correcta es "híbrido durante 18 meses y luego nube", y eso cambia por completo cuánta plataforma merece la pena montar.
• Consejo: escribe la decisión. DA-004 existe para que dentro de dos años nadie tenga que reconstruir por qué no se adoptó. Y para que, cuando se cumplan las condiciones de revisión, se revise de verdad.

Para cada uno de estos casos, decide si conviene GKE Enterprise / Google Distributed Cloud, otra alternativa más ligera, o nada, y justifica en tres o cuatro líneas.

(a) Una cadena de 60 supermercados. Cada tienda tiene cajas que deben cobrar aunque internet se caiga, y un sistema de etiquetado electrónico que se actualiza cada hora. Central con equipo de 8 personas de sistemas.

(b) Una startup de 12 personas con un backend de 4 microservicios en GKE Autopilot, todo en europe-west1. El CTO quiere "estar preparados para multinube".

(c) Una aseguradora que acaba de comprar una empresa más pequeña. La compradora está en Google Cloud; la comprada tiene 40 aplicaciones en un centro de datos propio con contrato de alojamiento vigente hasta dentro de 3 años. Ambos equipos se mantienen.

(d) Un fabricante con una planta en Zaragoza. Un sistema de visión artificial inspecciona piezas a 30 imágenes por segundo y debe decidir en menos de 50 ms si rechazar la pieza. Quieren además entrenar modelos con las imágenes históricas.

AlpinaShop quiere garantizar dos cosas más en alpinashop-cluster:

1. Ningún contenedor puede ejecutarse como root.
2. Todo contenedor debe declarar límites de CPU y memoria (para que Autopilot no facture sorpresas y para que un pod desbocado no ahogue a los demás).

Escribe los dos Constraint usando la biblioteca de plantillas (K8sPSPAllowPrivilegeEscalationContainer y K8sContainerLimits), indica dónde colocarlos en el repositorio alpinashop-infra, y describe el procedimiento completo de despliegue seguro. Explica además qué comprobarías antes de pasar a deny.

Un integrador presenta a la dirección de AlpinaShop esta propuesta:

"Recomendamos desplegar Google Distributed Cloud en la tienda de Sabadell y adoptar GKE Enterprise con Cloud Service Mesh. Así unificarán la gestión, tendrán mTLS extremo a extremo entre la tienda y la nube, políticas homogéneas y observabilidad centralizada, quedando preparados para el crecimiento multinube. Inversión: 18.000 € el primer año más 900 €/mes."

Escribe la respuesta técnica de Marta a la dirección: qué partes de la propuesta son ciertas, cuáles son irrelevantes para AlpinaShop, qué preguntas hay que hacerle al integrador, y qué contrapropuesta se plantea con su coste aproximado.

Solución 1 — Decidir con criterio en cuatro escenarios

(a) Cadena de 60 supermercados: SÍ, y es el caso de manual.

Concurren los tres factores decisivos a la vez. Funcionamiento sin conexión: las cajas deben cobrar con el enlace caído, luego tiene que haber cómputo local por obligación, no por preferencia. Escala: 60 emplazamientos son 60 clústeres, y gestionarlos uno a uno es inviable — aquí la flota deja de ser un lujo y pasa a ser la única forma de mantener la cordura. Equipo: 8 personas pueden sostener la plataforma.

La solución es Google Distributed Cloud en cada tienda, todas registradas en una flota, con Config Sync distribuyendo la configuración desde Git. Nótese la ventaja del modelo de tirón: las 60 tiendas no necesitan ser accesibles desde fuera; salen ellas a buscar su configuración. Actualizar el software de etiquetado electrónico en 60 tiendas pasa a ser un commit.

La malla de servicios, en cambio, se evaluaría aparte y probablemente más tarde: el valor aquí está en la gestión de flota, no en el mTLS entre servicios.

(b) Startup de 12 personas: NO, con claridad.

"Estar preparados para multinube" con 4 microservicios en un solo clúster no es una arquitectura: es una preocupación sin caso de uso. El coste de la preparación se paga hoy, todos los meses, y el beneficio quizá no llegue nunca.

Lo que sí conviene hacer, y es gratis:

• Mantener las aplicaciones contenedorizadas y sin dependencias propietarias en el camino crítico, que ya lo están.
• Gestionar la infraestructura con Terraform, que es multiproveedor por diseño.
• Que los datos sean exportables (formatos estándar, pg_dump, Parquet).
• Escribir en el README en qué servicios están acoplados a propósito y por qué.

Con eso, el día que haya un motivo real para moverse, la salida es de semanas. Y mientras tanto se aprovecha lo bueno de GCP en lugar de renunciar a ello. Si además quieren configuración como código, Config Sync sobre el clúster que ya tienen es la mejora con mejor retorno.

(c) Aseguradora tras una fusión: PROBABLEMENTE SÍ, y es el caso más matizado.

Concurren: inversión sin amortizar (contrato de alojamiento a 3 años, que es dinero comprometido), 40 aplicaciones (volumen que justifica una plataforma), y dos equipos que se mantienen (hay manos). Además, en un sector regulado, tener políticas de seguridad demostrablemente uniformes en ambos lados tiene valor de auditoría, no solo técnico.

La estrategia sensata es híbrido con fecha de caducidad: registrar los clústeres de ambos lados en una flota, unificar políticas con Policy Controller y observabilidad con Cloud Logging/Monitoring, y usar esos 3 años para migrar por olas las aplicaciones que tengan sentido. El error sería adoptarlo como estado permanente sin plan de convergencia; el otro error sería intentar migrar 40 aplicaciones de golpe.

Las preguntas que decidirían el detalle: ¿cuántas de esas 40 aplicaciones están contenedorizadas? Si son 3, la flota no ayuda a las otras 37 y el problema real es de modernización, no de plataforma.

(d) Fabricante con visión artificial: SÍ, pero en el borde y por un motivo distinto.

50 ms de presupuesto total para capturar, inferir y decidir hace que la nube sea imposible: solo la ida y vuelta a europe-southwest1 desde Zaragoza consume una parte significativa, y un corte de red pararía la línea de producción. La inferencia tiene que ser local, y no hay discusión posible.

Arquitectura: Google Distributed Cloud (o simplemente hardware con GPU y un runtime de inferencia) en la planta ejecutando el modelo; las imágenes y los resultados se suben de forma asíncrona a Cloud Storage; el entrenamiento se hace en Vertex AI (módulo 5) con el histórico; los modelos nuevos se despliegan a la planta desde el registro de modelos.

Es el patrón canónico del borde: inferencia abajo, entrenamiento arriba. Y obsérvese que la parte que justifica la plataforma no es la latencia en sí, sino que la línea no puede parar si se cae el enlace.

Solución 2 — Escribir y desplegar una política de conformidad

Ubicación en el repositorio. Ambos ficheros van en config-flota/cluster/politicas/, porque son políticas de clúster y no de un espacio de nombres concreto:

Política 1 — sin escalada de privilegios:

Política 2 — límites de CPU y memoria:

Nótese que K8sContainerLimits hace dos cosas a la vez, y conviene saberlo: exige que los límites existan y además que no superen los valores indicados. Los valores 2 vCPU y 4Gi son el techo por contenedor; se eligen midiendo el consumo real y dejando margen, no a ojo.

Procedimiento de despliegue seguro, paso a paso:

1. Rama y pull request en alpinashop-infra. Nunca directo a main: la revisión es parte del control (06-02).
2. Validación local antes de subir, para no descubrir un error de sintaxis en producción:

   kubectl apply --dry-run=server -f config-flota/cluster/politicas/
   

3. Merge a main tras revisión. Config Sync lo detecta en 30 segundos.
4. Verificar la sincronización, que es el paso que la gente se salta:

   gcloud beta container fleet config-management status
   nomos status   # herramienta especifica de Config Sync, mas detallada
   

5. Esperar entre 7 y 14 días en dryrun, cubriendo al menos un ciclo completo de despliegues y los procesos por lotes nocturnos y semanales. Una semana que no incluya el cierre mensual puede ocultar un incumplimiento.
6. Revisar violaciones:

   kubectl get constraints -o json | jq -r '
     .items[] | select(.status.totalViolations > 0) |
     "\\(.metadata.name): \\(.status.totalViolations) violaciones"'
   

7. Corregir el origen, no la política. Si un pod necesita más de 2 vCPU legítimamente, se sube el parámetro con justificación escrita; si no lo necesita, se corrige el pod.
8. Cambiar a deny en un pull request separado del que introdujo la política, para que el cambio de modo sea visible en el historial y se pueda revertir solo.

Qué comprobar antes de pasar a deny —la lista de Marta:

• Cero violaciones durante al menos 7 días consecutivos.
• Los CronJob semanales y mensuales se han ejecutado al menos una vez en ese periodo.
• Los espacios de nombres del sistema están excluidos y se ha verificado, no supuesto.
• Existe un procedimiento de excepción documentado: cómo pide alguien una exención, quién la aprueba y cuándo caduca.
• El procedimiento de reversión está escrito: git revert del commit y esperar 30 segundos. Saber que la vuelta atrás cuesta un minuto es lo que permite avanzar con tranquilidad.

Solución 3 — Rebatir la propuesta de un proveedor

Respuesta de Marta a dirección.

Qué es cierto de la propuesta. Todo lo técnico. GKE Enterprise unifica de verdad la gestión de clústeres, Cloud Service Mesh proporciona mTLS automático sin tocar el código, Config Sync y Policy Controller aplican políticas homogéneas, y la observabilidad se centraliza. El integrador no está exagerando ninguna capacidad. El problema no es que sea falso; es que responde a preguntas que no nos hemos hecho.

Qué es irrelevante para nosotros, punto por punto.

• "Unificarán la gestión": unificar la gestión de un clúster en la nube y un servidor ERP que ni siquiera ejecuta contenedores. No hay flota que gestionar; hay dos sistemas distintos que solo necesitan intercambiar dos flujos de datos.
• "mTLS extremo a extremo entre la tienda y la nube": un túnel IPsec de Cloud VPN ya cifra ese tráfico, y cuesta unos pocos euros al mes. El mTLS de la malla resuelve el cifrado entre servicios, y nosotros tenemos un servicio.
• "Políticas homogéneas": valioso a partir de varios clústeres. Con uno, Policy Controller aporta —y lo vamos a usar—, pero eso no requiere la licencia Enterprise ni el despliegue en la tienda.
• "Preparados para el crecimiento multinube": no hay ningún plan de negocio que contemple otra nube. Estaríamos pagando hoy por una opción que nadie ha pedido.
• Además, introduce un riesgo nuevo que la propuesta no menciona: hardware de Google en la trastienda de una tienda que hoy funciona con un servidor y un SAI. Eso es un elemento más que se puede romper, actualizar y quedarse sin soporte, en un sitio sin personal técnico.

Preguntas para el integrador. Son las que revelan si la propuesta se hizo para nosotros o es una plantilla:

1. ¿Qué cargas de trabajo en contenedores vamos a ejecutar en la tienda de Sabadell? (Respuesta real: ninguna. El ERP es una aplicación de escritorio con MySQL.)
2. ¿Cuántos servicios se llaman entre sí en nuestra arquitectura actual? (Respuesta real: prácticamente uno. La malla no tiene nada que mallar.)
3. Los 900 €/mes, ¿incluyen soporte, actualizaciones del hardware de la tienda y las horas de operación, o solo la licencia?
4. ¿Qué pasa el día que el catálogo se mueva a Cloud Run según DA-001? Buena parte de esta propuesta deja de aplicar, porque ya no habrá clúster que gestionar.
5. ¿Quién opera esto? Somos una persona de infraestructura. ¿Se incluye servicio gestionado 24×7, y a qué precio?
6. ¿Cuál es el coste y el plazo de salir de esta arquitectura si en dos años no encaja?

Contrapropuesta.

Coste total del orden de decenas de euros al mes, frente a 18.000 € más 900 €/mes. La diferencia no se ahorra: se invierte en lo que sí nos falta —fiabilidad, SLO y recuperación ante desastres (07-06)—, que es donde hoy tenemos el riesgo de verdad.

La frase para dirección. No estamos rechazando la propuesta porque sea cara, sino porque resuelve el problema de una empresa que no somos. Si abrimos cinco tiendas más y el ERP migra a contenedores, volveremos a mirarla — y por eso queda escrito en DA-004 cuándo se revisa.

Has entendido el mapa completo del híbrido y el multinube, y —más importante— sabes situarte en él.

Distingues híbrido, multinube, borde y esa cuarta categoría que nadie nombra, la multinube accidental, que es la situación real de casi todo el mundo. Conoces los cinco motivos para no estar solo en una nube en su versión honesta: la inversión previa que caduca sola, la latencia cuyo argumento fuerte no son los milisegundos sino el funcionamiento sin conexión, la regulación con sus tres niveles —residencia, soberanía y control físico— que casi nadie distingue, la dependencia del proveedor que tiene grados y cuya gestión correcta es saber en cuál estás, y la continuidad que casi siempre se resuelve con otra región y no con otra nube. Y conoces los costes ocultos de cada modelo, con el más caro subrayado: el humano.

Sabes qué es Anthos y en qué se ha convertido: GKE Enterprise para la gestión unificada de clústeres, Google Distributed Cloud para el software de Google fuera de Google, GKE Multi-Cloud para clústeres sobre AWS y Azure, y Cloud Service Mesh para la malla. Reconocerás el nombre antiguo en documentación y exámenes y sabrás traducirlo.

Dominas el concepto central, la flota, y su consecuencia menos evidente y más potente: la igualdad de espacios de nombres, que convierte tienda en "el equipo de la tienda" en todos los clústeres a la vez. Conoces sus componentes uno a uno, con Config Sync —GitOps de tirón, con la ventaja decisiva de no exigir acceso entrante a los emplazamientos remotos— y Policy Controller —Gatekeeper gestionado, con su biblioteca de plantillas y el imprescindible dryrun antes de deny— como los dos que aportan valor incluso con un solo clúster.

Lo has hecho en la práctica: registrar alpinashop-cluster en una flota, activar Config Sync contra alpinashop-infra, escribir dos políticas reales —solo imágenes del Artifact Registry propio y etiquetas obligatorias con valores validados—, medir sus violaciones en dryrun, corregir el origen y solo entonces denegar. Con el error número uno señalado: excluir siempre los espacios de nombres del sistema.

Entiendes la malla de servicios sin humo: qué resuelve de verdad —mTLS automático con identidad por servicio y telemetría uniforme sin tocar el código— y qué complejidad añade —contenedores duplicados, un salto de red más, seis objetos nuevos y una depuración más difícil—, con el umbral honesto de unos veinte servicios y varios equipos por debajo del cual no compensa. Y conoces Binary Authorization como control de admisión por firma, que volverá en 07-04 y que, a diferencia de la malla, sí aplica a Cloud Run.

Sabes cómo se factura —por vCPU de la flota, como edición de GKE— y por qué el precio no es lo que decide: lo que decide es que se paga por capacidades que no se van a usar y por horas de aprendizaje que no se tienen. Conoces las alternativas ligeras, de Cloud VPN y Pub/Sub como puente hasta Config Connector, con la nota histórica de Cloud Run for Anthos. Y te llevas la tabla de cuándo sí y cuándo no con su pregunta resumen: ¿tengo cargas ejecutándose fuera de GCP que necesiten la misma gestión? Si solo necesitas hablar con un sistema de fuera, no necesitas Anthos: necesitas red.

Y tienes DA-004 escrita: AlpinaShop no adopta GKE Enterprise. Conecta con Sabadell por Cloud VPN HA, sincroniza el stock con Workflows cada diez minutos, vuelca los pedidos por Pub/Sub con tolerancia a cortes, mantiene el TPV funcionando sin conexión, adopta Policy Controller en dryrun porque aporta con un solo clúster, y deja escritas las tres condiciones que obligarían a revisar la decisión.

Queda pendiente lo que esa decisión implica en dos frentes. Uno es la red: el túnel a Sabadell, el Cloud Router, el direccionamiento que no se puede solapar y todo lo que hay que diseñar para que dos redes que nacieron por separado se hablen sin sorpresas — es 07-03.

El otro es más antiguo. Esta lección ha decidido no montar una plataforma de contenedores más grande; la siguiente hace justo lo contrario y monta una más pequeña. Porque si AlpinaShop tiene un solo servicio web, con tráfico irregular, ya contenedorizado y sin estado, la pregunta que lleva pendiente desde 02-07 tiene una respuesta que ya no se puede aplazar. DA-001 se cumple en la próxima lección: el catálogo se va a Cloud Run.