Balanceo de cargas en paquetes con Seesaw

Version 1.11 

• Versión más reciente
• Versión 1.16
• Versiones anteriores (no admitidas)

Clústeres de Anthos alojados en VMware (GKE On-Prem) puede ejecutarse en uno de tres modos de balanceo de cargas: integrado, manual o en paquetes. En este documento, se muestra cómo configurar clústeres de Anthos alojados en VMware para ejecutar el balanceador de cargas de Seesaw en modo en paquetes.

Las instrucciones que aparecen aquí están completas. Para obtener una introducción más corta al uso del balanceador de cargas de Seesaw, consulta Balanceador de cargas de Seesaw (guía de inicio rápido).

En el modo de balanceo de cargas en paquetes, clústeres de Anthos alojados en VMware proporciona y administra el balanceador de cargas. No es necesario que obtengas una licencia para un balanceador de cargas, y la configuración que debes realizar es mínima.

En este documento, se muestra cómo configurar el balanceador de cargas de Seesaw para un clúster de administrador y un clúster de usuario asociado. Puedes ejecutar el balanceador de cargas de Seesaw en una sola VM o en el modo de alta disponibilidad (HA), que usa dos VM. En el modo de HA, el balanceador de cargas de Seesaw usa el Protocolo de redundancia de router virtual (VRRP). Las dos VM se llaman instancia principal y copia de seguridad. Cada VM de Seesaw recibe un identificador de router virtual (VRID) que elijas.

Ejemplo de una configuración de Seesaw

Este es un ejemplo de una configuración para clústeres que ejecutan el balanceador de cargas de Seesaw en modo de alta disponibilidad:

Configuración del balanceador de cargas de Seesaw en modo de alta disponibilidad (haz clic para ampliar)

En el diagrama anterior, se muestran dos VM de Seesaw, cada una para el clúster de administrador y el clúster de usuario. En este ejemplo, el clúster de administrador y el clúster de usuario están en dos VLAN independientes, y cada clúster se encuentra en una subred independiente:

Clúster	Subred
Clúster de administrador	172.16.20.0/24
Clúster de usuario	172.16.40.0/24

admin-cluster.yaml

En el siguiente ejemplo de un archivo de configuración del clúster de administrador, se muestra la configuración que aparece en el diagrama anterior:

• Es la dirección IP de la instancia principal del par de VM de Seesaw que dan servicio al clúster de administrador.

• VIP designadas para el servidor de API de Kubernetes y los complementos del clúster de administrador.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/admin-seesaw-ipblock.yaml"
    masterIP: 172.16.20.57
  ...

  vips:
    controlPlaneVIP: "172.16.20.70"
    addonsVIP: "172.16.20.71"

admin-cluster-ipblock.yaml

En el siguiente ejemplo de un archivo de bloque IP, se muestra la designación de las direcciones IP para los nodos en el clúster de administrador. Esto también incluye la dirección del nodo del plano de control del clúster de usuario y una dirección IP que se usará durante la actualización del clúster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.20.1"
  ips:
  - ip: 172.16.20.50
    hostname: admin-vm-1
  - ip: 172.16.20.51
    hostname: admin-vm-2
  - ip: 172.16.20.52
    hostname: admin-vm-3
  - ip: 172.16.20.53
    hostname: admin-vm-4
  - ip: 172.16.20.54
    hostname: admin-vm-5

admin-seesaw-ipblock.yaml

En el siguiente ejemplo de otro archivo de bloque de IP, se especifican dos direcciones IP para las VM de Seesaw que dan servicio al clúster de administrador. Ten en cuenta que este es un archivo de bloque de IP independiente para las VM del balanceador de cargas, no para los nodos del clúster.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.60"
      hostname: "admin-seesaw-vm-1"
    - ip: "172.16.20.61"
      hostname: "admin-seesaw-vm-2"

user-cluster.yaml

En el siguiente ejemplo de un archivo de configuración de clúster de usuario, se muestra la configuración de lo siguiente:

• Es la dirección IP de la instancia principal del par de VM de Seesaw que dan servicio al clúster de usuario.

• VIP designadas para el servidor de API de Kubernetes y el servicio de entrada en el clúster de usuario. La VIP del servidor de la API de Kubernetes se encuentra en la subred del clúster de administrador porque el plano de control de un clúster de usuario se ejecuta en un nodo del clúster de administrador.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/user-seesaw-ipblock.yaml"
    masterIP: 172.16.40.31
  ...

  vips:
    controlPlaneVIP: "172.16.20.72"
    ingressVIP: "172.16.40.100"

user-cluster-ipblock.yaml

En el siguiente ejemplo de un archivo de bloque IP, se muestra la designación de las direcciones IP para los nodos en el clúster de usuario. Esto incluye una dirección IP para usar durante la actualización del clúster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.21
    hostname: user-vm-1
  - ip: 172.16.40.22
    hostname: user-vm-2
  - ip: 172.16.40.23
    hostname: user-vm-3
  - ip: 172.16.40.24
    hostname: user-vm-4
  - ip: 172.16.40.25
    hostname: user-vm-5

user-seesaw-ipblock.yaml

En el siguiente ejemplo de otro archivo de bloque de IP, se especifican dos direcciones IP para las VM de Seesaw que dan servicio al clúster de usuario.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.29"
      hostname: "user-seesaw-vm-1"
    - ip: "172.16.40.30"
      hostname: "user-seesaw-vm-2"

Grupos de puertos

En la siguiente tabla, se describe la configuración de las interfaces de red para cada una de las VM de Seesaw y sus grupos de puertos conectados, como se muestra en el diagrama anterior.

VM de Seesaw	Interfaz de red	Configuración de interfaz de red	Grupo de puertos conectados
Master	network-interface-1	VIP	load-balancer
	network-interface-2	Dirección IP tomada del archivo de bloque de IP para las VM de Seesaw	cluster-node
Copia de seguridad	network-interface-1	Sin configuración	load-balancer
	network-interface-2	Dirección IP tomada del archivo de bloque de IP para las VM de Seesaw	cluster-node

Los nodos del clúster también se conectan al grupo de puertos cluster-node.

Como se muestra en la tabla anterior, cada una de las VM de Seesaw para los clústeres de administrador y de usuario tiene dos interfaces de red. Para cada VM de Seesaw, las dos interfaces de red están conectadas a dos grupos de puertos diferentes:

• grupo de puertos load-balancer

• grupo de puertos cluster-node

Los dos grupos de puertos para un clúster están en la misma VLAN para ese clúster.

Configura el balanceador de cargas de Seesaw

Versiones recomendadas

En el diagrama anterior, se muestra la configuración de red recomendada para el balanceo de cargas de Seesaw. Cuando planifiques tu propia configuración, te recomendamos que uses vSphere 6.7 o una versión posterior y Virtual Distributed Switch (VDS) 6.6 o una versión posterior para el modo de balanceo de cargas en paquetes.

Si lo prefieres, puedes usar versiones anteriores, pero la instalación será menos segura. En las secciones restantes de este tema, se proporcionan más detalles sobre las ventajas de seguridad del uso de vSphere 6.7+ y VDS 6.6+.

Planifica las VLAN

En el modo de balanceo de cargas en paquetes, te recomendamos que tengas los clústeres en distintas VLAN.

Si el clúster de administrador está en su propia VLAN, el tráfico del plano de control es independiente del tráfico del plano de datos. Esta separación protege los planos de control del clúster de administrador y de usuario de los errores de configuración involuntarios. Estos errores pueden generar, por ejemplo, problemas como una tormenta de transmisión debido a bucles de capa 2 en la misma VLAN o a una dirección IP en conflicto que elimina la separación deseada entre el plano de datos y el plano de control.

Aprovisiona recursos de VM

Para las VM que ejecutan el balanceador de cargas de Seesaw, aprovisiona la CPU y los recursos de memoria de acuerdo con el tráfico de red que esperas encontrar.

El balanceador de cargas de Seesaw no consume mucha memoria y se puede ejecutar en VM con 1 GB de memoria. Sin embargo, el requisito de CPU aumenta a medida que aumenta la frecuencia de paquetes de red.

En la siguiente tabla, se muestran los lineamientos de almacenamiento, CPU y memoria para el aprovisionamiento de las VM de Seesaw. Debido a que la tasa de paquetes no es una medida típica del rendimiento de red, en la tabla también se muestran los lineamientos para la cantidad máxima de conexiones de red activas. En los lineamientos, también se supone un entorno en el que las VM tienen un vínculo de 10 Gbps, y que las CPU se ejecutan con una capacidad inferior al 70%.

Cuando el balanceador de cargas de Seesaw se ejecuta en modo de alta disponibilidad, usa un par (instancia principal, copia de seguridad), por lo que todo el tráfico fluye a través de una sola VM. Como los casos de uso reales varían, estas pautas deben modificarse en función del tráfico real. Supervisa las métricas de CPU y frecuencia de paquetes para determinar los cambios necesarios.

Si necesitas cambiar la CPU y la memoria de las VM de Seesaw, consulta Actualiza un balanceador de cargas. Ten en cuenta que puedes mantener la misma versión del balanceador de cargas y cambiar la cantidad de CPU y la asignación de memoria.

En el caso de los clústeres de administrador pequeños, recomendamos 2 CPU y, en el caso de los clústeres de administrador grandes, recomendamos 4 CPU.

Almacenamiento	CPU	Memoria	Tasa de paquetes (pps)	Cantidad máxima de conexiones activas
20 GB	1 (no producción)	1 GB	250k	100
20 GB	2	3 GB	450k	300
20 GB	4	3 GB	850k	6,000
20 GB	6	3 GB	1,000k	10,000

Reserva las direcciones IP y VIP

VIP

Sin importar el modo de balanceo de cargas que elijas, debes reservar varias direcciones IP virtuales (VIP) que quieras usar para el balanceo de cargas. Estas VIP permiten que los clientes externos accedan a los servidores de la API de Kubernetes, los servicios de entrada y los servicios de complementos.

También piensa en cuántos Services de tipo LoadBalancer pueden estar activos en tu clúster de usuario en un momento determinado y reserva suficientes VIP para estos Services. A medida que crees Services de tipo LoadBalancer más adelante, los clústeres de Anthos alojados en VMware configuran las VIP de Service en el balanceador de cargas de forma automática.

Direcciones IP de nodos

En el modo de balanceo de cargas en paquetes, puedes especificar direcciones IP estáticas para los nodos del clúster, o estos pueden obtener sus direcciones IP de un servidor de DHCP.

Si deseas que los nodos del clúster tengan direcciones IP estáticas, reserva suficientes direcciones para los nodos del clúster de administrador y los nodos de todos los clústeres de usuario que quieras crear. También reserva una dirección IP adicional para que cada clúster use durante la actualización del clúster. Para obtener más información sobre cuántas direcciones IP de nodos se deben configurar, consulta Crea un clúster de administrador.

Direcciones IP para las VM de Seesaw

A continuación, en cada clúster, administrador y usuario, reserva direcciones IP para las VM que ejecutarán los balanceadores de cargas de Seesaw. La cantidad de direcciones que debes reservar dependerá de si deseas crear balanceadores de cargas de Seesaw con o sin HA.

Direcciones IP principales

Además de las direcciones IP para las VM de Seesaw, también debes reservar una sola dirección IP principal en el par de VM de Seesaw para cada clúster.

Configuración sin alta disponibilidad

Si tu configuración no tiene alta disponibilidad, haz lo siguiente:

• Para el clúster de administrador, reserva una dirección IP destinada a una VM de Seesaw y una dirección IP de la instancia principal para el balanceador de cargas de Seesaw. Ambas direcciones deben estar en la misma VLAN que los nodos del clúster de administrador.

• En el clúster de usuario, reserva una dirección IP para una VM de Seesaw y una dirección IP de instancia principal para el balanceador de cargas de Seesaw. Ambas direcciones deben estar en la misma VLAN que los nodos del clúster de usuario.

Planifica los grupos de puertos

En el diagrama anterior, se describen los dos grupos de puertos usados en una configuración de alta disponibilidad y cómo se conectan a las interfaces de red en las VM de Seesaw. En el caso de una VM individual de Seesaw, decide si deseas que las dos interfaces de red estén conectadas al mismo grupo de puertos de vSphere o a grupos de puertos diferentes. Si no habilitas el aprendizaje de MAC, puedes tener un grupo de puertos. Si los grupos de puertos son diferentes, deben estar en la misma VLAN.

Crea archivos de bloque de IP

Por cada clúster, administrador y usuario, especifica las direcciones que elegiste para las VM de Seesaw en un archivo de bloque de IP. Si deseas usar direcciones IP estáticas para los nodos del clúster, debes crear un archivo de bloque de IP independiente destinado a estas direcciones.

Completa los archivos de configuración

Prepara un archivo de configuración para tu clúster de administrador y otro archivo de configuración para el clúster de usuario.

En tu archivo de configuración de un clúster determinado, configura loadBalancer.kind como "Seesaw".

En loadBalancer, completa la sección seesaw:

loadBalancer:
  kind: Seesaw
  seesaw:

Si deseas obtener información para completar la sección seesaw de un archivo de configuración del clúster, consulta loadbalancer.seesaw (clúster de administrador) o loadbalancer.seesaw (clúster de usuario)

En el archivo de configuración del clúster de administrador, designa lo siguiente:

• Es la VIP para el servidor de la API de Kubernetes del clúster de administrador
• VIP para los complementos del clúster de administrador
• Dirección IP principal del par de VM de Seesaw que dan servicio al clúster de administrador.

Estas VIP deben estar en la subred del clúster de administrador.

En el archivo de configuración del clúster de usuario, designa lo siguiente:

• VIP para el servidor de la API de Kubernetes del clúster de usuario (debe estar en la subred del clúster de administrador)
• VIP de entrada en el clúster de usuario
• Dirección IP principal del par de VM de Seesaw que dan servicio al clúster de usuario.

Las últimas dos direcciones de la lista anterior deben estar en la subred del clúster de usuario.

Habilita el aprendizaje de MAC o el modo promiscuo (solo con alta disponibilidad)

Si configuras un balanceador de cargas de Seesaw sin alta disponibilidad, puedes omitir esta sección.

Si configuraste loadBalancer.seesaw.disableVRRPMAC como verdadero, puedes omitir esta sección.

Si configuras un balanceador de cargas de Seesaw con alta disponibilidad y configuraste loadBalancer.seesaw.disableVRRPMAC como false, debes habilitar alguna combinación de aprendizaje de MAC, transmisiones falsificadas y el modo promiscuo en el grupo de puertos del balanceador de cargas.

La forma de habilitar estas funciones varía según el tipo de interruptor que tengas:

Tipo de interruptor	Habilitación de las funciones	Impacto en la seguridad
vSphere 7.0 VDS	Para vSphere 7.0 con HA, debes establecer loadBalancer.seesaw.disableVRRPMAC como true. El aprendizaje de MAC no es compatible.
vSphere 6.7 con VDS 6.6	Habilita el aprendizaje de MAC y las transmisiones falsificadas para tu balanceador de cargas mediante la ejecución de este comando: gkectl prepare network --config [CONFIG_FILE], en el que [CONFIG_FILE] es la ruta del archivo de configuración del clúster. Necesitas el permiso dvPort group.Modify para hacer esto.	Es mínimo. Si el grupo de puertos del balanceador de cargas solo está conectado a las VM de Seesaw, puedes limitar el aprendizaje de MAC a las VM de Seesaw de confianza.
vSphere 6.5 o vSphere 6.7 con una versión de VDS anterior a la 6.6	Habilita el modo promiscuo y las transmisiones falsificadas en el grupo de puertos del balanceador de cargas. Usa la interfaz de usuario de vSphere en la página del grupo de puertos en la pestaña Networking: Edit Settings -> Security.	Todas las VM del grupo de puertos del balanceador de cargas están en modo promiscuo. Por lo tanto, todas pueden ver todo el tráfico. Si el grupo de puertos del balanceador de cargas solo está conectado a las VM de Seesaw, solo estas pueden ver todo el tráfico.
Interruptor lógico de NSX-T	Habilita el aprendizaje de MAC en el interruptor lógico.	vSphere no admite la creación de dos interruptores lógicos en el mismo dominio de capa 2. Por lo tanto, las VM de Seesaw y los nodos del clúster deben estar en el mismo interruptor lógico. Esto significa que el aprendizaje de MAC está habilitado para todos los nodos del clúster. Puede que un atacante logre falsificar la identidad de una MAC mediante la ejecución de Pods privilegiados en el clúster.
Interruptor estándar de vSphere	Habilita el modo promiscuo y las transmisiones falsificadas en el grupo de puertos del balanceador de cargas. Usa la interfaz de usuario de vSphere en cada host de ESXI: Configure -> Virtual switches -> Standard Switch -> Edit Setting on the port group -> Security.	Todas las VM del grupo de puertos del balanceador de cargas están en modo promiscuo. Por lo tanto, todas pueden ver todo el tráfico. Si el grupo de puertos del balanceador de cargas solo está conectado a las VM de Seesaw, solo estas pueden ver todo el tráfico.

Completa el archivo de configuración del clúster de administrador

Sigue las instrucciones en Crea un clúster de administrador para terminar de completar el archivo de configuración del clúster de administrador.

Ejecutar comprobaciones previas

Ejecuta comprobaciones previas en el archivo de configuración del clúster de administrador:

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador.

Sube imágenes de SO

Sube imágenes de SO al entorno de vSphere:

gkectl prepare --config ADMIN_CLUSTER_CONFIG

Crea un balanceador de cargas para tu clúster de administrador

gkectl create loadbalancer --config [ADMIN_CLUSTER_CONFIG]

Crea el clúster de administrador

Sigue las instrucciones en Crea un clúster de administrador a fin dde crear tu clúster de administrador.

Completa los archivos de configuración del clúster de usuario

Sigue las instrucciones en Crea un clúster de usuario para terminar de completar el archivo de configuración del clúster de usuario.

Ejecutar comprobaciones previas

Ejecuta comprobaciones previas en el archivo de configuración del clúster de usuario:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

• ADMIN_CLUSTERE_KUBECONFIG: la ruta de acceso al archivo kubeconfig del clúster de administrador

• USER_CLUSTER_CONFIG es la ruta de acceso del archivo de configuración del clúster de usuario.

Sube imágenes de SO

Sube imágenes de SO al entorno de vSphere:

gkectl prepare --config USER_CLUSTER_CONFIG

Cree un balanceador de cargas para tu clúster de usuario

Crea un balanceador de cargas para tu clúster de usuario

gkectl create loadbalancer --config USER_CLUSTER_CONFIG

Crea tu clúster de usuario

Sigue las instrucciones en Crea un clúster de usuario a fin de crearlo.

Prueba de rendimiento y carga

La capacidad de procesamiento de descarga de la aplicación se escala de forma lineal con la cantidad de backends. Esto se debe a que los backends envían respuestas directamente a los clientes mediante el retorno directo del servidor y omiten el balanceador de cargas.

En cambio, la capacidad de procesamiento de carga de la aplicación está limitada por la capacidad de la VM de Seesaw que realiza el balanceo de cargas.

La cantidad de CPU y memoria que necesitan las aplicaciones varía, por lo que es fundamental realizar una prueba de carga antes de comenzar a entregar a una gran cantidad de clientes.

Las pruebas indican que una sola VM de Seesaw con 6 CPU y 3 GB de memoria puede manejar 10 GB/s (velocidad de línea) de tráfico de carga con 10,000 conexiones de TCP simultáneas. Sin embargo, es importante que ejecutes tu propia prueba de carga si planeas admitir una gran cantidad de conexiones de TCP simultáneas.

Límites de escalamiento

En el balanceo de cargas en paquetes, existen límites para el escalamiento del clúster. Existe un límite en la cantidad de nodos del clúster y en la cantidad de objetos Service que se pueden configurar en el balanceador de cargas. También existe un límite para las verificaciones de estado. La cantidad de verificaciones de estado depende de la cantidad de nodos y de objetos Service.

A partir de la versión 1.3.1, la cantidad de verificaciones de estado depende de la cantidad de nodos y de objetos Service locales de tráfico. Un Service local de tráfico es un objeto Service en el que externalTrafficPolicy está configurada como "Local".

	Versión 1.3.0	Versión 1.3.1 y posteriores
Cantidad máxima de objetos Service (S)	100	500
Cantidad máxima de nodos (N)	100	100
Cantidad máxima de verificaciones de estado	S x N <= 10,000	N + L x N <= 10,000 (L es la cantidad de objetos Service locales de tráfico)

Ejemplo: Supongamos que tienes 100 nodos y 99 objetos Service locales de tráfico en la versión 1.3.1. Por lo tanto, la cantidad de verificaciones de estado será de 100 + 99 x 100 = 10,000, que se encuentra dentro del límite de 10,000.

Actualiza el balanceador de cargas de un clúster

Cuando actualizas un clúster, el balanceador de cargas se actualiza de forma automática. No es necesario ejecutar un comando separado para actualizar el balanceador de cargas.

Si lo deseas, puedes actualizar las CPU o la memoria de las VM de Seesaw sin realizar una actualización completa. Primero, edita los valores cpus y memoryMB en el archivo de configuración del clúster. Por ejemplo:

apiVersion: v1
bundlePath:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 3
    memoryMB: 3072

Luego, para actualizar el balanceador de cargas de un clúster de administrador, haz lo siguiente:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster

Para actualizar el balanceador de cargas de un clúster de usuario, haz lo siguiente:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

• ADMIN_CLUSTER_KUBECONFIG: la ruta de acceso al archivo kubeconfig del clúster de administrador

• ADMIN_CLUSTER_CONFIG: la ruta de acceso al archivo de configuración del clúster de administrador

• USER_CLUSTER_CONFIG es la ruta de acceso del archivo de configuración del clúster de usuario.

Visualiza registros de Seesaw

El balanceador de cargas en paquetes de Seesaw almacena archivos de registro en las VM de Seesaw en /var/log/seesaw/. El archivo de registro más importante es seesaw_engine.INFO.

A partir de la versión 1.6, si se habilita Stackdriver, los registros también se suben a Cloud. Puedes verlos en el recurso "anthos_l4lb". Para inhabilitar la carga de registros, puedes establecer una conexión SSH a la VM y ejecutar lo siguiente:

sudo systemctl disable --now docker.fluent-bit.service

Visualiza información sobre las VM de Seesaw

Puedes obtener información sobre las VM de Seesaw de un clúster desde el recurso personalizado SeesawGroup.

Visualiza el recurso personalizado SeesawGroup de un clúster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get seesawgroups -n kube-system -o yaml

Reemplaza CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster.

En el resultado, hay un campo isReady en el que se muestra si las VM están listas para controlar el tráfico. En el resultado, también se muestran los nombres y las direcciones IP de las VM de Seesaw y cuál de las VM es la principal:

apiVersion: seesaw.gke.io/v1alpha1
kind: SeesawGroup
metadata:
  ...
  name: seesaw-for-cluster-1
  namespace: kube-system
  ...
spec: {}
status:
  machines:
  - hostname: cluster-1-seesaw-1
    ip: 172.16.20.18
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Master
  - hostname: cluster-1-seesaw-2
    ip: 172.16.20.19
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Backup

Visualiza métricas de Seesaw

El balanceador de cargas en paquetes de Seesaw proporciona las siguientes métricas:

• Capacidad de procesamiento por Service o nodo
• Frecuencia de paquetes por Service o nodo
• Conexiones activas por Service o nodo
• Uso de memoria y CPU
• Cantidad de pods de backend en buen estado por Service
• Cuál VM es la principal y cuál es la copia de seguridad
• Tiempo de actividad

A partir de la versión 1.6, esas métricas se suben a Cloud con Stackdriver. Puedes verlos en la supervisión de recursos de “anthos_l4lb”.

Puedes usar cualquier solución de supervisión y de paneles que elijas, siempre que sea compatible con el formato Prometheus.

Borrar un balanceador de cargas

Si borras un clúster que usa el balanceo de cargas en paquetes, debes borrar las VM de Seesaw de ese clúster. Para ello, borra las VM de Seesaw en la interfaz de usuario de vSphere.

Como alternativa, puedes ejecutar gkectl delete loadbalancer.

Para un clúster de administrador:

gkectl delete loadbalancer --config ADMIN_CLUSTER_CONFIG --seesaw-group-file GROUP_FILE

Para un clúster de usuario:

gkectl delete loadbalancer  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
    --seesaw-group-file GROUP_FILE

Reemplaza lo siguiente:

• ADMIN_CLUSTER_CONFIG: la ruta de acceso del archivo de configuración de tu clúster de administrador

• USER_CLUSTER_CONFIG: la ruta del archivo de configuración de tu clúster de usuario

• ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

• GROUP_FILE: la ruta del archivo del grupo de Seesaw El nombre del archivo del grupo tiene el formato
  seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.
  Por ejemplo: seesaw-for-gke-admin-12345.yaml

Configura políticas de firewall distribuido sin estado de NSX-T para usarlas con el balanceador de cargas de Seesaw

Si tu configuración usa el firewall distribuido con estado de NSX-T y también deseas usar el balanceador de cargas de Seesaw, tienes varias opciones. Elige la que mejor se ajuste a tu entorno.

Nota: Las instrucciones proporcionadas aquí hacen referencia a NSX-T 3.1. Si ejecutas una versión anterior de NSX, las opciones del menú pueden ser un poco diferentes.

Nota: Independientemente de no tener habilitadas políticas de firewall distribuido, siempre que el firewall distribuido no esté inhabilitado de manera explícita, deberás seguir una de las siguientes opciones de configuración.

Lista de tareas para la configuración de NSX

Antes de implementar una de las opciones de solución descritas, verifica que tengas la siguiente configuración de DFW de NSX:

• Las secciones de DFW con estado de NSX son la configuración predeterminada. Es probable que esto sea lo que tienes en tu entorno. Consulta Secciones de firewall y reglas de firewall.

• A veces, la inserción de servicios se usa con el DFW de NSX para proporcionar encadenamiento de servicios e inspección de L7 como parte de la integración de socios. Las políticas de inserción de servicios también tienen estado de forma predeterminada. Para confirmar que esta integración está habilitada en tu entorno, consulta la siguiente información.

Opción 1: Crea una política de firewall distribuida sin estado para los balanceadores de cargas de Seesaw

Con esta opción, puedes mantener el firewall distribuido habilitado en el entorno, mientras asignas la infraestructura de Anthos, en particular los balanceadores de cargas de Seesaw, a una política sin estado. Asegúrate de considerar las diferencias entre los firewalls sin estado y los con estado a fin de asegurarte de elegir el tipo más adecuado para tu entorno. Consulta Agrega una sección de regla de firewall en el modo de administrador: procedimiento, paso 6 de la documentación de VMware.

Para crear una política de firewall sin estado, haz lo siguiente:

1. Navega a Inventario > Etiquetas. Crea una etiqueta con el nombre seesaw.

2. Navega a Inventario > Grupos. Crea un grupo llamado Seesaw.

3. Configura los miembros del conjunto de Seesaw.

   • Haz clic en Miembros del conjunto. Configura los miembros del conjunto con criterios de membresía en función de la etiqueta seesaw que creaste. Aunque el uso de etiquetas NSX generalmente se considera una práctica recomendada de VMware, esta metodología requiere la automatización para configurarlas cada vez que el entorno cambie, como cuando actualizas o cambias el tamaño de los clústeres de Anthos en tu entorno. En ese caso, una política basada en otros criterios de membresía podría funcionar mejor. Puedes usar otras opciones de membresía dinámicas, como nombres de VM (incluidas expresiones regulares), segmentos y puertos de segmentos. Para obtener más información sobre los criterios de membresía del grupo, consulta Agrega un grupo.

4. Ve a Seguridad > Firewall distribuido. Crea una sección llamada Anthos.

5. Haz clic en el ícono de ajustes superior derecho y mueve el interruptor de Con estado a No.

   Nota: Una política sin estado no se puede cambiar a una con estado después de crearla.

6. Agrega reglas a la sección. Te recomendamos que agregues al menos dos reglas simétricas, como las siguientes:

   Source: Seesaw Group, Destination: Any, Applied to: Seesaw Group
   Source: Any, Destination: Seesaw Group, Applied to: Seesaw Group
   

7. Publica los cambios y verifica las operaciones.

La sección sin estado debe colocarse en la tabla de DFW de NSX para que tenga prioridad sobre otras secciones que podrían permitir el mismo tráfico, pero con estado, lo que enmascara las reglas sin estado. Asegúrate de que la sección sin estado sea la más específica y de que preceda a otras políticas que podrían crear una superposición.

Aunque no es obligatorio, puede crear un grupo que incluya todas las VM de Anthos mediante criterios de membresía generales, como la etiqueta de segmento, lo que significa que todas las VM conectadas a una red NSX específica se incluyen en el grupo. Luego, puedes usar este grupo en tu política sin estado.

Advertencia: Si usas la inserción de servicios de NSX, es probable que las reglas de redireccionamiento se encuentren dentro de una política con estado. De ser así, debes crear una política sin estado nueva y asegurarte de que el redireccionamiento de los balanceadores de cargas de Seesaw de Anthos se encuentre en ella.

Opción 2: Agrega las VM de Seesaw a la lista de exclusiones de firewall distribuidas

Con esta opción, puedes excluir las VM de la inspección de firewall distribuido por completo sin inhabilitar el DFW de NSX. Consulta Administra una lista de exclusiones de firewall.

1. Ve a Seguridad > Firewall distribuido. Selecciona Acciones > Lista de exclusiones.

2. Elige el grupo de Seesaw o el grupo que incluye todas las VM de Anthos.

Soluciona problemas

Obtén una conexión SSH a una VM de Seesaw

A veces, es posible que quieras establecer una conexión SSH con una VM de Seesaw para solucionar problemas o realizar una depuración.

Obtén la clave SSH

Si ya creaste el clúster, sigue estos pasos para obtener la clave SSH:

1. Obtén el secreto seesaw-ssh del clúster. Obtén la clave SSH del secreto y decodifícalo en Base64. Guarda la clave decodificada en un archivo temporal:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get -n  kube-system secret seesaw-ssh -o \
   jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-key
   

   Reemplaza CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster.

2. Configura los permisos adecuados para el archivo de claves:

   chmod 0600 /tmp/seesaw-ssh-key

   Si aún no creaste el clúster, sigue estos pasos para obtener la clave SSH:

3. Ubica el archivo llamado seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.

   Se llama group file y se encuentra junto a config.yaml.

   Además, mediante gkectl create loadbalancer, se imprime la ubicación del archivo del grupo.

4. En el archivo, obtén el valor de credentials.ssh.privateKey y decodifícalo en Base64. Guarda la clave decodificada en un archivo temporal:

   cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml  | grep privatekey | sed 's/    privatekey: //g' \
   | base64 -d > /tmp/seesaw-ssh-key
   

5. Configura los permisos adecuados para el archivo de claves:

   chmod 0600 /tmp/seesaw-ssh-key
   

Ahora puedes establecer una conexión SSH con la VM de Seesaw:

ssh -i /tmp/seesaw-ssh-key ubuntu@SEESAW_IP

Reemplaza SEESAW_IP por la dirección IP de la VM de Seesaw.

Obtén instantáneas

Puedes capturar instantáneas de las VM de Seesaw mediante el uso del comando gkectl diagnose snapshot junto con la marca --scenario.

Si configuras --scenario como all o all-with-logs, se incluirán instantáneas de Seesaw junto con otras instantáneas en el resultado.

Si configuras --scenario como seesaw, solo se incluirán instantáneas de Seesaw en el resultado.

Ejemplos:

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --scenario seesaw

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster-name CLUSTER_NAME --scenario seesaw

gkectl diagnose snapshot --seesaw-group-file GROUP_FILE --scenario seesaw

Reemplaza lo siguiente:

• ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

• GROUP_FILE: la ruta de acceso del archivo del grupo para el clúster.

Problemas conocidos

Cisco ACI no funciona con el retorno directo del servidor (DSR)

Seesaw se ejecuta en modo DSR y, de forma predeterminada, no funciona en Cisco ACI debido al aprendizaje de IP del plano de datos. Para encontrar una solución alternativa, puedes usar el grupo de extremos de aplicaciones aquí.

Citrix Netscaler no funciona con el retorno directo del servidor (DSR).

Si ejecutas el balanceador de cargas de Netscaler frente a Seesaw, se debe desactivar el reenvío basado en MAC (MBF). Consulta la documentación de Citrix.

La actualización del balanceador de cargas de Seesaw no funciona en algunos casos.

Si intentas actualizar un clúster desde la versión 1.8.0, o usas gkectl upgrade loadbalancer para actualizar algunos parámetros de tu balanceador de cargas de Seesaw en la versión 1.8.0, esto no funcionará en modo DHCP ni IPAM. Espera una corrección anunciada en una versión futura antes de realizar la actualización.