Preguntas frecuentes sobre los grupos de nodos de Windows Server en AKS
En Azure Kubernetes Service (AKS) puede crear un grupo de nodos que ejecuta Windows Server como sistema operativo invitado en los nodos. Estos nodos pueden ejecutar aplicaciones de contenedor nativas de Windows, como las integradas en .NET Framework. Hay diferencias con respecto al modo en que los sistemas operativos Linux y Windows proporcionan compatibilidad de contenedor. Algunas características comunes de Linux relacionadas con Kubernetes y los pods no están disponibles en este momento para los grupos de nodos de Windows.
En este artículo se esbozan algunas de las preguntas frecuentes y los conceptos de sistema operativo sobre los nodos de Windows Server en AKS.
¿Qué tipo de discos se admiten en Windows?
Azure Disk y Azure Files son los tipos de volúmenes admitidos, a los que se accede como volúmenes NTFS en el contenedor de Windows Server.
¿Se admiten en Linux y Windows máquinas virtuales de Generación 2?
Las máquinas virtuales de Generación 2 solo se admiten en Linux y Windows para WS2022. Para más información, consulte Compatibilidad para máquinas virtuales de generación 2 en Azure.
¿Cómo se aplica una revisión a los nodos de Windows?
Para obtener las revisiones más recientes de los nodos de Windows, puede actualizar el grupo de nodos o actualizar la imagen de los nodos. Las actualizaciones de Windows no están habilitadas en los nodos de AKS. AKS publica nuevas imágenes de los grupos de nodos en cuanto hay revisiones disponibles; es responsabilidad de los usuarios actualizar los grupos de nodos para mantenerse al día de las revisiones y correcciones. Este proceso de revisión también se aplica a la versión de Kubernetes que se esté usando. Las notas de la versión de AKS indican cuándo hay nuevas versiones disponibles. Para más información sobre cómo actualizar un grupo de nodos de Windows Server, consulte el artículo de actualización de un grupo de nodos en AKS. Si solo está interesado en actualizar la imagen de los nodos, vea Actualizaciones de imágenes de nodo de AKS.
Nota
La imagen de Windows Server actualizada solo se usa si se ha realizado una actualización del clúster (actualización del plano de control) antes de actualizar el grupo de nodos.
¿Se admite la conservación de la IP de origen del cliente?
En este momento, la conservación de la IP de origen del cliente no es compatible con los nodos de Windows.
¿Se puede cambiar el número máximo de pods por nodo?
Sí. Para conocer las implicaciones de un cambio y las opciones disponibles, vea Pods máximos por nodo.
¿Cuál es el tiempo de espera de TCP predeterminado en el sistema operativo Windows?
El tiempo de espera de TCP predeterminado en el sistema operativo Windows es de 4 minutos. Este valor no se puede configurar. Cuando una aplicación usa un tiempo de espera más largo, las conexiones TCP entre distintos contenedores del mismo nodo se cierran después de cuatro minutos.
¿Por qué se muestra un error al tratar de crear un nuevo grupo de agentes de Windows?
Si ha creado el clúster antes de febrero de 2020 y nunca ha realizado ninguna operación de actualización, este sigue usando una imagen de Windows antigua. Es posible que se haya mostrado un error similar al siguiente:
"No se encontró la siguiente lista de imágenes a las que se hace referencia en la plantilla de implementación: Publicador: MicrosoftWindowsServer, Oferta: WindowsServer, SKU: 2019-datacenter-core-smalldisk-2004, Versión: más reciente. Vea Búsqueda y uso de imágenes de máquina virtual de Azure Marketplace con Azure PowerShell para obtener instrucciones para encontrar imágenes disponibles."
Para corregir este error:
- Actualice el plano de control del clúster a fin de actualizar la oferta y el publicador de la imagen.
- Cree nuevos grupos de agentes de Windows.
- Mueva los pods de Windows de los grupos de agentes de Windows existentes a los nuevos.
- Elimine los grupos de agentes de Windows anteriores.
¿Por qué se muestra un error al tratar de implementar pods de Windows?
Si especifica un valor en --max-pods menor que el número de pods que desea crear, es posible que vea el error No available addresses.
Para corregir este error, use el comando az aks nodepool add con un valor --max-pods suficientemente alto:
az aks nodepool add \
--cluster-name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--name $NODEPOOL_NAME \
--max-pods 3
Para más información, consulte la --max-pods documentación.
¿Por qué hay un usuario inesperado denominado "sshd" en mi nodo de máquina virtual?
AKS agrega un usuario denominado "sshd" al instalar el servicio OpenSSH. Este usuario no es malintencionado. Se recomienda que los clientes actualicen sus alertas para omitir esta cuenta de usuario inesperada.
¿Cómo se realiza la rotación de la entidad de servicio para el grupo de nodos de Windows?
Los grupos de nodos de Windows no admiten la rotación de la entidad de servicio. Para actualizar la entidad de servicio, cree un nuevo grupo de nodos de Windows y migre los pods del grupo anterior al nuevo. Después de migrar los pods al nuevo grupo, elimine el grupo de nodos anterior.
En lugar de entidades de servicio, use identidades administradas que, básicamente, son contenedores en torno a entidades de servicio. Para obtener más información, consulte Uso de identidades administradas en Azure Kubernetes Service.
¿Cómo cambio la contraseña de administrador de los nodos de Windows Server en el clúster?
Al crear el clúster de AKS, se especifican los parámetros --windows-admin-password y --windows-admin-username para establecer las credenciales de administrador de los nodos de Windows Server del clúster. Si no ha especificado la credenciales de administrador al crear un clúster mediante Azure Portal o al establecer --vm-set-type VirtualMachineScaleSets y --network-plugin azure mediante la CLI de Azure, el nombre de usuario tiene como valor predeterminado azureuser y una contraseña aleatoria.
Para cambiar la contraseña de administrador, use el comando az aks update:
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--windows-admin-password $NEW_PW
Importante
Al realizar la operaciónaz aks update se actualizan solo los grupos de nodos de Windows Server y se provoca un reinicio. Los grupos de nodos de Linux no se ven afectados.
Al cambiar --windows-admin-password, la nueva contraseña debe tener al menos 14 caracteres y cumplir los requisitos de contraseña de Windows Server.
¿Cuántos grupos de nodos puedo crear?
Un clúster de AKS con grupos de nodos de Windows no tiene un límite de recursos de AKS diferente al predeterminado especificado para el servicio AKS. Consulte Cuotas, restricciones de tamaño de máquinas virtuales y disponibilidad de regiones en Azure Kubernetes Service (AKS).
¿Qué nombre puedo usar para mis grupos de nodos de Windows?
Un grupo de nodos de Windows puede tener un nombre de seis caracteres.
¿Son todas las características compatibles con los nodos de Windows?
Kubenet actualmente no es compatible con los nodos de Windows.
¿Puedo ejecutar controladores de entrada en los nodos de Windows?
Sí, un controlador de entrada que admita contenedores de Windows Server se puede ejecutar en nodos de Windows en AKS.
¿Pueden usar gMSA los contenedores de Windows Server?
La compatibilidad con la cuenta de servicio administrada por grupo (gMSA) está disponible con carácter general para Windows en AKS. Consulte Habilitación de cuentas de servicio administradas por grupo (gMSA) para los nodos de Windows Server en el clúster de Azure Kubernetes Service (AKS).
¿Puedo usar Azure Monitor para contenedores con nodos y contenedores de Windows?
Sí, puede hacerlo. Pero Azure Monitor se encuentra en versión preliminar pública para la recopilación de registros (stdout, stderr) y métricas de contenedores de Windows. También puede conectarse al streaming en vivo de registros de stdout desde un contenedor de Windows.
¿Existe alguna limitación en el número de servicios que puede haber en un clúster con nodos de Windows?
Un clúster con nodos de Windows puede tener aproximadamente 500 servicios (algunas veces menos) antes de que se agote el puerto. Esta limitación se aplica a un servicio de Kubernetes con la directiva de tráfico externo establecida en "Clúster".
Cuando la directiva de tráfico externo en un servicio se configura como Clúster, el tráfico se somete a una NAT de origen adicional en el nodo, lo que también da lugar a la reserva de un puerto del grupo de puertos dinámicos TCPIP. Este grupo de puertos es un recurso limitado (unos 16 000 puertos de forma predeterminada) y muchas conexiones activas a un servicio pueden dar lugar a un agotamiento dinámico del grupo de puertos, lo que provoca caídas de conexión.
Si Kubernetes Service está configurado con la directiva de tráfico externo establecida en "Local", es probable que los problemas de agotamiento de puertos no se produzcan en 500 servicios.
¿Puedo usar Ventaja híbrida de Azure con los nodos de Windows?
Sí. Ventaja híbrida de Azure para Windows Server reduce los costes operativos, al permitirle llevar su licencia de Windows Server local a los nodos de Windows de AKS.
Ventaja híbrida de Azure puede usarse en todo el clúster de AKS o en nodos individuales. En los nodos individuales, debe ir al grupo de recursos de nodos y aplicar Ventaja híbrida de Azure directamente a los nodos. Para obtener más información sobre cómo aplicar Ventaja híbrida de Azure a nodos individuales, consulte Ventaja híbrida de Azure para Windows Server.
Para usar Ventaja híbrida de Azure en un nuevo clúster de AKS, ejecute el comando az aks create y use el argumento --enable-ahub.
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--load-balancer-sku Standard \
--windows-admin-password 'Password1234$' \
--windows-admin-username azure \
--network-plugin azure
--enable-ahub
Para usar Ventaja híbrida de Azure en un clúster de AKS existente, ejecute el comando az aks update y actualice el clúster con el argumento --enable-ahub.
az aks update \
--resource-group myResourceGroup
--name myAKSCluster
--enable-ahub
Para comprobar si Ventaja híbrida de Azure está establecido en los nodos de Windows del clúster, ejecute el comando az vmss show con los argumentos --name y --resource-group para consultar el conjunto de escalado de máquinas virtuales. Para identificar el grupo de recursos en el que se crea el conjunto de escalado del grupo de nodos de Windows, puede ejecutar el comando az vmss list -o table.
az vmss show --name myScaleSet --resource-group MC_<resourceGroup>_<clusterName>_<region>
Si los nodos de Windows del conjunto de escalado tienen habilitada la Ventaja híbrida de Azure, la salida de az vmss show será similar a la siguiente:
""hardwareProfile": null,
"licenseType": "Windows_Server",
"networkProfile": {
"healthProbe": null,
"networkApiVersion": null,
¿Cómo se cambia la zona horaria de un contenedor en ejecución?
Para cambiar la zona horaria de un contenedor de Windows Server en ejecución, conéctese al contenedor en ejecución con una sesión de PowerShell. Por ejemplo:
kubectl exec -it CONTAINER-NAME -- powershell
En el contenedor en ejecución, use Set-TimeZone para establecer la zona horaria del contenedor en ejecución. Por ejemplo:
Set-TimeZone -Id "Russian Standard Time"
Para ver la zona horaria actual del contenedor en ejecución o una lista disponible de zonas horarias, use Get-TimeZone.
¿Puedo mantener la afinidad de sesión desde las conexiones cliente a pods con contenedores de Windows?
Aunque se admite el mantenimiento de la afinidad de sesión desde las conexiones cliente a pods con contenedores de Windows en la versión del sistema operativo Windows Server 2022, la afinidad de sesión por IP de cliente se logra actualmente limitando el pod deseado a ejecutar una única instancia por nodo y configurando el servicio Kubernetes para dirigir el tráfico al pod en el nodo local.
Use la configuración siguiente:
- Use un clúster de AKS con una versión mínima de 1.20.
- Restrinja el pod para permitir solo una instancia por cada nodo de Windows. Puede lograrlo si usa la antiafinidad en la configuración de implementación.
- En la configuración del servicio Kubernetes, establezca externalTrafficPolicy=Local. Esto garantiza que el servicio de Kubernetes solo dirija el tráfico a los pods del nodo local.
- En la configuración del servicio Kubernetes, establezca sessionAffinity: ClientIP. Esto garantiza que Azure Load Balancer se configure con afinidad de sesión.
Pasos siguientes
Para empezar a trabajar con contenedores de Windows Server en AKS, vea Creación de un grupo de nodos que ejecute Windows Server en AKS.