Passer au contenu principal

Connecter une VM à un cluster Kubernetes managé

À la création d'un cluster Kubernetes managé, le choix du réseau détermine l'exposition du serveur d'API : réseau Public ("visibility": "EXTERNAL") ou réseau Privé ("visibility": "INTERNAL"). Avec un réseau Privé, le serveur d'API n'est joignable que depuis le réseau interne Numspot : pour l'administrer avec kubectl depuis une VM (Virtual Machine), connectez la VM au réseau du cluster par une connexion privée.

Ce guide décrit le cheminement complet depuis une VM placée dans un VPC (Virtual Private Cloud) : création du Hybrid Bridge, mise à jour du routage, ouverture des flux, déploiement du fichier kubeconfig puis connexion avec kubectl.

Prérequis​

info

Procédure​

Étape 1 : Créer le bridge entre le VPC et l'espace​

Un bridge connecte un VPC à l'ensemble des services managés de l'espace. La gestion des Hybrid Bridges s'effectue uniquement par API : suivez la procédure Créer un Hybrid Bridge ↗.

La commande POST /connectivity/spaces/{spaceId}/bridges crée le bridge : left désigne le VPC, right désigne l'espace.

La création est asynchrone : l'API retourne un code 202 Accepted et le bridge atteint ensuite un état READY. Attendez cet état avant de poursuivre.

Étape 2 : Ajouter les routes vers les services managés​

Une fois le bridge créé, lisez sa configuration : chaque entrée du tableau routes du bridge contient l'ipRange du réseau à joindre et l'identifiant vpcPeeringId à utiliser comme cible de route.

Créez une route pour chaque entrée, dans la route table (table de routage) associée au subnet (sous-réseau) de la VM :

  • l'ipRange du bridge en destination ;
  • le vpcPeeringId du bridge en cible de type VPC peering (peering VPC).

Suivez la procédure Créer une route ↗ dans la console ou via l'API POST /compute/spaces/{spaceId}/routeTables/{id}/routes.

Étape 3 : Autoriser le flux vers le serveur d'API​

Dans le security group (groupe de sécurité) associé à la VM, ajoutez une règle sortante autorisant le flux vers l'ipRange du control plane (plan de contrôle) du cluster sur le port 443. Suivez la procédure Ajouter une règle à un security group ↗.

Le trafic est bidirectionnel : les conteneurs des worker nodes (nœuds de travail) du cluster peuvent accéder à la VM. Si la VM doit recevoir du trafic depuis le cluster, ajoutez une règle entrante dédiée avec les sources nécessaires.

Étape 4 : Déployer le kubeconfig sur la VM​

Téléchargez le fichier kubeconfig depuis la console puis transférez-le sur la VM :

scp kubeconfig-<cluster-id>.yaml outscale@<ip-vm>:~

Sur la VM, placez le fichier à l'emplacement par défaut et restreignez ses droits :

mkdir -p ~/.kube
mv kubeconfig-<cluster-id>.yaml ~/.kube/config
chmod 600 ~/.kube/config

Étape 5 : Se connecter au cluster​

Depuis la VM, vérifiez la connexion au cluster :

kubectl get nodes
avertissement

L'URL du serveur d'API dans le fichier kubeconfig doit être conservée telle quelle : elle désigne un nom de domaine complet [FQDN (Fully Qualified Domain Name)] qui transporte l'extension TLS (Transport Layer Security) [SNI (Server Name Indication)] requise par la plateforme. Remplacer cette URL par l'adresse IP du serveur d'API entraîne une réinitialisation de la connexion TLS.

Vérification​

La commande kubectl get nodes retourne les worker nodes du cluster avec le statut Ready :

NAME                         STATUS   ROLES    AGE   VERSION
nodepool-1-8f4f9cabc-12xyz   Ready    worker   10m   v1.30.4
nodepool-1-8f4f9cabc-34xyz   Ready    worker   10m   v1.30.4

Vous pouvez ensuite déployer vos charges de travail et les joindre depuis la VM par leurs adresses IP privées dans le réseau du cluster.

Dépannage​

La connexion reste en attente ou expire​

Cause : le routage ou le filtrage bloque le trafic entre la VM et le serveur d'API.

Solution : vérifiez dans l'ordre :

  1. l'état du bridge, qui doit être READY ;
  2. l'existence d'une route par entrée du tableau routes du bridge, dans la route table associée au subnet de la VM ;
  3. la règle sortante du security group de la VM, qui autorise l'ipRange du control plane vers le port 443.

La connexion TLS est réinitialisée​

Cause : l'URL du serveur d'API a été remplacée par une adresse IP — l'extension SNI n'est alors pas transmise.

Solution : conservez l'URL du fichier kubeconfig telle quelle et relancez la commande.

Le serveur d'API refuse la requête​

Cause : le fichier kubeconfig est expiré ou ne correspond plus au cluster.

Solution : téléchargez à nouveau le fichier kubeconfig depuis la console puis remplacez le fichier sur la VM.

Cette page vous a-t-elle été utile ?