トールおよび管理ガイド nsx container plug-in for openshift：イ … · n...

NSX Container Plug-in for OpenShift：インストールおよび管理ガイド

NSX Container Plug-in 2.5、2.5.1

VMware NSX-T Data Center 2.5

最新の技術ドキュメントは、 VMware の Web サイト（https://docs.vmware.com/jp/）でご確認いただけます。このドキュメ

ントに関するご意見およびご感想は、[email protected] までお送りください。

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

ヴイエムウェア株式会社

105-0013　東京都港区浜松町 1-30-5浜松町スクエア 13Fwww.vmware.com/jp

Copyright ©

2017-2019 VMware, Inc. All rights reserved. 著作権および商標情報。


VMware, Inc. 2

https://docs.vmware.com/jp/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

目次

NSX-T Container Plug-in for OpenShift：インストールおよび管理ガイド 4

1 NSX-T Container Plug-in の概要 5互換性の要件 6

インストールの概要 6

仮想マシン環境での NCP のアップグレード 6

ベアメタルコンテナ環境での NCP のアップデート 7

2 NSX-T リソースのセットアップ 8[ネットワーク] タブでの NSX-T リソースの設定 8

[ネットワークとセキュリティの詳細設定] タブでの NSX-T リソースの設定 11

3 NCP のインストール 14システム要件 14

Ansible の hosts ファイルの準備 15

OpenShift クラスタと NCP のインストール 15

4 ロードバランシング 17ロードバランシングの設定 17

5 NSX Container Plug-in の管理 24NSX Manager グラフィカルユーザーインターフェイスでの IP ブロックの管理 24

NSX Manager グラフィカルユーザーインターフェイスでの IP ブロックのサブネットの表示 25

CIF 接続論理ポート 25

CLI コマンド 26

エラーコード 37

VMware, Inc. 3

NSX-T Container Plug-in for OpenShift：インストールおよび管理ガイド

このガイドでは、NSX Container Plug-in (NCP) をインストールして管理する方法を説明します。また、NSX-T Data Center と OpenShift を統合する方法についても説明します。

対象読者

このガイドは、システム管理者とネットワーク管理者を対象としています。NSX-T Data Center および OpenShift のインストールと管理について理解していることが前提となります。

VMware の技術ドキュメントの用語集VMware は、新しい用語を集めた用語集を提供しています。VMware の技術ドキュメントで使用されている用語の

定義については、http://www.vmware.com/support/pubs をご覧ください。

VMware, Inc. 4

http://www.vmware.com/support/pubs

NSX-T Container Plug-in の概要 1NSX Container Plug-in(NCP) は、NSX-T Data Center と Kubernetes などのコンテナオーケストレータとの統合

や、NSX-T Data Center と OpenShift などのコンテナベースの PaaS (Platform as a Service) ソフトウェア製品と

の統合を可能にします。このガイドでは、NCP と OpenShift のセットアップについて説明します。

NCP のメインコンポーネントはコンテナで実行され、NSX Manager や OpenShift 制御プレーンと通信を行いま

す。NCP は、コンテナや他のリソースに対する変更を監視し、NSX API を呼び出して、コンテナの論理ポート、ス

イッチ、ルーター、セキュリティグループなどのネットワークリソースを管理します。

NSX CNI プラグインは、各 OpenShift ノードで実行されます。コンテナのライフサイクルイベントを監視し、コン

テナインターフェイスをゲスト vSwitch に接続します。プログラムによってゲスト vSwitch をタグ付けし、コンテ

ナインターフェイスと vNIC 間でコンテナトラフィックを転送します。

NCP では、次の機能が提供されます。

n OpenShift クラスタに NSX-T 論理トポロジを自動的に作成し、OpenShift の名前空間に個別に論理ネットワー

クを作成します。

n OpenShift のポッドを論理ネットワークに接続し、IP アドレスと MAC アドレスを割り当てます。

n ネットワークアドレス変換 (NAT) をサポートしているため、OpenShift の名前空間に個別の SNAT IP を割り当

てることができます。

注： NAT を設定するとき、変換される IP アドレスの合計数は 1,000 を超えることはできません。

n NSX-T 分散ファイアウォールを使用した OpenShift ネットワークポリシーを実装。

n 入力方向および出力方向でネットワークポリシーをサポート。

n ネットワークポリシーで IPBlock セレクタをサポート。

n ネットワークポリシーでラベルセレクタを指定する際に matchLabels と matchExpression をサポー

ト。

n NSX-T レイヤー 7 ロードバランサを使用する OpenShift Route を実装。

n TLS Edge ターミネーションを含む HTTP Route と HTTPS Route をサポート。

n 代替バックエンドとワイルドカードサブドメインを含むルートをサポート。

n NSX-T 論理スイッチポート上に、名前空間、ポッド名、ポッドのラベル用のタグを作成し、管理者がタグベー

スで NSX-T Data Center のセキュリティグループとポリシーを定義できるようにします。

VMware, Inc. 5

本リリースでは、NCP は単一の OpenShift クラスタをサポートします。

この章には、次のトピックが含まれています。

n 互換性の要件

n インストールの概要

n 仮想マシン環境での NCP のアップグレード

n ベアメタルコンテナ環境での NCP のアップデート

互換性の要件

NSX Container Plug-in (NCP) には、次の互換性の要件があります。

互換性の要件については、リリースノートを参照してください。

インストールの概要

以下の手順に従って、NCP のインストールと設定を行います。手順を正常に実行するには、NSX-T Data Center および OpenShift のインストールと管理について理解している必要があります。

1 NSX-T Data Center をインストールします。

2 オーバーレイトランスポートゾーンを作成します。

3 オーバーレイ論理スイッチを作成し、ノードをスイッチに接続します。

これは、ベアメタルコンテナ (BMC) のセットアップでは必須ではありません。

4 最上位のルーターを作成します。

n 2 層トポロジの場合は、Tier-0 論理ルーターまたは Tier-0 ゲートウェイを作成します。

n 1 層トポロジの場合は、Tier-1 論理ルーターまたは Tier-1 ゲートウェイを作成します。

5 ポッドのネットワークに IP ブロックを作成します。

6 SNAT（送信元ネットワークアドレス変換）用の IP アドレスプールを作成します。

7 Ansible インベントリの hosts ファイルを準備します。

8 OpenShift と NCP をインストールします。

仮想マシン環境での NCP のアップグレードこのセクションでは、仮想マシン環境の NCP を 2.4.* を 2.5 にアップグレードする方法について説明します。

手順

1 インストールファイルをダウンロードします。

必要なファイルは次のとおりです。

n nsx-ncp-rhel-<version>.<build_no>.tar


VMware, Inc. 6

n ncp-openshift.yaml

2 次のコマンドを実行して、Docker イメージを読み込みます。

docker load -i nsx-ncp-rhel-<version>.<build_no>.tar

3 現在の環境に基づいて NCP YAML ファイル ncp-openshift.yaml を編集します。

4 次のコマンドを実行して、アップグレードを開始します。

kubectl apply -f ncp-openshift.yml

ベアメタルコンテナ環境での NCP のアップデートこのセクションでは、ベアメタルコンテナ (BMC) 環境の NCP を 2.4.* を 2.5 にアップデートする方法について説明

します。


2 次のコマンドを実行して、NCP YAML ファイル ncp-openshift-bm.yaml で nsx-kube-proxy DaemonSet

の部分をコメント行にします。

head -n 1155 ncp-openshift-bm.yaml > ncp-openshift-bm-upgrade.yaml

sed -n 1155,1297p ncp-openshift-bm.yaml > nsx-kube-proxy-bm-upgrade.yaml

3 古い NCP 環境を削除し、新しい new nsx-ncp イメージを使用して、ncp-openshift-bm.yaml を適用します。

kubectl delete -f <old-ncp.yaml> -n nsx-system

kubectl create -f ncp-openshift-bm-upgrade.yaml

4 nsx-node-agent DaemonSet のローリングアップデートを実行します。

kubectl set image ds nsx-node-agent -n nsx-system nsx-node-agent=<image>

kubectl set image ds nsx-node-agent -n nsx-system nsx-kube-proxy=<images>

kubectl rollout status ds/nsx-node-agent -n nsx-system

5 NSX-T をアップデートします。

NSX-T のアップデート後、nsx-node-agent ポッドがクラッシュします。nsx-node-agent は次の手順で削除

されるため、これは無視してかまいません。

6 環境から nsx-node-agent DaemonSet を削除し、手順 2 で作成した yaml ファイルを使用して新しい nsx-kube-proxy DaemonSet を作成します。

kubectl delete ds nsx-node-agent -n nsx-system

kubectl create -f nsx-kube-proxy-bm-upgrade.yaml -n nsx-system


VMware, Inc. 7

NSX-T リソースのセットアップ 2NCP をインストールする前に、一部の NSX-T リソースを設定する必要があります。

NSX Manager Web UI では、一部のネットワークリソースを設定方法が 2 つあります。

1 [ネットワーク] タブ。このタブでは、セグメント、ゲートウェイ、IP ブロック、IP プール、その他のオブジェク

トを設定できます。このタブのユーザーインターフェイスは、ポリシーユーザーインターフェイスともいいま

す。この方法の場合、API でネットワークを設定するときに、ポリシー API 呼び出しを使用する必要がありま

す。API リファレンスでは、これらの呼び出しに URI パス /policy/api/v1/... が付いています。

2 [ネットワークとセキュリティの詳細設定] タブ。このタブでは、論理スイッチ、論理ルーター、IP ブロック、IP プール、その他のオブジェクトを設定できます。このタブのユーザーインターフェイスは、マネージャユーザ

ーインターフェイスともいいます。この方法の場合、API でネットワークを設定するときに、マネージャ API 呼び出しを使用する必要があります。API リファレンスでは、これらの呼び出しに URI パス /api/v1/... が付い

ています。

NCP の NSX-T ネットワークを設定する場合、2 つの方法のいずれかを使用する必要がありますが、両方を使用する

必要はありません。ポリシーユーザーインターフェイスを使用する場合は、NCP YAML ファイルの

policy_nsxapi オプションを True に設定します。マネージャユーザーインターフェイスを使用する場合は、

False に設定します。

以降のセクションでは、NSX-T Data Center のインストールと管理について理解していることを前提としています。

詳細については、『NSX-T Data Center インストールガイド』と『 NSX-T Data Center 管理ガイド』を参照してく

ださい。


n [ネットワーク] タブでの NSX-T リソースの設定

n [ネットワークとセキュリティの詳細設定] タブでの NSX-T リソースの設定

[ネットワーク] タブでの NSX-T リソースの設定NCP に特定のネットワークリソースを設定するには、2 つの方法があります。このセクションでは、NSX Manager Web ユーザーインターフェイスで [ネットワーク] タブを使用する方法について説明します。

NCP 構成ファイル ncp.ini で、リソースの UUID または名前を使用して NSX-T リソースを指定できます。

VMware, Inc. 8

ゲートウェイとセグメント

1 Kubernetes ノードのセグメントを作成します（例：Segment1）。

2 Tier-0 ゲートウェイを作成します（例：T0GW1）。共有の Tier-1 トポロジを使用していない場合は、ncp.ini の

[nsx_v3] セクションで top_tier_router オプションにゲートウェイの ID に設定します。共有の Tier-1 ト

ポロジの設定方法については、以下を参照してください。このゲートウェイに NAT ルールを設定する場合は、

HA モードをアクティブ/スタンバイに設定します。それ以外の場合は、アクティブ/アクティブに設定します。

ルート再配分を有効にします。また、このゲートウェイを外部ネットワークへのアクセス用に設定します。

3 Tier-1 ゲートウェイを作成します（例：T1GW1）。このゲートウェイを Tier-0 ゲートウェイに接続します。

4 T1GW1 にルーターの通知を設定します。少なくとも、NSX が接続しているルートと NAT ルートを有効にする必

要があります。

5 T1GW1 を Segment1 に接続します。ゲートウェイポートの IP アドレスが Kubernetes ノードの IP アドレス

と競合していないことを確認します。

6 各ノード仮想マシンで、コンテナトラフィックの vNIC が自動作成の論理スイッチに接続していることを確認し

ます。接続していれば、[ネットワークとセキュリティの詳細設定] タブにセグメントと同じ名前 (Segment1) が

表示されます。

NCP は vNIC の VIF ID を認識している必要があります。[ネットワーク] > [セグメント] の順に移動すると、自動的に

作成された Segment1 のポートを確認できます。tag プロパティを除き、これらのポートは編集できません。これ

らのポートには次のタグが必要です。

scope: 'ncp/node_name', value: '<node_name>'

scope: 'ncp/cluster', value: '<cluster_name>'

これらのタグは、対応する論理スイッチポートに自動的に伝達されます。ノード名が変更された場合には、タグを更

新する必要があります。

クラスタにノードを追加するなど、NCP の実行中に Kubernetes クラスタを拡張する場合は、kubeadm join を実

行する前に、対応するスイッチポートにタグを追加する必要があります。kubeadm join の実行前にタグを追加しな

いと、新しいノードに接続できなくなります。その場合、タグを追加して NCP を再起動する必要があります。

ノード仮想マシンのスイッチポートを識別するには、次の API 呼び出しを実行します。

/api/v1/fabric/virtual-machines

応答でノード仮想マシンを検索し、external_id 属性の値を取得します。または、次の API 呼び出しを行います。

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

取得した外部 ID を次の API で使用し、仮想マシンの VIF を取得します。仮想マシンを起動するまで、VIF は読み込ま

れません。

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"


VMware, Inc. 9

lport_attachment_id 属性は、ノード仮想マシンの VIF ID です。その後、この VIF の論理ポートを検索し、必要

なタグを追加します。

Kubernetes ポッドの IP アドレスブロック

[ネットワーク] - [IP アドレス管理] - [IP アドレスブロック] の順に移動して、1 つ以上の IP ブロックを作成します。

IP アドレスブロックを CIDR 形式で指定します。ncp.ini の [nsx_v3] セクションで、container_ip_blocks

オプションに IP ブロックの UUID を設定します。NCP が IP ブロックを自動的に作成するように設定する場合は、

container_ip_blocks オプションにカンマ区切りのアドレスリストを CIDR 形式で設定します。

container_ip_blocks に UUID と CIDR の両方のアドレスを設定することはできません。

デフォルトでは、container_ip_blocks で指定された IP ブロックがプロジェクト間で共有されます。ncp.ini

の [nsx_v3] セクションで no_snat_ip_blocks オプションを設定すると、SNAT 以外の名前空間（Kubernetes

用）またはクラスタ（PCF 用）の IP ブロックを作成できます。

NCP の実行中に SNAT 以外の IP アドレスブロックを作成した場合には、NCP を再起動する必要があります。再起

動しない場合、IP アドレスブロックが枯渇するまで、NCP は共有の IP アドレスブロックを使用し続けます。

IP ブロックを作成するときに、NCP 構成ファイル ncp.ini の subnet_prefix オプションの値よりも大きいプリ

フィックスを使用しないでください。デフォルトは 24 です。

外部 IP プール

SNAT ルールを使用してポッドの IP を変換する際、または SNAT/DNAT ルールを使用して Ingress Controller と

LoadBalancer タイプのサービスを公開する際に、OpenStack のフローティング IP と同様に、外部 IP プールが IP アドレスの割り当てに使用されます。これらの IP アドレスは、外部 IP アドレスともいいます。

[ネットワーク] - [IP アドレス管理] - [IP アドレスプール] の順に移動して、IP プールを作成します。ncp.ini の

[nsx_v3] セクションで、external_ip_pools オプションに IP プールの UUID を設定します。NCP が IP プール

を自動的に作成するように設定する場合は、external_ip_pools オプションにカンマ区切りのアドレスリストを

CIDR 形式で設定するか、IP 範囲を設定します。external_ip_pools に UUID と CIDR の両方のアドレスを設定

することはできません。

複数の Kubernetes クラスタが同じ外部 IP アドレスプールを使用します。各 NCP インスタンスは、管理する

Kubernetes クラスタにこのプールのサブセットを使用します。デフォルトでは、ポッドのサブネットと同じサブネ

ットプリフィックスが使用されます。異なるサイズのサブネットを使用するには、ncp.ini の [nsx_v3] セクショ

ンにある external_subnet_prefix オプションを更新します。

設定ファイルを変更して NCP を再起動することで、異なる IP アドレスプールに変更できます。

共有の Tier-1 トポロジ

共有の Tier-1 トポロジを有効にするには、次の設定を行います。

n top_tier_router オプションに、Tier-0 ゲートウェイまたは Tier-1 ゲートウェイのいずれかの ID を設定しま

す。Tier-1 ゲートウェイの場合、外部接続用の Tier-0 ゲートウェイに接続する必要があります。

n ポッドトラフィックに SNAT が有効になっている場合は、Kubernetes ノードのセグメントのアップリンクを、

top_tier_router に設定されている Tier-0 または Tier-1 ゲートウェイに変更します。


VMware, Inc. 10

n single_tier_topology オプションを True に設定します。デフォルト値は False です。

n NCP が最上位層のルーターを Tier-1 ゲートウェイとして自動的に構成するように設定するには、

top_tier_router オプションの設定を解除し、tier0_gateway オプションを設定します。NCP は、Tier-1

ゲートウェイを作成し、tier0_gateway オプションに指定されている Tier-0 ゲートウェイとのアップリンク

を確立します。

[ネットワークとセキュリティの詳細設定] タブでの NSX-T リソースの設定

NCP に特定のネットワークリソースを設定するには、2 つの方法があります。このセクションでは、NSX Manager Web ユーザーインターフェイスで [ネットワークとセキュリティの詳細設定] タブを使用する方法について説明し

ます。

NCP 構成ファイル ncp.ini で、リソースの UUID または名前を使用して NSX-T リソースを指定できます。

論理ルーターと論理スイッチ

1 Kubernetes ノードの論理スイッチを作成します（例：LS1）。

2 Tier-0 論理ルーターを作成します（例：T0LR1）。共有の Tier-1 トポロジを使用していない場合は、ncp.ini の

[nsx_v3] セクションで tier0_router オプションに論理ルーターの ID に設定します。共有の Tier-1 トポ

ロジの設定方法については、以下を参照してください。この論理ルーターに NAT ルールを設定する場合は、HA モードをアクティブ/スタンバイに設定します。それ以外の場合は、アクティブ/アクティブに設定します。ルー

ト再配分を有効にします。また、このルーターを外部ネットワークへのアクセス用に設定します。

3 Tier-1 論理ルーターを作成します（例：T1LR1）。この論理ルーターを Tier-0 論理ルーターに接続します。

4 T1LR1 にルーターの通知を設定します。少なくとも、NSX が接続しているルートと NAT ルートを有効にする必

要があります。

5 T1LR1 を LS1 に接続します。論理ルーターのポートの IP アドレスが Kubernetes ノードの IP アドレスと競合

していないことを確認します。

6 各ノード仮想マシンで、コンテナトラフィックの vNIC が自動作成の論理スイッチに接続していることを確認し

ます。接続していれば、[ネットワークとセキュリティの詳細設定] タブに論理スイッチと同じ名前（LS1）が表

示されます。

NCP は vNIC の VIF ID を認識している必要があります。対応する論理スイッチのポートには次のタグが必要です。

scope: 'ncp/node_name', value: '<node_name>'

scope: 'ncp/cluster', value: '<cluster_name>'

ノード名が変更された場合には、タグを更新する必要があります。

クラスタにノードを追加するなど、NCP の実行中に Kubernetes クラスタを拡張する場合は、kubeadm join を実

行する前に、対応するスイッチポートにタグを追加する必要があります。kubeadm join の実行前にタグを追加しな

いと、新しいノードに接続できなくなります。その場合、タグを追加して NCP を再起動する必要があります。


VMware, Inc. 11

ノード仮想マシンのスイッチポートを識別するには、次の API 呼び出しを実行します。

/api/v1/fabric/virtual-machines

応答でノード仮想マシンを検索し、external_id 属性の値を取得します。または、次の API 呼び出しを行います。

/api/v1/search -G --data-urlencode "query=(resource_type:VirtualMachine AND

display_name:<node_vm_name>)"

取得した外部 ID を次の API で使用し、仮想マシンの VIF を取得します。仮想マシンを起動するまで、VIF は読み込ま

れません。

/api/v1/search -G --data-urlencode \

"query=(resource_type:VirtualNetworkInterface AND external_id:<node_vm_ext_id> AND \

_exists_:lport_attachment_id)"

lport_attachment_id 属性は、ノード仮想マシンの VIF ID です。その後、この VIF の論理ポートを検索し、必要

なタグを追加します。

Kubernetes ポッドの IP アドレスブロック

[ネットワークとセキュリティの詳細設定] - [IP 管理] の順に移動して、1 つ以上の IP ブロックを作成します。IP アド

レスブロックを CIDR 形式で指定します。ncp.ini の [nsx_v3] セクションで、container_ip_blocks オプシ

ョンに IP ブロックの UUID を設定します。

デフォルトでは、container_ip_blocks で指定された IP ブロックがプロジェクト間で共有されます。ncp.ini

の [nsx_v3] セクションで no_snat_ip_blocks オプションを設定すると、SNAT 以外の名前空間（Kubernetes

用）またはクラスタ（PCF 用）の IP ブロックを作成できます。

NCP の実行中に SNAT 以外の IP アドレスブロックを作成した場合には、NCP を再起動する必要があります。再起

動しない場合、IP アドレスブロックが枯渇するまで、NCP は共有の IP アドレスブロックを使用し続けます。

IP ブロックを作成するときに、NCP 構成ファイル ncp.ini の subnet_prefix パラメータ値よりも大きいプリフ

ィックスを使用しないでください。デフォルトは 24 です。

外部 IP プール

SNAT ルールを使用してポッドの IP を変換する際、または SNAT/DNAT ルールを使用して Ingress Controller と

LoadBalancer タイプのサービスを公開する際に、OpenStack のフローティング IP と同様に、外部 IP プールが IP アドレスの割り当てに使用されます。これらの IP アドレスは、外部 IP アドレスともいいます。

[ネットワークとセキュリティの詳細設定] - [インベントリ] - [グループ] - [IP プール] の順に移動して、IP プールを作

成します。ncp.ini の [nsx_v3] セクションで、external_ip_pools オプションに IP プールの UUID を設定し

ます。

複数の Kubernetes クラスタが同じ外部 IP アドレスプールを使用します。各 NCP インスタンスは、管理する

Kubernetes クラスタにこのプールのサブセットを使用します。デフォルトでは、ポッドのサブネットと同じサブネ

ットプリフィックスが使用されます。異なるサイズのサブネットを使用するには、ncp.ini の [nsx_v3] セクショ

ンにある external_subnet_prefix オプションを更新します。


VMware, Inc. 12

設定ファイルを変更して NCP を再起動することで、異なる IP アドレスプールに変更できます。

共有の Tier-1 トポロジ

共有の Tier-1 トポロジを有効にするには、次の設定を行います。

n top_tier_router オプションに、Tier-0 論理ルーターまたは Tier-1 論理ルーターのいずれかの ID を設定しま

す。Tier-1 論理ルーターの場合、外部接続用の Tier-0 論理ルーターに接続する必要があります。このオプション

は、tier0_router オプションを置換します。

n ポッドトラフィックに SNAT が有効になっている場合は、T1LR1 を LS1（Kubernetes ノードの論理スイッチ）

から切断し、top_tier_router に設定された Tier-0 または Tier-1 ルーターを LS1 に接続します。

n single_tier_topology オプションを True に設定します。デフォルト値は False です。

（オプション）ファイアウォールのマーカーセクション

管理者が作成したファイアウォールルールが、ネットワークポリシーに基づいて NCP で作成したファイアウォール

セクションに干渉されないようにするには、[ネットワークとセキュリティの詳細設定] - [セキュリティ] - [分散ファイ

アウォール] - [全般] の順に移動して、2 つのファイアウォールセクションを作成します。

ncp.ini の [nsx_v3] セクションで bottom_firewall_section_marker および

top_firewall_section_marker オプションを設定して、マーカーファイアウォールセクションを指定します。

最下位のファイアウォールセクションは、最上位のファイアウォールセクションの下に配置される必要があります。

これらのファイアウォールセクションを作成することで、NCP が分離用に作成するすべてのファイアウォールセク

ションは、リストの最下位のファイアウォールセクションの上に作成され、NCP がポリシー用に作成するすべての

ファイアウォールセクションは、最上位のファイアウォールセクションの下に作成されるようになります。マーカ

ーセクションを作成しない場合、すべての分離ルールはリストの最下位に作成され、すべてのポリシーセクション

は最上位に作成されます。同じ値を持つ複数のマーカーファイアウォールセクションを 1 つのクラスタに設定する

ことはできないため、エラーが発生します。


VMware, Inc. 13

NCP のインストール 3次のセクションでは、OpenShift と NCP のインストール手順について説明します。


n システム要件

n Ansible の hosts ファイルの準備

n OpenShift クラスタと NCP のインストール

システム要件

OpenShift をインストールする前に、環境が特定の要件を満たしていることを確認します。

一般的な要件

n Ansible 2.4 以降。

仮想マシンの要件

Openshift ノードの仮想マシンには 2 つの vNIC が必要です。

n 管理用 Tier-1 ルーターへのアップリンクを持つ論理スイッチに接続された管理用 vNIC。

n 特定の OpenShift ノードで実行されているすべてのポッドの親 VIF としてどのポートが使用されているかを

NSX Container Plug-in (NCP) が認識できるようにするには、すべての仮想マシンの 2 番目の vNIC で NSX-T の次のタグが必要です。

{'ncp/node_name': '<node_name>'}

{'ncp/cluster': '<cluster_name>'}

ベアメタルのマシンの要件

n OpenShift ノードは NSX-T トランスポートノードである必要があり、上記のタグは VIF ではなくトランスポー

トノードに適用される必要があります。

n Ansible の hosts ファイルには次の設定が必要です。nsx_node_type='BAREMETAL'

NSX-T の要件

n Tier-0 セグメントまたは論理ルーター。

VMware, Inc. 14

n オーバーレイトランスポートゾーン。

n ポッドネットワーク用の IP アドレスブロック。

n （オプション）ルーティングされた（非 NAT）ポッドネットワーク用の IP アドレスブロック。

n SNAT の IP アドレスプール。デフォルトでは、ポッドネットワーク用の IP アドレスブロックは NSX-T 内での

みルーティング可能です。NCP はこの IP アドレスプールを使用して外部への接続を提供します。

n （オプション）上部と下部のファイアウォールセクション。NCP はこれら 2 つのセクションの間に Kubernetes ネットワークポリシールールを配置します。

n Open vSwitch および CNI プラグイン RPM は、OpenShift ノード仮想マシンからアクセス可能な HTTP サー

バ上でホストされている必要があります。

NCP Docker イメージ

現在、NCP Docker イメージは公開されていません。ローカルのプライベートレジストリにイメージ nsx-ncp を含

めるか、次の手順を実行します。

ansible-playbook [-i /path/to/inventory] playbooks/prerequisites.yml

すべてのノード：

docker load -i nsx-ncp-rhel-xxx.yyyyyyyy.tar

docker image tag registry.local/xxx.yyyyyyyy/nsx-ncp-rhel nsx-ncp

ansible-playbook [-i /path/to/inventory] playbooks/deploy_cluster.yml

Ansible の hosts ファイルの準備Ansible hosts ファイルに次のパラメータを指定する必要があります。

n openshift_use_nsx=False

n openshift_use_openshift_sdn=False

n os_sdn_network_plugin_name='cni'

OpenShift クラスタと NCP のインストールOpenShift クラスタと NCP をインストールするには、次の手順に従います。


2 次のコマンドを実行して、必要なソフトウェアパッケージをインストールします。

ansible-playbook -i hosts playbooks/prerequisites.yml

3 次のコマンドを実行して、OpenShift クラスタをインストールします。

ansible-playbook -i hosts playbooks/deploy_cluster.yml

4 NCP YAML ファイルを準備します。


VMware, Inc. 15

仮想マシン環境の場合は、ncp-openshift.yaml を使用します。ベアメタル環境の場合は、ncp-openshift-

bm.yaml を使用します。

また、ベアメタル環境で NSX-T のバージョンが 2.4.* の場合、YAML ファイルの nsx-kube-proxy DaemonSet で、nsx-node-agent コンテナの行のコメントを解除する必要があります。

5 NCP YAML ファイルを適用します。次はその例です。

oc apply -f ncp-openshift.yaml


VMware, Inc. 16

ロードバランシング 4NSX-T Data Center ロードバランサは、OpenShift と連携し、OpenShift Router として機能します。

NCP は OpenShift Route とエンドポイントのイベントを監視し、ルートの仕様に基づいて、ロードバランサ上のロ

ードバランシングルールを設定します。結果的に、NSX-T Data Center ロードバランサはこのルールに基づき、適

切なバックエンドポッドにレイヤー 7 の受信トラフィックを転送します。


n ロードバランシングの設定

ロードバランシングの設定ロードバランシングの設定には、Kubernetes LoadBalancer サービスや OpenShift Route の設定などが含まれま

す。また、NCP レプリケーションコントローラの設定も必要です。LoadBalancer サービスは、レイヤー 4 トラフ

ィック向け、OpenShift Route は、レイヤー 7 トラフィック向けです。

Kubernetes LoadBalancer サービスを設定すると、設定した外部の IP アドレスブロックの IP アドレスが割り当て

られます。ロードバランサは、この IP アドレスとサービスポートを通じて公開されます。LoadBalancer に定義さ

れている loadBalancerIP を使用して、IP アドレスプールの名前または ID を指定できます。LoadBalancer サー

ビスの IP アドレスは、この IP アドレスプールから割り当てられます。loadBalancerIP が空白の場合、IP アドレ

スは事前設定した外部 IP アドレスブロックから割り当てられます。

loadBalancerIP で指定される IP アドレスプールには、タグ {"ncp/owner": cluster:<cluster>} を含め

る必要があります。

NSX-T Data Center のロードバランサを使用するには、ロードバランシングを NCP で設定する必要があります。

ncp_rc.yml ファイルで次の操作を行います。

1 use_native_loadbalancer を True に設定します。

2 pool_algorithm を WEIGHTED_ROUND_ROBIN に設定します。

3 lb_default_cert_path と lb_priv_key_path が、それぞれ認証局 (CA) 署名証明書ファイルとプライベートキーファイルの完全パス名になるように設定します。CA 署名証明書を生成するサンプルスクリプトについては、

以降を参照してください。また、NCP ポッドに、デフォルトの証明書とキーをマウントします。手順について

は、以降を参照してください。

VMware, Inc. 17

4 （オプション）パーシステンスの設定にパラメータ l4_persistence と l7_persistence を指定します。レ

イヤー 4 パーシステンスに使用可能なオプションは、送信元 IP アドレスです。レイヤー 7 パーシステンスに使

用可能なオプションは、Cookie と送信元 IP アドレスです。デフォルトは <None> です。次はその例です。

# Choice of persistence type for ingress traffic through L7 Loadbalancer.

# Accepted values:

# 'cookie'

# 'source_ip'

l7_persistence = cookie

# Choice of persistence type for ingress traffic through L4 Loadbalancer.

# Accepted values:

# 'source_ip'

l4_persistence = source_ip

5 （オプション）service_size に SMALL、MEDIUM、または LARGE を設定します。デフォルトは SMALL です。

6 OpenShift 3.11 を実行している場合、次の設定を実行して、OpenShift が LoadBalancer サービスに IP アドレ

スを割り当てないようにする必要があります。

n /etc/origin/master/master-config.yaml ファイル中の networkConfig で、

ingressIPNetworkCIDR を 0.0.0.0/32 に設定します。

n 次のコマンドを使用して API サーバとコントローラを再起動します。

master-restart api

master-restart controllers

Kubernetes LoadBalancer サービスの場合は、サービス仕様に sessionAffinity を指定して、グローバルレイ

ヤー 4 のパーシステンスがオフの場合、つまり l4_persistence が <None> に設定されている場合のサービスの

パーシステンス動作を設定することもできます。l4_persistence が source_ip に設定されている場合、サービ

スのパーシステンスタイムアウトをカスタマイズするために、サービス仕様の sessionAffinity を使用できま

す。デフォルトのレイヤー 4 のパーシステンスタイムアウトは 10,800 秒です。これは、サービスの Kubernetes ド


VMware, Inc. 18

キュメントに指定されているものと同じです（https://kubernetes.io/docs/concepts/services-networking/service を参照）。デフォルトのパーシステンスタイムアウトが設定されているサービスはすべて、同じ NSX-T ロー

ドバランサのパーシステンスプロファイルを共有します。デフォルト以外のパーシステンスタイムアウトを使用し

て、各サービスに専用プロファイルが作成されます。

注： Ingress のバックエンドサービスが LoadBalancer タイプのサービスである場合、サービスのレイヤー 4 仮想

サーバと Ingress のレイヤー 7 仮想サーバに異なるパーシステンスを設定することはできません。たとえば、レイヤ

ー 4 に source_ip、レイヤー 7 に cookie を設定することはできません。このようなシナリオでは、両方の仮想サ

ーバのパーシステンス設定を同じ（source_ip、cookie、または None）にするか、1 つを None（その他の設定

は source_ip または cookie）にする必要があります。シナリオの例：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: cafe-ingress

spec:

rules:

- host: cafe.example.com

http:

paths:

- path: /tea

backend:

serviceName: tea-svc

servicePort: 80

-----

apiVersion: v1

kind: Service

metadata:

name: tea-svc <==== same as the Ingress backend above

labels:

app: tea

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: tcp

selector:

app: tea

type: LoadBalancer

ルーターのシャーディング

NCP は常に TLS Edge ターミネーションと HTTP ルートを処理し、名前空間や名前空間ラベルに関係なく、TLS パス

スルールートおよび TLS 再暗号化ルートをスキップします。OpenShift ルーターが TLS 再暗号化およびパススルー

ルートのみを処理するように制限するには、次の手順を実行する必要があります。

n Openshift ルーターに名前空間ラベルセレクタを追加します。

n ターゲット名前空間に名前空間ラベルを追加します。


VMware, Inc. 19

https://kubernetes.io/docs/concepts/services-networking/service

https://kubernetes.io/docs/concepts/services-networking/service

n ターゲット名前空間に TLS 再暗号化/パススルールートを作成します。

たとえば、名前空間ラベルセレクタを使用してルーターを設定するには、次のコマンドを実行します（ルーターのサ

ービスアカウント名が router であると仮定します）。

oc set env dc/router NAMESPACE_LABELS="router=r1"

ルーターは選択された名前空間からルートを処理するようになります。このセレクタを名前空間と一致させるには、

次のコマンドを実行します（名前空間は ns1 であると仮定します）。

oc label namespace ns1 "router=r1"

レイヤー 7 ロードバランサの例

次の YAML ファイルでは、レイヤー 7 ロードバランシングを提供する 2 つのレプリケーションコントローラ（tea-rc および coffee-rc）、2 つのサービス（tea-svc および coffee-svc、2 つのルート（cafe-route-multi および cafe-route）を設定しています。

# RC

apiVersion: v1

kind: ReplicationController

metadata:

name: tea-rc

spec:

replicas: 2

template:

metadata:

labels:

app: tea

spec:

containers:

- name: tea

image: nginxdemos/hello

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80

---

apiVersion: v1

kind: ReplicationController

metadata:

name: coffee-rc

spec:

replicas: 2

template:

metadata:

labels:

app: coffee

spec:

containers:

- name: coffee

image: nginxdemos/hello

imagePullPolicy: IfNotPresent

ports:

- containerPort: 80


VMware, Inc. 20

---

# Services

apiVersion: v1

kind: Service

metadata:

name: tea-svc

labels:

app: tea

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: http

selector:

app: tea

---

apiVersion: v1

kind: Service

metadata:

name: coffee-svc

labels:

app: coffee

spec:

ports:

- port: 80

targetPort: 80

protocol: TCP

name: http

selector:

app: coffee

---

# Routes

apiVersion: v1

kind: Route

metadata:

name: cafe-route-multi

spec:

host: www.cafe.com

path: /drinks

to:

kind: Service

name: tea-svc

weight: 1

alternateBackends:

- kind: Service

name: coffee-svc

weight: 2

---

apiVersion: v1

kind: Route

metadata:

name: cafe-route

spec:

host: www.cafe.com


VMware, Inc. 21

path: /tea-svc

to:

kind: Service

name: tea-svc

weight: 1

補注

n HTTPS トラフィックでは Edge ターミネーションのみがサポートされます。

n ワイルドカードを使用するサブドメインの指定がサポートされています。たとえば、Subdomain に

wildcardPolicy が設定されていて、ホスト名が wildcard.example.com に設定されている場合、

*. example.com へのすべての要求に対してサービスが提供されます。

n 設定の誤りが原因で、Route イベントの処理中に NCP でエラーが発生する場合は、Route の YAML ファイルを

修正し、Route リソースを削除して再作成する必要があります。

n NCP では、名前空間によるホスト名の所有は適用されません。

n Kubernetes クラスタあたり 1 つの LoadBalancer サービスがサポートされます。

n NSX-T Data Center は、各 LoadBalancer サービスポートにレイヤー 4 のロードバランサ仮想サーバおよびプ

ールを作成します。TCP および UDP の両方がサポートされます。

n NSX-T Data Center ロードバランサには、異なるサイズを使用できます。NSX-T Data Center のロードバラン

サの構成については、『NSX-T Data Center 管理ガイド』を参照してください。

ロードバランサが作成された後に、構成ファイルを更新してロードバランサのサイズを変更することはできま

せん。変更するには、ユーザーインターフェイスまたは API を使用します。

n レイヤー 4 ロードバランサの自動スケーリングがサポートされます。Kubernetes LoadBalancer サービスが

追加の仮想サーバを必要とするように作成または変更されており、既存のレイヤー 4 ロードバランサに十分な容

量がない場合、新しいレイヤー 4 ロードバランサが作成されます。また、NCP は、仮想サーバが接続されてい

ないレイヤー 4 ロードバランサも削除します。この機能はデフォルトで有効になっています。NCP ConfigMap で l4_lb_auto_scaling を False に設定することで無効にできます。

CA 署名証明書を生成するサンプルスクリプト

次のスクリプトによって、CA 署名証明書とプライベートキーが生成され、それぞれファイル <filename>.crt およ

び <finename>.key として格納されます。genrsa コマンドで CA キーを生成します。CA キーは暗号化する必要

があります。aes256 などのコマンドを使用して、暗号化方式を指定できます。

#!/bin/bash

host="www.example.com"

filename=server

openssl genrsa -out ca.key 4096

openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/

L=Palo Alto/O=OS3/OU=Eng/CN=${host}"


VMware, Inc. 22

openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/

ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"

openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out $

{filename}.crt -sha256

デフォルトの証明書とキーの NCP ポッドへのマウント

証明書とプライベートキーは生成後、ホスト仮想マシンのディレクトリ /etc/nsx-ujo に配置されます。証明書と

キーファイルの名前がそれぞれ lb-default.crt、lb-default.key の場合、以下のように ncp-rc.yaml を編

集して、ホスト上のこれらのファイルが、ポッドにマウントされるようにします。次はその例です。

spec:

...

containers:

- name: nsx-ncp

...

volumeMounts:

...

- name: lb-default-cert

# Mount path must match nsx_v3 option "lb_default_cert_path"

mountPath: /etc/nsx-ujo/lb-default.crt

- name: lb-priv-key

# Mount path must match nsx_v3 option "lb_priv_key_path"

mountPath: /etc/nsx-ujo/lb-default.key

volumes:

...

- name: lb-default-cert

hostPath:

path: /etc/nsx-ujo/lb-default.crt

- name: lb-priv-key

hostPath:

path: /etc/nsx-ujo/lb-default.key


VMware, Inc. 23

NSX Container Plug-inの管理 5NSX Container Plug-in は、NSX Manager グラフィカルユーザーインターフェイスまたはコマンドラインインタ

ーフェイス (CLI) から管理できます。

注： ESXi 6.5 で稼動中のコンテナホストの仮想マシンを、別の ESXi 6.5 ホストに vMotion で移行する場合、移行

元のコンテナホスト上のコンテナから、移行先のコンテナホスト上のコンテナへの接続は失われます。この問題は、

コンテナホストの vNIC を切断し、再度接続することで解決できます。この問題は、ESXi 6.5 Update 1 以降では発

生しません。

Hyperbus では、ハイパーバイザーの VLAN ID 4094 は PVLAN の設定用に予約されており、ID を変更することはで

きません。VLAN の競合を避けるため、同じ VLAN ID の VLAN 論理スイッチまたは VTEP vmknic は設定しないで

ください。


n NSX Manager グラフィカルユーザーインターフェイスでの IP ブロックの管理

n NSX Manager グラフィカルユーザーインターフェイスでの IP ブロックのサブネットの表示

n CIF 接続論理ポート

n CLI コマンド

n エラーコード

NSX Managerグラフィカルユーザーインターフェイスでの IP ブロックの管理

NSX Manager グラフィカルユーザーインターフェイスで、IP ブロックのタグを追加、削除、編集、表示、管理で

きます。詳細を確認することもできます。

手順

1 ブラウザから NSX Manager (https://<nsx-manager-IP-address-or-domain-name>) にログインし

ます。

2 [ネットワーク] > [IP アドレス管理] の順に移動します。

既存の IP アドレスのブロックの一覧が表示されます。

VMware, Inc. 24

3 次のいずれかのアクションを実行します。

オプションアクション

IP ブロックを追加する [追加] をクリックします。

1 つ以上の IP ブロックを削除する 1 つ以上の IP ブロックを選択し、[削除] をクリックします。

IP ブロックを編集する IP ブロックを選択して [編集] をクリックします。

IP ブロックの詳細を表示する IP ブロック名をクリックします。全般的な情報を表示するには、[概要] タブをクリックしま

す。この IP ブロックのサブネットを表示するには、[サブネット] タブをクリックします。

IP ブロックのタグを管理します。 IP ブロックを選択し、[アクション] - [タグの管理] の順にクリックします。

サブネットが割り当てられた IP ブロックは削除できません。

NSX Manager グラフィカルユーザーインターフェイスでの IP ブロックのサブネットの表示

NSX Manager グラフィカルユーザーインターフェイスで IP ブロックのサブネットを表示できます。NCP をイン

ストールして実行した後に IP ブロックを追加または削除することは推奨されません。

手順

1 ブラウザから NSX Manager (https://<nsx-manager-IP-address-or-domain-name>) にログインし

ます。

2 [ネットワーク] > [IP アドレス管理] の順に移動します。

既存の IP アドレスのブロックの一覧が表示されます。

3 IP ブロックの名前をクリックします。

4 [サブネット] タブをクリックします。

CIF 接続論理ポートCIF（コンテナインターフェイス）は、スイッチ上の論理ポートに接続されているコンテナのネットワークインター

フェイスです。これらのポートは CIF 接続論理ポートといいます。

NSX Manager グラフィカルユーザーインターフェイスから CIF 接続論理ポートを管理できます。

CIF 接続論理ポートの管理

[ネットワーク] - [スイッチング] - [ポート] の順に移動して、CIF 接続論理ポートを含むすべての論理ポートを表示し

ます。CIF 接続論理ポートの接続リンクをクリックして、接続情報を表示します。論理ポートのリンクをクリックす

ると、ウィンドウペインが開き、[概要]、[監視]、[管理]、[関連] の 4 つのタブが表示されます。[関連] - [論理ポー

ト] の順にクリックすると、アップリンクスイッチに関連する論理ポートが表示されます。スイッチポートの詳細に

ついては、『NSX-T 管理ガイド』を参照してください。


VMware, Inc. 25

ネットワーク監視ツール

次のツールは、CIF 接続論理ポートをサポートします。これらのツールの詳細については、『NSX-T 管理ガイド』を

参照してください。

n トレースフロー

n ポート接続

n IPFIX

n コンテナに接続している論理スイッチポートの GRE カプセル化を使用して、リモートポートミラーリングを実

行できます。詳細については、『NSX-T 管理ガイド』の「ポートミラーリングスイッチングプロファイルにつ

いて」を参照してください。ただし、CIF ポートから VIF ポートへのミラーリングは、マネージャのユーザーインターフェイス経由ではサポートされません。

CLI コマンドCLI コマンドを実行するには、NSX Container Plug-in コンテナにログインしてターミナルを開き、nsxcli コマン

ドを実行します。

ノードで次のコマンドを実行して、CLI プロンプトを表示することもできます。

kubectl exec -it <pod name> nsxcli

表 5-1. NCP コンテナの CLI コマンド

タイプコマンド

状態 get ncp-master status

状態 get ncp-nsx status

状態 get ncp-watcher <watcher-name>

状態 get ncp-watchers

状態 get ncp-k8s-api-server status

状態 check projects

状態 check project <project-name>

キャッシュ get project-cache <project-name>

キャッシュ get project-caches

キャッシュ get namespace-cache <namespace-name>

キャッシュ get namespace-caches

キャッシュ get pod-cache <pod-name>

キャッシュ get pod-caches

キャッシュ get ingress-caches

キャッシュ get ingress-cache <ingress-name>

キャッシュ get ingress-controllers

キャッシュ get ingress-controller <ingress-controller-name>


VMware, Inc. 26

表 5-1. NCP コンテナの CLI コマンド（続き）


キャッシュ get network-policy-caches

キャッシュ get network-policy-cache <pod-name>

サポート get ncp-log file <filename>

サポート get ncp-log-level

サポート set ncp-log-level <log-level>

サポート get support-bundle file <filename>

サポート get node-agent-log file <filename>

サポート get node-agent-log file <filename> <node-name>

表 5-2. NSX Node Agent コンテナの CLI コマンド


状態 get node-agent-hyperbus status

キャッシュ get container-cache <container-name>

キャッシュ get container-caches

表 5-3. NSX Kube-Proxy コンテナの CLI コマンド


状態 get ncp-k8s-api-server status

状態 get kube-proxy-watcher <watcher-name>

状態 get kube-proxy-watchers

状態 dump ovs-flows

NCP コンテナの状態コマンド

n NCP マスターの状態を表示します。

get ncp-master status

例：

kubenode> get ncp-master status

This instance is not the NCP master

Current NCP Master id is a4h83eh1-b8dd-4e74-c71c-cbb7cc9c4c1c

Last master update at Wed Oct 25 22:46:40 2017

n NCP と NSX Manager の間の接続の状態を表示します。

get ncp-nsx status


VMware, Inc. 27

例：

kubenode> get ncp-nsx status

NSX Manager status: Healthy

n Ingress、名前空間、ポッド、サービスの監視の状態を表示します。

get ncp-watcher <watcher-name>

get ncp-watchers

例 1：

kubenode> get ncp-watcher pod

Average event processing time: 1174 msec (in past 3600-sec window)

Current watcher started time: Mar 02 2017 10:47:35 PST

Number of events processed: 1 (in past 3600-sec window)

Total events processed by current watcher: 1

Total events processed since watcher thread created: 1

Total watcher recycle count: 0

Watcher thread created time: Mar 02 2017 10:47:35 PST

Watcher thread status: Up

例 2：

kubenode> get ncp-watchers

pod:









namespace:









ingress:










VMware, Inc. 28

service:









n NCP と Kubernetes API サーバ間の接続の状態を表示します。

get ncp-k8s-api-server status

例：

kubenode> get ncp-k8s-api-server status

Kubernetes ApiServer status: Healthy

n すべてのプロジェクトまたは特定のプロジェクトを確認します。

check projects

check project <project-name>

例：

kubenode> check projects

default:

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

ns1:

Router 8accc9cd-9883-45f6-81b3-0d1fb2583180 is missing

kubenode> check project default

Tier-1 link port for router 1b90a61f-0f2c-4768-9eb6-ea8954b4f327 is missing

Switch 40a6829d-c3aa-4e17-ae8a-7f7910fdf2c6 is missing

NCP コンテナのキャッシュコマンド

n プロジェクトまたは名前空間の内部キャッシュを取得します

get project-cache <project-name>

get project-caches

get namespace-cache <namespace-name>

get namespace-caches

例：

kubenode> get project-caches

default:

logical-router: 8accc9cd-9883-45f6-81b3-0d1fb2583180


VMware, Inc. 29

logical-switch:

id: 9d7da647-27b6-47cf-9cdb-6e4f4d5a356d

ip_pool_id: 519ff57f-061f-4009-8d92-3e6526e7c17e

subnet: 10.0.0.0/24

subnet_id: f75fd64c-c7b0-4b42-9681-fc656ae5e435

kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get project-cache default


logical-switch:



subnet: 10.0.0.0/24


kubenode> get namespace-caches

default:


logical-switch:



subnet: 10.0.0.0/24


kube-system:

logical-router: 5032b299-acad-448e-a521-19d272a08c46

logical-switch:

id: 85233651-602d-445d-ab10-1c84096cc22a

ip_pool_id: ab1c5b09-7004-4206-ac56-85d9d94bffa2

subnet: 10.0.1.0/24

subnet_id: 73e450af-b4b8-4a61-a6e3-c7ddd15ce751

testns:

ext_pool_id: 346a0f36-7b5a-4ecc-ad32-338dcb92316f


VMware, Inc. 30

labels:

ns: myns

project: myproject

logical-router: 4dc8f8a9-69b4-4ff7-8fb7-d2625dc77efa

logical-switch:

id: 6111a99a-6e06-4faa-a131-649f10f7c815

ip_pool_id: 51ca058d-c3dc-41fd-8f2d-e69006ab1b3d

subnet: 50.0.2.0/24

subnet_id: 34f79811-bd29-4048-a67d-67ceac97eb98

project_nsgroup: 9606afee-6348-4780-9dbe-91abfd23e475

snat_ip: 4.4.0.3

kubenode> get namespace-cache default


logical-switch:



subnet: 10.0.0.0/24


n ポッドの内部キャッシュを取得します

get pod-cache <pod-name>

get pod-caches

例：

kubenode> get pod-caches

nsx.default.nginx-rc-uq2lv:

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4

gateway_ip: 10.0.0.1

host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb

ingress_controller: False

ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

nsx.testns.web-pod-1:

cif_id: ce134f21-6be5-43fe-afbf-aaca8c06b5cf


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 3180b521-270e-11e8-ab42-005056b198fb


ip: 50.0.2.3/24

labels:

app: nginx-new

role: db

tier: cache

mac: 02:50:56:00:20:02

port_id: 81bc2b8e-d902-4cad-9fc1-aabdc32ecaf8


VMware, Inc. 31

vlan: 3

kubenode> get pod-cache nsx.default.nginx-rc-uq2lv

cif_id: 2af9f734-37b1-4072-ba88-abbf935bf3d4


host_vif: d6210773-5c07-4817-98db-451bd1f01937

id: 1c8b5c52-3795-11e8-ab42-005056b198fb


ip: 10.0.0.2/24

labels:

app: nginx

mac: 02:50:56:00:08:00

port_id: d52c833a-f531-4bdf-bfa2-e8a084a8d41b

vlan: 1

n ネットワークポリシーキャッシュまたは特定のポリシーキャッシュを取得します。

get network-policy caches

get network-policy-cache <network-policy-name>

例：

kubenode> get network-policy-caches

nsx.testns.allow-tcp-80:

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:


VMware, Inc. 32

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1

kubenode> get network-policy-cache nsx.testns.allow-tcp-80

dest_labels: None

dest_pods:

50.0.2.3

match_expressions:

key: tier

operator: In

values:

cache

name: allow-tcp-80

np_dest_ip_set_ids:

22f82d76-004f-4d12-9504-ce1cb9c8aa00

np_except_ip_set_ids:

np_ip_set_ids:

14f7f825-f1a0-408f-bbd9-bb2f75d44666

np_isol_section_id: c8d93597-9066-42e3-991c-c550c46b2270

np_section_id: 04693136-7925-44f2-8616-d809d02cd2a9

ns_name: testns

src_egress_rules: None

src_egress_rules_hash: 97d170e1550eee4afc0af065b78cda302a97674c

src_pods:

50.0.2.0/24

src_rules:

from:

namespaceSelector:

matchExpressions:

key: tier

operator: DoesNotExist

matchLabels:

ns: myns

ports:

port: 80

protocol: TCP

src_rules_hash: e4ea7b8d91c1e722670a59f971f8fcc1a5ac51f1

NCP コンテナのサポートコマンド

n ファイルストアに NCP サポートバンドルを保存します。

サポートバンドルには、tier:nsx-networking というラベルが付いており、ポッド内のすべてのコンテナの

ログファイルが含まれます。バンドルファイルは tgz 形式で、CLI のデフォルトのファイルストアディレクト

リ /var/vmware/nsx/file-store に保存されます。CLI の file-store コマンドを使用すると、バンドルファ

イルをリモートサイトにコピーできます。

get support-bundle file <filename>


VMware, Inc. 33

例：

kubenode>get support-bundle file foo

Bundle file foo created in tgz format

kubenode>copy file foo url scp://[email protected]:/tmp

n NCP ログをファイルストアに保存します。

ログファイルは tgz 形式で、CLI のデフォルトのファイルストアディレクトリ /var/vmware/nsx/file-

store に保存されます。CLI の file-store コマンドを使用すると、バンドルファイルをリモートサイトにコピ

ーできます。

get ncp-log file <filename>

例：

kubenode>get ncp-log file foo

Log file foo created in tgz format

n Node Agent ログをファイルストアに保存します。

1 台のノードまたはすべてのノードの Node Agent ログを保存します。ログは tgz 形式で、CLI のデフォルトの

ファイルストアディレクトリ /var/vmware/nsx/file-store に保存されます。CLI の file-store コマンド

を使用すると、バンドルファイルをリモートサイトにコピーできます。

get node-agent-log file <filename>

get node-agent-log file <filename> <node-name>

例：

kubenode>get node-agent-log file foo

Log file foo created in tgz format

n ログレベルを取得して設定します。

使用可能なログレベルは NOTSET、DEBUG、INFO、WARNING、ERROR、および CRITICAL です。

get ncp-log-level

set ncp-log-level <log level>

例：

kubenode>get ncp-log-level

NCP log level is INFO

kubenode>set ncp-log-level DEBUG

NCP log level is changed to DEBUG


VMware, Inc. 34

NSX Node Agent コンテナの状態コマンド

n このノードの Node Agent と HyperBus 間の接続の状態を表示します。

get node-agent-hyperbus status

例：

kubenode> get node-agent-hyperbus status

HyperBus status: Healthy

NSX Node Agent コンテナのキャッシュコマンド

n NSX Node Agent コンテナの内部キャッシュを取得します。

get container-cache <container-name>

get container-caches

例 1：

kubenode> get container-cache cif104

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

例 2：

kubenode> get container-caches

cif104:

ip: 192.168.0.14/32

mac: 50:01:01:01:01:14

gateway_ip: 169.254.1.254/16

vlan_id: 104

NSX Kube-Proxy コンテナの状態コマンド

n Kube プロキシと Kubernetes API サーバ間の接続の状態を表示します。

get ncp-k8s-api-server status

例：

kubenode> get kube-proxy-k8s-api-server status

Kubernetes ApiServer status: Healthy

n Kube プロキシの監視の状態を表示します。

get kube-proxy-watcher <watcher-name>

get kube-proxy-watchers


VMware, Inc. 35

例 1：

kubenode> get kube-proxy-watcher endpoint


Current watcher started time: May 01 2017 15:06:24 PDT





Watcher thread created time: May 01 2017 15:06:24 PDT


例 2：

kubenode> get kube-proxy-watchers

endpoint:









service:









n ノードの OVS フローのダンプ

dump ovs-flows

例：

kubenode> dump ovs-flows

NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=8.876s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=100,ip

actions=ct(table=1)

cookie=0x0, duration=8.898s, table=0, n_packets=0, n_bytes=0, idle_age=8, priority=0

actions=NORMAL

cookie=0x0, duration=8.759s, table=1, n_packets=0, n_bytes=0, idle_age=8,

priority=100,tcp,nw_dst=10.96.0.1,tp_dst=443 actions=mod_tp_dst:443


priority=100,ip,nw_dst=10.96.0.10 actions=drop



VMware, Inc. 36

priority=90,ip,in_port=1 actions=ct(table=2,nat)

cookie=0x0, duration=8.799s, table=1, n_packets=0, n_bytes=0, idle_age=8, priority=80,ip

actions=NORMAL

cookie=0x0, duration=8.856s, table=2, n_packets=0, n_bytes=0, idle_age=8, actions=NORMAL

エラーコードこのセクションでは、さまざまなコンポーネントによって生成されるエラーコードについて説明します。

NCP (NSX Container Plug-in) エラーコード

エラーコード説明

NCP00001 設定が無効です

NCP00002 初期化に失敗しました

NCP00003 状態が無効です

NCP00004 アダプタが無効です

NCP00005 証明書が見つかりません

NCP00006 トークンが見つかりません

NCP00007 NSX の設定が無効です

NCP00008 NSX のタグが無効です

NCP00009 NSX の接続に失敗しました

NCP00010 ノードタグが見つかりません

NCP00011 ノードの論理スイッチポートが無効です

NCP00012 親 VIF の更新に失敗しました

NCP00013 VLAN が不足しています

NCP00014 VLAN の解放に失敗しました

NCP00015 IP アドレスプールが不足しています

NCP00016 IP アドレスの解放に失敗しました

NCP00017 IP アドレスブロックが不足しています

NCP00018 IP サブネットの作成に失敗しました

NCP00019 IP サブネットの削除に失敗しました

NCP00020 IP アドレスプールの作成に失敗しました

NCP00021 IP アドレスプールの削除に失敗しました

NCP00022 論理ルーターの作成に失敗しました

NCP00023 論理ルーターの更新に失敗しました

NCP00024 論理ルーターの削除に失敗しました

NCP00025 論理スイッチの作成に失敗しました


VMware, Inc. 37


NCP00026 論理スイッチの更新に失敗しました

NCP00027 論理スイッチの削除に失敗しました

NCP00028 論理ルーターポートの作成に失敗しました

NCP00029 論理ルーターポートの削除に失敗しました

NCP00030 論理スイッチポートの作成に失敗しました

NCP00031 論理スイッチポートの更新に失敗しました

NCP00032 論理スイッチポートの削除に失敗しました

NCP00033 ネットワークポリシーが見つかりません

NCP00034 ファイアウォールの作成に失敗しました

NCP00035 ファイアウォールの読み取りに失敗しました

NCP00036 ファイアウォールの更新に失敗しました

NCP00037 ファイアウォールの削除に失敗しました

NCP00038 複数のファイアウォールが見つかりました

NCP00039 NSGroup の作成に失敗しました

NCP00040 NSGroup の削除に失敗しました

NCP00041 IP セットの作成に失敗しました

NCP00042 IP セットの更新に失敗しました

NCP00043 IP セットの削除に失敗しました

NCP00044 SNAT ルールの作成に失敗しました

NCP00045 SNAT ルールの削除に失敗しました

NCP00046 アダプタ API による接続に失敗しました

NCP00047 アダプタウォッチャの例外です

NCP00048 ロードバランササービスの削除に失敗しました

NCP00049 ロードバランサ仮想サーバの作成に失敗しました

NCP00050 ロードバランサ仮想サーバの更新に失敗しました


NCP00051 ロードバランサ仮想サーバの削除に失敗しました

NCP00052 ロードバランサプールの作成に失敗しました

NCP00053 ロードバランサプールの更新に失敗しました

NCP00054 ロードバランサプールの削除に失敗しました

NCP00055 ロードバランサルールの作成に失敗しました

NCP00056 ロードバランサルールの更新に失敗しました

NCP00057 ロードバランサルールの削除に失敗しました

NCP00058 ロードバランサプールの IP アドレスの解放に失敗しました


VMware, Inc. 38


NCP00059 ロードバランサ仮想サーバとサービスの関連付けが見つかりません

NCP00060 NSGroup の更新に失敗しました

NCP00061 ファイアウォールルールの取得に失敗しました

NCP00062 NSGroup の条件がありません

NCP00063 ノード仮想マシンが見つかりません

NCP00064 ノード VIF が見つかりません

NCP00065 証明書のインポートに失敗しました

NCP00066 証明書のアンインポートに失敗しました

NCP00067 SSL バインドの更新に失敗しました

NCP00068 SSL プロファイルが見つかりません

NCP00069 IP アドレスプールが見つかりません

NCP00070 T0 Edge クラスタが見つかりません

NCP00071 IP アドレスプールの更新に失敗しました

NCP00072 ディスパッチャに失敗しました

NCP00073 NAT ルールの削除に失敗しました

NCP00074 論理ルーターポートの取得に失敗しました

NCP00075 NSX の設定の確認に失敗しました


NCP00076 SNAT ルールの更新に失敗しました

NCP00077 SNAT ルールが重複しています

NCP00078 ロードバランサのエンドポイントの追加に失敗しました

NCP00079 ロードバランサのエンドポイントの更新に失敗しました

NCP00080 ロードバランサルールプールの作成に失敗しました

NCP00081 ロードバランサ仮想サーバが見つかりません

NCP00082 IP セットの読み取りに失敗しました

NCP00083 SNAT プールの取得に失敗しました

NCP00084 ロードバランササービスの作成に失敗しました

NCP00085 ロードバランササービスの更新に失敗しました

NCP00086 論理ルーターポートの更新に失敗しました

NCP00087 ロードバランサの初期化に失敗しました

NCP00088 IP アドレスプールが一意ではありません

NCP00089 レイヤー 7 ロードバランサキャッシュの同期エラー

NCP00090 ロードバランサプールが配置されていません

NCP00091 ロードバランサルールキャッシュの初期化エラー


VMware, Inc. 39


NCP00092 SNAT プロセスが失敗しました

NCP00093 ロードバランサのデフォルト証明書エラー

NCP00094 ロードバランサのエンドポイントの削除に失敗しました

NCP00095 プロジェクトが見つかりません

NCP00096 プールのアクセスが拒否されました

NCP00097 ロードバランササービスの取得に失敗しました

NCP00098 ロードバランササービスの作成に失敗しました

NCP00099 ロードバランサのプールキャッシュ同期エラー

NSX ノードエージェントのエラーコード


NCP01001 OVS アップリンクが見つかりません

NCP01002 ホストの MAC アドレスが見つかりません

NCP01003 OVS ポートの作成に失敗しました

NCP01004 ポッドが設定されていません

NCP01005 ポッドの設定に失敗しました

NCP01006 ポッドの設定解除に失敗しました

NCP01007 CNI ソケットが見つかりません

NCP01008 CNI の接続に失敗しました

NCP01009 CNI バージョンが一致しません

NCP01010 CNI メッセージの受信に失敗しました

NCP01011 CNI メッセージの転送に失敗しました

NCP01012 Hyperbus の接続に失敗しました

NCP01013 Hyperbus バージョンが一致しません

NCP01014 Hyperbus メッセージの受信に失敗しました

NCP01015 Hyperbus メッセージの転送に失敗しました

NCP01016 GARP の送信に失敗しました

NCP01017 インターフェイスの設定に失敗しました

nsx-kube-proxy のエラーコード


NCP02001 無効なプロキシのゲートウェイポートです

NCP02002 プロキシコマンドの実行に失敗しました

NCP02003 プロキシの確認に失敗しました


VMware, Inc. 40

CLI のエラーコード


NCP03001 CLI の起動に失敗しました

NCP03002 CLI ソケットの作成に失敗しました

NCP03003 CLI ソケットの例外です

NCP03004 CLI クライアントの要求が無効です

NCP03005 CLI サーバの転送に失敗しました

NCP03006 CLI サーバの受信に失敗しました

NCP03007 CLI コマンドの実行に失敗しました

Kubernetes のエラーコード


NCP05001 Kubernetes の接続に失敗しました

NCP05002 Kubernetes の設定が無効です

NCP05003 Kubernetes の要求に失敗しました

NCP05004 Kubernetes のキーが見つかりません

NCP05005 Kubernetes のタイプが見つかりません

NCP05006 Kubernetes ウォッチャの例外です

NCP05007 Kubernetes リソースの長さが無効です

NCP05008 Kubernetes リソースのタイプが無効です

NCP05009 Kubernetes リソースの処理に失敗しました

NCP05010 Kubernetes サービスの処理に失敗しました

NCP05011 Kubernetes エンドポイントの処理に失敗しました

NCP05012 Kubernetes Ingress ハンドルの処理に失敗しました

NCP05013 Kubernetes ネットワークポリシーの処理に失敗しました

NCP05014 Kubernetes ノードの処理に失敗しました

NCP05015 Kubernetes 名前空間の処理に失敗しました

NCP05016 Kubernetes ポッドの処理に失敗しました

NCP05017 Kubernetes Secret の処理に失敗しました

NCP05018 Kubernetes デフォルトバックエンドが失敗しました

NCP05019 一致式が Kubernetes でサポートされていません

NCP05020 Kubernetes の状態の更新に失敗しました

NCP05021 Kubernetes のアノテーションの更新に失敗しました

NCP05022 Kubernetes の名前空間のキャッシュが見つかりません

NCP05023 Kubernetes Secret が見つかりません


VMware, Inc. 41


NCP05024 Kubernetes デフォルトバックエンドが使用中です

NCP05025 Kubernetes LoadBalancer サービスの処理に失敗しました

OpenShift のエラーコード


NCP07001 OC ルートの処理に失敗しました

NCP07002 OC ルートの状態の更新に失敗しました


VMware, Inc. 42

トールおよび管理ガイド nsx container plug-in for openshift：イ … · n...

Documents