Saltar a contenido

Clusters privados

kubelatch necesita llegar por https al API server de cada cluster que gestiona. Si el API server es privado (un EKS con endpoint privado, un k3s en una oficina), aquí tienes las opciones para alcanzarlo.

kubelatch no tiene relay propio ni soporte específico para túneles. Se usa la red de tu organización.

flowchart LR
  P[Personas y CI] -->|https| K[kubelatch<br/>cluster de gestión]
  K -->|túnel o VPN| A[API server privado]

Las opciones

Opción Cómo Cuándo
VPN o peering Une la red del cluster de gestión con la del cluster privado. La opción más simple si ya existe.
Tailscale El operador de Tailscale en el cluster privado expone el API server: tailscale up --advertise-routes en un nodo, o un ProxyGroup/Connector. kubelatch se ejecuta con un sidecar tailscale (extraContainers y extraVolumes en los values del chart), o el cluster de gestión está en la tailnet. Si ya usas Tailscale. El namespace kubelatch aplica PSA restricted: un sidecar que pida privilegios (por ejemplo NET_ADMIN) no arrancará ahí.
Cloudflare Tunnel Solo el túnel de red (WARP Connector o private networks), que da alcance IP al API server. Si ya usas Cloudflare Zero Trust.

Cloudflare Tunnel de aplicación no sirve

Publicar el API server como aplicación de Cloudflare Access exige un token de servicio de Access en cada petición. kubelatch no puede añadir esa cabecera, así que sus peticiones al cluster se rechazarían.

Registrar el cluster a través del túnel

El registro es el normal (Registrar un cluster), con una diferencia: la dirección del API server que usa kubelatch es la que kubelatch puede alcanzar, no la que usa tu kubectl.

  1. En el primer paso de la tarjeta «Enrolar» del cluster, abre «Opciones avanzadas», escribe esa dirección en «URL del API server para kubelatch», por ejemplo la que resuelve por la tailnet con Tailscale, y pulsa «Generar comando». Si ya tienes el comando, añade --server <url> al final, después de sh -s -- (o -s -- --server <url> si termina en un sh a secas): gana al campo.
  2. Ejecuta el comando de enrolamiento como siempre, con el kubeconfig de tu kubectl. El script muestra las dos direcciones (kubelatch will reach that API server at …) y pide confirmación.
  3. La CA no cambia: el script envía la de tu kubeconfig.

No editas ningún JSON. Si kubelatch no llega a esa dirección, rechaza los tokens, el script lo dice y el enlace sigue valiendo (hasta 10 intentos rechazados): vuelve a ejecutarlo con el --server correcto.

La URL solo admite https y nunca una IP literal link-local, de metadatos o multicast (los nombres no se resuelven para comprobarlo).

Comprueba que funciona

  • El cluster pasa a «Listo» en «Clusters».
  • «Namespaces» lista los namespaces del cluster.
  • Una petición a través del proxy funciona. Si el proxy responde 502 con could not talk to the cluster's API server, kubelatch no llega al server registrado: revisa el túnel y las rutas desde el cluster de gestión. El error completo está en el log de kubelatch.