NCP YAML ファイルの編集

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_tz、top_tier_router、container_ip_blocks、external_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 に接続するように NCP を構成する場合は、nsx_api_user オプションにユーザー名を指定し、nsx_api_password オプションにパスワードを指定します。安全性が低いため、この認証方法はおすすめしません。クライアント証明書で認証を行うように NCP が構成されている場合、これらのオプションは無視されます。これらのオプションは NCP YAML ファイルに含まれていません。手動で追加する必要があります。
NSX で認証を行うための 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 オブジェクトを作成できます。これは、同じ ID 名の ID のみがオブジェクトを変更または削除できることを意味します。これにより、NCP によって作成された NSX オブジェクトが誤って変更または削除されることはありません。管理者は、すべてのオブジェクトを変更または削除できます。プリンシパル 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 ポッドのマスターノードでの実行が許容されています。

ncp.ini の lb_segment_subnet パラメータは、サービスの ClusterIP セルフアクセスに使用されます。デフォルト値は 169.254.131.0/24 です。NCP は、このサブネットの最後から 2 番目の IP アドレスを SNAT IP アドレスとして使用します。たとえば、 lb_segment_subnet が 169.254.100.0/24 に設定されている場合、NCP は SNAT IP アドレスとして 169.254.100.254 を使用します。Windows ワーカーノードでは、lb_segment_subnet を 169.254.131.0/24 以外の値に設定する必要があります。クラスタの作成後に lb_segment_subnet を変更することはできません。

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 subnets で Connected Interfaces & Segments を選択すると、次のオプションを使用してルート再配分を制御できます。

[nsx_v3]
configure_t0_redistribution = True

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

NAT ルールのファイアウォール一致の構成

NCP 3.2.1 以降では、 natfirewallmatch オプションを使用して、Kubernetes ネームスペース用に作成された NAT ルールで NSX ゲートウェイファイアウォールの動作を指定できます。このオプションは、新しく作成された Kubernetes ネームスペースにのみ適用されます。既存のネームスペースには適用されません。このオプションはポリシーモードでのみ機能します。

[nsx_v3]
# This parameter indicate how firewall is applied to a traffic packet.
# Firewall can be bypassed, or be applied to external/internal address of
# NAT rule
# Choices: MATCH_EXTERNAL_ADDRESS MATCH_INTERNAL_ADDRESS BYPASS
#natfirewallmatch = MATCH_INTERNAL_ADDRESS

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

ポッドに hostPort を指定する場合、nsx-node-agent-config ConfigMap の [k8s] セクションで enable_hostport_snat を True に設定します。CNI プラグインをインストールする場合は、同じ ConfigMap で use_ncp_portmap を False（デフォルト値）に設定する必要があります。CNI プラグインをインストールせず、NCP イメージから portmap を使用する場合は、use_ncp_portmap を True に設定します。

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.ini に ovs_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 のすべてのインスタンスを置き換えます。

バックアップとリストアの有効化

NCP は、NSX でのバックアップとリストア機能をサポートします。サポートされるリソースは、ネームスペース、ポッド、およびサービスです。

注：NCP はポリシーモードで構成する必要があります。

この機能を有効にするには、 ncp.ini で enable_restore を True に設定して、NCP を再起動します。

[k8s]
enable_restore = True

NSX CLI コマンドを使用して、リストアの状態を確認できます。次はその例です。

nsxcli
> get ncp-restore status
NCP restore status is INITIAL

状態は、INITIAL、RUNNING、または SUCCESS です。INITIAL は、バックアップ/リストア機能の準備ができているが、リストアが実行されていないことを意味します。RUNNING は、リストアプロセスが NCP で実行中であることを意味します。SUCCESS は、リストアが正常に完了したことを意味します。リストア中にエラーが発生した場合、NCP は自動的に再起動して再試行します。状態が長時間 RUNNING になっている場合は、NCP ログでエラーメッセージを確認します。