Migración de GKE a Dataplane V2 (Cilium / eBPF)
GKE está cambiando su networking por defecto de iptables a Cilium y eBPF, y el campo que lo controla no se puede cambiar en un cluster en ejecución. Así convertí una destrucción y recreación forzada en un bootstrap GitOps versionado y un plan de validación de 18 puntos.
Entrega en no producción con verificaciones explícitas y rollback; producción quedó fuera de este alcance.
Contribución de un vistazo
- Mi responsabilidad
- Migración de red en no producción y un bootstrap de plataforma repetible.
- Alcance
- Migración de desarrollo, staging y sandbox; producción excluida de esta entrega.
- Colaboración y límites
- Validé la infraestructura y la compatibilidad de los controladores en la ventana de no producción disponible.
- Resultado
- Una entrega escalonada en no producción con validación explícita y rollback; no se afirma ningún resultado de migración a nivel de producción.
GKE anunció que, a partir del 30 de marzo de 2027, los nuevos clusters usan por defecto Dataplane V2 (DPv2), que reemplaza el antiguo data plane de kube-proxy e iptables (Dataplane V1) por Cilium y eBPF. El detalle: el campo datapath_provider es inmutable. No se puede cambiar un cluster en ejecución de V1 a V2. La única forma de cruzar es destruir y recrear el cluster.
Por qué moverse antes y no en la fecha límite
Esperar hasta 2027 es la opción cara. Me moví mientras era barato y seguro:
- La ventana estaba abierta. Tres de los cuatro clusters (dev, staging y sandbox) estaban vacíos, cero nodes y cero workloads activos. Ese es el momento de menor riesgo y menor costo que esta migración tendrá jamás.
- Evitar una sorpresa más adelante. Si esperaba, la próxima vez que cualquier cluster se recreara después de la fecha límite heredaría DPv2 por defecto, sin validación previa del stack de plataforma (ingress, cert-manager, external secrets, autoscaling, progressive delivery, GitOps).
- Saldar deuda en el proceso. Recrear un cluster te obliga a tener un bootstrap de verdad. Esa fue la oportunidad para reemplazar años de configuración manual por un pipeline repetible.
Hacer explícito el campo inmutable
La causa raíz del riesgo de la «sorpresa en 2027» es que el campo siempre se había dejado en el valor por defecto de la nube. Convertí datapath_provider en una variable de Terraform explícita y obligatoria en el módulo del cluster, para que ningún cluster se cree jamás sin una elección consciente:
- dev, staging y sandbox recreados con
ADVANCED_DATAPATH(DPv2 / Cilium). - producción mantenida explícitamente en
LEGACY_DATAPATH; migrar un cluster de producción activo es un proyecto aparte que necesita una ventana de mantenimiento real.
La lección se generaliza: cualquier campo de infraestructura inmutable debería ser una variable explícita en el código, nunca un valor por defecto heredado. Los valores por defecto cambian sin avisar.
El lado positivo: un bootstrap GitOps
Antes de esto, levantar un cluster significaba un montón de kubectl apply manuales e instalaciones ad-hoc de Helm: cert-manager, dos ingress controllers, el autoscaler, cluster issuers. Ese conocimiento vivía en la cabeza de las personas. Como una destrucción y recreación lo habría perdido todo, lo convertí en un directorio de bootstrap versionado más un workflow de CI, de modo que levantar un cluster desde cero es ahora una ejecución de pipeline determinista y revisada. La recreación también me permitió actualizar el autoscaler unas pocas versiones menores y fijar versiones exactas de cert-manager y del resto.
Cada cluster recreado se vuelve a registrar luego con el controlador central de GitOps, ya que el endpoint de la API del cluster, el token y el certificado de CA cambian al recrearlo.
Valida el data plane, no lo des por hecho
Cambiar el data plane puede alterar comportamientos sutiles (la aplicación de NetworkPolicy, las IP de origen, la conectividad). Validé cada cluster recreado contra un plan de 18 puntos: NetworkPolicies, external secrets con Workload Identity, sincronización de GitOps, scraping de Prometheus, emisión de certificados con cert-manager y egress a través de Cloud NAT, entre otros. Todo en verde antes de que algo dependiera de ello.
Lo que le diría a alguien que empieza con esto
- Haz explícitos los campos inmutables en tu IaC. Si cambiar un campo implica recrear el recurso, debería ser una variable obligatoria y revisada, no un valor por defecto silencioso.
- Aprovecha la ventana del cluster vacío. El momento más barato para hacer una migración destructiva es antes de que algo esté corriendo en él.
- Deja que una recreación forzada salde deuda. Si tienes que reconstruir, reconstruye como código: convierte el bootstrap manual en un pipeline GitOps repetible.
- Deja producción para el final, con su propia ventana. Prueba el patrón primero en los clusters vacíos.
- Valida el data plane de forma explícita. Un cambio de networking es justo donde el «probablemente siga funcionando» te pasa factura.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Mantener el data plane anterior evita el trabajo de migración inmediato; una reconstrucción controlada ofrece la oportunidad de validar el reemplazo antes de un cambio de dependencia futuro.
Contrapartida
El networking inmutable del cluster obliga a recrearlo. La compatibilidad de los controladores y el orden de restauración importan tanto como la creación del cluster.
Lo que mejoraría a continuación
Próxima mejora: conservar una lista de verificación de compatibilidad y ensayar los prerrequisitos de producción antes de planificar cualquier migración de producción aparte.