Información general para los usuarios sobre Azure Kubernetes Service en Azure Stack Hub
Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes en Azure y Azure Stack Hub. AKS reduce la complejidad y la sobrecarga operativa de la administración de clústeres de Kubernetes.
Como servicio de Kubernetes administrado, Azure Stack Hub controla tareas críticas como la supervisión de estado y facilita el mantenimiento. El equipo de Azure Stack administra la imagen que se usa para mantener los clústeres. El administrador del clúster solo tendrá que aplicar las actualizaciones según sea necesario. Los servicios no tienen ningún costo adicional. AKS es gratuito: solo paga por usar las máquinas virtuales (nodos maestros y de agente) de los clústeres. Es más fácil de usar que el motor de AKS, ya que elimina algunas de las tareas manuales necesarias con el motor de AKS.
Importante
Azure Kubernetes Service en Azure Stack Hub, actualmente en versión preliminar, se está descontinuando y no se convertirá en disponibilidad general. Consulte AKS Engine for a Kubernetes solution on Azure Stack Hub (Motor de AKS para obtener una solución de Kubernetes en Azure Stack Hub). Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
AKS en Azure Stack Hub
Puede administrar clústeres de AKS en Azure Stack Hub de la misma manera que en la nube de Azure mediante la misma CLI de Azure, el portal de usuarios de Azure Stack Hub, las plantillas de Azure Resource Manager y la API REST. Al implementar un clúster de AKS, el maestro y todos los nodos de Kubernetes se implementan y configuran automáticamente.
Para más información sobre los conceptos de Kubernetes, consulte la documentación de Kubernetes. Para obtener una documentación completa del servicio AKS en Azure global, consulte los documentos en Azure Kubernetes Service.
Roles y responsabilidades del usuario
Azure Stack Hub es un sistema local que los clientes pueden usar dentro de sus centros de datos para ejecutar sus cargas de trabajo nativas de nube. Estos sistemas admiten dos tipos de usuario: el operador de la nube y el usuario.
Las siguientes tareas recaen en el operador de Azure Stack Hub:
- Asegurarse de que las imágenes base de Azure Kubernetes Service estén disponibles en la instancia de Azure Stack Hub, lo que incluye descargarlas de Azure.
- Asegurarse de que la instancia de Azure Kubernetes Service esté disponible para planes de clientes y suscripciones de usuario, como es el caso en cualquier otro servicio de Azure Stack Hub.
- Supervisar la instancia de Azure Kubernetes Service y actuar sobre cualquier alerta y corrección asociada.
- Para más información sobre las tareas del operador, consulte Instalación y oferta de Azure Kubernetes Service en Azure Stack Hub.
Las siguientes tareas corresponden al usuario, es decir, al administrador del clúster de AKS del inquilino:
- Supervisar el estado de los agentes de clúster de Kubernetes y actuar sobre cualquier evento y corrección asociada. Aunque los maestros se crean dentro de la suscripción del inquilino, el servicio supervisará su estado y realizará los pasos de corrección según sea necesario. Sin embargo, puede haber escenarios de compatibilidad en los que sea necesario el administrador del clúster del inquilino para devolver el clúster a un estado correcto.
- Usar las utilidades de Azure Kubernetes Service para administrar el ciclo de vida del clúster, es decir, las operaciones de creación, actualización y escalado.
- Operaciones de mantenimiento: implementación de aplicaciones, copia de seguridad y restauración, solución de problemas, recopilación de registros y aplicaciones de supervisión.
- Para más información sobre las tareas del inquilino, consulte Uso de Azure Kubernetes Service en Azure Stack Hub con la CLI.
Comparación de características
En la tabla siguiente, se proporciona información general sobre las características de AKS en Azure global en comparación con las características en Azure Stack Hub.
| Áreas | Característica | Azure AKS | AKS en Azure Stack Hub |
|---|---|---|---|
| Seguridad de acceso | |||
| RBAC de Kubernetes | Sí | Sí | |
| Integración en Security Center | Sí | Sí | |
| Microsoft Entra auth/RBAC | Sí | No | |
| Directiva de red de Calico | Sí | No | |
| Supervisión y registro | |||
| Supervisión integrada de Azure (Insights, registros, métricas, alertas) | Sí | No | |
| Supervisión y corrección de nodos maestros | Sí | Sí | |
| Métricas del clúster | Sí | Sí | |
| Recomendaciones de Advisor | Sí | No | |
| Configuración de diagnóstico | Sí | Sí | |
| Registros del plano de control de Kubernetes | Sí | Sí | |
| Libros | Sí | No | |
| Clústeres y nodos | |||
| Escalado automático de nodos (escalador automático) | Sí | No | |
| Escalado de nodos dirigido | Sí | Sí | |
| Escalado automático de pods | Sí | Sí | |
| Pods habilitados para GPU | Sí | No | |
| Compatibilidad con volúmenes de almacenamiento | Sí | Sí | |
| Administración de grupo de varios nodos | Sí | No | |
| Integración y nodo virtual de Azure Container Instance | Sí | No | |
| SLA de tiempo de actividad | Sí | No | |
| Nodos maestros ocultos | Sí | No | |
| Redes virtuales y entrada | |||
| Red virtual predeterminada | Sí | Sí | |
| Red virtual personalizada | Sí | Sí | |
| Entrada HTTP | Sí | No | |
| Herramientas de desarrollo | |||
| Helm | Sí | Sí | |
| Estudio de desarrollo | Sí | No | |
| DevOps Starter | Sí | No | |
| Compatibilidad con imágenes de Docker y registro de contenedor privado | Sí | Sí | |
| Certificaciones | |||
| Certificado por CNCF | Sí | Sí | |
| Administración del ciclo de vida del clúster | |||
| Experiencia de usuario de AKS | Sí | Sí | |
| CLI de AKS (Windows y Linux) | Sí | Sí | |
| API de AKS | Sí | Sí | |
| Plantillas de AKS | Sí | Sí | |
| PowerShell de AKS | Sí | No |
Diferencias entre Azure y Azure Stack Hub
AKS en Azure y en Azure Stack Hub comparten el mismo repositorio de origen. No hay diferencias conceptuales entre los dos. Sin embargo, el funcionamiento en entornos diferentes aporta diferencias que hay que tener en cuenta al usar AKS en Azure Stack Hub. La mayoría de las diferencias están relacionadas con que el sistema reside dentro de los centros de datos de los clientes y también están relacionadas con alguna funcionalidad que aún no está disponible en Azure Stack Hub.
Azure Stack Hub conectado o desconectado en el centro de datos del cliente
En ambos escenarios, Azure Stack Hub está bajo el control del cliente. Además, los clientes pueden implementar Azure Stack Hub en un entorno completamente desconectado y aislado. Es posible que desee tener en cuenta los siguientes factores:
- Para operadores:
- Deben asegurarse de que el servicio AKS y las imágenes correspondientes estén disponibles para los inquilinos.
- Deben asociarse con inquilinos y Soporte técnico de Microsoft al resolver incidentes de soporte técnico (por ejemplo, recopilar los registros del stamp). Consulte el artículo sobre el operador para más detalles.
- Para inquilinos:
- Deben colaborar con el operador del stamp para solicitar imágenes base de AKS o si el servicio AKS no está disponible en el stamp.
- También deben colaborar con el operador y Soporte técnico de Microsoft durante los casos de soporte técnico. Una tarea sería la recopilación de registros relacionados con el clúster de AKS con la información proporcionada aquí.
Conexión a Azure Stack Hub mediante la CLI o PowerShell
Cuando se usa la CLI de Azure para conectarse a Azure, el binario de la CLI usará de forma predeterminada microsoft Entra ID para la autenticación y el punto de conexión global de Azure Resource Manager para las API. También puede usar la CLI de Azure con Azure Stack Hub. Sin embargo, deberá conectarse explícitamente al punto de conexión de Azure Resource Manager de Azure Stack Hub y usar Microsoft Entra ID o Servicios federados de Active Directory (AD FS) para la autenticación. El motivo es que Azure Stack Hub está diseñado para trabajar dentro de las empresas y pueden elegir AD FS en escenarios desconectados.
Para obtener información sobre cómo conectarse a Azure Stack Hub mediante microsoft Entra ID o identidades de AD FS mediante PowerShell, consulte Conexión a Azure Stack Hub con PowerShell como usuario.
Use este para conectarse mediante la CLI de Azure con el identificador de Microsoft Entra o las identidades de AD FS.
Características admitidas de la plataforma
Azure Stack Hub admite un subconjunto de las características disponibles en Azure global. Tenga en cuenta las siguientes diferencias:
- Sin Standard Load Balancer. Azure Stack Hub solo admite equilibrador de carga básico, lo que implica que las siguientes características, que dependen de Standard Load Balancer aún no están disponibles con AKS en Azure Stack Hub:
- Sin parámetro api-server-authorized-ip-ranges </azure/aks/api-server-authorized-ip-ranges>
- Sin parámetro load-balancer-managed-ip-count /azure/aks/load-balancer-standard#scale-the-number-of-managed-outbound-public-ips
- Sin parámetro enable-private-cluster </azure/aks/private-clusters>
- Sin escalador automático del clúster: </azure/aks/cluster-autoscaler>
- Sin parámetro enable-cluster-autoscaler
- az aks update no está disponible.
- No hay compatibilidad con varios grupos de nodos. Los comandos del grupo de nodos no están disponibles.
- La compatibilidad de la interfaz de usuario con las operaciones de varios grupos de nodos no está habilitada.
- No hay regiones de Azure ni zonas de disponibilidad
- Sin conjuntos de disponibilidad, solo conjuntos de escalado de máquinas virtuales
- Revise la lista de comandos para ver los comandos admitidos y no admitidos.
Servicios admitidos
La ausencia de algunos servicios de Azure limita algunas opciones de funcionalidad en AKS en Azure Stack Hub:
- No hay servicio Azure Files. Esto hace que no haya compatibilidad con volúmenes basados en el servicio Files en Kubernetes en Azure Stack Hub.
- Sin Azure Log Analytics ni Azure Container Monitor. Cualquier clúster de Kubernetes se puede conectar a Azure Container Monitor siempre que esté conectado a Internet; si está desconectado, no hay ningún servicio equivalente de forma local en Azure Stack Hub. Por lo tanto, no hay compatibilidad integrada con Azure Container Monitor en AKS en Azure Stack Hub.
- Sin Azure DevOps. Puesto que este servicio no está disponible para una instancia desconectada de Azure Stack Hub, no hay compatibilidad integrada para él.
Versiones admitidas de la API de AKS y Kubernetes
A menudo se da el caso de que AKS en Azure Stack Hub se retrasa con respecto a Azure en las versiones admitidas para Kubernetes y la API de AKS. Esto se debe a las dificultades del envío de código para que los clientes lo ejecuten en sus propios centros de datos.
Valores predeterminados de los parámetros de la CLI de AKS en Azure que se deben cambiar al usar la CLI de AKS en Azure Stack Hub
Dadas las diferencias entre las dos plataformas descritas anteriormente, el usuario debe tener en cuenta que algunos valores predeterminados de los parámetros de los comandos y la API que funcionan en AKS en Azure no funcionan en AKS en Azure Stack Hub. Por ejemplo:
| Parámetros comunes | Notas |
|---|---|
--service-principal --client-secret |
Azure Stack Hub no admite aún identidades administradas; siempre se necesitan credenciales de entidad de servicio. |
--load-balancer-sku basic |
Azure Stack Hub aún no admite Standard Load Balancer (SLB). |
--location |
El valor de ubicación es específico del elegido por el cliente. |
Microsoft Entra ID o AD FS pueden proporcionar entidades de servicio
Las entidades de servicio (SPN) son un requisito para crear y administrar un clúster de AKS. Dado que Azure Stack Hub se puede implementar en modo desconectado de Internet, debe tener disponible un administrador de identidades alternativo a Microsoft Entra ID, por lo que se usa Active Directory Federated Services (AD FS). Aquí se documenta cómo crean los SPN los inquilinos de Azure Stack Hub: