Selección de ubicación de recursos en Azure Operador Nexus Kubernetes
Las instancias de Operator Nexus se implementan en las instalaciones del cliente. Cada instancia consta de uno o más bastidores de servidores sin sistema operativo.
Cuando un usuario crea un Clúster de Nexus Kubernetes (NKS), especifica un recuento y una referencia de almacén (SKU) para las máquinas virtuales (VM) que componen el Plano de control de Kubernetes y uno o más Grupos de agentes. Los Grupos de agentes son el conjunto de Nodos de trabajo en los que se ejecutan las funciones de red en contenedor de un cliente.
La plataforma Nexus es responsable de decidir el servidor sin sistema operativo en el que se inicia cada máquina virtual de NKS.
Cómo programa la plataforma Nexus una máquina virtual de clúster de Nexus Kubernetes
Nexus identifica primero el conjunto de posibles servidores sin sistema operativo que cumplen todos los requisitos de recursos de la SKU de máquina virtual de NKS. Por ejemplo, si el usuario especificó una SKU de máquina virtual NC_G48_224_v1 para su grupo de agentes, Nexus recopila los servidores sin sistema operativo que tienen capacidad disponible para 48 vCPU, 224 Gi de RAM, etc.
Nexus examina después el campo AvailabilityZones del Grupo de agentes o Plano de control que se está programando. Si este campo no está vacío, Nexus filtra la lista de posibles servidores sin sistema operativo a solo los servidores de las zonas de disponibilidad (bastidores) especificadas. Este comportamiento es una restricción de programación estricta. Si no hay servidores sin sistema operativo en la lista filtrada, Nexus no programa la máquina virtual de NKS y el clúster no se aprovisiona.
Una vez que Nexus identifica una lista de posibles servidores sin sistema operativo en los que colocar la máquina virtual de NKS, Nexus elige después uno de los servidores sin sistema operativo tras aplicar las siguientes reglas de clasificación:
Es preferible disponer de servidores sin sistema operativo en zonas de disponibilidad (bastidores) que no tengan máquinas virtuales de NKS de este clúster de NKS. En otras palabras, distribuya las máquinas virtuales de NKS de un clúster de NKS entre las zonas de disponibilidad.
Es preferible disponer de servidores sin sistema operativo dentro de una única zona de disponibilidad (bastidor) que no tenga otras máquinas virtuales de NKS del mismo clúster de NKS. En otras palabras, distribuya las máquinas virtuales de NKS para un clúster de NKS entre servidores sin sistema operativo dentro de una zona de disponibilidad.
Si la SKU de la máquina virtual de NKS es
NC_G48_224_v1oNC_P46_224_v1, es preferible usar servidores sin sistema operativo que ya alberguen máquinas virtuales de NKS deNC_G48_224_v1oNC_P46_224_v1de otros clústeres de NKS. En otras palabras, agrupe las máquinas virtuales extragrandes de diferentes clústeres de NKS en los mismos servidores sin sistema operativo. Esta regla "empaqueta" las máquinas virtuales extragrandes para reducir la fragmentación de los recursos de proceso disponibles.
Escenarios de selección de ubicación de ejemplo
Las secciones siguientes destacan el comportamiento que deben esperar los usuarios de Nexus al crear clústeres de NKS en un entorno de Operator Nexus.
Sugerencia: puede ver en qué servidor sin sistema operativo se programaron sus máquinas virtuales de NKS examinando la propiedad
nodes.bareMetalMachineIddel recurso NKS KubernetesCluster o consultando la columna "Host" en la visualización de nodos de clúster de Kubernetes de Azure Portal.
El entorno de Operator Nexus de ejemplo tiene estas especificaciones:
- Ocho bastidores de 16 servidores sin sistema operativo
- Cada servidor sin sistema operativo contiene dos celdas de Acceso a memoria no uniforme (NUMA)
- Cada celda NUMA proporciona 48 CPU y 224 Gi de RAM
Entorno vacío
Dado un entorno de Operator Nexus vacío con la capacidad dada, creamos tres clústeres de Nexus Kubernetes de distinto tamaño.
Los clústeres de NKS tienen estas especificaciones y suponemos, a efectos de este ejercicio, que el usuario crea los tres clústeres en el siguiente orden:
Clúster A
- Plano de control,
NC_G12_56_v1SKU, tres unidades - Grupo de agentes n.º 1,
NC_P46_224_v1SKU, 24 unidades - Grupo de agentes n.º 2,
NC_G6_28_v1SKU, seis unidades
Clúster B
- Plano de control,
NC_G24_112_v1SKU, cinco unidades - Grupo de agentes n.º 1,
NC_P46_224_v1SKU, 48 unidades - Grupo de agentes n.º 2,
NC_P22_112_v1SKU, 24 unidades
Clúster C
- Plano de control,
NC_G12_56_v1SKU, tres unidades - Grupo de agentes n.º 1,
NC_P46_224_v1SKU, 12 unidades,AvailabilityZones = [1,4]
Esta es una tabla que resume lo que el usuario debería ver después de iniciar los clústeres A, B y C en un entorno de Operator Nexus vacío.
| Clúster | grupo | SKU | Recuento total | Número de bastidores previsto | Número real de bastidores | Número previsto de máquinas virtuales por bastidor | Número real de máquinas virtuales por bastidor |
|---|---|---|---|---|---|---|---|
| A | Plano de control | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | Grupo de agentes n.º 1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | Grupo de agentes n.º 2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | Plano de control | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | Grupo de agentes n.º 1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | Grupo de agentes n.º 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | Plano de control | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | Grupo de agentes n.º 1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Hay ocho bastidores, por lo que las máquinas virtuales de cada grupo se reparten en hasta ocho bastidores. Los grupos con más de ocho máquinas virtuales requieren varias máquinas virtuales por bastidor repartidas en diferentes servidores sin sistema operativo.
El Grupo de agentes del clúster C n.º 1 tiene 12 máquinas virtuales restringidas a las zonas de disponibilidad [1, 4], por lo que tiene 12 máquinas virtuales en 12 servidores sin sistema operativo, seis en cada uno de los bastidores 1 y 4.
Las máquinas virtuales extragrandes (la SKU NC_P46_224_v1) de diferentes clústeres se colocan en los mismos servidores sin sistema operativo (consulte la regla n.º 3 en Cómo programa la plataforma Nexus una máquina virtual de clúster de Nexus Kubernetes).
Esta es una visualización de un diseño que el usuario puede ver después de implementar clústeres A, B y C en un entorno vacío.
Entorno medio lleno
A continuación, ejecutaremos un ejemplo para iniciar otro clúster de NKS cuando el entorno de destino esté medio lleno. El entorno de destino está medio lleno después de implementar los clústeres A, B y C en el entorno de destino.
El clúster D tiene las siguientes especificaciones:
- Plano de control,
NC_G24_112_v1SKU, cinco unidades - Grupo de agentes n.º 1,
NC_P46_224_v1SKU, 24 unidades,AvailabilityZones = [7,8] - Grupo de agentes n.º 2,
NC_P22_112_v1SKU, 24 unidades
Esta es una tabla que resume lo que el usuario debería ver después de iniciar el clúster D en el entorno de Operator Nexus medio lleno que existe después de iniciar los clústeres A, B y C.
| Clúster | grupo | SKU | Recuento total | Número de bastidores previsto | Número real de bastidores | Número previsto de máquinas virtuales por bastidor | Número real de máquinas virtuales por bastidor |
|---|---|---|---|---|---|---|---|
| D | Plano de control | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Grupo de agentes n.º 1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Grupo de agentes n.º 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
El Grupo de agentes del clúster D n.º 1 tiene 12 máquinas virtuales restringidas a las zonas de disponibilidad [7, 8], por lo que tiene 12 máquinas virtuales en 12 servidores sin sistema operativo, seis en cada uno de los bastidores 7 y 8. Esas máquinas virtuales se ubican en servidores sin sistema operativo que también albergan máquinas virtuales extragrandes de otros clústeres debido a la regla de clasificación que agrupa las máquinas virtuales extragrandes de diferentes clústeres en los mismos servidores sin sistema operativo.
Si una máquina virtual del plano de control del clúster D se ubica en el bastidor 7 u 8, es probable que una máquina virtual del Grupo de agentes #1 del clúster D se ubique en el mismo servidor sin sistema operativo que esa máquina virtual del plano de control del clúster D. Este comportamiento se debe a que el grupo de agentes n.º 1 está "anclado" a los bastidores 7 y 8. Las restricciones de capacidad de esos bastidores hacen que el programador intercale una máquina virtual del plano de control y una máquina virtual del Grupo de agentes n.º 1 del mismo clúster de NKS.
El Grupo de agentes n.º 2 del clúster D tiene tres máquinas virtuales en diferentes servidores sin sistema operativo en cada uno de los ocho bastidores. Las restricciones de capacidad se debieron a que el Grupo de agentes n.º 1 del clúster D se ancló a los bastidores 7 y 8. Por lo tanto, las máquinas virtuales del Grupo de agentes n.º 1 y n.º 2 del clúster D están ubicadas en los mismos servidores sin sistema operativo en los bastidores 7 y 8.
Esta es una visualización de un diseño que el usuario podría ver después de implementar el clúster D en el entorno de destino.
Entorno casi lleno
En nuestro entorno de destino de ejemplo, cuatro de los ocho bastidores están próximos a su límite de capacidad. Intentemos iniciar otro clúster de NKS.
El clúster E tiene las siguientes especificaciones:
- Plano de control,
NC_G24_112_v1SKU, cinco unidades - Grupo de agentes n.º 1,
NC_P46_224_v1SKU, 32 unidades
Esta es una tabla que resume lo que el usuario debería ver después de iniciar el clúster E en el entorno de destino.
| Clúster | grupo | SKU | Recuento total | Número de bastidores previsto | Número real de bastidores | Número previsto de máquinas virtuales por bastidor | Número real de máquinas virtuales por bastidor |
|---|---|---|---|---|---|---|---|
| E | Plano de control | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Grupo de agentes n.º 1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 o 5 |
El Grupo de agentes n.º 1 del clúster E se repartirá de forma desigual por los ocho bastidores. Los bastidores 7 y 8 tendrán tres máquinas virtuales de NKS del Grupo de agentes n.º 1 en lugar de las cuatro esperadas porque no hay más capacidad para las máquinas virtuales SKU extragrandes en esos bastidores después de programar los clústeres A a D. Como los bastidores 7 y 8 no tienen capacidad para la cuarta SKU extragrande del Grupo de agentes n.º 1, cinco máquinas virtuales de NKS se ubicarán en los dos bastidores menos utilizados. En nuestro ejemplo, esos bastidores menos utilizados eran los bastidores 3 y 6.
Esta es una visualización de un diseño que el usuario podría ver después de implementar el clúster E en el entorno de destino.
Selección de ubicación durante una actualización en tiempo de ejecución
A partir de abril de 2024 (versión de Network Cloud 2304.1), las actualizaciones en tiempo de ejecución se realizan mediante una estrategia de bastidor a bastidor. Se restablece la imagen inicial de los servidores sin sistema operativo del bastidor 1 a la vez. El proceso de actualización se detiene hasta que todos los servidores sin sistema operativo se reinician correctamente e indican a Nexus que están listos para recibir cargas de trabajo.
Nota:
Es posible indicar a Operator Nexus que solo restablezca la imagen de una parte de los servidores sin sistema operativo de un bastidor a la vez, sin embargo, de manera predeterminada se restablecen todos los servidores sin sistema operativo de un bastidor en paralelo.
Cuando se restablece la imagen inicial de un servidor sin sistema operativo individual, todas las cargas de trabajo que se ejecutan en ese servidor sin sistema operativo, incluidas todas las máquinas virtuales de NKS, pierden potencia y conectividad. A su vez, los contenedores de carga de trabajo que se ejecutan en las máquinas virtuales de NKS perderán potencia y conectividad. Tras un minuto sin poder acceder a esos contenedores de carga de trabajo, el Plano de control de Kubernetes del clúster de NKS marcará los Pods correspondientes como no saludables. Si los Pods son miembros de una implementación o StatefulSet, el plano de control de Kubernetes del clúster de NKS intenta iniciar Pods de reemplazo para que el recuento de réplicas observado de la implementación o StatefulSet vuelva al recuento de réplicas deseado.
Los nuevos Pods solo se inician si hay capacidad disponible para el Pod en las restantes máquinas virtuales de NKS en estado correcto. A partir de abril de 2024 (versión 2304.1 de Network Cloud), no se crean nuevas máquinas virtuales de NKS para reemplazar las máquinas virtuales de NKS que se encontraban en el servidor sin sistema operativo que se está restaurando.
Una vez que se restablece la imagen inicial del servidor sin sistema operativo y el mismo es capaz de aceptar nuevas máquinas virtuales de NKS, las máquinas virtuales de NKS que se encontraban originalmente en el mismo servidor sin sistema operativo se reinician en el servidor sin sistema operativo recién restablecido. Los contenedores de carga de trabajo pueden después programarse para esas máquinas virtuales de NKS, restaurando potencialmente las implementaciones o StatefulSets que tenían Pods en máquinas virtuales de NKS que estaban en el servidor sin sistema operativo.
Nota:
Este comportamiento puede parecer al usuario como si las máquinas virtuales de NKS no se hubieran "movido" del servidor sin sistema operativo, cuando en realidad se inició una nueva instancia de una máquina virtual de NKS idéntica en el servidor sin sistema operativo del que se acaba de restablecer la imagen inicial que conservaba el mismo nombre de servidor sin sistema operativo que antes de restablecer la imagen inicial.
procedimientos recomendados
Cuando trabaje con Operator Nexus, tenga en cuenta los siguientes procedimientos recomendados.
- Evite especificar
AvailabilityZonespara un Grupo de agentes. - Iniciar clústeres de NKS más grandes antes que los más pequeños.
- Reduzca el recuento del Grupo de agentes antes de reducir el tamaño de la SKU de la máquina virtual.
Evite especificar AvailabilityZones para un Grupo de agentes
Como puede deducir de los escenarios de ubicación anteriores, especificar AvailabilityZones para un Grupo de agentes es la razón principal por la que las máquinas virtuales de NKS del mismo clúster de NKS acabarían en el mismo servidor sin sistema operativo. Al especificar AvailabilityZones, "ancla" el Grupo de agentes a un subconjunto de bastidores y, por lo tanto, limita el número de posibles servidores sin sistema operativo en ese conjunto de bastidores para que otros clústeres de NKS y otras máquinas virtuales del Grupo de agentes del mismo clúster de NKS se ubiquen en ellos.
Por lo tanto, nuestro primer procedimiento recomendado es evitar especificar AvailabilityZones para un Grupo de agentes. Si necesita vincular un Grupo de agentes a un conjunto de Zonas de disponibilidad, haga que ese conjunto sea lo más grande posible para minimizar el desequilibrio que puede producirse.
La única excepción a este procedimiento recomendado es cuando se tiene un escenario con solo dos o tres máquinas virtuales en un grupo de agentes. Puede considerar establecer AvailabilityZones para ese grupo de agentes en [1,3,5,7] o [0,2,4,6] para aumentar la disponibilidad durante las actualizaciones en tiempo de ejecución.
Iniciar clústeres de NKS más grandes antes que los más pequeños
A partir de abril de 2024 y de la versión 2403.1 de Network Cloud, los clústeres de NKS se programan en el orden en que se crean. Para empaquetar de forma más eficaz el entorno de destino, le recomendamos que cree clústeres de NKS más grandes antes que los más pequeños. Asimismo, le recomendamos que programe los Grupos de agentes más grandes antes que los más pequeños.
Esta recomendación es importante para los Grupos de agentes que usan la SKU NC_G48_224_v1 o NC_P46_224_v1 extragrande. La programación de los Grupos de agentes con el mayor número de estas máquinas virtuales SKU extragrandes crea un conjunto mayor de servidores sin sistema operativo en los que se pueden ubicar otras máquinas virtuales SKU extragrandes de los Grupos de agentes de otros clústeres de NKS.
Reduzca el recuento del Grupo de agentes antes de reducir el tamaño de la SKU de la máquina virtual
Si se encuentra con limitaciones de capacidad al iniciar un clúster de NKS o un Grupo de agentes, reduzca el recuento del Grupo de agentes antes de ajustar el tamaño de la SKU de la máquina virtual. Por ejemplo, si intenta crear un Clúster de NKS con un Grupo de agentes con un tamaño de SKU de máquina virtual de NC_P46_224_v1 y un Recuento de 24 y recibe un fallo al aprovisionar el clúster de NKS debido a recursos insuficientes, puede verse tentado a usar un Tamaño de SKU de máquina virtual de NC_P36_168_v1 y continuar con un Recuento de 24. Sin embargo, debido a los requisitos para que las máquinas virtuales de carga de trabajo estén alineadas en una única celda NUMA en un servidor sin sistema operativo, es probable que esa misma solicitud provoque fallos similares de insuficiencia de recursos. En lugar de reducir el tamaño de la SKU de la máquina virtual, considere reducir el recuento del Grupo de agentes a 20. Hay más posibilidades de que su solicitud se ajuste a la capacidad de recursos del entorno de destino y de que su implementación global tenga más núcleos de CPU que si redujera el tamaño de la SKU de la máquina virtual.