4.4. Operator Lifecycle Manager でのプロキシーサポートの設定
グローバルプロキシーが OpenShift Container Platform クラスターで設定されている場合、Operator Lifecycle Manager (OLM) はクラスター全体のプロキシーで管理する Operator を自動的に設定します。ただし、インストールされた Operator をグローバルプロキシーを上書きするか、またはカスタム CA 証明書を挿入するように設定することもできます。
関連情報
- クラスター全体のプロキシーの設定
- カスタム PKI の設定 (カスタム CA 証明書)
- Go、Ansible、および Helm のプロキシー設定をサポートする Operator の開発
4.4.1. Operator のプロキシー設定の上書き
クラスター全体の egress プロキシーが設定されている場合、Operator Lifecycle Manager (OLM) を使用して実行する Operator は、デプロイメントでクラスター全体のプロキシー設定を継承します。クラスター管理者は、Operator のサブスクリプションを設定してこれらのプロキシー設定を上書きすることもできます。
Operator は、管理対象オペランドの Pod でのプロキシー設定の環境変数の設定を処理する必要があります。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
-
Web コンソールで、Operators
OperatorHub ページに移動します。 - Operator を選択し、Install をクリックします。
Install Operator ページで、
Subscription
オブジェクトを変更して以下の 1 つ以上の環境変数をspec
セクションに組み込みます。-
HTTP_PROXY
-
HTTPS_PROXY
-
NO_PROXY
以下に例を示します。
プロキシー設定の上書きのある
Subscription
オブジェクトapiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: etcd-config-test namespace: openshift-operators spec: config: env: - name: HTTP_PROXY value: test_http - name: HTTPS_PROXY value: test_https - name: NO_PROXY value: test channel: clusterwide-alpha installPlanApproval: Automatic name: etcd source: community-operators sourceNamespace: openshift-marketplace startingCSV: etcdoperator.v0.9.4-clusterwide
注記これらの環境変数については、以前に設定されたクラスター全体またはカスタムプロキシーの設定を削除するために空の値を使用してそれらの設定を解除することもできます。
OLM はこれらの環境変数を単位として処理します。それらの環境変数が 1 つ以上設定されている場合、それらはすべて上書きされているものと見なされ、クラスター全体のデフォルト値はサブスクライブされた Operator のデプロイメントには使用されません。
-
- Install をクリックし、Operator を選択された namespace で利用可能にします。
Operator の CSV が関連する namespace に表示されると、カスタムプロキシーの環境変数がデプロイメントに設定されていることを確認できます。たとえば、CLI を使用します。
$ oc get deployment -n openshift-operators \ etcd-operator -o yaml \ | grep -i "PROXY" -A 2
出力例
- name: HTTP_PROXY value: test_http - name: HTTPS_PROXY value: test_https - name: NO_PROXY value: test image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c ...
4.4.2. カスタム CA 証明書の挿入
クラスター管理者が設定マップを使用してカスタム CA 証明書をクラスターに追加すると、Cluster Network Operator はユーザーによってプロビジョニングされる証明書およびシステム CA 証明書を単一バンドルにマージします。このマージされたバンドルを Operator Lifecycle Manager (OLM) で実行されている Operator に挿入することができます。これは、man-in-the-middle HTTPS プロキシーがある場合に役立ちます。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - 設定マップを使用してクラスターに追加されたカスタム CA 証明書。
- 必要な Operator が OLM にインストールされ、実行される。
手順
Operator のサブスクリプションがある namespace に空の設定マップを作成し、以下のラベルを組み込みます。
apiVersion: v1 kind: ConfigMap metadata: name: trusted-ca 1 labels: config.openshift.io/inject-trusted-cabundle: "true" 2
この設定マップの作成後すぐに、設定マップにはマージされたバンドルの証明書の内容が設定されます。
Subscription
オブジェクトを更新し、trusted-ca
設定マップをカスタム CA を必要とする Pod 内の各コンテナーにボリュームとしてマウントするspec.config
セクションを追加します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: my-operator spec: package: etcd channel: alpha config: 1 selector: matchLabels: <labels_for_pods> 2 volumes: 3 - name: trusted-ca configMap: name: trusted-ca items: - key: ca-bundle.crt 4 path: tls-ca-bundle.pem 5 volumeMounts: 6 - name: trusted-ca mountPath: /etc/pki/ca-trust/extracted/pem readOnly: true
注記Operator のデプロイメントは認証局の検証に失敗し、
x509 certificate signed by unknown authority
エラーが表示される可能性があります。このエラーは、Operator のサブスクリプションの使用時にカスタム CA を挿入した後でも発生する可能性があります。この場合、Operator のサブスクリプションを使用して、trusted-ca のmountPath
を/etc/ssl/certs
として設定できます。