Kubernetes ノードの準備

Kubernetes ノードを準備する手順のほとんどは、nsx-ovs と nsx-ncp-bootstrap 2 つのコンテナによって自動化されています。これらのコンテナはそれぞれ nsx-node-agent DaemonSet と nsx-ncp-bootstrap DaemonSet で実行されます。

NCP をインストールする前に、Kubernetes ノードに Python がインストールされ、コマンドラインインターフェイスからアクセスできることを確認してください。Linux パッケージマネージャを使用してインストールできます。たとえば、Ubuntu では、コマンド apt install python を実行できます。

Ubuntu の場合、 NSX CNI プラグインをインストールすると、AppArmor プロファイルファイル ncp-apparmor が /etc/apparmor.d にコピーされ、ロードされます。インストールの前に、AppArmor サービスが実行されており、 /etc/apparmor.d ディレクトリを作成しておく必要があります。これを行わないと、インストールは失敗します。次のコマンドで、AppArmor モジュールが有効かどうかを確認できます。

    sudo cat /sys/module/apparmor/parameters/enabled

次のコマンドで、AppArmor サービスが開始されているかどうかを確認できます。

    sudo /etc/init.d/apparmor status

ncp-apparmor プロファイルファイルは、node-agent-apparmor と呼ばれる NSX Node Agent 用の AppArmor プロファイルを提供します。これは、docker-default プロファイルとは次の点で異なります。

deny mountルールが削除されている。
mountルールが追加されている。
いくつかの network、capability、file、および umount オプションが追加されている。

node-agent-apparmorプロファイルは、別のプロファイルに置き換えることができます。その場合は、NCP YAML ファイルでプロファイル名 node-agent-apparmor を変更する必要があります。

NSX NCP ブートストラップコンテナは、ホストでの NSX CNI のインストールと更新を自動化します。以前のリリースでは、NSX CNI は deb/rpm パッケージによってインストールされました。このリリースでは、ファイルがホストにコピーされます。ブートストラップコンテナが、以前にインストールされた NSX CNI コンポーネントをパッケージマネージャのデータベースから削除します。次のディレクトリとファイルが削除されます。

/etc/cni/net.d
/etc/apparmor.d/ncp-apparmor
/opt/cni/bin/nsx

ブートストラップコンテナが 10-nsx.conflist ファイルを確認し、 nsxBuildVersion タグで CNI バージョン番号を検索します。このバージョンがブートストラップコンテナ内のバージョンよりも古い場合、次のファイルがホストにコピーされます。

/opt/cni/bin/nsx
/etc/cni/net.d/99-loopback.conf
/etc/cni/net.d/10-nsx.conflist
/etc/apparmor.d/ncp-apparmor

/opt/cni/bin/loopback ファイルと /etc/cni/net.d/99-loopback.conf ファイルが存在する場合、これらのファイルは上書きされません。OS タイプが Ubuntu の場合、ncp-apparmor ファイルもホストにコピーされます。

ブートストラップコンテナは IP アドレスとルートを br-int から node-if に移動します。また、OVS がホストで実行されている場合は、OVS を停止します。OVS は nsx-ovs コンテナ内で実行されます。br-int インスタンスが存在しない場合、nsx-ovs コンテナはこのインスタンスを作成します。さらに、ノードの論理スイッチに接続されているネットワークインターフェイス (node-if) を br-int に追加し、br-int と node-if のリンク状態が「稼動中」であることを確認します。IP アドレスとルートを node-if から br-int に移動します。nsx-node-agent ポッドまたは nsx-ovs コンテナが再起動されると、数秒のダウンタイムが発生します。

注： nsx-node-agent DaemonSet が削除された場合、OVS はホスト（コンテナまたはホストの PID 内）で実行されなくなります。

IP アドレスとルートを維持するようにネットワーク構成を更新します。たとえば、Ubuntu の場合、IP アドレスとルートを維持するように /etc/network/interfaces を編集します（必要に応じて、環境の実際の値を使用します）。

auto eth1
iface eth1 inet static
address 172.16.1.4/24
#persistent static routes
up route add -net 172.16.1.3/24 gw 172.16.1.1 dev eth1

次に、ifdown eth1; ifup eth1 コマンドを実行します。

RHEL の場合は、 /etc/sysconfig/network-scripts/ifcfg-<node-if> を作成して、IP アドレスとルートを維持するように編集します（必要に応じて、環境の実際の値を使用します）。

HWADDR=00:0C:29:B7:DC:6F
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=172.10.0.2
PREFIX=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV4_DNS_PRIORITY=100
IPV6INIT=no
NAME=eth1
UUID=39317e23-909b-45fc-9951-849ece53cb83
DEVICE=eth1
ONBOOT=yes

次に、systemctl restart network.service コマンドを実行します。

RHEL のパーシステントルートを構成する方法については、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-configuring_static_routes_in_ifcfg_filesを参照してください。

注：仮想マシンの再起動後に Kubernetes API サーバとの接続が失われないようにするには、アップリンクインターフェイス（ ovs_uplink_port で指定）で IP とスタティックルートを維持する必要があります。

注：デフォルトでは、nsx-ovs に名前 host-original-ovs-db、パス /etc/openvswitch のボリュームマウントがあります。これは、OVS が conf.db ファイルの保存に使用するデフォルトのパスです。OVS が別のパスを使用するように構成されているか、パスがソフトリンクの場合は、正しいパスで host-original-ovs-db マウントを更新する必要があります。

必要に応じて、ブートストラップコンテナによって行われた変更を取り消すことができます。詳細については、Kubernetes ノードのクリーンアップを参照してください。