Límites de recursos, tamaños de máquina virtual y regiones para AKS habilitados por Azure Arc
Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server
En este artículo se proporciona información sobre las configuraciones probadas, los límites de recursos, los tamaños de máquina virtual y las regiones de Azure Kubernetes Service (AKS) habilitados por Azure Arc. Las pruebas usaron la versión más reciente de AKS en Azure Local.
Especificaciones máximas
Las implementaciones de AKS habilitadas por Arc se han validado con las siguientes configuraciones, incluidos los máximos especificados. Tenga en cuenta que si supera estos máximos, bajo su propio riesgo, podría provocar comportamientos y errores inesperados. Este artículo servirá de guía para evitar errores de configuración comunes y podrá ayudar a crear una configuración mayor. Si tiene dudas, póngase en contacto con su oficina local de Microsoft para obtener ayuda o envíe una pregunta en la comunidad local de Azure.
| Resource | Máxima |
|---|---|
| Servidores físicos por clúster | 8 |
| Número total de máquinas virtuales | 200 |
Los límites recomendados se probaron con los tamaños de máquina virtual (VM) predeterminados, en función de la tabla siguiente:
| Rol del sistema | Tamaño de VM |
|---|---|
| AKS-Host | Standard_A4_v2 |
| Nodo del plano de control del clúster de destino | Valor predeterminado |
| Equilibrador de carga HAProxy de clúster de destino (opcional) | Standard_A4_v2 |
| Nodo de trabajo de Linux de clúster de destino | Standard_K8S3_v1 |
| Nodo de trabajo de Windows de clúster de destino | Standard_K8S3_v1 |
La configuración de hardware de cada nodo físico en el clúster local de Azure es la siguiente:
- Chasis: Servidor Dell PowerEdge R650 o similar.
- RAM: RDIMM, 3200 MT/s, Rango dual, total de 256 GB.
- CPU: Dos (2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10.4 GT/s, caché de 30M, Turbo, HT (150 W) DDR4-2666.
- Disco: 8 HDD (2 TB o más) y 2 NVMe de 1,6 TB para admitir configuraciones de almacenamiento S2D.
- Red: Cuatro (4) NIC de 100 Gbit (Mellanox o Intel).
La ingeniería de Microsoft ha probado AKS habilitado por Arc mediante la configuración anterior. Para un solo nodo. 2 nodos, 4 nodos y 8 clústeres de conmutación por error de Windows. Si tiene un requisito para superar la configuración probada, consulte Escalado de AKS en Azure Local.
Importante
Al actualizar una implementación de AKS, se consumen temporalmente recursos adicionales. Cada máquina virtual se actualiza en un flujo de actualización gradual, empezando por los nodos del plano de control. Para cada nodo del clúster de Kubernetes, se crea una nueva máquina virtual de nodo. La máquina virtual del nodo anterior está restringida para evitar que las cargas de trabajo se implementen en ella. A continuación, la máquina virtual restringida se purga de todos los contenedores para distribuirlos a otras máquinas virtuales del sistema. A continuación, la máquina virtual purgada se quita del clúster, se cierra y se reemplaza por la nueva máquina virtual actualizada. Este proceso se repite hasta que se actualizan todas las máquinas virtuales.
Tamaños de máquina virtual disponibles
Los siguientes tamaños de máquina virtual para los nodos del plano de control, los nodos de trabajo de Linux y los nodos de trabajo de Windows están disponibles para AKS en Azure Local. Aunque se admiten tamaños de máquina virtual como Standard_K8S2_v1 y Standard_K8S_v1 para realizar pruebas y implementaciones de requisitos de recursos bajos, use estos tamaños con cuidado y aplique pruebas estrictas, ya que pueden provocar errores inesperados debido a condiciones de memoria insuficientes.
| Tamaño de VM | CPU | Memoria (GB) | Tipo de GPU | Recuento de GPU |
|---|---|---|---|---|
| Valor predeterminado | 4 | 4 | ||
| Standard_A2_v2 | 2 | 4 | ||
| Standard_A4_v2 | 4 | 8 | ||
| Standard_D2s_v3 | 2 | 8 | ||
| Standard_D4s_v3 | 4 | 16 | ||
| Standard_D8s_v3 | 8 | 32 | ||
| Standard_D16s_v3 | 16 | 64 | ||
| Standard_D32s_v3 | 32 | 128 | ||
| Standard_DS2_v2 | 2 | 7 | ||
| Standard_DS3_v2 | 2 | 14 | ||
| Standard_DS4_v2 | 8 | 28 | ||
| Standard_DS5_v2 | 16 | 56 | ||
| Standard_DS13_v2 | 8 | 56 | ||
| Standard_K8S_v1 | 4 | 2 | ||
| Standard_K8S2_v1 | 2 | 2 | ||
| Standard_K8S3_v1 | 4 | 6 | ||
| Standard_NK6 | 6 | 12 | Tesla T4 | 1 |
| Standard_NK12 | 12 | 24 | Tesla T4 | 2 |
Regiones de Azure admitidas para el registro de Azure
AKS habilitado por Arc se admite en las siguientes regiones de Azure:
- Este de Australia
- Este de EE. UU.
- Sudeste de Asia
- Oeste de Europa
Escalado de AKS en Azure Local
El escalado de una implementación de AKS en Azure Local implica planear con antelación el conocimiento de las cargas de trabajo y el uso del clúster de destino. Además, tenga en cuenta los recursos de hardware de la infraestructura subyacente, como los núcleos de CPU totales, la memoria total, el almacenamiento, las direcciones IP, etc.
En los ejemplos siguientes se supone que solo se implementan cargas de trabajo basadas en AKS en la infraestructura subyacente. La implementación de cargas de trabajo que no son de AKS, como máquinas virtuales independientes o en clúster, o servidores de bases de datos, reduce los recursos disponibles para AKS, que debe tener en cuenta.
Antes de empezar, tenga en cuenta los siguientes puntos para determinar la escala máxima y el número de clústeres de destino que necesita admitir:
- Número de direcciones IP que tiene disponibles para pods en un clúster de destino.
- Número de direcciones IP disponibles para los servicios de Kubernetes en un clúster de destino.
- Número de pods que necesita para ejecutar las cargas de trabajo.
Para determinar el tamaño de la máquina virtual host de Azure Kubernetes Service, debe conocer el número de nodos de trabajo y clústeres de destino, ya que determina el tamaño de la máquina virtual host de AKS. Por ejemplo:
- Número de clústeres de destino en el sistema implementado final.
- Número de nodos, incluidos el plano de control, el equilibrador de carga y los nodos de trabajo en todos los clústeres de destino.
Nota:
Un único host de AKS solo puede administrar clústeres de destino en la misma plataforma.
Además, para determinar el tamaño del nodo del plano de control del clúster de destino, debe conocer el número de pods, contenedores y nodos de trabajo que planea implementar en cada clúster de destino.
Configuración predeterminada que actualmente no se puede cambiar en AKS
Actualmente no hay configuraciones y opciones predeterminadas disponibles para el control de clientes durante o después de la implementación. Esta configuración puede limitar la escala de un clúster de destino determinado.
- El número de direcciones IP de los pods de Kubernetes en un clúster de destino se limita a la subred
10.244.0.0/16. Es decir, se pueden usar 255 direcciones IP por nodo de trabajo en todos los espacios de nombres de Kubernetes para pods. Para ver el CIDR del pod asignado a cada nodo de trabajo del clúster, use el siguiente comando en PowerShell:
kubectl get nodes -o json | findstr 'hostname podCIDR'
"kubernetes.io/hostname": "moc-lip6cotjt0f",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.2.0/24",
"podCIDRs": [
"kubernetes.io/hostname": "moc-lmb6zqozk4m",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.4.0/24",
"podCIDRs": [
"kubernetes.io/hostname": "moc-wgwhhijxtfv",
"f:podCIDR": {},
"f:podCIDRs": {
"f:kubernetes.io/hostname": {},
"podCIDR": "10.244.5.0/24",
"podCIDRs": [
En el ejemplo, puede ver tres nodos con tres CIDR, cada uno capaz de hospedar 254 pods. La documentación de escalado de Kubernetes recomienda no superar los 110 pods por nodo por motivos de rendimiento. Consulte Consideraciones para clústeres de gran tamaño.
Otras consideraciones:
- El número de direcciones IP para los servicios de Kubernetes, fuera del grupo de DIRECCIONES VIP que asignó, procede del
10.96.0.0/16grupo de direcciones. El sistema consume una de las 255 direcciones disponibles para el servidor de API de Kubernetes. - El tamaño de la máquina virtual host de AKS solo se puede establecer en la instalación, cuando se ejecuta Set-AksHciConfig por primera vez. No se puede cambiar después.
- Solo puede establecer el tamaño del plano de control del clúster de destino y las máquinas virtuales del equilibrador de carga en el momento de la creación del clúster de destino.
Ejemplo de escalado
El ejemplo de escalado siguiente se basa en estas suposiciones generales o casos de uso:
- Quiere ser capaz de tolerar completamente la pérdida de un nodo físico en el clúster local de Azure.
- Desea admitir la actualización de clústeres de destino a versiones más recientes.
- Quiere permitir la alta disponibilidad de los nodos del plano de control del clúster de destino y los nodos del equilibrador de carga.
- Quiere reservar una parte de la capacidad global de Azure Local para estos casos.
Sugerencias
Para obtener un rendimiento óptimo, asegúrese de establecer al menos el 15 por ciento (100/8=12,5) de la capacidad del clúster para permitir que todos los recursos de un nodo físico se redistribuyan a los otros siete nodos (7). Esta configuración garantiza que tiene alguna reserva disponible para realizar una actualización u otras operaciones del día dos de AKS.
Si quiere aumentar más allá del límite de 200 máquinas virtuales para un clúster local de Azure local de ocho (8) nodos máximos de hardware, aumente el tamaño de la máquina virtual host de AKS. Duplicar el tamaño da como resultado aproximadamente el doble del número de máquinas virtuales que puede administrar. En un clúster local de Azure de 8 nodos, puede acceder a 8 192 máquinas virtuales (8x1024) basadas en los límites de recursos recomendados de Azure Local documentados en las especificaciones de hardware máxima admitidas. Debe reservar aproximadamente el 30 % de capacidad, lo que le deja con un límite teórico de 5734 máquinas virtuales en todos los nodos.
- Standard_D32s_v3, para el host de AKS con 32 núcleos y 128 GB, puede admitir un máximo de 1600 nodos.
Nota:
Dado que esta configuración no se ha probado ampliamente, requiere un enfoque y una validación cuidadosos.
A escala como esta, es posible que quiera dividir el entorno en al menos 8 clústeres de destino con 200 nodos de trabajo cada uno.
Para ejecutar 200 nodos de trabajo en un clúster de destino, puede usar el tamaño predeterminado de plano de control y equilibrador de carga. Según el número de pods por nodo, puede subir al menos un tamaño en el plano de control y usar Standard_D8s_v3.
Según el número de servicios de Kubernetes hospedados en cada clúster de destino, es posible que tenga que aumentar el tamaño de la máquina virtual del equilibrador de carga, así como la creación de clústeres de destino para asegurarse de que los servicios se pueden alcanzar con un alto rendimiento y el tráfico se enruta en consecuencia.
La implementación de AKS habilitada por Arc distribuye los nodos de trabajo para cada grupo de nodos de un clúster de destino en los nodos locales de Azure disponibles mediante la lógica de selección de ubicación local de Azure.
Importante
La ubicación del nodo no se conserva durante las actualizaciones de la plataforma y AKS y cambiará con el tiempo. Un nodo físico con error también afectará a la distribución de máquinas virtuales en los nodos de clúster restantes.
Nota:
No ejecute más de cuatro creaciones de clúster de destino al mismo tiempo si el clúster físico ya está lleno del 50 %, ya que esto puede provocar la contención temporal de recursos. Al escalar verticalmente los grupos de nodos de clúster de destino por números grandes, tenga en cuenta los recursos físicos disponibles, ya que AKS no comprueba la disponibilidad de los recursos para los procesos de creación y escalado paralelos. Asegúrese siempre de que la reserva sea suficiente para permitir las actualizaciones y conmutación por error. Especialmente en entornos muy grandes, estas operaciones, cuando se ejecutan en paralelo, pueden provocar un agotamiento rápido de los recursos.
Si tiene dudas, póngase en contacto con su oficina local de Microsoft para obtener ayuda o publicar en el foro de la comunidad local de Azure.