Contrôleur Kubernetes vs opérateur Kubernetes?

Question

Comme je comprends le but de la Kubernetes Contrôleur est de faire en sorte que l'état actuel est égal à l'état désiré. Néanmoins, Kubernetes Opérateur effectue le même travail.

La liste de contrôleur de gestion dans le Contrôle de l'avion:

• Déploiement
• ReplicaSet
• StatefulSet
• DaemonSet
• etc

De la Recherche Google, j'ai trouvé qu'il y a K8s des Opérateurs tels que

• etcd Opérateur
• Prometheus Opérateur
• kong Opérateurs

Cependant, je n'étais pas capable de comprendre pourquoi il ne peut être fait à l'aide du Contrôleur?

Est l'Opérateur de compléter les Contrôleurs?

Quelle est la différence entre ces deux design comme un but et fonctionnalité.

Ce que certaines choses à garder à l'esprit pour choisir entre l'automate et l'Opérateur? ?

Answer 1

Je crois que le terme "kubernetes opérateur" a été introduit par le CoreOS gens d'ici

Un Opérateur est une application spécifique de contrôleur qui s'étend de la Kubernetes API pour créer, configurer et gérer des instances de complexe dynamique des applications pour le compte d'un Kubernetes de l'utilisateur. Il s'appuie sur la base Kubernetes de ressources et de contrôleur de concepts, mais comprend également de domaine ou l'application des connaissances spécifiques pour automatiser des tâches courantes mieux gérés par des ordinateurs.

Donc, fondamentalement, un kubernetes opérateur est le nom d'un modèle qui se compose d'un kubernetes contrôleur qui ajoute de nouveaux objets à la Kubernetes API, afin de configurer et de gérer une application, comme Prométhée ou etcd.

En une phrase: un opérateur est un domaine contrôleur spécifique.

Mise à jour

Il y a une nouvelle discussion sur Github sur ce même sujet, un lien vers le même blog. Pertinentes des bribes de la discussion sont les suivants:

Tous les Opérateurs utilisent le modèle de contrôleur, mais pas tous les contrôleurs sont des Opérateurs. C'est seulement un Opérateur s'il y a: modèle de contrôleur de + extension API + une application unique de se concentrer.

L'opérateur est personnalisé contrôleur de mettre en œuvre avec les CRD. Il suit le même modèle avec construire-dans des contrôleurs (c'est à dire regarder, diff, action).

Answer 2

Dans Kubernetes, la plupart des opérations se produire de manière asynchrone.

Par exemple, quand on crée un jeu de réplication de l'objet (la cueillette d'un simple objet), c'est la séquence qui se passe:

1. Nous envoyer la demande à l'hôtel Kube api-serveur.
2. Le kube-api serveur dispose d'un complexe de validation
   • S'assure que l'utilisateur a le RBAC les informations d'identification pour créer la RS dans l'espace de noms donné
   • La demande est validée par l'ensemble des configuré admission contrôleurs
3. Enfin, l'objet est juste écrit pour ETCD - rien de plus rien de moins

Maintenant, il est de la responsabilité des différents Kubernetes contrôleurs de regarder l'ETCD changements et fait exécuter les opérations nécessaires. Dans ce cas, le jeu de réplication du contrôleur serait de le regarder pour que les modifications dans l'ETCD (par exemple CRUD de ReplicataSets) et permettrait de créer les Gousses que par la réplique de comptage etc.

Maintenant, pour les Opérateurs, sur le plan conceptuel, ils sont très similaires à Kubernetes contrôleurs. Mais ils sont utilisés avec des entités tierces. Dans Kubernetes, il y a un concept de la CRDs, où les vendeurs peuvent définir leurs propres CRD qui n'est rien mais une coutume (par exemple, Fournisseur spécifique) kubernetes type d'objet. Très similaire à la manière dont Kubernetes contrôleurs de lire le CRUD de Kubernetes objets, ces opérateurs de répondre aux opérations de l'correspondant à la CRDs. E. g. Kong opérateur peut créer de nouvelles API entrées dans le Kong de l'API serveur lorsqu'une nouvelle API CRD objet est créé dans le Kubernetes cluster.