OpenShift Container Platform

TLS セキュリティープロファイルタイプ (Old、Intermediate、または Custom) を指定します。デフォルトは Intermediate です。

選択したタイプに適切なフィールドを指定します。

old: {}
intermediate: {}
custom:

custom タイプには、TLS 暗号のリストと最小許容 TLS バージョンを指定します。

変更を適用するためにファイルを保存します。

検証

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

oc describe IngressController default -n openshift-ingress-operator

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

Copy to Clipboard

Toggle word wrap

出力例

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Name:         default
Namespace:    openshift-ingress-operator
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         IngressController
 ...
Spec:
 ...
  Tls Security Profile:
    Custom:
      Ciphers:
        ECDHE-ECDSA-CHACHA20-POLY1305
        ECDHE-RSA-CHACHA20-POLY1305
        ECDHE-RSA-AES128-GCM-SHA256
        ECDHE-ECDSA-AES128-GCM-SHA256
      Min TLS Version:  VersionTLS11
    Type:               Custom
 ...

Copy to Clipboard

Toggle word wrap

6.3.1.3. 相互 TLS 認証の設定
リンクのコピー

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

clientCA 値が X509v3 証明書失効リスト (CRL) ディストリビューションポイントを指定している場合、Ingress Operator は、提供された各証明書で指定されている HTTP URI X509v3 CRL Distribution Point に基づいて CRL config map をダウンロードおよび管理します。Ingress Controller は、mTLS/TLS ネゴシエーション中にこの config map を使用します。有効な証明書を提供しない要求は拒否されます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
PEM でエンコードされた CA 証明書バンドルがある。
CA バンドルが CRL ディストリビューションポイントを参照する場合は、エンドエンティティーまたはリーフ証明書もクライアント CA バンドルに含める必要があります。この証明書には、RFC 5280 で説明されているとおり、この証明書の CRL Distribution Points に HTTP URI が含まれている必要があります。以下に例を示します。
```
 Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
         Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.example.com/example.crl
```
```
 Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
         Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl.example.com/example.crl
```
Copy to Clipboard Toggle word wrap

手順

openshift-config namespace で、CA バンドルから config map を作成します。
```
oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \
   -n openshift-config
```
```
$ oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \
```
1
```
   -n openshift-config
```
Copy to Clipboard Toggle word wrap
1
ConfigMap データキーは ca-bundle.pem で、data の値は PEM 形式の CA 証明書である必要があります。
openshift-ingress-operator プロジェクトで IngressController リソースを編集します。
```
oc edit IngressController default -n openshift-ingress-operator
```
```
$ oc edit IngressController default -n openshift-ingress-operator
```
Copy to Clipboard Toggle word wrap

spec.clientTLS フィールドおよびサブフィールドを追加して相互 TLS を設定します。

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

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

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

Copy to Clipboard

Toggle word wrap

6.4. デフォルト Ingress Controller の表示
リンクのコピー

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

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

手順

デフォルト Ingress Controller を表示します。

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

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

Copy to Clipboard

Toggle word wrap

6.5. Ingress Operator ステータスの表示
リンクのコピー

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

手順

Ingress Operator ステータスを表示します。
```
oc describe clusteroperators/ingress
```
```
$ oc describe clusteroperators/ingress
```
Copy to Clipboard Toggle word wrap

6.6. Ingress Controller ログの表示
リンクのコピー

Ingress Controller ログを表示できます。

手順

Ingress Controller ログを表示します。

oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

Copy to Clipboard

Toggle word wrap

6.7. Ingress Controller ステータスの表示
リンクのコピー

特定の Ingress Controller のステータスを表示できます。

手順

Ingress Controller のステータスを表示します。

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

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

Copy to Clipboard

Toggle word wrap

6.8. Ingress Controller の設定
リンクのコピー

6.8.1. カスタムデフォルト証明書の設定
リンクのコピー

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

前提条件

PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
証明書が以下の要件を満たしている必要があります。
- 証明書が Ingress ドメインに対して有効化されている必要があります。
- 証明書は拡張を使用して、subjectAltName 拡張を使用して、*.apps.ocp4.example.com などのワイルドカードドメインを指定します。
IngressController CR がなければなりません。デフォルトの CR を使用できます。
```
oc --namespace openshift-ingress-operator get ingresscontrollers
```
```
$ oc --namespace openshift-ingress-operator get ingresscontrollers
```
Copy to Clipboard Toggle word wrap
出力例
```
NAME      AGE
default   10m
```
```
NAME      AGE
default   10m
```
Copy to Clipboard Toggle word wrap

注記

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

手順

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

注記

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

tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。
```
oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
```
```
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
```
Copy to Clipboard Toggle word wrap

IngressController CR を、新規証明書シークレットを参照するように更新します。

oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

Copy to Clipboard

Toggle word wrap

更新が正常に行われていることを確認します。

echo Q |\
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
  openssl x509 -noout -subject -issuer -enddate

$ echo Q |\
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
  openssl x509 -noout -subject -issuer -enddate

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<domain>: クラスターのベースドメイン名を指定します。

出力例

subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM

subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
notAfter=May 10 08:32:45 2022 GM

Copy to Clipboard

Toggle word wrap

ヒント

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

6.8.2. カスタムデフォルト証明書の削除
リンクのコピー

管理者は、使用する Ingress Controller を設定したカスタム証明書を削除できます。

前提条件

cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
OpenShift CLI (oc) がインストールされている。
Ingress Controller のカスタムデフォルト証明書を設定している。

手順

カスタム証明書を削除し、OpenShift Container Platform に同梱されている証明書を復元するには、以下のコマンドを入力します。
```
oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
```
$ oc patch -n openshift-ingress-operator ingresscontrollers/default \
  --type json -p $'- op: remove\n  path: /spec/defaultCertificate'
```
Copy to Clipboard Toggle word wrap
クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。

検証

元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。

echo Q | \
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -enddate

$ echo Q | \
  openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -enddate

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<domain>: クラスターのベースドメイン名を指定します。

出力例

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

subject=CN = *.apps.<domain>
issuer=CN = ingress-operator@1620633373
notAfter=May 10 10:44:36 2023 GMT

Copy to Clipboard

Toggle word wrap

6.8.3. Ingress Controller のスケーリング
リンクのコピー

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

注記

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

手順

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

Copy to Clipboard

Toggle word wrap

oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。
```
oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
```
```
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
```
Copy to Clipboard Toggle word wrap
出力例
```
ingresscontroller.operator.openshift.io/default patched
```
```
ingresscontroller.operator.openshift.io/default patched
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

Copy to Clipboard

Toggle word wrap

ヒント

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

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 3

1

Copy to Clipboard

Toggle word wrap

1: 異なる数のレプリカが必要な場合は replicas 値を変更します。

6.8.4. Ingress アクセスロギングの設定
リンクのコピー

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

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

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

前提条件

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

手順

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

Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container spec.logging.access.destination.type を指定する必要があります。以下の例は、コンテナー Container の宛先に対してログ記録する Ingress Controller 定義です。
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Container
```
Copy to Clipboard Toggle word wrap

Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に logs という名前のコンテナーを作成します。

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

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

Copy to Clipboard

Toggle word wrap

出力例

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

Copy to Clipboard

Toggle word wrap

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

Ingress アクセスロギングを設定するには、spec.logging.access.destination を使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、spec.logging.access.destination.type に Syslog を指定する必要があります。宛先タイプが Syslog の場合、spec.logging.access.destination.syslog.endpoint を使用して宛先エンドポイントも指定する必要があります。また、spec.logging.access.destination.syslog.facility を使用してファシリティーを指定できます。以下の例は、Syslog 宛先に対してログを記録する Ingress Controller の定義です。
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
```
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
```
Copy to Clipboard Toggle word wrap
注記
syslog 宛先ポートは UDP である必要があります。

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

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

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access:
      destination:
        type: Syslog
        syslog:
          address: 1.2.3.4
          port: 10514
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

Copy to Clipboard

Toggle word wrap

Ingress アクセスロギングを無効にします。

Ingress アクセスロギングを無効にするには、spec.logging または spec.logging.access を空のままにします。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  logging:
    access: null

Copy to Clipboard

Toggle word wrap

6.8.5. Ingress Controller スレッド数の設定
リンクのコピー

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

前提条件

以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

Ingress Controller を更新して、スレッド数を増やします。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'
```
Copy to Clipboard Toggle word wrap
注記
大量のリソースを実行できるノードがある場合、spec.nodePlacement.nodeSelector を、意図されているノードの容量に一致するラベルで設定し、spec.tuningOptions.threadCount を随時高い値に設定します。

6.8.6. 内部ロードバランサーを使用するための Ingress Controller の設定
リンクのコピー

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

警告

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

重要

IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。

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

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 権限を持つユーザーとしてログインしている。

手順

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

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name> 
spec:
  domain: <domain> 
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: <name>

1


spec:
  domain: <domain>

2


  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

3

Copy to Clipboard

Toggle word wrap

1: <name> を IngressController オブジェクトの名前に置き換えます。
2: コントローラーによって公開されるアプリケーションの ドメイン を指定します。
3: 内部ロードバランサーを使用するために Internal の値を指定します。

以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。
```
oc create -f <name>-ingress-controller.yaml
```
```
$ oc create -f <name>-ingress-controller.yaml 
```
1
Copy to Clipboard Toggle word wrap
1
<name> を IngressController オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。
```
oc --all-namespaces=true get ingresscontrollers
```
```
$ oc --all-namespaces=true get ingresscontrollers
```
Copy to Clipboard Toggle word wrap

6.8.7. GCP での Ingress Controller のグローバルアクセスの設定
リンクのコピー

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

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

前提条件

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

手順

グローバルアクセスを許可するように Ingress Controller リソースを設定します。

注記

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

Ingress Controller リソースを設定します。

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to Clipboard

Toggle word wrap

YAML ファイルを編集します。

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

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

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global

1


          type: GCP
        scope: Internal
      type: LoadBalancerService

Copy to Clipboard

Toggle word wrap

1: gcp.clientAccess を Global に設定します。

変更を適用するためにファイルを保存します。

以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。
```
oc -n openshift-ingress edit svc/router-default -o yaml
```
```
$ oc -n openshift-ingress edit svc/router-default -o yaml
```
Copy to Clipboard Toggle word wrap
この出力では、グローバルアクセスがアノテーション networking.gke.io/internal-load-balancer-allow-global-access で GCP について有効にされていることを示しています。

6.8.8. Ingress Controller のヘルスチェック間隔の設定
リンクのコピー

クラスター管理者は、ヘルスチェックの間隔を設定して、ルーターが連続する 2 回のヘルスチェックの間で待機する時間を定義できます。この値は、すべてのルートのデフォルトとしてグローバルに適用されます。デフォルト値は 5 秒です。

前提条件

以下では、Ingress Controller がすでに作成されていることを前提とします。

手順

Ingress Controller を更新して、バックエンドヘルスチェックの間隔を変更します。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'
```
Copy to Clipboard Toggle word wrap
注記
単一ルートの healthCheckInterval をオーバーライドするには、ルートアノテーション router.openshift.io/haproxy.health.check.interval を使用します

6.8.9. クラスターを内部に配置するためのデフォルト Ingress Controller の設定
リンクのコピー

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

警告

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

重要

IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。

前提条件

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

手順

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

oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF

$ oc replace --force --wait --filename - <<EOF
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: default
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal
EOF

Copy to Clipboard

Toggle word wrap

6.8.10. ルートの受付ポリシーの設定
リンクのコピー

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

警告

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

前提条件

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

手順

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

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

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

Copy to Clipboard

Toggle word wrap

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

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

Copy to Clipboard

Toggle word wrap

ヒント

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

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

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

Copy to Clipboard

Toggle word wrap

6.8.11. ワイルドカードルートの使用
リンクのコピー

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

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

手順

ワイルドカードポリシーを設定します。
1. 以下のコマンドを使用して IngressController リソースを編集します。
  $ oc edit IngressController
  Copy to Clipboard Toggle word wrap
2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。
  spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
  Copy to Clipboard Toggle word wrap

6.8.12. X-Forwarded ヘッダーの使用
リンクのコピー

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

手順

Ingress Controller 用に HTTPHeaders フィールドを設定します。

以下のコマンドを使用して IngressController リソースを編集します。
```
oc edit IngressController
```
```
$ oc edit IngressController
```
Copy to Clipboard Toggle word wrap

spec の下で、HTTPHeaders ポリシーフィールドを Append、Replace、IfNone、または Never に設定します。

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

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

Copy to Clipboard

Toggle word wrap

使用例

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

Ingress Controller に転送する前に、X-Forwarded-For ヘッダーを各リクエストに挿入する外部プロキシーを設定します。
ヘッダーを変更せずに渡すように Ingress Controller を設定するには、never ポリシーを指定します。これにより、Ingress Controller はヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。
外部プロキシーが外部クラスター要求を設定する X-Forwarded-For ヘッダーを変更せずに渡すように Ingress Controller を設定します。
外部プロキシーを通過しない内部クラスター要求に X-Forwarded-For ヘッダーを設定するように Ingress Controller を設定するには、if-none ポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress Controller はこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress Controller はヘッダーを追加します。

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

X-Forwarded-For ヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。
他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress Controller を設定するには、アプリケーションの Route にアノテーション haproxy.router.openshift.io/set-forwarded-headers: if-none または haproxy.router.openshift.io/set-forwarded-headers: never を追加します。
注記
Ingress Controller のグローバルに設定された値とは別に、haproxy.router.openshift.io/set-forwarded-headers アノテーションをルートごとに設定できます。

6.8.13. HTTP/2 Ingress 接続の有効化
リンクのコピー

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

個別の Ingress Controller またはクラスター全体について、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 ルートでは使用できません。

警告

再暗号化ルートで WebSocket を使用し、Ingress Controller で HTTP/2 を有効にするには、HTTP/2 を介した WebSocket のサポートが必要です。HTTP/2 上の WebSockets は HAProxy 2.4 の機能であり、現時点では OpenShift Container Platform ではサポートされていません。

重要

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

手順

単一 Ingress Controller で HTTP/2 を有効にします。

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

ヒント

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

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

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

Copy to Clipboard

Toggle word wrap

6.8.14. Ingress Controller の PROXY プロトコルの設定
リンクのコピー

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

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

重要

PROXY プロトコルまたは TCP を使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。

警告

PROXY プロトコルは、Keepalived Ingress VIP を使用するクラウド以外のプラットフォーム上のインストーラーによってプロビジョニングされたクラスターを使用するデフォルトの Ingress Controller ではサポートされていません。

前提条件

Ingress Controller を作成している。

手順

Ingress Controller リソースを編集します。

oc -n openshift-ingress-operator edit ingresscontroller/default

$ oc -n openshift-ingress-operator edit ingresscontroller/default

Copy to Clipboard

Toggle word wrap

PROXY 設定を設定します。
- Ingress Controller が hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。
  PROXY への hostNetwork の設定例
  spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork
  
  Copy to Clipboard Toggle word wrap
- Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。
  PROXY へのサンプル nodePort 設定
  spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService
  
  Copy to Clipboard Toggle word wrap

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

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

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

前提条件

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

手順

ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。
1. Ingress cluster リソースを編集します。
  $ oc edit ingresses.config/cluster -o yaml
  Copy to Clipboard Toggle word wrap
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
  
  Copy to Clipboard Toggle word wrap
  1
  デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。
  2
  オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。
注記
ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。
1. ルートを公開します。
  $ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed
  Copy to Clipboard Toggle word wrap
  出力例:
  $ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp None
  
  Copy to Clipboard Toggle word wrap

6.8.16. HTTP ヘッダーケースの変換
リンクのコピー

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

重要

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

前提条件

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

手順

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

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

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

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

Copy to Clipboard

Toggle word wrap

アプリケーションのルートにアノテーションを付けます。
```
oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
```
$ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true
```
Copy to Clipboard Toggle word wrap
次に、Ingress Controller は host 要求ヘッダーを指定どおりに調整します。

Ingress Controller の YAML ファイルを設定し、HeaderNameCaseAdjustments フィールドを使用して調整を指定します。

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

Ingress Controller YAML のサンプル

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

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

Copy to Clipboard

Toggle word wrap

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

ルート YAML のサンプル

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

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/h1-adjust-case: true

1


  name: my-application
  namespace: my-application
spec:
  to:
    kind: Service
    name: my-application

Copy to Clipboard

Toggle word wrap

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

6.8.17. ルーター圧縮の使用
リンクのコピー

特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または X-で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341を参照してください。

注記

圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。

すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。

手順

Ingress Controller のhttpCompressionフィールドを設定します。

以下のコマンドを使用して IngressController リソースを編集します。
```
oc edit -n openshift-ingress-operator ingresscontrollers/default
```
```
$ oc edit -n openshift-ingress-operator ingresscontrollers/default
```
Copy to Clipboard Toggle word wrap

specで、 httpCompression ポリシーフィールドをmimeTypes に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpCompression:
    mimeTypes:
    - "text/html"
    - "text/css; charset=utf-8"
    - "application/json"
   ...

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  httpCompression:
    mimeTypes:
    - "text/html"
    - "text/css; charset=utf-8"
    - "application/json"
   ...

Copy to Clipboard

Toggle word wrap

6.8.18. ルーターメトリクスの公開
リンクのコピー

デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。

前提条件

ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。

手順

次のコマンドを実行して、ルーター Pod 名を取得します。

oc get pods -n openshift-ingress

$ oc get pods -n openshift-ingress

Copy to Clipboard

Toggle word wrap

出力例

NAME                              READY   STATUS    RESTARTS   AGE
router-default-76bfffb66c-46qwp   1/1     Running   0          11h

NAME                              READY   STATUS    RESTARTS   AGE
router-default-76bfffb66c-46qwp   1/1     Running   0          11h

Copy to Clipboard

Toggle word wrap

ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。
1. 次のコマンドを実行して、ユーザー名を取得します。
  $ oc rsh <router_pod_name> cat metrics-auth/statsUsername
  Copy to Clipboard Toggle word wrap
2. 次のコマンドを実行して、パスワードを取得します。
  $ oc rsh <router_pod_name> cat metrics-auth/statsPassword
  Copy to Clipboard Toggle word wrap
次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。
```
oc describe pod <router_pod>
```
```
$ oc describe pod <router_pod>
```
Copy to Clipboard Toggle word wrap
つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。
```
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
```
```
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、安全にメトリクスにアクセスします。
```
curl -u user:password https://<router_IP>:<stats_port>/metrics -k
```
```
$ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。
```
curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
```
```
$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
```
Copy to Clipboard Toggle word wrap
例6.1 出力例
… # HELP haproxy_backend_connections_total Total number of connections. # TYPE haproxy_backend_connections_total gauge haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0 … # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value. # TYPE haproxy_exporter_server_threshold gauge haproxy_exporter_server_threshold{type="current"} 11 haproxy_exporter_server_threshold{type="limit"} 500 … # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes. # TYPE haproxy_frontend_bytes_in_total gauge haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0 haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0 haproxy_frontend_bytes_in_total{frontend="public"} 119070 … # HELP haproxy_server_bytes_in_total Current total of incoming bytes. # TYPE haproxy_server_bytes_in_total gauge haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0 haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0 …
ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。
```
http://<user>:<password>@<router_IP>:<stats_port>
```
```
http://<user>:<password>@<router_IP>:<stats_port>
```
Copy to Clipboard Toggle word wrap
オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。
```
http://<user>:<password>@<router_ip>:1936/metrics;csv
```
```
http://<user>:<password>@<router_ip>:1936/metrics;csv
```
Copy to Clipboard Toggle word wrap

6.8.19. HAProxy エラーコードの応答ページのカスタマイズ
リンクのコピー

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

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

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

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

注記

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

手順

openshift-config に my-custom-error-code-pages という名前の ConfigMap を作成します。
```
oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
```
$ oc -n openshift-config create configmap my-custom-error-code-pages \
--from-file=error-page-503.http \
--from-file=error-page-404.http
```
Copy to Clipboard Toggle word wrap
重要
カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、ConfigMap を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。
Ingress Controller にパッチを適用し、名前を指定して my-custom-error-code-pages ConfigMap を参照します。
```
oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
```
```
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
```
Copy to Clipboard Toggle word wrap
Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages ConfigMap をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って ConfigMap に名前を付けます。
コピーを表示します。
```
oc get cm default-errorpages -n openshift-ingress
```
```
$ oc get cm default-errorpages -n openshift-ingress
```
Copy to Clipboard Toggle word wrap
出力例
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
```
NAME                       DATA   AGE
default-errorpages         2      25s  
```
1
Copy to Clipboard Toggle word wrap
1
default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、ConfigMap 名の例は default-errorpages です。
カスタムエラー応答ページを含む ConfigMap がルーターボリュームにマウントされることを確認します。ConfigMap キーは、カスタム HTTP エラーコード応答を持つファイル名です。
- 503 カスタム HTTP カスタムエラーコード応答の場合:
  $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
  Copy to Clipboard Toggle word wrap
- 404 カスタム HTTP カスタムエラーコード応答の場合:
  $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
  Copy to Clipboard Toggle word wrap

検証

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

テストプロジェクトおよびアプリケーションを作成します。
```
oc new-project test-ingress
```
```
 $ oc new-project test-ingress
```
Copy to Clipboard Toggle word wrap
```
oc new-app django-psql-example
```
```
$ oc new-app django-psql-example
```
Copy to Clipboard Toggle word wrap
503 カスタム http エラーコード応答の場合:
1. アプリケーションのすべての Pod を停止します。
2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
  $ curl -vk <route_hostname>
  Copy to Clipboard Toggle word wrap
404 カスタム http エラーコード応答の場合:
1. 存在しないルートまたは正しくないルートにアクセスします。
2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。
  $ curl -vk <route_hostname>
  Copy to Clipboard Toggle word wrap

errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。

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

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

Copy to Clipboard

Toggle word wrap

6.8.20. Ingress Controller の最大接続数の設定
リンクのコピー

クラスター管理者は、OpenShift ルーターデプロイメントの同時接続の最大数を設定できます。既存の Ingress Controller にパッチを適用して、接続の最大数を増やすことができます。

前提条件

以下では、Ingress Controller が作成済みであることを前提とします。

手順

Ingress Controller を更新して、HAProxy の最大接続数を変更します。
```
oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
```
$ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'
```
Copy to Clipboard Toggle word wrap
警告
spec.tuningOptions.maxConnections の値を現在のオペレーティングシステムの制限よりも大きく設定すると、HAProxy プロセスは開始しません。このパラメーターの詳細は、Ingress Controller 設定パラメーターセクションの表を参照してください。

第7章 OpenShift Container Platform での Ingress シャーディング
リンクのコピー

OpenShift Container Platform では、Ingress Controller はすべてのルートを提供することも、ルートのサブセットを提供することもできます。デフォルトでは、Ingress Controller は、クラスター内の任意の namespace で作成されたすべてのルートを提供します。別の Ingress Controller をクラスターに追加して、選択した特性に基づくルートのサブセットである シャード を作成することにより、ルーティングを最適化できます。ルートをシャードのメンバーとしてマークするには、ルートまたは namespace の メタデータ フィールドでラベルを使用します。Ingress Controller は、選択式 とも呼ばれる セレクター を使用して、ルートのプール全体からルートのサブセットを選択し、サービスを提供します。

Ingress シャーディングは、受信トラフィックを複数の Ingress Controller 間で負荷分散する場合に、トラフィックを分離して特定の Ingress Controller にルーティングする場合、または次のセクションで説明する他のさまざまな理由で役立ちます。

デフォルトでは、各ルートはクラスターのデフォルトドメインを使用します。ただし、代わりにルーターのドメインを使用するようにルートを設定できます。詳細は Ingress Controller シャーディングのルートの作成を参照してください。

7.1. Ingress Controller のシャード化
リンクのコピー

Ingress シャーディング (ルーターシャーディングとも呼ばれます) を使用して、ルート、namespace、またはその両方にラベルを追加することで、一連のルートを複数のルーターに分散できます。Ingress Controller は、対応する一連のセレクターを使用して、指定されたラベルが含まれるルートのみを許可します。各 Ingress シャードは、特定の選択式を使用してフィルタリングされたルートで設定されます。

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

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

Ingress Controller がシャーディングされると、特定のルートがグループ内の 0 個以上の Ingress Controller に受け入れられます。ルートのステータスは、Ingress Controller がルートを受け入れたかどうかを示します。Ingress Controller は、ルートがそのシャードに固有である場合にのみルートを受け入れます。

Ingress Controller は、次の 3 つのシャーディング方法を使用できます。

namespace セレクターとラベルが同じ namespace 内のすべてのルートが Ingress シャードに含まれるように、namespace セレクターのみを Ingress Controller に追加します。
Ingress Controller にルートセレクターのみを追加して、ルートセレクターとラベルが同じ全ルートが Ingress シャードに含まれるようにします。
namespace セレクターとラベルが同じ namespace 内のルートセレクターのラベルがルートと同じ場合に、Ingress シャード内に含まれるように、namespace セレクターとルートセレクターの両方を Ingress Controller に追加します。

シャーディングを使用すると、ルートのサブセットを複数の Ingress Controller に分散できます。これらのサブセットは、重複なし (従来のシャーディングとも呼ばれる) にすることも、重複 (重複シャーディングとも呼ばれる) にすることもできます。

7.1.1. 従来のシャーディングの例
リンクのコピー

Ingress Controller の finops-router は、ラベルセレクター spec.namespaceSelector.matchLabels.name を finance および ops に指定して設定されます。

finops-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - finance
        - ops

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: finops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - finance
        - ops

Copy to Clipboard

Toggle word wrap

2 番目の Ingress Controller dev-router は、ラベルセレクター spec.namespaceSelector.matchLabels.name を dev に指定して設定されます。

dev-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: dev-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name: dev

Copy to Clipboard

Toggle word wrap

すべてのアプリケーションルートが個別の namespace にあり、それぞれに name:finance、name:ops、および name:dev というラベルが付けられている場合、この設定は 2 つの Ingress Controller 間でルートを効果的に分散します。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。

上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。

警告

デフォルト の Ingress Controller は、namespaceSelector または routeSelector フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress Controller からルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューションと「デフォルトの Ingress Controller のシャーディング」のセクションを参照してください。

7.1.2. 重複シャーディングの例
リンクのコピー

上記の例の finops-router と dev-router に加えて、ラベルセレクター spec.namespaceSelector.matchLabels.name を dev と ops に指定して設定された devops-router もあります。

Devops-router の YAML 定義の例

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - dev
        - ops

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: devops-router
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchLabels:
      name:
        - dev
        - ops

Copy to Clipboard

Toggle word wrap

name:dev および name:ops という 名前の namespace のルートは、2 つの異なる Ingress Controller によって処理されるようになりました。この設定では、ルートのサブセットが重複しています。

重複するルートのサブセットを使用すると、より複雑なルーティングルールを作成できます。たとえば、優先度の低いトラフィックを devops-router に送信しながら、優先度の高いトラフィックを専用の finops-router に迂回させることができます。

7.1.3. デフォルトの Ingress Controller のシャーディング
リンクのコピー

新しい Ingress シャードを作成した後に、デフォルトの Ingress Controller と、新しい Ingress シャードの両方により許可されるルートが存在する場合があります。これは、デフォルトの Ingress Controller にセレクターがなく、デフォルトですべてのルートを許可するためです。

namespace セレクターまたはルートセレクターを使用して、Ingress Controller が特定のラベルが割り当てられたルートの処理を制限できます。次の手順では、namespace セレクターを使用して、デフォルトの Ingress Controller が新しく分割された finance、ops、および dev ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。

重要

OpenShift Container Platform のすべての管理ルートを同じ Ingress Controller で保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトのIngress Controller に追加することは避けてください。

前提条件

OpenShift CLI (oc) がインストールされている。
プロジェクト管理者としてログインしている。

手順

次のコマンドを実行して、デフォルトのIngress Controller を変更します。
```
oc edit ingresscontroller -n openshift-ingress-operator default
```
```
$ oc edit ingresscontroller -n openshift-ingress-operator default
```
Copy to Clipboard Toggle word wrap

Ingress Controller を編集して、finance、ops、および dev ラベルのいずれかを持つルートを除外する namespaceSelector を含めます。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
      - key: type
        operator: NotIn
        values:
          - finance
          - ops
          - dev

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  namespaceSelector:
    matchExpressions:
      - key: type
        operator: NotIn
        values:
          - finance
          - ops
          - dev

Copy to Clipboard

Toggle word wrap

デフォルトの Ingress Controller では、name:finance、name:ops、および name:dev という名前の namespace が提供されなくなります。

7.1.4. Ingress シャーディングと DNS
リンクのコピー

クラスター管理者は、プロジェクト内のルーターごとに個別の DNS エントリーを作成します。ルーターは不明なルートを別のルーターに転送することはありません。

以下の例を考慮してください。

Router A はホスト 192.168.0.5 にあり、*.foo.com のルートを持つ。
Router B はホスト 192.168.1.9 にあり、*.example.com のルートを持つ。

個別の DNS エントリーは、*.foo.com をルーター A をホストするノードに解決し、*.example.com をルーター B をホストするノードに解決する必要があります。

*.foo.com A IN 192.168.0.5
*.example.com A IN 192.168.1.9

7.1.5. ルートラベルを使用した Ingress Controller のシャード化の設定
リンクのコピー

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

図7.1 ルートラベルを使用した Ingress シャーディング

ルートの所属先の namespace に関係なく、特定のルートと一致するラベルが含まれるルートにサービスを提供するさまざまなルートセレクターと複数の Ingress Controller を示す図

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

手順

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

cat router-internal.yaml
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

# cat router-internal.yaml
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net>

1


  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  routeSelector:
    matchLabels:
      type: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。

Ingress Controller の router-internal.yaml ファイルを適用します。
```
oc apply -f router-internal.yaml
```
```
# oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
Ingress Controller は、type: sharded というラベルのある namespace のルートを選択します。

router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

Copy to Clipboard

Toggle word wrap

7.1.6. namespace ラベルを使用した Ingress Controller のシャード化の設定
リンクのコピー

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

図7.2 namespace ラベルを使用した Ingress シャーディング

指定の namespace セレクターと同じラベルが含まれる namespace に所属するルートにサービスを提供するさまざまな namespace セレクターと複数の Ingress Controller を示す図

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

手順

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

cat router-internal.yaml

# cat router-internal.yaml

Copy to Clipboard

Toggle word wrap

出力例

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

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded
  namespace: openshift-ingress-operator
spec:
  domain: <apps-sharded.basedomain.example.net>

1


  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/worker: ""
  namespaceSelector:
    matchLabels:
      type: sharded

Copy to Clipboard

Toggle word wrap

1: Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。

Ingress Controller の router-internal.yaml ファイルを適用します。
```
oc apply -f router-internal.yaml
```
```
# oc apply -f router-internal.yaml
```
Copy to Clipboard Toggle word wrap
Ingress Controller は、type: sharded というラベルのある namespace セレクターによって選択される namespace のルートを選択します。

router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

Copy to Clipboard

Toggle word wrap

7.2. Ingress Controller シャーディングのルート作成
リンクのコピー

ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。

以下の手順では、例として hello-openshift アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法について説明します。

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

前提条件

OpenShift CLI (oc) がインストールされている。
プロジェクト管理者としてログインしている。
あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
シャーディング用に Ingress Controller を設定している。

手順

次のコマンドを実行して、hello-openshift というプロジェクトを作成します。
```
oc new-project hello-openshift
```
```
$ oc new-project hello-openshift
```
Copy to Clipboard Toggle word wrap

以下のコマンドを実行してプロジェクトに Pod を作成します。

oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、hello-openshift というサービスを作成します。
```
oc expose pod/hello-openshift
```
```
$ oc expose pod/hello-openshift
```
Copy to Clipboard Toggle word wrap
hello-openshift-route.yaml というルート定義を作成します。
シャーディング用に作成されたルートの YAML 定義:
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
```
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 
```
1
```
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 
```
2
```
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
```
Copy to Clipboard Toggle word wrap
1
ラベルキーとそれに対応するラベル値の両方が、Ingress Controller で指定されたものと一致する必要があります。この例では、Ingress Controller にはラベルキーと値 type: sharded があります。
2
ルートは、subdomain フィールドの値を使用して公開されます。subdomain フィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。host フィールドと subdomain フィールドの両方を指定すると、ルートは host フィールドの値を使用し、subdomain フィールドを無視します。
次のコマンドを実行し、hello-openshift-route.yaml を使用して hello-openshift アプリケーションへのルートを作成します。
```
oc -n hello-openshift create -f hello-openshift-route.yaml
```
```
$ oc -n hello-openshift create -f hello-openshift-route.yaml
```
Copy to Clipboard Toggle word wrap

検証

次のコマンドを使用して、ルートのステータスを取得します。

oc -n hello-openshift get routes/hello-openshift-edge -o yaml

$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

Copy to Clipboard

Toggle word wrap

結果の Route リソースは次のようになります。

出力例

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 
    routerName: sharded

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net>

1


    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net>

2


    routerName: sharded

3

Copy to Clipboard

Toggle word wrap

1: Ingress Controller またはルーターがルートを公開するために使用するホスト名。host フィールドの値は、Ingress Controller によって自動的に決定され、そのドメインを使用します。この例では、Ingress Controller のドメインは <apps-sharded.basedomain.example.net> です。
2: Ingress Controller のホスト名。
3: Ingress Controller の名前。この例では、Ingress Controller の名前は sharded です。

第8章 Ingress Controller エンドポイント公開戦略の設定
リンクのコピー

8.1. Ingress Controller エンドポイントの公開ストラテジー
リンクのコピー

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

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

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

図8.1 NodePortService の図

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

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

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

注記

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

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

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

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

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

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

8.1.1. Ingress Controller エンドポイント公開スコープの内部への設定
リンクのコピー

クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeがExternalに設定されたデフォルトの Ingress Controller が作成されます。クラスター管理者は、External スコープの Ingress Controller をInternalに変更できます。

前提条件

oc CLI をインストールしていること。

手順

Externalスコープの Ingress Controller をInternalに変更するには、次のコマンドを入力します。

oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'

Copy to Clipboard

Toggle word wrap

Ingress Controller のステータスを確認するには、次のコマンドを入力します。
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- ステータス状態が Progressing の場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  サービスを削除すると、Ingress Operator はサービスをInternalとして再作成します。

8.1.2. Ingress Controller エンドポイント公開スコープの外部への設定
リンクのコピー

クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeがExternalに設定されたデフォルトの Ingress Controller が作成されます。

Ingress Controller のスコープは、インストール中またはインストール後にInternalになるように設定でき、クラスター管理者はInternal の Ingress Controller をExternalに変更できます。

重要

一部のプラットフォームでは、サービスを削除して再作成する必要があります。

スコープを変更すると、場合によっては数分間、Ingress トラフィックが中断される可能性があります。これが該当するのは、サービスを削除して再作成する必要があるプラットフォームです。理由は、この手順により、OpenShift Container Platform が既存のサービスロードバランサーのプロビジョニングを解除して新しいサービスロードバランサーをプロビジョニングし、DNS を更新する可能性があるためです。

前提条件

oc CLI をインストールしていること。

手順

Internalスコープの入力コントローラーをExternalに変更するには、次のコマンドを入力します。

oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'

Copy to Clipboard

Toggle word wrap

Ingress Controller のステータスを確認するには、次のコマンドを入力します。
```
oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
```
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
```
Copy to Clipboard Toggle word wrap
- ステータス状態が Progressing の場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。
  $ oc -n openshift-ingress delete services/router-default
  Copy to Clipboard Toggle word wrap
  サービスを削除すると、Ingress Operator はサービスをExternalとして再作成します。

第9章エンドポイントへの接続の確認
リンクのコピー

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

9.1. 実行する接続ヘルスチェック
リンクのコピー

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

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

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

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

9.2. 接続ヘルスチェックの実装
リンクのコピー

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

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

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

9.3. PodNetworkConnectivityCheck オブジェクトフィールド
リンクのコピー

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

Expand

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

Expand

表9.2 status.conditions
フィールド	型	説明
`lastTransitionTime`	`string`	接続の条件がある状態から別の状態に移行した時間。
`message`	`string`	人が判読できる形式の最後の移行についての詳細。
`reason`	`string`	マシンの読み取り可能な形式での移行の最後のステータス。
`status`	`string`	状態のテータス。
`type`	`string`	状態のタイプ。

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

Expand

表9.3 status.outages
フィールド	型	説明
`end`	`string`	接続の障害が解決された時点からのタイムスタンプ。
`endLogs`	`array`	接続ログエントリー (停止の正常な終了に関連するログエントリーを含む)。
`message`	`string`	人が判読できる形式の停止について詳細情報の要約。
`start`	`string`	接続の障害が最初に検知された時点からのタイムスタンプ。
`startLogs`	`array`	元の障害を含む接続ログのエントリー。

接続ログフィールド

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

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

Expand

表9.4 接続ログオブジェクト
フィールド	型	説明
`latency`	`string`	アクションの期間を記録します。
`message`	`string`	ステータスを人が判読できる形式で提供します。
`reason`	`string`	ステータスの理由をマシンが判読できる形式で提供します。値は `TCPConnect`、`TCPConnectError`、`DNSResolve`、`DNSError` のいずれかになります。
`success`	`boolean`	ログエントリーが成功または失敗であるかを示します。
`time`	`string`	接続チェックの開始時間。

9.4. エンドポイントのネットワーク接続の確認
リンクのコピー

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

前提条件

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

手順

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

oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

$ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

Copy to Clipboard

Toggle word wrap

出力例

NAME                                                                                                                                AGE
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

NAME                                                                                                                                AGE
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

Copy to Clipboard

Toggle word wrap

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

直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。

オブジェクトを表示するには、以下のコマンドを入力します。

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

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

Copy to Clipboard

Toggle word wrap

ここで、<name> は PodNetworkConnectivityCheck オブジェクトの名前を指定します。

出力例

apiVersion: controlplane.operator.openshift.io/v1alpha1
kind: PodNetworkConnectivityCheck
metadata:
  name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
  namespace: openshift-network-diagnostics
  ...
spec:
  sourcePod: network-check-source-7c88f6d9f-hmg2f
  targetEndpoint: 10.0.0.4:6443
  tlsClientCert:
    name: ""
status:
  conditions:
  - lastTransitionTime: "2021-01-13T20:11:34Z"
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnectSuccess
    status: "True"
    type: Reachable
  failures:
  - latency: 2.241775ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:10:34Z"
  - latency: 2.582129ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:09:34Z"
  - latency: 3.483578ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:08:34Z"
  outages:
  - end: "2021-01-13T20:11:34Z"
    endLogs:
    - latency: 2.032018ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        tcp connection to 10.0.0.4:6443 succeeded'
      reason: TCPConnect
      success: true
      time: "2021-01-13T20:11:34Z"
    - latency: 2.241775ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:10:34Z"
    - latency: 2.582129ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:09:34Z"
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
    message: Connectivity restored after 2m59.999789186s
    start: "2021-01-13T20:08:34Z"
    startLogs:
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
  successes:
  - latency: 2.845865ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:14:34Z"
  - latency: 2.926345ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:13:34Z"
  - latency: 2.895796ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:12:34Z"
  - latency: 2.696844ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:11:34Z"
  - latency: 1.502064ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:10:34Z"
  - latency: 1.388857ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:09:34Z"
  - latency: 1.906383ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:08:34Z"
  - latency: 2.089073ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:07:34Z"
  - latency: 2.156994ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:06:34Z"
  - latency: 1.777043ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:05:34Z"

apiVersion: controlplane.operator.openshift.io/v1alpha1
kind: PodNetworkConnectivityCheck
metadata:
  name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
  namespace: openshift-network-diagnostics
  ...
spec:
  sourcePod: network-check-source-7c88f6d9f-hmg2f
  targetEndpoint: 10.0.0.4:6443
  tlsClientCert:
    name: ""
status:
  conditions:
  - lastTransitionTime: "2021-01-13T20:11:34Z"
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnectSuccess
    status: "True"
    type: Reachable
  failures:
  - latency: 2.241775ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:10:34Z"
  - latency: 2.582129ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:09:34Z"
  - latency: 3.483578ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
      to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
      connection refused'
    reason: TCPConnectError
    success: false
    time: "2021-01-13T20:08:34Z"
  outages:
  - end: "2021-01-13T20:11:34Z"
    endLogs:
    - latency: 2.032018ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        tcp connection to 10.0.0.4:6443 succeeded'
      reason: TCPConnect
      success: true
      time: "2021-01-13T20:11:34Z"
    - latency: 2.241775ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:10:34Z"
    - latency: 2.582129ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:09:34Z"
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
    message: Connectivity restored after 2m59.999789186s
    start: "2021-01-13T20:08:34Z"
    startLogs:
    - latency: 3.483578ms
      message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
        failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
        connect: connection refused'
      reason: TCPConnectError
      success: false
      time: "2021-01-13T20:08:34Z"
  successes:
  - latency: 2.845865ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:14:34Z"
  - latency: 2.926345ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:13:34Z"
  - latency: 2.895796ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:12:34Z"
  - latency: 2.696844ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:11:34Z"
  - latency: 1.502064ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:10:34Z"
  - latency: 1.388857ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:09:34Z"
  - latency: 1.906383ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:08:34Z"
  - latency: 2.089073ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:07:34Z"
  - latency: 2.156994ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:06:34Z"
  - latency: 1.777043ms
    message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
      connection to 10.0.0.4:6443 succeeded'
    reason: TCPConnect
    success: true
    time: "2021-01-13T21:05:34Z"

Copy to Clipboard

Toggle word wrap

第10章クラスターネットワークの MTU 変更
リンクのコピー

クラスター管理者は、クラスターのインストール後にクラスターネットワークの MTU を変更できます。MTU 変更の適用には、クラスターノードを再起動する必要があるため、変更により致命的な問題が発生する可能性があります。MTU は、OVN-Kubernetes または OpenShift SDN クラスターネットワークプロバイダーを使用するクラスターに対してのみ変更できます。

10.1. クラスター MTU について
リンクのコピー

インストール中に、クラスターネットワークの最大伝送ユニット (MTU) は、クラスター内のノードのプライマリーネットワークインターフェイスの MTU をもとに、自動的に検出されます。通常、検出された MTU を上書きする必要はありません。

以下のような理由でクラスターネットワークの MTU を変更する場合があります。

クラスターのインストール中に検出された MTU が使用中のインフラストラクチャーに適していない
クラスターインフラストラクチャーに異なる MTU が必要となった (例: パフォーマンスの最適化にさまざまな MTU を必要とするノードが追加された)。

OVN-Kubernetes および OpenShift SDN クラスターネットワークプロバイダーに対してのみ、クラスター MTU を変更できます。

10.1.1. サービス中断に関する考慮事項
リンクのコピー

クラスターで MTU の変更を開始すると、次の動作が原因でサービスの可用性に影響を与える可能性があります。

新しい MTU への移行を完了するには、少なくとも 2 回のローリングリブートが必要です。この間、一部のノードは再起動するため使用できません。
特定のアプリケーションに、絶対 TCP タイムアウト間隔よりもタイムアウトの間隔が短いクラスターにデプロイされた場合など、MTU の変更中に中断が発生する可能性があります。

10.1.2. MTU 値の選択
リンクのコピー

MTU の移行を計画するときは、関連しているが異なる MTU 値を 2 つ考慮する必要があります。

ハードウェア MTU: この MTU 値は、ネットワークインフラストラクチャーの詳細に基づいて設定されます。
クラスターネットワーク MTU: この MTU 値は、クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。特定のオーバーヘッドは、クラスターネットワークプロバイダーによって決定されます。
- OVN-Kubernetes: 100バイト
- OpenShift SDN: 50バイト

クラスターがノードごとに異なる MTU 値を必要とする場合は、クラスター内の任意のノードで使用される最小の MTU 値から、クラスターネットワークプロバイダーのオーバーヘッド値を差し引く必要があります。たとえば、クラスター内の一部のノードでは MTU が 9001 であり、MTU が 1500 のクラスターもある場合には、この値を 1400 に設定する必要があります。

10.1.3. 移行プロセスの仕組み
リンクのコピー

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

Expand

表10.1 クラスター MTU のライブマイグレーション
ユーザーが開始する手順	OpenShift Container Platform アクティビティー
Cluster Network Operator 設定で次の値を指定します。 `spec.migration.mtu.machine.to` `spec.migration.mtu.network.from` `spec.migration.mtu.network.to`	Cluster Network Operator (CNO): 各フィールドが有効な値に設定されていることを確認します。 `mtu.machine.to`は、新しいハードウェア MTU、またはハードウェアの MTU が変更されていない場合は、現在のハードウェア MTU のいずれかに設定する必要があります。この値は一時的なものであり、移行プロセスの一部として使用されます。これとは別に、既存のハードウェア MTU 値とは異なるハードウェア MTU を指定する場合は、マシン設定、DHCP 設定、Linux カーネルコマンドラインなどの他の方法で永続化するように MTU を手動で設定する必要があります。 `mtu.network.from`フィールドは、クラスターネットワークの現在の MTU である`network.status.cluster Network MTU`フィールドと同じである必要があります。 `mtu.network.to`フィールドは、ターゲットクラスターネットワーク MTU に設定する必要があり、クラスターネットワークプロバイダーのオーバーレイオーバーヘッドを考慮して、ハードウェア MTU よりも低くする必要があります。OVN-Kubernetes の場合、オーバーヘッドは`100`バイトで、OpenShift SDN の場合のオーバーヘッドは`50`バイトです。指定の値が有効な場合に、CNO は、クラスターネットワークの MTU が`mtu.network.to`フィールドの値に設定された新しい一時設定を書き出します。 Machine Config Operator (MCO): クラスター内の各ノードのローリングリブートを実行します。
クラスター上のノードのプライマリーネットワークインターフェイスの MTU を再設定します。これを実現するには、次のようなさまざまな方法を使用できます。 MTU を変更した新しい Network Manager 接続プロファイルのデプロイ DHCP サーバー設定による MTU の変更ブートパラメーターによる MTU の変更	該当なし
クラスターネットワークプロバイダーの CNO 設定で`mtu`値を設定し、 `spec.migration`を`null`に設定します。	Machine Config Operator (MCO): 新しい MTU 設定を使用して、クラスター内の各ノードのローリングリブートを実行します。

10.2. クラスター MTU の変更
リンクのコピー

クラスター管理者は、クラスターの最大転送単位 (MTU) を変更できます。移行には中断を伴い、MTU 更新が公開されると、クラスター内のノードが一時的に利用できなくなる可能性があります。

次の手順では、マシン設定、DHCP、または ISO のいずれかを使用してクラスター MTU を変更する方法について説明します。DHCP または ISO アプローチを使用する場合は、クラスターのインストール後に保持した設定アーティファクトを参照して、手順を完了する必要があります。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
クラスターのターゲット MTU を特定している。正しい MTU は、クラスターが使用するクラスターネットワークプロバイダーにより異なります。
- OVN-Kubernetes: クラスター MTU は、クラスター内の最小のハードウェア MTU 値から 100を引いた数に設定する必要があります。
- OpenShift SDN: クラスター MTU は、クラスター内の最小ハードウェア MTU 値から 50 を引いた値に設定する必要があります。

手順

クラスターネットワークの MTU を増減するには、次の手順を実行します。

クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

oc describe network.config cluster

$ oc describe network.config cluster

Copy to Clipboard

Toggle word wrap

出力例

...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OpenShiftSDN
  Service Network:
    10.217.4.0/23
...

...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OpenShiftSDN
  Service Network:
    10.217.4.0/23
...

Copy to Clipboard

Toggle word wrap

ハードウェア MTU の設定を準備します。
- ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。
  dhcp-option-force=26,<mtu>
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <mtu>
  DHCP サーバーがアドバタイズするハードウェア MTU を指定します。
- ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。
- ハードウェア MTU が Network Manager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。
  1. プライマリーネットワークインターフェイスを見つけます。
    OpenShift SDN ネットワークプロバイダーを使用している場合には、以下のコマンドを入力します。
    
    $ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'
    
    Copy to Clipboard Toggle word wrap
    
    ここでは、以下のようになります。
    <node_name>
    クラスター内のノードの名前を指定します。
    OVN-Kubernetes ネットワークプロバイダーを使用している場合には、以下のコマンドを入力します。
    
    $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0
    
    Copy to Clipboard Toggle word wrap
    
    ここでは、以下のようになります。
    <node_name>
    クラスター内のノードの名前を指定します。
  2. <interface>-mtu.conf ファイルに次の NetworkManager 設定を作成します。
    Network Manager 接続設定の例
    
    [connection-<interface>-mtu] match-device=interface-name:<interface> ethernet.mtu=<mtu>
    
    Copy to Clipboard Toggle word wrap
    
    ここでは、以下のようになります。
    <mtu>
    新しいハードウェア MTU 値を指定します。
    <interface>
    プライマリーネットワークインターフェイス名を指定します。
  3. 1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つのMachineConfigオブジェクトを作成します。
    control-plane-interface.bu ファイルに次の Butane 設定を作成します。
    
    variant: openshift version: 4.11.0 metadata: name: 01-control-plane-interface labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
    1
    contents: local: <interface>-mtu.conf
    2
    mode: 0600
    
    Copy to Clipboard Toggle word wrap
    
    1
    プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。
    2
    前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。
    worker-interface.bu ファイルに次の Butane 設定を作成します。
    
    variant: openshift version: 4.11.0 metadata: name: 01-worker-interface labels: machineconfiguration.openshift.io/role: worker storage: files: - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf
    1
    contents: local: <interface>-mtu.conf
    2
    mode: 0600
    
    Copy to Clipboard Toggle word wrap
    
    1
    プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。
    2
    前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。
    次のコマンドを実行して、Butane 設定から MachineConfig オブジェクトを作成します。
    
    $ for manifest in control-plane-interface worker-interface; do butane --files-dir . $manifest.bu > $manifest.yaml done
    
    Copy to Clipboard Toggle word wrap
MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。
```
oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<overlay_from>
現在のクラスターネットワークの MTU 値を指定します。
<overlay_to>
クラスターネットワークのターゲット MTU を指定します。この値は、 <machine_to>の値を基準にして設定され、それぞれ、OVN-Kubernetes の場合は100 を、OpenShift SDN の場合は50 を引いた値に指定します。
<machine_to>
基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。
クラスター MTU を増やす例
```
oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
```
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
```
Copy to Clipboard Toggle word wrap
MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get mcp
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
正常に更新されたノードには、UPDATED=true、UPDATING=false、 DEGRADED=false のステータスがあります。
注記
デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
  $ oc describe node | egrep "hostname|machineconfig"
  Copy to Clipboard Toggle word wrap
  出力例
  kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
  
  Copy to Clipboard Toggle word wrap
  以下のステートメントが true であることを確認します。
  - machineconfiguration.openshift.io/state フィールドの値は Done です。
  - machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。
  $ oc get machineconfig <config_name> -o yaml | grep ExecStart
  Copy to Clipboard Toggle word wrap
  <config_name> は machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前です。
  マシン設定には、systemd 設定に以下の更新を含める必要があります。
  ExecStart=/usr/local/bin/mtu-migration.sh
  Copy to Clipboard Toggle word wrap
基盤となるネットワークインターフェイスの MTU 値を更新します。
- Network Manager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。Machine Config Operator は、クラスター内のノードのローリングリブートを自動的に実行します。
  $ for manifest in control-plane-interface worker-interface; do oc create -f $manifest.yaml done
  Copy to Clipboard Toggle word wrap
- DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。
MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get mcp
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
正常に更新されたノードには、UPDATED=true、UPDATING=false、 DEGRADED=false のステータスがあります。
注記
デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
  $ oc describe node | egrep "hostname|machineconfig"
  Copy to Clipboard Toggle word wrap
  出力例
  kubernetes.io/hostname=master-0 machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b machineconfiguration.openshift.io/reason: machineconfiguration.openshift.io/state: Done
  
  Copy to Clipboard Toggle word wrap
  以下のステートメントが true であることを確認します。
  - machineconfiguration.openshift.io/state フィールドの値は Done です。
  - machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。
  $ oc get machineconfig <config_name> -o yaml | grep path:
  Copy to Clipboard Toggle word wrap
  <config_name> は machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前です。
  マシン設定が正常にデプロイされた場合には、前の出力に /etc/NetworkManager/system-connections/<connection_name> のファイルパスが含まれます。
  マシン設定には、ExecStart=/usr/local/bin/mtu-migration.sh 行を含めることはできません。
MTU 移行を完了するには、次のいずれかのコマンドを入力します。
- OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合:
  $ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <mtu>
  <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。
- OpenShift SDN クラスターネットワークプロバイダーを使用している場合:
  $ oc patch Network.operator.openshift.io cluster --type=merge --patch \ '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <mtu>
  <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。
MTU の移行が完了すると、各 MCP ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
```
oc get mcp
```
```
$ oc get mcp
```
Copy to Clipboard Toggle word wrap
正常に更新されたノードには、UPDATED=true、UPDATING=false、 DEGRADED=false のステータスがあります。

検証

クラスター内のノードで、前の手順で指定した MTU が使用されていることを確認できます。

クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。
```
oc describe network.config cluster
```
```
$ oc describe network.config cluster
```
Copy to Clipboard Toggle word wrap
ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。
1. クラスター内のノードをリスト表示するには、次のコマンドを入力します。
  $ oc get nodes
  Copy to Clipboard Toggle word wrap
2. ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。
  $ oc debug node/<node> -- chroot /host ip address show <interface>
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <node>
  前のステップの出力をもとに、ノードを指定します。
  <interface>
  ノードのプライマリーネットワークインターフェイス名を指定します。
  出力例
  ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051
  
  Copy to Clipboard Toggle word wrap

第11章ノードポートサービス範囲の設定
リンクのコピー

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

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

11.1. 前提条件
リンクのコピー

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

11.2. ノードのポート範囲の拡張
リンクのコピー

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

前提条件

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

手順

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

oc patch network.config.openshift.io cluster --type=merge -p \
  '{

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

Copy to Clipboard

Toggle word wrap

ヒント

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

network.config.openshift.io/cluster patched

network.config.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

第12章 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 です。

12.1. IP フェイルオーバーの環境変数
リンクのコピー

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

Expand

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

12.2. IP フェイルオーバーの設定
リンクのコピー

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

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

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

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

前提条件

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

手順

IP フェイルオーバーのサービスアカウントを作成します。
```
oc create sa ipfailover
```
```
$ oc create sa ipfailover
```
Copy to Clipboard Toggle word wrap

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

$ oc adm policy add-scc-to-user privileged -z ipfailover
$ oc adm policy add-scc-to-user hostnetwork -z ipfailover

Copy to Clipboard

Toggle word wrap

デプロイメント YAML ファイルを作成して IP フェイルオーバーを設定します。

IP フェイルオーバー設定のデプロイメント YAML の例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ipfailover-keepalived 
  labels:
    ipfailover: hello-openshift
spec:
  strategy:
    type: Recreate
  replicas: 2
  selector:
    matchLabels:
      ipfailover: hello-openshift
  template:
    metadata:
      labels:
        ipfailover: hello-openshift
    spec:
      serviceAccountName: ipfailover
      privileged: true
      hostNetwork: true
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      containers:
      - name: openshift-ipfailover
        image: 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 
          value: "1.1.1.1-2"
        - name: OPENSHIFT_HA_VIP_GROUPS 
          value: "10"
        - name: OPENSHIFT_HA_NETWORK_INTERFACE 
          value: "ens3" #The host interface to assign the VIPs
        - name: OPENSHIFT_HA_MONITOR_PORT 
          value: "30060"
        - name: OPENSHIFT_HA_VRRP_ID_OFFSET 
          value: "0"
        - name: OPENSHIFT_HA_REPLICA_COUNT 
          value: "2" #Must match the number of replicas in the deployment
        - name: OPENSHIFT_HA_USE_UNICAST
          value: "false"
        #- name: OPENSHIFT_HA_UNICAST_PEERS
          #value: "10.0.148.40,10.0.160.234,10.0.199.110"
        - name: OPENSHIFT_HA_IPTABLES_CHAIN 
          value: "INPUT"
        #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 
        #  value: /etc/keepalive/mynotifyscript.sh
        - name: OPENSHIFT_HA_CHECK_SCRIPT 
          value: "/etc/keepalive/mycheckscript.sh"
        - name: OPENSHIFT_HA_PREEMPTION 
          value: "preempt_delay 300"
        - name: OPENSHIFT_HA_CHECK_INTERVAL 
          value: "2"
        livenessProbe:
          initialDelaySeconds: 10
          exec:
            command:
            - pgrep
            - keepalived
      volumes:
      - name: lib-modules
        hostPath:
          path: /lib/modules
      - name: host-slash
        hostPath:
          path: /
      - name: etc-sysconfig
        hostPath:
          path: /etc/sysconfig
      # config-volume contains the check script
      # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
      - configMap:
          defaultMode: 0755
          name: keepalived-checkscript
        name: config-volume
      imagePullSecrets:
        - name: openshift-pull-secret

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ipfailover-keepalived

1


  labels:
    ipfailover: hello-openshift
spec:
  strategy:
    type: Recreate
  replicas: 2
  selector:
    matchLabels:
      ipfailover: hello-openshift
  template:
    metadata:
      labels:
        ipfailover: hello-openshift
    spec:
      serviceAccountName: ipfailover
      privileged: true
      hostNetwork: true
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      containers:
      - name: openshift-ipfailover
        image: 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

Copy to Clipboard

Toggle word wrap

1: IP フェイルオーバーデプロイメントの名前。
2: レプリケートする IP アドレス範囲のリストです。これは指定する必要があります。例: 1.2.3.4-6,1.2.3.9
3: VRRP に作成するグループの数です。これが設定されていない場合、グループは OPENSHIFT_HA_VIP_GROUPS 変数で指定されている仮想 IP 範囲ごとに作成されます。
4: IP フェイルオーバーが VRRP トラフィックの送信に使用するインターフェイス名。デフォルトで eth0 が使用されます。
5: IP フェイルオーバー Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。デフォルト値は 80 です。
6: 仮想ルーター ID の設定に使用されるオフセット値。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは 0 で、許可される範囲は 0 から 255 までです。
7: 作成するレプリカの数です。これは、IP フェイルオーバーデプロイメント設定の spec.replicas 値に一致する必要があります。デフォルト値は 2 です。
8: iptables チェーンの名前であり、iptables ルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、iptables ルールは追加されません。チェーンが存在しない場合は作成されず、Keepalived はユニキャストモードで動作します。デフォルトは INPUT です。
9: 状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
10: アプリケーションが動作していることを確認するために定期的に実行されるスクリプトの Pod ファイルシステム内の完全パス名です。
11: 新たな優先度の高いホストを処理するためのストラテジーです。デフォルト値は preempt_delay 300 で、優先順位の低いマスターが VIP を保持する場合に、Keepalived インスタンスが VIP を 5 分後に引き継ぎます。
12: check スクリプトが実行される期間 (秒単位) です。デフォルト値は 2 です。
13: デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。

12.3. 仮想 IP アドレスについて
リンクのコピー

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

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

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

注記

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

12.4. check スクリプトおよび notify スクリプトの設定
リンクのコピー

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

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

各 IP フェイルオーバー Pod は、Pod が実行されているノードで 1 つ以上の仮想 IP (VIP) を管理する Keepalived デーモンを管理します。Keepalived デーモンは、ノードの各 VIP の状態を維持します。特定のノード上の特定の VIP は、master、backup、または 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: 新規の状態: master、backup、または fault

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

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

前提条件

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

手順

必要なスクリプトを作成し、これを保持する ConfigMap を作成します。スクリプトには入力引数は指定されず、OK の場合は 0 を、fail の場合は 1 を返す必要があります。
check スクリプト mycheckscript.sh:
```
#!/bin/bash
    # Whatever tests are needed
    # E.g., send request and verify response
exit 0
```
```
#!/bin/bash
    # Whatever tests are needed
    # E.g., send request and verify response
exit 0
```
Copy to Clipboard Toggle word wrap

ConfigMap を作成します。

oc create configmap mycustomcheck --from-file=mycheckscript.sh

$ oc create configmap mycustomcheck --from-file=mycheckscript.sh

Copy to Clipboard

Toggle word wrap

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

oc set env deploy/ipfailover-keepalived \
    OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

$ oc set env deploy/ipfailover-keepalived \
    OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

Copy to Clipboard

Toggle word wrap

oc set volume deploy/ipfailover-keepalived --add --overwrite \
    --name=config-volume \
    --mount-path=/etc/keepalive \
    --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

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

Copy to Clipboard

Toggle word wrap

注記

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

ヒント

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

oc edit deploy ipfailover-keepalived

$ oc edit deploy ipfailover-keepalived

Copy to Clipboard

Toggle word wrap

    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_CHECK_SCRIPT  
          value: /etc/keepalive/mycheckscript.sh
...
        volumeMounts: 
        - mountPath: /etc/keepalive
          name: config-volume
      dnsPolicy: ClusterFirst
...
      volumes: 
      - configMap:
          defaultMode: 0755 
          name: customrouter
        name: config-volume
...

    spec:
      containers:
      - env:
        - name: OPENSHIFT_HA_CHECK_SCRIPT

1


          value: /etc/keepalive/mycheckscript.sh
...
        volumeMounts:

2


        - mountPath: /etc/keepalive
          name: config-volume
      dnsPolicy: ClusterFirst
...
      volumes:

3


      - configMap:
          defaultMode: 0755

4


          name: customrouter
        name: config-volume
...

Copy to Clipboard

Toggle word wrap

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

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

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

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

12.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 
          value: "3"
...
```
```
...
    spec:
        env:
        - name: OPENSHIFT_HA_VIP_GROUPS 
```
1
```
          value: "3"
...
```
Copy to Clipboard Toggle word wrap
1
たとえば、7 つの VIP のある環境で OPENSHIFT_HA_VIP_GROUPS が 3 に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。

注記

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

12.8. ingressIP の高可用性
リンクのコピー

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

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

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

12.9. IP フェイルオーバーの削除
リンクのコピー

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

手順

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

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

oc get pod -l ipfailover \
  -o jsonpath="\
{range .items[?(@.spec.volumes[*].configMap)]}

$ oc get pod -l ipfailover \
  -o jsonpath="\
{range .items[?(@.spec.volumes[*].configMap)]}
{'Namespace: '}{.metadata.namespace}
{'Pod:       '}{.metadata.name}
{'Volumes that use config maps:'}
{range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
  {'configMap: '}{.configMap.name}{'\n'}{end}
{end}"

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

前述の手順でボリュームとして使用される ConfigMap の名前が提供されている場合は、ConfigMap を削除します。
```
oc delete configmap <configmap_name>
```
```
$ oc delete configmap <configmap_name>
```
Copy to Clipboard Toggle word wrap

IP フェイルオーバーの既存デプロイメントを特定します。

oc get deployment -l ipfailover

$ oc get deployment -l ipfailover

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

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

oc delete deployment <ipfailover_deployment_name>

$ oc delete deployment <ipfailover_deployment_name>

Copy to Clipboard

Toggle word wrap

ipfailover サービスアカウントを削除します。
```
oc delete sa ipfailover
```
```
$ oc delete sa ipfailover
```
Copy to Clipboard Toggle word wrap

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

以下の例のような内容で remove-ipfailover-job.yaml などのファイルを作成します。

apiVersion: batch/v1
kind: Job
metadata:
  generateName: remove-ipfailover-
  labels:
    app: remove-ipfailover
spec:
  template:
    metadata:
      name: remove-ipfailover
    spec:
      containers:
      - name: remove-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover:4.11
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector:
        kubernetes.io/hostname: <host_name>  <.>
      restartPolicy: Never

apiVersion: batch/v1
kind: Job
metadata:
  generateName: remove-ipfailover-
  labels:
    app: remove-ipfailover
spec:
  template:
    metadata:
      name: remove-ipfailover
    spec:
      containers:
      - name: remove-ipfailover
        image: quay.io/openshift/origin-keepalived-ipfailover:4.11
        command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
      nodeSelector:
        kubernetes.io/hostname: <host_name>  <.>
      restartPolicy: Never

Copy to Clipboard

Toggle word wrap

<.> IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。

ジョブを実行します。

oc create -f remove-ipfailover-job.yaml

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

Copy to Clipboard

Toggle word wrap

出力例

job.batch/remove-ipfailover-2h8dm created

job.batch/remove-ipfailover-2h8dm created

Copy to Clipboard

Toggle word wrap

検証

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

oc logs job/remove-ipfailover-2h8dm

$ oc logs job/remove-ipfailover-2h8dm

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

第13章インターフェイスレベルのネットワーク sysctl の設定
リンクのコピー

Linux では、管理者は sysctl を使用してランタイム時にカーネルパラメーターを変更できます。チューニング Container Network Interface (CNI) メタプラグインを使用して、インターフェイスレベルのネットワーク sysctl を変更できます。チューニング CNI メタプラグインは、図に示すように、メインの CNI プラグインとチェーンで動作します。

メインの CNI プラグインはインターフェイスを割り当て、これをランタイム時にチューニング CNI メタプラグインに渡します。チューニング CNI メタプラグインを使用して、ネットワーク namespace の一部の sysctl といくつかのインターフェイス属性 (プロミスキャスモード、オールマルチキャストモード、MTU、および MAC アドレス) を変更できます。チューニング CNI メタプラグイン設定では、インターフェイス名は IFNAME トークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。

注記

OpenShift Container Platform では、チューニング CNI メタプラグインはインターフェイスレベルのネットワーク sysctl の変更のみをサポートします。

13.1. チューニング CNI の設定
リンクのコピー

次の手順では、チューニング CNI を設定し、インターフェイスレベルのネットワーク net.ipv4.conf.IFNAME.accept_redirects sysctl を変更します。この例では、ICMP リダイレクトパケットの受け入れと送信を有効にします。

手順

次の内容で、tuning-example.yaml などのネットワーク接続定義を作成します。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
  namespace: default 
spec:
  config: '{
    "cniVersion": "0.4.0", 
    "name": "<name>", 
    "plugins": [{
       "type": "<main_CNI_plugin>" 
      },
      {
       "type": "tuning", 
       "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1" 
        }
      }
     ]
}

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: <name>

1


  namespace: default

2


spec:
  config: '{
    "cniVersion": "0.4.0",

3


    "name": "<name>",

4


    "plugins": [{
       "type": "<main_CNI_plugin>"

5


      },
      {
       "type": "tuning",

6


       "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1"

7

Copy to Clipboard

Toggle word wrap

1: 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
2: オブジェクトが関連付けられている namespace を指定します。
3: CNI 仕様のバージョンを指定します。
4: 設定の名前を指定します。設定名をネットワーク接続定義の name の値に一致させることが推奨されます。
5: 設定するメイン CNI プラグインの名前を指定します。
6: CNI メタプラグインの名前を指定します。
7: 設定する sysctl を指定します。

yaml ファイルの例を次に示します。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
        }
    }
  ]
}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
        }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して yaml を適用します。

oc apply -f tuning-example.yaml

$ oc apply -f tuning-example.yaml

Copy to Clipboard

Toggle word wrap

出力例

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

Copy to Clipboard

Toggle word wrap

次のようなネットワーク接続定義を使用して、examplepod.yaml などの Pod を作成します。
```
apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad 
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 
      runAsGroup: 3000 
      allowPrivilegeEscalation: false 
      capabilities: 
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 
    seccompProfile: 
      type: RuntimeDefault
```
```
apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad 
```
1
```
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 
```
2
```
      runAsGroup: 3000 
```
3
```
      allowPrivilegeEscalation: false 
```
4
```
      capabilities: 
```
5
```
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 
```
6
```
    seccompProfile: 
```
7
```
      type: RuntimeDefault
```
Copy to Clipboard Toggle word wrap
1
設定済みの NetworkAttachmentDefinition の名前を指定します。
2
runAsUser は、コンテナーが実行されるユーザー ID を制御します。
3
runAsGroup は、コンテナーが実行されるプライマリーグループ ID を制御します。
4
allowPrivilegeEscalation は、Pod が特権の昇格を許可するように要求できるかどうかを決定します。指定しない場合、デフォルトで true に設定されます。このブール値は、no_new_privs フラグがコンテナープロセスに設定されるかどうかを直接制御します。
5
capabilities は、完全なルートアクセスを許可せずに権限操作を許可します。このポリシーにより、すべての機能が Pod から削除されます。
6
runAsNonRoot: true は、コンテナーが 0 以外の任意の UID を持つユーザーで実行されることを要求します。
7
RuntimeDefault は、Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを有効にします。
以下のコマンドを実行して yaml を適用します。
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、Pod が作成されていることを確認します。
```
oc get pod
```
```
$ oc get pod
```
Copy to Clipboard Toggle word wrap
出力例
```
NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s
```
```
NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、Pod にログインします。
```
oc rsh tunepod
```
```
$ oc rsh tunepod
```
Copy to Clipboard Toggle word wrap
設定された sysctl フラグの値を確認します。たとえば、次のコマンドを実行して、値 net.ipv4.conf.net1.accept_redirects を見つけます。
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
予想される出力
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

第14章ベアメタルクラスターでの SCTP (Stream Control Transmission Protocol) の使用
リンクのコピー

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

14.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 のいずれかの値に設定して定義する必要があります。

14.1.1. SCTP プロトコルを使用した設定例
リンクのコピー

protocol パラメーターを Pod またはサービスリソース定義の SCTP 値に設定して、Pod またはサービスを SCTP を使用するように設定できます。

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

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

apiVersion: v1
kind: Pod
metadata:
  namespace: project1
  name: example-pod
spec:
  containers:
    - name: example-pod
...
      ports:
        - containerPort: 30100
          name: sctpserver
          protocol: SCTP

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

14.2. SCTP (Stream Control Transmission Protocol) の有効化
リンクのコピー

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

前提条件

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

手順

以下の YAML 定義が含まれる load-sctp-module.yaml という名前のファイルを作成します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: load-sctp-module
  labels:
    machineconfiguration.openshift.io/role: worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modprobe.d/sctp-blacklist.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,
        - path: /etc/modules-load.d/sctp-load.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,sctp

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: load-sctp-module
  labels:
    machineconfiguration.openshift.io/role: worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - path: /etc/modprobe.d/sctp-blacklist.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,
        - path: /etc/modules-load.d/sctp-load.conf
          mode: 0644
          overwrite: true
          contents:
            source: data:,sctp

Copy to Clipboard

Toggle word wrap

MachineConfig オブジェクトを作成するには、以下のコマンドを入力します。
```
oc create -f load-sctp-module.yaml
```
```
$ oc create -f load-sctp-module.yaml
```
Copy to Clipboard Toggle word wrap
オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが Ready に移行すると、設定の更新が適用されます。
```
oc get nodes
```
```
$ oc get nodes
```
Copy to Clipboard Toggle word wrap

14.3. SCTP (Stream Control Transmission Protocol) が有効になっていることの確認
リンクのコピー

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

前提条件

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

手順

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

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

apiVersion: v1
kind: Pod
metadata:
  name: sctpserver
  labels:
    app: sctpserver
spec:
  containers:
    - name: sctpserver
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]
      ports:
        - containerPort: 30102
          name: sctpserver
          protocol: SCTP

apiVersion: v1
kind: Pod
metadata:
  name: sctpserver
  labels:
    app: sctpserver
spec:
  containers:
    - name: sctpserver
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]
      ports:
        - containerPort: 30102
          name: sctpserver
          protocol: SCTP

Copy to Clipboard

Toggle word wrap

以下のコマンドを入力して Pod を作成します。
```
oc create -f sctp-server.yaml
```
```
$ oc create -f sctp-server.yaml
```
Copy to Clipboard Toggle word wrap

SCTP リスナー Pod のサービスを作成します。

以下の YAML でサービスを定義する sctp-service.yaml という名前のファイルを作成します。

apiVersion: v1
kind: Service
metadata:
  name: sctpservice
  labels:
    app: sctpserver
spec:
  type: NodePort
  selector:
    app: sctpserver
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30102
      targetPort: 30102

apiVersion: v1
kind: Service
metadata:
  name: sctpservice
  labels:
    app: sctpserver
spec:
  type: NodePort
  selector:
    app: sctpserver
  ports:
    - name: sctpserver
      protocol: SCTP
      port: 30102
      targetPort: 30102

Copy to Clipboard

Toggle word wrap

サービスを作成するには、以下のコマンドを入力します。
```
oc create -f sctp-service.yaml
```
```
$ oc create -f sctp-service.yaml
```
Copy to Clipboard Toggle word wrap

SCTP クライアントの Pod を作成します。

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

apiVersion: v1
kind: Pod
metadata:
  name: sctpclient
  labels:
    app: sctpclient
spec:
  containers:
    - name: sctpclient
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]

apiVersion: v1
kind: Pod
metadata:
  name: sctpclient
  labels:
    app: sctpclient
spec:
  containers:
    - name: sctpclient
      image: registry.access.redhat.com/ubi8/ubi
      command: ["/bin/sh", "-c"]
      args:
        ["dnf install -y nc && sleep inf"]

Copy to Clipboard

Toggle word wrap

Pod オブジェクトを作成するには、以下のコマンドを入力します。
```
oc apply -f sctp-client.yaml
```
```
$ oc apply -f sctp-client.yaml
```
Copy to Clipboard Toggle word wrap

サーバーで SCTP リスナーを実行します。
1. サーバー Pod に接続するには、以下のコマンドを入力します。
  $ oc rsh sctpserver
  Copy to Clipboard Toggle word wrap
2. SCTP リスナーを起動するには、以下のコマンドを入力します。
  $ nc -l 30102 --sctp
  Copy to Clipboard Toggle word wrap
サーバーの SCTP リスナーに接続します。
1. ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。
2. sctpservice サービスの IP アドレスを取得します。以下のコマンドを入力します。
  $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'
  Copy to Clipboard Toggle word wrap
3. クライアント Pod に接続するには、以下のコマンドを入力します。
  $ oc rsh sctpclient
  Copy to Clipboard Toggle word wrap
4. SCTP クライアントを起動するには、以下のコマンドを入力します。<cluster_IP> を sctpservice サービスのクラスター IP アドレスに置き換えます。
  # nc <cluster_IP> 30102 --sctp
  Copy to Clipboard Toggle word wrap

第15章 PTP ハードウェアの使用
リンクのコピー

OpenShift Container Platform クラスターノードでlinuxptp サービスを設定し、PTP 対応ハードウェアを使用できます。

15.1. PTP ハードウェアについて
リンクのコピー

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

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

注記

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

15.2. PTP について
リンクのコピー

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

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

15.2.1. PTP ドメインの要素
リンクのコピー

PTP は、ネットワークに接続された複数のノードを各ノードのクロックと同期するために使用されます。PTP で同期するクロックは、同期元と同期先の階層で整理されています。この階層は、best master clock (BMC) アルゴリズムで作成され、自動的に更新されます。宛先のクロックは、ソースとなるクロックに同期され、宛先クロック自体が他のダウンストリームクロックのソースになることができます。以下のタイプのクロックを設定に追加できます。

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

15.2.2. NTP 上の PTP の利点
リンクのコピー

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

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

重要

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

15.2.3. デュアル NIC ハードウェアでの PTP の使用
リンクのコピー

OpenShift Container Platform は、クラスター内の正確な PTP タイミングのためにシングルおよびデュアル NIC ハードウェアをサポートします。

ミッドバンドスペクトルカバレッジを提供する 5G 電話会社ネットワークの場合、各仮想分散ユニット (vDU) には 6 つの無線ユニット (RU) への接続が必要です。これらの接続を確立するには、各 vDU ホストに境界クロックとして設定された 2 つの NIC が必要です。

デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給することができます。

15.3. CLI を使用した PTP Operator のインストール
リンクのコピー

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

前提条件

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

手順

PTP Operator の namespace を作成します。

次の YAML をptp-namespace.yamlファイルに保存します。

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    name: openshift-ptp
    openshift.io/cluster-monitoring: "true"

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    name: openshift-ptp
    openshift.io/cluster-monitoring: "true"

Copy to Clipboard

Toggle word wrap

namespace CR を作成します。
```
oc create -f ptp-namespace.yaml
```
```
$ oc create -f ptp-namespace.yaml
```
Copy to Clipboard Toggle word wrap

PTP Operator の Operator グループを作成します。

次の YAML をptp-operatorgroup.yamlファイルに保存します。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
spec:
  targetNamespaces:
  - openshift-ptp

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
spec:
  targetNamespaces:
  - openshift-ptp

Copy to Clipboard

Toggle word wrap

OperatorGroup CR を作成します。
```
oc create -f ptp-operatorgroup.yaml
```
```
$ oc create -f ptp-operatorgroup.yaml
```
Copy to Clipboard Toggle word wrap

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

次の YAML をptp-sub.yamlファイルに保存します。

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Copy to Clipboard

Toggle word wrap

Subscription CR を作成します。
```
oc create -f ptp-sub.yaml
```
```
$ oc create -f ptp-sub.yaml
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

Name                         Phase
4.12.0-202301261535          Succeeded

Name                         Phase
4.12.0-202301261535          Succeeded

Copy to Clipboard

Toggle word wrap

15.4. Web コンソールを使用した PTP Operator のインストール
リンクのコピー

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

注記

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

手順

OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator のリストから PTP Operator を選択してから Install をクリックします。
3. Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。
オプション: PTP Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに切り替えます。
2. PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトにリスト表示されていることを確認します。
  注記
  インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
  Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
  - Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
  - Workloads → Pods ページに移動し、openshift-ptp プロジェクトで Pod のログを確認します。

15.5. PTP デバイスの設定
リンクのコピー

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

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

15.5.1. クラスター内の PTP 対応ネットワークデバイスの検出
リンクのコピー

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

oc get NodePtpDevice -n openshift-ptp -o yaml

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

Copy to Clipboard

Toggle word wrap

出力例

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0 
    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices: 
    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

apiVersion: v1
items:
- apiVersion: ptp.openshift.io/v1
  kind: NodePtpDevice
  metadata:
    creationTimestamp: "2022-01-27T15:16:28Z"
    generation: 1
    name: dev-worker-0

1


    namespace: openshift-ptp
    resourceVersion: "6538103"
    uid: d42fc9ad-bcbf-4590-b6d8-b676c642781a
  spec: {}
  status:
    devices:

2


    - name: eno1
    - name: eno2
    - name: eno3
    - name: eno4
    - name: enp5s0f0
    - name: enp5s0f1
...

Copy to Clipboard

Toggle word wrap

1: name パラメーターの値は、親ノードの名前と同じです。
2: デバイスコレクションには、PTP Operator がノードに対して検出した PTP 対応デバイスのリストが含まれています。

15.5.2. linuxptp サービスをグランドマスタークロックとして設定する
リンクのコピー

ホスト NIC を設定する PtpConfig カスタムリソース (CR) を作成することで、linuxptp サービス (ptp4l、phc2sys、ts2phc) をグランドマスタークロックとして設定できます。

ts2phc ユーティリティーを使用すると、システムクロックを PTP グランドマスタークロックと同期できるため、ノードは高精度クロック信号をダウンストリームの PTP 通常クロックおよび境界クロックにストリーミングできます。

注記

次の PtpConfig CR の例をベースとして使用して、linuxptp サービスを特定のハードウェアおよび環境のグランドマスタークロックとして設定します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。

前提条件

Intel Westport Channel ネットワークインターフェイスをベアメタルクラスターホストにインストールします。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
PTP Operator をインストールします。

手順

PtpConfig リソースを作成します。以下に例を示します。

次の YAML を grandmaster-clock-ptp-config.yaml ファイルに保存します。

PTP グランドマスタークロック設定の例

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: grandmaster-clock
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: grandmaster-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: grandmaster-clock
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: grandmaster-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して CR を作成します。
```
oc create -f grandmaster-clock-ptp-config.yaml
```
```
$ oc create -f grandmaster-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

検証

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

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
linuxptp-daemon-74m2g         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
ptp-operator-5f4f48d7c-x7zkf  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com

NAME                          READY   STATUS    RESTARTS   AGE     IP             NODE
linuxptp-daemon-74m2g         3/3     Running   3          4d15h   10.16.230.7    compute-1.example.com
ptp-operator-5f4f48d7c-x7zkf  1/1     Running   1          4d15h   10.128.1.145   compute-1.example.com

Copy to Clipboard

Toggle word wrap

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

oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-74m2g -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

出力例

ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns
ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1
ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset         -1 s2 freq      -1
ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V
phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset       943 s2 freq  -89604 delay    504
phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset      1000 s2 freq  -89264 delay    474

ts2phc[94980.334]: [ts2phc.0.config] nmea delay: 98690975 ns
ts2phc[94980.334]: [ts2phc.0.config] ens3f0 extts index 0 at 1676577329.999999999 corr 0 src 1676577330.901342528 diff -1
ts2phc[94980.334]: [ts2phc.0.config] ens3f0 master offset         -1 s2 freq      -1
ts2phc[94980.441]: [ts2phc.0.config] nmea sentence: GNRMC,195453.00,A,4233.24427,N,07126.64420,W,0.008,,160223,,,A,V
phc2sys[94980.450]: [ptp4l.0.config] CLOCK_REALTIME phc offset       943 s2 freq  -89604 delay    504
phc2sys[94980.512]: [ptp4l.0.config] CLOCK_REALTIME phc offset      1000 s2 freq  -89264 delay    474

Copy to Clipboard

Toggle word wrap

15.5.3. linuxptp サービスを通常のクロックとして設定
リンクのコピー

Ptp Configカスタムリソース (CR) オブジェクトを作成して、 linuxptpサービス (ptp4l、phc2sys) を通常のクロックとして設定できます。

注記

次の例の PtpConfig CR を、特定のハードウェアおよび環境の通常クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効な場合にのみ必要です。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。

前提条件

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

手順

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

PTP 通常クロックの設定例

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: ordinary-clock
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: ordinary-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: ordinary-clock
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: ordinary-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

Copy to Clipboard

Toggle word wrap

Expand

表15.1 PTP 通常クロック CR 設定のオプション
カスタムリソースフィールド	説明
`name`	`PtpConfig` CR の名前。
`profile`	1 つ以上の `profile` オブジェクトの配列を指定します。各プロファイルの名前は一意である必要があります。
`interface`	`ptp4l` サービスで使用するネットワークインターフェイスを指定します (例: `ens787f1`)。
`ptp4lOpts`	`ptp4l` サービスのシステム設定オプションを指定します。たとえば、`-2` で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名 `-i <interface>` およびサービス設定ファイル `-f /etc/ptp4l.conf` を含めないでください。このインターフェイスで PTP 高速イベントを使用するには、`--summary_interval -4` を追加します。
`phc2sysOpts`	`phc2sys` サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator は `phc2sys` サービスを開始しません。Intel Columbiaville 800 Series NIC の場合、`phc2sysOpts` オプションを `-a -r -m -n 24 -N 8 -R 16` に設定します。`-m` はメッセージを `stdout` に出力します。`linuxptp-daemon` `DaemonSet` はログを解析し、Prometheus メトリックを生成します。
`ptp4lConf`	デフォルトの `/etc/ptp4l.conf` ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。
`tx_timestamp_timeout`	Intel Columbiaville 800 Series NIC の場合、`tx_timestamp_timeout` を `50` に設定します。
`boundary_clock_jbod`	Intel Columbiaville 800 Series NIC の場合、`boundary_clock_jbod` を `0` に設定します。
`ptpSchedulingPolicy`	`ptp4l` と `phc2sys` プロセスのスケジューリングポリシー。デフォルト値は `SCHED_OTHER` です。FIFO スケジューリングをサポートするシステムでは、`SCHED_FIFO` を使用してください。
`ptpSchedulingPriority`	`ptp SchedulingPolicy` が `SCHED_FIFO` に設定されている場合に、`ptp4l` および `phc2sys` プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。`ptpSchedulingPriority` フィールドは、`ptpSchedulingPolicy` が `SCHED_OTHER` に設定されている場合は使用されません。
`ptpClockThreshold`	オプション: `ptpClockThreshold` が存在しない場合、`ptpClockThreshold` フィールドにはデフォルト値が使用されます。`ptpClockThreshold` は、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。`holdOverTimeout` は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が `FREERUN` に変わるまでの時間値 (秒単位) です。`maxOffsetThreshold` および `minOffsetThreshold` 設定は、`CLOCK_REALTIME` (`phc2sys`) またはマスターオフセット (`ptp4l`) の値と比較するナノ秒単位のオフセット値を設定します。`ptp4l` または `phc2sys` のオフセット値がこの範囲外の場合、PTP クロックの状態が `FREERUN` に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が `LOCKED` に設定されます。
`recommend`	`profile` がノードに適用される方法を定義する 1 つ以上の `recommend` オブジェクトの配列を指定します。
`.recommend.profile`	`profile` セクションで定義される `.recommend.profile` オブジェクト名を指定します。
`.recommend.priority`	通常クロックの `.recommend.priority` を `0` に設定します。
`.recommend.match`	`.recommend.match` ルールを `nodeLabel` または `nodeName` の値に指定します。
`.recommend.match.nodeLabel`	`oc get Nodes --show-labels` コマンドを使用して、ノードオブジェクトの `node.Labels` フィールドの `key` で `nodeLabel` を設定します。例: `node-role.kubernetes.io/worker`。
`.recommend.match.nodeName`	`oc get nodes` コマンドを使用して、`nodeName` をノードオブジェクトの `node.Name` フィールドの値に設定します。`compute-1.example.com` はその例です。

次のコマンドを実行して、 PtpConfig CR を作成します。
```
oc create -f ordinary-clock-ptp-config.yaml
```
```
$ oc create -f ordinary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

検証

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

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2 -s
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

15.5.4. linuxptp サービスを境界クロックとして設定
リンクのコピー

PtpConfig カスタムリソース (CR) オブジェクトを作成して、linuxptp サービス (ptp4l、phc2sys を設定できます。

注記

次の例の PtpConfig CR を、特定のハードウェアおよび環境の境界クロックとして linuxptp サービスを設定する基礎として使用します。この例の CR は PTP 高速イベントを設定しません。PTP 高速イベントを設定するには、ptp4lOpts、ptp4lConf、ptpClockThreshold に適切な値を設定します。ptpClockThreshold は、イベントが有効になっている場合にのみ使用されます。詳細は、「PTP 高速イベント通知パブリッシャーの設定」を参照してください。

前提条件

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

手順

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

PTP 境界クロックの設定例

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: boundary-clock
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: boundary-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: boundary-clock
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: boundary-clock
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

Copy to Clipboard

Toggle word wrap

Expand

表15.2 PTP 境界クロックの CR 設定オプション
カスタムリソースフィールド	説明
`name`	`PtpConfig` CR の名前。
`profile`	1 つ以上の `profile` オブジェクトの配列を指定します。
`name`	プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。
`ptp4lOpts`	`ptp4l` サービスのシステム設定オプションを指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名 `-i <interface>` およびサービス設定ファイル `-f /etc/ptp4l.conf` を含めないでください。
`ptp4lConf`	`ptp4l` を境界クロックとして起動するために必要な設定を指定します。たとえば、`ens1f0` はグランドマスタークロックから同期し、`ens1f3` は接続されたデバイスを同期します。
`<interface_1>`	同期クロックを受信するインターフェイス。
`<interface_2>`	Synchronization クロックを送信するインターフェイス。
`tx_timestamp_timeout`	Intel Columbiaville 800 Series NIC の場合、`tx_timestamp_timeout` を `50` に設定します。
`boundary_clock_jbod`	Intel Columbiaville 800 Series NIC の場合、`boundary_clock_jbod` が `0` に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、`boundary_clock_jbod` が `1` に設定されていることを確認します。
`phc2sysOpts`	`phc2sys` サービスのシステム設定オプションを指定します。このフィールドが空の場合、PTP Operator は `phc2sys` サービスを開始しません。
`ptpSchedulingPolicy`	ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は `SCHED_OTHER` です。FIFO スケジューリングをサポートするシステムでは、`SCHED_FIFO` を使用してください。
`ptpSchedulingPriority`	`ptp SchedulingPolicy` が `SCHED_FIFO` に設定されている場合に、`ptp4l` および `phc2sys` プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。`ptpSchedulingPriority` フィールドは、`ptpSchedulingPolicy` が `SCHED_OTHER` に設定されている場合は使用されません。
`ptpClockThreshold`	オプション: `ptpClockThreshold` が存在しない場合、`ptpClockThreshold` フィールドにはデフォルト値が使用されます。`ptpClockThreshold` は、PTP マスタークロックが切断されてから PTP イベントが発生するまでの時間を設定します。`holdOverTimeout` は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が `FREERUN` に変わるまでの時間値 (秒単位) です。`maxOffsetThreshold` および `minOffsetThreshold` 設定は、`CLOCK_REALTIME` (`phc2sys`) またはマスターオフセット (`ptp4l`) の値と比較するナノ秒単位のオフセット値を設定します。`ptp4l` または `phc2sys` のオフセット値がこの範囲外の場合、PTP クロックの状態が `FREERUN` に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が `LOCKED` に設定されます。
`recommend`	`profile` がノードに適用される方法を定義する 1 つ以上の `recommend` オブジェクトの配列を指定します。
`.recommend.profile`	`profile` セクションで定義される `.recommend.profile` オブジェクト名を指定します。
`.recommend.priority`	`0` から `99` までの整数値で `priority` を指定します。数値が大きいほど優先度が低くなるため、`99` の優先度は `10` よりも低くなります。ノードが `match` フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。
`.recommend.match`	`.recommend.match` ルールを `nodeLabel` または `nodeName` の値に指定します。
`.recommend.match.nodeLabel`	`oc get Nodes --show-labels` コマンドを使用して、ノードオブジェクトの `node.Labels` フィールドの `key` で `nodeLabel` を設定します。例: `node-role.kubernetes.io/worker`。
`.recommend.match.nodeName`	`oc get nodes` コマンドを使用して、`nodeName` をノードオブジェクトの `node.Name` フィールドの値に設定します。`compute-1.example.com` はその例です。

以下のコマンドを実行して CR を作成します。
```
oc create -f boundary-clock-ptp-config.yaml
```
```
$ oc create -f boundary-clock-ptp-config.yaml
```
Copy to Clipboard Toggle word wrap

検証

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

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r -n 24
I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

Copy to Clipboard

Toggle word wrap

15.5.5. linuxptp サービスをデュアル NIC ハードウェアの境界クロックとして設定
リンクのコピー

重要

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

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

NIC ごとに PtpConfig カスタムリソース (CR) オブジェクトを作成することにより、linuxptp サービス (ptp4l、phc2sys) をデュアル NIC ハードウェアの境界クロックとして設定できます。

デュアル NIC ハードウェアを使用すると、各 NIC を同じアップストリームリーダークロックに接続し、NIC ごとに個別の ptp4l インスタンスをダウンストリームクロックに供給することができます。

前提条件

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

手順

linuxptp サービスを境界クロックとして設定の参照 CR を各 CR の基礎として使用して、NIC ごとに 1 つずつ、2 つの個別の PtpConfigCR を作成します。以下に例を示します。

phc2sysOpts の値を指定して、boundary-clock-ptp-config-nic1.yaml を作成します。

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic1
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile1"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens5f1]
      masterOnly 1
      [ens5f0]
      masterOnly 0
    ...
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"

2

Copy to Clipboard

Toggle word wrap

1: ptp4l を境界クロックとして開始するために必要なインターフェイスを指定します。たとえば、ens5f0 はグランドマスタークロックから同期し、ens5f1 は接続された機器から同期します。
2: phc2sysOpts の値が必要です。-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

boundary-clock-ptp-config-nic2.yaml を作成し、phc2sysOpts フィールドを完全に削除して、2 番目の NIC の phc2sys サービスを無効にします。

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: | 
      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-clock-ptp-config-nic2
  namespace: openshift-ptp
spec:
  profile:
  - name: "profile2"
    ptp4lOpts: "-2 --summary_interval -4"
    ptp4lConf: |

1


      [ens7f1]
      masterOnly 1
      [ens7f0]
      masterOnly 0
...

Copy to Clipboard

Toggle word wrap

1: 2 番目の NIC の境界クロックとして ptp4l を開始するために必要なインターフェイスを指定します。

注記

2 番目の NIC で phc2sys サービスを無効にするには、2 番目の PtpConfig CR から phc2sysOpts フィールドを完全に削除する必要があります。

次のコマンドを実行して、デュアル NIC PtpConfigCR を作成します。
1. 1 番目の NIC の PTP を設定する CR を作成します。
  $ oc create -f boundary-clock-ptp-config-nic1.yaml
  Copy to Clipboard Toggle word wrap
2. 2 番目の NIC の PTP を設定する CR を作成します。
  $ oc create -f boundary-clock-ptp-config-nic2.yaml
  Copy to Clipboard Toggle word wrap

検証

PTP Operator が両方の NIC に PtpConfigCR を適用していることを確認してください。デュアル NIC ハードウェアがインストールされているノードに対応する linuxptp デーモンのログを調べます。たとえば、以下のコマンドを実行します。

oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

$ oc logs linuxptp-daemon-cvgr6 -n openshift-ptp -c linuxptp-daemon-container

Copy to Clipboard

Toggle word wrap

出力例

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

ptp4l[80828.335]: [ptp4l.1.config] master offset          5 s2 freq   -5727 path delay       519
ptp4l[80828.343]: [ptp4l.0.config] master offset         -5 s2 freq  -10607 path delay       533
phc2sys[80828.390]: [ptp4l.0.config] CLOCK_REALTIME phc offset         1 s2 freq  -87239 delay    539

Copy to Clipboard

Toggle word wrap

15.5.6. PTP 通常クロックの参照としての IntelColumbiavilleE800 シリーズ NIC
リンクのコピー

次の表に、Intel Columbiaville E800 シリーズ NIC を通常のクロックとして使用するために参照 PTP 設定に加える必要のある変更を示します。クラスターに適用する PtpConfig カスタムリソース (CR) に変更を加えます。

Expand

表15.3 Intel Columbiaville NIC の推奨 PTP 設定
PTP 設定	推奨設定
`phc2sysOpts`	`-a -r -m -n 24 -N 8 -R 16`
`tx_timestamp_timeout`	`50`
`boundary_clock_jbod`	`0`

注記

phc2sysOpts の場合、-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

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

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

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

注記

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

手順

Ptp Config CR プロファイルを編集します。
```
oc edit PtpConfig -n openshift-ptp
```
```
$ oc edit PtpConfig -n openshift-ptp
```
Copy to Clipboard Toggle word wrap

ptp Scheduling Policy と ptp Scheduling Priority フィールドを変更します。

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO 
    ptpSchedulingPriority: 10

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: <ptp_config_name>
  namespace: openshift-ptp
...
spec:
  profile:
  - name: "profile1"
...
    ptpSchedulingPolicy: SCHED_FIFO

1


    ptpSchedulingPriority: 10

2

Copy to Clipboard

Toggle word wrap

1: ptp4l と phc2sys プロセスのスケジューリングポリシー。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO を使用してください。
2: 必須。ptp4l および phc2sys プロセスの FIFO 優先度の設定に使用する 1～65 の整数値を設定します。

保存して終了すると、Ptp ConfigCR に変更が適用されます。

検証

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

Copy to Clipboard

Toggle word wrap

15.6. 一般的な PTP Operator の問題のトラブルシューティング
リンクのコピー

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

前提条件

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

手順

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

注記

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

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

NAME                                  AGE
control-plane-0.example.com           10d
control-plane-1.example.com           10d
compute-0.example.com                 10d
compute-1.example.com                 10d
compute-2.example.com                 10d

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<node_name>

問い合わせるノードを指定します (例: compute-0.example.com )。

出力例

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

apiVersion: ptp.openshift.io/v1
kind: NodePtpDevice
metadata:
  creationTimestamp: "2021-09-14T16:52:33Z"
  generation: 1
  name: compute-0.example.com
  namespace: openshift-ptp
  resourceVersion: "177400"
  uid: 30413db0-4d8d-46da-9bef-737bacd548fd
spec: {}
status:
  devices:
  - name: eno1
  - name: eno2
  - name: eno3
  - name: eno4
  - name: enp5s0f0
  - name: enp5s0f1

Copy to Clipboard

Toggle word wrap

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

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

oc get pods -n openshift-ptp -o wide

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

Copy to Clipboard

Toggle word wrap

リモートシェルが必要な linuxptp-daemon コンテナーへのリモートシェルです。
```
oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
```
$ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<linux_daemon_container>
診断するコンテナーです (例: linuxptp-daemon-lmvgn)。

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

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

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

Copy to Clipboard

Toggle word wrap

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

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

sending: GET PORT_DATA_SET
    40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
        portIdentity            40a6b7.fffe.166ef0-1
        portState               SLAVE
        logMinDelayReqInterval  -4
        peerMeanPathDelay       0
        logAnnounceInterval     -3
        announceReceiptTimeout  3
        logSyncInterval         -4
        delayMechanism          1
        logMinPdelayReqInterval -4
        versionNumber           2

Copy to Clipboard

Toggle word wrap

15.6.1. Precision Time Protocol (PTP) Operator データの収集
リンクのコピー

oc adm must-gather CLI コマンドを使用して、クラスターに関する情報を収集できます。これには、Precision Time Protocol (PTP) Operator に関連する機能およびオブジェクトが含まれます。

前提条件

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

手順

must-gather を使用して PTP Operator データを収集するには、PTP Operator must-gather イメージを指定する必要があります。
```
oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.11
```
```
$ oc adm must-gather --image=registry.redhat.io/openshift4/ptp-must-gather-rhel8:v4.11
```
Copy to Clipboard Toggle word wrap

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

15.7.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 通常クロックまたは PTP 境界クロックを使用するように設定されたネットワークインターフェイスで使用できます。

15.7.2. PTP 高速イベント通知フレームワークについて
リンクのコピー

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

図15.1 PTP 高速イベントの概要

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 高速イベントを使用する方法について説明します。

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

15.7.3. AMQ メッセージングバスのインストール
リンクのコピー

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

前提条件

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

手順

AMQ Interconnect Operator を独自の amq-interconnect namespace にインストールします。Red Hat Integration - AMQ Interconnect Operator の追加を参照してください。

検証

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

oc get pods -n amq-interconnect

$ oc get pods -n amq-interconnect

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

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

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

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

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

前提条件

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

手順

デフォルトの PTP Operator 設定を変更して、PTP 高速イベントを有効にします。

次の YAML をptp-operatorconfig.yamlファイルに保存します。

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true 
    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  ptpEventConfig:
    enableEventPublisher: true

1


    transportHost: amqp://<instance_name>.<namespace>.svc.cluster.local

2

Copy to Clipboard

Toggle word wrap

1: enableEventPublisher を true に設定して、PTP 高速イベント通知を有効にします。
2: transportHost を、設定した AMQ ルーターに設定します。<instance_name> および <namespace> は AMQ Interconnect ルーターインスタンス名および namespace に対応します (例: amqp://amq-interconnect.amq-interconnect.svc.cluster.local)。

PtpOperatorConfig CR を更新します。
```
oc apply -f ptp-operatorconfig.yaml
```
```
$ oc apply -f ptp-operatorconfig.yaml
```
Copy to Clipboard Toggle word wrap

PTP 対応インターフェイスの PtpConfig カスタムリソースを作成し、ptpClockThreshold および ptp4lOpts に必要な値を設定します。次の YAML は、PtpConfig CR で設定する必要のある値 (必須) を示しています。
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
    ptp4lConf: "" 
    ptpClockThreshold: 
      holdOverTimeout: 5
      maxOffsetThreshold: 100
      minOffsetThreshold: -100
```
```
spec:
  profile:
  - name: "profile1"
    interface: "enp5s0f0"
    ptp4lOpts: "-2 -s --summary_interval -4" 
```
1
```
    phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 
```
2
```
    ptp4lConf: "" 
```
3
```
    ptpClockThreshold: 
```
4
```
      holdOverTimeout: 5
      maxOffsetThreshold: 100
      minOffsetThreshold: -100
```
Copy to Clipboard Toggle word wrap
1
--summary_interval -4を追加して、PTP 高速イベントを使用します。
2
phc2sysOpts の値が必要です。-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。
3
デフォルトの /etc/ptp4l.conf ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。
4
オプション: ptpClockThreshold スタンザが存在しない場合は、ptpClockThreshold フィールドにデフォルト値が使用されます。スタンザは、デフォルトの ptpClockThreshold 値を示します。ptpClockThreshold 値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeout は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が FREERUN に変わるまでの時間値 (秒単位) です。maxOffsetThreshold および minOffsetThreshold 設定は、CLOCK_REALTIME (phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l または phc2sys のオフセット値がこの範囲外の場合、PTP クロックの状態が FREERUN に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が LOCKED に設定されます。

15.7.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 エンドポイントを使用して、DU アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーによってポストされた PTP イベントに cloud-event-consumer DU アプリケーションをサブスクライブします。

/api/ocloudNotifications/v1/subscriptions
- POST: 新しいサブスクリプションを作成します。
- GET: サブスクリプションの一覧を取得します。
/api/ocloudNotifications/v1/subscriptions/<subscription_id>
- GET: 指定されたサブスクリプション ID の詳細を返します。
/api/ocloudNotifications/v1/health
- GET: ocloudNotifications API の正常性ステータスを返します
api/ocloudNotifications/v1/publishers
- GET: クラスターノードの os-clock-sync-state、ptp-clock-class-change、および lock-state メッセージの配列を返します
/api/ocloudnotifications/v1/<resource_address>/CurrentState
- GET: 次のいずれかのイベントタイプの現在の状態を返します: os-clock-sync-state、ptp-clock-class-change、または lock-state イベント

注記

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

15.7.5.1. api/ocloudNotifications/v1/subscriptions
リンクのコピー

HTTP メソッド

GET api/ocloudNotifications/v1/subscriptions

説明

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

API 応答の例

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

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

Copy to Clipboard

Toggle word wrap

HTTP メソッド

POST api/ocloudNotifications/v1/subscriptions

説明

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

Expand

表15.4 クエリーパラメーター
パラメーター	型
subscription	data

ペイロードの例

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

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

Copy to Clipboard

Toggle word wrap

15.7.5.2. api/ocloudNotifications/v1/subscriptions/
リンクのコピー

HTTP メソッド

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

説明

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

Expand

表15.5 クエリーパラメーター
パラメーター	型
`<subscription_id>`	string

API 応答の例

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

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

Copy to Clipboard

Toggle word wrap

15.7.5.3. api/ocloudNotifications/v1/health/
リンクのコピー

HTTP メソッド

GET api/ocloudNotifications/v1/health/

説明

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

API 応答の例

OK

OK

Copy to Clipboard

Toggle word wrap

15.7.5.4. api/ocloudNotifications/v1/publishers
リンクのコピー

HTTP メソッド

GET api/ocloudNotifications/v1/publishers

説明

クラスターノードの os-clock-sync-state、ptp-clock-class-change、および lock-state の 詳細の配列を返します。関連する機器の状態が変化すると、システムは通知を生成します。

os-clock-sync-state 通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKED または FREERUN 状態になります。
ptp-clock-class-change 通知は、PTP クロッククラスの現在の状態を示します。
lock-state 通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、または FREERUN 状態になります。

API 応答の例

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

[
  {
    "id": "0fa415ae-a3cf-4299-876a-589438bacf75",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/0fa415ae-a3cf-4299-876a-589438bacf75",
    "resource": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state"
  },
  {
    "id": "28cd82df-8436-4f50-bbd9-7a9742828a71",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/28cd82df-8436-4f50-bbd9-7a9742828a71",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change"
  },
  {
    "id": "44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "endpointUri": "http://localhost:9085/api/ocloudNotifications/v1/dummy",
    "uriLocation": "http://localhost:9085/api/ocloudNotifications/v1/publishers/44aa480d-7347-48b0-a5b0-e0af01fa9677",
    "resource": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state"
  }
]

Copy to Clipboard

Toggle word wrap

cloud-event-proxy コンテナーのログで、os-clock-sync-state、ptp-clock-class-change、および lock-state イベントを見つけることができます。以下に例を示します。

oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

$ oc logs -f linuxptp-daemon-cvgr6 -n openshift-ptp -c cloud-event-proxy

Copy to Clipboard

Toggle word wrap

os-clock-sync-state イベントの例

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

{
   "id":"c8a784d1-5f4a-4c16-9a81-a3b4313affe5",
   "type":"event.sync.sync-status.os-clock-sync-state-change",
   "source":"/cluster/compute-1.example.com/ptp/CLOCK_REALTIME",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.906277159Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/sync-status/os-clock-sync-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"-53"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

ptp-clock-class-change イベントの例

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

{
   "id":"69eddb52-1650-4e56-b325-86d44688d02b",
   "type":"event.sync.ptp-status.ptp-clock-class-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.147100033Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/ptp-clock-class-change",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"135"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

ロック状態イベントの例

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

{
   "id":"305ec18b-1472-47b3-aadd-8f37933249a9",
   "type":"event.sync.ptp-status.ptp-state-change",
   "source":"/cluster/compute-1.example.com/ptp/ens2fx/master",
   "dataContentType":"application/json",
   "time":"2022-05-06T15:31:23.467684081Z",
   "data":{
      "version":"v1",
      "values":[
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"notification",
            "valueType":"enumeration",
            "value":"LOCKED"
         },
         {
            "resource":"/sync/ptp-status/lock-state",
            "dataType":"metric",
            "valueType":"decimal64.3",
            "value":"62"
         }
      ]
   }
}

Copy to Clipboard

Toggle word wrap

15.7.5.5. /api/ocloudnotifications/v1//CurrentState
リンクのコピー

HTTP メソッド

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/lock-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/sync-status/os-clock-sync-state/CurrentState

GET api/ocloudNotifications/v1/cluster/node/<node_name>/sync/ptp-status/ptp-clock-class-change/CurrentState

説明

クラスターノードの os-clock-sync-state、ptp-clock-class-change、または lock-state イベントの現在の状態を返すように CurrentState API エンドポイントを設定します。

os-clock-sync-state 通知は、ホストオペレーティングシステムのクロック同期状態を示します。LOCKED または FREERUN 状態になります。
ptp-clock-class-change 通知は、PTP クロッククラスの現在の状態を示します。
lock-state 通知は、PTP 機器のロック状態の現在のステータスを示します。LOCKED、HOLDOVER、または FREERUN 状態になります。

Expand

表15.6 クエリーパラメーター
パラメーター	型
`<resource_address>`	string

ロック状態 API レスポンスの例

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

{
  "id": "c1ac3aa5-1195-4786-84f8-da0ea4462921",
  "type": "event.sync.ptp-status.ptp-state-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/lock-state",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:57.094981478Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "29"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

os-clock-sync-state API レスポンスの例

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

{
  "specversion": "0.3",
  "id": "4f51fe99-feaa-4e66-9112-66c5c9b9afcb",
  "source": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "type": "event.sync.sync-status.os-clock-sync-state-change",
  "subject": "/cluster/node/compute-1.example.com/sync/sync-status/os-clock-sync-state",
  "datacontenttype": "application/json",
  "time": "2022-11-29T17:44:22.202Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "notification",
        "valueType": "enumeration",
        "value": "LOCKED"
      },
      {
        "resource": "/cluster/node/compute-1.example.com/CLOCK_REALTIME",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "27"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

ptp-clock-class-change API レスポンスの例

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

{
  "id": "064c9e67-5ad4-4afb-98ff-189c6aa9c205",
  "type": "event.sync.ptp-status.ptp-clock-class-change",
  "source": "/cluster/node/compute-1.example.com/sync/ptp-status/ptp-clock-class-change",
  "dataContentType": "application/json",
  "time": "2023-01-10T02:41:56.785673989Z",
  "data": {
    "version": "v1",
    "values": [
      {
        "resource": "/cluster/node/compute-1.example.com/ens5fx/master",
        "dataType": "metric",
        "valueType": "decimal64.3",
        "value": "165"
      }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

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

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

注記

PTP 高速イベント通知メトリックは OpenShift Container Platform Web コンソールでも利用できます。

前提条件

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

手順

アクティブな linuxptp-daemon Pod のリストを取得します。

oc get pods -n openshift-ptp

$ oc get pods -n openshift-ptp

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、必要な cloud-event-proxy コンテナーのメトリックにアクセスします。

oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

$ oc exec -it <linuxptp-daemon> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<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
HELP cne_amqp_events_received Metric to get number of events received  by the transport
TYPE cne_amqp_events_received gauge
HELP cne_amqp_receiver Metric to get number of receiver created
TYPE cne_amqp_receiver gauge

# 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"}
...

Copy to Clipboard

Toggle word wrap

15.7.7. Web コンソールでの PTP 高速イベントメトリックの監視
リンクのコピー

事前に設定された自己更新型の Prometheus モニタリングスタックを使用して、OpenShift Container Platform Web コンソールで PTP 高速イベントメトリクスをモニタリングできます。

前提条件

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

手順

以下のコマンドを実行して、cloud-event-proxy サイドカーコンテナーから利用可能な PTP メトリックのリストを返します。
```
oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
```
$ oc exec -it <linuxptp_daemon_pod> -n openshift-ptp -c cloud-event-proxy -- curl 127.0.0.1:9091/metrics
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<linuxptp_daemon_pod>
問い合わせる Pod を指定します (例: linuxptp-daemon-2t78p)。
返されるメトリックのリストから問い合わせる PTP メトリックの名前 (例: cne_amqp_events_received) をコピーします。
OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。
PTP メトリックを Expression フィールドに貼り付け、Run queries をクリックします。

第16章外部 DNS Operator
リンクのコピー

16.1. OpenShift Container Platform の外部 DNS Operator
リンクのコピー

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

16.1.1. 外部 DNS Operator
リンクのコピー

外部 DNS Operator は、olm.openshift.io API グループから外部 DNS API を実装します。外部 DNS Operator は、デプロイメントリソースを使用して ExternalDNS をデプロイします。外部 DNS デプロイメントは、クラスター内のサービスやルートなどのリソースを監視し、外部 DNS プロバイダーを更新します。

手順

OperatorHub からオンデマンドで ExternalDNS Operator をデプロイできます。これにより、Subscription オブジェクトが作成されます。

インストールプランの名前を確認してください。

oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

$ oc -n external-dns-operator get sub external-dns-operator -o yaml | yq '.status.installplan.name'

Copy to Clipboard

Toggle word wrap

出力例

install-zcvlr

install-zcvlr

Copy to Clipboard

Toggle word wrap

インストールプランのステータスを確認します。インストールプランのステータスは Complete でなければなりません。
```
oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
```
```
$ oc -n external-dns-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
```
Copy to Clipboard Toggle word wrap
出力例
```
Complete
```
```
Complete
```
Copy to Clipboard Toggle word wrap

oc get コマンドを使用して Deployment ステータスを表示します。

oc get -n external-dns-operator deployment/external-dns-operator

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

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

16.1.2. 外部 DNS Operator ログ
リンクのコピー

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

手順

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

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

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

Copy to Clipboard

Toggle word wrap

16.1.2.1. 外部 DNS Operator のドメイン名の制限
リンクのコピー

外部 DNS Operator は、新しい形式に従って TXT レコードの接頭辞を追加する TXT レジストリーを使用します。これにより、TXT レコードのドメイン名の最大長が短くなります。DNS レコードは対応する TXT レコードなしでは存在できないため、DNS レコードのドメイン名は TXT レコードと同じ制限に従う必要があります。たとえば、DNS レコードは <domain-name-from-source> で、TXT レコードは external-dns-<record-type>-<domain-name-from-source> です。

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

Expand

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

外部 DNS によって生成されたドメイン名がドメイン名の制限を超えている場合、外部 DNS インスタンスは次のエラーを返します。

oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

$ oc -n external-dns-operator logs external-dns-aws-7ddbd9c7f8-2jqjh

1

Copy to Clipboard

Toggle word wrap

1: external-dns-aws-7ddbd9c7f8-2jqjh パラメーターは、外部 DNS Pod の名前を指定します。

出力例

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

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

Copy to Clipboard

Toggle word wrap

16.2. クラウドプロバイダーへの外部 DNS Operator のインストール
リンクのコピー

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

16.2.1. 外部 DNS Operator のインストール
リンクのコピー

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

手順

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

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

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

検証

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

16.3. 外部 DNS Operator 設定パラメーター
リンクのコピー

外部 DNS Operator には、次の設定パラメーターが含まれています。

16.3.1. 外部 DNS Operator 設定パラメーター
リンクのコピー

外部 DNS Operator には、次の設定パラメーターが含まれています。

Expand

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

16.4. AWS での DNS レコードの作成
リンクのコピー

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

16.4.1. Red Hat 外部 DNS Operator を使用した AWS のパブリックホストゾーンへの DNS レコードの作成
リンクのコピー

Red Hat 外部 DNS Operator を使用して、AWS のパブリックホストゾーンに DNS レコードを作成できます。同じ手順を使用して、AWS GovCloud のホストゾーンに DNS レコードを作成できます。

手順

ユーザーを確認してください。ユーザーは、 kube-systemnamespace にアクセスできる必要があります。クレデンシャルがない場合は、 kube-systemnamespace からクレデンシャルを取得すると、クラウドプロバイダークライアントを使用できます。
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
出力例
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

kube-systemnamespace に存在する aws-creds シークレットから値を取得します。

export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

$ export AWS_ACCESS_KEY_ID=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_access_key_id}} | base64 -d)
$ export AWS_SECRET_ACCESS_KEY=$(oc get secrets aws-creds -n kube-system  --template={{.data.aws_secret_access_key}} | base64 -d)

Copy to Clipboard

Toggle word wrap

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

oc get routes --all-namespaces | grep console

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

Copy to Clipboard

Toggle word wrap

出力例

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.testextdnsoperator.apacshift.support                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.testextdnsoperator.apacshift.support                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

route ソースの ExternalDNS リソースを作成します。
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
spec:
  domains:
  - filterType: Include   
    matchType: Exact   
    name: testextdnsoperator.apacshift.support 
  provider:
    type: AWS 
  source:  
    type: OpenShiftRoute 
    openshiftRouteOptions:
      routerName: default 
EOF
```
```
$ cat <<EOF | oc create -f -
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-aws 
```
1
```
spec:
  domains:
  - filterType: Include   
```
2
```
    matchType: Exact   
```
3
```
    name: testextdnsoperator.apacshift.support 
```
4
```
  provider:
    type: AWS 
```
5
```
  source:  
```
6
```
    type: OpenShiftRoute 
```
7
```
    openshiftRouteOptions:
      routerName: default 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
外部 DNS リソースの名前を定義します。
2
デフォルトでは、すべてのホストゾーンがターゲット候補として選択されます。必要なホストゾーンを追加できます。
3
ターゲットゾーンのドメインは、(正規表現の一致とは対照的に) 完全一致である必要があります。
4
更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
5
AWS Route53DNSプロバイダーを定義します。
6
DNS レコードのソースのオプションを定義します。
7
以前に指定された DNS プロバイダーで作成される DNS レコードのソースとして OpenShift route リソースを定義します。
8
ソースが OpenShiftRoute の場合に、OpenShift Ingress Controller 名を指定できます。外部 DNS Operator は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。

次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。

aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

$ aws route53 list-resource-record-sets --hosted-zone-id Z02355203TNN1XXXX1J6O --query "ResourceRecordSets[?Type == 'CNAME']" | grep console

Copy to Clipboard

Toggle word wrap

16.5. Azure での DNS レコードの作成
リンクのコピー

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

16.5.1. Red Hat 外部 DNS Operator を使用した Azure のパブリック DNS ゾーンへの DNS レコードの作成
リンクのコピー

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

手順

ユーザーを確認してください。ユーザーは、 kube-systemnamespace にアクセスできる必要があります。クレデンシャルがない場合は、 kube-systemnamespace からクレデンシャルを取得すると、クラウドプロバイダークライアントを使用できます。
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
出力例
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

kube-system namespace に存在する azure-credentials シークレットから値を取得します。

CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

$ CLIENT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_id}} | base64 -d)
$ CLIENT_SECRET=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_client_secret}} | base64 -d)
$ RESOURCE_GROUP=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_resourcegroup}} | base64 -d)
$ SUBSCRIPTION_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_subscription_id}} | base64 -d)
$ TENANT_ID=$(oc get secrets azure-credentials  -n kube-system  --template={{.data.azure_tenant_id}} | base64 -d)

Copy to Clipboard

Toggle word wrap

base64 でデコードされた値を使用して azure にログインします。

az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

$ az login --service-principal -u "${CLIENT_ID}" -p "${CLIENT_SECRET}" --tenant "${TENANT_ID}"

Copy to Clipboard

Toggle word wrap

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

oc get routes --all-namespaces | grep console

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

Copy to Clipboard

Toggle word wrap

出力例

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.azure.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.azure.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

DNS ゾーンのリストを取得して、以前に検出されたルートのドメインに対応するものを検索します。
```
az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
```
$ az network dns zone list --resource-group "${RESOURCE_GROUP}"
```
Copy to Clipboard Toggle word wrap

route ソースの ExternalDNS リソースを作成します。

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

apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-azure

1


spec:
  zones:
  - "/subscriptions/1234567890/resourceGroups/test-azure-xxxxx-rg/providers/Microsoft.Network/dnszones/test.azure.example.com"

2


  provider:
    type: Azure

3


  source:
    openshiftRouteOptions:

4


      routerName: default

5


    type: OpenShiftRoute

6

EOF

Copy to Clipboard

Toggle word wrap

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

次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。
```
az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
```
$ az network dns record-set list -g "${RESOURCE_GROUP}"  -z test.azure.example.com | grep console
```
Copy to Clipboard Toggle word wrap
注記
プライベート Azure DNS のプライベートホストゾーンにレコードを作成するには、ゾーンの下にプライベートゾーンを指定する必要があります。ゾーンは、ExternalDNSコンテナー引数でプロバイダータイプをazure-private-dnsに設定します。

16.6. GCP での DNS レコードの作成
リンクのコピー

外部 DNS Operator を使用して、GCP で DNS レコードを作成できます。

16.6.1. Red Hat 外部 DNS Operator を使用した GCP のパブリックマネージドゾーンへの DNS レコードの作成
リンクのコピー

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

手順

ユーザーを確認してください。ユーザーは、 kube-systemnamespace にアクセスできる必要があります。クレデンシャルがない場合は、 kube-systemnamespace からクレデンシャルを取得すると、クラウドプロバイダークライアントを使用できます。
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
出力例
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

Google のクレデンシャルをエクスポートします。
```
export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
```
$ export GOOGLE_CREDENTIALS=decoded-gcloud.json
```
Copy to Clipboard Toggle word wrap

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

gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

$ gcloud auth activate-service-account  <client_email as per decoded-gcloud.json> --key-file=decoded-gcloud.json

Copy to Clipboard

Toggle word wrap

プロジェクトを設定します。

gcloud config set project <project_id as per decoded-gcloud.json>

$ gcloud config set project <project_id as per decoded-gcloud.json>

Copy to Clipboard

Toggle word wrap

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

oc get routes --all-namespaces | grep console

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

Copy to Clipboard

Toggle word wrap

出力例

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.gcp.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.gcp.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

管理対象ゾーンのリストを取得して、以前に検出されたルートのドメインに対応するゾーンを見つけます。
```
gcloud dns managed-zones list | grep test.gcp.example.com
```
```
$ gcloud dns managed-zones list | grep test.gcp.example.com
qe-cvs4g-private-zone test.gcp.example.com
```
Copy to Clipboard Toggle word wrap
route ソースの ExternalDNS リソースを作成します。
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
spec:
  domains:
    - filterType: Include 
      matchType: Exact 
      name: test.gcp.example.com 
  provider:
    type: GCP 
  source:
    openshiftRouteOptions: 
      routerName: default 
    type: OpenShiftRoute 
EOF
```
```
apiVersion: externaldns.olm.openshift.io/v1beta1
kind: ExternalDNS
metadata:
  name: sample-gcp 
```
1
```
spec:
  domains:
    - filterType: Include 
```
2
```
      matchType: Exact 
```
3
```
      name: test.gcp.example.com 
```
4
```
  provider:
    type: GCP 
```
5
```
  source:
    openshiftRouteOptions: 
```
6
```
      routerName: default 
```
7
```
    type: OpenShiftRoute 
```
8
```
EOF
```
Copy to Clipboard Toggle word wrap
1
外部 DNS CR の名前を指定します。
2
デフォルトでは、すべてのホストゾーンがターゲット候補として選択されます。必要なホストゾーンを追加できます。
3
ターゲットゾーンのドメインは、(正規表現の一致とは対照的に) 完全一致である必要があります。
4
更新するゾーンのドメインを正確に指定します。ルートのホスト名は、指定されたドメインのサブドメインである必要があります。
5
Google Cloud DNS プロバイダーを定義します。
6
DNS レコードのソースのオプションを定義できます。
7
ソースが OpenShiftRoute の場合、OpenShift Ingress Controller 名を指定できます。外部 DNS は、CNAME レコードの作成時に、そのルーターの正規のホスト名をターゲットとして選択します。
8
以前に指定された DNS プロバイダーで作成される DNS レコードのソースとして OpenShift route リソースを定義します。
次のコマンドを使用して、OCP ルート用に作成されたレコードを確認します。
```
gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
```
```
$ gcloud dns record-sets list --zone=qe-cvs4g-private-zone | grep console
```
Copy to Clipboard Toggle word wrap

16.7. Infoblox での DNS レコードの作成
リンクのコピー

Red Hat 外部 DNS Operator を使用して、Infoblox で DNS レコードを作成できます。

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

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

前提条件

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

手順

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

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

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

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、ルートオブジェクトを取得してクラスタードメインを確認します。

oc get routes --all-namespaces | grep console

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

Copy to Clipboard

Toggle word wrap

出力例

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

openshift-console          console             console-openshift-console.apps.test.example.com                       console             https   reencrypt/Redirect     None
openshift-console          downloads           downloads-openshift-console.apps.test.example.com                     downloads           http    edge/Redirect          None

Copy to Clipboard

Toggle word wrap

次のように、externalDNS リソースの YAML ファイル (たとえば sample-infoblox.yaml) を作成します。

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

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

Copy to Clipboard

Toggle word wrap

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

16.8. 外部 DNS Operator でのクラスター全体のプロキシーの設定
リンクのコピー

外部 DNS Operator でクラスター全体のプロキシーを設定できます。外部 DNS Operator でクラスター全体のプロキシーを設定した後、Operator Lifecycle Manager (OLM) は、Operator のすべてのデプロイメントを HTTP_PROXY、HTTPS_PROXY、および NO_PROXY などの環境変数で自動的に更新します。

16.8.1. クラスター全体のプロキシーの認証局を信頼するように外部 DNS Operator を設定する
リンクのコピー

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

手順

次のコマンドを実行して、external-dns-operator namespace に CA バンドルを含める config map を作成します。
```
oc -n external-dns-operator create configmap trusted-ca
```
```
$ oc -n external-dns-operator create configmap trusted-ca
```
Copy to Clipboard Toggle word wrap
信頼できる CA バンドルを config map に挿入するには、次のコマンドを実行して、config.openshift.io/inject-trusted-cabundle=true ラベルを config map に追加します。
```
oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
```
$ oc -n external-dns-operator label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、外部 DNS Operator のサブスクリプションを更新します。

oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

$ oc -n external-dns-operator patch subscription external-dns-operator --type='json' -p='[{"op": "add", "path": "/spec/config", "value":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}]'

Copy to Clipboard

Toggle word wrap

検証

外部 DNS Operator のデプロイ後、次のコマンドを実行して、信頼できる CA 環境変数が external-dns-operator デプロイメントに追加されていることを確認します。
```
oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
```
$ oc -n external-dns-operator exec deploy/external-dns-operator -c external-dns-operator -- printenv TRUSTED_CA_CONFIGMAP_NAME
```
Copy to Clipboard Toggle word wrap
出力例
```
trusted-ca
```
```
trusted-ca
```
Copy to Clipboard Toggle word wrap

第17章ネットワークポリシー
リンクのコピー

17.1. ネットワークポリシーについて
リンクのコピー

クラスター管理者は、トラフィックをクラスター内の Pod に制限するネットワークポリシーを定義できます。

17.1.1. ネットワークポリシーについて
リンクのコピー

Kubernetes ネットワークポリシーをサポートする Kubernetes Container Network Interface (CNI) プラグインを使用するクラスターでは、ネットワークの分離は NetworkPolicy オブジェクトによって完全に制御されます。OpenShift Container Platform 4.11 では、OpenShift SDN はデフォルトのネットワーク分離モードでのネットワークポリシーの使用をサポートしています。

警告

ネットワークポリシーは、ホストのネットワーク namespace には適用されません。ホストネットワークが有効にされている Pod はネットワークポリシールールによる影響を受けません。ただし、ホストネットワークの Pod に接続する Pod はネットワークポリシールールの影響を受ける可能性があります。

ネットワークポリシーは、ローカルホストまたは常駐ノードからのトラフィックをブロックすることはできません。

デフォルトで、プロジェクトのすべての Pod は他の Pod およびネットワークのエンドポイントからアクセスできます。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。プロジェクト管理者は独自のプロジェクト内で NetworkPolicy オブジェクトの作成および削除を実行できます。

Pod が 1 つ以上の NetworkPolicy オブジェクトのセレクターで一致する場合、Pod はそれらの 1 つ以上の NetworkPolicy オブジェクトで許可される接続のみを受け入れます。NetworkPolicy オブジェクトによって選択されていない Pod は完全にアクセス可能です。

ネットワークポリシーは、TCP、UDP、ICMP、および SCTP プロトコルにのみ適用されます。他のプロトコルは影響を受けません。

以下のサンプル NetworkPolicy オブジェクトは、複数の異なるシナリオをサポートすることを示しています。

すべてのトラフィックを拒否します。
プロジェクトに deny by default (デフォルトで拒否) を実行させるには、すべての Pod に一致するが、トラフィックを一切許可しない NetworkPolicy オブジェクトを追加します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []
```
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []
```
Copy to Clipboard Toggle word wrap

OpenShift Container Platform Ingress Controller からの接続のみを許可します。

プロジェクトで OpenShift Container Platform Ingress Controller からの接続のみを許可するには、以下の NetworkPolicy オブジェクトを追加します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

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

Copy to Clipboard

Toggle word wrap

プロジェクト内の Pod からの接続のみを受け入れます。
Pod が同じプロジェクト内の他の Pod からの接続を受け入れるが、他のプロジェクトの Pod からの接続を拒否するように設定するには、以下の NetworkPolicy オブジェクトを追加します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
```
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
```
Copy to Clipboard Toggle word wrap

Pod ラベルに基づいて HTTP および HTTPS トラフィックのみを許可します。

特定のラベル (以下の例の role=frontend) の付いた Pod への HTTP および HTTPS アクセスのみを有効にするには、以下と同様の NetworkPolicy オブジェクトを追加します。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http-and-https
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443

Copy to Clipboard

Toggle word wrap

namespace および Pod セレクターの両方を使用して接続を受け入れます。

namespace と Pod セレクターを組み合わせてネットワークトラフィックのマッチングをするには、以下と同様の NetworkPolicy オブジェクトを使用できます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-pod-and-namespace-both
spec:
  podSelector:
    matchLabels:
      name: test-pods
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            project: project_name
        podSelector:
          matchLabels:
            name: test-pods

Copy to Clipboard

Toggle word wrap

NetworkPolicy オブジェクトは加算されるものです。つまり、複数の NetworkPolicy オブジェクトを組み合わせて複雑なネットワーク要件を満すことができます。

たとえば、先の例で定義された NetworkPolicy オブジェクトの場合、同じプロジェト内に allow-same-namespace と allow-http-and-https ポリシーの両方を定義することができます。これにより、ラベル role=frontend の付いた Pod は各ポリシーで許可されるすべての接続を受け入れます。つまり、同じ namespace の Pod からのすべてのポート、およびすべての namespace の Pod からのポート 80 および 443 での接続を受け入れます。

17.1.1.1. allow-from-router ネットワークポリシーの使用
リンクのコピー

次の NetworkPolicy を使用して、ルーターの設定に関係なく外部トラフィックを許可します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""

1


  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

1: policy-group.network.openshift.io/ingress:"" ラベルは、OpenShift-SDN と OVN-Kubernetes の両方をサポートします。

17.1.1.2. allow-from-hostnetwork ネットワークポリシーの使用
リンクのコピー

次の allow-from-hostnetwork NetworkPolicy オブジェクトを追加して、ホストネットワーク Pod からのトラフィックを転送します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress

Copy to Clipboard

Toggle word wrap

17.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 から許可する必要のある特定のトラフィックを可能にします。

17.1.3. 次のステップ
リンクのコピー

ネットワークポリシーの作成
オプション: デフォルトネットワークポリシーの定義

17.2. ネットワークポリシーイベントのロギング
リンクのコピー

クラスター管理者は、クラスターのネットワークポリシー監査ロギングを設定し、1 つ以上の namespace のロギングを有効にできます。

注記

ネットワークポリシーの監査ロギングは OVN-Kubernetes クラスターネットワークプロバイダーでのみ利用可能です。

17.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"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }

Copy to Clipboard

Toggle word wrap

ロギング形式は 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

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

Copy to Clipboard

Toggle word wrap

以下の表は、namespace アノテーションの値について説明しています。

Expand

表17.1 ネットワークポリシー監査ロギング namespace アノテーション
Annotation	値
`k8s.ovn.org/acl-logging`	namespace のネットワークポリシー監査ロギングを有効にするには、`allow`、`deny`、または両方のうち、少なくとも 1 つを指定する必要があります。 `deny` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。 `allow` オプション: `alert`、`warning`、`notice`、`info`、または `debug` を指定します。

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

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

以下の表は、ネットワークポリシー監査ロギングの設定フィールドについて説明しています。

Expand

表17.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` です。

17.2.3. クラスターのネットワークポリシー監査の設定
リンクのコピー

クラスター管理者は、クラスターのネットワークポリシー監査ロギングをカスタマイズできます。

前提条件

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

手順

ネットワークポリシーの監査ロギングの設定をカスタマイズするには、以下のコマンドを入力します。

oc edit network.operator.openshift.io/cluster

$ oc edit network.operator.openshift.io/cluster

Copy to Clipboard

Toggle word wrap

ヒント

または、以下の YAML をカスタマイズして適用することで、監査ロギングを設定できます。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0

Copy to Clipboard

Toggle word wrap

検証

ネットワークポリシーを使用して namespace を作成するには、次の手順を実行します。

検証用の namespace を作成します。

cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

$ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF

Copy to Clipboard

Toggle word wrap

出力例

namespace/verify-audit-logging created

namespace/verify-audit-logging created

Copy to Clipboard

Toggle word wrap

監査ロギングを有効にします。

oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

$ oc annotate namespace verify-audit-logging k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "alert" }'

Copy to Clipboard

Toggle word wrap

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

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

$ 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

Copy to Clipboard

Toggle word wrap

出力例

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created

Copy to Clipboard

Toggle word wrap

ソーストラフィックの Pod を default namespace に作成します。

cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

$ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF

Copy to Clipboard

Toggle word wrap

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

$ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done

Copy to Clipboard

Toggle word wrap

出力例

pod/client created
pod/server created

pod/client created
pod/server created

Copy to Clipboard

Toggle word wrap

トラフィックを生成し、ネットワークポリシー監査ログエントリーを作成するには、以下の手順を実行します。

verify-audit-logging namespace で server という名前の Pod の IP アドレスを取得します。

POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

$ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')

Copy to Clipboard

Toggle word wrap

default の namespace の client という名前の Pod の直前のコマンドから IP アドレスに ping し、すべてのパケットがドロップされていることを確認します。

oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

出力例

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms

Copy to Clipboard

Toggle word wrap

verify-audit-logging namespace の client という名前の Pod から POD_IP シェル環境変数に保存されている IP アドレスに ping し、すべてのパケットが許可されていることを確認します。

oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

$ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP

Copy to Clipboard

Toggle word wrap

出力例

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms

Copy to Clipboard

Toggle word wrap

ネットワークポリシー監査ログの最新エントリーを表示します。

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

17.2.4. namespace のネットワークポリシー監査ロギングの有効化
リンクのコピー

クラスター管理者は、namespace のネットワークポリシーの監査ロギングを有効化できます。

前提条件

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

手順

オプション: namespace のネットワークポリシー監査ロギングを有効にするには、以下のコマンドを入力します。

oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

$ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<namespace>: namespace の名前を指定します。

ヒント

または、以下の YAML を適用して監査ロギングを有効化できます。

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }

Copy to Clipboard

Toggle word wrap

出力例

namespace/verify-audit-logging annotated

namespace/verify-audit-logging annotated

Copy to Clipboard

Toggle word wrap

検証

ネットワークポリシー監査ログの最新エントリーを表示します。

for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

$ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done

Copy to Clipboard

Toggle word wrap

出力例

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

Copy to Clipboard

Toggle word wrap

17.2.5. namespace のネットワークポリシー監査ロギングの無効化
リンクのコピー

クラスター管理者は、namespace のネットワークポリシー監査ロギングを無効化できます。

前提条件

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

手順

namespace のネットワークポリシー監査ロギングを無効にするには、以下のコマンドを入力します。
```
oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
```
```
$ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<namespace>
namespace の名前を指定します。
ヒント
または、以下の YAML を適用して監査ロギングを無効化できます。
kind: Namespace apiVersion: v1 metadata: name: <namespace> annotations: k8s.ovn.org/acl-logging: null
Copy to Clipboard Toggle word wrap
出力例
```
namespace/verify-audit-logging annotated
```
```
namespace/verify-audit-logging annotated
```
Copy to Clipboard Toggle word wrap

17.3. ネットワークポリシーの作成
リンクのコピー

admin ロールを持つユーザーは、namespace のネットワークポリシーを作成できます。

17.3.1. サンプル NetworkPolicy オブジェクト
リンクのコピー

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

17.3.2. CLI を使用したネットワークポリシーの作成
リンクのコピー

クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義するには、ネットワークポリシーを作成できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを作成できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが適用される namespace で作業している。

手順

ポリシールールを作成します。
1. <policy_name>.yaml ファイルを作成します。
  $ touch <policy_name>.yaml
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <policy_name>
  ネットワークポリシーファイル名を指定します。
2. 作成したばかりのファイルで、以下の例のようなネットワークポリシーを定義します。
  すべての namespace のすべての Pod から ingress を拒否します。
  kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: ingress: []
  
  Copy to Clipboard Toggle word wrap
  同じ namespace のすべての Pod から ingress を許可します。
  kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-same-namespace spec: podSelector: ingress: - from: - podSelector: {}
  
  Copy to Clipboard Toggle word wrap
ネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
$ oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーファイル名を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
networkpolicy.networking.k8s.io/default-deny created
```
```
networkpolicy.networking.k8s.io/default-deny created
```
Copy to Clipboard Toggle word wrap

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

17.4. ネットワークポリシーの表示
リンクのコピー

admin ロールを持つユーザーは、namespace のネットワークポリシーを表示できます。

17.4.1. サンプル NetworkPolicy オブジェクト
リンクのコピー

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

17.4.2. CLI を使用したネットワークポリシーの表示
リンクのコピー

namespace のネットワークポリシーを検査できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを表示できます。

前提条件

OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

namespace のネットワークポリシーを一覧表示します。

namespace で定義されたネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap

オプション: 特定のネットワークポリシーを検査するには、以下のコマンドを入力します。

oc describe networkpolicy <policy_name> -n <namespace>

$ oc describe networkpolicy <policy_name> -n <namespace>

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<policy_name>: 検査するネットワークポリシーの名前を指定します。
<namespace>: オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

以下に例を示します。

oc describe networkpolicy allow-same-namespace

$ oc describe networkpolicy allow-same-namespace

Copy to Clipboard

Toggle word wrap

oc describe コマンドの出力

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress

Copy to Clipboard

Toggle word wrap

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。

17.5. ネットワークポリシーの編集
リンクのコピー

admin ロールを持つユーザーは、namespace の既存のネットワークポリシーを編集できます。

17.5.1. ネットワークポリシーの編集
リンクのコピー

namespace のネットワークポリシーを編集できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意の namespace でネットワークポリシーを編集できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

オプション: namespace のネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
```
oc get networkpolicy
```
```
$ oc get networkpolicy
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトを編集します。
- ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  <policy_file>
  ネットワークポリシーを含むファイルの名前を指定します。
- ネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
  $ oc edit networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <policy_name>
  ネットワークポリシーの名前を指定します。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
ネットワークポリシーオブジェクトが更新されていることを確認します。
```
oc describe networkpolicy <policy_name> -n <namespace>
```
```
$ oc describe networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。

17.5.2. サンプル NetworkPolicy オブジェクト
リンクのコピー

以下は、サンプル NetworkPolicy オブジェクトにアノテーションを付けます。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107 
spec:
  podSelector: 
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector: 
        matchLabels:
          app: app
    ports: 
    - protocol: TCP
      port: 27017

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107

1


spec:
  podSelector:

2


    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:

3


        matchLabels:
          app: app
    ports:

4


    - protocol: TCP
      port: 27017

Copy to Clipboard

Toggle word wrap

1: NetworkPolicy オブジェクトの名前。
2: ポリシーが適用される Pod を説明するセレクター。ポリシーオブジェクトは NetworkPolicy オブジェクトが定義されるプロジェクトの Pod のみを選択できます。
3: ポリシーオブジェクトが入力トラフィックを許可する Pod に一致するセレクター。セレクターは、NetworkPolicy と同じ namaspace にある Pod を照合して検索します。
4: トラフィックを受け入れる 1 つ以上の宛先ポートのリスト。

17.6. ネットワークポリシーの削除
リンクのコピー

admin ロールを持つユーザーは、namespace からネットワークポリシーを削除できます。

17.6.1. CLI を使用したネットワークポリシーの削除
リンクのコピー

namespace のネットワークポリシーを削除できます。

注記

cluster-admin ロールを持つユーザーでログインしている場合、クラスター内の任意のネットワークポリシーを削除できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。
ネットワークポリシーが存在する namespace で作業している。

手順

ネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
```
oc delete networkpolicy <policy_name> -n <namespace>
```
```
$ oc delete networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
ネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
networkpolicy.networking.k8s.io/default-deny deleted
```
```
networkpolicy.networking.k8s.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。

17.7. プロジェクトのデフォルトネットワークポリシーの定義
リンクのコピー

クラスター管理者は、新規プロジェクトの作成時にネットワークポリシーを自動的に含めるように新規プロジェクトテンプレートを変更できます。新規プロジェクトのカスタマイズされたテンプレートがまだない場合には、まずテンプレートを作成する必要があります。

17.7.1. 新規プロジェクトのテンプレートの変更
リンクのコピー

クラスター管理者は、デフォルトのプロジェクトテンプレートを変更し、新規プロジェクトをカスタム要件に基づいて作成することができます。

独自のカスタムプロジェクトテンプレートを作成するには、以下を実行します。

手順

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

デフォルトのプロジェクトテンプレートを生成します。

oc adm create-bootstrap-project-template -o yaml > template.yaml

$ oc adm create-bootstrap-project-template -o yaml > template.yaml

Copy to Clipboard

Toggle word wrap

オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。
プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。
```
oc create -f template.yaml -n openshift-config
```
```
$ oc create -f template.yaml -n openshift-config
```
Copy to Clipboard Toggle word wrap
Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。
- Web コンソールの使用
  1. Administration → Cluster Settings ページに移動します。
  2. Configuration をクリックし、すべての設定リソースを表示します。
  3. Project のエントリーを見つけ、Edit YAML をクリックします。
- CLI の使用
  1. project.config.openshift.io/cluster リソースを編集します。
    
    $ oc edit project.config.openshift.io/cluster
    
    Copy to Clipboard Toggle word wrap
spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。
カスタムプロジェクトテンプレートを含むプロジェクト設定リソース
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
```
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  ...
spec:
  projectRequestTemplate:
    name: <template_name>
```
Copy to Clipboard Toggle word wrap
変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

17.7.2. 新規プロジェクトへのネットワークポリシーの追加
リンクのコピー

クラスター管理者は、ネットワークポリシーを新規プロジェクトのデフォルトテンプレートに追加できます。OpenShift Container Platform は、プロジェクトのテンプレートに指定されたすべての NetworkPolicy オブジェクトを自動的に作成します。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするデフォルトの CNI ネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインする。
新規プロジェクトのカスタムデフォルトプロジェクトテンプレートを作成している。

手順

以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。
```
oc edit template <project_template> -n openshift-config
```
```
$ oc edit template <project_template> -n openshift-config
```
Copy to Clipboard Toggle word wrap
<project_template> を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名は project-request です。

テンプレートでは、各 NetworkPolicy オブジェクトを要素として objects パラメーターに追加します。objects パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。

以下の例では、objects パラメーターのコレクションにいくつかの NetworkPolicy オブジェクトが含まれます。

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...

Copy to Clipboard

Toggle word wrap

オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。
1. 新規プロジェクトを作成します。
  $ oc new-project <project>
  1
  Copy to Clipboard Toggle word wrap
  1
  <project> を、作成しているプロジェクトの名前に置き換えます。
2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。
  $ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
  Copy to Clipboard Toggle word wrap

17.8. ネットワークポリシーを使用したマルチテナント分離の設定
リンクのコピー

クラスター管理者は、マルチテナントネットワークの分離を実行するようにネットワークポリシーを設定できます。

注記

OpenShift SDN クラスターネットワークプロバイダーを使用している場合、本セクションで説明されているようにネットワークポリシーを設定すると、マルチテナントモードと同様のネットワーク分離が行われますが、ネットワークポリシーモードが設定されます。

17.8.1. ネットワークポリシーを使用したマルチテナント分離の設定
リンクのコピー

他のプロジェクト namespace の Pod およびサービスから分離できるようにプロジェクトを設定できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
admin 権限を持つユーザーとしてクラスターにログインしている。

手順

以下の NetworkPolicy オブジェクトを作成します。

allow-from-openshift-ingress という名前のポリシー:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

注記

policy-group.network.openshift.io/ingress: ""は、OpenShift SDN の推奨の namespace セレクターラベルです。network.openshift.io/policy-group: ingress namespace セレクターラベルを使用できますが、これはレガシーラベルです。

allow-from-openshift-monitoring という名前のポリシー。

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

allow-same-namespace という名前のポリシー:

cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

$ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF

Copy to Clipboard

Toggle word wrap

allow-from-kube-apiserver-operator という名前のポリシー:

cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

$ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF

Copy to Clipboard

Toggle word wrap

詳細は、新規の New kube-apiserver-operator webhook controller validating health of webhook を参照してください。

オプション: 以下のコマンドを実行し、ネットワークポリシーオブジェクトが現在のプロジェクトに存在することを確認します。

oc describe networkpolicy

$ oc describe networkpolicy

Copy to Clipboard

Toggle word wrap

出力例

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

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

Copy to Clipboard

Toggle word wrap

17.8.2. 次のステップ
リンクのコピー

デフォルトのネットワークポリシーの定義

第18章 CIDR 範囲の定義
リンクのコピー

次の CIDR 範囲には、重複しない範囲を指定する必要があります。

注記

クラスターの作成後にマシンの CIDR 範囲を変更することはできません。

重要

OpenShift Container Platform 4.11 以降のデフォルトのネットワークプロバイダーである OVN-Kubernetes は、IP アドレス範囲 100.64.0.0/16 を内部的に使用します。クラスターで OVN-Kubernetes を使用している場合は、クラスター内の他の CIDR 定義に IP アドレス範囲 100.64.0.0/16 を含めないでください。

18.1. Machine CIDR
リンクのコピー

Machine CIDR フィールドで、マシンまたはクラスターノードの IP アドレス範囲を指定する必要があります。

デフォルトは 10.0.0.0/16 です。この範囲は、接続されているネットワークと競合しないようにする必要があります。

18.2. Service CIDR
リンクのコピー

Service CIDR フィールドで、サービスの IP アドレス範囲を指定する必要があります。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 172.30.0.0/16 です。

18.3. Pod CIDR
リンクのコピー

Pod CIDR フィールドで、Pod の IP アドレス範囲を指定する必要があります。

Pod CIDR は、clusterNetwork CIDR およびクラスター CIDR と同じです。範囲は、ワークロードに対応するのに十分な大きさである必要があります。アドレスブロックは、クラスター内からアクセスする外部サービスと重複してはいけません。デフォルトは 10.128.0.0/14 です。クラスターをインストールした後に、範囲を拡張できます。

18.4. ホスト接頭辞
リンクのコピー

Host Prefix フィールドで、個々のマシンにスケジュールされた Pod に割り当てられたサブネット接頭辞の長さを指定する必要があります。ホスト接頭辞は、各マシンの Pod IP アドレスプールを決定します。

例えば、ホスト接頭辞を /23 に設定した場合、各マシンには Pod CIDR アドレス範囲から /23 のサブネットが割り当てられます。デフォルトは /23 で、510 台のクラスターノードと、ノードごとに 510 個の Pod IP アドレスを許可します。

第19章 AWS Load Balancer Operator
リンクのコピー

19.1. OpenShift Container Platform の AWS Load Balancer Operator
リンクのコピー

AWS Load Balancer (ALB) Operator は、aws-load-balancer-controller のインスタンスをデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から ALB Operator をインストールできます。

19.1.1. AWS Load Balancer Operator に関する考慮事項
リンクのコピー

AWS Load Balancer Operator をインストールおよび使用する前に、以下の制限を確認してください。

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

19.1.2. AWS Load Balancer Operator
リンクのコピー

AWS Load Balancer Operator は kubernetes.io/role/elb タグがない場合に、パブリックサブネットにタグを付けることができます。また、AWS Load Balancer Operator は基礎となる AWS クラウドから以下を検出します。

Operator をホストするクラスターがデプロイされる仮想プライベートクラウド (VPC) の ID。
検出された VPC のパブリックおよびプライベートサブネット。

前提条件

AWS 認証情報シークレットが必要です。認証情報は、サブネットのタグ付けおよび VPC 検出機能を提供するために使用されます。

手順

Subscription オブジェクトを作成して、OperatorHub から AWS Load Balancer Operator をオンデマンドでデプロイできます。

oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

$ oc -n aws-load-balancer-operator get sub aws-load-balancer-operator --template='{{.status.installplan.name}}{{"\n"}}'

Copy to Clipboard

Toggle word wrap

出力例

install-zlfbt

install-zlfbt

Copy to Clipboard

Toggle word wrap

インストール計画のステータスを確認します。インストール計画のステータスは、完了 する必要があります。
```
oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
```
```
$ oc -n aws-load-balancer-operator get ip <install_plan_name> --template='{{.status.phase}}{{"\n"}}'
```
Copy to Clipboard Toggle word wrap
出力例
```
Complete
```
```
Complete
```
Copy to Clipboard Toggle word wrap

oc get コマンドを使用して Deployment ステータスを表示します。

oc get -n aws-load-balancer-operator deployment/aws-load-balancer-operator-controller-manager

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

Copy to Clipboard

Toggle word wrap

出力例

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

NAME                                           READY     UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-operator-controller-manager  1/1       1            1           23h

Copy to Clipboard

Toggle word wrap

19.1.3. AWS Load Balancer Operator ログ
リンクのコピー

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

手順

AWS Load Balancer Operator のログを表示します。

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

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

Copy to Clipboard

Toggle word wrap

19.2. AWS Load Balancer Operator について
リンクのコピー

AWS Load Balancer (ALB) Operator は、aws-load-balancer-controller リソースのインスタンスをデプロイおよび管理します。OpenShift Container Platform Web コンソールまたは CLI を使用して、OperatorHub から AWS Load Balancer Operator をインストールできます。

19.2.1. AWS Load Balancer Operator のインストール
リンクのコピー

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

前提条件

cluster-admin パーミッションのあるユーザーとして OpenShift Container Platform Web コンソールにログインしていること。
クラスターは、AWS をプラットフォームタイプおよびクラウドプロバイダーとして設定されています。

手順

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

検証

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

19.3. AWS Load Balancer コントローラーのインスタンスの作成
リンクのコピー

Operator をインストールした後、 AWS Load Balancer コントローラーのインスタンスを作成できます。

19.3.1. AWS Load Balancer Operator を使用した AWS Load Balancer コントローラーインスタンスの作成
リンクのコピー

クラスターにインストールできる aws-load-balancer-controller のインスタンスは 1 つだけです。CLI を使用して AWS Load Balancer コントローラーを作成できます。AWS Load Balancer (ALB) Operator は、cluster という名前のリソースのみを調整します。

前提条件

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

手順

次のように、aws-load-balancer-controller リソース YAML ファイル (たとえば、sample-aws-lb.yaml) を作成します。
```
apiVersion: networking.olm.openshift.io/v1alpha1
kind: AWSLoadBalancerController 
metadata:
  name: cluster 
spec:
  subnetTagging: Auto 
  additionalResourceTags: 
    example.org/cost-center: 5113232
    example.org/security-scope: staging
  ingressClass: alb 
  config:
    replicas: 2 
  enabledAddons: 
    - AWSWAFv2 
```
```
apiVersion: networking.olm.openshift.io/v1alpha1
kind: AWSLoadBalancerController 
```
1
```
metadata:
  name: cluster 
```
2
```
spec:
  subnetTagging: Auto 
```
3
```
  additionalResourceTags: 
```
4
```
    example.org/cost-center: 5113232
    example.org/security-scope: staging
  ingressClass: alb 
```
5
```
  config:
    replicas: 2 
```
6
```
  enabledAddons: 
```
7
```
    - AWSWAFv2 
```
8
Copy to Clipboard Toggle word wrap
1
aws-load-balancer-controller リソースを定義します。
2
AWS Load Balancer コントローラーインスタンスの名前を定義します。このインスタンス名は、関連するすべてのリソースの接尾辞として追加されます。
3
有効なオプションは Auto と Manual です。値が Auto に設定されている場合、Operator はクラスターに属するサブネットを判別し、それらに適切なタグを付けようと試みます。内部サブネットタグが内部サブネットに存在しない場合、Operator はロールを正しく判別できません。ユーザー提供のインフラストラクチャーにクラスターをインストールした場合は、サブネットに適切なロールタグを手動でタグ付けし、サブネットタグ付けポリシーを Manual に設定できます。
4
コントローラーが AWS リソースをプロビジョニングするときに使用するタグを定義します。
5
このフィールドのデフォルト値は alb です。IngressClass リソースが存在しない場合、Operator は同じ名前でプロビジョニングします。
6
コントローラーのレプリカ数を指定します。
7
アノテーションを介して指定される AWS Load Balancer のアドオンを指定します。
8
alb.ingress.kubernetes.io/wafv2-acl-arn アノテーションを有効にします。
次のコマンドを実行して、aws-load-balancer-controller リソースを作成します。
```
oc create -f sample-aws-lb.yaml
```
```
$ oc create -f sample-aws-lb.yaml
```
Copy to Clipboard Toggle word wrap

AWS Load Balancer コントローラーが起動したら、deployment リソースを作成します。

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

apiVersion: apps/v1
kind: Deployment

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  selector:
    matchLabels:
      app: echoserver
  replicas: 3

3


  template:
    metadata:
      labels:
        app: echoserver
    spec:
      containers:
        - image: openshift/origin-node
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080

Copy to Clipboard

Toggle word wrap

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

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

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

apiVersion: v1
kind: Service

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: echoserver

Copy to Clipboard

Toggle word wrap

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

ALB ベースの Ingress リソースをデプロイします。

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

apiVersion: networking.k8s.io/v1
kind: Ingress

1


metadata:
  name: <echoserver>

2


  namespace: echoserver
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: instance
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <echoserver>

3


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

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

検証

次のコマンドを実行して、Ingress リソースのステータスを確認し、プロビジョニングされた AWS Load Balancer (ALB) のホストを表示します。
```
HOST=$(kubectl get ingress -n echoserver echoserver -o json | jq -r '.status.loadBalancer.ingress[0].hostname')
```
```
$ HOST=$(kubectl get ingress -n echoserver echoserver -o json | jq -r '.status.loadBalancer.ingress[0].hostname')
```
Copy to Clipboard Toggle word wrap
次のコマンドを実行して、プロビジョニングされた AWS Load Balancer (ALB) ホストのステータスを確認します。
```
curl $HOST
```
```
$ curl $HOST
```
Copy to Clipboard Toggle word wrap

19.4. 複数の Ingress の作成
リンクのコピー

単一の AWS Load Balancer (ALB) を介して、単一のドメインの一部であるさまざまなサービスにトラフィックをルーティングできます。各 Ingress リソースは、ドメインの異なるエンドポイントを提供します。

19.4.1. 単一の AWS Load Balancer を介して複数の Ingress を作成
リンクのコピー

CLI を使用すると、単一の AWS Load Balancer (ALB) を介してトラフィックを複数の Ingress にルーティングできます。

前提条件

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

手順

次のように、IngressClassParams リソースの YAML ファイル (例: sample-single-lb-params.yaml) を作成します。
```
apiVersion: elbv2.k8s.aws/v1beta1 
kind: IngressClassParams
metadata:
  name: single-lb-params 
spec:
  group:
    name: single-lb 
```
```
apiVersion: elbv2.k8s.aws/v1beta1 
```
1
```
kind: IngressClassParams
metadata:
  name: single-lb-params 
```
2
```
spec:
  group:
    name: single-lb 
```
3
Copy to Clipboard Toggle word wrap
1
IngressClassParams リソースの API グループとバージョンを定義します。
2
IngressClassParams リソースの名前を指定します。
3
IngressGroup の名前を指定します。このクラスのすべての Ingress は、この IngressGroup に属します。
次のコマンドを実行して、IngressClassParams リソースを作成します。
```
oc create -f sample-single-lb-params.yaml
```
```
$ oc create -f sample-single-lb-params.yaml
```
Copy to Clipboard Toggle word wrap
次のように、IngressClass リソースの YAML ファイル (例: sample-single-lb-class.yaml) を作成します。
```
apiVersion: networking.k8s.io/v1 
kind: IngressClass
metadata:
  name: single-lb 
spec:
  controller: ingress.k8s.aws/alb 
  parameters:
    apiGroup: elbv2.k8s.aws 
    kind: IngressClassParams 
    name: single-lb-params 
```
```
apiVersion: networking.k8s.io/v1 
```
1
```
kind: IngressClass
metadata:
  name: single-lb 
```
2
```
spec:
  controller: ingress.k8s.aws/alb 
```
3
```
  parameters:
    apiGroup: elbv2.k8s.aws 
```
4
```
    kind: IngressClassParams 
```
5
```
    name: single-lb-params 
```
6
Copy to Clipboard Toggle word wrap
1
API グループと IngressClass リソースのバージョンを定義します。
2
IngressClass の名前を指定します。
3
コントローラー名を定義します。ingress.k8s.aws/alb は、このクラスのすべての Ingress が aws-load-balancer-controller によって管理される必要があることを示します。
4
IngressClassParams リソースの API グループを定義します。
5
IngressClassParams リソースのリソースタイプを定義します。
6
IngressClassParams リソースの名前を定義します。
次のコマンドを実行して、IngressClass リソースを作成します。
```
oc create -f sample-single-lb-class.yaml
```
```
$ oc create -f sample-single-lb-class.yaml
```
Copy to Clipboard Toggle word wrap

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

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

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

1

Copy to Clipboard

Toggle word wrap

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

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

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-1

1


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

2


    alb.ingress.kubernetes.io/group.order: "1"

3


    alb.ingress.kubernetes.io/target-type: instance

4


spec:
  ingressClassName: single-lb

5


  rules:
  - host: example.com

6


    http:
        paths:
        - path: /blog

7


          pathType: Prefix
          backend:
            service:
              name: example-1

8


              port:
                number: 80

9


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

Copy to Clipboard

Toggle word wrap

1: Ingress の名前を指定します。
2: パブリックサブネットでプロビジョニングするロードバランサーを示し、インターネット経由でアクセスできるようにします。
3: ロードバランサーでリクエストを受信したときに、Ingress からのルールが一致する順序を指定します。
4: ロードバランサーがサービスに到達するために OpenShift ノードをターゲットにすることを示します。
5: この入力に属する Ingress クラスを指定します。
6: リクエストルーティングに使用されるドメインの名前を定義します。
7: サービスにルーティングする必要があるパスを定義します。
8: Ingress で設定されたエンドポイントにサービスを提供するサービスの名前を定義します。
9: エンドポイントにサービスを提供するサービスのポートを定義します。

次のコマンドを実行して、Ingress リソースを作成します。
```
oc create -f sample-multiple-ingress.yaml
```
```
$ oc create -f sample-multiple-ingress.yaml
```
Copy to Clipboard Toggle word wrap

19.5. TLS Termination の追加
リンクのコピー

AWS Load Balancer に TLS Termination を追加できます。

19.5.1. AWS Load Balancer への TLS Termination の追加
リンクのコピー

ドメインのトラフィックをサービスの Pod にルーティングし、AWS Load Balancer に TLS Termination を追加できます。

前提条件

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

手順

Operator をインストールし、aws-load-balancer-controller リソースのインスタンスを作成します。
```
apiVersion: networking.k8s.io/v1
kind: AWSLoadBalancerController
group: networking.olm.openshift.io/v1alpha1 
metadata:
  name: cluster
spec:
  subnetTagging: Auto
  ingressClass: tls-termination 
```
```
apiVersion: networking.k8s.io/v1
kind: AWSLoadBalancerController
group: networking.olm.openshift.io/v1alpha1 
```
1
```
metadata:
  name: cluster
spec:
  subnetTagging: Auto
  ingressClass: tls-termination 
```
2
Copy to Clipboard Toggle word wrap
1 2
AWS Load Balancer コントローラーによって調整される ingressClass リソースの名前を定義します。この ingressClass リソースは、存在しない場合に作成されます。さらに ingressClass 値を追加できます。spec.controller が ingress.k8s.aws/alb に設定されている場合、コントローラーは ingressClass の値を調整します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example> 
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing 
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx 
spec:
  ingressClassName: tls-termination 
  rules:
  - host: <example.com> 
    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service> 
                port:
                  number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <example>

1


  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing

2


    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:xxxxx

3


spec:
  ingressClassName: tls-termination

4


  rules:
  - host: <example.com>

5


    http:
        paths:
          - path: /
            pathType: Exact
            backend:
              service:
                name: <example-service>

6


                port:
                  number: 80

Copy to Clipboard

Toggle word wrap

1: Ingress の名前を指定します。
2: コントローラーは、パブリックサブネット内のこの Ingress リソースのロードバランサーをプロビジョニングして、インターネット経由でロードバランサーに到達できるようにします。
3: ロードバランサーに添付する証明書の Amazon Resource Name です。
4: Ingress クラス名を定義します。
5: トラフィックルーティングのドメインを定義します。
6: トラフィックルーティングのサービスを定義します。

第20章複数ネットワーク
リンクのコピー

20.1. 複数ネットワークについて
リンクのコピー

Kubernetes では、コンテナーネットワークは Container Network Interface (CNI) を実装するネットワークプラグインに委任されます。

OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール時に、デフォルト の Pod ネットワークを設定します。デフォルトのネットワークは、クラスターのすべての通常のネットワークトラフィックを処理します。利用可能な CNI プラグインに基づいて additional network を定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。必要に応じて、クラスターの複数のネットワークを追加で定義することができます。これにより、スイッチングやルーティングなどのネットワーク機能を提供する Pod を設定する際に柔軟性が得られます。

20.1.1. 追加ネットワークの使用シナリオ
リンクのコピー

データプレーンとコントロールプレーンの分離など、ネットワークの分離が必要な状況で追加のネットワークを使用できます。トラフィックの分離は、以下のようなパフォーマンスおよびセキュリティー関連の理由で必要になります。

パフォーマンス: 各プレーンのトラフィック量を管理するために、2 つの異なるプレーンにトラフィックを送信できます。
セキュリティー: 機密トラフィックは、セキュリティー上の考慮に基づいて管理されているネットワークに送信でき、テナントまたはカスタマー間で共有できないプライベートを分離することができます。

クラスターのすべての Pod はクラスター全体のデフォルトネットワークを依然として使用し、クラスター全体での接続性を維持します。すべての Pod には、クラスター全体の Pod ネットワークに割り当てられる eth0 インターフェイスがあります。Pod のインターフェイスは、oc exec -it <pod_name> -- ip a コマンドを使用して表示できます。Multus CNI を使用するネットワークを追加する場合、それらの名前は net1、net2、…、 netN になります。

追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェイスは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの CR のそれぞれにある CNI 設定は、インターフェイスの作成方法を定義します。

20.1.2. OpenShift Container Platform の追加ネットワーク
リンクのコピー

OpenShift Container Platform は、クラスターに追加のネットワークを作成するために使用する以下の CNI プラグインを提供します。

bridge: ブリッジベースの追加ネットワークを設定することで、同じホストにある Pod が相互に、かつホストと通信できます。
host-device: ホストデバイスの追加ネットワークを設定することで、Pod がホストシステム上の物理イーサネットネットワークデバイスにアクセスすることができます。
ipvlan: ipvlan ベースの追加ネットワークを設定することで、macvlan ベースの追加ネットワークと同様に、ホスト上の Pod が他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加のネットワークとは異なり、各 Pod は親の物理ネットワークインターフェイスと同じ MAC アドレスを共有します。
macvlan: macvlan ベースの追加ネットワークを作成することで、ホスト上の Pod が物理ネットワークインターフェイスを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
SR-IOV: SR-IOV ベースの追加ネットワークを設定することで、Pod をホストシステム上の SR-IOV 対応ハードウェアの Virtual Function (VF) インターフェイスに割り当てることができます。

20.2. 追加のネットワークの設定
リンクのコピー

クラスター管理者は、クラスターの追加のネットワークを設定できます。以下のネットワークタイプに対応しています。

20.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 プラグインを連鎖させることができます。

20.2.2. ネットワーク追加割り当ての設定
リンクのコピー

追加のネットワークは、k8s.cni.cncf.ioAPI グループの Network Attachment DefinitionAPI で設定されます。

重要

Network Attachment Definition オブジェクトには、プロジェクト管理ユーザーがアクセスできるので、機密情報やシークレットを保存しないでください。

API の設定については、以下の表で説明されています。

Expand

表20.1 NetworkAttachmentDefinition API フィールド
フィールド	型	説明
`metadata.name`	`string`	追加のネットワークの名前です。
`metadata.namespace`	`string`	オブジェクトが関連付けられる namespace。
`spec.config`	`string`	JSON 形式の CNI プラグイン設定。

20.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: 
  - name: <name> 
    namespace: <namespace> 
    rawCNIConfig: |- 
      {
        ...
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:

1


  - name: <name>

2


    namespace: <namespace>

3


    rawCNIConfig: |-

4


      {
        ...
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

1: 1 つまたは複数の追加ネットワーク設定の配列。
2: 作成している追加ネットワーク割り当ての名前。名前は指定された namespace 内で一意である必要があります。
3: ネットワークの割り当てを作成する namespace。値を指定しない場合、default の namespace が使用されます。
4: JSON 形式の CNI プラグイン設定。

20.2.2.2. YAML マニフェストからの追加ネットワークの設定
リンクのコピー

追加ネットワークの設定は、以下の例のように YAML 設定ファイルから指定します。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name> 
spec:
  config: |- 
    {
      ...
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: <name>

1


spec:
  config: |-

2


    {
      ...
    }

Copy to Clipboard

Toggle word wrap

1: 作成している追加ネットワーク割り当ての名前。
2: JSON 形式の CNI プラグイン設定。

20.2.3. 追加のネットワークタイプの設定
リンクのコピー

次のセクションでは、追加のネットワークの具体的な設定フィールドについて説明します。

20.2.3.1. ブリッジネットワークの追加設定
リンクのコピー

以下のオブジェクトは、ブリッジ CNI プラグインの設定パラメーターについて説明しています。

Expand

表20.2 Bridge CNI プラグイン JSON 設定オブジェクト
フィールド	型	説明
`cniVersion`	`string`	CNI 仕様のバージョン。値 `0.3.1` が必要です。
`name`	`string`	CNO 設定に以前に指定した `name` パラメーターの値。
`type`	`string`	設定する CNI プラグインの名前: `bridge`。
`ipam`	`object`	IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
`bridge`	`string`	オプション: 使用する仮想ブリッジの名前を指定します。ブリッジインターフェイスがホストに存在しない場合は、これが作成されます。デフォルト値は `cni0` です。
`ipMasq`	`boolean`	オプション: 仮想ネットワークから外すトラフィックの IP マスカレードを有効にするには、`true` に設定します。すべてのトラフィックのソース IP アドレスは、ブリッジの IP アドレスに書き換えられます。ブリッジに IP アドレスがない場合は、この設定は影響を与えません。デフォルト値は `false` です。
`isGateway`	`boolean`	オプション: IP アドレスをブリッジに割り当てるには `true` に設定します。デフォルト値は `false` です。
`isDefaultGateway`	`boolean`	オプション: ブリッジを仮想ネットワークのデフォルトゲートウェイとして設定するには、`true` に設定します。デフォルト値は `false` です。`isDefaultGateway` が `true` に設定される場合、`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 タグは割り当てません。
`preserveDefaultVlan`	`string`	オプション: デフォルトの VLAN をブリッジに接続されている `veth` 側で保持する必要があるか示します。デフォルトは true です。
`vlanTrunk`	`list`	オプション: VLAN トランクタグを割り当てます。デフォルト値は `none` です。
`mtu`	`string`	オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。
`enabledad`	`boolean`	オプション: コンテナー側の `veth` の重複アドレス検出を有効にします。デフォルト値は `false` です。
`macspoofchk`	`boolean`	オプション: MAC スプーフィングチェックを有効にして、コンテナーから発信されるトラフィックをインターフェイスの MAC アドレスに制限します。デフォルト値は `false` です。

注記

VLAN パラメーターは、veth のホスト側に VLAN タグを設定し、ブリッジインターフェイスで vlan_filtering 機能を有効にします。

注記

L2 ネットワークのアップリンクを設定するには、以下のコマンドを使用してアップリンクインターフェイスで vlan を許可する必要があります。

 bridge vlan add vid VLAN_ID dev DEV

$  bridge vlan add vid VLAN_ID dev DEV

Copy to Clipboard

Toggle word wrap

20.2.3.1.1. ブリッジ設定の例
リンクのコピー

以下の例では、bridge-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "bridge-net",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "bridge-net",
  "type": "bridge",
  "isGateway": true,
  "vlan": 2,
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

20.2.3.2. ホストデバイスの追加ネットワークの設定
リンクのコピー

注記

device、hwaddr、kernelpath、または pciBusID のいずれかのパラメーターを設定してネットワークデバイスを指定します。

以下のオブジェクトは、ホストデバイス CNI プラグインの設定パラメーターについて説明しています。

Expand

表20.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 アドレスを指定します。

20.2.3.2.1. ホストデバイス設定例
リンクのコピー

以下の例では、hostdev-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "hostdev-net",
  "type": "host-device",
  "device": "eth1"
}

{
  "cniVersion": "0.3.1",
  "name": "hostdev-net",
  "type": "host-device",
  "device": "eth1"
}

Copy to Clipboard

Toggle word wrap

20.2.3.3. IPVLAN 追加ネットワークの設定
リンクのコピー

以下のオブジェクトは、IPVLAN CNI プラグインの設定パラメーターについて説明しています。

Expand

表20.4 IPVLAN CNI プラグイン JSON 設定オブジェクト
フィールド	型	説明
`cniVersion`	`string`	CNI 仕様のバージョン。値 `0.3.1` が必要です。
`name`	`string`	CNO 設定に以前に指定した `name` パラメーターの値。
`type`	`string`	設定する CNI プラグインの名前: `ipvlan`。
`ipam`	`object`	IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。これは、プラグインが連鎖している場合を除き必要です。
`mode`	`string`	オプション: 仮想ネットワークの操作モードを指定します。この値は、`l2`、`l3`、または `l3s` である必要があります。デフォルト値は `l2` です。
`master`	`string`	オプション: ネットワーク割り当てに関連付けるイーサネットインターフェイスを指定します。`master` が指定されない場合、デフォルトのネットワークルートのインターフェイスが使用されます。
`mtu`	`integer`	オプション: 最大転送単位 (MTU) を指定された値に設定します。デフォルト値はカーネルによって自動的に設定されます。

注記

ipvlan オブジェクトは、仮想インターフェイスが master インターフェイスと通信することを許可しません。したがって、コンテナーは ipvlan インターフェイスを使用してホストに到達できなくなります。コンテナーが、Precision Time Protocol (PTP) をサポートするネットワークなど、ホストへの接続を提供するネットワークに参加していることを確認してください。
1 つのの master インターフェイスを、macvlan と ipvlan の両方を使用するように同時に設定することはできません。
インターフェイスに依存できない IP 割り当てスキームの場合、ipvlan プラグインは、このロジックを処理する以前のプラグインと連鎖させることができます。master が省略された場合、前の結果にはスレーブにする ipvlan プラグインのインターフェイス名が 1 つ含まれていなければなりません。ipam が省略された場合、ipvlan インターフェイスの設定には前の結果が使用されます。

20.2.3.3.1. IPVLAN 設定例
リンクのコピー

以下の例では、ipvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "ipvlan-net",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

{
  "cniVersion": "0.3.1",
  "name": "ipvlan-net",
  "type": "ipvlan",
  "master": "eth1",
  "mode": "l3",
  "ipam": {
    "type": "static",
    "addresses": [
       {
         "address": "192.168.10.10/24"
       }
    ]
  }
}

Copy to Clipboard

Toggle word wrap

20.2.3.4. MACVLAN 追加ネットワークの設定
リンクのコピー

以下のオブジェクトは、macvlan CNI プラグインの設定パラメーターについて説明しています。

Expand

表20.5 MACVLAN CNI プラグイン JSON 設定オブジェクト
フィールド	型	説明
`cniVersion`	`string`	CNI 仕様のバージョン。値 `0.3.1` が必要です。
`name`	`string`	CNO 設定に以前に指定した `name` パラメーターの値。
`type`	`string`	設定する CNI プラグインの名前: `macvlan`。
`ipam`	`object`	IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
`mode`	`string`	オプション: 仮想ネットワークのトラフィックの可視性を設定します。`bridge`、`passthru`、`private`、または `vepa` のいずれかである必要があります。値が指定されない場合、デフォルト値は `bridge` になります。
`master`	`string`	オプション: 新しく作成された macvlan インターフェイスに関連付けるホストネットワークインターフェイス。値が指定されていない場合は、デフォルトのルートインターフェイスが使用されます。
`mtu`	`string`	オプション: 指定された値への最大転送単位 (MTU)。デフォルト値はカーネルによって自動的に設定されます。

注記

プラグイン設定の master キーを指定する場合は、競合の可能性を回避するために、プライマリーネットワークプラグインに関連付けられているものとは異なる物理ネットワークインターフェイスを使用してください。

20.2.3.4.1. macvlan 設定の例
リンクのコピー

以下の例では、macvlan-net という名前の追加のネットワークを設定します。

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

{
  "cniVersion": "0.3.1",
  "name": "macvlan-net",
  "type": "macvlan",
  "master": "eth1",
  "mode": "bridge",
  "ipam": {
    "type": "dhcp"
    }
}

Copy to Clipboard

Toggle word wrap

20.2.4. 追加ネットワークの IP アドレス割り当ての設定
リンクのコピー

IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。

以下の IP アドレスの割り当てタイプを使用できます。

静的割り当て。
DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
Whereabouts IPAM CNI プラグインを使用した動的割り当て。

20.2.4.1. 静的 IP アドレス割り当ての設定
リンクのコピー

以下の表は、静的 IP アドレスの割り当ての設定について説明しています。

Expand

表20.6 ipam 静的設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `static` が必要です。
`addresses`	`array`	仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
`routes`	`array`	Pod 内で設定するルートを指定するオブジェクトの配列です。
`dns`	`array`	オプション: DNS の設定を指定するオブジェクトの配列です。

addressesの配列には、以下のフィールドのあるオブジェクトが必要です。

Expand

表20.7 ipam.addresses[] 配列
フィールド	型	説明
`address`	`string`	指定する IP アドレスおよびネットワーク接頭辞。たとえば、`10.10.21.10/24` を指定すると、追加のネットワークに IP アドレスの `10.10.21.10` が割り当てられ、ネットマスクは `255.255.255.0` になります。
`gateway`	`string`	egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。

Expand

表20.8 ipam.routes[] 配列
フィールド	型	説明
`dst`	`string`	CIDR 形式の IP アドレス範囲 (`192.168.17.0/24`、またはデフォルトルートの `0.0.0.0/0`)。
`gw`	`string`	ネットワークトラフィックがルーティングされるゲートウェイ。

Expand

表20.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/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

20.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"
        }
      }
  # ...

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"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

表20.10 ipam DHCP 設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `dhcp` が必要です。

動的 IP アドレス (DHCP) 割り当ての設定例

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

20.2.4.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
リンクのコピー

Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。

以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。

Expand

表20.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"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

20.2.4.4. Whereabouts reconciler デーモンセットの作成
リンクのコピー

Whereabouts reconciler は、Whereabouts IP アドレス管理 (IPAM) ソリューションを使用して、クラスター内の Pod の動的 IP アドレス割り当てを管理します。これにより、各 Pod が指定された IP アドレス範囲から一意の IP アドレスを確実に取得します。また、Pod が削除またはスケールダウンされた場合の IP アドレスの解放も処理します。

注記

NetworkAttachmentDefinition カスタムリソースを使用して動的 IP アドレスを割り当てることもできます。

Whereabouts reconciler デーモンセットは、Cluster Network Operator を通じて追加のネットワークを設定するときに自動的に作成されます。YAML マニフェストから追加のネットワークを設定する場合、これは自動的には作成されません。

Whereabouts reconciler デーモンセットのデプロイメントをトリガーするには、Cluster Network Operator のカスタムリソースファイルを編集して、Whereabouts-shim ネットワーク割り当てを手動で作成する必要があります。

Whereabouts reconciler デーモンセットをデプロイするには、次の手順を使用します。

手順

以下のコマンドを実行して、Network.operator.openshift.io カスタムリソース (CR) を編集します。
```
oc edit network.operator.openshift.io cluster
```
```
$ oc edit network.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

CR の AdditionalNetworks パラメーターを変更して、whereabouts-shim ネットワーク割り当て定義を追加します。以下に例を示します。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

ファイルを保存し、テキストエディターを編集します。

次のコマンドを実行して、whereabouts-reconciler デーモンセットが正常にデプロイされたことを確認します。

oc get all -n openshift-multus | grep whereabouts-reconciler

$ oc get all -n openshift-multus | grep whereabouts-reconciler

Copy to Clipboard

Toggle word wrap

出力例

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

Copy to Clipboard

Toggle word wrap

20.2.5. Cluster Network Operator による追加ネットワーク割り当ての作成
リンクのコピー

Cluster Network Operator (CNO) は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、CNO は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

重要

Cluster Network Operator が管理する NetworkAttachmentDefinition オブジェクトは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

前提条件

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

手順

オプション: 追加のネットワークの namespace を作成します。
```
oc create namespace <namespace_name>
```
```
$ oc create namespace <namespace_name>
```
Copy to Clipboard Toggle word wrap
CNO 設定を編集するには、以下のコマンドを入力します。
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  # ...
  additionalNetworks:
  - name: tertiary-net
    namespace: namespace2
    type: Raw
    rawCNIConfig: |-
      {
        "cniVersion": "0.3.1",
        "name": "tertiary-net",
        "type": "ipvlan",
        "master": "eth1",
        "mode": "l2",
        "ipam": {
          "type": "static",
          "addresses": [
            {
              "address": "192.168.1.23/24"
            }
          ]
        }
      }

Copy to Clipboard

Toggle word wrap

変更を保存し、テキストエディターを終了して、変更をコミットします。

検証

以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO がオブジェクトを作成するまでに遅延が生じる可能性があります。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<namespace>
CNO の設定に追加したネットワーク割り当ての namespace を指定します。
出力例
```
NAME                 AGE
test-network-1       14m
```
```
NAME                 AGE
test-network-1       14m
```
Copy to Clipboard Toggle word wrap

20.2.6. YAML マニフェストを適用した追加のネットワーク割り当ての作成
リンクのコピー

前提条件

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

手順

以下の例のように、追加のネットワーク設定を含む YAML ファイルを作成します。

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: next-net
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "work-network",
      "type": "host-device",
      "device": "eth1",
      "ipam": {
        "type": "dhcp"
      }
    }

Copy to Clipboard

Toggle word wrap

追加のネットワークを作成するには、次のコマンドを入力します。
```
oc apply -f <file>.yaml
```
```
$ oc apply -f <file>.yaml
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<file>
YAML マニフェストを含むファイルの名前を指定します。

20.3. 仮想ルーティングおよび転送について
リンクのコピー

20.3.1. 仮想ルーティングおよび転送について
リンクのコピー

VRF (Virtual Routing and Forwarding) デバイスは IP ルールとの組み合わせにより、仮想ルーティングと転送ドメインを作成する機能を提供します。VRF は、CNF で必要なパーミッションの数を減らし、セカンダリーネットワークのネットワークトポロジーの可視性を強化します。VRF はマルチテナンシー機能を提供するために使用されます。たとえば、この場合、各テナントには固有のルーティングテーブルがあり、異なるデフォルトゲートウェイが必要です。

プロセスは、ソケットを VRF デバイスにバインドできます。バインドされたソケット経由のパケットは、VRF デバイスに関連付けられたルーティングテーブルを使用します。VRF の重要な機能として、これは OSI モデルレイヤー 3 以上にのみ影響を与えるため、LLDP などの L2 ツールは影響を受けません。これにより、ポリシーベースのルーティングなどの優先度の高い IP ルールが、特定のトラフィックを転送する VRF デバイスルールよりも優先されます。

20.3.1.1. Telecommunications Operator についての Pod のセカンダリーネットワークの利点
リンクのコピー

通信のユースケースでは、各 CNF が同じアドレス空間を共有する複数の異なるネットワークに接続される可能性があります。これらのセカンダリーネットワークは、クラスターのメインネットワーク CIDR と競合する可能性があります。CNI VRF プラグインを使用すると、ネットワーク機能は、同じ IP アドレスを使用して異なるユーザーのインフラストラクチャーに接続でき、複数の異なるお客様の分離された状態を維持します。IP アドレスは OpenShift Container Platform の IP スペースと重複します。CNI VRF プラグインは、CNF で必要なパーミッションの数も減らし、セカンダリーネットワークのネットワークトポロジーの可視性を高めます。

20.4. マルチネットワークポリシーの設定
リンクのコピー

クラスター管理者は、追加のネットワークのネットワークポリシーを設定できます。

注記

macvlan の追加ネットワークのみに対して、マルチネットワークポリシーを指定することができます。ipvlan などの他の追加のネットワークタイプはサポートされていません。

20.4.1. マルチネットワークポリシーとネットワークポリシーの違い
リンクのコピー

MultiNetworkPolicy API は、NetworkPolicy API を実装していますが、いくつかの重要な違いがあります。

以下の場合は、MultiNetworkPolicy API を使用する必要があります。
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
```
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
```
Copy to Clipboard Toggle word wrap
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>
```
```
apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<network_name>
ネットワーク割り当て定義の名前を指定します。

20.4.2. クラスターのマルチネットワークポリシーの有効化
リンクのコピー

クラスター管理者は、クラスターでマルチネットワークポリシーのサポートを有効にすることができます。

前提条件

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

手順

以下の YAML で multinetwork-enable-patch.yaml ファイルを作成します。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  useMultiNetworkPolicy: true

Copy to Clipboard

Toggle word wrap

マルチネットワークポリシーを有効にするようにクラスターを設定します。

oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

$ oc patch network.operator.openshift.io cluster --type=merge --patch-file=multinetwork-enable-patch.yaml

Copy to Clipboard

Toggle word wrap

出力例

network.operator.openshift.io/cluster patched

network.operator.openshift.io/cluster patched

Copy to Clipboard

Toggle word wrap

20.4.3. マルチネットワークポリシーの使用
リンクのコピー

クラスター管理者は、マルチネットワークポリシーを作成、編集、表示、および削除することができます。

20.4.3.1. 前提条件
リンクのコピー

クラスターのマルチネットワークポリシーサポートを有効にしている。

20.4.3.2. CLI を使用したマルチネットワークポリシーの作成
リンクのコピー

マルチネットワークポリシーを作成し、クラスターの namespace に許可される Ingress または egress ネットワークトラフィックを記述する詳細なルールを定義することができます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
マルチネットワークポリシーが適用される namespace で作業していること。

手順

ポリシールールを作成します。

<policy_name>.yaml ファイルを作成します。
```
touch <policy_name>.yaml
```
```
$ touch <policy_name>.yaml
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
マルチネットワークポリシーのファイル名を指定します。

作成したばかりのファイルで、以下の例のようなマルチネットワークポリシーを定義します。

すべての 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: []

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: []

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<network_name>: ネットワーク割り当て定義の名前を指定します。

同じ namespace のすべての Pod から ingress を許可します。

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

apiVersion: k8s.cni.cncf.io/v1beta1
kind: MultiNetworkPolicy
metadata:
  name: allow-same-namespace
  annotations:
    k8s.v1.cni.cncf.io/policy-for: <network_name>
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}

Copy to Clipboard

Toggle word wrap

ここでは、以下のようになります。

<network_name>: ネットワーク割り当て定義の名前を指定します。

マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。
```
oc apply -f <policy_name>.yaml -n <namespace>
```
```
$ oc apply -f <policy_name>.yaml -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
マルチネットワークポリシーのファイル名を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny created
```
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny created
```
Copy to Clipboard Toggle word wrap

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

20.4.3.3. マルチネットワークポリシーの編集
リンクのコピー

namespace のマルチネットワークポリシーを編集できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
マルチネットワークポリシーが存在する namespace で作業している。

手順

オプション: namespace のマルチネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。
```
oc get multi-networkpolicy
```
```
$ oc get multi-networkpolicy
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトを編集します。
- マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。
  $ oc apply -n <namespace> -f <policy_file>.yaml
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
  <policy_file>
  ネットワークポリシーを含むファイルの名前を指定します。
- マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。
  $ oc edit multi-networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <policy_name>
  ネットワークポリシーの名前を指定します。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
マルチネットワークポリシーオブジェクトが更新されていることを確認します。
```
oc describe multi-networkpolicy <policy_name> -n <namespace>
```
```
$ oc describe multi-networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
マルチネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接編集できます。

20.4.3.4. CLI を使用したマルチネットワークポリシーの表示
リンクのコピー

namespace のマルチネットワークポリシーを検査できます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
マルチネットワークポリシーが存在する namespace で作業している。

手順

namespace のマルチネットワークポリシーをリスト表示します。
- namespace で定義されたマルチネットワークポリシーオブジェクトを表示するには、以下のコマンドを実行します。
  $ oc get multi-networkpolicy
  Copy to Clipboard Toggle word wrap
- オプション: 特定のマルチネットワークポリシーを検査するには、以下のコマンドを入力します。
  $ oc describe multi-networkpolicy <policy_name> -n <namespace>
  Copy to Clipboard Toggle word wrap
  ここでは、以下のようになります。
  <policy_name>
  検査するマルチネットワークポリシーの名前を指定します。
  <namespace>
  オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接表示できます。

20.4.3.5. CLI を使用したマルチネットワークポリシーの削除
リンクのコピー

namespace のマルチネットワークポリシーを削除できます。

前提条件

クラスターは、NetworkPolicy オブジェクトをサポートするクラスターネットワークプロバイダーを使用している (例: mode: NetworkPolicy が設定された OpenShift SDN ネットワークプロバイダー)。このモードは OpenShiftSDN のデフォルトです。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてクラスターにログインしている。
マルチネットワークポリシーが存在する namespace で作業している。

手順

マルチネットワークポリシーオブジェクトを削除するには、以下のコマンドを入力します。
```
oc delete multi-networkpolicy <policy_name> -n <namespace>
```
```
$ oc delete multi-networkpolicy <policy_name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
ここでは、以下のようになります。
<policy_name>
マルチネットワークポリシーの名前を指定します。
<namespace>
オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。
出力例
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
```
multinetworkpolicy.k8s.cni.cncf.io/default-deny deleted
```
Copy to Clipboard Toggle word wrap

注記

cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールの Actions メニューのポリシーから、クラスターの任意の namespace でネットワークポリシーを直接削除できます。

20.5. Pod の追加のネットワークへの割り当て
リンクのコピー

クラスターユーザーとして、Pod を追加のネットワークに割り当てることができます。

20.5.1. Pod の追加ネットワークへの追加
リンクのコピー

Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。

Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。

Pod が追加ネットワークと同じ namespace にあること。

前提条件

OpenShift CLI (oc) がインストールされている。
クラスターにログインする。

手順

アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。
1. カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。<network> を、Pod に関連付ける追加ネットワークの名前に置き換えます。
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
2. カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  NetworkAttachmentDefinition オブジェクトによって定義される追加のネットワークの名前を指定します。
  2
  NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。
  3
  オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。
Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

以下の例では、example-pod Pod が追加ネットワークの net1 に割り当てられています。

oc get pod example-pod -o yaml

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/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:
  ...

Copy to Clipboard

Toggle word wrap

1: k8s.v1.cni.cncf.io/networks-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。

20.5.1.1. Pod 固有のアドレスおよびルーティングオプションの指定
リンクのコピー

Pod を追加のネットワークに割り当てる場合、特定の Pod でそのネットワークに関するその他のプロパティーを指定する必要がある場合があります。これにより、ルーティングの一部を変更することができ、静的 IP アドレスおよび MAC アドレスを指定できます。これを実行するには、JSON 形式のアノテーションを使用できます。

前提条件

Pod が追加ネットワークと同じ namespace にあること。
OpenShift CLI (oc) がインストールされている。
クラスターにログインすること。

手順

アドレスおよび/またはルーティングオプションを指定する間に Pod を追加のネットワークに追加するには、以下の手順を実行します。

Pod リソース定義を編集します。既存の Pod リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name> を、編集する Pod リソースの名前に置き換えます。
```
oc edit pod <name>
```
```
$ oc edit pod <name>
```
Copy to Clipboard Toggle word wrap
Pod リソース定義で、k8s.v1.cni.cncf.io/networks パラメーターを Pod の metadata マッピングに追加します。k8s.v1.cni.cncf.io/networks は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition カスタムリソース (CR) 名を参照するオブジェクトリストの JSON 文字列を受け入れます。
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
```
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[<network>[,<network>,...]]' 
```
1
Copy to Clipboard Toggle word wrap
1
<network> を、以下の例にあるように JSON オブジェクトに置き換えます。一重引用符が必要です。

以下の例では、アノテーションで default-route パラメーターを使用して、デフォルトルートを持つネットワーク割り当てを指定します。

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
    {
      "name": "net1"
    },
    {
      "name": "net2", 
      "default-route": ["192.0.2.1"] 
    }]'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
    {
      "name": "net1"
    },
    {
      "name": "net2",

1


      "default-route": ["192.0.2.1"]

2


    }]'
spec:
  containers:
  - name: example-pod
    command: ["/bin/bash", "-c", "sleep 2000000000000"]
    image: centos/tools

Copy to Clipboard

Toggle word wrap

1: name キーは、Pod に関連付ける追加ネットワークの名前です。
2: default-route キーは、ルーティングテーブルに他のルーティングテーブルがない場合に、ルーティングされるトラフィックに使用されるゲートウェイ値を指定します。複数の default-route キーを指定すると、Pod がアクティブでなくなります。

デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。

重要

OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックについて予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。

Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。

oc exec -it <pod_name> -- ip route

$ oc exec -it <pod_name> -- ip route

Copy to Clipboard

Toggle word wrap

注記

また、Pod の k8s.v1.cni.cncf.io/networks-status を参照して、JSON 形式のリストのオブジェクトで default-route キーの有無を確認し、デフォルトルートが割り当てられている追加ネットワークを確認することができます。

Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。

以下のコマンドを実行して CNO CR を編集します。
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

以下の YAML は、CNO の設定パラメーターについて説明しています。

Cluster Network Operator YAML の設定

name: <name> 
namespace: <namespace> 
rawCNIConfig: '{ 
  ...
}'
type: Raw

name: <name>

1


namespace: <namespace>

2


rawCNIConfig: '{

3


  ...
}'
type: Raw

Copy to Clipboard

Toggle word wrap

1: 作成している追加ネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
2: ネットワークの割り当てを作成する namespace を指定します。値を指定しない場合、default の namespace が使用されます。
3: 以下のテンプレートに基づく CNI プラグイン設定を JSON 形式で指定します。

以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターについて説明しています。

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

{
  "cniVersion": "0.3.1",
  "name": "<name>", 
  "plugins": [{ 
      "type": "macvlan",
      "capabilities": { "ips": true }, 
      "master": "eth0", 
      "mode": "bridge",
      "ipam": {
        "type": "static"
      }
    }, {
      "capabilities": { "mac": true }, 
      "type": "tuning"
    }]
}

{
  "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"
    }]
}

Copy to Clipboard

Toggle word wrap

1: 作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。
2: CNI プラグイン設定の配列を指定します。1 つ目のオブジェクトは、macvlan プラグイン設定を指定し、2 つ目のオブジェクトはチューニングプラグイン設定を指定します。
3: CNI プラグインのランタイム設定機能の静的 IP 機能を有効にするために要求が実行されるように指定します。
4: macvlan プラグインが使用するインターフェイスを指定します。
5: CNI プラグインの静的 MAC アドレス機能を有効にするために要求が実行されるように指定します。

上記のネットワーク割り当ては、特定の Pod に割り当てられる静的 IP アドレスと MAC アドレスを指定するキーと共に、JSON 形式のアノテーションで参照できます。

以下を使用して Pod を編集します。

oc edit pod <name>

$ oc edit pod <name>

Copy to Clipboard

Toggle word wrap

静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {
        "name": "<name>", 
        "ips": [ "192.0.2.205/24" ], 
        "mac": "CA:FE:C0:FF:EE:00" 
      }
    ]'

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


      }
    ]'

Copy to Clipboard

Toggle word wrap

1: 上記の rawCNIConfig を作成する際に、指定されるように <name> を使用します。
2: サブネットマスクを含む IP アドレスを指定します。
3: MAC アドレスを指定します。

注記

静的 IP アドレスおよび MAC アドレスを同時に使用することはできません。これらは個別に使用することも、一緒に使用することもできます。

追加のネットワークを持つ Pod の IP アドレスと MAC プロパティーを検証するには、oc コマンドを使用して Pod 内で ip コマンドを実行します。

oc exec -it <pod_name> -- ip a

$ oc exec -it <pod_name> -- ip a

Copy to Clipboard

Toggle word wrap

20.6. 追加ネットワークからの Pod の削除
リンクのコピー

クラスターユーザーとして、追加のネットワークから Pod を削除できます。

20.6.1. 追加ネットワークからの Pod の削除
リンクのコピー

Pod を削除するだけで、追加のネットワークから Pod を削除できます。

前提条件

追加のネットワークが Pod に割り当てられている。
OpenShift CLI (oc) がインストールされている。
クラスターにログインする。

手順

Pod を削除するには、以下のコマンドを入力します。
```
oc delete pod <name> -n <namespace>
```
```
$ oc delete pod <name> -n <namespace>
```
Copy to Clipboard Toggle word wrap
- <name> は Pod の名前です。
- <namespace> は Pod が含まれる namespace です。

20.7. 追加ネットワークの編集
リンクのコピー

クラスター管理者は、既存の追加ネットワークの設定を変更することができます。

20.7.1. 追加ネットワーク割り当て定義の変更
リンクのコピー

クラスター管理者は、既存の追加ネットワークに変更を加えることができます。追加ネットワークに割り当てられる既存の Pod は更新されません。

前提条件

クラスター用に追加のネットワークを設定している。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。

手順

クラスターの追加ネットワークを編集するには、以下の手順を実行します。

以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
additionalNetworks コレクションで、追加ネットワークを変更内容で更新します。
変更を保存し、テキストエディターを終了して、変更をコミットします。

オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを更新していることを確認します。<network-name> を表示する追加ネットワークの名前に置き換えます。CNO が NetworkAttachmentDefinition オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。

oc get network-attachment-definitions <network-name> -o yaml

$ oc get network-attachment-definitions <network-name> -o yaml

Copy to Clipboard

Toggle word wrap

たとえば、以下のコンソールの出力は net1 という名前の NetworkAttachmentDefinition オブジェクトを表示します。

oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'

$ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
{ "cniVersion": "0.3.1", "type": "macvlan",
"master": "ens5",
"mode": "bridge",
"ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

Copy to Clipboard

Toggle word wrap

20.8. 追加ネットワークの削除
リンクのコピー

クラスター管理者は、追加のネットワーク割り当てを削除できます。

20.8.1. 追加ネットワーク割り当て定義の削除
リンクのコピー

クラスター管理者は、追加ネットワークを OpenShift Container Platform クラスターから削除できます。追加ネットワークは、割り当てられている Pod から削除されません。

前提条件

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

手順

クラスターから追加ネットワークを削除するには、以下の手順を実行します。

以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。
```
oc edit networks.operator.openshift.io cluster
```
```
$ oc edit networks.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap
削除しているネットワーク割り当て定義の additionalNetworks コレクションから設定を削除し、CR を変更します。
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
```
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks: [] 
```
1
Copy to Clipboard Toggle word wrap
1
additionalNetworks コレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。
変更を保存し、テキストエディターを終了して、変更をコミットします。
オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。
```
oc get network-attachment-definition --all-namespaces
```
```
$ oc get network-attachment-definition --all-namespaces
```
Copy to Clipboard Toggle word wrap

20.9. VRF へのセカンダリーネットワークの割り当て
リンクのコピー

20.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 インターフェイスに直接バインドします。

20.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 クラスターにログインします。

手順

以下のサンプル 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": [  
      {
        "type": "macvlan",  
        "master": "eth1",
        "ipam": {
            "type": "static",
            "addresses": [
            {
                "address": "191.168.1.23/24"
            }
            ]
        }
      },
      {
        "type": "vrf",
        "vrfname": "example-vrf-name",  
        "table": 1001   
      }]
    }'

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


      }]
    }'

Copy to Clipboard

Toggle word wrap

1: plugins は一覧である必要があります。リストの最初の項目は、VRF ネットワークのベースとなるセカンダリーネットワークである必要があります。一覧の 2 つ目の項目は、VRF プラグイン設定です。
2: type は vrf に設定する必要があります。
3: vrfname は、インターフェイスが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。
4: オプション: table はルーティングテーブル ID です。デフォルトで、tableid パラメーターが使用されます。これが指定されていない場合、CNI は空のルーティングテーブル ID を VRF に割り当てます。

注記

VRF は、リソースが netdevice タイプの場合にのみ正常に機能します。

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

oc create -f additional-network-attachment.yaml

$ oc create -f additional-network-attachment.yaml

Copy to Clipboard

Toggle word wrap

以下のコマンドを実行して、CNO が NetworkAttachmentDefinition CR を作成していることを確認します。<namespace> を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例: additional-network-1)。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace>
```
Copy to Clipboard Toggle word wrap
出力例
```
NAME                       AGE
additional-network-1       14m
```
```
NAME                       AGE
additional-network-1       14m
```
Copy to Clipboard Toggle word wrap
注記
CNO が CR を作成するまでに遅延が生じる可能性があります。

追加の VRF ネットワーク割り当てが正常であることの確認

VRF CNI が正しく設定され、追加のネットワーク割り当てが接続されていることを確認するには、以下を実行します。

VRF CNI を使用するネットワークを作成します。
ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが VRF の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
出力例
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap
VRF インターフェイスがセカンダリーインターフェイスのマスターであることを確認します。
```
ip link
```
```
$ ip link
```
Copy to Clipboard Toggle word wrap
出力例
```
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
```
```
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
```
Copy to Clipboard Toggle word wrap

第21章ハードウェアネットワーク
リンクのコピー

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

$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"

Copy to Clipboard

Toggle word wrap

21.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 は、デフォルトで有効にされ、default の SriovOperatorConfig CR を編集して無効にできます。SR-IOV Network Operator Admission Controller Webhook を無効にする場合は注意してください。トラブルシューティングなどの特定の状況下や、サポートされていないデバイスを使用する場合は、Webhook を無効にすることができます。

21.1.1.1. サポート対象のプラットフォーム
リンクのコピー

SR-IOV Network Operator は、以下のプラットフォームに対応しています。

ベアメタル
Red Hat OpenStack Platform (RHOSP)

21.1.1.2. サポートされるデバイス
リンクのコピー

以下のネットワークインターフェイスコントローラーは、OpenShift Container Platform でサポートされています。

Expand

表21.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	MT2892 Family [ConnectX-6 Dx]	15b3	101d
Mellanox	MT2894 Family [ConnectX‑6 Lx]	15b3	101f
Pensando ^[1]	Ionic ドライバー用 DSC-25 デュアルポート 25G 分散サービスカード	0x1dd8	0x1002
Pensando ^[1]	Ionic ドライバー用 DSC-100 デュアルポート 100G 分散サービスカード	0x1dd8	0x1003

OpenShift SR-IOV はサポートされますが、SR-IOV を使用する際に SR-IOV CNI 設定ファイルを使用して静的な Virtual Function (VF) メディアアクセス制御 (MAC) アドレスを設定する必要があります。

注記

サポートされているカードの最新リストおよび利用可能な互換性のある OpenShift Container Platform バージョンについては、Openshift Single Root I/O Virtualization (SR-IOV) and PTP hardware networks Support Matrix を参照してください。

21.1.1.3. SR-IOV ネットワークデバイスの自動検出
リンクのコピー

SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。

CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces リストは、ノード上のネットワークデバイスについての情報を提供します。

重要

SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。

21.1.1.3.1. SriovNetworkNodeState オブジェクトの例
リンクのコピー

以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。

SriovNetworkNodeState オブジェクト

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 
  - 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

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

Copy to Clipboard

Toggle word wrap

1: name フィールドの値はワーカーノードの名前と同じです。
2: interfaces スタンザには、ワーカーノード上の Operator によって検出されるすべての SR-IOV デバイスのリストが含まれます。

21.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"]

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"]

Copy to Clipboard

Toggle word wrap

以下の例は、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

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

Copy to Clipboard

Toggle word wrap

21.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 仕様の環境変数に応じて、l2fwd、l3wd または testpmd の DPDK サンプルアプリケーションのいずれかを実行できます。コンテナーイメージは、app-netutil ライブラリーをコンテナーイメージ自体に統合する例を提供します。ライブラリーを init コンテナーに統合することもできます。init コンテナーは必要なデータを収集し、データを既存の DPDK ワークロードに渡すことができます。

21.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> 接尾辞を付けることができます。

21.1.2. 次のステップ
リンクのコピー

SR-IOV Network Operator のインストール
オプション: SR-IOV Network Operator の設定
SR-IOV ネットワークデバイスの設定
OpenShift Virtualization を使用する場合: 仮想マシンの SR-IOV ネットワークへの接続
SR-IOV ネットワーク割り当ての設定
Pod の SR-IOV の追加ネットワークへの追加

21.2. SR-IOV Network Operator のインストール
リンクのコピー

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator をクラスターにインストールし、SR-IOV ネットワークデバイスとネットワークの割り当てを管理できます。

21.2.1. SR-IOV Network Operator のインストール
リンクのコピー

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

21.2.1.1. CLI: SR-IOV Network Operator のインストール
リンクのコピー

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

前提条件

SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つアカウント。

手順

openshift-sriov-network-operator namespace を作成するには、以下のコマンドを入力します。

cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

$ cat << EOF| oc create -f -
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
EOF

Copy to Clipboard

Toggle word wrap

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

cat << EOF| oc create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
  - openshift-sriov-network-operator
EOF

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

Copy to Clipboard

Toggle word wrap

SR-IOV Network Operator にサブスクライブします。

以下のコマンドを実行して OpenShift Container Platform のメジャーおよびマイナーバージョンを取得します。これは、次の手順の channel の値に必要です。
```
OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)
```
```
$ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)
```
Copy to Clipboard Toggle word wrap

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

$ 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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

出力例

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Name                                         Phase
sriov-network-operator.4.12.0-202310121402   Succeeded

Copy to Clipboard

Toggle word wrap

21.2.1.2. Web コンソール: SR-IOV Network Operator のインストール
リンクのコピー

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

前提条件

SR-IOV に対応するハードウェアを持つノードでベアメタルハードウェアにインストールされたクラスター。
OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つアカウント。

手順

SR-IOV Network Operator をインストールします。
1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. 利用可能な Operator の一覧から SR-IOV Network Operator を選択してから Install をクリックします。
3. Install Operator ページの Installed Namespace で、Operator recommend Namespace を選択します。
4. Install をクリックします。
SR-IOV Network Operator が正常にインストールされていることを確認します。
1. Operators → Installed Operators ページに移動します。
2. Status が InstallSucceeded の状態で、SR-IOV Network Operator が openshift-sriov-network-operator プロジェクトにリスト表示されていることを確認します。
  注記
  インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。
  Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。
  - Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
  - Workloads → Pods ページに移動し、openshift-sriov-network-operator プロジェクトで Pod のログを確認します。
  - YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーションworkload.openshift.io/allowed=management を Operator namespace に追加できます。
    
    $ oc annotate ns/openshift-sriov-network-operator workload.openshift.io/allowed=management
    
    Copy to Clipboard Toggle word wrap
    
    注記
    シングルノード OpenShift クラスターの場合は、namespace にアノテーション workload.openshift.io/allowed=management が必要です。

21.2.2. 次のステップ
リンクのコピー

オプション: SR-IOV Network Operator の設定

21.3. SR-IOV Network Operator の設定
リンクのコピー

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator は、クラスターで SR-IOV ネットワークデバイスおよびネットワーク割り当てを管理します。

21.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 を変更する必要があります。

21.3.1.1. SR-IOV Network Operator config カスタムリソース
リンクのコピー

sriovoperatorconfig カスタムリソースのフィールドは、以下の表で説明されています。

Expand

表21.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` に設定されています。

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

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

NAME                                      READY   STATUS    RESTARTS   AGE
network-resources-injector-5cz5p          1/1     Running   0          10m
network-resources-injector-dwqpx          1/1     Running   0          10m
network-resources-injector-lktz5          1/1     Running   0          10m

Copy to Clipboard

Toggle word wrap

21.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 によって有効にされ、すべてのコントロールプレーンノードでデーモンセットとして実行されます。

注記

SR-IOV Network Operator Admission Controller Webhook を無効にする場合は注意してください。トラブルシューティングなどの特定の状況下や、サポートされていないデバイスを使用する場合は、Webhook を無効にすることができます。サポート対象外のデバイスの設定については、サポート対象外の NIC を使用するための SR-IOV Network Operator の設定を参照してください。

以下は、3 つのコントロールプレーンノードを持つクラスターで実行される Operator Admission Controller Webhook Pod の例です。

oc get pods -n openshift-sriov-network-operator

$ oc get pods -n openshift-sriov-network-operator

Copy to Clipboard

Toggle word wrap

出力例

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

NAME                                      READY   STATUS    RESTARTS   AGE
operator-webhook-9jkw6                    1/1     Running   0          16m
operator-webhook-kbr5p                    1/1     Running   0          16m
operator-webhook-rpfrl                    1/1     Running   0          16m

Copy to Clipboard

Toggle word wrap

21.3.1.4. カスタムノードセレクターについて
リンクのコピー

SR-IOV Network Config デーモンは、クラスターノード上の SR-IOV ネットワークデバイスを検出し、設定します。デフォルトで、これはクラスター内のすべての worker ノードにデプロイされます。ノードラベルを使用して、SR-IOV Network Config デーモンが実行するノードを指定できます。

21.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> } }'

$ oc patch sriovoperatorconfig default \
  --type=merge -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableInjector": <value> } }'

Copy to Clipboard

Toggle word wrap

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableInjector: <value>

Copy to Clipboard

Toggle word wrap

21.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> } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "enableOperatorWebhook": <value> } }'

Copy to Clipboard

Toggle word wrap

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  enableOperatorWebhook: <value>

Copy to Clipboard

Toggle word wrap

21.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 '[{

$ oc patch sriovoperatorconfig default --type=json \
  -n openshift-sriov-network-operator \
  --patch '[{
      "op": "replace",
      "path": "/spec/configDaemonNodeSelector",
      "value": {<node_label>}
    }]'

Copy to Clipboard

Toggle word wrap

以下の例のように、<node_label> を適用するラベルに置き換えます: "node-role.kubernetes.io/worker": ""

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    <node_label>

Copy to Clipboard

Toggle word wrap

21.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 } }'

$ oc patch sriovoperatorconfig default --type=merge \
  -n openshift-sriov-network-operator \
  --patch '{ "spec": { "disableDrain": true } }'

Copy to Clipboard

Toggle word wrap

ヒント

または、以下の YAML を適用して Operator を更新することもできます。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  disableDrain: true

Copy to Clipboard

Toggle word wrap

21.3.2. 次のステップ
リンクのコピー

SR-IOV ネットワークデバイスの設定

21.4. SR-IOV ネットワークデバイスの設定
リンクのコピー

クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。

21.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> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 
  priority: <priority> 
  mtu: <mtu> 
  needVhostNet: false 
  numVfs: <num> 
  nicSelector: 
    vendor: "<vendor_code>" 
    deviceID: "<device_id>" 
    pfNames: ["<pf_name>", ...] 
    rootDevices: ["<pci_bus_id>", ...] 
    netFilter: "<filter_string>" 
  deviceType: <device_type> 
  isRdma: false 
    linkType: <link_type> 
  eSwitchMode: "switchdev"

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


  eSwitchMode: "switchdev"

18

Copy to Clipboard

Toggle word wrap

カスタムリソースオブジェクトの名前。

SR-IOV Network Operator がインストールされている namespace を指定します。

SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。

名前を指定するときは、resourceName で使用できる構文式 ^a-zA-Z0-9_+$ を必ず使用してください。

4

ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。

重要

SR-IOV Network Operator は、ノードネットワーク設定ポリシーを順番にノードに適用します。ノードネットワーク設定ポリシーを適用する前に、SR-IOV Network Operator は、ノードのマシン設定プール (MCP) が Degraded または Updating などの正常ではない状態にないか確認します。ノード正常ではない MCP にある場合、ノードネットワーク設定ポリシーをクラスター内のすべての対象ノードに適用するプロセスは、MCP が正常な状態に戻るまで一時停止します。

正常でない MCP 内にあるノードが、他のノード (他の MCP 内のノードを含む) にノードネットワーク設定ポリシーを適用することを阻害しないようにするには、MCP ごとに別のノードネットワーク設定ポリシーを作成する必要があります。

5

オプション: 優先度は 0 から 99 までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10 の優先度は 99 よりも高くなります。デフォルト値は 99 です。

6

オプション: Virtual Function (VF) の最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェイスコントローラー (NIC) に応じて異なります。

重要

デフォルトのネットワークインターフェイス上に仮想機能を作成する場合は、MTU がクラスター MTU と一致する値に設定されていることを確認してください。

7

オプション: /dev/vhost-net デバイスを Pod にマウントするには、needVhostNet を true に設定します。Data Plane Development Kit(DPDK) と共にマウントされた /dev/vhost-net デバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。

8

SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 128 よりも大きくすることはできません。

9

NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。

rootDevices を指定する場合、vendor、 deviceID、または 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 ドライバータイプを使用し、isRdma を true に設定します。

16

オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は false です。

isRdma パラメーターが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。

isRdma を true に設定し、追加の needVhostNet を true に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。

17

オプション: VF のリンクタイプ。イーサネットのデフォルト値は eth です。InfiniBand の場合、この値を ib に変更します。

linkType が ib に設定されている場合、SR-IOV Network Operator Webhook によって isRdma は true に自動的に設定されます。linkType が ib に設定されている場合、deviceType は vfio-pci に設定できません。

SriovNetworkNodePolicy の linkType を eth に設定しないでください。デバイスプラグインによって報告される使用可能なデバイスの数が正しくなくなる可能性があります。

18

オプション: NIC デバイスモード。許可される値は、legacy または switchdev のみです。

eSwitchMode を legacy に設定すると、デフォルトの SR-IOV 動作が有効になります。

eSwitchMode を switchdev に設定すると、ハードウェアオフロードが有効になります。

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

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

Copy to Clipboard

Toggle word wrap

以下の例では、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 
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"

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

Copy to Clipboard

Toggle word wrap

1: 仮想マシンのノードネットワークポリシーを設定する際に、numVfs フィールドは常に 1 に設定されます。
2: netFilter フィールドは、仮想マシンが RHOSP にデプロイされる際にネットワーク ID を参照する必要があります。netFilter の有効な値は、SriovNetworkNodeState オブジェクトから選択できます。

21.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"]

pfNames: ["netpf0#2-7"]

Copy to Clipboard

Toggle word wrap

netpf0 は PF インターフェイス名です。
2 は、範囲に含まれる最初の VF インデックス (0 ベース) です。
7 は、範囲に含まれる最後の VF インデックス (0 ベース) です。

以下の要件を満たす場合、異なるポリシー CR を使用して同じ PF から VF を選択できます。

numVfs の値は、同じ PF を選択するポリシーで同一である必要があります。
VF インデックスは、0 から <numVfs>-1 の範囲にある必要があります。たとえば、numVfs が 8 に設定されているポリシーがある場合、<first_vf> の値は 0 よりも小さくすることはできず、 <last_vf> は 7 よりも大きくすることはできません。
異なるポリシーの VF の範囲は重複しないようにしてください。
<first_vf> は <last_vf> よりも大きくすることはできません。

以下の例は、SR-IOV デバイスの NIC パーティション設定を示しています。

ポリシー policy-net-1 は、デフォルトの VF ドライバーと共に PF netpf0 の VF 0 が含まれるリソースプール net-1 を定義します。ポリシー policy-net-1-dpdk は、vfio VF ドライバーと共に PF netpf0 の VF 8 から 15 までが含まれるリソースプール net-1-dpdk を定義します。

ポリシー policy-net-1:

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

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

Copy to Clipboard

Toggle word wrap

ポリシー 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

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

Copy to Clipboard

Toggle word wrap

インターフェイスが正常にパーティショニングされていることを確認します

次のコマンドを実行して、インターフェイスが SR-IOV デバイスの仮想関数 (VF) にパーティショニングされていることを確認します。

ip link show <interface>

$ ip link show <interface>

1

Copy to Clipboard

Toggle word wrap

1: <interface> を、SR-IOV デバイスの VF にパーティショニングするときに指定したインターフェイス (例: ens3f1) に置き換えます。

出力例

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Copy to Clipboard

Toggle word wrap

21.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 ネットワークデバイス設定についてコントロールプレーンノードを選択していないこと。

手順

SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、SriovNetworkNodePolicy.Spec.NodeSelector でラベルを付けます。ノードのラベル付けについて、詳しくはノードのラベルを更新する方法についてを参照してください。
SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f <name>-sriov-node-network.yaml
```
```
$ oc create -f <name>-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
ここで、<name> はこの設定の名前を指定します。
設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。
SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap

21.4.3. SR-IOV 設定のトラブルシューティング
リンクのコピー

SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。

ノードの状態を表示するには、以下のコマンドを実行します。

oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

Copy to Clipboard

Toggle word wrap

ここで、<node_name> は SR-IOV ネットワークデバイスを持つノードの名前を指定します。

エラー出力: Cannot allocate memory

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

Copy to Clipboard

Toggle word wrap

ノードがメモリーを割り当てることができないことを示す場合は、以下の項目を確認します。

ノードの BIOS でグローバル SR-IOV 設定が有効になっていることを確認します。
ノードの BIOS で VT-d が有効であることを確認します。

21.4.4. SR-IOV ネットワークの VRF への割り当て
リンクのコピー

クラスター管理者は、CNI VRF プラグインを使用して、SR-IOV ネットワークインターフェイスを VRF ドメインに割り当てることができます。

これを実行するには、VRF 設定を SriovNetwork リソースのオプションの metaPlugins パラメーターに追加します。

注記

VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE オプションを使用できます。SO_BINDTODEVICE は、渡されるインターフェイス名で指定されているデバイスにソケットをバインドします (例: eth1)。SO_BINDTODEVICE を使用するには、アプリケーションに CAP_NET_RAW 機能がある必要があります。

ip vrf exec コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェイスに直接バインドします。

21.4.4.1. CNI VRF プラグインを使用した追加 SR-IOV ネットワーク割り当ての作成
リンクのコピー

SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。

注記

SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

CNI VRF プラグインで追加の SR-IOV ネットワーク割り当てを作成するには、以下の手順を実行します。

前提条件

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

手順

追加の SR-IOV ネットワーク割り当て用の SriovNetwork カスタムリソース (CR) を作成し、以下のサンプル CR のように metaPlugins 設定を挿入します。YAML を sriov-network-attachment.yaml ファイルとして保存します。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf", 
      "vrfname": "example-vrf-name" 
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: example-network
  namespace: additional-sriov-network-1
spec:
  ipam: |
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [{
        "dst": "0.0.0.0/0"
      }],
      "gateway": "10.56.217.1"
    }
  vlan: 0
  resourceName: intelnics
  metaPlugins : |
    {
      "type": "vrf",

1


      "vrfname": "example-vrf-name"

2

Copy to Clipboard

Toggle word wrap

1: type は vrf に設定する必要があります。
2: vrfname は、インターフェイスが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。

SriovNetwork リソースを作成します。
```
oc create -f sriov-network-attachment.yaml
```
```
$ oc create -f sriov-network-attachment.yaml
```
Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR が正常に作成されることの確認

以下のコマンドを実行して、SR-IOV Network Operator が NetworkAttachmentDefinition CR を作成していることを確認します。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
<namespace> を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例: additional-sriov-network-1)。
出力例
```
NAME                            AGE
additional-sriov-network-1      14m
```
```
NAME                            AGE
additional-sriov-network-1      14m
```
Copy to Clipboard Toggle word wrap
注記
SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。

追加の SR-IOV ネットワーク割り当てが正常であることの確認

VRF CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。

VRF CNI を使用する SR-IOV ネットワークを作成します。
ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
```
ip vrf show
```
```
$ ip vrf show
```
Copy to Clipboard Toggle word wrap
出力例
```
Name              Table
-----------------------
red                 10
```
```
Name              Table
-----------------------
red                 10
```
Copy to Clipboard Toggle word wrap
VRF インターフェイスがセカンダリーインターフェイスのマスターであることを確認します。
```
ip link
```
```
$ ip link
```
Copy to Clipboard Toggle word wrap
出力例
```
...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...
```
```
...
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
...
```
Copy to Clipboard Toggle word wrap

21.4.5. 次のステップ
リンクのコピー

SR-IOV ネットワーク割り当ての設定

21.5. SR-IOV イーサネットネットワーク割り当ての設定
リンクのコピー

クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスのイーサネットネットワーク割り当てを設定できます。

21.5.1. イーサネットデバイス設定オブジェクト
リンクのコピー

イーサネットネットワークデバイスは、SriovNetwork オブジェクトを定義して設定できます。

以下の YAML は SriovNetwork オブジェクトについて説明しています。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  vlan: <vlan> 
  spoofChk: "<spoof_check>" 
  ipam: |- 
    {}
  linkState: <link_state> 
  maxTxRate: <max_tx_rate> 
  minTxRate: <min_tx_rate> 
  vlanQoS: <vlan_qos> 
  trust: "<trust_vf>" 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  vlan: <vlan>

5


  spoofChk: "<spoof_check>"

6


  ipam: |-

7


    {}
  linkState: <link_state>

8


  maxTxRate: <max_tx_rate>

9


  minTxRate: <min_tx_rate>

10


  vlanQoS: <vlan_qos>

11


  trust: "<trust_vf>"

12


  capabilities: <capabilities>

13

Copy to Clipboard

Toggle word wrap

1: オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
2: SR-IOV Network Operator がインストールされている namespace を指定します。
3: この追加ネットワークの SR-IOV ハードウェアを定義する SriovNetworkNodePolicy オブジェクトの spec.resourceName パラメーターの値。
4: SriovNetwork オブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。
5: オプション: 追加ネットワークの仮想 LAN (VLAN) ID。整数値は 0 から 4095 である必要があります。デフォルト値は 0 です。
6: オプション: VF の spoof チェックモード。許可される値は、文字列の "on" および "off" です。
重要
指定する値を引用符で囲む必要があります。そうしないと、オブジェクトは SR-IOV ネットワーク Operator によって拒否されます。
7: YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
8: オプション: Virtual Function (VF) のリンク状態。許可される値は、enable、disable、および auto です。
9: オプション: VF の最大伝送レート (Mbps)。
10: オプション: VF の最小伝送レート (Mbps)。この値は、最大伝送レート以下である必要があります。
注記
Intel NIC は minTxRate パラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。
11: オプション: VF の IEEE 802.1p 優先度レベル。デフォルト値は 0 です。
12: オプション: VF の信頼モード。許可される値は、文字列の "on" および "off" です。
重要
指定する値を引用符で囲む必要があります。囲まないと、SR-IOV Network Operator はオブジェクトを拒否します。
13: オプション: この追加ネットワークに設定する機能。IP アドレスのサポートを有効にするには、"{ "ips": true }" を指定できます。または、MAC アドレスのサポートを有効にするには "{ "mac": true }" を指定します。

21.5.1.1. 追加ネットワークの IP アドレス割り当ての設定
リンクのコピー

IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。

以下の IP アドレスの割り当てタイプを使用できます。

静的割り当て。
DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
Whereabouts IPAM CNI プラグインを使用した動的割り当て。

21.5.1.1.1. 静的 IP アドレス割り当ての設定
リンクのコピー

以下の表は、静的 IP アドレスの割り当ての設定について説明しています。

Expand

表21.3 ipam 静的設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `static` が必要です。
`addresses`	`array`	仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
`routes`	`array`	Pod 内で設定するルートを指定するオブジェクトの配列です。
`dns`	`array`	オプション: DNS の設定を指定するオブジェクトの配列です。

addressesの配列には、以下のフィールドのあるオブジェクトが必要です。

Expand

表21.4 ipam.addresses[] 配列
フィールド	型	説明
`address`	`string`	指定する IP アドレスおよびネットワーク接頭辞。たとえば、`10.10.21.10/24` を指定すると、追加のネットワークに IP アドレスの `10.10.21.10` が割り当てられ、ネットマスクは `255.255.255.0` になります。
`gateway`	`string`	egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。

Expand

表21.5 ipam.routes[] 配列
フィールド	型	説明
`dst`	`string`	CIDR 形式の IP アドレス範囲 (`192.168.17.0/24`、またはデフォルトルートの `0.0.0.0/0`)。
`gw`	`string`	ネットワークトラフィックがルーティングされるゲートウェイ。

Expand

表21.6 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/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

21.5.1.1.2. 動的 IP アドレス (DHCP) 割り当ての設定
リンクのコピー

以下の JSON は、DHCP を使用した動的 IP アドレスの割り当ての設定について説明しています。

DHCP リースの更新

Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。

SR-IOV ネットワーク Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。

DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。

shim ネットワーク割り当ての定義例

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: dhcp-shim
    namespace: default
    type: Raw
    rawCNIConfig: |-
      {
        "name": "dhcp-shim",
        "cniVersion": "0.3.1",
        "type": "bridge",
        "ipam": {
          "type": "dhcp"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

表21.7 ipam DHCP 設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `dhcp` が必要です。

動的 IP アドレス (DHCP) 割り当ての設定例

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

21.5.1.1.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
リンクのコピー

Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。

以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。

Expand

表21.8 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"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

21.5.1.1.4. Whereabouts reconciler デーモンセットの作成
リンクのコピー

Whereabouts reconciler は、Whereabouts IP アドレス管理 (IPAM) ソリューションを使用して、クラスター内の Pod の動的 IP アドレス割り当てを管理します。これにより、各 Pod が指定された IP アドレス範囲から一意の IP アドレスを確実に取得します。また、Pod が削除またはスケールダウンされた場合の IP アドレスの解放も処理します。

注記

NetworkAttachmentDefinition カスタムリソースを使用して動的 IP アドレスを割り当てることもできます。

Whereabouts reconciler デーモンセットは、Cluster Network Operator を通じて追加のネットワークを設定するときに自動的に作成されます。YAML マニフェストから追加のネットワークを設定する場合、これは自動的には作成されません。

Whereabouts reconciler デーモンセットのデプロイメントをトリガーするには、Cluster Network Operator のカスタムリソースファイルを編集して、Whereabouts-shim ネットワーク割り当てを手動で作成する必要があります。

Whereabouts reconciler デーモンセットをデプロイするには、次の手順を使用します。

手順

以下のコマンドを実行して、Network.operator.openshift.io カスタムリソース (CR) を編集します。
```
oc edit network.operator.openshift.io cluster
```
```
$ oc edit network.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

CR の AdditionalNetworks パラメーターを変更して、whereabouts-shim ネットワーク割り当て定義を追加します。以下に例を示します。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

ファイルを保存し、テキストエディターを編集します。

次のコマンドを実行して、whereabouts-reconciler デーモンセットが正常にデプロイされたことを確認します。

oc get all -n openshift-multus | grep whereabouts-reconciler

$ oc get all -n openshift-multus | grep whereabouts-reconciler

Copy to Clipboard

Toggle word wrap

出力例

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

Copy to Clipboard

Toggle word wrap

21.5.2. SR-IOV の追加ネットワークの設定
リンクのコピー

SriovNetwork オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork オブジェクトの作成時に、SR-IOV Network Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

注記

SriovNetwork オブジェクトが running 状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。

前提条件

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

手順

SriovNetwork オブジェクトを作成してから、YAML を <name>.yaml ファイルに保存します。<name> はこの追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

オブジェクトを作成するには、以下のコマンドを入力します。
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
ここで、<name> は追加ネットワークの名前を指定します。
オプション: 以下のコマンドを実行して、直前の手順で作成した SriovNetwork オブジェクトに関連付けられた NetworkAttachmentDefinition オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace> を SriovNetwork オブジェクトで指定した networkNamespace に置き換えます。
```
oc get net-attach-def -n <namespace>
```
```
$ oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

21.5.3. 次のステップ
リンクのコピー

Pod の SR-IOV の追加ネットワークへの追加

21.6. SR-IOV InfiniBand ネットワーク割り当ての設定
リンクのコピー

クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスの InfiniBand (IB) ネットワーク割り当てを設定できます。

21.6.1. InfiniBand デバイス設定オブジェクト
リンクのコピー

SriovIBNetwork オブジェクトを定義することで、InfiniBand (IB) ネットワークデバイスを設定できます。

以下の YAML は、SriovIBNetwork オブジェクトについて説明しています。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name> 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: <sriov_resource_name> 
  networkNamespace: <target_namespace> 
  ipam: |- 
    {}
  linkState: <link_state> 
  capabilities: <capabilities>

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: <name>

1


  namespace: openshift-sriov-network-operator

2


spec:
  resourceName: <sriov_resource_name>

3


  networkNamespace: <target_namespace>

4


  ipam: |-

5


    {}
  linkState: <link_state>

6


  capabilities: <capabilities>

7

Copy to Clipboard

Toggle word wrap

1: オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
2: SR-IOV Operator がインストールされている namespace。
3: この追加ネットワークの SR-IOV ハードウェアを定義する SriovNetworkNodePolicy オブジェクトの spec.resourceName パラメーターの値。
4: SriovIBNetwork オブジェクトのターゲット namespace。ターゲット namespace の Pod のみをネットワークデバイスに割り当てることができます。
5: オプション: YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクト。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
6: オプション: Virtual Function (VF) のリンク状態。許可される値は、enable、disable、および auto です。
7: オプション: このネットワークに設定する機能。"{ "ips": true }" を指定して IP アドレスのサポートを有効にするか、"{ "infinibandGUID": true }" を指定して IB Global Unique Identifier (GUID) サポートを有効にします。

21.6.1.1. 追加ネットワークの IP アドレス割り当ての設定
リンクのコピー

IPAM (IP アドレス管理) Container Network Interface (CNI) プラグインは、他の CNI プラグインの IP アドレスを提供します。

以下の IP アドレスの割り当てタイプを使用できます。

静的割り当て。
DHCP サーバーを使用した動的割り当て。指定する DHCP サーバーは、追加のネットワークから到達可能である必要があります。
Whereabouts IPAM CNI プラグインを使用した動的割り当て。

21.6.1.1.1. 静的 IP アドレス割り当ての設定
リンクのコピー

以下の表は、静的 IP アドレスの割り当ての設定について説明しています。

Expand

表21.9 ipam 静的設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `static` が必要です。
`addresses`	`array`	仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。
`routes`	`array`	Pod 内で設定するルートを指定するオブジェクトの配列です。
`dns`	`array`	オプション: DNS の設定を指定するオブジェクトの配列です。

addressesの配列には、以下のフィールドのあるオブジェクトが必要です。

Expand

表21.10 ipam.addresses[] 配列
フィールド	型	説明
`address`	`string`	指定する IP アドレスおよびネットワーク接頭辞。たとえば、`10.10.21.10/24` を指定すると、追加のネットワークに IP アドレスの `10.10.21.10` が割り当てられ、ネットマスクは `255.255.255.0` になります。
`gateway`	`string`	egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。

Expand

表21.11 ipam.routes[] 配列
フィールド	型	説明
`dst`	`string`	CIDR 形式の IP アドレス範囲 (`192.168.17.0/24`、またはデフォルトルートの `0.0.0.0/0`)。
`gw`	`string`	ネットワークトラフィックがルーティングされるゲートウェイ。

Expand

表21.12 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/24"
        }
      ]
  }
}

{
  "ipam": {
    "type": "static",
      "addresses": [
        {
          "address": "191.168.1.7/24"
        }
      ]
  }
}

Copy to Clipboard

Toggle word wrap

21.6.1.1.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"
        }
      }
  # ...

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"
        }
      }
  # ...

Copy to Clipboard

Toggle word wrap

Expand

表21.13 ipam DHCP 設定オブジェクト
フィールド	型	説明
`type`	`string`	IPAM のアドレスタイプ。値 `dhcp` が必要です。

動的 IP アドレス (DHCP) 割り当ての設定例

{
  "ipam": {
    "type": "dhcp"
  }
}

{
  "ipam": {
    "type": "dhcp"
  }
}

Copy to Clipboard

Toggle word wrap

21.6.1.1.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
リンクのコピー

Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスを追加のネットワークに動的に割り当てることができます。

以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定について説明しています。

Expand

表21.14 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"
    ]
  }
}

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/27",
    "exclude": [
       "192.0.2.192/30",
       "192.0.2.196/32"
    ]
  }
}

Copy to Clipboard

Toggle word wrap

21.6.1.1.4. Whereabouts reconciler デーモンセットの作成
リンクのコピー

Whereabouts reconciler は、Whereabouts IP アドレス管理 (IPAM) ソリューションを使用して、クラスター内の Pod の動的 IP アドレス割り当てを管理します。これにより、各 Pod が指定された IP アドレス範囲から一意の IP アドレスを確実に取得します。また、Pod が削除またはスケールダウンされた場合の IP アドレスの解放も処理します。

注記

NetworkAttachmentDefinition カスタムリソースを使用して動的 IP アドレスを割り当てることもできます。

Whereabouts reconciler デーモンセットは、Cluster Network Operator を通じて追加のネットワークを設定するときに自動的に作成されます。YAML マニフェストから追加のネットワークを設定する場合、これは自動的には作成されません。

Whereabouts reconciler デーモンセットのデプロイメントをトリガーするには、Cluster Network Operator のカスタムリソースファイルを編集して、Whereabouts-shim ネットワーク割り当てを手動で作成する必要があります。

Whereabouts reconciler デーモンセットをデプロイするには、次の手順を使用します。

手順

以下のコマンドを実行して、Network.operator.openshift.io カスタムリソース (CR) を編集します。
```
oc edit network.operator.openshift.io cluster
```
```
$ oc edit network.operator.openshift.io cluster
```
Copy to Clipboard Toggle word wrap

CR の AdditionalNetworks パラメーターを変更して、whereabouts-shim ネットワーク割り当て定義を追加します。以下に例を示します。

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: whereabouts-shim
    namespace: default
    rawCNIConfig: |-
      {
       "name": "whereabouts-shim",
       "cniVersion": "0.3.1",
       "type": "bridge",
       "ipam": {
         "type": "whereabouts"
       }
      }
    type: Raw

Copy to Clipboard

Toggle word wrap

ファイルを保存し、テキストエディターを編集します。

次のコマンドを実行して、whereabouts-reconciler デーモンセットが正常にデプロイされたことを確認します。

oc get all -n openshift-multus | grep whereabouts-reconciler

$ oc get all -n openshift-multus | grep whereabouts-reconciler

Copy to Clipboard

Toggle word wrap

出力例

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

pod/whereabouts-reconciler-jnp6g 1/1 Running 0 6s
pod/whereabouts-reconciler-k76gg 1/1 Running 0 6s
pod/whereabouts-reconciler-k86t9 1/1 Running 0 6s
pod/whereabouts-reconciler-p4sxw 1/1 Running 0 6s
pod/whereabouts-reconciler-rvfdv 1/1 Running 0 6s
pod/whereabouts-reconciler-svzw9 1/1 Running 0 6s
daemonset.apps/whereabouts-reconciler 6 6 6 6 6 kubernetes.io/os=linux 6s

Copy to Clipboard

Toggle word wrap

21.6.2. SR-IOV の追加ネットワークの設定
リンクのコピー

SriovIBNetwork オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovIBNetwork オブジェクトの作成時に、SR-IOV Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

注記

SriovIBNetwork オブジェクトが、running 状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。

前提条件

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

手順

SriovIBNetwork CR を作成してから、YAML を <name>.yaml ファイルに保存します。<name> は、この追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovIBNetwork
metadata:
  name: attach1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  networkNamespace: project2
  ipam: |-
    {
      "type": "host-local",
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "gateway": "10.56.217.1"
    }

Copy to Clipboard

Toggle word wrap

オブジェクトを作成するには、以下のコマンドを入力します。
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap
ここで、<name> は追加ネットワークの名前を指定します。
オプション: 以下のコマンドを実行して、直前の手順で作成した SriovIBNetwork オブジェクトに関連付けられた NetworkAttachmentDefinition オブジェクトが存在することを確認します。<namespace> を SriovIBNetwork オブジェクトで指定した networkNamespace に置き換えます。
```
oc get net-attach-def -n <namespace>
```
```
$ oc get net-attach-def -n <namespace>
```
Copy to Clipboard Toggle word wrap

21.6.3. 次のステップ
リンクのコピー

Pod の SR-IOV の追加ネットワークへの追加

21.7. Pod の SR-IOV の追加ネットワークへの追加
リンクのコピー

Pod を既存の Single Root I/O Virtualization (SR-IOV) ネットワークに追加できます。

21.7.1. ネットワーク割り当てのランタイム設定
リンクのコピー

Pod を追加のネットワークに割り当てる場合、ランタイム設定を指定して Pod の特定のカスタマイズを行うことができます。たとえば、特定の MAC ハードウェアアドレスを要求できます。

Pod 仕様にアノテーションを設定して、ランタイム設定を指定します。アノテーションキーは k8s.v1.cni.cncf.io/networks で、ランタイム設定を記述する JSON オブジェクトを受け入れます。

21.7.1.1. イーサネットベースの SR-IOV 割り当てのランタイム設定
リンクのコピー

以下の JSON は、イーサネットベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。

[
  {
    "name": "<name>", 
    "mac": "<mac_address>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<name>",

1


    "mac": "<mac_address>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: SR-IOV ネットワーク割り当て定義 CR の名前。
2: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、SriovNetwork オブジェクトで { "mac": true } も指定する必要があります。
3: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、SriovNetwork オブジェクトで { "ips": true } も指定する必要があります。

ランタイム設定の例

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "net1",
          "mac": "20:04:0f:f1:88:01",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

21.7.1.2. InfiniBand ベースの SR-IOV 割り当てのランタイム設定
リンクのコピー

以下の JSON は、InfiniBand ベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。

[
  {
    "name": "<network_attachment>", 
    "infiniband-guid": "<guid>", 
    "ips": ["<cidr_range>"] 
  }
]

[
  {
    "name": "<network_attachment>",

1


    "infiniband-guid": "<guid>",

2


    "ips": ["<cidr_range>"]

3

}
]

Copy to Clipboard

Toggle word wrap

1: SR-IOV ネットワーク割り当て定義 CR の名前。
2: SR-IOV デバイスの InfiniBand GUIDこの機能を使用するには、SriovIBNetwork オブジェクトで { "infinibandGUID": true } も指定する必要があります。
3: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、SriovIBNetwork オブジェクトで { "ips": true } も指定する必要があります。

ランタイム設定の例

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "ib1",
          "infiniband-guid": "c2:11:22:33:44:55:66:77",
          "ips": ["192.168.10.1/24", "2001::1/64"]
        }
      ]
spec:
  containers:
  - name: sample-container
    image: <image>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

21.7.2. Pod の追加ネットワークへの追加
リンクのコピー

Pod を追加のネットワークに追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。

Pod が作成されると、追加のネットワークが割り当てられます。ただし、Pod がすでに存在する場合は、追加のネットワークをこれに割り当てることはできません。

Pod が追加ネットワークと同じ namespace にあること。

注記

SR-IOV Network Resource Injector は、Pod の最初のコンテナーに resource フィールドを自動的に追加します。

データプレーン開発キット (DPDK) モードでインテル製のネットワークインターフェイスコントローラー (NIC) を使用している場合には、Pod 内の最初のコンテナーのみが NIC にアクセスできるように設定されています。SR-IOV 追加ネットワークは、Sriov Network Node Policy オブジェクトで device Type が vfio-pci に設定されてる場合は DPDK モードに設定されます。

この問題は、NIC にアクセスする必要のあるコンテナーが Pod オブジェクトで定義された最初のコンテナーであることを確認するか、Network Resource Injector を無効にすることで回避できます。詳細は、BZ#1990953 を参照してください。

前提条件

OpenShift CLI (oc) がインストールされている。
クラスターにログインする。
SR-IOV Operator のインストール。
Pod を割り当てる SriovNetwork オブジェクトまたは SriovIBNetwork オブジェクトのいずれかを作成する。

手順

アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。
1. カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。<network> を、Pod に関連付ける追加ネットワークの名前に置き換えます。
  metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
  1
  Copy to Clipboard Toggle word wrap
  1
  複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。
2. カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。
  metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
  1
  "namespace": "<namespace>",
  2
  "default-route": ["<default-route>"]
  3
  } ]
  Copy to Clipboard Toggle word wrap
  1
  NetworkAttachmentDefinition オブジェクトによって定義される追加のネットワークの名前を指定します。
  2
  NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。
  3
  オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。
Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。
```
oc create -f <name>.yaml
```
```
$ oc create -f <name>.yaml
```
Copy to Clipboard Toggle word wrap

オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

oc get pod <name> -o yaml

$ oc get pod <name> -o yaml

Copy to Clipboard

Toggle word wrap

以下の例では、example-pod Pod が追加ネットワークの net1 に割り当てられています。

oc get pod example-pod -o yaml

$ oc get pod example-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: macvlan-bridge
    k8s.v1.cni.cncf.io/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:
  ...

Copy to Clipboard

Toggle word wrap

1: k8s.v1.cni.cncf.io/networks-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。

21.7.3. Non-Uniform Memory Access (NUMA) で配置された SR-IOV Pod の作成
リンクのコピー

NUMA で配置された SR-IOV Pod は、restricted または single-numa-node Topology Manager ポリシーで同じ NUMA ノードから割り当てられる SR-IOV および CPU リソースを制限することによって作成できます。

前提条件

OpenShift CLI (oc) がインストールされている。
CPU マネージャーのポリシーを static に設定している。CPU マネージャーの詳細は、関連情報セクションを参照してください。
Topology Manager ポリシーを single-numa-node に設定している。
注記
single-numa-node が要求を満たさない場合は、Topology Manager ポリシーを restricted にするように設定できます。

手順

以下の SR-IOV Pod 仕様を作成してから、YAML を <name>-sriov-pod.yaml ファイルに保存します。<name> をこの Pod の名前に置き換えます。

以下の例は、SR-IOV Pod 仕様を示しています。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name> 
spec:
  containers:
  - name: sample-container
    image: <image> 
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi" 
        cpu: "2" 
      requests:
        memory: "1Gi"
        cpu: "2"

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name>

1


spec:
  containers:
  - name: sample-container
    image: <image>

2


    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi"

3


        cpu: "2"

4


      requests:
        memory: "1Gi"
        cpu: "2"

Copy to Clipboard

Toggle word wrap

1: <name> を、SR-IOV ネットワーク割り当て定義 CR の名前に置き換えます。
2: <image> を sample-pod イメージの名前に置き換えます。
3: Guaranteed QoS を指定して SR-IOV Pod を作成するには、メモリー要求 に等しい メモリー制限 を設定します。
4: Guaranteed QoS を指定して SR-IOV Pod を作成するには、cpu 要求 に等しい cpu 制限 を設定します。

以下のコマンドを実行して SR-IOV Pod のサンプルを作成します。
```
oc create -f <filename>
```
```
$ oc create -f <filename> 
```
1
Copy to Clipboard Toggle word wrap
1
<filename> を、先の手順で作成したファイルの名前に置き換えます。
sample-pod が Guaranteed QoS を指定して設定されていることを確認します。
```
oc describe pod sample-pod
```
```
$ oc describe pod sample-pod
```
Copy to Clipboard Toggle word wrap
sample-pod が排他的 CPU を指定して割り当てられていることを確認します。
```
oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
Copy to Clipboard Toggle word wrap
sample-pod に割り当てられる SR-IOV デバイスと CPU が同じ NUMA ノード上にあることを確認します。
```
oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
```
$ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
```
Copy to Clipboard Toggle word wrap

21.7.4. OpenStack で SR-IOV を使用するクラスター用のテスト Pod テンプレート
リンクのコピー

次の testpmd Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。

testpmd Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

1


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: この例では、パフォーマンスプロファイルの名前が cnf-performance profile であると想定しています。

21.8. SR-IOV ネットワークのインターフェイスレベルのネットワーク sysctl 設定の設定
リンクのコピー

クラスター管理者は、SR-IOV ネットワークデバイスに接続された Pod の Container Network Interface (CNI) メタプラグインの調整を使用して、インターフェイスレベルのネットワーク sysctl を変更できます。

21.8.1. SR-IOV 対応 NIC を使用したノードのラベル付け
リンクのコピー

SR-IOV 対応ノードのみで SR-IOV を有効にしたい場合は、いくつかの方法があります。

Node Feature Discovery (NFD) Operator をインストールします。NFD は SR-IOV 対応の NIC の存在を検出し、ノードに node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = true ラベルを付けます。
各ノードの SriovNetworkNodeState CR を調べます。interfaces スタンザには、ワーカーノード上の SR-IOV Network Operator によって検出されるすべての SR-IOV デバイスの一覧が含まれます。次のコマンドを使用して、各ノードに feature.node.kubernetes.io/network-sriov.capable: "true" というラベルを付けます。
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
```
$ oc label node <node_name> feature.node.kubernetes.io/network-sriov.capable="true"
```
Copy to Clipboard Toggle word wrap
注記
任意の名前でノードにラベルを付けることができます。

21.8.2. 1 つの sysctl フラグの設定
リンクのコピー

SR-IOV ネットワークデバイスに接続された Pod のインターフェイスレベルのネットワーク sysctl 設定を設定できます。

この例では、作成された仮想インターフェイスで net.ipv4.conf.IFNAME.accept_redirects が 1 に設定されます。

sysctl-tuning-test は、この例で使用される namespace です。

次のコマンドを使用して、sysctl-tuning-test namespace を作成します。
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

21.8.2.1. SR-IOV ネットワークデバイスを持つノードで 1 つの sysctl フラグを設定する
リンクのコピー

SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。

注記

SriovNetworkNodePolicy オブジェクトで指定された設定を適用すると、SR-IOV Operator がノードをドレインして再起動する場合があります。

設定の変更が適用されるまでに数分の時間がかかる場合があります。

この手順に従って、SriovNetworkNodePolicy カスタムリソース (CR) を作成します。

手順

SriovNetworkNodePolicy カスタムリソース (CR) を作成します。たとえば、次の YAML をファイル policyoneflag-sriov-node-network.yaml として保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  nodeSelector: 
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens5"] 
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyoneflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  nodeSelector: 
```
4
```
    feature.node.kubernetes.io/network-sriov.capable="true"
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens5"] 
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
カスタムリソースオブジェクトの名前。
2
SR-IOV Network Operator がインストールされている namespace を指定します。
3
SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
4
ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
5
オプション: 優先度は 0 から 99 までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10 の優先度は 99 よりも高くなります。デフォルト値は 99 です。
6
SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 128 よりも大きくすることはできません。
7
NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。rootDevices を指定する場合、vendor、 deviceID、または pfName の値も指定する必要があります。pfNames および rootDevices の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。
8
オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
9
オプション: Virtual Function (VF) のドライバータイプ。許可される唯一の値は netdevice です。ベアメタルノードで Mellanox NIC を DPDK モードで動作させるには、isRdma を true に設定します。
10
オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は false です。isRdma パラメーターが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdma を true に設定し、追加の needVhostNet を true に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。
注記
vfio-pci ドライバータイプはサポートされていません。
SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f policyoneflag-sriov-node-network.yaml
```
```
$ oc create -f policyoneflag-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
設定の更新が適用された後に、sriov-network-operator namespace 変更のすべての Pod が Running ステータスに移行します。
SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
出力例
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

21.8.2.2. SR-IOV ネットワークでの sysctl の設定
リンクのコピー

SriovNetwork リソースのオプションの metaPlugins パラメーターにチューニング設定を追加することで、SR-IOV により作成された仮想インターフェイスにインターフェイス固有の sysctl 設定を設定できます。

SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。

注記

SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

インターフェイスレベルのネットワーク net.ipv4.conf.IFNAME.accept_redirects sysctl 設定を変更するには、Container Network Interface (CNI) チューニングプラグインを使用して追加の SR-IOV ネットワークを作成します。

前提条件

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

手順

追加の SR-IOV ネットワーク割り当て用の SriovNetwork カスタムリソース (CR) を作成し、以下のサンプル CR のように metaPlugins 設定を挿入します。YAML を sriov-network-interface-sysctl.yaml ファイルとして保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyoneflag 
  networkNamespace: sysctl-tuning-test 
  ipam: '{ "type": "static" }' 
  capabilities: '{ "mac": true, "ips": true }' 
  metaPlugins : | 
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: onevalidflag 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyoneflag 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  ipam: '{ "type": "static" }' 
```
5
```
  capabilities: '{ "mac": true, "ips": true }' 
```
6
```
  metaPlugins : | 
```
7
```
    {
      "type": "tuning",
      "capabilities":{
        "mac":true
      },
      "sysctl":{
         "net.ipv4.conf.IFNAME.accept_redirects": "1"
      }
    }
```
Copy to Clipboard Toggle word wrap
1
オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
2
SR-IOV Network Operator がインストールされている namespace を指定します。
3
この追加ネットワークの SR-IOV ハードウェアを定義する SriovNetworkNodePolicy オブジェクトの spec.resourceName パラメーターの値。
4
SriovNetwork オブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。
5
YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
6
オプション: 追加のネットワークの機能を設定します。IP アドレスのサポートを有効にするには、"{ "ips": true }" を指定できます。または、MAC アドレスのサポートを有効にするには "{ "mac": true }" を指定します。
7
オプション: metaPlugins パラメーターは、デバイスに機能を追加するために使用されます。このユースケースでは、type フィールドを tuning に設定します。設定したいインターフェイスレベルのネットワーク sysctl を sysctl フィールドに指定します。

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

oc create -f sriov-network-interface-sysctl.yaml

$ oc create -f sriov-network-interface-sysctl.yaml

Copy to Clipboard

Toggle word wrap

NetworkAttachmentDefinition CR が正常に作成されることの確認

以下のコマンドを実行して、SR-IOV Network Operator が NetworkAttachmentDefinition CR を作成していることを確認します。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
<namespace> を、SriovNetwork オブジェクトで指定した networkNamespace の値に置き換えます。たとえば、sysctl-tuning-test です。
出力例
```
NAME                                  AGE
onevalidflag                          14m
```
```
NAME                                  AGE
onevalidflag                          14m
```
Copy to Clipboard Toggle word wrap
注記
SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。

追加の SR-IOV ネットワーク割り当てが正常であることの確認

チューニング CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。

Pod CR を作成します。次の YAML を examplepod.yaml ファイルとして保存します。

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",  
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {
          "name": "onevalidflag",

1


          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: SR-IOV ネットワーク割り当て定義 CR の名前。
2: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、SriovNetwork オブジェクトで { "mac": true } も指定する必要があります。
3: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、SriovNetwork オブジェクトで { "ips": true } も指定する必要があります。

Pod CR を作成します。
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、Pod が作成されていることを確認します。

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

出力例

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、Pod にログインします。
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
設定された sysctl フラグの値を確認します。次のコマンドを実行して、net.ipv4.conf.IFNAME.accept_redirects の値を見つけます。
```
sysctl net.ipv4.conf.net1.accept_redirects
```
```
$ sysctl net.ipv4.conf.net1.accept_redirects
```
Copy to Clipboard Toggle word wrap
出力例
```
net.ipv4.conf.net1.accept_redirects = 1
```
```
net.ipv4.conf.net1.accept_redirects = 1
```
Copy to Clipboard Toggle word wrap

21.8.3. ボンディングされた SR-IOV インターフェイスフラグに関連付けられた Pod の sysctl 設定の設定
リンクのコピー

ボンディングされた SR-IOV ネットワークデバイスに接続された Pod のインターフェイスレベルのネットワーク sysctl 設定を設定できます。

この例では、設定可能な特定のネットワークインターフェイスレベルの sysctl 設定がボンドインターフェイスに設定されています。

sysctl-tuning-test は、この例で使用される namespace です。

次のコマンドを使用して、sysctl-tuning-test namespace を作成します。
```
oc create namespace sysctl-tuning-test
```
```
$ oc create namespace sysctl-tuning-test
```
Copy to Clipboard Toggle word wrap

21.8.3.1. SR-IOV ネットワークデバイスがボンドされたノードですべての sysctl フラグを設定する
リンクのコピー

SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io カスタムリソース定義 (CRD) を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。

注記

SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。

設定の変更が適用されるまでに数分かかる場合があります。

この手順に従って、SriovNetworkNodePolicy カスタムリソース (CR) を作成します。

手順

SriovNetworkNodePolicy カスタムリソース (CR) を作成します。次の YAML を policyallflags-sriov-node-network.yaml ファイルとして保存します。policyallflags を設定の名前に置き換えます。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  nodeSelector: 
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
  numVfs: 5 
  nicSelector: 
    pfNames: ["ens1f0"]  
  deviceType: "netdevice" 
  isRdma: false 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policyallflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  nodeSelector: 
```
4
```
    node.alpha.kubernetes-incubator.io/nfd-network-sriov.capable = `true`
  priority: 10 
```
5
```
  numVfs: 5 
```
6
```
  nicSelector: 
```
7
```
    pfNames: ["ens1f0"]  
```
8
```
  deviceType: "netdevice" 
```
9
```
  isRdma: false 
```
10
Copy to Clipboard Toggle word wrap
1
カスタムリソースオブジェクトの名前。
2
SR-IOV Network Operator がインストールされている namespace を指定します。
3
SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
4
ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
5
オプション: 優先度は 0 から 99 までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10 の優先度は 99 よりも高くなります。デフォルト値は 99 です。
6
SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 128 よりも大きくすることはできません。
7
NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。rootDevices を指定する場合、vendor、 deviceID、または pfName の値も指定する必要があります。pfNames および rootDevices の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。
8
オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
9
オプション: Virtual Function (VF) のドライバータイプ。許可される唯一の値は netdevice です。ベアメタルノードで Mellanox NIC を DPDK モードで動作させるには、isRdma を true に設定します。
10
オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は false です。isRdma パラメーターが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdma を true に設定し、追加の needVhostNet を true に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。
注記
vfio-pci ドライバータイプはサポートされていません。
SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f policyallflags-sriov-node-network.yaml
```
```
$ oc create -f policyallflags-sriov-node-network.yaml
```
Copy to Clipboard Toggle word wrap
設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。
SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。
```
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
```
$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
```
Copy to Clipboard Toggle word wrap
出力例
```
Succeeded
```
```
Succeeded
```
Copy to Clipboard Toggle word wrap

21.8.3.2. ボンディングされた SR-IOV ネットワークでの sysctl の設定
リンクのコピー

2 つの SR-IOV インターフェイスから作成されたボンドインターフェイスで、インターフェイス固有の sysctl 設定を設定できます。これを行うには、bond ネットワーク接続定義のオプションの Plugins パラメーターにチューニング設定を追加します。

注記

SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

特定のインターフェイスレベルのネットワーク sysctl 設定を変更するには、次の手順を使用して、Container Network Interface (CNI) チューニングプラグインを使用して、SriovNetwork カスタムリソース (CR) を作成します。

前提条件

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

手順

次の例の CR のように、ボンドされたインターフェイスの SriovNetwork カスタムリソース (CR) を作成します。YAML を sriov-network-attachment.yaml ファイルとして保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
  namespace: openshift-sriov-network-operator 
spec:
  resourceName: policyallflags 
  networkNamespace: sysctl-tuning-test 
  capabilities: '{ "mac": true, "ips": true }' 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: allvalidflags 
```
1
```
  namespace: openshift-sriov-network-operator 
```
2
```
spec:
  resourceName: policyallflags 
```
3
```
  networkNamespace: sysctl-tuning-test 
```
4
```
  capabilities: '{ "mac": true, "ips": true }' 
```
5
Copy to Clipboard Toggle word wrap
1
オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
2
SR-IOV Network Operator がインストールされている namespace を指定します。
3
この追加ネットワークの SR-IOV ハードウェアを定義する SriovNetworkNodePolicy オブジェクトの spec.resourceName パラメーターの値。
4
SriovNetwork オブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。
5
オプション: この追加ネットワークに設定する機能。IP アドレスのサポートを有効にするには、"{ "ips": true }" を指定できます。または、MAC アドレスのサポートを有効にするには "{ "mac": true }" を指定します。
SriovNetwork リソースを作成します。
```
oc create -f sriov-network-attachment.yaml
```
```
$ oc create -f sriov-network-attachment.yaml
```
Copy to Clipboard Toggle word wrap

次の例の CR のように、ボンドネットワーク接続定義を作成します。YAML を sriov-bond-network-interface.yaml ファイルとして保存します。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond", 
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "links": [ 
        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{ 
        "type":"static"
      }
    },
    {
      "type":"tuning", 
      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bond-sysctl-network
  namespace: sysctl-tuning-test
spec:
  config: '{
  "cniVersion":"0.4.0",
  "name":"bound-net",
  "plugins":[
    {
      "type":"bond",

1


      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "links": [

5


        {"name": "net1"},
        {"name": "net2"}
      ],
      "ipam":{

6


        "type":"static"
      }
    },
    {
      "type":"tuning",

7


      "capabilities":{
        "mac":true
      },
      "sysctl":{
        "net.ipv4.conf.IFNAME.accept_redirects": "0",
        "net.ipv4.conf.IFNAME.accept_source_route": "0",
        "net.ipv4.conf.IFNAME.disable_policy": "1",
        "net.ipv4.conf.IFNAME.secure_redirects": "0",
        "net.ipv4.conf.IFNAME.send_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_redirects": "0",
        "net.ipv6.conf.IFNAME.accept_source_route": "1",
        "net.ipv6.neigh.IFNAME.base_reachable_time_ms": "20000",
        "net.ipv6.neigh.IFNAME.retrans_time_ms": "2000"
      }
    }
  ]
}'

Copy to Clipboard

Toggle word wrap

タイプはbondです。

mode 属性は、ボンドモードを指定します。サポートされているボンドモードは次のとおりです。

balance-rr - 0
active-backup - 1
balance-xor - 2
balance-rr または balance-xor モードの場合には、SR-IOV Virtual Function の trust モードを on に設定する必要があります。

failover 属性は、active-backup モードでは必須です。

4

linksInContainer=true フラグは、必要なインターフェイスがコンテナー内にあることをボンディング CNI に通知します。デフォルトでは、ボンディング CNI は、SRIOV および Multus との統合で機能しないホストで、このようなインターフェイスを検索します。

5

links セクションは、結合の作成に使用するインターフェイスを定義します。デフォルトでは、Multus は接続されたインターフェイスに net と 1 から始まる連続した番号の名前を付けます。

6

YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、割り当て定義についての IP アドレスの割り当てを管理します。この Pod の例では、IP アドレスは手動で設定されているため、この場合、ipam は static に設定されています。

7

デバイスに追加の機能を追加します。たとえば、type フィールドを tuning に設定します。設定したいインターフェイスレベルのネットワーク sysctl を sysctl フィールドに指定します。この例では、設定可能なすべてのインターフェイスレベルのネットワーク sysctl 設定を設定します。

ボンドネットワーク接続リソースを作成します。
```
oc create -f sriov-bond-network-interface.yaml
```
```
$ oc create -f sriov-bond-network-interface.yaml
```
Copy to Clipboard Toggle word wrap

NetworkAttachmentDefinition CR が正常に作成されることの確認

以下のコマンドを実行して、SR-IOV Network Operator が NetworkAttachmentDefinition CR を作成していることを確認します。
```
oc get network-attachment-definitions -n <namespace>
```
```
$ oc get network-attachment-definitions -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
<namespace> は、ネットワーク割り当ての設定時に指定した networkNamespace に置き換えます (例: sysctl-tuning-test)。
出力例
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
```
NAME                          AGE
bond-sysctl-network           22m
allvalidflags                 47m
```
Copy to Clipboard Toggle word wrap
注記
SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。

SR-IOV ネットワークリソースの追加が成功したことの確認

チューニング CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。

Pod CR を作成します。たとえば、次の YAML を examplepod.yaml ファイルとして保存します。

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"}, 
        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c", 
          "ips": ["10.100.100.200/24"] 
       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

apiVersion: v1
kind: Pod
metadata:
  name: tunepod
  namespace: sysctl-tuning-test
  annotations:
    k8s.v1.cni.cncf.io/networks: |-
      [
        {"name": "allvalidflags"},

1


        {"name": "allvalidflags"},
        {
          "name": "bond-sysctl-network",
          "interface": "bond0",
          "mac": "0a:56:0a:83:04:0c",

2


          "ips": ["10.100.100.200/24"]

3


       }
      ]
spec:
  containers:
  - name: podexample
    image: centos
    command: ["/bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

Copy to Clipboard

Toggle word wrap

1: SR-IOV ネットワーク割り当て定義 CR の名前。
2: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、SriovNetwork オブジェクトで { "mac": true } も指定する必要があります。
3: オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、SriovNetwork オブジェクトで { "ips": true } も指定する必要があります。

YAML を適用します。
```
oc apply -f examplepod.yaml
```
```
$ oc apply -f examplepod.yaml
```
Copy to Clipboard Toggle word wrap

次のコマンドを実行して、Pod が作成されていることを確認します。

oc get pod -n sysctl-tuning-test

$ oc get pod -n sysctl-tuning-test

Copy to Clipboard

Toggle word wrap

出力例

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

NAME      READY   STATUS    RESTARTS   AGE
tunepod   1/1     Running   0          47s

Copy to Clipboard

Toggle word wrap

次のコマンドを実行して、Pod にログインします。
```
oc rsh -n sysctl-tuning-test tunepod
```
```
$ oc rsh -n sysctl-tuning-test tunepod
```
Copy to Clipboard Toggle word wrap
設定された sysctl フラグの値を確認します。次のコマンドを実行して、net.ipv6.neigh.IFNAME.base_reachable_time_ms の値を見つけます。
```
sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
```
$ sysctl net.ipv6.neigh.bond0.base_reachable_time_ms
```
Copy to Clipboard Toggle word wrap
出力例
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
```
net.ipv6.neigh.bond0.base_reachable_time_ms = 20000
```
Copy to Clipboard Toggle word wrap

21.9. 高パフォーマンスのマルチキャストの使用
リンクのコピー

Single Root I/O Virtualization (SR-IOV) ハードウェアネットワーク上でマルチキャストを使用できます。

21.9.1. 高パフォーマンスのマルチキャスト
リンクのコピー

OpenShift SDN デフォルト Container Network Interface (CNI) ネットワークプロバイダーは、デフォルトネットワーク上の Pod 間のマルチキャストをサポートします。これは低帯域幅の調整またはサービスの検出での使用に最も適しており、高帯域幅のアプリケーションには適していません。インターネットプロトコルテレビ (IPTV) やマルチポイントビデオ会議など、ストリーミングメディアなどのアプリケーションでは、Single Root I/O Virtualization (SR-IOV) ハードウェアを使用してネイティブに近いパフォーマンスを提供できます。

マルチキャストに追加の SR-IOV インターフェイスを使用する場合:

マルチキャストパッケージは、追加の SR-IOV インターフェイス経由で Pod によって送受信される必要があります。
SR-IOV インターフェイスに接続する物理ネットワークは、OpenShift Container Platform で制御されないマルチキャストルーティングとトポロジーを判別します。

21.9.2. マルチキャストでの SR-IOV インターフェイスの設定
リンクのコピー

以下の手順では、サンプルのマルチキャスト用の SR-IOV インターフェイスを作成します。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin ロールを持つユーザーとしてクラスターにログインする必要があります。

手順

SriovNetworkNodePolicy オブジェクトを作成します。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-example
  namespace: openshift-sriov-network-operator
spec:
  resourceName: example
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "8086"
    pfNames: ['ens803f0']
    rootDevices: ['0000:86:00.0']

Copy to Clipboard

Toggle word wrap

SriovNetwork オブジェクトを作成します。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: | 
    {
      "type": "host-local", 
      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: net-example
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: default
  ipam: |

1


    {
      "type": "host-local",

2


      "subnet": "10.56.217.0/24",
      "rangeStart": "10.56.217.171",
      "rangeEnd": "10.56.217.181",
      "routes": [
        {"dst": "224.0.0.0/5"},
        {"dst": "232.0.0.0/5"}
      ],
      "gateway": "10.56.217.1"
    }
  resourceName: example

Copy to Clipboard

Toggle word wrap

1 2: DHCP を IPAM として設定する選択をした場合は、DHCP サーバー経由でデフォルトルート (224.0.0.0/5 および 232.0.0.0/5) をプロビジョニングするようにしてください。これにより、デフォルトのネットワークプロバイダーによって設定された静的なマルチキャストルートが上書きされます。

マルチキャストアプリケーションで Pod を作成します。

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"] 
    command: [ "sleep", "infinity"]

apiVersion: v1
kind: Pod
metadata:
  name: testpmd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: nic1
spec:
  containers:
  - name: example
    image: rhel7:latest
    securityContext:
      capabilities:
        add: ["NET_ADMIN"]

1


    command: [ "sleep", "infinity"]

Copy to Clipboard

Toggle word wrap

1: NET_ADMIN 機能は、アプリケーションがマルチキャスト IP アドレスを SR-IOV インターフェイスに割り当てる必要がある場合にのみ必要です。それ以外の場合は省略できます。

21.10. DPDK および RDMA の使用
リンクのコピー

コンテナー化された Data Plane Development Kit (DPDK) アプリケーションは OpenShift Container Platform でサポートされています。Single Root I/O Virtualization (SR-IOV) ネットワークハードウェアは、Data Plane Development Kit (DPDK) および Remote Direct Memory Access (RDMA) で利用できます。

対応しているデバイスの詳細は、Supported devices を参照してください。

21.10.1. NIC を使用した DPDK モードでの Virtual Function の使用
リンクのコピー

前提条件

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

手順

以下の SriovNetworkNodePolicy オブジェクトを作成してから、YAML を intel-dpdk-node-policy.yaml ファイルに保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: intel-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: intelnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "8086"
    deviceID: "158b"
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: vfio-pci 
```
1
Copy to Clipboard Toggle word wrap
1
Virtual Function (VF) のドライバータイプを vfio-pci に指定します。
注記
SriovNetworkNodePolicy の各オプションに関する詳細は、Configuring SR-IOV network devices セクションを参照してください。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。
設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。
以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f intel-dpdk-node-policy.yaml
```
```
$ oc create -f intel-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
以下の SriovNetwork オブジェクトを作成してから、YAML を intel-dpdk-network.yaml ファイルに保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
  vlan: <vlan>
  resourceName: intelnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: intel-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |-
# ... 
```
1
```
  vlan: <vlan>
  resourceName: intelnics
```
Copy to Clipboard Toggle word wrap
1
IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
注記
SriovNetwork の各オプションに関する詳細は、SR-IOV の追加ネットワークの設定セクションを参照してください。
オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して、SriovNetwork オブジェクトを作成します。
```
oc create -f intel-dpdk-network.yaml
```
```
$ oc create -f intel-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
以下の Pod 仕様を作成してから、YAML を intel-dpdk-pod.yaml ファイルに保存します。
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /mnt/huge 
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: intel-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /mnt/huge 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/intelnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/intelnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
SriovNetwork オブジェクトの intel-dpdk-network が作成される同じ target_namespace を指定します。Pod を異なる namespace に作成する場合、target_namespace を Pod 仕様および SriovNetwork オブジェクトの両方で変更します。
2
アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
3
hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
4
hugepage ボリュームを /mnt/huge の下の DPDK Pod にマウントします。hugepage ボリュームは、メディアが Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。
5
オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト SriovOperatorConfig CR で enableInjector オプションを false に設定して無効にすることができます。
6
CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを static に設定し、Guaranteed QoS を持つ Pod を作成して実行されます。
7
hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数 default_hugepagesz=1GB、hugepagesz=1G および hugepages=16 を追加すると、16*1Gi hugepage がシステムの起動時に割り当てられます。
以下のコマンドを実行して DPDK Pod を作成します。
```
oc create -f intel-dpdk-pod.yaml
```
```
$ oc create -f intel-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

21.10.2. Mellanox NIC を使用した DPDK モードでの Virtual Function の使用
リンクのコピー

Mellanox NIC で DPDK モードの Virtual Function を使用して、ネットワークノードポリシーを作成し、Data Plane Development Kit (DPDK) Pod を作成できます。

前提条件

OpenShift CLI (oc) がインストールされている。
Single Root I/O Virtualization (SR-IOV) Network Operator をインストールしている。
cluster-admin 権限を持つユーザーとしてログインしている。

手順

次の SriovNetworkNodePolicy YAML 設定を mlx-dpdk-node-policy.yaml ファイルに保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-dpdk-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
```
1
```
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
```
2
```
  isRdma: true 
```
3
Copy to Clipboard Toggle word wrap
1
SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。
2
Virtual Function (VF) のドライバータイプを netdevice に指定します。Mellanox SR-IOV Virtual Function (VF) は、vfio-pci デバイスタイプを使用せずに DPDK モードで機能します。VF デバイスは、コンテナー内のカーネルネットワークインターフェイスとして表示されます。
3
リモートダイレクトメモリーアクセス (RDMA) モードを有効にします。これは、DPDK モードで機能させるために Mellanox カードで必要です。
注記
SriovNetworkNodePolicy オブジェクトの各オプションの詳細な説明については SR-IOV ネットワークデバイスの設定 を参照してください。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分かかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。
設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。
以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f mlx-dpdk-node-policy.yaml
```
```
$ oc create -f mlx-dpdk-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
次の SriovNetwork YAML 設定を mlx-dpdk-network.yaml ファイルに保存します:
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-dpdk-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
IP アドレス管理 (IPAM) コンテナーネットワークインターフェイス (CNI) プラグインの設定オブジェクトを YAML ブロックスカラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
注記
SriovNetwork オブジェクトの各オプションの詳細な説明については SR-IOV ネットワークデバイスの設定 を参照してください。
app-netutil オプションライブラリーには、コンテナーの親 Pod に関するネットワーク情報を収集するための API メソッドが複数あります。
以下のコマンドを実行して、SriovNetwork オブジェクトを作成します。
```
oc create -f mlx-dpdk-network.yaml
```
```
$ oc create -f mlx-dpdk-network.yaml
```
Copy to Clipboard Toggle word wrap
次の Pod YAML 設定を mlx-dpdk-pod.yaml ファイルに保存します。
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /mnt/huge 
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
spec:
  containers:
  - name: testpmd
    image: <DPDK_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /mnt/huge 
```
4
```
      name: hugepage
    resources:
      limits:
        openshift.io/mlxnics: "1" 
```
5
```
        memory: "1Gi"
        cpu: "4" 
```
6
```
        hugepages-1Gi: "4Gi" 
```
7
```
      requests:
        openshift.io/mlxnics: "1"
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
SriovNetwork オブジェクトの mlx-dpdk-network が作成される同じ target_namespace を指定します。別の namespace で Pod を作成するには、Pod 仕様と SriovNetwork オブジェクトの両方で target_namespace を変更します。
2
アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
3
hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
4
hugepage ボリュームを /mnt/huge の下の DPDK Pod にマウントします。hugepage ボリュームは、メディアが Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。
5
オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト SriovOperatorConfig CR で enableInjector オプションを false に設定して無効にすることができます。
6
CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これを行うには、CPU マネージャーポリシーを static に設定し、サービス品質 (QoS) が Guaranteed の Pod を作成します。
7
hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して DPDK Pod を作成します。
```
oc create -f mlx-dpdk-pod.yaml
```
```
$ oc create -f mlx-dpdk-pod.yaml
```
Copy to Clipboard Toggle word wrap

21.10.3. 特定の DPDK ラインレート達成に関する概要
リンクのコピー

特定の Data Plane Development Kit (DPDK) ラインレートを実現するには、Node Tuning Operator をデプロイし、Single Root I/O Virtualization (SR-IOV) を設定します。次のリソースの DPDK 設定も調整する必要があります。

分離された CPU
hugepage
トポロジースケジューラー

注記

OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。

DPDK テスト環境

次の図は、トラフィックテスト環境のコンポーネントを示しています。

トラフィックジェネレーター: 大量のパケットトラフィックを生成できるアプリケーション。
SR-IOV 対応 NIC: SR-IOV に対応したネットワークインターフェイスカードです。カードは、物理インターフェイス上で多数の Virtual Function を実行します。
Physical Function (PF): SR-IOV インターフェイスをサポートするネットワークアダプターの PCI Express (PCIe) 機能。
Virtual Function (VF): SR-IOV をサポートするネットワークアダプター上の軽量の PCIe 機能。VF は、ネットワークアダプターの PCIe PF に関連付けられています。VF は、ネットワークアダプターの仮想化されたインスタンスを表します。
スイッチ: ネットワークスイッチ。ノードは中断なしに接続することもできます。
testpmd: DPDK に含まれるサンプルアプリケーション。testpmd アプリケーションを使用して、パケット転送モードで DPDK をテストできます。testpmd アプリケーションは、DPDK ソフトウェア開発キット (SDK) を使用して本格的なアプリケーションを構築する方法の例でもあります。
worker 0 および worker 1: OpenShift Container Platform ノード。

21.10.4. SR-IOV と Node Tuning Operator を使用した DPDK ラインレートの実現
リンクのコピー

Node Tuning Operator を使用して、分離された CPU、ヒュージページ、およびトポロジースケジューラーを設定できます。その後、Node Tuning Operator と Single Root I/O Virtualization (SR-IOV) を使用して、特定の Data Plane Development Kit (DPDK) ラインレートを実現できます。

前提条件

OpenShift CLI (oc) がインストールされている。
SR-IOV Network Operator がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。
スタンドアロン Node Tuning Operator をデプロイしている。
注記
OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。

手順

次の例に基づいて PerformanceProfile オブジェクトを作成します。
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
    reserved: 0-20,52-72 
  hugepages:
    defaultHugepagesSize: 1G 
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
```
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  globallyDisableIrqLoadBalancing: true
  cpu:
    isolated: 21-51,73-103 
```
1
```
    reserved: 0-20,52-72 
```
2
```
  hugepages:
    defaultHugepagesSize: 1G 
```
3
```
    pages:
      - count: 32
        size: 1G
  net:
    userLevelNetworking: true
  numa:
    topologyPolicy: "single-numa-node"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
```
Copy to Clipboard Toggle word wrap
1
システムでハイパースレッディングが有効になっている場合は、関連するシンボリックリンクを isolated および reserved の CPU グループに割り当てます。システムに複数の Non-Uniform Memory Access (NUMA) ノードが含まれている場合は、両方の NUMA から両方のグループに CPU を割り当てます。このタスクには Performance Profile Creator を使用することもできます。詳細は、コントロールプレーンプロファイルの作成 について参照してください。
2
キューが予約済みの CPU 数に設定されているデバイスのリストを指定することもできます。詳細については Node Tuning Operator を使用した NIC キューの削減 を参照してください。
3
必要なヒュージページの数とサイズを割り当てます。ヒュージページの NUMA 設定を指定できます。デフォルトでは、システムは、そのシステムにあるすべての NUMA ノードに偶数分を割り当てます。必要に応じて、ノードのリアルタイムカーネルの使用をリクエストできます。詳しくは、 リアルタイム機能を備えたワーカーのプロビジョニング を参照してください。
yaml ファイルを mlx-dpdk-perfprofile-policy.yaml として保存します。
次のコマンドを使用して、パフォーマンスプロファイルを適用します。
```
oc create -f mlx-dpdk-perfprofile-policy.yaml
```
```
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
```
Copy to Clipboard Toggle word wrap

21.10.4.1. Virtual Function の SR-IOV Network Operator の例
リンクのコピー

Single Root I/O Virtualization (SR-IOV) ネットワーク Operator を使用して、ノード上の SR-IOV をサポートする Physical Function NIC から Virtual Function (VF) を割り当てて設定できます。

Operator のデプロイの詳細については、SR-IOV Network Operator のインストール を参照してください。SR-IOV ネットワークデバイスの設定の詳細については、SR-IOV ネットワークデバイスの設定 を参照してください。

Intel VF と Mellanox VF での Data Plane Development Kit (DPDK) ワークロードの実行にはいくつかの違いがあります。このセクションでは、両方の VF タイプのオブジェクト設定の例を示します。以下は、Intel NIC で DPDK アプリケーションを実行するために使用される sriovNetworkNodePolicy オブジェクトの例です。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci 
  needVhostNet: true 
  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci

1


  needVhostNet: true

2


  nicSelector:
    pfNames: ["ens3f0"]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  needVhostNet: true
  nicSelector:
    pfNames: ["ens3f1"]
  nodeSelector:
  node-role.kubernetes.io/worker-cnf: ""
  numVfs: 10
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Intel NIC の場合、deviceType は vfio-pci である必要があります。
2: DPDK ワークロードとのカーネル通信が必要な場合は、needVhostNet: true を追加します。これにより、/dev/net/tun および /dev/vhost-net デバイスがコンテナーにマウントされ、アプリケーションがタップデバイスを作成し、タップデバイスを DPDK ワークロードに接続できるようになります。

以下は、Mellanox NIC の sriovNetworkNodePolicy オブジェクトの例です。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice 
  isRdma: true 
  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-1
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice

1


  isRdma: true

2


  nicSelector:
    rootDevices:
      - "0000:5e:00.1"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: dpdk-nic-2
  namespace: openshift-sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  nicSelector:
    rootDevices:
      - "0000:5e:00.0"
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numVfs: 5
  priority: 99
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Mellanox デバイスの場合、deviceType は netdevice である必要があります。
2: Mellanox デバイスの場合、isRdma は true である必要があります。Mellanox カードは、Flow Bifurcation を使用して DPDK アプリケーションに接続されます。このメカニズムは、Linux ユーザー空間とカーネル空間の間でトラフィックを分割し、ラインレートの処理能力を高めることができます。

21.10.4.2. SR-IOV ネットワーク Operator の例
リンクのコピー

以下は、sriovNetwork オブジェクトの定義例です。この場合、Intel と Mellanox の設定は同じです。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}' 
  networkNamespace: dpdk-test 
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1 
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-1
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'

1


  networkNamespace: dpdk-test

2


  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_1

3


---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: dpdk-network-2
  namespace: openshift-sriov-network-operator
spec:
  ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
   "/run/my-orchestrator/container-ipam-state-1"}'
  networkNamespace: dpdk-test
  spoofChk: "off"
  trust: "on"
  resourceName: dpdk_nic_2

Copy to Clipboard

Toggle word wrap

1: Whereabouts など、別の IP Address Management (IPAM) 実装を使用できます。詳細については Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。
2: ネットワーク接続定義が作成される networkNamespace を要求する必要があります。openshift-sriov-network-operator namespace で sriovNetwork CR を作成する必要があります。
3: resourceName の値は、sriovNetworkNodePolicy で作成された resourceName の値と一致する必要があります。

21.10.4.3. DPDK ベースワークロードの例
リンクのコピー

以下は、Data Plane Development Kit (DPDK) コンテナーの例です。

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[ 
     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable" 
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance 
  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources: 
        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

apiVersion: v1
kind: Namespace
metadata:
  name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[

1


     {
      "name": "dpdk-network-1",
      "namespace": "dpdk-test"
     },
     {
      "name": "dpdk-network-2",
      "namespace": "dpdk-test"
     }
   ]'
    irq-load-balancing.crio.io: "disable"

2


    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
  labels:
    app: dpdk
  name: testpmd
  namespace: dpdk-test
spec:
  runtimeClassName: performance-performance

3


  containers:
    - command:
        - /bin/bash
        - -c
        - sleep INF
      image: registry.redhat.io/openshift4/dpdk-base-rhel8
      imagePullPolicy: Always
      name: dpdk
      resources:

4


        limits:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
        requests:
          cpu: "16"
          hugepages-1Gi: 8Gi
          memory: 2Gi
      securityContext:
        capabilities:
          add:
            - IPC_LOCK
            - SYS_RESOURCE
            - NET_RAW
            - NET_ADMIN
        runAsUser: 0
      volumeMounts:
        - mountPath: /mnt/huge
          name: hugepages
  terminationGracePeriodSeconds: 5
  volumes:
    - emptyDir:
        medium: HugePages
      name: hugepages

Copy to Clipboard

Toggle word wrap

1: 必要な SR-IOV ネットワークをリクエストします。デバイスのリソースは自動挿入されます。
2: CPU と IRQ 負荷分散ベースを無効にします。詳しくは 個々の Pod の割り込み処理の無効化 を参照してください。
3: runtimeClass は performance-performance に設定します。runtimeClass は HostNetwork または privileged に設定しないでください。
4: サービスの品質 (QoS) が Guaranteed さの Pod を開始するには、要求と制限に対して同じ数のリソースを要求します。

注記

SLEEP 状態の Pod を起動し、その Pod で exec 操作を実行して testpmd または DPDK ワークロードを開始しないでください。これにより、exec プロセスがどの CPU にも固定されていないため、割り込みが追加される可能性があります。

21.10.4.4. testpmd スクリプトの例
リンクのコピー

以下は、testpmd を実行するスクリプトの例です。

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}

dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02

Copy to Clipboard

Toggle word wrap

この例では、2 つの異なる sriovNetwork CR を使用しています。環境変数には、Pod に割り当てられた Virtual Function (VF) PCI アドレスが含まれています。Pod 定義で同じネットワークを使用する場合は、pciAddress を分割する必要があります。トラフィックジェネレータの正しい MAC アドレスを設定することが重要です。この例では、カスタム MAC アドレスを使用しています。

21.10.5. Mellanox NIC を使用した RDMA モードでの Virtual Function の使用
リンクのコピー

重要

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

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

RoCE (RDMA over Converged Ethernet) は、OpenShift Container Platform で RDMA を使用する場合に唯一サポートされているモードです。

前提条件

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

手順

以下の SriovNetworkNodePolicy オブジェクトを作成してから、YAML を mlx-rdma-node-policy.yaml ファイルに保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
  isRdma: true 
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlx-rdma-node-policy
  namespace: openshift-sriov-network-operator
spec:
  resourceName: mlxnics
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  priority: <priority>
  numVfs: <num>
  nicSelector:
    vendor: "15b3"
    deviceID: "1015" 
```
1
```
    pfNames: ["<pf_name>", ...]
    rootDevices: ["<pci_bus_id>", "..."]
  deviceType: netdevice 
```
2
```
  isRdma: true 
```
3
Copy to Clipboard Toggle word wrap
1
SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。
2
Virtual Function (VF) のドライバータイプを netdevice に指定します。
3
RDMA モードを有効にします。
注記
SriovNetworkNodePolicy の各オプションに関する詳細は、Configuring SR-IOV network devices セクションを参照してください。
SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。
設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。
以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f mlx-rdma-node-policy.yaml
```
```
$ oc create -f mlx-rdma-node-policy.yaml
```
Copy to Clipboard Toggle word wrap
以下の SriovNetwork オブジェクトを作成してから、YAML を mlx-rdma-network.yaml ファイルに保存します。
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
```
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: mlx-rdma-network
  namespace: openshift-sriov-network-operator
spec:
  networkNamespace: <target_namespace>
  ipam: |- 
```
1
```
# ...
  vlan: <vlan>
  resourceName: mlxnics
```
Copy to Clipboard Toggle word wrap
1
IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。
注記
SriovNetwork の各オプションに関する詳細は、SR-IOV の追加ネットワークの設定セクションを参照してください。
オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。
```
oc create -f mlx-rdma-network.yaml
```
```
$ oc create -f mlx-rdma-network.yaml
```
Copy to Clipboard Toggle word wrap
以下の Pod 仕様を作成してから、YAML を mlx-rdma-pod.yaml ファイルに保存します。
```
apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace> 
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image> 
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
    volumeMounts:
    - mountPath: /mnt/huge 
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4" 
        hugepages-1Gi: "4Gi" 
      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
```
apiVersion: v1
kind: Pod
metadata:
  name: rdma-app
  namespace: <target_namespace> 
```
1
```
  annotations:
    k8s.v1.cni.cncf.io/networks: mlx-rdma-network
spec:
  containers:
  - name: testpmd
    image: <RDMA_image> 
```
2
```
    securityContext:
      runAsUser: 0
      capabilities:
        add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 
```
3
```
    volumeMounts:
    - mountPath: /mnt/huge 
```
4
```
      name: hugepage
    resources:
      limits:
        memory: "1Gi"
        cpu: "4" 
```
5
```
        hugepages-1Gi: "4Gi" 
```
6
```
      requests:
        memory: "1Gi"
        cpu: "4"
        hugepages-1Gi: "4Gi"
    command: ["sleep", "infinity"]
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
```
Copy to Clipboard Toggle word wrap
1
SriovNetwork オブジェクトの mlx-rdma-network が作成される同じ target_namespace を指定します。Pod を異なる namespace に作成する場合は、target_namespace を Pod 仕様および SriovNetwork オブジェクトの両方で変更します。
2
アプリケーションとアプリケーションが使用する RDMA ライブラリーが含まれる RDMA イメージを指定します。
3
hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
4
hugepage ボリュームを /mnt/huge の下の RDMA Pod にマウントします。hugepage ボリュームは、メディアが Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。
5
CPU の数を指定します。RDMA Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを static に設定し、Guaranteed QoS を持つ Pod を作成して実行されます。
6
hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、RDMA Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して RDMA Pod を作成します。
```
oc create -f mlx-rdma-pod.yaml
```
```
$ oc create -f mlx-rdma-pod.yaml
```
Copy to Clipboard Toggle word wrap

21.10.6. OpenStack で OVS-DPDK を使用するクラスター用のテスト Pod テンプレート
リンクのコピー

次の testpmd Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。

testpmd Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1 
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile 
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-dpdk
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/dpdk1: 1

1


      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/dpdk1: 1
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile

2


  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: この例の dpdk1 という名前は、ユーザーが作成した SriovNetworkNodePolicy リソースです。この名前は、作成したリソースの名前に置き換えることができます。
2: パフォーマンスプロファイルの名前が cnf-performance profile でない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。

21.10.7. OpenStack で OVS ハードウェアオフロードを使用するクラスター用のテスト Pod テンプレート
リンクのコピー

次の testpmd Pod は、Red Hat OpenStack Platform (RHOSP) での Open vSwitch (OVS) ハードウェアオフロードを示しています。

testpmd Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile 
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile

1


  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Copy to Clipboard

Toggle word wrap

1: パフォーマンスプロファイルの名前が cnf-performance profile でない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。

21.11. Pod レベルのボンディングの使用
リンクのコピー

Pod レベルでのボンディングは、高可用性とスループットを必要とする Pod 内のワークロードを有効にするために不可欠です。Pod レベルのボンディングでは、カーネルモードインターフェイスで複数の Single Root I/O Virtualization (SR-IOV) Virtual Function インターフェイスからボンドインターフェイスを作成できます。SR-IOV Virtual Function は Pod に渡され、カーネルドライバーに割り当てられます。

Pod レベルのボンディングが必要なシナリオには、異なる Physical Function 上の複数の SR-IOV Virtual Function からのボンディングインターフェイスの作成が含まれます。ホストの 2 つの異なる Physical Function からボンディングインターフェイスを作成して、Pod レベルで高可用性およびスループットを実現するために使用できます。

SR-IOV ネットワークの作成、ネットワークポリシー、ネットワーク接続定義、Pod などのタスクのガイダンスはSR-IOV ネットワークデバイスの設定を参照してください。

21.11.1. 2 つの SR-IOV インターフェイスからのボンドインターフェイスの設定
リンクのコピー

ボンディングを使用して、複数のネットワークインターフェイスを、1 つの論理的なボンディングされたインターフェイスに集約できます。Bond Container Network Interface (Bond-CNI) により、コンテナーでボンディング機能を使用できます。

Bond-CNI は、Single Root I/O Virtualization (SR-IOV) Virtual Function を使用して作成し、それらをコンテナーネットワーク namespace に配置できます。

OpenShift Container Platform は、SR-IOV Virtual Functions を使用する Bond-CNI のみをサポートします。SR-IOV Network Operator は、Virtual Function の管理に必要な SR-IOV CNI プラグインを提供します。他の CNI またはインターフェイスのタイプはサポートされていません。

前提条件

SR-IOV Network Operator をインストールおよび設定して、コンテナー内の Virtual Functions を取得する必要があります。
SR-IOV インターフェイスを設定するには、インターフェイスごとに SR-IOV ネットワークとポリシーを作成する必要があります。
SR-IOV Network Operator は、定義された SR-IOV ネットワークとポリシーをもとに、各 SR-IOV インターフェイスのネットワーク接続定義を作成します。
linkState は、SR-IOV Virtual Function のデフォルト値 auto に設定されます。

21.11.1.1. ボンドネットワーク接続定義の作成
リンクのコピー

SR-IOV Virtual Function が使用可能になったので、ボンドネットワーク接続定義を作成できます。

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond", 
      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup", 
      "failOverMac": 1, 
      "linksInContainer": true, 
      "miimon": "100",
      "mtu": 1500,
      "links": [ 
            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: bond-net1
      namespace: demo
    spec:
      config: '{
      "type": "bond",

1


      "cniVersion": "0.3.1",
      "name": "bond-net1",
      "mode": "active-backup",

2


      "failOverMac": 1,

3


      "linksInContainer": true,

4


      "miimon": "100",
      "mtu": 1500,
      "links": [

5


            {"name": "net1"},
            {"name": "net2"}
        ],
      "ipam": {
            "type": "host-local",
            "subnet": "10.56.217.0/24",
            "routes": [{
            "dst": "0.0.0.0/0"
            }],
            "gateway": "10.56.217.1"
        }
      }'

Copy to Clipboard

Toggle word wrap

cni-type は常に bond に設定されます。

mode 属性は、ボンドモードを指定します。

注記

サポートされているボンドモードは次のとおりです。

balance-rr - 0
active-backup - 1
balance-xor - 2

balance-rr または balance-xor モードの場合には、SR-IOV Virtual Function の trust モードを on に設定する必要があります。