Hot migrate an ACK dedicated cluster to an ACK Pro cluster - Container Service for Kubernetes

Migrez à chaud un ACK dedicated cluster vers un ACK managed Pro cluster. Cette opération migre le cluster sans interrompre vos charges de travail.

Container Service for Kubernetes (ACK) a cessé de proposer des ACK dedicated cluster s le 21 août 2024. Pour les environnements de production, nous vous recommandons d'utiliser des ACK managed Pro cluster s. Ils offrent une fiabilité, une sécurité et une efficacité d'ordonnancement supérieures. Les ACK managed Pro cluster s disposent d'un control plane géré, d'une haute disponibilité et d'autres fonctionnalités avancées.

Prérequis

Vous disposez d'un ACK dedicated cluster (le cluster à migrer) exécutant Kubernetes version 1.18 ou ultérieure. Si vous devez mettre à niveau le cluster, consultez la rubrique Mise à niveau manuelle d'un cluster.

La version Kubernetes du cluster reste inchangée après la migration. Si vous souhaitez à la fois migrer et mettre à niveau le cluster, migrez d'abord le cluster, puis mettez à niveau la version du cluster .
Avant la migration, définissez le fuseau horaire du cluster sur sa page Basic Information. Cela garantit que le control plane du ACK managed Pro cluster résultant utilise le même fuseau horaire que le cluster d'origine, afin d'éviter des problèmes tels que des modifications inattendues des heures d'exécution des CronJob.
Créez un compartiment Object Storage Service (OSS) de classe de stockage Standard dans la même région que le cluster à migrer. Assurez-vous que la protection contre le hotlinking est désactivée pour ce compartiment, car elle peut entraîner l'échec de la migration. Pour plus d'informations, consultez les rubriques Création d'un compartiment et Protection contre le hotlinking.

Considérations

Élément	Description
Facturation	Après une migration réussie, les éléments facturables changent. Vous n'êtes plus facturé pour les nœuds maîtres supprimés. En revanche, ACK vous facture des frais de gestion de cluster. La facturation des autres ressources cloud reste inchangée. La création d'un compartiment OSS est gratuite. Vous êtes uniquement facturé pour le stockage des objets téléchargés dans le compartiment et pour le trafic généré par l'accès à ces objets. Pour plus d'informations, consultez la rubrique Présentation de la facturation.
Accès public	Si le serveur API est exposé au public via une EIP, l'adresse d'accès au cluster reste inchangée après la migration. Certains ACK dedicated clusters plus anciens utilisent une instance Server Load Balancer (SLB) publique pour accéder au serveur API. Après la migration de ces clusters vers des ACK managed Pro clusters, vous devez passer manuellement en mode EIP en associant une EIP à l'instance Classic Load Balancer (CLB) interne du serveur API. Pour plus d'informations, consultez la rubrique Contrôle de l'accès public au serveur API d'un cluster.
Configuration personnalisée des Pods	Si des configurations Pod personnalisées sont activées pour un ACK dedicated cluster, vous ne pouvez pas le migrer directement vers un ACK managed Pro cluster. Arrêtez terway-controlplane avant la migration et réactivez-le ensuite. Pour plus d'informations, consultez la rubrique Arrêt de terway-controlplane lors de la migration d'un ACK dedicated cluster. Pour savoir comment personnaliser les configurations des Pods, consultez la rubrique Configuration d'une adresse IP statique, d'un vSwitch distinct et d'un groupe de sécurité distinct pour un Pod.
Nœuds maîtres	Dans certains clusters plus anciens, Cloud Assistant Agent n'est pas installé par défaut sur les nœuds maîtres. Installez-le manuellement. Pour plus d'informations, consultez la rubrique Installation de Cloud Assistant Agent. Après la migration, l'état des nœuds maîtres passe à Not Ready.
Libération d'instances ECS	Lorsque vous supprimez les nœuds maîtres d'origine après la migration, ACK libère automatiquement uniquement les instances ECS à la demande et leurs disques de données. Libérez manuellement les instances ECS par abonnement. Pour plus d'informations, consultez la rubrique Libération d'une instance.

Étape 1 : Migration à chaud d'un ACK dedicated cluster vers un ACK managed Pro cluster

Une fois les prérequis remplis et les considérations examinées, lancez la migration. Après la migration à chaud, il est impossible de revenir en arrière, c'est-à-dire de convertir le ACK managed Pro cluster en ACK dedicated cluster.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, localisez le cluster que vous souhaitez migrer et choisissez More>Migrate to Pro dans la colonne Actions.
Dans la boîte de dialogue Migrate to Pro, effectuez la vérification préalable et l'autorisation RAM, sélectionnez le compartiment OSS que vous avez préparé pour la migration à chaud, lisez attentivement les notes, puis cliquez sur Confirm Migration.

Vérification préalable

Cliquez sur Precheck pour ouvrir la console Container Intelligence Service, puis exécutez la vérification de migration. Dans le panneau, examinez les éléments de vérification, cochez I understand and agree, puis cliquez sur Check.

Si la vérification préalable échoue, suivez les instructions affichées à l'écran pour résoudre les problèmes.
Autorisation RAM
1. Cliquez sur Go to RAM console pour accorder les autorisations requises pour la migration à chaud. Notez également le nom du compartiment OSS. Vous en aurez besoin pour modifier la stratégie à l'étape suivante.
2. Cliquez sur une stratégie dont le nom commence par k8sMasterRolePolicy. Sur la page des détails, cliquez sur l'onglet Policy Content, puis cliquez sur Modify Policy Document. Dans l'JSON Editor, ajoutez le contenu suivant au champ Statement, puis cliquez sur OK.
  
  Dans le code ci-dessous, remplacez <YOUR_BUCKET_NAME> par le nom du compartiment que vous avez préparé. Ce nom doit correspondre à celui spécifié dans la boîte de dialogue Migrate to Pro. N'incluez pas les chevrons (<>).
  , { "Action": [ "oss:PutObject", "oss:GetObject" ], "Effect": "Allow", "Resource": [ "acs:oss:*:*:<YOUR_BUCKET_NAME>/*" ] }
Une fois la migration terminée, un message s'affiche dans la boîte de dialogue Migrate to Pro. Vous pouvez alors vérifier le type de cluster et l'état de la migration vers Migrate to Pro.
- Type de cluster : Revenez à la page Clusters. Dans la colonne Cluster Type, vérifiez que le type est passé de ACK Dedicated Cluster à ACK Managed Cluster, et que la colonne Cluster Specification indique Pro.
- État des nœuds maîtres : Sur la page Clusters, cliquez sur Details dans la colonne Actions pour le cluster cible. Dans le volet de navigation de gauche, choisissez Nodes>Nodes. Sur la page Nodes, vérifiez la colonne Role/Status. L'état des nœuds maîtres d'origine passe à Unknown. Cet état indique que les nœuds maîtres sont déconnectés du cluster et ne sont plus utilisés. Vous pouvez alors les supprimer. Pour plus d'informations, consultez la rubrique Étape 2 : Suppression des nœuds maîtres d'origine.

Étape 2 : Suppression des nœuds maîtres du ACK dedicated cluster après la migration à chaud

Une fois la migration à chaud terminée, utilisez la console ou des commandes kubectl pour supprimer manuellement le nœud maître du ACK dedicated cluster.

Console

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Nodes > Nodes.
Sur la page Nodes, localisez le nœud maître que vous souhaitez supprimer et choisissez More>Remove dans la colonne Actions. Pour supprimer plusieurs nœuds maîtres, sélectionnez-les et cliquez sur Batch Remove en bas de la page. Dans la boîte de dialogue qui s'affiche, configurez les paramètres, lisez attentivement les notes, puis cliquez sur OK.

kubectl

Avant d'exécuter les commandes, connectez-vous au cluster à l'aide de kubectl. Pour plus d'informations, consultez la rubrique Obtention du kubeconfig d'un cluster et connexion au cluster avec kubectl.

Récupérez et notez les noms des nœuds maîtres à supprimer.
```
kubectl get node | grep control-plane
```
Supprimez le nœud maître cible. Remplacez <MASTER_NAME> par le nom du nœud maître obtenu à l'étape précédente.
```
kubectl delete node <MASTER_NAME>
```
Pour supprimer plusieurs nœuds maîtres simultanément, remplacez les espaces réservés <MASTER_NAME> par les noms des nœuds maîtres. Par exemple, pour supprimer les nœuds maîtres cn-hangzhou.192.xx.xx.65 et cn-hangzhou.192.xx.xx.66, exécutez la commande suivante :
```
kubectl delete node cn-hangzhou.192.xx.xx.65 cn-hangzhou.192.xx.xx.66
```

(Facultatif) Étape 3 : Gestion des modules complémentaires

Vérifiez si le contrôleur ALB Ingress ou le composant ACK Virtual Node est installé dans le ACK dedicated cluster d'origine. Si c'est le cas, réinstallez ou migrez le composant une fois la migration du cluster terminée.

Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, choisissez Operations > Add-ons.
Sur la page Add-ons, recherchez le composant ALB Ingress controller ou ACK Virtual Node. Si l'un d'eux est installé, traitez-le comme décrit dans les sections suivantes.
Réinstallation du contrôleur ALB Ingress

Si le contrôleur ALB Ingress est installé dans le ACK dedicated cluster, vous devez le réinstaller après la migration. Pour plus d'informations sur l'installation du contrôleur ALB Ingress, consultez la rubrique Gestion des modules complémentaires.

Après l'installation, exécutez la commande suivante pour supprimer l'application d'origine. Assurez-vous d'être connecté au cluster à l'aide de kubectl. Pour plus d'informations, consultez la rubrique Obtention du kubeconfig d'un cluster et connexion au cluster avec kubectl.
```
kubectl delete deployment alb-ingress-controller -n kube-system
```
Migration d'ACK Virtual Node vers la version gérée

Si le composant ACK Virtual Node est installé dans l'ACK dedicated cluster, vous devez le migrer vers la version gérée après la migration du cluster afin d'assurer une transition transparente pour vos charges de travail.
1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .
3. Sur la page Add-ons, installez le composant ACK Virtual Node.
4. Une fois le composant ACK Virtual Node installé, exécutez les commandes suivantes dans l'ordre pour supprimer les composants et configurations obsolètes.
```
# Delete the old vk-webhook Service, ack-virtual-node-controller Deployment, virtual-kubelet ClusterRoleBinding, and virtual-kubelet ServiceAccount in sequence.
kubectl -n kube-system delete service vk-webhook
kubectl -n kube-system delete deployment ack-virtual-node-controller
kubectl delete clusterrolebinding virtual-kubelet
kubectl -n kube-system delete serviceaccount virtual-kubelet
```
5. Une fois la migration terminée, créez un nouveau Pod pour tester si le cluster fonctionne comme prévu.

Étapes suivantes

Après la migration vers un ACK managed Pro cluster, restreignez manuellement les autorisations du rôle RAM worker pour améliorer la sécurité des nœuds. Pour plus d'informations, consultez la rubrique Restriction manuelle des autorisations du rôle RAM worker pour un ACK managed cluster.
Si cGPU Basic Edition est installé dans le ACK dedicated cluster, mettez-le à niveau vers cGPU Professional Edition après la migration vers un ACK managed Pro cluster. Pour plus d'informations, consultez la rubrique Mise à niveau de cGPU Basic Edition vers cGPU Professional Edition dans un ACK Pro cluster.
Dans les clusters à très grande échelle ou dans les scénarios présentant des pics de concurrence élevés, préallouez et dédiez des ressources au plan de contrôle afin de garantir des performances prévisibles. Pour plus d'informations, consultez la rubrique Plan de contrôle prédéfini ACK Pro. Le plan de contrôle ACK Pro est disponible en trois niveaux prédéfinis : Pro XL, Pro 2XL et Pro 4XL. La capacité du plan de contrôle est définie par des métriques telles que la concurrence des requêtes API (sièges), le taux d'ordonnancement des pods (pods/seconde) et la taille de la base de données etcd (Go).

FAQ

Les services d'un ACK dedicated cluster seront-ils affectés pendant la migration ?

Les composants du plan de contrôle de l'ACK dedicated cluster passent en mode veille pendant la migration, mais les charges de travail en cours d'exécution ne sont pas affectées.

Durée de la migration

Le processus de migration dure entre 10 et 15 minutes et comprend trois étapes : mise en veille du plan de contrôle, sauvegarde des données etcd et démarrage des composants gérés. Le serveur API devrait être indisponible pendant 5 à 10 minutes durant cette période.

Le chemin d'accès change-t-il ?

Non. L'adresse IP de l'instance CLB pour le serveur API reste inchangée. L'adresse du cluster ne change pas lors de l'accès au cluster via son kubeconfig.

Échec de la vérification préalable d'ACK Virtual Node

Si le composant ACK Virtual Node est installé dans l'ACK dedicated cluster, configurez manuellement le point de terminaison interne de kube-apiserver avant la migration. Pour ce faire, procédez comme suit :

Sur la page Cluster Information, obtenez le point de terminaison interne de kube-apiserver.
Sur la page Deployments, sélectionnez l'espace de noms kube-system, localisez le déploiement ack-virtual-node-controller, puis ajoutez les variables d'environnement suivantes à son champ spec.template.spec.containers[0].env :
- KUBERNETES_APISERVER_HOST : L'adresse IP privée de kube-apiserver.
- KUBERNETES_APISERVER_PORT : Le port privé de kube-apiserver, généralement 6443.

Comment récupérer après la suppression accidentelle des nœuds maîtres d'un ACK dedicated cluster ?

La méthode de récupération dépend de la version du cluster :

Version du cluster 1.20 ou ultérieure : Utilisez la console pour ajouter de nouveaux nœuds maîtres afin de restaurer le cluster.
Version du cluster antérieure à 1,20 : Suivez l'étape 1 de cette rubrique pour migrer à chaud le cluster dédié vers un ACK Pro cluster. Le système exécute automatiquement une vérification préalable avant la migration pour garantir la sécurité.