NCP YAML ファイルには、すべての NCP コンポーネントの構成、インストール、実行に必要な情報が含まれています。

NCP YAML ファイルに含まれる情報は次のとおりです。
  • RBAC の定義。
  • さまざまな CRD(CustomResourceDefinitions)。
  • NCP 専用の ncp.ini を含む ConfigMap。一部の推奨構成オプションが設定されています。
  • NCP 展開。
  • nsx-node-agent 専用の ncp.ini を含む ConfigMap。一部の推奨構成オプションが設定されています。
  • nsx-node-agent、nsx-kube-proxy、nsx-ovs を含む nsx-node-agent DaemonSet。
  • nsx-ncp-bootstrap DaemonSet

NSX CNI と OpenvSwitch カーネル モジュールは、nsx-ncp-bootstrap initContainers によって自動的にインストールされます。OpenvSwitch userspace デーモンは、各ノードの nsx-ovs コンテナで実行されます。

NCP 展開仕様の更新

nsx-ncp-config という名前の ConfigMap を探します。ConfigMap オプションの完全なリストについては、 nsx-ncp-config ConfigMapを参照してください。一部のオプションには推奨値が設定されています。環境のすべてのオプションをカスタマイズできます。次はその例です。
  • ログ レベルとログ ディレクトリ。
  • Kubernetes API サーバの IP、証明書のパス、クライアント トークンのパス。デフォルトでは、環境変数にある API サーバの ClusterIP が使用され、証明書とトークンは ServiceAccount から自動的にマウントされます。通常、変更する必要はありません。
  • Kubernetes クラスタ名。
  • NSX Manager の IP と認証情報。
  • NSX リソース オプション(overlay_tztop_tier_routercontainer_ip_blocksexternal_ip_blocks など)。

デフォルトでは、Kubernetes Service VIP/ポート、ServiceAccount トークン、ca_file が Kubernetes API へのアクセスで使用されます。ここで変更する必要はありませんが、ncp.ini の NSX API オプションをいくつか設定する必要があります。

  • nsx_api_managers オプションを指定します。RFC3896 に準拠する NSX Manager IP アドレスまたは URL 仕様のカンマ区切りリストを指定できます。次はその例です。
    nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
  • 基本認証を使用して NSX-T に接続するように NCP を設定する場合は、nsx_api_user オプションにユーザー名を指定し、nsx_api_password オプションにパスワードを指定します。安全性が低いため、この認証方法はおすすめしません。クライアント証明書で認証を行うように NCP が設定されている場合、これらのオプションは無視されます。これらのオプションは NCP YAML ファイルに含まれていません。手動で追加する必要があります。
  • NSX-T での認証に使用する nsx_api_cert_file オプションと nsx_api_private_key_file オプションを指定します。nsx_api_cert_file オプションは、PEM 形式のクライアント証明書ファイルのフル パスです。このファイルの内容は次のようになります。
    -----BEGIN CERTIFICATE-----
    <certificate_data_base64_encoded>
    -----END CERTIFICATE-----
    nsx_api_private_key_file オプションは、PEM 形式のクライアント プライベート キー ファイルのフル パスです。このファイルの内容は次のようになります。
    -----BEGIN PRIVATE KEY-----
    <private_key_data_base64_encoded>
    -----END PRIVATE KEY-----

    クライアント証明書による認証を行う場合、NCP はプリンシパル ID を使用して NSX-T オブジェクトを作成できます。これは、同じ ID 名の ID のみがオブジェクトを変更または削除できることを意味します。これにより、NCP によって作成された NSX-T オブジェクトが誤って変更または削除されることはありません。管理者は、すべてのオブジェクトを変更または削除できます。プリンシパル ID でオブジェクトを作成すると、警告が表示されます。

  • (任意)ca_file オプションを指定します。値は、NSX Manager サーバ証明書の確認に使用する CA バンドル ファイルにする必要があります。設定しないと、システムのルート CA が使用されます。nsx_api_managers に 1 つの IP アドレスを指定した場合は、CA ファイルを 1 つ指定します。nsx_api_managers に 3 つの IP アドレスを指定した場合は、1 つまたは 3 つの CA ファイルを指定できます。1 つの CA ファイルを指定した場合、3 つのマネージャすべてに使用されます。3 つの CA ファイルを指定した場合、それぞれが nsx_api_managers 内の対応する IP アドレスに使用されます。次はその例です。
       nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183
       ca_file = ca_file_for_all_mgrs
    or
       nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183
       ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3
  • (任意)insecure オプションを指定します。True に設定すると、NSX Manager サーバ証明書は検証されません。デフォルトは False です。
Kubernetes シークレットに NSX クライアント証明書とロード バランサのデフォルト証明書を格納する場合は、最初に kubectl コマンドでシークレットを作成し、展開仕様を更新する必要があります。
  • NCP ポッド仕様にシークレット ボリュームを追加するか、サンプルのシークレット ボリュームのコメントを解除します。
  • NCP コンテナ仕様にボリューム マウントを追加するか、サンプルのボリューム マウントのコメントを解除します。
  • ConfigMap の ncp.ini を更新し、マウントされたボリューム内のファイルを参照するように、証明書ファイルのパスを設定します。

共有の Tier-1 トポロジを使用していない場合は、NCP が Loadbalancer サービス用に Tier-1 ゲートウェイまたはルーターを作成するように、edge_cluster オプションに Edge クラスタ ID を設定する必要があります。Edge クラスタ ID を確認するには、[システム] > [ファブリック] > [ノード] の順に移動し、[Edge クラスタ] タブを選択して Edge クラスタ名をクリックします。

HA(高可用性)はデフォルトで有効になっています。本番環境では、HA を無効にしないことをおすすめします。

注: デフォルトでは、kube-scheduler はマスター ノードのポッドをスケジューリングしません。NCP YAML ファイルでは、NCP ポッドのマスター ノードでの実行が許容されています。

SNAT の設定

デフォルトでは、NCP はすべてのプロジェクトに SNAT を構成します。次のアノテーションを含むネームスペースに SNAT は設定されません。
ncp/no_snat: True
クラスタ内のどのネームスペースでも SNAT を使用しない場合は、 ncp.ini に次のオプションを構成します。
[coe]
enable_snat = False

注:既存のネームスペースの SNAT アノテーションは更新できません。このようなアクションを実行すると、古い SNAT ルールが残る可能性があるため、ネームスペースのトポロジが不整合な状態になります。不整合な状態から復旧するには、ネームスペースを再作成する必要があります。

(ポリシー モードのみ)クラスタに SNAT が設定され、Tier-0 ルーターの BGP が有効になっている場合、Tier-0 ルーターのルート再配分を設定するときに Advertised tier-1 subnetsConnected Interfaces & Segments を選択すると、次のオプションを使用してルート再配分を制御できます。
[nsx_v3]
configure_t0_redistribution = True 

configure_t0_redistributionTrue に設定されている場合、Tier-0 ルーターがクラスタの内部サブネットを BGP ネイバーにアドバタイズしないように、NCP は再配分ルールに deny ルート マップ エントリを追加します。これは主に vSphere with Kubernetes クラスタで使用されます。再配分ルールにルート マップを作成しない場合、NCP はそのプリンシパル ID を使用してルート マップを作成し、ルールに適用します。このルート マップを変更する場合は、新しいルート マップに置き換え、NCP によって作成されたルート マップからエントリをコピーし、新しいエントリを追加する必要があります。新しいエントリと NCP が作成されたエントリの間で競合が発生しないように管理する必要があります。再配分ルールに新しいルート マップを作成せずに、NCP によって作成されたルート マップの設定を解除した場合、再起動時に NCP は以前に作成したルート マップを再配分ルールに適用します。

nsx-node-agent DaemonSet 仕様の更新

nsx-node-agent-config という名前の ConfigMap を探します。ConfigMap オプションの完全なリストについては、 nsx-node-agent-config ConfigMapを参照してください。一部のオプションには推奨値が設定されています。環境のすべてのオプションをカスタマイズできます。次はその例です。
  • ログ レベルとログ ディレクトリ。
  • Kubernetes API サーバの IP、証明書のパス、クライアント トークンのパス。デフォルトでは、環境変数にある API サーバの ClusterIP が使用され、証明書とトークンは ServiceAccount から自動的にマウントされます。通常、変更する必要はありません。
  • OpenvSwitch アップリンク ポート。例: ovs_uplink_port=eth1
  • CNI の MTU 値。

CNI の MTU 値を設定するには、nsx-node-agent ConfigMap の mtu パラメータを変更し、nsx-ncp-bootstrap ポッドを再起動します。これにより、各ノードのポッドの MTU が更新されます。また、ノードの MTU も適宜更新する必要があります。ノードとポッドの MTU が一致していないと、ノードとポッド間の通信で問題が発生する可能性があります。たとえば、TCP の稼動状態と準備状態の検証に影響する可能性があります。

nsx-ncp-bootstrap DaemonSet は、CNI および OVS カーネル モジュールをノードにインストールします。次に、ノードで OVS デーモンをシャットダウンします。これにより、以降の nsx-ovs コンテナは Docker コンテナ内で OVS デーモンを実行できるようになります。CNI がインストールされていない場合、すべての Kubernetes ノードは「準備未完了」の状態になります。bootstrap DaemonSet では、「準備未完了」状態のノードでの実行が許容されています。CNI プラグインをインストールした後、ノードは「準備完了」になります。

NSX OVS カーネル モジュールを使用していない場合は、OVS カーネル モジュールのコンパイル中に、OpenvSwitch データベースが構成されている場所の正しいパスでボリューム パラメータ host-original-ovs-db を更新する必要があります。たとえば、--sysconfdir=/var/lib を指定する場合は、host-original-ovs-db/var/lib/openvswitch に設定します。シンボリック リンクではなく、実際の OVS データベースのパスを使用してください。

NSX OVS カーネル モジュールを使用している場合は、use_nsx_ovs_kernel_module = True を設定し、マウントするボリュームの行のコメントを解除する必要があります。

  # Uncomment these mounts if installing NSX-OVS kernel module
#   # mount host lib modules to install OVS kernel module if needed
#   - name: host-modules
#     mountPath: /lib/modules
#   # mount openvswitch database
#   - name: host-config-openvswitch
#     mountPath: /etc/openvswitch
#   - name: dir-tmp-usr-ovs-kmod-backup
#   # we move the usr kmod files to this dir temporarily before
#   # installing new OVS kmod and/or backing up existing OVS kmod backup
#     mountPath: /tmp/nsx_usr_ovs_kmod_backup

#   # mount linux headers for compiling OVS kmod
#   - name: host-usr-src
#     mountPath: /usr/src

...

# Uncomment these volumes if installing NSX-OVS kernel module
# - name: host-modules
#   hostPath:
#     path: /lib/modules
# - name: host-config-openvswitch
#   hostPath:
#     path: /etc/openvswitch
# - name: dir-tmp-usr-ovs-kmod-backup
#   hostPath:
#     path: /tmp/nsx_usr_ovs_kmod_backup

# - name: host-usr-src
#   hostPath:
#     path: /usr/src

NCP 3.1.1 以降では、hostPort がサポートされます。ポッドに hostPort を指定する場合、nsx-node-agent-config ConfigMap の [k8s] セクションで enable_hostport_snatTrue に設定します。CNI プラグインをインストールする場合は、同じ ConfigMap で use_ncp_portmapFalse(デフォルト値)に設定する必要があります。CNI プラグインをインストールせず、NCP イメージから portmap を使用する場合は、use_ncp_portmapTrue に設定します。

SNAT は、 hostIP トラフィックの送信元 IP として hostPort を使用します。ポッドにネットワーク ポリシーが設定され、ポッドの hostPort にアクセスする場合は、ネットワーク ポリシーの許可ルールにワーカー ノードの IP アドレスを追加する必要があります。たとえば、2 つのワーカー ノード(172.10.0.2 と 172.10.0.3)がある場合、Ingress ルールは次のようになります。
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: test
    - podSelector:
        matchLabels:
          app: tea
    - ipBlock:
        cidr: 172.10.0.3/32
    - ipBlock:
        cidr: 172.10.0.2/32
    ...
NSX Node Agent は、各ポッドで 3 つのコンテナを実行する DaemonSet です。
  • nsx-node-agent はコンテナ ネットワーク インターフェイスを管理します。CNI プラグインや Kubernetes API サーバと通信を行います。
  • nsx-kube-proxy は、クラスタの IP をポッド IP に変換し、Kubernetes サービスを抽象化します。アップストリームの kube-proxy と同じ機能を実装しますが、相互に排他的ではありません。
  • nsx-ovs は、OpenvSwitch userspace デーモンを実行します。また、OVS ブリッジを自動的に作成し、IP アドレスとルートを node-if から br-int に移動します。ethX を OVS ブリッジ アップリンクとして使用できるように、ncp.iniovs_uplink_port=ethX を追加する必要があります。

ワーカー ノードが Ubuntu を使用している場合、AppArmor カーネル モジュールが有効になっていると仮定されます。それ以外の場合は、Kubelet は nsx-node-agent DaemonSet の実行を拒否します(AppArmor オプションで設定されているため)。Ubuntu と SUSE の場合、これはデフォルトで有効になっています。モジュールが有効になっているかどうかを確認するには、/sys/module/apparmor/parameters/enabled ファイルを確認します。

AppArmor を意図的に無効にしている場合は、YAML ファイルに次の変更を行う必要があります。
  • AppArmor オプションを削除します。
    annotations:
        # The following line needs to be removed
        container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor
  • nsx-node-agent と nsx-kube-proxy の両方のコンテナで、特権モードを有効にします。
    securityContext:
        # The following line needs to be appended
        privileged: true

注:hyperkube イメージを使用するコンテナ内で kubelet を実行すると、実際の状態に関係なく、kubelet が AppArmor の状態を常に無効と報告します。上と同じ変更を行い、YAML ファイルに適用する必要があります。

NameSpace 名の更新

YAML ファイルでは、ServiceAccount、ConfigMap、Deployment など、すべてのネームスペース オブジェクトが nsx-system ネームスペースに作成されます。別のネームスペースを使用する場合は、nsx-system のすべてのインスタンスを置き換えます。