ネットワーク Operator
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
権限を持つユーザーとしてログインしている。
手順
- Operators → OperatorHub を選択します。
-
All Items の下の検索フィールドに、
nmstate
と入力し、Enter をクリックして Kubernetes NMState Operator を検索します。 - Kubernetes NMState Operator の検索結果をクリックします。
- Install をクリックして、Install Operator ウィンドウを開きます。
- Install をクリックして Operator をインストールします。
- Operator のインストールが完了したら、View Operator をクリックします。
-
Provided APIs で Create Instance をクリックし、
kubernetes-nmstate
のインスタンスを作成するダイアログボックスを開きます。 ダイアログボックスの Name フィールドで、インスタンスの名前が
nmstate
であることを確認します。注記名前の制限は既知の問題です。インスタンスはクラスター全体のシングルトンです。
- デフォルト設定を受け入れ、Create をクリックしてインスタンスを作成します。
1.1.2. CLI を使用した Kubernetes NMState Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc)
を使用して、Kubernetes NMState Operator をインストールできます。インストールが完了すると、Operator はすべてのクラスターノードに NMState State Controller をデーモンセットとしてデプロイできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
nmstate
Operator namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstate
Operator にサブスクライブします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstate
Operator デプロイメントのClusterServiceVersion
(CSV) ステータスがSucceeded
であることを確認します。oc get clusterserviceversion -n openshift-nmstate \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get clusterserviceversion -n openshift-nmstate \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstate
Operator のインスタンスを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow DNS 接続の問題が原因でクラスターで DNS ヘルスチェックプローブに問題がある場合は、次の DNS ホスト名設定を
NMState
CRD に追加して、これらの問題を解決できるヘルスチェックを組み込むことができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、DNS ホスト名の設定をクラスターネットワークに適用します。
<filename>
は、CRD ファイルの名前に置き換えます。$ oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、NMState Operator のすべての Pod のステータスが
Running
であることを確認します。oc get pod -n openshift-nmstate
$ oc get pod -n openshift-nmstate
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
マニフェストの例を示しています。
NodeNetworkConfigurationPolicy
マニフェストはメトリクスを公開し、Cluster Monitoring Operator (CMO) が利用できるようにします。次の例は、公開されたメトリクスの一部を示しています。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者として Web コンソールにログインし、Kubernetes NMState Operator をインストールしている。
- 開発者として、またはメトリクスで表示しているプロジェクトの表示権限を持つユーザーとしてクラスターへのアクセスがある。
- ユーザー定義プロジェクトのモニタリングが有効化されている。
- ユーザー定義プロジェクトにサービスをデプロイしている。
-
NodeNetworkConfigurationPolicy
マニフェストを作成し、クラスターに適用している。
OpenShift Container Platform 4.19 以降、Web コンソールのパースペクティブが統合されました。Developer パースペクティブは、デフォルトでは有効になっていません。
すべてのユーザーは、OpenShift Container Platform Web コンソールのすべての機能を操作できます。ただし、クラスターの所有者でない場合は、特定の機能にアクセスする権限をクラスターの所有者に要求する必要がある場合があります。
引き続き Developer パースペクティブを有効にできます。Web コンソールの Getting Started ペインでは、コンソールツアーの実行、クラスター設定に関する情報の検索、Developer パースペクティブを有効にするためのクイックスタートの表示、リンク先を表示して新機能の確認などを行えます。
手順
OpenShift Container Platform Web コンソールの Developer パースペクティブからメトリクスを表示する場合は、次のタスクを実行します。
- Observe をクリックします。
-
特定のプロジェクトのメトリクスを表示するには、Project: リストでプロジェクトを選択します。たとえば、
openshift-nmstate
です。 - Metrics タブをクリックします。
プロット上のメトリクスを視覚化するには、Select query リストからクエリーを選択するか、Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。
注記開発者ロールでは 1 度に 1 つのクエリーのみ実行できます。
管理者として OpenShift Container Platform Web コンソールでメトリクスを表示する場合は、以下のタスクを実行します。
- Observe → Metrics をクリックします。
-
Expression フィールドに
kubernetes_nmstate_features_applied
と入力します。 - Add query をクリックし、Run queries をクリックします。
視覚化されたメトリクスを調べるには、次のいずれかのタスクを実行します。
プロットを拡大して時間範囲を変更するには、次のいずれかのタスクを実行します。
- 時間範囲を視覚的に選択するには、プロットをクリックして水平にドラッグします。
- 時間範囲を選択するには、コンソールの左上にあるメニューを使用します。
- 時間の範囲をリセットするには、Reset zoom を選択します。
- 特定の時点におけるすべてのクエリーの出力を表示するには、その時点でプロット上にマウスカーソルを置きます。クエリー出力がポップアップボックスに表示されます。
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
権限を持つユーザーとしてログインしている。
手順
次のコマンドを実行して、
Subcription
リソースに対する Kubernetes NMState Operator のサブスクリプションを解除します。oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
$ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes NMState Operator に関連付けられている
ClusterServiceVersion
(CSV) リソースを見つけます。oc get --namespace openshift-nmstate clusterserviceversion
$ oc get --namespace openshift-nmstate clusterserviceversion
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CSV リソースをリストする出力例
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.19.0 Kubernetes NMState Operator 4.19.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.19.0 Kubernetes NMState Operator 4.19.0 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CSV リソースを削除します。ファイルを削除すると、OLM は Operator 用に作成した
RBAC
などの特定リソースを削除します。oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.19.0
$ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.19.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
nmstate
CR と関連するDeployment
リソースを削除します。oc -n openshift-nmstate delete nmstate nmstate
$ oc -n openshift-nmstate delete nmstate nmstate
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete --all deployments --namespace=openshift-nmstate
$ oc delete --all deployments --namespace=openshift-nmstate
Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstate
CR を削除した後、console.operator.openshift.io/cluster
CR からnmstate-console-plugin
コンソールプラグイン名を削除します。次のコマンドを実行して、有効なプラグインのリスト内に存在する
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')
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 Copied! Toggle word wrap Toggle overflow 次のパッチコマンドを実行して、
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\"}]"
$ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
INDEX
は補助変数です。この変数には別の名前を指定できます。
次のコマンドを実行して、
nmstates.nmstate.io
などのカスタムリソース定義 (CRD) をすべて削除します。oc delete crd nmstates.nmstate.io
$ oc delete crd nmstates.nmstate.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationenactments.nmstate.io
$ oc delete crd nodenetworkconfigurationenactments.nmstate.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkstates.nmstate.io
$ oc delete crd nodenetworkstates.nmstate.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationpolicies.nmstate.io
$ oc delete crd nodenetworkconfigurationpolicies.nmstate.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace を削除します。
oc delete namespace kubernetes-nmstate
$ oc delete namespace kubernetes-nmstate
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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
remote error: tls: protocol version not supported
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在、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-4052、OCPBUGS-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
(LoadBalancer
やClusterIP
ではない) になるように 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 サービスリソースをサポートします。
手順
OperatorHub からオンデマンドで AWS Load Balancer Operator をデプロイするには、次のコマンドを実行して
Subscription
オブジェクトを作成します。oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'
$ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、インストールプランのステータスが
Complete
になっているか確認します。oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
$ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
aws-load-balancer-operator-controller-manager
デプロイメントのステータスを表示します。oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
$ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
リソース設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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}"
$ oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターの OpenID Connect (OIDC) の DNS 情報がわかっている。この情報を表示するには、CLI で次のコマンドを入力します。
oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}"
$ oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- OIDC DNS の例は
https://rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f
です。
-
AWS Web コンソールにログインし、IAM → Access management → Identity 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 ロールは次の方法で作成できます。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) と定義済みのCredentialsRequest
オブジェクトを使用します。 - AWS CLI と事前定義された AWS マニフェストを使用します。
環境が 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
バイナリーを抽出して準備する必要があります。
手順
次のコマンドを実行して、
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
$ 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 Copied! Toggle word wrap Toggle overflow ccoctl
ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>
$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created 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
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 Copied! Toggle word wrap Toggle overflow - 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
) にアクセスできる。
手順
次のコマンドを実行して、アイデンティティープロバイダーを使用して信頼ポリシーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
です。
次のコマンドを実行して、生成された信頼ポリシーを使用して IAM ロールを作成します。
aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
$ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ROLE arn:aws:iam::<aws_account_number>:role/albo-operator 2023-08-02T12:13:22Z 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>
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 Copied! Toggle word wrap Toggle overflow - 1
- AWS Load Balancer Operator 用に作成された AWS IAM ロールの ARN (例:
arn:aws:iam::777777777777:role/albo-operator
) をメモします。
次のコマンドを実行して、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
$ 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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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
$ 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 Copied! Toggle word wrap Toggle overflow
2.3.3. AWS Load Balancer Operator 用の ARN ロールの設定 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator 用の Amazon Resource Name (ARN) ロールを環境変数として設定できます。CLI を使用して ARN ロールを設定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、
aws-load-balancer-operator
プロジェクトを作成します。oc new-project aws-load-balancer-operator
$ oc new-project aws-load-balancer-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 ロールは次の方法で作成できます。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) と定義済みのCredentialsRequest
オブジェクトを使用します。 - AWS CLI と事前定義された AWS マニフェストを使用します。
環境が ccoctl
コマンドをサポートしていない場合は、AWS CLI を使用します。
2.3.4.1. Cloud Credential Operator ユーティリティーを使用してコントローラー用の AWS IAM ロールを作成する リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator ユーティリティー (ccoctl
) を使用して、AWS Load Balancer Controller 用の AWS IAM ロールを作成できます。AWS IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。
前提条件
-
ccoctl
バイナリーを抽出して準備する必要があります。
手順
次のコマンドを実行して、
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
$ 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 Copied! Toggle word wrap Toggle overflow ccoctl
ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>
$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credentials_requests_dir> \ --identity-provider-arn <oidc_arn>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created 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
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 Copied! Toggle word wrap Toggle overflow - 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
) にアクセスできる。
手順
次のコマンドを実行して、アイデンティティプロバイダーを使用して信頼ポリシーファイルを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
です。
次のコマンドを実行して、生成された信頼ポリシーを使用して AWS IAM ロールを作成します。
aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
$ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ROLE arn:aws:iam::<aws_account_number>:role/albo-controller 2023-08-02T12:13:22Z 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>
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 Copied! Toggle word wrap Toggle overflow - 1
- AWS Load Balancer Controller の AWS IAM ロールの ARN (例:
arn:aws:iam::777777777777:role/albo-controller
) をメモします。
次のコマンドを実行して、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
$ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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
$ 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 Copied! Toggle word wrap Toggle overflow AWSLoadBalancerController
オブジェクトを定義する YAML ファイルを作成します。sample-aws-lb-manual-creds.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 を準備する」を参照してください。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub に移動します。
- AWS Load Balancer Operator を選択します。Filter by keyword テキストボックスを使用するか、フィルターリストを使用して、Operator のリストから AWS Load Balancer Operator を検索できます。
-
aws-load-balancer-operator
namespace を選択します。 Install Operator ページで、次のオプションを選択します。
- Update the channel で stable-v1 を選択します。
- Installation mode で All namespaces on the cluster (default) を選択します。
-
Installed Namespace で
aws-load-balancer-operator
を選択します。aws-load-balancer-operator
namespace が存在しない場合は、Operator のインストール中に作成されます。 - Update approval で Automatic または Manual を選択します。デフォルトでは、Update approval は Automatic に設定されています。Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように更新要求を手動で承認する必要があります。
- Install をクリックします。
検証
- AWS Load Balancer Operator で、インストール済み Operator ダッシュボードの Status が Succeeded と表示されることを確認します。
2.4.2. CLI を使用した AWS Load Balancer Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して AWS Load Balancer Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。 - クラスターのプラットフォームタイプとクラウドプロバイダーが AWS に設定されている。
-
OpenShift CLI (
oc
) にログイン済みである。
手順
Namespace
オブジェクトを作成します。Namespace
オブジェクトを定義する YAML ファイルを作成します。namespace.yaml
ファイルの例apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Namespace
オブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OperatorGroup
オブジェクトを作成します。OperatorGroup
オブジェクトを定義する YAML ファイルを作成します。operatorgroup.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Subscription
オブジェクトを作成します。Subscription
オブジェクトを定義する YAML ファイルを作成します。subscription.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サブスクリプションからインストールプランの名前を取得します。
oc -n aws-load-balancer-operator \ get subscription aws-load-balancer-operator \ --template='{{.status.installplan.name}}{{"\n"}}'
$ oc -n aws-load-balancer-operator \ get subscription aws-load-balancer-operator \ --template='{{.status.installplan.name}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストールプランのステータスを確認します。
oc -n aws-load-balancer-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'
$ oc -n aws-load-balancer-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は
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
) にアクセスできる。
手順
AWSLoadBalancerController
オブジェクトを定義する YAML ファイルを作成します。sample-aws-lb.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
アノテーションを有効にします。
次のコマンドを実行して、
AWSLoadBalancerController
オブジェクトを作成します。oc create -f sample-aws-lb.yaml
$ oc create -f sample-aws-lb.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Deployment
リソースを定義する YAML ファイルを作成します。sample-aws-lb.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Service
リソースを定義する YAML ファイルを作成します。service-albo.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress
リソースを定義する YAML ファイルを作成します。Ingress-albo.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、
Ingress
リソースのステータスをHOST
変数に保存します。HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
$ HOST=$(oc get ingress -n echoserver echoserver --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Ingress
リソースのステータスを確認します。curl $HOST
$ curl $HOST
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. AWS Load Balancer Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
2.5.1. クラスター全体のプロキシーの認証局を信頼する リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator でクラスター全体のプロキシーを設定できます。クラスター全体のプロキシーを設定すると、Operator Lifecycle Manager (OLM) が、HTTP_PROXY
、HTTPS_PROXY
、NO_PROXY
などの環境変数を使用して、Operator のすべてのデプロイメントを自動的に更新します。これらの変数は、AWS Load Balancer Operator によってマネージドコントローラーに入力されます。
次のコマンドを実行して、
aws-load-balancer-operator
namespace に認証局 (CA) バンドルを含める config map を作成します。oc -n aws-load-balancer-operator create configmap trusted-ca
$ oc -n aws-load-balancer-operator create configmap trusted-ca
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 信頼できる 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
$ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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"}]}}}'
$ 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 Copied! Toggle word wrap Toggle overflow 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"
$ 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 Copied! Toggle word wrap Toggle overflow 出力例
-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt trusted-ca
-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 Copied! Toggle word wrap Toggle overflow オプション: config-map が変更されるたびに、次のコマンドを実行して、AWS Load Balancer Operator のデプロイを再開します。
oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
$ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.2. AWS Load Balancer への TLS Termination の追加 リンクのコピーリンクがクリップボードにコピーされました!
ドメインのトラフィックをサービスの Pod にルーティングし、AWS Load Balancer に TLS Termination を追加できます。
前提条件
-
OpenShift CLI (
oc
) にアクセスできる。
手順
AWSLoadBalancerController
リソースを定義する YAML ファイルを作成します。add-tls-termination-albc.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress クラス名を定義します。クラスター内に Ingress クラスが存在しない場合は、AWS Load Balancer Controller によって作成されます。
spec.controller
がingress.k8s.aws/alb
に設定されている場合、AWS Load Balancer Controller は追加の Ingress クラス値を調整します。
Ingress
リソースを定義する YAML ファイルを作成します。add-tls-termination-ingress.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.3. 1 つの AWS ロードバランサーを介して複数の Ingress リソースを作成する リンクのコピーリンクがクリップボードにコピーされました!
1 つの AWS Load Balancer を介して、1 つのドメインに含まれるさまざまなサービスに、複数の Ingress リソースを使用してトラフィックをルーティングできます。各 Ingress リソースは、ドメインの異なるエンドポイントを提供します。
前提条件
-
OpenShift CLI (
oc
) にアクセスできる。
手順
次のように、
IngressClassParams
リソースの YAML ファイル (例:sample-single-lb-params.yaml
) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
IngressClassParams
リソースを作成します。oc create -f sample-single-lb-params.yaml
$ oc create -f sample-single-lb-params.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように、
IngressClass
リソースの YAML ファイル (例:sample-single-lb-class.yaml
) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して
IngressClass
リソースを作成します。oc create -f sample-single-lb-class.yaml
$ oc create -f sample-single-lb-class.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように、
AWSLoadBalancerController
リソース YAML ファイル (例:sample-single-lb.yaml
) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
IngressClass
リソースの名前を定義します。
次のコマンドを実行して、
AWSLoadBalancerController
リソースを作成します。oc create -f sample-single-lb.yaml
$ oc create -f sample-single-lb.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように、
Ingress
リソースの YAML ファイル (例:sample-multiple-ingress.yaml
) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress 名を指定します。
- 2
- インターネットにアクセスするためにパブリックサブネットにプロビジョニングするロードバランサーを示します。
- 3
- ロードバランサーで要求を受信したときに、複数の Ingress リソースからのルールをマッチする順序を指定します。
- 4
- ロードバランサーがサービスに到達するために OpenShift Container Platform ノードをターゲットにすることを示します。
- 5
- この Ingress に属する Ingress クラスを指定します。
- 6
- 要求のルーティングに使用するドメイン名を定義します。
- 7
- サービスにルーティングする必要があるパスを定義します。
- 8
Ingress
リソースで設定されたエンドポイントを提供するサービス名を定義します。- 9
- エンドポイントにサービスを提供するサービスのポートを定義します。
次のコマンドを実行して
Ingress
リソースを作成します。oc create -f sample-multiple-ingress.yaml
$ oc create -f sample-multiple-ingress.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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
) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
bpfman
namespace を作成するには、次のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
CR を作成するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow eBPF Manager Operator にサブスクライブします。
eBPF Manager Operator の
Subscription
CR を作成するには、次のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get ip -n bpfman
$ oc get ip -n bpfman
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CSV APPROVAL APPROVED install-ppjxl security-profiles-operator.v0.8.5 Automatic true
NAME CSV APPROVAL APPROVED install-ppjxl security-profiles-operator.v0.8.5 Automatic true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator のバージョンを確認するには、次のコマンドを入力します。
oc get csv -n bpfman
$ oc get csv -n bpfman
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE bpfman-operator.v0.5.0 eBPF Manager Operator 0.5.0 bpfman-operator.v0.4.2 Succeeded
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 Copied! Toggle word wrap Toggle overflow
3.2.2. Web コンソールを使用して eBPF Manager Operator をインストールする リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して eBPF Manager Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
eBPF Manager Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから eBPF Manager Operator を選択し、コミュニティー Operator を表示する ように求められたら、Continue をクリックします。
- Install をクリックします。
- Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
- Install をクリックします。
eBPF Manager Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに移動します。
eBPF Manager Operator が、Status が InstallSucceeded で openshift-ingress-node-firewall プロジェクトにリストされていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator の Status が InstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
bpfman
プロジェクト内の Pod のログを確認します。
3.2.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
3.3. eBPF プログラムのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、eBPF Manager Operator を使用してコンテナー化された eBPF アプリケーションをデプロイできます。
この手順でデプロイされるサンプル eBPF プログラムの場合、サンプルマニフェストは次のことを実行します。
まず、Namespace
、ServiceAccount
、ClusterRoleBinding
などの基本的な 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 をインストールしている。
手順
マニフェストをダウンロードするには、次のコマンドを入力します。
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
$ 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 Copied! Toggle word wrap Toggle overflow サンプル eBPF アプリケーションをデプロイするには、次のコマンドを実行します。
oc create -f go-xdp-counter-install-selinux.yaml
$ oc create -f go-xdp-counter-install-selinux.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow eBPF サンプルアプリケーションが正常にデプロイされたことを確認するには、次のコマンドを実行します。
oc get all -o wide -n go-xdp-counter
$ oc get all -o wide -n go-xdp-counter
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サンプル XDP プログラムが実行していることを確認するには、次のコマンドを実行します。
oc get xdpprogram go-xdp-counter-example
$ oc get xdpprogram go-xdp-counter-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME BPFFUNCTIONNAME NODESELECTOR STATUS go-xdp-counter-example xdp_stats {} ReconcileSuccess
NAME BPFFUNCTIONNAME NODESELECTOR STATUS go-xdp-counter-example xdp_stats {} ReconcileSuccess
Copy to Clipboard Copied! Toggle word wrap Toggle overflow XDP プログラムがデータを収集していることを確認するには、次のコマンドを実行します。
oc logs <pod_name> -n go-xdp-counter
$ oc logs <pod_name> -n go-xdp-counter
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <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 ...
2024/08/13 15:20:06 15016 packets received 2024/08/13 15:20:06 93581579 bytes received ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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. 新機能 リンクのコピーリンクがクリップボードにコピーされました!
- External DNS Operator が AWS 共有 VPC をサポートするようになりました。詳細は、共有 VPC を使用して別の AWS アカウントに DNS レコードを作成する を参照してください。
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
オブジェクトが作成されます。
次のコマンドを実行して、
install-zcvlr
などのインストールプランの名前を確認します。oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
$ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、インストールプランのステータスが
Complete
になっているか確認します。oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
$ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
external-dns-operator
デプロイメントのステータスを表示します。oc get -n external-dns-operator deployment/external-dns-operator
$ oc get -n external-dns-operator deployment/external-dns-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.2. External DNS Operator のログの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc logs
コマンドを使用して、External DNS Operator のログを表示できます。
手順
次のコマンドを実行して、External DNS Operator のログを表示します。
oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 レコードのドメイン名には、次の制限があります。
レコードの種類 | 文字数 |
---|---|
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"
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"
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 をインストールできます。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- External DNS Operator をクリックします。Filter by keyword のテキストボックスまたはフィルターリストを使用して、Operator のリストから External DNS Operator を検索できます。
-
external-dns-operator
namespace を選択します。 - External DNS Operator ページで Install をクリックします。
Install Operator ページで、次のオプションを選択していることを確認してください。
- Update the channel で stable-v1.0 を選択します。
- Installation mode で A specific name on the cluster を選択します。
-
Installed namespace で
external-dns-operator
を選択します。namespaceexternal-dns-operator
が存在しない場合は、Operator のインストール中に作成されます。 - Approval Strategy で Automatic または Manual を選択します。Approval Strategy はデフォルトで Automatic に設定されています。
- Install をクリックします。
Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
検証
Installed Operators ダッシュボードで、External DNS Operator の Status が Succeeded と表示されることを確認します。
4.3.2. CLI を使用した External DNS Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して External DNS Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。 -
OpenShift CLI (
oc
) にログイン済みである。
手順
Namespace
オブジェクトを作成します。Namespace
オブジェクトを定義する YAML ファイルを作成します。namespace.yaml
ファイルの例apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Namespace
オブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OperatorGroup
オブジェクトを作成します。OperatorGroup
オブジェクトを定義する YAML ファイルを作成します。operatorgroup.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Subscription
オブジェクトを作成します。Subscription
オブジェクトを定義する YAML ファイルを作成します。subscription.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、サブスクリプションからインストールプランの名前を取得します。
oc -n external-dns-operator \ get subscription external-dns-operator \ --template='{{.status.installplan.name}}{{"\n"}}'
$ oc -n external-dns-operator \ get subscription external-dns-operator \ --template='{{.status.installplan.name}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、インストールプランのステータスが
Complete
であることを確認します。oc -n external-dns-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'
$ oc -n external-dns-operator \ get ip <install_plan_name> \ --template='{{.status.phase}}{{"\n"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
external-dns-operator
Pod のステータスがRunning
であることを確認します。oc -n external-dns-operator get pod
$ oc -n external-dns-operator get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11m
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サブスクリプションのカタログソースが
redhat-operators
であることを確認します。oc -n external-dns-operator get subscription
$ oc -n external-dns-operator get subscription
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
external-dns-operator
のバージョンを確認します。oc -n external-dns-operator get csv
$ oc -n external-dns-operator get csv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. External DNS Operator の設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator には、次の設定パラメーターがあります。
4.4.1. External DNS Operator の設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator には、次の設定パラメーターがあります。
パラメーター | 説明 |
---|---|
| クラウドプロバイダーのタイプを有効にします。 |
|
ドメインごとに DNS ゾーンを指定できます。ゾーンを指定しない場合、 zones: - "myzoneid"
|
|
ドメインごとに AWS ゾーンを指定できます。ドメインを指定しない場合、 |
|
DNS レコードのソース (
|
4.5. AWS での DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、AWS および AWS GovCloud で DNS レコードを作成できます。
4.5.1. Red Hat External DNS Operator を使用した AWS のパブリックホストゾーンへの DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat External DNS Operator を使用して、AWS のパブリックホストゾーンに DNS レコードを作成できます。同じ手順を使用して、AWS GovCloud のホストゾーンに DNS レコードを作成できます。
手順
次のコマンドを実行して、
system:admin
などのユーザープロファイルを確認します。ユーザープロファイルには、kube-system
namespace へのアクセス権が必要です。認証情報がない場合は、次のコマンドを実行して、kube-system
namespace から認証情報を取得し、クラウドプロバイダークライアントを使用できます。oc whoami
$ oc whoami
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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)
$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_access_key_id}} | base64 -d)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_secret_access_key}} | base64 -d)
$ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_secret_access_key}} | base64 -d)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを取得して、ドメインを確認します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow DNS ゾーンのリストを取得し、以前にクエリーしたルートのドメインに対応する DNS ゾーンを見つけます。
aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow route
ソースのExternalDNS
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 外部 DNS リソースの名前を定義します。
- 2
- デフォルトでは、すべてのホストゾーンがターゲット候補として選択されます。必要なホストゾーンを追加できます。
- 3
- ターゲットゾーンのドメインは、(正規表現の一致とは対照的に) 完全一致である必要があります。
- 4
- 更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
- 5
AWS Route53DNS
プロバイダーを定義します。- 6
- DNS レコードのソースのオプションを定義します。
- 7
- 以前に指定された DNS プロバイダーで作成される DNS レコードのソースとして OpenShift
route
リソースを定義します。 - 8
- ソースが
OpenShiftRoute
の場合に、OpenShift Ingress Controller 名を指定できます。External DNS Operator は、CNAME レコードの作成時に、そのルーターの正規ホスト名をターゲットとして選択します。
次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。
aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 がインストールされている。
手順
次のコマンドを実行して、アカウント B からアカウント A の Route 53 ホストゾーンにアクセスできるように作成した IAM ロールのロール ARN を取得します。
aws --profile account-a iam get-role --role-name user-rol1 | head -1
$ aws --profile account-a iam get-role --role-name user-rol1 | head -1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、アカウント A の認証情報で使用するプライベートホストゾーンを特定します。
aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ExternalDNS
オブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アカウント A に DNS レコードを作成するには、ロール ARN を指定します。
次のコマンドを使用して、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
$ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 にアクセスできる。
手順
クラウドプロバイダークライアントを使用するために、次のコマンドを実行して
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)
$ 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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Azure にログインします。
az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"
$ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、DNS ゾーンのリストを取得します。
az network dns zone list --resource-group "${RESOURCE_GROUP}"
$ az network dns zone list --resource-group "${RESOURCE_GROUP}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-azure.yaml
) を作成します。external-dns-sample-azure.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。
az network dns record-set list -g "${RESOURCE_GROUP}" -z test.azure.example.com | grep console
$ az network dns record-set list -g "${RESOURCE_GROUP}" -z test.azure.example.com | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記プライベート 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 レコードを作成できます。
前提条件
- 管理者権限を持っている。
手順
次のコマンドを実行して、
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
$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Google の認証情報をエクスポートします。
export GOOGLE_CREDENTIALS=decoded-gcloud.json
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、アカウントをアクティブ化します。
gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
$ gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、プロジェクトを設定します。
gcloud config set project <project_id as per decoded-gcloud.json>
$ gcloud config set project <project_id as per decoded-gcloud.json>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
qe-cvs4g-private-zone test.gcp.example.com
などのマネージドゾーンのリストを取得します。gcloud dns managed-zones list | grep test.gcp.example.com
$ gcloud dns managed-zones list | grep test.gcp.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-gcp.yaml
) を作成します。external-dns-sample-gcp.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 外部 DNS 名を指定します。
- 2
- デフォルトでは、すべてのホストされたゾーンがターゲット候補として選択されます。ホストされたゾーンを含めることができます。
- 3
- ターゲットのドメインは、
name
キーで定義された文字列と一致する必要があります。 - 4
- 更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
- 5
- プロバイダータイプを定義します。
- 6
- DNS レコードのソースのオプションを定義できます。
- 7
- ソースタイプが
OpenShiftRoute
の場合、OpenShift Ingress Controller 名を渡すことができます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。 - 8
route
リソースを GCP DNS レコードのソースとして定義します。
次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。
gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 にアクセスできる。
手順
次のコマンドを実行して、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>
$ 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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-infoblox.yaml
) を作成します。external-dns-sample-infoblox.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Infoblox に
ExternalDNS
リソースを作成します。oc create -f external-dns-sample-infoblox.yaml
$ oc create -f external-dns-sample-infoblox.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Infoblox UI から、
console
ルート用に作成された DNS レコードを確認します。- Data Management → DNS → Zones をクリックします。
- ゾーン名を選択します。
4.9. External DNS Operator でクラスター全体のプロキシーを設定する リンクのコピーリンクがクリップボードにコピーされました!
クラスター全体のプロキシーを設定した後、Operator Lifecycle Manager (OLM) はデプロイされたすべての Operator に対して、HTTP_PROXY
、HTTPS_PROXY
、および NO_PROXY
環境変数の新しい内容の自動更新をトリガーします。
4.9.1. クラスター全体のプロキシーの認証局を信頼する リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を設定して、クラスター全体のプロキシーの認証局を信頼できます。
手順
次のコマンドを実行して、
external-dns-operator
namespace に CA バンドルを含める config map を作成します。oc -n external-dns-operator create configmap trusted-ca
$ oc -n external-dns-operator create configmap trusted-ca
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 信頼できる 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
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、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"}]}}]'
$ 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 Copied! Toggle word wrap Toggle overflow
検証
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
$ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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-example
、doc-example-reserved
、doc-example-ipv6
などの名前を使用します。MetalLBcontroller
は、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
"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 モードの制限 リンクのコピーリンクがクリップボードにコピーされました!
5.1.7.3.1. ノードに障害が発生すると、アクティブなすべての接続が切断される可能性があります リンクのコピーリンクがクリップボードにコピーされました!
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
権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、
metallb
と入力して MetalLB Operator を見つけます。また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
- Install Operator ページで、デフォルトを受け入れて Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
openshift-operators
の namespace 内に設置されていることと、その状態がSucceeded
となっていることを確認してください。
Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。
-
Operators → Installed Operators ページに移動し、
Status
列でエラーまたは失敗の有無を確認します。 -
Workloads → Pods ページにナビゲートし、問題を報告している
openshift-operators
プロジェクトの Pod のログを確認します。
-
Operators → Installed Operators ページに移動し、
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
権限を持つユーザーとしてログインしている。
手順
次のコマンドを入力して、MetalLB Operator の namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace に Operator グループのカスタムリソースを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator グループが namespace にインストールされていることを確認します。
oc get operatorgroup -n metallb-system
$ oc get operatorgroup -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE metallb-operator 14m
NAME AGE metallb-operator 14m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイルを保存します (例:metallb-sub.yaml
)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
redhat-operators
値を指定する必要があります。
Subscription
CR を作成するには、次のコマンドを実行します。oc create -f metallb-sub.yaml
$ oc create -f metallb-sub.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。
oc label ns metallb-system "openshift.io/cluster-monitoring=true"
$ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
この検証手順は、MetalLB Operator が metallb-system
namespace にインストールされていることを前提としています。
インストール計画が namespace にあることを確認します。
oc get installplan -n metallb-system
$ oc get installplan -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.19.0-nnnnnnnnnnnn Automatic true
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.19.0-nnnnnnnnnnnn Automatic true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Operator のインストールには数秒かかる場合があります。
Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に
Succeeded
と表示されていることを確認します。oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get clusterserviceversion -n metallb-system \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.3. クラスターでの MetalLB の起動 リンクのコピーリンクがクリップボードにコピーされました!
Operator のインストール後に、MetalLB カスタムリソースの単一のインスタンスを設定する必要があります。カスタムリソースの設定後、Operator はクラスターで MetalLB を起動します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
手順
この手順は、MetalLB Operator が metallb-system
namespace にインストールされていることを前提としています。Web コンソールを使用してインストールした場合は、namespace の代わりに openshift-operators
を使用してください。
MetalLB カスタムリソースの単一のインスタンスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
MetalLB コントローラーのデプロイメントと、MetalLB スピーカーのデーモンセットが実行していることを確認します。
コントローラーのデプロイメントが稼働していることを検証します。
oc get deployment -n metallb-system controller
$ oc get deployment -n metallb-system controller
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11m
NAME READY UP-TO-DATE AVAILABLE AGE controller 1/1 1 1 11m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow スピーカーに設定されているデーモンが実行されていることを検証します。
oc get daemonset -n metallb-system speaker
$ oc get daemonset -n metallb-system speaker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE speaker 6 6 6 6 6 kubernetes.io/os=linux 18m
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 Copied! Toggle word wrap Toggle overflow この出力例は、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 をワーカーノードに制限する設定例
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 を開始している。
手順
myPriorityClass.yaml
などのPriorityClass
カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority
という名前のPriorityClass
を、値1000000
で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PriorityClass
カスタムリソース設定を適用します。oc apply -f myPriorityClass.yaml
$ oc apply -f myPriorityClass.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MetalLBPodConfig.yaml
などのMetalLB
カスタムリソースを作成して、priorityClassName
とpodAffinity
の値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- MetalLB コントローラー Pod の優先クラスを指定します。この場合、
high-priority
に設定されます。 - 2
- Pod アフィニティールールを設定していることを指定します。これらのルールは、他の Pod またはノードに関連して Pod がどのようにスケジュールされるかを決定します。この設定は、
app: metallb
ラベルを持つ Pod を同じホスト名を共有するノードにスケジュールするようにスケジューラーに指示します。これは、MetalLB 関連の Pod を同じノード上に配置するのに役立ち、これらの Pod 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。
MetalLB
カスタムリソース設定を適用します。oc apply -f MetalLBPodConfig.yaml
$ oc apply -f MetalLBPodConfig.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
metallb-system
namespace の Pod に割り当てた優先クラスを表示するには、次のコマンドを実行します。oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示します。
oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.4.3. MetalLB デプロイメントでの Pod CPU 制限の設定 リンクのコピーリンクがクリップボードにコピーされました!
オプションで、MetalLB
カスタムリソースを設定することで、Pod の CPU 制限を controller
Pod と speaker
Pod に割り当てることができます。controller
Pod または speaker
Pod の CPU 制限を定義すると、ノード上のコンピュートリソースを管理するのに役立ちます。これにより、ノード上のすべての Pod に、ワークロードとクラスターのハウスキーピングを管理するために必要なコンピューティングリソースが確保されます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - MetalLB Operator がインストールされている。
手順
CPULimits.yaml
などのMetalLB
カスタムリソースファイルを作成し、コントローラー
およびspeaker
Pod のcpu
値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MetalLB
カスタムリソース設定を適用します。oc apply -f CPULimits.yaml
$ oc apply -f CPULimits.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Pod のコンピューティングリソースを表示するには、次のコマンドを実行し、
<pod_name>
をターゲット Pod に置き換えます。oc describe pod <pod_name>
$ oc describe pod <pod_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
ロールを持つユーザーとしてクラスターにアクセスします。
手順
次のコマンドを入力して、
metallb-system
namespace 内のmetallb-operator
サブスクリプションの YAML 定義を取得します。oc -n metallb-system get subscription metallb-operator -o yaml
$ oc -n metallb-system get subscription metallb-operator -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow installPlanApproval
パラメーターをManual
に設定して、Subscription
CR を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、最新の OpenShift Container Platform 4.19 バージョンの MetalLB Operator を見つけます。
oc -n metallb-system get csv
$ oc -n metallb-system get csv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、namespace に存在するインストールプランを確認します。
oc -n metallb-system get installplan
$ oc -n metallb-system get installplan
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 手動インストールプランとして 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
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 Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、namespace に存在するインストールプランを編集します。
<name_of_installplan>
は、install-tsz2g
などのインストールプランの名前に置き換えてください。oc edit installplan <name_of_installplan> -n metallb-system
$ oc edit installplan <name_of_installplan> -n metallb-system
Copy to Clipboard Copied! Toggle word wrap Toggle overflow エディターでインストールプランを開いた状態で、
spec.approval
パラメーターをManual
に設定し、spec.approved
パラメーターをtrue
に設定します。注記インストールプランを編集すると、アップグレード操作が開始します。アップグレード操作中に
oc -n metallb-system get csv
コマンドを入力すると、出力にReplacing
またはPending
ステータスが表示される場合があります。
検証
Operator がアップグレードされたことを確認するには、次のコマンドを入力し、、Operator に対して出力に
Succeeded
と表示されていることを確認します。oc -n metallb-system get csv
$ oc -n metallb-system get csv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
としてデプロイされます。
以下のコマンドを実行して Deployment のステータスを表示します。
oc get -n openshift-network-operator deployment/network-operator
$ oc get -n openshift-network-operator deployment/network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
oc get clusteroperator/network
$ oc get clusteroperator/network
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.16.1 True False False 50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.16.1 True False False 50m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のフィールドは、Operator のステータス (
AVAILABLE
、PROGRESSING
、およびDEGRADED
) に関する情報を提供します。AVAILABLE
フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合にTrue
になります。
6.2. クラスターネットワーク設定の表示 リンクのコピーリンクがクリップボードにコピーされました!
すべての新規 OpenShift Container Platform インストールには、cluster
という名前の network.config
オブジェクトがあります。
手順
oc describe
コマンドを使用して、クラスターネットワーク設定を表示します。oc describe network.config/cluster
$ oc describe network.config/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. Cluster Network Operator のステータス表示 リンクのコピーリンクがクリップボードにコピーされました!
oc describe
コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。
手順
以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
oc describe clusteroperators/network
$ oc describe clusteroperators/network
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. IP 転送をグローバルに有効にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.14 以降では、OVN-Kubernetes ベースのクラスターデプロイメントでグローバル IP アドレス転送が無効になります。これは、ルーターとして機能するノードによる、クラスター管理者にとって望ましくない影響を防ぐためです。ただし、トラフィックの転送が必要な場合には、すべての IP トラフィックの転送を許可する新しい設定パラメーター ipForwarding
を利用できます。
OVN-Kubernetes 管理インターフェイス上の全トラフィックの IP 転送を再度有効にするには、次の手順に従って、Cluster Network Operator の gatewayConfig.ipForwarding
仕様を Global
に設定します。
手順
次のコマンドを実行して、既存のネットワーク設定をバックアップします。
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、既存のネットワーク設定を変更します。
oc edit network.operator cluster
$ oc edit network.operator cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、
spec
の下に次のブロックを追加または更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存してから閉じます。
変更を適用した後、OpenShift Cluster Network Operator (CNO) によってクラスター全体に更新が適用されます。次のコマンドを使用して進行状況を監視できます。
oc get clusteroperators network
$ oc get clusteroperators network
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最終的に、ステータスに
Available
、Progressing=False
、Degraded=False
と報告されるはずです。または、次のコマンドを実行して、IP 転送をグローバルに有効にすることもできます。
oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この変更を元に戻す必要がある場合は、このパラメーターのもう 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
$ oc logs --namespace=openshift-network-operator deployment/network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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) のフィールドは以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 |
|
| サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。 spec: serviceNetwork: - 172.30.0.0/14
この値は読み取り専用であり、クラスターのインストール時に |
|
| クラスターネットワークのネットワークプラグインを設定します。 |
|
| このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。 |
複数のネットワークにオブジェクトをデプロイする必要があるクラスターの場合は、install-config.yaml
ファイルで定義されている各ネットワークタイプの clusterNetwork.hostPrefix
パラメーターに、必ず同じ値を指定してください。clusterNetwork.hostPrefix
パラメーターにそれぞれ異なる値を設定すると、OVN-Kubernetes ネットワークプラグインに影響が及び、異なるノード間のオブジェクトトラフィックをプラグインが効果的にルーティングできなくなる可能性があります。
defaultNetwork オブジェクト設定
defaultNetwork
オブジェクトの値は、以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。 |
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OVN-Kubernetes ネットワークプラグインの設定
次の表では、OVN-Kubernetes ネットワークプラグインの設定フィールドを説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。通常、この値は自動的に設定されます。 |
|
| Geneve オーバーレイネットワークの UDP ポート。 |
|
| クラスターの IPsec モードを示すオブジェクト。 |
|
| IPv4 設定の設定オブジェクトを指定します。 |
|
| IPv6 設定の設定オブジェクトを指定します。 |
|
| ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。 |
|
|
オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は 注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。 |
フィールド | 型 | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
| string |
既存のネットワークインフラストラクチャーが
デフォルト値は |
フィールド | 型 | 説明 |
---|---|---|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
| integer | 保持されるログファイルの最大数。 |
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
| string |
RFC5424 で定義される |
フィールド | 型 | 説明 |
---|---|---|
|
|
Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを
このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを |
|
|
注記
デフォルト値の |
|
| オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
|
| オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。 |
フィールド | 型 | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
フィールド | 型 | 説明 |
---|---|---|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は 重要
OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして |
フィールド | 型 | 説明 |
---|---|---|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
クラスターのインストール中にのみクラスターネットワークプラグインの設定を変更できます。ただし、インストール後のアクティビティーとして実行時に変更できる gatewayConfig
フィールドは除きます。
IPSec が有効な OVN-Kubernetes 設定の例
6.6.2. Cluster Network Operator の設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、詳細な CNO 設定が指定されています。
Cluster Network Operator オブジェクトのサンプル
第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
オブジェクトを使用してデプロイされます。
oc get
コマンドを使用してデプロイメントのステータスを表示します。oc get -n openshift-dns-operator deployment/dns-operator
$ oc get -n openshift-dns-operator deployment/dns-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get
コマンドを使用して DNS Operator の状態を表示します。oc get clusteroperator/dns
$ oc get clusteroperator/dns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE dns 4.1.15-0.11 True False False 92m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE dns 4.1.15-0.11 True False False 92m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE
、PROGRESSING
、およびDEGRADED
は、Operator のステータスに関する情報を示します。AVAILABLE
がTrue
になるのは、CoreDNS デーモンセットの 1 つ以上の Pod がAVAILABLE
ステータス条件を報告し、DNS サービスがクラスター IP アドレスを持っている場合です。
7.2. デフォルト DNS の表示 リンクのコピーリンクがクリップボードにコピーされました!
すべての新規 OpenShift Container Platform インストールには、default
という名前の dns.operator
があります。
手順
oc describe
コマンドを使用してデフォルトのdns
を表示します。oc describe dns.operator/default
$ oc describe dns.operator/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのサービス CIDR 範囲 (
172.30.0.0/16
など) を確認するには、oc get
コマンドを使用します。oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. DNS 転送の使用 リンクのコピーリンクがクリップボードにコピーされました!
次の方法で、DNS 転送を使用して /etc/resolv.conf
ファイル内のデフォルトの転送設定をオーバーライドできます。
-
すべてのゾーンにネームサーバー (
spec.servers
) を指定します。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、そのドメインに対してアップストリームのネームサーバーが許可されている必要があります。 -
アップストリーム DNS サーバーのリスト (
spec.upstreamResolvers
) を指定します。 - デフォルトの転送ポリシーを変更します。
デフォルトドメインの DNS 転送設定には、/etc/resolv.conf
ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。
手順
default
という名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドを実行すると、Operator が、
spec.servers
に基づく追加のサーバー設定ブロックを使用してdns-default
という名前の config map を作成および更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。DNS 転送の設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
にリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。Random
、RoundRobin
、またはSequential
のいずれかの値を指定できます。デフォルト値はSequential
です。- 7
- 省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。
TCP
に設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。 - 8
- DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
- 9
- 2 種類の
upstreams
(SystemResolvConf
またはNetwork
) を指定できます。SystemResolvConf
で、アップストリームが/etc/resolv.conf
を使用するように設定して、Network
でNetworkresolver
を定義します。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
$ oc describe clusteroperators/dns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow メッセージとスペルはリリースによって異なる場合がありますが、期待されるステータス出力は次のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.5. DNS Operator のログの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc logs
コマンドを使用して、DNS Operator ログを表示できます。
手順
DNS Operator のログを表示します。
oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.6. CoreDNS ログレベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。CoreDNS ログレベルを設定して、ログに記録されたエラーメッセージの情報量を決定できます。CoreDNS ログレベルの有効な値は、Normal
、Debug
、および Trace
です。デフォルトの logLevel
は Normal
です。
CoreDNS のエラーログレベルは常に有効です。次のログレベル設定では、それぞれ異なるエラー応答が報告されます。
-
logLevel
:Normal
は "errors" class:log . { class error }
を有効にします。 -
logLevel
:Debug
は "denial" class:log . { class denial error }
を有効にします。 -
logLevel
:Trace
は "all" class:log . { class all }
を有効にします。
手順
logLevel
をDebug
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow logLevel
をTrace
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
目的のログレベルが設定されていることを確認するには、config map を確認します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
logLevel
をTrace
に設定すると、各サーバーブロックに次のスタンザが表示されます。errors log . { class all }
errors log . { class all }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7. CoreDNS ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
oc logs
コマンドを使用して CoreDNS ログを表示できます。
手順
特定の CoreDNS Pod のログを表示するには、次のコマンドを入力します。
oc -n openshift-dns logs -c dns <core_dns_pod_name>
$ oc -n openshift-dns logs -c dns <core_dns_pod_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべての CoreDNS Pod のログを追跡するには、次のコマンドを入力します。
oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number>
$ oc -n openshift-dns logs -c dns -l dns.operator.openshift.io/daemonset-dns=default -f --max-log-requests=<number>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ログをストリーミングする DNS Pod の数を指定します。最大は 6 です。
7.8. CoreDNS Operator のログレベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel
の有効な値は、Normal
、Debug
、および Trace
です。Trace
には最も詳細にわたる情報が含まれます。デフォルトの operatorlogLevel
は Normal
です。Operator の問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal、および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。
-
operatorLogLevel: "Normal"
はlogrus.SetLogLevel("Info")
を設定します。 -
operatorLogLevel: "Debug"
はlogrus.SetLogLevel("Debug")
を設定します。 -
operatorLogLevel: "Trace"
はlogrus.SetLogLevel("Trace")
を設定します。
手順
operatorLogLevel
をDebug
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow operatorLogLevel
をTrace
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
結果の変更を確認するには、次のコマンドを入力します。
oc get dnses.operator -A -oyaml
$ oc get dnses.operator -A -oyaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 2 つのログレベルのエントリーが表示されるはずです。
operatorLogLevel
は OpenShift DNS Operator の問題に適用され、logLevel
は CoreDNS Pod のデーモンセットに適用されます。logLevel: Trace operatorLogLevel: Debug
logLevel: Trace operatorLogLevel: Debug
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デーモンセットのログを確認するには、次のコマンドを入力します。
oc logs -n openshift-dns ds/dns-default
$ oc logs -n openshift-dns ds/dns-default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9. CoreDNS キャッシュのチューニング リンクのコピーリンクがクリップボードにコピーされました!
CoreDNS の場合、成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間をチューニングすると、アップストリーム DNS リゾルバーの負荷を軽減できます。
TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。
手順
次のコマンドを実行して、
default
という名前の DNS Operator オブジェクトを編集します。oc edit dns.operator.openshift.io/default
$ oc edit dns.operator.openshift.io/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Time-to-Live (TTL) キャッシュ値を変更します。
DNS キャッシングの設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
変更を確認するには、次のコマンドを実行して config map を再度確認します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のようなエントリーが表示されていることを確認します。
cache 3600 { denial 9984 2400 }
cache 3600 { denial 9984 2400 }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 の問題が修正されているかどうかを確認するために、設定変更をテストする必要があります。
managementState
をUnmanaged
に設定することで、DNS Operator による設定変更の上書きを防止できます。 -
クラスター管理者は、CoreDNS の問題を報告していますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の
managementState
フィールドをUnmanaged
に設定して、回避策を適用できます。
手順
DNS Operator の
managementState
をUnmanaged
に変更します。oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow jsonpath
コマンドライン JSON パーサーを使用して DNS Operator のmanagementState
を確認します。oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記managementState
がUnmanaged
に設定されている間はアップグレードできません。
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 の
managementState
がManaged
に設定されている。
手順
CoreDNS のデーモンセットを特定のノードで実行できるようにするために、taint と toleration を設定します。
次のコマンドを入力して、DNS Pod の配置を制御するノードに taint を設定します。
oc adm taint nodes <node_name> dns-only=abc:NoExecute
$ oc adm taint nodes <node_name> dns-only=abc:NoExecute
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>
は、ノードの実際の名前に置き換えます。
次のコマンドを入力して、
default
という名前の DNS Operator オブジェクトを、対応する toleration が含まれるように変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow taint の taint キーと toleration を指定します。次の toleration は、ノードに設定された taint と一致します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ノードセレクターを使用してノードの配置を指定するには、デフォルトの DNS Operator を変更します。
default
という名前の DNS Operator オブジェクトを編集して、ノードセレクターを含めます。spec: nodePlacement: nodeSelector: node-role.kubernetes.io/control-plane: ""
spec: nodePlacement: nodeSelector:
1 node-role.kubernetes.io/control-plane: ""
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このノードセレクターにより、CoreDNS Pod がコントロールプレーンノードでのみ実行されるようになります。
7.10.3. TLS を使用した DNS 転送の設定 リンクのコピーリンクがクリップボードにコピーされました!
高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。
CoreDNS は転送された接続を 10 秒間キャッシュすることに注意してください。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。
手順
default
という名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。
TLS を使用した DNS 転送の設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
の値は1
〜65535
である必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。
注記servers
が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。
検証
config map を表示します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TLS 転送の例に基づく DNS ConfigMap のサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 定義
インストールプログラムは、このアセットを 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) には、組織の特定のニーズを満たすように設定できる任意の設定パラメーターが含まれています。
パラメーター | 説明 |
---|---|
|
空の場合、デフォルト値は |
|
|
|
クラウド環境の場合、
GCP、AWS、および Azure では、次の
設定されていない場合、デフォルト値は
ほとんどのプラットフォームでは、
ベアメタルプラットフォームなどの非クラウド環境の場合は、
これらのフィールドのいずれかで値を設定しない場合のデフォルト値は、
クラスターのデプロイ後に、
|
|
シークレットには以下のキーおよびデータが含まれる必要があります: *
設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの 使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。 |
|
|
|
|
|
設定されていない場合は、デフォルト値が使用されます。 注記
|
|
これが設定されていない場合、デフォルト値は
Ingress Controller の最小 TLS バージョンは 注記
設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが 重要
Ingress Operator は TLS |
|
|
|
|
|
|
|
デフォルトでは、ポリシーは
これらの調整は、クリアテキスト、edge-terminated、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。
要求ヘッダーの場合、これらの調整は
|
|
|
|
|
|
キャプチャーするすべての Cookie について、次のパラメーターが
以下に例を示します。 httpCaptureCookies: - matchType: Exact maxLength: 128 name: MYCOOKIE
|
|
|
|
|
|
|
|
これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを |
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 セキュリティープロファイルのいずれかを指定できます。
プロファイル | 説明 |
---|---|
| このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。
注記 Ingress Controller の場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。 |
| このプロファイルは、Ingress Controller、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。
注記 このプロファイルは、大多数のクライアントに推奨される設定です。 |
| このプロファイルは、下位互換性を必要としない最新のクライアントで使用することを目的としています。このプロファイルは、Modern compatibility の推奨設定に基づいています。
|
| このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。 警告
無効な設定により問題が発生する可能性があるため、 |
事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース 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
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.3
と Modern
プロファイルをサポートしています。
また、Ingress Operator は TLS 1.0
の Old
または Custom
プロファイルを 1.1
に変換します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-ingress-operator
プロジェクトのIngressController
CR を編集して、TLS セキュリティープロファイルを設定します。oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのサンプルIngressController
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。
検証
IngressController
CR にプロファイルが設定されていることを確認します。oc describe IngressController default -n openshift-ingress-operator
$ oc describe IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
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 Copied! Toggle word wrap Toggle overflow
手順
openshift-config
namespace で、CA バンドルから config map を作成します。oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \ -n openshift-config
$ oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \
1 -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- config map データキーは
ca-bundle.pem
で、data の値は PEM 形式の CA 証明書である必要があります。
openshift-ingress-operator
プロジェクトでIngressController
リソースを編集します。oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.clientTLS
フィールドおよびサブフィールドを追加して相互 TLS を設定します。フィルタリングパターンを指定する
clientTLS
プロファイルのサンプルIngressController
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプションで、次のコマンドを入力して、
allowedSubjectPatterns
の識別名 (DN) を取得します。
openssl x509 -in custom-cert.pem -noout -subject
$ openssl x509 -in custom-cert.pem -noout -subject
subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift
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
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5. Ingress Operator ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator のステータスを表示し、検査することができます。
手順
Ingress Operator ステータスを表示します。
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6. Ingress Controller ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller ログを表示できます。
手順
Ingress Controller ログを表示します。
oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.7. Ingress Controller ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
特定の Ingress Controller のステータスを表示できます。
手順
Ingress Controller のステータスを表示します。
oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8. カスタム Ingress Controller の作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、新規のカスタム Ingress Controller を作成できます。デフォルトの Ingress Controller は OpenShift Container Platform の更新時に変更される可能性があるため、クラスターの更新後も保持される設定を手動で維持する場合は、カスタム Ingress Controller を作成すると便利です。
この例では、カスタム Ingress Controller の最小限の仕様を提供します。カスタム Ingress Controller をさらにカスタマイズするには、「Ingress Controller の設定」を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
カスタム
IngressController
オブジェクトを定義する YAML ファイルを作成します。custom-ingress-controller.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してオブジェクトを作成します。
oc create -f custom-ingress-controller.yaml
$ oc create -f custom-ingress-controller.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
$ oc --namespace openshift-ingress-operator get ingresscontrollers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt
ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書をリスト表示します。
手順
以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt
および tls.key
ファイルにあることを前提とします。tls.crt
および tls.key
を実際のパス名に置き換えます。さらに、Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default
を別の名前に置き換えます。
このアクションにより、Ingress Controller はデプロイメントストラテジーを使用して再デプロイされます。
tls.crt
およびtls.key
ファイルを使用して、カスタム証明書を含む Secret リソースをopenshift-ingress
namespace に作成します。oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
Copy to Clipboard Copied! Toggle word wrap Toggle overflow IngressController CR を、新規証明書シークレットを参照するように更新します。
oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新が正常に行われていることを確認します。
echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
$ 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 Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<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
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 Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書シークレットの名前は、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'
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \ --type json -p $'- op: remove\n path: /spec/defaultCertificate'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。
検証
元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。
echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
$ 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 Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<domain>
- クラスターのベースドメイン名を指定します。
出力例
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
のインスタンスを作成できます。
-
この Operator は、Web コンソールで OperatorHub を使用してインストールできます。Operator をインストールしたら、
手順
以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。
oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
$ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントのトークンを使用して、
openshift-ingress-operator
namespace 内でTriggerAuthentication
オブジェクトを定義します。TriggerAuthentication
オブジェクトを作成し、secret
変数の値をTOKEN
パラメーターに渡します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Thanos からメトリクスを読み取るためのロールを作成して適用します。
Pod およびノードからメトリクスを読み取る新規ロール
thanos-metrics-reader.yaml
を作成します。thanos-metrics-reader.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規ロールを適用します。
oc apply -f thanos-metrics-reader.yaml
$ oc apply -f thanos-metrics-reader.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。
oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
$ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
$ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記引数
add-cluster-role-to-user
は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とするkube-metrics
namespace からのクエリーを使用します。デフォルトの Ingress Controller デプロイメントをターゲットにする新しい
ScaledObject
YAML ファイルingress-autoscaler.yaml
を作成します。ScaledObject
定義の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要namespace 間クエリーを使用している場合は、
serverAddress
フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。以下のコマンドを実行してカスタムリソース定義を適用します。
oc apply -f ingress-autoscaler.yaml
$ oc apply -f ingress-autoscaler.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して、デフォルトの Ingress Controller が
kube-state-metrics
クエリーによって返される値に一致するようにスケールアウトされていることを確認します。grep
コマンドを使用して、Ingress Controller YAML ファイルでレプリカの数を検索します。oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
$ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-ingress
プロジェクトで Pod を取得します。oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow
8.9.4. Ingress Controller のスケーリング リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc
コマンドは、IngressController
リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController
をスケールアップする例を示します。
スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。
手順
デフォルト
IngressController
の現在の利用可能なレプリカ数を表示します。oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch
コマンドを使用して、デフォルトのIngressController
を必要なレプリカ数にスケーリングします。以下の例では、デフォルトのIngressController
を 3 つのレプリカにスケーリングしています。oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトの
IngressController
が指定したレプリカ数にスケーリングされていることを確認します。oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 定義です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に
logs
という名前のコンテナーを作成します。oc -n openshift-ingress logs deployment.apps/router-default -c logs
$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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"
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 Copied! Toggle word wrap Toggle overflow
Syslog エンドポイントへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type
にSyslog
を指定する必要があります。宛先タイプがSyslog
の場合、spec.logging.access.destination.syslog.address
を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility
を使用してファシリティーを指定できます。以下の例は、Syslog
宛先に対してログを記録する Ingress Controller の定義です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記syslog
宛先ポートは UDP である必要があります。syslog
の宛先アドレスは IP アドレスにする必要があります。DNS ホスト名はサポートされていません。
特定のログ形式で Ingress アクセスロギングを設定します。
spec.logging.access.httpLogFormat
を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 のsyslog
エンドポイントに対してログを記録する Ingress Controller の定義です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Ingress アクセスロギングを無効にします。
Ingress アクセスロギングを無効にするには、
spec.logging
またはspec.logging.access
を空のままにします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
サイドカーの使用時に Ingress Controller が HAProxy ログの長さを変更できるようにします。
spec.logging.access.destination.type: Syslog
を使用している場合は、spec.logging.access.destination.syslog.maxLength
を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.logging.access.destination.type: Container
を使用している場合は、spec.logging.access.destination.container.maxLength
を使用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
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}}}'
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記大量のリソースを実行できるノードがある場合、
spec.nodePlacement.nodeSelector
を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount
を随時高い値に設定します。
8.9.7. 内部ロードバランサーを使用するための Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController
の scope
を変更する場合は、カスタムリソース (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
権限を持つユーザーとしてログインしている。
手順
以下の例のように、
<name>-ingress-controller.yaml
という名前のファイルにIngressController
カスタムリソース (CR) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。
oc create -f <name>-ingress-controller.yaml
$ oc create -f <name>-ingress-controller.yaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<name>
をIngressController
オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。
oc --all-namespaces=true get ingresscontrollers
$ oc --all-namespaces=true get ingresscontrollers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9.8. GCP での Ingress Controller のグローバルアクセスの設定 リンクのコピーリンクがクリップボードにコピーされました!
内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。
詳細情報は、GCP ドキュメントの グローバルアクセス を参照してください。
前提条件
- OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
- 内部ロードバランサーを使用するように Ingress Controller を設定している。
-
OpenShift CLI (
oc
) がインストールされている。
手順
グローバルアクセスを許可するように Ingress Controller リソースを設定します。
注記Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。
Ingress Controller リソースを設定します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを編集します。
サンプル
clientAccess
設定をGlobal
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
gcp.clientAccess
をGlobal
に設定します。
- 変更を適用するためにファイルを保存します。
以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。
oc -n openshift-ingress edit svc/router-default -o yaml
$ oc -n openshift-ingress edit svc/router-default -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力には、アノテーション
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"}}}'
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記単一ルートの
healthCheckInterval
をオーバーライドするには、ルートアノテーションrouter.openshift.io/haproxy.health.check.interval
を使用します
8.9.10. クラスターを内部に配置するためのデフォルト Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
削除や再作成を実行して、クラスターを内部に配置するように default
Ingress Controller を設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController
の scope
を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
default
Ingress Controller を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージコントローラー設定例
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してルートの受付ポリシーを設定できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9.12. ワイルドカードルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy
を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES
環境変数を設定します。
Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None
(既存の IngressController
リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressController
リソースを編集します。oc edit IngressController
$ oc edit IngressController
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec
の下で、wildcardPolicy
フィールドをWildcardsDisallowed
またはWildcardsAllowed
に設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
仕様の例
ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN
を設定します。
Route
仕様の例
IngressController
仕様と Route
仕様の両方で X-Frame-Options 応答ヘッダーが設定されている場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。リクエストヘッダーの場合、Route
仕様の値が IngressController
仕様の値をオーバーライドします。
この優先順位付けは、haproxy.config
ファイルで次のロジックが使用されるため発生します。このロジックでは、Ingress Controller がフロントエンドと見なされ、個々のルートがバックエンドと見なされます。フロントエンド設定に適用されるヘッダー値 DENY
は、バックエンドで設定されている値 SAMEORIGIN
で同じヘッダーをオーバーライドします。
さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。
8.9.13.2. 特殊なケースのヘッダー リンクのコピーリンクがクリップボードにコピーされました!
次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。
ヘッダー名 | IngressController 仕様を使用して設定可能かどうか | Route 仕様を使用して設定可能かどうか | 不許可の理由 | 別の方法で設定可能かどうか |
---|---|---|---|---|
| いいえ | いいえ |
| いいえ |
| いいえ | はい |
| いいえ |
| いいえ | いいえ |
|
はい: |
| いいえ | いいえ | HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。 | はい:
|
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 クラスターにアクセスできる。
手順
Ingress Controller リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
コンバーターを使用できます。- 変更を適用するためにファイルを保存します。
8.9.15. X-Forwarded ヘッダーの使用 リンクのコピーリンクがクリップボードにコピーされました!
Forwarded
および X-Forwarded-For
を含む HTTP ヘッダーの処理方法に関するポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders
フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS
環境変数を設定します。
手順
Ingress Controller 用に
HTTPHeaders
フィールドを設定します。以下のコマンドを使用して
IngressController
リソースを編集します。oc edit IngressController
$ oc edit IngressController
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec
の下で、HTTPHeaders
ポリシーフィールドをAppend
、Replace
、IfNone
、またはNever
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用例
クラスター管理者として、以下を実行できます。
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
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<ingresscontroller_name>
は、HTTP/2 を有効化する Ingress Controller の名前に置き換えます。
クラスター全体で HTTP/2 を有効にするには、
oc annotate
コマンドを入力します。oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、次の YAML コードを適用して HTTP/2 を有効化できます。
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
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<ingresscontroller_name>
は、HTTP/2 を無効化する Ingress Controller の名前に置き換えます。
クラスター全体で HTTP/2 を無効化するには、
oc annotate
コマンドを入力します。oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、次の YAML コードを適用して HTTP/2 を無効化できます。
8.9.17. Ingress Controller の PROXY プロトコルの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Ingress Controller が HostNetwork
、NodePortService
、または 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 を作成している。
手順
CLI で次のコマンドを入力して、Ingress Controller リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PROXY 設定を設定します。
Ingress Controller が
HostNetwork
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.hostNetwork.protocol
サブフィールドをPROXY
に設定します。PROXY
へのhostNetwork
の設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller が
NodePortService
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol
サブフィールドをPROXY
に設定します。PROXY
へのサンプルnodePort
設定Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller が
Private
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.private.protocol
サブフィールドをPROXY
に設定します。PROXY
へのprivate
設定のサンプルCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9.18. appsDomain オプションを使用した代替クラスタードメインの指定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、appsDomain
フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain
フィールドは、domain
フィールドで指定されているデフォルトの代わりに使用する OpenShift Container Platform のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。
たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
コマンドラインインターフェイスがインストールされている。
手順
ユーザーが作成するルートに代替のデフォルトドメインを指定して
appsDomain
フィールドを設定します。Ingress
cluster
リソースを編集します。oc edit ingresses.config/cluster -o yaml
$ oc edit ingresses.config/cluster -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルを編集します。
test.example.com
へのappsDomain
の設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、
appsDomain
フィールドで指定したドメイン名が含まれていることを確認します。注記ルートを公開する前に
openshift-apiserver
がローリング更新を終了するのを待機します。次のコマンドを入力してルートを公開します。このコマンドは、ルートの公開を指定するために
route.route.openshift.io/hello-openshift exposed
を出力します。oc expose service hello-openshift
$ oc expose service hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルートのリストを取得します。
oc get routes
$ oc get routes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp None
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 Copied! Toggle word wrap Toggle overflow
8.9.19. HTTP ヘッダーケースの変換 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com
は host: 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 ヘッダーを大文字にします。次のコマンドを実行して、HTTP ヘッダーを
host
からHost
に変更します。oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アノテーションをアプリケーションに適用できるように、
Route
リソースの YAML ファイルを作成します。my-application
という名前のルートの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller が指定どおりに
host
リクエストヘッダーを調整できるように、haproxy.router.openshift.io/h1-adjust-case
を設定します。
Ingress Controller YAML 設定ファイルで
HeaderNameCaseAdjustments
フィールドを設定して調整を指定します。次の Ingress Controller YAML ファイルの例では、適切にアノテーションが付けられたルートへの HTTP/1 リクエストの
host
ヘッダーをHost
に調整します。Ingress Controller YAML のサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のルートの例では、
haproxy.router.openshift.io/h1-adjust-case
アノテーションを使用して HTTP レスポンスヘッダー名の大文字と小文字の調整を有効にします。ルート YAML のサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。
手順
Ingress Controller の
httpCompression
フィールドを設定します。以下のコマンドを使用して
IngressController
リソースを編集します。oc edit -n openshift-ingress-operator ingresscontrollers/default
$ oc edit -n openshift-ingress-operator ingresscontrollers/default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec
で、httpCompression
ポリシーフィールドをmimeTypes
に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.9.21. ルーターメトリクスの公開 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。
前提条件
- ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。
手順
次のコマンドを実行して、ルーター Pod 名を取得します。
oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルーター Pod が
/var/lib/haproxy/conf/metrics-auth/statsUsername
および/var/lib/haproxy/conf/metrics-auth/statsPassword
ファイルに保存しているルーターのユーザー名およびパスワードを取得します。次のコマンドを実行して、ユーザー名を取得します。
oc rsh <router_pod_name> cat metrics-auth/statsUsername
$ oc rsh <router_pod_name> cat metrics-auth/statsUsername
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、パスワードを取得します。
oc rsh <router_pod_name> cat metrics-auth/statsPassword
$ oc rsh <router_pod_name> cat metrics-auth/statsPassword
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。
oc describe pod <router_pod>
$ oc describe pod <router_pod>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、安全にメトリクスにアクセスします。
curl -u user:password https://<router_IP>:<stats_port>/metrics -k
$ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例8.1 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。
http://<user>:<password>@<router_IP>:<stats_port>
http://<user>:<password>@<router_IP>:<stats_port>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。
http://<user>:<password>@<router_ip>:1936/metrics;csv
http://<user>:<password>@<router_ip>:1936/metrics;csv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.http
と error-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 改行コードを使用できるエディターが必要になります。
手順
openshift-config
にmy-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
$ 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 Copied! Toggle word wrap Toggle overflow 重要カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。
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
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 に名前を付けます。コピーを表示します。
oc get cm default-errorpages -n openshift-ingress
$ oc get cm default-errorpages -n openshift-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DATA AGE default-errorpages 2 25s
NAME DATA AGE default-errorpages 2 25s
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
default
の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例はdefault-errorpages
です。
カスタムエラー応答ページを含む 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
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 404 カスタム HTTP カスタムエラーコード応答の場合:
oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
カスタムエラーコード HTTP 応答を確認します。
テストプロジェクトおよびアプリケーションを作成します。
oc new-project test-ingress
$ oc new-project test-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-app django-psql-example
$ oc new-app django-psql-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 503 カスタム http エラーコード応答の場合:
- アプリケーションのすべての Pod を停止します。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
curl -vk <route_hostname>
$ curl -vk <route_hostname>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
404 カスタム http エラーコード応答の場合:
- 存在しないルートまたは正しくないルートにアクセスします。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
curl -vk <route_hostname>
$ curl -vk <route_hostname>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
errorfile
属性がhaproxy.config
ファイルで適切にあるかどうかを確認します。oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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}}}'
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告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
) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
openshift-ingress-node-firewall
namespace を作成するには、次のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
CR を作成するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Node Firewall Operator にサブスクライブします。
Ingress Node Firewall Operator の
Subscription
CR を作成するには、次のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get ip -n openshift-ingress-node-firewall
$ oc get ip -n openshift-ingress-node-firewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.19.0-202211122336 Automatic true
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.19.0-202211122336 Automatic true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator のバージョンを確認するには、次のコマンドを入力します。
oc get csv -n openshift-ingress-node-firewall
$ oc get csv -n openshift-ingress-node-firewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow
9.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
Ingress Node Firewall Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
- Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
- Install をクリックします。
Ingress Node Firewall Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに移動します。
Ingress Node Firewall Operator が openshift-ingress-node-firewall プロジェクトにリストされ、Status が InstallSucceeded であることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator の Status が InstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
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
$ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記単一ノードの 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 をノードにデプロイできます。
-
ingressnodefirewallconfig
という名前のopenshift-ingress-node-firewall
namespace 内にIngressNodeFirewallConfig
を作成します。 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。
oc apply -f rule.yaml
$ oc apply -f rule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3.1. Ingress ノードファイアウォール設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。
フィールド | 型 | 説明 |
---|---|---|
|
|
CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は |
|
|
Ingress Firewall Operator CR オブジェクトの namespace。 |
|
| 指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。 spec: nodeSelector: node-role.kubernetes.io/worker: ""
注記
デーモンセットを開始するには、 |
|
| Node Ingress Firewall Operator が eBPF プログラムを管理するために eBPF Manager Operator を使用するかどうかを指定します。この機能はテクノロジープレビュー機能です。 Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。 |
Operator は CR を使用し、nodeSelector
に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。
9.3.2. Ingress Node Firewall Operator の設定例 リンクのコピーリンクがクリップボードにコピーされました!
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォール設定オブジェクトを作成する方法の例
Operator は CR オブジェクトを消費し、nodeSelector に
一致するすべてのノードに Ingress ノードファイアウォールデーモンセットを作成します。
9.3.3. Ingress ノードファイアウォールルールオブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| CR オブジェクトの名前。 |
|
|
このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、 |
|
|
|
|
|
|
9.3.3.1. Ingress オブジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
ingress
オブジェクトの値は、次の表で定義されています。
フィールド | 型 | 説明 |
---|---|---|
|
| CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。 注記
異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の |
|
|
Ingress ファイアウォール
注記 Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。 |
9.3.3.2. Ingress ノードファイアウォールルールオブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォールの設定例
- 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 ノードファイアウォールルールの例
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 をインストールしている。
手順
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
$ oc label namespace openshift-ingress-node-firewall \ pod-security.kubernetes.io/enforce=privileged \ pod-security.kubernetes.io/warn=privileged --overwrite
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ingressnodefirewallconfig
という名前のIngressNodeFirewallConfig
オブジェクトを編集し、ebpfProgramManagerMode
フィールドを設定します。Ingress Node Firewall Operator 設定オブジェクト
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<ebpf_mode>
: Ingress Node Firewall Operator が eBPF Manager Operator を使用して eBPF プログラムを管理するかどうかを指定します。true
またはfalse
のどちらかでなければなりません。設定されていないと、eBPF マネージャーは使用されません。
9.6. Ingress Node Firewall Operator ルールの表示 リンクのコピーリンクがクリップボードにコピーされました!
手順
次のコマンドを実行して、現在のルールをすべて表示します。
oc get ingressnodefirewall
$ oc get ingressnodefirewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 返された
<resource>
名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。oc get <resource> <name> -o yaml
$ oc get <resource> <name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.7. Ingress Node Firewall Operator のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。
oc get crds | grep ingressnodefirewall
$ oc get crds | grep ingressnodefirewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。
oc get pods -n openshift-ingress-node-firewall
$ oc get pods -n openshift-ingress-node-firewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow 次のフィールドは、Operator のステータスに関する情報を提供します:
READY
、STATUS
、AGE
、およびRESTARTS
。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUS
フィールドはRunning
になります。次のコマンドを実行して、すべての Ingress ファイアウォールノード Pod のログを収集します。
oc adm must-gather – gather_ingress_node_firewall
$ oc adm must-gather – gather_ingress_node_firewall
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ログは、
/sos_commands/ebpf
にある eBPFbpftool
出力を含む 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
権限を持つアカウントがある。
手順
次のコマンドを入力して、
openshift-sriov-network-operator
namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
OperatorGroup
カスタムリソース (CR) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、SR-IOV Network Operator の
Subscription
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
SriovoperatorConfig
リソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に
Succeeded
と表示されていることを確認します。oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-sriov-network-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.1.1.2. Web コンソール: SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
前提条件
- SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントがある。
手順
SR-IOV Network Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
- Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
- Install をクリックします。
SR-IOV Network Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに移動します。
Status が InstallSucceeded の状態で、SR-IOV Network Operator が openshift-sriov-network-operator プロジェクトにリスト表示されていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
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
$ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シングルノード 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) を作成します。次の YAML を使用して、
sriovOperatorConfig.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
です。
次のコマンドを実行して、リソースを作成します。
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.1.1. SR-IOV Network Operator config カスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
sriovoperatorconfig
カスタムリソースのフィールドは、以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
SR-IOV Network Operator インスタンスの名前を指定します。デフォルト値は |
|
|
SR-IOV Network Operator インスタンスの namespace を指定します。デフォルト値は |
|
| 選択されたノードで SR-IOV Network Config Daemon のスケジューリングを制御するノードの選択オプションを指定します。デフォルトでは、このフィールドは設定されておらず、Operator はワーカーノードに SR-IOV Network Config デーモンセットを配置します。 |
|
|
新しいポリシーを適用してノードに NIC を設定する時に、ノードドレインプロセスを無効にするか、有効にするかを指定します。このフィールドを
シングルノードクラスターの場合は、Operator のインストール後にこのフィールドを |
|
| Network Resources Injector デーモンセットを有効にするか無効にするかを指定します。 |
|
| Operator Admission Controller の Webhook デーモンセットを有効にするか無効にするかを指定します。 |
|
|
Operator のログの詳細レベルを指定します。デフォルトでは、このフィールドは |
|
|
任意の機能を有効にするか無効にするかを指定します。たとえば、 |
|
|
SR-IOV Network Operator メトリクスを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは |
|
|
SR-IOV Network Operator の Virtual Function (VF) の変更時にファームウェアをリセットするかどうかを指定します。Intel C740 シリーズなどの一部のチップセットでは、NVIDIA/Mellanox NIC で VF を設定するために必要な PCI-E デバイスの電源が完全にオフになりません。デフォルトでは、このフィールドは 重要
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 で enableInjector
が true
に設定されている場合、SR-IOV Network Operator によって有効になります。network-resources-injector
Pod は、すべてのコントロールプレーンノード上でデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Network Resources Injector Pod の例です。
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operator
出力例
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
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
デフォルトでは、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
オブジェクトの設定例
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> } }'
$ oc patch sriovoperatorconfig default \ --type=merge -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableInjector": <value> } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 で enableOperatorWebhook
が true
に設定されている場合、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
$ oc get pods -n openshift-sriov-network-operator
出力例
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
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
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> } }'
$ oc patch sriovoperatorconfig default --type=merge \ -n openshift-sriov-network-operator \ --patch '{ "spec": { "enableOperatorWebhook": <value> } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 のノードセレクターを更新するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、
<node_label>
を適用するラベルに置き換えます:"node-role.kubernetes.io/worker": ""
ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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": "" } } }'
$ oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して Operator を更新することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2.1.9. Hosted Control Plane 用の SR-IOV Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ホスティングサービスクラスターを設定してデプロイすると、ホステッドクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。
前提条件
AWS 上でホステッドクラスターを設定およびデプロイしている。
手順
namespace と Operator グループを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator へのサブスクリプションを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。
oc get csv -n openshift-sriov-network-operator
$ oc get csv -n openshift-sriov-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 メトリクスを説明します。
メトリクス | 説明 | VF メトリクスを調べるための PromQL クエリーの例 |
---|---|---|
| Virtual Function ごとに受信したバイト数。 |
|
| Virtual Function ごとに送信されたバイト数。 |
|
| Virtual Function ごとの受信パケット数。 |
|
| Virtual Function あたりの送信パケット数。 |
|
| Virtual Function ごとに受信時にドロップされたパケット。 |
|
| Virtual Function ごとに送信中にドロップされたパケット。 |
|
| Virtual Function ごとに受信したマルチキャストパケット。 |
|
| Virtual Function ごとに受信したブロードキャストパケット。 |
|
| アクティブな 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
(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
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 がインストールされている。
手順
次のコマンドを実行して、クラスター監視を有効にします。
oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
$ oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター監視を有効にするには、SR-IOV Network Operator をインストールした namespace に
openshift.io/cluster-monitoring=true
ラベルを追加する必要があります。次のコマンドを実行して、
spec.featureGates.metricsExporter
フィールドをtrue
に設定します。oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \ --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'
$ oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \ --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、SR-IOV ネットワークメトリクスエクスポーターが有効になっていることを確認します。
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow sriov-network-metrics-exporter
Pod はREADY
状態である必要があります。- オプション: 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 がインストールされている。
手順
すべての SR-IOV カスタムリソース (CR) を削除します。
oc delete sriovnetwork -n openshift-sriov-network-operator --all
$ oc delete sriovnetwork -n openshift-sriov-network-operator --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
$ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete sriovibnetwork -n openshift-sriov-network-operator --all
$ oc delete sriovibnetwork -n openshift-sriov-network-operator --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete sriovoperatorconfigs -n openshift-sriov-network-operator --all
$ oc delete sriovoperatorconfigs -n openshift-sriov-network-operator --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 「クラスターからの Operator の削除」セクションに記載された手順に従い、クラスターから SR-IOV Network Operator を削除します。
SR-IOV Network Operator のアンインストール後にクラスターに残っている SR-IOV カスタムリソース定義を削除します。
oc delete crd sriovibnetworks.sriovnetwork.openshift.io
$ oc delete crd sriovibnetworks.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworks.sriovnetwork.openshift.io
$ oc delete crd sriovnetworks.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Network Operator の namespace を削除します。
oc delete namespace openshift-sriov-network-operator
$ oc delete namespace openshift-sriov-network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第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 デバイスを次の表に示します。
ベンター | デバイス | ファームウェア | 説明 |
---|---|---|---|
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
権限を持つアカウントがある。
手順
次のコマンドを入力して、
openshift-dpu-operator
namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
OperatorGroup
カスタムリソース (CR) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、DPU Operator の
Subscription
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Operator がインストールされていることを確認するには、次のコマンドを入力し、Operator に対して出力に
Succeeded
と表示されていることを確認します。oc get csv -n openshift-dpu-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-dpu-operator \ -o custom-columns=Name:.metadata.name,Phase:.status.phase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-dpu-operator
プロジェクトに変更します。oc project openshift-dpu-operator
$ oc project openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、DPU Operator が実行されていることを確認します。
oc get pods -n openshift-dpu-operator
$ oc get pods -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE dpu-operator-controller-manager-6b7bbb5db8-7lvkj 2/2 Running 0 2m9s
NAME READY STATUS RESTARTS AGE dpu-operator-controller-manager-6b7bbb5db8-7lvkj 2/2 Running 0 2m9s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2.2. Web コンソールを使用して DPU Operator をインストールする リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して DPU Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントがある。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから DPU Operator を選択してから Install をクリックします。
Install Operator ページの Installed Namespace で、Operator recommended Namespace オプションを選択します。アクションは不要です。
- Install をクリックします。
検証
- Operators → Installed Operators ページに移動します。
DPU Operator が、ステータス が InstallSucceeded で openshift-dpu-operator プロジェクトにリストされていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
トラブルシューティング
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
openshift-dpu-operator
プロジェクトで Pod のログを確認します。 YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション
workload.openshift.io/allowed=management
を Operator namespace に追加できます。oc annotate ns/openshift-dpu-operator workload.openshift.io/allowed=management
$ oc annotate ns/openshift-dpu-operator workload.openshift.io/allowed=management
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シングルノード OpenShift クラスターの場合は、namespace にアノテーション
workload.openshift.io/allowed=management
が必要です。
11.2.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
11.3. DPU Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の DPU デバイスとネットワークアタッチメントを管理するように DPU Operator を設定できます。
11.3.1. DPU Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
DPU Operator を設定するには、次の手順に従います。
手順
-
ホストクラスターと各 DPU クラスターの両方に
DpuOperatorConfig
カスタムリソース (CR) を作成します。この CR が作成された後に、各クラスターの DPU Operator がアクティブ化されます。 次の YAML を使用して、
dpu-operator-host-config.yaml
という名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、リソースを作成します。
oc apply -f dpu-operator-host-config.yaml
$ oc apply -f dpu-operator-host-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DPU が接続されている、あるいは DPU として機能している、そのいずれかに該当するすべてのノードにラベルを付ける必要があります。ホストクラスターでは、各ノードに DPU が接続されているものと見なし、すべてのコンピュートノードに
dpu=true
というラベルを付けることを意味します。各 MicroShift クラスターが単一のノードで構成される DPU では、各クラスター内のそのシングルノードにdpu=true
のラベルを付けます。次のコマンドを実行してこのラベルを適用できます。oc label node <node_name> dpu=true
$ oc label node <node_name> dpu=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
node_name
-
ノードの名前を参照します (例:
worker-1
)。
11.4. DPU でワークロードを実行する リンクのコピーリンクがクリップボードにコピーされました!
DPU でワークロードを実行すると、ネットワーク、セキュリティー、ストレージなどの特殊なインフラストラクチャータスクを専用の処理ユニットにオフロードできるようになります。これにより、パフォーマンスが向上し、インフラストラクチャーとアプリケーションのワークロード間のセキュリティー境界が強化され、ホストの CPU リソースが解放されます。
11.4.1. DPU でワークロードを実行する リンクのコピーリンクがクリップボードにコピーされました!
DPU にワークロードをデプロイするには、次の手順に従います。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントが利用可能である。 - DPU Operator がインストールされている。
手順
次の YAML を使用してホスト側にサンプルワークロードを作成し、ファイルを
workload-host.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ワークロードがデプロイされるノードの名前。
次のコマンドを実行して、ワークロードを作成します。
oc apply -f workload-host.yaml
$ oc apply -f workload-host.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4.2. DPU 上にサービスファンクションチェーンを作成する リンクのコピーリンクがクリップボードにコピーされました!
ネットワークサービスチェイニング (サービスファンクションチェイニング (SFC) とも呼ばれる) は、ソフトウェア定義ネットワーク (SDN) 機能を使用して、接続されたネットワークサービスのチェーンを作成する機能です。このチェーンには、ファイアウォール、ネットワークアドレス変換 (NAT)、侵入防止といった L4-7 サービスなどが含まれます。
以下の手順に従い、DPU 上でサービスファンクションチェーン内に my-network-function
ネットワーク機能を作成します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つアカウントがある。 - DPU Operator をインストールします。
手順
次の YAML ファイルの例を
sfc.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow DPU ノードで次のコマンドを実行してチェーンを作成します。
oc apply -f sfc.yaml
$ oc apply -f sfc.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.5. DPU Operator のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
DPU Operator をアンインストールするには、まず実行中の DPU ワークロードを削除する必要があります。DPU Operator をアンインストールするには、次の手順に従います。
11.5.1. DPU Operator のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、DPU Operator をアンインストールできます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - DPU Operator がインストールされている。
手順
次のコマンドを実行して作成された
DpuOperatorConfig
CR を削除します。oc delete DpuOperatorConfig dpu-operator-config
$ oc delete DpuOperatorConfig dpu-operator-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、DPU Operator のインストールに使用されたサブスクリプションを削除します。
oc delete Subscription openshift-dpu-operator-subscription -n openshift-dpu-operator
$ oc delete Subscription openshift-dpu-operator-subscription -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、作成された
OperatorGroup
リソースを削除します。oc delete OperatorGroup dpu-operators -n openshift-dpu-operator
$ oc delete OperatorGroup dpu-operators -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のように DPU Operator をアンインストールします。
次のコマンドを実行して、インストールされている Operator を確認します。
oc get csv -n openshift-dpu-operator
$ oc get csv -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE dpu-operator.v4.19.0-202503130333 DPU Operator 4.19.0-202503130333 Failed
NAME DISPLAY VERSION REPLACES PHASE dpu-operator.v4.19.0-202503130333 DPU Operator 4.19.0-202503130333 Failed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して DPU Operator を削除します。
oc delete csv dpu-operator.v4.19.0-202503130333 -n openshift-dpu-operator
$ oc delete csv dpu-operator.v4.19.0-202503130333 -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、DPU Operator 用に作成された namespace を削除します。
oc delete namespace openshift-dpu-operator
$ oc delete namespace openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、DPU Operator がアンインストールされていることを確認します。成功したコマンド出力の例は、
No resources found in openshift-dpu-operator namespace
です。oc get csv -n openshift-dpu-operator
$ oc get csv -n openshift-dpu-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.