Ce document explique comment créer un cluster d'utilisateur qui utilise un nouveau modèle d'installation disponible en tant que fonctionnalité en preview dans la version 1.13 d'Anthos clusters on VMware (GKE On-Prem).
Qu'est-ce que kubeception ?
Le terme kubeception est utilisé pour transmettre l'idée qu'un cluster Kubernetes est utilisé pour créer et gérer d'autres clusters Kubernetes. Dans le contexte d'Anthos clusters on VMware, kubeception fait référence au cas où le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds d'un cluster d'administrateur.
À partir de la version 1.13.0, vous avez la possibilité d'exécuter le plan de contrôle d'un cluster d'utilisateur sur un ou plusieurs nœuds du cluster d'utilisateur lui-même. Dans les versions précédentes d'Anthos clusters on VMware, kubeception était la seule option. Autrement dit, tous les clusters d'utilisateur disposent de leurs plans de contrôle dans le cluster d'administrateur.
Le nouveau modèle d'installation offre une cohérence architecturale entre les clusters d'administrateur et d'utilisateur, et dissocie le cluster d'utilisateur du cluster d'administrateur. C'est un avantage pour des scénarios tels que l'exécution de clusters sur différents sites géographiques.
Avant de commencer
Vous devez disposer d'un cluster d'administrateur dont la version doit être 1.13.0 ou ultérieure.
Planifier vos adresses IP
Lorsque vous planifiez les adresses IP de votre cluster d'utilisateur, tenez compte des exigences suivantes pour le nouveau modèle d'installation :
Les nœuds du plan de contrôle pour votre cluster d'utilisateur doivent obtenir leurs adresses IP à partir d'une liste d'adresses statiques que vous fournissez. C'est le cas même si vos nœuds de calcul obtiennent leurs adresses à partir d'un serveur DHCP. Vous avez besoin de trois nœuds de plan de contrôle pour un cluster d'utilisateur haute disponibilité, mais d'un seul nœud de plan de contrôle pour un cluster d'utilisateur standard.
Le ou les nœuds du plan de contrôle du cluster d'utilisateur doivent se trouver dans le même VLAN que les nœuds du nœud de calcul du cluster d'utilisateur. Cette démarche diffère du modèle kubeception.
L'adresse IP virtuelle du plan de contrôle du cluster d'utilisateur doit se trouver dans le même VLAN que les nœuds de calcul du cluster et les nœuds du plan de contrôle du cluster. Cette démarche diffère du modèle kubeception.
Planifier votre environnement vSphere
Le fichier de configuration du cluster d'administrateur et le fichier de configuration du cluster d'utilisateur disposent tous deux d'une section vCenter dans laquelle vous pouvez spécifier les ressources vSphere que le cluster d'administrateur ou d'utilisateur utilisera.
Pour un cluster d'utilisateur, vous n'avez pas besoin de remplir la section vCenter. En effet, un cluster d'utilisateur utilise par défaut les mêmes ressources vSphere que le cluster d'administrateur.
Toutefois, si vous souhaitez que votre cluster d'utilisateur utilise des ressources vSphere différentes de celles que vous avez spécifiées pour le cluster d'administrateur, vous pouvez renseigner les champs de votre choix dans la section vCenter du fichier de configuration du cluster d'utilisateur. Pour plus d'informations, consultez la section Configurer la hiérarchie d'objets vSphere.
Dans le nouveau modèle d'installation, les nœuds du plan de contrôle pour le cluster d'utilisateur se trouvent dans le cluster d'utilisateur lui-même. Ainsi, les nœuds du plan de contrôle utilisent les ressources vSphere spécifiées dans le fichier de configuration du cluster d'utilisateur. Par exemple, supposons que vous spécifiez datacenter-1 pour votre cluster d'administrateur et datacenter-2 pour votre cluster d'utilisateur. Les nœuds du plan de contrôle pour votre cluster d'utilisateur se trouveront dans datacenter-2.
Groupes d'anti-affinité
Le fichier de configuration du cluster d'administrateur et le fichier de configuration du cluster d'utilisateur disposent tous deux d'un champ antiAffinityGroups.enabled que vous pouvez définir sur true ou false.
Dans le nouveau modèle d'installation, les nœuds du plan de contrôle pour le cluster d'utilisateur sont distribués en fonction de la valeur antiAffinityGroups.enabled dans le fichier de configuration du cluster d'utilisateur.
En revanche, avec le modèle kubeception, les nœuds du plan de contrôle du cluster d'utilisateur sont distribués en fonction de la valeur antiAffinityGroups.enabled dans le fichier de configuration du cluster d'administrateur.
Exemple
Voici un exemple de cluster d'utilisateur présentant les caractéristiques suivantes :
Il y a trois nœuds de calcul.
Les nœuds de calcul ont des adresses IP statiques.
Il y a trois nœuds de plan de contrôle. Il s'agit d'un cluster haute disponibilité.
L'équilibreur de charge est MetalLB.
Le cluster d'utilisateur utilise les mêmes ressources vSphere que le cluster d'administrateur.
Le schéma suivant illustre le réseau des clusters d'administrateur et d'utilisateur :
Voici un exemple de fichier de bloc d'adresses IP et de partie d'un fichier de configuration de cluster d'utilisateur.
user-ipblock.yaml
blocks:
- netmask: 255.255.255.0
gateway: 172.16.21.1
ips:
- ip: 172.16.21.2
hostname: worker-vm-1
- ip: 172.16.21.3
hostname: worker-vm-2
- ip: 172.16.21.4
hostname: worker-vm-3
- ip: 172.16.21.5
hostname: worker-vm-4
user-cluster.yaml
apiVersion: v1
kind: UserCluster
...
kubeception: false
network:
hostConfig:
dnsServers:
- "203.0.113.2"
- "198.51.100.2"
ntpServers:
- "216.239.35.4"
ipMode:
type: "static"
ipBlockFilePath: "user-ipblock.yaml"
controlPlaneIPBlock:
netmask: "255.255.255.0"
gateway: "172.16.21.1"
ips:
- ip: "172.16.21.6"
hostname: "cp-vm-1"
- ip: "172.16.21.7"
hostname: "cp-vm-2"
- ip: "172.16.21.8"
hostname: "cp-vm-3"
loadBalancer:
vips:
controlPlaneVIP: "172.16.21.40"
ingressVIP: "172.16.21.30"
kind: MetalLB
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.21.30-172.16.21.39"
...
masterNode:
cpus: 4
memoryMB: 8192
replicas: 3
nodePools:
- name: "worker-node-pool"
enableLoadBalancer: true
Voici les points importants à comprendre dans l'exemple précédent :
Les adresses IP statiques des nœuds de calcul sont spécifiées dans un fichier de bloc d'adresses IP. Le fichier de blocs d'adresses IP comporte quatre adresses, même s'il n'y a que trois nœuds de calcul. L'adresse IP supplémentaire est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster.
Les adresses IP statiques des trois nœuds de plan de contrôle sont spécifiées dans la section
network.controlPlaneIPBlockdu fichier de configuration du cluster d'utilisateur. Aucune adresse IP supplémentaire n'est nécessaire dans ce bloc.Le champ
masterNode.replicasest défini sur3.L'adresse IP virtuelle du plan de contrôle et l'adresse IP virtuelle d'entrée se trouvent dans le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle.
Les adresses IP virtuelles réservées pour les services de type LoadBalancer sont spécifiées dans la section
loadBalancer.metalLB.addressPoolsdu fichier de configuration du cluster d'utilisateur. Ces adresses IP virtuelles se trouvent sur le même VLAN que les nœuds de calcul et les nœuds du plan de contrôle.Le fichier de configuration du cluster d'utilisateur n'inclut pas de section
vCenter. Le cluster d'utilisateur utilise donc les mêmes ressources vSphere que le cluster d'administrateur.
Créer des règles de pare-feu
Outre les règles de pare-feu standards, créez les règles de pare-feu suivantes selon vos besoins :
De |
Port source |
Vers |
Port dst |
Protocole |
Description |
|---|---|---|---|---|---|
|
Nœuds du cluster d'administrateur |
Tout |
Adresse IP virtuelle du plan de contrôle du cluster d'utilisateur |
443 |
https |
Autorisez les nœuds et les pods du cluster d'administrateur à communiquer avec le serveur d'API Kubernetes du cluster d'utilisateur. |
|
Nœuds du cluster d'administrateur |
Tout |
Nœuds du plan de contrôle du cluster d'utilisateur |
443 |
https |
Autorisez les nœuds et les pods du cluster d'administrateur à communiquer avec le serveur d'API Kubernetes du cluster d'utilisateur en utilisant l'adresse IP d'un nœud de plan de contrôle du cluster d'utilisateur. |
|
Nœuds du cluster d'administrateur |
Tout |
Serveur vCenter du cluster d'utilisateur |
443 |
https |
Autorisez le cluster d'administrateur à gérer le cycle de vie du cluster d'utilisateur. Obligatoire si vous avez spécifié pour vCenter.address une valeur différente de l'adresse vCenter du fichier de configuration de votre cluster d'administrateur. |
|
Nœuds du plan de contrôle du cluster d'utilisateur |
1024 - 65535 |
Registre Docker local sur site |
Dépend de votre registre |
TCP/https |
Obligatoire si vous avez spécifié un registre privé dans le fichier de configuration de votre cluster d'administrateur. |
Créer un cluster d'utilisateur à l'aide du nouveau modèle
Cette section explique comment créer un cluster d'utilisateur utilisant le nouveau modèle d'installation. Dans cet exemple, le cluster d'utilisateur utilise la même instance de vCenter Server que le cluster d'administrateur.
Suivez les instructions de la page Créer un cluster d'utilisateur.
Lorsque vous remplissez le fichier de configuration de votre cluster d'utilisateur :
Définissez
kubeceptionsurfalse.Ne spécifiez pas de valeur pour
vCenter.address.Remplissez la section
network.controlPlaneIPBlock. Si vous souhaitez un cluster d'utilisateur haute disponibilité, spécifiez trois adresses IP. Sinon, spécifiez une seule adresse IP.
Lorsque votre cluster d'utilisateur est en cours d'exécution, vérifiez que le plan de contrôle fonctionne sur un ou trois nœuds du cluster d'utilisateur :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Le résultat affiche un ou trois nœuds de plan de contrôle avec les nœuds de calcul. Exemple :
cp-vm-1 Ready control-plane,master 18m cp-vm-2 Ready control-plane,master 18m cp-vm-3 Ready control-plane,master 18m worker-vm-1 Ready 6m7s worker-vm-2 Ready 6m6s worker-vm-3 Ready 6m14s
Vérifiez que le plan de contrôle du cluster d'utilisateur n'est pas en cours d'exécution dans le cluster d'administrateur :
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Le résultat affiche un nœud de plan de contrôle pour le cluster d'administrateur, mais n'affiche aucun nœud de plan de contrôle pour le cluster d'utilisateur. Exemple :
admin-vm-1 Ready control-plane,master 82m admin-vm-2 Ready 71m admin-vm-3 Ready 71m
Mettre à niveau un cluster d'utilisateur
Suivez les instructions de la page Mettre à niveau Anthos clusters on VMware.
Notez que lorsque vous mettez à niveau un cluster d'utilisateur à l'aide du nouveau modèle d'installation, l'ensemble du cluster d'utilisateur, y compris les nœuds du plan de contrôle d'utilisateur, est mis à niveau.
En revanche, dans le cas des clusters d'utilisateur déployés avec le modèle kubeception, les nœuds du plan de contrôle ne sont pas mis à niveau lors de la mise à niveau du cluster d'utilisateur et ne le sont pas non plus jusqu'à la mise à niveau du cluster d'administrateur.
Supprimer un cluster d'utilisateur
Pour supprimer un cluster d'utilisateur :
gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER
Remplacez USER_CLUSTER par le nom du cluster d'utilisateur.
Lorsque vous supprimez un cluster d'utilisateur qui utilise le nouveau modèle d'installation, les disques de données du cluster ne sont pas automatiquement supprimés. Vous devez donc supprimer les disques de données manuellement. Un cluster haute disponibilité comporte trois disques de données, et un cluster standard n'en a qu'un seul.
Les disques de données du cluster d'utilisateur se trouvent à l'un des emplacements suivants :
ADMIN_CLUSTER/USER_CLUSTER/
ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/
Remplacez ADMIN_CLUSTER par le nom du cluster d'administrateur.
Si vous avez spécifié un dossier dans le champ vCenter.dataDisk du fichier de configuration du cluster d'administrateur, remplacez ADMIN_DISK_FOLDER par le nom du dossier.
Pour un cluster standard, le disque de données est nommé USER_CLUSTER-0-data.vmdk.
Pour un cluster haute disponibilité, les disques de données sont nommés :
- USER_CLUSTER-0-data.vmdk.
- USER_CLUSTER-1-data.vmdk.
- USER_CLUSTER-2-data.vmdk.
Vous pouvez utiliser le client vSphere pour supprimer les disques de données.
Créer un cluster d'utilisateur avec son propre serveur vCenter
Dans certains cas, il est judicieux de créer un cluster d'utilisateur qui utilise sa propre instance de vCenter Server. Autrement dit, le cluster d'administrateur et un cluster d'utilisateur associé utilisent des instances différentes de vCenter Server.
Par exemple, dans un emplacement périphérique, vous pouvez avoir une machine physique exécutant vCenter Server et une ou plusieurs machines physiques exécutant ESXi. Vous pouvez ensuite utiliser votre instance locale de vCenter Server pour créer une hiérarchie d'objets vSphere, y compris des centres de données, des clusters, des pools de ressources, des datastores et des dossiers.
Suivez les instructions de la section Créer un cluster d'utilisateur à l'aide du nouveau modèle.
Outre les étapes décrites dans cette section, remplissez l'intégralité de la section vCenter du fichier de configuration de votre cluster d'utilisateur. En particulier, spécifiez pour vCenter.address une valeur différente de l'adresse du serveur vCenter spécifiée dans le fichier de configuration du cluster d'administrateur.
Exemple
vCenter:
address: "vc-edge.example"
datacenter: "vc-edge"
cluster: "vc-edge-workloads"
resourcePool: "vc-edge-pool
datastore: "vc-edge-datastore
caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
credentials:
fileRef:
path: "credential.yaml"
entry: "vCenter-edge"
folder: "edge-vm-folder"
Dépannage
Consultez la section Dépanner la création et la mise à niveau du cluster.