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 Node) y qué no (el punto final de Kubernetes API), y proteger el API correctamente.
  • Secuenciar las dos dependencias de red (una puerta de enlace NAT y, para el tráfico de Node entre VDC, un Cross Connect privado) que deben existir antes de que se cree el Cluster.
  • Colocar el plano de control en la región para la 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 Node 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 Cluster privado es el valor predeterminado de producción para un patrimonio regulado: los Worker Nodes no llevan NICs públicas, por lo que el plano de datos solo es accesible a través de su red privada. Esa isolación es real, pero más estrecha de lo que sugiere el nombre, y la diferencia es donde los equipos se ven afectados. Esta unidad hace que el límite sea honesto, corrige los requisitos de red previos que deben existir primero, y luego construye la variante privada en el Data Center Designer sobre el patrón de Cluster público de la Unidad 6.2.

1. Qué aísla "Private" y qué no

La decisión de privacidad se aplica al Node Pool, no al servicio completo. Un Node Pool privado se implementa en un LAN privado detrás de una puerta de enlace NAT: el tráfico saliente hacia internet está permitido a través de la puerta de enlace, pero el tráfico entrante no. Los nodos no tienen direcciones públicas, y el tráfico de Node a Kubernetes permanece en su red privada. Esa es la isolación del plano de datos que FinCorp quiere para las cargas de trabajo que tocan los datos de cuenta bajo GDPR y controles BSI.

Lo que "private" no hace es ocultar el servidor Kubernetes API. El plano de control es gestionado por IONOS y el punto final API sigue siendo accesible desde internet, independientemente del tipo de Node Pool. Tratar "private Cluster" como si también fuera un cortafuegos para el API es el concepto erróneo central de esta unidad. La plataforma le proporciona un control separado para eso: el Cluster lleva una lista de permitidos API IP (la configuración "Restringir acceso por IP"), por lo que protege el API enumerando los rangos de origen permitidos para llegar a él, por ejemplo, las direcciones IP de salida de FinCorp CI/CD y la dirección de salida del equipo de operaciones VPN. Aislar los nodos y permitir la lista de API son decisiones independientes; un Cluster privado conforme necesita ambas.

Dos límites de la Unidad 6.1 importan más aquí. El tipo de servicio LoadBalancer no está disponible en Node Pools privado, por lo que el patrón de single-ingress-Node ha desaparecido; el ingreso es un Load Balancer provisionado por separado más un controlador de ingreso en Cluster (el patrón de la Unidad 6.2). Y Network Security Groups se unen a las NIC de los trabajadores, no a la abstracción Cluster, por lo que las políticas de red en Cluster siguen siendo su control a nivel de pod.

2. Las dos dependencias de red (Construya estas primero)

Un Cluster privado es de networking-first: el diálogo create-Cluster solicita una puerta de enlace IP que ya debe existir, por lo que la red tiene que estar construida antes de que se cree el Cluster.

Puerta de enlace NAT para salida. Los nodos privados aún necesitan internet saliente para obtener imágenes, actualizaciones de paquetes y seguridad, NTP y tráfico de Backup Service. Ese camino es la Managed NAT Gateway, que es SNAT-only: no proporciona entrada (no DNAT), lo que es exactamente la propiedad que mantiene el plano de datos privado. La puerta de enlace requiere una dirección pública IPv4 reservada, y esa dirección IP reservada se convierte en la puerta de enlace IP del Cluster. Un detalle crítico: la ruta predeterminada a la puerta de enlace no se inyecta automáticamente. Para las máquinas virtuales privadas, la tabla de enrutamiento debe modificarse para que la ruta predeterminada (o una ruta dedicada por destino) apunte a la puerta de enlace NAT; la integración del Node Pool privado maneja la salida Node a través de la puerta de enlace, pero usted es el propietario de la dirección IP reservada y la intención de enrutamiento. Una sola puerta de enlace NAT puede servir hasta seis redes LAN privadas.

Red privada Cross Connect para tráfico Node entre centros de datos virtuales. Cuando los nodos deben acceder a recursos en otro Centro de Datos Virtual (para FinCorp, el nivel de datos privado del Módulo 5 en un VDC separado), ese camino de este a oeste es una Red Privada Cross Connect. Sus restricciones son reglas de elegibilidad, no opciones: es de la misma región y mismo contrato solo (no entre regiones, no entre contratos), cada NIC en cada VDC conectado debe compartir el mismo rango de direcciones IP, y cada LAN solo puede pertenecer a una conexión Cross Connect. Su ancho de banda es comparable al de una NIC privada normal, y no es gratuito. Establezca la conexión antes de que los Node Pools que dependen de la conectividad entre centros de datos virtuales se inicien, o esos nodos se provisionarán en una red que no puede ver sus dependencias.

DCD Implementación paso a paso

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

Usted creará un Cluster privado y un grupo de Node privado en el Data Center Designer para la plataforma de contenedores FinCorp. Esto reutiliza el flujo de Cluster público de la Unidad 6.2; las diferencias son los requisitos previos de red y tres campos que se vuelven permanentes. La guía del grupo de Node en sí (ajustes de grupo, plantilla de Node, tipo de servidor, almacenamiento, LAN adjunto y direcciones IP reservadas) es idéntica a la de 6.2 y no se repite aquí.

Requisitos previos: una dirección IPv4 reservada para la puerta de enlace NAT (DCD > Menú > Servicios de red > Administración de IP); una puerta de enlace NAT adjunta a la LAN privada con la ruta predeterminada de LAN apuntando a ella; y, donde los nodos necesitan otro VDC, un Cross Connect privado en su lugar. El VDC y su región se reutilizan de módulos anteriores.

Pasos (en el Data Center Designer):

  1. Reserve una dirección IPv4 en Menú > Servicios de red > Administración de IP. Esto se convierte en la dirección IP de la puerta de enlace, así que réservela antes de abrir el diálogo de Cluster.
  2. Construya la puerta de enlace NAT: seleccione el centro de datos, asegúrese de que exista una red privada con la LAN de trabajo, agregue la puerta de enlace NAT, conecte su interfaz de origen a esa LAN privada y asigne la dirección IP pública reservada en la pestaña Configuración del Inspector. Establezca la ruta predeterminada de LAN privada para que apunte a la puerta de enlace.
  3. Vaya a Menú > Contenedores > Managed Kubernetes y seleccione + Crear Cluster. Introduzca un nombre siguiendo la convención de nomenclatura de Kubernetes (máximo 63 caracteres, inicio y fin alfanumérico).
  4. Seleccione la versión de Kubernetes del menú desplegable.
  5. En el campo de tipo de grupo de Node, elija Privado.
  6. Seleccione una Región del menú desplegable. Solo puede crear los VDC de Cluster privado en la misma región que el Cluster, así que esto fija la ubicación de soberanía ahora.
  7. En Dirección IP de la puerta de enlace, seleccione la dirección IP reservada asignada a su puerta de enlace NAT.
  8. (Opcional) Defina una Subred para la LAN privada: una subred /16 CIDR que no debe intersectar las redes de pods y servicios de Cluster (para Kubernetes 1.30 y superior, 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, más una LAN privada adjunta y direcciones IP reservadas.
  10. Establezca la lista de permitidos de dirección IP de API (Restringir acceso por IP) a los rangos de origen permitidos para llegar al API de Kubernetes, luego recupere el kubeconfig para conectarse con kubectl.

Errores comunes:

  • Tratar "privado" como si protegiera el API. Protege los nodos; el API sigue siendo administrado y accesible desde Internet. Establezca la lista de permitidos de IP por separado, o el plano de control estará abierto al mundo.
  • Crear el Cluster antes de la puerta de enlace NAT. El campo de dirección IP de la puerta de enlace necesita una dirección IP reservada que ya exista en una puerta de enlace desplegada.
  • Suponer que el tráfico de salida funciona automáticamente. La ruta predeterminada de NAT no se inyecta automáticamente; establezca la ruta predeterminada de LAN privada para que apunte a la puerta de enlace o las imágenes y actualizaciones fallarán silenciosamente.
  • Elegir una región de EE. UU. para el plano de control en un Workload vinculado a la soberanía. Para un Cluster privado, el plano de control se crea en el centro de datos elegido, así que la selección de región es la decisión de soberanía.
  • Confiar en un Servicio de equilibrio de carga. No está disponible en Node Pools privado; use un Load Balancer provisionado por separado más un controlador de entrada dentro de Cluster.
  • Olvidar que los campos son permanentes. La región, la dirección IP de la puerta de enlace y la subred no se pueden cambiar después de la provisión, y el tipo de grupo de Node no se puede cambiar entre privado y público.

3. Colocación del plano de control y mutabilidad

Para un Cluster privado, el plano de control se crea en el centro de datos que usted elige, por lo que los metadatos del plano de control permanecen en la región elegida. Elegir la ubicación de Alemania (Frankfurt) mantiene los datos del plano de control de FinCorp en Alemania y preserva la soberanía de la UE/Alemania; las cargas de trabajo y los datos del Node Pool siempre permanecen en la región elegida, independientemente de esto. Esto es el principio práctico detrás del principio de soberanía como colocación de la Unidad 1.4, y difiere de un Cluster público, cuyo plano de control administrado se ejecuta en Frankfurt o en uno de los tres centros de datos de EE. UU.

Varias opciones de creación son decisiones de diseño permanentes, no valores predeterminados de la consola. El tipo de Node Pool (privado o público) es inmutable después de la creación, y la región, la puerta de enlace IP y la subred de un Cluster privado no se pueden cambiar una vez provisionados. Usted todavía puede cambiar el tipo de servidor de un Node Pool entre Dedicated Core y vCPU, pero el tipo y la anclaje de red están fijos. Obtenga la región y los requisitos de red correctos antes de hacer clic en crear; el único remedio después es reconstruir el Cluster.

Resumen

Un Cluster privado aísla el plano de datos de Node detrás de una puerta de enlace NAT solo SNAT, mientras deja el punto de conexión de API administrado por IONOS accesible desde internet, por lo que una compilación compatible empareja Node Pools privado con una lista de permitidos explícita de API IP. La compilación es de networking en primer lugar: un IP reservado y una puerta de enlace NAT (con la ruta predeterminada establecida), y un Cross Connect privado de la misma región y contrato para el tráfico de Node entre centros de datos virtuales, deben existir antes de que se cree el Cluster. Colocar el plano de control en la región alemana elegida preserva la soberanía, y como el tipo de grupo de Node, la región, la puerta de enlace IP y la subred están todos fijos en el momento de la creación, las decisiones aquí son permanentes.

Puntos clave:

  • El privado aísla los nodos, no el API; proteja el punto de conexión de API con la lista de permitidos de IP como un paso separado y obligatorio.
  • La puerta de enlace NAT (salida, solo SNAT, IP reservado, ruta predeterminada manual) y el Cross Connect privado (entre centros de datos virtuales, misma región y contrato solo) son requisitos previos, no adiciones posteriores.
  • Para un Cluster 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 puerta de enlace IP, la subred y el tipo de grupo de Node son inmutables después de la creación; el recorrido del grupo de Node en sí es el mismo que la Unidad 6.2.