Balanceo de cargas nativo del contenedor con NEG independientes

En esta página, se muestra cómo crear un Service de Kubernetes con el respaldo de un grupo de extremos de red (NEG) zonal.

Consulta Balanceo de cargas nativo del contenedor para obtener información sobre los beneficios, los requisitos y las limitaciones del balanceo de cargas nativo del contenedor.

Descripción general

Un grupo de extremos de red (NEG) representa un grupo de backends que entrega un balanceador de cargas. Los NEG son listas de direcciones IP que administra un controlador de NEG y que usan los balanceadores de cargas de Google Cloud. Las direcciones IP en un NEG pueden ser direcciones IP principales o secundarias de una VM, lo que significa que pueden ser IP de pods. Esto habilita el balanceo de cargas nativo del contenedor que envía tráfico directamente a los Pods desde un balanceador de cargas de Google Cloud.

En el siguiente diagrama, se describe cómo se corresponden los objetos de la API de Kubernetes con los objetos de Compute Engine.

Los objetos Service de Kubernetes corresponden a los grupos de extremos de red de Compute Engine, y los Pods de Kubernetes corresponden a los extremos de red de Compute Engine. A esto lo administra el componente del controlador de NEG de la instancia principal de GKE.

Ingress con NEG

Cuando los NEG se usan con Ingress de GKE, el controlador de Ingress facilita la creación de todos los aspectos del balanceador de cargas L7. Esto incluye la creación de la dirección IP virtual, las reglas de reenvío, las verificaciones de estado, las reglas de firewall y mucho más.

Ingress es la forma recomendada de usar el balanceo de cargas nativo del contenedor, ya que tiene muchas funciones que simplifican la administración de los NEG. También, existe la opción de los NEG independientes si los NEG que administra Ingress no entregan tu caso práctico.

NEG independientes

Cuando los NEG se implementan con balanceadores de cargas y no es Ingress el que los aprovisiona, se consideran NEG independientes. Los NEG independientes se implementan y administran a través del controlador de NEG, pero las reglas de reenvío, las verificaciones de estado y otros objetos de balanceo de cargas se implementan de forma manual.

Los NEG independientes no entran en conflicto con el balanceo de cargas nativo del contenedor habilitado de Ingress.

En la siguiente ilustración, se muestran las distintas formas en que se implementan los objetos de balanceo de cargas en cada situación:

Con los NEG independientes y los que administra Ingress, el controlador de NEG en la instancia principal de GKE administra los objetos de extremo de red y el NEG. Con los NEG independientes, el usuario administra todos los otros componentes como se describe en los párrafos anteriores.

Casos prácticos de NEG independientes

Los NEG independientes tienen varios usos críticos. Son muy flexibles. Esto contrasta con Ingress (este se usa con o sin NEG), que define un conjunto específico de objetos de balanceo de cargas que se eligieron de una manera bien definida para facilitar su uso.

Los casos prácticos para los NEG independientes incluyen los siguientes:

Servicios heterogéneos de contenedores y VM

Los NEG pueden contener direcciones IP de contenedores y VM. Esto significa que una sola dirección IP virtual puede apuntar a un backend que consta de cargas de trabajo de Kubernetes y de cargas de trabajo que no son de Kubernetes. Esto también se puede usar para migrar las cargas de trabajo existentes a un clúster de GKE.

Los NEG independientes pueden apuntar a las IP de VM, lo que permite configurar de forma manual los balanceadores de cargas para que apunten a backends que se componen por VM y contenedores de la misma VIP de servicio.

Controladores de Ingress personalizados

Puedes usar un controlador de Ingress personalizado (o que no sea de Ingress) para configurar balanceadores de cargas que se dirigen a los NEG independientes.

Usa Traffic Director con GKE

Traffic Director con GKE. Traffic Director usa los NEG independientes a fin de proporcionar balanceo de cargas nativo del contenedor para la malla de servicios administrados.

Usa el balanceo de cargas del proxy TCP con GKE

Puedes usar NEG independientes para balancear las cargas directamente a los contenedores con el balanceador de cargas del proxy TCP que no es compatible de forma nativa con Kubernetes/GKE.

Preparación del pod

Las Puertas de preparación son una función de extensibilidad de Kubernetes que permite la inserción de comentarios o indicadores adicionales en el PodStatus para permitir que el pod pase al estado Listo. El controlador de NEG administra una puerta de preparación personalizada para garantizar que toda la ruta de red, desde el balanceador de cargas de Compute Engine hasta el pod, sea funcional. Las puertas de preparación de pods en GKE se explican en el balanceo de cargas nativo del contenedor.

Ingress con NEG implementa y administra las verificaciones de estado de Compute Engine en nombre del balanceador de cargas. Sin embargo, los NEG independientes no realizan suposiciones sobre las verificaciones de estado de Compute Engine porque se espera que se implementen y administren por separado. Las verificaciones de estado de Compute Engine siempre deben configurarse junto con el balanceador de cargas a fin de evitar que el tráfico se envíe a los backends que no estén listos para recibir. Si no hay un estado de verificación de estado asociado con el NEG (por lo general, porque no se configuró ninguna verificación de estado), el controlador de NEG marcará el valor de la puerta de preparación de Pods como Verdadero cuando se programe su extremo correspondiente en NEG.

Requisitos

Los NEG independientes están disponibles en GKE 1.10 y versiones posteriores. Los comentarios de la preparación de Pods están habilitados para los NEG independientes en la versión 1.16.4 y en versiones posteriores.

Tu clúster debe ser nativo de VPC. Si quieres obtener más información, consulta Cómo crear clústeres nativos de la VPC con direcciones IP de alias.

Tu clúster debe tener habilitado el balanceo de cargas HTTP. Los clústeres de GKE tienen habilitado el balanceo de cargas de HTTP de forma predeterminada. No debes inhabilitarlo.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project project-id
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
    gcloud config set compute/zone compute-zone
  • Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
    gcloud config set compute/region compute-region
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Usa NEG independientes

En las siguientes instrucciones, se muestra cómo usar los NEG independientes con un balanceador de cargas de HTTP externo en GKE.

Esto implica crear los siguientes objetos:

  • Un Deployment que crea y administra pods
  • Un Service que crea un NEG
  • Un balanceador de cargas creado con la API de Compute Engine. Esto difiere del uso de NEG con Ingress, en cuyo caso Ingress es el que crea y configura un balanceador de cargas. Con los NEG independientes, eres el responsable de asociar el NEG y el servicio de backend para conectar los pods al balanceador de cargas. El balanceador de cargas consta de varios componentes, que se muestran en el siguiente diagrama:

Los componentes de un balanceador de cargas son una regla de reenvío, un proxy HTTP de destino, un mapa de URL, una verificación de estado y un servicio de backend. Esto dirige el tráfico a un NEG que contiene direcciones IP del pod.

Crea un clúster nativo de la VPC

Para usar el balanceo de cargas nativo del contenedor, tienes que crear un clúster con las IP de alias habilitadas. Este clúster debe cumplir con las siguientes condiciones:

  • Debe ejecutar la versión 1.16.4 de Google Kubernetes Engine o una posterior.
  • Debe ser un clúster nativo de la VPC.
  • Debe tener habilitado el complemento de balanceo de cargas de HTTP. Los clústeres de GKE tienen habilitado el balanceo de cargas de HTTP de forma predeterminada. No debes inhabilitarlo.

Este comando crea un clúster, neg-demo-cluster, en la zona us-central1-a, con una subred aprovisionada de forma automática:

gcloud container clusters create neg-demo-cluster \
    --enable-ip-alias \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a

Crea un Deployment

Los manifiestos que se encuentran a continuación especifican un Deployment, neg-demo-app, que ejecuta tres instancias de un servidor HTTP con contenedores. El servidor HTTP responde a las solicitudes con el nombre de host del servidor de aplicaciones, el nombre del pod en el que se ejecuta el servidor.

Te recomendamos usar cargas de trabajo que usen los comentarios de preparación de pods, si están disponibles en la versión de GKE que usas. Consulta la sección sobre preparación de pods anterior a fin de obtener más información y la sección sobre requisitos a fin de conocer los requisitos de la versión de GKE para usar los comentarios de preparación de pods. Considera actualizar tu clúster para usar los comentarios de preparación de pods.

Usa comentarios de preparación de pods

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Usa un retraso codificado

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
      # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
      # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
      terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
  

Guarda este manifiesto como neg-demo-app.yaml y, luego, crea el Deployment mediante la ejecución del siguiente comando:

kubectl apply -f neg-demo-app.yaml

Crea un Service

El manifiesto que se muestra a continuación especifica un Service, neg-demo-svc.

  • Cualquier pod que tenga la etiqueta run: neg-demo-app es miembro de este Service.
  • El Service tiene un campo ServicePort con el puerto 80.
  • La anotación cloud.google.com/neg especifica que el puerto 80 se asociará con un NEG.
  • Cada pod miembro debe tener un contenedor que escuche en el puerto TCP 9376.
apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Guarda este manifiesto como neg-demo-svc.yaml y crea el Service mediante la ejecución del siguiente comando:

kubectl apply -f neg-demo-svc.yaml

Tipos de Service

Si bien en este ejemplo se usa un servicio ClusterIP, los cinco tipos de Service admiten NEG. Recomendamos el tipo predeterminado, ClusterIP, para la mayoría de los casos prácticos, ya que no expone el Service fuera del clúster, excepto a través del balanceador de cargas que creas a fin de apuntar al NEG.

Asigna puertos a varios NEG

Un Service puede escuchar en más de un puerto. Por definición, los NEG solo tienen una dirección IP y un puerto. Esto significa que si especificas un Service con varios puertos, se creará un NEG para cada puerto.

A continuación, se muestra el formato de la anotación cloud.google.com.neg:

cloud.google.com/neg: '{
   "exposed_ports":{
      "service-port-1":{},
      "service-port-2":{},
      "service-port-3":{},
      ...
   }'

En el ejemplo anterior, service-port-n son números de puerto distintos que hacen referencia a puertos de servicio existentes del Service. Para cada puerto de servicio enumerado, el controlador de NEG crea un NEG en cada zona que ocupa el clúster.

Recupera estados de NEG

Usa este comando para recuperar los estados de los objetos Service del clúster:

kubectl get service neg-demo-svc -o yaml

Este comando genera el estado de los NEG en el siguiente formato:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "service-port-1": "neg-name-1",
      "service-port-1": "neg-name-2",
      ...
   },
   "zones":["zone-1", "zone-2", ...]
}

En el ejemplo anterior, cada elemento de la asignación network-endpoint-groups es un puerto de servicio (service-port-1) y el nombre de los NEG administrados correspondientes (como neg-name-1). La lista zones contiene todas las zonas (como zone-1) que tienen un NEG.

El siguiente ejemplo es el resultado completo del comando:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["us-central1-a", "us-central1-b"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

En este ejemplo, la anotación muestra que el puerto de servicio 80 está expuesto a los NEG llamados k8s1-cca197ad-default-neg-demo-app-80-4db81e02 ubicados en las zonas us-central1-a y us-central1-b.

Valida la creación de NEG

Un NEG se crea en pocos minutos durante la creación del Service. Si hay pods que coinciden con la etiqueta que se especifica en el manifiesto de Service, el NEG contendrá las IP de los pods después de su creación.

Para verificar que el NEG exista debes enumerar los NEG en tu proyecto de Google Cloud y verificar si hay un NEG que coincida con el Service que creaste. El nombre del NEG tiene este formato: k8s1-cluster-uid-namespace-service-port-random-hash

Usa el siguiente comando para enumerar los NEG:

gcloud compute network-endpoint-groups list

El resultado se ve de la siguiente manera:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3

Este resultado muestra que el NEG tiene un SIZE de 3, lo que significa que tiene tres extremos que corresponden a los tres pods en el Deployment.

Identifica los extremos individuales con el siguiente comando:

gcloud compute network-endpoint-groups list-network-endpoints \
    k8s1-70aa83a6-default-my-service-80-c9710a6f

El resultado muestra tres extremos, cada extremo tiene una dirección IP y un puerto de pod:

INSTANCE                                           IP_ADDRESS  PORT
gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-standard-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Vincula un balanceador de cargas a los NEG independientes

Una vez que creaste tus NEG, puedes usarlos como backends para los siguientes tipos de balanceadores de cargas:

  • Un balanceador de cargas de HTTP(S) externo
  • Un balanceador de cargas de HTTP(S) interno
  • Un balanceador de cargas del proxy SSL
  • Un balanceador de cargas del proxy TCP

En los siguientes ejemplos, se muestra cómo hacerlo:

Vincula un balanceador de cargas de HTTP(S) externo a NEG independientes

En los siguientes pasos, se muestra cómo crear un balanceador de cargas de HTTP externo mediante la API de Compute Engine.

  1. Crea reglas de firewall en las que los balanceadores de cargas deban acceder a los extremos del clúster para realizar verificaciones de estado. Con el siguiente comando, se crean reglas de firewall que permiten ese acceso:

    gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
      --network=network-name \
      --action=allow \
      --direction=ingress \
      --target-tags=gke-node-network-tags \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --rules=tcp:9376

    En el ejemplo anterior, gke-node-network-tags son las etiquetas de red en los nodos de GKE, y network-name es la red en la que se ejecuta el clúster.

    Si no creaste etiquetas de red personalizadas para tus nodos, las generará GKE. Puedes buscar estas etiquetas generadas de forma automática si verificas los nodos con el siguiente comando:

    gcloud compute instances describe node-name
    
  2. Crea una dirección IP virtual global para el balanceador de cargas con el siguiente comando:

    gcloud compute addresses create hostname-server-vip \
      --ip-version=IPV4 \
      --global
  3. Crea una verificación de estado. El balanceador de cargas la usa para detectar los extremos individuales en funcionamiento dentro del NEG.

    gcloud compute health-checks create http http-basic-check \
      --use-serving-port
  4. Crea un servicio de backend que especifique que este es un balanceador de cargas de HTTP(S) externo global:

    gcloud compute backend-services create my-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
  5. Crea un mapa de URL y un proxy de destino para el balanceador de cargas. Este ejemplo es muy simple porque la app serve_hostname que se usa para esta guía tiene un solo extremo y no presenta URL.

    gcloud compute url-maps create web-map \
      --default-service my-bes
    gcloud compute target-http-proxies create http-lb-proxy \
      --url-map web-map
  6. Crea una regla de reenvío. Esto es lo que crea el balanceador de cargas.

    gcloud compute forwarding-rules create http-forwarding-rule \
      --address=hostname-server-vip \
      --global \
      --target-http-proxy=http-lb-proxy \
      --ports=80

    hostname-server-vip es la dirección IP que se usará para el balanceador de cargas. Puedes reservar una nueva dirección IP externa estática para este fin. También puedes omitir la opción --address y se asignará de forma automática una dirección IP efímera.

Punto de control

Estos son los recursos que creaste hasta el momento:

  • Una dirección IP virtual externa
  • Las reglas de reenvío
  • Las reglas de firewall
  • El proxy HTTP de destino
  • El mapa de URL y la verificación de estado de Compute Engine
  • El servicio de backend
  • La verificación de estado de Compute Engine

La relación entre estos recursos se muestra en el siguiente diagrama:

“”

Estos recursos juntos conforman un balanceador de cargas. En el siguiente paso, agregarás backends al balanceador de cargas. Uno de los beneficios de los NEG independientes que se demuestran aquí es que los ciclos de vida del balanceador de cargas y el backend pueden ser completamente independientes. El balanceador de cargas puede seguir en ejecución después de que se borra la aplicación, sus objetos Service o el clúster de GKE. Puedes agregar y quitar NEG nuevos o varios NEG del balanceador de cargas sin cambiar ninguno de los objetos del balanceador de cargas del principio.

Agrega backends al balanceador de cargas

Para usar gcloud compute backend-services add-backend a fin de conectar el NEG al balanceador de cargas, debes agregarlo como un backend del servicio de backend my-bes:

gcloud compute backend-services add-backend my-bes --global \
   --network-endpoint-group network-endpoint-group-name \
   --network-endpoint-group-zone network-endpoint-group-zone \
   --balancing-mode RATE --max-rate-per-endpoint 5

En el ejemplo anterior, se ilustra lo siguiente:

  • network-endpoint-group-name es el nombre del grupo de extremos de red. Consulta las instrucciones que se muestran a continuación para encontrar este valor.
  • network-endpoint-group-zone es la zona en la que se encuentra tu grupo de extremos de red. Consulta las instrucciones que se muestran a continuación para encontrar este valor.

Usa este comando para obtener el nombre y la ubicación del NEG:

gcloud compute network-endpoint-groups list

El resultado se ve de la siguiente manera:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3

En este resultado de ejemplo, el nombre del NEG es k8s1-70aa83a6-default-my-service-80-c9710a6f y está en la zona `us-central1-a.

Se pueden agregar varios NEG al mismo servicio de backend. Los servicios de backend globales, como my-bes, pueden tener backends de NEG en diferentes regiones, mientras que los servicios de backend regionales deben tener backends en una sola región.

Valida que el balanceador de cargas funcione

Hay dos formas de validar que el balanceador de cargas que configuraste funcione: puedes comprobar que la verificación de estado esté configurada de forma correcta y que informe un buen estado, y acceder a la aplicación y verificar su respuesta.

Comprueba las verificaciones de estado

Comprueba que el servicio de backend esté asociado con la verificación de estado y los grupos de extremos de red, y que los extremos individuales estén en buen estado.

Usa este comando para verificar que el servicio de backend esté asociado con tu verificación de estado y tu grupo de extremos de red:

gcloud compute backend-services describe my-bes --global

El resultado se ve de la siguiente manera:

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

Luego, verifica el estado de los extremos individuales:

gcloud compute backend-services get-health my-bes --global

La sección status: del resultado debería verse de la siguiente manera:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Accede a la aplicación

Accede a la aplicación a través de la dirección IP del balanceador de cargas para confirmar que todo funcione de forma correcta.

Primero, obtén la dirección IP virtual del balanceador de cargas:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

El resultado incluirá una dirección IP. Luego, envía una solicitud a esa dirección IP (34.98.102.37 en este ejemplo):

curl 34.98.102.37

La respuesta de la app serve_hostname debe ser neg-demo-app.

Vincula un balanceador de cargas de HTTP(S) interno a NEG independientes

En esta sección, se proporcionan instrucciones a fin de configurar el balanceo de cargas de HTTP(S) interno para los servicios que se ejecutan en pods de GKE independientes.

Configura la subred de solo proxy: id="proxy-only-subnet" }

La subred de solo proxy es para todos los balanceadores de cargas de HTTP(S) internos en la región del balanceador de cargas, en este ejemplo, us-west1.

console

Si usas GCP Console, puedes esperar y crear la subred de solo proxy más adelante en la IU del balanceo de cargas.

gcloud

Crea la subred de solo proxy con el comando gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

api

Crea la subred de solo proxy con el método subnetworks.insert y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Configura las reglas de firewall

En este ejemplo, se usan las siguientes reglas de firewall:

  • fw-allow-ssh: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar solo los rangos de IP del sistema desde el que inicias sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VM a las que se aplica la regla de firewall.

  • fw-allow-health-check: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP de los sistemas de verificación de estado de Google Cloud (en 130.211.0.0/2235.191.0.0/16). En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las instancias a las que debe aplicarse.

  • fw-allow-proxies: Es una regla de entrada, aplicable a las instancias con balanceo de cargas, que permite el tráfico de TCP en los puertos 804438000, y desde los proxies administrados del balanceador de cargas de HTTP(S) interno. En este ejemplo, se usa la etiqueta de destino load-balanced-backend para identificar las instancias a las que se debe aplicar.

Sin estas reglas de firewall, la regla predeterminada de denegación de entrada bloquea el tráfico entrante a las instancias de backend.

Console

  1. Ve a la página Reglas de Firewall en Google Cloud Console.
    Ir a la página Reglas de firewall
  2. Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes:
    • Nombre: fw-allow-ssh
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 0.0.0.0/0
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Marca tcp y escribe 22 para el número de puerto.
  3. Haz clic en Crear.
  4. Haz clic en Crear regla de firewall por segunda vez para crear la regla que permita las verificaciones de estado de Google Cloud:
    • Nombre: fw-allow-health-check
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados
      • Marca tcp e ingresa 80.
        Como práctica recomendada, limita esta regla solo a los protocolos y puertos que coincidan con los que usa tu verificación de estado. Si usas tcp:80 para el protocolo y el puerto, Google Cloud puede comunicarse con tus VM mediante HTTP en el puerto 80, pero no puede comunicarse con ellas mediante HTTPS en el puerto 443.
  5. Haz clic en Crear.
  6. Haz clic en Crear regla de firewall por tercera vez para crear la regla a fin de permitir que los servidores proxy del balanceador de cargas conecten los backends:
    • Nombre: fw-allow-proxies
    • Red: lb-network
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de fuente: IP ranges
    • Rangos de IP de origen: 10.129.0.0/23
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Marca tcp y escribe 80, 443, 8000 para los números de puerto.
  7. Haz clic en Crear.

gcloud

  1. Crea la regla de firewall fw-allow-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh. Cuando omites source-ranges, Google Cloud interpreta que la regla significa cualquier fuente.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Crea la regla fw-allow-health-check para permitir las verificaciones de estado de Google Cloud. En este ejemplo, se permite todo el tráfico de TCP de los sistemas de sondeo de la verificación de estado. Sin embargo, puedes configurar un conjunto más limitado de puertos para satisfacer tus necesidades.

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. Crea la regla fw-allow-proxies para permitir que los proxies del balanceador de cargas de HTTP(S) interno se conecten con los backends.

    gcloud compute firewall-rules create fw-allow-proxies \
      --network=lb-network \
      --action=allow \
      --direction=ingress \
      --source-ranges=10.129.0.0/23 \
      --target-tags=load-balanced-backend \
      --rules=tcp:80,tcp:443,tcp:8000
    

api

Crea la regla de firewall fw-allow-ssh mediante una solicitud POST al método firewalls.insert, y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Crea la regla de firewall fw-allow-health-check mediante una solicitud POST al método firewalls.insert, y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Crea la regla de firewall fw-allow-proxies para permitir el tráfico de TCP dentro de la subred de proxy con el método firewalls.insert, y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8000"
      ]
    }
  ],
  "direction": "INGRESS"
}

Configura el balanceador de cargas

Para la dirección IP de la regla de reenvío, usa una subred de backend. Si intentas usar la subred de solo proxy, la creación de la regla de reenvío fallará.

Console

Selecciona un tipo de balanceador de cargas

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. En Balanceo de cargas de HTTP(S), haz clic en Iniciar configuración.
  3. Selecciona Solo entre mis VM. Esta configuración indica que el balanceador de cargas es interno.
  4. Haz clic en Continuar.

Prepara el balanceador de cargas

  1. Para el Nombre del balanceador de cargas, ingresa l7-ilb-gke-map.
  2. En Región, selecciona us-west1.
  3. En Red, selecciona lb-network.
  4. Mantén la ventana abierta para continuar.

Reserva una subred de solo proxy

Para el balanceo de cargas de HTTP(S) interno, reserva una subred de proxy:

  1. Haz clic en Reservar una subred.
  2. En Nombre, ingresa proxy-only-subnet.
  3. En el Rango de direcciones IP, ingresa 10.129.0.0/23.
  4. Haz clic en Agregar.

Configura el servicio de backend

  1. Haz clic en Configuración de backend.
  2. En el menú Crear o seleccionar servicios de backend, selecciona Crear un servicio de backend.
  3. Establece el Nombre del servicio de backend como l7-ilb-gke-backend-service.
  4. En Tipo de backend, selecciona Grupos de extremos de red.
  5. En la tarjeta de Nuevo backend de la sección Backends, sigue estos pasos:
    1. Establece el Grupo de extremos de red en el NEG que creó GKE. Para obtener el nombre de NEG, consulta Valida la creación de NEG.
    2. Ingresa una tasa máxima de 5 RPS por extremo. Google Cloud excederá este máximo si es necesario.
    3. Haz clic en Listo.
  6. En la sección Verificación de estado, elige Crear una verificación de estado con los siguientes parámetros:
    1. Nombre: l7-ilb-gke-basic-check
    2. Protocolo: HTTP
    3. Especificación de puerto: Puerto de entrega
    4. Haz clic en Guardar y continuar.
  7. Haz clic en Crear.

Configura el mapa de URL

  1. Haz clic en Reglas de host y ruta. Asegúrate de que l7-ilb-gke-backend-service sea el único servicio de backend para cualquier host y ruta de acceso no coincidentes.

Configura el frontend

Para HTTP:

  1. Haz clic en Configuración de frontend.
  2. Haz clic en Agregar IP y puerto de frontend.
  3. Establece l7-ilb-gke-forwarding-rule como el Nombre.
  4. Establece el Protocolo en HTTP.
  5. Establece la Subred en backend-subnet.
  6. En IP interna, selecciona Reservar una dirección IP interna y estática.
  7. En el panel que aparece, proporciona los siguientes detalles:
    1. En el campo Nombre, ingresa l7-ilb-gke-ip.
    2. En la sección Dirección IP estática, selecciona Permitirme elegir.
    3. En la sección Dirección IP personalizada, ingresa 10.1.2.199.
    4. Haz clic en Reservar.
  8. Establece el Puerto en 80.
  9. Haz clic en Listo.

Para HTTPS:

Si usas HTTPS entre el cliente y el balanceador de cargas, necesitas uno o más recursos de certificado SSL para configurar el proxy. Consulta Certificados SSL para obtener información sobre cómo crear recursos de certificados SSL. Por el momento, los certificados administrados por Google no son compatibles con los balanceadores de cargas de HTTP(S) internos.

  1. Haz clic en Configuración de frontend.
  2. Haz clic en Agregar IP y puerto de frontend.
  3. En el campo Nombre, ingresa l7-ilb-gke-forwarding-rule.
  4. En el campo Protocolo, selecciona HTTPS (includes HTTP/2).
  5. Establece la Subred en backend-subnet.
  6. En IP interna, selecciona Reservar una dirección IP interna y estática.
  7. En el panel que aparece, proporciona los siguientes detalles:
    1. En el campo Nombre, ingresa l7-ilb-gke-ip.
    2. En la sección Dirección IP estática, selecciona Permitirme elegir.
    3. En la sección Dirección IP personalizada, ingresa 10.1.2.199.
    4. Haz clic en Reservar.
  8. Asegúrate de que el Puerto esté establecido en 443 para permitir el tráfico HTTPS.
  9. Haz clic en la lista desplegable Certificado.
    1. Si ya tienes un recurso de certificado SSL autoadministrado que deseas usar como certificado SSL principal, selecciónalo en el menú desplegable.
    2. De lo contrario, selecciona Crear un nuevo certificado.
      1. En Nombre, ingresa l7-ilb-cert.
      2. En los campos correspondientes, sube los archivos con formato PEM:
        • Certificado de clave pública
        • Cadena de certificado
        • Clave privada
      3. Haz clic en Crear.
  10. Para agregar otros recursos de certificado, además del recurso de certificado SSL principal, haz lo siguiente:
    1. Haz clic en Agregar certificado.
    2. Selecciona un certificado de la lista Certificados o haz clic en Crear un certificado nuevo y sigue las instrucciones anteriores.
  11. Haz clic en Listo.

Completa la configuración

  1. Haz clic en Crear.

gcloud

  1. Define la verificación de estado de HTTP mediante el comando gcloud compute health-checks create http.

    gcloud compute health-checks create http l7-ilb-gke-basic-check \
       --region=us-west1 \
       --use-serving-port
    
  2. Define el servicio de backend mediante el comando gcloud compute backend-services create.

    gcloud compute backend-services create l7-ilb-gke-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=l7-ilb-gke-basic-check \
      --health-checks-region=us-west1 \
      --region=us-west1
    
  3. Agrega backends de NEG al servicio de backend mediante el comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
       --network-endpoint-group=$DEPLOYMENT_NAME \
       --network-endpoint-group-zone=us-west1-b \
       --region=us-west1 \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=5
    
  4. Crea el mapa de URL mediante el comando gcloud compute url-maps create.

    gcloud compute url-maps create l7-ilb-gke-map \
      --default-service=l7-ilb-gke-backend-service \
      --region=us-west1
    
  5. Crea el proxy de destino.

    Para HTTP:

    Usa el comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create l7-ilb-gke-proxy \
      --url-map=l7-ilb-gke-map \
      --url-map-region=us-west1 \
      --region=us-west1
    

    Para HTTPS:

    Consulta Certificados SSL para obtener información sobre cómo crear recursos de certificados SSL. Por el momento, los certificados administrados por Google no son compatibles con los balanceadores de cargas de HTTP(S) internos.

    Asigna tus rutas de archivos a nombres de variables.

    export LB_CERT=path to PEM-formatted file
    
    export LB_PRIVATE_KEY=path to PEM-formatted file
    

    Crea un certificado SSL regional mediante el comando gcloud compute ssl-certificates create.

    gcloud compute ssl-certificates create

    gcloud compute ssl-certificates create l7-ilb-cert \
      --certificate=$LB_CERT \
      --private-key=$LB_PRIVATE_KEY \
      --region=us-west1
    

    Usa el certificado SSL regional para crear un proxy de destino mediante el comando gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create l7-ilb-gke-proxy \
      --url-map=l7-ilb-gke-map \
      --region=us-west1 \
      --ssl-certificates=l7-ilb-cert
    
  6. Crea la regla de reenvío.

    Para redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que esta es la subred de VM, no la subred de proxy.

    Para HTTP:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=10.1.2.199 \
      --ports=80 \
      --region=us-west1 \
      --target-http-proxy=l7-ilb-gke-proxy \
      --target-http-proxy-region=us-west1
    

    Para HTTPS:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=lb-network \
      --subnet=backend-subnet \
      --address=10.1.2.199 \
      --ports=443 \
      --region=us-west1 \
      --target-https-proxy=l7-ilb-gke-proxy \
      --target-https-proxy-region=us-west1
    

api

Para crear la verificación de estado, realiza una solicitud POST al método regionHealthChecks.insert y reemplaza project-id por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

Crea el servicio de backend regional mediante una solicitud POST al método regionBackendServices.insert, y reemplaza project-id por el ID del proyecto y neg-name por el nombre del NEG que creaste.

POST https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-b/networkEndpointGroups/neg-name",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/project-id/regions/us-west1/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Para crear el mapa de URL, realiza una solicitud POST al método regionUrlMaps.insert y reemplaza project-id por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/project-id/regions/us-west1/backendServices/l7-ilb-gke-backend-service"
}

Para crear el proxy HTTP de destino, realiza una solicitud POST al método regionTargetHttpProxies.insert y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/project-id/global/urlMaps/l7-ilb-gke-map",
  "region": "us-west1"
}

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert y reemplaza project-id por el ID del proyecto.

POST https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/project-id/regions/us-west1/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/project-id/regions/us-west1/subnetworks/backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Realiza pruebas

Crea una instancia de VM en la zona para probar la conectividad

gcloud compute instances create l7-ilb-client-us-west1-b \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=us-west1-b \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Accede a la instancia de cliente para verificar que los servicios HTTP(S) en los backends sean accesibles mediante la dirección IP de la regla de reenvío del balanceador de cargas de HTTP(S) interno y que las cargas del tráfico se balanceen en los extremos del NEG.

Conéctate mediante SSH a cada instancia de cliente.

gcloud compute ssh l7-ilb-client-us-west1-b \
    --zone=us-west1-b

Verifica que la IP entregue su nombre de host.

curl 10.1.2.199

Para la prueba de HTTPS, reemplaza curl por lo siguiente:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

La marca -k hace que curl omita la validación del certificado.

Ejecuta 100 solicitudes y confirma que sus cargas estén balanceadas.

Para HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Para HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Implementa servicios heterogéneos (VM y contenedores)

Los balanceadores de cargas pueden ser frontends para una combinación de cargas de trabajo de Kubernetes y cargas de trabajo que no son de Kubernetes. Esto podría ser parte de una migración de VM a contenedores o una arquitectura permanente que se beneficia de un balanceador de cargas compartido. Esto se puede lograr mediante la creación de balanceadores de cargas que se dirigen a diferentes tipos de backends, incluidos los NEG independientes.

VM y contenedores en el mismo servicio de backend

En este ejemplo, se muestra cómo crear un NEG que apunte a una VM existente que ejecuta una carga de trabajo, y cómo agregar este NEG como otro backend de un backendService existente. De esta manera, un solo balanceador de cargas balancea entre las VM y los contenedores de GKE.

En este ejemplo, se amplía el ejemplo anterior que usa un balanceador de cargas de HTTP externo.

Debido a que todos los extremos se agrupan por el mismo backendService, los extremos del contenedor y la VM se consideran el mismo servicio. Esto significa que la coincidencia del host y la ruta tratará todos los backends de manera idéntica según las reglas del mapa de URL.

Un diagrama que muestra la arquitectura que se describió antes. El balanceador de cargas creado con anterioridad apunta a dos NEG, el NEG para contenedores que se creó antes y un NEG nuevo que contiene una dirección IP de VM.

Cuando usas un NEG como backend para un servicio de backend, todos los demás backends en ese servicio también deben ser NEG. No puedes usar grupos de instancias y NEG como backends en el mismo servicio de backend. Además, los contenedores y las VM no pueden existir como extremos dentro del mismo NEG, por lo que siempre deben configurarse con NEG distintos.

  1. Implementa una VM en Compute Engine con el siguiente comando:

    gcloud compute instances create vm1 --zone zone --network=network \
     --subnet=subnet --image-project=cos-cloud \
     --image-family=cos-stable --tags=vm-neg-tag
  2. Implementa una aplicación en la VM:

    gcloud compute ssh vm1 --zone=${ZONE} --command="docker run -d --rm --network=host \
     k8s.gcr.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"

    Con este comando, se implementa en la VM la misma aplicación de ejemplo que se usó en el ejemplo anterior. Para simplificar, la aplicación se ejecuta como un contenedor de Docker, pero esto no es esencial. El comando iptables es necesario para permitir el acceso de firewall al contenedor en ejecución.

  3. Valida que la aplicación entregue en el puerto 9376 y que informe que se ejecuta en vm1:

    gcloud compute ssh vm1 --zone=zone --command="curl -s localhost:9376"

    El servidor debe responder con: vm1

  4. Crea un NEG para usar con el extremo de VM. Los contenedores y las VM pueden ser extremos de NEG, pero un solo NEG no puede tener extremos de contenedor y VM.

    gcloud compute network-endpoint-groups create vm-neg \
    --subnet=subnet --zone=zone
  5. Vincula el extremo de VM al NEG:

    gcloud compute network-endpoint-groups update vm-neg --zone=zone \
     --add-endpoint="instance=vm1,ip=vm-primary-ip,port=9376"
  6. Confirma que el NEG tenga el extremo de VM:

    gcloud compute network-endpoint-groups list-network-endpoints vm-neg --zone zone
  7. Vincula el NEG al servicio de backend mediante el mismo comando que usaste para agregar un backend de contenedor:

    gcloud compute backend-services add-backend my-bes --global \
     --network-endpoint-group vm-neg \
     --network-endpoint-group-zone zone \
     --balancing-mode RATE --max-rate-per-endpoint 10
  8. Abre el firewall para permitir la verificación de estado de la VM:

    gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
    --network=network \
    --action=allow \
    --direction=ingress \
    --target-tags=vm-neg-tag \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:9376
    
  9. Valida que el balanceador de cargas reenvíe tráfico al backend de vm1 nuevo y al backend del contenedor existente mediante el envío de tráfico de prueba:

    for i in `seq 1 100`; do curl ${VIP};echo; done

    Deberías ver las respuestas de los extremos del contenedor (neg-demo-app) y de la VM (vm1).

VM y contenedores para diferentes servicios de backend

En este ejemplo, se muestra cómo crear un NEG que apunta a una VM existente que ejecuta una carga de trabajo y cómo agregar este NEG como el backend de un backendService nuevo. Esto es útil para el caso en el que los contenedores y las VM son servicios diferentes, pero necesitan compartir el mismo balanceador de cargas L7, como si los servicios compartieran la misma dirección IP o nombre de dominio.

En este ejemplo, se amplía el ejemplo anterior que tiene un backend de VM en el mismo servicio de backend que el backend del contenedor. En este ejemplo, se vuelve a usar esa VM.

Debido a que los extremos del contenedor y la VM se agrupan en backendServices separados, se consideran servicios diferentes. Esto significa que el mapa de URL coincidirá con los backends y el tráfico directo a la VM o al contenedor según el nombre de host.

En el siguiente diagrama, se muestra cómo una sola dirección IP virtual corresponde a dos nombres de host, que, a su vez, corresponden a un servicio de backend basado en contenedores y a un servicio de backend basado en VM.

En el siguiente diagrama, se muestra la arquitectura que se describió antes:

La arquitectura tiene dos NEG, uno para el servicio implementado con contenedores y otro para el servicio implementado con VM. Hay un objeto de servicio de backend para cada NEG. El objeto del mapa de URL dirige el tráfico al servicio de backend correcto según la URL solicitada.

  1. Crea un servicio de backend nuevo para la VM:

    gcloud compute backend-services create my-vm-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
  2. Vincula el NEG de la VM, vm-neg, al servicio de backend:

    gcloud compute backend-services add-backend my-vm-bes --global \
     --network-endpoint-group vm-neg \
     --network-endpoint-group-zone zone \
     --balancing-mode RATE --max-rate-per-endpoint 10
  3. Agrega una regla de host al mapa de URL para dirigir las solicitudes del host container.example.com al servicio de backend del contenedor:

    gcloud compute url-maps add-path-matcher web-map \
      --path-matcher-name=container-path --default-service=my-bes \
      --new-hosts=container.example.com --global
    
  4. Agrega otra regla de host al mapa de URL para dirigir las solicitudes del host vm.example.com al servicio de backend de la VM:

    gcloud compute url-maps add-path-matcher web-map \
      --path-matcher-name=vm-path --default-service=my-vm-bes \
      --new-hosts=vm.example.com --global
    
  5. Valida que el balanceador de cargas envíe tráfico al backend de la VM según la ruta solicitada:

    curl -H "vm.example.com" virtual-ip

Limitaciones de los NEG independientes

  • Los errores de validación de anotaciones se exponen al usuario a través de eventos de Kubernetes.
  • El controlador del NEG genera los nombres del NEG. No puedes proporcionar nombres personalizados para los NEG.
  • Las limitaciones de los NEG también se aplican a los NEG independientes.
  • Los NEG independientes no funcionan con redes heredadas.
  • Los NEG independientes solo se pueden usar con servicios de red compatibles, incluidos Traffic Director y los tipos de balanceadores de cargas compatibles.

Precios

Consulta la sección de balanceo de cargas de la página de precios para obtener detalles sobre los precios del balanceador de cargas. No se aplican cargos adicionales por los NEG.

Soluciona problemas

No se configuró un NEG independiente

Síntoma: Un NEG no se crea.

Resolución posible:

  • Verifica los eventos asociados con el Service y busca mensajes de error.
  • Verifica que la anotación del NEG independiente sea un JSON con el formato correcto y que los puertos expuestos coincidan con los puertos existentes en la especificación del servicio.
  • Verifica la anotación del estado del NEG y si los puertos de servicio esperados tienen los NEG correspondientes.
  • Verifica que los NEG se creen en las zonas esperadas con el comando gcloud compute network-endpoint-groups list.

El tráfico no llega a los extremos

Síntoma: Errores 502 o conexiones rechazadas.

Resolución posible:

  • Después de configurar el servicio, por lo general, se puede acceder a los extremos nuevos después de vincularlos al NEG, siempre que respondan a las verificaciones de estado.
  • Si después de este tiempo el tráfico aún no llega a los extremos, y esto genera un código de error 502 de HTTP(S) o conexiones rechazadas para balanceadores de cargas TCP/SSL, verifica lo siguiente:
    • Verifica que las reglas de firewall permitan el tráfico de TCP entrante a los extremos de los siguientes rangos: 130.211.0.0/2235.191.0.0/16.
    • Verifica que los extremos estén en buen estado mediante gcloud o una llamada a la API de getHealth en BackendService o a la API de listEndpoints en el NEG con el parámetro showHealth establecido en SHOW.

Lanzamiento suspendido

Síntoma: El lanzamiento de un Deployment actualizado se suspende, y la cantidad de réplicas actualizadas no coincide con la cantidad deseada de réplicas.

Resolución posible:

Las verificaciones de estado de la implementación están fallando. La imagen del contenedor puede ser mala o la verificación de estado puede estar mal configurada. El reemplazo continuo de pods espera hasta que el pod recién iniciado pase su puerta de preparación de pod. Esto solo ocurre si el pod responde a las verificaciones de estado del balanceador de cargas. Si el pod no responde o la verificación de estado está mal configurada, no se pueden cumplir las condiciones de la puerta de preparación y el lanzamiento no puede continuar.

  • Si usas kubectl 1.13 o una versión posterior, puedes verificar el estado de las puertas de preparación de un pod con el siguiente comando:

    kubectl get my-Pod -o wide

    Consulta la columna READINESS GATES.

    Esta columna no existe en kubectl 1.12 ni en versiones anteriores. Un pod que está marcado en estado READY puede tener una puerta de preparación con errores. Para verificar esto, usa el siguiente comando:

    kubectl get my-pod -o yaml

    Las puertas de preparación y sus estados se enumeran en la salida.

  • Verifica que la imagen del contenedor en la especificación de tu pod de Deployment funcione de forma correcta y pueda responder a las verificaciones de estado.

  • Comprueba que las verificaciones de estado estén configuradas de forma correcta.

Próximos pasos