Unidad 6.1: Kubernetes Diseño de plataforma

Introducción

La decisión que gobierna un Managed Kubernetes diseño no es "¿cuál Kubernetes" sino "¿dónde deja IONOS de gestionar y dónde usted comienza". IONOS ejecuta el plano de control para usted y no le cobra por ello; usted es el propietario de la capacidad de los trabajadores, el borde de equilibrio de carga, la política de red en Cluster y la postura de cumplimiento de todo lo que se ejecuta en la parte superior. Tratar esa línea con precisión es lo que separa un diseño que se comporta en producción de uno que asume comodidades de hyperscaler que la plataforma no proporciona.

Esta unidad es solo de diseño. Establece la arquitectura y las compensaciones; el Cluster público se construye en el Data Center Designer en la Unidad 6.2 y la variante privada en la Unidad 6.3. Lea esta unidad para los límites, luego construya contra ellos.

1. El límite administrado: plano de control gratuito, Node Pools de pago

Managed Kubernetes está estructurado en dos capas con diferentes propietarios, diferentes facturaciones y diferentes Acuerdos de Nivel de Servicio.

El plano de control (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) está completamente administrado por IONOS y está oculto: sus componentes no son visibles para usted y no pueden ser modificados directamente, y el kube-apiserver solo se puede acceder a través de su REST API. El valor de la matriz para el modelo de facturación es plano: el plano de control es gratuito. El calificador es importante y debe viajar con la afirmación: la capa de servicio es gratuita, pero aún paga por la capacidad de procesamiento y almacenamiento subyacente del Node Pool. Una afirmación de que "Managed Kubernetes es gratuito" sin ese calificador es engañosa.

Los Node Pools son la capacidad de los trabajadores. Sus servidores son instancias ordinarias de Compute Engine provisionadas en su Centro de Datos Virtual; dentro de un Node Pool, todos los servidores son idénticos en configuración. Usted elige el tipo de servidor por Node Pool entre Núcleo dedicado o vCPU. El mapeo de CPU es coherente en ambos: un núcleo provisionado equivale a dos CPUs de Managed Kubernetes (dos hilos lógicos por unidad de CPU).

Las dos capas llevan Acuerdos de Nivel de Servicio separados, y esto es un punto ciego frecuente en el diseño:

El Acuerdo de Nivel de Servicio del plano de control se limita a los Kubernetes API del plano de control solo, no a sus cargas de trabajo y no a la disponibilidad de Node. Los Node Pools, al estar construidos sobre Compute Engine, heredan el Acuerdo de Nivel de Servicio de Compute Engine como un compromiso adicional y separado. Por lo tanto, diseñar para la disponibilidad significa diseñar sus Node Pools y su Workload para la resistencia; el Acuerdo de Nivel de Servicio del plano de control administrado no se extiende a ninguno de los dos.

Operativamente, IONOS mantiene el plano de control actualizado: las versiones de Kubernetes admitidas son 1.34, 1.33, 1.32 y 1.31, con un máximo de desviación de versión menor de uno entre el plano de control y los Node Pools. El CNI es Calico, fijo, sin opción para elegir un CNI diferente, y es el sustrato para las políticas de red discutidas en la Sección 4.

2. Node Pools como capacidad autoscaling inmutable

Un grupo de Node es la unidad de capacidad y la unidad de ciclo de vida. Dos propiedades impulsan el diseño.

Los nodos son inmutables. Los nodos nunca se parchean en su lugar. Cuando un grupo de Node se actualiza, ya sea automáticamente durante la ventana de mantenimiento semanal o desencadenada manualmente para un cambio de versión, cada Node en el grupo se reconstruye: un Node antiguo es reemplazado por uno nuevo. Dos hechos de planificación siguen. Primero, una reconstrucción puede agregar un Node activo facturable extra durante el reemplazo, por lo que el límite de cuota de servidores del contrato debe tener margen de maniobra o la reconstrucción se detendrá. Segundo, cualquier cosa que deba sobrevivir a un Node debe vivir fuera del Node: el estado persistente pertenece a volúmenes persistentes de Block Storage a través del proveedor CSI (cloud.ionos.com), nunca en disco local. La ventana de mantenimiento está limitada a cuatro horas por ejecución; dimensione su PodDisruptionBudget y los recuentos de réplicas para que un reemplazo por rodillos nunca haga que el Workload caiga por debajo del quórum.

Node Pools se escalan automáticamente, pero no hay escalado a cero. El escalador de Cluster aumenta un grupo cuando no se puede programar Pods debido a la falta de CPU o memoria, y lo reduce cuando los nodos se mantienen subutilizados y sus Pods pueden moverse a otro lugar. No excederá el máximo que establezca (ni la cuota del contrato), y no puede reducir un grupo a cero. El piso práctico es un Node caliente: un Cluster que existe cuesta al menos un Node por grupo que mantenga vivo. Diseñe el costo alrededor de ese piso consolidando cargas de trabajo intermitentes en un grupo compartido en lugar de mantener muchos grupos de un solo propósito cada uno fijado en un Node caliente.

Límites de tamaño para diseñar dentro (los techos recomendados y los techos duros son distintos y no deben confundirse):

El patrón es un grupo de Node por clase de Workload (por ejemplo, un grupo para servicios generales y un grupo separado para cargas de trabajo intensivas en memoria o vinculadas a Dedicated-Core), cada uno con su propia banda de escalado automático, sentado en un piso de un Node.

3. Los cuatro límites

Estos son el contenido de la unidad. Cada uno es un lugar donde Managed Kubernetes no se comporta como una oferta gestionada por un hyperscaler, y cada uno tiene un patrón nativo para componer alrededor de él.

3.1 Un servicio LoadBalancer es un Node estático único IP, no un Load Balancer gestionado

Este es el límite que más probablemente causará una interrupción si no se entiende. La implementación actual de un servicio de tipo LoadBalancer no despliega un verdadero Load Balancer frente al Cluster. En su lugar, IONOS reserva una dirección IP pública estática y la asigna como dirección IP secundaria a un único Node de trabajador, que luego actúa como el Node de entrada. Si el pod de destino no se ejecuta en ese Node, kube-proxy NATs el tráfico a dondequiera que viva el pod.

Tres consecuencias siguen directamente:

• No hay alta disponibilidad desde el servicio en sí. Un Node lleva la IP. Si falla, ese punto de conexión está abajo hasta que la IP se reasigna.
• La dirección IP de origen se pierde a menos que establezca externalTrafficPolicy: Local, porque kube-proxy NATs el tráfico.
• El rendimiento está limitado por la interfaz pública de ese único Node, que es de hasta 2 Gbit/s. No obtiene un ancho de banda agregado Cluster en la IP del servicio.

El patrón nativo es exponer solo el controlador de entrada como un servicio LoadBalancer y enrutar todo lo demás a través de la entrada en-Cluster. Para escalar más allá del techo de un Node, se reservan varias direcciones IP estáticas y se distribuyen en varios nodos de entrada (una IP por Node, distribuida por DNS), reservando esas direcciones IP fuera del Cluster para que sobrevivan a las reconstrucciones de Node. Tenga en cuenta también que el tipo de servicio LoadBalancer es compatible solo con Node Pools públicos; los Node Pools privados no lo admiten y carecen de direcciones IP estáticas Node. Donde necesite enrutamiento de capa 7 gestionado con terminación TLS, ese es el Managed Application Load Balancer separadamente aprovisionado de la Unidad 3, colocado frente al Cluster; no se aprovisiona automáticamente a partir de un manifiesto. La Unidad 6.2 cubre el cableado de ese ingreso gestionado.

3.2 Los eventos del plano de control no llegan al Logging Service

Los registros del grupo de Node fluyen hacia el Logging Service de IONOS (se admite la exportación a Object Storage), pero los eventos del plano de control gestionado no. Debido a que el plano de control está oculto y operado por IONOS, sus registros de componentes están fuera de su plano de telemetría. No encontrará eventos de kube-apiserver o programador en su tubería de registro.

Diseñe alrededor de esto instrumentando lo que usted posee: registros de aplicación y de nivel Node a través de la pila de registro en-Cluster al Logging Service o Object Storage, y visibilidad de auditoría Kubernetes API construida a partir de sus propios recursos. No diseñe un flujo de trabajo de alertas o forenses que suponga que los registros de eventos del plano de control están disponibles; no lo están, y la Unidad 7.2 trata esto como una de las brechas de observabilidad fijas de la plataforma.

3.3 Los grupos de seguridad no se pueden aplicar a Managed Kubernetes Worker Nodes

Los cortafuegos de nivel NIC y Network Security Groups no se pueden aplicar a Managed Kubernetes Worker Nodes en absoluto: los nodos del grupo de Node se excluyen explícitamente de la membresía de NSG, y los NSG no se aplican al plano de control gestionado ni a los equilibradores de carga gestionados. Un grupo de seguridad no tiene un punto de sujeción en la infraestructura de Cluster en absoluto.

El único mecanismo de segmentación disponible en el nivel de pod y espacio de nombres es las políticas de red en-Cluster Kubernetes, impuestas por el Calico CNI fijo; los cortafuegos de NIC y Network Security Groups no son una opción para el control de perímetro de nivel Node en Managed Kubernetes. El tráfico entre nodos y el plano de control está asegurado por TLS mutuos, por lo que la confidencialidad de Node a plano de control se maneja por la plataforma; su trabajo es la política de Workload este-oeste dentro de la Cluster.

3.4 La atribución de cumplimiento cubre la infraestructura, no las cargas de trabajo

Managed Kubernetes se encuentra dentro del certificado ISO 27001 basado en IT-Grundschutz (otorgado por el BSI el 2022-09-14, centros de datos alemanes). No se encuentra dentro de la acreditación C5 del BSI: C5 (un Testat de Tipo 1 otorgado el 2023-11-07) cubre Compute Engine, Cloud Cubes y S3 Object Storage, pero no Managed Kubernetes. Establezca el alcance con precisión y nunca generalice a "la plataforma está certificada".

El punto más profundo es el límite de atribución. Estas credenciales cubren solo la capa de infraestructura de IONOS: el servicio gestionado, los centros de datos, los controles operativos. No atestiguan sus cargas de trabajo. Sus imágenes de contenedor, configuración de RBAC, políticas de red, manejo de secretos y datos de aplicación siguen siendo su responsabilidad y su evidencia para producir en cualquier auditoría. IONOS cifra los datos secretos en REST y asegura el canal de Node a plano de control con TLS mutuos, que son controles de infraestructura; la seguridad de lo que se ejecuta en la Pods es del cliente. Para una Workload regulada, el alcance de IT-Grundschutz es el piso de la línea de responsabilidad compartida, no toda la historia de cumplimiento.

4. Colocación del plano de control y soberanía

Donde se ejecuta el plano de control es una decisión de soberanía, y depende del tipo de Cluster. 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). Para un Cluster privado, el plano de control se puede crear en cualquier centro de datos, es decir, en la región elegida por el cliente.

La soberanía sigue la ubicación elegida. Elija el plano de control alemán (Frankfurt) y los datos del plano de control se mantienen en Alemania, preservando la soberanía de la UE y Alemania. Elija un plano de control de EE. UU. y los metadatos del plano de control residen en EE. UU., por lo que no se obtiene la soberanía alemana para esos metadatos. En todos los casos, las cargas de trabajo del Node Pool y sus datos permanecen en la región del cliente elegida, independientemente de dónde se encuentre el plano de control.

Para un Workload alemán regulado, esto es decisivo: un Cluster público que se deja con la colocación predeterminada puede poner los metadatos del plano de control en un centro de datos de EE. UU., lo que conlleva una exposición jurisdiccional de EE. UU. incluso aunque los datos de los trabajadores nunca abandonan Alemania. La respuesta de diseño es fijar el plano de control en Frankfurt para un Cluster público, o utilizar un Cluster privado (plano de control en la región alemana elegida) cuando el requisito es que no salga ningún metadato del plano de control del país. Esto conecta directamente con la base de la soberanía en la Unidad 1.4: la soberanía es una propiedad de dónde se opera los datos, aplicada como un filtro sobre cada decisión de colocación, incluyendo esta.

Estudio de caso empresarial (FinCorp)

FinCorp, la empresa de servicios financieros alemana bajo las obligaciones de GDPR y BSI, está implementando su plataforma de contenedores para los nuevos servicios relacionados con la inteligencia artificial. Los límites anteriores dan forma al diseño.

Dado que el primer Cluster se enfrenta a un servicio API orientado al cliente, es un Cluster público, por lo que los arquitectos fijan su plano de control en Fráncfort en lugar de aceptar la colocación predeterminada que podría dejar los metadatos en un centro de datos de EE. UU.; los Node Pools se encuentran en la región alemana con las cargas de trabajo.

Definen dos Node Pools: un pool de servicios generales (vCPU, escalado automático de 1 a 6) y un pool de núcleo dedicado para un servicio sensible a la latencia (escalado automático de 1 a 4). Ambos honran el piso de un Node cálido, y FinCorp acepta dos nodos siempre activos como el precio de aislar las dos clases de Workload. El estado persistente se almacena en volúmenes de Block Storage de CSI, y se reserva espacio de cuota para que una reconstrucción de mantenimiento con cargo adicional de Node nunca se detenga.

En el borde, FinCorp expone solo un controlador de ingreso y coloca un Managed Application Load Balancer separadamente aprovisionado en el frente para la terminación de alta disponibilidad y TLS, ya que un solo Node de ingreso IP no puede ofrecer. Dentro del Cluster, las políticas de red de Calico segmentan el espacio de nombres orientado al cliente de los servicios internos; la autenticación de nivel de NIC Network Security Groups no se puede aplicar a los Worker Nodes en absoluto, ya que los nodos del Node Pool están excluidos de la membresía de NSG. Para la auditoría, FinCorp registra que IT-Grundschutz cubre la infraestructura de Managed Kubernetes, mientras que sus propias imágenes, RBAC y datos de aplicación siguen siendo la evidencia de FinCorp para producir, y envía registros de aplicación y Node a Object Storage, sabiendo que los eventos del plano de control no aparecerán allí.

Resumen de la decisión

Resumen

Managed Kubernetes le ofrece un plano de control completamente administrado de forma gratuita bajo su propia SLA del 99,95% de API y le deja como propietario de los componentes facturables Node Pools (con su SLA heredado Compute Engine), el borde de equilibrio de carga, la política de red en Cluster, la observabilidad de lo que ejecuta y el cumplimiento de sus cargas de trabajo. Diseñe los Node Pools como capacidad autoscaling inmutable con un piso de un cálido Node y arquitectúrelo deliberadamente alrededor de los cuatro límites, porque cada uno es un lugar donde asumir un comportamiento de hyperscaler produce una interrupción, un punto ciego o una auditoría fallida.

Puntos clave:

• El plano de control es gratuito y se administra bajo una SLA del 99,95% solo de API; los Node Pools son capacidad facturable Compute Engine bajo una SLA heredada separada del 99,95%. Mantenga el calificador "usted paga por la infraestructura" en cualquier reclamo de "gratuito".
• Los nodos son inmutables y se reconstruyen en cada actualización o ejecución de mantenimiento semanal; mantenga el estado en volúmenes CSI Block Storage y mantenga la cuota de servidor para el espacio de cabeza adicional para la reconstrucción facturable Node.
• No hay escalado a cero; el piso de escalado automático es un cálido Node por grupo, por lo que consolide las cargas de trabajo intermitentes en lugar de ejecutar muchos grupos de un solo propósito.
• Un servicio LoadBalancer es un estático IP de un solo Node (solo pools públicos, hasta 2 Gbit/s, sin alta disponibilidad, la fuente IP se pierde sin externalTrafficPolicy: Local); use un controlador de entrada detrás de un ALB administrado provisionado por separado para un comportamiento de borde real.
• Los eventos del plano de control nunca alcanzan el Logging Service, los grupos de seguridad de nivel NIC no se pueden aplicar a los Worker Nodes en absoluto (use las políticas de red de Calico para la segmentación Workload), y el alcance de IT-Grundschutz cubre la capa de infraestructura, no sus cargas de trabajo. C5 no cubre Managed Kubernetes.
• La colocación del plano de control es dependiente del tipo Cluster y decide la soberanía: fije Frankfurt (público) o use una Cluster privada en la región alemana elegida para mantener los metadatos del plano de control en el país.

Terminología importante:

• Grupo Node: Un conjunto de Worker Nodes configurados de forma idéntica provisionados como instancias Compute Engine en su VDC; la unidad de capacidad, tipo de servidor y escalado automático, e inmutable en el sentido de que los nodos se reemplazan en lugar de parchearse.
• Ingreso Node: El único trabajador Node al que se adjunta un servicio LoadBalancer estático IP como una IP secundaria; lleva el tráfico externo de ese servicio y kube-proxy NATs al pod objetivo.

Lectura adicional

• Unidad 6.2: Aprovisionamiento de un Cluster Público (la creación del diseño público aquí)
• Unidad 6.3: Aprovisionamiento de un Cluster Privado (plano de control privado, enfoque en redes)
• Unidad 1.4: Soberanía y Cumplimiento como Entradas de Diseño
• Unidad 7.2: Observabilidad y Operaciones (la brecha de registro del plano de control en contexto)