Unidad 6.1: Diseño de la plataforma Kubernetes

Introducción

La decisión que rige el diseño de un Managed Kubernetes no es "qué Kubernetes", sino "dónde IONOS CLOUD deja de gestionar y dónde usted comienza". IONOS CLOUD ejecuta el plano de control por usted y no cobra por él; usted es responsable de la capacidad de los nodos de trabajo, del borde de equilibrado de carga, de la política de red dentro del clúster y de la postura de cumplimiento de todo lo que se ejecuta sobre la plataforma. Delimitar con precisión esa frontera es lo que distingue un diseño que funciona en producción de uno que asume comodidades de un hiperescalador que la plataforma no ofrece.

Esta unidad es exclusivamente de diseño. Establece la arquitectura y las compensaciones; el clúster 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 conocer las fronteras y luego construya sobre ellas.

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

Managed Kubernetes está estructurado como dos capas con propiedad, facturación y SLAs diferentes.

El plano de control (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) es gestionado por completo por IONOS CLOUD y está oculto: sus componentes no son visibles para usted y no pueden modificarse directamente, y el kube-apiserver solo se accede a través de su API REST. El valor de la matriz para el modelo de facturación es claro: el plano de control es gratuito. El calificativo es importante y debe acompañar la afirmación: la capa de servicio es gratuita, pero usted sigue pagando por el cómputo y el almacenamiento de los node pools subyacentes. Una afirmación de que "Managed Kubernetes es gratuito" sin ese calificativo es engañosa.

Los node pools son la capacidad de trabajo. Sus servidores son instancias ordinarias de Compute Engine aprovisionadas 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 pool desde Dedicated Core o vCPU. La asignación de CPU es consistente en ambos: un núcleo aprovisionado equivale a dos CPUs de Managed Kubernetes (dos hilos lógicos por unidad de CPU).

Las dos capas tienen SLAs separados, y este es un punto ciego de diseño frecuente:

El SLA del plano de control está limitado a la API de Kubernetes del plano de control solo, no a sus cargas de trabajo ni a la disponibilidad de los nodos. Los node pools, al estar construidos sobre Compute Engine, heredan el SLA de Compute Engine como un compromiso separado y adicional. Diseñar para disponibilidad significa, por lo tanto, diseñar sus node pools y su carga de trabajo para la resiliencia; el SLA del plano de control gestionado no se extiende a ninguno de los dos.

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

2. Node Pools como capacidad inmutable y con escalado automático

Un Node Pools es la unidad de capacidad y la unidad de ciclo de vida. Dos propiedades determinan su diseño.

Los Nodes son inmutables. Los Nodes nunca se parchean in situ. Cuando un Node Pools se actualiza, ya sea de forma automática durante la ventana de mantenimiento semanal o de forma manual para un cambio de versión, cada Node del pool se reconstruye: un Node antiguo se reemplaza por uno nuevo. De esto se derivan dos hechos de planificación. Primero, una reconstrucción puede añadir un Node activo adicional facturable durante el reemplazo, por lo que la cuota de servidores del contrato debe contar con margen de sobra o la reconstrucción se detendrá. Segundo, todo lo que debe sobrevivir a un Node debe residir fuera del Node: el estado persistente debe ubicarse en volúmenes persistentes de Block Storage a través del aprovisionador CSI (cloud.ionos.com), nunca en el disco local. La ventana de mantenimiento tiene un límite de cuatro horas por ejecución; dimensione sus PodDisruptionBudget y las cantidades de réplicas de modo que un reemplazamiento progresivo no lleve la carga de trabajo por debajo del quórum.

Los Node Pools escalan automáticamente, pero no hay escalado a cero. El autoscaler del clúster aumenta el tamaño de un pool cuando los Pods no pueden programarse por falta de CPU o memoria, y lo reduce cuando los Nodes permanecen subutilizados y sus Pods pueden moverse a otro lugar. No excederá el máximo que usted establezca (ni la cuota del contrato), y no puede reducir un pool a cero. El límite práctico inferior es un Node cálido: un clúster que existe tiene un costo de al menos un Node por cada pool que se mantenga activo. Diseñe la arquitectura en torno a ese límite inferior consolidando cargas de trabajo intermitentes en un pool compartido, en lugar de mantener muchos pools de un solo propósito, cada uno fijado en un solo Node cálido.

Límites de dimensionamiento dentro de los cuales debe diseñar (los máximos recomendados y los máximos duros son distintos y no deben confundirse):

El patrón consiste en un Node Pools por clase de carga de trabajo (por ejemplo, un pool para servicios generales y un pool separado para cargas de trabajo intensivas en memoria o limitadas por Dedicated-Core), cada uno con su propio rango de escalado automático, y situado sobre un límite inferior de un Node.

3. Las cuatro fronteras

Estas son la sustancia de la unidad. Cada una es un lugar donde Managed Kubernetes no se comporta como una oferta gestionada por un hiperescalador, y cada una tiene un patrón nativo para componer en torno a ella.

3.1 Un servicio LoadBalancer es una IP estática de un solo Node, no un balanceador de carga gestionado

Esta es la frontera más probable de causar una interrupción si se malinterpreta. La implementación actual de un servicio de tipo LoadBalancer no despliega un balanceador de carga verdadero frente al clúster. En su lugar, IONOS CLOUD reserva una dirección IP pública estática y la asigna como IP secundaria a un solo Node de trabajo, que luego actúa como el Node de entrada. Si el pod objetivo no está en ejecución en ese Node, kube-proxy aplica NAT al tráfico hacia donde se encuentre el pod.

Siguen directamente tres consecuencias:

• No hay alta disponibilidad por parte del propio servicio. Un solo Node porta la IP. Si falla, ese punto de acceso estará caído hasta que la IP se reasigne.
• La IP de origen se pierde a menos que se configure externalTrafficPolicy: Local, porque kube-proxy aplica NAT al tráfico.
• El ancho de banda está limitado por la interfaz pública de ese único Node, que es de hasta 2 Gbit/s. No se obtiene el ancho de banda agregado del clúster 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 dentro del clúster. Para escalar más allá del límite de un solo Node, se reservan múltiples IPs estáticas y se distribuyen entre múltiples Nodes de entrada (una IP por Node, distribuida por DNS), reservando esas IPs fuera del clúster para que sobrevivan a las reconstrucciones de Node. Tenga en cuenta también que el tipo de servicio LoadBalancer está soportado únicamente en pools de Nodes públicos; los pools de Nodes privados no lo admiten y carecen de IPs de Node estáticas. Cuando se necesita enrutamiento gestionado de nivel 7 genuino con terminación TLS, ese es el Managed Application Load Balancer provisionado por separado del Módulo 3, colocado frente al clúster; no se provisiona automáticamente desde un manifiesto. La Unidad 6.2 cubre la configuración de esa entrada gestionada.

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

Los registros de los pools de Nodes fluyen al IONOS CLOUD Logging Service (se admite la exportación a Object Storage), pero los eventos del plano de control gestionado no. Como el plano de control está oculto y es operado por IONOS CLOUD, los registros de sus componentes están fuera de su plano de telemetría. No encontrará eventos de kube-apiserver ni del programador en su canal de registros.

Diseñe en torno a esto instrumentando lo que sí posee: registros de aplicación y a nivel de Node a través de la pila de registros dentro del clúster hacia el Logging Service o Object Storage, y la visibilidad de auditoría de la API de Kubernetes construida a partir de sus propios recursos. No diseñe un flujo de trabajo de alertas o forense que asuma 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 fijas de observabilidad de la plataforma.

3.3 Los grupos de seguridad no pueden aplicarse a los Nodes de trabajo de Managed Kubernetes

Los cortafuegos a nivel de NIC y los Network Security Groups no pueden aplicarse en absoluto a los Nodes de trabajo de Managed Kubernetes: los Nodes de los pools de Nodes están excluidos explícitamente de la membresía de NSG, y los NSG tampoco se aplican al plano de control gestionado ni a los balanceadores de carga gestionados. Un grupo de seguridad no tiene ningún punto de adjunción en la infraestructura del clúster.

El único mecanismo de segmentación disponible a nivel de pod y espacio de nombres es la política de red de Kubernetes dentro del clúster, aplicada por el CNI Calico fijo; los cortafuegos de NIC y los Network Security Groups no son una opción para el control perimetral a nivel de Node en Managed Kubernetes. El tráfico entre los Nodes y el plano de control está él mismo protegido por TLS mutuo, por lo que la confidencialidad de Node a plano de control la gestiona la plataforma; su trabajo es la política de carga de trabajo este-oeste dentro del clúster.

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 está dentro de la atestación BSI C5: C5 (un Testat de Tipo 1 otorgado el 2023-11-07) cubre Compute Engine, Cloud Cubes y S3 Object Storage, pero no Managed Kubernetes. Declare el alcance con precisión y no generalice nunca a "la plataforma está certificada".

El punto más profundo es la frontera de atribución. Estas credenciales cubren únicamente la capa de infraestructura de IONOS CLOUD: el servicio gestionado, los centros de datos, los controles operativos. No atestan sus cargas de trabajo. Sus imágenes de contenedor, la configuración de RBAC, las políticas de red, el manejo de secretos y los datos de la aplicación siguen siendo su responsabilidad y su evidencia a presentar en cualquier auditoría. IONOS CLOUD cifra los datos de secretos en reposo y protege el canal de Node a plano de control con TLS mutuo, que son controles de infraestructura; la seguridad de lo que se ejecuta en los pods es del cliente. Para una carga de trabajo regulada, el alcance de IT-Grundschutz es el piso de la línea de responsabilidad compartida, no toda la historia de cumplimiento.

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

La ubicación donde se ejecuta el plano de control es una decisión de soberanía, y depende del tipo de clúster. Para un clúster público, el plano de control administrado por IONOS CLOUD se ejecuta en Fráncfort o en uno de los tres centros de datos de Estados Unidos (Lenexa, Newark, Las Vegas). Para un clúster privado, el plano de control puede crearse en cualquier centro de datos, es decir, en la región elegida por el cliente.

La soberanía sigue la ubicación elegida. Si se elige el plano de control alemán (Fráncfort), los datos del plano de control permanecen en Alemania, preservando la soberanía de la UE y de Alemania. Si se elige un plano de control en Estados Unidos, los metadatos del plano de control residen en Estados Unidos, por lo que no se obtiene soberanía alemana para dichos metadatos. En todos los casos, las cargas de trabajo de los grupos de nodos y sus datos permanecen en la región elegida por el cliente, independientemente de la ubicación del plano de control.

Para una carga de trabajo alemana sujeta a regulación, esto es decisivo: un clúster público que se deje con la ubicación predeterminada puede colocar los metadatos del plano de control en un centro de datos de Estados Unidos, lo que conlleva exposición jurisdiccional de Estados Unidos, aunque los datos de los nodos de trabajo nunca salgan de Alemania. La respuesta de diseño es fijar el plano de control en Fráncfort para un clúster público, o utilizar un clúster privado (plano de control en la región alemana elegida) cuando el requisito es que ningún metadato del plano de control salga del país. Esto se 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 ubicación, incluida esta.

Estudio de caso empresarial (FinCorp)

FinCorp, la empresa alemana de servicios financieros sujeta a las obligaciones del RGPD y de la BSI, está implementando su plataforma de contenedores para los nuevos servicios adyacentes a la IA. Los límites descritos anteriormente determinan el diseño.

Dado que el primer clúster da servicio a una API orientada al cliente, se trata de un clúster público. Por lo tanto, los arquitectos fijan su plano de control en Frankfurt en lugar de aceptar la ubicación predeterminada, que podría situar los metadatos en un centro de datos de Estados Unidos. Los grupos de nodos se encuentran en la región alemana, junto con las cargas de trabajo.

Definen dos grupos de nodos: un grupo de servicios generales (vCPU, escalado automático de 1 a 6) y un grupo de núcleos dedicados para un servicio sensible a la latencia (escalado automático de 1 a 4). Ambos cumplen con el mínimo de un nodo cálido, y FinCorp acepta dos nodos siempre activos como el costo de aislar las dos clases de cargas de trabajo. El estado persistente se almacena en volúmenes de Block Storage CSI, y se reserva un margen de cuota para que el nodo adicional facturable de una reconstrucción de mantenimiento nunca cause una interrupción.

En el borde, FinCorp expone únicamente un controlador de entrada y coloca un Managed Application Load Balancer aprovisionado por separado delante para ofrecer la alta disponibilidad y la terminación TLS que una IP de entrada de un solo nodo no puede proporcionar. Dentro del clúster, las políticas de red de Calico segmentan el espacio de nombres orientado al cliente de los servicios internos. Los Network Security Groups a nivel de NIC no pueden aplicarse en absoluto a los nodos de trabajo, ya que los nodos de los grupos de nodos están excluidos de la membresía de NSG. Con fines de auditoría, FinCorp documenta que IT-Grundschutz cubre la infraestructura de Managed Kubernetes, mientras que sus propias imágenes, RBAC y datos de la aplicación siguen siendo evidencia que FinCorp debe presentar. Además, envía los registros de la aplicación y de los nodos a Object Storage, sabiendo que los eventos del plano de control no aparecerán allí.

Resumen de decisiones

Resumen

Managed Kubernetes le ofrece un plano de control gratuito y totalmente administrado bajo su propio SLA de API del 99,95%, y le deja a usted la responsabilidad de los grupos de nodos facturables (con su SLA heredado de Compute Engine), el borde de equilibrado de carga, la política de red dentro del clúster, la observabilidad de lo que ejecuta y el cumplimiento de sus cargas de trabajo. Diseñe los grupos de nodos como capacidad inmutable y de escalado automático con un mínimo de un nodo cálido, y diseñe deliberadamente en torno a las cuatro fronteras, porque cada una es un lugar donde asumir el comportamiento del hiperescalar produce una interrupción, un punto ciego o una auditoría fallida.

Puntos clave:

• El plano de control es gratuito y administrado bajo un SLA exclusivo de API del 99,95%; los grupos de nodos son capacidad de Compute Engine facturable bajo un SLA heredado separado del 99,95%. Mantenga la calificación de "usted paga por la infraestructura" en cualquier afirmación de "gratis".
• Los Node son inmutables y se reconstruyen en cada actualización o ejecución semanal de mantenimiento; mantenga el estado en volúmenes de Block Storage CSI y mantenga margen de cuota de servidor para el nodo de reconstrucción adicional facturable.
• No hay escalado a cero; el mínimo de escalado automático es de un nodo cálido 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 IP estático de un solo nodo (solo grupos públicos, hasta 2 Gbit/s, sin HA, IP de origen perdida sin externalTrafficPolicy: Local); use un controlador de entrada detrás de un ALB administrado aprovisionado por separado para un comportamiento real de borde.
• Los eventos del plano de control nunca llegan al Logging Service, los grupos de seguridad a nivel de NIC no pueden aplicarse a los nodos de trabajo en absoluto (use políticas de red de Calico para la segmentación de cargas de trabajo) y el alcance de IT-Grundschutz cubre la capa de infraestructura, no sus cargas de trabajo. C5 no cubre Managed Kubernetes.
• La ubicación del plano de control depende del tipo de clúster y determina la soberanía: fije Frankfurt (público) o use un clúster privado en la región alemana elegida para mantener los metadatos del plano de control en el país.

Terminología importante:

• Grupo de nodos: Un conjunto de nodos de trabajo configurados de manera idéntica y aprovisionados como instancias de Compute Engine en su VDC; la unidad de capacidad, tipo de servidor y escalado automático, e inmutable en el sentido de que los Node se reemplazan en lugar de recibir parches.
• Node de entrada: El único nodo de trabajo al que se adjunta el IP estático de un servicio LoadBalancer como IP secundaria; transporta el tráfico externo de ese servicio y kube-proxy realiza NAT hacia el pod de destino.

Lectura adicional

• Unidad 6.2: Aprovisionamiento de un Cluster público (la construcción del diseño público aquí)
• Unidad 6.3: Aprovisionamiento de un Cluster privado (plano de control privado, red primero)
• 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)