Requisitos del sistema para AKS habilitados por Azure Arc en Azure Stack HCI 22H2
Se aplica a: Azure Stack HCI, versiones 22H2; Windows Server 2022, Windows Server 2019
En este artículo se describen los requisitos para configurar Azure Kubernetes Service (AKS) habilitados por Azure Arc. Para obtener información general sobre AKS habilitado por Arc, consulte la introducción a AKS.
Requisitos de hardware
Microsoft recomienda adquirir una solución de hardware o software de Azure Stack HCI validada de nuestros asociados. Estas soluciones se diseñan, se ensamblan y se validan para ejecutar nuestra arquitectura de referencia y comprobar la compatibilidad y la confiabilidad, de modo que pueda empezar a utilizarlas rápidamente. Compruebe que los sistemas, componentes, dispositivos y controladores que usa estén certificados para Windows Server según el catálogo de Windows Server. Consulte el sitio web de soluciones de Azure Stack HCI para ver las soluciones validadas.
Importante
Los sistemas host para implementaciones de producción deben ser hardware físico. La virtualización anidada, que se caracteriza por implementar Azure Stack HCI o Windows Server en una máquina virtual e instalar AKS en esa máquina virtual, no se admite.
Especificaciones de hardware máximas admitidas
No se admiten las implementaciones de AKS en Azure Stack HCI y Windows Server que no cumplan las siguientes especificaciones:
| Recurso | Máxima |
|---|---|
| Servidores físicos por clúster | 8 (Azure Stack HCI versión 22H2 y Windows Server) |
| Total de máquinas virtuales (VM) | 200 |
Requisitos de proceso
Requisitos mínimos de memoria
Puede configurar el clúster de AKS de la siguiente manera para ejecutar AKS en un solo nodo de Windows Server con RAM limitada:
| Tipo de clúster | Tamaño de máquina virtual del plano de control | Nodo de trabajo | Para las operaciones de actualización | Equilibrador de carga |
|---|---|---|---|---|
| Host de AKS | Standard_A4_v2, tamaño de la máquina virtual = 8 GB | N/A: el host de AKS no tiene nodos de trabajo. | 8 GB | N/A: el host de AKS usa kubevip para el equilibrio de carga. |
| Clúster de carga de trabajo | Standard_A4_v2, tamaño de la máquina virtual = 8 GB | Standard_K8S3_v1 para 1 nodo de trabajo = 6 GB | Puede volver a usar este 8 GB reservado para la actualización del clúster de cargas de trabajo. | N/A si kubevip se usa para el equilibrio de carga (en lugar del equilibrador de carga haProxy predeterminado). |
Requisito mínimo total: 30 GB de RAM.
Este requisito mínimo es para una implementación de AKS con un nodo de trabajo para ejecutar aplicaciones en contenedor. Si decide agregar nodos de trabajo o un equilibrador de carga haProxy, el requisito de RAM final cambia en consecuencia.
Requisitos de proceso recomendados
| Entorno | Núcleos de CPU por servidor | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 GB |
| Clúster de conmutación por error de Windows Server | 32 | 256 GB |
| Windows Server de un solo nodo | 16 | 128 GB |
Para un entorno de producción, el ajuste de tamaño final depende de la aplicación y el número de nodos de trabajo que planea implementar en el clúster de Azure Stack HCI o Windows Server. Si decide ejecutar AKS en un servidor Windows Server de un solo nodo, no obtiene características como la alta disponibilidad que se incluye con la ejecución de AKS en un clúster de Azure Stack HCI o Windows Server o en un clúster de conmutación por error de Windows Server.
Otros requisitos de proceso para AKS en Azure Stack HCI y Windows Server están en línea con los requisitos de Azure Stack HCI. Consulte Requisitos del sistema de Azure Stack HCI para más información sobre los requisitos del servidor de Azure Stack HCI.
Debe instalar el mismo sistema operativo en cada servidor del clúster. Si usa Azure Stack HCI, el mismo sistema operativo y la misma versión deben estar en el mismo en cada servidor del clúster. Si usa Windows Server Datacenter, el mismo sistema operativo y versión debe ser el mismo en cada servidor del clúster. Cada sistema operativo debe usar las selecciones de idioma y región en-us . No puede cambiar esta configuración después de la instalación.
Requisitos de almacenamiento
AKS en Azure Stack HCI y Windows Server admiten las siguientes implementaciones de almacenamiento:
| Nombre | Tipo de almacenamiento | Capacidad necesaria |
|---|---|---|
| Clúster de Azure Stack HCI | Volúmenes compartidos en clúster | 1 TB |
| Clúster de conmutación por error de Windows Server | Volúmenes compartidos en clúster | 1 TB |
| Windows Server Datacenter de un solo nodo | Almacenamiento conectado directo | 500 GB |
Para un clúster de Azure Stack HCI o Windows Server, hay dos configuraciones de almacenamiento admitidas para ejecutar cargas de trabajo de máquina virtual:
- El almacenamiento híbrido equilibra el rendimiento y la capacidad mediante almacenamiento flash y unidades de disco duro (HDD).
- El almacenamiento All-Flash maximiza el rendimiento mediante unidades de estado sólido (SSD) o NVMe.
Los sistemas que solo tienen almacenamiento basado en HDD no son compatibles con Azure Stack HCI, por lo que no son recomendables para ejecutar AKS en Azure Stack HCI y Windows Server. Para más información sobre las configuraciones de unidad recomendadas, consulte la documentación de Azure Stack HCI. Todos los sistemas validados en el catálogo de Azure Stack HCI se dividen en una de estas dos configuraciones de almacenamiento admitidas.
Kubernetes usa etcd para almacenar el estado de los clústeres. Etcd almacena la configuración, las especificaciones y el estado de los pods en ejecución. Además, Kubernetes usa el almacén para la detección de servicios. Como componente de coordinación para el funcionamiento de Kubernetes y las cargas de trabajo que admite, la latencia y el rendimiento de etcd son fundamentales. Debe ejecutar AKS en una unidad de estado sólido. Para obtener más información, consulte Rendimiento en etcd.io.
En el caso de un clúster basado en Windows Server Datacenter, puede implementarlo con almacenamiento local o basado en SAN. Para el almacenamiento local, se recomienda usar el Espacios de almacenamiento directo integrado o una solución SAN virtual certificada equivalente para crear una infraestructura hiperconvergida que presente volúmenes compartidos de clúster para su uso por cargas de trabajo. Para Espacios de almacenamiento directo, es necesario que el almacenamiento sea híbrido (flash + HDD), que equilibre el rendimiento y la capacidad; u all-flash (SSD, NVMe), que maximice el rendimiento. Si decide implementar con el almacenamiento basado en SAN, asegúrese de que el almacenamiento SAN puede ofrecer suficiente rendimiento para ejecutar varias cargas de trabajo de máquinas virtuales. Es posible que el almacenamiento SAN basado en HDD anterior no ofrezca los niveles de rendimiento necesarios para ejecutar varias cargas de trabajo de máquina virtual y es posible que vea problemas de rendimiento y tiempos de espera.
En el caso de las implementaciones de Windows Server de un solo nodo mediante el almacenamiento local, se recomienda encarecidamente el uso del almacenamiento all-flash (SSD, NVMe) a fin de ofrecer el rendimiento necesario para hospedar varias máquinas virtuales en un único host físico. Sin almacenamiento flash, los niveles más bajos de rendimiento en hdD pueden provocar problemas de implementación y tiempos de espera.
Requisitos de red
Los siguientes requisitos se aplican a un clúster de Azure Stack HCI 22H2 y a un clúster de Windows Server Datacenter. Para conocer los requisitos de red en Azure Stack HCI 23H2, consulte Requisitos de redes.
- Para Azure Stack HCI 22H2 y Windows Server, compruebe que tiene un conmutador virtual externo existente configurado si usa Windows Admin Center. En el caso de los clústeres de HCI o Windows Server, este modificador y su nombre deben ser los mismos en todos los nodos del clúster. Para HCI 23H2, consulte los requisitos del sistema de red.
- Compruebe que ha deshabilitado IPv6 en todos los adaptadores de red.
- Para una implementación correcta, los nodos de clúster de Azure Stack HCI o Windows Server y las máquinas virtuales de clúster de Kubernetes deben tener conectividad externa a Internet.
- Asegúrese de que todas las subredes que defina para el clúster se pueden enrutar entre sí e Internet.
- Asegúrese de que haya conectividad de red entre los hosts de Azure Stack HCI y las máquinas virtuales de inquilino.
- La resolución de nombres DNS es necesaria para que todos los nodos puedan comunicarse entre sí.
- (Recomendado) Habilite las actualizaciones dinámicas de DNS en el entorno DNS para permitir que AKS registre el nombre de clúster genérico del agente en la nube en el sistema DNS para la detección.
Asignación de dirección IP
En AKS habilitado por Arc, las redes virtuales se usan para asignar direcciones IP a los recursos de Kubernetes que los requieren, como se ha indicado anteriormente. Hay dos modelos de red entre los que elegir, en función de la arquitectura de red de AKS deseada.
Nota
La arquitectura de red virtual definida aquí para las implementaciones de AKS es diferente de la arquitectura de red física subyacente en el centro de datos.
- Redes IP estáticas: la red virtual asigna direcciones IP estáticas al servidor de API del clúster de Kubernetes, los nodos de Kubernetes, las máquinas virtuales subyacentes, los equilibradores de carga y los servicios de Kubernetes que se ejecutan sobre el clúster.
- Redes DHCP: la red virtual asigna direcciones IP dinámicas a los nodos de Kubernetes, las máquinas virtuales subyacentes y los equilibradores de carga mediante un servidor DHCP. Al servidor de API del clúster de Kubernetes y los servicios de Kubernetes que se ejecutan en el clúster se les siguen asignando direcciones IP estáticas.
Reserva mínima de direcciones IP
Como mínimo, debe reservar el siguiente número de direcciones IP para la implementación:
| Tipo de clúster | Nodo del plano de control | Nodo de trabajo | Para las operaciones de actualización | Equilibrador de carga |
|---|---|---|---|---|
| Host de AKS | 1 dirección IP | N/D | 2 direcciones IP | N/D |
| Clúster de carga de trabajo | 1 dirección IP por nodo | 1 dirección IP por nodo | 5 direcciones IP | 1 dirección IP |
Además, debe reservar el siguiente número de direcciones IP para el grupo de direcciones VIP:
| Tipo de recurso | Número de direcciones IP |
|---|---|
| Servidor de API del clúster | 1 por clúster |
| Servicios de Kubernetes | 1 por servicio |
Como puede ver, el número de direcciones IP necesarias es variable en función de la arquitectura de AKS y del número de servicios que se ejecutan en el clúster de Kubernetes. Se recomienda reservar un total de 256 direcciones IP (subred /24) para la implementación.
Para más información sobre los requisitos de red, consulte conceptos de redes de nodo en AKS y conceptos de redes de contenedores en AKS.
Requisitos de puerto de red y de dirección URL
AKS habilitado por los requisitos de Arc
Al crear un clúster de Kubernetes en Azure Stack HCI, los siguientes puertos de firewall se abren automáticamente en cada servidor del clúster.
Si los nodos de clúster físico de Azure Stack HCI y las máquinas virtuales del clúster de Azure Kubernetes están en dos vlan aisladas, estos puertos se deben abrir en el firewall entre ellos:
| Puerto | Source | Descripción | Notas del firewall |
|---|---|---|---|
| 22 | Máquinas virtuales de AKS | Necesario para recopilar registros al usar Get-AksHciLogs. |
Si usa VLAN independientes, los hosts físicos de Hyper-V deben acceder a las máquinas virtuales de AKS en este puerto. |
| 6443 | Máquinas virtuales de AKS | Necesario para comunicarse con las API de Kubernetes. | Si usa VLAN independientes, los hosts físicos de Hyper-V deben acceder a las máquinas virtuales de AKS en este puerto. |
| 45000 | Hosts físico de Hyper-V | servidor gRPC de wssdAgent. | No se necesitan reglas entre VLAN. |
| 45001 | Hosts físico de Hyper-V | Autenticación gRPC de wssdAgent. | No se necesitan reglas entre VLAN. |
| 46000 | Máquinas virtuales de AKS | wssdCloudAgent a lbagent. | Si usa VLAN independientes, los hosts físicos de Hyper-V deben acceder a las máquinas virtuales de AKS en este puerto. |
| 55 000 | Recurso de clúster (-CloudServiceCIDR) | Servidor gRPC del Agente en la nube. | Si usa VLAN independientes, las máquinas virtuales de AKS deben acceder a la dirección IP del recurso de clúster en este puerto. |
| 65000 | Recurso de clúster (-CloudServiceCIDR) | Autenticación gRPC del agente en la nube. | Si usa VLAN independientes, las máquinas virtuales de AKS deben acceder a la dirección IP del recurso de clúster en este puerto. |
Si la red requiere el uso de un servidor proxy para conectarse a Internet, consulte Uso de la configuración del servidor proxy en AKS.
Se deben agregar las siguientes direcciones URL a la lista de permitidos:
| URL | Port | Notas |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Se usa al descargar el catálogo de productos, los bits de productos y las imágenes de sistema operativo de AKS en Azure Stack HCI desde SFS. Se produce cuando se ejecuta Set-AksHciConfig y en cualquier momento se descarga desde SFS. |
| msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com | 80 | Se usa al descargar el catálogo de productos, los bits de productos y las imágenes de sistema operativo de AKS en Azure Stack HCI desde SFS. Se produce cuando se ejecuta Set-AksHciConfig y en cualquier momento se descarga desde SFS. |
| login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net | 443 | Se usa para iniciar sesión en Azure cuando se ejecuta Set-AksHciRegistration. |
| ecpacr.azurecr.io mcr.microsoft.com punto de conexión *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net de EE. UU.: wus2replica*.blob.core.windows.net | 443 | Se requiere para extraer imágenes de contenedor al ejecutar Install-AksHci. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | Necesario para incorporar clústeres híbridos de AKS a Azure Arc. |
| gbl.his.arc.azure.com | 443 | Necesario para obtener el punto de conexión regional para extraer los certificados de la identidad administrada asignada por el sistema. |
| *.his.arc.azure.com | 443 | Necesario para extraer certificados de identidad administrados que haya asignado el sistema. |
| k8connecthelm.azureedge.net | 443 | Kubernetes habilitado para Arc usa Helm 3 para implementar agentes de Azure Arc en el clúster de administración de AKS-HCI. Este punto de conexión es necesario para la descarga del cliente de Helm para facilitar la implementación del gráfico de Helm del agente. |
| *.arc.azure.net | 443 | Necesario para administrar clústeres híbridos de AKS en Azure Portal. |
| dl.k8s.io | 443 | Necesario para descargar y actualizar archivos binarios de Kubernetes para Azure Arc. |
| akshci.azurefd.net | 443 | Se requiere para la facturación de AKS en Azure Stack HCI al ejecutar Install-AksHci. |
| v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net | 443 | Se usa periódicamente para enviar datos de diagnóstico necesarios de Microsoft desde el host de Azure Stack HCI o Windows Server. |
Nota
AKS habilitado por Arc almacena y procesa los datos de los clientes. De forma predeterminada, los datos del cliente permanecen dentro de la región en la que el cliente implementa la instancia de servicio. Estos datos se almacenan en centros de datos operados por Microsoft regionales. En el caso de las regiones con requisitos de residencia de datos, los datos del cliente siempre se mantienen dentro de la misma región.
Requisitos adicionales de dirección URL para las características de Azure Arc
En la lista de direcciones URL anteriores se tratan las direcciones URL mínimas necesarias para que conecte el servicio de AKS a Azure para la facturación. Debe permitir direcciones URL adicionales si desea usar la conexión de clústeres, ubicaciones personalizadas, RBAC de Azure y otros servicios de Azure, como Azure Monitor, etc., en el clúster de cargas de trabajo de AKS. Para obtener una lista completa de las direcciones URL de Arc, consulte Requisitos de red de Kubernetes habilitados para Azure Arc.
También debe revisar las direcciones URL de Azure Stack HCI. Dado que Arc para agentes de servidor ahora está instalado de forma predeterminada en los nodos de Azure Stack HCI desde Azure Stack HCI 21H2 y versiones posteriores, también debe revisar las direcciones URL de Arc para agentes de servidor.
Clústeres extendidos en AKS
Como se describe en la introducción a los clústeres extendidos, no se admite la implementación de AKS en Azure Stack HCI y Windows Server mediante clústeres extendidos de Windows. Se recomienda usar un enfoque de copia de seguridad y recuperación ante desastres para la continuidad operativa del centro de datos. Para más información, consulte Realización de copias de seguridad o restauración del clúster de cargas de trabajo mediante Velero y Azure Blob Storage en Azure Stack HCI y Windows Server, e Implementación de configuraciones en AksHci mediante GitOps con Flux v2 para la continuidad de la aplicación.
Requisitos de Windows Admin Center
Windows Admin Center es la interfaz de usuario para crear y administrar AKS habilitado por Azure Arc. Para usar Windows Admin Center con AKS en Azure Stack HCI y Windows Server, debe cumplir todos los criterios de la lista siguiente.
Estos son los requisitos de la máquina que ejecuta la puerta de enlace de Windows Admin Center:
- Windows 10 o Windows Server.
- Registrado con Azure.
- En el mismo dominio que el clúster de Azure Stack HCI o Windows Server Datacenter.
- Una suscripción de Azure en la que tiene derechos de propietario. Para comprobar el nivel de acceso, vaya a la suscripción y seleccione Control de acceso (IAM) en el lado izquierdo de la Azure Portal y, a continuación, seleccione Ver mi acceso.
Requisitos de Azure
Debe conectarse a su cuenta de Azure.
Cuenta y suscripción de Azure
Si aún no tiene una cuenta de Azure, cree una. Puede usar una suscripción existente de cualquier tipo:
- Cuenta gratuita con créditos de Azure para estudiantes o suscriptores de Visual Studio.
- Suscripción de pago por uso con tarjeta de crédito.
- Suscripción obtenida a través de un Contrato Enterprise (EA).
- Suscripción obtenida a través del programa Proveedor de soluciones en la nube (CSP).
permisos de Microsoft Entra, rol y nivel de acceso
Debe tener permisos suficientes para registrar una aplicación con el inquilino de Microsoft Entra.
Para comprobar que tiene permisos suficientes, haga lo siguiente:
- Vaya a la Azure Portal y seleccione Roles y administradores en Microsoft Entra ID para comprobar el rol.
- Si tiene el rol Usuario, debe asegurarse de que los no administradores pueden registrar aplicaciones.
- Para comprobar si puede registrar aplicaciones, vaya a Configuración del usuario en el servicio Microsoft Entra para comprobar si tiene permiso para registrar una aplicación.
Si la configuración de registros de aplicaciones está establecida en No, solo los usuarios con un rol de administrador pueden registrar estos tipos de aplicaciones. Para obtener información sobre los roles de administrador disponibles y los permisos específicos de Microsoft Entra ID que se proporcionan a cada rol, consulte Microsoft Entra roles integrados. Si la cuenta está asignada al rol Usuario, pero la opción Registros de aplicaciones está limitada a los administradores, pida al administrador que le asigne un rol de administrador para poder crear y administrar todos los aspectos de los registros de aplicaciones, o que permita a los usuarios registrar las aplicaciones.
Si no tiene permisos suficientes para registrar una aplicación y el administrador no puede conceder estos permisos, la manera más fácil de implementar AKS es pedir a su administrador de Azure que cree una entidad de servicio con los permisos adecuados. Los administradores pueden consultar la sección siguiente para aprender a crear una entidad de servicio.
Nivel de acceso y rol de suscripción de Azure
Para comprobar el nivel de acceso, vaya a su suscripción, seleccione Control de acceso (IAM) en el lado izquierdo de Azure Portal y, a continuación, seleccione View my access (Ver mi acceso).
- Si usa Windows Admin Center para implementar un host de AKS o un clúster de cargas de trabajo de AKS, debe tener una suscripción de Azure en la que sea propietario.
- Si usa PowerShell para implementar un host de AKS o un clúster de cargas de trabajo de AKS, el usuario que registra el clúster debe tener al menos una de las siguientes opciones:
- Una cuenta de usuario con el rol Propietario integrado.
- Una entidad de servicio con uno de los siguientes niveles de acceso:
- Rol colaborador integrado.
- Rol de propietario integrado.
Si la suscripción de Azure se realiza a través de un Contrato Enterprise o CSP, la manera más fácil de implementar AKS es pedir al administrador de Azure que cree una entidad de servicio con los permisos adecuados. Los administradores pueden comprobar la siguiente sección sobre cómo crear una entidad de servicio.
Opcional: crear una nueva entidad de servicio
Ejecute los pasos siguientes para crear una nueva entidad de servicio con el rol propietario integrado. Solo los propietarios de suscripciones pueden crear entidades de servicio con la asignación de roles adecuada. Para comprobar el nivel de acceso, vaya a la suscripción, seleccione Control de acceso (IAM) en el lado izquierdo de la Azure Portal y, a continuación, seleccione Ver mi acceso.
Establezca las siguientes variables de PowerShell en una ventana de administración de PowerShell. Compruebe que la suscripción y el inquilino son lo que desea usar para registrar el host de AKS para la facturación:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Instale e importe el módulo de PowerShell de AKS:
Install-Module -Name AksHci
Inicie sesión en Azure con el comando Connect-AzAccount de PowerShell:
Connect-AzAccount -tenant $tenantID
Establezca la suscripción que desea usar para registrar el host de AKS para la facturación como suscripción predeterminada ejecutando el comando Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Ejecute el comando Get-AzContext de PowerShell para comprobar que el contexto de inicio de sesión es correcto. Compruebe que la suscripción, el inquilino y la cuenta son lo que desea usar para registrar el host de AKS para la facturación:
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Cree una entidad de servicio mediante la ejecución del comando New-AzADServicePrincipal de PowerShell. Este comando crea una entidad de servicio con el rol Propietario y establece el ámbito en un nivel de suscripción. Para más información sobre cómo crear entidades de servicio, consulte Creación de una entidad de servicio de Azure con Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Para recuperar la contraseña de la entidad de servicio, ejecute el siguiente comando. Tenga en cuenta que este comando solo funciona para Az.Accounts 2.6.0 o inferior. Descargamos automáticamente el módulo Az.Accounts 2.6.0 al instalar el módulo de PowerShell de AksHci:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
En la salida anterior, ahora tiene el identificador de aplicación y el secreto disponibles al implementar AKS. Debe anotar estos elementos y almacenarlos de forma segura. Con eso creado, en el Azure Portal, en Suscripciones, Access Control y, a continuación, Asignaciones de roles, debería ver la nueva entidad de servicio.
Grupo de recursos de Azure
Antes del registro, debe tener un grupo de recursos de Azure disponible en la región Este de Australia, Este de EE. UU., Sudeste de Asia u Oeste de Europa de Azure.
Regiones de Azure
Advertencia
AKS Arc admite actualmente la creación de clústeres exclusivamente dentro de las siguientes regiones de Azure especificadas. Si intenta realizar la implementación en una región fuera de esta lista, se produce un error de implementación.
El servicio AKS Arc se usa para el registro, la facturación y la administración. Actualmente se admite en las siguientes regiones:
- Este de EE. UU.
- Centro-sur de EE. UU.
- Oeste de Europa
requisitos de Active Directory
Para que un clúster de conmutación por error de AKS con dos o más nodos físicos funcionen de forma óptima en un entorno de Active Directory, asegúrese de que se cumplen los siguientes requisitos:
Nota
Active Directory no es necesario para las implementaciones de Azure Stack HCI o Windows Server de un solo nodo.
- Configure la sincronización de hora para que la divergencia no supere los 2 minutos en todos los nodos del clúster y en el controlador de dominio. Para obtener información sobre cómo establecer la sincronización de hora, consulte Servicio de hora de Windows.
- Asegúrese de que las cuentas de usuario usadas para agregar actualizaciones y administrar clústeres de AKS o Windows Server Datacenter tienen los permisos correctos en Active Directory. Si usa unidades organizativas (UO) para administrar directivas de grupo para servidores y servicios, las cuentas de usuario requieren permisos de lista, lectura, modificación y eliminación en todos los objetos de la unidad organizativa.
- Use una unidad organizativa (OU) independiente para los servidores y servicios de los clústeres de AKS o Windows Server Datacenter. El uso de una unidad organizativa independiente le permitirá controlar el acceso y los permisos con mayor precisión.
- Si usa plantillas de GPO en contenedores de Active Directory, asegúrese de que la implementación de AKS en Azure Stack HCI y Windows Server esté exenta de la directiva.
Pasos siguientes
Después de haber cumplido todos los requisitos previos anteriores, puede configurar un host de AKS en Azure Stack HCI mediante:
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de