ネットワーク
クラスターネットワークの設定および管理
概要
第1章 ネットワークの概要 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Networking は、1 つまたは複数のハイブリッドクラスターのネットワークトラフィックを管理するためにクラスターが必要とする高度なネットワーク関連機能で Kubernetes ネットワーキングを拡張する機能、プラグイン、高度なネットワーク機能のエコシステムです。このネットワーキング機能のエコシステムは、Ingress、Egress、ロードバランシング、高性能スループット、セキュリティー、クラスター間およびクラスター内のトラフィック管理を統合し、ロールベースの可観測性ツールを提供して複雑さを軽減します。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
以下のリストは、クラスターで利用可能な最も一般的に使用される Red Hat OpenShift Networking 機能の一部を強調しています。
次の Container Network Interface (CNI) プラグインのいずれかによって提供されるプライマリークラスターネットワーク:
- OVN-Kubernetes ネットワークプラグイン (デフォルトのプラグイン)
- OpenShift SDN ネットワークプラグイン
- 認定されたサードパーティーの代替プライマリーネットワークプラグイン
- ネットワークプラグイン管理用の Cluster Network Operator
- TLS 暗号化 Web トラフィックの Ingress Operator
- 名前割り当てのための DNS Operator
- ベアメタルクラスターでのトラフィック負荷分散用の MetalLB Operator
- 高可用性のための IP フェイルオーバーのサポート
- macvlan、ipvlan、SR-IOV ハードウェアネットワークなど、複数の CNI プラグインによる追加のハードウェアネットワークサポート
- IPv4、IPv6、およびデュアルスタックアドレッシング
- Windows ベースのワークロード用のハイブリッド Linux-Windows ホストクラスター
- サービスのディスカバリー、ロードバランシング、サービス間認証、障害リカバリー、メトリクス、およびモニター用の Red Hat OpenShift Service Mesh
- シングルノード OpenShift
- ネットワークのデバッグと洞察のための Network Observability Operator
- クラスター間ネットワーク用の Submariner
- レイヤー 7 クラスター間ネットワーク用の Red Hat Service Interconnect
第2章 ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターで実行されるアプリケーションを外部トラフィックに公開し、ネットワーク接続のセキュリティーを保護するための複数のオプションがあります。
- ノードポートやロードバランサーなどのサービスタイプ
-
IngressやRouteなどの API リソース
デフォルトで、Kubernetes は各 Pod に、Pod 内で実行しているアプリケーションの内部 IP アドレスを割り当てます。Pod とそのコンテナーはネットワーク接続が可能ですが、クラスター外のクライアントにはネットワークアクセスがありません。アプリケーションを外部トラフィックに公開する場合、各 Pod に IP アドレスを割り当てると、ポートの割り当て、ネットワーク、名前の指定、サービス検出、負荷分散、アプリケーション設定、移行などの点で、Pod を物理ホストや仮想マシンのように扱うことができます。
一部のクラウドプラットフォームでは、169.254.169.254 IP アドレスでリッスンするメタデータ API があります。これは、IPv4 169.254.0.0/16 CIDR ブロックのリンクローカル IP アドレスです。
この CIDR ブロックは Pod ネットワークから到達できません。これらの IP アドレスへのアクセスを必要とする Pod には、Pod 仕様の spec.hostNetwork フィールドを true に設定して、ホストのネットワークアクセスが付与される必要があります。
Pod ホストのネットワークアクセスを許可する場合、Pod に基礎となるネットワークインフラストラクチャーへの特権アクセスを付与します。
2.1. OpenShift Container Platform DNS リンクのコピーリンクがクリップボードにコピーされました!
フロントエンドサービスやバックエンドサービスなど、複数のサービスを実行して複数の Pod で使用している場合、フロントエンド Pod がバックエンドサービスと通信できるように、ユーザー名、サービス IP などの環境変数を作成します。サービスが削除され、再作成される場合には、新規の IP アドレスがそのサービスに割り当てられるので、フロントエンド Pod がサービス IP の環境変数の更新された値を取得するには、これを再作成する必要があります。さらに、バックエンドサービスは、フロントエンド Pod を作成する前に作成し、サービス IP が正しく生成され、フロントエンド Pod に環境変数として提供できるようにする必要があります。
そのため、OpenShift Container Platform には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。
2.2. 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 エンドポイントを公開する方法を提供します。
2.2.1. ルートと Ingress の比較 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress Controller を実装します。Ingress トラフィックを管理する最も一般的な方法は Ingress Controller を使用することです。他の通常の Pod と同様にこの Pod をスケーリングし、複製できます。このルーターサービスは、オープンソースのロードバランサーソリューションである HAProxy をベースとしています。
OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress Controller でサポートされない可能性のある高度な機能を提供します。
Ingress トラフィックは、ルートを介してクラスターのサービスにアクセスします。ルートおよび Ingress は、Ingress トラフィックを処理する主要なリソースです。Ingress は、外部要求を受け入れ、ルートに基づいてそれらを委譲するなどのルートと同様の機能を提供します。ただし、Ingress では、特定タイプの接続 (HTTP/2、HTTPS およびサーバー名 ID(SNI)、ならび証明書を使用した TLS のみを許可できます。OpenShift Container Platform では、ルートは、Ingress リソースで指定される各種の条件を満たすために生成されます。
2.3. OpenShift Container Platform ネットワーキングの一般用語集 リンクのコピーリンクがクリップボードにコピーされました!
この用語集では、ネットワーキングコンテンツで使用される一般的な用語を定義します。
- authentication
- OpenShift Container Platform クラスターへのアクセスを制御するために、クラスター管理者はユーザー認証を設定し、承認されたユーザーのみがクラスターにアクセスできます。OpenShift Container Platform クラスターと対話するには、OpenShift Container Platform API に対して認証する必要があります。OpenShift Container Platform API へのリクエストで、OAuth アクセストークンまたは X.509 クライアント証明書を提供することで認証できます。
- AWS Load Balancer Operator
-
AWS Load Balancer (ALB) Operator は、
aws-load-balancer-controllerのインスタンスをデプロイおよび管理します。 - Cluster Network Operator
- Cluster Network Operator (CNO) は、OpenShift Container Platform クラスター内のクラスターネットワークコンポーネントをデプロイおよび管理します。これには、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインのデプロイが含まれます。
- config map
-
config map は、設定データを Pod に注入する方法を提供します。タイプ
ConfigMapのボリューム内の config map に格納されたデータを参照できます。Pod で実行しているアプリケーションは、このデータを使用できます。 - カスタムリソース (CR)
- CR は Kubernetes API の拡張です。カスタムリソースを作成できます。
- DNS
- クラスター DNS は、Kubernetes サービスの DNS レコードを提供する DNS サーバーです。Kubernetes により開始したコンテナーは、DNS 検索にこの DNS サーバーを自動的に含めます。
- DNS Operator
- DNS Operator は、CoreDNS をデプロイして管理し、Pod に名前解決サービスを提供します。これにより、OpenShift Container Platform で DNS ベースの Kubernetes サービス検出が可能になります。
- deployment
- アプリケーションのライフサイクルを維持する Kubernetes リソースオブジェクト。
- domain
- ドメインは、Ingress Controller によってサービスされる DNS 名です。
- Egress
- Pod からのネットワークのアウトバウンドトラフィックを介して外部とデータを共有するプロセス。
- External DNS Operator
- External DNS Operator は、ExternalDNS をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。
- HTTP ベースのルート
- HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
- Ingress
- OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress Controller を実装します。
- Ingress Controller
- Ingress Operator は Ingress Controller を管理します。Ingress Controller の使用は、最も一般的な、OpenShift Container Platform クラスターへの外部アクセスを許可する方法です。
- installer-provisioned infrastructure
- インストールプログラムは、クラスターが実行されるインフラストラクチャーをデプロイして設定します。
- kubelet
- コンテナーが Pod で実行されていることを確認するために、クラスター内の各ノードで実行されるプライマリーノードエージェント。
- Kubernetes NMState Operator
- Kubernetes NMState Operator は、NMState の OpenShift Container Platform クラスターのノード間でステートドリブンのネットワーク設定を実行するための Kubernetes API を提供します。
- kube-proxy
- Kube-proxy は、各ノードで実行するプロキシーサービスであり、外部ホストがサービスを利用できるようにするのに役立ちます。リクエストを正しいコンテナーに転送するのに役立ち、基本的な負荷分散を実行できます。
- ロードバランサー
- OpenShift Container Platform は、ロードバランサーを使用して、クラスターの外部からクラスターで実行されているサービスと通信します。
- MetalLB Operator
-
クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ
LoadBalancerのサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。 - multicast
- IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
- namespaces
- namespace は、すべてのプロセスから見える特定のシステムリソースを分離します。namespace 内では、その namespace のメンバーであるプロセスのみがそれらのリソースを参照できます。
- networking
- OpenShift Container Platform クラスターのネットワーク情報。
- node
- OpenShift Container Platform クラスター内のワーカーマシン。ノードは、仮想マシン (VM) または物理マシンのいずれかです。
- OpenShift Container Platform Ingress Operator
-
Ingress Operator は
IngressControllerAPI を実装し、OpenShift Container Platform サービスへの外部アクセスを可能にするコンポーネントです。 - Pod
- OpenShift Container Platform クラスターで実行されている、ボリュームや IP アドレスなどの共有リソースを持つ 1 つ以上のコンテナー。Pod は、定義、デプロイ、および管理される最小のコンピュート単位です。
- PTP Operator
-
PTP Operator は、
linuxptpサービスを作成し、管理します。 - route
- OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress Controller でサポートされない可能性のある高度な機能を提供します。
- スケーリング
- リソース容量の増減。
- サービス
- 一連の Pod で実行中のアプリケーションを公開します。
- シングルルート I/O 仮想化 (SR-IOV) Network Operator
- Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。
- ソフトウェア定義ネットワーク (SDN)
- OpenShift Container Platform は、Software Defined Networking (SDN) アプローチを使用して、クラスターのネットワークを統合し、OpenShift Container Platform クラスターの Pod 間の通信を可能にします。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
- SCTP (Stream Control Transmission Protocol)
- SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
- taint
- taint と toleration により、Pod が適切なノードに確実にスケジュールされます。ノードに 1 つ以上の taint を適用できます。
- toleration
- Pod に toleration を適用できます。Tolerations を使用すると、スケジューラーは、taint が一致する Pod をスケジュールできます。
- Web コンソール
- OpenShift Container Platform を管理するためのユーザーインターフェイス (UI)。
第3章 ホストへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インスタンスにアクセスして、セキュアシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。
3.1. installer-provisioned infrastructure クラスターでの Amazon Web Services のホストへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。OpenShift Container Platform ホストに対して SSH を実行できるようにするには、以下の手順を実行する必要があります。
手順
-
openshift-installコマンドで作成される Virtual Private Cloud (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。 - インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。
パブリック IP アドレスを、作成した Amazon EC2 インスタンスに関連付けます。
OpenShift Container Platform のインストールとは異なり、作成した Amazon EC2 インスタンスを SSH キーペアに関連付ける必要があります。これにはインターネットを OpenShift Container Platform クラスターの VPC にブリッジ接続するための SSH bastion としてのみの単純な機能しかないため、このインスタンスにどのオペレーティングシステムを選択しても問題ありません。どの Amazon Machine Image (AMI) を使用するかについては、注意が必要です。たとえば、Red Hat Enterprise Linux CoreOS (RHCOS) では、インストーラーと同様に、Ignition でキーを指定することができます。
Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。
注記直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、権限付き Pod を代わりに実行します。
-
oc get nodesを実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名はip-10-0-1-163.ec2.internalに類似したものになります。 Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。
ssh -i <ssh-key-path> core@<master-hostname>
$ ssh -i <ssh-key-path> core@<master-hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 ネットワークダッシュボード リンクのコピーリンクがクリップボードにコピーされました!
ネットワークメトリクスは、OpenShift Container Platform Web コンソール内のダッシュボードから、Observe → Dashboards で表示できます。
4.1. Network Observability Operator リンクのコピーリンクがクリップボードにコピーされました!
Network Observability Operator がインストールされている場合は、Dashboards ドロップダウンリストから Netobserv ダッシュボードを選択すると、ネットワークトラフィックメトリクスダッシュボードが表示されます。この ダッシュボード で利用できるメトリクスの詳細は、ネットワーク可観測性メトリクスのダッシュボード を参照してください。
4.2. ネットワーキングと OVN-Kubernetes ダッシュボード リンクのコピーリンクがクリップボードにコピーされました!
このダッシュボードからは、一般的なネットワークメトリクスと OVN-Kubernetes メトリクスの両方を表示できます。
一般的なネットワークメトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Linux Subsystem Stats を選択します。ダッシュボードから表示できるネットワークメトリクスは、Network Utilisation、Network Saturation、Network Errors です。
OVN-Kubernetes メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Infrastructure を選択します。表示できる OVN-Kuberenetes メトリクスは、Networking Configuration、TCP Latency Probes、Control Plane Resources、Worker Resources です。
4.3. Ingress Operator ダッシュボード リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator によって処理されるネットワークメトリクスをダッシュボードから表示できます。これには、次のようなメトリクスが含まれます。
- 受信および送信の帯域幅
- HTTP エラーレート
- HTTP サーバーの応答遅延
これらの Ingress メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Ingress を選択します。Top 10 Per Route、Top 10 Per Namespace、Top 10 Per Shard のカテゴリーの Ingress メトリクスを表示できます。
第5章 ネットワーク Operator リンクのコピーリンクがクリップボードにコピーされました!
5.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、および OpenStack インストール上の実稼働環境で Kubernetes NMState Operator をサポートします。
OpenShift Container Platform で NMState を使用する前に、Kubernetes NMState Operator をインストールする必要があります。Kubernetes NMState Operator をインストールしたら、次のタスクを完了できます。
- ノードのネットワーク状態と設定の監視と更新
-
カスタマイズされた
br-exブリッジを含むマニフェストオブジェクトの作成。これらのタスクの詳細は、関連情報 セクションを参照してください。
OpenShift Container Platform で NMState を使用する前に、Kubernetes NMState Operator をインストールする必要があります。
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-
ノードで要求されるネットワーク設定を説明します。
NodeNetworkConfigurationPolicyCR をクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。 NodeNetworkConfigurationEnactment- 各ノードに制定されたネットワークポリシーを報告します。
5.1.1. Kubernetes NMState Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
ウェブコンソールまたは CLI を使用して、Kubernetes NMState Operator をインストールできます。
5.1.1.1. Web コンソールを使用した Kubernetes NMState Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して 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 をクリックしてインスタンスを作成します。
概要
完了後に、Operator はすべてのクラスターノードに NMState State Controller をデーモンセットとしてデプロイしています。
5.1.1.2. CLI を使用した Kubernetes NMState Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して、Kubernetes NMState Operator をインストールできます。インストールが完了すると、Operator はすべてのクラスターノードに NMState State Controller をデーモンセットとしてデプロイできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
nmstateOperator namespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstateOperator にサブスクライブします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstateOperator デプロイメントの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.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase kubernetes-nmstate-operator.4.16.0-202210210157 Succeeded
Name Phase kubernetes-nmstate-operator.4.16.0-202210210157 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow nmstateOperator のインスタンスを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow NMState Operator のすべての Pod が
Running状態であることを確認します。oc get pod -n openshift-nmstate
$ oc get pod -n openshift-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Ready Status Restarts Age pod/nmstate-handler-wn55p 1/1 Running 0 77s pod/nmstate-operator-f6bb869b6-v5m92 1/1 Running 0 4m51s ...
Name Ready Status Restarts Age pod/nmstate-handler-wn55p 1/1 Running 0 77s pod/nmstate-operator-f6bb869b6-v5m92 1/1 Running 0 4m51s ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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) がインストールされている。 -
jqCLI ツールがインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
次のコマンドを実行して、
Subcriptionリソースに対する Kubernetes NMState Operator のサブスクリプションを解除します。oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
$ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes NMState Operator に関連付けられている
ClusterServiceVersion(CSV) リソースを見つけます。oc get --namespace openshift-nmstate clusterserviceversion
$ oc get --namespace openshift-nmstate clusterserviceversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow CSV リソースをリストする出力例
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.18.0 Kubernetes NMState Operator 4.18.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE kubernetes-nmstate-operator.v4.18.0 Kubernetes NMState Operator 4.18.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow CSV リソースを削除します。ファイルを削除すると、OLM は Operator 用に作成した
RBACなどの特定リソースを削除します。oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0
$ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
nmstateCR と関連するDeploymentリソースを削除します。oc -n openshift-nmstate delete nmstate nmstate
$ oc -n openshift-nmstate delete nmstate nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete --all deployments --namespace=openshift-nmstate
$ oc delete --all deployments --namespace=openshift-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow nmstateCR を削除した後、console.operator.openshift.io/clusterCR からnmstate-console-pluginコンソールプラグイン名を削除します。次のコマンドを実行して、有効なプラグインのリスト内に存在する
nmstate-console-pluginエントリーの位置を保存します。次のコマンドは、jqCLI ツールを使用して、エントリーのインデックスを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/clusterCR から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.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationenactments.nmstate.io
$ oc delete crd nodenetworkconfigurationenactments.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkstates.nmstate.io
$ oc delete crd nodenetworkstates.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd nodenetworkconfigurationpolicies.nmstate.io
$ oc delete crd nodenetworkconfigurationpolicies.nmstate.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow namespace を削除します。
oc delete namespace kubernetes-nmstate
$ oc delete namespace kubernetes-nmstateCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. AWS Load Balancer Operator リンクのコピーリンクがクリップボードにコピーされました!
5.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 をサポートしていません。
5.2.1.1. AWS Load Balancer Operator 1.2.0 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator バージョン 1.2.0 では、以下のアドバイザリーを利用できます。
5.2.1.1.1. 大きな変更 リンクのコピーリンクがクリップボードにコピーされました!
- このリリースでは、AWS Load Balancer Controller バージョン 2.8.2 がサポートされています。
-
このリリースでは、
Infrastructureリソースで定義されたプラットフォームタグが、コントローラーによって作成されたすべての AWS オブジェクトに追加されるようになりました。
5.2.1.2. AWS Load Balancer Operator 1.1.1 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。
5.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 では、以下のアドバイザリーを利用できます。
5.2.1.3.1. 大きな変更 リンクのコピーリンクがクリップボードにコピーされました!
- このリリースでは、Kubernetes API バージョン 0.27.2 を使用します。
5.2.1.3.2. 新機能 リンクのコピーリンクがクリップボードにコピーされました!
- AWS Load Balancer Operator は、Cloud Credential Operator を使用して標準化された Security Token Service (STS) フローをサポートするようになりました。
5.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 supportedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 現在、AWS Load Balancer Controller は TLS 1.2 を最小 TLS バージョンとして受け入れ、この問題は解決されています。(OCPBUGS-14846)
5.2.1.4. AWS Load Balancer Operator 1.0.1 リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。
5.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 を削除する必要があります。
5.2.1.5.1. 大きな変更 リンクのコピーリンクがクリップボードにコピーされました!
-
このリリースでは、新しい
v1API バージョンを使用しています。
5.2.1.5.2. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
- 以前のバージョンでは、AWS Load Balancer Operator によってプロビジョニングされたコントローラーは、クラスター全体のプロキシー設定を適切に使用しませんでした。これらの設定は、コントローラーに正しく適用されるようになりました。(OCPBUGS-4052、OCPBUGS-5295)
5.2.1.6. 以前のバージョン リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator の最初の 2 つのバージョンは、テクノロジープレビュー機能として利用できます。これらのバージョンは、実稼働クラスターで使用しないでください。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
AWS Load Balancer Operator バージョン 0.2.0 では、以下のアドバイザリーを利用できます。
AWS Load Balancer Operator バージョン 0.0.1 では、以下のアドバイザリーを利用できます。
5.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 をインストールできます。
5.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 を設定しておくようにしてください。
5.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 サービスリソースをサポートします。
手順
次のコマンドを実行して
Subscriptionオブジェクトを作成することにより、OperatorHub からオンデマンドで AWS Load Balancer Operator をデプロイできます。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 出力例
install-zlfbt
install-zlfbtCopy 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 出力例
Complete
CompleteCopy 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-managerCopy 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 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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 つのサブネットを指定する必要があります。
5.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 は、必要なシークレットが作成されて利用可能になるまで待機します。
5.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>です。
5.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 を使用します。
5.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.yamlCopy 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 created1 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 createdCopy 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 文字以下にする必要があります。
5.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.jsonCopy 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:22Z1 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.jsonCopy 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.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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-operatorCopy 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ステータスに移行します。
5.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 を使用します。
5.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.yamlCopy 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 created1 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 createdCopy 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 文字以下にする必要があります。
5.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.jsonCopy 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:22Z1 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.jsonCopy 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.jsonCopy 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です。
5.2.4. AWS Load Balancer Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
AWS Load Balancer Operator は、AWS Load Balancer Controller をデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から AWS Load Balancer Operator をインストールできます。
5.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-operatornamespace を選択します。 Install Operator ページで、次のオプションを選択します。
- Update the channel で stable-v1 を選択します。
- Installation mode で All namespaces on the cluster (default) を選択します。
-
Installed Namespace で
aws-load-balancer-operatorを選択します。aws-load-balancer-operatornamespace が存在しない場合は、Operator のインストール中に作成されます。 - Update approval で Automatic または Manual を選択します。デフォルトでは、Update approval は Automatic に設定されています。Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように更新要求を手動で承認する必要があります。
- Install をクリックします。
検証
- AWS Load Balancer Operator で、インストール済み Operator ダッシュボードの Status が Succeeded と表示されることを確認します。
5.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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Namespaceオブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yamlCopy 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.yamlCopy 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.yamlCopy 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でなければなりません。
5.2.4.3. AWS Load Balancer Controller の作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターにインストールできる AWSLoadBalancerController オブジェクトのインスタンスは 1 つだけです。CLI を使用して AWS Load Balancer Controller を作成できます。AWS Load Balancer Operator は、cluster という名前のリソースのみを調整します。
前提条件
-
echoservernamespace を作成している。 -
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.yamlCopy 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 $HOSTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. AWS Load Balancer Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
5.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-operatornamespace に認証局 (CA) バンドルを含める config map を作成します。oc -n aws-load-balancer-operator create configmap trusted-ca
$ oc -n aws-load-balancer-operator create configmap trusted-caCopy 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=trueCopy 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-caCopy 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-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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
5.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.yamlCopy 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.yamlCopy 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.yamlCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.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 managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. External DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
5.3.1. External DNS Operator のリリースノート リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator は、ExternalDNS をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。
External DNS Operator は、x86_64 アーキテクチャーでのみサポートされます。
これらのリリースノートでは、OpenShift Container Platform での外部 DNS Operator の開発を追跡しています。
5.3.1.1. 外部 DNS Operator 1.2.0 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator バージョン 1.2.0 では、以下のアドバイザリーを利用できます。
5.3.1.1.1. 新機能 リンクのコピーリンクがクリップボードにコピーされました!
- External DNS Operator が AWS 共有 VPC をサポートするようになりました。詳細は、共有 VPC を使用して別の AWS アカウントに DNS レコードを作成する を参照してください。
5.3.1.1.2. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
-
オペランドの更新ストラテジーが、
RollingからRecreateに変更されました。(OCPBUGS-3630)
5.3.1.2. External DNS Operator 1.1.1 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。利用できます。
5.3.1.3. External DNS Operator 1.1.0 リンクのコピーリンクがクリップボードにコピーされました!
このリリースには、アップストリームプロジェクトバージョン 0.13.1 からのオペランドのリベースが含まれていました。External DNS Operator バージョン 1.1.0 では、以下のアドバイザリーを利用できます。
5.3.1.3.1. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
-
以前は、ExternalDNS Operator がボリュームに空の
defaultMode値を強制していたため、OpenShift API との競合により更新が随時行われていました。現在は、defaultMode値は強制されず、オペランドのデプロイは随時更新されなくなりました。(OCPBUGS-2793)
5.3.1.4. External DNS Operator 1.0.1 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。
5.3.1.5. External DNS Operator 1.0.0 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator バージョン 1.0.0 では、以下のアドバイザリーを利用できます。
5.3.1.5.1. バグ修正 リンクのコピーリンクがクリップボードにコピーされました!
- 以前は、External DNS Operator は、ExternalDNS オペランド Pod のデプロイメント中に制限付き SCC ポリシーの違反に関する警告を発していました。この問題は解決されています。(BZ#2086408)
5.3.2. External DNS Operator について リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator は、ExternalDNS をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。
5.3.2.1. External DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator は、olm.openshift.io API グループから External DNS API を実装します。External DNS Operator は、サービス、ルート、外部 DNS プロバイダーを更新します。
前提条件
-
yqCLI ツールがインストールされている。
手順
OperatorHub からオンデマンドで External DNS Operator をデプロイできます。External DNS Operator をデプロイすると、Subscription オブジェクトが作成されます。
次のコマンドを実行して、インストールプランの名前を確認します。
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 出力例
install-zcvlr
install-zcvlrCopy 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 出力例
Complete
CompleteCopy 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-operatorCopy 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 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.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"
5.3.3. External DNS Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
AWS、Azure、GCP などのクラウドプロバイダーに External DNS Operator をインストールできます。
5.3.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-operatornamespace を選択します。 - 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 と表示されることを確認します。
5.3.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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Namespaceオブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yamlCopy 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.yamlCopy 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.yamlCopy 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-operatorPod のステータスがRunningであることを確認します。oc -n external-dns-operator get pod
$ oc -n external-dns-operator get podCopy 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 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サブスクリプションのカタログソースが
redhat-operatorsであることを確認します。oc -n external-dns-operator get subscription
$ oc -n external-dns-operator get subscriptionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PACKAGE SOURCE CHANNEL external-dns-operator external-dns-operator redhat-operators stable-v1
NAME PACKAGE SOURCE CHANNEL external-dns-operator external-dns-operator redhat-operators stable-v1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
external-dns-operatorのバージョンを確認します。oc -n external-dns-operator get csv
$ oc -n external-dns-operator get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE external-dns-operator.v<1.y.z> ExternalDNS Operator <1.y.z> Succeeded
NAME DISPLAY VERSION REPLACES PHASE external-dns-operator.v<1.y.z> ExternalDNS Operator <1.y.z> SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.4. External DNS Operator の設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator には、次の設定パラメーターがあります。
5.3.4.1. External DNS Operator の設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator には、次の設定パラメーターがあります。
| パラメーター | 説明 |
|---|---|
|
| クラウドプロバイダーのタイプを有効にします。 |
|
|
ドメインごとに DNS ゾーンを指定できます。ゾーンを指定しない場合、 zones: - "myzoneid"
|
|
|
ドメインごとに AWS ゾーンを指定できます。ドメインを指定しない場合、 |
|
|
DNS レコードのソース (
|
5.3.5. AWS での DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、AWS および AWS GovCloud で DNS レコードを作成できます。
5.3.5.1. Red Hat External DNS Operator を使用した AWS のパブリックホストゾーンへの DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat External DNS Operator を使用して、AWS のパブリックホストゾーンに DNS レコードを作成できます。同じ手順を使用して、AWS GovCloud のホストゾーンに DNS レコードを作成できます。
手順
ユーザーを確認してください。ユーザーは、
kube-systemnamespace にアクセスできる必要があります。クレデンシャルがない場合は、kube-systemnamespace からクレデンシャルを取得すると、クラウドプロバイダークライアントを使用できます。oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow kube-systemnamespace に存在する 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_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_secret_access_key}} | base64 -d)$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_access_key_id}} | 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 consoleCopy 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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow DNS ゾーンのリストを取得して、以前に検出されたルートのドメインに対応するものを検索します。
aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.supportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5Copy 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 consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.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 -1Copy 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-rol1Copy 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.supportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5Copy 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-consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.6. Azure での DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、Azure 上に DNS レコードを作成できます。
Microsoft Entra Workload ID 対応クラスターまたは Microsoft Azure Government (MAG) リージョンで実行されるクラスターで External DNS Operator を使用することはサポートされていません。
5.3.6.1. Azure のパブリック DNS ゾーン上で DNS レコードを作成する リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、Azure のパブリック DNS ゾーンに DNS レコードを作成できます。
前提条件
- 管理者権限を持っている。
-
adminユーザーの場合、kube-systemnamespace にアクセスできる。
手順
クラウドプロバイダークライアントを使用するために、次のコマンドを実行して
kube-systemnamespace から認証情報を取得します。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 consoleCopy 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 NoneCopy 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 consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記プライベート Azure DNS のホストされたプライベートゾーンにレコードを作成するには、
zonesフィールドの下にプライベートゾーンを指定する必要があります。これにより、プロバイダータイプがExternalDNS引数のazure-private-dnsに入力されます。
5.3.7. GCP での DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、Google Cloud Platform (GCP) 上に DNS レコードを作成できます。
GCP Workload Identity が有効なクラスターで External DNS Operator を使用することはサポートされていません。GCP Workload Identity の詳細は、GCP Workload Identity を参照してください。
5.3.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.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Google の認証情報をエクスポートします。
export GOOGLE_CREDENTIALS=decoded-gcloud.json
$ export GOOGLE_CREDENTIALS=decoded-gcloud.jsonCopy 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.jsonCopy 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 consoleCopy 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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マネージドゾーンのリストを取得します。
gcloud dns managed-zones list | grep test.gcp.example.com
$ gcloud dns managed-zones list | grep test.gcp.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
qe-cvs4g-private-zone test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.comCopy 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 consoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.8. Infoblox での DNS レコードの作成 リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を使用して、Infoblox 上に DNS レコードを作成できます。
5.3.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 consoleCopy 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 NoneCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Infoblox UI から、
consoleルート用に作成された DNS レコードを確認します。- Data Management → DNS → Zones をクリックします。
- ゾーン名を選択します。
5.3.9. External DNS Operator でクラスター全体のプロキシーを設定する リンクのコピーリンクがクリップボードにコピーされました!
クラスター全体のプロキシーを設定した後、Operator Lifecycle Manager (OLM) はデプロイされたすべての Operator に対して、HTTP_PROXY、HTTPS_PROXY、および NO_PROXY 環境変数の新しい内容の自動更新をトリガーします。
5.3.9.1. クラスター全体のプロキシーの認証局を信頼する リンクのコピーリンクがクリップボードにコピーされました!
External DNS Operator を設定して、クラスター全体のプロキシーの認証局を信頼できます。
手順
次のコマンドを実行して、
external-dns-operatornamespace に CA バンドルを含める config map を作成します。oc -n external-dns-operator create configmap trusted-ca
$ oc -n external-dns-operator create configmap trusted-caCopy 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=trueCopy 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デプロイメントに追加されていることを確認します。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_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
trusted-ca
trusted-caCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. MetalLB Operator リンクのコピーリンクがクリップボードにコピーされました!
5.4.1. MetalLB および MetalLB Operator について リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ LoadBalancer のサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。外部 IP アドレスがクラスターのホストネットワークに追加されます。
5.4.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.4.1.2. MetalLB Operator カスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
MetalLB Operator は、次のカスタムリソースについて独自の namespace を監視します。
MetalLB-
MetalLBカスタムリソースをクラスターに追加する際に、MetalLB Operator は MetalLB をクラスターにデプロイします。Operator はカスタムリソースの単一インスタンスのみをサポートします。インスタンスが削除されると、Operator はクラスターから MetalLB を削除します。 IPAddressPoolMetalLB には、タイプ
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.4.1.3. MetalLB ソフトウェアコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
MetalLB Operator のインストール時に、metallb-operator-controller-manager デプロイメントは Pod を起動します。Pod は Operator の実装です。Pod は、関連するすべてのリソースへの変更を監視します。
Operator が MetalLB のインスタンスを起動すると、controller デプロイメントと speaker のデーモンセットが開始します。
MetalLB カスタムリソースでデプロイメント仕様を設定して、controller および speaker Pod がクラスターへのデプロイおよび実行方法を管理できます。これらの展開仕様の詳細は、関連情報 セクションを参照してください。
controllerOperator はデプロイメントおよび単一の Pod を起動します。
LoadBalancerタイプのサービスを追加する場合、Kubernetes はcontrollerを使用してアドレスプールから IP アドレスを割り当てます。サービスに障害が発生した場合は、controllerPod のログに次のエントリーがあることを確認します。出力例
"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 controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow speakerOperator は、
speakerPod 用に設定されたデーモンを起動します。デフォルトでは、Pod はクラスター内の各ノードで起動されます。MetalLB の起動時にMetalLBカスタムリソースでノードセレクターを指定して、Pod を特定のノードに制限できます。controllerがサービスに IP アドレスを割り当てても、サービスがまだ利用できない場合は、speakerPod のログを確認してください。スピーカーPod が使用できない場合は、oc describe pod -nコマンドを実行します。レイヤー 2 モードの場合には、
controllerがサービスに IP アドレスを割り当てた後に、speakerPod はアルゴリズムを使用して、どのノードの、どのspeakerPod がロードバランサーの 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.4.1.4. MetalLB と外部トラフィックポリシー リンクのコピーリンクがクリップボードにコピーされました!
レイヤー 2 モードでは、クラスター内のノードはサービス IP アドレスのすべてのトラフィックを受信します。BGP モードでは、ホストネットワーク上のルーターが、新しいクライアントが接続を確立できるように、クラスター内のノードの 1 つに接続を開きます。クラスターがノードに入った後にトラフィックを処理する方法は、外部トラフィックポリシーの影響を受けます。
clusterこれは
spec.externalTrafficPolicyのデフォルト値です。clusterトラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックをサービスのすべての Pod に分散します。このポリシーは、Pod 全体に均一なトラフィック分散を提供しますが、クライアントの IP アドレスを覆い隠し、トラフィックがクライアントではなくノードから発信されているように Pod 内のアプリケーションに表示される可能性があります。locallocalトラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックを同じノードの Pod にのみ送信します。たとえば、ノード A のspeakerPod が外部サービス 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.4.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 を起動します。 -
各
speakerPod はホストネットワーク化された Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。 -
ノード 1 の
speakerPod は ARP を使用して、サービスの外部 IP アドレスに192.168.100.200を認識します。外部 IP アドレスをアナウンスするspeakerPod は、サービスのエンドポイントと同じノード上にあり、エンドポイントはReady状態である必要があります。 クライアントトラフィックはホストネットワークにルーティングされ、
192.168.100.200の IP アドレスに接続します。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。-
サービスの外部トラフィックポリシーが
clusterに設定されている場合、speakerPod が実行されているノードから192.168.100.200ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。 -
サービスの外部トラフィックポリシーが
localに設定されている場合、speakerPod が実行されているノードと少なくとも 1 つのサービスエンドポイントから192.168.100.200ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 1 または 3 のいずれかが192.168.100.200をアドバタイズします。
-
サービスの外部トラフィックポリシーが
-
ノード 1 が利用できない場合、外部 IP アドレスは別のノードにフェイルオーバーします。アプリケーション Pod およびサービスエンドポイントのインスタンスを持つ別のノードでは、
speakerPod は外部 IP アドレス192.168.100.200になり、新規ノードがクライアントトラフィックを受信します。図では、唯一の候補はノード 3 です。
5.4.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 を設定して、speakerPod を実行するノードを指定できます。 -
各
speakerPod はホストネットワーク化された Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。 -
各
speakerPod は、すべての BGP ピアとの BGP セッションを開始し、ロードバランサーの IP アドレスまたは集約されたルートを BGP ピアにアドバタイズします。speakerPod は、Autonomous System 65010 の一部であることをアドバタイズします。この図ではルーター R1 を示しており、これは同じ Autonomous System 内の BGP ピアです。ただし、他の Autonomous System に属するピアとの BGP セッションを開始するように MetalLB を設定できます。 ノードに、ロードバランサーの IP アドレスをアドバタイズする
speakerPod がある場合にはすべて、サービスのトラフィックを受信できます。-
サービスの外部トラフィックポリシーが
clusterに設定されている場合、スピーカー Pod が実行されているすべてのノードが203.0.113.200ロードバランサーの IP アドレスをアドバタイズし、speakerPod を持つすべてのノードがサービスのトラフィックを受信できます。ホストの接頭辞は、外部トラフィックポリシーが cluster に設定されている場合にのみ、ルーターピアにアドバタイズされます。 -
サービスの外部トラフィックポリシーが
localに設定されている場合、speakerPod が実行されているノードとサービスが実行されている少なくとも 1 つのエンドポイントが、203.0.113.200ロードバランサーの IP アドレスをアドバタイズできます。これらのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 2 と 3 は203.0.113.200をアドバタイズします。
-
サービスの外部トラフィックポリシーが
-
BGP ピアカスタムリソースの追加時にノードセレクターを指定して、特定の BGP ピアとの BGP セッションを開始する
speakerPod を制御するように MetalLB を設定できます。 - BGP を使用するように設定されている R1 などのルーターは、BGP ピアとして設定できます。
- クライアントトラフィックは、ホストネットワーク上のノードの 1 つにルーティングされます。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。
- ノードが使用できなくなった場合に、ルーターは障害を検出し、別のノードとの新しい接続を開始します。BGP ピアに双方向フォワーディング検出 (BFD) プロファイルを使用するように MetalLB を設定できます。BFD は、リンク障害検出がより高速であるため、ルーターは BFD がない場合よりも早く新しい接続を開始できます。
5.4.1.7. 制限および制限 リンクのコピーリンクがクリップボードにコピーされました!
5.4.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®
MetalLB Operator および MetalLB は、OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーでサポートされます。
5.4.1.7.2. レイヤー 2 モードの制限 リンクのコピーリンクがクリップボードにコピーされました!
5.4.1.7.2.1. 単一ノードのボトルネック リンクのコピーリンクがクリップボードにコピーされました!
MetalLB は、1 つのノードを介してサービス内のすべてのトラフィックをルーティングします。この際、ノードはボトルネックとなり、パフォーマンスを制限する可能性があります。
レイヤー 2 モードは、サービスの Ingress 帯域幅を単一ノードの帯域幅に制限します。これは、ARP および NDP を使用してトラフィックを転送するための基本的な制限です。
5.4.1.7.2.2. フェイルオーバーのパフォーマンスの低下 リンクのコピーリンクがクリップボードにコピーされました!
ノード間のフェイルオーバーは、クライアントからの操作によって異なります。フェイルオーバーが発生すると、MetalLB は Gratuitous ARP パケットを送信して、サービス IP に関連付けられた MAC アドレスが変更されたことをクライアントに通知します。
ほとんどのクライアントオペレーティングシステムは、Gratuitous ARP パケットを正しく処理し、隣接キャッシュを迅速に更新します。クライアントがキャッシュを迅速に更新すると、フェイルオーバーは数秒以内に完了します。通常、クライアントは新しいノードに 10 秒以内にフェイルオーバーします。しかし、一部のクライアントオペレーティングシステムは Gratuitous ARP パケットをまったく処理しないか、キャッシュの更新を遅延させる古い実装があります。
Windows、macOS、Linux などの一般的なオペレーティングシステムの新しいバージョンは、レイヤー 2 フェイルオーバーを正しく実装します。フェイルオーバーが遅いという問題は、古くてあまり一般的ではないクライアントオペレーティングシステムを除いて、予期されていません。
古いクライアントで予定されているフェイルオーバーの影響を最小限にするには、リーダーシップをフラップした後に、古いノードを数分にわたって実行したままにします。古いノードは、キャッシュが更新されるまで、古いクライアントのトラフィックを転送することができます。
予定外のフェイルオーバー時に、古いクライアントがキャッシュエントリーを更新するまでサービス IP に到達できません。
5.4.1.7.2.3. 追加ネットワークと MetalLB は同じネットワークを使用できない リンクのコピーリンクがクリップボードにコピーされました!
MetalLB とソース Pod 上に設定された追加のネットワークインターフェイスの両方に同じ VLAN を使用すると、接続エラーが発生する可能性があります。これは、MetalLB IP とソース Pod が同じノード上に存在する場合に発生します。
接続エラーを回避するには、ソース Pod が存在するサブネットとは異なるサブネットに MetalLB IP を配置します。この設定により、ソース Pod からのトラフィックがデフォルトゲートウェイを経由するようになります。その結果、トラフィックは OVN オーバーレイネットワークを使用して宛先に到達でき、接続が確実に意図したとおりに機能するようになります。
5.4.1.7.3. BGP モードの制限 リンクのコピーリンクがクリップボードにコピーされました!
5.4.1.7.3.1. ノードに障害が発生すると、アクティブなすべての接続が切断される可能性があります リンクのコピーリンクがクリップボードにコピーされました!
MetalLB には、BGP ベースのロードバランシングに共通する制限があります。ノードに障害が発生した場合や speaker Pod が再起動した場合など、BGP セッションが中断されると、すべてのアクティブな接続がリセットされる可能性があります。エンドユーザーに、Connection reset by peer のメッセージが表示される可能性があります。
BGP セッションが中断された場合にどうなるかは、各ルーターの製造元の実装によります。ただし、speaker Pod の数を変更すると、BGP セッションの数に影響し、BGP ピアとのアクティブな接続が切断されることが予想されます。
サービスの中断の可能性を回避または低減するために、BGP ピアの追加時にノードセレクターを指定できます。BGP セッションを開始するノードの数を制限すると、BGP セッションのないノードでの障害が発生しても、サービスへの接続に影響はありません。
5.4.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.4.2. MetalLB Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、MetalLB Operator を追加して、クラスター上の MetalLB インスタンスのライフサイクルを Operator によって管理できます。
MetalLB および IP フェイルオーバーは互換性がありません。クラスターの IP フェイルオーバーを設定している場合、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行します。
5.4.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.4.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-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE metallb-operator 14m
NAME AGE metallb-operator 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow SubscriptionCR を作成します。SubscriptionCR を定義し、YAML ファイルを保存します (例:metallb-sub.yaml)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
redhat-operators値を指定する必要があります。
SubscriptionCR を作成するには、次のコマンドを実行します。oc create -f metallb-sub.yaml
$ oc create -f metallb-sub.yamlCopy 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-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.16.0-nnnnnnnnnnnn Automatic true
NAME CSV APPROVAL APPROVED install-wzg94 metallb-operator.4.16.0-nnnnnnnnnnnn Automatic trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Operator のインストールには数秒かかる場合があります。
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
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.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase metallb-operator.4.16.0-nnnnnnnnnnnn Succeeded
Name Phase metallb-operator.4.16.0-nnnnnnnnnnnn SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.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 controllerCopy 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 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow スピーカーに設定されているデーモンが実行されていることを検証します。
oc get daemonset -n metallb-system speaker
$ oc get daemonset -n metallb-system speakerCopy 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 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力例は、6 つの speaker Pod を示しています。クラスターの speaker Pod の数は出力例とは異なる場合があります。出力で各ノードの 1 つの Pod が表示されることを確認します。
5.4.2.4. MetalLB のデプロイメント仕様 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB カスタムリソースを使用して MetalLB のインスタンスを起動すると、MetalLB カスタムリソースでデプロイメント仕様を設定して、controller または speaker Pod がクラスターにデプロイし、実行する方法を管理できます。これらのデプロイメント仕様を使用して、以下のタスクを管理します。
- MetalLB Pod デプロイメントのノードの選択
- Pod の優先順位および Pod のアフィニティーを使用したケジューリングの管理
- MetalLB Pod の CPU 制限の割り当て
- MetalLB Pod のコンテナー RuntimeClass の割り当て
- MetalLB Pod のメタデータの割り当て
5.4.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-systemspeaker コマンドを使用して Operator がデプロイした Pod の数を確認できます。同様に、oc get nodes -l node-role.kubernetes.io/worker= のようなコマンドを使用して、ラベルに一致するノードを表示できます。
オプションで、アフィニティールールを使用して、ノードがどの speaker Pod をスケジュールするか、スケジュールしないかを制御することができます。また、toleration の一覧を適用してこれらの Pod を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。
5.4.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: 1000000Copy to Clipboard Copied! Toggle word wrap Toggle overflow PriorityClassカスタムリソース設定を適用します。oc apply -f myPriorityClass.yaml
$ oc apply -f myPriorityClass.yamlCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
metallb-systemnamespace の 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.priorityClassNameCopy 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-priorityCopy 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-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.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カスタムリソースファイルを作成し、コントローラーおよびspeakerPod のcpu値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MetalLBカスタムリソース設定を適用します。oc apply -f CPULimits.yaml
$ oc apply -f CPULimits.yamlCopy 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.4.2.6. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
5.4.3. MetalLB Operator のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで namespace を metallb-system にサブスクライブする Subscription カスタムリソース (CR) は、installPlanApproval パラメーターを Automatic に自動的に設定します。そのため、Red Hat が提供する Operator カタログに MetalLB Operator の新しいバージョンが含まれている場合、その MetalLB Operator は自動的にアップグレードされます。
MetalLB Operator のアップグレードを手動で制御する必要がある場合は、installPlanApproval パラメーターを Manual に設定します。
5.4.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-systemnamespace 内のmetallb-operatorサブスクリプションの YAML 定義を取得します。oc -n metallb-system get subscription metallb-operator -o yaml
$ oc -n metallb-system get subscription metallb-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow installPlanApprovalパラメーターをManualに設定して、SubscriptionCR を編集します。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 csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE metallb-operator.v4.16.0 MetalLB Operator 4.16.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE metallb-operator.v4.16.0 MetalLB Operator 4.16.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、namespace に存在するインストールプランを確認します。
oc -n metallb-system get installplan
$ oc -n metallb-system get installplanCopy to Clipboard Copied! Toggle word wrap Toggle overflow 手動インストールプランとして install-tsz2g が表示された出力例
NAME CSV APPROVAL APPROVED install-shpmd metallb-operator.v4.16.0-202502261233 Automatic true install-tsz2g metallb-operator.v4.16.0-202503102139 Manual false
NAME CSV APPROVAL APPROVED install-shpmd metallb-operator.v4.16.0-202502261233 Automatic true install-tsz2g metallb-operator.v4.16.0-202503102139 Manual falseCopy 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-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターでインストールプランを開いた状態で、
spec.approvalパラメーターをManualに設定し、spec.approvedパラメーターをtrueに設定します。注記インストールプランを編集すると、アップグレード操作が開始します。アップグレード操作中に
oc -n metallb-system get csvコマンドを入力すると、出力にReplacingまたはPendingステータスが表示される場合があります。
検証
次のコマンドを入力して、アップグレードが成功したことを確認します。
oc -n metallb-system get csv
$ oc -n metallb-system get csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACE PHASE metallb-operator.v4.<latest>.0-202503102139 MetalLB Operator 4.16.0-202503102139 metallb-operator.v4.16.0-202502261233 Succeeded
NAME DISPLAY VERSION REPLACE PHASE metallb-operator.v4.<latest>.0-202503102139 MetalLB Operator 4.16.0-202503102139 metallb-operator.v4.16.0-202502261233 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.3.2. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
5.5. OpenShift Container Platform における Cluster Network Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) を使用すると、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインを含む、OpenShift Container Platform クラスター上のクラスターネットワークコンポーネントをデプロイおよび管理できます。
5.5.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-operatorCopy 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 56mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
oc get clusteroperator/network
$ oc get clusteroperator/networkCopy 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 50mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のフィールドは、Operator のステータス (
AVAILABLE、PROGRESSING、およびDEGRADED) に関する情報を提供します。AVAILABLEフィールドは、Cluster Network Operator が Available ステータス条件を報告する場合にTrueになります。
5.5.2. クラスターネットワーク設定の表示 リンクのコピーリンクがクリップボードにコピーされました!
すべての新規 OpenShift Container Platform インストールには、cluster という名前の network.config オブジェクトがあります。
手順
oc describeコマンドを使用して、クラスターネットワーク設定を表示します。oc describe network.config/cluster
$ oc describe network.config/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.3. Cluster Network Operator のステータス表示 リンクのコピーリンクがクリップボードにコピーされました!
oc describe コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。
手順
以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
oc describe clusteroperators/network
$ oc describe clusteroperators/networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、既存のネットワーク設定を変更します。
oc edit network.operator cluster
$ oc edit network.operator clusterCopy 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 networkCopy 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この変更を元に戻す必要がある場合は、このパラメーターのもう 1 つの有効なオプションである
Restrictedを設定します。デフォルトではRestrictedに設定されており、グローバル IP アドレス転送は無効です。
5.5.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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.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 アドレス範囲のみ変更できます。デフォルトのネットワークタイプは、移行時に OpenShift SDN から OVN-Kubernetes にのみ変更できます。
defaultNetwork オブジェクトのフィールドを cluster という名前の CNO オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
5.5.6.1. Cluster Network Operator 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNO オブジェクトの名前。この名前は常に |
|
|
| Pod IP アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 |
|
|
| サービスの IP アドレスのブロック。OpenShift SDN および 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 ネットワークプラグインを使用します。OpenShift SDN は、新しいクラスターのインストールの選択肢として利用できなくなりました。 |
|
|
| このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。 |
OpenShift SDN ネットワークプラグインの設定
以下の表では、OpenShift SDN ネットワークプラグインの設定フィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| OpenShift SDN のネットワーク分離モード。 |
|
|
| VXLAN オーバーレイネットワークの最大転送単位 (MTU)。通常、この値は自動的に設定されます。 |
|
|
|
すべての VXLAN パケットに使用するポート。デフォルト値は |
OpenShift SDN 設定の例
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 アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| IPsec 実装の動作を指定します。次の値のいずれかである必要があります。
|
クラスターのインストール中にのみクラスターネットワークプラグインの設定を変更できます。ただし、インストール後のアクティビティーとして実行時に変更できる gatewayConfig フィールドは除きます。
IPSec が有効な OVN-Kubernetes 設定の例
OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。
kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)
kubeProxyConfig オブジェクトの値は以下の表で定義されます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
|
kubeProxyConfig:
proxyArguments:
iptables-min-sync-period:
- 0s
|
5.5.6.2. Cluster Network Operator の設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、詳細な CNO 設定が指定されています。
Cluster Network Operator オブジェクトのサンプル
5.6. OpenShift Container Platform の DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の DNS Operator は、CoreDNS インスタンスをデプロイおよび管理して、クラスター内の Pod に名前解決サービスを提供し、DNS ベースの Kubernetes Service 検出を有効にし、内部の cluster.local 名を解決します。
5.6.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-operatorCopy 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 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc getコマンドを使用して DNS Operator の状態を表示します。oc get clusteroperator/dns
$ oc get clusteroperator/dnsCopy 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 92mCopy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE、PROGRESSING、およびDEGRADEDは、Operator のステータスに関する情報を示します。AVAILABLEがTrueになるのは、CoreDNS デーモンセットの 1 つ以上の Pod がAVAILABLEステータス条件を報告し、DNS サービスがクラスター IP アドレスを持っている場合です。
5.6.2. デフォルト DNS の表示 リンクのコピーリンクがクリップボードにコピーされました!
すべての新規 OpenShift Container Platform インストールには、default という名前の dns.operator があります。
手順
oc describeコマンドを使用してデフォルトのdnsを表示します。oc describe dns.operator/default
$ oc describe dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターのサービス CIDR 範囲を確認するには、
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 出力例
[172.30.0.0/16]
[172.30.0.0/16]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.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/defaultCopy 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 です。
5.6.4. DNS Operator のステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
oc describe コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。
手順
DNS Operator のステータスを表示します。
oc describe clusteroperators/dns
$ oc describe clusteroperators/dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow メッセージとスペルはリリースによって異なる場合がありますが、期待されるステータス出力は次のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.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=mergeCopy 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=mergeCopy 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 yamlCopy 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
5.6.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 です。
5.6.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=mergeCopy 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
結果の変更を確認するには、次のコマンドを入力します。
oc get dnses.operator -A -oyaml
$ oc get dnses.operator -A -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 2 つのログレベルのエントリーが表示されるはずです。
operatorLogLevelは OpenShift DNS Operator の問題に適用され、logLevelは CoreDNS Pod のデーモンセットに適用されます。logLevel: Trace operatorLogLevel: Debug
logLevel: Trace operatorLogLevel: DebugCopy to Clipboard Copied! Toggle word wrap Toggle overflow デーモンセットのログを確認するには、次のコマンドを入力します。
oc logs -n openshift-dns ds/dns-default
$ oc logs -n openshift-dns ds/dns-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.9. CoreDNS キャッシュのチューニング リンクのコピーリンクがクリップボードにコピーされました!
CoreDNS の場合、成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間をチューニングすると、アップストリーム DNS リゾルバーの負荷を軽減できます。
TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。
手順
次のコマンドを実行して、
defaultという名前の DNS Operator オブジェクトを編集します。oc edit dns.operator.openshift.io/default
$ oc edit dns.operator.openshift.io/defaultCopy 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 yamlCopy 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
5.6.10. 高度なタスク リンクのコピーリンクがクリップボードにコピーされました!
5.6.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 出力例
"Unmanaged"
"Unmanaged"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
managementState が Unmanaged に設定されている間はアップグレードできません。
5.6.10.2. DNS Pod 配置の制御 リンクのコピーリンクがクリップボードにコピーされました!
DNS Operator には 2 つのデーモンセットがあります。1 つは CoreDNS 用の dns-default という名前のデーモンセットで、もう 1 つは /etc/hosts ファイルの管理用の node-resolver という名前のデーモンセットです。
場合によっては、どのノードに CoreDNS Pod を割り当てて実行するかを制御する必要があります (ただし、これは一般的な操作ではありません)。たとえば、クラスター管理者がノードのペア間の通信を禁止できるセキュリティーポリシーを設定している場合、CoreDNS のデーモンセットが実行されるノードのセットを制限する必要があります。DNS Pod がクラスター内の一部のノードで実行されており、DNS Pod が実行されていないノードから DNS Pod が実行されているノードへのネットワーク接続がある場合、すべての Pod で DNS サービスが利用可能になります。
node-resolver デーモンセットは、すべてのノードホストで実行する必要があります。このデーモンセットにより、イメージのプルをサポートするクラスターイメージレジストリーのエントリーが追加されるためです。node-resolver Pod には、1 つのジョブのみがあります。コンテナーランタイムがサービス名を解決できるように、image-registry.openshift-image-registry.svc サービスのクラスター IP アドレスを検索し、それをノードホストの /etc/hosts に追加するジョブです。
クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。
前提条件
-
ocCLI がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
DNS Operator の
managementStateがManagedに設定されている。
手順
CoreDNS のデーモンセットを特定のノードで実行できるようにするために、taint と toleration を設定します。
defaultという名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow taint の taint キーおよび toleration を指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- taint が
dns-onlyである場合、それは無制限に許容できます。tolerationSecondsは省略できます。
5.6.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/defaultCopy 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 yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow TLS 転送の例に基づく DNS ConfigMap のサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
forwardPluginへの変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。
5.7. OpenShift Container Platform の Ingress Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は IngressController API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。
5.7.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 エンドポイントを公開する方法を提供します。
5.7.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リソースのデフォルトホストを生成する際にも使用されます。
5.7.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 ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを |
5.7.3.1. Ingress Controller の TLS セキュリティープロファイル リンクのコピーリンクがクリップボードにコピーされました!
TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。
5.7.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 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。
5.7.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プロジェクトのIngressControllerCR を編集して、TLS セキュリティープロファイルを設定します。oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.tlsSecurityProfileフィールドを追加します。CustomプロファイルのサンプルIngressControllerCRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。
検証
IngressControllerCR にプロファイルが設定されていることを確認します。oc describe IngressController default -n openshift-ingress-operator
$ oc describe IngressController default -n openshift-ingress-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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.crlIssuer: 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.crlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
openshift-confignamespace で、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-configCopy 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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.clientTLSフィールドおよびサブフィールドを追加して相互 TLS を設定します。フィルタリングパターンを指定する
clientTLSプロファイルのサンプルIngressControllerCRCopy 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
5.7.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/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.5. Ingress Operator ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator のステータスを表示し、検査することができます。
手順
Ingress Operator ステータスを表示します。
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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
5.7.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
5.7.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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9. Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
5.7.9.1. カスタムデフォルト証明書の設定 リンクのコピーリンクがクリップボードにコピーされました!
管理者として、Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress Controller がカスタム証明書を使用するように設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
証明書が以下の要件を満たしている必要があります。
- 証明書が Ingress ドメインに対して有効化されている必要があります。
-
証明書は拡張を使用して、
subjectAltName拡張を使用して、*.apps.ocp4.example.comなどのワイルドカードドメインを指定します。
IngressControllerCR がなければなりません。デフォルトの CR を使用できます。oc --namespace openshift-ingress-operator get ingresscontrollers
$ oc --namespace openshift-ingress-operator get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE default 10m
NAME AGE default 10mCopy 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-ingressnamespace に作成します。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.keyCopy 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 -enddateCopy 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 GMCopy 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 のデプロイメントを更新します。
5.7.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 -enddateCopy 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 GMTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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 thanosCopy 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-operatornamespace 内で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.yamlCopy 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-operatorCopy 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 thanosCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記引数
add-cluster-role-to-userは、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とするkube-metricsnamespace からのクエリーを使用します。デフォルトの Ingress Controller デプロイメントをターゲットにする新しい
ScaledObjectYAML ファイル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.yamlCopy 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 出力例
replicas: 3
replicas: 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-ingressプロジェクトで Pod を取得します。oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingressCopy 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 66sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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 出力例
2
2Copy 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ingresscontroller.operator.openshift.io/default patched
ingresscontroller.operator.openshift.io/default patchedCopy 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 出力例
3
3Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 異なる数のレプリカが必要な場合は
replicas値を変更します。
5.7.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を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Containerspec.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 logsCopy 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
5.7.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を随時高い値に設定します。
5.7.9.7. 内部ロードバランサーを使用するための Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController の scope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。
図5.2 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.yaml1 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 ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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/defaultCopy 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 yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力では、グローバルアクセスがアノテーション
networking.gke.io/internal-load-balancer-allow-global-accessで GCP について有効にされていることを示しています。
5.7.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を使用します
5.7.9.10. クラスターを内部に配置するためのデフォルト Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController の scope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
defaultIngress Controller を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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=mergeCopy 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
5.7.9.12. ワイルドカードルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。
Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressControllerリソースを編集します。oc edit IngressController
$ oc edit IngressControllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow specの下で、wildcardPolicyフィールドをWildcardsDisallowedまたはWildcardsAllowedに設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedspec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.9.13. HTTP ヘッダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。
IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。
5.7.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 またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。
5.7.9.13.2. 特殊なケースのヘッダー リンクのコピーリンクがクリップボードにコピーされました!
次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。
| ヘッダー名 | IngressController 仕様を使用して設定可能かどうか | Route 仕様を使用して設定可能かどうか | 不許可の理由 | 別の方法で設定可能かどうか |
|---|---|---|---|---|
|
| いいえ | いいえ |
| いいえ |
|
| いいえ | はい |
| いいえ |
|
| いいえ | いいえ |
|
はい: |
|
| いいえ | いいえ | HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。 | はい:
|
5.7.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/defaultCopy 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コンバーターを使用できます。- 変更を適用するためにファイルを保存します。
5.7.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 IngressControllerCopy 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アノテーションをルートごとに設定できます。
5.7.9.16. Ingress Controller での HTTP/2 の有効化および無効化 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy で透過的なエンドツーエンドの HTTP/2 接続を有効化または無効化できます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。
個別の Ingress Controller またはクラスター全体について、HTTP/2 接続を有効化または無効化できます。
クライアントから HAProxy への接続について HTTP/2 の使用を有効にするために、ルートはカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。
HAProxy からアプリケーション Pod への接続は、re-encrypt ルートのみに HTTP/2 を使用でき、edge-terminated ルートまたは非セキュアなルートには使用しません。この制限は、HAProxy が TLS 拡張である Application-Level Protocol Negotiation (ALPN) を使用してバックエンドで HTTP/2 の使用をネゴシエートするためにあります。そのため、エンドツーエンドの HTTP/2 はパススルーおよび re-encrypt で使用できますが、edge-terminated ルートでは使用できません。
Ingress Controller の HTTP/2 が有効か無効かに関係なく、安全でないルートで HTTP/2 を使用できます。
パススルー以外のルートの場合、Ingress Controller はクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。つまり、クライアントが Ingress Controller に接続して HTTP/1.1 をネゴシエートし、Ingress Controller は次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress Controller は WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。
5.7.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=true1 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=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
または、次の YAML コードを適用して HTTP/2 を有効化できます。
5.7.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=false1 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=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
または、次の YAML コードを適用して HTTP/2 を無効化できます。
5.7.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/defaultCopy 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
5.7.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 yamlCopy 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がローリング更新を終了するのを待機します。ルートを公開します。
oc expose service hello-openshift
$ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
oc get routes
$ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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 に設定します。
5.7.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/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow specで、httpCompressionポリシーフィールドをmimeTypesに設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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-ingressCopy 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 11hCopy 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/statsUsernameCopy 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/statsPasswordCopy 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>/metricsCopy 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 -kCopy 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>/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.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;csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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.httpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。
Ingress Controller にパッチを適用し、名前を指定して
my-custom-error-code-pagesconfig 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Operator は、
openshift-confignamespace からopenshift-ingressnamespace にmy-custom-error-code-pagesconfig map をコピーします。Operator は、openshift-ingressnamespace のパターン<your_ingresscontroller_name>-errorpagesに従って config map に名前を付けます。コピーを表示します。
oc get cm default-errorpages -n openshift-ingress
$ oc get cm default-errorpages -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DATA AGE default-errorpages 2 25s
NAME DATA AGE default-errorpages 2 25s1 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.httpCopy 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.httpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
カスタムエラーコード HTTP 応答を確認します。
テストプロジェクトおよびアプリケーションを作成します。
oc new-project test-ingress
$ oc new-project test-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-app django-psql-example
$ oc new-app django-psql-exampleCopy 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 errorfileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.7.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 設定パラメーター」セクションの表を参照してください。
5.8. OpenShift Container Platform の Ingress Node Firewall Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall Operator は、OpenShift Container Platform でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。
5.8.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 を実行する必要があります。
5.8.2. Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。
5.8.2.1. CLI を使用した Ingress Node Firewall Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者権限を持つアカウントがある。
手順
openshift-ingress-node-firewallnamespace を作成するには、次のコマンドを入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成するには、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Node Firewall Operator にサブスクライブします。
Ingress Node Firewall Operator の
SubscriptionCR を作成するには、次のコマンドを入力します。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-firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.16.0-202211122336 Automatic true
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.16.0-202211122336 Automatic trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Operator のバージョンを確認するには、次のコマンドを入力します。
oc get csv -n openshift-ingress-node-firewall
$ oc get csv -n openshift-ingress-node-firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.16.0-202211122336 Ingress Node Firewall Operator 4.16.0-202211122336 ingress-node-firewall.4.16.0-202211102047 Succeeded
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.16.0-202211122336 Ingress Node Firewall Operator 4.16.0-202211122336 ingress-node-firewall.4.16.0-202211102047 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.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=managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記単一ノードの OpenShift クラスターの場合、
openshift-ingress-node-firewallnamespace にはworkload.openshift.io/allowed=managementアノテーションが必要です。
5.8.3. Ingress Node Firewall Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Ingress Node Firewall Operator がインストールされます。
手順
Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。
-
ingressnodefirewallconfigという名前のopenshift-ingress-node-firewallnamespace 内にIngressNodeFirewallConfigを作成します。 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。
oc apply -f rule.yaml
$ oc apply -f rule.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.3.1. Ingress ノードファイアウォール設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は |
|
|
|
Ingress Firewall Operator CR オブジェクトの namespace。 |
|
|
| 指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。 spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
注記
デーモンセットを開始するには、 |
Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。
Ingress Node Firewall Operator の設定例
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォール設定オブジェクトの例
Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。
5.8.3.2. Ingress ノードファイアウォールルールオブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| CR オブジェクトの名前。 |
|
|
|
このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、 |
|
|
|
|
|
|
|
|
Ingress オブジェクトの設定
ingress オブジェクトの値は、次の表で定義されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。 注記
異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の |
|
|
|
Ingress ファイアウォール
注記 Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。 |
Ingress ノードファイアウォールルールオブジェクトの例
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォールの設定例
- 1
- <label_name> と <label_value> はノード上に存在する必要があり、
ingressfirewallconfigCR を実行するノードに適用されるnodeselectorラベルと値に一致する必要があります。<label_value> は、trueまたはfalseです。nodeSelectorラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfigCR の使用に異なるルールを適用できます。
ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例
ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。
次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。
次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。
ゼロトラストの Ingress ノードファイアウォールルールの例
5.8.4. Ingress Node Firewall Operator ルールの表示 リンクのコピーリンクがクリップボードにコピーされました!
手順
次のコマンドを実行して、現在のルールをすべて表示します。
oc get ingressnodefirewall
$ oc get ingressnodefirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 返された
<resource>名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。oc get <resource> <name> -o yaml
$ oc get <resource> <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.8.5. Ingress Node Firewall Operator のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。
oc get crds | grep ingressnodefirewall
$ oc get crds | grep ingressnodefirewallCopy 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:00ZCopy 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-firewallCopy 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 5d21hCopy 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_firewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow ログは、
/sos_commands/ebpfにある eBPFbpftool出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。
5.9. SR-IOV Operator リンクのコピーリンクがクリップボードにコピーされました!
5.9.1. SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。
5.9.1.1. SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して、Single Root I/O Virtualization (SR-IOV) Network Operator をインストールできます。
5.9.1.1.1. CLI: SR-IOV Network Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つアカウントがある。
手順
次のコマンドを入力して、
openshift-sriov-network-operatornamespace を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
OperatorGroupカスタムリソース (CR) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、SR-IOV Network Operator の
SubscriptionCR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
SriovoperatorConfigリソースを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、Operator がインストールされていることを確認します。
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.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase sriov-network-operator.4.16.0-202406131906 Succeeded
Name Phase sriov-network-operator.4.16.0-202406131906 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.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=managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シングルノード OpenShift クラスターの場合は、namespace にアノテーション
workload.openshift.io/allowed=managementが必要です。
5.9.1.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
5.9.2. SR-IOV Network Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。
5.9.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-injectorPod が実行されなくなります。推奨設定はtrueです。- 3
enableOperatorWebhookフィールドは、CR で指定されていないか、明示的に true に設定されていない場合、デフォルトでfalseまたは<none>に設定されます。その場合、namespace でoperator-webhookPod が実行されなくなります。推奨設定はtrueです。
次のコマンドを実行して、リソースを作成します。
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.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 メトリクスを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは |
5.9.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
5.9.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
5.9.2.1.4. SR-IOV Network Operator Admission Controller Webhook について リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator Admission Controller Webbook は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。
-
作成時または更新時の
SriovNetworkNodePolicyCR の検証 -
CR の作成または更新時の
priorityおよびdeviceTypeフィールドのデフォルト値の設定によるSriovNetworkNodePolicyCR の変更
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
5.9.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
5.9.2.1.6. カスタムノードセレクターについて リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。
5.9.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
5.9.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
5.9.2.1.9. Hosted Control Plane 用の SR-IOV Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
AWS プラットフォーム上の Hosted Control Plane は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ホスティングサービスクラスターを設定してデプロイすると、ホストされたクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。
前提条件
AWS 上でホストされたクラスターを設定およびデプロイしている。詳細は、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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.16.0-202211021237 SR-IOV Network Operator 4.16.0-202211021237 sriov-network-operator.4.16.0-202210290517 Succeeded
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.16.0-202211021237 SR-IOV Network Operator 4.16.0-202211021237 sriov-network-operator.4.16.0-202210290517 SucceededCopy 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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.9.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
5.9.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=trueCopy 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-operatorCopy 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 5d22hCopy to Clipboard Copied! Toggle word wrap Toggle overflow sriov-network-metrics-exporterPod はREADY状態である必要があります。- オプション: OpenShift Container Platform Web コンソールを使用して、SR-IOV Virtual Function (VF) メトリクスを調べます。詳細は、「メトリクスのクエリー」を参照してください。
5.9.2.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
5.9.3. SR-IOV Network Operator のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator をアンインストールするには、実行中の SR-IOV ワークロードをすべて削除し、Operator をアンインストールして、Operator が使用した Webhook を削除する必要があります。
5.9.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 --allCopy 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 --allCopy 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 --allCopy 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.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io
$ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovnetworks.sriovnetwork.openshift.io
$ oc delete crd sriovnetworks.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io
$ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Webhook を削除します。
oc delete mutatingwebhookconfigurations network-resources-injector-config
$ oc delete mutatingwebhookconfigurations network-resources-injector-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete MutatingWebhookConfiguration sriov-operator-webhook-config
$ oc delete MutatingWebhookConfiguration sriov-operator-webhook-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config
$ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-configCopy 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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 ネットワークセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
6.1. ネットワークポリシー API について リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes は、ネットワークセキュリティーの強化に使用できる 2 つの機能を提供します。機能の 1 つは、ユーザーによるネットワークポリシーの適用を可能にする NetworkPolicy API です。これは主にアプリケーション開発者と namespace テナント向けの機能で、namespace スコープのポリシーを作成して namespace を保護することを目的としています。
2 番目の機能は AdminNetworkPolicy で、AdminNetworkPolicy (ANP) API と BaselineAdminNetworkPolicy (BANP) API の 2 つの API で構成されています。ANP と BANP は、クラスターおよびネットワーク管理者向けの機能で、クラスタースコープのポリシーを作成してクラスター全体を保護することを目的としています。クラスター管理者は、ANP を使用すると、NetworkPolicy オブジェクトよりも優先されるオーバーライド不可能なポリシーを適用できます。BANP を使用すると、NetworkPolicy オブジェクトを使用して必要に応じてユーザーがオーバーライドできるオプションのクラスタースコープのネットワークポリシールールをセットアップおよび適用できます。ANP、BANP、およびネットワークポリシーを一緒に使用すると、管理者がクラスターのセキュリティー保護に使用できる完全なマルチテナント分離を実現できます。
OpenShift Container Platform の OVN-Kubernetes CNI は、アクセス制御リスト (ACL) の階層を使用してこれらのネットワークポリシーを実装し、それらを評価して適用します。ACL は、階層 1 から階層 3 まで降順で評価されます。
階層 1 では AdminNetworkPolicy (ANP) オブジェクトを評価します。階層 2 では NetworkPolicy オブジェクトを評価します。階層 3 では BaselineAdminNetworkPolicy (BANP) オブジェクトを評価します。
最初に ANP が評価されます。一致が ANP allow または deny ルールである場合、クラスター内の既存の NetworkPolicy および BaselineAdminNetworkPolicy (BANP) オブジェクトは評価からスキップされます。一致が ANP の pass ルールの場合、評価が ACL 階層 1 から階層 2 に進み、そこで NetworkPolicy ポリシーが評価されます。トラフィックに一致する NetworkPolicy がない場合、評価は Tier 2 ACL から Tier 3 ACL に移動し、そこで BANP が評価されます。
6.1.1. AdminNetworkPolicy と NetworkPolicy カスタムリソースの主な違い リンクのコピーリンクがクリップボードにコピーされました!
次の表は、クラスタースコープの AdminNetworkPolicy API と namespace スコープの NetworkPolicy API の主な違いを説明しています。
| ポリシーの要素 | AdminNetworkPolicy | NetworkPolicy |
|---|---|---|
| 対象ユーザー | クラスター管理者または同等の権限 | namespace の所有者 |
| スコープ | クラスター | namespace |
| トラフィックのドロップ |
明示的な |
ポリシー作成時に暗黙的に |
| トラフィックの委譲 |
| 該当なし |
| トラフィックの許可 |
明示的に | すべてのルールに対するデフォルトのアクションは allow です。 |
| ポリシー内のルールの優先順位 | ANP 内で表示される順序によって異なります。ルールの位置が高いほど、優先順位が高くなります。 | ルールは追加できます。 |
| ポリシーの優先順位 |
ANP 間では、 | ポリシー間にポリシー順序はありません。 |
| 機能の優先順位 | 最初に Tier 1 ACL を介して評価され、最後に BANP が Tier 3 ACL を介して評価されます。 | ANP の後、BANP の前に適用され、ACL の Tier 2 で評価されます。 |
| Pod 選択の一致 | namespace 間で異なるルールを適用できます。 | 1 つの namespace 内の Pod に異なるルールを適用できます。 |
| クラスターの Egress トラフィック |
|
受け入れられた CIDR 構文とともに |
| クラスター Ingress トラフィック | サポート対象外 | サポート対象外 |
| 完全修飾ドメイン名 (FQDN) ピアサポート | サポート対象外 | サポート対象外 |
| namespace セレクター |
|
|
6.2. 管理ネットワークポリシー リンクのコピーリンクがクリップボードにコピーされました!
6.2.1. OVN-Kubernetes AdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
6.2.1.1. AdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy (ANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、namespace を作成する前にネットワークポリシーを作成することで、ANP を使用してネットワークを保護できます。さらに、NetworkPolicy オブジェクトによってオーバーライドできないネットワークポリシーをクラスタースコープのレベルで作成できます。
AdminNetworkPolicy オブジェクトと NetworkPolicy オブジェクトの主な違いは、前者は管理者用でクラスタースコープであるのに対し、後者はテナント所有者用で namespace スコープであることです。
ANP を使用すると、管理者は以下を指定できます。
-
評価の順序を決定する
priority値。値が小さいほど優先度が高くなります。 - ポリシーが適用される namespace のセットまたは namespace で構成される Pod のセット。
-
subjectへのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subjectからのすべての Egress トラフィックに適用される Egress ルールのリスト。
AdminNetworkPolicy の例
例6.1 ANP の YAML ファイルの例
- 1
- ANP の名前を指定します。
- 2
spec.priorityフィールドは、0 - 99の値を受け入れ、クラスター内で最大 100 個の ANP をサポートします。範囲は最低値から最高値の順に読み取られるため、値が低いほど優先度が高くなります。同じ優先度で ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が意図したものになるように、異なる優先度で ANP を設定してください。- 3
- ANP リソースを適用する namespace を指定します。
- 4
- ANP には Ingress ルールと Egress ルールの両方があります。
spec.ingressフィールドの ANP ルールは、actionフィールドのPass、Deny、およびAllowの値を受け入れます。 - 5
ingress.nameの名前を指定します。- 6
namespaceSelector.matchLabelsによって選択された namespace 内の Pod を Ingress ピアとして選択するには、podSelector.matchLabelsを指定します。- 7
- ANP には、Ingress と Egress ルールの両方があります。
spec.egressフィールドの ANP ルールは、actionフィールドのPass、Deny、およびAllowの値を受け入れます。
6.2.1.1.1. ルールの AdminNetworkPolicy アクション リンクのコピーリンクがクリップボードにコピーされました!
管理者は、AdminNetworkPolicy ルールの action フィールドに Allow、Deny、または Pass を設定できます。OVN-Kubernetes は階層型 ACL を使用してネットワークトラフィックルールを評価するため、ANP を使用すると、非常に強力なポリシールールを設定できます。このポリシールールを変更するには、管理者がルールを変更、削除するか、より高い優先度のルールを設定してオーバーライドする必要があります。
AdminNetworkPolicy の Allow の例
優先度 9 で定義されている次の ANP は、monitoring namespace からクラスター内の任意のテナント (他のすべての namespace) への Ingress トラフィックをすべて許可します。
例6.2 強力な Allow ANP の YAML ファイルの例
これは、関係者全員がオーバーライドできない強力な Allow ANP の例です。テナントは、NetworkPolicy オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。
AdminNetworkPolicy の Deny の例
優先度 5 で定義されている次の ANP は、monitoring namespace から制限付きテナント (security: restricted ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。
例6.3 強力な Deny ANP の YAML ファイルの例
これは、関係者全員がオーバーライドできない強力な Deny ANP です。制限付きテナントの所有者は、トラフィックの監視を許可する権限を自分自身に付与できません。また、インフラストラクチャーの監視サービスは、これらの機密性の高い namespace から何も収集できません。
強力な Allow の例と組み合わせると、block-monitoring ANP の優先度の値よりも Allow の優先度の値のほうが高いため、制限付きテナントが監視されなくなります。
AdminNetworkPolicy の Pass の例
優先度 7 で定義されている次の ANP は、monitoring namespace から内部インフラストラクチャーテナント (security: internal ラベルを持つ namespace) への Ingress トラフィックをすべて ACL の階層 2 に渡し、トラフィックが namespace の NetworkPolicy オブジェクトによって評価されるようにします。
例6.4 強力な Pass ANP の YAML ファイルの例
この例は、テナント所有者によって定義された NetworkPolicy オブジェクトに決定を委譲する強力な Pass アクション ANP です。この pass-monitoring ANP により、internal セキュリティーレベルでグループ化されたすべてのテナント所有者は、インフラストラクチャーの監視サービスによって namespace スコープの NetworkPolicy オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。
6.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
6.2.2.1. BaselineAdminNetworkPolicy リンクのコピーリンクがクリップボードにコピーされました!
BaselineAdminNetworkPolicy (BANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、BANP を使用すると、NetworkPolicy オブジェクトを使用してユーザーが必要に応じてオーバーライドできるオプションのベースラインネットワークポリシールールを設定および適用できます。BANP のルールアクションは、allow または deny です。
BaselineAdminNetworkPolicy リソースは、クラスターのシングルトンオブジェクトであり、渡されたトラフィックポリシーがクラスター内のどの NetworkPolicy オブジェクトにも一致しない場合にガードレールポリシーとして使用できます。BANP は、クラスター内トラフィックをデフォルトでブロックするガードレールを提供するデフォルトのセキュリティーモデルとしても使用できます。その場合、ユーザーが NetworkPolicy オブジェクトを使用して既知のトラフィックを許可する必要があります。BANP リソースを作成するときは、名前として default を使用する必要があります。
BANP を使用すると、管理者は以下を指定できます。
-
一連の namespace または namespace で構成される
subject。 -
subjectへのすべての Ingress トラフィックに適用される Ingress ルールのリスト。 -
subjectからのすべての Egress トラフィックに適用される Egress ルールのリスト。
BaselineAdminNetworkPolicy の例
例6.5 BANP の YAML ファイルの例
- 1
- BANP はシングルトンオブジェクトであるため、ポリシー名は
defaultにする必要があります。 - 2
- ANP を適用する namespace を指定します。
- 3
- BANP には Ingress ルールと Egress ルールの両方があります。
spec.ingressフィールドとspec.egressフィールドの BANP ルールは、actionフィールドのDenyとAllowの値を受け入れます。 - 4
ingress.nameの名前を指定します。- 5
- BANP リソースを適用する Pod の選択元の namespace を指定します。
- 6
- BANP リソースを適用する Pod の
podSelector.matchLabels名を指定します。
BaselineAdminNetworkPolicy の Deny の例
次の BANP シングルトンは、internal セキュリティーレベルのテナントに着信するすべての Ingress 監視トラフィックに対してデフォルトの拒否ポリシーを設定します。「AdminNetworkPolicy の Pass の例」と組み合わせると、この拒否ポリシーは、ANP pass-monitoring ポリシーによって渡されるすべての Ingress トラフィックに対するガードレールポリシーとして機能します。
例6.6 Deny ガードレールルールの YAML ファイルの例
action フィールドに Pass 値を指定した AdminNetworkPolicy リソースを BaselineAdminNetworkPolicy リソースと組み合わせて使用すると、マルチテナントポリシーを作成できます。このマルチテナントポリシーを使用すると、あるテナントのアプリケーションの監視データを収集しながら、別のテナントのデータを収集しないことが可能になります。
管理者が「AdminNetworkPolicy の Pass アクションの例」と「BaselineAdminNetwork Policy の Deny の例」の両方を適用すると、BANP の前に評価される NetworkPolicy リソースを作成するかどうかをテナントが選択できるようになります。
たとえば、テナント 1 が Ingress トラフィックを監視する次の NetworkPolicy リソースを設定したとします。
例6.7 NetworkPolicy の例
この場合、テナント 1 のポリシーは、「AdminNetworkPolicy の Pass アクションの例」の後、security レベルが internal のテナントに着信する Ingress 監視トラフィックをすべて拒否する「BaselineAdminNetworkPolicy の Deny の例」の前に評価されます。テナント 1 の NetworkPolicy オブジェクトを設定すると、テナント 1 はアプリケーションのデータを収集できるようになります。一方、NetworkPolicy オブジェクトが設定されていないテナント 2 は、データを収集できません。管理者はデフォルトでは内部のテナントを監視していませんでした。その代わりに BANP を作成し、テナントが NetworkPolicy オブジェクトを使用して BANP のデフォルト動作をオーバーライドできるようにしました。
6.2.3. ANP と BANP の監視 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy および BaselineAdminNetworkPolicy リソースには、ポリシーの監視と管理に使用できるメトリクスがあります。メトリクスの詳細は、以下の表を参照してください。
6.2.3.1. AdminNetworkPolicy のメトリクス リンクのコピーリンクがクリップボードにコピーされました!
| 名前 | 説明 | 詳細 |
|---|---|---|
|
| 該当なし |
クラスター内の |
|
| 該当なし |
クラスター内の |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.2.4. AdminNetworkPolicy の Egress ノードとネットワークピア リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、nodes と networks のピアを説明します。管理者は、このセクションの例を使用して、クラスター内のノースバウンドトラフィックを制御するための AdminNetworkPolicy と BaselineAdminNetworkPolicy を設計できます。
6.2.4.1. AdminNetworkPolicy および BaselineAdminNetworkPolicy のノースバウンドトラフィック制御 リンクのコピーリンクがクリップボードにコピーされました!
ANP と BANP では、East-West トラフィック制御のサポートに加えて、管理者がクラスターから出るノースバウンドトラフィックや、ノードからクラスター内の他のノードに向かうトラフィックを制御することもできます。エンドユーザーは次のことができます。
-
nodesEgress ピアを使用してクラスターノードへの Egress トラフィック制御を実装する -
nodesまたはnetworksの Egress ピアを使用して Kubernetes API サーバーへの Egress トラフィック制御を実装する -
networksピアを使用してクラスター外の外部宛先への Egress トラフィック制御を実装する
ANP および BANP の場合、nodes と networks のピアは Egress ルールに対してのみ指定できます。
6.2.4.1.1. ノードピアを使用してクラスターノードへの Egress トラフィックを制御する リンクのコピーリンクがクリップボードにコピーされました!
nodes ピアを使用すると、管理者は Pod からクラスター内のノードへの Egress トラフィックを制御できます。この利点は、クラスターにノードを追加したり、クラスターからノードを削除したりするときにポリシーを変更する必要がないことです。
次の例では、ノードセレクターピアを使用して、restricted、confidential、または internal レベルのセキュリティーを持つ任意の namespace によるポート 6443 上の Kubernetes API サーバーへの Egress トラフィックを許可します。また、セキュリティーレベルが restricted、confidential、または internal のいずれかである namespace からクラスター内のすべてのワーカーノードへのトラフィックも拒否します。
例6.8 nodes ピアを使用した ANP Allow Egress の例
6.2.4.1.2. ネットワークピアを使用して外部の宛先への Egress トラフィックを制御する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、networks ピアで CIDR 範囲を使用し、Pod から networks フィールドで指定された CIDR 範囲内の IP アドレスで設定された宛先に送信される Egress トラフィックを制御するポリシーを適用できます。
以下の例では、networks ピアを使用し、ANP ポリシーと BANP ポリシーを組み合わせて出力トラフィックを制限します。
ANP および BANP の namespace フィールドで空のセレクター ({}) を使用する場合は注意が必要です。空のセレクターを使用する場合は、OpenShift namespace も選択します。
ANP または BANP Deny ルールで 0.0.0.0/0 の値を使用する場合は、Deny を 0.0.0.0/0 に設定する前に、必要な宛先に優先度の高い ANP Allow ルールを設定する必要があります。
例6.9 networks ピアを使用した ANP と BANP の例
network-as-egress-peer ANP と、networks ピアを使用する networks の BANP を組み合わせると、次の Egress ポリシーが適用されます。
- すべての Pod が、リストされた IP アドレスの外部 DNS サーバーと通信できない。
- すべての Pod が、会社のイントラネットの残りの部分と通信できる。
- すべての Pod が、他の Pod、ノード、およびサービスと通信できる。
-
どの Pod もインターネットと通信できない。最後の ANP
Passルールと強力な BANPDenyルールを組み合わせることで、クラスター内のトラフィックを保護するガードレールポリシーが作成されます。
6.2.4.1.3. ノードピアとネットワークピアを一緒に使用する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ANP および BANP ポリシーで nodes と networks ピアを組み合わせることができます。
例6.10 nodes と networks ピアの例
6.2.5. AdminNetworkPolicy のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
6.2.5.1. ANP の作成の確認 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy (ANP) と BaselineAdminNetworkPolicy (BANP) が正しく作成されていることを確認するには、oc describe anp または oc describe banp のコマンドのステータス出力を確認します。
ステータスが良好な場合は、OVN DB plumbing was successful および SetupSucceeded と表示されます。
例6.11 正常なステータスの ANP の例
設定が失敗した場合、それぞれのゾーンコントローラーからエラーが報告されます。
例6.12 不正なステータスとエラーメッセージを含む ANP の例
失敗したポリシーのトラブルシューティングに役立つ nbctl コマンドについては、次のセクションを参照してください。
6.2.5.1.1. ANP および BANP への nbctl コマンドの使用 リンクのコピーリンクがクリップボードにコピーされました!
失敗したセットアップのトラブルシューティングを行うには、まず ACL、AdressSet、Port_Group などの OVN Northbound データベース (nbdb) オブジェクトを確認します。nbdb を表示するには、そのノードの Pod 内にいて、そのノードのデータベース内のオブジェクトを表示する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
クラスターで ovn nbctl コマンドを実行するには、関連するノード上の `nbdb` にリモートシェルを起動する必要があります。
出力を生成するために次のポリシーが使用されました。
例6.13 出力の生成に使用される AdminNetworkPolicy
手順
次のコマンドを実行して、ノード情報を含む Pod をリスト表示します。
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ACL nbdb を確認するには、次のコマンドを実行します。
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。, cluster-control
-
トラブルシューティングする
AdminNetworkPolicyの名前を指定します。 - AdminNetworkPolicy
-
AdminNetworkPolicyまたはBaselineAdminNetworkPolicyのタイプを指定します。
例6.14 ACL の出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ingress および Egress の出力には、ACL のポリシーのロジックが表示されます。たとえば、パケットが指定された
matchと一致するたびにactionが実行されます。次のコマンドを実行して、ルールの特定の ACL を調べます。
ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。,
cluster-control -
ANP の
名前を指定します。 Ingress-
トラフィックの
方向をIngressまたはEgressのいずれかのタイプで指定します。 1- 確認するルールを指定します。
priority34のcluster-controlという名前の ANP の例では、Ingressrule1 の出力例は次のとおりです。例6.15 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 詳細は以下のようになります。,
nbdb 内のアドレスセットを確認するには、次のコマンドを実行します。
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.16
Address_Setの出力例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルールの特定のアドレスセットを調べます。
ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.17
Address_Setの出力例_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059_uuid : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72 addresses : ["0.0.0.0/0"] external_ids : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a11452480169090787059Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、nbdb 内のポートグループを確認します。
ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'$ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例6.18
Port_Groupの出力例_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]_uuid : f50acf71-7488-4b9a-b7b8-c8a024e99d21 acls : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd] external_ids : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy} name : a14645450421485494999 ports : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.6. AdminNetworkPolicy のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、AdminNetworkPolicy および BaselineAdminNetworkPolicy リソースのベストプラクティスを説明します。
6.2.6.1. AdminNetworkPolicy の設計 リンクのコピーリンクがクリップボードにコピーされました!
AdminNetworkPolicy (ANP) リソースを構築する場合は、ポリシーを作成するときに次の点を考慮する必要があります。
- 同じ優先度を持つ ANP を作成できます。同じ優先度で 2 つの ANP を作成する場合は、重複するルールが同じトラフィックに適用されないようにしてください。値ごとに 1 つのルールのみが適用されます。同じ優先度の値が複数ある場合は、どのルールが適用されるか保証されません。重複する ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が明確に定義されるように、異なる優先度で ANP を設定してください。
- 管理者は、システム namespace ではなくユーザー namespace に適用される ANP を作成する必要があります。
ANP および BaselineAdminNetworkPolicy (BANP) をシステム namespace (default、kube-system、名前が openshift- で始まる namespace など) に適用することはサポートされていないため、クラスターが応答しなくなり、機能しない状態になる可能性があります。
-
サポートされている優先度の範囲は
0 - 100であるため、30 - 70のような中間の範囲を使用するように ANP を設計することもできます。これにより、前後の優先順位のためのプレースホルダーが残ります。中間の範囲でも、インフラストラクチャーの要件が時間の経過とともに進化するにつれて、適切な優先度レベルで必要なときに新しい ANP を挿入できるように、ギャップを残しておくことを推奨します。ANP をパックすると、将来の変更に対応するために、それらをすべて再作成しないといけない場合があります。 -
0.0.0.0/0または::/0を使用して強力なDenyポリシーを作成する場合は、重要なトラフィックに対して優先度の高いAllowまたはPassルールがあることを確認してください。 -
どのような場合でも接続が許可されるようにしたい場合は、
actionフィールドとしてAllowを使用します。ANP のAllowルールは、接続が常に許可され、NetworkPolicyが無視されることを意味します。 -
接続を許可または拒否するポリシー決定を
NetworkPolicyレイヤーに委任するには、actionフィールドにPassを使用します。 - 複数のルールにわたるセレクターが重複しないようにして、同じ IP が複数のポリシーに表示されないようにします。これにより、パフォーマンスとスケールの制限が発生する可能性があります。
-
namedPortsをPortNumberおよびPortRangeと組み合わせて使用することは避けてください。これにより 6 つの ACL が作成され、クラスターの効率が低下します。
6.2.6.1.1. BaselineAdminNetworkPolicy の使用に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内で定義できる
BaselineAdminNetworkPolicy(BANP) リソースは 1 つだけです。以下は、管理者が BANP を設計する際に考慮する可能性がある、BANP でサポートされている用途です。-
ユーザー namespace 内のクラスターローカル Ingress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可したい Ingress トラフィックを許可するために
NetworkPolicyオブジェクトを追加する必要があり、Ingress 用のネットワークポリシーを追加しないとトラフィックが拒否されます。 -
ユーザー namespace のクラスターローカル Egress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可する Egress トラフィックを許可するために
NetworkPolicyオブジェクトを追加する必要があり、ネットワークポリシーを追加しないとトラフィックが拒否されます。 -
クラスター内 DNS サービスへの Egress に対してデフォルトの許可ポリシーを設定できます。このような BANP により、namespace のユーザーは、クラスター内 DNS サービスへの許可 Egress
NetworkPolicyを設定する必要がなくなります。 -
すべての Pod への内部 Egress トラフィックを許可し、すべての外部エンドポイント (つまり
0.0.0.0/0および::/0) へのアクセスを拒否する Egress ポリシーを設定できます。この BANP により、ユーザーワークロードは他のクラスター内エンドポイントにトラフィックを送信できますが、デフォルトでは外部エンドポイントには送信できません。開発者はNetworkPolicyを使用して、アプリケーションが明示的な外部サービスセットにトラフィックを送信できるようにすることができます。
-
ユーザー namespace 内のクラスターローカル Ingress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可したい Ingress トラフィックを許可するために
-
BANP のスコープを設定し、システム namespace ではなくユーザー namespace へのトラフィックのみを拒否するようにしてください。これは、システム namespace に BANP をオーバーライドする
NetworkPolicyオブジェクトがないためです。
6.2.6.1.2. AdminNetworkPolicy と NetworkPolicy の考慮すべき相違点 リンクのコピーリンクがクリップボードにコピーされました!
-
NetworkPolicyオブジェクトとは異なり、誤ってトラフィックが選択されることを避けるために、空の ({}) キャッチオールセレクターを使用するのではなく、明示的なラベルを使用して ANP および BANP 内のワークロードを参照する必要があります。
インフラストラクチャー namespace に空の namespace セレクターを適用すると、クラスターが応答しなくなり、機能しない状態になる可能性があります。
-
ANP の API セマンティクスでは、暗黙的な拒否を持つ
NetworkPolicyオブジェクトとは異なり、ポリシーを作成するときに許可または拒否のルールを明示的に定義する必要があります。 -
NetworkPolicyオブジェクトとは異なり、AdminNetworkPolicyオブジェクトの Ingress ルールはクラスター内の Pod と namespace に制限されているため、ホストネットワークからの Ingress のルールを設定することはできず、また設定する必要もありません。
6.3. ネットワークポリシー リンクのコピーリンクがクリップボードにコピーされました!
6.3.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。
6.3.1.1. ネットワークポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes ネットワークポリシーをサポートするネットワークプラグインを使用するクラスターでは、ネットワーク分離は NetworkPolicy オブジェクトによって完全に制御されます。OpenShift Container Platform 4.16 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。
- ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワーク化された Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。
-
podSelectorフィールドを{}に設定せずにnamespaceSelectorフィールドを使用すると、hostNetworkPod が含まれません。ネットワークポリシーの作成時にhostNetworkPod をターゲットにするには、namespaceSelectorフィールドでpodSelectorを{}に設定して使用する必要があります。 - ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。
デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。
Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。
ネットワークポリシーは、Transmission Control Protocol (TCP)、User Datagram Protocol (UDP)、Internet Control Message Protocol (ICMP)、および Stream Control Transmission Protocol (SCTP) プロトコルにのみ適用されます。他のプロトコルは影響を受けません。
以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。
すべてのトラフィックを拒否します。
プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform Ingress Controller からの接続のみを許可します。
プロジェクトで OpenShift Container Platform Ingress Controller からの接続のみを許可するには、以下の
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロジェクト内の Pod からの接続のみを受け入れます。
重要同じ namespace 内の
hostNetworkPod からの Ingress 接続を許可するには、allow-from-hostnetworkポリシーとallow-same-namespaceポリシーを一緒に適用する必要があります。Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の
NetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。
特定のラベル (以下の例の
role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様のNetworkPolicyオブジェクトを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace および Pod セレクターの両方を使用して接続を受け入れます。
namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の
NetworkPolicyオブジェクトを使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。
6.3.1.1.1. allow-from-router ネットワークポリシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
次の NetworkPolicy を使用して、ルーターの設定に関係なく外部トラフィックを許可します。
- 1
policy-group.network.openshift.io/ingress:""ラベルは、OpenShift-SDN と OVN-Kubernetes の両方をサポートします。
6.3.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
次の allow-from-hostnetwork NetworkPolicy オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。
6.3.1.2. OpenShift SDN を使用したネットワークポリシー最適化 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークポリシーを使用して、namespace 内でラベルで相互に区別される Pod を分離します。
NetworkPolicy オブジェクトを単一 namespace 内の多数の個別 Pod に適用することは効率的ではありません。Pod ラベルは IP レベルには存在しないため、ネットワークポリシーは、podSelector で選択されるすべての Pod 間のすべてのリンクに関する別個の Open vSwitch (OVS) フロールールを生成します。
たとえば、仕様の podSelector および NetworkPolicy オブジェクト内の Ingress podSelector のそれぞれが 200 Pod に一致する場合、40,000 (200*200) OVS フロールールが生成されます。これにより、ノードの速度が低下する可能性があります。
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
namespace を使用して分離する必要のある Pod のグループを組み込み、OVS フロールールの数を減らします。
namespace 全体を選択する
NetworkPolicyオブジェクトは、namespaceSelectorまたは空のpodSelectorを使用して、namespace の VXLAN 仮想ネットワーク ID (VNID) に一致する単一の OVS フロールールのみを生成します。- 分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なる namespace に移します。
- 追加のターゲット設定された namespace 間のネットワークポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。
6.3.1.3. OVN-Kubernetes ネットワークプラグインによるネットワークポリシーの最適化 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。
-
同じ
spec.podSelector仕様を持つネットワークポリシーの場合、ingressルールまたはegressルールを持つ複数のネットワークポリシーを使用するよりも、複数のIngressルールまたはegressルールを持つ 1 つのネットワークポリシーを使用する方が効率的です。 podSelectorまたはnamespaceSelector仕様に基づくすべてのIngressまたはegressルールは、number of pods selected by network policy + number of pods selected by ingress or egress ruleに比例する数の OVS フローを生成します。そのため、Pod ごとに個別のルールを作成するのではなく、1 つのルールで必要な数の Pod を選択できるpodSelectorまたはnamespaceSelector仕様を使用することが推奨されます。たとえば、以下のポリシーには 2 つのルールが含まれています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同じガイドラインが
spec.podSelector仕様に適用されます。異なるネットワークポリシーに同じingressルールまたはegressルールがある場合、共通のspec.podSelector仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のネットワークポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。
6.3.1.3.1. OVN-Kubernetes の NetworkPolicy CR と外部 IP リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes では、NetworkPolicy カスタムリソース (CR) によって厳密な分離ルールが適用されます。サービスが外部 IP を使用して公開されている場合、トラフィックを許可するように明示的に設定されていない限り、ネットワークポリシーによって他の namespace からのアクセスがブロックされる可能性があります。
namespace をまたいで外部 IP へのアクセスを許可するには、必要な namespace からの Ingress を明示的に許可し、指定されたサービスポートへのトラフィックが許可されるようにする NetworkPolicy CR を作成します。必要なポートへのトラフィックを許可しなければ、アクセスが制限される可能性があります。
出力例
ここでは、以下のようになります。
<policy_name>- ポリシーの名前を指定します。
<my_namespace>- ポリシーがデプロイされる namespace の名前を指定します。
詳細は、「ネットワークポリシーについて」を参照してください。
6.3.1.4. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
6.3.2. ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
admin ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。
6.3.2.1. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.3.2.2. CLI を使用したネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
ポリシールールを作成します。
<policy_name>.yamlファイルを作成します。touch <policy_name>.yaml
$ touch <policy_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーファイル名を指定します。
作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。
すべての namespace のすべての Pod から Ingress を拒否します。
これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同じ namespace のすべての Pod から Ingress を許可します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の namespace から 1 つの Pod への上りトラフィックを許可する
このポリシーは、
namespace-yで実行されている Pod からpod-aというラベルの付いた Pod へのトラフィックを許可します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーファイル名を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。
6.3.2.3. デフォルトの全拒否ネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
このポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されたネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。この手順では、my-project namespace に deny-by-default ポリシーを適用することにより、強力な拒否ポリシーを強制します。
トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、次のポリシーによってクラスター全体で通信問題が発生する可能性があります。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
すべての namespace におけるすべての Pod からの Ingress を拒否する
deny-by-defaultポリシーを定義する次の YAML を作成します。YAML をdeny-by-default.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.4. 外部クライアントからのトラフィックを許可するネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を
web-allow-external.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/web-allow-external created
networkpolicy.networking.k8s.io/web-allow-external createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。
6.3.2.5. すべての namespace からアプリケーションへのトラフィックを許可するネットワークポリシーを作成する リンクのコピーリンクがクリップボードにコピーされました!
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
この手順に従って、すべての namespace 内のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定します。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を
web-allow-all-namespaces.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、
namespaceSelectorの指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/web-allow-all-namespaces created
networkpolicy.networking.k8s.io/web-allow-all-namespaces createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、
defaultnamespace で Web サービスを開始します。oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをsecondarynamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.6. namespace からアプリケーションへのトラフィックを許可するネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
特定の namespace からラベル app=web を持つ Pod へのトラフィックを許可するポリシーを設定するには、次の手順に従います。以下の場合にこれを行うことができます。
- 運用データベースへのトラフィックを、運用ワークロードがデプロイされている namespace のみに制限します。
- 特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが適用される namespace で作業している。
手順
ラベルが
purpose=productionの特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML をweb-allow-prod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/web-allow-prod created
networkpolicy.networking.k8s.io/web-allow-prod createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、
defaultnamespace で Web サービスを開始します。oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace を作成します。oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace にラベルを付けます。oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
devnamespace を作成します。oc create namespace dev
$ oc create namespace devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
devnamespace にラベルを付けます。oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをdevnamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
wget: download timed out
wget: download timed outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをprodnamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3. ネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
admin ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。
6.3.3.1. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.3.3.2. CLI を使用したネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを検査できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを表示できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
namespace のネットワークポリシーを一覧表示します。
namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
oc get networkpolicy
$ oc get networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- 検査するネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
以下に例を示します。
oc describe networkpolicy allow-same-namespace
$ oc describe networkpolicy allow-same-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc describeコマンドの出力Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。
6.3.4. ネットワークポリシーの編集 リンクのコピーリンクがクリップボードにコピーされました!
admin ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。
6.3.4.1. ネットワークポリシーの編集 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを編集できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを編集できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
オプション: namespace のネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
oc get networkpolicy
$ oc get networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトを編集します。
ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>- ネットワークポリシーを含むファイルの名前を指定します。
ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
oc edit networkpolicy <policy_name> -n <namespace>
$ oc edit networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトが更新されていることを確認します。
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。
6.3.4.2. サンプル NetworkPolicy オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
6.3.5. ネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
admin ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。
6.3.5.1. CLI を使用したネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
namespace のネットワークポリシーを削除できます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを削除できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
oc delete networkpolicy <policy_name> -n <namespace>
$ oc delete networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/default-deny deleted
networkpolicy.networking.k8s.io/default-deny deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。
6.3.6. プロジェクトのデフォルトネットワークポリシーの定義 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。
6.3.6.1. 新規プロジェクトのテンプレートの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成できます。
独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。
前提条件
-
cluster-admin権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
-
cluster-admin権限を持つユーザーとしてログインしている。 デフォルトのプロジェクトテンプレートを生成します。
oc adm create-bootstrap-project-template -o yaml > template.yaml
$ oc adm create-bootstrap-project-template -o yaml > template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される
template.yamlファイルを変更します。 プロジェクトテンプレートは、
openshift-confignamespace に作成する必要があります。変更したテンプレートを読み込みます。oc create -f template.yaml -n openshift-config
$ oc create -f template.yaml -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。
Web コンソールの使用
- Administration → Cluster Settings ページに移動します。
- Configuration をクリックし、すべての設定リソースを表示します。
- Project のエントリーを見つけ、Edit YAML をクリックします。
CLI の使用
project.config.openshift.io/clusterリソースを編集します。oc edit project.config.openshift.io/cluster
$ oc edit project.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
specセクションを、projectRequestTemplateおよびnameパラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名はproject-requestです。カスタムプロジェクトテンプレートを含むプロジェクト設定リソース
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。
6.3.6.2. 新規プロジェクトへのネットワークポリシーの追加 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy オブジェクトを自動的に作成します。
前提条件
-
クラスターは、
mode: NetworkPolicyが設定された OpenShift SDN ネットワークプラグインなど、NetworkPolicyオブジェクトをサポートするデフォルトの CNI ネットワークプラグインを使用します。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。 - 新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成している。
手順
以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。
oc edit template <project_template> -n openshift-config
$ oc edit template <project_template> -n openshift-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow <project_template>を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名はproject-requestです。テンプレートでは、各
NetworkPolicyオブジェクトを要素としてobjectsパラメーターに追加します。objectsパラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。以下の例では、
objectsパラメーターのコレクションにいくつかのNetworkPolicyオブジェクトが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
新規プロジェクトを作成します。
oc new-project <project>
$ oc new-project <project>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<project>を、作成しているプロジェクトの名前に置き換えます。
新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
oc get networkpolicy
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.7. ネットワークポリシーを使用したマルチテナント分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。
OpenShift SDN ネットワークプラグインを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。
6.3.7.1. ネットワークポリシーを使用したマルチテナント分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
admin権限を持つユーザーとしてクラスターにログインしている。
手順
以下の
NetworkPolicyオブジェクトを作成します。allow-from-openshift-ingressという名前のポリシー:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記policy-group.network.openshift.io/ingress: ""は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingressnamespace セレクターラベルを使用できますが、これはレガシーラベルです。allow-from-openshift-monitoringという名前のポリシー。Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-same-namespaceという名前のポリシー:Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-from-kube-apiserver-operatorという名前のポリシー:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、新規の New
kube-apiserver-operatorwebhook controller validating health of webhook を参照してください。
オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。
oc describe networkpolicy
$ oc describe networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.7.2. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
6.4. ネットワークセキュリティーの監査ロギング リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインは、Open Virtual Network (OVN) アクセス制御リスト (ACL) を使用して、AdminNetworkPolicy、BaselineAdminNetworkPolicy、NetworkPolicy、および EgressFirewall オブジェクトを管理します。監査ログは、NetworkPolicy、EgressFirewall、および BaselineAdminNetworkPolicy カスタムリソース (CR) の allow および deny ACL イベントを公開します。ロギングは、AdminNetworkPolicy (ANP) CR の allow、deny、pass ACL イベントも公開します。
監査ログは、OVN-Kubernetes ネットワークプラグイン でのみ使用できます。
6.4.1. 監査設定 リンクのコピーリンクがクリップボードにコピーされました!
監査ロギングの設定は、OVN-Kubernetes クラスターネットワークプロバイダー設定の一部として指定されます。次の YAML は、監査ログのデフォルト値を示しています。
監査ロギング設定
次の表では、監査ログの設定フィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
| integer |
ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり |
|
| integer |
監査ログの最大サイズ (バイト単位)。デフォルト値は |
|
| integer | 保持されるログファイルの最大数。 |
|
| string | 以下の追加の監査ログターゲットのいずれかになります。
|
|
| string |
RFC5424 で定義される |
6.4.2. 監査ロギング リンクのコピーリンクがクリップボードにコピーされました!
syslog サーバーや UNIX ドメインソケットなど、監査ログの宛先を設定できます。追加の設定に関係なく、監査ログは常にクラスター内の各 OVN-Kubernetes Pod の /var/log/ovn/acl-audit-log.log に保存されます。
各 namespace 設定に k8s.ovn.org/acl-logging セクションをアノテーション付けすることで、各 namespace の監査ログを有効にできます。k8s.ovn.org/acl-logging セクションでは、namespace の監査ログを有効にするために、allow、deny、またはその両方の値を指定する必要があります。
ネットワークポリシーでは、Pass アクションセットをルールとして設定することはサポートされていません。
ACL ロギング実装は、ネットワークのアクセス制御リスト (ACL) イベントをログに記録します。これらのログを表示して、潜在的なセキュリティー問題を分析できます。
namespace アノテーションの例
デフォルトの ACL ロギング設定値を表示するには、cluster-network-03-config.yml ファイルの policyAuditConfig オブジェクトを参照してください。必要に応じて、このファイル内のログファイルパラメーターの ACL ロギング設定値を変更できます。
ログメッセージの形式は、RFC5424 で定義されている syslog と互換性があります。syslog ファシリティーは設定可能です。デフォルトは local0 です。次の例は、ログメッセージに出力される主要なパラメーターとその値を示しています。
パラメーターとその値を出力するロギングメッセージの例
<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
詳細は、以下のようになります。
-
<timestamp>は、ログメッセージが作成された日時を示します。 -
<message_serial>には、ログメッセージのシリアル番号がリストされます。 -
acl_log (ovn_pinctrl0)は、OVN-Kubernetes プラグイン内のログメッセージの場所を出力するリテラル文字列です。 -
<severity>は、ログメッセージの重大度レベルを設定します。allowタスクとdenyタスクをサポートする監査ログを有効にすると、ログメッセージ出力に 2 つの重大度レベルが表示されます。 -
<name>は、ネットワークポリシーによって作成された OVN ネットワークブリッジングデータベース (nbdb) 内の ACL ロギング実装の名前を示します。 -
<verdict>は、allowまたはdropのいずれかになります。 -
<direction>は、to-lportまたはfrom-lportのいずれかで、ポリシーが Pod に向かうトラフィックまたは Pod から出るトラフィックに適用されたことを示します。 -
<flow>は、OpenFlowプロトコルと同等の形式でパケット情報を表示します。このパラメーターは Open vSwitch (OVS) フィールドで構成されます。
次の例は、flow パラメーターがシステムメモリーからパケット情報を抽出するために使用する OVS フィールドを示しています。
flow パラメーターがパケット情報を抽出するために使用する OVS フィールドの例
<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
詳細は、以下のようになります。
-
<proto>はプロトコルを指定します。有効な値はtcpとudpです。 -
vlan_tci=0x0000は、内部 Pod ネットワークトラフィックに VLAN ID が設定されていないため、VLAN ヘッダーを0として示します。 -
<src_mac>は、メディアアクセス制御 (MAC) アドレスのソースを指定します。 -
<source_mac>は、MAC アドレスの宛先を指定します。 -
<source_ip>は、送信元 IP アドレスをリストします -
<target_ip>は、ターゲット IP アドレスをリストします。 -
<tos_dscp>は、特定のネットワークトラフィックを他のトラフィックよりも分類して優先順位を付ける差別化サービスコードポイント (DSCP) 値を指定します。 -
<tos_ecn>は、ネットワーク内の輻輳したトラフィックを示す明示的輻輳通知 (ECN) 値を示します。 -
<ip_ttl>は、パケットの Time To Live (TTP) 情報を示します。 -
<fragment>は、一致させる IP フラグメントまたは IP 非フラグメントのタイプを指定します。 -
<tcp_src_port>は、TCP および UDP プロトコルのポートのソースを示します。 -
<tcp_dst_port>は、TCP および UDP プロトコルの宛先ポートをリストします。 -
<tcp_flags>は、SYN、ACK、PSHなどの多数のフラグをサポートします。複数の値を設定する必要がある場合は、各値を縦棒 (|) で区切ります。UDP プロトコルはこのパラメーターをサポートしていません。
以前のフィールドの説明の詳細は、OVS の man ページの ovs-fields を参照してください。
ネットワークポリシーの ACL 拒否ログエントリーの例
2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn 2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn 2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
以下の表は、namespace アノテーションの値を説明しています。
| フィールド | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
6.4.3. AdminNetworkPolicy 監査ログ リンクのコピーリンクがクリップボードにコピーされました!
監査ロギングは、次の例のように、ANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けることにより、AdminNetworkPolicy CR ごとに有効になります。
例6.19 AdminNetworkPolicy CR のアノテーションの例
特定の OVN ACL に該当し、ロギングアノテーションで設定されたアクション基準を満たすたびに、ログが生成されます。たとえば、ラベルが tenant: product-development の namespace のいずれかが tenant: backend-storage のラベルが付いた namespace にアクセスするイベントでは、ログが生成されます。
ACL ロギングは 60 文字に制限されます。ANP 名 フィールドが長い場合、ログの残りの部分は切り捨てられます。
以下は、ログエントリーの例の方向インデックスです。
| 方向 | ルール |
|---|---|
| Ingress |
|
| Egress |
|
例6.20 anp-tenant-log という名前の AdminNetworkPolicy の Ingress:0 および Egress:0 による Allow アクションに関する ACL ログエントリー例
2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn 2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack 2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack
2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack
例6.21 anp-tenant-log という名前の AdminNetworkPolicy の Ingress:1 および Egress:1 による Pass アクションに関する ACL ログエントリー例
2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack 2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack
2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack
例6.22 anp-tenant-log という名前の AdminNetworkPolicy の Egress:2 および Ingress2 による Deny アクションに関する ACL ログエントリー例
2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn 2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn
2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn
次の表は、ANP アノテーションを説明しています。
| アノテーション | 値 |
|---|---|
|
|
namespace の監査ログを有効にするには、
|
6.4.4. BaselineAdminNetworkPolicy 監査ログ リンクのコピーリンクがクリップボードにコピーされました!
監査ロギングは、次の例のように、BANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けすることで、BaselineAdminNetworkPolicy CR で有効になります。
例6.23 BaselineAdminNetworkPolicy CR のアノテーションの例
この例では、ラベルが tenant: dns の namespace のいずれかが tenant: workloads ラベルを持つ namespace にアクセスするイベントで、ログが生成されます。
以下は、ログエントリーの例の方向インデックスです。
| 方向 | ルール |
|---|---|
| Ingress |
|
| Egress |
|
例6.24 Ingress:0 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例
例6.25 Egress:0 および Ingress:1 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例
次の表では、BANP アノテーションを説明します。
| アノテーション | 値 |
|---|---|
|
|
namespace の監査ロギングを有効にするには、少なくとも
|
6.4.5. クラスターの Egress ファイアウォールとネットワークポリシー監査の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターの監査ログをカスタマイズできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。
手順
監査ロギング設定をカスタマイズするには、次のコマンドを入力します。
oc edit network.operator.openshift.io/cluster
$ oc edit network.operator.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML をカスタマイズして適用することで、監査ロギングを設定できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。
検証用の namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
namespace/verify-audit-logging created
namespace/verify-audit-logging createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow namespace のネットワークポリシーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/deny-all created networkpolicy.networking.k8s.io/allow-from-same-namespace created
networkpolicy.networking.k8s.io/deny-all created networkpolicy.networking.k8s.io/allow-from-same-namespace createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ソーストラフィックの Pod を
defaultnamespace に作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow verify-audit-loggingnamespace に 2 つの Pod を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pod/client created pod/server created
pod/client created pod/server createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。
verify-audit-loggingnamespace でserverという名前の Pod の IP アドレスを取得します。POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow defaultの namespace のclientという名前の Pod の直前のコマンドから IP アドレスに ping し、すべてのパケットがドロップされていることを確認します。oc exec -it client -n default -- /bin/ping -c 2 $POD_IP
$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data. --- 10.128.2.55 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 2041ms
PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data. --- 10.128.2.55 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 2041msCopy to Clipboard Copied! Toggle word wrap Toggle overflow verify-audit-loggingnamespace のclientという名前の Pod からPOD_IPシェル環境変数に保存されている IP アドレスに ping し、すべてのパケットが許可されていることを確認します。oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP
$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ネットワークポリシー監査ログの最新エントリーを表示します。
for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.6. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを有効にする リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace の監査ログを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。
手順
namespace の監査ログを有効にするには、次のコマンドを入力します。
oc annotate namespace <namespace> \ k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'$ oc annotate namespace <namespace> \ k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- namespace の名前を指定します。
ヒントまたは、以下の YAML を適用して監査ロギングを有効化できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
namespace/verify-audit-logging annotated
namespace/verify-audit-logging annotatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
監査ログの最新のエントリーを表示します。
for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log done$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0 2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.7. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを無効にする リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace の監査ログを無効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。
手順
namespace の監査ログを無効にするには、次のコマンドを入力します。
oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
$ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- namespace の名前を指定します。
ヒントまたは、以下の YAML を適用して監査ロギングを無効化できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
namespace/verify-audit-logging annotated
namespace/verify-audit-logging annotatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. Egress ファイアウォール リンクのコピーリンクがクリップボードにコピーされました!
6.5.1. プロジェクトの Egress ファイアウォールの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Egress ファイアウォールの名前をリスト表示し、特定の Egress ファイアウォールのトラフィックルールを表示できます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
6.5.1.1. EgressFirewall オブジェクトの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで EgressFirewall オブジェクトを表示できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
ocとして知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。 - クラスターにログインすること。
手順
オプション: クラスターで定義された EgressFirewall オブジェクトの名前を表示するには、以下のコマンドを入力します。
oc get egressfirewall --all-namespaces
$ oc get egressfirewall --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーを検査するには、以下のコマンドを入力します。
<policy_name>を検査するポリシーの名前に置き換えます。oc describe egressfirewall <policy_name>
$ oc describe egressfirewall <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.2. プロジェクトの Egress ファイアウォールの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。
6.5.2.1. EgressFirewall オブジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールを更新できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressfirewall
$ oc get -n <project> egressfirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Egress ネットワークファイアウォールの作成時に EgressFirewall オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <project>をプロジェクトの名前に置き換えます。<name>をオブジェクトの名前に置き換えます。<filename>をファイルの名前に置き換え、YAML を保存します。ポリシールールに変更を加えたら、以下のコマンドを実行して EgressFirewall オブジェクトを置き換えます。
<filename>を、更新された EgressFirewall オブジェクトを含むファイルの名前に置き換えます。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.3. プロジェクトからの Egress ファイアウォールの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックに対するすべての制限を削除できます。
6.5.3.1. EgressFirewall オブジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressFirewall オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressfirewall
$ oc get -n <project> egressfirewallCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、EgressFirewall オブジェクトを削除します。
<project>をプロジェクトの名前に、<name>をオブジェクトの名前に置き換えます。oc delete -n <project> egressfirewall <name>
$ oc delete -n <project> egressfirewall <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.4. プロジェクトの Egress ファイアウォールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、Egress トラフィックを制限する Egress ファイアウォールを作成できます。
6.5.4.1. Egress ファイアウォールのプロジェクトでの機能 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーは以下のシナリオをサポートします。
- Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
- Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
- Pod は OpenShift Container Platform クラスター外の指定された内部サブネットまたはホストにアクセスできません。
- Pod は特定の外部ホストにのみ接続することができます。
たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者が Python pip ミラーから更新するのを制限し、承認されたソースからのみ更新が行われるように強制することもできます。
Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。
EgressFirewall カスタムリソース (CR) オブジェクトを作成して Egress ファイアウォールポリシーを設定します。Egress ファイアウォールは、以下のいずれかの基準を満たすネットワークトラフィックと一致します。
- CIDR 形式の IP アドレス範囲。
- IP アドレスに解決する DNS 名
- ポート番号
- プロトコル。TCP、UDP、および SCTP のいずれかになります。
Egress ファイアウォールに 0.0.0.0/0 の拒否ルールが含まれる場合、OpenShift Container Platform API サーバーへのアクセスはブロックされます。API サーバーに接続するには、IP アドレスごとに許可ルールを追加するか、Egress ポリシールールで nodeSelector タイプの許可ルールを使用する必要があります。
次の例は、API サーバーへのアクセスを確保するために必要な Egress ファイアウォールルールの順序を示しています。
API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。
詳細は、BZ#1988324 を参照してください。
Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。
6.5.4.1.1. Egress ファイアウォールの制限 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールには以下の制限があります。
- 複数の EgressFirewall オブジェクトを持つプロジェクトはありません。
- 最大 8,000 のルールを持つ最大 1 つの EgressFirewall オブジェクトはプロジェクトごとに定義できます。
- Red Hat OpenShift Networking の共有ゲートウェイモードで OVN-Kubernetes ネットワークプラグインを使用している場合に、リターン Ingress 応答は Egress ファイアウォールルールの影響を受けます。送信ファイアウォールルールが受信応答宛先 IP をドロップすると、トラフィックはドロップされます。
これらの制限のいずれかに違反すると、プロジェクトの Egress ファイアウォールが壊れます。その結果、すべての外部ネットワークトラフィックがドロップされ、組織にセキュリティーリスクが生じる可能性があります。
Egress ファイアウォールリソースは、kube-node-lease、kube-public、kube-system、openshift、openshift- プロジェクトで作成できます。
6.5.4.1.2. Egress ポリシールールのマッチング順序 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの Egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
6.5.4.1.3. DNS (Domain Name Server) 解決の仕組み リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。
- ドメイン名の更新は、Time-to-Live (TTL) 期間に基づいてポーリングされます。デフォルトで、期間は 30 分です。Egress ファイアウォールコントローラーがローカルネームサーバーでドメイン名をクエリーする場合に、応答に 30 分未満の TTL が含まれる場合、コントローラーは DNS 名の期間を返される値に設定します。それぞれの DNS 名は、DNS レコードの TTL の期限が切れた後にクエリーされます。
- Pod は、必要に応じて同じローカルネームサーバーからドメインを解決する必要があります。そうしない場合、Egress ファイアウォールコントローラーと Pod によって認識されるドメインの IP アドレスが異なる可能性があります。ホスト名の IP アドレスが異なる場合、Egress ファイアウォールは一貫して実行されないことがあります。
- Egress ファイアウォールコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod は Egress コントローラーが実行する前に更新された IP アドレスを取得する可能性があります。これにより、競合状態が生じます。この現時点の制限により、EgressFirewall オブジェクトのドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。
Egress ファイアウォールポリシーで DNS 名を使用しても、CoreDNS を介したローカル DNS 解決には影響しません。
ただし、Egress ファイアウォールポリシーでドメイン名を使用し、外部 DNS サーバーで関連する Pod の DNS 解決を処理する場合は、DNS サーバーの IP アドレスへのアクセスを許可する Egress ファイアウォールルールを含める必要があります。
6.5.4.1.3.1. DNS 解決とワイルドカードドメイン名の解決の改善 リンクのコピーリンクがクリップボードにコピーされました!
DNS レコードに関連付けられた IP アドレスが頻繁に変更される場合や、Egress ファイアウォールポリシールールでワイルドカードドメイン名を指定する必要がある場合もあります。
このような状況では、OVN-Kubernetes クラスターマネージャーは、Egress ファイアウォールポリシールールで使用される一意の DNS 名ごとに DNSNameResolver カスタムリソースオブジェクトを作成します。このカスタムリソースには次の情報が保存されます。
Egress ファイアウォールルールの DNS 解決の改善は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
DNSNameResolver CR 定義の例
- 1
- DNS 名。これは、標準の DNS 名またはワイルドカード DNS 名のいずれかになります。ワイルドカード DNS 名の場合、DNS 名解決情報には、ワイルドカード DNS 名に一致するすべての DNS 名が含まれます。
- 2
spec.nameフィールドに一致する解決された DNS 名。spec.nameフィールドにワイルドカード DNS 名が含まれている場合、解決時にワイルドカード DNS 名と一致する標準 DNS 名を含む複数のdnsNameエントリーが作成されます。ワイルドカード DNS 名も正常に解決できる場合は、このフィールドにはワイルドカード DNS 名も保存されます。- 3
- DNS 名に関連付けられている現在の IP アドレス。
- 4
- 最後の Time-to-Live (TTL) 期間。
- 5
- 最後のルックアップ時刻。
DNS 解決中に、クエリー内の DNS 名が DNSNameResolver CR で定義された名前と一致する場合、CR status フィールドで以前の情報がそれに応じて更新されます。DNS ワイルドカード名のルックアップが失敗した場合、デフォルトの TTL である 30 分後に要求が再試行されます。
OVN-Kubernetes クラスターマネージャーは、EgressFirewall カスタムリソースオブジェクトの更新を監視し、更新が発生すると、それらの Egress ファイアウォールポリシーに関連付けられた DNSNameResolver CR を作成、変更、または削除します。
DNSNameResolver カスタムリソースを直接変更しないでください。これにより、Egress ファイアウォールの望ましくない動作が発生する可能性があります。
6.5.4.2. EgressFirewall カスタムリソース (CR) オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールのルールを 1 つ以上定義できます。ルールは、ルールが適用されるトラフィックを指定して Allow ルールまたは Deny ルールのいずれかになります。
以下の YAML は EgressFirewall CR オブジェクトを説明しています。
EgressFirewall オブジェクト
6.5.4.2.1. EgressFirewall ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は Egress ファイアウォールルールオブジェクトを説明しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector を使用して、送信トラフィックを許可または拒否できます。egress スタンザは、単一または複数のオブジェクトの配列を予想します。
Egress ポリシールールのスタンザ
- 1
- ルールのタイプ。値には
AllowまたはDenyのいずれかを指定する必要があります。 - 2
cidrSelectorフィールドまたはdnsNameフィールドを指定する Egress トラフィックのマッチングルールを記述するスタンザ。同じルールで両方のフィールドを使用することはできません。- 3
- CIDR 形式の IP アドレス範囲。
- 4
- DNS ドメイン名。
- 5
- ラベルは、ユーザーが定義するキーと値のペアです。ラベルは Pod などのオブジェクトに添付されます。
nodeSelectorを使用すると、1 つ以上のノードラベルを選択して、Pod に添付できます。 - 6
- オプション: ルールのネットワークポートおよびプロトコルのコレクションを記述するスタンザ。
ポートスタンザ
ports: - port: <port> protocol: <protocol>
ports:
- port: <port>
protocol: <protocol>
6.5.4.2.2. EgressFirewall CR オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の Egress ファイアウォールポリシールールを定義します。
- 1
- Egress ファイアウォールポリシールールオブジェクトのコレクション。
次の例では、トラフィックが TCP プロトコルおよび宛先ポート 80 または任意のプロトコルおよび宛先ポート 443 のいずれかを使用している場合に、IP アドレス 172.16.1.1/32 のホストへのトラフィックを拒否するポリシールールを定義します。
6.5.4.2.3. EgressFirewall の nodeSelector の例 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、nodeSelector を使用して、ラベルを指定することにより、クラスター内のノードへの Egress トラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。以下は、region=east ラベルを使用した例です。
ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、Egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにするラベルを作成します。
6.5.4.3. Egress ファイアウォールポリシーオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressFirewall オブジェクトがすでに定義されている場合、既存のポリシーを編集して Egress ファイアウォールルールを変更する必要があります。
前提条件
- OVN-Kubernetes ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy_name>.yamlファイルを作成します。この場合、<policy_name>は Egress ポリシールールを記述します。 - 作成したファイルで、Egress ポリシーオブジェクトを定義します。
-
以下のコマンドを入力してポリシーオブジェクトを作成します。
<policy_name>をポリシーの名前に、<project>をルールが適用されるプロジェクトに置き換えます。oc create -f <policy_name>.yaml -n <project>
$ oc create -f <policy_name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、新規の EgressFirewall オブジェクトが
project1という名前のプロジェクトに作成されます。oc create -f default.yaml -n project1
$ oc create -f default.yaml -n project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
egressfirewall.k8s.ovn.org/v1 created
egressfirewall.k8s.ovn.org/v1 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: 後に変更できるように
<policy_name>.yamlファイルを保存します。
6.6. IPsec 暗号化の設定 リンクのコピーリンクがクリップボードにコピーされました!
IPsec を有効にすると、ノード間の内部 Pod 間のクラスタートラフィックと、Pod とクラスター外部の IPsec エンドポイント間の外部トラフィックの両方を暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、トランスポートモード の IPsec で暗号化されます。
IPsec はデフォルトで無効にされています。クラスターのインストール中またはインストール後に IPsec を有効にできます。クラスターのインストールの詳細は、OpenShift Container Platform インストールの概要 を参照してください。
libreswan パッケージおよび NetworkManager- パッケージが異なる OpenShift Container Platform バージョンになると、クラスターを OpenShift Container Platform 4.16 にアップグレードすると、2 回連続してコンピュートノードのリブート操作が発生します。最初の再起動では、Cluster Network Operator (CNO)は IPsec 設定をコンピュートノードに適用します。2 回目の再起動の場合、Machine Config Operator (MCO)は最新のマシン設定をクラスターに適用します。
libreswan
CNO および MCO の更新を単一ノード再起動に統合するには、以下のタスクを実行します。
-
クラスターをアップグレードする前に、コンピュートノードをグループ化する
MachineConfigPoolsカスタムリソース(CR)でpausedパラメーターをtrueに設定します。 -
クラスターをアップグレードしたら、パラメーターを
falseに設定します。
詳細は、コントロールプレーンのみの更新の実行 を 参照してください。
OpenShift Container Platform クラスター上の IPsec には次のサポート制限があります。
- IBM Cloud® では、IPsec は NAT-T のみをサポートします。このプラットフォームでは、Encapsulating Security Payload (ESP) はサポートされていません。
- クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、IPsec は、Pod 間のトラフィックや外部ホストへのトラフィックの IPsec 暗号化でサポートされません。
- 1 つ以上のネットワークインターフェイスが Open vSwitch (OVS) に接続されている場合、ネットワークインターフェイスでの ESP ハードウェアオフロードの使用はサポートされません。クラスターに対して IPsec を有効にすると、OVS に接続されたインターフェイスで IPsec が使用されるようになります。デフォルトでは、OpenShift Container Platform は、OVS に接続されたすべてのインターフェイスで ESP ハードウェアオフロードを無効にします。
- OVS に接続されていないネットワークインターフェイスに対して IPsec を有効にした場合、クラスター管理者は、OVS に接続されていない各インターフェイスで ESP ハードウェアオフロードを手動で無効にする必要があります。
-
IPsec は Red Hat Enterprise Linux (RHEL) コンピュートノードではサポートされていません。これは、各コンピュートノードに存在するホストと
ovn-ipsecコンテナー間のlibreswan非互換性の問題が原因です。(OCPBUGS-53316) を参照してください。
次のリストは、IPsec ドキュメントの主要なタスクの概要を示しています。
- クラスターのインストール後に IPsec を有効または無効にする
- クラスターと外部ホスト間のトラフィックの IPsec 暗号化を設定する
- IPsec が異なるノード上の Pod 間のトラフィックを暗号化することを確認する
6.6.1. 動作モード リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターで IPsec を使用する場合、以下の動作モードから選択できます。
| Mode | 説明 | デフォルト |
|---|---|---|
|
| トラフィックは暗号化されません。これはクラスターのデフォルトです。 | はい |
|
| Pod 間のトラフィックが、「Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ」の説明のとおりに暗号化されます。IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。 | いいえ |
|
| IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。 | いいえ |
6.6.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
外部ホストへのトラフィックを暗号化するために IPsec をサポートする場合は、次の前提条件が満たされていることを確認してください。
-
OVN-Kubernetes ネットワークプラグインが、ローカルゲートウェイモード (
ovnKubernetesConfig.gatewayConfig.routingViaHost=true) で設定されている。 NMState Operator がインストールされている。この Operator は、IPsec 設定を指定するために必要です。詳細は、Kubernetes NMState Operator を参照してください。
注記NMState Operator は、Google Cloud Platform (GCP) で IPsec を設定する場合にのみサポートされます。
-
ブタンツール (
butane) がインストールされている。Butane をインストールするには、Butane のインストール を参照してください。
これらの前提条件は、証明書をホストの NSS データベースに追加するために、および外部ホストと通信するように IPsec を設定するために必要です。
6.6.3. IPsec が有効になっている場合のネットワーク接続要件 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。
| プロトコル | ポート | 説明 |
|---|---|---|
| UDP |
| IPsec IKE パケット |
|
| IPsec NAT-T パケット | |
| ESP | 該当なし | IPsec Encapsulating Security Payload (ESP) |
6.6.4. Pod 間のトラフィックの IPsec 暗号化 リンクのコピーリンクがクリップボードにコピーされました!
Pod 間のトラフィックの IPsec 暗号化は、次のセクションで、暗号化される Pod 間のトラフィック、使用される暗号化プロトコルの種類、および X.509 証明書の処理の仕組みを説明します。以下のセクションは、クラスターと外部ホスト間の IPsec 暗号化には適用されません。この種の暗号化は、特定の外部ネットワークインフラストラクチャーに合わせて手動で設定する必要があります。
6.6.4.1. Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ リンクのコピーリンクがクリップボードにコピーされました!
IPsec を有効にすると、Pod 間の以下のネットワークトラフィックフローのみが暗号化されます。
- クラスターネットワーク上の複数の異なるノードの Pod 間のトラフィック
- ホストネットワークの Pod からクラスターネットワーク上の Pod へのトラフィック
以下のトラフィックフローは暗号化されません。
- クラスターネットワーク上の同じノードの Pod 間のトラフィック
- ホストネットワーク上の Pod 間のトラフィック
- クラスターネットワークの Pod からホストネットワークの Pod へのトラフィック
暗号化されていないフローと暗号化されていないフローを以下の図に示します。
6.6.4.2. 暗号化プロトコルおよび IPsec モード リンクのコピーリンクがクリップボードにコピーされました!
使用する暗号化は AES-GCM-16-256 です。整合性チェック値 (ICV) は 16 バイトです。鍵の長さは 256 ビットです。
使用される IPsec モードは トランスポートモード です。これは、元のパケットの IP ヘッダーに Encapsulated Security Payload (ESP) ヘッダーを追加してパケットデータを暗号化することで、エンドツーエンドの通信を暗号化するモードです。OpenShift Container Platform は現在、Pod 間通信に IPsec Tunnel モード を使用したり、サポートしたりしません。
6.6.4.3. セキュリティー証明書の生成およびローテーション リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は、暗号化用に IPsec によって使用される自己署名の X.509 認証局 (CA) を生成します。各ノードの証明書署名要求 (CSR) は、CNO によって自動的に満たされます。
この CA は 10 年間有効です。個別のノード証明書は 5 年間有効で、4 年半が経過すると自動的にローテーションされます。
6.6.5. 外部トラフィックの IPsec 暗号化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、TLS 証明書を使用した外部ホストへのトラフィックの IPsec 暗号化をサポートします。TLS 証明書は管理者が提供する必要があります。
6.6.5.1. サポート対象のプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
この機能は次のプラットフォームでサポートされています。
- ベアメタル
- Google Cloud Platform (GCP)
- Red Hat OpenStack Platform (RHOSP)
- VMware vSphere
Red Hat Enterprise Linux (RHEL) ワーカーノードがある場合、これらのプラットフォームは外部トラフィックの IPsec 暗号化をサポートしません。
クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、外部ホストへのトラフィックを暗号化するための IPsec の設定はサポートされません。
6.6.5.2. 制限事項 リンクのコピーリンクがクリップボードにコピーされました!
次の禁止事項が遵守されていることを確認してください。
- 外部トラフィックの IPsec を設定する場合、IPv6 設定は現在 NMState Operator によってサポートされません。
-
提供する証明書バンドル内の証明書共通名 (CN) には、接頭辞
ovs_を指定できません。この名前は、各ノードのネットワークセキュリティーサービス (NSS) データベース内の Pod 間の IPsec CN 名と競合する可能性があるためです。
6.6.6. IPsec 暗号化の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Pod 間の IPsec 暗号化、クラスターと外部 IPsec エンドポイント間の IPsec 暗号化を有効にできます。
次のいずれかのモードで IPsec を設定できます。
-
Full: Pod 間のトラフィックおよび外部トラフィックの暗号化 -
External: 外部トラフィックの暗号化
IPsec を Full モードで設定する場合は、「外部トラフィックの IPsec 暗号化の設定」手順も完了する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
クラスター MTU のサイズを
46バイト減らして、IPsec ESP ヘッダーにオーバーヘッドを設けている。
手順
IPsec 暗号化を有効にするには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 外部ホストへのトラフィックを暗号化するには
Externalを指定します。Pod 間のトラフィックを暗号化し、必要に応じて外部ホストへのトラフィックを暗号化するにはFullを指定します。デフォルトでは、IPsec は無効になっています。
- 「外部トラフィックの IPsec 暗号化の設定」手順を完了して、IPsec を使用して外部トラフィックを暗号化します。
検証
OVN-Kubernetes データプレーン Pod の名前を見つけるには、次のコマンドを入力します。
oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node
$ oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターで IPsec が有効になっていることを確認します。
注記クラスター管理者は、IPsec が
Fullモードで設定されている場合に、クラスター上の Pod 間で IPsec が有効になっていることを確認できます。この手順では、クラスターと外部ホストの間で IPsec が機能しているかどうかは検証されません。oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec
$ oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<XXXXX>には、上記ステップの Pod のランダムな文字シーケンスを指定します。
出力例
true
trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.7. 外部トラフィックの IPsec 暗号化の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、IPsec を使用して外部トラフィックを暗号化するには、PKCS#12 証明書の提供を含め、ネットワークインフラストラクチャーに IPsec を設定する必要があります。この手順では Butane を使用してマシン設定を作成するため、butane コマンドがインストールされている必要があります。
マシン設定を適用した後、Machine Config Operator はクラスター内の影響を受けるノードを再起動し、新しいマシン設定をロールアウトします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
ローカルコンピューターに
butaneユーティリティーがインストールされている。 - NMState Operator がクラスターにインストールされている。
-
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - IPsec エンドポイント用の既存の PKCS#12 証明書と PEM 形式の CA 証明書があります。
-
クラスターで
FullまたはExternalモードの IPsec が有効になっている。 -
OVN-Kubernetes ネットワークプラグインが、ローカルゲートウェイモード (
ovnKubernetesConfig.gatewayConfig.routingViaHost=true) で設定されている。
手順
NMState Operator ノードネットワーク設定ポリシーを使用して IPsec 設定を作成します。詳細は、IPsec VPN 実装としての Libreswan を参照してください。
IPsec エンドポイントであるクラスターノードの IP アドレスを特定するために、次のコマンドを入力します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、NMState Operator のノードネットワーク設定ポリシーを含む
ipsec-config.yamlという名前のファイルを作成します。NodeNetworkConfigurationPolicyオブジェクトの概要は、The Kubernetes NMState project を参照してください。NMState IPsec トランスポート設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーを適用するホスト名を指定します。このホストは、IPsec 設定の左側のホストとして機能します。
- 2
- ホスト上に作成するインターフェイスの名前を指定します。
- 3
- クラスター側の IPsec トンネルを終端するクラスターノードのホスト名を指定します。この名前は、提供した PKCS#12 証明書の SAN
[Subject Alternate Name]と一致する必要があります。 - 4
- 外部ホスト名 (
host.example.comなど) を指定します。この名前は、提供した PKCS#12 証明書の SAN[Subject Alternate Name]と一致する必要があります。 - 5
- 外部ホストの IP アドレス (
10.1.2.3/32など) を指定します。
NMState IPsec トンネル設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーを適用するホスト名を指定します。このホストは、IPsec 設定の左側のホストとして機能します。
- 2
- ホスト上に作成するインターフェイスの名前を指定します。
- 3
- クラスター側の IPsec トンネルを終端するクラスターノードのホスト名を指定します。この名前は、提供した PKCS#12 証明書の SAN
[Subject Alternate Name]と一致する必要があります。 - 4
- 外部ホスト名 (
host.example.comなど) を指定します。この名前は、提供した PKCS#12 証明書の SAN[Subject Alternate Name]と一致する必要があります。 - 5
- 外部ホストの IP アドレス (
10.1.2.3/32など) を指定します。
IPsec インターフェイスを設定するために、次のコマンドを入力します。
oc create -f ipsec-config.yaml
$ oc create -f ipsec-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次の証明書ファイルを提供して、各ホストのネットワークセキュリティーサービス (NSS) データベースに追加します。これらのファイルは、後続の手順で Butane 設定の一部としてインポートされます。
-
left_server.p12: IPsec エンドポイントの証明書バンドル -
ca.pem: 証明書に署名した認証局
-
証明書をクラスターに追加するためのマシン設定を作成します。
コントロールプレーンとワーカーノードの Butane 設定ファイルを作成するには、次のコマンドを入力します。
注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.16.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前の手順で作成した Butane ファイルをマシン設定に変換するには、次のコマンドを入力します。
for role in master worker; do butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml done$ for role in master worker; do butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マシン設定をクラスターに適用するには、次のコマンドを入力します。
for role in master worker; do oc apply -f 99-ipsec-${role}-endpoint-config.yaml done$ for role in master worker; do oc apply -f 99-ipsec-${role}-endpoint-config.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Machine Config Operator (MCO) は各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。外部 IPsec 接続が使用可能になる前に、すべてのノードが更新されるまで待つ必要があります。
以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
IPsec マシン設定が正常にロールアウトされたことを確認するために、次のコマンドを入力します。
IPsec マシン設定が作成されたことを確認します。
oc get mc | grep ipsec
$ oc get mc | grep ipsecCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
80-ipsec-master-extensions 3.2.0 6d15h 80-ipsec-worker-extensions 3.2.0 6d15h
80-ipsec-master-extensions 3.2.0 6d15h 80-ipsec-worker-extensions 3.2.0 6d15hCopy to Clipboard Copied! Toggle word wrap Toggle overflow IPsec 拡張機能がコントロールプレーンノードに適用されていることを確認します。
oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
$ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
2
2Copy to Clipboard Copied! Toggle word wrap Toggle overflow IPsec 拡張機能がワーカーノードに適用されていることを確認します。
oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
$ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
2
2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.8. 外部 IPsec エンドポイントの IPsec 暗号化の無効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、外部ホストへの既存の IPsec トンネルを削除できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
クラスターで
FullまたはExternalモードの IPsec が有効になっている。
手順
次の YAML を使用して、
remove-ipsec-tunnel.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
name- ノードネットワーク設定ポリシーの名前を指定します。
node_name- 削除する IPsec トンネルが存在するノードの名前を指定します。
tunnel_name- 既存の IPsec トンネルのインターフェイス名を指定します。
IPsec トンネルを削除するために、次のコマンドを入力します。
oc apply -f remove-ipsec-tunnel.yaml
$ oc apply -f remove-ipsec-tunnel.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.6.9. IPsec 暗号化の無効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、IPsec 暗号化を無効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。
手順
IPsec 暗号化を無効にするには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: IP パケットの IPsec ESP ヘッダーからのオーバーヘッドがなくなるため、クラスター MTU のサイズを
46バイト増やすことができます。
6.6.10. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
- Red Hat Enterprise Linux (RHEL) 9 での IPsec を使用した VPN の設定
- Butane のインストール
- OVN-Kubernetes Container Network Interface (CNI) ネットワークプラグインについて
- クラスターネットワークの MTU 変更
- link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/operator_apis/#network-operator-openshift-io-v1[Network [operator.openshift.io/v1\] API
6.7. ゼロトラストネットワーク リンクのコピーリンクがクリップボードにコピーされました!
ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。
OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。
以下は、ゼロトラストネットワークの対象となる機能の詳細です。
6.7.1. Root of Trust リンクのコピーリンクがクリップボードにコピーされました!
公開証明書と秘密鍵はゼロトラストネットワークにとって重要です。これらは、各コンポーネントを相互に識別し、認証し、トラフィックを保護するために使用されます。証明書は他の証明書によって署名され、ルート認証局 (CA) への信頼チェーンが存在します。ネットワークに参加するすべてが、信頼チェーンを検証できるように、最終的にルート CA の公開鍵を持っている必要があります。一般に公開されている場合、通常は世界的に知られているルート CA のセットであり、その鍵はオペレーティングシステムや Web ブラウザーなどとともに配布されます。ただし、プライベート CA の証明書がすべての関係者に配布されている場合、クラスターまたは企業向けにプライベート CA を実行できます。
活用方法:
- OpenShift Container Platform: OpenShift は、クラスターリソースの保護に使用される クラスター CA をインストール時に 作成します。ただし、OpenShift Container Platform は、クラスター内で サービス証明書 を作成して署名することもでき、そのクラスター CA バンドルを必要に応じて Pod に注入することもできます。OpenShift Container Platform によって作成および署名された サービス証明書 の有効期間 (TTL) は 26 カ月で、13 カ月ごとに自動的にローテーションされます。必要に応じて手動でローテーションすることも可能です。
- OpenShift cert-manager Operator: cert-manager を使用すると、外部の root of trust によって署名された鍵を要求できます。委譲された署名証明書を使用して実行する方法の他に、外部発行者と統合するために設定できる発行者が多数あります。cert-manager API は、ゼロトラストネットワーク内の他のソフトウェア (Red Hat OpenShift Service Mesh など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。
6.7.2. トラフィック認証と暗号化 リンクのコピーリンクがクリップボードにコピーされました!
回線上のすべてのトラフィックが暗号化され、エンドポイントが識別可能になります。一例として、相互認証方式である Mutual TLS (mTLS) が挙げられます。
活用方法:
- OpenShift Container Platform: 透過的な Pod 間の IPsec を使用することで、トラフィックの送信元と宛先を IP アドレスで識別できます。Egress トラフィックを IPsec を使用して暗号化 する機能があります。Egress IP 機能を使用すると、トラフィックの送信元 IP アドレスを使用して、クラスター内のトラフィックの送信元を識別できます。
- Red Hat OpenShift Service Mesh: Pod から送信されるトラフィックを透過的に拡張して認証と暗号化を提供する強力な mTLS 機能 を提供します。
- OpenShift cert-manager Operator: カスタムリソース定義 (CRD) を使用して、プログラムが SSL/TLS プロトコルに使用するためにマウントできる証明書を要求します。
6.7.3. 識別と認証 リンクのコピーリンクがクリップボードにコピーされました!
CA を使用して証明書を作成できるようになると、それを使用して接続のもう一方の端 (ユーザーまたはクライアントマシン) のアイデンティティーを検証することで信頼関係を確立できるようになります。また、侵害された場合に使用を制限するために、証明書のライフサイクルを管理する必要もあります。
活用方法:
- OpenShift Container Platform: クライアントが信頼済みエンドポイントと通信していることを確認するためのクラスター署名付き サービス証明書。これには、サービスが SSL/TLS を使用し、クライアントが クラスター CA を使用することが求められます。クライアントアイデンティティーは他の手段で提供する必要があります。
- Red Hat Single Sign-On: エンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの要求認証統合を提供します。
- Red Hat OpenShift Service Mesh: mTLS への接続の 透過的なアップグレード、自動ローテーション、カスタム証明書の有効期限、JSON Web トークン (JWT) による要求認証。
- OpenShift cert-manager Operator: アプリケーションで使用する証明書の作成と管理。証明書は CRD により制御され、シークレットとしてマウントできます。また、cert-manager API と直接対話するようにアプリケーションを変更することもできます。
6.7.4. サービス間認可 リンクのコピーリンクがクリップボードにコピーされました!
リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。
活用方法:
-
OpenShift Container Platform: Kubernetes
NetworkPolicyおよびAdminNetworkPolicyオブジェクトを使用して、プラットフォームのネットワーク層で分離を強制できます。 - Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトを使用し、mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 の トラフィック制御。
6.7.5. トランザクションレベルの検証 リンクのコピーリンクがクリップボードにコピーされました!
接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。
活用方法:
- Red Hat OpenShift Service Mesh: リクエストの L7 検査、不正な HTTP リクエストの拒否、トランザクションレベルの 可観測性およびレポート を行います。Service Mesh は、JWT を使用した リクエストベースの認証 も提供できます。
6.7.6. リスク評価 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。
活用方法:
-
Red Hat OpenShift Service Mesh: OpenShift Web コンソール を使用して、Kubernetes の
NetworkPolicyとAdminNetworkPolicy、および OpenShift Networking のEgressFirewallオブジェクトを作成および可視化します。 - Red Hat Advanced Cluster Security for Kubernetes: 高度な オブジェクトの可視化。
6.7.7. サイト全体のポリシーの施行と配布 リンクのコピーリンクがクリップボードにコピーされました!
クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。
活用方法:
6.7.8. 継続的かつ遡及的な評価のための可観測性 リンクのコピーリンクがクリップボードにコピーされました!
クラスターを実行した後は、トラフィックを観察し、トラフィックが定義したルールに準拠していることを確認する必要があります。これは侵入検知やフォレンジックのために重要であり、運用負荷管理にも役立ちます。
活用方法:
- Network Observability Operator: クラスター内の Pod やノードへのネットワーク接続に関する検査、監視、アラートが可能になります。
- Red Hat Advanced Cluster Management (RHACM) for Kubernetes: プロセス実行、ネットワーク接続とフロー、権限昇格などのシステムレベルのイベントを監視、収集、評価します。クラスターのベースラインを決定し、異常なアクティビティーを検出して警告することができます。
- Red Hat OpenShift Service Mesh: Pod に出入りする トラフィックを監視 できます。
- Red Hat OpenShift Distributed Tracing Platform: 適切に計装されたアプリケーションでは、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連するすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。
6.7.9. エンドポイントセキュリティー リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。
活用方法:
- OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名された イメージのみを実行するように設定できます。
- Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。
6.7.10. クラスター外への信頼の拡張 リンクのコピーリンクがクリップボードにコピーされました!
クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。
活用方法:
- OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
- Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントにワークロードのリモートアテステーションを提供できます。
第7章 手動 DNS 管理のための Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者として Ingress Controller を作成すると、Operator は DNS レコードを自動的に管理します。必要な DNS ゾーンがクラスター DNS ゾーンと異なる場合、または DNS ゾーンがクラウドプロバイダーの外部でホストされている場合、これにはいくつかの制限があります。
クラスター管理者は、Ingress Controller を設定して、自動 DNS 管理を停止し、手動 DNS 管理を開始することができます。dnsManagementPolicy を設定して、いつ自動または手動で管理するかを指定します。
Ingress Controller を Managed から Unmanaged DNS 管理ポリシーに変更すると、Operator はクラウドでプロビジョニングされた以前のワイルドカード DNS レコードをクリーンアップしません。Ingress Controller を Unmanaged から Managed DNS 管理ポリシーに変更すると、Operator は、クラウドプロバイダーに DNS レコードが存在しない場合は作成を試み、DNS レコードがすでに存在する場合は更新を試みます。
dnsManagementPolicy を unmanaged に設定すると、クラウドプロバイダーでワイルドカード DNS レコードのライフサイクルを手動で管理する必要があります。
7.1. Managed DNS 管理ポリシー リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller の Managed DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが Operator によって自動的に管理されるようになります。
7.2. Unmanaged DNS 管理ポリシー リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller の Unmanaged DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが自動的に管理されず、代わりにクラスター管理者の責任になります。
AWS クラウドプラットフォームでは、Ingress Controller のドメインが dnsConfig.Spec.BaseDomain と一致しない場合、DNS 管理ポリシーは自動的に Unmanaged に設定されます。
7.3. Unmanaged DNS 管理ポリシーを使用したカスタム Ingress Controller の作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Unmanaged DNS 管理ポリシーを使用して、新しいカスタム Ingress Controller を作成できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下を含む
sample-ingress.yamlという名前のカスタムリソース (CR) ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を適用するためにファイルを保存します。
oc apply -f <name>.yaml
oc apply -f <name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. 既存の Ingress Controller の変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Ingress Controller を変更して、DNS レコードのライフサイクルを手動で管理できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
選択した
IngressControllerを変更してdnsManagementPolicyを設定します。SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}") oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}") oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - オプション: クラウドプロバイダーで関連付けられている DNS レコードを削除できます。
第8章 エンドポイントへの接続の確認 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。
8.1. 実行する接続ヘルスチェック リンクのコピーリンクがクリップボードにコピーされました!
クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。
- Kubernetes API サーバーサービス
- Kubernetes API サーバーエンドポイント
- OpenShift API サーバーサービス
- OpenShift API サーバーエンドポイント
- ロードバランサー
サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。
- ヘルスチェックターゲットサービス
- ヘルスチェックターゲットエンドポイント
8.2. 接続ヘルスチェックの実装 リンクのコピーリンクがクリップボードにコピーされました!
接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。
Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。
- ヘルスチェックのソース
-
このプログラムは、
Deploymentオブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムはPodNetworkConnectivityオブジェクトを消費し、各オブジェクトで指定されるspec.targetEndpointに接続されます。 - ヘルスチェックのターゲット
- クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。
ノードセレクターを使用して、ネットワーク接続ソースとターゲットが実行されるノードを設定できます。さらに、ソース Pod とターゲット Pod で許容できる tolerations を指定することもできます。この設定は、config.openshift.io/v1 API グループの Network API のシングルトン cluster カスタムリソースで定義されます。
Pod のスケジュールは、設定を更新した後に実行されます。したがって、設定を更新する前に、セレクターで使用する予定のノードラベルを適用する必要があります。ネットワーク接続チェック Pod の配置を更新した後に適用されたラベルは無視されます。
次の YAML のデフォルト設定を参照してください。
接続ソースおよびターゲット Pod のデフォルト設定
- 1 1
- ネットワーク診断設定を指定します。値が指定されていないか、空のオブジェクトが指定されており、
clusterという名前のnetwork.operator.openshift.ioカスタムリソースでspec.disableNetworkDiagnostics=trueが設定されている場合、ネットワーク診断は無効になります。設定されている場合、この値はspec.disableNetworkDiagnostics=trueをオーバーライドします。 - 2
- 診断モードを指定します。値は、空の文字列、
All、またはDisabledです。空の文字列はAllを指定するのと同じです。 - 3
- オプション: 接続チェックのソース Pod のセレクターを指定します。
nodeSelectorおよびtolerationsフィールドを使用して、sourceNodePod をさらに指定できます。ただし、ソース Pod とターゲット Pod の両方にnodeSelectorとtolerationsの両方を使用する必要はありません。これらは省略可能なオプションのフィールドです。 - 4
- オプション: 接続チェックのターゲット Pod のセレクターを指定します。
nodeSelectorおよびtolerationsフィールドを使用して、targetNodePod をさらに指定できます。ただし、ソース Pod とターゲット Pod の両方にnodeSelectorとtolerationsの両方を使用する必要はありません。これらは省略可能なオプションのフィールドです。
8.3. Pod 接続チェックの配置の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、cluster という名前の network.config.openshift.io オブジェクトを変更することで、接続チェック Pod が実行するノードを設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
接続チェック設定を編集するには、次のコマンドを入力します。
oc edit network.config.openshift.io cluster
$ oc edit network.config.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
テキストエディターで、
networkDiagnosticsスタンザを更新して、ソース Pod とターゲット Pod に必要なノードセレクターを指定します。 - 変更をコミットするには、変更を保存してテキストエディターを終了します。
検証
ソース Pod とターゲット Pod が目的のノードで実行されていることを確認するには、次のコマンドを入力します。
oc get pods -n openshift-network-diagnostics -o wide
$ oc get pods -n openshift-network-diagnostics -o wide
出力例
8.4. PodNetworkConnectivityCheck オブジェクトフィールド リンクのコピーリンクがクリップボードにコピーされました!
PodNetworkConnectivityCheck オブジェクトフィールドについては、以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
以下の形式のオブジェクトの名前:
|
|
|
|
オブジェクトが関連付けられる namespace。この値は、常に |
|
|
|
接続チェックの起点となる Pod の名前 (例: |
|
|
|
|
|
|
| 使用する TLS 証明書の設定。 |
|
|
| 使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。 |
|
|
| 接続テストの状態を表す、および最近の接続の成功および失敗に関するログ。 |
|
|
| 接続チェックと最新のステータスと以前のステータス。 |
|
|
| 試行に失敗した接続テストのログ。 |
|
|
| 停止が生じた期間が含まれる接続テストのログ。 |
|
|
| 試行に成功した接続テストのログ。 |
以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 接続の条件がある状態から別の状態に移行した時間。 |
|
|
| 人が判読できる形式の最後の移行に関する詳細。 |
|
|
| マシンの読み取り可能な形式での移行の最後のステータス。 |
|
|
| 状態のテータス。 |
|
|
| 状態のタイプ。 |
以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 接続の障害が解決された時点からのタイムスタンプ。 |
|
|
| 接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。 |
|
|
| 人が判読できる形式の停止について詳細情報の要約。 |
|
|
| 接続の障害が最初に検知された時点からのタイムスタンプ。 |
|
|
| 元の障害を含む接続ログのエントリー。 |
接続ログフィールド
接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。
-
status.failures[] -
status.successes[] -
status.outages[].startLogs[] -
status.outages[].endLogs[]
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| アクションの期間を記録します。 |
|
|
| ステータスを人が判読できる形式で提供します。 |
|
|
|
ステータスの理由をマシンが判読できる形式で提供します。値は |
|
|
| ログエントリーが成功または失敗であるかを示します。 |
|
|
| 接続チェックの開始時間。 |
8.5. エンドポイントのネットワーク接続の確認 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、API サーバー、ロードバランサー、サービス、Pod などのエンドポイントの接続を確認し、ネットワーク診断が有効になっていることを確認できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
ネットワーク診断が有効になっていることを確認するには、次のコマンドを入力します。
oc get network.config.openshift.io cluster -o yaml
$ oc get network.config.openshift.io cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在の
PodNetworkConnectivityCheckオブジェクトをリスト表示するには、以下のコマンドを入力します。oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
$ oc get podnetworkconnectivitycheck -n openshift-network-diagnosticsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続テストログを表示します。
- 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。
オブジェクトを表示するには、以下のコマンドを入力します。
oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はPodNetworkConnectivityCheckオブジェクトの名前を指定します。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第9章 クラスターネットワークの MTU 変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのインストール後にクラスターネットワークの MTU を変更できます。MTU 変更の適用には、クラスターノードを再起動する必要があるため、変更により致命的な問題が発生する可能性があります。
MTU は、OVN-Kubernetes プラグインまたは OpenShift SDN ネットワークプラグインを使用するクラスターに対してのみ変更できます。
9.1. クラスター MTU について リンクのコピーリンクがクリップボードにコピーされました!
インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。
以下のような理由でクラスターネットワークの MTU を変更する場合があります。
- クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
- クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。
9.1.1. サービス中断に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。
- 新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
- 特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。
9.1.2. MTU 値の選択 リンクのコピーリンクがクリップボードにコピーされました!
MTU の移行を計画するときは、関連しているが異なる MTU 値を 2 つ考慮する必要があります。
- ハードウェア MTU: この MTU 値は、ネットワークインフラストラクチャーの詳細に基づいて設定されます。
-
クラスターネットワーク MTU: この MTU 値は、クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。OVN-Kubernetes の場合、オーバーヘッドは
100バイトです。OpenShift SDN の場合、オーバーヘッドは50バイトです。
クラスターがノードごとに異なる MTU 値を必要とする場合は、クラスター内の任意のノードで使用される最小の MTU 値から、ネットワークプラグインのオーバーヘッド値を差し引く必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。
ノードが受け入れられない MTU 値の選択を回避するには、ip -d link コマンドを使用して、ネットワークインターフェイスが受け入れる最大 MTU 値 (maxmtu) を確認します。
9.1.3. 移行プロセスの仕組み リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
| ユーザーが開始する手順 | OpenShift Container Platform アクティビティー |
|---|---|
| Cluster Network Operator 設定で次の値を指定します。
| Cluster Network Operator (CNO): 各フィールドが有効な値に設定されていることを確認します。
指定の値が有効な場合に、CNO は、クラスターネットワークの MTU が Machine Config Operator (MCO): クラスター内の各ノードのローリングリブートを実行します。 |
| クラスター上のノードのプライマリーネットワークインターフェイスの MTU を再設定します。これを実現するには、次のようなさまざまな方法を使用できます。
| 該当なし |
|
ネットワークプラグインの CNO 設定で | Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。 |
9.2. クラスターネットワーク MTU の変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターの最大伝送単位 (MTU) を増減できます。
MTU 移行プロセス中にノードの MTU 値をロールバックすることはできません。ただし、MTU 移行プロセスの完了後に値をロールバックすることはできます。
移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。
次の手順では、マシン設定、Dynamic Host Configuration Protocol (DHCP)、または ISO イメージのいずれかを使用してクラスターネットワーク MTU を変更する方法を説明します。DHCP または ISO アプローチを使用する場合は、クラスターのインストール後に保持した設定アーティファクトを参照して、手順を完了する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つアカウントを使用してクラスターにアクセスできる。 クラスターのターゲット MTU を特定している。
-
OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から
100を引いた値に設定する必要があります。 -
OpenShift SDN ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値より
50小さく設定する必要があります。
-
OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から
- ノードが物理マシンである場合は、クラスターネットワークと、接続されているネットワークスイッチがジャンボフレームをサポートしていることを確認する。
- ノードが仮想マシン (VM) である場合は、ハイパーバイザーと、接続されているネットワークスイッチがジャンボフレームをサポートしていることを確認する。
手順
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ハードウェア MTU の設定を準備します。
ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。
dhcp-option-force=26,<mtu>
dhcp-option-force=26,<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<mtu>- DHCP サーバーがアドバタイズするハードウェア MTU を指定します。
- ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。
ハードウェア MTU が NetworkManager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。
プライマリーネットワークインターフェイスを見つけます。
OpenShift SDN ネットワークプラグインを使用している場合は、次のコマンドを入力します。
oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'$ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node_name>- クラスター内のノードの名前を指定します。
OVN-Kubernetes ネットワークプラグインを使用している場合は、次のコマンドを入力します。
oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
$ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node_name>- クラスター内のノードの名前を指定します。
<interface>-mtu.confファイルに次の NetworkManager 設定を作成します。NetworkManager 接続設定の例
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
[connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<mtu>- 新しいハードウェア MTU 値を指定します。
<interface>- プライマリーネットワークインターフェイス名を指定します。
1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つの
MachineConfigオブジェクトを作成します。control-plane-interface.buファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.16.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow worker-interface.buファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0です。たとえば、4.16.0です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Butane 設定から
MachineConfigオブジェクトを作成します。for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 警告これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。
MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<overlay_from>- 現在のクラスターネットワークの MTU 値を指定します。
<overlay_to>-
クラスターネットワークのターゲット MTU を指定します。この値は、
<machine_to>の値を基準にして設定します。OVN-Kubernetes の場合、この値は<machine_to>の値から100を引いた値である必要があります。OpenShift SDN の場合、この値は <machine_to> の値より。50小さくする必要があります <machine_to>- 基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。
クラスター MTU を増やす例
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<config_name>はmachineconfiguration.openshift.io/currentConfigフィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/mtu-migration.sh
ExecStart=/usr/local/bin/mtu-migration.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
基盤となるネットワークインターフェイスの MTU 値を更新します。
NetworkManager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。MachineConfig Operator は、クラスター内のノードのローリングリブートを自動的に実行します。
for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。
Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep path:
$ oc get machineconfig <config_name> -o yaml | grep path:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<config_name>はmachineconfiguration.openshift.io/currentConfigフィールドのマシン設定の名前になります。マシン設定が正常にデプロイされた場合、前の出力には
/etc/NetworkManager/conf.d/99-<interface>-mtu.confファイルパスとExecStart=/usr/local/bin/mtu-migration.sh行が含まれます。
プラグインの MTU 移行の最終処理を行います。両方のコマンド例では、<
mtu> は、<overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。MTU の移行を完了するために、OVN-Kubernetes ネットワークプラグインに対して次のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow MTU 移行を完了するには、OpenShift SDN ネットワークプラグインに対して次のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'$ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。
検証
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
oc describe network.config cluster
$ oc describe network.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。
クラスター内のノードをリスト表示するには、次のコマンドを入力します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。
oc debug node/<node> -- chroot /host ip address show <interface>
$ oc debug node/<node> -- chroot /host ip address show <interface>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node>- 前のステップの出力をもとに、ノードを指定します。
<interface>- ノードのプライマリーネットワークインターフェイス名を指定します。
出力例
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第10章 ノードポートサービス範囲の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストール中に、クラスターの要件を満たすようにノードのポート範囲を設定できます。クラスターのインストール後は、クラスター管理者のみがインストール後のタスクとして範囲を拡張できます。クラスターが多数のノードポートを使用する場合は、クラスターの要件に応じて使用可能なポート範囲を増やすことを検討してください。
ノードのポート範囲を拡張する前に、Red Hat はデフォルトのポート範囲 30000-32768 外ではテストを実行していないことに注意してください。デフォルトのポート範囲外の範囲については、拡張されたノードポート範囲がクラスターに影響を与えないことを確認するためにテストを行ってください。範囲を拡張したところポート割り当ての問題が発生した場合は、新しいクラスターを作成し、必要な範囲を設定します。
クラスターのインストール中にノードのポート範囲を設定しない場合は、デフォルトの範囲 30000-32768 がクラスターに適用されます。この場合、どちらの側でも範囲を拡張できますが、新しいポート範囲内で 30000-32768 を維持する必要があります。
ノードのポート範囲を拡張し、OpenShift API サーバーとのポート競合のために OpenShift CLI (oc) が動作しなくなった場合は、新しいクラスターを作成する必要があります。新しいノードのポート範囲が、ホストネットワークで設定されているホストプロセスまたは Pod によってすでに使用されているポートと重複していないことを確認してください。
10.1. ノードのポート範囲の拡張 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのノードポート範囲を拡張できます。ただし、OpenShift Container Platform クラスターをインストールした後は、どちらの側でもノードのポート範囲を縮小することはできません。
ノードのポート範囲を拡張する前に、Red Hat はデフォルトのポート範囲 30000-32768 外ではテストを実行していないことに注意してください。デフォルトのポート範囲外の範囲については、拡張されたノードポート範囲がクラスターに影響を与えないことを確認するためにテストを行ってください。範囲を拡張したところポート割り当ての問題が発生した場合は、新しいクラスターを作成し、必要な範囲を設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
クラスターインフラストラクチャーが拡張範囲内にあるポートへのアクセスを許可していることを確認している。たとえば、ノードのポート範囲を
30000-32900に拡張する場合、ファイアウォールまたはパケットフィルタリングの設定で、30000-32900のポート範囲 (両端の値を含む) を許可する必要があります。
手順
コマンドラインインターフェイス (CLI) で次のコマンドを入力して、クラスターが Pod のトラフィックを管理するために使用する
network.config.openshift.ioオブジェクト内のserviceNodePortRangeパラメーターの範囲を拡張します。oc patch network.config.openshift.io cluster --type=merge -p \ '{$ oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "<port_range>" }1 }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
<port_range>は30000-32900などの拡張範囲です。
ヒント次の YAML を適用してノードのポート範囲を更新することもできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定が成功したことを確認するには、次のコマンドを入力します。更新の適用には数分かかる場合があります。
oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'$ oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"service-node-port-range":["30000-32900"]
"service-node-port-range":["30000-32900"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第11章 クラスターネットワーク範囲の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのインストール後にクラスターネットワークの範囲を拡張できます。追加ノード用にさらに多くの IP アドレスが必要な場合は、クラスターネットワーク範囲を拡張することを推奨します。
たとえば、クラスターをデプロイし、クラスターネットワーク範囲として 10.128.0.0/19 を指定し、ホスト接頭辞 23 を指定した場合、16 ノードに制限されます。クラスターの CIDR マスクを /14 に変更することで、これを 510 ノードに拡張できます。
クラスターのネットワークアドレス範囲を拡張する場合、クラスターは OVN-Kubernetes ネットワークプラグイン を使用する必要があります。他のネットワークプラグインはサポートされていません。
クラスターネットワークの IP アドレス範囲を変更する場合、次の制限が適用されます。
- 指定する CIDR マスクサイズは、現在設定されている CIDR マスクサイズより常に小さくする必要があります。これは、インストールされたクラスターにノードを追加することによってのみ IP スペースを増やすことができるためです。
- ホスト接頭辞は変更できません
- オーバーライドされたデフォルトゲートウェイで設定された Pod は、クラスターネットワークの拡張後に再作成する必要があります。
11.1. クラスターネットワークの IP アドレス範囲の拡張 リンクのコピーリンクがクリップボードにコピーされました!
クラスターネットワークの IP アドレス範囲を拡張できます。この変更には新しい Operator 設定をクラスター全体にロールアウトする必要があるため、有効になるまでに最大 30 分かかる場合があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。 - クラスターが OVN-Kubernetes ネットワークプラグインを使用していることを確認します。
手順
クラスターのクラスターネットワーク範囲とホスト接頭辞を取得するには、次のコマンドを入力します。
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"cidr":"10.217.0.0/22","hostPrefix":23}][{"cidr":"10.217.0.0/22","hostPrefix":23}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターネットワークの IP アドレス範囲を拡張するには、次のコマンドを入力します。前のコマンドの出力から返された CIDR IP アドレス範囲とホスト接頭辞を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network>-
前の手順で取得した
cidrフィールドのネットワーク部分を指定します。この値は変更できません。 <cidr>-
ネットワーク接頭辞長を指定します。たとえば、
14です。この値を前の手順の出力の値よりも小さい数値に変更して、クラスターネットワークの範囲を拡大します。 <prefix>-
クラスターの現在のホスト接頭辞を指定します。この値は、前の手順で取得した
hostPrefixフィールドの値と同じである必要があります。
コマンドの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定がアクティブであることを確認するには、以下のコマンドを入力します。この変更が有効になるまで、最大 30 分かかる場合があります。
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.clusterNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[{"cidr":"10.217.0.0/14","hostPrefix":23}][{"cidr":"10.217.0.0/14","hostPrefix":23}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第12章 IP フェイルオーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの IP フェイルオーバーの設定を説明します。
IP フェイルオーバーは Keepalived を使用して、一連のホストで外部からアクセスできる仮想 IP (VIP) アドレスのセットをホストします。各仮想 IP アドレスは、一度に 1 つのホストによってのみサービスされます。Keepalived は Virtual Router Redundancy Protocol (VRRP) を使用して、(一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。
セットのすべての VIP はセットから選択されるノードによって提供されます。単一のノードが使用可能な場合は、仮想 IP が提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべての VIP がそのノードに配置されます。
管理者は、すべての仮想 IP アドレスが次の要件を満たしていることを確認する必要があります。
- 設定されたホストでクラスター外からアクセスできる。
- クラスター内でこれ以外の目的で使用されていない。
各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してどのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視ポートでリッスンしている、またはチェックが無効にされている必要があります。
セット内の各仮想 IP は、異なるノードによってサービスされる可能性があります。
IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0 に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。
Keepalived を実行するノードが check スクリプトを渡す場合、ノードの VIP はプリエンプションストラテジーに応じて、その優先順位および現在のマスターの優先順位に基づいて master 状態になることができます。
クラスター管理者は OPENSHIFT_HA_NOTIFY_SCRIPT 変数を介してスクリプトを提供できます。このスクリプトは、ノードの VIP の状態が変更されるたびに呼び出されます。Keepalived は VIP を提供する場合は master 状態を、別のノードが VIP を提供する場合は backup 状態を、または check スクリプトが失敗する場合は fault 状態を使用します。notify スクリプトは、状態が変更されるたびに新規の状態で呼び出されます。
OpenShift Container Platform で IP フェイルオーバーのデプロイメント設定を作成できます。IP フェイルオーバーのデプロイメント設定は VIP アドレスのセットを指定し、それらの提供先となるノードのセットを指定します。クラスターには複数の IP フェイルオーバーのデプロイメント設定を持たせることができ、それぞれが固有な VIP アドレスの独自のセットを管理します。IP フェイルオーバー設定の各ノードは IP フェイルオーバー Pod として実行され、この Pod は Keepalived を実行します。
VIP を使用してホストネットワークを持つ Pod にアクセスする場合、アプリケーション Pod は IP フェイルオーバー Pod を実行しているすべてのノードで実行されます。これにより、いずれの IP フェイルオーバーノードもマスターになり、必要時に VIP を提供することができます。アプリケーション Pod が IP フェイルオーバーのすべてのノードで実行されていない場合、一部の IP フェイルオーバーノードが VIP を提供できないか、一部のアプリケーション Pod がトラフィックを受信できなくなります。この不一致を防ぐために、IP フェイルオーバーとアプリケーション Pod の両方に同じセレクターとレプリケーション数を使用します。
VIP を使用してサービスにアクセスしている間は、アプリケーション Pod が実行されている場所に関係なく、すべてのノードでサービスに到達できるため、任意のノードをノードの IP フェイルオーバーセットに含めることができます。いずれの IP フェイルオーバーノードも、いつでもマスターにすることができます。サービスは外部 IP およびサービスポートを使用するか、NodePort を使用することができます。NodePort のセットアップは権限付きの操作で実行されます。
サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、IP フェイルオーバーのモニタリングポートはサービスポートに設定されます。ノードポートを使用する場合、ポートはクラスター内のすべてのノードで開かれ、サービスは、現在 VIP にサービスを提供しているあらゆるノードからのトラフィックの負荷を分散します。この場合、IP フェイルオーバーのモニタリングポートはサービス定義で NodePort に設定されます。
サービス VIP の可用性が高い場合でも、パフォーマンスに影響が出る可能性があります。Keepalived は、各 VIP が設定内の一部のノードによってサービスされることを確認し、他のノードに VIP がない場合でも、複数の VIP が同じノードに配置される可能性があります。IP フェイルオーバーによって複数の VIP が同じノードに配置されると、VIP のセット全体で外部から負荷分散される戦略が妨げられる可能性があります。
ExternalIP を使用する場合は、ExternalIP 範囲と同じ仮想 IP 範囲を持つように IP フェイルオーバーを設定できます。また、モニタリングポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。どのユーザーでも、ExternalIP を使用してサービスをセットアップし、高可用性を実現できます。
クラスター内の VIP の最大数は 254 です。
12.1. IP フェイルオーバーの環境変数 リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、IP フェイルオーバーの設定に使用される変数を示しています。
| 変数名 | デフォルト | 説明 |
|---|---|---|
|
|
|
IP フェイルオーバー Pod は、各仮想 IP (VIP) のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが |
|
|
IP フェイルオーバーが Virtual Router Redundancy Protocol (VRRP) トラフィックの送信に使用するインターフェイス名。デフォルト値は
クラスターが OVN-Kubernetes ネットワークプラグインを使用する場合は、パケットロスを回避するためにこの値を | |
|
|
|
作成するレプリカの数。これは、IP フェイルオーバーデプロイメント設定の |
|
|
レプリケートする IP アドレス範囲のリスト。これは指定する必要があります。例: | |
|
|
|
仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは |
|
|
VRRP に作成するグループの数。これが設定されていない場合、グループは | |
|
| INPUT |
iptables チェーンの名前であり、 |
|
| アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名。 | |
|
|
| check スクリプトが実行される期間 (秒単位)。 |
|
| 状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名。 | |
|
|
|
新たな優先度の高いホストを処理するためのストラテジー。 |
12.2. クラスター内の IP フェイルオーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスター全体に IP フェイルオーバーを設定することも、ラベルセレクターの定義に基づいてノードのサブセットに IP フェイルオーバーを設定することもできます。クラスター内に IP フェイルオーバーのデプロイメントを複数設定して、それぞれを相互に切り離すこともできます。
IP フェイルオーバーのデプロイメントにより、使用される制約またはラベルに一致する各ノードでフェイルオーバー Pod が実行されるようになります。
この Pod は Keepalived を実行します。これは、最初のノードがサービスまたはエンドポイントに到達できない場合に、エンドポイントを監視し、Virtual Router Redundancy Protocol (VRRP) を使用して仮想 IP (VIP) を別のノードにフェイルオーバーできます。
実稼働環境で使用する場合は、少なくとも 2 つのノードを選択し、選択したノードの数に相当する replicas を設定する selector を設定します。
前提条件
-
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - プルシークレットを作成している。
Red Hat OpenStack Platform (RHOSP) のみ:
- ターゲット環境に RHOSP クライアント (RHCOS ドキュメント) をインストールした。
-
RHOSP
openrc.shrc ファイル (RHCOS ドキュメント) をダウンロードした。
手順
IP フェイルオーバーのサービスアカウントを作成します。
oc create sa ipfailover
$ oc create sa ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow hostNetworkの SCC (Security Context Constraints) を更新します。oc adm policy add-scc-to-user privileged -z ipfailover
$ oc adm policy add-scc-to-user privileged -z ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc adm policy add-scc-to-user hostnetwork -z ipfailover
$ oc adm policy add-scc-to-user hostnetwork -z ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenStack Platform (RHOSP) のみ: フェイルオーバー仮想 IP アドレスが RHOSP ポートに到達できるように、次の手順を実行します。
RHOSP CLI を使用して、RHOSP クラスターの
allowed_address_pairsパラメーターのデフォルトの RHOSP API および仮想 IP アドレスを表示します。openstack port show <cluster_name> -c allowed_address_pairs
$ openstack port show <cluster_name> -c allowed_address_pairsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
*Field* *Value* allowed_address_pairs ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb' ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'*Field* *Value* allowed_address_pairs ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb' ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHOSP CLI で次のコマンドを入力して、IP フェイルオーバーのデプロイメントに別の仮想 IP アドレスを設定し、RHOSP のポートでそのアドレスに到達できるようにします。デフォルトの RHOSP API および仮想 IP アドレスを、IP フェイルオーバーのデプロイメントのフェイルオーバー仮想 IP アドレスとして設定しないでください。
1.1.1.1フェイルオーバー IP アドレスを RHOSP ポートの許可されたアドレスとして追加する例openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cb
$ openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cbCopy to Clipboard Copied! Toggle word wrap Toggle overflow - デプロイメントの IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。後の手順の「IP フェイルオーバー設定のデプロイメント YAML の例」を参照してください。
IP フェイルオーバーのデプロイメントで次の仕様を指定して、フェイルオーバー仮想 IP アドレスを
OPENSHIFT_HA_VIRTUAL_IPS環境変数に渡します。OPENSHIFT_HA_VIRTUAL_IPSに1.1.1.1仮想 IP アドレスを追加する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。
注記Red Hat OpenStack Platform (RHOSP) の場合、デプロイメント YAML ファイルを再作成する必要はありません。このファイルは、以前の手順ですでに作成されています。
IP フェイルオーバー設定のデプロイメント YAML の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IP フェイルオーバーデプロイメントの名前。
- 2
- レプリケートする IP アドレス範囲のリスト。これは指定する必要があります。例:
1.2.3.4-6,1.2.3.9 - 3
- VRRP に作成するグループの数。これが設定されていない場合、グループは
OPENSHIFT_HA_VIP_GROUPS変数で指定されている仮想 IP 範囲ごとに作成されます。 - 4
- IP フェイルオーバーが VRRP トラフィックの送信に使用するインターフェイス名。デフォルトで
eth0が使用されます。 - 5
- IP フェイルオーバー Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが
0に設定される場合、テストは常にパスします。デフォルト値は80です。 - 6
- 仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは
0で、許可される範囲は0から255までです。 - 7
- 作成するレプリカの数です。これは、IP フェイルオーバーデプロイメント設定の
spec.replicas値に一致する必要があります。デフォルト値は2です。 - 8
iptablesチェーンの名前であり、iptablesルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、iptablesルールは追加されません。チェーンが存在しない場合は作成されず、Keepalived はユニキャストモードで動作します。デフォルトはINPUTです。- 9
- 状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名。
- 10
- アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名。
- 11
- 新たな優先度の高いホストを処理するためのストラテジー。デフォルト値は
preempt_delay 300で、優先順位の低いマスターが VIP を保持する場合に、Keepalived インスタンスが VIP を 5 分後に引き継ぎます。 - 12
- check スクリプトが実行される期間 (秒単位)。デフォルト値は
2です。 - 13
- デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。
12.3. check スクリプトおよび notify スクリプトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Keepalived は、オプションのユーザー指定のチェックスクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで web サーバーをテストします。クラスター管理者は、オプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。
check および notify スクリプトは、IP フェイルオーバー Pod で実行され、ホストファイルシステムではなく Pod ファイルシステムを使用します。ただし、IP フェイルオーバー Pod はホストファイルシステムが /hosts マウントパスで利用可能にします。check または notify スクリプトを設定する場合は、スクリプトへの完全パスを指定する必要があります。スクリプトを提供する方法として、ConfigMap オブジェクトの使用が推奨されます。
check および notify スクリプトの完全パス名は、Keepalived 設定ファイル (_/etc/keepalived/keepalived.conf) に追加されます。このファイルは、Keepalived が起動するたびにロードされます。次の方法で説明するように、ConfigMap オブジェクトを使用してスクリプトを Pod に追加できます。
Check script
チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0 の場合は抑制されます。
各 IP フェイルオーバー Pod は、Pod が実行されているノードで 1 つ以上の仮想 IP (VIP) アドレスを管理する Keepalived デーモンを管理します。Keepalived デーモンは、ノードの各 VIP の状態を維持します。特定のノード上の特定の VIP は、master、backup、または fault 状態にある可能性があります。
チェックスクリプトがゼロ以外を返す場合、ノードは backup 状態になり、保持されている仮想 IP は再割り当てされます。
Notify script
Keepalived は、次の 3 つのパラメーターを通知スクリプトに渡します。
-
$1-groupまたはinstance -
$2:groupまたはinstanceの名前です。 -
$3: 新規の状態:master、backup、またはfault
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
必要なスクリプトを作成し、それを保持する
ConfigMapオブジェクトを作成します。スクリプトには入力引数は指定されず、OKの場合は0を、failの場合は1を返す必要があります。check スクリプト
mycheckscript.sh:#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMapオブジェクトを作成します。oc create configmap mycustomcheck --from-file=mycheckscript.sh
$ oc create configmap mycustomcheck --from-file=mycheckscript.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトを Pod に追加します。マウントされた
ConfigMapオブジェクトファイルのdefaultModeは、ocコマンドを使用するか、デプロイメント設定を編集することで実行できる必要があります。通常は、0755、493(10 進数) の値が使用されます。oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh$ oc set env deploy/ipfailover-keepalived \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'$ oc set volume deploy/ipfailover-keepalived --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc set envコマンドは空白を区別します。=記号の両側に空白を入れることはできません。ヒントまたは、
ipfailover-keepalivedデプロイメント設定を編集することもできます。oc edit deploy ipfailover-keepalived
$ oc edit deploy ipfailover-keepalivedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を保存し、エディターを終了します。これにより
ipfailover-keepalivedが再起動されます。
12.4. VRRP プリエンプションの設定 リンクのコピーリンクがクリップボードにコピーされました!
ノードの仮想 IP (VIP) が check スクリプトを渡すことで fault 状態を終了すると、ノードの VIP は、現在 master 状態にあるノードの VIP よりも優先度が低い場合は backup 状態になります。nopreempt ストラテジーは master をホスト上の優先度の低いホストからホスト上の優先度の高い VIP に移動しません。デフォルトの preempt_delay 300 の場合、Keepalived は指定された 300 秒の間待機し、master をホスト上の優先度の高い VIP に移動します。
手順
プリエンプションを指定するには、
oc edit deploy ipfailover-keepalivedを入力し、ルーターのデプロイメント設定を編集します。oc edit deploy ipfailover-keepalived
$ oc edit deploy ipfailover-keepalivedCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
OPENSHIFT_HA_PREEMPTIONの値を設定します。-
preempt_delay 300: Keepalived は、指定された 300 秒の間待機し、masterをホスト上の優先度の高い VIP に移動します。これはデフォルト値です。 -
nopreempt:masterをホスト上の優先度の低い VIP からホスト上の優先度の高い VIP に移動しません。
-
12.5. 複数の IP フェイルオーバーインスタンスのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
IP フェイルオーバーのデプロイメント設定で管理される各 IP フェイルオーバー Pod (ノード/レプリカあたり 1 Pod) は Keepalived デーモンを実行します。設定される IP フェイルオーバーのデプロイメント設定が多くなると、作成される Pod も多くなり、共通の Virtual Router Redundancy Protocol (VRRP) ネゴシエーションに参加するデーモンも多くなります。このネゴシエーションはすべての Keepalived デーモンによって実行され、これはどのノードがどの仮想 IP (VIP) を提供するかを決定します。
Keepalived は内部で固有の vrrp-id を各 VIP に割り当てます。ネゴシエーションはこの vrrp-ids セットを使用し、決定後には優先される vrrp-id に対応する VIP が優先されるノードで提供されます。
したがって、IP フェイルオーバーのデプロイメント設定で定義されるすべての VIP について、IP フェイルオーバー Pod は対応する vrrp-id を割り当てる必要があります。これは、OPENSHIFT_HA_VRRP_ID_OFFSET から開始し、順序に従って vrrp-ids を VIP のリストに割り当てることによって実行されます。vrrp-ids には範囲 1..255 の値を設定できます。
複数の IP フェイルオーバーのデプロイメント設定がある場合は、OPENSHIFT_HA_VRRP_ID_OFFSET を指定して、デプロイメント設定内の VIP 数を増やす余地があり、vrrp-id 範囲が重複しないようにする必要があります。
12.6. 254 を超えるアドレスに関する IP フェイルオーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
IP フェイルオーバー管理は、仮想 IP (VIP) アドレスの 254 グループに制限されています。デフォルトでは、OpenShift Container Platform は各グループに 1 つの IP アドレスを割り当てます。OPENSHIFT_HA_VIP_GROUPS 変数を使用してこれを変更し、複数の IP アドレスが各グループに含まれるようにして、IP フェイルオーバーを設定するときに各 Virtual Router Redundancy Protocol (VRRP) インスタンスで使用可能な VIP グループの数を定義できます。
VIP の作成により、VRRP フェイルオーバーの発生時の広範囲の VRRP の割り当てが作成され、これはクラスター内のすべてのホストがローカルにサービスにアクセスする場合に役立ちます。たとえば、サービスが ExternalIP で公開されている場合などがこれに含まれます。
フェイルオーバーのルールとして、ルーターなどのサービスは特定の 1 つのホストに制限しません。代わりに、サービスは、IP フェイルオーバーの発生時にサービスが新規ホストに再作成されないように各ホストに複製可能な状態にする必要があります。
OpenShift Container Platform のヘルスチェックを使用している場合、IP フェイルオーバーおよびグループの性質上、グループ内のすべてのインスタンスはチェックされません。そのため、Kubernetes ヘルスチェック を使用してサービスが有効であることを確認する必要があります。
前提条件
-
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
各グループに割り当てられた IP アドレスの数を変更するには、
OPENSHIFT_HA_VIP_GROUPS変数の値を変更します。次に例を示します。IP フェイルオーバー設定の
DeploymentYAML の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- たとえば、7 つの VIP のある環境で
OPENSHIFT_HA_VIP_GROUPSが3に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。
OPENSHIFT_HA_VIP_GROUPS で設定されたグループの数が、フェイルオーバーに設定された IP アドレスの数より少ない場合、グループには複数の IP アドレスが含まれ、すべてのアドレスが 1 つのユニットとして移動します。
12.7. ExternalIP の高可用性 リンクのコピーリンクがクリップボードにコピーされました!
非クラウドクラスターでは、IP フェイルオーバーとサービスへの ExternalIP を組み合わせることができます。結果として、ExternalIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。
このアプローチでは、クラスターネットワーク設定の spec.ExternalIP.autoAssignCIDRs 範囲を指定し、同じ範囲を使用して IP フェイルオーバー設定を作成します。
IP フェイルオーバーはクラスター全体で最大 255 個の仮想 IP をサポートできるため、spec.ExternalIP.autoAssignCIDRs は /24 以下にする必要があります。
12.8. IP フェイルオーバーの削除 リンクのコピーリンクがクリップボードにコピーされました!
IP フェイルオーバーが最初に設定されている場合、クラスターのワーカーノードは、Keepalived 用に 224.0.0.18 のマルチキャストパケットを明示的に許可する iptables ルールを使用して変更されます。ノードが変更されるため、IP フェイルオーバーを削除するには、ジョブを実行して iptables ルールを削除し、Keepalived が使用する仮想 IP アドレスを削除する必要があります。
手順
オプション: config map として保存されるチェックおよび通知スクリプトを特定し、削除します。
IP フェイルオーバーの Pod が config map をボリュームとして使用するかどうかを決定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheck
Namespace: default Pod: keepalived-worker-59df45db9c-2x9mn Volumes that use config maps: volume: config-volume configMap: mycustomcheckCopy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の手順でボリュームとして使用される config map の名前が提供されている場合は、config map を削除します。
oc delete configmap <configmap_name>
$ oc delete configmap <configmap_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
IP フェイルオーバーの既存デプロイメントを特定します。
oc get deployment -l ipfailover
$ oc get deployment -l ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105d
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE default ipfailover 2/2 2 2 105dCopy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントを削除します。
oc delete deployment <ipfailover_deployment_name>
$ oc delete deployment <ipfailover_deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ipfailoverサービスアカウントを削除します。oc delete sa ipfailover
$ oc delete sa ipfailoverCopy to Clipboard Copied! Toggle word wrap Toggle overflow IP フェイルオーバーの設定時に追加された IP テーブルルールを削除するジョブを実行します。
以下の例のような内容で
remove-ipfailover-job.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ジョブを実行します。
oc create -f remove-ipfailover-job.yaml
$ oc create -f remove-ipfailover-job.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
job.batch/remove-ipfailover-2h8dm created
job.batch/remove-ipfailover-2h8dm createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ジョブが IP フェイルオーバーの初期設定を削除していることを確認します。
oc logs job/remove-ipfailover-2h8dm
$ oc logs job/remove-ipfailover-2h8dmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...
remove-failover.sh: OpenShift IP Failover service terminating. - Removing ip_vs module ... - Cleaning up ... - Releasing VIPs (interface eth0) ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第13章 チューニングプラグインを使用してシステムコントロールとインターフェイス属性を設定する リンクのコピーリンクがクリップボードにコピーされました!
Linux では、管理者は sysctl を使用してランタイム時にカーネルパラメーターを変更できます。チューニング Container Network Interface (CNI) メタプラグインを使用して、インターフェイスレベルのネットワーク sysctl を変更できます。チューニング CNI メタプラグインは、図に示すように、メインの CNI プラグインとチェーンで動作します。
メインの CNI プラグインはインターフェイスを割り当て、それをランタイム時にチューニング CNI メタプラグインに渡します。チューニング CNI メタプラグインを使用して、ネットワーク namespace の一部の sysctl といくつかのインターフェイス属性 (プロミスキャスモード、オールマルチキャストモード、MTU、および MAC アドレス) を変更できます。
13.1. チューニング CNI を使用してシステム制御を設定する リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、チューニング CNI を設定し、インターフェイスレベルのネットワーク net.ipv4.conf.IFNAME.accept_redirects sysctl を変更します。この例では、ICMP リダイレクトパケットの受け入れと送信を有効にします。チューニング CNI メタプラグイン設定では、インターフェイス名は IFNAME トークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。
手順
次の内容で、
tuning-example.yamlなどのネットワーク接続定義を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
- 2
- オブジェクトが関連付けられている namespace を指定します。
- 3
- CNI 仕様のバージョンを指定します。
- 4
- 設定の名前を指定します。設定名をネットワーク接続定義の name の値に一致させることが推奨されます。
- 5
- 設定するメイン CNI プラグインの名前を指定します。
- 6
- CNI メタプラグインの名前を指定します。
- 7
- 設定する sysctl を指定します。インターフェイス名は
IFNAMEトークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。
YAML ファイルの例を次に示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して YAML を適用します。
oc apply -f tuning-example.yaml
$ oc apply -f tuning-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
networkattachmentdefinition.k8.cni.cncf.io/tuningnad createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のようなネットワーク接続定義を使用して、
examplepod.yamlなどの Pod を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 設定済みの
NetworkAttachmentDefinitionの名前を指定します。 - 2
runAsUserは、コンテナーが実行されるユーザー ID を制御します。- 3
runAsGroupは、コンテナーが実行されるプライマリーグループ ID を制御します。- 4
allowPrivilegeEscalationは、Pod が権限の昇格を許可するように要求できるかどうかを決定します。指定しない場合、デフォルトで true に設定されます。このブール値は、no_new_privsフラグがコンテナープロセスに設定されるかどうかを直接制御します。- 5
capabilitiesは、完全なルートアクセスを許可せずに権限操作を許可します。このポリシーにより、すべての機能が Pod から削除されます。- 6
runAsNonRoot: trueは、コンテナーが 0 以外の任意の UID を持つユーザーで実行されることを要求します。- 7
RuntimeDefaultは、Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを有効にします。
以下のコマンドを実行して yaml を適用します。
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod
$ oc get podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod にログインします。
oc rsh tunepod
$ oc rsh tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定された sysctl フラグの値を確認します。たとえば、次のコマンドを実行して、値
net.ipv4.conf.net1.accept_redirectsを見つけます。sysctl net.ipv4.conf.net1.accept_redirects
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
net.ipv4.conf.net1.accept_redirects = 1
net.ipv4.conf.net1.accept_redirects = 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2. チューニング CNI を使用してオールマルチキャストモードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
チューニング Container Network Interface (CNI) メタプラグインを使用して、オールマルチキャストモードを有効にできます。
次の手順では、チューニング CNI を設定してオールマルチキャストモードを有効にする方法を説明します。
手順
次の内容で、
tuning-example.yamlなどのネットワーク接続定義を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
- 2
- オブジェクトが関連付けられている namespace を指定します。
- 3
- CNI 仕様のバージョンを指定します。
- 4
- 設定の名前を指定します。設定名は、ネットワーク接続定義の名前の値と一致させます。
- 5
- 設定するメイン CNI プラグインの名前を指定します。
- 6
- CNI メタプラグインの名前を指定します。
- 7
- インターフェイスのオールマルチキャストモードを変更します。有効にすると、ネットワーク上のすべてのマルチキャストパケットがそのインターフェイスで受信されます。
YAML ファイルの例を次に示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、YAML ファイルで指定された設定を適用します。
oc apply -f tuning-allmulti.yaml
$ oc apply -f tuning-allmulti.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
examplepod.yamlサンプルファイルで指定されているものと同様のネットワーク接続定義を持つ Pod を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 設定された
NetworkAttachmentDefinitionの名前を指定します。 - 2
- コンテナーの実行に使用するユーザー ID を指定します。
- 3
- コンテナーの実行に使用するプライマリーグループ ID を指定します。
- 4
- Pod が権限昇格を要求できるか指定します。指定しない場合、デフォルトで
trueに設定されます。このブール値は、no_new_privsフラグがコンテナープロセスに設定されるかどうかを直接制御します。 - 5
- コンテナーのケイパビリティーを指定します。
drop: ["ALL"]ステートメントは、すべての Linux ケイパビリティーが Pod からドロップされ、より制限的なセキュリティープロファイルが提供されていることを示します。 - 6
- UID が 0 以外のユーザーでコンテナーが実行されるように指定します。
- 7
- コンテナーの seccomp プロファイルを指定します。この場合、タイプは
RuntimeDefaultに設定されます。Seccomp は、プロセスで使用できるシステムコールを制限し、攻撃対象領域を最小化してセキュリティーを強化する Linux カーネル機能です。
次のコマンドを実行して、YAML ファイルで指定された設定を適用します。
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod
$ oc get podCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23s
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod にログインします。
oc rsh allmultipod
$ oc rsh allmultipodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod に関連付けられているすべてのインターフェイスをリスト表示します。
ip link
sh-4.4# ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第14章 Stream Control Transmission Protocol (SCTP) の使用 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ベアメタルクラスターで Stream Control Transmission Protocol (SCTP) を使用できます。
14.1. OpenShift Container Platform での SCTP のサポート リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service オブジェクトは、type パラメーターを ClusterIP または NodePort のいずれかの値に設定して定義する必要があります。
14.1.1. SCTP プロトコルを使用した設定例 リンクのコピーリンクがクリップボードにコピーされました!
protocol パラメーターを Pod またはサービスリソース定義の SCTP 値に設定して、Pod またはサービスを SCTP を使用するように設定できます。
以下の例では、Pod は SCTP を使用するように設定されています。
以下の例では、サービスは SCTP を使用するように設定されています。
以下の例では、NetworkPolicy オブジェクトは、特定のラベルの付いた Pod からポート 80 の SCTP ネットワークトラフィックに適用するように設定されます。
14.2. SCTP (Stream Control Transmission Protocol) の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の YAML 定義が含まれる
load-sctp-module.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigオブジェクトを作成するには、以下のコマンドを入力します。oc create -f load-sctp-module.yaml
$ oc create -f load-sctp-module.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが
Readyに移行すると、設定の更新が適用されます。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認 リンクのコピーリンクがクリップボードにコピーされました!
SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。
前提条件
-
クラスターからインターネットにアクセスし、
ncパッケージをインストールすること。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
SCTP リスナーを起動する Pod を作成します。
以下の YAML で Pod を定義する
sctp-server.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して Pod を作成します。
oc create -f sctp-server.yaml
$ oc create -f sctp-server.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP リスナー Pod のサービスを作成します。
以下の YAML でサービスを定義する
sctp-service.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成するには、以下のコマンドを入力します。
oc create -f sctp-service.yaml
$ oc create -f sctp-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SCTP クライアントの Pod を作成します。
以下の YAML で
sctp-client.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Podオブジェクトを作成するには、以下のコマンドを入力します。oc apply -f sctp-client.yaml
$ oc apply -f sctp-client.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーで SCTP リスナーを実行します。
サーバー Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpserver
$ oc rsh sctpserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP リスナーを起動するには、以下のコマンドを入力します。
nc -l 30102 --sctp
$ nc -l 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
サーバーの SCTP リスナーに接続します。
- ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
sctpserviceサービスの IP アドレスを取得します。以下のコマンドを入力します。oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow クライアント Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpclient
$ oc rsh sctpclientCopy to Clipboard Copied! Toggle word wrap Toggle overflow SCTP クライアントを起動するには、以下のコマンドを入力します。
<cluster_IP>をsctpserviceサービスのクラスター IP アドレスに置き換えます。nc <cluster_IP> 30102 --sctp
# nc <cluster_IP> 30102 --sctpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第15章 PTP ハードウェアの使用 リンクのコピーリンクがクリップボードにコピーされました!
15.1. OpenShift クラスターノードの Precision Time Protocol について リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) は、ネットワーク内のクロックを同期するのに使用されます。ハードウェアサポートと組み合わせて使用すると、PTP はマイクロ秒未満の精度を実現でき、Network Time Protocol (NTP) よりも正確になります。
PTP を使用する openshift-sdn クラスターで、ハードウェアタイムスタンプに User Datagram Protocol (UDP) を使用している場合、OVN-Kubernetes プラグインに移行すると、Open vSwitch (OVS) ブリッジなどのプライマリーインターフェイスデバイスにハードウェアタイムスタンプを適用できなくなります。そのため、UDP バージョン 4 の設定は、br-ex インターフェイスでは機能しません。
OpenShift Container Platform クラスターノードで linuxptp サービスを設定し、PTP 対応ハードウェアを使用できます。
OpenShift Container Platform Web コンソールまたは OpenShift CLI (oc) を使用して、PTP Operator をデプロイして PTP をインストールします。PTP Operator は linuxptp サービスを作成し、管理し、以下の機能を提供します。
- クラスター内の PTP 対応デバイスの検出。
-
linuxptpサービスの設定の管理。 -
PTP Operator
cloud-event-proxyサイドカーによるアプリケーションのパフォーマンスおよび信頼性に悪影響を与える PTP クロックイベントの通知。
PTP Operator は、ベアメタルインフラストラクチャーでのみプロビジョニングされるクラスターの PTP 対応デバイスと連携します。
15.1.1. PTP ドメインの要素 リンクのコピーリンクがクリップボードにコピーされました!
PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。PTP によって同期されるクロックは、リーダーとフォロワーの階層で構成されています。この階層は、1 クロックごとに実行される best master clock (BMC) アルゴリズムによって自動的に作成および更新されます。フォロワークロックはリーダークロックと同期しており、フォロワークロック自体が他のダウンストリームクロックのソースになることができます。
図15.1 ネットワーク内の PTP ノード
PTP クロックの 3 つの主要なタイプを以下に説明します。
- グランドマスタークロック
- グランドマスタークロックは、ネットワーク全体の他のクロックに標準時間情報を提供し、正確で安定した同期を保証します。タイムスタンプを書き込み、他のクロックからの時間の要求に応答します。グランドマスタークロックは、Global Navigation Satellite System (GNSS) のタイムソースと同期します。グランドマスタークロックは、ネットワーク内の時刻の信頼できるソースとして、他のすべてのデバイスに時刻同期を提供します。
- 境界クロック
- 境界クロックには、2 つ以上の通信パスにあるポートがあり、ソースと宛先の宛先を同時に他の宛先クロックに指定できます。境界クロックは、宛先クロックアップストリームとして機能します。宛先クロックはタイミングメッセージを受け取り、遅延に合わせて調整し、ネットワークを渡す新しいソースタイムシグナルを作成します。境界クロックは、ソースクロックと正しく同期され、ソースクロックに直接レポートする接続されたデバイスの数を減らすことができる新しいタイミングパケットを生成します。
- 通常のクロック
- 通常のクロックには、ネットワーク内の位置に応じて、送信元クロックまたは宛先クロックのロールを果たすことができる単一のポート接続があります。通常のクロックは、タイムスタンプの読み取りおよび書き込みが可能です。
NTP 上の PTP の利点
PTP が NTP を経由した主な利点の 1 つは、さまざまなネットワークインターフェイスコントローラー (NIC) およびネットワークスイッチにあるハードウェアサポートです。この特化されたハードウェアにより、PTP はメッセージ送信の遅れを説明でき、時間同期の精度を高められます。可能な限りの精度を実現するには、PTP クロック間の全ネットワークコンポーネントが PTP ハードウェアを有効にすることが推奨されます。
NIC は PTP パケットを送受信した瞬間にタイムスタンプを付けることができるため、ハードウェアベースの PTP は最適な精度を提供します。これをソフトウェアベースの PTP と比較します。これには、オペレーティングシステムによる PTP パケットの追加処理が必要になります。
PTP を有効にする前に、必要なノードについて NTP が無効になっていることを確認します。MachineConfig カスタムリソースを使用して chrony タイムサービス (chronyd) を無効にすることができます。詳細は、chrony タイムサービスの無効化 を参照してください。
15.1.2. OpenShift Container Platform ノードの linuxptp および gpsd の概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、高精度のネットワーク同期のために、PTP Operator とともに linuxptp および gpsd パッケージを使用します。linuxptp パッケージは、ネットワーク内の PTP タイミング用のツールとデーモンを提供します。Global Navigation Satellite System (GNSS) 対応の NIC を備えたクラスターホストは、GNSS クロックソースとのインターフェイスに gpsd を使用します。
linuxptp パッケージには、システムクロック同期用の ts2phc、pmc、ptp4l、および phc2sys プログラムが含まれています。
- ts2phc
ts2phcは、PTP デバイス間で PTP ハードウェアクロック (PHC) を高精度で同期します。ts2phcはグランドマスタークロック設定で使用されます。Global Navigation Satellite System (GNSS) などの高精度クロックソースから正確なタイミング信号を受信します。GNSS は、大規模な分散ネットワークで使用するための、正確で信頼性の高い同期時刻ソースを提供します。GNSS クロックは通常、数ナノ秒の精度で時刻情報を提供します。ts2phcシステムデーモンは、グランドマスタークロックから時刻情報を読み取り、PHC 形式に変換することにより、グランドマスタークロックからのタイミング情報をネットワーク内の他の PTP デバイスに送信します。PHC 時間は、ネットワーク内の他のデバイスがクロックをグランドマスタークロックと同期させるために使用されます。- pmc
-
pmcは、IEEE 標準 1588.1588 に従って PTP 管理クライアント (pmc) を実装します。pmcは、ptp4lシステムデーモンの基本的な管理アクセスを提供します。pmcは、標準入力から読み取り、選択されたトランスポート経由で出力を送信し、受信した応答を出力します。 - ptp4l
ptp4lは、PTP 境界クロックと通常のクロックを実装し、システムデーモンとして実行されます。ptp4lは、以下を行います。- ハードウェアタイムスタンプを使用して PHC をソースクロックに同期します。
- ソフトウェアタイムスタンプを使用してシステムクロックをソースクロックに同期します。
- phc2sys
-
phc2sysは、システムクロックをネットワークインターフェイスコントローラー (NIC) 上の PHC に同期します。phc2sysシステムデーモンは、PHC のタイミング情報を継続的に監視します。PHC はタイミングエラーを検出すると、システムクロックを修正します。
gpsd パッケージには、ホストクロックと GNSS クロックを同期するためのプログラム ubxtool、gspipe、gpsd が含まれています。
- ubxtool
-
ubxtoolCLI を使用すると、u-blox GPS システムと通信できます。ubxtoolCLI は、u-blox バイナリープロトコルを使用して GPS と通信します。 - gpspipe
-
gpspipeはgpsd出力に接続し、それをstdoutにパイプします。 - gpsd
-
gpsdは、ホストに接続されている 1 つ以上の GPS または AIS 受信機を監視するサービスデーモンです。
15.1.3. PTP グランドマスタークロックの GNSS タイミングの概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内の Global Navigation Satellite System (GNSS) ソースおよびグランドマスタークロック (T-GM) からの高精度 PTP タイミングの受信をサポートします。
OpenShift Container Platform は、Intel E810 Westport Channel NIC を使用した GNSS ソースからの PTP タイミングのみをサポートします。
図15.2 GNSS および T-GM との同期の概要
- Global Navigation Satellite System (GNSS)
GNSS は、測位情報、ナビゲーション情報、タイミング情報を世界中の受信機に提供するために使用される衛星ベースのシステムです。PTP では、高精度で安定した基準クロックソースとして GNSS 受信機がよく使用されます。これらの受信機は、複数の GNSS 衛星から信号を受信し、正確な時刻情報を計算できます。GNSS から取得したタイミング情報は、PTP グランドマスタークロックの基準として使用されます。
GNSS を基準として使用することにより、PTP ネットワークのグランドマスタークロックは、他のデバイスに高精度のタイムスタンプを提供し、ネットワーク全体での正確な同期を可能にします。
- Digital Phase-Locked Loop (DPLL)
- DPLL はネットワーク内の各 PTP ノード間のクロック同期を提供します。DPLL は、ローカルシステムクロック信号の位相を、受信同期信号 (PTP グランドマスタークロックからの PTP メッセージなど) の位相と比較します。DPLL は、ローカルクロックの周波数と位相を継続的に調整して、ローカルクロックと基準クロック間の位相差を最小限に抑えます。
GNSS 同期 PTP グランドマスタークロックでのうるう秒イベントの処理
うるう秒は、協定世界時 (UTC) を国際原子時 (TAI) と同期させるために、時折適用される 1 秒の調整です。UTC のうるう秒は予測できません。leap-seconds.list に、国際的に合意されたうるう秒が掲載されています。このファイルは、Earth Rotation and Reference Systems Service (IERS) によって定期的に更新されます。うるう秒が処理されないと、遠端の RAN ネットワークに大きな影響が及ぶ可能性があります。これにより、遠端の RAN アプリケーションが音声通話とデータセッションを直ちに切断する可能性があります。
15.1.4. PTP およびクロック同期エラーイベントについて リンクのコピーリンクがクリップボードにコピーされました!
仮想 RAN (vRAN) などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。PTP クロック同期エラーは、分散ユニット (DU) で実行している vRAN アプリケーションなど、低レイテンシーアプリケーションのパフォーマンスおよび信頼性に悪影響を及ぼす可能性があります。
PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークの OTA(Over the Air) トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。
イベント通知は、同じ DU ノード上で実行されている vRAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング (pub-sub メッセージング) は、非同期のサービス間通信アーキテクチャーです。このアーキテクチャーでは、トピックにパブリッシュされたメッセージが、そのトピックのすべてのサブスクライバーによって即座に受信されます。
PTP Operator は、すべての PTP 対応ネットワークインターフェイスの高速イベント通知を生成します。このイベントには、HTTP メッセージバス経由で cloud-event-proxy サイドカーコンテナーを使用してアクセスできます。
PTP 高速イベント通知は、PTP 通常クロック、PTP グランドマスタークロック、または PTP 境界クロックを使用するように設定されたネットワークインターフェイスで使用できます。
15.1.5. 2 カード E810 NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、シングルおよびデュアル NIC Intel E810 ハードウェアをサポートし、グランドマスタークロック (T-GM) および境界クロック (T-BC) の PTP タイミングを実現します。
- デュアル NIC グランドマスタークロック
デュアル NIC ハードウェアを備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 枚目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。
デュアル NIC グランドマスタークロックは、Remote Radio Unit (RRU) と Baseband Unit (BBU) が同じ無線セルサイトに配置されている分散型 RAN (D-RAN) 構成の機能です。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。
図15.3 デュアル NIC グランドマスタークロック
注記デュアル NIC T-GM 設定では、1 つの
ts2phcプログラムが、各 NIC に 1 つずつ存在する合計 2 つの PTP ハードウェアクロック (PHC) 上で動作します。- デュアル NIC 境界クロック
ミッドバンドスペクトルカバレッジを提供する 5G 電話会社ネットワークの場合、各仮想分散ユニット (vDU) には 6 つの無線ユニット (RU) への接続が必要です。これらの接続を確立するには、各 vDU ホストに境界クロックとして設定された 2 つの NIC が必要です。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の
ptp4lインスタンスをダウンストリームクロックに供給することができます。- デュアル NIC 境界クロックを備えた高可用性システムクロック
Intel E810-XXVDA4 Salem チャネルデュアル NIC ハードウェアを、高可用性システムクロックのタイミングを提供するデュアル PTP 境界クロックとして設定できます。この設定は、別々の NIC 上に複数のタイムソースがある場合に便利です。高可用性があれば、どちらかのタイミングソースが失われたり切断されたりしても、ノードのタイミング同期が失われることはありません。
各 NIC は同じアップストリームリーダークロックに接続されます。高可用性境界クロックは、複数の PTP ドメインを使用してターゲットシステムクロックと同期します。T-BC が高可用性である場合、NIC PHC クロックを同期する 1 つ以上の
ptp4lインスタンスが失敗した場合でも、ホストシステムクロックは正しいオフセットを維持できます。単一の SFP ポートまたはケーブルに障害が発生した場合、境界クロックはリーダークロックと同期したままになります。境界クロックリーダーソースの選択は、A-BMCA アルゴリズムを使用して行われます。詳細は、ITU-T recommendation G.8275.1 を参照してください。
15.1.6. 3 カード Intel E810 PTP グランドマスタークロック リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、PTP グランドマスタークロック (T-GM) として 3 つの Intel E810 NIC を使用するクラスターホストをサポートしています。
- 3 カードグランドマスタークロック
3 枚の NIC を備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目と 3 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 つ目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。
3 カード NIC グランドマスタークロックは、Radio Unit (RU) がフロントホールスイッチなしで分散ユニット (DU) に直接接続される分散 RAN (D-RAN) 構成に使用できます (例: RU と DU が同じ無線セルサイトにある場合)。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。
図15.4 3 カード Intel E810 PTP グランドマスタークロック
注記3 カードの T-GM 設定では、1 つの
ts2phcプロセスがシステム内の 3 つのts2phcインスタンスとして報告されます。
15.2. PTP デバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator は NodePtpDevice.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。
PTP Operator は、インストールされている場合、クラスター内の各ノードで Precision Time Protocol (PTP) 対応のネットワークデバイスを検索します。この Operator は、互換性のある PTP 対応ネットワークデバイスを提供する各ノードの NodePtpDevice カスタムリソース (CR) オブジェクトを作成および更新します。
PTP 機能が組み込まれたネットワークインターフェイスコントローラー (NIC) ハードウェアでは、デバイス固有の設定が必要な場合があります。PtpConfig カスタムリソース (CR) でプラグインを設定することで、PTP Operator でサポートされているハードウェア固有の NIC 機能を使用できます。linuxptp-daemon サービスが、plugin スタンザ内の名前付きパラメーターを使用して、特定のハードウェア設定に基づいて linuxptp プロセス、ptp4l および phc2sys を起動します。
OpenShift Container Platform 4.16 では、Intel E810 NIC が PtpConfig プラグインでサポートされています。
15.2.1. CLI を使用した PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成します。
次の YAML を
ptp-namespace.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespaceCR を作成します。oc create -f ptp-namespace.yaml
$ oc create -f ptp-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP Operator の Operator グループを作成します。
次の YAML を
ptp-operatorgroup.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成します。oc create -f ptp-operatorgroup.yaml
$ oc create -f ptp-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP Operator にサブスクライブします。
次の YAML を
ptp-sub.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SubscriptionCR を作成します。oc create -f ptp-sub.yaml
$ oc create -f ptp-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Phase 4.16.0-202301261535 Succeeded
Name Phase 4.16.0-202301261535 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.2. Web コンソールを使用した PTP Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Web コンソールを使用して PTP Operator をインストールできます。
先のセクションで説明されているように namespace および Operator グループを作成する必要があります。
手順
OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
- Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
オプション: PTP Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに切り替えます。
PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
- Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
-
Workloads → Pods ページに移動し、
openshift-ptpプロジェクトで Pod のログを確認します。
15.2.3. クラスター内の PTP 対応ネットワークデバイスの検出 リンクのコピーリンクがクリップボードにコピーされました!
PTP 対応ネットワークデバイスを設定できるように、クラスター内に存在する PTP 対応ネットワークデバイスを特定します。
前提条件
- PTP Operator がインストールされている。
手順
クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。
oc get NodePtpDevice -n openshift-ptp -o yaml
$ oc get NodePtpDevice -n openshift-ptp -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4. linuxptp サービスをグランドマスタークロックとして設定する リンクのコピーリンクがクリップボードにコピーされました!
ホスト NIC を設定する PtpConfig カスタムリソース (CR) を作成することで、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロック (T-GM) として設定できます。
ts2phc ユーティリティーを使用すると、システムクロックを PTP グランドマスタークロックと同期できるため、ノードは高精度クロック信号をダウンストリームの PTP 通常クロックおよび境界クロックにストリーミングできます。
次の PtpConfig CR の例をベースとして使用して、linuxptp サービスを Intel Westport Channel E810-XXVDA4T ネットワークインターフェイスの T-GM として設定してください。
PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに Intel E810 Westport Channel NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。要件に応じて、デプロイメントに次の T-GM 設定のいずれかを使用します。YAML を
grandmaster-clock-ptp-config.yamlファイルに保存します。例15.1 E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記E810 Westport Channel NIC の場合は、
ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f grandmaster-clock-ptp-config.yaml
$ oc create -f grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4.1. linuxptp サービスをデュアル E810 Westport Channel NIC のグランドマスタークロックとして設定する リンクのコピーリンクがクリップボードにコピーされました!
NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 2 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。
次の E810 NIC の場合、T-GM として linuxptp サービスを設定できます。
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
分散型 RAN (D-RAN) のユースケースでは、次の方法で 2 カード NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) のタイムソースに同期します。
-
NIC 2 を、NIC 1 によって提供される 1PPS タイミング出力に同期します。この設定は、
PtpConfigCR の PTP ハードウェアプラグインによって提供します。
2 カード PTP T-GM 設定では、ptp4l のインスタンス 1 つと ts2phc のインスタンス 1 つが使用されます。ptp4l および ts2phc プログラムは、各 NIC に 1 つずつ存在する 2 つの PTP ハードウェアクロック (PHC) 上で動作するようにそれぞれ設定されています。ホストのシステムクロックは、GNSS タイムソースに接続されている NIC から同期されます。
次の PtpConfig CR の例をベースとして使用して、linuxptp サービスをデュアル Intel Westport Channel E810-XXVDA4T ネットワークインターフェイスの T-GM として設定してください。
PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 2 つの Intel E810 Westport Channel NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。次の YAML を
grandmaster-clock-ptp-config-dual-nics.yamlファイルに保存します。例15.2 デュアル E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記E810 Westport Channel NIC の場合は、
ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f grandmaster-clock-ptp-config-dual-nics.yaml
$ oc create -f grandmaster-clock-ptp-config-dual-nics.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m2g 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x7zkf 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.4.2. 3 カード E810 NIC のグランドマスタークロックとして linuxptp サービスを設定する リンクのコピーリンクがクリップボードにコピーされました!
NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 3 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。
次の E810 NIC の場合、3 枚の NIC を使用する T-GM として linuxptp サービスを設定できます。
- Intel E810-XXVDA4T Westport Channel NIC
- Intel E810-CQDA2T Logan Beach NIC
分散型 RAN (D-RAN) のユースケースでは、次の方法で 3 カード NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) に同期します。
- NIC 2 と 3 を、1PPS フェイスプレート接続で NIC 1 に同期します。
次の PtpConfig CR の例をベースとして使用し、linuxptp サービスを 3 カード Intel E810 の T-GM として設定します。
前提条件
- 実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 3 枚の Intel E810 NIC がインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を作成します。以下に例を示します。次の YAML を
three-nic-grandmaster-clock-ptp-config.yamlファイルに保存します。例15.3 3 カード E810 NIC の PTP グランドマスタークロック設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ts2phc.nmea_serialportの値を/dev/gnss0に設定します。以下のコマンドを実行して CR を作成します。
oc create -f three-nic-grandmaster-clock-ptp-config.yaml
$ oc create -f three-nic-grandmaster-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-74m3q 3/3 Running 3 4d15h 10.16.230.7 compute-1.example.com ptp-operator-5f4f48d7c-x6zkn 1/1 Running 1 4d15h 10.128.1.145 compute-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。次のコマンドを実行し、
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを調べます。oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.5. グランドマスタークロックの PtpConfig 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
このリファレンスでは、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロックとして設定する PtpConfig カスタムリソース (CR) の設定オプションを説明します。
| PtpConfig CR フィールド | 説明 |
|---|---|
|
|
grandmaster クロック動作用に NIC を設定する
プラグインメカニズムにより、PTP Operator は自動ハードウェア設定を行うことができます。Intel Westport Channel NIC の場合、 |
|
|
|
|
|
|
|
| データを破棄する前に、送信者からの送信 (TX) タイムスタンプを待機する最大時間を指定します。 |
|
| JBOD 境界クロック時間遅延値を指定します。この値は、ネットワーク時間デバイス間で受け渡される時間値を修正するために使用されます。 |
|
|
注記
ここにリストされているネットワークインターフェイスがグランドマスターとして設定されており、 |
|
|
|
|
|
|
|
|
任意。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
15.2.5.1. グランドマスタークロッククラスの同期状態のリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、PTP グランドマスタークロック (T-GM) の gm.ClockClass の状態を示しています。クロッククラスの状態では、Primary Reference Time Clock (PRTC) またはその他のタイミングソースに関連する精度と安定性に基づいて T-GM クロックが分類されます。
ホールドオーバー仕様とは、PTP クロックがプライマリータイムソースから更新を受信せずに同期を維持できる時間です。
| クロッククラスの状態 | 説明 |
|---|---|
|
|
T-GM クロックは |
|
|
T-GM クロックは |
|
|
T-GM クロックは |
詳細は、"Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations を参照してください。
15.2.5.2. Intel Westport Channel E810 ハードウェア設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、Intel E810-XXVDA4T ハードウェアプラグイン を使用して E810 ネットワークインターフェイスを PTP グランドマスタークロックとして設定する方法を説明します。ハードウェアピンの設定により、ネットワークインターフェイスがシステム内の他のコンポーネントやデバイスとどのようにやり取りするかが決まります。E810-XXVDA4T NIC には、外部 1PPS 信号用の 4 つのコネクター (SMA1、SMA2、U.FL1、および U.FL2) があります。
| ハードウェアピン | 推奨設定 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SMA1 コネクターと U.FL1 コネクターはチャネル 1 を共有します。SMA2 コネクターと U.FL2 コネクターはチャネル 2 を共有します。
PtpConfig カスタムリソース (CR) で GNSS クロックを設定するには、spec.profile.plugins.e810.ublxCmds パラメーターを設定します。
T-GM GPS アンテナケーブルシグナルの遅延を補正するには、オフセット値を設定する必要があります。最適な T-GM アンテナオフセット値を設定するには、GNSS アンテナケーブルシグナルの遅延を正確に測定します。Red Hat はこの測定をサポートしたり、必要な遅延オフセットの値を提供したりすることはできません。
これらの ublxCmds スタンザはそれぞれ、ubxtool コマンドを使用してホスト NIC に適用する設定と対応しています。以下に例を示します。
- 1
- 測定された T-GM アンテナ遅延オフセット (ナノ秒単位)。必要な遅延オフセット値を取得するには、外部テスト機器を使用してケーブル遅延を測定する必要があります。
次の表は、同等の ubxtool コマンドを示しています。
| ubxtool コマンド | 説明 |
|---|---|
|
|
アンテナ電圧制御を有効にし、 |
|
| アンテナが GPS 信号を受信できるようにします。 |
|
| Galileo GPS 衛星から信号を受信するようにアンテナを設定します。 |
|
| アンテナが GLONASS GPS 衛星から信号を受信できないようにします。 |
|
| アンテナが BeiDou GPS 衛星から信号を受信できないようにします。 |
|
| アンテナが SBAS GPS 衛星から信号を受信できないようにします。 |
|
| GNSS 受信機のサーベイインプロセスを設定して、初期位置の推定を改善します。最適な結果が得られるまでに最大 24 時間かかる場合があります。 |
|
| ハードウェアの自動スキャンを 1 回実行し、NIC の状態と構成設定を報告します。 |
15.2.5.3. デュアル E810 Westport Channel NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、Intel E810-XXVDA4T ハードウェアプラグイン を使用して、E810 ネットワークインターフェイスのペアを PTP グランドマスタークロック (T-GM) として設定する方法を説明します。
デュアル NIC クラスターホストを設定する前に、1PPS フェイスプレート接続を使用して 2 つの NIC を SMA1 ケーブルで接続する必要があります。
デュアル NIC T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。
| PtpConfig フィールド | 説明 |
|---|---|
|
| PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。
|
|
|
|
|
|
複数の NIC のサポートを有効にするには、 |
15.2.5.4. 3 カード E810 NIC 設定リファレンス リンクのコピーリンクがクリップボードにコピーされました!
ここでは、3 カード E810 NIC を PTP グランドマスタークロック (T-GM) として設定する方法を説明します。
3 カードのクラスターホストを設定する前に、1PPS フェースプレート接続を使用して 3 枚の NIC を接続する必要があります。プライマリー NIC の 1PPS_out 出力は、他の 2 枚の NIC に提供されます。
3 カードの T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。
| PtpConfig フィールド | 説明 |
|---|---|
|
| PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。
|
|
|
|
|
|
複数の NIC のサポートを有効にするには、 |
15.2.6. PTP グランドマスタークロックの動的なうるう秒処理の設定 リンクのコピーリンクがクリップボードにコピーされました!
PTP Operator コンテナーイメージには、リリース時に利用可能な最新の leap-seconds.list ファイルが含まれています。PTP Operator は、Global Positioning System (GPS) アナウンスを使用してうるう秒ファイルを自動的に更新するように設定できます。
うるう秒情報は、openshift-ptp namespace の leap-configmap という名前の自動生成された ConfigMap リソースに保存されます。PTP Operator は、ts2phc プロセスがアクセスできる linuxptp-daemon Pod 内のボリュームとして leap-configmap リソースをマウントします。
GPS 衛星が新しいうるう秒データをブロードキャストすると、PTP Operator は leap-configmap リソースを新しいデータで更新します。ts2phc プロセスは変更を自動的に取得します。
次の手順は参考用です。PTP Operator のバージョン 4.16 では、デフォルトで自動うるう秒管理が有効になります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールし、クラスターに PTP グランドマスタークロック (T-GM) を設定した。
手順
PtpConfigCR のphc2sysOptsセクションで自動うるう秒処理を設定します。以下のオプションを設定します。phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 24
phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 241 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記以前は、過去のうるう秒を考慮するために、
phc2sys設定 (-O -37) のオフセット調整が T-GM に必要でした。これは不要になりました。PtpConfigCR のspec.profile.plugins.e810.ublxCmdsセクションで、GPS レシーバーによるNAV-TIMELSメッセージの定期的な報告を有効にするように Intel e810 NIC を設定します。以下に例を示します。- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"- args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定した T-GM が接続先の GPS から
NAV-TIMELSメッセージを受信していることを確認します。以下のコマンドを実行します。oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20
$ oc -n openshift-ptp -c linuxptp-daemon-container exec -it $(oc -n openshift-ptp get pods -o name | grep daemon) -- ubxtool -t -p NAV-TIMELS -P 29.20Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow leap-configmapリソースが PTP Operator によって正常に生成され、leap-seconds.list の最新バージョンに更新されていることを確認します。以下のコマンドを実行します。oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'$ oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.7. linuxptp サービスを境界クロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l、phc2sys を設定できます。
次の例の PtpConfig CR を、特定のハードウェアおよび環境の境界クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfigCR を作成してから、YAML をboundary-clock-ptp-config.yamlファイルに保存します。PTP 境界クロックの設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表15.7 PTP 境界クロックの CR 設定オプション CR フィールド 説明 namePtpConfigCR の名前。profile1 つ以上の
profileオブジェクトの配列を指定します。nameプロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
ptp4lOptsptp4lサービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>およびサービス設定ファイル-f /etc/ptp4l.confを含めないでください。ptp4lConfptp4lを境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0はグランドマスタークロックから同期し、ens1f3は接続されたデバイスを同期します。<interface_1>同期クロックを受信するインターフェイス。
<interface_2>synchronization クロックを送信するインターフェイス。
tx_timestamp_timeoutIntel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeoutを50に設定します。boundary_clock_jbodIntel Columbiaville 800 Series NIC の場合、
boundary_clock_jbodが0に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、boundary_clock_jbodが1に設定されていることを確認します。phc2sysOptsphc2sysサービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sysサービスを開始しません。ptpSchedulingPolicyptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は
SCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。ptpSchedulingPriorityptpSchedulingPolicyがSCHED_FIFOに設定されている場合に、ptp4lおよびphc2sysプロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriorityフィールドは、ptpSchedulingPolicyがSCHED_OTHERに設定されている場合は使用されません。ptpClockThreshold任意。
ptpClockThresholdが存在しない場合、ptpClockThresholdフィールドにはデフォルト値が使用されます。ptpClockThresholdは、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。recommendprofileがノードに適用される方法を定義する 1 つ以上のrecommendオブジェクトの配列を指定します。.recommend.profileprofileセクションで定義される.recommend.profileオブジェクト名を指定します。.recommend.priority0から99までの整数値でpriorityを指定します。数値が大きいほど優先度が低くなるため、99の優先度は10よりも低くなります。ノードがmatchフィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。.recommend.match.recommend.matchルールをnodeLabelまたはnodeNameの値に指定します。.recommend.match.nodeLabeloc get nodes --show-labelsコマンドを使用して、ノードオブジェクトのnode.LabelsフィールドのkeyでnodeLabelを設定します。例:node-role.kubernetes.io/worker。.recommend.match.nodeNameoc get nodesコマンドを使用して、nodeNameをノードオブジェクトのnode.Nameフィールドの値に設定します。compute-1.example.comはその例です。以下のコマンドを実行して CR を作成します。
oc create -f boundary-clock-ptp-config.yaml
$ oc create -f boundary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.7.1. linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
NIC ごとに PtpConfig カスタムリソース (CR) オブジェクトを作成することにより、linuxptp サービス (ptp4l、phc2sys) をデュアル NIC ハードウェアの境界クロックとして設定できます。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
「linuxptp サービスを境界クロックとして設定」の参照 CR を各 CR の基礎として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfigCR を作成します。以下に例を示します。phc2sysOptsの値を指定して、boundary-clock-ptp-config-nic1.yamlを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow boundary-clock-ptp-config-nic2.yamlを作成し、phc2sysOptsフィールドを完全に削除して、2 番目の NIC のphc2sysサービスを無効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 2 番目の NIC の境界クロックとして
ptp4lを開始するために必要なインターフェイスを指定します。
注記2 番目の NIC で
phc2sysサービスを無効にするには、2 番目のPtpConfigCR からphc2sysOptsフィールドを完全に削除する必要があります。
次のコマンドを実行して、デュアル NIC
PtpConfigCR を作成します。1 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic1.yaml
$ oc create -f boundary-clock-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 2 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic2.yaml
$ oc create -f boundary-clock-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PTP Operator が両方の NIC に
PtpConfigCRを適用していることを確認してください。デュアル NIC ハードウェアがインストールされているノードに対応するlinuxptpデーモンのログを調べます。たとえば、以下のコマンドを実行します。oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539
ptp4l[80828.335]: [ptp4l.1.config] master offset 5 s2 freq -5727 path delay 519 ptp4l[80828.343]: [ptp4l.0.config] master offset -5 s2 freq -10607 path delay 533 phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1 s2 freq -87239 delay 539Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.7.2. デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する リンクのコピーリンクがクリップボードにコピーされました!
linuxptp サービス ptp4l および phc2sys を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。
高可用性システムクロックは、2 つの境界クロックとして設定されたデュアル NIC Intel E810 Salem チャネルハードウェアからの複数のタイムソースを使用します。2 つの境界クロックインスタンスが HA セットアップに参加し、それぞれ独自の設定プロファイルを持ちます。各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給します。
NIC を T-BC として設定する 2 つの PtpConfig カスタムリソース (CR) オブジェクトと、2 つの NIC 間の高可用性を設定する 3 番目の PtpConfig CR を作成します。
HA を設定する PtpConfig CR で phc2SysOpts オプションを 1 回設定します。2 つの NIC を設定する PtpConfig CR で phc2sysOpts フィールドを空の文字列に設定します。これにより、2 つのプロファイルに対して個別の phc2sys プロセスがセットアップされなくなります。
3 番目の PtpConfig CR は、高可用性システムクロックサービスを設定します。CR は、ptp4l プロセスが実行されないように、ptp4lOpts フィールドを空の文字列に設定します。CR は、spec.profile.ptpSettings.haProfiles キーの下に ptp4l 設定のプロファイルを追加し、それらのプロファイルのカーネルソケットパスを phc2sys サービスに渡します。ptp4l 障害が発生すると、phc2sys サービスはバックアップ ptp4l 設定に切り替わります。プライマリープロファイルが再びアクティブになると、phc2sys サービスは元の状態に戻ります。
HA を設定するために使用する 3 つの PtpConfig CR すべてに対して、spec.recommend.priority を同じ値に設定していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
- Intel E810 Salem チャネルデュアル NIC を使用してクラスターノードを設定します。
手順
「linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定」の CR を各 CR の参照として使用して、NIC ごとに 1 つずつ、2 つの個別の
PtpConfigCR を作成します。phc2sysOptsフィールドに空の文字列を指定して、ha-ptp-config-nic1.yamlファイルを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、NIC 1 に
PtpConfigCR を適用します。oc create -f ha-ptp-config-nic1.yaml
$ oc create -f ha-ptp-config-nic1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow phc2sysOptsフィールドに空の文字列を指定して、ha-ptp-config-nic2.yamlファイルを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、NIC 2 に
PtpConfigCR を適用します。oc create -f ha-ptp-config-nic2.yaml
$ oc create -f ha-ptp-config-nic2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
HA システムクロックを設定する
PtpConfigCR を作成します。以下に例を示します。ptp-config-for-ha.yamlファイルを作成します。2 つの NIC を設定するPtpConfigCR で設定されているmetadata.nameフィールドと一致するようにhaProfilesを設定します。例:haProfiles: ha-ptp-config-nic1,ha-ptp-config-nic2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ptp4lOptsフィールドを空の文字列に設定します。空でない場合、p4ptlプロセスは重大なエラーで開始されます。
重要個々の NIC を設定する
PtpConfigCR の前に、高可用性PtpConfigCR を適用しないでください。次のコマンドを実行して、HA
PtpConfigCR を適用します。oc create -f ptp-config-for-ha.yaml
$ oc create -f ptp-config-for-ha.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PTP Operator が
PtpConfigCR を正しく適用したことを確認します。以下の手順を実行します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkrb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com ptp-operator-657bbq64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記linuxptp-daemonPod は 1 つだけ存在する必要があります。次のコマンドを実行して、プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.8. linuxptp サービスを通常のクロックとして設定 リンクのコピーリンクがクリップボードにコピーされました!
PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l、phc2sys) を通常のクロックとして設定できます。
次の例の PtpConfig CR を、特定のハードウェアおよび環境の通常クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効な場合にのみ必要です。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
以下の
PtpConfigCR を作成してから、YAML をordinary-clock-ptp-config.yamlファイルに保存します。PTP 通常クロックの設定例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表15.8 PTP 通常クロック CR 設定のオプション CR フィールド 説明 namePtpConfigCR の名前。profile1 つ以上の
profileオブジェクトの配列を指定します。各プロファイルの名前は一意である必要があります。interfaceptp4lサービスで使用するネットワークインターフェイスを指定します (例:ens787f1)。ptp4lOptsptp4lサービスのシステム設定オプションを指定します。たとえば、-2で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>およびサービス設定ファイル-f /etc/ptp4l.confを含めないでください。このインターフェイスで PTP 高速イベントを使用するには、--summary_interval -4を追加します。phc2sysOptsphc2sysサービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sysサービスを開始しません。Intel Columbiaville 800 Series NIC の場合、phc2sysOptsオプションを-a -r -m -n 24 -N 8 -R 16に設定します。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリックを生成します。ptp4lConfデフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。tx_timestamp_timeoutIntel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeoutを50に設定します。boundary_clock_jbodIntel Columbiaville 800 Series NIC の場合、
boundary_clock_jbodを0に設定します。ptpSchedulingPolicyptp4lとphc2sysプロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。ptpSchedulingPriorityptpSchedulingPolicyがSCHED_FIFOに設定されている場合に、ptp4lおよびphc2sysプロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriorityフィールドは、ptpSchedulingPolicyがSCHED_OTHERに設定されている場合は使用されません。ptpClockThreshold任意。
ptpClockThresholdが存在しない場合、ptpClockThresholdフィールドにはデフォルト値が使用されます。ptpClockThresholdは、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。recommendprofileがノードに適用される方法を定義する 1 つ以上のrecommendオブジェクトの配列を指定します。.recommend.profileprofileセクションで定義される.recommend.profileオブジェクト名を指定します。.recommend.priority通常クロックの
.recommend.priorityを0に設定します。.recommend.match.recommend.matchルールをnodeLabelまたはnodeNameの値に指定します。.recommend.match.nodeLabeloc get nodes --show-labelsコマンドを使用して、ノードオブジェクトのnode.LabelsフィールドのkeyでnodeLabelを設定します。例:node-role.kubernetes.io/worker。.recommend.match.nodeNameoc get nodesコマンドを使用して、nodeNameをノードオブジェクトのnode.Nameフィールドの値に設定します。compute-1.example.comはその例です。次のコマンドを実行して、
PtpConfigCR を作成します。oc create -f ordinary-clock-ptp-config.yaml
$ oc create -f ordinary-clock-ptp-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
PtpConfigプロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptpnamespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-4xkbb 1/1 Running 0 43m 10.1.196.24 compute-0.example.com linuxptp-daemon-tdspf 1/1 Running 0 43m 10.1.196.25 compute-1.example.com ptp-operator-657bbb64c8-2f8sj 1/1 Running 0 43m 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロファイルが正しいことを確認します。
PtpConfigプロファイルで指定したノードに対応するlinuxptpデーモンのログを検査します。以下のコマンドを実行します。oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container
$ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.8.1. PTP の通常クロックリファレンスとしての Intel Columbiaville E800 シリーズ NIC リンクのコピーリンクがクリップボードにコピーされました!
次の表は、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために、PTP リファレンス設定に加える必要がある変更を説明します。クラスターに適用する PtpConfig カスタムリソース (CR) に変更を加えます。
| PTP 設定 | 推奨設定 |
|---|---|
|
|
|
|
|
|
|
|
|
phc2sysOpts の場合、-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。
15.2.9. PTP ハードウェアの FIFO 優先スケジューリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
低遅延のパフォーマンスを確保する必要のある通信業者などのデプロイメントタイプでは、PTP デーモンスレッドが、残りのインフラストラクチャーコンポーネントとともに、限られた CPU リソースで実行されます。デフォルトでは、PTP スレッドは SCHED_OTHER ポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。
スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFO ポリシーでスレッドを実行できるように、PTP Operator の linuxptp サービスを設定できます。PtpConfig CR に SCHED_FIFO が設定されている場合には、ptp4l と phc2sys は、PtpConfig CR の ptpSchedulingPriority フィールドで設定された優先順位で、chrt の下の親コンテナーで実行されます。
ptpSchedulingPolicy の設定は任意です。レイテンシーエラーが発生している場合にのみ必要です。
手順
PtpConfigCR プロファイルを編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow ptpSchedulingPolicyとptpSchedulingPriorityフィールドを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
保存して終了すると、
PtpConfigCR に変更が適用されます。
検証
PtpConfigCR が適用されたlinuxptp-daemonPod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow ptp4lプロセスが、更新されたchrtFIFO 優先度で実行されていることを確認します。oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt
$ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -m
I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2 --summary_interval -4 -mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.10. linuxptp サービスのログフィルタリングの設定 リンクのコピーリンクがクリップボードにコピーされました!
linuxptp デーモンは、デバッグに使用できるログを生成します。ストレージ容量が制限されている通信業者などのデプロイメントタイプでは、これらのログによりストレージ需要が増大する可能性があります。
ログメッセージの数を減らすために、PtpConfig カスタムリソース (CR) を設定して、master offset 値をレポートするログメッセージを除外できます。master offset ログメッセージは、現在のノードのクロックとマスタークロックの違いをナノ秒単位でレポートします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfigCR を編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.profileで、ptpSettings.logReduce仕様を追加し、値をtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デバッグの目的で、この仕様を
Falseに戻すと、マスターオフセットメッセージを含めることができます。-
保存して終了すると、
PtpConfigCR に変更が適用されます。
検証
PtpConfigCR が適用されたlinuxptp-daemonPod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-gmv2n 3/3 Running 0 1d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-lgm55 3/3 Running 0 1d17h 10.1.196.25 compute-1.example.com ptp-operator-3r4dcvf7f4-zndk7 1/1 Running 0 1d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マスターオフセットメッセージがログから除外されていることを確認します。
oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <linux_daemon_container> は、
linuxptp-daemonPod の名前です (例:linuxptp-daemon-gmv2n)。
logReduce仕様を設定する場合、このコマンドはlinuxptpデーモンのログにmaster offsetのインスタンスを報告しません。
15.2.11. 一般的な PTP Operator の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を実行して、PTP Operator で典型的な問題のトラブルシューティングを行います。
前提条件
-
OpenShift Container Platform CLI (
oc) をインストールします。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP をサポートするホストを使用して、PTP Operator をベアメタルクラスターにインストールします。
手順
Operator およびオペランドが、設定されたノードについてクラスターに正常にデプロイされていることを確認します。
oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記PTP 高速イベントバスが有効な場合には、準備できた
linuxptp-daemonPod の数は3/3になります。PTP 高速イベントバスが有効になっていない場合、2/2が表示されます。サポートされているハードウェアがクラスターにあることを確認します。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードで利用可能な PTP ネットワークインターフェイスを確認します。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <node_name>
問い合わせるノードを指定します (例:
compute-0.example.com)。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
対応するノードの
linuxptp-daemonPod にアクセスし、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。以下のコマンドを実行して、
linuxptp-daemonPod の名前と、トラブルシューティングに使用するノードを取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE linuxptp-daemon-lmvgn 3/3 Running 0 4d17h 10.1.196.24 compute-0.example.com linuxptp-daemon-qhfg7 3/3 Running 0 4d17h 10.1.196.25 compute-1.example.com ptp-operator-6b8dcbf7f4-zndk7 1/1 Running 0 5d7h 10.129.0.61 control-plane-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow リモートシェルが必要な
linuxptp-daemonコンテナーへのリモートシェルです。oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <linux_daemon_container>
-
診断するコンテナーです (例:
linuxptp-daemon-lmvgn)。
linuxptp-daemonコンテナーへのリモートシェル接続では、PTP 管理クライアント (pmc) ツールを使用して、ネットワークインターフェイスを診断します。以下のpmcコマンドを実行して、PTP デバイスの同期ステータスを確認します (例:ptp4l)。pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'
# pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードがプライマリークロックに正常に同期されたときの出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
GNSS をソースとするグランドマスタークロックの場合は、次のコマンドを実行して、ツリー内 NIC ice ドライバーが正しいことを確認します。
oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-74m2g ethtool -i ens7f0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0
driver: ice version: 5.14.0-356.bz2232515.el9.x86_64 firmware-version: 4.20 0x8001778b 1.3346.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow GNSS をソースとするグランドマスタークロックの場合は、
linuxptp-daemonコンテナーが GNSS アンテナから信号を受信していることを確認します。コンテナーが GNSS 信号を受信していない場合、/dev/gnss0ファイルにデータが入力されません。検証するには、次のコマンドを実行します。oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container linuxptp-daemon-jnz6r cat /dev/gnss0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62
$GNRMC,125223.00,A,4233.24463,N,07126.64561,W,0.000,,300823,,,A,V*0A $GNVTG,,T,,M,0.000,N,0.000,K,A*3D $GNGGA,125223.00,4233.24463,N,07126.64561,W,1,12,99.99,98.6,M,-33.1,M,,*7E $GNGSA,A,3,25,17,19,11,12,06,05,04,09,20,,,99.99,99.99,99.99,1*37 $GPGSV,3,1,10,04,12,039,41,05,31,222,46,06,50,064,48,09,28,064,42,1*62Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.12. Intel 800 シリーズ NIC の CGU の DPLL ファームウェアバージョンを取得する リンクのコピーリンクがクリップボードにコピーされました!
クラスターノードへのデバッグシェルを開き、NIC ハードウェアを照会することで、Intel 800 シリーズ NIC の Clock Generation Unit (CGU) の digital phase-locked loop (DPLL) ファームウェアバージョンを取得できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - クラスターホストに Intel 800 シリーズ NIC がインストールされている。
- PTP をサポートするホストを含むベアメタルクラスターに PTP Operator をインストールしている。
手順
次のコマンドを実行してデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <node_name>
- Intel 800 シリーズ NIC をインストールしたノードです。
devlinkツールと、NIC がインストールされているバスおよびデバイス名を使用して、NIC の CGU ファームウェアバージョンを確認します。たとえば、以下のコマンドを実行します。devlink dev info <bus_name>/<device_name> | grep cgu
sh-4.4# devlink dev info <bus_name>/<device_name> | grep cguCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <bus_name>
-
NIC がインストールされているバスです (例:
pci)。 - <device_name>
-
NIC デバイス名です (例:
0000:51:00.0)。
出力例
cgu.id 36 fw.cgu 8032.16973825.6021
cgu.id 361 fw.cgu 8032.16973825.60212 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ファームウェアバージョンには、先頭のニブルと、バージョン番号の各部分に対する 3 つのオクテットがあります。
16973825を 2 進数で表すと0001 0000 0011 0000 0000 0000 0001になります。バイナリー値を使用してファームウェアバージョンをデコードします。以下に例を示します。Expand 表15.10 DPLL ファームウェアバージョン バイナリー部分 10 進数値 00011
0000 00113
0000 00000
0000 00011
15.2.13. PTP Operator データの収集 リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather コマンドを使用すると、PTP Operator に関連する機能やオブジェクトなど、クラスターに関する情報を収集できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 - PTP Operator がインストールされている。
手順
must-gatherを使用して PTP Operator データを収集するには、PTP Operatormust-gatherイメージを指定する必要があります。oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.16
$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel9:v4.16Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. REST API v2 を使用した PTP イベントコンシューマーアプリケーションの開発 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v2 を使用して PTP イベントをサブスクライブします。
以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。
15.3.1. PTP 高速イベント通知フレームワークについて リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) 高速イベント REST API v2 を使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。
高速イベント通知フレームワークは、通信に REST API を使用します。PTP イベント REST API v1 および v2 は、O-RAN ALLIANCE Specifications で提供されている O-RAN O-Cloud Notification API Specification for Event Consumers 4.0 に基づいています。
PTP イベント REST API v2 のみが O-RAN v4 に準拠しています。
15.3.2. PTP イベント REST API v2 を使用した PTP イベントの取得 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションは、プロデューサー側のクラウドイベントプロキシーサイドカーで O-RAN v4 互換の REST API を使用して PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。
図15.5 PTP イベントプロデューサー REST API v2 からの PTP 高速イベントの使用の概要
-
イベントはクラスターホストで生成されます。 -
PTP Operator が管理する Pod の
linuxptp-daemonプロセスは、KubernetesDaemonSetとして実行され、さまざまなlinuxptpプロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用のts2phc) を管理します。linuxptp-daemonは、イベントを UNIX ドメインソケットに渡します。 -
イベントが cloud-event-proxy サイドカーに渡されます。 -
PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーに渡します。cloud-event-proxyは、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。 -
イベントが公開される -
PTP Operator 管理 Pod 内の
cloud-event-proxyサイドカーはイベントを処理し、PTP イベント REST API v2 を使用してイベントを公開します。 -
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します -
コンシューマーアプリケーションは、プロデューサー
cloud-event-proxyサイドカーに API リクエストを送信して、PTP イベントサブスクリプションを作成します。サブスクライブされると、コンシューマーアプリケーションはリソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。
15.3.3. PTP 高速イベント通知パブリッシャーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のネットワークインターフェイスの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース (CR) で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator がインストールされている。
手順
デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
次の YAML を
ptp-operatorconfig.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfigリソースのspec.ptpEventConfig.transportHostフィールドを設定する必要はありません。PtpOperatorConfigCR を更新します。oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP 対応インターフェイスの
PtpConfigカスタムリソースを作成し、ptpClockThresholdおよびptp4lOptsに必要な値を設定します。次の YAML は、PtpConfigCR で設定する必要のある値 (必須) を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--summary_interval -4を追加して、PTP 高速イベントを使用します。- 2
phc2sysOptsの値が必要です。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリックを生成します。- 3
- デフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。 - 4
- 任意。
ptpClockThresholdスタンザが存在しない場合は、ptpClockThresholdフィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold値を示します。ptpClockThreshold値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。
15.3.4. PTP イベント REST API v2 コンシューマーアプリケーションリファレンス リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションには次の機能が必要です。
-
POSTハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス -
PTP イベントプロデューサーをサブスクライブするための
createSubscription関数 -
PTP イベントプロデューサーの現在の状態をポーリングする
getCurrentState関数
次の Go スニペットの例は、これらの要件を示しています。
Go での PTP イベントコンシューマーサーバー関数の例
PTP イベントの例 Go の createSubscription 関数
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
Go の PTP イベントコンシューマー getCurrentState 関数の例
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
15.3.5. PTP イベント REST API v2 を使用したイベントコンシューマーのデプロイメントとサービス CR の参照 リンクのコピーリンクがクリップボードにコピーされました!
PTP イベント REST API v2 で使用するために PTP イベントコンシューマーアプリケーションをデプロイする場合は、次の PTP イベントコンシューマーカスタムリソース (CR) の例を参照として使用します。
参照クラウドイベントコンシューマー namespace
リファレンスクラウドイベントコンシューマーのデプロイメント
参照クラウドイベントコンシューマーサービスアカウント
apiVersion: v1 kind: ServiceAccount metadata: name: consumer-sa namespace: cloud-events
apiVersion: v1
kind: ServiceAccount
metadata:
name: consumer-sa
namespace: cloud-events
リファレンスクラウドイベントコンシューマーサービス
15.3.6. REST API v2 を使用した PTP イベントのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
cloud-event-consumer アプリケーションコンテナーをデプロイし、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーが投稿する PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
適切なサブスクリプション要求ペイロードを渡して、http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions に POST 要求を送信することにより、コンシューマーアプリケーションを PTP イベントにサブスクライブします。
9043 は、PTP イベントプロデューサー Pod にデプロイされた cloud-event-proxy コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。
15.3.7. PTP イベント REST API v2 コンシューマーアプリケーションがイベントを受信していることを確認 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーション Pod 内の cloud-event-consumer コンテナーが Precision Time Protocol (PTP) イベントを受信していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールして設定している。
- クラウドイベントアプリケーション Pod と PTP イベントコンシューマーアプリケーションをデプロイしている。
手順
デプロイされたイベントコンシューマーアプリケーションのログを確認します。たとえば、以下のコマンドを実行します。
oc -n cloud-events logs -f deployment/cloud-consumer-deployment
$ oc -n cloud-events logs -f deployment/cloud-consumer-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 任意。
linuxptp-daemonデプロイメントからocとポート転送ポート9043を使用して REST API をテストします。たとえば、以下のコマンドを実行します。oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043
$ oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043
Forwarding from 127.0.0.1:9043 -> 9043 Forwarding from [::1]:9043 -> 9043 Handling connection for 9043Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいシェルプロンプトを開き、REST API v2 エンドポイントをテストします。
curl -X GET http://localhost:9043/api/ocloudNotifications/v2/health
$ curl -X GET http://localhost:9043/api/ocloudNotifications/v2/healthCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
OK
OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3.8. PTP 高速イベントメトリックのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
linuxptp-daemon が実行されているクラスターノードから PTP 高速イベントメトリクスを監視できます。事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。
手順
次のコマンドを実行して、ノードのデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow linuxptp-daemonコンテナーによって公開された PTP メトリックを確認します。たとえば、以下のコマンドを実行します。curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 任意。
cloud-event-proxyコンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例:
openshift_ptp_offset_ns) をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
15.3.9. PTP 高速イベントメトリクスのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 ( |
|
|
|
インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、 |
|
|
| タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。 |
|
|
|
異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 ( |
|
|
|
2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック ( |
|
|
|
インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 ( |
|
|
|
2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC ( |
|
|
| DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。 |
|
|
|
|
|
|
| PTP プロセスが実行中かどうかを示すステータスコードを返します。 |
|
|
|
|
|
T-GM が有効な場合のみ PTP 高速イベントメトリクス
次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 ( |
|
|
|
NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 ( |
|
|
|
NIC の DPLL 位相のステータスを返します。可能な値は、-1 ( |
|
|
|
NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 ( |
|
|
|
Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 ( |
|
15.4. PTP イベント REST API v2 リファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の REST API v2 エンドポイントを使用して、PTP イベントプロデューサー Pod の http://localhost:9043/api/ocloudNotifications/v2 に投稿された Precision Time Protocol (PTP) イベントに cloud-event-consumer アプリケーションをサブスクライブします。
api/ocloudNotifications/v2/subscriptions-
POST: 新しいサブスクリプションを作成します。 -
GET: サブスクリプションの一覧を取得します。 -
DELETE: すべてのサブスクリプションを削除します
-
api/ocloudNotifications/v2/subscriptions/{subscription_id}-
GET: 指定されたサブスクリプション ID の詳細を返します。 -
DELETE: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
-
api/ocloudNotifications/v2/health-
GET:ocloudNotificationsAPI の正常性ステータスを返します
-
api/ocloudNotifications/v2/publishers-
GET: クラスターノードの PTP イベントパブリッシャーのリストを返します。
-
api/ocloudnotifications/v2/{resource_address}/CurrentState-
GET:{resouce_address}で指定されたイベントタイプの現在の状態を返します。
-
15.4.1. PTP イベント REST API v2 エンドポイント リンクのコピーリンクがクリップボードにコピーされました!
15.4.1.1. api/ocloudNotifications/v2/subscriptions リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/subscriptions
説明
サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。
API 応答の例
HTTP メソッド
POST api/ocloudNotifications/v2/subscriptions
説明
適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。
次の PTP イベントをサブスクライブできます。
-
sync-stateイベント -
lock-stateイベント -
gnss-sync-status eventsイベント -
os-clock-sync-stateイベント -
clock-classイベント
| パラメーター | 型 |
|---|---|
| subscription | data |
同期状態サブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
PTP ロック状態イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP gnss-sync-status イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
PTP os-clock-sync-state イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class イベントサブスクリプションペイロードの例
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
API 応答の例
次のサブスクリプションステータスイベントが発生する可能性があります。
| ステータスコード | 説明 |
|---|---|
|
| サブスクリプションが作成されたことを示します。 |
|
| リクエストが不正または無効であったため、サーバーが要求を処理できなかったことを示します。 |
|
| サブスクリプションリソースが利用できないことを示します。 |
|
| サブスクリプションがすでに存在することを示します。 |
HTTP メソッド
DELETE api/ocloudNotifications/v2/subscriptions
説明
すべてのサブスクリプションを削除します。
API 応答の例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
15.4.1.2. api/ocloudNotifications/v2/subscriptions/{subscription_id} リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/subscriptions/{subscription_id}
説明
ID が subscription_id のサブスクリプションの詳細を返します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
HTTP メソッド
DELETE api/ocloudNotifications/v2/subscriptions/{subscription_id}
説明
ID subscription_id のサブスクリプションを削除します。
| パラメーター | 型 |
|---|---|
|
| string |
| HTTP レスポンス | 説明 |
|---|---|
| 204 No Content | Success |
15.4.1.3. api/ocloudNotifications/v2/health リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/health/
説明
ocloudNotifications REST API の正常性ステータスを返します。
| HTTP レスポンス | 説明 |
|---|---|
| 200 OK | Success |
15.4.1.4. api/ocloudNotifications/v2/publishers リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/publishers
説明
クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。
機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。
API 応答の例
| HTTP レスポンス | 説明 |
|---|---|
| 200 OK | Success |
15.4.1.5. api/ocloudNotifications/v2/{resource_address}/CurrentState リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
説明
クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。
-
os-clock-sync-state通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKEDまたはFREERUN状態になります。 -
clock-class通知は、PTP クロッククラスの現在の状態を説明します。 -
lock-state通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、またはFREERUN状態になります。 -
sync-state通知は、PTP クロックのlock-state状態とos-clock-sync-state状態のうち、最も同期されていない状態の現在のステータスを示します。 -
gnss-sync-status通知は、GNSS クロックの同期状態を説明します。
| パラメーター | 型 |
|---|---|
|
| string |
ロック状態 API レスポンスの例
os-clock-sync-state API レスポンスの例
clock-class API レスポンスの例
同期状態 API 応答の例
gnss-sync-state API 応答の例
15.5. REST API v1 を使用した PTP イベントコンシューマーアプリケーションの開発 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v1 を使用して PTP イベントをサブスクライブします。
以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。
PTP イベント REST API v1 は今後のリリースで廃止されます。PTP イベントを使用するアプリケーションを開発する場合は、PTP イベント REST API v2 を使用します。
15.5.1. PTP 高速イベント通知フレームワークについて リンクのコピーリンクがクリップボードにコピーされました!
Precision Time Protocol (PTP) 高速イベント REST API v2 を使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。
高速イベント通知フレームワークは、通信に REST API を使用します。PTP イベント REST API v1 および v2 は、O-RAN ALLIANCE Specifications で提供されている O-RAN O-Cloud Notification API Specification for Event Consumers 4.0 に基づいています。
PTP イベント REST API v2 のみが O-RAN v4 に準拠しています。
15.5.2. PTP イベント REST API v1 を使用した PTP イベントの取得 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションは、cloud-event-proxy コンテナーをサイドカーパターンで実行して、PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。
図15.6 コンシューマーサイドカーと HTTP メッセージトランスポートを使用した PTP 高速イベントの概要
-
イベントはクラスターホストで生成されます。 -
PTP Operator が管理する Pod の
linuxptp-daemonは、KubernetesDaemonSetとして実行され、さまざまなlinuxptpプロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用のts2phc) を管理します。linuxptp-daemonは、イベントを UNIX ドメインソケットに渡します。 -
イベントが cloud-event-proxy サイドカーに渡されます。 -
PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーに渡します。cloud-event-proxyは、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。 -
イベントが永続化される -
PTP Operator が管理する Pod 内の
cloud-event-proxyサイドカーは、REST API を使用してイベントを処理し、クラウドネイティブイベントを発行します。 -
メッセージはトランスポートされます。 -
メッセージトランスポーターは、HTTP 経由でアプリケーション Pod 内の
cloud-event-proxyサイドカーにイベントを転送します。 -
イベントは REST API から入手できます。 -
アプリケーション Pod の
cloud-event-proxyサイドカーはイベントを処理し、REST API を使用して利用できるようにします。 -
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します -
コンシューマーアプリケーションは、API 要求をアプリケーション Pod の
cloud-event-proxyサイドカーに送信して、PTP イベントサブスクリプションを作成します。cloud-event-proxyサイドカーは、サブスクリプションで指定されたリソースの HTTP メッセージングリスナープロトコルを作成します。
アプリケーション Pod の cloud-event-proxy サイドカーは、PTP Operator が管理する Pod からイベントを受信し、クラウドイベントオブジェクトをラッピング解除してデータを取得し、イベントをコンシューマーアプリケーションにポストします。コンシューマーアプリケーションは、リソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。
15.5.3. PTP 高速イベント通知パブリッシャーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のネットワークインターフェイスの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース (CR) で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator がインストールされている。
手順
デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
次の YAML を
ptp-operatorconfig.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
enableEventPublisherをtrueに設定して、PTP 高速イベント通知を有効にします。
注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfigリソースのspec.ptpEventConfig.transportHostフィールドを設定する必要はありません。PtpOperatorConfigCR を更新します。oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PTP 対応インターフェイスの
PtpConfigカスタムリソースを作成し、ptpClockThresholdおよびptp4lOptsに必要な値を設定します。次の YAML は、PtpConfigCR で設定する必要のある値 (必須) を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--summary_interval -4を追加して、PTP 高速イベントを使用します。- 2
phc2sysOptsの値が必要です。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリックを生成します。- 3
- デフォルトの
/etc/ptp4l.confファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。 - 4
- 任意。
ptpClockThresholdスタンザが存在しない場合は、ptpClockThresholdフィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold値を示します。ptpClockThreshold値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。
15.5.4. PTP イベントコンシューマーアプリケーションのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションには次の機能が必要です。
-
POSTハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス -
PTP イベントプロデューサーをサブスクライブするための
createSubscription関数 -
PTP イベントプロデューサーの現在の状態をポーリングする
getCurrentState関数
次の Go スニペットの例は、これらの要件を示しています。
Go での PTP イベントコンシューマーサーバー関数の例
PTP イベントの例 Go の createSubscription 関数
- 1
<node_name>を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.comはその例です。
Go の PTP イベントコンシューマー getCurrentState 関数の例
15.5.5. cloud-event-proxy のデプロイメントとサービス CR を参照する リンクのコピーリンクがクリップボードにコピーされました!
PTP イベントコンシューマーアプリケーションをデプロイするときは、次の cloud-event-proxy デプロイメントとサブスクライバサービス CR の例を参考として使用してください。
HTTP トランスポートを使用した cloud-event-proxy デプロイメントの参照
cloud-event-proxy サブスクライバーサービスの参照
15.5.6. REST API v1 を使用した PTP イベントのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
cloud-event-consumer アプリケーションコンテナーおよび cloud-event-proxy サイドカーコンテナーを別のアプリケーション Pod にデプロイします。
アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーによって投稿された PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。
15.5.7. PTP イベント REST API v1 コンシューマーアプリケーションがイベントを受信していることを確認 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーション Pod の cloud-event-proxy コンテナーが PTP イベントを受信していることを確認します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP Operator をインストールして設定している。
手順
アクティブな
linuxptp-daemonPod の一覧を取得します。以下のコマンドを実行します。oc get pods -n openshift-ptp
$ oc get pods -n openshift-ptpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8h
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 8h linuxptp-daemon-k8n88 3/3 Running 0 8hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、必要なコンシューマー側
cloud-event-proxyコンテナーのメトリックにアクセスします。oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
- <linuxptp-daemon>
問い合わせる Pod を指定します (例:
linuxptp-daemon-2t78p)。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.5.8. PTP 高速イベントメトリックのモニタリング リンクのコピーリンクがクリップボードにコピーされました!
linuxptp-daemon が実行されているクラスターノードから PTP 高速イベントメトリクスを監視できます。事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。
前提条件
-
OpenShift Container Platform CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。
手順
次のコマンドを実行して、ノードのデバッグ Pod を起動します。
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow linuxptp-daemonコンテナーによって公開された PTP メトリックを確認します。たとえば、以下のコマンドを実行します。curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 任意。
cloud-event-proxyコンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例:
openshift_ptp_offset_ns) をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
15.5.9. PTP 高速イベントメトリクスのリファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 ( |
|
|
|
インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、 |
|
|
| タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。 |
|
|
|
異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 ( |
|
|
|
2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック ( |
|
|
|
インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 ( |
|
|
|
2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC ( |
|
|
| DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。 |
|
|
|
|
|
|
| PTP プロセスが実行中かどうかを示すステータスコードを返します。 |
|
|
|
|
|
T-GM が有効な場合のみ PTP 高速イベントメトリクス
次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。
| メトリクス | 説明 | 例 |
|---|---|---|
|
|
NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 ( |
|
|
|
NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 ( |
|
|
|
NIC の DPLL 位相のステータスを返します。可能な値は、-1 ( |
|
|
|
NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 ( |
|
|
|
Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 ( |
|
15.6. PTP イベント REST API v1 リファレンス リンクのコピーリンクがクリップボードにコピーされました!
次の Precision Time Protocol (PTP) 高速イベント REST API v1 エンドポイントを使用して、アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーが投稿した PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。
PTP イベント REST API v1 は今後のリリースで廃止されます。PTP イベントを使用するアプリケーションを開発する場合は、PTP イベント REST API v2 を使用します。
以下の API エンドポイントを利用できます。
api/ocloudNotifications/v1/subscriptions-
POST: 新しいサブスクリプションを作成します。 -
GET: サブスクリプションの一覧を取得します。 -
DELETE: すべてのサブスクリプションを削除します
-
api/ocloudNotifications/v1/subscriptions/{subscription_id}-
GET: 指定されたサブスクリプション ID の詳細を返します。 -
DELETE: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
-
api/ocloudNotifications/v1/health-
GET:ocloudNotificationsAPI の正常性ステータスを返します
-
api/ocloudNotifications/v1/publishers-
GET: クラスターノードの PTP イベントパブリッシャーのリストを返します。
-
api/ocloudnotifications/v1/{resource_address}/CurrentState-
GET:sync-state、os-clock-sync-state、clock-class、lock-state、またはgnss-sync-statusイベントのいずれかの現在の状態を返します。
-
15.6.1. PTP イベント REST API v1 エンドポイント リンクのコピーリンクがクリップボードにコピーされました!
15.6.1.1. api/ocloudNotifications/v1/subscriptions リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions
説明
サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。
API 応答の例
HTTP メソッド
POST api/ocloudNotifications/v1/subscriptions
説明
適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。次の PTP イベントをサブスクライブできます。
-
lock-stateイベント -
os-clock-sync-stateイベント -
clock-classイベント -
gnss-sync-statusイベント -
sync-stateイベント
| パラメーター | 型 |
|---|---|
| subscription | data |
PTP イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
PTP ロック状態イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}
PTP os-clock-sync-state イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}
PTP clock-class イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}
PTP gnss-sync-status イベントサブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}
同期状態サブスクリプションペイロードの例
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions
説明
すべてのサブスクリプションを削除します。
API 応答の例
{
"status": "deleted all subscriptions"
}
{
"status": "deleted all subscriptions"
}
15.6.1.2. api/ocloudNotifications/v1/subscriptions/{subscription_id} リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID が subscription_id のサブスクリプションの詳細を返します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID subscription_id のサブスクリプションを削除します。
| パラメーター | 型 |
|---|---|
|
| string |
API 応答の例
{
"status": "OK"
}
{
"status": "OK"
}
15.6.1.3. api/ocloudNotifications/v1/health リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/health/
説明
ocloudNotifications REST API の正常性ステータスを返します。
API 応答の例
OK
OK
15.6.1.4. api/ocloudNotifications/v1/publishers リンクのコピーリンクがクリップボードにコピーされました!
api/ocloudNotifications/v1/publishers エンドポイントは、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーからのみ利用できます。アプリケーション Pod 内のコンシューマーアプリケーションでは使用できません。
HTTP メソッド
GET api/ocloudNotifications/v1/publishers
説明
クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。
機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。
API 応答の例
15.6.1.5. api/ocloudNotifications/v1/{resource_address}/CurrentState リンクのコピーリンクがクリップボードにコピーされました!
HTTP メソッド
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState
GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState
説明
クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。
-
os-clock-sync-state通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKEDまたはFREERUN状態になります。 -
clock-class通知は、PTP クロッククラスの現在の状態を説明します。 -
lock-state通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、またはFREERUN状態になります。 -
sync-state通知は、ptp-status/lock-stateエンドポイントおよびsync-status/os-clock-sync-stateエンドポイントのうち最も同期されていないエンドポイントの現在のステータスを説明します。 -
gnss-sync-status通知は、GNSS クロックの同期状態を説明します。
| パラメーター | 型 |
|---|---|
|
| string |
ロック状態 API レスポンスの例
os-clock-sync-state API レスポンスの例
clock-class API レスポンスの例
同期状態 API 応答の例
gnss-sync-status API 応答の例
第16章 CIDR 範囲の定義 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで OVN-Kubernetes を使用する場合は、Classless Inter-Domain Routing (CIDR) サブネット範囲に重複しない範囲を指定する必要があります。
OVN-Kubernetes を使用するクラスターでは、次のサブネットタイプが必須です。
- Join: 結合スイッチを使用して、ゲートウェイルーターを分散ルーターに接続します。結合スイッチは、分散ルーターの IP アドレスの数を削減します。OVN-Kubernetes プラグインを使用するクラスターの場合、結合スイッチに接続されるすべての論理ポートに専用サブネットの IP アドレスが割り当てられます。
- Masquerade: ロードバランサーがルーティングを決定した後、同じノードにヘアピントラフィックとして送信される同一の送信元および宛先 IP アドレスの競合を防止します。
- Transit: トランジットスイッチは、クラスター内のすべてのノードにまたがる分散スイッチの一種です。トランジットスイッチは、異なるゾーン間でトラフィックをルーティングします。OVN-Kubernetes プラグインを使用するクラスターの場合、トランジットスイッチに接続するすべての論理ポートに専用サブネットの IP アドレスが割り当てられます。
インストール後のタスクとして、クラスターの結合、マスカレード、およびトランジット CIDR 範囲を変更できます。
OpenShift Container Platform 4.14 以降のバージョンのデフォルトネットワークプロバイダーである OVN-Kubernetes は、内部的に次の IP アドレスサブネット範囲を使用します。
-
V4JoinSubnet:100.64.0.0/16 -
V6JoinSubnet:fd98::/64 -
V4TransitSwitchSubnet:100.88.0.0/16 -
V6TransitSwitchSubnet:fd97::/64 -
defaultV4MasqueradeSubnet:169.254.0.0/17 -
defaultV6MasqueradeSubnet:fd69::/125
前のリストには、参加、トランジット、マスカレード IPv4 および IPv6 アドレスサブネットが含まれています。クラスターで OVN-Kubernetes を使用する場合は、クラスターまたはインフラストラクチャー内の他の CIDR 定義にこれらの IP アドレスサブネット範囲を含めないでください。
16.1. Machine CIDR リンクのコピーリンクがクリップボードにコピーされました!
マシンの Classless Inter-Domain Routing (CIDR) フィールドでは、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。
クラスターの作成後にマシンの CIDR 範囲を変更することはできません。
デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。
16.2. Service CIDR リンクのコピーリンクがクリップボードにコピーされました!
Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。
16.3. Pod CIDR リンクのコピーリンクがクリップボードにコピーされました!
Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。
Pod CIDR は、clusterNetwork CIDR およびクラスター CIDR と同じです。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。クラスターをインストールした後に、範囲を拡張できます。
16.4. ホスト接頭辞 リンクのコピーリンクがクリップボードにコピーされました!
Host Prefix フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。
例えば、ホスト接頭辞を /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。
第17章 複数ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
17.1. 複数ネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて additional network を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これにより、スイッチングやルーティングなどのネットワーク機能を提供する Pod を設定する際に柔軟性が得られます。
17.1.1. 追加ネットワークの使用シナリオ リンクのコピーリンクがクリップボードにコピーされました!
データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で追加のネットワークを使用できます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。
- パフォーマンス
- 各プレーンのトラフィック量を管理するために、2 つの異なるプレーンにトラフィックを送信できます。
- セキュリティー
- 機密トラフィックは、セキュリティー上の考慮に基づいて管理されているネットワークに送信でき、テナントまたはカスタマー間で共有できないプライベートを分離することができます。
クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0 インターフェイスがあります。Pod のインターフェイスは、oc exec -it <pod_name> -- ip a コマンドを使用して表示できます。Multus CNI を使用するネットワークを追加する場合、それらの名前は net1、net2、…、netN になります。
追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェイスは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェイスの作成方法を定義します。
17.1.2. OpenShift Container Platform の追加ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスターに追加のネットワークを作成するために使用する以下の CNI プラグインを提供します。
- bridge: ブリッジベースの追加ネットワークを設定する ことで、同じホストにある Pod が相互に、かつホストと通信できます。
- host-device: ホストデバイスの追加ネットワークを設定する ことで、Pod がホストシステム上の物理イーサネットネットワークデバイスにアクセスすることができます。
- ipvlan: ipvlan ベースの追加ネットワークを設定する ことで、macvlan ベースの追加ネットワークと同様に、ホスト上の Pod が他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加のネットワークとは異なり、各 Pod は親の物理ネットワークインターフェイスと同じ MAC アドレスを共有します。
- vlan: VLAN ベースの追加ネットワークを設定 して、VLAN ベースのネットワークの分離と Pod の接続を可能にします。
- macvlan: macvlan ベースの追加ネットワークを作成 することで、ホスト上の Pod が物理ネットワークインターフェイスを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
- tap: タップベースの追加ネットワークを設定 して、コンテナー namespace 内にタップデバイスを作成します。タップデバイスを使用すると、ユーザー空間プログラムがネットワークパケットを送受信できるようになります。
- SR-IOV: SR-IOV ベースの追加ネットワークを設定する ことで、Pod をホストシステム上の SR-IOV 対応ハードウェアの Virtual Function (VF) インターフェイスに割り当てることができます。
-
route-override:
route-overrideベースの追加ネットワークを設定 して、Pod がルートをオーバーライドして設定できるようにします。
17.2. 追加のネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。
17.2.1. 追加のネットワークを管理するためのアプローチ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で追加のネットワークのライフサイクルを管理するには、Cluster Network Operator (CNO) 設定を変更するか、YAML マニフェストを適用します。各アプローチは同時に使用できず、追加のネットワークを管理する場合に 1 つのアプローチしか使用できません。どちらのアプローチでも、追加のネットワークは、お客様が設定した Container Network Interface (CNI) プラグインによって管理されます。2 つの異なるアプローチを以下にまとめます。
-
Cluster Network Operator (CNO) 設定の変更: CNO を介して追加のネットワークを設定できるのは、クラスター管理者だけです。CNO は
NetworkAttachmentDefinitionオブジェクトを自動的に作成および管理します。このアプローチを使用すると、install-configの設定により、インストール時にNetworkAttachmentDefinitionオブジェクトを定義できます。 -
YAML マニフェストを適用する:
NetworkAttachmentDefinitionオブジェクトを作成することで、追加のネットワークを直接管理できます。このアプローチでは、CNO 設定を変更する場合と比較して、設定に関してよりきめ細かい制御と柔軟性が得られます。
OVN Kubernetes を使用して、Red Hat OpenStack Platform (RHOSP) に複数のネットワークインターフェイスを持つ OpenShift Container Platform ノードをデプロイすると、セカンダリーインターフェイスの DNS 設定がプライマリーインターフェイスの DNS 設定よりも優先される場合があります。この場合、セカンダリーインターフェイスに接続されているサブネット ID の DNS ネームサーバーを削除してください。
openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
17.2.2. 追加のネットワークの IP アドレス割り当て リンクのコピーリンクがクリップボードにコピーされました!
追加のネットワークでは、Dynamic Host Configuration Protocol (DHCP) や静的割り当てなど、さまざまな割り当て方法をサポートする IP アドレス管理 (IPAM) CNI プラグインを使用して IP アドレスを割り当てることができます。
IP アドレスの動的割り当てを担当する DHCP IPAM CNI プラグインは、2 つの異なるコンポーネントを使用して動作します。
- CNI プラグイン: Kubernetes ネットワークスタックと統合して IP アドレスを要求および解放する役割を担います。
- DHCP IPAM CNI デーモン: 環境内の既存の DHCP サーバーと連携して IP アドレス割り当て要求を処理する DHCP イベントのリスナー。このデーモン自体は DHCP サーバーでは ありません。
IPAM 設定で type: dhcp を必要とするネットワークの場合は、次の点を確認してください。
- DHCP サーバーが環境内で利用可能かつ実行されている。DHCP サーバーはクラスターの外部にあり、お客様の既存のネットワークインフラストラクチャーの一部である必要があります。
- DHCP サーバーが、ノードに IP アドレスを提供するように適切に設定されている。
環境内で DHCP サーバーが利用可能でない場合は、代わりに Whereabouts IPAM CNI プラグインを使用することを推奨します。Whereabouts CNI は、外部 DHCP サーバーを必要とせずに同様の IP アドレス管理機能を提供します。
外部 DHCP サーバーがない場合、または静的 IP アドレス管理が望ましい場合は、Whereabouts CNI プラグインを使用してください。Whereabouts プラグインには、古くなった IP アドレスの割り当てを管理するためのリコンサイラーデーモンが含まれています。
コンテナーの有効期間中、DHCP リースを定期的に更新する必要があるため、別のデーモンである DHCP IPAM CNI デーモンが必要です。DHCP IPAM CNI デーモンをデプロイするには、追加のネットワーク設定の一部としてこのデーモンのデプロイをトリガーするように Cluster Network Operator (CNO) 設定を変更します。
17.2.3. ネットワーク追加割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
追加のネットワークは、k8s.cni.cncf.io API グループの NetworkAttachmentDefinition API を使用して設定されます。
NetworkAttachmentDefinition オブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。
API の設定は、以下の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 追加のネットワークの名前です。 |
|
|
| オブジェクトが関連付けられる namespace。 |
|
|
| JSON 形式の CNI プラグイン設定。 |
17.2.3.1. Cluster Network Operator による追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
追加のネットワーク割り当ての設定は、Cluster Network Operator (CNO) の設定の一部として指定します。
以下の YAML は、CNO で追加のネットワークを管理するための設定パラメーターを記述しています。
Cluster Network Operator (CNO) の設定
- 1
- 1 つまたは複数の追加ネットワーク設定の配列。
- 2
- 作成している追加ネットワーク割り当ての名前。名前は指定された
namespace内で一意である必要があります。 - 3
- ネットワークの割り当てを作成する namespace。値を指定しない場合、
defaultの namespace が使用されます。重要OVN-Kubernetes ネットワークプラグインの namespace の問題を阻止するには、追加のネットワークアタッチメントに
defaultという名前を付けないでください。この namespace は、defaultの追加のネットワークアタッチメント用に予約されているためです。 - 4
- JSON 形式の CNI プラグイン設定。
17.2.3.2. YAML マニフェストからの追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。
17.2.4. 追加のネットワークタイプの設定 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、追加のネットワークの具体的な設定フィールドを説明します。
17.2.4.1. ブリッジネットワークの追加設定 リンクのコピーリンクがクリップボードにコピーされました!
次のオブジェクトは、Bridge CNI プラグインの設定パラメーターを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
|
オプション: 使用する仮想ブリッジの名前を指定します。ブリッジインターフェイスがホストに存在しない場合は、これが作成されます。デフォルト値は |
|
|
|
オプション: 仮想ネットワークから外すトラフィックの IP マスカレードを有効にするには、 |
|
|
|
オプション: IP アドレスをブリッジに割り当てるには |
|
|
|
オプション: ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、 |
|
|
|
オプション: 仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、 |
|
|
|
オプション: 仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、 |
|
|
|
オプション: ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、 |
|
|
| オプション: 仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。 |
|
|
|
オプション: デフォルトの VLAN をブリッジに接続されている |
|
|
|
オプション: VLAN トランクタグを割り当てます。デフォルト値は |
|
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
|
オプション: コンテナー側の |
|
|
|
オプション: MAC スプーフィングチェックを有効にして、コンテナーから発信されるトラフィックをインターフェイスの MAC アドレスに制限します。デフォルト値は |
VLAN パラメーターは、veth のホスト側に VLAN タグを設定し、ブリッジインターフェイスで vlan_filtering 機能を有効にします。
L2 ネットワークのアップリンクを設定するには、次のコマンドを使用してアップリンクインターフェイスで VLAN を許可する必要があります。
bridge vlan add vid VLAN_ID dev DEV
$ bridge vlan add vid VLAN_ID dev DEV
17.2.4.1.1. ブリッジ CNI プラグインの設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、bridge-net という名前の追加のネットワークを設定します。
17.2.4.2. ホストデバイスの追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
device、hwaddr、kernelpath、または pciBusID のいずれかのパラメーターを設定してネットワークデバイスを指定します。
以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
|
オプション: |
|
|
| オプション: デバイスハードウェアの MAC アドレス。 |
|
|
|
オプション: |
|
|
|
オプション: |
17.2.4.2.1. ホストデバイス設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、hostdev-net という名前の追加のネットワークを設定します。
17.2.4.3. VLAN 追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
次のオブジェクトは、VLAN、vlan、CNI プラグインの設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
|
ネットワーク割り当てに関連付けるイーサネットインターフェイス。 |
|
|
|
|
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
| オプション: 返される DNS 情報。たとえば、DNS ネームサーバーの優先順位順リストなどです。 |
|
|
|
オプション: |
vlan 設定を持つ NetworkAttachmentDefinition カスタムリソース定義 (CRD) は、ノード内の単一の Pod でのみ使用できます。CNI プラグインは、同じ master インターフェイス上に同じ vlanId を持つ vlan サブインターフェイスを複数作成できないためです。
17.2.4.3.1. VLAN 設定例 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、vlan-net という名前の追加ネットワークを含む vlan 設定を示しています。
17.2.4.4. IPVLAN 追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
次のオブジェクトは、IPVLAN、ipvlan、CNI プラグインの設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。これは、プラグインが連鎖している場合を除き必要です。 |
|
|
|
オプション: 仮想ネットワークの操作モードを指定します。この値は、 |
|
|
|
オプション: ネットワーク割り当てに関連付けるイーサネットインターフェイスを指定します。 |
|
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
|
オプション: |
-
ipvlanオブジェクトは、仮想インターフェイスがmasterインターフェイスと通信することを許可しません。したがって、コンテナーはipvlanインターフェイスを使用してホストに到達できません。コンテナーが、Precision Time Protocol (PTP) をサポートするネットワークなど、ホストへの接続を提供するネットワークに参加していることを確認してください。 -
1 つの
masterインターフェイスを、macvlanとipvlanの両方を同時に使用するように設定することはできません。 -
インターフェイスに依存できない IP 割り当てスキームの場合、
ipvlanプラグインは、このロジックを処理する以前のプラグインと連鎖させることができます。masterが省略された場合、前の結果にはスレーブにするipvlanプラグインのインターフェイス名が 1 つ含まれていなければなりません。ipamが省略された場合、ipvlanインターフェイスの設定には前の結果が使用されます。
17.2.4.4.1. IPVLAN CNI プラグインの設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、ipvlan-net という名前の追加のネットワークを設定します。
17.2.4.5. MACVLAN 追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下のオブジェクトは、MAC 仮想 LAN (MACVLAN) Container Network Interface (CNI) プラグインの設定パラメーターについて説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
|
オプション: 仮想ネットワークのトラフィックの可視性を設定します。 |
|
|
| オプション: 新しく作成された macvlan インターフェイスに関連付けるホストネットワークインターフェイス。値が指定されていない場合は、デフォルトのルートインターフェイスが使用されます。 |
|
|
| オプション: 指定された値への最大転送単位 (MTU)。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
|
オプション: |
プラグイン設定の master キーを指定する場合は、競合の可能性を回避するために、プライマリーネットワークプラグインに関連付けられているものとは異なる物理ネットワークインターフェイスを使用してください。
17.2.4.5.1. MACVLAN CNI プラグイン設定の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、macvlan-net という名前の追加のネットワークを設定します。
17.2.4.6. TAP 追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下のオブジェクトは、TAP CNI プラグインの設定パラメーターを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。値 |
|
|
|
CNO 設定に以前に指定した |
|
|
|
設定する CNI プラグインの名前: |
|
|
| オプション: インターフェイスの指定された MAC アドレスを要求します。 |
|
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
| オプション: タップデバイスに関連付ける SELinux コンテキスト。 注記
OpenShift Container Platform には、値 |
|
|
|
オプション: マルチキューを有効にするには |
|
|
| オプション: タップデバイスを所有するユーザー。 |
|
|
| オプション: タップデバイスを所有するグループ。 |
|
|
| オプション: タップデバイスを既存のブリッジのポートとして設定します。 |
17.2.4.6.1. Tap 設定の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、mynet という名前の追加ネットワークを設定します。
17.2.4.6.2. TAP CNI プラグインの SELinux ブール値の設定 リンクのコピーリンクがクリップボードにコピーされました!
Container_t SELinux コンテキストを使用して Tap デバイスを作成するには、Machine Config Operator (MCO) を使用してホスト上で container_use_devices ブール値を有効にします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
次の詳細を含む、
setsebool-container-use-devices.yamlなどの名前の新しい YAML ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、新しい
MachineConfigオブジェクトを作成します。oc apply -f setsebool-container-use-devices.yaml
$ oc apply -f setsebool-container-use-devices.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MachineConfigオブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。この更新が適用されるまでに、時間がかかる場合があります。次のコマンドを実行して、変更が適用されていることを確認します。
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-e5e0c8e8be9194e7c5a882e047379cfa True False False 3 3 3 0 7d2h worker rendered-worker-d6c9ca107fba6cd76cdcbfcedcafa0f2 True False False 3 3 3 0 7d
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-e5e0c8e8be9194e7c5a882e047379cfa True False False 3 3 3 0 7d2h worker rendered-worker-d6c9ca107fba6cd76cdcbfcedcafa0f2 True False False 3 3 3 0 7dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記すべてのノードが更新され、準備完了状態になっている必要があります。
17.2.4.7. 追加ネットワークで route-override プラグインを使用してルートを設定する リンクのコピーリンクがクリップボードにコピーされました!
次のオブジェクトは、route-override CNI プラグインの設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
設定する CNI プラグインの名前: |
|
|
|
オプション: 既存ルートをフラッシュするには |
|
|
|
オプション: デフォルトルート、つまりゲートウェイルートをフラッシュするには |
|
|
| オプション: コンテナー namespace から削除するルートのリストを指定します。 |
|
|
|
オプション: コンテナー namespace に追加するルートのリストを指定します。各ルートは、 |
|
|
|
オプション: check コマンドをスキップするには、これを |
17.2.4.7.1. route-override プラグインの設定例 リンクのコピーリンクがクリップボードにコピーされました!
route-override CNI は、親 CNI と連鎖して使用するように設計された CNI タイプです。独立して動作するのではなく、まず親 CNI を利用してネットワークインターフェイスを作成して IP アドレスを割り当てます。その後、ルーティングルールの変更が可能になります。
次の例では、mymacvlan という名前の追加ネットワークを設定します。親 CNI は、eth1 にアタッチされたネットワークインターフェイスを作成し、host-local IPAM を使用して 192.168.1.0/24 の範囲の IP アドレスを割り当てます。これにより route-override CNI が親 CNI に連結され、既存ルートをフラッシュし、192.168.0.0/24 へのルートを削除し、カスタムゲートウェイを使用して 192.168.0.0/24 の新しいルートを追加することで、ルーティングルールが変更されます。
17.2.4.8. OVN-Kubernetes 追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインを使用すると、Pod のセカンダリーネットワークインターフェイスを設定できます。セカンダリーネットワークインターフェイスを設定するには、NetworkAttachmentDefinition カスタムリソース定義 (CRD) で設定を定義する必要があります。
Pod およびマルチネットワークポリシーの作成は、ノード内の OVN-Kubernetes コントロールプレーンエージェントが関連する network-attachment-definition CRD を処理するまで、保留状態のままになる場合があります。
OVN-Kubernetes 追加ネットワークは、レイヤー 2 または ローカルネット トポロジーで設定できます。
- レイヤ 2 トポロジーは、East-West クラスタートラフィックをサポートしますが、基礎となる物理ネットワークへのアクセスは許可しません。
- ローカルネットトポロジーでは物理ネットワークへの接続が可能ですが、クラスターノード上の基盤となる Open vSwitch (OVS) ブリッジの追加設定が必要です。
次のセクションでは、OVN-Kubernetes で現在セカンダリーネットワークに許可されている各トポロジーの設定例を示します。
ネットワーク名は一意である必要があります。たとえば、同じネットワークを参照する異なる設定を持つ複数の NetworkAttachmentDefinition CRD の作成はサポートされていません。
17.2.4.8.1. OVN-Kubernetes 追加ネットワークでサポートされるプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes 追加ネットワークは、次のサポートされているプラットフォームで使用できます。
- ベアメタル
- IBM Power®
- IBM Z®
- IBM® LinuxONE
- VMware vSphere
- Red Hat OpenStack Platform (RHOSP)
17.2.4.8.2. OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル リンクのコピーリンクがクリップボードにコピーされました!
次の表は、OVN-Kubernetes CNI ネットワークプラグインの設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNI 仕様のバージョン。必要な値は |
|
|
|
ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、 |
|
|
|
設定する CNI プラグインの名前。この値は |
|
|
|
ネットワークのトポロジー設定。 |
|
|
| クラスター全体のネットワークに使用するサブネット。
省略した場合、ネットワークを実装する論理スイッチはレイヤー 2 通信のみを提供し、ユーザーは Pod の IP アドレスを設定する必要があります。ポートセキュリティーは、MAC スプーフィングのみを防止します。 |
|
|
|
最大伝送単位 (MTU)。デフォルト値 |
|
|
|
この設定が含まれるネットワークアタッチメント定義 CRD のメタデータの |
|
|
| CIDR と IP アドレスのコンマ区切りのリスト。IP アドレスは割り当て可能な IP アドレスプールから削除され、Pod に渡されることはありません。 |
|
|
|
トポロジーが |
17.2.4.8.3. マルチネットワークポリシーとの互換性 リンクのコピーリンクがクリップボードにコピーされました!
k8s.cni.cncf.io API グループの MultiNetworkPolicy カスタムリソース定義 (CRD) によって提供されるマルチネットワークポリシー API は、OVN-Kubernetes セカンダリーネットワークと互換性があります。ネットワークポリシーを定義する場合、使用できるネットワークポリシールールは、OVN-Kubernetes セカンダリーネットワークが subnets フィールドを定義しているかどうかによって異なります。詳細は、次の表を参照してください。
subnets フィールドの指定 | 許可されたマルチネットワークポリシーセレクター |
|---|---|
| はい |
|
| いいえ |
|
たとえば、次のマルチネットワークポリシーは、blue2 という名前の追加ネットワークの追加ネットワーク CNI 設定で subnets フィールドが定義されている場合にのみ有効です。
Pod セレクターを使用するマルチネットワークポリシーの例
次の例では、ipBlock ネットワークポリシーセレクターを使用します。これは、OVN-Kubernetes 追加ネットワークに対して常に有効です。
IP ブロックセレクターを使用するマルチネットワークポリシーの例
17.2.4.8.4. レイヤー 2 スイッチドトポロジーの設定 リンクのコピーリンクがクリップボードにコピーされました!
スイッチド (レイヤー 2) トポロジーネットワークは、クラスター全体の論理スイッチを介してワークロードを相互接続します。この設定は、IPv6 およびデュアルスタックデプロイメントに使用できます。
レイヤー 2 スイッチドトポロジーネットワークでは、クラスター内の Pod 間のデータパケットの転送のみが許可されます。
次の JSON 例では、スイッチドセカンダリーネットワークを設定します。
17.2.4.8.5. ローカルネットトポロジーの設定 リンクのコピーリンクがクリップボードにコピーされました!
スイッチド localnet トポロジーは、ネットワークアタッチメント定義 (NAD) として作成されたワークロードを、クラスター全体の論理スイッチを介して物理ネットワークに相互接続します。
17.2.4.8.5.1. OVN-Kubernetes 追加ネットワークを設定するための前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- NMState Operator がインストールされている。詳細は、Kubernetes NMState Operator を参照してください。
17.2.4.8.5.2. OVN-Kubernetes 追加ネットワークマッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes 追加ネットワークとして使用するには、追加ネットワークを OVN ブリッジにマップする必要があります。ブリッジマッピングにより、ネットワークトラフィックが物理ネットワークに到達できるようになります。ブリッジマッピングは、インターフェイスラベルとも呼ばれる物理ネットワーク名を、Open vSwitch (OVS) で作成されたブリッジに関連付けます。
nmstate.io/v1 API グループの一部である NodeNetworkConfigurationPolicy (NNCP) オブジェクトを作成して、宣言的にマッピングを作成できます。この API は NMState Operator によって提供されます。この API を使用すると、指定した nodeSelector 式 (node-role.kubernetes.io/worker: '' など) に一致するノードにブリッジマッピングを適用できます。この宣言的なアプローチにより、NMState Operator は、ノードセレクターによって指定されたすべてのノードにセカンダリーネットワーク設定を自動的かつ透過的に適用します。
追加のネットワークを接続する場合、既存の br-ex ブリッジを使用することも、新しいブリッジを作成することもできます。どのアプローチを使用するかは、特定のネットワークインフラストラクチャーによって異なります。次のアプローチを検討してください。
-
ノードにネットワークインターフェイスが 1 つしか含まれていない場合は、既存のブリッジを使用する必要があります。このネットワークインターフェイスは OVN-Kubernetes によって所有および管理されているため、
br-exブリッジから削除したり、インターフェイス設定を変更したりしないでください。ネットワークインターフェイスを削除または変更すると、クラスターネットワークは正しく動作しなくなります。 - ノードに複数のネットワークインターフェイスが含まれている場合は、別のネットワークインターフェイスを新しいブリッジに接続して、追加のネットワークに使用できます。このアプローチでは、プライマリークラスターネットワークからトラフィックが分離されます。
次の例では、localnet1 ネットワークが br-ex ブリッジにマッピングされています。
ブリッジを共有するためのマッピングの例
- 1
- 設定オブジェクトの名前。
- 2
- ノードネットワーク設定ポリシーを適用するノードを指定するノードセレクター。
- 3
- トラフィックが OVS ブリッジに転送される追加ネットワークの名前。この追加ネットワークは、OVN-Kubernetes 追加ネットワークを定義する
NetworkAttachmentDefinitionCRD のspec.config.nameフィールドの名前と一致する必要があります。 - 4
- ノード上の OVS ブリッジの名前。この値は、
state: presentを指定する場合にのみ必要です。 - 5
- マッピングの状態。ブリッジを追加する場合は
present、ブリッジを削除する場合はabsentである必要があります。デフォルト値はpresentです。次の JSON の例では、
localnet1という名前の localnet セカンダリーネットワークを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次の例では、localnet2 ネットワークインターフェイスが ovs-br1 ブリッジに接続されています。この接続を使って、ネットワークインターフェイスを OVN-Kubernetes ネットワークプラグインで追加のネットワークとして利用できるようになります。
複数のインターフェイスを持つノードのマッピング例
- 1
- 設定オブジェクトの名前を指定します。
- 2
- ノードネットワーク設定ポリシーが適用されるノードを識別するノードセレクターを指定します。
- 3
- クラスタートラフィック用に OVN-Kubernetes によって使用されるデフォルトのブリッジとは別に動作する新しい OVS ブリッジを指定します。
- 4
- マルチキャストスヌーピングを有効にするかどうかを指定します。マルチキャストスヌーピングを有効にすると、ネットワークデバイスがすべてのネットワークメンバーにマルチキャストトラフィックをフラッディングすることを防止します。デフォルトでは、OVS ブリッジはマルチキャストスヌーピングを有効にしません。デフォルト値は
falseです。 - 5
- 新しい OVS ブリッジに関連付けるホストシステム上のネットワークデバイスを指定します。
- 6
- トラフィックを OVS ブリッジに転送する追加のネットワークの名前を指定します。この名前は、OVN-Kubernetes セカンダリーネットワークを定義する
NetworkAttachmentDefinitionCRD のspec.config.nameフィールドの値と一致する必要があります。 - 7
- ノード上の OVS ブリッジの名前を指定します。値は、
state: presentが設定されている場合にのみ必要です。 - 8
- マッピングの状態を指定します。有効な値は、ブリッジを追加する場合は
present、ブリッジを削除する場合はabsentです。デフォルト値はpresentです。次の JSON の例では、
localnet2という名前の localnet セカンダリーネットワークを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.4.8.6. 追加ネットワーク用の Pod の設定 リンクのコピーリンクがクリップボードにコピーされました!
k8s.v1.cni.cncf.io/networks アノテーションを使用して、セカンダリーネットワーク割り当てを指定する必要があります。
次の例では、このガイドに示されている割り当て設定ごとに 1 つずつ、2 つのセカンダリー割り当てを持つ Pod をプロビジョニングします。
17.2.4.8.7. 静的 IP アドレスを使用して Pod を設定する リンクのコピーリンクがクリップボードにコピーされました!
次の例では、静的 IP アドレスを使用して Pod をプロビジョニングします。
- レイヤー 2 割り当てに対する Pod のセカンダリーネットワーク割り当ての IP アドレスのみを指定できます。
- Pod の静的 IP アドレスを指定できるのは、割り当て設定にサブネットが含まれていない場合のみです。
17.2.5. ネットワークアタッチメントの IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。
以下の IP アドレスの割り当てタイプを使用できます。
- 静的割り当て。
- DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
- Whereabouts IPAM CNI プラグインを使用した動的割り当て。
17.2.5.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、静的 IP アドレスの割り当ての設定を説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses の配列には、以下のフィールドのあるオブジェクトが必要です。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
17.2.5.2. 動的 IP アドレス (DHCP) 割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
イーサネットネットワークアタッチメントの場合、SR-IOV Network Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
次の表は、DHCP による動的 IP アドレス割り当ての設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
以下の JSON の例は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
動的 IP アドレス (DHCP) 割り当ての設定例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
17.2.5.3. Whereabouts を使用した動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。
Whereabouts CNI プラグインは、重複する IP アドレス範囲と、別々の NetworkAttachmentDefinitions CRD 内で同じ CIDR 範囲を複数回設定することもサポートしています。これにより、マルチテナント環境での柔軟性と管理機能が向上します。
17.2.5.3.1. 動的 IP アドレス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定オブジェクトを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
|
|
| オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。 |
17.2.5.3.2. Whereabouts を使用した動的 IP アドレス割り当て設定 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、Whereabouts を使用する動的アドレス割り当て設定を示しています。
whereabouts 動的 IP アドレスの割り当て
17.2.5.3.3. IP アドレス範囲が重複する場合に Whereabouts を使用した動的 IP アドレス割り当て リンクのコピーリンクがクリップボードにコピーされました!
次の例は、マルチテナントネットワークで重複する IP アドレスの範囲を使用する、動的な IP アドレスの割り当てを示しています。
NetworkAttachmentDefinition 1
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 2のnetwork_nameと一致する必要があります。
NetworkAttachmentDefinition 2
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 1のnetwork_nameと一致する必要があります。
17.2.5.4. whereabouts-reconciler デーモンセットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Whereabouts reconciler は、Whereabouts IP アドレス管理 (IPAM) ソリューションを使用して、クラスター内の Pod の動的 IP アドレス割り当てを管理します。これにより、各 Pod が指定の IP アドレス範囲から一意の IP アドレスを確実に取得します。また、Pod が削除またはスケールダウンされた場合の IP アドレスの解放も処理します。
動的 IP アドレスの割り当てには、NetworkAttachmentDefinition カスタムリソース定義 (CRD) を使用することもできます。
whereabouts-reconciler デーモンセットは、Cluster Network Operator を通じて追加のネットワークを設定するときに自動的に作成されます。YAML マニフェストから追加のネットワークを設定する場合、これは自動的には作成されません。
whereabouts-reconciler デーモンセットのデプロイをトリガーするには、Cluster Network Operator のカスタムリソース (CR) ファイルを編集して、whereabouts-shim ネットワーク割り当てを手動で作成する必要があります。
whereabouts-reconciler デーモンセットをデプロイするには、次の手順を使用します。
手順
以下のコマンドを実行して、
Network.operator.openshift.ioカスタムリソース (CR) を編集します。oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例で展開されている YAML の
additionalNetworksセクションを、カスタムリソース (CR) のspec定義内に含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、テキストエディターを編集します。
次のコマンドを実行して、
whereabouts-reconcilerデーモンセットが正常にデプロイされたことを確認します。oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconcilerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.5.5. Whereabouts IP リコンサイラーのスケジュールの設定 リンクのコピーリンクがクリップボードにコピーされました!
Whereabouts IPAM CNI プラグインは、IP リコンサイラーを毎日実行します。このプロセスは、IP が枯渇して新しい Pod に IP が割り当てられなくなる状態を避けるために、完了せずに残っている IP 割り当てをクリーンアップします。
IP リコンサイラーを実行する頻度を変更するには、次の手順を使用します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
whereabouts-reconcilerデーモンセットがデプロイされており、whereabouts-reconcilerPod が起動して実行されている。
手順
次のコマンドを実行して、IP リコンサイラー用の特定の cron 式を使用し、
openshift-multusnamespace にwhereabouts-configという名前のConfigMapオブジェクトを作成します。oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"
$ oc create configmap whereabouts-config -n openshift-multus --from-literal=reconciler_cron_expression="*/15 * * * *"Copy to Clipboard Copied! Toggle word wrap Toggle overflow この cron 式は、IP リコンサイラーを 15 分ごとに実行するよう指定します。この式は固有の要件に基づいて調整してください。
注記whereabouts-reconcilerデーモンセットは、5 つのアスタリスクを含む cron 式パターンのみを使用できます。秒を表すために使用される 6 番目のアスタリスクは、現在サポートされていません。次のコマンドを実行して、
openshift-multusnamespace 内のwhereabouts-reconcilerデーモンセットおよび Pod に関連するリソースに関する情報を取得します。oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconcilerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、設定した間隔で
whereabouts-reconcilerPod が IP リコンサイラーを実行していることを確認します。oc -n openshift-multus logs whereabouts-reconciler-2p7hw
$ oc -n openshift-multus logs whereabouts-reconciler-2p7hwCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.5.6. デュアルスタック IP アドレスを動的に割り当てる設定の作成 リンクのコピーリンクがクリップボードにコピーされました!
デュアルスタックの IP アドレスの割り当ては、ipRanges パラメーターで設定できます。
- IPv4 アドレス
- IPv6 アドレス
- 複数の IP アドレスの割り当て
手順
-
typeをwhereaboutsに設定します。 以下の例のように、
ipRangesを使用して IP アドレスを割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ネットワークを Pod にアタッチします。詳細は、「追加のネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.6. Cluster Network Operator による追加ネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加のネットワークを指定すると、CNO によって NetworkAttachmentDefinition CRD が自動的に作成されます。
Cluster Network Operator によって管理される NetworkAttachmentDefinition CRD は編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
オプション: 追加のネットワークの namespace を作成します。
oc create namespace <namespace_name>
$ oc create namespace <namespace_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow CNO 設定を編集するには、以下のコマンドを入力します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存し、テキストエディターを終了して、変更をコミットします。
検証
次のコマンドを実行して、CNO が
NetworkAttachmentDefinitionCRD を作成したことを確認します。CNO が CRD を作成するまでに遅延が発生する可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- CNO の設定に追加したネットワーク割り当ての namespace を指定します。
出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.7. YAML マニフェストを適用した追加のネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の例のように、追加のネットワーク設定を含む YAML ファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 追加のネットワークを作成するには、次のコマンドを入力します。
oc apply -f <file>.yaml
$ oc apply -f <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<file>- YAML マニフェストを含むファイルの名前を指定します。
17.2.8. コンテナーネットワーク namespace での master インターフェイスの設定について リンクのコピーリンクがクリップボードにコピーされました!
コンテナー namespace に存在する master インターフェイスに基づいて、MAC-VLAN、IP-VLAN、または VLAN サブインターフェイスを作成できます。別のネットワークアタッチメント定義 CRD で、Pod ネットワーク設定の一部として master インターフェイスを作成することもできます。
コンテナー namespace の master インターフェイスを使用するには、NetworkAttachmentDefinition CRD のサブインターフェイス設定に存在する linkInContainer パラメーターに true を指定する必要があります。
17.2.8.1. SR-IOV VF 上で複数の VLAN を作成する リンクのコピーリンクがクリップボードにコピーされました!
この機能を利用するユースケースの例として、SR-IOV VF に基づいて複数の VLAN を作成することが挙げられます。これを行うには、まず SR-IOV ネットワークを作成し、次に VLAN インターフェイスのネットワーク割り当てを定義します。
次の例は、この図に示されているセットアップを設定する方法を示しています。
図17.1 VLAN の作成
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
手順
次のコマンドを使用して、Pod をデプロイする専用のコンテナー namespace を作成します。
oc new-project test-namespace
$ oc new-project test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV ノードポリシーを作成します。
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をsriov-node-network-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記deviceType: netdeviceを設定した SR-IOV ネットワークノードポリシーの設定例は、Mellanox ネットワークインターフェイスカード (NIC) 向けに特別に調整されています。以下のコマンドを実行して YAML を適用します。
oc apply -f sriov-node-network-policy.yaml
$ oc apply -f sriov-node-network-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ノードの再起動が必要なため、YAML の適用には時間がかかる場合があります。
SR-IOV ネットワークを作成します。
次の CR の例のように、追加の SR-IOV ネットワーク割り当て用の
SriovNetworkカスタムリソース (CR) を作成します。YAML をsriov-network-attachment.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して YAML を適用します。
oc apply -f sriov-network-attachment.yaml
$ oc apply -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
VLAN 追加ネットワークを作成します。
以下の YAML の例を使用して、
vlan100-additional-network-configuration.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f vlan100-additional-network-configuration.yaml
$ oc apply -f vlan100-additional-network-configuration.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
前に指定したネットワークを使用して、Pod 定義を作成します。
次の YAML の例を使用して、
pod-a.yamlという名前のファイルを作成します。注記以下のマニフェストには 2 つのリソースが含まれています。
- セキュリティーラベルのある namespace
- 適切なネットワークアノテーションを含む Pod 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VLAN インターフェイスの
masterとして使用される名前。
以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、
test-namespace内のnginx-podに関する詳細情報を取得します。oc describe pods nginx-pod -n test-namespace
$ oc describe pods nginx-pod -n test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.8.2. コンテナー namespace のブリッジマスターインターフェイスをベースにしてサブインターフェイスを作成する リンクのコピーリンクがクリップボードにコピーされました!
コンテナー namespace に存在するブリッジ master インターフェイスに基づいてサブインターフェイスを作成できます。サブインターフェイスの作成は、他のタイプのインターフェイスに適用できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。
手順
次のコマンドを入力して、Pod のデプロイ先となる専用のコンテナー namespace を作成します。
oc new-project test-namespace
$ oc new-project test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の YAML の例を使用して、
bridge-nad.yamlという名前のブリッジNetworkAttachmentDefinitionカスタムリソース定義 (CRD) ファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
NetworkAttachmentDefinitionCRD を OpenShift Container Platform クラスターに適用します。oc apply -f bridge-nad.yaml
$ oc apply -f bridge-nad.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
NetworkAttachmentDefinitionCRD が正常に作成されたことを確認します。oc get network-attachment-definitions
$ oc get network-attachment-definitionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE bridge-network 15s
NAME AGE bridge-network 15sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の YAML の例を使用して、追加の IPVLAN ネットワーク設定用に
ipvlan-additional-network-configuration.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f ipvlan-additional-network-configuration.yaml
$ oc apply -f ipvlan-additional-network-configuration.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
NetworkAttachmentDefinitionCRD が正常に作成されたことを確認します。oc get network-attachment-definitions
$ oc get network-attachment-definitionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE bridge-network 87s ipvlan-net 9s
NAME AGE bridge-network 87s ipvlan-net 9sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の YAML の例を使用して、Pod 定義用に
pod-a.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPVLAN インターフェイスの
masterとして使用する名前を指定します。
以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、Pod が実行されていることを確認します。
oc get pod -n test-namespace
$ oc get pod -n test-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
test-namespace内のpod-aリソースに関するネットワークインターフェイス情報を表示します。oc exec -n test-namespace pod-a -- ip a
$ oc exec -n test-namespace pod-a -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、ネットワークインターフェイス
ext1が物理インターフェイスext0に関連付けられていることを示しています。
17.3. 仮想ルーティングおよび転送について リンクのコピーリンクがクリップボードにコピーされました!
17.3.1. 仮想ルーティングおよび転送について リンクのコピーリンクがクリップボードにコピーされました!
Virtual Routing and Forwarding (VRF) デバイスと IP ルールを組み合わせることで、Virtual Routing and Forwarding ドメインを作成できます。VRF は、CNF で必要なパーミッションの数を減らし、セカンダリーネットワークのネットワークトポロジーの可視性を強化します。VRF はマルチテナンシー機能を提供するために使用されます。たとえば、この場合、各テナントには固有のルーティングテーブルがあり、異なるデフォルトゲートウェイが必要です。
プロセスは、ソケットを VRF デバイスにバインドできます。バインドされたソケット経由のパケットは、VRF デバイスに関連付けられたルーティングテーブルを使用します。VRF の重要な機能として、これは OSI モデルレイヤー 3 以上にのみ影響を与えるため、LLDP などの L2 ツールは影響を受けません。これにより、ポリシーベースのルーティングなどの優先度の高い IP ルールが、特定のトラフィックを転送する VRF デバイスルールよりも優先されます。
17.3.1.1. Telecommunications Operator に関する Pod のセカンダリーネットワークの利点 リンクのコピーリンクがクリップボードにコピーされました!
通信のユースケースでは、各 CNF が同じアドレス空間を共有する複数の異なるネットワークに接続される可能性があります。これらのセカンダリーネットワークは、クラスターのメインネットワーク CIDR と競合する可能性があります。CNI VRF プラグインを使用すると、ネットワーク機能は、同じ IP アドレスを使用して異なるユーザーのインフラストラクチャーに接続でき、複数の異なるお客様の分離された状態を維持します。IP アドレスは OpenShift Container Platform の IP スペースと重複します。CNI VRF プラグインは、CNF で必要なパーミッションの数も減らし、セカンダリーネットワークのネットワークトポロジーの可視性を高めます。
17.4. マルチネットワークポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、シングルルート I/O 仮想化 (SR-IOV)、MAC 仮想ローカルエリアネットワーク (MacVLAN)、または OVN-Kubernetes 追加ネットワークのマルチネットワークポリシーを設定できます。MacVLAN 追加ネットワークは完全にサポートされています。IP 仮想ローカルエリアネットワーク (IPVLAN) などの他の種類の追加ネットワークはサポートされていません。
SR-IOV 追加ネットワークのマルチネットワークポリシーの設定のサポートは、カーネルネットワークインターフェイスコントローラー (NIC) でのみサポートされます。SR-IOV は、データプレーン開発キット (DPDK) アプリケーションではサポートされていません。
17.4.1. マルチネットワークポリシーとネットワークポリシーの違い リンクのコピーリンクがクリップボードにコピーされました!
MultiNetworkPolicy API は、NetworkPolicy API を実装していますが、いくつかの重要な違いがあります。
以下の場合は、
MultiNetworkPolicyAPI を使用する必要があります。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
CLI を使用してマルチネットワークポリシーと対話する場合は、
multi-networkpolicyリソース名を使用する必要があります。たとえば、oc get multi-networkpolicy <name>コマンドを使用してマルチネットワークポリシーオブジェクトを表示できます。ここで、<name>はマルチネットワークポリシーの名前になります。 macvlan または SR-IOV 追加ネットワークを定義するネットワーク割り当て定義の名前でアノテーションを指定する必要があります。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: annotations: k8s.v1.cni.cncf.io/policy-for: <network_name>apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: annotations: k8s.v1.cni.cncf.io/policy-for: <network_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network_name>- ネットワーク割り当て定義の名前を指定します。
17.4.2. クラスターのマルチネットワークポリシーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。
手順
以下の YAML で
multinetwork-enable-patch.yamlファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチネットワークポリシーを有効にするようにクラスターを設定します。
oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml
$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.3. IPv6 ネットワークでのマルチネットワークポリシーのサポート リンクのコピーリンクがクリップボードにコピーされました!
ICMPv6 近隣探索プロトコル (NDP) は、デバイスが近隣ノードに関する情報を検出して維持できるようにするための、メッセージとプロセスのセットです。NDP は IPv6 ネットワークで重要な役割を果たし、同じリンク上のデバイス間の対話を促進します。
useMultiNetworkPolicy パラメーターが true に設定されている場合、Cluster Network Operator (CNO) はマルチネットワークポリシーの iptables 実装をデプロイします。
IPv6 ネットワークでマルチネットワークポリシーをサポートするために、Cluster Network Operator は、マルチネットワークポリシーの影響を受けるすべての Pod に次のルールのセットをデプロイします。
マルチネットワークポリシーのカスタムルール
- 1
- このルールは、近隣探索プロトコル (NDP) の一部である ICMPv6 ネイバー要請メッセージの受信を許可します。これらのメッセージは、近隣ノードのリンクレイヤーアドレスを決定するのに役立ちます。
- 2
- このルールは、NDP の一部であり、送信者のリンクレイヤーアドレスに関する情報を提供する、受信 ICMPv6 近隣アドバタイズメントメッセージを許可します。
- 3
- このルールは、ICMPv6 ルーター要請メッセージの受信を許可します。ホストは、これらのメッセージを使用してルーター設定情報を要求します。
- 4
- このルールは、ホストに設定情報を提供する ICMPv6 ルーターアドバタイズメントメッセージの受信を許可します。
これらの事前定義されたルールは編集できません。
これらのルールが集合することで、IPv6 環境でのアドレス解決やルーター通信などを含め、ネットワークが正しく機能するために不可欠な ICMPv6 トラフィックが有効になります。これらのルールが適用され、トラフィックを拒否するマルチネットワークポリシーがあれば、アプリケーションで接続の問題が発生することは考えられません。
17.4.4. マルチネットワークポリシーの使用 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。
17.4.4.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスターのマルチネットワークポリシーサポートを有効にしている。
17.4.4.2. CLI を使用したマルチネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
マルチネットワークポリシーを作成し、クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義することができます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
ポリシールールを作成します。
<policy_name>.yamlファイルを作成します。touch <policy_name>.yaml
$ touch <policy_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- マルチネットワークポリシーのファイル名を指定します。
作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。
すべての namespace のすべての Pod から Ingress を拒否します。
これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network_name>- ネットワーク割り当て定義の名前を指定します。
同じ namespace のすべての Pod から Ingress を許可します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network_name>- ネットワーク割り当て定義の名前を指定します。
特定の namespace から 1 つの Pod への上りトラフィックを許可する
このポリシーは、
namespace-yで実行されている Pod からpod-aというラベルの付いた Pod へのトラフィックを許可します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network_name>- ネットワーク割り当て定義の名前を指定します。
サービスへのトラフィックを制限する
このポリシーを適用すると、
app=bookstoreとrole=apiの両方のラベルを持つすべての Pod に、app=bookstoreというラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベルapp=bookstoreおよびrole=apiでマークされた REST API サーバーである可能性があります。この例では、次のユースケースに対応します。
- サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。
データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<network_name>- ネットワーク割り当て定義の名前を指定します。
マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- マルチネットワークポリシーのファイル名を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。
17.4.4.3. マルチネットワークポリシーの編集 リンクのコピーリンクがクリップボードにコピーされました!
namespace のマルチネットワークポリシーを編集できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
オプション: namespace のマルチネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
oc get multi-networkpolicy
$ oc get multi-networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトを編集します。
マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>- ネットワークポリシーを含むファイルの名前を指定します。
マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
oc edit multi-networkpolicy <policy_name> -n <namespace>
$ oc edit multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- ネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトが更新されていることを確認します。
oc describe multi-networkpolicy <policy_name> -n <namespace>
$ oc describe multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- マルチネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。
17.4.4.4. CLI を使用したマルチネットワークポリシーの表示 リンクのコピーリンクがクリップボードにコピーされました!
namespace のマルチネットワークポリシーを検査できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
namespace のマルチネットワークポリシーをリスト表示します。
namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
oc get multi-networkpolicy
$ oc get multi-networkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。
oc describe multi-networkpolicy <policy_name> -n <namespace>
$ oc describe multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- 検査するマルチネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。
17.4.4.5. CLI を使用したマルチネットワークポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
namespace のマルチネットワークポリシーを削除できます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
マルチネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
oc delete multi-networkpolicy <policy_name> -n <namespace>
$ oc delete multi-networkpolicy <policy_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<policy_name>- マルチネットワークポリシーの名前を指定します。
<namespace>- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
multinetworkpolicy.k8s.cni.cncf.io/default-deny deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。
17.4.4.6. デフォルトのすべてのマルチネットワーク拒否ポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
このポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されたネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。この手順では、my-project namespace に deny-by-default ポリシーを適用することにより、強力な拒否ポリシーを強制します。
トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、次のポリシーによってクラスター全体で通信問題が発生する可能性があります。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
すべての namespace におけるすべての Pod からの Ingress を拒否する
deny-by-defaultポリシーを定義する次の YAML を作成します。YAML をdeny-by-default.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーをデプロイする namespace を指定します。たとえば、
my-projectnamespace です。 - 2
- ネットワーク割り当て定義の名前を指定します。
- 3
- このフィールドが空の場合、設定はすべての Pod と一致します。したがって、ポリシーは
my-projectnamespace 内のすべての Pod に適用されます。 - 4
NetworkPolicyが関連するルールタイプのリストを指定します。- 5
Ingress専用のpolicyTypesを指定します。- 6
Ingressルールを指定します。指定しない場合は、すべての Pod へのすべての着信トラフィックがドロップされます。
次のコマンドを入力して、ポリシーを適用します。
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.4.7. 外部クライアントからのトラフィックを許可するマルチネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を
web-allow-external.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-external createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。
17.4.4.8. すべての namespace からアプリケーションへのトラフィックを許可するマルチネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
この手順に従って、すべての namespace 内のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定します。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を
web-allow-all-namespaces.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、
namespaceSelectorの指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、
defaultnamespace で Web サービスを開始します。oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをsecondarynamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.4.9. namespace からアプリケーションへのトラフィックを許可するマルチネットワークポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
特定の namespace からラベル app=web を持つ Pod へのトラフィックを許可するポリシーを設定するには、次の手順に従います。以下の場合にこれを行うことができます。
- 運用データベースへのトラフィックを、運用ワークロードがデプロイされている namespace のみに制限します。
- 特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。
前提条件
-
クラスターが、
NetworkPolicyオブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicyが設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが適用される namespace で作業していること。
手順
ラベルが
purpose=productionの特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML をweb-allow-prod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、
defaultnamespace で Web サービスを開始します。oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace を作成します。oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace にラベルを付けます。oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
devnamespace を作成します。oc create namespace dev
$ oc create namespace devCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
devnamespace にラベルを付けます。oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをdevnamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
wget: download timed out
wget: download timed outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをprodnamespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.5. Pod の追加のネットワークへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。
17.5.1. Pod の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターにログインする。
手順
アノテーションを
Podオブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成するには、以下のコマンドを入力します。
<name>を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: アノテーションが
PodCR に存在することを確認するには、<name>を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
example-podPod が追加ネットワークのnet1に割り当てられています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/network-statusパラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスを説明します。アノテーションの値はプレーンテキストの値として保存されます。
17.5.1.1. Pod 固有のアドレスおよびルーティングオプションの指定 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。
前提条件
- Pod が追加ネットワークと同じ namespace にあること。
-
OpenShift CLI (
oc) がインストールされている。 - クラスターにログインすること。
手順
アドレスおよび/またはルーティングオプションを指定する間に Pod を追加のネットワークに追加するには、以下の手順を実行します。
Podリソース定義を編集します。既存のPodリソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name>を、編集するPodリソースの名前に置き換えます。oc edit pod <name>
$ oc edit pod <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Podリソース定義で、k8s.v1.cni.cncf.io/networksパラメーターを Pod のmetadataマッピングに追加します。k8s.v1.cni.cncf.io/networksは、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinitionカスタムリソース (CR) 名を参照するオブジェクトリストの JSON 文字列を受け入れます。metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'metadata: annotations: k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<network>を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
以下の例では、アノテーションで
default-routeパラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。
OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックに予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。
Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。
oc exec -it <pod_name> -- ip route
$ oc exec -it <pod_name> -- ip route
また、Pod の k8s.v1.cni.cncf.io/network-status を参照して、JSON 形式の一覧のオブジェクトで default-route キーの有無を確認し、デフォルトルートが割り当てられている追加ネットワークを確認することができます。
Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。
以下のコマンドを実行して CNO CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
以下の YAML は、CNO の設定パラメーターを説明しています。
Cluster Network Operator YAML の設定
以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターを説明しています。
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。
以下を使用して Pod を編集します。
oc edit pod <name>
$ oc edit pod <name>
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。
追加のネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc コマンドを使用して Pod 内で ip コマンドを実行します。
oc exec -it <pod_name> -- ip a
$ oc exec -it <pod_name> -- ip a
17.6. 追加ネットワークからの Pod の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスターユーザーとして、追加のネットワークから Pod を削除できます。
17.6.1. 追加ネットワークからの Pod の削除 リンクのコピーリンクがクリップボードにコピーされました!
Pod を削除するだけで、追加のネットワークから Pod を削除できます。
前提条件
- 追加のネットワークが Pod に割り当てられている。
-
OpenShift CLI (
oc) がインストールされている。 - クラスターにログインする。
手順
Pod を削除するには、以下のコマンドを入力します。
oc delete pod <name> -n <namespace>
$ oc delete pod <name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<name>は Pod の名前です。 -
<namespace>は Pod が含まれる namespace です。
-
17.7. 追加ネットワークの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の追加ネットワークの設定を変更することができます。
17.7.1. 追加ネットワーク割り当て定義の変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の追加ネットワークに変更を加えることができます。追加ネットワークに割り当てられる既存の Pod は更新されません。
前提条件
- クラスター用に追加のネットワークを設定している。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターの追加ネットワークを編集するには、以下の手順を実行します。
以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
additionalNetworksコレクションで、追加ネットワークを変更内容で更新します。 - 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionオブジェクトを更新していることを確認します。<network-name>を表示する追加ネットワークの名前に置き換えます。CNO がNetworkAttachmentDefinitionオブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。oc get network-attachment-definitions <network-name> -o yaml
$ oc get network-attachment-definitions <network-name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下のコンソールの出力は
net1という名前のNetworkAttachmentDefinitionオブジェクトを表示します。oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}' { "cniVersion": "0.3.1", "type": "macvlan", "master": "ens5", "mode": "bridge", "ipam": {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.8. 追加ネットワークの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、追加のネットワーク割り当てを削除できます。
17.8.1. 追加ネットワーク割り当て定義の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、追加ネットワークを OpenShift Container Platform クラスターから削除できます。追加ネットワークは、割り当てられている Pod から削除されません。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
クラスターから追加ネットワークを削除するには、以下の手順を実行します。
以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 削除しているネットワーク割り当て定義の
additionalNetworksコレクションから設定を削除し、CR を変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
additionalNetworksコレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
- 変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。
oc get network-attachment-definition --all-namespaces
$ oc get network-attachment-definition --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
17.9. VRF へのセカンダリーネットワークの割り当て リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CNI VRF プラグインを使用して、Virtual Routing and Forwarding (VRF) ドメインの追加ネットワークを設定できます。このプラグインが作成する仮想ネットワークは、指定した物理インターフェイスに関連付けられます。
VRF インスタンスでセカンダリーネットワークを使用すると、次の利点があります。
- ワークロードの分離
- 追加のネットワークの VRF インスタンスを設定して、ワークロードトラフィックを分離します。
- セキュリティーの向上
- VRF ドメイン内の分離されたネットワークパスを通じて、セキュリティーを向上させます。
- マルチテナンシーのサポート
- 各テナントの VRF ドメイン内で、一意のルーティングテーブルを使用したネットワークセグメンテーションを通じて、マルチテナントをサポートします。
VRF を使用するアプリケーションは、特定のデバイスに対してバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE オプションを使用できます。SO_BINDTODEVICE オプションは、渡されたインターフェイス名 (例: eth1) で指定されたデバイスにソケットをバインドします。SO_BINDTODEVICE オプションを使用するには、アプリケーションに CAP_NET_RAW 機能が必要です。
ip vrf exec コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェイスに直接バインドします。
17.9.1. CNI VRF プラグインを使用した追加のネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。
Cluster Network Operator が管理する NetworkAttachmentDefinition CR は編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
CNI VRF プラグインで追加のネットワーク割り当てを作成するには、以下の手順を実行します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift クラスターにログインします。
手順
以下のサンプル CR のように、追加のネットワーク割り当て用の
Networkカスタムリソース (CR) を作成し、追加ネットワークのrawCNIConfig設定を挿入します。YAML をadditional-network-attachment.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
pluginsは一覧である必要があります。リストの最初の項目は、VRF ネットワークのベースとなるセカンダリーネットワークである必要があります。一覧の 2 つ目の項目は、VRF プラグイン設定です。- 2
typeはvrfに設定する必要があります。- 3
vrfnameは、インターフェイスが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。- 4
- 任意。
tableはルーティングテーブル ID です。デフォルトで、tableidパラメーターが使用されます。これが指定されていない場合、CNI は空のルーティングテーブル ID を VRF に割り当てます。
注記VRF は、リソースが
netdeviceタイプの場合にのみ正常に機能します。Networkリソースを作成します。oc create -f additional-network-attachment.yaml
$ oc create -f additional-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、CNO が
NetworkAttachmentDefinitionCR を作成していることを確認します。<namespace>を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例:additional-network-1)。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE additional-network-1 14m
NAME AGE additional-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記CNO が CR を作成するまでに遅延が生じる可能性があります。
検証
Pod を作成し、VRF インスタンスを使用して追加のネットワークに割り当てます。
Podリソースを定義する YAML ファイルを作成します。pod-additional-net.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- VRF インスタンスを使用する追加ネットワークの名前を指定します。
次のコマンドを実行して、
Podリソースを作成します。oc create -f pod-additional-net.yaml
$ oc create -f pod-additional-net.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pod/test-pod created
pod/test-pod createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod のネットワーク割り当てが VRF の追加ネットワークに接続されていることを確認します。Pod とのリモートセッションを開始し、次のコマンドを実行します。
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Table ----------------------- vrf-1 1001
Name Table ----------------------- vrf-1 1001Copy to Clipboard Copied! Toggle word wrap Toggle overflow VRF インターフェイスが追加インターフェイスのコントローラーであることを確認します。
ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP modeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第18章 ハードウェアネットワーク リンクのコピーリンクがクリップボードにコピーされました!
18.1. Single Root I/O Virtualization (SR-IOV) ハードウェアネットワークについて リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) 仕様は、単一デバイスを複数の Pod で共有できる PCI デバイス割り当てタイプの標準です。
SR-IOV Operator を使用すると、クラスターに Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。
SR-IOV を使用すると、準拠したネットワークデバイス (ホストノードで物理機能 (PF) として認識される) を複数の Virtual Function (VF) にセグメント化することができます。VF は他のネットワークデバイスと同様に使用されます。デバイスの SR-IOV ネットワークデバイスドライバーは、VF がコンテナーで公開される方法を判別します。
-
netdeviceドライバー: コンテナーのnetns内の通常のカーネルネットワークデバイス -
vfio-pciドライバー: コンテナーにマウントされるキャラクターデバイス
SR-IOV ネットワークデバイスは、ベアメタルまたは Red Hat OpenStack Platform (RHOSP) インフラ上にインストールされた OpenShift Container Platform クラスターにネットワークを追加して、高帯域または低遅延を確保する必要のあるアプリケーションに使用できます。
SR-IOV ネットワークのマルチネットワークポリシーを設定できます。これのサポートはテクノロジープレビューであり、SR-IOV 追加ネットワークはカーネル NIC でのみサポートされます。データプレーン開発キット (DPDK) アプリケーションではサポートされていません。
SR-IOV ネットワークでマルチネットワークポリシーを作成しても、マルチネットワークポリシーが設定されていない SR-IOV ネットワークと比較して、アプリケーションに同じパフォーマンスが提供されない場合があります。
SR-IOV ネットワークのマルチネットワークポリシーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
次のコマンドを使用して、ノードで SR-IOV を有効にできます。
oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
関連情報
18.1.1. SR-IOV ネットワークデバイスを管理するコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SR-IOV スタックのコンポーネントを作成し、管理します。Operator は次の機能を実行します。
- SR-IOV ネットワークデバイスの検出および管理のオーケストレーション
-
SR-IOV Container Network Interface (CNI) の
NetworkAttachmentDefinitionカスタムリソースの生成 - SR-IOV ネットワークデバイスプラグインの設定の作成および更新
-
ノード固有の
SriovNetworkNodeStateカスタムリソースの作成 -
各
SriovNetworkNodeStateカスタムリソースのspec.interfacesフィールドの更新
Operator は以下のコンポーネントをプロビジョニングします。
- SR-IOV ネットワーク設定デーモン
- SR-IOV Network Operator の起動時にワーカーノードにデプロイされるデーモンセット。デーモンは、クラスターで SR-IOV ネットワークデバイスを検出し、初期化します。
- SR-IOV Network Operator Webhook
- Operator カスタムリソースを検証し、未設定フィールドに適切なデフォルト値を設定する動的受付コントローラー Webhook。
- SR-IOV Network Resources Injector
-
SR-IOV VF などのカスタムネットワークリソースの要求および制限のある Kubernetes Pod 仕様のパッチを適用するための機能を提供する動的受付コントローラー Webhook。SR-IOV Network Resources Injector は、Pod 内の最初のコンテナーのみに
resourceフィールドを自動的に追加します。 - SR-IOV ネットワークデバイスプラグイン
- SR-IOV ネットワーク Virtual Function (VF) リソースの検出、公開、割り当てを実行するデバイスプラグイン。デバイスプラグインは、とりわけ物理デバイスでの制限されたリソースの使用を有効にするために Kubernetes で使用されます。デバイスプラグインは Kubernetes スケジューラーにリソースの可用性を認識させるため、スケジューラーはリソースが十分にあるノードで Pod をスケジュールできます。
- SR-IOV CNI プラグイン
- SR-IOV ネットワークデバイスプラグインから割り当てられる VF インターフェイスを直接 Pod に割り当てる CNI プラグイン。
- SR-IOV InfiniBand CNI プラグイン
- SR-IOV ネットワークデバイスプラグインから割り当てられる InfiniBand (IB) VF インターフェイスを直接 Pod に割り当てる CNI プラグイン。
SR-IOV Network Resources Injector および SR-IOV Network Operator Webhook は、デフォルトで有効にされ、default の SriovOperatorConfig CR を編集して無効にできます。SR-IOV Network Operator Admission Controller Webhook を無効にする場合は注意してください。トラブルシューティングなどの特定の状況下や、サポートされていないデバイスを使用する場合は、Webhook を無効にすることができます。
18.1.1.1. サポート対象のプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は、以下のプラットフォームに対応しています。
- ベアメタル
- Red Hat OpenStack Platform (RHOSP)
18.1.1.2. サポートされるデバイス リンクのコピーリンクがクリップボードにコピーされました!
以下のネットワークインターフェイスコントローラーは、OpenShift Container Platform でサポートされています。
| 製造元 | モデル | ベンダー ID | デバイス ID |
|---|---|---|---|
| Broadcom | BCM57414 | 14e4 | 16d7 |
| Broadcom | BCM57508 | 14e4 | 1750 |
| Broadcom | BCM57504 | 14e4 | 1751 |
| Intel | X710 | 8086 | 1572 |
| Intel | X710 Backplane | 8086 | 1581 |
| Intel | X710 Base T | 8086 | 15ff |
| Intel | XL710 | 8086 | 1583 |
| Intel | XXV710 | 8086 | 158b |
| Intel | E810-CQDA2 | 8086 | 1592 |
| Intel | E810-2CQDA2 | 8086 | 1592 |
| Intel | E810-XXVDA2 | 8086 | 159b |
| Intel | E810-XXVDA4 | 8086 | 1593 |
| Intel | E810-XXVDA4T | 8086 | 1593 |
| Intel | Ice E810-XXV Backplane | 8086 | 1599 |
| Intel | Ice E823L Backplane | 8086 | 124c |
| Intel | Ice E823L SFP | 8086 | 124d |
| Marvell | OCTEON Fusion CNF105XX | 177d | ba00 |
| Marvell | OCTEON10 CN10XXX | 177d | b900 |
| Mellanox | MT27700 Family [ConnectX‑4] | 15b3 | 1013 |
| Mellanox | MT27710 Family [ConnectX‑4 Lx] | 15b3 | 1015 |
| Mellanox | MT27800 Family [ConnectX‑5] | 15b3 | 1017 |
| Mellanox | MT28880 Family [ConnectX‑5 Ex] | 15b3 | 1019 |
| Mellanox | MT28908 Family [ConnectX‑6] | 15b3 | 101b |
| Mellanox | MT2892 Family [ConnectX-6 Dx] | 15b3 | 101d |
| Mellanox | MT2894 Family [ConnectX‑6 Lx] | 15b3 | 101f |
| Mellanox | Mellanox MT2910 ファミリー [ConnectX‑7] | 15b3 | 1021 |
| Mellanox | ConnectX-6 NIC モードの MT42822 BlueField-2 | 15b3 | a2d6 |
| Pensando [1] | ionic ドライバー用 DSC-25 デュアルポート 25G 分散サービスカード | 0x1dd8 | 0x1002 |
| Pensando [1] | ionic ドライバー用 DSC-100 デュアルポート 100G 分散サービスカード | 0x1dd8 | 0x1003 |
| Silicom | STS ファミリー | 8086 | 1591 |
- OpenShift SR-IOV はサポートされますが、SR-IOV を使用する際に SR-IOV CNI config ファイルを使用して静的な Virtual Function (VF) メディアアクセス制御 (MAC) アドレスを設定する必要があります。
サポートされているカードの最新リストおよび利用可能な互換性のある OpenShift Container Platform バージョンについては、Openshift Single Root I/O Virtualization (SR-IOV) and PTP hardware networks Support Matrix を参照してください。
18.1.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
18.2. SR-IOV ネットワークデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.2.1. SR-IOV ネットワークノード設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークノードポリシーを作成して、ノードの SR-IOV ネットワークデバイス設定を指定します。ポリシーの API オブジェクトは sriovnetwork.openshift.io API グループの一部です。
以下の YAML は SR-IOV ネットワークノードポリシーを説明しています。
- 1
- カスタムリソースオブジェクトの名前。
- 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
名前を指定するときは、
resourceNameで使用できる構文式^[a-zA-Z0-9_]+$を必ず使用してください。 - 4
- ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。重要
SR-IOV Network Operator は、ノードネットワーク設定ポリシーを順番にノードに適用します。ノードネットワーク設定ポリシーを適用する前に、SR-IOV Network Operator は、ノードのマシン設定プール (MCP) が
DegradedまたはUpdatingなどの正常ではない状態にないか確認します。ノード正常ではない MCP にある場合、ノードネットワーク設定ポリシーをクラスター内のすべての対象ノードに適用するプロセスは、MCP が正常な状態に戻るまで一時停止します。正常でない MCP 内にあるノードが、他のノード (他の MCP 内のノードを含む) にノードネットワーク設定ポリシーを適用することを阻害しないようにするには、MCP ごとに別のノードネットワーク設定ポリシーを作成する必要があります。
- 5
- オプション: 優先度は
0から99までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10の優先度は99よりも高くなります。デフォルト値は99です。 - 6
- オプション: Physical Function とそのす Virtual Function すべての最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェイスコントローラー (NIC) に応じて異なります。重要
デフォルトのネットワークインターフェイス上に仮想機能を作成する場合は、MTU がクラスター MTU と一致する値に設定されていることを確認してください。
Pod に割り当てられている 1 つの Virtual Function の MTU を変更する場合は、SR-IOV ネットワークノードポリシーで MTU 値を空白のままにします。そうしない場合、SR-IOV Network Operator により Virtual Function の MTU が SR-IOV ネットワークノードポリシーで定義された MTU 値に戻され、ノードドレインがトリガーされる可能性があります。
- 7
- オプション:
/dev/vhost-netデバイスを Pod にマウントするには、needVhostNetをtrueに設定します。Data Plane Development Kit(DPDK) と共にマウントされた/dev/vhost-netデバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。 - 8
- SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
127よりも大きくすることはできません。 - 9
externallyManagedフィールドは、SR-IOV Network Operator が Virtual Function (VF) のすべてを管理するか、またはサブセットのみを管理するかを示します。値をfalseに設定すると、SR-IOV Network Operator が PF 上のすべての VF を管理および設定します。注記externallyManagedをtrueに設定した場合、SriovNetworkNodePolicyリソースを適用する前に、物理機能 (PF) 上に仮想機能 (VF) を手動で作成する必要があります。VF が事前に作成されていないと、SR-IOV Network Operator の Webhook によってポリシー要求がブロックされます。externallyManagedをfalseに設定した場合、SR-IOV Network Operator が、VF を自動的に作成および管理し、必要に応じて VF のリセットなどを実行します。ホストシステムで VF を使用するには、NMState を通じて VF を作成し、
externallyManagedをtrueに設定する必要があります。このモードでは、SR-IOV Network Operator は、ポリシーのnicSelectorフィールドで明示的に定義されている VF を除き、PF または手動で管理される VF を変更しません。ただし、SR-IOV Network Operator は、Pod のセカンダリーインターフェイスとして使用される VF を引き続き管理します。- 10
- NIC セレクターにより、このリソースを適用するデバイスを指定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevicesを指定する場合、vendor、deviceID、またはpfNamesの値も指定する必要があります。pfNamesおよびrootDevicesの両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilterの値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。 - 11
- オプション: SR-IOV ネットワークデバイスの 16 進数ベンダー識別子。許可される値は
8086(Intel) と15b3(Mellanox) のみです。 - 12
- オプション: SR-IOV ネットワークデバイスの 16 進数デバイス識別子。たとえば、
101bは Mellanox ConnectX-6 デバイスのデバイス ID です。 - 13
- オプション: リソースを適用する必要がある 1 つ以上の物理機能 (PF) 名の配列。
- 14
- オプション: リソースを適用する必要がある 1 つ以上の PCI バスアドレスの配列。たとえば、
0000:02:00.1です。 - 15
- オプション: プラットフォーム固有のネットワークフィルター。サポートされるプラットフォームは Red Hat OpenStack Platform (RHOSP) のみです。許可される値は、
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxの形式を使用します。xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxを、/var/config/openstack/latest/network_data.jsonメタデータファイルの値に置き換えます。このフィルターにより、VF が特定の OpenStack ネットワークに確実に関連付けられます。Operator はこのフィルターを使用して、OpenStack プラットフォームによって提供されるメタデータに基づき、VF を適切なネットワークにマッピングします。 - 16
- オプション: このリソースから作成される VF 用に設定するドライバー。許可される値は
netdeviceおよびvfio-pciのみです。デフォルト値はnetdeviceです。Mellanox NIC をベアメタルノードの DPDK モードで機能させるには、
netdeviceドライバータイプを使用し、isRdmaをtrueに設定します。 - 17
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は
falseです。isRdmaパラメーターがtrueに設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdmaをtrueに設定し、追加のneedVhostNetをtrueに設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。注記Intel NIC の場合、
isRdmaパラメーターをtrueに設定することはできません。 - 18
- オプション: VF のリンクタイプ。イーサネットのデフォルト値は
ethです。InfiniBand の場合、この値を 'ib' に変更します。linkTypeがibに設定されている場合、SR-IOV Network Operator Webhook によってisRdmaはtrueに自動的に設定されます。linkTypeがibに設定されている場合、deviceTypeはvfio-pciに設定できません。SriovNetworkNodePolicy の linkType を
ethに設定しないでください。デバイスプラグインによって報告される使用可能なデバイスの数が正しくなくなる可能性があります。 - 19
- オプション: ハードウェアオフロードを有効にするには、
eSwitchModeフィールドを"switchdev"に設定する必要があります。ハードウェアオフロードの詳細は、「ハードウェアオフロードの設定」を参照してください。 - 20
- オプション: SR-IOV ネットワークリソースの NUMA ノードを Topology Manager にアドバタイスする場合を除外するには、値を
trueに設定します。デフォルト値はfalseです。
18.2.1.1. SR-IOV ネットワークノードの設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、InfiniBand デバイスの設定を示しています。
InfiniBand デバイスの設定例
以下の例は、RHOSP 仮想マシンの SR-IOV ネットワークデバイスの設定を示しています。
仮想マシンの SR-IOV デバイスの設定例
18.2.1.2. SR-IOV ネットワークデバイスの自動検出 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。
CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces リストは、ノード上のネットワークデバイスに関する情報を提供します。
SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。
18.2.1.2.1. SriovNetworkNodeState オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。
SriovNetworkNodeState オブジェクト
18.2.1.3. SR-IOV デバイスの Virtual Function (VF) パーティション設定 リンクのコピーリンクがクリップボードにコピーされました!
Virtual Function (VF) を同じ物理機能 (PF) から複数のリソースプールに分割する必要がある場合があります。たとえば、VF の一部をデフォルトドライバーで読み込み、残りの VF を vfio-pci ドライバーで読み込む必要がある場合などです。このようなデプロイメントでは、SriovNetworkNodePolicy カスタムリソース (CR) の pfNames セレクターは、以下の形式を使用してプールの VF の範囲を指定するために使用できます: <pfname>#<first_vf>-<last_vf>
たとえば、以下の YAML は、VF が 2 から 7 まである netpf0 という名前のインターフェイスのセレクターを示します。
pfNames: ["netpf0#2-7"]
pfNames: ["netpf0#2-7"]
-
netpf0は PF インターフェイス名です。 -
2は、範囲に含まれる最初の VF インデックス (0 ベース) です。 -
7は、範囲に含まれる最後の VF インデックス (0 ベース) です。
以下の要件を満たす場合、異なるポリシー CR を使用して同じ PF から VF を選択できます。
-
numVfsの値は、同じ PF を選択するポリシーで同一である必要があります。 -
VF インデックスは、
0から<numVfs>-1の範囲にある必要があります。たとえば、numVfsが8に設定されているポリシーがある場合、<first_vf>の値は0よりも小さくすることはできず、<last_vf>は7よりも大きくすることはできません。 - 異なるポリシーの VF の範囲は重複しないようにしてください。
-
<first_vf>は<last_vf>よりも大きくすることはできません。
以下の例は、SR-IOV デバイスの NIC パーティション設定を示しています。
ポリシー policy-net-1 は、デフォルトの VF ドライバーと共に PF netpf0 の VF 0 が含まれるリソースプール net-1 を定義します。ポリシー policy-net-1-dpdk は、vfio VF ドライバーと共に PF netpf0 の VF 8 から 15 までが含まれるリソースプール net-1-dpdk を定義します。
ポリシー policy-net-1:
ポリシー policy-net-1-dpdk:
インターフェイスが正常にパーティショニングされていることを確認します
次のコマンドを実行して、インターフェイスが SR-IOV デバイスの Virtual Function (VF) にパーティショニングされていることを確認します。
ip link show <interface>
$ ip link show <interface>
- 1
<interface>を、SR-IOV デバイスの VF にパーティショニングするときに指定したインターフェイス (例:ens3f1) に置き換えます。
出力例
18.2.1.4. OpenStack で SR-IOV を使用するクラスター用のテスト Pod テンプレート リンクのコピーリンクがクリップボードにコピーされました!
次の testpmd Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。
testpmd Pod の例
- 1
- この例では、パフォーマンスプロファイルの名前が
cnf-performance profileであると想定しています。
18.2.1.5. OpenStack で OVS ハードウェアオフロードを使用するクラスター用のテスト Pod テンプレート リンクのコピーリンクがクリップボードにコピーされました!
次の testpmd Pod は、Red Hat OpenStack Platform (RHOSP) での Open vSwitch (OVS) ハードウェアオフロードを示しています。
testpmd Pod の例
- 1
- パフォーマンスプロファイルの名前が
cnf-performance profileでない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。
18.2.1.6. Downward API の huge page リソースの挿入 リンクのコピーリンクがクリップボードにコピーされました!
Pod 仕様に huge page のリソース要求または制限が含まれる場合、Network Resources Injector は Downward API フィールドを Pod 仕様に自動的に追加し、huge page 情報をコンテナーに提供します。
Network Resources Injector は、podnetinfo という名前のボリュームを追加し、Pod の各コンテナー用に /etc/podnetinfo にマウントされます。ボリュームは Downward API を使用し、huge page の要求および制限に関するファイルを追加します。ファイルの命名規則は以下のとおりです。
-
/etc/podnetinfo/hugepages_1G_request_<container-name> -
/etc/podnetinfo/hugepages_1G_limit_<container-name> -
/etc/podnetinfo/hugepages_2M_request_<container-name> -
/etc/podnetinfo/hugepages_2M_limit_<container-name>
直前のリストで指定されているパスは、app-netutil ライブラリーと互換性があります。デフォルトで、ライブラリーは、/etc/podnetinfo ディレクトリーのリソース情報を検索するように設定されます。Downward API パス項目を手動で指定する選択をする場合、app-netutil ライブラリーは前述のリストのパスに加えて以下のパスを検索します。
-
/etc/podnetinfo/hugepages_request -
/etc/podnetinfo/hugepages_limit -
/etc/podnetinfo/hugepages_1G_request -
/etc/podnetinfo/hugepages_1G_limit -
/etc/podnetinfo/hugepages_2M_request -
/etc/podnetinfo/hugepages_2M_limit
Network Resources Injector が作成できるパスと同様に、前述の一覧のパスの末尾にはオプションで _<container-name> 接尾辞を付けることができます。
18.2.2. SR-IOV ネットワークデバイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。再起動は次の場合にのみ行われます。
-
Mellanox NIC (
mlx5ドライバー) の場合、Physical Function (PF) 上の Virtual Function (VF) の数が増加するたびにノードの再起動が行われます。 -
Intel NIC の場合、カーネルパラメーターに
intel_iommu=onとiommu=ptが含まれていない場合にのみ再起動が行われます。
設定の変更が適用されるまでに数分かかる場合があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
- ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがある。
- SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していない。
手順
-
SriovNetworkNodePolicyオブジェクトを作成してから、YAML を<name>-sriov-node-network.yamlファイルに保存します。<name>をこの設定の名前に置き換えます。 -
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、
SriovNetworkNodePolicy.Spec.NodeSelectorでラベルを付けます。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。 SriovNetworkNodePolicyオブジェクトを作成します。oc create -f <name>-sriov-node-network.yaml
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operatornamespace のすべての Pod がRunningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.3. Non-Uniform Memory Access (NUMA) に対応した SR-IOV Pod の作成 リンクのコピーリンクがクリップボードにコピーされました!
NUMA で配置された SR-IOV Pod は、restricted または single-numa-node Topology Manager ポリシーで同じ NUMA ノードから割り当てられる SR-IOV および CPU リソースを制限することによって作成できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
CPU マネージャーのポリシーを
staticに設定している。CPU マネージャーの詳細は、「関連情報」セクションを参照してください。 Topology Manager ポリシーを
single-numa-nodeに設定している。注記single-numa-nodeが要求を満たさない場合は、Topology Manager ポリシーをrestrictedにするように設定できます。より柔軟な SR-IOV ネットワークリソーススケジューリングについては、関連情報 セクションの NUMA 対応スケジューリングにおける SR-IOV ネットワークトポロジーの除外 を参照してください。
手順
以下の SR-IOV Pod 仕様を作成してから、YAML を
<name>-sriov-pod.yamlファイルに保存します。<name>をこの Pod の名前に置き換えます。以下の例は、SR-IOV Pod 仕様を示しています。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して SR-IOV Pod のサンプルを作成します。
oc create -f <filename>
$ oc create -f <filename>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<filename>を、先の手順で作成したファイルの名前に置き換えます。
sample-podが Guaranteed QoS を指定して設定されていることを確認します。oc describe pod sample-pod
$ oc describe pod sample-podCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-podが排他的 CPU を指定して割り当てられていることを確認します。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow sample-podに割り当てられる SR-IOV デバイスと CPU が同じ NUMA ノード上にあることを確認します。oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.4. NUMA 対応スケジューリング用の SR-IOV ネットワークトポロジーを除外する場合 リンクのコピーリンクがクリップボードにコピーされました!
NUMA 対応 Pod のスケジューリングでより柔軟な SR-IOV ネットワークデプロイメントを実現するために、SR-IOV ネットワークの Non-Uniform Memory Access (NUMA) ノードを Topology Manager にアドバタイズする場合を除外できます。
一部のシナリオでは、シングル NUMA ノード上の Pod の CPU およびメモリーリソースを最大化することが優先されます。Topology Manager に Pod の SR-IOV ネットワークリソースの NUMA ノードに関するヒントを提供しないことで、Topology Manager は SR-IOV ネットワークリソースと Pod の CPU およびメモリーリソースを異なる NUMA ノードにデプロイできます。その場合、NUMA ノード間のデータ転送により、ネットワーク遅延が増加する可能性があります。ただし、ワークロードが最適な CPU とメモリーのパフォーマンスを必要とするシナリオでは許容されます。
たとえば、2 つの NUMA ノード (uma0 と uma1) を備えたコンピュートノード compute-1 があるとします。SR-IOV が有効な NIC は numa0 にあります。Pod のスケジューリングに使用できる CPU は、numa1 にしかありません。excludeTopology 仕様を true に設定すると、Topology Manager は Pod の CPU およびメモリーリソースを numa1 に割り当て、同じ Pod の SR-IOV ネットワークリソースを numa0 に割り当てることができます。これは、excludeTopology 仕様を true に設定した場合にのみ可能です。そうではない場合、Topology Manager はすべてのリソースを同じ NUMA ノードに配置しようとします。
18.2.5. SR-IOV 設定のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。
ノードの状態を表示するには、以下のコマンドを実行します。
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
ここで、<node_name> は SR-IOV ネットワークデバイスを持つノードの名前を指定します。
エラー出力: Cannot allocate memory
"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"
"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"
ノードがメモリーを割り当てることができないことを示す場合は、以下の項目を確認します。
- ノードの BIOS でグローバル SR-IOV 設定が有効になっていることを確認します。
- ノードの BIOS で VT-d が有効であることを確認します。
18.2.6. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
18.3. SR-IOV イーサネットネットワーク割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスのイーサネットネットワーク割り当てを設定できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.3.1. イーサネットデバイス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
イーサネットネットワークデバイスは、SriovNetwork オブジェクトを定義して設定できます。
以下の YAML は SriovNetwork オブジェクトを説明しています。
- 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ
NetworkAttachmentDefinitionオブジェクトを作成します。 - 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーターの値。 - 4
SriovNetworkオブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- オプション: 追加ネットワークの仮想 LAN (VLAN) ID。整数値は
0から4095である必要があります。デフォルト値は0です。 - 6
- オプション: VF の spoof チェックモード。許可される値は、文字列の
"on"および"off"です。重要指定する値は引用符で囲む必要があります。引用符で囲まないと、オブジェクトが SR-IOV Network Operator によって拒否されます。
- 7
- YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
- 8
- オプション: Virtual Function (VF) のリンク状態。許可される値は、
enable、disable、およびautoです。 - 9
- オプション: VF の最大伝送レート (Mbps)。
- 10
- オプション: VF の最小伝送レート (Mbps)。この値は、最大伝送レート以下である必要があります。注記
Intel NIC は
minTxRateパラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。 - 11
- オプション: VF の IEEE 802.1p 優先度レベル。デフォルト値は
0です。 - 12
- オプション: VF の信頼モード。許可される値は、文字列の
"on"および"off"です。重要指定する値を引用符で囲む必要があります。囲まないと、SR-IOV Network Operator はオブジェクトを拒否します。
- 13
- オプション: この追加ネットワークに設定する機能。
'{ "ips": true }'を指定して IP アドレスのサポートを有効にするか、'{ "mac": true }'を指定して MAC アドレスのサポートを有効にすることができます。
18.3.1.1. デュアルスタック IP アドレスを動的に割り当てる設定の作成 リンクのコピーリンクがクリップボードにコピーされました!
デュアルスタックの IP アドレスの割り当ては、ipRanges パラメーターで設定できます。
- IPv4 アドレス
- IPv6 アドレス
- 複数の IP アドレスの割り当て
手順
-
typeをwhereaboutsに設定します。 以下の例のように、
ipRangesを使用して IP アドレスを割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ネットワークを Pod にアタッチします。詳細は、「追加のネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.1.2. ネットワークアタッチメントの IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。
以下の IP アドレスの割り当てタイプを使用できます。
- 静的割り当て。
- DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
- Whereabouts IPAM CNI プラグインを使用した動的割り当て。
18.3.1.2.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、静的 IP アドレスの割り当ての設定を説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses の配列には、以下のフィールドのあるオブジェクトが必要です。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
18.3.1.2.2. 動的 IP アドレス (DHCP) 割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
イーサネットネットワークアタッチメントの場合、SR-IOV Network Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
次の表は、DHCP による動的 IP アドレス割り当ての設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
以下の JSON の例は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
動的 IP アドレス (DHCP) 割り当ての設定例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
18.3.1.2.3. Whereabouts を使用した動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。
Whereabouts CNI プラグインは、重複する IP アドレス範囲と、別々の NetworkAttachmentDefinitions CRD 内で同じ CIDR 範囲を複数回設定することもサポートしています。これにより、マルチテナント環境での柔軟性と管理機能が向上します。
18.3.1.2.3.1. 動的 IP アドレス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定オブジェクトを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
|
|
| オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。 |
18.3.1.2.3.2. Whereabouts を使用した動的 IP アドレス割り当て設定 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、Whereabouts を使用する動的アドレス割り当て設定を示しています。
whereabouts 動的 IP アドレスの割り当て
18.3.1.2.3.3. IP アドレス範囲が重複する場合に Whereabouts を使用した動的 IP アドレス割り当て リンクのコピーリンクがクリップボードにコピーされました!
次の例は、マルチテナントネットワークで重複する IP アドレスの範囲を使用する、動的な IP アドレスの割り当てを示しています。
NetworkAttachmentDefinition 1
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 2のnetwork_nameと一致する必要があります。
NetworkAttachmentDefinition 2
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 1のnetwork_nameと一致する必要があります。
18.3.2. SR-IOV の追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
SriovNetwork オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork オブジェクトの作成時に、SR-IOV Network Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
SriovNetwork オブジェクトが running 状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
SriovNetworkオブジェクトを作成してから、YAML を<name>.yamlファイルに保存します。<name>はこの追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オブジェクトを作成するには、以下のコマンドを入力します。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>は追加ネットワークの名前を指定します。オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovNetworkオブジェクトに関連付けられたNetworkAttachmentDefinitionオブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace>をSriovNetworkオブジェクトで指定した networkNamespace に置き換えます。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.3. SR-IOV ネットワークの VRF への割り当て リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、CNI VRF プラグインを使用して、SR-IOV ネットワークインターフェイスを VRF ドメインに割り当てることができます。
これを実行するには、VRF 設定を SriovNetwork リソースのオプションの metaPlugins パラメーターに追加します。
VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE オプションを使用できます。SO_BINDTODEVICE は、渡されるインターフェイス名で指定されているデバイスにソケットをバインドします (例: eth1)。SO_BINDTODEVICE を使用するには、アプリケーションに CAP_NET_RAW 機能がある必要があります。
ip vrf exec コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェイスに直接バインドします。
18.3.3.1. CNI VRF プラグインを使用した追加 SR-IOV ネットワーク割り当ての作成 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。
SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
CNI VRF プラグインで追加の SR-IOV ネットワーク割り当てを作成するには、以下の手順を実行します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
手順
追加の SR-IOV ネットワーク割り当て用の
SriovNetworkカスタムリソース (CR) を作成し、以下のサンプル CR のようにmetaPlugins設定を挿入します。YAML をsriov-network-attachment.yamlファイルとして保存します。SriovNetworkカスタムリソース (CR) の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkリソースを作成します。oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR が正常に作成されることの確認
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinitionCR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例:additional-sriov-network-1)。
出力例
NAME AGE additional-sriov-network-1 14m
NAME AGE additional-sriov-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
追加の SR-IOV ネットワーク割り当てが正常であることの確認
VRF CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
- VRF CNI を使用する SR-IOV ネットワークを作成します。
- ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Table ----------------------- red 10
Name Table ----------------------- red 10Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、VRF インターフェイスがセカンダリーインターフェイスの
masterであることを確認します。ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.4. イーサネットベースの SR-IOV 割り当てのランタイム設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに割り当てる場合、ランタイム設定を指定して Pod の特定のカスタマイズを行うことができます。たとえば、特定の MAC ハードウェアアドレスを要求できます。
Pod 仕様にアノテーションを設定して、ランタイム設定を指定します。アノテーションキーは k8s.v1.cni.cncf.io/networks で、ランタイム設定を記述する JSON オブジェクトを受け入れます。
以下の JSON は、イーサネットベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。
- 1
- SR-IOV ネットワーク割り当て定義 CR の名前。
- 2
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、
SriovNetworkオブジェクトで{ "mac": true }も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetworkオブジェクトで{ "ips": true }も指定する必要があります。
ランタイム設定の例
18.3.5. Pod の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターにログインする。
手順
アノテーションを
Podオブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成するには、以下のコマンドを入力します。
<name>を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: アノテーションが
PodCR に存在することを確認するには、<name>を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
example-podPod が追加ネットワークのnet1に割り当てられています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/network-statusパラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスを説明します。アノテーションの値はプレーンテキストの値として保存されます。
18.3.6. SR-IOV ネットワークポリシーの更新中に並列ノードドレインを設定する リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、再設定によってワークロードが影響を受けないように、一度に 1 つのノードに対してこのアクションを実行します。
大規模なクラスターでは、ノードを順番にドレインするには時間がかかり、数時間または数日かかることもあります。時間に敏感な環境では、SriovNetworkPoolConfig カスタムリソース (CR) で並列ノードドレインを有効にして、SR-IOV ネットワーク設定のロールアウトを高速化できます。
並列ドレインを設定するには、SriovNetworkPoolConfig CR を使用してノードプールを作成します。次に、プールにノードを追加し、Operator が並行してドレインできるプール内のノードの最大数を定義できます。このアプローチでは、実行中のワークロードを処理するために十分なノードがプール内に残っていることを確認しながら、並列ドレインを有効にして再設定を高速化できます。
ノードは 1 つの SR-IOV ネットワークプール設定にのみ属することができます。ノードがプールの一部でない場合は、一度に 1 つのノードのみをドレインするように設定された仮想のデフォルトプールに追加されます。
ドレイン処理中にノードが再起動する可能性があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator をインストールします。
- ノードには SR-IOV をサポートするハードウェアがあります。
手順
SriovNetworkPoolConfigリソースを作成します。SriovNetworkPoolConfigリソースを定義する YAML ファイルを作成します。sriov-nw-pool.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkPoolConfigオブジェクトの名前を指定します。- 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- 更新中にプール内で使用できなくなるノードの整数値またはパーセンテージ値を指定します。たとえば、ノードが 10 個あり、使用不可の最大数を 2 に設定した場合は、一度に並列ドレインできるノードは 2 個だけとなり、ワークロードの処理には 8 個のノードが残ります。
- 4
- ノードセレクターを使用して、プールを追加するノードを指定します。この例では、
workerロールを持つすべてのノードをプールに追加します。
次のコマンドを実行して、
SriovNetworkPoolConfigリソースを作成します。oc create -f sriov-nw-pool.yaml
$ oc create -f sriov-nw-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、
sriov-testnamespace を作成します。oc create namespace sriov-test
$ oc create namespace sriov-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkNodePolicyリソースを作成します。SriovNetworkNodePolicyリソースを定義する YAML ファイルを作成します。sriov-node-policy.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkNodePolicyリソースを作成します。oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SriovNetworkリソースを作成します。SriovNetworkリソースを定義する YAML ファイルを作成します。sriov-network.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkリソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、作成したノードプールを表示します。
oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE pool-1 67s
NAME AGE pool-1 67s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、
pool-1にはworkerロールを持つすべてのノードが含まれています。
上記の手順のシナリオ例を使用してノードドレインプロセスをデモンストレーションするには、次の手順を実行します。
クラスター内のワークロードのドレインをトリガーするには、
SriovNetworkNodePolicyリソース内の Virtual Function の数を更新します。oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ターゲットクラスターのドレインステータスを監視します。
oc get sriovNetworkNodeState -n openshift-sriov-network-operator
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10h
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ドレインプロセスが完了すると、
SYNC STATUSがSucceededに変わり、DESIRED SYNC STATEとCURRENT SYNC STATEの値がIDLEに戻ります。出力例
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 Succeeded Idle Idle 3d10h openshift-sriov-network-operator worker-1 Succeeded Idle Idle 3d10h
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 Succeeded Idle Idle 3d10h openshift-sriov-network-operator worker-1 Succeeded Idle Idle 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3.7. NUMA 対応スケジューリングのための SR-IOV ネットワークトポロジーの除外 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークリソースの Non-Uniform Memory Access (NUMA) ノードを Topology Manager にアドバタイズする場合を除外するには、SriovNetworkNodePolicy カスタムリソースで excludeTopology 仕様を設定できます。NUMA 対応 Pod のスケジューリングでより柔軟な SR-IOV ネットワークデプロイメントを行うには、この設定を使用します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
CPU マネージャーのポリシーを
staticに設定している。CPU マネージャーの詳細は、関連情報 セクションを参照してください。 -
Topology Manager ポリシーを
single-numa-nodeに設定している。 - SR-IOV Network Operator がインストールされている。
手順
SriovNetworkNodePolicyCR を作成します。次の YAML を
sriov-network-node-policy.yamlファイルに保存し、環境に合わせて YAML 内の値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記複数の
SriovNetworkNodePolicyリソースが同じ SR-IOV ネットワークリソースをターゲットとする場合、SriovNetworkNodePolicyリソースの値はexcludeTopology仕様と同じである必要があります。そうでない場合、矛盾するポリシーは拒否されます。次のコマンドを実行して、
SriovNetworkNodePolicyリソースを作成します。oc create -f sriov-network-node-policy.yaml
$ oc create -f sriov-network-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SriovNetworkCR を作成します。次の YAML を
sriov-network.yamlファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkリソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成し、前の手順で作成した SR-IOV ネットワークリソースを割り当てます。
次の YAML を
sriov-network-pod.yamlファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- これは、
SriovNetworkNodePolicyリソースを使用するSriovNetworkリソースの名前です。
次のコマンドを実行して、
Podリソースを作成します。oc create -f sriov-network-pod.yaml
$ oc create -f sriov-network-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pod/example-pod created
pod/example-pod createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、Pod のステータスを確認します。その場合、
<pod_name>は Pod の名前に置き換えます。oc get pod <pod_name>
$ oc get pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲット Pod とのデバッグセッションを開き、SR-IOV ネットワークリソースがメモリーおよび CPU リソースとは異なるノードにデプロイされていることを確認します。
次のコマンドを実行して、Pod とのデバッグセッションを開きます。その場合、<pod_name> はターゲット Pod の名前に置き換えます。
oc debug pod/<pod_name>
$ oc debug pod/<pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow /hostをデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストからのルートファイルシステムをマウントします。ルートディレクトリーを/hostに変更すると、ホストファイルシステムからのバイナリーを実行できます。chroot /host
$ chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、CPU 割り当てに関する情報を表示します。
lscpu | grep NUMA
$ lscpu | grep NUMACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat /proc/self/status | grep Cpus
$ cat /proc/self/status | grep CpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat /sys/class/net/net1/device/numa_node
$ cat /sys/class/net/net1/device/numa_nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
0
0Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、CPU 1、3、5、7 が
NUMA node1に割り当てられていますが、SR-IOV ネットワークリソースはNUMA node0の NIC を使用できます。
excludeTopology 仕様が True に設定されている場合、必要なリソースが同じ NUMA ノードに存在する可能性があります。
18.4. SR-IOV InfiniBand ネットワーク割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスの InfiniBand (IB) ネットワーク割り当てを設定できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.4.1. InfiniBand デバイス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
SriovIBNetwork オブジェクトを定義することで、InfiniBand (IB) ネットワークデバイスを設定できます。
以下の YAML は、SriovIBNetwork オブジェクトを説明しています。
- 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ
NetworkAttachmentDefinitionオブジェクトを作成します。 - 2
- SR-IOV Operator がインストールされている namespace。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーターの値。 - 4
SriovIBNetworkオブジェクトのターゲット namespace。ターゲット namespace の Pod のみをネットワークデバイスに割り当てることができます。- 5
- オプション: YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
- 6
- オプション: Virtual Function (VF) のリンク状態。許可される値は、
enable、disable、およびautoです。 - 7
- オプション: このネットワークに設定する機能。
'{ "ips": true }'を指定して IP アドレスのサポートを有効にするか、'{ "infinibandGUID": true }'を指定して IB Global Unique Identifier (GUID) のサポートを有効にすることができます。
18.4.1.1. デュアルスタック IP アドレスを動的に割り当てる設定の作成 リンクのコピーリンクがクリップボードにコピーされました!
デュアルスタックの IP アドレスの割り当ては、ipRanges パラメーターで設定できます。
- IPv4 アドレス
- IPv6 アドレス
- 複数の IP アドレスの割り当て
手順
-
typeをwhereaboutsに設定します。 以下の例のように、
ipRangesを使用して IP アドレスを割り当てます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ネットワークを Pod にアタッチします。詳細は、「追加のネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip aCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.4.1.2. ネットワークアタッチメントの IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。
以下の IP アドレスの割り当てタイプを使用できます。
- 静的割り当て。
- DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
- Whereabouts IPAM CNI プラグインを使用した動的割り当て。
18.4.1.2.1. 静的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、静的 IP アドレスの割り当ての設定を説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses の配列には、以下のフィールドのあるオブジェクトが必要です。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
18.4.1.2.2. 動的 IP アドレス (DHCP) 割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
イーサネットネットワークアタッチメントの場合、SR-IOV Network Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
次の表は、DHCP による動的 IP アドレス割り当ての設定パラメーターを示しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
以下の JSON の例は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
動的 IP アドレス (DHCP) 割り当ての設定例
{
"ipam": {
"type": "dhcp"
}
}
{
"ipam": {
"type": "dhcp"
}
}
18.4.1.2.3. Whereabouts を使用した動的 IP アドレス割り当ての設定 リンクのコピーリンクがクリップボードにコピーされました!
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。
Whereabouts CNI プラグインは、重複する IP アドレス範囲と、別々の NetworkAttachmentDefinitions CRD 内で同じ CIDR 範囲を複数回設定することもサポートしています。これにより、マルチテナント環境での柔軟性と管理機能が向上します。
18.4.1.2.3.1. 動的 IP アドレス設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定オブジェクトを説明しています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
IPAM のアドレスタイプ。値 |
|
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
|
|
| オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。 |
18.4.1.2.3.2. Whereabouts を使用した動的 IP アドレス割り当て設定 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、Whereabouts を使用する動的アドレス割り当て設定を示しています。
whereabouts 動的 IP アドレスの割り当て
18.4.1.2.3.3. IP アドレス範囲が重複する場合に Whereabouts を使用した動的 IP アドレス割り当て リンクのコピーリンクがクリップボードにコピーされました!
次の例は、マルチテナントネットワークで重複する IP アドレスの範囲を使用する、動的な IP アドレスの割り当てを示しています。
NetworkAttachmentDefinition 1
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 2のnetwork_nameと一致する必要があります。
NetworkAttachmentDefinition 2
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 1のnetwork_nameと一致する必要があります。
18.4.2. SR-IOV の追加ネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
SriovIBNetwork オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovIBNetwork オブジェクトの作成時に、SR-IOV Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。
SriovIBNetwork オブジェクトが、running 状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
SriovIBNetworkオブジェクトを作成し、YAML を<name>.yamlファイルに保存します。<name>はこの追加ネットワークの名前です。オブジェクト仕様は以下の例のようになります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オブジェクトを作成するには、以下のコマンドを入力します。
oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>は追加ネットワークの名前を指定します。オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovIBNetworkオブジェクトに関連付けられたNetworkAttachmentDefinitionオブジェクトが存在することを確認します。<namespace>をSriovIBNetworkオブジェクトで指定した networkNamespace に置き換えます。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.4.3. InfiniBand ベースの SR-IOV 割り当てのランタイム設定 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに割り当てる場合、ランタイム設定を指定して Pod の特定のカスタマイズを行うことができます。たとえば、特定の MAC ハードウェアアドレスを要求できます。
Pod 仕様にアノテーションを設定して、ランタイム設定を指定します。アノテーションキーは k8s.v1.cni.cncf.io/networks で、ランタイム設定を記述する JSON オブジェクトを受け入れます。
以下の JSON は、InfiniBand ベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。
ランタイム設定の例
18.4.4. Pod の追加ネットワークへの追加 リンクのコピーリンクがクリップボードにコピーされました!
Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。
Pod が追加ネットワークと同じ namespace にあること。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスターにログインする。
手順
アノテーションを
Podオブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。
<network>を、Pod に関連付ける追加ネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成するには、以下のコマンドを入力します。
<name>を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: アノテーションが
PodCR に存在することを確認するには、<name>を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
example-podPod が追加ネットワークのnet1に割り当てられています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
k8s.v1.cni.cncf.io/network-statusパラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスを説明します。アノテーションの値はプレーンテキストの値として保存されます。
18.5. SR-IOV ネットワークのインターフェイスレベルのネットワーク sysctl 設定とオールマルチキャストモードを設定する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、SR-IOV ネットワークデバイスに接続されている Pod のチューニング Container Network Interface (CNI) メタプラグインを使用して、インターフェイスレベルのネットワーク sysctl と、プロミスキャスモード、オールマルチキャストモード、MTU、MAC アドレスなどのいくつかのインターフェイス属性を変更できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.5.1. SR-IOV 対応 NIC を使用したノードのラベル付け リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV 対応ノードのみで SR-IOV を有効にしたい場合は、いくつかの方法があります。
-
Node Feature Discovery (NFD) Operator をインストールします。NFD は SR-IOV 対応の NIC の存在を検出し、ノードに
node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = trueラベルを付けます。 各ノードの
SriovNetworkNodeStateCR を調べます。interfacesスタンザには、ワーカーノード上の SR-IOV Network Operator によって検出されるすべての SR-IOV デバイスの一覧が含まれます。次のコマンドを使用して、各ノードにfeature.node.kubernetes.io/network-sriov.capable: "true"というラベルを付けます。$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記任意の名前でノードにラベルを付けることができます。
18.5.2. 1 つの sysctl フラグの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークデバイスに接続された Pod のインターフェイスレベルのネットワーク sysctl 設定を設定できます。
この例では、作成された仮想インターフェイスで net.ipv4.conf.IFNAME.accept_redirects が 1 に設定されます。
sysctl-tuning-test は、この例で使用される namespace です。
次のコマンドを使用して、
sysctl-tuning-testnamespace を作成します。oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.2.1. SR-IOV ネットワークデバイスを持つノードで 1 つの sysctl フラグを設定する リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用すると、SR-IOV Operator がノードをドレインして再起動する場合があります。
設定の変更が適用されるまでに数分の時間がかかる場合があります。
この手順に従って、SriovNetworkNodePolicy カスタムリソース (CR) を作成します。
手順
SriovNetworkNodePolicyカスタムリソース (CR) を作成します。たとえば、次の YAML をファイルpolicyoneflag-sriov-node-network.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタムリソースオブジェクトの名前。
- 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
- 4
- ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション: 優先度は
0から99までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10の優先度は99よりも高くなります。デフォルト値は99です。 - 6
- SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
127よりも大きくすることはできません。 - 7
- NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevicesを指定する場合、vendor、deviceID、またはpfNamesの値も指定する必要があります。pfNamesおよびrootDevicesの両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilterの値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。 - 8
- オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
- 9
- オプション: Virtual Function のドライバータイプ。許可される唯一の値は
netdeviceです。ベアメタルノードで Mellanox NIC を DPDK モードで動作させるには、isRdmaをtrueに設定します。 - 10
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は
falseです。isRdmaパラメーターがtrueに設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdmaをtrueに設定し、追加のneedVhostNetをtrueに設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。
注記vfio-pciドライバータイプはサポートされていません。SriovNetworkNodePolicyオブジェクトを作成します。oc create -f policyoneflag-sriov-node-network.yaml
$ oc create -f policyoneflag-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定の更新が適用された後に、
sriov-network-operatornamespace 変更のすべての Pod がRunningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Succeeded
SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.2.2. SR-IOV ネットワークでの sysctl の設定 リンクのコピーリンクがクリップボードにコピーされました!
SriovNetwork リソースのオプションの metaPlugins パラメーターにチューニング設定を追加することで、SR-IOV により作成された仮想インターフェイスにインターフェイス固有の sysctl 設定を設定できます。
SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。
SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
インターフェイスレベルのネットワーク net.ipv4.conf.IFNAME.accept_redirects sysctl 設定を変更するには、Container Network Interface (CNI) チューニングプラグインを使用して追加の SR-IOV ネットワークを作成します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
手順
追加の SR-IOV ネットワーク割り当て用の
SriovNetworkカスタムリソース (CR) を作成し、以下のサンプル CR のようにmetaPlugins設定を挿入します。YAML をsriov-network-interface-sysctl.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
- 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーターの値。 - 4
SriovNetworkオブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
- 6
- オプション: 追加のネットワークの機能を設定します。IP アドレスのサポートを有効にするには、
"{ "ips": true }"を指定できます。または、MAC アドレスのサポートを有効にするには"{ "mac": true }"を指定します。 - 7
- オプション: metaPlugins パラメーターは、デバイスに機能を追加するために使用されます。このユースケースでは、
typeフィールドをtuningに設定します。設定したいインターフェイスレベルのネットワークsysctlをsysctlフィールドに指定します。
SriovNetworkリソースを作成します。oc create -f sriov-network-interface-sysctl.yaml
$ oc create -f sriov-network-interface-sysctl.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR が正常に作成されることの確認
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinitionCR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>を、SriovNetworkオブジェクトで指定したnetworkNamespaceの値に置き換えます。たとえば、sysctl-tuning-testです。
出力例
NAME AGE onevalidflag 14m
NAME AGE onevalidflag 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
追加の SR-IOV ネットワーク割り当てが正常であることの確認
チューニング CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
PodCR を作成します。次の YAML をexamplepod.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- SR-IOV ネットワーク割り当て定義 CR の名前。
- 2
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、SriovNetwork オブジェクトで
{ "mac": true }も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetworkオブジェクトで{ "ips": true }も指定する必要があります。
PodCR を作成します。oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod にログインします。
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定された sysctl フラグの値を確認します。次のコマンドを実行して、
net.ipv4.conf.IFNAME.accept_redirectsの値を見つけます。sysctl net.ipv4.conf.net1.accept_redirects
$ sysctl net.ipv4.conf.net1.accept_redirectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
net.ipv4.conf.net1.accept_redirects = 1
net.ipv4.conf.net1.accept_redirects = 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3. ボンディングされた SR-IOV インターフェイスフラグに関連付けられた Pod の sysctl 設定の設定 リンクのコピーリンクがクリップボードにコピーされました!
ボンディングされた SR-IOV ネットワークデバイスに接続された Pod のインターフェイスレベルのネットワーク sysctl 設定を設定できます。
この例では、設定可能な特定のネットワークインターフェイスレベルの sysctl 設定がボンドインターフェイスに設定されています。
sysctl-tuning-test は、この例で使用される namespace です。
次のコマンドを使用して、
sysctl-tuning-testnamespace を作成します。oc create namespace sysctl-tuning-test
$ oc create namespace sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3.1. SR-IOV ネットワークデバイスがボンドされたノードですべての sysctl フラグを設定する リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。
設定の変更が適用されるまでに数分かかる場合があります。
この手順に従って、SriovNetworkNodePolicy カスタムリソース (CR) を作成します。
手順
SriovNetworkNodePolicyカスタムリソース (CR) を作成します。次の YAML をpolicyallflags-sriov-node-network.yamlファイルとして保存します。policyallflagsを設定の名前に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カスタムリソースオブジェクトの名前。
- 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
- 4
- ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション: 優先度は
0から99までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10の優先度は99よりも高くなります。デフォルト値は99です。 - 6
- SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は
127よりも大きくすることはできません。 - 7
- NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevicesを指定する場合、vendor、deviceID、またはpfNamesの値も指定する必要があります。pfNamesおよびrootDevicesの両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilterの値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。 - 8
- オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
- 9
- オプション: Virtual Function のドライバータイプ。許可される唯一の値は
netdeviceです。ベアメタルノードで Mellanox NIC を DPDK モードで動作させるには、isRdmaをtrueに設定します。 - 10
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は
falseです。isRdmaパラメーターがtrueに設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdmaをtrueに設定し、追加のneedVhostNetをtrueに設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。
注記vfio-pciドライバータイプはサポートされていません。SriovNetworkNodePolicy オブジェクトを作成します。
oc create -f policyallflags-sriov-node-network.yaml
$ oc create -f policyallflags-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が
Runningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Succeeded
SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.3.2. ボンディングされた SR-IOV ネットワークでの sysctl の設定 リンクのコピーリンクがクリップボードにコピーされました!
2 つの SR-IOV インターフェイスから作成されたボンドインターフェイスで、インターフェイス固有の sysctl 設定を設定できます。これを行うには、bond ネットワーク接続定義のオプションの Plugins パラメーターにチューニング設定を追加します。
SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
特定のインターフェイスレベルのネットワーク sysctl 設定を変更するには、次の手順を使用して、Container Network Interface (CNI) チューニングプラグインを使用して、SriovNetwork カスタムリソース (CR) を作成します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
手順
次の例の CR のように、ボンドされたインターフェイスの
SriovNetworkカスタムリソース (CR) を作成します。YAML をsriov-network-attachment.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
- 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーターの値。 - 4
SriovNetworkオブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- オプション: この追加ネットワークに設定する機能。IP アドレスのサポートを有効にするには、
"{ "ips": true }"を指定できます。または、MAC アドレスのサポートを有効にするには"{ "mac": true }"を指定します。
SriovNetworkリソースを作成します。oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例の CR のように、ボンドネットワーク接続定義を作成します。YAML を
sriov-bond-network-interface.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- タイプは
bondです。 - 2
mode属性は、ボンドモードを指定します。サポートされているボンドモードは次のとおりです。-
balance-rr- 0 -
active-backup- 1 balance-xor- 2balance-rrまたはbalance-xorモードの場合には、SR-IOV Virtual Function のtrustモードをonに設定する必要があります。
-
- 3
failover属性は、active-backup モードでは必須です。- 4
linksInContainer=trueフラグは、必要なインターフェイスがコンテナー内にあることをボンディング CNI に通知します。デフォルトでは、ボンディング CNI は、SRIOV および Multus との統合で機能しないホストで、このようなインターフェイスを検索します。- 5
linksセクションは、結合の作成に使用するインターフェイスを定義します。デフォルトでは、Multus は接続されたインターフェイスに "net" と 1 から始まる連続した番号の名前を付けます。- 6
- YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。この Pod の例では、IP アドレスは手動で設定されているため、この場合、
ipamは static に設定されています。 - 7
- デバイスに追加の機能を追加します。たとえば、
typeフィールドをtuningに設定します。設定したいインターフェイスレベルのネットワークsysctlを sysctl フィールドに指定します。この例では、設定可能なすべてのインターフェイスレベルのネットワークsysctl設定を設定します。
ボンドネットワーク接続リソースを作成します。
oc create -f sriov-bond-network-interface.yaml
$ oc create -f sriov-bond-network-interface.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR が正常に作成されることの確認
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinitionCR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>は、ネットワーク割り当ての設定時に指定した networkNamespace に置き換えます (例:sysctl-tuning-test)。
出力例
NAME AGE bond-sysctl-network 22m allvalidflags 47m
NAME AGE bond-sysctl-network 22m allvalidflags 47mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
SR-IOV ネットワークリソースの追加が成功したことの確認
チューニング CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
PodCR を作成します。たとえば、次の YAML をexamplepod.yamlファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- SR-IOV ネットワーク割り当て定義 CR の名前。
- 2
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、SriovNetwork オブジェクトで
{ "mac": true }も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetworkオブジェクトで{ "ips": true }も指定する必要があります。
YAML を適用します。
oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod -n sysctl-tuning-test
$ oc get pod -n sysctl-tuning-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod にログインします。
oc rsh -n sysctl-tuning-test tunepod
$ oc rsh -n sysctl-tuning-test tunepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定された
sysctlフラグの値を確認します。次のコマンドを実行して、net.ipv6.neigh.IFNAME.base_reachable_time_msの値を見つけます。sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_msCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.5.4. オールマルチキャストモード リンクのコピーリンクがクリップボードにコピーされました!
特にルートレスアプリケーションのコンテキストでは、オールマルチキャストモードを有効にすることが重要です。このモードを有効にしない場合は、Pod のセキュリティーコンテキスト制約 (SCC) に NET_ADMIN ケイパビリティーを付与する必要があります。NET_ADMIN ケイパビリティーを使用して、特定の要件を超える変更を行う権限を Pod に付与すると、セキュリティーの脆弱性が露呈する可能性があります。
チューニング CNI プラグインは、オールマルチキャストモードを含め、いくつかのインターフェイス属性の変更をサポートしています。このモードを有効にすると、SR-IOV ネットワークデバイス上で設定された Virtual Function (VF) 上で実行されているアプリケーションは、接続されている物理機能が同じか異なるかにかかわらず、他の VF 上のアプリケーションからマルチキャストトラフィックを受信できます。
18.5.4.1. SR-IOV ネットワーク上でオールマルチキャストモードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV インターフェイスでオールマルチキャストモードを有効にするには、次の方法があります。
-
SriovNetworkリソースのmetaPluginsパラメーターにチューニング設定を追加します。 チューニング設定で、
allmultiフィールドをtrueに設定します。注記信頼を有効にして Virtual Function (VF) を作成していることを確認してください。
SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。
SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
このガイダンスに従って、SR-IOV ネットワーク上でオールマルチキャストモードを有効にします。
前提条件
- OpenShift Container Platform CLI (oc) がインストールされている。
-
cluster-admin権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている。 - SR-IOV Network Operator がインストールされている。
-
適切な
SriovNetworkNodePolicyオブジェクトを設定している。
手順
Mellanox ConnectX-5 デバイスの
SriovNetworkNodePolicyオブジェクトを定義する次の設定を使用して、YAML ファイルを作成します。YAML ファイルをsriovnetpolicy-mlx.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: SR-IOV 対応クラスターノードにラベルが付けられていない場合は、
SriovNetworkNodePolicy.Spec.NodeSelectorラベルを追加します。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。 以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f sriovnetpolicy-mlx.yaml
$ oc create -f sriovnetpolicy-mlx.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定の更新を適用すると、
sriov-network-operatornamespace 内のすべての Pod が自動的にRunningステータスに移行します。次のコマンドを実行して、
enable-allmulti-testnamespace を作成します。oc create namespace enable-allmulti-test
$ oc create namespace enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 追加の SR-IOV ネットワーク接続用の
SriovNetworkカスタムリソース (CR) を作成し、以下のサンプル CR YAML のようにmetaPlugins設定を挿入し、そのファイルをsriov-enable-all-multicast.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オブジェクトの名前を指定します。SR-IOV Network Operator は、同じ名前を持つ
NetworkAttachmentDefinitionオブジェクトを作成します。 - 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicyオブジェクトのspec.resourceNameパラメーター値を指定します。 - 4
SriovNetworkオブジェクトのターゲット namespace を指定します。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
- 6
- オプション: 追加のネットワークの機能を設定します。IP アドレスのサポートを有効にするには、
"{ "ips": true }"を指定できます。または、MAC アドレスのサポートを有効にするには"{ "mac": true }"を指定します。 - 7
- Virtual Function の信頼モードを指定します。これは "on" に設定する必要があります。
- 8
metaPluginsパラメーターを使用して、デバイスにケイパビリティーをさらに追加します。このユースケースでは、typeフィールドをtuningに設定し、allmultiフィールドを追加してtrueに設定します。
次のコマンドを実行して、
SriovNetworkリソースを作成します。oc create -f sriov-enable-all-multicast.yaml
$ oc create -f sriov-enable-all-multicast.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR の検証
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinitionCR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>を、SriovNetworkオブジェクトで指定したnetworkNamespaceの値に置き換えます。この例では、enable-allmulti-testです。
出力例
NAME AGE enableallmulti 14m
NAME AGE enableallmulti 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
次のコマンドを実行して、SR-IOV ネットワークリソースに関する情報を表示します。
oc get sriovnetwork -n openshift-sriov-network-operator
$ oc get sriovnetwork -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
追加の SR-IOV ネットワーク接続の検証
チューニング CNI が正しく設定されていること、および追加の SR-IOV ネットワーク接続が割り当てられていることを確認するには、次の手順を実行します。
PodCR を作成します。次のサンプル YAML をexamplepod.yamlという名前のファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- SR-IOV network attachment definition CR の名前を指定します。
- 2
- オプション: SR-IOV network attachment definition CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレスを指定します。この機能を使用するには、SriovNetwork オブジェクトで
{"mac": true}も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレスを指定します。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetworkオブジェクトで{ "ips": true }も指定する必要があります。
以下のコマンドを実行して
Podを作成します。oc apply -f examplepod.yaml
$ oc apply -f examplepod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod -n enable-allmulti-test
$ oc get pod -n enable-allmulti-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE samplepod 1/1 Running 0 47sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod にログインします。
oc rsh -n enable-allmulti-test samplepod
$ oc rsh -n enable-allmulti-test samplepodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod に関連付けられているすべてのインターフェイスをリスト表示します。
ip link
sh-4.4# ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.6. SR-IOV 対応ワークロードの QinQ サポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
QinQ は正式には 802.1Q-in-802.1Q と呼ばれ、IEEE 802.1ad で定義されたネットワーク技術です。IEEE 802.1ad は IEEE 802.1Q-1998 標準を拡張し、すでに 802.1Q でタグ付けされているパケットに追加の 802.1Q タグを導入することで VLAN 機能を強化します。この方法は、VLAN スタッキングまたはダブル VLAN とも呼ばれます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.6.1. 802.1Q-in-802.1Q サポートについて リンクのコピーリンクがクリップボードにコピーされました!
従来の VLAN セットアップでは、フレームには通常、VLAN-100 などの単一の VLAN タグと、Quality of Service (QoS) ビットやプロトコル情報などのその他のメタデータが含まれます。QinQ は 2 番目の VLAN タグを導入します。ここで、サービスプロバイダーは外部タグを自社用に指定して柔軟性を提供し、内部タグは顧客の VLAN 専用のままになります。
QinQ は、二重の VLAN タグ付けを使用してネストされた VLAN の作成を容易にし、ネットワーク環境内でのトラフィックのより細かいセグメンテーションと分離を可能にします。このアプローチは、トラフィックの分離と隔離を確保しながら、共通のインフラストラクチャーを介して複数の顧客に VLAN ベースのサービスを提供する必要があるサービスプロバイダーネットワークで特に役立ちます。
次の図は、OpenShift Container Platform が SR-IOV と QinQ を使用して、コンテナー化されたワークロードの高度なネットワークセグメンテーションと分離を実現する方法を示しています。
この図は、SR-IOV をサポートするワーカーノードでダブル VLAN タグ付け (QinQ) がどのように機能するかを示しています。Pod namespace ext0 にある SR-IOV Virtual Function (VF) は、VLAN ID と VLAN プロトコルを使用して SR-IOVContainer Network Interface (CNI) によって設定されます。これは S-tag に対応します。Pod 内では、VLAN CNI がプライマリーインターフェイス ext0 を使用してサブインターフェイスを作成します。このサブインターフェイスは、C タグに対応する 802.1Q プロトコルを使用して内部 VLAN ID を追加します。
ここでは、QinQ がネットワーク内でより細かいトラフィックのセグメンテーションと分離を可能にする方法を示しています。右側にはイーサネットフレーム構造の詳細が示されており、VLAN タグ、EtherType、IP、TCP、およびペイロードセクションの両方が含まれていることが強調されています。QinQ は、トラフィックの分離と隔離を確保しながら、共有インフラストラクチャーを介して複数の顧客に VLAN ベースのサービスを提供することを容易にします。
OpenShift Container Platform SR-IOV ソリューションは、SriovNetwork カスタムリソース (CR) での VLAN プロトコルの設定をすでにサポートしています。Virtual Function (VF) はこのプロトコルを使用して、外部タグとも呼ばれる VLAN タグを設定できます。その後、Pod は VLAN CNI プラグインを使用して内部タグを設定できます。
| NIC | 802.1ad/802.1Q | 802.1Q/802.1Q |
|---|---|---|
| Intel X710 | いいえ | サポート対象 |
| Intel E810 | サポート対象 | サポート対象 |
| Mellanox | いいえ | サポート対象 |
18.6.2. SR-IOV 対応ワークロードの QinQ サポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
手順
次の内容を使用して、
sriovnetpolicy-810-sriov-node-network.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f sriovnetpolicy-810-sriov-node-network.yaml
$ oc create -f sriovnetpolicy-810-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 別のターミナルウィンドウを開き、次のコマンドを実行して、
openshift-sriov-network-operatornamespace で指定されたノードの SR-IOV ネットワークノード状態の同期ステータスを監視します。watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'$ watch -n 1 'oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath="{.status.syncStatus}"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 同期ステータスが
InProgressからSucceededに変更されたことを示します。SriovNetworkオブジェクトを作成し、インフラストラクチャーに属する S-tag またはService Tagと呼ばれる外部 VLAN を設定します。重要スイッチのトランクインターフェイスで VLAN を設定する必要があります。さらに、QinQ タグ付けをサポートするために、一部のスイッチをさらに設定することを推奨します。
次の内容を使用して、
nad-sriovnetwork-1ad-810.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してオブジェクトを作成します。
oc create -f nad-sriovnetwork-1ad-810.yaml
$ oc create -f nad-sriovnetwork-1ad-810.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
内部 VLAN を使用して
NetworkAttachmentDefinitionオブジェクトを作成します。内部 VLAN はネットワーク機能に属しているため、多くの場合、C-tag またはCustomer Tagと呼ばれます。次の内容を使用して、
nad-cvlan100.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pod 内の VF インターフェイスを指定します。Pod アノテーションに名前が設定されていないため、デフォルト名は
net1になります。
以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f nad-cvlan100.yaml
$ oc apply -f nad-cvlan100.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次の手順に従って、ノード上で QinQ がアクティブであることを確認します。
次の内容を使用して、
test-qinq-pod.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してテスト Pod を作成します。
oc create -f test-qinq-pod.yaml
$ oc create -f test-qinq-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod が存在するターゲットノードでデバッグセッションに入り、次のコマンドを実行してネットワークインターフェイス
ens5f0に関する情報を表示します。oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"
$ oc debug node/my-cluster-node -- bash -c "ip link show ens5f0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力の
vlan protocol 802.1adID は、インターフェイスがプロトコル 802.1ad (QinQ) による VLAN タグ付けをサポートしていることを示します。VLAN ID は 171 です。
18.7. 高パフォーマンスのマルチキャストの使用 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ハードウェアネットワーク上でマルチキャストを使用できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.7.1. 高パフォーマンスのマルチキャスト リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN ネットワークプラグインは、デフォルトネットワーク上の Pod 間のマルチキャストをサポートします。これは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のアプリケーションには適していません。インターネットプロトコルテレビ (IPTV) やマルチポイントビデオ会議など、ストリーミングメディアなどのアプリケーションでは、Single Root I/O Virtualization (SR-IOV) ハードウェアを使用してネイティブに近いパフォーマンスを提供できます。
マルチキャストに追加の SR-IOV インターフェイスを使用する場合:
- マルチキャストパッケージは、追加の SR-IOV インターフェイス経由で Pod によって送受信される必要があります。
- SR-IOV インターフェイスに接続する物理ネットワークは、OpenShift Container Platform で制御されないマルチキャストルーティングとトポロジーを判別します。
18.7.2. マルチキャストでの SR-IOV インターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、サンプルのマルチキャスト用の SR-IOV インターフェイスを作成します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
SriovNetworkNodePolicyオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストアプリケーションで Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
NET_ADMIN機能は、アプリケーションがマルチキャスト IP アドレスを SR-IOV インターフェイスに割り当てる必要がある場合にのみ必要です。それ以外の場合は省略できます。
18.8. DPDK および RDMA の使用 リンクのコピーリンクがクリップボードにコピーされました!
コンテナー化された Data Plane Development Kit (DPDK) アプリケーションは OpenShift Container Platform でサポートされています。Single Root I/O Virtualization (SR-IOV) ネットワークハードウェアは、Data Plane Development Kit (DPDK) および Remote Direct Memory Access (RDMA) で利用できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.8.1. Pod での Virtual Function の使用例 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV VF が割り当てられている Pod で、Remote Direct Memory Access (RDMA) または Data Plane Development Kit (DPDK) アプリケーションを実行できます。
以下の例では、RDMA モードで Virtual Function (VF) を使用する Pod を示しています。
RDMA モードを使用する Pod 仕様
以下の例は、DPDK モードの VF のある Pod を示しています。
DPDK モードを使用する Pod 仕様
18.8.2. Intel NIC を使用した DPDK モードでの Virtual Function の使用 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - SR-IOV Network Operator をインストールします。
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をintel-dpdk-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Virtual Function のドライバータイプを
vfio-pciに指定します。
注記SriovNetworkNodePolicyの各オプションに関する詳細は、Configuring SR-IOV network devicesセクションを参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f intel-dpdk-node-policy.yaml
$ oc create -f intel-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
SriovNetworkオブジェクトを作成してから、YAML をintel-dpdk-network.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetworkの各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して、
SriovNetworkオブジェクトを作成します。oc create -f intel-dpdk-network.yaml
$ oc create -f intel-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Pod仕様を作成してから、YAML をintel-dpdk-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのintel-dpdk-networkが作成される同じtarget_namespaceを指定します。Pod を異なる namespace に作成する場合、target_namespaceをPod仕様およびSriovNetworkオブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/hugeの下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfigCR でenableInjectorオプションをfalseに設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 7
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数default_hugepagesz=1GB、hugepagesz=1Gおよびhugepages=16を追加すると、16*1Gihugepage がシステムの起動時に割り当てられます。
以下のコマンドを実行して DPDK Pod を作成します。
oc create -f intel-dpdk-pod.yaml
$ oc create -f intel-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.3. Mellanox NIC を使用した DPDK モードでの Virtual Function の使用 リンクのコピーリンクがクリップボードにコピーされました!
Mellanox NIC で DPDK モードの Virtual Function を使用して、ネットワークノードポリシーを作成し、Data Plane Development Kit (DPDK) Pod を作成できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - Single Root I/O Virtualization (SR-IOV) Network Operator がインストールされている。
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
次の
SriovNetworkNodePolicyYAML 設定をmlx-dpdk-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkNodePolicyオブジェクトの各オプションの詳細な説明は、SR-IOV ネットワークデバイスの設定 を参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分かかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-dpdk-node-policy.yaml
$ oc create -f mlx-dpdk-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
SriovNetworkYAML 設定をmlx-dpdk-network.yamlファイルに保存します:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IP アドレス管理 (IPAM) コンテナーネットワークインターフェイス (CNI) プラグインの設定オブジェクトを YAML ブロックスカラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetworkオブジェクトの各オプションの詳細な説明は、SR-IOV ネットワークデバイスの設定 を参照してください。app-netutilオプションライブラリーには、コンテナーの親 Pod に関するネットワーク情報を収集するための API メソッドが複数あります。以下のコマンドを実行して、
SriovNetworkオブジェクトを作成します。oc create -f mlx-dpdk-network.yaml
$ oc create -f mlx-dpdk-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
PodYAML 設定をmlx-dpdk-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのmlx-dpdk-networkが作成される同じtarget_namespaceを指定します。別の namespace で Pod を作成するには、Pod仕様とSriovNetworkオブジェクトの両方でtarget_namespaceを変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/hugeの下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepagesに指定されているemptyDirボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfigCR でenableInjectorオプションをfalseに設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これを行うには、CPU マネージャーポリシーを
staticに設定し、サービス品質 (QoS) がGuaranteedの Pod を作成します。 - 7
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して DPDK Pod を作成します。
oc create -f mlx-dpdk-pod.yaml
$ oc create -f mlx-dpdk-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.4. TAP CNI を使用したカーネルアクセスでのルートレス DPDK ワークロード実行 リンクのコピーリンクがクリップボードにコピーされました!
DPDK アプリケーションは、ログメッセージなどの特定の種類のパケットを処理のためにカーネルに挿入するための例外パスとして virtio-user を使用できます。この機能の詳細は、例外パスとしての Virtio_user を参照してください。
OpenShift Container Platform バージョン 4.14 以降では、非権限 Pod を使用して、tap CNI プラグインと一緒に DPDK アプリケーションを実行できます。この機能を有効にするには、SriovNetworkNodePolicy オブジェクト内で needVhostNet パラメーターを true に設定して、vhost-net デバイスをマウントする必要があります。
図18.1 DPDK と TAP の設定例
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - SR-IOV Network Operator がインストールされている。
-
cluster-admin権限を持つユーザーとしてログインしている。 すべてのノードで
setsebools container_use_devices=onが root として設定されていることを確認します。注記Machine Config Operator を使用して、この SELinux ブール値を設定します。
手順
次の例のような内容を含むファイル (
test-namespace.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
Namespaceオブジェクトを新規作成します。oc apply -f test-namespace.yaml
$ oc apply -f test-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のようなコンテンツを含むファイル (
sriov-node-network-policy.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- これは、プロファイルが Mellanox ネットワークインターフェイスコントローラー (NIC) 専用に調整されていることを示します。
- 2
isRdmaをtrueに設定する必要があるのは、Mellanox NIC の場合のみです。- 3
- これにより、
/dev/net/tunおよび/dev/vhost-netデバイスがコンテナーにマウントされ、アプリケーションがタップデバイスを作成し、タップデバイスを DPDK ワークロードに接続できるようになります。 - 4
- SR-IOV ネットワークデバイスのベンダーの 16 進数コード。値 15b3 は Mellanox NIC に関連付けられています。
- 5
- SR-IOV ネットワークデバイスのデバイスの 16 進数コード。
以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f sriov-node-network-policy.yaml
$ oc create -f sriov-node-network-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
SriovNetworkオブジェクトを作成し、YAML をsriov-network-attachment.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkの各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー
app-netutilは、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。以下のコマンドを実行して、
SriovNetworkオブジェクトを作成します。oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容を含む、ネットワーク割り当て定義を指定するファイル (
tap-example.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトが作成されるのと同じtarget_namespaceを指定します。
次のコマンドを実行して、
NetworkAttachmentDefinitionオブジェクトを作成します。oc apply -f tap-example.yaml
$ oc apply -f tap-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容を含むファイル
(dpdk-pod-rootless.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトが作成されるのと同じtarget_namespaceを指定します。Pod を別の namespace に作成する場合は、target_namespaceをPod仕様とSriovNetworkオブジェクトの両方で変更します。- 2
- ボリュームにマウントされたディレクトリーおよびそれらのボリューム内に作成されたファイルのグループ所有権を設定します。
- 3
- コンテナーの実行に使用するプライマリーグループ ID を指定します。
- 4
- アプリケーションを含む DPDK イメージとアプリケーションで使用される DPDK ライブラリーを指定します。
- 5
- コンテナーの securityContext からすべての機能 (
ALL) を削除すると、通常の操作に必要とされる権限以上の権限がコンテナーからなくなります。 - 6
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。これらの機能は、
setcapコマンドを使用してバイナリーファイルでも設定する必要があります。 - 7
- Mellanox ネットワークインターフェイスコントローラー (NIC) には、
NET_RAW機能が必要です。 - 8
- コンテナーの実行に使用するユーザー ID を指定します。
- 9
- この設定で、Pod 内のコンテナー (複数可) にホストシステムへの権限アクセスを許可しないように指定します。
- 10
- この設定を使用すると、コンテナーは、割り当てられている初期の root 以外の権限を超えて権限を昇格できます。
- 11
- また、この設定により、コンテナーは root 以外のユーザーで実行されます。これにより、最小権限の原則が適用され、コンテナーが不正アクセスされる可能性を最小限に抑えるとともに、攻撃対象領域を減少させます。
- 12
- hugepage ボリュームを
/mnt/hugeの下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 13
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfigCR でenableInjectorオプションをfalseに設定して無効にすることができます。 - 14
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 15
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数default_hugepagesz=1GB、hugepagesz=1Gおよびhugepages=16を追加すると、16*1Gihugepage がシステムの起動時に割り当てられます。 - 16
- パフォーマンスプロファイルの名前が
cnf-performance profileでない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。
以下のコマンドを実行して DPDK Pod を作成します。
oc create -f dpdk-pod-rootless.yaml
$ oc create -f dpdk-pod-rootless.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.5. 特定の DPDK ラインレート達成に関する概要 リンクのコピーリンクがクリップボードにコピーされました!
特定の Data Plane Development Kit (DPDK) ラインレートを実現するには、Node Tuning Operator をデプロイし、Single Root I/O Virtualization (SR-IOV) を設定します。次のリソースの DPDK 設定も調整する必要があります。
- 分離された CPU
- hugepage
- トポロジースケジューラー
OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
DPDK テスト環境
次の図は、トラフィックテスト環境のコンポーネントを示しています。
- トラフィックジェネレーター: 大量のパケットトラフィックを生成できるアプリケーション。
- SR-IOV 対応 NIC: SR-IOV に対応したネットワークインターフェイスカードです。カードは、物理インターフェイス上で多数の Virtual Function を実行します。
- Physical Function (PF): SR-IOV インターフェイスをサポートするネットワークアダプターの PCI Express (PCIe) 機能。
- Virtual Function (VF): SR-IOV をサポートするネットワークアダプター上の軽量の PCIe 機能。VF は、ネットワークアダプターの PCIe PF に関連付けられています。VF は、ネットワークアダプターの仮想化されたインスタンスを表します。
- スイッチ: ネットワークスイッチ。ノードは中断なしに接続することもできます。
-
testpmd: DPDK に含まれるサンプルアプリケーション。testpmdアプリケーションを使用して、パケット転送モードで DPDK をテストできます。testpmdアプリケーションは、DPDK ソフトウェア開発キット (SDK) を使用して本格的なアプリケーションを構築する方法の例でもあります。 - worker 0 および worker 1: OpenShift Container Platform ノード。
18.8.6. SR-IOV と Node Tuning Operator を使用した DPDK ラインレートの実現 リンクのコピーリンクがクリップボードにコピーされました!
Node Tuning Operator を使用して、分離された CPU、ヒュージページ、およびトポロジースケジューラーを設定できます。その後、Node Tuning Operator と Single Root I/O Virtualization (SR-IOV) を使用して、特定の Data Plane Development Kit (DPDK) ラインレートを実現できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - SR-IOV Network Operator がインストールされている。
-
cluster-admin権限を持つユーザーとしてログインしている。 スタンドアロン Node Tuning Operator をデプロイしている。
注記OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
手順
次の例に基づいて
PerformanceProfileオブジェクトを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- システムでハイパースレッディングが有効になっている場合は、関連するシンボリックリンクを
isolatedおよびreservedの CPU グループに割り当てます。システムに複数の Non-Uniform Memory Access (NUMA) ノードが含まれている場合は、両方の NUMA から両方のグループに CPU を割り当てます。このタスクには Performance Profile Creator を使用することもできます。詳細は、コントロールプレーンプロファイルの作成 を参照してください。 - 2
- キューが予約済みの CPU 数に設定されているデバイスのリストを指定することもできます。詳細は、Node Tuning Operator を使用した NIC キューの削減 を参照してください。
- 3
- 必要なヒュージページの数とサイズを割り当てます。ヒュージページの NUMA 設定を指定できます。デフォルトでは、システムは、そのシステムにあるすべての NUMA ノードに偶数分を割り当てます。必要に応じて、ノードのリアルタイムカーネルの使用をリクエストできます。詳細は、リアルタイム機能を備えたワーカーのプロビジョニング を参照してください。
-
yamlファイルをmlx-dpdk-perfprofile-policy.yamlとして保存します。 次のコマンドを使用して、パフォーマンスプロファイルを適用します。
oc create -f mlx-dpdk-perfprofile-policy.yaml
$ oc create -f mlx-dpdk-perfprofile-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.6.1. コンテナーアプリケーションで使用する DPDK ライブラリー リンクのコピーリンクがクリップボードにコピーされました!
オプションライブラリー の app-netutil は、その Pod 内で実行されるコンテナーから Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
このライブラリーは、DPDK (Data Plane Development Kit) モードの SR-IOV Virtual Function (VF) のコンテナーへの統合を支援します。このライブラリーは Golang API と C API の両方を提供します。
現時点で 3 つの API メソッドが実装されています。
GetCPUInfo()- この機能は、コンテナーで利用可能な CPU を判別し、リストを返します。
GetHugepages()-
この機能は、各コンテナーの
Pod仕様で要求される huge page メモリーの量を判別し、値を返します。 GetInterfaces()- この機能は、コンテナーのインターフェイスセットを判別し、インターフェイスタイプとタイプ固有のデータと共にリストを返します。戻り値には、インターフェイスのタイプと、各インターフェイスのタイプ固有のデータが含まれます。
ライブラリーのリポジトリーには、コンテナーイメージ dpdk-app-centos をビルドするためのサンプル Dockerfile が含まれます。コンテナーイメージは、Pod 仕様の環境変数に応じて、l2fwd、l3wd または testpmd の DPDK サンプルアプリケーションのいずれかを実行できます。コンテナーイメージは、app-netutil ライブラリーをコンテナーイメージ自体に統合する例を提供します。ライブラリーを init コンテナーに統合することもできます。init コンテナーは必要なデータを収集し、データを既存の DPDK ワークロードに渡すことができます。
18.8.6.2. Virtual Function の SR-IOV Network Operator の例 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator を使用して、ノード上の SR-IOV をサポートする Physical Function NIC から Virtual Function (VF) を割り当てて設定できます。
Operator のデプロイの詳細は、SR-IOV Network Operator のインストール を参照してください。SR-IOV ネットワークデバイスの設定の詳細は、SR-IOV ネットワークデバイスの設定 を参照してください。
Intel VF と Mellanox VF での Data Plane Development Kit (DPDK) ワークロードの実行にはいくつかの違いがあります。このセクションでは、両方の VF タイプのオブジェクト設定の例を示します。以下は、Intel NIC で DPDK アプリケーションを実行するために使用される sriovNetworkNodePolicy オブジェクトの例です。
以下は、Mellanox NIC の sriovNetworkNodePolicy オブジェクトの例です。
18.8.6.3. SR-IOV Network Operator の例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、sriovNetwork オブジェクトの定義例です。この場合、Intel と Mellanox の設定は同じです。
- 1
- Whereabouts など、別の IP Address Management (IPAM) 実装を使用できます。詳細は、Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。
- 2
- ネットワーク接続定義が作成される
networkNamespaceを要求する必要があります。openshift-sriov-network-operatornamespace でsriovNetworkCR を作成する必要があります。 - 3
resourceNameの値は、sriovNetworkNodePolicyで作成されたresourceNameの値と一致する必要があります。
18.8.6.4. DPDK ベースワークロードの例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、Data Plane Development Kit (DPDK) コンテナーの例です。
SLEEP 状態の Pod を起動し、その Pod で exec 操作を実行して testpmd または DPDK ワークロードを開始しないでください。これにより、exec プロセスがどの CPU にも固定されていないため、割り込みが追加される可能性があります。
18.8.6.5. testpmd スクリプトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、testpmd を実行するスクリプトの例です。
この例では、2 つの異なる sriovNetwork CR を使用しています。環境変数には、Pod に割り当てられた Virtual Function (VF) PCI アドレスが含まれています。Pod 定義で同じネットワークを使用する場合は、pciAddress を分割する必要があります。トラフィックジェネレータの正しい MAC アドレスを設定することが重要です。この例では、カスタム MAC アドレスを使用しています。
18.8.7. Mellanox NIC を使用した RDMA モードでの Virtual Function の使用 リンクのコピーリンクがクリップボードにコピーされました!
RoCE (RDMA over Converged Ethernet) はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
RoCE (RDMA over Converged Ethernet) は、OpenShift Container Platform で RDMA を使用する場合に唯一サポートされているモードです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - SR-IOV Network Operator をインストールします。
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の
SriovNetworkNodePolicyオブジェクトを作成してから、YAML をmlx-rdma-node-policy.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkNodePolicyの各オプションに関する詳細は、Configuring SR-IOV network devicesセクションを参照してください。SriovNetworkNodePolicyオブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operatornamespace のすべての Pod がRunningステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-rdma-node-policy.yaml
$ oc create -f mlx-rdma-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
SriovNetworkオブジェクトを作成してから、YAML をmlx-rdma-network.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetworkの各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して
SriovNetworkNodePolicyオブジェクトを作成します。oc create -f mlx-rdma-network.yaml
$ oc create -f mlx-rdma-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の
Pod仕様を作成してから、YAML をmlx-rdma-pod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkオブジェクトのmlx-rdma-networkが作成される同じtarget_namespaceを指定します。Pod を異なる namespace に作成する場合は、target_namespaceをPod仕様およびSriovNetworkオブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する RDMA ライブラリーが含まれる RDMA イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/hugeの下の RDMA Pod にマウントします。hugepage ボリュームは、メディアがHugepagesに指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- CPU の数を指定します。RDMA Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
staticに設定し、GuaranteedQoS を持つ Pod を作成して実行されます。 - 6
- hugepage サイズ
hugepages-1Giまたはhugepages-2Miを指定し、RDMA Pod に割り当てられる hugepage の量を指定します。2Miおよび1Gihugepage を別々に設定します。1Gihugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して RDMA Pod を作成します。
oc create -f mlx-rdma-pod.yaml
$ oc create -f mlx-rdma-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.8.8. OpenStack で OVS-DPDK を使用するクラスター用のテスト Pod テンプレート リンクのコピーリンクがクリップボードにコピーされました!
次の testpmd Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。
testpmd Pod の例
18.9. Pod レベルのボンディングの使用 リンクのコピーリンクがクリップボードにコピーされました!
Pod レベルでのボンディングは、高可用性とスループットを必要とする Pod 内のワークロードを有効にするために不可欠です。Pod レベルのボンディングでは、カーネルモードインターフェイスで複数の Single Root I/O Virtualization (SR-IOV) Virtual Function インターフェイスからボンドインターフェイスを作成できます。SR-IOV Virtual Function は Pod に渡され、カーネルドライバーに割り当てられます。
Pod レベルのボンディングが必要なシナリオには、異なる Physical Function 上の複数の SR-IOV Virtual Function からのボンディングインターフェイスの作成が含まれます。ホストの 2 つの異なる Physical Function からボンディングインターフェイスを作成して、Pod レベルで高可用性およびスループットを実現するために使用できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
SR-IOV ネットワークの作成、ネットワークポリシー、ネットワーク接続定義、Pod などのタスクのガイダンスは SR-IOV ネットワークデバイスの設定 を参照してください。
18.9.1. 2 つの SR-IOV インターフェイスからのボンドインターフェイスの設定 リンクのコピーリンクがクリップボードにコピーされました!
ボンディングを使用して、複数のネットワークインターフェイスを、1 つの論理的な "bonded" インターフェイスに集約できます。Bond Container Network Interface (Bond-CNI) により、コンテナーでボンディング機能を使用できます。
Bond-CNI は、Single Root I/O Virtualization (SR-IOV) Virtual Function を使用して作成し、それらをコンテナーネットワーク namespace に配置できます。
OpenShift Container Platform は、SR-IOV Virtual Functions を使用する Bond-CNI のみをサポートします。SR-IOV Network Operator は、Virtual Function の管理に必要な SR-IOV CNI プラグインを提供します。他の CNI またはインターフェイスのタイプはサポートされていません。
前提条件
- SR-IOV Network Operator をインストールおよび設定して、コンテナー内の Virtual Functions を取得する必要があります。
- SR-IOV インターフェイスを設定するには、インターフェイスごとに SR-IOV ネットワークとポリシーを作成する必要があります。
- SR-IOV Network Operator は、定義された SR-IOV ネットワークとポリシーをもとに、各 SR-IOV インターフェイスのネットワーク接続定義を作成します。
-
linkStateは、SR-IOV Virtual Function のデフォルト値autoに設定されます。
18.9.1.1. ボンドネットワーク接続定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV Virtual Function が使用可能になったので、ボンドネットワーク接続定義を作成できます。
- 1
- cni-type は常に
bondに設定されます。 - 2
mode属性は、ボンドモードを指定します。注記サポートされているボンドモードは次のとおりです。
-
balance-rr- 0 -
active-backup- 1 -
balance-xor- 2
balance-rrまたはbalance-xorモードの場合には、SR-IOV Virtual Function のtrustモードをonに設定する必要があります。-
- 3
- active-backup モードでは
フェイルオーバー属性が必須であり、1 に設定する必要があります。 - 4
linksInContainer=trueフラグは、必要なインターフェイスがコンテナー内にあることをボンディング CNI に通知します。デフォルトでは、ボンディング CNI は、SRIOV および Multus との統合で機能しないホストで、このようなインターフェイスを検索します。- 5
linksセクションは、結合の作成に使用するインターフェイスを定義します。デフォルトでは、Multus は接続されたインターフェイスに "net" と 1 から始まる連続した番号の名前を付けます。
18.9.1.2. ボンディングインターフェイスを使用した Pod の作成 リンクのコピーリンクがクリップボードにコピーされました!
podbonding.yamlなどの名前の YAML ファイルに以下の内容を追加して Pod を作成し、この設定をテストします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ネットワークのアノテーションに注意してください。これには、SR-IOV ネットワーク割り当てが 2 つとボンドネットワーク割り当てが 1 つ含まれています。ボンド割り当ては、2 つの SR-IOV インターフェイスをボンドポートインターフェイスとして使用します。
以下のコマンドを実行して yaml を適用します。
oc apply -f podbonding.yaml
$ oc apply -f podbonding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して Pod インターフェイスを検査します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Pod アノテーションでインターフェイス名が設定されていない場合、インターフェイス名は
net<n>として自動的に割り当てられます (<n>は1から始まります)。オプション: たとえば
bond0などの特定のインターフェイス名を設定する場合は、次のようにk8s.v1.cni.cncf.io/networksアノテーションを編集し、bond0をインターフェイス名として設定します。annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0annotations: k8s.v1.cni.cncf.io/networks: demo/sriovnet1, demo/sriovnet2, demo/bond-net1@bond0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10. ハードウェアオフロードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、互換性のあるノードでハードウェアオフロードを設定して、データ処理パフォーマンスを向上させ、ホスト CPU の負荷を軽減できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.10.1. ハードウェアのオフロードについて リンクのコピーリンクがクリップボードにコピーされました!
Open vSwitch ハードウェアオフロードは、ネットワークタスクを CPU から迂回させ、ネットワークインターフェイスコントローラー上の専用プロセッサーにオフロードすることにより、ネットワークタスクを処理する方法です。その結果、クラスターは、データ転送速度の高速化、CPU ワークロードの削減、およびコンピューティングコストの削減の恩恵を受けることができます。
この機能の重要な要素は、SmartNIC と呼ばれる最新クラスのネットワークインターフェイスコントローラーです。SmartNIC は、計算量の多いネットワーク処理タスクを処理できるネットワークインターフェイスコントローラーです。専用のグラフィックカードがグラフィックパフォーマンスを向上させるのと同じように、SmartNIC はネットワークパフォーマンスを向上させることができます。いずれの場合も、専用プロセッサーにより、特定のタイプの処理タスクのパフォーマンスが向上します。
OpenShift Container Platform では、互換性のある SmartNIC を持つベアメタルノードのハードウェアオフロードを設定できます。ハードウェアオフロードは、SR-IOV Network Operator によって設定および有効化されます。
ハードウェアのオフロードは、すべてのワークロードまたはアプリケーションタイプと互換性があるわけではありません。次の 2 つの通信タイプのみがサポートされています。
- pod-to-pod
- pod-to-service。サービスは通常の Pod に基づく ClusterIP サービスです。
すべての場合において、ハードウェアのオフロードは、それらの Pod とサービスが互換性のある SmartNIC を持つノードに割り当てられている場合にのみ行われます。たとえば、ハードウェアをオフロードしているノードの Pod が、通常のノードのサービスと通信しようとしているとします。通常のノードでは、すべての処理がカーネルで行われるため、Pod からサービスへの通信の全体的なパフォーマンスは、その通常のノードの最大パフォーマンスに制限されます。ハードウェアオフロードは、DPDK アプリケーションと互換性がありません。
ノードでのハードウェアのオフロードを有効にし、使用する Pod を設定しないと、Pod トラフィックのスループットパフォーマンスが低下する可能性があります。OpenShift Container Platform で管理される Pod のハードウェアオフロードを設定することはできません。
18.10.2. サポートされるデバイス リンクのコピーリンクがクリップボードにコピーされました!
ハードウェアオフロードは、次のネットワークインターフェイスコントローラーでサポートされています。
| 製造元 | モデル | ベンダー ID | デバイス ID |
|---|---|---|---|
| Mellanox | MT27800 Family [ConnectX‑5] | 15b3 | 1017 |
| Mellanox | MT28880 Family [ConnectX‑5 Ex] | 15b3 | 1019 |
| Mellanox | MT2892 Family [ConnectX‑6 Dx] | 15b3 | 101d |
| Mellanox | MT2894 ファミリー [ConnectX-6 Lx] | 15b3 | 101f |
| Mellanox | ConnectX-6 NIC モードの MT42822 BlueField-2 | 15b3 | a2d6 |
18.10.3. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスターに、ハードウェアのオフロードがサポートされているネットワークインターフェイスコントローラーを備えたベアメタルマシンが少なくとも 1 台ある。
- SR-IOV ネットワークオペレーターをインストール しています。
- クラスターで OVN-Kubernetes ネットワークプラグインを使用 している。
-
OVN-Kubernetes ネットワークプラグイン設定 で、
gatewayConfig.routingViaHostフィールドがfalseに設定されています。
18.10.4. SR-IOV Network Operator の systemd モードへの設定 リンクのコピーリンクがクリップボードにコピーされました!
ハードウェアオフロードをサポートするには、まず SR-IOV Network Operator を systemd モードに設定する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
すべての SR-IOV Operator コンポーネントをデプロイするには、
SriovOperatorConfigカスタムリソース (CR) を作成します。次の YAML を含む
sriovOperatorConfig.yamlという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、リソースを作成します。
oc apply -f sriovOperatorConfig.yaml
$ oc apply -f sriovOperatorConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10.5. ハードウェアオフロード用のマシン設定プールの設定 リンクのコピーリンクがクリップボードにコピーされました!
ハードウェアオフロードを有効にするには、専用のマシン設定プールを作成し、SR-IOV Network Operator と連携するように設定する必要があります。
前提条件
-
SR-IOV Network Operator がインストールされ、
systemdモードに設定されている。
手順
ハードウェアオフロードを使用するマシンのマシン設定プールを作成します。
次の例のようなコンテンツを含む
mcp-offloading.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow マシン設定プールの設定を適用します。
oc create -f mcp-offloading.yaml
$ oc create -f mcp-offloading.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マシン設定プールにノードを追加します。プールのノードロールラベルで各ノードにラベルを付けます。
oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""
$ oc label node worker-2 node-role.kubernetes.io/mcp-offloading=""Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 新しいプールが作成されたことを確認するには、次のコマンドを実行します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このマシン設定プールを
SriovNetworkPoolConfigカスタムリソースに追加します。次の例のようなコンテンツを含むファイル (
sriov-pool-config.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ハードウェアオフロード用のマシン設定プールの名前。
設定を適用します。
oc create -f <SriovNetworkPoolConfig_name>.yaml
$ oc create -f <SriovNetworkPoolConfig_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkPoolConfigオブジェクトで指定された設定を適用すると、SR-IOV Operator は、マシン設定プール内のノードをドレインして再起動します。設定の変更が適用されるまでに数分かかる場合があります。
18.10.6. SR-IOV ネットワークノードポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークノードポリシーを作成することにより、ノードの SR-IOV ネットワークデバイス設定を作成できます。ハードウェアオフロードを有効にするには、値 "switchdev" を使用して .spec.eSwitchMode フィールドを定義する必要があります。
次の手順では、ハードウェアをオフロードするネットワークインターフェイスコントローラー用の SR-IOV インターフェイスを作成します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
次の例のようなコンテンツを含むファイル (
sriov-node-policy.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーの設定を適用します。
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SriovNetworkPoolConfigオブジェクトで指定された設定を適用すると、SR-IOV Operator は、マシン設定プール内のノードをドレインして再起動します。設定の変更が適用されるまでに数分かかる場合があります。
18.10.6.1. OpenStack の SR-IOV ネットワークノードポリシーの例 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、Red Hat OpenStack Platform (RHOSP) でハードウェアオフロードを使用するネットワークインターフェイスコントローラー (NIC) の SR-IOV インターフェイスを示しています。
RHOSP でのハードウェアオフロードを備えた NIC の SR-IOV インターフェイス
18.10.7. Virtual Function を使用したネットワークトラフィックのパフォーマンスの向上 リンクのコピーリンクがクリップボードにコピーされました!
この手順に従って、OVN-Kubernetes 管理ポートに Virtual Function を割り当て、そのネットワークトラフィックパフォーマンスを向上させます。
この手順により 2 つのプールが作成されます。1 つ目には OVN-Kubernetes によって使用される Virtual Function があり、2 つ目は残りの Virtual Function で構成されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
次のコマンドを実行して、SmartNIC が存在する各ワーカーノードに
network.operator.openshift.io/smart-nicラベルを追加します。oc label node <node-name> network.operator.openshift.io/smart-nic=
$ oc label node <node-name> network.operator.openshift.io/smart-nic=Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodesコマンドを使用して、使用可能なノードのリストを取得します。次の例のような内容を含む、管理ポート用の
sriov-node-mgmt-vf-policy.yamlという名前のポリシーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような内容を含む
sriov-node-policy.yamlという名前のポリシーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記sriov-node-mgmt-vf-policy.yamlファイルには、pfNamesキーとresourceNameキーの値がsriov-node-policy.yamlファイルとは異なります。両方のポリシーの設定を適用します。
oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f sriov-node-mgmt-vf-policy.yaml
$ oc create -f sriov-node-mgmt-vf-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理設定用にクラスター内に Cluster Network Operator (CNO) ConfigMap を作成します。
次の内容を含む
hardware-offload-config.yamlという名前の ConfigMap を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMap の設定を適用します。
oc create -f hardware-offload-config.yaml
$ oc create -f hardware-offload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10.8. ネットワーク接続定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
マシン設定プールと SR-IOV ネットワークノードポリシーを定義した後、指定したネットワークインターフェイスカードのネットワーク接続定義を作成できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
次の例のようなコンテンツを含むファイル (
net-attach-def.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク接続定義の設定を適用します。
oc create -f net-attach-def.yaml
$ oc create -f net-attach-def.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、新しい定義が存在するかどうかを確認します。
oc get net-attach-def -A
$ oc get net-attach-def -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE net-attach-def net-attach-def 43h
NAMESPACE NAME AGE net-attach-def net-attach-def 43hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.10.9. ネットワーク接続定義を Pod へ追加 リンクのコピーリンクがクリップボードにコピーされました!
マシン設定プール、SriovNetworkPoolConfig および SriovNetworkNodePolicy カスタムリソース、およびネットワーク接続定義を作成した後、ネットワーク接続定義を Pod 仕様に追加することにより、これらの設定を Pod に適用できます。
手順
Pod 仕様で、
.metadata.annotations.k8s.v1.cni.cncf.io/networksフィールドを追加し、ハードウェアオフロード用に作成したネットワーク接続定義を指定します。.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def.... metadata: annotations: v1.multus-cni.io/default-network: net-attach-def/net-attach-def1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 値は、ハードウェアオフロード用に作成したネットワーク接続定義の名前と namespace である必要があります。
18.11. Bluefield-2 を DPU から NIC に切り替える リンクのコピーリンクがクリップボードにコピーされました!
Bluefield-2 ネットワークデバイスをデータ処理ユニット (DPU) モードからネットワークインターフェイスコントローラー (NIC) モードに切り替えることができます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
18.11.1. Bluefield-2 を DPU モードから NIC モードに切り替える リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、Bluefield-2 をデータ処理ユニット (DPU) モードからネットワークインターフェイスコントローラー (NIC) モードに切り替えます。
現在、DPU から NIC モードへの Bluefield-2 の切り替えのみがサポートされています。NIC モードから DPU モードへの切り替えはサポートされていません。
前提条件
- SR-IOV Network Operator がインストールされている。詳細は、「SR-IOV Network Operator のインストール」を参照してください。
- Bluefield-2 を最新のファームウェアに更新している。詳細は、Firmware for NVIDIA BlueField-2 を参照してください。
手順
次のコマンドを入力して、各ワーカーノードに次のラベルを追加します。
oc label node <example_node_name_one> node-role.kubernetes.io/sriov=
$ oc label node <example_node_name_one> node-role.kubernetes.io/sriov=Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node <example_node_name_two> node-role.kubernetes.io/sriov=
$ oc label node <example_node_name_two> node-role.kubernetes.io/sriov=Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Network Operator のマシン設定プールを作成します。次に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
machineconfig.yamlファイルをワーカーノードに適用します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- オプション: オプションで、特定のカードの PCI アドレスを指定することができます。例えば
ExecStart=/bin/bash -c '/etc/default/switch_in_sriov_config_daemon.sh nic 0000:5e:00.0 || echo done'。デフォルトでは、最初のデバイスが選択されています。複数のデバイスがある場合は、使用する PCI アドレスを指定する必要があります。Bluefield-2 を DPU モードから NIC モードに切り替えるすべてのノードで、PCI アドレスが同じである必要があります。
- ワーカーノードが再起動するまで待ちます。再起動後、ワーカーノードの Bluefield-2 ネットワークデバイスは NIC モードに切り替わります。
- オプション: 最新の Bluefield-2 ファームウェアリリースでは、NIC モードに切り替えるためにハードウェアの再起動が必要になるため、ホストハードウェアを再起動する必要がある場合があります。
第19章 OVN-Kubernetes ネットワークプラグイン リンクのコピーリンクがクリップボードにコピーされました!
19.1. OVN-Kubernetes ネットワークプラグインについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、Pod およびサービスネットワークに仮想化ネットワークを使用します。
Red Hat OpenShift Networking の一部である OVN-Kubernetes ネットワークプラグインは、OpenShift Container Platform のデフォルトのネットワークプロバイダーです。OVN-Kubernetes は Open Virtual Network (OVN) をベースとしており、オーバーレイベースのネットワーク実装を提供します。OVN-Kubernetes プラグインを使用するクラスターは、各ノードで Open vSwitch (OVS) も実行します。OVN は、宣言ネットワーク設定を実装するように各ノードで OVS を設定します。
OVN-Kubernetes は、OpenShift Container Platform および単一ノードの OpenShift デプロイメントのデフォルトのネットワークソリューションです。
OVS プロジェクトから生まれた OVN-Kubernetes は、オープンフロールールなど、同じコンストラクトの多くを使用して、パケットがネットワークを通過する方法を決定します。詳細は、Open Virtual Network の Web サイト を参照してください。
OVN-Kubernetes は、仮想ネットワーク設定を OpenFlow ルールに変換する OVS 用の一連のデーモンです。OpenFlow は、ネットワークスイッチおよびルーターと通信するためのプロトコルです。ネットワークデバイス上のネットワークトラフィックのフローをリモートで制御する手段を提供し、ネットワーク管理者がネットワークトラフィックのフローを設定、管理、および監視できるようにします。
OVN-Kubernetes は、OpenFlow では利用できない高度な機能をさらに提供します。OVN は、分散仮想ルーティング、分散論理スイッチ、アクセス制御、Dynamic Host Configuration Protocol (DHCP)、および DNS をサポートしています。OVN は、オープンフローと同等のロジックフロー内に分散仮想ルーターを実装します。たとえば、ネットワーク上の DHCP サーバーに DHCP 要求を送信する Pod がある場合、要求内のロジックフロールールによって OVN-Kubernetes がパケットを処理することにより、サーバーがゲートウェイ、DNS サーバー、IP アドレスなどの情報で応答できるようになります。
OVN-Kubernetes は、各ノードでデーモンを実行します。すべてのノードで実行されるデータベースおよび OVN コントローラー用のデーモンセットがあります。OVN コントローラーは、ネットワークプロバイダーの機能 (Egress IP、ファイアウォール、ルーター、ハイブリッドネットワーク、IPSEC 暗号化、IPv6、ネットワークポリシー、ネットワークポリシーログ、ハードウェアオフロード、およびマルチキャスト) をサポートするために、ノード上で Open vSwitch デーモンをプログラムします。
19.1.1. OVN-Kubernetes の目的 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインは、Open Virtual Network (OVN) を使用してネットワークトラフィックフローを管理する、オープンソースのフル機能の Kubernetes CNI プラグインです。OVN はコミュニティーで開発され、ベンダーに依存しないネットワーク仮想化ソリューションです。OVN-Kubernetes ネットワークプラグイン:
- Open Virtual Network (OVN) を使用してネットワークトラフィックフローを管理します。OVN はコミュニティーで開発され、ベンダーに依存しないネットワーク仮想化ソリューションです。
- Ingress および Egress ルールを含む Kubernetes ネットワークポリシーのサポートを実装します。
- ノード間にオーバーレイネットワークを作成するには、VXLAN ではなく GENEVE (Generic Network Virtualization Encapsulation) プロトコルを使用します。
OVN-Kubernetes ネットワークプラグインは、OpenShift SDN よりも次の利点があります。
- サポートされているプラットフォームでの IPv6 シングルスタックおよび IPv4/IPv6 デュアルスタックネットワークの完全サポート
- Linux と Microsoft Windows の両方のワークロードによるハイブリッドクラスターのサポート
- クラスター内通信のオプションの IPsec 暗号化
- ホスト CPU から互換性のあるネットワークカードおよびデータ処理ユニット (DPU) へのネットワークデータ処理のオフロード
19.1.2. サポートされているネットワークプラグイン機能のマトリックス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Networking は、ネットワークプラグイン用に OpenShift SDN と OVN-Kubernetes の 2 つのオプションを提供します。以下の表は、両方のネットワークプラグインの現在の機能サポートをまとめたものです。
| 機能 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| Egress IP | サポート対象 | サポート対象 |
| Egress ファイアウォール | サポート対象 | サポート対象 [1] |
| Egress ルーター | サポート対象 | サポート対象 [2] |
| ハイブリッドネットワーク | サポート対象外 | サポート対象 |
| クラスター内通信の IPsec 暗号化 | サポート対象外 | サポート対象 |
| IPv4 シングルスタック | サポート対象 | サポート対象 |
| IPv6 シングルスタック | サポート対象外 | サポート対象 [3] |
| IPv4/IPv6 デュアルスタック | サポート対象外 | サポート対象 [4] |
| IPv6/IPv4 デュアルスタック | サポート対象外 | サポート対象 [5] |
| Kubernetes ネットワークポリシー | サポート対象 | サポート対象 |
| Kubernetes ネットワークポリシーログ | サポート対象外 | サポート対象 |
| ハードウェアのオフロード | サポート対象外 | サポート対象 |
| マルチキャスト | サポート対象 | サポート対象 |
- Egress ファイアウォールは、OpenShift SDN では Egress ネットワークポリシーとしても知られています。これはネットワークポリシーの Egress とは異なります。
- OVN-Kubernetes の Egress ルーターはリダイレクトモードのみをサポートします。
- ベアメタルプラットフォーム上の IPv6 シングルスタックネットワーキング。
- ベアメタル、VMware vSphere (installer-provisioned infrastructure インストールのみ)、IBM Power®、IBM Z®、および RHOSP プラットフォーム上の IPv4/IPv6 または IPv6/IPv4 デュアルスタックネットワーク。
- ベアメタル、VMware vSphere (インストーラープロビジョニングインフラストラクチャーのインストールのみ)、および IBM Power® プラットフォーム上の IPv6/IPv4 デュアルスタックネットワーク。
19.1.3. OVN-Kubernetes IPv6 とデュアルスタックの制限 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインには、次の制限があります。
デュアルスタックネットワークに設定されたクラスターでは、IPv4 と IPv6 の両方のトラフィックがデフォルトゲートウェイとして同じネットワークインターフェイスを使用する必要があります。この要件が満たされない場合には、
ovnkube-nodeデーモンセットのホストにある Pod は、CrashLoopBackOff状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yamlのようなコマンドで Pod を表示すると、以下の出力のように、statusフィールドにデフォルトゲートウェイに関する複数のメッセージが表示されます。I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一の解決策は、両方の IP ファミリーがデフォルトゲートウェイに同じネットワークインターフェイスを使用するように、ホストネットワークを再設定することです。
デュアルスタックネットワーク用に設定されたクラスターの場合、IPv4 と IPv6 の両方のルーティングテーブルにデフォルトゲートウェイが含まれている必要があります。この要件が満たされない場合には、
ovnkube-nodeデーモンセットのホストにある Pod は、CrashLoopBackOff状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yamlのようなコマンドで Pod を表示すると、以下の出力のように、statusフィールドにデフォルトゲートウェイに関する複数のメッセージが表示されます。I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interfaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 唯一の解決策として、両方の IP ファミリーにデフォルトゲートウェイが含まれるようにホストネットワークを再設定できます。
19.1.4. セッションアフィニティー リンクのコピーリンクがクリップボードにコピーされました!
セッションアフィニティーは、Kubernetes Service オブジェクトに適用される機能です。<service_VIP>:<Port> に接続するたびに、トラフィックが常に同じバックエンドに負荷分散されるようにする場合は、セッションアフィニティー を使用できます。クライアントの IP アドレスに基づいてセッションアフィニティーを設定する方法など、詳細は、セッションアフィニティー を参照してください。
セッションアフィニティーのスティッキタイムアウト
OpenShift Container Platform の OVN-Kubernetes ネットワークプラグインは、最後のパケットに基づいて、クライアントからのセッションのスティッキタイムアウトを計算します。たとえば、curl コマンドを 10 回実行すると、スティッキーセッションタイマーは最初のパケットではなく 10 番目のパケットから開始します。その結果、クライアントが継続的にサービスに接続している場合でも、セッションがタイムアウトすることはありません。タイムアウトは、timeoutSeconds パラメーターで設定された時間、サービスがパケットを受信しなかった場合に開始されます。
19.2. OVN-Kubernetes のアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
19.2.1. OVN-Kubernetes のアーキテクチャーの紹介 リンクのコピーリンクがクリップボードにコピーされました!
次の図は、OVN-Kubernetes のアーキテクチャーを示しています。
図19.1 OVK-Kubernetes のアーキテクチャー
主なコンポーネントは次のとおりです。
- Cloud Management System (CMS) - OVN 統合用の CMS 固有のプラグインを提供する OVN 用のプラットフォーム固有のクライアント。このプラグインは、CMS 固有の形式で CMS 設定データベースに格納されているクラウド管理システムの論理ネットワーク設定の概念を、OVN が理解できる中間表現に変換します。
-
OVN ノースバウンドデータベース (
nbdb) コンテナー - CMS プラグインによって渡された論理ネットワーク設定を格納します。 -
OVN サウスバウンドデータベース (
sbdb) コンテナー - 各ノードの Open vSwitch (OVS) システムの物理および論理ネットワーク設定状態を、それらをバインドするテーブルを含めて格納します。 -
OVN North デーモン (
ovn-northd) - これは、nbdbコンテナーとsbdbコンテナーの間の仲介クライアントです。これは、論理ネットワーク設定を、nbdbコンテナーから取得した従来のネットワーク概念の観点から、その下のsbdbコンテナーの論理データパスフローに変換します。ovn-northdデーモンのコンテナー名はNorthdで、ovnkube-nodePod 内で実行されます。 -
ovn-controller -
sbdbコンテナーに必要な情報または更新のために、OVS およびハイパーバイザーと対話する OVN エージェントです。ovn-controllerはsbdbコンテナーから論理フローを読み取り、それらをOpenFlowフローに変換して、ノードの OVS デーモンに送信します。コンテナー名はovn-controllerで、ovnkube-nodePod で実行されます。
OVN Northd、ノースバウンドデータベース、およびサウスバウンドデータベースはクラスター内の各ノードで実行され、主にそのノードにローカルな情報を格納して処理します。
OVN ノースバウンドデータベースには、クラウド管理システム (CMS) によって渡された論理ネットワーク設定があります。OVN ノースバウンドデータベースには、ネットワークの現在の望ましい状態が含まれており、論理ポート、論理スイッチ、論理ルーターなどのコレクションとして提示されます。ovn-northd (northd コンテナー) は、OVN ノースバウンドデータベースと OVN サウスバウンドデータベースに接続します。これは、論理ネットワーク設定を、OVN ノースバウンドデータベースから取得した従来のネットワーク概念の観点から、OVN サウスバウンドデータベースの論理データパスフローに変換します。
OVN サウスバウンドデータベースには、ネットワークの物理的および論理的表現と、それらをリンクするバインディングテーブルがあります。これには、ノードのシャーシ情報と、クラスター内の他のノードに接続するために必要なリモート中継スイッチポートなどの他の設定要素が含まれます。OVN サウスバウンドデータベースには、すべてのロジックフローも含まれています。このロジックフローは、各ノードで実行される ovn-controller プロセスと共有され、ovn-controller はそれらを Open vSwitch (OVS) をプログラムする OpenFlow ルールに変換します。
Kubernetes コントロールプレーンノードでは、別々のノードに 2 つの ovnkube-control-plane Pod が含まれています。これらの Pod は、クラスター内の各ノードに一元的な IP アドレス管理 (IPAM) 割り当てを実行します。どの時点でも、1 つの ovnkube-control-plane Pod がリーダーです。
19.2.2. OVN-Kubernetes プロジェクト内のすべてのリソースの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes プロジェクトで実行されるリソースとコンテナーを見つけることは、OVN-Kubernetes ネットワークの実装を理解するのに役立ちます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、OVN-Kubernetes プロジェクト内のすべてのリソース、エンドポイント、および
ConfigMapを取得します。oc get all,ep,cm -n openshift-ovn-kubernetes
$ oc get all,ep,cm -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内の各ノードには、1 つの
ovnkube-nodePod があります。ovnkube-configconfig map には、OpenShift Container Platform OVN-Kubernetes 設定が含まれています。次のコマンドを実行して、
ovnkube-nodePod 内のすべてのコンテナーを一覧表示します。oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes$ oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-nodePod は、複数のコンテナーで構成されています。これは、ノースバウンドデータベース (nbdbコンテナー)、サウスバウンドデータベース (sbdbコンテナー)、ノースデーモン (northdコンテナー)、ovn-controllerおよびovnkube-controllerコンテナーをホストします。ovnkube-controllerコンテナーは、Pod、Egress IP、namespace、サービス、エンドポイント、Egress ファイアウォール、ネットワークポリシーなどの API オブジェクトを監視します。また、そのノードの利用可能なサブネットプールから Pod IP への割り当ても行います。次のコマンドを実行して、
ovnkube-control-planePod 内のすべてのコンテナーをリスト表示します。oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes$ oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
kube-rbac-proxy ovnkube-cluster-manager
kube-rbac-proxy ovnkube-cluster-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-control-planePod には、各 OpenShift Container Platform ノードに常駐するコンテナー (ovnkube-cluster-manager) があります。ovnkube-cluster-managerコンテナーは、Pod サブネット、トランジットスイッチサブネット IP、およびジョインスイッチサブネット IP をクラスター内の各ノードに割り当てます。kube-rbac-proxyコンテナーはovnkube-cluster-managerコンテナーのメトリックを監視します。
19.2.3. OVN-Kubernetes ノースバウンドデータベースの内容の一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
各ノードは、そのノード上の ovnkube-node Pod で実行されている ovnkube-controller コンテナーによって制御されます。OVN 論理ネットワークエンティティーを理解するには、そのノード上の ovnkube-node Pod 内でコンテナーとして実行されているノースバウンドデータベースを調べて、表示するノード内にどのようなオブジェクトがあるかを確認する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
クラスター内で ovn nbctl または sbctl コマンドを実行するには、関連するノード上の nbdb または sbdb コンテナーにリモートシェルを開く必要があります。
次のコマンドを実行して Pod をリスト表示します。
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Pod とノード情報をリストするには、次のコマンドを実行します。
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ノースバウンドデータベース内のすべてのオブジェクトを表示します。
ovn-nbctl show
$ ovn-nbctl showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は長すぎてここにリストできません。リストには、NAT ルール、論理スイッチ、ロードバランサーなどが含まれます。
次の任意のコマンドのいくつかを使用すると、特定のコンポーネントに絞り込むことができます。
次のコマンドを実行して、論理ルーターのリストを表示します。
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この出力から、各ノードにルーターと
ovn_cluster_routerがあることがわかります。次のコマンドを実行して、論理スイッチのリストを表示します。
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この出力から、各ノードの ext スイッチに加えて、ノード名自体を持つスイッチと結合スイッチがあることがわかります。
次のコマンドを実行して、ロードバランサーのリストを表示します。
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この出力 (一部省略あり) から、多くの OVN-Kubernetes ロードバランサーがあることがわかります。OVN-Kubernetes のロードバランサーはサービスの表現です。
次のコマンドを実行して、コマンド
ovn-nbctlで使用可能なオプションを表示します。oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.4. ノースバウンドデータベースの内容を調べるための ovn-nbctl のコマンドライン引数 リンクのコピーリンクがクリップボードにコピーされました!
次の表に、ノースバウンドデータベースの内容を調べるために ovn-nbctl で使用できるコマンドライン引数を示します。
内容を表示する Pod でリモートシェルを開き、ovn-nbctl コマンドを実行します。
| 引数 | 説明 |
|---|---|
|
| 特定のノードから見たノースバウンドデータベースの内容の概要。 |
|
| 指定されたスイッチまたはルーターに関連付けられた詳細を表示します。 |
|
| 論理ルーターを表示します。 |
|
|
|
|
| 指定されたルーターのネットワークアドレス変換の詳細を表示します。 |
|
| 論理スイッチを表示します。 |
|
|
|
|
| 論理ポートのタイプを取得します。 |
|
| ロードバランサーを表示します。 |
19.2.5. OVN-Kubernetes サウスバウンドデータベースの内容の一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
各ノードは、そのノード上の ovnkube-node Pod で実行されている ovnkube-controller コンテナーによって制御されます。OVN 論理ネットワークエンティティーを理解するには、そのノード上の ovnkube-node Pod 内でコンテナーとして実行されているノースバウンドデータベースを調べて、表示するノード内にどのようなオブジェクトがあるかを確認する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
クラスター内で ovn nbctl または sbctl コマンドを実行するには、関連するノード上の nbdb または sbdb コンテナーにリモートシェルを開く必要があります。
次のコマンドを実行して、Pod を一覧表示します。
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Pod とノード情報をリストするには、次のコマンドを実行します。
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod に移動してサウスバウンドデータベースを確認します。
oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サウスバウンドデータベース内のすべてのオブジェクトを表示します。
ovn-sbctl show
$ ovn-sbctl showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この詳細な出力は、シャーシとシャーシに接続されているポート (この場合、すべてのルーターポートとホストネットワークのように動作するもの) を示しています。すべての Pod は、ソースネットワークアドレス変換 (SNAT) を使用して、より広いネットワークと通信します。Pod の IP アドレスは、Pod が実行されているノードの IP アドレスに変換され、ネットワークに送信されます。
シャーシ情報に加えて、サウスバウンドデータベースにはすべてのロジックフローがあります。これらのロジックフローは各ノードで実行されている
ovn-controllerに送信されます。ovn-controllerは、ロジックフローをオープンフロールールに変換し、最終的にOpenvSwitchをプログラムして、Pod がオープンフロールールに従ってネットワークの外に出られるようにします。次のコマンドを実行して、コマンド
ovn-sbctlで使用可能なオプションを表示します。oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.6. サウスバウンドデータベースの内容を調べるための ovn-sbctl のコマンドライン引数 リンクのコピーリンクがクリップボードにコピーされました!
次の表に、サウスバウンドデータベースの内容を調べるために ovn-sbctl で使用できるコマンドライン引数を示します。
内容を表示する Pod でリモートシェルを開き、ovn-sbctl コマンドを実行します。
| 引数 | 説明 |
|---|---|
|
| 特定のノードから見たサウスバウンドデータベースの内容の概要。 |
|
| 指定されたポートのサウスバウンドデータベースの内容を一覧表示します。 |
|
| 論理フローを一覧表示します。 |
19.2.7. OVN-Kubernetes の論理アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
OVN はネットワーク仮想化ソリューションです。OVN は論理スイッチとルーターを作成します。これらのスイッチとルーターは相互接続され、任意のネットワークトポロジーを作成します。ログレベルを 2 または 5 に設定して ovnkube-trace を実行すると、OVN-Kubernetes 論理コンポーネントが公開されます。以下の図は、ルーターとスイッチが OpenShift Container Platform でどのように接続されているかを示しています。
図19.2 OVN-Kubernetes のルーターおよびスイッチコンポーネント
パケット処理に関係する主要なコンポーネントは次のとおりです。
- ゲートウェイルーター
-
L3 ゲートウェイルーターとも呼ばれるゲートウェイルーターは、通常、分散ルーターと物理ネットワークの間で使用されます。論理パッチポートを含むゲートウェイルーターは、(分散されていない) 物理的な場所またはシャーシにバインドされます。このルーターのパッチポートは、ovn-southbound データベース (
ovn-sbdb) では l3gateway ポートと呼ばれます。 - 分散論理ルーター
- 分散論理ルーターと、仮想マシンとコンテナーが接続されるその背後にある論理スイッチは、事実上、各ハイパーバイザーに常駐します。
- 結合ローカルスイッチ
- 結合ローカルスイッチは、分散ルーターとゲートウェイルーターを接続するために使用されます。これにより、分散ルーターで必要な IP アドレスの数が減ります。
- パッチポートを備えた論理スイッチ
- パッチポートを備えた論理スイッチは、ネットワークスタックを仮想化するために使用されます。これらは、トンネルを介してリモート論理ポートを接続します。
- localnet ポートを備えた論理スイッチ
- localnet ポートを備えた論理スイッチは、OVN を物理ネットワークに接続するために使用されます。これらは、localnet ポートを使用して直接接続された物理 L2 セグメントにパケットをブリッジすることにより、リモート論理ポートを接続します。
- パッチポート
- パッチポートは、論理スイッチと論理ルーターの間、およびピア論理ルーター間の接続を表します。1 つの接続には、このような接続ポイントごとに、両側に 1 つずつ、1 組のパッチポートがあります。
- l3gateway ポート
-
l3gateway ポートは、ゲートウェイルーターで使用される論理パッチポートの
ovn-sbdb内のポートバインディングエントリーです。これらのポートは、ゲートウェイルーター本体と同様にシャーシにバインドされているという事実を表すために、パッチポートではなく l3gateway ポートと呼ばれます。 - localnet ポート
-
localnet ポートは、各
ovn-controllerインスタンスからローカルにアクセス可能なネットワークへの接続を可能にするブリッジ論理スイッチに存在します。これは、論理スイッチから物理ネットワークへの直接接続をモデル化するのに役立ちます。論理スイッチに接続できる localnet ポートは 1 つだけです。
19.2.7.1. ローカルホストへの network-tools のインストール リンクのコピーリンクがクリップボードにコピーされました!
ローカルホストに network-tools をインストールして、OpenShift Container Platform クラスターネットワークの問題をデバッグするための一連のツールを使用できるようにします。
手順
次のコマンドを使用して、
network-toolsリポジトリーのクローンをワークステーションに作成します。git clone git@github.com:openshift/network-tools.git
$ git clone git@github.com:openshift/network-tools.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow クローン作成したリポジトリーのディレクトリーに移動します。
cd network-tools
$ cd network-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 使用可能なすべてのコマンドをリストします。
./debug-scripts/network-tools -h
$ ./debug-scripts/network-tools -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.7.2. network-tools の実行 リンクのコピーリンクがクリップボードにコピーされました!
network-tools を実行して、論理スイッチとルーターに関する情報を取得します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
ローカルホストに
network-toolsがインストールされている。
手順
次のコマンドを実行して、ルーターを一覧表示します。
./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
$ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、localnet ポートを一覧表示します。
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnet
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnetCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
l3gatewayポートを一覧表示します。./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gateway
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gatewayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、パッチポートを一覧表示します。
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patch
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3. OVN-Kubernetes のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes には、組み込みのヘルスチェックとログのソースが多数あります。以下のセクションの手順に従ってクラスターを調査してください。サポートケースが必要な場合は、サポートガイド に従って、must-gather を使用して追加情報を収集してください。-- gather_network_logs は、サポートから指示された場合にのみ使用してください。
19.3.1. readiness プローブを使用した OVN-Kubernetes の正常性の監視 リンクのコピーリンクがクリップボードにコピーされました!
ovnkube-control-plane および ovnkube-node Pod には、readiness プローブが設定されたコンテナーがあります。
前提条件
-
OpenShift CLI (
oc) へのアクセスがある。 -
cluster-admin権限でクラスターにアクセスできる。 -
jqがインストールされている。
手順
次のコマンドを実行して、
ovnkube-nodereadiness プローブの詳細を確認します。oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
$ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-nodePod 内のノースバウンドおよびサウスバウンドのデータベースコンテナーの Readiness プローブは、データベースとovnkube-controllerコンテナーの正常性をチェックします。ovnkube-nodePod のovnkube-controllerコンテナーには、OVN-Kubernetes CNI 設定ファイルの存在を確認するための readiness プローブがあります。この設定ファイルがない場合、Pod が実行中でないか、Pod を設定するリクエストを受け入れる準備ができていません。次のコマンドを使用して、プローブの失敗を含む namespace のすべてのイベントを表示します。
oc get events -n openshift-ovn-kubernetes
$ oc get events -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の Pod のみのイベントを表示します。
oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes
$ oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターネットワーク Operator からのメッセージとステータスを表示します。
oc get co/network -o json | jq '.status.conditions[]'
$ oc get co/network -o json | jq '.status.conditions[]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のスクリプトを実行して、
ovnkube-nodePod 内の各コンテナーのreadyステータスを表示します。for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ done$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記すべてのコンテナーのステータスが
trueとして報告されることが期待されます。readiness プローブが失敗すると、ステータスがfalseに設定されます。
19.3.2. コンソールでの OVN-Kubernetes アラートの表示 リンクのコピーリンクがクリップボードにコピーされました!
アラート UI は、アラートおよびそれらを規定するアラートルールおよびサイレンスに関する詳細情報を提供します。
前提条件
- 開発者として、またはメトリクスで表示しているプロジェクトの表示権限を持つユーザーとしてクラスターへのアクセスがある。
手順 (UI)
- Administrator パースペクティブで、Observe → Alerting を選択します。このパースペクティブのアラート UI の主なページには、Alerts、Silences、および Alerting Rules という 3 つのページがあります。
- Observe → Alerting → Alerting Rules を選択して、OVN-Kubernetes アラートのルールを表示します。
19.3.3. CLI での OVN-Kubernetes アラートの表示 リンクのコピーリンクがクリップボードにコピーされました!
コマンドラインから、アラートとその管理アラートルールおよびサイレンスに関する情報を取得できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。 -
jqがインストールされている。
手順
次のコマンドを実行して、アクティブまたは発生中のアラートを表示します。
次のコマンドを実行して、アラートマネージャーのルート環境変数を設定します。
ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')$ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してアラートマネージャールート API に
curlリクエストを実行します。$ALERT_MANAGERは、Alertmanagerインスタンスの URL に置き換えます。curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'
$ curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、アラートルールを表示します。
oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.4. CLI を使用した OVN-Kubernetes ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して、ovnkube-master および ovnkube-node Pod 内の各 Pod のログを表示できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) へのアクセスがある。 -
jqがインストールされている。
手順
特定の Pod のログを表示します。
oc logs -f <pod_name> -c <container_name> -n <namespace>
$ oc logs -f <pod_name> -c <container_name> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-f- オプション: ログに書き込まれている内容に沿って出力することを指定します。
<pod_name>- Pod の名前を指定します。
<container_name>- オプション: コンテナーの名前を指定します。Pod に複数のコンテナーがある場合、コンテナー名を指定する必要があります。
<namespace>- Pod が実行されている namespace を指定します。
以下に例を示します。
oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes
$ oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes
$ oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ログファイルの内容が出力されます。
ovnkube-nodePod 内のすべてのコンテナーの最新のエントリーを調べます。for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、
ovnkube-nodePod 内のすべてのコンテナーのすべてのログの最後の 5 行を表示します。oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5
$ oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.5. Web コンソールを使用した OVN-Kubernetes ログの表示 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールで、ovnkube-master Pod と ovnkube-node Pod の各 Pod のログを表示できます。
前提条件
-
OpenShift CLI (
oc) へのアクセスがある。
手順
- OpenShift Container Platform コンソールで Workloads → Pods に移動するか、調査するリソースから Pod に移動します。
-
ドロップダウンメニューから
openshift-ovn-kubernetesプロジェクトを選択します。 - 調査する Pod の名前をクリックします。
-
Logs をクリックします。
ovnkube-masterのデフォルトでは、northdコンテナーに関連付けられたログが表示されます。 - ドロップダウンメニューを使用して、各コンテナーのログを順番に選択します。
19.3.5.1. OVN-Kubernetes のログレベルの変更 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes のデフォルトのログレベルは 4 です。OVN-Kubernetes をデバッグするには、ログレベルを 5 に設定します。次の手順に従って OVN-Kubernetes のログレベルを上げることで、問題のデバッグに役立てることができます。
前提条件
-
cluster-admin権限でクラスターにアクセスできる。 - OpenShift Container Platform Web コンソールにアクセスできる。
手順
次のコマンドを実行して、OVN-Kubernetes プロジェクト内のすべての Pod の詳細情報を取得します。
oc get po -o wide -n openshift-ovn-kubernetes
$ oc get po -o wide -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような
ConfigMapファイルを作成し、env-overrides.yamlなどのファイル名を使用します。ConfigMapファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、
ConfigMapファイルを適用します。oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
$ oc apply -n openshift-ovn-kubernetes -f env-overrides.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
configmap/env-overrides.yaml created
configmap/env-overrides.yaml createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して
ovnkubePod を再起動し、新しいログレベルを適用します。oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ConfigMap ファイルが特定の Pod のすべてのノードに適用されていることを確認するには、次のコマンドを実行します。
oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'
$ oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<XXXX>前の手順の Pod の文字のランダムなシーケンスを指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション: 次のコマンドを実行して、
ConfigMapファイルが適用されていることを確認します。for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; done
for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.6. OVN-Kubernetes Pod ネットワーク接続のチェック リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.10 以降の接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。これには、Kubernetes API、OpenShift API、および個々のノードが含まれます。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。
前提条件
-
OpenShift CLI (
oc) へのアクセスがある。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
jqがインストールされている。
手順
現在の
PodNetworkConnectivityCheckオブジェクトをリスト表示するには、以下のコマンドを入力します。oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnosticsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、各接続オブジェクトの最新の成功を表示します。
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、各接続オブジェクトの最新のエラーを表示します。
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、各接続オブジェクトの最新の停止を表示します。
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 接続チェックコントローラーは、これらのチェックからのメトリクスも Prometheus に記録します。
次のコマンドを実行して、すべてのメトリクスを表示します。
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 過去 5 分間のソース Pod と openshift api サービス間のレイテンシーを表示します。
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.4. ovnkube-trace を使用した Openflow のトレース リンクのコピーリンクがクリップボードにコピーされました!
OVN と OVS のトラフィックフローは、ovnkube-trace という単一のユーティリティーでシミュレートできます。ovnkube-trace ユーティリティーは、ovn-trace、ovs-appctl ofproto/trace、および ovn-detrace を実行し、その情報を 1 つの出力に関連付けます。
専用コンテナーから ovnkube-trace バイナリーを実行できます。OpenShift Container Platform 4.7 以降のリリースでは、バイナリーをローカルホストにコピーして、そのホストから実行することもできます。
19.4.1. ローカルホストへの ovnkube-trace のインストール リンクのコピーリンクがクリップボードにコピーされました!
ovnkube-trace ツールは、OVN-Kubernetes で動作する OpenShift Container Platform クラスター内のポイント間における任意の UDP または TCP トラフィックのパケットシミュレーションをトレースします。ovnkube-trace バイナリーをローカルホストにコピーして、クラスターに対して実行できるようにします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
次のコマンドを使用して Pod 変数を作成します。
POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')$ POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルホストで次のコマンドを実行して、
ovnkube-control-planePod からバイナリーをコピーします。oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace
$ oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-traceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat Enterprise Linux (RHEL) 8 を使用して
ovnkube-traceツールを実行している場合は、/usr/lib/rhel8/ovnkube-traceファイルをローカルホストにコピーする必要があります。次のコマンドを実行して、
ovnkube-traceを実行可能にします。chmod +x ovnkube-trace
$ chmod +x ovnkube-traceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ovnkube-traceで使用可能なオプションを表示します。./ovnkube-trace -help
$ ./ovnkube-trace -helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サポートされているコマンドライン引数は、namespace、Pod、サービスなど、よく知られた Kubernetes コンストラクトであるため、MAC アドレス、宛先ノードの IP アドレス、または ICMP タイプを見つける必要はありません。
ログレベルは次のとおりです。
- 0 (最小出力)
- 2 (トレースコマンドの結果を示すより詳細な出力)
- 5 (デバッグ出力)
19.4.2. ovnkube-trace の実行 リンクのコピーリンクがクリップボードにコピーされました!
ovn-trace を実行して、OVN 論理ネットワーク内のパケット転送をシミュレートします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
ローカルホストに
ovnkube-traceがインストールされている。
例: デプロイされた Pod からの DNS 解決が機能することをテストする
この例は、デプロイされた Pod からクラスターで実行されるコア DNS Pod への DNS 解決をテストする方法を示しています。
手順
次のコマンドを入力して、default namespace で Web サービスを開始します。
oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-dnsnamespace で実行されている Pod を一覧表示します。oc get pods -n openshift-dns
oc get pods -n openshift-dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の
ovnkube-traceコマンドを実行して、DNS 解決が機能していることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dstPod が同じノードに配置された場合の出力例Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dstPod が別のノードに配置された場合の出力例Copy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、デプロイされた Pod から DNS ポートへの解決が成功し、その反対方向への解決も成功したことを示しています。つまり、Web Pod がコア DNS からの DNS 解決を行う場合に、UDP ポート 53 で双方向のトラフィックがサポートされていることがわかります。
たとえば、これが機能せず、ovn-trace を取得する必要がある場合は、proto/trace と ovn-detrace の ovs-appctl、およびデバッグのタイプ情報が、ログレベルを 2 に上げて、以下のようにコマンドを再度実行します。
このログレベルの出力は多すぎるため、ここにはリストできません。障害状況では、このコマンドの出力は、どのフローがそのトラフィックを破棄しているかを示します。たとえば、Egress または Ingress ネットワークポリシーが、そのトラフィックを許可しないクラスターで設定されている場合などがあります。
例: デバッグ出力を使用して設定済みのデフォルトの拒否を確認する
この例は、デバッグ出力を使用して、デフォルトの Ingress 拒否ポリシーがトラフィックをブロックしていることを特定する方法を示しています。
手順
すべての namespace におけるすべての Pod からの Ingress を拒否する
deny-by-defaultポリシーを定義する次の YAML を作成します。YAML をdeny-by-default.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
defaultnamespace で Web サービスを開始します。oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace を作成します。oc create namespace prod
$ oc create namespace prodCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
prodnamespace にラベルを付けます。oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=productionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
alpineイメージをprodnamespace にデプロイし、シェルを開始します。oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- shCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 別のターミナルセッションを開きます。
この新しいターミナルセッションで
ovn-traceを実行して、namespaceprodで実行されているソース Podtest-6459とdefaultnamespace で実行されている宛先 Pod 間の通信の失敗を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ovn-trace source pod to destination pod indicates failure from test-6459 to web
ovn-trace source pod to destination pod indicates failure from test-6459 to webCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ログレベルを 2 に上げて、失敗の理由を明らかにします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- デフォルトの拒否ポリシーが設定されているため、Ingress トラフィックがブロックされています。
ラベルが
purpose=productionの特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML をweb-allow-prod.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
ovnkube-traceを実行し、トラフィックが許可されていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 手順 6 で開いたシェルで次のコマンドを実行して、nginx を Web サーバーに接続します。
wget -qO- --timeout=2 http://web.default
wget -qO- --timeout=2 http://web.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5. OpenShift SDN ネットワークプラグインからの移行 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift ソフトウェア定義ネットワーク(SDN)プラグインから OVN-Kubernetes ネットワークプラグインに移行できます。
クラスターで OpenShift SDN ネットワークプラグインを使用している場合、クラスターを OpenShift Container Platform 4.17 にアップグレードすることはできません。最初にクラスターを OVN-Kubernetes プラグインに移行してから、クラスターを OpenShift Container Platform 4.17 にアップグレードする必要があります。
さらに、クラスターがサードパーティーのコンテナーネットワークインターフェイス(CNI)プラグインを使用している場合、クラスターを OVN-Kubernetes ネットワークプラグインに移行することはできません。これらの CNI プラグインの完全なリストは、認定 OpenShift CNI プラグ イン(Red Hat ナレッジベース)を参照してください。
OpenShift SDN ネットワークプラグインから OVN-Kubernetes プラグインに移行するための以下の方法があります。
- Ansible Playbook
- Ansible Playbook メソッドは、オフライン移行方法の手順を自動化します。この方法では、手動のオフライン移行方法と同じシナリオを使用します。
- オフラインマイグレーション
- これは、ダウンタイムを含む手動プロセスです。この方法は主に自己管理の OpenShift Container Platform デプロイメントに使用されます。また、OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションを実行できない場合は、この方法の使用を検討してください。
- Limited live migration (Preferred method)
- これは、クラスターを OpenShift SDN から OVN-Kubernetes に移行する自動プロセスです。
ライブマイグレーション方法のみの場合は、スクリプトまたは Red Hat Ansible Automation Platform などの別のツールを使用して、OpenShift SDN から OVN-Kubernetes への移行を自動化しないでください。これにより、OpenShift Container Platform クラスターが停止したりクラッシュしたりする可能性があります。
19.5.1. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションの概要 リンクのコピーリンクがクリップボードにコピーされました!
限定的なライブマイグレーション方式は、OpenShift SDN ネットワークプラグインとそのネットワーク設定、接続、および関連リソースを、サービスを中断することなく OVN-Kubernetes ネットワークプラグインに移行するプロセスです。これは OpenShift Container Platform で利用可能であり、OpenShift SDN から OVN-Kubernetes への移行で推奨される方法です。限られたライブマイグレーションを実行できない場合は、オフライン移行方法を使用できます。
OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。
Hosted Control Plane デプロイメントタイプでは使用できません。この移行方式は、継続的なサービス可用性を必要とするデプロイメントタイプにとって有用で、以下のような利点があります。
- 継続的なサービスの可用性
- ダウンタイムの最小化
- 自動ノード再起動
- OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへのシームレスな移行
ロールバック手順は提供されていますが、限定的なライブマイグレーションは一方向のプロセスとなる想定です。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
次のセクションでは、限定的なライブマイグレーションの方法についてさらに詳しく説明します。
19.5.1.1. 限定的なライブマイグレーション方式を使用する場合にサポートされるプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
次の表は、制限付きライブマイグレーションタイプでサポートされているプラットフォームに関する情報を示しています。
| プラットフォーム | 限定的なライブマイグレーション |
|---|---|
| ベアメタルハードウェア | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud Platform (GCP) | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| Red Hat OpenStack Platform (RHOSP) | ✓ |
| VMware vSphere | ✓ |
| Nutanix | ✓ |
リストされている各プラットフォームは、installer-provisioned infrastructure および user-provisioned infrastructure への OpenShift Container Platform クラスターのインストールをサポートしています。
19.5.1.2. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションのベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
限定的なライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Limited Live Migration from OpenShift SDN to OVN-Kubernetes を参照してください。
19.5.1.3. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションメソッドを使用する前に、クラスター管理者は次の情報を考慮する必要があります。
- OpenShift SDN マルチテナントモードが有効になっているクラスターでは、制限付きライブマイグレーション手順はサポートされません。
- Egress ルーター Pod は、制限されたライブマイグレーションプロセスをブロックします。制限付きライブマイグレーションのプロセスを開始する前に、それらを削除する必要があります。
- 移行時に、クラスターが OVN-Kubernetes と OpenShift SDN の両方で実行されている場合、マルチキャストおよび egress IP アドレスは両方の CNI について一時的に無効になります。Egress ファイアウォールは引き続き機能します。
- 移行は一方向のプロセスとして行われます。ただし、OpenShift-SDN にロールバックするユーザーの場合、OpenShift-SDN から OVN-Kubernetes への移行が成功している必要があります。以下の同じ手順に従って、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行できます。
- 制限付きライブマイグレーションは、HyperShift クラスターではサポートされていません。
- OpenShift SDN は IPsec をサポートしません。移行後、クラスター管理者は IPsec を有効にできます。
- OpenShift SDN は IPv6 をサポートしていません。移行後、クラスター管理者はデュアルスタックを有効にできます。
-
OpenShift SDN プラグインを使用すると、
NodeNetworkConfigurationPolicy(NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。 クラスター MTU は、Pod インターフェイスの MTU 値です。クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。オーバーヘッドは、OVN-Kubernetes の場合は 100 バイト、OpenShift SDN の場合は 50 バイトです。
制限付きライブマイグレーション中は、OVN-Kubernetes と OpenShift SDN の両方が並行して実行されます。OVN-Kubernetes は一部のノードのクラスターネットワークを管理し、OpenShift SDN は他のノードのクラスターネットワークを管理します。CNI 間のトラフィックが機能し続けるように、Cluster Network Operator はルーティング可能な MTU を更新し、両方の CNI が同じオーバーレイ MTU を共有するようにします。その結果、移行が完了すると、クラスター MTU は 50 バイト少なくなります。
-
OVN-Kubernetes は、
100.64.0.0/16および100.88.0.0/16の IP アドレス範囲を予約します。これらのサブネットは、他の内部ネットワークまたは外部ネットワークと重複することはできません。これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。 -
PTP を使用する
openshift-sdnクラスターで、ハードウェアタイムスタンプに User Datagram Protocol (UDP) を使用している場合、OVN-Kubernetes プラグインに移行すると、Open vSwitch (OVS) ブリッジなどのプライマリーインターフェイスデバイスにハードウェアタイムスタンプを適用できなくなります。そのため、UDP バージョン 4 の設定は、br-exインターフェイスでは機能しません。 - ほとんどの場合、制限付きライブマイグレーションは、Multus CNI プラグインによって作成された Pod のセカンダリーインターフェイスとは無関係です。ただし、これらのセカンダリーインターフェイスがホストのデフォルトのネットワークインターフェイスコントローラー (NIC) 上に設定されている場合 (たとえば、MACVLAN、IPVLAN、SR-IOV、またはブリッジインターフェイスを使用し、デフォルトの NIC を制御ノードとして使用する場合)、OVN-Kubernetes で誤動作が発生する可能性があります。限られたライブマイグレーションに進む前に、このような設定を削除する必要があります。
- ホスト内に複数の NIC があり、デフォルトルートが Kubernetes NodeIP を持つインターフェイス上にない場合は、代わりにオフライン移行を使用する必要があります。
-
制限付きライブマイグレーションを開始する前に、Cluster Network Operator (CNO) によって管理されていない
openshift-sdnnamespace 内のすべてのDaemonSetオブジェクトを削除する必要があります。これらの管理されていないデーモンセットが適切に処理されない場合は、移行ステータスが不完全なままになる可能性があります。 -
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。
PodDisruptionBudgetでminAvailableが 1 に設定されている場合、保留中のマシン設定を適用するためにノードがドレインされ、エビクションプロセスがブロックされる可能性があります。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudgetフィールドはノードのドレインを防ぐことができます。 OpenShift SDN と同様に、
EgressFirewallリソースなどの OVN-Kubernetes リソースにはClusterAdmin権限が必要です。OpenShift SDN から OVN-Kubernetes への移行では、ロールベースアクセス制御(RBAC)リソースは自動的に更新されません。aggregate-to-adminClusterRoleを使用してプロジェクト管理者に付与される OpenShift SDN リソースは、移行プロセスに含まれないため、手動で確認し、調整する必要があります。移行後に RBAC リソースを手動で検証する必要があります。移行後に
aggregate-to-adminClusterRole を設定する方法は、プロジェクト管理者が RHOCP4 の Egressfirewall リソースを管理する方法 の例を参照し てください。-
クラスターがホストネットワーク内の静的ルートまたはルーティングポリシーに依存して Pod が一部の宛先に到達できるようにする場合、ユーザーは移行前に
routingViaHost仕様をtrueに、ipForwardingをGlobalに設定する必要があります。これにより、ホストカーネルへのルーティングの決定がオフロードされます。詳細は、Openshift SDN ネットワークプラグインの移行の前に、OVNKubernetes プラグインへの移行(Red Hat ナレッジベース)に従うための推奨プラクティス および および「限られたライブマイグレーションを開始する前のクラスターリソースの確認」の手順 5 を参照してください。
19.5.1.4. 限定的なライブマイグレーションプロセスの仕組み リンクのコピーリンクがクリップボードにコピーされました!
次の表は、限定的なライブマイグレーションプロセスをまとめたものです。プロセス内のユーザーが開始する手順と、それに対して移行スクリプトが実行するアクションに分かれています。
| ユーザーが開始する手順 | 移行アクティビティー |
|---|---|
|
|
|
19.5.1.5. 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する リンクのコピーリンクがクリップボードにコピーされました!
制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行するには、複数のステップから成るプロセスが必要であり、ユーザーは Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace の動作を確認する必要があります。管理者は、限定的なライブマイグレーションプロセスを開始する前に、デプロイメント内のネットワークポリシーを確認し、Egress ルーターリソースを削除する必要があります。以下の手順を連続して実行する必要があります。
19.5.1.5.1. 限定的なライブマイグレーションを開始する前にクラスターリソースを確認する リンクのコピーリンクがクリップボードにコピーされました!
制限付きライブマイグレーションを使用して OVN-Kubernetes に移行する前に、OpenShift SDN デプロイメントで Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認する必要があります。また、デプロイメント内のネットワークポリシーも確認する必要があります。移行前にクラスターにこれらのリソースがあることがわかった場合は、移行後にそれらの動作をチェックして、意図したとおりに動作していることを確認する必要があります。
次の手順では、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、ネットワークポリシー、および NNCP を確認する方法を示します。これらのリソースを確認した後は、何もする必要はありません。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、
ocCLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。ocCLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。
oc get egressnetworkpolicies.network.openshift.io -A
$ oc get egressnetworkpolicies.network.openshift.io -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5dCopy to Clipboard Copied! Toggle word wrap Toggle overflow -o yamlフラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yaml
$ oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに
sdn_controller_num_egress_firewallsと入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
クラスターの Egress IP リソースを確認します。これは、
ocCLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。ocCLI ツールを使用して Egress IP を確認するには、以下を行います。Egress IP リソースを持つ namespace をリスト表示するには、次のコマンドを入力します。
oc get netnamespace -A | awk '$3 != ""'
$ oc get netnamespace -A | awk '$3 != ""'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME NETID EGRESS IPS namespace1 14173093 ["10.0.158.173"] namespace2 14173020 ["10.0.158.173"]
NAME NETID EGRESS IPS namespace1 14173093 ["10.0.158.173"] namespace2 14173020 ["10.0.158.173"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに
sdn_controller_num_egress_ipsと入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
クラスターでマルチキャスト対応の namespace を確認します。これは、
ocCLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。ocCLI ツールを使用してマルチキャスト対応の namespace を確認するには、次を行います。マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。
oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'
$ oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
namespace1 namespace3
namespace1 namespace3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Container Platform Web コンソールを使用してマルチキャスト対応の namespace を確認するには、以下を行います。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに
sdn_controller_num_multicast_enabled_namespacesと入力し、Run queries をクリックします。マルチキャスト対応の namespace がある場合は、それらが Expression ボックスに返されます。
クラスターのネットワークポリシーを確認します。これは
ocCLI を使用して実行できます。ocCLI ツールを使用してネットワークポリシーを確認するには、次のコマンドを実行します。oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
NAME POD-SELECTOR AGE allow-multicast app=my-app 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション:クラスターがホストネットワークで静的ルートまたはルーティングポリシーを使用する場合は、
routingViaHost仕様をtrueに設定し、ipForwarding仕様を移行中にgatewayConfigオブジェクトでGlobalに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
ipForwarding仕様がGlobalに、routingViaHost仕様がtrueに設定されていることを確認します。oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.2. 制限付きライブマイグレーションを開始する前に Egress ルーター Pod を削除する リンクのコピーリンクがクリップボードにコピーされました!
制限付きライブマイグレーションを開始する前に、Egress ルーター Pod を確認して削除する必要があります。制限付きライブマイグレーションを実行するときにクラスター上に Egress ルーター Pod がある場合、ネットワーク Operator は移行をブロックし、次のエラーを返します。
The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation. Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation.
Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
クラスター上の Egress ルーター Pod を見つけるには、次のコマンドを入力します。
oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'$ oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{ "name": "egress-multi", "namespace": "egress-router-project" }{ "name": "egress-multi", "namespace": "egress-router-project" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、OpenShift Container Platform Web コンソールでメトリクスをクエリーすることもできます。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに、
network_attachment_definition_instances{networks="egress-router"}と入力します。次に、Add をクリックします。
Egress ルーター Pod を削除するには、次のコマンドを実行します。
oc delete pod <egress_pod_name> -n <egress_router_project>
$ oc delete pod <egress_pod_name> -n <egress_router_project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.3. NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) の削除 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。
プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、Kubernetes-NMState はこの設定を管理できません。代わりに、configure-ovs.sh シェルスクリプトがプライマリーインターフェイスとそれに接続された設定を管理します。
前提条件
- NNCP CR を作成し、ネットワークのプライマリーインターフェイスに適用している。
手順
次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する
NodeNetworkConfigurationPolicy(NNCP) カスタムリソース (CR) を削除します。次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
NAME STATUS REASON bondmaster0 Available SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを
/etc/NetworkManager/system-connectionsシステムパスに保存します。クラスターから NNCP を削除します。
oc delete nncp <nncp_manifest_filename>
$ oc delete nncp <nncp_manifest_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.4. 限定的なライブマイグレーションプロセスの開始 リンクのコピーリンクがクリップボードにコピーされました!
Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応 namespace の動作を確認し、Egress ルーターリソースを削除したら、制限付きライブマイグレーションプロセスを開始できます。
前提条件
- クラスターは、ネットワークポリシー分離モードで OpenShift SDN CNI ネットワークプラグインを使用して設定されています。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップを作成している。
- クラスターは既知の正常な状態にあり、エラーがない。
-
OVN-Kubernetes に移行する前に、すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081上の UDP パケットを許可するセキュリティーグループルールを設定する必要があります。 -
100.64.0.0/16および100.88.0.0/16アドレス範囲が以前 OpenShift-SDN によって使用されていた場合は、パッチが適用されています。手順のステップでは、これらのアドレス範囲が使用されているかどうかを確認します。使用中の場合は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。 - Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認しました。
- 制限付きライブマイグレーションを開始する前に、Egress ルーター Pod をすべて削除しておきます。Egress ルーター Pod の詳細は、「リダイレクトモードでの Egress ルーター Pod のデプロイ」を参照してください。
- このドキュメントの「OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項」セクションを確認している。
手順
クラスターレベルのネットワーク設定にパッチを適用し、OpenShift SDN から OVN-Kubernetes への移行を開始するには、次のコマンドを入力します。
oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'$ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドを実行すると、移行プロセスが開始します。このプロセス中に、Machine Config Operator はクラスター内のノードを 2 回再起動します。移行には、クラスターのアップグレードの約 2 倍の時間がかかります。
重要この
oc patchコマンドは、OpenShift SDN で使用されている重複する CIDR をチェックします。重複する CIDR が検出された場合は、制限付きライブマイグレーションプロセスを開始する前に、CIDR をパッチする必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。オプション: 移行プロセスが完了したことを確認し、
network.configのステータスを確認するには、次のコマンドを実行します。oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'$ oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .$ oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow 問題のトラブルシューティングのために、限定的なライブマイグレーションのメトリクスを確認できます。詳細は、「限定的なライブマイグレーションのメトリクスの確認」を参照してください。
移行操作が正常に完了したら、次のコマンドを入力して、
network.openshift.io/network-type-migration-アノテーションをnetwork.configカスタムリソースから削除します。oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.1.5.5. OVN-Kubernetes アドレス範囲のパッチ適用 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes は次の IP アドレス範囲を予約します。
-
100.64.0.0/16.この IP アドレス範囲は、デフォルトで OVN-Kubernetes のinternalJoinSubnetパラメーターに使用されます。 -
100.88.0.0/16.この IP アドレス範囲は、デフォルトで OVN-Kubernetes のinternalTransSwitchSubnetパラメーターに使用されます。
これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。
移行が最初にブロックした場合は、次の手順を使用して、OpenShift SDN で使用している CIDR 範囲にパッチを適用できます。
これはオプションの手順であり、「限定的なライブマイグレーションプロセスの開始」の oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}' コマンドを使用した後に移行がブロックされた場合にのみ使用する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
100.64.0.0/16IP アドレス範囲がすでに使用されている場合は、次のコマンドを実行して別の範囲にパッチを適用します。次の例では、100.99.0.0/16 を使用します。oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.70.0.0/16"}}}}}'$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.70.0.0/16"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 100.88.0.0/16IP アドレス範囲がすでに使用されている場合は、次のコマンドを入力して別の範囲にパッチを適用します。次の例では、100.99.0.0/16を使用します。oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
IP アドレス範囲 100.64.0.0/16 および 100.88.0.0/16 にパッチを適用した後、制限付きライブマイグレーションを開始できます。
19.5.1.5.6. 限定的なライブマイグレーションを開始した後のクラスターリソースの確認 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、デプロイで OVN-Kubernetes を使用しているときに、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、およびネットワークポリシーを確認する方法を示します。OpenShift SDN 上にこれらのリソースがあった場合は、移行後にそれらを確認して、適切に動作していることを確認する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - 制限付きライブマイグレーションを使用して、OpenShift SDN から OVN-Kubernetes に正常に移行しました。
手順
OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、
ocCLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。ocCLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。
oc get egressfirewalls.k8s.ovn.org -A
$ oc get egressfirewalls.k8s.ovn.org -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5dCopy to Clipboard Copied! Toggle word wrap Toggle overflow -o yamlフラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。oc get egressfirewall <example_egressfirewall> -n <namespace> -o yaml
$ oc get egressfirewall <example_egressfirewall> -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 移行後にこのリソースの動作が変更されている可能性があるため、このリソースの動作が意図したとおりであることを確認してください。Egress ファイアウォールの詳細は、「プロジェクトの Egress ファイアウォールの設定」を参照してください。
OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに
ovnkube_controller_num_egress_firewall_rulesと入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
クラスターの Egress IP リソースを確認します。これは、
ocCLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。ocCLI ツールを使用して Egress IP を確認するには、以下を行います。Egress IP リソースを含む namespace をリスト表示するには、次のコマンドを実行します。
oc get egressip
$ oc get egressipCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME EGRESSIPS ASSIGNED NODE ASSIGNED EGRESSIPS egress-sample 192.0.2.10 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.10 egressip-sample-2 192.0.2.14 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.14
NAME EGRESSIPS ASSIGNED NODE ASSIGNED EGRESSIPS egress-sample 192.0.2.10 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.10 egressip-sample-2 192.0.2.14 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.14Copy to Clipboard Copied! Toggle word wrap Toggle overflow Egress IP に関する詳細情報を提供するには、次のコマンドを実行します。
oc get egressip <egressip_name> -o yaml
$ oc get egressip <egressip_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべての Egress IP に対してこれを繰り返します。移行後に各リソースの動作が変更されている可能性があるため、各リソースの動作が意図したとおりであることを確認します。Egress IP の詳細は、「Egress IP アドレスの設定」を参照してください。
OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。
- OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
-
Expression ボックスに
ovnkube_clustermanager_num_egress_ipsと入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
クラスターでマルチキャスト対応の namespace を確認します。これを実行できるのは
ocCLI を使用する場合のみです。マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。
oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'
$ oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
namespace1 namespace3
namespace1 namespace3Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャスト対応の各 namespace を説明するには、次のコマンドを実行します。
oc describe namespace <namespace>
$ oc describe namespace <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各 namespace でマルチキャスト機能が正しく設定され、期待どおりに動作していることを確認します。詳細は、"プロジェクトでのマルチキャストの有効化" を参照してください。
クラスターのネットワークポリシーを確認します。これを実行できるのは
ocCLI を使用する場合のみです。namespace 内のネットワークポリシーに関する情報を取得するには、次のコマンドを実行します。
oc get networkpolicy -n <namespace>
$ oc get networkpolicy -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
NAME POD-SELECTOR AGE allow-multicast app=my-app 11mCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークポリシーに関する詳細情報を提供するには、次のコマンドを入力します。
oc describe networkpolicy allow-multicast -n <namespace>
$ oc describe networkpolicy allow-multicast -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークポリシーの動作が意図したとおりであることを確認します。ネットワークポリシーの最適化は SDN と OVN-K で異なるため、ユーザーはさまざまな CNI で最適なパフォーマンスを実現するためにポリシーの調整が必要になる場合があります。詳細は、「ネットワークポリシーについて」を参照してください。
19.5.1.6. 限定的なライブマイグレーションのメトリクスの確認 リンクのコピーリンクがクリップボードにコピーされました!
限定的なライブマイグレーションの進行状況を監視するためのメトリクスが利用可能です。メトリクスは、OpenShift Container Platform Web コンソール、または oc CLI を使用して表示できます。
前提条件
- OVN-Kubernetes への限定的なライブマイグレーションを開始している。
手順
OpenShift Container Platform Web コンソールで限定されたライブマイグレーションメトリクスを表示するには、次の手順を実行します。
- Observe → Metrics をクリックします。
- Expression ボックスに openshift_network と入力し、openshift_network_operator_live_migration_procedure オプションをクリックします。
ocCLI を使用してメトリクスを表示するには、以下を実行します。以下のコマンドを入力して、
openshift-monitoringnamespace にprometheus-k8sサービスアカウントのトークンを生成します。token=`oc create token prometheus-k8s -n openshift-monitoring`
$ token=`oc create token prometheus-k8s -n openshift-monitoring`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
openshift_network_operator_live_migration_conditionメトリクスに関する情報を要求します。oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?' --data-urlencode 'query=openshift_network_operator_live_migration_condition' | jq
$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?' --data-urlencode 'query=openshift_network_operator_live_migration_condition' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
「制限付きのライブマイグレーションメトリクスに関する情報」の表には、利用可能なメトリクスと、openshift_network_operator_live_migration_procedure 式から入力されたラベル値が表示されます。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。
19.5.1.6.1. ライブマイグレーションのメトリックスに関する情報 リンクのコピーリンクがクリップボードにコピーされました!
次の表は、openshift_network_operator_live_migration_procedure 式から入力された利用可能なメトリクスとラベル値を示しています。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。
| メトリクス | ラベル値 |
|---|---|
|
|
|
|
19.5.3. OVN-Kubernetes ネットワークプラグインへのオフライン移行の概要 リンクのコピーリンクがクリップボードにコピーされました!
オフライン移行方法は手動のプロセスであり、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。オフライン移行手順を自動化する Ansible Playbook を使用すると、時間を節約できます。これらの方法は、主に自己管理の OpenShift Container Platform デプロイメントに使用され、限られたライブマイグレーション手順の代替手段です。これらのメソッドは、OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションを実行できない場合にのみ使用してください。
OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。
ロールバック手順が提供されますが、オフライン移行方法は一方向プロセスとして使用されます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
次のセクションでは、オフライン移行方法についてさらに詳しく説明します。
19.5.3.1. オフライン移行方法を使用する場合にサポートされるプラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、手動のオフライン移行タイプでサポートされるプラットフォームに関する情報を提供します。
| プラットフォーム | オフラインマイグレーション |
|---|---|
| ベアメタルハードウェア | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud Platform (GCP) | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| Red Hat OpenStack Platform (RHOSP) | ✓ |
| VMware vSphere | ✓ |
| Nutanix | ✓ |
以下の表は、手動のオフライン移行タイプでサポートされるプラットフォームに関する情報を提供します。
| プラットフォーム | Ansible Playbook のオフライン移行 |
|---|---|
| ベアメタルハードウェア | ✓ |
| Amazon Web Services (AWS) | ✓ |
| Google Cloud Platform (GCP) | ✓ |
| IBM Cloud® | ✓ |
| Microsoft Azure | ✓ |
| VMware vSphere | ✓ |
これらの表にリストされているプラットフォームごとに、プラットフォームは、インストーラーによってプロビジョニングされたインフラストラクチャーおよびユーザーによってプロビジョニングされたインフラストラクチャーへの OpenShift Container Platform クラスターのインストールをサポートします。
19.5.3.2. 手動オフライン移行および Ansible Playbook のオフライン移行方法のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
オフライン移行方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Best practices for OpenShift SDN to OVN Kubernetes CNI Offline migration を参照してください。
19.5.3.3. OVN-Kubernetes ネットワークプラグインへのオフライン移行方法に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターに 150 を超えるノードがある場合は、OVN-Kubernetes ネットワークプラグインへの移行について相談するサポートケースを開きます。
ノードに割り当てられたサブネット、および個々の Pod に割り当てられた IP アドレスは、移行時に保持されません。
OVN-Kubernetes ネットワークプラグインは、OpenShift SDN ネットワークプラグインに存在する多くの機能を実装していますが、設定は同じではありません。
クラスターが次の OpenShift SDN ネットワークプラグイン機能のいずれかを使用する場合、OVN-Kubernetes ネットワークプラグインで同じ機能を手動で設定する必要があります。
- namespace の分離
- Egress ルーター Pod
-
OVN-Kubernetes に移行する前に、IP アドレス範囲が 100.
64.0.00/16、/16、169.254.169.0/29、100.88.0.fd98::/64、fdが使用されていないことを確認してください。OVN-Kubernetes はこれらの範囲を内部で使用します。これらの範囲については、クラスターまたはインフラストラクチャーの他の CIDR 定義に含めないでください。69::/125、および/64fd97:: -
PTP を使用する
openshift-sdnクラスターで、ハードウェアタイムスタンプに User Datagram Protocol (UDP) を使用している場合、OVN-Kubernetes プラグインに移行すると、Open vSwitch (OVS) ブリッジなどのプライマリーインターフェイスデバイスにハードウェアタイムスタンプを適用できなくなります。そのため、UDP バージョン 4 の設定は、br-exインターフェイスでは機能しません。 OpenShift SDN と同様に、OVN-Kubernetes リソースに
ClusterAdmin権限が必要です。OpenShift SDN から OVN-Kubernetes への移行では、ロールベースアクセス制御(RBAC)リソースは自動的に更新されません。aggregate-to-adminClusterRoleを使用してプロジェクト管理者に付与される OpenShift SDN リソースは、移行プロセスに含まれないため、手動で確認し、調整する必要があります。移行後に RBAC リソースを手動で検証する必要があります。
以下のセクションでは、OVN-Kubernetes と OpenShift SDN ネットワークプラグインの前述の機能の設定の違いを強調しています。
プライマリーネットワークインターフェイス
OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。
プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、Kubernetes-NMState はこの設定を管理できません。代わりに、configure-ovs.sh シェルスクリプトがプライマリーインターフェイスと、このインターフェイスに接続されている設定を管理します。
namespace の分離
OVN-Kubernetes はネットワークポリシーの分離モードのみをサポートします。
マルチテナントモードまたはサブネット分離モードのいずれかで設定されている OpenShift SDN を使用するクラスターの場合でも、OVN-Kubernetes ネットワークプラグインに移行できます。移行操作後、マルチテナント分離モードは削除されるため、Pod とサービスに対して同じプロジェクトレベルの分離を実現するには、ネットワークポリシーを手動で設定する必要があることに注意してください。
Egress IP アドレス
OpenShift SDN は、2 つの異なる Egress IP モードをサポートしています。
- 自動的に割り当てる 方法では、Egress IP アドレス範囲はノードに割り当てられます。
- 手動で割り当てる 方法では、1 つ以上の Egress IP アドレスの一覧がノードに割り当てられます。
移行プロセスでは、自動割り当てモードを使用する Egress IP 設定の移行がサポートされています。
OVN-Kubernetes と OpenShift SDN との間に Egress IP アドレスを設定する際の相違点は、以下の表で説明されています。
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
OVN-Kubernetes で Egress IP アドレスを使用する方法の詳細は、「Egress IP アドレスの設定」を参照してください。
Egress ネットワークポリシー
OVN-Kubernetes と OpenShift SDN との間に Egress ファイアウォールとしても知られる Egress ネットワークポリシーの設定に関する相違点は、以下の表に記載されています。
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
EgressFirewall オブジェクトの名前は default にしか設定できないため、移行後は、OpenShift SDN での名前に関係なく、移行されたすべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。
その後、OpenShift SDN にロールバックすると、以前の名前が失われるため、すべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。
OVN-Kubernetes で Egress ファイアウォールを使用する方法の詳細は、「プロジェクトの Egress ファイアウォールの設定」を参照してください。
Egress ルーター Pod
OVN-Kubernetes は、リダイレクトモードで Egress ルーター Pod をサポートします。OVN-Kubernetes は、HTTP プロキシーモードまたは DNS プロキシーモードでは Egress ルーター Pod をサポートしません。
Cluster Network Operator で Egress ルーターをデプロイする場合、ノードセレクターを指定して、Egress ルーター Pod のホストに使用するノードを制御することはできません。
マルチキャスト
OVN-Kubernetes と OpenShift SDN でマルチキャストトラフィックを有効にする方法の相違点は、以下の表で説明されています。
| OVN-Kubernetes | OpenShift SDN |
|---|---|
|
|
OVN-Kubernetes でのマルチキャストの使用に関する詳細は、「プロジェクトのマルチキャストの有効化」を参照してください。
ネットワークポリシー
OVN-Kubernetes は、networking.k8s.io/v1 API グループで Kubernetes NetworkPolicy API を完全にサポートします。OpenShift SDN から移行する際に、ネットワークポリシーで変更を加える必要はありません。
19.5.3.4. オフライン移行プロセスの仕組み リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
| ユーザーが開始する手順 | 移行アクティビティー |
|---|---|
|
|
|
|
|
|
| クラスターの各ノードを再起動します。 |
|
19.5.3.5. Ansible Playbook を使用した OVN-Kubernetes ネットワークプラグインへの移行 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Ansible コレクション network.offline_migration_sdn_to_ovnk を使用して、OpenShift SDN Container Network Interface (CNI)ネットワークプラグインからクラスターの OVN-Kubernetes プラグインに移行できます。Ansible コレクションには、次の Playbook が含まれています。
-
playbooks/playbook-migration.yml: 各 Playbook が移行プロセスのステップを表すシーケンスで実行される Playbook が含まれます。 -
playbooks/playbook-rollback.yml: 各 Playbook がロールバックプロセスのステップを表すシーケンスで実行される Playbook が含まれます。
前提条件
-
python3パッケージ(最小バージョン 3.10)をインストールしている。 -
jmespathパッケージおよびjqパッケージをインストールしました。 - Red Hat Hybrid Cloud Console にログインし、Ansible Automation Platform Web コンソールを開いている。
-
すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。このタスクを実行しないと、クラスターが Pod のスケジュールに失敗する可能性があります。 -
OpenShift-SDN プラグインが 100
.64.0.0/16 およびアドレス範囲を使用する場合は、アドレス範囲にパッチを適用します。詳細については、関連情報 セクションの OVN-Kubernetes アドレス範囲の修正を参照して ください。100.88.0.0/16
手順
ansible-coreパッケージをインストールします(最小バージョン 2.15)。以下のコマンド例は、Red Hat Enterprise Linux (RHEL)にansible-coreパッケージをインストールする方法を示しています。sudo dnf install -y ansible-core
$ sudo dnf install -y ansible-coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow ansible.cfgファイルを作成し、以下の例のような情報をファイルに追加します。ansible-galaxyコマンドおよび Playbook が実行されるのと同じディレクトリーにファイルが存在することを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ansible Automation Platform Web コンソールから、Connect to Hub ページに移動し、次の手順を実行します。
- ページの Offline token セクションで、Load token ボタンをクリックします。
- トークンがロードされたら、Copy to clipboard アイコンをクリックします。
-
ansible.cfgファイルを開き、API トークンをtoken=パラメーターに貼り付けます。API トークンは、ansible.cfgファイルで指定されたサーバー URL に対して認証するために必要です。
以下の
ansible-galaxyコマンドを入力して、network.offline_migration_sdn_to_ovnkAnsible コレクションをインストールします。ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection install network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible コレクションがシステムにインストールされていることを確認します。ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.offline_migration_sdn_to_ovnk 1.0.2
network.offline_migration_sdn_to_ovnk 1.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible コレクションは、~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/のデフォルトパスに保存されます。playbooks/playbook-migration.ymlファイルで移行機能を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow migration_interface_name-
プライマリーインターフェイスで
NodeNetworkConfigurationPolicy(NNCP)リソースを使用する場合は、移行プロセス中に NNCP リソースがプライマリーインターフェイスで削除されるように、migration-playbook.ymlファイルでインターフェイス名を指定します。 migration_disable_auto_migration-
OVN-Kubernetes プラグインへの OpenShift SDN CNI プラグイン機能の自動移行を無効にします。機能の自動移行を無効にする場合は、
migration_egress_ipパラメーター、migration_egress_firewallパラメーター、およびmigration_multicastパラメーターもfalseに設定する必要があります。機能の自動移行を有効にする必要がある場合は、パラメーターをfalseに設定します。 migration_mtu- 移行プロセス後にクラスターネットワークに特定の最大伝送単位(MTU)を設定するオプションのパラメーター。
migration_geneve_port-
OVN-Kubernetes の Geneve ポートを設定するオプションのパラメーター。デフォルトのポートは
6081です。 migration_ipv4_subnet-
OVN-Kubernetes による内部使用の IPv4 アドレス範囲を設定するオプションのパラメーター。パラメーターのデフォルト値は
100.64.0.0/16 です。
playbooks/playbook-migration.ymlファイルを実行するには、以下のコマンドを入力します。ansible-playbook -v playbooks/playbook-migration.yml
$ ansible-playbook -v playbooks/playbook-migration.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.3.6. オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインに移行する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。
移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。
前提条件
- ネットワークポリシー分離モードの OpenShift SDN CNI ネットワークプラグインで設定されたクラスターがある。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップがある。
- 各ノードを手動で再起動できる。
- クラスターがエラーのない既知の良好な状態にあることを確認している。
-
すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。 - Webhook を削除しました。または、手順で説明する各 Webhook にタイムアウト値を設定できます。これらのタスクのいずれかを完了しなかった場合、クラスターは Pod のスケジュールに失敗する可能性があります。
手順
Webhook を削除しなかった場合は、
ValidatingWebhookConfigurationカスタムリソースを作成し、timeoutSecondsパラメーターのタイムアウト値を指定して、各 Webhook のタイムアウト値を3秒に設定します。oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \ -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \1 -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;webhook_name> は Webhook の名前です。
クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。
oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
$ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
OVN_SDN_MIGRATION_TIMEOUT環境変数が設定され、0sになっていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する
NodeNetworkConfigurationPolicy(NNCP) カスタムリソース (CR) を削除します。次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
NAME STATUS REASON bondmaster0 Available SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを
/etc/NetworkManager/system-connectionsシステムパスに保存します。クラスターから NNCP を削除します。
oc delete nncp <nncp_manifest_filename>
$ oc delete nncp <nncp_manifest_filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのノードを移行用に準備するには、次のコマンドを実行して、CNO 設定オブジェクトの
migrationフィールドを設定します。oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、
migrationフィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。次のコマンドを実行して、再起動が完了したことを確認します。
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、すべてのクラスター Operator が利用可能であることを確認します。
oc get co
$ oc get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、いくつかの OpenShift SDN 機能の OVN-Kubernetes 同等機能への自動移行を無効にすることができます。
- Egress IP
- Egress ファイアウォール
- マルチキャスト
前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
bool: 機能の移行を有効にするかどうかを指定します。デフォルトはtrueです。
オプション: ネットワークインフラストラクチャーの要件を満たすように OVN-Kubernetes の以下の設定をカスタマイズできます。
最大伝送単位 (MTU)。このオプションの手順で MTU をカスタマイズする前に、以下を考慮してください。
- デフォルトの MTU を使用しており、移行中にデフォルトの MTU を維持したい場合は、この手順を無視できます。
- カスタム MTU を使用しており、移行中にカスタム MTU を維持する必要がある場合は、この手順でカスタム MTU 値を宣言する必要があります。
移行中に MTU 値を変更する場合、この手順は機能しません。代わりに、まず「クラスター MTU の変更」に記載された指示に従う必要があります。その後、この手順を実行してカスタム MTU 値を宣言すると、カスタム MTU 値を維持できます。
注記OpenShift-SDN と OVN-Kubernetes のオーバーレイオーバーヘッドは異なります。MTU 値は、「MTU 値の選択」ページにあるガイドラインに従って選択する必要があります。
- Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークポート
- OVN-Kubernetes IPv4 内部サブネット
ゲートウェイモードと IP 転送
-
クラスターがホストネットワークで静的ルートまたはルーティングポリシーを使用する場合は、
routingViaHost仕様をtrueに、ipForwarding仕様をgatewayConfigオブジェクトでGlobalに設定します。
-
クラスターがホストネットワークで静的ルートまたはルーティングポリシーを使用する場合は、
以前の設定のいずれかをカスタマイズするには、以下のコマンドを入力してカスタマイズします。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
mtu-
Geneve オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも
100小さく設定する必要があります。 port-
Geneve オーバーレイネットワークの UDP ポート。値が指定されない場合、デフォルトは
6081になります。ポートは、OpenShift SDN で使用される VXLAN ポートと同じにすることはできません。VXLAN ポートのデフォルト値は4789です。 ipv4_subnet-
OVN-Kubernetes による内部使用のための IPv4 アドレス範囲。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は
100.64.0.0/16です。 routingViaHost-
値を
trueにするとローカルゲートウェイモードが設定され、値をfalseにすると共有ゲートウェイモードが設定されます。デフォルト値はfalseです。ローカルゲートウェイモードでは、トラフィックはホストネットワークスタックを介してルーティングされます。共有ゲートウェイモードでは、トラフィックはホストネットワークスタック経由でルーティングされません。 ipForwarding-
OVN-Kubernetes に関連しないトラフィックのルーターとしてノードのホストネットワークを機能させる必要がある場合は、ローカルゲートウェイモードとともに IP 転送を
Globalに設定します。
mtuフィールドを更新するoc patchコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow gatewayConfigオブジェクトを更新するoc patchコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true、UPDATING=false、DEGRADED=falseのステータスがあります。注記デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStartCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<config_name>はmachineconfiguration.openshift.io/currentConfigフィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含めることができます。
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードが
NotReady状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。Pod をリスト表示するには、以下のコマンドを入力します。
oc get pod -n openshift-machine-config-operator
$ oc get pod -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定デーモン Pod の名前は以下の形式になります。
machine-config-daemon-<seq><seq>値は、ランダムな 5 文字の英数字シーケンスになります。以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。
oc logs <pod> -n openshift-machine-config-operator
$ oc logs <pod> -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
podはマシン設定デーモン Pod の名前になります。- 直前のコマンドの出力で示されるログ内のエラーを解決します。
移行を開始するには、次のいずれかのコマンドを使用して OVN-Kubernetes ネットワークプラグインを設定します。
クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。
oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'$ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
cidrは CIDR ブロックであり、prefixはクラスター内の各ノードに割り当てられる CIDR ブロックのスライスです。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16CIDR ブロックと重複する CIDR ブロックは使用できません。重要移行時に、サービスネットワークのアドレスブロックを変更することはできません。
Multus デーモンセットのロールアウトが完了したことを確認してから、後続の手順を続行します。
oc -n openshift-multus rollout status daemonset/multus
$ oc -n openshift-multus rollout status daemonset/multusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Multus Pod の名前の形式は
multus-<xxxxx>です。ここで、<xxxxx>は文字のランダムなシーケンスになります。Pod が再起動するまでにしばらく時間がかかる可能性があります。出力例
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled out
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled outCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークプラグインの変更を完了するには、クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。
重要次のスクリプトは、クラスター内のすべてのノードを同時に再起動します。これにより、クラスターが不安定になる可能性があります。もう 1 つのオプションとして、ノードを一度に 1 つずつ手動でリブートすることもできます。ノードを 1 つずつ再起動すると、多数のノードを持つクラスターではかなりのダウンタイムが発生します。
ノードを再起動するまで、クラスター Operator は正しく動作しません。
oc rshコマンドでは、次のような bash スクリプトを使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sshコマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように sudo が設定されていることを前提としています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
移行が正常に完了したことを確認します。
ネットワークプラグインが OVN-Kubernetes であることを確認するには、次のコマンドを入力します。
status.networkTypeの値はOVNKubernetesである必要があります。oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'$ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノードが
Ready状態にあることを確認するには、以下のコマンドを実行します。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードの Pod がエラー状態にある場合は、そのノードを再起動します。
すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。
oc get co
$ oc get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator のステータスは、
AVAILABLE="True"、PROGRESSING="False"、DEGRADED="False"になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。
以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。
CNO 設定オブジェクトから移行設定を削除するには、以下のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift SDN ネットワークプロバイダーのカスタム設定を削除するには、以下のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift SDN ネットワークプロバイダー namespace を削除するには、以下のコマンドを入力します。
oc delete namespace openshift-sdn
$ oc delete namespace openshift-sdnCopy to Clipboard Copied! Toggle word wrap Toggle overflow 移行操作が正常に完了したら、次のコマンドを入力して、
network.openshift.io/network-type-migration-アノテーションをnetwork.configカスタムリソースから削除します。oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- オプション:クラスターの移行後に、IPv4 のシングルスタッククラスターを、IPv4 および IPv6 アドレスファミリーをサポートするデュアルネットワーククラスターネットワークに変換できます。詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換 を参照してください。
19.5.4. OVN-Kubernetes での外部 IP の動作の変更について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN から OVN-Kubernetes (OVN-K) に移行すると、NetworkPolicy が適用されて、外部 IP を使用するサービスが namespace をまたいでアクセスできなくなる可能性があります。
OpenShift SDN では、デフォルトで外部 IP が namespace をまたいでアクセス可能でした。しかし、OVN-K ではネットワークポリシーによってマルチテナント分離が厳密に適用され、他の namespace からの外部 IP 経由で公開されるサービスにアクセスできません。
アクセス権を確保するには、次の方法を検討してください。
- Ingress またはルートを使用する: 外部 IP を使用してサービスを公開する代わりに、セキュリティー制御を維持しながら外部アクセスを許可するように Ingress またはルートを設定します。
-
NetworkPolicyカスタムリソース(CR)の調整:NetworkPolicyCR を変更して、必要な namespace からのアクセスを明示的に許可し、トラフィックが指定されたサービスポートに対して許可されていることを確認します。必要なポートへのトラフィックを許可しないと、namespace が明示的に許可されていても、アクセスがブロックされる可能性があります。 -
LoadBalancerサービスを使用する: 該当する場合は、外部 IP に依存する代わりにLoadBalancerサービスをデプロイします。設定の詳細は、OVN-Kubernetes での NetworkPolicy と外部 IP を参照してください。
19.6. OpenShift SDN ネットワークプロバイダーへのロールバック リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、オフライン 移行方法または 制限付きライブ 移行方法のいずれかを使用して、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインにロールバックできます。これは、OVN-Kubernetes ネットワークプラグインへの移行が正常に完了した後にのみ実行できます。
- オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、オフライン移行ロールバック方法を使用する必要があります。
- 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、制限付きライブマイグレーションロールバック方式を使用する必要があります。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
19.6.1. オフライン移行方法を使用した OpenShift SDN ネットワークプラグインへのロールバック リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、オフライン移行方法を使用して、OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。移行中は、クラスター内のすべてのノードを手動で再起動する必要があります。オフライン移行方法では、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。
ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。
OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。
| ユーザーが開始する手順 | 移行アクティビティー |
|---|---|
| MCO を一時停止し、移行が中断されないようにします。 | MCO が停止します。 |
|
|
|
|
|
|
| クラスターの各ノードを再起動します。 |
|
| クラスターのすべてのノードが再起動した後に MCO を有効にします。 |
|
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
- インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
- etcd データベースの最新のバックアップが利用可能である。
- ノードごとに手動の再起動をトリガーできる。
- クラスターは既知の正常な状態にあり、エラーがない。
手順
Machine Config Operator (MCO) によって管理されるすべてのマシン設定プールを停止します。
CLI で次のコマンドを入力して、
master設定プールを停止します。oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": true } }'$ oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": true } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力して、
workerマシン設定プールを停止します。oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec":{ "paused": true } }'$ oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec":{ "paused": true } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
移行の準備をするには、CLI で次のコマンドを入力して、移行フィールドを
nullに設定します。oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力して、
Network.config.openshift.ioオブジェクトの移行ステータスが空であることを確認します。空のコマンド出力は、オブジェクトが移行操作中ではないことを示しています。oc get Network.config cluster -o jsonpath='{.status.migration}'$ oc get Network.config cluster -o jsonpath='{.status.migration}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力して、
Network.operator.openshift.ioオブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Network.operator.openshift.ioオブジェクトでパッチ操作が終了する前にNetwork.config.openshift.ioオブジェクトにパッチを適用した場合、Cluster Network Operator (CNO) は degradation 状態になり、CNO が degradation 状態から回復するまでわずかな遅延が発生します。CLI で次のコマンドを入力して、
Network.config.openshift.io clusterオブジェクトのネットワークプラグインの移行ステータスがOpenShiftSDNであることを確認します。oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'$ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力して、
Network.config.openshift.ioオブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。oc patch Network.config.openshift.io cluster --type='merge' \ --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'$ oc patch Network.config.openshift.io cluster --type='merge' \ --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: いくつかの OVN-Kubernetes 機能の OpenShift SDN 同等機能への自動移行を無効化します。
- Egress IP
- Egress ファイアウォール
- マルチキャスト
前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
bool: 機能の移行を有効にするかどうかを指定します。デフォルトはtrueです。オプション: ネットワークインフラストラクチャーの要件を満たすように OpenShift SDN の以下の設定をカスタマイズできます。
- 最大伝送単位 (MTU)
- VXLAN ポート
前述の設定のいずれかまたは両方をカスタマイズするには、CLI で次のコマンドをカスタマイズして入力します。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mtu-
VXLAN オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも
50小さく設定する必要があります。 port-
VXLAN オーバーレイネットワークの UDP ポート。値が指定されない場合は、デフォルトは
4789になります。ポートは OVN-Kubernetes で使用される Geneve ポートと同じにすることはできません。Geneve ポートのデフォルト値は6081です。
patch コマンドの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。
oc rshコマンドでは、次のような bash スクリプトを使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sshコマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように sudo が設定されていることを前提としています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Multus デーモンセットのロールアウトが完了するまで待機します。次のコマンドを実行して、ロールアウトのステータスを確認します。
oc -n openshift-multus rollout status daemonset/multus
$ oc -n openshift-multus rollout status daemonset/multusCopy to Clipboard Copied! Toggle word wrap Toggle overflow Multus Pod の名前の形式は
multus-<xxxxx>です。ここで、<xxxxx>は文字のランダムなシーケンスになります。Pod が再起動するまでにしばらく時間がかかる可能性があります。出力例
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled out
Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated... ... Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available... daemon set "multus" successfully rolled outCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のノードが再起動し、multus Pod がロールアウトされたら、次のコマンドを実行してすべてのマシン設定プールを起動します。
マスター設定プールを開始します。
oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": false } }'$ oc patch MachineConfigPool master --type='merge' --patch \ '{ "spec": { "paused": false } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカー設定プールを開始します。
oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec": { "paused": false } }'$ oc patch MachineConfigPool worker --type='merge' --patch \ '{ "spec": { "paused": false } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
MCO が各設定プールのマシンを更新すると、各ノードを再起動します。
デフォルトで、MCO は一度にプールごとに単一のマシンを更新するため、移行が完了するまでに必要な時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、CLI で以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: DoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/stateフィールドの値はDoneです。 -
machineconfiguration.openshift.io/currentConfigフィールドの値は、machineconfiguration.openshift.io/desiredConfigフィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、CLI で以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml
$ oc get machineconfig <config_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<config_name>はmachineconfiguration.openshift.io/currentConfigフィールドのマシン設定の名前になります。
移行が正常に完了したことを確認します。
ネットワークプラグインが OpenShift SDN であることを確認するには、CLI で次のコマンドを入力します。
status.networkTypeの値はOpenShiftSDNである必要があります。oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'$ oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノードが
Ready状態にあることを確認するには、CLI で以下のコマンドを入力します。oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードが
NotReady状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。Pod をリスト表示するには、CLI で次のコマンドを入力します。
oc get pod -n openshift-machine-config-operator
$ oc get pod -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定デーモン Pod の名前は以下の形式になります。
machine-config-daemon-<seq><seq>値は、ランダムな 5 文字の英数字シーケンスになります。前の出力に示されている各マシン設定デーモン Pod の Pod ログを表示するには、CLI で次のコマンドを入力します。
oc logs <pod> -n openshift-machine-config-operator
$ oc logs <pod> -n openshift-machine-config-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
podはマシン設定デーモン Pod の名前になります。- 直前のコマンドの出力で示されるログ内のエラーを解決します。
Pod がエラー状態ではないことを確認するには、CLI で次のコマンドを入力します。
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードの Pod がエラー状態にある場合は、そのノードを再起動します。
以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。
Cluster Network Operator 設定オブジェクトから移行設定を削除するには、CLI で次のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OVN-Kubernetes 設定を削除するには、CLI で次のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OVN-Kubernetes ネットワークプロバイダー namespace を削除するには、CLI で次のコマンドを入力します。
oc delete namespace openshift-ovn-kubernetes
$ oc delete namespace openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.2. Ansible Playbook を使用した OpenShift SDN ネットワークプラグインへのロールバック リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、network.offline_migration_sdn_to_ovnk Ansible コレクションの playbooks/playbook-rollback.yml を使用して、OVN-Kubernetes プラグインから OpenShift SDN Container Network Interface (CNI)ネットワークプラグインにロールバックできます。
前提条件
-
python3パッケージ(最小バージョン 3.10)をインストールしている。 -
jmespathパッケージおよびjqパッケージをインストールしました。 - Red Hat Hybrid Cloud Console にログインし、Ansible Automation Platform Web コンソールを開いている。
-
すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。このタスクを実行しないと、クラスターが Pod のスケジュールに失敗する可能性があります。
手順
ansible-coreパッケージをインストールします(最小バージョン 2.15)。以下のコマンド例は、Red Hat Enterprise Linux (RHEL)にansible-coreパッケージをインストールする方法を示しています。sudo dnf install -y ansible-core
$ sudo dnf install -y ansible-coreCopy to Clipboard Copied! Toggle word wrap Toggle overflow ansible.cfgファイルを作成し、以下の例のような情報をファイルに追加します。ansible-galaxyコマンドおよび Playbook が実行されるのと同じディレクトリーにファイルが存在することを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ansible Automation Platform Web コンソールから、Connect to Hub ページに移動し、次の手順を実行します。
- ページの Offline token セクションで、Load token ボタンをクリックします。
- トークンがロードされたら、Copy to clipboard アイコンをクリックします。
-
ansible.cfgファイルを開き、API トークンをtoken=パラメーターに貼り付けます。API トークンは、ansible.cfgファイルで指定されたサーバー URL に対して認証するために必要です。
以下の
ansible-galaxyコマンドを入力して、network.offline_migration_sdn_to_ovnkAnsible コレクションをインストールします。ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection install network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible コレクションがシステムにインストールされていることを確認します。ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.offline_migration_sdn_to_ovnk 1.0.2
network.offline_migration_sdn_to_ovnk 1.0.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnkAnsible コレクションは、~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/のデフォルトパスに保存されます。playbooks/playbook-migration.ymlファイルでロールバック機能を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow rollback_disable_auto_migration-
OpenShift SDN CNI プラグインへの OVN-Kubernetes プラグイン機能の自動移行を無効にします。機能の自動移行を無効にする場合は、
rollback_egress_ipパラメーター、rollback_egress_firewallパラメーター、およびrollback_multicastパラメーターもfalseに設定する必要があります。機能の自動移行を有効にする必要がある場合は、パラメーターをfalseに設定します。 rollback_mtu- 移行プロセス後にクラスターネットワークに特定の最大伝送単位(MTU)を設定するオプションのパラメーター。
rollback_vxlanPort-
OpenShift SDN CNI プラグインが使用する VXLAN (仮想拡張 LAN)ポートを設定するオプションのパラメーター。このパラメーターのデフォルト値は
4790です。
playbooks/playbook-rollback.ymlファイルを実行するには、以下のコマンドを入力します。ansible-playbook -v playbooks/playbook-rollback.yml
$ ansible-playbook -v playbooks/playbook-rollback.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.3. 制限付きのライブマイグレーションの方法を使用した OpenShift SDN ネットワークプラグインへのロールバック リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターを OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。この方法による移行中は、ノードは自動的に再起動され、クラスターへのサービスは中断されません。
ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。
OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。
| ユーザーが開始する手順 | 移行アクティビティー |
|---|---|
|
|
|
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
- インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
- etcd データベースの最新のバックアップが利用可能である。
- ノードごとに手動の再起動をトリガーできる。
- クラスターは既知の正常な状態にあり、エラーがない。
手順
OpenShift SDN へのロールバックを開始するには、次のコマンドを入力します。
oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'$ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 移行の進行状況を確認するには、次のコマンドを入力します。
watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\"" -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'
$ watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\"" -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、次の情報を毎秒出力します。
-
network.config.openshift.io/clusterオブジェクトのステータスの条件。移行の進捗を報告します。 -
machine-config-Operatorリソースに関するさまざまなノードのステータス。これには、アップグレード中かアップグレード済みか、および現在の設定と必要な設定が含まれます。
-
以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。
次のコマンドを入力して、
network.configカスタムリソースからnetwork.openshift.io/network-type-migration=アノテーションを削除します。oc annotate network.config cluster network.openshift.io/network-type-migration-
$ oc annotate network.config cluster network.openshift.io/network-type-migration-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、OVN-Kubernetes ネットワークプロバイダーの namespace を削除します。
oc delete namespace openshift-ovn-kubernetes
$ oc delete namespace openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.7. IPv4/IPv6 デュアルスタックネットワークへの変換 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、IPv4 および IPv6 アドレスファミリーをサポートするデュアルネットワーククラスターネットワークに、IPv4 の単一スタッククラスターを変換できます。デュアルスタックネットワークに変換すると、新しい Pod と既存の Pod でデュアルスタックネットワークが有効になります。
IPv6 を必要とするデュアルスタックネットワークを使用する場合、::FFFF:198.51.100.1 などの IPv4 にマッピングされた IPv6 アドレスは使用できません。
19.7.1. デュアルスタッククラスターネットワークへの変換 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、単一スタッククラスターネットワークをデュアルスタッククラスターネットワークに変換できます。
デュアルスタックネットワークを使用するようにクラスターを変換した後、Pod が IPv6 アドレスを受け取るように、既存の Pod を再作成する必要があります。IPv6 アドレスは、新しい Pod にのみ割り当てられるためです。
シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換するには、パッチを作成し、それをクラスターのネットワークとインフラストラクチャーに適用します。installer-provisioned infrastructure または user-provisioned infrastructure のいずれかで実行されるクラスターは、デュアルスタッククラスターネットワークに変換できます。
clusterNetwork、serviceNetwork、apiServerInternalIPs、および ingressIP オブジェクトを変更する各パッチ操作は、クラスターの再起動をトリガーします。MachineNetworks オブジェクトを変更しても、クラスターは再起動されません。
installer-provisioned infrastructure のみ、既存のデュアルスタック設定のクラスターに API および Ingress サービスの IPv6 仮想 IP (VIP) を追加する必要がある場合は、クラスターのネットワークではなく、インフラストラクチャーのみにパッチを適用する必要があります。
クラスターを OpenShift Container Platform 4.16 以降にすでにアップグレードしていて、シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換する必要がある場合は、YAML 設定パッチファイルで、API および Ingress サービスの install-config.yaml ファイルから既存の IPv4 machineNetwork ネットワーク設定を指定する必要があります。この設定により、IPv4 トラフィックがデフォルトゲートウェイと同じネットワークインターフェイスに存在させることができます。
machineNetwork ネットワーク用に IPv4 アドレスブロックが追加された YAML 設定ファイルの例
- op: add path: /spec/platformSpec/baremetal/machineNetworks/- value: 192.168.1.0/24 # ...
- op: add
path: /spec/platformSpec/baremetal/machineNetworks/-
value: 192.168.1.0/24
# ...
- 1
- マシンが動作する
machineNetworkネットワークのアドレスブロックを指定していることを確認してください。マシンネットワークの API および Ingress の両方の IP アドレスを選択する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - クラスターは OVN-Kubernetes ネットワークプラグインを使用します。
- クラスターノードに IPv6 アドレスがある。
- インフラストラクチャーに基づいて IPv6 対応ルーターを設定している。
手順
クラスターおよびサービスネットワークの IPv6 アドレスブロックを指定するには、次の例のような設定を持つ YAML 設定パッチファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力して、クラスターネットワーク設定にパッチを適用します。
oc patch network.config.openshift.io cluster \ --type='json' --patch-file <file>.yaml
$ oc patch network.config.openshift.io cluster \1 --type='json' --patch-file <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここで、
fileは作成した YAML ファイルの名前を指定します。
出力例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow API および Ingress サービス用の IPv6 仮想 IP を追加した installer-provisioned infrastructure で、次の手順を実行します。
クラスターの API および Ingress サービスに IPv6 仮想 IP を指定します。次の例と同様の設定を含む YAML 設定パッチファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI で次のコマンドを入力してインフラストラクチャーにパッチを適用します。
oc patch infrastructure cluster \ --type='json' --patch-file <file>.yaml
$ oc patch infrastructure cluster \ --type='json' --patch-file <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、以下のようになります。
- <file>
作成した YAML ファイルの名前を指定します。
出力例
infrastructure/cluster patched
infrastructure/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
CLI で次のコマンドを入力して、クラスターネットワーク設定を表示します。
oc describe network
$ oc describe networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターネットワーク設定が YAML ファイルで指定した IPv6 アドレスブロックを認識していることを確認し、ネットワーク設定へのパッチのインストールが正常に行われたことを確認します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow installer-provisioned infrastructure 上で実行されるクラスターに対して、次の追加タスクを完了します。
CLI で次のコマンドを入力して、クラスターインフラストラクチャー設定を表示します。
oc describe infrastructure
$ oc describe infrastructureCopy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルで指定した IPv6 アドレスブロックがインフラストラクチャーによって認識されるかどうかを確認して、クラスターインフラストラクチャーへのパッチのインストールが正常に行われたことを確認します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.7.2. 単一スタッククラスターネットワークへの変換 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、デュアルスタッククラスターネットワークを単一スタッククラスターネットワークに変換できます。
元々 IPv4 シングルスタッククラスターネットワークをデュアルスタッククラスターに変換していた場合は、IPv4 シングルスタッククラスターにのみ戻すことができます。IPv6 シングルスタッククラスターネットワークには戻すことができません。IPv6 シングルスタッククラスターネットワークに戻す場合も、同じ制限が適用されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - クラスターは OVN-Kubernetes ネットワークプラグインを使用します。
- クラスターノードに IPv6 アドレスがある。
- デュアルスタックネットワークを有効にしている。
手順
以下のコマンドを実行して、
networks.config.openshift.ioカスタムリソース (CR) を編集します。oc edit networks.config.openshift.io
$ oc edit networks.config.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
「デュアルスタッククラスターネットワークへの変換」手順の実行時に
cidrおよびhostPrefixパラメーターに追加した IPv4 または IPv6 設定を削除します。
19.8. OVN-Kubernetes 内部 IP アドレスサブネットの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OVN-Kubernetes ネットワークプラグインが結合および転送サブネットに使用する IP アドレス範囲を変更できます。
19.8.1. OVN-Kubernetes 参加サブネットの設定 リンクのコピーリンクがクリップボードにコピーされました!
環境内ですでに使用されている既存のサブネットとの競合を避けるために、OVN-Kubernetes で使用される参加サブネットを変更できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。 - クラスターが OVN-Kubernetes ネットワークプラグインを使用していることを確認します。
手順
OVN-Kubernetes 参加サブネットを変更するには、次のコマンドを入力します。
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalJoinSubnet": "<join_subnet>"}, "ipv6":{"internalJoinSubnet": "<join_subnet>"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<join_subnet>-
OVN-Kubernetes が内部で使用する IP アドレスサブネットを指定します。サブネットは、クラスター内のノード数よりも大きく、クラスター内のノードごとに 1 つの IP アドレスを収容できる大きさである必要があります。このサブネットは、OpenShift Container Platform またはホスト自体で使用される他のサブネットと重複することはできません。IPv4 のデフォルト値は
100.64.0.0/16で、IPv6 のデフォルト値はfd98::/64です。
出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定がアクティブであることを確認するには、以下のコマンドを入力します。
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンド操作による変更が有効になるまでに最大 30 分かかる場合があります。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.8.2. OVN-Kubernetes 転送サブネットの設定 リンクのコピーリンクがクリップボードにコピーされました!
環境内ですでに使用されている既存のサブネットとの競合を避けるために、OVN-Kubernetes で使用されるトランジットサブネットを変更できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインする。 - クラスターが OVN-Kubernetes ネットワークプラグインを使用していることを確認します。
手順
OVN-Kubernetes 転送サブネットを変更するには、以下のコマンドを入力します。
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalTransitSwitchSubnet": "<transit_subnet>"}, "ipv6":{"internalTransitSwitchSubnet": "<transit_subnet>"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<transit_subnet>-
east-west トラフィックを有効にする分散トランジットスイッチの IP アドレスサブネットを指定します。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。IPv4 のデフォルト値は
100.88.0.0/16で、IPv6 のデフォルト値はfd97::/64です。
出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定がアクティブであることを確認するには、以下のコマンドを入力します。
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow この変更が有効になるまで、最大 30 分かかる場合があります。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9. ゲートウェイモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、gatewayConfig オブジェクトを設定して、外部トラフィックをクラスターからどのように送信するかを管理できます。これを行うには、routingViaHost 仕様を true (ローカルモードの場合) または false (共有モードの場合) に設定します。
ローカルゲートウェイモードでは、トラフィックがホストを経由してルーティングされ、その結果、ホストのルーティングテーブルに適用されます。共有ゲートウェイモードでは、トラフィックはホストを経由してルーティングされません。代わりに、Open vSwitch (OVS) がトラフィックをノード IP インターフェイスに直接出力します。
19.9.1. ローカルおよび共有ゲートウェイモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Cluster Network Operator の gatewayConfig 仕様を使用してゲートウェイモードを設定できます。次の手順を使用して、routingViaHost フィールドを true (ローカルモードの場合) または false (共有モードの場合) に設定できます。
ノードのホストネットワークを、OVN-Kubernetes に関連しないトラフィックのルーターとして機能させる必要がある場合は、オプションのステップ 4 に従って、ローカルゲートウェイモードとともに IP 転送を有効にできます。たとえば、ローカルゲートウェイモードと IP 転送を組み合わせた使用例としては、次のようなものが考えられます。
- すべての Pod Egress トラフィックをノードの IP 経由で転送するように設定する
- OVN-Kubernetes CNI と外部ネットワークアドレス変換 (NAT) デバイスを統合する
- カーネルルーティングテーブルを使用するように OVN-Kubernetes CNI を設定する
前提条件
- 管理者権限を持つユーザーとしてログインしている。
手順
次のコマンドを実行して、既存のネットワーク設定をバックアップします。
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ローカルゲートウェイモードを使用するために、次のコマンドを実行して
routingViaHostパラメーターをtrueに設定します。oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ローカルゲートウェイモードが設定されていることを確認します。
oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 値を
trueにするとローカルゲートウェイモードが設定され、値をfalseにすると共有ゲートウェイモードが設定されます。ローカルゲートウェイモードでは、トラフィックがホストを経由してルーティングされます。共有ゲートウェイモードでは、トラフィックはホストを経由してルーティングされません。
オプション: 次のコマンドを実行して、IP 転送をグローバルに有効にします。
oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'$ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
ipForwarding仕様がGlobalに設定されていることを確認します。oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10. デフォルトネットワークに外部ゲートウェイを設定する リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、デフォルトネットワークに外部ゲートウェイを設定できます。
この機能には次の利点があります。
- namespace ごとの Egress トラフィックの詳細制御
- 静的および動的外部ゲートウェイ IP アドレスの柔軟な設定
- IPv4 と IPv6 の両方のアドレスファミリーのサポート
19.10.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスターは OVN-Kubernetes ネットワークプラグインを使用します。
- インフラストラクチャーは、セカンダリー外部ゲートウェイからのトラフィックをルーティングするように設定されています。
19.10.2. OpenShift Container Platform が外部ゲートウェイ IP アドレスを決定する方法 リンクのコピーリンクがクリップボードにコピーされました!
k8s.ovn.org API グループの AdminPolicyBasedExternalRoute カスタムリソース (CR) を使用してセカンダリー外部ゲートウェイを設定します。この CR は、外部ゲートウェイの IP アドレスを指定するための静的アプローチと動的アプローチをサポートしています。
AdminPolicyBasedExternalRoute CR の対象となる各 namespace は、他の AdminPolicyBasedExternalRoute CR で選択できません。namespace には同時にセカンダリー外部ゲートウェイを含めることはできません。
ポリシーへの変更はコントローラー内で分離されます。あるポリシーの適用が失敗した場合に、他のポリシーを変更しても、他のポリシーの再試行はトリガーされません。ポリシーが再評価され、変更によって発生した可能性のある差分が適用されるのは、ポリシー自体またはポリシーに関連するオブジェクト (対象の namespace、Pod ゲートウェイ、または動的ホップからそれらをホストする namespace など) の更新が行われたときのみです。
- 静的割り当て
- IP アドレスを直接指定します。
- 動的割り当て
namespace と Pod セレクター、およびオプションのネットワーク割り当て定義を使用して、IP アドレスを間接的に指定します。
- ネットワーク割り当て定義の名前が指定されている場合は、ネットワーク割り当ての外部ゲートウェイ IP アドレスが使用されます。
-
ネットワーク割り当て定義の名前が指定されていない場合は、Pod 自体の外部ゲートウェイ IP アドレスが使用されます。ただし、このアプローチは、Pod が
hostNetworkをtrueに指定して設定されている場合にのみ機能します。
19.10.3. AdminPolicyBasedExternalRoute オブジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
次のプロパティーを使用して、クラスタースコープの AdminPolicyBasedExternalRoute オブジェクトを定義できます。namespace は、一度に 1 つの AdminPolicyBasedExternalRoute CR でのみ選択できます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
ルーティングポリシーが適用される namespace セレクターを指定します。外部トラフィックでは from:
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
namespace を対象にできるのは、1 つの |
|
|
|
パケットの転送先を指定します。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 静的 IP アドレスの配列を指定します。 |
|
|
| 外部ゲートウェイターゲットとして使用するネットワーク割り当て定義で設定された Pod に対応する Pod セレクターの配列を指定します。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| 次の宛先ホップの IPv4 アドレスまたは IPv6 アドレスを指定します。 |
|
|
|
オプション: ネットワークで双方向転送検出 (BFD) がサポートされているかどうかを指定します。デフォルト値は |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| [set-based](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) ラベルセレクターを指定して、このネットワークに一致する namespace 内の Pod をフィルターします設定。 |
|
|
|
|
|
|
|
オプション: ネットワークで双方向転送検出 (BFD) がサポートされているかどうかを指定します。デフォルト値は |
|
|
| オプション: ネットワーク接続定義の名前を指定します。名前は、Pod に関連付けられた論理ネットワークのリストと一致する必要があります。このフィールドが指定されていない場合は、Pod のホストネットワークが使用されます。ただし、ホストネットワークを使用するには、Pod をホストネットワーク Pod として設定する必要があります。 |
19.10.3.1. セカンダリー外部ゲートウェイ設定の例 リンクのコピーリンクがクリップボードにコピーされました!
次の例では、AdminPolicyBasedExternalRoute オブジェクトは、ラベルが kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059 の namespace 内にある Pod の外部ゲートウェイとして 2 つの静的 IP アドレスを設定します。
次の例では、AdminPolicyBasedExternalRoute オブジェクトが動的外部ゲートウェイを設定します。外部ゲートウェイに使用される IP アドレスは、選択した各 Pod に関連付けられた追加のネットワーク割り当てから派生します。
次の例では、AdminPolicyBasedExternalRoute オブジェクトは静的外部ゲートウェイと動的外部ゲートウェイの両方を設定します。
19.10.4. セカンダリー外部ゲートウェイの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の namespace のデフォルトネットワークに外部ゲートウェイを設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
-
AdminPolicyBasedExternalRouteオブジェクトを含む YAML ファイルを作成します。 管理ポリシーベースの外部ルートを作成するには、次のコマンドを入力します。
oc create -f <file>.yaml
$ oc create -f <file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<file>- 前の手順で作成した YAML ファイルの名前を指定します。
出力例
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 管理ポリシーベースの外部ルートが作成されたことを確認するには、次のコマンドを入力します。
oc describe apbexternalroute <name> | tail -n 6
$ oc describe apbexternalroute <name> | tail -n 6Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<name>-
AdminPolicyBasedExternalRouteオブジェクトの名前を指定します。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.5. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
- 追加のネットワーク接続の詳細は、複数のネットワークについて を参照してください。
19.11. Egress IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、1 つ以上の Egress IP アドレスを namespace に、または namespace 内の特定の pod に割り当てるように、OVN-Kubernetes の Container Network Interface (CNI) ネットワークプラグインを設定することができます。
現時点では、ROSA with HCP クラスターでは Egress IP の設定はサポートされていません。
19.11.1. Egress IP アドレスアーキテクチャーの設計および実装 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の Egress IP アドレス機能を使用すると、1 つ以上の namespace の 1 つ以上の Pod からのトラフィックに、クラスターネットワーク外のサービスに対する一貫したソース IP アドレスを持たせることができます。
たとえば、クラスター外のサーバーでホストされるデータベースを定期的にクエリーする Pod がある場合があります。サーバーにアクセス要件を適用するために、パケットフィルタリングデバイスは、特定の IP アドレスからのトラフィックのみを許可するよう設定されます。この特定の Pod のみからサーバーに確実にアクセスできるようにするには、サーバーに要求を行う Pod に特定の Egress IP アドレスを設定できます。
namespace に割り当てられた Egress IP アドレスは、特定の宛先にトラフィックを送信するために使用されるスロールーターとは異なります。
一部のクラスター設定では、アプリケーション Pod と Ingress ルーター Pod が同じノードで実行されます。このシナリオでアプリケーションプロジェクトの Egress IP アドレスを設定する場合、アプリケーションプロジェクトからルートに要求を送信するときに IP アドレスは使用されません。
Egress IP アドレスは、ifcfg-eth0 などのように Linux ネットワーク設定ファイルで設定することはできません。
19.11.1.1. プラットフォームサポート リンクのコピーリンクがクリップボードにコピーされました!
各種のプラットフォームでの Egress IP アドレス機能のサポートについては、以下の表で説明されています。
| プラットフォーム | サポート対象 |
|---|---|
| ベアメタル | はい |
| VMware vSphere | はい |
| Red Hat OpenStack Platform (RHOSP) | はい |
| Amazon Web Services (AWS) | はい |
| Google Cloud Platform (GCP) | はい |
| Microsoft Azure | はい |
| IBM Z® および IBM® LinuxONE | はい |
| IBM Z® および IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM | はい |
| IBM Power® | はい |
| Nutanix | はい |
EgressIP 機能を持つコントロールプレーンノードへの Egress IP アドレスの割り当ては、Amazon Web Services (AWS) でプロビジョニングされるクラスターではサポートされません。(BZ#2039656)。
19.11.1.2. パブリッククラウドプラットフォームに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
通常、パブリッククラウドプロバイダーは Egress IP に制限を設けています。つまり、パブリッククラウドインフラストラクチャー上にプロビジョニングされたクラスターでは、ノードごとに割り当て可能な IP アドレスの絶対数に制約があります。ノードごとに割り当て可能な IP アドレスの最大数、つまり IP 容量 は、次の式で表すことができます。
IP capacity = public cloud default capacity - sum(current IP assignments)
IP capacity = public cloud default capacity - sum(current IP assignments)
Egress IP 機能はノードごとの IP アドレス容量を管理しますが、デプロイメントでこの制約を計画することが重要です。たとえば、パブリッククラウドプロバイダーが IP アドレス容量をノードあたり 10 個に制限していて、ノードが 8 個ある場合、割り当て可能な IP アドレスの合計数は 80 個だけになります。IP アドレス容量を引き上げるには、追加のノードを割り当てる必要があります。たとえば、割り当て可能な IP アドレスが 150 個必要な場合は、7 つの追加のノードを割り当てる必要があります。
パブリッククラウド環境内の任意のノードの IP 容量とサブネットを確認するには、oc get node <node_name> -o yaml コマンドを入力します。cloud.network.openshift.io/egress-ipconfig アノテーションには、ノードの容量とサブネット情報が含まれています。
アノテーション値は、プライマリーネットワークインターフェイスに次の情報を提供するフィールドを持つ単一のオブジェクトを持つ配列です。
-
interface: AWS と Azure のインターフェイス ID と GCP のインターフェイス名を指定します。 -
ifaddr: 一方または両方の IP アドレスファミリーのサブネットマスクを指定します。 -
capacity: ノードの IP アドレス容量を指定します。AWS では、IP アドレス容量は IP アドレスファミリーごとに提供されます。Azure と GCP では、IP アドレスの容量には IPv4 アドレスと IPv6 アドレスの両方が含まれます。
ノード間のトラフィックの送信 IP アドレスの自動アタッチおよびデタッチが可能です。これにより、namespace 内の多くの Pod からのトラフィックが、クラスター外の場所への一貫した送信元 IP アドレスを持つことができます。これは、OpenShift Container Platform 4.16 の Red Hat OpenShift Networking におけるデフォルトのネットワーキングプラグインである OpenShift SDN および OVN-Kubernetes もサポートします。
RHOSP Egress IP アドレス機能は、egressip-<IP address> と呼ばれる Neutron 予約ポートを作成します。OpenShift Container Platform クラスターのインストールに使用したものと同じ RHOSP ユーザーを使用して、Floating IP アドレスをこの予約ポートに割り当て、Egress トラフィック用の予測可能な SNAT アドレスを指定できます。RHOSP ネットワーク上の Egress IP アドレスが、ノードのフェイルオーバーなどのためにあるノードから別のノードに移動されると、Neutron 予約ポートが削除され、再作成されます。これは、フローティング IP の関連付けが失われ、フローティング IP アドレスを新しい予約ポートに手動で再割り当てする必要があることを意味します。
RHOSP クラスター管理者が Floating IP を予約ポートに割り当てると、OpenShift Container Platform は予約ポートを削除できません。RHOSP クラスター管理者が予約ポートから Floating IP の割り当てを解除するまで、CloudPrivateIPConfig オブジェクトは削除および移動操作を実行できません。
次の例は、いくつかのパブリッククラウドプロバイダーのノードからのアノテーションを示しています。アノテーションは、読みやすくするためにインデントされています。
AWS での cloud.network.openshift.io/egress-ipconfig アノテーションの例
GCP での cloud.network.openshift.io/egress-ipconfig アノテーションの例
次のセクションでは、容量計算で使用するためにサポートされているパブリッククラウド環境の IP アドレス容量を説明します。
19.11.1.2.1. Amazon Web Services (AWS) の IP アドレス容量の制限 リンクのコピーリンクがクリップボードにコピーされました!
AWS では、IP アドレスの割り当てに関する制約は、設定されているインスタンスタイプによって異なります。詳細は、IP addresses per network interface per instance type を参照してください。
19.11.1.2.2. Google Cloud Platform (GCP) の IP アドレス容量の制限 リンクのコピーリンクがクリップボードにコピーされました!
GCP では、ネットワークモデルは、IP アドレスの割り当てではなく、IP アドレスのエイリアス作成を介して追加のノード IP アドレスを実装します。ただし、IP アドレス容量は IP エイリアス容量に直接マッピングされます。
IP エイリアスの割り当てには、次の容量制限があります。
- ノードごとに、IPv4 と IPv6 の両方の IP エイリアスの最大数は 100 です。
- VPC ごとに、IP エイリアスの最大数は指定されていませんが、OpenShift Container Platform のスケーラビリティーテストでは、最大数が約 15,000 であることが明らかになっています。
詳細は、インスタンスごと のクォータと エイリアス IP 範囲の概要 を参照してください。
19.11.1.2.3. Microsoft Azure IP アドレスの容量制限 リンクのコピーリンクがクリップボードにコピーされました!
Azure では、IP アドレスの割り当てに次の容量制限があります。
- NIC ごとに、IPv4 と IPv6 の両方で割り当て可能な IP アドレスの最大数は 256 です。
- 仮想ネットワークごとに、割り当てられる IP アドレスの最大数は 65,536 を超えることはできません。
詳細は、ネットワークの制限 を参照してください。
19.11.1.3. 追加のネットワークインターフェイスで Egress IP を使用する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、Egress IP は管理者にネットワークトラフィックを制御する方法を提供します。Egress IP は、Open vSwitch に関連付けられた Linux ブリッジインターフェイスである br-ex (プライマリー) ネットワークインターフェイスで使用することも、追加のネットワークインターフェイスで使用することもできます。
次のコマンドを実行して、ネットワークインターフェイスのタイプを検査できます。
ip -details link show
$ ip -details link show
プライマリーネットワークインターフェイスには、サブネットマスクも含まれるノード IP アドレスが割り当てられます。このノードの IP アドレスの情報は、k8s.ovn.org/node-primary-ifaddr アノテーションを検査して、クラスター内の各ノードの Kubernetes ノードオブジェクトから取得できます。IPv4 クラスターでは、このアノテーションは "k8s.ovn.org/node-primary-ifaddr: {"ipv4":"192.168.111.23/24"}" の例に似ています。
Egress IP がプライマリーネットワークインターフェイスのサブネット内にない場合は、プライマリーネットワークインターフェイスタイプではない別の Linux ネットワークインターフェイスで Egress IP を使用できます。これにより、OpenShift Container Platform 管理者は、ルーティング、アドレス指定、セグメンテーション、セキュリティーポリシーなどのネットワーク側面をより高度に制御できるようになります。この機能は、トラフィックのセグメント化や特殊な要件への対応などの目的で、ワークロードトラフィックを特定のネットワークインターフェイス経由でルーティングするオプションもユーザーに提供します。
Egress IP がプライマリーネットワークインターフェイスのサブネット内にない場合、ノード上に Egress トラフィック用の別のネットワークインターフェイスが存在すると、そのネットワークインターフェイスが選択される可能性があります。
k8s.ovn.org/host-cidrs Kubernetes ノードのアノテーションを検査することで、他のどのネットワークインターフェイスが Egress IP をサポートしているかを判断できます。このアノテーションには、プライマリーネットワークインターフェイスで見つかったアドレスとサブネットマスクが含まれています。また、追加のネットワークインターフェイスアドレスとサブネットマスク情報も含まれます。これらのアドレスとサブネットマスクは、最長接頭辞マッチルーティング メカニズムを使用して、どのネットワークインターフェイスが Egress IP をサポートするかを決定するネットワークインターフェイスに割り当てられます。
OVN-Kubernetes は、特定の namespace および Pod からのアウトバウンドネットワークトラフィックを制御および送信するメカニズムを提供します。これにより、特定のネットワークインターフェイス経由で、特定の Egress IP アドレスを使用してクラスターからトラフィックが出ていきます。
プライマリーネットワークインターフェイスではないネットワークインターフェイスに Egress IP を割り当てる場合の要件
Egress IP とトラフィックをプライマリーネットワークインターフェイスではない特定のインターフェイス経由でルーティングすることを希望する場合は、次の条件を満たす必要があります。
- OpenShift Container Platform がベアメタルクラスターにインストールされている。この機能は、クラウドまたはハイパーバイザー環境では無効になります。
- OpenShift Container Platform Pod はホストネットワークとして設定されていません。
- ネットワークインターフェイスが削除された場合、またはインターフェイス上で Egress IP をホストできるようにする IP アドレスとサブネットマスクが削除された場合、Egress IP は再設定されます。その結果、別のノードおよびインターフェイスに割り当てられる可能性があります。
ネットワークインターフェイスに対して IP フォワーディングを有効にする必要があります。IP 転送を有効にするには、
oc edit network.operatorコマンドを使用し、次の例のようにオブジェクトを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.11.1.4. Egress IP の Pod への割り当て リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上の Egress IP を namespace に、または namespace の特定の Pod に割り当てるには、以下の条件を満たす必要があります。
-
クラスター内の 1 つ以上のノードに
k8s.ovn.org/egress-assignable: ""ラベルがなければなりません。 -
EgressIPオブジェクトが存在し、これは namespace の Pod からクラスターを離脱するトラフィックのソース IP アドレスとして使用する 1 つ以上の Egress IP アドレスを定義します。
Egress IP の割り当て用にクラスター内のノードにラベルを付ける前に EgressIP オブジェクトを作成する場合、OpenShift Container Platform は k8s.ovn.org/egress-assignable: "" ラベルですべての Egress IP アドレスを最初のノードに割り当てる可能性があります。
Egress IP アドレスがクラスター内のノード全体に広く分散されるようにするには、EgressIP オブジェクトを作成する前に、Egress IP アドレスをホストする予定のノードにラベルを常に適用します。
19.11.1.5. Egress IP のノードへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
EgressIP オブジェクトを作成する場合、k8s.ovn.org/egress-assignable: "" ラベルのラベルが付いたノードに以下の条件が適用されます。
- Egress IP アドレスは一度に複数のノードに割り当てられることはありません。
- Egress IP アドレスは、Egress IP アドレスをホストできる利用可能なノード間で均等に分散されます。
EgressIPオブジェクトのspec.EgressIPs配列が複数の IP アドレスを指定する場合は、以下の条件が適用されます。- 指定された IP アドレスを複数ホストするノードはありません。
- トラフィックは、指定された namespace の指定された IP アドレス間でほぼ均等に分散されます。
- ノードが利用不可の場合、そのノードに割り当てられる Egress IP アドレスは自動的に再割り当てされます (前述の条件が適用されます)。
Pod が複数の EgressIP オブジェクトのセレクターに一致する場合、EgressIP オブジェクトに指定される Egress IP アドレスのどれが Pod の Egress IP アドレスとして割り当てられるのかという保証はありません。
さらに、EgressIP オブジェクトが複数の送信 IP アドレスを指定する場合、どの送信 IP アドレスが使用されるかは保証されません。たとえば、Pod が 10.10.20.1 と 10.10.20.2 の 2 つの Egress IP アドレスを持つ EgressIP オブジェクトのセレクターと一致する場合、各 TCP 接続または UDP 会話にいずれかが使用される可能性があります。
19.11.1.6. Egress IP アドレス設定のアーキテクチャー図 リンクのコピーリンクがクリップボードにコピーされました!
以下の図は、Egress IP アドレス設定を示しています。この図では、クラスターの 3 つのノードで実行される 2 つの異なる namespace の 4 つの Pod を説明します。ノードには、ホストネットワークの 192.168.126.0/18 CIDR ブロックから IP アドレスが割り当てられます。
ノード 1 とノード 3 の両方に k8s.ovn.org/egress-assignable: "" というラベルが付けられるため、Egress IP アドレスの割り当てに利用できます。
図の破線は、pod1、pod2、および pod3 からのトラフィックフローが Pod ネットワークを通過し、クラスターがノード 1 およびノード 3 から出る様子を示しています。外部サービスが、EgressIP オブジェクトの例で選択した Pod からトラフィックを受信する場合、送信元 IP アドレスは 192.168.126.10 または 192.168.126.102 のいずれかになります。トラフィックはこれらの 2 つのノード間でほぼ均等に分散されます。
図にある次のリソースの詳細を以下に示します。
Namespaceオブジェクトnamespace は以下のマニフェストで定義されます。
namespace オブジェクト
Copy to Clipboard Copied! Toggle word wrap Toggle overflow EgressIPオブジェクト以下の
EgressIPオブジェクトは、envラベルがprodに設定される namespace のすべての Pod を選択する設定を説明しています。選択された Pod の Egress IP アドレスは192.168.126.10および192.168.126.102です。EgressIPオブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 直前の例の設定の場合、OpenShift Container Platform は両方の Egress IP アドレスを利用可能なノードに割り当てます。
statusフィールドは、Egress IP アドレスの割り当ての有無および割り当てられる場所を反映します。
19.11.2. EgressIP オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は、EgressIP オブジェクトの API を説明しています。オブジェクトの範囲はクラスター全体です。これは namespace では作成されません。
以下の YAML は namespace セレクターのスタンザを説明しています。
namespace セレクタースタンザ
namespaceSelector:
matchLabels:
<label_name>: <label_value>
namespaceSelector:
matchLabels:
<label_name>: <label_value>
- 1
- namespace の 1 つ以上のマッチングルール。複数のマッチングルールを指定すると、一致するすべての namespace が選択されます。
以下の YAML は Pod セレクターのオプションのスタンザを説明しています。
Pod セレクタースタンザ
podSelector:
matchLabels:
<label_name>: <label_value>
podSelector:
matchLabels:
<label_name>: <label_value>
- 1
- オプション: 指定された
namespaceSelectorルールに一致する、namespace の Pod の 1 つ以上のマッチングルール。これが指定されている場合、一致する Pod のみが選択されます。namespace の他の Pod は選択されていません。
以下の例では、EgressIP オブジェクトは 192.168.126.11 および 192.168.126.102 Egress IP アドレスを、app ラベルが web に設定されており、env ラベルが prod に設定されている namespace にある Pod に関連付けます。
EgressIP オブジェクトの例
以下の例では、EgressIP オブジェクトは、192.168.127.30 および 192.168.127.40 Egress IP アドレスを、environment ラベルが development に設定されていない Pod に関連付けます。
EgressIP オブジェクトの例
19.11.3. egressIPConfig オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Egress IP の機能の 1 つとして、reachabilityTotalTimeoutSeconds パラメーターがあります。これは、EgressIP ノードの到達可能性チェックの合計タイムアウトを秒単位で設定します。このタイムアウト内に EgressIP ノードに到達できない場合、ノードはダウンしていると宣言されます。
reachabilityTotalTimeoutSeconds の値は、egressIPConfig オブジェクトの設定ファイルで設定できます。大きな値を設定すると、EgressIP 実装のノードの変更に対する反応が遅くなる可能性があります。問題が発生して到達できない EgressIP ノードに対しては、実装の反応が遅くなります。
egressIPConfig オブジェクトから reachabilityTotalTimeoutSeconds パラメーターを省略すると、適切なデフォルト値が選択されます。ただし、この値は時間が経過すると変更される可能性があります。現在のデフォルトは 1 秒です。値が 0 の場合、EgressIP ノードの到達可能性チェックは無効になります。
次の egressIPConfig オブジェクトでは、reachabilityTotalTimeoutSeconds をデフォルトの 1 秒プローブから 5 秒プローブに変更するよう指定しています。
19.11.4. Egress IP アドレスをホストするノードのラベル付け リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform が 1 つ以上の Egress IP アドレスをノードに割り当てることができるように、k8s.ovn.org/egress-assignable="" ラベルをクラスター内のノードに適用することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインします。
手順
1 つ以上の Egress IP アドレスをホストできるようにノードにラベルを付けるには、以下のコマンドを入力します。
oc label nodes <node_name> k8s.ovn.org/egress-assignable=""
$ oc label nodes <node_name> k8s.ovn.org/egress-assignable=""1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ラベルを付けるノードの名前。
ヒントまたは、以下の YAML を適用してラベルをノードに追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.11.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
19.12. Egress IP アドレスの割り当て リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、namespace または namespace の特定の Pod からクラスターを出るトラフィックに Egress IP アドレスを割り当てることができます。
19.12.1. Egress IP アドレスの namespace への割り当て リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上の Egress IP アドレスを namespace または namespace の特定の Pod に割り当てることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインします。
- Egress IP アドレスをホストするように 1 つ以上のノードを設定します。
手順
EgressIPオブジェクトを作成します。-
<egressips_name>.yamlファイルを作成します。<egressips_name>はオブジェクトの名前になります。 作成したファイルで、以下の例のように
EgressIPオブジェクトを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
オブジェクトを作成するには、以下のコマンドを入力します。
oc apply -f <egressips_name>.yaml
$ oc apply -f <egressips_name>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<egressips_name>をオブジェクトの名前に置き換えます。
出力例
egressips.k8s.ovn.org/<egressips_name> created
egressips.k8s.ovn.org/<egressips_name> createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: 後に変更できるように
<egressips_name>.yamlファイルを保存します。 Egress IP アドレスを必要とする namespace にラベルを追加します。手順 1 で定義した
EgressIPオブジェクトの namespace にラベルを追加するには、以下のコマンドを実行します。oc label ns <namespace> env=qa
$ oc label ns <namespace> env=qa1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>は、Egress IP アドレスを必要とする namespace に置き換えてください。
検証
クラスターで使用されているすべての Egress IP を表示するには、次のコマンドを入力します。
oc get egressip -o yaml
$ oc get egressip -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記oc get egressipコマンドは、設定されている数に関係なく、1 つの Egress IP アドレスのみを返します。これはバグではなく、Kubernetes の制限です。回避策として、-o yamlまたは-o jsonフラグを渡して、使用中のすべての Egress IP アドレスを返すことができます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.13. 出力サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Egress サービスを使用して、ロードバランサーサービスの背後にある Pod の Egress トラフィックを設定できます。
Egress サービスはテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
EgressService カスタムリソース (CR) を使用して、次の方法で送信トラフィックを管理できます。
ロードバランサーサービスの IP アドレスを、ロードバランサーサービスの背後にある Pod の送信トラフィックの送信元 IP アドレスとして割り当てます。
このコンテキストでは、ロードバランサーの IP アドレスを送信元 IP アドレスとして割り当てると、単一の Egress と Ingress を提供するのに役立ちます。たとえば、一部のシナリオでは、ロードバランサーサービスの背後でアプリケーションと通信する外部システムは、アプリケーションの送信元 IP アドレスと宛先 IP アドレスが同じであると想定できます。
注記ロードバランサーサービスの IP アドレスをサービスの背後にある Pod の Egress トラフィックに割り当てると、OVN-Kubernetes は Ingress ポイントと Egress ポイントを単一のノードに制限します。これにより、MetalLB が通常提供するトラフィックのロードバランシングが制限されます。
ロードバランサーの背後にある Pod の Egress トラフィックを、デフォルトノードネットワークとは異なるネットワークに割り当てます。
これは、ロードバランサーの背後にあるアプリケーションの Egress トラフィックを、デフォルトネットワークとは異なるネットワークに割り当てる場合に便利です。通常、別のネットワークは、ネットワークインターフェイスに関連付けられた VRF インスタンスを使用して実装されます。
19.13.1. Egress サービスのカスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
EgressService カスタムリソースで Egress サービスの設定を定義します。次の YAML は、egress サービスの設定のフィールドを説明します。
- 1
- Egress サービスの名前を指定します。
EgressServiceリソースの名前は、変更するロードバランサーサービスの名前と一致する必要があります。 - 2
- Egress サービスの namespace を指定します。
EgressServiceの namespace は、変更するロードバランサーサービスの namespace と一致する必要があります。Egress サービスは namespace スコープです。 - 3
- サービスの背後にある Pod の Egress トラフィックの送信元 IP アドレスを指定します。有効な値は、
LoadBalancerIPまたはNetworkです。LoadBalancerIP値を使用して、LoadBalancerサービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てます。ネットワークを指定して、ネットワークインターフェイス IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てます。 - 4
- オプション:
sourceIPBy指定にLoadBalancerIP値を使用する場合、単一ノードがLoadBalancerサービストラフィックを処理します。このタスクを割り当て可能なノードを制限するには、nodeSelectorフィールドを使用します。サービストラフィックを処理するノードが選択されると、OVN-Kubernetes はそのノードにegress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""という形式でラベルを付けます。nodeSelectorフィールドが指定されていない場合、どのノードでもLoadBalancerサービストラフィックを管理できます。 - 5
- オプション: Egress トラフィックのルーティングテーブル ID を指定します。必ず
NodeNetworkConfigurationPolicyリソースで定義されているroute-table-idID と一致する値を指定してください。network仕様を含めない場合、Egress サービスはデフォルトのホストネットワークを使用します。
Egress サービス仕様の例
19.13.2. Egress サービスのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Egress サービスをデプロイして、LoadBalancer サービスの背後にある Pod の Egress トラフィックを管理できます。
次の例では、LoadBalancer サービスの Ingress IP アドレスと同じ送信元 IP アドレスを持つように Egress トラフィックを設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 -
MetalLB
BGPPeerリソースを設定している。
手順
サービスに必要な IP を使用して
IPAddressPoolCR を作成します。次の例のような内容を含むファイル (
ip-addr-pool.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、IP アドレスプールの設定を適用します。
oc apply -f ip-addr-pool.yaml
$ oc apply -f ip-addr-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ServiceCR およびEgressServiceCR を作成します。次の例のような内容を含むファイル
(service-egress-service.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
LoadBalancerサービスは、example-poolIP アドレスプールから MetalLB によって割り当てられた IP アドレスを使用します。- 2
- この例では、
LoadBalancerIP値を使用して、LoadBalancerサービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てます。 - 3
LoadBalancerIP値を指定すると、単一ノードがLoadBalancerサービスのトラフィックを処理します。この例では、トラフィックを処理する場合にworkerラベルが割り当てられたノードのみを選択できます。ノードが選択されると、OVN-Kubernetes はそのノードにegress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""という形式でラベルを付けます。
注記sourceIPBy: "LoadBalancerIP"設定を使用する場合は、BGPAdvertisementカスタムリソース (CR) でロードバランサーノードを指定する必要があります。次のコマンドを実行して、サービスと Egress サービスの設定を適用します。
oc apply -f service-egress-service.yaml
$ oc apply -f service-egress-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGPAdvertisementCR を作成してサービスをアドバタイズします。次の例のような内容を含むファイル
(service-bgp-advertisement.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、
EgressServiceCR は、ロードバランサーサービス IP アドレスを使用するように、Egress トラフィックの送信元 IP アドレスを設定します。したがって、Pod から発信されるトラフィックに同じリターンパスを使用するには、リターントラフィックのロードバランサーノードを指定する必要があります。
検証
次のコマンドを実行して、MetalLB サービスの背後で実行されている Pod のアプリケーションエンドポイントにアクセスできることを確認します。
curl <external_ip_address>:<port_number>
$ curl <external_ip_address>:<port_number>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションのエンドポイントに合わせて外部 IP アドレスとポート番号を更新します。
-
LoadBalancerサービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てた場合は、tcpdumpなどのツールを使用して外部クライアントで受信したパケットを分析し、この設定を確認します。
19.14. Egress ルーター Pod の使用に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
19.14.1. Egress ルーター Pod について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Egress ルーター Pod は、他の用途で使用されていないプライベートソース IP アドレスから指定されたリモートサーバーにトラフィックをリダイレクトします。Egress ルーター Pod により、特定の IP アドレスからのアクセスのみを許可するように設定されたサーバーにネットワークトラフィックを送信できます。
Egress ルーター Pod はすべての発信接続のために使用されることが意図されていません。多数の Egress ルーター Pod を作成することで、ネットワークハードウェアの制限を引き上げられる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに Egress ルーター Pod を作成すると、ソフトウェアの MAC アドレスのフィルターに戻る前にネットワークインターフェイスが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。
Egress ルーターイメージには Amazon AWS, Azure Cloud またはレイヤー 2 操作をサポートしないその他のクラウドプラットフォームとの互換性がありません。それらに macvlan トラフィックとの互換性がないためです。
19.14.1.1. Egress ルーターモード リンクのコピーリンクがクリップボードにコピーされました!
リダイレクトモード では、Egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約された送信元 IP アドレスを使用する必要があるクライアント Pod は、宛先 IP に直接接続するのではなく、スロールーターのサービスにアクセスするように設定する必要があります。curl コマンドを使用して、アプリケーション Pod から宛先サービスとポートにアクセスできます。以下に例を示します。
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
Egress ルーター CNI プラグインはリダイレクトモードのみをサポートします。これは、OpenShift SDN でデプロイできる Egress ルーター実装の相違点です。OpenShift SDN の Egress ルーターとは異なり、Egress ルーター CNI プラグインは HTTP プロキシーモードまたは DNS プロキシーモードをサポートしません。
19.14.1.2. Egress ルーター Pod の実装 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーターの実装では、Egress ルーターの Container Network Interface (CNI) プラグインを使用します。プラグインはセカンダリーネットワークインターフェイスを Pod に追加します。
Egress ルーターは、2 つのネットワークインターフェイスを持つ Pod です。たとえば、Pod には、eth0 および net1 ネットワークインターフェイスを使用できます。eth0 インターフェイスはクラスターネットワークにあり、Pod は通常のクラスター関連のネットワークトラフィックにこのインターフェイスを引き続き使用します。net1 インターフェイスはセカンダリーネットワークにあり、そのネットワークの IP アドレスとゲートウェイを持ちます。OpenShift Container Platform クラスターの他の Pod は Egress ルーターサービスにアクセスでき、サービスにより Pod が外部サービスにアクセスできるようになります。Egress ルーターは、Pod と外部システム間のブリッジとして機能します。
Egress ルーターから出るトラフィックはノードで終了しますが、パケットには Egress ルーター Pod からの net1 インターフェイスの MAC アドレスがあります。
Egress ルーターのカスタムリソースを追加すると、Cluster Network Operator は以下のオブジェクトを作成します。
-
Pod の
net1セカンダリーネットワークインターフェイス用のネットワーク接続定義。 - Egress ルーターのデプロイメント。
Egress ルーターカスタムリソースを削除する場合、Operator は Egress ルーターに関連付けられた直前のリストの 2 つのオブジェクトを削除します。
19.14.1.3. デプロイメントに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーター Pod は追加の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェイスに追加します。その結果、ハイパーバイザーまたはクラウドプロバイダーを、追加のアドレスを許可するように設定する必要がある場合があります。
- Red Hat OpenStack Platform (RHOSP)
OpenShift Container Platform を RHOSP にデプロイする場合、OpenStack 環境の Egress ルーター Pod の IP および MAC アドレスからのトラフィックを許可する必要があります。トラフィックを許可しないと、通信は失敗 します。
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - VMware vSphere
- VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護に関する VMware ドキュメント を参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMware vSphere デフォルト設定を表示し、変更します。
とくに、以下が有効にされていることを確認します。
19.14.1.4. フェイルオーバー設定 リンクのコピーリンクがクリップボードにコピーされました!
ダウンタイムを回避するにために、Cluster Network Operator は Egress ルーター Pod をデプロイメントリソースとしてデプロイします。デプロイメント名は egress-router-cni-deployment です。デプロイメントに対応する Pod には app=egress-router-cni のラベルがあります。
デプロイメントの新規サービスを作成するには、oc expose deployment/egress-router-cni-deployment --port <port_number> コマンドを使用するか、以下のようにファイルを作成します。
19.15. リダイレクトモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを予約された送信元 IP アドレスから指定された宛先 IP アドレスにリダイレクトするように Egress ルーター Pod をデプロイできます。
Egress ルーターの実装では、Egress ルーターの Container Network Interface (CNI) プラグインを使用します。
19.15.1. Egress ルーターのカスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーターのカスタムリソースで Egress ルーター Pod の設定を定義します。以下の YAML は、リダイレクトモードでの Egress ルーターの設定のフィールドを説明しています。
- 1
- オプション:
namespaceフィールドは、Egress ルーターを作成するための namespace を指定します。ファイルまたはコマンドラインで値を指定しない場合には、defaultnamespace が使用されます。 - 2
addressesフィールドは、セカンダリーネットワークインターフェイスに設定する IP アドレスを指定します。- 3
ipフィールドは、ノードが Egress ルーター Pod と使用する物理ネットワークからの予約済み送信元 IP アドレスとネットマスクを指定します。CIDR 表記を使用して IP アドレスとネットマスクを指定します。- 4
gatewayフィールドは、ネットワークゲートウェイの IP アドレスを指定します。- 5
- オプション:
redirectRulesフィールドは、Egress 宛先 IP アドレス、Egress ルーターポート、およびプロトコルの組み合わせを指定します。指定されたポートとプロトコルでの Egress ルーターへの着信接続は、宛先 IP アドレスにルーティングされます。 - 6
- オプション:
targetPortフィールドは、宛先 IP アドレスのネットワークポートを指定します。このフィールドが指定されていない場合、トラフィックは到達したネットワークポートと同じネットワークポートにルーティングされます。 - 7
protocolフィールドは TCP、UDP、または SCTP をサポートします。- 8
- オプション:
fallbackIPフィールドは、宛先 IP アドレスを指定します。リダイレクトルールを指定しない場合、Egress ルーターはすべてのトラフィックをこのフォールバック IP アドレスに送信します。リダイレクトルールを指定する場合、ルールに定義されていないネットワークポートへの接続は、Egress ルーターによってこのフォールバック IP アドレスに送信されます。このフィールドを指定しない場合、Egress ルーターはルールで定義されていないネットワークポートへの接続を拒否します。
Egress ルーター仕様の例
19.15.2. リダイレクトモードでの Egress ルーターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーターをデプロイして、独自の予約済み送信元 IP アドレスから 1 つ以上の宛先 IP アドレスにトラフィックをリダイレクトできます。
Egress ルーターを追加した後に、予約済み送信元 IP アドレスを使用する必要のあるクライアント Pod は、宛先 IP に直接接続するのでなく、Egress ルーターに接続するように変更される必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Egress ルーター定義の作成
他の Pod が Egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、Egress ルーターを使用するサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Egress ルーターのラベルを指定します。表示されている値は Cluster Network Operator によって追加され、設定不可能です。
サービスの作成後に、Pod はサービスに接続できます。Egress ルーター Pod は、トラフィックを宛先 IP アドレスの対応するポートにリダイレクトします。接続は、予約された送信元 IP アドレスを起点とします。
検証
Cluster Network Operator が Egress ルーターを起動したことを確認するには、以下の手順を実行します。
Operator が Egress ルーター用に作成したネットワーク接続定義を表示します。
oc get network-attachment-definition egress-router-cni-nad
$ oc get network-attachment-definition egress-router-cni-nadCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク接続定義の名前は設定できません。
出力例
NAME AGE egress-router-cni-nad 18m
NAME AGE egress-router-cni-nad 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow Egress ルーター Pod のデプロイメントを表示します。
oc get deployment egress-router-cni-deployment
$ oc get deployment egress-router-cni-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントの名前は設定できません。
出力例
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18m
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow Egress ルーター Pod のステータスを表示します。
oc get pods -l app=egress-router-cni
$ oc get pods -l app=egress-router-cniCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18m
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18mCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Egress ルーター Pod のログとルーティングテーブルを表示します。
Egress ルーター Pod のノード名を取得します。
POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")$ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲットノードのデバッグセッションに入ります。この手順は、
<node_name>-debugというデバッグ Pod をインスタンス化します。oc debug node/$POD_NODENAME
$ oc debug node/$POD_NODENAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow /hostをデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストのルートファイルシステムをマウントします。ルートディレクトリーを/hostに変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。chroot /host
# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow chroot環境コンソール内から、Egress ルーターログを表示します。cat /tmp/egress-router-log
# cat /tmp/egress-router-logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この手順で説明されているように、
EgressRouterオブジェクトを作成して Egress ルーターを起動する場合、ロギングファイルの場所とロギングレベルは設定できません。chroot環境コンソール内で、コンテナー ID を取得します。crictl ps --name egress-router-cni-pod | awk '{print $1}'# crictl ps --name egress-router-cni-pod | awk '{print $1}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
CONTAINER bac9fae69ddb6
CONTAINER bac9fae69ddb6Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーのプロセス ID を判別します。この例では、コンテナー ID は
bac9fae69ddb6です。crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'# crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
68857
68857Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナーのネットワーク namespace を入力します。
nsenter -n -t 68857
# nsenter -n -t 68857Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルーティングテーブルを表示します。
ip route
# ip routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の出力例では、
net1ネットワークインターフェイスはデフォルトのルートです。クラスターネットワークのトラフィックはeth0ネットワークインターフェイスを使用します。192.168.12.0/24ネットワークのトラフィックは、net1ネットワークインターフェイスを使用し、予約された送信元 IP アドレス192.168.12.99を起点とします。Pod は他のすべてのトラフィックを IP アドレス192.168.12.1のゲートウェイにルーティングします。サービスネットワークのルーティングは表示されません。出力例
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.16. プロジェクトのマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
19.16.1. マルチキャストについて リンクのコピーリンクがクリップボードにコピーされました!
IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
- 現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。
-
デフォルトでは、ネットワークポリシーは namespace 内のすべての接続に影響します。ただし、マルチキャストはネットワークポリシーの影響を受けません。マルチキャストがネットワークポリシーと同じ namespace で有効にされている場合、
deny-allネットワークポリシーがある場合でも、マルチキャストは常に許可されます。クラスター管理者は、これを有効にする前に、ネットワークポリシーからマルチキャストが除外されることの影響を考慮する必要があります。
OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされます。OVN-Kubernetes ネットワークプラグインを使用している場合は、プロジェクトごとにマルチキャストを有効にできます。
19.16.2. Pod 間のマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。
<namespace>を、マルチキャストを有効にする必要のある namespace に置き換えます。oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true$ oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用してアノテーションを追加できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
マルチキャストがプロジェクトについて有効にされていることを確認するには、以下の手順を実行します。
現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。
<project>をプロジェクト名に置き換えます。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストレシーバーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストセンダーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいターミナルウィンドウまたはタブで、マルチキャストリスナーを起動します。
Pod の IP アドレスを取得します。
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、マルチキャストリスナーを起動します。
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マルチキャストトランスミッターを開始します。
Pod ネットワーク IP アドレス範囲を取得します。
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストメッセージを送信するには、以下のコマンドを入力します。
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.17. プロジェクトのマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
19.17.1. Pod 間のマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを無効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行して、マルチキャストを無効にします。
oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled-$ oc annotate namespace <namespace> \1 k8s.ovn.org/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチキャストを無効にする必要のあるプロジェクトの
namespace。
ヒントまたは、以下の YAML を適用してアノテーションを削除できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.18. ネットワークフローの追跡 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、以下の領域をサポートする、クラスターからの Pod ネットワークフローに関する情報を収集できます。
- Pod ネットワークで Ingress および Egress トラフィックをモニターします。
- パフォーマンスに関する問題のトラブルシューティング
- 容量計画およびセキュリティー監査に関するデータを収集します。
ネットワークフローのコレクションを有効にすると、トラフィックに関するメタデータのみが収集されます。たとえば、パケットデータは収集されませんが、プロトコル、ソースアドレス、宛先アドレス、ポート番号、バイト数、その他のパケットレベルの情報を収集します。
データは、以下の 1 つ以上のレコード形式で収集されます。
- NetFlow
- sFlow
- IPFIX
1 つ以上のコレクター IP アドレスおよびポート番号を使用して Cluster Network Operator (CNO) を設定する場合、Operator は各ノードで Open vSwitch (OVS) を設定し、ネットワークフローレコードを各コレクターに送信します。
Operator を、複数のネットワークフローコレクターにレコードを送信するように設定できます。たとえば、レコードを NetFlow コレクターに送信し、レコードを sFlow コレクターに送信することもできます。
OVS がデータをコレクターに送信すると、それぞれのタイプのコレクターは同一レコードを受け取ります。たとえば、2 つの NetFlow コレクターを設定すると、ノード上の OVS は同じレコードを 2 つのコレクターに送信します。また、2 つの sFlow コレクターを設定した場合には、2 つの sFlow コレクターが同じレコードを受け取ります。ただし、各コレクタータイプには固有のレコード形式があります。
ネットワークフローデータを収集し、レコードをコレクターに送信すると、パフォーマンスに影響があります。ノードは低速でパケットを処理します。パフォーマンスへの影響が大きすぎる場合は、コレクターの宛先を削除し、ネットワークフローデータの収集を無効にしてパフォーマンスを回復できます。
ネットワークフローコレクターを有効にすると、クラスターネットワークの全体的なパフォーマンスに影響を与える可能性があります。
19.18.1. ネットワークフローを追跡するためのネットワークオブジェクト設定 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator (CNO) でネットワークフローコレクターを設定するフィールドを以下の表に示します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
CNO オブジェクトの名前。この名前は常に |
|
|
|
1 つ以上の |
|
|
| 最大 10 コレクターの IP アドレスとネットワークポートのペアのリスト。 |
|
|
| 最大 10 コレクターの IP アドレスとネットワークポートのペアのリスト。 |
|
|
| 最大 10 コレクターの IP アドレスとネットワークポートのペアのリスト。 |
以下のマニフェストを CNO に適用した後に、Operator は、192.168.1.99:2056 でリッスンする NetFlow コレクターにネットワークフローレコードを送信するようにクラスター内の各ノードで Open vSwitch (OVS) を設定します。
ネットワークフローを追跡するための設定例
19.18.2. ネットワークフローコレクターの宛先の追加 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者として、Cluster Network Operator (CNO) を設定して、Pod ネットワークに関するネットワークフローメタデータのネットワークフローコレクターへの送信を停止することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - ネットワークフローコレクターがあり、リッスンする IP アドレスとポートを把握している。
手順
ネットワークフローコレクターのタイプおよびコレクターの IP アドレスとポート情報を指定するパッチファイルを作成します。
spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークフローコレクターで CNO を設定します。
oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
$ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
検証は通常必須ではありません。以下のコマンドを実行して、各ノードの Open vSwitch (OVS) がネットワークフローレコードを 1 つ以上のコレクターに送信するように設定されていることを確認できます。
Operator 設定を表示して、
exportNetworkFlowsフィールドが設定されていることを確認します。oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"$ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"netFlow":{"collectors":["192.168.1.99:2056"]}}{"netFlow":{"collectors":["192.168.1.99:2056"]}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードから OVS のネットワークフロー設定を表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.18.3. ネットワークフローコレクターのすべての宛先の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者として、Cluster Network Operator (CNO) を設定して、ネットワークフローメタデータのネットワークフローコレクターへの送信を停止することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
すべてのネットワークフローコレクターを削除します。
oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'$ oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.19. ハイブリッドネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインを設定して、Linux および Windows ノードがそれぞれ Linux および Windows ワークロードをホストできるようにすることができます。
19.19.1. OVN-Kubernetes を使用したハイブリッドネットワークの設定 リンクのコピーリンクがクリップボードにコピーされました!
OVN-Kubernetes ネットワークプラグインを使用してハイブリッドネットワークを使用するようにクラスターを設定できます。これにより、異なるノードのネットワーク設定をサポートするハイブリッドクラスターが可能になります。
この設定は、同じクラスター内で Linux ノードと Windows ノードの両方を実行するために必要です。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 - クラスターが OVN-Kubernetes ネットワークプラグインを使用していることを確認します。
手順
OVN-Kubernetes ハイブリッドネットワークオーバーレイを設定するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
cidr- 追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。この CIDR は、クラスターネットワーク CIDR と重複させることはできません。
hostPrefix-
それぞれの個別ノードに割り当てるサブネット接頭辞の長さを指定します。たとえば、
hostPrefixが23に設定されている場合、各ノードに指定のcidrから/23サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。 hybridOverlayVXLANPort-
追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの
4789ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。
注記Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの
hybridOverlayVXLANPort値を持つクラスターではサポートされません。出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。
oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"$ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第20章 OpenShift SDN ネットワークプラグイン リンクのコピーリンクがクリップボードにコピーされました!
20.1. OpenShift SDN ネットワークプラグインについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Networking の一部である OpenShift SDN は、ソフトウェア定義ネットワーキング (SDN) アプローチを使用して、OpenShift Container Platform クラスター全体の Pod 間の通信を可能にする統合クラスターネットワークを提供するネットワークプラグインです。OpenShift SDN により、このような Pod ネットワークが確立され、メンテナンスされます。OpenShift SDN は Open vSwitch (OVS) を使用してオーバーレイネットワークを設定します。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.1.1. OpenShift SDN ネットワーク分離モード リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN では以下のように、Pod ネットワークを設定するための SDN モードを 3 つ提供します。
-
ネットワークポリシーモードは、プロジェクト管理者が
NetworkPolicyオブジェクトを使用して独自の分離ポリシーを設定することを可能にします。ネットワークポリシーは、OpenShift Container Platform 4.16 のデフォルトモードです。 - マルチテナント モードは、Pod およびサービスのプロジェクトレベルの分離を可能にします。異なるプロジェクトの Pod は、別のプロジェクトの Pod およびサービスとパケットの送受信をすることができなくなります。プロジェクトの分離を無効にし、クラスター全体のすべての Pod およびサービスにネットワークトラフィックを送信したり、それらの Pod およびサービスからネットワークトラフィックを受信したりすることができます。
- サブネット モードは、すべての Pod が他のすべての Pod およびサービスと通信できる Pod ネットワークを提供します。ネットワークポリシーモードは、サブネットモードと同じ機能を提供します。
20.1.2. サポートされているネットワークプラグイン機能のマトリックス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Networking は、ネットワークプラグイン用に OpenShift SDN と OVN-Kubernetes の 2 つのオプションを提供します。以下の表は、両方のネットワークプラグインの現在の機能サポートをまとめたものです。
| 機能 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| Egress IP | サポート対象 | サポート対象 |
| Egress ファイアウォール | サポート対象 | サポート対象 [1] |
| Egress ルーター | サポート対象 | サポート対象 [2] |
| ハイブリッドネットワーク | サポート対象外 | サポート対象 |
| クラスター内通信の IPsec 暗号化 | サポート対象外 | サポート対象 |
| IPv4 シングルスタック | サポート対象 | サポート対象 |
| IPv6 シングルスタック | サポート対象外 | サポート対象 [3] |
| IPv4/IPv6 デュアルスタック | サポート対象外 | サポート対象 [4] |
| IPv6/IPv4 デュアルスタック | サポート対象外 | サポート対象 [5] |
| Kubernetes ネットワークポリシー | サポート対象 | サポート対象 |
| Kubernetes ネットワークポリシーログ | サポート対象外 | サポート対象 |
| ハードウェアのオフロード | サポート対象外 | サポート対象 |
| マルチキャスト | サポート対象 | サポート対象 |
- Egress ファイアウォールは、OpenShift SDN では Egress ネットワークポリシーとしても知られています。これはネットワークポリシーの Egress とは異なります。
- OVN-Kubernetes の Egress ルーターはリダイレクトモードのみをサポートします。
- ベアメタルプラットフォーム上の IPv6 シングルスタックネットワーキング。
- ベアメタル、VMware vSphere (installer-provisioned infrastructure インストールのみ)、IBM Power®、IBM Z®、および RHOSP プラットフォーム上の IPv4/IPv6 または IPv6/IPv4 デュアルスタックネットワーク。
- ベアメタル、VMware vSphere (インストーラープロビジョニングインフラストラクチャーのインストールのみ)、および IBM Power® プラットフォーム上の IPv6/IPv4 デュアルスタックネットワーク。
20.2. プロジェクトの Egress IP の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift SDN の Container Network Interface (CNI) ネットワークプラグインが 1 つ以上の Egress IP アドレスをプロジェクトに割り当てるように設定できます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.2.1. Egress IP アドレスアーキテクチャーの設計および実装 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の Egress IP アドレス機能を使用すると、1 つ以上の namespace の 1 つ以上の Pod からのトラフィックに、クラスターネットワーク外のサービスに対する一貫したソース IP アドレスを持たせることができます。
たとえば、クラスター外のサーバーでホストされるデータベースを定期的にクエリーする Pod がある場合があります。サーバーにアクセス要件を適用するために、パケットフィルタリングデバイスは、特定の IP アドレスからのトラフィックのみを許可するよう設定されます。この特定の Pod のみからサーバーに確実にアクセスできるようにするには、サーバーに要求を行う Pod に特定の Egress IP アドレスを設定できます。
namespace に割り当てられた Egress IP アドレスは、特定の宛先にトラフィックを送信するために使用されるスロールーターとは異なります。
一部のクラスター設定では、アプリケーション Pod と Ingress ルーター Pod が同じノードで実行されます。このシナリオでアプリケーションプロジェクトの Egress IP アドレスを設定する場合、アプリケーションプロジェクトからルートに要求を送信するときに IP アドレスは使用されません。
Egress IP アドレスは、ノードのプライマリーネットワークインターフェイスの追加 IP アドレスとして実装され、ノードのプライマリー IP アドレスと同じサブネットにある必要があります。追加の IP アドレスは、クラスター内の他のノードには割り当てないでください。
Egress IP アドレスは、ifcfg-eth0 などのように Linux ネットワーク設定ファイルで設定することはできません。
20.2.1.1. プラットフォームサポート リンクのコピーリンクがクリップボードにコピーされました!
各種のプラットフォームでの Egress IP アドレス機能のサポートについては、以下の表で説明されています。
| プラットフォーム | サポート対象 |
|---|---|
| ベアメタル | はい |
| VMware vSphere | はい |
| Red Hat OpenStack Platform (RHOSP) | はい |
| Amazon Web Services (AWS) | はい |
| Google Cloud Platform (GCP) | はい |
| Microsoft Azure | はい |
| IBM Z® および IBM® LinuxONE | はい |
| IBM Z® および IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM | はい |
| IBM Power® | はい |
| Nutanix | はい |
EgressIP 機能を持つコントロールプレーンノードへの Egress IP アドレスの割り当ては、Amazon Web Services (AWS) でプロビジョニングされるクラスターではサポートされません。(BZ#2039656)。
20.2.1.2. パブリッククラウドプラットフォームに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
通常、パブリッククラウドプロバイダーは Egress IP に制限を設けています。つまり、パブリッククラウドインフラストラクチャー上にプロビジョニングされたクラスターでは、ノードごとに割り当て可能な IP アドレスの絶対数に制約があります。ノードごとに割り当て可能な IP アドレスの最大数、つまり IP 容量 は、次の式で表すことができます。
IP capacity = public cloud default capacity - sum(current IP assignments)
IP capacity = public cloud default capacity - sum(current IP assignments)
Egress IP 機能はノードごとの IP アドレス容量を管理しますが、デプロイメントでこの制約を計画することが重要です。たとえば、パブリッククラウドプロバイダーが IP アドレス容量をノードあたり 10 個に制限していて、ノードが 8 個ある場合、割り当て可能な IP アドレスの合計数は 80 個だけになります。IP アドレス容量を引き上げるには、追加のノードを割り当てる必要があります。たとえば、割り当て可能な IP アドレスが 150 個必要な場合は、7 つの追加のノードを割り当てる必要があります。
パブリッククラウド環境内の任意のノードの IP 容量とサブネットを確認するには、oc get node <node_name> -o yaml コマンドを入力します。cloud.network.openshift.io/egress-ipconfig アノテーションには、ノードの容量とサブネット情報が含まれています。
アノテーション値は、プライマリーネットワークインターフェイスに次の情報を提供するフィールドを持つ単一のオブジェクトを持つ配列です。
-
interface: AWS と Azure のインターフェイス ID と GCP のインターフェイス名を指定します。 -
ifaddr: 一方または両方の IP アドレスファミリーのサブネットマスクを指定します。 -
capacity: ノードの IP アドレス容量を指定します。AWS では、IP アドレス容量は IP アドレスファミリーごとに提供されます。Azure と GCP では、IP アドレスの容量には IPv4 アドレスと IPv6 アドレスの両方が含まれます。
ノード間のトラフィックの送信 IP アドレスの自動アタッチおよびデタッチが可能です。これにより、namespace 内の多くの Pod からのトラフィックが、クラスター外の場所への一貫した送信元 IP アドレスを持つことができます。これは、OpenShift Container Platform 4.16 の Red Hat OpenShift Networking におけるデフォルトのネットワーキングプラグインである OpenShift SDN および OVN-Kubernetes もサポートします。
RHOSP Egress IP アドレス機能は、egressip-<IP address> と呼ばれる Neutron 予約ポートを作成します。OpenShift Container Platform クラスターのインストールに使用したものと同じ RHOSP ユーザーを使用して、Floating IP アドレスをこの予約ポートに割り当て、Egress トラフィック用の予測可能な SNAT アドレスを指定できます。RHOSP ネットワーク上の Egress IP アドレスが、ノードのフェイルオーバーなどのためにあるノードから別のノードに移動されると、Neutron 予約ポートが削除され、再作成されます。これは、フローティング IP の関連付けが失われ、フローティング IP アドレスを新しい予約ポートに手動で再割り当てする必要があることを意味します。
RHOSP クラスター管理者が Floating IP を予約ポートに割り当てると、OpenShift Container Platform は予約ポートを削除できません。RHOSP クラスター管理者が予約ポートから Floating IP の割り当てを解除するまで、CloudPrivateIPConfig オブジェクトは削除および移動操作を実行できません。
次の例は、いくつかのパブリッククラウドプロバイダーのノードからのアノテーションを示しています。アノテーションは、読みやすくするためにインデントされています。
AWS での cloud.network.openshift.io/egress-ipconfig アノテーションの例
GCP での cloud.network.openshift.io/egress-ipconfig アノテーションの例
次のセクションでは、容量計算で使用するためにサポートされているパブリッククラウド環境の IP アドレス容量を説明します。
20.2.1.2.1. Amazon Web Services (AWS) の IP アドレス容量の制限 リンクのコピーリンクがクリップボードにコピーされました!
AWS では、IP アドレスの割り当てに関する制約は、設定されているインスタンスタイプによって異なります。詳細は、IP addresses per network interface per instance type を参照してください。
20.2.1.2.2. Google Cloud Platform (GCP) の IP アドレス容量の制限 リンクのコピーリンクがクリップボードにコピーされました!
GCP では、ネットワークモデルは、IP アドレスの割り当てではなく、IP アドレスのエイリアス作成を介して追加のノード IP アドレスを実装します。ただし、IP アドレス容量は IP エイリアス容量に直接マッピングされます。
IP エイリアスの割り当てには、次の容量制限があります。
- ノードごとに、IPv4 と IPv6 の両方の IP エイリアスの最大数は 100 です。
- VPC ごとに、IP エイリアスの最大数は指定されていませんが、OpenShift Container Platform のスケーラビリティーテストでは、最大数が約 15,000 であることが明らかになっています。
詳細は、インスタンスごと のクォータと エイリアス IP 範囲の概要 を参照してください。
20.2.1.2.3. Microsoft Azure IP アドレスの容量制限 リンクのコピーリンクがクリップボードにコピーされました!
Azure では、IP アドレスの割り当てに次の容量制限があります。
- NIC ごとに、IPv4 と IPv6 の両方で割り当て可能な IP アドレスの最大数は 256 です。
- 仮想ネットワークごとに、割り当てられる IP アドレスの最大数は 65,536 を超えることはできません。
詳細は、ネットワークの制限を参照してください。
20.2.1.3. 制限事項 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN ネットワークプラグインで egress IP アドレスを使用する場合、次の制限が適用されます。
- 手動で割り当てられた Egress IP アドレスと、自動的に割り当てられた Egress IP アドレスは同じノードで使用することができません。
- IP アドレス範囲から Egress IP アドレスを手動で割り当てる場合、その範囲を自動の IP 割り当てで利用可能にすることはできません。
- OpenShift SDN Egress IP アドレス実装を使用して、複数の namespace で Egress IP アドレスを共有することはできません。
複数の namespace 間で IP アドレスを共有する必要がある場合は、OVN-Kubernetes ネットワークプラグインの Egress IP アドレスの実装により、複数の namespace で IP アドレスを共有できます。
OpenShift SDN をマルチテナントモードで使用する場合、それらに関連付けられたプロジェクトによって別の namespace に参加している namespace と共に Egress IP アドレスを使用することはできません。たとえば、project1 および project2 に oc adm pod-network join-projects --to=project1 project2 コマンドを実行して参加している場合、どちらもプロジェクトも Egress IP アドレスを使用できません。詳細は、BZ#1645577 を参照してください。
20.2.1.4. IP アドレス割り当てアプローチ リンクのコピーリンクがクリップボードにコピーされました!
Egress IP アドレスは、NetNamespace オブジェクトの egressIPs パラメーターを設定して namespace に割り当てることができます。Egress IP アドレスがプロジェクトに関連付けられた後に、OpenShift SDN は 2 つの方法で Egress IP アドレスをホストに割り当てることを可能にします。
- 自動的に割り当てる 方法では、Egress IP アドレス範囲はノードに割り当てられます。
- 手動で割り当てる 方法では、1 つ以上の Egress IP アドレスのリストがノードに割り当てられます。
Egress IP アドレスを要求する namespace は、それらの Egress IP アドレスをホストできるノードに一致し、Egress IP アドレスはそれらのノードに割り当てられます。egressIPs パラメーターが NetNamespace オブジェクトに設定されるものの、ノードがその Egress IP アドレスをホストしない場合、namespace からの Egress トラフィックはドロップされます。
ノードの高可用性は自動的に実行されます。Egress IP アドレスをホストするノードが到達不可能であり、Egress IP アドレスをホストできるノードがある場合、Egress IP アドレスは新規ノードに移行します。到達不可能なノードが再びオンラインに戻ると、ノード間で Egress IP アドレスのバランスを図るために Egress IP アドレスは自動的に移行します。
20.2.1.4.1. 自動的に割り当てられた Egress IP アドレスを使用する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
Egress IP アドレスの自動割り当て方法を使用する場合、以下の考慮事項が適用されます。
-
各ノードの
HostSubnetリソースのegressCIDRsパラメーターを設定して、ノードでホストできる Egress IP アドレスの範囲を指定します。OpenShift Container Platform は、指定する IP アドレス範囲に基づいてHostSubnetリソースのegressIPsパラメーターを設定します。
namespace の Egress IP アドレスをホストするノードに到達できない場合、OpenShift Container Platform は互換性のある Egress IP アドレス範囲を持つ別のノードに Egress IP アドレスを再割り当てします。自動割り当て方法は、追加の IP アドレスをノードに関連付ける柔軟性のある環境にインストールされたクラスターに最も適しています。
20.2.1.4.2. 手動で割り当てられた Egress IP アドレスを使用する場合の考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
このアプローチにより、Egress IP アドレスをホストできるノードを制御できます。
クラスターがパブリッククラウドインフラストラクチャーにインストールされている場合は、Egress IP アドレスを割り当てる各ノードに、IP アドレスをホストするための十分な予備容量があることを確認する必要があります。詳細は、前のセクションの「プラットフォームに関する考慮事項」を参照してください。
Egress IP アドレスに手動割り当て方法を使用する場合、以下の考慮事項が適用されます。
-
各ノードの
HostSubnetリソースのegressIPsパラメーターを設定して、ノードでホストできる IP アドレスを指定します。 - namespace ごとに複数の Egress IP アドレスがサポートされます。
namespace に複数の Egress IP アドレスがあり、それらのアドレスが複数のノードでホストされる場合、以下の追加の考慮事項が適用されます。
- Pod が Egress IP アドレスをホストするノード上にある場合、その Pod はノード上の Egress IP アドレスを常に使用します。
- Pod が Egress IP アドレスをホストするノードにない場合、その Pod はランダムで Egress IP アドレスを使用します。
20.2.2. namespace の自動的に割り当てられた Egress IP アドレスの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、1 つ以上のノードで特定の namespace の Egress IP アドレスの自動的な割り当てを有効にできます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
以下の JSON を使用して、
NetNamespaceオブジェクトを Egress IP アドレスで更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<project_name>- プロジェクトの名前を指定します。
<ip_address>-
egressIPs配列の 1 つ以上の Egress IP アドレスを指定します。
たとえば、
project1を IP アドレスの 192.168.1.100 に、project2を IP アドレスの 192.168.1.101 に割り当てるには、以下を実行します。oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'$ oc patch netnamespace project1 --type=merge -p \ '{"egressIPs": ["192.168.1.100"]}' $ oc patch netnamespace project2 --type=merge -p \ '{"egressIPs": ["192.168.1.101"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift SDN は
NetNamespaceオブジェクトを管理するため、既存のNetNamespaceオブジェクトを変更することによってのみ変更を加えることができます。新規NetNamespaceオブジェクトは作成しません。以下の JSON を使用して、各ホストの
egressCIDRsパラメーターを設定して Egress IP アドレスをホストできるノードを示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node_name>- ノード名を指定します。
<ip_address_range>-
CIDR 形式の IP アドレス範囲を指定します。
egressCIDRs配列に複数のアドレス範囲を指定できます。
たとえば、
node1およびnode2を、192.168.1.0 から 192.168.1.255 の範囲で Egress IP アドレスをホストするように設定するには、以下を実行します。oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}' $ oc patch hostsubnet node2 --type=merge -p \ '{"egressCIDRs": ["192.168.1.0/24"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform はバランスを取りながら特定の Egress IP アドレスを利用可能なノードに自動的に割り当てます。この場合、Egress IP アドレス 192.168.1.100 を
node1に、Egress IP アドレス 192.168.1.101 をnode2に割り当て、その逆も行います。
20.2.3. namespace の手動で割り当てられた Egress IP アドレスの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で、1 つ以上の Egress IP アドレスを namespace に関連付けることができます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
以下の JSON オブジェクトを必要な IP アドレスで指定して、
NetNamespaceオブジェクトを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<project_name>- プロジェクトの名前を指定します。
<ip_address>-
egressIPs配列の 1 つ以上の Egress IP アドレスを指定します。
たとえば、
project1プロジェクトを IP アドレス192.168.1.100および192.168.1.101に割り当てるには、以下を実行します。oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'$ oc patch netnamespace project1 --type=merge \ -p '{"egressIPs": ["192.168.1.100","192.168.1.101"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 高可用性を提供するには、
egressIPsの値を異なるノードの 2 つ以上の IP アドレスに設定します。複数の Egress IP アドレスが設定されている場合、Pod はすべての Egress IP アドレスをほぼ均等に使用します。注記OpenShift SDN は
NetNamespaceオブジェクトを管理するため、既存のNetNamespaceオブジェクトを変更することによってのみ変更を加えることができます。新規NetNamespaceオブジェクトは作成しません。Egress IP アドレスをノードホストに手動で割り当てます。
クラスターがパブリッククラウドインフラストラクチャーにインストールされている場合は、ノードに使用可能な IP アドレス容量があることを確認する必要があります。
egressIPsパラメーターを、ノードホストのHostSubnetオブジェクトに設定します。以下の JSON を使用して、そのノードホストに割り当てる必要のある任意の数の IP アドレスを含めることができます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<node_name>- ノード名を指定します。
<ip_address>-
IP アドレスを指定します。
egressIPs配列に複数の IP アドレスを指定できます。
たとえば、
node1に Egress IP192.168.1.100、192.168.1.101、および192.168.1.102が設定されるように指定するには、以下を実行します。oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'$ oc patch hostsubnet node1 --type=merge -p \ '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前の例では、
project1のすべての Egress トラフィックは、指定された Egress IP をホストするノードにルーティングされてから、その IP アドレスに Network Address Translation (NAT) を使用して接続されます。
20.2.4. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
- 手動の Egress IP アドレス割り当てを設定している場合は、IP 容量計画の情報について、プラットフォームの考慮事項を参照してください。
20.3. プロジェクトの Egress ファイアウォールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、Egress トラフィックを制限する Egress ファイアウォールを作成できます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.3.1. Egress ファイアウォールのプロジェクトでの機能 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーは以下のシナリオをサポートします。
- Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
- Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
- Pod は OpenShift Container Platform クラスター外の指定された内部サブネットまたはホストにアクセスできません。
- Pod は特定の外部ホストにのみ接続することができます。
たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者が Python pip ミラーから更新するのを制限し、承認されたソースからのみ更新が行われるように強制することもできます。
Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。
EgressNetworkPolicy カスタムリソース (CR) オブジェクトを作成して Egress ファイアウォールポリシーを設定します。Egress ファイアウォールは、以下のいずれかの基準を満たすネットワークトラフィックと一致します。
- CIDR 形式の IP アドレス範囲。
- IP アドレスに解決する DNS 名
Egress ファイアウォールに 0.0.0.0/0 の拒否ルールが含まれる場合、OpenShift Container Platform API サーバーへのアクセスはブロックされます。API サーバーに接続するには、IP アドレスごとに許可ルールを追加するか、Egress ポリシールールで nodeSelector タイプの許可ルールを使用する必要があります。
次の例は、API サーバーへのアクセスを確保するために必要な Egress ファイアウォールルールの順序を示しています。
API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。
詳細は、BZ#1988324 を参照してください。
Egress ファイアウォールを設定するには、ネットワークポリシーまたはマルチテナントモードのいずれかを使用するように OpenShift SDN を設定する必要があります。
ネットワークポリシーモードを使用している場合、Egress ファイアウォールは namespace ごとに 1 つのポリシーとのみ互換性を持ち、グローバルプロジェクトなどのネットワークを共有するプロジェクトでは機能しません。
Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。
20.3.1.1. Egress ファイアウォールの制限 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールには以下の制限があります。
いずれのプロジェクトも複数の EgressNetworkPolicy オブジェクトを持つことができません。
重要複数の EgressNetworkPolicy オブジェクトの作成は可能ですが、作成するべきではありません。複数の EgressNetworkPolicy オブジェクトを作成すると、
dropping all rulesというメッセージが返されます。実際には、すべての外部トラフィックがドロップされるため、組織にセキュリティーリスクが生じる可能性があります。- 最大 1,000 のルールを持つ最大 1 つの EgressNetworkPolicy オブジェクトはプロジェクトごとに定義できます。
-
defaultプロジェクトは Egress ファイアウォールを使用できません。 マルチテナントモードで OpenShift SDN ネットワークプラグインを使用する場合、以下の制限が適用されます。
-
グローバルプロジェクトは Egress ファイアウォールを使用できません。
oc adm pod-network make-projects-globalコマンドを使用して、プロジェクトをグローバルにすることができます。 -
oc adm pod-network join-projectsコマンドを使用してマージされるプロジェクトでは、結合されたプロジェクトのいずれでも Egress ファイアウォールを使用することはできません。
-
グローバルプロジェクトは Egress ファイアウォールを使用できません。
-
セレクターレスサービスを作成し、外部 IP を参照するエンドポイントまたは
EndpointSlicesを手動で定義すると、EgressNetworkPolicyがすべての Egress トラフィックを拒否するように設定されている場合でも、サービス IP へのトラフィックが引き続き許可される可能性があります。これは、OpenShift SDN がこのような外部エンドポイントに対して Egress ネットワークポリシーを完全に適用していないために発生します。その結果、外部サービスへの予期しないアクセスが発生する可能性があります。
これらの制限のいずれかに違反すると、プロジェクトの Egress ファイアウォールが壊れます。その結果、すべての外部ネットワークトラフィックがドロップされ、組織にセキュリティーリスクが生じる可能性があります。
Egress ファイアウォールリソースは、kube-node-lease、kube-public、kube-system、openshift、openshift- プロジェクトで作成できます。
20.3.1.2. Egress ポリシールールのマッチング順序 リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの Egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。
20.3.1.3. DNS (Domain Name Server) 解決の仕組み リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。
- ドメイン名の更新は、Time-to-Live (TTL) 期間に基づいてポーリングされます。デフォルトの期間は 30 秒です。Egress ファイアウォールコントローラーがローカルネームサーバーでドメイン名をクエリーする場合に、応答に 30 秒未満の TTL が含まれる場合は、コントローラーはその期間を返される値に設定します。応答の TTL が 30 分を超える場合、コントローラーは期間を 30 分に設定します。TTL が 30 秒から 30 分の間に設定される場合、コントローラーは値を無視し、期間を 30 秒に設定します。
- Pod は、必要に応じて同じローカルネームサーバーからドメインを解決する必要があります。そうしない場合、Egress ファイアウォールコントローラーと Pod によって認識されるドメインの IP アドレスが異なる可能性があります。ホスト名の IP アドレスが異なる場合、Egress ファイアウォールは一貫して実行されないことがあります。
- Egress ファイアウォールコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod は Egress コントローラーが実行する前に更新された IP アドレスを取得する可能性があります。これにより、競合状態が生じます。この現時点の制限により、EgressNetworkPolicy オブジェクトのドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。
Egress ファイアウォールポリシーで DNS 名を使用しても、CoreDNS を介したローカル DNS 解決には影響しません。
ただし、Egress ファイアウォールポリシーでドメイン名を使用し、外部 DNS サーバーで関連する Pod の DNS 解決を処理する場合は、DNS サーバーの IP アドレスへのアクセスを許可する Egress ファイアウォールルールを含める必要があります。
20.3.2. EgressNetworkPolicy カスタムリソース (CR) オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
Egress ファイアウォールのルールを 1 つ以上定義できます。ルールは、ルールが適用されるトラフィックを指定して Allow ルールまたは Deny ルールのいずれかになります。
以下の YAML は EgressNetworkPolicy CR オブジェクトを説明しています。
EgressNetworkPolicy オブジェクト
20.3.2.1. EgressNetworkPolicy ルール リンクのコピーリンクがクリップボードにコピーされました!
以下の YAML は Egress ファイアウォールルールオブジェクトを説明しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector を使用して、送信トラフィックを許可または拒否できます。egress スタンザは、単一または複数のオブジェクトの配列を予想します。
Egress ポリシールールのスタンザ
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns_name>
egress:
- type: <type>
to:
cidrSelector: <cidr>
dnsName: <dns_name>
20.3.2.2. EgressNetworkPolicy CR オブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、複数の Egress ファイアウォールポリシールールを定義します。
- 1
- Egress ファイアウォールポリシールールオブジェクトのコレクション。
20.3.3. Egress ファイアウォールポリシーオブジェクトの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。
プロジェクトに EgressNetworkPolicy オブジェクトがすでに定義されている場合、既存のポリシーを編集して Egress ファイアウォールルールを変更する必要があります。
前提条件
- OpenShift SDN ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
ポリシールールを作成します。
-
<policy_name>.yamlファイルを作成します。この場合、<policy_name>は Egress ポリシールールを記述します。 - 作成したファイルで、Egress ポリシーオブジェクトを定義します。
-
以下のコマンドを入力してポリシーオブジェクトを作成します。
<policy_name>をポリシーの名前に、<project>をルールが適用されるプロジェクトに置き換えます。oc create -f <policy_name>.yaml -n <project>
$ oc create -f <policy_name>.yaml -n <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、新規の EgressNetworkPolicy オブジェクトが
project1という名前のプロジェクトに作成されます。oc create -f default.yaml -n project1
$ oc create -f default.yaml -n project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
egressnetworkpolicy.network.openshift.io/v1 created
egressnetworkpolicy.network.openshift.io/v1 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
オプション: 後に変更できるように
<policy_name>.yamlファイルを保存します。
20.4. プロジェクトの Egress ファイアウォールの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。
20.4.1. EgressNetworkPolicy オブジェクトの表示 リンクのコピーリンクがクリップボードにコピーされました!
クラスターで EgressNetworkPolicy オブジェクトを表示できます。
前提条件
- OpenShift SDN ネットワークプラグインを使用するクラスター。
-
ocとして知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。 - クラスターにログインすること。
手順
オプション: クラスターで定義された EgressNetworkPolicy オブジェクトの名前を表示するには、以下のコマンドを入力します。
oc get egressnetworkpolicy --all-namespaces
$ oc get egressnetworkpolicy --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーを検査するには、以下のコマンドを入力します。
<policy_name>を検査するポリシーの名前に置き換えます。oc describe egressnetworkpolicy <policy_name>
$ oc describe egressnetworkpolicy <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.5. プロジェクトの Egress ファイアウォールの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.5.1. EgressNetworkPolicy オブジェクトの編集 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトの Egress ファイアウォールを更新できます。
前提条件
- OpenShift SDN ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: Egress ネットワークファイアウォールの作成時に EgressNetworkPolicy オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yaml
$ oc get -n <project> egressnetworkpolicy <name> -o yaml > <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <project>をプロジェクトの名前に置き換えます。<name>をオブジェクトの名前に置き換えます。<filename>をファイルの名前に置き換え、YAML を保存します。ポリシールールに変更を加えたら、以下のコマンドを実行して EgressNetworkPolicy オブジェクトを置き換えます。
<filename>を、更新された EgressNetworkPolicy オブジェクトを含むファイルの名前に置き換えます。oc replace -f <filename>.yaml
$ oc replace -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
20.6. プロジェクトからの Egress ファイアウォールの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックに対するすべての制限を削除できます。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.6.1. EgressNetworkPolicy オブジェクトの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。
前提条件
- OpenShift SDN ネットワークプラグインを使用するクラスター。
-
OpenShift CLI (
oc) がインストールされている。 - クラスター管理者としてクラスターにログインする必要があります。
手順
プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。
<project>をプロジェクトの名前に置き換えます。oc get -n <project> egressnetworkpolicy
$ oc get -n <project> egressnetworkpolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力し、EgressNetworkPolicy オブジェクトを削除します。
<project>をプロジェクトの名前に、<name>をオブジェクトの名前に置き換えます。oc delete -n <project> egressnetworkpolicy <name>
$ oc delete -n <project> egressnetworkpolicy <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.7. Egress ルーター Pod の使用に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
20.7.1. Egress ルーター Pod について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Egress ルーター Pod は、他の用途で使用されていないプライベートソース IP アドレスから指定されたリモートサーバーにトラフィックをリダイレクトします。Egress ルーター Pod により、特定の IP アドレスからのアクセスのみを許可するように設定されたサーバーにネットワークトラフィックを送信できます。
Egress ルーター Pod はすべての発信接続のために使用されることが意図されていません。多数の Egress ルーター Pod を作成することで、ネットワークハードウェアの制限を引き上げられる可能性があります。たとえば、すべてのプロジェクトまたはアプリケーションに Egress ルーター Pod を作成すると、ソフトウェアの MAC アドレスのフィルターに戻る前にネットワークインターフェイスが処理できるローカル MAC アドレス数の上限を超えてしまう可能性があります。
Egress ルーターイメージには Amazon AWS, Azure Cloud またはレイヤー 2 操作をサポートしないその他のクラウドプラットフォームとの互換性がありません。それらに macvlan トラフィックとの互換性がないためです。
20.7.1.1. Egress ルーターモード リンクのコピーリンクがクリップボードにコピーされました!
リダイレクトモード では、Egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約された送信元 IP アドレスを使用する必要があるクライアント Pod は、宛先 IP に直接接続するのではなく、スロールーターのサービスにアクセスするように設定する必要があります。curl コマンドを使用して、アプリケーション Pod から宛先サービスとポートにアクセスできます。以下に例を示します。
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
HTTP プロキシーモードでは、Egress ルーター Pod はポート 8080 で HTTP プロキシーとして実行されます。このモードは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、数多くのプログラムは HTTP プロキシーを使用するように指示されます。
DNS プロキシーモードでは、Egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして実行されます。予約された送信元 IP アドレスを使用するには、クライアント Pod は、宛先 IP アドレスに直接接続するのでなく、Egress ルーター Pod に接続するように変更される必要があります。この修正により、外部の宛先でトラフィックが既知のソースから送信されているかのように処理されます。
リダイレクトモードは、HTTP および HTTPS 以外のすべてのサービスで機能します。HTTP および HTTPS サービスの場合は、HTTP プロキシーモードを使用します。IP アドレスまたはドメイン名を持つ TCP ベースのサービスの場合は、DNS プロキシーモードを使用します。
20.7.1.2. Egress ルーター Pod の実装 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーター Pod の設定は、初期化コンテナーで実行されます。このコンテナーは特権付きコンテキストで実行され、macvlan インターフェイスを設定して iptables ルールを設定できます。初期化コンテナーが iptables ルールの設定を終了すると、終了します。次に、Egress ルーター Pod はコンテナーを実行して Egress ルーターのトラフィックを処理します。使用されるイメージは、Egress ルーターモードによって異なります。
環境変数は、egress-router イメージが使用するアドレスを判別します。イメージは macvlan インターフェイスを、EGRESS_SOURCE をその IP アドレスとして使用し、EGRESS_GATEWAY をゲートウェイの IP アドレスとして使用するように設定します。
ネットワークアドレス変換 (NAT) ルールは、TCP ポートまたは UDP ポート上の Pod のクラスター IP アドレスへの接続が EGRESS_DESTINATION 変数で指定される IP アドレスの同じポートにリダイレクトされるように設定されます。
クラスター内の一部のノードのみが指定された送信元 IP アドレスを要求でき、指定されたゲートウェイを使用できる場合、受け入れ可能なノードを示す nodeName または nodeSelector を指定することができます。
20.7.1.3. デプロイメントに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーター Pod は追加の IP アドレスおよび MAC アドレスをノードのプライマリーネットワークインターフェイスに追加します。その結果、ハイパーバイザーまたはクラウドプロバイダーを、追加のアドレスを許可するように設定する必要がある場合があります。
- Red Hat OpenStack Platform (RHOSP)
OpenShift Container Platform を RHOSP にデプロイする場合、OpenStack 環境の Egress ルーター Pod の IP および MAC アドレスからのトラフィックを許可する必要があります。トラフィックを許可しないと、通信は失敗 します。
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - VMware vSphere
- VMware vSphere を使用している場合は、vSphere 標準スイッチのセキュリティー保護に関する VMware ドキュメント を参照してください。vSphere Web クライアントからホストの仮想スイッチを選択して、VMware vSphere デフォルト設定を表示し、変更します。
とくに、以下が有効にされていることを確認します。
20.7.1.4. フェイルオーバー設定 リンクのコピーリンクがクリップボードにコピーされました!
ダウンタイムを回避するには、以下の例のように Deployment リソースで Egress ルーター Pod をデプロイできます。サンプルのデプロイメント用に新規 Service オブジェクトを作成するには、oc expose deployment/egress-demo-controller コマンドを使用します。
20.8. リダイレクトモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された宛先 IP アドレスにリダイレクトするように設定された Egress ルーター Pod をデプロイできます。
20.8.1. リダイレクトモードの Egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで Egress ルーター Pod の設定を定義します。以下の YAML は、リダイレクトモードでの Egress ルーター Pod の設定のフィールドを説明しています。
- 1
- このアノテーションは、OpenShift Container Platform に対して、プライマリーネットワークインターフェイスコントローラー (NIC) に macvlan ネットワークインターフェイスを作成し、その macvlan インターフェイスを Pod ネットワークの namespace に移動するよう指示します。引用符を
"true"値の周囲に含める必要があります。OpenShift Container Platform が別の NIC インターフェイスに macvlan インターフェイスを作成するには、アノテーションの値をそのインターフェイスの名前に設定します。たとえば、eth1を使用します。 - 2
- ノードが置かれている物理ネットワークの IP アドレスは Egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、Egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- トラフィックの送信先となる外部サーバー。この例では、Pod の接続は
203.0.113.25にリダイレクトされます。 送信元 IP アドレスは192.168.12.99です。
Egress ルーター Pod 仕様の例
20.8.2. Egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーター Pod がリダイレクトモードでデプロイされる場合、以下のいずれかの形式を使用してリダイレクトルールを指定できます。
-
<port> <protocol> <ip_address>: 指定される<port>への着信接続が指定される<ip_address>の同じポートにリダイレクトされます。<protocol>はtcpまたはudpのいずれかになります。 -
<port> <protocol> <ip_address> <remote_port>: 接続が<ip_address>の別の<remote_port>にリダイレクトされるのを除き、上記と同じになります。 -
<ip_address>: 最後の行が単一 IP アドレスである場合、それ以外のポートの接続はその IP アドレスの対応するポートにリダイレクトされます。フォールバック IP アドレスがない場合、他のポートでの接続は拒否されます。
以下の例では、複数のルールが定義されます。
-
最初の行はローカルポート
80から203.0.113.25のポート80にトラフィックをリダイレクトします。 -
2 番目と 3 番目の行では、ローカルポート
8080および8443を、203.0.113.26のリモートポート80および443にリダイレクトします。 - 最後の行は、先のルールで指定されていないポートのトラフィックに一致します。
設定例
80 tcp 203.0.113.25 8080 tcp 203.0.113.26 80 8443 tcp 203.0.113.26 443 203.0.113.27
80 tcp 203.0.113.25
8080 tcp 203.0.113.26 80
8443 tcp 203.0.113.26 443
203.0.113.27
20.8.3. リダイレクトモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
リダイレクトモードでは、Egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスにリダイレクトするために iptables ルールをセットアップします。予約された送信元 IP アドレスを使用する必要があるクライアント Pod は、宛先 IP に直接接続するのではなく、スロールーターのサービスにアクセスするように設定する必要があります。curl コマンドを使用して、アプリケーション Pod から宛先サービスとポートにアクセスできます。以下に例を示します。
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Egress ルーター Pod の作成
他の Pod が Egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、Egress ルーター Pod を参照するサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がこのサービスに接続できるようになります。これらの接続は、予約された Egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。
20.9. HTTP プロキシーモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された HTTP および HTTPS ベースのサービスにプロキシーするように設定された Egress ルーター Pod をデプロイできます。
20.9.1. HTTP モードの Egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで Egress ルーター Pod の設定を定義します。以下の YAML は、HTTP モードでの Egress ルーター Pod の設定のフィールドを説明しています。
- 1
- このアノテーションは、OpenShift Container Platform に対して、プライマリーネットワークインターフェイスコントローラー (NIC) に macvlan ネットワークインターフェイスを作成し、その macvlan インターフェイスを Pod ネットワークの namespace に移動するよう指示します。引用符を
"true"値の周囲に含める必要があります。OpenShift Container Platform が別の NIC インターフェイスに macvlan インターフェイスを作成するには、アノテーションの値をそのインターフェイスの名前に設定します。たとえば、eth1を使用します。 - 2
- ノードが置かれている物理ネットワークの IP アドレスは Egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、Egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- プロキシーの設定方法を指定する文字列または YAML の複数行文字列です。これは、init コンテナーの他の環境変数ではなく、HTTP プロキシーコンテナーの環境変数として指定されることに注意してください。
20.9.2. Egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
Egress ルーター Pod が HTTP プロキシーモードでデプロイされる場合、以下の形式のいずれかを使用してリダイレクトルールを指定できます。これはすべてのリモート宛先への接続を許可することを意味します。 設定の各行には、許可または拒否する接続の 1 つのグループを指定します。
-
IP アドレス (例:
192.168.1.1) は該当する IP アドレスへの接続を許可します。 -
CIDR 範囲 (例:
192.168.1.0/24) は CIDR 範囲への接続を許可します。 -
ホスト名 (例:
www.example.com) は該当ホストへのプロキシーを許可します。 -
*.が前に付けられているドメイン名 (例:*.example.com) は該当ドメインおよびそのサブドメインのすべてへのプロキシーを許可します。 -
先の一致 (match) 式のいずれかの後に来る
!は接続を拒否します。 -
最後の行が
*の場合、明示的に拒否されていないすべてのものが許可されます。それ以外の場合、許可されないすべてのものが拒否されます。
* を使用してすべてのリモート宛先への接続を許可することもできます。
設定例
!*.example.com !192.168.1.0/24 192.168.2.1 *
!*.example.com
!192.168.1.0/24
192.168.2.1
*
20.9.3. HTTP プロキシーモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
HTTP プロキシーモードでは、Egress ルーター Pod はポート 8080 で HTTP プロキシーとして実行されます。このモードは、HTTP または HTTPS ベースのサービスと通信するクライアントの場合にのみ機能しますが、通常それらを機能させるのにクライアント Pod への多くの変更は不要です。環境変数を設定することで、数多くのプログラムは HTTP プロキシーを使用するように指示されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Egress ルーター Pod の作成
他の Pod が Egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、Egress ルーター Pod を参照するサービスを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
httpポートが常に8080に設定されていることを確認します。
http_proxyまたはhttps_proxy変数を設定して、クライアント Pod (Egress プロキシー Pod ではない) を HTTP プロキシーを使用するように設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 先の手順で作成したサービス。
注記すべてのセットアップに
http_proxyおよびhttps_proxy環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアに関するドキュメントを参照してください。
20.10. DNS プロキシーモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックを指定された DNS 名および IP アドレスにプロキシーするように設定された Egress ルーター Pod をデプロイできます。
20.10.1. DNS モードの Egress ルーター Pod 仕様 リンクのコピーリンクがクリップボードにコピーされました!
Pod オブジェクトで Egress ルーター Pod の設定を定義します。以下の YAML は、DNS モードでの Egress ルーター Pod の設定のフィールドを説明しています。
- 1
- このアノテーションは、OpenShift Container Platform に対して、プライマリーネットワークインターフェイスコントローラー (NIC) に macvlan ネットワークインターフェイスを作成し、その macvlan インターフェイスを Pod ネットワークの namespace に移動するよう指示します。引用符を
"true"値の周囲に含める必要があります。OpenShift Container Platform が別の NIC インターフェイスに macvlan インターフェイスを作成するには、アノテーションの値をそのインターフェイスの名前に設定します。たとえば、eth1を使用します。 - 2
- ノードが置かれている物理ネットワークの IP アドレスは Egress ルーター Pod で使用するために予約されます。オプション: サブネットの長さ
/24接尾辞を組み込み、ローカルサブネットへの適切なルートがセットアップされるようにできます。サブネットの長さを指定しない場合、Egress ルーターはEGRESS_GATEWAY変数で指定されたホストにのみアクセスでき、サブネットの他のホストにはアクセスできません。 - 3
- ノードで使用されるデフォルトゲートウェイと同じ値です。
- 4
- 1 つ以上のプロキシー宛先のリストを指定します。
- 5
- オプション: DNS プロキシーログ出力を
stdoutに出力するために指定します。
20.10.2. Egress 宛先設定形式 リンクのコピーリンクがクリップボードにコピーされました!
ルーターが DNS プロキシーモードでデプロイされる場合、ポートおよび宛先マッピングのリストを指定します。宛先には、IP アドレスまたは DNS 名のいずれかを使用できます。
Egress ルーター Pod は、ポートおよび宛先マッピングを指定するために以下の形式をサポートします。
- ポートおよびリモートアドレス
-
送信元ポートおよび宛先ホストは、2 つのフィールド形式 (
<port> <remote_address>) を使用して指定できます。
ホストには、IP アドレスまたは DNS 名を指定できます。DNS 名を指定すると、DNS 解決が起動時に行われます。特定のホストについては、プロキシーは、宛先ホスト IP アドレスへの接続時に、宛先ホストの指定された送信元ポートに接続されます。
ポートとリモートアドレスペアの例
80 172.16.12.11 100 example.com
80 172.16.12.11
100 example.com
- ポート、リモートアドレス、およびリモートポート
-
送信元ポート、宛先ホスト、および宛先ポートは、
<port> <remote_address> <remote_port>の 3 つのフィールドから成る形式を使用して指定できます。
3 つのフィールド形式は、2 つのフィールドバージョンと同じように動作しますが、宛先ポートが送信元ポートとは異なる場合があります。
ポート、リモートアドレス、およびリモートポートの例
8080 192.168.60.252 80 8443 web.example.com 443
8080 192.168.60.252 80
8443 web.example.com 443
20.10.3. DNS プロキシーモードでの Egress ルーター Pod のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
DNS プロキシーモードでは、Egress ルーター Pod は、トラフィックを独自の IP アドレスから 1 つ以上の宛先 IP アドレスに送信する TCP ベースのサービスの DNS プロキシーとして機能します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Egress ルーター Pod の作成
Egress ルーター Pod のサービスを作成します。
以下の YAML 定義が含まれる
egress-router-service.yamlという名前のファイルを作成します。spec.portsを、EGRESS_DNS_PROXY_DESTINATION環境変数に先に定義したポートのリストに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを作成するには、以下のコマンドを入力します。
oc create -f egress-router-service.yaml
$ oc create -f egress-router-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がこのサービスに接続できるようになります。これらの接続は、予約された Egress IP アドレスを使用して外部サーバーの対応するポートにプロキシー送信されます。
20.11. config map からの Egress ルーター Pod 宛先一覧の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Egress ルーター Pod の宛先マッピングを指定する ConfigMap オブジェクトを定義できます。設定の特定の形式は、Egress ルーター Pod のタイプによって異なります。形式の詳細は、特定の Egress ルーター Pod のドキュメントを参照してください。
20.11.1. config map を使用した Egress ルーター宛先マッピングの設定 リンクのコピーリンクがクリップボードにコピーされました!
宛先マッピングのセットのサイズが大きいか、これが頻繁に変更される場合、config map を使用して一覧を外部で維持できます。この方法の利点は、設定マップを編集するパーミッションを cluster-admin 権限を持たないユーザーに委任できることです。Egress ルーター Pod には特権付きコンテナーを必要とするため、cluster-admin 権限を持たないユーザーは Pod 定義を直接編集することはできません。
Egress ルーター Pod は、config map が変更されても自動的に更新されません。更新を取得するには、Egress ルーター Pod を再起動する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の例のように、Egress ルーター Pod のマッピングデータが含まれるファイルを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 空の行とコメントをこのファイルに追加できます。
このファイルから
ConfigMapオブジェクトを作成します。oc delete configmap egress-routes --ignore-not-found
$ oc delete configmap egress-routes --ignore-not-foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txt
$ oc create configmap egress-routes \ --from-file=destination=my-egress-destination.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 直前のコマンドで、
egress-routes値は、作成するConfigMapオブジェクトの名前で、my-egress-destination.txtはデータの読み取り元のファイルの名前です。ヒントまたは、以下の YAML を適用して config map を作成できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Egress ルーター Pod 定義を作成し、environment スタンザの
EGRESS_DESTINATIONフィールドにconfigMapKeyRefスタンザを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.12. プロジェクトのマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
20.12.1. マルチキャストについて リンクのコピーリンクがクリップボードにコピーされました!
IP マルチキャストを使用すると、データが多数の IP アドレスに同時に配信されます。
- 現時点で、マルチキャストは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のソリューションとしては適していません。
-
デフォルトでは、ネットワークポリシーは namespace 内のすべての接続に影響します。ただし、マルチキャストはネットワークポリシーの影響を受けません。マルチキャストがネットワークポリシーと同じ namespace で有効にされている場合、
deny-allネットワークポリシーがある場合でも、マルチキャストは常に許可されます。クラスター管理者は、これを有効にする前に、ネットワークポリシーからマルチキャストが除外されることの影響を考慮する必要があります。
OpenShift Container Platform の Pod 間のマルチキャストトラフィックはデフォルトで無効にされます。OpenShift SDN ネットワークプラグインを使用している場合、プロジェクトごとにマルチキャストを有効にできます。
networkpolicy 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。
-
Pod によって送信されるマルチキャストパケットは、
NetworkPolicyオブジェクトに関係なく、プロジェクトの他のすべての Pod に送信されます。Pod はユニキャストで通信できない場合でもマルチキャストで通信できます。 -
1 つのプロジェクトの Pod によって送信されるマルチキャストパケットは、
NetworkPolicyオブジェクトがプロジェクト間の通信を許可する場合であっても、それ以外のプロジェクトの Pod に送信されることはありません。
multitenant 分離モードで OpenShift SDN ネットワークプラグインを使用する場合は、以下を行います。
- Pod で送信されるマルチキャストパケットはプロジェクトにあるその他の全 Pod に送信されます。
- あるプロジェクトの Pod によって送信されるマルチキャストパケットは、各プロジェクトが結合し、マルチキャストが結合した各プロジェクトで有効にされている場合にのみ、他のプロジェクトの Pod に送信されます。
20.12.2. Pod 間のマルチキャストの有効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを有効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行し、プロジェクトのマルチキャストを有効にします。
<namespace>を、マルチキャストを有効にする必要のある namespace に置き換えます。oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=true$ oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
マルチキャストがプロジェクトについて有効にされていることを確認するには、以下の手順を実行します。
現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。
<project>をプロジェクト名に置き換えます。oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストレシーバーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストセンダーとして機能する Pod を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいターミナルウィンドウまたはタブで、マルチキャストリスナーを起動します。
Pod の IP アドレスを取得します。
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、マルチキャストリスナーを起動します。
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マルチキャストトランスミッターを開始します。
Pod ネットワーク IP アドレス範囲を取得します。
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストメッセージを送信するには、以下のコマンドを入力します。
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
20.13. プロジェクトのマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
20.13.1. Pod 間のマルチキャストの無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトの Pod でマルチキャストを無効にすることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを実行して、マルチキャストを無効にします。
oc annotate netnamespace <namespace> \ netnamespace.network.openshift.io/multicast-enabled-$ oc annotate netnamespace <namespace> \1 netnamespace.network.openshift.io/multicast-enabled-Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マルチキャストを無効にする必要のあるプロジェクトの
namespace。
20.14. OpenShift SDN を使用したネットワーク分離の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
クラスターが OpenShift SDN ネットワークプラグインのマルチテナント分離モードを使用するように設定されている場合、各プロジェクトはデフォルトで分離されます。ネットワークトラフィックは、マルチテナント分離モードでは、異なるプロジェクトの Pod およびサービス間で許可されません。
プロジェクトのマルチテナント分離の動作を 2 つの方法で変更することができます。
- 1 つ以上のプロジェクトを結合し、複数の異なるプロジェクトの Pod とサービス間のネットワークトラフィックを可能にします。
- プロジェクトのネットワーク分離を無効にできます。これはグローバルにアクセスできるようになり、他のすべてのプロジェクトの Pod およびサービスからのネットワークトラフィックを受け入れます。グローバルにアクセス可能なプロジェクトは、他のすべてのプロジェクトの Pod およびサービスにアクセスできます。
20.14.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- マルチテナント分離モードで OpenShift SDN ネットワークプラグインを使用するように設定されたクラスターが必要です。
20.14.2. プロジェクトの結合 リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上のプロジェクトを結合し、複数の異なるプロジェクトの Pod とサービス間のネットワークトラフィックを可能にします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
以下のコマンドを使用して、プロジェクトを既存のプロジェクトネットワークに参加させます。
oc adm pod-network join-projects --to=<project1> <project2> <project3>
$ oc adm pod-network join-projects --to=<project1> <project2> <project3>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。オプション: 以下のコマンドを実行し、結合した Pod ネットワークを表示します。
oc get netnamespaces
$ oc get netnamespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 同じ Pod ネットワークのプロジェクトには、NETID 列に同じネットワーク ID があります。
20.14.3. プロジェクトの分離 リンクのコピーリンクがクリップボードにコピーされました!
他のプロジェクトの Pod およびサービスがその Pod およびサービスにアクセスできないようにするためにプロジェクトを分離することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
クラスターのプロジェクトを分離するには、以下のコマンドを実行します。
oc adm pod-network isolate-projects <project1> <project2>
$ oc adm pod-network isolate-projects <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。
20.14.4. プロジェクトのネットワーク分離の無効化 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトのネットワーク分離を無効にできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにログインする必要があります。
手順
プロジェクトの以下のコマンドを実行します。
oc adm pod-network make-projects-global <project1> <project2>
$ oc adm pod-network make-projects-global <project1> <project2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、特定のプロジェクト名を指定する代わりに
--selector=<project_selector>オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。
20.15. kube-proxy の設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes メットワークプロキシー (kube-proxy) は各ノードで実行され、Cluster Network Operator (CNO) で管理されます。kube-proxy は、サービスに関連付けられたエンドポイントの接続を転送するためのネットワークルールを維持します。
20.15.1. iptables ルールの同期について リンクのコピーリンクがクリップボードにコピーされました!
同期の期間は、Kubernetes ネットワークプロキシー (kube-proxy) がノードで iptables ルールを同期する頻度を定めます。
同期は、以下のイベントのいずれかが生じる場合に開始します。
- サービスまたはエンドポイントのクラスターへの追加、またはクラスターからの削除などのイベントが発生する。
- 最後の同期以後の時間が kube-proxy に定義される同期期間を超過している。
20.15.2. kube-proxy 設定パラメーター リンクのコピーリンクがクリップボードにコピーされました!
以下の kubeProxyConfig パラメーターを変更することができます。
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。
| パラメーター | 説明 | 値 | デフォルト |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
20.15.3. kube-proxy 設定の変化 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの Kubernetes ネットワークプロキシー設定を変更することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールで実行中のクラスターにログインします。
手順
以下のコマンドを実行して、
Network.operator.openshift.ioカスタムリソース (CR) を編集します。oc edit network.operator.openshift.io cluster
$ oc edit network.operator.openshift.io clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプル CR のように、kube-proxy 設定への変更内容で、CR の
kubeProxyConfigパラメーターを変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを保存し、テキストエディターを編集します。
構文は、ファイルを保存し、エディターを終了する際に
ocコマンドによって検証されます。変更内容に構文エラーが含まれる場合、エディターはファイルを開き、エラーメッセージを表示します。以下のコマンドを実行して、設定の更新を確認します。
oc get networks.operator.openshift.io -o yaml
$ oc get networks.operator.openshift.io -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 以下のコマンドを実行し、Cluster Network Operator が設定変更を受け入れていることを確認します。
oc get clusteroperator network
$ oc get clusteroperator networkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.1.0-0.9 True False False 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定の更新が正常に適用されると、
AVAILABLEフィールドがTrueになります。
第21章 ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
21.1. ルート設定 リンクのコピーリンクがクリップボードにコピーされました!
21.1.1. HTTP ベースのルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
以下の手順では、hello-openshift アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。
手順
次のコマンドを実行して、
hello-openshiftというプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
hello-openshiftというサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
hello-openshiftアプリケーションに対して、セキュアではないルートを作成します。oc expose svc hello-openshift
$ oc expose svc hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
作成した
routeリソースを確認するには、次のコマンドを実行します。oc get routes -o yaml <name of resource>
$ oc get routes -o yaml <name of resource>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、ルートの名前は
hello-openshiftです。
上記で作成したセキュアでないルートの YAML 定義
- 1
hostフィールドは、サービスを指すエイリアス DNS レコードです。このフィールドには、www.example.comなどの有効な DNS 名を指定できます。DNS 名は DNS952 サブドメイン規則に従う必要があります。指定しない場合は、ルート名が自動的に生成されます。- 2
targetPortフィールドは、このルートが指すサービスによって選択される Pod 上のターゲットポートです。注記デフォルトの Ingress ドメインを表示するには、以下のコマンドを実行します。
oc get ingresses.config/cluster -o jsonpath={.spec.domain}$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.2. Ingress Controller シャーディングのルート作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法を説明します。
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
hello-openshiftというプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
hello-openshiftというサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow hello-openshift-route.yamlというルート定義を作成します。シャーディング用に作成したルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
hello-openshift-route.yamlを使用してhello-openshiftアプリケーションへのルートを作成します。oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを使用して、ルートのステータスを取得します。
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果の
Routeリソースは次のようになります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.3. ルートのタイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。
OpenShift Container Platform クラスターの前にユーザー管理の外部ロードバランサーを設定した場合は、ユーザー管理の外部ロードバランサーのタイムアウト値がルートのタイムアウト値よりも高いことを確認してください。この設定により、クラスターが使用するネットワーク上でのネットワーク輻輳の問題を防ぐことができます。
前提条件
- 実行中のクラスターでデプロイ済みの Ingress Controller が必要になります。
手順
oc annotateコマンドを使用して、ルートにタイムアウトを追加します。oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。
以下の例では、2 秒のタイムアウトを
myrouteという名前のルートに設定します。oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.4. HTTP Strict Transport Security リンクのコピーリンクがクリップボードにコピーされました!
HTTP Strict Transport Security (HSTS) ポリシーは、HTTPS トラフィックのみがルートホストで許可されるブラウザークライアントに通知するセキュリティーの拡張機能です。また、HSTS は、HTTP リダイレクトを使用せずに HTTPS トランスポートにシグナルを送ることで Web トラフィックを最適化します。HSTS は Web サイトとの対話を迅速化するのに便利です。
HSTS ポリシーが適用されると、HSTS はサイトから Strict Transport Security ヘッダーを HTTP および HTTPS 応答に追加します。HTTP を HTTPS にリダイレクトするルートで insecureEdgeTerminationPolicy 値を使用できます。HSTS を強制している場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するため、リダイレクトの必要がなくなります。
クラスター管理者は、以下を実行するために HSTS を設定できます。
- ルートごとに HSTS を有効にします。
- ルートごとに HSTS を無効にします。
- ドメインごとに HSTS を適用するか、ドメインと組み合わせた namespace ラベルを使用します。
HSTS はセキュアなルート (edge-terminated または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。
21.1.4.1. ルートごとの HTTP Strict Transport Security の有効化 リンクのコピーリンクがクリップボードにコピーされました!
HTTP 厳密なトランスポートセキュリティー (HSTS) は HAProxy テンプレートに実装され、haproxy.router.openshift.io/hsts_header アノテーションを持つ edge および re-encrypt ルートに適用されます。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
OpenShift CLI (
oc) がインストールされている。
手順
ルートで HSTS を有効にするには、
haproxy.router.openshift.io/hsts_header値を edge-terminated または re-encrypt ルートに追加します。これを実行するには、oc annotateツールを使用してこれを実行できます。oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ includeSubDomains;preload"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\1 includeSubDomains;preload"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、最長期間は
31536000ミリ秒 (約 8.5 時間) に設定されます。
注記この例では、等号 (
=) が引用符で囲まれています。これは、annotate コマンドを正しく実行するために必要です。アノテーションで設定されたルートの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必須。
max-ageは、HSTS ポリシーが有効な期間 (秒単位) を測定します。0に設定すると、これはポリシーを無効にします。 - 2
- 任意。
includeSubDomainsは、クライアントに対し、ホストのすべてのサブドメインにホストと同じ HSTS ポリシーを持つ必要があることを指示します。 - 3
- 任意。
max-ageが 0 より大きい場合、preloadをhaproxy.router.openshift.io/hsts_headerに追加し、外部サービスがこのサイトをそれぞれの HSTS プリロードリストに含めることができます。たとえば、Google などのサイトはpreloadが設定されているサイトの一覧を作成します。ブラウザーはこれらのリストを使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preloadを設定していない場合、ブラウザーはヘッダーを取得するために、HTTPS を介してサイトと少なくとも 1 回対話している必要があります。
21.1.4.2. ルートごとの HTTP Strict Transport Security の無効化 リンクのコピーリンクがクリップボードにコピーされました!
ルートごとに HSTS (HTTP Strict Transport Security) を無効にするには、ルートアノテーションの max-age の値を 0 に設定します。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
OpenShift CLI (
oc) がインストールされている。
手順
HSTS を無効にするには、以下のコマンドを入力してルートアノテーションの
max-ageの値を0に設定します。oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して config map を作成できます。
ルートごとに HSTS を無効にする例
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace のすべてのルートで HSTS を無効にするには、following コマンドを入力します。
oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name: routename HSTS: max-age=0
Name: routename HSTS: max-age=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.4.3. ドメインごとの HTTP Strict Transport Security の適用 リンクのコピーリンクがクリップボードにコピーされました!
セキュアなルートに対してドメインごとに HTTP Strict Transport Security (HSTS) を適用するには、Ingress 仕様に requiredHSTSPolicies レコードを追加して、HSTS ポリシーの設定を取得します。
requiredHSTSPolicy を設定して HSTS を適用する場合は、新規に作成されたルートは準拠された HSTS ポリシーアノテーションで設定する必要があります。
準拠しない HSTS ルートを持つアップグレードされたクラスターを処理するには、ソースでマニフェストを更新し、更新を適用できます。
oc expose route コマンドまたは oc create route コマンドを使用して、HSTS を強制するドメインにルートを追加することはできません。このコマンドの API はアノテーションを受け入れないためです。
HSTS がすべてのルートに対してグローバルに要求されている場合でも、セキュアではないルートや非 TLS ルートに適用することはできません。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行し、必要に応じてフィールドを更新して、Ingress 設定 YAML を編集します。
oc edit ingresses.config.openshift.io/cluster
$ oc edit ingresses.config.openshift.io/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow HSTS ポリシーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必須。
requiredHSTSPoliciesは順番に検証され、最初に一致するdomainPatternsが適用されます。 - 2
- 必須。1 つ以上の
domainPatternsホスト名を指定する必要があります。任意の数のドメインをリスト表示できます。さまざまなdomainPatternsについて、Enforcing オプションの複数のセクションを含めることができます。 - 3
- 任意。
namespaceSelectorを含める場合、ルートを配置するプロジェクトのラベルと一致する必要があります。これにより、ルートに設定された HSTS ポリシーを適用する必要があります。domainPatternsではなくnamespaceSelectorのみに一致するルートは検証されません。 - 4
- 必須。
max-ageは、HSTS ポリシーが有効な期間 (秒単位) を測定します。このポリシー設定により、最小および最大のmax-ageを適用することができます。-
largestMaxAgeの値は0から2147483647の範囲内で指定する必要があります。これを指定しないと、上限が強制されないことを意味します。 -
smallestMaxAgeの値は0から2147483647の範囲内で指定する必要があります。トラブルシューティングのために HSTS を無効にするには、0を入力します。HSTS を無効にする必要がない場合は1を入力します。これを指定しないと、下限が強制されません。
-
- 5
- 任意。
haproxy.router.openshift.io/hsts_headerにpreloadを含めることで、外部サービスがこのサイトをそれぞれの HSTS プリロードリストに含めることができます。ブラウザーはこれらの一覧を使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload設定がない場合、ブラウザーは少なくともサイトと通信してヘッダーを取得する必要があります。preloadは、以下のいずれかで設定できます。-
RequirePreload:preloadはRequiredHSTSPolicyで必要になります。 -
RequireNoPreload:preloadはRequiredHSTSPolicyによって禁止されます。 -
NoOpinion:preloadはRequiredHSTSPolicyに重要ではありません。
-
- 6
- 任意。
includeSubDomainsPolicyは、以下のいずれかで設定できます。-
RequireIncludeSubDomains:includeSubDomainsはRequiredHSTSPolicyで必要です。 -
RequireNoIncludeSubDomains:includeSubDomainsはRequiredHSTSPolicyによって禁止されています。 -
NoOpinion:includeSubDomainsはRequiredHSTSPolicyに重要ではありません。
-
oc annotate commandを入力して、HSTS をクラスターのすべてのルートまたは特定の namespace に適用することができます。HSTS をクラスターのすべてのルートに適用するには、
oc annotate commandを実行します。以下に例を示します。oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の namespace のすべてのルートに HSTS を適用するには、
oc annotate commandを実行します。以下に例を示します。oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定した HSTS ポリシーを確認できます。以下に例を示します。
必要な HSTS ポリシーの
maxAgeセットを確認するには、以下のコマンドを入力します。oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのルートで HSTS アノテーションを確認するには、以下のコマンドを入力します。
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.5. スループットの問題のトラブルシューティング方法 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。
Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。
pingまたはtcpdumpなどのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。たとえば、問題を生じさせる動作を再現している間に各ノードで
tcpdumpツールを実行 します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェイスが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
podipは Pod の IP アドレスです。oc get pod <pod_name> -o wideコマンドを実行して Pod の IP アドレスを取得します。
tcpdumpは、これらの 2 つの Pod 間のすべてのトラフィックが含まれる/tmp/dump.pcapのファイルを生成します。ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。以下のように ノード間でパケットアナライザーを実行すること もできます (式から SDN を排除する)。tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストリーミングのスループットおよび UDP スループットを測定するために
iperfなどの帯域幅測定ツールを使用します。最初に Pod からツールを実行し、次にノードから実行して、ボトルネックを特定します。-
iperfのインストールおよび使用に関する詳細は、こちらの Red Hat ソリューション を参照してください。
-
- 場合によっては、レイテンシーの問題が原因で、クラスターがルーター Pod を含むノードを異常としてマークすることがあります。ワーカーレイテンシープロファイルを使用して、アクションを実行する前にクラスターがノードからステータスの最新情報を受け取る頻度を調節します。
-
クラスターでレイテンシーの低いノードとレイテンシーの高いノードが指定されている場合は、Ingress Controller の
spec.nodePlacementフィールドを設定して、ルーター Pod の配置を制御します。
21.1.6. Cookie の使用によるルートのステートフル性の維持 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。
OpenShift Container Platform は Cookie を使用してセッションの永続化を設定できます。Ingress Controller はユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress Controller に対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。
Cookie は、HTTP トラフィックを表示できないので、パススルールートで設定できません。代わりに、送信元 IP アドレスをベースに数が計算され、バックエンドを判断します。
バックエンドが変わると、トラフィックが間違ったサーバーに転送されてしまい、スティッキーではなくなります。送信元 IP を非表示にするロードバランサーを使用している場合は、すべての接続に同じ番号が設定され、トラフィックは同じ Pod に送られます。
21.1.6.1. Cookie を使用したルートのアノテーション リンクのコピーリンクがクリップボードにコピーされました!
ルート用に自動生成されるデフォルト名を上書きするために Cookie 名を設定できます。これにより、ルートトラフィックを受信するアプリケーションが Cookie 名を認識できるようになります。Cookie を削除すると、次の要求でエンドポイントの再選択が強制的に実行される可能性があります。その結果、サーバーがオーバーロードしている場合は、クライアントからの要求を取り除き、それらの再分配を試行します。
手順
指定される cookie 名でルートにアノテーションを付けます。
oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<route_name>- Pod の名前を指定します。
<cookie_name>- cookie の名前を指定します。
たとえば、ルート
my_routeに cookie 名my_cookieでアノテーションを付けるには、以下を実行します。oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変数でルートのホスト名を取得します。
ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<route_name>- Pod の名前を指定します。
cookie を保存してからルートにアクセスします。
curl $ROUTE_NAME -k -c /tmp/cookie_jar
$ curl $ROUTE_NAME -k -c /tmp/cookie_jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。
curl $ROUTE_NAME -k -b /tmp/cookie_jar
$ curl $ROUTE_NAME -k -b /tmp/cookie_jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.7. パスベースのルート リンクのコピーリンクがクリップボードにコピーされました!
パスベースのルートは、URL に対して比較できるパスコンポーネントを指定します。この場合、ルートのトラフィックは HTTP ベースである必要があります。そのため、それぞれが異なるパスを持つ同じホスト名を使用して複数のルートを提供できます。ルーターは、最も具体的なパスの順に基づいてルートと一致する必要があります。
以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。
| ルート | 比較対象 | アクセス可能 |
|---|---|---|
| www.example.com/test | www.example.com/test | はい |
| www.example.com | いいえ | |
| www.example.com/test および www.example.com | www.example.com/test | はい |
| www.example.com | はい | |
| www.example.com | www.example.com/text | Yes (ルートではなく、ホストで一致) |
| www.example.com | はい |
パスが 1 つでセキュリティー保護されていないルート
- 1
- パスは、パスベースのルートに唯一追加される属性です。
ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、パススルー TLS を使用する場合には利用できません。
21.1.8. HTTP ヘッダーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。
IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。
21.1.8.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 またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。
21.1.8.2. 特殊なケースのヘッダー リンクのコピーリンクがクリップボードにコピーされました!
次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。
| ヘッダー名 | IngressController 仕様を使用して設定可能かどうか | Route 仕様を使用して設定可能かどうか | 不許可の理由 | 別の方法で設定可能かどうか |
|---|---|---|---|---|
|
| いいえ | いいえ |
| いいえ |
|
| いいえ | はい |
| いいえ |
|
| いいえ | いいえ |
|
はい: |
|
| いいえ | いいえ | HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。 | はい:
|
21.1.9. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除 リンクのコピーリンクがクリップボードにコピーされました!
コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。
たとえば、ルートを提供する Ingress Controller によってデフォルトのグローバルな場所が指定されている場合でも、コンテンツが複数の言語で記述されていると、Web アプリケーションが特定のルートの別の場所でコンテンツを提供するように指定できます。
以下の手順では Content-Location HTTP リクエストヘッダーを設定するルートを作成し、アプリケーション (https://app.example.com) に URL が関連付けられ、https://app.example.com/lang/en-us のロケーションにダイレクトされるようにします。アプリケーショントラフィックをこの場所にダイレクトすると、特定のルートを使用する場合はすべて、アメリカ英語で記載された Web コンテンツにアクセスすることになります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - プロジェクト管理者として OpenShift Container Platform クラスターにログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
手順
ルート定義を作成し、
app-example-route.yamlというファイルに保存します。HTTP ヘッダーディレクティブを使用して作成されたルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- HTTP ヘッダーに対して実行するアクションのリスト。
- 2
- 変更するヘッダーのタイプ。この場合は、応答ヘッダーです。
- 3
- 変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストは、HTTP ヘッダーの設定 を参照してください。
- 4
- ヘッダーに対して実行されるアクションのタイプ。このフィールドには、
SetまたはDeleteの値を指定できます。 - 5
- HTTP ヘッダーの設定時は、
値を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例:DENY)にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、値はコンテンツの相対位置に設定されます。
新しく作成したルート定義を使用して、既存の Web アプリケーションへのルートを作成します。
oc -n app-example create -f app-example-route.yaml
$ oc -n app-example create -f app-example-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
HTTP リクエストヘッダーの場合、ルート定義で指定されたアクションは、Ingress Controller の HTTP リクエストヘッダーに対して実行されたアクションの後に実行されます。これは、ルート内のこれらのリクエストヘッダーに設定された値が、Ingress Controller に設定された値よりも優先されることを意味します。HTTP ヘッダーの処理順序の詳細は、HTTP ヘッダーの設定 を参照してください。
21.1.10. ルート固有のアノテーション リンクのコピーリンクがクリップボードにコピーされました!
Ingress Controller は、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。
複数の送信元 IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、リストが警告やエラーメッセージなしに無視されます。
| 変数 | 説明 | デフォルトで使用される環境変数 |
|---|---|---|
|
|
ロードバランシングアルゴリズムを設定します。使用できるオプションは、 |
パススルールートの |
|
|
関連の接続を追跡する cookie の使用を無効にします。 | |
|
| このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。 | |
|
|
ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。 | |
|
|
| |
|
|
同じ送信元 IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。 | |
|
|
同じ送信元 IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。 | |
|
|
同じ送信元 IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。 | |
|
| ルートのサーバー側のタイムアウトを設定します。(TimeUnits) |
|
|
| このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した WebSocket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。 |
|
|
|
設定できるのは、IngressController または Ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxy |
|
|
| バックエンドのヘルスチェックの間隔を設定します。(TimeUnits) |
|
|
| ルートの許可リストを設定します。許可リストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにしたリストです。許可リストに含まれていない IP アドレスからの要求は破棄されます。
| |
|
| edge terminated または re-encrypt ルートの Strict-Transport-Security ヘッダーを設定します。 | |
|
| バックエンドの要求の書き換えパスを設定します。 | |
|
| Cookie を制限するために値を設定します。値は以下のようになります。
この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメント を参照してください。 | |
|
|
ルートごとに
|
|
-
デフォルトでは、ルーターは 5 秒ごとにリロードされ、最初から Pod 間の接続のバランスがリセットされます。その結果、
roundrobin状態はリロード間で保持されません。このアルゴリズムは、Pod のコンピューティング能力とストレージ容量がほぼ同じである場合に最適に機能します。たとえば、CI/CD パイプラインの使用により、アプリケーションまたはサービスのエンドポイントが継続的に変更される場合、結果的にバランスが不均一になる可能性があります。その場合は別のアルゴリズムを使用します。 許可リストの IP アドレスと CIDR 範囲の数が 61 を超えると、それらは別のファイルに書き込まれます。これは
haproxy.configファイルから参照されます。このファイルは、/var/lib/haproxy/router/allowlistsフォルダーに保存されます。注記アドレスが許可リストに書き込まれることを確認するには、CIDR 範囲の完全なリストが Ingress Controller 設定ファイルに記載されていることを確認します。etcd オブジェクトサイズ制限は、ルートアノテーションのサイズを制限します。このため、許可リストに追加できる IP アドレスと CIDR 範囲の最大数のしきい値が作成されます。
環境変数を編集することはできません。
ルータータイムアウト変数
TimeUnits は数字、その後に単位を指定して表現します。us *(マイクロ秒)、ms (ミリ秒、デフォルト)、s (秒)、m (分)、h *(時間)、d (日)
正規表現: [1-9][0-9]*(us\|ms\|s\|m\|h\|d)
| 変数 | デフォルト | 説明 |
|---|---|---|
|
|
| バックエンドでの後続の liveness チェックの時間の長さ。 |
|
|
| クライアントがルートに接続する場合の TCP FIN タイムアウトの期間を制御します。接続切断のために送信された FIN が指定の時間内に応答されない場合は、HAProxy が接続を切断します。小さい値を設定し、ルーターでリソースをあまり使用していない場合には、リスクはありません。 |
|
|
| クライアントがデータを確認するか、送信するための時間の長さ。 |
|
|
| 最大接続時間。 |
|
|
| ルーターからルートをバッキングする Pod の TCP FIN タイムアウトを制御します。 |
|
|
| サーバーがデータを確認するか、送信するための時間の長さ。 |
|
|
| TCP または WebSocket 接続が開放された状態で保つ時間数。このタイムアウト期間は、HAProxy が再読み込みされるたびにリセットされます。 |
|
|
|
新しい HTTP 要求が表示されるまで待機する最大時間を設定します。この値が低すぎる場合には、ブラウザーおよびアプリケーションの
有効なタイムアウト値には、想定した個別のタイムアウトではなく、特定の変数を合計した値に指定することができます。たとえば、 |
|
|
| HTTP 要求の伝送にかかる時間。 |
|
|
| ルーターがリロードし、新規の変更を受け入れる最小の頻度を許可します。 |
|
|
| HAProxy メトリクスの収集タイムアウト。 |
ルート設定のカスタムタイムアウト
- 1
- HAProxy 対応の単位 (
us、ms、s、m、h、d) で新規のタイムアウトを指定します。単位が指定されていない場合は、msがデフォルトになります。
パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、WebSocket 接続がそのルートで頻繁にタイムアウトする可能性があります。
特定の IP アドレスを 1 つだけ許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
複数の IP アドレスを許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
IP アドレスの CIDR ネットワークを許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
IP アドレスと IP アドレスの CIDR ネットワークの両方を許可するルート
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
書き換えターゲットを指定するルート
- 1
- バックエンドの要求の書き換えパスとして
/を設定します。
ルートに haproxy.router.openshift.io/rewrite-target アノテーションを設定すると、要求をバックエンドアプリケーションに転送する前に Ingress Controller がこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。
以下の表は、spec.path、要求パス、および書き換えターゲットの各種の組み合わせに関するパスの書き換え動作の例を示しています。
| Route.spec.path | 要求パス | 書き換えターゲット | 転送された要求パス |
|---|---|---|---|
| /foo | /foo | / | / |
| /foo | /foo/ | / | / |
| /foo | /foo/bar | / | /bar |
| /foo | /foo/bar/ | / | /bar/ |
| /foo | /foo | /bar | /bar |
| /foo | /foo/ | /bar | /bar/ |
| /foo | /foo/bar | /baz | /baz/bar |
| /foo | /foo/bar/ | /baz | /baz/bar/ |
| /foo/ | /foo | / | 該当なし (要求パスがルートパスに一致しない) |
| /foo/ | /foo/ | / | / |
| /foo/ | /foo/bar | / | /bar |
haproxy.router.openshift.io/rewrite-target 内の特定の特殊文字は、適切にエスケープする必要があるため、特別な処理が必要です。これらの文字がどのように処理されるかについては、次の表を参照してください。
| 以下の文字の場合 | 以下の文字を使用 | 注記 |
|---|---|---|
| # | \# | # は書き換え式を終了させるので使用しないでください。 |
| % | % または %% | %%% のような変則的なシーケンスは避けてください。 |
| ‘ | \’ | ‘ は無視されるので避けてください。 |
その他の有効な URL 文字はすべてエスケープせずに使用できます。
21.1.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=mergeCopy 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
21.1.12. Ingress オブジェクトを使用したルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のエコシステムコンポーネントには Ingress リソースとの統合機能がありますが、ルートリソースとは統合しません。これに対応するために、OpenShift Container Platform は Ingress オブジェクトの作成時に管理されるルートオブジェクトを自動的に作成します。これらのルートオブジェクトは、対応する Ingress オブジェクトが削除されると削除されます。
手順
OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、
oc createコマンドを実行します。Ingress の YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
route.openshift.io/terminationアノテーションは、Routeのspec.tls.terminationフィールドを設定するために使用できます。Ingressにはこのフィールドがありません。許可される値はedge、passthrough、およびreencryptです。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edgeがデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。- 3
Ingressオブジェクトを操作する場合、ルートを操作する場合とは異なり、明示的なホスト名を指定する必要があります。<host_name>.<cluster_ingress_domain>構文 (apps.openshiftdemos.comなど) を使用して、*.<cluster_ingress_domain>ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。route.openshift.io/terminationアノテーションでpassthroughの値を指定する場合は、仕様でpathを''に設定し、pathTypeをImplementationSpecificに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ingress.yaml
$ oc apply -f ingress.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 2
route.openshift.io/destination-ca-certificate-secretを Ingress オブジェクトで使用して、カスタム宛先証明書 (CA) でルートを定義できます。アノテーションは、生成されたルートに挿入される kubernetes シークレットsecret-ca-certを参照します。-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
data.tls.crt指定子に PEM エンコード形式の証明書を使用してkubernetes.io/tlsまたはOpaqueタイプのシークレットを作成する必要があります。
-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
ルートを一覧表示します。
oc get routes
$ oc get routesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果には、
frontend-で始まる名前の自動生成ルートが含まれます。NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow このルートを検査すると、以下のようになります。
自動生成されるルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.13. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する リンクのコピーリンクがクリップボードにコピーされました!
TLS 設定を指定せずに Ingress オブジェクトを作成すると、OpenShift Container Platform は安全でないルートを生成します。デフォルトの Ingress 証明書を使用してセキュアなエッジ終端ルートを生成する Ingress オブジェクトを作成するには、次のように空の TLS 設定を指定できます。
前提条件
- 公開したいサービスがあります。
-
OpenShift CLI (
oc) にアクセスできる。
手順
Ingress オブジェクトの YAML ファイルを作成します。この例では、ファイルの名前は
example-ingress.yamlです。Ingress オブジェクトの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。
次のコマンドを実行して、Ingress オブジェクトを作成します。
oc create -f example-ingress.yaml
$ oc create -f example-ingress.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して、OpenShift Container Platform が Ingress オブジェクトの予期されるルートを作成したことを確認します。
oc get routes -o yaml
$ oc get routes -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.14. Ingress アノテーションでの宛先 CA 証明書を使用したルート作成 リンクのコピーリンクがクリップボードにコピーされました!
route.openshift.io/destination-ca-certificate-secret アノテーションを Ingress オブジェクトで使用して、カスタム宛先 CA 証明書でルートを定義できます。
前提条件
- PEM エンコードされたファイルで証明書/キーのペアを持つことができます。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
手順
次のコマンドを入力して、宛先 CA 証明書のシークレットを作成します。
oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>
$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt
$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
secret/dest-ca-cert created
secret/dest-ca-cert createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow route.openshift.io/destination-ca-certificate-secretを Ingress アノテーションに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アノテーションは kubernetes シークレットを参照します。
このアノテーションで参照されているシークレットは、生成されたルートに挿入されます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.1.15. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターが IPv4 および IPv6 デュアルスタックネットワーク用に設定されている場合、クラスターは OpenShift Container Platform ルートによって外部からアクセス可能です。
Ingress Controller は、IPv4 エンドポイントと IPv6 エンドポイントの両方を持つサービスを自動的に提供しますが、シングルスタックまたはデュアルスタックサービス用に Ingress Controller を設定できます。
前提条件
- ベアメタルに OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc) がインストールされている。
手順
Ingress Controller が、IPv4 / IPv6 を介してトラフィックをワークロードに提供するようにするには、
ipFamiliesフィールドおよびipFamilyPolicyフィールドを設定して、サービス YAML ファイルを作成するか、既存のサービス YAML ファイルを変更します。以下に例を示します。サービス YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのリソースは、対応する
endpointsを生成します。Ingress Controller は、endpointslicesを監視するようになりました。endpointsを表示するには、以下のコマンドを入力します。oc get endpoints
$ oc get endpointsCopy to Clipboard Copied! Toggle word wrap Toggle overflow endpointslicesを表示するには、以下のコマンドを入力します。oc get endpointslices
$ oc get endpointslicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
21.2. セキュリティー保護されたルート リンクのコピーリンクがクリップボードにコピーされました!
セキュアなルートは、複数の TLS 終端タイプを使用してクライアントに証明書を提供できます。以下のセクションでは、カスタム証明書を使用して re-encrypt、edge、および passthrough ルートを作成する方法を説明します。
パブリックエンドポイントを使用して Microsoft Azure にルートを作成する場合、リソース名は制限されます。特定の用語を使用するリソースを作成することはできません。Azure が制限する語のリストは、Azure ドキュメントの Resolve reserved resource name errors を参照してください。
21.2.1. カスタム証明書を使用した re-encrypt ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
oc create route コマンドを使用し、カスタム証明書と共に reencrypt TLS termination を使用してセキュアなルートを設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および reencrypt TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。また、Ingress Controller がサービスの証明書を信頼できるように宛先 CA 証明書を指定する必要もあります。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、tls.key、cacert.crt、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のある Service リソースに置き換えます。www.example.com を適切な名前に置き換えます。
reencrypt TLS 終端およびカスタム証明書を使用してセキュアな
Routeリソースを作成します。oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 他のオプションは、
oc create route reencrypt --helpを参照してください。
21.2.2. カスタム証明書を使用した edge ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
oc create route コマンドを使用し、edge TLS termination とカスタム証明書を使用してセキュアなルートを設定できます。edge ルートの場合、Ingress Controller は、トラフィックを宛先 Pod に転送する前に TLS 暗号を終了します。ルートは、Ingress Controller がルートに使用する TLS 証明書およびキーを指定します。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
openssl rsa -in password_protected_tls.key -out tls.key
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および edge TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、tls.key、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のあるサービスの名前に置き換えます。www.example.com を適切な名前に置き換えます。
edge TLS termination およびカスタム証明書を使用して、セキュアな
Routeリソースを作成します。oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 他のオプションは、
oc create route edge --helpを参照してください。
21.2.3. passthrough ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
oc create route コマンドを使用し、passthrough termination を使用してセキュアなルートを設定できます。passthrough termination では、暗号化されたトラフィックが TLS 終端を提供するルーターなしに宛先に直接送信されます。そのため、ルートでキーや証明書は必要ありません。
前提条件
- 公開する必要のあるサービスが必要です。
手順
Routeリソースを作成します。oc create route passthrough route-passthrough-secured --service=frontend --port=8080
$ oc create route passthrough route-passthrough-secured --service=frontend --port=8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Routeリソースを検査すると、以下のようになります。passthrough termination を使用したセキュリティー保護されたルート
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 宛先 Pod は、エンドポイントでトラフィックに証明書を提供します。これは、必須となるクライアント証明書をサポートするための唯一の方法です (相互認証とも呼ばれる)。
21.2.4. 外部管理証明書を使用したルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
TLS シークレット内の外部証明書を使用してルートを保護する機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ルート API の .spec.tls.externalCertificate フィールドを使用して、サードパーティーの証明書管理ソリューションで OpenShift Container Platform ルートを設定できます。シークレットを介して外部で管理されている TLS 証明書を参照できるため、手動での証明書管理が不要になります。外部で管理される証明書を使用するとエラーが減り、証明書の更新がよりスムーズに展開されるため、OpenShift ルーターは更新された証明書を迅速に提供できるようになります。
この機能は、エッジルートと再暗号化ルートの両方に適用されます。
前提条件
-
RouteExternalCertificateフィーチャーゲートを有効にする必要があります。 -
routes/custom-hostに対するcreateおよびupdate権限が必要です。 -
tls.keyキーとtls.crtキーの両方を含む、kubernetes.io/tlsタイプの PEM エンコード形式の有効な証明書/キーペアを含むシークレットが必要です。 - 参照されるシークレットは、保護するルートと同じ namespace に配置する必要があります。
手順
次のコマンドを実行して、シークレットと同じ namespace に
roleを作成し、ルーターサービスアカウントに読み取りアクセスを許可します。oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ --namespace=<current-namespace>
$ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \1 --namespace=<current-namespace>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、シークレットと同じ namespace に
rolebindingを作成し、ルーターサービスアカウントを新しく作成されたロールにバインドします。oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>
$ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シークレットとルートの両方が存在する namespace を指定します。
次の例を使用して、
routeを定義し、証明書を含むシークレットを指定する YAML ファイルを作成します。セキュアなルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シークレットの実際の名前を指定します。
次のコマンドを実行して
routeリソースを作成します。oc apply -f <route.yaml>
$ oc apply -f <route.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 生成された YAML ファイル名を指定します。
シークレットが存在し、証明書/キーペアがある場合、すべての前提条件が満たされていれば、ルーターは生成された証明書を提供します。
.spec.tls.externalCertificate が指定されていないと、ルーターはデフォルトで生成された証明書を使用します。
.spec.tls.externalCertificate フィールドを使用する場合は、.spec.tls.certificate フィールドまたは .spec.tls.key フィールドを指定することはできません。
第22章 Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
22.1. Ingress クラスタートラフィックの設定の概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする以下の方法を提供します。
以下の方法が推奨されます。以下は、これらの方法の優先される順です。
- HTTP/HTTPS を使用する場合は Ingress Controller を使用する。
- HTTPS 以外の TLS で暗号化されたプロトコルを使用する場合、たとえば、SNI ヘッダーを使用する TLS の場合は、Ingress Controller を使用します。
-
それ以外の場合は、ロードバランサー、外部 IP、または
NodePortを使用します。
| 方法 | 目的 |
|---|---|
| HTTP/HTTPS トラフィックおよび HTTPS 以外の TLS で暗号化されたプロトコル (TLS と SNI ヘッダーの使用など) へのアクセスを許可します。 | |
| プールから割り当てられた IP アドレスを使用した非標準ポートへのトラフィックを許可します。ほとんどのクラウドプラットフォームは、ロードバランサーの IP アドレスでサービスを開始する方法を提供します。 | |
| マシンネットワーク上のプールから特定の IP アドレスまたはアドレスへのトラフィックを許可します。ベアメタルインストールまたはベアメタルのようなプラットフォームの場合、MetalLB は、ロードバランサーの IP アドレスを使用してサービスを開始する方法を提供します。 | |
| 特定の IP アドレスを使用した非標準ポートへのトラフィックを許可します。 | |
| クラスターのすべてのノードでサービスを公開します。 |
22.1.1. 比較: 外部 IP アドレスへのフォールトトレランスアクセス リンクのコピーリンクがクリップボードにコピーされました!
外部 IP アドレスへのアクセスを提供する通信メソッドの場合、IP アドレスへのフォールトトレランスアクセスは別の考慮事項となります。以下の機能は、外部 IP アドレスへのフォールトトレランスアクセスを提供します。
- IP フェイルオーバー
- IP フェイルオーバーはノードセットの仮想 IP アドレスのプールを管理します。これは、Keepalived および Virtual Router Redundancy Protocol (VRRP) で実装されます。IP フェイルオーバーはレイヤー 2 のメカニズムのみで、マルチキャストに依存します。マルチキャストには、一部のネットワークに欠点がある場合があります。
- MetalLB
- MetalLB にはレイヤー 2 モードがありますが、マルチキャストは使用されません。レイヤー 2 モードには、1 つのノードで外部 IP アドレスのトラフィックをすべて転送する欠点があります。
- 外部 IP アドレスの手動割り当て
- クラスターを、外部 IP アドレスをサービスに割り当てるために使用される IP アドレスブロックで設定できます。デフォルトでは、この機能は無効にされています。この機能は柔軟性がありますが、クラスターまたはネットワーク管理者に最大の負担をかけます。クラスターは、外部 IP 宛てのトラフィックを受信する準備ができていますが、各顧客は、トラフィックをノードにルーティングする方法を決定する必要があります。
22.2. サービスの ExternalIP の設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、トラフィックをクラスター内のサービスに送信できるクラスター外の IP アドレスブロックを指定できます。
この機能は通常、ベアメタルハードウェアにインストールされているクラスターに最も役立ちます。
22.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- ネットワークインフラストラクチャーは、外部 IP アドレスのトラフィックをクラスターにルーティングする必要があります。
22.2.2. ExternalIP について リンクのコピーリンクがクリップボードにコピーされました!
非クラウド環境の場合、OpenShift Container Platform は、Service オブジェクトの spec.externalIPs[] パラメーターで外部 IP アドレスを指定するための ExternalIP 機能の使用をサポートしています。ExternalIP で設定されたサービスは、type=NodePort を持つサービスと同様に機能し、トラフィックは負荷分散のためにローカルノードに送信されます。
クラウド環境の場合、クラウドの自動デプロイメントのためにロードバランサーサービスを使用し、サービスのエンドポイントをターゲットに設定します。
パラメーターの値を指定すると、OpenShift Container Platform はサービスに追加の仮想 IP アドレスを割り当てます。IP アドレスは、クラスターに定義したサービスネットワークの外部に存在することができます。
ExternalIP はデフォルトで無効になっているため、ExternalIP 機能を有効にすると、外部 IP アドレスへのクラスター内トラフィックがそのサービスに送信されるため、サービスにセキュリティーリスクが生じる可能性があります。この設定は、クラスターユーザーが外部リソース宛ての機密トラフィックをインターセプトできることを意味します。
MetalLB 実装または IP フェイルオーバーデプロイメントのいずれかを使用して、次の方法で ExternalIP リソースをサービスに接続できます。
- 外部 IP の自動割り当て
-
OpenShift Container Platform は、
spec.type=LoadBalancerを設定してServiceオブジェクトを作成する際に、IP アドレスをautoAssignCIDRsCIDR ブロックからspec.externalIPs[]配列に自動的に割り当てます。この設定では、OpenShift Container Platform はロードバランサーサービスタイプのクラウドバージョンを実装し、サービスに IP アドレスを割り当てます。自動割り当てはデフォルトでは無効になっており、クラスター管理者が「ExternalIP の設定」セクションの説明に従い設定する必要があります。 - 外部 IP の手動割り当て
-
OpenShift Container Platform は
Serviceオブジェクトの作成時にspec.externalIPs[]配列に割り当てられた IP アドレスを使用します。別のサービスによってすでに使用されている IP アドレスを指定することはできません。
MetalLB 実装または IP フェイルオーバーデプロイメントのいずれかを使用して外部 IP アドレスブロックをホストした後、外部 IP アドレスブロックがクラスターにルーティングされるようにネットワークインフラストラクチャーを設定する必要があります。この設定は、ノードからのネットワークインターフェイスに IP アドレスが設定されていないことを意味します。トラフィックを処理するには、静的な Address Resolution Protocol (ARP) エントリーなどの方法を使用して、ルーティングと外部 IP へのアクセスを設定する必要があります。
OpenShift Container Platform は以下の機能を追加して Kubernetes の ExternalIP 機能を拡張します。
- 設定可能なポリシーでの、ユーザーによる外部 IP アドレスの使用の制限
- 要求時の外部 IP アドレスのサービスへの自動割り当て
22.2.3. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
22.2.4. ExternalIP の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform での外部 IP アドレスの使用は、cluster という名前の Network.config.openshift.io カスタムリソース (CR) の以下のパラメーターで制御されます。
-
spec.externalIP.autoAssignCIDRsは、サービスの外部 IP アドレスを選択する際にロードバランサーによって使用される IP アドレスブロックを定義します。OpenShift Container Platform は、自動割り当て用の単一 IP アドレスブロックのみをサポートします。手動で ExternalIP をサービスに割り当てる場合は、数に限りのある共有 IP アドレスのポートスペースを管理する必要があるため、この設定はそ手動で設定するよりも少ない手順で行えます。自動割り当てを有効にすると、spec.type=LoadBalancerが設定されたServiceオブジェクトに外部 IP アドレスが割り当てられます。 -
spec.externalIP.policyは、IP アドレスを手動で指定する際に許容される IP アドレスブロックを定義します。OpenShift Container Platform は、spec.externalIP.autoAssignCIDRsパラメーターで定義した IP アドレスブロックにポリシールールを適用しません。
ルーティングが正しく行われると、設定された外部 IP アドレスブロックからの外部トラフィックは、サービスが公開する TCP ポートまたは UDP ポートを介してサービスのエンドポイントに到達できます。
クラスター管理者は、externalIP へのルーティングを設定する必要があります。割り当てる IP アドレスブロックがクラスター内の 1 つ以上のノードで終了することを確認する必要もあります。詳細は、Kubernetes External IPs を参照してください。
OpenShift Container Platform は IP アドレスの自動および手動割り当ての両方をサポートしており、それぞれのアドレスは 1 つのサービスの最大数に割り当てられることが保証されます。この設定により、ポートが他のサービスで公開されているかにかかわらず、各サービスはそれぞれ選択したポートを公開できます。
OpenShift Container Platform の autoAssignCIDRs で定義された IP アドレスブロックを使用するには、ホストのネットワークに必要な IP アドレスの割り当ておよびルーティングを設定する必要があります。
以下の YAML は、外部 IP アドレスが設定されたサービスを説明しています。
spec.externalIPs[] が設定された Service オブジェクトの例
22.2.5. 外部 IP アドレスの割り当ての制限 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、IP アドレスブロックを指定してサービスの IP アドレスを許可または拒否できます。制限は、cluster-admin 権限を持たないユーザーにのみ適用されます。クラスター管理者は、サービスの spec.externalIPs[] フィールドを任意の IP アドレスに常に設定できます。
policy オブジェクトの spec.ExternalIP.policy パラメーターに Classless Inter-Domain Routing (CIDR) アドレスブロックを指定して、IP アドレスポリシーを設定します。
policy オブジェクトとその CIDR パラメーターの JSON 形式の例
ポリシーの制限を設定する際に、以下のルールが適用されます。
-
policyが{}に設定されている場合、spec.ExternalIPs[]を使用してServiceオブジェクトを作成すると、サービスが失敗します。これは、OpenShift Container Platform のデフォルト設定です。policy: nullの場合も同じ動作になります。 policyが設定され、policy.allowedCIDRs[]またはpolicy.rejectedCIDRs[]のいずれかが設定される場合、以下のルールが適用されます。-
allowedCIDRs[]とrejectedCIDRs[]の両方が設定される場合、rejectedCIDRs[]がallowedCIDRs[]よりも優先されます。 -
allowedCIDRs[]が設定される場合、spec.ExternalIPs[]が設定されているServiceオブジェクトの作成は、指定された IP アドレスが許可される場合にのみ正常に実行されます。 -
rejectedCIDRs[]が設定される場合、spec.ExternalIPs[]が設定されているServiceオブジェクトの作成は、指定された IP アドレスが拒否されていない場合にのみ正常に実行されます。
-
22.2.6. ポリシーオブジェクトの例 リンクのコピーリンクがクリップボードにコピーされました!
このセクションの例では、さまざまな spec.externalIP.policy 設定を示します。
以下の例のポリシーは、外部 IP アドレスが指定されたサービスを OpenShift Container Platform が作成できないようにします。
Serviceオブジェクトのspec.externalIPs[]に指定された値を拒否するポリシーの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
allowedCIDRsおよびrejectedCIDRsフィールドの両方が設定されます。許可される、および拒否される CIDR ブロックの両方を含むポリシーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例では、
policyは{}に設定されます。これが設定されている場合、oc get networks.config.openshift.io -o yamlコマンドを使用して設定を表示してもpolicyパラメーターはコマンド出力に表示されません。policy: nullの場合も同じ動作になります。Serviceオブジェクトのspec.externalIPs[]に指定された値を許可するポリシーの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.7. ExternalIP アドレスブロックの設定 リンクのコピーリンクがクリップボードにコピーされました!
ExternalIP アドレスブロックの設定は、cluster という名前の Network カスタムリソース (CR) で定義されます。ネットワーク CR は config.openshift.io API グループに含まれます。
クラスターのインストール時に、Cluster Version Operator (CVO) は cluster という名前のネットワーク CR を自動的に作成します。このタイプのその他の CR オブジェクトの作成はサポートされていません。
以下の YAML は ExternalIP 設定を説明しています。
cluster という名前の network.config.openshift.io CR
以下の YAML は、policy スタンザのフィールドを説明しています。
Network.config.openshift.io policy スタンザ
policy: allowedCIDRs: [] rejectedCIDRs: []
policy:
allowedCIDRs: []
rejectedCIDRs: []
外部 IP 設定の例
外部 IP アドレスプールの予想される複数の設定が以下の例で表示されています。
以下の YAML は、自動的に割り当てられた外部 IP アドレスを有効にする設定を説明しています。
spec.externalIP.autoAssignCIDRsが設定された設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の YAML は、許可された、および拒否された CIDR 範囲のポリシールールを設定します。
spec.externalIP.policyが設定された設定例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.8. クラスターの外部 IP アドレスブロックの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、以下の ExternalIP を設定できます。
-
Serviceオブジェクトのspec.clusterIPフィールドを自動的に設定するために OpenShift Container Platform によって使用される ExternalIP アドレスブロック。 -
IP アドレスを制限するポリシーオブジェクトは
Serviceオブジェクトのspec.clusterIP配列に手動で割り当てられます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
オプション: 現在の外部 IP 設定を表示するには、以下のコマンドを入力します。
oc describe networks.config cluster
$ oc describe networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を編集するには、以下のコマンドを入力します。
oc edit networks.config cluster
$ oc edit networks.config clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように ExternalIP 設定を変更します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
externalIPスタンザの設定を指定します。
更新された ExternalIP 設定を確認するには、以下のコマンドを入力します。
oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'$ oc get networks.config cluster -o go-template='{{.spec.externalIP}}{{"\n"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.2.9. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
22.3. Ingress Controller を使用した Ingress クラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法は Ingress Controller を使用します。
22.3.1. Ingress Controller およびルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は Ingress Controller およびワイルドカード DNS を管理します。
Ingress Controller の使用は、最も一般的な、OpenShift Container Platform クラスターへの外部アクセスを許可する方法です。
Ingress Controller は外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するよう設定されます。これは、HTTP、SNI を使用する HTTPS、SNI を使用する TLS に限定されており、SNI を使用する TLS で機能する Web アプリケーションやサービスには十分な設定です。
管理者と連携して Ingress Controller を設定します。外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するように Ingress Controller を設定します。
管理者はワイルドカード DNS エントリーを作成してから Ingress Controller を設定できます。その後は管理者に問い合わせることなく edge Ingress Controller と連携できます。
デフォルトで、クラスター内のすべての Ingress Controller はクラスター内の任意のプロジェクトで作成されたすべてのルートを許可します。
Ingress Controller:
- デフォルトでは 2 つのレプリカがあるので、これは 2 つのワーカーノードで実行する必要があります。
- 追加のノードにレプリカを組み込むためにスケールアップすることができます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
22.3.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 つ以上のマスターと 1 つ以上のノードを持つ OpenShift Container Platform クラスターと、クラスターへのネットワークアクセス権を持つクラスター外部のシステムを用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
22.3.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトとサービスが存在しない場合は、プロジェクトを作成してからサービスを作成します。
プロジェクトとサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
OpenShift CLI (
oc) をインストールし、クラスター管理者としてログインしている。
手順
oc new-projectコマンドを実行して、サービス用の新しいプロジェクトを作成します。oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが作成されたことを確認するには、以下のコマンドを実行します。
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトで、新規サービスには外部 IP アドレスがありません。
22.3.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
前提条件
- OpenShift Container Platform にログインしている。
手順
公開するサービスが置かれているプロジェクトにログインします。
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc expose serviceコマンドを実行して、ルートを公開します。oc expose service nodejs-ex
$ oc expose service nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが公開されていることを確認するには、
curlなどのツールを使用して、クラスター外からサービスにアクセスできることを確認します。ルートのホスト名を見つけるには、次のコマンドを入力します。
oc get route
$ oc get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが GET 要求に応答することを確認するには、次のコマンドを入力します。
curlコマンドの例curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.5. OpenShift Container Platform での Ingress シャーディング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、Ingress Controller はすべてのルートを提供することも、ルートのサブセットを提供することもできます。デフォルトでは、Ingress Controller は、クラスター内の任意の namespace で作成されたすべてのルートを提供します。別の Ingress Controller をクラスターに追加して、選択した特性に基づくルートのサブセットである シャード を作成することにより、ルーティングを最適化できます。ルートをシャードのメンバーとしてマークするには、ルートまたは namespace の メタデータ フィールドでラベルを使用します。Ingress Controller は、選択式 とも呼ばれる セレクター を使用して、ルートのプール全体からルートのサブセットを選択し、サービスを提供します。
Ingress シャーディングは、受信トラフィックを複数の Ingress Controller 間で負荷分散する場合に、トラフィックを分離して特定の Ingress Controller にルーティングする場合、または次のセクションで説明する他のさまざまな理由で役立ちます。
デフォルトでは、各ルートはクラスターのデフォルトドメインを使用します。ただし、代わりにルーターのドメインを使用するようにルートを設定できます。
22.3.6. Ingress Controller のシャーディング リンクのコピーリンクがクリップボードにコピーされました!
Ingress シャーディング (ルーターシャーディングとも呼ばれます) を使用して、ルート、namespace、またはその両方にラベルを追加することで、一連のルートを複数のルーターに分散できます。Ingress Controller は、対応する一連のセレクターを使用して、指定されたラベルが含まれるルートのみを許可します。各 Ingress シャードは、特定の選択式を使用してフィルタリングされたルートで構成されます。
トラフィックがクラスターに送信される主要なメカニズムとして、Ingress Controller への要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。
- Ingress Controller またはルーターを複数のルートに分散し、変更に対する応答を高速化する。
- 特定のルートに、他のルートとは異なる信頼性保証を割り当てる。
- 特定の Ingress Controller に異なるポリシーを定義することを許可します。
- 特定のルートのみが追加機能を使用することを許可します。
- たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
- Blue-Green デプロイ時に、あるバージョンのアプリケーションから別のバージョンにトラフィックを転送する。
Ingress Controller がシャーディングされると、特定のルートがグループ内の 0 個以上の Ingress Controller に受け入れられます。ルートのステータスから、Ingress Controller がルートを許可したかどうかがわかります。Ingress Controller は、ルートがシャードに固有のものである場合にのみルートを許可します。
シャーディングを使用すると、ルートのサブセットを複数の Ingress Controller に分散できます。ルートのサブセットは、重複なし (従来 のシャーディング) にすることも、重複あり (オーバーラップ シャーディング) にすることもできます。
次の表に、3 つのシャーディング方法の概要を示します。
| シャーディング方法 | 説明 |
|---|---|
| namespace セレクター | Ingress Controller に namespace セレクターを追加すると、namespace セレクターに一致するラベルを持つ namespace 内のすべてのルートが Ingress シャードに追加されます。namespace 内に作成されたすべてのルートを Ingress Controller で提供する場合は、この方法を検討してください。 |
| ルートセレクター | Ingress Controller にルートセレクターを追加すると、ルートセレクターに一致するラベルを持つすべてのルートが Ingress シャードに追加されます。ルートのサブセットのみ、または namespace 内の特定のルートのみを Ingress Controller で提供する場合は、この方法を検討してください。 |
| namespace およびルートセレクター | namespace セレクターとルートセレクター両方の方法で Ingress Controller のスコープを指定します。namespace セレクターとルートセレクター両方の方法の柔軟性が必要な場合は、この方法を検討してください。 |
22.3.6.1. 従来のシャーディングの例 リンクのコピーリンクがクリップボードにコピーされました!
キー値が finance と ops に設定されたラベルセレクター spec.namespaceSelector.matchExpressions を持つ、設定済みの Ingress Controller finops-router の例:
finops-router の YAML 定義の例
キー値が dev に設定されたラベルセレクター spec.namespaceSelector.matchLabels.name を持つ、設定済みの Ingress Controller dev-router の例:
dev-router の YAML 定義の例
すべてのアプリケーションルートが、それぞれ name:finance、name:ops、name:dev などのラベルが付けられた別々の namespace にある場合は、設定によって 2 つの Ingress Controller 間でルートが効果的に分散されます。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。
前のシナリオでは、シャーディングは重複するサブセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。
デフォルト の Ingress Controller は、namespaceSelector または routeSelector フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress Controller からルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューション と「デフォルトの Ingress Controller のシャーディング」のセクションを参照してください。
22.3.6.2. 重複シャーディングの例 リンクのコピーリンクがクリップボードにコピーされました!
キー値が dev と ops に設定されたラベルセレクター spec.namespaceSelector.matchExpressions を持つ、設定済みの Ingress Controller devops-router の例:
devops-router の YAML 定義の例
name:dev および name:ops という 名前の namespace のルートは、2 つの異なる Ingress Controller によって処理されるようになりました。この設定では、ルートのサブセットが重複しています。
重複するルートのサブセットを使用すると、より複雑なルーティングルールを作成できます。たとえば、優先度の低いトラフィックを devops-router に送信しながら、優先度の高いトラフィックを専用の finops-router に迂回させることができます。
22.3.6.3. デフォルトの Ingress Controller のシャーディング リンクのコピーリンクがクリップボードにコピーされました!
新しい Ingress シャードを作成した後に、デフォルトの Ingress Controller と、新しい Ingress シャードの両方により許可されるルートが存在する場合があります。これは、デフォルトの Ingress Controller にセレクターがなく、デフォルトですべてのルートを許可するためです。
namespace セレクターまたはルートセレクターを使用して、Ingress Controller が特定のラベルが割り当てられたルートの処理を制限できます。次の手順では、namespace セレクターを使用して、デフォルトの Ingress Controller が新しく分割された finance、ops、および dev ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。
OpenShift Container Platform のすべての管理ルートを同じ Ingress Controller で保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトの Ingress Controller に追加することは避けてください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - プロジェクト管理者としてログインしている。
手順
次のコマンドを実行して、デフォルトの Ingress Controller を変更します。
oc edit ingresscontroller -n openshift-ingress-operator default
$ oc edit ingresscontroller -n openshift-ingress-operator defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller を編集して、
finance、ops、およびdevラベルのいずれかを持つルートを除外するnamespaceSelectorを含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトの Ingress Controller では、name:finance、name:ops、および name:dev という名前の namespace が提供されなくなります。
22.3.6.4. Ingress シャーディングと DNS リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクト内のルーターごとに個別の DNS エントリーを作成します。ルーターは不明なルートを別のルーターに転送することはありません。
以下の例を考慮してください。
-
Router A はホスト 192.168.0.5 にあり、
*.foo.comのルートを持つ。 -
Router B はホスト 192.168.1.9 にあり、
*.example.comのルートを持つ。
個別の DNS エントリーは、*.foo.com をルーター A をホストするノードに解決し、*.example.com をルーター B をホストするノードに解決する必要があります。
-
*.foo.com A IN 192.168.0.5 -
*.example.com A IN 192.168.1.9
22.3.6.5. ルートラベルを使用した Ingress Controller のシャーディングの設定 リンクのコピーリンクがクリップボードにコピーされました!
ルートラベルを使用した Ingress Controller のシャーディングとは、Ingress Controller がルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
図22.1 ルートラベルを使用した Ingress シャーディング
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
router-internal.yamlファイルを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
Ingress Controller の
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller は、
type: shardedというラベルのある namespace のルートを選択します。router-internal.yamlで設定されたドメインを使用して新しいルートを作成します。oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.6.6. namespace ラベルを使用した Ingress Controller のシャーディングの設定 リンクのコピーリンクがクリップボードにコピーされました!
namespace ラベルを使用した Ingress Controller のシャーディングとは、Ingress Controller が namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
図22.2 namespace ラベルを使用した Ingress シャーディング
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
router-internal.yamlファイルを編集します。cat router-internal.yaml
$ cat router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
Ingress Controller の
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
$ oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller は、
type: shardedというラベルのある namespace セレクターによって選択される namespace のルートを選択します。router-internal.yamlで設定されたドメインを使用して新しいルートを作成します。oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3.6.7. Ingress Controller シャーディングのルート作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法を説明します。
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
hello-openshiftというプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
hello-openshiftというサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow hello-openshift-route.yamlというルート定義を作成します。シャーディング用に作成したルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
hello-openshift-route.yamlを使用してhello-openshiftアプリケーションへのルートを作成します。oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを使用して、ルートのステータスを取得します。
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 結果の
Routeリソースは次のようになります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
関連情報
22.4. Ingress Controller エンドポイント公開戦略の設定 リンクのコピーリンクがクリップボードにコピーされました!
endpointPublishingStrategy は Ingress Controller エンドポイントを他のネットワークに公開し、ロードバランサーの統合を有効にし、他のシステムへのアクセスを提供するために使用されます。
Red Hat OpenStack Platform (RHOSP) では、クラウドプロバイダーがヘルスモニターを作成するように設定されている場合にのみ、LoadBalancerService エンドポイントの公開ストラテジーがサポートされます。RHOSP 16.2 の場合、このストラテジーは Amphora Octavia プロバイダーを使用する場合にのみ可能です。
詳細は、RHOSP インストールドキュメントの「RHOSP Cloud Controller Manager オプションの設定」セクションを参照してください。
22.4.1. Ingress Controller エンドポイントの公開ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
NodePortService エンドポイントの公開ストラテジー
NodePortService エンドポイント公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress Controller を公開します。
この設定では、Ingress Controller のデプロイメントはコンテナーのネットワークを使用します。NodePortService はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理対象の NodePortService のノードポートフィールドへの変更が保持されます。
図22.3 NodePortService の図
前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。
- クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
-
たとえば、クライアントが図に示す IP アドレス
10.0.128.4に接続してダウンしているノードに接続した場合に、ノードポートは、サービスを実行中で利用可能なノードにクライアントを直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、10.0.128.4アドレスがダウンしており、代わりに別の IP アドレスを使用する必要があります。
Ingress Operator は、サービスの .spec.ports[].nodePort フィールドへの更新を無視します。
デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、マネージドのサービスリソースを直接更新できます。
詳細は、NodePort に関する Kubernetes サービスのドキュメント を参照してください。
HostNetwork エンドポイントの公開ストラテジー
HostNetwork エンドポイント公開ストラテジーは、Ingress Controller がデプロイされるノードポートで Ingress Controller を公開します。
HostNetwork エンドポイント公開ストラテジーを持つ Ingress Controller には、ノードごとに 1 つの Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80 および 443 を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。
HostNetwork オブジェクトには、オプションのバインディングポートのデフォルト値が httpPort:80、httpsPort:443、statsPort:1936 の hostNetwork フィールドがあります。ネットワークに異なるバインディングポートを指定することで、HostNetwork ストラテジーに対して、同じノードに複数の Ingress Controller をデプロイできます。
例
22.4.1.1. Ingress Controller エンドポイント公開スコープの内部への設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scope が External に設定されたデフォルトの Ingress Controller が作成されます。クラスター管理者は、External スコープの Ingress Controller を Internal に変更できます。
前提条件
-
ocCLI がインストールされている。
手順
Externalスコープの Ingress Controller をInternalに変更するには、次のコマンドを入力します。oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller のステータスを確認するには、次のコマンドを入力します。
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ステータス状態が
Progressingの場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。oc -n openshift-ingress delete services/router-default
$ oc -n openshift-ingress delete services/router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを削除すると、Ingress Operator はサービスを
Internalとして再作成します。
22.4.1.2. Ingress Controller エンドポイント公開スコープの外部への設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scope が External に設定されたデフォルトの Ingress Controller が作成されます。
Ingress Controller のスコープは、インストール中またはインストール後に Internal になるように設定でき、クラスター管理者は Internal の Ingress Controller を External に変更できます。
一部のプラットフォームでは、サービスを削除して再作成する必要があります。
スコープを変更すると、場合によっては数分間、Ingress トラフィックが中断される可能性があります。これが該当するのは、サービスを削除して再作成する必要があるプラットフォームです。理由は、この手順により、OpenShift Container Platform が既存のサービスロードバランサーのプロビジョニングを解除して新しいサービスロードバランサーをプロビジョニングし、DNS を更新する可能性があるためです。
前提条件
-
ocCLI がインストールされている。
手順
Internalスコープの入力コントローラーをExternalに変更するには、次のコマンドを入力します。oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller のステータスを確認するには、次のコマンドを入力します。
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ステータス状態が
Progressingの場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。oc -n openshift-ingress delete services/router-default
$ oc -n openshift-ingress delete services/router-defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを削除すると、Ingress Operator はサービスを
Externalとして再作成します。
22.4.1.3. Ingress Controller への単一の NodePort サービスの追加 リンクのコピーリンクがクリップボードにコピーされました!
各プロジェクトに NodePort タイプの Service を作成する代わりに、NodePortService エンドポイント公開ストラテジーを使用するカスタム Ingress Controller を作成できます。Ingress シャーディングを介して、すでに HostNetwork Ingress Controller が存在する可能性のあるノードにルートのセットを適用する場合は、ポートの競合を防ぐために、このような Ingress Controller の設定を検討してください。
各プロジェクトに NodePort タイプの Service を設定する前に、次の考慮事項を確認してください。
- Nodeport Ingress Controller ドメインのワイルドカード DNS レコードを作成する必要があります。Nodeport Ingress Controller ルートには、ワーカーノードのアドレスからアクセスできます。ルートに必要な DNS レコードの詳細は、「user-provisioned DNS 要件」を参照してください。
-
サービス用のルートを公開し、カスタム Ingress Controller ドメインの
--hostname引数を指定する必要があります。 -
アプリケーション Pod にアクセスできるようにするには、
NodePortタイプのServiceに割り当てられているポートをルートに追加する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - ワイルドカード DNS レコードが作成されている。
手順
Ingress Controller のカスタムリソース (CR) ファイルを作成します。
IngressControllerオブジェクトの情報を定義する CR ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
IngressControllerCR のカスタムのnameを指定します。- 2
- Ingress Controller が提供する DNS の名前。たとえば、デフォルトの ingresscontroller ドメインは
apps.ipi-cluster.example.comであるため、<custom_ic_domain_name>にはnodeportsvc.ipi-cluster.example.comを指定します。 - 3
- カスタム Ingress Controller を含むノードのラベルを指定します。
- 4
- namespace のセットのラベルを指定します。
<key>:<value>は、キーと値のペアのマップに置き換えます。<key>は新しいラベルの一意の名前、<value>はその値です。たとえば、ingresscontroller: custom-icです。
oc label nodeコマンドを使用してノードにラベルを追加します。oc label node <node_name> <key>=<value>
$ oc label node <node_name> <key>=<value>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<value>は、IngressControllerCR のnodePlacementセクションで指定したキーと値のペアと同じである必要があります。
IngressControllerオブジェクトを作成します。oc create -f <ingress_controller_cr>.yaml
$ oc create -f <ingress_controller_cr>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow IngressControllerCR 用に作成されたサービスのポートを確認します。oc get svc -n openshift-ingress
$ oc get svc -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow router-nodeport-custom-ic3サービスのポート80:32432/TCPを示す出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-internal-default ClusterIP 172.30.195.74 <none> 80/TCP,443/TCP,1936/TCP 223d router-nodeport-custom-ic3 NodePort 172.30.109.219 <none> 80:32432/TCP,443:31366/TCP,1936:30499/TCP 155m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-internal-default ClusterIP 172.30.195.74 <none> 80/TCP,443/TCP,1936/TCP 223d router-nodeport-custom-ic3 NodePort 172.30.109.219 <none> 80:32432/TCP,443:31366/TCP,1936:30499/TCP 155mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいプロジェクトを作成するために、次のコマンドを入力します。
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい namespace にラベルを付けるために、次のコマンドを入力します。
oc label namespace <project_name> <key>=<value>
$ oc label namespace <project_name> <key>=<value>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<key>=<value>は、Ingress Controller CR のnamespaceSelectorセクションの値と同じである必要があります。
クラスター内に新しいアプリケーションを作成します。
oc new-app --image=<image_name>
$ oc new-app --image=<image_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<image_name>の例は、quay.io/openshifttest/hello-openshift:multiarchです。
サービスの
Routeオブジェクトを作成して、Pod がサービスを使用してアプリケーションをクラスターの外部に公開できるようにします。oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>
$ oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記--hostname引数で、カスタム Ingress Controller のドメイン名を指定する必要があります。これを行わない場合、Ingress Operator がデフォルトの Ingress Controller を使用してクラスターのすべてのルートを提供します。ルートのステータスが
Admittedであり、カスタム Ingress Controller のメタデータがルートに含まれていることを確認します。oc get route/hello-openshift -o json | jq '.status.ingress'
$ oc get route/hello-openshift -o json | jq '.status.ingress'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトの
IngressControllerCR を更新して、デフォルトの Ingress Controller がNodePortタイプのServiceを管理しないようにします。他のすべてのクラスタートラフィックは、引き続きデフォルトの Ingress Controller によって監視します。oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'$ oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、DNS エントリーがクラスターの内外にルーティングできることを確認します。このコマンドでは、上記の手順で
oc label nodeコマンドを実行してラベルを追加したノードの IP アドレスが出力されます。dig +short <svc_name>-<project_name>.<custom_ic_domain_name>
$ dig +short <svc_name>-<project_name>.<custom_ic_domain_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターが DNS 解決に外部 DNS サーバーの IP アドレスを使用していることを確認するために、次のコマンドを入力してクラスターの接続を確認します。
curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>
$ curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Hello OpenShift!
Hello OpenShift!Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.5. ロードバランサーを使用した Ingress クラスターの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法では、ロードバランサーを使用します。
22.5.1. ロードバランサーを使用したトラフィックのクラスターへの送信 リンクのコピーリンクがクリップボードにコピーされました!
特定の外部 IP アドレスを必要としない場合、ロードバランサーサービスを OpenShift Container Platform クラスターへの外部アクセスを許可するよう設定することができます。
ロードバランサーサービスは固有の IP を割り当てます。ロードバランサーには単一の edge ルーター IP があります (これは仮想 IP (VIP) の場合もありますが、初期の負荷分散では単一マシンになります。
プールが設定される場合、これはクラスター管理者によってではなく、インフラストラクチャーレベルで実行されます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
22.5.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin usernameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
22.5.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトとサービスが存在しない場合は、プロジェクトを作成してからサービスを作成します。
プロジェクトとサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
OpenShift CLI (
oc) をインストールし、クラスター管理者としてログインしている。
手順
oc new-projectコマンドを実行して、サービス用の新しいプロジェクトを作成します。oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが作成されたことを確認するには、以下のコマンドを実行します。
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトで、新規サービスには外部 IP アドレスがありません。
22.5.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
前提条件
- OpenShift Container Platform にログインしている。
手順
公開するサービスが置かれているプロジェクトにログインします。
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc expose serviceコマンドを実行して、ルートを公開します。oc expose service nodejs-ex
$ oc expose service nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposedCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが公開されていることを確認するには、
curlなどのツールを使用して、クラスター外からサービスにアクセスできることを確認します。ルートのホスト名を見つけるには、次のコマンドを入力します。
oc get route
$ oc get routeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが GET 要求に応答することを確認するには、次のコマンドを入力します。
curlコマンドの例curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.5.5. ロードバランサーサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、ロードバランサーサービスを作成します。
前提条件
- 公開するプロジェクトとサービスがあること。
- クラウドプロバイダーがロードバランサーをサポートしている。
手順
ロードバランサーサービスを作成するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトを読み込みます。
oc project project1
$ oc project project1Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンノードでテキストファイルを開き、以下のテキストを貼り付け、必要に応じてファイルを編集します。
ロードバランサー設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ロードバランサーを通過するトラフィックを特定の IP アドレスに制限するには、Ingress Controller フィールド
spec.endpointPublishingStrategy.loadBalancer.allowedSourceRangesを使用することを推奨します。loadBalancerSourceRangesフィールドを設定しないでください。- ファイルを保存し、終了します。
以下のコマンドを実行してサービスを作成します。
oc create -f <file-name>
$ oc create -f <file-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc create -f mysql-lb.yaml
$ oc create -f mysql-lb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して新規サービスを表示します。
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE egress-2 LoadBalancer 172.30.22.226 ad42f5d8b303045-487804948.example.com 3306:30357/TCP 15mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 有効にされたクラウドプロバイダーがある場合、サービスには外部 IP アドレスが自動的に割り当てられます。
マスターで cURL などのツールを使用し、パブリック IP アドレスを使用してサービスに到達できることを確認します。
curl <public-ip>:<port>
$ curl <public-ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
curl 172.29.121.74:3306
$ curl 172.29.121.74:3306Copy to Clipboard Copied! Toggle word wrap Toggle overflow このセクションの例では、クライアントアプリケーションを必要とする MySQL サービスを使用しています。
Got packets out of orderのメッセージと共に文字ストリングを取得する場合は、このサービスに接続していることになります。MySQL クライアントがある場合は、標準 CLI コマンドでログインします。
mysql -h 172.30.131.89 -u admin -p
$ mysql -h 172.30.131.89 -u admin -pCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>
Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. MySQL [(none)]>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.6. AWS での Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法では、AWS のロードバランサー、具体的には Network Load Balancer (NLB) またはク Classic Load Balancer (CLB) を使用します。どちらのタイプのロードバランサーもクライアントの IP アドレスをノードに転送できますが、CLB にはプロキシープロトコルのサポートが必要です。これは OpenShift Container Platform によって自動的に有効になります。
NLB を使用するように Ingress Controller を設定するには、次の 2 つの方法があります。
-
現在 CLB を使用している Ingress Controller を強制的に置き換える。これにより、
IngressControllerオブジェクトが削除され、新しい DNS レコードが伝達され、NLB がプロビジョニングされている間、停止が発生します。 -
CLB を使用する既存の Ingress Controller を編集して、NLB を使用する。これにより、
IngressControllerオブジェクトを削除して再作成することなく、ロードバランサーが変更されます。
どちらの方法も、NLB から CLB への切り替えに使用できます。
これらのロードバランサーは、新規または既存の AWS クラスターで設定できます。
22.6.1. AWS での Classic Load Balancer タイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、特定のルートまたは Ingress Controller のカスタムタイムアウト期間を設定するためのメソッドを提供します。さらに、AWS Classic Load Balancer (CLB) には独自のタイムアウト期間があり、デフォルトは 60 秒です。
CLB のタイムアウト期間がルートタイムアウトまたは Ingress Controller タイムアウトよりも短い場合、ロードバランサーは接続を途中で終了する可能性があります。ルートと CLB の両方のタイムアウト期間を増やすことで、この問題を防ぐことができます。
22.6.1.1. ルートのタイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。
OpenShift Container Platform クラスターの前にユーザー管理の外部ロードバランサーを設定した場合は、ユーザー管理の外部ロードバランサーのタイムアウト値がルートのタイムアウト値よりも高いことを確認してください。この設定により、クラスターが使用するネットワーク上でのネットワーク輻輳の問題を防ぐことができます。
前提条件
- 実行中のクラスターでデプロイ済みの Ingress Controller が必要になります。
手順
oc annotateコマンドを使用して、ルートにタイムアウトを追加します。oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。
以下の例では、2 秒のタイムアウトを
myrouteという名前のルートに設定します。oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.6.1.2. Classic Load Balancer タイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Classic Load Balancer (CLB) のデフォルトのタイムアウトを設定して、アイドル接続を延長できます。
前提条件
- 実行中のクラスターにデプロイ済みの Ingress Controller がある。
手順
次のコマンドを実行して、デフォルト
ingresscontrollerの AWS 接続アイドルタイムアウトを 5 分に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 次のコマンドを実行して、タイムアウトのデフォルト値を復元します。
oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \ {"connectionIdleTimeout":null}}}}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \ {"connectionIdleTimeout":null}}}}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現在のスコープがすでに設定されている場合を除き、接続タイムアウト値を変更するには scope フィールドを指定する必要があります。デフォルトのタイムアウト値に戻す場合は、scope フィールドを設定する際に再度設定する必要はありません。
22.6.2. ネットワークロードバランサーを使用した AWS での Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。そのような方法の 1 つでは、Network Load Balancer (NLB) を使用します。NLB を新規または既存の AWS クラスターに設定することができます。
22.6.2.1. Ingress Controller を Classic Load Balancer から Network Load Balancer に切り替える リンクのコピーリンクがクリップボードにコピーされました!
Classic Load Balancer (CLB) を使用している Ingress Controller を、AWS の Network Load Balancer (NLB) を使用する Ingress Controller に切り替えることができます。
これらのロードバランサーを切り替えても、IngressController オブジェクトは削除されません。
この手順により、次の問題が発生する可能性があります。
- 新しい DNS レコードの伝播、新しいロードバランサーのプロビジョニング、およびその他の要因により、数分間続く可能性のある停止。この手順を適用すると、Ingress Controller ロードバランサーの IP アドレスや正規名が変更になる場合があります。
- サービスのアノテーションの変更により、ロードバランサーリソースがリークする。
手順
NLB を使用して切り替える既存の Ingress Controller を変更します。この例では、デフォルトの Ingress Controller に
Externalスコープがあり、他のカスタマイズがないことを前提としています。ingresscontroller.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.typeフィールドの値を指定しない場合、Ingress Controller は、インストール時に設定されたクラスターIngress設定のspec.loadBalancer.platform.aws.type値を使用します。ヒントIngress Controller に、ドメインの変更など、更新したい他のカスタマイズがある場合は、代わりに Ingress Controller 定義ファイルを強制的に置き換えることを検討してください。
次のコマンドを実行して、Ingress Controller YAML ファイルに変更を適用します。
oc apply -f ingresscontroller.yaml
$ oc apply -f ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller の更新中は、数分間の停止が予想されます。
22.6.2.2. Network Load Balancer の使用から Classic Load Balancer への Ingress Controller の切り替え リンクのコピーリンクがクリップボードにコピーされました!
Network Load Balancer (NLB) を使用している Ingress Controller を、AWS の Classic Load Balancer (CLB) を使用する Ingress Controller に切り替えることができます。
これらのロードバランサーを切り替えても、IngressController オブジェクトは削除されません。
この手順により、新しい DNS レコードの伝播、新しいロードバランサーのプロビジョニング、およびその他の要因により、数分間続く停止が発生する可能性があります。この手順を適用すると、Ingress Controller ロードバランサーの IP アドレスや正規名が変更になる場合があります。
手順
CLB を使用して切り替える既存の Ingress Controller を変更します。この例では、デフォルトの Ingress Controller に
Externalスコープがあり、他のカスタマイズがないことを前提としています。ingresscontroller.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.typeフィールドの値を指定しない場合、Ingress Controller は、インストール時に設定されたクラスターIngress設定のspec.loadBalancer.platform.aws.type値を使用します。ヒントIngress Controller に、ドメインの変更など、更新したい他のカスタマイズがある場合は、代わりに Ingress Controller 定義ファイルを強制的に置き換えることを検討してください。
次のコマンドを実行して、Ingress Controller YAML ファイルに変更を適用します。
oc apply -f ingresscontroller.yaml
$ oc apply -f ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller の更新中は、数分間の停止が予想されます。
22.6.2.3. Ingress Controller Classic Load Balancer の Network Load Balancer への置き換え リンクのコピーリンクがクリップボードにコピーされました!
Classic Load Balancer (CLB) を使用している Ingress Controller は、AWS の Network Load Balancer (NLB) を使用している Ingress Controller に置き換えることができます。
この手順により、次の問題が発生する可能性があります。
- 新しい DNS レコードの伝播、新しいロードバランサーのプロビジョニング、およびその他の要因により、数分間続く可能性のある停止。この手順を適用すると、Ingress Controller ロードバランサーの IP アドレスや正規名が変更になる場合があります。
- サービスのアノテーションの変更により、ロードバランサーリソースがリークする。
手順
新しいデフォルトの Ingress Controller を含むファイルを作成します。以下の例では、デフォルトの Ingress Controller の範囲が
Externalで、その他のカスタマイズをしていないことを想定しています。ingresscontroller.ymlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトの Ingress Controller が他にカスタマイズされている場合には、それに応じてファイルを修正してください。
ヒントIngress Controller に他のカスタマイズがなく、ロードバランサータイプのみを更新する場合は、「Ingress Controller を Classic Load Balancer から Network Load Balancer に切り替える」に記載の手順に従ってください。
Ingress Controller の YAML ファイルを強制的に置き換えます。
oc replace --force --wait -f ingresscontroller.yml
$ oc replace --force --wait -f ingresscontroller.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller の置き換えが完了するまでお待ちください。数分間の停止が予想されます。
22.6.2.4. 既存 AWS クラスターでの Ingress Controller ネットワークロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
AWS Network Load Balancer (NLB) がサポートする Ingress Controller を既存のクラスターに作成できます。
前提条件
- AWS クラスターがインストールされている。
インフラストラクチャーリソースの
PlatformStatusは AWS である必要があります。PlatformStatusが AWS であることを確認するには、以下を実行します。oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}'$ oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}' AWSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
既存のクラスターの AWS NLB がサポートする Ingress Controller を作成します。
Ingress Controller のマニフェストを作成します。
cat ingresscontroller-aws-nlb.yaml
$ cat ingresscontroller-aws-nlb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターにリソースを作成します。
oc create -f ingresscontroller-aws-nlb.yaml
$ oc create -f ingresscontroller-aws-nlb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
新規 AWS クラスターで Ingress Controller NLB を設定する前に、インストール設定ファイルの作成 手順を完了する必要があります。
22.6.2.5. 新規 AWS クラスターでの Ingress Controller ネットワークロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
新規クラスターに AWS Network Load Balancer (NLB) がサポートする Ingress Controller を作成できます。
前提条件
-
install-config.yamlファイルを作成し、これに対する変更を完了します。
手順
新規クラスターの AWS NLB がサポートする Ingress Controller を作成します。
インストールプログラムが含まれるディレクトリーに切り替え、マニフェストを作成します。
./openshift-install create manifests --dir <installation_directory>
$ ./openshift-install create manifests --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>については、クラスターのinstall-config.yamlファイルが含まれるディレクトリーの名前を指定します。
cluster-ingress-default-ingresscontroller.yamlという名前のファイルを<installation_directory>/manifests/ディレクトリーに作成します。touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>については、クラスターのmanifests/ディレクトリーが含まれるディレクトリー名を指定します。
ファイルの作成後は、以下のようにいくつかのネットワーク設定ファイルが
manifests/ディレクトリーに置かれます。ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml
$ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-ingress-default-ingresscontroller.yaml
cluster-ingress-default-ingresscontroller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow エディターで
cluster-ingress-default-ingresscontroller.yamlファイルを開き、必要な Operator 設定を記述するカスタムリソース (CR) を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
cluster-ingress-default-ingresscontroller.yamlファイルを保存し、テキストエディターを終了します。 -
オプション:
manifests/cluster-ingress-default-ingresscontroller.yamlファイルをバックアップします。インストールプログラムは、クラスターの作成時にmanifests/ディレクトリーを削除します。
22.7. サービスの外部 IP を使用した Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB 実装または IP フェイルオーバーデプロイメントのいずれかを使用して、ExternalIP リソースをサービスに接続し、OpenShift Container Platform クラスター外部のトラフィックでそのサービスを利用できるようにすることができます。この方法で外部 IP アドレスをホストすることは、ベアメタルハードウェアにインストールされたクラスターにのみ適用されます。
トラフィックをサービスにルーティングするには、外部ネットワークインフラストラクチャーを正しく設定する必要があります。
22.7.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
クラスターが ExternalIP が有効にされた状態で設定されている。詳細は、サービスの ExternalIP の設定 を参照してください。
注記Egress IP に同じ ExternalIP を使用しないでください。
22.7.2. ExternalIP のサービスへの割り当て リンクのコピーリンクがクリップボードにコピーされました!
サービスに ExternalIP リソースを割り当てることができます。リソースをサービスに自動的に割り当てるようにクラスターを設定した場合は、ExternalIP をサービスに手動でアタッチする必要がない場合があります。
この手順の例では、IP フェイルオーバー設定を持つクラスター内のサービスに ExternalIP リソースを手動で割り当てるシナリオを使用します。
手順
CLI で次のコマンドを実行して、ExternalIP リソースの互換性のある IP アドレス範囲を確認します。
oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'$ oc get networks.config cluster -o jsonpath='{.spec.externalIP}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記autoAssignCIDRsが設定されていて、ExternalIP リソースのspec.externalIPsの値を指定していないと、OpenShift Container Platform は新しいServiceオブジェクトに ExternalIP を自動的に割り当てます。サービスに ExternalIP リソースを割り当てるには、次のいずれかのオプションを選択します。
新しいサービスを作成する場合は、
spec.externalIPsフィールドに値を指定し、allowedCIDRsパラメーターに 1 つ以上の有効な IP アドレスの配列を指定します。ExternalIP リソースをサポートするサービス YAML 設定ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ExternalIP を既存のサービスに割り当てる場合は、以下のコマンドを入力します。
<name>をサービス名に置き換えます。<ip_address>を有効な ExternalIP アドレスに置き換えます。コンマで区切られた複数の IP アドレスを指定できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'$ oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"mysql-55-rhel7" patched
"mysql-55-rhel7" patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ExternalIP アドレスがサービスに割り当てられていることを確認するには、以下のコマンドを入力します。新規サービスに ExternalIP を指定した場合、まずサービスを作成する必要があります。
oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13m
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE mysql-55-rhel7 172.30.131.89 192.174.120.10 3306/TCP 13mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.8. NodePort を使用した Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法は NodePort を使用します。
22.8.1. NodePort を使用したトラフィックのクラスターへの送信 リンクのコピーリンクがクリップボードにコピーされました!
NodePort-type Service リソースを使用して、クラスター内のすべてのノードの特定のポートでサービスを公開します。ポートは Service リソースの .spec.ports[*].nodePort フィールドで指定されます。
ノードポートを使用するには、追加のポートリソースが必要です。
NodePort は、ノードの IP アドレスの静的ポートでサービスを公開します。NodePort はデフォルトで 30000 から 32767 の範囲に置かれます。つまり、NodePort はサービスの意図されるポートに一致しないことが予想されます。たとえば、ポート 8080 はノードのポート 31020 として公開できます。
管理者は、外部 IP アドレスがノードにルーティングされることを確認する必要があります。
NodePort および外部 IP は独立しており、両方を同時に使用できます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
22.8.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin <user_name>
$ oc adm policy add-cluster-role-to-user cluster-admin <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
22.8.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトとサービスが存在しない場合は、プロジェクトを作成してからサービスを作成します。
プロジェクトとサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
OpenShift CLI (
oc) をインストールし、クラスター管理者としてログインしている。
手順
oc new-projectコマンドを実行して、サービス用の新しいプロジェクトを作成します。oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-appコマンドを使用してサービスを作成します。oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが作成されたことを確認するには、以下のコマンドを実行します。
oc get svc -n <project_name>
$ oc get svc -n <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトで、新規サービスには外部 IP アドレスがありません。
22.8.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose コマンドを使用して、サービスをルートとして公開することができます。
前提条件
- OpenShift Container Platform にログインしている。
手順
公開するサービスが置かれているプロジェクトにログインします。
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションのノードポートを公開するには、次のコマンドを入力して、サービスのカスタムリソース定義 (CRD) を変更します。
oc edit svc <service_name>
$ oc edit svc <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: サービスが公開されるノードポートで利用可能なことを確認するには、以下のコマンドを入力します。
oc get svc -n myproject
$ oc get svc -n myprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s nodejs-ex-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.217.127 <none> 3306/TCP 9m44s nodejs-ex-ingress NodePort 172.30.107.72 <none> 3306:31345/TCP 39sCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション:
oc new-appコマンドによって自動的に作成されたサービスを削除するには、以下のコマンドを入力します。oc delete svc nodejs-ex
$ oc delete svc nodejs-exCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サービスノードポートが
30000 ~ 32767の範囲のポートで更新されていることを確認するには、次のコマンドを入力します。oc get svc
$ oc get svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の出力例では、更新されたポートは
30327です。出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpd NodePort 172.xx.xx.xx <none> 8443:30327/TCP 109s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpd NodePort 172.xx.xx.xx <none> 8443:30327/TCP 109sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.9. ロードバランサーの許可された送信元範囲を使用した Ingress クラスタートラフィックの設定 リンクのコピーリンクがクリップボードにコピーされました!
IngressController の IP アドレス範囲の一覧を指定できます。endpointPublishingStrategy が LoadBalancerService の場合、これにより、ロードバランサーサービスへのアクセスが制限されます。
22.9.1. ロードバランサーの許可されるソース範囲の設定 リンクのコピーリンクがクリップボードにコピーされました!
spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges フィールドを有効にして設定できます。ロードバランサーの許可されるソース範囲を設定することで、Ingress Contoller のロードバランサーへのアクセスを、指定された IP アドレス範囲のリストに制限できます。Ingress Operator はロードバランサー Service を調整し、AllowedSourceRanges に基づいて spec.loadBalancerSourceRanges フィールドを設定します。
以前のバージョンの OpenShift Container Platform で spec.loadBalancerSourceRanges フィールドまたはロードバランサーサービスアノテーション service.beta.kubernetes.io/load-balancer-source-ranges をすでに設定している場合、Ingress Controller はアップグレード後に Progressing=True のレポートを開始します。.これを修正するには、spec.loadBalancerSourceRanges フィールドを上書きし、service.beta.kubernetes.io/load-balancer-source-ranges アノテーションをクリアする AllowedSourceRanges を設定します。Ingress Controller は、再び Progressing=False の報告を開始します。
前提条件
- 実行中のクラスターにデプロイされた Ingress Controller があります。
手順
次のコマンドを実行して、Ingress Controller の許可されるソース範囲 API を設定します。
oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"type":"LoadBalancerService", "loadbalancer": \ {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"type":"LoadBalancerService", "loadbalancer": \ {"scope":"External", "allowedSourceRanges":["0.0.0.0/0"]}}}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 例の値
0.0.0.0/0は、許可されるソース範囲を指定します。
22.9.2. ロードバランサーの許可されたソース範囲への移行 リンクのコピーリンクがクリップボードにコピーされました!
注釈 service.beta.kubernetes.io/load-balancer-source-ranges をすでに設定している場合は、ロードバランサーの許可されたソース範囲に移行できます。AllowedSourceRanges を設定すると、Ingress Controller は AllowedSourceRanges 値に基づいて spec.loadBalancerSourceRanges フィールドを設定し、service.beta.kubernetes.io/load-balancer-source-ranges アノテーションを設定解除します。
以前のバージョンの OpenShift Container Platform で spec.loadBalancerSourceRanges フィールドまたはロードバランサーサービスアノテーション service.beta.kubernetes.io/load-balancer-source-ranges をすでに設定している場合、Ingress Controller はアップグレード後に Progressing=True のレポートを開始します。.これを修正するには、spec.loadBalancerSourceRanges フィールドを上書きし、service.beta.kubernetes.io/load-balancer-source-ranges アノテーションをクリアする AllowedSourceRanges を設定します。Ingress Controller は再び Progressing=False の報告を開始します。
前提条件
-
service.beta.kubernetes.io/load-balancer-source-rangesアノテーションを設定しました。
手順
service.beta.kubernetes.io/load-balancer-source-rangesが設定されていることを確認します。oc get svc router-default -n openshift-ingress -o yaml
$ oc get svc router-default -n openshift-ingress -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/load-balancer-source-ranges: 192.168.0.1/32Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.loadBalancerSourceRangesフィールドが設定されていないことを確認します。oc get svc router-default -n openshift-ingress -o yaml
$ oc get svc router-default -n openshift-ingress -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
... spec: loadBalancerSourceRanges: - 0.0.0.0/0 ...
... spec: loadBalancerSourceRanges: - 0.0.0.0/0 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - クラスターを OpenShift Container Platform 4.16 に更新します。
次のコマンドを実行して、
ingresscontrollerの許可されるソース範囲 API を設定します。oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'$ oc -n openshift-ingress-operator patch ingresscontroller/default \ --type=merge --patch='{"spec":{"endpointPublishingStrategy": \ {"loadBalancer":{"allowedSourceRanges":["0.0.0.0/0"]}}}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 例の値
0.0.0.0/0は、許可されるソース範囲を指定します。
22.10. 既存の Ingress オブジェクトのパッチ適用 リンクのコピーリンクがクリップボードにコピーされました!
オブジェクトを再作成したり、オブジェクトへのサービスを中断したりすることなく、以下の既存の Ingress オブジェクトフィールドを更新または変更できます。
- Specifications
- Host
- Path
- Backend services
- SSL/TLS settings
- アノテーション
22.10.1. Ingress オブジェクトのパッチ適用による ingressWithoutClassName アラートの解決 リンクのコピーリンクがクリップボードにコピーされました!
ingressClassName フィールドは、IngressClass オブジェクトの名前を指定します。各 Ingress オブジェクトの ingressClassName フィールドを定義する必要があります。
Ingress オブジェクトの ingressClassName フィールドを定義していない場合は、ルーティングの問題が発生する可能性があります。24 時間後、ingressWithoutClassName アラートが届き、ingressClassName フィールドを設定するように通知されます。
手順
適切なルーティングと機能性を確保するために、完了した ingressClassName フィールドを使用して Ingress オブジェクトにパッチを適用します。
すべての
IngressClassオブジェクトをリスト表示します。oc get ingressclass
$ oc get ingressclassCopy to Clipboard Copied! Toggle word wrap Toggle overflow 全 namespace 内の
Ingressオブジェクトをすべてリスト表示します。oc get ingress -A
$ oc get ingress -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingressオブジェクトにパッチを適用します。oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'$ oc patch ingress/<ingress_name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow <ingress_name>はIngressオブジェクトの名前に置き換えます。このコマンドは、Ingressオブジェクトにパッチを適用して、目的の Ingress クラス名を含めます。
第23章 Kubernetes NMState リンクのコピーリンクがクリップボードにコピーされました!
23.1. ノードのネットワーク状態と設定の監視と更新 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes NMState Operator をインストールしたら、Operator を使用してクラスターのノードのネットワーク状態とネットワーク設定を監視および更新できます。
NMState Operator のインストール方法の詳細は、Kubernetes NMState Operator を参照してください。
br-ex ブリッジ (OVN-Kubernetes によって管理される Open vSwitch ブリッジ) を変更する設定を指定することはできません。ただし、カスタマイズした br-ex ブリッジを設定することはできます。
詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。
23.1.1. CLI を使用したノードのネットワーク状態の表示 リンクのコピーリンクがクリップボードにコピーされました!
ノードのネットワーク状態は、クラスター内のすべてのノードのネットワーク設定です。NodeNetworkState オブジェクトはクラスター内のすべてのノードにあります。このオブジェクトは定期的に更新され、ノードのネットワークの状態を取得します。
手順
クラスターのすべての
NodeNetworkStateオブジェクトをリスト表示します。oc get nns
$ oc get nnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow NodeNetworkStateオブジェクトを検査して、そのノードにネットワークを表示します。この例の出力は、明確にするために編集されています。oc get nns node01 -o yaml
$ oc get nns node01 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.1.2. Web コンソールからのノードのネットワーク状態の表示 リンクのコピーリンクがクリップボードにコピーされました!
管理者は、OpenShift Container Platform Web コンソールを使用して、NodeNetworkState リソースとネットワークインターフェイスを観察し、ネットワークの詳細にアクセスできます。
手順
Networking → NodeNetworkState に移動します。
NodeNetworkState ページでは、
NodeNetworkStateリソースと、ノード上に作成された対応するインターフェイスのリストを表示できます。Interface state、Interface type、および IP に基づく フィルター、または Name または Label の条件に基づく検索バーを使用して、表示されるNodeNetworkStateリソースを絞り込むことができます。-
NodeNetworkStateリソースに関する詳細情報にアクセスするには、Name 列にリストされているNodeNetworkStateリソース名をクリックします。 -
NodeNetworkStateリソースの Network Details セクションをデプロイメントして表示するには、> アイコンをクリックします。あるいは、Network interface 列の下の各インターフェイスタイプをクリックして、ネットワークの詳細を表示することもできます。
23.1.3. NodeNetworkConfigurationPolicy マニフェストを作成します。 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルは、Kubernetes NMState Operator が OpenShift Container Platform クラスター内に存在するノードのネットワークを設定するために使用するポリシーを定義します。
ノードのネットワークポリシーをノードに適用すると、Kubernetes NMState Operator によって、ノードのネットワークポリシーの詳細に従ってノードのネットワークが設定されます。
OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して NNCP を作成できます。インストール後のタスクとして、NNCP を作成したり、既存の NNCP を編集したりできます。
NNCP を作成する前に、「各種インターフェイスのポリシー設定例」のドキュメントを一読してください。
NNCP を削除する必要がある場合は、oc delete nncp コマンドを使用して削除アクションを完了できます。ただし、このコマンドではブリッジインターフェイスなどのオブジェクトは削除されません。
ノードにインターフェイスを追加したノードネットワークポリシーを削除しても、そのノード上のポリシー設定は変更されません。同様に、インターフェイスを削除してもポリシーは削除されません。これは、Pod またはノードが再起動されるたびに、Kubernetes NMState Operator が、削除されたインターフェイスを再度追加するためです。
NNCP、ノードネットワークポリシー、およびインターフェイスを実際に削除するには、通常、次の操作が必要です。
-
NNCP を編集し、ファイルからインターフェイスの詳細を削除します。ファイルから
name、state、typeパラメーターは削除しないでください。 -
NNCP の
interfaces.stateセクションにstate: absentを追加します。 -
oc apply -f <nncp_file_name>を実行します。Kubernetes NMState Operator がクラスター内の各ノードにノードネットワークポリシーを適用すると、各ノードに存在するすべてのインターフェイスが absent とマークされます。 -
oc delete nncpを実行して NNCP を削除します。
関連情報
23.1.4. Web コンソールからのポリシーの管理 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して、ノードからのインターフェイスの追加または削除など、ノードネットワーク設定を更新できます。Web コンソールからポリシーを管理するには、Networking メニューの NodeNetworkConfigurationPolicy ページで作成されたポリシーのリストにアクセスします。このページでは、ポリシーを作成、更新、監視、削除できます。
23.1.4.1. ポリシーステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy ページからポリシーのステータスを監視できます。このページには、クラスター内に作成されたすべてのポリシーが次の列を含む表形式で表示されます。
- 名前
- 作成されたポリシーの名前。
- 一致したノード
- ポリシーが適用されるノードの数。これは、ノードセレクターに基づくノードのサブセット、またはクラスター上のすべてのノードのいずれかになります。
- ノードのネットワーク状態
- 一致したノードの実行状態。制定状態をクリックすると、ステータスの詳細情報が表示されます。
目的のポリシーを見つけるには、Filter オプションを使用するか、検索オプションを使用して、制定状態に基づいてリストをフィルターできます。
23.1.4.2. ポリシーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールでフォームまたは YAML を使用してポリシーを作成できます。
手順
- Networking → NodeNetworkConfigurationPolicy に移動します。
NodeNetworkConfigurationPolicy ページで Create をクリックし、From Form オプションを選択します。
既存のポリシーがない場合は、Create NodeNetworkConfigurationPolicy をクリックして、フォームを使用してポリシーを作成することもできます。
注記YAML を使用してポリシーを作成するには、Create をクリックし、With YAML オプションを選択します。次の手順は、フォームを使用してポリシーを作成する場合にのみ適用されます。
- オプション: Apply this NodeNetworkConfigurationPolicy only to specific subsets of nodes using the node selector チェックボックスをオンにして、ポリシーを適用する必要があるノードを指定します。
- Policy name フィールドにポリシー名を入力します。
- オプション: Description フィールドにポリシーの説明を入力します。
オプション: Policy Interface(s) セクションでは、編集可能なフィールドにプリセット値が設定されたブリッジインターフェイスがデフォルトで追加されます。次の手順を実行して値を編集します。
- Interface name フィールドにインターフェイスの名前を入力します。
- Network state ドロップダウンからネットワーク状態を選択します。デフォルトで選択されている値は Up です。
Type ドロップダウンからインターフェイスのタイプを選択します。使用可能な値は、Bridge、Bonding、および Ethernet です。デフォルトで選択されている値は Bridge です。
注記フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集できません。
オプション: IP 設定セクションで、IPv4 チェックボックスをオンにしてインターフェイスに IPv4 アドレスを割り当て、IP アドレス割り当ての詳細を設定します。
- IP address をクリックしてインターフェイスを静的 IP アドレスで設定するか、DHCP をクリックして IP アドレスを自動割り当てします。
IP address オプションを選択した場合は、IPV4 address フィールドに IPv4 アドレスを、Prefix length フィールドに接頭辞長を入力します。
DHCP オプションを選択した場合は、無効にするオプションのチェックを外します。使用可能なオプションは、Auto-DNS、Auto-routes、および Auto-gateway です。すべてのオプションがデフォルトで選択されています。
- オプション: Port フィールドにポート番号を入力します。
- オプション: STP を有効にするには、Enable STP チェックボックスをオンにします。
- オプション: ポリシーにインターフェイスを追加するには、Add another interface to the policy をクリックします。
- オプション: ポリシーからインターフェイスを削除するには、インターフェイスの横にあるアイコン をクリックします。
注記または、ページ上部の Edit YAML をクリックして、YAML を使用してフォームの編集を続けることもできます。
- Create をクリックしてポリシーの作成を完了します。
23.1.5. ポリシーの更新 リンクのコピーリンクがクリップボードにコピーされました!
23.1.5.1. フォームを使用してポリシーを更新する リンクのコピーリンクがクリップボードにコピーされました!
手順
- Networking → NodeNetworkConfigurationPolicy に移動します。
-
NodeNetworkConfigurationPolicy ページで、編集するポリシーの横にあるアイコン
を選択し、Edit をクリックします。
- 更新するフィールドを編集します。
- Save をクリックします。
フォームを使用した VLAN インターフェイスの追加はサポートされていません。VLAN インターフェイスを追加するには、YAML を使用してポリシーを作成する必要があります。ポリシーを追加すると、フォームを使用してポリシーを編集することはできません。
23.1.5.2. YAML を使用したポリシーの更新 リンクのコピーリンクがクリップボードにコピーされました!
手順
- Networking → NodeNetworkConfigurationPolicy に移動します。
- NodeNetworkConfigurationPolicy ページで、編集するポリシーの Name 列の下にあるポリシー名をクリックします。
- YAML タブをクリックし、YAML を編集します。
- Save をクリックします。
23.1.5.3. ポリシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
手順
- Networking → NodeNetworkConfigurationPolicy に移動します。
-
NodeNetworkConfigurationPolicy ページで、削除するポリシーの横にあるアイコン
を選択し、Delete をクリックします。
- ポップアップウィンドウで、削除を確認するポリシー名を入力し、Delete をクリックします。
23.1.6. CLI を使用したポリシーの管理 リンクのコピーリンクがクリップボードにコピーされました!
23.1.6.1. ノード上でのインターフェイスの作成 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy (NNCP) マニフェストをクラスターに適用して、クラスター内のノードにインターフェイスを作成します。マニフェストには、インターフェイスの要求された設定の詳細が含まれます。
デフォルトでは、マニフェストはクラスター内のすべてのノードに適用されます。インターフェイスを特定ノードに追加するには、ノードセレクターの spec: nodeSelector パラメーターおよび適切な <key>:<value> を追加します。
複数の nmstate 対応ノードを同時に設定できます。この設定は、並列のノードの 50% に適用されます。このストラテジーでは、ネットワーク接続に障害が発生した場合にクラスター全体が使用できなくなるのを回避します。クラスターの特定の部分にポリシー設定を並行して適用するには、NodeNetworkConfigurationPolicy マニフェスト設定ファイルで maxUnavailable パラメーターを使用します。
ノードが 2 つある場合に、maxUnavailable パラメーターを 50% に設定した NNCP マニフェストをこれらのノードに適用すると、1 つのノードに NNCP 設定が反映されます。その後、maxUnavailable パラメーターを 50% に設定した追加の NNCP マニフェストファイルを導入すると、この NCCP は最初の NNCP とは別に適用されます。つまり、2 つの NNCP マニフェストによってノードに不適切な設定が適用されると、クラスターの半分を確実に機能させることができなくなります。
手順
NodeNetworkConfigurationPolicyマニフェストを作成します。以下の例は、すべてのワーカーノードで Linux ブリッジを設定し、DNS リゾルバーを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- オプション: ポリシー設定を同時に適用できる nmstate 対応ノードの最大数を指定します。このパラメーターは、
"10%"などのパーセンテージ値 (文字列)、または3などの絶対値 (数値) のいずれかに設定できます。 - 5
- オプション: インターフェイスの人間が判読できる説明。
- 6
- オプション:DNS サーバーの検索およびサーバー設定を指定します。
ノードのネットワークポリシーを作成します。
oc apply -f br1-eth1-policy.yaml
$ oc apply -f br1-eth1-policy.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードネットワーク設定ポリシーマニフェストのファイル名。
関連情報
23.1.6.2. ノード上でのノードネットワークポリシー更新の確認 リンクのコピーリンクがクリップボードにコピーされました!
ノードネットワークポリシーを適用する際に、NodeNetworkConfigurationEnactment オブジェクトがクラスター内のすべてのノードについて作成されます。ノードネットワーク設定の enactment (実行) は、そのノードでのポリシーの実行ステータスを表す読み取り専用オブジェクトです。ポリシーがノードに適用されない場合、そのノードの enactment (実行) にはトラブルシューティングのためのトレースバックが含まれます。
手順
ポリシーがクラスターに適用されていることを確認するには、ポリシーとそのステータスをリスト表示します。
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ポリシーの設定に想定されている以上の時間がかかる場合は、特定のポリシーの要求される状態とステータスの状態を検査できます。
oc get nncp <policy> -o yaml
$ oc get nncp <policy> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ポリシーのすべてのノード上での設定に想定されている以上の時間がかかる場合は、クラスターの enactment (実行) のステータスをリスト表示できます。
oc get nnce
$ oc get nnceCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: 特定の enactment (実行) の設定 (失敗した設定のエラーレポートを含む) を表示するには、以下を実行します。
oc get nnce <node>.<policy> -o yaml
$ oc get nnce <node>.<policy> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
23.1.6.3. ノードからインターフェイスの削除 リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy オブジェクトを編集し、インターフェイスの state を absent に設定して、クラスターの 1 つ以上のノードからインターフェイスを削除できます。
ノードからインターフェイスを削除しても、ノードのネットワーク設定は以前の状態に自動的に復元されません。以前の状態に復元する場合、そのノードのネットワーク設定をポリシーで定義する必要があります。
ブリッジまたはボンディングインターフェイスを削除すると、そのブリッジまたはボンディングインターフェイスに以前に接続されたか、それらの下位にあるノード NIC は down の状態になり、到達できなくなります。接続が失われないようにするには、同じポリシーでノード NIC を設定し、ステータスを up にし、DHCP または静的 IP アドレスのいずれかになるようにします。
インターフェイスを追加したポリシーを削除しても、ノード上のポリシーの設定は変更されません。NodeNetworkConfigurationPolicy はクラスターのオブジェクトですが、このオブジェクトは要求される設定のみを表します。同様に、インターフェイスを削除してもポリシーは削除されません。
手順
インターフェイスの作成に使用する
NodeNetworkConfigurationPolicyマニフェストを更新します。以下の例は Linux ブリッジを削除し、接続が失われないように DHCP でeth1NIC を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では
node-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 4
- 状態を
absentに変更すると、インターフェイスが削除されます。 - 5
- ブリッジインターフェイスから接続が解除されるインターフェイスの名前。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- インターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。
ノード上でポリシーを更新し、インターフェイスを削除します。
oc apply -f <br1-eth1-policy.yaml>
$ oc apply -f <br1-eth1-policy.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーマニフェストのファイル名。
23.1.7. 異なるインターフェイスのポリシー設定の例 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーをノードに適用する場合は、さまざまな NodeNetworkConfigurationPolicy (NNCP) マニフェスト設定例を読む前に、クラスターが最適なパフォーマンス状態で実行されるように次の要素を考慮してください。
-
ポリシーを複数のノードに適用する必要がある場合は、ターゲットノードごとに
NodeNetworkConfigurationPolicyマニフェストを作成します。Kubernetes NMState Operator は、定義済みの NNCP を持つ各ノードにポリシーを不特定の順序で適用します。この方法でポリシーのスコープを設定すると、ポリシーの適用にかかる時間が短縮されますが、クラスターの設定にエラーがある場合はクラスター全体が停止するリスクがあります。この種のエラーを回避するには、最初に一部のノードに NNCP を適用し、これらのノードに対して NNCP が正しく設定されていることを確認してから、残りのノードにポリシーを適用します。 -
多数のノードにポリシーを適用する必要があるが、すべてのノードに対して 1 つの NNCP のみを作成する場合、Kubernetes NMState Operator は各ノードにポリシーを順番に適用します。クラスターの設定ファイルの
maxUnavailableパラメーターを使用して、ターゲットノードに対するポリシー適用の速度と範囲を設定できます。パラメーターのパーセンテージ値を低く設定すると、ポリシー適用を受信しているノードのごく一部に障害が影響する場合に、クラスター全体の障害が発生するリスクを軽減できます。 -
2 つの NNCP マニフェストで
maxUnavailableパラメーターを50%に設定すると、ポリシー設定がクラスター内のノードの 100% に適用されます。 - ノードが再起動すると、Kubernetes NMState Operator はノードにポリシーを適用する順序を制御できなくなります。Kubernetes NMState Operator は、相互依存するポリシーを順番に適用する場合があります。その結果、ネットワークオブジェクトがデグレード状態になることがあります。
- 関連するすべてのネットワーク設定を 1 つのポリシーで指定することを検討してください。
23.1.7.1. 例: イーサネットインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノードにイーサネットインターフェイスを作成します。
以下の YAML ファイルは、イーサネットインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、イーサネットネットワークインターフェイスを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。
23.1.7.2. 例: Linux ブリッジインターフェイスノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノード上に Linux ブリッジインターフェイスを作成します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。 - 10
- この例では
stpを無効にします。 - 11
- ブリッジが接続されるノードの NIC。
23.1.7.3. 例: VLAN インターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してクラスター内のノード上に VLAN インターフェイスを作成します。
1 つの NodeNetworkConfigurationPolicy マニフェストで、ノードの VLAN インターフェイスに関連するすべての設定を定義します。たとえば、同じ NodeNetworkConfigurationPolicy マニフェストで、ノードの VLAN インターフェイスと VLAN インターフェイスの関連ルートを定義します。
ノードが再起動すると、Kubernetes NMState Operator はポリシーを適用する順序を制御できません。したがって、関連するネットワーク設定に別々のポリシーを使用すると、Kubernetes NMState Operator がこれらのポリシーを順番に適用するため、ネットワークオブジェクトがデグレード状態になる可能性があります。
以下の YAML ファイルは、VLAN インターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。ベアメタルにデプロイする場合、
<interface_name>.<vlan_number>VLAN 形式のみがサポートされます。 - 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。以下の例では VLAN を作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- VLAN が接続されているノードの NIC。
- 9
- VLAN タグ。
23.1.7.4. 例: ボンドインターフェイスノードネットワークの設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストをクラスターに適用してノード上にボンドインターフェイスを作成します。
OpenShift Container Platform は以下の bond モードのみをサポートします。
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
その他のボンディングモードはサポートされていません。
以下の YAML ファイルは、ボンドインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4
- インターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。この例では、ボンドを作成します。
- 7
- 作成後のインターフェイスの要求された状態。
- 8
- オプション:
dhcpを使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。 - 9
- この例では
ipv4を有効にします。 - 10
- ボンドのドライバーモード。この例では、アクティブなバックアップモードを使用します。
- 11
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 12
- ボンド内の下位ノードの NIC。
- 13
- オプション: ボンドの Maximum Transmission Unit (MTU)指定がない場合、この値はデフォルトで
1500に設定されます。
23.1.7.5. 例: 同じノードネットワーク設定ポリシーでの複数のインターフェイス リンクのコピーリンクがクリップボードにコピーされました!
同じノードネットワーク設定ポリシーで複数のインターフェイスを作成できます。これらのインターフェイスは相互に参照でき、単一のポリシーマニフェストを使用してネットワーク設定をビルドし、デプロイできます。
以下の YAML ファイルの例では、2 つの NIC 間に bond10 という名前のボンドと、ボンドに接続する bond10.103 という名前の VLAN を作成します。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例では、
hostnameノードセレクターを使用します。 - 4 11
- インターフェイスの名前。
- 5 12
- オプション: 人間が判読できるインターフェイスの説明。
- 6 13
- インターフェイスのタイプ。
- 7 14
- 作成後のインターフェイスの要求された状態。
- 8
- ボンドのドライバーモード。
- 9
- オプション: この例では、miimon を使用して 140ms ごとにボンドリンクを検査します。
- 10
- ボンド内の下位ノードの NIC。
- 15
- VLAN が接続されているノードの NIC。
- 16
- VLAN タグ。
- 17
- オプション: dhcp を使用しない場合は、静的 IP を設定するか、IP アドレスなしでインターフェイスを出ることができます。
- 18
- この例では ipv4 を有効にします。
23.1.7.6. 例: Virtual Function のノードネットワーク設定ポリシー (テクノロジープレビュー) リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy マニフェストを適用して、既存のクラスター内の Single Root I/O Virtualization (SR-IOV) ネットワーク Virtual Function (VF) のホストネットワーク設定を更新します。
SR-IOV ネットワーク VF のホストネットワーク設定の更新は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
NodeNetworkConfigurationPolicy マニフェストを既存のクラスターに適用して、次のタスクを完了できます。
- VF の QoS ホストネットワークを設定して、パフォーマンスを最適化します。
- ネットワークインターフェイスの VF を追加、削除、または更新します。
- VF ボンディング設定を管理します。
SR-IOV Network Operator を通じて管理もされる物理機能で NMState を使用して SR-IOV VF のホストネットワーク設定を更新するには、関連する SriovNetworkNodePolicy リソースの externallyManaging パラメーターを true に設定する必要があります。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VF の QoS ポリシーを定義するマニフェストの例です。このファイルにはサンプル値が含まれていますが、これは独自の情報に置き換える必要があります。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
workerロールを持つすべてのノードに適用されます。 - 4
- 物理機能 (PF) ネットワークインターフェイスの名前。
- 5
- オプション: 人間が判読できるインターフェイスの説明。
- 6
- インターフェイスのタイプ。
- 7
- 設定後のインターフェイスの要求された状態。
- 8
- VF の総数。
- 9
- ID
0を持つ VF を識別します。 - 10
- VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。
次の YAML ファイルは、VF 上に VLAN インターフェイスを作成し、それをボンディングされたネットワークインターフェイスに追加するマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。 - 3
- この例は、
workerロールを持つすべてのノードに適用されます。 - 4
- VF ネットワークインターフェイスの名前。
- 5
- VLAN ネットワークインターフェイスの名前。
- 6
- VLAN インターフェイスがアタッチされている VF ネットワークインターフェイス。
- 7
- ボンディングネットワークインターフェイスの名前。
- 8
- オプション: 人間が判読できるインターフェイスの説明。
- 9
- インターフェイスのタイプ。
- 10
- 設定後のインターフェイスの要求された状態。
- 11
- ボンディングのボンディングポリシー。
- 12
- 割り当てられたプライマリーボンディングポート。
- 13
- ボンディングされたネットワークインターフェイスのポート。
- 14
- この例では、この VLAN ネットワークインターフェイスが、追加インターフェイスとしてボンディングされたネットワークインターフェイスに追加されています。
23.1.7.7. 例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス リンクのコピーリンクがクリップボードにコピーされました!
NodeNetworkConfigurationPolicy カスタムリソース (CR) を適用して、Virtual Routing and Forwarding (VRF) インスタンスをネットワークインターフェイスに関連付けます。
VRF インスタンスとネットワークインターフェイスの関連付けは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
VRF インスタンスをネットワークインターフェイスに関連付けることにより、トラフィックの分離、独立したルーティングの決定、およびネットワークリソースの論理的な分離をサポートできます。
仮想ルート転送 (VRF) を設定する場合、VRF 値を 1000 未満のテーブル ID に変更する必要があります。1000 より大きい値は OpenShift Container Platform 用に予約されているためです。
ベアメタル環境では、MetalLB を使用して、VRF インスタンスに属するインターフェイスを通じてロードバランサーサービスを通知できます。詳細は、関連情報 セクションを参照してください。
次の YAML ファイルは、VRF インスタンスをネットワークインターフェイスに関連付ける例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
23.1.8. ノード上に IP over InfiniBand インターフェイスを作成する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールでは、InfiniBand (IPoIB) モードをサポートする NVIDIA Network Operator などの Red Hat 認定サードパーティー Operator をインストールできます。サードパーティー Operator は、通常、OpenShift Container Platform クラスター内のリソースを管理するために他のベンダーのインフラストラクチャーと組み合わせて使用します。クラスター内のノードに IPoIB インターフェイスを作成するには、NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルで InfiniBand (IPoIB) インターフェイスを定義する必要があります。
OpenShift Container Platform のドキュメントでは、NodeNetworkConfigurationPolicy (NNCP) マニフェストファイルで IPoIB インターフェイス設定を定義する方法についてのみ説明しています。設定手順の大部分については、NVIDIA およびその他のサードパーティーベンダーのドキュメントを参照してください。Red Hat のサポートは、NNCP 設定以外には適用されません。
NVIDIA Operator の詳細は、Getting Started with Red Hat OpenShift (NVIDIA Docs Hub) を参照してください。
前提条件
- IPoIB インターフェイスをサポートする Red Hat 認定サードパーティー Operator をインストールした。
手順
NodeNetworkConfigurationPolicy(NNCP) マニフェストファイルを作成または編集し、ファイル内で IPoIB インターフェイスを指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
datagramは IPoIB インターフェイスのデフォルトモードであり、このモードではパフォーマンスとレイテンシーが最適化されます。connectedモードはサポートされているモードですが、周辺ネットワークデバイスとのノードの接続性を高めるために最大転送単位 (MTU) 値を調整する必要がある場合にのみ、このモードを使用することを検討してください。- 2
- 文字列または整数値をサポートします。このパラメーターは、NVIDIA などのサードパーティーベンダーとの認証および暗号化通信を目的としたインターフェイスの保護キー (P-key) を定義します。
Noneおよび0xffffの値は、InfiniBand システムの基本インターフェイスの保護キーを示します。 - 3
- サポートされている値は、
name、デフォルト値、およびmac-addressです。name値は、指定されたインターフェイス名を持つインターフェイスに設定を適用します。 - 4
- インターフェイスの MAC アドレスを指定します。IP-over-InfiniBand (IPoIB) インターフェイスの場合、アドレスは 20 バイトの文字列です。
- 5
- インターフェイスのタイプを
infinibandに設定します。
次のコマンドを実行して、クラスター内の各ノードに NNCP 設定を適用します。Kubernetes NMState Operator は、各ノードに IPoIB インターフェイスを作成できます。
$ oc apply -f <nncp_file_name>
$ oc apply -f <nncp_file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<nncp_file_name>は、NNCP ファイルの名前に置き換えます。
23.1.9. ブリッジに接続された NIC の静的 IP の取得 リンクのコピーリンクがクリップボードにコピーされました!
NIC の静的 IP のキャプチャーは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
23.1.9.1. 例: ブリッジに接続された NIC から静的 IP アドレスを継承する Linux ブリッジインターフェイスノードネットワーク設定ポリシー リンクのコピーリンクがクリップボードにコピーされました!
クラスター内のノードに Linux ブリッジインターフェイスを作成し、単一の NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して NIC の静的 IP 設定をブリッジに転送します。
以下の YAML ファイルは、Linux ブリッジインターフェイスのマニフェストの例です。これには、独自の情報で置き換える必要のあるサンプルの値が含まれます。
- 1
- ポリシーの名前。
- 2
- オプション:
nodeSelectorパラメーターを含めない場合、ポリシーはクラスター内のすべてのノードに適用されます。この例ではnode-role.kubernetes.io/worker: ""ノードセレクターを使用し、クラスター内のすべてのワーカーノードを選択します。 - 3
- ブリッジを接続するノード NIC への参照。
- 4
- インターフェイスのタイプ。この例では、ブリッジを作成します。
- 5
- ブリッジインターフェイスの IP アドレス。この値は、
spec.capture.eth1-nicエントリーにより参照される NIC の IP アドレスと一致します。 - 6
- ブリッジが接続されるノードの NIC。
23.1.10. 例: IP 管理 リンクのコピーリンクがクリップボードにコピーされました!
次の設定スニペットの例は、さまざまな IP 管理方法を示しています。
これらの例では、ethernet インターフェイスタイプを使用して、ポリシー設定に関連するコンテキストを表示しつつ、サンプルを単純化します。これらの IP 管理のサンプルは、他のインターフェイスタイプでも使用できます。
23.1.10.1. 静的 リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、イーサネットインターフェイスで IP アドレスを静的に設定します。
- 1
- この値を、インターフェイスの静的 IP アドレスに置き換えます。
23.1.10.2. IP アドレスなし リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットでは、インターフェイスに IP アドレスがないことを確認できます。
インターフェイスを無効にするために ipv4.enabled パラメーターと ipv6.enabled パラメーターの両方を false に設定する場合は、必ず state パラメーターを up に設定してください。この設定で state: down を設定すると、自動 DHCP 割り当てによりインターフェイスは DHCP IP アドレスを受け取ります。
23.1.10.3. 動的ホストの設定 リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、動的 IP アドレス、ゲートウェイアドレス、および DNS を使用するイーサネットインターフェイスを設定します。
以下のスニペットは、動的 IP アドレスを使用しますが、動的ゲートウェイアドレスまたは DNS を使用しないイーサネットインターフェイスを設定します。
23.1.10.4. メディアアクセス制御 (MAC) アドレス リンクのコピーリンクがクリップボードにコピーされました!
ネットワークインターフェイスの名前を使用する代わりに、MAC アドレスを使用してネットワークインターフェイスを識別することができます。ネットワークインターフェイス名は、オペレーティングシステムの設定の変更など、さまざまな理由で変更される可能性があります。一方で、各ネットワークインターフェイスには、変更されない一意の MAC アドレスがあります。そのため、MAC アドレスを使用すると、特定のネットワークインターフェイスをより永続的に識別すことができます。
identifier パラメーターでサポートされている値は、デフォルトの name 値と mac-address 値です。name 値は、指定されたインターフェイス名を持つインターフェイスに設定を適用します。
identifier パラメーターに mac-address 値を使用すると、MAC アドレスがネットワークインターフェイスの識別子であることが指定されます。identifier の値を mac-address に設定する場合は、その後に続く mac-address パラメーターフィールドに特定の MAC アドレスを入力する必要があります。
name パラメーターの値を指定することもできますが、identifier: mac-address 値を設定すると、ネットワークインターフェイスのプライマリー識別子として MAC アドレスが使用されることになります。間違った MAC アドレスを指定した場合、nmstate によって無効な引数のエラーが報告されます。
次のスニペットでは、イーサネットデバイスのプライマリー識別子として MAC アドレスを指定します。デバイスの名前は eth1、MAC アドレスは 8A:8C:92:1A:F6:98 です。
23.1.10.5. DNS リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、nmstate API は DNS 値をネットワークインターフェイスに保存するのではなく、グローバルに保存します。特定の状況では、DNS 値を保存するようにネットワークインターフェイスを設定する必要があります。
DNS 設定の設定は、/etc/resolv.conf ファイルの変更に相当します。
ネットワークインターフェイスの DNS 設定を定義するには、最初にネットワークインターフェイスの YAML 設定ファイルで dns-resolver セクションを指定する必要があります。NNCP 設定をネットワークインターフェイスに適用するには、oc apply -f <nncp_file_name> コマンドを実行する必要があります。
次の例は、DNS 値をグローバルに保存するデフォルトの状況を示しています。
ネットワークインターフェイスなしで静的 DNS を設定します。ホストノード上の
/etc/resolv.confファイルを更新する場合、NodeNetworkConfigurationPolicy(NNCP) マニフェストでインターフェイス (IPv4 または IPv6) を指定する必要はありません。DNS 値をグローバルに保存するネットワークインターフェイスの DNS 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要次の例に示すように、NNCP ファイルの
dns-resolver.configセクションで DNS オプションを指定できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスから DNS オプションを削除する場合は、NNCP に次の設定を適用してから
oc apply -f <nncp_file_name>コマンドを実行します。... ...
# ... dns-resolver: config: {} interfaces: [] # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次の例は、DNS 値を格納するためにネットワークインターフェイスを設定する必要がある状況を示しています。
静的 DNS ネームサーバーを動的 DNS ネームサーバーよりも優先する場合は、ネットワークインターフェイス YAML 設定ファイルで、Dynamic Host Configuration Protocol (DHCP) または IPv6 自動設定 (
autoconf) メカニズムのいずれかを実行するインターフェイスを定義します。DHCPv4 ネットワークプロトコルから取得した DNS ネームサーバーに
192.0.2.1を追加する設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmstateAPI を使用して DNS 値をグローバルに保存するデフォルトの方法を採用するのではなく、DNS 値を保存するようにネットワークインターフェイスを設定する必要がある場合は、ネットワークインターフェイス YAML ファイルで静的 DNS 値と静的 IP アドレスを設定できます。重要ネットワークインターフェイスレベルで DNS 値を保存すると、インターフェイスを Open vSwitch (OVS) ブリッジ、Linux ブリッジ、ボンディングなどのネットワークコンポーネントに接続した後に、名前解決の問題が発生する可能性があります。
インターフェイスレベルで DNS 値を保存する設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスに静的 DNS 検索ドメインと動的 DNS ネームサーバーを設定する場合は、ネットワークインターフェイスの YAML 設定ファイルで、Dynamic Host Configuration Protocol (DHCP) または IPv6 自動設定 (
autoconf) メカニズムのいずれかを実行する動的インターフェイスを定義します。example.comおよびexample.orgの静的 DNS 検索ドメインと動的 DNS ネームサーバー設定を指定する設定の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.1.10.6. 静的ルーティング リンクのコピーリンクがクリップボードにコピーされました!
以下のスニペットは、インターフェイス eth1 に静的ルートおよび静的 IP を設定します。
静的ルートを設定する際に、カスタマイズされた br-ex ブリッジを手動で設定していない限り、OVN-Kubernetes br-ex ブリッジをネクストホップインターフェイスとして使用することはできません。
詳細は、インストーラーでプロビジョニングされるクラスターのベアメタルへのデプロイ、または ユーザーがプロビジョニングしたクラスターをベアメタルにインストール ドキュメントの「カスタマイズされた br-ex ブリッジを含むマニフェストオブジェクトの作成」を参照してください。
23.2. ノードのネットワーク設定のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ノードのネットワーク設定で問題が発生した場合には、ポリシーが自動的にロールバックされ、enactment (実行) レポートは失敗します。これには、以下のような問題が含まれます。
- ホストで設定を適用できません。
- ホストはデフォルトゲートウェイへの接続を失います。
- ホストは API サーバーへの接続を失います。
23.2.1. 正確でないノードネットワーク設定のポリシー設定のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ノードネットワーク設定ポリシーを適用し、クラスター全体でノードのネットワーク設定への変更を適用することができます。
誤った設定を適用した場合は、次の例を使用して、失敗したノードネットワークポリシーをトラブルシューティングして修正できます。この例では、3 つのコントロールプレーンノードと 3 つのコンピュートノードを持つクラスターに Linux ブリッジポリシーを適用します。ポリシーが間違ったインターフェイスを参照しているため、ポリシーは適用されません。
エラーを見つけるには、利用可能な NMState リソースを調査する必要があります。その後に、正しい設定でポリシーを更新できます。
前提条件
-
Linux システムに
ens01インターフェイスが存在しない。
手順
クラスターにポリシーを作成します。次の例では、
ens01をメンバーとして持つ単純なブリッジbr1を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワークインターフェイスにポリシーを適用します。
oc apply -f ens01-bridge-testfail.yaml
$ oc apply -f ens01-bridge-testfail.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail created
nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してポリシーのステータスを確認します。
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、ポリシーが失敗したことを示しています。
出力例
NAME STATUS ens01-bridge-testfail FailedToConfigure
NAME STATUS ens01-bridge-testfail FailedToConfigureCopy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーのステータスのみでは、すべてのノードで失敗したか、ノードのサブセットで失敗したかを確認することはできません。
ノードのネットワーク設定の enactment (実行) をリスト表示し、ポリシーがいずれかのノードで成功したかどうかを確認します。ポリシーがノードのサブセットに対してのみ失敗した場合、出力は、問題が特定のノード設定にあることを示唆します。すべてのノードでポリシーが失敗した場合、出力はポリシーに問題があることを示唆します。
oc get nnce
$ oc get nnceCopy to Clipboard Copied! Toggle word wrap Toggle overflow この出力は、ポリシーがすべてのノードで失敗したことを示しています。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 失敗した enactment の 1 つを表示します。以下のコマンドは、出力ツール
jsonpathを使用して出力をフィルターします。oc get nnce compute-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'$ oc get nnce compute-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
[2024-10-10T08:40:46Z INFO nmstatectl] Nmstate version: 2.2.37 NmstateError: InvalidArgument: Controller interface br1 is holding unknown port ens01
[2024-10-10T08:40:46Z INFO nmstatectl] Nmstate version: 2.2.37 NmstateError: InvalidArgument: Controller interface br1 is holding unknown port ens01Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前の例は、
InvalidArgumentエラーからの出力で、ens01が不明なポートであることを示しています。この例では、ポリシー設定ファイル内のポート設定を変更する必要がある場合があります。ポリシーが適切に設定されていることを確認するには、
NodeNetworkStateオブジェクトを要求して、1 つまたはすべてのノードのネットワーク設定を表示します。以下のコマンドは、control-plane-1ノードのネットワーク設定を返します。oc get nns control-plane-1 -o yaml
$ oc get nns control-plane-1 -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力は、ノード上のインターフェイス名は
ens1であるものの、失敗したポリシーがens01を誤って使用していることを示します。出力例
- ipv4: # ... name: ens1 state: up type: ethernet- ipv4: # ... name: ens1 state: up type: ethernetCopy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のポリシーを編集してエラーを修正します。
oc edit nncp ens01-bridge-testfail
$ oc edit nncp ens01-bridge-testfailCopy to Clipboard Copied! Toggle word wrap Toggle overflow # ... port: - name: ens1# ... port: - name: ens1Copy to Clipboard Copied! Toggle word wrap Toggle overflow ポリシーを保存して修正を適用します。
ポリシーのステータスをチェックして、更新が正常に行われたことを確認します。
oc get nncp
$ oc get nncpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS ens01-bridge-testfail SuccessfullyConfigured
NAME STATUS ens01-bridge-testfail SuccessfullyConfiguredCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたポリシーは、クラスターのすべてのノードで正常に設定されました。
23.2.2. 非接続環境での DNS 接続の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
非接続環境で nmstate を設定するときに DNS 接続の問題が発生する場合は、ドメイン root-servers.net のネームサーバーのリストを解決するように DNS サーバーを設定できます。
DNS サーバーに root-servers.net ゾーンのネームサーバー (NS) エントリーが含まれていることを確認します。DNS サーバーはクエリーをアップストリームのリゾルバーに転送する必要はありませんが、サーバーは NS クエリーに対して正しい回答を返す必要があります。
23.2.2.1. bind9 DNS 名前付きサーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
bind9 DNS サーバーを照会するように設定されたクラスターの場合は、少なくとも 1 つの NS レコードを含む設定ファイルに root-servers.net ゾーンを追加できます。たとえば、この条件にすでに一致するゾーンファイルとして /var/named/named.localhost を使用できます。
手順
次のコマンドを実行して、
/etc/named.conf設定ファイルの最後にroot-servers.netゾーンを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
namedサービスを再起動します。systemctl restart named
$ systemctl restart namedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
root-servers.netゾーンが存在することを確認します。journalctl -u named|grep root-servers.net
$ journalctl -u named|grep root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Jul 03 15:16:26 rhel-8-10 bash[xxxx]: zone root-servers.net/IN: loaded serial 0 Jul 03 15:16:26 rhel-8-10 named[xxxx]: zone root-servers.net/IN: loaded serial 0
Jul 03 15:16:26 rhel-8-10 bash[xxxx]: zone root-servers.net/IN: loaded serial 0 Jul 03 15:16:26 rhel-8-10 named[xxxx]: zone root-servers.net/IN: loaded serial 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、DNS サーバーが
root-servers.netドメインの NS レコードを解決できることを確認します。host -t NS root-servers.net. 127.0.0.1
$ host -t NS root-servers.net. 127.0.0.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Using domain server: Name: 127.0.0.1 Address: 127.0.0.53 Aliases: root-servers.net name server root-servers.net.
Using domain server: Name: 127.0.0.1 Address: 127.0.0.53 Aliases: root-servers.net name server root-servers.net.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.2.2.2. dnsmasq DNS サーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
dnsmasq を DNS サーバーとして使用している場合は、指定した DNS サーバーを使用して root-servers.net を解決する新しい設定ファイルを作成するなどして、root-servers.net ドメインの解決を別の DNS サーバーに委任できます。
次のコマンドを実行して、ドメイン
root-servers.netを別の DNS サーバーに委任する設定ファイルを作成します。echo 'server=/root-servers.net/<DNS_server_IP>'> /etc/dnsmasq.d/delegate-root-servers.net.conf
$ echo 'server=/root-servers.net/<DNS_server_IP>'> /etc/dnsmasq.d/delegate-root-servers.net.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
dnsmasqサービスを再起動します。systemctl restart dnsmasq
$ systemctl restart dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
root-servers.netドメインが別の DNS サーバーに委任されていることを確認します。journalctl -u dnsmasq|grep root-servers.net
$ journalctl -u dnsmasq|grep root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Jul 03 15:31:25 rhel-8-10 dnsmasq[1342]: using nameserver 192.168.1.1#53 for domain root-servers.net
Jul 03 15:31:25 rhel-8-10 dnsmasq[1342]: using nameserver 192.168.1.1#53 for domain root-servers.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、DNS サーバーが
root-servers.netドメインの NS レコードを解決できることを確認します。host -t NS root-servers.net. 127.0.0.1
$ host -t NS root-servers.net. 127.0.0.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: root-servers.net name server root-servers.net.
Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: root-servers.net name server root-servers.net.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第24章 クラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。既存クラスターのプロキシーオブジェクトを変更 するか、または新規クラスターの install-config.yaml ファイルでプロキシー設定を行うことにより、OpenShift Container Platform をプロキシーを使用するように設定できます。
サポート対象プラットフォーム上のクラスターに対してクラスター全体の Egress プロキシーを有効にすると、Red Hat Enterprise Linux CoreOS (RHCOS) は status.noProxy パラメーターに、サポート対象プラットフォーム上に存在する install-config.yaml ファイルの networking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、networking.serviceNetwork[] フィールドの値を入力します。
インストール後のタスクとして、networking.clusterNetwork[].cidr の値を変更できますが、networking.machineNetwork[].cidr および networking.serviceNetwork[] の値は変更できません。詳細は、「クラスターネットワーク範囲の設定」を参照してください。
Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、status.noProxy パラメーターには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
RHCOS によって Proxy オブジェクトの status: セグメントに追加される値の例
- 1
- Pod IP アドレスの割り当てに使用する IP アドレスブロックを指定します。デフォルト値は
10.128.0.0/14で、ホストの接頭辞は/23です。 - 2
- マシンの IP アドレスブロックを指定します。デフォルト値は
10.0.0.0/16です。 - 3
- サービスの IP アドレスブロックを指定します。デフォルト値は
172.30.0.0/16です。 - 4
oc get infrastructures.config.openshift.io cluster -o jsonpath='{.status.etcdDiscoveryDomain}'コマンドを実行すると、内部 API サーバーの URL を見つけることができます。
使用しているインストールタイプに networking.machineNetwork[].cidr フィールドの設定が含まれていない場合は、ノード間のトラフィックがプロキシーをバイパスできるようにするために、.status.noProxy フィールドにマシンの IP アドレスを手動で含める必要があります。
24.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
クラスターがアクセスする必要のあるサイト を確認し、プロキシーをバイパスする必要があるかどうかを判断します。デフォルトで、すべてのクラスターシステムの Egress トラフィック (クラスターをホストするクラウドのクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。システム全体のプロキシーは、ユーザーのワークロードではなく、システムコンポーネントにのみ影響を与えます。必要に応じて、Proxy オブジェクトの spec.noProxy パラメーターにサイトを追加してプロキシーをバイパスします。
24.2. クラスター全体のプロキシーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Proxy オブジェクトは、クラスター全体の Egress プロキシーを管理するために使用されます。プロキシーが設定されていない状態でクラスターをインストールまたはアップグレードすると、Proxy オブジェクトは生成されますが、その spec が nil になります。以下に例を示します。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
クラスター管理者は、cluster Proxy オブジェクトを変更することで、OpenShift Container Platform のプロキシーを設定できます。
クラスターのクラスター全体のプロキシー機能を有効にし、Proxy オブジェクトファイルを保存すると、Machine Config Operator (MCO) によってクラスター内のすべてのノードが再起動され、各ノードがクラスターの外部にある接続にアクセスできるようになります。これらのノードを手動で再起動する必要はありません。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる config map を作成します。
注記プロキシーのアイデンティティー証明書が Red Hat Enterprise Linux CoreOS (RHCOS) トラストバンドルの認証局によって署名されている場合は、この手順をスキップできます。
user-ca-bundle.yamlというファイルを作成し、PEM でエンコードされた証明書の値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
user-ca-bundle.yamlファイルから config map を作成します。oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
oc editコマンドを使用してProxyオブジェクトを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーに必要なフィールドを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。URL スキームは
httpまたはhttpsである必要があります。URL スキームをサポートするプロキシーの URL を指定します。たとえば、プロキシーがhttpsを使用するように設定されていても、httpしかサポートしていない場合、ほとんどのプロキシーはエラーを報告します。このエラーメッセージはログに反映されず、代わりにネットワーク接続エラーのように見える場合があります。クラスターからのhttps接続をリッスンするプロキシーを使用する場合は、プロキシーが使用する CA と証明書を受け入れるようにクラスターを設定する必要がある場合があります。 - 3
- プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス (またはその他のネットワーク CIDR)、およびポート番号のコンマ区切りリスト。注記
ポート番号は、IPv6 アドレスを設定する場合にのみサポートされます。IPv4 アドレスを設定する場合、ポート番号はサポートされません。
サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。noproxyフィールドにドメインアドレスを含める必要がある場合は、noproxyフィールドにその FQDN または接頭辞が一致するサブドメインを明示的に指定する必要があります。ドメインをカプセル化する IP アドレスまたは CIDR 範囲は使用できません。なぜなら、クラスターは DNS が IP アドレスを返すのを待たずにルート接続を割り当て、実行されているリクエストを明示的にチェックするからです。たとえば、noproxyフィールドに10.0.0.0/24などの CIDR ブロック値がある場合、フィールドがhttps://10.0.0.11にアクセスしようとすると、アドレスが正常にマッチします。しかし、A レコードのエントリーが10.0.0.11であるhttps://exampleserver.externaldomain.comにアクセスしようとすると、失敗します。noproxyフィールドに.externaldomain.comという追加の値が必要です。インストール設定の
networking.machineNetwork[].cidrフィールドで定義されたネットワークに含まれていないコンピュートノードをスケールアップする場合は、接続の問題を防ぐために、そのノードをこのリストに追加する必要があります。httpProxyまたはhttpsProxyフィールドのいずれも設定されていない場合に、このフィールドは無視されます。 - 4
httpProxyおよびhttpsProxyの値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。- 5
- HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる、
openshift-confignamespace の config map の参照。ここで参照する前に config map が存在している必要があります。このフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
- 変更を適用するためにファイルを保存します。
24.3. クラスター全体のプロキシーの削除 リンクのコピーリンクがクリップボードにコピーされました!
cluster プロキシーオブジェクトは削除できません。クラスターからプロキシーを削除するには、プロキシーオブジェクトからすべての spec フィールドを削除します。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
oc editコマンドを使用してプロキシーを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーオブジェクトからすべての
specフィールドを削除します。以下に例を示します。apiVersion: config.openshift.io/v1 kind: Proxy metadata: name: cluster spec: {}apiVersion: config.openshift.io/v1 kind: Proxy metadata: name: cluster spec: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を適用するためにファイルを保存します。
24.4. クラスター全体のプロキシー設定の検証 リンクのコピーリンクがクリップボードにコピーされました!
クラスター全体のプロキシー設定がデプロイしたら、期待どおりに動作していることを検証できます。次の手順に従って、ログを確認し、実装を検証してください。
前提条件
- クラスター管理者パーミッションがある。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
ocコマンドを使用してプロキシー設定のステータスを確認します。oc get proxy/cluster -o yaml
$ oc get proxy/cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
出力内のプロキシーフィールドを検証して、設定と一致していることを確認します。具体的には、
spec.httpProxy、spec.httpsProxy、spec.noProxy、およびspec.trustedCAフィールドを確認します。 Proxyオブジェクトのステータスを検査します。oc get proxy/cluster -o jsonpath='{.status}'$ oc get proxy/cluster -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Machine Config Operator (MCO) のログをチェックして、設定の変更が正常に適用されたことを確認します。
oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)
$ oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 必要に応じて、プロキシー設定が適用され、ノードが再起動されたことを示すメッセージを確認します。
外部リクエストを行うコンポーネント (Cluster Version Operator (CVO) など) のログをチェックして、システムコンポーネントがプロキシーを使用していることを確認します。
oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)
$ oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 外部リクエストがプロキシー経由でルーティングされたことを示すログエントリーを確認します。
関連情報
第25章 カスタム PKI の設定 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールなどの一部のプラットフォームコンポーネントは、通信にルートを使用し、それらと対話するために他のコンポーネントの証明書を信頼する必要があります。カスタムのパブリックキーインフラストラクチャー (PKI) を使用している場合は、プライベートに署名された CA 証明書がクラスター全体で認識されるようにこれを設定する必要があります。
プロキシー API を使用して、クラスター全体で信頼される CA 証明書を追加できます。インストール時またはランタイム時にこれを実行する必要があります。
インストール 時に、クラスター全体のプロキシーを設定します。プライベートに署名された CA 証明書は、
install-config.yamlファイルのadditionalTrustBundle設定で定義する必要があります。インストールプログラムは、定義した追加の CA 証明書が含まれる
user-ca-bundleという名前の ConfigMap を生成します。次に Cluster Network Operator は、これらの CA 証明書を Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundleConfigMap を作成し、この ConfigMap はプロキシーオブジェクトのtrustedCAフィールドで参照されます。-
ランタイム 時に、デフォルトのプロキシーオブジェクトを変更して、プライベートに署名された CA 証明書を追加 します (これは、クラスターのプロキシー有効化のワークフローの一部です)。これには、クラスターで信頼される必要があるプライベートに署名された CA 証明書が含まれる ConfigMap を作成し、次にプライベートに署名された証明書の ConfigMap を参照する
trustedCAでプロキシーリソースを変更することが関係します。
インストーラー設定の additionalTrustBundle フィールドおよびプロキシーリソースの trustedCA フィールドは、クラスター全体の信頼バンドルを管理するために使用されます。additionalTrustBundle はインストール時に使用され、プロキシーの trustedCA がランタイム時に使用されます。
trustedCA フィールドは、クラスターコンポーネントによって使用されるカスタム証明書とキーのペアを含む ConfigMap の参照です。
25.1. インストール時のクラスター全体のプロキシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境では、インターネットへの直接アクセスを拒否し、代わりに HTTP または HTTPS プロキシーを使用することができます。プロキシー設定を install-config.yaml ファイルで行うことにより、新規の OpenShift Container Platform クラスターをプロキシーを使用するように設定できます。
前提条件
クラスターがアクセスする必要のあるサイトを確認済みで、それらのいずれかがプロキシーをバイパスする必要があるかどうかを判別している。デフォルトで、すべてのクラスター Egress トラフィック (クラスターをホストするクラウドに関するクラウドプロバイダー API に対する呼び出しを含む) はプロキシーされます。プロキシーを必要に応じてバイパスするために、サイトを
Proxyオブジェクトのspec.noProxyフィールドに追加している。注記Proxyオブジェクトのstatus.noProxyフィールドには、インストール設定のnetworking.machineNetwork[].cidr、networking.clusterNetwork[].cidr、およびnetworking.serviceNetwork[]フィールドの値が設定されます。Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、および Red Hat OpenStack Platform (RHOSP) へのインストールの場合、
Proxyオブジェクトのstatus.noProxyフィールドには、インスタンスメタデータのエンドポイント (169.254.169.254) も設定されます。
手順
install-config.yamlファイルを編集し、プロキシー設定を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。
- 3
- プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。AmazonEC2、Elastic Load Balancing、およびS3VPC エンドポイントを VPC に追加した場合は、これらのエンドポイントをnoProxyフィールドに追加する必要があります。 - 4
- 指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる
user-ca-bundleという名前の設定マップをopenshift-confignamespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージするtrusted-ca-bundle設定マップを作成し、この設定マップはProxyオブジェクトのtrustedCAフィールドで参照されます。additionalTrustBundleフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。 - 5
- オプション:
trustedCAフィールドのuser-ca-bundle設定マップを参照するProxyオブジェクトの設定を決定するポリシー。許可される値はProxyonlyおよびAlwaysです。Proxyonlyを使用して、http/httpsプロキシーが設定されている場合にのみuser-ca-bundle設定マップを参照します。Alwaysを使用して、常にuser-ca-bundle設定マップを参照します。デフォルト値はProxyonlyです。
注記インストールプログラムは、プロキシーの
readinessEndpointsフィールドをサポートしません。注記インストーラーがタイムアウトした場合は、インストーラーの
wait-forコマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。./openshift-install wait-for install-complete --log-level debug
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。
インストールプログラムは、指定の install-config.yaml ファイルのプロキシー設定を使用する cluster という名前のクラスター全体のプロキシーを作成します。プロキシー設定が指定されていない場合、cluster Proxy オブジェクトが依然として作成されますが、これには spec がありません。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
25.2. クラスター全体のプロキシーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Proxy オブジェクトは、クラスター全体の Egress プロキシーを管理するために使用されます。プロキシーが設定されていない状態でクラスターをインストールまたはアップグレードすると、Proxy オブジェクトは生成されますが、その spec が nil になります。以下に例を示します。
cluster という名前の Proxy オブジェクトのみがサポートされ、追加のプロキシーを作成することはできません。
クラスター管理者は、cluster Proxy オブジェクトを変更することで、OpenShift Container Platform のプロキシーを設定できます。
クラスターのクラスター全体のプロキシー機能を有効にし、Proxy オブジェクトファイルを保存すると、Machine Config Operator (MCO) によってクラスター内のすべてのノードが再起動され、各ノードがクラスターの外部にある接続にアクセスできるようになります。これらのノードを手動で再起動する必要はありません。
前提条件
- クラスター管理者のパーミッション。
-
OpenShift Container Platform
ocCLI ツールがインストールされている。
手順
HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる config map を作成します。
注記プロキシーのアイデンティティー証明書が Red Hat Enterprise Linux CoreOS (RHCOS) トラストバンドルの認証局によって署名されている場合は、この手順をスキップできます。
user-ca-bundle.yamlというファイルを作成し、PEM でエンコードされた証明書の値を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
user-ca-bundle.yamlファイルから config map を作成します。oc create -f user-ca-bundle.yaml
$ oc create -f user-ca-bundle.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
oc editコマンドを使用してProxyオブジェクトを変更します。oc edit proxy/cluster
$ oc edit proxy/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーに必要なフィールドを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは
httpである必要があります。 - 2
- クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。URL スキームは
httpまたはhttpsである必要があります。URL スキームをサポートするプロキシーの URL を指定します。たとえば、プロキシーがhttpsを使用するように設定されていても、httpしかサポートしていない場合、ほとんどのプロキシーはエラーを報告します。このエラーメッセージはログに反映されず、代わりにネットワーク接続エラーのように見える場合があります。クラスターからのhttps接続をリッスンするプロキシーを使用する場合は、プロキシーが使用する CA と証明書を受け入れるようにクラスターを設定する必要がある場合があります。 - 3
- プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス (またはその他のネットワーク CIDR)、およびポート番号のコンマ区切りリスト。注記
ポート番号は、IPv6 アドレスを設定する場合にのみサポートされます。IPv4 アドレスを設定する場合、ポート番号はサポートされません。
サブドメインのみと一致するように、ドメインの前に
.を付けます。たとえば、.y.comはx.y.comに一致しますが、y.comには一致しません。*を使用し、すべての宛先のプロキシーをバイパスします。noproxyフィールドにドメインアドレスを含める必要がある場合は、noproxyフィールドにその FQDN または接頭辞が一致するサブドメインを明示的に指定する必要があります。ドメインをカプセル化する IP アドレスまたは CIDR 範囲は使用できません。なぜなら、クラスターは DNS が IP アドレスを返すのを待たずにルート接続を割り当て、実行されているリクエストを明示的にチェックするからです。たとえば、noproxyフィールドに10.0.0.0/24などの CIDR ブロック値がある場合、フィールドがhttps://10.0.0.11にアクセスしようとすると、アドレスが正常にマッチします。しかし、A レコードのエントリーが10.0.0.11であるhttps://exampleserver.externaldomain.comにアクセスしようとすると、失敗します。noproxyフィールドに.externaldomain.comという追加の値が必要です。インストール設定の
networking.machineNetwork[].cidrフィールドで定義されたネットワークに含まれていないコンピュートノードをスケールアップする場合は、接続の問題を防ぐために、そのノードをこのリストに追加する必要があります。httpProxyまたはhttpsProxyフィールドのいずれも設定されていない場合に、このフィールドは無視されます。 - 4
httpProxyおよびhttpsProxyの値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。- 5
- HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる、
openshift-confignamespace の config map の参照。ここで参照する前に config map が存在している必要があります。このフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。
- 変更を適用するためにファイルを保存します。
25.3. Operator を使用した証明書の挿入 リンクのコピーリンクがクリップボードにコピーされました!
カスタム CA 証明書が ConfigMap 経由でクラスターに追加されると、Cluster Network Operator はユーザーによってプロビジョニングされる CA 証明書およびシステム CA 証明書を単一バンドルにマージし、信頼バンドルの挿入を要求する Operator にマージされたバンドルを挿入します。
config.openshift.io/inject-trusted-cabundle="true" ラベルを config map に追加すると、そこに格納されている既存データが削除されます。Cluster Network Operator は config map の所有権を取得し、ca-bundle をデータとしてのみ受け入れます。service.beta.openshift.io/inject-cabundle=true アノテーションまたは同様の設定を使用して service-ca.crt を保存するには、別の config map を使用する必要があります。同じ config map に config.openshift.io/inject-trusted-cabundle="true" ラベルと service.beta.openshift.io/inject-cabundle=true アノテーションを追加すると、問題が発生する可能性があります。
Operator は、以下のラベルの付いた空の ConfigMap を作成してこの挿入を要求します。
config.openshift.io/inject-trusted-cabundle="true"
config.openshift.io/inject-trusted-cabundle="true"
空の ConfigMap の例:
- 1
- 空の ConfigMap 名を指定します。
Operator は、この ConfigMap をコンテナーのローカル信頼ストアにマウントします。
信頼された CA 証明書の追加は、証明書が Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルに含まれない場合にのみ必要になります。
証明書の挿入は Operator に制限されません。Cluster Network Operator は、空の ConfigMap が config.openshift.io/inject-trusted-cabundle=true ラベルを使用して作成される場合に、すべての namespace で証明書を挿入できます。
ConfigMap はすべての namespace に置くことができますが、ConfigMap はカスタム CA を必要とする Pod 内の各コンテナーに対してボリュームとしてマウントされる必要があります。以下に例を示します。
第26章 RHOSP での負荷分散 リンクのコピーリンクがクリップボードにコピーされました!
26.1. ロードバランサーサービスの制限 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform クラスターは、Octavia を使用してロードバランサーサービスを処理します。その結果、該当するクラスターには多くの機能的制限が生じます。
RHOSP Octavia では、Amphora と OVN の 2 つのプロバイダーがサポートされています。これらのプロバイダーでは、利用可能な機能と実装の詳細が異なります。そのような差異は、クラスター上に作成されるロードバランサーサービスに影響を及ぼします。
26.1.1. ローカルの外部トラフィックポリシー リンクのコピーリンクがクリップボードにコピーされました!
ロードバランサーサービスで外部トラフィックポリシー (ETP) パラメーター .spec.externalTrafficPolicy を設定して、受信トラフィックがサービスエンドポイント Pod に到達する際に、その送信元 IP アドレスを保存できます。ただし、クラスターが Amphora Octavia プロバイダーを使用している場合じゃ、トラフィックの送信元 IP は Amphora 仮想マシンの IP アドレスに置き換えられます。クラスターが OVN Octavia プロバイダーを使用している場合、この動作は発生しません。
ETP オプションを Local に設定する場合は、ロードバランサー用にヘルスモニターを作成する必要があります。ヘルスモニターがないと、機能するエンドポイントを持たないノードにトラフィックがルーティングされ、接続が切断される可能性があります。ヘルスモニターの作成を Cloud Provider OpenStack に強制するには、クラウドプロバイダー設定の create-monitor オプションの値を true に設定する必要があります。
RHOSP 16.2 では、OVN Octavia プロバイダーはヘルスモニターをサポートしません。そのため、ETP をローカルに設定することはサポートされていません。
RHOSP 16.2 では、Amphora Octavia プロバイダーは UDP プールでの HTTP モニターをサポートしません。その結果、UDP ロードバランサーサービスには UDP-CONNECT モニターが代わりに作成されます。実装の詳細に基づき、この設定は OVN-Kubernetes CNI プラグインでのみ適切に機能します。OpenShift SDN CNI プラグインを使用している場合、UDP サービスのアクティブなノードの検出が不確実になります。この問題は、ドライバーが HTTP ヘルスモニターをサポートしていないため、RHOSP バージョンの OVN Octavia プロバイダーにも影響します。
26.2. Octavia を使用したアプリケーショントラフィック用のクラスターのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) で実行される OpenShift Container Platform クラスターでは、Octavia 負荷分散サービスを使用して、複数の仮想マシン (VM) または Floating IP アドレスにトラフィックを分散することができます。この機能は、単一マシンまたはアドレスが生じさせるボトルネックを軽減します。
アプリケーションのネットワークのスケーリングに使用する、独自の Octavia ロードバランサーを作成する必要があります。
26.2.1. Octavia を使用したクラスターのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
複数の API ロードバランサーを使用する場合、Octavia ロードバランサーを作成し、それを使用するようにクラスターを設定します。
前提条件
- Octavia は Red Hat OpenStack Platform (RHOSP) デプロイメントで利用できます。
手順
コマンドラインから、Amphora ドライバーを使用する Octavia ロードバランサーを作成します。
openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>
$ openstack loadbalancer create --name API_OCP_CLUSTER --vip-subnet-id <id_of_worker_vms_subnet>Copy to Clipboard Copied! Toggle word wrap Toggle overflow API_OCP_CLUSTERの代わりに、任意の名前を使用することができます。ロードバランサーがアクティブになったら、リスナーを作成します。
openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTER
$ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol HTTPS--protocol-port 6443 API_OCP_CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ロードバランサーのステータスを表示するには、
openstack loadbalancer listと入力します。ラウンドロビンアルゴリズムを使用し、セッションの永続性が有効にされているプールを作成します。
openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPS
$ openstack loadbalancer pool create --name API_OCP_CLUSTER_pool_6443 --lb-algorithm ROUND_ROBIN --session-persistence type=<source_IP_address> --listener API_OCP_CLUSTER_6443 --protocol HTTPSCopy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンマシンが利用可能であることを確認するには、ヘルスモニターを作成します。
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443
$ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP API_OCP_CLUSTER_pool_6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow コントロールプレーンマシンをロードバランサープールのメンバーとして追加します。
for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP) do openstack loadbalancer member create --address $SERVER --protocol-port 6443 API_OCP_CLUSTER_pool_6443 done
$ for SERVER in $(MASTER-0-IP MASTER-1-IP MASTER-2-IP) do openstack loadbalancer member create --address $SERVER --protocol-port 6443 API_OCP_CLUSTER_pool_6443 doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: クラスター API の Floating IP アドレスを再利用するには、設定を解除します。
openstack floating ip unset $API_FIP
$ openstack floating ip unset $API_FIPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を解除された
API_FIP、または新規アドレスを、作成されたロードばランサー VIP に追加します。openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIP
$ openstack floating ip set --port $(openstack loadbalancer show -c <vip_port_id> -f value API_OCP_CLUSTER) $API_FIPCopy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターは、負荷分散に Octavia を使用するようになりました。
26.3. ユーザー管理ロードバランサーのサービス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform クラスターを設定して、デフォルトのロードバランサーの代わりにユーザー管理ロードバランサーを使用できます。
ユーザー管理ロードバランサーの設定は、ベンダーのロードバランサーによって異なります。
このセクションの情報と例は、ガイドラインのみを目的としています。ベンダーのロードバランサーに関する詳細は、ベンダーのドキュメントを参照してください。
Red Hat は、ユーザー管理ロードバランサーに対して次のサービスをサポートしています。
- Ingress Controller
- OpenShift API
- OpenShift MachineConfig API
ユーザー管理ロードバランサーに対して、これらのサービスの 1 つを設定するか、すべてを設定するかを選択できます。一般的な設定オプションは、Ingress Controller サービスのみを設定することです。次の図は、各サービスの詳細を示しています。
図26.1 OpenShift Container Platform 環境で動作する Ingress Controller を示すネットワークワークフローの例
図26.2 OpenShift Container Platform 環境で動作する OpenShift API を示すネットワークワークフローの例
図26.3 OpenShift Container Platform 環境で動作する OpenShift MachineConfig API を示すネットワークワークフローの例
ユーザー管理ロードバランサーでは、次の設定オプションがサポートされています。
- ノードセレクターを使用して、Ingress Controller を特定のノードのセットにマッピングします。このセットの各ノードに静的 IP アドレスを割り当てるか、Dynamic Host Configuration Protocol (DHCP) から同じ IP アドレスを受け取るように各ノードを設定する必要があります。インフラストラクチャーノードは通常、このタイプの設定を受け取ります。
サブネット上のすべての IP アドレスをターゲットにします。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。
/27や/28などの小規模なネットワーク上に設定されたマシンを使用して Ingress Pod をデプロイする場合、ロードバランサーのターゲットを簡素化できます。ヒントマシン config プールのリソースを確認することで、ネットワーク内に存在するすべての IP アドレスをリスト表示できます。
OpenShift Container Platform クラスターのユーザー管理ロードバランサーを設定する前に、以下の情報を考慮してください。
- フロントエンド IP アドレスの場合、フロントエンド IP アドレス、Ingress Controller のロードバランサー、および API ロードバランサーに同じ IP アドレスを使用できます。この機能は、ベンダーのドキュメントを確認してください。
バックエンド IP アドレスの場合、ユーザー管理ロードバランサーの有効期間中に OpenShift Container Platform コントロールプレーンノードの IP アドレスが変更されないことを確認します。次のいずれかのアクションを実行すると、これを実現できます。
- 各コントロールプレーンノードに静的 IP アドレスを割り当てます。
- ノードが DHCP リースを要求するたびに、DHCP から同じ IP アドレスを受信するように各ノードを設定します。ベンダーによっては、DHCP リースは IP 予約または静的 DHCP 割り当ての形式になる場合があります。
- Ingress Controller バックエンドサービスのユーザー管理ロードバランサーで Ingress Controller を実行する各ノードを手動で定義します。たとえば、Ingress Controller が未定義のノードに移動すると、接続が停止する可能性があります。
26.3.1. ユーザー管理ロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform (RHOSP) 上の OpenShift Container Platform クラスターを設定して、デフォルトのロードバランサーの代わりにユーザー管理ロードバランサーを使用できます。
ユーザー管理ロードバランサーを設定する前に、「ユーザー管理ロードバランサーのサービス」セクションを必ずお読みください。
ユーザー管理ロードバランサー用に設定するサービスに適用される次の前提条件をお読みください。
クラスター上で実行される MetalLB は、ユーザー管理ロードバランサーとして機能します。
OpenShift API の前提条件
- フロントエンド IP アドレスを定義している。
TCP ポート 6443 および 22623 は、ロードバランサーのフロントエンド IP アドレスで公開されている。以下の項目を確認します。
- ポート 6443 が OpenShift API サービスにアクセスできる。
- ポート 22623 が Ignition 起動設定をノードに提供できる。
- フロントエンド IP アドレスとポート 6443 へは、OpenShift Container Platform クラスターの外部の場所にいるシステムのすべてのユーザーがアクセスできる。
- フロントエンド IP アドレスとポート 22623 は、OpenShift Container Platform ノードからのみ到達できる。
- ロードバランサーバックエンドは、ポート 6443 および 22623 の OpenShift Container Platform コントロールプレーンノードと通信できる。
Ingress Controller の前提条件
- フロントエンド IP アドレスを定義している。
- TCP ポート 443 および 80 はロードバランサーのフロントエンド IP アドレスで公開されている。
- フロントエンドの IP アドレス、ポート 80、ポート 443 へは、OpenShift Container Platform クラスターの外部の場所にあるシステムの全ユーザーがアクセスできる。
- フロントエンドの IP アドレス、ポート 80、ポート 443 は、OpenShift Container Platform クラスターで動作するすべてのノードから到達できる。
- ロードバランサーバックエンドは、ポート 80、443、および 1936 で Ingress Controller を実行する OpenShift Container Platform ノードと通信できる。
ヘルスチェック URL 仕様の前提条件
ほとんどのロードバランサーは、サービスが使用可能か使用不可かを判断するヘルスチェック URL を指定して設定できます。OpenShift Container Platform は、OpenShift API、Machine Configuration API、および Ingress Controller バックエンドサービスのこれらのヘルスチェックを提供します。
次の例は、前にリスト表示したバックエンドサービスのヘルスチェック仕様を示しています。
Kubernetes API ヘルスチェック仕様の例
Path: HTTPS:6443/readyz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:6443/readyz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Machine Config API ヘルスチェック仕様の例
Path: HTTPS:22623/healthz Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 10 Interval: 10
Path: HTTPS:22623/healthz
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 10
Interval: 10
Ingress Controller のヘルスチェック仕様の例
Path: HTTP:1936/healthz/ready Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10
Path: HTTP:1936/healthz/ready
Healthy threshold: 2
Unhealthy threshold: 2
Timeout: 5
Interval: 10
手順
HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。
1 つのサブネットをリストした HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 複数のサブネットをリストした HAProxy 設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow curlCLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。
curl https://<loadbalancer_ip_address>:6443/version --insecure
$ curl https://<loadbalancer_ip_address>:6443/version --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。
curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure
$ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>
$ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cache
HTTP/1.1 302 Found content-length: 0 location: https://console-openshift-console.apps.ocp4.private.opequon.net/ cache-control: no-cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。
curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>
$ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ユーザー管理ロードバランサーのフロントエンド IP アドレスをターゲットにするようにクラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。
変更された DNS レコードの例
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A api.<cluster_name>.<base_domain> A record pointing to Load Balancer Front EndCopy to Clipboard Copied! Toggle word wrap Toggle overflow <load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front End
<load_balancer_ip_address> A apps.<cluster_name>.<base_domain> A record pointing to Load Balancer Front EndCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。
OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの
install-config.yamlファイルで次の設定を指定する必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスターのユーザー管理ロードバランサーを指定するには、
typeパラメーターにUserManagedを設定します。パラメーターのデフォルトはOpenShiftManagedDefaultで、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infranamespace で定義されたサービスの場合、ユーザー管理ロードバランサーはcorednsサービスをクラスター内の Pod にデプロイできますが、keepalivedおよびhaproxyサービスは無視します。 - 2
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。
- 3
- ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。
検証
curlCLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。
curl https://api.<cluster_name>.<base_domain>:6443/version --insecure
$ curl https://api.<cluster_name>.<base_domain>:6443/version --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合は、応答として JSON オブジェクトを受信します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。
curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure
$ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
HTTP/1.1 200 OK Content-Length: 0
HTTP/1.1 200 OK Content-Length: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。
curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。
curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure
$ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定が正しい場合、コマンドの出力には次の応答が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第27章 MetalLB を使用した負荷分散 リンクのコピーリンクがクリップボードにコピーされました!
27.1. MetalLB アドレスプールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、アドレスプールを追加、変更、および削除できます。MetalLB Operator は、アドレスプールカスタムリソースを使用して、MetalLB がサービスに割り当てることのできる IP アドレスを設定します。例で使用されている namespace は、namespace が metallb-system であることを前提としています。
MetalLB Operator のインストール方法の詳細は、MetalLB および MetalLB Operator について を参照してください。
27.1.1. IPAddressPool カスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
次の表で、IPAddressPool カスタムリソースのフィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
アドレスプールの名前を指定します。サービスを追加する場合は、 |
|
|
| アドレスプールの namespace を指定します。MetalLB Operator が使用するものと同じ namespace を指定します。 |
|
|
|
オプション: |
|
|
| MetalLB Operator がサービスに割り当てる IP アドレスのリストを指定します。1 つのプールで複数の範囲を指定できます。それらはすべて同じ設定を共有します。CIDR 表記で各範囲を指定するか、開始および終了の IP アドレスをハイフンで区切って指定します。 |
|
|
|
オプション: MetalLB がこのプールから IP アドレスを自動的に割り当てるかどうかを指定します。 注記
IP アドレスプール設定の場合、 |
|
|
|
オプション: これを有効にすると、 |
spec.serviceAllocation 仕様を設定することにより、IPAddressPool からサービスおよび namespace に IP アドレスを割り当てることができます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| オプション: 複数の IP アドレスプールがサービスまたは namespace に一致する場合の IP アドレスプール間の優先度を定義します。数字が小さいほど優先度が高いことを示します。 |
|
|
| オプション: IP アドレスプール内の IP アドレスに割り当てることができる namespace のリストを指定します。 |
|
|
| オプション: リスト形式のラベルセレクターを使用して、IP アドレスプールから IP アドレスに割り当てることができる namespace ラベルを指定します。 |
|
|
| オプション: リスト形式のラベルセレクターを使用して、アドレスプールから IP アドレスに割り当てることができるサービスラベルを指定します。 |
27.1.2. アドレスプールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターにアドレスプールを追加して、MetalLB がロードバランサーサービスに割り当てることのできる IP アドレスを制御できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
IPAddressPoolに割り当てられたこのラベルは、BGPAdvertisementCRD のipAddressPoolSelectorsによって参照され、IPAddressPoolをアドバタイズメントに関連付けることができます。
IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを入力して、アドレスプールを表示します。
oc describe -n metallb-system IPAddressPool doc-example
$ oc describe -n metallb-system IPAddressPool doc-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
doc-exampleなどのアドレスプール名と IP アドレス範囲が出力に存在することを確認します。
27.1.3. VLAN の MetalLB アドレスプールの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターにアドレスプールを追加することで、MetalLB がロードバランサーサービスに割り当てることのできる、作成された VLAN の IP アドレスを制御できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 別の VLAN を設定する。
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
次の例のようなファイル (
ipaddresspool-vlan.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool-vlan.yaml
$ oc apply -f ipaddresspool-vlan.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow この設定を VLAN に適用するために、
specのgatewayConfig.ipForwardingをGlobalに設定する必要があります。次のコマンドを実行して、ネットワーク設定カスタムリソース (CR) を編集します。
oc edit network.operator.openshift/cluster
$ oc edit network.operator.openshift/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.defaultNetwork.ovnKubernetesConfigセクションを更新して、gatewayConfig.ipForwardingをGlobalに設定します。次のようになります。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.1.4. アドレスプールの設定例 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、特定環境のアドレスプールの設定を示しています。
27.1.4.1. 例: IPv4 および CIDR 範囲 リンクのコピーリンクがクリップボードにコピーされました!
Classless Inter-Domain Routing (CIDR) 表記で IP アドレスの範囲を指定できます。CIDR 表記と、ハイフンを使用する表記を組み合わせて下層と上限を分けることができます。
27.1.4.2. 例: IP アドレスの割り当て リンクのコピーリンクがクリップボードにコピーされました!
autoAssign フィールドを false に設定すると、MetalLB がアドレスプールから IP アドレスを自動的に割り当てるのを防止できます。その場合、IP アドレスプールから単一の IP アドレスまたは複数の IP アドレスを割り当てることができます。IP アドレスを割り当てるには、spec.addresses パラメーター内のターゲット IP アドレスに CIDR 表記 /32 を追加します。この設定により、特定の IP アドレスのみが割り当て可能になります。予約されていない IP アドレスは、アプリケーション用に残されます。
複数の IP アドレスを割り当てる IPAddressPool CR の例
サービスを追加する場合は、アドレスプールから特定の IP アドレスを要求することも、アノテーションでプール名を指定して、そのプールから任意の IP アドレスを要求することもできます。
27.1.4.3. 例: IPv4 および IPv6 アドレス リンクのコピーリンクがクリップボードにコピーされました!
IPv4 および IPv6 を使用するアドレスプールを追加できます。複数の IPv4 の例と同様に、addresses 一覧で複数の範囲を指定できます。
サービスに、単一の IPv4 アドレス、単一の IPv6 アドレス、またはその両方を割り当てるかどうかは、サービスの追加方法によって決まります。spec.ipFamilies フィールドと spec.ipFamilyPolicy フィールドでは、IP アドレスをサービスに割り当てる方法を制御します。
- 1
10.0.100.0/28は、ローカルネットワーク IP アドレスとそれに続くネットワーク接頭辞/28です。
27.1.4.4. 例: IP アドレスプールをサービスまたは namespace に割り当てる リンクのコピーリンクがクリップボードにコピーされました!
IPAddressPool から指定したサービスと namespace に IP アドレスを割り当てることができます。
サービスまたは namespace を複数の IP アドレスプールに割り当てる場合、MetalLB は優先度の高い IP アドレスプールから使用可能な IP アドレスを使用します。割り当てられた優先度の高い IP アドレスプールから使用可能な IP アドレスがない場合、MetalLB は、優先度の低い、または優先度のない IP アドレスプールから使用可能な IP アドレスを使用します。
namespaceSelectors と serviceSelectors の仕様には、matchLabels ラベルセレクター、matchExpressions ラベルセレクター、またはその両方を使用できます。この例は、仕様ごとに 1 つのラベルセレクターを示しています。
27.1.5. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
27.2. IP アドレスプールのアドバタイズメントについて リンクのコピーリンクがクリップボードにコピーされました!
IP アドレスがレイヤー 2 プロトコル、BGP プロトコル、またはその両方でアドバタイズされるように MetalLB を設定できます。レイヤー 2 では、MetalLB ではフォールトトレラントな外部 IP アドレスを使用できます。BGP を使用すると、MetalLB で外部 IP アドレスに対するフォールトトレランス機能および負荷分散が提供されます。
MetalLB は、同じ IP アドレスのセットに対して L2 と BGP を使用したアドバタイズをサポートします。
MetalLB は、ネットワーク上のノードのサブセットに対して、特定の BGP ピアにアドレスプールを効果的に割り当てる柔軟性を提供します。これにより、たとえばノードの分離やネットワークのセグメンテーションを容易にするなど、より複雑な設定が可能になります。
27.2.1. BGPAdvertisement カスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
BGPAdvertisements オブジェクトのフィールドは、次の表に定義されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| BGP アドバタイズメントの名前を指定します。 |
|
|
| BGP アドバタイズメントの namespace を指定します。MetalLB Operator が使用するものと同じ namespace を指定します。 |
|
|
|
オプション: 32 ビット CIDR マスクに含めるビット数を指定します。マスクが複数のサービス IP アドレスのルートに適用され、speaker は集約されたルートをアドバタイズし、speaker が BGP ピアにアドバタイズするルートを集約します。たとえば、集約の長さが |
|
|
|
オプション: 128 ビット CIDR マスクに含めるビット数を指定します。たとえば、集約の長さが |
|
|
| オプション: 1 つ以上の BGP コミュニティーを指定します。各コミュニティーは、16 ビット値 2 つをコロン文字で区切って指定します。一般的なコミュニティーは、16 ビット値として指定する必要があります。
|
|
|
| オプション: このアドバタイズメントのローカル設定を指定します。この BGP 属性は、Autonomous System 内の BGP セッションに適用されます。 |
|
|
|
オプション: 名前で選択された、このアドバタイズメントでアドバタイズする |
|
|
|
オプション: このアドバタイズメントでアドバタイズされる |
|
|
|
オプション: |
|
|
|
オプション: リストを使用して、MetalLB サービス IP アドレスのアドバタイズメントを受信する各 |
27.2.2. BGP アドバタイズメントと基本的なユースケースを使用する MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB を次のとおり設定し、ピア BGP ルーターが、MetalLB がサービスに割り当てるロードバランサー IP アドレスごとに、203.0.113.200/32 ルート 1 つ、fc00:f853:ccd:e799::1/128 ルート 1 つを受信するようにします。localPref および communities フィールドが指定されていないため、ルートは localPref をゼロに設定して BGP コミュニティーなしでアドバタイズされます。
27.2.2.1. 例: BGP を使用する基本的なアドレスプール設定のアドバタイズメント リンクのコピーリンクがクリップボードにコピーされました!
IPAddressPool が BGP プロトコルでアドバタイズされるように、MetalLB を次のように設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP アドバタイズメントを作成します。
以下の例のような内容で、
bgpadvertisement.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f bgpadvertisement.yaml
$ oc apply -f bgpadvertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.3. BGP アドバタイズメントと高度なユースケースを使用する MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB を次のように設定し、MetalLB が 203.0.113.200 と 203.0.113.203、fc00:f853:ccd:e799::0 と fc00:f853:ccd:e799::f の範囲の IP アドレスを割り当てるようにします。
MetalLB が 203.0.113.200 の IP アドレスをサービスに割り当てる例を見ていき、これら 2 つの BGP アドバタイズメントを説明します。この IP アドレスを例にとると、speaker は 2 つのルートを BGP ピアにアドバタイズします。
-
localPrefが100に、コミュニティーがNO_ADVERTISEコミュニティーの数値に設定されている203.0.113.200/32。この仕様は、ピアルーターにこのルートを使用できることを指定していますが、このルートに関する情報を BGP ピアに伝播しないようにします。 -
MetalLB で割り当てられたロードバランサーの IP アドレスを 1 つのルートに集約する
203.0.113.200/30。MetalLB は、コミュニティー属性が8000:800に設定された BGP ピアに集約ルートをアドバタイズします。BGP ピアは、203.0.113.200/30ルートを他の BGP ピアに伝播します。トラフィックが speaker のあるノードにルーティングされる場合には、203.0.113.200/32ルートを使用して、トラフィックがクラスターに転送され、サービスに関連付けられている Pod に転送されます。
さらにサービスを追加し、MetalLB でプールからより多くのロードバランサー IP アドレスを割り当てると、ピアルーターはサービスごとにローカルルート 203.0.113.20x/32 を 1 つと、203.0.113.200/30 集約ルートを受け取ります。追加する各サービスは /30 ルートを生成しますが、MetalLB は、ピアルーターと通信する前に、ルートの重複を排除して 1 つの BGP アドバタイズにします。
27.2.3.1. 例: BGP を使用する高度なアドレスプール設定のアドバタイズメント リンクのコピーリンクがクリップボードにコピーされました!
IPAddressPool が BGP プロトコルでアドバタイズされるように、MetalLB を次のように設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP アドバタイズメントを作成します。
以下の例のような内容で、
bgpadvertisement1.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f bgpadvertisement1.yaml
$ oc apply -f bgpadvertisement1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のような内容で、
bgpadvertisement2.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f bgpadvertisement2.yaml
$ oc apply -f bgpadvertisement2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.4. ノードのサブセットからの IP アドレスプールのアドバタイズ リンクのコピーリンクがクリップボードにコピーされました!
特定のノードセットのみから IP アドレスプールから IP アドレスをアドバタイズするには、BGPAdvertisement カスタムリソースで .spec.nodeSelector 仕様を使用します。この仕様は、IP アドレスのプールをクラスター内の一連のノードに関連付けます。これは、クラスター内の異なるサブネット上にノードがあり、特定のサブネット (パブリックに面したサブネットのみなど) のアドレスプールから IP アドレスをアドバタイズしたい場合に役立ちます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
カスタムリソースを使用して IP アドレスプールを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGPAdvertisement カスタムリソースで
.spec.nodeSelector値を定義することにより、pool1からの IP アドレスがアドバタイズするクラスター内のノードを制御します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この例では、pool1 の IP アドレスは NodeA と NodeB からの み アドバタイズします。
27.2.5. L2Advertisement カスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
l2Advertisements オブジェクトのフィールドは、次の表に定義されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| L2 アドバタイズメントの名前を指定します。 |
|
|
| L2 アドバタイズメントの namespace を指定します。MetalLB Operator が使用するものと同じ namespace を指定します。 |
|
|
|
オプション: 名前で選択された、このアドバタイズメントでアドバタイズする |
|
|
|
オプション: このアドバタイズメントでアドバタイズされる |
|
|
|
オプション: 重要 ネクストホップとしてアナウンスするノードの制限は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。 Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。 |
|
|
|
オプション: ロードバランサー IP をアナウンスするために使用される |
27.2.6. L2 アドバタイズメントを使用した MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
IPAddressPool が L2 プロトコルでアドバタイズされるように、MetalLB を次のように設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
L2 アドバタイズメントを作成します。
以下の例のような内容で、
l2advertisement.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.7. L2 アドバタイズメントとラベルを使用した MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
BGPAdvertisement および L2Advertisement カスタムリソース定義の ipAddressPoolSelectors フィールドは、名前自体ではなく、IPAddressPool に割り当てられたラベルに基づいて IPAddressPool をアドバタイズメントに関連付けるために使用されます。
この例は、ipAddressPoolSelectors フィールドを設定することにより、IPAddressPool が L2 プロトコルでアドバタイズされるように MetalLB を設定する方法を示しています。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ipAddressPoolSelectorsを使用して IP をアドバタイズする L2 アドバタイズメントを作成します。以下の例のような内容で、
l2advertisement.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.2.8. 選択したインターフェイスの L2 アドバタイズを使用した MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、サービスに割り当てられた IP アドレスプールの IP アドレスが、すべてのネットワークインターフェイスからアドバタイズされます。L2Advertisement カスタムリソース定義の interfaces フィールドは、IP アドレスプールをアドバタイズするネットワークインターフェイスを制限するために使用されます。
この例では、すべてのノードの interfaces フィールドにリストされているネットワークインターフェイスからのみ IP アドレスプールがアドバタイズされるように、MetalLB を設定する方法を示します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
ipaddresspool.yamlなどのファイルを作成し、次の例のように設定の詳細を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
interfacesセレクターを使用して IP をアドバタイズする L2 アドバタイズメントを作成します。l2advertisement.yamlなどの YAML ファイルを作成し、次の例のように設定の詳細を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、広告の設定を適用します。
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
インターフェイスセレクターは、MetalLB が L2 を使用して特定の IP をアナウンスするノードを選択する方法には影響しません。ノードが選択されたインターフェイスを持たない場合、選択されたノードはサービスをアナウンスしません。
27.2.9. セカンダリーネットワークを使用した MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.14 以降、デフォルトのネットワーク動作では、ネットワークインターフェイス間での IP パケットの転送は許可されません。したがって、MetalLB がセカンダリーインターフェイス上に設定されている場合は、必要なインターフェイスに対してのみ IP 転送を有効にするマシン設定を追加する必要があります。
4.13 からアップグレードされた OpenShift Container Platform クラスターは、アップグレード中にグローバル IP 転送を有効にするグローバルパラメーターが設定されるため、影響を受けません。
セカンダリーインターフェイスの IP 転送を有効にするには、次の 2 つのオプションがあります。
- すべてのインターフェイスで IP 転送を有効にします。
特定のインターフェイスの IP 転送を有効にします。
注記特定のインターフェイスに対して IP 転送を有効にすると、よりきめ細かい制御が可能になりますが、すべてのインターフェイスに対して有効にすると、グローバル設定が適用されます。
手順
MachineConfigCR を作成して適用することで、bridge-netなどの特定のセカンダリーインターフェイスの転送を有効にします。-
Bridge-netという名前の指定されたセカンダリーインターフェイスの IP 転送を有効にするには、MachineConfigCR を作成します。 以下の YAML を
enable-ip-forward.yamlファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- IP 転送を有効にするノードロール (
workerなど)
以下のコマンドを実行して設定を適用します。
oc apply -f enable-ip-forward.yaml
$ oc apply -f enable-ip-forward.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
または、次のコマンドを実行して、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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3. MetalLB BGP ピアの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、ボーダーゲートウェイプロトコル (BGP) ピアを追加、変更、および削除できます。MetalLB Operator は、BGP ピアカスタムリソースを使用して、MetalLB speaker Pod が BGP セッションを開始するために接続するピアを識別します。ピアは、MetalLB がサービスに割り当てるロードバランサー IP アドレスのルートアドバタイズメントを受信します。
27.3.1. BGP ピアカスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
次の表で、BGP ピアカスタムリソースのフィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| BGP ピアカスタムリソースの名前を指定します。 |
|
|
| BGP ピアカスタムリソースの namespace を指定します。 |
|
|
|
BGP セッションのローカルエンドの AS 番号 (ASN) を指定します。追加するすべての BGP ピアカスタムリソースに同じ値を指定します。範囲は |
|
|
|
BGP セッションのリモートエンドの ASN を指定します。範囲は |
|
|
|
明示的に設定せずに、セッションのリモートエンドに使用する ASN を検出します。同じ ASN を持つピアの場合は |
|
|
| BGP セッションを確立するために接続するピアの IP アドレスを指定します。 |
|
|
| オプション: BGP セッションの確立時に使用する IP アドレスを指定します。値は IPv4 アドレスである必要があります。 |
|
|
|
オプション: BGP セッションを確立するために接続するピアのネットワークポートを指定します。範囲は |
|
|
|
オプション: BGP ピアに提案するホールドタイムの期間を指定します。最小値は 3 秒 ( |
|
|
|
オプション: キープアライブメッセージを BGP ピアに送信する間の最大間隔を指定します。このフィールドを指定する場合は、 |
|
|
| オプション: BGP ピアにアドバタイズするルーター ID を指定します。このフィールドを指定する場合は、追加するすべての BGP ピアカスタムリソースに同じ値を指定する必要があります。 |
|
|
| オプション: TCP MD5 認証が済んだ BGP セッションを実施するルーターのピアに送信する MD5 パスワードを指定します。 |
|
|
|
オプション: BGP ピアの認証シークレットの名前を指定します。シークレットは |
|
|
| オプション: BFD プロファイルの名前を指定します。 |
|
|
| オプション: 一致式と一致ラベルを使用してセレクターを指定し、BGP ピアに接続できるノードを制御します。 |
|
|
|
オプション: BGP ピアがネットワークホップ数回分を離れるように指定します。BGP ピアが同じネットワークに直接接続されていない場合には、このフィールドが |
passwordSecret フィールドは、password フィールドと相互に排他的であり、使用するパスワードを含むシークレットへの参照が含まれています。両方のフィールドを設定すると、解析が失敗します。
27.3.2. BGP ピアの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、BGP ピアカスタムリソースを追加して、ネットワークルーターとルーティング情報を交換し、サービスの IP アドレスをアドバタイズできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - BGP アドバタイズメントを使用して MetalLB を設定します。
手順
以下の例のような内容で、
bgppeer.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGP ピアの設定を適用します。
oc apply -f bgppeer.yaml
$ oc apply -f bgppeer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.3. 指定されたアドレスプールに対して特定の BGP ピアセットを設定 リンクのコピーリンクがクリップボードにコピーされました!
これは、以下を実行するための手順です。
-
アドレスプールのセット (
pool1およびpool2) を設定します。 -
BGP ピアセット (
peer1およびpeer2) を設定します。 -
pool1をpeer1に、pool2をpeer2に割り当てるように BGP アドバタイズメントを設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
アドレスプール
pool1を作成します。以下の例のような内容で、
ipaddresspool1.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプール
pool1の設定を適用します。oc apply -f ipaddresspool1.yaml
$ oc apply -f ipaddresspool1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
アドレスプール
pool2を作成します。以下の例のような内容で、
ipaddresspool2.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプール
pool2の設定を適用します。oc apply -f ipaddresspool2.yaml
$ oc apply -f ipaddresspool2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP
peer1を作成します。以下の例のような内容で、
bgppeer1.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGP ピアの設定を適用します。
oc apply -f bgppeer1.yaml
$ oc apply -f bgppeer1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP
peer2を作成します。以下の例のような内容で、
bgppeer2.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGP peer2 の設定を適用します。
oc apply -f bgppeer2.yaml
$ oc apply -f bgppeer2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP advertisement 1 を作成します。
以下の例のような内容で、
bgpadvertisement1.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f bgpadvertisement1.yaml
$ oc apply -f bgpadvertisement1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGP advertisement 2 を作成します。
以下の例のような内容で、
bgpadvertisement2.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc apply -f bgpadvertisement2.yaml
$ oc apply -f bgpadvertisement2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.4. ネットワーク VRF を介したサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークインターフェイス上の VRF を BGP ピアに関連付けることで、Virtual Routing and Forwarding (VRF) インスタンスを介してサービスを公開できます。
BGP ピア上の VRF を介したサービスの公開は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ネットワークインターフェイス上で VRF を使用して BGP ピア経由でサービスを公開すると、サービスへのトラフィックを分離し、独立したルーティング決定を設定し、ネットワークインターフェイス上でマルチテナントのサポートを有効化できます。
ネットワーク VRF に属するインターフェイスを通じて BGP セッションを確立すると、MetalLB はそのインターフェイスを通じてサービスをアドバタイズし、外部トラフィックがこのインターフェイスを通じてサービスに到達させることができます。ただし、ネットワーク VRF ルーティングテーブルは、OVN-Kubernetes で使用されるデフォルトの VRF ルーティングテーブルとは異なります。したがって、トラフィックは OVN-Kubernetes ネットワークインフラストラクチャーに到達できません。
サービスに送信されたトラフィックが OVN-Kubernetes ネットワークインフラストラクチャーに到達できるようにするには、ルーティングルールを設定してネットワークトラフィックのネクストホップを定義する必要があります。詳細は、関連情報 セクションの 「MetalLB を使用した対称ルーティングの管理」の NodeNetworkConfigurationPolicy リソースを参照してください。
BGP ピアを使用してネットワーク VRF を介してサービスを公開するための概要手順は次のとおりです。
- BGP ピアを定義し、ネットワーク VRF インスタンスを追加します。
- MetalLB の IP アドレスプールを指定します。
- MetalLB の BGP ルートアドバタイズメントを設定して、指定された IP アドレスプールと VRF インスタンスに関連付けられた BGP ピアを使用してルートをアドバタイズします。
- サービスをデプロイして設定をテストします。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 -
NodeNetworkConfigurationPolicyを定義して、Virtual Routing and Forwarding (VRF) インスタンスをネットワークインターフェイスに関連付けた。この前提条件を満たす方法の詳細は、関連情報 セクションを参照してください。 - MetalLB をクラスターにインストールした。
手順
BGPPeerカスタムリソース (CR) を作成します。次の例のような内容を含むファイル
(frrviavrf.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- BGP ピアに関連付けるネットワーク VRF インスタンスを指定します。MetalLB は、サービスをアドバタイズし、VRF 内のルーティング情報に基づいてルーティングを決定できます。
注記このネットワーク VRF インスタンスは
NodeNetworkConfigurationPolicyCR で設定する必要があります。詳細は、関連情報 を参照してください。次のコマンドを実行して、BGP ピアの設定を適用します。
oc apply -f frrviavrf.yaml
$ oc apply -f frrviavrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
IPAddressPoolCR を作成します。次の例のような内容を含むファイル (
first-pool.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、IP アドレスプールの設定を適用します。
oc apply -f first-pool.yaml
$ oc apply -f first-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGPAdvertisementCR を作成します。次の例のような内容を含むファイル (
first-adv.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、MetalLB は、
first-poolの IP アドレスプールからfrrviavrfBGP ピアに IP アドレスの範囲をアドバタイズします。
次のコマンドを実行して、BGP アドバタイズメントの設定を適用します。
oc apply -f first-adv.yaml
$ oc apply -f first-adv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Namespace、Deployment、およびServiceCR を作成します。次の例のような内容を含むファイル (
deploy-service.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、namespace、デプロイメント、およびサービスの設定を適用します。
oc apply -f deploy-service.yaml
$ oc apply -f deploy-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、MetalLB スピーカー Pod を識別します。
oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE speaker-c6c5f 6/6 Running 0 69m
NAME READY STATUS RESTARTS AGE speaker-c6c5f 6/6 Running 0 69mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、BGP セッションの状態がスピーカー Pod で
Establishedとなっていることを確認します。設定に一致するように変数を置き換えます。oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71 BGP state = Established, up for 04:20:09 ...
BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71 BGP state = Established, up for 04:20:09 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、サービスが正しくアドバタイズされていることを確認します。
oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.3.5. BGP ピア設定の例 リンクのコピーリンクがクリップボードにコピーされました!
27.3.5.1. 例: BGP ピアに接続するノードの制限 リンクのコピーリンクがクリップボードにコピーされました!
ノードセレクターフィールドを指定して、BGP ピアに接続できるノードを制御できます。
27.3.5.2. 例: BGP ピアの BFD プロファイル指定 リンクのコピーリンクがクリップボードにコピーされました!
BGP ピアに関連付ける BFD プロファイルを指定できます。BFD は、BGP のみの場合よりも、ピア間の通信障害をより迅速に検出して、BGP を補完します。
双方向転送検出 (BFD) プロファイルを削除し、ボーダーゲートウェイプロトコル (BGP) ピアリソースに追加された bfdProfile を削除しても、BFD は無効になりません。代わりに、BGP ピアはデフォルトの BFD プロファイルの使用を開始します。BGP ピアリソースから BFD をディセーブルにするには、BGP ピア設定を削除し、BFD プロファイルなしで再作成します。詳細は、BZ#2050824 を参照してください。
27.3.5.3. 例: デュアルスタックネットワーク用の BGP ピア指定 リンクのコピーリンクがクリップボードにコピーされました!
デュアルスタックネットワーキングをサポートするには、IPv4 用に BGP ピアカスタムリソース 1 つと IPv6 用に BGP ピアカスタムリソースを 1 つ追加します。
27.3.6. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
27.4. コミュニティーエイリアスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、コミュニティーエイリアスを設定して、さまざまなアドバタイズメントで使用できます。
27.4.1. コミュニティーカスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
community カスタムリソースは、コミュニティーのエイリアスのコレクションです。ユーザーは、BGPAdvertisement を使用して ipAddressPools をアドバタイズするときに使用される名前付きエイリアスを定義できます。次の表で、community カスタムリソースのフィールドを説明します。
community CRD は BGPAdvertisement にのみ適用されます。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
BGPAdvertisements で使用できる BGP コミュニティーエイリアスのリストを指定します。コミュニティーエイリアスは、名前 (エイリアス) と値 (番号 : 番号) のペアで構成されます。 |
| フィールド | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
指定された名前に対応する BGP |
27.4.2. BGP アドバタイズメントとコミュニティーエイリアスを使用した MetalLB の設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB を次のように設定し、IPAddressPool が BGP プロトコルでアドバタイズされ、コミュニティーエイリアスが NO_ADVERTISE コミュニティーの数値に設定されるようにします。
次の例では、ピア BGP ルーター doc-example-peer-community は、MetalLB がサービスに割り当てるロードバランサー IP アドレスごとに 1 つの 203.0.113.200/32 ルートと 1 つの fc00:f853:ccd:e799::1/128 ルートを受信します。コミュニティーエイリアスは、NO_ADVERTISE コミュニティーで設定されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
IP アドレスプールを作成します。
以下の例のような内容で、
ipaddresspool.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow IP アドレスプールの設定を適用します。
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
community1という名前のコミュニティーエイリアスを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow doc-example-bgp-peerという名前の BGP ピアを作成します。以下の例のような内容で、
bgppeer.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGP ピアの設定を適用します。
oc apply -f bgppeer.yaml
$ oc apply -f bgppeer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
コミュニティーエイリアスを使用して BGP アドバタイズメントを作成します。
以下の例のような内容で、
bgpadvertisement.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ここでは、コミュニティーのカスタムリソース (CR) 名ではなく、
CommunityAlias.nameを指定します。
設定を適用します。
oc apply -f bgpadvertisement.yaml
$ oc apply -f bgpadvertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.5. MetalLB BFD プロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、双方向フォワーディング検出 (BFD) プロファイルを追加、変更、および削除できます。MetalLB Operator は、BFD プロファイルのカスタムリソースを使用して、BFD を使用する BGP セッションで、BGP だけの時よりも障害検出のパスを素早く見つけ出すセッションを特定します。
27.5.1. BFD プロファイルカスタムリソースについて リンクのコピーリンクがクリップボードにコピーされました!
次の表で、BFD プロファイルのカスタムリソースのフィールドを説明します。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| BFD プロファイルカスタムリソースの名前を指定します。 |
|
|
| BFD プロファイルカスタムリソースの namespace を指定します。 |
|
|
| パケット損失を決定するための検出乗数を指定します。リモート送信間隔にこの値を乗算して、接続損失検出タイマーを決定します。
たとえば、ローカルシステムの検出乗数が
範囲は |
|
|
|
エコー送信モードを指定します。分散 BFD を使用していないと、エコー送信モードは、ピアが FRR でもある場合にのみ機能します。デフォルト値は
エコー送信モードが有効になっている場合は、制御パケットの送信間隔を増やして、帯域幅の使用量を減らすことを検討してください。たとえば、送信間隔を |
|
|
|
このシステムがエコーパケットの送受信に使用する最小送信間隔 (ジッターの軽減) を指定します。範囲は |
|
|
| 着信制御パケットに最小限必要な TTL を指定します。このフィールドは、マルチホップセッションにのみ適用されます。 最小 TTL を設定する目的は、パケット検証要件をより厳しくし、他のセッションからの制御パケットの受信を回避することです。
デフォルト値は |
|
|
| セッションをアクティブまたはパッシブとしてマークするかどうかを指定します。パッシブセッションは接続の開始を試行しません。代わりに、パッシブセッションは、応答の開始前にピアからの制御パケットを待機します。 セッションをパッシブとしてマークすることは、スターネットワークの中央ノードとして機能するルーターがあり、システムが送信する必要のない制御パケットの送信を避ける場合に役立ちます。
デフォルト値は |
|
|
|
このシステムが制御パケットを受信できる最小間隔を指定します。範囲は |
|
|
|
このシステムが制御パケットの送信に使用する最小送信間隔 (ジッターの軽減) を指定します。範囲は |
27.5.2. BFD プロファイルの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、BFD プロファイルを追加し、そのプロファイルを使用するように BGP ピアを設定できます。BFD は、BGP のみよりも、パスの障害検出が高速になります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
次の例のようなコンテンツを含む
bfdprofile.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow BFD プロファイルの設定を適用します。
oc apply -f bfdprofile.yaml
$ oc apply -f bfdprofile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
27.5.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
- BFD プロファイルを使用するように BGP ピアを設定 します。
27.6. MetalLB を使用するためのサービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、タイプ LoadBalancer のサービスを追加するときに、MetalLB が IP アドレスを割り当てる方法を制御できます。
27.6.1. 特定の IP アドレスの要求 リンクのコピーリンクがクリップボードにコピーされました!
他のロードバランサーの実装と同様に、MetalLB はサービス仕様の spec.loadBalancerIP フィールドを受け入れます。
要求された IP アドレスが任意のアドレスプールの範囲内にある場合、MetalLB は要求された IP アドレスを割り当てます。要求された IP アドレスが範囲外の場合、MetalLB は警告を報告します。
特定の IP アドレスのサービス YAML の例
MetalLB が要求された IP アドレスを割り当てることができない場合、サービスの EXTERNAL-IP が <pending> を報告し、oc describe service <service_name> の実行には、以下の例のようなイベントが含まれます。
MetalLB が要求された IP アドレスを割り当てることができない場合のイベントの例
... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning AllocationFailed 3m16s metallb-controller Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning AllocationFailed 3m16s metallb-controller Failed to allocate IP for "default/invalid-request": "4.3.2.1" is not allowed in config
27.6.2. 特定のプールからの IP アドレスの要求 リンクのコピーリンクがクリップボードにコピーされました!
特定の範囲から IP アドレスを割り当てても、特定の IP アドレスを気にしない場合は、metallb.universe.tf/address-pool アノテーションを使用して、指定したアドレスプールから IP アドレスを要求できます。
特定プールからの IP アドレスのサービス YAML の例
<address_pool_name> に指定するアドレスプールが存在しない場合、MetalLB は、自動割り当てを許可する任意のプールから IP アドレスを割り当てようとします。
27.6.3. 任意の IP アドレスを許可します。 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、アドレスプールは自動割り当てを許可するように設定されます。MetalLB は、これらのアドレスプールから IP アドレスを割り当てます。
自動割り当て用に設定されたプールから IP アドレスを受け入れるには、特別なアノテーションや設定は必要ありません。
任意の IP アドレスを受け入れるサービス YAML の例
27.6.5. MetalLB を使用したサービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
アドレスプールから外部 IP アドレスを使用するように、負荷分散サービスを設定することができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - MetalLB Operator をインストールして、MetalLB を起動します。
- 1 つ以上のアドレスプールを設定します。
- トラフィックをクライアントからクラスターのホストネットワークにルーティングするようにネットワークを設定します。
手順
<service_name>.yamlファイルを作成します。このファイルで、spec.typeフィールドがLoadBalancerに設定されていることを確認します。MetalLB がサービスに割り当てる外部 IP アドレスを要求する方法は、例を参照してください。
サービスを作成します。
oc apply -f <service_name>.yaml
$ oc apply -f <service_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
service/<service_name> created
service/<service_name> createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
サービスを記述します。
oc describe service <service_name>
$ oc describe service <service_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.7. MetalLB を使用した対称ルーティングの管理 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、MetalLB、NMState、OVN-Kubernetes の機能を実装することで、複数のホストインターフェイスを備えた MetalLB ロードバランサーサービスの背後にある Pod のトラフィックを効果的に管理できます。このコンテキストでこれらの機能を組み合わせることで、対称ルーティング、トラフィック分離を提供し、重複する CIDR アドレスを持つ異なるネットワーク上のクライアントをサポートできます。
この機能を実現するために、MetalLB を使用して Virtual Routing and Forwarding (VRF) インスタンスを実装し、Egress サービスを設定する方法を説明します。
MetalLB と出力サービスを備えた VRF インスタンスを使用した対称トラフィックの設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
27.7.1. MetalLB を使用した対称ルーティング管理の課題 リンクのコピーリンクがクリップボードにコピーされました!
複数のホストインターフェイスで MetalLB を使用すると、MetalLB はホスト上で使用可能なすべてのインターフェイスを通じてサービスを公開し、通知します。これにより、ネットワークの分離、非対称リターントラフィック、CIDR アドレスの重複に関する課題が生じる可能性があります。
戻りトラフィックが正しいクライアントに確実に到達するための 1 つのオプションとして、静的ルートを使用します。ただし、このソリューションでは、MetalLB がサービスを分離して、別のインターフェイスを通じて各サービスを通知できません。さらに、静的ルーティングには手動設定が必要であり、リモートサイトが追加された場合はメンテナンスが必要になります。
外部システムで、アプリケーションの送信元と宛先の IP アドレスが同じである必要があるシナリオなどが、MetalLB サービスの実装時における対称ルーティングのさらなる課題として挙げられます。OpenShift Container Platform のデフォルトの動作では、ホストネットワークインターフェイスの IP アドレスが、Pod から発信されるトラフィックの送信元 IP アドレスとして割り当てられます。これは、複数のホストインターフェイスがある場合に問題になります。
MetalLB、NMState、OVN-Kubernetes の機能を組み合わせた設定を実装することで、これらの課題を克服できます。
27.7.2. MetalLB で VRF を使用した対称ルーティング管理の概要 リンクのコピーリンクがクリップボードにコピーされました!
NMState を使用してホスト上で VRF インスタンスを設定し、VRF インスタンスを MetalLB BGPPeer リソースに関連付け、OVN-Kubernetes を使用して出力トラフィック用の出力サービスを設定することで、対称ルーティングの実装の課題を克服できます。
図27.1 MetalLB で VRF を使用して対称ルーティングを管理するネットワークの概要
設定プロセスには 3 つの段階が含まれます。
1.VRF とルーティングルールを定義する
-
NodeNetworkConfigurationPolicyカスタムリソース (CR) を設定して、VRF インスタンスをネットワークインターフェイスに関連付けます。 - VRF ルーティングテーブルを使用して、受信トラフィックと送信トラフィックを送信します。
2. VRF を MetalLB BGPPeer にリンクする
-
ネットワークインターフェイス上で VRF インスタンスを使用するように MetalLB
BGPPeerリソースを設定します。 -
BGPPeerリソースを VRF インスタンスに関連付けることにより、指定されたネットワークインターフェイスが BGP セッションのプライマリーインターフェイスになり、MetalLB はこのインターフェイスを通じてサービスをアドバタイズします。
3.Egress サービスを設定する
- Egress サービスを設定して、Egress トラフィック用の VRF インスタンスに関連付けられたネットワークを選択します。
- オプション: MetalLB ロードバランサーサービスの IP アドレスを Egress トラフィックの送信元 IP として使用するように Egress サービスを設定します。
27.7.3. MetalLB で VRF を使用した対称ルーティングの設定 リンクのコピーリンクがクリップボードにコピーされました!
同じ入力ネットワークパスと Egress ネットワークパスを必要とする MetalLB サービスの背後にあるアプリケーションに対して対称ネットワークルーティングを設定できます。
この例では、VRF ルーティングテーブルを MetalLB および出力サービスに関連付けて、LoadBalancer サービスの背後にある Pod の Ingress および Egress トラフィックの対称ルーティングを有効にします。
-
EgressServiceCR でsourceIPBy: "LoadBalancerIP"設定を使用する場合は、BGPAdvertisementカスタムリソース (CR) でロードバランサーノードを指定する必要があります。 -
sourceIPBy: "Network"設定は、gatewayConfig.routingViaHost仕様がtrueに設定された OVN-Kubernetes を使用するクラスターでのみ使用できます。さらに、sourceIPBy: "Network"設定を使用する場合は、ネットワーク VRF インスタンスで設定されたノード上でアプリケーションワークロードをスケジュールする必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - Kubernetes NMState Operator をインストールします。
- MetalLB Operator がインストールされている。
手順
NodeNetworkConfigurationPolicyCR を作成して VRF インスタンスを定義します。次の例のような内容を含むファイル (
node-network-vrf.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ポリシーの名前。
- 2
- この例では、
vrf:trueのラベルが割り当てられたべてのノードにポリシーを適用します。 - 3
- インターフェイスの名前。
- 4
- インターフェイスのタイプ。この例では VRF インスタンスを作成します。
- 5
- VRF が接続されるノードインターフェイス。
- 6
- VRF のルートテーブル ID の名前。
- 7
- VRF に関連付けられたインターフェイスの IPv4 アドレス。
- 8
- ネットワークルートの設定を定義します。
next-hop-addressフィールドは、ルートのネクストホップの IP アドレスを定義します。next-hop-interfaceフィールドは、ルートの送信インターフェイスを定義します。この例では、VRF ルーティングテーブルは2で、EgressServiceCR で定義した ID を参照します。 - 9
- 追加のルートルールを定義します。
ip-toフィールドは、Cluster Networkの CIDR、Service Networkの CIDR、およびInternal Masqueradeサブネットの CIDR と一致する必要があります。oc describe network.operator/clusterコマンドを実行すると、これらの CIDR アドレス仕様の値を表示できます。 - 10
- Linux カーネルがルートを計算するときに使用するメインルーティングテーブルの ID は
254です。
以下のコマンドを実行してポリシーを適用します。
oc apply -f node-network-vrf.yaml
$ oc apply -f node-network-vrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGPPeerカスタムリソース (CR) を作成します。次の例のような内容を含むファイル (
frr-via-vrf.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- BGP ピアに関連付ける VRF インスタンスを指定します。MetalLB は、サービスをアドバタイズし、VRF 内のルーティング情報に基づいてルーティングを決定できます。
次のコマンドを実行して、BGP ピアの設定を適用します。
oc apply -f frr-via-vrf.yaml
$ oc apply -f frr-via-vrf.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
IPAddressPoolCR を作成します。次の例のような内容を含むファイル (
first-pool.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、IP アドレスプールの設定を適用します。
oc apply -f first-pool.yaml
$ oc apply -f first-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
BGPAdvertisementCR を作成します。次の例のような内容を含むファイル (
first-adv.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、BGP アドバタイズメントの設定を適用します。
oc apply -f first-adv.yaml
$ oc apply -f first-adv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
EgressServiceCR を作成します。次の例のような内容を含むファイル (
egress-service.yamlなど) を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Egress サービスの名前を指定します。
EgressServiceリソースの名前は、変更するロードバランサーサービスの名前と一致する必要があります。 - 2
- Egress サービスの namespace を指定します。
EgressServiceの namespace は、変更するロードバランサーサービスの namespace と一致する必要があります。Egress サービスは namespace スコープです。 - 3
- この例では、
LoadBalancerサービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てます。 - 4
sourceIPBy仕様のLoadBalancerを指定すると、単一ノードがLoadBalancerサービストラフィックを処理します。この例では、ラベルがvrf: "true"のノードのみがサービストラフィックを処理できます。ノードを指定しない場合、OVN-Kubernetes はサービストラフィックを処理するワーカーノードを選択します。ノードが選択されると、OVN-Kubernetes はそのノードにegress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: ""という形式でラベルを付けます。- 5
- Egress トラフィックのルーティングテーブル ID を指定します。必ず
NodeNetworkConfigurationPolicyリソースで定義されているroute-table-idID (例:route-table-id: 2) と一致する値を指定してください。
次のコマンドを実行して、Egress サービスの設定を適用します。
oc apply -f egress-service.yaml
$ oc apply -f egress-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、MetalLB サービスの背後で実行されている Pod のアプリケーションエンドポイントにアクセスできることを確認します。
curl <external_ip_address>:<port_number>
$ curl <external_ip_address>:<port_number>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- アプリケーションのエンドポイントに合わせて外部 IP アドレスとポート番号を更新します。
-
オプション:
LoadBalancerサービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てた場合は、tcpdumpなどのツールを使用して外部クライアントで受信したパケットを分析し、この設定を確認します。
27.8. MetalLB と FRR-K8s の統合の設定 リンクのコピーリンクがクリップボードにコピーされました!
FRRConfiguration カスタムリソースは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
FRRouting (FRR) は、Linux および UNIX プラットフォーム用の無料のオープンソースインターネットルーティングプロトコルスイートです。FRR-K8s は、Kubernetes に準拠した方法で FRR API のサブセットを公開する Kubernetes ベースの DaemonSet です。クラスター管理者は、FRRConfiguration カスタムリソース (CR) を使用して、MetalLB がバックエンドとして FRR-K8s を使用するように設定できます。これを使用して、受信ルートなどの FRR サービスを利用できます。FRR-K8s をバックエンドとして MetalLB を実行すると、MetalLB は適用された MetalLB 設定に対応する FRR-K8s 設定を生成します。
27.8.1. MetalLB と FRR-K8s の統合の有効化 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、MetalLB のバックエンドとして FRR-K8s をアクティブ化する方法を示します。
前提条件
- ベアメタルハードウェアにクラスターがインストールされている。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
次の例のように、
MetalLBCR のbgpBackendフィールドをfrr-k8sに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.8.2. FRR の設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB で FRR サービスを使用するために、複数の FRRConfiguration CR を作成できます。MetalLB は FRRConfiguration オブジェクトを生成し、FRR-K8s はそのオブジェクトをすべてのユーザーが作成した他のすべての設定とマージします。
たとえば、特定の近隣によりアドバタイズされた接頭辞すべてを受信するように FRR-K8s を設定できます。次の例では、ホスト 172.18.0.5 の BGPPeer によってアドバタイズされるすべての接頭辞を受信するように FRR-K8 を設定します。
FRRConfiguration CR の例
また、FRR-K8s を設定して、適用される設定に関係なく、常に接頭辞のセットをブロックすることもできます。これは、クラスターが誤動作する可能性のある Pod または ClusterIPs CIDR へのルートを回避するのに役立ちます。次の例では、接頭辞セット 192.168.1.0/24 をブロックします。
MetalLB CR の例
FRR-K8s を設定すると、クラスターネットワーク CIDR と サービスネットワーク CIDR をブロックできます。次のコマンドを実行すると、これらの CIDR アドレス仕様の値を表示できます。
oc describe network.config/cluster
$ oc describe network.config/cluster
27.8.3. FRRConfiguration CRD の設定 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、FRRConfiguration カスタムリソース (CR) を使用する参照例を示します。
27.8.3.1. routers フィールド リンクのコピーリンクがクリップボードにコピーされました!
routers フィールドを使用して、Virtual Routing and Forwarding (VRF) リソースごとに 1 つずつ、複数のルーターを設定できます。各ルーターに AS 番号 (ASN) を定義する必要があります。
次の例のように、接続する Border Gateway Protocol (BGP) の近隣のリストを定義することもできます。
FRRConfiguration CR の例
27.8.3.2. toAdvertise フィールド リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、FRR-K8s はルーター設定の一部として設定された接頭辞をアドバタイズしません。これらをアドバタイズするには、toAdvertise フィールドを使用します。
次の例のように、接頭辞のサブセットをアドバタイズできます。
FRRConfiguration CR の例
- 1
- 接頭辞のサブセットをアドバタイズします。
次の例は、すべての接頭辞をアドバタイズする方法を示しています。
FRRConfiguration CR の例
- 1
- すべての接頭辞をアドバタイズします。
27.8.3.3. toReceive フィールド リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、FRR-K8s は近隣によってアドバタイズされた接頭辞を処理しません。toReceive フィールドを使用して、このようなアドレスを処理できます。
次の例のように、接頭辞のサブセットを設定できます。
FRRConfiguration CR の例
次の例では、アナウンスされたすべての接頭辞を処理するように FRR を設定します。
FRRConfiguration CR の例
27.8.3.4. bgp フィールド リンクのコピーリンクがクリップボードにコピーされました!
bgp フィールドを使用して、さまざまな BFD プロファイルを定義し、それらを近隣に関連付けることができます。次の例では、BFD は、BGP セッションをバックアップし、FRR はリンク障害を検出できます。
FRRConfiguration CR の例
27.8.3.5. nodeSelector フィールド リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、FRR-K8s は、デーモンが実行されているすべてのノードに設定を適用します。nodeSelector フィールドを使用して、設定を適用するノードを指定できます。以下に例を示します。
FRRConfiguration CR の例
FRRConfiguration カスタムリソースのフィールドは、次の表で説明されています。
| フィールド | 型 | 説明 |
|---|---|---|
|
|
| FRR が設定するルーターを指定します (VRF ごとに 1 つ)。 |
|
|
| セッションのローカル側で使用する AS 番号 (ASN)。 |
|
|
|
|
|
|
| このルーターからセッションを確立するために使用されるホスト VRF を指定します。 |
|
|
| BGP セッションを確立する近隣を指定します。 |
|
|
| セッションのリモート終了に使用する ASN を指定します。 |
|
|
| セッションを確立する IP アドレスを指定します。 |
|
|
| セッションを確立するときにダイアリングするポートを指定します。デフォルトは 179 です。 |
|
|
|
BGP セッションの確立に使用するパスワードを指定します。 |
|
|
|
ネイバーの認証シークレットの名前を指定します。シークレットは "kubernetes.io/basic-auth" タイプであり、FRR-K8s デーモンと同じ namespace にある必要があります。キー "password" はパスワードをシークレットに保存します。 |
|
|
| RFC4271 に従って、要求された BGP ホールド時間を指定します。デフォルトは 180s です。 |
|
|
|
RFC4271 に従って、要求された BGP キープアライブ時間を指定します。デフォルトは |
|
|
| BGP が近隣に次に接続を試行するまで待機する時間を指定します。 |
|
|
| BGPPeer がマルチホップ分、離れているかどうかを示します。 |
|
|
| BGP セッションに関連付けられた BFD セッションに使用する BFD プロファイルの名前を指定します。設定されていない場合、BFD セッションは設定されません。 |
|
|
| 近隣にアドバタイズする接頭辞のリストと、関連するプロパティーを表します。 |
|
|
| 近隣にアドバタイズする接頭辞のリストを指定します。このリストは、ルーターで定義した接頭辞と一致する必要があります。 |
|
|
|
接頭辞を処理するときに使用するモードを指定します。接頭辞リスト内の接頭辞のみを許可するように |
|
|
| アドバタイズされたローカルプリファレンスに関連付けられた接頭辞を指定します。ローカル設定に関連付けられた接頭辞を、アドバタイズが許可される接頭辞に指定する必要があります。 |
|
|
| ローカル設定に関連付けられた接頭辞を指定します。 |
|
|
| 接頭辞に関連付けられたローカル設定を指定します。 |
|
|
| アドバタイズされた BGP コミュニティーに関連付けられた接頭辞を指定します。アドバタイズする接頭辞のリストに、ローカル設定に関連付けられた接頭辞を含める必要があります。 |
|
|
| コミュニティーに関連付けられた接頭辞を指定します。 |
|
|
| 接頭辞に関連付けられたコミュニティーを指定します。 |
|
|
| 近隣から受信する接頭辞を指定します。 |
|
|
| 近隣から受信する情報を指定します。 |
|
|
| 近隣から許可される接頭辞を指定します。 |
|
|
|
接頭辞を処理するときに使用するモードを指定します。 |
|
|
| MP BGP を無効にして、IPv4 と IPv6 のルート交換を別々の BGP セッションに分離しないようにします。 |
|
|
| このルーターインスタンスからアドバタイズするすべての接頭辞を指定します。 |
|
|
| 近隣を設定するときに使用する BFD プロファイルのリストを指定します。 |
|
|
| 設定の他の部分で参照される BFD プロファイルの名前。 |
|
|
|
このシステムが制御パケットを受信できる最小間隔をミリ秒単位で指定します。デフォルトは |
|
|
|
このシステムが BFD 制御パケットを送信するために使用する、ジッターを除いた最小送信間隔をミリ秒単位で指定します。デフォルトは |
|
|
| パケット損失を判定するための検出乗数を設定します。接続損失検出タイマーを決定するには、リモート送信間隔にこの値を乗算します。 |
|
|
|
このシステムが処理できる最小のエコー受信送信間隔をミリ秒単位で設定します。デフォルトは |
|
|
| エコー送信モードを有効または無効にします。このモードはデフォルトで無効になっており、マルチホップ設定ではサポートされていません。 |
|
|
| セッションを passive としてマークします。passive セッションでは接続を開始せず、応答を開始する前にピアからの制御パケットを待機します。 |
|
|
| マルチホップセッションのみ。着信 BFD 制御パケットの最小予想 TTL を設定します。 |
|
|
| この設定の適用を試みるノードを制限します。指定した場合、指定されたセレクターに一致するラベルが割り当てられたノードのみが設定の適用を試みます。指定されていない場合は、すべてのノードがこの設定を適用しようとします。 |
|
|
| FRRConfiguration の監視状態を定義します。 |
27.8.4. FRR-K8s が複数の設定を統合する方法 リンクのコピーリンクがクリップボードにコピーされました!
複数のユーザーが同じノードを選択する設定を追加した場合、FRR-K8s は設定をマージします。各設定は他の設定のみを拡張できます。つまり、ルーターに新しい近隣を追加したり、ネイバーに追加の接頭辞をアドバタイズできますが、別の設定によって追加されたコンポーネントを削除できません。
27.8.4.1. 設定の競合 リンクのコピーリンクがクリップボードにコピーされました!
特定の設定では競合が発生し、エラーが発生する可能性があります。次に例を示します。
- 同じルーター (同じ VRF 内) に対して異なる ASN がある
- 同じネイバー (同じ IP/ポート) に対して異なる ASN がある
- 名前が同じで値が異なる BFD プロファイルが複数ある
デーモンは、ノードに対して無効な設定を検出すると、その設定を無効として報告し、以前の有効な FRR 設定に戻します。
27.8.4.2. マージ リンクのコピーリンクがクリップボードにコピーされました!
マージする場合、次のアクションを実行できます。
- 近隣にアドバタイズする IP セットを拡張します。
- IP セットを持つ別の近隣を追加します。
- コミュニティーを関連付ける IP のセットを拡張します。
- 近隣への着信ルートを許可します。
各設定は自己完結型である必要があります。つまり、たとえば、別の設定からの接頭辞を活用して、ルーターセクションで定義されていない接頭辞を許可することはできません。
適用する設定に互換性がある場合、マージは次のように機能します。
-
FRR-K8sは、すべてのルーターを組み合わせます。 -
FRR-K8sは、ルーターごとにすべての接頭辞と近隣をマージします。 -
FRR-K8sは、近隣ごとに、すべてのフィルターをマージします。
制限の少ないフィルターは、制限が厳密なフィルターよりも優先されます。たとえば、一部の接頭辞を受け入れるフィルターは、接頭辞をまったく受け入れないフィルターよりも優先され、すべての接頭辞を受け入れるフィルターは、一部の接頭辞を受け入れるフィルターよりも優先されます。
27.9. MetalLB のロギング、トラブルシューティング、サポート リンクのコピーリンクがクリップボードにコピーされました!
MetalLB 設定のトラブルシューティングが必要な場合は、次のセクションで一般的に使用されるコマンドを参照してください。
27.9.1. MetalLB ログレベルの設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB は、デフォルト設定の info を使用してコンテナーで FRRouting (FRR) を使用し、大量のログを生成します。この例に示すように logLevel を設定することにより、生成されるログの詳細度を制御できます。
次のように logLevel を debug に設定することで、MetalLB についてより深い洞察を得ることができます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
以下の例のような内容で、
setdebugloglevel.yamlなどのファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定を適用します。
oc replace -f setdebugloglevel.yaml
$ oc replace -f setdebugloglevel.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記metallbCR はすでに作成されており、ここではログレベルを変更していることを理解したうえで、oc replaceを使用します。speakerPod の名前を表示します。oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE speaker-2m9pm 4/4 Running 0 9m19s speaker-7m4qw 3/4 Running 0 19s speaker-szlmx 4/4 Running 0 9m19s
NAME READY STATUS RESTARTS AGE speaker-2m9pm 4/4 Running 0 9m19s speaker-7m4qw 3/4 Running 0 19s speaker-szlmx 4/4 Running 0 9m19sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記スピーカー Pod とコントローラー Pod が再作成され、更新されたログレベルが確実に適用されます。MetalLB のすべてのコンポーネントのログレベルが変更されます。
speakerログを表示します。oc logs -n metallb-system speaker-7m4qw -c speaker
$ oc logs -n metallb-system speaker-7m4qw -c speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow FRR ログを表示します。
oc logs -n metallb-system speaker-7m4qw -c frr
$ oc logs -n metallb-system speaker-7m4qw -c frrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
27.9.1.1. FRRouting (FRR) ログレベル リンクのコピーリンクがクリップボードにコピーされました!
次の表で、FRR ログレベルを説明します。
| ログレベル | 説明 |
|---|---|
|
| すべてのログレベルのすべてのログ情報を提供します。 |
|
|
診断に役立つ情報。詳細なトラブルシューティング情報を提供するには、 |
|
| 常にログに記録する必要がある情報を提供しますが、通常の状況ではユーザーの介入は必要ありません。これはデフォルトのログレベルです。 |
|
|
一貫性のない |
|
|
|
|
| すべてのロギングをオフにします。 |
27.9.2. BGP の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat がサポートする BGP 実装は、speaker Pod のコンテナーで FRRouting (FRR) を使用します。クラスター管理者は、BGP 設定の問題をトラブルシューティングする場合に、FRR コンテナーでコマンドを実行する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
speakerPod の名前を表示します。oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 56m speaker-gvfnf 4/4 Running 0 56m ...
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 56m speaker-gvfnf 4/4 Running 0 56m ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow FRR の実行設定を表示します。
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show running-config"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow BGP サマリーを表示します。
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp summary"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アドレスプールを受信した BGP ピアを表示します。
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bgp ipv4 unicast 203.0.113.200/30"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ipv4をipv6に置き換えて、IPv6 アドレスプールを受信した BGP ピアを表示します。203.0.113.200/30は、アドレスプールの IPv4 または IPv6IP アドレス範囲に置き換えます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 出力に BGP ピアの IP アドレスが含まれていることを確認します。
27.9.3. BFD の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Red Hat がサポートする双方向フォワーディング検出 (BFD) の実装では、speaker Pod のコンテナーで FRRouting (FRR) を使用します。BFD の実装は、BFD ピアに依存しており、このピアは、BGP セッションが確立されている BGP ピアとして設定されています。クラスター管理者は、BFD 設定の問題をトラブルシューティングする場合に、FRR コンテナーでコマンドを実行する必要があります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
speakerPod の名前を表示します。oc get -n metallb-system pods -l component=speaker
$ oc get -n metallb-system pods -l component=speakerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 26m speaker-gvfnf 4/4 Running 0 26m ...
NAME READY STATUS RESTARTS AGE speaker-66bth 4/4 Running 0 26m speaker-gvfnf 4/4 Running 0 26m ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow BFD ピアを表示します。
oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"
$ oc exec -n metallb-system speaker-66bth -c frr -- vtysh -c "show bfd peers brief"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Session count: 2 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3909139637 10.0.1.2 10.0.2.3 up <.>
Session count: 2 SessionId LocalAddress PeerAddress Status ========= ============ =========== ====== 3909139637 10.0.1.2 10.0.2.3 up <.>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <.>
PeerAddress列に各 BFD ピアが含まれていることを確認します。出力に含まれると予想される BFD ピア IP アドレスが出力にリストされていない場合は、ピアとの BGP 接続のトラブルシューティングを行います。ステータスフィールドがdownと表示されている場合は、ノードとピア間のリンクと機器の接続を確認します。speaker Pod のノード名は、oc get pods -n metallb-system speaker-66bth -o jsonpath='{.spec.nodeName}'などのコマンドで判断できます。
27.9.4. BGP および BFD の MetalLB メトリック リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、BGP ピアと BFD プロファイルに関連する MetalLB の次の Prometheus メトリクスをキャプチャーします。
| 名前 | 説明 |
|---|---|
|
| 各 BFD ピアから受信した BFD 制御パケットの数をカウントします。 |
|
| 各 BFD ピアに送信された BFD 制御パケットの数をカウントします。 |
|
| 各 BFD ピアから受信した BFD エコーパケットの数をカウントします。 |
|
| 各 BFD に送信された BFD エコーパケットの数をカウントします。 |
|
|
ピアとの BFD セッションが |
|
|
BFD ピアとの接続状態を示します。 |
|
|
ピアとの BFD セッションが |
|
| 各 BFD ピアの BFD Zebra 通知の数をカウントします。 |
| 名前 | 説明 |
|---|---|
|
| BGP ピアにアドバタイズされるロードバランサーの IP アドレス接頭辞の数をカウントします。接頭辞と集約ルートという用語は同じ意味です。 |
|
|
BGP ピアとの接続状態を示します。 |
|
| 各 BGP ピアに送信された BGP 更新メッセージの数をカウントします。 |
|
| 各 BGP ピアに送信された BGP オープンメッセージの数をカウントします。 |
|
| 各 BGP ピアから受信した BGP オープンメッセージの数をカウントします。 |
|
| 各 BGP ピアに送信された BGP 通知メッセージの数をカウントします。 |
|
| 各 BGP ピアから受信した BGP 更新メッセージの数をカウントします。 |
|
| 各 BGP ピアに送信された BGP keepalive メッセージの数をカウントします。 |
|
| 各 BGP ピアから受信した BGP keepalive メッセージの数をカウントします。 |
|
| 各 BGP ピアに送信された BGP ルートリフレッシュメッセージの数をカウントします。 |
|
| 各 BGP ピアに送信された BGP メッセージの合計数をカウントします。 |
|
| 各 BGP ピアから受信した BGP メッセージの合計数をカウントします。 |
関連情報
- モニタリングダッシュボードの使用方法については、モニタリングダッシュボードを使用してすべてのプロジェクトのメトリクスのクエリーを実行する を参照してください。
27.9.5. MetalLB データの収集について リンクのコピーリンクがクリップボードにコピーされました!
oc adm must-gather CLI コマンドを使用して、クラスター、MetalLB 設定、および MetalLB Operator に関する情報を収集できます。次の機能とオブジェクトは、MetalLB と MetalLB Operator に関連付けられています。
- MetalLB Operator がデプロイされている namespace と子オブジェクト
- すべての MetalLB Operator カスタムリソース定義 (CRD)
oc adm must-gather CLI コマンドは、Red Hat が BGP および BFD 実装に使用する FRRouting (FRR) から次の情報を収集します。
-
/etc/frr/frr.conf -
/etc/frr/frr.log -
/etc/frr/daemons設定ファイル -
/etc/frr/vtysh.conf
上記のリストのログファイルと設定ファイルは、各 speaker Pod の frr コンテナーから収集されます。
ログファイルと設定ファイル以外に、oc adm must-gather の CLI コマンドは、次の vtysh コマンドからの出力を収集します。
-
show running-config -
show bgp ipv4 -
show bgp ipv6 -
show bgp neighbor -
show bfd peer
oc adm must-gather CLI コマンドを実行する場合、追加の設定は必要ありません。
関連情報
第28章 セカンダリーインターフェイスメトリクスのネットワーク割り当てへの関連付け リンクのコピーリンクがクリップボードにコピーされました!
28.1. モニタリングのためのセカンダリーネットワークメトリックの拡張 リンクのコピーリンクがクリップボードにコピーされました!
セカンダリーデバイス (インターフェイス) は、各種の用途に合わせて使用されます。セカンダリーデバイスのメトリックを同じ分類で集計するために、それらを分類する方法を確保する必要があります。
公開されるメトリクスにはインターフェイスが含まれますが、インターフェイスの出所は指定されません。これは、追加のインターフェイスがない場合に実行できます。ただし、セカンダリーインターフェイスが追加された場合、インターフェイス名だけを使用してインターフェイスを識別するのは難しいため、メトリックの使用が困難になる可能性があります。
セカンダリーインターフェイスを追加する場合、その名前は追加された順序によって異なります。また、異なるセカンダリーインターフェイスが異なるネットワークに属し、これらを異なる目的に使用できます。
pod_network_name_info を使用すると、現在のメトリクスをインターフェイスタイプを識別する追加情報を使用して拡張できます。このようにして、メトリクスを集約し、特定のインターフェイスタイプに特定のアラームを追加できます。
ネットワークタイプは、関連する NetworkAttachmentDefinition の名前を使用して生成されます。この名前は、セカンダリーネットワークの異なるクラスを区別するために使用されます。たとえば、異なるネットワークに属するインターフェイスや、異なる CNI を使用するインターフェイスは、異なるネットワーク割り当て定義名を使用します。
28.1.1. Network Metrics Daemon リンクのコピーリンクがクリップボードにコピーされました!
Network Metrics Daemon は、ネットワーク関連のメトリックを収集し、公開するデーモンコンポーネントです。
kubelet はすでに確認できるネットワーク関連のメトリックを公開しています。以下は、これらのメトリックになります。
-
container_network_receive_bytes_total -
container_network_receive_errors_total -
container_network_receive_packets_total -
container_network_receive_packets_dropped_total -
container_network_transmit_bytes_total -
container_network_transmit_errors_total -
container_network_transmit_packets_total -
container_network_transmit_packets_dropped_total
これらのメトリックのラベルには、とくに以下が含まれます。
- Pod の名前
- Pod の namespace
-
インターフェイス名 (例:
eth0)
これらのメトリックは、たとえば Multus を使用して、新規インターフェイスが Pod に追加されるまで正常に機能します。
インターフェイスのラベルはインターフェイス名を参照しますが、そのインターフェイスの用途は明確ではありません。多くの異なるインターフェイスがある場合、監視しているメトリックが参照するネットワークを把握することはできません。
これには、以降のセクションで説明する新規の pod_network_name_info を導入して対応できます。
28.1.2. ネットワーク名を持つメトリック リンクのコピーリンクがクリップボードにコピーされました!
この daemonset は、固定の値が 0 の pod_network_name_info 測定メトリックを公開します。
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0
ネットワーク名ラベルは、Multus によって追加されるアノテーションを使用して生成されます。これは、ネットワークの割り当て定義が属する namespace の連結と、ネットワーク割り当て定義の名前です。
新しいメトリクスのみでは十分な値が提供されませんが、ネットワーク関連の container_network_* メトリクスと組み合わせて、セカンダリーネットワークの監視に対するサポートを強化します。
以下のような promql クエリーを使用すると、k8s.v1.cni.cncf.io/network-status アノテーションから取得した値とネットワーク名を含む新規のメトリクスを取得できます。
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.