10 min de lectura

Objetivos de aprendizaje

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

  • Aprovisionar de extremo a extremo un cluster Managed Kubernetes público y un pool de nodos en el Data Center Designer, eligiendo deliberadamente el tipo de servidor, la versión y la clase de almacenamiento persistente.
  • Recuperar y utilizar el kubeconfig del cluster, y definir una clase de almacenamiento CSI de IONOS CLOUD para volúmenes persistentes aprovisionados dinámicamente.
  • Diseñar correctamente el ingress, dado que los manifiestos no aprovisionan automáticamente un equilibrador de carga administrado, y componer un equilibrador de carga aprovisionado por separado con un controlador de ingress dentro del cluster.
  • Evitar los errores comunes de aprovisionamiento relacionados con el tipo de pool de nodos inmutable, las IPs reservadas, la pérdida de IP de origen y la colocación del plano de control.

Unidad 6.2: Aprovisionamiento de un Cluster público

Introducción

La Unidad 6.1 estableció las decisiones de diseño: un plano de control administrado gratuito sobre grupos de nodos de pago, sin escalado a cero, grupos de seguridad vinculados a las NIC de los nodos de trabajo en lugar del clúster, y la realidad ineludible de que un Service de tipo LoadBalancer no es un equilibrador de carga externo administrado. En esta unidad se materializa un clúster público en Data Center Designer. La implementación es breve; las decisiones con mayor impacto son el tipo de servidor y la versión del grupo de nodos (que determinan aspectos que no pueden modificarse posteriormente), cómo se aprovisiona el almacenamiento persistente a través del controlador CSI y cómo el tráfico llega realmente a sus pods. FinCorp necesita un clúster orientado al público para alojar la capa de API sin estado que da soporte a su nueva capacidad de IA, por lo que se construye exactamente eso.

1. Las decisiones que fija la creación

Dos opciones realizadas en el asistente de creación son efectivamente permanentes. El tipo de node-pool no puede cambiarse entre público y privado después de la creación, y un node-pool público es lo que permite un tipo de servicio LoadBalancer en absoluto (los pools privados no lo admiten). La capa de API de FinCorp está orientada a Internet, por lo que un pool público es correcto aquí; la capa de datos regulados permanece en el clúster privado construido en la Unidad 6.3.

El tipo de servidor se elige por node-pool a partir de Dedicated Core o vCPU. La asignación de recursos de CPU es fija: un núcleo aprovisionado equivale a dos CPUs de Managed Kubernetes. El límite recomendado es de 20 Node por node-pool (máximo duro de 100), y un Node soporta hasta 110 pods y hasta 20 volúmenes adjuntos. FinCorp utiliza Dedicated Core para la capa de API para obtener un núcleo exclusivo y una programación predecible bajo carga.

La ubicación del control plane determina la soberanía. Para un clúster público, el control plane gestionado de IONOS CLOUD se ejecuta en Fráncfort o en uno de tres centros de datos de EE. UU. (Lenexa, Newark, Las Vegas); elegir Fráncfort mantiene los datos del control plane en Alemania, la única opción aceptable para FinCorp según BSI y RGPD. Las cargas de trabajo y los datos del node-pool siempre permanecen en la región del cliente elegida, sin excepción. Tenga en cuenta también los límites honestos de la sección 6.1: las atestaciones de BSI cubren la capa de infraestructura de IONOS CLOUD, no las cargas de trabajo en el clúster, y los eventos del control plane de Kubernetes no fluyen a través del Logging Service de IONOS CLOUD.

2. Almacenamiento persistente a través del controlador CSI

El aprovisiona volúmenes de Block Storage como Persistent Volumes de Kubernetes a través del controlador CSI de IONOS CLOUD, cuyo aprovisionador es cloud.ionos.com. Usted controla la ubicación y el tipo definiendo un StorageClass. El ejemplo siguiente fija el almacenamiento SSD en una zona de disponibilidad y habilita la expansión en línea:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ionos-enterprise-ssd-zone-1
provisioner: cloud.ionos.com
parameters:
  type: SSD
  fstype: ext4
  availabilityZone: ZONE2
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

WaitForFirstConsumer retrasa la vinculación hasta que un pod se programa, de modo que el volumen se ubica en la misma zona que el nodo que lo consume. Los volúmenes aprovisionados dinámicamente son gestionados por el controlador CSI: con la política de recuperación Retain, un volumen permanece tras la eliminación del PV y aparece como un volumen residual en el VDC, por lo que la política de recuperación es una decisión deliberada del ciclo de vida, no un valor predeterminado que se deba ignorar.

3. Ingress: no existe un equilibrador de carga administrado automático

Este es el límite que más a menudo sorprende a los equipos que provienen de un hiperescalador. Un Service de tipo LoadBalancer no despliega un equilibrador de carga externo auténtico delante del clúster. IONOS CLOUD asigna una IP pública estática y la asigna como IP secundaria a un único nodo de trabajo, que se convierte en el nodo de entrada; si el pod de destino se ejecuta en otro lugar, kube-proxy aplica NAT al tráfico hacia él. De esto se derivan dos consecuencias. El ancho de banda está limitado por el máximo público de ese único nodo, por lo que para escalar más allá de él se reservan varias IPs y se distribuyen entre varios nodos de entrada (equilibrio de carga mediante DNS). Y el NAT reemplaza la IP de origen, por lo que se pierde la dirección del cliente a menos que se configure externalTrafficPolicy: Local.

El patrón de producción consiste, por lo tanto, en exponer un único controlador de entrada dentro del clúster como el Servicio LoadBalancer y permitir que enrute HTTP dentro del clúster, en lugar de exponer cada Servicio de aplicación. Reserve la IP de entrada en IP Management fuera de Kubernetes para que no se libere cuando se elimine el Servicio, y luego fíjela en un nodo de entrada dedicado.

Cuando FinCorp necesita un nivel 7 gestionado auténtico delante del clúster, la respuesta es un Managed Application Load Balancer aprovisionado por separado (Unidad 3.3), no un manifiesto. El ALB requiere una IP pública reservada, termina TLS (su listener acepta exactamente un certificado de hoja, opcionalmente con su cadena de CA en el mismo archivo) y se conecta a los nodos del clúster como objetivos. Nada en un manifiesto de Kubernetes lo aprovisiona o configura; es un recurso distinto que usted construye y apunta a los nodos de entrada.

Guía de implementación de DCD

Construirá un clúster público de Managed Kubernetes con un grupo de nodos de Dedicated Core, obtendrá su kubeconfig, definirá una clase de almacenamiento CSI y lo fronteará con un controlador de entrada expuesto a través de una IP reservada. Requisito previo: el permiso Create Kubernetes Clusters (propietarios de contratos, administradores y usuarios con permisos concedidos) y una IPv4 pública reservada en IP Management para el punto de entrada.

Objetivo de construcción: Construir un clúster público de extremo a extremo.

Pasos (en Data Center Designer):

  1. Vaya a Menú > Containers > Managed Kubernetes y luego seleccione + Create Cluster. Introduzca un nombre de clúster siguiendo las convenciones de nomenclatura de Kubernetes y elija la versión de Kubernetes. Para FinCorp, seleccione un plano de control respaldado por Frankfurt para mantener los datos del plano de control en Alemania.
  2. Abra el nuevo clúster y vaya a la pestaña Node pools in Cluster, luego seleccione Create node pool.
  3. En Pool Settings, introduzca un Pool Name, seleccione el Data Center en el que residen los nodos (créelo primero si es necesario), elija la Node pool version y establezca la Node count.
  4. Opcionalmente, active Autoscale y proporcione un recuento mínimo y máximo de nodos. El mínimo es un nodo cálido; no hay escalado a cero.
  5. En la plantilla de Node, establezca Server type en Dedicated Core (el valor predeterminado) o vCPU, luego elija Cores, RAM y Availability Zone. Recuerde que un núcleo aprovisionado se corresponde con dos CPU de Managed Kubernetes.
  6. Bajo Reserved IPs, agregue la IP pública reservada que respaldará el punto de entrada y adjunte las LAN privadas requeridas. Aprovisione el grupo de nodos y espere a que los nodos alcancen el estado ACTIVE.
  7. Obtenga el acceso: en la pestaña Cluster Settings, descargue kubeconfig.yaml (o .json), o use la CLI: ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Apunte kubectl al archivo.
  8. Aplique la StorageClass CSI de la Sección 2 (provisioner: cloud.ionos.com), luego despliegue un controlador de entrada y exponga solo su Service como tipo LoadBalancer, fijado a su IP reservada. Coloque los Services de la aplicación detrás de ese controlador, no directamente en internet.

Errores comunes:

  • Tratar un Service LoadBalancer como un LB administrado. Es una IP estática de un solo nodo con NAT de kube-proxy, limitada al rendimiento de un solo nodo. Exponga solo el controlador de entrada de esta manera; use un Managed ALB aprovisionado por separado para un nivel 7 real frente al clúster.
  • Olvidar externalTrafficPolicy: Local cuando la aplicación necesita la IP real del cliente. La ruta NAT predeterminada descarta la dirección de origen.
  • Dejar que Kubernetes reserve automáticamente la IP de entrada. Resérvela primero en IP Management para que eliminar el Service no libere la dirección (y no rompa sus registros DNS).
  • Elegir el tipo de grupo de nodos incorrecto. No se puede cambiar entre público y privado después de la creación; un grupo privado no admitiría el Service LoadBalancer en absoluto.
  • Colocar el plano de control en un centro de datos de EE. UU. para una carga de trabajo regulada. Para un clúster público, elija Frankfurt para mantener los datos del plano de control en Alemania.
  • Esperar encontrar registros del clúster y eventos del plano de control en Logging Service. Los eventos del plano de control no fluyen allí; planifique un reenvío separado.

Resumen

Un clúster público de Managed Kubernetes es una construcción breve cuyo peso reside en unas pocas decisiones irreversibles: el tipo de grupo de nodos y el tipo de servidor, la ubicación del plano de control por soberanía, y cómo se materializan realmente el almacenamiento persistente y el ingreso. El almacenamiento es dinámico a través del controlador CSI cloud.ionos.com mediante una StorageClass que usted define; el ingreso no es automático, por lo que debe colocar un controlador de ingreso dentro del clúster en una IP reservada como frontal del clúster, y recurrir a un Managed ALB aprovisionado por separado cuando necesite una capa 7 gestionada de forma verdadera. FinCorp ya tiene su nivel de API público listo para componerse con el nivel de datos privado que se construirá a continuación.

Puntos clave:

  • Un grupo de nodos públicos permite el tipo de Servicio LoadBalancer; los grupos privados no lo permiten, y el tipo es inmutable después de la creación.
  • El controlador CSI de IONOS CLOUD (provisioner: cloud.ionos.com) aprovisiona Block Storage como Volumes persistentes; la StorageClass fija el tipo, la zona, la expansión y el comportamiento de recuperación.
  • Un Servicio LoadBalancer es una IP estática de un solo nodo con NAT de kube-proxy, no un LB externo gestionado; escale a través de múltiples IPs de ingreso y resérvelas fuera de Kubernetes.
  • La IP de origen se pierde sin externalTrafficPolicy: Local; un Managed ALB aprovisionado por separado proporciona una capa 7 real y terminación de TLS frente al clúster.
  • Elija un plano de control en Frankfurt para los clústeres públicos para mantener los datos del plano de control en Alemania; los eventos del plano de control no llegan al Logging Service.

Terminología importante:

  • Controlador CSI: el plugin de Container Storage Interface (cloud.ionos.com) que aprovisiona dinámicamente Block Storage de IONOS CLOUD como Volumes persistentes de Kubernetes.
  • Nodo de ingreso: el único nodo de trabajo que recibe la IP estática de un Servicio LoadBalancer como IP secundaria y reenvía el tráfico a través de kube-proxy.
  • StorageClass: el objeto de Kubernetes que define cómo se aprovisionan los Volumes persistentes (tipo, zona de disponibilidad, sistema de archivos, expansión, modo de vinculación).

Lectura adicional

  • Unidad 6.1: Diseño de la plataforma de Kubernetes (las decisiones de diseño que esta implementación materializa)
  • Unidad 6.3: Aprovisionamiento de un Cluster privado (la variante privada con prioridad en la red)
  • Unidad 3.3: Equilibrio de carga: capa 7 (aplicación) (el front de ALB administrado)