Le problème des applications avec état dans Kubernetes
La configuration, le lancement et la mise à l'échelle ultérieure des applications et des services sont faciles lorsqu'il s'agit de cas classés comme apatrides, c'est-à-dire sans sauvegarder les données. Il est pratique d'exécuter de tels services dans Kubernetes, en utilisant ses API standard, car tout se passe « prêt à l'emploi » : selon des configurations standard, sans impliquer aucune spécificité ni magie.
En termes simples, pour lancer cinq copies supplémentaires du backend en PHP/Ruby/Python dans un cluster de conteneurs, il vous suffit de configurer 5 fois un nouveau serveur et de copier les sources. Étant donné que le code source et le script d'initialisation sont dans l'image, la mise à l'échelle d'une application sans état devient complètement élémentaire. Comme le savent bien les fans de conteneurs et d’architecture de microservices, la difficulté commence par applications avec état, c'est à dire. avec la persistance des données telles que les bases de données et les caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Cela s'applique aussi bien aux logiciels qui implémentent indépendamment un cluster quorum (par exemple, Percona XtraDB et Cassandra) qu'aux logiciels qui nécessitent des utilitaires de gestion distincts (tels que Redis, MySQL, PostgreSQL...).
Des difficultés surviennent car le code source et le lancement du service ne suffisent plus - vous devez effectuer quelques étapes supplémentaires. Au minimum, copiez les données et/ou rejoignez le cluster. Plus précisément, ces services nécessitent de comprendre comment les faire évoluer, les mettre à jour et les reconfigurer correctement sans perte de données ni indisponibilité temporaire. La prise en compte de ces besoins est appelée « connaissance opérationnelle ».
Opérateurs CoreOS
Afin de « programmer » les connaissances opérationnelles, le projet CoreOS a été lancé en fin d'année dernière « une nouvelle classe de logiciels » pour la plateforme Kubernetes - Opérateurs (de l'anglais « opération », c'est-à-dire « opération »).
Les opérateurs utilisant et étendant les fonctionnalités de base de Kubernetes (incl. Ensembles avec état, voir la différence ci-dessous) permettent aux spécialistes DevOps d'ajouter des connaissances opérationnelles au code de l'application.
Objectif de l'opérateur — fournir à l'utilisateur une API qui vous permet de gérer plusieurs entités d'application avec état dans un cluster Kubernetes, sans penser à ce qu'il y a sous le capot (quelles données et quoi en faire, quelles commandes doivent encore être exécutées pour maintenir le cluster ). En fait, l'Opérateur est conçu pour simplifier autant que possible le travail avec l'application au sein du cluster, en automatisant l'exécution des tâches opérationnelles qui devaient auparavant être résolues manuellement.
Comment fonctionnent les opérateurs
Ensembles de répliques Kubernetes vous permet de spécifier le nombre souhaité de pods en cours d'exécution, et les contrôleurs veillent à ce que leur nombre soit conservé (en créant et en supprimant des pods). Un opérateur fonctionne de la même manière, en ajoutant un ensemble de connaissances opérationnelles à une ressource et un contrôleur Kubernetes standard qui vous permettent d'effectuer des actions supplémentaires pour prendre en charge le nombre requis d'entités d'application.
En quoi est-ce différent de Ensembles avec état, conçu pour les applications qui nécessitent que le cluster leur fournisse des ressources avec état telles que le stockage de données ou des adresses IP statiques ? Pour de telles applications, les opérateurs peuvent utiliser Ensembles avec état (au lieu de Ensembles de répliques) comme base, offrant automatisation supplémentaire: effectuer les actions nécessaires en cas de crash, faire des sauvegardes, mettre à jour la configuration, etc.
ainsi, comment ça marche tout ça ? L'opérateur est un démon gestionnaire qui :
- s'abonne à l'API d'événement dans Kubernetes ;
- en reçoit des données sur le système (sur son Ensembles de répliques, Dosettes, Services et ainsi de suite.);
- reçoit des données sur Ressources tierces (voir exemples ci-dessous);
- réagit à l'apparence/au changement Ressources tierces (par exemple, pour changer la taille, changer la version, etc.) ;
- réagit aux changements d'état du système (à propos de son Ensembles de répliques, Dosettes, Services et ainsi de suite.);
- le plus important:
- fait appel à l'API Kubernetes pour créer tout ce dont il a besoin (encore une fois, son propre Ensembles de répliques, Dosettes, Services...),
- fait de la magie (pour simplifier, on peut penser que l'Opérateur va lui-même dans les pods et appelle des commandes, par exemple, pour rejoindre un cluster ou pour mettre à jour le format des données lors de la mise à jour d'une version).
En fait, comme le montre l'image, une application distincte est simplement ajoutée à Kubernetes (une application standard). Déploiement с Jeu de répliques), appelé Opérateur. Il vit dans un groupe ordinaire (généralement un seul) et, en règle générale, n'est responsable que de son Espace de noms. Cette application opérateur implémente son API - mais pas directement, mais via Ressources tierces dans Kubernetes.
Ainsi, après avoir créé dans Espace de noms Opérateur, nous pouvons y ajouter Ressources tierces.
Exemple pour etcd (voir ci-dessous pour plus de détails):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Exemple pour Elasticsearch :
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Exigences pour les opérateurs
CoreOS a formulé les principaux modèles obtenus par les ingénieurs en travaillant sur les opérateurs. Malgré le fait que tous les opérateurs soient individuels (créés pour une application spécifique avec ses propres caractéristiques et besoins), leur création doit être basée sur une sorte de cadre qui impose les exigences suivantes :
- L'installation doit être effectuée via un seul Déploiement: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - et ne nécessitent pas d'actions supplémentaires.
- Lors de l'installation d'un opérateur dans Kubernetes, un nouveau type tiers doit être créé (Ressource tierce). Pour lancer des instances d'application (instances de cluster) et les gérer davantage (mise à jour des versions, redimensionnement, etc.), l'utilisateur utilisera ce type.
- Dans la mesure du possible, vous devez utiliser les primitives intégrées à Kubernetes, telles que Services и Ensembles de répliquesutiliser un code bien testé et compréhensible.
- Nécessite une compatibilité descendante des opérateurs et la prise en charge des anciennes versions des ressources créées par l'utilisateur.
- Si l'opérateur est supprimé, l'application elle-même devrait continuer à fonctionner sans modification.
- Les utilisateurs doivent être capables de définir la version de l'application souhaitée et d'orchestrer les mises à jour de la version de l'application. Le manque de mises à jour logicielles est une source courante de problèmes opérationnels et de sécurité, les opérateurs doivent donc aider les utilisateurs dans ce domaine.
- Les opérateurs doivent être testés avec un outil comme Chaos Monkey, qui identifie les pannes potentielles dans les pods, les configurations et le réseau.
Opérateur etcd
Exemple d'implémentation d'opérateur - Opérateur etcd, le jour de l'annonce de ce concept. La configuration du cluster etcd peut être complexe en raison de la nécessité de maintenir le quorum, de la nécessité de reconfigurer l'adhésion au cluster, de créer des sauvegardes, etc. Par exemple, la mise à l'échelle manuelle d'un cluster etcd signifie que vous devez créer un nom DNS pour un nouveau membre du cluster, démarrer une nouvelle entité etcd et alerter le cluster du nouveau membre (Ajout d'un membre etcdctl). Dans le cas de l'opérateur, l'utilisateur n'aura qu'à modifier la taille du cluster - tout le reste se fera automatiquement.
Et comme etcd a également été créé dans CoreOS, il était assez logique de voir son Opérateur apparaître en premier. Comment travaille-t-il ? Logique de l'opérateur, etc. est déterminé par trois éléments :
- Observer. L'opérateur surveille l'état du cluster à l'aide de l'API Kubernetes.
- Analyse. Recherche les différences entre l'état actuel et celui souhaité (défini par la configuration utilisateur).
- Action. Résout les différences détectées à l’aide des API du service etcd et/ou Kubernetes.
Pour mettre en œuvre cette logique, des fonctions ont été préparées dans l'Opérateur Créer/Détruire (création et suppression de membres du cluster etcd) et "Resize" (changement du nombre de membres du cluster). L'exactitude de son fonctionnement a été vérifiée à l'aide d'un utilitaire créé à l'image de Chaos Monkey de Netflix, c'est-à-dire tuer les pods etcd au hasard.
Pour un fonctionnement complet d'etcd, l'opérateur fournit des fonctionnalités supplémentaires : sauvegarde (création automatique et invisible pour les utilisateurs de copies de sauvegarde - dans la configuration, il suffit de déterminer à quelle fréquence les réaliser et combien les stocker - et restauration ultérieure des données à partir de celles-ci) et Optimisation (mise à jour des installations etcd sans temps d'arrêt).
À quoi ressemble le travail avec un opérateur ?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
L'état actuel d'etcd Operator est une version bêta, nécessitant l'exécution de Kubernetes 1.5.3+ et etcd 3.0+. Le code source et la documentation (y compris les instructions d'utilisation) sont disponibles sur .
Un autre exemple d'implémentation de CoreOS a été créé - , mais il est encore en version alpha (toutes les fonctionnalités prévues n'ont pas été implémentées).
Statut et perspectives
5 mois se sont écoulés depuis l'annonce des opérateurs Kubernetes. Il n'y a encore que deux implémentations disponibles dans le référentiel officiel CoreOS (pour etcd et Prometheus). Les deux n’ont pas encore atteint leur version stable, mais des commits sont observés quotidiennement.
Les développeurs envisagent « un avenir dans lequel les utilisateurs installeront des opérateurs Postgres, des opérateurs Cassandra ou des opérateurs Redis sur leurs clusters Kubernetes et travailleront avec les entités évolutives de ces applications aussi facilement que le déploiement de répliques d'applications Web sans état l'est aujourd'hui ». D'abord Opérateurs de développeurs tiers a vraiment commencé à apparaître :
- des Entreprises UPMC ;
- de Crunchy Data (annoncé fin mars 2017) ;
- des auteurs d'un système de stockage de données distribué basé sur Ceph (Rook est en statut alpha) ;
- à partir de SAP CCloud.
Lors de la plus grande conférence européenne sur le logiciel libre FOSDEM, qui a eu lieu en février 2017 à Bruxelles, Josh Wood de CoreOS a annoncé les opérateurs en (une vidéo est disponible sur le lien !), ce qui devrait contribuer à la popularité croissante de ce concept dans la communauté Open Source au sens large.
PS Merci de votre intérêt pour l'article ! Abonnez-vous à notre hub, pour ne pas manquer de nouveaux matériels et recettes sur l'administration système DevOps et GNU/Linux - nous les publierons régulièrement !
Source: habr.com