OpenShift導入用のクラウドネイティブルーターのHelmチャートのカスタマイズ

trueに設定すると、インストール中にCloud-Native Routerの準備状況のプリフライトチェックとポストフライトチェックが有効になります。これをコメントアウトするか、falseに設定して、Cloud-Native Routerの準備状況のプリフライトチェックとポストフライトチェックを無効にします。

プリフライトチェックでは、インフラストラクチャがJCNRをサポートできることを確認します。プリフライトチェックは、Cloud-Native Routerをインストールする前に行われます。

ポストフライトチェックでは、Cloud-Native Routerのインストールが正しく動作していることを確認します。事後チェックは、Cloud-Native Routerのインストール後に行われます。

クラウドネイティブルーターの準備状況チェックを参照してください。

複数のインターフェイスからトラフィックを受信する集約されたインターフェイス。ファブリックインターフェイスは常に物理インターフェイスです。これらは、物理機能(PF)または仮想機能(VF)のいずれかです。これらのインターフェイスのスループット要件が高くなるため、複数のハードウェアキューが割り当てられます。各ハードウェア キューには専用の CPU コアが割り当てられます。詳細については、 クラウドネイティブルーターインターフェイス の概要を参照してください。

このフィールドは、DPDKにバインドされるファブリックインターフェイスのリストを提供するために使用します。インターフェイス名の代わりにサブネットを指定することもできます。インターフェイス名とサブネットの両方が指定されている場合、インターフェイス名がサブネット/ゲートウェイの組み合わせよりも優先されます。サブネットとゲートウェイの組み合わせは、マルチノードクラスターでインターフェイス名が異なる場合に便利です。

次に例を示します。

  # L2 only
  - eth1:
      ddp: "auto"                
      interface_mode: trunk
      vlan-id-list: [100, 200, 300, 700-705]
      native-vlan-id: 100

  # L3  only
  - eth1:
      ddp: "off"                                 

 # L2L3
  - eth1:
      ddp: "auto"                
  - eth2:
      ddp: "auto"                
      interface_mode: trunk
      vlan-id-list: [100, 200, 300, 700-705]
      native-vlan-id: 100

- subnet: 10.40.1.0/24 
  gateway: 10.40.1.1 
  ddp: "off"    

subnetオプションは、L3インターフェイスにのみ適用できます。入力のsubnetモードでは、各サブネットでインターフェイスが自動検出されます。サブネット/ゲートウェイまたはインターフェイス名を指定します。両方を設定しないでください。サブネット/ゲートウェイ形式の入力は、マルチノードクラスターでインターフェイス名が異なる環境で特に役立ちます。

(オプション)インターフェイスレベルの動的デバイスパーソナライゼーション(DDP)設定を示します。DDPは、GTPU、SCTPなどのトラフィックに対してNICでデータパス最適化を提供します。ボンディングインターフェイスの場合、DDP設定を有効にするには、すべてのスレーブインターフェイスNICがDDPをサポートしている必要があります。詳細については、「 個々のインターフェイスでの動的デバイスパーソナライゼーション(DDP)の有効化 」を参照してください。

オプションには、自動、オン、オフなどがあります。デフォルトはオフです。

L2インターフェイス用に trunk に設定し、L3インターフェイス用には設定 しません 。例えば、

interface_mode: trunk

インターフェイスに関連付けられたVLAN IDのリストを指定します。

vlan-id-list内の任意のVLAN IDでnative-vlan-idを設定し、ファブリックトランクモードインターフェイスの物理インターフェイスで受信したタグなしデータパケットに関連付けます。次に例を示します。

fabricInterface: 
  - bond0: 
      interface_mode: trunk 
      vlan-id-list: [100, 200, 300]  
      native-vlan-id: 100  

詳細については 、「ネイティブVLAN」 を参照してください。

このインターフェイスに適用可能な QoS スケジューラ プロファイルを指定します。 qosSchedulerProfiles セクションを参照してください。

プロファイルを指定しない場合、このインターフェイスの QoS スケジューラは無効になり、パケットはトラフィック クラスに関係なくスケジューリングされます。

定義されたディレクトリには、 contrail-vrouter-agent.log、 contrail-vrouter-dpdk.logなど、さまざまなJCNR関連の記述ログが格納されます。デフォルトは /var/log/jcnr/ です。

生成された通知をJSON形式で保存するファイルへの絶対パス syslog-ng 示します。デフォルトは /var/log/jcnr/jcnr_notifications.json です。

コアファイルの core_pattern を示します。空白のままにすると、Cloud-Native Routerポッドはホスト上のデフォルトパターンを上書きしません。

(オプション)ノードのラベルを定義して、vRouterポッドの配置場所を決定します。

デフォルトでは、vRouterポッドはクラスターのすべてのノードにデプロイされます。

以下の例では、ノード アフィニティ ラベルは key1=jcnr として定義されています。このラベルは、Cloud-Native Routerを導入する各ノードに適用する必要があります。

nodeAffinity:
- key: key1
operator: In
values:
- jcnr

OCP設定では、ワーカーノードでのみCloud-Native Routerを起動するようにノードアフィニティを設定する必要があります。次に例を示します。

  nodeAffinity:
  - key: node-role.kubernetes.io/worker
    operator: Exists
  - key: node-role.kubernetes.io/master
    operator: DoesNotExist

(オプション)JCNR ポッドを特定のテイントを持つノードに配置できる容認を定義します。

以下の例では、公差は jcnr=yesとして定義されています。つまり、ノードが jcnr=yes で汚染されている場合、またはまったく汚染されていない場合、そのノードでJCNRポッドをスケジュールできます。ノードが別のキーと値のペアで汚染されている場合、JCNR ポッドをそのノードでスケジュールすることはできません(効果によって異なります)。

tolerations:
  - key: "jcnr"
    operator: "Equal"
    value: "yes"
    effect: "NoSchedule"

(オプション)このパラメーターの値を入力して、cRPDテレメトリgRPCサーバーのデフォルトポート50053を上書きします。

存在する場合、これは静的なCPU割り当てを使用して、転送プレーンにコアを割り当てることを示しています。

この値は、転送プレーンに静的に割り当てる分離されたCPUコアのカンマ区切りのリストである必要があります(例: cpu_core_mask: "2,3,22,23")。ホストOSで使用されていないコアを使用します。

Kubernetes CPUマネージャーを使用してコアを転送プレーンに割り当てる場合は、コメントアウトしてください。

存在する場合、これは、Kubernetes CPU マネージャーまたは Nokia CPU プーラー(シングルポッド導入のみ)を使用して、CPU コアを転送プレーンに割り当てることを示しています。

この値は、Kubernetes CPU Manager が転送プレーンに割り当てる保証された CPU コアの数である必要があります。この値は、転送コアの数より少なくとも1つ多く設定する必要があります。

静的なCPU割り当てを使用して転送プレーンにコアを割り当てたい場合は、これをコメントアウトしてください。

静的CPU割り当てを使用する場合に、vRouter DPDK制御スレッドに割り当てるCPUコアを指定します。このリストは、 cpu_core_mask に記載されているコアとは異なり、 serviceCoreMaskのリストと同じにすることができます。

Kubernetes CPUマネージャーを使用してコアを転送プレーンに割り当てる場合は、コメントアウトしてください。

静的CPU割り当てを使用する場合に、vRouter DPDKサービススレッドに割り当てるCPUコアを指定します。このリストは、 cpu_core_mask に記載されているコアとは異なり、 dpdkCtrlThreadMaskのリストと同じにすることができます。

Kubernetes CPUマネージャーを使用してコアを転送プレーンに割り当てる場合は、コメントアウトしてください。

Kubernetes CPUマネージャーを使用するときに、vRouter DPDKサービス/制御トラフィックに割り当てるCPUコア数を指定します。

この数は、 guaranteedVrouterCpus コアの数よりも小さくする必要があります。残りの guaranteedVrouterCpus コアは転送用に割り当てられます。

静的なCPU割り当てを使用して転送プレーンにコアを割り当てたい場合は、これをコメントアウトしてください。

(オプション)ボンディングのプライマリインターフェイス。

slaveNetworkの詳細

追加のDPDKコマンドラインパラメーターを渡します。この --yield_option 0 はデフォルトで設定されており、DPDK転送コアが割り当てられたCPUコアを生成しないことを意味します。追加できるその他の一般的なパラメーターには、 tx 記述子と rx 記述子と mempoolがあります。次に例を示します。

dpdkCommandAdditionalArgs: "--yield_option 0 --dpdk_txd_sz 2048 --dpdk_rxd_sz 2048 --vr_mempool_sz 131072"

(オプション)グローバルな動的デバイスパーソナライゼーション(DDP)設定を示します。DDPは、GTPU、SCTPなどのトラフィックに対してNICでデータパス最適化を提供します。ボンディングインターフェイスの場合、DDP設定を有効にするには、すべてのスレーブインターフェイスNICがDDPをサポートしている必要があります。詳細については、「 個々のインターフェイスでの動的デバイスパーソナライゼーション(DDP)の有効化 」を参照してください。

オプションには、自動、オン、オフなどがあります。デフォルトはオフです。

(オプション)TWAMP セッション リフレクタ ポート(TWAMP セッションで vRouter タイムスタンプを使用する場合)。vRouterは、このポートでTWAMPテストメッセージをリッスンし、TWAMPテストメッセージにタイムスタンプを挿入/上書きします。(cRPD ではなく)vRouter で TWAMP メッセージをタイムスタンプすると、より正確な測定が可能になります。有効な値は、862 と 49152 から 65535 です。

このパラメータがない場合、vRouterはTWAMPセッションにタイムスタンプを挿入または上書きしません。タイムスタンプは、代わりにcRPDによって取得され、挿入されます。

TWAMP (Two-Way Active Measurement Protocol)を参照してください。

dpdkに設定します。

(オプション)cRPD テレメトリ設定を構成します。テレメトリの詳細については、「 テレメトリ機能」 を参照してください。

true に設定すると、cRPD テレメトリが無効になります。デフォルトはfalseで、cRPDテレメトリがデフォルトで有効になっていることを意味します。

cRPDテレメトリエクスポーターがPrometheusクエリーをリッスンしているポート。デフォルトは 8072 です。

warn、warning、info、debug、trace、verbose のいずれかです。デフォルトはinfoです。

(オプション)cRPD gNMI設定を構成します。

(オプション)vRouterのテレメトリ設定を構成します。テレメトリの詳細については、「 テレメトリ機能」 を参照してください。

終了GracePeriodSeconds