---
title: "Red"
description: "Consulta el endpoint de API y el esquema de red de tu clúster Kubernetes: CIDR de pods, de servicios, red de nodos y red privada conectada."
category: "Despliegue"
language: es
source: https://cubepath.com/es/docs/products/despliegue/k8s-network-es
updated: 2026-08-04
---

# Red

Abre el clúster → pestaña **Network** en [my.cubepath.com](https://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](/docs/products/despliegue/redes-privadas) conectada, con su nombre y CIDR, si conectaste una |

> Nota: Mientras 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](/docs/products/despliegue/k8s-load-balancers-es). Así los workers quedan fuera de internet público mientras tus apps siguen siendo accesibles.