WebLogic Kubernetes Operator (オペレータ)は、人間のオペレータが従来のデータ・センター・デプロイメントに組み込むようなロールを実行するように設計されています。 これには、ドメインで様々なライフサイクル操作を正しく実行する方法に関する一連の有用な組込みの知識が含まれています。
通常、人間のオペレータは、環境の起動と停止、スケーリング操作の実行、障害時リカバリと高可用性のニーズに関連する手動タスクの実行、および他のデータ・センターの他のオペレータとのアクションの調整を担当します。 Kubernetes環境では、オペレータに同様の役割があることが保証されます。
オペレータと管理者の違いに注意することが重要です。 WebLogic Server管理者は、通常、WebLogicドメインの詳細な構成の管理を中心に様々な責任を負います。 オペレータが関心を持つのはドメイン構成のみで、その主な関心はドメインの高レベルのトポロジ(クラスタとサーバーの数、チャネルなどのネットワーク・アクセス・ポイントに関する情報など)です。
人間のオペレータは複数のドメインを管理でき、オペレータは複数のドメインを管理できるように設計されています。 その人間の対応するものと同様に、オペレータは、管理対象として指定されたドメインに対してのみアクションを実行し、同じ環境に存在する可能性のある他のドメインは無視します。
人間のオペレータと同様に、オペレータはイベントベースとして設計されています。 重要なイベントが発生するか、スケジュールされた時間が経過するまで待機してから、適切なアクションを実行します。 重要なイベントの例としては、管理が必要な新しいドメインの認識、WebLogicクラスタのスケール・アップ・リクエストの受信、クラスタの可用性を維持しながらのWebLogic Serverパッチまたはアプリケーションの適用などがあります。
WebLogic Kubernetes Operatorによって現在実装されていない、バックアップの開始などのオペレータ・タスクがあります。 フィードバックや要件があれば、ロードマップを適切に作成するのに役立ちます。
オペレータは、アウト・セットのセキュリティを考慮して設計されています。 次に、特定のセキュリティ・プラクティスの例をいくつか示します:
このオペレータは、KubernetesでのWebLogic Serverの構成または使用方法に任意の制限を課さないように設計されています。 制限がある場合、これらはKubernetesの特定の機能(マルチキャスト・サポートなど)の可用性に基づきます。
オペレータは、ドメインKubernetesリソースおよびクラスタKubernetesリソースのインスタンスを介して、ドメイン内のWebLogicドメインおよびWebLogicクラスタを学習します。 オペレータがインストールされると、ドメイン・リソースの場合はKubernetes 「カスタム・リソース定義」、クラスタ・リソースの場合は別のオペレータが作成されます。 これらのカスタム・リソース定義は、ドメイン・タイプおよびクラスタ・タイプを定義します。 これらのタイプを定義したら、他のリソース・タイプと同様に、kubectlを使用してドメインおよびクラスタを管理できます。 たとえば、kubectl get domainやkubectl edit domain domain1などです。
ドメイン・タイプのスキーマは、できるだけスパースになるように設計されています。 これには管理サーバーの接続詳細が含まれますが、他のすべてのコンテンツは、起動する必要があるサーバーに関する操作の詳細、環境変数、およびKubernetesクラスタの外部に公開する必要があるものに関する詳細です。 同様に、クラスタ・タイプのスキーマも疎であり、多くの場合、値セットは対応するWebLogicクラスタの必要なサイズのみです。 これにより、WebLogicドメインの構成は正規の構成のままになります。