10 min de lectura

Objetivos de aprendizaje

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

  • Provisionar un Managed Kubernetes Cluster público y un grupo de Node de extremo a extremo en el Data Center Designer, eligiendo el tipo de servidor, la versión y la clase de almacenamiento persistente de manera deliberada.
  • Recuperar y utilizar el kubeconfig de Cluster, y definir una clase de almacenamiento IONOS CSI para volúmenes persistentes provisionados dinámicamente.
  • Diseñar el ingreso correctamente dado que los manifiestos no provisionan automáticamente un Load Balancer gestionado, componiendo un Load Balancer provisionado por separado con un controlador de ingreso en Cluster.
  • Evitar los errores comunes de provisionamiento alrededor del tipo de grupo de Node inmutable, las direcciones IP reservadas, la pérdida de origen de IP y la colocación del plano de control.

Unidad 6.2: Provisionamiento de un Cluster Público

Introducción

La Unidad 6.1 estableció las decisiones de diseño: un plano de control gestionado gratuito sobre el Node Pools de pago, sin escalabilidad cero, grupos de seguridad vinculados a las NIC de los trabajadores en lugar del Cluster, y la dura verdad de que un servicio LoadBalancer no es un Load Balancer externo gestionado. Esta unidad implementa un Cluster público en el Data Center Designer. La construcción es corta; las decisiones consecuentes son el tipo y la versión del servidor del Node Pool (que fijan cosas que no se pueden cambiar más tarde), cómo se provisiona el almacenamiento persistente a través del controlador CSI, y cómo el tráfico llega realmente a su Pods. FinCorp necesita un Cluster público para alojar el nivel API sin estado que da servicio a su nueva capacidad de inteligencia artificial, así que construimos exactamente eso.

1. Las decisiones para solucionar los problemas de creación

Dos elecciones realizadas en el asistente de creación son efectivamente permanentes. El tipo de grupo de Node no se puede cambiar entre público y privado después de la creación, y un grupo de Node público es lo que permite un tipo de servicio LoadBalancer en absoluto (los grupos privados no lo admiten). El nivel de API de FinCorp es de frente a internet, por lo que un grupo público es correcto aquí; el nivel de datos regulados se mantiene en el Cluster privado construido en la Unidad 6.3.

El tipo de servidor se elige por grupo de Node desde Dedicated Core o vCPU. El mapeo de recursos de CPU es fijo: un núcleo provisionado equivale a dos CPUs de Managed Kubernetes. El límite recomendado es de 20 nodos por grupo de Node (máximo duro 100), y un grupo de Node puede tener hasta 110 Pods y hasta 20 volúmenes adjuntos. FinCorp utiliza Dedicated Core para el nivel de API para obtener un núcleo exclusivo y una programación predecible bajo carga.

La colocación del plano de control decide la soberanía. Para un Cluster público, el plano de control administrado por IONOS se ejecuta en Frankfurt o en uno de los tres centros de datos de EE. UU. (Lenexa, Newark, Las Vegas); elegir Frankfurt mantiene los datos del plano de control en Alemania, la única opción aceptable para FinCorp bajo BSI y GDPR. Las cargas de trabajo y los datos del grupo de Node siempre permanecen en la región del cliente elegida, sin embargo. Tenga en cuenta también los límites honestos de 6.1: las acreditaciones de BSI cubren la capa de infraestructura de IONOS, no las cargas de trabajo en el Cluster, y los eventos del plano de control de Kubernetes no fluyen a través del Logging Service de IONOS.

2. Almacenamiento persistente a través del controlador CSI

El Cluster proporciona volúmenes Block Storage como Volúmenes Persistentes Kubernetes a través del controlador CSI de IONOS, cuyo proveedor es cloud.ionos.com. Usted controla la colocación y el tipo definiendo una StorageClass. El ejemplo a continuación fija el almacenamiento SSD a 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 unión hasta que un pod se programa, por lo que el Volume aterriza en la misma zona que el Node que lo consume. Los volúmenes provisionados dinámicamente son administrados por el controlador CSI: con la directiva de reclamación Retain, un Volume sobrevive a la eliminación de PV y aparece como un Volume sobrante en el VDC, por lo que la directiva de reclamación es una decisión de ciclo de vida deliberada, no un valor predeterminado para ignorar.

3. Ingress: no hay un Load Balancer administrado automático

Este es el límite que más a menudo sorprende a los equipos que llegan desde un hyperscaler. Un Service de tipo LoadBalancer no despliega un verdadero Load Balancer externo frente al Cluster. IONOS asigna una dirección pública estática IP y la asigna como una dirección secundaria IP a un solo trabajador Node, que se convierte en el Node de ingreso; si el pod de destino se ejecuta en otro lugar, kube-proxy NATs el tráfico hacia él. Dos consecuencias siguen. El rendimiento está limitado por el techo público de ese Node, por lo que para escalar más allá de él, se reservan varias direcciones IP y se distribuyen en varios nodos de ingreso (DNS de equilibrio de carga). Y el NAT reemplaza la dirección de origen IP, por lo que la dirección del cliente se pierde a menos que se establezca externalTrafficPolicy: Local.

El patrón de producción es, por lo tanto, exponer un solo controlador de ingreso in-Cluster como el Servicio LoadBalancer y dejar que enrute HTTP dentro del Cluster, en lugar de exponer cada Servicio de aplicación. Reservar la dirección de ingreso IP en la administración de IP fuera de Kubernetes para que no se libere cuando se elimina el Servicio, y luego fijarla a un Node de ingreso dedicado.

Donde FinCorp necesita un verdadero Managed Application Load Balancer administrado de capa 7 frente al Cluster, la respuesta es un Managed Application Load Balancer provisionado por separado (Unidad 3.3), no un manifiesto. El ALB requiere una dirección pública reservada IP, termina TLS (su oyente acepta exactamente un certificado de hoja, opcionalmente con su cadena de CA en el mismo archivo), y está conectado a los nodos Cluster como objetivos. Nada en un manifiesto Kubernetes provisiona o configura; es un recurso distinto que se construye y apunta a los nodos de ingreso.

DCD Implementación paso a paso

Construirá un Managed Kubernetes Cluster público con un grupo de Dedicated Core Node, recuperará su kubeconfig, definirá una clase de almacenamiento CSI y lo expondrá a través de un controlador de ingreso con una IP reservada. Requisito previo: el permiso Create Kubernetes Clusters (propietarios de contratos, administradores y usuarios autorizados), y una IPv4 pública reservada en IP Management para el punto de entrada de ingreso.

Objetivo de construcción: Construir un Cluster de extremo a extremo.

Pasos (en el Data Center Designer):

  1. Vaya a Menú > Contenedores > Managed Kubernetes, luego seleccione + Crear Cluster. Ingresa un nombre de Cluster siguiendo las convenciones de nomenclatura de Kubernetes y elija la versión de Kubernetes. Para FinCorp, seleccione un controlador de Frankfurt para mantener los datos del controlador en Alemania.
  2. Abra el nuevo Cluster y vaya a la pestaña Node Pools en Cluster, luego seleccione Crear grupo de Node.
  3. En la configuración del grupo, ingrese un nombre de grupo, seleccione el Centro de datos donde viven los nodos (cree uno primero si es necesario), elija la versión del grupo de Node y establezca el recuento de Node.
  4. Opcionalmente, active Autoscale y proporcione un recuento mínimo y máximo de Node. El piso es un Node cálido; no hay escalado a cero.
  5. En la plantilla de Node, establezca Tipo de servidor en Dedicated Core (el predeterminado) o vCPU, luego elija Núcleos, RAM y Zona de disponibilidad. Recuerde que un núcleo aprovisionado se asigna a dos CPUs de Managed Kubernetes.
  6. En Direcciones IP reservadas, agregue la IP pública reservada que respaldará el punto de entrada de ingreso y adjunte cualquier LAN privada requerida. Aprovisione el grupo de Node y espere a que los nodos alcancen el estado ACTIVO.
  7. Recupere el acceso: en la pestaña Configuración de Cluster, descargue kubeconfig.yaml (o .json), o use la CLI: ionosctl k8s kubeconfig get --cluster-id CLUSTERID. Apunte kubectl al archivo.
  8. Aplicar la clase de almacenamiento CSI de la Sección 2 (provisioner: cloud.ionos.com), luego implemente un controlador de ingreso y exponga solo su Servicio como tipo LoadBalancer, fijado a su IP reservada. Coloque los Servicios de aplicación detrás de ese controlador, no directamente en Internet.

Errores comunes:

  • Tratar un Servicio LoadBalancer como un LB administrado. Es una dirección IP estática de un solo Node con kube-proxy NAT, limitada a la capacidad de un Node. Exponga solo el controlador de ingreso de esta manera; use un ALB administrado separadamente aprovisionado para la capa 7 real frente al Cluster.
  • Olvidar externalTrafficPolicy: Local cuando la aplicación necesita la dirección IP del cliente real. El camino predeterminado de NAT descarta la dirección de origen.
  • Dejar que Kubernetes reserve automáticamente la dirección IP de ingreso. Resérvela en IP Management primero para que la eliminación del Servicio no libere la dirección (y rompa sus registros DNS).
  • Elegir el tipo incorrecto de grupo de Node. Público y privado no se pueden cambiar después de la creación; un grupo privado no admitiría el Servicio LoadBalancer en absoluto.
  • Colocar el controlador en un centro de datos de EE. UU. para una Workload regulada. Para un Cluster público, elija Frankfurt para mantener los datos del controlador en Alemania.
  • Esperar que los registros de Cluster y los eventos del controlador estén en el Logging Service. Los eventos del controlador no fluyen allí; planifique un reenvío separado.

Resumen

Un Managed Kubernetes Cluster público es una construcción corta cuyo peso se basa en algunas elecciones irreversibles: tipo de grupo Node y tipo de servidor, colocación del plano de control para la soberanía, y cómo se realizan el almacenamiento persistente y el ingreso. El almacenamiento es dinámico a través del controlador CSI cloud.ionos.com a través de una StorageClass que usted define; el ingreso no es automático, por lo que usted coloca el Cluster con un controlador de ingreso en un IP reservado y alcanza un Managed ALB separadamente provisionado cuando necesita un verdadero gestor de capa 7. FinCorp ahora tiene su nivel público API listo para componer con el nivel de datos privado construido a continuación.

Puntos clave:

  • Un grupo Node público permite el tipo de servicio LoadBalancer; los grupos privados no, y el tipo es inmutable después de la creación.
  • El controlador CSI de IONOS (provisioner: cloud.ionos.com) proporciona Block Storage como volúmenes persistentes; la StorageClass fija el tipo, zona, expansión y comportamiento de reclamación.
  • Un servicio LoadBalancer es un IP estático de un solo Node con kube-proxy NAT, no un gestor de equilibrio de carga externo; escala a través de múltiples direcciones IP de ingreso y réservalas fuera de Kubernetes.
  • La fuente IP se pierde sin externalTrafficPolicy: Local; un Managed ALB separadamente provisionado proporciona una verdadera capa 7 y terminación TLS frente al Cluster.
  • Elija un plano de control de Frankfurt para clusters públicos para mantener los datos del plano de control en Alemania; los eventos del plano de control no alcanzan el Logging Service.

Terminología importante:

  • Controlador CSI: el plugin de interfaz de almacenamiento de contenedores (cloud.ionos.com) que proporciona dinámicamente IONOS Block Storage como volúmenes persistentes de Kubernetes.
  • Ingreso Node: el trabajador Node único que recibe una dirección IP estática de un servicio LoadBalancer como una dirección IP secundaria y reenvía el tráfico a través de kube-proxy.
  • StorageClass: el objeto Kubernetes que define cómo se provisionan los volúmenes persistentes (tipo, zona de disponibilidad, sistema de archivos, expansión, modo de enlace).

Lectura adicional

  • Unidad 6.1: Kubernetes Diseño de plataforma (las decisiones de diseño que se realizan en esta construcción)
  • 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-end del Managed ALB)