Guide: migration de cluster K8S Rancher

Article écrit par Nicolas Desombre

Lorsque que l’on gère de multiples clusters Kubernetes, Rancher devient vite un outil de choix pour centraliser l’accès, l’administration ainsi que le provisionnement de nos clusters.

Le provisionnement des clusters via Rancher à un côté bien pratique, celui de pouvoir déployer via un provider Terraform unique, des clusters utilisant différentes distributions Kubernetes ainsi que différent hyperviseur/cloud public.

Mais voilà, il entraîne une limitation qui finit par poser problème, il n’est pas possible de dé-enregistrer de l’instance Rancher des clusters ainsi provisionnés sans les détruire.

Cette limitation n’est pas présente pour les clusters importés, pour lequel une procédure de Rancher est disponible.

Attention : cet article ne constitue pas une procédure officielle, mais plutôt un partage d’expérience, je vous invite vivement à vérifier vos backups avant de faire quoique ce soit. Et je ne peux d’ailleurs, à ce sujet, que vous conseiller l’excellent Velero sur lequel nous reviendrons sans doute en détail à l’occasion d’un prochain article.

État des lieux

Notre histoire est je pense assez banale, une instance Rancher ancienne reposant sur un cluster RKE, que nous souhaitons dé-provisionner depuis déjà un certain temps.

Nous avons jusque-là réussi à retirer progressivement les clusters y étant rattaché au gré des décommissionnements, mais il y reste 2 clusters Azure AKS dit “Rancher-Owned” (provisionné via Rancher) pour lequel aucune décommission n’est prévue dans un futur proche.

S’agissant d’environnements de production sensibles et anciens, nous souhaitions éviter au maximum une reconstruction de la plateforme.

Mode opératoire utilisé

Comme évoqué ci-dessus, nos clusters sont ici de type Azure AKS. Mais cette procédure devrait être applicable sans aucun souci pour les autres types de cluster, dès lors qu’il est possible de générer un KUBECONFIG indépendant de Rancher.

Génération d’un KUBECONFIG

La première étape est donc de générer un KUBECONFIG local, qui va nous permettre de reprendre le contrôle directement via l’api du cluster, sans passer par Rancher.

Pour un cluster AKS, cela passe par l’utilisation de la CLI Azure :

➜  ~ export KUBECONFIG=~/.kube/tmp-aks.yaml
➜  ~ az aks get-credentials --resource-group MyRG --name MyCluster
The behavior of this command has been altered by the following extension: aks-preview
Merged "MyCluster" as current context in /Users/nicolas/.kube/tmp-aks.yaml
➜  ~ kubectl get nodes
NAME                              STATUS   ROLES   AGE    VERSION
aks-default-12345678-vmss000000   Ready    agent   143d   v1.2x.x
aks-default-12345678-vmss000001   Ready    agent   143d   v1.2x.x
aks-default-12345678-vmss000002   Ready    agent   143d   v1.2x.x

Rancher Cleanup

Nous allons ensuite supprimer l’agent, ainsi que d’une manière générale, toutes traces de Rancher sur le cluster à l’aide de l’outil Rancher Cleanup :

➜  ~ git clone https://github.com/rancher/rancher-cleanup.git
➜  ~ kubectl create -f deploy/rancher-cleanup.yaml

Comme indiqué dans le README.md du dépôt, vous pouvez suivre l’avancement de l’opération via la commande kubectl -n kube-system logs -l job-name=cleanup-job -f

Une fois le job Completed n’oubliez pas de le supprimer via la commande kubectl delete -f deploy/rancher-cleanup.yaml, ceci afin d’éviter une exécution accidentelle ultérieurement.

Il n’y a désormais plus aucune trace de Rancher sur le cluster, qui est redevenu un cluster Azure AKS standard.

Suppression du cluster dans Rancher

À ce stade, dans l’UI de l’ancienne instance Rancher, vous devez être face à de nombreux messages d’erreur indiquant une impossibilité de communiquer avec le cluster.

- lastUpdateTime: "2023-11-22T07:06:04Z"
    message: 'Error while applying agent YAML, it will be retried automatically: exit
      status 1, Error from server (InternalError): an error on the server ("unable
      to create impersonator account: error getting service account token: service
      account is not ready") has prevented the request from succeeding '
    reason: Error
    status: "False"
    type: AgentDeployed
- lastUpdateTime: "2023-11-22T07:05:31Z"
    message: Cluster agent is not connected
  reason: Disconnected
  status: "False"
  type: Ready

Ce qui est parfaitement normal puisque l’agent ainsi que le compte RBAC utilisé par Rancher ont été supprimés.

Néanmoins, il n’est pas encore possible de supprimer le cluster via l’UI, Rancher souhaitera toujours le détruire dans ce cas de figure.

Pour éviter cela, nous allons donc devoir éditer la configuration du cluster dans Rancher. Celle-ci étant stockée sous forme d’objet Kubernetes, nous allons donc simplement utiliser kubectl sur le cluster support de l’instance.

Il faut tout d’abord récupérer l’id du cluster, celui-ci est visible dans l’url https://rancher.mydomain.com/dashboard/c/c-12345/explorer#cluster-events, ici c-12345.

Ensuite, nous allons supprimer les finalizers chargé du dé-provisionnement complet du cluster en cas de suppression de celui-ci :

➜  rancher-cleanup git:(main) kubectl get clusters.management.cattle.io
NAME      AGE
c-12345   525d
local     609d
➜  rancher-cleanup git:(main) kubectl patch clusters.management.cattle.io c-12345 -p '{"metadata":{"finalizers":null}}' --type=merge
cluster.management.cattle.io/c-flhkm patched

Il ne reste plus qu’à revenir dans l’UI, puis à se rendre dans Cluster Management et Delete.

Réintégration dans le Rancher de destination

À ce stade, on peut suivre la procédure habituelle d’import d’un cluster AKS dans Rancher.

Avec Terraform, l’on peut reprendre son code existant et y ajouter le switch ìmported = true, attention néanmoins aux drifts éventuels.

resource "rancher2_cluster" "my-aks-to-import" {
  name        = "my-aks-to-import"
  description = "Terraform AKS Cluster"
  aks_config_v2 {
    cloud_credential_id = rancher2_cloud_credential.aks.id
    name                = var.aws_aks_name
    region              = var.aws_region
    imported            = true
  }
}

Au bout de quelques minutes, votre cluster doit désormais être disponible dans la nouvelle instance Rancher.