第31章 エッジロードバランサーからのルーティング
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:
以下の変数を設定します。
# 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
古い 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
新規の 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 サービスを再起動すると、この設定はなくなります。
以下の変数を設定します。
# 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
古いトンネルを削除します。
# ip tunnel del tun1 || true
適切な 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
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
この
RAMP_SDN_IP
を追加のアドレスとして tun0 (ローカル SDN のゲートウェイ) に割り当てます。# ip addr add ${RAMP_SDN_IP} dev tun0
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"
高可用性を実現するように 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.2 を ramp-node-1 に、10.20.30.3 を ramp-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
変数) が自動的に再割り当てされます。