Compartir a través de

Uso de un equilibrador de carga estándar público en Azure Kubernetes Service (AKS)

  • Artículo

Azure Load Balancer opera en una capa 4 del modelo de Interconexión de sistemas abiertos (OSI) que admite escenarios de entrada y de salida. Distribuye flujos de entrada que llegan al front-end del equilibrador de carga a las instancias del grupo de servidores back-end.

Una equilibrador de carga público integrado con AKS tiene dos propósitos:

  1. Proporcionar conexiones salientes a los nodos de clúster dentro de la red virtual de AKS mediante la traducción de la dirección IP privada en una parte de la dirección IP pública de su grupo de salida.
  2. Proporcionar acceso a las aplicaciones a través de servicios de Kubernetes del tipo LoadBalancer, lo que le permite escalar fácilmente las aplicaciones y crear servicios de alta disponibilidad.

Un equilibrador de carga interno (o privado) se usa cuando solo se permiten direcciones IP privadas como front-end. Los equilibradores de carga internos se usan para equilibrar la carga del tráfico dentro de una red virtual. También se puede acceder a un servidor front-end de equilibrador de carga desde una red local en un escenario híbrido.

En este artículo se trata la integración con un equilibrador de carga público en AKS. Para la integración interna de Load Balancer, consulte Uso de un equilibrador de carga interno de AKS.

Antes de empezar

  • 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. La SKU estándar le da acceso a funcionalidad agregada, como un grupo mayor de back-end, varios grupos de nodos, Availability Zones, además es segura de manera predeterminada. Se trata de la SKU de equilibrador de carga recomendada para AKS. Para más información sobre las SKU básicas y estándar, consulte Comparación de las SKU de Load Balancer.
  • Para obtener una lista completa de las anotaciones admitidas para los servicios de Kubernetes con el tipo LoadBalancer, consulte Anotaciones del equilibrador de carga.
  • En este artículo se da por supuesto que tiene un clúster de AKS con la SKU Estándar de Azure Load Balancer. Si necesita un clúster de AKS, puede crear uno mediante la CLI de Azure, Azure PowerShell o Azure Portal.
  • AKS administra el ciclo de vida y las operaciones de los nodos de agente. No se admite la modificación de los recursos de IaaS asociados a los nodos de agente. Un ejemplo de una operación no admitida sería realizar cambios manuales en el grupo de recursos del equilibrador de carga.

Importante

Si prefiere usar su propia puerta de enlace, firewall o proxy para proporcionar una conexión de salida, puede omitir la creación del grupo de salida del equilibrador de carga y el IP del front-end respectivo si usa el tipo de salida como UserDefinedRouting (UDR). El tipo de salida define el método de salida para un clúster y su valor predeterminado es el tipo LoadBalancer.

Uso de la instancia pública de Standard Load Balancer.

Después de crear un clúster de AKS con el tipo de salida LoadBalancer (valor predeterminado), el clúster está listo para usar el equilibrador de carga para exponer los servicios.

Cree un manifiesto de servicio denominado public-svc.yaml, que crea un servicio público de tipo LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Especifique la dirección IP del equilibrador de carga

Si quiere usar una dirección IP específica con el equilibrador de carga, hay dos maneras:

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.

  • Establecer anotaciones de servicio: use 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 LoadBalancerIP al manifiesto YAML del equilibrador de carga: 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.

Implementación del manifiesto de servicio

Para implementar el manifiesto de servicio público, use kubectl apply y especifique el nombre del manifiesto de YAML.

kubectl apply -f public-svc.yaml

Azure Load Balancer se configura con una nueva dirección IP pública de entrada al nuevo servicio. Dado que Azure Load Balancer puede tener varias direcciones IP de front-end, cada nuevo servicio que implemente obtiene una nueva dirección IP de front-end dedicada a la que podrá acceder de forma única.

Puede usar el siguiente comando para confirmar que se ha creado el servicio y que el equilibrador de carga está configurado.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    203.0.113.187   80:32068/TCP    52s

Cuando visualiza los detalles del servicio, la dirección IP pública creada para este servicio en Load Balancer se muestra en la columna EXTERNAL-IP. Probablemente la dirección IP tarde unos minutos en cambiar de <pendiente> a una dirección IP pública real.

Para obtener información más detallada sobre el servicio, use el siguiente comando.

kubectl describe service public-svc

La siguiente salida de ejemplo es una versión condensada de la salida después de ejecutar kubectl describe service. LoadBalancer Ingress muestra la dirección IP externa expuesta por el servicio. IP muestra las direcciones internas.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        203.0.113.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Configuración de la instancia pública de Standard Load Balancer

Puede personalizar diferentes configuraciones para el equilibrador de carga público estándar en el momento de la creación del clúster o mediante la actualización del mismo. Estas opciones de personalización le permiten crear un equilibrador de carga que satisfaga las necesidades de la carga de trabajo. Con el equilibrador de carga estándar, puede hacer lo siguiente:

  • Definir o escalar el número de direcciones IP de salida administradas.
  • Traer sus propias IP, o prefijos de IP, de salida.
  • Personalizar el número de puertos de salida asignados a cada nodo del clúster.
  • Configurar el valor de tiempo de espera de las conexiones inactivas.

Importante

En un momento dado, solo se puede usar una opción de dirección IP de salida (direcciones IP administradas, traer sus propias direcciones IP o prefijo de IP).

Cambio del tipo de grupo de entrada

Para hacer referencia a los nodos de AKS en los grupos de back-end del equilibrador de carga, se puede usar su configuración IP (pertenencia basada en Azure Virtual Machine Scale Sets) o solo su dirección IP. El uso de la pertenencia al grupo de back-end basado en direcciones IP proporciona una mayor eficiencia al actualizar los servicios y aprovisionar equilibradores de carga, especialmente con un número alto de nodos. Ahora se admite el aprovisionamiento de nuevos clústeres con grupos de back-end basados en IP y la conversión de clústeres existentes. Cuando se combina con NAT Gateway o tipos de salida de enrutamiento definidos por el usuario, el aprovisionamiento de nuevos nodos y servicios es más eficaz.

Hay disponibles dos tipos de pertenencia a grupos diferentes:

  • nodeIPConfiguration: tipo de pertenencia a grupo basado en la configuración de IP de Virtual Machine Scale Sets heredada
  • nodeIP: tipo de pertenencia basada en grupos

Requisitos

  • Se debe usar la versión 1.23 o posterior del clúster de AKS.
  • El clúster de AKS debe usar equilibradores de carga estándar y conjuntos de escalado de máquinas virtuales.

Creación de un clúster de AKS con pertenencia a grupos de entrada basados en IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys

Actualización de un clúster de AKS existente para usar la pertenencia a grupos de entrada basados en IP

Advertencia

Esta operación provoca una interrupción temporal del tráfico de servicio entrante en el clúster. El tiempo de impacto aumenta con clústeres más grandes que tienen muchos nodos.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Escalar el número de direcciones IP públicas de salida administradas.

Azure Load Balancer proporciona conectividad de entrada y salida desde una red virtual. Las reglas de salida facilitan la configuración de la traducción de direcciones de red para el equilibrador de carga estándar público.

Las reglas de salida siguen la misma sintaxis que las reglas NAT de entrada y el equilibrio de carga:

IP de front-end + parámetros + grupo de back-end

Una regla de salida configura una NAT de salida para todas las máquinas virtuales identificadas por el grupo de back-end que se deben traducir para el front-end. Los parámetros proporcionan un mayor control sobre el algoritmo de NAT de salida.

Aunque puede usar una regla de salida con una única dirección IP pública, las reglas de salida son excelentes para escalar NAT de salida porque alivian la sobrecarga generada por la configuración. Puede usar varias direcciones IP para planear escenarios a gran escala y reglas de salida para mitigar los patrones con tendencia a agotamiento de SNAT. Cada dirección IP que proporciona un front-end ofrece 64 000 puertos efímeros que el equilibrador de carga puede usar como puertos SNAT.

Cuando se usa un equilibrador de carga de SKU Estándar con direcciones IP públicas de salida administradas, que se crean de forma predeterminada, se puede escalar el número de direcciones IP públicas de salida administradas mediante el parámetro --load-balancer-managed-outbound-ip-count.

Para actualizar un clúster existente, use el siguiente comando. También puede establecer este parámetro para que tenga varias direcciones IP públicas de salida administradas.

Importante

No se recomienda usar Azure Portal para realizar cambios en las reglas de salida. Al realizar estos cambios, debe pasar a través del clúster de AKS y no efectuarlos directamente en el recurso de Load Balancer.

Los cambios en las reglas de salida realizados directamente en el recurso de Load Balancer se eliminan en cuanto se concilie el clúster como, por ejemplo, cuando se detenga, inicie, actualice o escale.

Use la CLI de Azure, como se indica en los ejemplos. Los cambios en las reglas de salida realizados mediante los comandos az aks de la CLI son permanentes durante el tiempo de inactividad del clúster.

Para más información, consulte Reglas de salida de Azure Load Balancer.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

En el ejemplo anterior se establece el número de direcciones IP públicas de salida administradas en 2 para el clúster de myAKSCluster en myResourceGroup.

Durante la creación del clúster, también puede usar el parámetro --load-balancer-managed-outbound-ip-count y establecerlo en el valor deseado para definir el número inicial de direcciones IP públicas de salida administradas. El número predeterminado de direcciones IP públicas de salida administradas es 1.

Proporcionar prefijos o direcciones IP públicas de salida

Cuando se usa un equilibrador de carga de SKU estándar, el clúster de AKS crea automáticamente una dirección IP pública en el grupo de recursos de infraestructura administrado por AKS y la asigna al grupo de salida del equilibrador de carga de forma predeterminada.

Una IP pública creada por AKS es un recurso administrado por AKS, lo que significa que AKS administra el ciclo de vida de esa IP pública y no requiere la acción del usuario directamente sobre el recurso de la IP pública. Como alternativa, puede asignar su propio prefijo de dirección IP pública personalizada o IP pública en el momento de la creación del clúster. Las direcciones IP personalizadas también se pueden actualizar en las propiedades del equilibrador de carga de un clúster existente.

Requisitos para usar su propio prefijo o dirección IP pública:

  • Los usuarios deben crear y poseer direcciones IP públicas personalizadas. Las direcciones IP públicas administradas creadas por AKS no se pueden volver a usar como una dirección IP personalizada, ya que pueden provocar conflictos de administración.
  • Debe asegurarse de que la identidad de clúster de AKS (entidad de servicio o identidad administrada) tiene permisos para acceder a la dirección IP de salida, como se indica en la lista de permisos necesarios de dirección IP pública.
  • Asegúrese de que cumple los requisitos previos y las restricciones necesarios para configurar direcciones IP de salida o prefijos IP de salida.

Actualización del clúster con su propia dirección IP pública de salida

Use el comando az network public-ip show para enumerar los id. de las direcciones IP públicas.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

El comando anterior muestra el id. de la dirección IP pública myPublicIP en el grupo de recursos myResourceGroup.

Use el comando az aks update con el parámetro load-balancer-outbound-ips para actualizar el clúster con las direcciones IP públicas.

En el ejemplo siguiente se usa el parámetro load-balancer-outbound-ips con los identificadores del comando anterior.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Actualización del clúster con su propio prefijo de dirección IP pública de salida

También puede usar prefijos de dirección IP pública para la salida con el equilibrador de carga de SKU estándar. En el ejemplo siguiente se usa el comando az network public-ip prefix show para enumerar los id. de los prefijos de dirección IP pública.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

El comando anterior muestra el id. del prefijo de dirección IP pública myPublicIPPrefix en el grupo de recursos myResourceGroup.

En el ejemplo siguiente se usa el parámetro load-balancer-outbound-ip-prefixes con los id. del comando anterior.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Creación del clúster con su propio prefijo o dirección IP pública

Puede traer sus propias direcciones IP o prefijos IP para la salida en el momento de la creación del clúster para respaldar escenarios como la incorporación de puntos de conexión de salida a una lista de permitidos. Para definir sus propias direcciones IP públicas y prefijos IP en el momento de la creación del clúster, anexe los mismos parámetros que se indican en el comando anterior.

Use el comando az aks create con el parámetro load-balancer-outbound-ips para crear un clúster con sus propias direcciones IP públicas.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
    --generate-ssh-keys

Use el comando az aks create con el parámetro load-balancer-outbound-ip-prefixes para crear un clúster con sus propios prefijos de IP públicas.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2> \
    --generate-ssh-keys

Configuración de los puertos de salida asignados

Importante

Si tiene aplicaciones en el clúster que pueden establecer un gran número de conexiones a un pequeño conjunto de destinos en direcciones IP públicas, como muchas instancias de una aplicación de front-end que se conectan a una base de datos, es posible que tenga un escenario en el que se puede dar un agotamiento de puertos SNAT. El agotamiento de puertos SNAT se produce cuando una aplicación se queda sin puertos de salida que pueda usar para establecer una conexión con otra aplicación u host. Si tiene un escenario en el que se pueda producir el agotamiento de puertos SNAT, se recomienda aumentar los puertos de salida asignados y las direcciones IP de front-end de salida en el equilibrador de carga.

Para más información sobre SNAT, consulte Uso de SNAT para conexiones salientes.

De manera predeterminada, en su equilibrador de carga, AKS establece AllocatedOutboundPorts en 0, lo que permite la asignación automática de puertos de salida en función del tamaño del grupo de back-end al crear un clúster. Por ejemplo, si un clúster tiene 50 nodos o menos, se asignan 1024 puertos a cada nodo. Este valor permite escalar al número máximo de nodos del clúster sin necesidad de reconfigurar la red, pero puede hacer que el agotamiento de puertos SNAT sea más común a medida que se agregan más nodos. A medida que aumenta el número de nodos del clúster, hay menos puertos disponibles por nodo. Aumentar el número de nodos más allá de los límites del gráfico (por ejemplo, pasar de 50 a 51 nodos o de 100 a 101) puede afectar a la conectividad a medida que los puertos SNAT asignados a nodos existentes se reducen para permitir más nodos. Se recomienda usar un valor explícito para AllocatedOutboundPorts, como se muestra a continuación.

Para mostrar el valor de AllocatedOutboundPorts para el equilibrador de carga del clúster de AKS, use az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

La siguiente salida de ejemplo muestra que está habilitada la asignación automática de puertos de salida basada en el tamaño del grupo de back-end para el clúster.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Para configurar un valor específico para AllocatedOutboundPorts y la dirección IP de salida al crear o actualizar un clúster, use load-balancer-outbound-ports y load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips o load-balancer-outbound-ip-prefixes. Antes de establecer un valor específico o aumentar un valor existente para los puertos de salida y las direcciones IP de salida, debe calcular el número adecuado de puertos de salida y direcciones IP. Utilice la ecuación siguiente para este cálculo, redondeado al entero más cercano: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Importante

Agregar más direcciones IP salientes a un clúster no proporcionará más puertos SNAT disponibles para los nodos, a menos que se establezca un valor distinto de cero para AllocatedOutboundPorts. Si se deja el valor predeterminado de 0 para AllocatedOutboundPorts, los puertos SNAT de los nodos seguirán establecidos según la tabla de la documentación de Load Balancer y no se usarán los puertos adicionales de las direcciones IP agregadas.

Al calcular el número de puertos y direcciones IP de salida y establecer los valores, tenga en cuenta la siguiente información:

  • El número de puertos de salida por nodo se fijará en función del valor que establezca.
  • El valor de los puertos de salida debe ser un múltiplo de 8.
  • Agregar más direcciones IP no implica agregar más puertos a ningún nodo, pero esto proporciona capacidad para más nodos del clúster.
  • Debe tener en cuenta los nodos que se puedan agregar como parte de las actualizaciones, incluido el recuento de nodos especificado mediante valores maxSurge.

En los ejemplos siguientes se muestra cómo afectan los valores establecidos al número de puertos de salida y direcciones IP:

  • Si se utilizan los valores predeterminados y el clúster tiene 48 nodos, cada nodo tiene 1024 puertos disponibles.
  • Si se utilizan los valores predeterminados y el clúster se escala de 48 a 52 nodos, cada nodo se actualiza de 1024 puertos disponibles a 512 puertos disponibles.
  • Si el número de puertos de salida se establece en 1000 y el número de direcciones IP de salida se establece en 2, el clúster puede admitir un máximo de 128 nodos: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Si el número de puertos de salida se establece en 1000 y el número de direcciones IP de salida se establece en 2, el clúster puede admitir un máximo de 128 nodos: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Si el número de puertos de salida se establece en 4000 y el número de direcciones IP de salida se establece en 2, el clúster puede admitir un máximo de 32 nodos: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Si el número de puertos de salida se establece en 4000 y el número de direcciones IP de salida se establece en 2, el clúster puede admitir un máximo de 32 nodos: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Importante

Después de calcular el número de puertos de salida y direcciones IP, compruebe que tiene capacidad de puertos de salida adicional para controlar los picos de nodos durante las actualizaciones. Es fundamental asignar suficientes puertos en exceso para los nodos adicionales necesarios para la actualización y otras operaciones. AKS se establece de forma predeterminada en un nodo de búfer para las operaciones de actualización. Si usa valores maxSurge, multiplique los puertos de salida por nodo por el valor maxSurge para determinar el número de puertos necesarios. Por ejemplo, si calculó que necesitaba 4000 puertos por nodo con 7 direcciones IP en un clúster con un máximo de 100 nodos y un pico máximo de 2:

  • 2 nodos de pico * 4000 puertos por nodo = 8000 puertos necesarios para los picos de nodos durante las actualizaciones.
  • 100 nodos * 4000 puertos por nodo = 400 000 puertos necesarios para el clúster.
  • 7 direcciones IP * 64 000 puertos por dirección IP = 448 000 puertos disponibles para el clúster.

En el ejemplo anterior, se muestra que el clúster tiene una capacidad en exceso de 48 000 puertos, lo que es suficiente para controlar los 8000 puertos necesarios para los picos de nodos durante las actualizaciones.

Una vez calculados y comprobados los valores, puede aplicarlos mediante load-balancer-outbound-ports y load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips o load-balancer-outbound-ip-prefixes al crear o actualizar un clúster.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Configuración del tiempo de espera de inactividad del equilibrador de carga

Cuando se agotan los recursos de los puertos SNAT, los flujos de salida generan errores hasta que los flujos ya existentes liberan puertos SNAT. Load Balancer reclama puertos SNAT cuando el flujo se cierra y el equilibrador de carga configurado con AKS usa un tiempo de espera de inactividad de 30 minutos para reclamar puertos SNAT de los flujos inactivos.

También puede usar transporte (por ejemplo, TCP keepalives o application-layer keepalives) para actualizar un flujo de inactividad y restablecer este tiempo de expiración en caso necesario. Puede configurar este tiempo de expiración como en el ejemplo siguiente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Si espera tener numerosas conexiones de corta duración y ninguna conexión de larga duración que pueda tener tiempos de inactividad prolongados, como el uso de kubectl proxy o kubectl port-forward, considere el uso de un valor de tiempo de expiración bajo, como 4 minutos. Al usar mensajes de mantenimiento de conexión de TCP, es suficiente habilitarlos en un lado de la conexión. Por ejemplo, es suficiente habilitarlas solo en el servidor para restablecer el temporizador de inactividad del flujo. No es necesario que ambos lados inicien keepalives de TCP. Existen conceptos similares existen para la capa de aplicación, incluidas las configuraciones de cliente/servidor de base de datos. Compruebe el lado del servidor para ver qué opciones existen para las conexiones persistentes específicas de la aplicación.

Importante

AKS habilita el restablecimiento de TCP por inactividad de forma predeterminada. Recomendamos que mantenga esta configuración y la utilice para obtener un comportamiento de la aplicación más predecible en sus escenarios.

TCP RST solo se envía durante la conexión TCP en el estado ESTABLECIDO. Aquí encontrará más información.

Si establece IdleTimeoutInMinutes en un valor distinto del predeterminado de 30 minutos, tenga en cuenta el tiempo que las cargas de trabajo necesitan una conexión de salida. Tenga en cuenta también que el valor de tiempo de espera predeterminado para un equilibrador de carga de SKU Estándar usado fuera de AKS es de 4 minutos. Un valor de IdleTimeoutInMinutes que refleje de forma más precisa su carga de trabajo de AKS específica puede ayudar a reducir el agotamiento de SNAT causado por la vinculación de las conexiones ya no se usan.

Advertencia

El modificar los valores de AllocatedOutboundPorts e IdleTimeoutInMinutes puede cambiar significativamente el comportamiento de la regla de salida para el equilibrador de carga y no debe realizarse con poca luz. Consulte la sección Solución de problemas de SNAT y revise las reglas de salida de Load Balancer y las conexiones salientes en Azure antes de actualizar estos valores para comprender totalmente el impacto de los cambios.

Restricción del tráfico entrante a intervalos IP específicos

En el siguiente manifiesto se usa loadBalancerSourceRanges para especificar un nuevo intervalo IP para el tráfico externo entrante.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

En este ejemplo se actualiza la regla para permitir el tráfico externo entrante solo desde el intervalo MY_EXTERNAL_IP_RANGE. Si reemplaza MY_EXTERNAL_IP_RANGE por la dirección IP de la subred interna, el tráfico se restringe solo a las direcciones IP internas del clúster. Si el tráfico está restringido a las direcciones IP internas del clúster, los clientes fuera del clúster de Kubernetes no pueden acceder al equilibrador de carga.

Nota:

  • Los flujos de tráfico externos entrantes del equilibrador de carga a la red virtual para el clúster de AKS. La red virtual tiene un grupo de seguridad de red (NSG) que permite todo el tráfico entrante desde el equilibrador de carga. Este NSG usa una etiqueta de servicio de tipo LoadBalancer para permitir el tráfico desde el equilibrador de carga.
  • El CIDR de pod debería agregarse a loadBalancerSourceRanges si hubiera pods que necesiten acceder a la dirección IP de LoadBalancer del servicio para clústeres con la versión v1.25 o posterior.

Mantenimiento de la dirección IP del cliente en las conexiones entrantes

De forma predeterminada, un servicio de tipo LoadBalancer en Kubernetes y en AKS no conserva la dirección IP del cliente en la conexión con el pod. La dirección IP de origen del paquete que se proporciona al pod es la dirección IP privada del nodo. Para mantener la dirección IP del cliente, debe establecer service.spec.externalTrafficPolicy en local en la definición del servicio. En el siguiente manifiesto se muestra un ejemplo.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Personalizaciones mediante anotaciones de Kubernetes

Las anotaciones siguientes se admiten para los servicios de Kubernetes con el tipo LoadBalancer y solo se aplican a los flujos INBOUND.

Anotación Value Descripción
service.beta.kubernetes.io/azure-load-balancer-internal true o false Especifique si el equilibrador de carga debe ser interno. Si no se establece, el valor predeterminado es público.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nombre de la subred Especifique a qué subred se debe enlazar el equilibrador de carga interno. Si no se establece, el valor predeterminado es la subred configurada en el archivo de configuración de la nube.
service.beta.kubernetes.io/azure-dns-label-name Nombre de la etiqueta DNS en direcciones IP públicas Especifique el nombre de la etiqueta DNS para el servicio público. Si se establece en una cadena vacía, no se usa la entrada DNS de la dirección IP pública.
service.beta.kubernetes.io/azure-shared-securityrule true o false Especifique la exposición del servicio a través de una regla de seguridad de Azure potencialmente compartida para aumentar la exposición del servicio mediante reglas de seguridad aumentada de Azure en grupos de seguridad de red.
service.beta.kubernetes.io/azure-load-balancer-resource-group Nombre del grupo de recursos Especifique el grupo de recursos de direcciones IP públicas del equilibrador de carga que no están en el mismo grupo de recursos que la infraestructura de clúster (grupo de recursos de nodo).
service.beta.kubernetes.io/azure-allowed-service-tags Lista de etiquetas de servicio permitidas Especifique una lista de etiquetas de servicio permitidas separadas por comas.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Tiempo de expiración de inactividad de TCP en minutos Especifique el tiempo, en minutos, para la expiración de inactividad de conexión TCP en el equilibrador de carga. El valor predeterminado y el mínimo es 4. El valor máximo es 30. El valor debe ser un entero.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true o false Especifique si el equilibrador de carga debe deshabilitar el restablecimiento de TCP en el tiempo de espera de inactividad.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Dirección IPv4 Especifique la dirección IPv4 para asignar al equilibrador de carga.
service.beta.kubernetes.io/azure-load-balancer-ipv6 Dirección IPv6 Especifique la dirección IPv6 para asignar al equilibrador de carga.

Personalización del sondeo de estado del equilibrador de carga

Anotación Value Descripción
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Intervalo de sondeo de estado
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe El número mínimo de respuestas incorrectas del sondeo de estado
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Ruta de acceso de solicitud del sondeo de estado
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} es el número de puerto de servicio. Cuando se establece en true, no se genera ninguna regla de lb o regla de sondeo de estado para este puerto. El servicio de comprobación de estado no debe exponerse a la red pública de Internet (por ejemplo, el servicio de comprobación de estado istio/envoy)
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} es el número de puerto de servicio. Cuando se establece en true, no se genera ninguna regla de sondeo de estado para este puerto.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protocolo de sondeo de estado {port} es el número de puerto de servicio. Protocolo explícito para el sondeo de estado para el puerto de servicio {port}, que reemplaza port.appProtocol si se establece.
service.beta.kubernetes.io/port_{port}_health-probe_port número de puerto o nombre de puerto en el manifiesto de servicio {port} es el número de puerto de servicio. Puerto explícito para el sondeo de estado para el puerto de servicio {port}, que reemplaza el valor predeterminado.
service.beta.kubernetes.io/port_{port}_health-probe_interval Intervalo de sondeo de estado {port} es el número de puerto de servicio.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe El número mínimo de respuestas incorrectas del sondeo de estado {port} es el número de puerto de servicio.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Ruta de acceso de solicitud del sondeo de estado {port} es el número de puerto de servicio.

Tal como se documenta aquí, TCP, Http y Https son tres protocolos admitidos por el servicio de equilibrador de carga.

Actualmente, el protocolo predeterminado del sondeo de estado varía entre los servicios con diferentes protocolos de transporte, protocolos de aplicación, anotaciones y directivas de tráfico externo.

  1. para los servicios locales, se usará HTTP y /healthz. El sondeo de estado consultará NodeHealthPort en lugar del servicio back-end real
  2. para los servicios TCP del clúster, se usará TCP.
  3. para los servicios UDP del clúster, no hay sondeos de estado.

Nota:

En el caso de los servicios locales con la integración de PLS y el protocolo de proxy PLS habilitado, el sondeo de estado HTTP+/healthz predeterminado no funciona. Por lo tanto, el sondeo de estado se puede personalizar de la misma manera que los servicios de clúster para admitir este escenario.

Desde la versión 1.20, se introduce la anotación de servicio service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path para determinar el comportamiento del sondeo de estado.

  • Para los clústeres <=1.23, spec.ports.appProtocol solo se usarán como protocolo de sondeo de estado cuando service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path también se establece.
  • En el caso de los clústeres >1.24, spec.ports.appProtocol se usarán como protocolo de sondeo y / se usarán como ruta de acceso de solicitud de sondeo predeterminada (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path puede usarse para cambiar a una ruta de acceso de solicitud diferente).

Tenga en cuenta que la ruta de acceso de la solicitud se omitirá al usar TCP o el spec.ports.appProtocol está vacío. Más concretamente:

sku de Loadbalancer externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protocolo de sondeo de estado de LB Ruta de acceso de solicitud de sondeo de estado LB
Estándar locales cualquiera cualquiera cualquiera http /healthz
Estándar cluster UDP cualquiera cualquiera null null
Estándar cluster tcp (omitido) tcp null
Estándar cluster tcp tcp (omitido) tcp null
Estándar cluster tcp HTTP/HTTPS TCP(<=1.23) o http/https(>=1.24) null(<=1.23) o /(>=1.24)
Estándar cluster tcp HTTP/HTTPS /custom-path HTTP/HTTPS /custom-path
Estándar cluster tcp protocolo no admitido /custom-path tcp null
basic locales cualquiera cualquiera cualquiera http /healthz
basic cluster tcp (omitido) tcp null
basic cluster tcp tcp (omitido) tcp null
basic cluster tcp http TCP(<=1.23) o http/https(>=1.24) null(<=1.23) o /(>=1.24)
basic cluster tcp http /custom-path http /custom-path
basic cluster tcp protocolo no admitido /custom-path tcp null

Desde la versión 1.21, se introducen dos anotaciones de servicio service.beta.kubernetes.io/azure-load-balancer-health-probe-interval y load-balancer-health-probe-num-of-probe, que personalizan la configuración del sondeo de estado. Si no se establece service.beta.kubernetes.io/azure-load-balancer-health-probe-interval, se aplica el valor predeterminado de 5. Si no se establece load-balancer-health-probe-num-of-probe, se aplica el valor predeterminado de 2. Y el sondeo de estado total debe ser inferior a 120 segundos.

Sondeo de estado de Load Balancer personalizado para el puerto

Los distintos puertos de un servicio pueden requerir configuraciones de sondeo de estado diferentes. Esto puede deberse al diseño del servicio (por ejemplo, un único punto de conexión de mantenimiento que controla varios puertos) o a características de Kubernetes como MixedProtocolLBService.

Las siguientes anotaciones se pueden usar para personalizar la configuración de sondeo de estado por puerto de servicio.

anotación específica del puerto anotación de sondeo de estado global Uso
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (sin equivalente global) si se establece True, no se generarán reglas de LB ni reglas de sondeo de estado
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (sin equivalente global) si se establece True, no se generará ninguna regla de sondeo de estado
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (sin equivalente global) Establecer el protocolo de sondeo de estado para este puerto de servicio (por ejemplo, Http, Https, TCP)
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (sin equivalente global) Establece el puerto de sondeo de estado para este puerto de servicio (por ejemplo, 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path En Http o Https, establece la ruta de acceso de la solicitud de sondeo de estado. El valor predeterminado es /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Número de errores de sondeo de estado consecutivos antes de que el puerto se considere incorrecto
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Cantidad de tiempo entre los intentos de sondeo

Para el siguiente manifiesto, la regla de sondeo para el puerto httpsserver es diferente de la de httpserver porque se especifican anotaciones para el puerto httpsserver.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

En este manifiesto, los puertos https usan un puerto de nodo diferente, una comprobación de preparación HTTP en el puerto 10256 en /healthz(punto de conexión healthz de kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

En este manifiesto, los puertos https usan un punto de conexión de sondeo de estado diferente, una comprobación de preparación HTTP en el puerto 30000 en /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Solución de problemas de SNAT

Si sabe que se van a iniciar muchas conexiones TCP o UDP salientes a la misma dirección IP y puerto de destino, y observa errores en las conexiones salientes, o el soporte técnico le notifica el agotamiento de los puertos SNAT (puertos efímeros asignados previamente usados por PAT), dispone de varias opciones generales para mitigar este problema. Revise estas opciones y decida cuál es mejor para su escenario. Es posible que una o varias de ellas puedan ayudarle a administrar este escenario. Para obtener información detallada, revise la guía de solución de problemas de conexiones salientes.

Con frecuencia, la causa principal del agotamiento de SNAT es un antipatrón de cómo se establece y administra la conectividad de salida o cómo se cambian los temporizadores configurables de sus valores predeterminados. Consulte detenidamente esta sección.

Pasos

  1. Compruebe si las conexiones permanecen inactivas durante mucho tiempo y confíe en el tiempo de expiración de inactividad predeterminado para liberar ese puerto. En tal caso, puede que el tiempo de expiración predeterminado de 30 minutos se deba reducir para su escenario.
  2. Investigue la forma en que la aplicación crea conectividad saliente (por ejemplo la revisión del código o la captura de paquetes).
  3. Determine si esta actividad es el comportamiento esperado o si la aplicación no se comporta correctamente. Use las métricas y los registros de Azure Monitor para apoyar sus conclusiones. Por ejemplo, use la categoría "Error" para la métrica de conexiones SNAT.
  4. Evalúe si se siguen los patrones adecuados.
  5. Evalúe si el agotamiento de puertos SNAT debe mitigarse con más direcciones IP de salida y más puertos de salida asignados.

Patrones de diseño

Aproveche la reutilización de las conexiones y la agrupación de conexiones siempre que sea posible. Estos patrones evitarán problemas de agotamiento de los recursos y el resultado será un comportamiento predecible. Las primitivas de estos patrones se pueden encontrar en muchas bibliotecas y marcos de desarrollo.

  • Las solicitudes atómicas (una solicitud por conexión) no suelen ser una buena decisión de diseño. Estos límites de antipatrón escalan, reducen el rendimiento y disminuyen la confiabilidad. En su lugar, reutilice las conexiones HTTP/S para reducir el número de conexiones y los puertos SNAT asociados. El escalado de la aplicación aumenta y mejora el rendimiento debido a la reducción de los protocolos de enlace, a la sobrecarga y al costo de la operación criptográfica al usar TLS.
  • Si usa DNS personalizado o fuera del clúster, o servidores ascendentes personalizados de coreDNS, tenga en cuenta que DNS puede introducir muchos flujos individuales en el volumen cuando el cliente no almacena en caché el resultado de la resolución DNS. Asegúrese de personalizar coreDNS primero, en lugar de usar servidores DNS personalizados y definir un buen valor de almacenamiento en caché.
  • Los flujos UDP (por ejemplo, las búsquedas de DNS) asignan puertos SNAT mientras dura el tiempo de espera de inactividad. Cuanto mayor sea el tiempo de espera de inactividad, mayor será la presión sobre los puertos SNAT. Use un tiempo de espera de inactividad corto (por ejemplo, 4 minutos).
  • Use los grupos de conexiones para dar forma al volumen de la conexión.
  • Nunca abandone de forma silenciosa un flujo TCP y confíe en temporizadores TCP para limpiar el flujo. Si no permite que TCP cierre explícitamente la conexión, el estado permanecerá asignado en los sistemas y puntos de conexión intermedios y hará que los puertos de SNAT no estén disponibles para otras conexiones. Este patrón puede desencadenar errores en la aplicación y el agotamiento de SNAT.
  • No cambie los valores del temporizador relacionado con el cierre de TCP de nivel de sistema operativo sin el conocimiento experto de impacto. Aunque la pila de TCP se recupera, el rendimiento de la aplicación puede verse afectado negativamente si los puntos de conexión de una conexión tienen expectativas no coincidentes. El deseo de cambiar los temporizadores suele ser un signo de un problema de diseño subyacente. Revise las siguientes recomendaciones.

Traslado de un equilibrador de carga de la SKU básica a la SKU estándar

Si tiene un clúster existente con el equilibrador de carga de SKU básica, existen diferencias de comportamiento importantes que se deben tener en cuenta al migrar al SKU estándar.

Por ejemplo, la realización de implementaciones azul-verde para migrar clústeres es un procedimiento común dado el tipo load-balancer-sku de un clúster y solo se puede definir en el momento de la creación del clúster. Sin embargo, los equilibradores de carga de SKU básica usan direcciones IP de SKU básica que no son compatibles con los equilibradores de carga de SKU estándar. Los equilibradores de carga de SKU estándar requieren direcciones IP de SKU estándar. Al migrar clústeres para actualizar las SKU del equilibrador de carga, se necesitará una nueva dirección IP con una SKU de dirección IP compatible.

Para conocer más detalles sobre cómo migrar clústeres, consulte nuestra documentación con consideraciones sobre la migración.

Limitaciones

Las siguientes limitaciones se aplican al crear y administrar clústeres de AKS que admiten un equilibrador de carga con la SKU estándar:

  • Se requiere al menos una dirección IP pública o un prefijo de dirección IP pública para permitir el tráfico de salida del clúster de AKS. Esta dirección IP o el prefijo de dirección IP pública son necesarios para mantener la conectividad entre el plano de control y los nodos de agente, así como para mantener la compatibilidad con versiones anteriores de AKS. Tiene las siguientes opciones para especificar direcciones IP o prefijos de dirección IP pública con un equilibrador de carga de SKU estándar:
    • Proporcione sus propias IP públicas.
    • Proporcione sus propios prefijos de dirección IP pública.
    • Especifique un número hasta 100 para permitir que el clúster de AKS cree esa cantidad de direcciones IP públicas de SKU estándar en el mismo grupo de recursos que el clúster de AKS. El nombre de este grupo de recursos suele empezar por MC_ al principio. AKS asigna la dirección IP pública al equilibrador de carga de SKU estándar. De forma predeterminada, se crea automáticamente una IP pública en el mismo grupo de recursos que el clúster de AKS si no se especifica ninguna dirección IP pública, prefijo de dirección IP pública o número de direcciones IP. Asimismo, debe permitir las direcciones públicas y evitar la creación de cualquier directiva de Azure que prohíba la creación de direcciones IP.
  • Una dirección IP pública creada con AKS no se puede volver a usar como dirección IP pública propia personalizada. Los usuarios deben crear y administrar todas las direcciones IP personalizadas.
  • La definición de la SKU del equilibrador de carga solo puede realizarse cuando se crea un clúster de AKS. No se puede cambiar la SKU del equilibrador de carga una vez creado un clúster de AKS.
  • Solo se puede usar un tipo de SKU de equilibrador de carga (básica o estándar) en un único clúster.
  • Los equilibradores de carga de SKU estándar solo admiten direcciones IP de SKU estándar.

Pasos siguientes

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

Para más información sobre el uso de un equilibrador de carga interno para el tráfico de entrada, consulte la documentación del equilibrador de carga interno de AKS.