Versión 1.6. Esta versión ya no es compatible como se describe en la política de compatibilidad de versiones de Anthos. Para obtener los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a clústeres de Anthos alojados en VMware (GKE On-Prem), actualiza a una versión compatible. Puedes encontrar la versión más reciente aquí.

Versiones disponibles

Balanceo de cargas en paquetes con Seesaw

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. Este tema muestra cómo configurar clústeres de Anthos alojados en VMware para que se ejecuten en el modo de balanceo de cargas 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.

El balanceador de cargas en paquetes que proporciona clústeres de Anthos alojados en VMware es el balanceador de cargas Seesaw.

Ventajas del modo de balanceo de cargas en paquetes

El modo de balanceo de cargas en paquetes proporciona estas ventajas en comparación con el modo manual:

Un único equipo puede estar a cargo de la creación del clúster y la configuración del balanceador de cargas. Por ejemplo, un equipo de administración de clústeres no dependería de otro equipo de herramientas de redes para adquirir, ejecutar y configurar el balanceador de cargas con anticipación.
Clústeres de Anthos alojados en VMware configura de manera automática las direcciones IP virtuales (VIP) en el balanceador de cargas. En el momento de la creación del clúster, clústeres de Anthos alojados en VMware configura el balanceador de cargas con VIP para el servidor de API de Kubernetes, el servicio de entrada y los complementos del clúster. A medida que los clientes crean servicios de tipo LoadBalancer, clústeres de Anthos alojados en VMware configura de forma automática las VIP del servicio en el balanceador de cargas.
Se reducen las dependencias entre las organizaciones, los grupos y los administradores. En particular, el grupo que administra un clúster depende en menor medida del grupo que administra la red.

Versiones recomendadas

Recomendamos que uses vSphere 6.7 y el Virtual Distributed Switch (VDS) 6.6 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

Una instalación de clústeres de Anthos alojados en VMware tiene un clúster de administrador y uno o más clústeres de usuario. Con el modo de balanceo de cargas en paquetes, te recomendamos que tengas los clústeres en distintas VLAN y, en especial, que tu clúster de administrador esté en su propia 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 el balanceo de cargas empaquetado (Seesaw)

Con el balanceo de cargas empaquetado, aprovisiona tus recursos de CPU y memoria en función del tráfico de red que esperas encontrar.

El balanceador de cargas empaquetado no consume mucha memoria y se puede ejecutar en VM con 1 GB de memoria. Sin embargo, los aumentos en la frecuencia de paquetes de red requieren más CPU.

En la siguiente tabla, se muestran los lineamientos de almacenamiento, CPU y memoria para el aprovisionamiento de VM. Debido a que la tasa de paquetes no es una medida típica del rendimiento de red, en la tabla también se muestran las pautas para la cantidad máxima de conexiones de red activas. En las pautas, 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 empaquetado se ejecuta en modo de alta disponibilidad (HA), ejecuta un par activo y de 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 frecuencia de paquetes y CPU para realizar los cambios necesarios.

Si necesitas cambiar la CPU y la memoria de las VM de Seesaw, debes seguir las instrucciones para actualizar los balanceadores de cargas. Ten en cuenta que puedes mantener la misma versión del balanceador de cargas empaquetado y solo 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.

Storage	CPU	Memoria	Tasa de paquetes (pps)	Cantidad máxima de conexiones activas
20 GB	1 (entorno que no es de 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

Ten en cuenta que solo debes aprovisionar una sola CPU en un entorno que no sea de producción.

Reserva las direcciones IP virtuales

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.

Debes reservar un conjunto de VIP para el clúster de administrador y otro para cada clúster de usuario que desees crear. En el caso de un clúster determinado, estas VIP deben estar en la misma VLAN que los nodos y las VM de Seesaw de ese clúster.

Si deseas obtener instrucciones para reservar las VIP, consulta Reserva direcciones IP virtuales.

Reserva las direcciones IP de los 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. Para obtener más detalles sobre cuántas direcciones IP de nodos debes reservar, consulta Configura direcciones IP estáticas.

Reserva direcciones IP para las VM de Seesaw

A continuación, debes reservar las 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 alta disponibilidad (HA).

Caso 1: Balanceadores de cargas de Seesaw con alta disponibilidad

Para el clúster de administrador, debes reservar dos direcciones IP destinadas a un par de VM de Seesaw. También debes reservar una sola IP principal para el par de VM de Seesaw. Estas tres direcciones deben estar en la misma VLAN que los nodos del clúster de administrador.

Por cada clúster de usuario que desees crear, debes reservar dos direcciones IP para un par de VM de Seesaw. Además, por cada uno, debes reservar una sola IP principal para el par de VM de Seesaw. En el caso de un clúster de usuario determinado, las tres direcciones deben estar en la misma VLAN que los nodos del clúster de usuario.

Caso 2: Balanceadores de cargas de Seesaw sin alta disponibilidad

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

Por cada clúster de usuario que desees crear, debes reservar una dirección IP para una VM de Seesaw. Además, por cada clúster de usuario, debes reservar una IP 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 los puertos

Cada una de las VM de Seesaw tiene dos interfaces de red. Una de esas interfaces de red se configura con VIP de servicio. La otra se configura con la dirección IP de la VM.

En el caso de una VM individual de Seesaw, las dos interfaces de red se pueden conectar al mismo grupo de puertos de vSphere o a grupos de puertos diferentes. Si los grupos de puertos son diferentes, deben estar en la misma VLAN.

En este tema, se hace referencia a dos grupos de puertos:

grupo de puertos del balanceador de cargas: En una VM de Seesaw, la interfaz de red configurada con VIP de servicio se conecta a este grupo de puertos.
grupo de puertos del nodo del clúster: En una VM de Seesaw, la interfaz de red configurada con la dirección IP de la VM se conecta a este grupo de puertos. Tus nodos de clúster de clústeres de Anthos alojados en VMware también están conectados a este grupo de puertos.

El grupo de puertos del balanceador de cargas y el del nodo del clúster pueden ser el mismo. Sin embargo, recomendamos que sean independientes.

Crea archivos de bloqueo de IP

En cada clúster que desees crear, especifica las direcciones que elegiste para tus VM de Seesaw en un archivo de bloque de IP. Este archivo de bloque de IP es para tu VM del balanceador de cargas, no para los nodos del clúster. 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. Este es un ejemplo de un archivo de bloque de IP que especifica dos direcciones IP para VM de Seesaw:

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.18"
      hostname: "seesaw-vm"

Completa los archivos de configuración

Prepara un archivo de configuración para cada uno de los clústeres: el clúster de administrador y el clúster de usuario.

En el archivo de configuración de cada clúster, configura loadBalancer.kind como "Seesaw".

En cada clúster del archivo de configuración, completa la sección seesaw en la sección loadBalancer.

loadBalancer:
  kind: Seesaw
  seesaw:
    ipBlockFilePath::
    vrid:
    masterIP:
    cpus:
    memoryMB:
    vCenter:
      networkName:
    enableha:
    antiAffinityGroups:
      enabled:

`seesaw.ipBlockFilePath`

String. Establece esto en la ruta del archivo de bloque de IP para tus VM de Seesaw. Por ejemplo:

loadBalancer:
  seesaw:
    ipBlockFilePath: "admin-seesaw-ipblock.yaml"

`seesaw.vrid`

Número entero. Es el identificador del router virtual de la VM de Seesaw. Este identificador debe ser único en una VLAN. El rango válido es de 1 a 255. Por ejemplo:

loadBalancer:
  seesaw:
    vrid: 125

`seesaw.masterIP`

String. La IP principal de Seesaw. Por ejemplo:

loadBalancer:
  seesaw:
    masterIP: 172.16.20.21

`seesaw.cpus`

Número entero. Es la cantidad de CPU para la VM de Seesaw. Por ejemplo:

loadBalancer:
  seesaw:
    cpus: 4

`seesaw.memoryMB`

Número entero. Es la cantidad de megabytes de memoria para la VM de Seesaw. Por ejemplo:

loadBalancer:
  seesaw:
    memoryMB: 3072

`seesaw.vCenter.networkName`

String. Es el nombre de la red que contiene las VM de Seesaw. Si no se configura, se usa la misma red que para el clúster. Por ejemplo:

loadBalancer:
  seesaw:
    vCenter:
      networkName: "my-seesaw-network"

`seesaw.enableHA`

Booleano. Si deseas crear un balanceador de cargas de Seesaw con alta disponibilidad, configura esto como true. De lo contrario, configúralo como false. Por ejemplo:

loadBalancer:
  seesaw:
    enableHA: true

Si configuras enableha como true, debes habilitar el aprendizaje de MAC.

`seesaw.antiAffinityGroups.enabled`

Si deseas aplicar una regla antiafinidad en las VM de Seesaw, configura el valor de seesaw.antiAffinityGroups.enabled como true. De lo contrario, configúralo como false. El valor predeterminado es true. El valor recomendado es true, de forma que las VM de Seesaw se coloquen en hosts físicos diferentes siempre que sea posible. Por ejemplo:

loadBalancer:
  seesaw
    antiAffinityGroups:
      enabled: true

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 configuras un balanceador de cargas de Seesaw con alta disponibilidad, 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 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 de tu archivo de configuración de clústeres de Anthos alojados en VMware. 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.

Ejecuta una verificación previa en el archivo de configuración

Después de crear los archivos de bloque de IP y el archivo de configuración de tu clúster de administrador, ejecuta una comprobación previa en tu archivo de configuración:

gkectl check-config --config [ADMIN_CONFIG_FILE]

donde [ADMIN_CONFIG_FILE] es la ruta de acceso a tu archivo de configuración del clúster de administrador de clústeres de Anthos alojados en VMware.

Luego, en el archivo de configuración de clúster de usuario, debes incluir el archivo kubeconfig del clúster de administrador en el comando:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] check-config --config [USER_CONFIG_FILE]

En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig del clúster de administrador.

Si falla la verificación de comprobación previa, realiza los ajustes necesarios en tu archivo de configuración de clústeres de Anthos alojados en VMware y en los archivos de bloque de IP según sea necesario. Luego, vuelve a ejecutar la verificación previa.

Sube imágenes de SO

Ejecuta este comando para subir imágenes de SO al entorno de vSphere:

gkectl prepare --config [ADMIN_CONFIG_FILE]

donde [ADMIN_CONFIG_FILE] es la ruta de acceso a tu archivo de configuración del clúster de administrador de clústeres de Anthos alojados en VMware.

Crea un clúster de administrador que use el modo de balanceo de cargas en paquetes

Crea y configura las VM para el balanceador de cargas del clúster de administrador:

gkectl create loadbalancer --config [CONFIG_FILE]

donde [CONFIG_FILE] es la ruta de acceso a tu archivo de configuración clústeres de Anthos alojados en VMware para el clúster de administrador.

Crea el clúster de administrador:

gkectl create admin --config [CONFIG_FILE]

donde [CONFIG_FILE] es la ruta de acceso a tu archivo de configuración del clúster de administrador de clústeres de Anthos alojados en VMware.

Crea un clúster de usuario que use el modo de balanceo de cargas en paquetes

Crea y configura las VM para el balanceador de cargas del clúster de usuario:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create loadbalancer --config [CONFIG_FILE]

Crea el clúster de usuario:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create cluster --config [CONFIG_FILE]

donde [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig para tu clúster de administrador y [CONFIG_FILE] es la ruta de acceso a tu archivo de configuración del clúster de usuario de clústeres de Anthos alojados en VMware

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 * 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 del clúster de administrador

A partir de la versión 1.4, los balanceadores de cargas se actualizan cuando se actualiza el clúster. No es necesario ejecutar otros comandos para actualizar los balanceadores de cargas por separado. De todas formas, puedes usar el siguiente gkectl upgrade loadbalancer para actualizar algunos parámetros.

Puedes actualizar las CPU y la memoria de las VM de Seesaw. Crea un nuevo archivo de configuración como se muestra en el siguiente ejemplo y configura las CPU y la memoria para las VM de Seesaw. Déjalas vacías para mantenerlas sin cambios. Si se configura bundlePath, el balanceador de cargas se actualizará al que se especifica en el paquete.

Por ejemplo:

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

Luego, ejecuta este comando para actualizar el balanceador de cargas:

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CLUSTER_CONFIG] --admin-cluster

Donde:

[ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig para el clúster de administrador.
[ADMIN_CLUSTER_CONFIG] es el archivo de configuración del clúster de administrador que creaste.

Durante la actualización de un balanceador de cargas, habrá tiempo de inactividad. Si la alta disponibilidad está habilitada en el balanceador de cargas, el tiempo de inactividad máximo es de dos segundos.

Actualiza el balanceador de cargas de un clúster de usuario

Puedes actualizar las CPU y la memoria de las VM de Seesaw. Crea un nuevo archivo de configuración como se muestra en el siguiente ejemplo y configura las CPU y la memoria para las VM de Seesaw. Déjalas vacías para mantenerlas sin cambios. Si se configura gkeOnPremVersion, el balanceador de cargas se actualizará al que especifica esta versión.

Por ejemplo:

apiVersion: v1
kind: UserCluster
name: cluster-1
gkeOnPremVersion:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 4
    memoryMB: 3072

Luego, ejecuta este comando para actualizar el balanceador de cargas:

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

Donde:

[ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig para el clúster de administrador.
[USER_CLUSTER_CONFIG] es el archivo de configuración del usuario que creaste.

Visualiza los 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

En el ejemplo anterior, [CLUSTER_KUBECONFIG] es 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.

Borra 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, a partir de 1.4.2, puedes ejecutar gkectl y pasar archivos de configuración para borrar el balanceador de cargas en paquetes y su archivo de grupo.

Para los clústeres de administrador, ejecuta el siguiente comando:

gkectl delete loadbalancer --config [ADMIN_CONFIG_FILE] --seesaw-group-file [GROUP_FILE]

Para los clústeres de usuario, ejecuta el siguiente comando:

gkectl delete loadbalancer --config [CLUSTER_CONFIG_FILE] --seesaw-group-file [GROUP_FILE] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

donde

[ADMIN_CONFIG_FILE] es el archivo de configuración del clúster de administrador
[CLUSTER_CONFIG_FILE] es el archivo de configuración del clúster de usuario
[ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador
[GROUP_FILE] es el archivo del grupo de Seesaw. El nombre del archivo del grupo tiene el formato seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml.

Versiones anteriores a 1.14.2

En versiones anteriores a 1.4.2, como alternativa, puedes ejecutar este comando, que borra las VM de Seesaw y el archivo de grupo Seesaw:

gkectl delete loadbalancer --config vsphere.yaml --seesaw-group-file [GROUP_FILE]

donde

[GROUP_FILE] es el archivo del grupo de Seesaw. El archivo del grupo se encuentra en la estación de trabajo de administrador, junto a config.yaml. El nombre del archivo del grupo tiene el formato seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml.
vsphere.yaml es un archivo que contiene la siguiente información sobre el servidor de vCenter:

vcenter:
  credentials:
    address:
    username:
    password:
  datacenter:
  cacertpath:

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:

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
```
En el ejemplo anterior, [CLUSTER_KUBECONFIG] es el archivo kubeconfig para el clúster.
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:

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.
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
```
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]

En el ejemplo anterior, [SEESAW_IP] es 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

En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig para el clúster de administrador.

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

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

En el ejemplo anterior, [GROUP_FILE] es la ruta de acceso del archivo del grupo para el clúster, por ejemplo: seesaw-for-gke-admin-xxxxxx.yaml.

Problemas conocidos

No se puede actualizar el balanceador de cargas de la versión 1.3.x

Se sabe que si antiaffinitygroups está inhabilitado en un balanceador de cargas de Seesaw, la actualización del balanceador de cargas de la versión 1.3.x a la 1.3.x+ fallará con un error:

“El SeesawGroup actualizado no es válido:”, “SeesawConfig no es válido:” o “AntiAffinityGroups se debe establecer en el valor predeterminado si el usuario no lo proporciona”

Esto se corrigió en la versión 1.4, por lo que puedes omitir la versión 1.3.x+ y actualizar a la 1.4.