Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.3. RHOSO 上の BGP ネットワーク用に RHOCP を準備する

Red Hat OpenStack Services on OpenShift (RHOSO) サービスは、Red Hat OpenShift Container Platform (RHOCP) のワークロードとして実行されます。NMState Operator を使用して、必要な分離ネットワークにワーカーノードを接続します。MetalLB Operator を使用して、分離ネットワーク上の内部サービスエンドポイントを公開します。デフォルトでは、パブリックサービスエンドポイントは RHOCP ルートとして公開されます。

注記

次の手順の例では、IPv4 アドレスを使用します。IPv4 アドレスの代わりに IPv6 アドレスを使用できます。デュアルスタック(IPv4 および IPv6)は、プロジェクト（テナント）ネットワークでのみ使用できます。IPv6 アドレスの設定方法は、RHOCP ネットワーク ガイドの次のリソースを参照してください。

4.3.1. RHOCP ノードの BGP インターフェイスで rcp_filter を無効にする
リンクのコピー

Red Hat OpenShift Container Platform (RHOCP) ワーカーノードが受信した BGP アドバタイズメントに基づいてトラフィックを転送するには、RHOSO サービスを実行する RHOCP ワーカーノードの BGP インターフェイスでリバースパスフィルターを無効にする必要があります。

手順

  1. 次のような内容で、名前が tuned.yaml のマニフェストファイルを作成します。 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/ocp-tuned/provider},openshift

      [sysctl]
      net.ipv4.conf.enp8s0.rp_filter=0
      net.ipv4.conf.enp9s0.rp_filter=0
    name: openshift
  recommend:
  - match:
    - label: kubernetes.io/hostname
      value: worker-0
    - label: kubernetes.io/hostname
      value: worker-1
    - label: kubernetes.io/hostname
      value: worker-2
    - label: node-role.kubernetes.io/master
    operand:
      tunedConfig:
        reapply_sysctl: false
    priority: 15
    profile: openshift-no-reapply-sysctl
status: {}

  2. ファイルを保存し、Tuned リソースを作成します。 

    $ oc create -f tuned.yaml

4.3.2. BGP 用の分離されたネットワークインターフェイスを備えた RHOCP の準備
リンクのコピー

NodeNetworkConfigurationPolicy (nncp) カスタムリソース (CR) を作成し、Red Hat OpenShift Container Platform (RHOCP) クラスター内にある各ワーカーノードの各分離ネットワークのインターフェイスを設定します。

手順

  1. ワークステーションに NodeNetworkConfigurationPolicy (nncp) CR ファイル (例: openstack-nncp-bgp.yaml) を作成します。

  2. RHOCP クラスター内のワーカーノードの名前を取得します。 

    $ oc get nodes -l node-role.kubernetes.io/worker -o jsonpath="{.items[*].metadata.name}"

  3. ネットワーク設定を確認します。 

    $ oc get nns/<worker_node> -o yaml | more
    • <worker_node> は、手順 2 で取得したワーカーノードの名前 (例: worker-1) に置き換えます。各ワーカーノードに対してこの手順を繰り返します。

  4. nncp CR ファイルで、RHOCP クラスター内の各ワーカーノードの分離ネットワークそれぞれのインターフェイスを設定します。ネットワーク分離を設定する必要があるデフォルトの物理データセンターネットワークの詳細は、BGP 用のデフォルトの Red Hat OpenStack Services on OpenShift ネットワーク を参照してください。

    次の例では、nncp CR が Red Hat OpenStack Services on OpenShift (RHOSO) ネットワークをマッピングするために使用する複数の未接続ブリッジを設定します。BGP インターフェイスを使用してネットワークファブリックとピアリングし、接続を確立します。ループバックインターフェイスは、BGP ネットワークソースアドレス (99.99.0.x) で設定されます。必要に応じて、NIC を ctlplane ネットワーク専用にできます。 

    apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  labels:
    osp/nncm-config-type: standard
  name: worker-0
  namespace: openstack
spec:
  desiredState:
    dns-resolver:
      config:
        search: []
        server:
        - 192.168.122.1
    interfaces:
    - description: internalapi bridge
      mtu: 1500
      name: internalapi
      state: up
      type: linux-bridge
    - description: storage bridge
      mtu: 1500
      name: storage
      state: up
      type: linux-bridge
    - description: tenant bridge
      mtu: 1500
      name: tenant
      state: up
      type: linux-bridge
    - description: ctlplane bridge
      mtu: 1500
      name: ospbr
      state: up
      type: linux-bridge
    - description: BGP interface 1
      ipv4:
        address:
        - ip: 100.64.0.14
          prefix-length: "30"
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      mtu: 1500
      name: enp8s0
      state: up
      type: ethernet
    - description: BGP interface 2
      ipv4:
        address:
        - ip: 100.65.0.14
          prefix-length: "30"
        dhcp: false
        enabled: true
      ipv6:
        enabled: false
      mtu: 1500
      name: enp9s0
      state: up
      type: ethernet
    - description: loopback interface
      ipv4:
        address:
        - ip: 99.99.0.3
          prefix-length: "32"
        dhcp: false
        enabled: true
      mtu: 65536
      name: lo
      state: up
    route-rules:
      config: []
    routes:
      config:
      - destination: 99.99.0.0/16
        next-hop-address: 100.64.0.13
        next-hop-interface: enp8s0
      - destination: 99.99.0.0/16
        next-hop-address: 100.65.0.13
        next-hop-interface: enp9s0
  nodeSelector:
    kubernetes.io/hostname: worker-0
    node-role.kubernetes.io/worker: ""

  5. クラスターに nncp CR を作成します。 

    $ oc apply -f openstack-nncp-bgp.yaml

  6. nncp CR が作成されたことを確認します。 

    $ oc get nncp -w
NAME                        STATUS        REASON
osp-enp6s0-worker-1   Progressing   ConfigurationProgressing
osp-enp6s0-worker-1   Progressing   ConfigurationProgressing
osp-enp6s0-worker-1   Available     SuccessfullyConfigured

4.3.3. BGP 用の分離されたネットワークにサービス Pod を接続する
リンクのコピー

サービス Pod をネットワークに接続するために、分離されたネットワークごとに NetworkAttachmentDefinition (net-attach-def) カスタムリソース (CR) を作成します。

手順

  1. ワークステーションに NetworkAttachmentDefinition (net-attach-def) CR ファイル (例: openstack-net-attach-def.yaml) を作成します。

  2. NetworkAttachmentDefinition CR ファイルで、各分離ネットワークの NetworkAttachmentDefinition リソースを設定して、サービスデプロイメント Pod をネットワークに割り当てます。次の例では、特定のゲートウェイ設定と追加オプションを持つタイプブリッジインターフェイスを使用する NetworkAttachmentDefinition リソースを作成します。 

    apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  labels:
    osp/net: internalapi
    osp/net-attach-def-type: standard
  name: internalapi
  namespace: openstack
spec:
  config: |
	{
  	"cniVersion": "0.3.1",
  	"name": "internalapi",
  	"type": "bridge",
  	"isDefaultGateway": true,
  	"isGateway": true,
  	"forceAddress": false,
  	"ipMasq": true,
  	"hairpinMode": true,
  	"bridge": "internalapi",
  	"ipam": {
      "type": "whereabouts",
      "range": "172.17.0.0/24",
      "range_start": "172.17.0.30",
      "range_end": "172.17.0.70",
      "gateway": "172.17.0.1"
    }
  }
    • metadata.namespace: サービスがデプロイされる namespace。
    • "name": nncp CR で定義されている、ネットワークに関連付けられたノードのインターフェイス名。
    • "ipMasq": オプションのフィールド。true に設定すると、IP マスカレードが有効になります。ゲートウェイに IP アドレスがない場合、ipMasq は影響を受けません。デフォルト値は false です。データプレーンノードに必要なルートがない場合、またはフリー範囲ルーティング(FRR)を設定する前にデータプレーンノードにコントロールプレーンネットワークに接続 されていない場合は、ipMasq を設定します。
    • "ipam": whereabouts CNI IPAM プラグインは、作成された Pod に .30 - .70 の範囲の IP を割り当てます。
    • "range_start" - "range_end": IP アドレスプールの範囲が、MetalLB IPAddressPool の範囲および NetConfig allocationRange と重複しないようにしてください。

  3. クラスターに NetworkAttachmentDefinition CR を作成します。 

    $ oc apply -f openstack-net-attach-def.yaml

  4. NetworkAttachmentDefinition CR が作成されたことを確認します。 

    $ oc get net-attach-def -n openstack

4.3.4. RHOCP を BGP 用の RHOSO ネットワーク VIPS を使用するように準備する
リンクのコピー

各ノードの eth2 および eth3 インターフェイスに接続するリーフスイッチを定義するには、BGPPeer カスタムリソース (CR) のペアを作成する必要があります。たとえば、worker-0 には leaf-0 用と leaf-1 用に 1 つずつ、合計 2 つの BGPPeer CR があります。BGP ピアの詳細は、https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/ingress_and_load_balancing/load-balancing-with-metallb#nw-metallb-configure-bgppeer_configure-metallb-bgp-peers [BGP ピアの設定] を参照してください。

また、アドバタイズされるネットワーク範囲を定義する IPAddressPool CR と、BGPPeer CR のアナウンス方法を定義し、アドバタイズを受信する BGPPeer CR に IPAddressPool CR をリンクする BGPAdvertisement CR も作成する必要があります。

手順

  1. ワークステーションに BGPPeer CR ファイル (例: bgppeers.yaml) を作成します。

  2. ピアリングする各ノードの BGPPeer CR のペアを設定します。次の例では、worker-0 ノードに 2 つの BGPPeer CR を設定します。1 つは leaf-0 用、もう 1 つは leaf-1 用です。 

    apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: bgp-peer-node-0-0
  namespace: metallb-system
spec:
  myASN: 64999
  nodeSelectors:
  - matchExpressions:
	- key: kubernetes.io/hostname
  	operator: In
  	values:
  	- worker-0
  password: r3dh4t1234
  peerASN: 64999
  peerAddress: 100.64.0.13
---
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: bgp-peer-node-0-1
  namespace: metallb-system
spec:
  myASN: 64999
  nodeSelectors:
  - matchExpressions:
	- key: kubernetes.io/hostname
  	operator: In
  	values:
  	- worker-0
  password: r3dh4t1234
  peerASN: 64999
  peerAddress: 100.65.0.13

  3. BGPPeer CR を作成します。 

    $ oc create -f bgppeers.yaml
  4. ワークステーションに IPAddressPool CR ファイル (例: ipaddresspools-bgp.yaml) を作成します。

  5. IPAddressPool CR ファイルで、各分離ネットワークの IPAddressPool リソースを設定して、MetalLB が影響力を持つ IP アドレス範囲を指定します。 

    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ctlplane
  namespace: metallb-system
spec:
  addresses:
  - 192.168.125.80-192.168.125.90
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: internalapi
  namespace: metallb-system
spec:
  addresses:
  - 172.17.0.80-172.17.0.90
    • spec.addresses: IPAddressPool の範囲が、whereabouts IPAM の範囲および NetConfig allocationRange と重複しないようにしてください。

    他の IPAddressPool リソースパラメーターを設定する方法の詳細は、RHOCP ネットワークの概要 の MetalLB BGP ピアの設定 を参照してください。

  6. クラスターに IPAddressPool CR を作成します。 

    $ oc apply -f ipaddresspools-bgp.yaml

  7. IPAddressPool CR が作成されたことを確認します。 

    $ oc describe -n metallb-system IPAddressPool

  8. ワークステーションに BGPAdvertisement CR ファイル (例: bgpadvert.yaml) を作成します。 

    apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgpadvertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - ctlplane
  - internalapi
  - storage
  - tenant
  peers:
  - bgp-peer-node-0-0
  - bgp-peer-node-0-1
  - bgp-peer-node-1-0
  - bgp-peer-node-1-1
  - bgp-peer-node-2-0
  - bgp-peer-node-2-1
  ...
    • ピア: 各 RHOCP ノードが通信する必要のあるピア IP アドレス用に定義したすべての BGPPeer CR を一覧表示します。

  9. クラスター内に BGPAdvertisement CR を作成します。 

    $ oc apply -f bgpadvert.yaml

  10. クラスターにネットワークバックエンドとして OVNKubernetes がある場合は、MetalLB がセカンダリーネットワークインターフェイスで動作できるように、グローバル転送を有効にする必要があります。

    1. クラスターが使用するネットワークバックエンドを確認します。 

      $ oc get network.operator cluster --output=jsonpath='{.spec.defaultNetwork.type}'

    2. バックエンドが OVNKubernetes の場合は、次のコマンドを実行してグローバル IP 転送を有効にします。 

      $ oc patch network.operator cluster -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' --type=merge
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る