単一のオペレータ・インスタンスは、構成方法に応じて複数のドメインを複数のネームスペースで管理できます。 Kubernetesクラスタは複数のオペレータをホストできますが、ネームスペースごとに1つしかホストできません。
オペレータをインストールする前に、次の前提条件要件が満たされていることを確認してください:
「オペレータの前提条件」を確認して、Kubernetesクラスタがオペレータをサポートしていることを確認します。
サポートされている環境の中には、オペレータに固有の追加のヘルプやサンプルや、制限、特別なチューニング要件、特別なライセンス要件、制限の対象となるものがあることに注意してください。 詳細は、「サポートされている環境」を参照してください。
環境にKubernetesが設定されていない場合は、「Kubernetesの設定」を参照してください。
インストールされていない場合は、Helmをインストールします。 オペレータをインストールするには、KubernetesクラスタにHelmをインストールする必要があります。 オペレータは、Helmを使用して必要なリソースを作成し、そのオペレータをKubernetesクラスタにデプロイします。
すでにHelmが使用可能かどうかを確認するには、helm versionコマンドを試してください。
Helmのインストールの詳細は、「GitHub Helmリポジトリ」を参照してください。
オプションで、Istioを有効にします。
オペレータをインストールする前に、オペレータHelmチャートが使用可能である必要があります。 オペレータのHelmチャートには次のものが含まれます:
チャート・リポジトリを使用して、オペレータのHelmチャートへのアクセスを設定できます。
https://oracle.github.io/weblogic-kubernetes-operator/chartsにあるオペレータHelmチャート・リポジトリまたはユーザーが制御するカスタム・リポジトリを使用します。
https://oracle.github.io/weblogic-kubernetes-operator/chartsリポジトリにアクセスできるようにHelmインストールを設定し、リポジトリ参照にweblogic-operatorという名前を付けるには、次のコマンドhelm repo add <helm-chart-repo-name> <helm-chart-repo-url>を使用します :
$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update
Helmチャート・リポジトリが正しく追加されたか、既存のリポジトリをリストするには:
$ helm repo list
NAME URL
weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts
たとえば、リポジトリにweblogic-operatorという名前を付けた場合、チャートのロケーションを指定するときにHelmコマンドでweblogic-operator/weblogic-operatorを使用するだけです。
Helmチャート・リポジトリからインストールできるオペレータのバージョンをリストするには:
$ helm search repo weblogic-operator/weblogic-operator --versions
helm pullおよびhelm installコマンドを指定したHelmチャートおよびオペレータの指定したバージョンでは、--version <value>オプションを使用して必要なバージョンを選択し、latest値がデフォルトになります。
helm showコマンドを使用して、オペレータHelmチャートでサポートされる構成値およびデフォルト値を確認できます。
$ helm show values weblogic-operator/weblogic-operator
または、./kubernetes/charts/weblogic-operator/values.yamlファイルのオペレータ・ソースで、ほとんどの構成値とそのデフォルトを表示できます。
使用可能な構成値は、オペレータ構成リファレンスの「Helmのオペレータ構成値」セクションでカテゴリ別に説明します。
Helmコマンドの詳細は、「有用なHelm操作」を参照してください。
各オペレータには、ネームスペースの実行およびネームスペース内のKubernetesサービス・アカウントが必要です。 サービス・アカウントは、オペレータのセキュリティ権限をホストするために使用されます。 特定のネームスペースで実行できるオペレータは1つのみです。
オペレータの管理とモニタリングを簡素化するために、Oracleでは次のことを推奨しています:
defaultサービス・アカウントに依存するかわりに、各オペレータ専用のサービス・アカウントを作成します。次に、それぞれの例を示します:
$ kubectl create namespace sample-weblogic-operator-ns
$ kubectl create serviceaccount -n sample-weblogic-operator-ns sample-weblogic-operator-sa
オペレータのインストール・ステップでは、Helmインストール・コマンドラインで--namespace MY-NAMESPACEオペレータのHelmチャート構成設定を使用してネームスペースを指定します。 指定しない場合、デフォルトでdefaultに設定されます。 ネームスペースがまだ存在しない場合は、Helmによって自動的に作成されます(Kubernetesによって、新しいネームスペースにdefaultサービス・アカウントが作成されます)。 後でオペレータをアンインストールした場合、Helmは指定されたネームスペースを削除しません。 これらは、Helmの標準的な動作です。
同様に、Helm installコマンドラインでserviceAccount=MY-SERVICE-ACCOUNTオペレータのHelmチャート構成設定を指定して、オペレータが使用するオペレータのネームスペースにサービス・アカウントを指定します。 指定しない場合、デフォルトでdefaultに設定されます。 オペレータをアンインストールしても、このサービス・アカウントは自動的に削除されません。
オペレータ・イメージは、Kubernetesクラスタのすべてのノードで使用可能である必要があります。
オペレータの様々なサポートされているバージョンの本番対応のオペレータ・イメージは、オペレータ「GitHubコンテナ・レジストリ」に公開されています。 オペレータのGitHubコンテナ・レジストリ・イメージは、ghcr.io/oracle/weblogic-kubernetes-operator:N.N.Nのようなイメージ名を使用して直接参照できます。N.N.Nはオペレータのバージョン、ghcr.ioはGitHubコンテナ・レジストリのDNS名です。 オプションで、独自のオペレータ・イメージをビルドすることもできます。「開発者ガイド」を参照してください。
各Helmチャート・バージョンは、一致するバージョンのオペレータ・イメージを使用してデフォルト設定されます。 オペレータのインストール時に使用されるデフォルトのイメージ名を検索するには、「オペレータのHelmチャートを調べる」を参照し、image値を検索します。 値は、ghcr.io/oracle/weblogic-kubernetes-operator:N.N.Nのようになります。
ほとんどの場合、Kubernetesは必要に応じて、クラスタ・ノードのマシンにオペレータ・イメージを自動的にダウンロード(プル)します。
特定のマシンのコンテナ・イメージ・プールにオペレータ・イメージを手動で配置するか、イメージへのアクセスをテストする場合は、docker pullをコールします。 例えば:
$ docker pull ghcr.io/oracle/weblogic-kubernetes-operator:4.2.8
使用しているイメージ・レジストリがイメージ・プル資格証明を必要とするプライベート・レジストリである場合、docker pullをコールする前にdocker login my-registry-dns-name.comをコールする必要があります。
カスタム・オペレータ・イメージ名またはイメージ・プル・シークレットを指定する場合があります。 たとえば、「デフォルト・オペレータ・イメージ名」とは異なるバージョンをデプロイする場合や、独自のプライベート・イメージ・レジストリにオペレータ・イメージを配置する場合があります。
プライベート・イメージ・レジストリでは、名前の最初の部分がレジストリのDNSのロケーションであり、残りの部分はレジストリ内のイメージのロケーションを指すオペレータに、カスタム・イメージ名を使用する必要があります。 プライベート・イメージ・レジストリでは、セキュリティ資格証明を提供するためにイメージ・プル・レジストリ・シークレットが必要になる場合もあります。
image=オペレータのHelmチャート構成設定を指定します(例:--set "image=my-image-registry.io/my-operator-image:1.0")。imagePullSecretsの指定」の説明に従って、オペレータをデプロイするネームスペースにdocker-registryタイプのKubernetesシークレットを作成します。imagePullSecretsオペレータのHelmチャート構成設定を使用します。 例については、imagePullSecretsを参照してください。 オペレータのインストール時に、kubernetesPlatform Helmチャート構成設定に正しい値を設定することが重要です。
特に、オペレータ・バージョン3.3.2以降では、OpenShift Kubernetesプラットフォームを使用する場合は、オペレータkubernetesPlatform Helmチャート設定を値OpenShiftで指定します(例: --set "kubernetesPlatform=OpenShift")。 これは、OpenShiftセキュリティ要件に対応します。
詳細は、kubernetesPlatformを参照してください。
オペレータのデプロイには、一般的に使用される3つのセキュリティ計画があります:
オペレータのセキュリティ関連リソースの詳細な説明については、オペレータのロールに基づくアクセス制御(RBAC)の要件(「こちら」を参照)を参照してください。
オペレータにネームスペースへのアクセス権限を付与する場合は、ほとんどのユースケースで、オペレータのインストール時にenableClusterRoleBindingオペレータのHelmチャート構成設定をtrueに設定します。
たとえば、--set "enableClusterRoleBinding=true"です。 この設定のデフォルトはtrueです。
最も一般的なセキュリティ戦略です。
オペレータのHelm enableClusterRoleBinding構成値がfalseの場合、オペレータは複数のネームスペースを管理できますが、オペレータのHelmリリースをアップグレードするまで、実行中のオペレータは、そのネームスペース選択基準に一致する新規に追加されたネームスペースを管理する権限を持ちません。 「オペレータにネームスペースを管理する権限があることの確認」を参照してください。
ノート: enableClusterRoleBindingがtrueに設定されておらず、CRDのインストールにはクラスタ・ロール・バインディング権限が必要なため、オペレータCRDを手動でインストールする必要があります。 「ドメイン・リソース・カスタム・リソース定義(CRD)を手動でインストールする方法」を参照してください。
ローカル・ネームスペースのリソースのみにアクセスできるようにオペレータを制限する場合は、次を実行します:
Dedicatedネームスペースの選択方法を選択します。 「ドメイン・ネームスペースの選択方法の選択」を参照してください。 enableClusterRoleBindingがtrueに設定されておらず、CRDをインストールするにはクラスタ・ロール・バインディング権限が必要であるため、オペレータCRDを手動でインストールする必要があります。 「ドメイン・リソース・カスタム・リソース定義(CRD)を手動でインストールする方法」を参照してください。 これは、Dedicatedネームスペース戦略でオペレータを実行するときにOpenShiftプラットフォームで発生する可能性があるなど、オペレータがクラスタ・スコープの権限を持てない環境では必要になる場合があります。
オペレータをインストールする前に、domainNamespaceSelectionStrategy Helmチャート構成設定とその関連設定(ある場合)の値を選択します。 「ドメイン・ネームスペースのセクション戦略の選択」を参照してください。
「セキュリティ方針の選択」を参照してください。
ネームスペース管理の一般的な問題については、「よくある間違いと解決策」を参照してください。 参照方法については、「WebLogicドメイン管理」を参照してください。
オペレータにはインストールにHelmが必要です。Helmでは、インストールされた各オペレータにリリース名を割り当てる必要があります。 Helmリリース名は、異なるネームスペースにデプロイされている場合は同じにできますが、特定のネームスペース内で一意である必要があります。
一般的なHelmリリース名はweblogic-operatorです。 オペレータのサンプルとドキュメントでは、多くの場合sample-weblogic-operatorが使用されます。
「構成リファレンス」の設定で、特定のユース・ケースに適用される可能性がある、あまり使用されていない拡張または微調整のHelmチャート構成オプションを確認します。 これには、ノード・セレクタ、ノード・アフィニティ、Elastic Stack統合、オペレータREST API、オペレータ・ポッド・ラベルの設定、オペレータ・ポッド注釈の設定、およびIstioが含まれます。
該当する場合は、次の特殊なユースケースを確認してください。
上位レベルでは、helm pullを使用してリリースされたバージョンのHelmチャートをダウンロードし、インターネット・アクセスなしでマシンに移動すると、helm installを実行してオペレータをインストールできます。
ステップは次のとおりです。
$ helm pull weblogic-operator --repo https://oracle.github.io/weblogic-kubernetes-operator/charts --destination .
helm pullおよびhelm installが指定されたHelmチャートの指定したバージョンの場合、--version <value>オプションを使用して必要なバージョンを選択し、latest値がデフォルトになります。 Helmチャート・リポジトリからインストールできるオペレータのバージョンをリストするには、次を実行します:
$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update
$ helm search repo weblogic-operator/weblogic-operator --versions
weblogic-operator-<version>.tgzファイルを移動します。$ tar zxf weblogic-operator-<version>.tgzを実行します。 これにより、Helmチャート・ファイルがローカル・ディレクトリ./weblogic-operatorに配置されます。 $ kubectl create namespace weblogic-operatorを実行します。
オペレータの専用ネームスペースの作成は、最も一般的な方法ですが、必ずしも正しいか十分なものではありません。 詳細については、ステップ3から始まる前提条件のステップを参照してください。 「オペレータのHelmチャートを調べる」。 必ず、ステップ10で終わる、前述のすべての前提条件ステップに従ってください。 詳細なオペレータ構成オプションに注意してください。
$ helm install weblogic-operator ./weblogic-operator --namespace weblogic-operatorを実行します。ドメイン・リソース・タイプは、Kubernetes CustomResourceDefinition (CRD)リソースによって定義されます。 ドメインCRDは、オペレータ・ドメイン・リソースのスキーマとともにKubernetesを提供し、オペレータをホストする各KubernetesクラスタにドメインCRDが1つインストールされている必要があります。 同じKubernetesクラスタに複数のオペレータをインストールする場合、すべてのオペレータが同じドメインCRDを共有します。
ドメインCRDを手動でインストールする必要があるのはどのような場合ですか。
通常、オペレータは、オペレータが最初に起動したときに、ドメイン・タイプのCRDを自動的にインストールします。 ただし、オペレータがインストールするのに十分な権限がない場合は、提供されているいずれかのYAMLファイルを使用して、事前にCRDを手動でインストールすることを選択できます。 CRDを事前に手動でインストールすると、(Kubernetesのロールとバインディングを通じて) CRDやその他のクラスタ・スコープのリソースにアクセスまたは更新する権限を付与せずに、オペレータを実行できます。 これは、Dedicatedネームスペース戦略でオペレータを実行するときにOpenShiftなど、オペレータがクラスタ・スコープのセキュリティ権限を持たない環境では必要になる場合があります。 「セキュリティ方針の選択」を参照してください。
ドメインCRDを手動でインストールする方法。
CRDを手動でインストールするには、まず「オペレータのソースをダウンロード」を指定します。
オペレータ・ソースを/tmpディレクトリにインストールしたとします:
$ cd /tmp/weblogic-kubernetes-operator
$ kubectl create -f kubernetes/crd/domain-crd.yaml
ドメインCRDがインストールされているかどうかを確認する方法。
CustomResourceDefinitionがオペレータによってインストールされるか、前のcreateコマンドを使用してインストールされたら、次を使用してCRDが正しくインストールされていることを確認できます:
$ kubectl get crd domains.weblogic.oracle
または、次のようにコールします:
$ kubectl explain domain.spec
kubectl explainコールが成功し、CRDで定義されているドメイン・リソースのdomain.spec属性をリストする必要があります。