> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/automate-protect-and-extend/fr/integrations-et-api/kubernetes-integration.md). # Intégration Kubernetes ## Vue d’ensemble VergeOS fournit une intégration Kubernetes native via un pilote de stockage CSI et un Cloud Controller Manager (CCM). Ces composants connectent tout cluster Kubernetes exécuté sur des VM VergeOS — qu’il soit provisionné via [Rancher](/automate-protect-and-extend/fr/integrations-et-api/rancher-integration.md), kubeadm ou toute autre méthode — à la plateforme VergeOS sous-jacente. | Composant | Objectif | | ----------------------------------------------------- | --------------------------------------------------------------------------- | | [Pilote CSI](#csi-driver) | Stockage persistant pour les pods Kubernetes via VergeOS vSAN | | [Cloud Controller Manager](#cloud-controller-manager) | Gestion du cycle de vie des nœuds et intégration de l’équilibreur de charge | ### Prérequis * Un cluster Kubernetes exécuté sur des VM VergeOS (RKE2, K3s, kubeadm, etc.) * Une clé API VergeOS (générée dans les paramètres utilisateur) * `kubectl` et `helm` Outils CLI * Accès au kubeconfig du cluster {% hint style="info" %} **Certificats auto-signés** Si l'environnement VergeOS utilise un certificat auto-signé, définissez `vergeos.verifySSL=false` lors de l’installation du pilote CSI et des charts Helm CCM. C’est la valeur par défaut, mais cela vaut la peine de le noter si nous la modifions plus tard. {% endhint %} *** ## Pilote CSI Le pilote Container Storage Interface (CSI) permet aux pods Kubernetes de demander et de monter du stockage VergeOS en tant que volumes persistants. Il délègue directement les opérations de stockage à l’API VergeOS, en utilisant le vSAN pour ce pour quoi il a été conçu — déduplication, placement multi-niveaux et redondance distribuée. ### Backends de stockage Le pilote CSI prend en charge deux backends, servis tous deux par un seul binaire Go : | Backend | Mode d’accès | Description | | -------- | ------------- | ------------------------------------------------------------- | | **NAS** | ReadWriteMany | Volumes EXT4 sur les services NAS VergeOS, exposés via NFS | | **Bloc** | ReadWriteOnce | Disques de VM branchés à chaud sur des VM VergeOS via le vSAN | {% hint style="info" %} **Pourquoi pas Longhorn ?** Longhorn exécute son propre moteur de stockage répliqué *dans* Kubernetes, en superposant la réplication, les instantanés et la planification au-dessus de l’hyperviseur. Sur VergeOS, le pilote CSI natif est plus adapté : * **Pas de double réplication** — l’architecture de miroir distribué du vSAN fournit déjà la redondance des données * **Déduplication en ligne** — la déduplication du vSAN est globale sur tout le cluster ; les volumes Longhorn sont des blobs opaques qui ne peuvent pas y participer * **Placement multi-niveaux** — les volumes sont placés sur le bon niveau de vSAN (NVMe, SSD, HDD) en fonction de la StorageClass * **Gestion unifiée** — les volumes apparaissent dans l’interface VergeOS aux côtés des VM, des instantanés et des partages NAS {% endhint %} ### VM de pool de stockage bloc Pour le stockage bloc, créez dans VergeOS une VM vide nommée `k8spool`. Elle n’a jamais besoin de démarrer — elle ne fait que stocker des disques blocs inactifs. L’ID de la VM est transmis au chart Helm pendant l’installation. ### Installation Le pilote CSI est distribué sous forme de chart Helm depuis le dépôt `verge-io` Helm et peut être installé via l’interface CLI Helm ou via **l’interface Rancher Apps** sur les clusters en aval. Voir [Documentation et ressources](#documentation-and-resources) ci-dessous pour les détails du chart, les valeurs Helm et les options de configuration. {% hint style="warning" %} **Cluster en aval** Lors de l’installation via l’interface Rancher Apps, le dépôt Helm doit être ajouté sur le **cluster en aval**, et non sur le cluster de gestion Rancher. Les ClusterRepos ne se propagent pas depuis le cluster de gestion. {% endhint %} *** ## Cloud Controller Manager Le Cloud Controller Manager (CCM) est l’interface standard du fournisseur cloud Kubernetes pour VergeOS. Il gère la gestion du cycle de vie des nœuds et le provisionnement des équilibreurs de charge. ### Fonctionnalités * **Gestion des nœuds** — Renseigne les métadonnées des nœuds Kubernetes (ID du fournisseur, type d’instance, IP internes) à partir des VM VergeOS. Détecte l’existence de la VM et son état d’alimentation pour la gestion du cycle de vie des nœuds. * **Équilibrage de charge** — Provisionne les règles NAT/de traduction VergeOS VNet pour `type : LoadBalancer` les services. Alloue automatiquement des IP depuis un pool configurable et mappe les ports de service vers les ports de nœud. ### Comment fonctionne le cycle de vie des nœuds Le CCM implémente l’interface Kubernetes `InstancesV2` : 1. **InstanceMetadata** — Résout un nœud Kubernetes en une VM VergeOS (par ID de fournisseur ou par nom), puis renvoie l’ID du fournisseur (`vergeos://`), le type d’instance (`cpu-mb`), et les adresses IP internes des NIC de la VM 2. **InstanceExists** — Vérifie si la VM sous-jacente existe toujours dans VergeOS 3. **InstanceShutdown** — Indique si la VM est arrêtée ### Comment fonctionne l’équilibrage de charge Le CCM implémente l’interface Kubernetes `LoadBalancer` à l’aide de l’interface utilisant les règles VergeOS VNet : 1. **EnsureLoadBalancer** — Alloue une IP depuis le pool, puis crée une règle NAT VNet par port de service. Les règles traduisent `:` à `:`. Appelle `ApplyRules` pour activer. 2. **UpdateLoadBalancer** — Met à jour les IP cibles sur les règles existantes lorsque les nœuds changent 3. **EnsureLoadBalancerDeleted** — Supprime toutes les règles VNet du service et applique la modification ### Installation Le CCM est distribué sous forme de chart Helm, en complément du pilote CSI. Installez-le via l’interface CLI Helm ou via l’interface Rancher Apps sur le cluster en aval. Voir [Documentation et ressources](#documentation-and-resources) ci-dessous pour les détails du chart et les options de configuration. *** ## Cluster Autoscaler Le Kubernetes Cluster Autoscaler fonctionne avec les clusters basés sur VergeOS provisionnés via [Rancher](/automate-protect-and-extend/fr/integrations-et-api/rancher-integration.md). Il ajuste automatiquement le nombre de nœuds dans un pool en fonction des demandes de ressources des pods en attente — en augmentant l’échelle lorsque les pods ne peuvent pas être planifiés et en la réduisant lorsque les nœuds sont sous-utilisés. Voir [Documentation et ressources](#documentation-and-resources) ci-dessous pour le lien vers le projet amont. ### Comment ça fonctionne L’autoscaler utilise l’API de Rancher pour gérer les pools de nœuds : 1. **Montée en charge** — Lorsque des pods sont en attente en raison de ressources insuffisantes, l’autoscaler augmente la taille du pool de nœuds. Rancher utilise ensuite le pilote Docker Machine pour provisionner de nouvelles VM VergeOS. 2. **Réduction de l’échelle** — Lorsque les nœuds sont sous-utilisés pendant une période configurable, l’autoscaler les cordonne, les vide et les supprime. Le pilote supprime les VM VergeOS sous-jacentes. {% hint style="success" %} **Demandes de ressources** L’autoscaler prend ses décisions de mise à l’échelle en fonction des demandes de ressources des pods, et non de l’utilisation réelle. Veillez à ce que les workloads définissent `des requests` dans leurs spécifications de pod pour un comportement de mise à l’échelle précis. {% endhint %} *** ## Résumé VergeOS fournit trois composants Kubernetes qui fonctionnent ensemble avec tout cluster exécuté sur des VM VergeOS : * **Pilote CSI** — volumes persistants via VergeOS NAS (ReadWriteMany) et stockage bloc vSAN (ReadWriteOnce) * **Cloud Controller Manager** — gestion du cycle de vie des nœuds et `LoadBalancer` Services pris en charge par les règles VergeOS VNet * **Cluster Autoscaler** — mise à l’échelle automatique des pools de nœuds pour les clusters provisionnés par Rancher Tous les composants sont distribués sous forme de charts Helm depuis le dépôt `verge-io` et peuvent être installés via l’interface CLI Helm ou l’interface Rancher Apps. ## Étapes suivantes * Nouveau sur Rancher sur VergeOS ? Consultez le guide [Intégration Rancher](/automate-protect-and-extend/fr/integrations-et-api/rancher-integration.md) pour le provisionnement des clusters, la préparation des VM de modèle et la configuration du pilote de nœud. * Vous avez déjà un cluster en cours d’exécution ? Ajoutez le dépôt Helm et explorez les charts disponibles : ```bash helm repo add verge-io https://verge-io.github.io/helm-charts helm repo update helm search repo verge-io ``` * Consultez les dépôts de projet ci-dessous pour les valeurs des charts, la référence de configuration et les notes de version. ## Documentation et ressources | Dépôt | Description | | -------------------------------------------------------------------------------------------------------- | ---------------------------------- | | [csi-vergeos](https://github.com/verge-io/csi-vergeos) | Pilote Container Storage Interface | | [vergeos-cloud-controller-manager](https://github.com/verge-io/vergeos-cloud-controller-manager) | Cloud Controller Manager | | [helm-charts](https://github.com/verge-io/helm-charts) | Dépôt du chart Helm | | [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) | Autoscaler de cluster amont | ## Support Si vous rencontrez des problèmes ou avez des demandes de fonctionnalités, veuillez ouvrir une issue sur le dépôt GitHub concerné : * [Problèmes du pilote CSI](https://github.com/verge-io/csi-vergeos/issues) * [Problèmes du CCM](https://github.com/verge-io/vergeos-cloud-controller-manager/issues) * [Problèmes des charts Helm](https://github.com/verge-io/helm-charts/issues) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/automate-protect-and-extend/fr/integrations-et-api/kubernetes-integration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.