Dans le premier de deux articles couvrant l’utilisation de Kubernetes comme fournisseur de services Cloud, Brad Campbell répond à la question suivante : que sont les définitions de ressources personnalisées ?
Dans un monde où le Cloud et l’automatisation du cycle de vie de « toutes les choses » sont des préoccupations majeures pour de nombreux professionnels de l’informatique, les conversations sur Terraform, CloudFormation (et maintenant qui commencent à inclure régulièrement AWS CDK et Pulumi) sont relativement courantes. L’adoption croissante de Kubernetes s’est accompagnée d’une augmentation de sa capacité à s’intégrer dans des conversations autres que celles strictement liées à l’emplacement des conteneurs.
En fait, le thème de cette conversation est exactement celui par lequel nous avons commencé : l’automatisation du cycle de vie des objets et services basés sur le Cloud. Cette conversation sera cependant très différente de la plupart des conversations dans ce domaine, car elle se concentrera sur la manière de le faire via Kubernetes. Afin de relier les points de la façon dont nous pouvons accomplir cela (et pourquoi il est logique de le faire dans certains scénarios), nous discutons d’abord de quelques concepts qui sont des parties importantes du processus global.
Définitions de ressources personnalisées
Alors, que sont exactement les définitions de ressources personnalisées (ou CRD) ? Extrait de la documentation de Kubernetes :
une ressource personnalisée est une extension de l’API Kubernetes qui n’est pas nécessairement disponible dans une installation Kubernetes par défaut. Il représente une personnalisation d’une installation Kubernetes particulière. Cependant, de nombreuses fonctions centrales de Kubernetes sont désormais construites à l’aide de ressources personnalisées, ce qui rend Kubernetes plus modulaire.
D’après cette définition, nous voyons que les CRD sont un mécanisme que Kubernetes possède à des fins d’extensibilité.
Implémenteurs de définitions de ressources personnalisées
Les CRD peuvent sembler être une sorte de fonctionnalité exotique qui n’est pas souvent utilisée dans le monde réel. Mais en réalité, les CRD sont partout. Si vous avez déjà entendu parler de Calico, vous avez entendu parler d’un projet qui utilise des CRD. D’autres projets populaires comme kubeflow les utilisent. Operatorhub est un marché ouvert d’applications et de composants qui implémentent le modèle Operator, chacun étant généralement composé de plusieurs CRD.
Pour en revenir aux thèmes d’ouverture, dans cet article, nous allons utiliser un CRD d’une société appelée Crossplane. Crossplane dispose d’un ensemble impressionnant de CRD qui permettent à un développeur ou à un opérateur de cluster qui peut déployer des applications sur un cluster de provisionner des ressources cloud directement à partir du cluster. Grâce aux CRD Crossplane, les ressources Cloud sont gérées de manière déclarative via des fichiers YAML, tout comme un pod ou un déploiement ; vous pouvez également créer des ressources de manière impérative sur la CLI à l’aide de kubectl.
Une application autonome depuis le début grâce à Crossplane pour AWS
Vous avez un cluster ?
Si vous prévoyez de suivre le mouvement, vous aurez besoin d’un cluster. Pour cet article, j’utiliserai un cluster créé par Minikube, fonctionnant sur mon MacBook Pro (mais n’hésitez pas à utiliser un cluster provisionné comme vous le souhaitez). Il est temps d’allumer mon cluster.
➜ ~ démarrage de minikube minikube v1.14.2 sur Darwin 10.15.7 ✨ Utilisation du pilote docker basé sur le profil existant Démarrage du nœud de plan de contrôle minikube dans le cluster minikube Redémarrage du conteneur Docker existant pour « minikube » ... Préparation de Kubernetes v1.19.2 sur Docker 19.03.8 ... Vérification des composants Kubernetes... Modules complémentaires activés : default-storageclass, storage-provisioner Terminé ! kubectl est maintenant configuré pour utiliser « minikube » par défaut
Les petits plus
Sur la base de notre discussion précédente, nous savons que les CRD sont des extensions de Kubernetes de base. Ces extensions sont alimentées par des logiciels supplémentaires qui doivent être installés sur votre cluster. Je ne vais pas couvrir l’installation des CDD AWS de Crossplane ici, car j’ai un script pour installer tous les composants pertinents dans le cadre du déploiement de l’application sur le cluster, mais il convient de mentionner que ces extensions ne sont pas livrées avec une distribution de cluster standard et, quel que soit le contexte, nécessitent généralement une installation et une configuration logicielles supplémentaires pour que tout fonctionne. Dans cet exemple, nous partons d’un cluster local nouvellement installé à partir de Minikube.
AWS CRD de Crossplane est livré en version alpha et bêta. Bien que la version bêta soit plus stable, nous utilisons la version alpha dans cet article, car elle implémente le type de ressource (rubrique SNS) que notre application utilise. Si vous décidez d’utiliser l’un des CD AWS de Crossplane pour votre projet, consultez la page des ressources et déterminez la version du programme d’installation que vous devez utiliser pour vous assurer que vos types de ressources sont implémentés.
Quelle est la suite ?
Dans cet article, nous avons examiné les CRD et ce qui les rend utiles. En examinant l’offre de Crossplane pour le provisionnement des ressources AWS, nous préparons le terrain pour plonger dans notre application et la manière dont nous la déploierons dans notre cluster dans le prochain article.
Découvrez comment Kubernetes peut aider votre entreprise à se moderniser
Notre Kubernetes Launchpad est une solution à fort impact qui aide les équipes d’entreprise à découvrir rapidement les avantages du développement d’applications Cloud natives en déployant rapidement une plateforme DevOps et en replatformant une application sur la plateforme cloud de votre choix : AWS, GCP ou Azure.
