Comparaison entre les clusters améliorés et les clusters de base
Découvrez les différences entre les clusters améliorés et les clusters de base que vous pouvez créer à l'aide de Kubernetes Engine (OKE).
Lors de la création d'un cluster avec Kubernetes Engine, vous indiquez le type de cluster à créer sous l'une ou l'autre des formes suivantes :
- Cluster amélioré : les clusters améliorés prennent en charge toutes les fonctionnalités disponibles. Reportez-vous à Clusters améliorés.
- Cluster de base : les clusters de base prennent en charge toutes les fonctionnalités de base fournies par Kubernetes et Kubernetes Engine, mais aucune des fonctionnalités améliorées fournies par Kubernetes Engine. Reportez-vous à Clusters de base.
Tenez compte des éléments suivants lors de la création des clusters :
- Lorsque vous utilisez la console pour créer un cluster, si vous ne sélectionnez aucune fonctionnalité améliorée lors de la création du cluster, vous avez la possibilité de créer le nouveau cluster en tant que cluster de base. Par défaut, un nouveau cluster est créé en tant que cluster amélioré, sauf si vous choisissez explicitement de créer un cluster de base.
- Lorsque vous utilisez l'interface de ligne de commande ou l'API pour créer un cluster, vous pouvez indiquer s'il faut créer un cluster de base ou un cluster amélioré. Si vous ne spécifiez pas explicitement le type de cluster à créer, un nouveau cluster est créé en tant que cluster de base par défaut.
La création d'un nouveau cluster en tant que cluster amélioré vous permet d'ajouter facilement des fonctionnalités améliorées ultérieurement, même si vous n'avez pas initialement sélectionné de fonctionnalités améliorées. Lorsque vous créez un cluster amélioré, vous devez le créer en tant que VCN natif. Si vous choisissez de créer un cluster en tant que cluster de base, vous pouvez toujours choisir de le mettre à niveau vers un cluster amélioré ultérieurement, à condition qu'il soit natif VCN. Toutefois, vous ne pouvez pas rétrograder un cluster amélioré vers un cluster de base.
Toutes les références à "clusters" dans la documentation de Kubernetes Engine font référence aux clusters améliorés et aux clusters de base, sauf indication contraire explicite.
Clusters améliorés
Les clusters améliorés prennent en charge toutes les fonctionnalités disponibles, y compris celles qui ne sont pas prises en charge par les clusters de base (notamment les noeuds virtuels, la gestion des extensions de cluster, l'identité de la charge globale, des noeuds de processus actif supplémentaires par cluster, des noeuds autogérés et le cyclage des noeuds lors de la mise à jour ou de la mise à niveau des pools de noeuds). Les clusters améliorés sont fournis avec un contrat de niveau de service (SLA) soutenu financièrement.
Fonctionnalités notables prises en charge différemment par les clusters améliorés
En fonction des fonctionnalités améliorées que vous sélectionnez pour un cluster amélioré, certaines fonctionnalités sont prises en charge différemment dans les clusters améliorés par rapport aux clusters de base :
- Pools de noeuds gérés et virtuels : dans un cluster amélioré, vous pouvez choisir de créer des pools de noeuds virtuels (ainsi que les pools de noeuds gérés que vous êtes limité à créer dans un cluster de base). Si vous choisissez de créer des noeuds virtuels et des pools de noeuds, l'équilibrage de charge, la mise en réseau de pod, le redimensionnement automatique et l'affichage des journaux d'application sont pris en charge différemment. Reportez-vous à la section Virtual Nodes and Virtual Node Pools.
- Extensions de cluster : dans un cluster amélioré, vous pouvez utiliser Kubernetes Engine pour gérer les extensions essentielles et un portefeuille croissant d'extensions facultatives. Vous pouvez activer ou désactiver des modules spécifiques, sélectionner des versions, choisir les mises à jour automatiques par Oracle, et gérer les personnalisations spécifiques aux modules. Reportez-vous à Configuration des extensions de cluster.
- Droits d'accès : dans un cluster amélioré, vous pouvez choisir de définir des stratégies OCI IAM qui autorisent des pods spécifiques à effectuer des appels d'API OCI et à accéder aux ressources OCI. Reportez-vous à Attribution de l'accès aux ressources OCI aux charges globales.
En outre, vous pouvez nous contacter pour demander une augmentation du nombre de clusters améliorés que vous pouvez créer dans une région (reportez-vous à Limites de Kubernetes Engine).
Fonctionnalités notables non prises en charge par les clusters améliorés
Les clusters améliorés prennent en charge toutes les fonctionnalités prises en charge par les clusters de base. Aucune fonctionnalité prise en charge par les clusters de base n'est prise en charge par les clusters améliorés.
Clusters de base
Les clusters de base prennent en charge toutes les fonctionnalités de base fournies par Kubernetes et Kubernetes Engine, mais aucune des fonctionnalités améliorées fournies par Kubernetes Engine ne prend en charge les clusters améliorés (tels que les noeuds virtuels, la gestion des extensions de cluster, l'identité de charge de travail, le cycle des noeuds, les noeuds autogérés et les noeuds de processus actif supplémentaires par cluster). Les clusters de base ont un objectif de niveau de service, mais pas un contrat de niveau de service soutenu financièrement.
Fonctionnalités notables prises en charge différemment par les clusters de base
Certaines fonctionnalités sont prises en charge différemment dans les clusters de base par rapport aux clusters améliorés :
- Pools de noeuds gérés et virtuels : dans un cluster de base, vous pouvez uniquement créer des pools de noeuds gérés (plutôt que les pools de noeuds gérés et virtuels que vous pouvez choisir de créer dans un cluster amélioré). L'équilibrage de charge, la mise en réseau de pod, le redimensionnement automatique et l'affichage des journaux d'application sont pris en charge différemment avec les noeuds gérés et les pools de noeuds. Reportez-vous à Noeuds gérés et pools de noeuds gérés.
- Extensions de cluster : dans un cluster de base, vous avez plus de responsabilités et moins de flexibilité lors de la gestion des extensions de cluster. Vous êtes responsable de la mise à niveau des modules indispensables, mais vous ne pouvez pas installer ou désactiver des modules spécifiques, sélectionner des versions, choisir les mises à jour automatiques par Oracle ou gérer des personnalisations spécifiques aux modules complémentaires. En outre, vous êtes responsable de l'installation, de la gestion et de la maintenance des modules complémentaires facultatifs que vous souhaitez inclure dans le cluster. Reportez-vous à Configuration des extensions de cluster.
- Droits d'accès : dans un cluster de base, vous devez définir des stratégies OCI IAM qui autorisent les utilisateurs et les instances (plutôt que l'identité de charge globale que vous pouvez choisir d'implémenter dans un cluster amélioré). Par conséquent, plus de privilèges sont accordés que le minimum absolu requis, ce qui n'est pas la meilleure pratique. Reportez-vous à Octroi de l'accès aux ressources OCI aux charges globales
En outre, vous ne pouvez pas demander une augmentation du nombre de clusters de base que vous pouvez créer dans une région (reportez-vous à Limites de Kubernetes Engine).
Fonctionnalités notables non prises en charge par les clusters de base
Les clusters de base ne prennent pas en charge certaines des fonctionnalités prises en charge par les clusters améliorés :
- Pools de noeuds virtuels
- Déploiement et configuration détaillés d'extensions de cluster
- Identité de charge globale
- Augmentation du nombre de noeuds de processus actifs
- Noeuds auto-gérés
- Accord de niveau de service soutenu financièrement
- Cyclage de noeud lors de la mise à jour ou de la mise à niveau de pools de noeuds
- Configuration de la sécurité du conteneur Cloud Guard
Comparaison des clusters améliorés et des clusters de base
Le tableau suivant récapitule les similitudes et les différences entre les clusters améliorés et les clusters de base :
| Fonctionnalité/Capacité | Cluster amélioré | Cluster de base |
|---|---|---|
| Prend en charge toutes les fonctionnalités de base de Kubernetes et OKE | Oui | Oui |
| Pools de noeuds gérés pris en charge | Oui | Oui |
| Pools de noeuds virtuels pris en charge | Oui | Non |
| Noeuds autogérés pris en charge | Oui | Non |
| Cycles de nœuds (cordonage, vidange et remplacement automatiques des nœuds) pour les mises à jour/mises à niveau | Oui | Non |
| Configuration de la sécurité du conteneur Cloud Guard | Oui | Non |
| Modules de cluster flexibles et gérés | Oui | Non |
| Déploiement/configuration de modules complémentaires détaillés | Oui | Non |
| Peut gérer les modules complémentaires essentiels et facultatifs dans la console et d'autres interfaces | Oui | Non |
| Sélection de la version et mises à jour automatiques | Oui | Non |
| Modules gérés par l'utilisateur possibles | Oui | Oui |
| Identité de charge globale (OCI IAM détaillé pour les pods/conteneurs) | Oui | Non |
| Droits d'accès basés sur une stratégie utilisateur/instance | Oui | Oui |
| Peut demander une augmentation du nombre de clusters ou du nombre de noeuds par cluster | Oui | Non |
| Limites de noeud de processus actif supérieures | Oui | Non |
| Contrat de niveau de service financé | Oui | Non |
| Objectif de niveau de service uniquement | Non | Oui |
| Peut être mis à niveau vers un cluster amélioré | S/O | Oui (le cluster doit être natif VCN) |
| Type de création par défaut (console) | Oui | Non (sauf si sélectionné) |
| Type de création par défaut (CLI/API) | Non (sauf si sélectionné) | Oui |