diff --git a/pages/index.md b/pages/index.md index 9224437efe3..8baa2182d17 100644 --- a/pages/index.md +++ b/pages/index.md @@ -989,6 +989,7 @@ + [Add IP restrictions on an OVHcloud Managed Kubernetes cluster](public_cloud/containers_orchestration/managed_kubernetes/add-ip-restrictions) + [Changing the security update policy on an OVHcloud Managed Kubernetes cluster](public_cloud/containers_orchestration/managed_kubernetes/change-security-update) + [Configuring the OIDC provider on an OVHcloud Managed Kubernetes cluster](public_cloud/containers_orchestration/managed_kubernetes/configuring-oidc-provider-config) + + [Customising IP allocation on an OVHcloud Managed Kubernetes cluster](public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation) + [Nodepools & Nodes](public-cloud-containers-orchestration-managed-kubernetes-k8s-configuration-nodepools-and-nodes) + [How to manage nodes and node pools on an OVHcloud Managed Kubernetes cluster](public_cloud/containers_orchestration/managed_kubernetes/managing-nodes) + [Dynamically resizing a cluster with the cluster autoscaler](public_cloud/containers_orchestration/managed_kubernetes/using-cluster-autoscaler) diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.en-gb.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.en-gb.md new file mode 100644 index 00000000000..b78c6de6ee4 --- /dev/null +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.en-gb.md @@ -0,0 +1,129 @@ +--- +title: Customising IP allocation on an OVHcloud Managed Kubernetes cluster +excerpt: "Find out how to configure the IP allocation policy for your pods and services on an OVHcloud Managed Kubernetes cluster with Standard plan" +updated: 2026-03-17 +--- + +## Objective + +**This guide details how to customise the IP ranges used for the pods and services in your OVHcloud Managed Kubernetes cluster with Standard plan.** + +## Requirements + +- An [OVHcloud Managed Kubernetes](/links/public-cloud/kubernetes) cluster + +## Limits + +The customisation of the pods and services IP allocation policy is not possible on clusters with the Free plan. + +You cannot modify the IP allocation policy of a running cluster. It must be set at cluster creation or when resetting the cluster, which erases all data. + +## Configuration details + +Two parameters are available to control the IP allocation policy in your OVHcloud Managed Kubernetes cluster. + +| Parameter | Default value | Function | +| ------------------ | --------------- | ------------------------------------------------------------------ | +| `podsIpv4Cidr` | `10.240.0.0/13` | This is the subnet used to address all the pods in the cluster | +| `servicesIpv4Cidr` | `10.3.0.0/16` | This is the subnet used to address all the services in the cluster | + +> [!primary] +> +> You can find more information about the CIDR notation here: [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) +> + +Keep the following rules in mind for these parameters: + +- `podsIpv4Cidr` and `servicesIpv4Cidr` **must not** collide with each other, nor with the OpenStack subnets on the same VLAN in your project. +- The subnets **must** be chosen in the [private network blocks](https://en.wikipedia.org/wiki/List_of_reserved_IP_addresses). +- The minimal size allowed for the `podsIpv4Cidr` and the `servicesIpv4Cidr` subnets is `/16`. + +Each node in the cluster is assigned a `/24` subnet inside `podsIpv4Cidr`; choosing a `/16` limits the cluster to 256 nodes. + +> [!warning] +> +> Adding nodes past the limit of possible `/24` subnets in the `podsIpv4Cidr` could render your cluster unstable. +> + +## Instructions using the OVHcloud API + +> [!primary] +> +> You can find more information on how to use the OVHcloud API here: [First steps with the OVHcloud API](/pages/manage_and_operate/api/first-steps). +> + +### Creating a new cluster with a custom IP allocation policy + +Using the following call, you can create a new cluster: + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube POST /cloud/project/{serviceName}/kube +> + +To set a custom IP allocation policy on pods and/or services, you can use the following example: + +```json +{ + "name": "my-cluster-with-custom-ip", + "nodepool": { + "desiredNodes": 3, + "flavorName": "b3-8", + "name": "my-nodepool" + }, + "region": "GRA11", + "ipAllocationPolicy": { + "podsIpv4Cidr": "172.16.0.0/12", + "servicesIpv4Cidr": "10.100.0.0/16" + } +} +``` + +Once the cluster is created, use this call to verify the IP allocation policy: + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube GET /cloud/project/{serviceName}/kube +> + +### Resetting a cluster to change its IP allocations + +> [!warning] +> +> Resetting a cluster will delete all data and workload running on the cluster. +> + +Using the following call, you can reset a cluster and specify a custom IP allocation policy: + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube/{kubeId}/reset POST /cloud/project/{serviceName}/kube/{kubeId}/reset +> + +To set a custom IP allocation policy on pods and/or services, you can use the following example: + +```json +{ + "ipAllocationPolicy": { + "podsIpv4Cidr": "172.16.0.0/12", + "servicesIpv4Cidr": "10.100.0.0/16" + } +} +``` + +Once the cluster is reset, use this call to verify the IP allocation policy: + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube GET /cloud/project/{serviceName}/kube +> + +## Go further + +[Known limits of OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits) + +[First steps with the OVHcloud API](/pages/manage_and_operate/api/first-steps) + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. + +Join our [community of users](/links/community). diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.fr-fr.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.fr-fr.md new file mode 100644 index 00000000000..af25ffaa56f --- /dev/null +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/guide.fr-fr.md @@ -0,0 +1,129 @@ +--- +title: Personnaliser l'allocation IP sur un cluster OVHcloud Managed Kubernetes +excerpt: "Découvrez comment configurer la politique d'allocation IP pour vos pods et services sur un cluster OVHcloud Managed Kubernetes avec le plan Standard" +updated: 2026-03-17 +--- + +## Objectif + +**Ce guide détaille comment personnaliser les plages IP utilisées pour les pods et les services dans votre cluster OVHcloud Managed Kubernetes avec le plan Standard.** + +## Prérequis + +- Un cluster [OVHcloud Managed Kubernetes](/links/public-cloud/kubernetes) + +## Limites + +La personnalisation de la politique d'allocation IP des pods et services n'est pas possible sur les clusters avec le plan Free. + +Vous ne pouvez pas modifier la politique d'allocation IP d'un cluster en cours d'exécution. Elle doit être définie lors de la création du cluster ou lors de la réinitialisation du cluster, ce qui efface toutes les données. + +## Détails de la configuration + +Deux paramètres permettent de contrôler la politique d'allocation IP dans votre cluster OVHcloud Managed Kubernetes. + +| Paramètre | Valeur par défaut | Fonction | +| ------------------ | ----------------- | --------------------------------------------------------------------------- | +| `podsIpv4Cidr` | `10.240.0.0/13` | Sous-réseau pour l'adressage des pods du cluster | +| `servicesIpv4Cidr` | `10.3.0.0/16` | Sous-réseau pour l'adressage des services du cluster | + +> [!primary] +> +> Plus d'informations sur la notation CIDR : [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) +> + +Voici les règles à respecter pour ces paramètres : + +- `podsIpv4Cidr` et `servicesIpv4Cidr` **ne doivent pas** entrer en conflit l'un avec l'autre, ni avec les sous-réseaux OpenStack du même VLAN dans votre projet. +- Les sous-réseaux **doivent** être choisis dans les [blocs de réseau privé](https://en.wikipedia.org/wiki/List_of_reserved_IP_addresses). +- La taille minimale autorisée pour les sous-réseaux `podsIpv4Cidr` et `servicesIpv4Cidr` est `/16`. + +Chaque nœud du cluster se voit attribuer un sous-réseau `/24` dans le `podsIpv4Cidr` ; choisir un `/16` limite le cluster à 256 nœuds. + +> [!warning] +> +> L'ajout de nœuds au-delà de la limite des sous-réseaux `/24` possibles dans le `podsIpv4Cidr` pourrait rendre votre cluster instable. +> + +## Instructions via l'API OVHcloud + +> [!primary] +> +> Plus d'informations sur l'utilisation de l'API OVHcloud : [Premiers pas avec l'API OVHcloud](/pages/manage_and_operate/api/first-steps). +> + +### Créer un nouveau cluster avec une politique d'allocation IP personnalisée + +Utilisez l'appel suivant pour créer un nouveau cluster : + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube POST /cloud/project/{serviceName}/kube +> + +Pour définir une politique d'allocation IP personnalisée sur les pods et/ou services, utilisez l'exemple suivant : + +```json +{ + "name": "my-cluster-with-custom-ip", + "nodepool": { + "desiredNodes": 3, + "flavorName": "b3-8", + "name": "my-nodepool" + }, + "region": "GRA11", + "ipAllocationPolicy": { + "podsIpv4Cidr": "172.16.0.0/12", + "servicesIpv4Cidr": "10.100.0.0/16" + } +} +``` + +Une fois le cluster créé, utilisez cet appel pour vérifier la politique d'allocation IP : + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube GET /cloud/project/{serviceName}/kube +> + +### Réinitialiser un cluster pour modifier ses allocations IP + +> [!warning] +> +> La réinitialisation d'un cluster supprimera toutes les données et charges de travail en cours d'exécution sur le cluster. +> + +Utilisez l'appel suivant pour réinitialiser un cluster et spécifier une politique d'allocation IP personnalisée : + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube/{kubeId}/reset POST /cloud/project/{serviceName}/kube/{kubeId}/reset +> + +Pour définir une politique d'allocation IP personnalisée sur les pods et/ou services, utilisez l'exemple suivant : + +```json +{ + "ipAllocationPolicy": { + "podsIpv4Cidr": "172.16.0.0/12", + "servicesIpv4Cidr": "10.100.0.0/16" + } +} +``` + +Une fois le cluster réinitialisé, utilisez cet appel pour vérifier la politique d'allocation IP : + +> [!api] +> +> @api {v1} /cloud/project/{serviceName}/kube GET /cloud/project/{serviceName}/kube +> + +## Aller plus loin + +[Limites connues d'OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits) + +[Premiers pas avec l'API OVHcloud](/pages/manage_and_operate/api/first-steps) + +Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en œuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts Professional Services. + +Échangez avec notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/meta.yaml b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/meta.yaml new file mode 100644 index 00000000000..9acb91d636e --- /dev/null +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation/meta.yaml @@ -0,0 +1,2 @@ +id: 9a51d31f-debc-42fe-9d5d-c6ed95121d5d +full_slug: public-cloud-kubernetes-configure-pods-services-ip-allocation-policy diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.de-de.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.de-de.md index b7131b045fa..a7eca857390 100644 --- a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.de-de.md +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.de-de.md @@ -1,7 +1,7 @@ --- title: Known limits excerpt: 'Requirements and limits to respect' -updated: 2026-02-03 +updated: 2026-03-17 --- - ## Nodes, pods and etcd limits |Plan | Max nodes per cluster | Max Pods per node | Max nodes per anti-affinity group | etcd max size | @@ -34,7 +33,7 @@ updated: 2026-02-03 We have tested our OVHcloud Managed Kubernetes Service plans with a max number of nodes, while higher configurations might work and that there is no hard limits, we recommend staying under these limits for optimal stability. -Keep in mind that impact on the control plane isn't solely determined by the number of nodes. What truly defines a 'large cluster' depends on the combination of resources deployed pods, custom resources, and other objects which all contribute to control plane load. A cluster with fewer nodes but intensive resource utilization can stress the control plane more than a cluster with many nodes running minimal workloads. In such configuration it is recommended to switch to the Standard plan in order to benefit from higher and dedicated control plane resources. +Keep in mind that impact on the control plane isn't solely determined by the number of nodes. What truly defines a 'large cluster' depends on the combination of resources deployed pods, custom resources, and other objects which all contribute to control plane load. A cluster with fewer nodes but intensive resource utilisation can stress the control plane more than a cluster with many nodes running minimal workloads. In such configuration it is recommended to switch to the Standard plan in order to benefit from higher and dedicated control plane resources. While 110 pods per node is the default value defined by Kubernetes, please note that the OVHcloud teams deploy some management components on nodes (CNI, agents, Konnectivity, etc.), these are considered 'cluster mandatory' and will impact the pods per node capacity for user workloads. For the same reason, as those management components are mandatory and require a small amount of node resources, in case of node overloading you might face some of your pods being in state `Terminated` with `Reason: OOMKilled` and `Exit Code: 137`. That's why it is important to have a clean resources management for your workload in order to avoid nodes overloading and instabilities. @@ -160,7 +159,7 @@ To ensure proper operation of your OVHcloud Managed Kubernetes cluster, certain | 80 (169.254.169.254/32) | TCP | Init service (OpenStack metadata) | | 25000–31999 | TCP | TLS tunnel between pods and kubernetes API server | | 8090 | TCP | Internal (OVHcloud) node management service | -| 123 | UDP | NTP servers synchronization (systemd-timesync) | +| 123 | UDP | NTP servers synchronisation (systemd-timesync) | | 53 | TCP/UDP | Allow domain name resolution (systemd-resolve) | | 111 | TCP | rpcbind (only if using NFS client) | | 4443 | TCP | Metrics server communication | @@ -266,16 +265,18 @@ To prevent network conflicts, it is recommended to **keep the DHCP service runni #### Reserved IP ranges -The following ranges are used by the cluster, and should not be used elsewhere on the private network attached to the cluster: +By default, the following ranges are used by the cluster, and should not be used elsewhere on the private network attached to the cluster: ```bash 10.240.0.0/13 # Subnet used by pods 10.3.0.0/16 # Subnet used by services ``` +However, these ranges can be customised either when creating a cluster or when resetting an existing one by following this guide: [Customising IP allocation on an OVHcloud Managed Kubernetes cluster (Standard plan only)](/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation). + > [!warning] > -> These ranges are fixed for now but will be configurable in a future release. Do not use them elsewhere in your private network. +> The subnet ranges cannot be modified on a running cluster without resetting it and losing all data. > ## Cluster health diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.en-sg.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.en-sg.md index b7131b045fa..a7eca857390 100644 --- a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.en-sg.md +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.en-sg.md @@ -1,7 +1,7 @@ --- title: Known limits excerpt: 'Requirements and limits to respect' -updated: 2026-02-03 +updated: 2026-03-17 --- -## Nœuds, pods et limites d'etcd +## Limites de nœuds, de pods et d'etcd -|Plan | Nombre maximum de nœuds par cluster | Nombre maximum de pods par nœud | Nombre maximum de nœuds par groupe d'anti-affinité | Taille maximale d'etcd | +|Plan | Nombre maximum de nœuds par cluster | Nombre maximum de pods par nœud | Nombre maximum de nœuds par groupe d'anti-affinité | Taille maximale d'etcd | |---------|---|---|---|---| -| Free |100|110|5|400Mo| -| Standard|500|110|5|8Go| +| Free |100|110|5|400 Mo| +| Standard|500|110|5|8 Go| Nous avons testé nos plans du service OVHcloud Managed Kubernetes avec un nombre maximum de nœuds. Bien que des configurations plus élevées puissent fonctionner et qu'il n'y ait pas de limites strictes, nous recommandons de rester en dessous de ces limites pour une stabilité optimale. -Gardez à l'esprit que l'impact sur le plan de contrôle n'est pas uniquement déterminé par le nombre de nœuds. Ce qui définit réellement un « grand cluster » dépend de la combinaison des ressources déployées, des pods, des ressources personnalisées et d'autres objets qui contribuent tous à la charge du plan de contrôle. Un cluster avec moins de nœuds mais une utilisation intensive des ressources peut stresser davantage le plan de contrôle qu'un cluster avec de nombreux nœuds exécutant des charges de travail minimales. Dans de telles configurations, il est recommandé de passer au plan Standard afin de bénéficier de ressources de plan de contrôle plus élevées et dédiées. +Gardez à l'esprit que l'impact sur le plan de contrôle n'est pas uniquement déterminé par le nombre de nœuds. Ce qui définit réellement un « grand cluster » dépend de la combinaison des ressources déployées, des pods, des ressources personnalisées et d'autres objets qui contribuent tous à la charge du plan de contrôle. Un cluster avec moins de nœuds mais une utilisation intensive des ressources peut solliciter davantage le plan de contrôle qu'un cluster avec de nombreux nœuds exécutant des charges de travail minimales. Dans de telles configurations, il est recommandé de passer au plan Standard pour bénéficier de ressources de plan de contrôle plus élevées et dédiées. -Bien que 110 pods par nœud soit la valeur par défaut définie par Kubernetes, veuillez noter que l'équipe OVHcloud déploie certains composants de gestion sur les nœuds (CNI, agents, Konnectivity, ...), qui sont considérés comme « obligatoires » pour le cluster et affecteront la capacité du nombre de pods par nœud pour les charges de travail des utilisateurs. Pour la même raison, ces composants de gestion étant obligatoires et nécessitant une petite quantité de ressources de nœud, en cas de surcharge du nœud, vous pourriez retrouver certains de vos pods dans l'état `Terminated` avec `Reason: OOMKilled` et `Exit Code: 137`. C'est pourquoi il est important de gérer proprement les ressources de votre charge de travail afin d'éviter la surcharge des nœuds et les instabilités. +Bien que 110 pods par nœud soit la valeur par défaut définie par Kubernetes, l'équipe OVHcloud déploie certains composants de gestion sur les nœuds (CNI, agents, Konnectivity, etc.), qui sont considérés comme « obligatoires » pour le cluster et affecteront la capacité du nombre de pods par nœud pour les charges de travail des utilisateurs. Pour la même raison, ces composants de gestion étant obligatoires et nécessitant une petite quantité de ressources de nœud, en cas de surcharge du nœud, vous pourriez retrouver certains de vos pods dans l'état `Terminated` avec `Reason: OOMKilled` et `Exit Code: 137`. C'est pourquoi il est important de gérer proprement les ressources de votre charge de travail pour éviter la surcharge des nœuds et les instabilités. -En tant que service entièrement géré, vous **n'aurez pas d'accès SSH** aux nœuds. Toutes les mises à jour du système d'exploitation et des composants sont gérées par OVHcloud via des correctifs et des mises à jour mineures. Si vous avez besoin d'effectuer un **débogage au niveau du nœud**, vous pouvez utiliser les outils natifs Kubernetes avec [kubectl debug](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/#debugging-a-node-using-kubectl-debug-node) pour inspecter ou diagnostiquer un nœud sans nécessiter d'accès SSH direct. +En tant que service entièrement géré, vous **n'aurez pas d'accès SSH** aux nœuds. Toutes les mises à jour du système d'exploitation et des composants sont gérées par OVHcloud via des correctifs et des mises à jour mineures. Pour effectuer un **débogage au niveau du nœud**, vous pouvez utiliser les outils natifs Kubernetes avec [kubectl debug](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/#debugging-a-node-using-kubectl-debug-node) pour inspecter ou diagnostiquer un nœud sans nécessiter d'accès SSH direct. ## Disponibilité régionale par plan La disponibilité d'OVHcloud Managed Kubernetes Service varie selon le plan choisi (Free ou Standard). Chaque plan prend en charge différentes régions et architectures de déploiement (mono ou multi zones de disponibilité). -Pour des informations détaillées sur la disponibilité régionale, l'architecture de déploiement (1-AZ vs 3-AZ) et les fonctionnalités spécifiques au plan, consultez le guide « [Datacenters, nœuds et storage flavors - Disponibilité régionale par plan MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/datacenters-nodes-storage-flavors) ». +Pour des informations détaillées sur la disponibilité régionale, l'architecture de déploiement (1-AZ vs 3-AZ) et les fonctionnalités spécifiques au plan, consultez le guide suivant : [Datacenters, nœuds et storage flavors - Disponibilité régionale par plan MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/datacenters-nodes-storage-flavors). > [!primary] > **Fonctionnalités exclusives du plan Standard :** > -> Le plan Standard inclut des fonctionnalités avancées non disponibles sur le plan Free, telles que les Floating IP par nœud, la résilience cross-AZ, un SLA de niveau production (99,9% pour 1-AZ, 99,99% pour 3-AZ), un stockage etcd dédié et la prise en charge de jusqu'à 500 nœuds. Pour plus d'informations, consultez le guide [Comparaison des plans MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/mks_plans). +> Le plan Standard inclut des fonctionnalités avancées non disponibles sur le plan Free, telles que les Floating IP par nœud, la résilience cross-AZ, un SLA de niveau production (99,9 % pour 1-AZ, 99,99 % pour 3-AZ), un stockage etcd dédié et la prise en charge de jusqu'à 500 nœuds. Pour plus d'informations, consultez le guide [Comparaison des plans MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/mks_plans). ## Considérations sur les correctifs, mises à niveau et maintenances @@ -62,12 +62,12 @@ Les nœuds de travail (ajoutés manuellement ou via le Cluster Autoscaler) sont > Les nœuds de travail GPU (flavors t1 et t2) peuvent prendre plus d'une heure pour atteindre un état prêt. > -Si un incident est détecté par le monitoring OVHcloud, dans le cadre de l'auto-réparation, les nœuds peuvent être entièrement réinstallés après avoir été dans un état 'NotReady' pendant plus de 10 minutes. +Si un incident est détecté par le monitoring OVHcloud, dans le cadre de l'auto-réparation, les nœuds peuvent être entièrement réinstallés après avoir été dans un état `NotReady` pendant plus de 10 minutes. -## Persistance des données & Volumes persistants +## Persistance des données & volumes persistants -Pour éviter la perte de données en cas de panne de nœud, de correctif ou de mise à jour, il est recommandé d'enregistrer vos données sur des Volumes persistants (PV) basés sur des classes de stockage persistant (comme Block ou File Storage), et non directement sur les nœuds (y compris les disques NVMe supplémentaires). -Suivez notre [guide sur la configuration et la gestion des Volumes persistants sur OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume) pour plus d'informations. +Pour éviter la perte de données en cas de panne de nœud, de correctif ou de mise à jour, enregistrez vos données sur des volumes persistants (PV) basés sur des classes de stockage persistant (comme Block ou File Storage), et non directement sur les nœuds (y compris les disques NVMe supplémentaires). +Suivez notre [guide sur la configuration et la gestion des volumes persistants sur OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume) pour plus d'informations. Par défaut, OVHcloud fournit des [classes de stockage](https://github.com/ovh/docs/blob/develop/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume/guide.en-gb.md#storage-classes) basées sur la solution de stockage en bloc Cinder via Cinder CSI. Un nœud de travail peut avoir un maximum de 100 volumes persistants Cinder attachés, et un volume persistant Cinder ne peut être attaché qu'à un seul nœud de travail. @@ -76,7 +76,7 @@ Vous pouvez manuellement [configurer des volumes persistants multi-attach avec N ### Déploiements sur plusieurs zones de disponibilité -Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuvent utiliser des Volumes persistants Cinder provisionnés à l'aide de **classes de stockage spécifiques à la zone** : +Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuvent utiliser des volumes persistants Cinder provisionnés à l'aide de **classes de stockage spécifiques à la zone** : - `csi-cinder-high-speed` - `csi-cinder-high-speed-gen2` @@ -89,7 +89,7 @@ Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuv ### Redimensionnement des volumes -Le redimensionnement des `Persistent Volume Claims` Kubernetes ne permet que d'étendre les volumes, pas de réduire ceux-ci. +Le redimensionnement des `Persistent Volume Claims` Kubernetes ne permet que d'étendre les volumes, pas de les réduire. Si vous essayez de réduire la taille de stockage, vous obtiendrez un message du type : @@ -97,7 +97,7 @@ Si vous essayez de réduire la taille de stockage, vous obtiendrez un message du The PersistentVolumeClaim "mysql-pv-claim" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value ``` -Pour plus de détails, veuillez consulter la [documentation sur le redimensionnement des volumes persistants](/pages/public_cloud/containers_orchestration/managed_kubernetes/resizing-persistent-volumes). +Pour plus de détails, consultez la [documentation sur le redimensionnement des volumes persistants](/pages/public_cloud/containers_orchestration/managed_kubernetes/resizing-persistent-volumes). ### Volumes persistants chiffrés LUKS @@ -120,27 +120,27 @@ Pour plus d'informations : ## LoadBalancer La création d'un service Kubernetes de type LoadBalancer déclenche la création d'un Load Balancer Public Cloud basé sur OpenStack Octavia. -La durée de vie du Load Balancer externe (et de l'adresse IP associée, si elle n'est pas explicitement spécifiée pour la conserver) est liée à la durée de vie de la ressource Kubernetes. +La durée de vie du Load Balancer externe (et de l'adresse IP associée, si elle n'est pas explicitement spécifiée pour être conservée) est liée à la durée de vie de la ressource Kubernetes. Pour plus d'informations, consultez notre guide pour [exposer des services via un LoadBalancer](/pages/public_cloud/containers_orchestration/managed_kubernetes/expose_your_applications_using_a_load_balancer). ## Ressources & quotas -Les ressources du service Kubernetes managé comprenant les nœuds, les volumes persistants et les répartiteurs de charge sont basés sur des ressources Public Cloud standard déployées dans le projet utilisateur. Vous pouvez donc les voir dans l'[espace client Public Cloud d'OVHcloud](/links/manager) ou via les API. Cependant, cela ne signifie pas que vous pouvez interagir directement avec ces ressources de la même manière que vous le feriez avec d'autres instances Public Cloud. La partie *gérée* du service MKS d'OVHcloud signifie que nous avons configuré ces ressources pour qu'elles fassent partie de notre Kubernetes managé. +Les ressources du service Managed Kubernetes, comprenant les nœuds, les volumes persistants et les répartiteurs de charge, sont basées sur des ressources Public Cloud standard déployées dans le projet utilisateur. Vous pouvez donc les voir dans l'[espace client Public Cloud OVHcloud](/links/manager) ou via les API. Cependant, cela ne signifie pas que vous pouvez interagir directement avec ces ressources de la même manière que vous le feriez avec d'autres instances Public Cloud. La partie *gérée* du service MKS d'OVHcloud signifie que nous avons configuré ces ressources pour qu'elles fassent partie de notre Kubernetes managé. Veuillez éviter de les manipuler « manuellement » (modifier les ports laissés ouverts, renommer, supprimer, redimensionner des volumes, etc.), car vous pourriez les endommager. Dans le cadre de notre processus d'auto-réparation, toute suppression ou modification peut entraîner la création ou la duplication d'une nouvelle ressource. -Par défaut, il existe un quota de 20 clusters de plan 'Free' Managed Kubernetes par projet (également nommé 'tenant' OpenStack). +Par défaut, il existe un quota de 20 clusters de plan Free Managed Kubernetes par projet (également nommé `tenant` OpenStack). Les quotas des clusters MKS reposent sur les quotas de votre projet. Si nécessaire, consultez [cette documentation](/pages/public_cloud/public_cloud_cross_functional/increasing_public_cloud_quota) pour augmenter votre quota. ### Nommage des nœuds -En raison des limitations connues actuellement présentes dans le service `Kubelet`, faites attention à attribuer __un nom unique__ à toutes vos instances OpenStack exécutées dans votre projet **y compris** vos nœuds « Managed Kubernetes Service » et les instances que vous démarrez directement sur OpenStack via l'espace client OVHcloud ou l'API. +En raison des limitations connues actuellement présentes dans le service `Kubelet`, faites attention à attribuer __un nom unique__ à toutes vos instances OpenStack exécutées dans votre projet, **y compris** vos nœuds « Managed Kubernetes Service » et les instances que vous démarrez directement sur OpenStack via l'espace client OVHcloud ou l'API. ## Ports -Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, certains ports doivent rester ouverts. +Pour assurer le bon fonctionnement de votre cluster OVHcloud Managed Kubernetes, certains ports doivent rester ouverts. ### Plan Free @@ -161,7 +161,7 @@ Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, | 25000–31999 | TCP | Tunnel TLS entre les pods et le serveur API Kubernetes | | 8090 | TCP | Service interne (gestion des nœuds OVHcloud) | | 123 | UDP | Synchronisation des serveurs NTP (systemd-timesync) | -| 53 | TCP/UDP | Autoriser la résolution des noms de domaine (systemd-resolve) | +| 53 | TCP/UDP | Résolution des noms de domaine (systemd-resolve) | | 111 | TCP | rpcbind (uniquement si vous utilisez le client NFS) | | 4443 | TCP | Communication du serveur de métriques | @@ -179,19 +179,19 @@ Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, > > Pour les clusters du plan Standard, les mêmes règles s'appliquent. > -> Conservez le groupe de sécurité OpenStack par défaut inchangé pour éviter de déconnecter les nœuds ; ajoutez uniquement des règles spécifiques à l'application avec soin. +> Conservez le groupe de sécurité OpenStack par défaut inchangé pour éviter de déconnecter les nœuds ; ajoutez uniquement des règles spécifiques à l'application avec précaution. > #### À propos des groupes de sécurité OpenStack -Dans le cas où vous souhaitez appliquer des groupes de sécurité OpenStack à vos nœuds, il est obligatoire d'ajouter les ports ci-dessus dans un jeu de règles concernant le CIDR `0.0.0.0/0`. +Si vous souhaitez appliquer des groupes de sécurité OpenStack à vos nœuds, il est obligatoire d'ajouter les ports ci-dessus dans un jeu de règles concernant le CIDR `0.0.0.0/0`. > [!warning] > Si vous supprimez les règles par défaut acceptant toutes les entrées et sorties lors de la création d'un nouveau groupe de sécurité, assurez-vous d'autoriser les ports nécessaires à votre application ainsi que les ports obligatoires mentionnés ci-dessus. > > [!primary] -> Pour simplifier votre stratégie, vous pouvez ajouter ces règles qui ne spécifient aucun port et autoriseront tout le trafic interne entre les pods et les services au sein du cluster : +> Pour simplifier votre politique, vous pouvez ajouter ces règles qui ne spécifient aucun port et autoriseront tout le trafic interne entre les pods et les services au sein du cluster : > > | Direction | Ether Type | IP Protocol | Port Range | Remote IP Prefix | Description | > |---|---|---|---|---|---| @@ -200,7 +200,7 @@ Dans le cas où vous souhaitez appliquer des groupes de sécurité OpenStack à > > Cela vous permet de faire confiance au trafic interne entre les pods et les services au sein du cluster. -Pour plus de détails, veuillez consulter la [documentation sur la création et la configuration d'un groupe de sécurité dans Horizon](/pages/public_cloud/compute/setup_security_group). +Pour plus de détails, consultez la [documentation sur la création et la configuration d'un groupe de sécurité dans Horizon](/pages/public_cloud/compute/setup_security_group). ### Plan Standard @@ -223,7 +223,7 @@ openstack security group rule list default +--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+ ``` -Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leur configuration "par défaut" ou les nœuds pourraient être déconnectés du cluster. +Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leur configuration « par défaut », sinon les nœuds pourraient être déconnectés du cluster. ## Réseaux privés @@ -235,24 +235,24 @@ Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leu > > Modifier le nom du réseau ou du sous-réseau peut empêcher le déploiement correct des nouveaux nœuds. Les nœuds auront un taint `"uninitialized=true:NoSchedule"`, ce qui empêchera le kube-scheduler de déployer des pods sur ces nœuds. > -> Les nœuds affectés de cette manière n'auront également pas d'External-IP. +> Les nœuds affectés de cette manière n'auront pas non plus d'External-IP. > ### Plan Free ### Plages d'adresses IP non conformes connues -Les sous-réseaux suivants peuvent générer certains comportements incohérents avec nos réseaux overlay utilisés : +Les sous-réseaux suivants peuvent générer des comportements incohérents avec nos réseaux overlay utilisés : ```bash -10.2.0.0/16 # Subnet used by pods -10.3.0.0/16 # Subnet used by services -172.17.0.0/16 # Subnet used by the Docker daemon +10.2.0.0/16 # Sous-réseau utilisé par les pods +10.3.0.0/16 # Sous-réseau utilisé par les services +172.17.0.0/16 # Sous-réseau utilisé par le daemon Docker ``` > [!primary] > -> Ces sous-réseaux doivent être évités dans votre réseau privé afin d'éviter tout problème de mise en réseau. +> Ces sous-réseaux doivent être évités dans votre réseau privé pour prévenir tout problème réseau. > Pour éviter les conflits réseau, il est recommandé de **maintenir le service DHCP en fonctionnement** dans votre réseau privé. @@ -266,16 +266,18 @@ Pour éviter les conflits réseau, il est recommandé de **maintenir le service #### Plages d'adresses IP réservées -Les plages suivantes sont utilisées par le cluster et ne doivent pas être utilisées ailleurs sur le réseau privé connecté au cluster. +Par défaut, les plages suivantes sont utilisées par le cluster et ne doivent pas être utilisées ailleurs sur le réseau privé connecté au cluster : ```bash -10.240.0.0/13 # Subnet used by pods -10.3.0.0/16 # Subnet used by services +10.240.0.0/13 # Sous-réseau utilisé par les pods +10.3.0.0/16 # Sous-réseau utilisé par les services ``` +Ces plages peuvent toutefois être personnalisées lors de la création d'un cluster ou lors de la réinitialisation d'un cluster existant en suivant ce guide : [Personnaliser l'allocation IP sur un cluster OVHcloud Managed Kubernetes (plan Standard uniquement)](/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation). + > [!warning] > -> Ces plages sont fixes pour l'instant, mais seront configurables dans une prochaine version. Ne les utilisez pas ailleurs dans votre réseau privé. +> Les plages de sous-réseaux ne peuvent pas être modifiées sur un cluster en cours d'exécution sans le réinitialiser et perdre toutes les données. > ## Santé du cluster @@ -284,6 +286,6 @@ La commande `kubectl get componentstatus` signale que le planificateur, le gesti ## Aller plus loin -- Si vous avez besoin d'une formation ou d'une assistance technique pour mettre en œuvre nos solutions, contactez votre représentant commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander à nos experts de l'équipe Professional Services de vous aider dans le cadre de votre projet spécifique. +- Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en œuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une assistance auprès de nos experts Professional Services. -- Rejoignez notre [communauté d'utilisateurs](/links/community). \ No newline at end of file +- Échangez avec notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.fr-fr.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.fr-fr.md index 10d6b30d2e9..0449d7dcb3f 100644 --- a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.fr-fr.md +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.fr-fr.md @@ -1,7 +1,7 @@ --- title: Limites connues excerpt: 'Exigences et limites à respecter' -updated: 2026-02-03 +updated: 2026-03-17 --- -## Nœuds, pods et limites d'etcd +## Limites de nœuds, de pods et d'etcd -|Plan | Nombre maximum de nœuds par cluster | Nombre maximum de pods par nœud | Nombre maximum de nœuds par groupe d'anti-affinité | Taille maximale d'etcd | +|Plan | Nombre maximum de nœuds par cluster | Nombre maximum de pods par nœud | Nombre maximum de nœuds par groupe d'anti-affinité | Taille maximale d'etcd | |---------|---|---|---|---| -| Free |100|110|5|400Mo| -| Standard|500|110|5|8Go| +| Free |100|110|5|400 Mo| +| Standard|500|110|5|8 Go| Nous avons testé nos plans du service OVHcloud Managed Kubernetes avec un nombre maximum de nœuds. Bien que des configurations plus élevées puissent fonctionner et qu'il n'y ait pas de limites strictes, nous recommandons de rester en dessous de ces limites pour une stabilité optimale. -Gardez à l'esprit que l'impact sur le plan de contrôle n'est pas uniquement déterminé par le nombre de nœuds. Ce qui définit réellement un « grand cluster » dépend de la combinaison des ressources déployées, des pods, des ressources personnalisées et d'autres objets qui contribuent tous à la charge du plan de contrôle. Un cluster avec moins de nœuds mais une utilisation intensive des ressources peut stresser davantage le plan de contrôle qu'un cluster avec de nombreux nœuds exécutant des charges de travail minimales. Dans de telles configurations, il est recommandé de passer au plan Standard afin de bénéficier de ressources de plan de contrôle plus élevées et dédiées. +Gardez à l'esprit que l'impact sur le plan de contrôle n'est pas uniquement déterminé par le nombre de nœuds. Ce qui définit réellement un « grand cluster » dépend de la combinaison des ressources déployées, des pods, des ressources personnalisées et d'autres objets qui contribuent tous à la charge du plan de contrôle. Un cluster avec moins de nœuds mais une utilisation intensive des ressources peut solliciter davantage le plan de contrôle qu'un cluster avec de nombreux nœuds exécutant des charges de travail minimales. Dans de telles configurations, il est recommandé de passer au plan Standard pour bénéficier de ressources de plan de contrôle plus élevées et dédiées. -Bien que 110 pods par nœud soit la valeur par défaut définie par Kubernetes, veuillez noter que l'équipe OVHcloud déploie certains composants de gestion sur les nœuds (CNI, agents, Konnectivity, ...), qui sont considérés comme « obligatoires » pour le cluster et affecteront la capacité du nombre de pods par nœud pour les charges de travail des utilisateurs. Pour la même raison, ces composants de gestion étant obligatoires et nécessitant une petite quantité de ressources de nœud, en cas de surcharge du nœud, vous pourriez retrouver certains de vos pods dans l'état `Terminated` avec `Reason: OOMKilled` et `Exit Code: 137`. C'est pourquoi il est important de gérer proprement les ressources de votre charge de travail afin d'éviter la surcharge des nœuds et les instabilités. +Bien que 110 pods par nœud soit la valeur par défaut définie par Kubernetes, l'équipe OVHcloud déploie certains composants de gestion sur les nœuds (CNI, agents, Konnectivity, etc.), qui sont considérés comme « obligatoires » pour le cluster et affecteront la capacité du nombre de pods par nœud pour les charges de travail des utilisateurs. Pour la même raison, ces composants de gestion étant obligatoires et nécessitant une petite quantité de ressources de nœud, en cas de surcharge du nœud, vous pourriez retrouver certains de vos pods dans l'état `Terminated` avec `Reason: OOMKilled` et `Exit Code: 137`. C'est pourquoi il est important de gérer proprement les ressources de votre charge de travail pour éviter la surcharge des nœuds et les instabilités. -En tant que service entièrement géré, vous **n'aurez pas d'accès SSH** aux nœuds. Toutes les mises à jour du système d'exploitation et des composants sont gérées par OVHcloud via des correctifs et des mises à jour mineures. Si vous avez besoin d'effectuer un **débogage au niveau du nœud**, vous pouvez utiliser les outils natifs Kubernetes avec [kubectl debug](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/#debugging-a-node-using-kubectl-debug-node) pour inspecter ou diagnostiquer un nœud sans nécessiter d'accès SSH direct. +En tant que service entièrement géré, vous **n'aurez pas d'accès SSH** aux nœuds. Toutes les mises à jour du système d'exploitation et des composants sont gérées par OVHcloud via des correctifs et des mises à jour mineures. Pour effectuer un **débogage au niveau du nœud**, vous pouvez utiliser les outils natifs Kubernetes avec [kubectl debug](https://kubernetes.io/docs/tasks/debug/debug-cluster/kubectl-node-debug/#debugging-a-node-using-kubectl-debug-node) pour inspecter ou diagnostiquer un nœud sans nécessiter d'accès SSH direct. ## Disponibilité régionale par plan La disponibilité d'OVHcloud Managed Kubernetes Service varie selon le plan choisi (Free ou Standard). Chaque plan prend en charge différentes régions et architectures de déploiement (mono ou multi zones de disponibilité). -Pour des informations détaillées sur la disponibilité régionale, l'architecture de déploiement (1-AZ vs 3-AZ) et les fonctionnalités spécifiques au plan, consultez le guide « [Datacenters, nœuds et storage flavors - Disponibilité régionale par plan MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/datacenters-nodes-storage-flavors) ». +Pour des informations détaillées sur la disponibilité régionale, l'architecture de déploiement (1-AZ vs 3-AZ) et les fonctionnalités spécifiques au plan, consultez le guide suivant : [Datacenters, nœuds et storage flavors - Disponibilité régionale par plan MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/datacenters-nodes-storage-flavors). > [!primary] > **Fonctionnalités exclusives du plan Standard :** > -> Le plan Standard inclut des fonctionnalités avancées non disponibles sur le plan Free, telles que les Floating IP par nœud, la résilience cross-AZ, un SLA de niveau production (99,9% pour 1-AZ, 99,99% pour 3-AZ), un stockage etcd dédié et la prise en charge de jusqu'à 500 nœuds. Pour plus d'informations, consultez le guide [Comparaison des plans MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/mks_plans). +> Le plan Standard inclut des fonctionnalités avancées non disponibles sur le plan Free, telles que les Floating IP par nœud, la résilience cross-AZ, un SLA de niveau production (99,9 % pour 1-AZ, 99,99 % pour 3-AZ), un stockage etcd dédié et la prise en charge de jusqu'à 500 nœuds. Pour plus d'informations, consultez le guide [Comparaison des plans MKS](/pages/public_cloud/containers_orchestration/managed_kubernetes/mks_plans). ## Considérations sur les correctifs, mises à niveau et maintenances @@ -62,12 +62,12 @@ Les nœuds de travail (ajoutés manuellement ou via le Cluster Autoscaler) sont > Les nœuds de travail GPU (flavors t1 et t2) peuvent prendre plus d'une heure pour atteindre un état prêt. > -Si un incident est détecté par le monitoring OVHcloud, dans le cadre de l'auto-réparation, les nœuds peuvent être entièrement réinstallés après avoir été dans un état 'NotReady' pendant plus de 10 minutes. +Si un incident est détecté par le monitoring OVHcloud, dans le cadre de l'auto-réparation, les nœuds peuvent être entièrement réinstallés après avoir été dans un état `NotReady` pendant plus de 10 minutes. -## Persistance des données & Volumes persistants +## Persistance des données & volumes persistants -Pour éviter la perte de données en cas de panne de nœud, de correctif ou de mise à jour, il est recommandé d'enregistrer vos données sur des Volumes persistants (PV) basés sur des classes de stockage persistant (comme Block ou File Storage), et non directement sur les nœuds (y compris les disques NVMe supplémentaires). -Suivez notre [guide sur la configuration et la gestion des Volumes persistants sur OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume) pour plus d'informations. +Pour éviter la perte de données en cas de panne de nœud, de correctif ou de mise à jour, enregistrez vos données sur des volumes persistants (PV) basés sur des classes de stockage persistant (comme Block ou File Storage), et non directement sur les nœuds (y compris les disques NVMe supplémentaires). +Suivez notre [guide sur la configuration et la gestion des volumes persistants sur OVHcloud Managed Kubernetes](/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume) pour plus d'informations. Par défaut, OVHcloud fournit des [classes de stockage](https://github.com/ovh/docs/blob/develop/pages/public_cloud/containers_orchestration/managed_kubernetes/setting-up-a-persistent-volume/guide.en-gb.md#storage-classes) basées sur la solution de stockage en bloc Cinder via Cinder CSI. Un nœud de travail peut avoir un maximum de 100 volumes persistants Cinder attachés, et un volume persistant Cinder ne peut être attaché qu'à un seul nœud de travail. @@ -76,7 +76,7 @@ Vous pouvez manuellement [configurer des volumes persistants multi-attach avec N ### Déploiements sur plusieurs zones de disponibilité -Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuvent utiliser des Volumes persistants Cinder provisionnés à l'aide de **classes de stockage spécifiques à la zone** : +Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuvent utiliser des volumes persistants Cinder provisionnés à l'aide de **classes de stockage spécifiques à la zone** : - `csi-cinder-high-speed` - `csi-cinder-high-speed-gen2` @@ -89,7 +89,7 @@ Les clusters MKS déployés sur des régions avec 3 zones de disponibilité peuv ### Redimensionnement des volumes -Le redimensionnement des `Persistent Volume Claims` Kubernetes ne permet que d'étendre les volumes, pas de réduire ceux-ci. +Le redimensionnement des `Persistent Volume Claims` Kubernetes ne permet que d'étendre les volumes, pas de les réduire. Si vous essayez de réduire la taille de stockage, vous obtiendrez un message du type : @@ -97,7 +97,7 @@ Si vous essayez de réduire la taille de stockage, vous obtiendrez un message du The PersistentVolumeClaim "mysql-pv-claim" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value ``` -Pour plus de détails, veuillez consulter la [documentation sur le redimensionnement des volumes persistants](/pages/public_cloud/containers_orchestration/managed_kubernetes/resizing-persistent-volumes). +Pour plus de détails, consultez la [documentation sur le redimensionnement des volumes persistants](/pages/public_cloud/containers_orchestration/managed_kubernetes/resizing-persistent-volumes). ### Volumes persistants chiffrés LUKS @@ -120,27 +120,27 @@ Pour plus d'informations : ## LoadBalancer La création d'un service Kubernetes de type LoadBalancer déclenche la création d'un Load Balancer Public Cloud basé sur OpenStack Octavia. -La durée de vie du Load Balancer externe (et de l'adresse IP associée, si elle n'est pas explicitement spécifiée pour la conserver) est liée à la durée de vie de la ressource Kubernetes. +La durée de vie du Load Balancer externe (et de l'adresse IP associée, si elle n'est pas explicitement spécifiée pour être conservée) est liée à la durée de vie de la ressource Kubernetes. Pour plus d'informations, consultez notre guide pour [exposer des services via un LoadBalancer](/pages/public_cloud/containers_orchestration/managed_kubernetes/expose_your_applications_using_a_load_balancer). ## Ressources & quotas -Les ressources du service Kubernetes managé comprenant les nœuds, les volumes persistants et les répartiteurs de charge sont basés sur des ressources Public Cloud standard déployées dans le projet utilisateur. Vous pouvez donc les voir dans l'[espace client Public Cloud d'OVHcloud](/links/manager) ou via les API. Cependant, cela ne signifie pas que vous pouvez interagir directement avec ces ressources de la même manière que vous le feriez avec d'autres instances Public Cloud. La partie *gérée* du service MKS d'OVHcloud signifie que nous avons configuré ces ressources pour qu'elles fassent partie de notre Kubernetes managé. +Les ressources du service Managed Kubernetes, comprenant les nœuds, les volumes persistants et les répartiteurs de charge, sont basées sur des ressources Public Cloud standard déployées dans le projet utilisateur. Vous pouvez donc les voir dans l'[espace client Public Cloud OVHcloud](/links/manager) ou via les API. Cependant, cela ne signifie pas que vous pouvez interagir directement avec ces ressources de la même manière que vous le feriez avec d'autres instances Public Cloud. La partie *gérée* du service MKS d'OVHcloud signifie que nous avons configuré ces ressources pour qu'elles fassent partie de notre Kubernetes managé. Veuillez éviter de les manipuler « manuellement » (modifier les ports laissés ouverts, renommer, supprimer, redimensionner des volumes, etc.), car vous pourriez les endommager. Dans le cadre de notre processus d'auto-réparation, toute suppression ou modification peut entraîner la création ou la duplication d'une nouvelle ressource. -Par défaut, il existe un quota de 20 clusters de plan 'Free' Managed Kubernetes par projet (également nommé 'tenant' OpenStack). +Par défaut, il existe un quota de 20 clusters de plan Free Managed Kubernetes par projet (également nommé `tenant` OpenStack). Les quotas des clusters MKS reposent sur les quotas de votre projet. Si nécessaire, consultez [cette documentation](/pages/public_cloud/public_cloud_cross_functional/increasing_public_cloud_quota) pour augmenter votre quota. ### Nommage des nœuds -En raison des limitations connues actuellement présentes dans le service `Kubelet`, faites attention à attribuer __un nom unique__ à toutes vos instances OpenStack exécutées dans votre projet **y compris** vos nœuds « Managed Kubernetes Service » et les instances que vous démarrez directement sur OpenStack via l'espace client OVHcloud ou l'API. +En raison des limitations connues actuellement présentes dans le service `Kubelet`, faites attention à attribuer __un nom unique__ à toutes vos instances OpenStack exécutées dans votre projet, **y compris** vos nœuds « Managed Kubernetes Service » et les instances que vous démarrez directement sur OpenStack via l'espace client OVHcloud ou l'API. ## Ports -Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, certains ports doivent rester ouverts. +Pour assurer le bon fonctionnement de votre cluster OVHcloud Managed Kubernetes, certains ports doivent rester ouverts. ### Plan Free @@ -161,7 +161,7 @@ Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, | 25000–31999 | TCP | Tunnel TLS entre les pods et le serveur API Kubernetes | | 8090 | TCP | Service interne (gestion des nœuds OVHcloud) | | 123 | UDP | Synchronisation des serveurs NTP (systemd-timesync) | -| 53 | TCP/UDP | Autoriser la résolution des noms de domaine (systemd-resolve) | +| 53 | TCP/UDP | Résolution des noms de domaine (systemd-resolve) | | 111 | TCP | rpcbind (uniquement si vous utilisez le client NFS) | | 4443 | TCP | Communication du serveur de métriques | @@ -179,19 +179,19 @@ Pour assurer le bon fonctionnement de votre cluster Kubernetes Managé OVHcloud, > > Pour les clusters du plan Standard, les mêmes règles s'appliquent. > -> Conservez le groupe de sécurité OpenStack par défaut inchangé pour éviter de déconnecter les nœuds ; ajoutez uniquement des règles spécifiques à l'application avec soin. +> Conservez le groupe de sécurité OpenStack par défaut inchangé pour éviter de déconnecter les nœuds ; ajoutez uniquement des règles spécifiques à l'application avec précaution. > #### À propos des groupes de sécurité OpenStack -Dans le cas où vous souhaitez appliquer des groupes de sécurité OpenStack à vos nœuds, il est obligatoire d'ajouter les ports ci-dessus dans un jeu de règles concernant le CIDR `0.0.0.0/0`. +Si vous souhaitez appliquer des groupes de sécurité OpenStack à vos nœuds, il est obligatoire d'ajouter les ports ci-dessus dans un jeu de règles concernant le CIDR `0.0.0.0/0`. > [!warning] > Si vous supprimez les règles par défaut acceptant toutes les entrées et sorties lors de la création d'un nouveau groupe de sécurité, assurez-vous d'autoriser les ports nécessaires à votre application ainsi que les ports obligatoires mentionnés ci-dessus. > > [!primary] -> Pour simplifier votre stratégie, vous pouvez ajouter ces règles qui ne spécifient aucun port et autoriseront tout le trafic interne entre les pods et les services au sein du cluster : +> Pour simplifier votre politique, vous pouvez ajouter ces règles qui ne spécifient aucun port et autoriseront tout le trafic interne entre les pods et les services au sein du cluster : > > | Direction | Ether Type | IP Protocol | Port Range | Remote IP Prefix | Description | > |---|---|---|---|---|---| @@ -200,7 +200,7 @@ Dans le cas où vous souhaitez appliquer des groupes de sécurité OpenStack à > > Cela vous permet de faire confiance au trafic interne entre les pods et les services au sein du cluster. -Pour plus de détails, veuillez consulter la [documentation sur la création et la configuration d'un groupe de sécurité dans Horizon](/pages/public_cloud/compute/setup_security_group). +Pour plus de détails, consultez la [documentation sur la création et la configuration d'un groupe de sécurité dans Horizon](/pages/public_cloud/compute/setup_security_group). ### Plan Standard @@ -223,7 +223,7 @@ openstack security group rule list default +--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+ ``` -Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leur configuration "par défaut" ou les nœuds pourraient être déconnectés du cluster. +Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leur configuration « par défaut », sinon les nœuds pourraient être déconnectés du cluster. ## Réseaux privés @@ -235,24 +235,24 @@ Pour l'instant, il est recommandé de laisser ces règles de sécurité dans leu > > Modifier le nom du réseau ou du sous-réseau peut empêcher le déploiement correct des nouveaux nœuds. Les nœuds auront un taint `"uninitialized=true:NoSchedule"`, ce qui empêchera le kube-scheduler de déployer des pods sur ces nœuds. > -> Les nœuds affectés de cette manière n'auront également pas d'External-IP. +> Les nœuds affectés de cette manière n'auront pas non plus d'External-IP. > ### Plan Free ### Plages d'adresses IP non conformes connues -Les sous-réseaux suivants peuvent générer certains comportements incohérents avec nos réseaux overlay utilisés : +Les sous-réseaux suivants peuvent générer des comportements incohérents avec nos réseaux overlay utilisés : ```bash -10.2.0.0/16 # Subnet used by pods -10.3.0.0/16 # Subnet used by services -172.17.0.0/16 # Subnet used by the Docker daemon +10.2.0.0/16 # Sous-réseau utilisé par les pods +10.3.0.0/16 # Sous-réseau utilisé par les services +172.17.0.0/16 # Sous-réseau utilisé par le daemon Docker ``` > [!primary] > -> Ces sous-réseaux doivent être évités dans votre réseau privé afin d'éviter tout problème de mise en réseau. +> Ces sous-réseaux doivent être évités dans votre réseau privé pour prévenir tout problème réseau. > Pour éviter les conflits réseau, il est recommandé de **maintenir le service DHCP en fonctionnement** dans votre réseau privé. @@ -266,16 +266,18 @@ Pour éviter les conflits réseau, il est recommandé de **maintenir le service #### Plages d'adresses IP réservées -Les plages suivantes sont utilisées par le cluster et ne doivent pas être utilisées ailleurs sur le réseau privé connecté au cluster. +Par défaut, les plages suivantes sont utilisées par le cluster et ne doivent pas être utilisées ailleurs sur le réseau privé connecté au cluster : ```bash -10.240.0.0/13 # Subnet used by pods -10.3.0.0/16 # Subnet used by services +10.240.0.0/13 # Sous-réseau utilisé par les pods +10.3.0.0/16 # Sous-réseau utilisé par les services ``` +Ces plages peuvent toutefois être personnalisées lors de la création d'un cluster ou lors de la réinitialisation d'un cluster existant en suivant ce guide : [Personnaliser l'allocation IP sur un cluster OVHcloud Managed Kubernetes (plan Standard uniquement)](/pages/public_cloud/containers_orchestration/managed_kubernetes/configuring-pods-services-ip-allocation). + > [!warning] > -> Ces plages sont fixes pour l'instant, mais seront configurables dans une prochaine version. Ne les utilisez pas ailleurs dans votre réseau privé. +> Les plages de sous-réseaux ne peuvent pas être modifiées sur un cluster en cours d'exécution sans le réinitialiser et perdre toutes les données. > ## Santé du cluster @@ -284,6 +286,6 @@ La commande `kubectl get componentstatus` signale que le planificateur, le gesti ## Aller plus loin -- Si vous avez besoin d'une formation ou d'une assistance technique pour mettre en œuvre nos solutions, contactez votre représentant commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander à nos experts de l'équipe Professional Services de vous aider dans le cadre de votre projet spécifique. +- Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en œuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une assistance auprès de nos experts Professional Services. -- Rejoignez notre [communauté d'utilisateurs](/links/community). \ No newline at end of file +- Échangez avec notre [communauté d'utilisateurs](/links/community). diff --git a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.it-it.md b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.it-it.md index b7131b045fa..a7eca857390 100644 --- a/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.it-it.md +++ b/pages/public_cloud/containers_orchestration/managed_kubernetes/known-limits/guide.it-it.md @@ -1,7 +1,7 @@ --- title: Known limits excerpt: 'Requirements and limits to respect' -updated: 2026-02-03 +updated: 2026-03-17 ---