Was ist der Unterschied zwischen einem Kubernetes-Controller und einem Kubernetes-Operator?

Soweit ich weiß, besteht der Zweck des Kubernetes-Controllers darin, sicherzustellen, dass der aktuelle Status dem gewünschten Status entspricht. Trotzdem erledigt Kubernetes Operator den gleichen Job.

Die Liste der Controller in der Steuerebene:

• Einsatz
• ReplicaSet
• StatefulSet
• DaemonSet
• usw

In der Google-Suche habe ich herausgefunden, dass es K8-Operatoren wie z

• etcd Operator
• Prometheus-Betreiber
• Kong-Betreiber

Ich konnte jedoch nicht verstehen, warum dies nicht mit Controller möglich ist.

Ergänzt der Betreiber die Steuerungen?

Was ist der Unterschied zwischen diesen beiden Design als Zweck und Funktionalität.

Welche bestimmten Dinge müssen beachtet werden, um zwischen Controller und Operator zu wählen? ?

Ich glaube, der Begriff "kubernetes operator" wurde von den CoreOS-Leuten hier eingeführt

Ein Operator ist ein anwendungsspezifischer Controller, der die Kubernetes-API erweitert, um Instanzen komplexer Stateful-Anwendungen im Auftrag eines Kubernetes-Benutzers zu erstellen, zu konfigurieren und zu verwalten. Es baut auf den grundlegenden Ressourcen- und Controller-Konzepten von Kubernetes auf, enthält jedoch auch domänen- oder anwendungsspezifisches Wissen, um allgemeine Aufgaben zu automatisieren, die besser von Computern verwaltet werden.

Ein Kubernetes-Operator ist also im Grunde der Name eines Musters, das aus einem Kubernetes-Controller besteht, der der Kubernetes-API neue Objekte hinzufügt, um eine Anwendung wie Prometheus oder etcd zu konfigurieren und zu verwalten.

In einem Satz: Ein Operator ist ein domänenspezifischer Controller.

Aktualisieren

Auf Github gibt es eine neue Diskussion zu demselben Thema, die auf denselben Blog-Beitrag verweist. Relevante Teile der Diskussion sind:

Alle Operatoren verwenden das Controller-Muster, aber nicht alle Controller sind Operatoren. Es ist nur ein Operator, wenn es Folgendes hat: Controller-Muster + API-Erweiterung + Fokus auf eine einzelne App.

Operator ist eine angepasste Steuerung, die mit CRD implementiert ist. Es folgt dem gleichen Muster wie eingebaute Controller (dh Uhr, Diff, Aktion).

Update 2

Ich habe einen neuen Blog-Beitrag gefunden , der versucht, den Unterschied ebenfalls zu erklären.

In Kubernetes werden die meisten Vorgänge asynchron ausgeführt.

Wenn Sie beispielsweise ein ReplicaSet-Objekt erstellen (ein einfacheres Objekt auswählen), geschieht Folgendes:

1. Wir senden die Anfrage an den Kube API-Server.
2. Der kube-api-Server verfügt über eine komplexe Validierung
   • Stellt sicher, dass der Benutzer über die RBAC-Anmeldeinformationen verfügt, um die RS im angegebenen Namespace zu erstellen
   • Die Anfrage wird von allen konfigurierten Zulassungscontrollern validiert
3. Schließlich wird das Objekt nur in ETCD geschrieben - nicht mehr und nicht weniger

Jetzt liegt es in der Verantwortung der verschiedenen Kubernetes-Controller, die ETCD-Änderungen zu überwachen und die erforderlichen Vorgänge tatsächlich auszuführen. In diesem Fall würde der ReplicaSet-Controller nach Änderungen in ETCD suchen (z. B. CRUD von ReplicataSets) und die Pods gemäß der Anzahl der Replikate usw. erstellen.

Nun zu den Operatoren: Konzeptionell sind sie den Kubernetes-Controllern sehr ähnlich. Sie werden jedoch mit Drittanbietern verwendet. In Kubernetes gibt es ein Konzept von CRDs, bei dem Anbieter ihre eigene CRD definieren können, die nichts anderes als ein benutzerdefinierter (z. B. herstellerspezifischer) Kubernetes-Objekttyp ist. Diese Operatoren sind der Art und Weise, wie Kubernetes-Controller in die CRUD von Kubernetes-Objekten lesen, sehr ähnlich und reagieren auf die Operationen auf den entsprechenden CRDs. Beispielsweise kann der Kong-Operator neue API-Einträge auf dem Kong-API-Server erstellen, wenn ein neues API-CRD-Objekt im Kubernetes-Cluster erstellt wird.