GKE sur VMware peut s'exécuter dans l'un des trois modes d'équilibrage de charge : intégré, manuel ou groupé. Ce document explique comment configurer GKE sur VMware pour exécuter l'équilibreur de charge Seesaw en mode groupé.
Ces instructions sont complètes. Pour une présentation plus courte de l'utilisation de l'équilibreur de charge Seesaw, consultez la page Équilibreur de charge Seesaw (guide de démarrage rapide).
En mode d'équilibrage de charge groupé, GKE sur VMware fournit et gère l'équilibreur de charge. Vous n'avez pas besoin d'obtenir une licence pour un équilibreur de charge, et la configuration à effectuer est minimale.
Ce document explique comment configurer l'équilibreur de charge Seesaw pour un cluster d'administrateur et un cluster d'utilisateur associé. Vous pouvez exécuter l'équilibreur de charge Seesaw sur une seule VM ou en mode haute disponibilité, qui utilise deux VM. En mode haute disponibilité, l'équilibreur de charge Seesaw utilise le protocole VRRP (Virtual Router Redundancy Protocol). Les deux VM sont appelées principale et secours. Chaque VM Seesaw reçoit un identifiant de routeur virtuel (VRID, virtual router identifier) de votre choix.
Exemple de configuration Seesaw
Voici un exemple de configuration pour les clusters exécutant l'équilibreur de charge Seesaw en mode haute disponibilité :
Le schéma précédent montre deux VM Seesaw pour le cluster d'administrateur, et deux pour le cluster d'utilisateur. Dans cet exemple, le cluster d'administrateur et le cluster d'utilisateur se trouvent sur deux VLAN distincts, et chaque cluster se trouve dans un sous-réseau distinct :
| Cluster | Sous-réseau |
|---|---|
| Cluster d'administrateur | 172.16.20.0/24 |
| Cluster d'utilisateur | 172.16.40.0/24 |
admin-cluster.yaml
L'exemple suivant de fichier de configuration de cluster d'administrateur montre la configuration observée dans le schéma précédent :
Adresse IP principale de la paire de VM Seesaw du cluster d'administrateur.
Adresse IP virtuelle désignée pour le serveur d'API Kubernetes du cluster d'administrateur.
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
L'exemple suivant de fichier de bloc d'adresses IP indique la désignation des adresses IP pour les nœuds du cluster d'administrateur. Il inclut également l'adresse du nœud de plan de contrôle du cluster d'utilisateur et une adresse IP à utiliser lors de la mise à niveau du cluster.
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
L'exemple suivant d'un autre fichier de bloc d'adresses IP spécifie deux adresses IP pour les VM Seesaw du cluster d'administrateur. Notez qu'il s'agit d'un fichier de bloc d'adresses IP distinct pour les VM de l'équilibreur de charge, et non pour les nœuds du cluster.
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
L'exemple suivant de fichier de configuration de cluster d'utilisateur montre la configuration :
Adresse IP principale de la paire de VM Seesaw du cluster d'utilisateur.
Adresses IP virtuelles désignées pour le serveur d'API Kubernetes et le service d'entrée du cluster d'utilisateur. L'adresse IP virtuelle du serveur d'API Kubernetes se trouve sur le sous-réseau du cluster d'administrateur, car le plan de contrôle d'un cluster d'utilisateur s'exécute sur un nœud du cluster d'administrateur ;
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
L'exemple suivant de fichier de bloc d'adresses IP indique la désignation des adresses IP pour les nœuds du cluster d'utilisateur. Il inclut une adresse IP à utiliser lors de la mise à niveau du cluster.
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
L'exemple suivant d'un autre fichier de bloc d'adresses IP spécifie deux adresses IP pour les VM Seesaw du cluster d'utilisateur.
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"
Groupes de ports
Le tableau suivant décrit la configuration des interfaces réseau pour chacune des VM Seesaw et leurs groupes de ports connectés, comme illustré dans le schéma précédent.
| VM Seesaw | Interface réseau | Configuration de l'interface réseau | Groupe de ports connecté |
|---|---|---|---|
| Master | network-interface-1 | Adresses IP virtuelles | load-balancer |
| network-interface-2 | Adresse IP provenant du fichier de bloc d'adresses IP des VM Seesaw | cluster-node | |
| Backup | network-interface-1 | Aucune configuration | load-balancer |
| network-interface-2 | Adresse IP provenant du fichier de bloc d'adresses IP des VM Seesaw | cluster-node |
Les nœuds du cluster sont également connectés au groupe de ports "cluster-node".
Comme le montre le tableau précédent, chacune des VM Seesaw des clusters d'administrateur et d'utilisateur possède deux interfaces réseau. Pour chaque VM Seesaw, les deux interfaces réseau sont connectées à deux groupes de ports distincts :
Groupe de ports load-balancer
Groupe de ports cluster-node
Les deux groupes de ports d'un cluster se trouvent dans le même VLAN.
Configurer l'équilibreur de charge Seesaw
Versions recommandées
Le schéma précédent présente la configuration réseau recommandée pour l'équilibrage de charge Seesaw. Lorsque vous planifiez votre propre configuration, nous vous recommandons vivement d'utiliser les versions 6.7 et ultérieures de vSphere et 6.6 et ultérieures de Virtual Distributed Switch (VDS) pour le mode d'équilibrage de charge groupé.
Vous pouvez utiliser des versions antérieures si vous le souhaitez, mais votre installation sera moins sécurisée. Les sections restantes de cette rubrique fournissent des informations plus détaillées sur les avantages de vSphere 6.7+ et de Virtual Distributed Switch (VDS) 6.6+ en termes de sécurité.
Planifier vos VLAN
Avec le mode d'équilibrage de charge groupé, nous vous recommandons vivement de disposer vos clusters sur des VLAN distincts.
Si votre cluster d'administrateur se trouve sur son propre VLAN, le trafic du plan de contrôle est séparé du trafic du plan de données. Cette séparation protège le cluster d'administrateur et les plans de contrôle du cluster d'utilisateur contre les erreurs de configuration accidentelles. De telles erreurs peuvent entraîner, par exemple, des problèmes tels qu'une tempête de diffusion due à des boucles de couche 2 dans le même VLAN, ou à une adresse IP en conflit qui élimine la séparation souhaitée entre le plan de données et le plan de contrôle.
Provisionner des ressources de VM
Pour les VM qui exécutent votre équilibreur de charge Seesaw, provisionnez les ressources de processeur et de mémoire en fonction du trafic réseau que vous prévoyez de rencontrer.
L'équilibreur de charge Seesaw n'est pas gourmand en mémoire et peut s'exécuter sur des VM dotées de 1 Go de mémoire. Cependant, l'exigence du processeur augmente à mesure que le débit des paquets du réseau augmente.
Le tableau suivant présente les consignes en matière d'espace de stockage, de processeur et de mémoire pour le provisionnement des VM Seesaw. Le taux de paquets n'étant pas une mesure typique des performances du réseau, le tableau indique également le nombre maximal de connexions réseau actives. Les consignes supposent un environnement dans lequel les VM ont une liaison de 10 Gbit/s, et des processeurs exécutés à moins de 70 %.
Lorsque l'équilibreur de charge Seesaw s'exécute en mode haute disponibilité, il utilise une paire (maître, sauvegarde). Ainsi, tout le trafic passe par une seule VM. Étant donné que les cas d'utilisation réels varient, ces consignes doivent être modifiées en fonction de votre trafic réel. Surveillez vos métriques de CPU et de débit de paquets pour déterminer les modifications nécessaires.
Si vous devez modifier le processeur et la mémoire pour vos VM Seesaw, consultez la section Mettre à niveau un équilibreur de charge. Sachez que vous pouvez conserver la même version de l'équilibreur de charge et modifier le nombre de processeurs et l'allocation de mémoire.
Pour les clusters d'administrateur de petite taille, nous recommandons 2 processeurs. Pour les clusters d'administrateur de grande taille, nous recommandons 4 processeurs.
| Stockage | Processeur | Mémoire | Débit de paquets | Nombre maximal de connexions actives |
|---|---|---|---|---|
| 20 Go | 1 (hors production) | 1 Go | 250 k | 100 |
| 20 Go | 2 | 3 Go | 450 k | 300 |
| 20 Go | 4 | 3 Go | 850k | 6 000 |
| 20 Go | 6 | 3 Go | 1 000 k | 10 000 |
Réserver des adresses IP virtuelles et des adresses IP
Adresses IP virtuelles
Quel que soit le mode d'équilibrage de charge que vous avez choisi, vous devez mettre de côté les adresses IP virtuelles (VIP) que vous souhaitez utiliser pour l'équilibrage de charge. Ces adresses IP virtuelles permettent aux clients externes d'accéder à vos serveurs d'API Kubernetes, à vos services Ingress et à vos services complémentaires.
Réfléchissez également au nombre de services de type LoadBalancer qui sont susceptibles d'être actifs dans votre cluster d'utilisateur à un moment donné, et réservez suffisamment d'adresses IP virtuelles pour ces services. Lorsque vous créerez des services de type LoadBalancer ultérieurement, les clusters Anthos sur VMware configureront automatiquement les adresses IP virtuelles de service sur l'équilibreur de charge.
Adresses IP des nœuds
Avec le mode d'équilibrage de charge groupé, vous pouvez spécifier des adresses IP statiques pour vos nœuds de cluster, mais ces derniers peuvent également obtenir leurs adresses IP à partir d'un serveur DHCP.
Si vous souhaitez que vos nœuds de cluster aient des adresses IP statiques, réservez suffisamment d'adresses aux nœuds du cluster d'administrateur et aux nœuds de tous les clusters d'utilisateurs que vous souhaitez créer. Réservez également une adresse IP supplémentaire pour chaque cluster à utiliser lors de la mise à niveau. Pour en savoir plus sur le nombre d'adresses IP de nœud à réserver, consultez la section Créer un cluster d'administrateur.
Adresses IP pour les VM Seesaw
Ensuite, pour chaque cluster, d'administrateur et d'utilisateur, réservez les adresses IP des VM qui exécuteront vos équilibreurs de charge Seesaw. Le nombre d'adresses à mettre de côté varie selon que vous souhaitez créer des équilibreurs de charge Seesaw à disponibilité élevée ou des équilibreurs de charge Seesaw standards.
Adresses IP principales
Outre les adresses IP des VM Seesaw, réservez également une adresse IP principale unique pour la paire de VM Seesaw de chaque cluster.
Configuration standard
Si votre configuration est standard, procédez comme suit :
Dans le cluster d'administrateur, définissez une adresse IP pour une VM Seesaw et une adresse IP maître pour l'équilibreur de charge Seesaw. Ces deux adresses doivent se trouver sur le même VLAN que les nœuds de votre cluster d'administrateur.
Dans votre cluster d'utilisateur, réservez une adresse IP pour une VM Seesaw et une adresse IP maître pour l'équilibreur de charge Seesaw. Ces deux adresses doivent se trouver sur le même VLAN que les nœuds du cluster d'utilisateur.
Planifier des groupes de ports
Le diagramme ci-dessus décrit les deux groupes de ports utilisés dans une configuration haute disponibilité et la manière dont ils sont connectés aux interfaces réseau sur les VM Seesaw. Pour une VM Seesaw, décidez si vous souhaitez que les deux interfaces réseau soient connectées au même groupe de ports vSphere ou à des groupes de ports distincts. Si vous n'activez pas l'apprentissage MAC, vous pouvez utiliser un seul groupe de ports. Si les groupes de ports sont distincts, ils doivent se trouver sur le même VLAN.
Créer des fichiers de blocs d'adresses IP
Pour chaque cluster, d'administrateur et d'utilisateur, spécifiez les adresses que vous avez choisies pour vos VM Seesaw dans un fichier de bloc d'adresses IP. Si vous avez l'intention d'utiliser des adresses IP statiques pour vos nœuds de cluster, vous devez créer un fichier de bloc d'adresses IP distinct pour ces adresses.
Remplir vos fichiers de configuration
Préparez un fichier de configuration pour votre cluster d'administrateur et un autre fichier de configuration pour votre cluster d'utilisateur.
Dans le fichier de configuration d'un cluster donné, définissez loadBalancer.kind sur "Seesaw".
Sous loadBalancer, remplissez la section seesaw :
loadBalancer: kind: Seesaw seesaw:
Pour savoir comment remplir la section seesaw d'un fichier de configuration de cluster, consultez la section loadbalancer.seesaw (cluster d'administrateur) ou loadbalancer.seesaw (cluster d'utilisateur).
Dans le fichier de configuration du cluster d'administrateur, indiquez les éléments suivants :
- Adresse IP virtuelle pour le serveur d'API Kubernetes du cluster d'administrateur
- Adresses IP virtuelles des modules complémentaires du cluster d'administrateur
- Adresse IP principale de la paire de VM Seesaw du cluster d'administrateur.
Ces adresses IP virtuelles doivent se trouver sur le sous-réseau du cluster d'administrateur.
Dans le fichier de configuration du cluster d'utilisateur, spécifiez les éléments suivants :
- Adresse IP virtuelle du serveur d'API Kubernetes du cluster d'utilisateur (doit se trouver sur le sous-réseau du cluster d'administrateur)
- Adresse IP virtuelle d'entrée dans le cluster d'utilisateur
- Adresse IP principale de la paire de VM Seesaw du cluster d'utilisateur.
Les deux dernières adresses de la liste précédente doivent se trouver sur le sous-réseau du cluster d'utilisateur.
Activer l'apprentissage MAC ou le mode promiscuité (haute disponibilité uniquement)
Si vous configurez un équilibreur de charge Seesaw standard, vous pouvez ignorer cette section.
Si vous avez défini loadBalancer.seesaw.disableVRRPMAC sur "true", vous pouvez ignorer cette section.
Si vous configurez un équilibreur de charge Seesaw à haute disponibilité et avez défini loadBalancer.seesaw.disableVRRPMAC sur false, vous devez activer une combinaison d'apprentissage MAC, de transmissions falsifiées et de mode promiscuité sur le groupe de ports de l'équilibreur de charge.
La méthode d'activation de ces fonctionnalités varie selon le type de commutateur :
| Type de commutateur | Activation des fonctionnalités | Impact sur la sécurité |
|---|---|---|
| vSphere 7.0 VDS |
Sur vSphere 7.0 à haute disponibilité, vous devez définir loadBalancer.seesaw.disableVRRPMAC sur true. L'apprentissage MAC n'est pas compatible.
|
|
| vSphere 6.7 avec VDS 6.6 |
Activez l'apprentissage MAC et les transmissions falsifiées pour votre équilibreur de charge en exécutant la commande suivante : |
Minimal. Si le groupe de ports de votre équilibreur de charge n'est connecté qu'à vos VM Seesaw, vous pouvez limiter l'apprentissage MAC à vos VM Seesaw de confiance. |
vSphere 6.5 ou vSphere 6.7 avec une version de VDS antérieure à 6.6 |
Activez le mode promiscuité et les transmissions falsifiées pour le groupe de ports de votre équilibreur de charge. Dans l'onglet Mise en réseau, utilisez l'interface utilisateur de vSphere sur la page du groupe de ports : Modifier les paramètres -> Sécurité. | Toutes les VM du groupe de ports de l'équilibreur de charge sont en mode promiscuité. Ainsi, elles peuvent toutes voir l'ensemble du trafic. Si le groupe de ports de votre équilibreur de charge n'est connecté qu'à vos VM Seesaw, seules ces VM verront l'ensemble du trafic. |
| Commutateur logique NSX-T | Activez l'apprentissage MAC sur le commutateur logique. | vSphere ne permet pas de créer deux commutateurs logiques dans le même domaine de couche 2. Par conséquent, les VM Seesaw et les nœuds de cluster doivent se trouver sur le même commutateur logique. Cela signifie que l'apprentissage MAC est activé pour tous les nœuds de cluster. Un pirate informatique peut être en mesure de falsifier une adresse MAC en exécutant des pods privilégiés dans le cluster. |
| Commutateur standard vSphere | Activez le mode promiscuité et les transmissions falsifiées pour le groupe de ports de votre équilibreur de charge. Utilisez l'interface utilisateur vSphere sur chaque hôte ESXI : Configurer -> Commutateurs virtuels -> Commutateur standard -> Modifier le paramètre sur le groupe de ports -> Sécurité. | Toutes les VM du groupe de ports de l'équilibreur de charge sont en mode promiscuité. Ainsi, elles peuvent toutes voir l'ensemble du trafic. Si le groupe de ports de votre équilibreur de charge n'est connecté qu'à vos VM Seesaw, seules ces VM verront l'ensemble du trafic. |
Terminer de remplir le fichier de configuration de votre cluster d'administrateur
Suivez les instructions de la section Créer un cluster d'administrateur pour terminer le remplissage du fichier de configuration de votre cluster d'administrateur.
Exécuter des vérifications préliminaires
Exécutez les vérifications préliminaires sur le fichier de configuration de votre cluster d'administrateur :
gkectl check-config --config ADMIN_CLUSTER_CONFIG
Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.
Importer des images de l'OS
Importez des images de l'OS dans votre environnement vSphere :
gkectl prepare --config ADMIN_CLUSTER_CONFIG
Créer un équilibreur de charge pour votre cluster d'administrateur
gkectl create loadbalancer --config [ADMIN_CLUSTER_CONFIG]
Créer votre cluster d'administrateur
Pour créer votre cluster d'administrateur, suivez les instructions de la section Créer un cluster d'administrateur.
Terminer le remplissage des fichiers de configuration de cluster d'utilisateur
Suivez les instructions de la page Créer un cluster d'utilisateur pour terminer le remplissage du fichier de configuration de votre cluster d'utilisateur.
Exécuter des vérifications préliminaires
Exécutez les vérifications préliminaires sur le fichier de configuration de votre cluster d'utilisateur :
gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
Remplacez les éléments suivants :
ADMIN_CLUSTERE_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
Importer des images de l'OS
Importez des images de l'OS dans votre environnement vSphere :
gkectl prepare --config USER_CLUSTER_CONFIG
Créer un équilibreur de charge pour votre cluster utilisateur
Créer un équilibreur de charge pour votre cluster utilisateur
gkectl create loadbalancer --config USER_CLUSTER_CONFIG
Créer votre cluster d'utilisateur
Pour créer votre cluster d'utilisateur, suivez les instructions de la section Créer un cluster d'utilisateur.
Tests de performance et de charge
Le débit de téléchargement de votre application évolue de manière linéaire avec le nombre de backends. En effet, les backends envoient des réponses directement aux clients, en contournant l'équilibreur de charge, à l'aide du retour direct du serveur.
En revanche, le débit de transfert de votre application est limité par la capacité de la VM Seesaw qui exécute l'équilibrage de charge.
La quantité de consommation de processeur et de mémoire requises varie en fonction des applications. Il est donc essentiel de procéder à un test de charge avant de commencer à traiter un grand nombre de clients.
Les tests indiquent qu'une seule machine de type Seesaw avec 6 processeurs et 3 Go de mémoire peut gérer 10 Go/s (débit en ligne) en important 10 Ko de connexions TCP simultanées. Cependant, il est important d'exécuter votre propre test de charge si vous envisagez de prendre en charge un grand nombre de connexions TCP simultanées.
Limites de scaling
Le mode d'équilibrage de charge groupé limite l'évolutivité de votre cluster. Par exemple, le nombre de nœuds de votre cluster et de services pouvant être configurés sur votre équilibreur de charge est limité. C'est également le cas des vérifications de l'état. Leur nombre dépend à la fois du nombre de nœuds et du nombre de services.
En effet, à partir de la version 1.3.1, le nombre de vérifications d'état dépend du nombre de nœuds et de services locaux de trafic. Un service local de trafic est un service dont externalTrafficPolicy est défini sur "Local".
| Version 1.3.0 | Version 1.3.1 et ultérieure | |
|---|---|---|
| Nombre maximal de services (S) | 100 | 500 |
| Nombre maximal de nœuds (N) | 100 | 100 |
| Nombre maximal de vérifications d'état | S * N <= 10 000 | N + L * N <= 10 000, où L représente le nombre de services locaux de trafic |
Exemple : Dans la version 1.3.1, supposons que vous ayez 100 nœuds et 99 services locaux de trafic. Dans ce cas, le nombre de vérifications d'état est de 100 + 99 * 100 = 10 000, ce qui correspond à la limite de 10 000.
Mettre à niveau l'équilibreur de charge d'un cluster
Lorsque vous mettez à niveau un cluster, l'équilibreur de charge est automatiquement mis à niveau. Vous n'avez pas besoin d'exécuter une commande distincte pour mettre à niveau l'équilibreur de charge. Si votre équilibreur de charge est en mode haute disponibilité, GKE sur VMware recrée les VM de l'équilibreur de charge de manière progressive. Pour éviter toute interruption de service lors d'une mise à niveau, le cluster lance un basculement avant de créer la VM.
Si vous le souhaitez, vous pouvez mettre à jour les processeurs ou la mémoire de vos VM Seesaw sans effectuer de mise à niveau complète. Commencez par modifier les valeurs cpus et memoryMB dans le fichier de configuration du cluster. Exemple :
apiVersion: v1
bundlePath:
loadBalancer:
kind: Seesaw
seesaw:
cpus: 3
memoryMB: 3072
Pour mettre à jour l'équilibreur de charge d'un cluster d'administrateur, procédez comme suit :
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG --admin-cluster
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
Afficher les journaux Seesaw
L'équilibreur de charge groupé Seesaw stocke les fichiers journaux sur les VM Seesaw dans /var/log/seesaw/. Le fichier journal le plus important est seesaw_engine.INFO.
À partir de la version 1.6, si Stackdriver est activé, les journaux sont également importés dans le cloud. Vous pouvez les consulter sous la ressource "anthos_l4lb". Pour désactiver l'importation des journaux, vous pouvez vous connecter en SSH à la VM et exécuter la commande suivante :
sudo systemctl disable --now docker.fluent-bit.service
Afficher les informations sur vos VM Seesaw
Vous pouvez obtenir des informations sur les VM Seesaw d'un cluster à partir de la ressource personnalisée SeesawGroup.
Affichez la ressource personnalisée SeesawGroup d'un cluster :
kubectl --kubeconfig CLUSTER_KUBECONFIG get seesawgroups -n kube-system -o yaml
Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster.
Le résultat comporte un champ isReady qui indique si les VM sont prêtes à gérer le trafic. Le résultat affiche également les noms et les adresses IP des VM Seesaw, et la VM principale :
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
Afficher les métriques Seesaw
L'équilibreur de charge groupé Seesaw fournit les métriques suivantes :
- Débit par objet Service ou nœud
- Débit de paquets par objet Service ou nœud
- Connexions actives par objet Service ou nœud
- Utilisation du processeur et de la mémoire
- Nombre de pods backend sains par service
- Quelle VM est la VM principale et quelle VM est la sauvegarde
- Disponibilité
À partir de la version 1.6, ces métriques sont importées dans Cloud avec Stackdriver. Vous pouvez les consulter sous la ressource de surveillance "anthos_l4lb".
Vous pouvez également utiliser toutes les solutions de surveillance et de tableau de bord de votre choix, à condition qu'elles soient compatibles avec le format Prometheus.
Supprimer un équilibreur de charge
Si vous supprimez un cluster qui utilise un équilibrage de charge groupé, vous devez supprimer les VM Seesaw de ce cluster. Pour ce faire, supprimez les VM Seesaw dans l'interface utilisateur vSphere.
Vous pouvez également exécuter gkectl delete loadbalancer.
Pour un cluster d'administrateur :
gkectl delete loadbalancer --config ADMIN_CLUSTER_CONFIG --seesaw-group-file GROUP_FILE
Pour un cluster d'utilisateur :
gkectl delete loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
--seesaw-group-file GROUP_FILERemplacez les éléments suivants :
ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig du cluster d'administrateur
GROUP_FILE : chemin du fichier de groupe Seesaw. Le nom du fichier de groupe se présente sous la forme suivante :
seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.
Par exemple :seesaw-for-gke-admin-12345.yaml.
Configurer des règles de pare-feu distribuées sans état NSX-T pour une utilisation avec l'équilibreur de charge Seesaw
Si votre configuration utilise le pare-feu distribué NSX-T avec état et que vous souhaitez également utiliser l'équilibreur de charge Seesaw, plusieurs options s'offrent à vous. Choisissez celle qui convient le mieux à votre environnement.
Checklist de configuration NSX
Avant de mettre en œuvre l'une des options correctives décrites, vérifiez que vous disposez de la configuration NSX DFW suivante :
Les sections NSX DFW avec état correspondent à la configuration par défaut. Il s'agit probablement de ce dont vous disposez dans votre environnement. Consultez la section Sections de règles de pare-feu et règles de pare-feu.
L'insertion de services est parfois utilisée avec le NSX DFW pour assurer le chaînage de services et l'inspection L7 lors de l'intégration du partenaire. Les règles d'insertion de services sont également avec état par défaut. Pour confirmer que cette intégration est activée dans votre environnement, consultez les informations suivantes.
Option 1 : Créer une règle de pare-feu distribuée sans état pour les équilibreurs de charge Seesaw
Avec cette option, vous pouvez maintenir le pare-feu distribué activé dans l'environnement tout en mappant l'infrastructure Anthos, en particulier les équilibreurs de charge Seesaw, avec une règle sans état. Veillez à prendre en compte les différences entre les pare-feu sans état et avec état, afin de vous assurer de choisir le type le mieux adapté à votre environnement. Consultez la section Ajouter une section de règle de pare-feu en mode gestionnaire – Étape 6 dans la documentation de VMware.
Pour créer une stratégie de pare-feu sans état, procédez comme suit :
Accédez à Inventaire > Tags. Créez un tag nommé
seesaw.Accédez à Inventaire > Groupes. Créez un groupe nommé
Seesaw.Configurez les membres de l'ensemble Seesaw.
- Cliquez sur Définir les membres. Configurez les membres de l'ensemble en définissant les critères d'appartenance en fonction du tag
seesawque vous avez créé. Bien que l'utilisation de tags NSX soit généralement considérée comme une bonne pratique par VMware, cette méthodologie nécessite l'automatisation de leur configuration chaque fois que l'environnement est modifié, par exemple lorsque vous mettez à niveau ou redimensionnez les clusters Anthos dans votre environnement. Dans ce cas, une règle basée sur d'autres critères d'appartenance peut mieux fonctionner. Vous pouvez utiliser d'autres options d'appartenance dynamiques, telles que les noms de VM (y compris les expressions régulières), les segments et les ports de segment. Pour plus d'informations sur les critères d'appartenance à un groupe, consultez la section Ajouter un groupe.
- Cliquez sur Définir les membres. Configurez les membres de l'ensemble en définissant les critères d'appartenance en fonction du tag
Accédez à Sécurité > Pare-feu distribué. Créez une section appelée
Anthos.Cliquez sur l'icône en forme de roue dentée en haut à droite, puis définissez le bouton Avec état sur Non.
Ajoutez des règles à la section. Il est recommandé d'ajouter au moins deux règles symétriques, par exemple :
Source: Seesaw Group, Destination: Any, Applied to: Seesaw Group Source: Any, Destination: Seesaw Group, Applied to: Seesaw Group
Publiez les modifications et validez les opérations.
La section sans état doit être placée dans la table NSX DFW afin d'être prioritaire sur les autres sections pouvant autoriser le même trafic avec état, masquant ainsi les règles sans état. Assurez-vous que la section sans état est la plus spécifique et qu'elle précède les autres règles susceptibles de créer un chevauchement.
Bien que cela ne soit pas obligatoire, vous pouvez créer un groupe incluant toutes les VM Anthos, à l'aide d'un critère d'appartenance approximatif tel que le tag d'un segment, afin que toutes les VM connectées à un réseau NSX spécifique soient incluses dans le groupe. Vous pouvez ensuite utiliser ce groupe dans votre règle sans état.
Option 2 : Ajouter les VM Seesaw à la liste d'exclusion de pare-feu distribuée
Cette option vous permet d'exclure complètement les VM de l'inspection des pare-feu distribués sans désactiver NSX DFW. Consultez la section Gérer une liste d'exclusion de pare-feu.
Accédez à Sécurité > Pare-feu distribué. Sélectionnez Actions > Liste d'exclusion.
Choisissez le groupe Seesaw ou celui qui inclut toutes les VM Anthos.
Dépannage
Obtenir une connexion SSH à une VM Seesaw
Il peut arriver que vous souhaitiez vous connecter en SSH à une VM Seesaw pour le dépannage ou le débogage.
Obtenir la clé SSH
Si vous avez déjà créé votre cluster, procédez comme suit pour obtenir la clé SSH :
Récupérez le Secret
seesaw-sshdu cluster. Obtenez la clé SSH du Secret et décodez-la en base64. Enregistrez la clé décodée dans un fichier temporaire :kubectl --kubeconfig CLUSTER_KUBECONFIG get -n kube-system secret seesaw-ssh -o \ jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-keyRemplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster.
Définissez les autorisations appropriées pour le fichier de clé :
chmod 0600 /tmp/seesaw-ssh-key
Si vous n'avez pas encore créé votre cluster, procédez comme suit pour obtenir la clé SSH :
Recherchez le fichier nommé
seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.Le fichier est appelé fichier de groupe et se trouve à côté du fichier
config.yaml.La commande
gkectl create loadbalancerimprime également l'emplacement du fichier de groupe.Dans le fichier, récupérez la valeur de
credentials.ssh.privateKeyet décodez-la en base64. Enregistrez la clé décodée dans un fichier temporaire :cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml | grep privatekey | sed 's/ privatekey: //g' \ | base64 -d > /tmp/seesaw-ssh-key
Définissez les autorisations appropriées pour le fichier de clé :
chmod 0600 /tmp/seesaw-ssh-key
Vous pouvez maintenant vous connecter en SSH à la VM Seesaw :
ssh -i /tmp/seesaw-ssh-key ubuntu@SEESAW_IP
Remplacez SEESAW_IP par l'adresse IP de la VM Seesaw.
Obtenir des instantanés
Vous pouvez capturer des instantanés pour les VM Seesaw à l'aide de la commande gkectl diagnose snapshot avec l'option --scenario.
Si vous définissez --scenario sur all ou all-with-logs, le résultat inclut des instantanés de Seesaw avec d'autres instantanés.
Si vous définissez --scenario sur seesaw, le résultat inclut uniquement les instantanés Seesaw.
Par exemple :
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
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig du cluster d'administrateur
GROUP_FILE : chemin d'accès au fichier de groupe du cluster.
Recréer la VM Seesaw à partir d'un état défectueux
Si une VM Seesaw est supprimée accidentellement, vous pouvez la recréer à l'aide de la commande gkectl upgrade loadbalancer avec les options --no-diff et --force. Cela recrée toutes les VM Seesaw de votre cluster, indépendamment de l'existence ou de l'état de fonctionnement du cluster. Si votre équilibreur de charge est en mode haute disponibilité et qu'une seule VM sur deux est supprimée, l'exécution de cette commande recrée les deux VM.
Par exemple, pour recréer l'équilibreur de charge Seesaw dans le cluster d'administrateur, exécutez la commande suivante :
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff --force
Pour recréer l'équilibreur de charge Seesaw dans le cluster d'utilisateur, exécutez la commande suivante :
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG --no-diff --force
Remplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur
Problèmes connus
Cisco ACI ne fonctionne pas avec Direct Server Return (DSR)
Seesaw s'exécute en mode DSR et, par défaut, il ne fonctionne pas dans Cisco ACI en raison de l'apprentissage IP du plan de données. Pour contourner le problème à l'aide du groupe de points de terminaison d'application, cliquez ici.
Citrix Netscaler ne fonctionne pas avec Direct Server Return (DSR)
Si vous exécutez l'équilibreur de charge Netscaler devant Seesaw, MAC-Based Forwarding (MBF) doit être désactivé. Consultez la documentation Citrix.
La mise à niveau de l'équilibreur de charge Seesaw ne fonctionne pas dans certains cas
Si vous essayez de mettre à niveau un cluster 1.8.0 ou que vous utilisez gkectl upgrade loadbalancer pour mettre à jour certains paramètres de votre équilibreur de charge Seesaw version 1.8.0, cela ne fonctionnera pas en mode DHCP ou IPAM. Attendez la résolution du problème annoncée dans une version ultérieure avant de procéder à la mise à niveau.