Uso de un equilibrador de carga interno con Azure Kubernetes Service (AKS)
Artículo
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.
Importante
El 30 de septiembre de 2025, se retirará Basic Load Balancer. Para obtener más información, consulte el anuncio oficial. Si actualmente utiliza el Basic Load Balancer, asegúrese de actualizarlo al Standard Load Balancer antes de la fecha de retirada. Para obtener instrucciones sobre la actualización, visite Actualización de Load Balancer básico: Guía.
Es necesaria la versión 2.0.59 o posterior de la CLI de Azure. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
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
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
Al especificar una dirección IP para el equilibrador de carga, la dirección IP especificada debe residir en la misma red virtual que el clúster de AKS, pero, aún, no puede estar asignado a otro recurso de la red virtual. 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. El uso de una dirección IP que ya está asignada a otro recurso de la misma red virtual puede provocar problemas con el equilibrador de carga.
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. Para obtener más información sobre las anotaciones de servicio, consulte Anotaciones compatibles con Azure LoadBalancer.
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.
Agregue la propiedad Service.Spec.LoadBalancerIP al manifiesto YAML del equilibrador de carga. Este campo está en desuso después de Kubernetes ascendente y no puede admitir la pila doble. El uso actual sigue siendo el mismo y se espera que los servicios existentes funcionen sin modificaciones.
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
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
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
# 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
Creación de un punto de conexión privado al servicio Private Link
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.
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.
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.
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)
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.
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:
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.
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.
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Muestre el diseño, la implementación y el mantenimiento de la infraestructura de red de Azure, el tráfico de equilibrio de carga, el enrutamiento de red, etc.