検索

第31章 エッジロードバランサーからのルーティング

download PDF

31.1. 概要

OpenShift Container Platform クラスター内の Pod は、クラスターネットワーク上の IP アドレスを介してのみ到達可能です。エッジロードバランサーを使用することで、ネットワーク外部からのトラフィックを受け取り、OpenShift Container Platform クラスター内の Pod にトラフィックをプロキシーすることができます。ロードバランサーがクラスターネットワークに含まれていない場合は、内部クラスターネットワークがエッジロードバランサーからアクセスできないため、ルーティングが困難になります。

OpenShift Container Platform クラスターがクラスターネットワークソリューションとして OpenShift Container Platform SDN を使用している場合にこの問題を解決するには、Pod へのネットワークアクセスを以下の 2 つの方法で確保することができます。

31.2. ロードバランサーの SDN への追加

可能な場合は、ネットワークプラグインとして OpenShift SDN を使用するロードバランサー自体で OpenShift Container Platform ノードインスタンスを実行します。これにより、エッジマシンは独自の Open vSwitch ブリッジを取得し、このブリッジは、クラスターにある Pod とノードへのアクセスを提供するために SDN によって自動的に設定されます。ルーティングテーブル は、Pod が作成および削除される際に SDN によって動的に設定されるため、ルーティングソフトウェアは Pod に到達することができます。

Pod がロードバランサー自体に設定されないように、ロードバランサーマシンに スケジュール対象外ノードというマークを付けます。

$ oc adm manage-node <load_balancer_hostname> --schedulable=false

ロードバランサーがコンテナーとしてパッケージ化されている場合は、OpenShift Container Platform との統合が簡単になります。ロードバランサーをホストポートが公開されている状態の Pod として実行します。OpenShift Container Platform で事前にパッケージ化された HAProxy ルーターはこの方法で実行されます。

31.3. Ramp ノードを使用したトンネルの確立

前述のソリューションを使用できない場合もあります。たとえば、F5® は互換性のないカスタム Linux カーネルとディストリビューションを使用するため、F5 BIG-IP® ホストは OpenShift Container Platform ノードインスタンスまたは OpenShift Container Platform SDN を実行できません。

代わりに、F5 BIG-IP® を有効にして Pod に到達できるようにするために、クラスターネットワーク内の既存のノードを Ramp ノード として選択し、F5 BIG-IP® ホストと指定された Ramp ノード間でトンネルを確立することができます。Ramp ノードは通常の OpenShift Container Platform ノードであるため、Ramp ノードには、トラフィックをクラスターネットワーク内のノードにある Pod にルーティングするための設定が必要になります。そのため、Ramp ノードは F5 BIG-IP® ホストがクラスターネットワーク全体にアクセスする際に使用するゲートウェイのロールを引き継ぎます。

以下は、F5 BIG-IP® ホストと指定された Ramp ノード間で ipip トンネルを確立する例です。

On the F5 BIG-IP® host:

  1. 以下の変数を設定します。

    # F5_IP=10.3.89.66 1
    # RAMP_IP=10.3.89.89 2
    # TUNNEL_IP1=10.3.91.216 3
    # CLUSTER_NETWORK=10.128.0.0/14 4
    1 2
    F5_IP 変数と RAMP_IP 変数はそれぞれ、共有内部ネットワーク上にある F5 BIG-IP® ホストと Ramp ノードの IP アドレスを指しています。
    3
    ipip トンネルの F5® ホストの終端となる競合しない任意の IP アドレス。
    4
    OpenShift SDN が Pod にアドレスを割り当てるために使用するオーバーレイネットワークの CIDR 範囲。
  2. 古い route、self、tunnel および SNAT pool を削除します。

    # tmsh delete net route $CLUSTER_NETWORK || true
    # tmsh delete net self SDN || true
    # tmsh delete net tunnels tunnel SDN || true
    # tmsh delete ltm snatpool SDN_snatpool || true
  3. 新規の tunnel、self、route および SNAT pool を作成し、この SNAT pool を仮想サーバーで使用します。

    # tmsh create net tunnels tunnel SDN \
        \{ description "OpenShift SDN" local-address \
        $F5_IP profile ipip remote-address $RAMP_IP \}
    # tmsh create net self SDN \{ address \
        ${TUNNEL_IP1}/24 allow-service all vlan SDN \}
    # tmsh create net route $CLUSTER_NETWORK interface SDN
    # tmsh create ltm snatpool SDN_snatpool members add { $TUNNEL_IP1 }
    # tmsh modify ltm virtual  ose-vserver source-address-translation { type snat pool SDN_snatpool }
    # tmsh modify ltm virtual  https-ose-vserver source-address-translation { type snat pool SDN_snatpool }

Ramp ノード:

注記

以下で、永続性のない設定が作成されます。つまり、ramp ノードまたは openvswitch サービスを再起動すると、この設定はなくなります。

  1. 以下の変数を設定します。

    # F5_IP=10.3.89.66
    # TUNNEL_IP1=10.3.91.216
    # TUNNEL_IP2=10.3.91.217 1
    # CLUSTER_NETWORK=10.128.0.0/14 2
    1
    ipip トンネルの Ramp ノードの終端となる 2 番目の任意の IP アドレス。
    2
    OpenShift SDN が Pod にアドレスを割り当てるために使用するオーバーレイネットワークの CIDR 範囲。
  2. 古いトンネルを削除します。

    # ip tunnel del tun1 || true
  3. 適切な L2 接続インターフェース (たとえば、eth0) を使用して、Ramp ノードで ipip トンネルを作成します。

    # ip tunnel add tun1 mode ipip \
        remote $F5_IP dev eth0
    # ip addr add $TUNNEL_IP2 dev tun1
    # ip link set tun1 up
    # ip route add $TUNNEL_IP1 dev tun1
    # ping -c 5 $TUNNEL_IP1
  4. SDN サブネットの未使用の IP を使用してトンネル IP を SNAT します。

    # source /run/openshift-sdn/config.env
    # tap1=$(ip -o -4 addr list tun0 | awk '{print $4}' | cut -d/ -f1 | head -n 1)
    # subaddr=$(echo ${OPENSHIFT_SDN_TAP1_ADDR:-"$tap1"} | cut -d "." -f 1,2,3)
    # export RAMP_SDN_IP=${subaddr}.254
  5. この RAMP_SDN_IP を追加のアドレスとして tun0 (ローカル SDN のゲートウェイ) に割り当てます。

    # ip addr add ${RAMP_SDN_IP} dev tun0
  6. SNAT の OVS ルールを変更します。

    # ipflowopts="cookie=0x999,ip"
    # arpflowopts="cookie=0x999, table=0, arp"
    #
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "${ipflowopts},nw_src=${TUNNEL_IP1},actions=mod_nw_src:${RAMP_SDN_IP},resubmit(,0)"
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "${ipflowopts},nw_dst=${RAMP_SDN_IP},actions=mod_nw_dst:${TUNNEL_IP1},resubmit(,0)"
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "${arpflowopts}, arp_tpa=${RAMP_SDN_IP}, actions=output:2"
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "${arpflowopts}, priority=200, in_port=2, arp_spa=${RAMP_SDN_IP}, arp_tpa=${CLUSTER_NETWORK}, actions=goto_table:30"
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "arp, table=5, priority=300, arp_tpa=${RAMP_SDN_IP}, actions=output:2"
    # ovs-ofctl -O OpenFlow13 add-flow br0 \
        "ip,table=5,priority=300,nw_dst=${RAMP_SDN_IP},actions=output:2"
    # ovs-ofctl -O OpenFlow13 add-flow br0 "${ipflowopts},nw_dst=${TUNNEL_IP1},actions=output:2"
  7. 高可用性を実現するように Ramp ノードを設定する予定がない場合は、必要に応じて、Ramp ノードをスケジュール対象外としてマークします。以下のセクションに従う予定や、高可用性を備えた Ramp ノードを作成する予定がある場合は、この手順を省略してください。

    $ oc adm manage-node <ramp_node_hostname> --schedulable=false
注記

F5 ルータープラグインは F5 BIG-IP® と統合します。

31.3.1. 高可用性を備えた Ramp ノードの設定

keepalived を内部で使用する OpenShift Container Platform の ipfailover 機能を使用することで、F5 BIG-IP® の観点から Ramp ノードの高可用性を確保することができます。これを実行するには、まず同じ L2 サブネット上の 2 つのノード (たとえば、ramp-node-1 および ramp-node-2) を起動します。

次に、仮想 IP ( VIP) を使用するために未割り当ての IP アドレスを同じサブネット内から選択します。この IP アドレスは、F5 BIG-IP® でトンネルを設定するときに使用する RAMP_IP 変数として設定されます。

たとえば、Ramp ノードに対して使用するサブネットは 10.20.30.0/24 とし、10.20.30.2ramp-node-1 に、10.20.30.3ramp-node-2 に割り当てているとします。VIP については、同じ 10.20.30.0/24 サブネットから未割り当てのアドレスを選択します (例: 10.20.30.4)。次に、ipfailover を設定するために、両方のノードに f5rampnode などのラベルでマークを付けします。

$ oc label node ramp-node-1 f5rampnode=true
$ oc label node ramp-node-2 f5rampnode=true

ipfailover ドキュメントで説明されているのと同様に、ここでサービスアカウントを作成し、そのアカウントを特権付き SCC に追加する必要があります。最初に、f5ipfailover サービスアカウントを作成します。

$ oc create serviceaccount f5ipfailover -n default

次に、f5ipfailover サービスを特権付き SCC に追加できます。default namespace の f5ipfailover特権付き SCC に追加するには、以下を実行します。

$ oc adm policy add-scc-to-user privileged system:serviceaccount:default:f5ipfailover

最後に、選択した VIP (RAMP_IP 変数) と f5ipfailover サービスアカウントを使用して、先に設定した f5rampnode ラベルを使用して VIP を 2 つのノードに割り当て、ipfailover を設定します。

# RAMP_IP=10.20.30.4
# IFNAME=eth0 1
# oc adm ipfailover <name-tag> \
    --virtual-ips=$RAMP_IP \
    --interface=$IFNAME \
    --watch-port=0 \
    --replicas=2 \
    --service-account=f5ipfailover  \
    --selector='f5rampnode=true'
1
RAMP_IP を設定する必要があるインターフェース。

上記の設定を行うと、現在 VIP が割り当てられている Ramp ノードホストで障害が発生した場合に VIP (RAMP_IP 変数) が自動的に再割り当てされます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.