KubeCon NA 2025: Kubernetes para empresas medianas (sin caer en complejidad innecesaria)
KubeCon + CloudNativeCon North America 2025 cerró en Atlanta con la sensación de que el ecosistema cloud-native dejó atrás su fase de "fiesta para SREs de Google" y entró en una etapa más sobria, donde el énfasis está en operación, costos y casos reales de empresas que no son hyperscalers. Para nosotros, que asesoramos a empresas medianas mexicanas, fue el primer KubeCon en años donde se sintió que la conversación realmente baja a tierra.
En este artículo resumimos los anuncios que importan, separamos lo que es ruido de lo que tiene impacto operativo, y proponemos un camino concreto para adoptar Kubernetes sin necesidad de armar un equipo de plataforma de diez personas.
Los anuncios que sí importan
Hubo cientos de sesiones, pero cinco temas dominaron el evento:
- Autoscaling más inteligente. KEDA llegó a 3.0 con soporte nativo para escalado por costos y por SLOs, no solo por CPU. Karpenter sigue ganando terreno como reemplazo del Cluster Autoscaler clásico, especialmente en AWS.
- eBPF como capa de red estándar. Cilium consolidó su posición como CNI por defecto en clusters serios. Las distribuciones managed (EKS, GKE) ya lo ofrecen sin fricción.
- Gateway API en GA. El reemplazo natural de Ingress quedó estable. Es momento de planear la migración, sobre todo si manejas múltiples dominios o necesitas routing avanzado.
- AI workloads como ciudadanos de primera clase. Kubeflow, Ray on Kubernetes y los nuevos operadores de NVIDIA (NIM) reflejan que entrenar e inferir modelos sobre Kubernetes ya no es exótico.
- FinOps integrado. OpenCost se volvió proyecto graduado de la CNCF. Por fin hay forma estándar de saber cuánto cuesta cada namespace, deployment o equipo.
Cuándo Kubernetes vale la pena en empresa mediana
Aquí va nuestra opinión directa: Kubernetes no es para todos. Es una herramienta poderosa que cobra una factura constante en complejidad operativa. Antes de adoptarlo conviene ser honesto sobre el caso de uso.
Vale la pena cuando:
- Operas más de 8 a 10 microservicios que necesitan orquestación, descubrimiento y escalado coordinado.
- Tienes picos de tráfico irregulares y necesitas autoscaling real (Hot Sale, Buen Fin, lanzamientos).
- Quieres un modelo multi-cloud o híbrido con portabilidad genuina.
- Tienes equipos de desarrollo que se beneficiarían de un workflow GitOps maduro.
No vale la pena cuando:
- Tu sistema es un monolito que se despliega 2 o 3 veces al mes. Un Elastic Beanstalk, App Runner o un par de VMs con Ansible siguen siendo más sencillos y baratos.
- No tienes a nadie en el equipo con experiencia operando Linux a profundidad.
- Tu carga es predecible y baja. Pagar el "impuesto K8s" sin necesidad real es desperdicio.
En empresas con 30 a 200 empleados que vemos en México, alrededor del 40% de los proyectos donde se planteó Kubernetes en realidad estaban mejor servidos por una opción más simple.
Managed: la única vía sensata para casi todos
Si la decisión es Kubernetes, el siguiente paso es no autohospedarlo. La operación de un control plane propio (etcd, API server, scheduler, certificados rotando) consume entre 20% y 40% del tiempo de un equipo de plataforma. Es trabajo que no diferencia tu producto.
Para empresas medianas en México las opciones razonables son:
- Amazon EKS: la más madura, integración profunda con IAM, VPC y servicios AWS. Costo del control plane: USD 73 al mes por cluster.
- Google GKE Autopilot: la mejor experiencia de desarrollo, pagas por pod usado. Excelente si tu equipo no quiere pensar en nodos.
- Azure AKS: sólida, sobre todo si ya estás integrado con Entra ID y M365.
- DigitalOcean Kubernetes: subestimada. Para cargas de menor escala y presupuestos ajustados, es la opción con mejor relación costo-simplicidad. Control plane gratis.
En todas, los nodos worker se cobran por separado al precio de las VMs subyacentes.
Stack mínimo razonable
Una vez con el cluster managed corriendo, el riesgo es caer en la trampa de instalar todo lo que dijo el último blog post. Recomendamos un stack mínimo viable y crecer solo cuando duela no tener algo:
- Ingress / Gateway: ahora con Gateway API (envoy gateway o el ingress de tu proveedor).
- Observabilidad: Prometheus + Grafana para métricas, Loki para logs, Tempo para trazas. O un SaaS como Grafana Cloud o Datadog si prefieres no operar el stack.
- Secretos: External Secrets Operator conectado a AWS Secrets Manager, GCP Secret Manager o Azure Key Vault. Nunca secretos en YAML.
- GitOps: ArgoCD o Flux. Sin esto, terminas haciendo
kubectl applydesde laptops y perdiendo trazabilidad. - Políticas: Kyverno para validar manifests (no permitir
latest, requerir resource limits, prohibir privilegios root). - FinOps: OpenCost desde el día uno. Saber qué cuesta cada cosa cambia decisiones.
Eso es todo lo que la mayoría necesita los primeros 12 meses. Service mesh (Istio, Linkerd) puede esperar hasta que tengas un problema concreto que justifique su complejidad.
Plan de migración en 90 días
Para empresas que ya decidieron migrar, este es el ritmo que recomendamos:
Días 1 a 30: fundación. Provisionar el cluster managed, montar el stack mínimo, definir políticas. Migrar un solo servicio no crítico (un job nocturno, una API interna). Documentar el runbook.
Días 31 a 60: escala controlada. Migrar 3 a 5 servicios más, incluyendo uno con tráfico real pero baja criticidad. Ajustar autoscaling, definir SLOs, configurar alertas. Capacitar al equipo.
Días 61 a 90: producción crítica. Migrar el primer servicio crítico con un esquema de canary o blue-green. Activar disaster recovery. Cerrar pendientes de seguridad y compliance.
Pasar de cero a operación crítica en 30 días casi siempre termina mal. Tres meses es el mínimo razonable.
Lo que aprendimos en Atlanta
KubeCon NA 2025 dejó dos mensajes claros. Primero, que la comunidad maduró: ya no se celebra la complejidad, se busca reducirla. Segundo, que adoptar Kubernetes en empresa mediana mexicana es viable hoy si se eligen managed services, un stack reducido y un plan realista. La diferencia entre un proyecto exitoso y uno que se atora suele estar más en la decisión inicial de scope que en la tecnología misma.
¿Estás pensando en migrar a Kubernetes? Hagamos un assessment. Agenda una conversación de 30 minutos y revisamos contigo si tu caso justifica la inversión, qué provider te conviene y cómo se vería un plan realista de adopción.