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-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 を無効にしないことをおすすめします。

デフォルトでは、NCP はすべてのプロジェクトに SNAT を設定します。次の注釈を含む名前空間に SNAT は設定されません。

ncp/no_snat: True

クラスタ内のどの名前空間でも SNAT を使用しない場合は、 ncp.ini に次のオプションを設定します。

[coe]
enable_snat = False

注: デフォルトでは、kube-scheduler はマスターノードのポッドをスケジューリングしません。NCP YAML ファイルでは、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

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

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