-
Accueil
-
Fiches Pratiques
-
-
-
-
-
-
- NSX-T : Comment configurer une solution IPSEC [EN]
- NSX-T : configuration de DNAT [EN]
- NSX-T : configuration de SNAT [EN]
- NSX-T : Création de T1 [EN]
- NSX-T : Créer et configurer un segment overlay Geneve
- NSX-T: Configurer un Pare-Feu de Passerelle/"Gateway Firewall"
- NSX-T: Configurer un Pare-Feu Distribué
- NSX-T: Créer un VPN Ipsec
- Sauvegarde : Conception globale de l'offre VCOD [EN]
- Sauvegarde : Créer une sauvegarde VCOD [EN]
- Sauvegarde : Guide de l'utilisateur pour l'offre VCOD [EN]
- Sauvegarde : Installation de l'agent Netbackup pour Linux [EN]
- Sauvegarde : Installation de l'agent Netbackup pour Windows [EN]
- Sauvegarde : Mode Agent B&R via NSS Pour l`offre IAAS [EN]
- VCenter : Réinitialiser le mot de passe de cloudadmin [EN]
- VCenter : Snapshot de VM
- VCenter : Storage Vmotion d'une VM
- VCenter: Cloner une VM
- VCenter: Créer une nouvelle VM
- VCenter: Upgrader les Vmware tools sur une VM
- Show all articles (5) Collapse Articles
-
-
Liste des Services (NGP)
- Accès internet
- API
- Appliance de QoS
- Bare Metal Serveur
- BVPN
- Certifications
- Cluster Dédié
- Cross Connect
- DRaaS avec VCDA
- Dual Site
- HA Dual Room
- Kubernetes
- Licences
- LoadBalancer As A Service
- Option Switch : collocation mutualisée (Cross connect)
- Outillage
- Politiques de Sauvegarde
- Réplication de VM
- Réseau
- Sécurité
- Stockage Bloc
- Stockage Objet
- Stockage Réseau
- Support & Coaching
- VCenter à la demande
- VCenter à la demande
- Show all articles (11) Collapse Articles
-
-
- Articles coming soon
-
- Articles coming soon
-
-
Q&R
KaaS – Suppression du bootstrap cluster
Introduction
Afin de réduire le nombre de clusters utilisés, il est envisageable de transférer les objets Cluster API (Cluster, MachineDeployment, etc.) d’un cluster de management vers un autre.
Cela permet de déplacer les objets Cluster API qui se trouvent actuellement dans le cluster de bootstrap vers votre cluster de management .
Ainsi, vous n’aurez plus qu’un seul cluster de management qui gérera à la fois vos clusters de travail et lui-même.
Prérequis
Avant de continuer la procédure, vous devez vous assurer que :
- Le cluster de management cible soit correctement installé et fonctionnel.
- Aucune opération de scaling ou de mise à jour soit en cours.
- Les versions doivent être identiques sur le cluster source et cible, que ce soit celle de Cluster API ou du Provider CAPVCD.
- Version du provider VCD :
kubectl get pod -n capvcd-system -l cluster.x-k8s.io/provider=infrastructure-vcd -o=jsonpath='{range .items[*]}{.status.containerStatuses[0].image}{"\r\n"}{end}'
- Version du provider Cluster API :
kubectl get pod -n capi-system -l cluster.x-k8s.io/provider=cluster-api -o=jsonpath='{range .items[*]}{.status.containerStatuses[0].image}{"\r\n"}{end}'
- Version du provider VCD :
À noter !
Attention : cette méthode est uniquement faite pour se séparer du cluster de bootstrap, elle n’est en aucun cas à utiliser pour un autre usage.
Vous pouvez, en complément, vous référer à la procédure officielle de Cluster API : ICI
Cluster move
Se connecter au cluster de bootstrap.
Vous pouvez vérifier en faisant un kubectl get nodes
pour vérifier que vous êtes bien connecté au cluster de bootstrap.
Aussi, si vous faites un kubectl get cluster
vous devez voir votre cluster de management, c’est entre autres cet objet qui va être déplacé.
#kubectl get nodes
NAME STATUS ROLES AGE VERSION
mstr-3no2 Ready control-plane,master 28m v1.22.9+vmware.1
node-c4jq Ready <none> 25m v1.22.9+vmware.1
#kubectl get cluster
NAME PHASE AGE VERSION
mgt02 Provisioned 19m
Le provider CAPVCD utilise un secret (capi-user-credentials
) présent dans le namespace default qui n’est pas migré par la commande clusterctl.
Nous allons donc copier ce secret sur le cluster de destination.
Modifiez la variable DST en pointant vers le fichier kubeconfig du cluster de management de destination.
DST=/chemin/vers/kubeconfigDestination
kubectl get secret capi-user-credentials -o yaml | kubectl apply --kubeconfig=${DST} -f -
Repérez le fichier kubeconfig de connexion à votre cluster de management (cluster de destination)
puis lancer la commande :
clusterctl move --to-kubeconfig=/chemin/vers/kubeconfigCible
clusterctl move --to-kubeconfig=${DST}
Suite à cette commande, vous ne devriez plus avoir d’objet Cluster sur votre cluster de bootstrap.
En revanche,, vous devriez voir l’objet Cluster correspondant à votre cluster de management sur votre cluster de management.