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 ノードのクリーンアップを参照してください。