Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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:
- Cambie el tipo de grupo de entrada.
- Establezca o escale el número de direcciones IP de salida administradas.
- Proporcione sus propias direcciones IP de salida personalizadas o prefijo IP de salida.
- Personalice el número de puertos de salida asignados a cada nodo del clúster.
- Configure el valor de tiempo de espera para las conexiones inactivas.
Importante
Solo puede usar una opción de IP de salida (direcciones IP administradas, traer su propia dirección IP o prefijo de IP) al mismo tiempo.
Antes de empezar
- Siga los pasos descritos en Uso de un equilibrador de carga estándar público en Azure Kubernetes Service (AKS) para crear e implementar un servicio de equilibrador de carga en AKS.
Cambio del tipo de grupo de entrada
Puede hacer referencia a los nodos de AKS en los grupos de back-end del equilibrador de carga mediante su configuración ip (pertenencia basada en Azure Virtual Machine Scale Sets) o solo su dirección IP. La pertenencia al grupo de back-end basado en direcciones IP proporciona mayores eficiencias al actualizar servicios y aprovisionar equilibradores de carga, especialmente en recuentos altos de nodos. Cuando se combina con NAT Gateway o tipos de enrutamiento de salida 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 basado en IP.
Requisitos para cambiar el tipo de grupo entrante
Asegúrese de cumplir los siguientes requisitos antes de cambiar el tipo de grupo de entrada:
- 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.
- Crear un nuevo clúster de AKS con membresía de grupo de entrada basada en IP
- Actualizar un clúster existente de AKS para utilizar la membresía basada en IP del grupo de entrada
Cree un clúster de AKS con pertenencia al grupo de entrada basada en IP usando el comando
az aks createcon el parámetro--load-balancer-backend-pool-type=nodeIP.az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --load-balancer-backend-pool-type=nodeIP \ --generate-ssh-keys
Escalar el número de direcciones IP públicas de salida administradas.
Azure Load Balancer proporciona conectividad saliente e entrante 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 el equilibrio de carga y las reglas NAT de entrada: direcciones IP de frontend + parámetros + grupo de servidores back-end
Una regla de salida configura el NAT de salida para todas las máquinas virtuales (VM) identificadas por el grupo de back-end para traducirse al 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.
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 del equilibrador de carga se eliminan cada vez que se reconcilia el clúster, como cuando se detiene, se inicia, se actualiza o se escala.
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.
Establecer el número de direcciones IP públicas de salida administradas
- Creación de un clúster con un número específico de direcciones IP públicas de salida administradas
- Actualización de un clúster existente para escalar el número de direcciones IP públicas de salida administradas
Cree un nuevo clúster de AKS con un número específico de direcciones IP públicas de salida administradas usando el comando
az aks createcon el parámetro--load-balancer-managed-outbound-ip-count. En el ejemplo siguiente se establece el número de direcciones IP públicas de salida administradas en dos.az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --load-balancer-managed-outbound-ip-count 2 \ --generate-ssh-keys
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 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 sus propias direcciones IP o prefijos públicos salientes
Asegúrese de cumplir los siguientes requisitos antes de proporcionar sus propias direcciones IP o prefijos públicos salientes:
- Debe crear y poseer direcciones IP públicas personalizadas. No puede reutilizar las direcciones IP públicas administradas creadas por AKS como "traiga su propia dirección IP personalizada" porque puede provocar conflictos de administración.
- Debe asegurarse de que la identidad del clúster de AKS tiene permisos para acceder a la dirección IP de salida, según la lista de permisos de IP pública necesaria.
- Asegúrese de que cumple los requisitos previos y las restricciones necesarias para configurar IP de salida o prefijos de IP de salida.
Proporcione sus propias direcciones IP públicas salientes.
- Proporcione sus propias direcciones IP públicas salientes al crear un nuevo clúster.
- Actualización de un clúster existente para usar sus propias direcciones IP públicas salientes
Cree un nuevo clúster de AKS con sus propias direcciones IP públicas salientes usando el comando
az aks createcon el parámetro--load-balancer-outbound-ips. Asegúrese de reemplazar los valores de marcador de posición por los suyos propios.az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --load-balancer-outbound-ips $PUBLIC_IP_ID1,$PUBLIC_IP_ID2 \ --generate-ssh-keys
Proporcione sus propios prefijos de IP pública de salida.
- Proporcione sus propios prefijos de dirección IP pública salientes al crear un nuevo clúster
- Actualice un clúster existente para usar su propio prefijo de IP pública saliente
Cree un nuevo clúster de AKS con los prefijos de dirección IP pública salientes propios mediante el comando
az aks createcon el parámetro--load-balancer-outbound-ip-prefixes. Asegúrese de reemplazar los valores de marcador de posición por los suyos propios.az aks create \ --name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP \ --load-balancer-outbound-ip-prefixes $PUBLIC_IP_PREFIX_ID1,$PUBLIC_IP_PREFIX_ID2 \ --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 susceptible de encontrar agotamiento de puertos SNAT, se recomienda encarecidamente aumentar los puertos de salida asignados y las direcciones IP salientes de front-end 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 los recuentos de nodos a través de los límites del gráfico (por ejemplo, pasar de 50 a 51 nodos o 100 a 101) podría resultar perjudicial para la conectividad, ya que los puertos SNAT asignados a los nodos existentes se reducen para permitir más nodos. Se recomienda usar un valor explícito para AllocatedOutboundPorts.
Visualización de los puertos de salida asignados actuales
Obtenga el valor AllocatedOutboundPorts del equilibrador de carga del clúster de AKS mediante el
az network lb outbound-rule listcomando .NODE_RG=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query nodeResourceGroup -o tsv) az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o tableEn la salida de ejemplo siguiente se muestra que la asignación automática de puertos salientes en función del tamaño del grupo de back-end está habilitada para el clúster:
AllocatedOutboundPorts EnableTcpReset IdleTimeoutInMinutes Name Protocol ProvisioningState ResourceGroup ------------------------ ---------------- ---------------------- --------------- ---------- ------------------- ------------- 0 True 30 aksOutboundRule All Succeeded MC_myResourceGroup_myAKSCluster_eastus
Cálculo y comprobación de los puertos y direcciones IP de salida necesarios
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>.
Consideraciones para calcular los puertos de salida y las direcciones IP
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 pueden agregar como parte de las actualizaciones, incluido el recuento de nodos especificados a través de los valores
maxCountymaxSurge.
Ejemplos de cálculo de puertos y direcciones IP de salida
Los siguientes ejemplos muestran cómo los valores que establezca afectan al número de puertos de salida y direcciones IP:
- Si se utilizan los valores por defecto y el clúster tiene 48 nodos, cada nodo tiene 1 024 puertos disponibles.
- Si se utilizan los valores por defecto y el clúster se escala de 48 a 52 nodos, cada nodo se actualiza de 1 024 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 y direcciones IP de salida, compruebe que tiene capacidad adicional de puerto de salida para controlar el aumento de nodos durante las actualizaciones. Es fundamental asignar suficientes puertos excesivos para nodos adicionales necesarios para la actualización y otras operaciones. AkS tiene como valor predeterminado un nodo de búfer para las operaciones de actualización. Si usa maxSurge valores, multiplique los puertos de salida por nodo por su maxSurge valor para determinar el número de puertos necesarios. Por ejemplo, si calcula que necesita 4000 puertos por nodo con 7 direcciones IP en un clúster con un máximo de 100 nodos y un aumento 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 este ejemplo se muestra que el clúster tiene una capacidad excesiva de 48 000 puertos, lo que es suficiente para controlar los 8000 puertos necesarios para el aumento del nodo durante las actualizaciones.
Establecer los puertos de salida asignados y las direcciones IP salientes
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.
- Creación de un clúster con puertos e direcciones IP de salida específicos
- Actualización de un clúster existente con puertos e direcciones IP de salida específicos
Cree un nuevo clúster de AKS con puertos e direcciones IP de salida específicos mediante el
az aks createcomando . En el ejemplo siguiente se establece el--load-balancer-managed-outbound-ip-countparámetro en 7 y el--load-balancer-outbound-portsparámetro en 4000:az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --load-balancer-managed-outbound-ip-count 7 \ --load-balancer-outbound-ports 4000 \ --generate-ssh-keys
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.
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. Para más información, consulte Restablecimiento de TCP del equilibrador de carga de Azure.
Cuando configure IdleTimeoutInMinutes con un valor distinto al predeterminado de 30 minutos, tenga en cuenta cuánto tiempo necesitan sus cargas de trabajo una conexión saliente. Tenga en cuenta también que el valor de tiempo de espera predeterminado para un equilibrador de carga de SKU estándar que se usa 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 Solución de problemas de SNAT y revise las reglas de salida del equilibrador de carga y las conexiones salientes en Azure antes de actualizar estos valores para comprender completamente el impacto de los cambios.
- Creación de un clúster con un tiempo de espera de inactividad específico
- Actualización de un clúster existente con un tiempo de espera de inactividad específico
Cree un nuevo clúster de AKS con un tiempo de espera de inactividad específico mediante el
az aks createcomando con el--load-balancer-idle-timeoutparámetro . En el ejemplo siguiente se establece el tiempo de espera de inactividad en 4 minutos:az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --load-balancer-idle-timeout 4 \ --generate-ssh-keys
Restricción del tráfico entrante a intervalos IP específicos
El siguiente manifiesto 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 IP internas del clúster, los clientes externos a su clúster Kubernetes no podrán acceder al equilibrador de carga.
Nota:
Tenga en cuenta la siguiente información al restringir el tráfico entrante:
- Cuando necesite permitir los bloques CIDR y las etiquetas de servicio de Azure, quite la
loadBalancerSourceRangespropiedad y agregue las anotacionesservice.beta.kubernetes.io/azure-allowed-ip-rangesy/oservice.beta.kubernetes.io/azure-allowed-service-tagsLoad Balancer. Esta configuración solo aplica el filtrado en la capa de NSG y omite las reglas kube-proxy de nivel de host. Si establece laloadBalancerSourceRangespropiedad junto con laazure-allowed-service-tagsanotación, AKS notificará un error al intentar aplicar la especificación. - De entrada, el tráfico externo fluye desde el equilibrador de carga a la red virtual del 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 del Pod debe agregarse a
loadBalancerSourceRangessi hay Pods que necesitan acceder a la dirección IP del Equilibrador de Carga del servicio para clústeres con Kubernetes versión 1.25 o posterior.
Mantenimiento de la dirección IP del cliente en las conexiones entrantes
Por defecto, un servicio de tipo LoadBalanceren Kubernetes y en AKS no persiste la dirección IP del cliente en la conexión al pod. La IP de origen del paquete que se entrega al pod se convierte en la IP privada del nodo. Para mantener la dirección IP del cliente, debe establecer service.spec.externalTrafficPolicy a local en la definición del servicio. En el manifiesto siguiente 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 | Importancia | Description |
|---|---|---|
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, la entrada DNS en la IP pública no se utiliza. |
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-allowed-ip-ranges |
lista de intervalos IP permitidos | Especifique una lista de intervalos IP permitidos separados 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 que se asignará al equilibrador de carga. |
service.beta.kubernetes.io/azure-load-balancer-ipv6 |
Dirección IPv6 | Especifique la dirección IPv6 que se asignará al equilibrador de carga. |
Personalización de intervalos IP permitidos (versión preliminar)
Puede usar las anotaciones azure-allowed-service-tags y azure-allowed-ip-ranges para combinar bloques CIDR y etiquetas de servicio de Azure en un equilibrador de carga. Agregue service.beta.kubernetes.io/azure-allowed-ip-ranges con una lista separada por comas de prefijos IP y agregue service.beta.kubernetes.io/azure-allowed-service-tags con una o varias etiquetas de servicio de Azure. El proveedor de nube de AKS combina ambos valores en una sola regla de NSG, de modo que el tráfico se filtra de forma centralizada en el NSG, ofreciéndole un único plano de control centrado en NSG tanto para las direcciones IP como para las etiquetas de servicio.
Puede seguir usando la loadBalancerSourceRanges propiedad para los casos en los que quiera aplicar restricciones basadas en CIDR tanto en el NSG como en el host. No se puede usar esta propiedad con la azure-allowed-service-tags anotación . Si se especifican ambos, AKS notifica un error al intentar aplicar la especificación del servicio del equilibrador de carga.
Personalización del sondeo de estado del equilibrador de carga
Se admiten las siguientes anotaciones para personalizar el comportamiento del sondeo de estado del equilibrador de carga:
| Anotación | Importancia | Description |
|---|---|---|
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 generan reglas de sondeo de estado ni equilibrador de carga para este puerto. El servicio de comprobación de estado no debe exponerse a la red pública de Internet. |
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 generan reglas 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. |
Nota:
AKS ahora ofrece compatibilidad con pruebas de estado compartidas para externalTrafficPolicy: Cluster Servicios. Para más información, consulte Uso de sondeos de estado compartidos para externalTrafficPolicy: Cluster servicios (versión preliminar) en Azure Kubernetes Service (AKS).
Comportamiento predeterminado de la prueba de estado de salud
Actualmente, el protocolo predeterminado de la sonda de salud varía entre los servicios con diferentes protocolos de transporte, protocolos de aplicación, anotaciones y políticas de tráfico externo.
- En el caso de los servicios locales, se usaría HTTP y /healthz. El sondeo de estado consultará
NodeHealthPorten lugar del servicio back-end real. - En el caso de los servicios TCP del clúster, se usaría TCP.
- En los servicios UDP del clúster, no hay probes de salud.
Nota:
Para los servicios locales con la integración de PLS y el protocolo de proxy PLS habilitados, el sondeo de estado HTTP y /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.
Anotación de ruta de solicitud de sonda de salud
A partir de la versión 1.20 de Kubernetes, la anotación service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path del servicio se introdujo para determinar el comportamiento del sondeo de estado.
- Para los clústeres <=1.23,
spec.ports.appProtocolsolo se usarán como protocolo de sondeo de estado cuandoservice.beta.kubernetes.io/azure-load-balancer-health-probe-request-pathtambién se establece. - En el caso de los clústeres >1.24,
spec.ports.appProtocolse 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-pathpuede 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. En la tabla siguiente se resume el comportamiento predeterminado de la sonda de estado.
| balanceador de carga SKU | externalTrafficPolicy |
spec.ports.Protocol | spec.ports.AppProtocol | service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path |
Protocolo de sondeo de LB | Ruta de solicitud de sondeo del equilibrador de carga |
|---|---|---|---|---|---|---|
| standard | local | any | any | any | HTTP | /healthz |
| standard | conglomerado | udp | any | any | nulo | nulo |
| standard | conglomerado | tcp | (ignored) | tcp | nulo | |
| standard | conglomerado | tcp | tcp | (ignored) | tcp | nulo |
| standard | conglomerado | tcp | http/https | TCP(<=1.23) o http/https(>=1.24) | null(<=1.23) o /(>=1.24) |
|
| standard | conglomerado | tcp | http/https | /custom-path |
http/https | /custom-path |
| standard | conglomerado | tcp | protocolo no admitido | /custom-path |
tcp | nulo |
| básico | local | any | any | any | HTTP | /healthz |
| básico | conglomerado | tcp | (ignored) | tcp | nulo | |
| básico | conglomerado | tcp | tcp | (ignored) | tcp | nulo |
| básico | conglomerado | tcp | HTTP | TCP(<=1.23) o http/https(>=1.24) | null(<=1.23) o /(>=1.24) |
|
| básico | conglomerado | tcp | HTTP | /custom-path |
HTTP | /custom-path |
| básico | conglomerado | tcp | protocolo no admitido | /custom-path |
tcp | nulo |
Intervalo de sondeo de salud y número de registros de sondeo
A partir de la versión 1.21 de Kubernetes, se introdujeron 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 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval no se establece, se aplica un valor predeterminado de 5 . Si load-balancer-health-probe-num-of-probe no se establece, se aplica un valor predeterminado de 2 .
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.
En la tabla siguiente se resumen las anotaciones específicas del puerto que se pueden usar para invalidar las anotaciones de sondeo de estado global para un puerto específico en el servicio:
| Anotación específica del puerto | Anotación de sonda global | Comportamiento |
|---|---|---|
service.beta.kubernetes.io/port_{port}_no_lb_rule |
N/A (sin equivalente global) | Si se establece en true, no se generan reglas de sondeo o equilibrador de carga. |
service.beta.kubernetes.io/port_{port}_no_probe_rule |
N/A (sin equivalente global) | Si se establece en true, no se generan reglas de sondeo. |
service.beta.kubernetes.io/port_{port}_health-probe_protocol |
N/A (sin equivalente global) | Establece 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 comprobación 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 |
Para Http o Https, establece la ruta de solicitud de sondeo de estado (de manera predeterminada, 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 fallos de sondeo consecutivos antes de que el puerto se considere no operativo. |
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. |
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.