Compartir a través de


Arquitectura de AKS en Azure Stack HCI 23H2

Se aplica a: Azure Stack HCI, versión 23H2

Azure Kubernetes Service (AKS) en Azure Stack HCI es una plataforma de contenedor de Kubernetes de nivel empresarial. Incluye Kubernetes principal compatible con Microsoft, un host de contenedor de Windows creado específicamente y un host de contenedor de Linux compatible con Microsoft, con el objetivo de tener una experiencia sencilla de implementación y administración del ciclo de vida.

En este artículo se presentan los componentes centrales de la infraestructura de Kubernetes, como el ​​plano de control, los nodos y los grupos de nodos. También se presentan los recursos de la carga de trabajo, como los pods, las implementaciones y los conjuntos, junto con información acerca de cómo agrupar los recursos en espacios de nombres.

Arquitectura de AKS en Azure Stack HCI

Los clústeres de AKS en Azure Stack HCI usan Arc Resource Bridge (también conocido como dispositivo arc) para proporcionar el mecanismo de orquestación principal y la interfaz para implementar y administrar uno o varios clústeres de AKS. Las aplicaciones en contenedores se implementan en clústeres de AKS.

Diagrama que muestra la arquitectura del clúster.

AKS Arc usa una configuración predefinida para implementar clústeres de Kubernetes de forma eficaz y con escalabilidad en mente. Una operación de implementación crea varias máquinas virtuales Linux o Windows y las une para crear uno o varios clústeres de Kubernetes.

Nota

Para ayudar a mejorar la confiabilidad del sistema, si ejecuta varios volúmenes compartidos de clúster (CSV) en el clúster, los datos de máquina virtual de forma predeterminada se reparten automáticamente entre todos los CSV disponibles en el clúster. Esto garantiza que las aplicaciones sobrevivan en caso de interrupciones de CSV.

Puente de recursos de Arc

Arc Resource Bridge conecta una nube privada (por ejemplo, Azure Stack HCI, VMWare/vSphere o SCVMM) a Azure y habilita la administración de recursos local desde Azure. Azure Arc Resource Bridge proporciona la línea de visión a las nubes privadas necesarias para administrar recursos como clústeres de Kubernetes locales a través de Azure. Arc Resource Bridge incluye los siguientes componentes principales de AKS Arc:

  • Extensiones de clúster de AKS Arc: una extensión de clúster es el equivalente local de un proveedor de recursos de Azure Resource Manager. Al igual que el proveedor de recursos Microsoft.ContainerService administra los clústeres de AKS en Azure, la extensión de clúster de AKS Arc, una vez agregada a Arc Resource Bridge, ayuda a administrar clústeres de Kubernetes a través de Azure.
  • Ubicación personalizada: una ubicación personalizada es el equivalente local de una región de Azure y es una extensión de la construcción de ubicación de Azure. Las ubicaciones personalizadas proporcionan una manera de que los administradores de inquilinos usen su centro de datos con las extensiones adecuadas instaladas, como ubicaciones de destino para implementar instancias de servicio de Azure.

Clústeres de AKS

Los clústeres de AKS son una implementación de alta disponibilidad de Kubernetes mediante máquinas virtuales Linux para ejecutar componentes del plano de control de Kubernetes y grupos de nodos de Linux. Puede implementar grupos de nodos adicionales basados en Windows Server Core para ejecutar contenedores de Windows. Puede haber uno o varios clústeres de AKS administrados por Arc Resource Bridge.

Un clúster de AKS tiene dos componentes principales, como se describe en las secciones siguientes.

Nodos del plano de control

Kubernetes usa nodos del plano de control para asegurarse de que todos los componentes del clúster de Kubernetes se mantienen en el estado deseado. El plano de control también administra y mantiene los grupos de nodos de trabajo que contienen las aplicaciones en contenedor. AKS habilitado por Arc implementa el equilibrador de carga kubeVIP para asegurarse de que la dirección IP del servidor de API del plano de control de Kubernetes está disponible en todo momento. Microsoft no le cobra por los nodos del plano de control, ya que los nodos del plano de control no hospedan aplicaciones de cliente.

Los nodos del plano de control ejecutan los siguientes componentes principales (no una lista exhaustiva):

  • Servidor de API: habilita la interacción con la API de Kubernetes. Este componente proporciona la interacción con las herramientas de administración, como la CLI de Azure, Azure Portal o kubectl.
  • Etcd: un almacén de clave-valor distribuido que almacena los datos necesarios para la administración del ciclo de vida del clúster. Almacena el estado del plano de control.

Grupos de nodos de Linux o Windows

En Kubernetes, un grupo de nodos es un grupo de nodos dentro de un clúster que comparte la misma configuración. Los grupos de nodos permiten crear y administrar conjuntos de nodos que tienen roles, funcionalidades o configuraciones de hardware específicas, lo que permite un control más granular sobre la infraestructura del clúster de AKS. Puede implementar grupos de nodos de Linux o Windows en el clúster de AKS. Sin embargo, debe tener al menos 1 grupo de nodos de Linux para hospedar los agentes de Arc para mantener la conectividad con Azure.

Implementaciones de sistema operativo mixto

Si un clúster de carga de trabajo determinado consta de nodos de trabajo de Linux y Windows, debe programarse en un sistema operativo que pueda admitir el aprovisionamiento de la carga de trabajo. Kubernetes ofrece dos mecanismos para garantizar que las cargas de trabajo se dirijan a nodos con un sistema operativo de destino:

  • El selector de nodos es un campo sencillo en la especificación de pod que restringe los pods para que solo se programe en nodos correctos que coincidan con el sistema operativo.
  • Las taints y tolerations funcionan conjuntamente para asegurarse de que los pods no están programados en los nodos de forma involuntaria. Un nodo puede "tainted" para no aceptar pods que no toleran explícitamente su taint a través de una "tolerancia" en la especificación del pod.

Para más información, consulte selectores de nodo e intolerancias y tolerancias.

Administración del ciclo de vida

Azure Arc se habilita automáticamente en todos los clústeres de Kubernetes creados mediante AKS Arc. Puede usar el identificador de Entra de Microsoft para conectarse a los clústeres desde cualquier lugar. Azure Arc le permite usar herramientas conocidas como Azure Portal, la CLI de Azure y plantillas de Azure Resource Manager para crear y administrar los clústeres de Kubernetes.

Actualizaciones basadas en la nube para componentes de infraestructura

Azure Stack HCI 23H2 consolida todas las actualizaciones pertinentes para el sistema operativo, los agentes de software, la infraestructura de Azure Arc y los controladores y firmware oem en un paquete de actualización mensual unificado. Este paquete de actualización completo se identifica y aplica desde la nube a través de la herramienta Azure Update Manager.

AKS ahora forma parte de Azure Stack HCI a partir de la versión 23H2. La administración del ciclo de vida de AKS habilitada por la infraestructura de Azure Arc sigue el mismo enfoque que cualquier otro componente de Azure Stack HCI 23H2. Este enfoque proporciona una base flexible para integrar y administrar varios aspectos de la solución de Azure Stack HCI en un solo lugar, incluida la administración del sistema operativo, los agentes principales y los servicios, y la extensión de la solución. Los componentes de la infraestructura de Arc habilitados por AKS, como parte de las extensiones de solución, se actualizan mediante el paquete de actualización de Azure Stack HCI 23H2.

Para más información, consulte Introducción a la actualización de Azure Stack HCI, versión 23H2.

Pasos siguientes