Tutoriel : Configurer la CNI de votre cluster

Les clusters OKS sont déployés avec une interface réseau de conteneur (Container Network Interface ou CNI) par défaut afin d’assurer la communication réseau entre les pods Kubernetes.

Par défaut, OKS installe Cilium comme CNI du cluster. Cilium est déployé en remplacement complet de kube-proxy, ce qui signifie que kube-proxy n’est pas déployé sur les worker nodes.

La plupart des composants du cluster sont gérés par OKS et ne sont pas personnalisables. Vous pouvez toutefois personnaliser la configuration CNI de votre cluster. Ainsi, vous pouvez :

  • Choisir la version de Cilium à installer.

  • Mettre à jour la configuration CNI d’un cluster existant, à condition que la transition demandée soit prise en charge.

  • Désactiver l’installation par défaut de CNI pour installer et configurer votre propre CNI.

  • Désactiver l’installation par défaut de la CNI rend le cluster inopérant jusqu’à ce que vous installiez et configuriez manuellement votre propre CNI.

  • Cette option est réservée aux utilisateurs avancés. Elle n’est pas recommandée aux utilisateurs novices, car vous devrez réparer et configurer vous-même le réseau du cluster avant que les charges de travail puissent communiquer correctement.

Comprendre la configuration de la CNI

Une interface réseau de conteneur (CNI) est un plugin réseau utilisé par Kubernetes pour assurer la connectivité réseau entre les pods et les autres composants du cluster.

Kubernetes nécessite un plugin CNI afin que :

  • Les pods puissent communiquer entre eux.

  • Les pods puissent communiquer avec les services.

  • Les politiques réseau puissent être appliquées.

  • La mise en réseau du cluster puisse fonctionner entre les worker nodes.

Cilium est installé par défaut en tant que CNI du cluster. Cilium est un plugin réseau Kubernetes qui assure la connectivité réseau, le routage des services et l’application des politiques réseau pour les charges de travail du cluster. Dans OKS, Cilium remplace également kube-proxy, ce qui signifie que le routage des services est géré directement par Cilium plutôt que par un composant kube-proxy distinct.

Versions de Cilium prises en charge

Vous pouvez choisir une version spécifique de Cilium prise en charge par OKS lors de la création d’un cluster ou lors de la mise à jour de la configuration CNI d’un cluster existant.

Lors de la mise à jour d’un cluster existant, les versions cibles disponibles dépendent de la configuration CNI actuelle. Pour en savoir plus, voir Mettre à jour la CNI d’un cluster existant > Matrice de compatibilité CNI.

Les valeurs prises en charge sont les suivantes :

  • cilium-1.16

  • cilium-1.17

  • cilium-1.18

  • cilium-1.19

OKS déploie la version de Cilium sélectionnée et continue de la gérer.

Configurer un CNI sur votre cluster

Créer un cluster avec une version spécifique de Cilium avec OKS CLI

Avant de commencer :

Pour créer un cluster avec une version spécifique de Cilium, utilisez la commande cluster create avec l’option set cni :

Exemple de requête
$ oks-cli cluster create \
    --profile NAME_OF_PROFILE \
    --cluster-name NAME_OF_CLUSTER \
    --project-name NAME_OF_PROJECT \
    --set cni=CILIUM_VERSION

Pour en savoir plus, voir Créer un cluster et Versions de Cilum prises en charge.

Installer manuellement un CNI sur un cluster

Pour installer et configurer votre propre CNI, désactivez d’abord la CNI gérée par OKS en définissant la configuration cni sur none.

Vous pouvez le faire soit :

Lorsque la configuration cni est définie sur none, OKS ne gère ni n’installe de CNI sur le cluster. Le réseau du cluster reste inopérant jusqu’à ce que vous installiez et configuriez manuellement un CNI.

Désactiver la CNI par défaut sur votre cluster

Pour désactiver la CNI par défaut lors de la création d’un cluster, définissez l’option cni sur none :

Désactiver l’installation par défaut de la CNI est une option de configuration avancée :

  • OKS n’installera pas Cilium lors de la création du cluster. Le réseau du cluster ne sera donc pas opérationnel tant que vous n’aurez pas installé et configuré manuellement votre propre CNI.

  • Les pods ne pourront pas communiquer correctement, et certains composants du cluster pourraient rester indisponibles ou présenter un état de santé défaillant.

  • Vous serez responsable de la configuration, de la mise à jour, de la mise à niveau et du dépannage de votre CNI. OKS ne gère pas les installations CNI personnalisées.
Exemple de requête
$ oks-cli cluster create \
    --profile NAME_OF_PROFILE \
    --cluster-name NAME_OF_CLUSTER \
    --project-name NAME_OF_PROJECT \
    --set cni=none

Pour en savoir plus, voir Créer un cluster.

Pour désactiver la CNI gérée par OKS sur un cluster existant, modifiez sa configuration CNI en indiquant none. Pour en savoir plus, voir Configurer une CNI sur votre cluster > Mettre à jour la CNI d’un cluster existant.

Installer Cilium manuellement sur votre cluster

Avant de commencer :

  • Installez Cilium CLI.

  • Assurez-vous que votre variable KUBECONFIG pointe vers le cluster créé avec cni=none :

    Exemple de requête
    $ export KUBECONFIG=$(oks-cli cluster kubeconfig \
  --project-name NOM_DU_PROJET \
  --cluster-name NOM_DU_CLUSTER \
  --print-path)

Une fois que la configuration cni de votre cluster est définie sur none, vous pouvez y installer manuellement une version de Cilium. Dans ce cas, vous serez responsable du déploiement, de la configuration, de la mise à jour et de la maintenance de Cilium.

  • 3DS OUTSCALE ne se chargera pas de mettre à jour, de faire évoluer ou de reconfigurer cette installation CNI à votre place.

  • Cette section fournit un exemple utilisant Cilium. Si vous souhaitez installer un autre CNI, suivez la documentation officielle du plugin réseau sélectionné et assurez-vous qu’il offre les fonctionnalités réseau requises par votre cluster.

  1. Installez la version souhaitée de Cilium :

    Exemple de requête
    $ cilium install --version CILIUM_VERSION

    Cilium détecte automatiquement que kube-proxy n’est pas installé et remplace intégralement ses fonctionnalités.

    Pour en savoir plus, voir Versions de Cilum prises en charge.

  2. Appliquez un manifeste de node pool pour créer des worker nodes pour le cluster :

    Exemple de requête
    $ kubectl apply -f NODEPOOL_MANIFEST.yaml

    • Pour en savoir plus sur la rédaction d’un manifeste de node pool, voir Référence des manifestes de node pool.

    • Les pods Cilium restent à l’état Pending jusqu’à ce que des worker nodes soient disponibles dans le cluster.

  3. Vérifiez que les worker nodes sont à l’état Ready :

    Exemple de requête
    $ kubectl get nodes

  4. Vérifiez que Cilium fonctionne correctement :

    Exemple de requête
    $ cilium status

    Cilium est correctement installé lorsque les composants Cilium, Operator et Envoy DaemonSet sont à l’état OK.

  5. Vérifiez la connectivité réseau :

    Exemple de requête
    $ cilium connectivity test

Mettre à jour la CNI d’un cluster existant

Vous pouvez mettre à jour la configuration CNI d’un cluster existant. La configuration cible prise en charge dépend de la configuration CNI actuellement utilisée par le cluster.

Matrice de compatibilité CNI

Avant de mettre à jour la configuration CNI, vérifiez que la migration de votre version actuelle de CNI vers la version cible est prise en charge.

CNI actuelle Cible de CNI prise en charge

none

None

cilium

none, cilium-1.17, cilium-1.18

cilium-1.17

none, cilium, cilium-1.18

cilium-1.18

none, cilium-1.19

cilium-1.19

none

Mettre à jour la CNI d’un cluster existant avec OKS CLI

  1. Mettez à jour la configuration CNI du cluster en indiquant la version CNI souhaitée :

    Exemple de requête
    $ oks-cli cluster update \
    --cluster-name NAME_OF_CLUSTER \
    --set cni=CILIUM_VERSION

    Cette commande contient les options suivantes que vous devez spécifier :

    • cluster-name : Le nom du cluster.

    • set : L’option de configuration à mettre à jour. Définissez cni=CILIUM_VERSION, où CILIUM_VERSION correspond à la configuration CNI souhaitée, par exemple cilium-1.18. Pour en savoir plus, voir la Matrice de compatibilité CNI.

  2. Mettez à jour le cluster pour appliquer la nouvelle configuration CNI :

    Exemple de requête
    $ oks-cli cluster upgrade  \
    --cluster-name NAME_OF_CLUSTER

    La mise à jour peut prendre plusieurs minutes.

    Vous pouvez surveiller le cluster pendant la mise à niveau avec :

    $ oks-cli cluster list \
    --project-name NAME_OF_PROJECT \
    --output w

    Cette commande contient les options suivantes que vous devez spécifier :

    • NAME_OF_PROJECT : Le nom du projet contenant le cluster.

    • -w : Surveille la liste des clusters et actualise l’affichage lorsque l’état d’un cluster change.

  3. Une fois la mise à jour terminée, répertoriez les pods Cilium en cours d’exécution dans l’espace de noms kube-system :

    Exemple de requête
    $ kubectl get pods -n kube-system -l k8s-app=cilium

  4. Vérifiez la version de Cilium en cours d’exécution sur l’un des pods :

    Exemple de requête
    $ kubectl describe pod -n kube-system <CILIUM_POD> | grep Image

    Cette commande contient les options suivantes que vous devez spécifier :

    • CILIUM_POD : Le nom de l’un des pods Cilium renvoyé à l’étape précédente.

    • grep Image : Filtre la sortie de la commande afin de n’afficher que les lignes contenant Image, pour plus de clarté.

      La version de l’image correspond à la version de Cilium actuellement en cours d’exécution sur le cluster.

Vérifier votre configuration CNI avec kubectl

  1. Une fois la configuration mise en place sur votre cluster, quelle que soit la méthode utilisée, vous pouvez vérifier la configuration CNI en récupérant votre fichier kubeconfig :

    Exemple de requête
    $ export KUBECONFIG=`oks-cli cluster kubeconfig \
    --project-name NOM_DU_PROJET \
    --cluster-name NOM_DU_CLUSTER \
    --print-path`

  2. Vérifiez les ressources déployées dans le namespace kube-system :

    Exemple de requête
    $ kubectl get deployment -n kube-system

Si la CNI par défaut est installé, les ressources Cilium seront présentes dans le cluster.

Vous pouvez également vérifier son état à l’aide de la commande suivante :

Exemple de requête
$ cilium status

Pages connexes

Exporter en PDF