Uso de la integración con red virtual del servidor de API en Azure Kubernetes Service (AKS)

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

Un clúster de Azure Kubernetes Service (AKS) configurado con la integración con red virtual de API Server proyecta el punto de conexión del servidor de API directamente en una subred delegada en la red virtual donde se implementa AKS. API Server VNet Integration permite la comunicación de red entre el servidor de API y los nodos del clúster sin necesidad de ningún vínculo privado o túnel. El servidor de API está disponible detrás de una dirección IP virtual de equilibrador de carga interno en la subred delegada, que los nodos estarán configurados para usar. Mediante API Server VNet Integration, puede asegurarse de que el tráfico de red entre el servidor de API y los grupos de nodos permanece solo en la red privada.

Para la mayoría de las cargas de trabajo de producción, AKS Automatic es la experiencia predeterminada de AKS recomendada. AKS Automatic está listo para producción de forma predeterminada e incluye la integración con red virtual del servidor de API como una funcionalidad de seguridad de clúster preconfigurada. En AKS Standard, la integración con red virtual del servidor de API es opcional y se habilita durante la creación del clúster o actualizando un clúster existente.

Para obtener más información sobre AKS Automatic, consulte ¿Qué es Azure Kubernetes Service (AKS) automático?

Integración de red virtual de API Server en AKS Automatic y AKS Standard

La integración con red virtual del servidor de API está disponible en ambos modos de clúster de AKS, pero la configuración difiere:

  • AKS Automatic: la integración de red virtual del servidor de API está preconfigurada.
  • AKS Standard: la integración con red virtual del servidor de API es opcional y debe habilitarse explícitamente.

Para la mayoría de los escenarios de producción, comience con AKS Automatic para usar los valores predeterminados listos para producción y reduzca la sobrecarga operativa.

Conectividad del servidor de API

El plano de control o el servidor de API se encuentra en una suscripción de Azure administrada por AKS. El clúster o el grupo de nodos se encuentra en la suscripción de Azure. El servidor y las máquinas virtuales que componen los nodos del clúster se pueden comunicar entre sí mediante la dirección IP virtual del servidor de API y las direcciones IP del pod que se proyectan en la subred delegada.

API Server VNet Integration se admite en clústeres públicos y privados. Puede agregar o quitar el acceso público después del aprovisionamiento del clúster. A diferencia de los clústeres integrados que no son de red virtual, los nodos del agente siempre se comunican directamente con la dirección IP privada de la dirección IP del equilibrador de carga interno (ILB) del servidor de API sin usar DNS. Todo el tráfico del nodo al servidor de API se mantiene en redes privadas y no se requiere ningún túnel para la conectividad del servidor de API al nodo. Los clientes fuera del clúster que necesitan comunicarse con el servidor de API pueden hacerlo normalmente si está habilitado el acceso a la red pública. Si el acceso a la red pública está deshabilitado, debe seguir la misma metodología de configuración de DNS privada que los clústeres privados estándar.

Requisitos previos

  • Debe tener CLI de Azure versión 2.73.0 o posterior instalada. Puede comprobar la versión mediante el az --version comando .
  • Si trae su propia red virtual, revise los requisitos previos de la red virtual.

Limitaciones

Las siguientes limitaciones se aplican a la integración con red virtual del servidor de API, tanto si está preconfigurada en AKS Automático como habilitado explícitamente en AKS Standard:

  • La integración de VNet del servidor API no admite el cifrado de red virtual. Los clústeres implementados en las SKU de nodo de AKS v3 o anteriores (que no admiten el cifrado de red virtual) se permiten, pero el tráfico no está cifrado. Los clústeres implementados en nodos SKU de AKS v4 o posterior (que admiten cifrado de VNet) están bloqueados debido a que las VNets cifradas no son compatibles con la Integración de VNet del servidor API. Para más información, consulte SKU de máquina virtual compatibles con AKS.
  • Para usar redes de doble pila, el clúster necesita Kubernetes versión 1.26.3 o posterior, el complemento de red azure y el modo de complemento de red overlay. Para más información, consulta Azure CNI cluster con redes dual-stack.

Disponibilidad

  • La integración con red virtual del servidor de API está disponible en todas las regiones de nube pública de disponibilidad general, excepto qatarcentral.

Creación de un clúster con integración con red virtual de API Server

En AKS Automatic, la integración con red virtual del servidor de API está preconfigurada. No se requiere ninguna marca explícita --enable-apiserver-vnet-integration .

Cree un clúster automático de AKS siguiendo el inicio rápido:

AKS Standard: red virtual administrada

Puede configurar clústeres estándar de AKS con integración de red virtual de API Server en modo de red virtual administrada como clústeres públicos o privados.

Nota:

La integración con red virtual de API Server no está disponible en qatarcentral.

Crear un grupo de recursos

Cree un grupo de recursos con el comando az group create.

az group create --location <location> --name <resource-group>

Implementación de un clúster público

Implementa un clúster público de AKS Estándar con integración de API Server VNet para VNet administrada utilizando el comando az aks create con el indicador --enable-apiserver-vnet-integration.

az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-apiserver-vnet-integration \
    --generate-ssh-keys

Implementación de un clúster privado

Implemente un clúster privado de AKS Estándar con integración de red virtual (VNet) del servidor de API para una red virtual administrada mediante el comando az aks create con los indicadores --enable-apiserver-vnet-integration y --enable-private-cluster.

az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-private-cluster \
    --enable-apiserver-vnet-integration \
    --generate-ssh-keys

AKS Standard: traiga su propia red virtual

Cuando utilices bring-your-own VNet, debes crear y delegar una subred de servidor API a Microsoft.ContainerService/managedClusters. Esta delegación otorga al servicio AKS permisos para inyectar los pods del servidor API y el Load Balancer interno en esa subred. No puede usar la subred para ninguna otra carga de trabajo, pero puede usarla para varios clústeres de AKS ubicados en la misma red virtual. El tamaño mínimo admitido de subred del servidor de API es /28.

La identidad del clúster necesita permisos para la subred del servidor de API y la subred del nodo. La falta de permisos en la subred del servidor de API puede provocar un error de aprovisionamiento.

Advertencia

Un clúster de AKS reserva al menos nueve direcciones IP en el espacio de direcciones de subred. Quedarse sin direcciones IP puede impedir que el servidor API se escale y provocar una interrupción del servidor API.

Nota:

La integración con red virtual de API Server no está disponible en qatarcentral.

Crear un grupo de recursos

Cree un grupo de recursos con el comando az group create.

az group create --location <location> --name <resource-group>

Creación de una red virtual

  1. Cree una red virtual mediante el comando az network vnet create.

    az network vnet create --name <vnet-name> \
--resource-group <resource-group> \
--location <location> \
--address-prefixes 172.19.0.0/16

  2. Cree una subred de servidor de API mediante el comando az network vnet subnet create.

    az network vnet subnet create --resource-group <resource-group> \
--vnet-name <vnet-name> \
--name <apiserver-subnet-name> \
--delegations Microsoft.ContainerService/managedClusters \
--address-prefixes 172.19.0.0/28

  3. Cree una subred de clúster mediante el comando az network vnet subnet create.

    az network vnet subnet create --resource-group <resource-group> \
--vnet-name <vnet-name> \
--name <cluster-subnet-name> \
--address-prefixes 172.19.1.0/24

Creación de una identidad administrada y concesión de permisos en la red virtual

  1. Crear una identidad administrada usando el comando az identity create.

    az identity create --resource-group <resource-group> --name <managed-identity-name> --location <location>

  2. Asigne el rol Colaborador de red a la subred del servidor de API mediante el comando az role assignment create.

    az role assignment create --scope <apiserver-subnet-resource-id> \
--role "Network Contributor" \
--assignee <managed-identity-client-id>

  3. Asigne el rol Colaborador de red a la subred del clúster mediante el comando az role assignment create.

    az role assignment create --scope <cluster-subnet-resource-id> \
--role "Network Contributor" \
--assignee <managed-identity-client-id>

Implementación de un clúster público

Implemente un clúster de AKS público con API Server VNet Integration mediante el comando az aks create con la marca --enable-apiserver-vnet-integration.

az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-apiserver-vnet-integration \
    --vnet-subnet-id <cluster-subnet-resource-id> \
    --apiserver-subnet-id <apiserver-subnet-resource-id> \
    --assign-identity <managed-identity-resource-id> \
    --generate-ssh-keys

Implementación de un clúster privado

Implemente un clúster de AKS privado con API Server VNet Integration mediante el comando az aks create con las marcas --enable-apiserver-vnet-integration y --enable-private-cluster.

az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-private-cluster \
    --enable-apiserver-vnet-integration \
    --vnet-subnet-id <cluster-subnet-resource-id> \
    --apiserver-subnet-id <apiserver-subnet-resource-id> \
    --assign-identity <managed-identity-resource-id> \
    --generate-ssh-keys

Conversión de un clúster estándar de AKS existente en integración con red virtual del servidor de API

Advertencia

La integración de VNet del servidor API es una característica unidireccional y sensible a la capacidad. Al habilitar la integración con red virtual del servidor de API en un clúster estándar de AKS existente, se aplican las siguientes limitaciones:

  • Reinicio manual necesario: después de habilitar la integración con red virtual del servidor de API mediante az aks update --enable-apiserver-vnet-integration, debido a la transición de recursos del plano de control, debe reiniciar inmediatamente el clúster para que el cambio surta efecto. Este reinicio no está automatizado. Retrasar el reinicio aumenta el riesgo de que la capacidad no esté disponible, lo que puede impedir que se inicie el servidor de API. El reinicio del clúster también garantiza que todos los nodos se vuelvan a conectar de forma confiable al nuevo punto de conexión del servidor de API.
  • La capacidad se valida, pero no está reservada: AKS valida la capacidad regional al habilitar la característica en un clúster existente, pero esta validación no reserva capacidad. Si retrasa el reinicio y la capacidad deja de estar disponible mientras tanto, es posible que el clúster no se inicie después de una detención o reinicio. Los clústeres que habilitaron esta característica antes de la disponibilidad general (GA) o que aún no se han reiniciado desde la habilitación, no se someten a la validación de la capacidad.
  • No se puede deshabilitar la característica: una vez habilitada, la característica es permanente. No se puede deshabilitar la integración con red virtual del servidor de API.

Esta actualización realiza una actualización de la versión de imagen de nodo en todos los grupos de nodos y reinicia todas las cargas de trabajo mientras se someten a una actualización gradual de la imagen.

Advertencia

La conversión de un clúster a la integración con red virtual del servidor de API da lugar a un cambio de la dirección IP del servidor de API, aunque el nombre de host sigue siendo el mismo. Si configura la dirección IP del servidor de API en cualquier firewall o reglas de grupo de seguridad de red, es posible que tenga que actualizar esas reglas.

  1. Actualice el clúster a API Server VNet Integration mediante el comando az aks update con la marca --enable-apiserver-vnet-integration.

    az aks update --name <cluster-name> \
    --resource-group <resource-group> \
    --enable-apiserver-vnet-integration \
    --apiserver-subnet-id <apiserver-subnet-resource-id>

  2. Reinicie el clúster mediante los comandos [az aks stop][az-aks-stop] y [az aks start][az-aks-start].

    az aks stop --name <cluster-name> --resource-group <resource-group>
az aks start --name <cluster-name> --resource-group <resource-group>

Habilitación o deshabilitación del modo de clúster privado en un clúster existente con integración con red virtual del servidor de API

Los clústeres de AKS configurados con la integración con red virtual del servidor de API pueden tener habilitado el acceso a la red pública o el modo de clúster privado o deshabilitado sin volver a implementar el clúster. El nombre de host del servidor de API no cambia, pero las entradas DNS públicas se modifican o se quitan si es necesario.

Nota:

--disable-private-cluster se encuentra actualmente en versión preliminar. Para obtener más información, consulte Niveles de referencia y soporte técnico.

Habilitación del modo de clúster privado

Habilite el modo de clúster privado mediante el comando az aks update con la marca --enable-private-cluster.

az aks update --name <cluster-name> \
    --resource-group <resource-group> \
    --enable-private-cluster \
    --enable-apiserver-vnet-integration \
    --apiserver-subnet-id <apiserver-subnet-resource-id>

Deshabilitación del modo de clúster privado

Deshabilite el modo de clúster privado mediante el comando az aks update con la marca --disable-private-cluster.

az aks update --name <cluster-name> \
    --resource-group <resource-group> \
    --disable-private-cluster

Conexión a un clúster mediante kubectl

Configure kubectl para conectarse al clúster ejecutando el comando az aks get-credentials.

az aks get-credentials --resource-group <resource-group> --name <cluster-name>

Puede exponer el punto de conexión del servidor de API de un clúster privado mediante Azure Private Link, utilizando la integración VNet del servidor de API. En los pasos siguientes se muestra cómo crear un servicio de Private Link (PLS) en la red virtual del clúster y conectarse a ella desde otra red virtual o suscripción mediante un punto de conexión privado.

Nota:

La integración con red virtual de API Server no está disponible en qatarcentral.

Creación de un clúster privado de integración con red virtual de API Server

Cree un clúster de AKS privado con API Server VNet Integration mediante el comando az aks create con las marcas --enable-apiserver-vnet-integration y --enable-private-cluster.

az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-private-cluster \
    --enable-apiserver-vnet-integration

Para obtener más instrucciones sobre cómo configurar Private Link con la integración con red virtual de API Server, consulte Private Link with API Server VNet Integration.

Reglas de seguridad del grupo de seguridad de red

De manera predeterminada, se permite todo el tráfico dentro de la red virtual. Pero si ha agregado reglas de NSG para restringir el tráfico entre diferentes subredes, asegúrese de que las reglas de seguridad de NSG permiten los siguientes tipos de comunicación:

Destination Fuente Protocolo Puerto Uso
CIDR de subred de APIServer Subred de clúster TCP 443 y 4443 Necesario para habilitar la comunicación entre nodos y el servidor de API.
CIDR de subred de APIServer Azure Load Balancer TCP 9988 Necesario para habilitar la comunicación entre Azure Load Balancer y el servidor de API. También puede habilitar todas las comunicaciones entre el Azure Load Balancer y el CIDR de subred del servidor de API.

Contenido relacionado

  • Last updated on