Share via


Arquitectura de clúster de AKS Arc y carga de trabajo

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 del clúster

Un clúster de Azure Kubernetes Service tiene los siguientes componentes:

  • Arc Resource Bridge (también conocido como dispositivo arc) proporciona el mecanismo de orquestación principal y la interfaz para implementar y administrar uno o varios clústeres de carga de trabajo.
  • Los clústeres de cargas de trabajo (también conocidos como clústeres de destino) son donde se implementan las aplicaciones en contenedores.

Diagrama que muestra la arquitectura del clúster.

AKS Arc usa un conjunto de configuraciones predefinidas 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 cargas de trabajo

El clúster de carga de trabajo es una implementación de alta disponibilidad de Kubernetes con máquinas virtuales Linux para ejecutar componentes del plano de control de Kubernetes, así como nodos de trabajo de Linux. Las máquinas virtuales basadas en Windows Server Core se usan para establecer nodos de trabajo de Windows. Puede haber uno o varios clústeres de carga de trabajo administrados por un clúster de administración.

Un clúster de cargas de trabajo tiene muchos componentes, como se describe en las secciones siguientes.

Plano de control

  • Servidor de API: el servidor de API permite la interacción con la API de Kubernetes. Este componente proporciona la interacción con las herramientas de administración, como Windows Admin Center, módulos de PowerShell o kubectl.
  • Etcd: Etcd es un almacén distribuido de clave-valor que almacena los datos necesarios para la administración del ciclo de vida del clúster. Almacena el estado del plano de control.

Equilibrador de carga

El equilibrador de carga es una máquina virtual que ejecuta Linux y HAProxy y KeepAlive para proporcionar servicios de carga equilibrada para los clústeres de carga de trabajo implementados por el clúster de administración. Para cada clúster de carga de trabajo, AKS Arc agrega al menos una máquina virtual del equilibrador de carga. Cualquier servicio de Kubernetes de tipo LoadBalancer que se crea en el clúster de carga de trabajo crea una regla de equilibrio de carga en la máquina virtual.

La extensión MetalLB Arc es una herramienta que permite generar direcciones IP externas para sus aplicaciones y servicios. Los clústeres de Kubernetes habilitados para Arc se pueden integrar con MetalLB mediante la Arc Networking extensión k8s. Para obtener información sobre el equilibrio de carga de MetalLB para AKS habilitado por los clústeres de Arc Kubernetes, consulte La introducción a MetalLB para clústeres de Kubernetes.

Nodos de trabajo

Para ejecutar las aplicaciones y los servicios de soporte técnico, necesitará un nodo de Kubernetes. Un clúster de cargas de trabajo de AKS tiene uno o varios nodos de trabajo. Los nodos de trabajo actúan como máquinas virtuales (VM) que ejecutan los componentes del nodo de Kubernetes y hospedan los pods y servicios que componen la carga de trabajo de la aplicación.

Hay componentes principales de carga de trabajo de Kubernetes que puede implementar en clústeres de cargas de trabajo de AKS, como pods e implementaciones.

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 la identidad de Microsoft Entra para conectarse a los clústeres desde cualquier lugar. Azure Arc permite usar herramientas conocidas como las plantillas de Azure Portal, la CLI de Azure y Azure Resource Manager para crear y administrar los clústeres de Kubernetes.

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.

Pasos siguientes