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


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

  • GoAnsible、および Helm のプロキシー設定をサポートする Operator の開発

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

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

重要

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

前提条件

  • dedicated-admin ロールを持つユーザーとして OpenShift Dedicated クラスターにアクセスできる。

手順

  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 証明書の挿入

dedicated-admin ロールを持つ管理者が config map を使用してカスタム CA 証明書をクラスターに追加すると、Cluster Network Operator がユーザー提供の証明書とシステム CA 証明書を 1 つのバンドルにマージします。このマージされたバンドルを Operator Lifecycle Manager (OLM) で実行されている Operator に挿入することができます。これは、man-in-the-middle HTTPS プロキシーがある場合に役立ちます。

前提条件

  • dedicated-admin ロールを持つユーザーとして OpenShift Dedicated クラスターにアクセスできる。
  • 設定マップを使用してクラスターに追加されたカスタム 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 ボリュームマウントを作成します。
    注記

    Operator のデプロイメントは認証局の検証に失敗し、x509 certificate signed by unknown authority エラーが表示される可能性があります。このエラーは、Operator のサブスクリプションの使用時にカスタム CA を挿入した後でも発生する可能性があります。この場合、Operator のサブスクリプションを使用して、trusted-ca の mountPath/etc/ssl/certs として設定できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.