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 o posterior y el Virtual Distributed Switch (VDS) 6.6 o 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
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 (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 |
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.
A fin de obtener instrucciones para separar los VIP, consulta Crea un clúster de administrador.
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 información sobre cuántas direcciones IP de nodos se deben configurar, consulta Crea un clúster de administrador.
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. En el caso del clúster de administrador, también debes reservar una sola IP de instancia 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, para cada clúster de usuario, separa una dirección IP principal única 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. Además, en el clúster de administrador, reserva 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 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 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
Cada una de las VM de Seesaw tiene dos interfaces de red. Una de esas interfaces de red se configura con VIP. La otra interfaz de red se configura con una dirección IP tomada de un archivo de bloqueo de IP que debes proporcionar.
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 se conecta a este grupo de puertos.
grupo de puertos del nodo de clústeres: para una VM de Sesaw, la interfaz de red que está configurada con una dirección IP tomada de tu archivo de bloque de IP se conecta a este grupo de puertos. Los nodos del clúster 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.
En el siguiente diagrama, se ilustra la configuración de red recomendada para el balanceo de cargas de Seesaw:
Nodos de clúster y VM de Seesaw en una VLAN
En el diagrama anterior, se representa un solo clúster, ya sea un clúster de administrador o un clúster de usuario. Recuerda que recomendamos que cada clúster esté en su propia VLAN.
En el diagrama, puedes ver las siguientes características de la red:
Hay dos VM de Seesaw, una principal y una copia de seguridad.
Las VM de Seesaw están en la misma VLAN que los nodos del clúster.
La VM de Seesaw de copia de seguridad tiene dos interfaces de red. Una interfaz se configura con una dirección IP tomada de tu archivo de bloque de IP de Seesaw. La otra interfaz no está configurada con ninguna dirección IP.
La VM principal de Seesaw tiene dos interfaces de red. Una interfaz se configura con una dirección IP tomada de tu archivo de bloque de IP de Seesaw. La otra interfaz está configurada con VIP.
Cada VM de Seesaw tiene una interfaz de red conectada al grupo de puertos del balanceador de cargas. Todas las demás interfaces de red en el diagrama están conectadas al grupo de puertos del nodo del clúster.
Todas las direcciones IP, incluidas las VIP, configuradas en las interfaces de red que se muestran en el diagrama deben ser enrutables a la VLAN.
Para un clúster de administrador, la interfaz de las VIP de la VM principal de Seesaw se configura con las siguientes direcciones IP:
- La VIP de la VM principal de Seesaw del clúster de administrador
- La VIP de complementos de clúster de administrador
- La VIP del plano de control para el clúster de administrador
- Las VIP del plano de control para todos los clústeres de usuario asociados.
- VIP para Services de tipo LoadBalancer que se ejecutan en el clúster de administrador
Para un clúster de usuarios, la interfaz de las VIP en la VM principal de Seesaw se configura con las siguientes direcciones IP:
- La VIP para la VM principal de Seesaw del clúster de usuario
- La VIP de entrada del clúster de usuario
- VIP para Services de tipo LoadBalancer que se ejecutan en el clúster de usuario
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-1"
- ip: "172.16.20.19"
hostname: "seesaw-vm-2"
Completa los archivos de configuración
Prepara un archivo de configuración para cada uno de tus clústeres: un clúster de administrador y uno o más clústeres 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:
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 dirección IP de la instancia principal para el balanceador de cargas de Seesaw. Por ejemplo:
loadBalancer:
seesaw:
masterIP: 172.16.20.21
seesaw.cpus
Número entero. Es la cantidad de CPU para cada VM de Seesaw. Por ejemplo:
loadBalancer:
seesaw:
cpus: 4
seesaw.memoryMB
Número entero. Es la cantidad de megabytes de memoria para cada 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 de 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 configuraste loadBalancer.seesaw.disableVRRPMAC como verdadero, no se requiere la configuración de aprendizaje de MAC, aunque tu red debe ser compatible con la conmutación por error de IP mediante un ARP injustificado.
Consulta el archivo de configuración del clúster de usuario.
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: |
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]
En el ejemplo anterior, [ADMIN_CONFIG_FILE] es la ruta de acceso del archivo de configuración de tu clúster de administrador.
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 la comprobación previa falla, realiza ajustes en el archivo de configuración del clúster y en los archivos de bloqueo 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]
En el ejemplo anterior, [ADMIN_CONFIG_FILE] es la ruta de acceso del archivo de configuración de tu clúster de administrador.
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]
En el ejemplo anterior, [CONFIG_FILE] es la ruta de acceso del archivo de configuración de tu clúster de administrador.
Crea el clúster de administrador:
gkectl create admin --config [CONFIG_FILE]
En el ejemplo anterior, [CONFIG_FILE] es la ruta de acceso del archivo de configuración de tu clúster de administrador.
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]
En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta del archivo kubeconfig del clúster de administrador y [CONFIG_FILE] es la ruta del archivo de configuración del clúster de usuario.
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
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 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.
[CLUSTER_NAME] es el nombre del clúster que se está actualizando.
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
kubeconfigdel 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 formatoseesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml.vsphere.yamles 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-sshdel 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-keyEn 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.privateKeyy 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
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í.