Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Exemples de scénarios

Ces scénarios d’exemple décrivent comment une organisation pourrait utiliser des modèles pour standardiser la création de clusters.

Application des modèles : Les administrateurs pourraient vouloir appliquer un ou plusieurs paramètres de modèle pour tout le monde s’ils souhaitent que tous les nouveaux clusters provisionnés par Rancher aient ces paramètres.
Partage de différents modèles avec différents utilisateurs : Les administrateurs pourraient donner différents modèles aux utilisateurs basiques et avancés, afin que les utilisateurs basiques aient des options plus restreintes et que les utilisateurs avancés aient plus de liberté lors de la création de clusters.
Mise à jour des paramètres de modèle : Si les équipes de sécurité et de DevOps d’une organisation décident d’incorporer les meilleures pratiques dans les paramètres requis pour les nouveaux clusters, ces meilleures pratiques pourraient évoluer avec le temps. Si les meilleures pratiques changent, un modèle peut être mis à jour vers une nouvelle révision et les clusters créés à partir du modèle peuvent être mis à niveau vers la nouvelle version du modèle.
Partage de la propriété d’un modèle : Lorsqu’un propriétaire de modèle ne souhaite plus maintenir un modèle, ou souhaite déléguer la propriété du modèle, ce scénario décrit comment la propriété du modèle peut être partagée.

Application d’un paramètre de modèle pour tout le monde

Disons qu’il y a une organisation dans laquelle les administrateurs décident que tous les nouveaux clusters doivent être créés avec la version Kubernetes 1.14.

Tout d’abord, un administrateur crée un modèle qui spécifie la version Kubernetes comme 1.14 et marque tous les autres paramètres comme Autoriser la surcharge par l’utilisateur.
L’administrateur rend le modèle public.
L’administrateur active l’application du modèle.

Résultats :

Tous les utilisateurs de Rancher dans l’organisation ont accès au modèle.
Tous les nouveaux clusters créés par utilisateurs standards avec ce modèle utiliseront Kubernetes 1.14 et ils ne pourront pas utiliser une version Kubernetes différente. Par défaut, les utilisateurs standards n’ont pas la permission de créer des modèles, donc ce modèle sera le seul qu’ils pourront utiliser à moins que d’autres modèles ne leur soient partagés.
Tous les utilisateurs standards doivent utiliser un modèle de cluster pour créer un nouveau cluster. Ils ne peuvent pas créer un cluster sans utiliser un modèle.

De cette manière, les administrateurs appliquent la version de Kubernetes dans toute l’organisation, tout en permettant aux utilisateurs finaux de configurer tout le reste.

Modèles pour utilisateurs basiques et avancés

Disons qu’une organisation a à la fois des utilisateurs basiques et avancés. Les administrateurs souhaitent que les utilisateurs basiques soient tenus d’utiliser un modèle, tandis que les utilisateurs avancés et les administrateurs créent leurs clusters comme ils le souhaitent.

Tout d’abord, un administrateur active l’application du modèle RKE. Cela signifie que chaque utilisateur standard dans Rancher devra utiliser un modèle RKE lorsqu’il crée un cluster.
L’administrateur crée ensuite deux modèles :
- Un modèle pour les utilisateurs basiques, avec presque toutes les options spécifiées sauf pour les clés d’accès
- Autoriser la surcharge par l’utilisateur
L’administrateur partage le modèle avancé uniquement avec les utilisateurs avancés.
L’administrateur rend le modèle pour les utilisateurs basiques public, de sorte que le modèle plus restrictif soit une option pour tous ceux qui créent un cluster provisionné par Rancher.

Résultat : Tous les utilisateurs de Rancher, à l’exception des administrateurs, sont tenus d’utiliser un modèle lors de la création d’un cluster. Tout le monde a accès au modèle restrictif, mais seuls les utilisateurs avancés ont la permission d’utiliser le modèle plus permissif. Les utilisateurs basiques sont plus restreints, tandis que les utilisateurs avancés ont plus de liberté lors de la configuration de leurs clusters Kubernetes.

Mise à jour des modèles et des clusters créés avec eux

Disons qu’une organisation a un modèle qui exige que les clusters utilisent Kubernetes v1.14. Cependant, au fil du temps, les administrateurs changent d’avis. Ils décident qu’ils veulent que les utilisateurs puissent mettre à niveau leurs clusters pour utiliser des versions plus récentes de Kubernetes.

Dans cette organisation, de nombreux clusters ont été créés avec un modèle qui exige Kubernetes v1.14. Parce que le modèle ne permet pas de remplacer ce paramètre, les utilisateurs qui ont créé le cluster ne peuvent pas modifier directement ce paramètre.

Le propriétaire du modèle a plusieurs options pour permettre aux créateurs de clusters de mettre à niveau Kubernetes sur leurs clusters :

Spécifiez Kubernetes v1.15 sur le modèle : Le propriétaire du modèle peut créer une nouvelle révision du modèle qui spécifie Kubernetes v1.15. Ensuite, le propriétaire de chaque cluster utilisant ce modèle peut mettre à niveau son cluster vers une nouvelle révision du modèle. Cette mise à niveau du modèle permet au créateur de cluster de mettre à niveau Kubernetes vers v1.15 sur son cluster.
Autoriser n’importe quelle version de Kubernetes sur le modèle : Autoriser la surcharge par l’utilisateur Cela permettra aux clusters qui se mettent à niveau vers cette révision du modèle d’utiliser n’importe quelle version de Kubernetes.
Autoriser la dernière version mineure de Kubernetes sur le modèle : Le propriétaire du modèle peut également créer une révision du modèle dans laquelle la version de Kubernetes est définie comme Dernière v1.14 (Autorise les mises à niveau de version de correctif). Cela signifie que les clusters utilisant cette révision pourront obtenir des mises à niveau de version de correctif, mais les mises à niveau de version majeure ne seront pas autorisées.

Autoriser d’autres utilisateurs à contrôler et partager un modèle

Disons qu’Alice est une administratrice de Rancher. Elle possède un modèle RKE qui reflète les meilleures pratiques convenues de son organisation pour créer un cluster.

Bob est un utilisateur avancé qui peut prendre des décisions éclairées sur la configuration du cluster. Alice fait confiance à Bob pour créer de nouvelles révisions de son modèle à mesure que les meilleures pratiques sont mises à jour. Par conséquent, elle décide de faire de Bob un propriétaire du modèle.

Pour partager la propriété du modèle avec Bob, Alice ajoute Bob en tant que propriétaire de son modèle.

Le résultat est qu’en tant que propriétaire du modèle, Bob est responsable du contrôle de version de ce modèle. Bob peut désormais effectuer toutes les tâches suivantes :

Réviser le modèle lorsque les meilleures pratiques changent
Désactiver les révisions obsolètes du modèle afin qu’aucun nouveau cluster ne puisse être créé avec celui-ci
Supprimer l’ensemble du modèle si l’organisation souhaite prendre une direction différente
Définir une certaine révision comme par défaut lorsque les utilisateurs créent un cluster avec celle-ci. Les utilisateurs finaux du modèle pourront toujours choisir quelle révision ils souhaitent utiliser pour créer le cluster.
Partager le modèle avec des utilisateurs spécifiques, rendre le modèle disponible à tous les utilisateurs de Rancher, ou partager la propriété du modèle avec un autre utilisateur.