Compartir a través de


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 ga. 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:

  1. 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.
  2. 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.
  3. Supervisar la instancia de Azure Kubernetes Service y actuar sobre cualquier alerta y corrección asociada.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Área Característica AKS en Azure AKS en Azure Stack Hub
Seguridad de acceso
RBAC de Kubernetes
Integración en Security Center
Microsoft Entra autenticación/RBAC No
Directiva de red de Calico No
Supervisión del registro de &
Supervisión integrada de Azure (Insights, registros, métricas, alertas) No
Supervisión y corrección de nodos maestros
Métricas del clúster
Recomendaciones de Advisor No
Configuración de diagnóstico
Registros del plano de control de Kubernetes
Workbooks No
Clústeres & nodos
Escalado automático de nodos (escalador automático) No
Escalado de nodos dirigido
Escalado automático de pods
Pods habilitados para GPU No
Compatibilidad con volúmenes de almacenamiento
Administración de grupo de varios nodos No
Integración de Azure Container Instance & nodo virtual No
Acuerdo de Nivel de Servicio de tiempo de actividad No
Nodos maestros ocultos No
Redes virtuales y entrada
Red virtual predeterminada
Red virtual personalizada
Entrada HTTP No
Herramientas de desarrollo
Helm
Estudio de desarrollo No
DevOps Starter No
Compatibilidad con imágenes de Docker y registro de contenedor privado
Certificaciones
Certificado por CNCF
Administración del ciclo de vida del clúster
Experiencia de usuario de AKS
CLI de AKS (Windows y Linux)
API de AKS
Plantillas de AKS
PowerShell de AKS 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 los 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 los 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 identificador 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 Active Directory Federated Services (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.

  1. Para obtener información sobre cómo conectarse a Azure Stack Hub mediante Microsoft Entra identificador o identidades de AD FS mediante PowerShell, consulte Conexión a Azure Stack Hub con PowerShell como usuario.

  2. Use esta para conectarse mediante la CLI de Azure con Microsoft Entra identificador o 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 el equilibrador de carga básico; esto 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.

Las entidades de servicio se pueden proporcionar mediante el identificador de Microsoft Entra o AD FS.

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 para Microsoft Entra identificador, 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:

Pasos siguientes

Aprenda a usar AKS en Azure Stack Hub