Skip navigation
2020

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 が起動されたことが確認できます。

k8s-powercli-01.png

 

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 を表示できます。

k8s-powercli-02.png

 

dnsPolicy は ClusterFirst になっています。

k8s-powercli-03.png

 

ちなみに、この 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 設定が変更できています。

k8s-powercli-04.png

 

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」によるクラスタ。

wcp-00-k8s-image.png

 

下記の流れで、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: 環境説明編

前回は、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 のラボ環境構築でした。