Conceptos de red para implementar nodos de AKS

Artículo
04/27/2023

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

Puede elegir entre dos modelos de asignación de direcciones IP para la arquitectura de red para AKS habilitado por Azure Arc. AKS admite varias opciones de implementación para Azure Kubernetes Service (AKS).

Redes IP estáticas: la red virtual asigna direcciones IP estáticas al servidor de API del clúster de Kubernetes, los nodos de Kubernetes, las máquinas virtuales subyacentes, los equilibradores de carga y los servicios de Kubernetes que se ejecutan sobre el clúster.
Redes DHCP: la red virtual asigna direcciones IP dinámicas a los nodos de Kubernetes, las máquinas virtuales subyacentes y los equilibradores de carga mediante un servidor DHCP. Al servidor de API del clúster de Kubernetes y los servicios de Kubernetes que se ejecutan en el clúster aún se les asignan direcciones IP estáticas.

Nota

La arquitectura de red virtual definida aquí para AKS Arc podría ser diferente de la arquitectura de red física subyacente en un centro de datos.

Grupo de direcciones IP virtuales

Un grupo de direcciones IP virtuales (VIP) es un conjunto de direcciones IP que son obligatorias para cualquier implementación en AKS Arc. El grupo de VIP es un intervalo de direcciones IP reservadas que se usan para asignar direcciones IP al servidor de API del clúster de Kubernetes. Garantiza que siempre se puede acceder a las aplicaciones en los servicios de Kubernetes. Tenga en cuenta que independientemente del modelo de red virtual y el modelo de asignación de direcciones que elija, debe proporcionar un grupo de VIP para la implementación del host de AKS.

El número de direcciones IP del grupo de VIP depende del número de clústeres de carga de trabajo y de los servicios de Kubernetes que tiene pensados para su implementación.

En función del modelo de red, la definición del grupo de VIP difiere de las siguientes maneras:

IP estática: si usa una dirección IP estática, asegúrese de que las direcciones IP virtuales proceden de la misma subred proporcionada.
DHCP: si la red está configurada con DHCP, trabaje con el administrador de red para excluir el intervalo IP del grupo de VIP del ámbito DHCP que se usa para la implementación de AKS en Azure Stack HCI.

Grupo de IP de VM de los nodos de Kubernetes

Los nodos de Kubernetes se implementan como máquinas virtuales especializadas en AKS Arc. AKS asigna direcciones IP a estas máquinas virtuales para habilitar la comunicación entre nodos de Kubernetes.

IP estática: debe especificar un intervalo de grupo de direcciones IP de máquina virtual del nodo de Kubernetes. El número de direcciones IP de este intervalo depende del número total de nodos de Kubernetes que tiene pensado para implementar en el host de AKS y de los clústeres de Kubernetes de cargas de trabajo. Tenga en cuenta que las actualizaciones consumen una a tres direcciones IP adicionales durante la actualización.
DHCP: no es necesario especificar un grupo de máquinas virtuales de nodo de Kubernetes, ya que el servidor DHCP de la red asigna dinámicamente las direcciones IP a los nodos de Kubernetes.

Red virtual con redes IP estáticas (recomendado)

Este modelo de redes crea una red virtual que asigna direcciones IP desde un grupo de direcciones definidas estáticamente a todos los objetos de la implementación. Una ventaja adicional de usar redes IP estáticas es que se garantiza que las implementaciones de larga duración y las cargas de trabajo de aplicación siempre son accesibles.

Especifique los siguientes parámetros al definir una red virtual con configuraciones de IP estáticas:

Importante

Esta versión de AKS no permite ningún cambio en la configuración de red una vez implementado el host de AKS o el clúster de cargas de trabajo. Para cambiar la configuración de red, debe empezar de nuevo quitando los clústeres de carga de trabajo y desinstalando AKS.

Nombre: Nombre de la red virtual.
Prefijo de direcciones: Prefijo de la dirección IP que se va a usar para la subred.
Puerta de enlace: dirección IP de la puerta de enlace predeterminada de la subred.
Servidor DNS: matriz de direcciones IP que apuntan a los servidores DNS que se van a usar para la subred. Se puede proporcionar un mínimo de uno y un máximo de tres servidores.
Grupo de VM de los nodos de Kubernetes: Intervalo continuo de direcciones IP que se usará para las VM de los nodos de Kubernetes.
Grupo de IP virtuales: Intervalo continuo de direcciones IP que se usará para el servidor de API del clúster de Kubernetes y los servicios de Kubernetes.

Nota

El grupo de VIP debe formar parte de la misma subred que el grupo de VM de los nodos de Kubernetes.
Id. de vLAN: identificador de vLAN de la red virtual. Si se omite, la red virtual no se etiqueta.

Red virtual con redes DHCP

Este modelo de redes crea una red virtual que asigna direcciones IP mediante DHCP a todos los objetos de la implementación.

Debe especificar los siguientes parámetros al definir una red virtual con configuraciones de IP estáticas:

Importante

En esta versión de AKS, no es posible cambiar la configuración de red una vez implementado el host de AKS o el clúster de cargas de trabajo. La única manera de cambiar la configuración de red es empezar a trabajar de nuevo mediante la eliminación de los clústeres de carga de trabajo y la desinstalación de AKS.

Nombre: Nombre de la red virtual.
Grupo de IP virtuales: Intervalo continuo de direcciones IP que se usará para el servidor de API del clúster de Kubernetes y los servicios de Kubernetes.

Nota

Las direcciones del grupo de VIP deben estar en la misma subred que el ámbito de DHCP y deben excluirse del ámbito de DHCP para evitar conflictos de direcciones.
Id. de vLAN: identificador de vLAN de la red virtual. Si se omite, la red virtual no se etiqueta.

Servicio Microsoft On-premises Cloud

Microsoft On-premises Cloud (MOC) es la pila de administración que permite administrar en la nube las máquinas virtuales en Azure Stack HCI y los SDDC basados en Windows Server. MOC consta de:

Una única instancia del servicio cloud agent de alta disponibilidad implementado en un clúster. Este agente se ejecuta en cualquier nodo del clúster de Azure Stack HCI o Windows Server y está configurado para conmutar por error a otro nodo.
Una instancia de node agent que se ejecuta en cada nodo físico de Azure Stack HCI.

Para habilitar la comunicación con MOC, debe proporcionar el CIDR de dirección IP que se usará para el servicio. -cloudserviceCIDR es un parámetro del comando Set-AksHciConfig, que se usa para asignar la dirección IP al servicio del agente en la nube y habilitar la alta disponibilidad del servicio del agente en la nube.

La elección de una dirección IP para el servicio MOC depende del modelo de red subyacente que usa la implementación del clúster en Azure Stack HCI o Windows Server.

Nota

La asignación de direcciones IP para el servicio MOC es independiente del modelo de red virtual de Kubernetes. La asignación de direcciones IP depende de la red física subyacente y de las direcciones IP configuradas para los nodos de clúster de Azure Stack HCI o Windows Server en el centro de datos.

Nodos de clúster de Azure Stack HCI y Windows Server con un modo de asignación de direcciones IP basado en DHCP: si a los nodos de Azure Stack HCI se les asigna una dirección IP desde un servidor DHCP presente en la red física, no es necesario proporcionar explícitamente una dirección IP al servicio MOC, ya que el servicio MOC también recibe una dirección IP del servidor DHCP.
Nodos del clúster de Azure Stack HCI y Windows Server con un modelo de asignación de IP estática: Si se asignan direcciones IP estáticas a los nodos del clúster, debe proporcionar explícitamente una dirección IP para el servicio MOC en la nube. La dirección IP del servicio MOC debe estar en la misma subred que las direcciones IP de los nodos del clúster de Azure Stack HCI y Windows Server. Para asignar explícitamente una dirección IP al servicio MOC, use el parámetro -cloudserviceCIDR en el comando Set-AksHciConfig. Asegúrese de escribir una dirección IP en formato CIDR; por ejemplo, "10.11.23.45/16".

Comparación de modelos de red

DHCP y IP estática proporcionan conectividad de red en akS en la implementación de Azure Stack HCI y Windows Server. Sin embargo, cada uno tiene sus ventajas y sus desventajas. En general, se aplican las siguientes consideraciones:

DHCP : no garantiza direcciones IP de larga duración para algunos tipos de recursos en una implementación de AKS. Admite la expansión de direcciones IP de DHCP reservadas si la implementación es mayor de lo previsto inicialmente.

IP estática : garantiza direcciones IP de larga duración para todos los recursos de una implementación de AKS. Dado que la expansión automática del grupo de direcciones IP de los nodos de Kubernetes no se admite, es posible que no pueda crear nuevos clústeres si ha agotado el grupo de direcciones IP de los nodos de Kubernetes.

En la tabla siguiente se compara la asignación de direcciones IP para los recursos entre los modelos de redes con direcciones IP estáticas y DHCP:

Capacidad	IP estática	DHCP
Servidor de API del clúster de Kubernetes	Asignado estáticamente mediante el grupo de VIP.	Asignado estáticamente mediante el grupo de VIP.
Nodos de Kubernetes (en máquinas virtuales)	Asignado mediante el grupo de direcciones IP del nodo de Kubernetes.	Asignado dinámicamente.
Servicios de Kubernetes	Asignado estáticamente mediante el grupo de VIP.	Asignado estáticamente mediante el grupo de VIP.
Máquina virtual del equilibrador de carga HAProxy	Asignado mediante el grupo de direcciones IP del nodo de Kubernetes.	Asignado dinámicamente.
Servicio en la nube local de Microsoft	Depende de la configuración de red física para los nodos de clúster de Azure Stack HCI y Windows Server.	Depende de la configuración de red física para los nodos de clúster de Azure Stack HCI y Windows Server.
Grupo de direcciones VIP	Mandatory	Mandatory
Grupo de IP de VM de los nodos de Kubernetes	Mandatory	No compatible

Reservas mínimas de direcciones IP para una implementación de AKS

Independientemente del modelo de implementación, el número de direcciones IP reservadas sigue siendo el mismo. En esta sección se describe el número de direcciones IP que debe reservar en función del modelo de implementación de AKS Arc.

Reserva mínima de direcciones IP

Como mínimo, debe reservar el siguiente número de direcciones IP para la implementación:

Tipo de clúster	Nodo del plano de control	Nodo de trabajo	Para las operaciones de actualización	Equilibrador de carga
Host de AKS	Una dirección IP	N/D	Dos direcciones IP	N/D
Clúster de carga de trabajo	Una dirección IP por nodo	Una dirección IP por nodo	5 direcciones IP	Una dirección IP

Además, debe reservar el siguiente número de direcciones IP para el grupo de direcciones VIP:

Tipo de recurso	Número de direcciones IP
Servidor de API del clúster	1 por clúster
Servicios de Kubernetes	1 por servicio
Servicios de aplicación	1 por servicio planificado

Como puede ver, el número de direcciones IP necesarias es variable en función de la arquitectura de la implementación de AKS y del número de servicios que se ejecutan en el clúster de Kubernetes. Se recomienda reservar un mínimo de 256 direcciones IP (subred /24) para la implementación.

Recorrido por una implementación de ejemplo

Jane es un administrador de TI que acaba de empezar con AKS habilitado por Azure Arc. Quiere implementar dos clústeres de Kubernetes: clúster de Kubernetes A y clúster de Kubernetes B en su clúster de Azure Stack HCI. También desea ejecutar una aplicación de votación en su clúster. Esta aplicación tiene tres instancias de la interfaz de usuario de front-end que se ejecutan en los dos clústeres y una instancia de la base de datos back-end.

El clúster de Kubernetes A tiene 3 nodos de plano de control y 5 nodos de trabajo.
El clúster de Kubernetes B tiene 1 nodo de plano de control y 3 nodos de trabajo.
3 instancias de la interfaz de usuario de front-end (puerto 443).
1 instancia de la base de datos back-end (puerto 80).

En función de la tabla anterior, debe reservar:

3 direcciones IP para el host de AKS (una dirección IP para el nodo del plano de control y dos direcciones IP para ejecutar operaciones de actualización).
3 direcciones IP para los nodos del plano de control del clúster A (una DIRECCIÓN IP por nodo del plano de control).
5 direcciones IP para los nodos de trabajo del clúster A (una dirección IP por nodo de trabajo).
6 direcciones IP adicionales para el clúster A (cinco direcciones IP para ejecutar operaciones de actualización y 1 DIRECCIÓN IP para el equilibrador de carga).
1 direcciones IP para los nodos del plano de control del clúster B (una dirección IP por nodo de plano de control).
3 direcciones IP para los nodos de trabajo del clúster B (una dirección IP por nodo de trabajo).
6 direcciones IP adicionales para el clúster B (cinco direcciones IP para ejecutar operaciones de actualización y 1 DIRECCIÓN IP para el equilibrador de carga).
2 direcciones IP para los servidores de API del clúster de Kubernetes (una dirección IP por clúster de Kubernetes).
3 direcciones IP para el servicio Kubernetes (una dirección IP por instancia de la interfaz de usuario de front-end, ya que todas usan el mismo puerto. La base de datos back-end puede usar cualquiera de las tres direcciones IP siempre que use un puerto diferente).

Como se explicó anteriormente, Jane requiere un total de 32 direcciones IP para implementar el clúster. Por lo tanto, Julia debe reservar una subred /26 para la red virtual.

División de direcciones IP reservadas según un modelo de red con direcciones IP estáticas

Aunque el número total de direcciones IP reservadas sigue siendo el mismo, el modelo de implementación determina cómo se dividen estas direcciones IP entre los grupos de direcciones IP. El modelo de red con direcciones IP estáticas tiene dos grupos de IP:

Grupo de direcciones IP de máquina virtual del nodo de Kubernetes: para las máquinas virtuales de nodo de Kubernetes y la máquina virtual del equilibrador de carga. Este grupo de IP también incluye la dirección IP necesaria para ejecutar las operaciones de actualización.
Grupo de direcciones IP virtuales: para el servidor de API de Kubernetes y los servicios de Kubernetes.

En este ejemplo, Jane debe dividir aún más estas direcciones IP entre grupos de VIP y grupos de direcciones IP de nodo de Kubernetes:

5 (dos para el servidor de API del clúster de Kubernetes y tres para los servicios de Kubernetes) de las 32 direcciones IP para el grupo de VIP.
27 (todas las direcciones IP para las VM de los nodos de Kubernetes y las VM subyacentes, las VM del equilibrador de carga y las operaciones de actualización) para el grupo de IP de los nodos de Kubernetes.

División de direcciones IP reservadas según un modelo de red con DHCP

Aunque el número total de direcciones IP reservadas sigue siendo el mismo, el modelo de implementación determina cómo se dividen estas direcciones IP entre los grupos de direcciones IP. Como se ha visto en la sección anterior, el modelo de red con DHCP tiene un ámbito de IP:

Grupo de direcciones IP virtuales: para el servidor de API de Kubernetes y los servicios de Kubernetes

Trabajar con el ejemplo anterior:

Julia debe reservar un total de 32 direcciones IP o una subred /26 en el servidor DHCP.
Tiene que excluir 5 (dos para el servidor de API del clúster de Kubernetes y tres para los servicios de Kubernetes) del ámbito de DHCP de 32 direcciones IP para el grupo de VIP.

Controladores de entrada

Durante la implementación de un clúster de destino, se crea un recurso de equilibrador de carga basado en HAProxy. El equilibrador de carga está configurado para distribuir el tráfico a los pods en su servicio en un puerto determinado. El equilibrador de carga solo funciona en la capa 4, lo que indica que el servicio no es consciente de la aplicación real; Es decir, no puede realizar consideraciones de enrutamiento adicionales.

Los controladores de entrada funcionan en la capa 7 y pueden usar reglas más inteligentes para distribuir el tráfico de las aplicaciones. Un uso común de un controlador de entrada es enrutar el tráfico HTTP a diferentes aplicaciones en función de la dirección URL de entrada.

Pasos siguientes

En este artículo se tratan algunos de los conceptos de red para implementar nodos de AKS en Azure Stack HCI. Vea los siguientes artículos para más información:

Share via