VMware NSX Container Plugin 3.2

4.2 4.1 4.0 3.2 3.1 3.0
简体中文 Deutsch Español Français Italiano 日本語 한국어 繁體中文 English

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

Content feedback and comments