Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS)

Para restringir el acceso a las aplicaciones en Azure Kubernetes Service (AKS), puede crear y usar un equilibrador de carga interno. Un equilibrador de carga interno no dispone de dirección IP pública y hace que un servicio de Kubernetes sea accesible solo para las aplicaciones que pueden acceder a la dirección IP privada. Estas aplicaciones pueden estar dentro de la misma red virtual o en otra red virtual a través del emparejamiento de VNET. En este artículo se muestra cómo crear y usar un equilibrador de carga interno con AKS.

Nota:

Azure Load Balancer está disponible en dos SKU: Básico y Estándar. De manera predeterminada, la SKU Estándar se usa al crear un clúster de AKS. Al crear un tipo de servicio LoadBalancer, obtendrá el mismo tipo de equilibrador de carga que cuando aprovisionó el clúster. Para obtener más información, consulte el apartado de comparación de las SKU de Azure Load Balancer.

Antes de empezar

Creación de un conjunto de equilibrador de carga interno

  1. Cree un manifiesto de servicio denominado internal-lb.yaml con el tipo de servicio LoadBalancer y la anotación azure-load-balancer-internal.

    apiVersion: v1
    kind: Service
    metadata:
      name: internal-app
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    spec:
      type: LoadBalancer
      ports:
      - port: 80
      selector:
        app: internal-app
    
  2. Implemente el equilibrador de carga interno mediante el comando kubectl apply. Este comando crea un equilibrador de carga de Azure en el grupo de recursos del nodo, conectado a la misma red virtual que el clúster de AKS.

    kubectl apply -f internal-lb.yaml
    
  3. Vea los detalles del servicio mediante el comando kubectl get service.

    kubectl get service internal-app
    

    La dirección IP del equilibrador de carga interno se muestra en la columna EXTERNAL-IP, como se muestra en la salida del ejemplo siguiente. En este contexto, External hace referencia a la interfaz externa del equilibrador de carga. No significa que reciba una dirección IP pública y externa. Esta dirección IP se asigna dinámicamente desde la misma subred que el clúster de AKS.

    NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
    internal-app   LoadBalancer   10.0.248.59   10.240.0.7    80:30555/TCP   2m
    

Especificación de una dirección IP

Cuando especifique una dirección IP para el equilibrador de carga, la dirección IP especificada debe encontrarse en la misma subred que el clúster de AKS y no se puede haber asignado ya a un recurso. Por ejemplo, no se debe usar una dirección IP en el intervalo designado para la subred de Kubernetes dentro del clúster de AKS.

Puede usar el comando de la CLI de Azure az network vnet subnet list o el cmdlet de PowerShell Get-AzVirtualNetworkSubnetConfig para obtener las subredes de la red virtual.

Para obtener más información sobre las subredes, vea Incorporación de un grupo de nodos con una subred única.

Si quiere usar una dirección IP específica con el equilibrador de carga interno, tiene dos opciones: configurar las anotaciones de servicio o agregar la propiedad LoadBalancerIP al manifiesto YAML del equilibrador de carga.

Importante

La adición de la propiedad LoadBalancerIP al manifiesto YAML del equilibrador de carga está en desuso después de Kubernetes ascendente. Aunque se espera que el uso actual siga siendo el mismo y los servicios existentes funcionen sin modificaciones, se recomienda encarecidamente establecer anotaciones de servicio en su lugar.

  1. Configure las anotaciones de servicio usando service.beta.kubernetes.io/azure-load-balancer-ipv4 para una dirección IPv4 y service.beta.kubernetes.io/azure-load-balancer-ipv6 para una dirección IPv6.

    apiVersion: v1
    kind: Service
    metadata:
      name: internal-app
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.240.0.25
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    spec:
      type: LoadBalancer
      ports:
      - port: 80
      selector:
        app: internal-app
    
  1. Vea los detalles del servicio mediante el comando kubectl get service.

    kubectl get service internal-app
    

    La dirección IP de la columna EXTERNAL-IP debe reflejar la dirección IP especificada, como se muestra en la siguiente salida de ejemplo:

    NAME           TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
    internal-app   LoadBalancer   10.0.184.168   10.240.0.25   80:30225/TCP   4m
    

Para más información sobre cómo configurar el equilibrador de carga en una subred diferente, vea Especificación de una subred diferente.

Antes de empezar

  1. Cree un manifiesto de servicio denominado internal-lb-pls.yaml con el tipo de servicio LoadBalancer y las anotaciones azure-load-balancer-internal y azure-pls-create. Para obtener más opciones, consulte el documento de diseño Integración de servicio de Azure Private Link

    apiVersion: v1
    kind: Service
    metadata:
      name: internal-app
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
        service.beta.kubernetes.io/azure-pls-create: "true"
    spec:
      type: LoadBalancer
      ports:
      - port: 80
      selector:
        app: internal-app
    
  2. Implemente el equilibrador de carga interno mediante el comando kubectl apply. Este comando crea un equilibrador de carga de Azure en el grupo de recursos del nodo, conectado a la misma red virtual que el clúster de AKS. También crea un objeto de servicio de Private Link que se conecta a la configuración IP de front-end del equilibrador de carga asociado al servicio Kubernetes.

    kubectl apply -f internal-lb-pls.yaml
    
  3. Vea los detalles del servicio mediante el comando kubectl get service.

    kubectl get service internal-app
    

    La dirección IP del equilibrador de carga interno se muestra en la columna EXTERNAL-IP, como se muestra en la salida del ejemplo siguiente. En este contexto, External hace referencia a la interfaz externa del equilibrador de carga. No significa que reciba una dirección IP pública y externa.

    NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
    internal-app   LoadBalancer   10.125.17.53  10.125.0.66   80:30430/TCP   64m
    
  4. Vea los detalles del objeto de servicio de Private Link mediante el comando az network private-link-service list.

    # Create a variable for the node resource group
    
    AKS_MC_RG=$(az aks show -g myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
    
    # View the details of the Private Link Service object
    
    az network private-link-service list -g $AKS_MC_RG --query "[].{Name:name,Alias:alias}" -o table
    

    El resultado debería ser similar al ejemplo siguiente:

    Name      Alias
    --------  -------------------------------------------------------------------------
    pls-xyz   pls-xyz.abc123-defg-4hij-56kl-789mnop.eastus2.azure.privatelinkservice
    

Un punto de conexión privado permite conectarse de forma privada al objeto service de Kubernetes mediante el objeto Service de Private Link que se ha creado.

  • Cree el punto de conexión privado usando el comando az network private-endpoint create.

    # Create a variable for the private link service
    
    AKS_PLS_ID=$(az network private-link-service list -g $AKS_MC_RG --query "[].id" -o tsv)
    
    # Create the private endpoint
    
    $ az network private-endpoint create \
        -g myOtherResourceGroup \
        --name myAKSServicePE \
        --vnet-name myOtherVNET \
        --subnet pe-subnet \
        --private-connection-resource-id $AKS_PLS_ID \
        --connection-name connectToMyK8sService
    

Personalizaciones de PLS mediante anotaciones

A continuación se muestran anotaciones que se pueden usar para personalizar el recurso PLS.

Anotación Value Descripción Necesario Valor predeterminado
service.beta.kubernetes.io/azure-pls-create "true" Booleano que indica si es necesario crear un PLS. Obligatorio
service.beta.kubernetes.io/azure-pls-name <PLS name> Cadena que especifica el nombre del recurso PLS que se va a crear. Opcional "pls-<LB frontend config name>"
service.beta.kubernetes.io/azure-pls-resource-group Resource Group name Cadena que especifica el nombre del grupo de recursos donde se creará el recurso PLS Opcional MC_ resource
service.beta.kubernetes.io/azure-pls-ip-configuration-subnet <Subnet name> Cadena que indica la subred en la que se implementará el PLS. Esta subred debe existir en la misma red virtual que el grupo de back-end. Las direcciones IP NAT de PLS se asignan dentro de esta subred. Opcional Si service.beta.kubernetes.io/azure-load-balancer-internal-subnet, se usa esta subred ILB. De lo contrario, se usa la subred predeterminada del archivo de configuración.
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count [1-8] Número total de direcciones IP NAT privadas que se van a asignar. Opcional 1
service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address "10.0.0.7 ... 10.0.0.10" Lista separada por espacios de direcciones IP de IPv4 estáticas que se van a asignar. (no se admite IPv6 ahora mismo). El número total de direcciones IP no debe ser mayor que el número de direcciones IP especificado en service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count. Si se especifican menos direcciones IP, el resto se asigna dinámicamente. La primera dirección IP de la lista se establece como Primary. Opcional Todas las direcciones IP se asignan dinámicamente.
service.beta.kubernetes.io/azure-pls-fqdns "fqdn1 fqdn2" Una lista separada por espacios de fqdns asociada al PLS. Opcional []
service.beta.kubernetes.io/azure-pls-proxy-protocol "true" o "false" Booleano que indica si el protocolo TCP PROXY debe estar habilitado en el PLS para pasar a través de la información de conexión, incluido el identificador de vínculo y la dirección IP de origen. Tenga en cuenta que el servicio back-end DEBE admitir el protocolo PROXY o se producirá un error en las conexiones. Opcional false
service.beta.kubernetes.io/azure-pls-visibility "sub1 sub2 sub3 … subN" o "*" Lista separada por espacios de identificadores de suscripción de Azure para los que está visible el servicio de vínculo privado. Use "*" para exponer el PLS a todos los subs (menos restrictivo). Opcional Lista vacía [] que indica solo el control de acceso basado en roles: este servicio de vínculo privado solo estará disponible para usuarios con permisos de control de acceso basado en rol dentro del directorio. (Más restrictivo)
service.beta.kubernetes.io/azure-pls-auto-approval "sub1 sub2 sub3 … subN" Lista separada por espacios de identificadores de suscripción de Azure. Esto permite que las solicitudes de conexión PE de las suscripciones enumeradas en el PLS se aprueben automáticamente. Esto solo funciona cuando la visibilidad se establece en "*". Opcional []

Uso de redes privadas

Al crear su clúster de AKS, puede especificar la configuración de red avanzada. Esta configuración permite implementar el clúster en una red y subredes virtuales de Azure existentes. Por ejemplo, puede implementar el clúster de AKS en una red privada conectada a su entorno local y ejecutar servicios que son solo accesibles internamente.

Para obtener más información, vea cómo configurar sus propias subredes de red virtual con Kubenet o Azure CNI.

No es necesario realizar ningún cambio en los pasos anteriores para implementar un equilibrador de carga interno que use una red privada en un clúster de AKS. El equilibrador de carga se crea en el mismo grupo de recursos que el clúster de AKS, pero está conectado a la red virtual privada y la subred, tal como se muestra en el ejemplo siguiente:

$ kubectl get service internal-app

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
internal-app   LoadBalancer   10.1.15.188   10.0.0.35     80:31669/TCP   1m

Nota:

La identidad de clúster que usa el clúster de AKS al menos debe tener el rol de Colaborador de la red en el recurso de la red virtual. Puede ver la identidad del clúster mediante el comando az aks show, como az aks show --resource-group <resource-group-name> --name <cluster-name> --query "identity". Puede asignar el rol Colaborador de red mediante el comando az role assignment create, como az role assignment create --assignee <identity-resource-id> --scope <virtual-network-resource-id> --role "Network Contributor".

Si quiere definir un rol personalizado en su lugar, necesita los permisos siguientes:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Para más información, consulte Agregar, cambiar o eliminar una subred de red virtual.

Especificación de una subred diferente

  • Agregue la anotación azure-load-balancer-internal-subnet al servicio para especificar una subred para el equilibrador de carga. La subred especificada debe estar en la misma red virtual que el clúster de AKS. Cuando se implementa, la dirección del equilibrador de carga EXTERNAL-IP forma parte de la subred especificada.

    apiVersion: v1
    kind: Service
    metadata:
      name: internal-app
      annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
        service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "apps-subnet"
    spec:
      type: LoadBalancer
      ports:
      - port: 80
      selector:
        app: internal-app
    

Eliminación del equilibrador de carga

El equilibrador de carga se elimina cuando se eliminan todos sus servicios.

Puede eliminar directamente un servicio del mismo modo que cualquier recurso de Kubernetes, como kubectl delete service internal-app, acción que también eliminará el equilibrador de carga de Azure subyacente.

Pasos siguientes

Más información sobre los servicios de Kubernetes en la documentación de servicios de Kubernetes.