Abre el clúster → pestaña Network en my.cubepath.com.
Una vista de solo lectura de cómo está cableado el clúster. Los valores se fijan en la creación, y por eso mismo conviene entenderlos antes de crear el siguiente clúster.
Qué se muestra
| Campo | Qué es |
|---|---|
| API Endpoint | La dirección con la que habla kubectl. Es también la que va dentro del kubeconfig |
| Pod CIDR | El rango del que los pods toman dirección (por defecto 10.42.0.0/16) |
| Service CIDR | El rango del que los servicios ClusterIP toman dirección (por defecto 10.43.0.0/16) |
| Node Network | El rango en el que están los propios nodos worker |
| Private Network | La red privada conectada, con su nombre y CIDR, si conectaste una |
NotaMientras el clúster se está aprovisionando, el endpoint de API aparece como no disponible aún. Se muestra cuando el control plane está arriba.
Por qué importan los CIDRs
Estos tres rangos no deben solaparse entre sí, ni con la red de nodos, ni con nada a lo que pienses llegar desde dentro del clúster. El solapamiento no falla ruidosamente al crear: falla después, como tráfico hacia un rango concreto que se va en silencio al sitio equivocado.
El caso clásico: tu oficina u otra VPC usa 10.42.0.0/16, el rango de pods del clúster es el mismo, y los pods ya no llegan a esa red porque el clúster la enruta internamente. Revisa tus rangos existentes antes de desplegar y define CIDRs personalizados en Advanced Settings si hay conflicto.
Aviso: Los CIDRs de pods y servicios no se pueden cambiar después de crear el clúster. Arreglar un solapamiento implica reconstruirlo.
Workers públicos y privados
Los workers reciben IPv4 e IPv6 públicas por defecto. Desactivar la IPv6 pública requiere una red privada para que los nodos sigan siendo accesibles.
Para un clúster sin ninguna IP pública en los workers, conecta una red privada al desplegar y expón los servicios a través de un balanceador de carga. Así los workers quedan fuera de internet público mientras tus apps siguen siendo accesibles.