ネットワーク
クラスターネットワークの設定および管理
概要
第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 を使用できます。
以下のリストは、クラスターで利用可能な最も一般的に使用される 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 は IngressController
API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。
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 は
IngressController
API を実装し、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 を使用できます。
- 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章 ゼロトラストネットワーク
ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。
OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。
以下は、ゼロトラストネットワークの対象となる機能の詳細です。
3.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 など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。
3.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 プロトコルに使用するためにマウントできる証明書を要求します。
3.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 と直接対話するようにアプリケーションを変更することもできます。
3.4. サービス間認可
リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。
活用方法:
-
OpenShift Container Platform: Kubernetes
NetworkPolicy
およびAdminNetworkPolicy
オブジェクトを使用して、プラットフォームのネットワーク層で分離を強制できます。 - Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトを使用して、mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 の トラフィック制御。
3.5. トランザクションレベルの検証
接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。
活用方法:
- Red Hat OpenShift Service Mesh: 要求の L7 検査、不正な HTTP 要求の拒否、トランザクションレベルの 可観測性およびレポート を行います。Service Mesh は、JWT を使用した 要求ベースの認証 も提供できます。
3.6. リスク評価
クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。
活用方法:
-
Red Hat OpenShift Service Mesh: OpenShift Web コンソール を使用して、Kubernetes の
NetworkPolicy
とAdminNetworkPolicy
、および OpenShift Networking のEgressFirewall
オブジェクトを作成および可視化します。 - Red Hat Advanced Cluster Security for Kubernetes: 高度な オブジェクトの可視化。
3.7. サイト全体のポリシーの施行と配布
クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。
活用方法:
- Red Hat OpenShift Service Mesh: ポリシーオブジェクトを制御 し、制御を委譲する RBAC。
- Red Hat Advanced Cluster Security for Kubernetes: ポリシー適用 エンジン。
- Red Hat Advanced Cluster Management (RHACM) for Kubernetes: 一元的なポリシー制御。
3.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: 適切に計装されたアプリケーションでは、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連するすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。
3.9. エンドポイントセキュリティー
クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。
活用方法:
- OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名された イメージのみを実行するように設定できます。
- Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。
3.10. クラスター外への信頼の拡張
クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。
活用方法:
- OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
- Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントに、ワークロードのリモートアテステーションを提供できます。
第4章 ホストへのアクセス
OpenShift Container Platform インスタンスにアクセスして、セキュアシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。
4.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
コマンドで作成される仮想プライベートクラウド (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!
第5章 ネットワーキング Operator の概要
OpenShift Container Platform は、複数のタイプのネットワーキング Operator をサポートします。これらのネットワーク Operator を使用して、クラスターネットワークを管理できます。
5.1. Cluster Network Operator
Cluster Network Operator (CNO) は、OpenShift Container Platform クラスター内のクラスターネットワークコンポーネントをデプロイおよび管理します。これには、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインのデプロイが含まれます。詳細は、OpenShift Container Platform における Cluster Network Operator を参照してください。
5.2. DNS Operator
DNS Operator は、CoreDNS をデプロイして管理し、Pod に名前解決サービスを提供します。これにより、OpenShift Container Platform で DNS ベースの Kubernetes サービス検出が可能になります。詳細は、OpenShift Container Platform の DNS Operator を参照してください。
5.3. Ingress Operator
OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれの IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は Ingress Controller API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にします。詳細は、OpenShift Container Platform の Ingress Operator を参照してください。
5.4. 外部 DNS Operator
外部 DNS Operator は、ExternalDNS をデプロイして管理し、外部 DNS プロバイダーから OpenShift Container Platform へのサービスおよびルートの名前解決を提供します。詳細は、Understanding the External DNS Operator を参照してください。
5.5. Ingress Node Firewall Operator
Ingress Node Firewall Operator は、拡張された Berkley Packet Filter (eBPF) と eXpress Data Path (XDP) プラグインを使用して、ノードファイアウォールルールを処理し、統計を更新し、ドロップされたトラフィックのイベントを生成します。Operator は、Ingress ノードファイアウォールリソースを管理し、ファイアウォール設定を検証し、クラスターアクセスを妨げる可能性がある誤設定されたルールを許可せず、ルールのオブジェクトで選択されたインターフェイスに Ingress ノードファイアウォール XDP プログラムをロードします。詳細は、Ingress Node Firewall Operator についてを参照してください。
5.6. Network Observability Operator
Network Observability Operator は、クラスター管理者が OpenShift Container Platform クラスターのネットワークトラフィックを観察するために使用できるオプションの Operator です。Network Observability Operator は、eBPF テクノロジーを使用してネットワークフローを作成します。その後、ネットワークフローは OpenShift Container Platform 情報で強化され、Loki に保存されます。保存されたネットワークフロー情報を OpenShift Container Platform コンソールで表示および分析して、さらなる洞察とトラブルシューティングを行うことができます。詳細は、ネットワーク可観測性 Operator について を参照してください。
第6章 ネットワークダッシュボード
ネットワークメトリクスは、OpenShift Container Platform Web コンソール内のダッシュボードから、Observe → Dashboards で表示できます。
6.1. Network Observability Operator
Network Observability Operator がインストールされている場合は、Dashboards ドロップダウンリストから Netobserv ダッシュボードを選択すると、ネットワークトラフィックメトリクスダッシュボードが表示されます。このダッシュボード で利用できるメトリクスの詳細は、ネットワーク可観測性メトリクスのダッシュボード を参照してください。
6.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 です。
6.3. Ingress Operator ダッシュボード
Ingress Operator によって処理されるネットワークメトリクスをダッシュボードから表示できます。これには、次のようなメトリクスが含まれます。
- 受信および送信の帯域幅
- HTTP エラーレート
- HTTP サーバーの応答遅延
これらの Ingress メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Ingress を選択します。Top 10 Per Route、Top 10 Per Namespace、Top 10 Per Shard のカテゴリーの Ingress メトリクスを表示できます。
第7章 OpenShift Container Platform における Cluster Network Operator
Cluster Network Operator (CNO) を使用すると、インストール時にクラスター用に選択された Container Network Interface (CNI) ネットワークプラグインを含む、OpenShift Container Platform クラスター上のクラスターネットワークコンポーネントをデプロイおよび管理できます。
7.1. Cluster Network Operator
Cluster Network Operator は、operator.openshift.io
API グループから network
API を実装します。Operator は、デーモンセットを使用して、クラスターのインストール中に選択した OVN-Kubernetes ネットワークプラグインまたはネットワークプロバイダープラグインをデプロイします。
手順
Cluster Network Operator は、インストール時に Kubernetes Deployment
としてデプロイされます。
以下のコマンドを実行して Deployment のステータスを表示します。
oc get -n openshift-network-operator deployment/network-operator
$ oc get -n openshift-network-operator deployment/network-operator
Copy to Clipboard Copied! 出力例
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
NAME READY UP-TO-DATE AVAILABLE AGE network-operator 1/1 1 1 56m
Copy to Clipboard Copied! 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
oc get clusteroperator/network
$ oc get clusteroperator/network
Copy to Clipboard Copied! 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.5.4 True False False 50m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE network 4.5.4 True False False 50m
Copy to Clipboard Copied! 以下のフィールドは、Operator のステータス (
AVAILABLE
、PROGRESSING
、およびDEGRADED
) に関する情報を提供します。AVAILABLE
フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合にTrue
になります。
7.2. クラスターネットワーク設定の表示
すべての新規 OpenShift Container Platform インストールには、cluster
という名前の network.config
オブジェクトがあります。
手順
oc describe
コマンドを使用して、クラスターネットワーク設定を表示します。oc describe network.config/cluster
$ oc describe network.config/cluster
Copy to Clipboard Copied! 出力例
Name: cluster Namespace: Labels: <none> Annotations: <none> API Version: config.openshift.io/v1 Kind: Network Metadata: Self Link: /apis/config.openshift.io/v1/networks/cluster Spec: Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Status: Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Cluster Network MTU: 8951 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Events: <none>
Name: cluster Namespace: Labels: <none> Annotations: <none> API Version: config.openshift.io/v1 Kind: Network Metadata: Self Link: /apis/config.openshift.io/v1/networks/cluster Spec:
1 Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Status:
2 Cluster Network: Cidr: 10.128.0.0/14 Host Prefix: 23 Cluster Network MTU: 8951 Network Type: OpenShiftSDN Service Network: 172.30.0.0/16 Events: <none>
Copy to Clipboard Copied!
7.3. Cluster Network Operator のステータス表示
oc describe
コマンドを使用して、Cluster Network Operator のステータスを検査し、その詳細を表示することができます。
手順
以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
oc describe clusteroperators/network
$ oc describe clusteroperators/network
Copy to Clipboard Copied!
7.4. IP 転送をグローバルに有効にする
OpenShift Container Platform 4.14 以降では、OVN-Kubernetes ベースのクラスターデプロイメントでグローバル IP アドレス転送が無効になります。これは、ルーターとして機能するノードによる、クラスター管理者にとって望ましくない影響を防ぐためです。ただし、トラフィックの転送が必要な場合には、すべての IP トラフィックの転送を許可する新しい設定パラメーター ipForwarding
を利用できます。
OVN-Kubernetes 管理インターフェイス上の全トラフィックの IP 転送を再度有効にするには、次の手順に従って、Cluster Network Operator の gatewayConfig.ipForwarding
仕様を Global
に設定します。
手順
次のコマンドを実行して、既存のネットワーク設定をバックアップします。
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yaml
Copy to Clipboard Copied! 次のコマンドを実行して、既存のネットワーク設定を変更します。
oc edit network.operator cluster
$ oc edit network.operator cluster
Copy to Clipboard Copied! 次の例に示すように、
spec
の下に次のブロックを追加または更新します。spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 networkType: OVNKubernetes clusterNetworkMTU: 8900 defaultNetwork: ovnKubernetesConfig: gatewayConfig: ipForwarding: Global
spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 networkType: OVNKubernetes clusterNetworkMTU: 8900 defaultNetwork: ovnKubernetesConfig: gatewayConfig: ipForwarding: Global
Copy to Clipboard Copied! - ファイルを保存してから閉じます。
変更を適用した後、OpenShift Cluster Network Operator (CNO) によってクラスター全体に更新が適用されます。次のコマンドを使用して進行状況を監視できます。
oc get clusteroperators network
$ oc get clusteroperators network
Copy to Clipboard Copied! 最終的に、ステータスに
Available
、Progressing=False
、Degraded=False
と報告されるはずです。または、次のコマンドを実行して、IP 転送をグローバルに有効にすることもできます。
oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}
$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}
Copy to Clipboard Copied! 注記この変更を元に戻す必要がある場合は、このパラメーターのもう 1 つの有効なオプションである
Restricted
を設定します。デフォルトではRestricted
に設定されており、グローバル IP アドレス転送は無効です。
7.5. Cluster Network Operator ログの表示
oc logs
コマンドを使用して、Cluster Network Operator ログを表示できます。
手順
以下のコマンドを実行して、Cluster Network Operator のログを表示します。
oc logs --namespace=openshift-network-operator deployment/network-operator
$ oc logs --namespace=openshift-network-operator deployment/network-operator
Copy to Clipboard Copied!
7.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 オブジェクトに設定することにより、クラスターのクラスターネットワークプラグイン設定を指定できます。
7.6.1. Cluster Network Operator 設定オブジェクト
Cluster Network Operator (CNO) のフィールドは以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNO オブジェクトの名前。この名前は常に |
|
| Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23
|
|
| サービスの 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 設定の例
defaultNetwork: type: OpenShiftSDN openshiftSDNConfig: mode: NetworkPolicy mtu: 1450 vxlanPort: 4789
defaultNetwork:
type: OpenShiftSDN
openshiftSDNConfig:
mode: NetworkPolicy
mtu: 1450
vxlanPort: 4789
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 設定の例
defaultNetwork: type: OVNKubernetes ovnKubernetesConfig: mtu: 1400 genevePort: 6081 ipsecConfig: mode: Full
defaultNetwork:
type: OVNKubernetes
ovnKubernetesConfig:
mtu: 1400
genevePort: 6081
ipsecConfig:
mode: Full
OVNKubernetes を使用すると、IBM Power® でスタック枯渇の問題が発生する可能性があります。
kubeProxyConfig オブジェクト設定 (OpenShiftSDN コンテナーネットワークインターフェイスのみ)
kubeProxyConfig
オブジェクトの値は以下の表で定義されます。
フィールド | 型 | 説明 |
---|---|---|
|
|
注記
OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、 |
|
|
kubeProxyConfig: proxyArguments: iptables-min-sync-period: - 0s
|
7.6.2. Cluster Network Operator の設定例
以下の例では、詳細な CNO 設定が指定されています。
Cluster Network Operator オブジェクトのサンプル
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 serviceNetwork: - 172.30.0.0/16 networkType: OVNKubernetes clusterNetworkMTU: 8900
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
serviceNetwork:
- 172.30.0.0/16
networkType: OVNKubernetes
clusterNetworkMTU: 8900
第8章 OpenShift Container Platform の DNS Operator
DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、OpenShift Container Platform での DNS ベースの Kubernetes サービス検出を可能にします。
8.1. DNS Operator
DNS Operator は、operator.openshift.io
API グループから dns
API を実装します。この Operator は、デーモンセットを使用して CoreDNS をデプロイし、デーモンセットのサービスを作成し、kubelet を Pod に対して名前解決に CoreDNS サービス IP を使用するように指示するように設定します。
手順
DNS Operator は、インストール時に Deployment
オブジェクトを使用してデプロイされます。
oc get
コマンドを使用してデプロイメントのステータスを表示します。oc get -n openshift-dns-operator deployment/dns-operator
$ oc get -n openshift-dns-operator deployment/dns-operator
Copy to Clipboard Copied! 出力例
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE dns-operator 1/1 1 1 23h
Copy to Clipboard Copied! oc get
コマンドを使用して DNS Operator の状態を表示します。oc get clusteroperator/dns
$ oc get clusteroperator/dns
Copy to Clipboard Copied! 出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE dns 4.1.0-0.11 True False False 92m
Copy to Clipboard Copied! AVAILABLE
、PROGRESSING
およびDEGRADED
は、Operator のステータスについての情報を提供します。AVAILABLE
は、CoreDNS デーモンセットからの 1 つ以上の Pod がAvailable
ステータス条件を報告する場合はTrue
になります。
8.2. DNS Operator managementState の変更
DNS は CoreDNS コンポーネントを管理し、クラスター内の Pod およびサービスの名前解決サービスを提供します。DNS Operator の managementState
はデフォルトで Managed
に設定されます。これは、DNS Operator がそのリソースをアクティブに管理できることを意味します。これを Unmanaged
に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。
以下は、DNS Operator managementState
を変更するためのユースケースです。
-
開発者であり、CoreDNS の問題が修正されているかどうかを確認するために設定変更をテストする必要があります。
managementState
をUnmanaged
に設定すると、DNS Operator により修正が上書きされないようにできます。 -
クラスター管理者であり、CoreDNS の問題が報告されていますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の
managementState
フィールドをUnmanaged
に設定して、回避策を適用できます。
手順
managementState
DNS Operator を変更します。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!
8.3. DNS Pod 配置の制御
DNS Operator には、CoreDNS 用と /etc/hosts
ファイルを管理するための 2 つのデーモンセットがあります。/etc/hosts
に設定されたデーモンは、イメージのプルをサポートするクラスターイメージレジストリーのエントリーを追加するために、すべてのノードホストで実行する必要があります。セキュリティーポリシーにより、ノードのペア間の通信が禁止され、CoreDNS のデーモンセットがすべてのノードで実行できなくなります。
クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。
前提条件
-
oc
CLI がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしている。
手順
特定のノード間の通信を防ぐには、
spec.nodePlacement.nodeSelector
API フィールドを設定します。default
という名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! spec.nodePlacement.nodeSelector
API フィールドにコントロールプレーンノードのみが含まれるノードセレクターを指定します。spec: nodePlacement: nodeSelector: node-role.kubernetes.io/worker: ""
spec: nodePlacement: nodeSelector: node-role.kubernetes.io/worker: ""
Copy to Clipboard Copied!
CoreDNS のデーモンセットをノードで実行されるようにするには、テイントおよび容認を設定します。
default
という名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! taint の taint キーおよび toleration を指定します。
spec: nodePlacement: tolerations: - effect: NoExecute key: "dns-only" operators: Equal value: abc tolerationSeconds: 3600
spec: nodePlacement: tolerations: - effect: NoExecute key: "dns-only" operators: Equal value: abc tolerationSeconds: 3600
1 Copy to Clipboard Copied! - 1
- taint が
dns-only
である場合、それは無制限に許容できます。tolerationSeconds
は省略できます。
8.4. デフォルト DNS の表示
すべての新規 OpenShift Container Platform インストールには、default
という名前の dns.operator
があります。
手順
oc describe
コマンドを使用してデフォルトのdns
を表示します。oc describe dns.operator/default
$ oc describe dns.operator/default
Copy to Clipboard Copied! 出力例
Name: default Namespace: Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: DNS ... Status: Cluster Domain: cluster.local Cluster IP: 172.30.0.10 ...
Name: default Namespace: Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: DNS ... Status: Cluster Domain: cluster.local
1 Cluster IP: 172.30.0.10
2 ...
Copy to Clipboard Copied! クラスターのサービス 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!
出力例
[172.30.0.0/16]
[172.30.0.0/16]
8.5. DNS 転送の使用
DNS 転送を使用して、次の方法で/etc/resolv.conf
ファイルのデフォルトの転送設定を上書きできます。
- すべてのゾーンにネームサーバーを指定します。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、アップストリームネームサーバーがドメインについて認証される必要があります。
- アップストリーム DNS サーバーのリストを指定します。
- デフォルトの転送ポリシーを変更します。
デフォルトドメインの DNS 転送設定には、/etc/resolv.conf
ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。
手順
default
という名前の DNS Operator オブジェクトを変更します。oc edit dns.operator/default
$ oc edit dns.operator/default
Copy to Clipboard Copied! 以前のコマンドを実行した後に、Operator は
Server
に基づく追加のサーバー設定ブロックを使用してdns-default
という名前の config map を作成して更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。DNS 転送の設定
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: servers: - name: example-server zones: - example.com forwardPlugin: policy: Random upstreams: - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers: policy: Random upstreams: - type: SystemResolvConf - type: Network address: 1.2.3.4 port: 53
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: servers: - name: example-server
1 zones:
2 - example.com forwardPlugin: policy: Random
3 upstreams:
4 - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers:
5 policy: Random
6 upstreams:
7 - type: SystemResolvConf
8 - type: Network address: 1.2.3.4
9 port: 53
10 Copy to Clipboard Copied! - 1
rfc6335
サービス名の構文に準拠する必要があります。- 2
rfc1123
サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインのcluster.local
は、zones
フィールドの無効なサブドメインです。- 3
- アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値は
Random
です。RoundRobin
およびSequential
の値を使用することもできます。 - 4
forwardPlugin
ごとに最大 15 のupstreams
が許可されます。- 5
- オプション: これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは
/etc/resolv.conf
のサーバーに送信されます。 - 6
- クエリー用にアップストリームサーバーが選択される順序を決定します。
Random
、RoundRobin
、またはSequential
のいずれかの値を指定できます。デフォルト値はSequential
です。 - 7
- オプション: これを使用して、アップストリームリゾルバーを指定できます。
- 8
SystemResolvConf
とNetwork
の 2 種類のアップストリーム
を指定できます。SystemResolvConf
で、アップストリームが/etc/resolv.conf
を使用するように設定して、Network
でNetworkresolver
を定義します。1 つまたは両方を指定できます。- 9
- 指定したタイプが
Network
の場合には、IP アドレスを指定する必要があります。address
フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。 - 10
- 指定したタイプが
Network
の場合、必要に応じてポートを指定できます。port
フィールドの値は1
〜65535
である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。
任意: 高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。
TLS を使用した DNS 転送の設定
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: servers: - name: example-server zones: - example.com forwardPlugin: transportConfig: transport: TLS tls: caBundle: name: mycacert serverName: dnstls.example.com policy: Random upstreams: - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers: transportConfig: transport: TLS tls: caBundle: name: mycacert serverName: dnstls.example.com upstreams: - type: Network address: 1.2.3.4 port: 53
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: servers: - name: example-server
1 zones:
2 - example.com forwardPlugin: transportConfig: transport: TLS
3 tls: caBundle: name: mycacert serverName: dnstls.example.com
4 policy: Random
5 upstreams:
6 - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers:
7 transportConfig: transport: TLS tls: caBundle: name: mycacert serverName: dnstls.example.com upstreams: - type: Network
8 address: 1.2.3.4
9 port: 53
10 Copy to Clipboard Copied! - 1
rfc6335
サービス名の構文に準拠する必要があります。- 2
rfc1123
サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインのcluster.local
は、zones
フィールドの無効なサブドメインです。クラスタードメインのcluster.local
は、zones
の無効なsubdomain
です。- 3
- 転送された DNS クエリーの TLS を設定する場合、
transport
フィールドの値をTLS
に設定します。デフォルトでは、CoreDNS は転送された接続を 10 秒間キャッシュします。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。 - 4
- 転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。
- 5
- アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値は
Random
です。RoundRobin
およびSequential
の値を使用することもできます。 - 6
- 必須。これを使用して、アップストリームリゾルバーを指定できます。
forwardPlugin
エントリーごとに最大 15 のupstreams
エントリーが許可されます。 - 7
- 任意。これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは
/etc/resolv.conf
のサーバーに送信されます。 - 8
Network
タイプは、このアップストリームリゾルバーが/etc/resolv.conf
にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。TLS を使用する場合、Network
タイプのみが許可され、IP アドレスを指定する必要があります。- 9
address
フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。- 10
- オプションでポートを指定できます。
port
の値は1
〜65535
である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。
注記servers
が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。
検証
config map を表示します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yaml
Copy to Clipboard Copied! 以前のサンプル DNS に基づく DNS ConfigMap の例
apiVersion: v1 data: Corefile: | example.com:5353 { forward . 1.1.1.1 2.2.2.2:5353 } bar.com:5353 example.com:5353 { forward . 3.3.3.3 4.4.4.4:5454 } .:5353 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf 1.2.3.4:53 { policy Random } cache 30 reload } kind: ConfigMap metadata: labels: dns.operator.openshift.io/owning-dns: default name: dns-default namespace: openshift-dns
apiVersion: v1 data: Corefile: | example.com:5353 { forward . 1.1.1.1 2.2.2.2:5353 } bar.com:5353 example.com:5353 { forward . 3.3.3.3 4.4.4.4:5454
1 } .:5353 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf 1.2.3.4:53 { policy Random } cache 30 reload } kind: ConfigMap metadata: labels: dns.operator.openshift.io/owning-dns: default name: dns-default namespace: openshift-dns
Copy to Clipboard Copied! - 1
forwardPlugin
への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。
8.6. DNS Operator のステータス
oc describe
コマンドを使用して、DNS Operator のステータスを検査し、その詳細を表示することができます。
手順
DNS Operator のステータスを表示します。
oc describe clusteroperators/dns
$ oc describe clusteroperators/dns
8.7. DNS Operator ログ
oc logs
コマンドを使用して、DNS Operator ログを表示できます。
手順
DNS Operator のログを表示します。
oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator
8.8. CoreDNS ログレベルの設定
CoreDNS ログレベルを設定して、ログに記録されたエラーメッセージの情報量を決定できます。CoreDNS ログレベルの有効な値は、Normal
、Debug
、および Trace
です。デフォルトの logLevel
は Normal
です。
エラープラグインは常に有効になっています。次の logLevel
設定は、さまざまなエラー応答を報告します。
-
logLevel
:Normal
は "errors" class:log . { class error }
を有効にします。 -
logLevel
:Debug
は "denial" class:log . { class denial error }
を有効にします。 -
logLevel
:Trace
は "all" class:log . { class all }
を有効にします。
手順
logLevel
をDebug
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge
Copy to Clipboard Copied! logLevel
をTrace
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
Copy to Clipboard Copied!
検証
目的のログレベルが設定されていることを確認するには、config map を確認します。
oc get configmap/dns-default -n openshift-dns -o yaml
$ oc get configmap/dns-default -n openshift-dns -o yaml
Copy to Clipboard Copied!
8.9. 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! すべての 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! - 1
- ログをストリーミングする DNS Pod の数を指定します。最大は 6 です。
8.10. CoreDNS Operator のログレベルの設定
クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel
の有効な値は、Normal
、Debug
、および Trace
です。Trace
には最も詳細にわたる情報が含まれます。デフォルトのoperatorlogLevel
はNormal
です。問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。
-
operatorLogLevel: "Normal"
はlogrus.SetLogLevel("Info")
を設定します。 -
operatorLogLevel: "Debug"
はlogrus.SetLogLevel("Debug")
を設定します。 -
operatorLogLevel: "Trace"
はlogrus.SetLogLevel("Trace")
を設定します。
手順
operatorLogLevel
をDebug
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge
Copy to Clipboard Copied! operatorLogLevel
をTrace
に設定するには、次のコマンドを入力します。oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
Copy to Clipboard Copied!
8.11. CoreDNS キャッシュのチューニング
CoreDNS によって実行される成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間を調整すると、上流の DNS リゾルバーの負荷を軽減できます。
手順
次のコマンドを実行して、
default
という名前の DNS Operator オブジェクトを編集します。oc edit dns.operator.openshift.io/default
$ oc edit dns.operator.openshift.io/default
Copy to Clipboard Copied! Time-to-Live (TTL) キャッシュ値を変更します。
DNS キャッシングの設定
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: cache: positiveTTL: 1h negativeTTL: 0.5h10m
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: cache: positiveTTL: 1h
1 negativeTTL: 0.5h10m
2 Copy to Clipboard Copied! 警告TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。
第9章 OpenShift Container Platform の Ingress Operator
9.1. OpenShift Container Platform Ingress Operator
OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は IngressController
API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。
Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route
および Kubernetes Ingress
リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy
タイプおよび内部負荷分散を定義する機能などの Ingress Controller 内の設定は、Ingress Controller エンドポイントを公開する方法を提供します。
9.2. Ingress 設定アセット
インストールプログラムでは、config.openshift.io
API グループの Ingress
リソースでアセットを生成します (cluster-ingress-02-config.yml
)。
Ingress
リソースの YAML 定義
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.openshiftdemos.com
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
spec:
domain: apps.openshiftdemos.com
インストールプログラムは、このアセットを manifests/
ディレクトリーの cluster-ingress-02-config.yml
ファイルに保存します。この Ingress
リソースは、Ingress のクラスター全体の設定を定義します。この Ingress 設定は、以下のように使用されます。
- Ingress Operator は、クラスター Ingress 設定のドメインを、デフォルト Ingress Controller のドメインとして使用します。
-
OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない
Route
リソースのデフォルトホストを生成する際にも使用されます。
9.3. Ingress Controller 設定パラメーター
IngressController
カスタムリソース (CR) には、組織の特定のニーズを満たすように設定できる任意の設定パラメーターが含まれています。
パラメーター | 説明 |
---|---|
|
空の場合、デフォルト値は |
|
|
|
クラウド環境の場合、
GCP、AWS、および Azure では、次の
設定されていない場合、デフォルト値は
ほとんどのプラットフォームでは、
ベアメタルプラットフォームなどの非クラウド環境の場合は、
これらのフィールドのいずれかで値を設定しない場合のデフォルト値は、
クラスターのデプロイ後に、
|
|
シークレットには以下のキーおよびデータが含まれる必要があります: *
設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの 使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。 |
|
|
|
|
|
設定されていない場合は、デフォルト値が使用されます。 注記
nodePlacement: nodeSelector: matchLabels: kubernetes.io/os: linux tolerations: - effect: NoSchedule operator: Exists
|
|
これが設定されていない場合、デフォルト値は
Ingress Controller の最小 TLS バージョンは 注記
設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが 重要
Ingress Operator は TLS |
|
|
|
|
|
|
|
デフォルトでは、ポリシーは
これらの調整は、クリアテキスト、edge-terminated、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。
要求ヘッダーの場合、これらの調整は
|
|
|
|
|
|
キャプチャーするすべての Cookie について、次のパラメーターが
以下に例を示します。 httpCaptureCookies: - matchType: Exact maxLength: 128 name: MYCOOKIE
|
|
httpCaptureHeaders: request: - maxLength: 256 name: Connection - maxLength: 128 name: User-Agent response: - maxLength: 256 name: Content-Type - maxLength: 256 name: Content-Length
|
|
|
|
|
|
これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを |
9.3.1. Ingress Controller の TLS セキュリティープロファイル
TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。
9.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 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。
9.3.1.2. Ingress Controller の TLS セキュリティープロファイルの設定
Ingress Controller の TLS セキュリティープロファイルを設定するには、IngressController
カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。
Old
TLS のセキュリティープロファイルを設定するサンプル IngressController
CR
apiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: old: {} type: Old ...
apiVersion: operator.openshift.io/v1
kind: IngressController
...
spec:
tlsSecurityProfile:
old: {}
type: Old
...
TLS セキュリティープロファイルは、Ingress Controller の TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。
設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile
配下の IngressController
カスタムリソース (CR) と Spec.Tls Security Profile
配下の設定された TLS セキュリティープロファイルで確認できます。Custom
TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。
HAProxy Ingress Controller イメージは、TLS 1.3
と Modern
プロファイルをサポートしています。
また、Ingress Operator は TLS 1.0
の Old
または Custom
プロファイルを 1.1
に変換します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-ingress-operator
プロジェクトのIngressController
CR を編集して、TLS セキュリティープロファイルを設定します。oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのサンプルIngressController
CRapiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: type: Custom custom: ciphers: - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11 ...
apiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: type: Custom
1 custom:
2 ciphers:
3 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11 ...
Copy to Clipboard Copied! - 変更を適用するためにファイルを保存します。
検証
IngressController
CR にプロファイルが設定されていることを確認します。oc describe IngressController default -n openshift-ingress-operator
$ oc describe IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! 出力例
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
Copy to Clipboard Copied!
9.3.1.3. 相互 TLS 認証の設定
spec.clientTLS
値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress Controller を設定できます。clientTLS
値は、クライアント証明書を検証するように Ingress Controller を設定します。この設定には、config map の参照である clientCA
値の設定が含まれます。config map には、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターのリストも設定できます。
clientCA
値が X509v3 証明書失効リスト (CRL) ディストリビューションポイントを指定している場合、Ingress Operator は、提供された各証明書で指定されている HTTP URI X509v3 CRL Distribution Point
に基づいて CRL config map をダウンロードおよび管理します。Ingress Controller は、mTLS/TLS ネゴシエーション中にこの config map を使用します。有効な証明書を提供しない要求は拒否されます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - PEM でエンコードされた CA 証明書バンドルがある。
CA バンドルが CRL ディストリビューションポイントを参照する場合は、エンドエンティティーまたはリーフ証明書もクライアント CA バンドルに含める必要があります。この証明書には、RFC 5280 で説明されているとおり、この証明書の
CRL Distribution Points
に HTTP URI が含まれている必要があります。以下に例を示します。Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1 Subject: SOME SIGNED CERT X509v3 CRL Distribution Points: Full Name: URI:http://crl.example.com/example.crl
Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1 Subject: SOME SIGNED CERT X509v3 CRL Distribution Points: Full Name: URI:http://crl.example.com/example.crl
Copy to Clipboard Copied!
手順
openshift-config
namespace で、CA バンドルから config map を作成します。oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \ -n openshift-config
$ oc create configmap \ router-ca-certs-default \ --from-file=ca-bundle.pem=client-ca.crt \
1 -n openshift-config
Copy to Clipboard Copied! - 1
- config map データキーは
ca-bundle.pem
で、data の値は PEM 形式の CA 証明書である必要があります。
openshift-ingress-operator
プロジェクトでIngressController
リソースを編集します。oc edit IngressController default -n openshift-ingress-operator
$ oc edit IngressController default -n openshift-ingress-operator
Copy to Clipboard Copied! spec.clientTLS
フィールドおよびサブフィールドを追加して相互 TLS を設定します。フィルタリングパターンを指定する
clientTLS
プロファイルのサンプルIngressController
CRapiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: clientTLS: clientCertificatePolicy: Required clientCA: name: router-ca-certs-default allowedSubjectPatterns: - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: clientTLS: clientCertificatePolicy: Required clientCA: name: router-ca-certs-default allowedSubjectPatterns: - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
Copy to Clipboard Copied! -
オプションで、次のコマンドを入力して、
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
9.4. デフォルト Ingress Controller の表示
Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。
すべての新規 OpenShift Container Platform インストールには、ingresscontroller
の名前付きのデフォルトがあります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller
が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。
手順
デフォルト Ingress Controller を表示します。
oc describe --namespace=openshift-ingress-operator ingresscontroller/default
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
Copy to Clipboard Copied!
9.5. Ingress Operator ステータスの表示
Ingress Operator のステータスを表示し、検査することができます。
手順
Ingress Operator ステータスを表示します。
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingress
Copy to Clipboard Copied!
9.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!
9.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!
9.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
ファイルの例apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: <custom_name> namespace: openshift-ingress-operator spec: defaultCertificate: name: <custom-ingress-custom-certs> replicas: 1 domain: <custom_domain>
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: <custom_name>
1 namespace: openshift-ingress-operator spec: defaultCertificate: name: <custom-ingress-custom-certs>
2 replicas: 1
3 domain: <custom_domain>
4 Copy to Clipboard Copied! 以下のコマンドを実行してオブジェクトを作成します。
oc create -f custom-ingress-controller.yaml
$ oc create -f custom-ingress-controller.yaml
Copy to Clipboard Copied!
9.9. Ingress Controller の設定
9.9.1. カスタムデフォルト証明書の設定
管理者として、Secret リソースを作成し、IngressController
カスタムリソース (CR) を編集して Ingress Controller がカスタム証明書を使用するように設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
証明書が以下の要件を満たしている必要があります。
- 証明書が Ingress ドメインに対して有効化されている必要があります。
-
証明書は拡張を使用して、
subjectAltName
拡張を使用して、*.apps.ocp4.example.com
などのワイルドカードドメインを指定します。
IngressController
CR がなければなりません。デフォルトの CR を使用できます。oc --namespace openshift-ingress-operator get ingresscontrollers
$ oc --namespace openshift-ingress-operator get ingresscontrollers
Copy to Clipboard Copied! 出力例
NAME AGE default 10m
NAME AGE default 10m
Copy to Clipboard Copied!
Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt
ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書をリスト表示します。
手順
以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt
および tls.key
ファイルにあることを前提とします。tls.crt
および tls.key
を実際のパス名に置き換えます。さらに、Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default
を別の名前に置き換えます。
このアクションにより、Ingress Controller はデプロイメントストラテジーを使用して再デプロイされます。
tls.crt
およびtls.key
ファイルを使用して、カスタム証明書を含む Secret リソースをopenshift-ingress
namespace に作成します。oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
Copy to Clipboard Copied! 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! 更新が正常に行われていることを確認します。
echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
$ echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
Copy to Clipboard Copied! ここでは、以下のようになります。
<domain>
- クラスターのベースドメイン名を指定します。
出力例
subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com notAfter=May 10 08:32:45 2022 GM
subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com notAfter=May 10 08:32:45 2022 GM
Copy to Clipboard Copied! ヒントまたは、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: defaultCertificate: name: custom-certs-default
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: defaultCertificate: name: custom-certs-default
Copy to Clipboard Copied! 証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。
IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress Controller のデプロイメントを更新します。
9.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! クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。
検証
元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。
echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
$ echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
Copy to Clipboard Copied! ここでは、以下のようになります。
<domain>
- クラスターのベースドメイン名を指定します。
出力例
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
Copy to Clipboard Copied!
9.9.3. Ingress Controller の自動スケーリング
Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に動的に対応するために自動でスケーリングできます。
以下の手順では、デフォルトの Ingress Controller をスケールアップする例を示します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。 Custom Metrics Autoscaler Operator と関連する KEDA Controller がインストールされている。
-
この Operator は、Web コンソールで OperatorHub を使用してインストールできます。Operator をインストールしたら、
KedaController
のインスタンスを作成できます。
-
この Operator は、Web コンソールで OperatorHub を使用してインストールできます。Operator をインストールしたら、
手順
以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。
oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
$ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
Copy to Clipboard Copied! 出力例
Name: thanos Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> Image pull secrets: thanos-dockercfg-kfvf2 Mountable secrets: thanos-dockercfg-kfvf2 Tokens: thanos-token-c422q Events: <none>
Name: thanos Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> Image pull secrets: thanos-dockercfg-kfvf2 Mountable secrets: thanos-dockercfg-kfvf2 Tokens: thanos-token-c422q Events: <none>
Copy to Clipboard Copied! オプション: 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。
重要ImageRegistry
機能を無効にした場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にした場合は、イメージプルシークレットがサービスアカウントごとに生成されません。この状況では、この手順を実行する必要があります。oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: thanos-token namespace: openshift-ingress-operator annotations: kubernetes.io/service-account.name: thanos type: kubernetes.io/service-account-token EOF
$ oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: thanos-token namespace: openshift-ingress-operator annotations: kubernetes.io/service-account.name: thanos type: kubernetes.io/service-account-token EOF
Copy to Clipboard Copied! サービスアカウントのトークンを使用して、
openshift-ingress-operator
namespace 内でTriggerAuthentication
オブジェクトを定義します。次のコマンドを実行して、シークレットを含む
secret
変数を定義します。secret=$(oc get secret -n openshift-ingress-operator | grep thanos-token | head -n 1 | awk '{ print $1 }')
$ secret=$(oc get secret -n openshift-ingress-operator | grep thanos-token | head -n 1 | awk '{ print $1 }')
Copy to Clipboard Copied! TriggerAuthentication
オブジェクトを作成し、secret
変数の値をTOKEN
パラメーターに渡します。oc process TOKEN="$secret" -f - <<EOF | oc apply -n openshift-ingress-operator -f - apiVersion: template.openshift.io/v1 kind: Template parameters: - name: TOKEN objects: - apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-prometheus spec: secretTargetRef: - parameter: bearerToken name: \${TOKEN} key: token - parameter: ca name: \${TOKEN} key: ca.crt EOF
$ oc process TOKEN="$secret" -f - <<EOF | oc apply -n openshift-ingress-operator -f - apiVersion: template.openshift.io/v1 kind: Template parameters: - name: TOKEN objects: - apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-prometheus spec: secretTargetRef: - parameter: bearerToken name: \${TOKEN} key: token - parameter: ca name: \${TOKEN} key: ca.crt EOF
Copy to Clipboard Copied!
Thanos からメトリクスを読み取るためのロールを作成して適用します。
Pod およびノードからメトリクスを読み取る新規ロール
thanos-metrics-reader.yaml
を作成します。thanos-metrics-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: thanos-metrics-reader namespace: openshift-ingress-operator rules: - apiGroups: - "" resources: - pods - nodes verbs: - get - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch - apiGroups: - "" resources: - namespaces verbs: - get
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: thanos-metrics-reader namespace: openshift-ingress-operator rules: - apiGroups: - "" resources: - pods - nodes verbs: - get - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch - apiGroups: - "" resources: - namespaces verbs: - get
Copy to Clipboard Copied! 以下のコマンドを実行して新規ロールを適用します。
oc apply -f thanos-metrics-reader.yaml
$ oc apply -f thanos-metrics-reader.yaml
Copy to Clipboard Copied!
以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。
oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
$ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
Copy to Clipboard Copied! oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
$ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos
Copy to Clipboard Copied! 注記引数
add-cluster-role-to-user
は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とするkube-metrics
namespace からのクエリーを使用します。デフォルトの Ingress Controller デプロイメントをターゲットにする新しい
ScaledObject
YAML ファイルingress-autoscaler.yaml
を作成します。ScaledObject
定義の例apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ingress-scaler namespace: openshift-ingress-operator spec: scaleTargetRef: apiVersion: operator.openshift.io/v1 kind: IngressController name: default envSourceContainerName: ingress-operator minReplicaCount: 1 maxReplicaCount: 20 cooldownPeriod: 1 pollingInterval: 1 triggers: - type: prometheus metricType: AverageValue metadata: serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 namespace: openshift-ingress-operator metricName: 'kube-node-role' threshold: '1' query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' authModes: "bearer" authenticationRef: name: keda-trigger-auth-prometheus
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ingress-scaler namespace: openshift-ingress-operator spec: scaleTargetRef:
1 apiVersion: operator.openshift.io/v1 kind: IngressController name: default envSourceContainerName: ingress-operator minReplicaCount: 1 maxReplicaCount: 20
2 cooldownPeriod: 1 pollingInterval: 1 triggers: - type: prometheus metricType: AverageValue metadata: serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
3 namespace: openshift-ingress-operator
4 metricName: 'kube-node-role' threshold: '1' query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})'
5 authModes: "bearer" authenticationRef: name: keda-trigger-auth-prometheus
Copy to Clipboard Copied! 重要namespace 間クエリーを使用している場合は、
serverAddress
フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。以下のコマンドを実行してカスタムリソース定義を適用します。
oc apply -f ingress-autoscaler.yaml
$ oc apply -f ingress-autoscaler.yaml
Copy to Clipboard Copied!
検証
以下のコマンドを実行して、デフォルトの 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! 出力例
replicas: 3
replicas: 3
Copy to Clipboard Copied! openshift-ingress
プロジェクトで Pod を取得します。oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingress
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE router-default-7b5df44ff-l9pmm 2/2 Running 0 17h router-default-7b5df44ff-s5sl5 2/2 Running 0 3d22h router-default-7b5df44ff-wwsth 2/2 Running 0 66s
NAME READY STATUS RESTARTS AGE router-default-7b5df44ff-l9pmm 2/2 Running 0 17h router-default-7b5df44ff-s5sl5 2/2 Running 0 3d22h router-default-7b5df44ff-wwsth 2/2 Running 0 66s
Copy to Clipboard Copied!
9.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! 出力例
2
2
Copy to Clipboard Copied! oc patch
コマンドを使用して、デフォルトのIngressController
を必要なレプリカ数にスケーリングします。以下の例では、デフォルトのIngressController
を 3 つのレプリカにスケーリングしています。oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
Copy to Clipboard Copied! 出力例
ingresscontroller.operator.openshift.io/default patched
ingresscontroller.operator.openshift.io/default patched
Copy to Clipboard Copied! デフォルトの
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! 出力例
3
3
Copy to Clipboard Copied! ヒントまたは、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 3
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 3
1 Copy to Clipboard Copied! - 1
- 異なる数のレプリカが必要な場合は
replicas
値を変更します。
9.9.5. Ingress アクセスロギングの設定
アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。
コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress Controller で問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。
アクセスログが OpenShift Logging スタックの容量を超える可能性がある高トラフィックのクラスターや、ログソリューションを既存の Syslog ログインフラストラクチャーと統合する必要がある環境では、Syslog が必要です。Syslog のユースケースは重複する可能性があります。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
サイドカーへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container
spec.logging.access.destination.type
を指定する必要があります。以下の例は、コンテナーContainer
の宛先に対してログ記録する Ingress Controller 定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container
Copy to Clipboard Copied! Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に
logs
という名前のコンテナーを作成します。oc -n openshift-ingress logs deployment.apps/router-default -c logs
$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
Copy to Clipboard Copied! 出力例
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!
Syslog エンドポイントへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type
にSyslog
を指定する必要があります。宛先タイプがSyslog
の場合、spec.logging.access.destination.syslog.endpoint
を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility
を使用してファシリティーを指定できます。以下の例は、Syslog
宛先に対してログを記録する Ingress Controller の定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514
Copy to Clipboard Copied! 注記syslog
宛先ポートは UDP である必要があります。
特定のログ形式で Ingress アクセスロギングを設定します。
spec.logging.access.httpLogFormat
を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 のsyslog
エンドポイントに対してログを記録する Ingress Controller の定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514 httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514 httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
Copy to Clipboard Copied!
Ingress アクセスロギングを無効にします。
Ingress アクセスロギングを無効にするには、
spec.logging
またはspec.logging.access
を空のままにします。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: null
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: null
Copy to Clipboard Copied!
サイドカーの使用時に Ingress Controller が HAProxy ログの長さを変更できるようにします。
spec.logging.access.destination.type: Syslog
を使用している場合は、spec.logging.access.destination.syslog.maxLength
を使用します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 maxLength: 4096 port: 10514
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 maxLength: 4096 port: 10514
Copy to Clipboard Copied! spec.logging.access.destination.type: Container
を使用している場合は、spec.logging.access.destination.container.maxLength
を使用します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container container: maxLength: 8192
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container container: maxLength: 8192
Copy to Clipboard Copied!
9.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! 注記大量のリソースを実行できるノードがある場合、
spec.nodePlacement.nodeSelector
を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount
を随時高い値に設定します。
9.9.7. 内部ロードバランサーを使用するための Ingress Controller の設定
クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController
の scope
を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更します。
図9.1 LoadBalancer の図

前述の図では、OpenShift Container Platform Ingress LoadBalancerService エンドポイントの公開戦略に関する以下のような概念を示しています。
- 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
- ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
- 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細は、Kubernetes サービスドキュメント を参照してください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の例のように、
<name>-ingress-controller.yaml
という名前のファイルにIngressController
カスタムリソース (CR) を作成します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: <name> spec: domain: <domain> endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: <name>
1 spec: domain: <domain>
2 endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal
3 Copy to Clipboard Copied! 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。
oc create -f <name>-ingress-controller.yaml
$ oc create -f <name>-ingress-controller.yaml
1 Copy to Clipboard Copied! - 1
<name>
をIngressController
オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。
oc --all-namespaces=true get ingresscontrollers
$ oc --all-namespaces=true get ingresscontrollers
Copy to Clipboard Copied!
9.9.8. GCP での Ingress Controller のグローバルアクセスの設定
内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。
詳細情報は、GCP ドキュメントの グローバルアクセス を参照してください。
前提条件
- OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
- 内部ロードバランサーを使用するように Ingress Controller を設定している。
-
OpenShift CLI (
oc
) がインストールされている。
手順
グローバルアクセスを許可するように Ingress Controller リソースを設定します。
注記Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。
Ingress Controller リソースを設定します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! YAML ファイルを編集します。
サンプル
clientAccess
設定をGlobal
に設定します。spec: endpointPublishingStrategy: loadBalancer: providerParameters: gcp: clientAccess: Global type: GCP scope: Internal type: LoadBalancerService
spec: endpointPublishingStrategy: loadBalancer: providerParameters: gcp: clientAccess: Global
1 type: GCP scope: Internal type: LoadBalancerService
Copy to Clipboard Copied! - 1
gcp.clientAccess
をGlobal
に設定します。
- 変更を適用するためにファイルを保存します。
以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。
oc -n openshift-ingress edit svc/router-default -o yaml
$ oc -n openshift-ingress edit svc/router-default -o yaml
Copy to Clipboard Copied! この出力では、グローバルアクセスがアノテーション
networking.gke.io/internal-load-balancer-allow-global-access
で GCP について有効にされていることを示しています。
9.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! 注記単一ルートの
healthCheckInterval
をオーバーライドするには、ルートアノテーションrouter.openshift.io/haproxy.health.check.interval
を使用します
9.9.10. クラスターを内部に配置するためのデフォルト Ingress Controller の設定
削除や再作成を実行して、クラスターを内部に配置するように default
Ingress Controller を設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。
IngressController
の scope
を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
default
Ingress Controller を設定します。oc replace --force --wait --filename - <<EOF apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: default spec: endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal EOF
$ oc replace --force --wait --filename - <<EOF apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: default spec: endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal EOF
Copy to Clipboard Copied!
9.9.11. ルートの受付ポリシーの設定
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。
複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。
前提条件
- クラスター管理者の権限。
手順
以下のコマンドを使用して、
ingresscontroller
リソース変数の.spec.routeAdmission
フィールドを編集します。oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
Copy to Clipboard Copied! イメージコントローラー設定例
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
Copy to Clipboard Copied! ヒントまたは、以下の YAML を適用してルートの受付ポリシーを設定できます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed
Copy to Clipboard Copied!
9.9.12. ワイルドカードルートの使用
HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy
を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES
環境変数を設定します。
Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None
(既存の IngressController
リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressController
リソースを編集します。oc edit IngressController
$ oc edit IngressController
Copy to Clipboard Copied! spec
の下で、wildcardPolicy
フィールドをWildcardsDisallowed
またはWildcardsAllowed
に設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
Copy to Clipboard Copied!
9.9.13. HTTP ヘッダーの設定
OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。
IngressController
または Route
CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions
の代わりに spec.httpHeaders.forwardedHeaderPolicy
フィールドを使用します。
9.9.13.1. 優先順位
同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。
- HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
- HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。
たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY
を設定します。
IngressController
仕様の例
apiVersion: operator.openshift.io/v1 kind: IngressController # ... spec: httpHeaders: actions: response: - name: X-Frame-Options action: type: Set set: value: DENY
apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
httpHeaders:
actions:
response:
- name: X-Frame-Options
action:
type: Set
set:
value: DENY
ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN
を設定します。
Route
仕様の例
apiVersion: route.openshift.io/v1 kind: Route # ... spec: httpHeaders: actions: response: - name: X-Frame-Options action: type: Set set: value: SAMEORIGIN
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
httpHeaders:
actions:
response:
- name: X-Frame-Options
action:
type: Set
set:
value: SAMEORIGIN
IngressController
仕様と Route
仕様の両方で X-Frame-Options ヘッダーを設定している場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。
この優先順位付けは、haproxy.config
ファイルが次のロジックを使用するために発生します。このロジックでは、Ingress Controller がフロントエンドとみなされ、個々のルートがバックエンドとみなされます。フロントエンド設定に適用されるヘッダー値 DENY
は、バックエンドで設定されている値 SAMEORIGIN
で同じヘッダーをオーバーライドします。
frontend public http-response set-header X-Frame-Options 'DENY' frontend fe_sni http-response set-header X-Frame-Options 'DENY' frontend fe_no_sni http-response set-header X-Frame-Options 'DENY' backend be_secure:openshift-monitoring:alertmanager-main http-response set-header X-Frame-Options 'SAMEORIGIN'
frontend public
http-response set-header X-Frame-Options 'DENY'
frontend fe_sni
http-response set-header X-Frame-Options 'DENY'
frontend fe_no_sni
http-response set-header X-Frame-Options 'DENY'
backend be_secure:openshift-monitoring:alertmanager-main
http-response set-header X-Frame-Options 'SAMEORIGIN'
さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。
9.9.13.2. 特殊なケースのヘッダー
次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。
ヘッダー名 | IngressController 仕様を使用して設定可能かどうか | Route 仕様を使用して設定可能かどうか | 不許可の理由 | 別の方法で設定可能かどうか |
---|---|---|---|---|
| いいえ | いいえ |
| いいえ |
| いいえ | はい |
| いいえ |
| いいえ | いいえ |
|
はい: |
| いいえ | いいえ | HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。 | はい:
|
9.9.14. Ingress Controller での HTTP リクエストおよびレスポンスヘッダーの設定または削除
コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。
たとえば、相互 TLS を使用するようにクラスター上で実行されているアプリケーションを移行する場合があります。このような場合、お使いのアプリケーションで X-Forwarded-Client-Cert リクエストヘッダーをチェックする必要がありますが、OpenShift Container Platform のデフォルトの Ingress Controller は X-SSL-Client-Der リクエストヘッダーを提供します。
次の手順では、Ingress Controller を変更して X-Forwarded-Client-Cert リクエストヘッダーを設定し、X-SSL-Client-Der リクエストヘッダーを削除します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
手順
Ingress Controller リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: actions: request: - name: X-Forwarded-Client-Cert action: type: Set set: value: "%{+Q}[ssl_c_der,base64]" - name: X-SSL-Client-Der action: type: Delete
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: actions:
1 request:
2 - name: X-Forwarded-Client-Cert
3 action: type: Set
4 set: value: "%{+Q}[ssl_c_der,base64]"
5 - name: X-SSL-Client-Der action: type: Delete
Copy to Clipboard Copied! - 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
コンバーターを使用できます。- 変更を適用するためにファイルを保存します。
9.9.15. X-Forwarded ヘッダーの使用
Forwarded
および X-Forwarded-For
を含む HTTP ヘッダーの処理方法に関するポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders
フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS
環境変数を設定します。
手順
Ingress Controller 用に
HTTPHeaders
フィールドを設定します。以下のコマンドを使用して
IngressController
リソースを編集します。oc edit IngressController
$ oc edit IngressController
Copy to Clipboard Copied! spec
の下で、HTTPHeaders
ポリシーフィールドをAppend
、Replace
、IfNone
、またはNever
に設定します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: forwardedHeaderPolicy: Append
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: forwardedHeaderPolicy: Append
Copy to Clipboard Copied!
使用例
クラスター管理者として、以下を実行できます。
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
アノテーションをルートごとに設定できます。
9.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 プロトコルへのアップグレードに失敗します。
9.9.16.1. HTTP/2 の有効化
特定の Ingress Controller で HTTP/2 を有効化するか、クラスター全体で HTTP/2 を有効化できます。
手順
特定の Ingress Controller で HTTP/2 を有効化するには、
oc annotate
コマンドを入力します。oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
1 Copy to Clipboard Copied! - 1
<ingresscontroller_name>
は、HTTP/2 を有効化する Ingress Controller の名前に置き換えます。
クラスター全体で HTTP/2 を有効にするには、
oc annotate
コマンドを入力します。oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
Copy to Clipboard Copied!
または、次の YAML コードを適用して HTTP/2 を有効化できます。
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster annotations: ingress.operator.openshift.io/default-enable-http2: "true"
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
annotations:
ingress.operator.openshift.io/default-enable-http2: "true"
9.9.16.2. HTTP/2 の無効化
特定の Ingress Controller で HTTP/2 を無効化するか、またはクラスター全体で HTTP/2 を無効化できます。
手順
特定の Ingress Controller で HTTP/2 を無効化するには、
oc annotate
コマンドを入力します。oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false
$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false
1 Copy to Clipboard Copied! - 1
<ingresscontroller_name>
は、HTTP/2 を無効化する Ingress Controller の名前に置き換えます。
クラスター全体で HTTP/2 を無効化するには、
oc annotate
コマンドを入力します。oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=false
Copy to Clipboard Copied!
または、次の YAML コードを適用して HTTP/2 を無効化できます。
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster annotations: ingress.operator.openshift.io/default-enable-http2: "false"
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
name: cluster
annotations:
ingress.operator.openshift.io/default-enable-http2: "false"
9.9.17. Ingress Controller の PROXY プロトコルの設定
クラスター管理者は、Ingress Controller が HostNetwork
、NodePortService
、または Private
エンドポイントの公開ストラテジータイプのいずれかを使用する際に PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。
Keepalived Ingress 仮想 IP (VIP) を使用するクラウド以外のプラットフォーム上の installer-provisioned クラスターを備えたデフォルトの Ingress Controller は、PROXY プロトコルをサポートしていません。
PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられる送信元 IP アドレスのみが含まれます。
パススルールート設定の場合、OpenShift Container Platform クラスター内のサーバーは、元のクライアント送信元 IP アドレスを監視できません。元のクライアント送信元 IP アドレスを知る必要がある場合は、Ingress Controller の Ingress アクセスロギングを設定して、クライアント送信元 IP アドレスを表示できるようにします。
再暗号化およびエッジルートの場合、OpenShift Container Platform ルーターは Forwarded
ヘッダーと X-Forwarded-For
ヘッダーを設定し、アプリケーションワークロードがクライアントの送信元 IP アドレスをチェックできるようにします。
Ingress アクセスロギングの詳細は、「Ingress アクセスロギングの設定」を参照してください。
LoadBalancerService
エンドポイント公開ストラテジータイプを使用する場合、Ingress Controller の PROXY プロトコルの設定はサポートされません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。
PROXY プロトコルまたは TCP のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。
この機能は、クラウドデプロイメントではサポートされていません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。
PROXY プロトコルまたは Transmission Control Protocol (TCP) のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。
前提条件
- Ingress Controller を作成している。
手順
CLI で次のコマンドを入力して、Ingress Controller リソースを編集します。
oc -n openshift-ingress-operator edit ingresscontroller/default
$ oc -n openshift-ingress-operator edit ingresscontroller/default
Copy to Clipboard Copied! PROXY 設定を設定します。
Ingress Controller が
HostNetwork
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.hostNetwork.protocol
サブフィールドをPROXY
に設定します。PROXY
へのhostNetwork
の設定例# ... spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork # ...
# ... spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork # ...
Copy to Clipboard Copied! Ingress Controller が
NodePortService
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol
サブフィールドをPROXY
に設定します。PROXY
へのサンプルnodePort
設定# ... spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService # ...
# ... spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService # ...
Copy to Clipboard Copied! Ingress Controller が
Private
エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.private.protocol
サブフィールドをPROXY
に設定します。PROXY
へのprivate
設定のサンプル# ... spec: endpointPublishingStrategy: private: protocol: PROXY type: Private # ...
# ... spec: endpointPublishingStrategy: private: protocol: PROXY type: Private # ...
Copy to Clipboard Copied!
9.9.18. appsDomain オプションを使用した代替クラスタードメインの指定
クラスター管理者は、appsDomain
フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain
フィールドは、domain
フィールドで指定されているデフォルトの代わりに使用する OpenShift Container Platform のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。
たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
-
oc
コマンドラインインターフェイスがインストールされている。
手順
ユーザーが作成するルートに代替のデフォルトドメインを指定して
appsDomain
フィールドを設定します。Ingress
cluster
リソースを編集します。oc edit ingresses.config/cluster -o yaml
$ oc edit ingresses.config/cluster -o yaml
Copy to Clipboard Copied! YAML ファイルを編集します。
test.example.com
へのappsDomain
の設定例apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com appsDomain: <test.example.com>
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com
1 appsDomain: <test.example.com>
2 Copy to Clipboard Copied!
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、
appsDomain
フィールドで指定したドメイン名が含まれていることを確認します。注記ルートを公開する前に
openshift-apiserver
がローリング更新を終了するのを待機します。ルートを公開します。
oc expose service hello-openshift
$ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed
Copy to Clipboard Copied! 出力例:
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 None
Copy to Clipboard Copied!
9.9.19. HTTP ヘッダーケースの変換
HAProxy では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com
は host: xyz.com
に変更されます。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments
API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。
OpenShift Container Platform には HAProxy 2.6 が含まれています。このバージョンの 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! アノテーションをアプリケーションに適用できるように、
Route
リソースの YAML ファイルを作成します。my-application
という名前のルートの例apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/h1-adjust-case: true name: <application_name> namespace: <application_name> # ...
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/h1-adjust-case: true
1 name: <application_name> namespace: <application_name> # ...
Copy to Clipboard Copied! - 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 のサンプル
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: headerNameCaseAdjustments: - Host
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: headerNameCaseAdjustments: - Host
Copy to Clipboard Copied! 次のルートの例では、
haproxy.router.openshift.io/h1-adjust-case
アノテーションを使用して HTTP レスポンスヘッダー名の大文字と小文字の調整を有効にします。ルート YAML のサンプル
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/h1-adjust-case: true name: my-application namespace: my-application spec: to: kind: Service name: my-application
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/h1-adjust-case: true
1 name: my-application namespace: my-application spec: to: kind: Service name: my-application
Copy to Clipboard Copied! - 1
haproxy.router.openshift.io/h1-adjust-case
を true に設定します。
9.9.20. ルーター圧縮の使用
特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes
変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または "X-" で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341 を参照してください。
圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。
すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。
手順
Ingress Controller の
httpCompression
フィールドを設定します。以下のコマンドを使用して
IngressController
リソースを編集します。oc edit -n openshift-ingress-operator ingresscontrollers/default
$ oc edit -n openshift-ingress-operator ingresscontrollers/default
Copy to Clipboard Copied! spec
で、httpCompression
ポリシーフィールドをmimeTypes
に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpCompression: mimeTypes: - "text/html" - "text/css; charset=utf-8" - "application/json" ...
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpCompression: mimeTypes: - "text/html" - "text/css; charset=utf-8" - "application/json" ...
Copy to Clipboard Copied!
9.9.21. ルーターメトリクスの公開
デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。
前提条件
- ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。
手順
次のコマンドを実行して、ルーター Pod 名を取得します。
oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingress
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h
NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h
Copy to Clipboard Copied! ルーター Pod が
/var/lib/haproxy/conf/metrics-auth/statsUsername
および/var/lib/haproxy/conf/metrics-auth/statsPassword
ファイルに保存しているルーターのユーザー名およびパスワードを取得します。次のコマンドを実行して、ユーザー名を取得します。
oc rsh <router_pod_name> cat metrics-auth/statsUsername
$ oc rsh <router_pod_name> cat metrics-auth/statsUsername
Copy to Clipboard Copied! 次のコマンドを実行して、パスワードを取得します。
oc rsh <router_pod_name> cat metrics-auth/statsPassword
$ oc rsh <router_pod_name> cat metrics-auth/statsPassword
Copy to Clipboard Copied!
次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。
oc describe pod <router_pod>
$ oc describe pod <router_pod>
Copy to Clipboard Copied! つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
Copy to Clipboard Copied! 次のコマンドを実行して、安全にメトリクスにアクセスします。
curl -u user:password https://<router_IP>:<stats_port>/metrics -k
$ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
Copy to Clipboard Copied! 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
Copy to Clipboard Copied! 例9.1 出力例
... # HELP haproxy_backend_connections_total Total number of connections. # TYPE haproxy_backend_connections_total gauge haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0 ... # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value. # TYPE haproxy_exporter_server_threshold gauge haproxy_exporter_server_threshold{type="current"} 11 haproxy_exporter_server_threshold{type="limit"} 500 ... # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes. # TYPE haproxy_frontend_bytes_in_total gauge haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0 haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0 haproxy_frontend_bytes_in_total{frontend="public"} 119070 ... # HELP haproxy_server_bytes_in_total Current total of incoming bytes. # TYPE haproxy_server_bytes_in_total gauge haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0 haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0 ...
... # HELP haproxy_backend_connections_total Total number of connections. # TYPE haproxy_backend_connections_total gauge haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0 ... # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value. # TYPE haproxy_exporter_server_threshold gauge haproxy_exporter_server_threshold{type="current"} 11 haproxy_exporter_server_threshold{type="limit"} 500 ... # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes. # TYPE haproxy_frontend_bytes_in_total gauge haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0 haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0 haproxy_frontend_bytes_in_total{frontend="public"} 119070 ... # HELP haproxy_server_bytes_in_total Current total of incoming bytes. # TYPE haproxy_server_bytes_in_total gauge haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0 haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0 ...
Copy to Clipboard Copied! ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。
http://<user>:<password>@<router_IP>:<stats_port>
http://<user>:<password>@<router_IP>:<stats_port>
Copy to Clipboard Copied! オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。
http://<user>:<password>@<router_ip>:1936/metrics;csv
http://<user>:<password>@<router_ip>:1936/metrics;csv
Copy to Clipboard Copied!
9.9.22. HAProxy エラーコードの応答ページのカスタマイズ
クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。
カスタムエラーコードの応答ページは config map に指定し、Ingress Controller にパッチを適用されます。config map キーには、error-page-503.http
と error-page-404.http
の 2 つの利用可能なファイル名があります。
カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。
デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTP エラーコード応答をカスタマイズするための config map が提供されておらず、カスタム HTTP エラーコード応答ページを使用している場合、ルーターはデフォルトの 404 または 503 エラーコード応答ページを提供します。
OpenShift Container Platform のデフォルトの 503 エラーコードページをカスタマイズのテンプレートとして使用する場合、ファイル内のヘッダーで CRLF 改行コードを使用できるエディターが必要になります。
手順
openshift-config
にmy-custom-error-code-pages
という名前の config map を作成します。oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.http
$ oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.http
Copy to Clipboard Copied! 重要カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。
Ingress Controller にパッチを適用し、名前を指定して
my-custom-error-code-pages
config map を参照します。oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
Copy to Clipboard Copied! Ingress Operator は、
openshift-config
namespace からopenshift-ingress
namespace にmy-custom-error-code-pages
config map をコピーします。Operator は、openshift-ingress
namespace のパターン<your_ingresscontroller_name>-errorpages
に従って config map に名前を付けます。コピーを表示します。
oc get cm default-errorpages -n openshift-ingress
$ oc get cm default-errorpages -n openshift-ingress
Copy to Clipboard Copied! 出力例
NAME DATA AGE default-errorpages 2 25s
NAME DATA AGE default-errorpages 2 25s
1 Copy to Clipboard Copied! - 1
default
の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例はdefault-errorpages
です。
カスタムエラー応答ページを含む config map がルーターボリュームにマウントされることを確認します。config map キーは、カスタム HTTP エラーコード応答を持つファイル名です。
503 カスタム HTTP カスタムエラーコード応答の場合:
oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
Copy to Clipboard Copied! 404 カスタム HTTP カスタムエラーコード応答の場合:
oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
$ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
Copy to Clipboard Copied!
検証
カスタムエラーコード HTTP 応答を確認します。
テストプロジェクトおよびアプリケーションを作成します。
oc new-project test-ingress
$ oc new-project test-ingress
Copy to Clipboard Copied! oc new-app django-psql-example
$ oc new-app django-psql-example
Copy to Clipboard Copied! 503 カスタム http エラーコード応答の場合:
- アプリケーションのすべての Pod を停止します。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
curl -vk <route_hostname>
$ curl -vk <route_hostname>
Copy to Clipboard Copied!
404 カスタム http エラーコード応答の場合:
- 存在しないルートまたは正しくないルートにアクセスします。
以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
curl -vk <route_hostname>
$ curl -vk <route_hostname>
Copy to Clipboard Copied!
errorfile
属性がhaproxy.config
ファイルで適切にあるかどうかを確認します。oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
$ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile
Copy to Clipboard Copied!
9.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! 警告spec.tuningOptions.maxConnections
の値を現在のオペレーティングシステムの制限よりも大きく設定すると、HAProxy プロセスは開始しません。このパラメーターの詳細は、「Ingress Controller 設定パラメーター」セクションの表を参照してください。
第10章 OpenShift Container Platform の Ingress Node Firewall Operator
Ingress Node Firewall Operator は、OpenShift Container Platform でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。
10.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 を実行する必要があります。
Ingress Node Firewall Operator は、デフォルトの OpenShift インストールを備えた Amazon Web Services (AWS) または Red Hat OpenShift Service on AWS (ROSA) ではサポートされていません。Red Hat OpenShift Service on AWS のサポートと Ingress の詳細は、Red Hat OpenShift Service on AWS の Ingress Operator を参照してください。
10.2. Ingress Node Firewall Operator のインストール
クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。
10.2.1. CLI を使用した Ingress Node Firewall Operator のインストール
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者権限を持つアカウントを持っています。
手順
openshift-ingress-node-firewall
namespace を作成するには、次のコマンドを入力します。cat << EOF| oc create -f - apiVersion: v1 kind: Namespace metadata: labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/enforce-version: v1.24 name: openshift-ingress-node-firewall EOF
$ cat << EOF| oc create -f - apiVersion: v1 kind: Namespace metadata: labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/enforce-version: v1.24 name: openshift-ingress-node-firewall EOF
Copy to Clipboard Copied! OperatorGroup
CR を作成するには、以下のコマンドを実行します。cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ingress-node-firewall-operators namespace: openshift-ingress-node-firewall EOF
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ingress-node-firewall-operators namespace: openshift-ingress-node-firewall EOF
Copy to Clipboard Copied! Ingress Node Firewall Operator にサブスクライブします。
Ingress Node Firewall Operator の
Subscription
CR を作成するには、次のコマンドを入力します。cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ingress-node-firewall-sub namespace: openshift-ingress-node-firewall spec: name: ingress-node-firewall channel: stable source: redhat-operators sourceNamespace: openshift-marketplace EOF
$ cat << EOF| oc create -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ingress-node-firewall-sub namespace: openshift-ingress-node-firewall spec: name: ingress-node-firewall channel: stable source: redhat-operators sourceNamespace: openshift-marketplace EOF
Copy to Clipboard Copied!
Operator がインストールされていることを確認するには、以下のコマンドを入力します。
oc get ip -n openshift-ingress-node-firewall
$ oc get ip -n openshift-ingress-node-firewall
Copy to Clipboard Copied! 出力例
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.15.0-202211122336 Automatic true
NAME CSV APPROVAL APPROVED install-5cvnz ingress-node-firewall.4.15.0-202211122336 Automatic true
Copy to Clipboard Copied! Operator のバージョンを確認するには、次のコマンドを入力します。
oc get csv -n openshift-ingress-node-firewall
$ oc get csv -n openshift-ingress-node-firewall
Copy to Clipboard Copied! 出力例
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.15.0-202211122336 Ingress Node Firewall Operator 4.15.0-202211122336 ingress-node-firewall.4.15.0-202211102047 Succeeded
NAME DISPLAY VERSION REPLACES PHASE ingress-node-firewall.4.15.0-202211122336 Ingress Node Firewall Operator 4.15.0-202211122336 ingress-node-firewall.4.15.0-202211102047 Succeeded
Copy to Clipboard Copied!
10.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール
クラスター管理者は、Web コンソールを使用して Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者権限を持つアカウントを持っています。
手順
Ingress Node Firewall Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
- Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
- Install をクリックします。
Ingress Node Firewall Operator が正常にインストールされていることを確認します。
- Operators → Installed Operators ページに移動します。
Ingress Node Firewall Operator が openshift-ingress-node-firewall プロジェクトにリストされ、Status が InstallSucceeded であることを確認します。
注記インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
Operator の Status が InstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。
- Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
-
Workloads → Pods ページに移動し、
openshift-ingress-node-firewall
プロジェクトの Pod のログを確認します。 YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション
workload.openshift.io/allowed=management
を Operator namespace に追加できます。oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
$ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
Copy to Clipboard Copied! 注記単一ノードの OpenShift クラスターの場合、
openshift-ingress-node-firewall
namespace にはworkload.openshift.io/allowed=management
アノテーションが必要です。
10.3. Ingress Node Firewall Operator のデプロイ
前提条件
- Ingress Node Firewall Operator がインストールされます。
手順
Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig
カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall
CRD をノードにデプロイできます。
-
ingressnodefirewallconfig
という名前のopenshift-ingress-node-firewall
namespace 内にIngressNodeFirewallConfig
を作成します。 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。
oc apply -f rule.yaml
$ oc apply -f rule.yaml
Copy to Clipboard Copied!
10.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 ノードファイアウォール設定オブジェクトの例
apiVersion: ingressnodefirewall.openshift.io/v1alpha1 kind: IngressNodeFirewallConfig metadata: name: ingressnodefirewallconfig namespace: openshift-ingress-node-firewall spec: nodeSelector: node-role.kubernetes.io/worker: ""
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
name: ingressnodefirewallconfig
namespace: openshift-ingress-node-firewall
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
Operator は CR を使用し、nodeSelector
に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。
10.3.2. Ingress ノードファイアウォールルールオブジェクト
Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。
フィールド | 型 | 説明 |
---|---|---|
|
| CR オブジェクトの名前。 |
|
|
このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、 |
|
|
|
|
|
|
Ingress オブジェクトの設定
ingress
オブジェクトの値は、次の表で定義されています。
フィールド | 型 | 説明 |
---|---|---|
|
| CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。 注記
異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の |
|
|
Ingress ファイアウォール
注記 ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーや SSH などの重要なクラスターサービスをブロックすることを防ぎます。 |
ingress ノードファイアウォールルールオブジェクトの例
次の例では、完全な Ingress ノードファイアウォール設定が指定されています。
Ingress ノードファイアウォールの設定例
apiVersion: ingressnodefirewall.openshift.io/v1alpha1 kind: IngressNodeFirewall metadata: name: ingressnodefirewall spec: interfaces: - eth0 nodeSelector: matchLabels: <ingress_firewall_label_name>: <label_value> ingress: - sourceCIDRs: - 172.16.0.0/12 rules: - order: 10 protocolConfig: protocol: ICMP icmp: icmpType: 8 #ICMP Echo request action: Deny - order: 20 protocolConfig: protocol: TCP tcp: ports: "8000-9000" action: Deny - sourceCIDRs: - fc00:f853:ccd:e793::0/64 rules: - order: 10 protocolConfig: protocol: ICMPv6 icmpv6: icmpType: 128 #ICMPV6 Echo request action: Deny
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
name: ingressnodefirewall
spec:
interfaces:
- eth0
nodeSelector:
matchLabels:
<ingress_firewall_label_name>: <label_value>
ingress:
- sourceCIDRs:
- 172.16.0.0/12
rules:
- order: 10
protocolConfig:
protocol: ICMP
icmp:
icmpType: 8 #ICMP Echo request
action: Deny
- order: 20
protocolConfig:
protocol: TCP
tcp:
ports: "8000-9000"
action: Deny
- sourceCIDRs:
- fc00:f853:ccd:e793::0/64
rules:
- order: 10
protocolConfig:
protocol: ICMPv6
icmpv6:
icmpType: 128 #ICMPV6 Echo request
action: Deny
- 1
- <label_name> と <label_value> はノード上に存在する必要があり、
ingressfirewallconfig
CR を実行するノードに適用されるnodeselector
ラベルと値に一致する必要があります。<label_value> は、true
またはfalse
です。nodeSelector
ラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfig
CR の使用に異なるルールを適用できます。
ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例
ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。
次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。
次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。
ゼロトラストの Ingress ノードファイアウォールルールの例
apiVersion: ingressnodefirewall.openshift.io/v1alpha1 kind: IngressNodeFirewall metadata: name: ingressnodefirewall-zero-trust spec: interfaces: - eth1 nodeSelector: matchLabels: <ingress_firewall_label_name>: <label_value> ingress: - sourceCIDRs: - 0.0.0.0/0 rules: - order: 10 protocolConfig: protocol: TCP tcp: ports: 22 action: Allow - order: 20 action: Deny
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
name: ingressnodefirewall-zero-trust
spec:
interfaces:
- eth1
nodeSelector:
matchLabels:
<ingress_firewall_label_name>: <label_value>
ingress:
- sourceCIDRs:
- 0.0.0.0/0
rules:
- order: 10
protocolConfig:
protocol: TCP
tcp:
ports: 22
action: Allow
- order: 20
action: Deny
10.4. Ingress Node Firewall Operator ルールの表示
手順
次のコマンドを実行して、現在のルールをすべて表示します。
oc get ingressnodefirewall
$ oc get ingressnodefirewall
Copy to Clipboard Copied! 返された
<resource>
名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。oc get <resource> <name> -o yaml
$ oc get <resource> <name> -o yaml
Copy to Clipboard Copied!
10.5. Ingress Node Firewall Operator のトラブルシューティング
次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。
oc get crds | grep ingressnodefirewall
$ oc get crds | grep ingressnodefirewall
Copy to Clipboard Copied! 出力例
NAME READY UP-TO-DATE AVAILABLE AGE ingressnodefirewallconfigs.ingressnodefirewall.openshift.io 2022-08-25T10:03:01Z ingressnodefirewallnodestates.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z ingressnodefirewalls.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z
NAME READY UP-TO-DATE AVAILABLE AGE ingressnodefirewallconfigs.ingressnodefirewall.openshift.io 2022-08-25T10:03:01Z ingressnodefirewallnodestates.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z ingressnodefirewalls.ingressnodefirewall.openshift.io 2022-08-25T10:03:00Z
Copy to Clipboard Copied! 次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。
oc get pods -n openshift-ingress-node-firewall
$ oc get pods -n openshift-ingress-node-firewall
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE ingress-node-firewall-controller-manager 2/2 Running 0 5d21h ingress-node-firewall-daemon-pqx56 3/3 Running 0 5d21h
NAME READY STATUS RESTARTS AGE ingress-node-firewall-controller-manager 2/2 Running 0 5d21h ingress-node-firewall-daemon-pqx56 3/3 Running 0 5d21h
Copy to Clipboard Copied! 次のフィールドは、Operator のステータスに関する情報を提供します:
READY
、STATUS
、AGE
、およびRESTARTS
。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUS
フィールドはRunning
になります。次のコマンドを実行して、すべての Ingress ファイアウォールノード Pod のログを収集します。
oc adm must-gather – gather_ingress_node_firewall
$ oc adm must-gather – gather_ingress_node_firewall
Copy to Clipboard Copied! ログは、
/sos_commands/ebpf
にある eBPFbpftool
出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。
第11章 手動 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 レコードのライフサイクルを手動で管理する必要があります。
11.1. Managed
DNS 管理ポリシー
Ingress Controller の Managed
DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが Operator によって自動的に管理されるようになります。
11.2. Unmanaged
DNS 管理ポリシー
Ingress Controller の Unmanaged
DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが自動的に管理されず、代わりにクラスター管理者の責任になります。
AWS クラウドプラットフォームでは、Ingress Controller のドメインが dnsConfig.Spec.BaseDomain
と一致しない場合、DNS 管理ポリシーは自動的に Unmanaged
に設定されます。
11.3. Unmanaged
DNS 管理ポリシーを使用したカスタム Ingress Controller の作成
クラスター管理者は、Unmanaged
DNS 管理ポリシーを使用して、新しいカスタム Ingress Controller を作成できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下を含む
sample-ingress.yaml
という名前のカスタムリソース (CR) ファイルを作成します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: <name> spec: domain: <domain> endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: External dnsManagementPolicy: Unmanaged
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: <name>
1 spec: domain: <domain>
2 endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: External
3 dnsManagementPolicy: Unmanaged
4 Copy to Clipboard Copied! 変更を適用するためにファイルを保存します。
oc apply -f <name>.yaml
oc apply -f <name>.yaml
1 Copy to Clipboard Copied!
11.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! - オプション: クラウドプロバイダーで関連付けられている DNS レコードを削除できます。
第12章 エンドポイントへの接続の確認
Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。
12.1. 実行する接続ヘルスチェック
クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。
- Kubernetes API サーバーサービス
- Kubernetes API サーバーエンドポイント
- OpenShift API サーバーサービス
- OpenShift API サーバーエンドポイント
- ロードバランサー
サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。
- ヘルスチェックターゲットサービス
- ヘルスチェックターゲットエンドポイント
12.2. 接続ヘルスチェックの実装
接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics
namespace の PodNetworkConnectivity
オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。
Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。
- ヘルスチェックのソース
-
このプログラムは、
Deployment
オブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムはPodNetworkConnectivity
オブジェクトを消費し、各オブジェクトで指定されるspec.targetEndpoint
に接続されます。 - ヘルスチェックのターゲット
- クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。
12.3. PodNetworkConnectivityCheck オブジェクトフィールド
PodNetworkConnectivityCheck
オブジェクトフィールドについては、以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
|
以下の形式のオブジェクトの名前:
|
|
|
オブジェクトが関連付けられる namespace。この値は、常に |
|
|
接続チェックの起点となる Pod の名前 (例: |
|
|
|
|
| 使用する TLS 証明書の設定。 |
|
| 使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。 |
|
| 接続テストの状態を表す、および最近の接続の成功および失敗に関するログ。 |
|
| 接続チェックと最新のステータスと以前のステータス。 |
|
| 試行に失敗した接続テストのログ。 |
|
| 停止が生じた期間が含まれる接続テストのログ。 |
|
| 試行に成功した接続テストのログ。 |
以下の表は、status.conditions
配列内のオブジェクトのフィールドを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
| 接続の条件がある状態から別の状態に移行した時間。 |
|
| 人が判読できる形式の最後の移行に関する詳細。 |
|
| マシンの読み取り可能な形式での移行の最後のステータス。 |
|
| 状態のテータス。 |
|
| 状態のタイプ。 |
以下の表は、status.conditions
配列内のオブジェクトのフィールドを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
| 接続の障害が解決された時点からのタイムスタンプ。 |
|
| 接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。 |
|
| 人が判読できる形式の停止について詳細情報の要約。 |
|
| 接続の障害が最初に検知された時点からのタイムスタンプ。 |
|
| 元の障害を含む接続ログのエントリー。 |
接続ログフィールド
接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。
-
status.failures[]
-
status.successes[]
-
status.outages[].startLogs[]
-
status.outages[].endLogs[]
フィールド | 型 | 説明 |
---|---|---|
|
| アクションの期間を記録します。 |
|
| ステータスを人が判読できる形式で提供します。 |
|
|
ステータスの理由をマシンが判読できる形式で提供します。値は |
|
| ログエントリーが成功または失敗であるかを示します。 |
|
| 接続チェックの開始時間。 |
12.4. エンドポイントのネットワーク接続の確認
クラスター管理者は、API サーバー、ロードバランサー、サービス、または Pod などのエンドポイントの接続を確認できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
現在の
PodNetworkConnectivityCheck
オブジェクトをリスト表示するには、以下のコマンドを入力します。oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics
Copy to Clipboard Copied! 出力例
NAME AGE network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 73m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster 75m
NAME AGE network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 73m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1 75m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2 74m network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster 75m
Copy to Clipboard Copied! 接続テストログを表示します。
- 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。
オブジェクトを表示するには、以下のコマンドを入力します。
oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
$ oc get podnetworkconnectivitycheck <name> \ -n openshift-network-diagnostics -o yaml
Copy to Clipboard Copied! ここで、
<name>
はPodNetworkConnectivityCheck
オブジェクトの名前を指定します。出力例
apiVersion: controlplane.operator.openshift.io/v1alpha1 kind: PodNetworkConnectivityCheck metadata: name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 namespace: openshift-network-diagnostics ... spec: sourcePod: network-check-source-7c88f6d9f-hmg2f targetEndpoint: 10.0.0.4:6443 tlsClientCert: name: "" status: conditions: - lastTransitionTime: "2021-01-13T20:11:34Z" message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnectSuccess status: "True" type: Reachable failures: - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" outages: - end: "2021-01-13T20:11:34Z" endLogs: - latency: 2.032018ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T20:11:34Z" - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" message: Connectivity restored after 2m59.999789186s start: "2021-01-13T20:08:34Z" startLogs: - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" successes: - latency: 2.845865ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:14:34Z" - latency: 2.926345ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:13:34Z" - latency: 2.895796ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:12:34Z" - latency: 2.696844ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:11:34Z" - latency: 1.502064ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:10:34Z" - latency: 1.388857ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:09:34Z" - latency: 1.906383ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:08:34Z" - latency: 2.089073ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:07:34Z" - latency: 2.156994ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:06:34Z" - latency: 1.777043ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:05:34Z"
apiVersion: controlplane.operator.openshift.io/v1alpha1 kind: PodNetworkConnectivityCheck metadata: name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0 namespace: openshift-network-diagnostics ... spec: sourcePod: network-check-source-7c88f6d9f-hmg2f targetEndpoint: 10.0.0.4:6443 tlsClientCert: name: "" status: conditions: - lastTransitionTime: "2021-01-13T20:11:34Z" message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnectSuccess status: "True" type: Reachable failures: - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" outages: - end: "2021-01-13T20:11:34Z" endLogs: - latency: 2.032018ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T20:11:34Z" - latency: 2.241775ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:10:34Z" - latency: 2.582129ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:09:34Z" - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" message: Connectivity restored after 2m59.999789186s start: "2021-01-13T20:08:34Z" startLogs: - latency: 3.483578ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect: connection refused' reason: TCPConnectError success: false time: "2021-01-13T20:08:34Z" successes: - latency: 2.845865ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:14:34Z" - latency: 2.926345ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:13:34Z" - latency: 2.895796ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:12:34Z" - latency: 2.696844ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:11:34Z" - latency: 1.502064ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:10:34Z" - latency: 1.388857ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:09:34Z" - latency: 1.906383ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:08:34Z" - latency: 2.089073ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:07:34Z" - latency: 2.156994ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:06:34Z" - latency: 1.777043ms message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp connection to 10.0.0.4:6443 succeeded' reason: TCPConnect success: true time: "2021-01-13T21:05:34Z"
Copy to Clipboard Copied!
第13章 クラスターネットワークの MTU 変更
クラスター管理者は、クラスターのインストール後にクラスターネットワークの MTU を変更できます。MTU 変更の適用には、クラスターノードを再起動する必要があるため、変更により致命的な問題が発生する可能性があります。
MTU は、OVN-Kubernetes プラグインまたは OpenShift SDN ネットワークプラグインを使用するクラスターに対してのみ変更できます。
13.1. クラスター MTU について
インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。
以下のような理由でクラスターネットワークの MTU を変更する場合があります。
- クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
- クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。
13.1.1. サービス中断に関する考慮事項
クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。
- 新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
- 特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。
13.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
) を確認します。
13.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 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。 |
13.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 cluster
Copy to Clipboard Copied! 出力例
... Status: Cluster Network: Cidr: 10.217.0.0/22 Host Prefix: 23 Cluster Network MTU: 1400 Network Type: OVNKubernetes Service Network: 10.217.4.0/23 ...
... Status: Cluster Network: Cidr: 10.217.0.0/22 Host Prefix: 23 Cluster Network MTU: 1400 Network Type: OVNKubernetes Service Network: 10.217.4.0/23 ...
Copy to Clipboard Copied! ハードウェア MTU の設定を準備します。
ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。
dhcp-option-force=26,<mtu>
dhcp-option-force=26,<mtu>
Copy to Clipboard Copied! ここでは、以下のようになります。
<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! ここでは、以下のようになります。
<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-phys0
Copy to Clipboard Copied! ここでは、以下のようになります。
<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! ここでは、以下のようになります。
<mtu>
- 新しいハードウェア MTU 値を指定します。
<interface>
- プライマリーネットワークインターフェイス名を指定します。
1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つの
MachineConfig
オブジェクトを作成します。control-plane-interface.bu
ファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0
です。たとえば、4.15.0
です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。variant: openshift version: 4.15.0 metadata: name: 01-control-plane-interface labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf contents: local: <interface>-mtu.conf mode: 0600
variant: openshift version: 4.15.0 metadata: name: 01-control-plane-interface labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
1 contents: local: <interface>-mtu.conf
2 mode: 0600
Copy to Clipboard Copied! worker-interface.bu
ファイルに次の Butane 設定を作成します。注記設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に
0
です。たとえば、4.15.0
です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。variant: openshift version: 4.15.0 metadata: name: 01-worker-interface labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf contents: local: <interface>-mtu.conf mode: 0600
variant: openshift version: 4.15.0 metadata: name: 01-worker-interface labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
1 contents: local: <interface>-mtu.conf
2 mode: 0600
Copy to Clipboard Copied! 次のコマンドを実行して、Butane 設定から
MachineConfig
オブジェクトを作成します。for manifest in control-plane-interface worker-interface; do
$ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done
Copy to Clipboard Copied! 警告これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。
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! ここでは、以下のようになります。
<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! Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpools
Copy to Clipboard Copied! 正常に更新されたノードには、
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! 出力例
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: Done
Copy to Clipboard Copied! 以下のステートメントが 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 ExecStart
Copy to Clipboard Copied! ここで、
<config_name>
はmachineconfiguration.openshift.io/currentConfig
フィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/mtu-migration.sh
ExecStart=/usr/local/bin/mtu-migration.sh
Copy to Clipboard Copied!
基盤となるネットワークインターフェイスの MTU 値を更新します。
NetworkManager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。MachineConfig Operator は、クラスター内のノードのローリングリブートを自動的に実行します。
for manifest in control-plane-interface worker-interface; do
$ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done
Copy to Clipboard Copied! - DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。
Machine Config Operator は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpools
Copy to Clipboard Copied! 正常に更新されたノードには、
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! 出力例
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: Done
Copy to Clipboard Copied! 以下のステートメントが 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! ここで、
<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! 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!
MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get machineconfigpools
$ oc get machineconfigpools
Copy to Clipboard Copied! 正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。
検証
クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
oc describe network.config cluster
$ oc describe network.config cluster
Copy to Clipboard Copied! ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。
クラスター内のノードをリスト表示するには、次のコマンドを入力します。
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! ノードのプライマリーネットワークインターフェイスの現在の 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! ここでは、以下のようになります。
<node>
- 前のステップの出力をもとに、ノードを指定します。
<interface>
- ノードのプライマリーネットワークインターフェイス名を指定します。
出力例
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
Copy to Clipboard Copied!
第14章 ノードポートサービス範囲の設定
クラスターのインストール時に、クラスターの要件を満たすようにノードポート範囲を設定できます。クラスターのインストール後に、クラスター管理者のみがインストール後のタスクとして範囲を拡張できます。クラスターで多数のノードポートが使用される場合、クラスターの要件に応じて利用可能なポート範囲を増やすことを検討してください。
ノードのポート範囲を拡張する前に、Red Hat がデフォルトのポート範囲の 30000-32768
外でテストを実行していないことを検討してください。デフォルトのポート範囲外の範囲については、拡張ノードポート範囲がクラスターに影響を与えないことを確認するためにテストしてください。範囲とポート割り当ての問題が発生した場合は、新しいクラスターを作成し、そのクラスターに必要な範囲を設定します。
クラスターのインストール時にノードポート範囲を設定しない場合、デフォルトの 30000-32768
の範囲がクラスターに適用されます。この場合、どちらの側で範囲を拡張できますが、新しいポート範囲内に 30000-32768
を保持する必要があります。
ノードのポート範囲を拡張し、ポートが OpenShift API サーバーとの競合のために OpenShift CLI (oc
)が機能しなくなった場合は、新しいクラスターを作成する必要があります。新規ノードポート範囲が、ホストネットワークで設定されているホストプロセスまたは Pod ですでに使用されているポートと重複しないようにしてください。
14.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! - 1
- ここで
、<port_range
> は30000-32900
などの拡張範囲になります。
ヒント以下の YAML を適用して、ノードのポート範囲を更新することもできます。
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "<port_range>" # ...
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "<port_range>" # ...
Copy to Clipboard Copied! 出力例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patched
Copy to Clipboard Copied!
検証
設定が正常に行われたことを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分かかる場合があります。
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! 出力例
"service-node-port-range":["30000-32900"]
"service-node-port-range":["30000-32900"]
Copy to Clipboard Copied!
第15章 クラスターネットワーク範囲の設定
クラスター管理者は、クラスターのインストール後にクラスターネットワークの範囲を拡張できます。追加ノード用にさらに多くの IP アドレスが必要な場合は、クラスターネットワーク範囲を拡張することを推奨します。
たとえば、クラスターをデプロイし、クラスターネットワーク範囲として 10.128.0.0/19
を指定し、ホスト接頭辞 23
を指定した場合、16 ノードに制限されます。クラスターの CIDR マスクを /14
に変更することで、これを 510 ノードに拡張できます。
クラスターのネットワークアドレス範囲を拡張する場合、クラスターは OVN-Kubernetes ネットワークプラグイン を使用する必要があります。他のネットワークプラグインはサポートされていません。
クラスターネットワークの IP アドレス範囲を変更する場合、次の制限が適用されます。
- 指定する CIDR マスクサイズは、現在設定されている CIDR マスクサイズより常に小さくする必要があります。これは、インストールされたクラスターにノードを追加することによってのみ IP スペースを増やすことができるためです。
- ホスト接頭辞は変更できません
- オーバーライドされたデフォルトゲートウェイで設定された Pod は、クラスターネットワークの拡張後に再作成する必要があります。
15.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! 出力例
[{"cidr":"10.217.0.0/22","hostPrefix":23}]
[{"cidr":"10.217.0.0/22","hostPrefix":23}]
Copy to Clipboard Copied! クラスターネットワークの IP アドレス範囲を拡張するには、次のコマンドを入力します。前のコマンドの出力から返された CIDR IP アドレス範囲とホスト接頭辞を使用します。
oc patch Network.config.openshift.io cluster --type='merge' --patch \ '{
$ oc patch Network.config.openshift.io cluster --type='merge' --patch \ '{ "spec":{ "clusterNetwork": [ {"cidr":"<network>/<cidr>","hostPrefix":<prefix>} ], "networkType": "OVNKubernetes" } }'
Copy to Clipboard Copied! ここでは、以下のようになります。
<network>
-
前の手順で取得した
cidr
フィールドのネットワーク部分を指定します。この値は変更できません。 <cidr>
-
ネットワーク接頭辞長を指定します。たとえば、
14
です。この値を前の手順の出力の値よりも小さい数値に変更して、クラスターネットワークの範囲を拡大します。 <prefix>
-
クラスターの現在のホスト接頭辞を指定します。この値は、前の手順で取得した
hostPrefix
フィールドの値と同じである必要があります。
コマンドの例
oc patch Network.config.openshift.io cluster --type='merge' --patch \ '{
$ oc patch Network.config.openshift.io cluster --type='merge' --patch \ '{ "spec":{ "clusterNetwork": [ {"cidr":"10.217.0.0/14","hostPrefix": 23} ], "networkType": "OVNKubernetes" } }'
Copy to Clipboard Copied! 出力例
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patched
Copy to Clipboard Copied! 設定がアクティブであることを確認するには、以下のコマンドを入力します。この変更が有効になるまで、最大 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! 出力例
[{"cidr":"10.217.0.0/14","hostPrefix":23}]
[{"cidr":"10.217.0.0/14","hostPrefix":23}]
Copy to Clipboard Copied!
第16章 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 です。
16.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 ファイルシステム内の完全パス名です。 | |
|
|
新たな優先度の高いホストを処理するためのストラテジーです。 |
16.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.sh
rc ファイル (RHCOS ドキュメント) をダウンロードした。
手順
IP フェイルオーバーのサービスアカウントを作成します。
oc create sa ipfailover
$ oc create sa ipfailover
Copy to Clipboard Copied! hostNetwork
の SCC (Security Context Constraints) を更新します。oc adm policy add-scc-to-user privileged -z ipfailover
$ oc adm policy add-scc-to-user privileged -z ipfailover
Copy to Clipboard Copied! oc adm policy add-scc-to-user hostnetwork -z ipfailover
$ oc adm policy add-scc-to-user hostnetwork -z ipfailover
Copy to Clipboard Copied! 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_pairs
Copy to Clipboard Copied! 出力例
*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! 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:cb
Copy to Clipboard Copied! - デプロイメントの IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。後の手順の「IP フェイルオーバー設定のデプロイメント YAML の例」を参照してください。
IP フェイルオーバーのデプロイメントで次の仕様を指定して、フェイルオーバー仮想 IP アドレスを
OPENSHIFT_HA_VIRTUAL_IPS
環境変数に渡します。OPENSHIFT_HA_VIRTUAL_IPS
に1.1.1.1
仮想 IP アドレスを追加する例apiVersion: apps/v1 kind: Deployment metadata: name: ipfailover-keepalived # ... spec: env: - name: OPENSHIFT_HA_VIRTUAL_IPS value: "1.1.1.1" # ...
apiVersion: apps/v1 kind: Deployment metadata: name: ipfailover-keepalived # ... spec: env: - name: OPENSHIFT_HA_VIRTUAL_IPS value: "1.1.1.1" # ...
Copy to Clipboard Copied!
IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。
注記Red Hat OpenStack Platform (RHOSP) の場合、デプロイメント YAML ファイルを再作成する必要はありません。このファイルは、以前の手順ですでに作成されています。
IP フェイルオーバー設定のデプロイメント YAML の例
apiVersion: apps/v1 kind: Deployment metadata: name: ipfailover-keepalived labels: ipfailover: hello-openshift spec: strategy: type: Recreate replicas: 2 selector: matchLabels: ipfailover: hello-openshift template: metadata: labels: ipfailover: hello-openshift spec: serviceAccountName: ipfailover privileged: true hostNetwork: true nodeSelector: node-role.kubernetes.io/worker: "" containers: - name: openshift-ipfailover image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.15 ports: - containerPort: 63000 hostPort: 63000 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: lib-modules mountPath: /lib/modules readOnly: true - name: host-slash mountPath: /host readOnly: true mountPropagation: HostToContainer - name: etc-sysconfig mountPath: /etc/sysconfig readOnly: true - name: config-volume mountPath: /etc/keepalive env: - name: OPENSHIFT_HA_CONFIG_NAME value: "ipfailover" - name: OPENSHIFT_HA_VIRTUAL_IPS value: "1.1.1.1-2" - name: OPENSHIFT_HA_VIP_GROUPS value: "10" - name: OPENSHIFT_HA_NETWORK_INTERFACE value: "ens3" #The host interface to assign the VIPs - name: OPENSHIFT_HA_MONITOR_PORT value: "30060" - name: OPENSHIFT_HA_VRRP_ID_OFFSET value: "0" - name: OPENSHIFT_HA_REPLICA_COUNT value: "2" #Must match the number of replicas in the deployment - name: OPENSHIFT_HA_USE_UNICAST value: "false" #- name: OPENSHIFT_HA_UNICAST_PEERS #value: "10.0.148.40,10.0.160.234,10.0.199.110" - name: OPENSHIFT_HA_IPTABLES_CHAIN value: "INPUT" #- name: OPENSHIFT_HA_NOTIFY_SCRIPT # value: /etc/keepalive/mynotifyscript.sh - name: OPENSHIFT_HA_CHECK_SCRIPT value: "/etc/keepalive/mycheckscript.sh" - name: OPENSHIFT_HA_PREEMPTION value: "preempt_delay 300" - name: OPENSHIFT_HA_CHECK_INTERVAL value: "2" livenessProbe: initialDelaySeconds: 10 exec: command: - pgrep - keepalived volumes: - name: lib-modules hostPath: path: /lib/modules - name: host-slash hostPath: path: / - name: etc-sysconfig hostPath: path: /etc/sysconfig # config-volume contains the check script # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh` - configMap: defaultMode: 0755 name: keepalived-checkscript name: config-volume imagePullSecrets: - name: openshift-pull-secret
apiVersion: apps/v1 kind: Deployment metadata: name: ipfailover-keepalived
1 labels: ipfailover: hello-openshift spec: strategy: type: Recreate replicas: 2 selector: matchLabels: ipfailover: hello-openshift template: metadata: labels: ipfailover: hello-openshift spec: serviceAccountName: ipfailover privileged: true hostNetwork: true nodeSelector: node-role.kubernetes.io/worker: "" containers: - name: openshift-ipfailover image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.15 ports: - containerPort: 63000 hostPort: 63000 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: lib-modules mountPath: /lib/modules readOnly: true - name: host-slash mountPath: /host readOnly: true mountPropagation: HostToContainer - name: etc-sysconfig mountPath: /etc/sysconfig readOnly: true - name: config-volume mountPath: /etc/keepalive env: - name: OPENSHIFT_HA_CONFIG_NAME value: "ipfailover" - name: OPENSHIFT_HA_VIRTUAL_IPS
2 value: "1.1.1.1-2" - name: OPENSHIFT_HA_VIP_GROUPS
3 value: "10" - name: OPENSHIFT_HA_NETWORK_INTERFACE
4 value: "ens3" #The host interface to assign the VIPs - name: OPENSHIFT_HA_MONITOR_PORT
5 value: "30060" - name: OPENSHIFT_HA_VRRP_ID_OFFSET
6 value: "0" - name: OPENSHIFT_HA_REPLICA_COUNT
7 value: "2" #Must match the number of replicas in the deployment - name: OPENSHIFT_HA_USE_UNICAST value: "false" #- name: OPENSHIFT_HA_UNICAST_PEERS #value: "10.0.148.40,10.0.160.234,10.0.199.110" - name: OPENSHIFT_HA_IPTABLES_CHAIN
8 value: "INPUT" #- name: OPENSHIFT_HA_NOTIFY_SCRIPT
9 # value: /etc/keepalive/mynotifyscript.sh - name: OPENSHIFT_HA_CHECK_SCRIPT
10 value: "/etc/keepalive/mycheckscript.sh" - name: OPENSHIFT_HA_PREEMPTION
11 value: "preempt_delay 300" - name: OPENSHIFT_HA_CHECK_INTERVAL
12 value: "2" livenessProbe: initialDelaySeconds: 10 exec: command: - pgrep - keepalived volumes: - name: lib-modules hostPath: path: /lib/modules - name: host-slash hostPath: path: / - name: etc-sysconfig hostPath: path: /etc/sysconfig # config-volume contains the check script # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh` - configMap: defaultMode: 0755 name: keepalived-checkscript name: config-volume imagePullSecrets: - name: openshift-pull-secret
13 Copy to Clipboard Copied! - 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
- デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。
16.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 0
Copy to Clipboard Copied! ConfigMap
オブジェクトを作成します。oc create configmap mycustomcheck --from-file=mycheckscript.sh
$ oc create configmap mycustomcheck --from-file=mycheckscript.sh
Copy to Clipboard Copied! スクリプトを 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.sh
Copy to Clipboard Copied! 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! 注記oc set env
コマンドは空白を区別します。=
記号の両側に空白を入れることはできません。ヒントまたは、
ipfailover-keepalived
デプロイメント設定を編集することもできます。oc edit deploy ipfailover-keepalived
$ oc edit deploy ipfailover-keepalived
Copy to Clipboard Copied! spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT value: /etc/keepalive/mycheckscript.sh ... volumeMounts: - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst ... volumes: - configMap: defaultMode: 0755 name: customrouter name: config-volume ...
spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT
1 value: /etc/keepalive/mycheckscript.sh ... volumeMounts:
2 - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst ... volumes:
3 - configMap: defaultMode: 0755
4 name: customrouter name: config-volume ...
Copy to Clipboard Copied! 変更を保存し、エディターを終了します。これにより
ipfailover-keepalived
が再起動されます。
16.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-keepalived
Copy to Clipboard Copied! ... spec: containers: - env: - name: OPENSHIFT_HA_PREEMPTION value: preempt_delay 300 ...
... spec: containers: - env: - name: OPENSHIFT_HA_PREEMPTION
1 value: preempt_delay 300 ...
Copy to Clipboard Copied! - 1
OPENSHIFT_HA_PREEMPTION
の値を設定します。-
preempt_delay 300
: Keepalived は、指定された 300 秒の間待機し、master
をホスト上の優先度の高い VIP に移動します。これはデフォルト値です。 -
nopreempt
:master
をホスト上の優先度の低い VIP からホスト上の優先度の高い VIP に移動しません。
-
16.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
範囲が重複しないようにする必要があります。
16.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 フェイルオーバー設定の
Deployment
YAML の例... spec: env: - name: OPENSHIFT_HA_VIP_GROUPS value: "3" ...
... spec: env: - name: OPENSHIFT_HA_VIP_GROUPS
1 value: "3" ...
Copy to Clipboard Copied! - 1
- たとえば、7 つの VIP のある環境で
OPENSHIFT_HA_VIP_GROUPS
が3
に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。
OPENSHIFT_HA_VIP_GROUPS
で設定されたグループの数が、フェイルオーバーに設定された IP アドレスの数より少ない場合、グループには複数の IP アドレスが含まれ、すべてのアドレスが 1 つのユニットとして移動します。
16.7. ExternalIP の高可用性
非クラウドクラスターでは、IP フェイルオーバーとサービスへの ExternalIP
を組み合わせることができます。結果として、ExternalIP
を使用してサービスを作成するユーザーに高可用サービスが提供されます。
このアプローチでは、クラスターネットワーク設定の spec.ExternalIP.autoAssignCIDRs
範囲を指定し、同じ範囲を使用して IP フェイルオーバー設定を作成します。
IP フェイルオーバーはクラスター全体で最大 255 個の仮想 IP をサポートできるため、spec.ExternalIP.autoAssignCIDRs
は /24
以下にする必要があります。
16.8. IP フェイルオーバーの削除
IP フェイルオーバーが最初に設定されている場合、クラスターのワーカーノードは、Keepalived 用に 224.0.0.18
のマルチキャストパケットを明示的に許可する iptables
ルールを使用して変更されます。ノードが変更されるため、IP フェイルオーバーを削除するには、ジョブを実行して iptables
ルールを削除し、Keepalived が使用する仮想 IP アドレスを削除する必要があります。
手順
オプション: config map として保存されるチェックおよび通知スクリプトを特定し、削除します。
IP フェイルオーバーの Pod が config map をボリュームとして使用するかどうかを決定します。
oc get pod -l ipfailover \ -o jsonpath="\ {range .items[?(@.spec.volumes[*].configMap)]}
$ oc get pod -l ipfailover \ -o jsonpath="\ {range .items[?(@.spec.volumes[*].configMap)]} {'Namespace: '}{.metadata.namespace} {'Pod: '}{.metadata.name} {'Volumes that use config maps:'} {range .spec.volumes[?(@.configMap)]} {'volume: '}{.name} {'configMap: '}{.configMap.name}{'\n'}{end} {end}"
Copy to Clipboard Copied! 出力例
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: mycustomcheck
Copy to Clipboard Copied! 前述の手順でボリュームとして使用される config map の名前が提供されている場合は、config map を削除します。
oc delete configmap <configmap_name>
$ oc delete configmap <configmap_name>
Copy to Clipboard Copied!
IP フェイルオーバーの既存デプロイメントを特定します。
oc get deployment -l ipfailover
$ oc get deployment -l ipfailover
Copy to Clipboard Copied! 出力例
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 105d
Copy to Clipboard Copied! デプロイメントを削除します。
oc delete deployment <ipfailover_deployment_name>
$ oc delete deployment <ipfailover_deployment_name>
Copy to Clipboard Copied! ipfailover
サービスアカウントを削除します。oc delete sa ipfailover
$ oc delete sa ipfailover
Copy to Clipboard Copied! IP フェイルオーバーの設定時に追加された IP テーブルルールを削除するジョブを実行します。
以下の例のような内容で
remove-ipfailover-job.yaml
などのファイルを作成します。apiVersion: batch/v1 kind: Job metadata: generateName: remove-ipfailover- labels: app: remove-ipfailover spec: template: metadata: name: remove-ipfailover spec: containers: - name: remove-ipfailover image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.15 command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"] nodeSelector: kubernetes.io/hostname: <host_name> restartPolicy: Never
apiVersion: batch/v1 kind: Job metadata: generateName: remove-ipfailover- labels: app: remove-ipfailover spec: template: metadata: name: remove-ipfailover spec: containers: - name: remove-ipfailover image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.15 command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"] nodeSelector:
1 kubernetes.io/hostname: <host_name>
2 restartPolicy: Never
Copy to Clipboard Copied! ジョブを実行します。
oc create -f remove-ipfailover-job.yaml
$ oc create -f remove-ipfailover-job.yaml
Copy to Clipboard Copied! 出力例
job.batch/remove-ipfailover-2h8dm created
job.batch/remove-ipfailover-2h8dm created
Copy to Clipboard Copied!
検証
ジョブが IP フェイルオーバーの初期設定を削除していることを確認します。
oc logs job/remove-ipfailover-2h8dm
$ oc logs job/remove-ipfailover-2h8dm
Copy to Clipboard Copied! 出力例
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!
第17章 チューニングプラグインを使用してシステムコントロールとインターフェイス属性を設定する
Linux では、管理者は sysctl を使用してランタイム時にカーネルパラメーターを変更できます。チューニング Container Network Interface (CNI) メタプラグインを使用して、インターフェイスレベルのネットワーク sysctl を変更できます。チューニング CNI メタプラグインは、図に示すように、メインの CNI プラグインとチェーンで動作します。

メインの CNI プラグインはインターフェイスを割り当て、それをランタイム時にチューニング CNI メタプラグインに渡します。チューニング CNI メタプラグインを使用して、ネットワーク namespace の一部の sysctl といくつかのインターフェイス属性 (プロミスキャスモード、オールマルチキャストモード、MTU、および MAC アドレス) を変更できます。
17.1. チューニング CNI を使用してシステム制御を設定する
次の手順では、チューニング CNI を設定し、インターフェイスレベルのネットワーク net.ipv4.conf.IFNAME.accept_redirects
sysctl を変更します。この例では、ICMP リダイレクトパケットの受け入れと送信を有効にします。チューニング CNI メタプラグイン設定では、インターフェイス名は IFNAME
トークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。
手順
次の内容で、
tuning-example.yaml
などのネットワーク接続定義を作成します。apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <name> namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "<name>", "plugins": [{ "type": "<main_CNI_plugin>" }, { "type": "tuning", "sysctl": { "net.ipv4.conf.IFNAME.accept_redirects": "1" } } ] }
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <name>
1 namespace: default
2 spec: config: '{ "cniVersion": "0.4.0",
3 "name": "<name>",
4 "plugins": [{ "type": "<main_CNI_plugin>"
5 }, { "type": "tuning",
6 "sysctl": { "net.ipv4.conf.IFNAME.accept_redirects": "1"
7 } } ] }
Copy to Clipboard Copied! - 1
- 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
- 2
- オブジェクトが関連付けられている namespace を指定します。
- 3
- CNI 仕様のバージョンを指定します。
- 4
- 設定の名前を指定します。設定名をネットワーク接続定義の name の値に一致させることが推奨されます。
- 5
- 設定するメイン CNI プラグインの名前を指定します。
- 6
- CNI メタプラグインの名前を指定します。
- 7
- 設定する sysctl を指定します。インターフェイス名は
IFNAME
トークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。
YAML ファイルの例を次に示します。
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: tuningnad namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "tuningnad", "plugins": [{ "type": "bridge" }, { "type": "tuning", "sysctl": { "net.ipv4.conf.IFNAME.accept_redirects": "1" } } ] }'
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: tuningnad namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "tuningnad", "plugins": [{ "type": "bridge" }, { "type": "tuning", "sysctl": { "net.ipv4.conf.IFNAME.accept_redirects": "1" } } ] }'
Copy to Clipboard Copied! 以下のコマンドを実行して YAML を適用します。
oc apply -f tuning-example.yaml
$ oc apply -f tuning-example.yaml
Copy to Clipboard Copied! 出力例
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
networkattachmentdefinition.k8.cni.cncf.io/tuningnad created
Copy to Clipboard Copied! 次のようなネットワーク接続定義を使用して、
examplepod.yaml
などの Pod を作成します。apiVersion: v1 kind: Pod metadata: name: tunepod namespace: default annotations: k8s.v1.cni.cncf.io/networks: tuningnad spec: containers: - name: podexample image: centos command: ["/bin/bash", "-c", "sleep INF"] securityContext: runAsUser: 2000 runAsGroup: 3000 allowPrivilegeEscalation: false capabilities: drop: ["ALL"] securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault
apiVersion: v1 kind: Pod metadata: name: tunepod namespace: default annotations: k8s.v1.cni.cncf.io/networks: tuningnad
1 spec: containers: - name: podexample image: centos command: ["/bin/bash", "-c", "sleep INF"] securityContext: runAsUser: 2000
2 runAsGroup: 3000
3 allowPrivilegeEscalation: false
4 capabilities:
5 drop: ["ALL"] securityContext: runAsNonRoot: true
6 seccompProfile:
7 type: RuntimeDefault
Copy to Clipboard Copied! - 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.yaml
Copy to Clipboard Copied! 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod
$ oc get pod
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
NAME READY STATUS RESTARTS AGE tunepod 1/1 Running 0 47s
Copy to Clipboard Copied! 次のコマンドを実行して、Pod にログインします。
oc rsh tunepod
$ oc rsh tunepod
Copy to Clipboard Copied! 設定された sysctl フラグの値を確認します。たとえば、次のコマンドを実行して、値
net.ipv4.conf.net1.accept_redirects
を見つけます。sysctl net.ipv4.conf.net1.accept_redirects
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
Copy to Clipboard Copied! 予想される出力
net.ipv4.conf.net1.accept_redirects = 1
net.ipv4.conf.net1.accept_redirects = 1
Copy to Clipboard Copied!
17.2. チューニング CNI を使用してオールマルチキャストモードを有効にする
チューニング Container Network Interface (CNI) メタプラグインを使用して、オールマルチキャストモードを有効にできます。
次の手順では、チューニング CNI を設定してオールマルチキャストモードを有効にする方法を説明します。
手順
次の内容で、
tuning-example.yaml
などのネットワーク接続定義を作成します。apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <name> namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "<name>", "plugins": [{ "type": "<main_CNI_plugin>" }, { "type": "tuning", "allmulti": true } } ] }
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <name>
1 namespace: default
2 spec: config: '{ "cniVersion": "0.4.0",
3 "name": "<name>",
4 "plugins": [{ "type": "<main_CNI_plugin>"
5 }, { "type": "tuning",
6 "allmulti": true
7 } } ] }
Copy to Clipboard Copied! - 1
- 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
- 2
- オブジェクトが関連付けられている namespace を指定します。
- 3
- CNI 仕様のバージョンを指定します。
- 4
- 設定の名前を指定します。設定名は、ネットワーク接続定義の名前の値と一致させます。
- 5
- 設定するメイン CNI プラグインの名前を指定します。
- 6
- CNI メタプラグインの名前を指定します。
- 7
- インターフェイスのオールマルチキャストモードを変更します。有効にすると、ネットワーク上のすべてのマルチキャストパケットがそのインターフェイスで受信されます。
YAML ファイルの例を次に示します。
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: setallmulti namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "setallmulti", "plugins": [ { "type": "bridge" }, { "type": "tuning", "allmulti": true } ] }'
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: setallmulti namespace: default spec: config: '{ "cniVersion": "0.4.0", "name": "setallmulti", "plugins": [ { "type": "bridge" }, { "type": "tuning", "allmulti": true } ] }'
Copy to Clipboard Copied! 次のコマンドを実行して、YAML ファイルで指定された設定を適用します。
oc apply -f tuning-allmulti.yaml
$ oc apply -f tuning-allmulti.yaml
Copy to Clipboard Copied! 出力例
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created
networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created
Copy to Clipboard Copied! 次の
examplepod.yaml
サンプルファイルで指定されているものと同様のネットワーク接続定義を持つ Pod を作成します。apiVersion: v1 kind: Pod metadata: name: allmultipod namespace: default annotations: k8s.v1.cni.cncf.io/networks: setallmulti spec: containers: - name: podexample image: centos command: ["/bin/bash", "-c", "sleep INF"] securityContext: runAsUser: 2000 runAsGroup: 3000 allowPrivilegeEscalation: false capabilities: drop: ["ALL"] securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault
apiVersion: v1 kind: Pod metadata: name: allmultipod namespace: default annotations: k8s.v1.cni.cncf.io/networks: setallmulti
1 spec: containers: - name: podexample image: centos command: ["/bin/bash", "-c", "sleep INF"] securityContext: runAsUser: 2000
2 runAsGroup: 3000
3 allowPrivilegeEscalation: false
4 capabilities:
5 drop: ["ALL"] securityContext: runAsNonRoot: true
6 seccompProfile:
7 type: RuntimeDefault
Copy to Clipboard Copied! - 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.yaml
Copy to Clipboard Copied! 次のコマンドを実行して、Pod が作成されていることを確認します。
oc get pod
$ oc get pod
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23s
NAME READY STATUS RESTARTS AGE allmultipod 1/1 Running 0 23s
Copy to Clipboard Copied! 次のコマンドを実行して、Pod にログインします。
oc rsh allmultipod
$ oc rsh allmultipod
Copy to Clipboard Copied! 次のコマンドを実行して、Pod に関連付けられているすべてのインターフェイスをリスト表示します。
ip link
sh-4.4# ip link
Copy to Clipboard Copied! 出力例
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8901 qdisc noqueue state UP mode DEFAULT group default link/ether 0a:58:0a:83:00:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0 3: net1@if24: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether ee:9b:66:a4:ec:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8901 qdisc noqueue state UP mode DEFAULT group default link/ether 0a:58:0a:83:00:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0
1 3: net1@if24: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether ee:9b:66:a4:ec:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0
2 Copy to Clipboard Copied!
第18章 Stream Control Transmission Protocol (SCTP) の使用
クラスター管理者は、ベアメタルクラスターで Stream Control Transmission Protocol (SCTP) を使用できます。
18.1. OpenShift Container Platform での SCTP のサポート
クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。
SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。
これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service
オブジェクトは、type
パラメーターを ClusterIP
または NodePort
のいずれかの値に設定して定義する必要があります。
18.1.1. SCTP プロトコルを使用した設定例
protocol
パラメーターを Pod またはサービスリソース定義の SCTP
値に設定して、Pod またはサービスを SCTP を使用するように設定できます。
以下の例では、Pod は SCTP を使用するように設定されています。
apiVersion: v1 kind: Pod metadata: namespace: project1 name: example-pod spec: containers: - name: example-pod ... ports: - containerPort: 30100 name: sctpserver protocol: SCTP
apiVersion: v1
kind: Pod
metadata:
namespace: project1
name: example-pod
spec:
containers:
- name: example-pod
...
ports:
- containerPort: 30100
name: sctpserver
protocol: SCTP
以下の例では、サービスは SCTP を使用するように設定されています。
apiVersion: v1 kind: Service metadata: namespace: project1 name: sctpserver spec: ... ports: - name: sctpserver protocol: SCTP port: 30100 targetPort: 30100 type: ClusterIP
apiVersion: v1
kind: Service
metadata:
namespace: project1
name: sctpserver
spec:
...
ports:
- name: sctpserver
protocol: SCTP
port: 30100
targetPort: 30100
type: ClusterIP
以下の例では、NetworkPolicy
オブジェクトは、特定のラベルの付いた Pod からポート 80
の SCTP ネットワークトラフィックに適用するように設定されます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-sctp-on-http spec: podSelector: matchLabels: role: web ingress: - ports: - protocol: SCTP port: 80
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-sctp-on-http
spec:
podSelector:
matchLabels:
role: web
ingress:
- ports:
- protocol: SCTP
port: 80
18.2. SCTP (Stream Control Transmission Protocol) の有効化
クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の YAML 定義が含まれる
load-sctp-module.yaml
という名前のファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: load-sctp-module labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/modprobe.d/sctp-blacklist.conf mode: 0644 overwrite: true contents: source: data:, - path: /etc/modules-load.d/sctp-load.conf mode: 0644 overwrite: true contents: source: data:,sctp
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: load-sctp-module labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/modprobe.d/sctp-blacklist.conf mode: 0644 overwrite: true contents: source: data:, - path: /etc/modules-load.d/sctp-load.conf mode: 0644 overwrite: true contents: source: data:,sctp
Copy to Clipboard Copied! MachineConfig
オブジェクトを作成するには、以下のコマンドを入力します。oc create -f load-sctp-module.yaml
$ oc create -f load-sctp-module.yaml
Copy to Clipboard Copied! オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが
Ready
に移行すると、設定の更新が適用されます。oc get nodes
$ oc get nodes
Copy to Clipboard Copied!
18.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認
SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。
前提条件
-
クラスターからインターネットにアクセスし、
nc
パッケージをインストールすること。 -
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
SCTP リスナーを起動する Pod を作成します。
以下の YAML で Pod を定義する
sctp-server.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: sctpserver labels: app: sctpserver spec: containers: - name: sctpserver image: registry.access.redhat.com/ubi9/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"] ports: - containerPort: 30102 name: sctpserver protocol: SCTP
apiVersion: v1 kind: Pod metadata: name: sctpserver labels: app: sctpserver spec: containers: - name: sctpserver image: registry.access.redhat.com/ubi9/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"] ports: - containerPort: 30102 name: sctpserver protocol: SCTP
Copy to Clipboard Copied! 以下のコマンドを入力して Pod を作成します。
oc create -f sctp-server.yaml
$ oc create -f sctp-server.yaml
Copy to Clipboard Copied!
SCTP リスナー Pod のサービスを作成します。
以下の YAML でサービスを定義する
sctp-service.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Service metadata: name: sctpservice labels: app: sctpserver spec: type: NodePort selector: app: sctpserver ports: - name: sctpserver protocol: SCTP port: 30102 targetPort: 30102
apiVersion: v1 kind: Service metadata: name: sctpservice labels: app: sctpserver spec: type: NodePort selector: app: sctpserver ports: - name: sctpserver protocol: SCTP port: 30102 targetPort: 30102
Copy to Clipboard Copied! サービスを作成するには、以下のコマンドを入力します。
oc create -f sctp-service.yaml
$ oc create -f sctp-service.yaml
Copy to Clipboard Copied!
SCTP クライアントの Pod を作成します。
以下の YAML で
sctp-client.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: sctpclient labels: app: sctpclient spec: containers: - name: sctpclient image: registry.access.redhat.com/ubi9/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"]
apiVersion: v1 kind: Pod metadata: name: sctpclient labels: app: sctpclient spec: containers: - name: sctpclient image: registry.access.redhat.com/ubi9/ubi command: ["/bin/sh", "-c"] args: ["dnf install -y nc && sleep inf"]
Copy to Clipboard Copied! Pod
オブジェクトを作成するには、以下のコマンドを入力します。oc apply -f sctp-client.yaml
$ oc apply -f sctp-client.yaml
Copy to Clipboard Copied!
サーバーで SCTP リスナーを実行します。
サーバー Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpserver
$ oc rsh sctpserver
Copy to Clipboard Copied! SCTP リスナーを起動するには、以下のコマンドを入力します。
nc -l 30102 --sctp
$ nc -l 30102 --sctp
Copy to Clipboard Copied!
サーバーの 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! クライアント Pod に接続するには、以下のコマンドを入力します。
oc rsh sctpclient
$ oc rsh sctpclient
Copy to Clipboard Copied! SCTP クライアントを起動するには、以下のコマンドを入力します。
<cluster_IP>
をsctpservice
サービスのクラスター IP アドレスに置き換えます。nc <cluster_IP> 30102 --sctp
# nc <cluster_IP> 30102 --sctp
Copy to Clipboard Copied!
第19章 Precision Time Protocol ハードウェアの使用
19.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 対応デバイスと連携します。
19.1.1. PTP ドメインの要素
PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。PTP によって同期されるクロックは、リーダーとフォロワーの階層で構成されています。この階層は、1 クロックごとに実行される best master clock (BMC) アルゴリズムによって自動的に作成および更新されます。フォロワークロックはリーダークロックと同期しており、フォロワークロック自体が他のダウンストリームクロックのソースになることができます。
図19.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 タイムサービスの無効化 を参照してください。
19.1.2. PTP を使用するデュアル Intel 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 は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。
図19.2 デュアル NIC グランドマスタークロック
注記デュアル NIC T-GM 構成では、単一の
ts2phc
プロセスがシステム内の 2 つのts2phc
インスタンスとして報告されます。- デュアル NIC 境界クロック
ミッドバンドスペクトルカバレッジを提供する 5G 電話会社ネットワークの場合、各仮想分散ユニット (vDU) には 6 つの無線ユニット (RU) への接続が必要です。これらの接続を確立するには、各 vDU ホストに境界クロックとして設定された 2 つの NIC が必要です。
デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の
ptp4l
インスタンスをダウンストリームクロックに供給することができます。
19.1.3. 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
-
ubxtool
CLI を使用すると、u-blox GPS システムと通信できます。ubxtool
CLI は、u-blox バイナリープロトコルを使用して GPS と通信します。 - gpspipe
-
gpspipe
はgpsd
出力に接続し、それをstdout
にパイプします。 - gpsd
-
gpsd
は、ホストに接続されている 1 つ以上の GPS または AIS 受信機を監視するサービスデーモンです。
19.1.4. PTP グランドマスタークロックの GNSS タイミングの概要
OpenShift Container Platform は、クラスター内の Global Navigation Satellite System (GNSS) ソースおよびグランドマスタークロック (T-GM) からの高精度 PTP タイミングの受信をサポートします。
OpenShift Container Platform は、Intel E810 Westport Channel NIC を使用した GNSS ソースからの PTP タイミングのみをサポートします。
図19.3 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 アプリケーションが音声通話とデータセッションを直ちに切断する可能性があります。
19.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.15 では、Intel E810 NIC が PtpConfig
プラグインでサポートされています。
19.2.1. CLI を使用した PTP Operator のインストール
クラスター管理者は、CLI を使用して Operator をインストールできます。
前提条件
- PTP に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
PTP Operator の namespace を作成します。
次の YAML を
ptp-namespace.yaml
ファイルに保存します。apiVersion: v1 kind: Namespace metadata: name: openshift-ptp annotations: workload.openshift.io/allowed: management labels: name: openshift-ptp openshift.io/cluster-monitoring: "true"
apiVersion: v1 kind: Namespace metadata: name: openshift-ptp annotations: workload.openshift.io/allowed: management labels: name: openshift-ptp openshift.io/cluster-monitoring: "true"
Copy to Clipboard Copied! namespace
CR を作成します。oc create -f ptp-namespace.yaml
$ oc create -f ptp-namespace.yaml
Copy to Clipboard Copied!
PTP Operator の Operator グループを作成します。
次の YAML を
ptp-operatorgroup.yaml
ファイルに保存します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ptp-operators namespace: openshift-ptp spec: targetNamespaces: - openshift-ptp
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: ptp-operators namespace: openshift-ptp spec: targetNamespaces: - openshift-ptp
Copy to Clipboard Copied! OperatorGroup
CR を作成します。oc create -f ptp-operatorgroup.yaml
$ oc create -f ptp-operatorgroup.yaml
Copy to Clipboard Copied!
PTP Operator にサブスクライブします。
次の YAML を
ptp-sub.yaml
ファイルに保存します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ptp-operator-subscription namespace: openshift-ptp spec: channel: "stable" name: ptp-operator source: redhat-operators sourceNamespace: openshift-marketplace
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ptp-operator-subscription namespace: openshift-ptp spec: channel: "stable" name: ptp-operator source: redhat-operators sourceNamespace: openshift-marketplace
Copy to Clipboard Copied! Subscription
CR を作成します。oc create -f ptp-sub.yaml
$ oc create -f ptp-sub.yaml
Copy to Clipboard Copied!
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.phase
Copy to Clipboard Copied! 出力例
Name Phase 4.15.0-202301261535 Succeeded
Name Phase 4.15.0-202301261535 Succeeded
Copy to Clipboard Copied!
19.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 のログを確認します。
19.2.3. クラスター内の PTP 対応ネットワークデバイスの検出
PTP 対応ネットワークデバイスを設定できるように、クラスター内に存在する PTP 対応ネットワークデバイスを特定します。
前提条件
- PTP Operator がインストールされている。
手順
クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。
oc get NodePtpDevice -n openshift-ptp -o yaml
$ oc get NodePtpDevice -n openshift-ptp -o yaml
Copy to Clipboard Copied! 出力例
apiVersion: v1 items: - apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2022-01-27T15:16:28Z" generation: 1 name: dev-worker-0 namespace: openshift-ptp resourceVersion: "6538103" uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a spec: {} status: devices: - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1 ...
apiVersion: v1 items: - apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2022-01-27T15:16:28Z" generation: 1 name: dev-worker-0
1 namespace: openshift-ptp resourceVersion: "6538103" uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a spec: {} status: devices:
2 - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1 ...
Copy to Clipboard Copied!
19.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 をインストールします。
手順
PtpConfig
CR を作成します。以下に例を示します。要件に応じて、デプロイメントに次の T-GM 設定のいずれかを使用します。YAML を
grandmaster-clock-ptp-config.yaml
ファイルに保存します。例19.1 E810 NIC の PTP グランドマスタークロック設定
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_master -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: enableDefaultConfig: false settings: LocalMaxHoldoverOffSet: 1500 LocalHoldoverTimeout: 14400 MaxInSpecOffset: 1500 pins: $e810_pins # "$iface_master": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "0 1" ublxCmds: - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 - "-P" - "29.20" - "-z" - "CFG-HW-ANT_CFG_VOLTCTRL,1" reportOutput: false - args: #ubxtool -P 29.20 -e GPS - "-P" - "29.20" - "-e" - "GPS" reportOutput: false - args: #ubxtool -P 29.20 -d Galileo - "-P" - "29.20" - "-d" - "Galileo" reportOutput: false - args: #ubxtool -P 29.20 -d GLONASS - "-P" - "29.20" - "-d" - "GLONASS" reportOutput: false - args: #ubxtool -P 29.20 -d BeiDou - "-P" - "29.20" - "-d" - "BeiDou" reportOutput: false - args: #ubxtool -P 29.20 -d SBAS - "-P" - "29.20" - "-d" - "SBAS" reportOutput: false - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000 - "-P" - "29.20" - "-t" - "-w" - "5" - "-v" - "1" - "-e" - "SURVEYIN,600,50000" reportOutput: true - args: #ubxtool -P 29.20 -p MON-HW - "-P" - "29.20" - "-p" - "MON-HW" reportOutput: true - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_master] ts2phc.extts_polarity rising ts2phc.extts_correction 0 ptp4lConf: | [$iface_master] masterOnly 1 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_master -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: enableDefaultConfig: false settings: LocalMaxHoldoverOffSet: 1500 LocalHoldoverTimeout: 14400 MaxInSpecOffset: 1500 pins: $e810_pins # "$iface_master": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "0 1" ublxCmds: - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 - "-P" - "29.20" - "-z" - "CFG-HW-ANT_CFG_VOLTCTRL,1" reportOutput: false - args: #ubxtool -P 29.20 -e GPS - "-P" - "29.20" - "-e" - "GPS" reportOutput: false - args: #ubxtool -P 29.20 -d Galileo - "-P" - "29.20" - "-d" - "Galileo" reportOutput: false - args: #ubxtool -P 29.20 -d GLONASS - "-P" - "29.20" - "-d" - "GLONASS" reportOutput: false - args: #ubxtool -P 29.20 -d BeiDou - "-P" - "29.20" - "-d" - "BeiDou" reportOutput: false - args: #ubxtool -P 29.20 -d SBAS - "-P" - "29.20" - "-d" - "SBAS" reportOutput: false - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000 - "-P" - "29.20" - "-t" - "-w" - "5" - "-v" - "1" - "-e" - "SURVEYIN,600,50000" reportOutput: true - args: #ubxtool -P 29.20 -p MON-HW - "-P" - "29.20" - "-p" - "MON-HW" reportOutput: true - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_master] ts2phc.extts_polarity rising ts2phc.extts_correction 0 ptp4lConf: | [$iface_master] masterOnly 1 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Copied! 注記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.yaml
Copy to Clipboard Copied!
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! プロファイルが正しいことを確認します。
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-container
Copy to Clipboard Copied! 出力例
ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1 ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset -1 s2 freq -1 ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset 943 s2 freq -89604 delay 504 phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1000 s2 freq -89264 delay 474
ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1 ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset -1 s2 freq -1 ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset 943 s2 freq -89604 delay 504 phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset 1000 s2 freq -89264 delay 474
Copy to Clipboard Copied!
19.2.5. linuxptp サービスをデュアル E810 Westport Channel NIC のグランドマスタークロックとして設定する
ホスト NIC を設定する PtpConfig
カスタムリソース (CR) を作成することで、linuxptp
サービス (ptp4l
、phc2sys
、ts2phc
) をデュアル E810 Westport Channel NIC のグランドマスタークロック (T-GM) として設定できます。
分散型 RAN (D-RAN) のユースケースでは、次の方法でデュアル NIC の PTP を設定できます。
- NIC 1 を、Global Navigation Satellite System (GNSS) のタイムソースに同期します。
-
NIC 2 を、NIC 1 によって提供される 1PPS タイミング出力に同期します。この設定は、
PtpConfig
CR の PTP ハードウェアプラグインによって提供します。
デュアル NIC PTP T-GM 構成では、1 つの ptp4l
インスタンスと、各 NIC に 1 つずつ、2 つの ts2phc
インスタンスを報告する 1 つの ts2phc
プロセスを使用します。ホストのシステムクロックは、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 をインストールします。
手順
PtpConfig
CR を作成します。以下に例を示します。次の YAML を
grandmaster-clock-ptp-config-dual-nics.yaml
ファイルに保存します。例19.2 デュアル E810 NIC の PTP グランドマスタークロック設定
# In this example two cards $iface_nic1 and $iface_nic2 are connected via # SMA1 ports by a cable and $iface_nic2 receives 1PPS signals from $iface_nic1 apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_nic1 -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: enableDefaultConfig: false settings: LocalMaxHoldoverOffSet: 1500 LocalHoldoverTimeout: 14400 MaxInSpecOffset: 1500 pins: $e810_pins # "$iface_nic1": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "2 1" # "$iface_nic2": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "1 1" ublxCmds: - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 - "-P" - "29.20" - "-z" - "CFG-HW-ANT_CFG_VOLTCTRL,1" reportOutput: false - args: #ubxtool -P 29.20 -e GPS - "-P" - "29.20" - "-e" - "GPS" reportOutput: false - args: #ubxtool -P 29.20 -d Galileo - "-P" - "29.20" - "-d" - "Galileo" reportOutput: false - args: #ubxtool -P 29.20 -d GLONASS - "-P" - "29.20" - "-d" - "GLONASS" reportOutput: false - args: #ubxtool -P 29.20 -d BeiDou - "-P" - "29.20" - "-d" - "BeiDou" reportOutput: false - args: #ubxtool -P 29.20 -d SBAS - "-P" - "29.20" - "-d" - "SBAS" reportOutput: false - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000 - "-P" - "29.20" - "-t" - "-w" - "5" - "-v" - "1" - "-e" - "SURVEYIN,600,50000" reportOutput: true - args: #ubxtool -P 29.20 -p MON-HW - "-P" - "29.20" - "-p" - "MON-HW" reportOutput: true - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_nic1] ts2phc.extts_polarity rising ts2phc.extts_correction 0 [$iface_nic2] ts2phc.master 0 ts2phc.extts_polarity rising #this is a measured value in nanoseconds to compensate for SMA cable delay ts2phc.extts_correction -10 ptp4lConf: | [$iface_nic1] masterOnly 1 [$iface_nic1_1] masterOnly 1 [$iface_nic1_2] masterOnly 1 [$iface_nic1_3] masterOnly 1 [$iface_nic2] masterOnly 1 [$iface_nic2_1] masterOnly 1 [$iface_nic2_2] masterOnly 1 [$iface_nic2_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 1 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
# In this example two cards $iface_nic1 and $iface_nic2 are connected via # SMA1 ports by a cable and $iface_nic2 receives 1PPS signals from $iface_nic1 apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: grandmaster namespace: openshift-ptp annotations: {} spec: profile: - name: "grandmaster" ptp4lOpts: "-2 --summary_interval -4" phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_nic1 -n 24 ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" plugins: e810: enableDefaultConfig: false settings: LocalMaxHoldoverOffSet: 1500 LocalHoldoverTimeout: 14400 MaxInSpecOffset: 1500 pins: $e810_pins # "$iface_nic1": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "2 1" # "$iface_nic2": # "U.FL2": "0 2" # "U.FL1": "0 1" # "SMA2": "0 2" # "SMA1": "1 1" ublxCmds: - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 - "-P" - "29.20" - "-z" - "CFG-HW-ANT_CFG_VOLTCTRL,1" reportOutput: false - args: #ubxtool -P 29.20 -e GPS - "-P" - "29.20" - "-e" - "GPS" reportOutput: false - args: #ubxtool -P 29.20 -d Galileo - "-P" - "29.20" - "-d" - "Galileo" reportOutput: false - args: #ubxtool -P 29.20 -d GLONASS - "-P" - "29.20" - "-d" - "GLONASS" reportOutput: false - args: #ubxtool -P 29.20 -d BeiDou - "-P" - "29.20" - "-d" - "BeiDou" reportOutput: false - args: #ubxtool -P 29.20 -d SBAS - "-P" - "29.20" - "-d" - "SBAS" reportOutput: false - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000 - "-P" - "29.20" - "-t" - "-w" - "5" - "-v" - "1" - "-e" - "SURVEYIN,600,50000" reportOutput: true - args: #ubxtool -P 29.20 -p MON-HW - "-P" - "29.20" - "-p" - "MON-HW" reportOutput: true - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248 - "-P" - "29.20" - "-p" - "CFG-MSG,1,38,248" reportOutput: true ts2phcOpts: " " ts2phcConf: | [nmea] ts2phc.master 1 [global] use_syslog 0 verbose 1 logging_level 7 ts2phc.pulsewidth 100000000 #cat /dev/GNSS to find available serial port #example value of gnss_serialport is /dev/ttyGNSS_1700_0 ts2phc.nmea_serialport $gnss_serialport [$iface_nic1] ts2phc.extts_polarity rising ts2phc.extts_correction 0 [$iface_nic2] ts2phc.master 0 ts2phc.extts_polarity rising #this is a measured value in nanoseconds to compensate for SMA cable delay ts2phc.extts_correction -10 ptp4lConf: | [$iface_nic1] masterOnly 1 [$iface_nic1_1] masterOnly 1 [$iface_nic1_2] masterOnly 1 [$iface_nic1_3] masterOnly 1 [$iface_nic2] masterOnly 1 [$iface_nic2_1] masterOnly 1 [$iface_nic2_2] masterOnly 1 [$iface_nic2_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 6 clockAccuracy 0x27 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval -4 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 1 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20 recommend: - profile: "grandmaster" priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Copied! 注記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.yaml
Copy to Clipboard Copied!
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! プロファイルが正しいことを確認します。
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-container
Copy to Clipboard Copied! 出力例
ts2phc[509863.660]: [ts2phc.0.config] nmea delay: 347527248 ns ts2phc[509863.660]: [ts2phc.0.config] ens2f0 extts index 0 at 1705516553.000000000 corr 0 src 1705516553.652499081 diff 0 ts2phc[509863.660]: [ts2phc.0.config] ens2f0 master offset 0 s2 freq -0 I0117 18:35:16.000146 1633226 stats.go:57] state updated for ts2phc =s2 I0117 18:35:16.000163 1633226 event.go:417] dpll State s2, gnss State s2, tsphc state s2, gm state s2, ts2phc[1705516516]:[ts2phc.0.config] ens2f0 nmea_status 1 offset 0 s2 GM[1705516516]:[ts2phc.0.config] ens2f0 T-GM-STATUS s2 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 extts index 0 at 1705516553.000000010 corr -10 src 1705516553.652499081 diff 0 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 master offset 0 s2 freq -0 I0117 18:35:16.016597 1633226 stats.go:57] state updated for ts2phc =s2 phc2sys[509863.719]: [ptp4l.0.config] CLOCK_REALTIME phc offset -6 s2 freq +15441 delay 510 phc2sys[509863.782]: [ptp4l.0.config] CLOCK_REALTIME phc offset -7 s2 freq +15438 delay 502
ts2phc[509863.660]: [ts2phc.0.config] nmea delay: 347527248 ns ts2phc[509863.660]: [ts2phc.0.config] ens2f0 extts index 0 at 1705516553.000000000 corr 0 src 1705516553.652499081 diff 0 ts2phc[509863.660]: [ts2phc.0.config] ens2f0 master offset 0 s2 freq -0 I0117 18:35:16.000146 1633226 stats.go:57] state updated for ts2phc =s2 I0117 18:35:16.000163 1633226 event.go:417] dpll State s2, gnss State s2, tsphc state s2, gm state s2, ts2phc[1705516516]:[ts2phc.0.config] ens2f0 nmea_status 1 offset 0 s2 GM[1705516516]:[ts2phc.0.config] ens2f0 T-GM-STATUS s2 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 extts index 0 at 1705516553.000000010 corr -10 src 1705516553.652499081 diff 0 ts2phc[509863.677]: [ts2phc.0.config] ens7f0 master offset 0 s2 freq -0 I0117 18:35:16.016597 1633226 stats.go:57] state updated for ts2phc =s2 phc2sys[509863.719]: [ptp4l.0.config] CLOCK_REALTIME phc offset -6 s2 freq +15441 delay 510 phc2sys[509863.782]: [ptp4l.0.config] CLOCK_REALTIME phc offset -7 s2 freq +15438 delay 502
Copy to Clipboard Copied!
19.2.5.1. グランドマスタークロックの PtpConfig 設定リファレンス
このリファレンスでは、linuxptp
サービス (ptp4l
、phc2sys
、ts2phc
) をグランドマスタークロックとして設定する PtpConfig
カスタムリソース (CR) の設定オプションを説明します。
PtpConfig CR フィールド | 説明 |
---|---|
|
grandmaster クロック動作用に NIC を設定する
プラグインメカニズムにより、PTP Operator は自動ハードウェア設定を行うことができます。Intel Westport Channel NIC の場合、 |
|
|
|
|
| データを破棄する前に、送信者からの送信 (TX) タイムスタンプを待機する最大時間を指定します。 |
| JBOD 境界クロック時間遅延値を指定します。この値は、ネットワーク時間デバイス間で受け渡される時間値を修正するために使用されます。 |
|
注記
ここにリストされているネットワークインターフェイスがグランドマスターとして設定されており、 |
|
|
|
|
|
任意。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
19.2.5.2. グランドマスタークロッククラスの同期状態のリファレンス
次の表は、PTP グランドマスタークロック (T-GM) の gm.ClockClass
の状態を示しています。クロッククラスの状態では、Primary Reference Time Clock (PRTC) またはその他のタイミングソースに関連する精度と安定性に基づいて T-GM クロックが分類されます。
ホールドオーバー仕様とは、PTP クロックがプライマリータイムソースから更新を受信せずに同期を維持できる時間です。
クロッククラスの状態 | 説明 |
---|---|
|
T-GM クロックは |
|
T-GM クロックは |
|
T-GM クロックは |
|
T-GM クロックは |
詳細は、"Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations を参照してください。
19.2.5.3. 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 に適用する設定と対応しています。以下に例を示します。
ublxCmds: - args: - "-P" - "29.20" - "-z" - "CFG-HW-ANT_CFG_VOLTCTRL,1" - "-z" - "CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>" reportOutput: false
ublxCmds:
- args:
- "-P"
- "29.20"
- "-z"
- "CFG-HW-ANT_CFG_VOLTCTRL,1"
- "-z"
- "CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>"
reportOutput: false
- 1
- 測定された T-GM アンテナ遅延オフセット (ナノ秒単位)。必要な遅延オフセット値を取得するには、外部テスト機器を使用してケーブル遅延を測定する必要があります。
次の表は、同等の ubxtool
コマンドを示しています。
ubxtool コマンド | 説明 |
---|---|
|
アンテナ電圧制御を有効にし、 |
| アンテナが GPS 信号を受信できるようにします。 |
| Galileo GPS 衛星から信号を受信するようにアンテナを設定します。 |
| アンテナが GLONASS GPS 衛星から信号を受信できないようにします。 |
| アンテナが BeiDou GPS 衛星から信号を受信できないようにします。 |
| アンテナが SBAS GPS 衛星から信号を受信できないようにします。 |
| GNSS 受信機のサーベイインプロセスを設定して、初期位置の推定を改善します。最適な結果が得られるまでに最大 24 時間かかる場合があります。 |
| ハードウェアの自動スキャンを 1 回実行し、NIC の状態と構成設定を報告します。 |
19.2.5.4. デュアル 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 のサポートを有効にするには、 |
19.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.15 では、デフォルトで自動うるう秒管理が有効になります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールし、クラスターに PTP グランドマスタークロック (T-GM) を設定した。
手順
PtpConfig
CR の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 24
1 Copy to Clipboard Copied! 注記以前は、過去のうるう秒を考慮するために、
phc2sys
設定 (-O -37
) のオフセット調整が T-GM に必要でした。これは不要になりました。PtpConfig
CR の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!
検証
設定した 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.20
Copy to Clipboard Copied! 出力例
1722509534.4417 UBX-NAV-STATUS: iTOW 384752000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367642864 1722509534.4419 UBX-NAV-TIMELS: iTOW 384752000 version 0 reserved2 0 0 0 srcOfCurrLs 2 currLs 18 srcOfLsChange 2 lsChange 0 timeToLsEvent 70376866 dateOfLsGpsWn 2441 dateOfLsGpsDn 7 reserved2 0 0 0 valid x3 1722509534.4421 UBX-NAV-CLOCK: iTOW 384752000 clkB 784281 clkD 435 tAcc 3 fAcc 215 1722509535.4477 UBX-NAV-STATUS: iTOW 384753000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367643864 1722509535.4479 UBX-NAV-CLOCK: iTOW 384753000 clkB 784716 clkD 435 tAcc 3 fAcc 218
1722509534.4417 UBX-NAV-STATUS: iTOW 384752000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367642864 1722509534.4419 UBX-NAV-TIMELS: iTOW 384752000 version 0 reserved2 0 0 0 srcOfCurrLs 2 currLs 18 srcOfLsChange 2 lsChange 0 timeToLsEvent 70376866 dateOfLsGpsWn 2441 dateOfLsGpsDn 7 reserved2 0 0 0 valid x3 1722509534.4421 UBX-NAV-CLOCK: iTOW 384752000 clkB 784281 clkD 435 tAcc 3 fAcc 215 1722509535.4477 UBX-NAV-STATUS: iTOW 384753000 gpsFix 5 flags 0xdd fixStat 0x0 flags2 0x8 ttff 18261, msss 1367643864 1722509535.4479 UBX-NAV-CLOCK: iTOW 384753000 clkB 784716 clkD 435 tAcc 3 fAcc 218
Copy to Clipboard Copied! 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! 出力例
Do not edit This file is generated automatically by linuxptp-daemon
# Do not edit # This file is generated automatically by linuxptp-daemon #$ 3913697179 #@ 4291747200 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 2303683200 12 # 1 Jan 1973 2335219200 13 # 1 Jan 1974 2366755200 14 # 1 Jan 1975 2398291200 15 # 1 Jan 1976 2429913600 16 # 1 Jan 1977 2461449600 17 # 1 Jan 1978 2492985600 18 # 1 Jan 1979 2524521600 19 # 1 Jan 1980 2571782400 20 # 1 Jul 1981 2603318400 21 # 1 Jul 1982 2634854400 22 # 1 Jul 1983 2698012800 23 # 1 Jul 1985 2776982400 24 # 1 Jan 1988 2840140800 25 # 1 Jan 1990 2871676800 26 # 1 Jan 1991 2918937600 27 # 1 Jul 1992 2950473600 28 # 1 Jul 1993 2982009600 29 # 1 Jul 1994 3029443200 30 # 1 Jan 1996 3076704000 31 # 1 Jul 1997 3124137600 32 # 1 Jan 1999 3345062400 33 # 1 Jan 2006 3439756800 34 # 1 Jan 2009 3550089600 35 # 1 Jul 2012 3644697600 36 # 1 Jul 2015 3692217600 37 # 1 Jan 2017 #h e65754d4 8f39962b aa854a61 661ef546 d2af0bfa
Copy to Clipboard Copied!
19.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 をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をboundary-clock-ptp-config.yaml
ファイルに保存します。PTP 境界クロックの設定例
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: boundary-clock ptp4lOpts: "-2" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | # The interface name is hardware-specific [$iface_slave] masterOnly 0 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 slaveOnly 0 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 0 clock_class_threshold 135 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: boundary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: boundary-clock ptp4lOpts: "-2" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | # The interface name is hardware-specific [$iface_slave] masterOnly 0 [$iface_master_1] masterOnly 1 [$iface_master_2] masterOnly 1 [$iface_master_3] masterOnly 1 [global] # # Default Data Set # twoStepFlag 1 slaveOnly 0 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 0 clock_class_threshold 135 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type BC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: boundary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Copied! 表19.6 PTP 境界クロックの CR 設定オプション CR フィールド 説明 name
PtpConfig
CR の名前。profile
1 つ以上の
profile
オブジェクトの配列を指定します。name
プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
ptp4lOpts
ptp4l
サービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。ptp4lConf
ptp4l
を境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0
はグランドマスタークロックから同期し、ens1f3
は接続されたデバイスを同期します。<interface_1>
同期クロックを受信するインターフェイス。
<interface_2>
synchronization クロックを送信するインターフェイス。
tx_timestamp_timeout
Intel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeout
を50
に設定します。boundary_clock_jbod
Intel Columbiaville 800 Series NIC の場合、
boundary_clock_jbod
が0
に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、boundary_clock_jbod
が1
に設定されていることを確認します。phc2sysOpts
phc2sys
サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。ptpSchedulingPolicy
ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は
SCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。ptpSchedulingPriority
ptpSchedulingPolicy
が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
に設定されます。recommend
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。.recommend.profile
profile
セクションで定義される.recommend.profile
オブジェクト名を指定します。.recommend.priority
0
から99
までの整数値でpriority
を指定します。数値が大きいほど優先度が低くなるため、99
の優先度は10
よりも低くなります。ノードがmatch
フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。.recommend.match
.recommend.match
ルールをnodeLabel
またはnodeName
の値に指定します。.recommend.match.nodeLabel
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
フィールドのkey
でnodeLabel
を設定します。例:node-role.kubernetes.io/worker
。.recommend.match.nodeName
oc 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.yaml
Copy to Clipboard Copied!
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! プロファイルが正しいことを確認します。
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-container
Copy to Clipboard Copied! 出力例
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
Copy to Clipboard Copied!
19.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 つの個別の
PtpConfig
CR を作成します。以下に例を示します。phc2sysOpts
の値を指定して、boundary-clock-ptp-config-nic1.yaml
を作成します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic1 namespace: openshift-ptp spec: profile: - name: "profile1" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | [ens5f1] masterOnly 1 [ens5f0] masterOnly 0 ... phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic1 namespace: openshift-ptp spec: profile: - name: "profile1" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: |
1 [ens5f1] masterOnly 1 [ens5f0] masterOnly 0 ... phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
2 Copy to Clipboard Copied! boundary-clock-ptp-config-nic2.yaml
を作成し、phc2sysOpts
フィールドを完全に削除して、2 番目の NIC のphc2sys
サービスを無効にします。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic2 namespace: openshift-ptp spec: profile: - name: "profile2" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: | [ens7f1] masterOnly 1 [ens7f0] masterOnly 0 ...
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: boundary-clock-ptp-config-nic2 namespace: openshift-ptp spec: profile: - name: "profile2" ptp4lOpts: "-2 --summary_interval -4" ptp4lConf: |
1 [ens7f1] masterOnly 1 [ens7f0] masterOnly 0 ...
Copy to Clipboard Copied! - 1
- 2 番目の NIC の境界クロックとして
ptp4l
を開始するために必要なインターフェイスを指定します。
注記2 番目の NIC で
phc2sys
サービスを無効にするには、2 番目のPtpConfig
CR からphc2sysOpts
フィールドを完全に削除する必要があります。
次のコマンドを実行して、デュアル NIC
PtpConfigCR
を作成します。1 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic1.yaml
$ oc create -f boundary-clock-ptp-config-nic1.yaml
Copy to Clipboard Copied! 2 番目の NIC の PTP を設定する CR を作成します。
oc create -f boundary-clock-ptp-config-nic2.yaml
$ oc create -f boundary-clock-ptp-config-nic2.yaml
Copy to Clipboard Copied!
検証
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-container
Copy to Clipboard Copied! 出力例
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 539
Copy to Clipboard Copied!
19.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 をインストールします。
手順
以下の
PtpConfig
CR を作成してから、YAML をordinary-clock-ptp-config.yaml
ファイルに保存します。PTP 通常クロックの設定例
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ordinary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: ordinary-clock # The interface name is hardware-specific interface: $interface ptp4lOpts: "-2 -s" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | [global] # # Default Data Set # twoStepFlag 1 slaveOnly 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 255 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type OC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: ordinary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: ordinary-clock namespace: openshift-ptp annotations: {} spec: profile: - name: ordinary-clock # The interface name is hardware-specific interface: $interface ptp4lOpts: "-2 -s" phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: "true" ptp4lConf: | [global] # # Default Data Set # twoStepFlag 1 slaveOnly 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 255 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type OC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: ordinary-clock priority: 4 match: - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Copied! 表19.7 PTP 通常クロック CR 設定のオプション CR フィールド 説明 name
PtpConfig
CR の名前。profile
1 つ以上の
profile
オブジェクトの配列を指定します。各プロファイルの名前は一意である必要があります。interface
ptp4l
サービスで使用するネットワークインターフェイスを指定します (例:ens787f1
)。ptp4lOpts
ptp4l
サービスのシステム設定オプションを指定します。たとえば、-2
で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名-i <interface>
およびサービス設定ファイル-f /etc/ptp4l.conf
を含めないでください。このインターフェイスで PTP 高速イベントを使用するには、--summary_interval -4
を追加します。phc2sysOpts
phc2sys
サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator はphc2sys
サービスを開始しません。Intel Columbiaville 800 Series NIC の場合、phc2sysOpts
オプションを-a -r -m -n 24 -N 8 -R 16
に設定します。-m
はメッセージをstdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。ptp4lConf
デフォルトの
/etc/ptp4l.conf
ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。tx_timestamp_timeout
Intel Columbiaville 800 Series NIC の場合、
tx_timestamp_timeout
を50
に設定します。boundary_clock_jbod
Intel Columbiaville 800 Series NIC の場合、
boundary_clock_jbod
を0
に設定します。ptpSchedulingPolicy
ptp4l
とphc2sys
プロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHER
です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO
を使用してください。ptpSchedulingPriority
ptpSchedulingPolicy
が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
に設定されます。recommend
profile
がノードに適用される方法を定義する 1 つ以上のrecommend
オブジェクトの配列を指定します。.recommend.profile
profile
セクションで定義される.recommend.profile
オブジェクト名を指定します。.recommend.priority
通常クロックの
.recommend.priority
を0
に設定します。.recommend.match
.recommend.match
ルールをnodeLabel
またはnodeName
の値に指定します。.recommend.match.nodeLabel
oc get nodes --show-labels
コマンドを使用して、ノードオブジェクトのnode.Labels
フィールドのkey
でnodeLabel
を設定します。例:node-role.kubernetes.io/worker
。.recommend.match.nodeName
oc get nodes
コマンドを使用して、nodeName
をノードオブジェクトのnode.Name
フィールドの値に設定します。compute-1.example.com
はその例です。次のコマンドを実行して、
PtpConfig
CR を作成します。oc create -f ordinary-clock-ptp-config.yaml
$ oc create -f ordinary-clock-ptp-config.yaml
Copy to Clipboard Copied!
検証
PtpConfig
プロファイルがノードに適用されていることを確認します。以下のコマンドを実行して、
openshift-ptp
namespace の Pod の一覧を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! プロファイルが正しいことを確認します。
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-container
Copy to Clipboard Copied! 出力例
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1 I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to: I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------ I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1 I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24 I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
Copy to Clipboard Copied!
19.2.8.1. PTP の通常クロックリファレンスとしての Intel Columbiaville E800 シリーズ NIC
次の表は、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために、PTP リファレンス設定に加える必要がある変更を説明します。クラスターに適用する PtpConfig
カスタムリソース (CR) に変更を加えます。
PTP 設定 | 推奨設定 |
---|---|
|
|
|
|
|
|
phc2sysOpts
の場合、-m
はメッセージを stdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、Prometheus メトリックを生成します。
19.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
の設定は任意です。レイテンシーエラーが発生している場合にのみ必要です。
手順
PtpConfig
CR プロファイルを編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptp
Copy to Clipboard Copied! ptpSchedulingPolicy
とptpSchedulingPriority
フィールドを変更します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSchedulingPolicy: SCHED_FIFO
1 ptpSchedulingPriority: 10
2 Copy to Clipboard Copied! -
保存して終了すると、
PtpConfig
CR に変更が適用されます。
検証
PtpConfig
CR が適用されたlinuxptp-daemon
Pod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! ptp4l
プロセスが、更新されたchrt
FIFO 優先度で実行されていることを確認します。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 chrt
Copy to Clipboard Copied! 出力例
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 -m
Copy to Clipboard Copied!
19.2.10. linuxptp サービスのログフィルタリングの設定
linuxptp
デーモンは、デバッグに使用できるログを生成します。ストレージ容量が制限されている通信業者などのデプロイメントタイプでは、これらのログによりストレージ需要が増大する可能性があります。
ログメッセージの数を減らすために、PtpConfig
カスタムリソース (CR) を設定して、master offset
値をレポートするログメッセージを除外できます。master offset
ログメッセージは、現在のノードのクロックとマスタークロックの違いをナノ秒単位でレポートします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールします。
手順
PtpConfig
CR を編集します。oc edit PtpConfig -n openshift-ptp
$ oc edit PtpConfig -n openshift-ptp
Copy to Clipboard Copied! spec.profile
で、ptpSettings.logReduce
仕様を追加し、値をtrue
に設定します。apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSettings: logReduce: "true"
apiVersion: ptp.openshift.io/v1 kind: PtpConfig metadata: name: <ptp_config_name> namespace: openshift-ptp ... spec: profile: - name: "profile1" ... ptpSettings: logReduce: "true"
Copy to Clipboard Copied! 注記デバッグの目的で、この仕様を
False
に戻すと、マスターオフセットメッセージを含めることができます。-
保存して終了すると、
PtpConfig
CR に変更が適用されます。
検証
PtpConfig
CR が適用されたlinuxptp-daemon
Pod と対応するノードの名前を取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! 次のコマンドを実行して、マスターオフセットメッセージがログから除外されていることを確認します。
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! - 1
- <linux_daemon_container> は、
linuxptp-daemon
Pod の名前です (例:linuxptp-daemon-gmv2n
)。
logReduce
仕様を設定する場合、このコマンドはlinuxptp
デーモンのログにmaster offset
のインスタンスを報告しません。
19.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 wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! 注記PTP 高速イベントバスが有効な場合には、準備できた
linuxptp-daemon
Pod の数は3/3
になります。PTP 高速イベントバスが有効になっていない場合、2/2
が表示されます。サポートされているハードウェアがクラスターにあることを確認します。
oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
$ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io
Copy to Clipboard Copied! 出力例
NAME AGE control-plane-0.example.com 10d control-plane-1.example.com 10d compute-0.example.com 10d compute-1.example.com 10d compute-2.example.com 10d
NAME AGE control-plane-0.example.com 10d control-plane-1.example.com 10d compute-0.example.com 10d compute-1.example.com 10d compute-2.example.com 10d
Copy to Clipboard Copied! ノードで利用可能な 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 yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
- <node_name>
問い合わせるノードを指定します (例:
compute-0.example.com
)。出力例
apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2021-09-14T16:52:33Z" generation: 1 name: compute-0.example.com namespace: openshift-ptp resourceVersion: "177400" uid: 30413db0-4d8d-46da-9bef-737bacd548fd spec: {} status: devices: - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1
apiVersion: ptp.openshift.io/v1 kind: NodePtpDevice metadata: creationTimestamp: "2021-09-14T16:52:33Z" generation: 1 name: compute-0.example.com namespace: openshift-ptp resourceVersion: "177400" uid: 30413db0-4d8d-46da-9bef-737bacd548fd spec: {} status: devices: - name: eno1 - name: eno2 - name: eno3 - name: eno4 - name: enp5s0f0 - name: enp5s0f1
Copy to Clipboard Copied!
対応するノードの
linuxptp-daemon
Pod にアクセスし、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。以下のコマンドを実行して、
linuxptp-daemon
Pod の名前と、トラブルシューティングに使用するノードを取得します。oc get pods -n openshift-ptp -o wide
$ oc get pods -n openshift-ptp -o wide
Copy to Clipboard Copied! 出力例
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.com
Copy to Clipboard Copied! リモートシェルが必要な
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! ここでは、以下のようになります。
- <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! ノードがプライマリークロックに正常に同期されたときの出力例
sending: GET PORT_DATA_SET 40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 40a6b7.fffe.166ef0-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval -3 announceReceiptTimeout 3 logSyncInterval -4 delayMechanism 1 logMinPdelayReqInterval -4 versionNumber 2
sending: GET PORT_DATA_SET 40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 40a6b7.fffe.166ef0-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval -3 announceReceiptTimeout 3 logSyncInterval -4 delayMechanism 1 logMinPdelayReqInterval -4 versionNumber 2
Copy to Clipboard Copied!
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 ens7f0
Copy to Clipboard Copied! 出力例
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.0
Copy to Clipboard Copied! 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/gnss0
Copy to Clipboard Copied! 出力例
$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*62
Copy to Clipboard Copied!
19.2.12. 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-rhel8:v4.15
$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.15
Copy to Clipboard Copied!
19.3. PTP ハードウェア高速イベント通知フレームワークの使用
仮想 RAN (vRAN) などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。Precision Time Protocol (PTP) クロックの同期エラーは、分散ユニット (DU) で実行される vRAN アプリケーションなど、低遅延アプリケーションのパフォーマンスと信頼性に悪影響を及ぼす可能性があります。
19.3.1. PTP およびクロック同期エラーイベントについて
PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークの OTA(Over the Air) トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。
イベント通知は、同じ DU ノード上で実行されている vRAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング (pub-sub メッセージング) は、非同期のサービス間通信アーキテクチャーです。このアーキテクチャーでは、トピックにパブリッシュされたメッセージが、そのトピックのすべてのサブスクライバーによって即座に受信されます。
PTP Operator は、すべての PTP 対応ネットワークインターフェイスの高速イベント通知を生成します。イベントには、HTTP またはアドバンストメッセージキュープロトコル (AMQP) メッセージバス経由で cloud-event-proxy
サイドカーコンテナーを使用してアクセスできます。
PTP 高速イベント通知は、PTP 通常クロック、PTP グランドマスタークロック、または PTP 境界クロックを使用するように設定されたネットワークインターフェイスで使用できます。
HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。
19.3.2. PTP 高速イベント通知フレームワークについて
Precision Time Protocol (PTP) 高速イベント通知フレームワークを使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。
高速イベント通知フレームワークは、通信に REST API を使用します。REST API は、O-RAN ALLIANCE 仕様 から入手できる O-RAN O-Cloud Notification API Specification for Event Consumers 3.0 に基づいています。
このフレームワークは、パブリッシャー、サブスクライバー、および AMQ または HTTP メッセージングプロトコルで構成され、パブリッシャーとサブスクライバーのアプリケーション間の通信を処理します。アプリケーションは、cloud-event-proxy
コンテナーをサイドカーパターンで実行して、PTP イベントをサブスクライブします。cloud-event-proxy
サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。
HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。
図19.4 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 または AMQP 1.0 QPID を介して、アプリケーション Pod 内の
cloud-event-proxy
サイドカーにイベントを転送します。 -
イベントは REST API から入手できます。
-
アプリケーション Pod の
cloud-event-proxy
サイドカーはイベントを処理し、REST API を使用して利用できるようにします。 -
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します
-
コンシューマーアプリケーションは、API 要求をアプリケーション Pod の
cloud-event-proxy
サイドカーに送信して、PTP イベントサブスクリプションを作成します。cloud-event-proxy
サイドカーは、サブスクリプションで指定されたリソースの AMQ または HTTP メッセージングリスナープロトコルを作成します。
アプリケーション Pod の cloud-event-proxy
サイドカーは、PTP Operator が管理する Pod からイベントを受信し、クラウドイベントオブジェクトをラッピング解除してデータを取得し、イベントをコンシューマーアプリケーションにポストします。コンシューマーアプリケーションは、リソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。
19.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
ファイルに保存します。apiVersion: ptp.openshift.io/v1 kind: PtpOperatorConfig metadata: name: default namespace: openshift-ptp spec: daemonNodeSelector: node-role.kubernetes.io/worker: "" ptpEventConfig: enableEventPublisher: true
apiVersion: ptp.openshift.io/v1 kind: PtpOperatorConfig metadata: name: default namespace: openshift-ptp spec: daemonNodeSelector: node-role.kubernetes.io/worker: "" ptpEventConfig: enableEventPublisher: true
1 Copy to Clipboard Copied! - 1
enableEventPublisher
をtrue
に設定して、PTP 高速イベント通知を有効にします。
注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfig
リソースのspec.ptpEventConfig.transportHost
フィールドを設定する必要はありません。PTP イベントに AMQP トランスポートを使用する場合にのみ、transportHost
を設定します。PtpOperatorConfig
CR を更新します。oc apply -f ptp-operatorconfig.yaml
$ oc apply -f ptp-operatorconfig.yaml
Copy to Clipboard Copied!
PTP 対応インターフェイスの
PtpConfig
カスタムリソースを作成し、ptpClockThreshold
およびptp4lOpts
に必要な値を設定します。次の YAML は、PtpConfig
CR で設定する必要のある値 (必須) を示しています。spec: profile: - name: "profile1" interface: "enp5s0f0" ptp4lOpts: "-2 -s --summary_interval -4" phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" ptp4lConf: "" ptpClockThreshold: holdOverTimeout: 5 maxOffsetThreshold: 100 minOffsetThreshold: -100
spec: profile: - name: "profile1" interface: "enp5s0f0" ptp4lOpts: "-2 -s --summary_interval -4"
1 phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
2 ptp4lConf: ""
3 ptpClockThreshold:
4 holdOverTimeout: 5 maxOffsetThreshold: 100 minOffsetThreshold: -100
Copy to Clipboard Copied! - 1
--summary_interval -4
を追加して、PTP 高速イベントを使用します。- 2
phc2sysOpts
の値が必要です。-m
はメッセージをstdout
に出力します。linuxptp-daemon
DaemonSet
はログを解析し、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
に設定されます。
19.3.4. PTP またはベアメタルイベントに HTTP トランスポートを使用するためのコンシューマーアプリケーションの移行
以前に PTP またはベアメタルイベントのコンシューマーアプリケーションをデプロイしている場合は、HTTP メッセージトランスポートを使用するようにアプリケーションを更新する必要があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator または Bare Metal Event Relay を、デフォルトで HTTP トランスポートを使用するバージョン 4.13 以降に更新している。
手順
HTTP トランスポートを使用するようにイベントコンシューマーアプリケーションを更新します。クラウドイベントサイドカーデプロイメントの
http-event-publishers
変数を設定します。たとえば、PTP イベントが設定されているクラスターでは、以下の YAML スニペットはクラウドイベントサイドカーデプロイメントを示しています。
containers: - name: cloud-event-sidecar image: cloud-event-sidecar args: - "--metrics-addr=127.0.0.1:9091" - "--store-path=/store" - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043" - "--api-port=8089"
containers: - name: cloud-event-sidecar image: cloud-event-sidecar args: - "--metrics-addr=127.0.0.1:9091" - "--store-path=/store" - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
1 - "--api-port=8089"
Copy to Clipboard Copied! - 1
- PTP Operator は、PTP イベントを生成するホストに対して
NODE_NAME
を自動的に解決します。compute-1.example.com
はその例です。
ベアメタルイベントが設定されているクラスターでは、クラウドイベントサイドカーデプロイメント CR で
http-event-publishers
フィールドをhw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043
に設定します。consumer-events-subscription-service
サービスをイベントコンシューマーアプリケーションと併せてデプロイします。以下に例を示します。apiVersion: v1 kind: Service metadata: annotations: prometheus.io/scrape: "true" service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret name: consumer-events-subscription-service namespace: cloud-events labels: app: consumer-service spec: ports: - name: sub-port port: 9043 selector: app: consumer clusterIP: None sessionAffinity: None type: ClusterIP
apiVersion: v1 kind: Service metadata: annotations: prometheus.io/scrape: "true" service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret name: consumer-events-subscription-service namespace: cloud-events labels: app: consumer-service spec: ports: - name: sub-port port: 9043 selector: app: consumer clusterIP: None sessionAffinity: None type: ClusterIP
Copy to Clipboard Copied!
19.3.5. AMQ メッセージングバスのインストール
ノードのパブリッシャーとサブスクライバー間で PTP 高速イベント通知を渡すには、ノードでローカルに実行するように AMQ メッセージングバスをインストールおよび設定する必要があります。AMQ メッセージングを使用するには、AMQ Interconnect Operator をインストールする必要があります。
HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。
前提条件
-
OpenShift Container Platform CLI (
oc
) をインストールします。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
AMQ Interconnect Operator を独自の
amq-interconnect
namespace にインストールします。Red Hat Integration - AMQ Interconnect Operator の追加 を参照してください。
検証
AMQ Interconnect Operator が利用可能で、必要な Pod が実行していることを確認します。
oc get pods -n amq-interconnect
$ oc get pods -n amq-interconnect
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
Copy to Clipboard Copied! 必要な
linuxptp-daemon
PTP イベントプロデューサー Pod がopenshift-ptp
namespace で実行していることを確認します。oc get pods -n openshift-ptp
$ oc get pods -n openshift-ptp
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 12h linuxptp-daemon-k8n88 3/3 Running 0 12h
NAME READY STATUS RESTARTS AGE linuxptp-daemon-2t78p 3/3 Running 0 12h linuxptp-daemon-k8n88 3/3 Running 0 12h
Copy to Clipboard Copied!
19.3.6. REST API を使用して PTP イベントに DU アプリケーションをサブスクライブする
リソースアドレス/cluster/node/<node_name>/ptp
を使用して、アプリケーションを PTP イベントにサブスクライブします。ここで、<node_name>
は、DU アプリケーションを実行しているクラスターノードです。
cloud-event-consumer
DU アプリケーションコンテナーと cloud-event-proxy
サイドカーコンテナーを別々の DU アプリケーション Pod にデプロイします。cloud-event-consumer
DU アプリケーションは、アプリケーション Pod のcloud-event-proxy
コンテナーにサブスクライブします。
次の API エンドポイントを使用して、DU アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/
にある cloud-event-proxy
コンテナーによってポストされた PTP イベントに cloud-event-consumer
DU アプリケーションをサブスクライブします。
/api/ocloudNotifications/v1/subscriptions
-
POST
: 新しいサブスクリプションを作成します。 -
GET
: サブスクリプションの一覧を取得します。 -
DELETE
: すべてのサブスクリプションを削除します
-
/api/ocloudNotifications/v1/subscriptions/{subscription_id}
-
GET
: 指定されたサブスクリプション ID の詳細を返します。 -
DELETE
: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
-
/api/ocloudNotifications/v1/health
-
GET
:ocloudNotifications
API の正常性ステータスを返します
-
api/ocloudNotifications/v1/publishers
-
GET
: クラスターノードのos-clock-sync-state
、ptp-clock-class-change
、lock-state
、およびgnss-sync-status
メッセージの配列を返します。
-
/api/ocloudnotifications/v1/{resource_address}/CurrentState
-
GET
:os-clock-sync-state
、ptp-clock-class-change
、lock-state
、またはgnss-state-change
イベントタイプの現在の状態を返します。
-
9089
は、アプリケーション Pod にデプロイされた cloud-event-consumer
コンテナーのデフォルトポートです。必要に応じて、DU アプリケーションに別のポートを設定できます。
19.3.6.1. PTP イベント REST API リファレンス
PTP イベント通知 REST API を使用して、親ノードで生成された PTP イベントにクラスターアプリケーションをサブスクライブします。
19.3.6.1.1. api/ocloudNotifications/v1/subscriptions
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions
説明
サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK
のステータスコードが返されます。
API 応答の例
[ { "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826", "endpointUri": "http://localhost:9089/event", "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826", "resource": "/cluster/node/compute-1.example.com/ptp" } ]
[
{
"id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
"endpointUri": "http://localhost:9089/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
]
HTTP メソッド
POST api/ocloudNotifications/v1/subscriptions
説明
新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created
ステータスコードが返されます。
パラメーター | 型 |
---|---|
subscription | data |
ペイロードの例
{ "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions", "resource": "/cluster/node/compute-1.example.com/ptp" }
{
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
"resource": "/cluster/node/compute-1.example.com/ptp"
}
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions
説明
すべてのサブスクリプションを削除します。
API 応答の例
{ "status": "deleted all subscriptions" }
{
"status": "deleted all subscriptions"
}
19.3.6.1.2. api/ocloudNotifications/v1/subscriptions/{subscription_id}
HTTP メソッド
GET api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID が subscription_id
のサブスクリプションの詳細を返します。
パラメーター | 型 |
---|---|
| string |
API 応答の例
{ "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab", "endpointUri": "http://localhost:9089/event", "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab", "resource":"/cluster/node/compute-1.example.com/ptp" }
{
"id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
"endpointUri": "http://localhost:9089/event",
"uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
"resource":"/cluster/node/compute-1.example.com/ptp"
}
HTTP メソッド
DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}
説明
ID subscription_id
のサブスクリプションを削除します。
パラメーター | 型 |
---|---|
| string |
API 応答の例
{ "status": "OK" }
{
"status": "OK"
}
19.3.6.1.3. api/ocloudNotifications/v1/health
HTTP メソッド
GET api/ocloudNotifications/v1/health/
説明
ocloudNotifications
REST API の正常性ステータスを返します。
API 応答の例
OK
OK
19.3.6.1.4. api/ocloudNotifications/v1/publishers
HTTP メソッド
GET api/ocloudNotifications/v1/publishers
説明
クラスターノードの os-clock-sync-state
、ptp-clock-class-change
、lock-state
、および gnss-sync-status
の詳細の配列を返します。関連する機器の状態が変化すると、システムは通知を生成します。
-
os-clock-sync-state
通知は、ホストオペレーティングシステムのクロック同期状態を示します。有効な状態はLOCKED
またはFREERUN
です。 -
ptp-clock-class-change
通知は、PTP クロッククラスの現在の状態を示します。 -
lock-state
通知は、PTP 機器のロック状態の現在のステータスを示します。有効な状態はLOCKED
、HOLDOVER
またはFREERUN
です。 -
gnss-sync-status
通知は、外部 GNSS クロック信号に関する GPS 同期状態を示します。有効な状態はSYNCHRONIZED
、ANTENNA_DISCONNECTED
、またはACQUIRING_SYNC
です。
機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。
API 応答の例
[ { "id": "0fa415ae-a3cf-4299-876a-589438bacf75", "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy", "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75", "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state" }, { "id": "28cd82df-8436-4f50-bbd9-7a9742828a71", "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy", "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71", "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change" }, { "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677", "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy", "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677", "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state" }, { "id": "778da345d-4567-67b0-a43f0-rty885a456", "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy", "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/778da345d-4567-67b0-a43f0-rty885a456", "resource": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status" } ]
[
{
"id": "0fa415ae-a3cf-4299-876a-589438bacf75",
"endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
"uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
"resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
},
{
"id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
"endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
"uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
"resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
},
{
"id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
"endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
"uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
"resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
},
{
"id": "778da345d-4567-67b0-a43f0-rty885a456",
"endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
"uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/778da345d-4567-67b0-a43f0-rty885a456",
"resource": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status"
}
]
cloud-event-proxy
コンテナーのログには、os-clock-sync-state
、ptp-clock-class-change
、lock-state
、および gnss-sync-status
イベントが含まれています。以下に例を示します。
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-proxy
os-clock-sync-state イベントの例
{ "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5", "type":"event.sync.sync-status.os-clock-sync-state-change", "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME", "dataContentType":"application/json", "time":"2022-05-06T15:31:23.906277159Z", "data":{ "version":"v1", "values":[ { "resource":"/sync/sync-status/os-clock-sync-state", "dataType":"notification", "valueType":"enumeration", "value":"LOCKED" }, { "resource":"/sync/sync-status/os-clock-sync-state", "dataType":"metric", "valueType":"decimal64.3", "value":"-53" } ] } }
{
"id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
"type":"event.sync.sync-status.os-clock-sync-state-change",
"source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
"dataContentType":"application/json",
"time":"2022-05-06T15:31:23.906277159Z",
"data":{
"version":"v1",
"values":[
{
"resource":"/sync/sync-status/os-clock-sync-state",
"dataType":"notification",
"valueType":"enumeration",
"value":"LOCKED"
},
{
"resource":"/sync/sync-status/os-clock-sync-state",
"dataType":"metric",
"valueType":"decimal64.3",
"value":"-53"
}
]
}
}
ptp-clock-class-change イベントの例
{ "id":"69eddb52-1650-4e56-b325-86d44688d02b", "type":"event.sync.ptp-status.ptp-clock-class-change", "source":"/cluster/compute-1.example.com/ptp/ens2fx/master", "dataContentType":"application/json", "time":"2022-05-06T15:31:23.147100033Z", "data":{ "version":"v1", "values":[ { "resource":"/sync/ptp-status/ptp-clock-class-change", "dataType":"metric", "valueType":"decimal64.3", "value":"135" } ] } }
{
"id":"69eddb52-1650-4e56-b325-86d44688d02b",
"type":"event.sync.ptp-status.ptp-clock-class-change",
"source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
"dataContentType":"application/json",
"time":"2022-05-06T15:31:23.147100033Z",
"data":{
"version":"v1",
"values":[
{
"resource":"/sync/ptp-status/ptp-clock-class-change",
"dataType":"metric",
"valueType":"decimal64.3",
"value":"135"
}
]
}
}
lock-state イベントの例
{ "id":"305ec18b-1472-47b3-aadd-8f37933249a9", "type":"event.sync.ptp-status.ptp-state-change", "source":"/cluster/compute-1.example.com/ptp/ens2fx/master", "dataContentType":"application/json", "time":"2022-05-06T15:31:23.467684081Z", "data":{ "version":"v1", "values":[ { "resource":"/sync/ptp-status/lock-state", "dataType":"notification", "valueType":"enumeration", "value":"LOCKED" }, { "resource":"/sync/ptp-status/lock-state", "dataType":"metric", "valueType":"decimal64.3", "value":"62" } ] } }
{
"id":"305ec18b-1472-47b3-aadd-8f37933249a9",
"type":"event.sync.ptp-status.ptp-state-change",
"source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
"dataContentType":"application/json",
"time":"2022-05-06T15:31:23.467684081Z",
"data":{
"version":"v1",
"values":[
{
"resource":"/sync/ptp-status/lock-state",
"dataType":"notification",
"valueType":"enumeration",
"value":"LOCKED"
},
{
"resource":"/sync/ptp-status/lock-state",
"dataType":"metric",
"valueType":"decimal64.3",
"value":"62"
}
]
}
}
gnss-sync-status イベントの例
{ "id": "435e1f2a-6854-4555-8520-767325c087d7", "type": "event.sync.gnss-status.gnss-state-change", "source": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status", "dataContentType": "application/json", "time": "2023-09-27T19:35:33.42347206Z", "data": { "version": "v1", "values": [ { "resource": "/cluster/node/compute-1.example.com/ens2fx/master", "dataType": "notification", "valueType": "enumeration", "value": "SYNCHRONIZED" }, { "resource": "/cluster/node/compute-1.example.com/ens2fx/master", "dataType": "metric", "valueType": "decimal64.3", "value": "5" } ] } }
{
"id": "435e1f2a-6854-4555-8520-767325c087d7",
"type": "event.sync.gnss-status.gnss-state-change",
"source": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
"dataContentType": "application/json",
"time": "2023-09-27T19:35:33.42347206Z",
"data": {
"version": "v1",
"values": [
{
"resource": "/cluster/node/compute-1.example.com/ens2fx/master",
"dataType": "notification",
"valueType": "enumeration",
"value": "SYNCHRONIZED"
},
{
"resource": "/cluster/node/compute-1.example.com/ens2fx/master",
"dataType": "metric",
"valueType": "decimal64.3",
"value": "5"
}
]
}
}
19.3.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/ptp-clock-class-change/CurrentState
説明
クラスターノードの os-clock-sync-state
、ptp-clock-class-change
、lock-state
イベントの現在の状態を返すように CurrentState
API エンドポイントを設定します。
-
os-clock-sync-state
通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKED
またはFREERUN
状態になります。 -
ptp-clock-class-change
通知は、PTP クロッククラスの現在の状態を示します。 -
lock-state
通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED
、HOLDOVER
、またはFREERUN
状態になります。
パラメーター | 型 |
---|---|
| string |
ロック状態 API レスポンスの例
{ "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921", "type": "event.sync.ptp-status.ptp-state-change", "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state", "dataContentType": "application/json", "time": "2023-01-10T02:41:57.094981478Z", "data": { "version": "v1", "values": [ { "resource": "/cluster/node/compute-1.example.com/ens5fx/master", "dataType": "notification", "valueType": "enumeration", "value": "LOCKED" }, { "resource": "/cluster/node/compute-1.example.com/ens5fx/master", "dataType": "metric", "valueType": "decimal64.3", "value": "29" } ] } }
{
"id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
"type": "event.sync.ptp-status.ptp-state-change",
"source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
"dataContentType": "application/json",
"time": "2023-01-10T02:41:57.094981478Z",
"data": {
"version": "v1",
"values": [
{
"resource": "/cluster/node/compute-1.example.com/ens5fx/master",
"dataType": "notification",
"valueType": "enumeration",
"value": "LOCKED"
},
{
"resource": "/cluster/node/compute-1.example.com/ens5fx/master",
"dataType": "metric",
"valueType": "decimal64.3",
"value": "29"
}
]
}
}
os-clock-sync-state API レスポンスの例
{ "specversion": "0.3", "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb", "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state", "type": "event.sync.sync-status.os-clock-sync-state-change", "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state", "datacontenttype": "application/json", "time": "2022-11-29T17:44:22.202Z", "data": { "version": "v1", "values": [ { "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME", "dataType": "notification", "valueType": "enumeration", "value": "LOCKED" }, { "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME", "dataType": "metric", "valueType": "decimal64.3", "value": "27" } ] } }
{
"specversion": "0.3",
"id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
"source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
"type": "event.sync.sync-status.os-clock-sync-state-change",
"subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
"datacontenttype": "application/json",
"time": "2022-11-29T17:44:22.202Z",
"data": {
"version": "v1",
"values": [
{
"resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
"dataType": "notification",
"valueType": "enumeration",
"value": "LOCKED"
},
{
"resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
"dataType": "metric",
"valueType": "decimal64.3",
"value": "27"
}
]
}
}
ptp-clock-class-change API レスポンスの例
{ "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205", "type": "event.sync.ptp-status.ptp-clock-class-change", "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change", "dataContentType": "application/json", "time": "2023-01-10T02:41:56.785673989Z", "data": { "version": "v1", "values": [ { "resource": "/cluster/node/compute-1.example.com/ens5fx/master", "dataType": "metric", "valueType": "decimal64.3", "value": "165" } ] } }
{
"id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
"type": "event.sync.ptp-status.ptp-clock-class-change",
"source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
"dataContentType": "application/json",
"time": "2023-01-10T02:41:56.785673989Z",
"data": {
"version": "v1",
"values": [
{
"resource": "/cluster/node/compute-1.example.com/ens5fx/master",
"dataType": "metric",
"valueType": "decimal64.3",
"value": "165"
}
]
}
}
19.3.7. 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! linuxptp-daemon
コンテナーによって公開された PTP メトリックを確認します。たとえば、以下のコマンドを実行します。curl http://localhost:9091/metrics
sh-4.4# curl http://localhost:9091/metrics
Copy to Clipboard Copied! 出力例
HELP cne_api_events_published Metric to get number of events published by the rest api TYPE cne_api_events_published gauge
# HELP cne_api_events_published Metric to get number of events published by the rest api # TYPE cne_api_events_published gauge cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",status="success"} 1 cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",status="success"} 94 cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",status="success"} 18 cne_api_events_published{address="/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",status="success"} 27
Copy to Clipboard Copied! -
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例:
openshift_ptp_offset_ns
) をコピーします。 - OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
- PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。
19.3.8. 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 ( |
|
19.4. Precision Time Protocol イベントのコンシューマーアプリケーションの開発
ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを使用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションと cloud-event-proxy
コンテナーを別のアプリケーション Pod にデプロイする必要があります。cloud-event-proxy
コンテナーは、PTP Operator Pod からイベントを受信し、これをコンシューマーアプリケーションに渡します。コンシューマーアプリケーションは、REST API を使用して cloud-event-proxy
コンテナーで投稿されたイベントにサブスクライブします。
PTP イベントアプリケーションのデプロイに関する詳細は、PTP 高速イベント通知フレームワークについて を参照してください。
以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。
19.4.1. PTP イベントコンシューマーアプリケーションのリファレンス
PTP イベントコンシューマーアプリケーションには次の機能が必要です。
-
POST
ハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス -
PTP イベントプロデューサーをサブスクライブするための
createSubscription
関数 -
PTP イベントプロデューサーの現在の状態をポーリングする
getCurrentState
関数
次の Go スニペットの例は、これらの要件を示しています。
Go での PTP イベントコンシューマーサーバー関数の例
func server() { http.HandleFunc("/event", getEvent) http.ListenAndServe("localhost:8989", nil) } func getEvent(w http.ResponseWriter, req *http.Request) { defer req.Body.Close() bodyBytes, err := io.ReadAll(req.Body) if err != nil { log.Errorf("error reading event %v", err) } e := string(bodyBytes) if e != "" { processEvent(bodyBytes) log.Infof("received event %s", string(bodyBytes)) } else { w.WriteHeader(http.StatusNoContent) } }
func server() {
http.HandleFunc("/event", getEvent)
http.ListenAndServe("localhost:8989", nil)
}
func getEvent(w http.ResponseWriter, req *http.Request) {
defer req.Body.Close()
bodyBytes, err := io.ReadAll(req.Body)
if err != nil {
log.Errorf("error reading event %v", err)
}
e := string(bodyBytes)
if e != "" {
processEvent(bodyBytes)
log.Infof("received event %s", string(bodyBytes))
} else {
w.WriteHeader(http.StatusNoContent)
}
}
PTP イベントの例 Go の createSubscription 関数
import ( "github.com/redhat-cne/sdk-go/pkg/pubsub" "github.com/redhat-cne/sdk-go/pkg/types" v1pubsub "github.com/redhat-cne/sdk-go/v1/pubsub" ) // Subscribe to PTP events using REST API s1,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state") s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change") s3,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/lock-state") // Create PTP event subscriptions POST func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) { var status int apiPath:= "/api/ocloudNotifications/v1/" localAPIAddr:=localhost:8989 // vDU service API address apiAddr:= "localhost:8089" // event framework API address subURL := &types.URI{URL: url.URL{Scheme: "http", Host: apiAddr Path: fmt.Sprintf("%s%s", apiPath, "subscriptions")}} endpointURL := &types.URI{URL: url.URL{Scheme: "http", Host: localAPIAddr, Path: "event"}} sub = v1pubsub.NewPubSub(endpointURL, resourceAddress) var subB []byte if subB, err = json.Marshal(&sub); err == nil { rc := restclient.New() if status, subB = rc.PostWithReturn(subURL, subB); status != http.StatusCreated { err = fmt.Errorf("error in subscription creation api at %s, returned status %d", subURL, status) } else { err = json.Unmarshal(subB, &sub) } } else { err = fmt.Errorf("failed to marshal subscription for %s", resourceAddress) } return }
import (
"github.com/redhat-cne/sdk-go/pkg/pubsub"
"github.com/redhat-cne/sdk-go/pkg/types"
v1pubsub "github.com/redhat-cne/sdk-go/v1/pubsub"
)
// Subscribe to PTP events using REST API
s1,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state")
s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change")
s3,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/lock-state")
// Create PTP event subscriptions POST
func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) {
var status int
apiPath:= "/api/ocloudNotifications/v1/"
localAPIAddr:=localhost:8989 // vDU service API address
apiAddr:= "localhost:8089" // event framework API address
subURL := &types.URI{URL: url.URL{Scheme: "http",
Host: apiAddr
Path: fmt.Sprintf("%s%s", apiPath, "subscriptions")}}
endpointURL := &types.URI{URL: url.URL{Scheme: "http",
Host: localAPIAddr,
Path: "event"}}
sub = v1pubsub.NewPubSub(endpointURL, resourceAddress)
var subB []byte
if subB, err = json.Marshal(&sub); err == nil {
rc := restclient.New()
if status, subB = rc.PostWithReturn(subURL, subB); status != http.StatusCreated {
err = fmt.Errorf("error in subscription creation api at %s, returned status %d", subURL, status)
} else {
err = json.Unmarshal(subB, &sub)
}
} else {
err = fmt.Errorf("failed to marshal subscription for %s", resourceAddress)
}
return
}
- 1
<node_name>
を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.com
はその例です。
Go の PTP イベントコンシューマー getCurrentState 関数の例
//Get PTP event state for the resource func getCurrentState(resource string) { //Create publisher url := &types.URI{URL: url.URL{Scheme: "http", Host: localhost:8989, Path: fmt.SPrintf("/api/ocloudNotifications/v1/%s/CurrentState",resource}} rc := restclient.New() status, event := rc.Get(url) if status != http.StatusOK { log.Errorf("CurrentState:error %d from url %s, %s", status, url.String(), event) } else { log.Debugf("Got CurrentState: %s ", event) } }
//Get PTP event state for the resource
func getCurrentState(resource string) {
//Create publisher
url := &types.URI{URL: url.URL{Scheme: "http",
Host: localhost:8989,
Path: fmt.SPrintf("/api/ocloudNotifications/v1/%s/CurrentState",resource}}
rc := restclient.New()
status, event := rc.Get(url)
if status != http.StatusOK {
log.Errorf("CurrentState:error %d from url %s, %s", status, url.String(), event)
} else {
log.Debugf("Got CurrentState: %s ", event)
}
}
19.4.2. cloud-event-proxy のデプロイメントとサービス CR を参照する
PTP イベントコンシューマーアプリケーションをデプロイするときは、次の cloud-event-proxy
デプロイメントとサブスクライバサービス CR の例を参考として使用してください。
HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。
HTTP トランスポートを使用した cloud-event-proxy デプロイメントの参照
apiVersion: apps/v1 kind: Deployment metadata: name: event-consumer-deployment namespace: <namespace> labels: app: consumer spec: replicas: 1 selector: matchLabels: app: consumer template: metadata: labels: app: consumer spec: serviceAccountName: sidecar-consumer-sa containers: - name: event-subscriber image: event-subscriber-app - name: cloud-event-proxy-as-sidecar image: openshift4/ose-cloud-event-proxy args: - "--metrics-addr=127.0.0.1:9091" - "--store-path=/store" - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043" - "--api-port=8089" env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: NODE_IP valueFrom: fieldRef: fieldPath: status.hostIP volumeMounts: - name: pubsubstore mountPath: /store ports: - name: metrics-port containerPort: 9091 - name: sub-port containerPort: 9043 volumes: - name: pubsubstore emptyDir: {}
apiVersion: apps/v1
kind: Deployment
metadata:
name: event-consumer-deployment
namespace: <namespace>
labels:
app: consumer
spec:
replicas: 1
selector:
matchLabels:
app: consumer
template:
metadata:
labels:
app: consumer
spec:
serviceAccountName: sidecar-consumer-sa
containers:
- name: event-subscriber
image: event-subscriber-app
- name: cloud-event-proxy-as-sidecar
image: openshift4/ose-cloud-event-proxy
args:
- "--metrics-addr=127.0.0.1:9091"
- "--store-path=/store"
- "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
- "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
- "--api-port=8089"
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
volumeMounts:
- name: pubsubstore
mountPath: /store
ports:
- name: metrics-port
containerPort: 9091
- name: sub-port
containerPort: 9043
volumes:
- name: pubsubstore
emptyDir: {}
AMQ トランスポートを使用した cloud-event-proxy デプロイメントの参照
apiVersion: apps/v1 kind: Deployment metadata: name: cloud-event-proxy-sidecar namespace: cloud-events labels: app: cloud-event-proxy spec: selector: matchLabels: app: cloud-event-proxy template: metadata: labels: app: cloud-event-proxy spec: nodeSelector: node-role.kubernetes.io/worker: "" containers: - name: cloud-event-sidecar image: openshift4/ose-cloud-event-proxy args: - "--metrics-addr=127.0.0.1:9091" - "--store-path=/store" - "--transport-host=amqp://router.router.svc.cluster.local" - "--api-port=8089" env: - name: <node_name> valueFrom: fieldRef: fieldPath: spec.nodeName - name: <node_ip> valueFrom: fieldRef: fieldPath: status.hostIP volumeMounts: - name: pubsubstore mountPath: /store ports: - name: metrics-port containerPort: 9091 - name: sub-port containerPort: 9043 volumes: - name: pubsubstore emptyDir: {}
apiVersion: apps/v1
kind: Deployment
metadata:
name: cloud-event-proxy-sidecar
namespace: cloud-events
labels:
app: cloud-event-proxy
spec:
selector:
matchLabels:
app: cloud-event-proxy
template:
metadata:
labels:
app: cloud-event-proxy
spec:
nodeSelector:
node-role.kubernetes.io/worker: ""
containers:
- name: cloud-event-sidecar
image: openshift4/ose-cloud-event-proxy
args:
- "--metrics-addr=127.0.0.1:9091"
- "--store-path=/store"
- "--transport-host=amqp://router.router.svc.cluster.local"
- "--api-port=8089"
env:
- name: <node_name>
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: <node_ip>
valueFrom:
fieldRef:
fieldPath: status.hostIP
volumeMounts:
- name: pubsubstore
mountPath: /store
ports:
- name: metrics-port
containerPort: 9091
- name: sub-port
containerPort: 9043
volumes:
- name: pubsubstore
emptyDir: {}
cloud-event-proxy サブスクライバーサービスの参照
apiVersion: v1 kind: Service metadata: annotations: prometheus.io/scrape: "true" service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret name: consumer-events-subscription-service namespace: cloud-events labels: app: consumer-service spec: ports: - name: sub-port port: 9043 selector: app: consumer clusterIP: None sessionAffinity: None type: ClusterIP
apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/scrape: "true"
service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret
name: consumer-events-subscription-service
namespace: cloud-events
labels:
app: consumer-service
spec:
ports:
- name: sub-port
port: 9043
selector:
app: consumer
clusterIP: None
sessionAffinity: None
type: ClusterIP
19.4.3. cloud-event-proxy サイドカー REST API から利用可能な PTP イベント
PTP イベントコンシューマーアプリケーションは、以下の PTP タイミングイベントの PTP イベントプロデューサーをポーリングできます。
リソース URI | 説明 |
---|---|
|
現在の PTP 機器のロック状態を説明します。 |
|
ホストオペレーティングシステムのクロック同期状態を説明します。 |
| PTP クロッククラスの現在の状態を説明します。 |
19.4.4. コンシューマーアプリケーションを PTP イベントにサブスクライブする
PTP イベントコンシューマーアプリケーションがイベントをポーリングできるようにするには、アプリケーションをイベントプロデューサーにサブスクライブする必要があります。
19.4.4.1. PTP lock-state イベントのサブスクライブ
PTP lock-state
イベントのサブスクリプションを作成するには、次のペイロードを使用して、http://localhost:8081/api/ocloudNotifications/v1/subscriptions
のクラウドイベント API に POST
アクションを送信します。
{ "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",
}
応答の例
{ "id": "e23473d9-ba18-4f78-946e-401a0caeff90", "endpointUri": "http://localhost:8989/event", "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90", "resource": "/cluster/node/<node_name>/sync/ptp-status/lock-state", }
{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/ptp-status/lock-state",
}
19.4.4.2. PTP os-lock-sync-state イベントのサブスクライブ
PTP os-clock-sync-state
イベントのサブスクリプションを作成するには、次のペイロードを使用して、http://localhost:8081/api/ocloudNotifications/v1/subscriptions
のクラウドイベント API に POST
アクションを送信します。
{ "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",
}
応答の例
{ "id": "e23473d9-ba18-4f78-946e-401a0caeff90", "endpointUri": "http://localhost:8989/event", "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90", "resource": "/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state", }
{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state",
}
19.4.4.3. PTP ptp-lock-class-change イベントのサブスクライブ
PTP ptp-clock-class-change
イベントのサブスクリプションを作成するには、次のペイロードを使用して、http://localhost:8081/api/ocloudNotifications/v1/subscriptions
のクラウドイベント API に POST
アクションを送信します。
{ "endpointUri": "http://localhost:8989/event", "resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change", }
{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change",
}
応答の例
{ "id": "e23473d9-ba18-4f78-946e-401a0caeff90", "endpointUri": "http://localhost:8989/event", "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90", "resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change", }
{
"id": "e23473d9-ba18-4f78-946e-401a0caeff90",
"endpointUri": "http://localhost:8989/event",
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/e23473d9-ba18-4f78-946e-401a0caeff90",
"resource": "/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change",
}
19.4.5. 現在の PTP クロックステータスの取得
ノードの現在の PTP ステータスを取得するには、GET
アクションを以下のイベント REST API のいずれかに送信します。
-
http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/lock-state/CurrentState
-
http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state/CurrentState
-
http://localhost:8081/api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState
応答はクラウドネイティブイベント JSON オブジェクトです。以下に例を示します。
ロック状態 API レスポンスの例
{ "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921", "type": "event.sync.ptp-status.ptp-state-change", "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state", "dataContentType": "application/json", "time": "2023-01-10T02:41:57.094981478Z", "data": { "version": "v1", "values": [ { "resource": "/cluster/node/compute-1.example.com/ens5fx/master", "dataType": "notification", "valueType": "enumeration", "value": "LOCKED" }, { "resource": "/cluster/node/compute-1.example.com/ens5fx/master", "dataType": "metric", "valueType": "decimal64.3", "value": "29" } ] } }
{
"id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
"type": "event.sync.ptp-status.ptp-state-change",
"source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
"dataContentType": "application/json",
"time": "2023-01-10T02:41:57.094981478Z",
"data": {
"version": "v1",
"values": [
{
"resource": "/cluster/node/compute-1.example.com/ens5fx/master",
"dataType": "notification",
"valueType": "enumeration",
"value": "LOCKED"
},
{
"resource": "/cluster/node/compute-1.example.com/ens5fx/master",
"dataType": "metric",
"valueType": "decimal64.3",
"value": "29"
}
]
}
}
19.4.6. PTP イベントコンシューマーアプリケーションがイベントを受信していることの確認
アプリケーション Pod の cloud-event-proxy
コンテナーが PTP イベントを受信していることを確認します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - PTP Operator をインストールして設定している。
手順
アクティブな
linuxptp-daemon
Pod の一覧を取得します。以下のコマンドを実行します。oc get pods -n openshift-ptp
$ oc get pods -n openshift-ptp
Copy to Clipboard Copied! 出力例
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 8h
Copy to Clipboard Copied! 次のコマンドを実行して、必要なコンシューマー側
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/metrics
Copy to Clipboard Copied! ここでは、以下のようになります。
- <linuxptp-daemon>
問い合わせる Pod を指定します (例:
linuxptp-daemon-2t78p
)。出力例
HELP cne_transport_connections_resets Metric to get number of connection resets TYPE cne_transport_connections_resets gauge HELP cne_transport_receiver Metric to get number of receiver created TYPE cne_transport_receiver gauge HELP cne_transport_sender Metric to get number of sender created TYPE cne_transport_sender gauge HELP cne_events_ack Metric to get number of events produced TYPE cne_events_ack gauge HELP cne_events_transport_published Metric to get number of events published by the transport TYPE cne_events_transport_published gauge HELP cne_events_transport_received Metric to get number of events received by the transport TYPE cne_events_transport_received gauge HELP cne_events_api_published Metric to get number of events published by the rest api TYPE cne_events_api_published gauge HELP cne_events_received Metric to get number of events received TYPE cne_events_received gauge HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served. TYPE promhttp_metric_handler_requests_in_flight gauge HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code. TYPE promhttp_metric_handler_requests_total counter
# HELP cne_transport_connections_resets Metric to get number of connection resets # TYPE cne_transport_connections_resets gauge cne_transport_connection_reset 1 # HELP cne_transport_receiver Metric to get number of receiver created # TYPE cne_transport_receiver gauge cne_transport_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 2 cne_transport_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"} 2 # HELP cne_transport_sender Metric to get number of sender created # TYPE cne_transport_sender gauge cne_transport_sender{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1 cne_transport_sender{address="/cluster/node/compute-1.example.com/redfish/event",status="active"} 1 # HELP cne_events_ack Metric to get number of events produced # TYPE cne_events_ack gauge cne_events_ack{status="success",type="/cluster/node/compute-1.example.com/ptp"} 18 cne_events_ack{status="success",type="/cluster/node/compute-1.example.com/redfish/event"} 18 # HELP cne_events_transport_published Metric to get number of events published by the transport # TYPE cne_events_transport_published gauge cne_events_transport_published{address="/cluster/node/compute-1.example.com/ptp",status="failed"} 1 cne_events_transport_published{address="/cluster/node/compute-1.example.com/ptp",status="success"} 18 cne_events_transport_published{address="/cluster/node/compute-1.example.com/redfish/event",status="failed"} 1 cne_events_transport_published{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 18 # HELP cne_events_transport_received Metric to get number of events received by the transport # TYPE cne_events_transport_received gauge cne_events_transport_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 18 cne_events_transport_received{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 18 # HELP cne_events_api_published Metric to get number of events published by the rest api # TYPE cne_events_api_published gauge cne_events_api_published{address="/cluster/node/compute-1.example.com/ptp",status="success"} 19 cne_events_api_published{address="/cluster/node/compute-1.example.com/redfish/event",status="success"} 19 # HELP cne_events_received Metric to get number of events received # TYPE cne_events_received gauge cne_events_received{status="success",type="/cluster/node/compute-1.example.com/ptp"} 18 cne_events_received{status="success",type="/cluster/node/compute-1.example.com/redfish/event"} 18 # HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served. # TYPE promhttp_metric_handler_requests_in_flight gauge promhttp_metric_handler_requests_in_flight 1 # HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code. # TYPE promhttp_metric_handler_requests_total counter promhttp_metric_handler_requests_total{code="200"} 4 promhttp_metric_handler_requests_total{code="500"} 0 promhttp_metric_handler_requests_total{code="503"} 0
Copy to Clipboard Copied!
第20章 External DNS Operator
20.1. External DNS Operator のリリースノート
External DNS Operator は、ExternalDNS
をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。
External DNS Operator は、x86_64
アーキテクチャーでのみサポートされます。
これらのリリースノートでは、OpenShift Container Platform での外部 DNS Operator の開発を追跡しています。
20.1.1. 外部 DNS Operator 1.2.0
External DNS Operator バージョン 1.2.0 では、以下のアドバイザリーを利用できます。
20.1.1.1. 新機能
- External DNS Operator が AWS 共有 VPC をサポートするようになりました。詳細は、共有 VPC を使用して別の AWS アカウントに DNS レコードを作成する を参照してください。
20.1.1.2. バグ修正
-
オペランドの更新ストラテジーが、
Rolling
からRecreate
に変更されました。(OCPBUGS-3630)
20.1.2. External DNS Operator 1.1.1
External DNS Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。利用できます。
20.1.3. External DNS Operator 1.1.0
このリリースには、アップストリームプロジェクトバージョン 0.13.1 からのオペランドのリベースが含まれていました。External DNS Operator バージョン 1.1.0 では、以下のアドバイザリーを利用できます。
20.1.3.1. バグ修正
-
以前は、ExternalDNS Operator がボリュームに空の
defaultMode
値を強制していたため、OpenShift API との競合により更新が随時行われていました。現在は、defaultMode
値は強制されず、オペランドのデプロイは随時更新されなくなりました。(OCPBUGS-2793)
20.1.4. External DNS Operator 1.0.1
External DNS Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。
20.1.5. External DNS Operator 1.0.0
External DNS Operator バージョン 1.0.0 では、以下のアドバイザリーを利用できます。
20.1.5.1. バグ修正
- 以前は、External DNS Operator は、ExternalDNS オペランド Pod のデプロイメント中に制限付き SCC ポリシーの違反に関する警告を発していました。この問題は解決されています。(BZ#2086408)
20.2. OpenShift Container Platform の External DNS Operator
External DNS Operator は、ExternalDNS
をデプロイおよび管理して、外部 DNS プロバイダーから OpenShift Container Platform へのサービスとルートの名前解決を提供します。
20.2.1. External DNS Operator
External DNS Operator は、olm.openshift.io
API グループから External DNS API を実装します。External DNS Operator は、サービス、ルート、外部 DNS プロバイダーを更新します。
前提条件
-
yq
CLI ツールがインストールされている。
手順
OperatorHub からオンデマンドで External DNS Operator をデプロイできます。External DNS Operator をデプロイすると、Subscription
オブジェクトが作成されます。
次のコマンドを実行して、インストールプランの名前を確認します。
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! 出力例
install-zcvlr
install-zcvlr
Copy to Clipboard Copied! 次のコマンドを実行して、インストールプランのステータスが
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! 出力例
Complete
Complete
Copy to Clipboard Copied! 次のコマンドを実行して、
external-dns-operator
デプロイメントのステータスを表示します。oc get -n external-dns-operator deployment/external-dns-operator
$ oc get -n external-dns-operator deployment/external-dns-operator
Copy to Clipboard Copied! 出力例
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE external-dns-operator 1/1 1 1 23h
Copy to Clipboard Copied!
20.2.2. 外部 DNS Operator ログ
oc logs
コマンドを使用して、外部 DNS Operator のログを表示できます。
手順
次のコマンドを実行して、External DNS Operator のログを表示します。
oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator
Copy to Clipboard Copied!
20.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"
20.3. クラウドプロバイダーへの External DNS Operator のインストール
AWS、Azure、GCP などのクラウドプロバイダーに External DNS Operator をインストールできます。
20.3.1. OperatorHub を使用した External DNS Operator のインストール
OpenShift Container Platform OperatorHub を使用して、External DNS Operator をインストールできます。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- External DNS Operator をクリックします。Filter by keyword のテキストボックスまたはフィルターリストを使用して、Operator のリストから External DNS Operator を検索できます。
-
external-dns-operator
namespace を選択します。 - External DNS Operator ページで Install をクリックします。
Install Operator ページで、次のオプションを選択していることを確認してください。
- Update the channel で stable-v1.0 を選択します。
- Installation mode で A specific name on the cluster を選択します。
-
Installed namespace で
external-dns-operator
を選択します。namespaceexternal-dns-operator
が存在しない場合は、Operator のインストール中に作成されます。 - Approval Strategy で Automatic または Manual を選択します。Approval Strategy はデフォルトで Automatic に設定されています。
- Install をクリックします。
Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
検証
Installed Operators ダッシュボードで、External DNS Operator の Status が Succeeded と表示されることを確認します。
20.3.2. CLI を使用した External DNS Operator のインストール
CLI を使用して External DNS Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。 -
OpenShift CLI (
oc
) にログイン済みである。
手順
Namespace
オブジェクトを作成します。Namespace
オブジェクトを定義する YAML ファイルを作成します。namespace.yaml
ファイルの例apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
Copy to Clipboard Copied! 次のコマンドを実行して、
Namespace
オブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yaml
Copy to Clipboard Copied!
OperatorGroup
オブジェクトを作成します。OperatorGroup
オブジェクトを定義する YAML ファイルを作成します。operatorgroup.yaml
ファイルの例apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: external-dns-operator namespace: external-dns-operator spec: upgradeStrategy: Default targetNamespaces: - external-dns-operator
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: external-dns-operator namespace: external-dns-operator spec: upgradeStrategy: Default targetNamespaces: - external-dns-operator
Copy to Clipboard Copied! 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied!
Subscription
オブジェクトを作成します。Subscription
オブジェクトを定義する YAML ファイルを作成します。subscription.yaml
ファイルの例apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: external-dns-operator namespace: external-dns-operator spec: channel: stable-v1 installPlanApproval: Automatic name: external-dns-operator source: redhat-operators sourceNamespace: openshift-marketplace
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: external-dns-operator namespace: external-dns-operator spec: channel: stable-v1 installPlanApproval: Automatic name: external-dns-operator source: redhat-operators sourceNamespace: openshift-marketplace
Copy to Clipboard Copied! 以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied!
検証
次のコマンドを実行して、サブスクリプションからインストールプランの名前を取得します。
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! 次のコマンドを実行して、インストールプランのステータスが
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! 次のコマンドを実行して、
external-dns-operator
Pod のステータスがRunning
であることを確認します。oc -n external-dns-operator get pod
$ oc -n external-dns-operator get pod
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11m
NAME READY STATUS RESTARTS AGE external-dns-operator-5584585fd7-5lwqm 2/2 Running 0 11m
Copy to Clipboard Copied! 次のコマンドを実行して、サブスクリプションのカタログソースが
redhat-operators
であることを確認します。oc -n external-dns-operator get subscription
$ oc -n external-dns-operator get subscription
Copy to Clipboard Copied! 出力例
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-v1
Copy to Clipboard Copied! 次のコマンドを実行して、
external-dns-operator
のバージョンを確認します。oc -n external-dns-operator get csv
$ oc -n external-dns-operator get csv
Copy to Clipboard Copied! 出力例
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> Succeeded
Copy to Clipboard Copied!
20.4. External DNS Operator の設定パラメーター
External DNS Operator には、次の設定パラメーターがあります。
20.4.1. External DNS Operator の設定パラメーター
External DNS Operator には、次の設定パラメーターがあります。
パラメーター | 説明 |
---|---|
| クラウドプロバイダーのタイプを有効にします。 spec: provider: type: AWS aws: credentials: name: aws-access-key
|
|
ドメインごとに DNS ゾーンを指定できます。ゾーンを指定しない場合、 zones: - "myzoneid"
|
|
ドメインごとに AWS ゾーンを指定できます。ドメインを指定しない場合、 domains: - filterType: Include matchType: Exact name: "myzonedomain1.com" - filterType: Include matchType: Pattern pattern: ".*\\.otherzonedomain\\.com"
|
|
DNS レコードのソース ( source: type: Service service: serviceType: - LoadBalancer - ClusterIP labelFilter: matchLabels: external-dns.mydomain.org/publish: "yes" hostnameAnnotation: "Allow" fqdnTemplate: - "{{.Name}}.myzonedomain.com"
source: type: OpenShiftRoute openshiftRouteOptions: routerName: default labelFilter: matchLabels: external-dns.mydomain.org/publish: "yes"
|
20.5. AWS での DNS レコードの作成
External DNS Operator を使用して、AWS および AWS GovCloud で DNS レコードを作成できます。
20.5.1. Red Hat External DNS Operator を使用した AWS のパブリックホストゾーンへの DNS レコードの作成
Red Hat External DNS Operator を使用して、AWS のパブリックホストゾーンに DNS レコードを作成できます。同じ手順を使用して、AWS GovCloud のホストゾーンに DNS レコードを作成できます。
手順
ユーザーを確認してください。ユーザーは、
kube-system
namespace にアクセスできる必要があります。クレデンシャルがない場合は、kube-system
namespace からクレデンシャルを取得すると、クラウドプロバイダークライアントを使用できます。oc whoami
$ oc whoami
Copy to Clipboard Copied! 出力例
system:admin
system:admin
Copy to Clipboard Copied! kube-system
namespace に存在する aws-creds シークレットから値を取得します。export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system --template={{.data.aws_access_key_id}} | base64 -d) export AWS_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! ルートを取得して、ドメインを確認します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! 出力例
openshift-console console console-openshift-console.apps.testextdnsoperator.apacshift.support console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.testextdnsoperator.apacshift.support downloads http edge/Redirect None
openshift-console console console-openshift-console.apps.testextdnsoperator.apacshift.support console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.testextdnsoperator.apacshift.support downloads http edge/Redirect None
Copy to Clipboard Copied! DNS ゾーンのリストを取得して、以前に検出されたルートのドメインに対応するものを検索します。
aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
Copy to Clipboard Copied! 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
Copy to Clipboard Copied! route
ソースのExternalDNS
リソースを作成します。$ cat <<EOF | oc create -f - apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-aws spec: domains: - filterType: Include matchType: Exact name: testextdnsoperator.apacshift.support provider: type: AWS source: type: OpenShiftRoute openshiftRouteOptions: routerName: default EOF
$ cat <<EOF | oc create -f - apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-aws
1 spec: domains: - filterType: Include
2 matchType: Exact
3 name: testextdnsoperator.apacshift.support
4 provider: type: AWS
5 source:
6 type: OpenShiftRoute
7 openshiftRouteOptions: routerName: default
8 EOF
Copy to Clipboard Copied! - 1
- 外部 DNS リソースの名前を定義します。
- 2
- デフォルトでは、すべてのホストゾーンがターゲット候補として選択されます。必要なホストゾーンを追加できます。
- 3
- ターゲットゾーンのドメインは、(正規表現の一致とは対照的に) 完全一致である必要があります。
- 4
- 更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
- 5
AWS Route53DNS
プロバイダーを定義します。- 6
- DNS レコードのソースのオプションを定義します。
- 7
- 以前に指定された DNS プロバイダーで作成される DNS レコードのソースとして OpenShift
route
リソースを定義します。 - 8
- ソースが
OpenShiftRoute
の場合に、OpenShift Ingress Controller 名を指定できます。External DNS Operator は、CNAME レコードの作成時に、そのルーターの正規ホスト名をターゲットとして選択します。
次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。
aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console
Copy to Clipboard Copied!
20.5.2. 共有 VPC を使用して別の AWS アカウントに DNS レコードを作成する
ExternalDNS Operator を使用すると、共有 Virtual Private Cloud (VPC) を使用して別の AWS アカウントに DNS レコードを作成できます。共有 VPC を使用すると、組織は複数のプロジェクトのリソースを共通の VPC ネットワークに接続できます。その後、VPC 共有を使用して、複数の AWS アカウント間で単一の Route 53 インスタンスを使用できます。
前提条件
- 2 つの Amazon AWS アカウントを作成している。1 つは VPC と Route 53 プライベートホストゾーンが設定されたもの (アカウント A)、もう 1 つはクラスターをインストールするためのもの (アカウント B) です。
- アカウント B でアカウント A の Route 53 ホストゾーンに DNS レコードを作成するために、適切な権限を持つ IAM ポリシーと IAM ロールをアカウント A に作成している。
- アカウント B のクラスターをアカウント A の既存の VPC にインストールしている。
- アカウント B のクラスターに ExternalDNS Operator がインストールされている。
手順
次のコマンドを実行して、アカウント B からアカウント A の Route 53 ホストゾーンにアクセスできるように作成した IAM ロールのロール ARN を取得します。
aws --profile account-a iam get-role --role-name user-rol1 | head -1
$ aws --profile account-a iam get-role --role-name user-rol1 | head -1
Copy to Clipboard Copied! 出力例
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1
ROLE arn:aws:iam::1234567890123:role/user-rol1 2023-09-14T17:21:54+00:00 3600 / AROA3SGB2ZRKRT5NISNJN user-rol1
Copy to Clipboard Copied! 次のコマンドを実行して、アカウント A の認証情報で使用するプライベートホストゾーンを特定します。
aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
$ aws --profile account-a route53 list-hosted-zones | grep testextdnsoperator.apacshift.support
Copy to Clipboard Copied! 出力例
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
HOSTEDZONES terraform /hostedzone/Z02355203TNN1XXXX1J6O testextdnsoperator.apacshift.support. 5
Copy to Clipboard Copied! 次のコマンドを実行して、
ExternalDNS
オブジェクトを作成します。cat <<EOF | oc create -f - apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-aws spec: domains: - filterType: Include matchType: Exact name: testextdnsoperator.apacshift.support provider: type: AWS aws: assumeRole: arn: arn:aws:iam::12345678901234:role/user-rol1 source: type: OpenShiftRoute openshiftRouteOptions: routerName: default EOF
$ cat <<EOF | oc create -f - apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-aws spec: domains: - filterType: Include matchType: Exact name: testextdnsoperator.apacshift.support provider: type: AWS aws: assumeRole: arn: arn:aws:iam::12345678901234:role/user-rol1
1 source: type: OpenShiftRoute openshiftRouteOptions: routerName: default EOF
Copy to Clipboard Copied! - 1
- アカウント A に DNS レコードを作成するには、ロール ARN を指定します。
次のコマンドを使用して、OpenShift Container Platform (OCP) ルートに対して作成されたレコードを確認します。
aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console
$ aws --profile account-a route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console-openshift-console
Copy to Clipboard Copied!
20.6. Azure での DNS レコードの作成
External DNS Operator を使用して、Azure 上に DNS レコードを作成できます。
Microsoft Entra Workload ID 対応クラスターまたは Microsoft Azure Government (MAG) リージョンで実行されるクラスターで External DNS Operator を使用することはサポートされていません。
20.6.1. Azure のパブリック DNS ゾーン上で DNS レコードを作成する
Red Hat External DNS Operator を使用して、Azure のパブリック DNS ゾーンに DNS レコードを作成できます。
前提条件
- 管理者権限を持っている。
-
admin
ユーザーの場合、kube-system
namespace にアクセスできる。
手順
クラウドプロバイダークライアントを使用するために、次のコマンドを実行して
kube-system
namespace から認証情報を取得します。CLIENT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_id}} | base64 -d) CLIENT_SECRET=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_secret}} | base64 -d) RESOURCE_GROUP=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_resourcegroup}} | base64 -d) SUBSCRIPTION_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_subscription_id}} | base64 -d) TENANT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_tenant_id}} | base64 -d)
$ CLIENT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_id}} | base64 -d) $ CLIENT_SECRET=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_client_secret}} | base64 -d) $ RESOURCE_GROUP=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_resourcegroup}} | base64 -d) $ SUBSCRIPTION_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_subscription_id}} | base64 -d) $ TENANT_ID=$(oc get secrets azure-credentials -n kube-system --template={{.data.azure_tenant_id}} | base64 -d)
Copy to Clipboard Copied! 次のコマンドを実行して、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! 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! 出力例
openshift-console console console-openshift-console.apps.test.azure.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.azure.example.com downloads http edge/Redirect None
openshift-console console console-openshift-console.apps.test.azure.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.azure.example.com downloads http edge/Redirect None
Copy to Clipboard Copied! 次のコマンドを実行して、DNS ゾーンのリストを取得します。
az network dns zone list --resource-group "${RESOURCE_GROUP}"
$ az network dns zone list --resource-group "${RESOURCE_GROUP}"
Copy to Clipboard Copied! ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-azure.yaml
) を作成します。external-dns-sample-azure.yaml
ファイルの例apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-azure spec: zones: - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com" provider: type: Azure source: openshiftRouteOptions: routerName: default type: OpenShiftRoute
apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-azure
1 spec: zones: - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com"
2 provider: type: Azure
3 source: openshiftRouteOptions:
4 routerName: default
5 type: OpenShiftRoute
6 Copy to Clipboard Copied! 次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。
az network dns record-set list -g "${RESOURCE_GROUP}" -z test.azure.example.com | grep console
$ az network dns record-set list -g "${RESOURCE_GROUP}" -z test.azure.example.com | grep console
Copy to Clipboard Copied! 注記プライベート Azure DNS のホストされたプライベートゾーンにレコードを作成するには、
zones
フィールドの下にプライベートゾーンを指定する必要があります。これにより、プロバイダータイプがExternalDNS
引数のazure-private-dns
に入力されます。
20.7. GCP での DNS レコードの作成
External DNS Operator を使用して、Google Cloud Platform (GCP) 上に DNS レコードを作成できます。
GCP Workload Identity が有効なクラスターで External DNS Operator を使用することはサポートされていません。GCP Workload Identity の詳細は、GCP Workload Identity を参照してください。
20.7.1. GCP のパブリックマネージドゾーン上で DNS レコードを作成する
External DNS Operator を使用して、GCP のパブリックマネージドゾーンに DNS レコードを作成できます。
前提条件
- 管理者権限を持っている。
手順
次のコマンドを実行して、
encoded-gcloud.json
ファイル内のgcp-credentials
シークレットをコピーします。oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json
Copy to Clipboard Copied! 次のコマンドを実行して、Google の認証情報をエクスポートします。
export GOOGLE_CREDENTIALS=decoded-gcloud.json
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
Copy to Clipboard Copied! 次のコマンドを使用して、アカウントをアクティブ化します。
gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
$ gcloud auth activate-service-account <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json
Copy to Clipboard Copied! 次のコマンドを実行して、プロジェクトを設定します。
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! 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! 出力例
openshift-console console console-openshift-console.apps.test.gcp.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.gcp.example.com downloads http edge/Redirect None
openshift-console console console-openshift-console.apps.test.gcp.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.gcp.example.com downloads http edge/Redirect None
Copy to Clipboard Copied! 次のコマンドを実行して、マネージドゾーンのリストを取得します。
gcloud dns managed-zones list | grep test.gcp.example.com
$ gcloud dns managed-zones list | grep test.gcp.example.com
Copy to Clipboard Copied! 出力例
qe-cvs4g-private-zone test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com
Copy to Clipboard Copied! ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-gcp.yaml
) を作成します。external-dns-sample-gcp.yaml
ファイルの例apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-gcp spec: domains: - filterType: Include matchType: Exact name: test.gcp.example.com provider: type: GCP source: openshiftRouteOptions: routerName: default type: OpenShiftRoute
apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-gcp
1 spec: domains: - filterType: Include
2 matchType: Exact
3 name: test.gcp.example.com
4 provider: type: GCP
5 source: openshiftRouteOptions:
6 routerName: default
7 type: OpenShiftRoute
8 Copy to Clipboard Copied! - 1
- 外部 DNS 名を指定します。
- 2
- デフォルトでは、すべてのホストされたゾーンがターゲット候補として選択されます。ホストされたゾーンを含めることができます。
- 3
- ターゲットのドメインは、
name
キーで定義された文字列と一致する必要があります。 - 4
- 更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
- 5
- プロバイダータイプを定義します。
- 6
- DNS レコードのソースのオプションを定義できます。
- 7
- ソースタイプが
OpenShiftRoute
の場合、OpenShift Ingress Controller 名を渡すことができます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。 - 8
route
リソースを GCP DNS レコードのソースとして定義します。
次のコマンドを実行して、OpenShift Container Platform ルートに対して作成された DNS レコードを確認します。
gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
Copy to Clipboard Copied!
20.8. Infoblox での DNS レコードの作成
External DNS Operator を使用して、Infoblox 上に DNS レコードを作成できます。
20.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! 次のコマンドを実行して、ルートのリストを取得します。
oc get routes --all-namespaces | grep console
$ oc get routes --all-namespaces | grep console
Copy to Clipboard Copied! 出力例
openshift-console console console-openshift-console.apps.test.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.example.com downloads http edge/Redirect None
openshift-console console console-openshift-console.apps.test.example.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.test.example.com downloads http edge/Redirect None
Copy to Clipboard Copied! ExternalDNS
オブジェクトを定義する YAML ファイル (例:external-dns-sample-infoblox.yaml
) を作成します。external-dns-sample-infoblox.yaml
ファイルの例apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-infoblox spec: provider: type: Infoblox infoblox: credentials: name: infoblox-credentials gridHost: ${INFOBLOX_GRID_PUBLIC_IP} wapiPort: 443 wapiVersion: "2.3.1" domains: - filterType: Include matchType: Exact name: test.example.com source: type: OpenShiftRoute openshiftRouteOptions: routerName: default
apiVersion: externaldns.olm.openshift.io/v1beta1 kind: ExternalDNS metadata: name: sample-infoblox
1 spec: provider: type: Infoblox
2 infoblox: credentials: name: infoblox-credentials gridHost: ${INFOBLOX_GRID_PUBLIC_IP} wapiPort: 443 wapiVersion: "2.3.1" domains: - filterType: Include matchType: Exact name: test.example.com source: type: OpenShiftRoute
3 openshiftRouteOptions: routerName: default
4 Copy to Clipboard Copied! 次のコマンドを実行して、Infoblox に
ExternalDNS
リソースを作成します。oc create -f external-dns-sample-infoblox.yaml
$ oc create -f external-dns-sample-infoblox.yaml
Copy to Clipboard Copied! Infoblox UI から、
console
ルート用に作成された DNS レコードを確認します。- Data Management → DNS → Zones をクリックします。
- ゾーン名を選択します。
20.9. External DNS Operator でクラスター全体のプロキシーを設定する
クラスター全体のプロキシーを設定した後、Operator Lifecycle Manager (OLM) はデプロイされたすべての Operator に対して、HTTP_PROXY
、HTTPS_PROXY
、および NO_PROXY
環境変数の新しい内容の自動更新をトリガーします。
20.9.1. クラスター全体のプロキシーの認証局を信頼する
External DNS Operator を設定して、クラスター全体のプロキシーの認証局を信頼できます。
手順
次のコマンドを実行して、
external-dns-operator
namespace に CA バンドルを含める config map を作成します。oc -n external-dns-operator create configmap trusted-ca
$ oc -n external-dns-operator create configmap trusted-ca
Copy to Clipboard Copied! 信頼できる CA バンドルを config map に挿入するには、次のコマンドを実行して、
config.openshift.io/inject-trusted-cabundle=true
ラベルを config map に追加します。oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
Copy to Clipboard Copied! 次のコマンドを実行して、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!
検証
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_NAME
Copy to Clipboard Copied! 出力例
trusted-ca
trusted-ca
Copy to Clipboard Copied!
第21章 ネットワークポリシー
21.1. ネットワークポリシーについて
開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。
21.1.1. ネットワークポリシーについて
Kubernetes ネットワークポリシーをサポートするネットワークプラグインを使用するクラスターでは、ネットワーク分離は NetworkPolicy
オブジェクトによって完全に制御されます。OpenShift Container Platform 4.15 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。
- ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワーク化された Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。
-
podSelector
フィールドを{}
に設定せずにnamespaceSelector
フィールドを使用すると、hostNetwork
Pod が含まれません。ネットワークポリシーの作成時にhostNetwork
Pod をターゲットにするには、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
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []
Copy to Clipboard Copied! OpenShift Container Platform Ingress Controller からの接続のみを許可します。
プロジェクトで OpenShift Container Platform Ingress Controller からの接続のみを許可するには、以下の
NetworkPolicy
オブジェクトを追加します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress
Copy to Clipboard Copied! プロジェクト内の Pod からの接続のみを受け入れます。
重要同じ namespace 内の
hostNetwork
Pod からの Ingress 接続を許可するには、allow-from-hostnetwork
ポリシーとallow-same-namespace
ポリシーを一緒に適用する必要があります。Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の
NetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {}
Copy to Clipboard Copied! Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。
特定のラベル (以下の例の
role=frontend
) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様のNetworkPolicy
オブジェクトを追加します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-http-and-https spec: podSelector: matchLabels: role: frontend ingress: - ports: - protocol: TCP port: 80 - protocol: TCP port: 443
Copy to Clipboard Copied! namespace および Pod セレクターの両方を使用して接続を受け入れます。
namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の
NetworkPolicy
オブジェクトを使用できます。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-pod-and-namespace-both spec: podSelector: matchLabels: name: test-pods ingress: - from: - namespaceSelector: matchLabels: project: project_name podSelector: matchLabels: name: test-pods
Copy to Clipboard Copied!
NetworkPolicy
オブジェクトは加算されるものです。つまり、複数の NetworkPolicy
オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。
たとえば、先の例で定義された NetworkPolicy
オブジェクトの場合、同じプロジェト内に allow-same-namespace
と allow-http-and-https
ポリシーの両方を定義することができます。これにより、ラベル role=frontend
の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80
および 443
での接続を受け入れます。
21.1.1.1. allow-from-router ネットワークポリシーの使用
次の NetworkPolicy
を使用して、ルーターの設定に関係なく外部トラフィックを許可します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-router spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-router
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/ingress: ""
podSelector: {}
policyTypes:
- Ingress
- 1
policy-group.network.openshift.io/ingress:""
ラベルは、OpenShift-SDN と OVN-Kubernetes の両方をサポートします。
21.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用
次の allow-from-hostnetwork
NetworkPolicy
オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-hostnetwork spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/host-network: "" podSelector: {} policyTypes: - Ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-hostnetwork
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
policy-group.network.openshift.io/host-network: ""
podSelector: {}
policyTypes:
- Ingress
21.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 から許可する必要のある特定のトラフィックを可能にします。
21.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 つのルールが含まれています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend - from: - podSelector: matchLabels: role: backend
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend - from: - podSelector: matchLabels: role: backend
Copy to Clipboard Copied! 以下のポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchExpressions: - {key: role, operator: In, values: [frontend, backend]}
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy spec: podSelector: {} ingress: - from: - podSelector: matchExpressions: - {key: role, operator: In, values: [frontend, backend]}
Copy to Clipboard Copied! 同じガイドラインが
spec.podSelector
仕様に適用されます。異なるネットワークポリシーに同じingress
ルールまたはegress
ルールがある場合、共通のspec.podSelector
仕様で 1 つのネットワークポリシーを作成する方が効率的な場合があります。たとえば、以下の 2 つのポリシーには異なるルールがあります。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy1 spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy2 spec: podSelector: matchLabels: role: client ingress: - from: - podSelector: matchLabels: role: frontend
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy1 spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy2 spec: podSelector: matchLabels: role: client ingress: - from: - podSelector: matchLabels: role: frontend
Copy to Clipboard Copied! 以下のネットワークポリシーは、上記と同じ 2 つのルールを 1 つのルールとして表現しています。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy3 spec: podSelector: matchExpressions: - {key: role, operator: In, values: [db, client]} ingress: - from: - podSelector: matchLabels: role: frontend
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: policy3 spec: podSelector: matchExpressions: - {key: role, operator: In, values: [db, client]} ingress: - from: - podSelector: matchLabels: role: frontend
Copy to Clipboard Copied! この最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。
21.1.3.1. OVN-Kubernetes の NetworkPolicy CR と外部 IP
OVN-Kubernetes では、NetworkPolicy
カスタムリソース (CR) によって厳密な分離ルールが適用されます。サービスが外部 IP を使用して公開されている場合、トラフィックを許可するように明示的に設定されていない限り、ネットワークポリシーによって他の namespace からのアクセスがブロックされる可能性があります。
namespace をまたいで外部 IP へのアクセスを許可するには、必要な namespace からの Ingress を明示的に許可し、指定されたサービスポートへのトラフィックが許可されるようにする NetworkPolicy
CR を作成します。必要なポートへのトラフィックを許可しなければ、アクセスが制限される可能性があります。
出力例
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: annotations: name: <policy_name> namespace: openshift-ingress spec: ingress: - ports: - port: 80 protocol: TCP - ports: - port: 443 protocol: TCP - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: <my_namespace> podSelector: {} policyTypes: - Ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
annotations:
name: <policy_name>
namespace: openshift-ingress
spec:
ingress:
- ports:
- port: 80
protocol: TCP
- ports:
- port: 443
protocol: TCP
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: <my_namespace>
podSelector: {}
policyTypes:
- Ingress
ここでは、以下のようになります。
<policy_name>
- ポリシーの名前を指定します。
<my_namespace>
- ポリシーがデプロイされる namespace の名前を指定します。
詳細は、「ネットワークポリシーについて」を参照してください。
21.1.4. 次のステップ
- ネットワークポリシーの作成
- オプション: デフォルトネットワークポリシーの定義
21.2. ネットワークポリシーの作成
admin
ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。
21.2.1. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 spec: podSelector: matchLabels: app: mongodb ingress: - from: - podSelector: matchLabels: app: app ports: - protocol: TCP port: 27017
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
21.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>.yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーファイル名を指定します。
作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。
すべての namespace のすべての Pod から Ingress を拒否します。
これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} policyTypes: - Ingress ingress: []
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} policyTypes: - Ingress ingress: []
Copy to Clipboard Copied! 同じ namespace のすべての Pod から Ingress を許可します。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
Copy to Clipboard Copied! 特定の namespace から 1 つの Pod への上りトラフィックを許可する
このポリシーは、
namespace-y
で実行されている Pod からpod-a
というラベルの付いた Pod へのトラフィックを許可します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-traffic-pod spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-traffic-pod spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y
Copy to Clipboard Copied!
ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーファイル名を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default created
Copy to Clipboard Copied!
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。
21.2.3. デフォルトの全拒否ネットワークポリシーの作成
これは基本的なポリシーであり、他のデプロイメントされたネットワークポリシーの設定によって許可されたネットワークトラフィック以外のすべてのクロス Pod ネットワークをブロックします。この手順では、デフォルトの deny-by-default
ポリシーを適用します。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
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
ファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: default spec: podSelector: {} ingress: []
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: default
1 spec: podSelector: {}
2 ingress: []
3 Copy to Clipboard Copied! 次のコマンドを入力して、ポリシーを適用します。
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yaml
Copy to Clipboard Copied! 出力例
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default created
Copy to Clipboard Copied!
21.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
ファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-external namespace: default spec: policyTypes: - Ingress podSelector: matchLabels: app: web ingress: - {}
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-external namespace: default spec: policyTypes: - Ingress podSelector: matchLabels: app: web ingress: - {}
Copy to Clipboard Copied! 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yaml
Copy to Clipboard Copied! 出力例
networkpolicy.networking.k8s.io/web-allow-external created
networkpolicy.networking.k8s.io/web-allow-external created
Copy to Clipboard Copied! このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

21.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
ファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-all-namespaces namespace: default spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: {}
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-all-namespaces namespace: default spec: podSelector: matchLabels: app: web
1 policyTypes: - Ingress ingress: - from: - namespaceSelector: {}
2 Copy to Clipboard Copied! 注記デフォルトでは、
namespaceSelector
の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yaml
Copy to Clipboard Copied! 出力例
networkpolicy.networking.k8s.io/web-allow-all-namespaces created
networkpolicy.networking.k8s.io/web-allow-all-namespaces created
Copy to Clipboard Copied!
検証
次のコマンドを入力して、
default
namespace で 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=80
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをsecondary
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
Copy to Clipboard Copied!
21.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
ファイルに保存します。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-prod namespace: default spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: production
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: web-allow-prod namespace: default spec: podSelector: matchLabels: app: web
1 policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: production
2 Copy to Clipboard Copied! 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yaml
Copy to Clipboard Copied! 出力例
networkpolicy.networking.k8s.io/web-allow-prod created
networkpolicy.networking.k8s.io/web-allow-prod created
Copy to Clipboard Copied!
検証
次のコマンドを入力して、
default
namespace で 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=80
Copy to Clipboard Copied! 次のコマンドを実行して、
prod
namespace を作成します。oc create namespace prod
$ oc create namespace prod
Copy to Clipboard Copied! 次のコマンドを実行して、
prod
namespace にラベルを付けます。oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=production
Copy to Clipboard Copied! 次のコマンドを実行して、
dev
namespace を作成します。oc create namespace dev
$ oc create namespace dev
Copy to Clipboard Copied! 次のコマンドを実行して、
dev
namespace にラベルを付けます。oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testing
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをdev
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
wget: download timed out
wget: download timed out
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをprod
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
Copy to Clipboard Copied!
21.3. ネットワークポリシーの表示
admin
ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。
21.3.1. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 spec: podSelector: matchLabels: app: mongodb ingress: - from: - podSelector: matchLabels: app: app ports: - protocol: TCP port: 27017
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
21.3.2. CLI を使用したネットワークポリシーの表示
namespace のネットワークポリシーを検査できます。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを表示できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。 - ネットワークポリシーが存在する namespace で作業している。
手順
namespace のネットワークポリシーを一覧表示します。
namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
oc get networkpolicy
$ oc get networkpolicy
Copy to Clipboard Copied! オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- 検査するネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
以下に例を示します。
oc describe networkpolicy allow-same-namespace
$ oc describe networkpolicy allow-same-namespace
Copy to Clipboard Copied! oc describe
コマンドの出力Name: allow-same-namespace Namespace: ns1 Created on: 2021-05-24 22:28:56 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: <none> Not affecting egress traffic Policy Types: Ingress
Name: allow-same-namespace Namespace: ns1 Created on: 2021-05-24 22:28:56 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: PodSelector: <none> Not affecting egress traffic Policy Types: Ingress
Copy to Clipboard Copied!
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。
21.4. ネットワークポリシーの編集
admin
ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。
21.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 networkpolicy
Copy to Clipboard Copied! ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトを編集します。
ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
<policy_file>
- ネットワークポリシーを含むファイルの名前を指定します。
ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
oc edit networkpolicy <policy_name> -n <namespace>
$ oc edit networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトが更新されていることを確認します。
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。
21.4.2. サンプル NetworkPolicy オブジェクト
以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-27107 spec: podSelector: matchLabels: app: mongodb ingress: - from: - podSelector: matchLabels: app: app ports: - protocol: TCP port: 27017
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-27107
spec:
podSelector:
matchLabels:
app: mongodb
ingress:
- from:
- podSelector:
matchLabels:
app: app
ports:
- protocol: TCP
port: 27017
21.5. ネットワークポリシーの削除
admin
ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。
21.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! ここでは、以下のようになります。
<policy_name>
- ネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
networkpolicy.networking.k8s.io/default-deny deleted
networkpolicy.networking.k8s.io/default-deny deleted
Copy to Clipboard Copied!
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。
21.6. プロジェクトのデフォルトネットワークポリシーの定義
クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。
21.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.yaml
Copy to Clipboard Copied! -
オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される
template.yaml
ファイルを変更します。 プロジェクトテンプレートは、
openshift-config
namespace に作成する必要があります。変更したテンプレートを読み込みます。oc create -f template.yaml -n openshift-config
$ oc create -f template.yaml -n openshift-config
Copy to Clipboard Copied! 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/cluster
Copy to Clipboard Copied!
spec
セクションを、projectRequestTemplate
およびname
パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名はproject-request
です。カスタムプロジェクトテンプレートを含むプロジェクト設定リソース
apiVersion: config.openshift.io/v1 kind: Project metadata: # ... spec: projectRequestTemplate: name: <template_name> # ...
apiVersion: config.openshift.io/v1 kind: Project metadata: # ... spec: projectRequestTemplate: name: <template_name> # ...
Copy to Clipboard Copied! - 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。
21.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-config
Copy to Clipboard Copied! <project_template>
を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名はproject-request
です。テンプレートでは、各
NetworkPolicy
オブジェクトを要素としてobjects
パラメーターに追加します。objects
パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。以下の例では、
objects
パラメーターのコレクションにいくつかのNetworkPolicy
オブジェクトが含まれます。objects: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: podSelector: {} policyTypes: - Ingress - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress ...
objects: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-same-namespace spec: podSelector: {} ingress: - from: - podSelector: {} - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: podSelector: {} policyTypes: - Ingress - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress ...
Copy to Clipboard Copied! オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
新規プロジェクトを作成します。
oc new-project <project>
$ oc new-project <project>
1 Copy to Clipboard Copied! - 1
<project>
を、作成しているプロジェクトの名前に置き換えます。
新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
oc get networkpolicy
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
Copy to Clipboard Copied!
21.7. ネットワークポリシーを使用したマルチテナント分離の設定
クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。
OpenShift SDN ネットワークプラグインを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。
21.7.1. ネットワークポリシーを使用したマルチテナント分離の設定
他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。
前提条件
-
クラスターが、
NetworkPolicy
オブジェクトをサポートするネットワークプラグイン (mode: NetworkPolicy
が設定された OVN-Kubernetes ネットワークプラグインまたは OpenShift SDN ネットワークプラグインなど) を使用している。このモードは OpenShift SDN のデフォルトです。 -
OpenShift CLI (
oc
) がインストールされている。 -
admin
権限を持つユーザーとしてクラスターにログインしている。
手順
以下の
NetworkPolicy
オブジェクトを作成します。allow-from-openshift-ingress
という名前のポリシー:cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOF
$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress spec: ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: {} policyTypes: - Ingress EOF
Copy to Clipboard Copied! 注記policy-group.network.openshift.io/ingress: ""
は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingress
namespace セレクターラベルを使用できますが、これはレガシーラベルです。allow-from-openshift-monitoring
という名前のポリシー。cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOF
$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress EOF
Copy to Clipboard Copied! allow-same-namespace
という名前のポリシー:cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOF
$ cat << EOF| oc create -f - kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {} EOF
Copy to Clipboard Copied! allow-from-kube-apiserver-operator
という名前のポリシー:cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress EOF
$ cat << EOF| oc create -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-kube-apiserver-operator spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-kube-apiserver-operator podSelector: matchLabels: app: kube-apiserver-operator policyTypes: - Ingress EOF
Copy to Clipboard Copied! 詳細は、新規の New
kube-apiserver-operator
webhook controller validating health of webhook を参照してください。
オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。
oc describe networkpolicy
$ oc describe networkpolicy
Copy to Clipboard Copied! 出力例
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: policy-group.network.openshift.io/ingress: Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
Name: allow-from-openshift-ingress Namespace: example1 Created on: 2020-06-09 00:28:17 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: policy-group.network.openshift.io/ingress: Not affecting egress traffic Policy Types: Ingress Name: allow-from-openshift-monitoring Namespace: example1 Created on: 2020-06-09 00:29:57 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: <none> (Allowing the specific traffic to all pods in this namespace) Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: NamespaceSelector: network.openshift.io/policy-group: monitoring Not affecting egress traffic Policy Types: Ingress
Copy to Clipboard Copied!
21.7.2. 次のステップ
第22章 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 アドレスサブネット範囲を含めないでください。
22.1. Machine CIDR
マシンの Classless Inter-Domain Routing (CIDR) フィールドでは、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。
クラスターの作成後にマシンの CIDR 範囲を変更することはできません。
デフォルトは 10.0.0.0/16
です。この範囲は、接続されているネットワークと競合しないようにする必要があります。
22.2. Service CIDR
Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16
です。
22.3. Pod CIDR
Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。
Pod CIDR は、clusterNetwork
CIDR およびクラスター CIDR と同じです。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14
です。クラスターをインストールした後に、範囲を拡張できます。
22.4. ホスト接頭辞
Host Prefix フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。
例えば、ホスト接頭辞を /23
に設定した場合、各マシンには Pod CIDR アドレス範囲から /23
のサブネットが割り当てられます。デフォルトは /23
で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。
第23章 AWS Load Balancer Operator
23.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 をサポートしていません。
23.1.1. AWS Load Balancer Operator 1.1.1
AWS Load Balancer Operator バージョン 1.1.1 では、以下のアドバイザリーを利用できます。
23.1.2. 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 では、以下のアドバイザリーを利用できます。
23.1.2.1. 大きな変更
- このリリースでは、Kubernetes API バージョン 0.27.2 を使用します。
23.1.2.2. 新機能
- AWS Load Balancer Operator は、Cloud Credential Operator を使用して標準化された Security Token Service (STS) フローをサポートするようになりました。
23.1.2.3. バグ修正
FIPS 準拠のクラスターでは、TLS バージョン 1.2 を使用する必要があります。以前は、AWS Load Balancer Controller の Webhook は最小バージョンとして TLS 1.3 のみを受け入れていたため、FIPS 準拠のクラスターで次のようなエラーが発生しました。
remote error: tls: protocol version not supported
remote error: tls: protocol version not supported
Copy to Clipboard Copied! 現在、AWS Load Balancer Controller は TLS 1.2 を最小 TLS バージョンとして受け入れ、この問題は解決されています。(OCPBUGS-14846)
23.1.3. AWS Load Balancer Operator 1.0.1
AWS Load Balancer Operator バージョン 1.0.1 では、以下のアドバイザリーを利用できます。
23.1.4. 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 を削除する必要があります。
23.1.4.1. 大きな変更
-
このリリースでは、新しい
v1
API バージョンを使用しています。
23.1.4.2. バグ修正
- 以前のバージョンでは、AWS Load Balancer Operator によってプロビジョニングされたコントローラーは、クラスター全体のプロキシー設定を適切に使用しませんでした。これらの設定は、コントローラーに正しく適用されるようになりました。(OCPBUGS-4052、OCPBUGS-5295)
23.1.5. 以前のバージョン
AWS Load Balancer Operator の最初の 2 つのバージョンは、テクノロジープレビュー機能として利用できます。これらのバージョンは、実稼働クラスターで使用しないでください。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
AWS Load Balancer Operator バージョン 0.2.0 では、以下のアドバイザリーを利用できます。
AWS Load Balancer Operator バージョン 0.0.1 では、以下のアドバイザリーを利用できます。
23.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 をインストールできます。
23.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 を設定しておくようにしてください。
23.2.2. AWS Load Balancer Operator
AWS Load Balancer Operator は kubernetes.io/role/elb
タグがない場合に、パブリックサブネットにタグを付けることができます。また、AWS Load Balancer Operator は、基盤となる AWS クラウドから次の情報を検出します。
- Operator をホストするクラスターがデプロイされる仮想プライベートクラウド (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! 出力例
install-zlfbt
install-zlfbt
Copy to Clipboard Copied! 次のコマンドを実行して、インストールプランのステータスが
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! 出力例
Complete
Complete
Copy to Clipboard Copied! 次のコマンドを実行して、
aws-load-balancer-operator-controller-manager
デプロイメントのステータスを表示します。oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
$ oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager
Copy to Clipboard Copied! 出力例
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23h
NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-operator-controller-manager 1/1 1 1 23h
Copy to Clipboard Copied!
23.2.3. Outpost に拡張された AWS VPC クラスターでの AWS Load Balancer Operator の使用
Outpost に拡張された AWS VPC クラスター内で AWS Application Load Balancer をプロビジョニングするように AWS Load Balancer Operator を設定できます。AWS Outposts は AWS Network Load Balancer をサポートしていません。そのため、AWS Load Balancer Operator は Outpost に Network Load Balancer をプロビジョニングできません。
AWS Application Load Balancer は、クラウドサブネットか Outpost サブネットのどちらかに作成できます。クラウドの Application Load Balancer はクラウドベースのコンピュートノードに接続でき、Outpost の Application Load Balancer はエッジコンピュートノードに接続できます。Ingress リソースには Outpost サブネットまたは VPC サブネットのアノテーションを付ける必要がありますが、両方を付けることはできません。
前提条件
- AWS VPC クラスターを Outpost に拡張した。
-
OpenShift CLI (
oc
) がインストールされている。 - AWS Load Balancer Operator をインストールし、AWS Load Balancer Controller を作成した。
手順
指定のサブネットを使用するように
Ingress
リソースを設定します。Ingress
リソース設定の例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <application_name> annotations: alb.ingress.kubernetes.io/subnets: <subnet_id> spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: <application_name> port: number: 80
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <application_name> annotations: alb.ingress.kubernetes.io/subnets: <subnet_id>
1 spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: <application_name> port: number: 80
Copy to Clipboard Copied! - 1
- 使用するサブネットを指定します。
- Outpost で Application Load Balancer を使用するには、Outpost のサブネット ID を指定します。
- クラウドで Application Load Balancer を使用するには、別々のアベイラビリティーゾーンに少なくとも 2 つのサブネットを指定する必要があります。
23.2.4. AWS Load Balancer Operator ログ
oc logs
コマンドを使用して、AWS Load Balancer Operator のログを表示できます。
手順
次のコマンドを実行して、AWS Load Balancer Operator のログを表示します。
oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager
Copy to Clipboard Copied!
23.3. AWS Load Balancer Operator のインストール
AWS Load Balancer Operator は、AWS Load Balancer Controller をデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から AWS Load Balancer Operator をインストールできます。
23.3.1. Web コンソールを使用した AWS Load Balancer Operator のインストール
Web コンソールを使用して、AWS Load Balancer Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。 - クラスターのプラットフォームタイプとクラウドプロバイダーが AWS に設定されている。
- セキュリティートークンサービス (STS) または user-provisioned infrastructure を使用している場合は、関連する準備手順に従います。たとえば、AWS Security Token Service を使用している場合は、「AWS Security Token Service (STS) を使用してクラスター上で AWS Load Balancer Operator を準備する」を参照してください。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub に移動します。
- AWS Load Balancer Operator を選択します。Filter by keyword テキストボックスを使用するか、フィルターリストを使用して、Operator のリストから AWS Load Balancer Operator を検索できます。
-
aws-load-balancer-operator
namespace を選択します。 Install Operator ページで、次のオプションを選択します。
- Update the channel で stable-v1 を選択します。
- Installation mode で All namespaces on the cluster (default) を選択します。
-
Installed Namespace で
aws-load-balancer-operator
を選択します。aws-load-balancer-operator
namespace が存在しない場合は、Operator のインストール中に作成されます。 - Update approval で Automatic または Manual を選択します。デフォルトでは、Update approval は Automatic に設定されています。Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように更新要求を手動で承認する必要があります。
- Install をクリックします。
検証
- AWS Load Balancer Operator で、インストール済み Operator ダッシュボードの Status が Succeeded と表示されることを確認します。
23.3.2. CLI を使用した AWS Load Balancer Operator のインストール
CLI を使用して AWS Load Balancer Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインしている。 - クラスターのプラットフォームタイプとクラウドプロバイダーが AWS に設定されている。
-
OpenShift CLI (
oc
) にログイン済みである。
手順
Namespace
オブジェクトを作成します。Namespace
オブジェクトを定義する YAML ファイルを作成します。namespace.yaml
ファイルの例apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
Copy to Clipboard Copied! 次のコマンドを実行して、
Namespace
オブジェクトを作成します。oc apply -f namespace.yaml
$ oc apply -f namespace.yaml
Copy to Clipboard Copied!
OperatorGroup
オブジェクトを作成します。OperatorGroup
オブジェクトを定義する YAML ファイルを作成します。operatorgroup.yaml
ファイルの例apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: aws-lb-operatorgroup namespace: aws-load-balancer-operator spec: upgradeStrategy: Default
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: aws-lb-operatorgroup namespace: aws-load-balancer-operator spec: upgradeStrategy: Default
Copy to Clipboard Copied! 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied!
Subscription
オブジェクトを作成します。Subscription
オブジェクトを定義する YAML ファイルを作成します。subscription.yaml
ファイルの例apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: channel: stable-v1 installPlanApproval: Automatic name: aws-load-balancer-operator source: redhat-operators sourceNamespace: openshift-marketplace
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: channel: stable-v1 installPlanApproval: Automatic name: aws-load-balancer-operator source: redhat-operators sourceNamespace: openshift-marketplace
Copy to Clipboard Copied! 以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied!
検証
サブスクリプションからインストールプランの名前を取得します。
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! インストールプランのステータスを確認します。
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! 出力は
Complete
でなければなりません。
23.4. AWS Security Token Service を使用したクラスター上の AWS Load Balancer Operator の準備
STS を使用するクラスターに AWS Load Balancer Operator をインストールできます。Operator をインストールする前に、次の手順に従ってクラスターを準備します。
AWS Load Balancer Operator は、CredentialsRequest
オブジェクトに依存して Operator と AWS Load Balancer Controller をブートストラップします。AWS Load Balancer Operator は、必要なシークレットが作成されて利用可能になるまで待機します。
23.4.1. AWS Load Balancer Operator 用の IAM ロールの作成
STS を使用するクラスターに AWS Load Balancer Operator を正常にインストールするには、追加の AWS アイデンティティーおよびアクセス管理 (IAM) ロールが必要です。この IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために必要です。AWS Load Balancer Operator は、自身をブートストラップするために IAM ロールを持つ CredentialsRequest
オブジェクトを生成します。
IAM ロールは次の方法で作成できます。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) と定義済みのCredentialsRequest
オブジェクトを使用します。 - AWS CLI と事前定義された AWS マニフェストを使用します。
環境が ccoctl
コマンドをサポートしていない場合は、AWS CLI を使用します。
23.4.1.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 <credrequests-dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml
$ curl --create-dirs -o <credrequests-dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml
Copy to Clipboard Copied! ccoctl
ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credrequests-dir> \ --identity-provider-arn <oidc-arn>
$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credrequests-dir> \ --identity-provider-arn <oidc-arn>
Copy to Clipboard Copied! 出力例
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/<credrequests-dir>/manifests/aws-load-balancer-operator-aws-load-balancer-operator-credentials.yaml 2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-operator created
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-operator created
1 2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credrequests-dir>/manifests/aws-load-balancer-operator-aws-load-balancer-operator-credentials.yaml 2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-operator created
Copy to Clipboard Copied! - 1
- AWS IAM ロールの Amazon Resource Name (ARN) をメモします。
注記AWS IAM ロール名の長さは 12 文字以下にする必要があります。
23.4.1.2. AWS CLI を使用して AWS IAM ロールを作成する
AWS コマンドラインインターフェイスを使用して、AWS Load Balancer Operator 用の IAM ロールを作成できます。IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。
前提条件
-
AWS コマンドラインインターフェイス (
aws
) にアクセスできる。
手順
次のコマンドを実行して、アイデンティティープロバイダーを使用して信頼ポリシーファイルを生成します。
cat <<EOF > albo-operator-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::777777777777:oidc-provider/<oidc-provider-id>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<oidc-provider-id>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" } } } ] } EOF
$ cat <<EOF > albo-operator-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::777777777777:oidc-provider/<oidc-provider-id>"
1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<oidc-provider-id>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager"
2 } } } ] } EOF
Copy to Clipboard Copied! 次のコマンドを実行して、生成された信頼ポリシーを使用して IAM ロールを作成します。
aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
$ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json
Copy to Clipboard Copied! 出力例
ROLE arn:aws:iam::777777777777: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:777777777777:oidc-provider/<oidc-provider-id>
ROLE arn:aws:iam::777777777777:role/albo-operator 2023-08-02T12:13:22Z
1 ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-manager PRINCIPAL arn:aws:iam:777777777777:oidc-provider/<oidc-provider-id>
Copy to Clipboard Copied! - 1
- 作成した IAM ロールの ARN をメモします。
次のコマンドを実行して、AWS Load Balancer Operator の権限ポリシーをダウンロードします。
curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json
$ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json
Copy to Clipboard Copied! 次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーを IAM ロールに割り当てます。
aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.json
$ aws iam put-role-policy --role-name albo-operator --policy-name perms-policy-albo-operator --policy-document file://albo-operator-permission-policy.json
Copy to Clipboard Copied!
23.4.2. AWS Load Balancer Operator 用の ARN ロールの設定
AWS Load Balancer Operator 用の Amazon Resource Name (ARN) ロールを環境変数として設定できます。CLI を使用して ARN ロールを設定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、
aws-load-balancer-operator
プロジェクトを作成します。oc new-project aws-load-balancer-operator
$ oc new-project aws-load-balancer-operator
Copy to Clipboard Copied! 以下のコマンドを実行して
OperatorGroup
オブジェクトを作成します。cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: targetNamespaces: [] EOF
$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: targetNamespaces: [] EOF
Copy to Clipboard Copied! 以下のコマンドを実行して
Subscription
オブジェクトを作成します。cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: channel: stable-v1 name: aws-load-balancer-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: ROLEARN value: "<role-arn>" EOF
$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: aws-load-balancer-operator namespace: aws-load-balancer-operator spec: channel: stable-v1 name: aws-load-balancer-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: ROLEARN value: "<role-arn>"
1 EOF
Copy to Clipboard Copied! - 1
- AWS Load Balancer Operator の AWS 認証情報をプロビジョニングするために
CredentialsRequest
で使用する ARN ロールを指定します。
注記AWS Load Balancer Operator は、シークレットが作成されるまで待機してから、
Available
ステータスに移行します。
23.4.3. AWS Load Balancer Controller 用の IAM ロールの作成
AWS Load Balancer Controller の CredentialsRequest
オブジェクトは、手動でプロビジョニングした IAM ロールを使用して設定する必要があります。
IAM ロールは次の方法で作成できます。
-
Cloud Credential Operator ユーティリティー (
ccoctl
) と定義済みのCredentialsRequest
オブジェクトを使用します。 - AWS CLI と事前定義された AWS マニフェストを使用します。
環境が ccoctl
コマンドをサポートしていない場合は、AWS CLI を使用します。
23.4.3.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 <credrequests-dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml
$ curl --create-dirs -o <credrequests-dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml
Copy to Clipboard Copied! ccoctl
ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credrequests-dir> \ --identity-provider-arn <oidc-arn>
$ ccoctl aws create-iam-roles \ --name <name> \ --region=<aws_region> \ --credentials-requests-dir=<credrequests-dir> \ --identity-provider-arn <oidc-arn>
Copy to Clipboard Copied! 出力例
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/<credrequests-dir>/manifests/aws-load-balancer-operator-aws-load-balancer-controller-credentials.yaml 2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-controller created
2023/09/12 11:38:57 Role arn:aws:iam::777777777777:role/<name>-aws-load-balancer-operator-aws-load-balancer-controller created
1 2023/09/12 11:38:57 Saved credentials configuration to: /home/user/<credrequests-dir>/manifests/aws-load-balancer-operator-aws-load-balancer-controller-credentials.yaml 2023/09/12 11:38:58 Updated Role policy for Role <name>-aws-load-balancer-operator-aws-load-balancer-controller created
Copy to Clipboard Copied! - 1
- AWS IAM ロールの Amazon Resource Name (ARN) をメモします。
注記AWS IAM ロール名の長さは 12 文字以下にする必要があります。
23.4.3.2. AWS CLI を使用してコントローラー用の AWS IAM ロールを作成する
AWS コマンドラインインターフェイスを使用して、AWS Load Balancer Controller 用の AWS IAM ロールを作成できます。AWS IAM ロールは、サブネットおよび Virtual Private Cloud (VPC) と対話するために使用されます。
前提条件
-
AWS コマンドラインインターフェイス (
aws
) にアクセスできる。
手順
次のコマンドを実行して、アイデンティティプロバイダーを使用して信頼ポリシーファイルを生成します。
cat <<EOF > albo-controller-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::777777777777:oidc-provider/<oidc-provider-id>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<oidc-provider-id>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster" } } } ] } EOF
$ cat <<EOF > albo-controller-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::777777777777:oidc-provider/<oidc-provider-id>"
1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<oidc-provider-id>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"
2 } } } ] } EOF
Copy to Clipboard Copied! 次のコマンドを実行して、生成された信頼ポリシーを使用して AWS IAM ロールを作成します。
aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
$ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json
Copy to Clipboard Copied! 出力例
ROLE arn:aws:iam::777777777777: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-controller-cluster PRINCIPAL arn:aws:iam:777777777777:oidc-provider/<oidc-provider-id>
ROLE arn:aws:iam::777777777777:role/albo-controller 2023-08-02T12:13:22Z
1 ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster PRINCIPAL arn:aws:iam:777777777777:oidc-provider/<oidc-provider-id>
Copy to Clipboard Copied! - 1
- AWS IAM ロールの ARN をメモします。
次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーをダウンロードします。
curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json
$ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json
Copy to Clipboard Copied! 次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーを AWS IAM ロールに割り当てます。
aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.json
$ aws iam put-role-policy --role-name albo-controller --policy-name perms-policy-albo-controller --policy-document file://albo-controller-permission-policy.json
Copy to Clipboard Copied! AWSLoadBalancerController
オブジェクトを定義する YAML ファイルを作成します。sample-aws-lb-manual-creds.yaml
ファイルの例:apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: credentialsRequestConfig: stsIAMRoleARN: <role-arn>
apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController
1 metadata: name: cluster
2 spec: credentialsRequestConfig: stsIAMRoleARN: <role-arn>
3 Copy to Clipboard Copied!
23.5. AWS Load Balancer Controller のインスタンスを作成する
AWS Load Balancer Operator をインストールしたら、AWS Load Balancer Controller を作成できます。
23.5.1. AWS Load Balancer Controller の作成
クラスターにインストールできる AWSLoadBalancerController
オブジェクトのインスタンスは 1 つだけです。CLI を使用して AWS Load Balancer Controller を作成できます。AWS Load Balancer Operator は、cluster
という名前のリソースのみを調整します。
前提条件
-
echoserver
namespace を作成している。 -
OpenShift CLI (
oc
) にアクセスできる。
手順
AWSLoadBalancerController
オブジェクトを定義する YAML ファイルを作成します。sample-aws-lb.yaml
ファイルの例apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: subnetTagging: Auto additionalResourceTags: - key: example.org/security-scope value: staging ingressClass: alb config: replicas: 2 enabledAddons: - AWSWAFv2
apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController
1 metadata: name: cluster
2 spec: subnetTagging: Auto
3 additionalResourceTags:
4 - key: example.org/security-scope value: staging ingressClass: alb
5 config: replicas: 2
6 enabledAddons:
7 - AWSWAFv2
8 Copy to Clipboard Copied! - 1
AWSLoadBalancerController
オブジェクトを定義します。- 2
- AWS Load Balancer Controller 名を定義します。このインスタンス名は、関連するすべてのリソースの接尾辞として追加されます。
- 3
- AWS Load Balancer Controller のサブネットのタグ付け方法を設定します。次の値が有効です。
-
Auto
: AWS Load Balancer Operator は、クラスターに属するサブネットを決定し、適切にタグ付けします。内部サブネットタグが内部サブネットに存在しない場合、Operator はロールを正しく判別できません。 -
Manual
: クラスターに属するサブネットに適切なロールタグを手動でタグ付けします。ユーザー提供のインフラストラクチャーにクラスターをインストールした場合は、このオプションを使用します。
-
- 4
- AWS Load Balancer Controller が AWS リソースをプロビジョニングするときに使用するタグを定義します。
- 5
- Ingress クラス名を定義します。デフォルト値は
alb
です。 - 6
- AWS Load Balancer Controller のレプリカの数を指定します。
- 7
- AWS Load Balancer Controller のアドオンとしてアノテーションを指定します。
- 8
alb.ingress.kubernetes.io/wafv2-acl-arn
アノテーションを有効にします。
次のコマンドを実行して、
AWSLoadBalancerController
オブジェクトを作成します。oc create -f sample-aws-lb.yaml
$ oc create -f sample-aws-lb.yaml
Copy to Clipboard Copied! Deployment
リソースを定義する YAML ファイルを作成します。sample-aws-lb.yaml
ファイルの例apiVersion: apps/v1 kind: Deployment metadata: name: <echoserver> namespace: echoserver spec: selector: matchLabels: app: echoserver replicas: 3 template: metadata: labels: app: echoserver spec: containers: - image: openshift/origin-node command: - "/bin/socat" args: - TCP4-LISTEN:8080,reuseaddr,fork - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"' imagePullPolicy: Always name: echoserver ports: - containerPort: 8080
apiVersion: apps/v1 kind: Deployment
1 metadata: name: <echoserver>
2 namespace: echoserver spec: selector: matchLabels: app: echoserver replicas: 3
3 template: metadata: labels: app: echoserver spec: containers: - image: openshift/origin-node command: - "/bin/socat" args: - TCP4-LISTEN:8080,reuseaddr,fork - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"' imagePullPolicy: Always name: echoserver ports: - containerPort: 8080
Copy to Clipboard Copied! Service
リソースを定義する YAML ファイルを作成します。service-albo.yaml
ファイルの例:apiVersion: v1 kind: Service metadata: name: <echoserver> namespace: echoserver spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: app: echoserver
apiVersion: v1 kind: Service
1 metadata: name: <echoserver>
2 namespace: echoserver spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: app: echoserver
Copy to Clipboard Copied! Ingress
リソースを定義する YAML ファイルを作成します。Ingress-albo.yaml
ファイルの例:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <name> namespace: echoserver annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: <echoserver> port: number: 80
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <name>
1 namespace: echoserver annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: alb rules: - http: paths: - path: / pathType: Exact backend: service: name: <echoserver>
2 port: number: 80
Copy to Clipboard Copied!
検証
次のコマンドを実行して、
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! 次のコマンドを実行して、
Ingress
リソースのステータスを確認します。curl $HOST
$ curl $HOST
Copy to Clipboard Copied!
23.6. 1 つの AWS ロードバランサーを介して複数の Ingress リソースを提供する
1 つの AWS Load Balancer を介して、1 つのドメインに含まれるさまざまなサービスにトラフィックをルーティングできます。各 Ingress リソースは、ドメインの異なるエンドポイントを提供します。
23.6.1. 1 つの AWS ロードバランサーを介して複数の Ingress リソースを作成する
CLI を使用すると、1 つの AWS ロードバランサーを介して複数の Ingress リソースにトラフィックをルーティングできます。
前提条件
-
OpenShift CLI (
oc
) にアクセスできる。
手順
次のように、
IngressClassParams
リソースの YAML ファイル (例:sample-single-lb-params.yaml
) を作成します。apiVersion: elbv2.k8s.aws/v1beta1 kind: IngressClassParams metadata: name: single-lb-params spec: group: name: single-lb
apiVersion: elbv2.k8s.aws/v1beta1
1 kind: IngressClassParams metadata: name: single-lb-params
2 spec: group: name: single-lb
3 Copy to Clipboard Copied! 次のコマンドを実行して、
IngressClassParams
リソースを作成します。oc create -f sample-single-lb-params.yaml
$ oc create -f sample-single-lb-params.yaml
Copy to Clipboard Copied! 次のように、
IngressClass
リソースの YAML ファイル (例:sample-single-lb-class.yaml
) を作成します。apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: single-lb spec: controller: ingress.k8s.aws/alb parameters: apiGroup: elbv2.k8s.aws kind: IngressClassParams name: single-lb-params
apiVersion: networking.k8s.io/v1
1 kind: IngressClass metadata: name: single-lb
2 spec: controller: ingress.k8s.aws/alb
3 parameters: apiGroup: elbv2.k8s.aws
4 kind: IngressClassParams
5 name: single-lb-params
6 Copy to Clipboard Copied! 次のコマンドを実行して
IngressClass
リソースを作成します。oc create -f sample-single-lb-class.yaml
$ oc create -f sample-single-lb-class.yaml
Copy to Clipboard Copied! 次のように、
AWSLoadBalancerController
リソース YAML ファイル (例:sample-single-lb.yaml
) を作成します。apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: subnetTagging: Auto ingressClass: single-lb
apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: subnetTagging: Auto ingressClass: single-lb
1 Copy to Clipboard Copied! - 1
IngressClass
リソースの名前を定義します。
次のコマンドを実行して、
AWSLoadBalancerController
リソースを作成します。oc create -f sample-single-lb.yaml
$ oc create -f sample-single-lb.yaml
Copy to Clipboard Copied! 次のように、
Ingress
リソースの YAML ファイル (例:sample-multiple-ingress.yaml
) を作成します。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-1 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/group.order: "1" alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: single-lb rules: - host: example.com http: paths: - path: /blog pathType: Prefix backend: service: name: example-1 port: number: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-2 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/group.order: "2" alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: single-lb rules: - host: example.com http: paths: - path: /store pathType: Prefix backend: service: name: example-2 port: number: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-3 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/group.order: "3" alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: single-lb rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example-3 port: number: 80
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-1
1 annotations: alb.ingress.kubernetes.io/scheme: internet-facing
2 alb.ingress.kubernetes.io/group.order: "1"
3 alb.ingress.kubernetes.io/target-type: instance
4 spec: ingressClassName: single-lb
5 rules: - host: example.com
6 http: paths: - path: /blog
7 pathType: Prefix backend: service: name: example-1
8 port: number: 80
9 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-2 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/group.order: "2" alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: single-lb rules: - host: example.com http: paths: - path: /store pathType: Prefix backend: service: name: example-2 port: number: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-3 annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/group.order: "3" alb.ingress.kubernetes.io/target-type: instance spec: ingressClassName: single-lb rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example-3 port: number: 80
Copy to Clipboard Copied! - 1
- Ingress 名を指定します。
- 2
- インターネットにアクセスするためにパブリックサブネットにプロビジョニングするロードバランサーを示します。
- 3
- ロードバランサーで要求を受信したときに、複数の Ingress リソースからのルールをマッチする順序を指定します。
- 4
- ロードバランサーがサービスに到達するために OpenShift Container Platform ノードをターゲットにすることを示します。
- 5
- この Ingress に属する Ingress クラスを指定します。
- 6
- 要求のルーティングに使用するドメイン名を定義します。
- 7
- サービスにルーティングする必要があるパスを定義します。
- 8
Ingress
リソースで設定されたエンドポイントを提供するサービス名を定義します。- 9
- エンドポイントにサービスを提供するサービスのポートを定義します。
次のコマンドを実行して
Ingress
リソースを作成します。oc create -f sample-multiple-ingress.yaml
$ oc create -f sample-multiple-ingress.yaml
Copy to Clipboard Copied!
23.7. TLS Termination の追加
AWS Load Balancer に TLS Termination を追加できます。
23.7.1. AWS Load Balancer への TLS Termination の追加
ドメインのトラフィックをサービスの Pod にルーティングし、AWS Load Balancer に TLS Termination を追加できます。
前提条件
-
OpenShift CLI (
oc
) にアクセスできる。
手順
AWSLoadBalancerController
リソースを定義する YAML ファイルを作成します。add-tls-termination-albc.yaml
ファイルの例apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: subnetTagging: Auto ingressClass: tls-termination
apiVersion: networking.olm.openshift.io/v1 kind: AWSLoadBalancerController metadata: name: cluster spec: subnetTagging: Auto ingressClass: tls-termination
1 Copy to Clipboard Copied! - 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
ファイルの例apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <example> annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx spec: ingressClassName: tls-termination rules: - host: <example.com> http: paths: - path: / pathType: Exact backend: service: name: <example-service> port: number: 80
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: <example>
1 annotations: alb.ingress.kubernetes.io/scheme: internet-facing
2 alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx
3 spec: ingressClassName: tls-termination
4 rules: - host: <example.com>
5 http: paths: - path: / pathType: Exact backend: service: name: <example-service>
6 port: number: 80
Copy to Clipboard Copied!
23.8. クラスター全体のプロキシーの設定
AWS Load Balancer Operator でクラスター全体のプロキシーを設定できます。クラスター全体のプロキシーを設定すると、Operator Lifecycle Manager (OLM) が、HTTP_PROXY
、HTTPS_PROXY
、NO_PROXY
などの環境変数を使用して、Operator のすべてのデプロイメントを自動的に更新します。これらの変数は、AWS Load Balancer Operator によってマネージドコントローラーに入力されます。
23.8.1. クラスター全体のプロキシーの認証局を信頼する
次のコマンドを実行して、
aws-load-balancer-operator
namespace に認証局 (CA) バンドルを含める config map を作成します。oc -n aws-load-balancer-operator create configmap trusted-ca
$ oc -n aws-load-balancer-operator create configmap trusted-ca
Copy to Clipboard Copied! 信頼できる CA バンドルを config map に挿入するには、次のコマンドを実行して、
config.openshift.io/inject-trusted-cabundle=true
ラベルを config map に追加します。oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
$ oc -n aws-load-balancer-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
Copy to Clipboard Copied! 次のコマンドを実行して、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! 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! 出力例
-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt trusted-ca
-rw-r--r--. 1 root 1000690000 5875 Jan 11 12:25 /etc/pki/tls/certs/albo-tls-ca-bundle.crt trusted-ca
Copy to Clipboard Copied! オプション: config-map が変更されるたびに、次のコマンドを実行して、AWS Load Balancer Operator のデプロイを再開します。
oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
$ oc -n aws-load-balancer-operator rollout restart deployment/aws-load-balancer-operator-controller-manager
Copy to Clipboard Copied!
第24章 複数ネットワーク
24.1. 複数ネットワークについて
Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて additional network を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これにより、スイッチングやルーティングなどのネットワーク機能を提供する Pod を設定する際に柔軟性が得られます。
24.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 設定は、インターフェイスの作成方法を定義します。
24.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 がルートをオーバーライドして設定できるようにします。
24.2. 追加のネットワークの設定
クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。
24.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>
24.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) 設定を変更します。
24.2.3. ネットワーク追加割り当ての設定
追加のネットワークは、k8s.cni.cncf.io
API グループの NetworkAttachmentDefinition
API を使用して設定されます。
NetworkAttachmentDefinition
オブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。
API の設定は、以下の表で説明されています。
フィールド | 型 | 説明 |
---|---|---|
|
| 追加のネットワークの名前です。 |
|
| オブジェクトが関連付けられる namespace。 |
|
| JSON 形式の CNI プラグイン設定。 |
24.2.3.1. Cluster Network Operator による追加ネットワークの設定
追加のネットワーク割り当ての設定は、Cluster Network Operator (CNO) の設定の一部として指定します。
以下の YAML は、CNO で追加のネットワークを管理するための設定パラメーターを記述しています。
Cluster Network Operator (CNO) の設定
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: <name> namespace: <namespace> rawCNIConfig: |- { ... } type: Raw
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
# ...
additionalNetworks:
- name: <name>
namespace: <namespace>
rawCNIConfig: |-
{
...
}
type: Raw
- 1
- 1 つまたは複数の追加ネットワーク設定の配列。
- 2
- 作成している追加ネットワーク割り当ての名前。名前は指定された
namespace
内で一意である必要があります。 - 3
- ネットワークの割り当てを作成する namespace。値を指定しない場合、
default
の namespace が使用されます。重要OVN-Kubernetes ネットワークプラグインの namespace の問題を阻止するには、追加のネットワークアタッチメントに
default
という名前を付けないでください。この namespace は、default
の追加のネットワークアタッチメント用に予約されているためです。 - 4
- JSON 形式の CNI プラグイン設定。
24.2.3.2. YAML マニフェストからの追加ネットワークの設定
追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: <name> spec: config: |- { ... }
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: <name>
spec:
config: |-
{
...
}
24.2.4. 追加のネットワークタイプの設定
次のセクションでは、追加のネットワークの具体的な設定フィールドを説明します。
24.2.4.1. ブリッジネットワークの追加設定
以下のオブジェクトは、ブリッジ 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
24.2.4.1.1. ブリッジ設定の例
以下の例では、bridge-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "bridge-net", "type": "bridge", "isGateway": true, "vlan": 2, "ipam": { "type": "dhcp" } }
{
"cniVersion": "0.3.1",
"name": "bridge-net",
"type": "bridge",
"isGateway": true,
"vlan": 2,
"ipam": {
"type": "dhcp"
}
}
24.2.4.2. ホストデバイスの追加ネットワークの設定
device
、hwaddr
、kernelpath
、または pciBusID
のいずれかのパラメーターを設定してネットワークデバイスを指定します。
以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
オプション: |
|
| オプション: デバイスハードウェアの MAC アドレス。 |
|
|
オプション: |
|
|
オプション: |
24.2.4.2.1. ホストデバイス設定例
以下の例では、hostdev-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "hostdev-net", "type": "host-device", "device": "eth1" }
{
"cniVersion": "0.3.1",
"name": "hostdev-net",
"type": "host-device",
"device": "eth1"
}
24.2.4.3. VLAN 追加ネットワークの設定
次のオブジェクトは、VLAN、vlan
、CNI プラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
|
ネットワーク割り当てに関連付けるイーサネットインターフェイス。 |
|
|
|
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
| オプション: 返される DNS 情報。たとえば、DNS ネームサーバーの優先順位順リストなどです。 |
|
|
オプション: |
vlan
設定を持つ NetworkAttachmentDefinition
カスタムリソース定義 (CRD) は、ノード内の単一の Pod でのみ使用できます。CNI プラグインは、同じ master
インターフェイス上に同じ vlanId
を持つ vlan
サブインターフェイスを複数作成できないためです。
24.2.4.3.1. VLAN 設定例
次の例は、vlan-net
という名前の追加ネットワークを含む vlan
設定を示しています。
{ "name": "vlan-net", "cniVersion": "0.3.1", "type": "vlan", "master": "eth0", "mtu": 1500, "vlanId": 5, "linkInContainer": false, "ipam": { "type": "host-local", "subnet": "10.1.1.0/24" }, "dns": { "nameservers": [ "10.1.1.1", "8.8.8.8" ] } }
{
"name": "vlan-net",
"cniVersion": "0.3.1",
"type": "vlan",
"master": "eth0",
"mtu": 1500,
"vlanId": 5,
"linkInContainer": false,
"ipam": {
"type": "host-local",
"subnet": "10.1.1.0/24"
},
"dns": {
"nameservers": [ "10.1.1.1", "8.8.8.8" ]
}
}
24.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
インターフェイスの設定には前の結果が使用されます。
24.2.4.4.1. IPVLAN 設定例
以下の例では、ipvlan-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "ipvlan-net", "type": "ipvlan", "master": "eth1", "linkInContainer": false, "mode": "l3", "ipam": { "type": "static", "addresses": [ { "address": "192.168.10.10/24" } ] } }
{
"cniVersion": "0.3.1",
"name": "ipvlan-net",
"type": "ipvlan",
"master": "eth1",
"linkInContainer": false,
"mode": "l3",
"ipam": {
"type": "static",
"addresses": [
{
"address": "192.168.10.10/24"
}
]
}
}
24.2.4.5. MACVLAN 追加ネットワークの設定
以下のオブジェクトは、MAC 仮想 LAN (MACVLAN) Container Network Interface (CNI) プラグインの設定パラメーターについて説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| IPAM CNI プラグインの設定オブジェクト。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。 |
|
|
オプション: 仮想ネットワークのトラフィックの可視性を設定します。 |
|
| オプション: 新しく作成された macvlan インターフェイスに関連付けるホストネットワークインターフェイス。値が指定されていない場合は、デフォルトのルートインターフェイスが使用されます。 |
|
| オプション: 指定された値への最大転送単位 (MTU)。デフォルト値はカーネルによって自動的に設定されます。 |
|
|
オプション: |
プラグイン設定の master
キーを指定する場合は、競合の可能性を回避するために、プライマリーネットワークプラグインに関連付けられているものとは異なる物理ネットワークインターフェイスを使用してください。
24.2.4.5.1. macvlan 設定の例
以下の例では、macvlan-net
という名前の追加のネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "macvlan-net", "type": "macvlan", "master": "eth1", "linkInContainer": false, "mode": "bridge", "ipam": { "type": "dhcp" } }
{
"cniVersion": "0.3.1",
"name": "macvlan-net",
"type": "macvlan",
"master": "eth1",
"linkInContainer": false,
"mode": "bridge",
"ipam": {
"type": "dhcp"
}
}
24.2.4.6. TAP 追加ネットワークの設定
以下のオブジェクトは、TAP CNI プラグインの設定パラメーターを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。値 |
|
|
CNO 設定に以前に指定した |
|
|
設定する CNI プラグインの名前: |
|
| オプション: インターフェイスの指定された MAC アドレスを要求します。 |
|
| オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。 |
|
| オプション: タップデバイスに関連付ける SELinux コンテキスト。 注記
OpenShift Container Platform には、値 |
|
|
オプション: マルチキューを有効にするには |
|
| オプション: タップデバイスを所有するユーザー。 |
|
| オプション: タップデバイスを所有するグループ。 |
|
| オプション: タップデバイスを既存のブリッジのポートとして設定します。 |
24.2.4.6.1. Tap 設定の例
以下の例では、mynet
という名前の追加ネットワークを設定します。
{ "name": "mynet", "cniVersion": "0.3.1", "type": "tap", "mac": "00:11:22:33:44:55", "mtu": 1500, "selinuxcontext": "system_u:system_r:container_t:s0", "multiQueue": true, "owner": 0, "group": 0 "bridge": "br1" }
{
"name": "mynet",
"cniVersion": "0.3.1",
"type": "tap",
"mac": "00:11:22:33:44:55",
"mtu": 1500,
"selinuxcontext": "system_u:system_r:container_t:s0",
"multiQueue": true,
"owner": 0,
"group": 0
"bridge": "br1"
}
24.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 ファイルを作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-setsebool spec: config: ignition: version: 3.2.0 systemd: units: - enabled: true name: setsebool.service contents: | [Unit] Description=Set SELinux boolean for the TAP CNI plugin Before=kubelet.service [Service] Type=oneshot ExecStart=/usr/sbin/setsebool container_use_devices=on RemainAfterExit=true [Install] WantedBy=multi-user.target graphical.target
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-setsebool spec: config: ignition: version: 3.2.0 systemd: units: - enabled: true name: setsebool.service contents: | [Unit] Description=Set SELinux boolean for the TAP CNI plugin Before=kubelet.service [Service] Type=oneshot ExecStart=/usr/sbin/setsebool container_use_devices=on RemainAfterExit=true [Install] WantedBy=multi-user.target graphical.target
Copy to Clipboard Copied! 次のコマンドを実行して、新しい
MachineConfig
オブジェクトを作成します。oc apply -f setsebool-container-use-devices.yaml
$ oc apply -f setsebool-container-use-devices.yaml
Copy to Clipboard Copied! 注記MachineConfig
オブジェクトに変更を適用すると、変更が適用された後、影響を受けるすべてのノードが正常に再起動します。この更新が適用されるまでに、時間がかかる場合があります。次のコマンドを実行して、変更が適用されていることを確認します。
oc get machineconfigpools
$ oc get machineconfigpools
Copy to Clipboard Copied! 予想される出力
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 7d
Copy to Clipboard Copied! 注記すべてのノードが更新され、準備完了状態になっている必要があります。
24.2.4.7. 追加ネットワークで route-override プラグインを使用してルートを設定する
次のオブジェクトは、route-override
CNI プラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
設定する CNI プラグインの名前: |
|
|
オプション: 既存ルートをフラッシュするには |
|
|
オプション: デフォルトルート、つまりゲートウェイルートをフラッシュするには |
|
| オプション: コンテナー namespace から削除するルートのリストを指定します。 |
|
|
オプション: コンテナー namespace に追加するルートのリストを指定します。各ルートは、 |
|
|
オプション: check コマンドをスキップするには、これを |
24.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
の新しいルートを追加することで、ルーティングルールが変更されます。
{ "cniVersion": "0.3.0", "name": "mymacvlan", "plugins": [ { "type": "macvlan", "master": "eth1", "mode": "bridge", "ipam": { "type": "host-local", "subnet": "192.168.1.0/24" } }, { "type": "route-override", "flushroutes": true, "delroutes": [ { "dst": "192.168.0.0/24" } ], "addroutes": [ { "dst": "192.168.0.0/24", "gw": "10.1.254.254" } ] } ] }
{
"cniVersion": "0.3.0",
"name": "mymacvlan",
"plugins": [
{
"type": "macvlan",
"master": "eth1",
"mode": "bridge",
"ipam": {
"type": "host-local",
"subnet": "192.168.1.0/24"
}
},
{
"type": "route-override",
"flushroutes": true,
"delroutes": [
{
"dst": "192.168.0.0/24"
}
],
"addroutes": [
{
"dst": "192.168.0.0/24",
"gw": "10.1.254.254"
}
]
}
]
}
24.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 の作成はサポートされていません。
24.2.4.8.1. OVN-Kubernetes 追加ネットワークでサポートされるプラットフォーム
OVN-Kubernetes 追加ネットワークは、次のサポートされているプラットフォームで使用できます。
- ベアメタル
- IBM Power®
- IBM Z®
- IBM® LinuxONE
- VMware vSphere
- Red Hat OpenStack Platform (RHOSP)
24.2.4.8.2. OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル
次の表は、OVN-Kubernetes CNI ネットワークプラグインの設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
CNI 仕様のバージョン。必要な値は |
|
|
ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、 |
|
|
設定する CNI プラグインの名前。この値は |
|
|
ネットワークのトポロジー設定。 |
|
| クラスター全体のネットワークに使用するサブネット。
省略した場合、ネットワークを実装する論理スイッチはレイヤー 2 通信のみを提供し、ユーザーは Pod の IP アドレスを設定する必要があります。ポートセキュリティーは、MAC スプーフィングのみを防止します。 |
|
|
最大伝送単位 (MTU)。デフォルト値 |
|
|
この設定が含まれるネットワークアタッチメント定義 CRD のメタデータの |
|
| CIDR と IP アドレスのコンマ区切りのリスト。IP アドレスは割り当て可能な IP アドレスプールから削除され、Pod に渡されることはありません。 |
|
|
トポロジーが |
24.2.4.8.3. マルチネットワークポリシーとの互換性
k8s.cni.cncf.io
API グループの MultiNetworkPolicy
カスタムリソース定義 (CRD) によって提供されるマルチネットワークポリシー API は、OVN-Kubernetes セカンダリーネットワークと互換性があります。ネットワークポリシーを定義する場合、使用できるネットワークポリシールールは、OVN-Kubernetes セカンダリーネットワークが subnets
フィールドを定義しているかどうかによって異なります。詳細は、次の表を参照してください。
subnets フィールドの指定 | 許可されたマルチネットワークポリシーセレクター |
---|---|
はい |
|
いいえ |
|
たとえば、次のマルチネットワークポリシーは、blue2
という名前の追加ネットワークの追加ネットワーク CNI 設定で subnets
フィールドが定義されている場合にのみ有効です。
Pod セレクターを使用するマルチネットワークポリシーの例
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-same-namespace annotations: k8s.v1.cni.cncf.io/policy-for: blue2 spec: podSelector: ingress: - from: - podSelector: {}
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: allow-same-namespace
annotations:
k8s.v1.cni.cncf.io/policy-for: blue2
spec:
podSelector:
ingress:
- from:
- podSelector: {}
次の例では、ipBlock
ネットワークポリシーセレクターを使用します。これは、OVN-Kubernetes 追加ネットワークに対して常に有効です。
IP ブロックセレクターを使用するマルチネットワークポリシーの例
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: ingress-ipblock annotations: k8s.v1.cni.cncf.io/policy-for: default/flatl2net spec: podSelector: matchLabels: name: access-control policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 10.200.0.0/30
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
name: ingress-ipblock
annotations:
k8s.v1.cni.cncf.io/policy-for: default/flatl2net
spec:
podSelector:
matchLabels:
name: access-control
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 10.200.0.0/30
24.2.4.8.4. レイヤー 2 スイッチドトポロジーの設定
スイッチド (レイヤー 2) トポロジーネットワークは、クラスター全体の論理スイッチを介してワークロードを相互接続します。この設定は、IPv6 およびデュアルスタックデプロイメントに使用できます。
レイヤー 2 スイッチドトポロジーネットワークでは、クラスター内の Pod 間のデータパケットの転送のみが許可されます。
次の JSON 例では、スイッチドセカンダリーネットワークを設定します。
{ "cniVersion": "0.3.1", "name": "l2-network", "type": "ovn-k8s-cni-overlay", "topology":"layer2", "subnets": "10.100.200.0/24", "mtu": 1300, "netAttachDefName": "ns1/l2-network", "excludeSubnets": "10.100.200.0/29" }
{
"cniVersion": "0.3.1",
"name": "l2-network",
"type": "ovn-k8s-cni-overlay",
"topology":"layer2",
"subnets": "10.100.200.0/24",
"mtu": 1300,
"netAttachDefName": "ns1/l2-network",
"excludeSubnets": "10.100.200.0/29"
}
24.2.4.8.5. ローカルネットトポロジーの設定
スイッチド localnet
トポロジーは、ネットワークアタッチメント定義 (NAD) として作成されたワークロードを、クラスター全体の論理スイッチを介して物理ネットワークに相互接続します。
24.2.4.8.5.1. OVN-Kubernetes 追加ネットワークを設定するための前提条件
- NMState Operator がインストールされている。詳細は、Kubernetes NMState Operator について を参照してください。
24.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
ブリッジにマッピングされています。
ブリッジを共有するためのマッピングの例
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: mapping spec: nodeSelector: node-role.kubernetes.io/worker: '' desiredState: ovn: bridge-mappings: - localnet: localnet1 bridge: br-ex state: present
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: mapping
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
ovn:
bridge-mappings:
- localnet: localnet1
bridge: br-ex
state: present
- 1
- 設定オブジェクトの名前。
- 2
- ノードネットワーク設定ポリシーを適用するノードを指定するノードセレクター。
- 3
- トラフィックが OVS ブリッジに転送される追加ネットワークの名前。この追加ネットワークは、OVN-Kubernetes 追加ネットワークを定義する
NetworkAttachmentDefinition
CRD のspec.config.name
フィールドの名前と一致する必要があります。 - 4
- ノード上の OVS ブリッジの名前。この値は、
state: present
を指定する場合にのみ必要です。 - 5
- マッピングの状態。ブリッジを追加する場合は
present
、ブリッジを削除する場合はabsent
である必要があります。デフォルト値はpresent
です。次の JSON の例では、
localnet1
という名前の localnet セカンダリーネットワークを設定します。{ "cniVersion": "0.3.1", "name": "ns1-localnet-network", "type": "ovn-k8s-cni-overlay", "topology":"localnet", "physicalNetworkName": "localnet1", "subnets": "202.10.130.112/28", "vlanID": 33, "mtu": 1500, "netAttachDefName": "ns1/localnet-network", "excludeSubnets": "10.100.200.0/29" }
{ "cniVersion": "0.3.1", "name": "ns1-localnet-network", "type": "ovn-k8s-cni-overlay", "topology":"localnet", "physicalNetworkName": "localnet1", "subnets": "202.10.130.112/28", "vlanID": 33, "mtu": 1500, "netAttachDefName": "ns1/localnet-network", "excludeSubnets": "10.100.200.0/29" }
Copy to Clipboard Copied!
次の例では、localnet2
ネットワークインターフェイスが ovs-br1
ブリッジに接続されています。この接続を使って、ネットワークインターフェイスを OVN-Kubernetes ネットワークプラグインで追加のネットワークとして利用できるようになります。
複数のインターフェイスを持つノードのマッピング例
apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: ovs-br1-multiple-networks spec: nodeSelector: node-role.kubernetes.io/worker: '' desiredState: interfaces: - name: ovs-br1 description: |- A dedicated OVS bridge with eth1 as a port allowing all VLANs and untagged traffic type: ovs-bridge state: up bridge: allow-extra-patch-ports: true options: stp: false port: - name: eth1 ovn: bridge-mappings: - localnet: localnet2 bridge: ovs-br1 state: present
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: ovs-br1-multiple-networks
spec:
nodeSelector:
node-role.kubernetes.io/worker: ''
desiredState:
interfaces:
- name: ovs-br1
description: |-
A dedicated OVS bridge with eth1 as a port
allowing all VLANs and untagged traffic
type: ovs-bridge
state: up
bridge:
allow-extra-patch-ports: true
options:
stp: false
port:
- name: eth1
ovn:
bridge-mappings:
- localnet: localnet2
bridge: ovs-br1
state: present
- 1
- 設定オブジェクトの名前。
- 2
- ノードネットワーク設定ポリシーを適用するノードを指定するノードセレクター。
- 3
- OVN-Kubernetes がすべてのクラスタートラフィックに使用するデフォルトブリッジとは別の、新しい OVS ブリッジ。
- 4
- この新しい OVS ブリッジに関連付けるホストシステム上のネットワークデバイス。
- 5
- トラフィックが OVS ブリッジに転送される追加ネットワークの名前。この追加ネットワークは、OVN-Kubernetes 追加ネットワークを定義する
NetworkAttachmentDefinition
CRD のspec.config.name
フィールドの名前と一致する必要があります。 - 6
- ノード上の OVS ブリッジの名前。この値は、
state: present
を指定する場合にのみ必要です。 - 7
- マッピングの状態。ブリッジを追加する場合は
present
、ブリッジを削除する場合はabsent
である必要があります。デフォルト値はpresent
です。次の JSON の例では、
localnet2
という名前の localnet セカンダリーネットワークを設定します。{ "cniVersion": "0.3.1", "name": "ns1-localnet-network", "type": "ovn-k8s-cni-overlay", "topology":"localnet", "physicalNetworkName": "localnet2", "subnets": "202.10.130.112/28", "vlanID": 33, "mtu": 1500, "netAttachDefName": "ns1/localnet-network" "excludeSubnets": "10.100.200.0/29" }
{ "cniVersion": "0.3.1", "name": "ns1-localnet-network", "type": "ovn-k8s-cni-overlay", "topology":"localnet", "physicalNetworkName": "localnet2", "subnets": "202.10.130.112/28", "vlanID": 33, "mtu": 1500, "netAttachDefName": "ns1/localnet-network" "excludeSubnets": "10.100.200.0/29" }
Copy to Clipboard Copied!
24.2.4.8.6. 追加ネットワーク用の Pod の設定
k8s.v1.cni.cncf.io/networks
アノテーションを使用して、セカンダリーネットワーク割り当てを指定する必要があります。
次の例では、このガイドに示されている割り当て設定ごとに 1 つずつ、2 つのセカンダリー割り当てを持つ Pod をプロビジョニングします。
apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: l2-network name: tinypod namespace: ns1 spec: containers: - args: - pause image: k8s.gcr.io/e2e-test-images/agnhost:2.36 imagePullPolicy: IfNotPresent name: agnhost-container
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: l2-network
name: tinypod
namespace: ns1
spec:
containers:
- args:
- pause
image: k8s.gcr.io/e2e-test-images/agnhost:2.36
imagePullPolicy: IfNotPresent
name: agnhost-container
24.2.4.8.7. 静的 IP アドレスを使用して Pod を設定する
次の例では、静的 IP アドレスを使用して Pod をプロビジョニングします。
- レイヤー 2 割り当てに対する Pod のセカンダリーネットワーク割り当ての IP アドレスのみを指定できます。
- Pod の静的 IP アドレスを指定できるのは、割り当て設定にサブネットが含まれていない場合のみです。
apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "l2-network", "mac": "02:03:04:05:06:07", "interface": "myiface1", "ips": [ "192.0.2.20/24" ] } ]' name: tinypod namespace: ns1 spec: containers: - args: - pause image: k8s.gcr.io/e2e-test-images/agnhost:2.36 imagePullPolicy: IfNotPresent name: agnhost-container
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: '[
{
"name": "l2-network",
"mac": "02:03:04:05:06:07",
"interface": "myiface1",
"ips": [
"192.0.2.20/24"
]
}
]'
name: tinypod
namespace: ns1
spec:
containers:
- args:
- pause
image: k8s.gcr.io/e2e-test-images/agnhost:2.36
imagePullPolicy: IfNotPresent
name: agnhost-container
24.2.5. 追加ネットワークの IP アドレス割り当ての設定
IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。
以下の IP アドレスの割り当てタイプを使用できます。
- 静的割り当て。
- DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
- Whereabouts IPAM CNI プラグインを使用した動的割り当て。
24.2.5.1. 静的 IP アドレス割り当ての設定
以下の表は、静的 IP アドレスの割り当ての設定を説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses
の配列には、以下のフィールドのあるオブジェクトが必要です。
フィールド | 型 | 説明 |
---|---|---|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7/24" } ] } }
{
"ipam": {
"type": "static",
"addresses": [
{
"address": "191.168.1.7/24"
}
]
}
}
24.2.5.2. 動的 IP アドレス (DHCP) 割り当ての設定
以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: dhcp-shim namespace: default type: Raw rawCNIConfig: |- { "name": "dhcp-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "dhcp" } } # ...
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: dhcp-shim
namespace: default
type: Raw
rawCNIConfig: |-
{
"name": "dhcp-shim",
"cniVersion": "0.3.1",
"type": "bridge",
"ipam": {
"type": "dhcp"
}
}
# ...
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
動的 IP アドレス (DHCP) 割り当ての設定例
{ "ipam": { "type": "dhcp" } }
{
"ipam": {
"type": "dhcp"
}
}
24.2.5.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
Whereabouts を使用する動的 IP アドレス割り当ての設定例
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/27", "exclude": [ "192.0.2.192/30", "192.0.2.196/32" ] } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/27",
"exclude": [
"192.0.2.192/30",
"192.0.2.196/32"
]
}
}
24.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 cluster
Copy to Clipboard Copied! この例で展開されている YAML の
additionalNetworks
セクションを、カスタムリソース (CR) のspec
定義内に含めます。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster # ... spec: additionalNetworks: - name: whereabouts-shim namespace: default rawCNIConfig: |- { "name": "whereabouts-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "whereabouts" } } type: Raw # ...
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster # ... spec: additionalNetworks: - name: whereabouts-shim namespace: default rawCNIConfig: |- { "name": "whereabouts-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "whereabouts" } } type: Raw # ...
Copy to Clipboard Copied! - ファイルを保存し、テキストエディターを編集します。
次のコマンドを実行して、
whereabouts-reconciler
デーモンセットが正常にデプロイされたことを確認します。oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconciler
Copy to Clipboard Copied! 出力例
pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s
pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s
Copy to Clipboard Copied!
24.2.5.5. Whereabouts IP リコンサイラーのスケジュールの設定
Whereabouts IPAM CNI プラグインは、IP リコンサイラーを毎日実行します。このプロセスは、IP が枯渇して新しい Pod に IP が割り当てられなくなる状態を避けるために、完了せずに残っている IP 割り当てをクリーンアップします。
IP リコンサイラーを実行する頻度を変更するには、次の手順を使用します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
whereabouts-reconciler
デーモンセットがデプロイされており、whereabouts-reconciler
Pod が起動して実行されている。
手順
次のコマンドを実行して、IP リコンサイラー用の特定の cron 式を使用し、
openshift-multus
namespace に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! この cron 式は、IP リコンサイラーを 15 分ごとに実行するよう指定します。この式は固有の要件に基づいて調整してください。
注記whereabouts-reconciler
デーモンセットは、5 つのアスタリスクを含む cron 式パターンのみを使用できます。秒を表すために使用される 6 番目のアスタリスクは、現在サポートされていません。次のコマンドを実行して、
openshift-multus
namespace 内のwhereabouts-reconciler
デーモンセットおよび Pod に関連するリソースに関する情報を取得します。oc get all -n openshift-multus | grep whereabouts-reconciler
$ oc get all -n openshift-multus | grep whereabouts-reconciler
Copy to Clipboard Copied! 出力例
pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s pod/whereabouts-reconciler-76jk7 1/1 Running 0 4m14s pod/whereabouts-reconciler-94zw6 1/1 Running 0 4m14s pod/whereabouts-reconciler-mfh68 1/1 Running 0 4m14s pod/whereabouts-reconciler-pgshz 1/1 Running 0 4m14s pod/whereabouts-reconciler-xn5xz 1/1 Running 0 4m14s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 4m16s
pod/whereabouts-reconciler-2p7hw 1/1 Running 0 4m14s pod/whereabouts-reconciler-76jk7 1/1 Running 0 4m14s pod/whereabouts-reconciler-94zw6 1/1 Running 0 4m14s pod/whereabouts-reconciler-mfh68 1/1 Running 0 4m14s pod/whereabouts-reconciler-pgshz 1/1 Running 0 4m14s pod/whereabouts-reconciler-xn5xz 1/1 Running 0 4m14s daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 4m16s
Copy to Clipboard Copied! 次のコマンドを実行して、設定した間隔で
whereabouts-reconciler
Pod が IP リコンサイラーを実行していることを確認します。oc -n openshift-multus logs whereabouts-reconciler-2p7hw
$ oc -n openshift-multus logs whereabouts-reconciler-2p7hw
Copy to Clipboard Copied! 出力例
2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CHMOD 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..data_tmp": RENAME 2024-02-02T16:33:54Z [verbose] using expression: */15 * * * * 2024-02-02T16:33:54Z [verbose] configuration updated to file "/cron-schedule/..data". New cron expression: */15 * * * * 2024-02-02T16:33:54Z [verbose] successfully updated CRON configuration id "00c2d1c9-631d-403f-bb86-73ad104a6817" - new cron expression: */15 * * * * 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/config": CREATE 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_26_17.3874177937": REMOVE 2024-02-02T16:45:00Z [verbose] starting reconciler run 2024-02-02T16:45:00Z [debug] NewReconcileLooper - inferred connection data 2024-02-02T16:45:00Z [debug] listing IP pools 2024-02-02T16:45:00Z [debug] no IP addresses to cleanup 2024-02-02T16:45:00Z [verbose] reconciler success
2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CREATE 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_33_54.1375928161": CHMOD 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..data_tmp": RENAME 2024-02-02T16:33:54Z [verbose] using expression: */15 * * * * 2024-02-02T16:33:54Z [verbose] configuration updated to file "/cron-schedule/..data". New cron expression: */15 * * * * 2024-02-02T16:33:54Z [verbose] successfully updated CRON configuration id "00c2d1c9-631d-403f-bb86-73ad104a6817" - new cron expression: */15 * * * * 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/config": CREATE 2024-02-02T16:33:54Z [debug] event not relevant: "/cron-schedule/..2024_02_02_16_26_17.3874177937": REMOVE 2024-02-02T16:45:00Z [verbose] starting reconciler run 2024-02-02T16:45:00Z [debug] NewReconcileLooper - inferred connection data 2024-02-02T16:45:00Z [debug] listing IP pools 2024-02-02T16:45:00Z [debug] no IP addresses to cleanup 2024-02-02T16:45:00Z [verbose] reconciler success
Copy to Clipboard Copied!
24.2.5.6. デュアルスタック IP アドレスを動的に割り当てる設定の作成
デュアルスタックの IP アドレスの割り当ては、ipRanges
パラメーターで設定できます。
- IPv4 アドレス
- IPv6 アドレス
- 複数の IP アドレスの割り当て
手順
-
type
をwhereabouts
に設定します。 以下の例のように、
ipRanges
を使用して IP アドレスを割り当てます。cniVersion: operator.openshift.io/v1 kind: Network =metadata: name: cluster spec: additionalNetworks: - name: whereabouts-shim namespace: default type: Raw rawCNIConfig: |- { "name": "whereabouts-dual-stack", "cniVersion": "0.3.1, "type": "bridge", "ipam": { "type": "whereabouts", "ipRanges": [ {"range": "192.168.10.0/24"}, {"range": "2001:db8::/64"} ] } }
cniVersion: operator.openshift.io/v1 kind: Network =metadata: name: cluster spec: additionalNetworks: - name: whereabouts-shim namespace: default type: Raw rawCNIConfig: |- { "name": "whereabouts-dual-stack", "cniVersion": "0.3.1, "type": "bridge", "ipam": { "type": "whereabouts", "ipRanges": [ {"range": "192.168.10.0/24"}, {"range": "2001:db8::/64"} ] } }
Copy to Clipboard Copied! - ネットワークを Pod にアタッチします。詳細は、「追加のネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip a
Copy to Clipboard Copied!
24.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! CNO 設定を編集するには、以下のコマンドを入力します。
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
Copy to Clipboard Copied! 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: namespace2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: namespace2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
Copy to Clipboard Copied! - 変更を保存し、テキストエディターを終了して、変更をコミットします。
検証
次のコマンドを実行して、CNO が
NetworkAttachmentDefinition
CRD を作成したことを確認します。CNO が CRD を作成するまでに遅延が発生する可能性があります。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<namespace>
- CNO の設定に追加したネットワーク割り当ての namespace を指定します。
出力例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14m
Copy to Clipboard Copied!
24.2.7. YAML マニフェストを適用した追加のネットワーク割り当ての作成
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の例のように、追加のネットワーク設定を含む YAML ファイルを作成します。
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
Copy to Clipboard Copied! 追加のネットワークを作成するには、次のコマンドを入力します。
oc apply -f <file>.yaml
$ oc apply -f <file>.yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
<file>
- YAML マニフェストを含むファイルの名前を指定します。
24.2.8. コンテナーネットワーク namespace での master インターフェイスの設定について
コンテナー namespace に存在する master
インターフェイスに基づいて、MAC-VLAN、IP-VLAN、または VLAN サブインターフェイスを作成できます。別のネットワークアタッチメント定義 CRD で、Pod ネットワーク設定の一部として master
インターフェイスを作成することもできます。
コンテナー namespace の master
インターフェイスを使用するには、NetworkAttachmentDefinition
CRD のサブインターフェイス設定に存在する linkInContainer
パラメーターに true
を指定する必要があります。
24.2.8.1. SR-IOV VF 上で複数の VLAN を作成する
この機能を利用するユースケースの例として、SR-IOV VF に基づいて複数の VLAN を作成することが挙げられます。これを行うには、まず SR-IOV ネットワークを作成し、次に VLAN インターフェイスのネットワーク割り当てを定義します。
次の例は、この図に示されているセットアップを設定する方法を示しています。
図24.1 VLAN の作成

前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - SR-IOV Network Operator がインストールされている。
手順
次のコマンドを使用して、Pod をデプロイする専用のコンテナー namespace を作成します。
oc new-project test-namespace
$ oc new-project test-namespace
Copy to Clipboard Copied! SR-IOV ノードポリシーを作成します。
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML をsriov-node-network-policy.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriovnic namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: false needVhostNet: true nicSelector: vendor: "15b3" deviceID: "101b" rootDevices: ["00:05.0"] numVfs: 10 priority: 99 resourceName: sriovnic nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriovnic namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: false needVhostNet: true nicSelector: vendor: "15b3"
1 deviceID: "101b"
2 rootDevices: ["00:05.0"] numVfs: 10 priority: 99 resourceName: sriovnic nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
Copy to Clipboard Copied! 注記deviceType: netdevice
を設定した SR-IOV ネットワークノードポリシーの設定例は、Mellanox ネットワークインターフェイスカード (NIC) 向けに特別に調整されています。以下のコマンドを実行して YAML を適用します。
oc apply -f sriov-node-network-policy.yaml
$ oc apply -f sriov-node-network-policy.yaml
Copy to Clipboard Copied! 注記ノードの再起動が必要なため、YAML の適用には時間がかかる場合があります。
SR-IOV ネットワークを作成します。
次の CR の例のように、追加の SR-IOV ネットワーク割り当て用の
SriovNetwork
カスタムリソース (CR) を作成します。YAML をsriov-network-attachment.yaml
ファイルとして保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-network namespace: openshift-sriov-network-operator spec: networkNamespace: test-namespace resourceName: sriovnic spoofChk: "off" trust: "on"
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-network namespace: openshift-sriov-network-operator spec: networkNamespace: test-namespace resourceName: sriovnic spoofChk: "off" trust: "on"
Copy to Clipboard Copied! 以下のコマンドを実行して YAML を適用します。
oc apply -f sriov-network-attachment.yaml
$ oc apply -f sriov-network-attachment.yaml
Copy to Clipboard Copied!
VLAN 追加ネットワークを作成します。
以下の YAML の例を使用して、
vlan100-additional-network-configuration.yaml
という名前のファイルを作成します。apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: vlan-100 namespace: test-namespace spec: config: | { "cniVersion": "0.4.0", "name": "vlan-100", "plugins": [ { "type": "vlan", "master": "ext0", "mtu": 1500, "vlanId": 100, "linkInContainer": true, "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]} } ] }
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: vlan-100 namespace: test-namespace spec: config: | { "cniVersion": "0.4.0", "name": "vlan-100", "plugins": [ { "type": "vlan", "master": "ext0",
1 "mtu": 1500, "vlanId": 100, "linkInContainer": true,
2 "ipam": {"type": "whereabouts", "ipRanges": [{"range": "1.1.1.0/24"}]} } ] }
Copy to Clipboard Copied! 以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f vlan100-additional-network-configuration.yaml
$ oc apply -f vlan100-additional-network-configuration.yaml
Copy to Clipboard Copied!
前に指定したネットワークを使用して、Pod 定義を作成します。
次の YAML の例を使用して、
pod-a.yaml
という名前のファイルを作成します。注記以下のマニフェストには 2 つのリソースが含まれています。
- セキュリティーラベルのある namespace
- 適切なネットワークアノテーションを含む Pod 定義
apiVersion: v1 kind: Namespace metadata: name: test-namespace labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged security.openshift.io/scc.podSecurityLabelSync: "false" --- apiVersion: v1 kind: Pod metadata: name: nginx-pod namespace: test-namespace annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0" }, { "name": "vlan-100", "namespace": "test-namespace", "interface": "ext0.100" } ]' spec: securityContext: runAsNonRoot: true containers: - name: nginx-container image: nginxinc/nginx-unprivileged:latest securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] ports: - containerPort: 80 seccompProfile: type: "RuntimeDefault"
apiVersion: v1 kind: Namespace metadata: name: test-namespace labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged security.openshift.io/scc.podSecurityLabelSync: "false" --- apiVersion: v1 kind: Pod metadata: name: nginx-pod namespace: test-namespace annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0"
1 }, { "name": "vlan-100", "namespace": "test-namespace", "interface": "ext0.100" } ]' spec: securityContext: runAsNonRoot: true containers: - name: nginx-container image: nginxinc/nginx-unprivileged:latest securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] ports: - containerPort: 80 seccompProfile: type: "RuntimeDefault"
Copy to Clipboard Copied! - 1
- VLAN インターフェイスの
master
として使用される名前。
以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yaml
Copy to Clipboard Copied!
次のコマンドを実行して、
test-namespace
内のnginx-pod
に関する詳細情報を取得します。oc describe pods nginx-pod -n test-namespace
$ oc describe pods nginx-pod -n test-namespace
Copy to Clipboard Copied! 出力例
Name: nginx-pod Namespace: test-namespace Priority: 0 Node: worker-1/10.46.186.105 Start Time: Mon, 14 Aug 2023 16:23:13 -0400 Labels: <none> Annotations: k8s.ovn.org/pod-networks: {"default":{"ip_addresses":["10.131.0.26/23"],"mac_address":"0a:58:0a:83:00:1a","gateway_ips":["10.131.0.1"],"routes":[{"dest":"10.128.0.0... k8s.v1.cni.cncf.io/network-status: [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.131.0.26" ], "mac": "0a:58:0a:83:00:1a", "default": true, "dns": {} },{ "name": "test-namespace/sriov-network", "interface": "ext0", "mac": "6e:a7:5e:3f:49:1b", "dns": {}, "device-info": { "type": "pci", "version": "1.0.0", "pci": { "pci-address": "0000:d8:00.2" } } },{ "name": "test-namespace/vlan-100", "interface": "ext0.100", "ips": [ "1.1.1.1" ], "mac": "6e:a7:5e:3f:49:1b", "dns": {} }] k8s.v1.cni.cncf.io/networks: [ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0" }, { "name": "vlan-100", "namespace": "test-namespace", "i... openshift.io/scc: privileged Status: Running IP: 10.131.0.26 IPs: IP: 10.131.0.26
Name: nginx-pod Namespace: test-namespace Priority: 0 Node: worker-1/10.46.186.105 Start Time: Mon, 14 Aug 2023 16:23:13 -0400 Labels: <none> Annotations: k8s.ovn.org/pod-networks: {"default":{"ip_addresses":["10.131.0.26/23"],"mac_address":"0a:58:0a:83:00:1a","gateway_ips":["10.131.0.1"],"routes":[{"dest":"10.128.0.0... k8s.v1.cni.cncf.io/network-status: [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.131.0.26" ], "mac": "0a:58:0a:83:00:1a", "default": true, "dns": {} },{ "name": "test-namespace/sriov-network", "interface": "ext0", "mac": "6e:a7:5e:3f:49:1b", "dns": {}, "device-info": { "type": "pci", "version": "1.0.0", "pci": { "pci-address": "0000:d8:00.2" } } },{ "name": "test-namespace/vlan-100", "interface": "ext0.100", "ips": [ "1.1.1.1" ], "mac": "6e:a7:5e:3f:49:1b", "dns": {} }] k8s.v1.cni.cncf.io/networks: [ { "name": "sriov-network", "namespace": "test-namespace", "interface": "ext0" }, { "name": "vlan-100", "namespace": "test-namespace", "i... openshift.io/scc: privileged Status: Running IP: 10.131.0.26 IPs: IP: 10.131.0.26
Copy to Clipboard Copied!
24.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-namespace
Copy to Clipboard Copied! 次の YAML の例を使用して、
bridge-nad.yaml
という名前のブリッジNetworkAttachmentDefinition
カスタムリソース定義 (CRD) ファイルを作成します。apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-network spec: config: '{ "cniVersion": "0.4.0", "name": "bridge-network", "type": "bridge", "bridge": "br-001", "isGateway": true, "ipMasq": true, "hairpinMode": true, "ipam": { "type": "host-local", "subnet": "10.0.0.0/24", "routes": [{"dst": "0.0.0.0/0"}] } }'
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: bridge-network spec: config: '{ "cniVersion": "0.4.0", "name": "bridge-network", "type": "bridge", "bridge": "br-001", "isGateway": true, "ipMasq": true, "hairpinMode": true, "ipam": { "type": "host-local", "subnet": "10.0.0.0/24", "routes": [{"dst": "0.0.0.0/0"}] } }'
Copy to Clipboard Copied! 次のコマンドを実行して、
NetworkAttachmentDefinition
CRD を OpenShift Container Platform クラスターに適用します。oc apply -f bridge-nad.yaml
$ oc apply -f bridge-nad.yaml
Copy to Clipboard Copied! 次のコマンドを入力して、
NetworkAttachmentDefinition
CRD が正常に作成されたことを確認します。oc get network-attachment-definitions
$ oc get network-attachment-definitions
Copy to Clipboard Copied! 出力例
NAME AGE bridge-network 15s
NAME AGE bridge-network 15s
Copy to Clipboard Copied! 以下の YAML の例を使用して、追加の IPVLAN ネットワーク設定用に
ipvlan-additional-network-configuration.yaml
という名前のファイルを作成します。apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: ipvlan-net namespace: test-namespace spec: config: '{ "cniVersion": "0.3.1", "name": "ipvlan-net", "type": "ipvlan", "master": "ext0", "mode": "l3", "linkInContainer": true, "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]} }'
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: ipvlan-net namespace: test-namespace spec: config: '{ "cniVersion": "0.3.1", "name": "ipvlan-net", "type": "ipvlan", "master": "ext0",
1 "mode": "l3", "linkInContainer": true,
2 "ipam": {"type": "whereabouts", "ipRanges": [{"range": "10.0.0.0/24"}]} }'
Copy to Clipboard Copied! 以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f ipvlan-additional-network-configuration.yaml
$ oc apply -f ipvlan-additional-network-configuration.yaml
Copy to Clipboard Copied! 次のコマンドを実行して、
NetworkAttachmentDefinition
CRD が正常に作成されたことを確認します。oc get network-attachment-definitions
$ oc get network-attachment-definitions
Copy to Clipboard Copied! 出力例
NAME AGE bridge-network 87s ipvlan-net 9s
NAME AGE bridge-network 87s ipvlan-net 9s
Copy to Clipboard Copied! 以下の YAML の例を使用して、Pod 定義用に
pod-a.yaml
という名前のファイルを作成します。apiVersion: v1 kind: Pod metadata: name: pod-a namespace: test-namespace annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "bridge-network", "interface": "ext0" }, { "name": "ipvlan-net", "interface": "ext1" } ]' spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: test-pod image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4 securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL]
apiVersion: v1 kind: Pod metadata: name: pod-a namespace: test-namespace annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "bridge-network", "interface": "ext0"
1 }, { "name": "ipvlan-net", "interface": "ext1" } ]' spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: test-pod image: quay.io/openshifttest/hello-sdn@sha256:c89445416459e7adea9a5a416b3365ed3d74f2491beb904d61dc8d1eb89a72a4 securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL]
Copy to Clipboard Copied! - 1
- IPVLAN インターフェイスの
master
として使用する名前を指定します。
以下のコマンドを実行して、YAML ファイルを適用します。
oc apply -f pod-a.yaml
$ oc apply -f pod-a.yaml
Copy to Clipboard Copied! 以下のコマンドを使用して、Pod が実行されていることを確認します。
oc get pod -n test-namespace
$ oc get pod -n test-namespace
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
NAME READY STATUS RESTARTS AGE pod-a 1/1 Running 0 2m36s
Copy to Clipboard Copied! 次のコマンドを実行して、
test-namespace
内のpod-a
リソースに関するネットワークインターフェイス情報を表示します。oc exec -n test-namespace pod-a -- ip a
$ oc exec -n test-namespace pod-a -- ip a
Copy to Clipboard Copied! 出力例
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default link/ether 0a:58:0a:d9:00:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.217.0.93/23 brd 10.217.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::488b:91ff:fe84:a94b/64 scope link valid_lft forever preferred_lft forever 4: ext0@if107: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.0.2/24 brd 10.0.0.255 scope global ext0 valid_lft forever preferred_lft forever inet6 fe80::bcda:bdff:fe7e:f437/64 scope link valid_lft forever preferred_lft forever 5: ext1@ext0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global ext1 valid_lft forever preferred_lft forever inet6 fe80::beda:bd00:17e:f437/64 scope link valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default link/ether 0a:58:0a:d9:00:5d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.217.0.93/23 brd 10.217.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::488b:91ff:fe84:a94b/64 scope link valid_lft forever preferred_lft forever 4: ext0@if107: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.0.2/24 brd 10.0.0.255 scope global ext0 valid_lft forever preferred_lft forever inet6 fe80::bcda:bdff:fe7e:f437/64 scope link valid_lft forever preferred_lft forever 5: ext1@ext0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether be:da:bd:7e:f4:37 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 brd 10.0.0.255 scope global ext1 valid_lft forever preferred_lft forever inet6 fe80::beda:bd00:17e:f437/64 scope link valid_lft forever preferred_lft forever
Copy to Clipboard Copied! この出力は、ネットワークインターフェイス
ext1
が物理インターフェイスext0
に関連付けられていることを示しています。
24.3. 仮想ルーティングおよび転送について
24.3.1. 仮想ルーティングおよび転送について
Virtual Routing and Forwarding (VRF) デバイスと IP ルールを組み合わせることで、Virtual Routing and Forwarding ドメインを作成できます。VRF は、CNF で必要なパーミッションの数を減らし、セカンダリーネットワークのネットワークトポロジーの可視性を強化します。VRF はマルチテナンシー機能を提供するために使用されます。たとえば、この場合、各テナントには固有のルーティングテーブルがあり、異なるデフォルトゲートウェイが必要です。
プロセスは、ソケットを VRF デバイスにバインドできます。バインドされたソケット経由のパケットは、VRF デバイスに関連付けられたルーティングテーブルを使用します。VRF の重要な機能として、これは OSI モデルレイヤー 3 以上にのみ影響を与えるため、LLDP などの L2 ツールは影響を受けません。これにより、ポリシーベースのルーティングなどの優先度の高い IP ルールが、特定のトラフィックを転送する VRF デバイスルールよりも優先されます。
24.3.1.1. Telecommunications Operator に関する Pod のセカンダリーネットワークの利点
通信のユースケースでは、各 CNF が同じアドレス空間を共有する複数の異なるネットワークに接続される可能性があります。これらのセカンダリーネットワークは、クラスターのメインネットワーク CIDR と競合する可能性があります。CNI VRF プラグインを使用すると、ネットワーク機能は、同じ IP アドレスを使用して異なるユーザーのインフラストラクチャーに接続でき、複数の異なるお客様の分離された状態を維持します。IP アドレスは OpenShift Container Platform の IP スペースと重複します。CNI VRF プラグインは、CNF で必要なパーミッションの数も減らし、セカンダリーネットワークのネットワークトポロジーの可視性を高めます。
24.4. マルチネットワークポリシーの設定
クラスター管理者は、シングルルート I/O 仮想化 (SR-IOV)、MAC 仮想ローカルエリアネットワーク (MacVLAN)、または OVN-Kubernetes 追加ネットワークのマルチネットワークポリシーを設定できます。MacVLAN 追加ネットワークは完全にサポートされています。IP 仮想ローカルエリアネットワーク (IPVLAN) などの他の種類の追加ネットワークはサポートされていません。
SR-IOV 追加ネットワークのマルチネットワークポリシーの設定のサポートは、カーネルネットワークインターフェイスコントローラー (NIC) でのみサポートされます。SR-IOV は、データプレーン開発キット (DPDK) アプリケーションではサポートされていません。
24.4.1. マルチネットワークポリシーとネットワークポリシーの違い
MultiNetworkPolicy
API は、NetworkPolicy
API を実装していますが、いくつかの重要な違いがあります。
以下の場合は、
MultiNetworkPolicy
API を使用する必要があります。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy
Copy to Clipboard Copied! -
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! ここでは、以下のようになります。
<network_name>
- ネットワーク割り当て定義の名前を指定します。
24.4.2. クラスターのマルチネットワークポリシーの有効化
クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインする。
手順
以下の YAML で
multinetwork-enable-patch.yaml
ファイルを作成します。apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: useMultiNetworkPolicy: true
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: useMultiNetworkPolicy: true
Copy to Clipboard Copied! マルチネットワークポリシーを有効にするようにクラスターを設定します。
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.yaml
Copy to Clipboard Copied! 出力例
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied!
24.4.3. IPv6 ネットワークでのマルチネットワークポリシーのサポート
ICMPv6 近隣探索プロトコル (NDP) は、デバイスが近隣ノードに関する情報を検出して維持できるようにするための、メッセージとプロセスのセットです。NDP は IPv6 ネットワークで重要な役割を果たし、同じリンク上のデバイス間の対話を促進します。
useMultiNetworkPolicy
パラメーターが true
に設定されている場合、Cluster Network Operator (CNO) はマルチネットワークポリシーの iptables 実装をデプロイします。
IPv6 ネットワークでマルチネットワークポリシーをサポートするために、Cluster Network Operator は、マルチネットワークポリシーの影響を受けるすべての Pod に次のルールのセットをデプロイします。
マルチネットワークポリシーのカスタムルール
kind: ConfigMap apiVersion: v1 metadata: name: multi-networkpolicy-custom-rules namespace: openshift-multus data: custom-v6-rules.txt: | # accept NDP -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT # accept RA/RS -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
kind: ConfigMap
apiVersion: v1
metadata:
name: multi-networkpolicy-custom-rules
namespace: openshift-multus
data:
custom-v6-rules.txt: |
# accept NDP
-p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT
-p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT
# accept RA/RS
-p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
-p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
- 1
- このルールは、近隣探索プロトコル (NDP) の一部である ICMPv6 ネイバー要請メッセージの受信を許可します。これらのメッセージは、近隣ノードのリンクレイヤーアドレスを決定するのに役立ちます。
- 2
- このルールは、NDP の一部であり、送信者のリンクレイヤーアドレスに関する情報を提供する、受信 ICMPv6 近隣アドバタイズメントメッセージを許可します。
- 3
- このルールは、ICMPv6 ルーター要請メッセージの受信を許可します。ホストは、これらのメッセージを使用してルーター設定情報を要求します。
- 4
- このルールは、ホストに設定情報を提供する ICMPv6 ルーターアドバタイズメントメッセージの受信を許可します。
これらの事前定義されたルールは編集できません。
これらのルールが集合することで、IPv6 環境でのアドレス解決やルーター通信などを含め、ネットワークが正しく機能するために不可欠な ICMPv6 トラフィックが有効になります。これらのルールが適用され、トラフィックを拒否するマルチネットワークポリシーがあれば、アプリケーションで接続の問題が発生することは考えられません。
24.4.4. マルチネットワークポリシーの使用
クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。
24.4.4.1. 前提条件
- クラスターのマルチネットワークポリシーサポートを有効にしている。
24.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>.yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。
すべての namespace のすべての Pod から Ingress を拒否します。
これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default annotations: k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> spec: podSelector: {} policyTypes: - Ingress ingress: []
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default annotations: k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name> spec: podSelector: {} policyTypes: - Ingress ingress: []
Copy to Clipboard Copied! ここでは、以下のようになります。
<network_name>
- ネットワーク割り当て定義の名前を指定します。
同じ namespace のすべての Pod から Ingress を許可します。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-same-namespace annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: ingress: - from: - podSelector: {}
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-same-namespace annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: ingress: - from: - podSelector: {}
Copy to Clipboard Copied! ここでは、以下のようになります。
<network_name>
- ネットワーク割り当て定義の名前を指定します。
特定の namespace から 1 つの Pod への上りトラフィックを許可する
このポリシーは、
namespace-y
で実行されている Pod からpod-a
というラベルの付いた Pod へのトラフィックを許可します。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-traffic-pod annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: allow-traffic-pod annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: pod: pod-a policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: namespace-y
Copy to Clipboard Copied! ここでは、以下のようになります。
<network_name>
- ネットワーク割り当て定義の名前を指定します。
サービスへのトラフィックを制限する
このポリシーを適用すると、
app=bookstore
とrole=api
の両方のラベルを持つすべての Pod に、app=bookstore
というラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベルapp=bookstore
およびrole=api
でマークされた REST API サーバーである可能性があります。この例では、次のユースケースに対応します。
- サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。
データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: api-allow annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: bookstore role: api ingress: - from: - podSelector: matchLabels: app: bookstore
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: api-allow annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: bookstore role: api ingress: - from: - podSelector: matchLabels: app: bookstore
Copy to Clipboard Copied! ここでは、以下のようになります。
<network_name>
- ネットワーク割り当て定義の名前を指定します。
マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーのファイル名を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
Copy to Clipboard Copied!
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。
24.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-networkpolicy
Copy to Clipboard Copied! ここでは、以下のようになります。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトを編集します。
マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yaml
Copy to Clipboard Copied! ここでは、以下のようになります。
<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! ここでは、以下のようになります。
<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! ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。
24.4.4.4. CLI を使用したマルチネットワークポリシーの表示
namespace のマルチネットワークポリシーを検査できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしている。 - マルチネットワークポリシーが存在する namespace で作業している。
手順
namespace のマルチネットワークポリシーをリスト表示します。
namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
oc get multi-networkpolicy
$ oc get multi-networkpolicy
Copy to Clipboard Copied! オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。
oc describe multi-networkpolicy <policy_name> -n <namespace>
$ oc describe multi-networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! ここでは、以下のようになります。
<policy_name>
- 検査するマルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。
24.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! ここでは、以下のようになります。
<policy_name>
- マルチネットワークポリシーの名前を指定します。
<namespace>
- オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
Copy to Clipboard Copied!
cluster-admin
権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。
24.4.4.6. デフォルトのすべてのマルチネットワーク拒否ポリシーの作成
これは基本的なポリシーであり、他のデプロイメントされたネットワークポリシーの設定によって許可されたネットワークトラフィック以外のすべてのクロス Pod ネットワークをブロックします。この手順では、デフォルトの deny-by-default
ポリシーを適用します。
cluster-admin
ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。
前提条件
-
クラスターが、
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
ファイルに保存します。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <namespace_name>/<network_name> spec: podSelector: {} policyTypes: - Ingress ingress: []
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: deny-by-default namespace: default
1 annotations: k8s.v1.cni.cncf.io/policy-for: <namespace_name>/<network_name>
2 spec: podSelector: {}
3 policyTypes:
4 - Ingress
5 ingress: []
6 Copy to Clipboard Copied! - 1
namespace: default
は、このポリシーをdefault
namespace にデプロイします。- 2
network_name
: ネットワーク割り当て定義の名前を指定します。- 3
podSelector:
は空です。これは、すべての Pod に一致することを意味します。したがって、ポリシーはデフォルト namespace のすべての Pod に適用されます。- 4
policyTypes:
NetworkPolicy
が関連するルールタイプのリスト。- 5
Ingress
のみのpolicyType
として指定します。- 6
- 指定された
ingress
ルールはありません。これにより、着信トラフィックがすべての Pod にドロップされます。
次のコマンドを入力して、ポリシーを適用します。
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yaml
Copy to Clipboard Copied! 出力例
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
multinetworkpolicy.k8s.cni.cncf.io/deny-by-default created
Copy to Clipboard Copied!
24.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
ファイルに保存します。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-external namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: policyTypes: - Ingress podSelector: matchLabels: app: web ingress: - {}
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-external namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: policyTypes: - Ingress podSelector: matchLabels: app: web ingress: - {}
Copy to Clipboard Copied! 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yaml
Copy to Clipboard Copied! 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-external created
Copy to Clipboard Copied! このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

24.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
ファイルに保存します。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-all-namespaces namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: {}
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-all-namespaces namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: web
1 policyTypes: - Ingress ingress: - from: - namespaceSelector: {}
2 Copy to Clipboard Copied! 注記デフォルトでは、
namespaceSelector
の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yaml
Copy to Clipboard Copied! 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-all-namespaces created
Copy to Clipboard Copied!
検証
次のコマンドを入力して、
default
namespace で 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=80
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをsecondary
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
Copy to Clipboard Copied!
24.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
ファイルに保存します。apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-prod namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: production
apiVersion: k8s.cni.cncf.io/v1beta1 kind: MultiNetworkPolicy metadata: name: web-allow-prod namespace: default annotations: k8s.v1.cni.cncf.io/policy-for: <network_name> spec: podSelector: matchLabels: app: web
1 policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: production
2 Copy to Clipboard Copied! 次のコマンドを入力して、ポリシーを適用します。
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yaml
Copy to Clipboard Copied! 出力例
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
multinetworkpolicy.k8s.cni.cncf.io/web-allow-prod created
Copy to Clipboard Copied!
検証
次のコマンドを入力して、
default
namespace で 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=80
Copy to Clipboard Copied! 次のコマンドを実行して、
prod
namespace を作成します。oc create namespace prod
$ oc create namespace prod
Copy to Clipboard Copied! 次のコマンドを実行して、
prod
namespace にラベルを付けます。oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=production
Copy to Clipboard Copied! 次のコマンドを実行して、
dev
namespace を作成します。oc create namespace dev
$ oc create namespace dev
Copy to Clipboard Copied! 次のコマンドを実行して、
dev
namespace にラベルを付けます。oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testing
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをdev
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
wget: download timed out
wget: download timed out
Copy to Clipboard Copied! 次のコマンドを実行して、
alpine
イメージをprod
namespace にデプロイし、シェルを開始します。oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! 予想される出力
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
Copy to Clipboard Copied!
24.5. Pod の追加のネットワークへの割り当て
クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。
24.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! - 1
- 複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", "namespace": "<namespace>", "default-route": ["<default-route>"] } ]
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
1 "namespace": "<namespace>",
2 "default-route": ["<default-route>"]
3 } ]
Copy to Clipboard Copied!
Pod を作成するには、以下のコマンドを入力します。
<name>
を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yaml
Copy to Clipboard Copied! オプション: アノテーションが
Pod
CR に存在することを確認するには、<name>
を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yaml
Copy to Clipboard Copied! 以下の例では、
example-pod
Pod が追加ネットワークのnet1
に割り当てられています。oc get pod example-pod -o yaml
$ oc get pod example-pod -o yaml apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: macvlan-bridge k8s.v1.cni.cncf.io/network-status: |-
1 [{ "name": "openshift-sdn", "interface": "eth0", "ips": [ "10.128.2.14" ], "default": true, "dns": {} },{ "name": "macvlan-bridge", "interface": "net1", "ips": [ "20.2.2.100" ], "mac": "22:2f:60:a5:f8:00", "dns": {} }] name: example-pod namespace: default spec: ... status: ...
Copy to Clipboard Copied! - 1
k8s.v1.cni.cncf.io/network-status
パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスを説明します。アノテーションの値はプレーンテキストの値として保存されます。
24.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! 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! - 1
<network>
を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
以下の例では、アノテーションで
default-route
パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1" }, { "name": "net2", "default-route": ["192.0.2.1"] }]' spec: containers: - name: example-pod command: ["/bin/bash", "-c", "sleep 2000000000000"] image: centos/tools
apiVersion: v1 kind: Pod metadata: name: example-pod annotations: k8s.v1.cni.cncf.io/networks: '[ { "name": "net1" }, { "name": "net2",
1 "default-route": ["192.0.2.1"]
2 }]' spec: containers: - name: example-pod command: ["/bin/bash", "-c", "sleep 2000000000000"] image: centos/tools
Copy to Clipboard Copied!
デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。
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 cluster
Copy to Clipboard Copied!
以下の YAML は、CNO の設定パラメーターを説明しています。
Cluster Network Operator YAML の設定
name: <name> namespace: <namespace> rawCNIConfig: '{ ... }' type: Raw
name: <name>
namespace: <namespace>
rawCNIConfig: '{
...
}'
type: Raw
以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターを説明しています。
静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト
{ "cniVersion": "0.3.1", "name": "<name>", "plugins": [{ "type": "macvlan", "capabilities": { "ips": true }, "master": "eth0",