11 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Explicar con precisión qué aísla un Cluster privado (el plano de datos de los nodos) y qué no aísla (el punto de acceso de la API de Kubernetes), y proteger la API de manera correcta.
  • Establecer la secuencia de las dos dependencias de red (una NAT Gateway y, para el tráfico de nodos entre VDC, un Private Cross Connect) que deben existir antes de que se cree el Cluster.
  • Colocar el plano de control dentro de la región por motivos de soberanía y razonar sobre los campos que se vuelven permanentes en el momento de la creación.
  • Aprovisionar un Cluster privado y un grupo de nodos privado en el Data Center Designer, reutilizando el patrón de Cluster público de la Unidad 6.2.

Unidad 6.3: Aprovisionamiento de un Cluster privado

Introducción

Un clúster privado es la configuración predeterminada de producción para un entorno regulado: los nodos de trabajo no tienen NICs públicas, por lo que el plano de datos solo es accesible a través de su red privada. Dicho aislamiento es real, pero más limitado de lo que el nombre sugiere, y esa diferencia es donde los equipos suelen tener problemas. Esta unidad define con claridad el límite, corrige los requisitos de red que deben existir previamente y, a continuación, construye la variante privada en Data Center Designer sobre la base del patrón de clúster público de la Unidad 6.2.

1. Lo que "privado" aísla y lo que no

La decisión de configurar un clúster como privado se aplica a la piscina de nodos, no a todo el servicio. Una piscina de nodos privada se despliega en una LAN privada detrás de una NAT Gateway: el tráfico saliente hacia internet se permite a través de la pasarela, pero el tráfico entrante no. Los nodos no tienen direcciones públicas, y el tráfico entre nodos y servicios de Kubernetes permanece en su red privada. Esa es la aislación del plano de datos que FinCorp necesita para las cargas de trabajo que manipulan datos de cuentas bajo el RGPD y los controles de BSI.

Lo que la configuración privada no hace es ocultar el servidor de API de Kubernetes. El plano de control es administrado por IONOS CLOUD y el punto de acceso de la API permanece expuesto a internet, independientemente del tipo de piscina de nodos. Considerar un "clúster privado" como si también aplicara un cortafuegos a la API es el malentendido central de esta unidad. La plataforma le ofrece un control separado para ello: el clúster cuenta con una lista de permisos de IP para la API (la configuración "Restrict Access by IP"), de modo que protege la API enumerando los rangos de origen autorizados a acceder a ella, por ejemplo, las IP de salida de CI/CD de FinCorp y la salida de VPN del equipo de operaciones. Aislar los nodos y aplicar una lista de permisos a la API son decisiones independientes; un clúster privado conforme a las normativas requiere ambas.

Dos límites de la Unidad 6.1 son más relevantes aquí. El tipo de servicio LoadBalancer no está disponible en piscinas de nodos privadas, por lo que el patrón de nodo de entrada único desaparece; la entrada es un equilibrador de carga provisionado por separado más un controlador de entrada dentro del clúster (el patrón de la Unidad 6.2). Y los grupos de seguridad de red se vinculan a las NIC de los nodos de trabajo, no a la abstracción del clúster, por lo que las políticas de red dentro del clúster siguen siendo su control a nivel de pod.

2. Las dos dependencias de red (constrúyalas primero)

Un clúster privado prioriza la red: el diálogo de creación de clúster solicita una IP de pasarela que debe existir previamente, por lo que la red debe construirse antes que el clúster.

Pasarela NAT para tráfico de salida. Los nodos privados aún requieren acceso a Internet saliente para la descarga de imágenes, actualizaciones de paquetes y de seguridad, NTP y tráfico de Backup Service. Esa ruta es la Managed NAT Gateway, que es solo SNAT: no proporciona tráfico entrante (sin DNAT), lo cual es exactamente la propiedad que mantiene el plano de datos privado. La pasarela requiere una dirección IPv4 pública reservada, y esa IP reservada se convierte en la IP de pasarela del clúster. Un detalle crítico: la ruta predeterminada hacia la pasarela no se inyecta automáticamente. Para las VM privadas, la tabla de enrutamiento debe modificarse para que la ruta predeterminada (o una ruta dedicada por destino) apunte a la pasarela NAT; la integración del grupo de nodos privados gestiona la salida de los nodos a través de la pasarela, pero usted es responsable de la IP reservada y de la intención de enrutamiento. Una sola pasarela NAT puede servir hasta seis LAN privadas.

Cross Connect privado para tráfico de nodos entre VDC. Cuando los nodos deben alcanzar recursos en otro centro de datos virtual (para FinCorp, la capa de datos privada del Módulo 5 en un VDC separado), esa ruta este-oeste es un Cross Connect privado. Sus restricciones son reglas de elegibilidad, no opciones: es solo de la misma región y del mismo contrato (sin cruce de regiones, sin cruce de contratos), todas las NIC en todos los VDC conectados deben compartir el mismo rango de IP, y cada LAN puede pertenecer a solo una conexión Cross Connect. Su ancho de banda es comparable al de una NIC privada normal, y no es gratuito. Establezca esta conexión antes de que se inicien los grupos de nodos que dependen de la conectividad entre VDC, o esos nodos se aprovisionarán en una red que no puede ver sus dependencias.

Recorrido de implementación de DCD

Objetivo de la construcción: Construir la variante privada reutilizando los patrones del Cluster público, comenzando por la red.

Creará un Cluster privado y un grupo de Node privado en el Data Center Designer para la plataforma de contenedores de FinCorp. Esto reutiliza el flujo del Cluster público de la Unidad 6.2; las diferencias son los requisitos previos de red y tres campos que se vuelven permanentes. El recorrido del grupo de Node en sí (configuraciones del grupo, plantilla de Node, tipo de servidor, almacenamiento, LAN conectada y IPs reservadas) es idéntico al de la 6.2 y no se repite aquí.

Requisitos previos: una dirección IPv4 reservada para el Gateway de NAT (DCD > Menú > Servicios de red > Gestión de IP); un Gateway de NAT conectado a la LAN privada con la ruta predeterminada de la LAN apuntando a este; y, donde los Node necesiten otro VDC, un Cross Connect privado instalado. El VDC y su región se reutilizan de módulos anteriores.

Pasos (en el Data Center Designer):

  1. Reserve una dirección IPv4 bajo Menú > Servicios de red > Gestión de IP. Esto se convierte en la IP del Gateway, por lo que resérvela antes de abrir el diálogo del Cluster.
  2. Construya el Gateway de NAT: seleccione el centro de datos, asegúrese de que exista una red privada con la LAN de trabajadores, agregue el Gateway de NAT, conecte su interfaz de origen a esa LAN privada y asigne la IP pública reservada en la pestaña Inspector > Configuración. Establezca la ruta predeterminada de la LAN privada para que apunte al gateway.
  3. Vaya a Menú > Contenedores > Managed Kubernetes y seleccione + Crear Cluster. Ingrese un Nombre siguiendo la convención de nomenclatura de Kubernetes (máximo 63 caracteres, inicio y fin alfanuméricos).
  4. Seleccione la Versión de Kubernetes desde el menú desplegable.
  5. En el campo de tipo de grupo de Node, elija Privado.
  6. Seleccione una Región desde el menú desplegable. Solo puede crear los VDCs del Cluster privado en la misma región que el Cluster, por lo que esto fija la ubicación de soberanía ahora.
  7. En IP del Gateway, seleccione la IP reservada asignada a su Gateway de NAT.
  8. (Opcional) Defina una Subred para la LAN privada: una CIDR de /16 que no debe intersectar las redes de pods y servicios del Cluster (para Kubernetes 1.30 y superiores, 100.96.0.0/12 y 100.64.0.0/18; para versiones anteriores, 10.208.0.0/12 y 10.233.0.0/18).
  9. Seleccione + Crear Cluster. Una vez que el Cluster esté activo, agregue el grupo de Node privado exactamente como en la Unidad 6.2: un grupo de Node requiere un centro de datos en la misma ubicación que el Cluster, además de una LAN privada conectada y IPs reservadas.
  10. Establezca la lista de permisos de IP de la API (Restringir acceso por IP) a los rangos de origen permitidos para alcanzar la API de Kubernetes, luego recupere el kubeconfig para conectarse con kubectl.

Errores comunes:

  • Tratar "privado" como si protegiera la API. Protege los Node; la API sigue siendo administrada y accesible desde internet. Establezca la lista de permisos de IP por separado, o el plano de control quedará abierto al mundo.
  • Crear el Cluster antes que el Gateway de NAT. El campo IP del Gateway necesita una IP reservada que ya exista en un gateway desplegado.
  • Suponer que la salida funciona por sí sola. La ruta predeterminada de NAT no se inyecta automáticamente; establezca la ruta predeterminada de la LAN privada hacia el gateway, o las descargas de imágenes y actualizaciones fallarán silenciosamente.
  • Elegir una región de EE. UU. para el plano de control en una carga de trabajo vinculada a soberanía. Para un Cluster privado, el plano de control se crea en el centro de datos elegido, por lo que la selección de región es la decisión de soberanía.
  • Contar con un Servicio de LoadBalancer. No está disponible en grupos de Node privados; use un equilibrador de carga provisionado por separado más un controlador de entrada dentro del Cluster.
  • Olvidar que los campos son permanentes. Región, IP del Gateway y Subred no se pueden cambiar después del aprovisionamiento, y el tipo de grupo de Node no se puede cambiar entre privado y público.

3. Colocación e inmutabilidad del plano de control

En un clúster privado, el plano de control se crea en el centro de datos que usted elija, de modo que los metadatos del plano de control permanecen en la región seleccionada. Al elegir la ubicación Alemania (Frankfurt), los datos del plano de control de FinCorp se mantienen en Alemania y se preserva la soberanía de la UE y de Alemania; las cargas de trabajo y los datos de los grupos de nodos siempre permanecen en la región elegida, independientemente de la ubicación del plano de control. Este es el mecanismo práctico detrás del principio de soberanía como colocación de la Unidad 1.4, y difiere de un clúster público, cuyo plano de control administrado se ejecuta en Frankfurt o en uno de tres centros de datos de Estados Unidos.

Varias decisiones en el momento de la creación son decisiones de diseño permanentes, no valores predeterminados de la consola. El tipo de grupo de nodos (privado frente a público) es inmutable después de la creación, y la Región, la IP de la pasarela y la subred del clúster privado no pueden modificarse una vez aprovisionados. Aún puede cambiar el tipo de servidor de un grupo de nodos entre Dedicated Core y vCPU, pero el tipo y la anclaje de red quedan fijos. Asegúrese de configurar correctamente la región y los requisitos previos de red antes de hacer clic en crear; el único remedio posterior es reconstruir el clúster.

Resumen

Un clúster privado aísla el plano de datos de los nodos detrás de una NAT Gateway con solo SNAT, manteniendo el punto de acceso de la API administrada por IONOS CLOUD accesible desde internet. Por lo tanto, una implementación conforme combina pools de nodos privados con una lista de autorización de IP para la API de forma explícita. La implementación prioriza la red: una IP reservada y una NAT Gateway (con la ruta predeterminada configurada), así como un Private Cross Connect en la misma región y con el mismo contrato para el tráfico de nodos entre VDC, deben existir antes de crear el clúster. Colocar el plano de control en la región alemana elegida preserva la soberanía, y dado que el tipo de pool de nodos, la región, la IP de la gateway y la subred se fijan en el momento de la creación, las decisiones tomadas aquí son permanentes.

Puntos clave:

  • Private aísla los nodos, no la API; proteja el punto de acceso de la API mediante la lista de autorización de IP como un paso separado y obligatorio.
  • La NAT Gateway (egreso, solo SNAT, IP reservada, ruta predeterminada manual) y el Private Cross Connect (entre VDC, solo en la misma región y con el mismo contrato) son requisitos previos, no adiciones posteriores.
  • En un clúster privado, el plano de control se encuentra en la región elegida, por lo que la selección de la región es la decisión de soberanía.
  • La región, la IP de la Gateway, la Subred y el tipo de pool de nodos son inmutables después de la creación; la guía del pool de nodos en sí es la misma que la de la Unidad 6.2.