ネットワーク Operator


OpenShift Container Platform 4.19

OpenShift Container Platform におけるネットワーク固有の Operator の管理

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform におけるさまざまなネットワーク関連 Operator のインストール、設定、管理を説明します。

第1章 Kubernetes NMState Operator

Kubernetes NMState Operator は、NMState の OpenShift Container Platform クラスターのノード間でステートドリブンのネットワーク設定を実行するための Kubernetes API を提供します。Kubernetes NMState Operator は、ユーザーに対して、クラスターノードの各種のネットワークインターフェイスタイプ、DNS、およびルーティングを設定する機能を提供します。さらに、クラスターノードのデーモンは、各ノードの API サーバーへのネットワークインターフェイスの状態の定期的な報告を行います。

重要

Red Hat は、ベアメタル、IBM Power®、IBM Z®、IBM® LinuxONE、VMware vSphere、および Red Hat OpenStack Platform (RHOSP) インストール上の実稼働環境で Kubernetes NMState Operator をサポートしています。

Red Hat では、Microsoft Azure 上で Kubernetes NMState Operator を使用するためのサポートが提供されていますが、その機能は限られています。サポートは、インストール後のタスクとしてシステム上の DNS サーバーを設定することに限定されています。

OpenShift Container Platform で NMState を使用する前に、Kubernetes NMState Operator をインストールする必要があります。Kubernetes NMState Operator をインストールしたら、次のタスクを完了できます。

  • ノードのネットワーク状態と設定の監視と更新
  • カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成

これらのタスクの詳細は、関連情報 セクションを参照してください。

注記

Kubernetes NMState Operator は、セカンダリー NIC のネットワーク設定を更新します。Operator は、プライマリー NIC のネットワーク設定を更新したり、ほとんどのオンプレミスネットワーク上の br-ex ブリッジを更新したりすることはできません。

ベアメタルプラットフォームでは、Kubernetes NMState Operator を使用して br-ex ブリッジネットワーク設定を更新することは、マシン設定マニフェストファイルで br-ex ブリッジをインターフェイスとして設定した場合にのみサポートされます。br-ex ブリッジをインストール後のタスクとして更新するには、クラスターの NodeNetworkConfigurationPolicy カスタムリソース (CR) の NMState 設定で、br-ex ブリッジをインターフェイスとして設定する必要があります。詳細は、インストール後の設定カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成 を参照してください。

OpenShift Container Platform は nmstate を使用して、ノードネットワークの状態を報告し、これを設定します。これにより、たとえばすべてのノードに Linux ブリッジを作成するなど、単一の設定マニフェストをクラスターに適用して、ネットワークポリシー設定を変更できるようになります。

ノードのネットワークは、以下のオブジェクトによって監視され更新されます。

NodeNetworkState
そのノード上のネットワークの状態を報告します。
NodeNetworkConfigurationPolicy
ノードで要求されるネットワーク設定を説明します。NodeNetworkConfigurationPolicy CR をクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。
NodeNetworkConfigurationEnactment
各ノードに制定されたネットワークポリシーを報告します。

1.1. Kubernetes NMState Operator のインストール

ウェブコンソールまたは CLI を使用して、Kubernetes NMState Operator をインストールできます。

1.1.1. Web コンソールを使用した Kubernetes NMState Operator のインストール

Web コンソールを使用して Kubernetes NMState Operator をインストールできます。Kubernetes NMState Operator をインストールすると、Operator によって NMState State Controller がすべてのクラスターノードにデーモンセットとしてデプロイされます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OperatorsOperatorHub を選択します。
  2. All Items の下の検索フィールドに、nmstate と入力し、Enter をクリックして Kubernetes NMState Operator を検索します。
  3. Kubernetes NMState Operator の検索結果をクリックします。
  4. Install をクリックして、Install Operator ウィンドウを開きます。
  5. Install をクリックして Operator をインストールします。
  6. Operator のインストールが完了したら、View Operator をクリックします。
  7. Provided APIsCreate Instance をクリックし、kubernetes-nmstate のインスタンスを作成するダイアログボックスを開きます。
  8. ダイアログボックスの Name フィールドで、インスタンスの名前が nmstate であることを確認します。

    注記

    名前の制限は既知の問題です。インスタンスはクラスター全体のシングルトンです。

  9. デフォルト設定を受け入れ、Create をクリックしてインスタンスを作成します。

1.1.2. CLI を使用した Kubernetes NMState Operator のインストール

OpenShift CLI (oc) を使用して、Kubernetes NMState Operator をインストールできます。インストールが完了すると、Operator はすべてのクラスターノードに NMState State Controller をデーモンセットとしてデプロイできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. nmstate Operator namespace を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-nmstate
    spec:
      finalizers:
      - kubernetes
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-nmstate
      namespace: openshift-nmstate
    spec:
      targetNamespaces:
      - openshift-nmstate
    EOF
    Copy to Clipboard Toggle word wrap
  3. nmstate Operator にサブスクライブします。

    $ cat << EOF| oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: kubernetes-nmstate-operator
      namespace: openshift-nmstate
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: kubernetes-nmstate-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap
  4. nmstate Operator デプロイメントの ClusterServiceVersion (CSV) ステータスが Succeeded であることを確認します。

    $ oc get clusterserviceversion -n openshift-nmstate \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap
  5. nmstate Operator のインスタンスを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: nmstate.io/v1
    kind: NMState
    metadata:
      name: nmstate
    EOF
    Copy to Clipboard Toggle word wrap
  6. DNS 接続の問題が原因でクラスターで DNS ヘルスチェックプローブに問題がある場合は、次の DNS ホスト名設定を NMState CRD に追加して、これらの問題を解決できるヘルスチェックを組み込むことができます。

    apiVersion: nmstate.io/v1
    kind: NMState
    metadata:
      name: nmstate
    spec:
      probeConfiguration:
        dns:
          host: redhat.com
    # ...
    Copy to Clipboard Toggle word wrap
    1. 次のコマンドを実行して、DNS ホスト名の設定をクラスターネットワークに適用します。<filename> は、CRD ファイルの名前に置き換えます。

      $ oc apply -f <filename>.yaml
      Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを入力して、NMState Operator のすべての Pod のステータスが Running であることを確認します。

    $ oc get pod -n openshift-nmstate
    Copy to Clipboard Toggle word wrap

1.1.3. Kubernetes NMState Operator によって収集されたメトリクスの表示

Kubernetes NMState Operator である kubernetes-nmstate-operator は、kubernetes_nmstate_features_applied コンポーネントからメトリクスを収集し、すぐに使用できるメトリクスとして公開できます。メトリクスを表示するユースケースとして、NodeNetworkConfigurationPolicy カスタムリソースを作成し、そのポリシーがアクティブであることを確認する状況を考えてみましょう。

注記

kubernetes_nmstate_features_applied メトリクスは API ではないため、OpenShift Container Platform のバージョン間で変更になる可能性があります。

Web コンソールのメトリクス UI には、選択したプロジェクトの定義済み CPU、メモリー、帯域幅、およびネットワークパケットクエリーがいくつか含まれています。プロジェクトの CPU、メモリー、帯域幅、ネットワークパケット、およびアプリケーションメトリクスにカスタム Prometheus Query Language (PromQL) クエリーを実行できます。

次の例は、OpenShift Container Platform クラスターに適用される NodeNetworkConfigurationPolicy マニフェストの例を示しています。

# ...
interfaces:
  - name: br1
    type: linux-bridge
    state: up
    ipv4:
      enabled: true
      dhcp: true
      dhcp-custom-hostname: foo
    bridge:
      options:
        stp:
          enabled: false
      port: []
# ...
Copy to Clipboard Toggle word wrap

NodeNetworkConfigurationPolicy マニフェストはメトリクスを公開し、Cluster Monitoring Operator (CMO) が利用できるようにします。次の例は、公開されたメトリクスの一部を示しています。

controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.005"} 16
controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.01"} 16
controller_runtime_reconcile_time_seconds_bucket{controller="nodenetworkconfigurationenactment",le="0.025"} 16
...
# HELP kubernetes_nmstate_features_applied Number of nmstate features applied labeled by its name
# TYPE kubernetes_nmstate_features_applied gauge
kubernetes_nmstate_features_applied{name="dhcpv4-custom-hostname"} 1
Copy to Clipboard Toggle word wrap

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者として Web コンソールにログインし、Kubernetes NMState Operator をインストールしている。
  • 開発者として、またはメトリクスで表示しているプロジェクトの表示権限を持つユーザーとしてクラスターへのアクセスがある。
  • ユーザー定義プロジェクトのモニタリングが有効化されている。
  • ユーザー定義プロジェクトにサービスをデプロイしている。
  • NodeNetworkConfigurationPolicy マニフェストを作成し、クラスターに適用している。
重要

OpenShift Container Platform 4.19 以降、Web コンソールのパースペクティブが統合されました。Developer パースペクティブは、デフォルトでは有効になっていません。

すべてのユーザーは、OpenShift Container Platform Web コンソールのすべての機能を操作できます。ただし、クラスターの所有者でない場合は、特定の機能にアクセスする権限をクラスターの所有者に要求する必要がある場合があります。

引き続き Developer パースペクティブを有効にできます。Web コンソールの Getting Started ペインでは、コンソールツアーの実行、クラスター設定に関する情報の検索、Developer パースペクティブを有効にするためのクイックスタートの表示、リンク先を表示して新機能の確認などを行えます。

手順

  1. OpenShift Container Platform Web コンソールの Developer パースペクティブからメトリクスを表示する場合は、次のタスクを実行します。

    1. Observe をクリックします。
    2. 特定のプロジェクトのメトリクスを表示するには、Project: リストでプロジェクトを選択します。たとえば、openshift-nmstate です。
    3. Metrics タブをクリックします。
    4. プロット上のメトリクスを視覚化するには、Select query リストからクエリーを選択するか、Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。

      注記

      開発者ロールでは 1 度に 1 つのクエリーのみ実行できます。

  2. 管理者として OpenShift Container Platform Web コンソールでメトリクスを表示する場合は、以下のタスクを実行します。

    1. ObserveMetrics をクリックします。
    2. Expression フィールドに kubernetes_nmstate_features_applied と入力します。
    3. Add query をクリックし、Run queries をクリックします。
  3. 視覚化されたメトリクスを調べるには、次のいずれかのタスクを実行します。

    1. プロットを拡大して時間範囲を変更するには、次のいずれかのタスクを実行します。

      • 時間範囲を視覚的に選択するには、プロットをクリックして水平にドラッグします。
      • 時間範囲を選択するには、コンソールの左上にあるメニューを使用します。
    2. 時間の範囲をリセットするには、Reset zoom を選択します。
    3. 特定の時点におけるすべてのクエリーの出力を表示するには、その時点でプロット上にマウスカーソルを置きます。クエリー出力がポップアップボックスに表示されます。

1.2. Kubernetes NMState Operator のアンインストール

Operator Lifecycle Manager (OLM) を使用して Kubernetes NMState Operator をアンインストールできますが、設計上、OLM は関連付けられているカスタムリソース定義 (CRD)、カスタムリソース (CR)、API サービスを削除しません。

OLM が使用する Subcription リソースから Kubernetes NMState Operator をアンインストールする前に、削除する Kubernetes NMState Operator リソースを特定します。そうすることで、実行中のクラスターに影響を与えることなくリソースを削除できます。

Kubernetes NMState Operator を再インストールする必要がある場合は、「CLI を使用した Kubernetes NMState Operator のインストール」または「Web コンソールを使用した Kubernetes NMState Operator のインストール」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • jq CLI ツールがインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを実行して、Subcription リソースに対する Kubernetes NMState Operator のサブスクリプションを解除します。

    $ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
    Copy to Clipboard Toggle word wrap
  2. Kubernetes NMState Operator に関連付けられている ClusterServiceVersion (CSV) リソースを見つけます。

    $ oc get --namespace openshift-nmstate clusterserviceversion
    Copy to Clipboard Toggle word wrap

    CSV リソースをリストする出力例

    NAME                              	  DISPLAY                   	VERSION   REPLACES     PHASE
    kubernetes-nmstate-operator.v4.19.0   Kubernetes NMState Operator   4.19.0           	   Succeeded
    Copy to Clipboard Toggle word wrap

  3. CSV リソースを削除します。ファイルを削除すると、OLM は Operator 用に作成した RBAC などの特定リソースを削除します。

    $ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.19.0
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、nmstate CR と関連する Deployment リソースを削除します。

    $ oc -n openshift-nmstate delete nmstate nmstate
    Copy to Clipboard Toggle word wrap
    $ oc delete --all deployments --namespace=openshift-nmstate
    Copy to Clipboard Toggle word wrap
  5. nmstate CR を削除した後、console.operator.openshift.io/cluster CR から nmstate-console-plugin コンソールプラグイン名を削除します。

    1. 次のコマンドを実行して、有効なプラグインのリスト内に存在する nmstate-console-plugin エントリーの位置を保存します。次のコマンドは、jq CLI ツールを使用して、エントリーのインデックスを INDEX という名前の環境変数に保存します。

      INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
      Copy to Clipboard Toggle word wrap
    2. 次のパッチコマンドを実行して、console.operator.openshift.io/cluster CR から nmstate-console-plugin エントリーを削除します。

      $ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]" 
      1
      Copy to Clipboard Toggle word wrap
      1
      INDEX は補助変数です。この変数には別の名前を指定できます。
  6. 次のコマンドを実行して、nmstates.nmstate.io などのカスタムリソース定義 (CRD) をすべて削除します。

    $ oc delete crd nmstates.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkconfigurationenactments.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkstates.nmstate.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd nodenetworkconfigurationpolicies.nmstate.io
    Copy to Clipboard Toggle word wrap
  7. namespace を削除します。

    $ oc delete namespace kubernetes-nmstate
    Copy to Clipboard Toggle word wrap

第2章 AWS Load Balancer Operator

2.1. AWS Load Balancer Operator リリースノート

AWS Load Balancer (ALB) Operator は、AWSLoadBalancerController リソースのインスタンスをデプロイおよび管理します。

重要

AWS Load Balancer (ALB) Operator は、x86_64 アーキテクチャーでのみサポートされます。

これらのリリースノートは、OpenShift Container Platform での AWS Load Balancer Operator の開発を追跡します。

AWS Load Balancer Operator の概要は、OpenShift Container Platform の AWS Load Balancer Operator を参照してください。

注記

AWS Load Balancer Operator は現在、AWS GovCloud をサポートしていません。

2.1.1. AWS Load Balancer Operator 1.2.0

AWS Load Balancer Operator バージョン 1.2.0 では、以下のアドバイザリーを利用できます。

2.1.1.1. 大きな変更
  • このリリースでは、AWS Load Balancer Controller バージョン 2.8.2 がサポートされています。
  • このリリースでは、Infrastructure リソースで定義されたプラットフォームタグが、コントローラーによって作成されたすべての AWS オブジェクトに追加されるようになりました。

2.1.2. AWS Load Balancer Operator 1.1.1

AWS Load Balancer Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。

2.1.3. AWS Load Balancer Operator 1.1.0

AWS Load Balancer Operator バージョン 1.1.0 は、AWS Load Balancer Controller バージョン 2.4.4 をサポートします。

AWS Load Balancer Operator バージョン 1.1.0 では、以下のアドバイザリーを利用できます。

2.1.3.1. 大きな変更
  • このリリースでは、Kubernetes API バージョン 0.27.2 を使用します。
2.1.3.2. 新機能
  • AWS Load Balancer Operator は、Cloud Credential Operator を使用して標準化された Security Token Service (STS) フローをサポートするようになりました。
2.1.3.3. バグ修正
  • FIPS 準拠のクラスターでは、TLS バージョン 1.2 を使用する必要があります。以前は、AWS Load Balancer Controller の Webhook は最小バージョンとして TLS 1.3 のみを受け入れていたため、FIPS 準拠のクラスターで次のようなエラーが発生しました。

    remote error: tls: protocol version not supported
    Copy to Clipboard Toggle word wrap

    現在、AWS Load Balancer Controller は TLS 1.2 を最小 TLS バージョンとして受け入れ、この問題は解決されています。(OCPBUGS-14846)

2.1.4. AWS Load Balancer Operator 1.0.1

AWS Load Balancer Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。

2.1.5. AWS Load Balancer Operator 1.0.0

このリリースで、AWS Load Balancer Operator の一般提供が開始されました。AWS Load Balancer Operator バージョン 1.0.0 は、AWS Load Balancer Controller バージョン 2.4.4 をサポートします。

AWS Load Balancer Operator バージョン 1.0.0 では、以下のアドバイザリーを利用できます。

重要

AWS Load Balancer (ALB) Operator バージョン 1.x.x は、テクノロジープレビューバージョン 0.x.x から自動的にアップグレードできません。以前のバージョンからアップグレードするには、ALB オペランドをアンインストールし、aws-load-balancer-operator namespace を削除する必要があります。

2.1.5.1. 大きな変更
  • このリリースでは、新しい v1 API バージョンを使用しています。
2.1.5.2. バグ修正
  • 以前のバージョンでは、AWS Load Balancer Operator によってプロビジョニングされたコントローラーは、クラスター全体のプロキシー設定を適切に使用しませんでした。これらの設定は、コントローラーに正しく適用されるようになりました。(OCPBUGS-4052OCPBUGS-5295)

2.1.6. 以前のバージョン

AWS Load Balancer Operator の最初の 2 つのバージョンは、テクノロジープレビュー機能として利用できます。これらのバージョンは、実稼働クラスターで使用しないでください。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

AWS Load Balancer Operator バージョン 0.2.0 では、以下のアドバイザリーを利用できます。

AWS Load Balancer Operator バージョン 0.0.1 では、以下のアドバイザリーを利用できます。

2.2. OpenShift Container Platform の AWS Load Balancer Operator

AWS Load Balancer Operator は、AWS Load Balancer Controller をデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から AWS Load Balancer Operator をインストールできます。

2.2.1. AWS Load Balancer Operator に関する考慮事項

AWS Load Balancer Operator をインストールして使用する前に、次の制限事項を確認してください。

  • IP トラフィックモードは、AWS Elastic Kubernetes Service (EKS) でのみ機能します。AWS Load Balancer Operator は、AWS Load Balancer Controller の IP トラフィックモードを無効にします。IP トラフィックモードを無効にすると、AWS Load Balancer Controller は Pod readiness ゲートを使用できません。
  • AWS Load Balancer Operator は --disable-ingress-class-annotation--disable-ingress-group-name-annotation などのコマンドラインフラグを AWS Load Balancer Controller に追加します。したがって、AWS Load Balancer Operator では、Ingress リソースで kubernetes.io/ingress.class および alb.ingress.kubernetes.io/group.name アノテーションを使用できません。
  • SVC タイプが NodePort (LoadBalancerClusterIP ではない) になるように AWS Load Balancer Operator を設定しておくようにしてください。

2.2.2. AWS Load Balancer Operator

AWS Load Balancer Operator は kubernetes.io/role/elb タグがない場合に、パブリックサブネットにタグを付けることができます。また、AWS Load Balancer Operator は、基盤となる AWS クラウドから次の情報を検出します。

  • Operator をホストするクラスターがデプロイされる Virtual Private Cloud (VPC) の ID。
  • 検出された VPC のパブリックおよびプライベートサブネット。

AWS Load Balancer Operator は、インスタンス ターゲットタイプのみで Network Load Balancer (NLB) を使用することにより、タイプ LoadBalancer の Kubernetes サービスリソースをサポートします。

手順

  1. OperatorHub からオンデマンドで AWS Load Balancer Operator をデプロイするには、次のコマンドを実行して Subscription オブジェクトを作成します。

    $ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、インストールプランのステータスが Complete になっているか確認します。

    $ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、aws-load-balancer-operator-controller-manager デプロイメントのステータスを表示します。

    $ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
    aws-load-balancer-operator-controller-manager  1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

2.2.3. Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用

Outpost に拡張された AWS VPC クラスター内で AWS Application Load Balancer をプロビジョニングするように AWS Load Balancer Operator を設定できます。AWS Outposts は AWS Network Load Balancer をサポートしていません。そのため、AWS Load Balancer Operator は Outpost に Network Load Balancer をプロビジョニングできません。

AWS Application Load Balancer は、クラウドサブネットか Outpost サブネットのどちらかに作成できます。クラウドの Application Load Balancer はクラウドベースのコンピュートノードに接続でき、Outpost の Application Load Balancer はエッジコンピュートノードに接続できます。Ingress リソースには Outpost サブネットまたは VPC サブネットのアノテーションを付ける必要がありますが、両方を付けることはできません。

前提条件

  • AWS VPC クラスターを Outpost に拡張した。
  • OpenShift CLI (oc) がインストールされている。
  • AWS Load Balancer Operator をインストールし、AWS Load Balancer Controller を作成した。

手順

  • 指定のサブネットを使用するように Ingress リソースを設定します。

    Ingress リソース設定の例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <application_name>
      annotations:
        alb.ingress.kubernetes.io/subnets: <subnet_id> 
    1
    
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <application_name>
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    使用するサブネットを指定します。
    • Outpost で Application Load Balancer を使用するには、Outpost のサブネット ID を指定します。
    • クラウドで Application Load Balancer を使用するには、別々のアベイラビリティーゾーンに少なくとも 2 つのサブネットを指定する必要があります。

2.3. AWS Load Balancer Operator 用に AWS STS クラスターを準備する

Security Token Service (STS) を使用するクラスターに Amazon Web Services (AWS) Load Balancer Operator をインストールできます。Operator をインストールする前に、次の手順に従ってクラスターを準備します。

AWS Load Balancer Operator は、CredentialsRequest オブジェクトに依存して Operator と AWS Load Balancer Controller をブートストラップします。AWS Load Balancer Operator は、必要なシークレットが作成されて利用可能になるまで待機します。

2.3.1. 前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスターのインフラストラクチャー ID がわかっている。この ID を表示するには、CLI で次のコマンドを実行します。

    $ oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"
    Copy to Clipboard Toggle word wrap
  • クラスターの OpenID Connect (OIDC) の DNS 情報がわかっている。この情報を表示するには、CLI で次のコマンドを入力します。

    $ oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}" 
    1
    Copy to Clipboard Toggle word wrap
    1
    OIDC DNS の例は https://rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。
  • AWS Web コンソールにログインし、IAMAccess managementIdentity providers に移動して、OIDC の Amazon Resource Name (ARN) 情報を確認した。OIDC の ARN の例は、arn:aws:iam::777777777777:oidc-provider/<oidc_dns_url> です。

2.3.2. AWS Load Balancer Operator 用の IAM ロールの作成

STS を使用するクラスターに AWS Load Balancer Operator を正常にインストールするには、追加の Amazon Web Services (AWS) Identity and Access Management (IAM) ロールが必要です。この IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために必要です。AWS Load Balancer Operator は、自身をブートストラップするために IAM ロールを持つ CredentialsRequest オブジェクトを生成します。

IAM ロールは次の方法で作成できます。

環境が ccoctl コマンドをサポートしていない場合は、AWS CLI を使用します。

2.3.2.1. Cloud Credential Operator ユーティリティーを使用して AWS IAM ロールを作成する

Cloud Credential Operator ユーティリティー (ccoctl) を使用して、AWS Load Balancer Operator 用の AWS IAM ロールを作成できます。AWS IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話します。

前提条件

  • ccoctl バイナリーを抽出して準備する必要があります。

手順

  1. 次のコマンドを実行して、CredentialsRequest カスタムリソース (CR) をダウンロードし、ディレクトリーに保存します。

    $ curl --create-dirs -o <credentials_requests_dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  2. ccoctl ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。

    $ ccoctl aws create-iam-roles \
        --name <name> \
        --region=<aws_region> \
        --credentials-requests-dir=<credentials_requests_dir> \
        --identity-provider-arn <oidc_arn>
    Copy to Clipboard Toggle word wrap

    出力例

    2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created 
    1
    
    2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credentials_requests_dir>/manifests/aws-load-balancer-operator-aws-load-balancer-operator-credentials.yaml
    2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-operator created
    Copy to Clipboard Toggle word wrap

    1
    AWS Load Balancer Operator 用に作成された AWS IAM ロールの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator) をメモします。
    注記

    AWS IAM ロール名の長さは 12 文字以下にする必要があります。

2.3.2.2. AWS CLI を使用して AWS IAM ロールを作成する

AWS コマンドラインインターフェイスを使用して、AWS Load Balancer Operator 用の IAM ロールを作成できます。IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。

前提条件

  • AWS コマンドラインインターフェイス (aws) にアクセスできる。

手順

  1. 次のコマンドを実行して、アイデンティティープロバイダーを使用して信頼ポリシーファイルを生成します。

    $ cat <<EOF > albo-operator-trust-policy.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "<oidc_arn>" 
    1
    
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 
    2
    
                    }
                }
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
    1
    OIDC アイデンティティープロバイダーの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f) を指定します。
    2
    AWS Load Balancer Controller のサービスアカウントを指定します。<cluster_oidc_endpoint> の例は、rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。
  2. 次のコマンドを実行して、生成された信頼ポリシーを使用して IAM ロールを作成します。

    $ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
    Copy to Clipboard Toggle word wrap

    出力例

    ROLE	arn:aws:iam::<aws_account_number>:role/albo-operator	2023-08-02T12:13:22Z 
    1
    
    ASSUMEROLEPOLICYDOCUMENT	2012-10-17
    STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
    STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-manager
    PRINCIPAL	arn:aws:iam:<aws_account_number>:oidc-provider/<cluster_oidc_endpoint>
    Copy to Clipboard Toggle word wrap

    1
    AWS Load Balancer Operator 用に作成された AWS IAM ロールの ARN (例: arn:aws:iam::777777777777:role/albo-operator) をメモします。
  3. 次のコマンドを実行して、AWS Load Balancer Operator の権限ポリシーをダウンロードします。

    $ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーを IAM ロールに割り当てます。

    $ aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.json
    Copy to Clipboard Toggle word wrap

2.3.3. AWS Load Balancer Operator 用の ARN ロールの設定

AWS Load Balancer Operator 用の Amazon Resource Name (ARN) ロールを環境変数として設定できます。CLI を使用して ARN ロールを設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、aws-load-balancer-operator プロジェクトを作成します。

    $ oc new-project aws-load-balancer-operator
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して OperatorGroup オブジェクトを作成します。

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      targetNamespaces: []
    EOF
    Copy to Clipboard Toggle word wrap
  3. 以下のコマンドを実行して Subscription オブジェクトを作成します。

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      channel: stable-v1
      name: aws-load-balancer-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        env:
        - name: ROLEARN
          value: "<albo_role_arn>" 
    1
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    AWS Load Balancer Operator の AWS 認証情報をプロビジョニングするために CredentialsRequest で使用する ARN ロールを指定します。<albo_role_arn> の例は、arn:aws:iam::<aws_account_number>:role/albo-operator です。
    注記

    AWS Load Balancer Operator は、シークレットが作成されるまで待機してから、Available ステータスに移行します。

2.3.4. AWS Load Balancer Controller 用の IAM ロールの作成

AWS Load Balancer Controller の CredentialsRequest オブジェクトは、手動でプロビジョニングした IAM ロールを使用して設定する必要があります。

IAM ロールは次の方法で作成できます。

環境が ccoctl コマンドをサポートしていない場合は、AWS CLI を使用します。

Cloud Credential Operator ユーティリティー (ccoctl) を使用して、AWS Load Balancer Controller 用の AWS IAM ロールを作成できます。AWS IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。

前提条件

  • ccoctl バイナリーを抽出して準備する必要があります。

手順

  1. 次のコマンドを実行して、CredentialsRequest カスタムリソース (CR) をダウンロードし、ディレクトリーに保存します。

    $ curl --create-dirs -o <credentials_requests_dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml
    Copy to Clipboard Toggle word wrap
  2. ccoctl ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。

    $ ccoctl aws create-iam-roles \
        --name <name> \
        --region=<aws_region> \
        --credentials-requests-dir=<credentials_requests_dir> \
        --identity-provider-arn <oidc_arn>
    Copy to Clipboard Toggle word wrap

    出力例

    2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created 
    1
    
    2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credentials_requests_dir>/manifests/aws-load-balancer-operator-aws-load-balancer-controller-credentials.yaml
    2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-controller created
    Copy to Clipboard Toggle word wrap

    1
    AWS Load Balancer Controller 用に作成された AWS IAM ロールの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller) をメモします。
    注記

    AWS IAM ロール名の長さは 12 文字以下にする必要があります。

2.3.4.2. AWS CLI を使用してコントローラー用の AWS IAM ロールを作成する

AWS コマンドラインインターフェイスを使用して、AWS Load Balancer Controller 用の AWS IAM ロールを作成できます。AWS IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。

前提条件

  • AWS コマンドラインインターフェイス (aws) にアクセスできる。

手順

  1. 次のコマンドを実行して、アイデンティティプロバイダーを使用して信頼ポリシーファイルを生成します。

    $ cat <<EOF > albo-controller-trust-policy.json
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "<oidc_arn>" 
    1
    
                },
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                    "StringEquals": {
                        "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 
    2
    
                    }
                }
            }
        ]
    }
    EOF
    Copy to Clipboard Toggle word wrap
    1
    OIDC アイデンティティープロバイダーの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f) を指定します。
    2
    AWS Load Balancer Controller のサービスアカウントを指定します。<cluster_oidc_endpoint> の例は、rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。
  2. 次のコマンドを実行して、生成された信頼ポリシーを使用して AWS IAM ロールを作成します。

    $ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
    Copy to Clipboard Toggle word wrap

    出力例

    ROLE	arn:aws:iam::<aws_account_number>:role/albo-controller	2023-08-02T12:13:22Z 
    1
    
    ASSUMEROLEPOLICYDOCUMENT	2012-10-17
    STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
    STRINGEQUALS	system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager
    PRINCIPAL	arn:aws:iam:<aws_account_number>:oidc-provider/<cluster_oidc_endpoint>
    Copy to Clipboard Toggle word wrap

    1
    AWS Load Balancer Controller の AWS IAM ロールの ARN (例: arn:aws:iam::777777777777:role/albo-controller) をメモします。
  3. 次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーをダウンロードします。

    $ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーを AWS IAM ロールに割り当てます。

    $ aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.json
    Copy to Clipboard Toggle word wrap
  5. AWSLoadBalancerController オブジェクトを定義する YAML ファイルを作成します。

    sample-aws-lb-manual-creds.yaml ファイルの例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      credentialsRequestConfig:
        stsIAMRoleARN: <albc_role_arn> 
    3
    Copy to Clipboard Toggle word wrap

    1
    AWSLoadBalancerController オブジェクトを定義します。
    2
    AWS Load Balancer Controller 名を定義します。このインスタンス名は、関連するすべてのリソースの接尾辞として使用されます。
    3
    AWS Load Balancer Controller の ARN ロールを指定します。CredentialsRequest オブジェクトは、この ARN ロールを使用して AWS 認証情報をプロビジョニングします。<albc_role_arn> の例は、arn:aws:iam::777777777777:role/albo-controller です。

2.4. AWS Load Balancer Operator のインストール

AWS Load Balancer Operator は、AWS Load Balancer Controller をデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から AWS Load Balancer Operator をインストールできます。

2.4.1. Web コンソールを使用した AWS Load Balancer Operator のインストール

Web コンソールを使用して、AWS Load Balancer Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。
  • クラスターのプラットフォームタイプとクラウドプロバイダーが AWS に設定されている。
  • セキュリティートークンサービス (STS) または user-provisioned infrastructure を使用している場合は、関連する準備手順に従います。たとえば、AWS Security Token Service を使用している場合は、「AWS Security Token Service (STS) を使用してクラスター上で AWS Load Balancer Operator を準備する」を参照してください。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub に移動します。
  2. AWS Load Balancer Operator を選択します。Filter by keyword テキストボックスを使用するか、フィルターリストを使用して、Operator のリストから AWS Load Balancer Operator を検索できます。
  3. aws-load-balancer-operator namespace を選択します。
  4. Install Operator ページで、次のオプションを選択します。

    1. Update the channelstable-v1 を選択します。
    2. Installation modeAll namespaces on the cluster (default) を選択します。
    3. Installed Namespaceaws-load-balancer-operator を選択します。aws-load-balancer-operator namespace が存在しない場合は、Operator のインストール中に作成されます。
    4. Update approvalAutomatic または Manual を選択します。デフォルトでは、Update approvalAutomatic に設定されています。Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように更新要求を手動で承認する必要があります。
  5. Install をクリックします。

検証

  • AWS Load Balancer Operator で、インストール済み Operator ダッシュボードの StatusSucceeded と表示されることを確認します。

2.4.2. CLI を使用した AWS Load Balancer Operator のインストール

CLI を使用して AWS Load Balancer Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。
  • クラスターのプラットフォームタイプとクラウドプロバイダーが AWS に設定されている。
  • OpenShift CLI (oc) にログイン済みである。

手順

  1. Namespace オブジェクトを作成します。

    1. Namespace オブジェクトを定義する YAML ファイルを作成します。

      namespace.yaml ファイルの例

      apiVersion: v1
      kind: Namespace
      metadata:
        name: aws-load-balancer-operator
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、Namespace オブジェクトを作成します。

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. OperatorGroup オブジェクトを作成します。

    1. OperatorGroup オブジェクトを定義する YAML ファイルを作成します。

      operatorgroup.yaml ファイルの例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: aws-lb-operatorgroup
        namespace: aws-load-balancer-operator
      spec:
        upgradeStrategy: Default
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して OperatorGroup オブジェクトを作成します。

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. Subscription オブジェクトを作成します。

    1. Subscription オブジェクトを定義する YAML ファイルを作成します。

      subscription.yaml ファイルの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: aws-load-balancer-operator
        namespace: aws-load-balancer-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: aws-load-balancer-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して Subscription オブジェクトを作成します。

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

検証

  1. サブスクリプションからインストールプランの名前を取得します。

    $ oc -n aws-load-balancer-operator \
      get subscription aws-load-balancer-operator \
      --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. インストールプランのステータスを確認します。

    $ oc -n aws-load-balancer-operator \
      get ip <install_plan_name> \
      --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap

    出力は Complete でなければなりません。

2.4.3. AWS Load Balancer Controller の作成

クラスターにインストールできる AWSLoadBalancerController オブジェクトのインスタンスは 1 つだけです。CLI を使用して AWS Load Balancer Controller を作成できます。AWS Load Balancer Operator は、cluster という名前のリソースのみを調整します。

前提条件

  • echoserver namespace を作成している。
  • OpenShift CLI (oc) にアクセスできる。

手順

  1. AWSLoadBalancerController オブジェクトを定義する YAML ファイルを作成します。

    sample-aws-lb.yaml ファイルの例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController 
    1
    
    metadata:
      name: cluster 
    2
    
    spec:
      subnetTagging: Auto 
    3
    
      additionalResourceTags: 
    4
    
      - key: example.org/security-scope
        value: staging
      ingressClass: alb 
    5
    
      config:
        replicas: 2 
    6
    
      enabledAddons: 
    7
    
        - AWSWAFv2 
    8
    Copy to Clipboard Toggle word wrap

    1
    AWSLoadBalancerController オブジェクトを定義します。
    2
    AWS Load Balancer Controller 名を定義します。このインスタンス名は、関連するすべてのリソースの接尾辞として追加されます。
    3
    AWS Load Balancer Controller のサブネットのタグ付け方法を設定します。次の値が有効です。
    • Auto: AWS Load Balancer Operator は、クラスターに属するサブネットを決定し、適切にタグ付けします。内部サブネットタグが内部サブネットに存在しない場合、Operator はロールを正しく判別できません。
    • Manual: クラスターに属するサブネットに適切なロールタグを手動でタグ付けします。ユーザー提供のインフラストラクチャーにクラスターをインストールした場合は、このオプションを使用します。
    4
    AWS Load Balancer Controller が AWS リソースをプロビジョニングするときに使用するタグを定義します。
    5
    Ingress クラス名を定義します。デフォルト値は alb です。
    6
    AWS Load Balancer Controller のレプリカの数を指定します。
    7
    AWS Load Balancer Controller のアドオンとしてアノテーションを指定します。
    8
    alb.ingress.kubernetes.io/wafv2-acl-arn アノテーションを有効にします。
  2. 次のコマンドを実行して、AWSLoadBalancerController オブジェクトを作成します。

    $ oc create -f sample-aws-lb.yaml
    Copy to Clipboard Toggle word wrap
  3. Deployment リソースを定義する YAML ファイルを作成します。

    sample-aws-lb.yaml ファイルの例

    apiVersion: apps/v1
    kind: Deployment 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      selector:
        matchLabels:
          app: echoserver
      replicas: 3 
    3
    
      template:
        metadata:
          labels:
            app: echoserver
        spec:
          containers:
            - image: openshift/origin-node
              command:
               - "/bin/socat"
              args:
                - TCP4-LISTEN:8080,reuseaddr,fork
                - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
              imagePullPolicy: Always
              name: echoserver
              ports:
                - containerPort: 8080
    Copy to Clipboard Toggle word wrap

    1
    デプロイメントリソースを定義します。
    2
    デプロイメント名を指定します。
    3
    デプロイメントのレプリカの数を指定します。
  4. Service リソースを定義する YAML ファイルを作成します。

    service-albo.yaml ファイルの例

    apiVersion: v1
    kind: Service 
    1
    
    metadata:
      name: <echoserver> 
    2
    
      namespace: echoserver
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector:
        app: echoserver
    Copy to Clipboard Toggle word wrap

    1
    サービスリソースを定義します。
    2
    サービス名を指定します。
  5. Ingress リソースを定義する YAML ファイルを作成します。

    Ingress-albo.yaml ファイルの例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <name> 
    1
    
      namespace: echoserver
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <echoserver> 
    2
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    Ingress リソースの名前を指定します。
    2
    サービス名を指定します。

検証

  • 次のコマンドを実行して、Ingress リソースのステータスを HOST 変数に保存します。

    $ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
    Copy to Clipboard Toggle word wrap
  • 次のコマンドを実行して、Ingress リソースのステータスを確認します。

    $ curl $HOST
    Copy to Clipboard Toggle word wrap

2.5. AWS Load Balancer Operator の設定

2.5.1. クラスター全体のプロキシーの認証局を信頼する

AWS Load Balancer Operator でクラスター全体のプロキシーを設定できます。クラスター全体のプロキシーを設定すると、Operator Lifecycle Manager (OLM) が、HTTP_PROXYHTTPS_PROXYNO_PROXY などの環境変数を使用して、Operator のすべてのデプロイメントを自動的に更新します。これらの変数は、AWS Load Balancer Operator によってマネージドコントローラーに入力されます。

  1. 次のコマンドを実行して、aws-load-balancer-operator namespace に認証局 (CA) バンドルを含める config map を作成します。

    $ oc -n aws-load-balancer-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 信頼できる CA バンドルを config map に挿入するには、次のコマンドを実行して、config.openshift.io/inject-trusted-cabundle=true ラベルを config map に追加します。

    $ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、AWS Load Balancer Operator デプロイメントの config map にアクセスできるように AWS Load Balancer Operator サブスクリプションを更新します。

    $ oc -n aws-load-balancer-operator patch subscription aws-load-balancer-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}],"volumes":[{"name":"trusted-ca","configMap":{"name":"trusted-ca"}}],"volumeMounts":[{"name":"trusted-ca","mountPath":"/etc/pki/tls/certs/albo-tls-ca-bundle.crt","subPath":"ca-bundle.crt"}]}}}'
    Copy to Clipboard Toggle word wrap
  4. AWS Load Balancer Operator がデプロイされたら、次のコマンドを実行して、CA バンドルが aws-load-balancer-operator-controller-manager デプロイメントに追加されていることを確認します。

    $ oc -n aws-load-balancer-operator exec deploy/aws-load-balancer-operator-controller-manager -c manager -- bash -c "ls -l /etc/pki/tls/certs/albo-tls-ca-bundle.crt; printenv TRUSTED_CA_CONFIGMAP_NAME"
    Copy to Clipboard Toggle word wrap

    出力例

    -rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt
    trusted-ca
    Copy to Clipboard Toggle word wrap

  5. オプション: config-map が変更されるたびに、次のコマンドを実行して、AWS Load Balancer Operator のデプロイを再開します。

    $ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
    Copy to Clipboard Toggle word wrap

2.5.2. AWS Load Balancer への TLS Termination の追加

ドメインのトラフィックをサービスの Pod にルーティングし、AWS Load Balancer に TLS Termination を追加できます。

前提条件

  • OpenShift CLI (oc) にアクセスできる。

手順

  1. AWSLoadBalancerController リソースを定義する YAML ファイルを作成します。

    add-tls-termination-albc.yaml ファイルの例

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: tls-termination 
    1
    Copy to Clipboard Toggle word wrap

    1
    Ingress クラス名を定義します。クラスター内に Ingress クラスが存在しない場合は、AWS Load Balancer Controller によって作成されます。spec.controlleringress.k8s.aws/alb に設定されている場合、AWS Load Balancer Controller は追加の Ingress クラス値を調整します。
  2. Ingress リソースを定義する YAML ファイルを作成します。

    add-tls-termination-ingress.yaml ファイルの例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: <example> 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
    3
    
    spec:
      ingressClassName: tls-termination 
    4
    
      rules:
      - host: example.com 
    5
    
        http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: <example_service> 
    6
    
                    port:
                      number: 80
    Copy to Clipboard Toggle word wrap

    1
    Ingress 名を指定します。
    2
    コントローラーは、パブリックサブネット内の Ingress のロードバランサーをプロビジョニングし、インターネット経由でロードバランサーにアクセスします。
    3
    ロードバランサーに割り当てる証明書の Amazon Resource Name (ARN)。
    4
    Ingress クラス名を定義します。
    5
    トラフィックルーティングのドメインを定義します。
    6
    トラフィックルーティングのサービスを定義します。

2.5.3. 1 つの AWS ロードバランサーを介して複数の Ingress リソースを作成する

1 つの AWS Load Balancer を介して、1 つのドメインに含まれるさまざまなサービスに、複数の Ingress リソースを使用してトラフィックをルーティングできます。各 Ingress リソースは、ドメインの異なるエンドポイントを提供します。

前提条件

  • OpenShift CLI (oc) にアクセスできる。

手順

  1. 次のように、IngressClassParams リソースの YAML ファイル (例: sample-single-lb-params.yaml) を作成します。

    apiVersion: elbv2.k8s.aws/v1beta1 
    1
    
    kind: IngressClassParams
    metadata:
      name: single-lb-params 
    2
    
    spec:
      group:
        name: single-lb 
    3
    Copy to Clipboard Toggle word wrap
    1
    IngressClassParams リソースの API グループとバージョンを定義します。
    2
    IngressClassParams リソース名を指定します。
    3
    IngressGroup リソース名を指定します。このクラスのすべての Ingress リソースは、この IngressGroup に属します。
  2. 次のコマンドを実行して、IngressClassParams リソースを作成します。

    $ oc create -f sample-single-lb-params.yaml
    Copy to Clipboard Toggle word wrap
  3. 次のように、IngressClass リソースの YAML ファイル (例: sample-single-lb-class.yaml) を作成します。

    apiVersion: networking.k8s.io/v1 
    1
    
    kind: IngressClass
    metadata:
      name: single-lb 
    2
    
    spec:
      controller: ingress.k8s.aws/alb 
    3
    
      parameters:
        apiGroup: elbv2.k8s.aws 
    4
    
        kind: IngressClassParams 
    5
    
        name: single-lb-params 
    6
    Copy to Clipboard Toggle word wrap
    1
    API グループと IngressClass リソースのバージョンを定義します。
    2
    Ingress クラス名を指定します。
    3
    コントローラー名を定義します。ingress.k8s.aws/alb という値は、このクラスのすべての Ingress リソースを AWS Load Balancer Controller によって管理することを意味します。
    4
    IngressClassParams リソースの API グループを定義します。
    5
    IngressClassParams リソースのリソースタイプを定義します。
    6
    IngressClassParams リソース名を定義します。
  4. 次のコマンドを実行して IngressClass リソースを作成します。

    $ oc create -f sample-single-lb-class.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のように、AWSLoadBalancerController リソース YAML ファイル (例: sample-single-lb.yaml) を作成します。

    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
      name: cluster
    spec:
      subnetTagging: Auto
      ingressClass: single-lb 
    1
    Copy to Clipboard Toggle word wrap
    1
    IngressClass リソースの名前を定義します。
  6. 次のコマンドを実行して、AWSLoadBalancerController リソースを作成します。

    $ oc create -f sample-single-lb.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のように、Ingress リソースの YAML ファイル (例: sample-multiple-ingress.yaml) を作成します。

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-1 
    1
    
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing 
    2
    
        alb.ingress.kubernetes.io/group.order: "1" 
    3
    
        alb.ingress.kubernetes.io/target-type: instance 
    4
    
    spec:
      ingressClassName: single-lb 
    5
    
      rules:
      - host: example.com 
    6
    
        http:
            paths:
            - path: /blog 
    7
    
              pathType: Prefix
              backend:
                service:
                  name: example-1 
    8
    
                  port:
                    number: 80 
    9
    
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-2
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "2"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /store
              pathType: Prefix
              backend:
                service:
                  name: example-2
                  port:
                    number: 80
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-3
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/group.order: "3"
        alb.ingress.kubernetes.io/target-type: instance
    spec:
      ingressClassName: single-lb
      rules:
      - host: example.com
        http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  name: example-3
                  port:
                    number: 80
    Copy to Clipboard Toggle word wrap
    1
    Ingress 名を指定します。
    2
    インターネットにアクセスするためにパブリックサブネットにプロビジョニングするロードバランサーを示します。
    3
    ロードバランサーで要求を受信したときに、複数の Ingress リソースからのルールをマッチする順序を指定します。
    4
    ロードバランサーがサービスに到達するために OpenShift Container Platform ノードをターゲットにすることを示します。
    5
    この Ingress に属する Ingress クラスを指定します。
    6
    要求のルーティングに使用するドメイン名を定義します。
    7
    サービスにルーティングする必要があるパスを定義します。
    8
    Ingress リソースで設定されたエンドポイントを提供するサービス名を定義します。
    9
    エンドポイントにサービスを提供するサービスのポートを定義します。
  8. 次のコマンドを実行して Ingress リソースを作成します。

    $ oc create -f sample-multiple-ingress.yaml
    Copy to Clipboard Toggle word wrap

2.5.4. AWS Load Balancer Operator ログ

oc logs コマンドを使用して、AWS Load Balancer Operator のログを表示できます。

手順

  • 次のコマンドを実行して、AWS Load Balancer Operator のログを表示します。

    $ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
    Copy to Clipboard Toggle word wrap

第3章 eBPF マネージャー Operator

3.1. eBPF Manager Operator について

重要

eBPF Manager Operator はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.1.1. eBPF (Extended Berkeley Packet Filter) について

eBPF は、高度なネットワークトラフィックフィルタリングを実現するために、オリジナルの Berkeley Packet Filter を拡張します。これは Linux カーネル内の仮想マシンとして機能し、ネットワークパケット、システムコール、カーネル関数などのイベントに応じてサンドボックス化されたプログラムを実行できるようにします。

3.1.2. eBPF Manager Operator について

eBPF Manager は、Kubernetes 内での eBPF プログラムの管理とデプロイメントを簡素化し、eBPF プログラムの使用に関するセキュリティーを強化します。Kubernetes カスタムリソース定義 (CRD) を使用して、OCI コンテナーイメージとしてパッケージ化された eBPF プログラムを管理します。このアプローチは、特定のユーザーが展開できるプログラムの種類を制限することで、デプロイメント権限を明確にし、セキュリティーを強化するのに役立ちます。

eBPF Manager は、Kubernetes 内で eBPF プログラムを管理するために設計されたソフトウェアスタックです。Kubernetes クラスター内の eBPF プログラムのロード、アンロード、変更、監視を容易にします。デーモン、CRD、エージェント、Operator が含まれます。

bpfman
gRPC API を介して eBPF プログラムを管理するシステムデーモン。
eBPF CRDs
eBPF プログラムをロードするための XdpProgram や TcProgram などの CRD のセットと、ロードされたプログラムの状態を表すための bpfman によって生成された CRD (BpfProgram)。
bpfman-agent
デーモンセットコンテナー内で実行し、各ノード上の eBPF プログラムが目的の状態にあることを確認する。
bpfman-operator
Operator SDK を使用して、クラスター内の bpfman-agent と CRD のライフサイクルを管理します。

eBPF Manager Operator は次の機能を提供します。

  • 制御されたデーモンを通じて eBPF プログラムのロードを一元化することで、セキュリティーを強化します。eBPF Manager には昇格された権限があるため、アプリケーションに昇格された権限は必要ありません。eBPF プログラム制御は、標準の Kubernetes ロールベースアクセス制御 (RBAC) によって規制され、eBPF プログラムのロードとアンロードを管理するさまざまな eBPF マネージャー CRD へのアプリケーションのアクセスを許可または拒否できます。
  • アクティブな eBPF プログラムの詳細な可視性を提供し、システム全体の問題をデバッグする能力を向上させます。
  • XDP および TC プログラム用の libxdp などのプロトコルを使用して、異なるソースからの複数の eBPF プログラムの共存を容易にし、相互運用性を強化します。
  • Kubernetes での eBPF プログラムのデプロイメントとライフサイクル管理を合理化します。Cilium、libbpf、Aya などの既存の eBPF ライブラリーをサポートしているため、開発者はライフサイクル管理ではなくプログラムのやり取りに集中できます。

3.1.4. 次のステップ

3.2. eBPF Manager Operator のインストール

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して eBPF Manager Operator をインストールできます。

重要

eBPF Manager Operator はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.2.1. CLI を使用して eBPF Manager Operator をインストールする

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. bpfman namespace を作成するには、次のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: bpfman
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: bpfman-operators
      namespace: bpfman
    EOF
    Copy to Clipboard Toggle word wrap
  3. eBPF Manager Operator にサブスクライブします。

    1. eBPF Manager Operator の Subscription CR を作成するには、次のコマンドを実行します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bpfman-operator
        namespace: bpfman
      spec:
        name: bpfman-operator
        channel: alpha
        source: community-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

    $ oc get ip -n bpfman
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            CSV                                 APPROVAL    APPROVED
    install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. Operator のバージョンを確認するには、次のコマンドを入力します。

    $ oc get csv -n bpfman
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
    bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded
    Copy to Clipboard Toggle word wrap

3.2.2. Web コンソールを使用して eBPF Manager Operator をインストールする

クラスター管理者は、Web コンソールを使用して eBPF Manager Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. eBPF Manager Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator のリストから eBPF Manager Operator を選択し、コミュニティー Operator を表示する ように求められたら、Continue をクリックします。
    3. Install をクリックします。
    4. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
    5. Install をクリックします。
  2. eBPF Manager Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. eBPF Manager Operator が、StatusInstallSucceededopenshift-ingress-node-firewall プロジェクトにリストされていることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator の StatusInstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、bpfman プロジェクト内の Pod のログを確認します。

3.2.3. 次のステップ

3.3. eBPF プログラムのデプロイ

クラスター管理者は、eBPF Manager Operator を使用してコンテナー化された eBPF アプリケーションをデプロイできます。

この手順でデプロイされるサンプル eBPF プログラムの場合、サンプルマニフェストは次のことを実行します。

まず、NamespaceServiceAccountClusterRoleBinding などの基本的な Kubernetes オブジェクトを作成します。また、eBPF Manager が提供するカスタムリソース定義 (CRD) である XdpProgram オブジェクトも作成し、eBPF XDP プログラムをロードします。各プログラムタイプには独自の CRD がありますが、その機能は似ています。詳細は、Kubernetes での eBPF プログラムのロード を参照してください。

次に、eBPF プログラムが作成する eBPF マップを読み取るユーザー空間プログラムを実行するデーモンセットを作成します。この eBPF マップは、Container Storage Interface (CSI) ドライバーを使用してボリュームマウントされます。ホスト上でアクセスする代わりにコンテナー内の eBPF マップをボリュームマウントすることで、アプリケーション Pod は権限なしで eBPF マップにアクセスできます。CSI の設定方法の詳細は、Kubernetes での eBPF 対応アプリケーションのデプロイ を参照してください。

重要

eBPF Manager Operator はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.3.1. コンテナー化された eBPF プログラムの導入

クラスター管理者は、クラスター上のノードに eBPF プログラムをデプロイできます。この手順では、サンプルのコンテナー化された eBPF プログラムが go-xdp-counter namespace にインストールされます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。
  • eBPF Manager Operator をインストールしている。

手順

  1. マニフェストをダウンロードするには、次のコマンドを入力します。

    $ curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml
    Copy to Clipboard Toggle word wrap
  2. サンプル eBPF アプリケーションをデプロイするには、次のコマンドを実行します。

    $ oc create -f go-xdp-counter-install-selinux.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    namespace/go-xdp-counter created
    serviceaccount/bpfman-app-go-xdp-counter created
    clusterrolebinding.rbac.authorization.k8s.io/xdp-binding created
    daemonset.apps/go-xdp-counter-ds created
    xdpprogram.bpfman.io/go-xdp-counter-example created
    selinuxprofile.security-profiles-operator.x-k8s.io/bpfman-secure created
    Copy to Clipboard Toggle word wrap

  3. eBPF サンプルアプリケーションが正常にデプロイされたことを確認するには、次のコマンドを実行します。

    $ oc get all -o wide -n go-xdp-counter
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
    pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
    pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
    pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
    daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter
    Copy to Clipboard Toggle word wrap

  4. サンプル XDP プログラムが実行していることを確認するには、次のコマンドを実行します。

    $ oc get xdpprogram go-xdp-counter-example
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
    go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess
    Copy to Clipboard Toggle word wrap

  5. XDP プログラムがデータを収集していることを確認するには、次のコマンドを実行します。

    $ oc logs <pod_name> -n go-xdp-counter
    Copy to Clipboard Toggle word wrap

    <pod_name> を、go-xdp-counter-ds-4m9cw などの XDP プログラム Pod の名前に置き換えます。

    出力例

    2024/08/13 15:20:06 15016 packets received
    2024/08/13 15:20:06 93581579 bytes received
    ...
    Copy to Clipboard Toggle word wrap

第4章 External DNS Operator

4.1. External DNS Operator のリリースノート

External DNS Operator は、ExternalDNS をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。

重要

External DNS Operator は、x86_64 アーキテクチャーでのみサポートされます。

これらのリリースノートでは、OpenShift Container Platform の External DNS Operator の開発を追跡しています。

4.1.1. External DNS Operator 1.3.0

External DNS Operator バージョン 1.3.0 では、以下のアドバイザリーを利用できます。

この更新には、アップストリームプロジェクトの 0.14.2 バージョンへのリベースが含まれています。

4.1.1.1. バグ修正

以前は、ExternalDNS Operator が HCP クラスターにオペランドをデプロイできませんでした。このリリースでは、Operator がオペランドを実行中かつ準備完了の状態でデプロイします。(OCPBUGS-37059)

以前は、ExternalDNS Operator が RHEL 9 をビルドイメージまたはベースイメージとして使用していませんでした。このリリースでは、RHEL9 がベースです。(OCPBUGS-41683)

以前、godoc の Infoblox プロバイダーへのリンクが壊れていました。このリリースでは、godoc が改訂され正確になりました。リンクは削除されるか、GitHub のパーマリンクに置き換えられました。(OCPBUGS-36797)

4.1.2. External DNS Operator 1.2.0

External DNS Operator バージョン 1.2.0 では、以下のアドバイザリーを利用できます。

4.1.2.1. 新機能
4.1.2.2. バグ修正
  • オペランドの更新ストラテジーが、Rolling から Recreate に変更されました。(OCPBUGS-3630)

4.1.3. External DNS Operator 1.1.1

External DNS Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。利用できます。

4.1.4. External DNS Operator 1.1.0

このリリースには、アップストリームプロジェクトバージョン 0.13.1 からのオペランドのリベースが含まれていました。External DNS Operator バージョン 1.1.0 では、以下のアドバイザリーを利用できます。

4.1.4.1. バグ修正
  • 以前は、ExternalDNS Operator がボリュームに空の defaultMode 値を強制していたため、OpenShift API との競合により更新が随時行われていました。現在は、defaultMode 値は強制されず、オペランドのデプロイは随時更新されなくなりました。(OCPBUGS-2793)

4.1.5. External DNS Operator 1.0.1

External DNS Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。

4.1.6. External DNS Operator 1.0.0

External DNS Operator バージョン 1.0.0 では、以下のアドバイザリーを利用できます。

4.1.6.1. バグ修正
  • 以前は、External DNS Operator は、ExternalDNS オペランド Pod のデプロイメント中に制限付き SCC ポリシーの違反に関する警告を発していました。この問題は解決されています。(BZ#2086408)

4.2. External DNS Operator について

External DNS Operator は、ExternalDNS をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。

4.2.1. External DNS Operator

External DNS Operator は、olm.openshift.io API グループから External DNS API を実装します。External DNS Operator は、サービス、ルート、外部 DNS プロバイダーを更新します。

前提条件

  • yq CLI ツールがインストールされている。

手順

OperatorHub からオンデマンドで External DNS Operator をデプロイできます。External DNS Operator をデプロイすると、Subscription オブジェクトが作成されます。

  1. 次のコマンドを実行して、install-zcvlr などのインストールプランの名前を確認します。

    $ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、インストールプランのステータスが Complete になっているか確認します。

    $ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、external-dns-operator デプロイメントのステータスを表示します。

    $ oc get -n external-dns-operator deployment/external-dns-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                    READY     UP-TO-DATE   AVAILABLE   AGE
    external-dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

4.2.2. External DNS Operator のログの表示

oc logs コマンドを使用して、External DNS Operator のログを表示できます。

手順

  1. 次のコマンドを実行して、External DNS Operator のログを表示します。

    $ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
    Copy to Clipboard Toggle word wrap
4.2.2.1. External DNS Operator のドメイン名の制限

External DNS Operator は、TXT レコードの接頭辞を追加する TXT レジストリーを使用します。これにより、TXT レコードのドメイン名の最大長が短くなります。DNS レコードは対応する TXT レコードなしでは存在できないため、DNS レコードのドメイン名は TXT レコードと同じ制限に従う必要があります。たとえば、DNS レコードが <domain_name_from_source> の場合、TXT レコードは external-dns-<record_type>-<domain_name_from_source> になります。

External DNS Operator によって生成される DNS レコードのドメイン名には、次の制限があります。

Expand
レコードの種類文字数

CNAME

44

AzureDNS のワイルドカード CNAME レコード

42

A

48

AzureDNS のワイルドカード A レコード

46

生成されたドメイン名がドメイン名の制限を超えると、External DNS Operator のログに次のエラーが表示されます。

time="2022-09-02T08:53:57Z" level=error msg="Failure in zone test.example.io. [Id: /hostedzone/Z06988883Q0H0RL6UMXXX]"
time="2022-09-02T08:53:57Z" level=error msg="InvalidChangeBatch: [FATAL problem: DomainLabelTooLong (Domain label is too long) encountered with 'external-dns-a-hello-openshift-aaaaaaaaaa-bbbbbbbbbb-ccccccc']\n\tstatus code: 400, request id: e54dfd5a-06c6-47b0-bcb9-a4f7c3a4e0c6"
Copy to Clipboard Toggle word wrap

4.3. External DNS Operator のインストール

AWS、Azure、GCP などのクラウドプロバイダーに External DNS Operator をインストールできます。

4.3.1. OperatorHub を使用した External DNS Operator のインストール

OpenShift Container Platform OperatorHub を使用して、External DNS Operator をインストールできます。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. External DNS Operator をクリックします。Filter by keyword のテキストボックスまたはフィルターリストを使用して、Operator のリストから External DNS Operator を検索できます。
  3. external-dns-operator namespace を選択します。
  4. External DNS Operator ページで Install をクリックします。
  5. Install Operator ページで、次のオプションを選択していることを確認してください。

    1. Update the channel で stable-v1.0 を選択します。
    2. Installation mode で A specific name on the cluster を選択します。
    3. Installed namespace で external-dns-operator を選択します。namespace external-dns-operator が存在しない場合は、Operator のインストール中に作成されます。
    4. Approval StrategyAutomatic または Manual を選択します。Approval Strategy はデフォルトで Automatic に設定されています。
    5. Install をクリックします。

Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。

検証

Installed Operators ダッシュボードで、External DNS Operator の StatusSucceeded と表示されることを確認します。

4.3.2. CLI を使用した External DNS Operator のインストール

CLI を使用して External DNS Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift CLI (oc) にログイン済みである。

手順

  1. Namespace オブジェクトを作成します。

    1. Namespace オブジェクトを定義する YAML ファイルを作成します。

      namespace.yaml ファイルの例

      apiVersion: v1
      kind: Namespace
      metadata:
        name: external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、Namespace オブジェクトを作成します。

      $ oc apply -f namespace.yaml
      Copy to Clipboard Toggle word wrap
  2. OperatorGroup オブジェクトを作成します。

    1. OperatorGroup オブジェクトを定義する YAML ファイルを作成します。

      operatorgroup.yaml ファイルの例

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        upgradeStrategy: Default
        targetNamespaces:
        - external-dns-operator
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して OperatorGroup オブジェクトを作成します。

      $ oc apply -f operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  3. Subscription オブジェクトを作成します。

    1. Subscription オブジェクトを定義する YAML ファイルを作成します。

      subscription.yaml ファイルの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: external-dns-operator
        namespace: external-dns-operator
      spec:
        channel: stable-v1
        installPlanApproval: Automatic
        name: external-dns-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して Subscription オブジェクトを作成します。

      $ oc apply -f subscription.yaml
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、サブスクリプションからインストールプランの名前を取得します。

    $ oc -n external-dns-operator \
      get subscription external-dns-operator \
      --template='{{.status.installplan.name}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、インストールプランのステータスが Complete であることを確認します。

    $ oc -n external-dns-operator \
      get ip <install_plan_name> \
      --template='{{.status.phase}}{{"\n"}}'
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、external-dns-operator Pod のステータスが Running であることを確認します。

    $ oc -n external-dns-operator get pod
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                     READY   STATUS    RESTARTS   AGE
    external-dns-operator-5584585fd7-5lwqm   2/2     Running   0          11m
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、サブスクリプションのカタログソースが redhat-operators であることを確認します。

    $ oc -n external-dns-operator get subscription
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、external-dns-operator のバージョンを確認します。

    $ oc -n external-dns-operator get csv
    Copy to Clipboard Toggle word wrap

4.4. External DNS Operator の設定パラメーター

External DNS Operator には、次の設定パラメーターがあります。

4.4.1. External DNS Operator の設定パラメーター

External DNS Operator には、次の設定パラメーターがあります。

Expand
パラメーター説明

spec

クラウドプロバイダーのタイプを有効にします。

spec:
  provider:
    type: AWS 
1

    aws:
      credentials:
        name: aws-access-key 
2
Copy to Clipboard Toggle word wrap
1
AWS、GCP、Azure、Infoblox などの利用可能なオプションを定義します。
2
クラウドプロバイダーのシークレット名を定義します。

zones

ドメインごとに DNS ゾーンを指定できます。ゾーンを指定しない場合、ExternalDNS リソースはクラウドプロバイダーアカウントに存在するすべてのゾーンを検出します。

zones:
- "myzoneid" 
1
Copy to Clipboard Toggle word wrap
1
DNS ゾーンの名前を指定します。

domains

ドメインごとに AWS ゾーンを指定できます。ドメインを指定しない場合、ExternalDNS リソースはクラウドプロバイダーアカウントに存在するすべてのゾーンを検出します。

domains:
- filterType: Include 
1

  matchType: Exact 
2

  name: "myzonedomain1.com" 
3

- filterType: Include
  matchType: Pattern 
4

  pattern: ".*\\.otherzonedomain\\.com" 
5
Copy to Clipboard Toggle word wrap
1
ExternalDNS リソースにドメイン名が含まれていることを確認します。
2
ドメインは、正規表現での照合ではなく、完全に一致する必要があることを、ExternalDNS に指示します。
3
ドメインの名前を定義します。
4
ExternalDNS リソースに regex-domain-filter フラグを設定します。正規表現フィルターを使用して、使用できるドメインに限定します。
5
ターゲットゾーンのドメインをフィルタリングするために ExternalDNS リソースが使用する正規表現パターンを定義します。

source

DNS レコードのソース (Service または Route) を指定できます。

source: 
1

  type: Service 
2

  service:
    serviceType:
3

      - LoadBalancer
      - ClusterIP
  labelFilter: 
4

    matchLabels:
      external-dns.mydomain.org/publish: "yes"
  hostnameAnnotation: "Allow" 
5

  fqdnTemplate:
  - "{{.Name}}.myzonedomain.com" 
6
Copy to Clipboard Toggle word wrap
1
DNS レコードのソースの設定を定義します。
2
ExternalDNS リソースは、DNS レコードを作成するためのソースとして Service タイプを使用します。
3
ExternalDNS リソースに service-type-filter フラグを設定します。serviceType には、次のフィールドが含まれています。
  • デフォルト: LoadBalancer
  • expected: ClusterIP
  • NodePort
  • LoadBalancer
  • ExternalName
4
コントローラーで考慮するのは、ラベルフィルターと一致するリソースのみにします。
5
hostnameAnnotation のデフォルト値は Ignore で、フィールド fqdnTemplates で指定されたテンプレートを使用して DNS レコードを生成するように ExternalDNS に指示します。値が Allow の場合には、external-dns.alpha.kubernetes.io/hostname アノテーションで指定された値をもとに DNS レコードが生成されます。
6
External DNS Operator は文字列を使用して、ホスト名を定義していないソースから DNS 名を生成したり、偽のソースとペアになったときにホスト名の接尾辞を追加したりします。
source:
  type: OpenShiftRoute 
1

  openshiftRouteOptions:
    routerName: default 
2

    labelFilter:
      matchLabels:
        external-dns.mydomain.org/publish: "yes"
Copy to Clipboard Toggle word wrap
1
DNS レコードを作成します。
2
ソースタイプが OpenShiftRoute の場合は、Ingress Controller 名を指定できます。ExternalDNS リソースは、CNAME レコードのターゲットとして Ingress Controller の正規名を使用します。

4.5. AWS での DNS レコードの作成

External DNS Operator を使用して、AWS および AWS GovCloud で DNS レコードを作成できます。

Red Hat External DNS Operator を使用して、AWS のパブリックホストゾーンに DNS レコードを作成できます。同じ手順を使用して、AWS GovCloud のホストゾーンに DNS レコードを作成できます。

手順

  1. 次のコマンドを実行して、system:admin などのユーザープロファイルを確認します。ユーザープロファイルには、kube-system namespace へのアクセス権が必要です。認証情報がない場合は、次のコマンドを実行して、kube-system namespace から認証情報を取得し、クラウドプロバイダークライアントを使用できます。

    $ oc whoami
    Copy to Clipboard Toggle word wrap
  2. kube-system namespace に存在する aws-creds シークレットから値を取得します。

    $ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
    Copy to Clipboard Toggle word wrap
    $ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  3. ルートを取得して、ドメインを確認します。

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    出力例

    openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. DNS ゾーンのリストを取得し、以前にクエリーしたルートのドメインに対応する DNS ゾーンを見つけます。

    $ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
    Copy to Clipboard Toggle word wrap

    出力例

    HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5
    Copy to Clipboard Toggle word wrap

  5. route ソースの ExternalDNS リソースを作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-aws 
    1
    
    spec:
      domains:
      - filterType: Include   
    2
    
        matchType: Exact   
    3
    
        name: testextdnsoperator.apacshift.support 
    4
    
      provider:
        type: AWS 
    5
    
      source:  
    6
    
        type: OpenShiftRoute 
    7
    
        openshiftRouteOptions:
          routerName: default 
    8
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    外部 DNS リソースの名前を定義します。
    2
    デフォルトでは、すべてのホストゾーンがターゲット候補として選択されます。必要なホストゾーンを追加できます。
    3
    ターゲットゾーンのドメインは、(正規表現の一致とは対照的に) 完全一致である必要があります。
    4
    更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
    5
    AWS Route53DNS プロバイダーを定義します。
    6
    DNS レコードのソースのオプションを定義します。
    7
    以前に指定された DNS プロバイダーで作成される DNS レコードのソースとして OpenShift route リソースを定義します。
    8
    ソースが OpenShiftRoute の場合に、OpenShift Ingress Controller 名を指定できます。External DNS Operator は、CNAME レコードの作成時に、そのルーターの正規ホスト名をターゲットとして選択します。
  6. 次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。

    $ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
    Copy to Clipboard Toggle word wrap

4.5.2. 共有 VPC を使用して別の AWS アカウントに DNS レコードを作成する

ExternalDNS Operator を使用すると、共有 Virtual Private Cloud (VPC) を使用して別の AWS アカウントに DNS レコードを作成できます。共有 VPC を使用すると、組織は複数のプロジェクトのリソースを共通の VPC ネットワークに接続できます。その後、VPC 共有を使用して、複数の AWS アカウント間で単一の Route 53 インスタンスを使用できます。

前提条件

  • 2 つの Amazon AWS アカウントを作成している。1 つは VPC と Route 53 プライベートホストゾーンが設定されたもの (アカウント A)、もう 1 つはクラスターをインストールするためのもの (アカウント B) です。
  • アカウント B でアカウント A の Route 53 ホストゾーンに DNS レコードを作成するために、適切な権限を持つ IAM ポリシーと IAM ロールをアカウント A に作成している。
  • アカウント B のクラスターをアカウント A の既存の VPC にインストールしている。
  • アカウント B のクラスターに ExternalDNS Operator がインストールされている。

手順

  1. 次のコマンドを実行して、アカウント B からアカウント A の Route 53 ホストゾーンにアクセスできるように作成した IAM ロールのロール ARN を取得します。

    $ aws --profile account-a iam get-role --role-name user-rol1 | head -1
    Copy to Clipboard Toggle word wrap

    出力例

    ROLE	arn:aws:iam::1234567890123:role/user-rol1	2023-09-14T17:21:54+00:00	3600	/	AROA3SGB2ZRKRT5NISNJN	user-rol1
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、アカウント A の認証情報で使用するプライベートホストゾーンを特定します。

    $ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
    Copy to Clipboard Toggle word wrap

    出力例

    HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support. 5
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、ExternalDNS オブジェクトを作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-aws
    spec:
      domains:
      - filterType: Include
        matchType: Exact
        name: testextdnsoperator.apacshift.support
      provider:
        type: AWS
        aws:
          assumeRole:
            arn: arn:aws:iam::12345678901234:role/user-rol1 
    1
    
      source:
        type: OpenShiftRoute
        openshiftRouteOptions:
          routerName: default
    EOF
    Copy to Clipboard Toggle word wrap
    1
    アカウント A に DNS レコードを作成するには、ロール ARN を指定します。
  4. 次のコマンドを使用して、OpenShift Container Platform (OCP) ルートに対して作成されたレコードを確認します。

    $ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console
    Copy to Clipboard Toggle word wrap

4.6. Azure での DNS レコードの作成

External DNS Operator を使用して、Azure 上に DNS レコードを作成できます。

重要

Microsoft Entra Workload ID 対応クラスターまたは Microsoft Azure Government (MAG) リージョンで実行されるクラスターで External DNS Operator を使用することはサポートされていません。

4.6.1. Azure のパブリック DNS ゾーン上で DNS レコードを作成する

External DNS Operator を使用して、Azure のパブリック DNS ゾーンに DNS レコードを作成できます。

前提条件

  • 管理者権限を持っている。
  • admin ユーザーの場合、kube-system namespace にアクセスできる。

手順

  1. クラウドプロバイダークライアントを使用するために、次のコマンドを実行して kube-system namespace から認証情報を取得します。

    $ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
    $ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
    $ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
    $ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
    $ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Azure にログインします。

    $ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、ルートのリストを取得します。

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    出力例

    openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、DNS ゾーンのリストを取得します。

    $ az network dns zone list --resource-group "${RESOURCE_GROUP}"
    Copy to Clipboard Toggle word wrap
  5. ExternalDNS オブジェクトを定義する YAML ファイル (例: external-dns-sample-azure.yaml) を作成します。

    external-dns-sample-azure.yaml ファイルの例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-azure 
    1
    
    spec:
      zones:
      - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" 
    2
    
      provider:
        type: Azure 
    3
    
      source:
        openshiftRouteOptions: 
    4
    
          routerName: default 
    5
    
        type: OpenShiftRoute 
    6
    Copy to Clipboard Toggle word wrap

    1
    外部 DNS 名を指定します。
    2
    ゾーン ID を定義します。
    3
    プロバイダータイプを定義します。
    4
    DNS レコードのソースのオプションを定義できます。
    5
    ソースタイプが OpenShiftRoute の場合、OpenShift Ingress Controller 名を渡すことができます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。
    6
    route リソースを Azure DNS レコードのソースとして定義します。
  6. 次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。

    $ az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
    Copy to Clipboard Toggle word wrap
    注記

    プライベート Azure DNS のホストされたプライベートゾーンにレコードを作成するには、zones フィールドの下にプライベートゾーンを指定する必要があります。これにより、プロバイダータイプが ExternalDNS 引数の azure-private-dns に入力されます。

4.7. GCP での DNS レコードの作成

External DNS Operator を使用して、Google Cloud Platform (GCP) 上に DNS レコードを作成できます。

重要

GCP Workload Identity が有効なクラスターで External DNS Operator を使用することはサポートされていません。GCP Workload Identity の詳細は、GCP Workload Identity を参照してください。

4.7.1. GCP のパブリックマネージドゾーン上で DNS レコードを作成する

External DNS Operator を使用して、GCP のパブリックマネージドゾーンに DNS レコードを作成できます。

前提条件

  • 管理者権限を持っている。

手順

  1. 次のコマンドを実行して、encoded-gcloud.json ファイル内の gcp-credentials シークレットをコピーします。

    $ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Google の認証情報をエクスポートします。

    $ export GOOGLE_CREDENTIALS=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを使用して、アカウントをアクティブ化します。

    $ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、プロジェクトを設定します。

    $ gcloud config set project <project_id as per decoded-gcloud.json>
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、ルートのリストを取得します。

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    出力例

    openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを実行して、qe-cvs4g-private-zone test.gcp.example.com などのマネージドゾーンのリストを取得します。

    $ gcloud dns managed-zones list | grep test.gcp.example.com
    Copy to Clipboard Toggle word wrap
  7. ExternalDNS オブジェクトを定義する YAML ファイル (例: external-dns-sample-gcp.yaml) を作成します。

    external-dns-sample-gcp.yaml ファイルの例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-gcp 
    1
    
    spec:
      domains:
        - filterType: Include 
    2
    
          matchType: Exact 
    3
    
          name: test.gcp.example.com 
    4
    
      provider:
        type: GCP 
    5
    
      source:
        openshiftRouteOptions: 
    6
    
          routerName: default 
    7
    
        type: OpenShiftRoute 
    8
    Copy to Clipboard Toggle word wrap

    1
    外部 DNS 名を指定します。
    2
    デフォルトでは、すべてのホストされたゾーンがターゲット候補として選択されます。ホストされたゾーンを含めることができます。
    3
    ターゲットのドメインは、name キーで定義された文字列と一致する必要があります。
    4
    更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
    5
    プロバイダータイプを定義します。
    6
    DNS レコードのソースのオプションを定義できます。
    7
    ソースタイプが OpenShiftRoute の場合、OpenShift Ingress Controller 名を渡すことができます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。
    8
    route リソースを GCP DNS レコードのソースとして定義します。
  8. 次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。

    $ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
    Copy to Clipboard Toggle word wrap

4.8. Infoblox での DNS レコードの作成

External DNS Operator を使用して、Infoblox 上に DNS レコードを作成できます。

4.8.1. Infoblox のパブリック DNS ゾーンでの DNS レコードの作成

External DNS Operator を使用して、Infoblox のパブリック DNS ゾーンに DNS レコードを作成できます。

前提条件

  • OpenShift CLI (oc) にアクセスできる。
  • Infoblox UI にアクセスできる。

手順

  1. 次のコマンドを実行して、Infoblox クレデンシャルを使用して secret オブジェクトを作成します。

    $ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ルートのリストを取得します。

    $ oc get routes --all-namespaces | grep console
    Copy to Clipboard Toggle word wrap

    出力例

    openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
    openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None
    Copy to Clipboard Toggle word wrap

  3. ExternalDNS オブジェクトを定義する YAML ファイル (例: external-dns-sample-infoblox.yaml) を作成します。

    external-dns-sample-infoblox.yaml ファイルの例

    apiVersion: externaldns.olm.openshift.io/v1beta1
    kind: ExternalDNS
    metadata:
      name: sample-infoblox 
    1
    
    spec:
      provider:
        type: Infoblox 
    2
    
        infoblox:
          credentials:
            name: infoblox-credentials
          gridHost: ${INFOBLOX_GRID_PUBLIC_IP}
          wapiPort: 443
          wapiVersion: "2.3.1"
      domains:
      - filterType: Include
        matchType: Exact
        name: test.example.com
      source:
        type: OpenShiftRoute 
    3
    
        openshiftRouteOptions:
          routerName: default 
    4
    Copy to Clipboard Toggle word wrap

    1
    外部 DNS 名を指定します。
    2
    プロバイダータイプを定義します。
    3
    DNS レコードのソースのオプションを定義できます。
    4
    ソースタイプが OpenShiftRoute の場合、OpenShift Ingress Controller 名を渡すことができます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。
  4. 次のコマンドを実行して、Infoblox に ExternalDNS リソースを作成します。

    $ oc create -f external-dns-sample-infoblox.yaml
    Copy to Clipboard Toggle word wrap
  5. Infoblox UI から、console ルート用に作成された DNS レコードを確認します。

    1. Data ManagementDNSZones をクリックします。
    2. ゾーン名を選択します。

4.9. External DNS Operator でクラスター全体のプロキシーを設定する

クラスター全体のプロキシーを設定した後、Operator Lifecycle Manager (OLM) はデプロイされたすべての Operator に対して、HTTP_PROXYHTTPS_PROXY、および NO_PROXY 環境変数の新しい内容の自動更新をトリガーします。

4.9.1. クラスター全体のプロキシーの認証局を信頼する

External DNS Operator を設定して、クラスター全体のプロキシーの認証局を信頼できます。

手順

  1. 次のコマンドを実行して、external-dns-operator namespace に CA バンドルを含める config map を作成します。

    $ oc -n external-dns-operator create configmap trusted-ca
    Copy to Clipboard Toggle word wrap
  2. 信頼できる CA バンドルを config map に挿入するには、次のコマンドを実行して、config.openshift.io/inject-trusted-cabundle=true ラベルを config map に追加します。

    $ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、External DNS Operator のサブスクリプションを更新します。

    $ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'
    Copy to Clipboard Toggle word wrap

検証

  • External DNS Operator のデプロイメントが完了したら、次のコマンドを実行して、信頼できる CA 環境変数が external-dns-operator デプロイメントに追加され、trusted-ca として出力されていることを確認します。

    $ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
    Copy to Clipboard Toggle word wrap

第5章 MetalLB Operator

5.1. MetalLB および MetalLB Operator について

クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ LoadBalancer のサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。外部 IP アドレスがクラスターのホストネットワークに追加されます。

5.1.1. MetalLB を使用するタイミング

MetalLB の使用は、ベアメタルクラスター、またはベアメタルのようなインフラストラクチャーがある場合や、外部 IP アドレスを使用したアプリケーションへのフォールトトレラントがあるアクセスが必要な場合に役立ちます。

ネットワークインフラストラクチャーを設定し、外部 IP アドレスのネットワークトラフィックがクライアントからクラスターのホストネットワークにルーティングされるようにする必要があります。

MetalLB Operator を使用して MetalLB をデプロイした後、タイプ LoadBalancer のサービスを追加すると、MetalLB はプラットフォームネイティブなロードバランサーを提供します。

外部トラフィックが MetalLB LoadBalancer サービスを通じて OpenShift Container Platform クラスターに入ると、クライアントへの戻りトラフィックに、ロードバランサーの外部 IP アドレスがソース IP として含まれます。

レイヤ 2 モードで動作する MetalLB は、IP フェイルオーバーと同様のメカニズムを利用してフェイルオーバーをサポートします。ただし、仮想ルーター冗長プロトコル (VRRP) とキープアライブに依存する代わりに、MetalLB はゴシップベースのプロトコルを利用してノード障害のインスタンスを識別します。フェイルオーバーが検出されると、別のノードがリーダーノードのロールを引き継ぎ、Gratuitous ARP メッセージがディスパッチされて、この変更がブロードキャストされます。

レイヤ 3 またはボーダーゲートウェイプロトコル (BGP) モードで動作する MetalLB は、障害検出をネットワークに委任します。OpenShift Container Platform ノードが接続を確立した BGP ルーターは、ノードの障害を識別し、そのノードへのルートを終了します。

Pod とサービスの高可用性を確保するには、IP フェイルオーバーの代わりに MetalLB を使用することを推奨します。

5.1.2. MetalLB Operator カスタムリソース

MetalLB Operator は、次のカスタムリソースに対して独自の namespace を監視します。

MetalLB
MetalLB カスタムリソースをクラスターに追加する際に、MetalLB Operator は MetalLB をクラスターにデプロイします。Operator はカスタムリソースの単一インスタンスのみをサポートします。インスタンスが削除されると、Operator はクラスターから MetalLB を削除します。
IPAddressPool

MetalLB には、タイプ LoadBalancer のサービスを追加する際にサービスに割り当てることができる IP アドレスの 1 つ以上のプールが必要です。IPAddressPool には、IP アドレスのリストが含まれています。リストは、1.1.1.1-1.1.1.1 などの範囲を使用して設定された単一の IP アドレス、CIDR 表記で指定された範囲、ハイフンで区切られた開始アドレスと終了アドレスとして指定された範囲、またはこの 3 つの組み合わせにすることができます。IPAddressPool には名前が必要です。ドキュメントは、doc-exampledoc-example-reserveddoc-example-ipv6 などの名前を使用します。MetalLB controller は、IPAddressPool 内のアドレスのプールから IP アドレスを割り当てます。L2Advertisement および BGPAdvertisement カスタムリソースは、指定されたプールからの指定された IP のアドバタイズメントを有効にします。IPAddressPool カスタムリソースの IPAddressPool 仕様を使用して、spec.serviceAllocation からサービスと namespace に IP アドレスを割り当てることができます。

注記

単一の IPAddressPool は、L2 アドバタイズメントと BGP アドバタイズメントによって参照できます。

BGPPeer
BGP ピアカスタムリソースは、通信する MetalLB の BGP ルーター、ルーターの AS 番号、MetalLB の AS 番号、およびルートアドバタイズメントのカスタマイズを識別します。MetalLB は、サービスロードバランサーの IP アドレスのルートを 1 つ以上の BGP ピアにアドバタイズします。
BFDProfile
BFD プロファイルカスタムリソースは、BGP ピアの双方向フォワーディング検出 (BFD) を設定します。BFD は、BGP のみよりも、パスの障害検出が高速になります。
L2Advertisement
L2Advertisement カスタムリソースは、L2 プロトコルを使用して IPAddressPool からの IP をアドバタイズします。
BGPAdvertisement
BGPAdvertisement カスタムリソースは、BGP プロトコルを使用して IPAddressPool からの IP をアドバタイズします。

MetalLB カスタムリソースをクラスターに追加し、Operator が MetalLB をデプロイすると、controller および speaker MetalLB ソフトウェアコンポーネントは実行を開始します。

MetalLB は、関連するすべてのカスタムリソースを検証します。

5.1.3. MetalLB ソフトウェアコンポーネント

MetalLB Operator のインストール時に、metallb-operator-controller-manager デプロイメントは Pod を起動します。Pod は Operator の実装です。Pod は、関連するすべてのリソースへの変更を監視します。

Operator が MetalLB のインスタンスを起動すると、controller デプロイメントと speaker のデーモンセットが開始します。

注記

MetalLB カスタムリソースでデプロイメント仕様を設定して、controller および speaker Pod がクラスターへのデプロイおよび実行方法を管理できます。これらの展開仕様の詳細は、関連情報 セクションを参照してください。

controller

Operator はデプロイメントおよび単一の Pod を起動します。LoadBalancer タイプのサービスを追加する場合、Kubernetes は controller を使用してアドレスプールから IP アドレスを割り当てます。サービスに障害が発生した場合は、controller Pod のログに次のエントリーがあることを確認します。

出力例

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
Copy to Clipboard Toggle word wrap

speaker

Operator は、speaker Pod 用に設定されたデーモンを起動します。デフォルトでは、Pod はクラスター内の各ノードで起動されます。MetalLB の起動時に MetalLB カスタムリソースでノードセレクターを指定して、Pod を特定のノードに制限できます。controller がサービスに IP アドレスを割り当てても、サービスがまだ利用できない場合は、speaker Pod のログを確認してください。スピーカー Pod が使用できない場合は、oc describe pod -n コマンドを実行します。

レイヤー 2 モードの場合には、controller がサービスに IP アドレスを割り当てた後に、speaker Pod はアルゴリズムを使用して、どのノードの、どの speaker Pod がロードバランサーの IP アドレスをアナウンスするかを決定します。このアルゴリズムには、ノード名とロードバランサーの IP アドレスのハッシュが含まれます。詳細は、「MetalLB と外部トラフィックポリシー」を参照してください。speaker は、Address Resolution Protocol (ARP) を使用して IPv4 アドレスと Neighbor Discovery Protocol (NDP) を公開して、IPv6 アドレスにアナウンスします。

Border Gateway Protocol (BGP) モードの場合、コントローラー がサービスに IP アドレスを割り当てた後に、各 speaker Pod はロードバランサーの IP アドレスを BGP ピアにアドバタイズします。どのノードが BGP ピアとの BGP セッションを開始するかを設定できます。

ロードバランサーの IP アドレスの要求は、IP アドレスを通知する speaker でノードにルーティングされます。ノードがパケットを受信した後に、サービスプロキシーはパケットをサービスのエンドポイントにルーティングします。エンドポイントは、最適なケースでは同じノードに配置することも、別のノードに配置することもできます。サービスプロキシーは、接続が確立されるたびにエンドポイントを選択します。

5.1.4. MetalLB と外部トラフィックポリシー

レイヤー 2 モードでは、クラスター内のノードはサービス IP アドレスのすべてのトラフィックを受信します。BGP モードでは、ホストネットワーク上のルーターが、新しいクライアントが接続を確立できるように、クラスター内のノードの 1 つに接続を開きます。クラスターがノードに入った後にトラフィックを処理する方法は、外部トラフィックポリシーの影響を受けます。

cluster

これは spec.externalTrafficPolicy のデフォルト値です。

cluster トラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックをサービスのすべての Pod に分散します。このポリシーは、Pod 全体に均一なトラフィック分散を提供しますが、クライアントの IP アドレスを覆い隠し、トラフィックがクライアントではなくノードから発信されているように Pod 内のアプリケーションに表示される可能性があります。

local

local トラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックを同じノードの Pod にのみ送信します。たとえば、ノード A の speaker Pod が外部サービス IP をアナウンスすると、すべてのトラフィックがノード A に送信されます。トラフィックがノード A に入った後、サービスプロキシーはノード A にあるサービスの Pod にのみトラフィックを送信します。追加のノードにあるサービスの Pod は、ノード A からトラフィックを受信しません。追加のノードにあるサービスの Pod は、フェイルオーバーが必要な場合にレプリカとして機能します。

このポリシーは、クライアントの IP アドレスには影響しません。アプリケーション Pod は、受信接続からクライアント IP アドレスを判別できます。

注記

次の情報は、BGP モードで外部トラフィックポリシーを設定する場合に重要です。

MetalLB は、適格なすべてのノードからロードバランサーの IP アドレスをアドバタイズしますが、サービスのロードバランシングを行うノードの数は、等コストマルチパス (ECMP) ルートを確立するルーターの容量によって制限される場合があります。IP をアドバタイズするノードの数がルーターの ECMP グループ制限よりも多い場合、ルーターは IP をアドバタイズするノードよりも少ないノードを使用します。

たとえば、外部トラフィックポリシーが local に設定され、ルーターの ECMP グループ制限が 16 に設定され、LoadBalancer サービスを実装する Pod が 30 ノードにデプロイされている場合、14 ノードにデプロイされた Pod はトラフィックを受信しません。この状況では、サービスの外部トラフィックポリシーを cluster に設定することを推奨します。

5.1.5. レイヤー 2 モードの MetalLB の概念

レイヤー 2 モードでは、1 つのノードの speaker Pod が、サービスの外部 IP アドレスをホストネットワークに公開します。ネットワークの観点からは、ノードで複数の IP アドレスがネットワークインターフェイスに割り当てられるように見えます。

注記

レイヤ 2 モードでは、MetalLB は ARP と NDP に依存します。これらのプロトコルは、特定のサブネット内でローカルアドレス解決を実装します。このコンテキストでは、MetalLB が機能するために、クライアントは、サービスをアナウンスするノードと同じサブネット上に存在する MetalLB によって割り当てられた VIP に到達できなければなりません。

speaker Pod は、IPv4 サービスの ARP 要求と IPv6 の NDP 要求に応答します。

レイヤー 2 モードでは、サービス IP アドレスのすべてのトラフィックは 1 つのノードを介してルーティングされます。トラフィックがノードに入ると、CNI ネットワークプロバイダーのサービスプロキシーはトラフィックをサービスのすべての Pod に配信します。

サービスのすべてのトラフィックがレイヤー 2 モードで単一のノードを通過するので、より厳密な意味で、MetalLB はレイヤー 2 のロードバランサーを実装しません。むしろ、MetalLB はレイヤー 2 のフェイルオーバーメカニズムを実装しているため、speaker Pod が利用できなくなったときに、別のノードの speaker Pod がサービス IP アドレスをアナウンスできます。

ノードが使用できなくなると、フェイルオーバーが自動的に行われます。他のノードの speaker Pod は、ノードが使用できないことを検出し、障害が発生したノードから、新しい speaker Pod とノードがサービス IP アドレスの所有権を取得します。

前述のグラフは、MetalLB に関する以下の概念を示しています。

  • アプリケーションは、172.130.0.0/16 サブネットのクラスター IP を持つサービスで利用できます。その IP アドレスはクラスター内からアクセスできます。サービスには、MetalLB がサービス 192.168.100.200 に割り当てられている外部 IP アドレスもあります。
  • ノード 1 および 3 には、アプリケーションの Pod があります。
  • speaker デーモンセットは、各ノードで Pod を実行します。MetalLB Operator はこれらの Pod を起動します。
  • speaker Pod はホストネットワークを使用する Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。
  • ノード 1 の speaker Pod は ARP を使用して、サービスの外部 IP アドレスに 192.168.100.200 を認識します。外部 IP アドレスをアナウンスする speaker Pod は、サービスのエンドポイントと同じノード上にあり、エンドポイントは Ready 状態である必要があります。
  • クライアントトラフィックはホストネットワークにルーティングされ、192.168.100.200 の IP アドレスに接続します。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。

    • サービスの外部トラフィックポリシーが cluster に設定されている場合、speaker Pod が実行されているノードから 192.168.100.200 ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。
    • サービスの外部トラフィックポリシーが local に設定されている場合、speaker Pod が実行されているノードと少なくとも 1 つのサービスエンドポイントから 192.168.100.200 ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 1 または 3 のいずれかが 192.168.100.200 をアドバタイズします。
  • ノード 1 が利用できない場合、外部 IP アドレスは別のノードにフェイルオーバーします。アプリケーション Pod およびサービスエンドポイントのインスタンスを持つ別のノードでは、speaker Pod は外部 IP アドレス 192.168.100.200 になり、新規ノードがクライアントトラフィックを受信します。図では、唯一の候補はノード 3 です。

5.1.6. BGP モードの MetalLB の概念

BGP モードでは、デフォルトで各 speaker Pod がサービスのロードバランサー IP アドレスを各 BGP ピアにアドバタイズします。オプションの BGP ピアのリストを追加すると、指定されたプールからの IP を指定されたピアセットにアドバタイズすることもできます。BGP ピアは通常、BGP プロトコルを使用するように設定されたネットワークルーターです。ルーターがロードバランサーの IP アドレスのトラフィックを受信すると、ルーターは IP アドレスをアドバタイズした speaker Pod が含まれるノードの 1 つを選択します。ルーターはトラフィックをそのノードに送信します。トラフィックがノードに入ると、CNI ネットワークプラグインのサービスプロキシーはトラフィックをサービスのすべての Pod に配信します。

クラスターノードと同じレイヤー 2 のネットワークセグメントに直接接続されたルーターは、BGP ピアとして設定できます。直接接続されたルーターが BGP ピアとして設定されていない場合は、ロードバランサーの IP アドレスのパケットが BGP ピアと speaker Pod を実行するクラスターノードの間でルーティングされるようにネットワークを設定する必要があります。

ルーターは、ロードバランサーの IP アドレスの新しいトラフィックを受信するたびに、ノードへの新しい接続を作成します。各ルーターのメーカーには、接続開始ノードを選択する実装固有のアルゴリズムがあります。ただし、アルゴリズムは通常、ネットワーク負荷のバランスをとるために、使用可能なノード間でトラフィックを分散するように設計されています。

ノードが使用できなくなった場合に、ルーターは、ロードバランサーの IP アドレスをアドバタイズする speaker Pod が含まれる別のノードとの新しい接続を開始します。

図5.1 BGP モードの MetalLB トポロジーの図

前述のグラフは、MetalLB に関する以下の概念を示しています。

  • アプリケーションは、172.130.0.0/16 サブネットの IPv4 クラスター IP を持つサービスで利用できます。その IP アドレスはクラスター内からアクセスできます。サービスには、MetalLB がサービス 203.0.113.200 に割り当てられている外部 IP アドレスもあります。
  • ノード 2 および 3 には、アプリケーションの Pod があります。
  • speaker デーモンセットは、各ノードで Pod を実行します。MetalLB Operator はこれらの Pod を起動します。MetalLB を設定して、speaker Pod を実行するノードを指定できます。
  • speaker Pod はホストネットワークを使用する Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。
  • speaker Pod は、すべての BGP ピアとの BGP セッションを開始し、ロードバランサーの IP アドレスまたは集約されたルートを BGP ピアにアドバタイズします。speaker Pod は、Autonomous System 65010 の一部であることをアドバタイズします。この図ではルーター R1 を示しており、これは同じ Autonomous System 内の BGP ピアです。ただし、他の Autonomous System に属するピアとの BGP セッションを開始するように MetalLB を設定できます。
  • ノードに、ロードバランサーの IP アドレスをアドバタイズする speaker Pod がある場合にはすべて、サービスのトラフィックを受信できます。

    • サービスの外部トラフィックポリシーが cluster に設定されている場合、スピーカー Pod が実行されているすべてのノードが 203.0.113.200 ロードバランサーの IP アドレスをアドバタイズし、speaker Pod を持つすべてのノードがサービスのトラフィックを受信できます。ホストの接頭辞は、外部トラフィックポリシーが cluster に設定されている場合にのみ、ルーターピアにアドバタイズされます。
    • サービスの外部トラフィックポリシーが local に設定されている場合、speaker Pod が実行されているノードとサービスが実行されている少なくとも 1 つのエンドポイントが、203.0.113.200 ロードバランサーの IP アドレスをアドバタイズできます。これらのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 2 と 3 は 203.0.113.200 をアドバタイズします。
  • BGP ピアカスタムリソースの追加時にノードセレクターを指定して、特定の BGP ピアとの BGP セッションを開始する speaker Pod を制御するように MetalLB を設定できます。
  • BGP を使用するように設定されている R1 などのルーターは、BGP ピアとして設定できます。
  • クライアントトラフィックは、ホストネットワーク上のノードの 1 つにルーティングされます。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。
  • ノードが使用できなくなった場合に、ルーターは障害を検出し、別のノードとの新しい接続を開始します。BGP ピアに双方向フォワーディング検出 (BFD) プロファイルを使用するように MetalLB を設定できます。BFD は、リンク障害検出がより高速であるため、ルーターは BFD がない場合よりも早く新しい接続を開始できます。

5.1.7. 制限および制限

5.1.7.1. MetalLB のインフラストラクチャーに関する考慮事項

MetalLB は、ネイティブのロードバランサー機能が含まれていないため、主にオンプレミスのベアメタルインストールに役立ちます。ベアメタルのインストールに加え、一部のインフラストラクチャーに OpenShift Container Platform をインストールする場合は、ネイティブのロードバランサー機能が含まれていない場合があります。たとえば、以下のインフラストラクチャーは MetalLB Operator を追加するのに役立ちます。

  • ベアメタル
  • VMware vSphere
  • IBM Z® および IBM® LinuxONE
  • IBM Z® および IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
  • IBM Power®
5.1.7.2. レイヤー 2 モードの制限
5.1.7.2.1. 単一ノードのボトルネック

MetalLB は、1 つのノードを介してサービス内のすべてのトラフィックをルーティングします。この際、ノードはボトルネックとなり、パフォーマンスを制限する可能性があります。

レイヤー 2 モードは、サービスの Ingress 帯域幅を単一ノードの帯域幅に制限します。これは、ARP および NDP を使用してトラフィックを転送するための基本的な制限です。

5.1.7.2.2. フェイルオーバーのパフォーマンスの低下

ノード間のフェイルオーバーは、クライアントからの操作によって異なります。フェイルオーバーが発生すると、MetalLB は Gratuitous ARP パケットを送信して、サービス IP に関連付けられた MAC アドレスが変更されたことをクライアントに通知します。

ほとんどのクライアントオペレーティングシステムは、Gratuitous ARP パケットを正しく処理し、隣接キャッシュを迅速に更新します。クライアントがキャッシュを迅速に更新すると、フェイルオーバーは数秒以内に完了します。通常、クライアントは新しいノードに 10 秒以内にフェイルオーバーします。しかし、一部のクライアントオペレーティングシステムは Gratuitous ARP パケットをまったく処理しないか、キャッシュの更新を遅延させる古い実装があります。

Windows、macOS、Linux などの一般的なオペレーティングシステムの新しいバージョンは、レイヤー 2 フェイルオーバーを正しく実装します。フェイルオーバーが遅いという問題は、古くてあまり一般的ではないクライアントオペレーティングシステムを除いて、予期されていません。

古いクライアントで予定されているフェイルオーバーの影響を最小限にするには、リーダーシップをフラップした後に、古いノードを数分にわたって実行したままにします。古いノードは、キャッシュが更新されるまで、古いクライアントのトラフィックを転送することができます。

予定外のフェイルオーバー時に、古いクライアントがキャッシュエントリーを更新するまでサービス IP に到達できません。

5.1.7.2.3. 追加ネットワークと MetalLB は同じネットワークを使用できない

MetalLB とソース Pod 上に設定された追加のネットワークインターフェイスの両方に同じ VLAN を使用すると、接続エラーが発生する可能性があります。これは、MetalLB IP とソース Pod が同じノード上に存在する場合に発生します。

接続エラーを回避するには、ソース Pod が存在するサブネットとは異なるサブネットに MetalLB IP を配置します。この設定により、ソース Pod からのトラフィックがデフォルトゲートウェイを経由するようになります。その結果、トラフィックは OVN オーバーレイネットワークを使用して宛先に到達でき、接続が確実に意図したとおりに機能するようになります。

5.1.7.3. BGP モードの制限

MetalLB には、BGP ベースのロードバランシングに共通する制限があります。ノードに障害が発生した場合や speaker Pod が再起動した場合など、BGP セッションが中断されると、すべてのアクティブな接続がリセットされる可能性があります。エンドユーザーに、Connection reset by peer のメッセージが表示される可能性があります。

BGP セッションが中断された場合にどうなるかは、各ルーターの製造元の実装によります。ただし、speaker Pod の数を変更すると、BGP セッションの数に影響し、BGP ピアとのアクティブな接続が切断されることが予想されます。

サービスの中断の可能性を回避または低減するために、BGP ピアの追加時にノードセレクターを指定できます。BGP セッションを開始するノードの数を制限すると、BGP セッションのないノードでの障害が発生しても、サービスへの接続に影響はありません。

5.1.7.3.2. 単一の ASN とルーター ID のみのサポート

BGP ピアカスタムリソースを追加するときは、spec.myASN フィールドを指定して、MetalLB が属する AS 番号 (ASN) を特定します。OpenShift Container Platform は、MetalLB を使用した BGP の実装を使用しますが、この実装は MetalLB が単一の ASN に所属する必要があります。BGP ピアを追加し、spec.myASN に既存の BGP ピアカスタムリソースとは異なる値を指定しようとするとエラーが発生します。

同様に、BGP ピアカスタムリソースを追加する場合には、spec.routerID フィールドはオプションです。このフィールドに値を指定する場合は、追加する他の BGP ピアカスタムリソースすべてに、同じ値を指定する必要があります。

単一の ASN と単一のルーター ID のサポートに制限がある点が、コミュニティーがサポートする MetalLB の実装との違いです。

5.2. MetalLB Operator のインストール

クラスター管理者は、MetalLB Operator を追加して、クラスター上の MetalLB インスタンスのライフサイクルを Operator によって管理できます。

MetalLB および IP フェイルオーバーは互換性がありません。クラスターに IP フェイルオーバーを設定した場合は、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行してください。

5.2.1. Web コンソールを使用した OperatorHub からの MetalLB Operator のインストール

クラスター管理者は、OpenShift Container Platform Web コンソールを使用して MetalLB Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、metallb と入力して MetalLB Operator を見つけます。

    また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。

  3. Install Operator ページで、デフォルトを受け入れて Install をクリックします。

検証

  1. インストールが正常に行われたことを確認するには、以下を実行します。

    1. OperatorsInstalled Operators ページに移動します。
    2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。
  2. Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。

    1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
    2. WorkloadsPods ページにナビゲートし、問題を報告している openshift-operators プロジェクトの Pod のログを確認します。

5.2.2. CLI を使用した OperatorHub からのインストール

OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。OpenShift CLI (oc) を使用して、MetalLB Operator をインストールできます。

CLI を使用する場合は、metallb-system namespace に Operator をインストールすることを推奨します。

前提条件

  • ベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを入力して、MetalLB Operator の namespace を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  2. namespace に Operator グループのカスタムリソースを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap
  3. Operator グループが namespace にインストールされていることを確認します。

    $ oc get operatorgroup -n metallb-system
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               AGE
    metallb-operator   14m
    Copy to Clipboard Toggle word wrap

  4. Subscription CR を作成します。

    1. Subscription CR を定義し、YAML ファイルを保存します (例: metallb-sub.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator-sub
        namespace: metallb-system
      spec:
        channel: stable
        name: metallb-operator
        source: redhat-operators 
      1
      
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
      1
      redhat-operators 値を指定する必要があります。
    2. Subscription CR を作成するには、次のコマンドを実行します。

      $ oc create -f metallb-sub.yaml
      Copy to Clipboard Toggle word wrap
  5. オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
    Copy to Clipboard Toggle word wrap

検証

この検証手順は、MetalLB Operator が metallb-system namespace にインストールされていることを前提としています。

  1. インストール計画が namespace にあることを確認します。

    $ oc get installplan -n metallb-system
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            CSV                                   APPROVAL    APPROVED
    install-wzg94   metallb-operator.4.19.0-nnnnnnnnnnnn   Automatic   true
    Copy to Clipboard Toggle word wrap

    注記

    Operator のインストールには数秒かかる場合があります。

  2. Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に Succeeded と表示されていることを確認します。

    $ oc get clusterserviceversion -n metallb-system \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

5.2.3. クラスターでの MetalLB の起動

Operator のインストール後に、MetalLB カスタムリソースの単一のインスタンスを設定する必要があります。カスタムリソースの設定後、Operator はクラスターで MetalLB を起動します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。

手順

この手順は、MetalLB Operator が metallb-system namespace にインストールされていることを前提としています。Web コンソールを使用してインストールした場合は、namespace の代わりに openshift-operators を使用してください。

  1. MetalLB カスタムリソースの単一のインスタンスを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    EOF
    Copy to Clipboard Toggle word wrap

検証

MetalLB コントローラーのデプロイメントと、MetalLB スピーカーのデーモンセットが実行していることを確認します。

  1. コントローラーのデプロイメントが稼働していることを検証します。

    $ oc get deployment -n metallb-system controller
    Copy to Clipboard Toggle word wrap

    出力例

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    controller   1/1     1            1           11m
    Copy to Clipboard Toggle word wrap

  2. スピーカーに設定されているデーモンが実行されていることを検証します。

    $ oc get daemonset -n metallb-system speaker
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    speaker   6         6         6       6            6           kubernetes.io/os=linux   18m
    Copy to Clipboard Toggle word wrap

    この出力例は、6 つの speaker Pod を示しています。クラスターの speaker Pod の数は出力例とは異なる場合があります。出力で各ノードの 1 つの Pod が表示されることを確認します。

5.2.4. MetalLB のデプロイメント仕様

MetalLB カスタムリソースを使用して MetalLB のインスタンスを起動すると、MetalLB カスタムリソースでデプロイメント仕様を設定して、controller または speaker Pod がクラスターにデプロイし、実行する方法を管理できます。これらのデプロイメント仕様を使用して、以下のタスクを管理します。

  • MetalLB Pod デプロイメントのノードの選択
  • Pod の優先順位および Pod のアフィニティーを使用したケジューリングの管理
  • MetalLB Pod の CPU 制限の割り当て
  • MetalLB Pod のコンテナー RuntimeClass の割り当て
  • MetalLB Pod のメタデータの割り当て
5.2.4.1. speaker Pod の特定のノードへの限定

デフォルトでは、MetalLB Operator を使用して MetalLB を開始すると、Operator はクラスター内の各ノードで speaker Pod のインスタンスを開始します。ロードバランサーの IP アドレスをアドバタイズできるのは、speaker Pod を備えたノードのみです。ノードセレクターを使用して MetalLB カスタムリソースを設定し、speaker Pod を実行するノードを指定できます。

speaker Pod を特定のノードに制限する最も一般的な理由として、特定のネットワークにネットワークインターフェイスがあるノードのみがロードバランサーの IP アドレスをアドバタイズするようにすることが挙げられます。ロードバランサーの IP アドレスの宛先として、speaker Pod が実行されているノードのみがアドバタイズされます。

speaker Pod を特定のノードに制限し、サービスの外部トラフィックポリシーに local を指定する場合は、サービスのアプリケーション Pod が同じノードにデプロイされていることを確認する必要があります。

speaker Pod をワーカーノードに制限する設定例

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  
1

    node-role.kubernetes.io/worker: ""
  speakerTolerations:   
2

  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"
Copy to Clipboard Toggle word wrap

1
この設定例では、speaker Pod をワーカーノードに割り当てるように指定していますが、ノードまたは任意の有効なノードセレクターに割り当てたラベルを指定できます。
2
この設定例では、operator を使用して toleration が割り当てらた Pod で keyeffect の値と合致する taint が許容されます。

spec.nodeSelector フィールドを使用してマニフェストを適用した後、oc get daemonset -n metallb-system speaker コマンドを使用して、Operator がデプロイした Pod の数を確認できます。同様に、oc get nodes -l node-role.kubernetes.io/worker= のようなコマンドを使用して、ラベルに一致するノードを表示できます。

オプションで、アフィニティールールを使用して、ノードがどの speaker Pod をスケジュールするか、スケジュールしないかを制御することができます。また、toleration の一覧を適用してこれらの Pod を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。

5.2.4.2. MetalLB デプロイメントでの Pod の優先順位および Pod アフィニティーの設定

オプションで、MetalLB カスタムリソースを設定して、Pod の優先順位と Pod のアフィニティールールを controller Pod および speaker Pod に割り当てることができます。Pod の優先順位は、ノード上の Pod の相対的な重要度を示し、この優先順位に基づいて Pod をスケジュールします。controller または speaker Pod に高い優先順位を設定して、ノード上の他の Pod よりも優先的にスケジューリングされるようにします。

Pod のアフィニティーは Pod 間の関係を管理します。Pod のアフィニティーを controller または speaker Pod に割り当て、スケジューラーが Pod 関係のコンテキストで Pod を配置するノードを制御します。たとえば、Pod アフィニティールールを使用して、複数の特定 Pod を同じノードまたは別のノードに配置するようにできます。これにより、ネットワーク通信が改善され、これらのコンポーネント間の遅延が縮小されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。
  • クラスター上で MetalLB Operator を開始している。

手順

  1. myPriorityClass.yaml などの PriorityClass カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority という名前の PriorityClass を、値 1000000 で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。

    apiVersion: scheduling.k8s.io/v1
    kind: PriorityClass
    metadata:
      name: high-priority
    value: 1000000
    Copy to Clipboard Toggle word wrap
  2. PriorityClass カスタムリソース設定を適用します。

    $ oc apply -f myPriorityClass.yaml
    Copy to Clipboard Toggle word wrap
  3. MetalLBPodConfig.yaml などの MetalLB カスタムリソースを作成して、priorityClassNamepodAffinity の値を指定します。

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        priorityClassName: high-priority 
    1
    
        affinity:
          podAffinity: 
    2
    
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
      speakerConfig:
        priorityClassName: high-priority
        affinity:
          podAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                 app: metallb
              topologyKey: kubernetes.io/hostname
    Copy to Clipboard Toggle word wrap
    1
    MetalLB コントローラー Pod の優先クラスを指定します。この場合、high-priority に設定されます。
    2
    Pod アフィニティールールを設定していることを指定します。これらのルールは、他の Pod またはノードに関連して Pod がどのようにスケジュールされるかを決定します。この設定は、app: metallb ラベルを持つ Pod を同じホスト名を共有するノードにスケジュールするようにスケジューラーに指示します。これは、MetalLB 関連の Pod を同じノード上に配置するのに役立ち、これらの Pod 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。
  4. MetalLB カスタムリソース設定を適用します。

    $ oc apply -f MetalLBPodConfig.yaml
    Copy to Clipboard Toggle word wrap

検証

  • metallb-system namespace の Pod に割り当てた優先クラスを表示するには、次のコマンドを実行します。

    $ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                 PRIORITY
    controller-584f5c8cd8-5zbvg                          high-priority
    metallb-operator-controller-manager-9c8d9985-szkqg   <none>
    metallb-operator-webhook-server-c895594d4-shjgx      <none>
    speaker-dddf7                                        high-priority
    Copy to Clipboard Toggle word wrap

  • スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示します。

    $ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
    Copy to Clipboard Toggle word wrap
5.2.4.3. MetalLB デプロイメントでの Pod CPU 制限の設定

オプションで、MetalLB カスタムリソースを設定することで、Pod の CPU 制限を controller Pod と speaker Pod に割り当てることができます。controller Pod または speaker Pod の CPU 制限を定義すると、ノード上のコンピュートリソースを管理するのに役立ちます。これにより、ノード上のすべての Pod に、ワークロードとクラスターのハウスキーピングを管理するために必要なコンピューティングリソースが確保されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。

手順

  1. CPULimits.yaml などの MetalLB カスタムリソースファイルを作成し、コントローラー および speaker Pod の cpu 値を指定します。

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      logLevel: debug
      controllerConfig:
        resources:
          limits:
            cpu: "200m"
      speakerConfig:
        resources:
          limits:
            cpu: "300m"
    Copy to Clipboard Toggle word wrap
  2. MetalLB カスタムリソース設定を適用します。

    $ oc apply -f CPULimits.yaml
    Copy to Clipboard Toggle word wrap

検証

  • Pod のコンピューティングリソースを表示するには、次のコマンドを実行し、<pod_name> をターゲット Pod に置き換えます。

    $ oc describe pod <pod_name>
    Copy to Clipboard Toggle word wrap

5.2.6. 次のステップ

5.3. MetalLB Operator のアップグレード

デフォルトで namespace を metallb-system にサブスクライブする Subscription カスタムリソース (CR) は、installPlanApproval パラメーターを Automatic に自動的に設定します。そのため、Red Hat が提供する Operator カタログに MetalLB Operator の新しいバージョンが含まれている場合、その MetalLB Operator は自動的にアップグレードされます。

MetalLB Operator のアップグレードを手動で制御する必要がある場合は、installPlanApproval パラメーターを Manual に設定します。

5.3.1. MetalLB Operator の手動アップグレード

MetalLB Operator のアップグレードを手動で制御するには、namespace を metallb-system にサブスクライブする Subscription カスタムリソース (CR) を編集する必要があります。Subscription CR は Operator のインストール中に作成されます。この CR の installPlanApproval パラメーターは、デフォルトで Automatic に設定されます。

前提条件

  • クラスターを最新の z-stream リリースに更新した。
  • OperatorHub を使用して MetalLB Operator をインストールした。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。

手順

  1. 次のコマンドを入力して、metallb-system namespace 内の metallb-operator サブスクリプションの YAML 定義を取得します。

    $ oc -n metallb-system get subscription metallb-operator -o yaml
    Copy to Clipboard Toggle word wrap
  2. installPlanApproval パラメーターを Manual に設定して、Subscription CR を編集します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: metallb-operator
      namespace: metallb-system
    # ...
    spec:
       channel: stable
       installPlanApproval: Manual
       name: metallb-operator
       source: redhat-operators
       sourceNamespace: openshift-marketplace
    # ...
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、最新の OpenShift Container Platform 4.19 バージョンの MetalLB Operator を見つけます。

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、namespace に存在するインストールプランを確認します。

    $ oc -n metallb-system get installplan
    Copy to Clipboard Toggle word wrap

    手動インストールプランとして install-tsz2g が表示された出力例

    NAME            CSV                                     APPROVAL    APPROVED
    install-shpmd   metallb-operator.v4.19.0-202502261233   Automatic   true
    install-tsz2g   metallb-operator.v4.19.0-202503102139   Manual      false
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、namespace に存在するインストールプランを編集します。<name_of_installplan> は、install-tsz2g などのインストールプランの名前に置き換えてください。

    $ oc edit installplan <name_of_installplan> -n metallb-system
    Copy to Clipboard Toggle word wrap
    1. エディターでインストールプランを開いた状態で、spec.approval パラメーターを Manual に設定し、spec.approved パラメーターを true に設定します。

      注記

      インストールプランを編集すると、アップグレード操作が開始します。アップグレード操作中に oc -n metallb-system get csv コマンドを入力すると、出力に Replacing または Pending ステータスが表示される場合があります。

検証

  • Operator がアップグレードされたことを確認するには、次のコマンドを入力し、、Operator に対して出力に Succeeded と表示されていることを確認します。

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap

5.3.2. 関連情報

第6章 OpenShift Container Platform における Cluster Network Operator

Cluster Network Operator (CNO) を使用すると、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインを含む、OpenShift Container Platform クラスター上のクラスターネットワークコンポーネントをデプロイおよび管理できます。

6.1. Cluster Network Operator

Cluster Network Operator は、operator.openshift.io API グループから network API を実装します。Operator は、デーモンセットを使用して、クラスターのインストール中に選択した OVN-Kubernetes ネットワークプラグインまたはネットワークプロバイダープラグインをデプロイします。

手順

Cluster Network Operator は、インストール時に Kubernetes Deployment としてデプロイされます。

  1. 以下のコマンドを実行して Deployment のステータスを表示します。

    $ oc get -n openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m
    Copy to Clipboard Toggle word wrap

  2. 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。

    $ oc get clusteroperator/network
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.16.1     True        False         False      50m
    Copy to Clipboard Toggle word wrap

    以下のフィールドは、Operator のステータス (AVAILABLEPROGRESSING、および DEGRADED) に関する情報を提供します。AVAILABLE フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合に True になります。

6.2. クラスターネットワーク設定の表示

すべての新規 OpenShift Container Platform インストールには、cluster という名前の network.config オブジェクトがあります。

手順

  • oc describe コマンドを使用して、クラスターネットワーク設定を表示します。

    $ oc describe network.config/cluster
    Copy to Clipboard Toggle word wrap

    出力例

    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Creation Timestamp:  2024-08-08T11:25:56Z
      Generation:          3
      Resource Version:    29821
      UID:                 808dd2be-5077-4ff7-b6bb-21b7110126c7
    Spec: 
    1
    
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      External IP:
        Policy:
      Network Diagnostics:
        Mode:
        Source Placement:
        Target Placement:
      Network Type:  OVNKubernetes
      Service Network:
        172.30.0.0/16
    Status: 
    2
    
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  1360
      Conditions:
        Last Transition Time:  2024-08-08T11:51:50Z
        Message:
        Observed Generation:   0
        Reason:                AsExpected
        Status:                True
        Type:                  NetworkDiagnosticsAvailable
      Network Type:            OVNKubernetes
      Service Network:
        172.30.0.0/16
    Events:  <none>
    Copy to Clipboard Toggle word wrap

    1
    Spec フィールドは、クラスターネットワークの設定済みの状態を表示します。
    2
    Status フィールドは、クラスターネットワークの現在の状態を表示します。

6.3. Cluster Network Operator のステータス表示

oc describe コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。

手順

  • 以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。

    $ oc describe clusteroperators/network
    Copy to Clipboard Toggle word wrap

6.4. IP 転送をグローバルに有効にする

OpenShift Container Platform 4.14 以降では、OVN-Kubernetes ベースのクラスターデプロイメントでグローバル IP アドレス転送が無効になります。これは、ルーターとして機能するノードによる、クラスター管理者にとって望ましくない影響を防ぐためです。ただし、トラフィックの転送が必要な場合には、すべての IP トラフィックの転送を許可する新しい設定パラメーター ipForwarding を利用できます。

OVN-Kubernetes 管理インターフェイス上の全トラフィックの IP 転送を再度有効にするには、次の手順に従って、Cluster Network Operator の gatewayConfig.ipForwarding 仕様を Global に設定します。

手順

  1. 次のコマンドを実行して、既存のネットワーク設定をバックアップします。

    $ oc get network.operator cluster -o yaml > network-config-backup.yaml
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、既存のネットワーク設定を変更します。

    $ oc edit network.operator cluster
    Copy to Clipboard Toggle word wrap
    1. 次の例に示すように、spec の下に次のブロックを追加または更新します。

      spec:
        clusterNetwork:
        - cidr: 10.128.0.0/14
          hostPrefix: 23
        serviceNetwork:
        - 172.30.0.0/16
        networkType: OVNKubernetes
        clusterNetworkMTU: 8900
        defaultNetwork:
          ovnKubernetesConfig:
            gatewayConfig:
              ipForwarding: Global
      Copy to Clipboard Toggle word wrap
    2. ファイルを保存してから閉じます。
  3. 変更を適用した後、OpenShift Cluster Network Operator (CNO) によってクラスター全体に更新が適用されます。次のコマンドを使用して進行状況を監視できます。

    $ oc get clusteroperators network
    Copy to Clipboard Toggle word wrap

    最終的に、ステータスに AvailableProgressing=FalseDegraded=False と報告されるはずです。

  4. または、次のコマンドを実行して、IP 転送をグローバルに有効にすることもできます。

    $ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
    Copy to Clipboard Toggle word wrap
    注記

    この変更を元に戻す必要がある場合は、このパラメーターのもう 1 つの有効なオプションである Restricted を設定します。デフォルトでは Restricted に設定されており、グローバル IP アドレス転送は無効です。

6.5. Cluster Network Operator ログの表示

oc logs コマンドを使用して、Cluster Network Operator ログを表示できます。

手順

  • 以下のコマンドを実行して、Cluster Network Operator のログを表示します。

    $ oc logs --namespace=openshift-network-operator deployment/network-operator
    Copy to Clipboard Toggle word wrap

6.6. Cluster Network Operator の設定

クラスターネットワークの設定は、Cluster Network Operator (CNO) 設定の一部として指定され、cluster という名前のカスタムリソース (CR) オブジェクトに保存されます。CR は operator.openshift.io API グループの Network API のフィールドを指定します。

CNO 設定は、Network.config.openshift.io API グループの Network API からクラスターのインストール時に以下のフィールドを継承します。

clusterNetwork
Pod IP アドレスの割り当てに使用する IP アドレスプール。
serviceNetwork
サービスの IP アドレスプール。
defaultNetwork.type
クラスターネットワークプラグイン。OVNKubernetes は、インストール時にサポートされる唯一のプラグインです。
注記

クラスターをインストールした後は、clusterNetwork IP アドレス範囲のみ変更できます。

defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。

6.6.1. Cluster Network Operator 設定オブジェクト

Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。

Expand
表6.1 Cluster Network Operator 設定オブジェクト
フィールド説明

metadata.name

string

CNO オブジェクトの名前。この名前は常に cluster です。

spec.clusterNetwork

array

Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。

spec:
  clusterNetwork:
  - cidr: 10.128.0.0/19
    hostPrefix: 23
  - cidr: 10.128.32.0/19
    hostPrefix: 23
Copy to Clipboard Toggle word wrap

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。

spec:
  serviceNetwork:
  - 172.30.0.0/14
Copy to Clipboard Toggle word wrap

この値は読み取り専用であり、クラスターのインストール時に cluster という名前の Network.config.openshift.io オブジェクトから継承されます。

spec.defaultNetwork

object

クラスターネットワークのネットワークプラグインを設定します。

spec.kubeProxyConfig

object

このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

重要

複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。

defaultNetwork オブジェクト設定

defaultNetwork オブジェクトの値は、以下の表で定義されます。

Expand
表6.2 defaultNetwork オブジェクト
フィールド説明

type

string

OVNKubernetes。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。

ovnKubernetesConfig

object

このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

OVN-Kubernetes ネットワークプラグインの設定

次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。

Expand
表6.3 ovnKubernetesConfig オブジェクト
フィールド説明

mtu

integer

Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。通常、この値は自動的に設定されます。

genevePort

integer

Geneve オーバーレイネットワークの UDP ポート。

ipsecConfig

object

クラスターの IPsec モードを示すオブジェクト。

ipv4

object

IPv4 設定の設定オブジェクトを指定します。

ipv6

object

IPv6 設定の設定オブジェクトを指定します。

policyAuditConfig

object

ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。

gatewayConfig

object

オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は SharedLocal です。デフォルト値は Shared です。デフォルト設定では、Open vSwitch (OVS) がトラフィックをノード IP インターフェイスに直接出力します。Local 設定では、トラフィックがホストネットワークを通過し、その結果、ホストのルーティングテーブルに適用されます。

注記

Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

Expand
表6.4 ovnKubernetesConfig.ipv4 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが 100.88.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。east-west トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は 100.88.0.0/16 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが 100.64.0.0/16 IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、clusterNetwork.cidr 値が 10.128.0.0/14 で、clusterNetwork.hostPrefix 値が /23 の場合、ノードの最大数は 2^(23-14)=512 です。

デフォルト値は 100.64.0.0/16 です。

Expand
表6.5 ovnKubernetesConfig.ipv6 object
フィールド説明

internalTransitSwitchSubnet

string

既存のネットワークインフラストラクチャーが fd97::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。east-west トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。

デフォルト値は fd97::/64 です。

internalJoinSubnet

string

既存のネットワークインフラストラクチャーが fd98::/64 IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。

デフォルト値は fd98::/64 です。

Expand
表6.6 policyAuditConfig オブジェクト
フィールド説明

rateLimit

integer

ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり 20 メッセージです。

maxFileSize

integer

監査ログの最大サイズ (バイト単位)。デフォルト値は 50000000 (50MB) です。

maxLogFiles

integer

保持されるログファイルの最大数。

destination

string

以下の追加の監査ログターゲットのいずれかになります。

libc
ホスト上の journald プロセスの libc syslog() 関数。
udp:<host>:<port>
syslog サーバー。<host>:<port> を syslog サーバーのホストおよびポートに置き換えます。
unix:<file>
<file> で指定された Unix ドメインソケットファイル。
null
監査ログを追加のターゲットに送信しないでください。

syslogFacility

string

RFC5424 で定義される kern などの syslog ファシリティー。デフォルト値は local0 です。

Expand
表6.7 gatewayConfig オブジェクト
フィールド説明

routingViaHost

boolean

Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを true に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は false です。

このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを true に設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。

ipForwarding

object

Network リソースの ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは Global です。

注記

デフォルト値の Restricted では、IP 転送がドロップされるように設定されます。

ipv4

object

オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

ipv6

object

オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

Expand
表6.8 gatewayConfig.ipv4 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 169.254.169.0/29 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして 169.254.0.0/17 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

Expand
表6.9 gatewayConfig.ipv6 object
フィールド説明

internalMasqueradeSubnet

string

ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は fd69::/125 です。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして fd69::/112 を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

Expand
表6.10 ipsecConfig オブジェクト
フィールド説明

mode

string

IPsec 実装の動作を指定します。次の値のいずれかである必要があります。

  • Disabled: クラスターノードで IPsec が有効になりません。
  • External: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
  • Full: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。
注記

クラスターのインストール中にのみクラスターネットワークプラグインの設定を変更できます。ただし、インストール後のアクティビティーとして実行時に変更できる gatewayConfig フィールドは除きます。

IPSec が有効な OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full
Copy to Clipboard Toggle word wrap

6.6.2. Cluster Network Operator の設定例

以下の例では、詳細な CNO 設定が指定されています。

Cluster Network Operator オブジェクトのサンプル

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
Copy to Clipboard Toggle word wrap

第7章 OpenShift Container Platform の DNS Operator

OpenShift Container Platform の DNS Operator は、CoreDNS インスタンスをデプロイおよび管理して、クラスター内の Pod に名前解決サービスを提供し、DNS ベースの Kubernetes Service 検出を有効にし、内部の cluster.local 名を解決します。

7.1. DNS Operator のステータスの確認

DNS Operator は、operator.openshift.io API グループから dns API を実装します。この Operator は、デーモンセットを使用して CoreDNS をデプロイし、デーモンセットのサービスを作成し、kubelet を Pod に対して名前解決に CoreDNS サービス IP を使用するように指示するように設定します。

手順

DNS Operator は、インストール時に Deployment オブジェクトを使用してデプロイされます。

  1. oc get コマンドを使用してデプロイメントのステータスを表示します。

    $ oc get -n openshift-dns-operator deployment/dns-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h
    Copy to Clipboard Toggle word wrap

  2. oc get コマンドを使用して DNS Operator の状態を表示します。

    $ oc get clusteroperator/dns
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    dns       4.1.15-0.11  True        False         False      92m
    Copy to Clipboard Toggle word wrap

    AVAILABLEPROGRESSING、および DEGRADED は、Operator のステータスに関する情報を示します。AVAILABLETrue になるのは、CoreDNS デーモンセットの 1 つ以上の Pod が AVAILABLE ステータス条件を報告し、DNS サービスがクラスター IP アドレスを持っている場合です。

7.2. デフォルト DNS の表示

すべての新規 OpenShift Container Platform インストールには、default という名前の dns.operator があります。

手順

  1. oc describe コマンドを使用してデフォルトの dns を表示します。

    $ oc describe dns.operator/default
    Copy to Clipboard Toggle word wrap

    出力例

    Name:         default
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         DNS
    ...
    Status:
      Cluster Domain:  cluster.local 
    1
    
      Cluster IP:      172.30.0.10 
    2
    
    ...
    Copy to Clipboard Toggle word wrap

    1
    Cluster Domain フィールドは、完全修飾 Pod およびサービスドメイン名を作成するために使用されるベース DNS ドメインです。
    2
    クラスター IP は、Pod が名前解決のためにクエリーするアドレスです。IP は、サービス CIDR 範囲の 10 番目のアドレスで定義されます。
  2. クラスターのサービス CIDR 範囲 (172.30.0.0/16 など) を確認するには、oc get コマンドを使用します。

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
    Copy to Clipboard Toggle word wrap

7.3. DNS 転送の使用

次の方法で、DNS 転送を使用して /etc/resolv.conf ファイル内のデフォルトの転送設定をオーバーライドできます。

  • すべてのゾーンにネームサーバー (spec.servers) を指定します。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、そのドメインに対してアップストリームのネームサーバーが許可されている必要があります。
  • アップストリーム DNS サーバーのリスト (spec.upstreamResolvers) を指定します。
  • デフォルトの転送ポリシーを変更します。
注記

デフォルトドメインの DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。

手順

  1. default という名前の DNS Operator オブジェクトを変更します。

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    上記のコマンドを実行すると、Operator が、spec.servers に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成および更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。

    DNS 転送の設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        negativeTTL: 0s
        positiveTTL: 0s
      logLevel: Normal
      nodePlacement: {}
      operatorLogLevel: Normal
      servers:
      - name: example-server 
    1
    
        zones:
        - example.com 
    2
    
        forwardPlugin:
          policy: Random 
    3
    
          upstreams: 
    4
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    5
    
        policy: Random 
    6
    
        protocolStrategy: ""  
    7
    
        transportConfig: {}  
    8
    
        upstreams:
        - type: SystemResolvConf 
    9
    
        - type: Network
          address: 1.2.3.4 
    10
    
          port: 53 
    11
    
        status:
          clusterDomain: cluster.local
          clusterIP: x.y.z.10
          conditions:
    ...
    Copy to Clipboard Toggle word wrap

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。
    3
    forwardPlugin にリストされているアップストリームリゾルバーを選択するポリシーを定義します。デフォルト値は Random です。RoundRobin および Sequential の値を使用することもできます。
    4
    forwardPlugin ごとに最大 15 の upstreams が許可されます。
    5
    upstreamResolvers を使用すると、デフォルトの転送ポリシーをオーバーライドし、デフォルトドメインの指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを提供しなかった場合、DNS 名のクエリーが /etc/resolv.conf で宣言されたサーバーに送信されます。
    6
    upstreams にリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。RandomRoundRobin、または Sequential のいずれかの値を指定できます。デフォルト値は Sequential です。
    7
    省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。TCP に設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。
    8
    DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
    9
    2 種類の upstreams (SystemResolvConf または Network) を指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、NetworkNetworkresolver を定義します。1 つまたは両方を指定できます。
    10
    指定したタイプが Network の場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    11
    指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドには 1 - 65535 の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。

7.4. DNS Operator のステータスの確認

oc describe コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。

手順

  • DNS Operator のステータスを表示します。

    $ oc describe clusteroperators/dns
    Copy to Clipboard Toggle word wrap

    メッセージとスペルはリリースによって異なる場合がありますが、期待されるステータス出力は次のようになります。

    Status:
      Conditions:
        Last Transition Time:  <date>
        Message:               DNS "default" is available.
        Reason:                AsExpected
        Status:                True
        Type:                  Available
        Last Transition Time:  <date>
        Message:               Desired and current number of DNSes are equal
        Reason:                AsExpected
        Status:                False
        Type:                  Progressing
        Last Transition Time:  <date>
        Reason:                DNSNotDegraded
        Status:                False
        Type:                  Degraded
        Last Transition Time:  <date>
        Message:               DNS default is upgradeable: DNS Operator can be upgraded
        Reason:                DNSUpgradeable
        Status:                True
        Type:                  Upgradeable
    Copy to Clipboard Toggle word wrap

7.5. DNS Operator のログの表示

oc logs コマンドを使用して、DNS Operator ログを表示できます。

手順

  • DNS Operator のログを表示します。

    $ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
    Copy to Clipboard Toggle word wrap

7.6. CoreDNS ログレベルの設定

CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。CoreDNS ログレベルを設定して、ログに記録されたエラーメッセージの情報量を決定できます。CoreDNS ログレベルの有効な値は、NormalDebug、および Trace です。デフォルトの logLevelNormal です。

注記

CoreDNS のエラーログレベルは常に有効です。次のログレベル設定では、それぞれ異なるエラー応答が報告されます。

  • logLevel: Normal は "errors" class: log . { class error } を有効にします。
  • logLevel: Debug は "denial" class: log . { class denial error } を有効にします。
  • logLevel: Trace は "all" class: log . { class all } を有効にします。

手順

  • logLevelDebug に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • logLevelTrace に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

検証

  • 目的のログレベルが設定されていることを確認するには、config map を確認します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

    たとえば、logLevelTrace に設定すると、各サーバーブロックに次のスタンザが表示されます。

    errors
    log . {
        class all
    }
    Copy to Clipboard Toggle word wrap

7.7. CoreDNS ログの表示

oc logs コマンドを使用して CoreDNS ログを表示できます。

手順

  • 特定の CoreDNS Pod のログを表示するには、次のコマンドを入力します。

    $ oc -n openshift-dns logs -c dns <core_dns_pod_name>
    Copy to Clipboard Toggle word wrap
  • すべての CoreDNS Pod のログを追跡するには、次のコマンドを入力します。

    $ oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number> 
    1
    Copy to Clipboard Toggle word wrap
    1
    ログをストリーミングする DNS Pod の数を指定します。最大は 6 です。

7.8. CoreDNS Operator のログレベルの設定

CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel の有効な値は、NormalDebug、および Trace です。Trace には最も詳細にわたる情報が含まれます。デフォルトの operatorlogLevelNormal です。Operator の問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal、および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。

  • operatorLogLevel: "Normal"logrus.SetLogLevel("Info") を設定します。
  • operatorLogLevel: "Debug"logrus.SetLogLevel("Debug") を設定します。
  • operatorLogLevel: "Trace"logrus.SetLogLevel("Trace") を設定します。

手順

  • operatorLogLevelDebug に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  • operatorLogLevelTrace に設定するには、次のコマンドを入力します。

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
    Copy to Clipboard Toggle word wrap

検証

  1. 結果の変更を確認するには、次のコマンドを入力します。

    $ oc get dnses.operator -A -oyaml
    Copy to Clipboard Toggle word wrap

    2 つのログレベルのエントリーが表示されるはずです。operatorLogLevel は OpenShift DNS Operator の問題に適用され、logLevel は CoreDNS Pod のデーモンセットに適用されます。

     logLevel: Trace
     operatorLogLevel: Debug
    Copy to Clipboard Toggle word wrap
  2. デーモンセットのログを確認するには、次のコマンドを入力します。

    $ oc logs -n openshift-dns ds/dns-default
    Copy to Clipboard Toggle word wrap

7.9. CoreDNS キャッシュのチューニング

CoreDNS の場合、成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間をチューニングすると、アップストリーム DNS リゾルバーの負荷を軽減できます。

警告

TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。

手順

  1. 次のコマンドを実行して、default という名前の DNS Operator オブジェクトを編集します。

    $ oc edit dns.operator.openshift.io/default
    Copy to Clipboard Toggle word wrap
  2. Time-to-Live (TTL) キャッシュ値を変更します。

    DNS キャッシングの設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        positiveTTL: 1h 
    1
    
        negativeTTL: 0.5h10m 
    2
    Copy to Clipboard Toggle word wrap

    1
    文字列値 1h は、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 900 を使用します。
    2
    文字列値は、0.5h10m などの単位の組み合わせにすることができ、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 30 を使用します。

検証

  1. 変更を確認するには、次のコマンドを実行して config map を再度確認します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap
  2. 次の例のようなエントリーが表示されていることを確認します。

           cache 3600 {
                denial 9984 2400
            }
    Copy to Clipboard Toggle word wrap

7.10. 高度なタスク

7.10.1. DNS Operator managementState の変更

DNS Operator は、CoreDNS コンポーネントを管理し、クラスター内の Pod とサービスに名前解決サービスを提供します。DNS Operator の managementState は、デフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理していることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

  • 開発者は、CoreDNS の問題が修正されているかどうかを確認するために、設定変更をテストする必要があります。managementStateUnmanaged に設定することで、DNS Operator による設定変更の上書きを防止できます。
  • クラスター管理者は、CoreDNS の問題を報告していますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の managementState フィールドを Unmanaged に設定して、回避策を適用できます。

手順

  1. DNS Operator の managementStateUnmanaged に変更します。

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
    Copy to Clipboard Toggle word wrap
  2. jsonpath コマンドライン JSON パーサーを使用して DNS Operator の managementState を確認します。

    $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
    Copy to Clipboard Toggle word wrap
    注記

    managementStateUnmanaged に設定されている間はアップグレードできません。

7.10.2. DNS Pod 配置の制御

DNS Operator には 2 つのデーモンセットがあります。1 つは CoreDNS 用の dns-default という名前のデーモンセットで、もう 1 つは /etc/hosts ファイルの管理用の node-resolver という名前のデーモンセットです。

指定したノードに CoreDNS Pod を割り当て、そのノード上で実行できます。たとえば、クラスター管理者がノードペア間の通信を禁止するセキュリティーポリシーを設定している場合は、制限されたノードセットで実行するように CoreDNS Pod を設定できます。

次の状況が当てはまる場合、すべての Pod で DNS サービスを使用できます。

  • クラスター内の一部のノードで DNS Pod が実行されている。
  • DNS Pod が実行されていないノードに、DNS Pod が実行されているノードとのネットワーク接続がある。

node-resolver デーモンセットは、すべてのノードホストで実行する必要があります。このデーモンセットにより、イメージのプルをサポートするクラスターイメージレジストリーのエントリーが追加されるためです。node-resolver Pod には、1 つのジョブのみがあります。コンテナーランタイムがサービス名を解決できるように、image-registry.openshift-image-registry.svc サービスのクラスター IP アドレスを検索し、それをノードホストの /etc/hosts に追加するジョブです。

クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。

前提条件

  • oc CLI がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
  • DNS Operator の managementStateManaged に設定されている。

手順

  • CoreDNS のデーモンセットを特定のノードで実行できるようにするために、taint と toleration を設定します。

    1. 次のコマンドを入力して、DNS Pod の配置を制御するノードに taint を設定します。

      $ oc adm taint nodes <node_name> dns-only=abc:NoExecute 
      1
      Copy to Clipboard Toggle word wrap
      1
      <node_name> は、ノードの実際の名前に置き換えます。
    2. 次のコマンドを入力して、default という名前の DNS Operator オブジェクトを、対応する toleration が含まれるように変更します。

      $ oc edit dns.operator/default
      Copy to Clipboard Toggle word wrap
    3. taint の taint キーと toleration を指定します。次の toleration は、ノードに設定された taint と一致します。

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only" 
      1
      
             operator: Equal
             value: abc
             tolerationSeconds: 3600 
      2
      Copy to Clipboard Toggle word wrap
      1
      key フィールドが dns-only に設定されている場合、永久的に許容されます。
      2
      tolerationSeconds フィールドはオプションです。
    4. オプション: ノードセレクターを使用してノードの配置を指定するには、デフォルトの DNS Operator を変更します。

      1. default という名前の DNS Operator オブジェクトを編集して、ノードセレクターを含めます。

         spec:
           nodePlacement:
             nodeSelector:    
        1
        
               node-role.kubernetes.io/control-plane: ""
        Copy to Clipboard Toggle word wrap
        1
        このノードセレクターにより、CoreDNS Pod がコントロールプレーンノードでのみ実行されるようになります。

7.10.3. TLS を使用した DNS 転送の設定

高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。

CoreDNS は転送された接続を 10 秒間キャッシュすることに注意してください。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。

手順

  1. default という名前の DNS Operator オブジェクトを変更します。

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。

    TLS を使用した DNS 転送の設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: example-server 
    1
    
        zones:
        - example.com 
    2
    
        forwardPlugin:
          transportConfig:
            transport: TLS 
    3
    
            tls:
              caBundle:
                name: mycacert
              serverName: dnstls.example.com  
    4
    
          policy: Random 
    5
    
          upstreams: 
    6
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    7
    
        transportConfig:
          transport: TLS
          tls:
            caBundle:
              name: mycacert
            serverName: dnstls.example.com
        upstreams:
        - type: Network 
    8
    
          address: 1.2.3.4 
    9
    
          port: 53 
    10
    Copy to Clipboard Toggle word wrap

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。クラスタードメインの cluster.local は、zones の無効な subdomain です。
    3
    転送された DNS クエリーの TLS を設定する場合、transport フィールドの値を TLS に設定します。
    4
    転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。
    5
    アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値は Random です。RoundRobin および Sequential の値を使用することもできます。
    6
    必須。アップストリームリゾルバーを指定するために使用します。forwardPlugin エントリーごとに最大 15 の upstreams エントリーが許可されます。
    7
    任意。これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。
    8
    TLS を使用する場合、Network タイプのみが許可され、IP アドレスを指定する必要があります。Network タイプは、このアップストリームリゾルバーが /etc/resolv.conf にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。
    9
    address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    10
    オプションでポートを指定できます。port の値は 165535 である必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。
    注記

    servers が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。

検証

  1. config map を表示します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    Copy to Clipboard Toggle word wrap

    TLS 転送の例に基づく DNS ConfigMap のサンプル

    apiVersion: v1
    data:
      Corefile: |
        example.com:5353 {
            forward . 1.1.1.1 2.2.2.2:5353
        }
        bar.com:5353 example.com:5353 {
            forward . 3.3.3.3 4.4.4.4:5454 
    1
    
        }
        .:5353 {
            errors
            health
            kubernetes cluster.local in-addr.arpa ip6.arpa {
                pods insecure
                upstream
                fallthrough in-addr.arpa ip6.arpa
            }
            prometheus :9153
            forward . /etc/resolv.conf 1.2.3.4:53 {
                policy Random
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns
    Copy to Clipboard Toggle word wrap

    1
    forwardPlugin への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。

第8章 OpenShift Container Platform の Ingress Operator

Ingress Operator は IngressController API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。

8.1. OpenShift Container Platform Ingress Operator

OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などの Ingress Controller 内の設定は、Ingress Controller エンドポイントを公開する方法を提供します。

8.2. Ingress 設定アセット

インストールプログラムでは、config.openshift.io API グループの Ingress リソースでアセットを生成します (cluster-ingress-02-config.yml)。

Ingress リソースの YAML 定義

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com
Copy to Clipboard Toggle word wrap

インストールプログラムは、このアセットを manifests/ ディレクトリーの cluster-ingress-02-config.yml ファイルに保存します。この Ingress リソースは、Ingress のクラスター全体の設定を定義します。この Ingress 設定は、以下のように使用されます。

  • Ingress Operator は、クラスター Ingress 設定のドメインを、デフォルト Ingress Controller のドメインとして使用します。
  • OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない Route リソースのデフォルトホストを生成する際にも使用されます。

8.3. Ingress Controller 設定パラメーター

IngressController カスタムリソース (CR) には、組織の特定のニーズを満たすように設定できる任意の設定パラメーターが含まれています。

Expand
パラメーター説明

domain

domain は Ingress Controller によって提供される DNS 名で、複数の機能を設定するために使用されます。

  • LoadBalancerService エンドポイント公開ストラテジーの場合、domain は DNS レコードを設定するために使用されます。endpointPublishingStrategy を参照してください。
  • 生成されるデフォルト証明書を使用する場合、証明書は domain およびその subdomains で有効です。defaultCertificate を参照してください。
  • この値は個別の Route ステータスに公開され、ユーザーは外部 DNS レコードのターゲット先を認識できるようにします。

domain 値はすべての Ingress Controller の中でも固有の値であり、更新できません。

空の場合、デフォルト値は ingress.config.openshift.io/cluster .spec.domain です。

replicas

replicas は、Ingress Controller レプリカの数です。設定されていない場合、デフォルト値は 2 になります。

endpointPublishingStrategy

endpointPublishingStrategy は Ingress Controller エンドポイントを他のネットワークに公開し、ロードバランサーの統合を有効にし、他のシステムへのアクセスを提供するために使用されます。

クラウド環境の場合、loadBalancer フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。

GCP、AWS、および Azure では、次の endpointPublishingStrategy フィールドを設定できます。

  • loadBalancer.scope
  • loadBalancer.allowedSourceRanges

設定されていない場合、デフォルト値は infrastructure.config.openshift.io/cluster .status.platform をベースとします。

  • Azure: LoadBalancerService (外部スコープあり)
  • Google Cloud Platform (GCP): LoadBalancerService (外部スコープあり)

ほとんどのプラットフォームでは、endpointPublishingStrategy 値は更新できます。GCP では、次の endpointPublishingStrategy フィールドを設定できます。

  • loadBalancer.scope
  • loadbalancer.providerParameters.gcp.clientAccess

ベアメタルプラットフォームなどの非クラウド環境の場合は、NodePortServiceHostNetwork、または Private フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。

これらのフィールドのいずれかで値を設定しない場合のデフォルト値は、IngressController CR の .status.platform 値で指定されたバインディングポートに基づきます。

クラスターのデプロイ後に、endpointPublishingStrategy の値を更新する必要がある場合は、次の endpointPublishingStrategy フィールドを設定できます。

  • hostNetwork.protocol
  • nodePort.protocol
  • private.protocol

defaultCertificate

defaultCertificate 値は、Ingress Controller によって提供されるデフォルト証明書が含まれるシークレットへの参照です。ルートが独自の証明書を指定しない場合、defaultCertificate が使用されます。

シークレットには以下のキーおよびデータが含まれる必要があります: * tls.crt: 証明書ファイルコンテンツ * tls.key: キーファイルコンテンツ

設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの domain および subdomains で有効であり、生成された証明書 CA はクラスターの信頼ストアに自動的に統合されます。

使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。

namespaceSelector

namespaceSelector は、Ingress Controller によって提供される namespace セットをフィルターするために使用されます。これはシャードの実装に役立ちます。

routeSelector

routeSelector は、Ingress Controller によって提供される Routes のセットをフィルターするために使用されます。これはシャードの実装に役立ちます。

nodePlacement

nodePlacement は、Ingress Controller のスケジュールに対する明示的な制御を有効にします。

設定されていない場合は、デフォルト値が使用されます。

注記

nodePlacement パラメーターには、nodeSelectortolerations の 2 つの部分が含まれます。以下に例を示します。

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists
Copy to Clipboard Toggle word wrap

tlsSecurityProfile

tlsSecurityProfile は、Ingress Controller の TLS 接続の設定を指定します。

これが設定されていない場合、デフォルト値は apiservers.config.openshift.io/cluster リソースをベースとして設定されます。

OldIntermediate、および Modern のプロファイルタイプを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が Ingress Controller に適用され、ロールアウトが生じる可能性があります。

Ingress Controller の最小 TLS バージョンは 1.1 で、最大 TLS バージョンは 1.3 です。

注記

設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが TLSProfile ステータスに反映されます。

重要

Ingress Operator は TLS 1.0Old または Custom プロファイルを 1.1 に変換します。

clientTLS

clientTLS は、クラスターおよびサービスへのクライアントアクセスを認証します。その結果、相互 TLS 認証が有効になります。設定されていない場合、クライアント TLS は有効になっていません。

clientTLS には、必要なサブフィールド spec.clientTLS.clientCertificatePolicy および spec.clientTLS.ClientCA があります。

ClientCertificatePolicy サブフィールドは、Required または Optional の 2 つの値のいずれかを受け入れます。ClientCA サブフィールドは、openshift-config namespace にある config map を指定します。config map には CA 証明書バンドルが含まれている必要があります。

AllowedSubjectPatterns は、要求をフィルターするために有効なクライアント証明書の識別名と照合される正規表現のリストを指定する任意の値です。正規表現は PCRE 構文を使用する必要があります。1 つ以上のパターンがクライアント証明書の識別名と一致している必要があります。一致しない場合、Ingress Controller は証明書を拒否し、接続を拒否します。指定しないと、Ingress Controller は識別名に基づいて証明書を拒否しません。

routeAdmission

routeAdmission は、複数の namespace での要求の許可または拒否など、新規ルート要求を処理するためのポリシーを定義します。

namespaceOwnership は、namespace 間でホスト名の要求を処理する方法を記述します。デフォルトは Strict です。

  • Strict: ルートが複数の namespace 間で同じホスト名を要求することを許可しません。
  • InterNamespaceAllowed: ルートが複数の namespace 間で同じホスト名の異なるパスを要求することを許可します。

wildcardPolicy は、ワイルドカードポリシーを使用するルートが Ingress Controller によって処理される方法を記述します。

  • WildcardsAllowed: ワイルドカードポリシーと共にルートが Ingress Controller によって許可されていることを示します。
  • WildcardsDisallowed: ワイルドカードポリシーの None を持つルートのみが Ingress Controller によって許可されることを示します。wildcardPolicyWildcardsAllowed から WildcardsDisallowed に更新すると、ワイルドカードポリシーの Subdomain を持つ許可されたルートが機能を停止します。これらのルートは、Ingress Controller によって許可されるように None のワイルドカードポリシーに対して再作成される必要があります。WildcardsDisallowed はデフォルト設定です。

IngressControllerLogging

logging はログに記録される内容および場所のパラメーターを定義します。このフィールドが空の場合、操作ログは有効になりますが、アクセスログは無効になります。

  • access は、クライアント要求をログに記録する方法を記述します。このフィールドが空の場合、アクセスロギングは無効になります。

    • destination はログメッセージの宛先を記述します。

      • type はログの宛先のタイプです。

        • Container は、ログがサイドカーコンテナーに移動することを指定します。Ingress Operator は Ingress Controller Pod で logs という名前のコンテナーを設定し、Ingress Controller がログをコンテナーに書き込むように設定します。管理者がこのコンテナーからログを読み取るカスタムロギングソリューションを設定することが予想されます。コンテナーログを使用すると、ログの割合がコンテナーランタイムの容量やカスタムロギングソリューションの容量を超えるとログがドロップされることがあります。
        • Syslog は、ログが Syslog エンドポイントに送信されることを指定します。管理者は、Syslog メッセージを受信できるエンドポイントを指定する必要があります。管理者がカスタム Syslog インスタンスを設定していることが予想されます。
      • containerContainer ロギング宛先タイプのパラメーターを記述します。現在、コンテナーロギングのパラメーターはないため、このフィールドは空である必要があります。
      • syslog は、Syslog ロギング宛先タイプのパラメーターを記述します。

        • address は、ログメッセージを受信する syslog エンドポイントの IP アドレスです。
        • port は、ログメッセージを受信する syslog エンドポイントの UDP ポート番号です。
        • maxLength は、syslog メッセージの最大長です。サイズは 480 から 4096 バイトである必要があります。このフィールドが空の場合には、最大長はデフォルト値の 1024 バイトに設定されます。
        • facility はログメッセージの syslog ファシリティーを指定します。このフィールドが空の場合、ファシリティーは local1 になります。それ以外の場合、有効な syslog ファシリティー (kernusermaildaemonauthsysloglprnewsuucpcronauth2ftpntpauditalertcron2local0local1local2local3) を指定する必要があります。local4local5local6、または local7
    • httpLogFormat は、HTTP 要求のログメッセージの形式を指定します。このフィールドが空の場合、ログメッセージは実装のデフォルト HTTP ログ形式を使用します。HAProxy のデフォルトの HTTP ログ形式は、HAProxy ドキュメント を参照してください。

httpHeaders

httpHeaders は HTTP ヘッダーのポリシーを定義します。

IngressControllerHTTPHeadersforwardedHeaderPolicy を設定することで、Ingress Controller が ForwardedX-Forwarded-ForX-Forwarded-HostX-Forwarded-PortX-Forwarded-Proto、および X-Forwarded-Proto-Version HTTP ヘッダーをいつどのように設定するか指定します。

デフォルトでは、ポリシーは Append に設定されます。

  • Append は、Ingress Controller がヘッダーを追加するように指定し、既存のヘッダーを保持します。
  • Replace は、Ingress Controller がヘッダーを設定するように指定し、既存のヘッダーを削除します。
  • IfNone は、ヘッダーがまだ設定されていない場合に、Ingress Controller がヘッダーを設定するように指定します。
  • Never は、Ingress Controller がヘッダーを設定しないように指定し、既存のヘッダーを保持します。

headerNameCaseAdjustments を設定して、HTTP ヘッダー名に適用できるケースの調整を指定できます。それぞれの調整は、必要な大文字化を指定して HTTP ヘッダー名として指定されます。たとえば、X-Forwarded-For を指定すると、指定された大文字化を有効にするために x-forwarded-for HTTP ヘッダーを調整する必要があることを示唆できます。

これらの調整は、クリアテキスト、edge-terminated、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。

要求ヘッダーの場合、これらの調整は haproxy.router.openshift.io/h1-adjust-case=true アノテーションを持つルートにのみ適用されます。応答ヘッダーの場合、これらの調整はすべての HTTP 応答に適用されます。このフィールドが空の場合、要求ヘッダーは調整されません。

actions は、ヘッダーに対して特定のアクションを実行するためのオプションを指定します。TLS パススルー接続のヘッダーは設定または削除できません。actions フィールドには、spec.httpHeader.actions.response および spec.httpHeader.actions.request の追加のサブフィールドがあります。

  • response サブフィールドは、設定または削除する HTTP 応答ヘッダーのリストを指定します。
  • request サブフィールドは、設定または削除する HTTP 要求ヘッダーのリストを指定します。

httpCompression

httpCompression は、HTTP トラフィック圧縮のポリシーを定義します。

  • mimeTypes は、圧縮を適用する必要がある MIME タイプのリストを定義します。(例: text/css; charset=utf-8, text/html, text/*, image/svg+xml, application/octet-stream, X-custom/customsub, using the format pattern, type/subtype; [;attribute=value])types は、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または X- で始まるカスタムタイプ。例: MIME タイプとサブタイプの完全な表記を確認するには、RFC1341 を参照してください。

httpErrorCodePages

httpErrorCodePages は、カスタムの HTTP エラーコードの応答ページを指定します。デフォルトで、IngressController は IngressController イメージにビルドされたエラーページを使用します。

httpCaptureCookies

httpCaptureCookies は、アクセスログにキャプチャーする HTTP Cookie を指定します。httpCaptureCookies フィールドが空の場合、アクセスログは Cookie をキャプチャーしません。

キャプチャーするすべての Cookie について、次のパラメーターが IngressController 設定に含まれている必要があります。

  • name は、Cookie の名前を指定します。
  • maxLength は、Cookie の最大長を指定します。
  • matchType は、Cookie のフィールドの name が、キャプチャー Cookie 設定と完全に一致するか、キャプチャー Cookie 設定の接頭辞であるかを指定します。matchType フィールドは Exact および Prefix パラメーターを使用します。

以下に例を示します。

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE
Copy to Clipboard Toggle word wrap

httpCaptureHeaders

httpCaptureHeaders は、アクセスログにキャプチャーする HTTP ヘッダーを指定します。httpCaptureHeaders フィールドが空の場合、アクセスログはヘッダーをキャプチャーしません。

httpCaptureHeaders には、アクセスログにキャプチャーするヘッダーの 2 つのリストが含まれています。ヘッダーフィールドの 2 つのリストは requestresponse です。どちらのリストでも、name フィールドはヘッダー名を指定し、maxlength フィールドはヘッダーの最大長を指定する必要があります。以下に例を示します。

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length
Copy to Clipboard Toggle word wrap

tuningOptions

tuningOptions は、Ingress Controller Pod のパフォーマンスを調整するためのオプションを指定します。

  • clientFinTimeout は、クライアントの応答が接続を閉じるのを待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは 1s です。
  • clientTimeout は、クライアント応答の待機中に接続が開かれる期間を指定します。デフォルトのタイムアウトは 30s です。
  • headerBufferBytes は、Ingress Controller 接続セッション用に予約されるメモリーの量をバイト単位で指定します。Ingress Controller で HTTP / 2 が有効になっている場合、この値は少なくとも 16384 である必要があります。設定されていない場合、デフォルト値は 32768 バイトになります。このフィールドを設定することは推奨しません。headerBufferBytes 値が小さすぎると Ingress Controller が破損する可能性があり、headerBufferBytes 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。
  • headerBufferMaxRewriteBytes は、HTTP ヘッダーの書き換えと Ingress Controller 接続セッションの追加のために headerBufferBytes から予約するメモリーの量をバイト単位で指定します。headerBufferMaxRewriteBytes の最小値は 4096 です。受信 HTTP 要求には、headerBufferBytesheaderBufferMaxRewriteBytes よりも大きくなければなりません。設定されていない場合、デフォルト値は 8192 バイトになります。このフィールドを設定することは推奨しません。headerBufferMaxRewriteBytes 値が小さすぎると Ingress Controller が破損する可能性があり、headerBufferMaxRewriteBytes 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。
  • healthCheckInterval は、ルーターがヘルスチェックの間隔として待機する時間を指定します。デフォルトは 5s です。
  • serverFinTimeout は、接続を閉じるクライアントへの応答を待つ間、接続が開かれる期間を指定します。デフォルトのタイムアウトは 1s です。
  • serverTimeout は、サーバーの応答を待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは 30s です。
  • threadCount は、HAProxy プロセスごとに作成するスレッドの数を指定します。より多くのスレッドを作成すると、使用されるシステムリソースを増やすことで、各 Ingress Controller Pod がより多くの接続を処理できるようになります。HAProxy は最大 64 のスレッドをサポートします。このフィールドが空の場合、Ingress Controller はデフォルト値の 4 スレッドを使用します。デフォルト値は、将来のリリースで変更される可能性があります。このフィールドを設定することは推奨しません。HAProxy スレッドの数を増やすと、Ingress Controller Pod が負荷時に CPU 時間をより多く使用できるようになり、他の Pod が実行に必要な CPU リソースを受け取れないようになるためです。スレッドの数を減らすと、Ingress Controller のパフォーマンスが低下する可能性があります。
  • tlsInspectDelay は、一致するルートを見つけるためにルーターがデータを保持する期間を指定します。この値の設定が短すぎると、より一致する証明書を使用している場合でも、ルーターがエッジ終端、再暗号化された、またはパススルーのルートのデフォルトの証明書にフォールバックする可能性があります。デフォルトの検査遅延は 5s です。
  • tunnelTimeout は、トンネルがアイドル状態の間、websocket などのトンネル接続期間を開いた期間を指定します。デフォルトのタイムアウトは 1h です。
  • maxConnections は、HAProxy プロセスごとに確立できる同時接続の最大数を指定します。この値を増やすと、追加のシステムリソースで各 Ingress Controller Pod がより多くの接続を処理できるようになります。0-12000 から 2000000 の範囲内の任意の値を使用でき、フィールドを空にすることも可能です。

    • このフィールドが空のままであるか、値が 0 の場合、Ingress Controller はデフォルト値の 50000 を使用します。この値は、今後のリリースで変更される可能性があります。
    • フィールド値が -1 の場合、HAProxy は、実行中のコンテナーで使用可能な ulimit に基づき最大値を動的に計算します。このプロセスにより、計算値が大きくなり、現在のデフォルト値である 50000 と比較してかなり大きなメモリー使用量が発生します。
    • フィールドの値が現在のオペレーティングシステムの制限よりも大きい場合、HAProxy プロセスは開始されません。
    • 個別の値を選択し、ルーター Pod が新しいノードに移行された場合、新しいノードに同一の ulimit が設定されていない可能性があります。このような場合、Pod は起動に失敗します。
    • 異なる ulimit を持つノードが設定されていて、離散値を選択する場合は、実行時に接続の最大数が計算されるように、このフィールドに -1 の値を使用することを推奨します。

logEmptyRequests

logEmptyRequests は、リクエストを受け取らず、ログに記録されない接続を指定します。これらの空の要求は、ロードバランサーヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から送信され、これらの要求をログに記録することは望ましくない場合があります。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。この場合は、空の要求をログに記録すると、エラーの診断に役立ちます。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。このフィールドに使用できる値は Log および Ignore です。デフォルト値は Log です。

LoggingPolicy タイプは、以下のいずれかの値を受け入れます。

  • ログ: この値を Log に設定すると、イベントがログに記録される必要があることを示します。
  • Ignore: この値を Ignore に設定すると、HAproxy 設定の dontlognull オプションを設定します。

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy は、リクエストを受け取る前に接続がタイムアウトした場合に HTTP 接続を処理する方法を記述します。このフィールドに使用できる値は Respond および Ignore です。デフォルト値は Respond です。

HTTPEmptyRequestsPolicy タイプは、以下のいずれかの値を受け入れます。

  • 応答: フィールドが Respond に設定されている場合、Ingress Controller は HTTP 400 または 408 応答を送信する場合、アクセスログが有効な場合に接続をログに記録し、適切なメトリックで接続をカウントします。
  • ignore: このオプションを Ignore に設定すると HAproxy 設定に http-ignore-probes パラメーターが追加されます。フィールドが Ignore に設定されている場合、Ingress Controller は応答を送信せずに接続を閉じると、接続をログに記録するか、メトリクスを増分します。

これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを Ignore に設定すると問題の検出と診断が妨げられる可能性があります。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。

8.3.1. Ingress Controller の TLS セキュリティープロファイル

TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。

8.3.1.1. TLS セキュリティープロファイルについて

TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定 に基づいています。

コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。

Expand
表8.1 TLS セキュリティープロファイル
プロファイル説明

Old

このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。

Old プロファイルには、最小 TLS バージョン 1.0 が必要です。

注記

Ingress Controller の場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。

Intermediate

このプロファイルは、Ingress Controller、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。

Intermediate プロファイルには、最小 TLS バージョン 1.2 が必要です。

注記

このプロファイルは、大多数のクライアントに推奨される設定です。

Modern

このプロファイルは、下位互換性を必要としない最新のクライアントで使用することを目的としています。このプロファイルは、Modern compatibility の推奨設定に基づいています。

Modern プロファイルには、最小 TLS バージョン 1.3 が必要です。

Custom

このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。

警告

無効な設定により問題が発生する可能性があるため、Custom プロファイルを使用する際には注意してください。

注記

事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。

8.3.1.2. Ingress Controller の TLS セキュリティープロファイルの設定

Ingress Controller の TLS セキュリティープロファイルを設定するには、IngressController カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。

Old TLS のセキュリティープロファイルを設定するサンプル IngressController CR

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...
Copy to Clipboard Toggle word wrap

TLS セキュリティープロファイルは、Ingress Controller の TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。

設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile 配下の IngressController カスタムリソース (CR) と Spec.Tls Security Profile 配下の設定された TLS セキュリティープロファイルで確認できます。Custom TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。

注記

HAProxy Ingress Controller イメージは、TLS 1.3Modern プロファイルをサポートしています。

また、Ingress Operator は TLS 1.0Old または Custom プロファイルを 1.1 に変換します。

前提条件

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

手順

  1. openshift-ingress-operator プロジェクトの IngressController CR を編集して、TLS セキュリティープロファイルを設定します。

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  2. spec.tlsSecurityProfile フィールドを追加します。

    Custom プロファイルのサンプル IngressController CR

    apiVersion: operator.openshift.io/v1
    kind: IngressController
     ...
    spec:
      tlsSecurityProfile:
        type: Custom 
    1
    
        custom: 
    2
    
          ciphers: 
    3
    
          - ECDHE-ECDSA-CHACHA20-POLY1305
          - ECDHE-RSA-CHACHA20-POLY1305
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-GCM-SHA256
          minTLSVersion: VersionTLS11
     ...
    Copy to Clipboard Toggle word wrap

    1
    TLS セキュリティープロファイルタイプ (OldIntermediate、または Custom) を指定します。デフォルトは Intermediate です。
    2
    選択したタイプに適切なフィールドを指定します。
    • old: {}
    • intermediate: {}
    • modern: {}
    • custom:
    3
    custom タイプには、TLS 暗号のリストと最小許容 TLS バージョンを指定します。
  3. 変更を適用するためにファイルを保存します。

検証

  • IngressController CR にプロファイルが設定されていることを確認します。

    $ oc describe IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap

    出力例

    Name:         default
    Namespace:    openshift-ingress-operator
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         IngressController
     ...
    Spec:
     ...
      Tls Security Profile:
        Custom:
          Ciphers:
            ECDHE-ECDSA-CHACHA20-POLY1305
            ECDHE-RSA-CHACHA20-POLY1305
            ECDHE-RSA-AES128-GCM-SHA256
            ECDHE-ECDSA-AES128-GCM-SHA256
          Min TLS Version:  VersionTLS11
        Type:               Custom
     ...
    Copy to Clipboard Toggle word wrap

8.3.1.3. 相互 TLS 認証の設定

spec.clientTLS 値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress Controller を設定できます。clientTLS 値は、クライアント証明書を検証するように Ingress Controller を設定します。この設定には、config map の参照である clientCA 値の設定が含まれます。config map には、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターのリストも設定できます。

clientCA 値が X509v3 証明書失効リスト (CRL) ディストリビューションポイントを指定している場合、Ingress Operator は、提供された各証明書で指定されている HTTP URI X509v3 CRL Distribution Point に基づいて CRL config map をダウンロードおよび管理します。Ingress Controller は、mTLS/TLS ネゴシエーション中にこの config map を使用します。有効な証明書を提供しない要求は拒否されます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • PEM でエンコードされた CA 証明書バンドルがある。
  • CA バンドルが CRL ディストリビューションポイントを参照する場合は、エンドエンティティーまたはリーフ証明書もクライアント CA バンドルに含める必要があります。この証明書には、RFC 5280 で説明されているとおり、この証明書の CRL Distribution Points に HTTP URI が含まれている必要があります。以下に例を示します。

     Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
             Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                    Full Name:
                      URI:http://crl.example.com/example.crl
    Copy to Clipboard Toggle word wrap

手順

  1. openshift-config namespace で、CA バンドルから config map を作成します。

    $ oc create configmap \
       router-ca-certs-default \
       --from-file=ca-bundle.pem=client-ca.crt \
    1
    
       -n openshift-config
    Copy to Clipboard Toggle word wrap
    1
    config map データキーは ca-bundle.pem で、data の値は PEM 形式の CA 証明書である必要があります。
  2. openshift-ingress-operator プロジェクトで IngressController リソースを編集します。

    $ oc edit IngressController default -n openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
  3. spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。

    フィルタリングパターンを指定する clientTLS プロファイルのサンプル IngressController CR

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        clientTLS:
          clientCertificatePolicy: Required
          clientCA:
            name: router-ca-certs-default
          allowedSubjectPatterns:
          - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
    Copy to Clipboard Toggle word wrap

  4. オプションで、次のコマンドを入力して、allowedSubjectPatterns の識別名 (DN) を取得します。
$ openssl  x509 -in custom-cert.pem  -noout -subject
subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift
Copy to Clipboard Toggle word wrap

8.4. デフォルト Ingress Controller の表示

Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。

すべての新規 OpenShift Container Platform インストールには、ingresscontroller の名前付きのデフォルトがあります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。

手順

  • デフォルト Ingress Controller を表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
    Copy to Clipboard Toggle word wrap

8.5. Ingress Operator ステータスの表示

Ingress Operator のステータスを表示し、検査することができます。

手順

  • Ingress Operator ステータスを表示します。

    $ oc describe clusteroperators/ingress
    Copy to Clipboard Toggle word wrap

8.6. Ingress Controller ログの表示

Ingress Controller ログを表示できます。

手順

  • Ingress Controller ログを表示します。

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
    Copy to Clipboard Toggle word wrap

8.7. Ingress Controller ステータスの表示

特定の Ingress Controller のステータスを表示できます。

手順

  • Ingress Controller のステータスを表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
    Copy to Clipboard Toggle word wrap

8.8. カスタム Ingress Controller の作成

クラスター管理者は、新規のカスタム Ingress Controller を作成できます。デフォルトの Ingress Controller は OpenShift Container Platform の更新時に変更される可能性があるため、クラスターの更新後も保持される設定を手動で維持する場合は、カスタム Ingress Controller を作成すると便利です。

この例では、カスタム Ingress Controller の最小限の仕様を提供します。カスタム Ingress Controller をさらにカスタマイズするには、「Ingress Controller の設定」を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. カスタム IngressController オブジェクトを定義する YAML ファイルを作成します。

    custom-ingress-controller.yaml ファイルの例

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
        name: <custom_name> 
    1
    
        namespace: openshift-ingress-operator
    spec:
        defaultCertificate:
            name: <custom-ingress-custom-certs> 
    2
    
        replicas: 1 
    3
    
        domain: <custom_domain> 
    4
    Copy to Clipboard Toggle word wrap

    1
    IngressController オブジェクトのカスタム を指定します。
    2
    カスタムワイルドカード証明書でシークレットの名前を指定します。
    3
    最小レプリカは ONE である必要があります
    4
    ドメイン名のドメインを指定します。IngressController オブジェクトで指定されるドメインと、証明書に使用されるドメインが一致する必要があります。たとえば、ドメイン値が "custom_domain.mycompany.com" の場合、証明書には SAN *.custom_domain.mycompany.com が必要です (*. がドメインに追加されます)。
  2. 以下のコマンドを実行してオブジェクトを作成します。

    $ oc create -f custom-ingress-controller.yaml
    Copy to Clipboard Toggle word wrap

8.9. Ingress Controller の設定

8.9.1. カスタムデフォルト証明書の設定

管理者として、Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress Controller がカスタム証明書を使用するように設定できます。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
  • 証明書が以下の要件を満たしている必要があります。

    • 証明書が Ingress ドメインに対して有効化されている必要があります。
    • 証明書は拡張を使用して、subjectAltName 拡張を使用して、*.apps.ocp4.example.com などのワイルドカードドメインを指定します。
  • IngressController CR が必要です。これには、default IngressController CR のみが含まれます。次のコマンドを実行して、IngressController CR があるかどうかを確認できます。

    $ oc --namespace openshift-ingress-operator get ingresscontrollers
    Copy to Clipboard Toggle word wrap
注記

Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書をリスト表示します。

手順

以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提とします。tls.crt および tls.key を実際のパス名に置き換えます。さらに、Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default を別の名前に置き換えます。

注記

このアクションにより、Ingress Controller はデプロイメントストラテジーを使用して再デプロイされます。

  1. tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
    Copy to Clipboard Toggle word wrap
  2. IngressController CR を、新規証明書シークレットを参照するように更新します。

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
    Copy to Clipboard Toggle word wrap
  3. 更新が正常に行われていることを確認します。

    $ echo Q |\
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <domain>
    クラスターのベースドメイン名を指定します。

    出力例

    subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
    issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
    notAfter=May 10 08:32:45 2022 GM
    Copy to Clipboard Toggle word wrap

    ヒント

    または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default
    Copy to Clipboard Toggle word wrap

    証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress Controller のデプロイメントを更新します。

8.9.2. カスタムデフォルト証明書の削除

管理者は、使用する Ingress Controller を設定したカスタム証明書を削除できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • Ingress Controller のカスタムデフォルト証明書を設定している。

手順

  • カスタム証明書を削除し、OpenShift Container Platform に同梱されている証明書を復元するには、以下のコマンドを入力します。

    $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
      --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
    Copy to Clipboard Toggle word wrap

    クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。

検証

  • 元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。

    $ echo Q | \
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
      openssl x509 -noout -subject -issuer -enddate
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <domain>
    クラスターのベースドメイン名を指定します。

    出力例

    subject=CN = *.apps.<domain>
    issuer=CN = ingress-operator@1620633373
    notAfter=May 10 10:44:36 2023 GMT
    Copy to Clipboard Toggle word wrap

8.9.3. Ingress Controller の自動スケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に動的に対応するために自動でスケーリングできます。

以下の手順では、デフォルトの Ingress Controller をスケールアップする例を示します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
  • Custom Metrics Autoscaler Operator と関連する KEDA Controller がインストールされている。

    • この Operator は、Web コンソールで OperatorHub を使用してインストールできます。Operator をインストールしたら、KedaController のインスタンスを作成できます。

手順

  1. 以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。

    $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
    Copy to Clipboard Toggle word wrap

    出力例

    Name:                thanos
    Namespace:           openshift-ingress-operator
    Labels:              <none>
    Annotations:         <none>
    Image pull secrets:  thanos-dockercfg-kfvf2
    Mountable secrets:   thanos-dockercfg-kfvf2
    Tokens:              <none>
    Events:              <none>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。

    $ oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-token
      namespace: openshift-ingress-operator
      annotations:
        kubernetes.io/service-account.name: thanos
    type: kubernetes.io/service-account-token
    EOF
    Copy to Clipboard Toggle word wrap
  3. サービスアカウントのトークンを使用して、openshift-ingress-operator namespace 内で TriggerAuthentication オブジェクトを定義します。

    1. TriggerAuthentication オブジェクトを作成し、secret 変数の値を TOKEN パラメーターに渡します。

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF
      Copy to Clipboard Toggle word wrap
  4. Thanos からメトリクスを読み取るためのロールを作成して適用します。

    1. Pod およびノードからメトリクスを読み取る新規ロール thanos-metrics-reader.yaml を作成します。

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して新規ロールを適用します。

      $ oc apply -f thanos-metrics-reader.yaml
      Copy to Clipboard Toggle word wrap
  5. 以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。

    $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
    Copy to Clipboard Toggle word wrap
    $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
    Copy to Clipboard Toggle word wrap
    注記

    引数 add-cluster-role-to-user は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とする kube-metrics namespace からのクエリーを使用します。

  6. デフォルトの Ingress Controller デプロイメントをターゲットにする新しい ScaledObject YAML ファイル ingress-autoscaler.yaml を作成します。

    ScaledObject 定義の例

    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: ingress-scaler
      namespace: openshift-ingress-operator
    spec:
      scaleTargetRef: 
    1
    
        apiVersion: operator.openshift.io/v1
        kind: IngressController
        name: default
        envSourceContainerName: ingress-operator
      minReplicaCount: 1
      maxReplicaCount: 20 
    2
    
      cooldownPeriod: 1
      pollingInterval: 1
      triggers:
      - type: prometheus
        metricType: AverageValue
        metadata:
          serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 
    3
    
          namespace: openshift-ingress-operator 
    4
    
          metricName: 'kube-node-role'
          threshold: '1'
          query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 
    5
    
          authModes: "bearer"
        authenticationRef:
          name: keda-trigger-auth-prometheus
    Copy to Clipboard Toggle word wrap

    1
    対象とするカスタムリソース。この場合、Ingress Controller。
    2
    オプション: レプリカの最大数。このフィールドを省略すると、デフォルトの最大値は 100 レプリカに設定されます。
    3
    openshift-monitoring namespace の Thanos サービスエンドポイント。
    4
    Ingress Operator namespace。
    5
    この式は、デプロイされたクラスターに存在するワーカーノードの数に対して評価されます。
    重要

    namespace 間クエリーを使用している場合は、serverAddress フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

  7. 以下のコマンドを実行してカスタムリソース定義を適用します。

    $ oc apply -f ingress-autoscaler.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 以下のコマンドを実行して、デフォルトの Ingress Controller が kube-state-metrics クエリーによって返される値に一致するようにスケールアウトされていることを確認します。

    • grep コマンドを使用して、Ingress Controller YAML ファイルでレプリカの数を検索します。

      $ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
      Copy to Clipboard Toggle word wrap
    • openshift-ingress プロジェクトで Pod を取得します。

      $ oc get pods -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                             READY   STATUS    RESTARTS   AGE
      router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
      router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
      router-default-7b5df44ff-wwsth   2/2     Running   0          66s
      Copy to Clipboard Toggle word wrap

8.9.4. Ingress Controller のスケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc コマンドは、IngressController リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。

注記

スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。

手順

  1. デフォルト IngressController の現在の利用可能なレプリカ数を表示します。

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap
  2. oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
    Copy to Clipboard Toggle word wrap
  3. デフォルトの IngressController が指定したレプリカ数にスケーリングされていることを確認します。

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    Copy to Clipboard Toggle word wrap
    ヒント

    または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 3               
    1
    Copy to Clipboard Toggle word wrap
    1
    異なる数のレプリカが必要な場合は replicas 値を変更します。

8.9.5. Ingress アクセスロギングの設定

アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。

コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress Controller で問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。

アクセスログが OpenShift Logging スタックの容量を超える可能性がある高トラフィックのクラスターや、ログソリューションを既存の Syslog ログインフラストラクチャーと統合する必要がある環境では、Syslog が必要です。Syslog のユースケースは重複する可能性があります。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

サイドカーへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container spec.logging.access.destination.type を指定する必要があります。以下の例は、コンテナー Container の宛先に対してログ記録する Ingress Controller 定義です。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Container
    Copy to Clipboard Toggle word wrap
  • Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に logs という名前のコンテナーを作成します。

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs
    Copy to Clipboard Toggle word wrap

    出力例

    2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"
    Copy to Clipboard Toggle word wrap

Syslog エンドポイントへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.typeSyslog を指定する必要があります。宛先タイプが Syslog の場合、spec.logging.access.destination.syslog.address を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility を使用してファシリティーを指定できます。以下の例は、Syslog 宛先に対してログを記録する Ingress Controller の定義です。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
    Copy to Clipboard Toggle word wrap
    注記

    syslog 宛先ポートは UDP である必要があります。

    syslog の宛先アドレスは IP アドレスにする必要があります。DNS ホスト名はサポートされていません。

特定のログ形式で Ingress アクセスロギングを設定します。

  • spec.logging.access.httpLogFormat を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 の syslog エンドポイントに対してログを記録する Ingress Controller の定義です。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
          httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
    Copy to Clipboard Toggle word wrap

Ingress アクセスロギングを無効にします。

  • Ingress アクセスロギングを無効にするには、spec.logging または spec.logging.access を空のままにします。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access: null
    Copy to Clipboard Toggle word wrap

サイドカーの使用時に Ingress Controller が HAProxy ログの長さを変更できるようにします。

  • spec.logging.access.destination.type: Syslog を使用している場合は、spec.logging.access.destination.syslog.maxLength を使用します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              maxLength: 4096
              port: 10514
    Copy to Clipboard Toggle word wrap
  • spec.logging.access.destination.type: Container を使用している場合は、spec.logging.access.destination.container.maxLength を使用します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            container:
              maxLength: 8192
            type: Container
          httpCaptureHeaders:
            request:
            - maxLength: 128
              name: X-Forwarded-For
    Copy to Clipboard Toggle word wrap
  • Ingress アクセスログの X-Forwarded-For ヘッダーを使用して元のクライアントソース IP アドレスを表示するには、Red Hat ナレッジベースの記事 "Capturing Original Client IP from the X-Forwarded-For Header in Ingress and Application Logs" を参照してください。

8.9.6. Ingress Controller スレッド数の設定

クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress Controller にパッチを適用して、スレッドの数を増やすことができます。

前提条件

  • 以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

  • Ingress Controller を更新して、スレッド数を増やします。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
    Copy to Clipboard Toggle word wrap
    注記

    大量のリソースを実行できるノードがある場合、spec.nodePlacement.nodeSelector を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount を随時高い値に設定します。

8.9.7. 内部ロードバランサーを使用するための Ingress Controller の設定

クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。

重要

IngressControllerscope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。

図8.1 LoadBalancer の図

前述の図では、OpenShift Container Platform Ingress LoadBalancerService エンドポイントの公開戦略に関する以下のような概念を示しています。

  • 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
  • ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
  • 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細は、Kubernetes サービスドキュメント を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 以下の例のように、<name>-ingress-controller.yaml という名前のファイルに IngressController カスタムリソース (CR) を作成します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> 
    1
    
    spec:
      domain: <domain> 
    2
    
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal 
    3
    Copy to Clipboard Toggle word wrap
    1
    <name>IngressController オブジェクトの名前に置き換えます。
    2
    コントローラーによって公開されるアプリケーションの ドメイン を指定します。
    3
    内部ロードバランサーを使用するために Internal の値を指定します。
  2. 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。

    $ oc create -f <name>-ingress-controller.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <name>IngressController オブジェクトの名前に置き換えます。
  3. オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。

    $ oc --all-namespaces=true get ingresscontrollers
    Copy to Clipboard Toggle word wrap

8.9.8. GCP での Ingress Controller のグローバルアクセスの設定

内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。

詳細情報は、GCP ドキュメントの グローバルアクセス を参照してください。

前提条件

  • OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
  • 内部ロードバランサーを使用するように Ingress Controller を設定している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. グローバルアクセスを許可するように Ingress Controller リソースを設定します。

    注記

    Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。

    1. Ingress Controller リソースを設定します。

      $ oc -n openshift-ingress-operator edit ingresscontroller/default
      Copy to Clipboard Toggle word wrap
    2. YAML ファイルを編集します。

      サンプル clientAccess 設定を Global に設定します。

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 
      1
      
                type: GCP
              scope: Internal
            type: LoadBalancerService
      Copy to Clipboard Toggle word wrap

      1
      gcp.clientAccessGlobal に設定します。
    3. 変更を適用するためにファイルを保存します。
  2. 以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。

    $ oc -n openshift-ingress edit svc/router-default -o yaml
    Copy to Clipboard Toggle word wrap

    この出力には、アノテーション networking.gke.io/internal-load-balancer-allow-global-access により GCP のグローバルアクセスが有効になっていることが示されています。

8.9.9. Ingress Controller のヘルスチェック間隔の設定

クラスター管理者は、ヘルスチェックの間隔を設定して、ルーターが連続する 2 回のヘルスチェックの間で待機する時間を定義できます。この値は、すべてのルートのデフォルトとしてグローバルに適用されます。デフォルト値は 5 秒です。

前提条件

  • 以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

  • Ingress Controller を更新して、バックエンドヘルスチェックの間隔を変更します。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
    Copy to Clipboard Toggle word wrap
    注記

    単一ルートの healthCheckInterval をオーバーライドするには、ルートアノテーション router.openshift.io/haproxy.health.check.interval を使用します

8.9.10. クラスターを内部に配置するためのデフォルト Ingress Controller の設定

削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定できます。

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。

重要

IngressControllerscope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定します。

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF
    Copy to Clipboard Toggle word wrap

8.9.11. ルートの受付ポリシーの設定

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。

警告

複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。

前提条件

  • クラスター管理者の権限。

手順

  • 以下のコマンドを使用して、ingresscontroller リソース変数の .spec.routeAdmission フィールドを編集します。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    イメージコントローラー設定例

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...
    Copy to Clipboard Toggle word wrap

    ヒント

    または、以下の YAML を適用してルートの受付ポリシーを設定できます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    Copy to Clipboard Toggle word wrap

8.9.12. ワイルドカードルートの使用

HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。

Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。

手順

  1. ワイルドカードポリシーを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
      Copy to Clipboard Toggle word wrap

8.9.13. HTTP ヘッダーの設定

OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。

注記

IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。

8.9.13.1. 優先順位

同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。

  • HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
  • HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。

たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY を設定します。

IngressController 仕様の例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY
Copy to Clipboard Toggle word wrap

ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN を設定します。

Route 仕様の例

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN
Copy to Clipboard Toggle word wrap

IngressController 仕様と Route 仕様の両方で X-Frame-Options 応答ヘッダーが設定されている場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。リクエストヘッダーの場合、Route 仕様の値が IngressController 仕様の値をオーバーライドします。

この優先順位付けは、haproxy.config ファイルで次のロジックが使用されるため発生します。このロジックでは、Ingress Controller がフロントエンドと見なされ、個々のルートがバックエンドと見なされます。フロントエンド設定に適用されるヘッダー値 DENY は、バックエンドで設定されている値 SAMEORIGIN で同じヘッダーをオーバーライドします。

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'
Copy to Clipboard Toggle word wrap

さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

8.9.13.2. 特殊なケースのヘッダー

次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。

Expand
表8.2 特殊な場合のヘッダー設定オプション
ヘッダー名IngressController 仕様を使用して設定可能かどうかRoute 仕様を使用して設定可能かどうか不許可の理由別の方法で設定可能かどうか

proxy

いいえ

いいえ

プロキシー HTTP リクエストヘッダーを使用して、ヘッダー値を HTTP_PROXY 環境変数に挿入して、脆弱な CGI アプリケーションを悪用できます。プロキシー HTTP リクエストヘッダーも標準ではないため、設定中にエラーが発生しやすくなります。

いいえ

host

いいえ

はい

IngressController CR を使用して ホスト HTTP 要求ヘッダーが設定されている場合、HAProxy は正しいルートを検索するときに失敗する可能性があります。

いいえ

strict-transport-security

いいえ

いいえ

strict-transport-security HTTP 応答ヘッダーはルートアノテーションを使用してすでに処理されているため、別の実装は必要ありません。

はい: haproxy.router.openshift.io/hsts_header ルートアノテーション

cookieset-cookie

いいえ

いいえ

HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。

はい:

  • haproxy.router.openshift.io/disable_cookie ルートアノテーション
  • haproxy.router.openshift.io/cookie_name ルートアノテーション

8.9.14. Ingress Controller での HTTP リクエストおよびレスポンスヘッダーの設定または削除

コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。

たとえば、相互 TLS を使用するようにクラスター上で実行されているアプリケーションを移行する場合があります。このような場合、お使いのアプリケーションで X-Forwarded-Client-Cert リクエストヘッダーをチェックする必要がありますが、OpenShift Container Platform のデフォルトの Ingress Controller は X-SSL-Client-Der リクエストヘッダーを提供します。

次の手順では、Ingress Controller を変更して X-Forwarded-Client-Cert リクエストヘッダーを設定し、X-SSL-Client-Der リクエストヘッダーを削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。

手順

  1. Ingress Controller リソースを編集します。

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
    Copy to Clipboard Toggle word wrap
  2. X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      httpHeaders:
        actions: 
    1
    
          request: 
    2
    
          - name: X-Forwarded-Client-Cert 
    3
    
            action:
              type: Set 
    4
    
              set:
               value: "%{+Q}[ssl_c_der,base64]" 
    5
    
          - name: X-SSL-Client-Der
            action:
              type: Delete
    Copy to Clipboard Toggle word wrap
    1
    HTTP ヘッダーに対して実行するアクションのリスト。
    2
    変更するヘッダーのタイプ。この場合はリクエストヘッダーです。
    3
    変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストは、HTTP ヘッダーの設定 を参照してください。
    4
    ヘッダーに対して実行されるアクションのタイプ。このフィールドには、Set または Delete の値を指定できます。
    5
    HTTP ヘッダーの設定時は、 を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例: DENY) にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、動的な値が追加されます。
    注記

    HTTP 応答の動的ヘッダー値を設定する場合、サンプルフェッチャーとして res.hdr および ssl_c_der を使用できます。HTTP リクエストの動的ヘッダー値を設定する場合、許可されるサンプルフェッチャーは req.hdr および ssl_c_der です。リクエストとレスポンスの両方の動的値で、lower コンバーターと Base64 コンバーターを使用できます。

  3. 変更を適用するためにファイルを保存します。

8.9.15. X-Forwarded ヘッダーの使用

Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法に関するポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。

手順

  1. Ingress Controller 用に HTTPHeaders フィールドを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController
      Copy to Clipboard Toggle word wrap
    2. spec の下で、HTTPHeaders ポリシーフィールドを AppendReplaceIfNone、または Never に設定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append
      Copy to Clipboard Toggle word wrap
使用例

クラスター管理者として、以下を実行できます

  • Ingress Controller に転送する前に、X-Forwarded-For ヘッダーを各リクエストに挿入する外部プロキシーを設定します。

    ヘッダーを変更せずに渡すように Ingress Controller を設定するには、never ポリシーを指定します。これにより、Ingress Controller はヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。

  • 外部プロキシーが外部クラスター要求を設定する X-Forwarded-For ヘッダーを変更せずに渡すように Ingress Controller を設定します。

    外部プロキシーを通過しない内部クラスター要求に X-Forwarded-For ヘッダーを設定するように Ingress Controller を設定するには、if-none ポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress Controller はこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress Controller はヘッダーを追加します。

アプリケーション開発者として、以下を実行できます

  • X-Forwarded-For ヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。

    他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress Controller を設定するには、アプリケーションの Route にアノテーション haproxy.router.openshift.io/set-forwarded-headers: if-none または haproxy.router.openshift.io/set-forwarded-headers: never を追加します。

    注記

    Ingress Controller のグローバルに設定された値とは別に、haproxy.router.openshift.io/set-forwarded-headers アノテーションをルートごとに設定できます。

8.9.16. Ingress Controller で HTTP/2 を有効または無効にする

HAProxy で透過的なエンドツーエンドの HTTP/2 接続を有効化または無効化できます。アプリケーション所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなどの HTTP/2 プロトコル機能を使用できます。

個別の Ingress Controller またはクラスター全体について、HTTP/2 接続を有効化または無効化できます。

注記

個々の Ingress Controller およびクラスター全体に対して HTTP/2 接続を有効または無効にすると、Ingress Controller の HTTP/2 設定がクラスターの HTTP/2 設定よりも優先されます。

クライアントから HAProxy インスタンスへの接続に HTTP/2 の使用を有効にするには、ルートでカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。

各ルートタイプにおける HTTP/2 接続の次のユースケースを検討してください。

  • 再暗号化ルートの場合、アプリケーションが Application-Level Protocol Negotiation (ALPN) を使用して HAProxy と HTTP/2 をネゴシエートすることをサポートしている場合、HAProxy からアプリケーション Pod への接続で HTTP/2 を使用できます。Ingress Controller で HTTP/2 が有効になっていない限り、再暗号化ルートで HTTP/2 を使用できません。
  • パススルールートの場合、アプリケーションが ALPN を使用してクライアントと HTTP/2 をネゴシエートすることをサポートしている場合、接続で HTTP/2 を使用できます。Ingress Controller が HTTP/2 を有効または無効にする場合、パススルールートで HTTP/2 を使用できます。
  • エッジ終端のセキュアなルートの場合、サービスが appProtocol: kubernetes.io/h2c のみを指定すると、接続では HTTP/2 が使用されます。Ingress Controller で HTTP/2 が有効または無効な場合、エッジ終端のセキュアなルートで HTTP/2 を使用できます。
  • 安全でないルートの場合、サービスが appProtocol: kubernetes.io/h2c のみを指定すると、接続では HTTP/2 が使用されます。Ingress Controller で HTTP/2 が有効または無効になっている場合は、安全でないルートで HTTP/2 を使用できます。
重要

パススルー以外のルートの場合、Ingress Controller はクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。これは、クライアントが Ingress Controller に接続し、HTTP/1.1 をネゴシエートする可能性があることを意味します。その後、Ingress Controller はアプリケーションに接続し、HTTP/2 接続を確立し、HTTP/2 接続を使用してクライアント HTTP/1.1 接続からのリクエストをアプリケーションに転送します。

この一連のイベントは、その後クライアントが HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると、問題が発生します。WebSocket 接続の受け入れを目的としたアプリケーションがあり、そのアプリケーションが HTTP/2 プロトコルネゴシエーションを許可しようとすると、クライアントが WebSocket プロトコルへのアップグレードを試行しても失敗することに注意してください。

8.9.16.1. HTTP/2 の有効化

特定の Ingress Controller で HTTP/2 を有効化するか、クラスター全体で HTTP/2 を有効化できます。

手順

  • 特定の Ingress Controller で HTTP/2 を有効化するには、oc annotate コマンドを入力します。

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true 
    1
    Copy to Clipboard Toggle word wrap
    1
    <ingresscontroller_name> は、HTTP/2 を有効化する Ingress Controller の名前に置き換えます。
  • クラスター全体で HTTP/2 を有効にするには、oc annotate コマンドを入力します。

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    Copy to Clipboard Toggle word wrap
ヒント

または、次の YAML コードを適用して HTTP/2 を有効化できます。

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "true"
Copy to Clipboard Toggle word wrap
8.9.16.2. HTTP/2 の無効化

特定の Ingress Controller で HTTP/2 を無効化するか、またはクラスター全体で HTTP/2 を無効化できます。

手順

  • 特定の Ingress Controller で HTTP/2 を無効化するには、oc annotate コマンドを入力します。

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false 
    1
    Copy to Clipboard Toggle word wrap
    1
    <ingresscontroller_name> は、HTTP/2 を無効化する Ingress Controller の名前に置き換えます。
  • クラスター全体で HTTP/2 を無効化するには、oc annotate コマンドを入力します。

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
    Copy to Clipboard Toggle word wrap
ヒント

または、次の YAML コードを適用して HTTP/2 を無効化できます。

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
  annotations:
    ingress.operator.openshift.io/default-enable-http2: "false"
Copy to Clipboard Toggle word wrap

8.9.17. Ingress Controller の PROXY プロトコルの設定

クラスター管理者は、Ingress Controller が HostNetworkNodePortService、または Private エンドポイント公開ストラテジータイプを使用する場合、PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。

警告

Keepalived Ingress 仮想 IP (VIP) を使用するクラウド以外のプラットフォーム上の installer-provisioned クラスターを備えたデフォルトの Ingress Controller は、PROXY プロトコルをサポートしていません。

PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられる送信元 IP アドレスのみが含まれます。

重要

パススルールート設定の場合、OpenShift Container Platform クラスター内のサーバーは、元のクライアント送信元 IP アドレスを監視できません。元のクライアント送信元 IP アドレスを知る必要がある場合は、Ingress Controller の Ingress アクセスロギングを設定して、クライアント送信元 IP アドレスを表示できるようにします。

再暗号化およびエッジルートの場合、OpenShift Container Platform ルーターは Forwarded ヘッダーと X-Forwarded-For ヘッダーを設定し、アプリケーションワークロードがクライアントの送信元 IP アドレスをチェックできるようにします。

Ingress アクセスロギングの詳細は、「Ingress アクセスロギングの設定」を参照してください。

LoadBalancerService エンドポイント公開ストラテジータイプを使用する場合、Ingress Controller の PROXY プロトコルの設定はサポートされません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。

重要

PROXY プロトコルまたは TCP のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

この機能は、クラウドデプロイメントではサポートされていません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。

重要

PROXY プロトコルまたは Transmission Control Protocol (TCP) のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

前提条件

  • Ingress Controller を作成している。

手順

  1. CLI で次のコマンドを入力して、Ingress Controller リソースを編集します。

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
    Copy to Clipboard Toggle word wrap
  2. PROXY 設定を設定します。

    • Ingress Controller が HostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.hostNetwork.protocol サブフィールドを PROXY に設定します。

      PROXY への hostNetwork の設定例

      # ...
        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: HostNetwork
      # ...
      Copy to Clipboard Toggle word wrap

    • Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

      PROXY へのサンプル nodePort 設定

      # ...
        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService
      # ...
      Copy to Clipboard Toggle word wrap

    • Ingress Controller が Private エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.private.protocol サブフィールドを PROXY に設定します。

      PROXY への private 設定のサンプル

      # ...
        spec:
          endpointPublishingStrategy:
            private:
              protocol: PROXY
          type: Private
      # ...
      Copy to Clipboard Toggle word wrap

8.9.18. appsDomain オプションを使用した代替クラスタードメインの指定

クラスター管理者は、appsDomain フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain フィールドは、domain フィールドで指定されているデフォルトの代わりに使用する OpenShift Container Platform のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。

たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc コマンドラインインターフェイスがインストールされている。

手順

  1. ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。

    1. Ingress cluster リソースを編集します。

      $ oc edit ingresses.config/cluster -o yaml
      Copy to Clipboard Toggle word wrap
    2. YAML ファイルを編集します。

      test.example.com への appsDomain の設定例

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            
      1
      
        appsDomain: <test.example.com>      
      2
      Copy to Clipboard Toggle word wrap

      1
      デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。
      2
      オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。
  2. ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。

    注記

    ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。

    1. 次のコマンドを入力してルートを公開します。このコマンドは、ルートの公開を指定するために route.route.openshift.io/hello-openshift exposed を出力します。

      $ oc expose service hello-openshift
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、ルートのリストを取得します。

      $ oc get routes
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None
      Copy to Clipboard Toggle word wrap

8.9.19. HTTP ヘッダーケースの変換

HAProxy では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.comhost: xyz.com に変更されます。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。

重要

OpenShift Container Platform には HAProxy 2.8 が含まれています。このバージョンの Web ベースのロードバランサーに更新する場合は、必ずクラスターの設定ファイルに spec.httpHeaders.headerNameCaseAdjustments セクションを追加してください。

クラスター管理者は、oc patch コマンドを入力するか、Ingress Controller YAML ファイルの HeaderNameCaseAdjustments フィールドを設定して HTTP ヘッダーのケースを変換できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  • oc patch コマンドを使用して、HTTP ヘッダーを大文字にします。

    1. 次のコマンドを実行して、HTTP ヘッダーを host から Host に変更します。

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
      Copy to Clipboard Toggle word wrap
    2. アノテーションをアプリケーションに適用できるように、Route リソースの YAML ファイルを作成します。

      my-application という名前のルートの例

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 
      1
      
        name: <application_name>
        namespace: <application_name>
      # ...
      Copy to Clipboard Toggle word wrap

      1
      Ingress Controller が指定どおりに host リクエストヘッダーを調整できるように、haproxy.router.openshift.io/h1-adjust-case を設定します。
  • Ingress Controller YAML 設定ファイルで HeaderNameCaseAdjustments フィールドを設定して調整を指定します。

    1. 次の Ingress Controller YAML ファイルの例では、適切にアノテーションが付けられたルートへの HTTP/1 リクエストの host ヘッダーを Host に調整します。

      Ingress Controller YAML のサンプル

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host
      Copy to Clipboard Toggle word wrap

    2. 次のルートの例では、haproxy.router.openshift.io/h1-adjust-case アノテーションを使用して HTTP レスポンスヘッダー名の大文字と小文字の調整を有効にします。

      ルート YAML のサンプル

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 
      1
      
        name: my-application
        namespace: my-application
      spec:
        to:
          kind: Service
          name: my-application
      Copy to Clipboard Toggle word wrap

      1
      haproxy.router.openshift.io/h1-adjust-case を true に設定します。

8.9.20. ルーター圧縮の使用

特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes 変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または "X-" で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341 を参照してください。

注記

圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。

すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。

手順

  1. Ingress Controller の httpCompression フィールドを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default
      Copy to Clipboard Toggle word wrap
    2. spec で、httpCompression ポリシーフィールドを mimeTypes に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...
      Copy to Clipboard Toggle word wrap

8.9.21. ルーターメトリクスの公開

デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。

前提条件

  • ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。

手順

  1. 次のコマンドを実行して、ルーター Pod 名を取得します。

    $ oc get pods -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                              READY   STATUS    RESTARTS   AGE
    router-default-76bfffb66c-46qwp   1/1     Running   0          11h
    Copy to Clipboard Toggle word wrap

  2. ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。

    1. 次のコマンドを実行して、ユーザー名を取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、パスワードを取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword
      Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。

    $ oc describe pod <router_pod>
    Copy to Clipboard Toggle word wrap
  4. つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、安全にメトリクスにアクセスします。

    $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    Copy to Clipboard Toggle word wrap

    例8.1 出力例

    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
    Copy to Clipboard Toggle word wrap
  7. ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。

    http://<user>:<password>@<router_IP>:<stats_port>
    Copy to Clipboard Toggle word wrap
  8. オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。

    http://<user>:<password>@<router_ip>:1936/metrics;csv
    Copy to Clipboard Toggle word wrap

8.9.22. HAProxy エラーコードの応答ページのカスタマイズ

クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズすると、アプリケーション Pod が実行していないときにページが提供され、不正なルートまたは存在しないルートに対しては、デフォルトの 404 エラーコード HTTP 応答ページが HAProxy ルーターにより提供されます。

カスタムエラーコードの応答ページは config map に指定し、Ingress Controller にパッチを適用されます。config map キーには、error-page-503.httperror-page-404.http の 2 つの利用可能なファイル名があります。

カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。

デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTP エラーコード応答をカスタマイズするための config map が提供されておらず、カスタム HTTP エラーコード応答ページを使用している場合、ルーターはデフォルトの 404 または 503 エラーコード応答ページを提供します。

注記

OpenShift Container Platform のデフォルトの 503 エラーコードページをカスタマイズのテンプレートとして使用する場合、ファイル内のヘッダーで CRLF 改行コードを使用できるエディターが必要になります。

手順

  1. openshift-configmy-custom-error-code-pages という名前の config map を作成します。

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
      --from-file=error-page-503.http \
      --from-file=error-page-404.http
    Copy to Clipboard Toggle word wrap
    重要

    カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。

  2. Ingress Controller にパッチを適用し、名前を指定して my-custom-error-code-pages config map を参照します。

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages config map をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って config map に名前を付けます。

  3. コピーを表示します。

    $ oc get cm default-errorpages -n openshift-ingress
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                       DATA   AGE
    default-errorpages         2      25s  
    1
    Copy to Clipboard Toggle word wrap

    1
    default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例は default-errorpages です。
  4. カスタムエラー応答ページを含む config map がルーターボリュームにマウントされることを確認します。config map キーは、カスタム HTTP エラーコード応答を持つファイル名です。

    • 503 カスタム HTTP カスタムエラーコード応答の場合:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
      Copy to Clipboard Toggle word wrap
    • 404 カスタム HTTP カスタムエラーコード応答の場合:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
      Copy to Clipboard Toggle word wrap

検証

カスタムエラーコード HTTP 応答を確認します。

  1. テストプロジェクトおよびアプリケーションを作成します。

    $ oc new-project test-ingress
    Copy to Clipboard Toggle word wrap
    $ oc new-app django-psql-example
    Copy to Clipboard Toggle word wrap
  2. 503 カスタム http エラーコード応答の場合:

    1. アプリケーションのすべての Pod を停止します。
    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  3. 404 カスタム http エラーコード応答の場合:

    1. 存在しないルートまたは正しくないルートにアクセスします。
    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>
      Copy to Clipboard Toggle word wrap
  4. errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
    Copy to Clipboard Toggle word wrap

8.9.23. Ingress Controller の最大接続数の設定

クラスター管理者は、OpenShift ルーターデプロイメントの同時接続の最大数を設定できます。既存の Ingress Controller にパッチを適用して、接続の最大数を増やすことができます。

前提条件

  • 以下では、Ingress Controller が作成済みであることを前提とします。

手順

  • Ingress Controller を更新して、HAProxy の最大接続数を変更します。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
    Copy to Clipboard Toggle word wrap
    警告

    spec.tuningOptions.maxConnections の値を現在のオペレーティングシステムの制限よりも大きく設定すると、HAProxy プロセスは開始しません。このパラメーターの詳細は、「Ingress Controller 設定パラメーター」セクションの表を参照してください。

第9章 OpenShift Container Platform の Ingress Node Firewall Operator

Ingress Node Firewall Operator は、OpenShift Container Platform でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。

9.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator は、ファイアウォール設定で指定および管理するノードにデーモンセットをデプロイすることにより、ノードレベルで Ingress ファイアウォールルールを提供します。デーモンセットをデプロイするには、IngressNodeFirewallConfig カスタムリソース (CR) を作成します。Operator は IngressNodeFirewallConfig CR を適用して、nodeSelector に一致するすべてのノードで実行される ingress ノードファイアウォールデーモンセット (daemon) を作成します。

IngressNodeFirewall CR の rules を設定し、nodeSelector を使用して値を "true" に設定してクラスターに適用します。

重要

Ingress Node Firewall Operator は、ステートレスファイアウォールルールのみをサポートします。

ネイティブ XDP ドライバーをサポートしないネットワークインターフェイスコントローラー (NIC) は、より低いパフォーマンスで実行されます。

OpenShift Container Platform 4.14 以降の場合は、RHEL 9.0 以降で Ingress Node Firewall Operator を実行する必要があります。

9.2. Ingress Node Firewall Operator のインストール

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。

9.2.1. CLI を使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. openshift-ingress-node-firewall namespace を作成するには、次のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ingress-node-firewall-operators
      namespace: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  3. Ingress Node Firewall Operator にサブスクライブします。

    1. Ingress Node Firewall Operator の Subscription CR を作成するには、次のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

    $ oc get ip -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            CSV                                         APPROVAL    APPROVED
    install-5cvnz   ingress-node-firewall.4.19.0-202211122336   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. Operator のバージョンを確認するには、次のコマンドを入力します。

    $ oc get csv -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
    ingress-node-firewall.4.19.0-202211122336   Ingress Node Firewall Operator   4.19.0-202211122336   ingress-node-firewall.4.19.0-202211102047   Succeeded
    Copy to Clipboard Toggle word wrap

9.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、Web コンソールを使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. Ingress Node Firewall Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
    3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
    4. Install をクリックします。
  2. Ingress Node Firewall Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. Ingress Node Firewall Operatoropenshift-ingress-node-firewall プロジェクトにリストされ、StatusInstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator の StatusInstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、openshift-ingress-node-firewall プロジェクトの Pod のログを確認します。
      • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション workload.openshift.io/allowed=management を Operator namespace に追加できます。

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        注記

        単一ノードの OpenShift クラスターの場合、openshift-ingress-node-firewall namespace には workload.openshift.io/allowed=management アノテーションが必要です。

9.3. Ingress Node Firewall Operator のデプロイ

前提条件

  • Ingress Node Firewall Operator がインストールされます。

手順

Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。

  1. ingressnodefirewallconfig という名前の openshift-ingress-node-firewall namespace 内に IngressNodeFirewallConfig を作成します。
  2. 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。

    $ oc apply -f rule.yaml
    Copy to Clipboard Toggle word wrap

9.3.1. Ingress ノードファイアウォール設定オブジェクト

Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。

Expand
表9.1 Ingress ノードファイアウォール設定オブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は ingressnodefirewallconfig である必要があります。

metadata.namespace

string

Ingress Firewall Operator CR オブジェクトの namespace。IngressNodeFirewallConfig CR は、openshift-ingress-node-firewall namespace 内に作成する必要があります。

spec.nodeSelector

string

指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap
注記

デーモンセットを開始するには、nodeSelector で使用される 1 つのラベルがノードのラベルと一致する必要があります。たとえば、ノードラベル node-role.kubernetes.io/worker および node-type.kubernetes.io/vm がノードに適用される場合、デーモンセットを開始するには、nodeSelector を使用して少なくとも 1 つのラベルを設定する必要があります。

spec.ebpfProgramManagerMode

boolean

Node Ingress Firewall Operator が eBPF プログラムを管理するために eBPF Manager Operator を使用するかどうかを指定します。この機能はテクノロジープレビュー機能です。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

注記

Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。

9.3.2. Ingress Node Firewall Operator の設定例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォール設定オブジェクトを作成する方法の例

$ cat << EOF | oc create -f -
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
EOF
Copy to Clipboard Toggle word wrap

注記

Operator は CR オブジェクトを消費し、nodeSelector に 一致するすべてのノードに Ingress ノードファイアウォールデーモンセットを作成します。

9.3.3. Ingress ノードファイアウォールルールオブジェクト

Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。

Expand
表9.2 Ingress ノードファイアウォールルールオブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。

interfaces

array

このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、-en0-en1 です。

nodeSelector

array

nodeSelector を使用して、ファイアウォールルールを適用するノードを選択できます。名前付き nodeselector ラベルの値を true に設定して、ルールを適用します。

ingress

object

ingress を使用すると、クラスター上のサービスへの外部アクセスを許可するルールを設定できます。

9.3.3.1. Ingress オブジェクトの設定

ingress オブジェクトの値は、次の表で定義されています。

Expand
表9.3 ingress オブジェクト
フィールド説明

sourceCIDRs

array

CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。

注記

異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の IngressNodeFirewall オブジェクトがある場合、order フィールドは最初に適用されるルールを指定します。ルールは昇順で適用されます。

rules

array

Ingress ファイアウォール rules.order オブジェクトは、source.CIDR ごとに 1 から順に並べられ、CIDR ごとに最大 100 のルールがあります。低次ルールが最初に実行されます。

rules.protocolConfig.protocol は次のプロトコルをサポートします: TCP、UDP、SCTP、ICMP、および ICMPv6。ICMP および ICMPv6 ルールは、ICMP および ICMPv6 のタイプまたはコードと照合できます。TCP、UDP、および SCTP ルールは、<start : end-1> 形式を使用して、単一の宛先ポートまたはポートの範囲に対して照合できます。

rules.action を設定してルールの適用を allow するか、deny してルールを禁止します。

注記

Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。

9.3.3.2. Ingress ノードファイアウォールルールオブジェクトの例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォールの設定例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 
1

  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny
Copy to Clipboard Toggle word wrap

1
<label_name> と <label_value> はノード上に存在する必要があり、ingressfirewallconfig CR を実行するノードに適用される nodeselector ラベルと値に一致する必要があります。<label_value> は、true または false です。nodeSelector ラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfig CR の使用に異なるルールを適用できます。
9.3.3.3. ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例

ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。

次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。

重要

次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。

ゼロトラストの Ingress ノードファイアウォールルールの例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 
1

 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 
2

 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 
3

   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 
4
Copy to Clipboard Toggle word wrap

1
ネットワークインターフェイスクラスター
2
<label_name> と <label_value> は、ingressfirewallconfig CR を適用する特定のノードに適用される nodeSelector ラベルと値に一致する必要があります。
3
0.0.0.0/0 は、任意の CIDR に一致するように設定されています
4
Deny に設定された action
重要

eBPF Manager Operator の統合は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

9.4. Ingress ノードファイアウォール Operator の統合

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。代わりに、これらのプログラムのロードと管理に eBPF Manager Operator を使用するように Ingress Node Firewall Operator を設定できます。

この統合を有効にすると、次の制限が適用されます。

  • XDP が利用できず、TCX が bpfman と互換性がない場合、Ingress Node Firewall Operator は TCX を使用します。
  • Ingress Node Firewall Operator デーモンセットの Pod は、ファイアウォールルールが適用されるまで ContainerCreating 状態のままになります。
  • Ingress Node Firewall Operator デーモンセットの Pod は権限として実行します。

9.5. eBPF Manager Operator を使用するように Ingress ノードファイアウォール Operator の設定

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。

クラスター管理者は、Ingress Node Firewall Operator を設定して、代わりに eBPF Manager Operator を使用してこれらのプログラムをロードおよび管理し、セキュリティーと監視機能を追加できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。
  • Ingress Node Firewall Operator をインストールしました。
  • eBPF Manager Operator をインストールしている。

手順

  1. ingress-node-firewall-system namespace に次のラベルを適用します。

    $ oc label namespace openshift-ingress-node-firewall \
        pod-security.kubernetes.io/enforce=privileged \
        pod-security.kubernetes.io/warn=privileged --overwrite
    Copy to Clipboard Toggle word wrap
  2. ingressnodefirewallconfig という名前の IngressNodeFirewallConfig オブジェクトを編集し、ebpfProgramManagerMode フィールドを設定します。

    Ingress Node Firewall Operator 設定オブジェクト

    apiVersion: ingressnodefirewall.openshift.io/v1alpha1
    kind: IngressNodeFirewallConfig
    metadata:
      name: ingressnodefirewallconfig
      namespace: openshift-ingress-node-firewall
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      ebpfProgramManagerMode: <ebpf_mode>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <ebpf_mode>: Ingress Node Firewall Operator が eBPF Manager Operator を使用して eBPF プログラムを管理するかどうかを指定します。true または false のどちらかでなければなりません。設定されていないと、eBPF マネージャーは使用されません。

9.6. Ingress Node Firewall Operator ルールの表示

手順

  1. 次のコマンドを実行して、現在のルールをすべて表示します。

    $ oc get ingressnodefirewall
    Copy to Clipboard Toggle word wrap
  2. 返された <resource> 名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。

    $ oc get <resource> <name> -o yaml
    Copy to Clipboard Toggle word wrap

9.7. Ingress Node Firewall Operator のトラブルシューティング

  • 次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。

    $ oc get crds | grep ingressnodefirewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
    ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
    ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z
    Copy to Clipboard Toggle word wrap

  • 次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。

    $ oc get pods -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       READY  STATUS         RESTARTS  AGE
    ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
    ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h
    Copy to Clipboard Toggle word wrap

    次のフィールドは、Operator のステータスに関する情報を提供します: READYSTATUSAGE、および RESTARTS。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUS フィールドは Running になります。

  • 次のコマンドを実行して、すべての Ingress ファイアウォールノード Pod のログを収集します。

    $ oc adm must-gather – gather_ingress_node_firewall
    Copy to Clipboard Toggle word wrap

    ログは、/sos_commands/ebpf にある eBPF bpftool 出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。

第10章 SR-IOV Operator

10.1. SR-IOV Network Operator のインストール

Single Root I/O Virtualization (SR-IOV) Network Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークアタッチメントを管理できます。

10.1.1. SR-IOV Network Operator のインストール

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して、Single Root I/O Virtualization (SR-IOV) Network Operator をインストールできます。

10.1.1.1. CLI: SR-IOV Network Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントがある。

手順

  1. 次のコマンドを入力して、openshift-sriov-network-operator namespace を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
      annotations:
        workload.openshift.io/allowed: management
    EOF
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、OperatorGroup カスタムリソース (CR) を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    EOF
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、SR-IOV Network Operator の Subscription CR を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subscription
      namespace: openshift-sriov-network-operator
    spec:
      channel: stable
      name: sriov-network-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、SriovoperatorConfig リソースを作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: true
      enableOperatorWebhook: true
      logLevel: 2
      disableDrain: false
    EOF
    Copy to Clipboard Toggle word wrap

検証

  • Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に Succeeded と表示されていることを確認します。

    $ oc get csv -n openshift-sriov-network-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap
10.1.1.2. Web コンソール: SR-IOV Network Operator のインストール

クラスター管理者は、Web コンソールを使用して Operator をインストールできます。

前提条件

  • SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントがある。

手順

  1. SR-IOV Network Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
    3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
    4. Install をクリックします。
  2. SR-IOV Network Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. StatusInstallSucceeded の状態で、SR-IOV Network Operatoropenshift-sriov-network-operator プロジェクトにリスト表示されていることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、openshift-sriov-network-operator プロジェクトで Pod のログを確認します。
      • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション workload.openshift.io/allowed=management を Operator namespace に追加できます。

        $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        注記

        シングルノード OpenShift クラスターの場合は、namespace にアノテーション workload.openshift.io/allowed=management が必要です。

10.1.2. 次のステップ

10.2. SR-IOV Network Operator の設定

Single Root I/O Virtualization (SR-IOV) Network Operator は、クラスター内の SR-IOV ネットワークデバイスとネットワークアタッチメントを管理します。

10.2.1. SR-IOV Network Operator の設定

  • すべての SR-IOV Operator コンポーネントをデプロイするには、SriovOperatorConfig カスタムリソース (CR) を作成します。

    1. 次の YAML を使用して、sriovOperatorConfig.yaml という名前のファイルを作成します。

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovOperatorConfig
      metadata:
        name: default 
      1
      
        namespace: openshift-sriov-network-operator
      spec:
        disableDrain: false
        enableInjector: true 
      2
      
        enableOperatorWebhook: true 
      3
      
        logLevel: 2
        featureGates:
          metricsExporter: false
      Copy to Clipboard Toggle word wrap
      1
      SriovOperatorConfig リソースの有効な名前は default のみであり、Operator がデプロイされている namespace 内にある必要があります。
      2
      enableInjector フィールドは、CR で指定されていないか、明示的に true に設定されていない場合、デフォルトで false または <none> に設定されます。その場合、namespace で network-resources-injector Pod が実行されなくなります。推奨設定は true です。
      3
      enableOperatorWebhook フィールドは、CR で指定されていないか、明示的に true に設定されていない場合、デフォルトで false または <none> に設定されます。その場合、namespace で operator-webhook Pod が実行されなくなります。推奨設定は true です。
    2. 次のコマンドを実行して、リソースを作成します。

      $ oc apply -f sriovOperatorConfig.yaml
      Copy to Clipboard Toggle word wrap
10.2.1.1. SR-IOV Network Operator config カスタムリソース

sriovoperatorconfig カスタムリソースのフィールドは、以下の表で説明されています。

Expand
表10.1 SR-IOV Network Operator config カスタムリソース
フィールド説明

metadata.name

string

SR-IOV Network Operator インスタンスの名前を指定します。デフォルト値は default です。別の値を設定しないでください。

metadata.namespace

string

SR-IOV Network Operator インスタンスの namespace を指定します。デフォルト値は openshift-sriov-network-operator です。別の値を設定しないでください。

spec.configDaemonNodeSelector

string

選択されたノードで SR-IOV Network Config Daemon のスケジューリングを制御するノードの選択オプションを指定します。デフォルトでは、このフィールドは設定されておらず、Operator はワーカーノードに SR-IOV Network Config デーモンセットを配置します。

spec.disableDrain

boolean

新しいポリシーを適用してノードに NIC を設定する時に、ノードドレインプロセスを無効にするか、有効にするかを指定します。このフィールドを true に設定すると、ソフトウェアの開発や OpenShift Container Platform の単一ノードへのインストールが容易になります。デフォルトでは、このフィールドは設定されていません。

シングルノードクラスターの場合は、Operator のインストール後にこのフィールドを true に設定します。このフィールドは必ず true に設定してください。

spec.enableInjector

boolean

Network Resources Injector デーモンセットを有効にするか無効にするかを指定します。

spec.enableOperatorWebhook

boolean

Operator Admission Controller の Webhook デーモンセットを有効にするか無効にするかを指定します。

spec.logLevel

integer

Operator のログの詳細レベルを指定します。デフォルトでは、このフィールドは 0 に設定されており、基本的なログのみが表示されます。2 に設定すると、利用可能なすべてのログが表示されます。

spec.featureGates

map[string]bool

任意の機能を有効にするか無効にするかを指定します。たとえば、metricsExporter です。

spec.featureGates.metricsExporter

boolean

SR-IOV Network Operator メトリクスを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは false に設定されています。

spec.featureGates.mellanoxFirmwareReset

boolean

SR-IOV Network Operator の Virtual Function (VF) の変更時にファームウェアをリセットするかどうかを指定します。Intel C740 シリーズなどの一部のチップセットでは、NVIDIA/Mellanox NIC で VF を設定するために必要な PCI-E デバイスの電源が完全にオフになりません。デフォルトでは、このフィールドは false に設定されています。

重要

spec.featureGates.mellanoxFirmwareReset パラメーターは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

10.2.1.2. Network Resources Injector について

Network Resources Injector は、Kubernetes Dynamic Admission Controller アプリケーションであり、次の機能を提供します。

  • SR-IOV リソース名を SR-IOV ネットワーク割り当て定義アノテーションに従って追加するための、Pod 仕様でのリソース要求および制限の変更。
  • Pod のアノテーション、ラベル、および huge page の要求および制限を公開するための Downward API ボリュームでの Pod 仕様の変更。Pod で実行されるコンテナーは、公開される情報に /etc/podnetinfo パスでファイルとしてアクセスできます。

Network Resources Injector は、SriovOperatorConfig CR で enableInjectortrue に設定されている場合、SR-IOV Network Operator によって有効になります。network-resources-injector Pod は、すべてのコントロールプレーンノード上でデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Network Resources Injector Pod の例です。

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m
Copy to Clipboard Toggle word wrap

デフォルトでは、Network Resources Injector Webhook の failurePolicy フィールドは Ignore に設定されています。このデフォルト設定により、Webhook が利用できない場合でも Pod の作成がブロックされなくなります。

failurePolicy フィールドが Fail に設定され、Network Resources Injector Webhook が利用できない場合は、Webhook はすべての Pod 作成および更新リクエストを変更しようとします。この動作により、Pod の作成がブロックされ、通常のクラスター操作が中断される可能性があります。このような問題を回避するには、SriovOperatorConfig オブジェクトの featureGates.resourceInjectorMatchCondition 機能を有効にして、Network Resources Injector Webhook のスコープを制限できます。この機能を有効にすると、Webhook はセカンダリーネットワークアノテーション k8s.v1.cni.cncf.io/networks を持つ Pod にのみ適用されます。

resourceInjectorMatchCondition 機能の有効化後、failurePolicy フィールドを Fail に設定すると、Webhook はセカンダリーネットワークアノテーション k8s.v1.cni.cncf.io/networks を持つ Pod にのみ適用されます。Webhook が利用できない場合でも、このアノテーションのない Pod はデプロイされ、クラスター操作の不要な中断を防ぎます。

featureGates.resourceInjectorMatchCondition 機能はデフォルトで無効になっています。この機能を有効にするには、SriovOperatorConfig オブジェクトで featureGates.resourceInjectorMatchCondition フィールドを true に設定します。

SriovOperatorConfig オブジェクトの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: sriov-network-operator
spec:
# ...
  featureGates:
    resourceInjectorMatchCondition: true
# ...
Copy to Clipboard Toggle word wrap

10.2.1.3. Network Resources Injector の無効化または有効化

Network Resources Injector を無効または有効にするには、次の手順を実行します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • SR-IOV Network Operator がインストールされていること。

手順

  • enableInjector フィールドを設定します。<value>false に置き換えて機能を無効にするか、true に置き換えて機能を有効にします。

    $ oc patch sriovoperatorconfig default \
      --type=merge -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableInjector": <value> } }'
    Copy to Clipboard Toggle word wrap
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: <value>
    Copy to Clipboard Toggle word wrap
10.2.1.4. SR-IOV Network Operator Admission Controller Webhook について

SR-IOV Network Operator Admission Controller Webhook は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。

  • 作成時または更新時の SriovNetworkNodePolicy CR の検証
  • CR の作成または更新時の priority および deviceType フィールドのデフォルト値の設定による SriovNetworkNodePolicy CR の変更

SR-IOV Network Operator Admission Controller Webhook は、SriovOperatorConfig CR で enableOperatorWebhooktrue に設定されている場合、Operator によって有効になります。operator-webhook Pod は、すべてのコントロールプレーンノード上でデーモンセットとして実行されます。

注記

SR-IOV Network Operator Admission Controller Webhook を無効にする場合は注意してください。トラブルシューティングなどの特定の状況下や、サポートされていないデバイスを使用する場合は、Webhook を無効にすることができます。サポート対象外のデバイスの設定は、サポート対象外の NIC を使用するための SR-IOV Network Operator の設定 を参照してください。

以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。

$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m
Copy to Clipboard Toggle word wrap

10.2.1.5. SR-IOV Network Operator Admission Controller Webhook の無効化または有効化

Admission Controller Webhook を無効または有効にするには、次の手順を実行します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • SR-IOV Network Operator がインストールされていること。

手順

  • enableOperatorWebhook フィールドを設定します。<value>false に置き換えて機能を無効するか、true に置き換えて機能を有効にします。

    $ oc patch sriovoperatorconfig default --type=merge \
      -n openshift-sriov-network-operator \
      --patch '{ "spec": { "enableOperatorWebhook": <value> } }'
    Copy to Clipboard Toggle word wrap
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableOperatorWebhook: <value>
    Copy to Clipboard Toggle word wrap
10.2.1.6. カスタムノードセレクターについて

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

10.2.1.7. SR-IOV Network Config Daemon のカスタム NodeSelector の設定

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

SR-IOV Network Config デーモンがデプロイされるノードを指定するには、以下の手順を実行します。

重要

configDaemonNodeSelector フィールドを更新する際に、SR-IOV Network Config デーモンがそれぞれの選択されたノードに再作成されます。デーモンが再作成されている間、クラスターのユーザーは新規の SR-IOV Network ノードポリシーを適用したり、新規の SR-IOV Pod を作成したりできません。

手順

  • Operator のノードセレクターを更新するには、以下のコマンドを入力します。

    $ oc patch sriovoperatorconfig default --type=json \
      -n openshift-sriov-network-operator \
      --patch '[{
          "op": "replace",
          "path": "/spec/configDaemonNodeSelector",
          "value": {<node_label>}
        }]'
    Copy to Clipboard Toggle word wrap

    以下の例のように、<node_label> を適用するラベルに置き換えます: "node-role.kubernetes.io/worker": ""

    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        <node_label>
    Copy to Clipboard Toggle word wrap
10.2.1.8. 単一ノードのインストール用の SR-IOV Network Operator の設定

デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、このアクションを実行して、再設定する前に Virtual Function を使用しているワークロードがないことを確認します。

1 つのノードにインストールする場合には、ワークロードを受信するノードは他にありません。そのため、Operator は、単一のノードからワークロードがドレインされないように設定する必要があります。

重要

以下の手順を実行してワークロードのドレインを無効にした後に、SR-IOV ネットワークインターフェイスを使用しているワークロードを削除してから SR-IOV ネットワークノードのポリシーを変更する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • SR-IOV Network Operator がインストールされていること。

手順

  • disableDrain フィールドを true に設定し、configDaemonNodeSelector フィールドを node-role.kubernetes.io/master: "" に設定するには、以下のコマンドを入力します。

    $ oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'
    Copy to Clipboard Toggle word wrap
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      disableDrain: true
      configDaemonNodeSelector:
       node-role.kubernetes.io/master: ""
    Copy to Clipboard Toggle word wrap
10.2.1.9. Hosted Control Plane 用の SR-IOV Operator のデプロイ

ホスティングサービスクラスターを設定してデプロイすると、ホステッドクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。

前提条件

AWS 上でホステッドクラスターを設定およびデプロイしている。

手順

  1. namespace と Operator グループを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap
  2. SR-IOV Operator へのサブスクリプションを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subsription
      namespace: openshift-sriov-network-operator
    spec:
      channel: stable
      name: sriov-network-operator
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: ""
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

検証

  1. SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。

    $ oc get csv -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
    sriov-network-operator.4.19.0-202211021237   SR-IOV Network Operator   4.19.0-202211021237   sriov-network-operator.4.19.0-202210290517   Succeeded
    Copy to Clipboard Toggle word wrap

  2. SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

10.2.2. SR-IOV ネットワークメトリクスエクスポーターについて

Single Root I/O Virtualization (SR-IOV) ネットワークメトリクスエクスポーターは、SR-IOV Virtual Function (VF) のメトリクスを読み取り、これらの VF メトリクスを Prometheus 形式で公開します。SR-IOV ネットワークメトリクスエクスポーターが有効になっている場合は、OpenShift Container Platform Web コンソールを使用して SR-IOV VF メトリクスをクエリーし、SR-IOV Pod のネットワークアクティビティーを監視できます。

Web コンソールを使用して SR-IOV VF メトリクスをクエリーすると、SR-IOV ネットワークメトリクスエクスポーターは、VF が接続されている Pod の名前と namespace とともに、VF ネットワーク統計を取得して返します。

次の表は、メトリクスエクスポーターが Prometheus 形式で読み取り、公開する SR-IOV VF メトリクスを説明します。

Expand
表10.2 SR-IOV VF メトリクス
メトリクス説明VF メトリクスを調べるための PromQL クエリーの例

sriov_vf_rx_bytes

Virtual Function ごとに受信したバイト数。

sriov_vf_rx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_bytes

Virtual Function ごとに送信されたバイト数。

sriov_vf_tx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_packets

Virtual Function ごとの受信パケット数。

sriov_vf_rx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_packets

Virtual Function あたりの送信パケット数。

sriov_vf_tx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_dropped

Virtual Function ごとに受信時にドロップされたパケット。

sriov_vf_rx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_tx_dropped

Virtual Function ごとに送信中にドロップされたパケット。

sriov_vf_tx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_multicast

Virtual Function ごとに受信したマルチキャストパケット。

sriov_vf_rx_multicast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_vf_rx_broadcast

Virtual Function ごとに受信したブロードキャストパケット。

sriov_vf_rx_broadcast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice

sriov_kubepoddevice

アクティブな Pod にリンクされた Virtual Function。

-

これらのクエリーを kube-state-metrics と組み合わせて、SR-IOV Pod に関する詳細情報を取得することもできます。たとえば、次のクエリーを使用して、標準の Kubernetes Pod ラベルからアプリケーション名とともに VF ネットワーク統計を取得できます。

(sriov_vf_tx_packets * on (pciAddr,node)  group_left(pod,namespace)  sriov_kubepoddevice) * on (pod,namespace) group_left (label_app_kubernetes_io_name) kube_pod_labels
Copy to Clipboard Toggle word wrap
10.2.2.1. SR-IOV ネットワークメトリクスエクスポーターを有効にする

Single Root I/O Virtualization (SR-IOV) ネットワークメトリクスエクスポーターは、デフォルトでは無効になっています。メトリクスエクスポーターを有効にするには、spec.featureGates.metricsExporter フィールドを true に設定する必要があります。

重要

メトリクスエクスポーターが有効になっていると、SR-IOV Network Operator は SR-IOV 機能を持つノードにのみメトリクスエクスポーターをデプロイします。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • SR-IOV Network Operator がインストールされている。

手順

  1. 次のコマンドを実行して、クラスター監視を有効にします。

    $ oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
    Copy to Clipboard Toggle word wrap

    クラスター監視を有効にするには、SR-IOV Network Operator をインストールした namespace に openshift.io/cluster-monitoring=true ラベルを追加する必要があります。

  2. 次のコマンドを実行して、spec.featureGates.metricsExporter フィールドを true に設定します。

    $ oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \
        --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、SR-IOV ネットワークメトリクスエクスポーターが有効になっていることを確認します。

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                     READY   STATUS    RESTARTS   AGE
    operator-webhook-hzfg4                   1/1     Running   0          5d22h
    sriov-network-config-daemon-tr54m        1/1     Running   0          5d22h
    sriov-network-metrics-exporter-z5d7t     1/1     Running   0          10s
    sriov-network-operator-cc6fd88bc-9bsmt   1/1     Running   0          5d22h
    Copy to Clipboard Toggle word wrap

    sriov-network-metrics-exporter Pod は READY 状態である必要があります。

  2. オプション: OpenShift Container Platform Web コンソールを使用して、SR-IOV Virtual Function (VF) メトリクスを調べます。詳細は、「メトリクスのクエリー」を参照してください。

10.2.3. 次のステップ

10.3. SR-IOV Network Operator のアンインストール

SR-IOV Network Operator をアンインストールするには、実行中の SR-IOV ワークロードをすべて削除し、Operator をアンインストールして、Operator が使用した Webhook を削除する必要があります。

10.3.1. SR-IOV Network Operator のアンインストール

クラスター管理者は、SR-IOV Network Operator をアンインストールできます。

前提条件

  • cluster-admin 権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • SR-IOV Network Operator がインストールされている。

手順

  1. すべての SR-IOV カスタムリソース (CR) を削除します。

    $ oc delete sriovnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovibnetwork -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
    $ oc delete sriovoperatorconfigs -n openshift-sriov-network-operator --all
    Copy to Clipboard Toggle word wrap
  2. 「クラスターからの Operator の削除」セクションに記載された手順に従い、クラスターから SR-IOV Network Operator を削除します。
  3. SR-IOV Network Operator のアンインストール後にクラスターに残っている SR-IOV カスタムリソース定義を削除します。

    $ oc delete crd sriovibnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovnetworks.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
    $ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
    Copy to Clipboard Toggle word wrap
  4. SR-IOV Network Operator の namespace を削除します。

    $ oc delete namespace openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

第11章 DPU Operator

11.1. DPU と DPU Operator について

クラスター管理者は、DPU Operator をクラスターに追加して、DPU デバイスとネットワークアタッチメントを管理できます。

重要

DPU Operator はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

11.1.1. DPU Operator による DPU のオーケストレーション

Data Processing Unit (DPU) は、プログラム可能なプロセッサーの一種です。CPU や GPU と並んでコンピューティングを支える 3 つの基本的な柱の 1 つと考えられています。CPU が一般的なコンピューティングタスクを処理し、GPU が特定のワークロードを高速化するのに対し、DPU の主なロールは、ネットワーク、ストレージ、セキュリティー機能などのデータ中心のワークロードをオフロードして高速化することです。

DPU は通常、データセンターやクラウド環境で、CPU からこれらのタスクをオフロードすることでパフォーマンスを向上させ、レイテンシーを削減し、セキュリティーを強化するために使用されます。DPU は、特化したワークロードをデータソースのより近くにデプロイすることを可能にし、それによって、より効率的で柔軟なインフラストラクチャーを構築するためにも利用できます。

DPU Operator は、DPU デバイスとネットワークアタッチメントを管理します。DPU Operator は、DPU 上で稼働する DPU デーモンを制御する API を介して通信する OpenShift Container Platform コンピュートノードに、DPU デーモンをデプロイします。DPU Operator は、ovn-kube コンポーネントのライフサイクル管理と、DPU における必須のホストネットワーク初期化という役割を担います。

現在サポートされている DPU デバイスを次の表に示します。

Expand
表11.1 サポートされているデバイス
ベンターデバイスファームウェア説明

Intel

IPU E2100

バージョン 2.0.0.11126 以降

データセンターのホスト CPU からネットワーク、ストレージ、およびセキュリティータスクをオフロードし、効率とパフォーマンスを向上させるように設計された DPU。完全なエンドツーエンドのソリューションをデプロイする手順は、Red Hat ナレッジベースソリューション Accelerating Confidential AI on OpenShift with the Intel E2100 IPU, DPU Operator, and F5 NGINX を参照してください。

11.2. DPU Operator のインストール

クラスターにデータ処理ユニット (DPU) Operator をインストールして、DPU デバイスとネットワークアタッチメントを管理できます。DPU Operator をホストクラスターとすべての DPU クラスターの両方にインストールします。DPU Operator は、サポートされているすべての DPU のライフサイクルを管理します。

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して DPU Operator をインストールできます。

注記

ホストクラスターと各 DPU クラスターに DPU Operator をインストールする必要があります。

11.2.1. CLI を使用して DPU Operator をインストールする

クラスター管理者は、CLI を使用して DPU Operator をインストールできます。

注記

DPU クラスターに DPU Operator をインストールするには、CLI を使用する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントがある。

手順

  1. 次のコマンドを入力して、openshift-dpu-operator namespace を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-dpu-operator
      annotations:
        workload.openshift.io/allowed: management
    EOF
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、OperatorGroup カスタムリソース (CR) を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: dpu-operators
      namespace: openshift-dpu-operator
    spec:
      targetNamespaces:
      - openshift-dpu-operator
    EOF
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、DPU Operator の Subscription CR を作成します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-dpu-operator-subscription
      namespace: openshift-dpu-operator
    spec:
      channel: stable
      name: dpu-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF
    Copy to Clipboard Toggle word wrap

検証

  1. Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に Succeeded と表示されていることを確認します。

    $ oc get csv -n openshift-dpu-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap
  2. openshift-dpu-operator プロジェクトに変更します。

    $ oc project openshift-dpu-operator
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、DPU Operator が実行されていることを確認します。

    $ oc get pods -n openshift-dpu-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                               READY   STATUS    RESTARTS   AGE
    dpu-operator-controller-manager-6b7bbb5db8-7lvkj   2/2     Running   0          2m9s
    Copy to Clipboard Toggle word wrap

11.2.2. Web コンソールを使用して DPU Operator をインストールする

クラスター管理者は、Web コンソールを使用して DPU Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントがある。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. 利用可能な Operator のリストから DPU Operator を選択してから Install をクリックします。
  3. Install Operator ページの Installed Namespace で、Operator recommended Namespace オプションを選択します。アクションは不要です。

    1. Install をクリックします。

検証

  1. OperatorsInstalled Operators ページに移動します。
  2. DPU Operator が、ステータスInstallSucceededopenshift-dpu-operator プロジェクトにリストされていることを確認します。

    注記

    インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

トラブルシューティング

  • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
  • WorkloadsPods ページに移動し、openshift-dpu-operator プロジェクトで Pod のログを確認します。
  • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション workload.openshift.io/allowed=management を Operator namespace に追加できます。

    $ oc annotate ns/openshift-dpu-operator workload.openshift.io/allowed=management
    Copy to Clipboard Toggle word wrap
    注記

    シングルノード OpenShift クラスターの場合は、namespace にアノテーション workload.openshift.io/allowed=management が必要です。

11.2.3. 次のステップ

11.3. DPU Operator の設定

クラスター内の DPU デバイスとネットワークアタッチメントを管理するように DPU Operator を設定できます。

11.3.1. DPU Operator の設定

DPU Operator を設定するには、次の手順に従います。

手順

  1. ホストクラスターと各 DPU クラスターの両方に DpuOperatorConfig カスタムリソース (CR) を作成します。この CR が作成された後に、各クラスターの DPU Operator がアクティブ化されます。
  2. 次の YAML を使用して、dpu-operator-host-config.yaml という名前のファイルを作成します。

    apiVersion: config.openshift.io/v1
    kind: DpuOperatorConfig
    metadata:
     name: dpu-operator-config 
    1
    
    spec:
     mode: host 
    2
    Copy to Clipboard Toggle word wrap
    1
    カスタムリソースの名前は dpu-operator-config にする必要があります。
    2
    ホストクラスター上で値を host に設定します。DPU ごとに 1 つの MicroShift クラスターを実行する各 DPU クラスターで、値を dpu に設定します。
  3. 次のコマンドを実行して、リソースを作成します。

    $ oc apply -f dpu-operator-host-config.yaml
    Copy to Clipboard Toggle word wrap
  4. DPU が接続されている、あるいは DPU として機能している、そのいずれかに該当するすべてのノードにラベルを付ける必要があります。ホストクラスターでは、各ノードに DPU が接続されているものと見なし、すべてのコンピュートノードに dpu=true というラベルを付けることを意味します。各 MicroShift クラスターが単一のノードで構成される DPU では、各クラスター内のそのシングルノードに dpu=true のラベルを付けます。次のコマンドを実行してこのラベルを適用できます。

    $ oc label node <node_name> dpu=true
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    node_name
    ノードの名前を参照します (例: worker-1)。

11.4. DPU でワークロードを実行する

DPU でワークロードを実行すると、ネットワーク、セキュリティー、ストレージなどの特殊なインフラストラクチャータスクを専用の処理ユニットにオフロードできるようになります。これにより、パフォーマンスが向上し、インフラストラクチャーとアプリケーションのワークロード間のセキュリティー境界が強化され、ホストの CPU リソースが解放されます。

11.4.1. DPU でワークロードを実行する

DPU にワークロードをデプロイするには、次の手順に従います。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントが利用可能である。
  • DPU Operator がインストールされている。

手順

  1. 次の YAML を使用してホスト側にサンプルワークロードを作成し、ファイルを workload-host.yaml として保存します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
      namespace: default
      annotations:
        k8s.v1.cni.cncf.io/networks: default-sriov-net
    spec:
      nodeSelector:
        kubernetes.io/hostname: worker-237 
    1
    
      containers:
      - name: appcntr1
        image: registry.access.redhat.com/ubi9/ubi:latest
        command: ['/bin/sh', '-c', 'sleep infinity']
        imagePullPolicy: Always
        securityContext:
          priviledged: true
          runAsNonRoot: false
          runAsUser: 0
          seccompProfile:
            type: RuntimeDefault
        resources:
          requests:
            openshift.io/dpu: '1'
          limits:
            openshift.io/dpu: '1'
    Copy to Clipboard Toggle word wrap
    1
    ワークロードがデプロイされるノードの名前。
  2. 次のコマンドを実行して、ワークロードを作成します。

    $ oc apply -f workload-host.yaml
    Copy to Clipboard Toggle word wrap

11.4.2. DPU 上にサービスファンクションチェーンを作成する

ネットワークサービスチェイニング (サービスファンクションチェイニング (SFC) とも呼ばれる) は、ソフトウェア定義ネットワーク (SDN) 機能を使用して、接続されたネットワークサービスのチェーンを作成する機能です。このチェーンには、ファイアウォール、ネットワークアドレス変換 (NAT)、侵入防止といった L4-7 サービスなどが含まれます。

以下の手順に従い、DPU 上でサービスファンクションチェーン内に my-network-function ネットワーク機能を作成します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つアカウントがある。
  • DPU Operator をインストールします。

手順

  1. 次の YAML ファイルの例を sfc.yaml として保存します。

    apiVersion: config.openshift.io/v1
    kind: ServiceFunctionChain
    metadata:
      name: sfc
      namespace: openshift-dpu-operator
    spec:
      networkFunctions:
      - name: my-network-function 
    1
    
        image: quay.io/example-org/my-network-function:latest 
    2
    Copy to Clipboard Toggle word wrap
    1
    ネットワーク関数の名前。この名前は、サービスファンクションチェーン内のネットワーク機能を識別するために使用されます。
    2
    ネットワーク機能を含むコンテナーイメージへの URL。イメージは DPU からアクセスできる必要があります。
  2. DPU ノードで次のコマンドを実行してチェーンを作成します。

    $ oc apply -f sfc.yaml
    Copy to Clipboard Toggle word wrap

11.5. DPU Operator のアンインストール

DPU Operator をアンインストールするには、まず実行中の DPU ワークロードを削除する必要があります。DPU Operator をアンインストールするには、次の手順に従います。

11.5.1. DPU Operator のアンインストール

クラスター管理者は、DPU Operator をアンインストールできます。

前提条件

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

手順

  1. 次のコマンドを実行して作成された DpuOperatorConfig CR を削除します。

    $ oc delete DpuOperatorConfig dpu-operator-config
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、DPU Operator のインストールに使用されたサブスクリプションを削除します。

    $ oc delete Subscription openshift-dpu-operator-subscription -n openshift-dpu-operator
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、作成された OperatorGroup リソースを削除します。

    $ oc delete OperatorGroup dpu-operators -n openshift-dpu-operator
    Copy to Clipboard Toggle word wrap
  4. 次のように DPU Operator をアンインストールします。

    1. 次のコマンドを実行して、インストールされている Operator を確認します。

      $ oc get csv -n openshift-dpu-operator
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                DISPLAY        VERSION               REPLACES   PHASE
      dpu-operator.v4.19.0-202503130333   DPU Operator   4.19.0-202503130333              Failed
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して DPU Operator を削除します。

      $ oc delete csv dpu-operator.v4.19.0-202503130333 -n openshift-dpu-operator
      Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、DPU Operator 用に作成された namespace を削除します。

    $ oc delete namespace openshift-dpu-operator
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、DPU Operator がアンインストールされていることを確認します。成功したコマンド出力の例は、No resources found in openshift-dpu-operator namespace です。

    $ oc get csv -n openshift-dpu-operator
    Copy to Clipboard Toggle word wrap

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat