En esta página, se explica cómo crear un balanceador de cargas de red de transferencia interno o un balanceador de cargas interno en Google Kubernetes Engine (GKE). Para crear un balanceador de cargas de red de transferencia externo, aprende a Crear un Service de tipo LoadBalancer.
- Objeto Service LoadBalancer
- Parámetros de Services LoadBalancer.
- Balanceador de cargas de red de transferencia externo basado en servicios de backend.
Usa la subdivisión del balanceador de cargas de red de transferencia interno
Los balanceadores de cargas de red de transferencia internos permiten que los clientes dentro de la red de VPC de tu clúster y los clientes en redes conectadas a la red de VPC de tu clúster puedan acceder a los Services del clúster. No es necesario que los clientes estén ubicados en tu clúster. Por ejemplo, se puede acceder a un objeto Service LoadBalancer interno para las instancias de máquina virtual (VM) que se encuentran en la red de VPC del clúster.
Usa la subdivisión de GKE
La subdivisión de GKE mejora la escalabilidad de los objetos Service LoadBalancer internos porque usa grupos de extremos de red (NEG) de GCE_VM_IP
como backends en lugar de grupos de instancias. Cuando la subdivisión de GKE está habilitada, GKE crea un NEG por zona de procesamiento por cada objeto Service LoadBalancer interno.
Los extremos miembros en el NEG son las direcciones IP de los nodos que tienen al menos uno de los Pods de entrega del objeto Service. Para obtener más información sobre la subdivisión de GKE, consulta Agrupación de nodos.
Requisitos y limitaciones
La subdivisión de GKE tiene los siguientes requisitos y limitaciones:
- Puedes habilitar la subdivisión en clústeres estándar nuevos y existentes en la versión de GKE 1.18.19-gke.1400 y versiones posteriores. La subdivisión de GKE no se puede inhabilitar una vez habilitada.
- La subdivisión de GKE está inhabilitada en los clústeres de Autopilot.
- La subdivisión de GKE requiere que el complemento
HttpLoadBalancing
esté habilitado. Este complemento está habilitado de forma predeterminada. En los clústeres de Autopilot, no puedes inhabilitar este complemento necesario. - Se aplican cuotas para los grupos de extremos de red. Google Cloud crea un NEG
GCE_VM_IP
por Service de LoadBalancer interno por zona. - Se aplican cuotas para las reglas de reenvío, los servicios de backend y las verificaciones de estado. Para obtener más información, consulta Cuotas y límites.
- La subdivisión de GKE no se puede usar con la anotación para compartir un servicio de backend entre varios balanceadores de cargas,
alpha.cloud.google.com/load-balancer-backend-share
. - Debes tener la versión 345.0.0 de Google Cloud CLI o una posterior.
Antes de comenzar
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta
gcloud components update
para obtener la versión más reciente.
Habilita la subdivisión de GKE en un clúster estándar nuevo
Puedes crear un clúster Standard con la subdivisión de GKE habilitada a través de Google Cloud CLI, la consola de Google Cloud o Terraform. Un clúster creado con la subdivisión de GKE habilitada siempre usa la subdivisión de GKE.
Console
Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.
Haz clic en add_box Crear.
Configura tu clúster como desees.
En el panel de navegación, en Clúster, haz clic en Redes.
Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.
Haz clic en Crear.
gcloud
gcloud container clusters create CLUSTER_NAME \
--cluster-version=VERSION \
--enable-l4-ilb-subsetting \
--location=COMPUTE_LOCATION
Reemplaza lo siguiente:
CLUSTER_NAME
es el nombre del clúster nuevo.VERSION
: la versión de GKE, que debe ser 1.18.19-gke.1400 o posterior. También puedes usar la opción--release-channel
para seleccionar un canal de versiones. El canal de versiones debe tener una versión predeterminada 1.18.19-gke.1400 o posterior.COMPUTE_LOCATION
: la ubicación de Compute Engine para el clúster.
Para usar una red o subred no predeterminadas, ejecuta el siguiente comando:
gcloud container clusters create CLUSTER_NAME \
--cluster-version=VERSION \
--network NETWORK_NAME \
--subnetwork SUBNETWORK_NAME \
--enable-l4-ilb-subsetting \
--location=COMPUTE_LOCATION
Reemplaza lo siguiente:
SUBNET_NAME
: es el nombre de la subred nueva. En las versiones de GKE 1.22.4-gke.100 y posteriores, puedes especificar una subred en un proyecto diferente mediante la URL de recurso completamente calificada para este campo. Puedes obtener la URL del recurso completamente calificado mediante el comandogcloud compute networks subnets describe
.NETWORK_NAME
: es el nombre de la red de VPC para la subred.
Terraform
Para crear un clúster Standard con la subdivisión de GKE habilitada a través de Terraform, consulta el siguiente ejemplo:
Si deseas obtener más información sobre el uso de Terraform, consulta Compatibilidad con Terraform para GKE.
Habilita la subdivisión de GKE en un clúster estándar existente
Puedes habilitar la subdivisión de GKE para un clúster estándar existente con la CLI de gcloud o la consola de Google Cloud. No puedes inhabilitar la subdivisión de GKE después de habilitarla.
Consola
En la consola de Google Cloud, ve a la página Google Kubernetes Engine.
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
En Herramientas de redes, junto al campo Subdivisión de balanceadores de cargas internos L4, haz clic en edit Habilitar la subdivisión de balanceadores de cargas internos L4.
Selecciona la casilla de verificación Habilitar subconjunto para balanceadores de cargas internos L4.
Haz clic en Save Changes.
gcloud
gcloud container clusters update CLUSTER_NAME \
--enable-l4-ilb-subsetting
Reemplaza lo siguiente:
CLUSTER_NAME
: el nombre del clúster
La habilitación de la subdivisión de GKE no interrumpe los Services LoadBalancer internos existentes. Si deseas migrar los objetos Service LoadBalancer internos existentes para usar servicios de backend con NEG GCE_VM_IP
como backends, debes implementar un manifiesto de Service de reemplazo. Para obtener más detalles, consulta Agrupación de nodos en la documentación de conceptos del objeto Service LoadBalancer.
Implementa una carga de trabajo
En el siguiente manifiesto, se describe una implementación que ejecuta una imagen de contenedor de aplicación web de muestra.
Guarda el manifiesto como
ilb-deployment.yaml
:apiVersion: apps/v1 kind: Deployment metadata: name: ilb-deployment spec: replicas: 3 selector: matchLabels: app: ilb-deployment template: metadata: labels: app: ilb-deployment spec: containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Aplica el manifiesto al clúster:
kubectl apply -f ilb-deployment.yaml
Crea un objeto Service LoadBalancer interno
En el siguiente ejemplo, se crea un objeto Service LoadBalancer interno mediante el puerto TCP 80
. GKE implementa un balanceador de cargas de red de transferencia interno cuya regla de reenvío usa el puerto 80
, pero luego reenvía el tráfico a los pods de backend en el puerto 8080
:
Guarda el manifiesto como
ilb-svc.yaml
:apiVersion: v1 kind: Service metadata: name: ilb-svc annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer externalTrafficPolicy: Cluster selector: app: ilb-deployment ports: - name: tcp-port protocol: TCP port: 80 targetPort: 8080
El manifiesto debe contener las siguientes características:
- Un
name
para el objeto Service LoadBalancer interno, en este casoilb-svc
. - Una anotación que especifica que necesitas un objeto Service LoadBalancer interno.
Para las versiones de GKE 1.17 y posteriores, usa la anotación
networking.gke.io/load-balancer-type: "Internal"
como se muestra en el manifiesto de ejemplo. Para versiones anteriores, usacloud.google.com/load-balancer-type: "Internal"
en su lugar. - El tipo
type: LoadBalancer
. - Un campo
spec: selector
para especificar los pods a los que se orientará el servicio, por ejemplo,app: hello
. - Información del puerto:
port
representa el puerto de destino en el que la regla de reenvío del balanceador de cargas de red de transferencia interno recibe paquetes.- El
targetPort
debe coincidir con uncontainerPort
definido en cada Pod de entrega. - No es necesario que los valores
port
ytargetPort
sean los mismos. Los nodos siempre realizan NAT de destino y cambian la dirección IP de la regla de reenvío del balanceador de cargas de destino yport
a una dirección IP de Pod de destino ytargetPort
. Para obtener más detalles, consulta Traducción de direcciones de red de destino en nodos en la documentación de conceptos del objeto Service LoadBalancer.
El manifiesto puede contener lo siguiente:
spec.ipFamilyPolicy
yipFamilies
para definir cómo GKE asigna direcciones IP al Service. GKE admite Objetos Service LoadBalancer de IP de pila única (solo IPv4 o solo IPv6) o de pila doble. Un objeto Service LoadBalancer de doble pila se implementa con dos reglas de reenvío del balanceador de cargas de red de transferencia interno separadas: una para el tráfico IPv4 y otra para el tráfico IPv6. El objeto Service LoadBalancer de pila doble de GKE está disponible en la versión 1.29 o posterior. Para obtener más información, consulta Services de pila doble de IPv4/IPv6.
Para obtener más información, consulta los parámetros del objeto Service LoadBalancer.
- Un
Aplica el manifiesto al clúster:
kubectl apply -f ilb-svc.yaml
Obtén información detallada sobre el servicio:
kubectl get service ilb-svc --output yaml
El resultado es similar a este:
apiVersion: v1 kind: Service metadata: annotations: cloud.google.com/neg: '{"ingress":true}' cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}' kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}} networking.gke.io/load-balancer-type: Internal service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r creationTimestamp: "2022-07-22T17:26:04Z" finalizers: - gke.networking.io/l4-ilb-v2 - service.kubernetes.io/load-balancer-cleanup name: ilb-svc namespace: default resourceVersion: "51666" uid: d7a1a865-7972-44e1-aa9e-db5be23d6567 spec: allocateLoadBalancerNodePorts: true clusterIP: 10.88.2.141 clusterIPs: - 10.88.2.141 externalTrafficPolicy: Cluster internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: tcp-port nodePort: 30521 port: 80 protocol: TCP targetPort: 8080 selector: app: ilb-deployment sessionAffinity: None type: LoadBalancer status: loadBalancer: ingress: - ip: 10.128.15.245
El resultado tiene los siguientes atributos:
- La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno se incluye en
status.loadBalancer.ingress
. Esta dirección IP es diferente del valor declusterIP
. En este ejemplo, la dirección IP de la regla de reenvío del balanceador de cargas es10.128.15.245
. - Cualquier Pod que tenga la etiqueta
app: ilb-deployment
es un Pod de entrega para este Service. Estos son los Pods que reciben paquetes enrutados por el balanceador de cargas de red de transferencia interno. - Los clientes llaman al Service mediante esta dirección IP de
loadBalancer
y el puerto de destino TCP especificado en el campoport
del manifiesto del Service. Para obtener detalles completos sobre cómo se enrutan los paquetes una vez que un nodo los recibe, consulta Procesamiento de paquetes. - GKE asignó un
nodePort
al objeto Service. En este ejemplo, se asigna el puerto30521
. ElnodePort
no es relevante para el balanceador de cargas de red de transferencia interno.
- La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno se incluye en
Inspecciona el grupo de extremos de red de Service:
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
El resultado es similar a este:
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
La respuesta indica que GKE creó un grupo de extremos de red llamado
k8s2-knlc4c77-default-ilb-svc-ua5ugas0
. Esta anotación está presente en los servicios del tipoLoadBalancer
que utilizan la subdivisión de GKE y no está presente en los Services que no usan la subdivisión de GKE.
Verifica los componentes del balanceador de cargas de red de transferencia interno
La dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno es 10.128.15.245
en el ejemplo incluido en la sección Crea un Service LoadBalancer interno. Puedes ver que esta regla de reenvío se incluye en la lista de reglas de reenvío del proyecto del clúster mediante Google Cloud CLI:
gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
El resultado incluye la regla de reenvío del balanceador de cargas de red de transferencia interno relevante, su dirección IP y el servicio de backend al que hace referencia la regla de reenvío (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
).
NAME ... IP_ADDRESS ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r 10.128.15.245 ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
Puedes describir el servicio de backend del balanceador de cargas mediante Google Cloud CLI:
gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
Reemplaza COMPUTE_REGION
por la región de procesamiento del servicio de backend.
El resultado incluye el NEG GCE_VM_IP
de backend o los NEGs para el Service (en este ejemplo, k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
):
backends:
- balancingMode: CONNECTION
group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...
A fin de determinar la lista de nodos en el subconjunto de un servicio, usa el siguiente comando:
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
--zone=COMPUTE_ZONE
Reemplaza lo siguiente:
NEG_NAME
: el nombre del grupo de extremos de red que crea el controlador de GKE.COMPUTE_ZONE
: La zona de procesamiento de extremos de red en la que se operará.
Para determinar la lista de nodos en buen estado para un balanceador de cargas de red de transferencia interno, usa el siguiente comando:
gcloud compute backend-services get-health SERVICE_NAME \
--region=COMPUTE_REGION
Reemplaza lo siguiente:
SERVICE_NAME
: el nombre del servicio de backend. Este valor es el mismo que el nombre del grupo de extremos de red creado por el controlador de GKE.COMPUTE_REGION
: es la región de procesamiento del servicio de backend en la que se operará.
Prueba la conectividad al balanceador de cargas de red de transferencia interno
Establece una conexión SSH a una instancia de VM en la misma red de VPC y en la misma región que el clúster, luego, ejecuta el siguiente comando:
curl LOAD_BALANCER_IP:80
Reemplaza LOAD_BALANCER_IP
por la dirección IP de la regla de reenvío del balanceador de cargas.
La respuesta muestra la salida de ilb-deployment
:
Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n
Solo se puede acceder al balanceador de cargas de red de transferencia interno dentro de la misma red de VPC (o una red conectada). De forma predeterminada, la regla de reenvío del balanceador de cargas tiene inhabilitado el acceso global, por lo que las VMs de cliente, los túneles de Cloud VPN o los adjuntos de Cloud Interconnect (VLAN) deben estar ubicados en la misma región que el balanceador de cargas de red de transferencia interno. Para admitir clientes en todas las regiones, puedes habilitar el acceso global en la regla de reenvío del balanceador de cargas si incluyes la anotación de acceso global en el manifiesto del objeto Service.
Borra el objeto Service LoadBalancer interno y los recursos del balanceador de cargas
Puedes borrar los objetos Deployment y Service con kubectl delete
o la consola de Google Cloud.
kubectl
Borra la implementación
Para borrar la implementación, ejecuta el siguiente comando:
kubectl delete deployment ilb-deployment
Borra el servicio
Para borrar el servicio, ejecuta el siguiente comando:
kubectl delete service ilb-svc
Consola
Borra la implementación
Para borrar la implementación, sigue estos pasos:
Ve a la página Cargas de trabajo en la consola de Google Cloud.
Selecciona la implementación que deseas borrar y, luego, haz clic en delete Borrar.
Cuando se le solicite que confirme la acción, seleccione la casilla de verificación Borrar el escalador automático horizontal del Pod asociado con la implementación seleccionada y, luego, haga clic en Borrar.
Borra el servicio
Para borrar el servicio, sigue estos pasos:
Ve a la página Ingress y servicios en la consola de Google Cloud.
Selecciona el servicio que quieres borrar y, luego, haz clic en delete Borrar.
Cuando se te solicite confirmar, haz clic en Borrar.
IP compartida
El balanceador de cargas de red de transferencia interno permite el uso compartido de una dirección IP virtual entre varias reglas de reenvío.
Esto es útil para expandir la cantidad de puertos simultáneos en la misma IP o aceptar tráfico de UDP y TCP en la misma IP. Permite un máximo de 50 puertos expuestos por dirección IP. Las IP compartidas se admiten de forma nativa en los clústeres de GKE con servicios de LoadBalancer internos.
Cuando se implementa, el campo loadBalancerIP
del servicio se usa para indicar qué IP se debe compartir entre los servicios.
Limitaciones
Una IP compartida para varios balanceadores de cargas tiene las siguientes limitaciones y capacidades:
- Cada servicio (o regla de reenvío) puede tener un máximo de cinco puertos.
- Un máximo de diez servicios (reglas de reenvío) pueden compartir una dirección IP. Esto da como resultado un máximo de 50 puertos por IP compartida.
- Cada regla de reenvío que comparte la misma dirección IP debe usar una combinación única de protocolos y puertos. Por lo tanto, cada objeto Service LoadBalancer interno debe usar un conjunto único de protocolos y puertos.
- Se admite una combinación de servicios de solo TCP y de solo UDP en la misma IP compartida. Sin embargo, no puedes exponer ambos puertos de TCP y UDP en el mismo servicio.
Habilita la IP compartida
Si deseas habilitar que los servicios de LoadBalancer internos compartan una IP común, sigue estos pasos:
Crea una IP interna estática con
--purpose SHARED_LOADBALANCER_VIP
. Se debe crear una dirección IP con esta finalidad para habilitar su capacidad de ser compartida. Si creas la dirección IP interna estática en una VPC compartida, debes crear la dirección IP en el mismo proyecto de servicio que la instancia que usará la dirección IP, aunque el valor de la dirección IP vendrá del rango de IP disponibles en una subred compartida seleccionada de la red de VPC compartida. Consulta Reserva una IP interna estática en la página Aprovisiona la VPC compartida para obtener más información.Implementa hasta diez servicios de LoadBalancer internos mediante esta IP estática en el campo
loadBalancerIP
. El controlador del servicio de GKE concilia los balanceadores de cargas de red de transferencia internos y estos se implementan mediante la misma IP de frontend.
En el siguiente ejemplo, se muestra cómo hacer esto con el fin de admitir varios puertos de TCP y UDP en la misma IP del balanceador de cargas interno.
Crea una IP estática en la misma región en la que se encuentra el clúster de GKE. La subred debe ser la misma que usa el balanceador de cargas. De forma predeterminada, es la misma subred que usan las IP del nodo del clúster de GKE.
Si tu clúster y la red de VPC están en el mismo proyecto, haz lo siguiente:
gcloud compute addresses create IP_ADDR_NAME \ --project=PROJECT_ID \ --subnet=SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP
Si tu clúster está en un proyecto de servicio de VPC compartida, pero usa una red de VPC compartida en un proyecto host, haz lo siguiente:
gcloud compute addresses create IP_ADDR_NAME \ --project=SERVICE_PROJECT_ID \ --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \ --addresses=IP_ADDRESS \ --region=COMPUTE_REGION \ --purpose=SHARED_LOADBALANCER_VIP
Reemplaza lo siguiente:
IP_ADDR_NAME
: un nombre para el objeto de dirección IPSERVICE_PROJECT_ID
: el ID del proyecto de servicioPROJECT_ID
: el ID de tu proyecto (proyecto único)HOST_PROJECT_ID
: el ID del proyecto host de la VPC compartidaCOMPUTE_REGION
: es la región de procesamiento que contiene la subred compartida.IP_ADDRESS
: una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada Si omites especificar una dirección IP, Google Cloud selecciona una dirección IP interna sin usar del rango de direcciones IP principal de la subred seleccionada. Para determinar una dirección seleccionada de forma automática, deberás ejecutargcloud compute addresses describe
.SUBNET
: el nombre de la subred compartida
Guarda la siguiente configuración del servicio de TCP en un archivo llamado
tcp-service.yaml
y, luego, impleméntala en el clúster. ReemplazaIP_ADDRESS
por la dirección IP que elegiste en el paso anterior.apiVersion: v1 kind: Service metadata: name: tcp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: myapp ports: - name: 8001-to-8001 protocol: TCP port: 8001 targetPort: 8001 - name: 8002-to-8002 protocol: TCP port: 8002 targetPort: 8002 - name: 8003-to-8003 protocol: TCP port: 8003 targetPort: 8003 - name: 8004-to-8004 protocol: TCP port: 8004 targetPort: 8004 - name: 8005-to-8005 protocol: TCP port: 8005 targetPort: 8005
Aplica esta definición de servicio en el clúster:
kubectl apply -f tcp-service.yaml
Guarda la siguiente configuración del servicio de UDP en un archivo llamado
udp-service.yaml
y, luego, impleméntala. También usa elIP_ADDRESS
que especificaste en el paso anterior.apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: my-udp-app ports: - name: 9001-to-9001 protocol: UDP port: 9001 targetPort: 9001 - name: 9002-to-9002 protocol: UDP port: 9002 targetPort: 9002
Aplica este archivo en el clúster:
kubectl apply -f udp-service.yaml
Para validar que la VIP se comparta entre las reglas de reenvío del balanceador de cargas, enuméralas y filtra la IP estática. Esto muestra que hay una regla de reenvío de UDP y una de TCP que escuchan en siete puertos diferentes en el
IP_ADDRESS
compartido, que en este ejemplo es10.128.2.98
.gcloud compute forwarding-rules list | grep 10.128.2.98 ab4d8205d655f4353a5cff5b224a0dde us-west1 10.128.2.98 UDP us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde acd6eeaa00a35419c9530caeb6540435 us-west1 10.128.2.98 TCP us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
Restricciones y límites
Restricciones para los balanceadores de cargas de red de transferencia internos
- Para los clústeres que ejecutan Kubernetes versión 1.7.4 o superior, pueden usar balanceadores de cargas internos con subredes modo personalizado además de las subredes en modo automático
- Los clústeres que ejecutan Kubernetes versión 1.7.X y posteriores admiten el uso de una dirección IP reservada para el balanceador de cargas de red de transferencia interno si creas la dirección IP reservada con la marca
--purpose
establecida enSHARED_LOADBALANCER_VIP
. Para obtener instrucciones paso a paso, consulta Habilita IP compartida. GKE solo conserva la dirección IP de un balanceador de cargas de red de transferencia interno si el Service hace referencia a una dirección IP interna con ese propósito. De lo contrario, GKE podría cambiar la dirección IP del balanceador de cargas (spec.loadBalancerIP
) si el servicio se actualiza (por ejemplo, si se cambian los puertos). - Incluso si la dirección IP del balanceador de cargas cambia (consulta el punto anterior), el
spec.clusterIP
permanece constante.
Restricciones para balanceadores de cargas de UDP internos
- Los balanceadores de cargas UDP internos no son compatibles con
sessionAffinity: ClientIP
.
Problemas conocidos
Tiempo de espera de conexión cada 10 minutos
Los servicios LoadBalancer internos creados con subdivisión pueden observar interrupciones del tráfico cada 10 minutos, aproximadamente. Este error se corrigió en las siguientes versiones:
- 1.18.19-gke.1700 y posteriores
- 1.19.10-gke.1000 y posteriores
- 1.20.6-gke.1000 y posteriores
Error durante la creación del balanceador de cargas en el nivel Estándar
Cuando creas un balanceador de cargas de red de transferencia interno en un proyecto con el nivel de red predeterminado del proyecto configurado como Estándar, aparece el siguiente mensaje de error:
Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest
Para resolver este problema en las versiones de GKE anteriores a 1.23.3-gke.900, configura el nivel de red predeterminado del proyecto como Premium.
Este problema se resuelve en las versiones 1.23.3-gke.900 y posteriores de GKE cuando la subdivisión de GKE está habilitada.
El controlador de GKE crea balanceadores de cargas de red de transferencia internos en el nivel de red Premium, incluso si el nivel de red predeterminado del proyecto está configurado en Estándar.
¿Qué sigue?
- Consulta la descripción general de la red GKE.
- Más información sobre el balanceador de cargas de Compute Engine.
- Obtén información para crear un clúster nativo de la VPC.