ネットワーク

OpenShift Container Platform 4.18

クラスターネットワークの設定および管理

Red Hat OpenShift Documentation Team

概要

この文書では、DNS、Ingress および Pod ネットワークを含む、OpenShift Container Platform のクラスターネットワークを設定し、管理する方法を説明します。

第1章ネットワークについて

OpenShift Container Platform のネットワークの基礎を理解することで、クラスター内での効率的で安全な通信が確保されます。これは、効果的なネットワーク管理に不可欠です。環境内のネットワークに関する重要な要素には、Pod とサービスの通信方法、IP アドレスのロール、サービスディスカバリーのための DNS の使用などがあります。

1.1. OpenShift Container Platform のネットワーク

OpenShift Container Platform では、クラスター内のさまざまなコンポーネント間、および外部クライアントとクラスター間のシームレスな通信が確保されます。ネットワークは、次のコア概念とコンポーネントに依存します。

Pod 間通信
サービス
DNS
Ingress
ネットワーク制御
負荷分散

1.1.1. ネットワークサービスの一般的な慣行

OpenShift Container Platform では、複数の Pod がサービスを提供している場合でも、サービスはクライアントが使用するための IP アドレスを 1 つ作成します。この抽象化により、クライアントに影響を与えることなく、シームレスなスケーリング、フォールトトレランス、ローリングアップグレードが可能になります。

ネットワークセキュリティーポリシーは、クラスター内のトラフィックを管理します。ネットワーク制御を行うことで、namespace 管理者は Pod の Ingress ルールと Egress ルールを定義できます。ネットワーク管理ポリシーを使用すると、クラスター管理者は namespace ポリシーを設定したり、namespace ポリシーをオーバーライドしたり、定義されていない場合にデフォルトのポリシーを設定したりできます。

Egress ファイアウォール設定は、Pod からの送信トラフィックを制御します。これらの設定により、許可された通信のみが実行されます。Ingress ノードファイアウォールは、着信トラフィックを制御することでノードを保護します。さらに、Universal Data Network はクラスター全体のデータトラフィックを管理します。

1.1.2. ネットワーク機能

OpenShift Container Platform は、いくつかのネットワーク機能と拡張機能を提供します。以下に、これらの機能と拡張機能をリストします。

Ingress Operator と Route API: OpenShift Container Platform には、Ingress Controller API を実装する Ingress Operator が含まれています。このコンポーネントは、高度なルーティング設定と負荷分散をサポートする HAProxy ベースの Ingress コントローラーをデプロイおよび管理することで、クラスターサービスへの外部アクセスを可能にします。OpenShift Container Platform は、Route API を使用して、アップストリーム Ingress オブジェクトをルートオブジェクトに変換します。Route は OpenShift Container Platform のネットワーク固有のものですが、サードパーティーの Ingress コントローラーを使用することもできます。
セキュリティーの強化: OpenShift Container Platform は、Egress ファイアウォールや Ingress ノードファイアウォールなどの高度なネットワークセキュリティー機能を提供します。
- Egress ファイアウォール: Egress ファイアウォールは、クラスター内の Pod からの送信トラフィックを制御および制限します。Pod が通信できる外部ホストまたは IP 範囲を制限するルールを設定できます。
- Ingress ノードファイアウォール: Ingress ノードファイアウォールは、Ingress Firewall Operator によって管理され、ノードレベルのファイアウォールルールを提供します。クラスター内の特定のノードにこのファイアウォールを設定して、着信トラフィックがこれらのノードに到達する前にフィルタリングすることで、ノードを脅威から保護できます。
  注記
  OpenShift Container Platform は、Pod 間の通信を保護し、アクセス制御を適用するためのネットワークポリシー、管理ネットワークポリシー、Security Context Constraints (SCC) などのサービスも実装します。
ロールベースのアクセス制御 (RBAC): OpenShift Container Platform は Kubernetes RBAC を拡張して、ネットワークリソースにアクセスして管理できるユーザーをより細かく制御できるようにします。RBAC は、クラスター内のセキュリティーとコンプライアンスの維持に役立ちます。
マルチテナンシーサポート: OpenShift Container Platform は、複数のユーザーとチームがリソースを分離して安全に保ちながら同じクラスターを共有できるようにするマルチテナンシーサポートを提供します。
ハイブリッドおよびマルチクラウド機能: OpenShift Container Platform は、オンプレミス環境、クラウド環境、マルチクラウド環境をまたいでシームレスに動作するように設計されています。この柔軟性により、組織はコンテナー化されたアプリケーションを、さまざまなインフラストラクチャーをまたいでデプロイおよび管理できます。
可観測性と監視: OpenShift Container Platform は、ネットワークの問題の管理とトラブルシューティングに役立つ、統合された可観測性および監視ツールを提供します。これらのツールには、ネットワークメトリクスとログへのロールベースのアクセスが含まれます。
ユーザー定義ネットワーク (UDN): 管理者は、UDN を使用してネットワーク設定をカスタマイズできます。UDN は、ネットワーク分離と IP アドレス管理を強化します。
Egress IP: Egress IP を使用すると、namespace 内の Pod から送信されるすべての Egress トラフィックに固定の送信元 IP アドレスを割り当てることができます。Egress IP は、外部サービスのソース IP アドレスの一貫性を確保することで、セキュリティーとアクセス制御を強化できます。たとえば、Pod が特定の IP アドレスからのトラフィックのみを許可する外部データベースにアクセスする必要がある場合、その Pod の Egress IP を設定してアクセス要件を満たすことができます。
Egress ルーター: Egress ルーターは、クラスターと外部システム間のブリッジとして機能する Pod です。Egress ルーターを使用すると、Pod からのトラフィックを、他の目的で使用されていない特定の IP アドレス経由でルーティングできます。Egress ルーターを使用すると、アクセス制御を適用したり、特定のゲートウェイを経由してトラフィックをルーティングしたりできます。

1.2. ノード、クライアント、クラスターとのネットワーク

ノードは、コントロールプレーンコンポーネント、ワークロードコンポーネント、またはその両方を実行できるクラスター内のマシンです。ノードは、物理サーバーまたは仮想マシンのいずれかです。クラスターは、コンテナー化されたアプリケーションを実行するノードのコレクションです。クライアントは、クラスターと対話するツールおよびユーザーです。

1.2.1. ノードとは

ノードは、コンテナー化されたアプリケーションを実行する物理マシンまたは仮想マシンです。ノードは Pod をホストし、アプリケーションを実行するためのメモリーやストレージなどのリソースを提供します。ノードは Pod 間の通信を可能にします。各 Pod には IP アドレスが割り当てられます。同じノード内の Pod は、IP アドレスを使用して相互に通信できます。ノードは、Pod がクラスター内のサービスを検出して通信できるようにすることで、サービスディスカバリーを容易にします。ノードは、ネットワークトラフィックを Pod 間で分散し、効率的な負荷分散とアプリケーションの高可用性を確保するのに役立ちます。ノードは、内部クラスターネットワークと外部ネットワーク間のブリッジを提供し、外部クライアントがクラスター上で実行されているサービスにアクセスできるようにします。

1.2.2. クラスターとは

クラスターは、コンテナー化されたアプリケーションを実行するために連携して動作するノードのコレクションです。ノードには、コントロールプレーンノードとコンピュートノードが含まれます。

1.2.3. 外部クライアントとは

外部クライアントとは、クラスター内で実行されているサービスやアプリケーションと対話するクラスター外のエンティティーです。外部には、エンドユーザー、外部サービス、外部デバイスが含まれます。エンドユーザーとは、ブラウザーやモバイルデバイスを通じて、クラスター内でホストされている Web アプリケーションにアクセスするユーザーです。外部サービスとは、クラスター内のサービスと (多くの場合は API を介して) 対話する他のソフトウェアシステムまたはアプリケーションです。外部デバイスとは、Internet of Things (IoT) デバイスなど、クラスターサービスと通信する必要があるクラスターネットワーク外のハードウェアです。

1.3. ネットワークの概念とコンポーネント

OpenShift Container Platform のネットワークでは、いくつかの主要なコンポーネントと概念が使用されます。

Pod とサービスは Kubernetes でデプロイ可能な最小単位であり、サービスは Pod セットに安定した IP アドレスと DNS 名を提供します。クラスター内の各 Pod には、一意の IP アドレスが割り当てられます。Pod は、どのノード上にあるかに関係なく、IP アドレスを使用して他の Pod と直接通信します。Pod が破棄および作成されると、Pod の IP アドレスは変更されます。サービスには、一意の IP アドレスも割り当てられます。サービスは、サービスを提供できる Pod に関連付けられます。アクセスされると、サービス IP アドレスは、サービスをサポートする Pod の 1 つにトラフィックを送信することで、Pod に安定してアクセスする方法を提供します。
Route API と Ingress API は、クラスター内のサービスに HTTP、HTTPS、および TLS トラフィックをルーティングするルールを定義します。OpenShift Container Platform は、デフォルトのインストールの一部として Route API と Ingress API の両方を提供しますが、サードパーティーの Ingress コントローラーをクラスターに追加することもできます。
Container Network Interface (CNI) プラグインは、Pod ネットワークを管理して、Pod 間の通信を可能にします。
Cluster Network Operator (CNO) CNO は、クラスターのネットワークプラグインコンポーネントを管理します。CNO を使用すると、Pod ネットワーク CIDR やサービスネットワーク CIDR などのネットワーク構成を設定できます。
DNS Operator は、クラスター内の DNS サービスを管理して、DNS 名で確実にサービスにアクセスできるようにします。
ネットワーク制御は、Pod 間、および Pod と他のネットワークエンドポイント間で許可される通信方法を定義します。これらのポリシーは、トラフィックフローを制御し、Pod 通信のルールを適用することで、クラスターを保護するために役立ちます。
負荷分散は、ネットワークトラフィックを複数のサーバーに分散し、信頼性とパフォーマンスを確保します。
サービスディスカバリーは、クラスター内でサービスが相互に検出して通信するためのメカニズムです。
Ingress Operator は、OpenShift Container Platform Route を使用してルーターを管理し、クラスターサービスへの外部アクセスを有効にします。

関連情報

ネットワークポリシーについて

1.4. Pod の通信方法

Pod は、IP アドレスを使用して通信し、Dynamic Name System (DNS) を使用して Pod またはサービスの IP アドレスを検出します。クラスターは、どの通信を許可するかを制御するさまざまなポリシータイプを使用します。Pod は、Pod 間およびサービスと Pod 間の 2 つの方法で通信します。

1.4.1. Pod 間通信

Pod 間通信とは、クラスター内で Pod が相互に通信する機能です。これは、マイクロサービスと分散アプリケーションが動作するために不可欠な機能です。

クラスター内の各 Pod には、他の Pod と直接通信するために使用する一意の IP アドレスが割り当てられます。Pod 間通信は、Pod がデータを交換したり、共同でタスクを実行したりする必要があるクラスター内通信に役立ちます。たとえば、Pod A は Pod B の IP アドレスを使用して Pod B に要求を直接送信できます。Pod は、ネットワークアドレス変換 (NAT) なしでフラットネットワーク経由で通信できます。これにより、ノードをまたいだ Pod 間のシームレスな通信が可能になります。

1.4.1.1. 例: Pod 間通信の制御

複数の Pod を持つマイクロサービスベースのアプリケーションでは、フロントエンド Pod はバックエンド Pod と通信してデータを取得する必要があります。直接またはサービスを介して Pod 間通信を使用することで、これらの Pod は効率的に情報を交換できます。

Pod 間の通信を制御し、保護するために、ネットワーク制御を定義できます。そのような制御は、Pod が相互に対話する方法をラベルおよびセレクターに基づき指定することで、セキュリティーとコンプライアンスの要件を適用します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-some-pods
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: app
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend
      ports:
        - protocol: TCP
          port: 80

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-some-pods
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: app
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend
      ports:
        - protocol: TCP
          port: 80

Copy to clipboard

1.4.2. サービスと Pod 間の通信

サービスと Pod 間の通信により、サービスがトラフィックを適切な Pod に確実にルーティングできるようになります。サービスは、Pod の論理セットを定義し、IP アドレスや DNS 名などの安定したエンドポイントを提供するオブジェクトです。Pod の IP アドレスは変更される可能性があります。サービスは Pod の IP アドレスを抽象化して、IP アドレスが変更された場合でもアプリケーションコンポーネントに一貫してアクセスできるようにします。

サービスと Pod 間の通信の主な概念は次のとおりです。

エンドポイント: エンドポイントは、サービスに関連付けられている Pod の IP アドレスとポートを定義します。
セレクター: セレクターは、キーと値のペアなどのラベルを使用して、サービスがターゲットとするオブジェクトセットを選択するための条件を定義します。
サービス: サービスは、Pod セットに対して安定した IP アドレスと DNS 名を提供します。この抽象化により、他のコンポーネントは個々の Pod ではなくサービスと通信できるようになります。
サービスディスカバリー: DNS によりサービスが検出可能になります。サービスが作成されると、DNS 名が割り当てられます。他の Pod はこの DNS 名を検出し、それを使用してサービスと通信します。
サービスタイプ: サービスタイプは、クラスター内外でサービスがどのように公開されるかを制御します。
- ClusterIP は、内部クラスター IP 上でサービスを公開します。これはデフォルトのサービスタイプであり、クラスター内からのみサービスにアクセスできるようになります。
- NodePort は、各ノードの IP のサービスを静的ポートで公開することにより、外部トラフィックがサービスにアクセスできるようにします。
- LoadBalancer は、クラウドプロバイダーのロードバランサーを使用してサービスを外部に公開します。

サービスはセレクターを使用して、トラフィックを受信する Pod を識別します。セレクターは Pod のラベルを照合して、どの Pod がサービスの一部であるかを決定します。例: セレクター app: myapp を持つサービスは、ラベル app: myapp を持つすべての Pod にトラフィックをルーティングします。

エンドポイントは、サービスセレクターに一致する Pod の現行 IP アドレスを反映するように動的に更新されます。{product-name} はこれらのエンドポイントを維持し、サービスがトラフィックを正しい Pod にルーティングするようにします。

通信フローとは、Kubernetes のサービスがトラフィックを適切な Pod にルーティングするときに発生する一連の手順とインタラクションを指します。サービスと Pod 間の通信の一般的な通信フローは次のとおりです。

サービスの作成: サービスの作成時に、サービスタイプ、サービスがリッスンするポート、およびセレクターラベルを定義します。

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app: myapp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app: myapp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080

Copy to clipboard

DNS 解決: 各 Pod には、他の Pod がサービスと通信するために使用できる DNS 名があります。たとえば、my-app namespace 内の my-service という名前のサービスの DNS 名は my-service.my-app.svc.cluster.local になります。
トラフィックルーティング: Pod がサービスの DNS 名に要求を送信すると、OpenShift Container Platform はその名前をサービスの ClusterIP に解決します。次に、サービスはエンドポイントを使用して、セレクターに一致する Pod の 1 つにトラフィックをルーティングします。
負荷分散: サービスは基本的な負荷分散も提供します。着信トラフィックを、セレクターに一致するすべての Pod に分散します。これにより、1 つの Pod にトラフィックが過剰に集中して負荷がかかることがなくなります。

1.4.2.1. 例: サービスと Pod 間の通信を制御する

クラスターは、フロントエンドおよびバックエンドの 2 つのコンポーネントを持つマイクロサービスベースのアプリケーションを実行しています。フロントエンドは、データを取得するためにバックエンドと通信する必要があります。

手順

バックエンドサービスを作成します。

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Copy to clipboard

バックエンド Pod を設定します。

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  labels:
    app: backend
spec:
  containers:
    - name: backend-container
      image: my-backend-image
      ports:
        - containerPort: 8080

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  labels:
    app: backend
spec:
  containers:
    - name: backend-container
      image: my-backend-image
      ports:
        - containerPort: 8080

Copy to clipboard

フロントエンド通信を確立します。
これでフロントエンド Pod は、DNS 名 backend.default.svc.cluster.local を使用してバックエンドサービスと通信できるようになりました。このサービスは、トラフィックが確実にバックエンド Pod の 1 つにルーティングされるようにします。

サービスと Pod 間の通信により、Pod IP の管理の複雑さが抽象化され、クラスター内で信頼性が高く効率的な通信が確保されます。

1.5. サポートされているロードバランサー

負荷分散は、着信ネットワークトラフィックを複数のサーバーに分散し、1 つのサーバーに過度の負荷がかからないようにすることで、クラスターの健全性と効率を保ちます。ロードバランサーは負荷分散を実行するデバイスです。クライアントとサーバーの間の仲介として機能し、事前に定義されたルールに基づきトラフィックを管理および誘導します。

OpenShift Container Platform は、次のタイプのロードバランサーをサポートします。

Classic Load Balancer (CLB)
Elastic Load Balancing (ELB)
Network Load Balancer (NLB)
Application Load Balancer (ALB)

ELB は、AWS ルーターのデフォルトのロードバランサータイプです。CLB は、セルフマネージド環境のデフォルトです。NLB は、Red Hat OpenShift Service on AWS (ROSA) のデフォルトです。

重要

ALB は、アプリケーションの前で使用しますが、ルーターの前では使用しないでください。ALB を使用するには、AWS Load Balancer Operator アドオンが必要です。この Operator は、すべての Amazon Web Services (AWS) リージョンまたはすべての OpenShift Container Platform プロファイルでサポートされているわけではありません。

1.5.1. ロードバランサーの設定

クラスターのインストール時に、デフォルトのロードバランサータイプを定義できます。インストール後、クラスターのインストール時に定義したグローバルプラットフォーム設定でカバーされていない特定の方法で動作するように、Ingress コントローラーを設定できます。

1.5.1.1. デフォルトのロードバランサータイプを定義する

クラスターのインストール時に、使用するロードバランサーのタイプを指定できます。クラスターのインストール時に選択したロードバランサーのタイプは、クラスター全体に適用されます。

この例では、AWS 上にデプロイされたクラスターのデフォルトのロードバランサータイプを定義する方法を示します。この手順は、サポートされている他のプラットフォームにも適用できます。

apiVersion: v1
kind: Network
metadata:
   name: cluster
platform:
  aws: 1
    lbType: classic 2

apiVersion: v1
kind: Network
metadata:
   name: cluster
platform:
  aws: 1
    lbType: classic 2

Copy to clipboard

1: platform キーは、クラスターをデプロイしたプラットフォームを表します。この例では aws を使用します。
2: lbType キーは、ロードバランサーのタイプを表します。この例では、Classic Load Balancer (classic) を使用します。

1.5.1.2. Ingress コントローラーのロードバランサーの動作を指定する

クラスターをインストールした後、Ingress コントローラーを設定して、サービスを外部ネットワークに公開する方法を指定できます。これにより、ロードバランサーの設定と動作をより適切に制御できるようになります。

注記

Ingress コントローラーのロードバランサー設定を変更すると、インストール時に指定したロードバランサー設定がオーバーライドされる可能性があります。

apiVersion: v1
kind: Network
metadata:
  name: cluster
endpointPublishingStrategy:
  loadBalancer: 1
    dnsManagementPolicy: Managed
    providerParameters:
      aws:
        classicLoadBalancer: 2
          connectionIdleTimeout: 0s
        type: Classic
      type: AWS
    scope: External
  type: LoadBalancerService

apiVersion: v1
kind: Network
metadata:
  name: cluster
endpointPublishingStrategy:
  loadBalancer: 1
    dnsManagementPolicy: Managed
    providerParameters:
      aws:
        classicLoadBalancer: 2
          connectionIdleTimeout: 0s
        type: Classic
      type: AWS
    scope: External
  type: LoadBalancerService

Copy to clipboard

1: `loadBalancer' フィールドは、ロードバランサー構成の設定を指定します。
2: classicLoadBalancer フィールドは、ロードバランサーを classic に設定します。これには、AWS 上の CLB に固有の設定が含まれます。

1.6. Domain Name System (DNS)

Domain Name System (DNS) は、www.example.com などの人間が理解しやすいドメイン名を、ネットワーク上のコンピューターを識別する IP アドレスに変換するために使用される、階層型かつ分散型の命名システムです。DNS は、サービスディスカバリーと名前解決において重要な役割を果たします。

OpenShift Container Platform は、確実に DNS 名でサービスにアクセスできるようにするため、組み込みの DNS を提供しています。これにより、基盤となる IP アドレスが変更された場合でも、安定した通信を維持できます。Pod を起動すると、サービス名、IP アドレス、ポートの環境変数が自動的に作成され、Pod は他のサービスと通信できるようになります。

1.6.1. 重要な DNS 用語

CoreDNS: CoreDNS は DNS サーバーであり、サービスと Pod の名前解決を提供します。
DNS 名: サービスには、namespace と名前に基づいて DNS 名が割り当てられます。たとえば、default namespace にある my-service という名前のサービスの DNS 名は my-service.default.svc.cluster.local になります。
ドメイン名: ドメイン名は、example.com など、Web サイトやサービスにアクセスするために使用されるわかりやすい名前です。
IP アドレス: IP アドレスは、通信に IP を使用するコンピューターネットワークに接続された各デバイスに割り当てられる数値ラベルです。IPv4 アドレスの例は 192.0.2.1 です。IPv6 アドレスの例は 2001:0db8:85a3:0000:0000:8a2e:0370:7334 です。
DNS サーバー: DNS サーバーは、DNS レコードの保存に特化されたサーバーです。これらのレコードは、ドメイン名を IP アドレスにマッピングします。ブラウザーにドメイン名を入力すると、コンピューターは DNS サーバーに接続して対応する IP アドレスを見つけます。
解決プロセス: DNS クエリーが DNS リゾルバーに送信されます。次に、DNS リゾルバーは一連の DNS サーバーに接続して、ドメイン名に関連付けられた IP アドレスを見つけます。リゾルバーは、<namespace>.svc.cluster.local、svc.cluster.local、cluster.local などの一連のドメインで、名前の使用を試みます。このプロセスは、最初に一致した時点で停止します。IP アドレスはブラウザーに返され、その IP アドレスを使用して Web サーバーに接続します。

1.6.2. 例: DNS のユースケース

この例では、フロントエンドアプリケーションが 1 つの Pod セットで実行され、バックエンドサービスが別の Pod セットで実行されています。フロントエンドアプリケーションは、バックエンドサービスと通信する必要があります。バックエンド Pod に安定した IP アドレスと DNS 名を付与するサービスを作成します。フロントエンド Pod は、個々の Pod IP アドレスが変更されても、この DNS 名を使用してバックエンドサービスにアクセスします。

バックエンド Pod 用のサービスを作成することにより、フロントエンド Pod がバックエンドサービスと通信するために使用できる、安定した IP と DNS 名 (backend-service.default.svc.cluster.local) が提供されます。この設定により、個々の Pod の IP アドレスが変更された場合でも、通信の一貫性と信頼性が維持されます。

次の手順は、DNS を使用してバックエンドサービスと通信するように、フロントエンド Pod を設定する方法の例を示しています。

バックエンドサービスを作成します。

バックエンド Pod をデプロイします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment
  labels:
    app: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: backend-container
          image: your-backend-image
          ports:
            - containerPort: 8080

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment
  labels:
    app: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: backend-container
          image: your-backend-image
          ports:
            - containerPort: 8080

Copy to clipboard

バックエンド Pod を公開するサービスを定義します。

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Copy to clipboard

フロントエンド Pod を作成します。

フロントエンド Pod を定義します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-deployment
  labels:
    app: frontend
  spec:
    replicas: 3
    selector:
    matchLabels:
      app: frontend
   template:
   metadata:
     labels:
       app: frontend
   spec:
     containers:
       - name: frontend-container
         image: your-frontend-image
         ports:
           - containerPort: 80

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-deployment
  labels:
    app: frontend
  spec:
    replicas: 3
    selector:
    matchLabels:
      app: frontend
   template:
   metadata:
     labels:
       app: frontend
   spec:
     containers:
       - name: frontend-container
         image: your-frontend-image
         ports:
           - containerPort: 80

Copy to clipboard

Pod 定義をクラスターに適用します。

oc apply -f frontend-deployment.yaml

$ oc apply -f frontend-deployment.yaml

Copy to clipboard

フロントエンドをバックエンドと通信するように設定します。
フロントエンドアプリケーションコードでは、バックエンドサービスの DNS 名を使用して要求を送信します。たとえば、フロントエンドアプリケーションがバックエンド Pod からデータを取得する必要がある場合、アプリケーションには次のコードが含まれる可能性があります。
```
fetch('http://backend-service.default.svc.cluster.local/api/data')
  .then(response => response.json())
  .then(data => console.log(data));
```
```
fetch('http://backend-service.default.svc.cluster.local/api/data')
  .then(response => response.json())
  .then(data => console.log(data));
```
Copy to clipboardCopied

1.7. ネットワーク制御

ネットワーク制御は、Pod 間および Pod と他のネットワークエンドポイント間の通信を許可するためのルールを定義します。ネットワーク制御はネットワークレベルで実装され、許可されたトラフィックのみが Pod 間で流れるようにします。これにより、トラフィックフローを制限し、不正アクセスを防止することで、クラスターが保護されます。

管理ネットワークポリシー (ANP): ANP は、クラスターをスコープ指定したカスタムリソース定義 (CRD) です。クラスター管理者は、ANP を使用してクラスターレベルでネットワークポリシーを定義できます。通常のネットワークポリシーオブジェクトを使用してこれらのポリシーをオーバーライドすることはできません。これらのポリシーは、クラスター全体に厳格なネットワークセキュリティールールを適用します。管理者は、ANP で Ingress ルールと Egress ルールを指定して、クラスターに出入りするトラフィックを制御できます。
Egress ファイアウォール: Egress ファイアウォールは、クラスターから出る Egress トラフィックを制限します。管理者は、このファイアウォールを使用して、クラスター内から Pod がアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーを設定して、特定の IP 範囲、DNS 名、または外部サービスへのトラフィックを許可または拒否できます。これにより、外部リソースへの不正アクセスを防ぎ、許可されたトラフィックのみがクラスターから出るようにできます。
Ingress ノードファイアウォール: Ingress ノードファイアウォールは、クラスター内のノードへの Ingress トラフィックを制御します。管理者は、このファイアウォールを使用して、ノードへの接続を開始できる外部ホストを制限するルールを定義します。これにより、不正アクセスからノードを保護し、信頼できるトラフィックのみがクラスターに到達できるようになります。

1.8. ルートと Ingress

ルートおよび Ingress は、どちらもアプリケーションを外部トラフィックに公開するために使用されます。ただし、その目的は若干異なり、機能も異なります。

1.8.1. ルート

ルートは、外部クライアントが名前でサービスにアクセスできるように、ホスト名でサービスを公開する OpenShift Container Platform リソースに固有のものです。

ルートは、ホスト名をサービスにマッピングします。ルート名のマッピングにより、外部クライアントはホスト名を使用してサービスにアクセスできます。ルートは、サービスに向けられたトラフィックの負荷分散を行います。ルートで使用されるホスト名は、ルーターの IP アドレスに解決されます。その後、ルートはトラフィックを適切なサービスに転送します。ルートは、SSL/TLS を使用してクライアントとサービス間のトラフィックを暗号化することで保護することもできます。

1.8.2. Ingress

Ingress は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングなどの高度なルーティング機能を提供するリソースです。Ingress に関する重要なポイントは次のとおりです。

HTTP/HTTPS ルーティング: Ingress を使用して、クラスター内のサービスに HTTP および HTTPS トラフィックをルーティングするためのルールを定義できます。
負荷分散: NGINX や HAProxy などの Ingress コントローラーは、ユーザーが定義したルールに基づいてトラフィックルーティングと負荷分散を管理します。
SSL/TLS Termination: SSL/TLS Termination は、着信 SSL/TLS トラフィックをバックエンドサービスに渡す前に復号するプロセスです。
複数のドメインとパス: Ingress は、複数のドメインとパスのトラフィックルーティングをサポートします。

1.8.3. ルートと Ingress の比較

ルートは、Ingress に比べて柔軟性が高く、高度な機能を提供します。そのため、ルートは複雑なルーティングシナリオに適しています。ルートは、特に基本的な外部アクセスのニーズの場合、簡単に設定および使用できます。Ingress は、よりシンプルで直接的な外部アクセスによく使用されます。ルートは、高度なルーティングと SSL/TLS Termination を必要とするより複雑なシナリオに使用されます。

1.8.4. 例: ウェブアプリケーションを公開するためのルートと Ingress の設定

OpenShift Container Platform クラスター上で Web アプリケーションが実行されています。外部ユーザーがアプリケーションにアクセスできるようにしたいと考えています。アプリケーションは特定のドメイン名を通じてアクセスできる必要があり、トラフィックは TLS を使用して安全に暗号化される必要があります。次の例は、ルートと Ingress の両方を設定して、Web アプリケーションを外部トラフィックに安全に公開する方法を示しています。

1.8.4.1. ルートの作成

新しいプロジェクトを作成する。
```
oc new-project webapp-project
```
```
$ oc new-project webapp-project
```
Copy to clipboardCopied

Web アプリケーションをデプロイします。

oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp

$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git --name=webapp

Copy to clipboard

ルートを使用してサービスを公開します。

oc expose svc/webapp --hostname=webapp.example.com

$ oc expose svc/webapp --hostname=webapp.example.com

Copy to clipboard

TLS を使用してルートを保護します。

証明書と鍵を使用して TLS シークレットを作成します。

oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key

$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key

Copy to clipboard

TLS シークレットを使用するようにルートを更新します。

oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}'

$ oc patch route/webapp -p '{"spec":{"tls":{"termination":"edge","certificate":"path/to/tls.crt","key":"path/to/tls.key"}}}'

Copy to clipboard

1.8.4.2. Ingress の設定

Ingress リソースを作成します。
Ingress コントローラーがクラスターにインストールされ、実行されていることを確認します。

Web アプリケーション用のサービスを作成します。まだ作成されていない場合は、アプリケーションをサービスとして公開します。

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
  namespace: webapp-project
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
  namespace: webapp-project
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Copy to clipboard

Ingress リソースを作成します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: webapp-project
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
    - host: webapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp-service
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: webapp-project
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
    - host: webapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp-service
                port:
                  number: 80

Copy to clipboard

TLS を使用して Ingress を保護します。

証明書と鍵を使用して TLS シークレットを作成します。

oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project

$ oc create secret tls webapp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n webapp-project

Copy to clipboard

TLS シークレットを使用するように Ingress リソースを更新します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: webapp-project
spec:
  tls: 1
    - hosts:
        - webapp.example.com
      secretName: webapp-tls 2
  rules:
    - host: webapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp-service
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: webapp-project
spec:
  tls: 1
    - hosts:
        - webapp.example.com
      secretName: webapp-tls 2
  rules:
    - host: webapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp-service
                port:
                  number: 80

Copy to clipboard

1: TLS セクションで TLS 設定を指定します。
2: secretName フィールドは、TLS 証明書と鍵が含まれる Kubernetes シークレットの名前です。

1.9. セキュリティーとトラフィック管理

管理者は、ClusterIP、NodePort、LoadBalaner などのサービスタイプと、Ingress や Route などの API リソースを使用して、アプリケーションを外部トラフィックに公開し、ネットワーク接続を保護できます。Ingress Operator と Cluster Network Operator (CNO) は、これらのサービスとリソースの設定と管理に役立ちます。Ingress Operator は、1 つ以上の Ingress Controller をデプロイおよび管理します。これらのコントローラーは、外部の HTTP および HTTPS トラフィックをクラスター内のサービスにルーティングします。CNO は、Pod ネットワーク、サービスネットワーク、DNS などのクラスターネットワークコンポーネントをデプロイおよび管理します。

1.9.1. アプリケーションの公開

ClusterIP は、クラスター内の内部 IP でサービスを公開し、クラスター内の他のサービスのみがクラスターにアクセスできるようにします。NodePort サービスタイプは、各ノードの IP 上の静的ポートでサービスを公開します。このサービスタイプでは、外部トラフィックがサービスにアクセスできます。ロードバランサーは通常、MetalLB を使用するクラウドまたはベアメタル環境で使用されます。このサービスタイプは、外部トラフィックをサービスにルーティングする外部ロードバランサーをプロビジョニングします。ベアメタル環境では、MetalLB は VIP と ARP アナウンスメントまたは BGP アナウンスメントを使用します。

Ingress は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングなどのサービスへの外部アクセスを管理する API オブジェクトです。NGINX や HAProxy などの Ingress コントローラーは、Ingress API を実装し、ユーザーが定義したルールに基づいてトラフィックルーティングを処理します。

1.9.2. 接続のセキュリティー保護

Ingress コントローラーは、SSL/TLS Termination を管理し、着信 SSL/TLS トラフィックをバックエンドサービスに渡す前に復号します。SSL/TLS Termination により、暗号化/復号プロセスがアプリケーション Pod からオフロードされます。TLS 証明書を使用して、クライアントとサービス間のトラフィックを暗号化できます。cert-manager などのツールを使用して証明書を管理し、証明書の配布と更新を自動化できます。

SNI フィールドがある場合、ルートは TLS トラフィックを Pod に渡します。このプロセスにより、HTTP/HTTPS だけでなく TLS を使用して、TCP を実行するサービスを公開できるようになります。サイト管理者は証明書を一元管理でき、権限を持たないアプリケーション開発者による秘密鍵の読み取りを許可できます。

Route API を使用すると、クラスターが管理する証明書を使用してルーターから Pod へのトラフィックを暗号化できます。これにより、内部の通信区間の暗号化は維持されたまま、外部証明書が一元管理されます。アプリケーション開発者は、アプリケーション用の一意の秘密鍵を受け取ります。これらの鍵は Pod 内にシークレットとしてマウントできます。

ネットワーク制御は、Pod 間および Pod と他のネットワークエンドポイント間で通信する方法のルールを定義します。これにより、クラスター内のトラフィックフローが制御され、セキュリティーが強化されます。この制御はネットワークプラグインレベルで実装され、許可されたトラフィックのみが Pod 間で流れるようにします。

ロールベースのアクセス制御 (RBAC) は、権限を管理し、クラスター内のリソースにアクセスできるユーザーを制御します。サービスアカウントは、API にアクセスする Pod にアイデンティティーを提供します。RBAC を使用すると、各 Pod が実行できる操作を細かく制御できます。

1.9.3. 例: アプリケーションの公開と接続の保護

この例では、クラスター内で実行されている Web アプリケーションに外部ユーザーがアクセスする必要があります。

ニーズに合うサービスタイプを使用して、サービスを作成し、アプリケーションをサービスとして公開します。

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  type: LoadBalancer
  selector:
    app: my-web-app
  ports:
  - port: 80
    targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  type: LoadBalancer
  selector:
    app: my-web-app
  ports:
  - port: 80
    targetPort: 8080

Copy to clipboard

HTTP/HTTPS トラフィックを管理し、サービスにルーティングするための Ingress リソースを定義します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-web-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: mywebapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-app
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-web-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: mywebapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-app
            port:
              number: 80

Copy to clipboard

Ingress に TLS を設定して、安全で暗号化された接続を確保します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-web-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - mywebapp.example.com
    secretName: my-tls-secret
  rules:
  - host: mywebapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-app
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-web-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - mywebapp.example.com
    secretName: my-tls-secret
  rules:
  - host: mywebapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-app
            port:
              number: 80

Copy to clipboard

1.9.4. サービスタイプと API リソースの選択

サービスタイプと API リソースには、アプリケーションの公開とネットワーク接続の保護に関連するさまざまな利点があります。適切なサービスタイプまたは API リソースを活用することで、アプリケーションの公開方法を効果的に管理し、内部クライアントと外部クライアントの両方に対して安全で信頼性の高いアクセスを確保できます。

OpenShift Container Platform は、次のサービスタイプと API リソースをサポートしています。

サービスタイプ
- ClusterIP は、内部のみの公開を目的としています。容易にセットアップでき、クラスター内のサービスにアクセスするための安定した内部 IP アドレスを提供します。ClusterIP は、クラスター内のサービス間の通信に適しています。
- NodePort は、各ノードの IP 上のサービスを静的ポートで公開することで、外部アクセスを許可します。容易にセットアップでき、開発やテストに役立ちます。NodePort は、クラウドプロバイダーのロードバランサーを必要としない単純な外部アクセスに適しています。
- LoadBalancer は、トラフィックを複数のノードに分散するために、外部ロードバランサーを自動的にプロビジョニングします。信頼性と可用性の高いアクセスを必要とする実稼働環境に最適です。
- ExternalName はサービスを外部 DNS 名にマッピングし、クラスター外のサービスに、DNS 名を使用してアクセスできるようにします。外部サービスやレガシーシステムをクラスターと統合する場合に適しています。
- Headless サービスは、安定した ClusterIP を提供せずに Pod IP のリストを返す DNS 名です。これは、ステートフルアプリケーションや、個々の Pod IP への直接アクセスが必要なシナリオに最適です。
API リソース
- Ingress は、負荷分散、SSL/TLS Termination、名前ベースの仮想ホスティングをサポートし、HTTP および HTTPS トラフィックのルーティングを制御します。サービス単独よりも柔軟性が高く、複数のドメインとパスをサポートします。複雑なルーティングが必要な場合、Ingress が最適です。
- Route は Ingress に似ていますが、さらに TLS 再暗号化やパススルーなどの追加機能を提供します。これを使用することで、サービスの外部公開プロセスが単純化されます。Route は、統合された証明書管理などの高度な機能が必要な場合に最適です。

簡単にサービスを外部トラフィックに公開できる方法が必要な場合は、おそらく Route または Ingress が最適な選択肢です。これらのリソースは、namespace 管理者または開発者が管理できます。最も簡単な方法として、ルートを作成し、その外部 DNS 名を確認し、外部 DNS 名を指す CNAME を持つように DNS を設定できます。

HTTP/HTTPS/TLS の場合、Route または Ingress で十分です。それ以外の場合はより複雑で、クラスター管理者はポートがアクセス可能であることや MetalLB が設定されていることを確認する必要があります。クラウド環境または適切に設定されたベアメタル環境の場合、LoadBalancer サービスも選択肢として検討できます。

第2章ホストへのアクセス

OpenShift Container Platform インスタンスにアクセスして、セキュアシェル (SSH) アクセスでコントロールプレーンノードにアクセスするために bastion ホストを作成する方法を学びます。

2.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 clipboardCopied

第3章ネットワークダッシュボード

ネットワークメトリクスは、OpenShift Container Platform Web コンソール内のダッシュボードから、Observe → Dashboards で表示できます。

3.1. Network Observability Operator

Network Observability Operator がインストールされている場合は、Dashboards ドロップダウンリストから Netobserv ダッシュボードを選択すると、ネットワークトラフィックメトリクスダッシュボードが表示されます。この ダッシュボード で利用できるメトリクスの詳細は、ネットワーク可観測性メトリクスのダッシュボードを参照してください。

3.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 です。

3.3. Ingress Operator ダッシュボード

Ingress Operator によって処理されるネットワークメトリクスをダッシュボードから表示できます。これには、次のようなメトリクスが含まれます。

受信および送信の帯域幅
HTTP エラーレート
HTTP サーバーの応答遅延

これらの Ingress メトリクスを表示するには、Dashboards ドロップダウンリストから Networking/Ingress を選択します。Top 10 Per Route、Top 10 Per Namespace、Top 10 Per Shard のカテゴリーの Ingress メトリクスを表示できます。

第4章ネットワーク Operator

4.1. Kubernetes NMState Operator

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

重要

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

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

OpenShift Container Platform で NMState を使用する前に、Kubernetes NMState Operator をインストールする必要があります。

注記

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

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

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

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

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

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

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

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

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

前提条件

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

手順

Operators → OperatorHub を選択します。
All Items の下の検索フィールドに、nmstate と入力し、Enter をクリックして Kubernetes NMState Operator を検索します。
Kubernetes NMState Operator の検索結果をクリックします。
Install をクリックして、Install Operator ウィンドウを開きます。
Install をクリックして Operator をインストールします。
Operator のインストールが完了したら、View Operator をクリックします。
Provided APIs で Create Instance をクリックし、kubernetes-nmstate のインスタンスを作成するダイアログボックスを開きます。
ダイアログボックスの Name フィールドで、インスタンスの名前が nmstate であることを確認します。
注記
名前の制限は既知の問題です。インスタンスはクラスター全体のシングルトンです。
デフォルト設定を受け入れ、Create をクリックしてインスタンスを作成します。

概要

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

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

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

前提条件

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

手順

nmstate Operator namespace を作成します。

cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
spec:
  finalizers:
  - kubernetes
EOF

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
spec:
  finalizers:
  - kubernetes
EOF

Copy to clipboard

OperatorGroup を作成します。

cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
  - openshift-nmstate
EOF

$ cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
  - openshift-nmstate
EOF

Copy to clipboard

nmstate Operator にサブスクライブします。

cat << EOF| oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: stable
  installPlanApproval: Automatic
  name: kubernetes-nmstate-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: stable
  installPlanApproval: Automatic
  name: kubernetes-nmstate-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to clipboard

nmstate Operator デプロイメントの ClusterServiceVersion (CSV) ステータスが Succeeded であることを確認します。

oc get clusterserviceversion -n openshift-nmstate \
 -o custom-columns=Name:.metadata.name,Phase:.status.phase

$ oc get clusterserviceversion -n openshift-nmstate \
 -o custom-columns=Name:.metadata.name,Phase:.status.phase

Copy to clipboard

出力例

Name                                                          Phase
kubernetes-nmstate-operator.4.18.0-202210210157  Succeeded

Name                                                          Phase
kubernetes-nmstate-operator.4.18.0-202210210157  Succeeded

Copy to clipboard

nmstate Operator のインスタンスを作成します。

cat << EOF | oc apply -f -
apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
EOF

$ cat << EOF | oc apply -f -
apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
EOF

Copy to clipboard

NMState Operator のすべての Pod が Running 状態であることを確認します。

oc get pod -n openshift-nmstate

$ oc get pod -n openshift-nmstate

Copy to clipboard

出力例

Name                                      Ready   Status   Restarts  Age
pod/nmstate-handler-wn55p                 1/1     Running  0         77s
pod/nmstate-operator-f6bb869b6-v5m92      1/1     Running  0         4m51s
...

Name                                      Ready   Status   Restarts  Age
pod/nmstate-handler-wn55p                 1/1     Running  0         77s
pod/nmstate-operator-f6bb869b6-v5m92      1/1     Running  0         4m51s
...

Copy to clipboard

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

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

注記

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

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

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

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

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

Copy to clipboard

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

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

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

Copy to clipboard

前提条件

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

手順

OpenShift Container Platform Web コンソールの Developer パースペクティブからメトリクスを表示する場合は、次のタスクを実行します。
1. Observe をクリックします。
2. 特定のプロジェクトのメトリクスを表示するには、Project: リストでプロジェクトを選択します。たとえば、openshift-nmstate です。
3. Metrics タブをクリックします。
4. プロット上のメトリクスを視覚化するには、Select query リストからクエリーを選択するか、Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。
  注記
  Developer パースペクティブでは、1 度に 1 つのクエリーのみを実行できます。
OpenShift Container Platform Web コンソールの Administrator パースペクティブからメトリクスを表示する場合は、次のタスクを実行します。
1. Observe → Metrics をクリックします。
2. Expression フィールドに kubernetes_nmstate_features_applied と入力します。
3. Add query をクリックし、Run queries をクリックします。
視覚化されたメトリクスを調べるには、次のいずれかのタスクを実行します。
1. プロットを拡大して時間範囲を変更するには、次のいずれかのタスクを実行します。
  - 時間範囲を視覚的に選択するには、プロットをクリックして水平にドラッグします。
  - 時間範囲を選択するには、コンソールの左上にあるメニューを使用します。
2. 時間の範囲をリセットするには、Reset zoom を選択します。
3. 特定の時点におけるすべてのクエリーの出力を表示するには、その時点でプロット上にマウスカーソルを置きます。クエリー出力がポップアップボックスに表示されます。

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

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

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

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

前提条件

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

手順

次のコマンドを実行して、Subcription リソースに対する Kubernetes NMState Operator のサブスクリプションを解除します。
```
oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
```
```
$ oc delete --namespace openshift-nmstate subscription kubernetes-nmstate-operator
```
Copy to clipboardCopied

Kubernetes NMState Operator に関連付けられている ClusterServiceVersion (CSV) リソースを見つけます。

oc get --namespace openshift-nmstate clusterserviceversion

$ oc get --namespace openshift-nmstate clusterserviceversion

Copy to clipboard

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

NAME                              	  DISPLAY                   	VERSION   REPLACES     PHASE
kubernetes-nmstate-operator.v4.18.0   Kubernetes NMState Operator   4.18.0           	   Succeeded

NAME                              	  DISPLAY                   	VERSION   REPLACES     PHASE
kubernetes-nmstate-operator.v4.18.0   Kubernetes NMState Operator   4.18.0           	   Succeeded

Copy to clipboard

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

oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0

$ oc delete --namespace openshift-nmstate clusterserviceversion kubernetes-nmstate-operator.v4.18.0

Copy to clipboard

次のコマンドを実行して、nmstate CR と関連する Deployment リソースを削除します。

oc -n openshift-nmstate delete nmstate nmstate

$ oc -n openshift-nmstate delete nmstate nmstate

Copy to clipboard

oc delete --all deployments --namespace=openshift-nmstate

$ oc delete --all deployments --namespace=openshift-nmstate

Copy to clipboard

nmstate CR を削除した後、console.operator.openshift.io/cluster CR から nmstate-console-plugin コンソールプラグイン名を削除します。
1. 次のコマンドを実行して、有効なプラグインのリスト内に存在する nmstate-console-plugin エントリーの位置を保存します。次のコマンドは、jq CLI ツールを使用して、エントリーのインデックスを INDEX という名前の環境変数に保存します。
```
INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
```
```
INDEX=$(oc get console.operator.openshift.io cluster -o json | jq -r '.spec.plugins | to_entries[] | select(.value == "nmstate-console-plugin") | .key')
```
  Copy to clipboardCopied
2. 次のパッチコマンドを実行して、console.operator.openshift.io/cluster CR から nmstate-console-plugin エントリーを削除します。
```
oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]" 1
```
```
$ oc patch console.operator.openshift.io cluster --type=json -p "[{\"op\": \"remove\", \"path\": \"/spec/plugins/$INDEX\"}]" 1
```
  Copy to clipboardCopied
  1
  INDEX は補助変数です。この変数には別の名前を指定できます。

次のコマンドを実行して、nmstates.nmstate.io などのカスタムリソース定義 (CRD) をすべて削除します。

oc delete crd nmstates.nmstate.io

$ oc delete crd nmstates.nmstate.io

Copy to clipboard

oc delete crd nodenetworkconfigurationenactments.nmstate.io

$ oc delete crd nodenetworkconfigurationenactments.nmstate.io

Copy to clipboard

oc delete crd nodenetworkstates.nmstate.io

$ oc delete crd nodenetworkstates.nmstate.io

Copy to clipboard

oc delete crd nodenetworkconfigurationpolicies.nmstate.io

$ oc delete crd nodenetworkconfigurationpolicies.nmstate.io

Copy to clipboard

namespace を削除します。

oc delete namespace kubernetes-nmstate

$ oc delete namespace kubernetes-nmstate

Copy to clipboard

4.1.3. 関連情報

ノード上でのインターフェイスの作成

4.1.4. 次のステップ

ノードのネットワーク状態と設定の監視と更新

4.2. AWS Load Balancer Operator

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

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

重要

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

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

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

注記

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

4.2.1.1. AWS Load Balancer Operator 1.2.0

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

RHEA-2025:0034 Release of AWS Load Balancer Operator 1.2.z on OperatorHub

4.2.1.1.1. 大きな変更

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

4.2.1.2. AWS Load Balancer Operator 1.1.1

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

RHEA-2024:0555 Release of AWS Load Balancer Operator 1.1.z on OperatorHub

4.2.1.3. AWS Load Balancer Operator 1.1.0

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

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

RHEA-2023:6218 Release of AWS Load Balancer Operator on OperatorHub Enhancement Advisory Update

4.2.1.3.1. 大きな変更

このリリースでは、Kubernetes API バージョン 0.27.2 を使用します。

4.2.1.3.2. 新機能

AWS Load Balancer Operator は、Cloud Credential Operator を使用して標準化された Security Token Service (STS) フローをサポートするようになりました。

4.2.1.3.3. バグ修正

FIPS 準拠のクラスターでは、TLS バージョン 1.2 を使用する必要があります。以前は、AWS Load Balancer Controller の Webhook は最小バージョンとして TLS 1.3 のみを受け入れていたため、FIPS 準拠のクラスターで次のようなエラーが発生しました。
```
remote error: tls: protocol version not supported
```
```
remote error: tls: protocol version not supported
```
Copy to clipboardCopied
現在、AWS Load Balancer Controller は TLS 1.2 を最小 TLS バージョンとして受け入れ、この問題は解決されています。(OCPBUGS-14846)

4.2.1.4. AWS Load Balancer Operator 1.0.1

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

Release of AWS Load Balancer Operator 1.0.1 on OperatorHub

4.2.1.5. AWS Load Balancer Operator 1.0.0

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

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

RHEA-2023:1954 Release of AWS Load Balancer Operator on OperatorHub Enhancement Advisory Update

重要

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

4.2.1.5.1. 大きな変更

このリリースでは、新しい v1 API バージョンを使用しています。

4.2.1.5.2. バグ修正

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

4.2.1.6. 以前のバージョン

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

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

RHEA-2022:9084 Release of AWS Load Balancer Operator on OperatorHub Enhancement Advisory Update

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

RHEA-2022:5780 Release of AWS Load Balancer Operator on OperatorHub Enhancement Advisory Update

4.2.2. OpenShift Container Platform の AWS Load Balancer Operator

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

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

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

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

4.2.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

出力例

install-zlfbt

install-zlfbt

Copy to clipboard

次のコマンドを実行して、インストールプランのステータスが 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

出力例

Complete

Complete

Copy to clipboard

次のコマンドを実行して、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

出力例

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

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

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

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

前提条件

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

手順

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

Ingress リソース設定の例

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

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

1

使用するサブネットを指定します。

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

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

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

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

4.2.3.1. 前提条件

OpenShift CLI (oc) がインストールされている。
クラスターのインフラストラクチャー ID がわかっている。この ID を表示するには、CLI で次のコマンドを実行します。
```
oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"
```
```
$ oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"
```
Copy to clipboardCopied
クラスターの OpenID Connect (OIDC) の DNS 情報がわかっている。この情報を表示するには、CLI で次のコマンドを入力します。
```
oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}" 1
```
```
$ oc get authentication.config cluster -o=jsonpath="{.spec.serviceAccountIssuer}" 1
```
Copy to clipboardCopied
1
OIDC DNS の例は https://rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。
AWS Web コンソールにログインし、IAM → Access management → Identity providers に移動して、OIDC の Amazon Resource Name (ARN) 情報を確認した。OIDC の ARN の例は、arn:aws:iam::777777777777:oidc-provider/<oidc_dns_url> です。

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

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

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

Cloud Credential Operator ユーティリティー (ccoctl) と定義済みの CredentialsRequest オブジェクトを使用します。
AWS CLI と事前定義された AWS マニフェストを使用します。

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

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

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

前提条件

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

手順

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

curl --create-dirs -o <credentials_requests_dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml

$ curl --create-dirs -o <credentials_requests_dir>/operator.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-credentials-request.yaml

Copy to clipboard

ccoctl ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。

ccoctl aws create-iam-roles \
    --name <name> \
    --region=<aws_region> \
    --credentials-requests-dir=<credentials_requests_dir> \
    --identity-provider-arn <oidc_arn>

$ ccoctl aws create-iam-roles \
    --name <name> \
    --region=<aws_region> \
    --credentials-requests-dir=<credentials_requests_dir> \
    --identity-provider-arn <oidc_arn>

Copy to clipboard

出力例

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

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

Copy to clipboard

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

注記

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

4.2.3.2.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": "<oidc_arn>" 1
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 2
                }
            }
        }
    ]
}
EOF

$ cat <<EOF > albo-operator-trust-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "<oidc_arn>" 1
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 2
                }
            }
        }
    ]
}
EOF

Copy to clipboard

1: OIDC アイデンティティープロバイダーの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f) を指定します。
2: AWS Load Balancer Controller のサービスアカウントを指定します。<cluster_oidc_endpoint> の例は、rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。

次のコマンドを実行して、生成された信頼ポリシーを使用して IAM ロールを作成します。

aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json

$ aws iam create-role --role-name albo-operator --assume-role-policy-document file://albo-operator-trust-policy.json

Copy to clipboard

出力例

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

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

Copy to clipboard

1: AWS Load Balancer Operator 用に作成された AWS IAM ロールの ARN (例: arn:aws:iam::777777777777:role/albo-operator) をメモします。

次のコマンドを実行して、AWS Load Balancer Operator の権限ポリシーをダウンロードします。

curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json

$ curl -o albo-operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/operator-permission-policy.json

Copy to clipboard

次のコマンドを実行して、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

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

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

前提条件

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

手順

次のコマンドを実行して、aws-load-balancer-operator プロジェクトを作成します。
```
oc new-project aws-load-balancer-operator
```
```
$ oc new-project aws-load-balancer-operator
```
Copy to clipboardCopied

以下のコマンドを実行して 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

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

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: aws-load-balancer-operator
  namespace: aws-load-balancer-operator
spec:
  channel: stable-v1
  name: aws-load-balancer-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: "<albo_role_arn>" 1
EOF

$ cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: aws-load-balancer-operator
  namespace: aws-load-balancer-operator
spec:
  channel: stable-v1
  name: aws-load-balancer-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: "<albo_role_arn>" 1
EOF

Copy to clipboard

1: AWS Load Balancer Operator の AWS 認証情報をプロビジョニングするために CredentialsRequest で使用する ARN ロールを指定します。<albo_role_arn> の例は、arn:aws:iam::<aws_account_number>:role/albo-operator です。

注記

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

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

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

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

Cloud Credential Operator ユーティリティー (ccoctl) と定義済みの CredentialsRequest オブジェクトを使用します。
AWS CLI と事前定義された AWS マニフェストを使用します。

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

4.2.3.4.1. Cloud Credential Operator ユーティリティーを使用してコントローラー用の AWS IAM ロールを作成する

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

前提条件

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

手順

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

curl --create-dirs -o <credentials_requests_dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml

$ curl --create-dirs -o <credentials_requests_dir>/controller.yaml https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/hack/controller/controller-credentials-request.yaml

Copy to clipboard

ccoctl ユーティリティーを使用して次のコマンドを実行し、AWS IAM ロールを作成します。

ccoctl aws create-iam-roles \
    --name <name> \
    --region=<aws_region> \
    --credentials-requests-dir=<credentials_requests_dir> \
    --identity-provider-arn <oidc_arn>

$ ccoctl aws create-iam-roles \
    --name <name> \
    --region=<aws_region> \
    --credentials-requests-dir=<credentials_requests_dir> \
    --identity-provider-arn <oidc_arn>

Copy to clipboard

出力例

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

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

Copy to clipboard

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

注記

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

4.2.3.4.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": "<oidc_arn>" 1
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 2
                }
            }
        }
    ]
}
EOF

$ cat <<EOF > albo-controller-trust-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "<oidc_arn>" 1
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "<cluster_oidc_endpoint>:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager" 2
                }
            }
        }
    ]
}
EOF

Copy to clipboard

1: OIDC アイデンティティープロバイダーの Amazon Resource Name (ARN) (例: arn:aws:iam::777777777777:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f) を指定します。
2: AWS Load Balancer Controller のサービスアカウントを指定します。<cluster_oidc_endpoint> の例は、rh-oidc.s3.us-east-1.amazonaws.com/28292va7ad7mr9r4he1fb09b14t59t4f です。

次のコマンドを実行して、生成された信頼ポリシーを使用して AWS IAM ロールを作成します。

aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json

$ aws iam create-role --role-name albo-controller --assume-role-policy-document file://albo-controller-trust-policy.json

Copy to clipboard

出力例

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

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

Copy to clipboard

1: AWS Load Balancer Controller の AWS IAM ロールの ARN (例: arn:aws:iam::777777777777:role/albo-controller) をメモします。

次のコマンドを実行して、AWS Load Balancer Controller の権限ポリシーをダウンロードします。

curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json

$ curl -o albo-controller-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/main/assets/iam-policy.json

Copy to clipboard

次のコマンドを実行して、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

AWSLoadBalancerController オブジェクトを定義する YAML ファイルを作成します。
sample-aws-lb-manual-creds.yaml ファイルの例
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 1
metadata:
  name: cluster 2
spec:
  credentialsRequestConfig:
    stsIAMRoleARN: <albc_role_arn> 3
```
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController 1
metadata:
  name: cluster 2
spec:
  credentialsRequestConfig:
    stsIAMRoleARN: <albc_role_arn> 3
```
Copy to clipboardCopied
1
AWSLoadBalancerController オブジェクトを定義します。
2
AWS Load Balancer Controller 名を定義します。このインスタンス名は、関連するすべてのリソースの接尾辞として使用されます。
3
AWS Load Balancer Controller の ARN ロールを指定します。CredentialsRequest オブジェクトは、この ARN ロールを使用して AWS 認証情報をプロビジョニングします。<albc_role_arn> の例は、arn:aws:iam::777777777777:role/albo-controller です。

4.2.3.5. 関連情報

Cloud Credential Operator ユーティリティーの設定

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

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

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

前提条件

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

手順

OpenShift Container Platform Web コンソールで、Operators → OperatorHub に移動します。
AWS Load Balancer Operator を選択します。Filter by keyword テキストボックスを使用するか、フィルターリストを使用して、Operator のリストから AWS Load Balancer Operator を検索できます。
aws-load-balancer-operator namespace を選択します。
Install Operator ページで、次のオプションを選択します。
1. Update the channel で stable-v1 を選択します。
2. Installation mode で All namespaces on the cluster (default) を選択します。
3. Installed Namespace で aws-load-balancer-operator を選択します。aws-load-balancer-operator namespace が存在しない場合は、Operator のインストール中に作成されます。
4. Update approval で Automatic または Manual を選択します。デフォルトでは、Update approval は Automatic に設定されています。Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように更新要求を手動で承認する必要があります。
Install をクリックします。

検証

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

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

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

前提条件

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

手順

Namespace オブジェクトを作成します。
1. Namespace オブジェクトを定義する YAML ファイルを作成します。
  namespace.yaml ファイルの例
  apiVersion: v1 kind: Namespace metadata: name: aws-load-balancer-operator
  Copy to clipboard
2. 次のコマンドを実行して、Namespace オブジェクトを作成します。
```
oc apply -f namespace.yaml
```
```
$ oc apply -f namespace.yaml
```
  Copy to clipboardCopied

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

以下のコマンドを実行して OperatorGroup オブジェクトを作成します。
```
oc apply -f operatorgroup.yaml
```
```
$ oc apply -f operatorgroup.yaml
```
Copy to clipboardCopied

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

以下のコマンドを実行して Subscription オブジェクトを作成します。
```
oc apply -f subscription.yaml
```
```
$ oc apply -f subscription.yaml
```
Copy to clipboardCopied

検証

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

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

インストールプランのステータスを確認します。

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

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

4.2.4.3. AWS Load Balancer Controller の作成

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

前提条件

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

手順

AWSLoadBalancerController オブジェクトを定義する YAML ファイルを作成します。
sample-aws-lb.yaml ファイルの例
```
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
```
```
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 clipboardCopied
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 clipboardCopied

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

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

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

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

1: デプロイメントリソースを定義します。
2: デプロイメント名を指定します。
3: デプロイメントのレプリカの数を指定します。

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

service-albo.yaml ファイルの例

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

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

1: サービスリソースを定義します。
2: サービス名を指定します。

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

Ingress-albo.yaml ファイルの例

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

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

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

検証

次のコマンドを実行して、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

次のコマンドを実行して、Ingress リソースのステータスを確認します。
```
curl $HOST
```
```
$ curl $HOST
```
Copy to clipboardCopied

4.2.5. AWS Load Balancer Operator の設定

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

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

次のコマンドを実行して、aws-load-balancer-operator namespace に認証局 (CA) バンドルを含める config map を作成します。
```
oc -n aws-load-balancer-operator create configmap trusted-ca
```
```
$ oc -n aws-load-balancer-operator create configmap trusted-ca
```
Copy to clipboardCopied
信頼できる 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 clipboardCopied

次のコマンドを実行して、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

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

出力例

-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

オプション: 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

関連情報

Operator を使用した証明書の挿入

4.2.5.2. 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 1
```
```
apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster
spec:
  subnetTagging: Auto
  ingressClass: tls-termination 1
```
Copy to clipboardCopied
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> 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

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

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

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

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

前提条件

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

手順

次のように、IngressClassParams リソースの YAML ファイル (例: sample-single-lb-params.yaml) を作成します。
```
apiVersion: elbv2.k8s.aws/v1beta1 1
kind: IngressClassParams
metadata:
  name: single-lb-params 2
spec:
  group:
    name: single-lb 3
```
```
apiVersion: elbv2.k8s.aws/v1beta1 1
kind: IngressClassParams
metadata:
  name: single-lb-params 2
spec:
  group:
    name: single-lb 3
```
Copy to clipboardCopied
1
IngressClassParams リソースの API グループとバージョンを定義します。
2
IngressClassParams リソース名を指定します。
3
IngressGroup リソース名を指定します。このクラスのすべての Ingress リソースは、この IngressGroup に属します。
次のコマンドを実行して、IngressClassParams リソースを作成します。
```
oc create -f sample-single-lb-params.yaml
```
```
$ oc create -f sample-single-lb-params.yaml
```
Copy to clipboardCopied
次のように、IngressClass リソースの YAML ファイル (例: sample-single-lb-class.yaml) を作成します。
```
apiVersion: networking.k8s.io/v1 1
kind: IngressClass
metadata:
  name: single-lb 2
spec:
  controller: ingress.k8s.aws/alb 3
  parameters:
    apiGroup: elbv2.k8s.aws 4
    kind: IngressClassParams 5
    name: single-lb-params 6
```
```
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 clipboardCopied
1
API グループと IngressClass リソースのバージョンを定義します。
2
Ingress クラス名を指定します。
3
コントローラー名を定義します。ingress.k8s.aws/alb という値は、このクラスのすべての Ingress リソースを AWS Load Balancer Controller によって管理することを意味します。
4
IngressClassParams リソースの API グループを定義します。
5
IngressClassParams リソースのリソースタイプを定義します。
6
IngressClassParams リソース名を定義します。
次のコマンドを実行して IngressClass リソースを作成します。
```
oc create -f sample-single-lb-class.yaml
```
```
$ oc create -f sample-single-lb-class.yaml
```
Copy to clipboardCopied

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

apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster
spec:
  subnetTagging: Auto
  ingressClass: single-lb 1

apiVersion: networking.olm.openshift.io/v1
kind: AWSLoadBalancerController
metadata:
  name: cluster
spec:
  subnetTagging: Auto
  ingressClass: single-lb 1

Copy to clipboard

1: IngressClass リソースの名前を定義します。

次のコマンドを実行して、AWSLoadBalancerController リソースを作成します。
```
oc create -f sample-single-lb.yaml
```
```
$ oc create -f sample-single-lb.yaml
```
Copy to clipboardCopied

次のように、Ingress リソースの YAML ファイル (例: sample-multiple-ingress.yaml) を作成します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-1 1
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 2
    alb.ingress.kubernetes.io/group.order: "1" 3
    alb.ingress.kubernetes.io/target-type: instance 4
spec:
  ingressClassName: single-lb 5
  rules:
  - host: example.com 6
    http:
        paths:
        - path: /blog 7
          pathType: Prefix
          backend:
            service:
              name: example-1 8
              port:
                number: 80 9
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-2
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "2"
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: single-lb
  rules:
  - host: example.com
    http:
        paths:
        - path: /store
          pathType: Prefix
          backend:
            service:
              name: example-2
              port:
                number: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-3
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.order: "3"
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: single-lb
  rules:
  - host: example.com
    http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: example-3
              port:
                number: 80

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

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 clipboardCopied

4.2.5.4. AWS Load Balancer Operator ログ

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

手順

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

oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

$ oc logs -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager -c manager

Copy to clipboard

4.3. eBPF マネージャー Operator

4.3.1. eBPF Manager Operator について

重要

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

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

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

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

4.3.1.2. eBPF Manager Operator について

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

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

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

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

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

4.3.1.3. 関連情報

4.3.1.4. 次のステップ

eBPF Manager Operator のインストール

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

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

重要

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

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

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

前提条件

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

手順

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

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.24
  name: bpfman
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: v1.24
  name: bpfman
EOF

Copy to clipboard

OperatorGroup CR を作成するには、以下のコマンドを実行します。

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: bpfman-operators
  namespace: bpfman
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: bpfman-operators
  namespace: bpfman
EOF

Copy to clipboard

eBPF Manager Operator にサブスクライブします。

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

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: bpfman-operator
  namespace: bpfman
spec:
  name: bpfman-operator
  channel: alpha
  source: community-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: bpfman-operator
  namespace: bpfman
spec:
  name: bpfman-operator
  channel: alpha
  source: community-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to clipboard

Operator がインストールされていることを確認するには、以下のコマンドを入力します。

oc get ip -n bpfman

$ oc get ip -n bpfman

Copy to clipboard

出力例

NAME            CSV                                 APPROVAL    APPROVED
install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true

NAME            CSV                                 APPROVAL    APPROVED
install-ppjxl   security-profiles-operator.v0.8.5   Automatic   true

Copy to clipboard

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

oc get csv -n bpfman

$ oc get csv -n bpfman

Copy to clipboard

出力例

NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded

NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
bpfman-operator.v0.5.0              eBPF Manager Operator              0.5.0     bpfman-operator.v0.4.2              Succeeded

Copy to clipboard

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

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

前提条件

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

手順

eBPF Manager Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator のリストから eBPF Manager Operator を選択し、コミュニティー Operator を表示する ように求められたら、Continue をクリックします。
3. Install をクリックします。
4. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
5. Install をクリックします。
eBPF Manager Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに移動します。
2. eBPF Manager Operator が、Status が InstallSucceeded で openshift-ingress-node-firewall プロジェクトにリストされていることを確認します。
  注記
  インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
  Operator の Status が InstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。
  - Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
  - Workloads → Pods ページに移動し、bpfman プロジェクト内の Pod のログを確認します。

4.3.2.3. 次のステップ

コンテナー化された eBPF プログラムの導入
eBPF Manager Operator を使用するように Ingress ノードファイアウォール Operator の設定

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

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

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

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

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

重要

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

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

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

前提条件

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

手順

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

curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml

$ curl -L https://github.com/bpfman/bpfman/releases/download/v0.5.1/go-xdp-counter-install-selinux.yaml -o go-xdp-counter-install-selinux.yaml

Copy to clipboard

サンプル eBPF アプリケーションをデプロイするには、次のコマンドを実行します。

oc create -f go-xdp-counter-install-selinux.yaml

$ oc create -f go-xdp-counter-install-selinux.yaml

Copy to clipboard

出力例

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

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

Copy to clipboard

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

oc get all -o wide -n go-xdp-counter

$ oc get all -o wide -n go-xdp-counter

Copy to clipboard

出力例

NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter

NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                                 NOMINATED NODE   READINESS GATES
pod/go-xdp-counter-ds-4m9cw   1/1     Running   0          44s   10.129.0.92    ci-ln-dcbq7d2-72292-ztrkp-master-1   <none>           <none>
pod/go-xdp-counter-ds-7hzww   1/1     Running   0          44s   10.130.0.86    ci-ln-dcbq7d2-72292-ztrkp-master-2   <none>           <none>
pod/go-xdp-counter-ds-qm9zx   1/1     Running   0          44s   10.128.0.101   ci-ln-dcbq7d2-72292-ztrkp-master-0   <none>           <none>

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS       IMAGES                                           SELECTOR
daemonset.apps/go-xdp-counter-ds   3         3         3       3            3           <none>          44s   go-xdp-counter   quay.io/bpfman-userspace/go-xdp-counter:v0.5.0   name=go-xdp-counter

Copy to clipboard

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

oc get xdpprogram go-xdp-counter-example

$ oc get xdpprogram go-xdp-counter-example

Copy to clipboard

出力例

NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess

NAME                     BPFFUNCTIONNAME   NODESELECTOR   STATUS
go-xdp-counter-example   xdp_stats         {}             ReconcileSuccess

Copy to clipboard

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

oc logs <pod_name> -n go-xdp-counter

$ oc logs <pod_name> -n go-xdp-counter

Copy to clipboard

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

出力例

2024/08/13 15:20:06 15016 packets received
2024/08/13 15:20:06 93581579 bytes received

2024/08/13 15:20:09 19284 packets received
2024/08/13 15:20:09 99638680 bytes received

2024/08/13 15:20:12 23522 packets received
2024/08/13 15:20:12 105666062 bytes received

2024/08/13 15:20:15 27276 packets received
2024/08/13 15:20:15 112028608 bytes received

2024/08/13 15:20:18 29470 packets received
2024/08/13 15:20:18 112732299 bytes received

2024/08/13 15:20:21 32588 packets received
2024/08/13 15:20:21 113813781 bytes received

2024/08/13 15:20:06 15016 packets received
2024/08/13 15:20:06 93581579 bytes received

2024/08/13 15:20:09 19284 packets received
2024/08/13 15:20:09 99638680 bytes received

2024/08/13 15:20:12 23522 packets received
2024/08/13 15:20:12 105666062 bytes received

2024/08/13 15:20:15 27276 packets received
2024/08/13 15:20:15 112028608 bytes received

2024/08/13 15:20:18 29470 packets received
2024/08/13 15:20:18 112732299 bytes received

2024/08/13 15:20:21 32588 packets received
2024/08/13 15:20:21 113813781 bytes received

Copy to clipboard

4.4. External DNS Operator

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

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

重要

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

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

4.4.1.1. External DNS Operator 1.3.0

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

RHEA-2024:8550 Product Enhancement Advisory

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

4.4.1.1.1. バグ修正

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

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

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

4.4.1.2. External DNS Operator 1.2.0

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

RHEA-2022:5867 ExternalDNS Operator 1.2 operator/operand containers

4.4.1.2.1. 新機能

External DNS Operator が AWS 共有 VPC をサポートするようになりました。詳細は、共有 VPC を使用して別の AWS アカウントに DNS レコードを作成するを参照してください。

4.4.1.2.2. バグ修正

オペランドの更新ストラテジーが、Rolling から Recreate に変更されました。(OCPBUGS-3630)

4.4.1.3. External DNS Operator 1.1.1

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

RHEA-2024:0536 ExternalDNS Operator 1.1 operator/operand containers

4.4.1.4. External DNS Operator 1.1.0

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

RHEA-2022:9086-01 ExternalDNS Operator 1.1 operator/operand containers

4.4.1.4.1. バグ修正

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

4.4.1.5. External DNS Operator 1.0.1

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

RHEA-2024:0537 ExternalDNS Operator 1.0 operator/operand containers

4.4.1.6. External DNS Operator 1.0.0

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

RHEA-2022:5867 ExternalDNS Operator 1.0 operator/operand containers

4.4.1.6.1. バグ修正

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

4.4.2. External DNS Operator について

4.4.2.1. External DNS Operator

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

前提条件

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

手順

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

次のコマンドを実行して、インストールプランの名前を確認します。

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

出力例

install-zcvlr

install-zcvlr

Copy to clipboard

次のコマンドを実行して、インストールプランのステータスが 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

出力例

Complete

Complete

Copy to clipboard

次のコマンドを実行して、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

出力例

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

4.4.2.2. External DNS Operator のログの表示

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

手順

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

oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

$ oc logs -n external-dns-operator deployment/external-dns-operator -c external-dns-operator

Copy to clipboard

4.4.2.2.1. External DNS Operator のドメイン名の制限

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

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

レコードの種類	文字数
CNAME	44
AzureDNS のワイルドカード CNAME レコード	42
A	48
AzureDNS のワイルドカード A レコード	46

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

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

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

Copy to clipboard

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

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

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

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

手順

OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
External DNS Operator をクリックします。Filter by keyword のテキストボックスまたはフィルターリストを使用して、Operator のリストから External DNS Operator を検索できます。
external-dns-operator namespace を選択します。
External DNS Operator ページで Install をクリックします。
Install Operator ページで、次のオプションを選択していることを確認してください。
1. Update the channel で stable-v1.0 を選択します。
2. Installation mode で A specific name on the cluster を選択します。
3. Installed namespace で external-dns-operator を選択します。namespace external-dns-operator が存在しない場合は、Operator のインストール中に作成されます。
4. Approval Strategy で Automatic または Manual を選択します。Approval Strategy はデフォルトで Automatic に設定されています。
5. Install をクリックします。

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

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

検証

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

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

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

前提条件

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

手順

Namespace オブジェクトを作成します。
1. Namespace オブジェクトを定義する YAML ファイルを作成します。
  namespace.yaml ファイルの例
  apiVersion: v1 kind: Namespace metadata: name: external-dns-operator
  Copy to clipboard
2. 次のコマンドを実行して、Namespace オブジェクトを作成します。
```
oc apply -f namespace.yaml
```
```
$ oc apply -f namespace.yaml
```
  Copy to clipboardCopied

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

以下のコマンドを実行して OperatorGroup オブジェクトを作成します。
```
oc apply -f operatorgroup.yaml
```
```
$ oc apply -f operatorgroup.yaml
```
Copy to clipboardCopied

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

以下のコマンドを実行して Subscription オブジェクトを作成します。
```
oc apply -f subscription.yaml
```
```
$ oc apply -f subscription.yaml
```
Copy to clipboardCopied

検証

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

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

次のコマンドを実行して、インストールプランのステータスが 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

次のコマンドを実行して、external-dns-operator Pod のステータスが Running であることを確認します。

oc -n external-dns-operator get pod

$ oc -n external-dns-operator get pod

Copy to clipboard

出力例

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

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

oc -n external-dns-operator get subscription

$ oc -n external-dns-operator get subscription

Copy to clipboard

出力例

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

次のコマンドを実行して、external-dns-operator のバージョンを確認します。

oc -n external-dns-operator get csv

$ oc -n external-dns-operator get csv

Copy to clipboard

出力例

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

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

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

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

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

パラメーター	説明
`spec`	クラウドプロバイダーのタイプを有効にします。 `spec: provider: type: AWS 1 aws: credentials: name: aws-access-key 2` Copy to clipboard 1 AWS、GCP、Azure、Infoblox などの利用可能なオプションを定義します。 2 クラウドプロバイダーのシークレット名を定義します。
`zones`	ドメインごとに DNS ゾーンを指定できます。ゾーンを指定しない場合、`ExternalDNS` リソースはクラウドプロバイダーアカウントに存在するすべてのゾーンを検出します。 `zones: - "myzoneid" 1` Copy to clipboard 1 DNS ゾーンの名前を指定します。
`domains`	ドメインごとに AWS ゾーンを指定できます。ドメインを指定しない場合、`ExternalDNS` リソースはクラウドプロバイダーアカウントに存在するすべてのゾーンを検出します。 `domains: - filterType: Include 1 matchType: Exact 2 name: "myzonedomain1.com" 3 - filterType: Include matchType: Pattern 4 pattern: ".*\\.otherzonedomain\\.com" 5` Copy to clipboard 1 `ExternalDNS` リソースにドメイン名が含まれていることを確認します。 2 ドメインは、正規表現での照合ではなく、完全に一致する必要があることを、`ExternalDNS` に指示します。 3 ドメインの名前を定義します。 4 `ExternalDNS` リソースに `regex-domain-filter` フラグを設定します。正規表現フィルターを使用して、使用できるドメインに限定します。 5 ターゲットゾーンのドメインをフィルタリングするために `ExternalDNS` リソースが使用する正規表現パターンを定義します。
`source`	DNS レコードのソース (`Service` または `Route`) を指定できます。 `source: 1 type: Service 2 service: serviceType:3 - LoadBalancer - ClusterIP labelFilter: 4 matchLabels: external-dns.mydomain.org/publish: "yes" hostnameAnnotation: "Allow" 5 fqdnTemplate: - "{{.Name}}.myzonedomain.com" 6` Copy to clipboard 1 DNS レコードのソースの設定を定義します。 2 `ExternalDNS` リソースは、DNS レコードを作成するためのソースとして `Service` タイプを使用します。 3 `ExternalDNS` リソースに `service-type-filter` フラグを設定します。`serviceType` には、次のフィールドが含まれています。 `デフォルト`: `LoadBalancer` `expected`: `ClusterIP` `NodePort` `LoadBalancer` `ExternalName` 4 コントローラーで考慮するのは、ラベルフィルターと一致するリソースのみにします。 5 `hostnameAnnotation` のデフォルト値は `Ignore` で、フィールド `fqdnTemplates` で指定されたテンプレートを使用して DNS レコードを生成するように `ExternalDNS` に指示します。値が `Allow` の場合には、`external-dns.alpha.kubernetes.io/hostname` アノテーションで指定された値をもとに DNS レコードが生成されます。 6 External DNS Operator は文字列を使用して、ホスト名を定義していないソースから DNS 名を生成したり、偽のソースとペアになったときにホスト名の接尾辞を追加したりします。 `source: type: OpenShiftRoute 1 openshiftRouteOptions: routerName: default 2 labelFilter: matchLabels: external-dns.mydomain.org/publish: "yes"` Copy to clipboard 1 DNS レコードを作成します。 2 ソースタイプが `OpenShiftRoute` の場合は、Ingress Controller 名を指定できます。`ExternalDNS` リソースは、CNAME レコードのターゲットとして Ingress Controller の正規名を使用します。

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

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

4.4.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 clipboardCopied
出力例
```
system:admin
```
```
system:admin
```
Copy to clipboardCopied

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

ルートを取得して、ドメインを確認します。

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to clipboard

出力例

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

DNS ゾーンのリストを取得して、以前に検出されたルートのドメインに対応するものを検索します。

aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

$ aws route53 list-hosted-zones | grep testextdnsoperator.apacshift.support

Copy to clipboard

出力例

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support.	5

Copy to clipboard

route ソースの ExternalDNS リソースを作成します。
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 1
spec:
  domains:
  - filterType: Include   2
    matchType: Exact   3
    name: testextdnsoperator.apacshift.support 4
  provider:
    type: AWS 5
  source:  6
    type: OpenShiftRoute 7
    openshiftRouteOptions:
      routerName: default 8
EOF
```
```
$ 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 clipboardCopied
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

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

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

前提条件

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

手順

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

aws --profile account-a iam get-role --role-name user-rol1 | head -1

$ aws --profile account-a iam get-role --role-name user-rol1 | head -1

Copy to clipboard

出力例

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

次のコマンドを実行して、アカウント 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

出力例

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support. 5

HOSTEDZONES	terraform	/hostedzone/Z02355203TNN1XXXX1J6O	testextdnsoperator.apacshift.support. 5

Copy to clipboard

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

cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws
spec:
  domains:
  - filterType: Include
    matchType: Exact
    name: testextdnsoperator.apacshift.support
  provider:
    type: AWS
    aws:
      assumeRole:
        arn: arn:aws:iam::12345678901234:role/user-rol1 1
  source:
    type: OpenShiftRoute
    openshiftRouteOptions:
      routerName: default
EOF

$ 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

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

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

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

重要

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

4.4.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

次のコマンドを実行して、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

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

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to clipboard

出力例

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

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

az network dns zone list --resource-group "${RESOURCE_GROUP}"

$ az network dns zone list --resource-group "${RESOURCE_GROUP}"

Copy to clipboard

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

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

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

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

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

次のコマンドを実行して、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 clipboardCopied
注記
プライベート Azure DNS のホストされたプライベートゾーンにレコードを作成するには、zones フィールドの下にプライベートゾーンを指定する必要があります。これにより、プロバイダータイプが ExternalDNS 引数の azure-private-dns に入力されます。

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

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

重要

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

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

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

前提条件

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

手順

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

oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

$ oc get secret gcp-credentials -n kube-system --template='{{$v := index .data "service_account.json"}}{{$v}}' | base64 -d - > decoded-gcloud.json

Copy to clipboard

次のコマンドを実行して、Google の認証情報をエクスポートします。
```
export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
```
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
Copy to clipboardCopied

次のコマンドを使用して、アカウントをアクティブ化します。

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

次のコマンドを実行して、プロジェクトを設定します。

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

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

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to clipboard

出力例

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

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

gcloud dns managed-zones list | grep test.gcp.example.com

$ gcloud dns managed-zones list | grep test.gcp.example.com

Copy to clipboard

出力例

qe-cvs4g-private-zone test.gcp.example.com

qe-cvs4g-private-zone test.gcp.example.com

Copy to clipboard

ExternalDNS オブジェクトを定義する YAML ファイル (例: external-dns-sample-gcp.yaml) を作成します。
external-dns-sample-gcp.yaml ファイルの例
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 1
spec:
  domains:
    - filterType: Include 2
      matchType: Exact 3
      name: test.gcp.example.com 4
  provider:
    type: GCP 5
  source:
    openshiftRouteOptions: 6
      routerName: default 7
    type: OpenShiftRoute 8
```
```
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 clipboardCopied
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 clipboardCopied

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

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

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

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

前提条件

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

手順

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

oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

$ oc -n external-dns-operator create secret generic infoblox-credentials --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_USERNAME=<infoblox_username> --from-literal=EXTERNAL_DNS_INFOBLOX_WAPI_PASSWORD=<infoblox_password>

Copy to clipboard

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

oc get routes --all-namespaces | grep console

$ oc get routes --all-namespaces | grep console

Copy to clipboard

出力例

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

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

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

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

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

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

次のコマンドを実行して、Infoblox に ExternalDNS リソースを作成します。
```
oc create -f external-dns-sample-infoblox.yaml
```
```
$ oc create -f external-dns-sample-infoblox.yaml
```
Copy to clipboardCopied
Infoblox UI から、console ルート用に作成された DNS レコードを確認します。
1. Data Management → DNS → Zones をクリックします。
2. ゾーン名を選択します。

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

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

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

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

手順

次のコマンドを実行して、external-dns-operator namespace に CA バンドルを含める config map を作成します。
```
oc -n external-dns-operator create configmap trusted-ca
```
```
$ oc -n external-dns-operator create configmap trusted-ca
```
Copy to clipboardCopied
信頼できる 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 clipboardCopied

次のコマンドを実行して、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

検証

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

出力例

trusted-ca

trusted-ca

Copy to clipboard

4.5. MetalLB Operator

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

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

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

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

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

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

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

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

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

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

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

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

MetalLB: MetalLB カスタムリソースをクラスターに追加する際に、MetalLB Operator は MetalLB をクラスターにデプロイします。Operator はカスタムリソースの単一インスタンスのみをサポートします。インスタンスが削除されると、Operator はクラスターから MetalLB を削除します。
IPAddressPool: MetalLB には、タイプ LoadBalancer のサービスを追加する際にサービスに割り当てることができる IP アドレスの 1 つ以上のプールが必要です。IPAddressPool には、IP アドレスのリストが含まれています。リストは、1.1.1.1-1.1.1.1 などの範囲を使用して設定された単一の IP アドレス、CIDR 表記で指定された範囲、ハイフンで区切られた開始アドレスと終了アドレスとして指定された範囲、またはこの 3 つの組み合わせにすることができます。IPAddressPool には名前が必要です。ドキュメントは、doc-example、doc-example-reserved、doc-example-ipv6 などの名前を使用します。MetalLB controller は、IPAddressPool 内のアドレスのプールから IP アドレスを割り当てます。L2Advertisement および BGPAdvertisement カスタムリソースは、指定されたプールからの指定された IP のアドバタイズメントを有効にします。IPAddressPool カスタムリソースの IPAddressPool 仕様を使用して、spec.serviceAllocation からサービスと namespace に IP アドレスを割り当てることができます。
注記
単一の IPAddressPool は、L2 アドバタイズメントと BGP アドバタイズメントによって参照できます。
BGPPeer: BGP ピアカスタムリソースは、通信する MetalLB の BGP ルーター、ルーターの AS 番号、MetalLB の AS 番号、およびルートアドバタイズメントのカスタマイズを識別します。MetalLB は、サービスロードバランサーの IP アドレスのルートを 1 つ以上の BGP ピアにアドバタイズします。
BFDProfile: BFD プロファイルカスタムリソースは、BGP ピアの双方向フォワーディング検出 (BFD) を設定します。BFD は、BGP のみよりも、パスの障害検出が高速になります。
L2Advertisement: L2Advertisement カスタムリソースは、L2 プロトコルを使用して IPAddressPool からの IP をアドバタイズします。
BGPAdvertisement: BGPAdvertisement カスタムリソースは、BGP プロトコルを使用して IPAddressPool からの IP をアドバタイズします。

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

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

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

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

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

注記

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

controller

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

出力例

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller

Copy to clipboard

speaker

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

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

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

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

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

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

cluster

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

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

local

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

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

注記

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

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

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

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

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

注記

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

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

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

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

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

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

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

4.5.1.6. BGP モードの MetalLB の概念

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

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

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

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

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

ホストネットワーク 10.0.1.0/24 の speaker Pod は、BGP を使用して、ロードバランサーの IP アドレス 203.0.113.200 をルーターにアドバタイズします。

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

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

4.5.1.7. 制限および制限

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

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

ベアメタル
VMware vSphere
IBM Z® および IBM® LinuxONE
IBM Z® および IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
IBM Power®

4.5.1.7.2. レイヤー 2 モードの制限

4.5.1.7.2.1. 単一ノードのボトルネック

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

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

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

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

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

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

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

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

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

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

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

4.5.1.7.3. BGP モードの制限

4.5.1.7.3.1. ノードに障害が発生すると、アクティブなすべての接続が切断される可能性があります

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

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

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

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

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

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

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

4.5.1.8. 関連情報

Comparison: Fault tolerant access to external IP addresses
IP フェイルオーバーの削除
MetalLB のデプロイメント仕様

4.5.2. MetalLB Operator のインストール

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

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

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

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

前提条件

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

手順

OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、metallb と入力して MetalLB Operator を見つけます。
また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
Install Operator ページで、デフォルトを受け入れて Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。
1. Operators → Installed Operators ページに移動します。
2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。
Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。
1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
2. Workloads → Pods ページにナビゲートし、問題を報告している openshift-operators プロジェクトの Pod のログを確認します。

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

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

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

前提条件

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

手順

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

cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
EOF

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
EOF

Copy to clipboard

namespace に Operator グループのカスタムリソースを作成します。

cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system
EOF

$ cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system
EOF

Copy to clipboard

Operator グループが namespace にインストールされていることを確認します。

oc get operatorgroup -n metallb-system

$ oc get operatorgroup -n metallb-system

Copy to clipboard

出力例

NAME               AGE
metallb-operator   14m

NAME               AGE
metallb-operator   14m

Copy to clipboard

Subscription CR を作成します。

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

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators 1
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators 1
  sourceNamespace: openshift-marketplace

Copy to clipboard

1: redhat-operators 値を指定する必要があります。

Subscription CR を作成するには、次のコマンドを実行します。
```
oc create -f metallb-sub.yaml
```
```
$ oc create -f metallb-sub.yaml
```
Copy to clipboardCopied

オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。
```
oc label ns metallb-system "openshift.io/cluster-monitoring=true"
```
```
$ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
```
Copy to clipboardCopied

検証

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

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

oc get installplan -n metallb-system

$ oc get installplan -n metallb-system

Copy to clipboard

出力例

NAME            CSV                                   APPROVAL    APPROVED
install-wzg94   metallb-operator.4.18.0-nnnnnnnnnnnn   Automatic   true

NAME            CSV                                   APPROVAL    APPROVED
install-wzg94   metallb-operator.4.18.0-nnnnnnnnnnnn   Automatic   true

Copy to clipboard

注記

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

Operator がインストールされていることを確認するには、以下のコマンドを入力します。

oc get clusterserviceversion -n metallb-system \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

$ oc get clusterserviceversion -n metallb-system \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

Copy to clipboard

出力例

Name                                  Phase
metallb-operator.4.18.0-nnnnnnnnnnnn   Succeeded

Name                                  Phase
metallb-operator.4.18.0-nnnnnnnnnnnn   Succeeded

Copy to clipboard

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

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

前提条件

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

手順

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

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

cat << EOF | oc apply -f -
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
EOF

$ cat << EOF | oc apply -f -
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
EOF

Copy to clipboard

検証

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

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

oc get deployment -n metallb-system controller

$ oc get deployment -n metallb-system controller

Copy to clipboard

出力例

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
controller   1/1     1            1           11m

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
controller   1/1     1            1           11m

Copy to clipboard

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

oc get daemonset -n metallb-system speaker

$ oc get daemonset -n metallb-system speaker

Copy to clipboard

出力例

NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
speaker   6         6         6       6            6           kubernetes.io/os=linux   18m

NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
speaker   6         6         6       6            6           kubernetes.io/os=linux   18m

Copy to clipboard

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

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

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

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

4.5.2.4.1. speaker Pod の特定のノードへの限定

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

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

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

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

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  1
    node-role.kubernetes.io/worker: ""
  speakerTolerations:   2
  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:  1
    node-role.kubernetes.io/worker: ""
  speakerTolerations:   2
  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"

Copy to clipboard

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

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

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

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

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

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

前提条件

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

手順

myPriorityClass.yaml などの PriorityClass カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority という名前の PriorityClass を、値 1000000 で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。
```
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
```
```
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
```
Copy to clipboardCopied
PriorityClass カスタムリソース設定を適用します。
```
$ oc apply -f myPriorityClass.yaml
```
```
$ oc apply -f myPriorityClass.yaml
```
Copy to clipboardCopied

MetalLBPodConfig.yaml などの MetalLB カスタムリソースを作成して、priorityClassName と podAffinity の値を指定します。

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    priorityClassName: high-priority 1
    affinity:
      podAffinity: 2
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname
  speakerConfig:
    priorityClassName: high-priority
    affinity:
      podAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    priorityClassName: high-priority 1
    affinity:
      podAffinity: 2
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname
  speakerConfig:
    priorityClassName: high-priority
    affinity:
      podAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname

Copy to clipboard

1: MetalLB コントローラー Pod の優先クラスを指定します。この場合、high-priority に設定されます。
2: Pod アフィニティールールを設定していることを指定します。これらのルールは、他の Pod またはノードに関連して Pod がどのようにスケジュールされるかを決定します。この設定は、app: metallb ラベルを持つ Pod を同じホスト名を共有するノードにスケジュールするようにスケジューラーに指示します。これは、MetalLB 関連の Pod を同じノード上に配置するのに役立ち、これらの Pod 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。

MetalLB カスタムリソース設定を適用します。
```
$ oc apply -f MetalLBPodConfig.yaml
```
```
$ oc apply -f MetalLBPodConfig.yaml
```
Copy to clipboardCopied

検証

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

$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName

$ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName

Copy to clipboard

出力例

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

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

Copy to clipboard

スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示します。
```
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
```
```
$ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
```
Copy to clipboardCopied

4.5.2.4.3. MetalLB デプロイメントでの Pod CPU 制限の設定

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

前提条件

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

手順

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

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    resources:
      limits:
        cpu: "200m"
  speakerConfig:
    resources:
      limits:
        cpu: "300m"

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    resources:
      limits:
        cpu: "200m"
  speakerConfig:
    resources:
      limits:
        cpu: "300m"

Copy to clipboard

MetalLB カスタムリソース設定を適用します。
```
$ oc apply -f CPULimits.yaml
```
```
$ oc apply -f CPULimits.yaml
```
Copy to clipboardCopied

検証

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

4.5.2.5. 関連情報

4.5.2.6. 次のステップ

MetalLB アドレスプールの設定

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

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

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

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

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

前提条件

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

手順

次のコマンドを入力して、metallb-system namespace 内の metallb-operator サブスクリプションの YAML 定義を取得します。
```
oc -n metallb-system get subscription metallb-operator -o yaml
```
```
$ oc -n metallb-system get subscription metallb-operator -o yaml
```
Copy to clipboardCopied

installPlanApproval パラメーターを Manual に設定して、Subscription CR を編集します。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb-system
# ...
spec:
   channel: stable
   installPlanApproval: Manual
   name: metallb-operator
   source: redhat-operators
   sourceNamespace: openshift-marketplace
# ...

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb-system
# ...
spec:
   channel: stable
   installPlanApproval: Manual
   name: metallb-operator
   source: redhat-operators
   sourceNamespace: openshift-marketplace
# ...

Copy to clipboard

次のコマンドを入力して、最新の OpenShift Container Platform 4.18 バージョンの MetalLB Operator を見つけます。

oc -n metallb-system get csv

$ oc -n metallb-system get csv

Copy to clipboard

出力例

NAME                       DISPLAY            VERSION    REPLACES    PHASE
metallb-operator.v4.18.0   MetalLB Operator   4.18.0                 Succeeded

NAME                       DISPLAY            VERSION    REPLACES    PHASE
metallb-operator.v4.18.0   MetalLB Operator   4.18.0                 Succeeded

Copy to clipboard

次のコマンドを入力して、namespace に存在するインストールプランを確認します。

oc -n metallb-system get installplan

$ oc -n metallb-system get installplan

Copy to clipboard

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

NAME            CSV                                     APPROVAL    APPROVED
install-shpmd   metallb-operator.v4.18.0-202502261233   Automatic   true
install-tsz2g   metallb-operator.v4.18.0-202503102139   Manual      false

NAME            CSV                                     APPROVAL    APPROVED
install-shpmd   metallb-operator.v4.18.0-202502261233   Automatic   true
install-tsz2g   metallb-operator.v4.18.0-202503102139   Manual      false

Copy to clipboard

次のコマンドを入力して、namespace に存在するインストールプランを編集します。<name_of_installplan> は、install-tsz2g などのインストールプランの名前に置き換えてください。
```
oc edit installplan <name_of_installplan> -n metallb-system
```
```
$ oc edit installplan <name_of_installplan> -n metallb-system
```
Copy to clipboardCopied
1. エディターでインストールプランを開いた状態で、spec.approval パラメーターを Manual に設定し、spec.approved パラメーターを true に設定します。
  注記
  インストールプランを編集すると、アップグレード操作が開始します。アップグレード操作中に oc -n metallb-system get csv コマンドを入力すると、出力に Replacing または Pending ステータスが表示される場合があります。

検証

次のコマンドを入力して、アップグレードが成功したことを確認します。

oc -n metallb-system get csv

$ oc -n metallb-system get csv

Copy to clipboard

出力例

NAME                                        DISPLAY                 VERSION                           REPLACE                                 PHASE
metallb-operator.v<latest>.0-202503102139   MetalLB Operator        4.18.0-202503102139               metallb-operator.v4.18.0-202502261233   Succeeded

NAME                                        DISPLAY                 VERSION                           REPLACE                                 PHASE
metallb-operator.v<latest>.0-202503102139   MetalLB Operator        4.18.0-202503102139               metallb-operator.v4.18.0-202502261233   Succeeded

Copy to clipboard

4.5.3.2. 関連情報

4.6. OpenShift Container Platform における Cluster Network Operator

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

4.6.1. Cluster Network Operator

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

手順

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

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

oc get -n openshift-network-operator deployment/network-operator

$ oc get -n openshift-network-operator deployment/network-operator

Copy to clipboard

出力例

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

以下のコマンドを実行して、Cluster Network Operator の状態を表示します。
```
oc get clusteroperator/network
```
```
$ oc get clusteroperator/network
```
Copy to clipboardCopied
出力例
```
NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
network   4.16.1     True        False         False      50m
```
```
NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
network   4.16.1     True        False         False      50m
```
Copy to clipboardCopied
以下のフィールドは、Operator のステータス (AVAILABLE、PROGRESSING、および DEGRADED) に関する情報を提供します。AVAILABLE フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合に True になります。

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

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

手順

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

oc describe network.config/cluster

$ oc describe network.config/cluster

Copy to clipboard

出力例

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

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

Copy to clipboard

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

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

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

手順

以下のコマンドを実行して、Cluster Network Operator のステータスを表示します。
```
oc describe clusteroperators/network
```
```
$ oc describe clusteroperators/network
```
Copy to clipboardCopied

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

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

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

手順

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

oc get network.operator cluster -o yaml > network-config-backup.yaml

$ oc get network.operator cluster -o yaml > network-config-backup.yaml

Copy to clipboard

次のコマンドを実行して、既存のネットワーク設定を変更します。

oc edit network.operator cluster

$ oc edit network.operator cluster

Copy to clipboard

次の例に示すように、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

ファイルを保存してから閉じます。

変更を適用した後、OpenShift Cluster Network Operator (CNO) によってクラスター全体に更新が適用されます。次のコマンドを使用して進行状況を監視できます。
```
oc get clusteroperators network
```
```
$ oc get clusteroperators network
```
Copy to clipboardCopied
最終的に、ステータスに Available、Progressing=False、Degraded=False と報告されるはずです。
または、次のコマンドを実行して、IP 転送をグローバルに有効にすることもできます。
```
oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
```
```
$ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
```
Copy to clipboardCopied
注記
この変更を元に戻す必要がある場合は、このパラメーターのもう 1 つの有効なオプションである Restricted を設定します。デフォルトでは Restricted に設定されており、グローバル IP アドレス転送は無効です。

4.6.5. Cluster Network Operator ログの表示

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

手順

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

oc logs --namespace=openshift-network-operator deployment/network-operator

$ oc logs --namespace=openshift-network-operator deployment/network-operator

Copy to clipboard

4.6.6. Cluster Network Operator の設定

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

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

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

注記

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

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

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

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

表4.1 Cluster Network Operator 設定オブジェクト
フィールド	型	説明
`metadata.name`	`string`	CNO オブジェクトの名前。この名前は常に `cluster` です。
`spec.clusterNetwork`	`array`	Pod ID アドレスの割り当て、サブネット接頭辞の長さのクラスター内の個別ノードへの割り当てに使用される IP アドレスのブロックを指定するリストです。以下に例を示します。 `spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23` Copy to clipboard
`spec.serviceNetwork`	`array`	サービスの IP アドレスのブロック。OVN-Kubernetes ネットワークプラグインは、サービスネットワークに対して単一の IP アドレスブロックのみをサポートします。以下に例を示します。 `spec: serviceNetwork: - 172.30.0.0/14` Copy to clipboard この値は読み取り専用であり、クラスターのインストール時に `cluster` という名前の `Network.config.openshift.io` オブジェクトから継承されます。
`spec.defaultNetwork`	`object`	クラスターネットワークのネットワークプラグインを設定します。
`spec.kubeProxyConfig`	`object`	このオブジェクトのフィールドは、kube-proxy 設定を指定します。OVN-Kubernetes クラスターネットワークプラグインを使用している場合、kube-proxy 設定は機能しません。

重要

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

defaultNetwork オブジェクト設定

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

表4.2 defaultNetwork オブジェクト
フィールド	型	説明
`type`	`string`	`OVNKubernetes`。Red Hat OpenShift Networking ネットワークプラグインは、インストール中に選択されます。この値は、クラスターのインストール後は変更できません。注記 OpenShift Container Platform は、デフォルトで OVN-Kubernetes ネットワークプラグインを使用します。
`ovnKubernetesConfig`	`object`	このオブジェクトは、OVN-Kubernetes ネットワークプラグインに対してのみ有効です。

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

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

表4.3 ovnKubernetesConfig オブジェクト
フィールド	型	説明
`mtu`	`integer`	Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークの MTU (maximum transmission unit)。通常、この値は自動的に設定されます。
`genevePort`	`integer`	Geneve オーバーレイネットワークの UDP ポート。
`ipsecConfig`	`object`	クラスターの IPsec モードを示すオブジェクト。
`ipv4`	`object`	IPv4 設定の設定オブジェクトを指定します。
`ipv6`	`object`	IPv6 設定の設定オブジェクトを指定します。
`policyAuditConfig`	`object`	ネットワークポリシー監査ロギングをカスタマイズする設定オブジェクトを指定します。指定されていない場合は、デフォルトの監査ログ設定が使用されます。
`gatewayConfig`	`object`	オプション: Egress トラフィックのノードゲートウェイへの送信方法をカスタマイズするための設定オブジェクトを指定します。有効な値は `Shared` と `Local` です。デフォルト値は `Shared` です。デフォルト設定では、Open vSwitch (OVS) がトラフィックをノード IP インターフェイスに直接出力します。`Local` 設定では、トラフィックがホストネットワークを通過し、その結果、ホストのルーティングテーブルに適用されます。注記 Egress トラフィックの移行中は、Cluster Network Operator (CNO) が変更を正常にロールアウトするまで、ワークロードとサービストラフィックに多少の中断が発生することが予想されます。

表4.4 ovnKubernetesConfig.ipv4 object
フィールド	型	説明
`internalTransitSwitchSubnet`	string	既存のネットワークインフラストラクチャーが `100.88.0.0/16` IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。デフォルト値は `100.88.0.0/16` です。
`internalJoinSubnet`	string	既存のネットワークインフラストラクチャーが `100.64.0.0/16` IPv4 サブネットと重複している場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。たとえば、`clusterNetwork.cidr` 値が `10.128.0.0/14` で、`clusterNetwork.hostPrefix` 値が `/23` の場合、ノードの最大数は `2^(23-14)=512` です。デフォルト値は `100.64.0.0/16` です。

表4.5 ovnKubernetesConfig.ipv6 object
フィールド	型	説明
`internalTransitSwitchSubnet`	string	既存のネットワークインフラストラクチャーが `fd97::/64` IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。東西トラフィックを可能にする分散トランジットスイッチのサブネット。このサブネットは、OVN-Kubernetes またはホスト自体で使用される他のサブネットと重複することはできません。クラスター内のノードごとに 1 つの IP アドレスを収容できる必要があります。デフォルト値は `fd97::/64` です。
`internalJoinSubnet`	string	既存のネットワークインフラストラクチャーが `fd98::/64` IPv6 サブネットと重複する場合は、OVN-Kubernetes による内部使用のために別の IP アドレス範囲を指定できます。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は `fd98::/64` です。

表4.6 policyAuditConfig オブジェクト
フィールド	型	説明
`rateLimit`	integer	ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり `20` メッセージです。
`maxFileSize`	integer	監査ログの最大サイズ (バイト単位)。デフォルト値は `50000000` (50MB) です。
`maxLogFiles`	integer	保持されるログファイルの最大数。
`比較先`	string	以下の追加の監査ログターゲットのいずれかになります。 `libc` ホスト上の journald プロセスの libc `syslog()` 関数。 `udp:<host>:<port>` syslog サーバー。`<host>:<port>` を syslog サーバーのホストおよびポートに置き換えます。 `unix:<file>` `<file>` で指定された Unix ドメインソケットファイル。 `null` 監査ログを追加のターゲットに送信しないでください。
`syslogFacility`	string	RFC5424 で定義される `kern` などの syslog ファシリティー。デフォルト値は `local0` です。

表4.7 gatewayConfig オブジェクト
フィールド	型	説明
`routingViaHost`	`boolean`	Pod からホストネットワークスタックへの Egress トラフィックを送信するには、このフィールドを `true` に設定します。インストールおよびアプリケーションがカーネルルーティングテーブルに手動設定されたルートに依存するなど非常に特化されている場合には、Egress トラフィックをホストネットワークスタックにルーティングすることを推奨します。デフォルトでは、Egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。デフォルト値は `false` です。このフィールドで、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。このフィールドを `true` に設定すると、Egress トラフィックがホストネットワークスタックで処理されるため、パフォーマンス的に、オフロードによる利点は得られません。
`ipForwarding`	`object`	`Network` リソースの `ipForwarding` 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP フォワーディングを制御できます。Kubernetes 関連のトラフィックの IP フォワーディングのみを許可するには、`Restricted` を指定します。すべての IP トラフィックの転送を許可するには、`Global` を指定します。新規インストールの場合、デフォルトは `Restricted` です。OpenShift Container Platform 4.14 以降に更新する場合、デフォルトは `Global` です。注記デフォルト値の `Restricted` では、IP 転送がドロップされるように設定されます。
`ipv4`	`object`	オプション: IPv4 アドレスのホストからサービスへのトラフィック用の内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。
`ipv6`	`object`	オプション: IPv6 アドレスのホストからサービスへのトラフィックの内部 OVN-Kubernetes マスカレードアドレスを設定するオブジェクトを指定します。

表4.8 gatewayConfig.ipv4 object
フィールド	型	説明
`internalMasqueradeSubnet`	`string`	ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv4 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は `169.254.169.0/29` です。重要 OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして `169.254.0.0/17` を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表4.9 gatewayConfig.ipv6 object
フィールド	型	説明
`internalMasqueradeSubnet`	`string`	ホストからサービスへのトラフィックを有効にするために内部的に使用されるマスカレード IPv6 アドレス。ホストは、これらの IP アドレスと共有ゲートウェイブリッジインターフェイスを使用して設定されます。デフォルト値は `fd69::/125` です。重要 OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして `fd69::/112` を使用します。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

表4.10 ipsecConfig オブジェクト
フィールド	型	説明
`mode`	`string`	IPsec 実装の動作を指定します。次の値のいずれかである必要があります。 `Disabled`: クラスターノードで IPsec が有効になりません。 `External`: 外部ホストとのネットワークトラフィックに対して IPsec が有効になります。 `Full`: Pod トラフィックおよび外部ホストとのネットワークトラフィックに対して IPsec が有効になります。

注記

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

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

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full

Copy to clipboard

4.6.6.2. Cluster Network Operator の設定例

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

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

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
      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

Copy to clipboard

4.6.7. 関連情報

4.7. OpenShift Container Platform の DNS Operator

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

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

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

手順

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

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

oc get -n openshift-dns-operator deployment/dns-operator

$ oc get -n openshift-dns-operator deployment/dns-operator

Copy to clipboard

出力例

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

oc get コマンドを使用して DNS Operator の状態を表示します。
```
oc get clusteroperator/dns
```
```
$ oc get clusteroperator/dns
```
Copy to clipboardCopied
出力例
```
NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
dns       4.1.15-0.11  True        False         False      92m
```
```
NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
dns       4.1.15-0.11  True        False         False      92m
```
Copy to clipboardCopied
AVAILABLE、PROGRESSING、および DEGRADED は、Operator のステータスに関する情報を示します。AVAILABLE が True になるのは、CoreDNS デーモンセットの 1 つ以上の Pod が AVAILABLE ステータス条件を報告し、DNS サービスがクラスター IP アドレスを持っている場合です。

4.7.2. デフォルト DNS の表示

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

手順

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

oc describe dns.operator/default

$ oc describe dns.operator/default

Copy to clipboard

出力例

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
...

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

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

クラスターのサービス CIDR 範囲を確認するには、oc get コマンドを使用します。

oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

$ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

Copy to clipboard

出力例

[172.30.0.0/16]

[172.30.0.0/16]

Copy to clipboard

4.7.3. DNS 転送の使用

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

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

注記

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

手順

default という名前の DNS Operator オブジェクトを変更します。
```
oc edit dns.operator/default
```
```
$ oc edit dns.operator/default
```
Copy to clipboardCopied
上記のコマンドを実行すると、Operator が、spec.servers に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成および更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。
DNS 転送の設定
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    negativeTTL: 0s
    positiveTTL: 0s
  logLevel: Normal
  nodePlacement: {}
  operatorLogLevel: Normal
  servers:
  - name: example-server 1
    zones:
    - example.com 2
    forwardPlugin:
      policy: Random 3
      upstreams: 4
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 5
    policy: Random 6
    protocolStrategy: ""  7
    transportConfig: {}  8
    upstreams:
    - type: SystemResolvConf 9
    - type: Network
      address: 1.2.3.4 10
      port: 53 11
    status:
      clusterDomain: cluster.local
      clusterIP: x.y.z.10
      conditions:
   ...
```
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    negativeTTL: 0s
    positiveTTL: 0s
  logLevel: Normal
  nodePlacement: {}
  operatorLogLevel: Normal
  servers:
  - name: example-server 1
    zones:
    - example.com 2
    forwardPlugin:
      policy: Random 3
      upstreams: 4
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 5
    policy: Random 6
    protocolStrategy: ""  7
    transportConfig: {}  8
    upstreams:
    - type: SystemResolvConf 9
    - type: Network
      address: 1.2.3.4 10
      port: 53 11
    status:
      clusterDomain: cluster.local
      clusterIP: x.y.z.10
      conditions:
   ...
```
Copy to clipboardCopied
1
rfc6335 サービス名の構文に準拠する必要があります。
2
rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。
3
forwardPlugin にリストされているアップストリームリゾルバーを選択するポリシーを定義します。デフォルト値は Random です。RoundRobin および Sequential の値を使用することもできます。
4
forwardPlugin ごとに最大 15 の upstreams が許可されます。
5
upstreamResolvers を使用すると、デフォルトの転送ポリシーをオーバーライドし、デフォルトドメインの指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを提供しなかった場合、DNS 名のクエリーが /etc/resolv.conf で宣言されたサーバーに送信されます。
6
upstreams にリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。Random、RoundRobin、または Sequential のいずれかの値を指定できます。デフォルト値は Sequential です。
7
省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。TCP に設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。
8
DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
9
2 種類の upstreams (SystemResolvConf または Network) を指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、Network で Networkresolver を定義します。1 つまたは両方を指定できます。
10
指定したタイプが Network の場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
11
指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドには 1 - 65535 の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。

関連情報

DNS 転送の詳細は、CoreDNS forward のドキュメントを参照してください。

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

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

手順

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

oc describe clusteroperators/dns

$ oc describe clusteroperators/dns

Copy to clipboard

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

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

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

Copy to clipboard

4.7.5. DNS Operator のログの表示

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

手順

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

oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

$ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

Copy to clipboard

4.7.6. CoreDNS ログレベルの設定

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

注記

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

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

手順

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

oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge

$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge

Copy to clipboard

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

検証

目的のログレベルが設定されていることを確認するには、config map を確認します。
```
oc get configmap/dns-default -n openshift-dns -o yaml
```
```
$ oc get configmap/dns-default -n openshift-dns -o yaml
```
Copy to clipboardCopied
たとえば、logLevel を Trace に設定すると、各サーバーブロックに次のスタンザが表示されます。
```
errors
log . {
    class all
}
```
```
errors
log . {
    class all
}
```
Copy to clipboardCopied

4.7.7. CoreDNS Operator のログレベルの設定

CoreDNS と CoreDNS Operator のログレベルは、それぞれ異なる方法を使用して設定します。クラスター管理者は、Operator ログレベルを設定して、OpenShift DNS の問題をより迅速に追跡できます。operatorLogLevel の有効な値は、Normal、Debug、および Trace です。Trace には最も詳細にわたる情報が含まれます。デフォルトの operatorlogLevel は Normal です。Operator の問題のログレベルには、Trace、Debug、Info、Warning、Error、Fatal、および Panic の 7 つがあります。ログレベルの設定後に、その重大度またはそれを超える重大度のログエントリーがログに記録されます。

operatorLogLevel: "Normal" は logrus.SetLogLevel("Info") を設定します。
operatorLogLevel: "Debug" は logrus.SetLogLevel("Debug") を設定します。
operatorLogLevel: "Trace" は logrus.SetLogLevel("Trace") を設定します。

手順

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

oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge

$ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge

Copy to clipboard

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

検証

結果の変更を確認するには、次のコマンドを入力します。
```
oc get dnses.operator -A -oyaml
```
```
$ oc get dnses.operator -A -oyaml
```
Copy to clipboardCopied
2 つのログレベルのエントリーが表示されるはずです。operatorLogLevel は OpenShift DNS Operator の問題に適用され、logLevel は CoreDNS Pod のデーモンセットに適用されます。
```
 logLevel: Trace
 operatorLogLevel: Debug
```
```
 logLevel: Trace
 operatorLogLevel: Debug
```
Copy to clipboardCopied
デーモンセットのログを確認するには、次のコマンドを入力します。
```
oc logs -n openshift-dns ds/dns-default
```
```
$ oc logs -n openshift-dns ds/dns-default
```
Copy to clipboardCopied

4.7.8. CoreDNS キャッシュのチューニング

CoreDNS の場合、成功または失敗したキャッシュ (それぞれポジティブキャッシュまたはネガティブキャッシュとも呼ばれます) の最大期間を設定できます。DNS クエリー応答のキャッシュ期間をチューニングすると、アップストリーム DNS リゾルバーの負荷を軽減できます。

警告

TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。

手順

次のコマンドを実行して、default という名前の DNS Operator オブジェクトを編集します。
```
oc edit dns.operator.openshift.io/default
```
```
$ oc edit dns.operator.openshift.io/default
```
Copy to clipboardCopied
Time-to-Live (TTL) キャッシュ値を変更します。
DNS キャッシングの設定
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    positiveTTL: 1h 1
    negativeTTL: 0.5h10m 2
```
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    positiveTTL: 1h 1
    negativeTTL: 0.5h10m 2
```
Copy to clipboardCopied
1
文字列値 1h は、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 900 を使用します。
2
文字列値は、0.5h10m などの単位の組み合わせにすることができ、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 30 を使用します。

検証

変更を確認するには、次のコマンドを実行して config map を再度確認します。
```
oc get configmap/dns-default -n openshift-dns -o yaml
```
```
oc get configmap/dns-default -n openshift-dns -o yaml
```
Copy to clipboardCopied

次の例のようなエントリーが表示されていることを確認します。

       cache 3600 {
            denial 9984 2400
        }

       cache 3600 {
            denial 9984 2400
        }

Copy to clipboard

関連情報

キャッシュの詳細は、CoreDNS cache を参照してください。

4.7.9. 高度なタスク

4.7.9.1. DNS Operator managementState の変更

DNS Operator は、CoreDNS コンポーネントを管理し、クラスター内の Pod とサービスに名前解決サービスを提供します。DNS Operator の managementState は、デフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理していることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

開発者は、CoreDNS の問題が修正されているかどうかを確認するために、設定変更をテストする必要があります。managementState を Unmanaged に設定することで、DNS Operator による設定変更の上書きを防止できます。
クラスター管理者は、CoreDNS の問題を報告していますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の managementState フィールドを Unmanaged に設定して、回避策を適用できます。

手順

DNS Operator の managementState を Unmanaged に変更します。

oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

Copy to clipboard

jsonpath コマンドライン JSON パーサーを使用して DNS Operator の managementState を確認します。

oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'

Copy to clipboard

出力例

"Unmanaged"

"Unmanaged"

Copy to clipboard

注記

managementState が Unmanaged に設定されている間はアップグレードできません。

4.7.9.2. DNS Pod 配置の制御

DNS Operator には 2 つのデーモンセットがあります。1 つは CoreDNS 用の dns-default という名前のデーモンセットで、もう 1 つは /etc/hosts ファイルの管理用の node-resolver という名前のデーモンセットです。

指定したノードに CoreDNS Pod を割り当て、そのノード上で実行できます。たとえば、クラスター管理者がノードペア間の通信を禁止するセキュリティーポリシーを設定している場合は、制限されたノードセットで実行するように CoreDNS Pod を設定できます。

次の状況が当てはまる場合、すべての Pod で DNS サービスを使用できます。

クラスター内の一部のノードで DNS Pod が実行されている。
DNSPod が実行されていないノードには、DNSPod が実行されているノードとのネットワーク接続がある。

node-resolver デーモンセットは、すべてのノードホストで実行する必要があります。このデーモンセットにより、イメージのプルをサポートするクラスターイメージレジストリーのエントリーが追加されるためです。node-resolver Pod には、1 つのジョブのみがあります。コンテナーランタイムがサービス名を解決できるように、image-registry.openshift-image-registry.svc サービスのクラスター IP アドレスを検索し、それをノードホストの /etc/hosts に追加するジョブです。

クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、実行しないように設定できます。

前提条件

oc CLI がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
DNS Operator の managementState が Managed に設定されている。

手順

CoreDNS のデーモンセットを特定のノードで実行できるようにするために、taint と toleration を設定します。
1. 次のコマンドを入力して、DNS Pod の配置を制御するノードに taint を設定します。
```
oc adm taint nodes <node_name> dns-only=abc:NoExecute 1
```
```
$ oc adm taint nodes <node_name> dns-only=abc:NoExecute 1
```
  Copy to clipboardCopied
  1
  <node_name> は、ノードの実際の名前に置き換えます。
2. 次のコマンドを入力して、default という名前の DNS Operator オブジェクトを、対応する toleration が含まれるように変更します。
```
oc edit dns.operator/default
```
```
$ oc edit dns.operator/default
```
  Copy to clipboardCopied
3. taint の taint キーと toleration を指定します。次の toleration は、ノードに設定された taint と一致します。
```
 spec:
   nodePlacement:
     tolerations:
     - effect: NoExecute
       key: "dns-only" 1
       operator: Equal
       value: abc
       tolerationSeconds: 3600 2
```
```
 spec:
   nodePlacement:
     tolerations:
     - effect: NoExecute
       key: "dns-only" 1
       operator: Equal
       value: abc
       tolerationSeconds: 3600 2
```
  Copy to clipboardCopied
  1
  key フィールドが dns-only に設定されている場合、永久的に許容されます。
  2
  tolerationSeconds フィールドはオプションです。
4. オプション: ノードセレクターを使用してノードの配置を指定するには、デフォルトの DNS Operator を変更します。
  1. default という名前の DNS Operator オブジェクトを編集して、ノードセレクターを含めます。
    spec: nodePlacement: nodeSelector: 1 node-role.kubernetes.io/control-plane: ""
    Copy to clipboard
    1
    このノードセレクターにより、CoreDNS Pod がコントロールプレーンノードでのみ実行されるようになります。

4.7.9.3. TLS を使用した DNS 転送の設定

高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。

CoreDNS は転送された接続を 10 秒間キャッシュすることに注意してください。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。

手順

default という名前の DNS Operator オブジェクトを変更します。
```
oc edit dns.operator/default
```
```
$ oc edit dns.operator/default
```
Copy to clipboardCopied
クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。
TLS を使用した DNS 転送の設定
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server 1
    zones:
    - example.com 2
    forwardPlugin:
      transportConfig:
        transport: TLS 3
        tls:
          caBundle:
            name: mycacert
          serverName: dnstls.example.com  4
      policy: Random 5
      upstreams: 6
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 7
    transportConfig:
      transport: TLS
      tls:
        caBundle:
          name: mycacert
        serverName: dnstls.example.com
    upstreams:
    - type: Network 8
      address: 1.2.3.4 9
      port: 53 10
```
```
apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server 1
    zones:
    - example.com 2
    forwardPlugin:
      transportConfig:
        transport: TLS 3
        tls:
          caBundle:
            name: mycacert
          serverName: dnstls.example.com  4
      policy: Random 5
      upstreams: 6
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: 7
    transportConfig:
      transport: TLS
      tls:
        caBundle:
          name: mycacert
        serverName: dnstls.example.com
    upstreams:
    - type: Network 8
      address: 1.2.3.4 9
      port: 53 10
```
Copy to clipboardCopied
1
rfc6335 サービス名の構文に準拠する必要があります。
2
rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。クラスタードメインの cluster.local は、zones の無効な subdomain です。
3
転送された DNS クエリーの TLS を設定する場合、transport フィールドの値を TLS に設定します。
4
転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。
5
アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値は Random です。RoundRobin および Sequential の値を使用することもできます。
6
必須。アップストリームリゾルバーを指定するために使用します。forwardPlugin エントリーごとに最大 15 の upstreams エントリーが許可されます。
7
任意。これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。
8
TLS を使用する場合、Network タイプのみが許可され、IP アドレスを指定する必要があります。Network タイプは、このアップストリームリゾルバーが /etc/resolv.conf にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。
9
address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
10
オプションでポートを指定できます。port の値は 1 〜 65535 である必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。
注記
servers が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。

検証

config map を表示します。

oc get configmap/dns-default -n openshift-dns -o yaml

$ oc get configmap/dns-default -n openshift-dns -o yaml

Copy to clipboard

TLS 転送の例に基づく DNS ConfigMap のサンプル

apiVersion: v1
data:
  Corefile: |
    example.com:5353 {
        forward . 1.1.1.1 2.2.2.2:5353
    }
    bar.com:5353 example.com:5353 {
        forward . 3.3.3.3 4.4.4.4:5454 1
    }
    .:5353 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            upstream
            fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf 1.2.3.4:53 {
            policy Random
        }
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  labels:
    dns.operator.openshift.io/owning-dns: default
  name: dns-default
  namespace: openshift-dns

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

1: forwardPlugin への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。

関連情報

DNS 転送の詳細は、CoreDNS forward のドキュメントを参照してください。

4.8. OpenShift Container Platform の Ingress Operator

Ingress Operator は IngressController API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。

4.8.1. OpenShift Container Platform Ingress Operator

OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などの Ingress Controller 内の設定は、Ingress Controller エンドポイントを公開する方法を提供します。

4.8.2. Ingress 設定アセット

インストールプログラムでは、config.openshift.io API グループの Ingress リソースでアセットを生成します (cluster-ingress-02-config.yml)。

Ingress リソースの YAML 定義

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

Copy to clipboard

インストールプログラムは、このアセットを manifests/ ディレクトリーの cluster-ingress-02-config.yml ファイルに保存します。この Ingress リソースは、Ingress のクラスター全体の設定を定義します。この Ingress 設定は、以下のように使用されます。

Ingress Operator は、クラスター Ingress 設定のドメインを、デフォルト Ingress Controller のドメインとして使用します。
OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない Route リソースのデフォルトホストを生成する際にも使用されます。

4.8.3. Ingress Controller 設定パラメーター

IngressController カスタムリソース (CR) には、組織の特定のニーズを満たすように設定できる任意の設定パラメーターが含まれています。

パラメーター	説明
`domain`	`domain` は Ingress Controller によって提供される DNS 名で、複数の機能を設定するために使用されます。 `LoadBalancerService` エンドポイント公開ストラテジーの場合、`domain` は DNS レコードを設定するために使用されます。`endpointPublishingStrategy` を参照してください。生成されるデフォルト証明書を使用する場合、証明書は `domain` およびその `subdomains` で有効です。`defaultCertificate` を参照してください。この値は個別の Route ステータスに公開され、ユーザーは外部 DNS レコードのターゲット先を認識できるようにします。 `domain` 値はすべての Ingress Controller の中でも固有の値であり、更新できません。空の場合、デフォルト値は `ingress.config.openshift.io/cluster` `.spec.domain` です。
`replicas`	`replicas` は、Ingress Controller レプリカの数です。設定されていない場合、デフォルト値は `2` になります。
`endpointPublishingStrategy`	`endpointPublishingStrategy` は Ingress Controller エンドポイントを他のネットワークに公開し、ロードバランサーの統合を有効にし、他のシステムへのアクセスを提供するために使用されます。クラウド環境の場合、`loadBalancer` フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。 GCP、AWS、および Azure では、次の `endpointPublishingStrategy` フィールドを設定できます。 `loadBalancer.scope` `loadBalancer.allowedSourceRanges` 設定されていない場合、デフォルト値は `infrastructure.config.openshift.io/cluster` `.status.platform` をベースとします。 Azure: `LoadBalancerService` (外部スコープあり) Google Cloud Platform (GCP): `LoadBalancerService` (外部スコープあり) ほとんどのプラットフォームでは、`endpointPublishingStrategy` 値は更新できます。GCP では、次の `endpointPublishingStrategy` フィールドを設定できます。 `loadBalancer.scope` `loadbalancer.providerParameters.gcp.clientAccess` ベアメタルプラットフォームなどの非クラウド環境の場合は、`NodePortService`、`HostNetwork`、または `Private` フィールドを使用して、Ingress Controller のエンドポイント公開ストラテジーを設定します。これらのフィールドのいずれかで値を設定しない場合のデフォルト値は、`IngressController` CR の `.status.platform` 値で指定されたバインディングポートに基づきます。クラスターのデプロイ後に、`endpointPublishingStrategy` の値を更新する必要がある場合は、次の `endpointPublishingStrategy` フィールドを設定できます。 `hostNetwork.protocol` `nodePort.protocol` `private.protocol`
`defaultCertificate`	`defaultCertificate` 値は、Ingress Controller によって提供されるデフォルト証明書が含まれるシークレットへの参照です。ルートが独自の証明書を指定しない場合、`defaultCertificate` が使用されます。シークレットには以下のキーおよびデータが含まれる必要があります: * `tls.crt`: 証明書ファイルコンテンツ * `tls.key`: キーファイルコンテンツ設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの `domain` および `subdomains` で有効であり、生成された証明書 CA はクラスターの信頼ストアに自動的に統合されます。使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。
`namespaceSelector`	`namespaceSelector` は、Ingress Controller によって提供される namespace セットをフィルターするために使用されます。これはシャードの実装に役立ちます。
`routeSelector`	`routeSelector` は、Ingress Controller によって提供される Routes のセットをフィルターするために使用されます。これはシャードの実装に役立ちます。
`nodePlacement`	`nodePlacement` は、Ingress Controller のスケジュールに対する明示的な制御を有効にします。設定されていない場合は、デフォルト値が使用されます。注記 `nodePlacement` パラメーターには、`nodeSelector` と `tolerations` の 2 つの部分が含まれます。以下に例を示します。 `nodePlacement: nodeSelector: matchLabels: kubernetes.io/os: linux tolerations: - effect: NoSchedule operator: Exists` Copy to clipboard
`tlsSecurityProfile`	`tlsSecurityProfile` は、Ingress Controller の TLS 接続の設定を指定します。これが設定されていない場合、デフォルト値は `apiservers.config.openshift.io/cluster` リソースをベースとして設定されます。 `Old`、`Intermediate`、および `Modern` のプロファイルタイプを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース `X.Y.Z` にデプロイされた `Intermediate` プロファイルを使用する仕様がある場合、リリース `X.Y.Z+1` へのアップグレードにより、新規のプロファイル設定が Ingress Controller に適用され、ロールアウトが生じる可能性があります。 Ingress Controller の最小 TLS バージョンは `1.1` で、最大 TLS バージョンは `1.3` です。注記設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが `TLSProfile` ステータスに反映されます。重要 Ingress Operator は TLS `1.0` の `Old` または `Custom` プロファイルを `1.1` に変換します。
`clientTLS`	`clientTLS` は、クラスターおよびサービスへのクライアントアクセスを認証します。その結果、相互 TLS 認証が有効になります。設定されていない場合、クライアント TLS は有効になっていません。 `clientTLS` には、必要なサブフィールド `spec.clientTLS.clientCertificatePolicy` および `spec.clientTLS.ClientCA` があります。 `ClientCertificatePolicy` サブフィールドは、`Required` または `Optional` の 2 つの値のいずれかを受け入れます。`ClientCA` サブフィールドは、openshift-config namespace にある config map を指定します。config map には CA 証明書バンドルが含まれている必要があります。 `AllowedSubjectPatterns` は、要求をフィルターするために有効なクライアント証明書の識別名と照合される正規表現のリストを指定する任意の値です。正規表現は PCRE 構文を使用する必要があります。1 つ以上のパターンがクライアント証明書の識別名と一致している必要があります。一致しない場合、Ingress Controller は証明書を拒否し、接続を拒否します。指定しないと、Ingress Controller は識別名に基づいて証明書を拒否しません。
`routeAdmission`	`routeAdmission` は、複数の namespace での要求の許可または拒否など、新規ルート要求を処理するためのポリシーを定義します。 `namespaceOwnership` は、namespace 間でホスト名の要求を処理する方法を記述します。デフォルトは `Strict` です。 `Strict`: ルートが複数の namespace 間で同じホスト名を要求することを許可しません。 `InterNamespaceAllowed`: ルートが複数の namespace 間で同じホスト名の異なるパスを要求することを許可します。 `wildcardPolicy` は、ワイルドカードポリシーを使用するルートが Ingress Controller によって処理される方法を記述します。 `WildcardsAllowed`: ワイルドカードポリシーと共にルートが Ingress Controller によって許可されていることを示します。 `WildcardsDisallowed`: ワイルドカードポリシーの `None` を持つルートのみが Ingress Controller によって許可されることを示します。`wildcardPolicy` を `WildcardsAllowed` から `WildcardsDisallowed` に更新すると、ワイルドカードポリシーの `Subdomain` を持つ許可されたルートが機能を停止します。これらのルートは、Ingress Controller によって許可されるように `None` のワイルドカードポリシーに対して再作成される必要があります。`WildcardsDisallowed` はデフォルト設定です。
`IngressControllerLogging`	`logging` はログに記録される内容および場所のパラメーターを定義します。このフィールドが空の場合、操作ログは有効になりますが、アクセスログは無効になります。 `access` は、クライアント要求をログに記録する方法を記述します。このフィールドが空の場合、アクセスロギングは無効になります。 `destination` はログメッセージの宛先を記述します。 `type` はログの宛先のタイプです。 `Container` は、ログがサイドカーコンテナーに移動することを指定します。Ingress Operator は Ingress Controller Pod で logs という名前のコンテナーを設定し、Ingress Controller がログをコンテナーに書き込むように設定します。管理者がこのコンテナーからログを読み取るカスタムロギングソリューションを設定することが予想されます。コンテナーログを使用すると、ログの割合がコンテナーランタイムの容量やカスタムロギングソリューションの容量を超えるとログがドロップされることがあります。 `Syslog` は、ログが Syslog エンドポイントに送信されることを指定します。管理者は、Syslog メッセージを受信できるエンドポイントを指定する必要があります。管理者がカスタム Syslog インスタンスを設定していることが予想されます。 `container` は `Container` ロギング宛先タイプのパラメーターを記述します。現在、コンテナーロギングのパラメーターはないため、このフィールドは空である必要があります。 `syslog` は、`Syslog` ロギング宛先タイプのパラメーターを記述します。 `address` は、ログメッセージを受信する syslog エンドポイントの IP アドレスです。 `port` は、ログメッセージを受信する syslog エンドポイントの UDP ポート番号です。 `maxLength` は、syslog メッセージの最大長です。サイズは `480` から `4096` バイトである必要があります。このフィールドが空の場合には、最大長はデフォルト値の `1024` バイトに設定されます。 `facility` はログメッセージの syslog ファシリティーを指定します。このフィールドが空の場合、ファシリティーは `local1` になります。それ以外の場合、有効な syslog ファシリティー (`kern`、`user`、`mail`、`daemon`、`auth`、`syslog`、`lpr`、`news`、`uucp`、`cron`、`auth2`、`ftp`、`ntp`、`audit`、`alert`、`cron2`、`local0`、`local1`、`local2`、`local3`) を指定する必要があります。`local4`、`local5`、`local6`、または `local7`。 `httpLogFormat` は、HTTP 要求のログメッセージの形式を指定します。このフィールドが空の場合、ログメッセージは実装のデフォルト HTTP ログ形式を使用します。HAProxy のデフォルトの HTTP ログ形式は、HAProxy ドキュメントを参照してください。
`httpHeaders`	`httpHeaders` は HTTP ヘッダーのポリシーを定義します。 `IngressControllerHTTPHeaders` の `forwardedHeaderPolicy` を設定することで、Ingress Controller が `Forwarded`、`X-Forwarded-For`、`X-Forwarded-Host`、`X-Forwarded-Port`、`X-Forwarded-Proto`、および `X-Forwarded-Proto-Version` HTTP ヘッダーをいつどのように設定するか指定します。デフォルトでは、ポリシーは `Append` に設定されます。 `Append` は、Ingress Controller がヘッダーを追加するように指定し、既存のヘッダーを保持します。 `Replace` は、Ingress Controller がヘッダーを設定するように指定し、既存のヘッダーを削除します。 `IfNone` は、ヘッダーがまだ設定されていない場合に、Ingress Controller がヘッダーを設定するように指定します。 `Never` は、Ingress Controller がヘッダーを設定しないように指定し、既存のヘッダーを保持します。 `headerNameCaseAdjustments` を設定して、HTTP ヘッダー名に適用できるケースの調整を指定できます。それぞれの調整は、必要な大文字化を指定して HTTP ヘッダー名として指定されます。たとえば、`X-Forwarded-For` を指定すると、指定された大文字化を有効にするために `x-forwarded-for` HTTP ヘッダーを調整する必要があることを示唆できます。これらの調整は、クリアテキスト、edge-terminated、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。要求ヘッダーの場合、これらの調整は `haproxy.router.openshift.io/h1-adjust-case=true` アノテーションを持つルートにのみ適用されます。応答ヘッダーの場合、これらの調整はすべての HTTP 応答に適用されます。このフィールドが空の場合、要求ヘッダーは調整されません。 `actions` は、ヘッダーに対して特定のアクションを実行するためのオプションを指定します。TLS パススルー接続のヘッダーは設定または削除できません。`actions` フィールドには、`spec.httpHeader.actions.response` および `spec.httpHeader.actions.request` の追加のサブフィールドがあります。 `response` サブフィールドは、設定または削除する HTTP 応答ヘッダーのリストを指定します。 `request` サブフィールドは、設定または削除する HTTP 要求ヘッダーのリストを指定します。
`httpCompression`	`httpCompression` は、HTTP トラフィック圧縮のポリシーを定義します。 `mimeTypes` は、圧縮を適用する必要がある MIME タイプのリストを定義します。(例: `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`)`types` は、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または `X-` で始まるカスタムタイプ。例: MIME タイプとサブタイプの完全な表記を確認するには、RFC1341 を参照してください。
`httpErrorCodePages`	`httpErrorCodePages` は、カスタムの HTTP エラーコードの応答ページを指定します。デフォルトで、IngressController は IngressController イメージにビルドされたエラーページを使用します。
`httpCaptureCookies`	`httpCaptureCookies` は、アクセスログにキャプチャーする HTTP Cookie を指定します。`httpCaptureCookies` フィールドが空の場合、アクセスログは Cookie をキャプチャーしません。キャプチャーするすべての Cookie について、次のパラメーターが `IngressController` 設定に含まれている必要があります。 `name` は、Cookie の名前を指定します。 `maxLength` は、Cookie の最大長を指定します。 `matchType` は、Cookie のフィールドの `name` が、キャプチャー Cookie 設定と完全に一致するか、キャプチャー Cookie 設定の接頭辞であるかを指定します。`matchType` フィールドは `Exact` および `Prefix` パラメーターを使用します。以下に例を示します。 `httpCaptureCookies: - matchType: Exact maxLength: 128 name: MYCOOKIE` Copy to clipboard
`httpCaptureHeaders`	`httpCaptureHeaders` は、アクセスログにキャプチャーする HTTP ヘッダーを指定します。`httpCaptureHeaders` フィールドが空の場合、アクセスログはヘッダーをキャプチャーしません。 `httpCaptureHeaders` には、アクセスログにキャプチャーするヘッダーの 2 つのリストが含まれています。ヘッダーフィールドの 2 つのリストは `request` と `response` です。どちらのリストでも、`name` フィールドはヘッダー名を指定し、`maxlength` フィールドはヘッダーの最大長を指定する必要があります。以下に例を示します。 `httpCaptureHeaders: request: - maxLength: 256 name: Connection - maxLength: 128 name: User-Agent response: - maxLength: 256 name: Content-Type - maxLength: 256 name: Content-Length` Copy to clipboard
`tuningOptions`	`tuningOptions` は、Ingress Controller Pod のパフォーマンスを調整するためのオプションを指定します。 `clientFinTimeout` は、クライアントの応答が接続を閉じるのを待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは `1s` です。 `clientTimeout` は、クライアント応答の待機中に接続が開かれる期間を指定します。デフォルトのタイムアウトは `30s` です。 `headerBufferBytes` は、Ingress Controller 接続セッション用に予約されるメモリーの量をバイト単位で指定します。Ingress Controller で HTTP / 2 が有効になっている場合、この値は少なくとも `16384` である必要があります。設定されていない場合、デフォルト値は `32768` バイトになります。このフィールドを設定することは推奨しません。`headerBufferBytes` 値が小さすぎると Ingress Controller が破損する可能性があり、`headerBufferBytes` 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。 `headerBufferMaxRewriteBytes` は、HTTP ヘッダーの書き換えと Ingress Controller 接続セッションの追加のために `headerBufferBytes` から予約するメモリーの量をバイト単位で指定します。`headerBufferMaxRewriteBytes` の最小値は `4096` です。受信 HTTP 要求には、`headerBufferBytes` は `headerBufferMaxRewriteBytes` よりも大きくなければなりません。設定されていない場合、デフォルト値は `8192` バイトになります。このフィールドを設定することは推奨しません。`headerBufferMaxRewriteBytes` 値が小さすぎると Ingress Controller が破損する可能性があり、`headerBufferMaxRewriteBytes` 値が大きすぎると、Ingress Controller が必要以上のメモリーを使用する可能性があるためです。 `healthCheckInterval` は、ルーターがヘルスチェックの間隔として待機する時間を指定します。デフォルトは `5s` です。 `serverFinTimeout` は、接続を閉じるクライアントへの応答を待つ間、接続が開かれる期間を指定します。デフォルトのタイムアウトは `1s` です。 `serverTimeout` は、サーバーの応答を待機している間に接続が開かれる期間を指定します。デフォルトのタイムアウトは `30s` です。 `threadCount` は、HAProxy プロセスごとに作成するスレッドの数を指定します。より多くのスレッドを作成すると、使用されるシステムリソースを増やすことで、各 Ingress Controller Pod がより多くの接続を処理できるようになります。HAProxy は最大 `64` のスレッドをサポートします。このフィールドが空の場合、Ingress Controller はデフォルト値の `4` スレッドを使用します。デフォルト値は、将来のリリースで変更される可能性があります。このフィールドを設定することは推奨しません。HAProxy スレッドの数を増やすと、Ingress Controller Pod が負荷時に CPU 時間をより多く使用できるようになり、他の Pod が実行に必要な CPU リソースを受け取れないようになるためです。スレッドの数を減らすと、Ingress Controller のパフォーマンスが低下する可能性があります。 `tlsInspectDelay` は、一致するルートを見つけるためにルーターがデータを保持する期間を指定します。この値の設定が短すぎると、より一致する証明書を使用している場合でも、ルーターがエッジ終端、再暗号化された、またはパススルーのルートのデフォルトの証明書にフォールバックする可能性があります。デフォルトの検査遅延は `5s` です。 `tunnelTimeout` は、トンネルがアイドル状態の間、websocket などのトンネル接続期間を開いた期間を指定します。デフォルトのタイムアウトは `1h` です。 `maxConnections` は、HAProxy プロセスごとに確立できる同時接続の最大数を指定します。この値を増やすと、追加のシステムリソースで各 Ingress Controller Pod がより多くの接続を処理できるようになります。`0`、`-1`、`2000` から `2000000` の範囲内の任意の値を使用でき、フィールドを空にすることも可能です。このフィールドが空のままであるか、値が `0` の場合、Ingress Controller はデフォルト値の `50000` を使用します。この値は、今後のリリースで変更される可能性があります。フィールド値が `-1` の場合、HAProxy は、実行中のコンテナーで使用可能な `ulimit` に基づき最大値を動的に計算します。このプロセスにより、計算値が大きくなり、現在のデフォルト値である `50000` と比較してかなり大きなメモリー使用量が発生します。フィールドの値が現在のオペレーティングシステムの制限よりも大きい場合、HAProxy プロセスは開始されません。個別の値を選択し、ルーター Pod が新しいノードに移行された場合、新しいノードに同一の `ulimit` が設定されていない可能性があります。このような場合、Pod は起動に失敗します。異なる `ulimit` を持つノードが設定されていて、離散値を選択する場合は、実行時に接続の最大数が計算されるように、このフィールドに `-1` の値を使用することを推奨します。
`logEmptyRequests`	`logEmptyRequests` は、リクエストを受け取らず、ログに記録されない接続を指定します。これらの空の要求は、ロードバランサーヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から送信され、これらの要求をログに記録することは望ましくない場合があります。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。この場合は、空の要求をログに記録すると、エラーの診断に役立ちます。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。このフィールドに使用できる値は `Log` および `Ignore` です。デフォルト値は `Log` です。 `LoggingPolicy` タイプは、以下のいずれかの値を受け入れます。 `ログ`: この値を `Log` に設定すると、イベントがログに記録される必要があることを示します。 `Ignore`: この値を `Ignore` に設定すると、HAproxy 設定の `dontlognull` オプションを設定します。
`HTTPEmptyRequestsPolicy`	`HTTPEmptyRequestsPolicy` は、リクエストを受け取る前に接続がタイムアウトした場合に HTTP 接続を処理する方法を記述します。このフィールドに使用できる値は `Respond` および `Ignore` です。デフォルト値は `Respond` です。 `HTTPEmptyRequestsPolicy` タイプは、以下のいずれかの値を受け入れます。 `応答`: フィールドが `Respond` に設定されている場合、Ingress Controller は HTTP `400` または `408` 応答を送信する場合、アクセスログが有効な場合に接続をログに記録し、適切なメトリックで接続をカウントします。 `ignore`: このオプションを `Ignore` に設定すると HAproxy 設定に `http-ignore-probes` パラメーターが追加されます。フィールドが `Ignore` に設定されている場合、Ingress Controller は応答を送信せずに接続を閉じると、接続をログに記録するか、メトリックを増分します。これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続 (事前接続) から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを `Ignore` に設定すると問題の検出と診断が妨げられる可能性があります。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。

4.8.3.1. Ingress Controller の TLS セキュリティープロファイル

TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。

4.8.3.1.1. TLS セキュリティープロファイルについて

TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定に基づいています。

コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。

表4.11 TLS セキュリティープロファイル
プロファイル	説明
`Old`	このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性の推奨設定に基づいています。 `Old` プロファイルには、最小 TLS バージョン 1.0 が必要です。注記 Ingress Controller の場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。
`中級者`	このプロファイルは、Ingress Controller、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性の推奨設定に基づいています。 `Intermediate` プロファイルには、最小 TLS バージョン 1.2 が必要です。注記このプロファイルは、大多数のクライアントに推奨される設定です。
`Modern`	このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性の推奨設定に基づいています。 `Modern` プロファイルには、最小 TLS バージョン 1.3 が必要です。
`カスタム`	このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。警告無効な設定により問題が発生する可能性があるため、`Custom` プロファイルを使用する際には注意してください。

注記

事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。

4.8.3.1.2. Ingress Controller の TLS セキュリティープロファイルの設定

Ingress Controller の TLS セキュリティープロファイルを設定するには、IngressController カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。

Old TLS のセキュリティープロファイルを設定するサンプル IngressController CR

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

Copy to clipboard

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 clipboardCopied

spec.tlsSecurityProfile フィールドを追加します。

Custom プロファイルのサンプル IngressController CR

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    type: Custom 1
    custom: 2
      ciphers: 3
      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
 ...

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

1

TLS セキュリティープロファイルタイプ (Old、Intermediate、または Custom) を指定します。デフォルトは Intermediate です。

2

選択したタイプに適切なフィールドを指定します。

old: {}
intermediate: {}
custom:

3

custom タイプには、TLS 暗号のリストと最小許容 TLS バージョンを指定します。

変更を適用するためにファイルを保存します。

検証

IngressController CR にプロファイルが設定されていることを確認します。

oc describe IngressController default -n openshift-ingress-operator

$ oc describe IngressController default -n openshift-ingress-operator

Copy to clipboard

出力例

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

4.8.3.1.3. 相互 TLS 認証の設定

spec.clientTLS 値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress Controller を設定できます。clientTLS 値は、クライアント証明書を検証するように Ingress Controller を設定します。この設定には、config map の参照である clientCA 値の設定が含まれます。config map には、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターのリストも設定できます。

clientCA 値が X509v3 証明書失効リスト (CRL) ディストリビューションポイントを指定している場合、Ingress Operator は、提供された各証明書で指定されている HTTP URI X509v3 CRL Distribution Point に基づいて CRL config map をダウンロードおよび管理します。Ingress Controller は、mTLS/TLS ネゴシエーション中にこの config map を使用します。有効な証明書を提供しない要求は拒否されます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
PEM でエンコードされた CA 証明書バンドルがある。

CA バンドルが CRL ディストリビューションポイントを参照する場合は、エンドエンティティーまたはリーフ証明書もクライアント CA バンドルに含める必要があります。この証明書には、RFC 5280 で説明されているとおり、この証明書の CRL Distribution Points に HTTP URI が含まれている必要があります。以下に例を示します。

 Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
         Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.example.com/example.crl

 Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
         Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.example.com/example.crl

Copy to clipboard

手順

openshift-config namespace で、CA バンドルから config map を作成します。

oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \1

$ oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \1
   -n openshift-config

Copy to clipboard

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

spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。

フィルタリングパターンを指定する clientTLS プロファイルのサンプル IngressController CR

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    clientTLS:
      clientCertificatePolicy: Required
      clientCA:
        name: router-ca-certs-default
      allowedSubjectPatterns:
      - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

  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

オプションで、次のコマンドを入力して、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

Copy to clipboard

4.8.4. デフォルト Ingress Controller の表示

Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。

すべての新規 OpenShift Container Platform インストールには、ingresscontroller の名前付きのデフォルトがあります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。

手順

デフォルト Ingress Controller を表示します。

oc describe --namespace=openshift-ingress-operator ingresscontroller/default

$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

Copy to clipboard

4.8.5. Ingress Operator ステータスの表示

Ingress Operator のステータスを表示し、検査することができます。

手順

Ingress Operator ステータスを表示します。
```
oc describe clusteroperators/ingress
```
```
$ oc describe clusteroperators/ingress
```
Copy to clipboardCopied

4.8.6. Ingress Controller ログの表示

Ingress Controller ログを表示できます。

手順

Ingress Controller ログを表示します。

oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

Copy to clipboard

4.8.7. Ingress Controller ステータスの表示

特定の Ingress Controller のステータスを表示できます。

手順

Ingress Controller のステータスを表示します。

oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

Copy to clipboard

4.8.8. カスタム Ingress Controller の作成

クラスター管理者は、新規のカスタム Ingress Controller を作成できます。デフォルトの Ingress Controller は OpenShift Container Platform の更新時に変更される可能性があるため、クラスターの更新後も保持される設定を手動で維持する場合は、カスタム Ingress Controller を作成すると便利です。

この例では、カスタム Ingress Controller の最小限の仕様を提供します。カスタム Ingress Controller をさらにカスタマイズするには、「Ingress Controller の設定」を参照してください。

前提条件

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

手順

カスタム IngressController オブジェクトを定義する YAML ファイルを作成します。
custom-ingress-controller.yaml ファイルの例
```
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
```
```
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 clipboardCopied
1
IngressController オブジェクトのカスタム 名 を指定します。
2
カスタムワイルドカード証明書でシークレットの名前を指定します。
3
最小レプリカは ONE である必要があります
4
ドメイン名のドメインを指定します。IngressController オブジェクトで指定されるドメインと、証明書に使用されるドメインが一致する必要があります。たとえば、ドメイン値が "custom_domain.mycompany.com" の場合、証明書には SAN *.custom_domain.mycompany.com が必要です (*. がドメインに追加されます)。
以下のコマンドを実行してオブジェクトを作成します。
```
oc create -f custom-ingress-controller.yaml
```
```
$ oc create -f custom-ingress-controller.yaml
```
Copy to clipboardCopied

4.8.9. Ingress Controller の設定

4.8.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

出力例

NAME      AGE
default   10m

NAME      AGE
default   10m

Copy to clipboard

注記

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

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

更新が正常に行われていることを確認します。

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

ここでは、以下のようになります。

<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

ヒント

または、以下の 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

証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress Controller のデプロイメントを更新します。

4.8.9.2. カスタムデフォルト証明書の削除

管理者は、使用する Ingress Controller を設定したカスタム証明書を削除できます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
OpenShift CLI (oc) がインストールされている。
Ingress Controller のカスタムデフォルト証明書を設定している。

手順

カスタム証明書を削除し、OpenShift Container Platform に同梱されている証明書を復元するには、以下のコマンドを入力します。
```
oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
```
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
Copy to clipboardCopied
クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。

検証

元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。

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

ここでは、以下のようになります。

<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

4.8.9.3. Ingress Controller の自動スケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に動的に対応するために自動でスケーリングできます。

以下の手順では、デフォルトの Ingress Controller をスケールアップする例を示します。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
Custom Metrics Autoscaler Operator と関連する KEDA Controller がインストールされている。
- この Operator は、Web コンソールで OperatorHub を使用してインストールできます。Operator をインストールしたら、KedaController のインスタンスを作成できます。

手順

以下のコマンドを実行して、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

出力例

Name:                thanos
Namespace:           openshift-ingress-operator
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-kfvf2
Mountable secrets:   thanos-dockercfg-kfvf2
Tokens:              <none>
Events:              <none>

Name:                thanos
Namespace:           openshift-ingress-operator
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-kfvf2
Mountable secrets:   thanos-dockercfg-kfvf2
Tokens:              <none>
Events:              <none>

Copy to clipboard

次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。

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

サービスアカウントのトークンを使用して、openshift-ingress-operator namespace 内で TriggerAuthentication オブジェクトを定義します。

TriggerAuthentication オブジェクトを作成し、secret 変数の値を TOKEN パラメーターに渡します。

oc apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
  namespace: openshift-ingress-operator
spec:
  secretTargetRef:
  - parameter: bearerToken
    name: thanos-token
    key: token
  - parameter: ca
    name: thanos-token
    key: ca.crt
EOF

$ oc apply -f - <<EOF
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
  namespace: openshift-ingress-operator
spec:
  secretTargetRef:
  - parameter: bearerToken
    name: thanos-token
    key: token
  - parameter: ca
    name: thanos-token
    key: ca.crt
EOF

Copy to clipboard

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

以下のコマンドを実行して新規ロールを適用します。
```
oc apply -f thanos-metrics-reader.yaml
```
```
$ oc apply -f thanos-metrics-reader.yaml
```
Copy to clipboardCopied

以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。

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

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

注記

引数 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: 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

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

1: 対象とするカスタムリソース。この場合、Ingress Controller。
2: オプション: レプリカの最大数。このフィールドを省略すると、デフォルトの最大値は 100 レプリカに設定されます。
3: openshift-monitoring namespace の Thanos サービスエンドポイント。
4: Ingress Operator namespace。
5: この式は、デプロイされたクラスターに存在するワーカーノードの数に対して評価されます。

重要

namespace 間クエリーを使用している場合は、serverAddress フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

以下のコマンドを実行してカスタムリソース定義を適用します。
```
oc apply -f ingress-autoscaler.yaml
```
```
$ oc apply -f ingress-autoscaler.yaml
```
Copy to clipboardCopied

検証

以下のコマンドを実行して、デフォルトの 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

出力例

  replicas: 3

  replicas: 3

Copy to clipboard

openshift-ingress プロジェクトで Pod を取得します。

oc get pods -n openshift-ingress

$ oc get pods -n openshift-ingress

Copy to clipboard

出力例

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

関連情報

4.8.9.4. Ingress Controller のスケーリング

Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc コマンドは、IngressController リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。

注記

スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。

手順

デフォルト IngressController の現在の利用可能なレプリカ数を表示します。

oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

Copy to clipboard

出力例

Copy to clipboard

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

出力例

ingresscontroller.operator.openshift.io/default patched

ingresscontroller.operator.openshift.io/default patched

Copy to clipboard

デフォルトの 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

出力例

Copy to clipboard

ヒント

または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3               1

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3               1

Copy to clipboard

1: 異なる数のレプリカが必要な場合は replicas 値を変更します。

4.8.9.5. Ingress アクセスロギングの設定

アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。

コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress Controller で問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。

アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。

前提条件

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

手順

サイドカーへの Ingress アクセスロギングを設定します。

Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container spec.logging.access.destination.type を指定する必要があります。以下の例は、コンテナー Container の宛先に対してログ記録する Ingress Controller 定義です。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container

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

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

出力例

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

Syslog エンドポイントへの Ingress アクセスロギングを設定します。

Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type に Syslog を指定する必要があります。宛先タイプが Syslog の場合、spec.logging.access.destination.syslog.address を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility を使用してファシリティーを指定できます。以下の例は、Syslog 宛先に対してログを記録する Ingress Controller の定義です。
```
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 clipboardCopied
注記
syslog 宛先ポートは UDP である必要があります。
syslog の宛先アドレスは IP アドレスにする必要があります。DNS ホスト名はサポートされていません。

特定のログ形式で Ingress アクセスロギングを設定します。

spec.logging.access.httpLogFormat を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 の syslog エンドポイントに対してログを記録する Ingress Controller の定義です。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

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

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

サイドカーの使用時に 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

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

4.8.9.6. Ingress Controller スレッド数の設定

クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress Controller にパッチを適用して、スレッドの数を増やすことができます。

前提条件

以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

Ingress Controller を更新して、スレッド数を増やします。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
Copy to clipboardCopied
注記
大量のリソースを実行できるノードがある場合、spec.nodePlacement.nodeSelector を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount を随時高い値に設定します。

4.8.9.7. 内部ロードバランサーを使用するための Ingress Controller の設定

クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの Egress 接続を失います。

重要

IngressController の scope を変更する場合は、カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更します。

図4.2 LoadBalancer の図

OpenShift Container Platform Ingress LoadBalancerService エンドポイント公開ストラテジー

前述の図では、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> 1
spec:
  domain: <domain> 2
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal 3

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

1: <name> を IngressController オブジェクトの名前に置き換えます。
2: コントローラーによって公開されるアプリケーションの ドメイン を指定します。
3: 内部ロードバランサーを使用するために Internal の値を指定します。

以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。
```
oc create -f <name>-ingress-controller.yaml 1
```
```
$ oc create -f <name>-ingress-controller.yaml 1
```
Copy to clipboardCopied
1
<name> を IngressController オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。
```
oc --all-namespaces=true get ingresscontrollers
```
```
$ oc --all-namespaces=true get ingresscontrollers
```
Copy to clipboardCopied

4.8.9.8. GCP での Ingress Controller のグローバルアクセスの設定

内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。

詳細情報は、GCP ドキュメントのグローバルアクセスを参照してください。

前提条件

OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
内部ロードバランサーを使用するように Ingress Controller を設定している。
OpenShift CLI (oc) がインストールされている。

手順

グローバルアクセスを許可するように Ingress Controller リソースを設定します。

注記

Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。

Ingress Controller リソースを設定します。

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to clipboard

YAML ファイルを編集します。

サンプル clientAccess 設定を Global に設定します。

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global 1
          type: GCP
        scope: Internal
      type: LoadBalancerService

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global 1
          type: GCP
        scope: Internal
      type: LoadBalancerService

Copy to clipboard

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 clipboardCopied
この出力では、グローバルアクセスがアノテーション networking.gke.io/internal-load-balancer-allow-global-access で GCP について有効にされていることを示しています。

4.8.9.9. Ingress Controller のヘルスチェック間隔の設定

クラスター管理者は、ヘルスチェックの間隔を設定して、ルーターが連続する 2 回のヘルスチェックの間で待機する時間を定義できます。この値は、すべてのルートのデフォルトとしてグローバルに適用されます。デフォルト値は 5 秒です。

前提条件

以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

Ingress Controller を更新して、バックエンドヘルスチェックの間隔を変更します。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
Copy to clipboardCopied
注記
単一ルートの healthCheckInterval をオーバーライドするには、ルートアノテーション router.openshift.io/haproxy.health.check.interval を使用します

4.8.9.10. クラスターを内部に配置するためのデフォルト Ingress Controller の設定

削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定できます。

警告

重要

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

4.8.9.11. ルートの受付ポリシーの設定

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。

警告

複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。

前提条件

クラスター管理者の権限。

手順

以下のコマンドを使用して、ingresscontroller リソース変数の .spec.routeAdmission フィールドを編集します。

oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

$ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

Copy to clipboard

イメージコントローラー設定例

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

Copy to clipboard

ヒント

または、以下の 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

4.8.9.12. ワイルドカードルートの使用

HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。

Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。

手順

ワイルドカードポリシーを設定します。
1. 以下のコマンドを使用して IngressController リソースを編集します。
```
oc edit IngressController
```
```
$ oc edit IngressController
```
  Copy to clipboardCopied
2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。
```
spec:
  routeAdmission:
    wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
```
```
spec:
  routeAdmission:
    wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
```
  Copy to clipboardCopied

4.8.9.13. HTTP ヘッダーの設定

OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。

注記

IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。

4.8.9.13.1. 優先順位

同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。

HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。

たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY を設定します。

IngressController 仕様の例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

Copy to clipboard

ルート所有者は、クラスター管理者が 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

Copy to clipboard

IngressController 仕様と Route 仕様の両方で X-Frame-Options 応答ヘッダーが設定されている場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。リクエストヘッダーの場合、Route 仕様の値が IngressController 仕様の値をオーバーライドします。

この優先順位付けは、haproxy.config ファイルで次のロジックが使用されるため発生します。このロジックでは、Ingress Controller がフロントエンドと見なされ、個々のルートがバックエンドと見なされます。フロントエンド設定に適用されるヘッダー値 DENY は、バックエンドで設定されている値 SAMEORIGIN で同じヘッダーをオーバーライドします。

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

Copy to clipboard

さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

4.8.9.13.2. 特殊なケースのヘッダー

次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。

表4.12 特殊な場合のヘッダー設定オプション
ヘッダー名	`IngressController` 仕様を使用して設定可能かどうか	`Route` 仕様を使用して設定可能かどうか	不許可の理由	別の方法で設定可能かどうか
`proxy`	いいえ	いいえ	`プロキシー` HTTP リクエストヘッダーを使用して、ヘッダー値を `HTTP_PROXY` 環境変数に挿入して、脆弱な CGI アプリケーションを悪用できます。`プロキシー` HTTP リクエストヘッダーも標準ではないため、設定中にエラーが発生しやすくなります。	いいえ
`host`	いいえ	はい	`IngressController` CR を使用して `ホスト` HTTP 要求ヘッダーが設定されている場合、HAProxy は正しいルートを検索するときに失敗する可能性があります。	いいえ
`strict-transport-security`	いいえ	いいえ	`strict-transport-security` HTTP 応答ヘッダーはルートアノテーションを使用してすでに処理されているため、別の実装は必要ありません。	はい: `haproxy.router.openshift.io/hsts_header` ルートアノテーション
`cookie` と `set-cookie`	いいえ	いいえ	HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。	はい: `haproxy.router.openshift.io/disable_cookie` ルートアノテーション `haproxy.router.openshift.io/cookie_name` ルートアノテーション

4.8.9.14. Ingress Controller での HTTP リクエストおよびレスポンスヘッダーの設定または削除

コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。

たとえば、相互 TLS を使用するようにクラスター上で実行されているアプリケーションを移行する場合があります。このような場合、お使いのアプリケーションで X-Forwarded-Client-Cert リクエストヘッダーをチェックする必要がありますが、OpenShift Container Platform のデフォルトの Ingress Controller は X-SSL-Client-Der リクエストヘッダーを提供します。

次の手順では、Ingress Controller を変更して X-Forwarded-Client-Cert リクエストヘッダーを設定し、X-SSL-Client-Der リクエストヘッダーを削除します。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。

手順

Ingress Controller リソースを編集します。

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to clipboard

X-SSL-Client-Der HTTP リクエストヘッダーは X-Forwarded-Client-Cert HTTP リクエストヘッダーに置き換えます。
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpHeaders:
    actions: 1
      request: 2
      - name: X-Forwarded-Client-Cert 3
        action:
          type: Set 4
          set:
           value: "%{+Q}[ssl_c_der,base64]" 5
      - name: X-SSL-Client-Der
        action:
          type: Delete
```
```
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 clipboardCopied
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 コンバーターを使用できます。
変更を適用するためにファイルを保存します。

4.8.9.15. X-Forwarded ヘッダーの使用

Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法に関するポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。

手順

Ingress Controller 用に HTTPHeaders フィールドを設定します。

以下のコマンドを使用して IngressController リソースを編集します。
```
oc edit IngressController
```
```
$ oc edit IngressController
```
Copy to clipboardCopied

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

使用例

クラスター管理者として、以下を実行できます。

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 アノテーションをルートごとに設定できます。

4.8.9.16. Ingress コントローラーで HTTP/2 を有効または無効にする

HAProxy で透過的なエンドツーエンドの HTTP/2 接続を有効化または無効化できます。アプリケーション所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなどの HTTP/2 プロトコル機能を使用できます。

個別の Ingress Controller またはクラスター全体について、HTTP/2 接続を有効化または無効化できます。

注記

個々の Ingress コントローラーおよびクラスター全体に対して HTTP/2 接続を有効または無効にすると、Ingress コントローラーの HTTP/2 設定がクラスターの HTTP/2 設定よりも優先されます。

クライアントから HAProxy インスタンスへの接続に HTTP/2 の使用を有効にするには、ルートでカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。

各ルートタイプにおける HTTP/2 接続の次のユースケースを検討してください。

再暗号化ルートの場合、アプリケーションが Application-Level Protocol Negotiation (ALPN) を使用して HAProxy と HTTP/2 をネゴシエートすることをサポートしている場合、HAProxy からアプリケーション Pod への接続で HTTP/2 を使用できます。Ingress コントローラーで HTTP/2 が有効になっていない限り、再暗号化ルートで HTTP/2 を使用できません。
パススルールートの場合、アプリケーションが ALPN を使用してクライアントと HTTP/2 をネゴシエートすることをサポートしている場合、接続で HTTP/2 を使用できます。Ingress コントローラーが HTTP/2 を有効または無効にする場合、パススルールートで HTTP/2 を使用できます。
エッジ終端のセキュアなルートの場合、サービスが appProtocol: kubernetes.io/h2c のみを指定すると、接続では HTTP/2 が使用されます。Ingress コントローラーで HTTP/2 が有効または無効な場合、エッジ終端のセキュアなルートで HTTP/2 を使用できます。
安全でないルートの場合、サービスが appProtocol: kubernetes.io/h2c のみを指定すると、接続では HTTP/2 が使用されます。Ingress コントローラーで HTTP/2 が有効または無効になっている場合は、安全でないルートで HTTP/2 を使用できます。

重要

パススルー以外のルートの場合、Ingress Controller はクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。これは、クライアントが Ingress コントローラーに接続し、HTTP/1.1 をネゴシエートする可能性があることを意味します。その後、Ingress コントローラーはアプリケーションに接続し、HTTP/2 接続を確立し、HTTP/2 接続を使用してクライアント HTTP/1.1 接続からのリクエストをアプリケーションに転送します。

この一連のイベントは、その後クライアントが HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると、問題が発生します。WebSocket 接続の受け入れを目的としたアプリケーションがあり、そのアプリケーションが HTTP/2 プロトコルネゴシエーションを許可しようとすると、クライアントが WebSocket プロトコルへのアップグレードを試行しても失敗することに注意してください。

4.8.9.16.1. HTTP/2 の有効化

特定の Ingress Controller で HTTP/2 を有効化するか、クラスター全体で HTTP/2 を有効化できます。

手順

特定の Ingress Controller で HTTP/2 を有効化するには、oc annotate コマンドを入力します。

oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true 1

$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true 1

Copy to clipboard

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

ヒント

または、次の 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"

Copy to clipboard

4.8.9.16.2. HTTP/2 の無効化

特定の Ingress Controller で HTTP/2 を無効化するか、またはクラスター全体で HTTP/2 を無効化できます。

手順

特定の Ingress Controller で HTTP/2 を無効化するには、oc annotate コマンドを入力します。

oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false 1

$ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=false 1

Copy to clipboard

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

ヒント

または、次の 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"

Copy to clipboard

4.8.9.17. Ingress Controller の PROXY プロトコルの設定

クラスター管理者は、Ingress Controller が HostNetwork、NodePortService、または Private エンドポイント公開ストラテジータイプを使用する場合、PROXY プロトコルを設定できます。PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。

警告

Keepalived Ingress 仮想 IP (VIP) を使用するクラウド以外のプラットフォーム上の installer-provisioned クラスターを備えたデフォルトの Ingress Controller は、PROXY プロトコルをサポートしていません。

PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられる送信元 IP アドレスのみが含まれます。

重要

パススルールート設定の場合、OpenShift Container Platform クラスター内のサーバーは、元のクライアント送信元 IP アドレスを監視できません。元のクライアント送信元 IP アドレスを知る必要がある場合は、Ingress Controller の Ingress アクセスロギングを設定して、クライアント送信元 IP アドレスを表示できるようにします。

再暗号化およびエッジルートの場合、OpenShift Container Platform ルーターは Forwarded ヘッダーと X-Forwarded-For ヘッダーを設定し、アプリケーションワークロードがクライアントの送信元 IP アドレスをチェックできるようにします。

Ingress アクセスロギングの詳細は、「Ingress アクセスロギングの設定」を参照してください。

LoadBalancerService エンドポイント公開ストラテジータイプを使用する場合、Ingress Controller の PROXY プロトコルの設定はサポートされません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。

重要

PROXY プロトコルまたは TCP のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

この機能は、クラウドデプロイメントではサポートされていません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、Ingress Controller がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。

重要

PROXY プロトコルまたは Transmission Control Protocol (TCP) のいずれかを使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

前提条件

Ingress Controller を作成している。

手順

CLI で次のコマンドを入力して、Ingress Controller リソースを編集します。

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to clipboard

PROXY 設定を設定します。
- Ingress Controller が HostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.hostNetwork.protocol サブフィールドを PROXY に設定します。
  PROXY への hostNetwork の設定例
  # ... spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork # ...
  Copy to clipboard
- Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。
  PROXY へのサンプル nodePort 設定
  # ... spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService # ...
  Copy to clipboard
- Ingress Controller が Private エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.private.protocol サブフィールドを PROXY に設定します。
  PROXY への private 設定のサンプル
  # ... spec: endpointPublishingStrategy: private: protocol: PROXY type: Private # ...
  Copy to clipboard

関連情報

Ingress アクセスロギングの設定

4.8.9.18. appsDomain オプションを使用した代替クラスタードメインの指定

クラスター管理者は、appsDomain フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain フィールドは、domain フィールドで指定されているデフォルトの代わりに使用する OpenShift Container Platform のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。

たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。

前提条件

OpenShift Container Platform クラスターをデプロイしていること。
oc コマンドラインインターフェイスがインストールされている。

手順

ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。
1. Ingress cluster リソースを編集します。
```
oc edit ingresses.config/cluster -o yaml
```
```
$ oc edit ingresses.config/cluster -o yaml
```
  Copy to clipboardCopied
2. YAML ファイルを編集します。
  test.example.com への appsDomain の設定例
  apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com 1 appsDomain: <test.example.com> 2
  Copy to clipboard
  1
  デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。
  2
  オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。
注記
ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。
1. ルートを公開します。
```
oc expose service hello-openshift
```
```
$ oc expose service hello-openshift
route.route.openshift.io/hello-openshift exposed
```
  Copy to clipboardCopied
  出力例
  $ 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

4.8.9.19. HTTP ヘッダーケースの変換

HAProxy では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com は host: xyz.com に変更されます。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。

重要

OpenShift Container Platform には HAProxy 2.8 が含まれています。このバージョンの Web ベースのロードバランサーに更新する場合は、必ずクラスターの設定ファイルに spec.httpHeaders.headerNameCaseAdjustments セクションを追加してください。

クラスター管理者は、oc patch コマンドを入力するか、Ingress Controller YAML ファイルの HeaderNameCaseAdjustments フィールドを設定して HTTP ヘッダーのケースを変換できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

oc patch コマンドを使用して、HTTP ヘッダーを大文字にします。

次のコマンドを実行して、HTTP ヘッダーを host から Host に変更します。

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

Copy to clipboard

アノテーションをアプリケーションに適用できるように、Route リソースの YAML ファイルを作成します。

my-application という名前のルートの例

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true 1
  name: <application_name>
  namespace: <application_name>
# ...

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

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

次のルートの例では、haproxy.router.openshift.io/h1-adjust-case アノテーションを使用して HTTP レスポンスヘッダー名の大文字と小文字の調整を有効にします。

ルート YAML のサンプル

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true 1
  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

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

1: haproxy.router.openshift.io/h1-adjust-case を true に設定します。

4.8.9.20. ルーター圧縮の使用

特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes 変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または "X-" で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341 を参照してください。

注記

圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。

すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。

手順

Ingress Controller の httpCompression フィールドを設定します。

以下のコマンドを使用して IngressController リソースを編集します。

oc edit -n openshift-ingress-operator ingresscontrollers/default

$ oc edit -n openshift-ingress-operator ingresscontrollers/default

Copy to clipboard

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

4.8.9.21. ルーターメトリクスの公開

デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。

前提条件

ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。

手順

次のコマンドを実行して、ルーター Pod 名を取得します。

oc get pods -n openshift-ingress

$ oc get pods -n openshift-ingress

Copy to clipboard

出力例

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

ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。
1. 次のコマンドを実行して、ユーザー名を取得します。
```
oc rsh <router_pod_name> cat metrics-auth/statsUsername
```
```
$ oc rsh <router_pod_name> cat metrics-auth/statsUsername
```
  Copy to clipboardCopied
2. 次のコマンドを実行して、パスワードを取得します。
```
oc rsh <router_pod_name> cat metrics-auth/statsPassword
```
```
$ oc rsh <router_pod_name> cat metrics-auth/statsPassword
```
  Copy to clipboardCopied
次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。
```
oc describe pod <router_pod>
```
```
$ oc describe pod <router_pod>
```
Copy to clipboardCopied

つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。

curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

Copy to clipboard

次のコマンドを実行して、安全にメトリクスにアクセスします。

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

次のコマンドを実行して、デフォルトの 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

例4.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

ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。
```
http://<user>:<password>@<router_IP>:<stats_port>
```
```
http://<user>:<password>@<router_IP>:<stats_port>
```
Copy to clipboardCopied
オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。
```
http://<user>:<password>@<router_ip>:1936/metrics;csv
```
```
http://<user>:<password>@<router_ip>:1936/metrics;csv
```
Copy to clipboardCopied

4.8.9.22. HAProxy エラーコードの応答ページのカスタマイズ

クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。

カスタムエラーコードの応答ページは config map に指定し、Ingress Controller にパッチを適用されます。config map キーには、error-page-503.http と error-page-404.http の 2 つの利用可能なファイル名があります。

カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドラインに従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページの例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。

デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTP エラーコード応答をカスタマイズするための config map が提供されておらず、カスタム HTTP エラーコード応答ページを使用している場合、ルーターはデフォルトの 404 または 503 エラーコード応答ページを提供します。

注記

OpenShift Container Platform のデフォルトの 503 エラーコードページをカスタマイズのテンプレートとして使用する場合、ファイル内のヘッダーで CRLF 改行コードを使用できるエディターが必要になります。

手順

openshift-config に my-custom-error-code-pages という名前の config map を作成します。
```
oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
```
$ oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
Copy to clipboardCopied
重要
カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター 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 clipboardCopied
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

出力例

NAME                       DATA   AGE
default-errorpages         2      25s  1

NAME                       DATA   AGE
default-errorpages         2      25s  1

Copy to clipboard

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

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

検証

カスタムエラーコード HTTP 応答を確認します。

テストプロジェクトおよびアプリケーションを作成します。
```
oc new-project test-ingress
```
```
 $ oc new-project test-ingress
```
Copy to clipboardCopied
```
oc new-app django-psql-example
```
```
$ oc new-app django-psql-example
```
Copy to clipboardCopied
503 カスタム http エラーコード応答の場合:
1. アプリケーションのすべての Pod を停止します。
2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
```
curl -vk <route_hostname>
```
```
$ curl -vk <route_hostname>
```
  Copy to clipboardCopied
404 カスタム http エラーコード応答の場合:
1. 存在しないルートまたは正しくないルートにアクセスします。
2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
```
curl -vk <route_hostname>
```
```
$ curl -vk <route_hostname>
```
  Copy to clipboardCopied

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

4.8.9.23. Ingress Controller の最大接続数の設定

クラスター管理者は、OpenShift ルーターデプロイメントの同時接続の最大数を設定できます。既存の Ingress Controller にパッチを適用して、接続の最大数を増やすことができます。

前提条件

以下では、Ingress Controller が作成済みであることを前提とします。

手順

Ingress Controller を更新して、HAProxy の最大接続数を変更します。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
Copy to clipboardCopied
警告
spec.tuningOptions.maxConnections の値を現在のオペレーティングシステムの制限よりも大きく設定すると、HAProxy プロセスは開始しません。このパラメーターの詳細は、「Ingress Controller 設定パラメーター」セクションの表を参照してください。

4.8.10. 関連情報

カスタム PKI の設定

4.9. OpenShift Container Platform の Ingress Node Firewall Operator

Ingress Node Firewall Operator は、OpenShift Container Platform でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。

4.9.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator は、ファイアウォール設定で指定および管理するノードにデーモンセットをデプロイすることにより、ノードレベルで Ingress ファイアウォールルールを提供します。デーモンセットをデプロイするには、IngressNodeFirewallConfig カスタムリソース (CR) を作成します。Operator は IngressNodeFirewallConfig CR を適用して、nodeSelector に一致するすべてのノードで実行される ingress ノードファイアウォールデーモンセット (daemon) を作成します。

IngressNodeFirewall CR の rule を設定し、nodeSelector を使用して値を "true" に設定してクラスターに適用します。

重要

Ingress Node Firewall Operator は、ステートレスファイアウォールルールのみをサポートします。

ネイティブ XDP ドライバーをサポートしないネットワークインターフェイスコントローラー (NIC) は、より低いパフォーマンスで実行されます。

OpenShift Container Platform 4.14 以降の場合は、RHEL 9.0 以降で Ingress Node Firewall Operator を実行する必要があります。

4.9.2. Ingress Node Firewall Operator のインストール

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

4.9.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

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

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

Operator がインストールされていることを確認するには、以下のコマンドを入力します。

oc get ip -n openshift-ingress-node-firewall

$ oc get ip -n openshift-ingress-node-firewall

Copy to clipboard

出力例

NAME            CSV                                         APPROVAL    APPROVED
install-5cvnz   ingress-node-firewall.4.18.0-202211122336   Automatic   true

NAME            CSV                                         APPROVAL    APPROVED
install-5cvnz   ingress-node-firewall.4.18.0-202211122336   Automatic   true

Copy to clipboard

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

oc get csv -n openshift-ingress-node-firewall

$ oc get csv -n openshift-ingress-node-firewall

Copy to clipboard

出力例

NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
ingress-node-firewall.4.18.0-202211122336   Ingress Node Firewall Operator   4.18.0-202211122336   ingress-node-firewall.4.18.0-202211102047   Succeeded

NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
ingress-node-firewall.4.18.0-202211122336   Ingress Node Firewall Operator   4.18.0-202211122336   ingress-node-firewall.4.18.0-202211102047   Succeeded

Copy to clipboard

4.9.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール

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

前提条件

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

手順

Ingress Node Firewall Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
4. Install をクリックします。
Ingress Node Firewall Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに移動します。
2. 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
    Copy to clipboard
    注記
    単一ノードの OpenShift クラスターの場合、openshift-ingress-node-firewall namespace には workload.openshift.io/allowed=management アノテーションが必要です。

4.9.3. Ingress Node Firewall Operator のデプロイ

前提条件

Ingress Node Firewall Operator がインストールされます。

手順

Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。

ingressnodefirewallconfig という名前の openshift-ingress-node-firewall namespace 内に IngressNodeFirewallConfig を作成します。
次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。
```
oc apply -f rule.yaml
```
```
$ oc apply -f rule.yaml
```
Copy to clipboardCopied

4.9.3.1. Ingress ノードファイアウォール設定オブジェクト

Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。

表4.13 Ingress ノードファイアウォール設定オブジェクト
フィールド	型	説明
`metadata.name`	`string`	CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は `ingressnodefirewallconfig` である必要があります。
`metadata.namespace`	`string`	Ingress Firewall Operator CR オブジェクトの namespace。`IngressNodeFirewallConfig` CR は、`openshift-ingress-node-firewall` namespace 内に作成する必要があります。
`spec.nodeSelector`	`string`	指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。 `spec: nodeSelector: node-role.kubernetes.io/worker: ""` Copy to clipboard 注記デーモンセットを開始するには、`nodeSelector` で使用される 1 つのラベルがノードのラベルと一致する必要があります。たとえば、ノードラベル `node-role.kubernetes.io/worker` および `node-type.kubernetes.io/vm` がノードに適用される場合、デーモンセットを開始するには、`nodeSelector` を使用して少なくとも 1 つのラベルを設定する必要があります。
`spec.ebpfProgramManagerMode`	`boolean`	Node Ingress Firewall Operator が eBPF プログラムを管理するために eBPF Manager Operator を使用するかどうかを指定します。この機能はテクノロジープレビュー機能です。 Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

注記

Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。

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: ""

Copy to clipboard

注記

Operator は CR を使用し、nodeSelector に一致するすべてのノード上に Ingress ノードファイアウォールデーモンセットを作成します。

4.9.3.2. Ingress ノードファイアウォールルールオブジェクト

Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。

表4.14 Ingress ノードファイアウォールルールオブジェクト
フィールド	型	説明
`metadata.name`	`string`	CR オブジェクトの名前。
`interfaces`	`array`	このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、`-en0` と `-en1` です。
`nodeSelector`	`array`	`nodeSelector` を使用して、ファイアウォールルールを適用するノードを選択できます。名前付き `nodeselector` ラベルの値を `true` に設定して、ルールを適用します。
`ingress`	`object`	`ingress` を使用すると、クラスター上のサービスへの外部アクセスを許可するルールを設定できます。

Ingress オブジェクトの設定

ingress オブジェクトの値は、次の表で定義されています。

表4.15 ingress オブジェクト
フィールド	型	説明
`sourceCIDRs`	`array`	CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。注記異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の `IngressNodeFirewall` オブジェクトがある場合、`order` フィールドは最初に適用されるルールを指定します。ルールは昇順で適用されます。
`rules`	`array`	Ingress ファイアウォール `rules.order` オブジェクトは、`source.CIDR` ごとに `1` から順に並べられ、CIDR ごとに最大 100 のルールがあります。低次ルールが最初に実行されます。 `rules.protocolConfig.protocol` は次のプロトコルをサポートします: TCP、UDP、SCTP、ICMP、および ICMPv6。ICMP および ICMPv6 ルールは、ICMP および ICMPv6 のタイプまたはコードと照合できます。TCP、UDP、および SCTP ルールは、`<start : end-1>` 形式を使用して、単一の宛先ポートまたはポートの範囲に対して照合できます。 `rules.action` を設定してルールの適用を `allow` するか、`deny` してルールを禁止します。注記 Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。

Ingress ノードファイアウォールルールオブジェクトの例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォールの設定例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 1
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 1
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny

Copy to clipboard

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 1
 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 2
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 3
   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 4

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 1
 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 2
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 3
   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 4

Copy to clipboard

1: ネットワークインターフェイスクラスター
2: <label_name> と <label_value> は、ingressfirewallconfig CR を適用する特定のノードに適用される nodeSelector ラベルと値に一致する必要があります。
3: 0.0.0.0/0 は、任意の CIDR に一致するように設定されています
4: Deny に設定された action

重要

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

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

4.9.4. Ingress ノードファイアウォール Operator の統合

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。代わりに、これらのプログラムのロードと管理に eBPF Manager Operator を使用するように Ingress Node Firewall Operator を設定できます。

この統合を有効にすると、次の制限が適用されます。

XDP が利用できず、TCX が bpfman と互換性がない場合、Ingress Node Firewall Operator は TCX を使用します。
Ingress Node Firewall Operator デーモンセットの Pod は、ファイアウォールルールが適用されるまで ContainerCreating 状態のままになります。
Ingress Node Firewall Operator デーモンセットの Pod は特権として実行します。

4.9.5. eBPF Manager Operator を使用するように Ingress ノードファイアウォール Operator の設定

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。

クラスター管理者は、Ingress Node Firewall Operator を設定して、代わりに eBPF Manager Operator を使用してこれらのプログラムをロードおよび管理し、セキュリティーと監視機能を追加できます。

前提条件

OpenShift CLI (oc) がインストールされている。
管理者権限を持つアカウントを持っています。
Ingress Node Firewall Operator をインストールしました。
eBPF Manager Operator をインストールしている。

手順

Ingress-node-firewall-system namespace に次のラベルを適用します。

oc label namespace openshift-ingress-node-firewall \
    pod-security.kubernetes.io/enforce=privileged \
    pod-security.kubernetes.io/warn=privileged --overwrite

$ oc label namespace openshift-ingress-node-firewall \
    pod-security.kubernetes.io/enforce=privileged \
    pod-security.kubernetes.io/warn=privileged --overwrite

Copy to clipboard

ingressnodefirewallconfig という名前の IngressNodeFirewallConfig オブジェクトを編集し、ebpfProgramManagerMode フィールドを設定します。
Ingress Node Firewall Operator 設定オブジェクト
```
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  ebpfProgramManagerMode: <ebpf_mode>
```
```
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  ebpfProgramManagerMode: <ebpf_mode>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<ebpf_mode>: Ingress Node Firewall Operator が eBPF Manager Operator を使用して eBPF プログラムを管理するかどうかを指定します。true または false のどちらかでなければなりません。設定されていないと、eBPF マネージャーは使用されません。

4.9.6. Ingress Node Firewall Operator ルールの表示

手順

次のコマンドを実行して、現在のルールをすべて表示します。
```
oc get ingressnodefirewall
```
```
$ oc get ingressnodefirewall
```
Copy to clipboardCopied
返された <resource> 名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。
```
oc get <resource> <name> -o yaml
```
```
$ oc get <resource> <name> -o yaml
```
Copy to clipboardCopied

4.9.7. Ingress Node Firewall Operator のトラブルシューティング

次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。

oc get crds | grep ingressnodefirewall

$ oc get crds | grep ingressnodefirewall

Copy to clipboard

出力例

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

次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。

oc get pods -n openshift-ingress-node-firewall

$ oc get pods -n openshift-ingress-node-firewall

Copy to clipboard

出力例

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

次のフィールドは、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 clipboardCopied
ログは、/sos_commands/ebpf にある eBPF bpftool 出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。

4.9.8. 関連情報

eBPF Manager Operator について

4.10. SR-IOV Operator

4.10.1. SR-IOV Network Operator のインストール

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。

4.10.1.1. SR-IOV Network Operator のインストール

クラスター管理者は、OpenShift Container Platform CLI または Web コンソールを使用して、Single Root I/O Virtualization (SR-IOV) Network Operator をインストールできます。

4.10.1.1.1. CLI: SR-IOV Network Operator のインストール

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

前提条件

SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つアカウント。

手順

次のコマンドを入力して、openshift-sriov-network-operator namespace を作成します。

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

Copy to clipboard

次のコマンドを入力して、OperatorGroup カスタムリソース (CR) を作成します。

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

Copy to clipboard

次のコマンドを入力して、SR-IOV Network Operator の Subscription CR を作成します。

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: stable
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

$ cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: stable
  name: sriov-network-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

Copy to clipboard

次のコマンドを入力して、SriovoperatorConfig リソースを作成します。

cat <<EOF | oc create -f -
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 2
  disableDrain: false
EOF

$ cat <<EOF | oc create -f -
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 2
  disableDrain: false
EOF

Copy to clipboard

検証

次のコマンドを入力して、Operator がインストールされていることを確認します。

oc get csv -n openshift-sriov-network-operator \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

$ oc get csv -n openshift-sriov-network-operator \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase

Copy to clipboard

出力例

Name                                         Phase
sriov-network-operator.4.18.0-202406131906   Succeeded

Name                                         Phase
sriov-network-operator.4.18.0-202406131906   Succeeded

Copy to clipboard

4.10.1.1.2. Web コンソール: SR-IOV Network Operator のインストール

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

前提条件

SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つアカウント。

手順

SR-IOV Network Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
4. Install をクリックします。
SR-IOV Network Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに移動します。
2. Status が InstallSucceeded の状態で、SR-IOV Network Operator が openshift-sriov-network-operator プロジェクトにリスト表示されていることを確認します。
  注記
  インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
  Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
  - Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
  - Workloads → Pods ページに移動し、openshift-sriov-network-operator プロジェクトで Pod のログを確認します。
  - YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション workload.openshift.io/allowed=management を Operator namespace に追加できます。
    $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
    Copy to clipboard
    注記
    シングルノード OpenShift クラスターの場合は、namespace にアノテーション workload.openshift.io/allowed=management が必要です。

4.10.1.2. 次のステップ

SR-IOV Network Operator の設定

4.10.2. SR-IOV Network Operator の設定

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。

4.10.2.1. SR-IOV Network Operator の設定

すべての SR-IOV Operator コンポーネントをデプロイするには、SriovOperatorConfig カスタムリソース (CR) を作成します。
1. 次の YAML を使用して、sriovOperatorConfig.yaml という名前のファイルを作成します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default 1
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: false
  enableInjector: true 2
  enableOperatorWebhook: true 3
  logLevel: 2
  featureGates:
    metricsExporter: false
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default 1
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: false
  enableInjector: true 2
  enableOperatorWebhook: true 3
  logLevel: 2
  featureGates:
    metricsExporter: false
```
  Copy to clipboardCopied
  1
  SriovOperatorConfig リソースの有効な名前は default のみであり、Operator がデプロイされている namespace 内にある必要があります。
  2
  enableInjector フィールドは、CR で指定されていないか、明示的に true に設定されていない場合、デフォルトで false または <none> に設定されます。その場合、namespace で network-resources-injector Pod が実行されなくなります。推奨設定は true です。
  3
  enableOperatorWebhook フィールドは、CR で指定されていないか、明示的に true に設定されていない場合、デフォルトで false または <none> に設定されます。その場合、namespace で operator-webhook Pod が実行されなくなります。推奨設定は true です。
2. 次のコマンドを実行して、リソースを作成します。
```
oc apply -f sriovOperatorConfig.yaml
```
```
$ oc apply -f sriovOperatorConfig.yaml
```
  Copy to clipboardCopied

4.10.2.1.1. SR-IOV Network Operator config カスタムリソース

sriovoperatorconfig カスタムリソースのフィールドは、以下の表で説明されています。

表4.16 SR-IOV Network Operator config カスタムリソース
フィールド	型	説明
`metadata.name`	`string`	SR-IOV Network Operator インスタンスの名前を指定します。デフォルト値は `default` です。別の値を設定しないでください。
`metadata.namespace`	`string`	SR-IOV Network Operator インスタンスの namespace を指定します。デフォルト値は `openshift-sriov-network-operator` です。別の値を設定しないでください。
`spec.configDaemonNodeSelector`	`string`	選択されたノードで SR-IOV Network Config Daemon のスケジューリングを制御するノードの選択オプションを指定します。デフォルトでは、このフィールドは設定されておらず、Operator はワーカーノードに SR-IOV Network Config デーモンセットを配置します。
`spec.disableDrain`	`boolean`	新しいポリシーを適用してノードに NIC を設定する時に、ノードドレインプロセスを無効にするか、有効にするかを指定します。このフィールドを `true` に設定すると、ソフトウェアの開発や OpenShift Container Platform の単一ノードへのインストールが容易になります。デフォルトでは、このフィールドは設定されていません。シングルノードクラスターの場合は、Operator のインストール後にこのフィールドを `true` に設定します。このフィールドは必ず `true` に設定してください。
`spec.enableInjector`	`boolean`	Network Resources Injector デーモンセットを有効にするか無効にするかを指定します。
`spec.enableOperatorWebhook`	`boolean`	Operator Admission Controller の Webhook デーモンセットを有効にするか無効にするかを指定します。
`spec.logLevel`	`integer`	Operator のログの詳細レベルを指定します。デフォルトでは、このフィールドは `0` に設定されており、基本的なログのみが表示されます。`2` に設定すると、利用可能なすべてのログが表示されます。
`spec.featureGates`	`map[string]bool`	任意の機能を有効にするか無効にするかを指定します。たとえば、`metricsExporter` です。
`spec.featureGates.metricsExporter`	`boolean`	SR-IOV Network Operator メトリクスを有効にするか無効にするかを指定します。デフォルトでは、このフィールドは `false` に設定されています。
`spec.featureGates.mellanoxFirmwareReset`	`boolean`	SR-IOV Network Operator の Virtual Function (VF) の変更時にファームウェアをリセットするかどうかを指定します。Intel C740 シリーズなどの一部のチップセットでは、NVIDIA/Mellanox NIC で VF を設定するために必要な PCI-E デバイスの電源が完全にオフになりません。デフォルトでは、このフィールドは `false` に設定されています。重要 `spec.featureGates.mellanoxFirmwareReset` パラメーターは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。 Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

4.10.2.1.2. Network Resources Injector について

Network Resources Injector は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。

SR-IOV リソース名を SR-IOV ネットワーク割り当て定義アノテーションに従って追加するための、Pod 仕様でのリソース要求および制限の変更。
Pod のアノテーション、ラベル、および huge page の要求および制限を公開するための Downward API ボリュームでの Pod 仕様の変更。Pod で実行されるコンテナーは、公開される情報に /etc/podnetinfo パスでファイルとしてアクセスできます。

Network Resources Injector は、SriovOperatorConfig CR で enableInjector が true に設定されている場合、SR-IOV Network Operator によって有効になります。network-resources-injector Pod は、すべてのコントロールプレーンノード上でデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Network Resources Injector Pod の例です。

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to clipboard

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

Copy to clipboard

4.10.2.1.3. Network Resources Injector の無効化または有効化

Network Resources Injector を無効または有効にするには、次の手順を実行します。

前提条件

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

手順

enableInjector フィールドを設定します。<value> を false に置き換えて機能を無効にするか、true に置き換えて機能を有効にします。

oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

$ oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

Copy to clipboard

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

Copy to clipboard

4.10.2.1.4. SR-IOV Network Operator Admission Controller Webhook について

SR-IOV Network Operator Admission Controller Webbook は Kubernetes Dynamic Admission Controller アプリケーションです。これは、以下の機能を提供します。

作成時または更新時の SriovNetworkNodePolicy CR の検証
CR の作成または更新時の priority および deviceType フィールドのデフォルト値の設定による SriovNetworkNodePolicy CR の変更

SR-IOV Network Operator Admission Controller Webhook は、SriovOperatorConfig CR で enableOperatorWebhook が true に設定されている場合、Operator によって有効になります。operator-webhook Pod は、すべてのコントロールプレーンノード上でデーモンセットとして実行されます。

注記

SR-IOV Network Operator Admission Controller Webhook を無効にする場合は注意してください。トラブルシューティングなどの特定の状況下や、サポートされていないデバイスを使用する場合は、Webhook を無効にすることができます。サポート対象外のデバイスの設定は、サポート対象外の NIC を使用するための SR-IOV Network Operator の設定を参照してください。

以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to clipboard

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

Copy to clipboard

4.10.2.1.5. SR-IOV Network Operator Admission Controller Webhook の無効化または有効化

Admission Controller Webhook を無効または有効にするには、次の手順を実行します。

前提条件

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

手順

enableOperatorWebhook フィールドを設定します。<value> を false に置き換えて機能を無効するか、true に置き換えて機能を有効にします。

oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

Copy to clipboard

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

Copy to clipboard

4.10.2.1.6. カスタムノードセレクターについて

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

4.10.2.1.7. SR-IOV Network Config Daemon のカスタム NodeSelector の設定

SR-IOV Network Config デーモンがデプロイされるノードを指定するには、以下の手順を実行します。

重要

configDaemonNodeSelector フィールドを更新する際に、SR-IOV Network Config デーモンがそれぞれの選択されたノードに再作成されます。デーモンが再作成されている間、クラスターのユーザーは新規の SR-IOV Network ノードポリシーを適用したり、新規の SR-IOV Pod を作成したりできません。

手順

Operator のノードセレクターを更新するには、以下のコマンドを入力します。

oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{

$ oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

Copy to clipboard

以下の例のように、<node_label> を適用するラベルに置き換えます: "node-role.kubernetes.io/worker": ""

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

Copy to clipboard

4.10.2.1.8. 単一ノードのインストール用の SR-IOV Network Operator の設定

デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、このアクションを実行して、再設定する前に Virtual Function を使用しているワークロードがないことを確認します。

1 つのノードにインストールする場合には、ワークロードを受信するノードは他にありません。そのため、Operator は、単一のノードからワークロードがドレインされないように設定する必要があります。

重要

以下の手順を実行してワークロードのドレインを無効にした後に、SR-IOV ネットワークインターフェイスを使用しているワークロードを削除してから SR-IOV ネットワークノードのポリシーを変更する必要があります。

前提条件

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

手順

disableDrain フィールドを true に設定し、configDaemonNodeSelector フィールドを node-role.kubernetes.io/master: "" に設定するには、以下のコマンドを入力します。

oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'

$ oc patch sriovoperatorconfig default --type=merge -n openshift-sriov-network-operator --patch '{ "spec": { "disableDrain": true, "configDaemonNodeSelector": { "node-role.kubernetes.io/master": "" } } }'

Copy to clipboard

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true
  configDaemonNodeSelector:
   node-role.kubernetes.io/master: ""

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true
  configDaemonNodeSelector:
   node-role.kubernetes.io/master: ""

Copy to clipboard

4.10.2.1.9. Hosted Control Plane 用の SR-IOV Operator のデプロイ

ホスティングサービスクラスターを設定してデプロイすると、ホストされたクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。

前提条件

AWS 上でホストされたクラスターを設定およびデプロイしている。

手順

namespace と Operator グループを作成します。

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator

Copy to clipboard

SR-IOV Operator へのサブスクリプションを作成します。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subsription
  namespace: openshift-sriov-network-operator
spec:
  channel: stable
  name: sriov-network-operator
  config:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
  source: redhat-operators
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subsription
  namespace: openshift-sriov-network-operator
spec:
  channel: stable
  name: sriov-network-operator
  config:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Copy to clipboard

検証

SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。

oc get csv -n openshift-sriov-network-operator

$ oc get csv -n openshift-sriov-network-operator

Copy to clipboard

出力例

NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
sriov-network-operator.4.18.0-202211021237   SR-IOV Network Operator   4.18.0-202211021237   sriov-network-operator.4.18.0-202210290517   Succeeded

NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
sriov-network-operator.4.18.0-202211021237   SR-IOV Network Operator   4.18.0-202211021237   sriov-network-operator.4.18.0-202210290517   Succeeded

Copy to clipboard

SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。
```
oc get pods -n openshift-sriov-network-operator
```
```
$ oc get pods -n openshift-sriov-network-operator
```
Copy to clipboardCopied

4.10.2.2. SR-IOV ネットワークメトリクスエクスポーターについて

Single Root I/O Virtualization (SR-IOV) ネットワークメトリクスエクスポーターは、SR-IOV Virtual Function (VF) のメトリクスを読み取り、これらの VF メトリクスを Prometheus 形式で公開します。SR-IOV ネットワークメトリクスエクスポーターが有効になっている場合は、OpenShift Container Platform Web コンソールを使用して SR-IOV VF メトリクスをクエリーし、SR-IOV Pod のネットワークアクティビティーを監視できます。

Web コンソールを使用して SR-IOV VF メトリクスをクエリーすると、SR-IOV ネットワークメトリクスエクスポーターは、VF が接続されている Pod の名前と namespace とともに、VF ネットワーク統計を取得して返します。

次の表は、メトリクスエクスポーターが Prometheus 形式で読み取り、公開する SR-IOV VF メトリクスを説明します。

表4.17 SR-IOV VF メトリクス
メトリクス	説明	VF メトリクスを調べるための PromQL クエリーの例
`sriov_vf_rx_bytes`	Virtual Function ごとに受信したバイト数。	`sriov_vf_rx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_tx_bytes`	Virtual Function ごとに送信されたバイト数。	`sriov_vf_tx_bytes * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_rx_packets`	Virtual Function ごとの受信パケット数。	`sriov_vf_rx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_tx_packets`	Virtual Function あたりの送信パケット数。	`sriov_vf_tx_packets * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_rx_dropped`	Virtual Function ごとに受信時にドロップされたパケット。	`sriov_vf_rx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_tx_dropped`	Virtual Function ごとに送信中にドロップされたパケット。	`sriov_vf_tx_dropped * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_rx_multicast`	Virtual Function ごとに受信したマルチキャストパケット。	`sriov_vf_rx_multicast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_vf_rx_broadcast`	Virtual Function ごとに受信したブロードキャストパケット。	`sriov_vf_rx_broadcast * on (pciAddr,node) group_left(pod,namespace,dev_type) sriov_kubepoddevice`
`sriov_kubepoddevice`	アクティブな Pod にリンクされた Virtual Function。	-

これらのクエリーを kube-state-metrics と組み合わせて、SR-IOV Pod に関する詳細情報を取得することもできます。たとえば、次のクエリーを使用して、標準の Kubernetes Pod ラベルからアプリケーション名とともに VF ネットワーク統計を取得できます。

(sriov_vf_tx_packets * on (pciAddr,node)  group_left(pod,namespace)  sriov_kubepoddevice) * on (pod,namespace) group_left (label_app_kubernetes_io_name) kube_pod_labels

(sriov_vf_tx_packets * on (pciAddr,node)  group_left(pod,namespace)  sriov_kubepoddevice) * on (pod,namespace) group_left (label_app_kubernetes_io_name) kube_pod_labels

Copy to clipboard

4.10.2.2.1. SR-IOV ネットワークメトリクスエクスポーターを有効にする

Single Root I/O Virtualization (SR-IOV) ネットワークメトリクスエクスポーターは、デフォルトでは無効になっています。メトリクスエクスポーターを有効にするには、spec.featureGates.metricsExporter フィールドを true に設定する必要があります。

重要

メトリクスエクスポーターが有効になっていると、SR-IOV Network Operator は SR-IOV 機能を持つノードにのみメトリクスエクスポーターをデプロイします。

前提条件

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

手順

次のコマンドを実行して、クラスター監視を有効にします。
```
oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
```
```
$ oc label ns/openshift-sriov-network-operator openshift.io/cluster-monitoring=true
```
Copy to clipboardCopied
クラスター監視を有効にするには、SR-IOV Network Operator をインストールした namespace に openshift.io/cluster-monitoring=true ラベルを追加する必要があります。

次のコマンドを実行して、spec.featureGates.metricsExporter フィールドを true に設定します。

oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \
    --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'

$ oc patch -n openshift-sriov-network-operator sriovoperatorconfig/default \
    --type='merge' -p='{"spec": {"featureGates": {"metricsExporter": true}}}'

Copy to clipboard

検証

次のコマンドを実行して、SR-IOV ネットワークメトリクスエクスポーターが有効になっていることを確認します。

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to clipboard

出力例

NAME                                     READY   STATUS    RESTARTS   AGE
operator-webhook-hzfg4                   1/1     Running   0          5d22h
sriov-network-config-daemon-tr54m        1/1     Running   0          5d22h
sriov-network-metrics-exporter-z5d7t     1/1     Running   0          10s
sriov-network-operator-cc6fd88bc-9bsmt   1/1     Running   0          5d22h

NAME                                     READY   STATUS    RESTARTS   AGE
operator-webhook-hzfg4                   1/1     Running   0          5d22h
sriov-network-config-daemon-tr54m        1/1     Running   0          5d22h
sriov-network-metrics-exporter-z5d7t     1/1     Running   0          10s
sriov-network-operator-cc6fd88bc-9bsmt   1/1     Running   0          5d22h

Copy to clipboard

sriov-network-metrics-exporter Pod は READY 状態である必要があります。

オプション: OpenShift Container Platform Web コンソールを使用して、SR-IOV Virtual Function (VF) メトリクスを調べます。詳細は、「メトリクスのクエリー」を参照してください。

関連情報

4.10.3. SR-IOV Network Operator のアンインストール

SR-IOV Network Operator をアンインストールするには、実行中の SR-IOV ワークロードをすべて削除し、Operator をアンインストールして、Operator が使用した Webhook を削除する必要があります。

4.10.3.1. SR-IOV Network Operator のアンインストール

クラスター管理者は、SR-IOV Network Operator をアンインストールできます。

前提条件

cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
SR-IOV Network Operator がインストールされている。

手順

すべての SR-IOV カスタムリソース (CR) を削除します。

oc delete sriovnetwork -n openshift-sriov-network-operator --all

$ oc delete sriovnetwork -n openshift-sriov-network-operator --all

Copy to clipboard

oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all

$ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all

Copy to clipboard

oc delete sriovibnetwork -n openshift-sriov-network-operator --all

$ oc delete sriovibnetwork -n openshift-sriov-network-operator --all

Copy to clipboard

oc delete sriovoperatorconfigs -n openshift-sriov-network-operator --all

$ oc delete sriovoperatorconfigs -n openshift-sriov-network-operator --all

Copy to clipboard

「クラスターからの Operator の削除」セクションに記載された手順に従い、クラスターから SR-IOV Network Operator を削除します。

SR-IOV Network Operator のアンインストール後にクラスターに残っている SR-IOV カスタムリソース定義を削除します。

oc delete crd sriovibnetworks.sriovnetwork.openshift.io

$ oc delete crd sriovibnetworks.sriovnetwork.openshift.io

Copy to clipboard

oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io

$ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io

Copy to clipboard

oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io

$ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io

Copy to clipboard

oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io

$ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io

Copy to clipboard

oc delete crd sriovnetworks.sriovnetwork.openshift.io

$ oc delete crd sriovnetworks.sriovnetwork.openshift.io

Copy to clipboard

oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io

$ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io

Copy to clipboard

SR-IOV Network Operator の namespace を削除します。

oc delete namespace openshift-sriov-network-operator

$ oc delete namespace openshift-sriov-network-operator

Copy to clipboard

関連情報

クラスターからの Operator の削除

第5章ネットワークセキュリティー

5.1. ネットワークポリシー API について

Kubernetes は、ネットワークセキュリティーの強化に使用できる 2 つの機能を提供します。機能の 1 つは、ユーザーによるネットワークポリシーの適用を可能にする NetworkPolicy API です。これは主にアプリケーション開発者と namespace テナント向けの機能で、namespace スコープのポリシーを作成して namespace を保護することを目的としています。

2 番目の機能は AdminNetworkPolicy で、AdminNetworkPolicy (ANP) API と BaselineAdminNetworkPolicy (BANP) API の 2 つの API で構成されています。ANP と BANP は、クラスターおよびネットワーク管理者向けの機能で、クラスタースコープのポリシーを作成してクラスター全体を保護することを目的としています。クラスター管理者は、ANP を使用すると、NetworkPolicy オブジェクトよりも優先されるオーバーライド不可能なポリシーを適用できます。BANP を使用すると、NetworkPolicy オブジェクトを使用して必要に応じてユーザーがオーバーライドできるオプションのクラスタースコープのネットワークポリシールールをセットアップおよび適用できます。ANP、BANP、およびネットワークポリシーを一緒に使用すると、管理者がクラスターのセキュリティー保護に使用できる完全なマルチテナント分離を実現できます。

OpenShift Container Platform の OVN-Kubernetes CNI は、アクセス制御リスト (ACL) の階層を使用してこれらのネットワークポリシーを実装し、それらを評価して適用します。ACL は、階層 1 から階層 3 まで降順で評価されます。

階層 1 では AdminNetworkPolicy (ANP) オブジェクトを評価します。階層 2 では NetworkPolicy オブジェクトを評価します。階層 3 では BaselineAdminNetworkPolicy (BANP) オブジェクトを評価します。

最初に ANP が評価されます。一致が ANP allow または deny ルールである場合、クラスター内の既存の NetworkPolicy および BaselineAdminNetworkPolicy (BANP) オブジェクトは評価からスキップされます。一致が ANP の pass ルールの場合、評価が ACL 階層 1 から階層 2 に進み、そこで NetworkPolicy ポリシーが評価されます。トラフィックに一致する NetworkPolicy がない場合、評価は Tier 2 ACL から Tier 3 ACL に移動し、そこで BANP が評価されます。

5.1.1. AdminNetworkPolicy と NetworkPolicy カスタムリソースの主な違い

次の表は、クラスタースコープの AdminNetworkPolicy API と namespace スコープの NetworkPolicy API の主な違いを説明しています。

ポリシーの要素	AdminNetworkPolicy	NetworkPolicy
対象ユーザー	クラスター管理者または同等の権限	namespace の所有者
スコープ	クラスター	namespace
トラフィックのドロップ	明示的な `Deny` アクションをルールとして設定することでサポートされます。	ポリシー作成時に暗黙的に `Deny` 分離することでサポートされます。
トラフィックの委譲	`Pass` アクションをルールとして設定することでサポートされます。	該当なし
トラフィックの許可	明示的に `Allow` アクションをルールとして設定することでサポートされます。	すべてのルールに対するデフォルトのアクションは allow です。
ポリシー内のルールの優先順位	ANP 内で表示される順序によって異なります。ルールの位置が高いほど、優先順位が高くなります。	ルールは追加できます。
ポリシーの優先順位	ANP 間では、`priority` フィールドによって評価の順序が設定されます。優先順位の数字が低いほど、ポリシーの優先順位が高くなります。	ポリシー間にポリシー順序はありません。
機能の優先順位	最初に Tier 1 ACL を介して評価され、最後に BANP が Tier 3 ACL を介して評価されます。	ANP の後、BANP の前に適用され、ACL の Tier 2 で評価されます。
Pod 選択の一致	namespace 間で異なるルールを適用できます。	1 つの namespace 内の Pod に異なるルールを適用できます。
クラスターの Egress トラフィック	`nodes` と `networks` ピアを介してサポートされます。	受け入れられた CIDR 構文とともに `ipBlock` フィールドを使用してサポートされます。
クラスター Ingress トラフィック	サポート対象外	サポート対象外
完全修飾ドメイン名 (FQDN) ピアサポート	サポート対象外	サポート対象外
namespace セレクター	`namespaces.matchLabels` フィールドを使用した namespace の高度な選択をサポートします	`namespaceSelector` フィールドを使用したラベルベースでの namespace の選択をサポートします

5.2. 管理ネットワークポリシー

5.2.1. OVN-Kubernetes AdminNetworkPolicy

5.2.1.1. AdminNetworkPolicy

AdminNetworkPolicy (ANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、namespace を作成する前にネットワークポリシーを作成することで、ANP を使用してネットワークを保護できます。さらに、NetworkPolicy オブジェクトによってオーバーライドできないネットワークポリシーをクラスタースコープのレベルで作成できます。

AdminNetworkPolicy オブジェクトと NetworkPolicy オブジェクトの主な違いは、前者は管理者用でクラスタースコープであるのに対し、後者はテナント所有者用で namespace スコープであることです。

ANP を使用すると、管理者は以下を指定できます。

評価の順序を決定する priority 値。値が小さいほど優先度が高くなります。
ポリシーが適用される namespace のセットまたは namespace で構成される Pod のセット。
subject へのすべての Ingress トラフィックに適用される Ingress ルールのリスト。
subject からのすべての Egress トラフィックに適用される Egress ルールのリスト。

AdminNetworkPolicy の例

例5.1 ANP の YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: sample-anp-deny-pass-rules 1
spec:
  priority: 50 2
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name 3
  ingress: 4
  - name: "deny-all-ingress-tenant-1" 5
    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1 6
  egress:7
  - name: "pass-all-egress-to-tenant-1"
    action: "Pass"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: sample-anp-deny-pass-rules 1
spec:
  priority: 50 2
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name 3
  ingress: 4
  - name: "deny-all-ingress-tenant-1" 5
    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1 6
  egress:7
  - name: "pass-all-egress-to-tenant-1"
    action: "Pass"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1

Copy to clipboard

1: ANP の名前を指定します。
2: spec.priority フィールドは、0 - 99 の値を受け入れ、クラスター内で最大 100 個の ANP をサポートします。範囲は最低値から最高値の順に読み取られるため、値が低いほど優先度が高くなります。同じ優先度で ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が意図したものになるように、異なる優先度で ANP を設定してください。
3: ANP リソースを適用する namespace を指定します。
4: ANP には Ingress ルールと Egress ルールの両方があります。spec.ingress フィールドの ANP ルールは、action フィールドの Pass、Deny、および Allow の値を受け入れます。
5: ingress.name の名前を指定します。
6: namespaceSelector.matchLabels によって選択された namespace 内の Pod を Ingress ピアとして選択するには、podSelector.matchLabels を指定します。
7: ANP には、Ingress と Egress ルールの両方があります。spec.egress フィールドの ANP ルールは、action フィールドの Pass、Deny、および Allow の値を受け入れます。

関連情報

Network Policy API Working Group

5.2.1.1.1. ルールの AdminNetworkPolicy アクション

管理者は、AdminNetworkPolicy ルールの action フィールドに Allow、Deny、または Pass を設定できます。OVN-Kubernetes は階層型 ACL を使用してネットワークトラフィックルールを評価するため、ANP を使用すると、非常に強力なポリシールールを設定できます。このポリシールールを変更するには、管理者がルールを変更、削除するか、より高い優先度のルールを設定してオーバーライドする必要があります。

AdminNetworkPolicy の Allow の例

優先度 9 で定義されている次の ANP は、monitoring namespace からクラスター内の任意のテナント (他のすべての namespace) への Ingress トラフィックをすべて許可します。

例5.2 強力な Allow ANP の YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: allow-monitoring
spec:
  priority: 9
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  ingress:
  - name: "allow-ingress-from-monitoring"
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: allow-monitoring
spec:
  priority: 9
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  ingress:
  - name: "allow-ingress-from-monitoring"
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

Copy to clipboard

これは、関係者全員がオーバーライドできない強力な Allow ANP の例です。テナントは、NetworkPolicy オブジェクトを使用してテナント自体の監視をブロックすることはできません。また、監視を実行するテナントが監視の対象を決定することもできません。

AdminNetworkPolicy の Deny の例

優先度 5 で定義されている次の ANP は、monitoring namespace から制限付きテナント (security: restricted ラベルを持つ namespace) への Ingress トラフィックをすべてブロックします。

例5.3 強力な Deny ANP の YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: block-monitoring
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        security: restricted
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: block-monitoring
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        security: restricted
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

Copy to clipboard

これは、関係者全員がオーバーライドできない強力な Deny ANP です。制限付きテナントの所有者は、トラフィックの監視を許可する権限を自分自身に付与できません。また、インフラストラクチャーの監視サービスは、これらの機密性の高い namespace から何も収集できません。

強力な Allow の例と組み合わせると、block-monitoring ANP の優先度の値よりも Allow の優先度の値のほうが高いため、制限付きテナントが監視されなくなります。

AdminNetworkPolicy の Pass の例

優先度 7 で定義されている次の ANP は、monitoring namespace から内部インフラストラクチャーテナント (security: internal ラベルを持つ namespace) への Ingress トラフィックをすべて ACL の階層 2 に渡し、トラフィックが namespace の NetworkPolicy オブジェクトによって評価されるようにします。

例5.4 強力な Pass ANP の YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: pass-monitoring
spec:
  priority: 7
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "pass-ingress-from-monitoring"
    action: "Pass"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: pass-monitoring
spec:
  priority: 7
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "pass-ingress-from-monitoring"
    action: "Pass"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

Copy to clipboard

この例は、テナント所有者によって定義された NetworkPolicy オブジェクトに決定を委譲する強力な Pass アクション ANP です。この pass-monitoring ANP により、internal セキュリティーレベルでグループ化されたすべてのテナント所有者は、インフラストラクチャーの監視サービスによって namespace スコープの NetworkPolicy オブジェクトを使用してメトリクスを収集する必要があるかどうかを選択できます。

5.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy

5.2.2.1. BaselineAdminNetworkPolicy

BaselineAdminNetworkPolicy (BANP) は、クラスタースコープのカスタムリソース定義 (CRD) です。OpenShift Container Platform 管理者は、BANP を使用すると、NetworkPolicy オブジェクトを使用してユーザーが必要に応じてオーバーライドできるオプションのベースラインネットワークポリシールールを設定および適用できます。BANP のルールアクションは、allow または deny です。

BaselineAdminNetworkPolicy リソースは、クラスターのシングルトンオブジェクトであり、渡されたトラフィックポリシーがクラスター内のどの NetworkPolicy オブジェクトにも一致しない場合にガードレールポリシーとして使用できます。BANP は、クラスター内トラフィックをデフォルトでブロックするガードレールを提供するデフォルトのセキュリティーモデルとしても使用できます。その場合、ユーザーが NetworkPolicy オブジェクトを使用して既知のトラフィックを許可する必要があります。BANP リソースを作成するときは、名前として default を使用する必要があります。

BANP を使用すると、管理者は以下を指定できます。

一連の namespace または namespace で構成される subject。
subject へのすべての Ingress トラフィックに適用される Ingress ルールのリスト。
subject からのすべての Egress トラフィックに適用される Egress ルールのリスト。

BaselineAdminNetworkPolicy の例

例5.5 BANP の YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default 1
spec:
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name 2
  ingress: 3
  - name: "deny-all-ingress-from-tenant-1" 4
    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1 5
        podSelector:
          matchLabels:
            custom-banp: tenant-1 6
  egress:
  - name: "allow-all-egress-to-tenant-1"
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default 1
spec:
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name 2
  ingress: 3
  - name: "deny-all-ingress-from-tenant-1" 4
    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1 5
        podSelector:
          matchLabels:
            custom-banp: tenant-1 6
  egress:
  - name: "allow-all-egress-to-tenant-1"
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1

Copy to clipboard

1: BANP はシングルトンオブジェクトであるため、ポリシー名は default にする必要があります。
2: ANP を適用する namespace を指定します。
3: BANP には Ingress ルールと Egress ルールの両方があります。spec.ingress フィールドと spec.egress フィールドの BANP ルールは、action フィールドの Deny と Allow の値を受け入れます。
4: ingress.name の名前を指定します。
5: BANP リソースを適用する Pod の選択元の namespace を指定します。
6: BANP リソースを適用する Pod の podSelector.matchLabels 名を指定します。

BaselineAdminNetworkPolicy の Deny の例

次の BANP シングルトンは、internal セキュリティーレベルのテナントに着信するすべての Ingress 監視トラフィックに対してデフォルトの拒否ポリシーを設定します。「AdminNetworkPolicy の Pass の例」と組み合わせると、この拒否ポリシーは、ANP pass-monitoring ポリシーによって渡されるすべての Ingress トラフィックに対するガードレールポリシーとして機能します。

例5.6 Deny ガードレールルールの YAML ファイルの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

Copy to clipboard

action フィールドに Pass 値を指定した AdminNetworkPolicy リソースを BaselineAdminNetworkPolicy リソースと組み合わせて使用すると、マルチテナントポリシーを作成できます。このマルチテナントポリシーを使用すると、あるテナントのアプリケーションの監視データを収集しながら、別のテナントのデータを収集しないことが可能になります。

管理者が「AdminNetworkPolicy の Pass アクションの例」と「BaselineAdminNetwork Policy の Deny の例」の両方を適用すると、BANP の前に評価される NetworkPolicy リソースを作成するかどうかをテナントが選択できるようになります。

たとえば、テナント 1 が Ingress トラフィックを監視する次の NetworkPolicy リソースを設定したとします。

例5.7 NetworkPolicy の例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: tenant 1
spec:
  podSelector:
  policyTypes:
    - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: tenant 1
spec:
  podSelector:
  policyTypes:
    - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...

Copy to clipboard

この場合、テナント 1 のポリシーは、「AdminNetworkPolicy の Pass アクションの例」の後、security レベルが internal のテナントに着信する Ingress 監視トラフィックをすべて拒否する「BaselineAdminNetworkPolicy の Deny の例」の前に評価されます。テナント 1 の NetworkPolicy オブジェクトを設定すると、テナント 1 はアプリケーションのデータを収集できるようになります。一方、NetworkPolicy オブジェクトが設定されていないテナント 2 は、データを収集できません。管理者はデフォルトでは内部のテナントを監視していませんでした。その代わりに BANP を作成し、テナントが NetworkPolicy オブジェクトを使用して BANP のデフォルト動作をオーバーライドできるようにしました。

5.2.3. ANP と BANP の監視

AdminNetworkPolicy および BaselineAdminNetworkPolicy リソースには、ポリシーの監視と管理に使用できるメトリクスがあります。メトリクスの詳細は、以下の表を参照してください。

5.2.3.1. AdminNetworkPolicy のメトリクス

名前	説明	詳細
`ovnkube_controller_admin_network_policies`	該当なし	クラスター内の `AdminNetworkPolicy` リソースの合計数。
`ovnkube_controller_baseline_admin_network_policies`	該当なし	クラスター内の `BaselineAdminNetworkPolicy` リソースの合計数。0 または 1 の値を指定してください。
`ovnkube_controller_admin_network_policies_rules`	`direction`: `Ingress` または `Egress` のいずれかを指定します。 `action`: `Pass`、`Allow`、または `Deny` のいずれかを指定します。	`direction` と `action` 別にグループ化された、クラスター内の全 ANP ポリシーにわたるルールの合計数。
`ovnkube_controller_baseline_admin_network_policies_rules`	`direction`: `Ingress` または `Egress` のいずれかを指定します。 `action`: `Allow` または `Deny` のいずれかを指定します。	`direction` と `action` 別にグループ化された、クラスター内の全 BANP ポリシーにわたるルールの合計数。
`ovnkube_controller_admin_network_policies_db_objects`	`table_name`: `ACL` または `Address_Set` のいずれかを指定します	`table_name` でグループ化されたクラスター内の全 ANP によって作成された OVN Northbound データベース (nbdb) オブジェクトの合計数。
`ovnkube_controller_baseline_admin_network_policies_db_objects`	`table_name`: `ACL` または `Address_Set` のいずれかを指定します	`table_name` でグループ化されたクラスター内の全 BANP によって作成された OVN Northbound データベース (nbdb) オブジェクトの合計数。

5.2.4. AdminNetworkPolicy の Egress ノードとネットワークピア

このセクションでは、nodes と networks のピアを説明します。管理者は、このセクションの例を使用して、クラスター内のノースバウンドトラフィックを制御するための AdminNetworkPolicy と BaselineAdminNetworkPolicy を設計できます。

5.2.4.1. AdminNetworkPolicy および BaselineAdminNetworkPolicy のノースバウンドトラフィック制御

ANP と BANP では、East-West トラフィック制御のサポートに加えて、管理者がクラスターから出るノースバウンドトラフィックや、ノードからクラスター内の他のノードに向かうトラフィックを制御することもできます。エンドユーザーは次のことができます。

nodes Egress ピアを使用してクラスターノードへの Egress トラフィック制御を実装する
nodes または networks の Egress ピアを使用して Kubernetes API サーバーへの Egress トラフィック制御を実装する
networks ピアを使用してクラスター外の外部宛先への Egress トラフィック制御を実装する

注記

ANP および BANP の場合、nodes と networks のピアは Egress ルールに対してのみ指定できます。

5.2.4.1.1. ノードピアを使用してクラスターノードへの Egress トラフィックを制御する

nodes ピアを使用すると、管理者は Pod からクラスター内のノードへの Egress トラフィックを制御できます。この利点は、クラスターにノードを追加したり、クラスターからノードを削除したりするときにポリシーを変更する必要がないことです。

次の例では、ノードセレクターピアを使用して、restricted、confidential、または internal レベルのセキュリティーを持つ任意の namespace によるポート 6443 上の Kubernetes API サーバーへの Egress トラフィックを許可します。また、セキュリティーレベルが restricted、confidential、または internal のいずれかである namespace からクラスター内のすべてのワーカーノードへのトラフィックも拒否します。

例5.8 nodes ピアを使用した ANP Allow Egress の例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-security-allow
spec:
  egress:
  - action: Deny
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
  - action: Allow
    name: allow-to-kubernetes-api-server-and-engr-dept-pods
    ports:
    - portNumber:
        port: 6443
        protocol: TCP
    to:
    - nodes: 1
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    - pods: 2
        namespaceSelector:
          matchLabels:
            dept: engr
        podSelector: {}
  priority: 55
  subject: 3
    namespaces:
      matchExpressions:
      - key: security 4
        operator: In
        values:
        - restricted
        - confidential
        - internal

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-security-allow
spec:
  egress:
  - action: Deny
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
  - action: Allow
    name: allow-to-kubernetes-api-server-and-engr-dept-pods
    ports:
    - portNumber:
        port: 6443
        protocol: TCP
    to:
    - nodes: 1
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    - pods: 2
        namespaceSelector:
          matchLabels:
            dept: engr
        podSelector: {}
  priority: 55
  subject: 3
    namespaces:
      matchExpressions:
      - key: security 4
        operator: In
        values:
        - restricted
        - confidential
        - internal

Copy to clipboard

1: matchExpressions フィールドを使用して、クラスター内のノードまたはノードセットを指定します。
2: dept: engr のラベルが付けられたすべての Pod を指定します。
3: ネットワークポリシーで使用されるラベルに一致する namespace を含む ANP のサブジェクトを指定します。この例は、security レベルが restrict、confidential、または internal である namespace のいずれかに一致します。
4: matchExpressions フィールドのキー/値のペアを指定します。

5.2.4.1.2. ネットワークピアを使用して外部の宛先への Egress トラフィックを制御する

クラスター管理者は、networks ピアで CIDR 範囲を使用し、Pod から networks フィールドで指定された CIDR 範囲内の IP アドレスで設定された宛先に送信される Egress トラフィックを制御するポリシーを適用できます。

以下の例では、networks ピアを使用し、ANP ポリシーと BANP ポリシーを組み合わせて出力トラフィックを制限します。

重要

ANP および BANP の namespace フィールドで空のセレクター ({}) を使用する場合は注意が必要です。空のセレクターを使用する場合は、OpenShift namespace も選択します。

ANP または BANP Deny ルールで 0.0.0.0/0 の値を使用する場合は、Deny を 0.0.0.0/0 に設定する前に、必要な宛先に優先度の高い ANP Allow ルールを設定する必要があります。

例5.9 networks ピアを使用した ANP と BANP の例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: network-as-egress-peer
spec:
  priority: 70
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-egress-to-external-dns-servers"
    action: "Deny"
    to:
    - networks:1
      - 8.8.8.8/32
      - 8.8.4.4/32
      - 208.67.222.222/32
    ports:
      - portNumber:
          protocol: UDP
          port: 53
  - name: "allow-all-egress-to-intranet"
    action: "Allow"
    to:
    - networks: 2
      - 89.246.180.0/22
      - 60.45.72.0/22
  - name: "allow-all-intra-cluster-traffic"
    action: "Allow"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  - name: "pass-all-egress-to-internet"
    action: "Pass"
    to:
    - networks:
      - 0.0.0.0/0 3
---
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-all-egress-to-internet"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0 4
---

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: network-as-egress-peer
spec:
  priority: 70
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-egress-to-external-dns-servers"
    action: "Deny"
    to:
    - networks:1
      - 8.8.8.8/32
      - 8.8.4.4/32
      - 208.67.222.222/32
    ports:
      - portNumber:
          protocol: UDP
          port: 53
  - name: "allow-all-egress-to-intranet"
    action: "Allow"
    to:
    - networks: 2
      - 89.246.180.0/22
      - 60.45.72.0/22
  - name: "allow-all-intra-cluster-traffic"
    action: "Allow"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  - name: "pass-all-egress-to-internet"
    action: "Pass"
    to:
    - networks:
      - 0.0.0.0/0 3
---
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-all-egress-to-internet"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0 4
---

Copy to clipboard

1: networks を使用して、クラスター外の CIDR ネットワークの範囲を指定します。
2: リソースからのクラスター内トラフィックの CIDR 範囲を指定します。
3 4: networks 値を 0.0.0.0/0 に設定して、すべてに対して Deny Egress を指定します。Deny を 0.0.0.0/0 に設定する前に、必要な宛先に対して優先度の高い Allow ルールが設定されていることを確認してください。これにより、Kubernetes API および DNS サーバーを含むすべてのトラフィックが拒否されます。

network-as-egress-peer ANP と、networks ピアを使用する networks の BANP を組み合わせると、次の Egress ポリシーが適用されます。

どの Pod も、リストされた IP アドレスの外部 DNS サーバーと通信できない。
どの Pod も、会社の残りのイントラネットと通信できない。
すべての Pod が、他の Pod、ノード、およびサービスと通信できる。
どの Pod もインターネットと通信できない。最後の ANP Pass ルールと強力な BANP Deny ルールを組み合わせることで、クラスター内のトラフィックを保護するガードレールポリシーが作成されます。

5.2.4.1.3. ノードピアとネットワークピアを一緒に使用する

クラスター管理者は、ANP および BANP ポリシーで nodes と networks ピアを組み合わせることができます。

例5.10 nodes と networks ピアの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-peer-1 1
spec:
  egress: 2
  - action: "Allow"
    name: "allow-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - workloads # Egress traffic from nodes with label worker-group: workloads is allowed.
    - networks:
      - 104.154.164.170/32
    - pods:
        namespaceSelector:
          matchLabels:
            apps: external-apps
        podSelector:
          matchLabels:
            app: web # This rule in the policy allows the traffic directed to pods labeled apps: web in projects with apps: external-apps to leave the cluster.
  - action: "Deny"
    name: "deny-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - infra # Egress traffic from nodes with label worker-group: infra is denied.
    - networks:
      - 104.154.164.160/32 # Egress traffic to this IP address from cluster is denied.
    - pods:
        namespaceSelector:
          matchLabels:
            apps: internal-apps
        podSelector: {}
  - action: "Pass"
    name: "pass-egress"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists # All other egress traffic is passed to NetworkPolicy or BANP for evaluation.
  priority: 30 3
  subject: 4
    namespaces:
      matchLabels:
        apps: all-apps

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-peer-1 1
spec:
  egress: 2
  - action: "Allow"
    name: "allow-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - workloads # Egress traffic from nodes with label worker-group: workloads is allowed.
    - networks:
      - 104.154.164.170/32
    - pods:
        namespaceSelector:
          matchLabels:
            apps: external-apps
        podSelector:
          matchLabels:
            app: web # This rule in the policy allows the traffic directed to pods labeled apps: web in projects with apps: external-apps to leave the cluster.
  - action: "Deny"
    name: "deny-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - infra # Egress traffic from nodes with label worker-group: infra is denied.
    - networks:
      - 104.154.164.160/32 # Egress traffic to this IP address from cluster is denied.
    - pods:
        namespaceSelector:
          matchLabels:
            apps: internal-apps
        podSelector: {}
  - action: "Pass"
    name: "pass-egress"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists # All other egress traffic is passed to NetworkPolicy or BANP for evaluation.
  priority: 30 3
  subject: 4
    namespaces:
      matchLabels:
        apps: all-apps

Copy to clipboard

1: ポリシーの名前を指定します。
2: nodes および networks ピアの場合、Egress として ANP のノースバウンドトラフィック制御のみを使用できます。
3: ANP の優先順位を指定して、評価する順序を決定します。優先度の低いルールの方が優先順位が高くなります。ANP は 0 - 99 の値を受け入れます。0 が最高の優先度、99 が最低の優先度です。
4: ポリシーのルールを適用するクラスター内の Pod のセットを指定します。この例では、すべての namespace で apps: all-apps ラベルが付いたすべての Pod がポリシーの 対象 になります。

5.2.5. AdminNetworkPolicy のトラブルシューティング

5.2.5.1. ANP の作成の確認

AdminNetworkPolicy (ANP) と BaselineAdminNetworkPolicy (BANP) が正しく作成されていることを確認するには、oc describe anp または oc describe banp のコマンドのステータス出力を確認します。

ステータスが良好な場合は、OVN DB plumbing was successful および SetupSucceeded と表示されます。

例5.11 正常なステータスの ANP の例

...
Conditions:
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-control-plane Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker2
...

...
Conditions:
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-control-plane Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker2
...

Copy to clipboard

設定が失敗した場合、それぞれのゾーンコントローラーからエラーが報告されます。

例5.12 不正なステータスとエラーメッセージを含む ANP の例

...
Status:
  Conditions:
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:45Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-0.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-2.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-0.example.example-org.net
    ```

...
Status:
  Conditions:
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:45Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-0.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-2.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-0.example.example-org.net
    ```

Copy to clipboard

失敗したポリシーのトラブルシューティングに役立つ nbctl コマンドについては、次のセクションを参照してください。

5.2.5.1.1. ANP および BANP への nbctl コマンドの使用

失敗したセットアップのトラブルシューティングを行うには、まず ACL、AdressSet、Port_Group などの OVN Northbound データベース (nbdb) オブジェクトを確認します。nbdb を表示するには、そのノードの Pod 内にいて、そのノードのデータベース内のオブジェクトを表示する必要があります。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
OpenShift CLI (oc) がインストールされている。

注記

クラスターで ovn nbctl コマンドを実行するには、関連するノード上の `nbdb` にリモートシェルを起動する必要があります。

出力を生成するために次のポリシーが使用されました。

例5.13 出力の生成に使用される AdminNetworkPolicy

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: cluster-control
spec:
  priority: 34
  subject:
    namespaces:
      matchLabels:
        anp: cluster-control-anp # Only namespaces with this label have this ANP
  ingress:
  - name: "allow-from-ingress-router" # rule0
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  - name: "allow-from-monitoring" # rule1
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: openshift-monitoring
    ports:
    - portNumber:
        protocol: TCP
        port: 7564
    - namedPort: "scrape"
  - name: "allow-from-open-tenants" # rule2
    action: "Allow"
    from:
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-from-restricted-tenants" # rule3
    action: "Pass"
    from:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny" # rule4
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "allow-to-dns" # rule0
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchlabels:
            kubernetes.io/metadata.name: openshift-dns
        podSelector:
          matchlabels:
            app: dns
    ports:
    - portNumber:
        protocol: UDP
        port: 5353
  - name: "allow-to-kapi-server" # rule1
    action: "Allow"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    ports:
    - portNumber:
        protocol: TCP
        port: 6443
  - name: "allow-to-splunk" # rule2
    action: "Allow"
    to:
    - namespaces:
        matchlabels:
          tenant: splunk
    ports:
    - portNumber:
        protocol: TCP
        port: 8991
    - portNumber:
        protocol: TCP
        port: 8992
  - name: "allow-to-open-tenants-and-intranet-and-worker-nodes" # rule3
    action: "Allow"
    to:
    - nodes: # worker-nodes
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
    - networks: # intranet
      - 172.29.0.0/30
      - 10.0.54.0/19
      - 10.0.56.38/32
      - 10.0.69.0/24
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-to-restricted-tenants" # rule4
    action: "Pass"
    to:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: cluster-control
spec:
  priority: 34
  subject:
    namespaces:
      matchLabels:
        anp: cluster-control-anp # Only namespaces with this label have this ANP
  ingress:
  - name: "allow-from-ingress-router" # rule0
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  - name: "allow-from-monitoring" # rule1
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: openshift-monitoring
    ports:
    - portNumber:
        protocol: TCP
        port: 7564
    - namedPort: "scrape"
  - name: "allow-from-open-tenants" # rule2
    action: "Allow"
    from:
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-from-restricted-tenants" # rule3
    action: "Pass"
    from:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny" # rule4
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "allow-to-dns" # rule0
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchlabels:
            kubernetes.io/metadata.name: openshift-dns
        podSelector:
          matchlabels:
            app: dns
    ports:
    - portNumber:
        protocol: UDP
        port: 5353
  - name: "allow-to-kapi-server" # rule1
    action: "Allow"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    ports:
    - portNumber:
        protocol: TCP
        port: 6443
  - name: "allow-to-splunk" # rule2
    action: "Allow"
    to:
    - namespaces:
        matchlabels:
          tenant: splunk
    ports:
    - portNumber:
        protocol: TCP
        port: 8991
    - portNumber:
        protocol: TCP
        port: 8992
  - name: "allow-to-open-tenants-and-intranet-and-worker-nodes" # rule3
    action: "Allow"
    to:
    - nodes: # worker-nodes
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
    - networks: # intranet
      - 172.29.0.0/30
      - 10.0.54.0/19
      - 10.0.56.38/32
      - 10.0.69.0/24
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-to-restricted-tenants" # rule4
    action: "Pass"
    to:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0

Copy to clipboard

手順

次のコマンドを実行して、ノード情報を含む Pod をリスト表示します。

oc get pods -n openshift-ovn-kubernetes -owide

$ oc get pods -n openshift-ovn-kubernetes -owide

Copy to clipboard

出力例

NAME                                     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
ovnkube-control-plane-5c95487779-8k9fd   2/2     Running   0          34m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-control-plane-5c95487779-v2xn8   2/2     Running   0          34m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-524dt                       8/8     Running   0          33m   10.0.0.4     ci-ln-0tv5gg2-72292-6sjw5-master-2         <none>           <none>
ovnkube-node-gbwr9                       8/8     Running   0          24m   10.0.128.4   ci-ln-0tv5gg2-72292-6sjw5-worker-c-s9gqt   <none>           <none>
ovnkube-node-h4fpx                       8/8     Running   0          33m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-node-j4hzw                       8/8     Running   0          24m   10.0.128.2   ci-ln-0tv5gg2-72292-6sjw5-worker-a-hzbh5   <none>           <none>
ovnkube-node-wdhgv                       8/8     Running   0          33m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-wfncn                       8/8     Running   0          24m   10.0.128.3   ci-ln-0tv5gg2-72292-6sjw5-worker-b-5bb7f   <none>           <none>

NAME                                     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
ovnkube-control-plane-5c95487779-8k9fd   2/2     Running   0          34m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-control-plane-5c95487779-v2xn8   2/2     Running   0          34m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-524dt                       8/8     Running   0          33m   10.0.0.4     ci-ln-0tv5gg2-72292-6sjw5-master-2         <none>           <none>
ovnkube-node-gbwr9                       8/8     Running   0          24m   10.0.128.4   ci-ln-0tv5gg2-72292-6sjw5-worker-c-s9gqt   <none>           <none>
ovnkube-node-h4fpx                       8/8     Running   0          33m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-node-j4hzw                       8/8     Running   0          24m   10.0.128.2   ci-ln-0tv5gg2-72292-6sjw5-worker-a-hzbh5   <none>           <none>
ovnkube-node-wdhgv                       8/8     Running   0          33m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-wfncn                       8/8     Running   0          24m   10.0.128.3   ci-ln-0tv5gg2-72292-6sjw5-worker-b-5bb7f   <none>           <none>

Copy to clipboard

次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。
```
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
```
```
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
```
Copy to clipboardCopied

ACL nbdb を確認するには、次のコマンドを実行します。

ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

Copy to clipboard

詳細は以下のようになります。, cluster-control: トラブルシューティングする AdminNetworkPolicy の名前を指定します。
AdminNetworkPolicy: AdminNetworkPolicy または BaselineAdminNetworkPolicy のタイプを指定します。

例5.14 ACL の出力例

_uuid               : 0d5e4722-b608-4bb1-b625-23c323cc9926
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13730899355151937870))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:2"
options             : {}
priority            : 26598
severity            : []
tier                : 1

_uuid               : b7be6472-df67-439c-8c9c-f55929f0a6e0
action              : drop
direction           : from-lport
external_ids        : {direction=Egress, gress-index="5", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a11452480169090787059))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:5"
options             : {apply-after-lb="true"}
priority            : 26595
severity            : []
tier                : 1

_uuid               : 5a6e5bb4-36eb-4209-b8bc-c611983d4624
action              : pass
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a764182844364804195))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:3"
options             : {}
priority            : 26597
severity            : []
tier                : 1

_uuid               : 04f20275-c410-405c-a923-0e677f767889
action              : pass
direction           : from-lport
external_ids        : {direction=Egress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a5972452606168369118))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:4"
options             : {apply-after-lb="true"}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 4b5d836a-e0a3-4088-825e-f9f0ca58e538
action              : drop
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13814616246365836720))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:4"
options             : {}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 5d09957d-d2cc-4f5a-9ddd-b97d9d772023
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a18396736153283155648)) && tcp && tcp.dst=={8991,8992}"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:2"
options             : {apply-after-lb="true"}
priority            : 26598
severity            : []
tier                : 1

_uuid               : 1a68a5ed-e7f9-47d0-b55c-89184d97e81a
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10706246167277696183)) && tcp && tcp.dst==6443"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:1"
options             : {apply-after-lb="true"}
priority            : 26599
severity            : []
tier                : 1

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

_uuid               : 1a27d30e-3f96-4915-8ddd-ade7f22c117b
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10622494091691694581))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:3"
options             : {apply-after-lb="true"}
priority            : 26597
severity            : []
tier                : 1

_uuid               : b23a087f-08f8-4225-8c27-4a9a9ee0c407
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:udp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=udp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a13517855690389298082)) && udp && udp.dst==5353"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:0"
options             : {apply-after-lb="true"}
priority            : 26600
severity            : []
tier                : 1

_uuid               : d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a14545668191619617708))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:0"
options             : {}
priority            : 26600
severity            : []
tier                : 1

_uuid               : 0d5e4722-b608-4bb1-b625-23c323cc9926
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13730899355151937870))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:2"
options             : {}
priority            : 26598
severity            : []
tier                : 1

_uuid               : b7be6472-df67-439c-8c9c-f55929f0a6e0
action              : drop
direction           : from-lport
external_ids        : {direction=Egress, gress-index="5", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a11452480169090787059))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:5"
options             : {apply-after-lb="true"}
priority            : 26595
severity            : []
tier                : 1

_uuid               : 5a6e5bb4-36eb-4209-b8bc-c611983d4624
action              : pass
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a764182844364804195))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:3"
options             : {}
priority            : 26597
severity            : []
tier                : 1

_uuid               : 04f20275-c410-405c-a923-0e677f767889
action              : pass
direction           : from-lport
external_ids        : {direction=Egress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a5972452606168369118))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:4"
options             : {apply-after-lb="true"}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 4b5d836a-e0a3-4088-825e-f9f0ca58e538
action              : drop
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13814616246365836720))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:4"
options             : {}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 5d09957d-d2cc-4f5a-9ddd-b97d9d772023
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a18396736153283155648)) && tcp && tcp.dst=={8991,8992}"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:2"
options             : {apply-after-lb="true"}
priority            : 26598
severity            : []
tier                : 1

_uuid               : 1a68a5ed-e7f9-47d0-b55c-89184d97e81a
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10706246167277696183)) && tcp && tcp.dst==6443"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:1"
options             : {apply-after-lb="true"}
priority            : 26599
severity            : []
tier                : 1

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

_uuid               : 1a27d30e-3f96-4915-8ddd-ade7f22c117b
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10622494091691694581))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:3"
options             : {apply-after-lb="true"}
priority            : 26597
severity            : []
tier                : 1

_uuid               : b23a087f-08f8-4225-8c27-4a9a9ee0c407
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:udp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=udp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a13517855690389298082)) && udp && udp.dst==5353"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:0"
options             : {apply-after-lb="true"}
priority            : 26600
severity            : []
tier                : 1

_uuid               : d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a14545668191619617708))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:0"
options             : {}
priority            : 26600
severity            : []
tier                : 1

Copy to clipboard

注記

Ingress および Egress の出力には、ACL のポリシーのロジックが表示されます。たとえば、パケットが指定された match と一致するたびに action が実行されます。

次のコマンドを実行して、ルールの特定の ACL を調べます。

ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'

$ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'

Copy to clipboard

詳細は以下のようになります。, cluster-control: ANP の 名前 を指定します。
Ingress: トラフィックの 方向 を Ingress または Egress のいずれかのタイプで指定します。
1: 確認するルールを指定します。

priority 34 の cluster-control という名前の ANP の例では、Ingress rule 1 の出力例は次のとおりです。

例5.15 出力例

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

Copy to clipboard

nbdb 内のアドレスセットを確認するには、次のコマンドを実行します。

ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

Copy to clipboard

例5.16 Address_Set の出力例

_uuid               : 56e89601-5552-4238-9fc3-8833f5494869
addresses           : ["192.168.194.135", "192.168.194.152", "192.168.194.193", "192.168.194.254"]
external_ids        : {direction=Egress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10706246167277696183

_uuid               : 7df9330d-380b-4bdb-8acd-4eddeda2419c
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13814616246365836720

_uuid               : 84d76f13-ad95-4c00-8329-a0b1d023c289
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Egress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a5972452606168369118

_uuid               : 0c53e917-f7ee-4256-8f3a-9522c0481e52
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a18396736153283155648

_uuid               : 5228bf1b-dfd8-40ec-bfa8-95c5bf9aded9
addresses           : []
external_ids        : {direction=Ingress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14545668191619617708

_uuid               : 46530d69-70da-4558-8c63-884ec9dc4f25
addresses           : ["10.132.2.10", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.133.0.47", "10.134.0.33", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.19", "10.135.0.24", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a6786643370959569281

_uuid               : 65fdcdea-0b9f-4318-9884-1b51d231ad1d
addresses           : ["10.132.3.72", "10.135.0.42"]
external_ids        : {direction=Ingress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13730899355151937870

_uuid               : 73eabdb0-36bf-4ca3-b66d-156ac710df4c
addresses           : ["10.0.32.0/19", "10.0.56.38/32", "10.0.69.0/24", "10.132.3.72", "10.135.0.42", "172.29.0.0/30", "192.168.194.103", "192.168.194.2"]
external_ids        : {direction=Egress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10622494091691694581

_uuid               : 50cdbef2-71b5-474b-914c-6fcd1d7712d3
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13517855690389298082

_uuid               : 32a42f32-2d11-43dd-979d-a56d7ee6aa57
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Ingress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a764182844364804195

_uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059

_uuid               : 56e89601-5552-4238-9fc3-8833f5494869
addresses           : ["192.168.194.135", "192.168.194.152", "192.168.194.193", "192.168.194.254"]
external_ids        : {direction=Egress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10706246167277696183

_uuid               : 7df9330d-380b-4bdb-8acd-4eddeda2419c
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13814616246365836720

_uuid               : 84d76f13-ad95-4c00-8329-a0b1d023c289
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Egress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a5972452606168369118

_uuid               : 0c53e917-f7ee-4256-8f3a-9522c0481e52
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a18396736153283155648

_uuid               : 5228bf1b-dfd8-40ec-bfa8-95c5bf9aded9
addresses           : []
external_ids        : {direction=Ingress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14545668191619617708

_uuid               : 46530d69-70da-4558-8c63-884ec9dc4f25
addresses           : ["10.132.2.10", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.133.0.47", "10.134.0.33", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.19", "10.135.0.24", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a6786643370959569281

_uuid               : 65fdcdea-0b9f-4318-9884-1b51d231ad1d
addresses           : ["10.132.3.72", "10.135.0.42"]
external_ids        : {direction=Ingress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13730899355151937870

_uuid               : 73eabdb0-36bf-4ca3-b66d-156ac710df4c
addresses           : ["10.0.32.0/19", "10.0.56.38/32", "10.0.69.0/24", "10.132.3.72", "10.135.0.42", "172.29.0.0/30", "192.168.194.103", "192.168.194.2"]
external_ids        : {direction=Egress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10622494091691694581

_uuid               : 50cdbef2-71b5-474b-914c-6fcd1d7712d3
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13517855690389298082

_uuid               : 32a42f32-2d11-43dd-979d-a56d7ee6aa57
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Ingress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a764182844364804195

_uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059

Copy to clipboard

次のコマンドを実行して、ルールの特定のアドレスセットを調べます。

ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'

$ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'

Copy to clipboard

例5.17 Address_Set の出力例

_uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059

_uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059

Copy to clipboard

次のコマンドを実行して、nbdb 内のポートグループを確認します。

ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

$ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'

Copy to clipboard

例5.18 Port_Group の出力例

_uuid               : f50acf71-7488-4b9a-b7b8-c8a024e99d21
acls                : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd]
external_ids        : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14645450421485494999
ports               : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]

_uuid               : f50acf71-7488-4b9a-b7b8-c8a024e99d21
acls                : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd]
external_ids        : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14645450421485494999
ports               : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]

Copy to clipboard

5.2.5.2. 関連情報

ovnkube-trace を使用した Openflow のトレース
OVN-Kubernetes のトラブルシューティング

5.2.6. AdminNetworkPolicy のベストプラクティス

このセクションでは、AdminNetworkPolicy および BaselineAdminNetworkPolicy リソースのベストプラクティスを説明します。

5.2.6.1. AdminNetworkPolicy の設計

AdminNetworkPolicy (ANP) リソースを構築する場合は、ポリシーを作成するときに次の点を考慮する必要があります。

同じ優先度を持つ ANP を作成できます。同じ優先度で 2 つの ANP を作成する場合は、重複するルールが同じトラフィックに適用されないようにしてください。値ごとに 1 つのルールのみが適用されます。同じ優先度の値が複数ある場合は、どのルールが適用されるか保証されません。重複する ANP を作成すると、どのポリシーが優先されるか保証されません。そのため、優先順位が明確に定義されるように、異なる優先度で ANP を設定してください。
管理者は、システム namespace ではなくユーザー namespace に適用される ANP を作成する必要があります。

重要

ANP および BaselineAdminNetworkPolicy (BANP) をシステム namespace (default、kube-system、名前が openshift- で始まる namespace など) に適用することはサポートされていないため、クラスターが応答しなくなり、機能しない状態になる可能性があります。

サポートされている優先度の範囲は 0 - 100 であるため、30 - 70 のような中間の範囲を使用するように ANP を設計することもできます。これにより、前後の優先順位のためのプレースホルダーが残ります。中間の範囲でも、インフラストラクチャーの要件が時間の経過とともに進化するにつれて、適切な優先度レベルで必要なときに新しい ANP を挿入できるように、ギャップを残しておくことを推奨します。ANP をパックすると、将来の変更に対応するために、それらをすべて再作成しないといけない場合があります。
0.0.0.0/0 または ::/0 を使用して強力な Deny ポリシーを作成する場合は、重要なトラフィックに対して優先度の高い Allow または Pass ルールがあることを確認してください。
どのような場合でも接続が許可されるようにしたい場合は、action フィールドとして Allow を使用します。ANP の Allow ルールは、接続が常に許可され、NetworkPolicy が無視されることを意味します。
接続を許可または拒否するポリシー決定を NetworkPolicy レイヤーに委任するには、action フィールドに Pass を使用します。
複数のルールにわたるセレクターが重複しないようにして、同じ IP が複数のポリシーに表示されないようにします。これにより、パフォーマンスとスケールの制限が発生する可能性があります。
namedPorts を PortNumber および PortRange と組み合わせて使用することは避けてください。これにより 6 つの ACL が作成され、クラスターの効率が低下します。

5.2.6.1.1. BaselineAdminNetworkPolicy の使用に関する考慮事項

クラスター内で定義できる BaselineAdminNetworkPolicy (BANP) リソースは 1 つだけです。以下は、管理者が BANP を設計する際に考慮する可能性がある、BANP でサポートされている用途です。
- ユーザー namespace 内のクラスターローカル Ingress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可したい Ingress トラフィックを許可するために NetworkPolicy オブジェクトを追加する必要があり、Ingress 用のネットワークポリシーを追加しないとトラフィックが拒否されます。
- ユーザー namespace のクラスターローカル Egress に対してデフォルトの拒否ポリシーを設定できます。この BANP により、開発者は許可する Egress トラフィックを許可するために NetworkPolicy オブジェクトを追加する必要があり、ネットワークポリシーを追加しないとトラフィックが拒否されます。
- クラスター内 DNS サービスへの Egress に対してデフォルトの許可ポリシーを設定できます。このような BANP により、namespace のユーザーは、クラスター内 DNS サービスへの許可 Egress NetworkPolicy を設定する必要がなくなります。
- すべての Pod への内部 Egress トラフィックを許可し、すべての外部エンドポイント (つまり 0.0.0.0/0 および ::/0) へのアクセスを拒否する Egress ポリシーを設定できます。この BANP により、ユーザーワークロードは他のクラスター内エンドポイントにトラフィックを送信できますが、デフォルトでは外部エンドポイントには送信できません。開発者は NetworkPolicy を使用して、アプリケーションが明示的な外部サービスセットにトラフィックを送信できるようにすることができます。
BANP のスコープを設定し、システム namespace ではなくユーザー namespace へのトラフィックのみを拒否するようにしてください。これは、システム namespace に BANP をオーバーライドする NetworkPolicy オブジェクトがないためです。

5.2.6.1.2. AdminNetworkPolicy と NetworkPolicy の考慮すべき相違点

NetworkPolicy オブジェクトとは異なり、誤ってトラフィックが選択されることを避けるために、空の ({}) キャッチオールセレクターを使用するのではなく、明示的なラベルを使用して ANP および BANP 内のワークロードを参照する必要があります。

重要

インフラストラクチャー namespace に空の namespace セレクターを適用すると、クラスターが応答しなくなり、機能しない状態になる可能性があります。

ANP の API セマンティクスでは、暗黙的な拒否を持つ NetworkPolicy オブジェクトとは異なり、ポリシーを作成するときに許可または拒否のルールを明示的に定義する必要があります。
NetworkPolicy オブジェクトとは異なり、AdminNetworkPolicy オブジェクトの Ingress ルールはクラスター内の Pod と namespace に制限されているため、ホストネットワークからの Ingress のルールを設定することはできず、また設定する必要もありません。

5.3. ネットワークポリシー

5.3.1. ネットワークポリシーについて

開発者は、クラスター内の Pod へのトラフィックを制限するネットワークポリシーを定義できます。

5.3.1.1. ネットワークポリシーについて

デフォルトで、プロジェクトのすべての 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) プロトコルにのみ適用されます。他のプロトコルは影響を受けません。

警告

ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワーク化された Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。
podSelector フィールドを {} に設定せずに namespaceSelector フィールドを使用すると、hostNetwork Pod が含まれません。ネットワークポリシーの作成時に hostNetwork Pod をターゲットにするには、namespaceSelector フィールドで podSelector を {} に設定して使用する必要があります。
ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。

以下のサンプル 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 clipboardCopied

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

プロジェクト内の 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 clipboardCopied

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

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

NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。

5.3.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: ""1
  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: ""1
  podSelector: {}
  policyTypes:
  - Ingress

Copy to clipboard

1: policy-group.network.openshift.io/ingress:"" ラベルは OVN-Kubernetes をサポートします。

5.3.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

Copy to clipboard

5.3.1.2. 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

以下のポリシーは、上記と同じ 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

同じガイドラインが 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

以下のネットワークポリシーは、上記と同じ 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

この最適化は、複数のセレクターを 1 つのセレクターとして表現する場合に限り適用できます。セレクターが異なるラベルに基づいている場合、この最適化は適用できない可能性があります。その場合は、ネットワークポリシーの最適化に特化して新規ラベルをいくつか適用することを検討してください。

5.3.1.2.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

Copy to clipboard

ここでは、以下のようになります。

<policy_name>: ポリシーの名前を指定します。
<my_namespace>: ポリシーがデプロイされる namespace の名前を指定します。

詳細は、「ネットワークポリシーについて」を参照してください。

5.3.1.3. 次のステップ

ネットワークポリシーの作成
オプション: プロジェクトのデフォルトのネットワークポリシーを定義する

5.3.1.4. 関連情報

プロジェクトおよび namespace
ネットワークポリシーを使用したマルチテナント分離の設定
NetworkPolicy API

5.3.2. ネットワークポリシーの作成

admin ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。

5.3.2.1. サンプル NetworkPolicy オブジェクト

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

Copy to clipboard

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

5.3.2.2. CLI を使用したネットワークポリシーの作成

クラスターの namespace に許可される Ingress または Egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが適用される namespace で作業している。

手順

ポリシールールを作成します。

<policy_name>.yaml ファイルを作成します。
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to clipboardCopied
ここでは、以下のようになります。
<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

同じ 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

特定の 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

ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
$ oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーファイル名を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
networkpolicy.networking.k8s.io/deny-by-default created
```
```
networkpolicy.networking.k8s.io/deny-by-default created
```
Copy to clipboardCopied

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

5.3.2.3. デフォルトの全拒否ネットワークポリシーの作成

このポリシーは、デプロイされた他のネットワークポリシーの設定によって許可されたネットワークトラフィックと、ホストネットワークを使用する Pod 間のトラフィック以外のすべての Pod 間ネットワークをブロックします。この手順では、my-project namespace に deny-by-default ポリシーを適用することにより、強力な拒否ポリシーを強制します。

警告

トラフィック通信を許可する NetworkPolicy カスタムリソース (CR) を設定しない場合、次のポリシーによってクラスター全体で通信問題が発生する可能性があります。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
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: my-project 1
spec:
  podSelector: {} 2
  ingress: [] 3
```
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: my-project 1
spec:
  podSelector: {} 2
  ingress: [] 3
```
Copy to clipboardCopied
1
ポリシーをデプロイする namespace を指定します。たとえば、`my-project namespace です。
2
このフィールドが空の場合、設定はすべての Pod と一致します。したがって、ポリシーは my-project namespace 内のすべての Pod に適用されます。
3
指定された ingress ルールはありません。これにより、着信トラフィックがすべての Pod にドロップされます。

次のコマンドを入力して、ポリシーを適用します。

oc apply -f deny-by-default.yaml

$ oc apply -f deny-by-default.yaml

Copy to clipboard

出力例

networkpolicy.networking.k8s.io/deny-by-default created

networkpolicy.networking.k8s.io/deny-by-default created

Copy to clipboard

5.3.2.4. 外部クライアントからのトラフィックを許可するネットワークポリシーの作成

deny-by-default ポリシーを設定すると、外部クライアントからラベル app=web を持つ Pod へのトラフィックを許可するポリシーの設定に進むことができます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、パブリックインターネットから直接、またはロードバランサーを使用して Pod にアクセスすることにより、外部サービスを許可するポリシーを設定します。トラフィックは、ラベル app=web を持つ Pod にのみ許可されます。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
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

次のコマンドを入力して、ポリシーを適用します。
```
oc apply -f web-allow-external.yaml
```
```
$ oc apply -f web-allow-external.yaml
```
Copy to clipboardCopied
出力例
```
networkpolicy.networking.k8s.io/web-allow-external created
```
```
networkpolicy.networking.k8s.io/web-allow-external created
```
Copy to clipboardCopied
このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

5.3.2.5. すべての namespace からアプリケーションへのトラフィックを許可するネットワークポリシーを作成する

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

この手順に従って、すべての namespace 内のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを設定します。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
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 1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {} 2
```
```
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 clipboardCopied
1
デフォルトの namespace の app:web Pod にのみポリシーを適用します。
2
すべての namespace のすべての Pod を選択します。
注記
デフォルトでは、namespaceSelector の指定を省略した場合、namespace は選択されません。つまり、ポリシーは、ネットワークポリシーがデプロイされている namespace からのトラフィックのみを許可します。

次のコマンドを入力して、ポリシーを適用します。

oc apply -f web-allow-all-namespaces.yaml

$ oc apply -f web-allow-all-namespaces.yaml

Copy to clipboard

出力例

networkpolicy.networking.k8s.io/web-allow-all-namespaces created

networkpolicy.networking.k8s.io/web-allow-all-namespaces created

Copy to clipboard

検証

次のコマンドを入力して、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

次のコマンドを実行して、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 clipboardCopied

シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to clipboard

予想される出力

<!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

5.3.2.6. namespace からアプリケーションへのトラフィックを許可するネットワークポリシーの作成

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

特定の namespace からラベル app=web を持つ Pod へのトラフィックを許可するポリシーを設定するには、次の手順に従います。以下の場合にこれを行うことができます。

運用データベースへのトラフィックを、運用ワークロードがデプロイされている namespace のみに制限します。
特定の namespace にデプロイされた監視ツールを有効にして、現在の namespace からメトリクスをスクレイピングします。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
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 1
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production 2

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

1: デフォルトの namespace の app:web Pod にのみポリシーを適用します。
2: ラベルが purpose=production の namespace 内にある Pod のみにトラフィックを制限します。

次のコマンドを入力して、ポリシーを適用します。

oc apply -f web-allow-prod.yaml

$ oc apply -f web-allow-prod.yaml

Copy to clipboard

出力例

networkpolicy.networking.k8s.io/web-allow-prod created

networkpolicy.networking.k8s.io/web-allow-prod created

Copy to clipboard

検証

次のコマンドを入力して、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

次のコマンドを実行して、prod namespace を作成します。
```
oc create namespace prod
```
```
$ oc create namespace prod
```
Copy to clipboardCopied
次のコマンドを実行して、prod namespace にラベルを付けます。
```
oc label namespace/prod purpose=production
```
```
$ oc label namespace/prod purpose=production
```
Copy to clipboardCopied
次のコマンドを実行して、dev namespace を作成します。
```
oc create namespace dev
```
```
$ oc create namespace dev
```
Copy to clipboardCopied
次のコマンドを実行して、dev namespace にラベルを付けます。
```
oc label namespace/dev purpose=testing
```
```
$ oc label namespace/dev purpose=testing
```
Copy to clipboardCopied
次のコマンドを実行して、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 clipboardCopied
シェルで次のコマンドを実行し、リクエストがブロックされていることを確認します。
```
wget -qO- --timeout=2 http://web.default
```
```
# wget -qO- --timeout=2 http://web.default
```
Copy to clipboardCopied
予想される出力
```
wget: download timed out
```
```
wget: download timed out
```
Copy to clipboardCopied
次のコマンドを実行して、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 clipboardCopied

シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。

wget -qO- --timeout=2 http://web.default

# wget -qO- --timeout=2 http://web.default

Copy to clipboard

予想される出力

<!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

5.3.2.7. 関連情報

Web コンソールへのアクセス
Egress ファイアウォールとネットワークポリシールールのロギング

5.3.3. ネットワークポリシーの表示

admin ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。

5.3.3.1. サンプル NetworkPolicy オブジェクト

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

Copy to clipboard

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

5.3.3.2. CLI を使用したネットワークポリシーの表示

namespace のネットワークポリシーを検査できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを表示できます。

前提条件

OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

namespace のネットワークポリシーを一覧表示します。

namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to clipboardCopied

オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。

oc describe networkpolicy <policy_name> -n <namespace>

$ oc describe networkpolicy <policy_name> -n <namespace>

Copy to clipboard

ここでは、以下のようになります。

<policy_name>: 検査するネットワークポリシーの名前を指定します。
<namespace>: オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

以下に例を示します。

oc describe networkpolicy allow-same-namespace

$ oc describe networkpolicy allow-same-namespace

Copy to clipboard

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

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。

5.3.4. ネットワークポリシーの編集

admin ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。

5.3.4.1. ネットワークポリシーの編集

namespace のネットワークポリシーを編集できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを編集できます。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

オプション: namespace のネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to clipboardCopied
ここでは、以下のようになります。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトを編集します。
- ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
```
oc apply -n <namespace> -f <policy_file>.yaml
```
```
$ oc apply -n <namespace> -f <policy_file>.yaml
```
  Copy to clipboardCopied
  ここでは、以下のようになります。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  <policy_file>
  ネットワークポリシーを含むファイルの名前を指定します。
- ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
```
oc edit networkpolicy <policy_name> -n <namespace>
```
```
$ oc edit networkpolicy <policy_name> -n <namespace>
```
  Copy to clipboardCopied
  ここでは、以下のようになります。
  <policy_name>
  ネットワークポリシーの名前を指定します。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトが更新されていることを確認します。
```
oc describe networkpolicy <policy_name> -n <namespace>
```
```
$ oc describe networkpolicy <policy_name> -n <namespace>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。

5.3.4.2. サンプル NetworkPolicy オブジェクト

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 1
spec:
  podSelector: 2
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 3
        matchLabels:
          app: app
    ports: 4
    - protocol: TCP
      port: 27017

Copy to clipboard

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

5.3.4.3. 関連情報

ネットワークポリシーの作成

5.3.5. ネットワークポリシーの削除

admin ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。

5.3.5.1. CLI を使用したネットワークポリシーの削除

namespace のネットワークポリシーを削除できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを削除できます。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
```
oc delete networkpolicy <policy_name> -n <namespace>
```
```
$ oc delete networkpolicy <policy_name> -n <namespace>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
networkpolicy.networking.k8s.io/default-deny deleted
```
```
networkpolicy.networking.k8s.io/default-deny deleted
```
Copy to clipboardCopied

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。

5.3.6. プロジェクトのデフォルトネットワークポリシーの定義

クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。

5.3.6.1. 新規プロジェクトのテンプレートの変更

クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成できます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

前提条件

cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

cluster-admin 権限を持つユーザーとしてログインします。

デフォルトのプロジェクトテンプレートを生成します。

oc adm create-bootstrap-project-template -o yaml > template.yaml

$ oc adm create-bootstrap-project-template -o yaml > template.yaml

Copy to clipboard

オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。
プロジェクトテンプレートは、openshift-config namespace に作成する必要があります。変更したテンプレートを読み込みます。
```
oc create -f template.yaml -n openshift-config
```
```
$ oc create -f template.yaml -n openshift-config
```
Copy to clipboardCopied
Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。
- Web コンソールの使用
  1. Administration → Cluster Settings ページに移動します。
  2. Configuration をクリックし、すべての設定リソースを表示します。
  3. Project のエントリーを見つけ、Edit YAML をクリックします。
- CLI の使用
  1. project.config.openshift.io/cluster リソースを編集します。
    $ oc edit project.config.openshift.io/cluster
    Copy to clipboard
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 clipboardCopied
変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

5.3.6.2. 新規プロジェクトへのネットワークポリシーの追加

クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy オブジェクトを自動的に作成します。

前提条件

クラスターが、NetworkPolicy オブジェクトをサポートするデフォルトの CNI ネットワークプラグイン (OVN-Kubernetes など) を使用している。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインする。
新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成している。

手順

以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。
```
oc edit template <project_template> -n openshift-config
```
```
$ oc edit template <project_template> -n openshift-config
```
Copy to clipboardCopied
<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

オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
1. 新規プロジェクトを作成します。
```
oc new-project <project> 1
```
```
$ oc new-project <project> 1
```
  Copy to clipboardCopied
  1
  <project> を、作成しているプロジェクトの名前に置き換えます。
2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
```
oc get networkpolicy
```
```
$ oc get networkpolicy
NAME                           POD-SELECTOR   AGE
allow-from-openshift-ingress   <none>         7s
allow-from-same-namespace      <none>         7s
```
  Copy to clipboardCopied

5.3.7. ネットワークポリシーを使用したマルチテナント分離の設定

クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。

注記

このセクションで説明するようにネットワークポリシーを設定すると、以前のバージョンの OpenShift Container Platform における OpenShift SDN のマルチテナントモードと同様のネットワーク分離が実現します。

5.3.7.1. ネットワークポリシーを使用したマルチテナント分離の設定

他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。

前提条件

クラスターが、mode: NetworkPolicy が設定された NetworkPolicy オブジェクトをサポートするネットワークプラグイン (OVN-Kubernetes ネットワークプラグインなど) を使用している。
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

注記

policy-group.network.openshift.io/Ingress: "" は、OVN-Kubernetes の推奨される 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

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

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

詳細は、新規の New kube-apiserver-operator webhook controller validating health of webhook を参照してください。

オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。

oc describe networkpolicy

$ oc describe networkpolicy

Copy to clipboard

出力例

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

5.3.7.2. 次のステップ

プロジェクトのデフォルトネットワークポリシーの定義

5.4. ネットワークセキュリティーの監査ロギング

OVN-Kubernetes ネットワークプラグインは、Open Virtual Network (OVN) アクセス制御リスト (ACL) を使用して、AdminNetworkPolicy、BaselineAdminNetworkPolicy、NetworkPolicy、および EgressFirewall オブジェクトを管理します。監査ログは、NetworkPolicy、EgressFirewall、および BaselineAdminNetworkPolicy カスタムリソース (CR) の allow および deny ACL イベントを公開します。ロギングは、AdminNetworkPolicy (ANP) CR の allow、deny、pass ACL イベントも公開します。

注記

監査ログは、OVN-Kubernetes ネットワークプラグインでのみ使用できます。

5.4.1. 監査設定

監査ロギングの設定は、OVN-Kubernetes クラスターネットワークプロバイダー設定の一部として指定されます。次の YAML は、監査ログのデフォルト値を示しています。

監査ロギング設定

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to clipboard

次の表では、監査ログの設定フィールドを説明します。

表5.1 policyAuditConfig オブジェクト
フィールド	型	説明
`rateLimit`	integer	ノードごとに毎秒生成されるメッセージの最大数。デフォルト値は、1 秒あたり `20` メッセージです。
`maxFileSize`	integer	監査ログの最大サイズ (バイト単位)。デフォルト値は `50000000` (50MB) です。
`maxLogFiles`	integer	保持されるログファイルの最大数。
`比較先`	string	以下の追加の監査ログターゲットのいずれかになります。 `libc` ホスト上の journald プロセスの libc `syslog()` 関数。 `udp:<host>:<port>` syslog サーバー。`<host>:<port>` を syslog サーバーのホストおよびポートに置き換えます。 `unix:<file>` `<file>` で指定された Unix ドメインソケットファイル。 `null` 監査ログを追加のターゲットに送信しないでください。
`syslogFacility`	string	RFC5424 で定義される `kern` などの syslog ファシリティー。デフォルト値は `local0` です。

5.4.2. 監査ロギング

syslog サーバーや UNIX ドメインソケットなど、監査ログの宛先を設定できます。追加の設定に関係なく、監査ログは常にクラスター内の各 OVN-Kubernetes Pod の /var/log/ovn/acl-audit-log.log に保存されます。

各 namespace 設定に k8s.ovn.org/acl-logging セクションをアノテーション付けすることで、各 namespace の監査ログを有効にできます。k8s.ovn.org/acl-logging セクションでは、namespace の監査ログを有効にするために、allow、deny、またはその両方の値を指定する必要があります。

注記

ネットワークポリシーでは、Pass アクションセットをルールとして設定することはサポートされていません。

ACL ロギング実装は、ネットワークのアクセス制御リスト (ACL) イベントをログに記録します。これらのログを表示して、潜在的なセキュリティー問題を分析できます。

namespace アノテーションの例

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

Copy to clipboard

デフォルトの ACL ロギング設定値を表示するには、cluster-network-03-config.yml ファイルの policyAuditConfig オブジェクトを参照してください。必要に応じて、このファイル内のログファイルパラメーターの ACL ロギング設定値を変更できます。

ログメッセージの形式は、RFC5424 で定義されている syslog と互換性があります。syslog ファシリティーは設定可能です。デフォルトは local0 です。次の例は、ログメッセージに出力される主要なパラメーターとその値を示しています。

パラメーターとその値を出力するロギングメッセージの例

<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>

<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>

Copy to clipboard

ここでは、以下のようになります。

<timestamp> は、ログメッセージが作成された日時を示します。
<message_serial> には、ログメッセージのシリアル番号がリストされます。
acl_log (ovn_pinctrl0) は、OVN-Kubernetes プラグイン内のログメッセージの場所を出力するリテラル文字列です。
<severity> は、ログメッセージの重大度レベルを設定します。allow タスクと deny タスクをサポートする監査ログを有効にすると、ログメッセージ出力に 2 つの重大度レベルが表示されます。
<name> は、ネットワークポリシーによって作成された OVN ネットワークブリッジングデータベース (nbdb) 内の ACL ロギング実装の名前を示します。
<verdict> は、allow または drop のいずれかになります。
<direction> は、to-lport または from-lport のいずれかで、ポリシーが Pod に向かうトラフィックまたは Pod から出るトラフィックに適用されたことを示します。
<flow> は、OpenFlow プロトコルと同等の形式でパケット情報を表示します。このパラメーターは Open vSwitch (OVS) フィールドで構成されます。

次の例は、flow パラメーターがシステムメモリーからパケット情報を抽出するために使用する OVS フィールドを示しています。

flow パラメーターがパケット情報を抽出するために使用する OVS フィールドの例

<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>

<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>

Copy to clipboard

ここでは、以下のようになります。

<proto> はプロトコルを指定します。有効な値は tcp と udp です。
vlan_tci=0x0000 は、内部 Pod ネットワークトラフィックに VLAN ID が設定されていないため、VLAN ヘッダーを 0 として示します。
<src_mac> は、メディアアクセス制御 (MAC) アドレスのソースを指定します。
<source_mac> は、MAC アドレスの宛先を指定します。
<source_ip> は、送信元 IP アドレスをリストします
<target_ip> は、ターゲット IP アドレスをリストします。
<tos_dscp> は、特定のネットワークトラフィックを他のトラフィックよりも分類して優先順位を付ける差別化サービスコードポイント (DSCP) 値を指定します。
<tos_ecn> は、ネットワーク内の輻輳したトラフィックを示す明示的輻輳通知 (ECN) 値を示します。
<ip_ttl> は、パケットの Time To Live (TTP) 情報を示します。
<fragment> は、一致させる IP フラグメントまたは IP 非フラグメントのタイプを指定します。
<tcp_src_port> は、TCP および UDP プロトコルのポートのソースを示します。
<tcp_dst_port> は、TCP および UDP プロトコルの宛先ポートをリストします。
<tcp_flags> は、SYN、ACK、PSH などの多数のフラグをサポートします。複数の値を設定する必要がある場合は、各値を縦棒 (|) で区切ります。UDP プロトコルはこのパラメーターをサポートしていません。

注記

以前のフィールドの説明の詳細は、OVS の man ページの ovs-fields を参照してください。

ネットワークポリシーの ACL 拒否ログエントリーの例

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn

Copy to clipboard

以下の表は、namespace アノテーションの値を説明しています。

表5.2 k8s.ovn.org/acl-logging の監査ロギング namespace アノテーション
フィールド	説明
`deny`	`deny` アクションを含む ACL ルールに一致するすべてのトラフィックへの namespace アクセスをブロックします。このフィールドは、`alert`、`warning`、`notice`、`info`、または `debug` の値をサポートします。
`allow`	`allow` アクションを含む ACL ルールに一致するすべてのトラフィックへの namespace アクセスを許可します。このフィールドは、`alert`、`warning`、`notice`、`info`、または `debug` の値をサポートします。
`pass`	`pass` アクションは、管理ネットワークポリシーの ACL ルールに適用されます。`pass` アクションにより、namespace 内のネットワークポリシーまたはベースライン管理ネットワークポリシールールのいずれかを使用して、すべての受信トラフィックと送信トラフィックを評価できます。ネットワークポリシーは `pass` アクションをサポートしていません。

関連情報

ネットワークポリシー API について

5.4.3. AdminNetworkPolicy 監査ログ

監査ロギングは、次の例のように、ANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けることにより、AdminNetworkPolicy CR ごとに有効になります。

例5.19 AdminNetworkPolicy CR のアノテーションの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert", "pass" : "warning" }'
  name: anp-tenant-log
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        tenant: backend-storage # Selects all pods owned by storage tenant.
  ingress:
    - name: "allow-all-ingress-product-development-and-customer" # Product development and customer tenant ingress to backend storage.
      action: "Allow"
      from:
      - pods:
          namespaceSelector:
            matchExpressions:
            - key: tenant
              operator: In
              values:
              - product-development
              - customer
          podSelector: {}
    - name: "pass-all-ingress-product-security"
      action: "Pass"
      from:
      - namespaces:
          matchLabels:
              tenant: product-security
    - name: "deny-all-ingress" # Ingress to backend from all other pods in the cluster.
      action: "Deny"
      from:
      - namespaces: {}
  egress:
    - name: "allow-all-egress-product-development"
      action: "Allow"
      to:
      - pods:
          namespaceSelector:
            matchLabels:
              tenant: product-development
          podSelector: {}
    - name: "pass-egress-product-security"
      action: "Pass"
      to:
      - namespaces:
           matchLabels:
             tenant: product-security
    - name: "deny-all-egress" # Egress from backend denied to all other pods.
      action: "Deny"
      to:
      - namespaces: {}

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert", "pass" : "warning" }'
  name: anp-tenant-log
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        tenant: backend-storage # Selects all pods owned by storage tenant.
  ingress:
    - name: "allow-all-ingress-product-development-and-customer" # Product development and customer tenant ingress to backend storage.
      action: "Allow"
      from:
      - pods:
          namespaceSelector:
            matchExpressions:
            - key: tenant
              operator: In
              values:
              - product-development
              - customer
          podSelector: {}
    - name: "pass-all-ingress-product-security"
      action: "Pass"
      from:
      - namespaces:
          matchLabels:
              tenant: product-security
    - name: "deny-all-ingress" # Ingress to backend from all other pods in the cluster.
      action: "Deny"
      from:
      - namespaces: {}
  egress:
    - name: "allow-all-egress-product-development"
      action: "Allow"
      to:
      - pods:
          namespaceSelector:
            matchLabels:
              tenant: product-development
          podSelector: {}
    - name: "pass-egress-product-security"
      action: "Pass"
      to:
      - namespaces:
           matchLabels:
             tenant: product-security
    - name: "deny-all-egress" # Egress from backend denied to all other pods.
      action: "Deny"
      to:
      - namespaces: {}

Copy to clipboard

特定の OVN ACL に該当し、ロギングアノテーションで設定されたアクション基準を満たすたびに、ログが生成されます。たとえば、ラベルが tenant: product-development の namespace のいずれかが tenant: backend-storage のラベルが付いた namespace にアクセスするイベントでは、ログが生成されます。

注記

ACL ロギングは 60 文字に制限されます。ANP 名 フィールドが長い場合、ログの残りの部分は切り捨てられます。

以下は、ログエントリーの例の方向インデックスです。

方向	ルール
Ingress	Rule0 `product-development` および `customer` のテナントから `backend-storage` テナントの Ingress を許可する、Ingress0: `Allow` Rule1 product-security` から `backend-storage テナントの Ingress を通過させる、Ingress1: `Pass` Rule2 全 Pod からの Ingress を拒否する、Ingress2: `Deny`
Egress	Rule0 `product-development` への Egress を許可する、Egress0: `Allow` Rule1 `product-security` への Egress を通過させる、Egress1: `Pass` Rule2 その他の Pod すべてへの Egress を拒否する、Egress2: `Deny`

例5.20 Ingress:0 および Egress:0 の anp-tenant-log という名前の AdminNetworkPolicy の 許可 アクションの ACL ログエントリーの例

2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack

2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack

Copy to clipboard

例5.21 Ingress:1 および Egress:1 を持つ anp-tenant-log という名前の AdminNetworkPolicy の Pass アクションの ACL ログエントリーの例

2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack

2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack

Copy to clipboard

例5.22 Egress:2 および Ingress2 を持つ anp-tenant-log という名前の AdminNetworkPolicy の deny アクションの ACL ログエントリーの例

2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn

2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn

Copy to clipboard

次の表は、ANP アノテーションを説明しています。

表5.3 監査ログの AdminNetworkPolicy アノテーション
アノテーション	値
`k8s.ovn.org/acl-logging`	namespace の監査ログを有効にするには、`Allow`、`Deny`、または `Pass` を指定する必要があります。 `Deny` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。 `Allow` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。 `Pass` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。

5.4.4. BaselineAdminNetworkPolicy 監査ログ

監査ロギングは、次の例のように、BANP ポリシーに k8s.ovn.org/acl-logging キーのアノテーションを付けすることで、BaselineAdminNetworkPolicy CR で有効になります。

例5.23 BaselineAdminNetworkPolicy CR のアノテーションの例

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert"}'
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
          tenant: workloads # Selects all workload pods in the cluster.
  ingress:
  - name: "default-allow-dns" # This rule allows ingress from dns tenant to all workloads.
    action: "Allow"
    from:
    - namespaces:
          matchLabels:
            tenant: dns
  - name: "default-deny-dns" # This rule denies all ingress from all pods to workloads.
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "default-deny-dns" # This rule denies all egress from workloads. It will be applied when no ANP or network policy matches.
    action: "Deny"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert"}'
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
          tenant: workloads # Selects all workload pods in the cluster.
  ingress:
  - name: "default-allow-dns" # This rule allows ingress from dns tenant to all workloads.
    action: "Allow"
    from:
    - namespaces:
          matchLabels:
            tenant: dns
  - name: "default-deny-dns" # This rule denies all ingress from all pods to workloads.
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "default-deny-dns" # This rule denies all egress from workloads. It will be applied when no ANP or network policy matches.
    action: "Deny"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.

Copy to clipboard

この例では、ラベルが tenant: dns の namespace のいずれかが tenant: workloads ラベルを持つ namespace にアクセスするイベントで、ログが生成されます。

以下は、ログエントリーの例の方向インデックスです。

方向	ルール
Ingress	Rule0 `dns` テナントから `workloads` テナントへの Ingress を許可する、Ingress0: `Allow` Rule1 全 Pod から `workloads` テナントへの Ingress を拒否する、Ingress1: `Deny`
Egress	Rule0 すべての Pod への Egress を拒否する、Egress0: `Deny`

例5.24 Ingress:0 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例

2024-06-10T18:11:58.263Z|00022|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=syn
2024-06-10T18:11:58.264Z|00023|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=psh|ack
2024-06-10T18:11:58.264Z|00024|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00025|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00026|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=fin|ack
2024-06-10T18:11:58.264Z|00027|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack

2024-06-10T18:11:58.263Z|00022|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=syn
2024-06-10T18:11:58.264Z|00023|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=psh|ack
2024-06-10T18:11:58.264Z|00024|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00025|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00026|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=fin|ack
2024-06-10T18:11:58.264Z|00027|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack

Copy to clipboard

例5.25 Egress:0 および Ingress:1 での default BANP の Allow アクションに関する ACL 許可ログエントリーの例

2024-06-10T18:09:57.774Z|00016|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:09:58.809Z|00017|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:00.857Z|00018|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:25.414Z|00019|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:26.457Z|00020|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:28.505Z|00021|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn

2024-06-10T18:09:57.774Z|00016|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:09:58.809Z|00017|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:00.857Z|00018|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:25.414Z|00019|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:26.457Z|00020|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:28.505Z|00021|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn

Copy to clipboard

次の表では、BANP アノテーションを説明します。

表5.4 監査ログの BaselineAdminNetworkPolicy アノテーション
アノテーション	値
`k8s.ovn.org/acl-logging`	namespace の監査ロギングを有効にするには、少なくとも `Allow` または `Deny` のいずれかを指定する必要があります。 `Deny` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。 `Allow` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。

5.4.5. クラスターの Egress ファイアウォールとネットワークポリシー監査の設定

クラスター管理者は、クラスターの監査ログをカスタマイズできます。

前提条件

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

手順

監査ロギング設定をカスタマイズするには、次のコマンドを入力します。

oc edit network.operator.openshift.io/cluster

$ oc edit network.operator.openshift.io/cluster

Copy to clipboard

ヒント

または、以下の YAML をカスタマイズして適用することで、監査ロギングを設定できます。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to clipboard

検証

ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。

検証用の namespace を作成します。

cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

$ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

Copy to clipboard

出力例

namespace/verify-audit-logging created

namespace/verify-audit-logging created

Copy to clipboard

namespace のネットワークポリシーを作成します。

cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: verify-audit-logging
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: verify-audit-logging
EOF

$ cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: verify-audit-logging
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: verify-audit-logging
EOF

Copy to clipboard

出力例

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

Copy to clipboard

ソーストラフィックの Pod を default namespace に作成します。

cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

$ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

Copy to clipboard

verify-audit-logging namespace に 2 つの Pod を作成します。

for name in client server; do

$ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

Copy to clipboard

出力例

pod/client created
pod/server created

pod/client created
pod/server created

Copy to clipboard

トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。

verify-audit-logging namespace で server という名前の Pod の IP アドレスを取得します。

POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

Copy to clipboard

default の namespace の client という名前の Pod の直前のコマンドから IP アドレスに ping し、すべてのパケットがドロップされていることを確認します。

oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

Copy to clipboard

出力例

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

Copy to clipboard

verify-audit-logging namespace の client という名前の Pod から POD_IP シェル環境変数に保存されている IP アドレスに ping し、すべてのパケットが許可されていることを確認します。

oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

Copy to clipboard

出力例

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

Copy to clipboard

ネットワークポリシー監査ログの最新エントリーを表示します。

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to clipboard

出力例

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

Copy to clipboard

5.4.6. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを有効にする

クラスター管理者は、namespace の監査ログを有効にすることができます。

前提条件

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

手順

namespace の監査ログを有効にするには、次のコマンドを入力します。

oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

$ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

Copy to clipboard

ここでは、以下のようになります。

<namespace>: namespace の名前を指定します。

ヒント

または、以下の YAML を適用して監査ロギングを有効化できます。

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

Copy to clipboard

出力例

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to clipboard

検証

監査ログの最新のエントリーを表示します。

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to clipboard

出力例

2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0

Copy to clipboard

5.4.7. namespace の Egress ファイアウォールとネットワークポリシーの監査ログを無効にする

クラスター管理者は、namespace の監査ログを無効にすることができます。

前提条件

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

手順

namespace の監査ログを無効にするには、次のコマンドを入力します。

oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-

$ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-

Copy to clipboard

ここでは、以下のようになります。

<namespace>: namespace の名前を指定します。

ヒント

または、以下の YAML を適用して監査ロギングを無効化できます。

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null

Copy to clipboard

出力例

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to clipboard

5.4.8. 関連情報

ネットワークポリシーについて
プロジェクトの Egress ファイアウォールの設定

5.5. Egress ファイアウォール

5.5.1. プロジェクトの Egress ファイアウォールの表示

クラスター管理者は、既存の egress ファイアウォールの名前をリスト表示し、特定の egress ファイアウォールのトラフィックルールを表示できます。

5.5.1.1. EgressFirewall オブジェクトの表示

クラスターで EgressFirewall オブジェクトを表示できます。

前提条件

OVN-Kubernetes ネットワークプラグインを使用するクラスター。
oc として知られる OpenShift コマンドラインインターフェイス (CLI) のインストール。
クラスターにログインすること。

手順

オプション: クラスターで定義された EgressFirewall オブジェクトの名前を表示するには、以下のコマンドを入力します。
```
oc get egressfirewall --all-namespaces
```
```
$ oc get egressfirewall --all-namespaces
```
Copy to clipboardCopied

ポリシーを検査するには、以下のコマンドを入力します。<policy_name> を検査するポリシーの名前に置き換えます。

oc describe egressfirewall <policy_name>

$ oc describe egressfirewall <policy_name>

Copy to clipboard

出力例

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0

Copy to clipboard

5.5.2. プロジェクトの Egress ファイアウォールの編集

クラスター管理者は、既存の Egress ファイアウォールのネットワークトラフィックルールを変更できます。

5.5.2.1. EgressFirewall オブジェクトの編集

クラスター管理者は、プロジェクトの Egress ファイアウォールを更新できます。

前提条件

OVN-Kubernetes ネットワークプラグインを使用するクラスター。
OpenShift CLI (oc) がインストールされている。
クラスター管理者としてクラスターにログインする必要があります。

手順

プロジェクトの EgressFirewall オブジェクトの名前を検索します。<project> をプロジェクトの名前に置き換えます。
```
oc get -n <project> egressfirewall
```
```
$ oc get -n <project> egressfirewall
```
Copy to clipboardCopied
オプション: Egress ネットワークファイアウォールの作成時に EgressFirewall オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。
```
oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
```
```
$ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
```
Copy to clipboardCopied
<project> をプロジェクトの名前に置き換えます。<name> をオブジェクトの名前に置き換えます。<filename> をファイルの名前に置き換え、YAML を保存します。
ポリシールールに変更を加えたら、以下のコマンドを実行して EgressFirewall オブジェクトを置き換えます。<filename> を、更新された EgressFirewall オブジェクトを含むファイルの名前に置き換えます。
```
oc replace -f <filename>.yaml
```
```
$ oc replace -f <filename>.yaml
```
Copy to clipboardCopied

5.5.3. プロジェクトからの Egress ファイアウォールの削除

クラスター管理者は、プロジェクトから Egress ファイアウォールを削除して、OpenShift Container Platform クラスター外に出るプロジェクトからネットワークトラフィックに対するすべての制限を削除できます。

5.5.3.1. EgressFirewall オブジェクトの削除

クラスター管理者は、プロジェクトから Egress ファイアウォールを削除できます。

前提条件

OVN-Kubernetes ネットワークプラグインを使用するクラスター。
OpenShift CLI (oc) がインストールされている。
クラスター管理者としてクラスターにログインする必要があります。

手順

プロジェクトの EgressFirewall オブジェクトの名前を検索します。<project> をプロジェクトの名前に置き換えます。
```
oc get -n <project> egressfirewall
```
```
$ oc get -n <project> egressfirewall
```
Copy to clipboardCopied
以下のコマンドを入力し、EgressFirewall オブジェクトを削除します。<project> をプロジェクトの名前に、<name> をオブジェクトの名前に置き換えます。
```
oc delete -n <project> egressfirewall <name>
```
```
$ oc delete -n <project> egressfirewall <name>
```
Copy to clipboardCopied

5.5.4. プロジェクトの Egress ファイアウォールの設定

クラスター管理者は、OpenShift Container Platform クラスター外に出るプロジェクトのプロジェクについて、Egress トラフィックを制限する Egress ファイアウォールを作成できます。

5.5.4.1. Egress ファイアウォールのプロジェクトでの機能

クラスター管理者は、Egress ファイアウォール を使用して、一部またはすべての Pod がクラスター内からアクセスできる外部ホストを制限できます。Egress ファイアウォールポリシーは以下のシナリオをサポートします。

Pod の接続を内部ホストに制限し、パブリックインターネットへの接続を開始できないようにする。
Pod の接続をパブリックインターネットに制限し、OpenShift Container Platform クラスター外にある内部ホストへの接続を開始できないようにする。
Pod は OpenShift Container Platform クラスター外の指定された内部サブネットまたはホストにアクセスできません。
Pod は特定の外部ホストにのみ接続することができます。

たとえば、指定された IP 範囲へのあるプロジェクトへのアクセスを許可する一方で、別のプロジェクトへの同じアクセスを拒否することができます。または、アプリケーション開発者の (Python) pip mirror からの更新を制限したり、更新を承認されたソースからの更新のみに強制的に制限したりすることができます。

注記

Egress ファイアウォールは、ホストネットワークの namespace には適用されません。ホストネットワークが有効になっている Pod は、Egress ファイアウォールルールの影響を受けません。

EgressFirewall カスタムリソース (CR) オブジェクトを作成して Egress ファイアウォールポリシーを設定します。Egress ファイアウォールは、以下のいずれかの基準を満たすネットワークトラフィックと一致します。

CIDR 形式の IP アドレス範囲。
IP アドレスに解決する DNS 名
ポート番号
プロトコル。TCP、UDP、および SCTP のいずれかになります。

重要

Egress ファイアウォールに 0.0.0.0/0 の拒否ルールが含まれる場合、OpenShift Container Platform API サーバーへのアクセスはブロックされます。API サーバーに接続するには、IP アドレスごとに許可ルールを追加するか、Egress ポリシールールで nodeSelector タイプの許可ルールを使用する必要があります。

次の例は、API サーバーへのアクセスを確保するために必要な Egress ファイアウォールルールの順序を示しています。

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace> 1
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 2
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 3
    type: Deny

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace> 1
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 2
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 3
    type: Deny

Copy to clipboard

1: Egress ファイアウォールの namespace。
2: OpenShift Container Platform API サーバーを含む IP アドレス範囲。
3: グローバル拒否ルールにより、OpenShift Container Platform API サーバーへのアクセスが阻止されます。

API サーバーの IP アドレスを見つけるには、oc get ep kubernetes -n default を実行します。

詳細は、BZ#1988324 を参照してください。

警告

Egress ファイアウォールルールは、ルーターを通過するトラフィックには適用されません。ルート CR オブジェクトを作成するパーミッションを持つユーザーは、禁止されている宛先を参照するルートを作成することにより、Egress ファイアウォールポリシールールをバイパスできます。

5.5.4.1.1. Egress ファイアウォールの制限

Egress ファイアウォールには以下の制限があります。

複数の EgressFirewall オブジェクトを持つプロジェクトはありません。
最大 8,000 のルールを持つ最大 1 つの EgressFirewall オブジェクトはプロジェクトごとに定義できます。
Red Hat OpenShift Networking の共有ゲートウェイモードで OVN-Kubernetes ネットワークプラグインを使用している場合に、リターン Ingress 応答は Egress ファイアウォールルールの影響を受けます。送信ファイアウォールルールが受信応答宛先 IP をドロップすると、トラフィックはドロップされます。

これらの制限のいずれかに違反すると、プロジェクトの Egress ファイアウォールが壊れます。その結果、すべての外部ネットワークトラフィックがドロップされ、組織にセキュリティーリスクが生じる可能性があります。

Egress ファイアウォールリソースは、kube-node-lease、kube-public、kube-system、openshift、openshift- プロジェクトで作成できます。

5.5.4.1.2. Egress ポリシールールのマッチング順序

Egress ファイアウォールポリシールールは、最初から最後へと定義された順序で評価されます。Pod からの Egress 接続に一致する最初のルールが適用されます。この接続では、後続のルールは無視されます。

5.5.4.1.3. DNS (Domain Name Server) 解決の仕組み

Egress ファイアウォールポリシールールのいずれかで DNS 名を使用する場合、ドメイン名の適切な解決には、以下の制限が適用されます。

ドメイン名の更新は、Time-to-Live (TTL) 期間に基づいてポーリングされます。デフォルトで、期間は 30 分です。Egress ファイアウォールコントローラーがローカルネームサーバーでドメイン名をクエリーする場合に、応答に 30 分未満の TTL が含まれる場合、コントローラーは DNS 名の期間を返される値に設定します。それぞれの DNS 名は、DNS レコードの TTL の期限が切れた後にクエリーされます。
Pod は、必要に応じて同じローカルネームサーバーからドメインを解決する必要があります。そうしない場合、Egress ファイアウォールコントローラーと Pod によって認識されるドメインの IP アドレスが異なる可能性があります。ホスト名の IP アドレスが異なる場合、Egress ファイアウォールは一貫して実行されないことがあります。
Egress ファイアウォールコントローラーおよび Pod は同じローカルネームサーバーを非同期にポーリングするため、Pod は Egress コントローラーが実行する前に更新された IP アドレスを取得する可能性があります。これにより、競合状態が生じます。この現時点の制限により、EgressFirewall オブジェクトのドメイン名の使用は、IP アドレスの変更が頻繁に生じないドメインの場合にのみ推奨されます。

注記

Egress ファイアウォールポリシーで DNS 名を使用しても、CoreDNS を介したローカル DNS 解決には影響しません。

ただし、Egress ファイアウォールポリシーでドメイン名を使用し、外部 DNS サーバーで関連する Pod の DNS 解決を処理する場合は、DNS サーバーの IP アドレスへのアクセスを許可する Egress ファイアウォールルールを含める必要があります。

5.5.4.1.3.1. DNS 解決とワイルドカードドメイン名の解決の改善

DNS レコードに関連付けられた IP アドレスが頻繁に変更される場合や、Egress ファイアウォールポリシールールでワイルドカードドメイン名を指定する必要がある場合もあります。

このような状況では、OVN-Kubernetes クラスターマネージャーは、Egress ファイアウォールポリシールールで使用される一意の DNS 名ごとに DNSNameResolver カスタムリソースオブジェクトを作成します。このカスタムリソースには次の情報が保存されます。

重要

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

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

DNSNameResolver CR 定義の例

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com. 1
status:
  resolvedNames:
  - dnsName: www.example.com. 2
    resolvedAddress:
    - ip: "1.2.3.4" 3
      ttlSeconds: 60 4
      lastLookupTime: "2023-08-08T15:07:04Z" 5

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com. 1
status:
  resolvedNames:
  - dnsName: www.example.com. 2
    resolvedAddress:
    - ip: "1.2.3.4" 3
      ttlSeconds: 60 4
      lastLookupTime: "2023-08-08T15:07:04Z" 5

Copy to clipboard

1: DNS 名。これは、標準の DNS 名またはワイルドカード DNS 名のいずれかになります。ワイルドカード DNS 名の場合、DNS 名解決情報には、ワイルドカード DNS 名に一致するすべての DNS 名が含まれます。
2: spec.name フィールドに一致する解決された DNS 名。spec.name フィールドにワイルドカード DNS 名が含まれている場合、解決時にワイルドカード DNS 名と一致する標準 DNS 名を含む複数の dnsName エントリーが作成されます。ワイルドカード DNS 名も正常に解決できる場合は、このフィールドにはワイルドカード DNS 名も保存されます。
3: DNS 名に関連付けられている現在の IP アドレス。
4: 最後の Time-to-Live (TTL) 期間。
5: 最後のルックアップ時刻。

DNS 解決中に、クエリー内の DNS 名が DNSNameResolver CR で定義された名前と一致する場合、CR status フィールドで以前の情報がそれに応じて更新されます。DNS ワイルドカード名のルックアップが失敗した場合、デフォルトの TTL である 30 分後に要求が再試行されます。

OVN-Kubernetes クラスターマネージャーは、EgressFirewall カスタムリソースオブジェクトの更新を監視し、更新が発生すると、それらの Egress ファイアウォールポリシーに関連付けられた DNSNameResolver CR を作成、変更、または削除します。

警告

DNSNameResolver カスタムリソースを直接変更しないでください。これにより、Egress ファイアウォールの望ましくない動作が発生する可能性があります。

5.5.4.2. EgressFirewall カスタムリソース (CR) オブジェクト

Egress ファイアウォールのルールを 1 つ以上定義できます。ルールは、ルールが適用されるトラフィックを指定して Allow ルールまたは Deny ルールのいずれかになります。

以下の YAML は EgressFirewall CR オブジェクトを説明しています。

EgressFirewall オブジェクト

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

Copy to clipboard

1: オブジェクトの名前は default である必要があります。
2: 以下のセクションで説明されているように、Egress ネットワークポリシールールのコレクション。

5.5.4.2.1. EgressFirewall ルール

以下の YAML は Egress ファイアウォールルールオブジェクトを説明しています。ユーザーは、CIDR 形式の IP アドレス範囲またはドメイン名を選択するか、nodeSelector を使用して、送信トラフィックを許可または拒否できます。egress スタンザは、単一または複数のオブジェクトの配列を予想します。

Egress ポリシールールのスタンザ

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4
    nodeSelector: <label_name>: <label_value> 5
  ports: 6
      ...

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4
    nodeSelector: <label_name>: <label_value> 5
  ports: 6
      ...

Copy to clipboard

1: ルールのタイプ。値には Allow または Deny のいずれかを指定する必要があります。
2: cidrSelector フィールドまたは dnsName フィールドを指定する Egress トラフィックのマッチングルールを記述するスタンザ。同じルールで両方のフィールドを使用することはできません。
3: CIDR 形式の IP アドレス範囲。
4: DNS ドメイン名。
5: ラベルは、ユーザーが定義するキーと値のペアです。ラベルは Pod などのオブジェクトに添付されます。nodeSelector を使用すると、1 つ以上のノードラベルを選択して、Pod に添付できます。
6: オプション: ルールのネットワークポートおよびプロトコルのコレクションを記述するスタンザ。

ポートスタンザ

ports:
- port: <port> 1
  protocol: <protocol> 2

ports:
- port: <port> 1
  protocol: <protocol> 2

Copy to clipboard

1: 80 や 443 などのネットワークポート。このフィールドの値を指定する場合は、protocol の値も指定する必要があります。
2: ネットワークプロトコル。値は TCP、UDP、または SCTP のいずれかである必要があります。

5.5.4.2.2. EgressFirewall CR オブジェクトの例

以下の例では、複数の Egress ファイアウォールポリシールールを定義します。

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

Copy to clipboard

1: Egress ファイアウォールポリシールールオブジェクトのコレクション。

次の例では、トラフィックが TCP プロトコルおよび宛先ポート 80 または任意のプロトコルおよび宛先ポート 443 のいずれかを使用している場合に、IP アドレス 172.16.1.1/32 のホストへのトラフィックを拒否するポリシールールを定義します。

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1/32
    ports:
    - port: 80
      protocol: TCP
    - port: 443

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1/32
    ports:
    - port: 80
      protocol: TCP
    - port: 443

Copy to clipboard

5.5.4.2.3. EgressFirewall の nodeSelector の例

クラスター管理者は、nodeSelector を使用して、ラベルを指定することにより、クラスター内のノードへの Egress トラフィックを許可または拒否できます。ラベルは、1 つ以上のノードに適用できます。以下は、region=east ラベルを使用した例です。

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow

Copy to clipboard

ヒント

ノード IP アドレスごとに手動でルールを追加する代わりに、ノードセレクターを使用して、Egress ファイアウォールの背後にある Pod がホストネットワーク Pod にアクセスできるようにするラベルを作成します。

5.5.4.3. Egress ファイアウォールポリシーオブジェクトの作成

クラスター管理者は、プロジェクトの Egress ファイアウォールポリシーオブジェクトを作成できます。

重要

プロジェクトに EgressFirewall オブジェクトがすでに定義されている場合、既存のポリシーを編集して Egress ファイアウォールルールを変更する必要があります。

前提条件

OVN-Kubernetes ネットワークプラグインを使用するクラスター。
OpenShift CLI (oc) がインストールされている。
クラスター管理者としてクラスターにログインする必要があります。

手順

ポリシールールを作成します。
1. <policy_name>.yaml ファイルを作成します。この場合、<policy_name> は Egress ポリシールールを記述します。
2. 作成したファイルで、Egress ポリシーオブジェクトを定義します。
以下のコマンドを入力してポリシーオブジェクトを作成します。<policy_name> をポリシーの名前に、<project> をルールが適用されるプロジェクトに置き換えます。
```
oc create -f <policy_name>.yaml -n <project>
```
```
$ oc create -f <policy_name>.yaml -n <project>
```
Copy to clipboardCopied
以下の例では、新規の EgressFirewall オブジェクトが project1 という名前のプロジェクトに作成されます。
```
oc create -f default.yaml -n project1
```
```
$ oc create -f default.yaml -n project1
```
Copy to clipboardCopied
出力例
```
egressfirewall.k8s.ovn.org/v1 created
```
```
egressfirewall.k8s.ovn.org/v1 created
```
Copy to clipboardCopied
オプション: 後に変更できるように <policy_name>.yaml ファイルを保存します。

5.6. IPsec 暗号化の設定

IPsec を有効にすると、ノード間の内部 Pod 間のクラスタートラフィックと、Pod とクラスター外部の IPsec エンドポイント間の外部トラフィックの両方を暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、トランスポートモード の IPsec で暗号化されます。

IPsec はデフォルトで無効にされています。クラスターのインストール中またはインストール後に IPsec を有効にできます。クラスターのインストールの詳細は、OpenShift Container Platform インストールの概要を参照してください。

OpenShift Container Platform クラスター上の IPsec には次のサポート制限があります。

IBM Cloud® では、IPsec は NAT-T のみをサポートします。このプラットフォームでは、Encapsulating Security Payload (ESP) はサポートされていません。
クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、IPsec は、Pod 間のトラフィックや外部ホストへのトラフィックの IPsec 暗号化でサポートされません。
1 つ以上のネットワークインターフェイスが Open vSwitch (OVS) に接続されている場合、ネットワークインターフェイスでの ESP ハードウェアオフロードの使用はサポートされません。クラスターに対して IPsec を有効にすると、OVS に接続されたインターフェイスで IPsec が使用されるようになります。デフォルトでは、OpenShift Container Platform は、OVS に接続されたすべてのインターフェイスで ESP ハードウェアオフロードを無効にします。
OVS に接続されていないネットワークインターフェイスに対して IPsec を有効にした場合、クラスター管理者は、OVS に接続されていない各インターフェイスで ESP ハードウェアオフロードを手動で無効にする必要があります。
IPsec は Red Hat Enterprise Linux (RHEL) コンピュートノードではサポートされていません。これは、各コンピュートノードに存在するホストと ovn-ipsec コンテナー間の libreswan 非互換性の問題が原因です。(OCPBUGS-53316) を参照してください。

次のリストは、IPsec ドキュメントの主要なタスクの概要を示しています。

クラスターのインストール後に IPsec を有効または無効にする
クラスターと外部ホスト間のトラフィックの IPsec 暗号化を設定する
IPsec が異なるノード上の Pod 間のトラフィックを暗号化することを確認する

5.6.1. 動作モード

OpenShift Container Platform クラスターで IPsec を使用する場合、以下の動作モードから選択できます。

表5.5 IPsec の動作モード
Mode	説明	デフォルト
`Disabled`	トラフィックは暗号化されません。これはクラスターのデフォルトです。	はい
`Full`	Pod 間のトラフィックが、「Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ」の説明のとおりに暗号化されます。IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。	いいえ
`External`	IPsec に必要な設定手順を完了すると、外部ノードへのトラフィックを暗号化できます。	いいえ

5.6.2. 前提条件

外部ホストへのトラフィックを暗号化するために IPsec をサポートする場合は、次の前提条件が満たされていることを確認してください。

OVN-Kubernetes ネットワークプラグインが、ローカルゲートウェイモード (ovnKubernetesConfig.gatewayConfig.routingViaHost=true) で設定されている。
NMState Operator がインストールされている。この Operator は、IPsec 設定を指定するために必要です。詳細は、Kubernetes NMState Operator を参照してください。
注記
NMState Operator は、Google Cloud Platform (GCP) で IPsec を設定する場合にのみサポートされます。
ブタンツール (butane) がインストールされている。Butane をインストールするには、Butane のインストールを参照してください。

これらの前提条件は、証明書をホストの NSS データベースに追加するために、および外部ホストと通信するように IPsec を設定するために必要です。

5.6.3. IPsec が有効になっている場合のネットワーク接続要件

OpenShift Container Platform クラスターのコンポーネントが通信できるように、マシン間のネットワーク接続を設定する必要があります。すべてのマシンではクラスターの他のすべてのマシンのホスト名を解決できる必要があります。

表5.6 すべてのマシンからすべてのマシンへの通信に使用されるポート
プロトコル	ポート	説明
UDP	`500`	IPsec IKE パケット
UDP	`4500`	IPsec NAT-T パケット
ESP	該当なし	IPsec Encapsulating Security Payload (ESP)

5.6.4. Pod 間のトラフィックの IPsec 暗号化

Pod 間のトラフィックの IPsec 暗号化は、次のセクションで、暗号化される Pod 間のトラフィック、使用される暗号化プロトコルの種類、および X.509 証明書の処理の仕組みを説明します。以下のセクションは、クラスターと外部ホスト間の IPsec 暗号化には適用されません。この種の暗号化は、特定の外部ネットワークインフラストラクチャーに合わせて手動で設定する必要があります。

5.6.4.1. Pod 間の IPsec によって暗号化されるネットワークトラフィックフローのタイプ

IPsec を有効にすると、Pod 間の以下のネットワークトラフィックフローのみが暗号化されます。

クラスターネットワーク上の複数の異なるノードの Pod 間のトラフィック
ホストネットワークの Pod からクラスターネットワーク上の Pod へのトラフィック

以下のトラフィックフローは暗号化されません。

クラスターネットワーク上の同じノードの Pod 間のトラフィック
ホストネットワーク上の Pod 間のトラフィック
クラスターネットワークの Pod からホストネットワークの Pod へのトラフィック

暗号化されていないフローと暗号化されていないフローを以下の図に示します。

5.6.4.2. 暗号化プロトコルおよび IPsec モード

使用する暗号化は AES-GCM-16-256 です。整合性チェック値 (ICV) は 16 バイトです。鍵の長さは 256 ビットです。

使用される IPsec モードは トランスポートモード です。これは、元のパケットの IP ヘッダーに Encapsulated Security Payload (ESP) ヘッダーを追加してパケットデータを暗号化することで、エンドツーエンドの通信を暗号化するモードです。OpenShift Container Platform は現在、Pod 間通信に IPsec Tunnel モード を使用したり、サポートしたりしません。

5.6.4.3. セキュリティー証明書の生成およびローテーション

Cluster Network Operator (CNO) は、暗号化用に IPsec によって使用される自己署名の X.509 認証局 (CA) を生成します。各ノードの証明書署名要求 (CSR) は、CNO によって自動的に満たされます。

この CA は 10 年間有効です。個別のノード証明書は 5 年間有効で、4 年半が経過すると自動的にローテーションされます。

5.6.5. 外部トラフィックの IPsec 暗号化

OpenShift Container Platform は、TLS 証明書を使用した外部ホストへのトラフィックの IPsec 暗号化をサポートします。TLS 証明書は管理者が提供する必要があります。

5.6.5.1. サポート対象のプラットフォーム

この機能は次のプラットフォームでサポートされています。

ベアメタル
Google Cloud Platform (GCP)
Red Hat OpenStack Platform (RHOSP)
VMware vSphere

重要

Red Hat Enterprise Linux (RHEL) ワーカーノードがある場合、これらのプラットフォームは外部トラフィックの IPsec 暗号化をサポートしません。

クラスターが Red Hat OpenShift Container Platform の Hosted Control Plane を使用している場合、外部ホストへのトラフィックを暗号化するための IPsec の設定はサポートされません。

5.6.5.2. 制限事項

次の禁止事項が遵守されていることを確認してください。

外部トラフィックの IPsec を設定する場合、IPv6 設定は現在 NMState Operator によってサポートされません。
提供する証明書バンドル内の証明書共通名 (CN) には、接頭辞 ovs_ を指定できません。この名前は、各ノードのネットワークセキュリティーサービス (NSS) データベース内の Pod 間の IPsec CN 名と競合する可能性があるためです。

5.6.6. IPsec 暗号化の有効化

クラスター管理者は、Pod 間の IPsec 暗号化、クラスターと外部 IPsec エンドポイント間の IPsec 暗号化を有効にできます。

次のいずれかのモードで IPsec を設定できます。

Full: Pod 間のトラフィックおよび外部トラフィックの暗号化
External: 外部トラフィックの暗号化

注記

IPsec を Full モードで設定する場合は、「外部トラフィックの IPsec 暗号化の設定」手順も完了する必要があります。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
クラスター MTU のサイズを 46 バイト減らして、IPsec ESP ヘッダーにオーバーヘッドを設けている。

手順

IPsec 暗号化を有効にするには、次のコマンドを入力します。
```
oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
```
```
$ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"<mode"> 1
        }}}}}'
```
Copy to clipboardCopied
1
外部ホストへのトラフィックを暗号化するには External を指定します。Pod 間のトラフィックを暗号化し、必要に応じて外部ホストへのトラフィックを暗号化するには Full を指定します。デフォルトでは、IPsec は無効になっています。
「外部トラフィックの IPsec 暗号化の設定」手順を完了して、IPsec を使用して外部トラフィックを暗号化します。

検証

OVN-Kubernetes データプレーン Pod の名前を見つけるには、次のコマンドを入力します。

oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node

$ oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node

Copy to clipboard

出力例

ovnkube-node-5xqbf                       8/8     Running   0              28m
ovnkube-node-6mwcx                       8/8     Running   0              29m
ovnkube-node-ck5fr                       8/8     Running   0              31m
ovnkube-node-fr4ld                       8/8     Running   0              26m
ovnkube-node-wgs4l                       8/8     Running   0              33m
ovnkube-node-zfvcl                       8/8     Running   0              34m
...

ovnkube-node-5xqbf                       8/8     Running   0              28m
ovnkube-node-6mwcx                       8/8     Running   0              29m
ovnkube-node-ck5fr                       8/8     Running   0              31m
ovnkube-node-fr4ld                       8/8     Running   0              26m
ovnkube-node-wgs4l                       8/8     Running   0              33m
ovnkube-node-zfvcl                       8/8     Running   0              34m
...

Copy to clipboard

次のコマンドを実行して、クラスターで IPsec が有効になっていることを確認します。
注記
クラスター管理者は、IPsec が Full モードで設定されている場合に、クラスター上の Pod 間で IPsec が有効になっていることを確認できます。この手順では、クラスターと外部ホストの間で IPsec が機能しているかどうかは検証されません。
```
oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec 1
```
```
$ oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec 1
```
Copy to clipboardCopied
1
<XXXXX> には、上記ステップの Pod のランダムな文字シーケンスを指定します。
出力例
```
true
```
```
true
```
Copy to clipboardCopied

5.6.7. 外部トラフィックの IPsec 暗号化の設定

クラスター管理者は、IPsec を使用して外部トラフィックを暗号化するには、PKCS#12 証明書の提供を含め、ネットワークインフラストラクチャーに IPsec を設定する必要があります。この手順では Butane を使用してマシン設定を作成するため、butane コマンドがインストールされている必要があります。

注記

マシン設定を適用した後、Machine Config Operator はクラスター内の影響を受けるノードを再起動し、新しいマシン設定をロールアウトします。

前提条件

OpenShift CLI (oc) がインストールされている。
ローカルコンピューターに butane ユーティリティーがインストールされている。
NMState Operator がクラスターにインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
IPsec エンドポイント用の既存の PKCS#12 証明書と PEM 形式の CA 証明書があります。
クラスターで Full または External モードの IPsec が有効になっている。
OVN-Kubernetes ネットワークプラグインが、ローカルゲートウェイモード (ovnKubernetesConfig.gatewayConfig.routingViaHost=true) で設定されている。

手順

NMState Operator ノードネットワーク設定ポリシーを使用して IPsec 設定を作成します。詳細は、IPsec VPN 実装としての Libreswan を参照してください。

IPsec エンドポイントであるクラスターノードの IP アドレスを特定するために、次のコマンドを入力します。
```
oc get nodes
```
```
$ oc get nodes
```
Copy to clipboardCopied

次の例のように、NMState Operator のノードネットワーク設定ポリシーを含む ipsec-config.yaml という名前のファイルを作成します。NodeNetworkConfigurationPolicy オブジェクトの概要は、The Kubernetes NMState project を参照してください。

NMState IPsec トランスポート設定の例

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>" 1
  desiredState:
    interfaces:
    - name: <interface_name> 2
      type: ipsec
      libreswan:
        left: <cluster_node> 3
        leftid: '%fromcert'
        leftrsasigkey: '%cert'
        leftcert: left_server
        leftmodecfgclient: false
        right: <external_host> 4
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32 5
        ikev2: insist
        type: transport

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>" 1
  desiredState:
    interfaces:
    - name: <interface_name> 2
      type: ipsec
      libreswan:
        left: <cluster_node> 3
        leftid: '%fromcert'
        leftrsasigkey: '%cert'
        leftcert: left_server
        leftmodecfgclient: false
        right: <external_host> 4
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32 5
        ikev2: insist
        type: transport

Copy to clipboard

1: ポリシーを適用するホスト名を指定します。このホストは、IPsec 設定の左側のホストとして機能します。
2: ホスト上に作成するインターフェイスの名前を指定します。
3: クラスター側の IPsec トンネルを終端するクラスターノードのホスト名を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
4: 外部ホスト名 (host.example.com など) を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
5: 外部ホストの IP アドレス (10.1.2.3/32 など) を指定します。

NMState IPsec トンネル設定の例

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>" 1
  desiredState:
    interfaces:
    - name: <interface_name> 2
      type: ipsec
      libreswan:
        left: <cluster_node> 3
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftrsasigkey: '%cert'
        leftcert: left_server
        right: <external_host> 4
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32 5
        ikev2: insist
        type: tunnel

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>" 1
  desiredState:
    interfaces:
    - name: <interface_name> 2
      type: ipsec
      libreswan:
        left: <cluster_node> 3
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftrsasigkey: '%cert'
        leftcert: left_server
        right: <external_host> 4
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32 5
        ikev2: insist
        type: tunnel

Copy to clipboard

1: ポリシーを適用するホスト名を指定します。このホストは、IPsec 設定の左側のホストとして機能します。
2: ホスト上に作成するインターフェイスの名前を指定します。
3: クラスター側の IPsec トンネルを終端するクラスターノードのホスト名を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
4: 外部ホスト名 (host.example.com など) を指定します。この名前は、提供した PKCS#12 証明書の SAN [Subject Alternate Name] と一致する必要があります。
5: 外部ホストの IP アドレス (10.1.2.3/32 など) を指定します。

IPsec インターフェイスを設定するために、次のコマンドを入力します。
```
oc create -f ipsec-config.yaml
```
```
$ oc create -f ipsec-config.yaml
```
Copy to clipboardCopied

次の証明書ファイルを提供して、各ホストのネットワークセキュリティーサービス (NSS) データベースに追加します。これらのファイルは、後続の手順で Butane 設定の一部としてインポートされます。
- left_server.p12: IPsec エンドポイントの証明書バンドル
- ca.pem: 証明書に署名した認証局

証明書をクラスターに追加するためのマシン設定を作成します。

コントロールプレーンとワーカーノードの Butane 設定ファイルを作成するには、次のコマンドを入力します。

注記

設定ファイルで指定する Butane のバージョンは、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.18.0 です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

for role in master worker; do

$ for role in master worker; do
  cat >> "99-ipsec-${role}-endpoint-config.bu" <<-EOF
  variant: openshift
  version: 4.18.0
  metadata:
    name: 99-${role}-import-certs
    labels:
      machineconfiguration.openshift.io/role: $role
  systemd:
    units:
    - name: ipsec-import.service
      enabled: true
      contents: |
        [Unit]
        Description=Import external certs into ipsec NSS
        Before=ipsec.service

        [Service]
        Type=oneshot
        ExecStart=/usr/local/bin/ipsec-addcert.sh
        RemainAfterExit=false
        StandardOutput=journal

        [Install]
        WantedBy=multi-user.target
  storage:
    files:
    - path: /etc/pki/certs/ca.pem
      mode: 0400
      overwrite: true
      contents:
        local: ca.pem
    - path: /etc/pki/certs/left_server.p12
      mode: 0400
      overwrite: true
      contents:
        local: left_server.p12
    - path: /usr/local/bin/ipsec-addcert.sh
      mode: 0740
      overwrite: true
      contents:
        inline: |
          #!/bin/bash -e
          echo "importing cert to NSS"
          certutil -A -n "CA" -t "CT,C,C" -d /var/lib/ipsec/nss/ -i /etc/pki/certs/ca.pem
          pk12util -W "" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
          certutil -M -n "left_server" -t "u,u,u" -d /var/lib/ipsec/nss/
EOF
done

Copy to clipboard

前の手順で作成した Butane ファイルをマシン設定に変換するには、次のコマンドを入力します。

for role in master worker; do

$ for role in master worker; do
  butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml
done

Copy to clipboard

マシン設定をクラスターに適用するには、次のコマンドを入力します。
```
for role in master worker; do
```
```
$ for role in master worker; do
  oc apply -f 99-ipsec-${role}-endpoint-config.yaml
done
```
Copy to clipboardCopied
重要
Machine Config Operator (MCO) は各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。外部 IPsec 接続が使用可能になる前に、すべてのノードが更新されるまで待つ必要があります。
以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get mcp
```
```
$ oc get mcp
```
Copy to clipboardCopied
正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。
注記
デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
IPsec マシン設定が正常にロールアウトされたことを確認するために、次のコマンドを入力します。
1. IPsec マシン設定が作成されたことを確認します。
```
oc get mc | grep ipsec
```
```
$ oc get mc | grep ipsec
```
  Copy to clipboardCopied
  出力例
  80-ipsec-master-extensions 3.2.0 6d15h 80-ipsec-worker-extensions 3.2.0 6d15h
  Copy to clipboard
2. IPsec 拡張機能がコントロールプレーンノードに適用されていることを確認します。
```
oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
```
```
$ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
```
  Copy to clipboardCopied
  予想される出力
  2
  Copy to clipboard
3. IPsec 拡張機能がワーカーノードに適用されていることを確認します。
```
oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
```
```
$ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
```
  Copy to clipboardCopied
  予想される出力
  2
  Copy to clipboard

関連情報

nmstate IPsec API の詳細は、IPsec Encryption を参照してください。

5.6.8. 外部 IPsec エンドポイントの IPsec 暗号化の無効化

クラスター管理者は、外部ホストへの既存の IPsec トンネルを削除できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
クラスターで Full または External モードの IPsec が有効になっている。

手順

次の YAML を使用して、remove-ipsec-tunnel.yaml という名前のファイルを作成します。

kind: NodeNetworkConfigurationPolicy
apiVersion: nmstate.io/v1
metadata:
  name: <name>
spec:
  nodeSelector:
    kubernetes.io/hostname: <node_name>
  desiredState:
    interfaces:
    - name: <tunnel_name>
      type: ipsec
      state: absent

kind: NodeNetworkConfigurationPolicy
apiVersion: nmstate.io/v1
metadata:
  name: <name>
spec:
  nodeSelector:
    kubernetes.io/hostname: <node_name>
  desiredState:
    interfaces:
    - name: <tunnel_name>
      type: ipsec
      state: absent

Copy to clipboard

ここでは、以下のようになります。

name: ノードネットワーク設定ポリシーの名前を指定します。
node_name: 削除する IPsec トンネルが存在するノードの名前を指定します。
tunnel_name: 既存の IPsec トンネルのインターフェイス名を指定します。

IPsec トンネルを削除するために、次のコマンドを入力します。
```
oc apply -f remove-ipsec-tunnel.yaml
```
```
$ oc apply -f remove-ipsec-tunnel.yaml
```
Copy to clipboardCopied

5.6.9. IPsec 暗号化の無効化

クラスター管理者は、IPsec 暗号化を無効にすることができます。

前提条件

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

手順

IPsec 暗号化を無効にするには、次のコマンドを入力します。

oc patch networks.operator.openshift.io cluster --type=merge \
-p '{

$ oc patch networks.operator.openshift.io cluster --type=merge \
-p '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Disabled"
        }}}}}'

Copy to clipboard

オプション: IP パケットの IPsec ESP ヘッダーからのオーバーヘッドがなくなるため、クラスター MTU のサイズを 46 バイト増やすことができます。

5.6.10. 関連情報

Red Hat Enterprise Linux (RHEL) 9 での IPsec を使用した VPN の設定
Butane のインストール
OVN-Kubernetes Container Network Interface (CNI) ネットワークプラグインについて
クラスターネットワークの MTU 変更
ネットワーク [operator.openshift.io/v1] API

5.7. ゼロトラストネットワーク

ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。

OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。

以下は、ゼロトラストネットワークの対象となる機能の詳細です。

5.7.1. Root of Trust

公開証明書と秘密鍵はゼロトラストネットワークにとって重要です。これらは、各コンポーネントを相互に識別し、認証し、トラフィックを保護するために使用されます。証明書は他の証明書によって署名され、ルート認証局 (CA) への信頼チェーンが存在します。ネットワークに参加するすべてが、信頼チェーンを検証できるように、最終的にルート CA の公開鍵を持っている必要があります。一般に公開されている場合、通常は世界的に知られているルート CA のセットであり、その鍵はオペレーティングシステムや Web ブラウザーなどとともに配布されます。ただし、プライベート CA の証明書がすべての関係者に配布されている場合、クラスターまたは企業向けにプライベート CA を実行できます。

活用方法:

OpenShift Container Platform: OpenShift は、クラスターリソースの保護に使用されるクラスター CA をインストール時に作成します。ただし、OpenShift Container Platform は、クラスター内でサービス証明書を作成して署名することもでき、そのクラスター CA バンドルを必要に応じて Pod に注入することもできます。OpenShift Container Platform によって作成および署名されたサービス証明書の有効期間 (TTL) は 26 カ月で、13 カ月ごとに自動的にローテーションされます。必要に応じて手動でローテーションすることも可能です。
OpenShift cert-manager Operator: cert-manager を使用すると、外部の root of trust によって署名された鍵を要求できます。委譲された署名証明書を使用して実行する方法の他に、外部発行者と統合するために設定できる発行者が多数あります。cert-manager API は、ゼロトラストネットワーク内の他のソフトウェア (Red Hat OpenShift Service Mesh など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。

5.7.2. トラフィック認証と暗号化

回線上のすべてのトラフィックが暗号化され、エンドポイントが識別可能になります。一例として、相互認証方式である Mutual TLS (mTLS) が挙げられます。

活用方法:

OpenShift Container Platform: 透過的な Pod 間の IPsec を使用することで、トラフィックの送信元と宛先を IP アドレスで識別できます。Egress トラフィックを IPsec を使用して暗号化する機能があります。Egress IP 機能を使用すると、トラフィックの送信元 IP アドレスを使用して、クラスター内のトラフィックの送信元を識別できます。
Red Hat OpenShift Service Mesh: Pod から送信されるトラフィックを透過的に拡張して認証と暗号化を提供する強力な mTLS 機能を提供します。
OpenShift cert-manager Operator: カスタムリソース定義 (CRD) を使用して、プログラムが SSL/TLS プロトコルに使用するためにマウントできる証明書を要求します。

5.7.3. 識別と認証

CA を使用して証明書を作成できるようになると、それを使用して接続のもう一方の端 (ユーザーまたはクライアントマシン) のアイデンティティーを検証することで信頼関係を確立できるようになります。また、侵害された場合に使用を制限するために、証明書のライフサイクルを管理する必要もあります。

活用方法:

OpenShift Container Platform: クライアントが信頼済みエンドポイントと通信していることを確認するためのクラスター署名付きサービス証明書。これには、サービスが SSL/TLS を使用し、クライアントがクラスター CA を使用することが必要です。クライアントアイデンティティーは他の手段で提供する必要があります。
Red Hat Single Sign-On: エンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの要求認証インテグレーションを提供します。
Red Hat OpenShift Service Mesh: mTLS への接続の透過的なアップグレード、自動ローテーション、カスタム証明書の有効期限、JSON Web トークン (JWT) による要求認証。
OpenShift cert-manager Operator: アプリケーションで使用する証明書の作成と管理。証明書は CRD により制御され、シークレットとしてマウントできます。また、cert-manager API と直接対話するようにアプリケーションを変更することもできます。

5.7.4. サービス間認可

リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。

活用方法:

OpenShift Container Platform: Kubernetes NetworkPolicy および AdminNetworkPolicy オブジェクトを使用して、プラットフォームのネットワーク層で分離を強制できます。
Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトおよび mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 のトラフィック制御。

5.7.5. トランザクションレベルの検証

接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。

活用方法:

Red Hat OpenShift Service Mesh: 要求の L7 検査、不正な HTTP 要求の拒否、トランザクションレベルの可観測性およびレポートを行います。Service Mesh は、JWT を使用した要求ベースの認証も提供できます。

5.7.6. リスク評価

クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。

活用方法:

Red Hat OpenShift Service Mesh: OpenShift Web コンソールを使用して、Kubernetes の NetworkPolicy と AdminNetworkPolicy、および OpenShift Networking の EgressFirewall オブジェクトを作成および可視化します。
Red Hat Advanced Cluster Security for Kubernetes: 高度なオブジェクトの可視化。

5.7.7. サイト全体のポリシーの施行と配布

クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。

活用方法:

Red Hat OpenShift Service Mesh: ポリシーオブジェクトを制御し、制御を委譲する RBAC。
Red Hat Advanced Cluster Security for Kubernetes: ポリシー適用エンジン。
Red Hat Advanced Cluster Management (RHACM) for Kubernetes: 一元的なポリシー制御。

5.7.8. 継続的かつ遡及的な評価のための可観測性

クラスターを実行した後は、トラフィックを観察し、トラフィックが定義したルールに準拠していることを確認する必要があります。これは侵入検知やフォレンジックのために重要であり、運用負荷管理にも役立ちます。

活用方法:

Network Observability Operator: クラスター内の Pod やノードへのネットワーク接続に関する検査、モニタリング、アラートを可能にします。
Red Hat Advanced Cluster Management (RHACM) for Kubernetes: プロセス実行、ネットワーク接続とフロー、権限昇格などのシステムレベルのイベントを監視、収集、評価します。クラスターのベースラインを決定し、異常なアクティビティーを検出して警告することができます。
Red Hat OpenShift Service Mesh: Pod に出入りするトラフィックを監視できます。
Red Hat OpenShift 分散トレーシングプラットフォーム: 適切にインストルメント化されたアプリケーションの場合、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連付けられたすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。

5.7.9. エンドポイントセキュリティー

クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。

活用方法:

OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名されたイメージのみを実行するように設定できます。
Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。

5.7.10. クラスター外への信頼の拡張

クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。

活用方法:

OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントに、ワークロードのリモートアテステーションを提供できます。

第6章手動 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 レコードのライフサイクルを手動で管理する必要があります。

6.1. `Managed` DNS 管理ポリシー

Ingress Controller の Managed DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが Operator によって自動的に管理されるようになります。

6.2. `Unmanaged` DNS 管理ポリシー

Ingress Controller の Unmanaged DNS 管理ポリシーにより、クラウドプロバイダーのワイルドカード DNS レコードのライフサイクルが自動的に管理されず、代わりにクラスター管理者の責任になります。

注記

AWS クラウドプラットフォームでは、Ingress Controller のドメインが dnsConfig.Spec.BaseDomain と一致しない場合、DNS 管理ポリシーは自動的に Unmanaged に設定されます。

6.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> 1
spec:
  domain: <domain> 2
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External 3
      dnsManagementPolicy: Unmanaged 4
```
```
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 clipboardCopied
1
IngressController オブジェクトの名前で <name> を指定します。
2
前提として作成した DNS レコードをもとに domain を指定します。
3
scope を External として指定して、ロードバランサーを外部に公開します。
4
dnsManagementPolicy は、Ingress Controller がロードバランサーに関連付けられたワイルドカード DNS レコードのライフサイクルを管理しているかどうかを示します。有効な値は Managed および Unmanaged です。デフォルト値は Managed です。
変更を適用するためにファイルを保存します。
```
oc apply -f <name>.yaml 1
```
```
oc apply -f <name>.yaml 1
```
Copy to clipboardCopied

6.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

オプション: クラウドプロバイダーで関連付けられている DNS レコードを削除できます。

6.5. 関連情報

Ingress Controller 設定パラメーター

第7章エンドポイントへの接続の確認

Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。

7.1. 実行する接続ヘルスチェック

クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。

Kubernetes API サーバーサービス
Kubernetes API サーバーエンドポイント
OpenShift API サーバーサービス
OpenShift API サーバーエンドポイント
ロードバランサー

サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。

ヘルスチェックターゲットサービス
ヘルスチェックターゲットエンドポイント

7.2. 接続ヘルスチェックの実装

接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。

Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。

ヘルスチェックのソース: このプログラムは、Deployment オブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムは PodNetworkConnectivity オブジェクトを消費し、各オブジェクトで指定される spec.targetEndpoint に接続されます。
ヘルスチェックのターゲット: クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。

ノードセレクターを使用して、ネットワーク接続ソースとターゲットが実行されるノードを設定できます。さらに、ソース Pod とターゲット Pod で許容できる tolerations を指定することもできます。この設定は、config.openshift.io/v1 API グループの Network API のシングルトン cluster カスタムリソースで定義されます。

Pod のスケジュールは、設定を更新した後に実行されます。したがって、設定を更新する前に、セレクターで使用する予定のノードラベルを適用する必要があります。ネットワーク接続チェック Pod の配置を更新した後に適用されたラベルは無視されます。

次の YAML のデフォルト設定を参照してください。

接続ソースおよびターゲット Pod のデフォルト設定

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
    networkDiagnostics: 1
      mode: "All" 2
      sourcePlacement: 3
        nodeSelector:
          checkNodes: groupA
        tolerations:
        - key: myTaint
          effect: NoSchedule
          operator: Exists
      targetPlacement: 4
        nodeSelector:
          checkNodes: groupB
        tolerations:
        - key: myOtherTaint
          effect: NoExecute
          operator: Exists

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
    networkDiagnostics: 1
      mode: "All" 2
      sourcePlacement: 3
        nodeSelector:
          checkNodes: groupA
        tolerations:
        - key: myTaint
          effect: NoSchedule
          operator: Exists
      targetPlacement: 4
        nodeSelector:
          checkNodes: groupB
        tolerations:
        - key: myOtherTaint
          effect: NoExecute
          operator: Exists

Copy to clipboard

1 1: ネットワーク診断設定を指定します。値が指定されていないか、空のオブジェクトが指定されており、cluster という名前の network.operator.openshift.io カスタムリソースで spec.disableNetworkDiagnostics=true が設定されている場合、ネットワーク診断は無効になります。設定されている場合、この値は spec.disableNetworkDiagnostics=true をオーバーライドします。
2: 診断モードを指定します。値は、空の文字列、All、または Disabled です。空の文字列は All を指定するのと同じです。
3: オプション: 接続チェックのソース Pod のセレクターを指定します。nodeSelector および tolerations フィールドを使用して、sourceNode Pod をさらに指定できます。ただし、ソース Pod とターゲット Pod の両方に nodeSelector と tolerations の両方を使用する必要はありません。これらは省略可能なオプションのフィールドです。
4: オプション: 接続チェックのターゲット Pod のセレクターを指定します。nodeSelector および tolerations フィールドを使用して、targetNode Pod をさらに指定できます。ただし、ソース Pod とターゲット Pod の両方に nodeSelector と tolerations の両方を使用する必要はありません。これらは省略可能なオプションのフィールドです。

7.3. Pod 接続チェックの配置の設定

クラスター管理者は、cluster という名前の network.config.openshift.io オブジェクトを変更することで、接続チェック Pod が実行するノードを設定できます。

前提条件

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

手順

接続チェック設定を編集するには、次のコマンドを入力します。
```
oc edit network.config.openshift.io cluster
```
```
$ oc edit network.config.openshift.io cluster
```
Copy to clipboardCopied
テキストエディターで、networkDiagnostics スタンザを更新して、ソース Pod とターゲット Pod に必要なノードセレクターを指定します。
変更をコミットするには、変更を保存してテキストエディターを終了します。

検証

ソース Pod とターゲット Pod が目的のノードで実行されていることを確認するには、次のコマンドを入力します。

oc get pods -n openshift-network-diagnostics -o wide

$ oc get pods -n openshift-network-diagnostics -o wide

Copy to clipboard

出力例

NAME                                    READY   STATUS    RESTARTS   AGE     IP           NODE                                        NOMINATED NODE   READINESS GATES
network-check-source-84c69dbd6b-p8f7n   1/1     Running   0          9h      10.131.0.8   ip-10-0-40-197.us-east-2.compute.internal   <none>           <none>
network-check-target-46pct              1/1     Running   0          9h      10.131.0.6   ip-10-0-40-197.us-east-2.compute.internal   <none>           <none>
network-check-target-8kwgf              1/1     Running   0          9h      10.128.2.4   ip-10-0-95-74.us-east-2.compute.internal    <none>           <none>
network-check-target-jc6n7              1/1     Running   0          9h      10.129.2.4   ip-10-0-21-151.us-east-2.compute.internal   <none>           <none>
network-check-target-lvwnn              1/1     Running   0          9h      10.128.0.7   ip-10-0-17-129.us-east-2.compute.internal   <none>           <none>
network-check-target-nslvj              1/1     Running   0          9h      10.130.0.7   ip-10-0-89-148.us-east-2.compute.internal   <none>           <none>
network-check-target-z2sfx              1/1     Running   0          9h      10.129.0.4   ip-10-0-60-253.us-east-2.compute.internal   <none>           <none>

NAME                                    READY   STATUS    RESTARTS   AGE     IP           NODE                                        NOMINATED NODE   READINESS GATES
network-check-source-84c69dbd6b-p8f7n   1/1     Running   0          9h      10.131.0.8   ip-10-0-40-197.us-east-2.compute.internal   <none>           <none>
network-check-target-46pct              1/1     Running   0          9h      10.131.0.6   ip-10-0-40-197.us-east-2.compute.internal   <none>           <none>
network-check-target-8kwgf              1/1     Running   0          9h      10.128.2.4   ip-10-0-95-74.us-east-2.compute.internal    <none>           <none>
network-check-target-jc6n7              1/1     Running   0          9h      10.129.2.4   ip-10-0-21-151.us-east-2.compute.internal   <none>           <none>
network-check-target-lvwnn              1/1     Running   0          9h      10.128.0.7   ip-10-0-17-129.us-east-2.compute.internal   <none>           <none>
network-check-target-nslvj              1/1     Running   0          9h      10.130.0.7   ip-10-0-89-148.us-east-2.compute.internal   <none>           <none>
network-check-target-z2sfx              1/1     Running   0          9h      10.129.0.4   ip-10-0-60-253.us-east-2.compute.internal   <none>           <none>

Copy to clipboard

7.4. PodNetworkConnectivityCheck オブジェクトフィールド

PodNetworkConnectivityCheck オブジェクトフィールドについては、以下の表で説明されています。

表7.1 PodNetworkConnectivityCheck オブジェクトフィールド
フィールド	型	説明
`metadata.name`	`string`	以下の形式のオブジェクトの名前: `<source>-to-<target><target>` で記述される宛先には、以下のいずれかの文字列が含まれます。 `load-balancer-api-external` `load-balancer-api-internal` `kubernetes-apiserver-endpoint` `kubernetes-apiserver-service-cluster` `network-check-target` `openshift-apiserver-endpoint` `openshift-apiserver-service-cluster`
`metadata.namespace`	`string`	オブジェクトが関連付けられる namespace。この値は、常に `openshift-network-diagnostics` になります。
`spec.sourcePod`	`string`	接続チェックの起点となる Pod の名前 (例: `network-check-source-596b4c6566-rgh92`)。
`spec.targetEndpoint`	`string`	`api.devcluster.example.com:6443` などの接続チェックのターゲット。
`spec.tlsClientCert`	`object`	使用する TLS 証明書の設定。
`spec.tlsClientCert.name`	`string`	使用される TLS 証明書の名前 (ある場合)。デフォルト値は空の文字列です。
`status`	`object`	接続テストの状態を表す、および最近の接続の成功および失敗に関するログ。
`status.conditions`	`array`	接続チェックと最新のステータスと以前のステータス。
`status.failures`	`array`	試行に失敗した接続テストのログ。
`status.outages`	`array`	停止が生じた期間が含まれる接続テストのログ。
`status.successes`	`array`	試行に成功した接続テストのログ。

以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。

表7.2 status.conditions
フィールド	型	説明
`lastTransitionTime`	`string`	接続の条件がある状態から別の状態に移行した時間。
`message`	`string`	人が判読できる形式の最後の移行に関する詳細。
`reason`	`string`	マシンの読み取り可能な形式での移行の最後のステータス。
`status`	`string`	状態のテータス。
`type`	`string`	状態のタイプ。

以下の表は、status.conditions 配列内のオブジェクトのフィールドを説明しています。

表7.3 status.outages
フィールド	型	説明
`end`	`string`	接続の障害が解決された時点からのタイムスタンプ。
`endLogs`	`array`	接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。
`message`	`string`	人が判読できる形式の停止について詳細情報の要約。
`start`	`string`	接続の障害が最初に検知された時点からのタイムスタンプ。
`startLogs`	`array`	元の障害を含む接続ログのエントリー。

接続ログフィールド

接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。

status.failures[]
status.successes[]
status.outages[].startLogs[]
status.outages[].endLogs[]

表7.4 接続ログオブジェクト
フィールド	型	説明
`latency`	`string`	アクションの期間を記録します。
`message`	`string`	ステータスを人が判読できる形式で提供します。
`reason`	`string`	ステータスの理由をマシンが判読できる形式で提供します。値は `TCPConnect`、`TCPConnectError`、`DNSResolve`、`DNSError` のいずれかになります。
`success`	`boolean`	ログエントリーが成功または失敗であるかを示します。
`time`	`string`	接続チェックの開始時間。

7.5. エンドポイントのネットワーク接続の確認

クラスター管理者は、API サーバー、ロードバランサー、サービス、Pod などのエンドポイントの接続を確認し、ネットワーク診断が有効になっていることを確認できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

ネットワーク診断が有効になっていることを確認するには、次のコマンドを入力します。

oc get network.config.openshift.io cluster -o yaml

$ oc get network.config.openshift.io cluster -o yaml

Copy to clipboard

出力例

...

  # ...
  status:
  # ...
    conditions:
    - lastTransitionTime: "2024-05-27T08:28:39Z"
      message: ""
      reason: AsExpected
      status: "True"
      type: NetworkDiagnosticsAvailable

Copy to clipboard

現在の PodNetworkConnectivityCheck オブジェクトをリスト表示するには、以下のコマンドを入力します。

oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

Copy to clipboard

出力例

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

接続テストログを表示します。

直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。

オブジェクトを表示するには、以下のコマンドを入力します。

oc get podnetworkconnectivitycheck <name> \
  -n openshift-network-diagnostics -o yaml

$ oc get podnetworkconnectivitycheck <name> \
  -n openshift-network-diagnostics -o yaml

Copy to clipboard

ここで、<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

第8章クラスターネットワークの MTU 変更

クラスター管理者は、クラスターのインストール後にクラスターネットワークの MTU を変更できます。MTU 変更の適用には、クラスターノードを再起動する必要があるため、変更により致命的な問題が発生する可能性があります。

8.1. クラスター MTU について

インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU をオーバーライドする必要はありません。

以下のような理由でクラスターネットワークの MTU を変更する場合があります。

クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。

OVN-Kubernetes クラスターネットワークプラグインのみが MTU 値の変更をサポートしています。

8.1.1. サービス中断に関する考慮事項

クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。

新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。

8.1.2. MTU 値の選択

MTU の移行を計画するときは、関連しているが異なる MTU 値を 2 つ考慮する必要があります。

ハードウェア MTU: この MTU 値は、ネットワークインフラストラクチャーの詳細に基づいて設定されます。
クラスターネットワーク MTU: この MTU 値は、クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。具体的なオーバーヘッドは、ネットワークプラグインによって決まります。OVN-Kubernetes の場合、オーバーヘッドは 100 バイトです。

クラスターがノードごとに異なる MTU 値を必要とする場合は、クラスター内の任意のノードで使用される最小の MTU 値から、ネットワークプラグインのオーバーヘッド値を差し引く必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

重要

ノードが受け入れられない MTU 値の選択を回避するには、ip -d link コマンドを使用して、ネットワークインターフェイスが受け入れる最大 MTU 値 (maxmtu) を確認します。

8.1.3. 移行プロセスの仕組み

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

表8.1 クラスター MTU のライブマイグレーション
ユーザーが開始する手順	OpenShift Container Platform アクティビティー
Cluster Network Operator 設定で次の値を指定します。 `spec.migration.mtu.machine.to` `spec.migration.mtu.network.from` `spec.migration.mtu.network.to`	Cluster Network Operator (CNO): 各フィールドが有効な値に設定されていることを確認します。 `mtu.machine.to` は、新しいハードウェア MTU、またはハードウェアの MTU が変更されていない場合は、現在のハードウェア MTU のいずれかに設定する必要があります。この値は一時的なものであり、移行プロセスの一部として使用されます。これとは別に、既存のハードウェア MTU 値とは異なるハードウェア MTU を指定する場合は、マシン設定、DHCP 設定、Linux カーネルコマンドラインなどの他の方法で永続化するように MTU を手動で設定する必要があります。 `mtu.network.from` フィールドは、クラスターネットワークの現在の MTU である `network.status.clusterNetworkMTU` フィールドと同じである必要があります。 `mtu.network.to` フィールドは、ターゲットクラスターネットワーク MTU に設定する必要があり、ネットワークプラグインのオーバーレイオーバーヘッドを考慮して、ハードウェア MTU よりも低くする必要があります。OVN-Kubernetes の場合、オーバーヘッドは `100` バイトです。指定の値が有効な場合に、CNO は、クラスターネットワークの MTU が `mtu.network.to` フィールドの値に設定された新しい一時設定を書き出します。 Machine Config Operator (MCO): クラスター内の各ノードのローリングリブートを実行します。
クラスター上のノードのプライマリーネットワークインターフェイスの MTU を再設定します。これを実現するには、次のようなさまざまな方法を使用できます。 MTU を変更した新しい NetworkManager 接続プロファイルのデプロイ DHCP サーバー設定による MTU の変更ブートパラメーターによる MTU の変更	該当なし
ネットワークプラグインの CNO 設定で `mtu` 値を設定し、`spec.migration` を `null` に設定します。	Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。

8.2. クラスターネットワーク MTU の変更

クラスター管理者は、クラスターの最大伝送単位 (MTU) を増減できます。

重要

移行には中断が伴うため、MTU 更新が有効になると、クラスター内のノードが一時的に使用できなくなる可能性があります。

次の手順では、マシン設定、Dynamic Host Configuration Protocol (DHCP)、または ISO イメージのいずれかを使用してクラスターネットワーク MTU を変更する方法を説明します。DHCP または ISO アプローチを使用する場合は、クラスターのインストール後に保持した設定アーティファクトを参照して、手順を完了する必要があります。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つアカウントを使用してクラスターにアクセスできる。
クラスターのターゲット MTU を特定している。OVN-Kubernetes ネットワークプラグインの MTU は、クラスター内の最小のハードウェア MTU 値から 100 を引いた値に設定する必要があります。

手順

クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

oc describe network.config cluster

$ oc describe network.config cluster

Copy to clipboard

出力例

...
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

ハードウェア MTU の設定を準備します。
- ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。
```
dhcp-option-force=26,<mtu>
```
```
dhcp-option-force=26,<mtu>
```
  Copy to clipboardCopied
  ここでは、以下のようになります。
  <mtu>
  DHCP サーバーがアドバタイズするハードウェア MTU を指定します。
- ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。
- ハードウェア MTU が NetworkManager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。
  1. 次のコマンドを入力して、プライマリーネットワークインターフェイスを見つけます。
    $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
    Copy to clipboard
    ここでは、以下のようになります。
    <node_name>
    クラスター内のノードの名前を指定します。
  2. <interface>-mtu.conf ファイルに次の NetworkManager 設定を作成します。
    NetworkManager 接続設定の例
    
    [connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
    Copy to clipboard
    ここでは、以下のようになります。
    <mtu>
    新しいハードウェア MTU 値を指定します。
    <interface>
    プライマリーネットワークインターフェイス名を指定します。
  3. 1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つの MachineConfig オブジェクトを作成します。
    control-plane-interface.bu ファイルに次の Butane 設定を作成します。
    注記
    設定ファイルで指定する Butane のバージョンは、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.18.0 です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
    variant: openshift version: 4.18.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
    1
    プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。
    2
    前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。
    worker-interface.bu ファイルに次の Butane 設定を作成します。
    注記
    設定ファイルで指定する Butane のバージョンは、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.18.0 です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
    variant: openshift version: 4.18.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
    1
    プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。
    2
    前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。
    次のコマンドを実行して、Butane 設定から MachineConfig オブジェクトを作成します。
    $ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done
    Copy to clipboard
    警告
    これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。
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 clipboardCopied
ここでは、以下のようになります。
<overlay_from>
現在のクラスターネットワークの MTU 値を指定します。
<overlay_to>
クラスターネットワークのターゲット MTU を指定します。この値は、<machine_to> の値を基準にして設定します。OVN-Kubernetes の場合、この値は <machine_to> の値から 100 を引いた値である必要があります。
<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 clipboardCopied
Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get machineconfigpools
```
```
$ oc get machineconfigpools
```
Copy to clipboardCopied
正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。
注記
Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
```
oc describe node | egrep "hostname|machineconfig"
```
```
$ oc describe node | egrep "hostname|machineconfig"
```
  Copy to clipboardCopied
  出力例
  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
2. 以下のステートメントが true であることを確認します。
  - machineconfiguration.openshift.io/state フィールドの値は Done です。
  - machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
3. マシン設定が正しいことを確認するには、以下のコマンドを入力します。
```
oc get machineconfig <config_name> -o yaml | grep ExecStart
```
```
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
```
  Copy to clipboardCopied
  ここで、<config_name> は machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。
  マシン設定には、systemd 設定に以下の更新を含める必要があります。
```
ExecStart=/usr/local/bin/mtu-migration.sh
```
```
ExecStart=/usr/local/bin/mtu-migration.sh
```
  Copy to clipboardCopied
基盤となるネットワークインターフェイスの 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 clipboardCopied
- DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。
Machine Config Operator (MCO) は、各マシン設定プール内のマシンを更新するときに、各ノードを 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get machineconfigpools
```
```
$ oc get machineconfigpools
```
Copy to clipboardCopied
正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。
注記
Machine Config Operator は、デフォルトでプールごとに 1 つずつマシンを更新するため、クラスターのサイズに応じて移行にかかる合計時間が増加します。
ホスト上の新規マシン設定のステータスを確認します。
1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
```
oc describe node | egrep "hostname|machineconfig"
```
```
$ oc describe node | egrep "hostname|machineconfig"
```
  Copy to clipboardCopied
  出力例
  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
  以下のステートメントが true であることを確認します。
  - machineconfiguration.openshift.io/state フィールドの値は Done です。
  - machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。
```
oc get machineconfig <config_name> -o yaml | grep path:
```
```
$ oc get machineconfig <config_name> -o yaml | grep path:
```
  Copy to clipboardCopied
  ここで、<config_name> は machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。
  マシン設定が正常にデプロイされた場合、前の出力には /etc/NetworkManager/conf.d/99-<interface>-mtu.conf ファイルパスと ExecStart=/usr/local/bin/mtu-migration.sh 行が含まれます。

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

ここでは、以下のようになります。

<mtu>: <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。

MTU の移行が完了すると、各マシン設定プールノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get machineconfigpools
```
```
$ oc get machineconfigpools
```
Copy to clipboardCopied
正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

検証

クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
```
oc describe network.config cluster
```
```
$ oc describe network.config cluster
```
Copy to clipboardCopied
ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。
1. クラスター内のノードをリスト表示するには、次のコマンドを入力します。
```
oc get nodes
```
```
$ oc get nodes
```
  Copy to clipboardCopied
2. ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。
```
oc debug node/<node> -- chroot /host ip address show <interface>
```
```
$ oc debug node/<node> -- chroot /host ip address show <interface>
```
  Copy to clipboardCopied
  ここでは、以下のようになります。
  <node>
  前のステップの出力をもとに、ノードを指定します。
  <interface>
  ノードのプライマリーネットワークインターフェイス名を指定します。
  出力例
  ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
  Copy to clipboard

8.3. 関連情報

第9章ノードポートサービス範囲の設定

クラスター管理者は、利用可能なノードのポート範囲を拡張できます。クラスターで多数のノードポートが使用される場合、利用可能なポートの数を増やす必要がある場合があります。

デフォルトのポート範囲は 30000-32767 です。最初にデフォルト範囲を超えて拡張した場合でも、ポート範囲を縮小することはできません。

9.1. 前提条件

クラスターインフラストラクチャーは、拡張された範囲内で指定するポートへのアクセスを許可する必要があります。たとえば、ノードのポート範囲を 30000-32900 に拡張する場合、ファイアウォールまたはパケットフィルタリングの設定によりこれに含まれるポート範囲 32768-32900 を許可する必要があります。

9.2. ノードのポート範囲の拡張

クラスターのノードポート範囲を拡張できます。

重要

ノードポート範囲を、保護されたポート範囲 (0 - 32767) に拡張できます。ただし、拡張後に範囲を変更することはできません。範囲を変更しようとすると、次のエラーが返されます: The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the previous range 0-32767。

変更する前に、設定した新しい範囲がクラスターに適切であることを確認してください。

前提条件

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

手順

ノードのポート範囲を拡張するには、以下のコマンドを入力します。<port> を、新規の範囲内で最大のポート番号に置き換えます。

oc patch network.config.openshift.io cluster --type=merge -p \
  '{

$ oc patch network.config.openshift.io cluster --type=merge -p \
  '{
    "spec":
      { "serviceNodePortRange": "30000-<port>" }
  }'

Copy to clipboard

ヒント

または、以下の YAML を適用してノードのポート範囲を更新することもできます。

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNodePortRange: "30000-<port>"

apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNodePortRange: "30000-<port>"

Copy to clipboard

出力例

network.config.openshift.io/cluster patched

network.config.openshift.io/cluster patched

Copy to clipboard

設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。

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

出力例

"service-node-port-range":["30000-33000"]

"service-node-port-range":["30000-33000"]

Copy to clipboard

9.3. 関連情報

第10章クラスターネットワーク範囲の設定

クラスター管理者は、クラスターのインストール後にクラスターネットワークの範囲を拡張できます。追加ノード用にさらに多くの IP アドレスが必要な場合は、クラスターネットワーク範囲を拡張することを推奨します。

たとえば、クラスターをデプロイし、クラスターネットワーク範囲として 10.128.0.0/19 を指定し、ホスト接頭辞 23 を指定した場合、16 ノードに制限されます。クラスターの CIDR マスクを /14 に変更することで、これを 510 ノードに拡張できます。

クラスターのネットワークアドレス範囲を拡張する場合、クラスターは OVN-Kubernetes ネットワークプラグインを使用する必要があります。他のネットワークプラグインはサポートされていません。

クラスターネットワークの IP アドレス範囲を変更する場合、次の制限が適用されます。

指定する CIDR マスクサイズは、現在設定されている CIDR マスクサイズより常に小さくする必要があります。これは、インストールされたクラスターにノードを追加することによってのみ IP スペースを増やすことができるためです。
ホスト接頭辞は変更できません
オーバーライドされたデフォルトゲートウェイで設定された Pod は、クラスターネットワークの拡張後に再作成する必要があります。

10.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

出力例

[{"cidr":"10.217.0.0/22","hostPrefix":23}]

[{"cidr":"10.217.0.0/22","hostPrefix":23}]

Copy to clipboard

クラスターネットワークの 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 clipboardCopied
ここでは、以下のようになります。
<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 clipboardCopied
出力例
```
network.config.openshift.io/cluster patched
```
```
network.config.openshift.io/cluster patched
```
Copy to clipboardCopied

設定がアクティブであることを確認するには、以下のコマンドを入力します。この変更が有効になるまで、最大 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

出力例

[{"cidr":"10.217.0.0/14","hostPrefix":23}]

[{"cidr":"10.217.0.0/14","hostPrefix":23}]

Copy to clipboard

10.2. 関連情報

Red Hat OpenShift Network Calculator
OVN-Kubernetes ネットワークプラグインについて

第11章 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 です。

11.1. IP フェイルオーバーの環境変数

以下の表は、IP フェイルオーバーの設定に使用される変数を示しています。

表11.1 IP フェイルオーバーの環境変数
変数名	デフォルト	説明
`OPENSHIFT_HA_MONITOR_PORT`	`80`	IP フェイルオーバー Pod は、各仮想 IP (VIP) のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが `0` に設定される場合、テストは常にパスします。
`OPENSHIFT_HA_NETWORK_INTERFACE`		IP フェイルオーバーが Virtual Router Redundancy Protocol (VRRP) トラフィックの送信に使用するインターフェイス名。デフォルト値は `eth0` です。クラスターが OVN-Kubernetes ネットワークプラグインを使用する場合は、パケットロスを回避するためにこの値を `br-ex` に設定します。OVN-Kubernetes ネットワークプラグインを使用するクラスターの場合、すべてのリスニングインターフェイスは VRRP を提供せず、代わりに `br-ex` ブリッジ経由の受信トラフィックを受け入れます。
`OPENSHIFT_HA_REPLICA_COUNT`	`2`	作成するレプリカの数です。これは、IP フェイルオーバーデプロイメント設定の `spec.replicas` 値に一致する必要があります。
`OPENSHIFT_HA_VIRTUAL_IPS`		レプリケートする IP アドレス範囲のリストです。これは指定する必要があります。例: `1.2.3.4-6,1.2.3.9`
`OPENSHIFT_HA_VRRP_ID_OFFSET`	`0`	仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは `0` で、許可される範囲は `0` から `255` までです。
`OPENSHIFT_HA_VIP_GROUPS`		VRRP に作成するグループの数です。これが設定されていない場合、グループは `OPENSHIFT_HA_VIP_GROUPS` 変数で指定されている仮想 IP 範囲ごとに作成されます。
`OPENSHIFT_HA_IPTABLES_CHAIN`	INPUT	iptables チェーンの名前であり、`iptables` ルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、`iptables` ルールは追加されません。チェーンが存在しない場合は作成されません。
`OPENSHIFT_HA_CHECK_SCRIPT`		アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
`OPENSHIFT_HA_CHECK_INTERVAL`	`2`	check スクリプトが実行される期間 (秒単位) です。
`OPENSHIFT_HA_NOTIFY_SCRIPT`		状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
`OPENSHIFT_HA_PREEMPTION`	`preempt_nodelay 300`	新たな優先度の高いホストを処理するためのストラテジーです。`nopreempt` ストラテジーでは、マスターを優先度の低いホストから優先度の高いホストに移動しません。

11.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 clipboardCopied

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

oc adm policy add-scc-to-user hostnetwork -z ipfailover

$ oc adm policy add-scc-to-user hostnetwork -z ipfailover

Copy to clipboard

Red Hat OpenStack Platform (RHOSP) のみ: フェイルオーバー仮想 IP アドレスが RHOSP ポートに到達できるように、次の手順を実行します。
1. 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 clipboardCopied
  出力例
  *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
2. 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
  Copy to clipboard
3. デプロイメントの IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。後の手順の「IP フェイルオーバー設定のデプロイメント YAML の例」を参照してください。
4. 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" # ...
  Copy to clipboard

IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。

注記

Red Hat OpenStack Platform (RHOSP) の場合、デプロイメント YAML ファイルを再作成する必要はありません。このファイルは、以前の手順ですでに作成されています。

IP フェイルオーバー設定のデプロイメント YAML の例

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.18
        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

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.18
        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

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: デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。

11.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 clipboardCopied

ConfigMap オブジェクトを作成します。

oc create configmap mycustomcheck --from-file=mycheckscript.sh

$ oc create configmap mycustomcheck --from-file=mycheckscript.sh

Copy to clipboard

スクリプトを 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

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

注記

oc set env コマンドは空白を区別します。= 記号の両側に空白を入れることはできません。

ヒント

または、ipfailover-keepalived デプロイメント設定を編集することもできます。

oc edit deploy ipfailover-keepalived

$ oc edit deploy ipfailover-keepalived

Copy to clipboard

    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
...

    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

1: spec.container.env フィールドで、マウントされたスクリプトファイルを参照する OPENSHIFT_HA_CHECK_SCRIPT 環境変数を追加します。
2: spec.container.volumeMounts フィールドを追加してマウントポイントを作成します。
3: 新規の spec.volumes フィールドを追加して config map に言及します。
4: これはファイルの実行パーミッションを設定します。読み取られる場合は 10 進数 (493) で表示されます。

変更を保存し、エディターを終了します。これにより ipfailover-keepalived が再起動されます。

11.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 clipboardCopied
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  1
          value: preempt_delay 300
...
```
```
...
    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_PREEMPTION  1
          value: preempt_delay 300
...
```
Copy to clipboardCopied
1
OPENSHIFT_HA_PREEMPTION の値を設定します。
preempt_delay 300: Keepalived は、指定された 300 秒の間待機し、master をホスト上の優先度の高い VIP に移動します。これはデフォルト値です。
nopreempt: master をホスト上の優先度の低い VIP からホスト上の優先度の高い VIP に移動しません。

11.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 範囲が重複しないようにする必要があります。

11.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 1
          value: "3"
...
```
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 1
          value: "3"
...
```
Copy to clipboardCopied
1
たとえば、7 つの VIP のある環境で OPENSHIFT_HA_VIP_GROUPS が 3 に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。

注記

OPENSHIFT_HA_VIP_GROUPS で設定されたグループの数が、フェイルオーバーに設定された IP アドレスの数より少ない場合、グループには複数の IP アドレスが含まれ、すべてのアドレスが 1 つのユニットとして移動します。

11.7. ExternalIP の高可用性

非クラウドクラスターでは、IP フェイルオーバーとサービスへの ExternalIP を組み合わせることができます。結果として、ExternalIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。

このアプローチでは、クラスターネットワーク設定の spec.ExternalIP.autoAssignCIDRs 範囲を指定し、同じ範囲を使用して IP フェイルオーバー設定を作成します。

IP フェイルオーバーはクラスター全体で最大 255 個の仮想 IP をサポートできるため、spec.ExternalIP.autoAssignCIDRs は /24 以下にする必要があります。

関連情報

11.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

出力例

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

前述の手順でボリュームとして使用される config map の名前が提供されている場合は、config map を削除します。
```
oc delete configmap <configmap_name>
```
```
$ oc delete configmap <configmap_name>
```
Copy to clipboardCopied

IP フェイルオーバーの既存デプロイメントを特定します。

oc get deployment -l ipfailover

$ oc get deployment -l ipfailover

Copy to clipboard

出力例

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

デプロイメントを削除します。

oc delete deployment <ipfailover_deployment_name>

$ oc delete deployment <ipfailover_deployment_name>

Copy to clipboard

ipfailover サービスアカウントを削除します。
```
oc delete sa ipfailover
```
```
$ oc delete sa ipfailover
```
Copy to clipboardCopied

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.18
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector: 1
        kubernetes.io/hostname: <host_name>  2
      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.18
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector: 1
        kubernetes.io/hostname: <host_name>  2
      restartPolicy: Never

Copy to clipboard

1: nodeSelector は、古い IP フェイルオーバーデプロイメントで使用されていたセレクターと同じである可能性があります。
2: IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。

ジョブを実行します。

oc create -f remove-ipfailover-job.yaml

$ oc create -f remove-ipfailover-job.yaml

Copy to clipboard

出力例

job.batch/remove-ipfailover-2h8dm created

job.batch/remove-ipfailover-2h8dm created

Copy to clipboard

検証

ジョブが IP フェイルオーバーの初期設定を削除していることを確認します。

oc logs job/remove-ipfailover-2h8dm

$ oc logs job/remove-ipfailover-2h8dm

Copy to clipboard

出力例

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

第12章チューニングプラグインを使用してシステムコントロールとインターフェイス属性を設定する

Linux では、管理者は sysctl を使用してランタイム時にカーネルパラメーターを変更できます。チューニング Container Network Interface (CNI) メタプラグインを使用して、インターフェイスレベルのネットワーク sysctl を変更できます。チューニング CNI メタプラグインは、図に示すように、メインの CNI プラグインとチェーンで動作します。

メインの CNI プラグインはインターフェイスを割り当て、それをランタイム時にチューニング CNI メタプラグインに渡します。チューニング CNI メタプラグインを使用して、ネットワーク namespace の一部の sysctl といくつかのインターフェイス属性 (プロミスキャスモード、オールマルチキャストモード、MTU、および MAC アドレス) を変更できます。

12.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> 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
        }
      }
     ]
}

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

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

以下のコマンドを実行して YAML を適用します。

oc apply -f tuning-example.yaml

$ oc apply -f tuning-example.yaml

Copy to clipboard

出力例

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

Copy to clipboard

次のようなネットワーク接続定義を使用して、examplepod.yaml などの Pod を作成します。
```
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
```
```
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 clipboardCopied
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 clipboardCopied

次のコマンドを実行して、Pod が作成されていることを確認します。

oc get pod

$ oc get pod

Copy to clipboard

出力例

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

次のコマンドを実行して、Pod にログインします。
```
oc rsh tunepod
```
```
$ oc rsh tunepod
```
Copy to clipboardCopied
設定された 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 clipboardCopied
予想される出力
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to clipboardCopied

12.2. チューニング CNI を使用してオールマルチキャストモードを有効にする

チューニング Container Network Interface (CNI) メタプラグインを使用して、オールマルチキャストモードを有効にできます。

次の手順では、チューニング CNI を設定してオールマルチキャストモードを有効にする方法を説明します。

手順

次の内容で、tuning-example.yaml などのネットワーク接続定義を作成します。

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
        }
      }
     ]
}

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

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

次のコマンドを実行して、YAML ファイルで指定された設定を適用します。

oc apply -f tuning-allmulti.yaml

$ oc apply -f tuning-allmulti.yaml

Copy to clipboard

出力例

networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created

networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created

Copy to clipboard

次の examplepod.yaml サンプルファイルで指定されているものと同様のネットワーク接続定義を持つ Pod を作成します。
```
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
```
```
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 clipboardCopied
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 clipboardCopied

次のコマンドを実行して、Pod が作成されていることを確認します。

oc get pod

$ oc get pod

Copy to clipboard

出力例

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

次のコマンドを実行して、Pod にログインします。
```
oc rsh allmultipod
```
```
$ oc rsh allmultipod
```
Copy to clipboardCopied

次のコマンドを実行して、Pod に関連付けられているすべてのインターフェイスをリスト表示します。

ip link

sh-4.4# ip link

Copy to clipboard

出力例

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

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

1: eth0@if22 は、プライマリーインターフェイスです。
2: net1@if24 は、オールマルチキャストモード (ALLMULTI フラグ) をサポートするネットワーク接続定義で設定されたセカンダリーインターフェイスです。

12.3. 関連情報

コンテナーでの sysctl の使用
SR-IOV ネットワークノード設定オブジェクト
SR-IOV ネットワークのインターフェイスレベルのネットワーク sysctl 設定とオールマルチキャストモードを設定する

第13章 Stream Control Transmission Protocol (SCTP) の使用

クラスター管理者は、ベアメタルクラスターで Stream Control Transmission Protocol (SCTP) を使用できます。

13.1. OpenShift Container Platform での SCTP のサポート

クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。

SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。

これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service オブジェクトは、type パラメーターを ClusterIP または NodePort のいずれかの値に設定して定義する必要があります。

13.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

Copy to clipboard

以下の例では、サービスは 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

Copy to clipboard

以下の例では、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

Copy to clipboard

13.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

MachineConfig オブジェクトを作成するには、以下のコマンドを入力します。
```
oc create -f load-sctp-module.yaml
```
```
$ oc create -f load-sctp-module.yaml
```
Copy to clipboardCopied
オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが Ready に移行すると、設定の更新が適用されます。
```
oc get nodes
```
```
$ oc get nodes
```
Copy to clipboardCopied

13.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

以下のコマンドを入力して Pod を作成します。
```
oc create -f sctp-server.yaml
```
```
$ oc create -f sctp-server.yaml
```
Copy to clipboardCopied

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

サービスを作成するには、以下のコマンドを入力します。
```
oc create -f sctp-service.yaml
```
```
$ oc create -f sctp-service.yaml
```
Copy to clipboardCopied

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

Pod オブジェクトを作成するには、以下のコマンドを入力します。
```
oc apply -f sctp-client.yaml
```
```
$ oc apply -f sctp-client.yaml
```
Copy to clipboardCopied

サーバーで SCTP リスナーを実行します。
1. サーバー Pod に接続するには、以下のコマンドを入力します。
```
oc rsh sctpserver
```
```
$ oc rsh sctpserver
```
  Copy to clipboardCopied
2. SCTP リスナーを起動するには、以下のコマンドを入力します。
```
nc -l 30102 --sctp
```
```
$ nc -l 30102 --sctp
```
  Copy to clipboardCopied
サーバーの SCTP リスナーに接続します。
1. ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
2. sctpservice サービスの IP アドレスを取得します。以下のコマンドを入力します。
```
oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
```
```
$ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
```
  Copy to clipboardCopied
3. クライアント Pod に接続するには、以下のコマンドを入力します。
```
oc rsh sctpclient
```
```
$ oc rsh sctpclient
```
  Copy to clipboardCopied
4. SCTP クライアントを起動するには、以下のコマンドを入力します。<cluster_IP> を sctpservice サービスのクラスター IP アドレスに置き換えます。
```
nc <cluster_IP> 30102 --sctp
```
```
# nc <cluster_IP> 30102 --sctp
```
  Copy to clipboardCopied

第14章 PTP ハードウェアの使用

14.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 対応デバイスと連携します。

14.1.1. PTP ドメインの要素

PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。PTP によって同期されるクロックは、リーダーとフォロワーの階層で構成されています。この階層は、1 クロックごとに実行される best master clock (BMC) アルゴリズムによって自動的に作成および更新されます。フォロワークロックはリーダークロックと同期しており、フォロワークロック自体が他のダウンストリームクロックのソースになることができます。

図14.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 タイムサービスの無効化を参照してください。

14.1.2. OpenShift Container Platform ノードの linuxptp および gpsd の概要

OpenShift Container Platform は、高精度のネットワーク同期のために、PTP Operator とともに linuxptp および gpsd パッケージを使用します。linuxptp パッケージは、ネットワーク内の PTP タイミング用のツールとデーモンを提供します。Global Navigation Satellite System (GNSS) 対応の NIC を備えたクラスターホストは、GNSS クロックソースとのインターフェイスに gpsd を使用します。

linuxptp パッケージには、システムクロック同期用の ts2phc、pmc、ptp4l、および phc2sys プログラムが含まれています。

ts2phc

ts2phc は、PTP デバイス間で PTP ハードウェアクロック (PHC) を高精度で同期します。ts2phc はグランドマスタークロック設定で使用されます。Global Navigation Satellite System (GNSS) などの高精度クロックソースから正確なタイミング信号を受信します。GNSS は、大規模な分散ネットワークで使用するための、正確で信頼性の高い同期時刻ソースを提供します。GNSS クロックは通常、数ナノ秒の精度で時刻情報を提供します。

ts2phc システムデーモンは、グランドマスタークロックから時刻情報を読み取り、PHC 形式に変換することにより、グランドマスタークロックからのタイミング情報をネットワーク内の他の PTP デバイスに送信します。PHC 時間は、ネットワーク内の他のデバイスがクロックをグランドマスタークロックと同期させるために使用されます。

pmc

pmc は、IEEE 標準 1588.1588 に従って PTP 管理クライアント (pmc) を実装します。pmc は、ptp4l システムデーモンの基本的な管理アクセスを提供します。pmc は、標準入力から読み取り、選択されたトランスポート経由で出力を送信し、受信した応答を出力します。

ptp4l

ptp4l は、PTP 境界クロックと通常のクロックを実装し、システムデーモンとして実行されます。ptp4l は、以下を行います。

ハードウェアタイムスタンプを使用して PHC をソースクロックに同期します。
ソフトウェアタイムスタンプを使用してシステムクロックをソースクロックに同期します。

phc2sys

phc2sys は、システムクロックをネットワークインターフェイスコントローラー (NIC) 上の PHC に同期します。phc2sys システムデーモンは、PHC のタイミング情報を継続的に監視します。PHC はタイミングエラーを検出すると、システムクロックを修正します。

gpsd パッケージには、ホストクロックと GNSS クロックを同期するためのプログラム ubxtool、gspipe、gpsd が含まれています。

ubxtool: ubxtool CLI を使用すると、u-blox GPS システムと通信できます。ubxtool CLI は、u-blox バイナリープロトコルを使用して GPS と通信します。
gpspipe: gpspipe は gpsd 出力に接続し、それを stdout にパイプします。
gpsd: gpsd は、ホストに接続されている 1 つ以上の GPS または AIS 受信機を監視するサービスデーモンです。

14.1.3. PTP グランドマスタークロックの GNSS タイミングの概要

OpenShift Container Platform は、クラスター内の Global Navigation Satellite System (GNSS) ソースおよびグランドマスタークロック (T-GM) からの高精度 PTP タイミングの受信をサポートします。

重要

OpenShift Container Platform は、Intel E810 Westport Channel NIC を使用した GNSS ソースからの PTP タイミングのみをサポートします。

図14.2 GNSS および T-GM との同期の概要

Global Navigation Satellite System (GNSS)

GNSS は、測位情報、ナビゲーション情報、タイミング情報を世界中の受信機に提供するために使用される衛星ベースのシステムです。PTP では、高精度で安定した基準クロックソースとして GNSS 受信機がよく使用されます。これらの受信機は、複数の GNSS 衛星から信号を受信し、正確な時刻情報を計算できます。GNSS から取得したタイミング情報は、PTP グランドマスタークロックの基準として使用されます。

GNSS を基準として使用することにより、PTP ネットワークのグランドマスタークロックは、他のデバイスに高精度のタイムスタンプを提供し、ネットワーク全体での正確な同期を可能にします。

Digital Phase-Locked Loop (DPLL)

DPLL はネットワーク内の各 PTP ノード間のクロック同期を提供します。DPLL は、ローカルシステムクロック信号の位相を、受信同期信号 (PTP グランドマスタークロックからの PTP メッセージなど) の位相と比較します。DPLL は、ローカルクロックの周波数と位相を継続的に調整して、ローカルクロックと基準クロック間の位相差を最小限に抑えます。

GNSS 同期 PTP グランドマスタークロックでのうるう秒イベントの処理

うるう秒は、協定世界時 (UTC) を国際原子時 (TAI) と同期させるために、時折適用される 1 秒の調整です。UTC のうるう秒は予測できません。leap-seconds.list に、国際的に合意されたうるう秒が掲載されています。このファイルは、Earth Rotation and Reference Systems Service (IERS) によって定期的に更新されます。うるう秒が処理されないと、遠端の RAN ネットワークに大きな影響が及ぶ可能性があります。これにより、遠端の RAN アプリケーションが音声通話とデータセッションを直ちに切断する可能性があります。

14.1.4. PTP およびクロック同期エラーイベントについて

仮想 RAN (vRAN) などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。PTP クロック同期エラーは、分散ユニット (DU) で実行している vRAN アプリケーションなど、低レイテンシーアプリケーションのパフォーマンスおよび信頼性に悪影響を及ぼす可能性があります。

PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークの OTA(Over the Air) トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。

イベント通知は、同じ DU ノード上で実行されている vRAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング (pub-sub メッセージング) は、非同期のサービス間通信アーキテクチャーです。このアーキテクチャーでは、トピックにパブリッシュされたメッセージが、そのトピックのすべてのサブスクライバーによって即座に受信されます。

PTP Operator は、すべての PTP 対応ネットワークインターフェイスの高速イベント通知を生成します。このイベントには、HTTP メッセージバス経由で cloud-event-proxy サイドカーコンテナーを使用してアクセスできます。

注記

PTP 高速イベント通知は、PTP 通常クロック、PTP グランドマスタークロック、または PTP 境界クロックを使用するように設定されたネットワークインターフェイスで使用できます。

14.1.5. 2 カード E810 NIC 設定リファレンス

OpenShift Container Platform は、シングルおよびデュアル NIC Intel E810 ハードウェアをサポートし、グランドマスタークロック (T-GM) および境界クロック (T-BC) の PTP タイミングを実現します。

デュアル NIC グランドマスタークロック

デュアル NIC ハードウェアを備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 枚目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。

デュアル NIC グランドマスタークロックは、Remote Radio Unit (RRU) と Baseband Unit (BBU) が同じ無線セルサイトに配置されている分散型 RAN (D-RAN) 構成の機能です。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。

図14.3 デュアル NIC グランドマスタークロック

GNSS タイミングソースとダウンストリームの PTP 境界クロックおよび通常のクロックに接続されたデュアル NIC PTP グランドマスタークロック

注記

デュアル NIC T-GM 設定では、1 つの ts2phc プログラムが、各 NIC に 1 つずつ存在する合計 2 つの PTP ハードウェアクロック (PHC) 上で動作します。

デュアル NIC 境界クロック

ミッドバンドスペクトルカバレッジを提供する 5G 電話会社ネットワークの場合、各仮想分散ユニット (vDU) には 6 つの無線ユニット (RU) への接続が必要です。これらの接続を確立するには、各 vDU ホストに境界クロックとして設定された 2 つの NIC が必要です。

デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給することができます。

デュアル NIC 境界クロックを備えた高可用性システムクロック

Intel E810-XXVDA4 Salem チャネルデュアル NIC ハードウェアを、高可用性システムクロックのタイミングを提供するデュアル PTP 境界クロックとして設定できます。この設定は、別々の NIC 上に複数のタイムソースがある場合に便利です。高可用性があれば、どちらかのタイミングソースが失われたり切断されたりしても、ノードのタイミング同期が失われることはありません。

各 NIC は同じアップストリームリーダークロックに接続されます。高可用性境界クロックは、複数の PTP ドメインを使用してターゲットシステムクロックと同期します。T-BC が高可用性である場合、NIC PHC クロックを同期する 1 つ以上の ptp4l インスタンスが失敗した場合でも、ホストシステムクロックは正しいオフセットを維持できます。単一の SFP ポートまたはケーブルに障害が発生した場合、境界クロックはリーダークロックと同期したままになります。

境界クロックリーダーソースの選択は、A-BMCA アルゴリズムを使用して行われます。詳細は、ITU-T recommendation G.8275.1 を参照してください。

14.1.6. 3 カード Intel E810 PTP グランドマスタークロック

OpenShift Container Platform は、PTP グランドマスタークロック (T-GM) として 3 つの Intel E810 NIC を使用するクラスターホストをサポートしています。

3 カードグランドマスタークロック

3 枚の NIC を備えたクラスターホストを PTP グランドマスタークロックとして使用できます。1 枚目の NIC は、Global Navigation Satellite System (GNSS) からタイミング情報を受信します。2 枚目と 3 枚目の NIC は、E810 NIC フェイスプレート上の SMA1 Tx/Rx 接続を使用して、1 つ目の NIC からタイミング情報を受信します。クラスターホストのシステムクロックは、GNSS 衛星に接続されている NIC から同期されます。

3 カード NIC グランドマスタークロックは、Radio Unit (RU) がフロントホールスイッチなしで分散ユニット (DU) に直接接続される分散 RAN (D-RAN) 構成に使用できます (例: RU と DU が同じ無線セルサイトにある場合)。D-RAN は、コアネットワークにリンクするバックホール接続により、複数のサイトに無線機能を分散します。

図14.4 3 カード Intel E810 PTP グランドマスタークロック

GNSS タイミングソースとダウンストリームの PTP 境界クロックおよび通常のクロックに接続された 3 カード NIC PTP グランドマスタークロック

注記

3 カードの T-GM 設定では、1 つの ts2phc プロセスがシステム内の 3 つの ts2phc インスタンスとして報告されます。

14.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.18 では、Intel E810 NIC が PtpConfig プラグインでサポートされています。

14.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

namespace CR を作成します。

oc create -f ptp-namespace.yaml

$ oc create -f ptp-namespace.yaml

Copy to clipboard

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

OperatorGroup CR を作成します。

oc create -f ptp-operatorgroup.yaml

$ oc create -f ptp-operatorgroup.yaml

Copy to clipboard

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

Subscription CR を作成します。
```
oc create -f ptp-sub.yaml
```
```
$ oc create -f ptp-sub.yaml
```
Copy to clipboardCopied

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

出力例

Name                         Phase
4.18.0-202301261535          Succeeded

Name                         Phase
4.18.0-202301261535          Succeeded

Copy to clipboard

14.2.2. Web コンソールを使用した PTP Operator のインストール

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

注記

先のセクションで説明されているように namespace および Operator グループを作成する必要があります。

手順

OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
3. Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
オプション: PTP Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに切り替えます。
2. PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。
  注記
  インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
  Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
  - Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
  - Workloads → Pods ページに移動し、openshift-ptp プロジェクトで Pod のログを確認します。

14.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

出力例

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
...

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

1: name パラメーターの値は、親ノードの名前と同じです。
2: デバイス コレクションには、PTP Operator がノードに対して検出した PTP 対応デバイスのリストが含まれています。

14.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 ファイルに保存します。

例14.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

注記

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

検証

PtpConfig プロファイルがノードに適用されていることを確認します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

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

プロファイルが正しいことを確認します。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

出力例

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

14.2.4.1. デュアル E810 NIC のグランドマスタークロックとして linuxptp サービスの設定

NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 2 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。

次の E810 NIC の場合、T-GM として linuxptp サービスを設定できます。

Intel E810-XXVDA4T Westport Channel NIC
Intel E810-CQDA2T Logan Beach NIC

分散型 RAN (D-RAN) のユースケースでは、次の方法で 2 カード NIC の PTP を設定できます。

NIC 1 を、Global Navigation Satellite System (GNSS) のタイムソースに同期します。
NIC 2 を、NIC 1 によって提供される 1PPS タイミング出力に同期します。この設定は、PtpConfig CR の PTP ハードウェアプラグインによって提供します。

2 カード PTP T-GM 設定では、ptp4l のインスタンス 1 つと ts2phc のインスタンス 1 つが使用されます。ptp4l および ts2phc プログラムは、各 NIC に 1 つずつ存在する 2 つの PTP ハードウェアクロック (PHC) 上で動作するようにそれぞれ設定されています。ホストのシステムクロックは、GNSS タイムソースに接続されている NIC から同期されます。

注記

次の PtpConfig CR の例をベースとして使用し、linuxptp サービスをデュアル Intel E810 ネットワークインターフェイスの T-GM として設定します。

前提条件

実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 2 枚の Intel E810 NIC がインストールされている。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP Operator をインストールします。

手順

PtpConfig CR を作成します。以下に例を示します。

次の YAML を grandmaster-clock-ptp-config-dual-nics.yaml ファイルに保存します。

例14.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

注記

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

検証

PtpConfig プロファイルがノードに適用されていることを確認します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

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

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

出力例

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

14.2.4.2. 3 カード E810 NIC のグランドマスタークロックとして linuxptp サービスを設定する

NIC を設定する PtpConfig カスタムリソース (CR) を作成することにより、linuxptp サービス (ptp4l、phc2sys、ts2phc) を 3 カード E810 NIC のグランドマスタークロック (T-GM) として設定できます。

次の E810 NIC の場合、3 枚の NIC を使用する T-GM として linuxptp サービスを設定できます。

Intel E810-XXVDA4T Westport Channel NIC
Intel E810-CQDA2T Logan Beach NIC

分散型 RAN (D-RAN) のユースケースでは、次の方法で 3 カード NIC の PTP を設定できます。

NIC 1 を、Global Navigation Satellite System (GNSS) に同期します。
NIC 2 と 3 を、1PPS フェイスプレート接続で NIC 1 に同期します。

次の PtpConfig CR の例をベースとして使用し、linuxptp サービスを 3 カード Intel E810 の T-GM として設定します。

前提条件

実稼働環境の T-GM クロックの場合は、ベアメタルクラスターホストに 3 枚の Intel E810 NIC がインストールされている。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP Operator をインストールします。

手順

PtpConfig CR を作成します。以下に例を示します。

次の YAML を three-nic-grandmaster-clock-ptp-config.yaml ファイルに保存します。

例14.3 3 カード E810 NIC の PTP グランドマスタークロック設定

# In this example, the three cards are connected via SMA cables:
# - $iface_timeTx1 has the GNSS signal input
# - $iface_timeTx2 SMA1 is connected to $iface_timeTx1 SMA1
# - $iface_timeTx3 SMA1 is connected to $iface_timeTx1 SMA2
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: gm-3card
  namespace: openshift-ptp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "10"
spec:
  profile:
  - name: grandmaster
    ptp4lOpts: -2 --summary_interval -4
    phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_timeTx1 -n 24
    ptpSchedulingPolicy: SCHED_FIFO
    ptpSchedulingPriority: 10
    ptpSettings:
      logReduce: "true"
    plugins:
      e810:
        enableDefaultConfig: false
        settings:
          LocalHoldoverTimeout: 14400
          LocalMaxHoldoverOffSet: 1500
          MaxInSpecOffset: 1500
        pins:
          # Syntax guide:
          # - The 1st number in each pair must be one of:
          #    0 - Disabled
          #    1 - RX
          #    2 - TX
          # - The 2nd number in each pair must match the channel number
          $iface_timeTx1:
            SMA1: 2 1
            SMA2: 2 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_timeTx2:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_timeTx3:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
        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
      #example value of nmea_serialport is /dev/gnss0
      ts2phc.nmea_serialport (?<gnss_serialport>[/\w\s/]+)
      leapfile /usr/share/zoneinfo/leap-seconds.list
      [$iface_timeTx1]
      ts2phc.extts_polarity rising
      ts2phc.extts_correction 0
      [$iface_timeTx2]
      ts2phc.master 0
      ts2phc.extts_polarity rising
      #this is a measured value in nanoseconds to compensate for SMA cable delay
      ts2phc.extts_correction -10
      [$iface_timeTx3]
      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_timeTx1]
      masterOnly 1
      [$iface_timeTx1_1]
      masterOnly 1
      [$iface_timeTx1_2]
      masterOnly 1
      [$iface_timeTx1_3]
      masterOnly 1
      [$iface_timeTx2]
      masterOnly 1
      [$iface_timeTx2_1]
      masterOnly 1
      [$iface_timeTx2_2]
      masterOnly 1
      [$iface_timeTx2_3]
      masterOnly 1
      [$iface_timeTx3]
      masterOnly 1
      [$iface_timeTx3_1]
      masterOnly 1
      [$iface_timeTx3_2]
      masterOnly 1
      [$iface_timeTx3_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
    ptpClockThreshold:
      holdOverTimeout: 5
      maxOffsetThreshold: 1500
      minOffsetThreshold: -1500
  recommend:
  - profile: grandmaster
    priority: 4
    match:
    - nodeLabel: node-role.kubernetes.io/$mcp

# In this example, the three cards are connected via SMA cables:
# - $iface_timeTx1 has the GNSS signal input
# - $iface_timeTx2 SMA1 is connected to $iface_timeTx1 SMA1
# - $iface_timeTx3 SMA1 is connected to $iface_timeTx1 SMA2
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: gm-3card
  namespace: openshift-ptp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "10"
spec:
  profile:
  - name: grandmaster
    ptp4lOpts: -2 --summary_interval -4
    phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_timeTx1 -n 24
    ptpSchedulingPolicy: SCHED_FIFO
    ptpSchedulingPriority: 10
    ptpSettings:
      logReduce: "true"
    plugins:
      e810:
        enableDefaultConfig: false
        settings:
          LocalHoldoverTimeout: 14400
          LocalMaxHoldoverOffSet: 1500
          MaxInSpecOffset: 1500
        pins:
          # Syntax guide:
          # - The 1st number in each pair must be one of:
          #    0 - Disabled
          #    1 - RX
          #    2 - TX
          # - The 2nd number in each pair must match the channel number
          $iface_timeTx1:
            SMA1: 2 1
            SMA2: 2 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_timeTx2:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_timeTx3:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
        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
      #example value of nmea_serialport is /dev/gnss0
      ts2phc.nmea_serialport (?<gnss_serialport>[/\w\s/]+)
      leapfile /usr/share/zoneinfo/leap-seconds.list
      [$iface_timeTx1]
      ts2phc.extts_polarity rising
      ts2phc.extts_correction 0
      [$iface_timeTx2]
      ts2phc.master 0
      ts2phc.extts_polarity rising
      #this is a measured value in nanoseconds to compensate for SMA cable delay
      ts2phc.extts_correction -10
      [$iface_timeTx3]
      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_timeTx1]
      masterOnly 1
      [$iface_timeTx1_1]
      masterOnly 1
      [$iface_timeTx1_2]
      masterOnly 1
      [$iface_timeTx1_3]
      masterOnly 1
      [$iface_timeTx2]
      masterOnly 1
      [$iface_timeTx2_1]
      masterOnly 1
      [$iface_timeTx2_2]
      masterOnly 1
      [$iface_timeTx2_3]
      masterOnly 1
      [$iface_timeTx3]
      masterOnly 1
      [$iface_timeTx3_1]
      masterOnly 1
      [$iface_timeTx3_2]
      masterOnly 1
      [$iface_timeTx3_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
    ptpClockThreshold:
      holdOverTimeout: 5
      maxOffsetThreshold: 1500
      minOffsetThreshold: -1500
  recommend:
  - profile: grandmaster
    priority: 4
    match:
    - nodeLabel: node-role.kubernetes.io/$mcp

Copy to clipboard

注記

ts2phc.nmea_serialport の値を /dev/gnss0 に設定します。

以下のコマンドを実行して CR を作成します。

oc create -f three-nic-grandmaster-clock-ptp-config.yaml

$ oc create -f three-nic-grandmaster-clock-ptp-config.yaml

Copy to clipboard

検証

PtpConfig プロファイルがノードに適用されていることを確認します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
linuxptp-daemon-74m3q         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
ptp-operator-5f4f48d7c-x6zkn  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com

NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
linuxptp-daemon-74m3q         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
ptp-operator-5f4f48d7c-x6zkn  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com

Copy to clipboard

プロファイルが正しいことを確認します。次のコマンドを実行し、PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを調べます。

oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-74m3q -n openshift-ptp -c linuxptp-daemon-container

Copy to clipboard

出力例

ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp11 1
ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp7 2
ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp14 3
ts2phc[2527.586]: [ts2phc.0.config:7] nmea delay: 56308811 ns
ts2phc[2527.586]: [ts2phc.0.config:6] /dev/ptp14 offset          0 s2 freq      +0 4
ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp7 offset          0 s2 freq      +0 5
ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp11 offset          0 s2 freq      -0 6
I0324 14:25:05.000439  106907 stats.go:61] state updated for ts2phc =s2
I0324 14:25:05.000504  106907 event.go:419] dpll State s2, gnss State s2, tsphc state s2, gm state s2,
I0324 14:25:05.000906  106907 stats.go:61] state updated for ts2phc =s2
I0324 14:25:05.001059  106907 stats.go:61] state updated for ts2phc =s2
ts2phc[1742826305]:[ts2phc.0.config] ens4f0 nmea_status 1 offset 0 s2
GM[1742826305]:[ts2phc.0.config] ens4f0 T-GM-STATUS s2 7

ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp11 1
ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp7 2
ts2phc[2527.586]: [ts2phc.0.config:7] adding tstamp 1742826342.000000000 to clock /dev/ptp14 3
ts2phc[2527.586]: [ts2phc.0.config:7] nmea delay: 56308811 ns
ts2phc[2527.586]: [ts2phc.0.config:6] /dev/ptp14 offset          0 s2 freq      +0 4
ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp7 offset          0 s2 freq      +0 5
ts2phc[2527.587]: [ts2phc.0.config:6] /dev/ptp11 offset          0 s2 freq      -0 6
I0324 14:25:05.000439  106907 stats.go:61] state updated for ts2phc =s2
I0324 14:25:05.000504  106907 event.go:419] dpll State s2, gnss State s2, tsphc state s2, gm state s2,
I0324 14:25:05.000906  106907 stats.go:61] state updated for ts2phc =s2
I0324 14:25:05.001059  106907 stats.go:61] state updated for ts2phc =s2
ts2phc[1742826305]:[ts2phc.0.config] ens4f0 nmea_status 1 offset 0 s2
GM[1742826305]:[ts2phc.0.config] ens4f0 T-GM-STATUS s2 7

Copy to clipboard

1 2 3: ts2phc が PTP ハードウェアクロックを更新しています。
4 5 6: PTP デバイスと基準クロック間の PTP デバイスオフセット推定値は 0 ナノ秒です。PTP デバイスはリーダークロックと同期しています。
7: T-GM はロック状態 (s2) です。

関連情報

PTP 高速イベント通知パブリッシャーの設定

14.2.5. グランドマスタークロックの PtpConfig 設定リファレンス

このリファレンスでは、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロックとして設定する PtpConfig カスタムリソース (CR) の設定オプションを説明します。

表14.1 PTP グランドマスタークロックの PtpConfig 設定オプション
PtpConfig CR フィールド	説明
`plugins`	grandmaster クロック動作用に NIC を設定する `.exec.cmdline` オプションの配列を指定します。grandmaster クロック設定では、特定の PTP ピンを無効にする必要があります。プラグインメカニズムにより、PTP Operator は自動ハードウェア設定を行うことができます。Intel Westport Channel NIC または Intel Logan Beach NIC では、`enableDefaultConfig` フィールドが `true` に設定されていると、PTP Operator はハードコードされたスクリプトを実行して、NIC に必要な設定を実行します。
`ptp4lOpts`	`ptp4l` サービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名 `-i <interface>` およびサービス設定ファイル `-f /etc/ptp4l.conf` を含めないでください。
`ptp4lConf`	`ptp4l` をグランドマスタークロックとして起動するために必要な設定を指定します。たとえば、`ens2f1` インターフェイスは、ダウンストリームに接続されたデバイスを同期します。グランドマスタークロックの場合、`clockClass` を `6` に設定し、`clockAccuracy` を `0x27` に設定します。Global Navigation Satellite System (GNSS) からタイミング信号を受信する場合は、`timeSource` を `0x20` に設定します。
`tx_timestamp_timeout`	データを破棄する前に、送信者からの送信 (TX) タイムスタンプを待機する最大時間を指定します。
`boundary_clock_jbod`	JBOD 境界クロック時間遅延値を指定します。この値は、ネットワーク時間デバイス間で受け渡される時間値を修正するために使用されます。
`phc2sysOpts`	`phc2sys` サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator は `phc2sys` サービスを開始しません。注記ここにリストされているネットワークインターフェイスがグランドマスターとして設定されており、`ts2phcConf` および `ptp4lConf` フィールドで必要に応じて参照されていることを確認してください。
`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` 値を示します。`ptpClockThreshold` 値は、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。`holdOverTimeout` は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が `FREERUN` に変わるまでの時間値 (秒単位) です。`maxOffsetThreshold` および `minOffsetThreshold` 設定は、`CLOCK_REALTIME` (`phc2sys`) またはマスターオフセット (`ptp4l`) の値と比較するナノ秒単位のオフセット値を設定します。`ptp4l` または `phc2sys` のオフセット値がこの範囲外の場合、PTP クロックの状態が `FREERUN` に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が `LOCKED` に設定されます。
`ts2phcConf`	`ts2phc` コマンドの設定を設定します。 `Leapfile` は、PTP Operator コンテナーイメージ内の現在のうるう秒定義ファイルへのデフォルトパスです。 `ts2phc.nmea_serialport` は、NMEA GPS クロックソースに接続されているシリアルポートデバイスです。設定すると、`/dev/gnss<id>` で GNSS 受信機にアクセスできるようになります。ホストに複数の GNSS 受信機がある場合は、次のいずれかのデバイスを列挙することで正しいデバイスを見つけることができます。 `/sys/class/net/<eth_port>/device/gnss/` `/sys/class/gnss/gnss<id>/device/`
`ts2phcOpts`	`ts2phc` コマンドのオプションを設定します。
`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` はその例です。

14.2.5.1. グランドマスタークロッククラスの同期状態のリファレンス

次の表は、PTP グランドマスタークロック (T-GM) の gm.ClockClass の状態を示しています。クロッククラスの状態では、Primary Reference Time Clock (PRTC) またはその他のタイミングソースに関連する精度と安定性に基づいて T-GM クロックが分類されます。

ホールドオーバー仕様とは、PTP クロックがプライマリータイムソースから更新を受信せずに同期を維持できる時間です。

表14.2 T-GM クロッククラスの状態
クロッククラスの状態	説明
`gm.ClockClass 6`	T-GM クロックは `LOCKED` モードで PRTC に接続しています。たとえば、PRTC は GNSS タイムソースまで追跡できます。
`gm.ClockClass 7`	T-GM クロックは `HOLDOVER` モードであり、ホールドオーバー仕様の範囲内にあります。クロックソースはカテゴリー 1 の周波数ソースまで追跡できない場合があります。
`gm.ClockClass 248`	T-GM クロックは `FREERUN` モードです。

詳細は、"Phase/time traceability information", ITU-T G.8275.1/Y.1369.1 Recommendations を参照してください。

14.2.5.2. Intel E810 NIC ハードウェア設定リファレンス

ここでは、Intel E810 ハードウェアプラグインを使用して E810 ネットワークインターフェイスを PTP グランドマスタークロックとして設定する方法を説明します。ハードウェアピンの設定により、ネットワークインターフェイスがシステム内の他のコンポーネントやデバイスとどのようにやり取りするかが決まります。Intel E810 NIC には、外部 1PPS 信号用のコネクターが 4 つあります (SMA1、SMA2、U.FL1、U.FL2)。

表14.3 Intel E810 NIC ハードウェアコネクターの設定
ハードウェアピン	推奨設定	説明
`U.FL1`	`0 1`	`U.FL1` コネクター入力を無効にします。`U.FL1` コネクターは出力専用です。
`U.FL2`	`0 2`	`U.FL2` コネクター出力を無効にします。`U.FL2` コネクターは入力専用です。
`SMA1`	`0 1`	`SMA1` コネクター入力を無効にします。`SMA1` コネクターは双方向です。
`SMA2`	`0 2`	`SMA2` コネクター出力を無効にします。`SMA2` コネクターは双方向です。

注記

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>"1
    reportOutput: false

ublxCmds:
  - args:
      - "-P"
      - "29.20"
      - "-z"
      - "CFG-HW-ANT_CFG_VOLTCTRL,1"
      - "-z"
      - "CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>"1
    reportOutput: false

Copy to clipboard

1: 測定された T-GM アンテナ遅延オフセット (ナノ秒単位)。必要な遅延オフセット値を取得するには、外部テスト機器を使用してケーブル遅延を測定する必要があります。

次の表は、同等の ubxtool コマンドを示しています。

表14.4 Intel E810 ublxCmds の設定
ubxtool コマンド	説明
`ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1 -z CFG-TP-ANT_CABLEDELAY,<antenna_delay_offset>`	アンテナ電圧制御を有効にし、`UBX-MON-RF` および `UBX-INF-NOTICE` ログメッセージでアンテナステータスの報告を許可し、GPS アンテナケーブルシグナルの遅延をオフセットする `<antenna_delay_offset>` 値をナノ秒単位で設定します。
`ubxtool -P 29.20 -e GPS`	アンテナが GPS 信号を受信できるようにします。
`ubxtool -P 29.20 -d Galileo`	Galileo GPS 衛星から信号を受信するようにアンテナを設定します。
`ubxtool -P 29.20 -d GLONASS`	アンテナが GLONASS GPS 衛星から信号を受信できないようにします。
`ubxtool -P 29.20 -d BeiDou`	アンテナが BeiDou GPS 衛星から信号を受信できないようにします。
`ubxtool -P 29.20 -d SBAS`	アンテナが SBAS GPS 衛星から信号を受信できないようにします。
`ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000`	GNSS 受信機のサーベイインプロセスを設定して、初期位置の推定を改善します。最適な結果が得られるまでに最大 24 時間かかる場合があります。
`ubxtool -P 29.20 -p MON-HW`	ハードウェアの自動スキャンを 1 回実行し、NIC の状態と構成設定を報告します。

14.2.5.3. デュアル E810 NIC 設定リファレンス

ここでは、Intel E810 ハードウェアプラグインを使用して、E810 ネットワークインターフェイスのペアを PTP グランドマスタークロック (T-GM) として設定する方法を説明します。

デュアル NIC クラスターホストを設定する前に、1PPS フェイスプレート接続を使用して 2 つの NIC を SMA1 ケーブルで接続する必要があります。

デュアル NIC T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。

表14.5 E810 デュアル NIC T-GM PtpConfig CR リファレンス
PtpConfig フィールド	説明
`spec.profile.plugins.e810.pins`	PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。ピン `2 1` は、NIC 1 の `SMA1` の `1PPS OUT` 接続を有効にします。ピン `1 1` は、NIC 2 の `SMA1` の `1PPS IN` 接続を有効にします。
`spec.profile.ts2phcConf`	`ts2phcConf` フィールドは、NIC 1 と NIC 2 のパラメーターを設定するために使用します。NIC 2 には `ts2phc.master 0` を設定します。これにより、GNSS ではなく 1PPS 入力から NIC 2 のタイミングソースが設定されます。使用する特定の SMA ケーブルおよびケーブルの長さにより発生する遅延を補正するには、NIC 2 の `ts2phc.extts_correction` 値を設定します。設定する値は、具体的な測定値と SMA1 ケーブルの長さによって異なります。
`spec.profile.ptp4lConf`	複数の NIC のサポートを有効にするには、`boundary_lock_jbod` の値を 1 に設定します。

14.2.5.4. 3 カード E810 NIC 設定リファレンス

ここでは、3 カード E810 NIC を PTP グランドマスタークロック (T-GM) として設定する方法を説明します。

3 カードのクラスターホストを設定する前に、1PPS フェースプレート接続を使用して 3 枚の NIC を接続する必要があります。プライマリー NIC の 1PPS_out 出力は、他の 2 枚の NIC に提供されます。

3 カードの T-GM を設定する際は、SMA1 接続ポートを使用して NIC を接続する場合に発生する 1PPS 信号遅延を補正する必要があります。ケーブルの長さ、周囲温度、コンポーネントと製作公差などのさまざまな要因が信号遅延に影響を与える可能性があります。遅延を補正するには、信号遅延のオフセットに使用する特定の値を計算する必要があります。

表14.6 3 カード E810 T-GM PtpConfig CR リファレンス
PtpConfig フィールド	説明
`spec.profile.plugins.e810.pins`	PTP Operator E810 ハードウェアプラグインを使用して E810 ハードウェアピンを設定します。 `$iface_timeTx1.SMA1` は、NIC 1 の `SMA1` の `1PPS OUT` 接続を有効にします。 `$iface_timeTx1.SMA2` は、NIC 1 の `SMA2` の `1PPS OUT` 接続を有効にします。 `$iface_timeTx2.SMA1` と `$iface_timeTx3.SMA1` は、NIC 2 と NIC 3 の `SMA1` の `1PPS IN` 接続を有効にします。 `$iface_timeTx2.SMA2` と `$iface_timeTx3.SMA2` は、NIC 2 と NIC 3 の `SMA2` 接続を無効にします。
`spec.profile.ts2phcConf`	`ts2phcConf` フィールドは、NIC のパラメーターを設定するために使用します。NIC 2 と NIC 3 に `ts2phc.master 0` を設定します。これにより、GNSS ではなく 1PPS 入力から NIC 2 および NIC 3 のタイミングソースが設定されます。使用する特定の SMA ケーブルとケーブルの長さにより発生する遅延を補正するには、NIC 2 と NIC 3 の `ts2phc.extts_correction` 値を設定します。設定する値は、具体的な測定値と SMA1 ケーブルの長さによって異なります。
`spec.profile.ptp4lConf`	複数の NIC のサポートを有効にするには、`boundary_lock_jbod` の値を 1 に設定します。

14.2.6. GNSS をソースとするグランドマスタークロックのホールドオーバー

ホールドオーバーにより、Global Navigation Satellite System (GNSS) ソースが利用できない場合でもグランドマスター (T-GM) クロックは同期パフォーマンスを維持できます。この期間中、T-GM クロックは内部オシレーターとホールドオーバーパラメーターに依存してタイミングの中断を削減します。

PTPConfig カスタムリソース (CR) で次のホールドオーバーパラメーターを設定することにより、ホールドオーバー動作を定義できます。

MaxInSpecOffset: 許容される最大オフセットをナノ秒単位で指定します。T-GM クロックが MaxInSpecOffset 値を超えると、FREERUN 状態 (クロッククラス状態 gm.ClockClass 248) に遷移します。
LocalHoldoverTimeout: T-GM クロックが FREERUN 状態に遷移するまでホールドオーバー状態を維持する最大期間 (秒単位) を指定します。
LocalMaxHoldoverOffSet: ホールドオーバー状態にあるときに T-GM クロックが到達できる最大オフセットをナノ秒単位で指定します。

MaxInSpecOffset 値が LocalMaxHoldoverOffset 値より小さく、T-GM クロックが最大オフセット値を超える場合、T-GM クロックはホールドオーバー状態から FREERUN 状態に遷移します。

重要

LocalMaxHoldoverOffSet 値が MaxInSpecOffset 値より小さい場合、クロックが最大オフセットに達する前にホールドオーバータイムアウトが発生します。この問題を解決するには、MaxInSpecOffset フィールドと LocalMaxHoldoverOffset フィールドを同じ値に設定します。

クロッククラスの状態の詳細は、「グランドマスタークロッククラス同期状態リファレンス」のドキュメントを参照してください。

T-GM クロックは、ホールドオーバーパラメーターの LocalMaxHoldoverOffSet と LocalHoldoverTimeout を使用してスロープを計算します。スロープは、位相オフセットが時間の経過とともに変化するレートです。これはナノ秒/秒単位で測定され、設定された値は、指定された期間内にオフセットがどれだけ増加するかを示します。

T-GM クロックはスロープ値を使用して時間ドリフトを予測および補正し、ホールドオーバー中のタイミングの中断を削減します。T-GM クロックは、次の式を使用してスロープを計算します。

スロープ = localMaxHoldoverOffSet/localHoldoverTimeout
たとえば、LocalHoldOverTimeout パラメーターが 60 秒に設定され、LocalMaxHoldoverOffset パラメーターが 3000 ナノ秒に設定されている場合、スロープは次のように計算されます。
スロープ = 3000 ナノ秒/60 秒 = 50 ナノ秒/秒
T-GM クロックは 60 秒で最大オフセットに達します。

注記

位相オフセットはピコ秒からナノ秒に変換されます。その結果、ホールドオーバー中に計算された位相オフセットはナノ秒で表され、スロープはナノ秒/秒で表されます。

次の図は、GNSS をソースとする T-GM クロックのホールドオーバー動作を示しています。

図14.5 GNSS をソースとする T-GM クロックのホールドオーバー

GNSS シグナルが失われ、T-GM クロックが HOLDOVER モードになります。T-GM クロックは内部クロックを使用して時間の精度を維持します。

GNSS シグナルが復元され、T-GM クロックは再び LOCKED モードになります。GNSS シグナルが復元されると、ts2phc オフセット、Digital Phase-Locked Loop (DPLL) 位相オフセット、GNSS オフセットなど、同期チェーン内のすべての依存コンポーネントが安定した LOCKED モードに達した後にのみ、T-GM クロックは再び LOCKED モードになります。

GNSS シグナルが再び失われ、T-GM クロックは再度 HOLDOVER モードになります。タイムエラーの増加が始まります。

トレーサビリティの長期的な損失により、タイムエラーが MaxInSpecOffset しきい値を超えます。

GNSS シグナルが復元され、T-GM クロックが同期を再開します。タイムエラーの減少が始まります。

タイムエラーが減少し、MaxInSpecOffset しきい値内に戻ります。

関連情報

グランドマスタークロッククラスの同期状態のリファレンス

14.2.7. 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.18 では、デフォルトで自動うるう秒管理が有効になります。

前提条件

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 1
```
```
phc2sysOpts: -r -u 0 -m -N 8 -R 16 -S 2 -s ens2f0 -n 24 1
```
Copy to clipboardCopied
注記
以前は、過去のうるう秒を考慮するために、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 clipboardCopied

検証

設定した 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

出力例

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

leap-configmap リソースが PTP Operator によって正常に生成され、leap-seconds.list の最新バージョンに更新されていることを確認します。以下のコマンドを実行します。

oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}' 1

$ oc -n openshift-ptp get configmap leap-configmap -o jsonpath='{.data.<node_name>}' 1

Copy to clipboard

1 1: <node_name> は、自動うるう秒管理を使用する PTP T-GM クロックをインストールおよび設定したノードに置き換えます。ノード名内の特殊文字をエスケープします。たとえば、node-1\.example\.com とします。

出力例

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

14.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 を 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

表14.7 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

検証

PtpConfig プロファイルがノードに適用されていることを確認します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

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

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

出力例

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

関連情報

PTP ハードウェアの FIFO 優先スケジューリングの設定
PTP 高速イベント通知パブリッシャーの設定

14.2.8.1. linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定

NIC ごとに PtpConfig カスタムリソース (CR) オブジェクトを作成することにより、linuxptp サービス (ptp4l、phc2sys) をデュアル NIC ハードウェアの境界クロックとして設定できます。

前提条件

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: | 1
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 2

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

1: ptp4l を境界クロックとして開始するために必要なインターフェイスを指定します。たとえば、ens5f0 はグランドマスタークロックから同期し、ens5f1 は接続された機器から同期します。
2: phc2sysOpts の値が必要です。-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

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: | 1
      [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

1: 2 番目の NIC の境界クロックとして ptp4l を開始するために必要なインターフェイスを指定します。

注記

2 番目の NIC で phc2sys サービスを無効にするには、2 番目の PtpConfig CR から phc2sysOpts フィールドを完全に削除する必要があります。

次のコマンドを実行して、デュアル NIC PtpConfig CR を作成します。
1. 1 番目の NIC の PTP を設定する CR を作成します。
```
oc create -f boundary-clock-ptp-config-nic1.yaml
```
```
$ oc create -f boundary-clock-ptp-config-nic1.yaml
```
  Copy to clipboardCopied
2. 2 番目の NIC の PTP を設定する CR を作成します。
```
oc create -f boundary-clock-ptp-config-nic2.yaml
```
```
$ oc create -f boundary-clock-ptp-config-nic2.yaml
```
  Copy to clipboardCopied

検証

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

出力例

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

14.2.8.2. デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する

linuxptp サービス ptp4l および phc2sys を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。

高可用性システムクロックは、2 つの境界クロックとして設定されたデュアル NIC Intel E810 Salem チャネルハードウェアからの複数のタイムソースを使用します。2 つの境界クロックインスタンスが HA セットアップに参加し、それぞれ独自の設定プロファイルを持ちます。各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給します。

NIC を T-BC として設定する 2 つの PtpConfig カスタムリソース (CR) オブジェクトと、2 つの NIC 間の高可用性を設定する 3 番目の PtpConfig CR を作成します。

重要

HA を設定する PtpConfig CR で phc2SysOpts オプションを 1 回設定します。2 つの NIC を設定する PtpConfig CR で phc2sysOpts フィールドを空の文字列に設定します。これにより、2 つのプロファイルに対して個別の phc2sys プロセスがセットアップされなくなります。

3 番目の PtpConfig CR は、高可用性システムクロックサービスを設定します。CR は、ptp4l プロセスが実行されないように、ptp4lOpts フィールドを空の文字列に設定します。CR は、spec.profile.ptpSettings.haProfiles キーの下に ptp4l 設定のプロファイルを追加し、それらのプロファイルのカーネルソケットパスを phc2sys サービスに渡します。ptp4l 障害が発生すると、phc2sys サービスはバックアップ ptp4l 設定に切り替わります。プライマリープロファイルが再びアクティブになると、phc2sys サービスは元の状態に戻ります。

重要

HA を設定するために使用する 3 つの PtpConfig CR すべてに対して、spec.recommend.priority を同じ値に設定していることを確認します。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP Operator をインストールします。
Intel E810 Salem チャネルデュアル NIC を使用してクラスターノードを設定します。

手順

「linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定」の CR を各 CR の参照として使用して、NIC ごとに 1 つずつ、2 つの個別の PtpConfig CR を作成します。

phc2sysOpts フィールドに空の文字列を指定して、ha-ptp-config-nic1.yaml ファイルを作成します。以下に例を示します。

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ha-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "ha-ptp-config-profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 1
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    #...
    phc2sysOpts: "" 2

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ha-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "ha-ptp-config-profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 1
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    #...
    phc2sysOpts: "" 2

Copy to clipboard

1: ptp4l を境界クロックとして開始するために必要なインターフェイスを指定します。たとえば、ens5f0 はグランドマスタークロックから同期し、ens5f1 は接続された機器から同期します。
2: phc2sysOpts を空の文字列に設定します。これらの値は、高可用性を設定する PtpConfig CR の spec.profile.ptpSettings.haProfiles フィールドから入力されます。

次のコマンドを実行して、NIC 1 に PtpConfig CR を適用します。
```
oc create -f ha-ptp-config-nic1.yaml
```
```
$ oc create -f ha-ptp-config-nic1.yaml
```
Copy to clipboardCopied

phc2sysOpts フィールドに空の文字列を指定して、ha-ptp-config-nic2.yaml ファイルを作成します。以下に例を示します。

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ha-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "ha-ptp-config-profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |
      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
    #...
    phc2sysOpts: ""

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ha-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "ha-ptp-config-profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |
      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
    #...
    phc2sysOpts: ""

Copy to clipboard

次のコマンドを実行して、NIC 2 に PtpConfig CR を適用します。
```
oc create -f ha-ptp-config-nic2.yaml
```
```
$ oc create -f ha-ptp-config-nic2.yaml
```
Copy to clipboardCopied

HA システムクロックを設定する PtpConfig CR を作成します。以下に例を示します。

ptp-config-for-ha.yaml ファイルを作成します。2 つの NIC を設定する PtpConfig CR で設定されている metadata.name フィールドと一致するように haProfiles を設定します。例: haProfiles: ha-ptp-config-nic1,ha-ptp-config-nic2

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: "" 1
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: "" 1
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

Copy to clipboard

1: ptp4lOpts フィールドを空の文字列に設定します。空でない場合、p4ptl プロセスは重大なエラーで開始されます。

重要

個々の NIC を設定する PtpConfig CR の前に、高可用性 PtpConfig CR を適用しないでください。

次のコマンドを実行して、HA PtpConfig CR を適用します。
```
oc create -f ptp-config-for-ha.yaml
```
```
$ oc create -f ptp-config-for-ha.yaml
```
Copy to clipboardCopied

検証

PTP Operator が PtpConfig CR を正しく適用したことを確認します。以下の手順を実行します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkrb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
ptp-operator-657bbq64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkrb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
ptp-operator-657bbq64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to clipboard

注記

linuxptp-daemon Pod は 1 つだけ存在する必要があります。

次のコマンドを実行して、プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。

oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-4xkrb -n openshift-ptp -c linuxptp-daemon-container

Copy to clipboard

出力例

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: ha-ptp-config-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: ha-ptp-config-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

14.2.9. 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

表14.8 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 clipboardCopied

検証

PtpConfig プロファイルがノードに適用されていることを確認します。

以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

oc get pods -n openshift-ptp -o wide

$ oc get pods -n openshift-ptp -o wide

Copy to clipboard

出力例

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

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

出力例

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

関連情報

PTP ハードウェアの FIFO 優先スケジューリングの設定
PTP 高速イベント通知パブリッシャーの設定

14.2.9.1. PTP の通常クロックリファレンスとしての Intel Columbiaville E800 シリーズ NIC

次の表は、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために、PTP リファレンス設定に加える必要がある変更を説明します。クラスターに適用する PtpConfig カスタムリソース (CR) に変更を加えます。

表14.9 Intel Columbiaville NIC の推奨 PTP 設定
PTP 設定	推奨設定
`phc2sysOpts`	`-a -r -m -n 24 -N 8 -R 16`
`tx_timestamp_timeout`	`50`
`boundary_clock_jbod`	`0`

注記

phc2sysOpts の場合、-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

関連情報

PTP 高速イベントを使用して linuxptp サービスを通常のクロックとして設定する CR の詳細な例は、linuxptp サービスを通常のクロックとして設定するを参照してください。

14.2.10. PTP ハードウェアの FIFO 優先スケジューリングの設定

低遅延のパフォーマンスを確保する必要のある通信業者などのデプロイメントタイプでは、PTP デーモンスレッドが、残りのインフラストラクチャーコンポーネントとともに、限られた CPU リソースで実行されます。デフォルトでは、PTP スレッドは SCHED_OTHER ポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。

スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFO ポリシーでスレッドを実行できるように、PTP Operator の linuxptp サービスを設定できます。PtpConfig CR に SCHED_FIFO が設定されている場合には、ptp4l と phc2sys は、PtpConfig CR の ptpSchedulingPriority フィールドで設定された優先順位で、chrt の下の親コンテナーで実行されます。

注記

ptpScheduling Policy の設定はオプションで、レイテンシーエラーが発生している場合にのみ必要となります。

手順

PtpConfig CR プロファイルを編集します。
```
oc edit PtpConfig -n openshift-ptp
```
```
$ oc edit PtpConfig -n openshift-ptp
```
Copy to clipboardCopied

ptpSchedulingPolicy と ptpSchedulingPriority フィールドを変更します。

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

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

1: ptp4l と phc2sys プロセスのスケジューリングポリシー。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO を使用してください。
2: 必須。ptp4l および phc2sys プロセスの FIFO 優先度の設定に使用する 1～65 の整数値を設定します。

保存して終了すると、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

出力例

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

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

出力例

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

14.2.11. 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

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

注記

デバッグの目的で、この仕様を 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

出力例

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

次のコマンドを実行して、マスターオフセットメッセージがログから除外されていることを確認します。
```
oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset" 1
```
```
$ oc -n openshift-ptp logs <linux_daemon_container> -c linuxptp-daemon-container | grep "master offset" 1
```
Copy to clipboardCopied
1
<linux_daemon_container> は、linuxptp-daemon Pod の名前です (例: linuxptp-daemon-gmv2n)。
logReduce 仕様を設定する場合、このコマンドは linuxptp デーモンのログに master offset のインスタンスを報告しません。

14.2.12. 一般的な 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

出力例

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

注記

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

出力例

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

ノードで利用可能な 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

ここでは、以下のようになります。

<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

対応するノードの 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

出力例

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

リモートシェルが必要な 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 clipboardCopied
ここでは、以下のようになります。
<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

ノードがプライマリークロックに正常に同期されたときの出力例

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

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

出力例

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

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

出力例

$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

14.2.13. Intel 800 シリーズ NIC の CGU の DPLL ファームウェアバージョンを取得する

クラスターノードへのデバッグシェルを開き、NIC ハードウェアを照会することで、Intel 800 シリーズ NIC の Clock Generation Unit (CGU) の digital phase-locked loop (DPLL) ファームウェアバージョンを取得できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
クラスターホストに Intel 800 シリーズ NIC がインストールされている。
PTP をサポートするホストを含むベアメタルクラスターに PTP Operator をインストールしている。

手順

次のコマンドを実行してデバッグ Pod を起動します。
```
oc debug node/<node_name>
```
```
$ oc debug node/<node_name>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<node_name>
Intel 800 シリーズ NIC をインストールしたノードです。

devlink ツールと、NIC がインストールされているバスおよびデバイス名を使用して、NIC の CGU ファームウェアバージョンを確認します。たとえば、以下のコマンドを実行します。

devlink dev info <bus_name>/<device_name> | grep cgu

sh-4.4# devlink dev info <bus_name>/<device_name> | grep cgu

Copy to clipboard

ここでは、以下のようになります。

<bus_name>: NIC がインストールされているバスです (例: pci)。
<device_name>: NIC デバイス名です (例: 0000:51:00.0)。

出力例

cgu.id 36 1
fw.cgu 8032.16973825.6021 2

cgu.id 36 1
fw.cgu 8032.16973825.6021 2

Copy to clipboard

1: CGU ハードウェアリビジョン番号
2: CGU で実行されている DPLL ファームウェアバージョン。DPLL ファームウェアバージョンは 6201、DPLL モデルは 8032 です。文字列 16973825 は、DPLL ファームウェアバージョン (1.3.0.1) のバイナリーバージョンの短縮表現です。

注記

ファームウェアバージョンには、先頭のニブルと、バージョン番号の各部分に対する 3 つのオクテットがあります。16973825 を 2 進数で表すと 0001 0000 0011 0000 0000 0000 0001 になります。バイナリー値を使用してファームウェアバージョンをデコードします。以下に例を示します。

表14.10 DPLL ファームウェアバージョン
バイナリー部分	10 進数値
`0001`	1
`0000 0011`	3
`0000 0000`	0
`0000 0001`	1

14.2.14. PTP Operator データの収集

oc adm must-gather コマンドを使用すると、PTP Operator に関連する機能やオブジェクトなど、クラスターに関する情報を収集できます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
OpenShift CLI (oc) がインストールされている。
PTP Operator がインストールされている。

手順

must-gather を使用して PTP Operator データを収集するには、PTP Operator must-gather イメージを指定する必要があります。

oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.18

$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.18

Copy to clipboard

14.3. REST API v2 を使用した PTP イベントコンシューマーアプリケーションの開発

ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v2 を使用して PTP イベントをサブスクライブします。

注記

以下の情報は、PTP イベントを使用するコンシューマーアプリケーションを開発するための一般的なガイダンスです。完全なイベントコンシューマーアプリケーションの例は、この情報の範囲外です。

関連情報

PTP イベント REST API v2 リファレンス

14.3.1. PTP 高速イベント通知フレームワークについて

Precision Time Protocol (PTP) 高速イベント REST API v2 を使用して、ベアメタルクラスターノードが生成する PTP イベントにクラスターアプリケーションをサブスクライブします。

注記

高速イベント通知フレームワークは、通信に REST API を使用します。PTP イベント REST API v1 および v2 は、O-RAN ALLIANCE 仕様から入手できる O-RAN O-Cloud Notification API 仕様 for Event Consumers 3.0 に基づいています。

PTP イベント REST API v2 のみが O-RAN v3 に準拠しています。

14.3.2. PTP イベント REST API v2 を使用して PTP イベントを取得

アプリケーションは、プロデューサー側のクラウドイベントプロキシーサイドカーで O-RAN v3 互換の REST API を使用して PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。

図14.6 PTP イベントプロデューサー REST API v2 からの PTP 高速イベントの使用の概要

PTP イベントプロデューサー REST API からの PTP 高速イベントの使用の概要

イベントはクラスターホストで生成されます。: PTP Operator が管理する Pod の linuxptp-daemon プロセスは、Kubernetes DaemonSet として実行され、さまざまな linuxptp プロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用の ts2phc) を管理します。linuxptp-daemon は、イベントを UNIX ドメインソケットに渡します。
イベントが cloud-event-proxy サイドカーに渡されます。: PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の cloud-event-proxy サイドカーに渡します。cloud-event-proxy は、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。
イベントが公開される: PTP Operator 管理 Pod 内の cloud-event-proxy サイドカーはイベントを処理し、PTP イベント REST API v2 を使用してイベントを公開します。
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します: コンシューマーアプリケーションは、プロデューサー cloud-event-proxy サイドカーに API リクエストを送信して、PTP イベントサブスクリプションを作成します。サブスクライブされると、コンシューマーアプリケーションはリソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。

14.3.3. PTP 高速イベント通知パブリッシャーの設定

クラスター内のネットワークインターフェイスの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース (CR) で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。

前提条件

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

手順

デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
1. 次の 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:
    apiVersion: "2.0" 1
    enableEventPublisher: true 2
```
```
apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    apiVersion: "2.0" 1
    enableEventPublisher: true 2
```
  Copy to clipboardCopied
  1
  ptpEventConfig.apiVersion を "2.0" に設定して、PTP イベントプロデューサーの PTP イベント REST API v2 を有効にします。デフォルト値は "1.0" です。
  2
  enableEventPublisher を true に設定して、PTP 高速イベント通知を有効にします。
  注記
  OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、PtpOperatorConfig リソースの spec.ptpEventConfig.transportHost フィールドを設定する必要はありません。
2. PtpOperatorConfig CR を更新します。
```
oc apply -f ptp-operatorconfig.yaml
```
```
$ oc apply -f ptp-operatorconfig.yaml
```
  Copy to clipboardCopied
PTP 対応インターフェイスの PtpConfig カスタムリソースを作成し、ptpClockThreshold および ptp4lOpts に必要な値を設定します。次の YAML は、PtpConfig CR で設定する必要のある値 (必須) を示しています。
```
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
```
```
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 clipboardCopied
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 に設定されます。

関連情報

PTP 高速イベントを使用して linuxptp サービスを通常のクロックとして設定する CR の詳細な例は、linuxptp サービスを通常のクロックとして設定するを参照してください。

14.3.4. PTP イベント REST API v2 コンシューマーアプリケーションリファレンス

PTP イベントコンシューマーアプリケーションには次の機能が必要です。

POST ハンドラーで実行され、クラウドネイティブ PTP イベントの JSON ペイロードを受信する Web サービス
PTP イベントプロデューサーをサブスクライブするための createSubscription 関数
PTP イベントプロデューサーの現在の状態をポーリングする getCurrentState 関数

次の Go スニペットの例は、これらの要件を示しています。

Go での PTP イベントコンシューマーサーバー関数の例

func server() {
  http.HandleFunc("/event", getEvent)
  http.ListenAndServe(":9043", 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))
  }
  w.WriteHeader(http.StatusNoContent)
}

func server() {
  http.HandleFunc("/event", getEvent)
  http.ListenAndServe(":9043", 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))
  }
  w.WriteHeader(http.StatusNoContent)
}

Copy to clipboard

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 v2 REST API
s1,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/sync-state")
s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/lock-state")
s3,_:=createsubscription("/cluster/node/<node_name>/sync/gnss-status/gnss-sync-status")
s4,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state")
s5,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/clock-class")

// Create PTP event subscriptions POST
func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) {
  var status int
  apiPath := "/api/ocloudNotifications/v2/"
  localAPIAddr := "consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" // vDU service API address
  apiAddr := "ptp-event-publisher-service-<node_name>.openshift-ptp.svc.cluster.local:9043" 1
  apiVersion := "2.0"

  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, apiVersion)
  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 v2 REST API
s1,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/sync-state")
s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/lock-state")
s3,_:=createsubscription("/cluster/node/<node_name>/sync/gnss-status/gnss-sync-status")
s4,_:=createsubscription("/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state")
s5,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/clock-class")

// Create PTP event subscriptions POST
func createSubscription(resourceAddress string) (sub pubsub.PubSub, err error) {
  var status int
  apiPath := "/api/ocloudNotifications/v2/"
  localAPIAddr := "consumer-events-subscription-service.cloud-events.svc.cluster.local:9043" // vDU service API address
  apiAddr := "ptp-event-publisher-service-<node_name>.openshift-ptp.svc.cluster.local:9043" 1
  apiVersion := "2.0"

  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, apiVersion)
  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
}

Copy to clipboard

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: "ptp-event-publisher-service-<node_name>.openshift-ptp.svc.cluster.local:9043", 1
    Path: fmt.SPrintf("/api/ocloudNotifications/v2/%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: "ptp-event-publisher-service-<node_name>.openshift-ptp.svc.cluster.local:9043", 1
    Path: fmt.SPrintf("/api/ocloudNotifications/v2/%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)
  }
}

Copy to clipboard

1: <node_name> を、PTP イベントを生成しているノードの FQDN に置き換えます。compute-1.example.com はその例です。

14.3.5. PTP イベント REST API v2 を使用したイベントコンシューマーのデプロイメントとサービス CR の参照

PTP イベント REST API v2 で使用するために PTP イベントコンシューマーアプリケーションをデプロイする場合は、次の PTP イベントコンシューマーカスタムリソース (CR) の例を参照として使用します。

参照クラウドイベントコンシューマー namespace

apiVersion: v1
kind: Namespace
metadata:
  name: cloud-events
  labels:
    security.openshift.io/scc.podSecurityLabelSync: "false"
    pod-security.kubernetes.io/audit: "privileged"
    pod-security.kubernetes.io/enforce: "privileged"
    pod-security.kubernetes.io/warn: "privileged"
    name: cloud-events
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management

apiVersion: v1
kind: Namespace
metadata:
  name: cloud-events
  labels:
    security.openshift.io/scc.podSecurityLabelSync: "false"
    pod-security.kubernetes.io/audit: "privileged"
    pod-security.kubernetes.io/enforce: "privileged"
    pod-security.kubernetes.io/warn: "privileged"
    name: cloud-events
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management

Copy to clipboard

リファレンスクラウドイベントコンシューマーのデプロイメント

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-consumer-deployment
  namespace: cloud-events
  labels:
    app: consumer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: consumer
  template:
    metadata:
      annotations:
        target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
      labels:
        app: consumer
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      serviceAccountName: consumer-sa
      containers:
        - name: cloud-event-consumer
          image: cloud-event-consumer
          imagePullPolicy: Always
          args:
            - "--local-api-addr=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
            - "--api-path=/api/ocloudNotifications/v2/"
            - "--api-addr=127.0.0.1:8089"
            - "--api-version=2.0"
            - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: CONSUMER_TYPE
              value: "PTP"
            - name: ENABLE_STATUS_CHECK
              value: "true"
      volumes:
        - name: pubsubstore
          emptyDir: {}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-consumer-deployment
  namespace: cloud-events
  labels:
    app: consumer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: consumer
  template:
    metadata:
      annotations:
        target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
      labels:
        app: consumer
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      serviceAccountName: consumer-sa
      containers:
        - name: cloud-event-consumer
          image: cloud-event-consumer
          imagePullPolicy: Always
          args:
            - "--local-api-addr=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
            - "--api-path=/api/ocloudNotifications/v2/"
            - "--api-addr=127.0.0.1:8089"
            - "--api-version=2.0"
            - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: CONSUMER_TYPE
              value: "PTP"
            - name: ENABLE_STATUS_CHECK
              value: "true"
      volumes:
        - name: pubsubstore
          emptyDir: {}

Copy to clipboard

参照クラウドイベントコンシューマーサービスアカウント

apiVersion: v1
kind: ServiceAccount
metadata:
  name: consumer-sa
  namespace: cloud-events

apiVersion: v1
kind: ServiceAccount
metadata:
  name: consumer-sa
  namespace: cloud-events

Copy to clipboard

リファレンスクラウドイベントコンシューマーサービス

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: "true"
  name: consumer-events-subscription-service
  namespace: cloud-events
  labels:
    app: consumer-service
spec:
  ports:
    - name: sub-port
      port: 9043
  selector:
    app: consumer
  sessionAffinity: None
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: "true"
  name: consumer-events-subscription-service
  namespace: cloud-events
  labels:
    app: consumer-service
spec:
  ports:
    - name: sub-port
      port: 9043
  selector:
    app: consumer
  sessionAffinity: None
  type: ClusterIP

Copy to clipboard

14.3.6. REST API v2 を使用した PTP イベントのサブスクライブ

cloud-event-consumer アプリケーションコンテナーをデプロイし、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーが投稿する PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。

適切なサブスクリプション要求ペイロードを渡して、http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions に POST 要求を送信することにより、コンシューマーアプリケーションを PTP イベントにサブスクライブします。

注記

9043 は、PTP イベントプロデューサー Pod にデプロイされた cloud-event-proxy コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。

関連情報

api/ocloudNotifications/v2/subscriptions

14.3.7. PTP イベント REST API v2 コンシューマーアプリケーションがイベントを受信していることを確認

アプリケーション Pod 内の cloud-event-consumer コンテナーが Precision Time Protocol (PTP) イベントを受信していることを確認します。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP Operator をインストールして設定している。
クラウドイベントアプリケーション Pod と PTP イベントコンシューマーアプリケーションをデプロイしている。

手順

デプロイされたイベントコンシューマーアプリケーションのログを確認します。たとえば、以下のコマンドを実行します。

oc -n cloud-events logs -f deployment/cloud-consumer-deployment

$ oc -n cloud-events logs -f deployment/cloud-consumer-deployment

Copy to clipboard

出力例

time = "2024-09-02T13:49:01Z"
level = info msg = "transport host path is set to  ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043"
time = "2024-09-02T13:49:01Z"
level = info msg = "apiVersion=2.0, updated apiAddr=ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043, apiPath=/api/ocloudNotifications/v2/"
time = "2024-09-02T13:49:01Z"
level = info msg = "Starting local API listening to :9043"
time = "2024-09-02T13:49:06Z"
level = info msg = "transport host path is set to  ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043"
time = "2024-09-02T13:49:06Z"
level = info msg = "checking for rest service health"
time = "2024-09-02T13:49:06Z"
level = info msg = "health check http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/health"
time = "2024-09-02T13:49:07Z"
level = info msg = "rest service returned healthy status"
time = "2024-09-02T13:49:07Z"
level = info msg = "healthy publisher; subscribing to events"
time = "2024-09-02T13:49:07Z"
level = info msg = "received event {\"specversion\":\"1.0\",\"id\":\"ab423275-f65d-4760-97af-5b0b846605e4\",\"source\":\"/sync/ptp-status/clock-class\",\"type\":\"event.sync.ptp-status.ptp-clock-class-change\",\"time\":\"2024-09-02T13:49:07.226494483Z\",\"data\":{\"version\":\"1.0\",\"values\":[{\"ResourceAddress\":\"/cluster/node/compute-1.example.com/ptp-not-set\",\"data_type\":\"metric\",\"value_type\":\"decimal64.3\",\"value\":\"0\"}]}}"

time = "2024-09-02T13:49:01Z"
level = info msg = "transport host path is set to  ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043"
time = "2024-09-02T13:49:01Z"
level = info msg = "apiVersion=2.0, updated apiAddr=ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043, apiPath=/api/ocloudNotifications/v2/"
time = "2024-09-02T13:49:01Z"
level = info msg = "Starting local API listening to :9043"
time = "2024-09-02T13:49:06Z"
level = info msg = "transport host path is set to  ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043"
time = "2024-09-02T13:49:06Z"
level = info msg = "checking for rest service health"
time = "2024-09-02T13:49:06Z"
level = info msg = "health check http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/health"
time = "2024-09-02T13:49:07Z"
level = info msg = "rest service returned healthy status"
time = "2024-09-02T13:49:07Z"
level = info msg = "healthy publisher; subscribing to events"
time = "2024-09-02T13:49:07Z"
level = info msg = "received event {\"specversion\":\"1.0\",\"id\":\"ab423275-f65d-4760-97af-5b0b846605e4\",\"source\":\"/sync/ptp-status/clock-class\",\"type\":\"event.sync.ptp-status.ptp-clock-class-change\",\"time\":\"2024-09-02T13:49:07.226494483Z\",\"data\":{\"version\":\"1.0\",\"values\":[{\"ResourceAddress\":\"/cluster/node/compute-1.example.com/ptp-not-set\",\"data_type\":\"metric\",\"value_type\":\"decimal64.3\",\"value\":\"0\"}]}}"

Copy to clipboard

任意。linuxptp-daemon デプロイメントから oc とポート転送ポート 9043 を使用して REST API をテストします。たとえば、以下のコマンドを実行します。

oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043

$ oc port-forward -n openshift-ptp ds/linuxptp-daemon 9043:9043

Copy to clipboard

出力例

Forwarding from 127.0.0.1:9043 -> 9043
Forwarding from [::1]:9043 -> 9043
Handling connection for 9043

Forwarding from 127.0.0.1:9043 -> 9043
Forwarding from [::1]:9043 -> 9043
Handling connection for 9043

Copy to clipboard

新しいシェルプロンプトを開き、REST API v2 エンドポイントをテストします。

curl -X GET http://localhost:9043/api/ocloudNotifications/v2/health

$ curl -X GET http://localhost:9043/api/ocloudNotifications/v2/health

Copy to clipboard

出力例

OK

OK

Copy to clipboard

14.3.8. PTP 高速イベントメトリックのモニタリング

linuxptp-daemon が実行されているクラスターノードから PTP 高速イベントメトリクスを監視できます。事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。

前提条件

OpenShift Container Platform CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。

手順

次のコマンドを実行して、ノードのデバッグ Pod を起動します。
```
oc debug node/<node_name>
```
```
$ oc debug node/<node_name>
```
Copy to clipboardCopied

linuxptp-daemon コンテナーによって公開された PTP メトリックを確認します。たとえば、以下のコマンドを実行します。

curl http://localhost:9091/metrics

sh-4.4# curl http://localhost:9091/metrics

Copy to clipboard

出力例

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/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

任意。cloud-event-proxy コンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。
```
oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
```
```
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
```
Copy to clipboardCopied
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例: openshift_ptp_offset_ns) をコピーします。
OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。

関連情報

開発者としてメトリクスにアクセスする

14.3.9. PTP 高速イベントメトリクスのリファレンス

次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。

表14.11 PTP 高速イベントメトリクス
メトリクス	説明	例
`openshift_ptp_clock_class`	インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 (`LOCKED`)、7 (`PRC UNLOCKED IN-SPEC`)、52 (`PRC UNLOCKED OUT-OF-SPEC`)、187 (`PRC UNLOCKED OUT-OF-SPEC`)、135 (`T-BC HOLDOVER IN-SPEC`)、165 (`T-BC HOLDOVER OUT-OF-SPEC`)、248 (`DEFAULT`)、または 255 (`SLAVE ONLY CLOCK`) です。	`{node="compute-1.example.com",process="ptp4l"} 6`
`openshift_ptp_clock_state`	インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、`FREERUN`、`LOCKED`、または `HOLDOVER` です。	`{iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} 1`
`openshift_ptp_delay_ns`	タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。	`{from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 0`
`openshift_ptp_ha_profile_status`	異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 (`INACTIVE`) と 1 (`ACTIVE`) です。	`{node="node1",process="phc2sys",profile="profile1"} 1{node="node1",process="phc2sys",profile="profile2"} 0`
`openshift_ptp_frequency_adjustment_ns`	2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック (`phc`) と NIC の間などです。	`{from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -6768`
`openshift_ptp_interface_role`	インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 (`PASSIVE`)、1 (`SLAVE`)、2 (`MASTER`)、3 (`FAULTY`)、4 (`UNKNOWN`)、または 5 (`LISTENING`) です。	`{iface="ens2f0", node="compute-1.example.com", process="ptp4l"} 2`
`openshift_ptp_max_offset_ns`	2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC (`ts2phc`) の間、または PTP ハードウェアクロック (`phc`) とシステムクロック (`phc2sys`) の間などです。	`{from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 1.038099569e+09`
`openshift_ptp_offset_ns`	DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。	`{from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -9`
`openshift_ptp_process_restart_count`	`ptp4l` および `ts2phc` プロセスが再起動した回数を返します。	`{config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
`openshift_ptp_process_status`	PTP プロセスが実行中かどうかを示すステータスコードを返します。	`{config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
`openshift_ptp_threshold`	`HoldOverTimeout`、`MaxOffsetThreshold`、および `MinOffsetThreshold` の値を返します。 `holdOverTimeout` は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が `FREERUN` に変わるまでの時間値 (秒単位) です。 `maxOffsetThreshold` および `minOffsetThreshold` は、NIC の `PtpConfig` CR で設定した `CLOCK_REALTIME` (`phc2sys`) またはマスターオフセット (`ptp4l`) の値と比較されるナノ秒単位のオフセット値です。	`{node="compute-1.example.com", profile="grandmaster", threshold="HoldOverTimeout"} 5`

T-GM が有効な場合のみ PTP 高速イベントメトリクス

次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。

表14.12 T-GM が有効な場合の PTP 高速イベントメトリクス
メトリクス	説明	例
`openshift_ptp_frequency_status`	NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 (`UNKNOWN`)、0 (`INVALID`)、1 (`FREERUN`)、2 (`LOCKED`)、3 (`LOCKED_HO_ACQ`)、または 4 (`HOLDOVER`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 3`
`openshift_ptp_nmea_status`	NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 (`UNAVAILABLE`) と 1 (`AVAILABLE`) です。	`{iface="ens2fx",node="compute-1.example.com",process="ts2phc"} 1`
`openshift_ptp_phase_status`	NIC の DPLL 位相のステータスを返します。可能な値は、-1 (`UNKNOWN`)、0 (`INVALID`)、1 (`FREERUN`)、2 (`LOCKED`)、3 (`LOCKED_HO_ACQ`)、または 4 (`HOLDOVER`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 3`
`openshift_ptp_pps_status`	NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 (`UNAVAILABLE`) と 1 (`AVAILABLE`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 1`
`openshift_ptp_gnss_status`	Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 (`NOFIX`)、1 (`DEAD RECKONING ONLY`)、2 (`2D-FIX`)、3 (`3D-FIX`)、4 (`GPS+DEAD RECKONING FIX`)、5 (`TIME ONLY FIX`) です。	`{from="gnss",iface="ens2fx",node="compute-1.example.com",process="gnss"} 3`

14.4. PTP イベント REST API v2 リファレンス

次の REST API v2 エンドポイントを使用して、PTP イベントプロデューサー Pod の http://localhost:9043/api/ocloudNotifications/v2 に投稿された Precision Time Protocol (PTP) イベントに cloud-event-consumer アプリケーションをサブスクライブします。

api/ocloudNotifications/v2/subscriptions
- POST: 新しいサブスクリプションを作成します。
- GET: サブスクリプションの一覧を取得します。
- DELETE: すべてのサブスクリプションを削除します
api/ocloudNotifications/v2/subscriptions/{subscription_id}
- GET: 指定されたサブスクリプション ID の詳細を返します。
- DELETE: 指定されたサブスクリプション ID に関連付けられたサブスクリプションを削除します
api/ocloudNotifications/v2/health
- GET: ocloudNotifications API の正常性ステータスを返します
api/ocloudNotifications/v2/publishers
- GET: クラスターノードの PTP イベントパブリッシャーのリストを返します。
api/ocloudnotifications/v2/{resource_address}/CurrentState
- GET: {resouce_address} で指定されたイベントタイプの現在の状態を返します。

14.4.1. PTP イベント REST API v2 エンドポイント

14.4.1.1. api/ocloudNotifications/v2/subscriptions

HTTP メソッド

GET api/ocloudNotifications/v2/subscriptions

説明

サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。

API 応答の例

[
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ccedbf08-3f96-4839-a0b6-2eb0401855ed",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ccedbf08-3f96-4839-a0b6-2eb0401855ed"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/clock-class",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "a939a656-1b7d-4071-8cf1-f99af6e931f2",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/a939a656-1b7d-4071-8cf1-f99af6e931f2"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ba4564a3-4d9e-46c5-b118-591d3105473c",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ba4564a3-4d9e-46c5-b118-591d3105473c"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ea0d772e-f00a-4889-98be-51635559b4fb",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ea0d772e-f00a-4889-98be-51635559b4fb"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "762999bf-b4a0-4bad-abe8-66e646b65754",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/762999bf-b4a0-4bad-abe8-66e646b65754"
 }
]

[
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ccedbf08-3f96-4839-a0b6-2eb0401855ed",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ccedbf08-3f96-4839-a0b6-2eb0401855ed"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/clock-class",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "a939a656-1b7d-4071-8cf1-f99af6e931f2",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/a939a656-1b7d-4071-8cf1-f99af6e931f2"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ba4564a3-4d9e-46c5-b118-591d3105473c",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ba4564a3-4d9e-46c5-b118-591d3105473c"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "ea0d772e-f00a-4889-98be-51635559b4fb",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/ea0d772e-f00a-4889-98be-51635559b4fb"
 },
 {
  "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
  "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
  "SubscriptionId": "762999bf-b4a0-4bad-abe8-66e646b65754",
  "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/762999bf-b4a0-4bad-abe8-66e646b65754"
 }
]

Copy to clipboard

HTTP メソッド

POST api/ocloudNotifications/v2/subscriptions

説明

適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。

次の PTP イベントをサブスクライブできます。

sync-state イベント
lock-state イベント
gnss-sync-status events イベント
os-clock-sync-state イベント
clock-class イベント

表14.13 クエリーパラメーター
パラメーター	型
subscription	data

同期状態サブスクリプションペイロードの例

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}

Copy to clipboard

PTP ロック状態イベントサブスクリプションペイロードの例

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}

Copy to clipboard

PTP gnss-sync-status イベントサブスクリプションペイロードの例

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}

Copy to clipboard

PTP os-clock-sync-state イベントサブスクリプションペイロードの例

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}

Copy to clipboard

PTP clock-class イベントサブスクリプションペイロードの例

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}

{
"EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
"ResourceAddress": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}

Copy to clipboard

API 応答の例

{
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
    "SubscriptionId": "620283f3-26cd-4a6d-b80a-bdc4b614a96a",
    "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/620283f3-26cd-4a6d-b80a-bdc4b614a96a"
}

{
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
    "SubscriptionId": "620283f3-26cd-4a6d-b80a-bdc4b614a96a",
    "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/620283f3-26cd-4a6d-b80a-bdc4b614a96a"
}

Copy to clipboard

次のサブスクリプションステータスイベントが発生する可能性があります。

表14.14 PTP イベントの REST API v2 サブスクリプションステータスコード
ステータスコード	説明
`201 Created`	サブスクリプションが作成されたことを示します。
`400 Bad Request`	リクエストが不正または無効であったため、サーバーが要求を処理できなかったことを示します。
`404 Not Found`	サブスクリプションリソースが利用できないことを示します。
`409 Conflict`	サブスクリプションがすでに存在することを示します。

HTTP メソッド

DELETE api/ocloudNotifications/v2/subscriptions

説明

すべてのサブスクリプションを削除します。

API 応答の例

{
"status": "deleted all subscriptions"
}

{
"status": "deleted all subscriptions"
}

Copy to clipboard

14.4.1.2. api/ocloudNotifications/v2/subscriptions/{subscription_id}

HTTP メソッド

GET api/ocloudNotifications/v2/subscriptions/{subscription_id}

説明

ID が subscription_id のサブスクリプションの詳細を返します。

表14.15 グローバルパスパラメーター
パラメーター	型
`subscription_id`	string

API 応答の例

{
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
    "SubscriptionId": "620283f3-26cd-4a6d-b80a-bdc4b614a96a",
    "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/620283f3-26cd-4a6d-b80a-bdc4b614a96a"
}

{
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://consumer-events-subscription-service.cloud-events.svc.cluster.local:9043/event",
    "SubscriptionId": "620283f3-26cd-4a6d-b80a-bdc4b614a96a",
    "UriLocation": "http://ptp-event-publisher-service-compute-1.openshift-ptp.svc.cluster.local:9043/api/ocloudNotifications/v2/subscriptions/620283f3-26cd-4a6d-b80a-bdc4b614a96a"
}

Copy to clipboard

HTTP メソッド

DELETE api/ocloudNotifications/v2/subscriptions/{subscription_id}

説明

ID subscription_id のサブスクリプションを削除します。

表14.16 グローバルパスパラメーター
パラメーター	型
`subscription_id`	string

表14.17 HTTP 応答コード
HTTP レスポンス	説明
204 No Content	Success

14.4.1.3. api/ocloudNotifications/v2/health

HTTP メソッド

GET api/ocloudNotifications/v2/health/

説明

ocloudNotifications REST API の正常性ステータスを返します。

表14.18 HTTP 応答コード
HTTP レスポンス	説明
200 OK	Success

14.4.1.4. api/ocloudNotifications/v2/publishers

HTTP メソッド

GET api/ocloudNotifications/v2/publishers

説明

クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。

機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。

API 応答の例

[
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "4ea72bfa-185c-4703-9694-cdd0434cd570",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/4ea72bfa-185c-4703-9694-cdd0434cd570"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "71fbb38e-a65d-41fc-823b-d76407901087",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/71fbb38e-a65d-41fc-823b-d76407901087"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/clock-class",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "7bc27cad-03f4-44a9-8060-a029566e7926",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/7bc27cad-03f4-44a9-8060-a029566e7926"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "6e7b6736-f359-46b9-991c-fbaed25eb554",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/6e7b6736-f359-46b9-991c-fbaed25eb554"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "31bb0a45-7892-45d4-91dd-13035b13ed18",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/31bb0a45-7892-45d4-91dd-13035b13ed18"
  }
]

[
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "4ea72bfa-185c-4703-9694-cdd0434cd570",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/4ea72bfa-185c-4703-9694-cdd0434cd570"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "71fbb38e-a65d-41fc-823b-d76407901087",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/71fbb38e-a65d-41fc-823b-d76407901087"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/clock-class",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "7bc27cad-03f4-44a9-8060-a029566e7926",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/7bc27cad-03f4-44a9-8060-a029566e7926"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "6e7b6736-f359-46b9-991c-fbaed25eb554",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/6e7b6736-f359-46b9-991c-fbaed25eb554"
  },
  {
    "ResourceAddress": "/cluster/node/compute-1.example.com/sync/gnss-status/gnss-sync-status",
    "EndpointUri": "http://localhost:9043/api/ocloudNotifications/v2/dummy",
    "SubscriptionId": "31bb0a45-7892-45d4-91dd-13035b13ed18",
    "UriLocation": "http://localhost:9043/api/ocloudNotifications/v2/publishers/31bb0a45-7892-45d4-91dd-13035b13ed18"
  }
]

Copy to clipboard

表14.19 HTTP 応答コード
HTTP レスポンス	説明
200 OK	Success

14.4.1.5. api/ocloudNotifications/v2/{resource_address}/CurrentState

HTTP メソッド

GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState

GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState

GET api/ocloudNotifications/v2/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState

説明

クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。

os-clock-sync-state 通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKED または FREERUN 状態になります。
clock-class 通知は、PTP クロッククラスの現在の状態を説明します。
lock-state 通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、または FREERUN 状態になります。
sync-state 通知は、PTP クロックの lock-state 状態と os-clock-sync-state 状態のうち、最も同期されていない状態の現在のステータスを示します。
gnss-sync-status 通知は、GNSS クロックの同期状態を説明します。

表14.20 グローバルパスパラメーター
パラメーター	型
`resource_address`	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": "1.0",
    "values": [
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "ResourceAddress": "/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": "1.0",
    "values": [
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

Copy to clipboard

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": "1.0",
    "values": [
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "ResourceAddress": "/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": "1.0",
    "values": [
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

Copy to clipboard

clock-class 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/clock-class",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "1.0",
    "values": [
      {
        "ResourceAddress": "/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/clock-class",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "1.0",
    "values": [
      {
        "ResourceAddress": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

Copy to clipboard

同期状態 API 応答の例

{
    "specversion": "0.3",
    "id": "8c9d6ecb-ae9f-4106-82c4-0a778a79838d",
    "source": "/sync/sync-status/sync-state",
    "type": "event.sync.sync-status.synchronization-state-change",
    "subject": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "datacontenttype": "application/json",
    "time": "2024-08-28T14:50:57.327585316Z",
    "data":
    {
        "version": "1.0",
        "values": [
        {
            "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
            "data_type": "notification",
            "value_type": "enumeration",
            "value": "LOCKED"
        }]
    }
}

{
    "specversion": "0.3",
    "id": "8c9d6ecb-ae9f-4106-82c4-0a778a79838d",
    "source": "/sync/sync-status/sync-state",
    "type": "event.sync.sync-status.synchronization-state-change",
    "subject": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "datacontenttype": "application/json",
    "time": "2024-08-28T14:50:57.327585316Z",
    "data":
    {
        "version": "1.0",
        "values": [
        {
            "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
            "data_type": "notification",
            "value_type": "enumeration",
            "value": "LOCKED"
        }]
    }
}

Copy to clipboard

gnss-sync-state API 応答の例

{
  "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": "1.0",
    "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": "1.0",
    "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"
      }
    ]
  }
}

Copy to clipboard

14.5. REST API v1 を使用した PTP イベントコンシューマーアプリケーションの開発

ベアメタルクラスターノードで Precision Time Protocol (PTP) イベントを利用するコンシューマーアプリケーションを開発する場合は、コンシューマーアプリケーションを別のアプリケーション Pod にデプロイします。コンシューマーアプリケーションは、PTP イベント REST API v1 を使用して PTP イベントをサブスクライブします。

注記

重要

PTP イベント REST API v1 およびイベントコンシューマーアプリケーションサイドカーは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。

関連情報

PTP イベント REST API v1 リファレンス

14.5.1. PTP 高速イベント通知フレームワークについて

注記

PTP イベント REST API v2 のみが O-RAN v3 に準拠しています。

14.5.2. PTP イベント REST API v1 を使用して PTP イベントを取得

アプリケーションは、cloud-event-proxy コンテナーをサイドカーパターンで実行して、PTP イベントをサブスクライブします。cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースをまったく使用せずに、大幅な待機時間なしで、プライマリーアプリケーションコンテナーと同じリソースにアクセスできます。

図14.7 コンシューマーサイドカーと HTTP メッセージトランスポートを使用した PTP 高速イベントの概要

イベントはクラスターホストで生成されます。: PTP Operator が管理する Pod の linuxptp-daemon は、Kubernetes DaemonSet として実行され、さまざまな linuxptp プロセス (ptp4l、phc2sys、およびオプションでグランドマスタークロック用の ts2phc) を管理します。linuxptp-daemon は、イベントを UNIX ドメインソケットに渡します。
イベントが cloud-event-proxy サイドカーに渡されます。: PTP プラグインは、UNIX ドメインソケットからイベントを読み取り、PTP Operator が管理する Pod 内の cloud-event-proxy サイドカーに渡します。cloud-event-proxy は、イベントを Kubernetes インフラストラクチャーから Cloud-Native Network Functions (CNF) に低レイテンシーで配信します。
イベントが永続化される: PTP Operator が管理する Pod 内の cloud-event-proxy サイドカーは、REST API を使用してイベントを処理し、クラウドネイティブイベントを発行します。
メッセージはトランスポートされます。: メッセージトランスポーターは、HTTP 経由でアプリケーション Pod 内の cloud-event-proxy サイドカーにイベントを転送します。
イベントは REST API から入手できます。: アプリケーション Pod の cloud-event-proxy サイドカーはイベントを処理し、REST API を使用して利用できるようにします。
コンシューマーアプリケーションがサブスクリプションをリクエストし、サブスクライブされたイベントを受信します: コンシューマーアプリケーションは、API 要求をアプリケーション Pod の cloud-event-proxy サイドカーに送信して、PTP イベントサブスクリプションを作成します。cloud-event-proxy サイドカーは、サブスクリプションで指定されたリソースの HTTP メッセージングリスナープロトコルを作成します。

アプリケーション Pod の cloud-event-proxy サイドカーは、PTP Operator が管理する Pod からイベントを受信し、クラウドイベントオブジェクトをラッピング解除してデータを取得し、イベントをコンシューマーアプリケーションにポストします。コンシューマーアプリケーションは、リソース修飾子で指定されたアドレスをリッスンし、PTP イベントを受信して処理します。

14.5.3. PTP 高速イベント通知パブリッシャーの設定

前提条件

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

手順

デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。
1. 次の 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 1
```
```
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 clipboardCopied
  1
  enableEventPublisher を true に設定して、PTP 高速イベント通知を有効にします。
  注記
  OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、PtpOperatorConfig リソースの spec.ptpEventConfig.transportHost フィールドを設定する必要はありません。
2. PtpOperatorConfig CR を更新します。
```
oc apply -f ptp-operatorconfig.yaml
```
```
$ oc apply -f ptp-operatorconfig.yaml
```
  Copy to clipboardCopied
PTP 対応インターフェイスの PtpConfig カスタムリソースを作成し、ptpClockThreshold および ptp4lOpts に必要な値を設定します。次の YAML は、PtpConfig CR で設定する必要のある値 (必須) を示しています。
```
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
```
```
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 clipboardCopied
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 に設定されます。

関連情報

PTP 高速イベントを使用して linuxptp サービスを通常のクロックとして設定する CR の詳細な例は、linuxptp サービスを通常のクロックとして設定するを参照してください。

14.5.4. 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)
  }
}

Copy to clipboard

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") 1
s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/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") 1
s2,_:=createsubscription("/cluster/node/<node_name>/sync/ptp-status/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
}

Copy to clipboard

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)
  }
}

Copy to clipboard

14.5.5. cloud-event-proxy のデプロイメントとサービス CR を参照する

PTP イベントコンシューマーアプリケーションをデプロイするときは、次の cloud-event-proxy デプロイメントとサブスクライバサービス CR の例を参考として使用してください。

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: {}

Copy to clipboard

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

Copy to clipboard

14.5.6. REST API v1 を使用した PTP イベントのサブスクライブ

cloud-event-consumer アプリケーションコンテナーおよび cloud-event-proxy サイドカーコンテナーを別のアプリケーション Pod にデプロイします。

アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーによって投稿された PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。

注記

9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。

関連情報

api/ocloudNotifications/v1/subscriptions

14.5.7. PTP イベント REST API v1 コンシューマーアプリケーションがイベントを受信していることを確認

アプリケーション 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

出力例

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

次のコマンドを実行して、必要なコンシューマー側 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

ここでは、以下のようになります。

<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

14.5.8. PTP 高速イベントメトリックのモニタリング

前提条件

OpenShift Container Platform CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP 対応ハードウェアを搭載したノードに PTP Operator をインストールし、設定します。

手順

次のコマンドを実行して、ノードのデバッグ Pod を起動します。
```
oc debug node/<node_name>
```
```
$ oc debug node/<node_name>
```
Copy to clipboardCopied

linuxptp-daemon コンテナーによって公開された PTP メトリックを確認します。たとえば、以下のコマンドを実行します。

curl http://localhost:9091/metrics

sh-4.4# curl http://localhost:9091/metrics

Copy to clipboard

出力例

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/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

任意。cloud-event-proxy コンテナーのログでも PTP イベントを見つけることができます。たとえば、以下のコマンドを実行します。
```
oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
```
```
$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy
```
Copy to clipboardCopied
OpenShift Container Platform Web コンソールで PTP イベントを表示するには、クエリーする PTP メトリクスの名前 (例: openshift_ptp_offset_ns) をコピーします。
OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。

関連情報

開発者としてメトリクスにアクセスする

14.5.9. PTP 高速イベントメトリクスのリファレンス

次の表は、linuxptp-daemon サービスが実行されているクラスターノードから利用できる PTP 高速イベントメトリクスを説明します。

表14.21 PTP 高速イベントメトリクス
メトリクス	説明	例
`openshift_ptp_clock_class`	インターフェイスの PTP クロッククラスを返します。PTP クロッククラスの可能な値は、6 (`LOCKED`)、7 (`PRC UNLOCKED IN-SPEC`)、52 (`PRC UNLOCKED OUT-OF-SPEC`)、187 (`PRC UNLOCKED OUT-OF-SPEC`)、135 (`T-BC HOLDOVER IN-SPEC`)、165 (`T-BC HOLDOVER OUT-OF-SPEC`)、248 (`DEFAULT`)、または 255 (`SLAVE ONLY CLOCK`) です。	`{node="compute-1.example.com",process="ptp4l"} 6`
`openshift_ptp_clock_state`	インターフェイスの現在の PTP クロック状態を返します。PTP クロック状態の可能な値は、`FREERUN`、`LOCKED`、または `HOLDOVER` です。	`{iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} 1`
`openshift_ptp_delay_ns`	タイミングパケットを送信するプライマリークロックとタイミングパケットを受信するセカンダリークロックの間の遅延をナノ秒単位で返します。	`{from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 0`
`openshift_ptp_ha_profile_status`	異なる NIC に複数のタイムソースがある場合に、高可用性システムクロックの現在のステータスを返します。可能な値は 0 (`INACTIVE`) と 1 (`ACTIVE`) です。	`{node="node1",process="phc2sys",profile="profile1"} 1{node="node1",process="phc2sys",profile="profile2"} 0`
`openshift_ptp_frequency_adjustment_ns`	2 つの PTP クロック間の周波数調整をナノ秒単位で返します。たとえば、アップストリームクロックと NIC の間、システムクロックと NIC の間、または PTP ハードウェアクロック (`phc`) と NIC の間などです。	`{from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -6768`
`openshift_ptp_interface_role`	インターフェイスに設定された PTP クロックの役割を返します。可能な値は、0 (`PASSIVE`)、1 (`SLAVE`)、2 (`MASTER`)、3 (`FAULTY`)、4 (`UNKNOWN`)、または 5 (`LISTENING`) です。	`{iface="ens2f0", node="compute-1.example.com", process="ptp4l"} 2`
`openshift_ptp_max_offset_ns`	2 つのクロックまたはインターフェイス間の最大オフセットをナノ秒単位で返します。たとえば、アップストリーム GNSS クロックと NIC (`ts2phc`) の間、または PTP ハードウェアクロック (`phc`) とシステムクロック (`phc2sys`) の間などです。	`{from="master", iface="ens2fx", node="compute-1.example.com", process="ts2phc"} 1.038099569e+09`
`openshift_ptp_offset_ns`	DPLL クロックまたは GNSS クロックソースと NIC ハードウェアクロック間のオフセットをナノ秒単位で返します。	`{from="phc", iface="CLOCK_REALTIME", node="compute-1.example.com", process="phc2sys"} -9`
`openshift_ptp_process_restart_count`	`ptp4l` および `ts2phc` プロセスが再起動した回数を返します。	`{config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
`openshift_ptp_process_status`	PTP プロセスが実行中かどうかを示すステータスコードを返します。	`{config="ptp4l.0.config", node="compute-1.example.com",process="phc2sys"} 1`
`openshift_ptp_threshold`	`HoldOverTimeout`、`MaxOffsetThreshold`、および `MinOffsetThreshold` の値を返します。 `holdOverTimeout` は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が `FREERUN` に変わるまでの時間値 (秒単位) です。 `maxOffsetThreshold` および `minOffsetThreshold` は、NIC の `PtpConfig` CR で設定した `CLOCK_REALTIME` (`phc2sys`) またはマスターオフセット (`ptp4l`) の値と比較されるナノ秒単位のオフセット値です。	`{node="compute-1.example.com", profile="grandmaster", threshold="HoldOverTimeout"} 5`

T-GM が有効な場合のみ PTP 高速イベントメトリクス

次の表は、PTP グランドマスタークロック (T-GM) が有効な場合にのみ使用できる PTP 高速イベントメトリクスを示しています。

表14.22 T-GM が有効な場合の PTP 高速イベントメトリクス
メトリクス	説明	例
`openshift_ptp_frequency_status`	NIC の Digital Phase-Locked Loop (DPLL) 周波数の現在のステータスを返します。可能な値は、-1 (`UNKNOWN`)、0 (`INVALID`)、1 (`FREERUN`)、2 (`LOCKED`)、3 (`LOCKED_HO_ACQ`)、または 4 (`HOLDOVER`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 3`
`openshift_ptp_nmea_status`	NMEA 接続の現在のステータスを返します。NMEA は、1PPS NIC 接続に使用されるプロトコルです。可能な値は 0 (`UNAVAILABLE`) と 1 (`AVAILABLE`) です。	`{iface="ens2fx",node="compute-1.example.com",process="ts2phc"} 1`
`openshift_ptp_phase_status`	NIC の DPLL 位相のステータスを返します。可能な値は、-1 (`UNKNOWN`)、0 (`INVALID`)、1 (`FREERUN`)、2 (`LOCKED`)、3 (`LOCKED_HO_ACQ`)、または 4 (`HOLDOVER`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 3`
`openshift_ptp_pps_status`	NIC 1PPS 接続の現在のステータスを返します。1PPS 接続は、接続された NIC 間のタイミングを同期するために使用します。可能な値は 0 (`UNAVAILABLE`) と 1 (`AVAILABLE`) です。	`{from="dpll",iface="ens2fx",node="compute-1.example.com",process="dpll"} 1`
`openshift_ptp_gnss_status`	Global Navigation Satellite System (GNSS) 接続の現在のステータスを返します。GNSS は、衛星ベースの測位、ナビゲーション、およびタイミングサービスを世界中に提供します。可能な値は、0 (`NOFIX`)、1 (`DEAD RECKONING ONLY`)、2 (`2D-FIX`)、3 (`3D-FIX`)、4 (`GPS+DEAD RECKONING FIX`)、5 (`TIME ONLY FIX`) です。	`{from="gnss",iface="ens2fx",node="compute-1.example.com",process="gnss"} 3`

14.6. PTP イベント REST API v1 リファレンス

次の Precision Time Protocol (PTP) 高速イベント REST API v1 エンドポイントを使用して、アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーが投稿した PTP イベントに cloud-event-consumer アプリケーションをサブスクライブします。

重要

以下の API エンドポイントを利用できます。

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: クラスターノードの PTP イベントパブリッシャーのリストを返します。
api/ocloudnotifications/v1/{resource_address}/CurrentState
- GET: sync-state、os-clock-sync-state、clock-class、lock-state、または gnss-sync-status イベントのいずれかの現在の状態を返します。

14.6.1. PTP イベント REST API v1 エンドポイント

14.6.1.1. api/ocloudNotifications/v1/subscriptions

HTTP メソッド

GET api/ocloudNotifications/v1/subscriptions

説明

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"
 }
]

Copy to clipboard

HTTP メソッド

POST api/ocloudNotifications/v1/subscriptions

説明

適切なペイロードを渡すことで、必要なイベントの新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。次の PTP イベントをサブスクライブできます。

lock-state イベント
os-clock-sync-state イベント
clock-class イベント
gnss-sync-status イベント
sync-state イベント

表14.23 クエリーパラメーター
パラメーター	型
subscription	data

PTP イベントサブスクリプションペイロードの例

{
  "endpointUri": "http://localhost:8989/event",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

{
  "endpointUri": "http://localhost:8989/event",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

Copy to clipboard

PTP ロック状態イベントサブスクリプションペイロードの例

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/lock-state"
}

Copy to clipboard

PTP os-clock-sync-state イベントサブスクリプションペイロードの例

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state"
}

Copy to clipboard

PTP clock-class イベントサブスクリプションペイロードの例

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/ptp-status/clock-class"
}

Copy to clipboard

PTP gnss-sync-status イベントサブスクリプションペイロードの例

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/gnss-status/gnss-sync-status"
}

Copy to clipboard

同期状態サブスクリプションペイロードの例

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}

{
"endpointUri": "http://localhost:8989/event",
"resource": "/cluster/node/{node_name}/sync/sync-status/sync-state"
}

Copy to clipboard

HTTP メソッド

DELETE api/ocloudNotifications/v1/subscriptions

説明

すべてのサブスクリプションを削除します。

API 応答の例

{
"status": "deleted all subscriptions"
}

{
"status": "deleted all subscriptions"
}

Copy to clipboard

14.6.1.2. api/ocloudNotifications/v1/subscriptions/{subscription_id}

HTTP メソッド

GET api/ocloudNotifications/v1/subscriptions/{subscription_id}

説明

ID が subscription_id のサブスクリプションの詳細を返します。

表14.24 グローバルパスパラメーター
パラメーター	型
`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"
}

Copy to clipboard

HTTP メソッド

DELETE api/ocloudNotifications/v1/subscriptions/{subscription_id}

説明

ID subscription_id のサブスクリプションを削除します。

表14.25 グローバルパスパラメーター
パラメーター	型
`subscription_id`	string

API 応答の例

{
"status": "OK"
}

{
"status": "OK"
}

Copy to clipboard

14.6.1.3. api/ocloudNotifications/v1/health

HTTP メソッド

GET api/ocloudNotifications/v1/health/

説明

ocloudNotifications REST API の正常性ステータスを返します。

API 応答の例

OK

OK

Copy to clipboard

14.6.1.4. api/ocloudNotifications/v1/publishers

重要

api/ocloudNotifications/v1/publishers エンドポイントは、PTP Operator が管理する Pod 内の cloud-event-proxy コンテナーからのみ利用できます。アプリケーション Pod 内のコンシューマーアプリケーションでは使用できません。

HTTP メソッド

GET api/ocloudNotifications/v1/publishers

説明

クラスターノードの発行者の詳細のリストを返します。関連する機器の状態が変化すると、システムは通知を生成します。

機器の同期ステータスのサブスクリプションを組み合わせて使用すると、システム全体の同期状態の詳細なビューを提供できます。

API 応答の例

[
  {
    "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/clock-class"
  },
  {
    "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/clock-class"
  },
  {
    "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"
  }
]

Copy to clipboard

14.6.1.5. api/ocloudNotifications/v1/{resource_address}/CurrentState

HTTP メソッド

GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/ptp-status/clock-class/CurrentState

GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/sync-status/sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/{node_name}/sync/gnss-status/gnss-sync-state/CurrentState

説明

クラスターノードの os-clock-sync-state、clock-class、lock-state、gnss-sync-status、または sync-state イベントの現在の状態を返します。

os-clock-sync-state 通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKED または FREERUN 状態になります。
clock-class 通知は、PTP クロッククラスの現在の状態を説明します。
lock-state 通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、または FREERUN 状態になります。
sync-state 通知は、ptp-status/lock-state エンドポイントおよび sync-status/os-clock-sync-state エンドポイントのうち最も同期されていないエンドポイントの現在のステータスを説明します。
gnss-sync-status 通知は、GNSS クロックの同期状態を説明します。

表14.26 グローバルパスパラメーター
パラメーター	型
`resource_address`	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": "1.0",
    "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": "1.0",
    "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"
      }
    ]
  }
}

Copy to clipboard

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": "1.0",
    "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": "1.0",
    "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"
      }
    ]
  }
}

Copy to clipboard

clock-class 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/clock-class",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "1.0",
    "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/clock-class",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "1.0",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

Copy to clipboard

同期状態 API 応答の例

{
    "specversion": "0.3",
    "id": "8c9d6ecb-ae9f-4106-82c4-0a778a79838d",
    "source": "/sync/sync-status/sync-state",
    "type": "event.sync.sync-status.synchronization-state-change",
    "subject": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "datacontenttype": "application/json",
    "time": "2024-08-28T14:50:57.327585316Z",
    "data":
    {
        "version": "1.0",
        "values": [
        {
            "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
            "data_type": "notification",
            "value_type": "enumeration",
            "value": "LOCKED"
        }]
    }
}

{
    "specversion": "0.3",
    "id": "8c9d6ecb-ae9f-4106-82c4-0a778a79838d",
    "source": "/sync/sync-status/sync-state",
    "type": "event.sync.sync-status.synchronization-state-change",
    "subject": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
    "datacontenttype": "application/json",
    "time": "2024-08-28T14:50:57.327585316Z",
    "data":
    {
        "version": "1.0",
        "values": [
        {
            "ResourceAddress": "/cluster/node/compute-1.example.com/sync/sync-status/sync-state",
            "data_type": "notification",
            "value_type": "enumeration",
            "value": "LOCKED"
        }]
    }
}

Copy to clipboard

gnss-sync-status API 応答の例

{
  "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": "1.0",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens2fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "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": "1.0",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens2fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens2fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "5"
      }
    ]
  }
}

Copy to clipboard

第15章 CIDR 範囲の定義

クラスターで OVN-Kubernetes を使用する場合は、Classless Inter-Domain Routing (CIDR) サブネット範囲に重複しない範囲を指定する必要があります。

重要

OpenShift Container Platform 4.17 以降のバージョンでは、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は 169.254.0.0/17、IPv6 の場合は fd69::/112 を使用します。ユーザーはこれらの範囲も回避する必要があります。アップグレードされたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。

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::/112

重要

前のリストには、参加、トランジット、マスカレード IPv4 および IPv6 アドレスサブネットが含まれています。クラスターで OVN-Kubernetes を使用する場合は、クラスターまたはインフラストラクチャー内の他の CIDR 定義にこれらの IP アドレスサブネット範囲を含めないでください。

関連情報

join サブネットまたは transit サブネットの設定の詳細は、OVN-Kubernetes 内部 IP アドレスサブネットの設定を参照してください。

15.1. Machine CIDR

マシンの Classless Inter-Domain Routing (CIDR) フィールドでは、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。

注記

クラスターの作成後にマシンの CIDR 範囲を変更することはできません。

デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。

関連情報

Cluster Network Operator の設定

15.2. Service CIDR

Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。

15.3. Pod CIDR

Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。

Pod CIDR は、clusterNetwork CIDR およびクラスター CIDR と同じです。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。クラスターをインストールした後に、範囲を拡張できます。

関連情報

Cluster Network Operator の設定
クラスターネットワーク範囲の設定

15.4. ホスト接頭辞

Host Prefix フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。

例えば、ホスト接頭辞を /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。

第16章複数ネットワーク

16.1. 複数ネットワークについて

デフォルトでは、OVN-Kubernetes が OpenShift Container Platform クラスターの Container Network Interface (CNI) として機能します。OpenShift Container Platform の管理者またはユーザーは、OVN-Kubernetes をクラスターのデフォルトの CNI として使用すると、ユーザー定義ネットワーク (UDN) または NetworkAttachmentDefinition (NAD) を活用して、クラスターの通常のネットワークトラフィックすべてを処理する 1 つまたは複数のデフォルトネットワークを作成できます。ユーザー定義ネットワークとネットワークアタッチメント定義は、どちらも次のネットワークタイプとして機能できます。

プライマリーネットワーク: Pod のプライマリーネットワークとして機能します。デフォルトでは、Pod のルートが他のネットワーク経由でトラフィックを送信するように設定されていない限り、すべてのトラフィックがプライマリーネットワークを通過します。
セカンダリーネットワーク: Pod の、デフォルトではないセカンダリーネットワークとして機能します。セカンダリーネットワークは、特定のトラフィックの種類または目的専用の個別のインターフェイスを提供します。セカンダリーネットワークを使用するように明示的に設定された Pod トラフィックのみが、そのインターフェイスを介してルーティングされます。

ただし、OpenShift Container Platform 管理者は、クラスターのインストール時に、Multus CNI プラグインを活用して、代替のデフォルトのセカンダリー Pod ネットワークを設定できます。Multus を使用すると、ipvlan、macvlan などの複数の CNI プラグインやネットワークアタッチメント定義を一緒に使用して、Pod のセカンダリーネットワークとして機能させることができます。

注記

ユーザー定義ネットワークは、CNI として OVN-Kubernetes が使用されている場合にのみ使用できます。他の CNI での使用はサポートされていません。

利用可能な CNI プラグインに基づいてセカンダリーネットワークを定義し、そのネットワークのうち 1 つ以上を Pod に割り当てることができます。必要に応じて、クラスターに複数のセカンダリーネットワークを定義できます。これにより、スイッチングやルーティングなどのネットワーク機能を提供する Pod を設定する際に柔軟性が得られます。

サポートされている CNI プラグインの完全なリストについては、OpenShift Container Platform のセカンダリーネットワークを参照してください。

ユーザー定義ネットワークの詳細は、ユーザー定義ネットワーク (UDN) についてを参照してください。

ネットワークアタッチメント定義の詳細は、NetworkAttachmentDefinition を使用したプライマリーネットワークの作成を参照してください。

16.1.1. セカンダリーネットワークの使用シナリオ

データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で、セカンダリーネットワーク と呼ばれる 2 つ目のネットワークを使用できます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。

パフォーマンス
トラフィック管理: 2 つの異なるプレーンでトラフィックを送信して、各プレーンのトラフィック量を管理できます。
セキュリティー
ネットワーク分離: セキュリティーを考慮して特別に管理されたネットワークプレーンに機密トラフィックを送信し、テナントまたは顧客間で共有してはならないプライベートデータを分離できます。

クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0 インターフェイスがあります。Pod のインターフェイスは、oc exec -it <pod_name> -- ip a コマンドを使用して表示できます。Multus CNI を使用するセカンダリーネットワークインターフェイスを追加する場合、それらの名前は net1、net2、…、netN になります。

セカンダリーネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。各インターフェイスは、UserDefinedNetwork カスタムリソース (CR) または NetworkAttachmentDefinition CR のいずれかを使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェイスの作成方法を定義します。

UserDefinedNetwork CR の作成の詳細は、ユーザー定義ネットワークについてを参照してください。

NetworkAttachmentDefinition CR の作成の詳細は、NetworkAttachmentDefinition を使用したプライマリーネットワークの作成を参照してください。

16.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: TAP ベースのセカンダリーネットワークを設定して、コンテナー namespace 内に TAP デバイスを作成します。TAP デバイスを使用すると、ユーザー空間プログラムがネットワークパケットを送受信できるようになります。
SR-IOV: SR-IOV ベースのセカンダリーネットワークを設定することで、Pod をホストシステム上の SR-IOV 対応ハードウェアの Virtual Function (VF) インターフェイスに割り当てることができます。
route-override: route-override ベースのセカンダリーネットワークを設定して、Pod がルートをオーバーライドして設定できるようにします。

16.1.3. UserDefinedNetwork および NetworkAttachmentDefinition のサポートマトリックス

UserDefinedNetwork および NetworkAttachmentDefinition カスタムリソース (CR) により、クラスター管理者とユーザーは、カスタマイズ可能なネットワーク設定の作成、独自ネットワークトポロジーの定義、ネットワーク分離の確保、ワークロードの IP アドレスの管理、高度なネットワーク機能の設定を行うことができます。3 番目の CR である ClusterUserDefinedNetwork も使用できます。これにより、管理者はクラスターレベルで複数の namespace にまたがるセカンダリーネットワークを作成および定義できます。

ユーザー定義ネットワークとネットワークアタッチメント定義は、プライマリーおよびセカンダリーネットワークインターフェイスの両方として機能することが可能で、それぞれ layer2 および layer3 のトポロジーをサポートします。3 番目のネットワークトポロジーである Localnet も、セカンダリーネットワークのネットワークアタッチメント定義でサポートされます。

注記

OpenShift Container Platform 4.18 以降では、Localnet トポロジーは UserDefinedNetwork および ClusterUserDefinedNetwork CR では使用できません。これは、セカンダリーネットワークを活用する NetworkAttachmentDefinition CR でのみ使用できます。

次のセクションでは、UserDefinedNetwork および NetworkAttachmentDefinition CR がプライマリーネットワークまたはセカンダリーネットワークとして使用される場合にサポートされる機能について説明します。ClusterUserDefinedNetwork CR 用の別のテーブルも含まれています。

表16.1 UserDefinedNetwork および NetworkAttachmentDefinition CR のプライマリーネットワークのサポートマトリックス
ネットワーク機能	Layer2 トポロジー	Layer3 トポロジー
east-west トラフィック	✓	✓
north-south トラフィック	✓	✓
永続的な IP	✓	X
サービス	✓	✓
ルート	X	X
`EgressIP` リソース	✓	✓
マルチキャスト ^[1]	X	✓
`NetworkPolicy` リソース ^[2]	✓	✓
`MultiNetworkPolicy` リソース	X	X

マルチキャストは namespace で有効にする必要があり、OVN-Kubernetes ネットワーク Pod 間でのみ使用できます。マルチキャストの詳細は、「プロジェクトでのマルチキャストの有効化」を参照してください。
プライマリーネットワークタイプを使用して UserDefinedNetwork CR を作成する場合、UserDefinedNetwork CR の後にネットワークポリシーを作成する必要があります。

表16.2 UserDefinedNetwork および NetworkAttachmentDefinition CR のセカンダリーネットワークのサポートマトリックス
ネットワーク機能	Layer2 トポロジー	Layer3 トポロジー	Localnet トポロジー ^[1]
east-west トラフィック	✓	✓	✓ (`NetworkAttachmentDefinition` CR のみ)
north-south トラフィック	X	X	✓ (`NetworkAttachmentDefinition` CR のみ)
永続的な IP	✓	X	✓ (`NetworkAttachmentDefinition` CR のみ)
サービス	X	X	X
ルート	X	X	X
`EgressIP` リソース	X	X	X
マルチキャスト	X	X	X
`NetworkPolicy` リソース	X	X	X
`MultiNetworkPolicy` リソース	✓	✓	✓ (`NetworkAttachmentDefinition` CR のみ)

Localnet トポロジーは、UserDefinedNetwork CR では使用できません。NetworkAttachmentDefinition CR のセカンダリーネットワークでのみサポートされます。

表16.3 ClusterUserDefinedNetwork CR のサポートマトリックス
ネットワーク機能	Layer2 トポロジー	Layer3 トポロジー
east-west トラフィック	✓	✓
north-south トラフィック	✓	✓
永続的な IP	✓	X
サービス	✓	✓
ルート	X	X
`EgressIP` リソース	✓	✓
マルチキャスト ^[1]	X	✓
`MultiNetworkPolicy` リソース	X	X
`NetworkPolicy` リソース ^[2]	✓	✓

マルチキャストは namespace で有効にする必要があり、OVN-Kubernetes ネットワーク Pod 間でのみ使用できます。詳細は、「マルチキャストについて」を参照してください。
プライマリーネットワークタイプを使用して ClusterUserDefinedNetwork CR を作成する場合、UserDefinedNetwork CR の後にネットワークポリシーを作成する必要があります。

関連情報

プロジェクトのマルチキャストの有効化

16.2. プライマリーネットワーク

16.2.1. ユーザー定義ネットワークについて

ユーザー定義ネットワーク (UDN) が実装される前は、OpenShift Container Platform の OVN-Kubernetes CNI プラグインは、プライマリーまたは メイン ネットワーク上の Layer 3 トポロジーのみをサポートしていました。Kubernetes の設計原則により、すべての Pod はメインネットワークにアタッチされ、すべての Pod は IP アドレスを使用して相互に通信し、Pod 間のトラフィックはネットワークポリシーに基づき制限されます。

Kubernetes 設計は単純なデプロイメントには便利ですが、この Layer 3 トポロジーでは、特に最新のマルチテナントデプロイメントの場合、プライマリーネットワークセグメント設定のカスタマイズが制限されます。

UDN では、カスタムの Layer 2 および Layer 3 ネットワークセグメントを有効にすることで、Kubernetes Pod ネットワークのデフォルトの Layer 3 トポロジーの柔軟性とセグメンテーション機能が向上します。これらのセグメントはすべてデフォルトで分離されています。これらのセグメントは、デフォルトの OVN-Kubernetes CNI プラグインを使用するコンテナー Pod および仮想マシンの、プライマリーネットワークまたはセカンダリーネットワークとして機能します。UDN を使用することで、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。

注記

cgroupv1 Linux Control Groups (cgroup) を使用するノードは、ユーザー定義ネットワークを作成する前に、cgroupv1 から cgroupv2 に再設定する必要があります。詳細は、Linux cgroup の設定を参照してください。

クラスター管理者は、ClusterUserDefinedNetwork カスタムリソース (CR) を使用することで、クラスターレベルで複数の namespace にまたがるプライマリーまたはセカンダリーのネットワークを UDN を使用して作成および定義できます。クラスター管理者またはクラスターユーザーは、UDN を使用して、namespace レベルで UserDefinedNetwork CR でセカンダリーネットワークを定義することもできます。

次のセクションでは、ユーザー定義ネットワークの利点と制限、ClusterUserDefinedNetwork または UserDefinedNetwork CR を作成する際のベストプラクティス、CR の作成方法、およびお客様のデプロイメントに関連する可能性のある追加設定の詳細についてさらに詳しく説明します。

16.2.1.1. ユーザー定義ネットワークの利点

ユーザー定義ネットワークには次のような利点があります。

セキュリティーのためのネットワーク分離の強化
- テナントの分離: Red Hat OpenStack Platform (RHOSP) でテナントが分離される方法と同様に、namespace には独自の分離されたプライマリーネットワークを設定できます。これにより、テナント間のトラフィックのリスクが軽減され、セキュリティーが向上します。
ネットワークの柔軟性
- レイヤー 2 およびレイヤー 3 のサポート: クラスター管理者は、プライマリーネットワークをレイヤー 2 またはレイヤー 3 のネットワークタイプとして設定できます。
簡素化されたネットワーク管理
- ネットワーク設定の複雑さの軽減: ユーザー定義ネットワークでは、異なるネットワーク内のワークロードをグループ化することで分離を実現できるため、複雑なネットワークポリシーが不要になります。
高度な機能
- 一貫性があり選択可能な IP アドレス指定: ユーザーは、異なる namespace 間とクラスター間で IP サブネットを指定して再利用できるため、一貫性のあるネットワーク環境が実現します。
- 複数のネットワークのサポート: ユーザー定義のネットワーク機能により、管理者は複数の namespace を単一のネットワークに接続したり、異なる namespace セットごとに個別のネットワークを作成したりできます。
Red Hat OpenStack Platform (RHOSP) からのアプリケーション移行の簡素化
- ネットワークパリティー: ユーザー定義ネットワークでは、同様のネットワーク分離および設定オプションが提供されるため、OpenStack から OpenShift Container Platform へのアプリケーションの移行が簡素化されます。

開発者と管理者は、カスタムリソースを使用して、namespace スコープのユーザー定義ネットワークを作成できます。プロセスの概要は次のとおりです。

管理者は、k8s.ovn.org/primary-user-defined-network ラベルを使用して、ユーザー定義ネットワークの namespace を作成します。
UserDefinedNetwork CR は、クラスター管理者またはユーザーによって作成されます。
ユーザーは namespace 内に Pod を作成します。

16.2.1.2. ユーザー定義ネットワークの制限

ユーザー定義ネットワーク (UDN) は高度にカスタマイズ可能なネットワーク設定オプションを提供しますが、クラスター管理者と開発者がこれらのネットワークを実装および管理する際に認識しておくべき制限があります。UDN を実装する前に、次の制限について考慮してください。

DNS の制限:
- Pod の DNS ルックアップは、クラスターのデフォルトネットワーク上の Pod の IP アドレスに解決されます。Pod がユーザー定義ネットワークの一部である場合でも、DNS ルックアップではそのユーザー定義ネットワーク上の Pod の IP アドレスは解決されません。ただし、サービスおよび外部エンティティーの DNS ルックアップは期待どおりに機能します。
- Pod がプライマリー UDN に割り当てられると、その Pod はクラスターのデフォルトネットワーク上の Kubernetes API (KAPI) および DNS サービスにアクセスできるようになります。
初期ネットワーク割り当て: Pod を作成する前に、namespace とネットワークを作成する必要があります。Pod を含む namespace を新しいネットワークに割り当てたり、既存の namespace に UDN を作成したりすることは、OVN-Kubernetes では受け入れられません。

ヘルスチェックの制限: Kubelet ヘルスチェックはクラスターのデフォルトネットワークによって実行されますが、Pod 上のプライマリーインターフェイスのネットワーク接続は確認されません。したがって、デフォルトネットワークでは Pod が正常に見えるものの、プライマリーインターフェイスで接続が切断されるというシナリオが、ユーザー定義ネットワークでは発生する可能性があります。
ネットワークポリシーの制限: ユーザー定義の異なるプライマリネットワークに接続された namespace 間のトラフィックを有効にするネットワークポリシーは効果がありません。これらのトラフィックポリシーが有効にならないのは、これらの隔離されたネットワーク間に接続性がないためです。
作成および変更の制限: ClusterUserDefinedNetwork CR および UserDefinedNetwork CR は、作成後に変更することはできません。
デフォルトのネットワークサービスアクセス: ユーザー定義ネットワークの Pod は、デフォルトのネットワークから分離されているため、ほとんどのデフォルトのネットワークサービスにアクセスできません。たとえば、ユーザー定義ネットワークの Pod は、現在 OpenShift Container Platform イメージレジストリーにアクセスできません。この制限のため、Source-to-Image ビルドはユーザー定義ネットワークの namespace では機能しません。さらに、Git リポジトリー内のソースコードに基づいてアプリケーションを作成する機能 (oc new-app <command> など) や、Source-to-Image ビルドを使用する OpenShift Container Platform テンプレートからアプリケーションを作成する機能など、他の機能も動作しません。この制限は他の openshift-*.svc サービスにも影響する可能性があります。
接続制限: ユーザー定義ネットワーク上の NodePort サービスは分離が保証されません。たとえば、同じノード上の Pod からサービスへの NodePort トラフィックにはアクセスできませんが、別のノード上の Pod からのトラフィックは成功します。

16.2.1.3. レイヤー 2 およびレイヤー 3 トポロジー

レイヤー 2 トポロジーは、クラスター内のすべてのノードに分散される仮想スイッチを作成します。仮想マシンと Pod はこの仮想スイッチに接続し、これらすべてのコンポーネントが同じサブネット内で相互通信できるようにします。レイヤー 2 サブネットを指定しない場合は、クラスター内の各 Pod の IP アドレスを手動で設定する必要があります。レイヤー 2 サブネットを指定しないと、ポートのセキュリティーがメディアアクセスコントロール (MAC) スプーフィングの防止だけに限定され、IP スプーフィングが対象外になります。レイヤー 2 トポロジーでは、単一のブロードキャストドメインが作成されます。しかし、大規模なネットワーク環境では、これにより問題が発生することがあります。ブロードキャストストームが発生して、ネットワークのパフォーマンスが低下する可能性があるためです。

次の図は、レイヤー 2 トポロジーの UDN を使用して Node 1 から Node 2 への Pod のライブマイグレーションを実行する 2 つのノードを示しています。各ノードには、次の 2 つのインターフェイスが含まれています。

ノードインターフェイス。これは、ネットワークコンポーネントをノードに接続するコンピュートノードです。
br-ex などの Open vSwitch (OVS) ブリッジ。これは、Pod が相互に通信してリソースを共有できるように、レイヤー 2 OVN スイッチを作成します。

これら 2 つのインターフェイスは、外部スイッチによって接続されています。ゲートウェイまたはルーターにより、外部スイッチとレイヤー 2 OVN スイッチ間のルーティングトラフィックが処理されます。ノード内の Pod は UDN を使用して相互に通信できます。レイヤー 2 OVN スイッチは、UDN 経由のノードトラフィックを処理します。これにより、あるノードから別のノードへの Pod のライブマイグレーションが可能になります。

図16.1 レイヤー 2 トポロジーを使用するユーザー定義ネットワーク (UDN)

Pod を node-1 から node-2 に移行するためにレイヤー 2 トポロジーを使用する UDN

レイヤー 3 トポロジーでは、クラスター内の各ノードに固有のレイヤー 2 セグメントが作成されます。レイヤー 3 ルーティングメカニズムはこれらのセグメントを相互接続し、異なるノードでホストされている仮想マシンと Pod が相互に通信できるようにします。レイヤー 3 トポロジーでは、各ドメインを特定のノードに割り当てることで大規模なブロードキャストドメインを効果的に管理できるため、ブロードキャストトラフィックの範囲は小さくなっています。レイヤー 3 トポロジーを設定するには、cidr および hostSubnet パラメーターを設定する必要があります。

16.2.1.4. ClusterUserDefinedNetwork CR について

ClusterUserDefinedNetwork (UDN) カスタムリソース (CR) は、管理者のみにクラスタースコープのネットワークセグメンテーションと分離を提供します。

次の図は、クラスター管理者が ClusterUserDefinedNetwork CR を使用してテナント間のネットワーク分離を作成する方法を示しています。このネットワーク設定により、ネットワークを複数の namespace にまたがって構築できるようになります。この図では、udn-1 と udn-2 という 2 つのユーザー定義ネットワークを作成することでネットワークを分離しています。これらのネットワークは接続されておらず、spec.namespaceSelector.matchLabels フィールドを使用して異なる namespace を選択しています。たとえば、udn-1 は namespace-1 と namespace-2 の通信を設定および分離し、udn-2 は namespace-3 と namespace-4 の通信を設定および分離します。namespace を分離し、同じ namespace 内の Pod が通信できるようにすることで、分離されたテナント (Tenants 1 と Tenants 2) が作成されます。

図16.2 ClusterUserDefinedNetwork CR を使用したテナント分離

16.2.1.4.1. ClusterUserDefinedNetwork CR のベストプラクティス

ユーザーは、ClusterUserDefinedNetwork カスタムリソース (CR) を設定する前に、次の情報を考慮する必要があります。

ClusterUserDefinedNetwork CR はクラスター管理者による使用を目的としているため、管理者以外は使用しないでください。誤って使用すると、デプロイメントでセキュリティー上の問題が発生したり、中断が発生したり、クラスターネットワークが切断されたりする可能性があります。
ClusterUserDefinedNetwork CR で default namespace を選択しないでください。分離されず、その結果としてクラスターにセキュリティーリスクが生じる可能性があります。
ClusterUserDefinedNetwork CR で openshift-* namespace を選択しないでください。
OpenShift Container Platform 管理者は、次のいずれかの条件が満たされると、クラスターのすべての namespace が選択されることに注意する必要があります。
- matchLabels セレクターが空のままである。
- matchExpressions セレクターが空のままである。
- namespaceSelector は初期化されているが、matchExpressions または matchLabel が指定されていない。例: namespaceSelector: {}。
プライマリーネットワークの場合、ClusterUserDefinedNetwork CR に使用される namespace には、k8s.ovn.org/primary-user-defined-network ラベルが含まれている必要があります。このラベルは更新できず、namespace 作成時にのみ追加できます。k8s.ovn.org/primary-user-defined-network namespace ラベルには次の条件が適用されます。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、Pod が作成された場合、Pod はデフォルトのネットワークにアタッチされます。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、その namespace に一致するプライマリー ClusterUserDefinedNetwork CR が作成されると、エラーが報告され、ネットワークは作成されません。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、プライマリー ClusterUserDefinedNetwork CR がすでに存在する場合、その namespace 内に Pod が作成され、デフォルトのネットワークにアタッチされます。
- namespace にラベルがあり、プライマリー ClusterUserDefinedNetwork CR が存在しない場合、ClusterUserDefinedNetwork CR が作成されるまで、その namespace に Pod は作成されません。

16.2.1.4.2. CLI を使用して ClusterUserDefinedNetwork CR を作成する

次の手順では、CLI を使用して ClusterUserDefinedNetwork カスタムリソース (CR) を作成します。ユースケースに基づき、Layer2 トポロジータイプの場合は cluster-layer-two-udn.yaml の例、Layer3 トポロジータイプの場合は cluster-layer-three-udn.yaml の例を使用してリクエストを作成します。

重要

ClusterUserDefinedNetwork CR はクラスター管理者による使用を目的としているため、管理者以外は使用しないでください。誤って使用すると、デプロイメントでセキュリティー上の問題が発生したり、中断が発生したり、クラスターネットワークが切断されたりする可能性があります。
OpenShift Virtualization は、Layer2 トポロジーのみをサポートします。

前提条件

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

手順

オプション: プライマリーネットワークを使用する ClusterUserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: <cudn_namespace_name>
  labels:
    k8s.ovn.org/primary-user-defined-network: ""
EOF

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: <cudn_namespace_name>
  labels:
    k8s.ovn.org/primary-user-defined-network: ""
EOF

Copy to clipboard

Layer2 または Layer3 トポロジータイプのクラスター全体のユーザー定義ネットワークリクエストを作成します。
1. Layer2 トポロジーのリクエストを定義するには、次の例のように、cluster-layer-two-udn.yaml などの YAML ファイルを作成します。
```
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: <cudn_name> 1
spec:
  namespaceSelector: 2
    matchLabels: 3
      "<label_1_key>": "<label_1_value>" 4
      "<label_2_key>": "<label_2_value>" 5
  network: 6
    topology: Layer2 7
    layer2: 8
      role: Primary 9
      subnets:
        - "2001:db8::/64"
        - "10.100.0.0/16" 10
```
```
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: <cudn_name> 1
spec:
  namespaceSelector: 2
    matchLabels: 3
      "<label_1_key>": "<label_1_value>" 4
      "<label_2_key>": "<label_2_value>" 5
  network: 6
    topology: Layer2 7
    layer2: 8
      role: Primary 9
      subnets:
        - "2001:db8::/64"
        - "10.100.0.0/16" 10
```
  Copy to clipboardCopied
  1
  ClusterUserDefinedNetwork CR の名前。
  2
  クラスター UDN CR が適用される namespace のセットに対するラベルクエリー。標準の Kubernetes MatchLabel セレクターを使用します。デフォルト または openshift-* namespace は指定しないでください。
  3
  matchLabels セレクタータイプを使用します。このセレクタータイプでは、用語が AND 関係で評価されます。
  4 5
  matchLabels セレクタータイプが使用されているため、<label_1_key>=<label_1_value> ラベルと <label_2_key>=<label_2_value> ラベルの両方を含む namespace がプロビジョニングされます。
  6
  ネットワーク設定を記述します。
  7
  topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2 と Layer3 です。Layer2 トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。
  8
  このフィールドは、トポロジー設定を指定します。layer2 または layer3 に指定できます。
  9
  Primary または Secondary を指定します。4.18 でサポートされる role 仕様は Primary のみです。
  10
  Layer2 トポロジータイプの場合、以下は subnet フィールドの設定を指定します。
  subnets フィールドは任意です。
  subnets フィールドはタイプが string で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。
  subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は 10.100.0.0/16 と 2001:db8::/64 です。
  Layer2 サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。
2. Layer3 トポロジーの要求を定義するには、次の例のように、cluster-layer-three-udn.yaml などの YAML ファイルを作成します。
```
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: <cudn_name> 1
spec:
  namespaceSelector: 2
    matchExpressions: 3
    - key: kubernetes.io/metadata.name 4
      operator: In 5
      values: ["<example_namespace_one>", "<example_namespace_two>"] 6
  network: 7
    topology: Layer3 8
    layer3: 9
      role: Primary 10
      subnets: 11
        - cidr: 10.100.0.0/16
          hostSubnet: 24
```
```
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: <cudn_name> 1
spec:
  namespaceSelector: 2
    matchExpressions: 3
    - key: kubernetes.io/metadata.name 4
      operator: In 5
      values: ["<example_namespace_one>", "<example_namespace_two>"] 6
  network: 7
    topology: Layer3 8
    layer3: 9
      role: Primary 10
      subnets: 11
        - cidr: 10.100.0.0/16
          hostSubnet: 24
```
  Copy to clipboardCopied
  1
  ClusterUserDefinedNetwork CR の名前。
  2
  クラスター UDN が適用される namespace セットに対するラベルクエリー。標準の Kubernetes MatchLabel セレクターを使用します。デフォルト または openshift-* namespace は指定しないでください。
  3
  matchExpressions セレクタータイプを使用します。このセレクタータイプでは、用語が OR 関係で評価されます。
  4
  照合するラベルキーを指定します。
  5
  Operator を指定します。有効な値には、In、NotIn、Exists、DoesNotExist などがあります。
  6
  matchExpressions タイプが使用されているため、<example_namespace_one> または <example_namespace_two> のいずれかに一致する namespace がプロビジョニングされます。
  7
  ネットワーク設定を記述します。
  8
  topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2 と Layer3 です。Layer3 トポロジータイプを指定すると、ノードごとにレイヤー 2 セグメントが作成され、それぞれに異なるサブネットが割り当てられます。レイヤー 3 ルーティングは、ノードサブネットを相互接続するために使用されます。
  9
  このフィールドは、トポロジー設定を指定します。有効な値は layer2 または layer3 です。
  10
  Primary ロールまたは Secondary ロールを指定します。4.18 でサポートされる role 仕様は Primary のみです。
  11
  Layer3 トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。
  subnets フィールドは必須です。
  subnets フィールドのタイプは、cidr および hostSubnet です。
  cidr はクラスターのサブネットであり、文字列値を受け入れます。
  hostSubnet は、クラスターサブネットが分割されるノードサブネット接頭辞を指定します。
  IPv6 の場合、hostSubnet では /64 の長さのみがサポートされます。
次のコマンドを実行してリクエストを適用します。
```
oc create --validate=true -f <example_cluster_udn>.yaml
```
```
$ oc create --validate=true -f <example_cluster_udn>.yaml
```
Copy to clipboardCopied
この場合の <example_cluster_udn>.yaml は Layer2 または Layer3 設定ファイルの名前です。

次のコマンドを実行して、リクエストが成功したことを確認します。

oc get clusteruserdefinednetwork <cudn_name> -o yaml

$ oc get clusteruserdefinednetwork <cudn_name> -o yaml

Copy to clipboard

この場合の <cudn_name> は、クラスター全体のユーザー定義ネットワークに作成した名前です。

出力例

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  creationTimestamp: "2024-12-05T15:53:00Z"
  finalizers:
  - k8s.ovn.org/user-defined-network-protection
  generation: 1
  name: my-cudn
  resourceVersion: "47985"
  uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
spec:
  namespaceSelector:
    matchExpressions:
    - key: custom.network.selector
      operator: In
      values:
      - example-namespace-1
      - example-namespace-2
      - example-namespace-3
  network:
    layer3:
      role: Primary
      subnets:
      - cidr: 10.100.0.0/16
    topology: Layer3
status:
  conditions:
  - lastTransitionTime: "2024-11-19T16:46:34Z"
    message: 'NetworkAttachmentDefinition has been created in following namespaces:
      [example-namespace-1, example-namespace-2, example-namespace-3]'
    reason: NetworkAttachmentDefinitionReady
    status: "True"
    type: NetworkCreated

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  creationTimestamp: "2024-12-05T15:53:00Z"
  finalizers:
  - k8s.ovn.org/user-defined-network-protection
  generation: 1
  name: my-cudn
  resourceVersion: "47985"
  uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
spec:
  namespaceSelector:
    matchExpressions:
    - key: custom.network.selector
      operator: In
      values:
      - example-namespace-1
      - example-namespace-2
      - example-namespace-3
  network:
    layer3:
      role: Primary
      subnets:
      - cidr: 10.100.0.0/16
    topology: Layer3
status:
  conditions:
  - lastTransitionTime: "2024-11-19T16:46:34Z"
    message: 'NetworkAttachmentDefinition has been created in following namespaces:
      [example-namespace-1, example-namespace-2, example-namespace-3]'
    reason: NetworkAttachmentDefinitionReady
    status: "True"
    type: NetworkCreated

Copy to clipboard

16.2.1.4.3. Web コンソールを使用して ClusterUserDefinedNetwork CR を作成する

OpenShift Container Platform Web コンソールの Layer2 トポロジーを使用して、ClusterUserDefinedNetwork カスタムリソース(CR)を作成できます。

注記

現時点で、OpenShift Container Platform Web コンソールを使用する場合、レイヤー 3 トポロジーを使用した ClusterUserDefinedNetwork CR の作成はサポートされません。

前提条件

cluster-admin パーミッションのあるユーザーとして OpenShift Container Platform Web コンソールにアクセスできる。
namespace を作成し、k8s.ovn.org/primary-user-defined-network ラベルを適用している。

手順

Administrator パースペクティブから、Networking → UserDefinedNetworks をクリックします。
ClusterUserDefinedNetwork をクリックします。
Name フィールドで、クラスタースコープの UDN の名前を指定します。
Subnet フィールドに値を指定します。
Project(s) Match Labels フィールドに適切なラベルを追加して、クラスター UDN が適用される namespace を選択します。
Create をクリックします。クラスタースコープの UDN は、手順 5 で指定したラベルを含む namespace に配置された Pod のデフォルトプライマリーネットワークとして機能します。

関連情報

静的 IP アドレスを使用して Pod を設定する

16.2.1.5. UserDefinedNetwork CR について

UserDefinedNetwork (UDN) カスタムリソース (CR) は、ユーザーと管理者に高度なネットワークのセグメンテーションと分離を提供します。

次の図は、4 つのクラスター namespace を示しています。各 namespace には 1 つのユーザー定義ネットワーク (UDN) が割り当てられており、各 UDN には Pod IP 割り当て用のカスタムサブネットが割り当てられています。OVN-Kubernetes は重複する UDN サブネットを処理します。Kubernetes ネットワークポリシーを使用しなくても、UDN にアタッチされた Pod はその UDN 内の他の Pod と通信できます。デフォルトでは、これらの Pod は他の UDN に配置された Pod との通信から分離されます。マイクロセグメンテーションの場合、UDN 内でネットワークポリシーを適用できます。namespace には 1 つ以上の UDN を割り当てることができますが、1 つの namespace には 1 つのプライマリー UDN を、1 つの UDN には 1 つ以上の namespace を割り当てるという制限があります。

図16.3 UserDefinedNetwork CR を使用した namespace 分離

16.2.1.5.1. UserDefinedNetwork CR のベストプラクティス

UserDefinedNetwork カスタムリソース (CR) を設定する前に、次の情報を考慮する必要があります。

UserDefinedNetwork CR の設定に openshift-* namespace は使用しないでください。
デフォルトの namespace に UserDefinedNetwork CR は作成しないでください。分離されず、その結果としてクラスターにセキュリティーリスクが生じる可能性があります。
プライマリーネットワークの場合、UserDefinedNetwork CR に使用される namespace には k8s.ovn.org/primary-user-defined-network ラベルが含まれている必要があります。このラベルは更新できず、namespace 作成時にのみ追加できます。k8s.ovn.org/primary-user-defined-network namespace ラベルには次の条件が適用されます。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、Pod が作成された場合、Pod はデフォルトのネットワークにアタッチされます。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、その namespace に一致するプライマリー UserDefinedNetwork CR が作成されると、ステータスエラーが報告され、ネットワークは作成されません。
- namespace に k8s.ovn.org/primary-user-defined-network ラベルがなく、プライマリー UserDefinedNetwork CR がすでに存在する場合、その namespace 内に Pod が作成され、デフォルトのネットワークにアタッチされます。
- namespace にラベルがあり、プライマリー UserDefinedNetwork CR が存在しない場合、UserDefinedNetwork CR が作成されるまで、その namespace に Pod は作成されません。
ユーザー定義ネットワークには 2 つのマスカレード IP アドレスが必要です。必要な数のネットワークを保持できる大きさになるように、マスカレードサブネットを再設定する必要があります。
重要
- OpenShift Container Platform 4.17 以降では、クラスターはデフォルトのマスカレードサブネットとして、IPv4 の場合は 169.254.0.0/17、IPv6 の場合は fd69::/112 を使用します。ユーザーはこれらの範囲を避ける必要があります。更新されたクラスターの場合は、デフォルトのマスカレードサブネットに変更がありません。
- プロジェクト用のユーザー定義ネットワークが設定された後は、クラスターのマスカレードサブネットの変更はサポートされません。UserDefinedNetwork CR を設定した後にマスカレードサブネットを変更しようとすると、ネットワーク接続が中断され、設定の問題が発生する可能性があります。
テナントが NetworkAttachmentDefinition (NAD) CR ではなく UserDefinedNetwork リソースを使用していることを確認します。これにより、テナント間でセキュリティー上のリスクが生じる可能性があります。
ネットワークセグメンテーションを作成するときは、UserDefinedNetwork CR を使用してユーザー定義のネットワークセグメンテーションを完了できない場合にのみ、NetworkAttachmentDefinition CR を使用する必要があります。
UserDefinedNetwork CR のクラスターサブネットとサービス CIDR は、デフォルトのクラスターサブネット CIDR と重複できません。OVN-Kubernetes ネットワークプラグインは、ネットワークのデフォルトの結合サブネットとして 100.64.0.0/16 を使用します。この値は、UserDefinedNetwork CR の joinSubnets フィールドの設定値として使用しないでください。クラスターのネットワーク内のどこかでデフォルトのアドレス値が使用されている場合は、joinSubnets フィールドを設定してデフォルト値をオーバーライドする必要があります。詳細は、「ユーザー定義ネットワークの追加設定の詳細」を参照してください。

16.2.1.5.2. CLI を使用して UserDefinedNetwork CR を作成する

次の手順では、namespace スコープの UserDefinedNetwork CR を作成します。ユースケースに基づき、Layer2 トポロジータイプの場合は my-layer-two-udn.yaml の例、Layer3 トポロジータイプの場合は my-layer-three-udn.yaml の例を使用してリクエストを作成します。

手順

オプション: プライマリーネットワークを使用する UserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: <udn_namespace_name>
  labels:
    k8s.ovn.org/primary-user-defined-network: ""
EOF

$ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: <udn_namespace_name>
  labels:
    k8s.ovn.org/primary-user-defined-network: ""
EOF

Copy to clipboard

Layer2 または Layer3 トポロジータイプのユーザー定義のネットワークのリクエストを作成します。
1. Layer2 トポロジーのリクエストを定義するには、次の例のように、my-layer-two-udn.yaml などの YAML ファイルを作成します。
```
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  name: udn-1 1
  namespace: <some_custom_namespace>
spec:
  topology: Layer2 2
  layer2: 3
    role: Primary 4
    subnets:
      - "10.0.0.0/24"
      - "2001:db8::/60" 5
```
```
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  name: udn-1 1
  namespace: <some_custom_namespace>
spec:
  topology: Layer2 2
  layer2: 3
    role: Primary 4
    subnets:
      - "10.0.0.0/24"
      - "2001:db8::/60" 5
```
  Copy to clipboardCopied
  1
  UserDefinedNetwork リソースの名前。これは default にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。
  2
  topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2 と Layer3 です。Layer2 トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。
  3
  このフィールドは、トポロジー設定を指定します。layer2 または layer3 に指定できます。
  4
  Primary ロールまたは Secondary ロールを指定します。
  5
  Layer2 トポロジータイプの場合、以下は subnet フィールドの設定を指定します。
  subnets フィールドは任意です。
  subnets フィールドはタイプが string で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。
  subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は 10.100.0.0/16 と 2001:db8::/64 です。
  Layer2 サブネットは省略できます。省略すると、ユーザーは Pod の IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。
  ipamLifecycle フィールドが指定されている場合、Layer2subnets フィールドは必須です。
2. Layer3 トポロジーのリクエストを定義するには、次の例のように、my-layer-three-udn.yaml などの YAML ファイルを作成します。
```
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  name: udn-2-primary 1
  namespace: <some_custom_namespace>
spec:
  topology: Layer3 2
  layer3: 3
    role: Primary 4
    subnets: 5
      - cidr: 10.150.0.0/16
        hostSubnet: 24
      - cidr: 2001:db8::/60
        hostSubnet: 64
# ...
```
```
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  name: udn-2-primary 1
  namespace: <some_custom_namespace>
spec:
  topology: Layer3 2
  layer3: 3
    role: Primary 4
    subnets: 5
      - cidr: 10.150.0.0/16
        hostSubnet: 24
      - cidr: 2001:db8::/60
        hostSubnet: 64
# ...
```
  Copy to clipboardCopied
  1
  UserDefinedNetwork リソースの名前。これは default にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。
  2
  topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2 と Layer3 です。Layer3 トポロジータイプを指定すると、ノードごとにレイヤー 2 セグメントが作成され、それぞれに異なるサブネットが割り当てられます。レイヤー 3 ルーティングは、ノードサブネットを相互接続するために使用されます。
  3
  このフィールドは、トポロジー設定を指定します。有効な値は layer2 または layer3 です。
  4
  Primary ロールまたは Secondary ロールを指定します。
  5
  Layer3 トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。
  subnets フィールドは必須です。
  subnets フィールドのタイプは、cidr および hostSubnet です。
  cidr は、クラスターの clusterNetwork 設定に相当します。CIDR 内の IP アドレスは、ユーザー定義ネットワーク内の Pod に配布されます。このパラメーターは文字列値を受け入れます。
  hostSubnet は、ノードごとのサブネット接頭辞を定義します。
  IPv6 の場合、hostSubnet では /64 の長さのみがサポートされます。
次のコマンドを実行してリクエストを適用します。
```
oc apply -f <my_layer_two_udn>.yaml
```
```
$ oc apply -f <my_layer_two_udn>.yaml
```
Copy to clipboardCopied
この場合の <my_layer_two_udn.yaml> は、Layer2 または Layer3 設定ファイルの名前です。

次のコマンドを実行して、リクエストが成功したことを確認します。

oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

Copy to clipboard

ここでは、some_custom_namespace は、ユーザー定義ネットワーク用に作成した namespace です。

出力例

apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  creationTimestamp: "2024-08-28T17:18:47Z"
  finalizers:
  - k8s.ovn.org/user-defined-network-protection
  generation: 1
  name: udn-1
  namespace: some-custom-namespace
  resourceVersion: "53313"
  uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c
spec:
  layer2:
    role: Primary
    subnets:
    - 10.0.0.0/24
    - 2001:db8::/60
  topology: Layer2
status:
  conditions:
  - lastTransitionTime: "2024-08-28T17:18:47Z"
    message: NetworkAttachmentDefinition has been created
    reason: NetworkAttachmentDefinitionReady
    status: "True"
    type: NetworkCreated

apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
  creationTimestamp: "2024-08-28T17:18:47Z"
  finalizers:
  - k8s.ovn.org/user-defined-network-protection
  generation: 1
  name: udn-1
  namespace: some-custom-namespace
  resourceVersion: "53313"
  uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c
spec:
  layer2:
    role: Primary
    subnets:
    - 10.0.0.0/24
    - 2001:db8::/60
  topology: Layer2
status:
  conditions:
  - lastTransitionTime: "2024-08-28T17:18:47Z"
    message: NetworkAttachmentDefinition has been created
    reason: NetworkAttachmentDefinitionReady
    status: "True"
    type: NetworkCreated

Copy to clipboard

16.2.1.5.3. Web コンソールを使用して UserDefinedNetwork CR を作成する

OpenShift Container Platform Web コンソールを使用して、Layer2 トポロジーと プライマリー ロールで UserDefinedNetwork カスタムリソース(CR)を作成できます。

注記

現時点で、OpenShift Container Platform Web コンソールを使用する場合、レイヤー 3 トポロジーまたは セカンダリー ロールを使用した UserDefinedNetwork CR の作成はサポートされません。

前提条件

cluster-admin パーミッションのあるユーザーとして OpenShift Container Platform Web コンソールにアクセスできる。
namespace を作成し、k8s.ovn.org/primary-user-defined-network ラベルを適用している。

手順

Administrator パースペクティブから、Networking → UserDefinedNetworks をクリックします。
Create UserDefinedNetwork をクリックします。
Project name リストから、以前に作成した namespace を選択します。
Subnet フィールドに値を指定します。
Create をクリックします。ユーザー定義ネットワークは、この namespace で作成する Pod のデフォルトのプライマリーネットワークとして機能します。

16.2.1.6. ユーザー定義ネットワークの追加設定の詳細

次の表では、オプションの ClusterUserDefinedNetwork および UserDefinedNetwork カスタムリソース (CR) の追加設定について説明します。OVN-Kubernetes ネットワークトポロジーに対する明示的な要件がなく、理解していない場合は、これらのフィールドを設定することは推奨しません。

表16.4 UserDefinedNetworks のオプションの設定
フィールド	型	説明
`spec.joinSubnets`	object	省略すると、プラットフォームは `joinSubnets` フィールドのデフォルト値を IPv4 の場合は `100.65.0.0/16`、IPv6 の場合は `fd99::/64` に設定します。クラスターのネットワーク内のどこかでデフォルトのアドレス値が使用されている場合は、`joinSubnets` フィールドを設定して上書きする必要があります。このフィールドを設定する場合は、クラスターサブネット、`default` ネットワーククラスターサブネット、マスカレードサブネットなど、クラスター内の他のサブネットと競合しないことを確認してください。 `joinSubnets` フィールドは、ユーザー定義ネットワーク内の異なるセグメント間のルーティングを設定します。デュアルスタッククラスターでは、IP ファミリーごとに 1 つずつ、合計 2 つのサブネットを設定できます。それ以外の場合は、1 つのサブネットのみが許可されます。このフィールドは `Primary` ネットワークに対してのみ許可されます。
`spec.ipam.lifecycle`	object	`spec.ipam.lifecycle` フィールドは、IP アドレス管理システム (IPAM) を設定します。永続的な IP アドレスを確保するために、仮想ワークロードにこのフィールドを使用する場合があります。許可される値は `Persistent` のみであり、これにより、再起動後や移行後も仮想ワークロードの IP アドレスが永続的になります。Container Network Interface (CNI) によって割り当てられ、OVN-Kubernetes によって Pod の IP アドレスをプログラムするために使用されます。Pod アノテーションの場合はこれを変更しないでください。 `Persistent` の値の設定は、`spec.ipam.mode` が `Enabled` に設定されている場合にのみサポートされます。
`spec.ipam.mode`	object	`spec.ipam.mode` フィールドは、OVN-Kubernetes が IP 設定を管理する範囲を制御します。以下のオプションが利用できます。 Enabled: 有効な場合、OVN-Kubernetes は IP 設定を SDN インフラストラクチャーに適用し、選択したサブネットの IP アドレスを個々の Pod に割り当てます。これはデフォルト設定です。`Enabled` に設定する場合は、`subnets` フィールドを定義する必要があります。`Enabled` はデフォルトの設定です。 Disabled: 無効な場合、OVN-Kubernetes は MAC アドレスのみを割り当て、レイヤー 2 通信を提供します。これにより、ユーザーは IP アドレスを設定できます。`Disabled` は、レイヤー 2 (セカンダリー) ネットワークでのみ使用できます。IPAM を無効にすると、ネットワークポリシーやサービスなど、IP での Pod 選択に依存する機能が動作しなくなります。さらに、このネットワークに接続されているインターフェイスでは IP ポートセキュリティーも無効になります。`spec.ipam.mode` が `Disabled.` に設定されている場合、`subnets` フィールドは空でなければなりません。
`spec.layer2.mtu` および `spec.layer3.mtu`	integer	最大転送単位 (MTU)。デフォルト値は `1400` です。IPv4 の境界は `576` で、IPv6 の境界は `1280` です。

16.2.1.7. ユーザー定義ネットワークのステータス条件タイプ

次の表は、リソースを記述するときに ClusterUserDefinedNetwork および UserDefinedNetwork CR に返されるステータス条件タイプについて説明しています。これらの条件は、デプロイメントのトラブルシューティングに使用できます。

表16.5 NetworkCreated 条件タイプ (ClusterDefinedNetwork および UserDefinedNetwork CR)
条件タイプ	ステータス	理由とメッセージ
`NetworkCreated`	`True`	`True` の場合、次の理由とメッセージが返されます。
		理由	メッセージ
		`NetworkAttachmentDefinitionCreated`	'NetworkAttachmentDefinition has been created in following namespaces: [example-namespace-1, example-namespace-2, example-namespace-3]'`
`NetworkCreated`	`False`	`False` の場合、次のいずれかのメッセージが返されます。
		理由	メッセージ
		`SyncError`	`failed to generate NetworkAttachmentDefinition`
		`SyncError`	`failed to update NetworkAttachmentDefinition`
		`SyncError`	`primary network already exist in namespace "<namespace_name>": "<primary_network_name>"`
		`SyncError`	`failed to create NetworkAttachmentDefinition: create NAD error`
		`SyncError`	`foreign NetworkAttachmentDefinition with the desired name already exist`
		`SyncError`	`failed to add finalizer to UserDefinedNetwork`
		`NetworkAttachmentDefinitionDeleted`	`NetworkAttachmentDefinition is being deleted: [<namespace>/<nad_name>]`

表16.6 NetworkAllocationSucceeded 条件タイプ (UserDefinedNetwork CR)
条件タイプ	ステータス	理由とメッセージ
`NetworkAllocationSucceeded`	`True`	`True` の場合、次の理由とメッセージが返されます。
		理由	メッセージ
		`NetworkAllocationSucceeded`	`Network allocation succeeded for all synced nodes.`
`NetworkAllocationSucceeded`	`False`	`False` の場合、次のメッセージが返されます。
		理由	メッセージ
		`InternalError`	`Network allocation failed for at least one node: [<node_name>], check UDN events for more info.`

16.2.1.8. ユーザー定義のネットワーク Pod でデフォルトのネットワークポートを開く

デフォルトでは、ユーザー定義ネットワーク (UDN) 上の Pod はデフォルトネットワークから分離されています。つまり、モニタリングサービス (Prometheus または Alertmanager) や OpenShift Container Platform イメージレジストリーを実行しているデフォルトのネットワーク Pod は、UDN Pod への接続を開始できません。

デフォルトのネットワーク Pod がユーザー定義のネットワーク Pod に接続できるようにするには、k8s.ovn.org/open-default-ports アノテーションを使用できます。このアノテーションは、デフォルトネットワークからのアクセス用に、ユーザー定義ネットワーク Pod 上の特定のポートを開きます。

次の Pod 仕様では、デフォルトネットワークからのポート 80 での着信 TCP 接続とポート 53 での UDP トラフィックが許可されます。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.ovn.org/open-default-ports: |
      - protocol: tcp
        port: 80
      - protocol: udp
        port: 53
# ...

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.ovn.org/open-default-ports: |
      - protocol: tcp
        port: 80
      - protocol: udp
        port: 53
# ...

Copy to clipboard

注記

開いているポートは、UDN ネットワーク IP ではなく、Pod のデフォルトネットワーク IP でアクセスできます。

16.2.2. NetworkAttachmentDefinition を使用したプライマリーネットワークの作成

次のセクションでは、NetworkAttachmentDefinition (NAD) リソースを使用してプライマリーネットワークを作成および管理する方法について説明します。

16.2.2.1. プライマリーネットワークの管理方法

NAD によって作成されたプライマリーネットワークのライフサイクルは、次のどちらかの方法で管理できます。

Cluster Network Operator (CNO) 設定を変更します。この方法を使用すると、CNO によって NetworkAttachmentDefinition オブジェクトが自動的に作成および管理されます。CNO は、オブジェクトのライフサイクルを管理するだけでなく、DHCP によって割り当てられる IP アドレスを使用するプライマリーネットワークで DHCP が利用可能であることを確認します。
YAML マニフェストを適用します。この方法を使用すると、NetworkAttachmentDefinition オブジェクトを作成してプライマリーネットワークを直接管理できます。この方法では、Pod にプライマリーネットワークインターフェイスを割り当てるために複数の CNI プラグインを呼び出すことができます。

各アプローチは同時に使用できず、プライマリーネットワークを管理する場合に 1 つのアプローチしか使用できません。どちらのアプローチでも、プライマリーネットワークは、お客様が設定した Container Network Interface (CNI) プラグインによって管理されます。

注記

OVN SDN を使用して、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>

Copy to clipboard

16.2.2.2. 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 clipboardCopied
CNO 設定を編集するには、以下のコマンドを入力します。
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to clipboardCopied

以下のサンプル 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

変更を保存し、テキストエディターを終了して、変更をコミットします。

検証

次のコマンドを実行して、CNO が NetworkAttachmentDefinition CRD を作成したことを確認します。CNO が CRD を作成するまでに遅延が発生する可能性があります。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace>
```
Copy to clipboardCopied
ここでは、以下のようになります。
<namespace>
CNO の設定に追加したネットワーク割り当ての namespace を指定します。
出力例
```
NAME                 AGE
test-network-1       14m
```
```
NAME                 AGE
test-network-1       14m
```
Copy to clipboardCopied

16.2.2.2.1. プライマリーネットワークアタッチメントの設定

プライマリーネットワークは、k8s.cni.cncf.io API グループの NetworkAttachmentDefinition API を使用して設定されます。

API の設定は、以下の表で説明されています。

表16.7 NetworkAttachmentDefinition API フィールド
フィールド	型	説明
`metadata.name`	`string`	プライマリーネットワークの名前。
`metadata.namespace`	`string`	オブジェクトが関連付けられる namespace。
`spec.config`	`string`	JSON 形式の CNI プラグイン設定。

16.2.2.3. YAML マニフェストを適用したプライマリーネットワークアタッチメントの作成

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
NAD のデプロイ先となる namespace で作業している。

手順

以下の例のように、プライマリーネットワーク設定を含む YAML ファイルを作成します。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "namespace": "namespace2", 1
      "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",
      "namespace": "namespace2", 1
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

Copy to clipboard

1: オプション: NAD が適用される namespace を指定できます。NAD のデプロイ先となる namespace で作業している場合、この仕様は必要ありません。

プライマリーネットワークを作成するには、次のコマンドを入力します。
```
oc apply -f <file>.yaml
```
```
$ oc apply -f <file>.yaml
```
Copy to clipboardCopied
ここでは、以下のようになります。
<file>
YAML マニフェストを含むファイルの名前を指定します。

16.3. セカンダリーネットワーク

16.3.1. OVN-Kubernetes でのセカンダリーネットワークの作成

クラスター管理者は、NetworkAttachmentDefinition (NAD) リソースを使用して、クラスターのセカンダリーネットワークを設定できます。

注記

セカンダリーネットワークとしてのユーザー定義ネットワークのサポートが、OpenShift Container Platform の今後のバージョンで追加される予定です。

16.3.1.1. OVN-Kubernetes セカンダリーネットワークの設定

Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインを使用すると、Pod のセカンダリーネットワークインターフェイスを設定できます。セカンダリーネットワークインターフェイスを設定するには、NetworkAttachmentDefinition カスタムリソース定義 (CRD) で設定を定義する必要があります。

注記

Pod およびマルチネットワークポリシーの作成は、ノード内の OVN-Kubernetes コントロールプレーンエージェントが関連する network-attachment-definition CRD を処理するまで、保留状態のままになる場合があります。

OVN-Kubernetes セカンダリーネットワークは、レイヤー 2、レイヤー 3、またはローカルネットトポロジーで設定できます。これらのトポロジーでサポートされる機能の詳細は、「UserDefinedNetwork および NetworkAttachmentDefinition のサポートマトリックス」を参照してください。

次のセクションでは、OVN-Kubernetes で現在セカンダリーネットワークに許可されている各トポロジーの設定例を示します。

注記

ネットワーク名は一意である必要があります。たとえば、同じネットワークを参照する異なる設定を持つ複数の NetworkAttachmentDefinition CRD の作成はサポートされていません。

16.3.1.1.1. OVN-Kubernetes セカンダリーネットワークのサポート対象プラットフォーム

次のサポート対象プラットフォームで OVN-Kubernetes セカンダリーネットワークを使用できます。

ベアメタル
IBM Power®
IBM Z®
IBM® LinuxONE
VMware vSphere
Red Hat OpenStack Platform (RHOSP)

16.3.1.1.2. OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル

次の表は、OVN-Kubernetes CNI ネットワークプラグインの設定パラメーターを示しています。

表16.8 OVN-Kubernetes ネットワークプラグインの JSON 設定テーブル
フィールド	型	説明
`cniVersion`	`string`	CNI 仕様のバージョン。必要な値は `0.3.1` です。
`name`	`string`	ネットワークの名前。このネットワークは namespace スコープではありません。たとえば、`l2-network` という名前のネットワークは、別の namespace に存在する `NetworkAttachmentDefinition` カスタムリソース (CR) によって参照できます。この設定により、別の namespace で `NetworkAttachmentDefinition` CR を使用する Pod が同じセカンダリーネットワークを介して通信できるようになります。ただし、`NetworkAttachmentDefinition` CR は、`topology`、`subnets`、`mtu`、`excludeSubnets`、`vlanID` などの同じネットワーク固有のパラメーターを共有する必要があります。`vlanID` パラメーターは、`topology` フィールドが `localnet` に設定されている場合にのみ適用されます。
`type`	`string`	設定する CNI プラグインの名前。この値は `ovn-k8s-cni-overlay` に設定する必要があります。
`topology`	`string`	ネットワークのトポロジー設定。`layer2` または `localnet` のいずれかである必要があります。
`subnets`	`string`	クラスター全体のネットワークに使用するサブネット。 `"topology":"layer2"` デプロイメントでは、IPv6 (`2001:DBB::/64`) およびデュアルスタック (`192.168.100.0/24,2001:DBB::/64`) サブネットがサポートされています。省略した場合、ネットワークを実装する論理スイッチはレイヤー 2 通信のみを提供し、ユーザーは Pod の IP アドレスを設定する必要があります。ポートセキュリティーは、MAC スプーフィングのみを防止します。
`mtu`	`string`	最大伝送単位 (MTU)。デフォルト値 `1300` は、カーネルによって自動的に設定されます。
`netAttachDefName`	`string`	この設定が含まれるネットワークアタッチメント定義 CRD のメタデータの `namespace` と `name`。たとえば、この設定が namespace `ns1` 内の `NetworkAttachmentDefinition` CRD で `l2-network` という名前で定義されている場合、このフィールドは `ns1/l2-network` に設定する必要があります。
`excludeSubnets`	`string`	CIDR と IP アドレスのコンマ区切りのリスト。IP アドレスは割り当て可能な IP アドレスプールから削除され、Pod に渡されることはありません。
`vlanID`	`integer`	トポロジーが `localnet` に設定されている場合、指定された VLAN タグがこのセカンダリーネットワークからのトラフィックに割り当てられます。デフォルトでは、VLAN タグは割り当てられません。

16.3.1.1.3. マルチネットワークポリシーとの互換性

k8s.cni.cncf.io API グループの MultiNetworkPolicy カスタムリソース定義 (CRD) によって提供されるマルチネットワークポリシー API は、OVN-Kubernetes セカンダリーネットワークと互換性があります。ネットワークポリシーを定義する場合、使用できるネットワークポリシールールは、OVN-Kubernetes セカンダリーネットワークが subnets フィールドを定義しているかどうかによって異なります。詳細は、次の表を参照してください。

表16.9 subnets CNI 設定に基づいてサポートされるマルチネットワークポリシーセレクター
`subnets` フィールドの指定	許可されたマルチネットワークポリシーセレクター
はい	`podSelector` と `namespaceSelector` `ipBlock`
いいえ	`ipBlock`

たとえば、次のマルチネットワークポリシーは、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: {}

Copy to clipboard

次の例では、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

Copy to clipboard

16.3.1.1.4. localnet スイッチドトポロジーの設定

スイッチド localnet トポロジーは、ネットワークアタッチメント定義 (NAD) として作成されたワークロードを、クラスター全体の論理スイッチを介して物理ネットワークに相互接続します。

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 1
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 2
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: localnet1 3
        bridge: br-ex 4
        state: present 5

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: mapping 1
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 2
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: localnet1 3
        bridge: br-ex 4
        state: present 5

Copy to clipboard

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

次の例では、localnet2 ネットワークインターフェイスが ovs-br1 ブリッジに接続されています。この接続を使って、ネットワークインターフェイスを OVN-Kubernetes ネットワークプラグインでセカンダリーネットワークとして利用できるようになります。

複数のインターフェイスを持つノードのマッピング例

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ovs-br1-multiple-networks 1
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 2
  desiredState:
    interfaces:
    - name: ovs-br1 3
      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
          mcast-snooping-enable: true 4
        port:
        - name: eth1 5
    ovn:
      bridge-mappings:
      - localnet: localnet2 6
        bridge: ovs-br1 7
        state: present 8

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ovs-br1-multiple-networks 1
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 2
  desiredState:
    interfaces:
    - name: ovs-br1 3
      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
          mcast-snooping-enable: true 4
        port:
        - name: eth1 5
    ovn:
      bridge-mappings:
      - localnet: localnet2 6
        bridge: ovs-br1 7
        state: present 8

Copy to clipboard

1

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

2

ノードネットワーク設定ポリシーが適用されるノードを識別するノードセレクターを指定します。

3

クラスタートラフィック用に OVN-Kubernetes によって使用されるデフォルトのブリッジとは別に動作する新しい OVS ブリッジを指定します。

4

マルチキャストスヌーピングを有効にするかどうかを指定します。マルチキャストスヌーピングを有効にすると、ネットワークデバイスがすべてのネットワークメンバーにマルチキャストトラフィックをフラッディングすることを防止します。デフォルトでは、OVS ブリッジはマルチキャストスヌーピングを有効にしません。デフォルト値は false です。

5

新しい OVS ブリッジに関連付けるホストシステム上のネットワークデバイスを指定します。

6

トラフィックを OVS ブリッジに転送するセカンダリーネットワークの名前を指定します。この名前は、OVN-Kubernetes セカンダリーネットワークを定義する NetworkAttachmentDefinition CRD の spec.config.name フィールドの値と一致する必要があります。

7

ノード上の OVS ブリッジの名前を指定します。値は、state: present が設定されている場合にのみ必要です。

8

マッピングの状態を指定します。有効な値は、ブリッジを追加する場合は 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

16.3.1.1.4.1. レイヤー 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"
}

Copy to clipboard

16.3.1.1.5. セカンダリーネットワーク用の 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

Copy to clipboard

ネットワーク

クラスターネットワークの設定および管理

第1章 ネットワークについて

1.1. OpenShift Container Platform のネットワーク

1.1.1. ネットワークサービスの一般的な慣行

1.1.2. ネットワーク機能

1.2. ノード、クライアント、クラスターとのネットワーク

1.2.1. ノードとは

1.2.2. クラスターとは

1.2.3. 外部クライアントとは

1.3. ネットワークの概念とコンポーネント

1.4. Pod の通信方法

1.4.1. Pod 間通信

1.4.1.1. 例: Pod 間通信の制御

1.4.2. サービスと Pod 間の通信

1.4.2.1. 例: サービスと Pod 間の通信を制御する

1.5. サポートされているロードバランサー

1.5.1. ロードバランサーの設定

1.5.1.1. デフォルトのロードバランサータイプを定義する

1.5.1.2. Ingress コントローラーのロードバランサーの動作を指定する

1.6. Domain Name System (DNS)

1.6.1. 重要な DNS 用語

1.6.2. 例: DNS のユースケース

1.7. ネットワーク制御

1.8. ルートと Ingress

1.8.1. ルート

1.8.2. Ingress

1.8.3. ルートと Ingress の比較

1.8.4. 例: ウェブアプリケーションを公開するためのルートと Ingress の設定

1.8.4.1. ルートの作成

1.8.4.2. Ingress の設定

1.9. セキュリティーとトラフィック管理

1.9.1. アプリケーションの公開

1.9.2. 接続のセキュリティー保護

1.9.3. 例: アプリケーションの公開と接続の保護

1.9.4. サービスタイプと API リソースの選択

第2章 ホストへのアクセス

2.1. installer-provisioned infrastructure クラスターでの Amazon Web Services のホストへのアクセス

第3章 ネットワークダッシュボード

3.1. Network Observability Operator

3.2. ネットワーキングと OVN-Kubernetes ダッシュボード

3.3. Ingress Operator ダッシュボード

第4章 ネットワーク Operator

4.1. Kubernetes NMState Operator

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

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

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

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

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

4.1.3. 関連情報

4.1.4. 次のステップ

4.2. AWS Load Balancer Operator

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

4.2.1.1. AWS Load Balancer Operator 1.2.0

4.2.1.1.1. 大きな変更

4.2.1.2. AWS Load Balancer Operator 1.1.1

4.2.1.3. AWS Load Balancer Operator 1.1.0

4.2.1.3.1. 大きな変更

4.2.1.3.2. 新機能

4.2.1.3.3. バグ修正

4.2.1.4. AWS Load Balancer Operator 1.0.1

4.2.1.5. AWS Load Balancer Operator 1.0.0

4.2.1.5.1. 大きな変更

4.2.1.5.2. バグ修正

4.2.1.6. 以前のバージョン

4.2.2. OpenShift Container Platform の AWS Load Balancer Operator

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

4.2.2.2. AWS Load Balancer Operator

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

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

4.2.3.1. 前提条件

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

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

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

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

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

4.2.3.4.1. Cloud Credential Operator ユーティリティーを使用してコントローラー用の AWS IAM ロールを作成する

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

4.2.3.5. 関連情報

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

第1章ネットワークについて

第2章ホストへのアクセス

第3章ネットワークダッシュボード

第4章ネットワーク Operator