Kubernetes Controller対Kubernetes Operator？
私が理解しているように、Kubernetesコントローラーの目的は、現在の状態が目的の状態に等しいことを確認することです。それでも、Kubernetes Operatorは同じ仕事をします。
コントロールプレーンのコントローラーのリスト：
- 展開
- ReplicaSet
- StatefulSet
- デーモンセット
- 等
Google検索から、次のようなK8オペレーターがあることがわかりました。
- etcd演算子
- プロメテウス演算子
- kong演算子
しかし、なぜControllerを使用してできないのか理解できませんでしたか？
オペレーターはコントローラーを補完していますか？
目的と機能としてのこれら2つの設計の違いは何ですか。
コントローラーとオペレーターのいずれかを選択するために留意すべき特定の事項は何ですか？ ？
「kubernetesオペレータ」という用語は CoreOSの人々 によって導入されたと思います
オペレーターは、Kubernetes APIを拡張して、Kubernetesユーザーに代わって複雑なステートフルアプリケーションのインスタンスを作成、構成、管理するアプリケーション固有のコントローラーです。 Kubernetesの基本的なリソースとコントローラーの概念に基づいて構築されていますが、ドメインまたはアプリケーション固有の知識も含まれており、コンピューターで管理しやすい一般的なタスクを自動化します。
基本的に、kubernetesオペレーターは、Prometheusやetcdなどのアプリケーションを構成および管理するために、Kubernetes APIに新しいオブジェクトを追加するkubernetesコントローラーで構成されるパターンの名前です。
一文で：オペレーターはドメイン固有のコントローラーです。
更新
Githubでの新しい議論 この同じトピックについて、同じブログ投稿にリンクしています。議論の関連部分は次のとおりです。
すべてのオペレーターがコントローラーパターンを使用しますが、すべてのコントローラーがオペレーターではありません。コントローラーパターン+ API拡張機能+シングルアプリフォーカスを取得している場合は、オペレーターのみです。
オペレーターは、CRDを備えたカスタマイズされたコントローラーの実装です。組み込みのコントローラー（ウォッチ、差分、アクション）でも同じパターンに従います。
Kubernetesでは、ほとんどの操作は非同期で行われます。
たとえば、ReplicaSetオブジェクトを作成する（より単純なオブジェクトを選択する）場合、これは発生するシーケンスです。
- Kube api-serverにリクエストを送信します。
- Kube-apiサーバーには複雑な検証があります
- 指定された名前空間にRSを作成するためのRBAC資格情報がユーザーにあることを確認します
- 要求は、構成されたすべてのアドミッションコントローラーによって検証されます
- 最後にオブジェクトはETCDに書き込まれます-これ以上のことは何もありません
現在、ETCDの変更を監視し、実際に必要な操作を実行するのは、さまざまなKubernetesコントローラーの責任です。この場合、ReplicatSetコントローラーはETCDの変更（ReplicataSetsのCRUDなど）を監視し、レプリカ数などに従ってPodを作成します。
今、オペレーターに来て、概念的にそれらはKubernetesコントローラーに非常に似ています。ただし、サードパーティのエンティティで使用されます。 Kubernetesには、ベンダーがカスタム（ベンダー固有の）kubernetesオブジェクトタイプ以外の独自のCRDを定義できるCRDの概念があります。 KubernetesコントローラーがKubernetesオブジェクトのCRUDを読み取る方法と非常に似ており、これらのオペレーターは対応するCRDの操作に応答します。例えば。 Kongオペレーターは、Kubernetesクラスターで新しいAPI CRDオブジェクトが作成されると、Kong APIサーバーで新しいAPIエントリを作成できます。