OKE en producción: qué es distinto respecto a EKS y GKE

Los equipos que han llevado EKS o GKE encuentran OKE familiar en una hora — es Kubernetes upstream con plano de control gestionado, los complementos habituales y una CLI sensata. Las diferencias que importan son pocas, y tres merecen planificarse.

Las tres diferencias reales

El plano de control básico es gratuito. Los clústeres enhanced llevan una cuota por hora y añaden funciones que probablemente quieras en producción (gestión del ciclo de vida de complementos, workload identity, límites de nodos más altos), pero el coste de entrada es menor que en los equivalentes. En un entorno con muchos clústeres pequeños —por equipo o por entorno— esto cambia de verdad lo que es asumible.

Pools de nodos ARM Ampere A1 con una franquicia siempre gratuita sustancial. Para un clúster de desarrollo o de herramientas internas, esto puede significar que el cómputo sea casi gratis. Aplican las mismas consideraciones de build que en cualquier otro sitio: imágenes multiarquitectura, comprobar que tus agentes y operadores tienen build ARM, y pools separados en lugar de arquitecturas mezcladas.

La elección de CNI se hace al crear el clúster y no se puede cambiar. Esta es la decisión que hay que acertar.

Red nativa de VCN o flannel: elige a propósito

La red de pods nativa de VCN da a cada pod una IP de una subred de la VCN. Los pods son directamente direccionables desde el resto de tu VCN, los grupos de seguridad de red se aplican a los pods y el tráfico entre servicios no atraviesa una superposición. Es la elección correcta para producción, y viene con la restricción de que debes planificar la subred de pods con margen real — la misma trampa de agotamiento que pilla a la gente con Azure CNI en AKS.

Dimensiónala bien: pods por nodo por número máximo de nodos, más capacidad extra para las actualizaciones. Un /24 no basta para un clúster que pretendes hacer crecer.

La superposición flannel ahorra espacio de direcciones de la VCN y es más simple donde el espacio de IP es escaso, a costa de las políticas de red a nivel de pod y de la direccionabilidad directa.

No hay migración en caliente entre ambos, así que es una decisión de recreación de clúster.

Identidad: workload identity, no ficheros de configuración

Los clústeres enhanced admiten workload identity, que permite a una cuenta de servicio de Kubernetes autenticarse directamente contra los servicios de OCI. Úsalo. La alternativa —una clave de firma de API en un Secret de Kubernetes— es el patrón de credencial que las políticas y grupos dinámicos de OCI existen para sustituir.

Para el acceso a las APIs de OCI a nivel de nodo, principales de instancia mediante un grupo dinámico emparejado por el compartimento del pool de nodos y una etiqueta definida.

Pools de nodos y coste

El trabajo de coste es el mismo que en cualquier Kubernetes gestionado y la palanca es la misma: requests fijadas a partir del uso observado, y empaquetado. Todo lo de por qué tu clúster de EKS cuesta el doble se transfiere sin cambios — la razón entre CPU solicitada y usada es el número que decide tu factura con independencia del proveedor.

Añadidos específicos de OCI:

• Formas flexibles para los nodos. Puedes dimensionar un pool a las OCPU y memoria exactas que necesitan tus pods en lugar de redondear a una talla, lo que mejora el empaquetado antes de afinar nada.
• Pools de nodos interrumpibles para lotes, CI y réplicas sin estado.
• Un pool aparte para los componentes de sistema, con taint, para que los complementos no compitan con las cargas.

El autoescalador soportado es Cluster Autoscaler; configúralo por pool de nodos y pon mínimos sensatos para que un escalado a cero no te deje sin capacidad para CoreDNS.

Lista de comprobación antes de producción

• Endpoint de API privado, con un bastión o una sesión del servicio OCI Bastion para el acceso. Un endpoint público de la API de Kubernetes es superficie de ataque innecesaria.
• Grupos de seguridad de red en las subredes de pods y nodos, no solo listas de seguridad — los NSG son el más granular y mantenible de los dos modelos de cortafuegos de OCI.
• Logs hacia OCI Logging y métricas hacia Monitoring, con los flow logs de la VCN activados.
• Escaneo de imágenes en OCI Container Registry, y Cloud Guard activado en la tenancy.
• Plan de actualización. Las versiones de OKE caducan según un calendario como en cualquier Kubernetes gestionado; fija una cadencia trimestral y prueba en un clúster de preproducción de la misma versión.
• Pod Disruption Budgets antes de la primera actualización de un pool de nodos, no después.

Dónde encaja OKE

Para una organización ya en OCI por coste o por licencias, OKE es un Kubernetes gestionado sólido sin carencias significativas para cargas estándar. No es por sí solo un motivo para elegir OCI, y el ecosistema a su alrededor —operadores, charts de Helm que asumen otras nubes, integraciones de proveedores— es más fino, así que reserva algo de tiempo para los bordes. Lo desplegamos y operamos en proyectos cloud junto a los otros tres proveedores.

Qué hacer esta semana

Comprueba qué CNI usa tu clúster y, si es nativa de VCN, calcula cuántos pods admite tu subred de pods. Ese número es tu techo de escalado y es mucho mejor saberlo ahora que durante un crecimiento.