All TKB Articles in Help & Resources

NSX-T の分散ファイアウォール（DFW）は、NSX-T のセグメント（オーバーレイ or VLAN）で機能します。 今回は、VLAN セグメントでも DFW が利用できることを確認してみます。 ラボ環境について。 今回のラボ環境は、下記のように用意してあります。 NSX-T 3.0 のシンプルな DFW ラボを構築する。 特にオーバーレイ ネットワークやルーティング機能などは準備せず、 ただ「VLAN セグメント」が利用できるようになっています。 NSX-T では、VLAN セグメント「seg-vlan-0006」を作成してあります。 まず、NSX Manager の画面から確認しておきます。 セグメントはオーバーレイではなく、VLAN のトランスポート ゾーンに作成し、VLAN ID 6 を設定しています。 つまりこれは NSX-T で作成されたセグメントですが、Geneve のオーバーレイではなく VLAN によるものです。 vCenter（の vSphere Client）で vDS「vds-21」を確認すると、 「seg-vlan-0006」が表示されており、NSX の「N」マークがついています。 ちなみに、dvpg-vlan-0006 という NSX-T に関係しない、VLAN ID 6 の分散ポートグループも別途作成してあります。 ※この分散ポートグループは次の投稿で利用します。 VM「vm01」の vNIC に、ポートグループとして NSX-T による VLAN セグメントを割り当てました。 なお、この VM の IP アドレスは 10.0.6.91 です。あとで、このアドレス宛に疎通確認します。 ESXi ホスト「192.168.10.21」で仮想スイッチの構成を確認すると、1つの vDS だけが構成されてます。 この vDS は NSX と統合されており、「NSX 仮想スイッチ」となっていることがわかります。 分散ポートグループやセグメントは、トポロジの図では実際に使用されているものだけが表示されています。 DFW ポリシー / ルールの作成。 NSX Manager で、DFW のポリシーとルールを作成します。 今回は、デフォルトで作成されているポリシーはそのままで、あえてポリシーを追加作成します。 そして、ルールの適用有無が分かりやすいように、すべての通信を許可 / 遮断するためのルールを、1つだけ作成します。 「セキュリティ」→「分散ファイアウォール」→「カテゴリ固有のルール」→「アプリケーション」を開きます。 デフォルト作成されるポリシー「Default Layer3 Section 」には、すべての通信を「許可」するルールが設定されているので、 今回の動作確認には特に影響しません。 この画面で「ポリシーの追加」をクリックすると「新規ポリシー」が作成されるので、 名前を「test-policy-01」に変更します。 追加された「test-policy-01」ポリシーを選択して、「ルールを追加」をクリックします。 「新規ルール」が作成されるので、「test-rule-01」に変更します。 ルールの「適用先」はデフォルトで「分散ファイアウォール」全体となっており、 NSX-T の オーバーレイ / VLAN セグメントに接続された VM に適用されます。 また、ルールの「送信元」、「宛先」、「サービス」は、いずれも「任意」になっているので、すべての通信が対象になります。 ただし、アクションは「許可」なので、このままでは通信の遮断はされません。 そして「発行」をクリックしてポリシー / ルールを保存しておきます。 ルールが保存され、このルールの ID は 3048 が採番されました。 このあと、このルールの設定を変更して、DFW の動作確認をします。 DFW ルールの動作確認。 それでは NSX 外部のマシンから、VLAN セグメントに接続されている vm01 宛に ping で疎通確認をしつつ、 DFW で通信を遮断してみます。 作成した DFW ルール「test-rule-01」のアクションを「許可」→「却下」に変更します。 ※これはドロップより却下の方がデモ的に見栄えがよいため・・・ 「発行」をクリックすると、ルールが適用されます。 この時点で vm01 宛に通信できる外部のマシンから ping を実行しつつ、「発行」をクリックします。 DFW のルールが作用して、外部の端末から vm01（10.0.6.91）への ping が通らなくなりました。 DFW ルール「test-rule-01」のアクションを「却下」→「許可」に戻して、「発行」をクリックすると・・・ 外部の端末から、vm01 への ping が通るようになりました。 このように、オーバーレイ セグメントではなく、VLAN セグメントでも、NSX-T の DFW は動作します。 まずは、DFW が動作することの確認でした。 次は、VM の vNIC に「NSX の VLAN セグメント」ではなく「vDS の分散ポートグループ」を割り当てた環境で、 分散ファイアウォール ルールが動作しない様子を確認してみます。 つづく！ NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（後編）

NSX-T には、分散ファイアウォール（DFW）機能があります。 この DFW は、NSX-T の有名な機能であるオーバーレイ ネットワーク（Geneve による）の環境でなくても利用可能です。 そこで今回は、オーバーレイ ネットワークなしのシンプルな DFW ラボ環境を構築してみます。 今回の環境。 今回のラボは、下記のような構成です。 vCenter Server 7.0d / ESXi 7.0 NSX-T 3.0 NSX の仮想スイッチは、N-VDS ではなく vDS 7.0 を利用（NSX-T 3.0 ～新機能） NSX Edge は無し。オーバーレイ ネットワークも無し。 vCenter / ESXi の仮想スイッチは、分散仮想スイッチ（vDS）のみを構成しています。 vDS のバージョンは 7.0 で作成してあり、アップリンクには ESXi の物理 NIC（vmnic0 と vmnic1）が割り当てられています。 NSX Manager の仮想アプライアンス（VM）は、すでにデプロイしてあります。 OVA ファイルは「nsx-unified-appliance-3.0.0.0.0.15945876-le.ova」です。 なお、NSX-T の設定作業をするためにはライセンスの適用は必須です。 デプロイ直後の NSX Manger の VM を起動して、 評価ライセンスを適用してある状態です。 NSX Manager での vCenter 登録。 NSX-T に「コンピュート マネージャ」として vCenter を登録します。 これは、NSX-T の仮想スイッチで vDS を利用するために必要です。 「システム」→「ファブリック」→「コンピュート マネージャ」を開き、 「追加」をクリックして「コンピュート マネージャの作成」画面を表示します。 そして、下記を入力して「追加」をクリックします。 vCenter の「名前」（これは任意の文字列） vCenter の「FQDN または IP アドレス」 vCenter の、ユーザー名と、パスワード 画面に従って証明書のサムプリントを受け入れると、vCenter がコンピュート マネージャとして登録されます。 これで、「システム」→「ファブリック」→「ノード」→ 「ホスト トランスポート ノード」で vCenter を選択すると、クラスタと ESXi が表示されるようになります。 ただしこの ESXi は、まだ NSX-T むけに準備されていない状態です。 ESXi のホスト トランスポート ノードとしての準備。 ここから ESXi を、NSX-T の「ホスト トランスポート ノード」として準備します。 まず、「システム」→「ファブリック」→「プロファイル」→ 「トランスポート ノード プロファイル」で、「追加」をクリックします。 「トランスポート ノード プロファイルの追加」画面が表示されるので、 下記を入力して、そのまま画面を下にスクロールします。 プロファイルにつける「名前」を入力。今回は tnp-esxi-vds-01 としています。 ノード スイッチの「タイプ」で、「VDS」を選択。 ノード スイッチ「名前」では、vCenter と vDS 名を選択。（例での vDS は vds-21） トランスポート ゾーンとして「nsx-vlan-transportzone」を選択。 （これは、デフォルト作成される VLAN トランスポート ゾーン） アップリンク プロファイルとして「nsx-default-uplink-hostswitch-profile」を選択。 画面下にスクロールして、下記を入力してから「追加」をクリックします。 uplink-1 → vDS の1つめのアップリンク名（例では dvUplink1） uplink-2 → vDS の2つめのアップリンク名（例では dvUplink2） これで、VLAN セグメントを利用できるようになる、トランスポート ノード プロファイルが作成されました。 「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、 クラスタ（ESXi ではなくその上の）を選択して、「NSX の設定」をクリックします。 「NSX のインストール」画面が表示されるので、先ほど作成したトランスポート ノード プロファイルを選択して、 「適用」をクリックします。 これで少し待つと、クラスタ配下の ESXi が NSX のホスト トランスポート ノードとして設定された状態になります。 NSX-T によるネットワークの準備。 このラボでは DFW だけを利用するため、NSX Edge はデプロイしていません。 そして、ルーティングのための Tier-0 / Tier-1 ゲートウェイや、Geneve のオーバーレイ セグメントも作成しません。 VLAN 接続するための「VLAN セグメント」のみ作成します。 Tier-0 ゲートウェイは、作成しません。 そして Tier-1 ゲートウェイも作成しません。 NSX-T では、vCenter でポートグループとして扱える「セグメント」を作成できます。 そして NSX-T の DFW は、この「セグメント」で作用します。 NSX-T のセグメントには、「オーバーレイ」と「VLAN」の ２種類がありますが、DFW はどちらでも利用できます。 そこで、ここでは「VLAN セグメント」のみを作成します。 「ネットワーク」→「セグメント」にある、「セグメント」タブで、「セグメントの追加」をクリックします。 そして下記を入力して、画面を下にスクロールします。 セグメント名を入力。ここでは seg-vlan-0006。 トランスポート ゾーンを選択。デフォルトで作成されている「nsx-vlan-transportzone | VLAN」を選択する。 VLAN ID を入力し、「保存」をクリックします。 今回は、セグメント名からもわかるように VLAN ID 6 のセグメントを作成します。 ちなみに、この VLAN ID は（NSX 外部の）物理スイッチのトランク ポートでも設定しておく必要があります。 このセグメントの設定を続行するかという確認メッセージは、「いいえ」で閉じます。 これで、VLAN セグメントが作成されました。 ここで作成した、VLAN セグメント「seg-vlan-0006」は、 vCenter の vSphere Client などでは、ポートグループとして VM の vNIC に割り当てられます。 これで、DFW を利用可能な、シンプルな構成のラボが構築できました。 つづく。

vSphere with Kubernetes のスーパーバイザー クラスタ上に作成した 「Tanzu Kubernetse Cluster」に、kubectl を使用していくつかの方法で接続してみます。 ドキュメントでは、下記のあたりが参考になります。 Tanzu Kubernetesクラスタ環境への接続 環境について。 今回の接続元の環境は Linux です。 スーパーバイザー クラスタの管理プレーンから、kubectl と vSphere プラグインはダウンロードしてあります。 $ cat /etc/system-release Oracle Linux Server release 7.8 $ kubectl version --short --client Client Version: v1.17.4-2+a00aae1e6a4a69 $ kubectl vsphere version kubectl-vsphere: version 0.0.2, build 16232217, change 8039971 Tanzu Kubernetse Cluster のラボは、下記のように構築しています。 vSphere with Kubernetes ラボ環境構築。（まとめ） kubectl は、スーパーバイザー クラスタの制御プレーンからダウンロードしたものを利用しています。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 vCenter Server 7.0b で、3ノードの ESXi で スーパーバイザー クラスタを構成しています。 スーパーバイザークラスタ「wcp-cluster-41」の、制御プレーンの IP アドレスは「192.168.70.97」です。 Tanzu Kubernetes Cluster（TKC）は、スーパーバイザークラスタの名前空間「lab-ns-03」に作成ずみです。 TKC の名前は「tkg-cluster-41」で、制御プレーンの IP アドレスは「192.168.70.99」です。 あらかじめ、vCenter Single Sign-On には、ID ソースとして LDAP サーバを登録ずみです。 ID ソースのドメイン「go-lab.jp」からユーザ情報を取得できています。 方法1： vCenter Single Sign-On 認証で接続する。 ここでは、「k8s-infra-user @ go-lab.jp」という vCenter Single Sigh-On のユーザーで接続してみます。 まず、対象のユーザーには、スーパーバイザー クラスタの名前空間で「権限の追加」が必要です。 そして、kubectl で TKC に接続する際は、スーパーバイザー制御プレーン宛となります。 ちなみに、vCenter の管理者ユーザ（administrator@vsphere.local）であれば、 デフォルトでスーパーバイザー クラスタや TKC にアクセス可能です。 1-1： スーパーバイザー名前空間での権限の追加。 スーパーバイザー クラスタの名前空間「lab-ns-03」の、 「サマリ」→「権限」にある「権限の追加」をクリックします。 ID ソース、ユーザー（またはグループ）、ロールを選択して、「OK」をクリックします。 今回は、ユーザー（k8s-infra-user）を指定していますが、一般的にはグループを指定するはずです。 ロールでは、「編集可能」（edit） または、「表示可能」（view）が選択できます。 権限が追加されました。 1-2： kubectl での接続。 kubectl vsphere login でログインすると、kubeconfig のファイルが生成されます。 デフォルトでは、$HOME/.kube/config というファイル名で作成されますが、 環境変数 KUBECONFIG を設定しておくと、そのパスに生成されます。 $ export KUBECONFIG=$(pwd)/kubeconfig_tkc kubectl vsphere login では、次のようなオプションを指定します。 --server： Tanzu Kubernetes Cluster の制御プレーンではなく、 スーパーバイザー クラスタの、制御プレーンが持つ IP アドレス（この環境では 192.168.70.97）を指定します。 --tanzu-kubernetes-cluster-namespace： TKC を作成したスーパーバイザー名前空間 --tanzu-kubernetes-cluster-name： TKC の名前 $ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41 Username: k8s-infra-user@go-lab.jp Password: ★パスワードを入力。 Logged in successfully. You have access to the following contexts:    192.168.70.97    lab-ns-03    tkg-cluster-41 If the context you wish to use is not in this list, you may need to try logging in again later, or contact your cluster administrator. To change context, use `kubectl config use-context <workload name>` $ TKC「tkg-cluster-41」と、TKC のスーパーバイザー名前空間「lab-ns-03」と同名のコンテキストが作成されます。 ここでも、TKC  の制御プレーン アドレス「192.168.70.99」がわかります。 $ kubectl config get-contexts tkg-cluster-41 CURRENT   NAME             CLUSTER         AUTHINFO                                     NAMESPACE *         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-infra-user@go-lab.jp TKC のノードが表示できました。 $ kubectl --context tkg-cluster-41 get nodes NAME                                            STATUS   ROLES    AGE    VERSION tkg-cluster-41-control-plane-vcdpg              Ready    master   153m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   131m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   127m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   131m   v1.17.8+vmware.1 ちなみに権限を追加していなかったり、ロールが「表示可能」の場合はエラーになります。 $ kubectl --context tkg-cluster-41 get nodes Error from server (Forbidden): nodes is forbidden: User "sso:k8s-infra-user@go-lab.jp" cannot list resource "nodes" in API group "" at the cluster scope なお、TKC で Deployment リソースなどで Pod を作成するには、PodSecurityPolicy の設定が必要になったりします。 （これは、この後の方法でも同様です） vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編 方法2： Kubernetes の管理ユーザ（kubernetes-admin）として接続する。 この方法では、TKC を作成してあるスーパーバイザー名前空間「lab-ns-03」に自動作成されている Secret リソースから、kubeconfig の情報を取得します。 これは、あらかじめ kubectl vsphere login でスーパーバイザー クラスタか TKC に接続したうえで取得することになります。 kubernetes-admin の kubeconfig での接続は、直接 TKC の管理プレーン宛を指定します。 2-1： kubernetes-admin ユーザーの kubeconfig の取得。 Secret リソースは、「＜Tanzu Kubernetes Cluster の名前＞-kubeconfig」となっており、 この環境では「tkg-cluster-41-kubeconfig」です。 $ kubectl --context lab-ns-03 get secrets tkg-cluster-41-kubeconfig NAME                        TYPE     DATA   AGE tkg-cluster-41-kubeconfig   Opaque   1      167m JSON パスでの「{.data.value}」に、base64 エンコーディングされた kubeconfig が格納されています。 この内容を、「base64 -d」コマンドでデコードして、ファイルに保存します。 $ kubectl --context lab-ns-03 get secret tkg-cluster-41-kubeconfig -o jsonpath='{.data.value}' | base64 -d > ./kubeconfig_tkg-cluster-41 2-2： 生成した kubeconfig での kubectl 接続。 保存した kubeconfig で、管理ユーザーのコンテキストで TKC に接続できます。 これは、vCenter Single Sign-On の認証とは関係なく接続できるものです。 $ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 config current-context kubernetes-admin@tkg-cluster-41 $ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 get nodes NAME                                            STATUS   ROLES    AGE    VERSION tkg-cluster-41-control-plane-vcdpg              Ready    master   155m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   133m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   129m   v1.17.8+vmware.1 tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   133m   v1.17.8+vmware.1 方法3： Kubernetes の ServiceAccount を作成して接続する。 方法1か、方法2の、いずれかで TKC に接続したうえで、TKC の名前空間に ServiceAccount を作成して接続します。 ServiceAccount での TKC への接続も、スーパーバイザー制御プレーンではなく、TKC 制御プレーン宛となります。 3-1： ServiceAccount の作成。 ここからは、ちょうど直前の 方法2 で作成した kubeconfig を利用します。 $ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41 $ kubectl config current-context kubernetes-admin@tkg-cluster-41 この時点では TKC の「default」名前空間を使用していますが、 あらたに「tkg-ns-01」という名前空間を作成して、そこに ServiceAccount で接続できるようにします。 $ kubectl create namespace tkg-ns-01 namespace/tkg-ns-01 created この時点 tkg-ns-01 名前空間に存在するのは、ServiceAccount（sa） は default のみです。 $ kubectl -n tkg-ns-01 get sa NAME      SECRETS   AGE default   1         43s ServiceAccount「sa-01」を作成します。 $ kubectl -n tkg-ns-01 create sa sa-01 serviceaccount/sa-01 created $ kubectl -n tkg-ns-01 get sa NAME      SECRETS   AGE default   1         47s sa-01     1         12s この ServiceAccount のトークンが格納されている、Secret リソースの名前を確認します。 $ SA_SECRET_NAME=$(kubectl -n tkg-ns-01 get sa sa-01 -o jsonpath='{.secrets[0].name}') $ echo $SA_SECRET_NAME sa-01-token-zc74c Secret リソースから、トークンを取得します。 $ SA_TOKEN=$(kubectl -n tkg-ns-01 get secrets $SA_SECRET_NAME -o jsonpath='{.data.token}' | base64 -d) 確認したトークンをもとに、Credential、コンテキストを作成します。 $ kubectl config set-credentials sa-01 --token=$SA_TOKEN User "sa-01" set. $ kubectl config set-context ctx-sa-01 --user=sa-01 --cluster=tkg-cluster-41 --namespace=tkg-ns-01 Context "ctx-sa-01" created. コンテキストを kubeconfig ファイルとして保存しておきます。 $ kubectl config view --minify --context=ctx-sa-01 --raw > ./kubeconfig_ctx-sa-01 $ kubectl config delete-context ctx-sa-01 ServiceAccount で接続する kubeconifg が生成されました。 $ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 config get-contexts CURRENT   NAME        CLUSTER          AUTHINFO   NAMESPACE *         ctx-sa-01   tkg-cluster-41   sa-01      tkg-ns-01 3-2： ServiceAccount の権限設定。 作成した ServiceAccount「sa-01」が Kubernetes のリソースを操作できるように、 ClusterRole「edit」を割り当てる RoleBinding を作成しておきます。 role-binding-edit.yml --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: rb-edit-sa-01 roleRef:   kind: ClusterRole   name: edit   apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount   name: sa-01 RoleBinding を、TKC の tkg-ns-01 名前空間に作成します。 $ kubectl -n tkg-ns-01 apply -f role-binding-edit.yml rolebinding.rbac.authorization.k8s.io/rb-edit-sa-01 created TKC で Pod を起動できるように、PodSecurityPolicy を割り当てる RoleBinding も作成しておきます。 こちらは、すべての ServiceAccount を指定しています。 role-binding-psp.yml --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: rb-vmware-system-privileged roleRef:   kind: ClusterRole   name: psp:vmware-system-privileged   apiGroup: rbac.authorization.k8s.io subjects: - kind: Group   name: system:serviceaccounts   apiGroup: rbac.authorization.k8s.io TKC の名前空間に RoleBinding を作成します。 $ kubectl -n tkg-ns-01 apply -f role-binding-psp.yml rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created 3-3： 生成した kubeconifg での kubectl 接続。 生成した kubeconfig で、Pod の起動ができました。 $ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 run pod-01 --image=gowatana/centos7:httpd --restart=Never pod/pod-01 created $ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 get pods NAME     READY   STATUS              RESTARTS   AGE pod-01   1/1     Running             0          44s Pod は削除しておきます。 $ kubectl --kubeconfig=./kubeconfig_ctx-sa-01.txt delete pod pod-01 pod "pod-01" deleted 方法4： TKC 側で vCenter Single Sign-On ユーザーの権限を割り当てる。 あらかじめ、方法1、または方法2の、いずれかの方法で TKC に接続しておきます。 そして方法1 とは異なり、TKC で作成した名前空間に vCenter Single Sigh-On ユーザーの権限を割り当てます。 そのあとの TKC への接続はスーパーバイザー制御プレーン宛となります。 方法4-1： TKC の名前空間への権限の追加。 ここでは、方法2 で生成した kubeconfig を利用して、TKC を操作します。 （方法1 の接続でも同様に操作できます） $ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41 $ kubectl config current-context kubernetes-admin@tkg-cluster-41 TKC の名前空間「tkg-ns-02」を追加作成します。 あわせて、PSP の RoleBinding（YAML は方法3のものと同様）も作成しておきます。 $ kubectl create namespace tkg-ns-02 namespace/tkg-ns-02 created $ kubectl -n tkg-ns-02 apply -f role-binding-psp.yml rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created RoleBinding の YAML を用意します。 リソースを操作できるように、ClusterRole「edit」を割り当てます。 subjects では vCenter Single Sign-On ユーザー（sso:k8s-dev-user@go-lab.jp）を指定しています。 ちなみに、グループを指定する場合は、「kind: User」を「kind: Group」にします。 role-binding-vcsso.yml --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: rb-edit-k8s-dev-user roleRef:   kind: ClusterRole   name: edit   apiGroup: rbac.authorization.k8s.io subjects: - kind: User   name: sso:k8s-dev-user@go-lab.jp #sso:<username>@<domain>   apiGroup: rbac.authorization.k8s.io 作成した TKC の名前空間「tkg-ns-02」に、RoleBinding を作成します。 $ kubectl -n tkg-ns-02 apply -f role-binding-vcsso.yml rolebinding.rbac.authorization.k8s.io/rb-edit-k8s-dev-user created 方法4-2： kubectl での接続。 既存の kubeconfig を上書きしないように、環境変数 KUBECONFIG に、新しい kubeconfig ファイルのパスを指定します。 この時点では「kubeconfig_k8s-dev-user」ファイルは存在しません。 $ export KUBECONFIG=$(pwd)/kubeconfig_k8s-dev-user kubectl vsphere login で、スーパーバイザー制御プレーンと TKC に接続します。 $ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41 Username: k8s-dev-user@go-lab.jp Password: ★パスワードを入力。 Logged in successfully. You have access to the following contexts:    192.168.70.97    tkg-cluster-41 If the context you wish to use is not in this list, you may need to try logging in again later, or contact your cluster administrator. To change context, use `kubectl config use-context <workload name>` $ コンテキストが生成されました。 $ kubectl config get-contexts tkg-cluster-41 CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE *         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-dev-user@go-lab.jp コンテキストを TKC の「tkg-cluster-41」に切り替えて、 デフォルトの名前空間として「tkg-ns-02」を設定します。 $ kubectl config use-context tkg-cluster-41 Switched to context "tkg-cluster-41". $ kubectl config set-context --current --namespace=tkg-ns-02 Context "tkg-cluster-41" modified. $ kubectl config get-contexts tkg-cluster-41 CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE *         tkg-cluster-41   192.168.70.99   wcp:192.168.70.99:k8s-dev-user@go-lab.jp   tkg-ns-02 Pod が起動できました。 $ kubectl run pod-01 --image=gowatana/centos7:httpd --restart=Never pod/pod-01 created $ kubectl get pods -n tkg-ns-02 NAME     READY   STATUS    RESTARTS   AGE pod-01   1/1     Running   0          10s スーパーバイザー名前空間「lab-ns-03」では「k8s-dev-user」ユーザーへの権限は追加していませんが、 vCenter Single Sigh-On ユーザーでリソース作成ができました。 vSphere Client で確認すると、方法1 で使用した「k8s-infra-user」ユーザーのみが追加されています。 vCenter 同梱ではない kubectl の接続。 ちなみに、ここまでの方法に関わらず、kubeconfig が生成できていれば 一般的な Kubernetes 操作ツールでも TKC に（スーパーバイザー クラスタにも）接続することができます。 Kubernetes のドキュメントでおなじみの URL から kubectl をダウンロードします。 $ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.8/bin/linux/amd64/kubectl $ chmod +x ./kubectl vCenter 同梱の kubectl と、あらたにダウンロードした kubectl（./kubectl でカレント ディレクトリのものを実行）です。 $ kubectl version --short Client Version: v1.17.4-2+a00aae1e6a4a69 Server Version: v1.17.8+vmware.1 $ ./kubectl version --short Client Version: v1.17.8 Server Version: v1.17.8+vmware.1 どちらの kubectl でも、普通に TKC を操作できます。 $ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user run pod-01 --image=gowatana/centos7:httpd --restart=Never pod/pod-01 created $ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user get pods NAME     READY   STATUS    RESTARTS   AGE pod-01   1/1     Running   0          15s Tanzu Kubernetes Cluster は、kubectl + vSphere プラグインによる vCenter Single Sign-On の認証だけでなく、 一般的な kubernetes と同様なクラスターへの接続ができます。 いくつか接続方法を試しましたが、もっとよい方法もあるかもしれません。 以上、いろいろと Tanzu Kubernetes Cluster への接続を試してみる話でした。

vSphere with Kubernetes のスーパーバイザー クラスタで、 Pod をノードに分散して起動する「アンチ アフィニティ」を試してみます。 vSphere で VM を起動する場合でも、複数台の VM を ESXi に分散して配置しようとするケースが多くあります。 たとえば「Web サーバ VM の 1号機と2号機は別の ESXi で起動する」といったものです。 vSphere Pod の実体は VM なのですが、特殊な VM なので、 ユーザが手動で vMotion できなかったり、DRS ＋ アンチ アフィニティルールが利用できなかったりします。 そこで、Kubernetes の持つ affinity の仕組みを利用できそうか様子を見てみます。 今回の環境。 vCenter Server 7.0b / ESXi 7.0 を利用しています。 スーパーバイザー クラスタ（wcp-cluster-41）には、3台のワーカー ノードとなる ESXi があります。 kubectl でも、スーパーバイザー クラスタに ESXi が 3台あることが確認できます。 $ kubectl get nodes NAME                               STATUS   ROLES    AGE   VERSION 42113326156c17e10192d03d69cfc933   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69 4211b5cba366a26db4debeca422d75ca   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69 4211b7998322f27779a8a0af22dbf35d   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69 lab-wcp-esxi-41.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8 lab-wcp-esxi-42.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8 lab-wcp-esxi-43.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8 ホスト名やソフトウェア バージョンは若干異なりますが、 このラボは下記のように環境構築しています。 vSphere with Kubernetes ラボ環境構築。（まとめ） vSphere Pod の起動。 まず、Kubernetes の Deployment リソースで、vSphere Pod を2つ起動します。 Deployment の定義は下記のようにしています。 httpd.yml · GitHub --- kind: Service apiVersion: v1 metadata:   name: web-svc spec:   type: LoadBalancer   ports:   - port: 80     protocol: TCP     targetPort: 80   selector:     app: demo-httpd --- kind: Deployment apiVersion: apps/v1 metadata:   name: demo-httpd   labels:     app: web spec:   replicas: 2   selector:     matchLabels:       app: demo-httpd   template:     metadata:       labels:         app: demo-httpd     spec:       containers:       - name: httpd         image: gowatana/centos7:httpd         ports:         - containerPort: 80           protocol: TCP Pod を作成するのは、スーパーバイザー クラスタの名前空間「lab-ns-01」です。 $ kubectl config current-context lab-ns-01 $ kubectl config get-contexts lab-ns-01 CURRENT   NAME        CLUSTER         AUTHINFO                                        NAMESPACE *         lab-ns-01   192.168.70.97   wcp:192.168.70.97:administrator@vsphere.local   lab-ns-01 Deployment を作成します。 $ kubectl apply -f httpd.yml service/web-svc created deployment.apps/demo-httpd created 特に Pod 配置にかかわる定義はなく、1つのホストに Pod が2つとも起動しています。 $ kubectl get pods -o wide NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                        NOMINATED NODE   READINESS GATES demo-httpd-6b58f9f454-kqld5   1/1     Running   0          70s   10.244.0.227   lab-wcp-esxi-41.go-lab.jp   <none>           <none> demo-httpd-6b58f9f454-t8bwj   1/1     Running   0          70s   10.244.0.226   lab-wcp-esxi-41.go-lab.jp   <none>           <none> vSphere Client でも、vSphere Pod として、 Pod が 2つとも「lab-wcp-esxi-41.go-lab.jp」で起動されたことが確認できます。 1つめの vSphere Pod です。 2つめの vSphere Pod です。 アンチ アフィニティへの定義変更。 アンチ アフィニティの方法については、下記の Kubernetes ドキュメントが参考になります。 アフィニティとアンチアフィニティ（日本語） https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity podAntiAffinity を定義した、下記のような YAML を用意しました。 httpd_anti-affinity.yml · GitHub Deployment を作成した YAML との差分です。 今回は、わかりやすく動きを見たいので、必須要件となるように 「requiredDuringSchedulingIgnoredDuringExecution」を指定しています。 $ diff httpd.yml httpd_anti-affinity.yml 37a38,47 >       affinity: >         podAntiAffinity: >           requiredDuringSchedulingIgnoredDuringExecution: >           - labelSelector: >               matchExpressions: >               - key: app >                 operator: In >                 values: >                 - demo-httpd >             topologyKey: "kubernetes.io/hostname" それでは、定義を変更（YAML を適用）します。 ※今回は既存の Deployment の定義を変更していますが、新規作成でもアンチ アフィニティ配置になります。 $ kubectl apply -f httpd_anti-affinity.yml service/web-svc unchanged deployment.apps/demo-httpd configured kubectl get pods で様子を見ていると、 Kubernetes による Pod の追加 / 削除が実施されます。 既存の Pod（～-c26jc、～-sjxpp）は停止され、あらたに Pod（～-rdz6l、～-wb774）が起動されています。 特に、スーパーバイザー クラスタだからといって、vSphere DRS で vMotion されたりはしていません。 ちなみに内部的には、ReplicaSet リソースが作成されて Pod が追加されています。 $ kubectl get pods --watch NAME                          READY   STATUS    RESTARTS   AGE demo-httpd-68979c6d58-rdz6l   0/1     Pending   0          9s demo-httpd-6b58f9f454-c26jc   1/1     Running   0          70m demo-httpd-6b58f9f454-sjxpp   1/1     Running   0          71m demo-httpd-68979c6d58-rdz6l   1/1     Running   0          9s demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m demo-httpd-68979c6d58-wb774   0/1     Pending       0          0s demo-httpd-68979c6d58-wb774   0/1     Pending       0          0s demo-httpd-68979c6d58-wb774   0/1     Pending       0          1s demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m demo-httpd-68979c6d58-wb774   0/1     Pending       0          3s demo-httpd-68979c6d58-wb774   0/1     Pending       0          4s demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m demo-httpd-68979c6d58-wb774   1/1     Running       0          9s demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m 別のワーカー ノードで、Pod が起動された状態になりました。 $ kubectl get pods -o wide NAME                          READY   STATUS    RESTARTS   AGE    IP             NODE                        NOMINATED NODE   READINESS GATES demo-httpd-68979c6d58-bvlgx   1/1     Running   0          119s   10.244.0.228   lab-wcp-esxi-43.go-lab.jp   <none>           <none> demo-httpd-68979c6d58-dhrpc   1/1     Running   0          106s   10.244.0.229   lab-wcp-esxi-42.go-lab.jp   <none>           <none> vSphere Client でも、vSphere Pod が順次追加 → 削除される様子が見られます。 最終的に vSphere Pod は 2つとなり、別の ESXi で起動されたことが確認できます。 1つめの vSphere Pod です。 もうひとつの vSphere Pod も、別の ESXi で起動されています。 vSphere Pod 起動時の配置決定では DRS が利用されています。 しかし、vCenter 7.0b 時点では、vSphere Pod の配置制御を工夫したい場合には アフィニティ ルールや DRS ではなく、Kubernetes 側の仕組みを利用するとよさそうです。 以上、vSphere Pod をアンチ アフィニティ配置してみる話でした。

通常の Kubernetes では、名前空間（Namespace）を分ければ、同名の Pod を作成できます。 今回は、ためしに vSphere with Kubernetes の 2つのスーパーバイザー名前空間でも、 あえて同名の vSphere Pod を起動してみました。 ちなみに、今回の環境は vCenter Server 7.0b です。 ソフトウェア バージョンやホスト名などは異なりますが、下記のようにラボを用意しています。 vSphere with Kubernetes ラボ環境構築。（まとめ） それではまず、 1つめのスーパーバイザー名前空間「lab-ns-01」（と対応するコンテキスト）です。 $ kubectl config get-contexts lab-ns-01 CURRENT   NAME        CLUSTER         AUTHINFO                                        NAMESPACE *         lab-ns-01   192.168.70.97   wcp:192.168.70.97:administrator@vsphere.local   lab-ns-01 Pod を「pod-01」という名前で起動します。 $ kubectl run pod-01 --image=gowatana/centos7:httpd --generator=run-pod/v1 --context=lab-ns-01 pod/pod-01 created $ kubectl get pods --context=lab-ns-01 NAME     READY   STATUS    RESTARTS   AGE pod-01   1/1     Running   0          102s vSphere Pod として起動された様子が、vSphere Client でも確認できます。 2つめのスーパーバイザー名前空間は「lab-ns-02」です。 $ kubectl config get-contexts lab-ns-02 CURRENT   NAME        CLUSTER         AUTHINFO                                        NAMESPACE           lab-ns-02   192.168.70.97   wcp:192.168.70.97:administrator@vsphere.local   lab-ns-02 この名前空間でも、Pod をあえて「pod-01」という名前で起動してみます。 （当然ながら起動できます） $ kubectl run pod-01 --image=gowatana/centos7:httpd --generator=run-pod/v1 --context=lab-ns-02 pod/pod-01 created $ kubectl get pods --context=lab-ns-02 NAME     READY   STATUS              RESTARTS   AGE pod-01   1/1     Running             0          2m53s vSphere Client でも、vSphere Pod が起動できたことが確認できます。 vSphere Pod の実体は VM です。 vSphere では、フォルダ内では同名の VM は作成できませんが・・・ 一方で、リソースプール内では、もともと同名の VM が作成可能でした。 そして「Namespaces」リソースプールの配下の「名前空間」でも、ちゃんと同名の Pod は起動できます。 従来からの vSphere の仕組みを、うまく利用しているのだなと思いました。 以上、重複する名前の vSphere Pod を起動してみる話でした。

vSphere 7.0 では、コンテンツ ライブラリに登録した「仮想マシン テンプレート」で、 バージョン管理をしやすくなりました。 vSphere Client での操作で、コンテンツ ライブラリに登録したテンプレートの 「チェックアウト」、「チェックイン」といった更新管理ができるようになっています。 ドキュメントでは下記のあたりです。 仮想マシン テンプレートの管理 今回の環境。 今回の環境は、vCenter Server 7.0b（Build 16386335）を利用しています。 コンテンツ ライブラリには「仮想マシン テンプレート」と「OVF & OVA テンプレート」が登録できますが、 ここでの対象は「仮想マシン テンプレート」の方です。 コンテンツ ライブラリ「lib-os-02」には、「ol78-min-01」という名前で、Linux VM を登録してあります。 テンプレートの実体となる仮想マシン（最新のもものは「ol78-min-01 (3)」）や、 「このテンプレートから仮想マシンをチェックアウト」ボタンが表示されています。 OVF とは異なり、「仮想マシン テンプレート」では サブスクライブしたライブラリでのコンテンツ同期はできませんが、 今回紹介するようなバージョン管理ができるようになっています。 「仮想マシンおよびテンプレート」のインベントリでも、 テンプレートに紐づく仮想マシン テンプレートの「サマリ」や「バージョン管理」タブから 同様の UI でチェックアウトができるようになっています。 古いバージョンのテンプレートには、新バージョンへのリンクがあります。 1. 仮想マシン テンプレートのチェックアウト。 ためしに、仮想マシン テンプレートを更新してみます。 テンプレートを選択して、「このテンプレートから仮想マシンをチェックアウト」をクリックします。 仮想マシン名を入力し、場所（仮想マシン フォルダ）を選択して「次へ」をクリックします。 クラスタ / リソースプール を選択して「次へ」をクリックします。 「チェックアウト後に仮想マシンをパワーオン」のチェックを入れて「完了」をクリックします。 仮想マシンが作成され「チェックアウト」された状態になりました。 パワーオン状態なので、この時点ではまだ「チェックイン」できません。 2. 仮想マシン（ゲスト OS）の更新。 起動された仮想マシンにアクセスして、ゲスト OS で何らかの更新をしておきます。 そして、仮想マシンを停止（ゲスト OS をシャットダウン）します。 ※ゲスト OS 内部からのシャットダウンでも大丈夫です。 3. 仮想マシン テンプレートへのチェックイン。 チェックアウトで作成された仮想マシンには、水色の丸印がついています。 仮想マシンを停止した状態で、「テンプレートに仮想マシンをチェックイン」をクリックます。 「仮想マシンのチェックイン」画面で、チェックイン メモを何か入力して「チェックイン」をクリックします。 仮想マシンがテンプレートに変換（仮想マシン名も変更）され、 2世代前のテンプレート（元から存在していた、前バージョンのもの）は自動削除されます。 新しく作成された仮想マシン テンプレート「ol78-min-01 (4)」でも、 「サマリ」や「バージョン管理」タブの表示が更新されています。 これで、コンテンツ ライブラリの UI （でのテンプレートの右クリック）などから、 更新されたテンプレートから、仮想マシンが新規作成できるようになります。 参考： 仮想マシン テンプレートのバージョンを戻す。 仮想マシン テンプレートを、ひとつ前のバージョンに戻すことができます。 「・・・」→「このバージョンに戻す」から実行します。 「バージョンを戻す」画面で、「メモを元に戻す」に何か入力して「元に戻す」をクリックします。 ひとつ前のバージョンの仮想マシン テンプレート「ol78-min-01 (3)」から、あらたに「ol78-min-01 (5)」が作成されます。 このように、コンテンツ ライブラリで管理される「仮想マシン テンプレート」では、 同時に 2つまでの、実体となる仮想マシンが存在することになります。 ちなみに、前バージョンのテンプレート（の仮想マシン）は、 不要になったら「バージョンの削除」メニューから削除することもできます。 この例では「ol78-min-01 (5)」ではなく、古い「ol78-min-01 (4)」の方が削除されます。 仮想マシン テンプレート更新にかかわる手順を一般化するときに便利かなと思います。 以上、コンテンツ ライブラリで仮想マシンをチェックアウト / チェックインしてみる話でした。

The error would  occur in vcetner 6.5 vcenter appliance while accessing through winSCP 1- Login to the VCSC appliance ( in my case password was expired so I had to reset the password first.) #shell # chsh –s /bin/bash root  ( run this command ) You can change the settings back to default with following command: #chsh -s /bin/appliancesh root

vSphere with Kubernetes によるスーパーバイザー クラスタで、vSphere Pod が削除できなくなることがあります。 そもそも vSphere Pod は右クリックメニューなどから削除できず、わりと悩ましい状態になります。 そこで、なぜか残ってしまった Pod を削除する方法を紹介してみます。 削除ずみの vSphere Pod が残った状態。 kubectl（kubectl delete pod ～ など）で vSphere Pod を削除すると、 下記のような状態で Pod が残ってしまうことがあります。 通常は少し待つと自動的に削除されますが、たまに 1日待っても vCenter を再起動しても削除されないことがあります。 停止された Pod が残っている様子です。 ごく稀に、起動中の Pod が残ったりもします。 kubectl では、すでに Pod が削除された状態で、 対象の名前空間では、Pod がみつかりません。 $ kubectl config current-context lab-ns-01 $ kubectl config get-contexts lab-ns-01 CURRENT   NAME        CLUSTER         AUTHINFO                                        NAMESPACE *         lab-ns-01   192.168.70.97   wcp:192.168.70.97:administrator@vsphere.local   lab-ns-01 $ kubectl get pods -n lab-ns-01 No resources found in lab-ns-01 namespace. $ スーパーバイザー クラスタの名前空間を削除すれば一緒に削除できますが、 Pod 単位での削除を試みます。 vCenter インベントリに残った vSphere Pod の削除。 まず、Pod が残った名前空間に、あえて同名の Pod「demo-centos7-httpd-6b58f9f454-2jddf」を作成します。 コンテナ イメージは何でもよいので、サイズが小さそうな busybox を利用しました。 $ kubectl run demo-centos7-httpd-6b58f9f454-2jddf --image=busybox --restart=Never pod/demo-centos7-httpd-6b58f9f454-2jddf created このとき、名前空間にはすでに同名 Pod があるため、Pod の作成は失敗します。 $ kubectl get pod NAME                                  READY   STATUS                RESTARTS   AGE demo-centos7-httpd-6b58f9f454-2jddf   0/1     PodVMCreationFailed   0          5s vSphere Client でも、Pod の作成が失敗します。 ここから、あらためて Pod を削除します。 $ kubectl delete pod demo-centos7-httpd-6b58f9f454-2jddf pod "demo-centos7-httpd-6b58f9f454-2jddf" deleted $ kubectl get pod No resources found in lab-ns-01 namespace. これで Pod「demo-centos7-httpd-6b58f9f454-2jddf」は削除されました。 同様に、もう一つの vSphere Pod「demo-centos7-httpd-68979c6d58-4l47n」も削除します。 $ kubectl run demo-centos7-httpd-68979c6d58-4l47n --image=busybox --restart=Never pod/demo-centos7-httpd-68979c6d58-4l47n created $ kubectl get pods NAME                                  READY   STATUS                RESTARTS   AGE demo-centos7-httpd-68979c6d58-4l47n   0/1     PodVMCreationFailed   0          22s $ kubectl delete pod demo-centos7-httpd-68979c6d58-4l47n pod "demo-centos7-httpd-68979c6d58-4l47n" deleted $ kubectl get pods No resources found in lab-ns-01 namespace. vSphere Client でも、削除が確認できました。 このように vSphere Pod が削除できますが、他にいい方法がないかは気になっています・・・ 以上、kubectl で削除できなかった vSphere Pod を削除してみる話でした。

vSphere の運用では、PowerCLI が利用できると便利です。 PowerCLI は PowerShell ベースのツールです。 そのため、以前は Windows が必要でしたが、最近では Linux の PowerShell でも利用でき、 Docker コンテナ イメージ（vmware/powerclicore）も用意されていたりします。 Doker Hub の PowerCLI Core コンテナ イメージ https://hub.docker.com/r/vmware/powerclicore そこで、今回は Kubernetes で PowerCLI コンテナを起動してみます。 今回の環境。 Kubernetes は、vSphere with Kubernetes によるスーパーバイザー クラスタを利用して、 コンテナは vSphere Pod として起動してみます。 スーパーバイザー クラスタの環境は下記のように構築しています。 vSphere with Kubernetes ラボ環境構築。（まとめ） kubectl では、下記のようにスーパーバイザ クラスタに login してあります。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 Kubernetes での PowerCLI の起動。 それでは、kubectl run コマンドで、Pod として起動します。 Pod の名前は「pcli01」にしています。 「-it」を指定して、そのままコンテナに接続して対話的にコマンド実行できるようにします。 vmware/powerclicore コンテナ イメージを起動します。イメージは Docker Hub からダウンロードしているので、インターネットへの接続が必要です。 kubectl run コマンドに、「--restart=Never」オプションを指定すると、Pod（Deployment リソースではなく）として起動できます。 「--rm」を指定すると、コンテナ終了と同時に Pod が自動削除されます。 Pod が起動されると、そのままコンテナの中の PowerShell プロンプトが表示されます。 $ kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm If you don't see a command prompt, try pressing enter. PowerShell 7.0.0 Copyright (c) Microsoft Corporation. All rights reserved. https://aka.ms/powershell Type 'help' to get help. PS /root> これで、PowerCLI が利用できます。 ※今回は CEIP の警告は無視しています。 PS /root> Connect-VIServer -Force -Server lab-vc-41.go-lab.jp WARNING: Please consider joining the VMware Customer Experience Improvement Program, so you can help us make PowerCLI a better product. You can join using the following command: Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true VMware's Customer Experience Improvement Program ("CEIP") provides VMware with information that enables VMware to improve its products and services, to fix problems, and to advise you on how best to deploy and use our products.  As part of the CEIP, VMware collects technical information about your organization?s use of VMware products and services on a regular basis in association with your organization?s VMware license key(s).  This information does not personally identify any individual. For more details: type "help about_ceip" to see the related help article. To disable this warning and set your preference use the following command and restart PowerShell: Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true or $false. Specify Credential Please specify server credential User: administrator@vsphere.local ★ユーザー名とパスワードを入力。 Password for user administrator@vsphere.local: ******** Name                           Port  User ----                           ----  ---- lab-vc-41.go-lab.jp            443   VSPHERE.LOCAL\Administrator PS /root> 接続した vCenter から、情報取得ができました。 ちなみに、今回はスーパーバイザー クラスタを管理している vCenter に接続しており、 VM の一覧には vSphere Pod（pcli01）も表示されています。 PS /root> Get-Cluster Name                           HAEnabled  HAFailover DrsEnabled DrsAutomationLe                                           Level                 vel ----                           ---------  ---------- ---------- --------------- wcp-cluster-41                 True       1          True       FullyAutomated PS /root> Get-VMHost Name                 ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz ----                 --------------- ---------- ------ ----------- ----------- lab-wcp-esxi-41.go-… Connected       PoweredOn       2        4322        6000 lab-wcp-esxi-42.go-… Connected       PoweredOn       2        1526        4608 lab-wcp-esxi-43.go-… Connected       PoweredOn       2        1990        4608 PS /root> Get-VM Name                 PowerState Num CPUs MemoryGB ----                 ---------- -------- -------- SupervisorControlPl… PoweredOn  2        8.000 SupervisorControlPl… PoweredOn  2        8.000 SupervisorControlPl… PoweredOn  2        8.000 pcli01               PoweredOn  1        0.500 vSphere Clinet でも、PowerCLI の vSphere Pod が起動されたことが確認できます。 PowerCLI では、vCenter Server に接続する際に DNS による名前解決が重要になります。 そこで、コンテナの中の DNS サーバ参照の設定を確認してみると、 Kubernetes の機能による DNS サーバのアドレスが指定されています。 これは、このラボの DNS サーバのアドレスではありません。 PS /root> cat /etc/resolv.conf nameserver 10.96.0.254 search sc-ns-01.svc.cluster.local svc.cluster.local cluster.local 起動した Pod は、デフォルトで「dnsPolicy: ClusterFirst」が設定されます。 これにより、Kubernetes の機能による DNS サーバで名前解決できなくても、 外部の DNS サーバで名前解決できるようになっています。 dnsPolicy については、下記が参考になります。 https://kubernetes.io/ja/docs/concepts/services-networking/dns-pod-service/  ちなみにスーパーバイザー クラスタでは、外部の DNS サーバのアドレスは、 vSphere クラスタで「ワークロード管理」を有効化する際に設定したものです。 この設定は、kubectl get pods -o yaml といったコマンドラインや、 Pod 起動時の --dry-run -o yaml オプションなどで確認することもできます。 $ kubectl run pcli01 --image=vmware/powerclicore --restart=Never --dry-run -o yaml apiVersion: v1 kind: Pod metadata:   creationTimestamp: null   labels:     run: pcli01   name: pcli01 spec:   containers:   - image: vmware/powerclicore     name: pcli01     resources: {}   dnsPolicy: ClusterFirst   restartPolicy: Never status: {} vSphere Pod の YAML は、vSphere Client でも確認できます。 vSphere Pod の「サマリ」→「メタデータ」などから、Pod の YAML を表示できます。 dnsPolicy は ClusterFirst になっています。 ちなみに、この Pod から exit すると、自動的に Pod は停止 ～ 削除されます。（--rm オプションにより） PS /root> exit pod "pcli01" deleted $ DNS サーバ設定を指定した Pod の起動。 Pod の DNS サーバ設定は、Pod 起動時に YAML で指定することもできます。 kubectl run であっても、下記のように Pod 起動時に、dnsPolicy と dnsConfig を上書きできたりします。 今回は、自宅ラボの DNS サーバのアドレスとして、192.168.1.101 と 192.168.1.102 を指定して、 見やすくなるように JSON 部分を整形してあります。 kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm --overrides=' {   "apiVersion": "v1",   "spec": {     "dnsPolicy": "None",     "dnsConfig": {       "nameservers": ["192.168.1.101", "192.168.1.102"],       "searches": ["go-lab.jp"]     }   } }' 実際に実行してみると、下記のようになります。 起動後の Pod では、/etc/resolv.conf ファイルを確認すると、DNS サーバの設定が変更できています。 $ kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm --overrides=' > { >   "apiVersion": "v1", >   "spec": { >     "dnsPolicy": "None", >     "dnsConfig": { >       "nameservers": ["192.168.1.101", "192.168.1.102"], >       "searches": ["go-lab.jp"] >     } >   } > }' If you don't see a command prompt, try pressing enter. PowerShell 7.0.0 Copyright (c) Microsoft Corporation. All rights reserved. https://aka.ms/powershell Type 'help' to get help. PS /root> cat /etc/resolv.conf nameserver 192.168.1.101 nameserver 192.168.1.102 search go-lab.jp PS /root> vSphere Client で表示できる  Pod の YAML でも、同様に DNS 設定が変更できています。 vSphere with Kubernetes の動作確認やデモなどでも利用できそうかなと思います。 また、スーパーバイザー クラスタ特有の機能を利用するものではないので、 Kubernetes があればどこでも同じように PowerCLI コンテナが起動できるはず・・・ 以上、Kubernetes で PowerCLI を起動してみる話でした。

vSphere 7.0 の新機能、vSphere with Kubernetes の自宅ラボ環境を構築した様子を伝えします。 vSphere with Kubernetes では、2種類の Kubernetes クラスタが利用できるようになります。 Supervisor Cluster vSphere クラスタで「ワークロード管理」が有効化され、kubernetes の機能が追加されたもの。 vSphere 上で Kubernetes リソースを稼働させることができ、 「名前空間」や vSphere Pod などが作成できるようになる。 Tanzu Kubernetes Cluster スーパーバイザー クラスタの「名前空間」に、Tanzu Kubernetes Grid を利用して作成されるもの。 Kubernetes としてはわりと普通な「コンテナ ホストの VM」によるクラスタ。 下記の流れで、vSphere 環境に 2種類の Kubernetes クラスタを作成していきます。 はじめに。（今回のネステッド環境の紹介など） vSphere with Kubernetes ラボ環境構築。Part-01: 環境説明編 vSphere / データストアまわりの準備。 vSphere with Kubernetes ラボ環境構築。Part-02: vSphere 事前準備編 vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編 NSX-T 関連の準備。 vSphere with Kubernetes ラボ環境構築。Part-04: NSX Manager デプロイ編 vSphere with Kubernetes ラボ環境構築。Part-05: NSX Manager 設定編 vSphere with Kubernetes ラボ環境構築。Part-06: ホスト トランスポート ノード準備編 vSphere with Kubernetes ラボ環境構築。Part-07: NSX Edge デプロイ編 vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編 vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編 vSphere クラスタでの「ワークロード管理」有効化。（Supervisor Cluster の作成） vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 Tanzu Kubernetes Cluster の作成。 vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編 vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編 vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編 vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編 それでは、1回目はこちら・・・ vSphere with Kubernetes ラボ環境構築。Part-01: 環境説明編

To get out of this situation do the following: Restart and turn off Secure Boot in the UEFI firmware and boot the host with Secure Boot turned off. When booted, log into the host and remove the offending VIB and shutdown. ( which is on PSOD screen) Re-enable Secure Boot and restart the host and the system should boot normally.

前回は、Tanzu Kubernetes Cluster に接続して、Pod を単独で起動してみました。 前回の投稿はこちら。 vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編 しかし、Kubernetes で Pod を起動する場合には、 Deployment や StatefulSet といったリソースを利用することが一般的だと思うので、今回は Deployment リソースから Pod を作成してみます。 なお、今回の一連の手順では Kubernetes の Namespace を省略しており、「default」Namespace 作業対象にしています。 Deployment 作成を試す。（PSP エラーになるパターン） まず、ほぼデフォルト状態の Tanzu Kubernetes Cluster に、Deployment を作成してみます。 ただし、Tanzu Kubernetes Cluster ではアドミッション コントロールと呼ばれる機能が有効化されており、 この時点での Pod 作成は失敗してしまいます。 前回の投稿 でも実施したように、kubectl で Tanzu Kubernetes Cluster にログインして、 Context を切り替えておきます。 $ kubectl vsphere login --insecure-skip-tls-verify --server lab-wcp-01.go-lab.jp --tanzu-kubernetes-cluster-namespace lab-ns-02 --tanzu-kubernetes-cluster-name tkg-cluster-01 $ kubectl config use-context tkg-cluster-01 Nginx コンテナの Pod を、Deployment から起動する YAML ファイル（nginx-deploy.yml · GitHub​）を用意します。 $ cat nginx-deploy.yml --- kind: Deployment apiVersion: apps/v1 metadata:   name: tkc-demo spec:   replicas: 2   selector:     matchLabels:       app: tkc-demo   template:     metadata:       labels:         app: tkc-demo     spec:       containers:       - name: nginx-container         image: nginx         ports:         - containerPort: 80           protocol: TCP Deployment を作成します。 $ kubectl apply -f nginx-deploy.yml deployment.apps/tkc-demo created Deployment では、Deployment → ReplicaSet → Pod といった順でリソースが作成されますが、 待っても Pod が起動されません。 $ kubectl get all NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE service/kubernetes   ClusterIP   198.48.0.1   <none>        443/TCP    17d service/supervisor   ClusterIP   None         <none>        6443/TCP   17d NAME                       READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/tkc-demo   0/2     0            0           61s NAME                                 DESIRED   CURRENT   READY   AGE replicaset.apps/tkc-demo-659dff8bd   2         0         0       61s これは、ReplicaSet を作成する時点で PodSecurityPolicy（pod security policy）に関係するエラーが発生しています。 $ kubectl describe replicasets tkc-demo-659dff8bd Name:           tkc-demo-659dff8bd Namespace:      default Selector:       app=tkc-demo,pod-template-hash=659dff8bd Labels:         app=tkc-demo                 pod-template-hash=659dff8bd Annotations:    deployment.kubernetes.io/desired-replicas: 2                 deployment.kubernetes.io/max-replicas: 3                 deployment.kubernetes.io/revision: 1 Controlled By:  Deployment/tkc-demo Replicas:       0 current / 2 desired Pods Status:    0 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template:   Labels:  app=tkc-demo            pod-template-hash=659dff8bd   Containers:    nginx-container:     Image:        nginx     Port:         80/TCP     Host Port:    0/TCP     Environment:  <none>     Mounts:       <none>   Volumes:        <none> Conditions:   Type             Status  Reason   ----             ------  ------   ReplicaFailure   True    FailedCreate Events:   Type     Reason        Age                  From                   Message   ----     ------        ----                 ----                   -------   Warning  FailedCreate  39s (x15 over 2m1s)  replicaset-controller  Error creating: pods "tkc-demo-659dff8bd-" is forbidden: unable to validate against any pod security policy: [] エラーになった Deployment は、ひとまず削除しておきます。 $ kubectl delete -f nginx-deploy.yml deployment.apps "tkc-demo" deleted それでは、PodSecurityPolicy を使用してみます。 ドキュメントは下記のあたりです。 Tanzu Kubernetesクラスタでのポッド セキュリティ ポリシーの使用 PodSecurityPolicy（PSP）の確認。 それでは、Deployment から Pod が起動できるように、 PodSecurityPolicy（PSP）と Kubernetes のサービスアカウント（ServiceAccount）をひもづける RoleBindig を作成しておきます。 Tanzu Kubernetes Cluster には、デフォルトで PSP が2つ用意されており、 vmware-system-privileged と vmware-system-restricted が作成されています。 $ kubectl get podsecuritypolicies NAME                       PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES vmware-system-privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            * vmware-system-restricted   false          RunAsAny   MustRunAsNonRoot   MustRunAs   MustRunAs   false            configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim 今回は root ユーザとして Pod を起動できる vmware-system-privileged を指定します。 ちなみに、もう一つの vmware-system-restricted が指定されている状態で root で Pod 起動しようとすると、 Pod のイベントとして、下記のようなエラーが発生します。 Error: container has runAsNonRoot and image will run as root RoleBinding の作成。 PSP を指定した RoleBinding を作成します。 下記のような YAML ファイル（tkc-rb-privileged.yml · GitHub​）を用意しておきます。 RoleBinding の名前は rb-vmware-system-privileged を指定。 roleRef には、ClusterRole「psp:vmware-system-privileged」を指定。 subjects には system:serviceaccounts Group（すべてのサービスアカウントが含まれる）を指定。 $ cat tkc-rb-privileged.yml --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: rb-vmware-system-privileged roleRef:   kind: ClusterRole   name: psp:vmware-system-privileged   apiGroup: rbac.authorization.k8s.io subjects: - kind: Group   name: system:serviceaccounts   apiGroup: rbac.authorization.k8s.io roleRef で指定している ClusterRole「psp:vmware-system-privileged」では、 resourceNames に PSP「vmware-system-privileged」が指定されています。 この ClusterRole も、デフォルトで作成されているものです。 $ kubectl get clusterrole psp:vmware-system-privileged -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   creationTimestamp: "2020-07-30T03:36:50Z"   name: psp:vmware-system-privileged   resourceVersion: "480"   selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/psp%3Avmware-system-privileged   uid: 391f6160-44c8-4bcc-b776-184b17dce8d6 rules: - apiGroups:   - policy   resourceNames:   - vmware-system-privileged   resources:   - podsecuritypolicies   verbs:   - use それでは、RoleBindig を作成します。 $ kubectl apply -f tkc-rb-privileged.yml rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created Deployment 作成を試す。（リトライ） あらためて、Deployment を作成します。 $ kubectl apply -f nginx-deploy.yml deployment.apps/tkc-demo created 今度は、Deployment から Pod が起動されました。 $ kubectl get all NAME                            READY   STATUS    RESTARTS   AGE pod/tkc-demo-6b459d8b8d-8hfbb   1/1     Running   0          10s pod/tkc-demo-6b459d8b8d-q7cq5   1/1     Running   0          10s NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE service/kubernetes   ClusterIP   198.48.0.1   <none>        443/TCP    17d service/supervisor   ClusterIP   None         <none>        6443/TCP   17d NAME                       READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/tkc-demo   2/2     2            2           11s NAME                                  DESIRED   CURRENT   READY   AGE replicaset.apps/tkc-demo-6b459d8b8d   2         2         2       11s これで、アドミッション コントロールなしの Kubernetes クラスタと同様にワークロード展開できるはずです。 また、今回は RoleBindig を作成しましたが、デモ環境などであれば ClusterRoleBinding でクラスタ全体の設定にしてもよいと思います。 以上、vSphere with Kubernetes と Tanzu Kubernetes Cluster のラボ環境構築でした。

本ブログは3回にわたって執筆している「vCenterとSDDC ManagerのDBをローカルPCにインポートする方法」の第三回目です。 前回と前々回の記事はこちらを参照してください。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】 第三回の今回は一回目で取得したDBダンプを、二回目で構築したローカルPCのPostgreSQL DMBSにインポートします。 DB Dumpファイルの下処理 SDDC ManagerのDBダンプ（postgres-db-dump.gz）は、解凍してテキスト形式（postgres-db-dump）のファイルにさせしてしまえばそれでOKです。 それ自体で完結していますので特に何もする必要はありません。 問題はvCenterのDBダンプのほうです。vCenterのVCDBはTablespaceと呼ばれる機能で、DBの一部を別の場所に保存しています。 （この辺りは私の知識ではよくわかってませんが、、） 第一回の記事で、/storage/seat/vpostgres/* の部分をまとめてTarで固めて圧縮しましたが、その部分がTablespaceにあたります。 TableSpaceの場所はDB Dump内にフルパスで記載されてなければならず、VCSAから採取したDB Dumpには当然、/storage/seat/vpostgres/のままになっています。 ローカルのDMBSにインポートする前にこのパスを修正する必要があります。 1．vCenter DB Dumpの下準備その①【解凍する】 何はともあれまずは解凍しましょう。話はそれからです。 ローカルPCに転送したtgz形式のファイルを任意の解凍ツールで解凍してください。 以下のファイルが含まれているはずです。 vcdb_dump alarmtblspディレクトリ eventtblspディレクトリ hs1tblspディレクトリ hs2tblspディレクトリ hs3tblspディレクトリ hs4tblspディレクトリ tasktblspディレクトリ 2．vcdb_dumpファイルをテキストエディタで開いて編集する 次にvcdb_dumpファイルをテキストエディタで開きます。 ファイル自体がとても大きいため、Notepadではスペックが足りません。 ※大容量のテキストファイルを開けるエディタを利用してください。もしくは転送前のVCSAにてviなどで編集してから転送してください。（筆者は秀丸を利用してます） 編集するのは以下のTablespaceについての項目です。 見て分かる通り、TablespaceのロケーションのPathがVCSA内のロケーションにままです。 これを編集して、ローカルPCのロケーション（絶対パス）に書き直します。 以下は書き直した際の例です。書き直す際は実際に実施している環境のPathに置き換えてください。 書き換えが終わったらSaveしてDB ダンプ側の対処は終了です。 PostgreSQL側の下準備 次にPostgreSQL側の事前準備を説明します。 PostgreSQLにpgadminで接続する場合は特に準備は不要なのですが、psqlで接続する場合は事前に対処が必要となります。 psqlはPostgreSQL DBMSを起動した際にすでにpsqlで接続済みの状態となっていますが、このCLIは利用することができません。 まず、psqlのCLIからはDBをインポートできませんし、インポート後にいろいろやっているとすぐにエラーになって使えないことがわかります。 エラーになる理由は私にはわかりませんが、とりあえず、別途psqlを別途起動し、改めて接続すれば問題ありません。 しかしながら改めて接続した場合でも、いくつか問題が発生するため事前に下準備をする必要があります。 まずはPowershellを起動し、バッファサイズを最大にします。デフォルトのバッファサイズだと少なすぎて表示が切れてしまうからです。 次に、起動したPowershellで、PostgreSQL DBMSをインストールしたフォルダのどこかにあるpsql.exeを実行すれば、DBMSに接続できるのですが、このままだと文字コードの問題が発生します。 細かくは説明しませんが、日本語のWindows環境のデフォルトはShift JISなのに対し、DB Dumpの中身はUTF-8なので表示する際に問題が発生するのです。 なので、Powershellの表示文字コードとpsqlのデフォルトの文字コードを両方ともUTF-8にする必要があります。 何はともあれPowershellを起動して以下の2つのコマンドを実行すればOKです。 > chcp 65001 > $env:PGCLIENTENCODING = "UTF8" 1つ目のコマンドはPowershellの文字コードをUTF8にするためのものです。 2つ目のコマンドはpsqlの文字コードをUTF8にするためのものです。 このコマンドを実行したら、一度postgreSQL DBMSに接続してください。以下のコマンドで接続できます。 > psql.exe -U postgres 接続したら以下のコマンドをうってエンコードがUTF8になっていることを確認します。 postgres=# SHOW client_encoding; 一連の流れの例は以下です。 ※chcp 65001を実行した直後にPowershellがRefreshされるため、このコマンドの実行行は表示されてません Active code page: 65001 PS C:\Users\administrator\Downloads\vcdb_dump> $env:PGCLIENTENCODING = "UTF8" PS C:\Users\administrator\Downloads\vcdb_dump> PS C:\Users\administrator\Downloads\vcdb_dump> PS C:\Users\administrator\Downloads\vcdb_dump> PS C:\Users\administrator\Downloads\vcdb_dump> C:\Users\administrator\Downloads\PostgreSQLPortable\App\PgSQL\bin\psql.exe -U postgres psql (10.4) WARNING: Console code page (65001) differs from Windows code page (932)          8-bit characters might not work correctly. See psql reference          page "Notes for Windows users" for details. Type "help" for help. postgres=# SHOW client_encoding; client_encoding ----------------- UTF8 (1 row) postgres=# DB Dumpのインポートを実行 ここまで確認出来たらいったんpsqlからExitします。Exit方法は\qです。 Exitしたら以下のコマンドで、postgreSQL DBMSにDBをインポートします。 > psql.exe -U postgres -f .\vcdb_dump ※-f オプションでdb dumpのファイルを指定しています。インポートするdb dumpは一つだけを想定しています。別のdb dumpをインポートしたい場合は後述の手順でいったんDBをResetし、再度イニシャライズしてからインポートします。 インポート中にエラーが出ないことを確認してください。Tablespaceのパスが間違っていた場合は、エラーが表示されます。 ※「role "postgres" already exsits 」 というエラーが出るのは問題ありません。それ以外のエラーがでたら内容を確認してください。 問題なく完了したら改めて、> psql.exe -U postgres で接続してください。 \l （￥マークと小文字のエル）でDatabaseの一覧を表示すると、インポートされたデータベースが表示されていると思います。 pgadminのGUIからも同様に確認できるはずです。（自動で更新されない場合はrefreshして下さい。） DMBSの再イニシャライズ方法（ポータブル版のみ） 上記まででDB ダンプのインポートは完了なのですが、別の環境のDBをインポートしようとすると名前がかぶったりしてしまうのでうまくインポートできないはずです。 個別に削除してもいいのですが、ゴミがすべて手動で消すのは面倒なので、再度イニシャライズをしてしまうのが良いです。 ポータブル版の場合、再度イニシャライズするのは非常に簡単です。 ポータブル版のPostgreSQLをインストールしたフォルダにDataというフォルダがあると思います。 Dataフォルダ配下にさらにdata というフォルダがあります。 このdata というフォルダを丸ごと削除して、DMBSを再度起動すればOKです。 まずは既存のPosgreSQL DMBSを終了します。終了方法は起動した際のコマンドプロンプトのpsqlを\qでExitすればOKです。 次の上記のdataフォルダを丸ごと消してください。 再度PostgreSQLを起動すれば、DBがイニシャライズされ初期状態になります。（それまでに書き込んだ処理はすべて消えます。） これでDBMSが初期状態に戻ってますので、きれいな状態で再度あたらしいDB Dumpをインポート可能です。 いかがでしたでしょうか。 三回に分けて紹介したDB Dumpのインポートはこれで終了です。 実際には閲覧をするためにはpsqlの使い方やSQL文の知識が必要になりますが、この記事ではカバーしません。 Internet上にわかりやすい記事があると思うので探してみてください。

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster を作成しました。 前回はこちら。 vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編 今回は、作成した Tanzu Kubernetes Cluster に接続して、Pod を起動してみます。 Tanzu Kubernetes Cluster は作成ずみです。 ※なお、前回の手順で作成していますが、再作成しているのでノードの名前が異なります。 Tanzu Kubernetes Cluster への接続。 kubectl で、Tanzu Kubernetes Cluster に接続します。 vSphere 専用の kubectl の準備については、下記の投稿のようにしています。 vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編 login では、Supervisor Cluster に接続する場合のコマンドラインに、 追加で下記のオプションを指定しています。 --tanzu-kubernetes-cluster-namespace=lab-ns-02 --tanzu-kubernetes-cluster-name=tkg-cluster-01 Tanzu Kubernetes Cluster の名前は、名前空間ごとに一意になるので、 「--tanzu-kubernetes-cluster-name」だけでなく、 名前空間の名前「--tanzu-kubernetes-cluster-namespace」も指定する必要があります。 $ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33 --tanzu-kubernetes-cluster-namespace=lab-ns-02 --tanzu-kubernetes-cluster-name=tkg-cluster-01 Username: administrator@vsphere.local Password: ★パスワード入力 Logged in successfully. You have access to the following contexts:    192.168.70.33    lab-ns-01    lab-ns-02    tkg-cluster-01 If the context you wish to use is not in this list, you may need to try logging in again later, or contact your cluster administrator. To change context, use `kubectl config use-context <workload name>` $ Kubernetes クラスタを構成するノードの確認。 context  を明示的に指定して get nodes でノードの確認をしてみます。 Tanzu Kubernetes Cluster では、下記のように、デプロイされた VM によって、 Supervisor Cluster とは別の Kubernetes クラスタが構成されていることが分かります。 $ kubectl --context tkg-cluster-01 get nodes NAME                                            STATUS   ROLES    AGE   VERSION tkg-cluster-01-control-plane-5w6vn              Ready    master   13h   v1.16.8+vmware.1 tkg-cluster-01-control-plane-p89lb              Ready    master   12h   v1.16.8+vmware.1 tkg-cluster-01-control-plane-phd6l              Ready    master   12h   v1.16.8+vmware.1 tkg-cluster-01-workers-l6qtc-586578bd88-5d7kh   Ready    <none>   12h   v1.16.8+vmware.1 tkg-cluster-01-workers-l6qtc-586578bd88-czrpg   Ready    <none>   12h   v1.16.8+vmware.1 tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   Ready    <none>   12h   v1.16.8+vmware.1 あらためて、Tanzu Kubernetes Cluster（tkg-cluster-01）の外側の context（lab-ns-02 名前空間と同名）を指定して、 Kubernetes ノードを確認しておきます。 こちらは、ESXi と Supervisor Control Plane VM で、Kubernetes のクラスタが構成されています。 $ kubectl --context lab-ns-02 get nodes NAME                               STATUS   ROLES    AGE   VERSION 422c6912a62eabbf0a45c417405308c9   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69 422c9d9222c60e5328cdc12a543c099a   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69 422cfbc654627c47880a2ec7ae144424   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69 lab-wcp-esxi-031.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b lab-wcp-esxi-032.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b lab-wcp-esxi-033.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b Tanzu Kubernetes Cluster での Pod 起動。 以前に vSphere Pod を起動した YAML ファイルで、 tkg-cluster-01 上に Pod を起動してみます。 YAML ファイルの内容は、下記のようになっています。 $ cat nginx-pod.yml --- kind: Pod apiVersion: v1 metadata:   name: nginx-pod   labels:     app: wcp-demo spec:   containers:   - image: nginx     name: nginx-container kubectl で操作する context を tkg-cluster-01 に切り替えます。 $ kubectl config use-context tkg-cluster-01 Switched to context "tkg-cluster-01". それでは、Pod を起動します。 $ kubectl apply -f nginx-pod.yml pod/nginx-pod created tkg-cluster-01 クラスタのノード（tkg-cluster-01-workers-～）で起動されました。 $ kubectl get pods -o wide NAME        READY   STATUS    RESTARTS   AGE   IP            NODE                                            NOMINATED NODE   READINESS GATES nginx-pod   1/1     Running   0          40s   192.0.175.2   tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   <none>           <none> 一方、vSphere Client で確認すると、（vSphere Pod の場合ような）Pod の確認はできません。 vSphere Pod の場合には、インベントリや下記の赤枠のあたりで、起動された Pod が表示されていました。 しかし、Tanzu Kubernetes Cluster の Pod（そして他の Kubernete リソースも）は、 この「コア Kubernetes」の画面には表示されません。 これは、Pod が VM（この環境では、「tkg-cluster-01-workers-～」）の内部で起動されているためです。 vSphere Pod は、Pod が特殊な VM として作成されるので vSphere Client での視認性がよかったのですが、 Tanzu Kubernetes Cluster では、よくある「Docker をインストールした VM」と同様、 Pod がコンテナホストになる VM の内部で起動されるので、 特に「vSphere ならではの見やすさ」はありません。 そこで、リソースの確認には Octant（https://github.com/vmware-tanzu/octant）などの Kubernetes 可視化ツールがあると便利です。 まだ続きそう。 vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDB Dumpを、ローカルのPostgreSQL DBMSにインポートする手順の第二回です。 本記事は以下の記事の続きに当たります vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBダンプ取得方法】 また次回の記事は以下です。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】 第一回の記事では、インポートするDBのDump取得を説明しました。 今回の記事ではローカルPC（Windows PC）にPostgreSQLをInstallする方法を説明します。 PostgreSQLをWindows PCにどのように構築するか Install自体は難しい作業ではありません。ググればいくらでも手順紹介記事が出てくると思いますし、Installerの入手もたやすいです。 ただし、目的ではDBの一般的な使い方とは異なり、あくまでもDumpされたDBの静止点を閲覧するためだけの用途になります。 そのため、ふつうにInstallするよりも、簡単に削除やResetや再構築が可能な環境となることが望ましいです。 PostgreSQLに限らず、アプリケーションを普通にIntallしてしまうと、レジストリや環境変数などがいじられてしまい、アンインストールしたとしても残滓が完全に消しきれない場合などもあります。なによりInstallすること自体にちょっと懸念がある場合も考えられます。 そこで、今回はPostgreSQLのポータブル版を利用することにしました。 ポータブル版であればレジストリや環境変数などに依存せず、インストール場所を指定し、実行ファイルを実行するだけで利用可能になります。 USBメモリなどにインストールして、持ち運び可能なDBにすることもできますし、削除やResetがしたいくなった場合はInstall フォルダを削除するだけでOKです。 もちろん、通常インストーラでインストールしても問題ありません。 この記事では通常のインストーラでのインストール方法は説明しませんので、そちらを実施される場合はググっていただければ記事がたくさん出てくると思います。 通常手順でInstallされる場合は、以下の記事の内容は必要ありませんので、第三回にスキップしてください。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】 ポータブル版のPostgreSQLをダウンロードする 本記事ではあえてダウンロード先のURLを示しません。 https://www.postgresql.org/download/ ではポータブル版が公開されていなかったからです。 ググればPortable 版のPostgreSQLのダウンロードリンクが容易に見つかるとは思いますが、安全性については各自の責任でお願いいたします。 またダウンロードするPostgreSQLのVersionについては、目的とする環境と同じか、最も近いものが良いと思います。 ポータブル版をInstallする ダウンロードする際にZipやtar.gzなどもあると思いますが、paf.exe 形式のものがあればこれを利用するのが一番容易だと思います。 こちらの実行ファイルをダウンロードして実行すればWizardが現れますので、ダウンロード先のフォルダを選択すれば解凍してすぐに使えるようになります。 ポータブル版を起動する ポータブル版のインストールしたフォルダに実行ファイルがありますのでそちらを起動してください。 起動すると自動的にDBのイニシャライズが開始されて、 Initialising database for first use, please wait... といったメッセージがひょうじされます。数分とたたずに利用可能な状態になります。 以下のようなメッセージが出てpostgres=#と出れば完了しています。 'postgres' connected on port 5432. Type \q to quit and shutdown the server. psql (10.4) WARNING: Console code page (1252) differs from Windows code page (932)          8-bit characters might not work correctly. See psql reference          page "Notes for Windows users" for details. Type "help" for help. postgres=# 試しに \l と入力して、イニシャライズ直後のDBのリストを見てみましょう。 ※\l は￥マーク（バックスラッシュ）と、アルファベット小文字のL（エル）です。 postgres=# \l                              List of databases    Name    |  Owner   | Encoding | Collate | Ctype |   Access privileges -----------+----------+----------+---------+-------+----------------------- postgres  | postgres | UTF8     | C       | C     | template0 | postgres | UTF8     | C       | C     | =c/postgres          +            |          |          |         |       | postgres=CTc/postgres template1 | postgres | UTF8     | C       | C     | =c/postgres          +            |          |          |         |       | postgres=CTc/postgres (3 rows) postgres=# こんな感じになっているはずです。 DB管理ツールをInstallする 通常PostgreSQLをInstallするとpgadminという管理用GUIも一緒にInstallされますがポータブル版にはpsqlのコマンドラインしかInstallされません。 そのため、別途pgadminをInstallすることをお勧めします。 pgadminはGUIでDBを管理したり閲覧したりできるツールなのでSQL文が苦手な人だけでなく、DBの構造を俯瞰したり、ちょろっとDB内の値をいじりたい場合などに便利です。 pgadminは以下からダウンロード可能です。 https://www.pgadmin.org/ ↑のサイトのダウンロードページからWindows用のInstallerを選んでInstallすればOKです。特に難しい点はないので一直線の作業です。 pgadminを起動してDBに接続する インストールしたpgadminを起動すると、ブラウザが起動して自動的にローカルのpgadminのプロセスに接続されます。 ↑のような画面がでれば成功です。 次に、左側の枠内のあるServersのところを右クリックしてCreate > Server...を選びましょう 設定ウィザードが出るので、General タブのNameの項目に任意の名前を入れましょう。 次にConnectionタブのHostのところにlocalhostと入力して、残りはすべてデフォルトのままSaveボタンを押してください。 Saveが完了すると左側の枠に表示が現れます。 展開するとDB内の構造や中身の情報を見ることができます。 ためしにDatabaseを一つ追加してみましょう。 Databasesのところを右クリックしてCreate->Database....を選んでください。 GeneralタブのDatabaseに任意の名前を入れて、Saveして下さい。 Saveが完了すると新しいDatabaseが現れます。 PSQLのコマンドでも作成したDatabaseを確認してみましょう。 先ほどの出力と比べるとtestdbがリストに追加されたことがわかります。 pgadminでは、DBに対する様々な操作が可能ですが、その他の操作や閲覧方法については、以下の外部記事がとても分かりやすかったのでこちらをご参考にしていただければと思います。 https://itsakura.com/pgadmin4-db-create pgadminの停止方法 pgadminはちょくちょく動作がおかしくなることがあります。 そういう場合はpgadminを再起動すればよいです。 タスクトレイにpgadminの象さんのマークがあるので、それを右クリックしてShutdown Serverを選んで停止し、改めて起動してください。 今回はPostgreSQL DBMSのInstallとGUI管理ツールであるpgadminを紹介しました。 次回では実際にDumpしたDBをインポートして、内容を確認する作業を説明します。 vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】