Arquitectura y cargas de trabajo de clúster de Kubernetes para AKS habilitados por Azure Arc

Artículo
01/11/2024

Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server

Azure Kubernetes Service (AKS) en Azure Stack HCI y Windows Server es una plataforma de contenedores de Kubernetes de nivel empresarial con tecnología de Azure Stack HCI. Incluye una instancia de Kubernetes principal compatible con Microsoft, un host de contenedores creado específicamente para Windows y un host de contenedores de Linux compatible con Microsoft, con el fin 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 de Kubernetes

Kubernetes es el componente principal de AKS habilitado por Azure Arc. AKS usa un conjunto de configuraciones predefinidas para implementar clústeres de Kubernetes de forma eficaz y con escalabilidad en mente.

La operación de implementación crea varias máquinas virtuales Linux o Windows y las une para crear 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. Esto solo se aplica a las instalaciones nuevas (no a las actualizaciones).

El sistema implementado está listo para recibir cargas de trabajo estándar de Kubernetes, escalar estas cargas de trabajo, o incluso escalar o reducir verticalmente el número de máquinas virtuales y de clústeres, según sea necesario.

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

El clúster de administración (conocido también como host de AKS) proporciona el mecanismo de orquestación principal y la interfaz para implementar y administrar uno o más clústeres de carga de trabajo.
Los clústeres de carga de trabajo (también conocidos como clústeres de destino) son el lugar donde se implementan las aplicaciones en contenedores.

Administración de AKS habilitado por Arc

Puede administrar AKS mediante las siguientes opciones de administración:

Windows Admin Center ofrece una interfaz de usuario intuitiva para que el operador de Kubernetes administre el ciclo de vida de los clústeres.
Un módulo de PowerShell facilita la descarga, configuración e implementación de AKS. El módulo de PowerShell también admite la implementación y la configuración de otros clústeres de carga de trabajo, así como la reconfiguración de los existentes.

El clúster de administración

Al crear un clúster de Kubernetes, se crea y configura automáticamente un clúster de administración. Este clúster de administración es responsable del aprovisionamiento y la administración de los clústeres de carga de trabajo en los que se ejecutan las cargas de trabajo. Un clúster de administración incluye los siguientes componentes principales de Kubernetes:

Servidor de API: el servidor de API es cómo se exponen las API de Kubernetes subyacentes. Este componente proporciona la interacción a las herramientas de administración como Windows Admin Center, los módulos de PowerShell o kubectl.
Equilibrador de carga: el equilibrador de carga es una sola máquina virtual Linux dedicada con una regla de equilibrio de carga para el servidor de API del clúster de administración.

El clúster de carga 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. Un solo clúster de administración puede administrar uno o varios clústeres de carga de trabajo.

Componentes del clúster de carga de trabajo

El clúster de carga de trabajo tiene muchos componentes, que se describen 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 a las herramientas de administración como Windows Admin Center, los 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 en la que se ejecuta Linux y HAProxy + KeepAlive para proporcionar servicios con equilibrio de carga para los clústeres de carga de trabajo que implementa el clúster de administración. Para cada clúster de carga de trabajo, AKS agrega al menos una máquina virtual del equilibrador de carga. Cualquier servicio de Kubernetes de tipo LoadBalancer que se cree en el clúster de cargas de trabajo crea finalmente una regla de equilibrio de carga en la máquina virtual.

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 los servicios que componen la carga de trabajo de la aplicación.

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

Pods

Kubernetes utiliza pods para ejecutar una instancia de la aplicación. Un pod representa una instancia individual de la aplicación. Normalmente, los pods tienen una asignación 1:1 con un contenedor, aunque hay escenarios avanzados en los que un pod puede contener varios contenedores. Los pods de varios contenedores se programan conjuntamente en el mismo nodo y permiten que los contenedores compartan recursos relacionados. Para obtener más información, consulte Pods de Kubernetes y Ciclo de vida de pods de Kubernetes.

Implementaciones

Una implementación representa uno o varios pods idénticos, administrados por el controlador de implementación de Kubernetes. Una implementación define el número de réplicas (pods ) que se van a crear y el programador de Kubernetes garantiza que si los pods o nodos tienen problemas, se programan pods adicionales en nodos correctos. Para más información, consulte el artículo sobre las implementaciones de Kubernetes.

StatefulSets y DaemonSets

Deployment Controller usa el programador de Kubernetes para ejecutar un número determinado de réplicas en cualquier nodo disponible con recursos disponibles. Este enfoque de uso de implementaciones puede ser suficiente para las aplicaciones sin estado, pero no para las aplicaciones que requieren una convención de nomenclatura persistente o un almacenamiento. Para aplicaciones que requieren que exista una réplica en cada nodo o nodos seleccionados dentro de un clúster, el controlador de implementación no observa el modo en que las réplicas se distribuyen entre los nodos.

StatefulSets: statefulSet es similar a una implementación en la que se crean y administran uno o varios pods idénticos. Las réplicas de StatefulSet siguen un enfoque estable y secuencial para la implementación, el escalado, las actualizaciones y las finalizaciones. Con StatefulSet (a medida que las réplicas se vuelven a programar), la convención de nomenclatura, los nombres de red y el almacenamiento persisten. Las réplicas de statefulSet se programan y se ejecutan en cualquier nodo disponible en un clúster de Kubernetes. Si necesita asegurarse de que al menos un pod del conjunto se ejecuta en un nodo, puede usar un DaemonSet. Para más información, consulte el objeto StatefulSets de Kubernetes.
DaemonSets: para necesidades específicas de recopilación o supervisión de registros, es posible que tenga que ejecutar un pod determinado en todos los nodos o seleccionados. Un DaemonSet se usa de nuevo para implementar uno o varios pods idénticos, pero el controlador DaemonSet garantiza que cada nodo especificado ejecuta una instancia del pod. Para más información, consulte el objeto DaemonSets de Kubernetes.

Espacios de nombres

Los recursos de Kubernetes, como los pods y las implementaciones, se agrupan lógicamente en un espacio de nombres. Estas agrupaciones proporcionan una manera de dividir lógicamente los clústeres de cargas de trabajo y restringir el acceso para crear, ver o administrar recursos. Por ejemplo, puede crear espacios de nombres para separar grupos de negocios. Los usuarios solo pueden interactuar con los recursos dentro de sus espacios de nombres asignados. Para más información, consulte los espacios de nombres de Kubernetes.

Al crear un clúster de Azure Kubernetes Service en AKS habilitado por Arc, están disponibles los siguientes espacios de nombres:

default: un espacio de nombres donde se crean pods e implementaciones de forma predeterminada cuando no se proporciona ninguno. En entornos más pequeños, puede implementar aplicaciones directamente en el espacio de nombres predeterminado sin crear separaciones lógicas adicionales. Al interactuar con la API de Kubernetes, como con kubectl get pods, el espacio de nombres predeterminado se utiliza cuando no se especifica ninguno.
kube-system: un espacio de nombres donde existen recursos principales, como características de red como DNS y proxy, o el panel de Kubernetes. Normalmente, el usuario no implementa sus propias aplicaciones en este espacio de nombres.
kube-public: un espacio de nombres que normalmente no se usa, pero se puede usar para que los recursos sean visibles en todo el clúster y cualquier usuario pueda verlo.

Secretos

Los secretos de Kubernetes permiten almacenar y administrar información confidencial, como contraseñas, tokens de OAuth y claves de Secure Shell (SSH). De forma predeterminada, Kubernetes almacena secretos como cadenas codificadas en base64 sin cifrar y cualquier persona con acceso a la API puede recuperarlos como texto sin formato. Para más información, consulte Secretos de Kubernetes.

Volúmenes persistentes

Un volumen persistente es un recurso de almacenamiento en un clúster de Kubernetes que el administrador ha aprovisionado o que se ha aprovisionado dinámicamente mediante clases de almacenamiento. Para usar volúmenes persistentes, los pods solicitan acceso mediante PersistentVolumeClaim. Para más información, consulte Volúmenes persistentes.

Implementaciones de sistema operativo mixto

Si un clúster de carga de trabajo determinado consta de nodos de trabajo de Linux y Windows, se debe programar en un sistema operativo que admita su aprovisionamiento. 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 intolerancias y tolerancias funcionan conjuntamente para garantizar que los pods no se programan en los nodos de forma involuntaria. Un nodo puede ser "tainted" de modo que no acepte 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

En este artículo, ha obtenido información sobre la arquitectura de clúster de AKS habilitada por Azure Arc y los componentes del clúster de carga de trabajo. Para obtener más información sobre estos conceptos, consulte los siguientes artículos: