Menu Close

ネットワーク

OpenShift Container Platform 4.9

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

概要

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

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

クラスター管理者は、クラスターで実行されるアプリケーションを外部トラフィックに公開し、ネットワーク接続のセキュリティーを保護するための複数のオプションがあります。

  • ノードポートやロードバランサーなどのサービスタイプ
  • IngressRouteなどの API リソース

デフォルトで、Kubernetes は各 Podに、Pod 内で実行しているアプリケーションの内部 IP アドレスを割り当てます。Pod とそのコンテナーはネットワークネットワーク接続が可能ですが、クラスター外のクライアントにはネットワークアクセスがありません。こうすることで、Pod 内の全コンテナーが同じホスト上にいるかように動作します。アプリケーションを外部トラフィックに公開する場合、各 Pod に IP アドレスを割り当てると、ポートの割り当て、ネットワーク、名前の指定、サービス検出、負荷分散、アプリケーション設定、移行などの点で、Pod を物理ホストや仮想マシンのように扱うことができます。

注記

一部のクラウドプラットフォームでは、169.254.169.254 IP アドレスでリッスンするメタデータ API があります。これは、IPv4 169.254.0.0/16 CIDR ブロックのリンクローカル IP アドレスです。

この CIDR ブロックは Pod ネットワークから到達できません。これらの IP アドレスへのアクセスを必要とする Pod には、Pod 仕様の spec.hostNetwork フィールドを true に設定して、ホストのネットワークアクセスが付与される必要があります。

Pod ホストのネットワークアクセスを許可する場合、Pod に基礎となるネットワークインフラストラクチャーへの特権アクセスを付与します。

1.1. OpenShift Container Platform DNS

フロントエンドサービスやバックエンドサービスなど、複数のサービスを実行して複数の Pod で使用している場合、フロントエンド Pod がバックエンドサービスと通信できるように、ユーザー名、サービス IP などの環境変数を作成します。サービスが削除され、再作成される場合には、新規の IP アドレスがそのサービスに割り当てられるので、フロントエンド Pod がサービス IP の環境変数の更新された値を取得するには、これを再作成する必要があります。さらに、バックエンドサービスは、フロントエンド Pod を作成する前に作成し、サービス IP が正しく生成され、フロントエンド Pod に環境変数として提供できるようにする必要があります。

そのため、OpenShift Container Platform には DNS が組み込まれており、これにより、サービスは、サービス IP/ポートと共にサービス DNS によって到達可能になります。

1.2. OpenShift Container Platform Ingress Operator

OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は IngressController API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress コントローラー をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などのIngress コントローラー内の設定は、Ingress コントローラーエンドポイントを公開する方法を提供します。

1.2.1. ルートと Ingress の比較

OpenShift Container Platform の Kubernetes Ingress リソースは、クラスター内で Pod として実行される共有ルーターサービスと共に Ingress コントローラーを実装します。Ingress トラフィックを管理する最も一般的な方法は Ingress コントローラーを使用することです。他の通常の Pod と同様にこの Pod をスケーリングし、複製できます。このルーターサービスは、オープンソースのロードバランサーソリューションである HAProxy をベースとしています。

OpenShift Container Platform ルートは、クラスターのサービスに Ingress トラフィックを提供します。ルートは、Blue-Green デプロイメント向けに TLS 再暗号化、TLS パススルー、分割トラフィックなどの標準の Kubernetes Ingress コントローラーでサポートされない可能性のある高度な機能を提供します。

Ingress トラフィックは、ルートを介してクラスターのサービスにアクセスします。ルートおよび Ingress は、Ingress トラフィックを処理する主要なリソースです。Ingress は、外部要求を受け入れ、ルートに基づいてそれらを委譲するなどのルートと同様の機能を提供します。ただし、Ingress では、特定タイプの接続(HTTP/2、HTTPS およびサーバー名 ID(SNI)、ならび証明書を使用した TLS のみを許可できます。OpenShift Container Platform では、ルートは、Ingress リソースで指定される各種の条件を満たすために生成されます。

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

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

2.1. インストーラーでプロビジョニングされるインフラストラクチャークラスターでの Amazon Web Services のホストへのアクセス

OpenShift Container Platform インストーラーは、OpenShift Container Platform クラスターにプロビジョニングされる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパブリック IP アドレスを作成しません。OpenShift Container Platform ホストに対して SSH を実行できるようにするには、以下の手順を実行する必要があります。

手順

  1. openshift-install コマンドで作成される仮想プライベートクラウド (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。
  2. インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。
  3. パブリック 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 でキーを指定することができます。

  4. Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。

    注記

    直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、特権付き Pod を代わりに実行します。

  5. oc get nodes を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名は ip-10-0-1-163.ec2.internal に類似したものになります。
  6. Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。

    $ ssh -i <ssh-key-path> core@<master-hostname>

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

Cluster Network Operator (CNO) は、インストール時にクラスター用に選択される Container Network Interface (CNI) デフォルトネットワークプロバイダープラグインを含む、OpenShift Container Platform クラスターの各種のクラスターネットワークコンポーネントをデプロイし、これらを管理します。

3.1. Cluster Network Operator

Cluster Network Operator は、operator.openshift.io API グループから network API を実装します。Operator は、デーモンセットを使用して OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダープラグイン、またはクラスターのインストール時に選択したデフォルトネットワークプロバイダープラグインをデプロイします。

手順

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

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

    $ oc get -n openshift-network-operator deployment/network-operator

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    network-operator   1/1     1            1           56m

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

    $ oc get clusteroperator/network

    出力例

    NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    network   4.5.4     True        False         False      50m

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

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

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

手順

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

    $ oc describe network.config/cluster

    出力例

    Name:         cluster
    Namespace:
    Labels:       <none>
    Annotations:  <none>
    API Version:  config.openshift.io/v1
    Kind:         Network
    Metadata:
      Self Link:           /apis/config.openshift.io/v1/networks/cluster
    Spec: 1
      Cluster Network:
        Cidr:         10.128.0.0/14
        Host Prefix:  23
      Network Type:   OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Status: 2
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
      Cluster Network MTU:  8951
      Network Type:         OpenShiftSDN
      Service Network:
        172.30.0.0/16
    Events:  <none>

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

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

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

手順

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

    $ oc describe clusteroperators/network

3.4. Cluster Network Operator ログの表示

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

手順

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

    $ oc logs --namespace=openshift-network-operator deployment/network-operator

3.5. Cluster Network Operator (CNO) の設定

クラスターネットワークの設定は、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
OpenShift SDN または OVN-Kubernetes などのクラスターネットワークプロバイダー。
注記

クラスターのインストール後に、直前のセクションで一覧表示されているフィールドを変更することはできません。

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

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

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

表3.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

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

spec.serviceNetwork

array

サービスの IP アドレスのブロック。OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダーは、サービスネットワークの単一 IP アドレスブロックのみをサポートします。以下は例になります。

spec:
  serviceNetwork:
  - 172.30.0.0/14

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

spec.defaultNetwork

object

クラスターネットワークの Container Network Interface (CNI) ネットワークプロバイダーを設定します。

spec.kubeProxyConfig

object

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

defaultNetwork オブジェクト設定

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

表3.2 defaultNetwork オブジェクト

フィールドタイプ詳細

type

string

OpenShiftSDN または OVNKubernetes のいずれか。クラスターネットワークプロバイダーはインストール時に選択されます。この値は、クラスターのインストール後は変更できません。

注記

OpenShift Container Platform はデフォルトで、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーを使用します。

openshiftSDNConfig

object

このオブジェクトは OpenShift SDN クラスターネットワークプロバイダーにのみ有効です。

ovnKubernetesConfig

object

このオブジェクトは OVN-Kubernetes クラスターネットワークプロバイダーにのみ有効です。

OpenShift SDN CNI クラスターネットワークプロバイダーの設定

以下の表は、OpenShift SDN Container Network Interface (CNI) クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表3.3 openshiftSDNConfig オブジェクト

フィールドタイプ詳細

mode

string

OpenShiftSDN のネットワーク分離モード。

mtu

integer

VXLAN オーバーレイネットワークの最大転送単位 (MTU)。通常、この値は自動的に設定されます。

vxlanPort

integer

すべての VXLAN パケットに使用するポート。デフォルト値は 4789 です。

注記

クラスターのインストール時にのみクラスターネットワークプロバイダーの設定を変更することができます。

OpenShift SDN 設定の例

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定

以下の表は OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定フィールドについて説明しています。

表3.4 ovnKubernetesConfig object

フィールドタイプ詳細

mtu

integer

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

genevePort

integer

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

ipsecConfig

object

フィールドがある場合、IPsec はクラスターに対して有効にされます。

policyAuditConfig

object

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

表3.5 policyAuditConfig object

フィールドタイプ詳細

rateLimit

integer

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

maxFileSize

integer

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

destination

string

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

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

syslogFacility

string

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

注記

クラスターのインストール時にのみクラスターネットワークプロバイダーの設定を変更することができます。

OVN-Kubernetes 設定の例

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig: {}

kubeProxyConfig オブジェクト設定

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

表3.6 kubeProxyConfig オブジェクト

フィールドタイプ詳細

iptablesSyncPeriod

string

iptables ルールの更新期間。デフォルト値は 30s です。有効なサフィックスには、sm、および h などが含まれ、これらについては、Go time パッケージドキュメントで説明されています。

注記

OpenShift Container Platform 4.3 以降で強化されたパフォーマンスの向上により、iptablesSyncPeriod パラメーターを調整する必要はなくなりました。

proxyArguments.iptables-min-sync-period

array

iptables ルールを更新する前の最小期間。このフィールドにより、更新の頻度が高くなり過ぎないようにできます。有効なサフィックスには、sm、および h などが含まれ、これらについては、Go time パッケージで説明されています。デフォルト値:

kubeProxyConfig:
  proxyArguments:
    iptables-min-sync-period:
    - 0s

3.5.2. Cluster Network Operator の設定例

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

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

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork: 1
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork: 2
  - 172.30.0.0/16
  defaultNetwork: 3
    type: OpenShiftSDN
    openshiftSDNConfig:
      mode: NetworkPolicy
      mtu: 1450
      vxlanPort: 4789
  kubeProxyConfig:
    iptablesSyncPeriod: 30s
    proxyArguments:
      iptables-min-sync-period:
      - 0s

1 2 3
クラスターのインストール時にのみ設定されます。

3.6. 関連情報

第4章 OpenShift Container Platform の DNS Operator

DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、OpenShift Container Platform での DNS ベースの Kubernetes サービス検出を可能にします。

4.1. DNS Operator

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

手順

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

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

    $ oc get -n openshift-dns-operator deployment/dns-operator

    出力例

    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
    dns-operator   1/1       1            1           23h

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

    $ oc get clusteroperator/dns

    出力例

    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
    dns       4.1.0-0.11  True        False         False      92m

    AVAILABLEPROGRESSING および DEGRADED は、Operator のステータスについての情報を提供します。AVAILABLE は、CoreDNS デーモンセットからの 1 つ以上の Pod が Available ステータス条件を報告する場合は True になります。

4.2. DNS Operator managementState の変更

DNS は CoreDNS コンポーネントを管理し、クラスター内の Pod およびサービスの名前解決サービスを提供します。DNS Operator の managementState はデフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理できることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

  • 開発者であり、CoreDNS の問題が修正されているかどうかを確認するために設定変更をテストする必要があります。managementStateUnmanaged に設定すると、DNS Operator により修正が上書きされないようにできます。
  • クラスター管理者であり、CoreDNS の問題が報告されていますが、問題が修正されるまで回避策を適用する必要があります。DNS Operator の managementState フィールドを Unmanaged に設定して、回避策を適用できます。

手順

  • managementState DNS Operator を変更します。

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

4.3. DNS Pod 配置の制御

DNS Operator には、CoreDNS 用と /etc/hosts ファイルを管理するための 2 つのデーモンセットがあります。/etc/hosts に設定されたデーモンは、イメージのプルをサポートするクラスターイメージレジストリーのエントリーを追加するために、すべてのノードホストで実行する必要があります。セキュリティーポリシーにより、ノードのペア間の通信が禁止され、CoreDNS のデーモンセットがすべてのノードで実行できなくなります。

クラスター管理者は、カスタムノードセレクターを使用して、CoreDNS のデーモンセットを特定のノードで実行するか、または実行しないように設定できます。

前提条件

  • oc CLI をインストールしていること。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。

手順

  • 特定のノード間の通信を防ぐには、spec.nodePlacement.nodeSelector API フィールドを設定します。

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

      $ oc edit dns.operator/default
    2. spec.nodePlacement.nodeSelector API フィールドにコントロールプレーンノードのみが含まれるノードセレクターを指定します。

       spec:
         nodePlacement:
           nodeSelector:
             node-role.kubernetes.io/worker: ""
  • CoreDNS のデーモンセットをノードで実行されるようにするには、テイントおよび容認を設定します。

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

      $ oc edit dns.operator/default
    2. テイントのテイントキーおよび容認を指定します。

       spec:
         nodePlacement:
           tolerations:
           - effect: NoExecute
             key: "dns-only"
             operators: Equal
             value: abc
             tolerationSeconds: 3600 1
      1
      テイントが dns-only である場合、それは無制限に許容できます。tolerationSeconds は省略できます。

4.4. デフォルト DNS の表示

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

手順

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

    $ oc describe dns.operator/default

    出力例

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

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

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

出力例

[172.30.0.0/16]

4.5. DNS 転送の使用

DNS 転送を使用すると、指定のゾーンにどのネームサーバーを使用するかを指定することで、ゾーンごとに /etc/resolv.conf で特定される転送設定をオーバーライドできます。転送されるゾーンが OpenShift Container Platform によって管理される Ingress ドメインである場合、アップストリームネームサーバーがドメインについて認証される必要があります。

手順

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

    $ oc edit dns.operator/default

    これにより、Server に基づく追加のサーバー設定ブロックを使用して dns-default という名前の ConfigMap を作成し、更新できます。クエリーに一致するゾーンを持つサーバーがない場合、名前解決は /etc/resolv.conf で指定されたネームサーバーにフォールバックします。

    DNS の例

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      servers:
      - name: foo-server 1
        zones: 2
          - example.com
        forwardPlugin:
          upstreams: 3
            - 1.1.1.1
            - 2.2.2.2:5353
      - name: bar-server
        zones:
          - bar.com
          - example.com
        forwardPlugin:
          upstreams:
            - 3.3.3.3
            - 4.4.4.4:5454

    1
    name は、rfc6335 サービス名の構文に準拠する必要があります。
    2
    zones は、rfc1123subdomain の定義に準拠する必要があります。クラスタードメインの cluster.local は、 zones の無効な subdomain です。
    3
    forwardPlugin ごとに最大 15 の upstreams が許可されます。
    注記

    servers が定義されていないか、または無効な場合、ConfigMap にはデフォルトサーバーのみが含まれます。

  2. ConfigMap を表示します。

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    以前のサンプル DNS に基づく DNS ConfigMap の例

    apiVersion: v1
    data:
      Corefile: |
        example.com:5353 {
            forward . 1.1.1.1 2.2.2.2:5353
        }
        bar.com:5353 example.com:5353 {
            forward . 3.3.3.3 4.4.4.4:5454 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 {
                policy sequential
            }
            cache 30
            reload
        }
    kind: ConfigMap
    metadata:
      labels:
        dns.operator.openshift.io/owning-dns: default
      name: dns-default
      namespace: openshift-dns

    1
    forwardPlugin への変更により、CoreDNS デーモンセットのローリングアップデートがトリガーされます。

関連情報

4.6. DNS Operator のステータス

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

手順

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

$ oc describe clusteroperators/dns

4.7. DNS Operator ログ

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

手順

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

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

第5章 OpenShift Container Platform の Ingress Operator

5.1. OpenShift Container Platform Ingress Operator

OpenShift Container Platform クラスターを作成すると、クラスターで実行している Pod およびサービスにはそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。Ingress Operator は IngressController API を実装し、OpenShift Container Platform クラスターサービスへの外部アクセスを可能にするコンポーネントです。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress コントローラー をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。OpenShift Container Platform Route および Kubernetes Ingress リソースを指定して、トラフィックをルーティングするために Ingress Operator を使用します。endpointPublishingStrategy タイプおよび内部負荷分散を定義する機能などのIngress コントローラー内の設定は、Ingress コントローラーエンドポイントを公開する方法を提供します。

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

インストールプログラムは、このアセットを manifests/ ディレクトリーの cluster-ingress-02-config.yml ファイルに保存します。この Ingress リソースは、Ingress のクラスター全体の設定を定義します。この Ingress 設定は、以下のように使用されます。

  • Ingress Operator は、クラスター Ingress 設定のドメインを、デフォルト Ingress コントローラーのドメインとして使用します。
  • OpenShift API Server Operator は、クラスター Ingress 設定からのドメインを使用します。このドメインは、明示的なホストを指定しない Route リソースのデフォルトホストを生成する際にも使用されます。

5.3. Ingress コントローラー設定パラメーター

ingresscontrollers.operator.openshift.io リソースは以下の設定パラメーターを提供します。

パラメーター詳細

domain

domain は Ingress コントローラーによって提供される DNS 名で、複数の機能を設定するために使用されます。

  • LoadBalancerService エンドポイント公開ストラテジーの場合、domain は DNS レコードを設定するために使用されます。endpointPublishingStrategy を参照してください。
  • 生成されるデフォルト証明書を使用する場合、証明書は domain およびその subdomains で有効です。defaultCertificate を参照してください。
  • この値は個別の Route ステータスに公開され、ユーザーは外部 DNS レコードのターゲット先を認識できるようにします。

domain 値はすべての Ingress コントローラーの中でも固有の値であり、更新できません。

空の場合、デフォルト値は ingress.config.openshift.io/cluster .spec.domain です。

replicas

replicas は Ingress コントローラーレプリカの必要な数です。設定されていない場合、デフォルト値は 2 になります。

endpointPublishingStrategy

endpointPublishingStrategy は Ingress コントローラーエンドポイントを他のネットワークに公開し、ロードバランサーの統合を有効にし、他のシステムへのアクセスを提供するために使用されます。

設定されていない場合、デフォルト値は infrastructure.config.openshift.io/cluster .status.platform をベースとします。

  • AWS: LoadBalancerService (外部スコープあり)
  • Azure: LoadBalancerService (外部スコープあり)
  • GCP: LoadBalancerService (外部スコープあり)
  • Bare metal: NodePortService
  • その他: HostNetwork

ほとんどのプラットフォームの場合、endpointPublishingStrategy 値は更新できません。ただし、GCP では、loadbalancer.providerParameters.gcp.clientAccess サブフィールドを設定できます。

defaultCertificate

defaultCertificate 値は、Ingress コントローラーによって提供されるデフォルト証明書が含まれるシークレットへの参照です。ルートが独自の証明書を指定しない場合、defaultCertificate が使用されます。

シークレットには以下のキーおよびデータが含まれる必要があります: * tls.crt: 証明書ファイルコンテンツ * tls.key: キーファイルコンテンツ

設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの domain および subdomains で有効であり、生成された証明書 CA はクラスターの信頼ストアに自動的に統合されます。

使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。

namespaceSelector

namespaceSelector は、Ingress コントローラーによって提供される namespace セットをフィルターするために使用されます。これはシャードの実装に役立ちます。

routeSelector

routeSelector は、Ingress コントローラーによって提供される Routes のセットをフィルターするために使用されます。これはシャードの実装に役立ちます。

nodePlacement

nodePlacement は、Ingress コントローラーのスケジュールに対する明示的な制御を有効にします。

設定されていない場合は、デフォルト値が使用されます。

注記

nodePlacement パラメーターには、nodeSelectortolerationsの 2 つの部分が含まれます。以下は例になります。

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists

tlsSecurityProfile

tlsSecurityProfile は、Ingress コントローラーの TLS 接続の設定を指定します。

これが設定されていない場合、デフォルト値は apiservers.config.openshift.io/cluster リソースをベースとして設定されます。

OldIntermediate、および Modern のプロファイルタイプを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が Ingress コントローラーに適用され、ロールアウトが生じる可能性があります。

Ingress コントローラーの最小 TLS バージョンは 1.1 で、最大 TLS バージョンは 1.3 です。

注記

設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが TLSProfile ステータスに反映されます。

重要

Ingress Operator は TLS 1.0Old または Custom プロファイルを 1.1 に変換します。

clientTLS

clientTLS は、クラスターおよびサービスへのクライアントアクセスを認証します。その結果、相互 TLS 認証が有効になります。設定されていない場合、クライアント TLS は有効になっていません。

ClientTLS には、必要なサブフィールド spec.clientTLS.clientCertificatePolicy および spec.clientTLS.ClientCA があります。

ClientCertificatePolicy サブフィールドは、Required または Optional の 2 つの値のいずれかを受け入れます。ClientCA サブフィールドは、openshift-config namespace にある設定マップを指定します。設定マップには CA 証明書バンドルが含まれている必要があります。AllowedSubjectPatterns は、要求をフィルターするために有効なクライアント証明書の識別名と照合される正規表現の一覧を指定する任意の値です。正規表現は PCRE 構文を使用する必要があります。1 つ以上のパターンがクライアント証明書の識別名と一致している必要があります。一致しない場合、Ingress コントローラーは証明書を拒否し、接続を拒否します。指定しないと、Ingress コントローラーは識別名に基づいて証明書を拒否しません。

routeAdmission

routeAdmission は、複数の namespace での要求の許可または拒否など、新規ルート要求を処理するためのポリシーを定義します。

namespaceOwnership は、namespace 間でホスト名の要求を処理する方法を記述します。デフォルトは Strict です。

  • Strict: ルートが複数の namespace 間で同じホスト名を要求することを許可しません。
  • InterNamespaceAllowed: ルートが複数の namespace 間で同じホスト名の異なるパスを要求することを許可します。

wildcardPolicy は、ワイルドカードポリシーを使用するルートが Ingress コントローラーによって処理される方法を記述します。

  • WildcardsAllowed: ワイルドカードポリシーと共にルートが Ingress コントローラーによって許可されていることを示します。
  • WildcardsDisallowed: ワイルドカードポリシーの None を持つルートのみが Ingress コントローラーによって許可されることを示します。wildcardPolicyWildcardsAllowed から WildcardsDisallowed に更新すると、ワイルドカードポリシーの Subdomain を持つ許可されたルートが機能を停止します。これらのルートは、Ingress コントローラーによって許可されるように None のワイルドカードポリシーに対して再作成される必要があります。WildcardsDisallowed はデフォルト設定です。

IngressControllerLogging

logging はログに記録される内容および場所のパラメーターを定義します。このフィールドが空の場合、操作ログは有効になりますが、アクセスログは無効になります。

  • access は、クライアント要求をログに記録する方法を記述します。このフィールドが空の場合、アクセスロギングは無効になります。

    • destination はログメッセージの宛先を記述します。

      • type はログの宛先のタイプです。

        • Container は、ログがサイドカーコンテナーに移動することを指定します。Ingress Operator は Ingress コントローラー Pod で logs という名前のコンテナーを設定し、Ingress コントローラーがログをコンテナーに書き込むように設定します。管理者がこのコンテナーからログを読み取るカスタムロギングソリューションを設定することが予想されます。コンテナーログを使用すると、ログの割合がコンテナーランタイムの容量やカスタムロギングソリューションの容量を超えるとログがドロップされることがあります。
        • Syslog は、ログが Syslog エンドポイントに送信されることを指定します。管理者は、Syslog メッセージを受信できるエンドポイントを指定する必要があります。管理者がカスタム Syslog インスタンスを設定していることが予想されます。
      • containerContainer ロギング宛先タイプのパラメーターを記述します。現在、コンテナーロギングのパラメーターはないため、このフィールドは空である必要があります。
      • syslog は、Syslog ロギング宛先タイプのパラメーターを記述します。

        • address は、ログメッセージを受信する syslog エンドポイントの IP アドレスです。
        • port は、ログメッセージを受信する syslog エンドポイントの UDP ポート番号です。
        • facility はログメッセージの syslog ファシリティーを指定します。このフィールドが空の場合、ファシリティーは local1 になります。それ以外の場合、有効な syslog ファシリティー ( kernusermaildaemonauthsysloglprnewsuucpcronauth2ftpntpauditalertcron2local0local1local2local3) を指定する必要があります。local4local5local6、または local7
    • httpLogFormat は、HTTP 要求のログメッセージの形式を指定します。このフィールドが空の場合、ログメッセージは実装のデフォルト HTTP ログ形式を使用します。HAProxy のデフォルトの HTTP ログ形式については、HAProxy ドキュメント を参照してください。

httpHeaders

httpHeaders は HTTP ヘッダーのポリシーを定義します。

IngressControllerHTTPHeadersforwardedHeaderPolicy を設定することで、Ingress コントローラーが ForwardedX-Forwarded-ForX-Forwarded-HostX-Forwarded-PortX-Forwarded-Proto、および X-Forwarded-Proto-Version HTTP ヘッダーをいつどのように設定するか指定します。

デフォルトでは、ポリシーは Append に設定されます。

  • Append は、Ingress コントローラーがヘッダーを追加するように指定し、既存のヘッダーを保持します。
  • Replace は、Ingress コントローラーがヘッダーを設定するように指定し、既存のヘッダーを削除します。
  • IfNone は、ヘッダーがまだ設定されていない場合に、Ingress コントローラーがヘッダーを設定するように指定します。
  • Never は、Ingress コントローラーがヘッダーを設定しないように指定し、既存のヘッダーを保持します。

headerNameCaseAdjustments を設定して、HTTP ヘッダー名に適 用できるケースの調整を指定できます。それぞれの調整は、必要な大文字化を指定して HTTP ヘッダー名として指定されます。たとえば、X-Forwarded-For を指定すると、指定された大文字化を有効にするために x-forwarded-for HTTP ヘッダーを調整する必要があることを示唆できます。

これらの調整は、クリアテキスト、edge terminationd、および re-encrypt ルートにのみ適用され、HTTP/1 を使用する場合にのみ適用されます。

要求ヘッダーの場合、これらの調整は haproxy.router.openshift.io/h1-adjust-case=true アノテーションを持つルートについてのみ適用されます。応答ヘッダーの場合、これらの調整はすべての HTTP 応答に適用されます。このフィールドが空の場合、要求ヘッダーは調整されません。

httpErrorCodePages

httpErrorCodePages は、カスタムの HTTP エラーコードの応答ページを指定します。デフォルトで、IngressController は IngressController イメージにビルドされたエラーページを使用します。

tuningOptions

tuningOptions は、Ingress コントローラー Pod のパフォーマンスを調整するためのオプションを指定します。

  • headerBufferBytes は、Ingress コントローラー接続セッション用に予約されるメモリーの量をバイト単位で指定します。Ingress コントローラーで HTTP / 2 が有効になっている場合、この値は少なくとも 16384 である必要があります。設定されていない場合、デフォルト値は 32768 バイトになります。このフィールドを設定することはお勧めしません。headerBufferBytes 値が小さすぎると Ingress コントローラーが破損する可能性があり、headerBufferBytes 値が大きすぎると、Ingress コントローラーが必要以上のメモリーを使用する可能性があるためです。
  • headerBufferMaxRewriteBytes は、HTTP ヘッダーの書き換えと Ingress コントローラー接続セッションの追加のために headerBufferBytes から予約するメモリーの量をバイト単位で指定します。headerBufferMaxRewriteBytes の最小値は 4096 です。受信 HTTP 要求には、headerBufferBytesheaderBufferMaxRewriteBytes よりも大きくなければなりません。設定されていない場合、デフォルト値は 8192 バイトになります。このフィールドを設定することはお勧めしません。headerBufferMaxRewriteBytes 値が小さすぎると Ingress コントローラーが破損する可能性があり、headerBufferMaxRewriteBytes 値が大きすぎると、Ingress コントローラーが必要以上のメモリーを使用する可能性があるためです。
  • threadCount は、HAProxy プロセスごとに作成するスレッドの数を指定します。より多くのスレッドを作成すると、使用されるシステムリソースを増やすことで、各 Ingress コントローラー Pod がより多くの接続を処理できるようになります。HAProxy は最大 64 のスレッドをサポートします。このフィールドが空の場合、Ingress コントローラーはデフォルト値の 4 スレッドを使用します。デフォルト値は、将来のリリースで変更される可能性があります。このフィールドを設定することはお勧めしません。HAProxy スレッドの数を増やすと、Ingress コントローラー Pod が負荷時に CPU 時間をより多く使用できるようになり、他の Pod が実行に必要な CPU リソースを受け取れないようになるためです。スレッドの数を減らすと、Ingress コントローラーのパフォーマンスが低下する可能性があります。
  • clientTimeout は、クライアント応答の待機中に接続が開かれる期間を指定します。未設定の場合、デフォルトのタイムアウトは 30s です。
  • serverFinTimeout は、接続を閉じるクライアントへの応答を待つ間、接続が開かれる期間を指定します。未設定の場合、デフォルトのタイムアウトは 1s です。
  • serverTimeout は、サーバーの応答を待機している間に接続が開かれる期間を指定します。未設定の場合、デフォルトのタイムアウトは 30s です。
  • clientFinTimeout は、クライアントの応答が接続を閉じるのを待機している間に接続が開かれる期間を指定します。未設定の場合、デフォルトのタイムアウトは 1s です。
  • tlsInspectDelay は、一致するルートを見つけるためにルーターがデータを保持する期間を指定します。この値の設定が短すぎると、より一致する証明書を使用している場合でも、ルーターがエッジ終端、再暗号化された、またはパススルーのルートのデフォルトの証明書にフォールバックする可能性があります。未設定の場合、デフォルトの検査遅延は 5s です。
  • tunnelTimeout は、トンネルがアイドル状態の間、WebSocket などのトンネル接続期間を開いた期間を指定します。未設定の場合、デフォルトのタイムアウトは 1h です。

logEmptyRequests

logEmptyRequests は、リクエストを受け取らず、ログに記録されない接続を指定します。これらの空の要求は、ロードバランサーヘルスプローブまたはWebブラウザーの投機的接続(事前接続)から送信され、これらの要求をログに記録することは望ましくない場合があります。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。この場合は、空の要求をログに記録すると、エラーの診断に役立ちます。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。このフィールドに使用できる値は Log および Ignore です。デフォルト値は Log です。

LoggingPolicy タイプは、以下のいずれかの値を受け入れます。

  • ログ: この値を Log に設定すると、イベントがログに記録される必要があることを示します。
  • Ignore: この値を Ignore に設定すると、HAproxy 設定の dontlognull オプションを設定します。

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy は、リクエストを受け取る前に接続がタイムアウトした場合に HTTP 接続を処理する方法を記述します。このフィールドに使用できる値は Respond および Ignore です。デフォルト値は Respond です。

HTTPEmptyRequestsPolicy タイプは、以下のいずれかの値を受け入れます。

  • 応答: フィールドが Respond に設定されている場合、Ingress コントローラーは HTTP 400 または 408 応答を送信する場合、アクセスログが有効な場合に接続をログに記録し、適切なメトリクスで接続をカウントします。
  • ignore: このオプションを Ignore に設定すると HAproxy 設定に http-ignore-probes パラメーターが追加されます。フィールドが Ignore に設定されている場合、Ingress コントローラーは応答を送信せずに接続を閉じると、接続をログに記録するか、メトリクスを増分します。

これらの接続は、ロードバランサーのヘルスプローブまたは Web ブラウザーの投機的接続(事前接続)から取得され、無視しても問題はありません。ただし、これらの要求はネットワークエラーによって引き起こされる可能性があります。そのため、このフィールドを Ignore に設定すると問題の検出と診断が妨げられる可能性があります。これらの要求はポートスキャンによって引き起こされ、空の要求をログに記録すると、侵入の試行が検出されなくなります。

注記

すべてのパラメーターはオプションです。

5.3.1. Ingress コントローラーの TLS セキュリティープロファイル

TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。

5.3.1.1. TLS セキュリティープロファイルについて

TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定 に基づいています。

コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。

表5.1 TLS セキュリティープロファイル

プロファイル詳細

Old

このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。

Old プロファイルには、最小 TLS バージョン 1.0 が必要です。

注記

Ingress コントローラーの場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。

Intermediate

このプロファイルは、大多数のクライアントに推奨される設定です。これは、Ingress コントローラー、kubelet、およびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。

Intermediate プロファイルには、最小 TLS バージョン 1.2 が必要です。

Modern

このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性 の推奨設定に基づいています。

Modern プロファイルには、最小 TLS バージョン 1.3 が必要です。

カスタム

このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。

警告

無効な設定により問題が発生する可能性があるため、Custom プロファイルを使用する際には注意してください。

注記

事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。

5.3.1.2. Ingress コントローラーの TLS セキュリティープロファイルの設定

Ingress コントローラーの TLS セキュリティープロファイルを設定するには、IngressController カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。

Old TLS のセキュリティープロファイルを設定するサンプル IngressController CR

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

TLS セキュリティープロファイルは、Ingress コントローラーの TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。

設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile 配下の IngressController カスタムリソース (CR) と Spec.Tls Security Profile 配下の設定された TLS セキュリティープロファイルで確認できます。Custom TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。

注記

HAProxy Ingress Controller イメージは、TLS1.3Modernプロファイルをサポートしています。

また、Ingress Operator は TLS 1.0Old または Custom プロファイルを 1.1 に変換します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. openshift-ingress-operator プロジェクトの IngressController CR を編集して、TLS セキュリティープロファイルを設定します。

    $ oc edit IngressController default -n openshift-ingress-operator
  2. spec.tlsSecurityProfile フィールドを追加します。

    Custom プロファイルのサンプル IngressController CR

    apiVersion: operator.openshift.io/v1
    kind: IngressController
     ...
    spec:
      tlsSecurityProfile:
        type: Custom 1
        custom: 2
          ciphers: 3
          - ECDHE-ECDSA-CHACHA20-POLY1305
          - ECDHE-RSA-CHACHA20-POLY1305
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-GCM-SHA256
          minTLSVersion: VersionTLS11
     ...

    1
    TLS セキュリティープロファイルタイプ (OldIntermediate、または Custom) を指定します。デフォルトは Intermediate です。
    2
    選択したタイプに適切なフィールドを指定します。
    • old: {}
    • intermediate: {}
    • custom:
    3
    custom タイプには、TLS 暗号の一覧と最小許容 TLS バージョンを指定します。
  3. 変更を適用するためにファイルを保存します。

検証

  • IngressController CR にプロファイルが設定されていることを確認します。

    $ oc describe IngressController default -n openshift-ingress-operator

    出力例

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

5.3.1.3. 相互 TLS 認証の設定

spec.clientTLS 値を設定して、相互 TLS (mTLS) 認証を有効にするように Ingress コントローラーを設定できます。clientTLS 値は、クライアント証明書を検証するように Ingress コントローラーを設定します。この設定には、設定マップの参照である clientCA 値の設定が含まれます。設定マップには、クライアントの証明書を検証するために使用される PEM でエンコードされた CA 証明書バンドルが含まれます。必要に応じて、証明書サブジェクトフィルターの一覧を設定できます。

clientCA の値が X509v3 証明書失効リスト (CRL)の分散ポイントを指定する場合、Ingress Operator は CRL をダウンロードし、Ingress コントローラーがこれを認識するように設定します。有効な証明書を提供しない要求は拒否されます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. openshift-config namespace にある設定マップを作成します。

    $ oc create configmap router-ca-certs-default --from-file=ca-bundle.pem=client-ca.crt -n openshift-config
    注記

    設定マップデータキーは ca-bundle.pem で、data の値は PEM 形式の CA 証明書である必要があります。

  2. openshift-ingress-operator プロジェクトで IngressController リソースを編集します。

    $ oc edit IngressController default -n openshift-ingress-operator
  3. spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。

    フィルタリングパターンを指定する clientTLS プロファイルのサンプル IngressController CR

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        clientTLS:
          clientCertificatePolicy: Required
          clientCA:
            name: router-ca-certs-default
          allowedSubjectPatterns:
          - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"

5.3.2. Ingress コントローラーエンドポイントの公開ストラテジー

NodePortService エンドポイントの公開ストラテジー

NodePortService エンドポイントの公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress コントローラーを公開します。

この設定では、Ingress コントローラーのデプロイメントはコンテナーのネットワークを使用します。NodePortService はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理される NodePortService のノードポートフィールドへの変更が保持されます。

図5.1 NodePortService の図

OpenShift Container Platform Ingress NodePort のエンドポイント公開戦略

前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。

  • クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
  • グラフィックで 10.0.128.4 IP アドレスを接続して、クライアントがダウンしているノードに接続すると、ノードポートはクライアントを、サービスを実行している利用可能なノードに直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、1.128.4 アドレスがダウンし、代わりに別の IP アドレスを使用する必要があります。
注記

Ingress Operator は、サービスの .spec.ports[].nodePort フィールドへの更新を無視します。

デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、管理対象のサービスリソースを直接更新できます。

詳細は、NodePort についての Kubernetes サービスについてのドキュメント を参照してください。

HostNetwork エンドポイントの公開ストラテジー

HostNetwork エンドポイントの公開ストラテジーは、Ingress コントローラーがデプロイされるノードポートで Ingress コントローラーを公開します。

HostNetwork エンドポイント公開ストラテジーを持つ Ingress コントローラーには、ノードごとに単一の Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80 および 443 を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。

5.4. デフォルト Ingress コントローラーの表示

Ingress Operator は、OpenShift Container Platform の中核となる機能であり、追加の設定なしに有効にできます。

すべての新規 OpenShift Container Platform インストールには、ingresscontroller の名前付きのデフォルトがあります。これは、追加の Ingress コントローラーで補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。

手順

  • デフォルト Ingress コントローラーを表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

5.5. Ingress Operator ステータスの表示

Ingress Operator のステータスを表示し、検査することができます。

手順

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

    $ oc describe clusteroperators/ingress

5.6. Ingress コントローラーログの表示

Ingress コントローラーログを表示できます。

手順

  • Ingress コントローラーログを表示します。

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator

5.7. Ingress コントローラーステータスの表示

特定の Ingress コントローラーのステータスを表示できます。

手順

  • Ingress コントローラーのステータスを表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

5.8. Ingress コントローラーの設定

5.8.1. カスタムデフォルト証明書の設定

管理者として、 Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress コントローラーがカスタム証明書を使用するように設定できます。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
  • 証明書が以下の要件を満たしている必要があります。

    • 証明書が Ingress ドメインに対して有効化されている必要があります。
    • 証明書は拡張を使用して、subjectAltName 拡張を使用して、*.apps.ocp4.example.com などのワイルドカードドメインを指定します。
  • IngressController CR がなければなりません。デフォルトの CR を使用できます。

    $ oc --namespace openshift-ingress-operator get ingresscontrollers

    出力例

    NAME      AGE
    default   10m

注記

Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書を一覧表示します。

手順

以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提とします。tls.crt および tls.key を実際のパス名に置き換えます。さらに、 Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default を別の名前に置き換えます。

注記

このアクションにより、Ingress コントローラーはデプロイメントストラテジーを使用して再デプロイされます。

  1. tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
  2. IngressController CR を、新規証明書シークレットを参照するように更新します。

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
  3. 更新が正常に行われていることを確認します。

    $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
      --output jsonpath='{.spec.defaultCertificate}'

    出力例

    map[name:custom-certs-default]

    ヒント

    または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default

    証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress コントローラーのデプロイメントを更新します。

5.8.2. Ingress コントローラーのスケーリング

Ingress コントローラーは、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc コマンドは、IngressController リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。

注記

スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。

手順

  1. デフォルト IngressControllerの現在の利用可能なレプリカ数を表示します。

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    出力例

    2

  2. oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

    出力例

    ingresscontroller.operator.openshift.io/default patched

  3. デフォルトの IngressController が指定したレプリカ数にスケーリングされていることを確認します。

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

    出力例

    3

    ヒント

    または、以下の YAML を適用して Ingress コントローラーを 3 つのレプリカにスケーリングすることもできます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 3               1
    1
    異なる数のレプリカが必要な場合は replicas 値を変更します。

5.8.3. Ingress アクセスロギングの設定

アクセスログを有効にするように Ingress コントローラーを設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。

コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress コントローラーで問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。

アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。

前提条件

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

手順

サイドカーへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container spec.logging.access.destination.type を指定する必要があります。以下の例は、コンテナー Container の宛先に対してログ記録する Ingress コントローラー定義です。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Container
  • Ingress コントローラーをサイドカーに対してログを記録するように設定すると、Operator は Ingress コントローラー Pod 内に logs という名前のコンテナーを作成します。

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs

    出力例

    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"

Syslog エンドポイントへの Ingress アクセスロギングを設定します。

  • Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.typeSyslog を指定する必要があります。宛先タイプが Syslog の場合、spec.logging.access.destination.syslog.endpoint を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility を使用してファシリティーを指定できます。以下の例は、Syslog 宛先に対してログを記録する Ingress コントローラーの定義です。

    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
    注記

    syslog 宛先ポートは UDP である必要があります。

特定のログ形式で Ingress アクセスロギングを設定します。

  • spec.logging.access.httpLogFormat を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 の syslog エンドポイントに対してログを記録する Ingress コントローラーの定義です。

    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'

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

5.8.4. Ingress コントローラースレッド数の設定

クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress コントローラーにパッチを適用して、スレッドの数を増やすことができます。

前提条件

  • 以下では、Ingress コントローラーがすでに作成されていることを前提とします。

手順

  • Ingress コントローラーを更新して、スレッド数を増やします。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
    注記

    大量のリソースを実行できるノードがある場合、spec.nodePlacement.nodeSelector を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount を随時高い値に設定します。

5.8.5. Ingress コントローラーのシャード化

トラフィックがクラスターに送信される主要なメカニズムとして、Ingress コントローラーまたはルーターへの要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。

  • Ingress コントローラーまたはルーターを複数のルートに分散し、変更に対する応答を加速します。
  • 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
  • 特定の Ingress コントローラーに異なるポリシーを定義することを許可します。
  • 特定のルートのみが追加機能を使用することを許可します。
  • たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。

Ingress コントローラーは、ルートラベルまたは namespace ラベルのいずれかをシャード化の方法として使用できます。

5.8.5.1. ルートラベルを使用した Ingress コントローラーのシャード化の設定

ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
  2. Ingress コントローラーの router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress コントローラーは、type: sharded というラベルのある namespace のルートを選択します。

5.8.5.2. namespace ラベルを使用した Ingress コントローラーのシャード化の設定

namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。

警告

Keepalived Ingress VIP をデプロイする場合は、endpoint Publishing StrategyパラメーターにHost Networkの値が割り当てられた、デフォルト以外の Ingress Controller をデプロイしないでください。デプロイしてしまうと、問題が発生する可能性があります。endpoint Publishing StrategyHost Networkではなく、Node Portという値を使用してください。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net>
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

  2. Ingress コントローラーの router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress コントローラーは、type: sharded というラベルのある namespace セレクターによって選択される namespace のルートを選択します。

5.8.6. 内部ロードバランサーを使用するように Ingress コントローラーを設定する

クラウドプラットフォームで Ingress コントローラーを作成する場合、Ingress コントローラーはデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress コントローラーを作成できます。

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。

重要

IngressController オブジェクトのスコープを変更する必要がある場合、IngressController オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更することはできません。

図5.2 ロードバランサーの図

OpenShift Container Platform Ingress Load Balancer Service のエンドポイント公開戦略

前述の図では、OpenShift Container Platform Ingress LoadBalancerService エンドポイントの公開戦略に関する以下のような概念を示しています。

  • 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
  • ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
  • 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細については、Kubernetes サービスドキュメント を参照してください。

前提条件

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

手順

  1. 以下の例のように、<name>-ingress-controller.yaml という名前のファイルに IngressController カスタムリソース (CR) を作成します。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> 1
    spec:
      domain: <domain> 2
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal 3
    1
    <name>IngressController オブジェクトの名前に置き換えます。
    2
    コントローラーによって公開されるアプリケーションのドメインを指定します。
    3
    内部ロードバランサーを使用するために Internal の値を指定します。
  2. 以下のコマンドを実行して、直前の手順で定義された Ingress コントローラーを作成します。

    $ oc create -f <name>-ingress-controller.yaml 1
    1
    <name>IngressController オブジェクトの名前に置き換えます。
  3. オプション: 以下のコマンドを実行して Ingress コントローラーが作成されていることを確認します。

    $ oc --all-namespaces=true get ingresscontrollers

5.8.7. GCP での Ingress コントローラーのグローバルアクセスの設定

内部ロードバランサーで GCP で作成された Ingress コントローラーは、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。

詳細情報は、GCP ドキュメントのグローバルアクセスについて参照してください。

前提条件

  • OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
  • 内部ロードバランサーを使用するように Ingress コントローラーを設定している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. グローバルアクセスを許可するように Ingress コントローラーリソースを設定します。

    注記

    Ingress コントローラーを作成し、グローバルアクセスのオプションを指定することもできます。

    1. Ingress コントローラーリソースを設定します。

      $ oc -n openshift-ingress-operator edit ingresscontroller/default
    2. YAML ファイルを編集します。

      サンプル clientAccess 設定を Global に設定します。

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 1
                type: GCP
              scope: Internal
            type: LoadBalancerService

      1
      gcp.clientAccessGlobal に設定します。
    3. 変更を適用するためにファイルを保存します。
  2. 以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。

    $ oc -n openshift-ingress edit svc/router-default -o yaml

    この出力では、グローバルアクセスがアノテーション networking.gke.io/internal-load-balancer-allow-global-access で GCP について有効にされていることを示しています。

5.8.8. クラスターを内部に配置するようにのデフォルト Ingress コントローラーを設定する

削除や再作成を実行して、クラスターを内部に配置するように default Ingress コントローラーを設定できます。

警告

クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。

重要

IngressController オブジェクトのスコープを変更する必要がある場合、IngressController オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更することはできません。

前提条件

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

手順

  1. 削除や再作成を実行して、クラスターを内部に配置するように default Ingress コントローラーを設定します。

    $ 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

5.8.9. ルートの受付ポリシーの設定

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。

警告

複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。

前提条件

  • クラスター管理者の権限。

手順

  • 以下のコマンドを使用して、ingresscontroller リソース変数の .spec.routeAdmission フィールドを編集します。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

    イメージコントローラー設定例

    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...

    ヒント

    または、以下の YAML を適用してルートの受付ポリシーを設定できます。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed

5.8.10. ワイルドカードルートの使用

HAProxy Ingress コントローラーにはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress コントローラーの ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。

Ingress コントローラーのデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。

手順

  1. ワイルドカードポリシーを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController
    2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

5.8.11. X-Forwarded ヘッダーの使用

Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法についてのポリシーを指定するように HAProxy Ingress コントローラーを設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress コントローラーの ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。

手順

  1. Ingress コントローラー用に HTTPHeaders フィールドを設定します。

    1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController
    2. spec の下で、HTTPHeaders ポリシーフィールドを AppendReplaceIfNone、または Never に設定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append
使用例

クラスター管理者として、以下を実行できます

  • Ingress コントローラーに転送する前に、X-Forwarded-For ヘッダーを各リクエストに挿入する外部プロキシーを設定します。

    ヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、never ポリシーを指定します。これにより、Ingress コントローラーはヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。

  • 外部プロキシーが外部クラスター要求を設定する X-Forwarded-For ヘッダーを変更せずに渡すように Ingress コントローラーを設定します。

    外部プロキシーを通過しない内部クラスター要求に X-Forwarded-For ヘッダーを設定するように Ingress コントローラーを設定するには、if-none ポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress コントローラーはこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress コントローラーはヘッダーを追加します。

アプリケーション開発者として、以下を実行できます

  • X-Forwarded-For ヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。

    他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、アプリケーションの Route に アノテーション haproxy.router.openshift.io/set-forwarded-headers: if-none または haproxy.router.openshift.io/set-forwarded-headers: never を追加します。

    注記

    Ingress コントローラーのグローバルに設定された値とは別に、haproxy.router.openshift.io/set-forwarded-headers アノテーションをルートごとに設定できます。

5.8.12. HTTP/2 Ingress 接続の有効化

HAProxy で透過的なエンドツーエンド HTTP/2 接続を有効にすることができます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。

個別の Ingress コントローラーまたはクラスター全体について、HTTP/2 接続を有効にすることができます。

クライアントから HAProxy への接続について HTTP/2 の使用を有効にするために、ルートはカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。

HAProxy からアプリケーション Pod への接続は、re-encrypt ルートのみに HTTP/2 を使用でき、edge termination ルートまたは非セキュアなルートには使用しません。この制限は、HAProxy が TLS 拡張である Application-Level Protocol Negotiation (ALPN) を使用してバックエンドで HTTP/2 の使用をネゴシエートするためにあります。そのため、エンドツーエンドの HTTP/2 はパススルーおよび re-encrypt 使用できますが、非セキュアなルートまたは edge termination ルートでは使用できません。

重要

パススルー以外のルートの場合、Ingress コントローラーはクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。つまり、クライアントが Ingress コントローラーに接続して HTTP/1.1 をネゴシエートし、Ingress コントローラーは次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress コントローラーは WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。

手順

単一 Ingress コントローラーで HTTP/2 を有効にします。

  • Ingress コントローラーで HTTP/2 を有効にするには、oc annotate コマンドを入力します。

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

    <ingresscontroller_name> をアノテーションを付ける Ingress コントローラーの名前に置き換えます。

クラスター全体で HTTP/2 を有効にします。

  • クラスター全体で HTTP/2 を有効にするには、oc annotate コマンドを入力します。

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
    ヒント

    または、以下の YAML を適用してアノテーションを追加できます。

    apiVersion: config.openshift.io/v1
    kind: Ingress
    metadata:
      name: cluster
      annotations:
        ingress.operator.openshift.io/default-enable-http2: "true"

5.8.13. Ingress コントローラーの PROXY プロトコルの設定

クラスター管理者は、Ingress コントローラーが HostNetwork または NodePortService エンドポイントの公開ストラテジータイプのいずれかを使用する際に PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress コントローラーが受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress コントローラーが受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。

この機能は、クラウドデプロイメントではサポートされていません。この制限は、OpenShift Container Platform がクラウドプラットフォームで実行される場合、IngressController はサービスロードバランサーを使用するように指定し、Ingress Operator はロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためにあります。

警告

接続の障害を防ぐには、Ingress コントローラーとロードバランサーの両方を PROXY プロトコルを使用するように設定します。

前提条件

  • Ingress コントローラーを作成している。

手順

  1. Ingress コントローラーリソースを編集します。

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
  2. PROXY 設定を設定します。

    • Ingress コントローラーが hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

      PROXYへの hostNetwork の設定例

        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: HostNetwork

    • Ingress コントローラーが NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

      PROXYへのサンプル nodePort 設定

        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService

5.8.14. appsDomain オプションを使用した代替クラスタードメインの指定

クラスター管理者は、appsDomain フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain フィールドは、ドメインフィールドで指定されるデフォルトの代わりに使用する OpenShift Container Platform のオプションの ドメイン です。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。

たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。

前提条件

  • OpenShift Container Platform クラスターをデプロイしていること。
  • oc コマンドラインインターフェースをインストールしている。

手順

  1. ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。

    1. Ingress クラスター リソースを編集します。

      $ oc edit ingresses.config/cluster -o yaml
    2. YAML ファイルを編集します。

      test.example.comへのapps Domainの設定例

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            1
        appsDomain: <test.example.com>      2

      1
      デフォルトドメイン
      2
      オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトのプレフィックスであるappsの代わりに、testのような別のプレフィックスを使用できます。
  2. ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。

    注記

    ルートを公開する前に openshift-apiserver がローリングアップデートを終了するのを待機します。

    1. ルートを公開します。

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      出力例:

      $ 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

5.8.15. HTTP ヘッダーケースの変換

HAProxy 2.2 では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.comhost: xyz.com に変更します。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。

重要

OpenShift Container Platform 4.9 には HAProxy 2.2 が含まれるため、アップグレードする前に spec.httpHeaders.headerNameCaseAdjustments を使用して必要な設定を追加するようにしてください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

クラスター管理者は、oc patch コマンドを入力するか、または Ingress コントローラー YAML ファイルの HeaderNameCaseAdjustments フィールドを設定して HTTP ヘッダーのケースを変換できます。

  • oc patch コマンドを入力して、HTTP ヘッダーの大文字化を指定します。

    1. oc patch コマンドを入力して、HTTP host ヘッダーを Host に変更します。

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
    2. アプリケーションのルートにアノテーションを付けます。

      $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true

      次に、Ingress コントローラーは host 要求ヘッダーを指定どおりに調整します。

  • Ingress コントローラーの YAML ファイルを設定し、 HeaderNameCaseAdjustments フィールドを使用して調整を指定します。

    1. 以下のサンプル Ingress コントローラー YAML は、適切にアノテーションが付けられたルートへの HTTP/1 要求について host ヘッダーを Host に調整します。

      Ingress コントローラー YAML のサンプル

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host

    2. 以下のサンプルルートでは、haproxy.router.openshift.io/h1-adjust-case アノテーションを使用して HTTP 応答ヘッダー名のケース調整を有効にします。

      ルート YAML のサンプル

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true 1
        name: my-application
        namespace: my-application
      spec:
        to:
          kind: Service
          name: my-application

      1
      haproxy.router.openshift.io/h1-adjust-case を true に設定します。

5.8.16. HAProxy エラーコードの応答ページのカスタマイズ

クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。

カスタムエラーコードの応答ページは設定マップに指定し、Ingress コントローラーにパッチを適用されます。設定マップキーには、error-page-503.httperror-page-404.http の 2 つの利用可能なファイル名があります。

カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。

デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTPエラーコード応答をカスタマイズするための設定マップが提供されておらず、カスタムHTTPエラーコード応答ページを使用している場合、ルーターはデフォルトの404または503エラーコード応答ページを提供します。

注記

カスタマイズ用のテンプレートとして OpenShift Container Platform のデフォルトの 503 エラーコードページを使用する場合、ファイルのヘッダーには CRLF 行の終了よりも多くのエディターが必要になります。

手順

  1. openshift-configmy-custom-error-code-pages という名前の設定マップを作成します。

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
    --from-file=error-page-503.http \
    --from-file=error-page-404.http
    重要

    カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、設定マップを削除するか、または修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。

  2. Ingress コントローラーにパッチを適用し、名前を指定して my-custom-error-code-pages 設定マップを参照します。

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

    Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages 設定マップをコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って設定マップに名前を付けます。

  3. コピーを表示します。

    $ oc get cm default-errorpages -n openshift-ingress

    出力例

    NAME                       DATA   AGE
    default-errorpages         2      25s  1

    1
    default の Ingress Controller カスタムリソース(CR)にパッチが適用されているため、設定マップ名の例は default-errorpages です。
  4. カスタムエラー応答ページを含む構成マップがルーターボリュームにマウントされることを確認します。構成マップキーは、カスタム HTTP エラーコード応答を持つファイル名です。

    • 503 カスタム HTTP カスタムエラーコード応答の場合:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
    • 404 カスタム HTTP カスタムエラーコード応答の場合:

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http

検証

カスタムエラーコード HTTP 応答を確認します。

  1. テストプロジェクトおよびアプリケーションを作成します。

     $ oc new-project test-ingress
    $ oc new-app django-psql-example
  2. 503 カスタム http エラーコード応答の場合:

    1. アプリケーションのすべての Pod を停止します。
    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>
  3. 404 カスタム http エラーコード応答の場合:

    1. 存在しないルートまたは正しくないルートにアクセスします。
    2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>
  4. errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

5.9. 関連情報

第6章 エンドポイントへの接続の確認

Cluster Network Operator (CNO) は、クラスター内のリソース間の接続ヘルスチェックを実行するコントローラーである接続性チェックコントローラーを実行します。ヘルスチェックの結果を確認して、調査している問題が原因で生じる接続の問題を診断したり、ネットワーク接続を削除したりできます。

6.1. 実行する接続ヘルスチェック

クラスターリソースにアクセスできることを確認するには、以下のクラスター API サービスのそれぞれに対して TCP 接続が行われます。

  • Kubernetes API サーバーサービス
  • Kubernetes API サーバーエンドポイント
  • OpenShift API サーバーサービス
  • OpenShift API サーバーエンドポイント
  • ロードバランサー

サービスおよびサービスエンドポイントがクラスター内のすべてのノードで到達可能であることを確認するには、以下の各ターゲットに対して TCP 接続が行われます。

  • ヘルスチェックターゲットサービス
  • ヘルスチェックターゲットエンドポイント

6.2. 接続ヘルスチェックの実装

接続チェックコントローラーは、クラスター内の接続検証チェックをオーケストレーションします。接続テストの結果は、openshift-network-diagnostics namespace の PodNetworkConnectivity オブジェクトに保存されます。接続テストは、1 分ごとに並行して実行されます。

Cluster Network Operator (CNO) は、接続性ヘルスチェックを送受信するためにいくつかのリソースをクラスターにデプロイします。

ヘルスチェックのソース
このプログラムは、Deployment オブジェクトで管理される単一の Pod レプリカセットにデプロイします。このプログラムは PodNetworkConnectivity オブジェクトを消費し、各オブジェクトで指定される spec.targetEndpoint に接続されます。
ヘルスチェックのターゲット
クラスターのすべてのノードにデーモンセットの一部としてデプロイされた Pod。Pod はインバウンドのヘルスチェックをリッスンします。すべてのノードにこの Pod が存在すると、各ノードへの接続をテストすることができます。

6.3. PodNetworkConnectivityCheck オブジェクトフィールド

PodNetworkConnectivityCheck オブジェクトフィールドについては、以下の表で説明されています。

表6.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 配列内のオブジェクトのフィールドについて説明しています。

表6.2 status.conditions

フィールドタイプ詳細

lastTransitionTime

string

接続の条件がある状態から別の状態に移行した時間。

message

string

人が判読できる形式の最後の移行についての詳細。

reason

string

マシンの読み取り可能な形式での移行の最後のステータス。

status

string

状態のテータス。

type

string

状態のタイプ。

以下の表は、status.conditions 配列内のオブジェクトのフィールドについて説明しています。

表6.3 status.outages

フィールドタイプ詳細

end

string

接続の障害が解決された時点からのタイムスタンプ。

endLogs

array

接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。

message

string

人が判読できる形式の停止について詳細情報の要約。

start

string

接続の障害が最初に検知された時点からのタイムスタンプ。

startLogs

array

元の障害を含む接続ログのエントリー。

接続ログフィールド

接続ログエントリーのフィールドの説明は以下の表で説明されています。オブジェクトは以下のフィールドで使用されます。

  • status.failures[]
  • status.successes[]
  • status.outages[].startLogs[]
  • status.outages[].endLogs[]

表6.4 接続ログオブジェクト

フィールドタイプ詳細

latency

string

アクションの期間を記録します。

message

string

ステータスを人が判読できる形式で提供します。

reason

string

ステータスの理由をマシンが判読できる形式で提供します。値は TCPConnectTCPConnectErrorDNSResolveDNSError のいずれかになります。

success

boolean

ログエントリーが成功または失敗であるかを示します。

time

string

接続チェックの開始時間。

6.4. エンドポイントのネットワーク接続の確認

クラスター管理者は、API サーバー、ロードバランサー、サービス、または Pod などのエンドポイントの接続を確認できます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセス。

手順

  1. 現在の PodNetworkConnectivityCheck オブジェクトを一覧表示するには、以下のコマンドを入力します。

    $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

    出力例

    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

  2. 接続テストログを表示します。

    1. 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。
    2. オブジェクトを表示するには、以下のコマンドを入力します。

      $ oc get podnetworkconnectivitycheck <name> \
        -n openshift-network-diagnostics -o yaml

      ここで、<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"

第7章 ノードポートサービス範囲の設定

クラスター管理者は、利用可能なノードのポート範囲を拡張できます。クラスターで多数のノードポートが使用される場合、利用可能なポートの数を増やす必要がある場合があります。

デフォルトのポート範囲は 30000-32767 です。最初にデフォルト範囲を超えて拡張した場合でも、ポート範囲を縮小することはできません。

7.1. 前提条件

  • クラスターインフラストラクチャーは、拡張された範囲内で指定するポートへのアクセスを許可する必要があります。たとえば、ノードのポート範囲を 30000-32900 に拡張する場合、ファイアウォールまたはパケットフィルタリングの設定によりこれに含まれるポート範囲 32768-32900 を許可する必要があります。

7.2. ノードのポート範囲の拡張

クラスターのノードポート範囲を拡張できます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。

手順

  1. ノードのポート範囲を拡張するには、以下のコマンドを入力します。<port> を、新規の範囲内で最大のポート番号に置き換えます。

    $ oc patch network.config.openshift.io cluster --type=merge -p \
      '{
        "spec":
          { "serviceNodePortRange": "30000-<port>" }
      }'
    ヒント

    または、以下の YAML を適用してノードのポート範囲を更新することもできます。

    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNodePortRange: "30000-<port>"

    出力例

    network.config.openshift.io/cluster patched

  2. 設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。

    $ oc get configmaps -n openshift-kube-apiserver config \
      -o jsonpath="{.data['config\.yaml']}" | \
      grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

    出力例

    "service-node-port-range":["30000-33000"]

7.3. 関連情報

第8章 IP フェイルオーバーの設定

このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの IP フェイルオーバーの設定について説明します。

IP フェイルオーバーは、ノードセットの仮想 IP (VIP) アドレスのプールを管理します。セットのすべての VIP はセットから選択されるノードによって提供されます。VIP は単一ノードが利用可能である限り提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべての VIP がそのノードに配置されます。

注記

VIP はクラスター外からルーティングできる必要があります。

IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0 に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。

IP フェイルオーバーは Keepalived を使用して、一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。Keepalived は Virtual Router Redundancy Protocol (VRRP) を使用して、(一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。

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 を使用することができます。

サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、IP フェイルオーバーのモニタリングポートはサービスポートに設定されます。ノードポートを使用する場合、ポートはクラスター内のすべてのノードで開かれ、サービスは、現在 VIP にサービスを提供しているあらゆるノードからのトラフィックの負荷を分散します。この場合、IP フェイルオーバーのモニタリングポートはサービス定義で NodePort に設定されます。

重要

NodePort のセットアップは特権付きの操作で実行されます。

重要

サービス VIP の可用性が高い場合でも、パフォーマンスに影響が出る可能性があります。Keepalived は、各 VIP が設定内の一部のノードによってサービスされることを確認し、他のノードに VIP がない場合でも、複数の VIP が同じノードに配置される可能性があります。IP フェイルオーバーによって複数の VIP が同じノードに配置されると、VIP のセット全体で外部から負荷分散される戦略が妨げられる可能性があります。

ingressIP を使用する場合は、IP フェイルオーバーを ingressIP 範囲と同じ VIP 範囲を持つように設定できます。また、モニタリングポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。すべてのユーザーが ingressIP でサービスをセットアップし、これを高い可用性のあるサービスにすることができます。

重要

クラスター内の VIP の最大数は 254 です。

8.1. IP フェイルオーバーの環境変数

以下の表は、IP フェイルオーバーの設定に使用される変数を示しています。

表8.1 IP フェイルオーバーの環境変数

変数名デフォルト詳細

OPENSHIFT_HA_MONITOR_PORT

80

IP フェイルオーバー Pod は、各仮想 IP (VIP) のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。

OPENSHIFT_HA_NETWORK_INTERFACE

 

IP フェイルオーバーが Virtual Router Redundancy Protocol (VRRP) トラフィックの送信に使用するインターフェース名。デフォルト値は eth0 です。

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 ストラテジーでは、マスターを優先度の低いホストから優先度の高いホストに移動しません。

8.2. IP フェイルオーバーの設定

クラスター管理者は、クラスター全体に IP フェイルオーバーを設定することも、ラベルセレクターの定義に基づいてノードのサブセットに IP フェイルオーバーを設定することもできます。また、複数の IP フェイルオーバーのデプロイメント設定をクラスター内に設定することもでき、それぞれの設定をクラスター内で相互に切り離すことができます。

IP フェイルオーバーのデプロイメント設定により、フェイルオーバー Pod は、制約または使用されるラベルに一致する各ノードで確実に実行されます。

この Pod は Keepalived を実行します。これは、最初のノードがサービスまたはエンドポイントに到達できない場合に、エンドポイントを監視し、Virtual Router Redundancy Protocol (VRRP) を使用して仮想 IP (VIP) を別のノードにフェイルオーバーできます。

実稼働環境で使用する場合は、少なくとも 2 つのノードを選択し、選択したノードの数に相当するreplicas を設定する selector を設定します。

前提条件

  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。
  • プルシークレットを作成している。

手順

  1. IP フェイルオーバーのサービスアカウントを作成します。

    $ oc create sa ipfailover
  2. hostNetwork の SCC (Security Context Constraints) を更新します。

    $ oc adm policy add-scc-to-user privileged -z ipfailover
    $ oc adm policy add-scc-to-user hostnetwork -z ipfailover
  3. デプロイメント YAML ファイルを作成して IP フェイルオーバーを設定します。

    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: quay.io/openshift/origin-keepalived-ipfailover
            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

    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
    デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。

8.3. 仮想 IP アドレスについて

Keepalived は一連の仮想 IP アドレス (VIP) を管理します。管理者はこれらすべてのアドレスについて以下の点を確認する必要があります。

  • 仮想 IP アドレスは設定されたホストでクラスター外からアクセスできる。
  • 仮想 IP アドレスはクラスター内でこれ以外の目的で使用されていない。

各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してどのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視 ポートでリッスンしている、またはチェックが無効にされている必要があります。

注記

セット内の各 VIP は最終的に別のノードによって提供される可能性があります。

8.4. check スクリプトおよび notify スクリプトの設定

Keepalived は、オプションのユーザー指定の check スクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで web サーバーをテストします。

チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0 の場合は抑制されます。

各 IP フェイルオーバー Pod は、Pod が実行されているノードで 1 つ以上の仮想 IP (VIP) を管理する Keepalived デーモンを管理します。Keepalived デーモンは、ノードの各 VIP の状態を維持します。特定のノード上の特定の VIP は、masterbackup、または fault 状態にある可能性があります。

master 状態にあるノードでその VIP の check スクリプトが失敗すると、そのノードの VIP は fault 状態になり、再ネゴシエーションがトリガーされます。再ネゴシエーションの中に fault 状態にないノード上のすべての VIP は、どのノードが VIP を引き継ぐかを決定することに参加します。最終的に VIP は一部のノードで master の状態に入り、VIP は他のノードで backup 状態のままになります。

backup 状態の VIP を持つノードに障害が発生すると、そのノードの VIP は fault 状態になります。fault 状態のノード上の VIP の check スクリプトが再度パスすると、そのノードの VIP はfault 状態を終了し、master 状態に入るためにネゴシエートします。次に、そのノードの VIP は、master 状態または backup 状態のいずれかになります。

クラスター管理者は、オプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。Keepalived は以下の 3 つのパラメーターをこのスクリプトに渡します。

  • $1 - group または instance
  • $2: group または instance の名前です。
  • $3: 新規の状態: masterbackup、または fault

check および notify スクリプトは、IP フェイルオーバー Pod で実行され、ホストファイルシステムではなく Pod ファイルシステムを使用します。ただし、IP フェイルオーバー Pod はホストファイルシステムが /hosts マウントパスで利用可能にします。check または notify スクリプトを設定する場合は、スクリプトへの完全パスを指定する必要があります。スクリプトを提供する方法として、設定マップの使用が推奨されます。

check および notify スクリプトの完全パス名は、Keepalived 設定ファイル (_/etc/keepalived/keepalived.conf) に追加されます。このファイルは、Keepalived が起動するたびにロードされます。スクリプトは、以下のように設定マップを使用して Pod に追加できます。

前提条件

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

手順

  1. 必要なスクリプトを作成し、これを保持する設定マップを作成します。スクリプトには入力引数は指定されず、OK の場合は 0 を、fail の場合は 1 を返す必要があります。

    check スクリプト mycheckscript.sh:

    #!/bin/bash
        # Whatever tests are needed
        # E.g., send request and verify response
    exit 0
  2. 設定マップを作成します。

    $ oc create configmap mycustomcheck --from-file=mycheckscript.sh
  3. スクリプトを Pod に追加します。マウントされた設定マップファイルの defaultMode は、oc コマンドを使用して、またはデプロイメント設定を編集して実行できる必要があります。通常は、0755493 (10 進数) の値が使用されます。

    $ oc set env deploy/ipfailover-keepalived \
        OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
    $ oc set volume deploy/ipfailover-keepalived --add --overwrite \
        --name=config-volume \
        --mount-path=/etc/keepalive \
        --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
    注記

    oc set env コマンドは空白を区別します。= 記号の両側に空白を入れることはできません。

    ヒント

    または、ipfailover-keepalived デプロイメント設定を編集することもできます。

    $ oc edit deploy ipfailover-keepalived
        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
    ...
    1
    spec.container.env フィールドで、マウントされたスクリプトファイルを参照する OPENSHIFT_HA_CHECK_SCRIPT 環境変数を追加します。
    2
    spec.container.volumeMounts フィールドを追加してマウントポイントを作成します。
    3
    新規の spec.volumes フィールドを追加して設定マップに言及します。
    4
    これはファイルの実行パーミッションを設定します。読み取られる場合は 10 進数 (493) で表示されます。

    変更を保存し、エディターを終了します。これにより ipfailover-keepalived が再起動されます。

8.5. VRRP プリエンプションの設定

ノードの仮想 IP (VIP) が check スクリプトを渡すことで fault 状態を終了すると、ノードの VIP は、現在 master 状態にあるノードの VIP よりも優先度が低い場合は backup 状態になります。ただし、fault 状態を終了するノードの VIP の優先度が高い場合は、プリエンプションストラテジーによってクラスター内でのその役割が決定されます。

nopreempt ストラテジーは master をホスト上の優先度の低いホストからホスト上の優先度の高い VIP に移動しません。デフォルトの preempt_delay 300 の場合、Keepalived は指定された 300 秒の間待機し、master をホスト上の優先度の高い VIP に移動します。

前提条件

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

手順

  • プリエンプションを指定するには、oc edit deploy ipfailover-keepalived を入力し、ルーターのデプロイメント設定を編集します。

    $ oc edit deploy ipfailover-keepalived
    ...
        spec:
          containers:
          - env:
            - name: OPENSHIFT_HA_PREEMPTION  1
              value: preempt_delay 300
    ...
    1
    OPENSHIFT_HA_PREEMPTION の値を設定します。
    • preempt_delay 300: Keepalived は、指定された 300 秒の間待機し、master をホスト上の優先度の高い VIP に移動します。これはデフォルト値です。
    • nopreempt: master をホスト上の優先度の低い VIP からホスト上の優先度の高い VIP に移動しません。

8.6. VRRP ID オフセットについて

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 範囲が重複しないようにする必要があります。

8.7. 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"
    ...

    1
    たとえば、7 つの VIP のある環境で OPENSHIFT_HA_VIP_GROUPS3 に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。
注記

OPENSHIFT_HA_VIP_GROUPS で設定されたグループの数が、フェイルオーバーに設定された IP アドレスの数より少ない場合、グループには複数の IP アドレスが含まれ、すべてのアドレスが 1 つのユニットとして移動します。

8.8. ingressIP の高可用性

クラウド以外のクラスターでは、IP フェイルオーバーおよびサービスへの ingressIP を組み合わせることができます。結果として、ingressIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。

この方法では、まず ingressIPNetworkCIDR 範囲を指定し、次に ipfailover 設定を作成する際に同じ範囲を使用します。

IP フェイルオーバーはクラスター全体に対して最大 255 の VIP をサポートできるため、ingressIPNetworkCIDR/24 以下に設定する必要があります。

8.9. IP フェイルオーバーの削除

IP フェイルオーバーが最初に設定されている場合、クラスターのワーカーノードは、Keepalived 用に 224.0.0.18 のマルチキャストパケットを明示的に許可する iptables ルールを使用して変更されます。ノードが変更されるため、IP フェイルオーバーを削除するには、ジョブを実行して iptables ルールを削除し、Keepalived が使用する仮想 IP アドレスを削除する必要があります。

手順

  1. オプション: 設定マップとして保存されるチェックおよび通知スクリプトを特定し、削除します。

    1. IP フェイルオーバーの Pod が設定マップをボリュームとして使用するかどうかを決定します。

      $ 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}"

      出力例

      Namespace: default
      Pod:       keepalived-worker-59df45db9c-2x9mn
      Volumes that use config maps:
        volume:    config-volume
        configMap: mycustomcheck

    2. 前述の手順でボリュームとして使用される設定マップの名前が提供されている場合は、設定マップを削除します。

      $ oc delete configmap <configmap_name>
  2. IP フェイルオーバーの既存デプロイメントを特定します。

    $ oc get deployment -l ipfailover

    出力例

    NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
    default     ipfailover   2/2     2            2           105d

  3. デプロイメントを削除します。

    $ oc delete deployment <ipfailover_deployment_name>
  4. ipfailover サービスアカウントを削除します。

    $ oc delete sa ipfailover
  5. IP フェイルオーバーの設定時に追加された IP テーブルルールを削除するジョブを実行します。

    1. 以下の例のような内容で 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: quay.io/openshift/origin-keepalived-ipfailover:4.9
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector:
              kubernetes.io/hostname: <host_name>  1
            restartPolicy: Never
      1
      IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。
    2. ジョブを実行します。

      $ oc create -f remove-ipfailover-job.yaml

      出力例

      job.batch/remove-ipfailover-2h8dm created

検証

  • ジョブが IP フェイルオーバーの初期設定を削除していることを確認します。

    $ oc logs job/remove-ipfailover-2h8dm

    出力例

    remove-failover.sh: OpenShift IP Failover service terminating.
      - Removing ip_vs module ...
      - Cleaning up ...
      - Releasing VIPs  (interface eth0) ...

第9章 ベアメタルクラスターでの SCTP (Stream Control Transmission Protocol) の使用

クラスター管理者は、クラスターで SCTP (Stream Control Transmission Protocol) を使用できます。

9.1. OpenShift Container Platform での SCTP (Stream Control Transmission Protocol) のサポート

クラスター管理者は、クラスターのホストで SCTP を有効にできます。Red Hat Enterprise Linux CoreOS (RHCOS) で、SCTP モジュールはデフォルトで無効にされています。

SCTP は、IP ネットワークの上部で実行される信頼できるメッセージベースのプロトコルです。

これを有効にすると、SCTP を Pod、サービス、およびネットワークポリシーでプロトコルとして使用できます。Service オブジェクトは、type パラメーターを ClusterIP または NodePort のいずれかの値に設定して定義する必要があります。

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

以下の例では、サービスは SCTP を使用するように設定されています。

apiVersion: v1
kind: Service
metadata:
  namespace: project1
  name: sctpserver
spec:
...
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30100
      targetPort: 30100
  type: ClusterIP

以下の例では、NetworkPolicy オブジェクトは、特定のラベルの付いた Pod からポート 80 の SCTP ネットワークトラフィックに適用するように設定されます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-sctp-on-http
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - ports:
    - protocol: SCTP
      port: 80

9.2. SCTP (Stream Control Transmission Protocol) の有効化

クラスター管理者は、クラスターのワーカーノードでブラックリストに指定した SCTP カーネルモジュールを読み込み、有効にできます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセス。

手順

  1. 以下の 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
  2. MachineConfig オブジェクトを作成するには、以下のコマンドを入力します。

    $ oc create -f load-sctp-module.yaml
  3. オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが Ready に移行すると、設定の更新が適用されます。

    $ oc get nodes

9.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認

SCTP がクラスターで機能することを確認するには、SCTP トラフィックをリッスンするアプリケーションで Pod を作成し、これをサービスに関連付け、公開されたサービスに接続します。

前提条件

  • クラスターからインターネットにアクセスし、nc パッケージをインストールすること。
  • OpenShift CLI (oc) をインストールします。
  • cluster-admin ロールを持つユーザーとしてのクラスターへのアクセス。

手順

  1. SCTP リスナーを起動する Pod を作成します。

    1. 以下の YAML で Pod を定義する sctp-server.yaml という名前のファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpserver
        labels:
          app: sctpserver
      spec:
        containers:
          - name: sctpserver
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
            ports:
              - containerPort: 30102
                name: sctpserver
                protocol: SCTP
    2. 以下のコマンドを入力して Pod を作成します。

      $ oc create -f sctp-server.yaml
  2. SCTP リスナー Pod のサービスを作成します。

    1. 以下の 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
    2. サービスを作成するには、以下のコマンドを入力します。

      $ oc create -f sctp-service.yaml
  3. SCTP クライアントの Pod を作成します。

    1. 以下の YAML で sctp-client.yaml という名前のファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpclient
        labels:
          app: sctpclient
      spec:
        containers:
          - name: sctpclient
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
    2. Pod オブジェクトを作成するには、以下のコマンドを入力します。

      $ oc apply -f sctp-client.yaml
  4. サーバーで SCTP リスナーを実行します。

    1. サーバー Pod に接続するには、以下のコマンドを入力します。

      $ oc rsh sctpserver
    2. SCTP リスナーを起動するには、以下のコマンドを入力します。

      $ nc -l 30102 --sctp
  5. サーバーの SCTP リスナーに接続します。

    1. ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
    2. sctpservice サービスの IP アドレスを取得します。以下のコマンドを入力します。

      $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
    3. クライアント Pod に接続するには、以下のコマンドを入力します。

      $ oc rsh sctpclient
    4. SCTP クライアントを起動するには、以下のコマンドを入力します。<cluster_IP>sctpservice サービスのクラスター IP アドレスに置き換えます。

      # nc <cluster_IP> 30102 --sctp

第10章 PTP ハードウェアの使用

重要

境界クロックとして設定した PTP (Precision Time Protocol) ハードウェアは、テクノロジープレビュー機能としてのみ提供されています。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

10.1. PTP ハードウェアについて

OpenShift Container Platform では、ノード上で PTP ハードウェアを使用できます。linuxptp サービスは、PTP 対応ハードウェアを搭載したノードで設定できます。

注記

PTP Operator は、ベアメタルインフラストラクチャーでのみプロビジョニングされるクラスターの PTP 対応デバイスと連携します。

PTP Operator をデプロイし、OpenShift Container Platform コンソールまたは oc を使用して PTP をインストールできます。PTP Operator は linuxptp サービスを作成し、管理し、以下の機能を提供します。

  • クラスター内の PTP 対応デバイスの検出。
  • linuxptp サービスの設定の管理。
  • PTP Operator cloud-event-proxy サイドカーによるアプリケーションのパフォーマンスおよび信頼性に悪影響を与える PTP クロックイベントの通知。

10.2. PTP について

Precision Time Protocol (PTP) は、ネットワーク内のクロックを同期するのに使用されます。ハードウェアサポートと併用する場合、PTP はマイクロ秒以下の正確性があり、Network Time Protocol (NTP) よりも正確になります。

linuxptp パッケージには、クロック同期用の ptp4l および phc2sys プログラムが含まれています。ptp4l は、PTP 境界クロックと通常のクロックを実装します。ptp4l は PTP ハードウェアクロックをハードウェアのタイムスタンプにソースクロックに同期し、システムクロックをソフトウェアタイムスタンプとクロックに同期します。phc2sys は、ネットワークインターフェースコントローラー (NIC) 上の PTP ハードウェアクロックに同期するために、ハードウェアタイムスタンプに使用されます。

10.2.1. PTP ドメインの要素

PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。以下のタイプのクロックを設定に追加できます。

グランドマスタークロック
グランドマスタークロックは、ネットワーク全体の他のクロックに標準時間情報を提供し、正確で安定した同期を保証します。グランドマスタークロッククロックはタイムスタンプを書き込み、他のクロックからのタイムリクエストに応答します。
通常のクロック
通常のクロックには、ネットワーク内の位置に応じて、送信元クロックまたは宛先クロックの役割を果たすことができる単一のポート接続があります。通常のクロックは、タイムスタンプの読み取りおよび書き込みが可能です。
境界クロック
境界クロックには、2 つ以上の通信パスにあるポートがあり、ソースと宛先の宛先を同時に他の宛先クロックに指定できます。境界クロックは、宛先クロックアップストリームとして機能します。宛先クロックはタイミングメッセージを受け取り、遅延に合わせて調整し、ネットワークを渡す新しいソースタイムシグナルを作成します。境界クロックは、ソースクロックと正しく同期され、ソースクロックに直接レポートする接続されたデバイスの数を減らすことができる新しいタイミングパケットを生成します。

10.2.2. NTP 上の PTP の利点

PTP が NTP を経由した主な利点の 1 つは、さまざまなネットワークインターフェースコントローラー (NIC) およびネットワークスイッチにあるハードウェアサポートです。この特化されたハードウェアにより、PTP はメッセージ送信の遅れを説明でき、時間同期の精度を高められます。可能な限りの精度を実現するには、PTP クロック間の全ネットワークコンポーネントが PTP ハードウェアを有効にすることが推奨されます。

NICはPTPパケットを送受信した瞬間にタイムスタンプを付けることができるため、ハードウェアベースのPTPは最適な精度を提供します。これをソフトウェアベースの PTP と比較します。これには、オペレーティングシステムによる PTP パケットの追加処理が必要になります。

重要

PTP を有効にする前に、必要なノードについて NTP が無効になっていることを確認します。MachineConfig カスタムリソースを使用して chrony タイムサービス (chronyd) を無効にすることができます。詳細は、chrony タイムサービスの無効化を参照してください。

10.3. CLI を使用した PTP Operator のインストール

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

前提条件

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

手順

  1. PTP Operator の namespace を作成するには、以下のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-ptp
      annotations:
        workload.openshift.io/allowed: management
      labels:
        name: openshift-ptp
        openshift.io/cluster-monitoring: "true"
    EOF
  2. Operator の Operator グループを作成するには、以下のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ptp-operators
      namespace: openshift-ptp
    spec:
      targetNamespaces:
      - openshift-ptp
    EOF
  3. PTP Operator にサブスクライブします。

    1. 以下のコマンドを実行して、OpenShift Container Platform のメジャーおよびマイナーバージョンを環境変数として設定します。これは次の手順で channel の値として使用されます。

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)
    2. PTP Operator のサブスクリプションを作成するには、以下のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "${OC_VERSION}"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

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

    出力例

    Name                                        Phase
    ptp-operator.4.4.0-202006160135             Succeeded

10.4. Web コンソールを使用した PTP Operator のインストール

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

注記

先のセクションで説明されているように namespace および Operator グループを作成する必要があります。

手順

  1. OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から PTP Operator を選択してから Install をクリックします。
    3. Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
  2. オプション: PTP Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. PTP OperatorStatusInstallSucceeded の状態で openshift-ptp プロジェクトに一覧表示されていることを確認します。

      注記

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

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • WorkloadsPods ページに移動し、openshift-ptp プロジェクトで Pod のログを確認します。

10.5. PTP ネットワークデバイスの自動検出

PTP Operator は NodePtpDevice.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。

PTP Operator はクラスターで、各ノードの PTP 対応ネットワークデバイスを検索します。これは、互換性のある PTP デバイスを提供する各ノードの NodePtpDevice カスタムリソース (CR) オブジェクトを作成し、更新します。

1 つの CR がノードごとに作成され、ノードと同じ名前を共有します。.status.devices 一覧は、ノード上の PTP デバイスについての情報を提供します。

以下は、PTP Operator によって作成される NodePtpDevice CR の例です。

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2019-11-15T08:57:11Z"
  generation: 1
  name: dev-worker-0 1
  namespace: openshift-ptp 2
  resourceVersion: "487462"
  selfLink: /apis/ptp.openshift.io/v1/namespaces/openshift-ptp/nodeptpdevices/dev-worker-0
  uid: 08d133f7-aae2-403f-84ad-1fe624e5ab3f
spec: {}
status:
  devices: 3
  - name: eno1
  - name: eno2
  - name: ens787f0
  - name: ens787f1
  - name: ens801f0
  - name: ens801f1
  - name: ens802f0
  - name: ens802f1
  - name: ens803
1
name パラメーターの値はノードの名前と同じです。
2
CR は PTP Operator によって openshift-ptp namespace に作成されます。
3
devices コレクションには、ノード上の Operator によって検出される PTP 対応デバイスの一覧が含まれます。

クラスター内の PTP 対応ネットワークデバイスの一覧を返すには、以下のコマンドを実行します。

$ oc get NodePtpDevice -n openshift-ptp -o yaml

10.6. linuxptp サービスを通常のクロックとして設定

PTP Operator は PtpConfig.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4lphc2sys) を設定できます。

前提条件

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

手順

  1. 以下の PtpConfig CR を作成してから、YAML を ordinary-clock-ptp-config.yaml ファイルに保存します。

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: ordinary-clock-ptp-config 1
      namespace: openshift-ptp
    spec:
      profile: 2
      - name: "profile1" 3
        interface: "ens787f1" 4
        ptp4lOpts: "-s -2" 5
        phc2sysOpts: "-a -r" 6
        ptp4lConf: "" 7
        ptpSchedulingPolicy: SCHED_OTHER 8
        ptpSchedulingPriority: 65 9
      recommend: 10
      - profile: "profile1" 11
        priority: 10 12
        match: 13
        - nodeLabel: "node-role.kubernetes.io/worker" 14
          nodeName: "compute-0.example.com" 15
    1
    PtpConfig CR の名前。
    2
    1 つ以上の profile オブジェクトの配列を指定します。
    3
    プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
    4
    ptp4l サービスで使用するネットワークインターフェース名を指定します (例: ens787f1)。
    5
    ptp4lサービスのシステム設定オプションを指定します。たとえば、-2で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェース名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェース名 -i <interface> およびサービス設定ファイル -f /etc/ptp4l.conf を含めないでください。
    6
    phc2sys サービスのシステム設定オプション(例: -a -r) を指定します。このフィールドが空の場合、PTP Operator は phc2sys サービスを開始しません。
    7
    デフォルトの /etc/ptp4l.conf ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。
    8
    ptp4lphc2sysプロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。
    9
    ptp4lおよびphc2sysプロセスの FIFO 優先度の設定に使用する 1〜65 の整数値。ptp Scheduling PolicySCHED_FIFOが設定されている場合は必須です。
    10
    profile がノードに適用される方法を定義する 1 つ以上の recommend オブジェクトの配列を指定します。
    11
    profile セクションに定義される profile オブジェクト名を指定します。
    12
    0 から 99 までの整数値で priority を指定します。数値が大きいほど優先度が低くなるため、99 の優先度は 10よりも低くなります。ノードが match フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。
    13
    match ルールを、nodeLabel または nodeName で指定します。
    14
    oc get nodes --show-labels コマンドを使用して、ノードオブジェクトのnode.LabelskeynodeLabelを指定します。
    15
    oc get nodesコマンドを使用して、ノードオブジェクトのnode.NamenodeNameを指定します。
  2. 以下のコマンドを実行して CR を作成します。

    $ oc create -f ordinary-clock-ptp-config.yaml

検証手順

  1. PtpConfig プロファイルがノードに適用されていることを確認します。

    1. 以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      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

    2. プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。以下のコマンドを実行します。

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

      出力例

      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: -s -2
      I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

10.7. linuxptp サービスを境界クロックとして設定

PTP Operator は PtpConfig.ptp.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4lphc2sys) を設定できます。

前提条件

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

手順

  1. 以下の PtpConfig CR を作成してから、YAML を boundary-clock-ptp-config.yaml ファイルに保存します。

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: boundary-clock-ptp-config 1
      namespace: openshift-ptp
    spec:
      profile: 2
      - name: "profile1" 3
        interface: "" 4
        ptp4lOpts: "-2" 5
        ptp4lConf: | 6
          [ens1f0] 7
          masterOnly 0
          [ens1f3] 8
          masterOnly 1
          [global]
          #
          # Default Data Set
          #
          twoStepFlag                       1
          #slaveOnly                        1
          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       10
          #was 1 (default !)
          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
          #
          # 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              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    UDPv4
          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              0xA0
        phc2sysOpts: "-a -r" 9
        ptpSchedulingPolicy: SCHED_OTHER 10
        ptpSchedulingPriority: 65 11
      recommend: 12
      - profile: "profile1" 13
        priority: 10 14
        match: 15
        - nodeLabel: "node-role.kubernetes.io/worker" 16
          nodeName: "compute-0.example.com" 17
    1
    PtpConfig CR の名前。
    2
    1 つ以上の profile オブジェクトの配列を指定します。
    3
    プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
    4
    このフィールドは、境界クロックの場合は空のままにする必要があります。
    5
    ptp4l サービスのシステム設定オプション (例: -2) を指定します。ネットワークインターフェース名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェース名 -i <interface> およびサービス設定ファイル -f /etc/ptp4l.conf を含めないでください。
    6
    ptp4l を境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0 はグランドマスタークロックから同期し、ens1f3 は接続されたデバイスを同期します。
    7
    同期元のインターフェース名。
    8
    インターフェースに接続されたデバイスを同期するインターフェース。
    9
    phc2sys サービスのシステム設定オプション(例: -a -r) を指定します。このフィールドが空の場合、PTP Operator は phc2sys サービスを開始しません。
    10
    ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値はSCHED_OTHERです。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。
    11
    ptp4lおよびphc2sysプロセスの FIFO 優先度の設定に使用する 1〜65 の整数値。ptp Scheduling PolicySCHED_FIFOが設定されている場合は必須です。
    12
    profile がノードに適用される方法を定義する 1 つ以上の recommend オブジェクトの配列を指定します。
    13
    profile セクションに定義される profile オブジェクト名を指定します。
    14
    0 から 99 までの整数値で priority を指定します。数値が大きいほど優先度が低くなるため、99 の優先度は 10よりも低くなります。ノードが match フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。
    15
    match ルールを、nodeLabel または nodeName で指定します。
    16
    oc get nodes --show-labels コマンドを使用して、ノードオブジェクトのnode.LabelskeynodeLabelを指定します。
    17
    oc get nodesコマンドを使用して、ノードオブジェクトのnode.NamenodeNameを指定します。
  2. 以下のコマンドを実行して CR を作成します。

    $ oc create -f boundary-clock-ptp-config.yaml

検証手順

  1. PtpConfig プロファイルがノードに適用されていることを確認します。

    1. 以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      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

    2. プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。以下のコマンドを実行します。

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

      出力例

      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
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

10.8. PTP ハードウェアの FIFO 優先スケジューリングの設定

低遅延のパフォーマンスを確保する必要のある通信業者や他のデプロイメント設定では、PTP デーモンスレッドは、制約された CPU フットプリントで、残りのインフラストラクチャーのコンポーネントと一緒に、実行されます。デフォルトでは、PTP スレッドはSCHED_OTHERポリシーで実行されます。負荷が高いと、エラーなしで運用する必要のある、これらのスレッドのスケジューリングでレイテンシーが発生する可能性があります。

スケジューリングのレイテンシーでエラーが発生する可能性を軽減するために、SCHED_FIFOポリシーでスレッドを実行できるように、PTP Operator のlinuxptp サービスを設定できます。Ptp ConfigCR にSCHED_FIFOが設定されている場合には、ptp4lphc2sysは、Ptp ConfigCR のptp Scheduling Priorityフィールドで設定された優先順位で、chrtの下の親コンテナーで実行されます。

注記

ptp Scheduling Policyの設定はオプションで、レイテンシーエラーが発生している場合にのみ必要となります。

手順

  1. Ptp Config CR プロファイルを編集します。

    $ oc edit PtpConfig -n openshift-ptp
  2. ptp Scheduling Policyptp Scheduling Priorityフィールドを変更します。

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: <ptp_config_name>
      namespace: openshift-ptp
    ...
    spec:
      profile:
      - name: "profile1"
    ...
        ptpSchedulingPolicy: SCHED_FIFO 1
        ptpSchedulingPriority: 65 2
    1
    ptp4lphc2sysプロセスのスケジューリングポリシー。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFOを使用してください。
    2
    必須。ptp4lおよびphc2sysプロセスの FIFO 優先度の設定に使用する 1~65 の整数値を設定します。
  3. 保存して終了すると、Ptp ConfigCR に変更が適用されます。

検証

  1. Ptp ConfigCR が適用されたlinuxptp-daemon Pod と対応するノードの名前を取得します。

    $ oc get pods -n openshift-ptp -o wide

    出力例

    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

  2. ptp4lプロセスが、更新されたchrtFIFO 優先度で実行されていることを確認します。

    $ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

    出力例

    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

10.9. 一般的な PTP Operator の問題のトラブルシューティング

以下の手順を実行して、PTP Operator で典型的な問題のトラブルシューティングを行います。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • PTP をサポートするホストを使用して、PTP Operator をベアメタルクラスターにインストールします。

手順

  1. Operator およびオペランドが、設定されたノードについてクラスターに正常にデプロイされていることを確認します。

    $ oc get pods -n openshift-ptp -o wide

    出力例

    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

    注記

    PTP 高速イベントバスが有効な場合には、準備できた linuxptp-daemon Pod の数は 3/3 になります。PTP 高速イベントバスが有効になっていない場合、2/2 が表示されます。

  2. サポートされているハードウェアがクラスターにあることを確認します。

    $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

    出力例

    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

  3. ノードで利用可能な PTP ネットワークインターフェースを確認します。

    $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

    ここで、

    <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

  4. 対応するノードの linuxptp-daemon Pod にアクセスし、PTP インターフェースがプライマリークロックに正常に同期されていることを確認します。

    1. 以下のコマンドを実行して、linuxptp-daemon Pod の名前と、トラブルシューティングに使用するノードを取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      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

    2. リモートシェルが必要な linuxptp-daemon コンテナーへのリモートシェルです。

      $ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>

      ここで、

      <linux_daemon_container>
      診断するコンテナーです(例: linuxptp-daemon-lmvgn)。
    3. linuxptp-daemon コンテナーへのリモートシェル接続では、PTP 管理クライアント(pmc)ツールを使用して、ネットワークインターフェースを診断します。以下の pmc コマンドを実行して、PTP デバイスの同期ステータスを確認します(例: ptp4l)。

      # pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      ノードがプライマリークロックに正常に同期されたときの出力例

      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

10.10. PTP ハードウェアの高速イベント通知フレームワーク

重要

通常のクロックを使用した PTP イベントは、テクノロジープレビューとしてのみ機能します。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

10.10.1. PTP およびクロック同期エラーイベントについて

仮想 RAN などのクラウドネイティブアプリケーションでは、ネットワーク全体の機能に重要なハードウェアタイミングイベントに関する通知へのアクセスが必要です。高速イベント通知は、差し迫ったおよび Real-time Precision Time Protocol (PTP)のクロック同期イベントに関する早期の警告シグナルです。PTP クロック同期エラーは、分散ユニット(DU)で実行している vRAN アプリケーションなど、低レイテンシーアプリケーションのパフォーマンスおよび信頼性に悪影響を及ぼす可能性があります。

PTP 同期の損失は、RAN ネットワークでは重大なエラーです。ノードで同期が失われると、無線がシャットダウンされ、ネットワークのOTA(Over the Air)トラフィックがワイヤレスネットワーク内の別のノードにシフトされる可能性があります。高速のイベント通知は、クラスターノードが DU で実行している vRAN アプリケーションに対して PTP クロック同期ステータスと通信できるようにすることで、ワークロードのエラーを軽減します。

イベント通知は、同じ DU ノードで実行している RAN アプリケーションで利用できます。パブリッシュ/サブスクライブ REST API は、イベント通知をメッセージングバスに渡します。パブリッシュ/サブスクライブメッセージング、またはpub/subメッセージングは、トピックに公開されたメッセージがトピックのすべてのサブスクライバーに即座に受信される、サービス通信アーキテクチャへの非同期サービスです。

高速イベント通知は、すべての PTP 対応ネットワークインターフェースについて OpenShift Container Platform の PTP Operator によって生成されます。イベントは、Advanced Message Queuing Protocol (AMQP)メッセージバスで cloud-event-proxy サイドカーコンテナーを使用して利用可能になります。AMQP メッセージバスは AMQ Interconnect Operator によって提供されます。

注記

PTP 高速イベント通知は、PTP もしくは通常のクロックを使用するように設定されたネットワークインターフェースでのみ利用できます。

10.10.2. PTP 高速イベント通知フレームワークについて

分散ユニット(DU)アプリケーションを、PTP Operator および cloud-event-proxy サイドカーコンテナーを使用して、OpenShift Container Platform によって生成される Precision Time Protocol(PTP)高速イベント通知にサブスクライブできます。ptpOperatorConfig カスタムリソース(CR)で enableEventPublisher フィールドを true に設定し、transportHost アドレスを指定することで、cloud-event-proxy サイドカーコンテナーを有効にします 。PTP 高速イベントは、AMQ Interconnect Operator によって提供される Advanced Message Queuing Protocol (AMQP)イベント通知バスを使用します。AMQ Interconnect は Red Hat AMQ のコンポーネントで、AMQP 対応エンドポイント間でメッセージを柔軟にルーティングするメッセージングルーターです。

cloud-event-proxy サイドカーコンテナーは、プライマリーアプリケーションのリソースを使用せずに、プライマリー vRAN アプリケーションと同じリソースにアクセスでき、レイテンシーが大きくなくても構いません。

高速イベント通知フレームワークは通信に REST API を使用し、O-RAN REST API 仕様に基づいています。フレームワークは、パブリッシャーとサブスクライバーアプリケーション間の通信を処理するパブリッシャー、サブスクライバー、および AMQ メッセージングバスで構成されます。cloud-event-proxy サイドカーは、DU ノードのメイン DU アプリケーションコンテナーにゆるく結合された Pod で実行するユーティリティーコンテナーです。これは、DU アプリケーションを公開された PTP イベントにサブスクライブできるようにするイベント公開フレームワークを提供します。

DU アプリケーションはサイドカーパターンで cloud-event-proxy コンテナーを実行し、PTP イベントにサブスクライブします。以下のワークフローでは、DU アプリケーションが PTP 高速イベントを使用する方法について説明します。

  1. DU アプリケーションはサブスクリプションを要求: DU は API リクエストを cloud-event-proxy サイドカーに送信し、PTP イベントサブスクリプションを作成します。cloud-event-proxy サイドカーは、サブスクリプションリソースを作成します。
  2. cloud-event-proxy サイドカーは、サブスクリプションを作成: イベントリソースは cloud-event-proxy サイドカーによって永続化されます。cloud-event-proxy サイドカーコンテナーは、ID と URL の場所で確認応答を送信し、保存されたサブスクリプションリソースにアクセスします。サイドカーは、サブスクリプションに指定されたリソースの AMQ メッセージングリスナープロトコルを作成します。
  3. DU アプリケーションは PTP イベント通知を受受け取る: cloud-event-proxy サイドカーコンテナーは、リソース修飾子で指定されたアドレスをリッスンします。DU イベントのコンシューマーはメッセージを処理し、これをサブスクリプションで指定した返信 URL に渡します。
  4. cloud-event-proxy サイドカーは、PTP イベントを検証し、これを DU アプリケーションに送信: cloud-event-proxy サイドカーはイベントを受信し、クラウドイベントオブジェクトをアンラップデータを取得し、イベントを返す URL を取得して DU コンシューマーアプリケーションに返します。
  5. DU アプリケーションは PTP イベントを使用: DU アプリケーションイベントコンシューマーは PTP イベントを受信して処理します。

10.10.3. AMQ メッセージングバスのインストール

ノードのパブリッシャーとサブスクライバー間で PTP 高速イベント通知を渡すには、ノードでローカルに実行するように AMQ メッセージングバスをインストールおよび設定する必要があります。これは、クラスターで使用するために AMQ Interconnect Operator をインストールして行います。

前提条件

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

手順

検証

  1. AMQ Interconnect Operator が利用可能で、必要な Pod が実行していることを確認します。

    $ oc get pods -n amq-interconnect

    出力例

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
    interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

  2. 必要な linuxptp-daemon PTP イベントプロデューサー Pod が openshift-ptp namespace で実行していることを確認します。

    $ oc get pods -n openshift-ptp

    出力例

    NAME                     READY   STATUS    RESTARTS       AGE
    linuxptp-daemon-2t78p    3/3     Running   0              12h
    linuxptp-daemon-k8n88    3/3     Running   0              12h

10.10.4. PTP 高速イベント通知パブリッシャーの設定

クラスター内のネットワークインターフェースの PTP 高速イベント通知の使用を開始するには、PTP Operator PtpOperatorConfig カスタムリソース(CR)で高速イベントパブリッシャーを有効にし、作成する PtpConfig CR に ptpClockThreshold 値を設定する必要があります。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • PTP Operator および AMQ Interconnect Operator をインストールします。

手順

  1. PtpOperatorConfig リソースの spec.ptpEventConfig フィールドを変更し、以下のコマンドを実行して適切な値を設定します。

    $ oc edit PtpOperatorConfig default -n openshift-ptp
    ...
    spec:
      daemonNodeSelector:
        node-role.kubernetes.io/worker: ""
      ptpEventConfig:
        enableEventPublisher: true 1
        transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local 2
    1
    enableEventPublishertrue に設定して、PTP 高速イベント通知を有効にします。
    2
    transportHost を、設定した AMQ ルーターに設定します。<instance_name> および <namespace> は AMQ Interconnect ルーターインスタンス名および namespace に対応します(例: amqp://amq-interconnect.amq-interconnect.svc.cluster.local)。
  2. PTP 対応インターフェースの PtpConfig カスタムリソースを作成し、ptpClockThreshold に必要な値を設定します。以下に例を示します。

    apiVersion: ptp.openshift.io/v1
    kind: PtpConfig
    metadata:
      name: example-ptpconfig
      namespace: openshift-ptp
    spec:
      profile:
      - name: "profile1"
        interface: "enp5s0f0"
        ptp4lOpts: "-2 -s --summary_interval -4"
        phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpClockThreshold:
        holdOverTimeout: 5 1
        maxOffsetThreshold: 100 2
        minOffsetThreshold: -100 3
      recommend:
      - profile: "profile1"
        priority: 4
        match:
        - nodeLabel: "node-role.kubernetes.io/worker"
    1
    クロックホールドオーバー状態にとどまる秒数。ホールドオーバー状態は、ローカルクロックとマスタークロックの同期の間の期間です。
    2
    最大オフセット値(ナノ秒)。オフセットは、ローカルクロックとマスタークロック間の時間差です。
    3
    最小オフセット値(ナノ秒)。

10.10.5. DU アプリケーションを PTP イベントにサブスクライブする RESTAPI リファレンス

PTP イベント通知 REST API を使用して、分散ユニット (DU) アプリケーションを親ノードで生成される PTP イベントにサブスクライブします。

リソースアドレス/cluster/node/<node_name>/ptp を使用して、アプリケーションを PTP イベントにサブスクライブします。ここで、<node_name> は、DU アプリケーションを実行しているクラスターノードです。

cloud-event-consumerDUアプリケーションコンテナーとcloud-event-proxyサイドカーコンテナーを別々の DU アプリケーション Pod にデプロイします。cloud-event-consumer DU アプリケーションは、アプリケーション Pod のcloud-event-proxyコンテナーにサブスクライブします。

次の API エンドポイントを使用して、cloud-event-consumer DU アプリケーションを、DU アプリケーション Pod の http://localhost:8089/api/cloudNotifications/v1/ にある cloud-event-proxy コンテナーによって投稿された PTP イベントにサブスクライブします。

  • /api/cloudNotifications/v1/subscriptions

    • POST: 新しいサブスクリプションを作成します。
    • GET: サブスクリプションの一覧を取得します。
  • /api/cloudNotifications/v1/subscriptions/<subscription_id>

    • GET:指定されたサブスクリプション ID の詳細を返します。
  • api/cloudNotifications/v1/subscriptions/status/<subscription_id>

    • PUT: 指定されたサブスクリプション ID に新しいステータス ping 要求を作成します。
  • /api/cloudNotifications/v1/health

    • GET: cloudNotifications API の正常性ステータスを返します。
注記

9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、DU アプリケーションに別のポートを設定できます。

10.10.5.1. api/cloudNotifications/v1/subscriptions

10.10.5.1.1. HTTP メソッド

GET api/cloudNotifications/v1/subscriptions

10.10.5.1.1.1. 詳細

サブスクリプションの一覧を返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。

API 応答の例

[
 {
  "id": "75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions/75b1ad8f-c807-4c23-acf5-56f4b7ee3826",
  "resource": "/cluster/node/compute-1.example.com/ptp"
 }
]

10.10.5.1.2. HTTP メソッド

POST api/cloudNotifications/v1/subscriptions

10.10.5.1.2.1. 詳細

新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。

表10.1 クエリーパラメーター

パラメータータイプ

subscription

data

ペイロードの例

{
  "uriLocation": "http://localhost:8089/api/cloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/compute-1.example.com/ptp"
}

10.10.5.2. api/cloudNotifications/v1/subscriptions/<subscription_id>

10.10.5.2.1. HTTP メソッド

GET api/cloudNotifications/v1/subscriptions/<subscription_id>

10.10.5.2.1.1. 詳細

ID が <subscription_id>のサブスクリプションの詳細を返します。

表10.2 クエリーパラメーター

パラメータータイプ

<subscription_id>

string

API 応答の例

{
  "id":"48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "endpointUri": "http://localhost:9089/event",
  "uriLocation":"http://localhost:8089/api/cloudNotifications/v1/subscriptions/48210fb3-45be-4ce0-aa9b-41a0e58730ab",
  "resource":"/cluster/node/compute-1.example.com/ptp"
}

10.10.5.3. api/cloudNotifications/v1/subscriptions/status/<subscription_id>

10.10.5.3.1. HTTP メソッド

PUT api/cloudNotifications/v1/subscriptions/status/<subscription_id>

10.10.5.3.1.1. 詳細

ID <subscription_id> のサブスクリプションの新規ステータス ping 要求を作成します。サブスクリプションが存在する場合は、ステータスリクエストに成功し、202 Accepted ステータスコードが返されます。

表10.3 クエリーパラメーター

パラメータータイプ

<subscription_id>

string

API 応答の例

{"status":"ping sent"}

10.10.5.4. api/cloudNotifications/v1/health/

10.10.5.4.1. HTTP メソッド

GET api/cloudNotifications/v1/health/

10.10.5.4.1.1. 詳細

cloudNotifications REST API の正常性ステータスを返します。

API 応答の例

OK

10.10.6. CLI を使用した PTP 高速イベントメトリクスの監視

oc CLI を使用して、cloud-event-proxy コンテナーから直接高速イベントバスメトリクスをモニターできます。

注記

PTP 高速イベント通知メトリクスは OpenShift Container Platform Web コンソールでも利用できます。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • PTP Operator をインストールし、設定します。

手順

  1. アクティブな linuxptp-daemon Pod の一覧を取得します。

    $ oc get pods -n openshift-ptp

    出力例

    NAME                    READY   STATUS    RESTARTS   AGE
    linuxptp-daemon-2t78p   3/3     Running   0          8h
    linuxptp-daemon-k8n88   3/3     Running   0          8h

  2. 以下のコマンドを実行して、必要な cloud-event-proxy コンテナーのメトリクスにアクセスします。

    $ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

    ここで、

    <linuxptp-daemon>

    問い合わせる Pod を指定します(例: linuxptp-daemon-2t78p)。

    出力例

    # HELP cne_amqp_events_published Metric to get number of events published by the transport
    # TYPE cne_amqp_events_published gauge
    cne_amqp_events_published{address="/cluster/node/compute-1.example.com/ptp/status",status="success"} 1041
    # HELP cne_amqp_events_received Metric to get number of events received  by the transport
    # TYPE cne_amqp_events_received gauge
    cne_amqp_events_received{address="/cluster/node/compute-1.example.com/ptp",status="success"} 1019
    # HELP cne_amqp_receiver Metric to get number of receiver created
    # TYPE cne_amqp_receiver gauge
    cne_amqp_receiver{address="/cluster/node/mock",status="active"} 1
    cne_amqp_receiver{address="/cluster/node/compute-1.example.com/ptp",status="active"} 1
    cne_amqp_receiver{address="/cluster/node/compute-1.example.com/redfish/event",status="active"}
    ...

10.10.7. Web コンソールでの PTP 高速イベントメトリクスの監視

事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。

前提条件

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

手順

  1. 以下のコマンドを実行して、cloud-event-proxy サイドカーコンテナーから利用可能な PTP メトリクスの一覧を返します。

    $ oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

    ここで、

    <linuxptp_daemon_pod>
    問い合わせる Pod を指定します(例: linuxptp-daemon-2t78p)。
  2. 返されるメトリクスの一覧から問い合わせる PTP メトリクスの名前(例: cne_amqp_events_received)をコピーします。
  3. OpenShift Container Platform Web コンソールで、ObserveMetrics をクリックします。
  4. PTP メトリクスを Expression フィールドに貼り付け、Run queries をクリックします。

第11章 ネットワークポリシー

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

クラスター管理者は、トラフィックをクラスター内の Pod に制限するネットワークポリシーを定義できます。

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

Kubernetes ネットワークポリシーをサポートする Kubernetes Container Network Interface (CNI) プラグインを使用するクラスターでは、ネットワークの分離は NetworkPolicy オブジェクトによって完全に制御されます。OpenShift Container Platform 4.9 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。

注記

OpenShift SDN クラスターネットワークプロバイダーを使用する場合、ネットワークポリシーについて、以下の制限が適用されます。

  • egress フィールドで指定される egress ネットワークポリシーはサポートされていません。
  • IPBlock はネットワークポリシーでサポートされますが、except 句はサポートしません。except 句を含む IPBlock セクションのあるポリシーを作成する場合、SDN Pod は警告をログに記録し、そのポリシーの IPBlock セクション全体は無視されます。
警告

ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。

デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。

Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。

以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。

  • すべてのトラフィックを拒否します。

    プロジェクトに「deny by default (デフォルトで拒否)」を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
    spec:
      podSelector: {}
      ingress: []
  • OpenShift Container Platform Ingress コントローラーからの接続のみを許可します。

    プロジェクトで OpenShift Container Platform Ingress コントローラーからの接続のみを許可するには、以下の NetworkPolicy オブジェクトを追加します。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-ingress
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: ingress
      podSelector: {}
      policyTypes:
      - Ingress
  • プロジェクト内の Pod からの接続のみを受け入れます。

    Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の NetworkPolicy オブジェクトを追加します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector: {}
      ingress:
      - from:
        - podSelector: {}
  • 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
  • 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

NetworkPolicy オブジェクトは加算されるものです。 つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespaceallow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。

11.1.2. ネットワークポリシーの最適化

ネットワークポリシーを使用して、namespace 内でラベルで相互に区別される Pod を分離します。

注記

ネットワークポリシールールを効果的に使用するためのガイドラインは、OpenShift SDN クラスターネットワークプロバイダーのみに適用されます。

NetworkPolicy オブジェクトを単一 namespace 内の多数の個別 Pod に適用することは効率的ではありません。Pod ラベルは IP レベルには存在しないため、ネットワークポリシーは、podSelector で選択されるすべての Pod 間のすべてのリンクについての別個の Open vSwitch (OVS) フロールールを生成します。

たとえば、仕様の podSelector および NetworkPolicy オブジェクト内の ingress podSelector のそれぞれが 200 Pod に一致する場合、40,000 (200*200) OVS フロールールが生成されます。これにより、ノードの速度が低下する可能性があります。

ネットワークポリシーを設計する場合は、以下のガイドラインを参照してください。

  • namespace を使用して分離する必要のある Pod のグループを組み込み、OVS フロールールの数を減らします。

    namespace 全体を選択する NetworkPolicy オブジェクトは、namespaceSelectors または空の podSelectors を使用して、namespace の VXLAN 仮想ネットワーク ID に一致する単一の OVS フロールールのみを生成します。

  • 分離する必要のない Pod は元の namespace に維持し、分離する必要のある Pod は 1 つ以上の異なる namespace に移します。
  • 追加のターゲット設定された namespace 間のネットワークポリシーを作成し、分離された Pod から許可する必要のある特定のトラフィックを可能にします。

11.1.3. 次のステップ

11.1.4. 関連情報

11.2. ネットワークポリシーイベントのロギング

クラスター管理者は、クラスターのネットワークポリシー監査ロギングを設定し、1 つ以上の namespace のロギングを有効にできます。

注記

ネットワークポリシーの監査ロギングは OVN-Kubernetes クラスターネットワークプロバイダー でのみ利用可能です。

11.2.1. ネットワークポリシー監査ロギング

OVN-Kubernetes クラスターネットワークプロバイダーは、Open Virtual Network (OVN) ACL を使用してネットワークポリシーを管理します。監査ロギングは ACL イベントの許可および拒否を公開します。

syslog サーバーや UNIX ドメインソケットなどのネットワークポリシー監査ログの宛先を設定できます。追加の設定に関係なく、監査ログは常にクラスター内の各 OVN-Kubernetes Pod の /var/log/ovn/acl-audit-log.log に保存されます。

以下の例のように、namespace に k8s.ovn.org/acl-logging キーでアノテーションを付けることにより、namespace ごとにネットワークポリシー監査ログを有効にします。

namespace アノテーションの例

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

ロギング形式は RFC5424 によって定義される syslog と互換性があります。syslog ファシリティーは設定可能です。デフォルトは local0 です。ログエントリーの例は、以下のようになります。

ACL 拒否ログエントリーの例

2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

以下の表は、namespace アノテーションの値について説明しています。

表11.1 ネットワークポリシー監査ロギング namespace アノテーション

アノテーション

k8s.ovn.org/acl-logging

namespace のネットワークポリシー監査ロギングを有効にするには、allowdeny、または両方のうち、少なくとも 1 つを指定する必要があります。

deny
オプション: alertwarningnoticeinfo、または debug を指定します。
allow
オプション: alertwarningnoticeinfo、または debug を指定します。

11.2.2. ネットワークポリシー監査の設定

監査ロギングの設定は、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

以下の表は、ネットワークポリシー監査ロギングの設定フィールドについて説明しています。

表11.2 policyAuditConfig object

フィールドタイプ詳細

rateLimit

integer

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

maxFileSize

integer

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

destination

string

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

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

syslogFacility

string

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

11.2.3. クラスターのネットワークポリシー監査の設定

クラスター管理者は、クラスターのネットワークポリシー監査ロギングをカスタマイズできます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。

手順

  • ネットワークポリシーの監査ロギングの設定をカスタマイズするには、以下のコマンドを入力します。

    $ oc edit network.operator.openshift.io/cluster
    ヒント

    または、以下の YAML をカスタマイズして適用することで、監査ロギングを設定できます。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      defaultNetwork:
        ovnKubernetesConfig:
          policyAuditConfig:
            destination: "null"
            maxFileSize: 50
            rateLimit: 20
            syslogFacility: local0

検証

  1. ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。

    1. 検証用の 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

      出力例

      namespace/verify-audit-logging created

    2. 監査ロギングを有効にします。

      $ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'
      namespace/verify-audit-logging annotated
    3. 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
      spec:
        podSelector: {}
        policyTypes:
         - Ingress
         - Egress
        ingress:
          - from:
              - podSelector: {}
        egress:
          - to:
             - namespaceSelector:
                matchLabels:
                  namespace: verify-audit-logging
      EOF

      出力例

      networkpolicy.networking.k8s.io/deny-all created
      networkpolicy.networking.k8s.io/allow-from-same-namespace created

  2. ソーストラフィックの 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
  3. verify-audit-logging namespace に 2 つの Pod を作成します。

    $ 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

    出力例

    pod/client created
    pod/server created

  4. トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。

    1. verify-audit-logging namespace で server という名前の Pod の IP アドレスを取得します。

      $ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')
    2. default の namespace の client という名前の Pod の直前のコマンドから IP アドレスに ping し、すべてのパケットがドロップされていることを確認します。

      $ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

      出力例

      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

    3. verify-audit-logging namespace の client という名前の Pod から POD_IP シェル環境変数に保存されている IP アドレスに ping し、すべてのパケットが許可されていることを確認します。

      $ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

      出力例

      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

  5. ネットワークポリシー監査ログの最新エントリーを表示します。

    $ 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

    出力例

    Defaulting container name to ovn-controller.
    Use 'oc describe pod/ovnkube-node-hdb8v -n openshift-ovn-kubernetes' to see all of the containers in this pod.
    2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:33:12.614Z|00006|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:44:10.037Z|00007|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0
    2021-06-13T19:44:11.037Z|00008|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_allow-from-same-namespace_0", verdict=allow, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:3b,dl_dst=0a:58:0a:80:02:3a,nw_src=10.128.2.59,nw_dst=10.128.2.58,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

11.2.4. namespace のネットワークポリシー監査ロギングの有効化

クラスター管理者は、namespace のネットワークポリシーの監査ロギングを有効化できます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。

手順

  • オプション: namespace のネットワークポリシー監査ロギングを有効にするには、以下のコマンドを入力します。

    $ oc annotate namespace <namespace> \
      k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

    ここで、

    <namespace>
    namespace の名前を指定します。
    ヒント

    または、以下の YAML を適用して監査ロギングを有効化できます。

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/acl-logging: |-
          {
            "deny": "alert",
            "allow": "notice"
          }

    出力例

    namespace/verify-audit-logging annotated

検証

  • ネットワークポリシー監査ログの最新エントリーを表示します。

    $ 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

    出力例

    2021-06-13T19:33:11.590Z|00005|acl_log(ovn_pinctrl0)|INFO|name="verify-audit-logging_deny-all", verdict=drop, severity=alert: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:39,dl_dst=0a:58:0a:80:02:37,nw_src=10.128.2.57,nw_dst=10.128.2.55,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0

11.2.5. namespace のネットワークポリシー監査ロギングの無効化

クラスター管理者は、namespace のネットワークポリシー監査ロギングを無効化できます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。

手順

  • namespace のネットワークポリシー監査ロギングを無効にするには、以下のコマンドを入力します。

    $ annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging={}

    ここで、

    <namespace>
    namespace の名前を指定します。
    ヒント

    または、以下の YAML を適用して監査ロギングを無効化できます。

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/acl-logging: null

    出力例

    namespace/verify-audit-logging annotated

11.2.6. 関連情報

11.3. ネットワークポリシーの作成

admin ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。

11.3.1. ネットワークポリシーの作成

クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを作成できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが適用される namespace で作業している。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。

      $ touch <policy_name>.yaml

      ここでは、以下のようになります。

      <policy_name>
      ネットワークポリシーファイル名を指定します。
    2. 作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。

      すべての namespace のすべての Pod から ingress を拒否します。

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []

    同じ namespace のすべての Pod から ingress を許可します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-same-namespace
    spec:
      podSelector:
      ingress:
      - from:
        - podSelector: {}

  2. ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。

    $ oc apply -f <policy_name>.yaml -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーファイル名を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    networkpolicy.networking.k8s.io/default-deny created

注記

コンソールで cluster-admin ロールが割り当てられたユーザーでログインした場合に、YAML ビューから直接、または Web コンソールのフォームから、クラスター内の任意の namespace にネットワークポリシーを作成できます。

11.3.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
1
NetworkPolicy オブジェクトの名前。
2
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ名前空間の Pod と一致します。
4
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

11.3.3. 関連情報

11.4. ネットワークポリシーの表示

admin ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。

11.4.1. ネットワークポリシーの表示

namespace のネットワークポリシーを検査できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内のネットワークポリシーを表示できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  • namespace のネットワークポリシーを一覧表示します。

    • namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。

      $ oc get networkpolicy
    • オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。

      $ oc describe networkpolicy <policy_name> -n <namespace>

      ここでは、以下のようになります。

      <policy_name>
      検査するネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

      以下は例になります。

      $ oc describe networkpolicy allow-same-namespace

      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

11.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
1
NetworkPolicy オブジェクトの名前。
2
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ名前空間の Pod と一致します。
4
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

11.5. ネットワークポリシーの編集

admin ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。

11.5.1. ネットワークポリシーの編集

namespace のネットワークポリシーを編集できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の namespace でネットワークポリシーを編集できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  1. オプション: namespace のネットワークポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。

    $ oc get networkpolicy

    ここでは、以下のようになります。

    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  2. ネットワークポリシーオブジェクトを編集します。

    • ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。

      $ oc apply -n <namespace> -f <policy_file>.yaml

      ここでは、以下のようになります。

      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
      <policy_file>
      ネットワークポリシーを含むファイルの名前を指定します。
    • ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。

      $ oc edit networkpolicy <policy_name> -n <namespace>

      ここでは、以下のようになります。

      <policy_name>
      ネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  3. ネットワークポリシーオブジェクトが更新されていることを確認します。

    $ oc describe networkpolicy <policy_name> -n <namespace>

    ここでは、以下のようになります。

    <policy_name>
    ネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

11.5.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
1
NetworkPolicy オブジェクトの名前。
2
ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3
ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ名前空間の Pod と一致します。
4
トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

11.5.3. 関連情報

11.6. ネットワークポリシーの削除

admin ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。

11.6.1. ネットワークポリシーの削除

namespace のネットワークポリシーを削除できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内のネットワークポリシーを削除できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。
  • ネットワークポリシーが存在する namespace で作業している。

手順

  • ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。

    $ oc delete networkpolicy <policy_name> -n <namespace>

    ここで、

    <policy_name>
    ネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    networkpolicy.networking.k8s.io/default-deny deleted

11.7. プロジェクトのデフォルトネットワークポリシーの定義

クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。

11.7.1. 新規プロジェクトのテンプレートの変更

クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成することができます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

手順

  1. cluster-admin 権限を持つユーザーとしてログインしている。
  2. デフォルトのプロジェクトテンプレートを生成します。

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。
  4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

    $ oc create -f template.yaml -n openshift-config
  5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

    • Web コンソールの使用

      1. AdministrationCluster Settings ページに移動します。
      2. Configuration をクリックし、すべての設定リソースを表示します。
      3. Project のエントリーを見つけ、Edit YAML をクリックします。
    • CLI の使用

      1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster
  6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

    カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
      ...
    spec:
      projectRequestTemplate:
        name: <template_name>

  7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

11.7.2. 新規プロジェクトへのネットワークポリシーの追加

クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy オブジェクトを自動的に作成します。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用する(例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。
  • 新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成していること。

手順

  1. 以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。

    $ oc edit template <project_template> -n openshift-config

    <project_template> を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名は project-request です。

  2. テンプレートでは、各 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:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
    ...
  3. オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。

    1. 新規プロジェクトを作成します。

      $ oc new-project <project> 1
      1
      <project> を、作成しているプロジェクトの名前に置き換えます。
    2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

11.8. ネットワークポリシーを使用したマルチテナント分離の設定

クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。

注記

OpenShift SDN クラスターネットワークプロバイダーを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。

11.8.1. ネットワークポリシーを使用したマルチテナント分離の設定

他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 以下の NetworkPolicy オブジェクトを作成します。

    1. 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
      注記

      policy-group.network.openshift.io/ingress: ""は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingress namespace セレクターラベルを使用できますが、これはレガシーラベルです。

    2. 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
    3. 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
  2. オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。

    $ oc describe networkpolicy

    出力例

    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: network.openshift.io/policy-group: 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

11.8.2. 次のステップ

11.8.3. 関連情報

第12章 複数ネットワーク

12.1. 複数ネットワークについて

Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。

OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて 追加のネットワーク を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これは、スイッチまたはルーティングなどのネットワーク機能を提供する Pod を設定する場合に柔軟性を実現します。

12.1.1. 追加ネットワークの使用シナリオ

データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で追加のネットワークを使用することができます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。

パフォーマンス
各プレーンのトラフィック量を管理するために、2 つの異なるプレーンにトラフィックを送信できます。
セキュリティー
機密トラフィックは、セキュリティー上の考慮に基づいて管理されているネットワークに送信でき、テナントまたはカスタマー間で共有できないプライベートを分離することができます。

クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0 インターフェースがあります。Pod のインターフェースは、oc exec -it <pod_name> -- ip a コマンドを使用して表示できます。Multus CNI を使用するネットワークを追加する場合、それらの名前は net1net2、…​、 netN になります。

追加のネットワークを Pod に割り当てるには、インターフェースの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェースは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェースの作成方法を定義します。

12.1.2. OpenShift Container Platform の追加ネットワーク

OpenShift Container Platform は、クラスターに追加のネットワークを作成するために使用する以下の CNI プラグインを提供します。

12.2. 追加のネットワークの設定

クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。

12.2.1. 追加のネットワークを管理するためのアプローチ

追加したネットワークのライフサイクルを管理するには、2 つのアプローチがあります。各アプローチは同時に使用できず、追加のネットワークを管理する場合に 1 つのアプローチしか使用できません。いずれの方法でも、追加のネットワークは、お客様が設定した Container Network Interface (CNI)プラグインで管理します。

追加ネットワークの場合には、IP アドレスは、追加ネットワークの一部として設定する IPAM(IP Address Management)CNI プラグインでプロビジョニングされます。IPAM プラグインは、DHCP や静的割り当てなど、さまざまな IP アドレス割り当ての方法をサポートしています。

  • Cluster Network Operator (CNO) の設定を変更する: CNO は自動的に Network Attachment Definition オブジェクトを作成し、管理します。CNO は、オブジェクトのライフサイクル管理に加えて、DHCP で割り当てられた IP アドレスを使用する追加のネットワークで確実に DHCP が利用できるようにします。
  • YAML マニフェストを適用する: Network Attachment Definitionオブジェクトを作成することで、追加のネットワークを直接管理できます。この方法では、CNI プラグインを連鎖させることができます。

12.2.2. ネットワーク追加割り当ての設定

追加のネットワークは、k8s.cni.cncf.ioAPI グループのNetwork Attachment DefinitionAPI で設定されます。

重要

Network Attachment Definitionオブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。

API の設定については、以下の表で説明されています。

表12.1 NetworkAttachmentDefinition API フィールド

フィールドタイプ詳細

metadata.name

string

追加のネットワークの名前です。

metadata.namespace

string

オブジェクトが関連付けられる namespace。

spec.config

string

JSON 形式の CNI プラグイン設定です。

12.2.2.1. Cluster Network Operator による追加ネットワークの設定

追加のネットワーク割り当ての設定は、Cluster Network Operator (CNO) の設定の一部として指定します。

以下の YAML は、CNO で追加のネットワークを管理するための設定パラメーターを記述しています。

Cluster Network Operator (CNO) の設定

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks: 1
  - name: <name> 2
    namespace: <namespace> 3
    rawCNIConfig: |- 4
      {
        ...
      }
    type: Raw

1
1 つまたは複数の追加ネットワーク設定の配列。
2
作成している追加ネットワーク割り当ての名前。名前は指定された namespace 内で一意である必要があります。
3
ネットワークの割り当てを作成する namespace。値を指定しない場合、default の namespace が使用されます。
4
JSON 形式の CNI プラグインの設定です。

12.2.2.2. YAML マニフェストからの追加ネットワークの設定

追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 1
spec:
  config: |- 2
    {
      ...
    }
1
作成している追加ネットワーク割り当ての名前。
2
JSON 形式の CNI プラグインの設定です。

12.2.3. 追加のネットワークタイプの設定

次のセクションでは、追加のネットワークの具体的な設定フィールドについて説明します。

12.2.3.1. ブリッジネットワークの追加設定

以下のオブジェクトは、ブリッジ CNI プラグインの設定パラメーターについて説明しています。

表12.2 ブリッジ CNI プラグイン JSON 設定オブジェクト

フィールドタイプ詳細

cniVersion

string

CNI 仕様のバージョン。値 0.3.1 が必要です。

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

 

bridge

string

使用する仮想ブリッジの名前を指定します。ブリッジインターフェースがホストに存在しない場合は、これが作成されます。デフォルト値は cni0 です。

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。

ipMasq

boolean

仮想ネットワークから外すトラフィックについて IP マスカレードを有効にするには、true に設定します。すべてのトラフィックのソース IP アドレスは、ブリッジの IP アドレスに書き換えられます。ブリッジに IP アドレスがない場合は、この設定は影響を与えません。デフォルト値は false です。

isGateway

boolean

IP アドレスをブリッジに割り当てるには true に設定します。デフォルト値は false です。

isDefaultGateway

boolean

ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、true に設定します。デフォルト値は false です。isDefaultGatewaytrue に設定される場合、isGateway も自動的に true に設定されます。

forceAddress

boolean

仮想ブリッジの事前に割り当てられた IP アドレスの割り当てを許可するには、true に設定します。falseに設定される場合、重複サブセットの IPv4 アドレスまたは IPv6 アドレスが仮想ブリッジに割り当てられるとエラーが発生します。デフォルト値は false です。

hairpinMode

boolean

仮想ブリッジが受信時に使用した仮想ポートでイーサネットフレームを送信できるようにするには、true に設定します。このモードは、Reflective Relay (リフレクティブリレー) としても知られています。デフォルト値は false です。

promiscMode

boolean

ブリッジで無作為検出モード (Promiscuous Mode) を有効にするには、true に設定します。デフォルト値は false です。

vlan

string

仮想 LAN (VLAN) タグを整数値として指定します。デフォルトで、VLAN タグは割り当てません。

mtu

string

最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

12.2.3.1.1. ブリッジ設定の例

以下の例では、bridge-netという名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

12.2.3.2. ホストデバイスの追加ネットワークの設定

重要

devicehwaddrkernelpath、または pciBusID のいずれかのパラメーターを設定してネットワークデバイスを指定します。

以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターについて説明しています。

表12.3 ホストデバイス CNI プラグイン JSON 設定オブジェクト

フィールドタイプ詳細

cniVersion

string

CNI 仕様のバージョン。値 0.3.1 が必要です。

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: host-device

device

string

オプション: eth0などのデバイスの名前。

hwaddr

string

オプション: デバイスハードウェアの MAC アドレス。

kernelpath

string

オプション: /sys/devices/pci0000:00/0000:00:1f.6 などの Linux カーネルデバイス。

pciBusID

string

オプション: 0000:00:1f.6 などのネットワークデバイスの PCI アドレスを指定します。

12.2.3.2.1. ホストデバイス設定例

以下の例では、hostdev-netという名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "host-device",
  "device": "eth1"
}

12.2.3.3. IPVLAN 追加ネットワークの設定

以下のオブジェクトは、IPVLAN CNI プラグインの設定パラメーターについて説明しています。

表12.4 IPVLAN CNI プラグイン JSON 設定オブジェクト

フィールドタイプ詳細

cniVersion

string

CNI 仕様のバージョン。値 0.3.1 が必要です。

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: ipvlan

mode

string

仮想ネットワークの操作モード。この値は、l2l3、または l3s である必要があります。デフォルト値は l2です。

master

string

ネットワーク割り当てに関連付けるイーサネットインターフェース。master が指定されない場合、デフォルトのネットワークルートのインターフェースが使用されます。

mtu

integer

最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。

dhcpは指定しないでください。IPVLAN インターフェースは MAC アドレスをホストインターフェースと共有するため、IPVLAN の DHCP 設定はサポートされていません。

12.2.3.3.1. IPVLAN 設定例

以下の例では、ipvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "work-network",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10"
       }
    ]
  }
}

12.2.3.4. MACVLAN 追加ネットワークの設定

以下のオブジェクトは、macvlan CNI プラグインの設定パラメーターについて説明しています。

表12.5 MACVLAN CNI プラグイン JSON 設定オブジェクト

フィールドタイプ詳細

cniVersion

string

CNI 仕様のバージョン。値 0.3.1 が必要です。

name

string

CNO 設定に以前に指定した name パラメーターの値。

type

string

設定する CNI プラグインの名前: macvlan

mode

string

仮想ネットワークのトラフィックの可視性を設定します。bridgepassthruprivate、または vepa のいずれかである必要があります。値が指定されない場合、デフォルト値は bridge になります。

master

string

仮想インターフェースに関連付けるイーサネット、ボンディング、または VLAN インターフェース。値が指定されない場合、ホストシステムのプライマリーイーサネットインターフェースが使用されます。

mtu

string

最大転送単位 (MTU) を指定された値。デフォルト値はカーネルによって自動的に設定されます。

ipam

object

IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。

12.2.3.4.1. macvlan 設定の例

以下の例では、macvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

12.2.4. 追加ネットワークの IP アドレス割り当ての設定

IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。

以下の IP アドレスの割り当てタイプを使用できます。

  • 静的割り当て。
  • DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
  • Whereabouts IPAM CNI プラグインを使用した動的割り当て。

12.2.4.1. 静的 IP アドレス割り当ての設定

以下の表は、静的 IP アドレスの割り当ての設定について説明しています。

表12.6 ipam 静的設定オブジェクト

フィールドタイプ詳細

type

string

IPAM のアドレスタイプ。値 static が必要です。

addresses

array

仮想インターフェースに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。

routes

array

Pod 内で設定するルートを指定するオブジェクトの配列です。

dns

array

オプション: DNS の構成を指定するオブジェクトの配列です。

addressesの配列には、以下のフィールドのあるオブジェクトが必要です。

表12.7 ipam.addresses[] 配列

フィールドタイプ詳細

address

string

指定する IP アドレスおよびネットワークプレフィックス。たとえば、10.10.21.10/24 を指定すると、追加のネットワークに IP アドレスの 10.10.21.10 が割り当てられ、ネットマスクは 255.255.255.0 になります。

gateway

string

egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。

表12.8 ipam.routes[] 配列

フィールドタイプ詳細

dst

string

CIDR 形式の IP アドレス範囲 (192.168.17.0/24、またはデフォルトルートの 0.0.0.0/0)。

gw

string

ネットワークトラフィックがルーティングされるゲートウェイ。

表12.9 ipam.dns オブジェクト

フィールドタイプ詳細

nameservers

array

DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。

domain

array

ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが example.com に設定されている場合、example-host の DNS ルックアップクエリーは example-host.example.com として書き換えられます。

search

array

DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: example-host)。

静的 IP アドレス割り当ての設定例

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7"
        }
      ]
  }
}

12.2.4.2. 動的 IP アドレス (DHCP) 割り当ての設定

以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。

DHCP リースの更新

Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。

DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。

shim ネットワーク割り当ての定義例

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

表12.10 ipam DHCP 設定オブジェクト

フィールドタイプ詳細

type

string

IPAM のアドレスタイプ。値dhcp が必要です。

動的 IP アドレス (DHCP) 割り当ての設定例

{
  "ipam": {
    "type": "dhcp"
  }
}

12.2.4.3. Whereabouts を使用した動的 IP アドレス割り当ての設定

Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。

以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。

表12.11 ipamwhereabouts 設定オブジェクト

フィールドタイプ詳細

type

string

IPAM のアドレスタイプ。値whereaboutsが必要です。

range

string

IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。

exclude

array

オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) の一覧。除外されたアドレス範囲内の IP アドレスは割り当てられません。

Whereabouts を使用する動的 IP アドレス割り当ての設定例

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

12.2.5. Cluster Network Operator による追加ネットワーク割り当ての作成

Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

重要

Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

前提条件

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

手順

  1. CNO 設定を編集するには、以下のコマンドを入力します。

    $ oc edit networks.operator.openshift.io cluster
  2. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      # ...
      additionalNetworks:
      - name: tertiary-net
        namespace: project2
        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"
                }
              ]
            }
          }
  3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

検証

  • 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO がオブジェクトを作成するまでに遅延が生じる可能性があります。

    $ oc get network-attachment-definitions -n <namespace>

    ここで、

    <namespace>
    CNO の構成に追加したネットワーク割り当ての namespace を指定します。

    出力例

    NAME                 AGE
    test-network-1       14m

12.2.6. YAML マニフェストを適用した追加のネットワーク割り当ての作成

前提条件

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

手順

  1. 以下の例のように、追加のネットワーク設定を含む YAML ファイルを作成します。

    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      name: next-net
    spec:
      config: |-
        {
          "cniVersion": "0.3.1",
          "name": "work-network",
          "type": "host-device",
          "device": "eth1",
          "ipam": {
            "type": "dhcp"
          }
        }
  2. 追加のネットワークを作成するには、次のコマンドを入力します。

    $ oc apply -f <file>.yaml

    ここで、

    <file>
    YAML マニフェストを含むファイルの名前を指定します。

12.3. 仮想ルーティングおよび転送について

12.3.1. 仮想ルーティングおよび転送について

VRF (Virtual Routing and Forwarding) デバイスは IP ルールとの組み合わせにより、仮想ルーティングと転送ドメインを作成する機能を提供します。VRF は、CNF で必要なパーミッションの数を減らし、セカンダリーネットワークのネットワークトポロジーの可視性を強化します。VRF はマルチテナンシー機能を提供するために使用されます。たとえば、この場合、各テナントには固有のルーティングテーブルがあり、異なるデフォルトゲートウェイが必要です。

プロセスは、ソケットを VRF デバイスにバインドできます。バインドされたソケット経由のパケットは、VRF デバイスに関連付けられたルーティングテーブルを使用します。VRF の重要な機能として、これは OSI モデルレイヤー 3 以上にのみ影響を与えるため、LLDP などの L2 ツールは影響を受けません。これにより、ポリシーベースのルーティングなどの優先度の高い IP ルールが、特定のトラフィックを転送する VRF デバイスルールよりも優先されます。

12.3.1.1. Telecommunications Operator についての Pod のセカンダリーネットワークの利点

通信のユースケースでは、各 CNF が同じアドレス空間を共有する複数の異なるネットワークに接続される可能性があります。これらのセカンダリーネットワークは、クラスターのメインネットワーク CIDR と競合する可能性があります。CNI VRF プラグインを使用すると、ネットワーク機能は、同じ IP アドレスを使用して異なるユーザーのインフラストラクチャーに接続でき、複数の異なるお客様の分離された状態を維持します。IP アドレスは OpenShift Container Platform の IP スペースと重複します。CNI VRF プラグインは、CNF で必要なパーミッションの数も減らし、セカンダリーネットワークのネットワークトポロジーの可視性を高めます。

12.4. マルチネットワークポリシーの設定

クラスター管理者は、追加のネットワークのネットワークポリシーを設定できます。

注記

macvlan の追加ネットワークのみに対して、マルチネットワークポリシーを指定することができます。ipvlan などの他の追加のネットワークタイプはサポートされていません。

12.4.1. マルチネットワークポリシーとネットワークポリシーの違い

MultiNetworkPolicy API は、NetworkPolicy API を実装していますが、いくつかの重要な違いがあります。

  • 以下の場合は、MultiNetworkPolicy API を使用する必要があります。

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
  • CLI を使用してマルチネットワークポリシーと対話する場合は、multi-networkpolicy リソース名を使用する必要があります。たとえば、oc get multi-networkpolicy <name> コマンドを使用してマルチネットワークポリシーオブジェクトを表示できます。ここで、<name> はマルチネットワークポリシーの名前になります。
  • macvlan 追加ネットワークを定義するネットワーク接続定義の名前でアノテーションを指定する必要があります。

    apiVersion: k8s.cni.cncf.io/v1beta1
    kind: MultiNetworkPolicy
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/policy-for: <network_name>

    ここで、

    <network_name>
    ネットワーク接続定義の名前を指定します。

12.4.2. クラスターのマルチネットワークポリシーの有効化

クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインすること。

手順

  1. 以下の YAML で multinetwork-enable-patch.yaml ファイルを作成します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      useMultiNetworkPolicy: true
  2. マルチネットワークポリシーを有効にするようにクラスターを設定します。

    $ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

    出力例

    network.operator.openshift.io/cluster patched

12.4.3. マルチネットワークポリシーの使用

クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。

12.4.3.1. 前提条件

  • クラスターのマルチネットワークポリシーサポートを有効にしている。

12.4.3.2. マルチネットワークポリシーの作成

マルチネットワークポリシーを作成し、クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義することができます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。
  • マルチネットワークポリシーが適用される namespace で作業していること。

手順

  1. ポリシールールを作成します。

    1. <policy_name>.yaml ファイルを作成します。

      $ touch <policy_name>.yaml

      ここでは、以下のようになります。

      <policy_name>
      マルチネットワークポリシーのファイル名を指定します。
    2. 作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。

      すべての namespace のすべての Pod から ingress を拒否します。

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: deny-by-default
        annotations:
          k8s.v1.cni.cncf.io/policy-for: <network_name>
      spec:
        podSelector:
        ingress: []

      ここでは、以下のようになります。

      <network_name>
      ネットワーク接続定義の名前を指定します。

      同じ namespace のすべての Pod から ingress を許可します。

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-same-namespace
        annotations:
          k8s.v1.cni.cncf.io/policy-for: <network_name>
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}

      ここでは、以下のようになります。

      <network_name>
      ネットワーク接続定義の名前を指定します。
  2. マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。

    $ oc apply -f <policy_name>.yaml -n <namespace>

    ここで、

    <policy_name>
    マルチネットワークポリシーのファイル名を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    multinetworkpolicy.k8s.cni.cncf.io/default-deny created

注記

コンソールで cluster-admin ロールが割り当てられたユーザーでログインした場合に、YAML ビューから直接、または Web コンソールのフォームから、クラスター内の任意の namespace にネットワークポリシーを作成できます。

12.4.3.3. マルチネットワークポリシーの編集

namespace のマルチネットワークポリシーを編集できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  1. オプション: namespace のマルチネットワークポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。

    $ oc get multi-networkpolicy

    ここで、

    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  2. マルチネットワークポリシーオブジェクトを編集します。

    • マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。

      $ oc apply -n <namespace> -f <policy_file>.yaml

      ここで、

      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
      <policy_file>
      ネットワークポリシーを含むファイルの名前を指定します。
    • マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。

      $ oc edit multi-networkpolicy <policy_name> -n <namespace>

      ここで、

      <policy_name>
      ネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  3. マルチネットワークポリシーオブジェクトが更新されていることを確認します。

    $ oc describe multi-networkpolicy <policy_name> -n <namespace>

    ここで、

    <policy_name>
    マルチネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

12.4.3.4. マルチネットワークポリシーの表示

namespace のマルチネットワークポリシーを検査できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  • namespace のマルチネットワークポリシーを一覧表示します。

    • namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。

      $ oc get multi-networkpolicy
    • オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。

      $ oc describe multi-networkpolicy <policy_name> -n <namespace>

      ここで、

      <policy_name>
      検査するマルチネットワークポリシーの名前を指定します。
      <namespace>
      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

12.4.3.5. マルチネットワークポリシーの削除

namespace のマルチネットワークポリシーを削除できます。

前提条件

  • クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用する (例: OVN-Kubernetes ネットワークプロバイダー、または mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしていること。
  • マルチネットワークポリシーが存在する namespace で作業している。

手順

  • マルチネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。

    $ oc delete multi-networkpolicy <policy_name> -n <namespace>

    ここで、

    <policy_name>
    マルチネットワークポリシーの名前を指定します。
    <namespace>
    オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

    出力例

    multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted

12.4.4. 関連情報

12.5. Pod の追加のネットワークへの割り当て

クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。

12.5.1. Pod の追加ネットワークへの追加

Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。

Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。

Pod が追加ネットワークと同じ namespace にあること。

前提条件

  • OpenShift CLI (oc) をインストールします。
  • クラスターにログインする。

手順

  1. アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。

    1. カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。<network> を、Pod に関連付ける追加ネットワークの名前に置き換えます。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
      1
      複数の追加ネットワークを指定するには、各ネットワークをカンマで区切ります。カンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェースをそのネットワークに割り当てます。
    2. カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]
      1
      NetworkAttachmentDefinition オブジェクトによって定義される追加のネットワークの名前を指定します。
      2
      NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。
      3
      オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。
  2. Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。

    $ oc create -f <name>.yaml
  3. オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

    $ oc get pod <name> -o yaml

    以下の例では、example-pod Pod が追加ネットワークの net1 に割り当てられています。

    $ oc get pod example-pod -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: macvlan-bridge
        k8s.v1.cni.cncf.io/networks-status: |- 1
          [{
              "name": "openshift-sdn",
              "interface": "eth0",
              "ips": [
                  "10.128.2.14"
              ],
              "default": true,
              "dns": {}
          },{
              "name": "macvlan-bridge",
              "interface": "net1",
              "ips": [
                  "20.2.2.100"
              ],
              "mac": "22:2f:60:a5:f8:00",
              "dns": {}
          }]
      name: example-pod
      namespace: default
    spec:
      ...
    status:
      ...
    1
    k8s.v1.cni.cncf.io/networks-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。

12.5.1.1. Pod 固有のアドレスおよびルーティングオプションの指定

Pod を追加のネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。

前提条件

  • Pod が追加ネットワークと同じ namespace にあること。
  • OpenShift CLI (oc) をインストールします。
  • クラスターにログインすること。

手順

アドレスおよび/またはルーティングオプションを指定する間に Pod を追加のネットワークに追加するには、以下の手順を実行します。

  1. Pod リソース定義を編集します。既存の Pod リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name> を、編集する Pod リソースの名前に置き換えます。

    $ oc edit pod <name>
  2. Pod リソース定義で、k8s.v1.cni.cncf.io/networks パラメーターを Pod の metadata マッピングに追加します。k8s.v1.cni.cncf.io/networks は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition カスタムリソース (CR) 名を参照するオブジェクト一覧の JSON 文字列を受け入れます。

    metadata:
      annotations:
        k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 1
    1
    <network> を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。
  3. 以下の例では、アノテーションで default-route パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: example-pod
      annotations:
        k8s.v1.cni.cncf.io/networks: '
        {
          "name": "net1"
        },
        {
          "name": "net2", 1
          "default-route": ["192.0.2.1"] 2
        }'
    spec:
      containers:
      - name: example-pod
        command: ["/bin/bash", "-c", "sleep 2000000000000"]
        image: centos/tools
    1
    name キーは、Pod に関連付ける追加ネットワークの名前です。
    2
    default-route キーは、ルーティングテーブルに他のルーティングテーブルがない場合に、ルーティングされるトラフィックに使用されるゲートウェイ値を指定します。複数の default-route キーを指定すると、Pod がアクティブでなくなります。

デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。

重要

OpenShift Container Platform のデフォルトのネットワークインターフェース以外のインターフェースへのデフォルトのルートを設定すると、Pod 間のトラフィックについて予想されるトラフィックが別のインターフェースでルーティングされる可能性があります。

Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。

$ oc exec -it <pod_name> -- ip route
注記

また、Pod の k8s.v1.cni.cncf.io/networks-status を参照して、JSON 形式の一覧のオブジェクトで default-route キーの有無を確認し、デフォルトルートが割り当てられている追加ネットワークを確認することができます。

Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。

  1. 以下のコマンドを実行して CNO CR を編集します。

    $ oc edit networks.operator.openshift.io cluster

以下の YAML は、CNO の設定パラメーターについて説明しています。

Cluster Network Operator YAML の設定

name: <name> 1
namespace: <namespace> 2
rawCNIConfig: '{ 3
  ...
}'
type: Raw

1
作成している追加ネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
2
ネットワークの割り当てを作成する namespace を指定します。値を指定しない場合、default の namespace が使用されます。
3
以下のテンプレートに基づく CNI プラグイン設定を JSON 形式で指定します。

以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターについて説明しています。

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

{
  "cniVersion": "0.3.1",
  "name": "<name>", 1
  "plugins": [{ 2
      "type": "macvlan",
      "capabilities": { "ips": true }, 3
      "master": "eth0", 4
      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true }, 5
      "type": "tuning"
    }]
}

1
作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
2
CNI プラグイン設定の配列を指定します。1 つ目のオブジェクトは、macvlan プラグイン設定を指定し、2 つ目のオブジェクトはチューニングプラグイン設定を指定します。
3
CNI プラグインのランタイム設定機能の静的 IP 機能を有効にするために要求が実行されるように指定します。
4
macvlan プラグインが使用するインターフェースを指定します。
5
CNI プラグインの静的 MAC アドレス機能を有効にするために要求が実行されるように指定します。

上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。

以下を使用して Pod を編集します。

$ oc edit pod <name>

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>", 1
        "ips": [ "192.0.2.205/24" ], 2
        "mac": "CA:FE:C0:FF:EE:00" 3
      }
    ]'

1
上記の rawCNIConfig を作成する際に、指定されるように <name> を使用します。
2
サブネットマスクを含む IP アドレスを指定します。
3
MAC アドレスを指定します。
注記

静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。

追加のネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc コマンドを使用して Pod 内で ip コマンドを実行します。

$ oc exec -it <pod_name> -- ip a

12.6. 追加ネットワークからの Pod の削除

クラスターユーザーとして、追加のネットワークから Pod を削除できます。

12.6.1. 追加ネットワークからの Pod の削除

Pod を削除するだけで、追加のネットワークから Pod を削除できます。

前提条件

  • 追加のネットワークが Pod に割り当てられている。
  • OpenShift CLI (oc) をインストールします。
  • クラスターにログインする。

手順

  • Pod を削除するには、以下のコマンドを入力します。

    $ oc delete pod <name> -n <namespace>
    • <name> は Pod の名前です。
    • <namespace> は Pod が含まれる namespace です。

12.7. 追加ネットワークの編集

クラスター管理者は、既存の追加ネットワークの設定を変更することができます。

12.7.1. 追加ネットワーク割り当て定義の変更

クラスター管理者は、既存の追加ネットワークに変更を加えることができます。追加ネットワークに割り当てられる既存の Pod は更新されません。

前提条件

  • クラスター用に追加のネットワークを設定している。
  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

クラスターの追加ネットワークを編集するには、以下の手順を実行します。

  1. 以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。

    $ oc edit networks.operator.openshift.io cluster
  2. additionalNetworks コレクションで、追加ネットワークを変更内容で更新します。
  3. 変更を保存し、テキストエディターを終了して、変更をコミットします。
  4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを更新していることを確認します。<network-name> を表示する追加ネットワークの名前に置き換えます。CNO が NetworkAttachmentDefinition オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。

    $ oc get network-attachment-definitions <network-name> -o yaml

    たとえば、以下のコンソールの出力は net1 という名前の NetworkAttachmentDefinition オブジェクトを表示します。

    $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
    { "cniVersion": "0.3.1", "type": "macvlan",
    "master": "ens5",
    "mode": "bridge",
    "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

12.8. 追加ネットワークの削除

クラスター管理者は、追加のネットワーク割り当てを削除できます。

12.8.1. 追加ネットワーク割り当て定義の削除

クラスター管理者は、追加ネットワークを OpenShift Container Platform クラスターから削除できます。追加ネットワークは、割り当てられている Pod から削除されません。

前提条件

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

手順

クラスターから追加ネットワークを削除するには、以下の手順を実行します。

  1. 以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。

    $ oc edit networks.operator.openshift.io cluster
  2. 削除しているネットワーク割り当て定義の additionalNetworks コレクションから設定を削除し、CR を変更します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      additionalNetworks: [] 1
    1
    additionalNetworks コレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
  3. 変更を保存し、テキストエディターを終了して、変更をコミットします。
  4. オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。

    $ oc get network-attachment-definition --all-namespaces

12.9. VRF へのセカンダリーネットワークの割り当て

12.9.1. VRF へのセカンダリーネットワークの割り当て

クラスター管理者は、CNI VRF プラグインを使用して、VRF ドメインの追加のネットワークを設定できます。このプラグインにより作成される仮想ネットワークは、指定する物理インターフェースに関連付けられます。

注記

VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE オプションを使用できます。SO_BINDTODEVICE は、渡されるインターフェース名で指定されているデバイスにソケットをバインドします (例: eth1)。SO_BINDTODEVICE を使用するには、アプリケーションに CAP_NET_RAW 機能がある必要があります。

ip vrf exec コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェースに直接バインドします。

12.9.1.1. CNI VRF プラグインを使用した追加のネットワーク割り当ての作成

Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。

注記

Cluster Network Operator が管理する NetworkAttachmentDefinition CR は編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

CNI VRF プラグインで追加のネットワーク割り当てを作成するには、以下の手順を実行します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとして OpenShift クラスターにログインします。

手順

  1. 以下のサンプル CR のように、追加のネットワーク割り当て用の Network カスタムリソース(CR)を作成し、追加ネットワークの rawCNIConfig 設定を挿入します。YAML を additional-network-attachment.yaml ファイルとして保存します。

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
      spec:
      additionalNetworks:
      - name: test-network-1
        namespace: additional-network-1
        type: Raw
        rawCNIConfig: '{
          "cniVersion": "0.3.1",
          "name": "macvlan-vrf",
          "plugins": [  1
          {
            "type": "macvlan",  2
            "master": "eth1",
            "ipam": {
                "type": "static",
                "addresses": [
                {
                    "address": "191.168.1.23/24"
                }
                ]
            }
          },
          {
            "type": "vrf",
            "vrfname": "example-vrf-name",  3
            "table": 1001   4
          }]
        }'
    1
    plugins は一覧である必要があります。一覧の最初の項目は、VRF ネットワークのベースとなるセカンダリーネットワークである必要があります。一覧の 2 つ目の項目は、VRF プラグイン設定です。
    2
    typevrf に設定する必要があります。
    3
    vrfname は、インターフェースが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。
    4
    オプション。table はルーティングテーブル ID です。デフォルトで、tableid パラメーターが使用されます。これが指定されていない場合、CNI は空のルーティングテーブル ID を VRF に割り当てます。
    注記

    VRF は、リソースが netdevice タイプの場合にのみ正常に機能します。

  2. Network リソースを作成します。

    $ oc create -f additional-network-attachment.yaml
  3. 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition CR を作成していることを確認します。<namespace> を、ネットワーク割り当ての設定時に指定した namespace に置き換えます(例: additional-network-1)。

    $ oc get network-attachment-definitions -n <namespace>

    出力例

    NAME                       AGE
    additional-network-1       14m

    注記

    CNO が CR を作成するまでに遅延が生じる可能性があります。

追加の VRF ネットワーク割り当てが正常であることの確認

VRF CNI が正しく設定され、追加のネットワーク割り当てが接続されていることを確認するには、以下を実行します。

  1. VRF CNI を使用するネットワークを作成します。
  2. ネットワークを Pod に割り当てます。
  3. Pod のネットワーク割り当てが VRF の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。

    $ ip vrf show

    出力例

    Name              Table
    -----------------------
    red                 10

  4. VRF インターフェースがセカンダリーインターフェースのマスターであることを確認します。

    $ ip link

    出力例

    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode

第13章 ハードウェアネットワーク

13.1. Single Root I/O Virtualization (SR-IOV) ハードウェアネットワークについて

Single Root I/O Virtualization (SR-IOV) 仕様は、単一デバイスを複数の Pod で共有できる PCI デバイス割り当てタイプの標準です。

SR-IOV を使用すると、準拠したネットワークデバイス (ホストノードで物理機能 (PF) として認識される) を複数の Virtual Function (VF) にセグメント化することができます。VF は他のネットワークデバイスと同様に使用されます。デバイスの SR-IOV ネットワークデバイスドライバーは、VF がコンテナーで公開される方法を判別します。

  • netdevice ドライバー: コンテナーの netns 内の通常のカーネルネットワークデバイス
  • vfio-pci ドライバー: コンテナーにマウントされるキャラクターデバイス

SR-IOV ネットワークデバイスは、ベアメタルまたは Red Hat Open Stack Platform (RHOSP)インフラ上にインストールされた OpenShift Container Platform クラスターにネットワークを追加して、高帯域または低遅延を確保する必要のあるアプリケーションに使用できます。

以下のコマンドを使用して、ノードで SR-IOV を有効にすることができます。

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

13.1.1. SR-IOV ネットワークデバイスを管理するコンポーネント

SR-IOV Network Operator は SR-IOV スタックのコンポーネントを作成し、管理します。以下の機能を実行します。

  • SR-IOV ネットワークデバイスの検出および管理のオーケストレーション
  • SR-IOV Container Network Interface (CNI) の NetworkAttachmentDefinition カスタムリソースの生成
  • SR-IOV ネットワークデバイスプラグインの設定の作成および更新
  • ノード固有の SriovNetworkNodeState カスタムリソースの作成
  • SriovNetworkNodeState カスタムリソースの spec.interfaces フィールドの更新

Operator は以下のコンポーネントをプロビジョニングします。

SR-IOV ネットワーク設定デーモン
SR-IOV Network Operator の起動時にワーカーノードにデプロイされるデーモンセット。デーモンは、クラスターで SR-IOV ネットワークデバイスを検出し、初期化します。
SR-IOV ネットワーク Operator Webhook
Operator カスタムリソースを検証し、未設定フィールドに適切なデフォルト値を設定する動的受付コントローラー Webhook。
SR-IOV Network Resources Injector
SR-IOV VF などのカスタムネットワークリソースの要求および制限のある Kubernetes Pod 仕様のパッチを適用するための機能を提供する動的受付コントローラー Webhook。SR-IOV ネットワークリソースインジェクターは、 Pod 内の最初のコンテナーのみにresourceフィールドを自動的に追加します。
SR-IOV ネットワークデバイスプラグイン
SR-IOV ネットワーク Virtual Function (VF) リソースの検出、公開、割り当てを実行するデバイスプラグイン。デバイスプラグインは、とりわけ物理デバイスでの制限されたリソースの使用を有効にするために Kubernetes で使用されます。デバイスプラグインは Kubernetes スケジューラーにリソースの可用性を認識させるため、スケジューラーはリソースが十分にあるノードで Pod をスケジュールできます。
SR-IOV CNI プラグイン
SR-IOV ネットワークデバイスプラグインから割り当てられる VF インターフェースを直接 Pod に割り当てる CNI プラグイン。
SR-IOV InfiniBand CNI プラグイン
SR-IOV ネットワークデバイスプラグインから割り当てられる InfiniBand (IB) VF インターフェースを直接 Pod に割り当てる CNI プラグイン。
注記

SR-IOV Network Resources Injector および SR-IOV Network Operator Webhook は、デフォルトで有効にされ、defaultSriovOperatorConfig CR を編集して無効にできます。

13.1.1.1. サポートされるプラットフォーム

SR-IOV Network Operator は、以下のプラットフォームに対応しています。

  • ベアメタル
  • Red Hat OpenStack Platform (RHOSP)

13.1.1.2. 対応デバイス

以下のネットワークインターフェースコントローラーは、OpenShift Container Platform でサポートされています。

表13.1 サポート対象のネットワークインターフェースコントローラー

製造元モデルベンダー IDデバイス ID

Broadcom

BCM57414

14e4

16d7

Broadcom

BCM57508

14e4

1750

Intel

X710

8086

1572

Intel

XL710

8086

1583

Intel

XXV710

8086

158b

Intel

E810-CQDA2

8086

1592

Intel

E810-2CQDA2

8086

1592

Intel

E810-XXVDA2

8086

159b

Intel

E810-XXVDA4

8086

1593

Mellanox

MT27700 Family [ConnectX‑4]

15b3

1013

Mellanox

MT27710 Family [ConnectX‑4 Lx]

15b3

1015

Mellanox

MT27800 Family [ConnectX‑5]

15b3

1017

Mellanox

MT28880 Family [ConnectX‑5 Ex]

15b3

1019

Mellanox

MT28908 Family [ConnectX‑6]

15b3

101b

Mellanox

MT28908 Family [ConnectX‑6 Lx]

15b3

101f

注記

サポートされるカードの最新の一覧と互換性のある OpenShift Container Platform バージョンについては、「OpenShift Single Root I/O Virtualization(SR-IOV)および PTP ハードウェアネットワークのサポートマトリックス 」を参照してください。

13.1.1.3. SR-IOV ネットワークデバイスの自動検出

SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。

CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces 一覧は、ノード上のネットワークデバイスについての情報を提供します。

重要

SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。

13.1.1.3.1. SriovNetworkNodeState オブジェクトの例

以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。

SriovNetworkNodeState オブジェクト

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1
name フィールドの値はワーカーノードの名前と同じです。
2
interfaces スタンザには、ワーカーノード上の Operator によって検出されるすべての SR-IOV デバイスの一覧が含まれます。

13.1.1.4. Pod での Virtual Function (VF) の使用例

SR-IOV VF が割り当てられている Pod で、Remote Direct Memory Access (RDMA) または Data Plane Development Kit (DPDK) アプリケーションを実行できます。

以下の例では、RDMA モードで Virtual Function (VF) を使用する Pod を示しています。

RDMA モードを使用する Pod 仕様

apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-rdma-mlnx
spec:
  containers:
  - name: testpmd
    image: <RDMA_image>
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    command: ["sleep", "infinity"]

以下の例は、DPDK モードの VF のある Pod を示しています。

DPDK モードを使用する Pod 仕様

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-dpdk-net
spec:
  containers:
  - name: testpmd
    image: <DPDK_image>
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"]
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
      requests:
        memory: "1Gi"
        cpu: "2"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

13.1.1.5. コンテナーアプリケーションで使用する DPDK ライブラリー

オプションライブラリーapp-netutil は、その Pod 内で実行されるコンテナーから Pod についてのネットワーク情報を収集するための複数の API メソッドを提供します。

このライブラリーは、DPDK (Data Plane Development Kit) モードの SR-IOV Virtual Function (VF) のコンテナーへの統合を支援します。このライブラリーは Golang API と C API の両方を提供します。

現時点で 3 つの API メソッドが実装されています。

GetCPUInfo()
この機能は、コンテナーで利用可能な CPU を判別し、一覧を返します。
GetHugepages()
この機能は、各コンテナーの Pod 仕様で要求される huge page メモリーの量を判別し、値を返します。
GetInterfaces()
この機能は、コンテナーのインターフェースセットを判別し、インターフェースタイプとタイプ固有のデータと共に一覧を返します。戻り値には、インターフェースのタイプと、各インターフェースのタイプ固有のデータが含まれます。

ライブラリーのリポジトリーには、コンテナーイメージ dpdk-app-centos をビルドするためのサンプル Dockerfile が含まれます。コンテナーイメージは、Pod 仕様の環境変数に応じて、l2fwdl3wd または testpmd の DPDK サンプルアプリケーションのいずれかを実行できます。コンテナーイメージは、app-netutil ライブラリーをコンテナーイメージ自体に統合する例を提供します。ライブラリーを init コンテナーに統合することもできます。init コンテナーは必要なデータを収集し、データを既存の DPDK ワークロードに渡すことができます。

13.1.1.6. Downward API の Huge Page リソースの挿入

Pod 仕様に Huge Page のリソース要求または制限が含まれる場合、Network Resources Injector は Downward API フィールドを Pod 仕様に自動的に追加し、Huge Page 情報をコンテナーに提供します。

Network Resources Injector は、podnetinfo という名前のボリュームを追加し、Pod の各コンテナー用に /etc/podnetinfo にマウントされます。ボリュームは Downward API を使用し、Huge Page の要求および制限についてのファイルを追加します。ファイルの命名規則は以下のとおりです。

  • /etc/podnetinfo/hugepages_1G_request_<container-name>
  • /etc/podnetinfo/hugepages_1G_limit_<container-name>
  • /etc/podnetinfo/hugepages_2M_request_<container-name>
  • /etc/podnetinfo/hugepages_2M_limit_<container-name>

直前の一覧で指定されているパスは、app-netutil ライブラリーと互換性があります。デフォルトで、ライブラリーは、/etc/podnetinfo ディレクトリーのリソース情報を検索するように設定されます。Downward API パス項目を手動で指定する選択をする場合、app-netutil ライブラリーは前述の一覧のパスに加えて以下のパスを検索します。

  • /etc/podnetinfo/hugepages_request
  • /etc/podnetinfo/hugepages_limit
  • /etc/podnetinfo/hugepages_1G_request
  • /etc/podnetinfo/hugepages_1G_limit
  • /etc/podnetinfo/hugepages_2M_request
  • /etc/podnetinfo/hugepages_2M_limit

Network Resources Injector が作成できるパスと同様に、前述の一覧のパスの末尾にはオプションで _<container-name> サフィックスを付けることができます。

13.1.2. 次のステップ

13.2. SR-IOV Network Operator のインストール

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。

13.2.1. SR-IOV Network Operator のインストール

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

13.2.1.1. CLI: SR-IOV Network Operator のインストール

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

前提条件

  • SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つアカウント。

手順

  1. openshift-sriov-network-operator namespace を作成するには、以下のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
      annotations:
        workload.openshift.io/allowed: management
    EOF
  2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    EOF
  3. SR-IOV Network Operator にサブスクライブします。

    1. 以下のコマンドを実行して OpenShift Container Platform のメジャーおよびマイナーバージョンを取得します。これは、次の手順の channel の値に必要です。

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)
    2. 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: "${OC_VERSION}"
        name: sriov-network-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

    $ oc get csv -n openshift-sriov-network-operator \
      -o custom-columns=Name:.metadata.name,Phase:.status.phase

    出力例

    Name                                        Phase
    sriov-network-operator.4.9.0-202110121402   Succeeded

13.2.1.2. Web コンソール: SR-IOV Network Operator のインストール

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

注記

CLI を使用して Operator グループを作成する必要があります。

前提条件

  • SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つアカウント。

手順

  1. SR-IOV Network Operator の namespace を作成します。

    1. OpenShift Container Platform Web コンソールで、AdministrationNamespaces をクリックします。
    2. Create Namespace をクリックします。
    3. Name フィールドに openshift-sriov-network-operator を入力し、Create をクリックします。
  2. SR-IOV Network Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
    3. Install Operator ページの A specific namespace on the cluster の下で、openshift-sriov-network-operator を選択します。
    4. Install をクリックします。
  3. SR-IOV Network Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. StatusInstallSucceeded の状態で、SR-IOV Network Operatoropenshift-sriov-network-operator プロジェクトに一覧表示されていることを確認します。

      注記

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

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、openshift-sriov-network-operator プロジェクトで Pod のログを確認します。
      • YAML ファイルのnamespaceを確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーションworkload.openshift.io/allowed=management を Operator namespaceに追加できます。

        $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
        注記

        シングルノード OpenShift (SNO) クラスターの場合には、namespaceにアノテーションworkload.openshift.io/allowed=managementが必要です。

13.2.2. 次のステップ

13.3. SR-IOV Network Operator の設定

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。

13.3.1. SR-IOV Network Operator の設定

重要

通常、SR-IOV Network Operator 設定を変更する必要はありません。デフォルト設定は、ほとんどのユースケースで推奨されます。Operator のデフォルト動作がユースケースと互換性がない場合にのみ、関連する設定を変更する手順を実行します。

SR-IOV Network Operator は SriovOperatorConfig.sriovnetwork.openshift.io CustomResourceDefinition リソースを追加します。Operator は、openshift-sriov-network-operator namespace に default という名前の SriovOperatorConfig カスタムリソース (CR) を自動的に作成します。

注記

default CR には、クラスターの SR-IOV Network Operator 設定が含まれます。Operator 設定を変更するには、この CR を変更する必要があります。

13.3.1.1. SR-IOV Network Operator config カスタムリソース

sriovoperatorconfig カスタムリソースのフィールドは、以下の表で説明されています。

表13.2 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 デーモンセットを有効にするか無効にするかを指定します。デフォルトでは、このフィールドはtrueに設定されています。

spec.enableOperatorWebhook

boolean

Operator Admission Controller の Webhook デーモンセットを有効にするか無効にするかを指定します。デフォルトでは、このフィールドはtrueに設定されています。

spec.logLevel

integer

Operator のログの冗長度を指定します。0に設定すると、基本的なログのみを表示します。2に設定すると、利用可能なすべてのログが表示されます。デフォルトでは、このフィールドは2に設定されています。

13.3.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 は SR-IOV Network Operator によって有効にされ、すべてのコントロールプレーンノードでデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Network Resources Injector Pod の例です。

$ oc get pods -n openshift-sriov-network-operator

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

13.3.1.3. 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 は Operator によって有効にされ、すべてのコントロールプレーンノードでデーモンセットとして実行されます。以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。

$ oc get pods -n openshift-sriov-network-operator

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

13.3.1.4. カスタムノードセレクターについて

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

13.3.1.5. 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> } }'
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableInjector: <value>

13.3.1.6. SR-IOV Network Operator Admission Controller Webhook の無効化または有効化

デフォルトで有効にされている なっている受付コントローラー 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> } }'
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      enableOperatorWebhook: <value>

13.3.1.7. SRIOV Network Config Daemon のカスタム NodeSelector の設定

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

SR-IOV Network Config デーモンがデプロイされるノードを指定するには、以下の手順を実行します。

重要

configDaemonNodeSelector フィールドを更新する際に、SR-IOV Network Config デーモンがそれぞれの選択されたノードに再作成されます。デーモンが再作成されている間、クラスターのユーザーは新規の SR-IOV Network ノードポリシーを適用したり、新規の SR-IOV Pod を作成したりできません。

手順

  • Operator のノードセレクターを更新するには、以下のコマンドを入力します。

    $ oc patch sriovoperatorconfig default --type=json \
      -n openshift-sriov-network-operator \
      --patch '[{
          "op": "replace",
          "path": "/spec/configDaemonNodeSelector",
          "value": {<node_label>}
        }]'

    以下の例のように、<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>

13.3.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 がインストールされていること。

手順

  • disable Drainフィールドをtrueに設定するには、次のコマンドを入力します。

    $ oc patch sriovoperatorconfig default --type=merge \
      -n openshift-sriov-network-operator \
      --patch '{ "spec": { "disableDrain": true } }'
    ヒント

    または、以下の YAML を適用して Operator を更新することもできます。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      disableDrain: true

13.3.2. 次のステップ

13.4. SR-IOV ネットワークデバイスの設定

クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。

13.4.1. SR-IOV ネットワークノード設定オブジェクト

SR-IOV ネットワークノードポリシーを作成して、ノードの SR-IOV ネットワークデバイス設定を指定します。ポリシーの API オブジェクトは sriovnetwork.openshift.io API グループの一部です。

以下の YAML は SR-IOV ネットワークノードポリシーについて説明しています。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  needVhostNet: false 7
  numVfs: <num> 8
  nicSelector: 9
    vendor: "<vendor_code>" 10
    deviceID: "<device_id>" 11
    pfNames: ["<pf_name>", ...] 12
    rootDevices: ["<pci_bus_id>", ...] 13
    netFilter: "<filter_string>" 14
  deviceType: <device_type> 15
  isRdma: false 16
  linkType: <link_type> 17
1
カスタムリソースオブジェクトの名前。
2
SR-IOV Network Operator がインストールされている namespace を指定します。
3
SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
4
ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
5
オプション: 優先度は 0 から 99 までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10 の優先度は 99 よりも高くなります。デフォルト値は 99 です。
6
オプション: Virtual Function (VF) の最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェースコントローラー (NIC) に応じて異なります。
7
オプション: /dev/vhost-net デバイスを Pod にマウントするには、needVhostNettrue に設定します。Data Plane Development Kit(DPDK)と共にマウントされた /dev/vhost-net デバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。
8
SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェースコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 128 よりも大きくすることはできません。
9
NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。

rootDevices を指定する場合、vendordeviceID、または pfName の値も指定する必要があります。pfNames および rootDevices の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。

10
オプション: SR-IOV ネットワークデバイスのベンダーの 16 進数コード。許可される値は 8086 および 15b3 のみになります。
11
オプション: SR-IOV ネットワークデバイスのデバイスの 16 進数コード。たとえば、101b は Mellanox ConnectX-6 デバイスのデバイス ID です。
12
オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
13
オプション: デバイスの PF 用の 1 つ以上の PCI バスアドレスの配列。以下の形式でアドレスを指定します: 0000:02:00.1
14
オプション: プラットフォーム固有のネットワークフィルター。サポートされるプラットフォームは Red Hat OpenStack Platform (RHOSP) のみです。許可される値は、openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx の形式を使用します。xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx を、/var/config/openstack/latest/network_data.json メタデータファイルの値に置き換えます。
15
オプション: Virtual Function (VF) のドライバータイプ。許可される値は netdevice および vfio-pci のみです。デフォルト値は netdevice です。

Mellanox NIC をベアメタルノードの DPDK モードで機能させるには、netdevice ドライバータイプを使用し、isRdmatrue に設定します。

16
オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は false です。

isRdma パラメーターが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。

isRdmatrue に設定し、追加の needVhostNettrue に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。

17
オプション: VF のリンクタイプ。デフォルト値は、イーサネットの場合は eth です。InfiniBand のこの値を ib に変更します。

linkTypeib に設定されている場合、SR-IOV Network Operator Webhook によって isRdmatrue に自動的に設定されます。linkTypeib に設定されている場合、deviceTypevfio-pci に設定できません。

SriovNetworkNodePolicy では linkTypeeth に設定しないでください。デバイスプラグインによって報告される利用可能なデバイスの数が正しくない数になる可能性があるためです。

オプション: ハードウェアオフロードを有効にするには、eSwitchMode フィールドを switchdev に設定する必要があります。

13.4.1.1. SR-IOV ネットワークノードの設定例

以下の例では、InfiniBand デバイスの設定について説明します。

InfiniBand デバイスの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

以下の例では、RHOSP 仮想マシンの SR-IOV ネットワークデバイスの設定について説明します。

仮想マシンの SR-IOV デバイスの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2

1
仮想マシンのノードネットワークポリシーを設定する際に、numVfs フィールドは常に 1 に設定されます。
2
netFilter フィールドは、仮想マシンが RHOSP にデプロイされる際にネットワーク ID を参照する必要があります。netFilter の有効な値は、SriovNetworkNodeState オブジェクトから選択できます。

13.4.1.2. SR-IOV デバイスの Virtual Function (VF) パーティション設定

Virtual Function (VF) を同じ物理機能 (PF) から複数のリソースプールに分割する必要がある場合があります。たとえば、VF の一部をデフォルトドライバーで読み込み、残りの VF を vfio-pci ドライバーで読み込む必要がある場合などです。このようなデプロイメントでは、SriovNetworkNodePolicy カスタムリソース (CR) の pfNames セレクターは、以下の形式を使用してプールの VF の範囲を指定するために使用できます: <pfname>#<first_vf>-<last_vf>

たとえば、以下の YAML は、VF が 2 から 7 まである netpf0 という名前のインターフェースのセレクターを示します。

pfNames: ["netpf0#2-7"]
  • netpf0 は PF インターフェース名です。
  • 2 は、範囲に含まれる最初の VF インデックス (0 ベース)です。
  • 7 は、範囲に含まれる最後の VF インデックス (0 ベース)です。

以下の要件を満たす場合、異なるポリシー CR を使用して同じ PF から VF を選択できます。

  • numVfs の値は、同じ PF を選択するポリシーで同一である必要があります。
  • VF インデックスは、0 から <numVfs>-1 の範囲にある必要があります。たとえば、numVfs8 に設定されているポリシーがある場合、<first_vf> の値は 0 よりも小さくすることはできず、 <last_vf>7 よりも大きくすることはできません。
  • 異なるポリシーの VF の範囲は重複しないようにしてください。
  • <first_vf><last_vf> よりも大きくすることはできません。

以下の例は、SR-IOV デバイスの NIC パーティション設定を示しています。

ポリシー policy-net-1 は、デフォルトの VF ドライバーと共に PF netpf0 の VF 0 が含まれるリソースプール net-1 を定義します。ポリシー policy-net-1-dpdk は、vfio VF ドライバーと共に PF netpf0 の VF 8 から 15 までが含まれるリソースプール net-1-dpdk を定義します。

ポリシー policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

ポリシー policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

13.4.2. SR-IOV ネットワークデバイスの設定

SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。

注記

SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。

設定の変更が適用されるまでに数分かかる場合があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • SR-IOV Network Operator がインストールされていること。
  • ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがあること。
  • SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していないこと。

手順

  1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。
  2. オプション: SR-IOV 対応クラスターノードに SriovNetworkNodePolicy.Spec.NodeSelector のラベルが付けられていない場合は、これらのノードにラベルを付けます。ノードのラベル付けに関する詳細は、「ノードでラベルを更新する方法について」を参照してください。
  1. SriovNetworkNodePolicy オブジェクトを作成します。

    $ oc create -f <name>-sriov-node-network.yaml

    ここで、<name> はこの設定の名前を指定します。

    設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。

  2. SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

13.4.3. SR-IOV 設定のトラブルシューティング

SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。

ノードの状態を