Kubernetes para Gerentes V2
En octubre de 2023 publiqué el post Kubernetes para Gerentes dirigido a gestores de equipos técnicos. En aquel momento, el tema parecía urgente porque había un movimiento casi emocional en dirección a Kubernetes. Muchos gestores con quienes conversaba sentían que necesitaban migrar simplemente porque otras empresas del mercado estaban haciendo lo mismo.
Las preguntas que planteé en aquella época tenían un objetivo claro: reducir el ruido, bajar la ansiedad y crear un diálogo más racional entre quien gestiona equipos y quien está más cerca de las implementaciones técnicas en el día a día, los Tech Leads.
Pasados poco más de dos años, la pregunta “migrar o no migrar a Kubernetes” prácticamente dejó de existir. Kubernetes se consolidó como una plataforma madura y extremadamente versátil para muchos casos de uso, aunque sigue siendo bastante complejo. Aun así, en 2025 y 2026 (que ya está ahí), ese diálogo sigue siendo necesario, pero las preguntas necesitan evolucionar, por eso decidí crear esta V2.
A continuación, mira algunas cuestiones sobre Kubernetes que considero fundamentales en el contexto actual:
Escalabilidad, capacidad y costo
En vez de simplemente “agregar más nodos”, ¿vamos a usar Karpenter para aprovisionamiento o todavía dependemos solo del cluster autoscaler tradicional?
¿Cómo está la configuración del Vertical Pod Autoscaler (VPA) para evitar desperdicio?
Además de CPU y memoria, ¿las aplicaciones exigen GPUs o TPUs para workloads de IA o LLMs?
¿Vamos a usar HPA basado solo en CPU? ¿HPA + métricas personalizadas? ¿Ya probaste si la regla funciona? ¿Esta aplicación usa más CPU o memoria?
¿Las aplicaciones soportan scale-to-zero en Kubernetes? ¿Tiene sentido tener eso ya que pagamos por algunos nodos encendidos 24x7?
¿El equipo entiende el impacto financiero del autoscaling? ¿Existe visibilidad clara de costo por aplicación o por namespace?
Tráfico, red y exposición de servicios
¿Todavía vamos a utilizar Ingress Controllers legados o tiene sentido migrar al Kubernetes Gateway API para obtener más control sobre el tráfico L4 y L7?
¿NGINX va a dejar de ser el ingress controller? ¿Existen planes de migración?
¿Cómo se implementará el mTLS?
¿El rate limit se hará en el gateway o vía service mesh para soportar picos extremos? ¿Es necesario un nuevo deploy para ajustar esas políticas? ¿Puede hacerse sin GMUD?
Seguridad, identidad y secretos
¿Vamos a utilizar External Secrets integrado al provider de cloud?
¿Cómo se autentican las aplicaciones en servicios externos?
¿Estamos usando servicios de identidad para eliminar claves y secretos estáticos?
¿Todavía existen secrets definidos directamente en YAML o, peor, versionados en repositorios?
En las imágenes, ¿existe una estrategia clara para scanning continuo de CVEs y remediación?
Resiliencia, disponibilidad y datos
¿Cómo está definida la estrategia de backup del cluster y de las aplicaciones? No estamos asumiendo que “el cluster nunca va a caer”, ¿verdad?
¿El cluster será “zonal” o regional?
¿Las aplicaciones están preparadas para fallo de zona? ¿La base de datos también?
¿El costo de una arquitectura multi-AZ está justificado por el negocio y alineado con la arquitectura? ¿Quién tomó esa decisión?
¿El equipo entiende los límites de escalabilidad del etcd y sus impactos operativos?
Performance y pruebas
¿Ya se ejecutaron pruebas automatizadas de carga, stress y spike?
¿Esas pruebas consideran todas las aplicaciones corriendo simultáneamente?
En escenarios como Black Friday, todas las aplicaciones estarán bajo carga máxima al mismo tiempo. Sí, porque en el Black Friday todas las APPs van a estar en utilización máxima al mismo tiempo. ¿Los clusters están probados?
¿Las aplicaciones implementan correctamente liveness, readiness y startup probes? Esta pregunta sigue válida desde siempre.
Organización, aislamiento y gobernanza
Además de la separación por namespaces, ¿existen Network Policies, ResourceQuotas y LimitRanges bien definidos?
¿El acceso al cluster sigue el principio de menor privilegio vía RBAC?
¿Los equipos entienden claramente qué permisos poseen y por qué?
Operación, GitOps y gobernanza de cambios
¿El cluster se gestiona vía GitOps con herramientas como ArgoCD o Flux?
Usar kubectl directamente en producción no escala y no es auditable. ¿Esto está claro?
¿Existe estrategia de rollback automatizado?
¿Cómo se detectan y tratan los drifts de configuración?
¿Es posible proporcionar trazas de auditoría claras sobre cambios en entornos productivos?
¿El Disaster Recovery ya se probó de verdad o existe apenas un procedimiento documentado que nunca fue ejecutado?
Observabilidad y soporte
¿Cómo acceden los equipos de desarrollo a métricas, logs centralizados y traces distribuidos?
¿Existe una política clara de retención de logs? ¿Atiende requisitos de compliance y auditoría?
¿Cómo pueden los equipos de desarrollo tener acceso para visualizar métricas? ¿A los logs centralizados? ¿A los traces distribuidos?
¿Cuál es la política de retención de logs? ¿Atienden al compliance de la empresa? ¿Es auditable?
Modelo operativo
¿Vamos a usar cluster gestionado o self-hosted? En 2025, operar Kubernetes “a mano” no se justifica, ¿no?
¿El equipo está preparado para dar soporte fuera del horario comercial? ¿Existe compartición de conocimientos?
¿Existe una documentación de la infra?
¿La documentación está viva? ¿Existen runbooks claros para los equipos de soporte y guardia?
Resumen
Las preguntas fundamentales sobre arquitectura, disponibilidad y operaciones siguen siendo relevantes, pero el ecosistema Kubernetes maduró de forma significativa. En 2025, algunos temas dejaron de ser diferenciales y se volvieron obligatorios:
- La seguridad pasó a ser más sofisticada e innegociable
- GitOps dejó de ser opcional y se volvió estándar operativo
- FinOps ganó importancia crítica con el aumento de los costos de cloud
- Platform Engineering emergió como disciplina estructurante
- La observabilidad se consolidó con OpenTelemetry
- Los workloads de IA y ML se volvieron comunes en clusters de producción
Mi sugerencia es simple: transforma esas preguntas en un checklist de evaluación o en un punto de partida para conversaciones más maduras con los tech leads de tu equipo.
No te dejes convencer por quien tiene un vocabulario lleno de siglas y expresiones extrañas, cuestiona siempre. Gestionar equipos técnicos nunca fue simple. Exige estudio continuo, decisiones difíciles y mucho trabajo. Quien cree que es fácil todavía no entendió el tamaño del desafío, pero estamos aquí para traer luz a los temas.
¡Un abrazo!
¡Larga y próspera vida a todos!
Referencias
- https://infraascode.com.br/kubernetes-para-gerentes/
- https://www.cve.org/
- https://velero.io/
- https://etcd.io/docs/v3.3/dev-guide/limit/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
- https://kubernetes.io/docs/concepts/workloads/autoscaling/
- https://kubernetes.io/docs/concepts/services-networking/network-policies/
- https://kubernetes.io/docs/concepts/policy/resource-quotas/
- https://kubernetes.io/docs/concepts/policy/limit-range/
Entre em contato:
NewsLetter - https://engineeringmanager.com.br/Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
