Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第15章 SDN の設定
15.1. 概要
OpenShift SDN は、OpenShift Container Platform クラスターでの Pod 間の通信を有効にして Pod ネットワークを構築します。現在利用可能な SDN プラグイン は 3 種類 (ovs-subnet、ovs-multitenant、ovs-networkpolicy) あり、これらは Pod ネットワークを設定するためのそれぞれ異なる方法を提供します。
15.2. 利用可能な SDN プロバイダー
アップストリームの Kubernetes プロジェクトはデフォルトのネットワークソリューションを備えていません。その代わりに、Kubernetes では Container Network Interface (CNI) を開発し、ネットワークプロバイダーが独自の SDN ソリューションを統合することを可能にしています。
Red Hat は、サードパーティーのプラグインのほかにも追加設定なしで使用できるいくつかの OpenShift SDN プラグインを提供しています。
Red Hat は数多くの SDN プロバイダーと協力し、Kubernetes CNI インターフェースを使用した OpenShift Container Platform 上での SDN ネットワークソリューション (これには、製品のエンタイトルメントプロセスでの SDN プラグインのサポートプロセスが含まれます) の認定を行っています。Red Hat は、ユーザーが OpenShift でサポートケースを作成される場合、両社が共にユーザーのニーズに対応できるよう交換プロセスを促進し、これを容易にできます。
以下は、サードパーティーのベンダーが OpenShift Container Platform で直接検証を行い、サポートしている SDN ソリューションです。
- Cisco Contiv (™)
- Juniper Contrail (™)
- Nokia Nuage (™)
- Tigera Calico (™)
- VMware NSX-T (™)
VMware NSX-T (™) の OpenShift Container Platform へのインストール
VMware NSX-T (™) は、クラウドネイティブなアプリケーション環境を構築するための SDN およびセキュリティー基盤を提供しています。これらの環境には、vSphere Hypervisors (ESX) のほかに KVM とネイティブなパブリッククラウドが含まれます。
現在の統合には、NSX-T と OpenShift Container Platform の両方の新規インストールが必要です。現時点で、NSX-T バージョン 2.1 がサポートされ、これは ESX と KVM のハイパーバイザーの使用のみに対応しています。
詳細は「NSX-T Container Plug-in for OpenShift - Installation and Administration Guide」を参照してください。
15.3. Ansible を使用した Pod ネットワークの設定
初回の通常インストール (Advanced installation) では、ovs-subnet プラグインはデフォルトでインストールされ、設定されますが、このプラグインは、os_sdn_network_plugin_name パラメーターを使ってインストール時に上書きできます。これは Ansible インベントリーファイルで設定できます。
たとえば、標準の ovs-subnet プラグインを上書きし、代わりに ovs-multitenant プラグインを使用するには、以下を実行します。
# Configure the multi-tenant SDN plugin (default is 'redhat/openshift-ovs-subnet') os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'
インベントリーファイルに設定できるネットワーキング関連の Ansible 変数の詳細については、「クラスター変数の設定」を参照してください。
初回のクイックインストールでも、ovs-subnet プラグインは同様にデフォルトでインストールされ、設定され、master-config.yaml ファイルの networkConfig スタンザを使って、インストール後に再設定することができます。
15.4. マスターでの Pod ネットワークの設定
クラスター管理者は、マスター設定ファイル (デフォルトの場所は /etc/origin/master/master-config.yaml) の networkConfig セクションにあるパラメーターを変更することで、マスターホスト上で Pod ネットワーク設定を管理できます。
単一 CIDR の Pod ネットワーク設定
networkConfig: clusterNetworks: - cidr: 10.128.0.0/14 1 hostSubnetLength: 9 2 networkPluginName: "redhat/openshift-ovs-subnet" 3 serviceNetworkCIDR: 172.30.0.0/16 4
また、複数の CIDR 範囲を持つ Pod ネットワークを作成することもできます。これは、個別の範囲をその範囲と hostSubnetLength を指定した clusterNetworks フィールドに追加して実行できます。
複数の範囲は同時に使用することができ、この範囲は拡張または縮小することが可能です。ノードは、ノードの退避、削除および再作成によってある範囲から別の範囲に移動できます。詳細は、「ノードの管理」セクションを参照してください。ノードの割り当ては一覧の順序で行われ、範囲が一杯になると以下の一覧に移行します。
複数 CIDR の Pod ネットワークの設定
networkConfig: clusterNetworks: - cidr: 10.128.0.0/14 1 hostSubnetLength: 9 2 - cidr: 10.132.0.0/14 hostSubnetLength: 9 externalIPNetworkCIDRs: null hostSubnetLength: 9 ingressIPNetworkCIDR: 172.29.0.0/16 networkPluginName: redhat/openshift-ovs-multitenant 3 serviceNetworkCIDR: 172.30.0.0/16
clusterNetworks 値に要素を追加するか、その CIDR 範囲を使用しているノードがなければ要素を削除することができます。ただし変更を有効にするために、必ず atomic-openshift-master-api および atomic-openshift-master-controllers のサービスを再起動してください。
hostSubnetLength の値は、クラスターの初回作成後に変更することができません。cidr は、ノードが範囲内に割り当てられている場合に最初のネットワークが含まれるより大きいネットワークに変更することのみ可能です。また、serviceNetworkCIDR は拡張可能です。たとえば、デフォルト値が 10.128.0.0/14 の場合、cidr を 10.128.0.0/9 (上半分の net 10 を参照) に変更することは可能ですが、10.64.0.0/16 には元の値と重複しないために変更することができません。
serviceNetworkCIDR は 172.30.0.0/16 から 172.30.0.0/15 に変更できますが、172.28.0.0/14 に変更できません。元の範囲が新規の範囲内にある場合でも、その範囲が CIDR の開始部分になければならないためです。
15.5. ノードでの Pod ネットワークの設定
クラスター管理者は、ノード設定ファイル (デフォルトの場所は /etc/origin/node/node-config.yaml ) の networkConfig セクションにあるパラメーターを変更することで、ノード上に設定される Pod ネットワークを制御できます。
networkConfig: mtu: 1450 1 networkPluginName: "redhat/openshift-ovs-subnet" 2
OpenShift Container Platform SDN を構成するすべてのマスターおよび ノードで MTU サイズを変更する必要があります。また、tun0 インターフェースの MTU サイズはクラスターを構成するすべてのノードで同一である必要があります。
15.6. SDN プラグイン間の移行
SDN プラグインをすでに 1 つ使用していて、別のプラグインへ切り替える場合には、以下を実行します。
-
設定ファイル内のすべてのマスターとノードで
networkPluginNameパラメーターを変更します。 - すべてのマスターで atomic-openshift-master-api および atomic-openshift-master-controllers サービスを再起動します。
- すべてのマスターおよびノードで atomic-origin-node サービスを停止します。
- OpenShift SDN プラグインを切り換える場合、すべてのマスターおよびノードで openvswitch サービスを再起動します。
- すべてのマスターおよびノードで atomic-openshift-node サービスを停止します。
- OpenShift SDN プラグインからサードパーティーのプラグインへ切り替える場合は、OpenShift SDN 固有のアーティファクトを消去します。
$ oc delete clusternetwork --all $ oc delete hostsubnets --all $ oc delete netnamespaces --all
ovs-subnet から ovs-multitenant OpenShift SDN プラグインに切り替えると、クラスター内の既存のすべてのプロジェクトが完全に分離します (つまり、これらに固有の VNID が割り当てられます)。クラスター管理者は、管理者 CLI を使用してプロジェクトネットワークの変更を選択できます。
以下を実行して VNID をチェックします。
$ oc get netnamespace
15.6.1. ovs-multitenant から ovs-networkpolicy への移行
「SDN プラグイン間の移行」セクションでの上記の一般的なプラグインの移行に加え、ovs-multitenant プラグインから ovs-networkpolicy プラグインへの移行にはもう 1 つの追加の手順があります。つまり、すべての namespace に NetIDがあることを確認する必要があります。これは、以前にプロジェクトを結合している場合や、プロジェクトをグローバルにしている場合に、ovs-networkpolicy プラグインに切り換える前にこのやり直しを実行する必要があります。そうしない場合には、NetworkPolicy オブジェクトが適切に機能しなくなる可能性があります。
ヘルパースクリプトを使うと、NetID’s の修正、以前に分離した namespace を分離するための NetworkPolicy オブジェクトの作成、および以前に結合した namespace 間の接続の有効化を実行できます。
ovs-multitenant プラグインを実行した状態でヘルパースクリプトを使用して ovs-networkpolicy プラグインを移行するには、以下の手順に従ってください。
スクリプトをダウンロードし、実行ファイルパーミッションを追加します。
$ curl -O https://raw.githubusercontent.com/openshift/origin/master/contrib/migration/migrate-network-policy.sh $ chmod a+x migrate-network-policy.sh
スクリプトを実行します (クラスター管理者ロールが必要です)。
$ ./migrate-network-policy.sh
このスクリプトを実行すると、すべての namespace が他のすべての namespace から完全に分離されるので、ovs-networkpolicy プラグインへの移行が完了するまでは、異なる namespace にある Pod 間で接続を試行してもこれに失敗します。
新たに作成した namespace に同じポリシーをデフォルトで適用したい場合には、移行スクリプトで作成した default-deny および allow-from-global-namespaces ポリシーと一致する デフォルトの NetworkPolicy オブジェクトが作成されるように設定します。
スクリプトが失敗するか他のエラーが発生した場合、または ovs-multitenant プラグインに戻したい場合は、移行取り消し (un-migration) スクリプトを使用します。このスクリプトは移行スクリプトが実行した変更を取り消し、以前に結合した namespace を再度結合します。
15.7. クラスターネットワークへの外部アクセス
OpenShift Container Platform の外部にあるホストがクラスターネットワークへのアクセスを要求した場合、ユーザーには 2 つの選択肢があります。
- ホストを OpenShift Container Platform ノードとして設定する。ただし、これには スケジュール対象外 (unschedulable)のマークを付け、マスターがこれにコンテナーをスケジュールできないようにします。
- ユーザーのホストとクラスターネットワーク上のホストの間にトンネルを作成する。
上記のオプションはどちらも OpenShift SDN 内での edge ロードバランサーからコンテナーへのルーティングを設定するための実践的ユースケースの一部として本ドキュメントで紹介されています。
15.8. Flannel の使用
デフォルトの SDN の代わりとして、OpenShift Container Platform は、flannel ベースのネットワークをインストールするための Ansible Playbook を提供しています。これは、SDN に依存しているクラウドプロバイダーのプラットフォーム (Red Hat OpenStack Platform など) で OpenShift Container Platform を実行していて、両方のプラットフォームでパケットのカプセル化を 2 回実行することを避けたい場合に役立ちます。
Flannel は、すべてのコンテナーに単一の IP ネットワーク空間を使用し、隣接する空間のサブセットを各インスタンスに割り当てることを可能にします。これにより、コンテナーは何にも妨げられずに同じネットワーク空間内の任意の IP へ接続を試みることができます。これはネットワークを使ってアプリケーション内にあるコンテナーを別のアプリケーションから分離することができないために、マルチテナンシーを妨げます。
マルチテナンシーの分離とパフォーマンスのどちらを優先するかに応じて、内部ネットワークに OpenShift SDN (マルチテナンシー) と Flannel (パフォーマンス) のいずれか適切な方を選択する必要があります。
Flannel は、Red Hat OpenStack Platform の OpenShift Container Platform のみでサポートされています。
Neutron の現行バージョンはデフォルトで、各ポートに対するポートセキュリティーが有効になっているので、ポート自体のアドレスと異なる MAC アドレスを使ったパケットの送受信を実行できません。Flannel は、仮想の MAC アドレスと IP アドレスを作成し、パケットをポート上で送受信する必要があります。したがって、Flannel のトラフィックを実行するポートでは、ポートセキュリティーを無効にしておく必要があります。
OpenShift Container Platform クラスターで Flannel を無効にするには、以下を実行します。
Neutron のポートセキュリティーコントロールは、Flannel と互換性を持つように設定される必要があります。Red Hat OpenStack Platform のデフォルト設定では、
port_securityのユーザーコントロールは無効にされています。Neutron を、ユーザーが個々のポートでport_security設定を制御できるように設定します。Neutron サーバーで、以下を /etc/neutron/plugins/ml2/ml2_conf.ini ファイルに追加します。
[ml2] ... extension_drivers = port_security
次に、Neutron のサービスを再起動します。
service neutron-dhcp-agent restart service neutron-ovs-cleanup restart service neutron-metadata-agentrestart service neutron-l3-agent restart service neutron-plugin-openvswitch-agent restart service neutron-vpn-agent restart service neutron-server restart
Red Hat OpenStack Platform で OpenShift Container Platform インスタンスが作成されている間に、ポートのポートセキュリティーとセキュリティーグループの両方を無効にします。ここで、コンテナーネットワークの Flannel インターフェースは以下のようになります。
neutron port-update $port --no-security-groups --port-security-enabled=False
注記Flannel は、ノードのサブネットを設定し、割り当てるために etcd からの情報を収集します。したがって、etcd ホストに割り当てられるセキュリティーグループは、ノードからポート 2379/tcp へのアクセスを許可し、ノードのセキュリティーグループは etcd ホストでのそのポートへの egress 通信を許可する必要があります。
インストールを実行する前に以下の変数を Ansible インベントリーファイルに設定します。
openshift_use_openshift_sdn=false 1 openshift_use_flannel=true 2 flannel_interface=eth0
オプションで、
flannel_interface変数を使用してホスト間の通信に使用するインターフェースを指定することができます。この変数がない場合は、OpenShift Container Platform インストールではデフォルトのインターフェースが使用されます。注記Flannel を使用した Pod とサービスのカスタムのネットワーク CIDR は、今後のリリースでサポートされる予定です。BZ#1473858
OpenShift Container Platform をインストールした後、iptables の一連のルールを各 OpenShift Container Platform ノードに追加します。
iptables -A DOCKER -p all -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
これらの変更を /etc/sysconfig/iptables で永続化するには、すべてのノードで以下のコマンドを使用します。
cp /etc/sysconfig/iptables{,.orig} sh -c "tac /etc/sysconfig/iptables.orig | sed -e '0,/:DOCKER -/ s/:DOCKER -/:DOCKER ACCEPT/' | awk '"\!"p && /POSTROUTING/{print \"-A POSTROUTING -o eth1 -j MASQUERADE\"; p=1} 1' | tac > /etc/sysconfig/iptables"注記iptables-saveコマンドは、現在の インメモリー の iptables ルールをすべて保存します。ただし、Docker、Kubernetes、OpenShift Container Platform では永続化することが意図されていない iptables ルール (サービスなど) が多数作成されるために、これらのルールを保存すると問題が発生する可能性があります。
コンテナーのトラフィックを OpenShift Container Platform の残りのトラフィックから分離するには、分離されたテナントネットワークを作成し、すべてのノードをこれに割り当てることを推奨します。異なるネットワークインターフェース (eth1) を使用している場合は、インターフェースをブート時に /etc/sysconfig/network-scripts/ifcfg-eth1 ファイルを使用して起動するように設定してください。
DEVICE=eth1 TYPE=Ethernet BOOTPROTO=dhcp ONBOOT=yes DEFTROUTE=no PEERDNS=no
