Requisitos de planeamiento de direcciones IP
Se aplica a: Azure Local, versión 23H2
El planeamiento de direcciones IP para AKS habilitado por Azure Arc implica diseñar una red que admita aplicaciones, grupos de nodos, redes de pods, comunicación de servicio y acceso externo. Este artículo le guía por algunas consideraciones clave para el planeamiento eficaz de direcciones IP y el número mínimo de direcciones IP necesarias para implementar AKS en producción. Consulte los conceptos y requisitos de redes de AKS antes de leer este artículo.
Planeamiento de direcciones IP simples para clústeres y aplicaciones de Kubernetes
En el siguiente escenario, puede reservar direcciones IP de una sola red para los clústeres y servicios de Kubernetes. Este ejemplo es el escenario más sencillo y sencillo para la asignación de direcciones IP.
| Requisito de dirección IP | Número mínimo de direcciones IP | Cómo y dónde realizar esta reserva |
|---|---|---|
| DIRECCIONES IP de máquina virtual de AKS Arc | Reserve una dirección IP para cada nodo de trabajo del clúster de Kubernetes. Por ejemplo, si desea crear 3 grupos de nodos con 3 nodos en cada grupo de nodos, necesita 9 direcciones IP en el grupo de DIRECCIONES IP. | Reserve direcciones IP a través de grupos de DIRECCIONES IP en la red lógica de máquina virtual de Arc. |
| Direcciones IP de actualización de la versión de AKS Arc K8s | Dado que AKS Arc realiza actualizaciones graduales, reserve una dirección IP para cada clúster de AKS Arc para las operaciones de actualización de versiones de Kubernetes. | Reserve direcciones IP a través de grupos de DIRECCIONES IP en la red lógica de máquina virtual de Arc. |
| IP del plano de control | Reserve una dirección IP para cada clúster de Kubernetes del entorno. Por ejemplo, si desea crear 5 clústeres en total, reserve 5 direcciones IP, una para cada clúster de Kubernetes. | Reserve direcciones IP a través de grupos de DIRECCIONES IP en la red lógica de máquina virtual de Arc. |
| Direcciones IP del equilibrador de carga | El número de direcciones IP reservadas depende del modelo de implementación de aplicaciones. Como punto de partida, puede reservar una dirección IP para cada servicio de Kubernetes. | Reserve direcciones IP en la misma subred que la red lógica de máquina virtual de Arc, pero fuera del grupo de DIRECCIONES IP. |
Tutorial de ejemplo para la reserva de direcciones IP para clústeres y aplicaciones de Kubernetes
Jane es un administrador de TI que acaba de empezar con AKS habilitado por Azure Arc. Jane quiere implementar dos clústeres de Kubernetes: clúster de Kubernetes A y clúster de Kubernetes B en el clúster local de Azure. Jane también quiere ejecutar una aplicación de votación sobre el clúster A. Esta aplicación tiene tres instancias de la interfaz de usuario de front-end que se ejecuta en los dos clústeres y una instancia de la base de datos back-end. Todos los clústeres y servicios de AKS se ejecutan en una sola red, con una sola subred.
- 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, Jane debe reservar un total de 19 direcciones IP en la subred de Jane:
- 8 direcciones IP para las máquinas virtuales de nodo de AKS Arc en el clúster A (una dirección IP por máquina virtual de nodo K8s).
- 4 direcciones IP para las máquinas virtuales de nodo de AKS Arc en el clúster B (una dirección IP por máquina virtual de nodo K8s).
- 2 direcciones IP para ejecutar la operación de actualización de AKS Arc (una dirección IP por clúster de AKS Arc).
- 2 direcciones IP para el plano de control de AKS Arc (una dirección IP por clúster de AKS Arc)
- 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).
Siguiendo con este ejemplo y agregándolo a la tabla siguiente, obtendrá:
| Parámetro | Número de direcciones IP | Cómo y dónde realizar esta reserva |
|---|---|---|
| VM de AKS Arc, actualización de versiones K8s y IP del plano de control | Reservar 16 direcciones IP | Realice esta reserva a través de grupos de DIRECCIONES IP en la red lógica local de Azure. |
| Direcciones IP del equilibrador de carga | 3 Dirección IP para los servicios de Kubernetes, para la aplicación de votación de Jane. | Estas direcciones IP se usan al instalar un equilibrador de carga en el clúster A. Puede usar la extensión MetalLB Arc o traer su propio equilibrador de carga de terceros. Asegúrese de que esta dirección IP está en la misma subred que la red lógica de Arc, pero fuera del grupo de DIRECCIONES IP definido en la red lógica de la máquina virtual de Arc. |
Comandos de la CLI de ejemplo para la reserva de direcciones IP para clústeres y aplicaciones de Kubernetes
En esta sección se describe el conjunto de comandos que Jane ejecuta para su escenario. En primer lugar, cree una red lógica con un grupo de DIRECCIONES IP que tenga al menos 16 direcciones IP. Hemos creado el grupo de DIRECCIONES IP con 20 direcciones IP para proporcionar la opción de escalar el día N. Para obtener información detallada sobre las opciones de parámetro en redes lógicas, vea az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
A continuación, cree un clúster de AKS Arc con la red lógica anterior:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Ahora puede habilitar el equilibrador de carga MetalLB con un grupo de direcciones IP de 3 direcciones IP, en la misma subred que la red lógica de máquina virtual de Arc. Puede agregar más grupos de DIRECCIONES IP más adelante si la aplicación necesita un aumento. Para conocer los requisitos detallados, consulte la introducción a la extensión MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Consideraciones de LNET para clústeres de AKS y máquinas virtuales de Arc
Tanto los clústeres de AKS como las máquinas virtuales de Arc usan redes lógicas en Azure Local. Puede configurar redes lógicas de una de las dos maneras siguientes:
- Comparta una red lógica entre máquinas virtuales de AKS y Arc.
- Defina redes lógicas independientes para clústeres de AKS y máquinas virtuales de Arc.
El uso compartido de una red lógica entre máquinas virtuales de AKS y Arc en Azure Local ofrece la ventaja de una comunicación simplificada, ahorro de costos y administración simplificada de red. Sin embargo, este enfoque también presenta posibles desafíos, como la contención de recursos, los riesgos de seguridad y la complejidad en la solución de problemas.
| Criterios | Uso compartido de una red lógica | Definición de redes lógicas independientes |
|---|---|---|
| Complejidad de la configuración | Configuración más sencilla con una sola red, lo que reduce la complejidad de la configuración. | Configuración más compleja, ya que necesita configurar varias redes lógicas para máquinas virtuales y clústeres de AKS. |
| Escalabilidad | Las posibles limitaciones de escalabilidad, ya que tanto las máquinas virtuales de Arc como los clústeres de AKS comparten recursos de red. | Más escalable, ya que los recursos de red están separados y se pueden escalar de forma independiente. |
| Administración de directivas de red | Más fácil de administrar con un conjunto de directivas de red, pero más difícil de aislar las cargas de trabajo. | Más fácil de aislar las cargas de trabajo, ya que se pueden aplicar directivas independientes por red lógica. |
| Consideraciones de seguridad | Aumento del riesgo de vulnerabilidades entre comunicaciones si no se segmentan correctamente. | Mejor seguridad ya que cada red se puede segmentar y aislar más estrictamente. |
| Impacto de los errores de red | Un error en la red compartida puede afectar simultáneamente a las máquinas virtuales de AKS y Arc. | Un error en una red afecta solo a las cargas de trabajo dentro de esa red, lo que reduce el riesgo general. |
Asignación de intervalo de direcciones IP para CIDR de pod y CIDR de servicio
En esta sección se describen los intervalos de direcciones IP que usa Kubernetes para la comunicación entre pods y servicios dentro de un clúster. Estos intervalos de direcciones IP se definen durante el proceso de creación del clúster de AKS y se usan para asignar direcciones IP únicas a pods y servicios dentro del clúster.
CIDR de red de pods
CIDR de red de pod es un intervalo de direcciones IP que usa Kubernetes para asignar direcciones IP únicas a los pods individuales que se ejecutan dentro de un clúster de Kubernetes. Cada pod obtiene su propia dirección IP dentro de este intervalo, lo que permite que los pods se comuniquen entre sí y con servicios dentro del clúster. En AKS, las direcciones IP del pod se asignan a través de Calico CNI en modo VXLAN. Calico VXLAN ayuda a crear redes de superposición, donde las direcciones IP de los pods (desde el CIDR de red del pod) se virtualizan y tunelan a través de la red física. En este modo, a cada pod se le asigna una dirección IP desde el CIDR de red del pod, pero esta dirección IP no se puede enrutar directamente en la red física. En su lugar, se encapsula dentro de los paquetes de red y se envía a través de la red física subyacente para llegar a su pod de destino en otro nodo.
AKS proporciona un valor predeterminado de 10.244.0.0/16 para el CIDR de red del pod. AKS admite personalizaciones para el CIDR de red de pods. Puede establecer su propio valor mediante el --pod-cidr parámetro al crear el clúster de AKS. Asegúrese de que el intervalo IP CIDR es lo suficientemente grande como para dar cabida al número máximo de pods por nodo y a través del clúster de Kubernetes.
CIDR de red de servicio
El CIDR de red de servicio es el intervalo de direcciones IP reservadas para los servicios de Kubernetes, como LoadBalancers, ClusterIP y NodePort dentro de un clúster. Kubernetes admite los siguientes tipos de servicio:
- ClusterIP: el tipo de servicio predeterminado, que expone el servicio dentro del clúster. La dirección IP asignada desde el CIDR de red de servicio solo es accesible dentro del clúster de Kubernetes.
- NodePort: expone el servicio en un puerto específico en la dirección IP de cada nodo. ClusterIP se sigue usando internamente, pero el acceso externo se realiza a través de las direcciones IP del nodo y un puerto específico.
- LoadBalancer: este tipo crea un equilibrador de carga administrado por el proveedor de nube y expone el servicio externamente. Normalmente, el proveedor de nube administra la asignación de IP externa, mientras que clusterIP interno permanece dentro del CIDR de red de servicio.
AKS proporciona un valor predeterminado de 10.96.0.0/12 para el CIDR de red de servicio. AKS no admite personalizaciones para el CIDR de red de servicio en la actualidad.
Pasos siguientes
Creación de redes lógicas para clústeres de Kubernetes en Azure Local, versión 23H2