Skip navigation

Blog Posts

Total : 4,586

Blog Posts

1 2 Previous Next

I suspect many of you may have stumbled upon this post because of the latest announcement from Apple on switching to APNS over HTTP/2 by November 2020.

Upgrade Workspace ONE UEM before November 2020 to support Apple Push Notifications over HTTP/2 (78976)

Quite a while ago, I wrote a series of posts on upgrading the on-premises environment.

SaaS-based customers, fortunately, have an advantage over on-premises customers that the core components (database, device services, and console) are upgraded by the operation team at VMware resulting in significant time-saving. However, you are still responsible for upgrading the auxiliary components (AirWatch Cloud Connector, Secure Email Gateway, etc.) manually.Per my VMware Support Account Manager (SAM) on whether to upgrade our Secure Email Gateway along with our console upgrade:

  • SEG applications are generally compatible with all current versions of UEM
  • UEM v2005+ and SEG 2.10 + are absolutely compatible
  • There is NO official documentation on SEG/UEM interoperability

The goal of this post is to show you the steps required to upgrade your dedicated SaaS to a newer version. For more information, feel free to check out the link below from VMware.

Steps

Similar to upgrading the on-premises environment, first make sure to review the release notes of the version you wish to upgrade to.

Once you confirm the desired version you wish to upgrade to, log onto https://support.workspaceone.com to schedule the upgrade under My Workspace ONE -> My Company. Click on the link Schedule an upgrade time to begin.

1 (1).jpg

Depending on the version you are upgrading from, you may see more or fewer options after clicking on the drop-down menu.

3.jpg

You will then need to pick a timeslot for the upgrade anywhere between 1 am to 6 pm with 4 hours minimum for the upgrade.

4.jpg

The last step is to click YES, THIS IS WHAT I WANT button to confirm your request.

5.jpg

Soon after, you will see the prompt below and receive the ticket info via email.

6.jpg

You can also view the details of the ticket from your ticket portal.

dsaasupgrade10.jpg

You do have the option to reschedule or even cancel the upgrade later on from the same web portal as needed.

2 (1).jpg

Once the upgrade begins for your environment, in the past you would receive an email notification via the same ticket. The same goes when the upgrade completes. Unfortunately, VMware upgraded its internal system so now email notification is no longer generated.

In the web portal, you will also see updates similar to the below during and after the upgrade.

saasupgrade1.jpg

saasupgrade2.jpg

The more I adapt to the SaaS model of AirWatch, the more I appreciate the time I now have to offer more values to my customers. Sure I miss tweaking the servers for optimal performance or designing the high availability/disaster discovery setup across multiple sites. At the same time, I no longer worry about critical server/data backup or the need to restart any essential services on these servers. The main benefits of keeping the infrastructure on-premises, in my opinion, are total control and security. The pandemic of 2020 forces businesses of all sizes to be more adaptable to both planned and unplanned changes. Going to the 'cloud' appears to be the most feasible solution.

VMware製品の調査をしていると、製品が内部に持つ管理DBの中身を見ることがあります。

管理DBの中身を見る方法は、実機で直接DBに接続してSQLコマンドをたたく方法と、Dumpされたテキストファイルを見る方法がありますが、

このブログでは3回に分けてDumpされたDBをローカルのPostgreSQLにインポートして、ローカルで調査する方法を紹介したいと思います。

第一回はSDDC ManagerとvCenterの内部管理DBのDump方法について紹介します。

 

※筆者はPostgreSQLに関する知識は素人に毛が生えたレベルですので不正確な部分についてご容赦ください。また、DB Dumpなどの方法についてはVMwareから提供されている方法を正としていただき、本ブログはあくまでも参考情報としてご利用ください。

 

第2回、第3回の記事は以下です。

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【DBをインポートして閲覧する】

 

 

全体の流れを確認

DB Dumpの取得方法を説明する前に、3回にわたる今回の記事の流れを説明します。

ゴールはVCSAとSDDC ManagerのDBの中身をローカルPCにInstall したPostgreSQL DBMSで閲覧することです。

DBの情報をローカルにコピーする必要があるため、DBの中身をDumpし、それをインポートする流れになります。

そのため、第一回では対象のDBのDumpを取得する方法を説明します。

第二回では実際にDB DumpをインポートするPostgreSQL DBをWindows PCにInstallする手順を示します。

第三回では、DB Dumpを実際にインポートする手順と注意事項などについて説明します。

 

 

SDDC ManagerのDBダンプ取得方法

SDDC Managerの管理DBのDump方法は非常に簡単です。

SDDC Managerのログバンドルを取得するとその中に含まれています。

SDDC Managerはsos utilityで取得できますが、実行の際に--sddc-manager-logs オプションをつけることでSDDC Managerのログバンドルを明示的に指定して取得可能です。

sos utilityを用いたログ採取については下記もご参考ください。

Cloud Foundation システムのログの収集

 

ログバンドルの中にpostgres-db-dumpというファイルがありますので、こちらがDB Dumpに相当します。

 

 

VCDB (vCenter内部管理DB)のダンプ取得方法

こちらについては、VMwareの公式情報が見つからなかったのであくまでもPostgreSQL観点での実施方法になります。

なお、今回の検証で利用しているのは、vCenter Server Applianceの6.7.0-15132721です。

 

0. VCSAのサービスを停止

DB dumpを取得する前に、VCSAのサービスを停止しましょう。

以下のVMware KBを参考にしてください。。

https://kb.vmware.com/s/article/2109887?lang=ja

 

1. postgres ユーザのパスワードを確認する

VCSA内のPostgreSQL DBのpostgres ユーザのパスワードを確認します。

パスワードは.pgpassファイルに書かれており、以下のコマンドで中身を確認できます。

# cat /root/.pgpass

 

2. postgreSQL DBのDumpを取得する

パスワードを確認したらDB Dumpを取得します。

DBのDumpはサイズが大きくなることが想定されるのであらかじめ、容量に余裕のある場所に生成するようにします。

本記事では/storage/core 配下に保存することにします。

/storage/coreはデフォルトで50GBが割り当てられており、障害が発生しない限りほとんど空いてます。

#  cd /storage/core/

 

次にpg_dumpallコマンドでダンプを取得します。以下のコマンドを実行するだけでOKです。

#  pg_dumpall -U postgres > vcdb_dump

 

ファイル名はなんでもいいです。

コマンドを実行するとパスワードが求められますので、1.のステップで確認したパスワードを入力してください。

パスワードを間違えるとエラーメッセージが出ますが、何も出ずにプロンプトが返れば成功です。

 

3. TableSpaceのファイルもまとめて.tgzに固める

VCDBの一部は別の場所に保存されているのでそちらも採取しておく必要があります。

2.のステップで取得したDumpファイルと合わせてtarで固めて圧縮し、転送しやすくしましょう。

以下のコマンドで十分です。

# tar cvzf vcdb_dump.tgz vcdb_dump /storage/seat/vpostgres/*

 

vcdb_dump.tgz がカレントディレクトリ(/storage/core)に生成されているはずなので、これをローカルのPCに転送しましょう。

 

4. VCSAのサービス起動

DB Dump採取前に停止したサービスは忘れずに起動してください。

 

 

今回は、vCenterとSDDC Managerの内部管理用PostgreSQL DBMSのDump方法について紹介しました。

次回はローカルPCにPostgreSQL DBMSをインストールする方法を紹介します。

 

vCenterとSDDC ManagerのDBをローカルPCにインポートする方法【PostgreSQLのインストール】

ThejasKV Novice

test blog in MyVirtualWorld

Posted by ThejasKV Jun 11, 2020

checking

Symptoms

 

After upgrading the operating system where VMware componenets are installed, you experience these symptoms:

 

  • You are unable to start the VMware VirtualCenter Server, VMware VirtualCenter Management Webservices, or VMware vSphere Web Client service
  • Starting a service fails with the error:

    Error 1075: The dependency service does not exist or has been marked for deletion

  • The operating system was upgraded to Microsoft Windows Server 2012 R2 from Windows Server 2008 R2

Cause

 

This issue occurs due to the change of services and service names in Microsoft Windows Server 2012 R2.

 

In Microsoft Windows Server 2008 R2, the VMware Virtual Center Server and VMware vSphere Web Client services are dependent on the Protected Storage service. In Microsoft Windows Server 2012 R2, the Protected Storage service is renamed to the Security Accounts Manager service. During the operating system upgrade, the VMware service dependencies are not updated with the new service names. This results in the VMware Virtual Center Server service not being able to start as the Protected Storage service no longer exists.

 

I followed this KB (2112741)

 

VMware Knowledge Base

In order to deploy Progressive Web Apps with Workspace ONE UEM you need to create two profiles.

  1. ADMX Ingest (Chrome/Edge)
  2. Set WebAppInstallForceList

 

I will share the details in this post.

1

 

To Import the latest Google Chrome or Microsoft Edge ADMX Policy Templates go to the website of the chosen browser vendor.

For this post I will stick to Chrome.

 

Create a new Windows 10 Device Profile in WS1 UEM > Custom Settings:

 

Install Settings:

<Replace><CmdID>1</CmdID><Item><Meta><Format>chr</Format><Type>text/plain</Type></Meta><Target><LocURI>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx</LocURI></Target><Data><![CDATA[<INSERT_YOUR_ADMX_CONTENT_HERE>]]></Data></Item></Replace>

Remove Settings:

<Delete><CmdID>1</CmdID><Item><Target><LocURI>./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy</LocURI></Target><Data></Data></Item></Delete>

2

 

I will use Microsoft Teams as an example PWApp (you can change the URL as you wish).

For more details on the two other parameters visit Googles or Microsofts documentation.

 

Create another new Windows 10 Device Profile in WS1 UEM > Custom Settings:

 

Install Settings:

<Replace><CmdID>1</CmdID><Item><Target><LocURI>./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/WebAppInstallForceList</LocURI></Target><Data><![CDATA[<enabled/><data id="WebAppInstallForceList" value='[{"create_desktop_shortcut":true,"default_launch_container":"window","url":"https://teams.microsoft.com"}]'/>]]></Data></Item></Replace>

Remove Settings:

<Delete><CmdID>1</CmdID><Item><Target><LocURI>./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/WebAppInstallForceList</LocURI></Target><Data></Data></Item></Delete>

Thats it, the PWA will be installed automatically as soon as the browser is launched and will be removed if the profile/policy no longer applies.

Alex

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster 作成の準備作業をしました。

今回は Tanzu Kubernetes Cluster を作成してみます。

 

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

 

Tanzu Kubernetes Grid(TKG)サービスで利用されている Cluster API では、

Management Cluster と Workload Cluster という役割の Kubernetes クラスタが登場しますが、

今回作成する Tanzu Kubernetes Cluster は、Workload Cluster にあたります。

 

Supervisor Cluster への接続。

kubectl で、Supervisor Cluster に接続します。

vSphere 専用の kubectl の準備については、下記の投稿のようにしています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

 

kubectl では、下記のようログインにしてます。

  • この環境では Supervisor Cluster の Control Plane アドレスとして、192.168.70.33 を指定します。
  • このあとの対話入力で、administrator@vsphere.local とパスワードを入力。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33

 

環境の確認。

前回の準備をふまえて、あらためて環境確認をしておきます。

 

今回は、名前空間「lab-ns-02」に Tanzu Kuberntes Cluster を作成するので、

同名の Context に切りかえておきます。

$ kubectl config use-context lab-ns-02

Switched to context "lab-ns-02".

 

作成されている Storage Class です。

あとで Tanzu Kuberntes Cluster の設定値として YAML で指定するので、

「vm-storage-policy-wcp」という名前をひかえておきます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

 

名前空間へのコンテンツ ライブラリ追加により、VirtualMachineImage の情報取得ができるようになっています。

イメージの名前(NAME 列)の文字列から、このあとの YAML では Kubernetes バージョン「v1.16.8」を指定します。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

 

Tanzu Kuberntes Cluster の YAML 作成。

Tanzu Kuberntes Cluster の設定値を記載したマニュフェストを、YAML 形式のファイルとして作成します。

 

tkg-cluster-01.yml

---

kind: TanzuKubernetesCluster

apiVersion: run.tanzu.vmware.com/v1alpha1

metadata:

  name: tkg-cluster-01

spec:

  distribution:

    version: v1.16.8

  topology:

    controlPlane:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

    workers:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

  settings:

    network:

      cni:

        name: calico

      services:

        cidrBlocks: ["198.51.100.0/12"] # Cannot overlap with Supervisor Cluster

      pods:

        cidrBlocks: ["192.0.2.0/16"]    # Cannot overlap with Supervisor Cluster

    storage:

      classes: ["vm-storage-policy-wcp"]  # Named PVC storage classes

      defaultClass: vm-storage-policy-wcp # Default PVC storage class

 

YMAL では、下記のようにパラメータを指定しています。

 

Kubernetes のバージョンは、コンテンツ ライブラリに登録されている OVF テンプレート

(にもどづく VirtualMachineImage の名前)の文字列を指定します。

ここでは省略して「v1.16.8」と指定しています。

  • spec.distribution.version

 

各所で指定している「vm-storage-policy-wcp」は、

名前空間へのストレージ ポリシー追加で自動的に作成・利用可能になった、

仮想マシン ストレージ ポリシーと同名の StorageClass です。

 

CIDR によるアドレス範囲は、Supervisor Cluster とは別のものを指定します。

ちなみに、Pod Network の CNI では、Calico が使用されます。

  • spec.settings.network.services.cidrBlocks
  • spec.settings.network.pods.cidrBlocks

 

Control Plane ノード、Worker ノードは、それぞれ 3ノードです。

  • spec.topology.controlPlane.count
  • spec.topology.worker.count

 

Control Plane ノード、Worker ノードの VM スペックは、下記で指定しています。

ここでは、「best-effort-xsmall」を指定しています。

  • spec.topology.controlPlane.class
  • spec.topology.worker.class

 

ここで指定している class(VirtualMachineClass)には、下記が用意されています。

$ kubectl get virtualmachineclasses

NAME                 AGE

best-effort-large    12d

best-effort-medium   12d

best-effort-small    12d

best-effort-xlarge   12d

best-effort-xsmall   12d

guaranteed-large     12d

guaranteed-medium    12d

guaranteed-small     12d

guaranteed-xlarge    12d

guaranteed-xsmall    12d

 

ちなみに、今回指定した VirtualMachineClass「best-effort-xsmall」は、下記のようなスペックです。

vCPU は 2個(cpus: 2)、メモリ容量は 2GiB(memory: 2Gi)です。

$ kubectl get virtualmachineclasses best-effort-xsmall -o yaml

apiVersion: vmoperator.vmware.com/v1alpha1

kind: VirtualMachineClass

metadata:

  annotations:

    kubectl.kubernetes.io/last-applied-configuration: |

      {"apiVersion":"vmoperator.vmware.com/v1alpha1","kind":"VirtualMachineClass","metadata":{"annotations":{},"name":"best-effort-xsmall"},"spec":{"hardware":{"cpus":2,"memory":"2Gi"}}}

  creationTimestamp: "2020-05-24T15:20:10Z"

  generation: 1

  name: best-effort-xsmall

  resourceVersion: "2182"

  selfLink: /apis/vmoperator.vmware.com/v1alpha1/virtualmachineclasses/best-effort-xsmall

  uid: b5a801bc-28d4-4526-966b-7e30dbc9b570

spec:

  hardware:

    cpus: 2

    memory: 2Gi

 

Tanzu Kubernetes Cluster の作成。

それでは、Tanzu Kubernetes Cluster を作成します。

用意した YAML を指定して、kubectl apply を実行します。

$ kubectl apply -f ./tkg-cluster-01.yml

tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-01 created

 

しばらく待つと、lab-ns-02 名前空間に、Kubernetes のノードになる VM がデプロイ、起動されます。

これらの VM(のゲスト OS)で、Tanzu Kubernetes Cluster が構成されています。

wcp-12-28.png

 

Kubernetes のバージョンは、v1.16.8 になっています。

これは、Supervisor Cluster の Kubernetes バージョンと一致するわけではありません。

kubectl でログイン先として指定する、制御プレーンのアドレスもわかります。

(これは、Supervisor Cluster への接続と同じアドレスです)

wcp-12-30.png

 

YAML で指定したとおり、Kubernetes Node が VM で作成されています。

Control Plane Node(VM 名は、<クラスタ名>-control-plane-~) が 3 VM、

Worker Node(VM 名は、<クラスタ名>-worker-~)が 3 VM 作成されています。

どちらも、仮想マシン クラスは、best-effort-xsmall になっています。

wcp-12-31.png

 

続く?

If you are a VMware Cloud Services Customer and you are trying to use the VMware Workspace ONE application in Okta to leverage SCIM management of identities in WS1, you might be running into an issue with Groups.

 

In Workspace ONE Access you will notice that groups created from Okta are associated with the System Domain but are not associated with associated with the directory that was created for Okta to provision users and groups.

 

oktagroupissue.png

The reason this is happening is because the Okta SCIM request to create a group does not contain the  domain attribute which is associated with the correct directory information in Workspace ONE Access. Unfortunately, the SCIM request to create a group in Okta cannot be customized to include this attribute.

 

To work around this issue, we will have to pre-create the group on Workspace ONE Access.

 

  1. Open a new tab in postman
  2. Add the correct authorization header (as per the main Okta SCIM Integration Blog https://communities.vmware.com/blogs/steveIDM/2019/08/13/workspace-one-okta-integration-part-3-setting-up-scim-provisioning)
  3. For the HTTP Method, select "POST"
  4. For the URL, enter: "https://[TENANT]/SAAS/jersey/manager/api/scim/Groups
  5. Under "Headers", set the Content-Type to "application/json"
  6. Use the following as a sample and Send. You will need to do this for each group you plan on linking in Okta: Replace the DisplayName with the same name as the group in Okta.  You will need to include the correct domain name associated with the directory previously created for use with Okta SCIM.
    {  
      "schemas": [  
        "urn:scim:schemas:core:1.0",
        "urn:scim:schemas:extension:workspace:1.0"
      ],  
      "displayName": "VMWCSPgroup1",  
      "urn:scim:schemas:extension:workspace:1.0": {
            "domain": "vmwaredemo.com"
        }
    
    
    } 
    
    
  7. You will now see the group created in Workspace ONE Access and associated with the correct directory.
    oktagroupissue2.png
  8. In the Okta Administration Console, please make sure this group exists in Okta before proceeding.
  9. In the VMWare Workspace ONE application (in Okta Admin Console), click on the Push Groups tab.
  10. Click on Refresh App Groups to ensure Okta has a complete list of groups in Workspace ONE Access.
  11. Click on Push Groups -> Find Groups by Name
  12. Enter the name of the group
  13. Ensure that a match is found in Workspace ONE Access with the option to Link Group:
    Screen Shot 05-28-20 at 11.55 AM.PNG
  14. Click Save
  15. Very the the Group Linking was Successful
  16. The group should now sync with Workspace ONE Access.

ここまでに、vSphere with Kubernetes のラボ環境を構築して、

名前空間(Supervisor Namespace)に vSphere Pod を起動してみました。

 

前回の投稿はこちら。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

 

vSphere with Kubernetes では、おもに 2種類の方法でコンテナを起動できます。

  1. Supervisor Cluster(ESXi が Kubernetes Worker ノード)の上で、vSphere Pod を起動する。※前回の投稿。
  2. Supervisor Cluster のうえに、さらに ゲスト OS による Kubernetes クラスタ(Tanzu Kubernetes Cluster)を作成して、その上で Pod を起動する。

wcp-01-p01.png

 

今回から、前回までに構築した Subervisor Cluster に、Tanzu Kubernetes Cluster のデモ環境を構築していきます。

つまり、Supervisor Namespace に Tanzu Kubernetes Grid サービスによる Kubernetes Cluster

(ドキュメントでは Tanzu Kubernetes Cluster)を作成してみます。

vSphere with Kubernetes での Tanzu Kubernetes クラスタの実行

 

Tanzu Kubernetes Grid(TKG)は、Cluster API という Kubernetes クラスタ自体のライフサイクルを管理できる API を利用しています。

Cluster API では、おもに 2種類の Kubernetes クラスタが登場します。

  • Management Cluster
    • Kubernetes クラスタを管理するための Kubernetes クラスタ。
    • vSphere with Kubernetes の TKG では、Subervisor Cluster が Management Cluster になる。
  • Workload Cluster
    • 実際になにかしたいワークロードを展開するための Kubernetes クラスタ。
    • vSphere with Kubernetes の TKG では、Subervisor Cluster の名前空間に VM がデプロイされて、そのゲスト OS でさらに Kubernetes クラスタが作成される。

 

ここからは、Management Cluster での準備作業です。

 

コンテンツ ライブラリの準備。

TKG では、Kubernetes ノードになる VM のテンプレートを利用します。

そして、vSphere with Kubernetes の TKG では、VM テンプレートの配置に vCenter のコンテンツ ライブラリを利用します。

 

ここでは、TKG で利用するコンテンツ ライブラリを作成して、コンテンツを同期(インターネット経由でダウンロード)しておきます。

vSphere Client で、「コンテンツ ライブラリ」メニューを開きます。

wcp-12-01.png

 

「作成」ボタンをクリックして、「新しいコンテンツ ライブラリ」画面を開きます。

コンテンツ ライブラリの名前は「lib-tkg-01」にしています。

wcp-12-03.png

 

「コンテンツ ライブラリの設定」では、次のように入力して「NEXT」をクリックします。

  • 「サブスクライブ済み コンテンツ」を選択
  • サブスクリプション URL を入力: https://wp-content.vmware.com/v2/latest/lib.json
    ※製品ドキュメントにある URL です。
  • コンテンツのダウンロード: 今すぐ(デフォルトのまま)

wcp-12-04.png

 

ストレージの追加では、ダウンロードされたコンテンツを格納するデータストアを選択します。

wcp-12-06.png

 

コンテンツ ライブラリが作成されました。

しばらく待つと、コンテンツ ライブラリの同期が完了します。

この処理は 5GB を超えるファイルのダウンロードなので、そこそこ時間がかかります。

※「ライブラリの同期」タスクは 0% の状態が長く続きます。

 

同期の完了したコンテンツ ライブラリで、名前(lib-tkg-01)をクリックします。

wcp-12-10.png

 

「OVF & OVA テンプレート」を開くと、

Kubernetes ノードになる VM テンプレートが見つかります。

名前の文字列から、Kubernetes のバージョンが v1.16.8 であることがわかります。

wcp-12-11.png

 

名前空間でのコンテンツ ライブラリ追加。

名前空間で、TKG が VM テンプレートをさがすコンテンツ ライブラリを追加します。

名前空間(ここでは lab-ns-02)の「サマリ」→「Tanzu Kubernetes」で、

「ライブラリの追加」をクリックします。

wcp-12-22.png

 

「ライブラリの追加」をクリックします。

※名前空間の「設定」→「名前空間」→「全般」を直接ひらいても大丈夫です。

wcp-12-23.png

 

先ほど作成・同期したコンテンツ ライブラリを選択し、「OK」をクリックします。

wcp-12-24.png

 

コンテンツ ライブラリが追加されました。

wcp-12-25.png

 

これにより、Kubernetes の VirtualMachineImage リソースが作成されます。

kubectl で接続(前回の投稿参照)すれば、下記のようにリソースの存在を確認できます。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

 

名前空間への仮想マシン ストレージ ポリシーの追加。

名前空間に、仮想マシン ストレージ ポリシーを追加します。

この手順により、この仮想マシン ストレージ ポリシーによってデータストアを利用する、Kubernetes の StorageClass リソースが用意されます。

 

名前空間(ここでは lab-ns-02)の「サマリ」→「ストレージ」で、「ストレージの追加」をクリックします。

wcp-10-43.png

 

仮想マシン ストレージ ポリシーを選択して、「OK」をクリックします。

wcp-10-44.png

 

名前空間に、仮想マシン ストレージ ポリシーが追加されました。

wcp-10-45.png

 

これにより、Kubernetes の StorageClasse リソースが作成されます。

kubectl で接続(前回の投稿参照)すれば、下記のようにリソースの存在を確認できます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

 

つづく・・・。

vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編

I'm trying a new method of snapshots of gold images for my linked-clone pools. Usually I make one gold master for each pool, and update each master monthly. That's getting rather time consuming, so now I'm making a single gold master for all pools, and snapshots for each pool. I can run the updates on the master and then re-snapshot for each pool. Hopefully I only have to run monthly updates on one image instead of five, and reduce the chance of the images getting corrupted.

 

This is the old method, with each pool having it's own gold and snapshots:

To this, which looks much cleaner:

Problem description:

 

With Appstack 4.0 attached in the remote desktop, if the user tries to configure any network printer it fails with an error

"Windows Cannot connect to the printer. Operation failed with error 0x00000006"

 

On the same remote desktop, if the no appstack is attached, user is able to configure the network printer.

 

Product:

 

VMware AppVolumes 4.0

 

 

Workaround:

 

Note: First implement the action plan on a test pool or test machine before moving it to production.

 

  • Power on master VM.
  • Navigate to C:\Program Files(x86)\CloudVolumes\Agent\Config.
  • Create a new folder called "Custom"
  • Then create a new folder called "app"
  • Create a notepad file, open the file and add below lines:

 

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider

exclude_path=%SystemRoot%\System32\DriverStore\FileRepository
exclude_path=%SystemRoot%\INF
exclude_registry=\REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers
exclude_registry=\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Print\Printers

 

  • Save the file as snapvol.cfg (make sure to remove the extension txt)

    The complete path of the file is : C:\Program Files(x86)\CloudVolumes\Agent\Config\Custom\app\snapvol.cfg
  • Reboot the VM, Shutdown the VM and take a snapshot and recompose/publish the pool with this snapshot.
  • Login to the VM and you should be able to map network printers now.

 

PS: For further details or information please contact VMware App Volumes support team.

vSphere with Kubernetes を体験するためのラボ環境構築をしたので、

kubectl で接続して、コンテナ を Kubernetes の Pod(vSphere Pod)として起動してみます。

Supervisor Cluster に作成した名前空間の配下の管理は、基本的には vSphere 専用の kubectl を利用します。

 

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

 

クライアント環境について。

今回は、kubectl を実行するクライアントとして Linux(VMware Photon OS 3.0)を利用しています。

gowatana [ ~ ]$ cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=49d932d

 

Photon OS はデフォルトのパッケージが少ないので、

あらかじめ root ユーザで RPM を追加インストールしておきます。

  • photon-checksum-generator: ハッシュ値確認のため(sha256sum コマンド)
  • unzip: kubectl の zip ファイル(vsphere-plugin.zip)の解凍のため。

root@vm01 [ ~ ]# tdnf install -y photon-checksum-generator unzip

 

kubectl のダウンロード ページ。

まず、vSphere 専用の kubectl をダウンロードします。

 

この環境の Supervisor Cluster には、名前空間「lab-ns-01」、「lab-ns-02」を作成してあります。

ダウンロード サイトには、「名前空間」のサマリページにある「開く」リンクからアクセスできます。

wcp-11-01.png

 

「Kubernetes CLI Tools」ページが開けます。

ちなみに、このサイトのアドレスは、Supervisor Control Plane VM (のアドレスをメンバにしている NSX-T の LB の VIP)のものです。

Web ブラウザのアドレスバーを見ると、今回の IP アドレスは、192.168.70.33 になっています。

このあとの kubectl での接続先も、この IP アドレスです。

wcp-11-02.png

 

ダウンロードサイトでは、Windows / Linux / Mac OS 用の kubectl と、

それぞれの SHA256 ハッシュ値のファイルが提供されます。

wcp-11-03.png

 

OS ごとの kubectl の利用手順も、このページに記載されています。

wcp-11-04.png

 

kubectl のダウンロード ~ ログイン。

「Kubernetes CLI Tools」ページにある「CLI PLUGIN LINUX」と「Checksum CLI plugin Linux」から

右クリック メニューなどでダウンロード URL を取得しておきます。

そして、今回 kubectl を実行する Linux からダウンロードします。

 

kubectl の zip ファイル(vsphere-plugin.zip)を、curl でダウンロードします。

gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/vsphere-plugin.zip

 

あわせて、ハッシュ値のファイル(sha256sum.txt)をダウンロードします。

gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/sha256sum.txt

 

2つのファイルをダウンロードしたら、SHA256 のハッシュ値でファイルに問題がなそうか確認しておきます。

  • Photon OS 3.0 では、「Kubernetes CLI Tools」ページとは少し手順が異なり、
    冒頭での photon-checksum-generator のインストールが必要です。
  • とりあえず実行してみるだけであれば、ハッシュ値確認は省略しても大丈夫です。

gowatana [ ~ ]$ ls

sha256sum.txt  vsphere-plugin.zip

gowatana [ ~ ]$ tdnf install -y photon-checksum-generator

gowatana [ ~ ]$ sha256sum --check sha256sum.txt < vsphere-plugin.zip

vsphere-plugin.zip: OK

 

zunzip でファイルを解凍すると、中に kubectl が入っています。

gowatana [ ~ ]$ unzip vsphere-plugin.zip

Archive:  vsphere-plugin.zip

   creating: bin/

  inflating: bin/kubectl-vsphere

  inflating: bin/kubectl

 

kubectl に PATH を通しておきます。

gowatana [ ~ ]$ export PATH=$(pwd)/bin:$PATH

gowatana [ ~ ]$ which kubectl

/home/gowatana/bin/kubectl

 

今回の kubectl のバージョンです。

gowatana [ ~ ]$ kubectl version --client

Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.4-2+a00aae1e6a4a69", GitCommit:"a00aae1e6a4a698595445ec86aab1502a495c1ce", GitTreeState:"clean", BuildDate:"2020-04-22T11:35:29Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

 

kubectl で Bash の Tab キー補完を利用するためのコマンドラインを実行しておきます。

gowatana [ ~ ]$ source <(kubectl completion bash)

 

ちなみに、Photon OS ではなく RHEL / CentOS などを利用する場合、

この Bash 補完機能を利用するためには、bash-completion のインストールと再ログインが必要だったりします。

[root@centos7 ~]# yum install -y bash-completion

 

ダウンロードした kubectl には、一般的な kubectl にはない「kubectl vsphere ~」といったコマンドがあります。

gowatana [ ~ ]$ kubectl vsphere --help

vSphere Plugin for kubectl.

 

Usage:

  kubectl-vsphere [command]

 

Available Commands:

  help        Help about any command

  login       Authenticate user with vCenter Namespaces

  logout      Destroys current sessions with all vCenter Namespaces clusters.

  version     Prints the version of the plugin.

 

Flags:

  -h, --help                     help for kubectl-vsphere

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.

 

Use "kubectl-vsphere [command] --help" for more information about a command.

 

「kubectl vsphere login」で、Supervisor Control VM のアドレス宛にログインします。

gowatana [ ~ ]$ kubectl vsphere login --help

Authenticate user with vCenter Namespaces:

To access Kubernetes, you must first authenticate against vCenter Namespaces.

You must pass the address of the vCenter Namspaces server and the username of

the user to authenticate, and will be prompted to provide further credentials.

 

Usage:

  kubectl-vsphere login [flags]

 

Examples:

kubectl vsphere login --vsphere-username user@domain --server=https://10.0.1.10

 

https://10.0.1.10/Flags:

  -h, --help                                        help for login

      --insecure-skip-tls-verify                    Skip certificate verification (this is insecure).

      --server string                               Address of the server to authenticate against.

      --tanzu-kubernetes-cluster-name string        Name of the Tanzu Kubernetes cluster to login to.

      --tanzu-kubernetes-cluster-namespace string   Namespace in which the Tanzu Kubernetes cluster resides.

  -u, --vsphere-username string                     Username to authenticate.

 

Global Flags:

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.

 

今回は、vCenter の名前空間で特にアクセス権限を付与していないので、

デフォルトでアクセス可能になっている administrator@vsphere.local ユーザでログインします。

接続先は、vCenter ではなく、Supervisor Control VM にアクセスできる VIP アドレス「192.168.70.33」です。さきほどの 「Kubernetes CLI Tools」ページと同じアドレスになるはずです。

証明書エラーを回避するため、「--insecure-skip-tls-verify」を指定しています。

gowatana [ ~ ]$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33

 

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

 

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>`

 

利用可能な Context が表示されるので、

名前空間「lab-ns-01」にアクセスできる、同名のコンテキストに切り替えます。

gowatana [ ~ ]$ kubectl config use-context lab-ns-01

Switched to context "lab-ns-01".

 

Pod の起動確認。(kubectl run)

まずは、kubectl コマンドで CentOS 7 のコンテナを Kubernetes の Pod として起動してみます。

下記のようなオプション指定で、まずは コンテナが起動できることだけ確認します。

  • コンテナ イメージは centos:7 を Docker Hubからダウンロードしています。
  • 「-it」 オプションで起動したコンテナにそのまま接続しています。
  • 「--rm」オプションで、コンテナから抜けた(exit した)際に、Pod を削除します。

 

コンテナを起動し、そのまま接続して、CentOS であることを確認してみました。

gowatana [ ~ ]$ kubectl run -it --image=centos:7 --generator=run-pod/v1 --rm centos

If you don't see a command prompt, try pressing enter.

[root@centos /]# ★ここからコンテナの中。

[root@centos /]#

[root@centos /]# cat /etc/centos-release

CentOS Linux release 7.8.2003 (Core)

 

この状態で vSphere Client から名前空間「lab-ns-01」を確認すると、

「centos」という名前のコンテナを含む Pod が作成、起動されています。

wcp-11-05.png

 

exit で抜けると、「--rm」オプションにより自動的にコンテナは削除されます。

[root@centos /]# exit

exit

Session ended, resume using 'kubectl attach centos -c centos -i -t' command when the pod is running

pod "centos" deleted

gowatana [ ~ ]$

 

vSphere Client でも、Pod が削除される様子が確認できます。

ちなみに、タスク名が「仮想マシンの削除」なのは、vSphere Pod では Pod が仮想マシンとして起動されているためです。

wcp-11-07.png

 

Pod の起動確認。(kubectl apply)

Kubernetes へのコンテナの展開は、実際には YAML ファイルを利用するのが一般的です。

そこで、YAML ファイルを用意して Pod を起動してみます。

 

下記のような nginx-pod.yml ファイルを用意します。

nginx イメージによる nginx-container コンテナ 1つを含む、nginx-pod という Pod を作成します。

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

nginx-pod.yml  ファイルは、たとえば vi などのテキスト エディタで作成・・・

gowatana [ ~ ]$ vi nginx-pod.yml

 

もしくは下記のように ファイルを作成します。

gowatana [ ~ ]$ cat << EOF > nginx-pod.yml

> ---

> kind: Pod

> apiVersion: v1

> metadata:

>   name: nginx-pod

>   labels:

>     app: wcp-demo

> spec:

>   containers:

>   - image: nginx

>     name: nginx-container

> EOF

gowatana [ ~ ]$ cat ./nginx-pod.yml

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

kubectl apply コマンドで YAML ファイルを指定して、Pod を起動してみます。

gowatana [ ~ ]$ kubectl apply -f nginx-pod.yml

pod/nginx-pod created

 

Pod の起動が、kubectl で確認できます。

gowatana [ ~ ]$ kubectl get pods

NAME        READY   STATUS    RESTARTS   AGE

nginx-pod   1/1     Running   0          40s

 

vSphere Client でも、Pod が起動された様子が確認できます。

 

ちなみに、今回はただ Pod を起動しただけなので、Nginx に Web アクセスするには別途手順が必要です。

vSphere with Kubernetes の機能は NSX-T を前提としており、kubectl での操作に合わせて、

NSX によるネットワークが自動的に設定変更されます。(これについては別途・・・)

wcp-11-08.png

 

kubectl delete コマンドで Pod を削除すると、

vSphere Client でも Pod が削除された様子がわかるはずです。

gowatana [ ~ ]$ kubectl delete pod -f nginx-pod.yml

pod "nginx-pod" deleted

 

このように、vSphere with Kubernetes のでの Kubernetes ワークロードの操作については、

vSphere Client ではなく、基本的に kubectl を利用します。

 

以上、Supervisor Cluster に kubectl でアクセスして Pod を起動してみる話でした。

 

次は・・・

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

本記事ではVxRailのESXi Imageに目的のFixが含まれているかを確認します。

 

 

VxRail の ESXi ImageとVMwareのESXi Imageの差異について

 

VxRailには、ESXiのImageが含まれています。

しかしながら、VxRailのESXi ImageはVMwareから公開されているESXi Imageと必ず同じとは限らず、微妙に差異がある場合があります。

 

では、不具合などのFixを確実に適用したい場合はどうしたらよいでしょうか。

 

 

目的のFixが含まれているかを確認する方法

 

 

目的のFixが含まれていることを確認するもっとも簡単な方法は、VxRailのRelease Noteを見ることです。

重要なSecurity FixなどはReleaseNoteに記載されていることが多いため、容易に確認が可能です。

 

ただしすべてのFixがReleaseNoteに記載されるわけではありませんので、記載のないものについては個別に確認する必要があります。

 

ESXiのImageはZipで固められているので、その中身をみて個別のFixが入っていることを確認するのが一番確実です。

 

 

 

具体的な手順

 

ここでは、以下で報告されているSecurity FixがVxRail 4.7.510に含まれているかどうかを確認する手順を例にとって説明します。

 

 

DSA-2020-118: Dell EMC VxRail Appliance Security Update for Third Party Component Vulnerability in VMware ESXi

https://support.emc.com/kb/543403

 

VMSA-2020-0008

https://www.vmware.com/security/advisories/VMSA-2020-0008.html

 

 

上記のFixはVxRailのReleaseNoteを見るとVxRail 4.7.510に含まれている旨の記載があります。

Release-Notes 4.7

https://support.emc.com/docu91467_VxRail-Appliance-Software-4.7.x-Release-Notes.pdf

 

 

 

本当に含まれているかを、VxRailのUpgradeファイル内のESXi Imageを展開して確認してみましょう。

VMSA-2020-0008 によると、ESXi 6.7でのFixed Versionは、ESXi670-202004103-SG

だとあります。

My VMwareのProduct Patchから、このFixはESXi670-202004002 に含まれていることがわかります。

 

 

 

 

ESXi670-202004002のリリースノートを見てみると以下の記載があります。

 

 

 

 

 

つまり、VMware_bootbank_esx-ui_1.33.7-15803439のVIBがVxRail 4.7.510のESXi Imageに含まれていればよい、ということになります。

 

 

では、実際にVxRail 4.7.510のUpgradeファイルをダウンロードして中身を確認しましょう。

https://dl.dell.com/downloads/DL98593_VxRail-4.7.510-Composite-Upgrade-Package-for-4.7.x.zip

 

 

こちらのZIPを確認すると、以下のようなディレクトリ構造が見えますので、bundles → ESXi-xxx.zip と辿ってESXi Imageを入手します。

 

 

 

このESXi-xxx.zipを解凍するとさらにディレクトリ構造がありますので、metadata.zipをさらに解凍します。

 

 

metadata.zipに含まれる、vmware.xmlファイルを開きます。

 

 

このファイルの中で先ほど調べたVIB(VMware_bootbank_esx-ui_1.33.7-15803439)を検索します。

 

 

対象のVIBが確認できましたのでこのVersionには問題なくFixが含まれていることを確認できました。

Microsoft Teams On VMware Virtual Infrastructure Platform:

 

Recently we observe many organizations are slowly migrating from Skype For Business to Microsoft Teams. There are two types of Microsoft Teams installation:

 

  • Per-User Mode: For scenarios, where we have persistent VDIs, then we will go with Per-User mode.
  • Per Machine Mode: For scenarios, where we have non-persistent VDIs, then we will go with Per-Desktop mode. So, it allows the user setup individually while on session.

 

In this article we discuss about capturing Microsoft Teams on appstack or placing them on master image on VDI infrastructure. Also we discuss about Roaming Credentials through DEM.

 

Pre-Requisites:

 

 

Scenario 1: Microsoft Teams on VMware VDI non persistent desktop: {for this scenario as per Microsoft, we need to use Per-Machine mode installation type}

 

  • Power on parent / master Image.
  • Once the VM is powered on,
  • Create a folder called teams on C: drive
  • Copy the msi to C:\Teams folder. [ Optional ]
  • Open elevated command prompt and run below command:

 

msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1

 

  • You will see a Microsoft Teams banner which says Installing Teams for around 10 – 15 seconds.
  • Once the installation is complete, do not launch the application. You will see a shortcut on desktop, and you can see Teams Machine Wide installer on control panel add or remove programs
  • Shutdown the VM take a snapshot and publish or recompose the pool with this snapshot.

 

Scenario 2: Microsoft Teams On Appstack: [ Per-Machine mode ]

 

  • Open App Volumes UI create application and package for Microsoft Teams.
  • Revert the snapshot on capture VM, power on the VM.
  • Click on Package on app volume and select the capture VM.
  • While you are on provisioning mode.
  • Run the command to install MS teams:

 

msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1

 

  • Complete the provisioning, reboot the desktop.
  • Assign the Teams package to user group or to a user.

 

Note: Do not keep more than one instance of Microsoft teams on a particular machine. Example, having MS team package attachment on VM which has MS teams natively installed. This is  not supported.

 

Capturing MS teams credentials on DEM:

 

  • Download the Teams.zip file and extract the files at: \\SHARE\DEMConfiguration\general\application
  • Then open DEM management console and click on refresh tree.
  • Ensure we have IEPassword config file is enabled along with this to roam the credentials.

 

Note: Do not use the Teams configuration which comes with default template. That contains directlex path as %localappdata%\Microsoft\teams\update.exe. This is not the correct directflexpath for machine mode MS Teams. If you want to enable directflex, then path would be: C:\Program Files(x86)\Microsoft\Teams\current\Teams.exe

 

Attached zip file is new version of Teams config file.

ひきつづき、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

これまでは、前提環境をととのえるための準備でしたが、

今回は、Supervisor Cluster を有効化します。

 

前回の投稿はこちら。

vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編

 

Supervisor Cluster の有効化。

Supervisor Cluster は、vSphere Client の「ワークロード管理」から有効化します。

(むしろ「ワークロード管理」を有効化します)

 

vSphere Client で、「ワークロード管理」メニューを開きます。

wcp-10-05.png

 

「ワークロード管理」で、「有効化」をクリックします。

wcp-10-06.png

 

これまでの準備により「互換性あり」に vSphere Cluster が表示されるはずなので、

「wcp-cluster-01」を選択して「次へ」をクリックします。

wcp-10-07.png

 

制御プレーンのサイズ(Supervisor Control Plane VM のスペック)を選択します。

今回はハードウェア リソースの都合上「極小」を選択しています。

wcp-10-08.png

 

ネットワークの設定をします。

管理ネットワークは、次のようなパラメータを入力しています。

  • ネットワーク: DPortGroup-labmgmt-0010
    • vCenter などと通信できる、管理ネットワークのポートグループを指定する。
    • Supervisor Control Plane VM の 1つめの vNIC に割り当てられる。
  • 開始 IP アドレス: 192.168.10.51
    • Supervisor Control Plane VM に付与される IP アドレス。
    • 開始 IP アドレスから 5つ消費する。
      • Supervisor Control Plane VM の Floating IP アドレス。(1つ。開始 IP アドレスが使用される)
      • Supervisor Control Plane VM 3台の IP アドレス。3つ。今回は .52 ~ .54)
      • アップグレード時の予約。(1つ。今回は .55)
  • サブネットマスク: 255.255.255.0(「開始 IP アドレス」のネットワークでのサブネット マスク)
  • ゲートウェイ: 192.168.10.1(「開始 IP アドレス」のネットワークでのサブネット マスク)
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • DNS 検索ドメイン: go-lab.jp
  • NTP サーバ: (カンマ区切りで DNS サーバを指定)

wcp-10-09.png

 

下にスクロールし、

ワークロード ネットワークは、次のようなパラメータを入力しています。

  • vSphere Distributed Switch: DSwitch
  • Edge クラスタ: edge-cluster-01
  • API サーバのエンドポイント FQDN: lab-wcp-01.go-lab.jp
    • Supervisor Control Plane VM の Floating IP にアクセスすると、
      ここで指定した名前が証明書 Subject Alternative Name に設定されていたりする。
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • ポッド CIDR: 10.244.0.0/21(デフォルトのまま)
    • Pod のネットワークが、このレンジから払い出される。
  • サービス CIDR: 10.96.0.0/24(デフォルトのまま)
    • Kubernetes 内部通信の ClusterIP で利用される。
  • 入力方向 CIDR:192.168.70.32/27
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX ロードバランサによる VIP に払い出される。
    • Supervisor Control Plane VM の VIP は、この CIDR の最初の IP アドレス(192.168.70.33)になる。
  • 出力方向 CIDR: 192.168.70.64/27
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX では Tier-1 ゲートウェイの SNAT アドレスとして利用される。

wcp-10-11.png

 

ストレージでは、下記の 3つのデータストアを指定するため、

仮想マシン ストレージ ポリシーを指定します。

ここでは、以前の投稿で作成した「vm-storage-policy-wcp」を指定しています。

  • 制御プレーン ノード(Supervisor Control Plane VM の VMDK を配置するデータストア)
  • 短期ディスク(vSphere Pod で利用するデータストア)
  • イメージ キャッシュ(コンテナ イメージのキャッシュ)

wcp-10-14.png

 

設定値を確認して「完了」をクリックすると、Supervisor Cluster の有効化がはじまります。

wcp-10-15.png

 

「クラスタ」タブで、構成ステータスが確認できます。

開始直後、「最近のタスク」にリモートファイルのダウンロードで 404 エラーが表示されますが、これは無視します。

wcp-10-19.png

 

Supervisor Control Plane VM が自動的にデプロイされます。

ちなみに、ESXi が 4台以上あるクラスタでも、Control Plane VM は 3台です。

wcp-10-20.png

 

有効化処理がうまくいかない場合は、vCenter に root ユーザでログインして、

まず下記のログを確認してみるとよいと思います。

  • ログファイル: /var/log/vmware/wcp/wcpsvc.log

 

しばらく(数十分 ~ 数時間)待つと、「構成ステータス」が「実行中」になり、

「制御プレーン ノード」の IP アドレスが、最終的に「入力方向 CIDR」で指定したレンジの IP アドレスになります。

「現在のバージョン」には、Supervisor Cluster の Kubernetes バージョンが表示されています。

wcp-10-22.png

 

これで wcp-cluster-01 クラスタで、Supervisor Cluster の機能が有効化されました。

 

名前空間の作成。

「ワークロード管理」メニューの「名前空間」タブを開くと、

「名前空間の作成」が表示されるので、クリックします。

wcp-10-23.png

 

クラスタを選択して、名前空間の名前(ここでは lab-ns-01)を入力して「作成」をクリックします。

wcp-10-31.png

 

名前空間が作成されました。

「ステータス」→「CLI ツールへのリンク」にある、「開く」をクリックします。

wcp-10-32.png

 

「Kubernetes CLI Tools」という、

専用 kubectl のダウンロード ページが表示されるはずです。

wcp-10-33.png

 

これでひとまず、vSphere with Kubernetes を体験するためのラボ環境が構築できました。

このページが表示されていない場合は、Supervisor Cluster の有効化が成功していても

NSX-T や物理ネットワークなどの構成がうまくできていない可能性があります。

 

ちなみに名前空間は、Supervisor Cluster を有効化したクラスタの右クリック →「新規名前空間」でも作成できます。

wcp-10-41.png

 

以上、vSphere 7.0 + NSX-T 3.0 で Supervisor Cluster の有効化でした。

おそらくつづく。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、NSX の Tier-0 ゲートウェイを作成します。

 

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編

 

ここでは、Supervisor Cluster を有効化する前提として必要な

NSX-T によるネットワークを作成しておきます。

 

VLAN セグメントの作成。

Tier-0 ゲートウェイのアップリンク インターフェースを接続する

VLAN セグメントを作成しておきます。

これは、NSX Edge から NSX 外部のネットワークに接続する VLAN になります。

 

NSX Manager にログインして、

「ネットワーク」→「接続」→「セグメント」を開きます。

「セグメント」タブの「セグメントの追加」をクリックして、パラメータを入力していきます。

パラメータは、今回のラボ環境にわせて下記のようにしています。

  • セグメント名: seg-vlan0070
  • 接続: なし(デフォルトのまま)
  • トランスポート ゾーン: nsx-vlan-transportzone
  • VLAN: 70

wcp-08-03.png

 

少し下にスクロールして、「保存」をクリックします。

wcp-08-04.png

 

「この Segment の設定を続行しますか?」を「いいえ」で抜けると、

VLAN セグメントが作成されたことが確認できます。

wcp-08-06.png

 

Tier-0 ゲートウェイの作成。

「ネットワーク」→「接続」→「Tier-0 ゲートウェイ」を開き、

「ゲートウェイの追加」→「Tier-0」をクリックします。

 

つぎのようにパラメータを入力して、「保存」をクリックします。

  • Tier-0 ゲートウェイの名前:
  • HA モード: アクティブ/スタンバイ
  • Edge クラスタ: edge-cluster-01

wcp-08-14.png

 

「この Tier-0 ゲートウェイの設定を続行しますか?」では、

「はい」を選択して、つづけてインターフェースの追加を実施します。

wcp-08-15.png

 

Edge の外部インターフェイスの追加。

NSX Edge のアップリンクにあたる、「外部インターフェイス」を作成します。

 

「インターフェイス」→「設定」をクリックします。

wcp-08-16.png

 

「インターフェイスの追加」をクリックし、パラメータを入力してから「保存」をクリックします。

  • 名前: if-uplink-01
  • タイプ: 外部(デフォルトのまま)
  • IP アドレス/マスク: 192.168.70.2/24
  • 接続先: seg-vlan0070
  • Edge ノード: lab-nsx-edge-31

wcp-08-18.png

 

インターフェイスが作成されたこと確認して、「閉じる」をクリックします。

wcp-08-20.png

 

スタティック ルートの設定。

このラボでは、ルーティング プロトコル(BGP)を利用していないので、

NSX 外部のネットワークと Edge のアップリンク ネットワーク

(この直前に作成したインターフェイスの接続されているネットワーク)とでルーティングが必要になります。

そこで、今回はスタティック ルート設定しています。

 

まだ編集途中の Tier-0 ゲートウェイの画面で

「ルーティング」→「スタティック ルート」のとなりの「設定」をクリックします。

wcp-08-21.png

 

「スタティック ルートの追加」をクリックして、

次のようなパラメータを入力して「ネクスト ホップの設定」をクリックします。

  • 名前: default-route
  • ネットワーク: 0.0.0.0/0

wcp-08-23.png

 

「ネクスト ホップの追加」をクリックして、

IP アドレスを入力(このラボ環境では 192.168.70.1)入力してから

「追加」→「適用」をクリックして閉じます。

wcp-08-24.png

 

「ホップ数: 1」と表示されたことを確認してから、

「保存」→「閉じる」をクリックします。

wcp-08-26.png

 

スタティック ルートに「1」と表示されたことを確認して、

「編集を終了」をクリックします。

wcp-08-28.png

 

Edge のアップリンク インターフェイスへの疎通確認。

これで、NSX-T の Tier-0 ゲートウェイとそのアップリンク インターフェイスが作成できたので、

直近で作成したインターフェイス(192.168.70.2)の疎通確認をしておきます。

 

たとえば、最終的に Kubernetes 環境を構築したあとで、

kubectl(kubernetes のクライアント ツール)を実行する想定の端末から

ping 確認などをしておきます。

 

つづく!

vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

1 2 Previous Next

Actions

Looking for a blog?

Can't find a specific blog? Try using the Blog page to browse and search blogs.