4.4. Operator Lifecycle Manager でのプロキシーサポートの設定

グローバルプロキシーが OpenShift Container Platform クラスターで設定されている場合、Operator Lifecycle Manager (OLM) はクラスター全体のプロキシーで管理する Operator を自動的に設定します。ただし、インストールされた Operator をグローバルプロキシーを上書きするか、またはカスタム CA 証明書を挿入するように設定することもできます。

4.4.1. Operator のプロキシー設定の上書き

クラスター全体の egress プロキシーが設定されている場合、Operator Lifecycle Manager (OLM) を使用して実行する Operator は、デプロイメントでクラスター全体のプロキシー設定を継承します。クラスター管理者は、Operator のサブスクリプションを設定してこれらのプロキシー設定を上書きすることもできます。

重要

Operator は、管理対象オペランドの Pod でのプロキシー設定の環境変数の設定を処理する必要があります。

前提条件

  • cluster-admin 権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. Web コンソールで、Operators → OperatorHub ページに移動します。
  2. Operator を選択し、Install をクリックします。
  3. 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 のデプロイメントには使用されません。

  4. Install をクリックし、Operator を選択された namespace で利用可能にします。
  5. 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 にインストールされ、実行される。

手順

  1. Operator のサブスクリプションがある namespace に空の設定マップを作成し、以下のラベルを組み込みます。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: trusted-ca 1
      labels:
        config.openshift.io/inject-trusted-cabundle: "true" 2
    1
    設定マップの名前。
    2
    Cluster Network Operator に対してマージされたバンドルを挿入するように要求します。

    この設定マップの作成後すぐに、設定マップにはマージされたバンドルの証明書の内容が設定されます。

  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
    1
    config セクションがない場合に、これを追加します。
    2
    Operator が所有する Pod に一致するラベルを指定します。
    3
    trusted-ca ボリュームを作成します。
    4
    ca-bundle.crt は設定マップキーとして必要になります。
    5
    tls-ca-bundle.pem は設定マップパスとして必要になります。
    6
    trusted-ca ボリュームマウントを作成します。