Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all 3135 articles
Browse latest View live

How to recover vCenter from vSphere replication point-in-time copy

$
0
0

vSphere replication can be used to protect vCenter server by replicating it to another location, it is not the best disaster recovery solution but it works. We can create point-in-time copies (PIT), select RPO, enable compression, etc. But what if vCenter actually breaks down and we want to recover it. And even worse what if we have to recover it to a previous point in time copy (because the latest replicated state is corruped) ? The problem is that the vSphere replication UI is embedded in vCenter UI, so no vCenter UI means no vSphere replication UI.

Well, there is a way to do it and I'm going to explain how it can be done.

 

First we need to know the datastore where vCenter was replicated:

 

And to what point-in-time copy (snapshot in reality) we want to recover. In this example we want to go back to the Oct 30, 2019 11:04 PIT.

As the vCenter is no longer available we have to login to the ESXi host as root (via ssh) and change to a directory where the replicated data is stored. The idea is to recreate the vCenter and point it to the files that were created during desired PIT. First we need to get the instance id, .vmx and .nvram files names (from PIT) and use them to create the standard .vmx and .nvram files. All the information is stored in the .txt file in the same directory.

 

Note: The timestamps are in UTC so in this case one -1 hour.

After that we have to do the same for the vCenter disks (vmdk). Just like on the screenshot below, based on disk id (disk.0) we replace the vc-5-02_2.vmdk with the PIT replica disks (hbrdisk) in vc-5-01.vmx file. This step is not required if we want to recover to the latest state of the vCenter (becasue the .vmx file already points to correct vmkd disks).

We need to repeate that operation with all other disks. Once this is over the .vmx file should look like this:

At this stage the .vmx file is reconfigured and we can register out replicated vCenter as a new VM. This can either be done using vim-cmd command or via ESXi UI.

Last step is to edit the VM settings and connect it to the correct port-group. As the orignal vCenter is down we can only connect the recoverd vCenter VM to a standard vswitch (vSS) port-group or to  ephemeral port-group on distributed vswitch (vDS). This is one of the reason why we should always create this kind of port-group on our management vDS.

 

With this step done the VM can be powered up and after a while the vCenter will be up and running again.

Note: It is important to answer "I moved it" if asked during power-on operation if you do not want to get new uuid.bios and uuid.location values, and a new MAC address.

 

Last thing to do is to clean-up and remove other snapshots from the vCenter VM (consolidate).


Apple's Security Research Developer Program Support Page

$
0
0

Apple's newly rolled out Security Research Developer Program just rolled out earlier last month was a big step towards their support for secuirty developers and professionals to build upon their product. This was a much anticipated accomplishment and served very much so as a hint towards a different tone in regards for their security. Either way this program serves as a great implication on their behalf and from the looks of the page there is a deadline for this wishing to participate. I presume like any new program that is rolled out. It will be closely observed with few selected. Their application has an end date on August 24, 2020.

 

I firmly believe anyone who is here should participate!

 

https://developer.apple.com/programs/security-research-device/

 

 

Logging out,

 

Anthony

vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

$
0
0

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

Using the AirWatch Provisioning Adapter with Windows 10 AAD Join

$
0
0

NOTE: This feature in the AirWatch Provisioning Adapter is only available in Preview

 

Are you using the AirWatch Provisioning Adapter without a locally configured directory in Workspace ONE UEM and when trying to enroll your Windows 10 Devices and you are getting the following error:

 

Screen Shot 08-17-20 at 11.48 AM.PNG

 

The reason behind this error is because UEM is checking if the attribute "aadMappingAtribute" is currently set for the particular user received in the request from Azure.  If the attribute is not currently set, UEM will search the directory to retrieve this attribute based on on the value configured in UEM:

 

Screen Shot 08-20-20 at 12.25 PM.PNG

 

UEM will retrieve this value from Active Directory (typically) and store this as a binary/hex (ie. 1e7306a8-7eb8-4b6e-a22f-c3e951a5db6e) or as a string depending on the mapping attribute data type.  This is very important because UEM will not successfully map to a userif the value is Base64 encoded. So the following "vZ/lGAC9bUWiA7Egpw5fqg==" is not acceptable.

 

If this attribute is not set and you don't have an  Enterprise Systems Connector (ACC) with a directory configured, you will receive this error. If you are using the AirWatch Provisioning Adapter, you probably don't have an Enterprise Systems Connector (ACC) and directory configured.

 

Workspace ONE UEM will allow you to update this attribute manually in the Admin Console:

Screen Shot 08-20-20 at 12.33 PM.PNG

 

This however is not scalable by any means. Workspace ONE Access is releasing functionality to set this attribute when the user is created by the AirWatch Provisioning Adapter. Unfortunately, UEM will not allow this attribute to be updated via the API so only "CREATE" is supported at this time.

 

In the AirWatch Provisioning Adapter, you'll soon be able to map this attribute:

 

Screen Shot 08-20-20 at 12.42 PM.PNG

 

Please remember that this value can NOT be Based64 encoded.  The following is a guideline of possible values:

 

 

aadMappingAttribute in Workspace ONE UEMImmutable ID in AzureAcceptable
18e59fbd-bd00-456d-a203-b120a70e5faavZ/lGAC9bUWiA7Egpw5fqg==YES
00ut8unvqk5z6cgtG0h700ut8unvqk5z6cgtG0h7YES
vZ/lGAC9bUWiA7Egpw5fqg==vZ/lGAC9bUWiA7Egpw5fqg==NO

Extending the Workspace ONE Application in Okta for Additional Attributes

$
0
0

In Workspace ONE Access, you might have configured additional attributes and would like to populate those attributes from your source of truth such as Okta.

 

Perhaps its a single attribute:

Screen Shot 08-20-20 at 02.53 PM.PNG

Or maybe you have many attributes:

 

Screen Shot 08-20-20 at 02.55 PM.PNG

 

When these attributes are created in Workspace ONE Access, they are created in a custom schema.  The schema is in the following format:

 

urn:scim:schemas:extension:workspace:tenant:TENANT:1.0

 

The TENANT will be replaced by your actual tenant name, such as "urn:scim:schemas:extension:workspace:tenant:dsas:1.0".

 

If you are unsure, I recommend you use Postman to query the user using the GET API. ie. {{tenant_url}}/SAAS/jersey/manager/api/scim/Users?filter=userName%20eq%20%22steve%22

 

Here is a sample Postman that I'll use as my guideline. Note - this step is not required but I will use it to demonstrate my approach.

 

Screen Shot 08-20-20 at 02.59 PM.PNG

 

Now that we know how attributes are stored in Workspace ONE Access, lets configure Okta to send these attributes

 

  1. Open the Workspace ONE Application in Okta
  2. Click on the Provisioning Tab
  3. Click on " Go to Profile Editor"
    Screen Shot 08-20-20 at 03.05 PM.PNG
  4. Click Add Attribute
    Screen Shot 08-20-20 at 03.07 PM.PNG
  5. Enter the Display Name, Variable Name and External Name exactly how it is created in WS1 Access (ie. objectGUID).
  6. Enter the custom schema as we noted above. Make sure your tenant name is included correctly.
  7. Check the user personal checkbox under Scope
    Screen Shot 08-20-20 at 03.08 PM.PNG
  8. Click Save
  9. Repeat this process for all the attributes you want to provision.
  10. Click on Mappings
  11. Click on the Okta User to VMware Workspace ONE Tab (Note: My image below is slightly different as I've renamed my application)
    Screen Shot 08-20-20 at 03.12 PM.PNG
  12. Select the correct attribute to map. In my environment, I'm mapping the ExternalID to the objectGUID
    Screen Shot 08-20-20 at 03.13 PM.PNG
    Note: You can get the AD objectGUID using: findDirectoryUser().externalId

  13. Click Save Mappings
  14. Click Apply Updates Now

uefi secure boot failed PSOD

$
0
0

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.

vSphere with Kubernetes ラボ環境構築。(まとめ)

$
0
0

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: 環境説明編

Integrating Zoom with Workspace ONE Access

$
0
0

For updates on this blog and other blogs: Follow @SteveIDM

 

In this blog we are going to walk through the process of integrating Zoom with Workspace ONE Access.  There are two very important prerequisites before you can setup the SAML integration with zoom:

  1. You need an approved Vanity URL.
  2. Users need to be created with an SSO Profile (unless you are using JIT)

 

Zoom Vanity URL

In your Zoom administration console, under Admin -> Account Management -> Account Profile. You can apply for the Vanity URL at the bottom of this screen. Note: It might take some time to get this approved by Zoom.

 

Screen Shot 08-27-20 at 02.01 PM.PNG

 

Zoom Users

When you create users in Zoom, they need to be created with the "SSO User" feature. Users can be created via CSV or through their API. If you are using the API to create users, you will need to include the "SSOCreate" action:

 

 

{  "action": "ssoCreate",  "user_info": {    "email": "steve@vmtestdrive.com",    "type": 1,    "first_name": "Steve",    "last_name": "Test"  }
}

 

When users are created, you will see the SSO Icon:

Screen Shot 08-27-20 at 01.56 PM.PNG

Zoom Single Sign-On Setup

 

In order to configure Zoom for Single Sign-On, you will need to your IDP Metadata from Workspace ONE Access.

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Applications and Click the Settings Button
  3. Click on SAML Metadata ->Identity Provider (IdP) Metadata

 

In your Zoom Administration Console:

  1. Go to Admin -> Advanced -> Single Sign-On
  2. Enter your Sign-in page URL. This can be found in the "md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"" tag. This URL will end in /SAAS/auth/federation/sso
    Screen Shot 08-27-20 at 02.44 PM.PNG
  3. Paste your Identity Provider Certificate (Signing). Note: Proper certificate formatting is not required.
  4. Leave the default SP Provider (SP) Entity ID
  5. In the "Issuer (IDP Entity ID)" enter the value from the WS1 Metadata. This can be found entityID field which is on the first line of the metadata. This URL will end in idp.xml.
  6. Select HTTP-POST for the binding.
  7. Select "SHA-256" for the Signature Hash Algorithm.
    Screen Shot 08-27-20 at 02.45 PM.PNG
  8. Under Security, select Sign SAML Request and Save SAML response logs on user sign-in.
  9. Under Provision User, select "Prior to Sign-in" unless you are doing JIT.
  10. Download your metadata at https://yourcompany.zoom.us/saml/metadata/sp

 

Workspace ONE Access Single Sign-On Setup

  1. Log into the Workspace ONE Administration Console
  2. Go to Catalog -> Web Apps
  3. Click New
  4. Provide a Name (ie. Zoom) and an Icon
    Screen Shot 08-27-20 at 02.25 PM.PNG
  5. Click Next
  6. Open the previously downloaded metadata and copy/paste into the URL/XML section.
    Screen Shot 08-27-20 at 02.27 PM.PNG
  7. Click Next, Next Save.
  8. Edit the Zoom Application we just created.
    Screen Shot 08-27-20 at 02.33 PM.PNG
  9. Click Next
  10. Enter the correct Username Value that will be used to match the corresponding users in Zoom.
    Screen Shot 08-27-20 at 02.31 PM.PNG
  11. Open Advanced Properties
  12. Select Sign Response, Sign Assertion and include Assertion Signature
    Screen Shot 08-27-20 at 02.35 PM.PNG
  13. Under Signature Algorithm, change the value to SHA256 with RSA
  14. Under Digest Algorithm, change the value to SHA256
    Screen Shot 08-27-20 at 02.36 PM.PNG
  15. Click Next, Next Save
  16. Assign the Zoom App to your users in Workspace ONE Access.

 

Log into Workspace ONE Access as an end user and test the application.  Use the SAML Response Logs in Zoom to help troubleshoot.

 

Screen Shot 08-27-20 at 02.39 PM.PNG


Kubernetes で PowerCLI を起動してみる。

$
0
0

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 with Kubernetes でうまく削除できなかった vSphere Pod を削除してみる。

$
0
0

vSphere with Kubernetes によるスーパーバイザー クラスタで、vSphere Pod が削除できなくなることがあります。

そもそも vSphere Pod は右クリックメニューなどから削除できず、わりと悩ましい状態になります。

そこで、なぜか残ってしまった Pod を削除する方法を紹介してみます。

 

削除ずみの vSphere Pod が残った状態。

kubectl(kubectl delete pod ~ など)で vSphere Pod を削除すると、

下記のような状態で Pod が残ってしまうことがあります。

通常は少し待つと自動的に削除されますが、たまに 1日待っても vCenter を再起動しても削除されないことがあります。

 

停止された Pod が残っている様子です。

vsphere-pod-del-01.png

 

ごく稀に、起動中の Pod が残ったりもします。

vsphere-pod-del-02.png

 

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 の作成が失敗します。

vsphere-pod-del-03.png

 

ここから、あらためて 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-del-05.png

 

同様に、もう一つの 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-del-08.png

 

このように vSphere Pod が削除できますが、他にいい方法がないかは気になっています・・・

 

以上、kubectl で削除できなかった vSphere Pod を削除してみる話でした。

Error Host is not cummnunicating for more than 15 secons. While accessing the ESXi host from winSCp

$
0
0

The error would  occur in vcetner 6.5 vcenter appliance while accessing through winSCP

  1. 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 7.0 のコンテンツ ライブラリで仮想マシン テンプレートをチェックアウト / チェックインしてみる。

$
0
0

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)」)や、

「このテンプレートから仮想マシンをチェックアウト」ボタンが表示されています。

lib-vm-template-00.png

 

OVF とは異なり、「仮想マシン テンプレート」では

サブスクライブしたライブラリでのコンテンツ同期はできませんが、

今回紹介するようなバージョン管理ができるようになっています。

 

「仮想マシンおよびテンプレート」のインベントリでも、

テンプレートに紐づく仮想マシン テンプレートの「サマリ」や「バージョン管理」タブから

同様の UI でチェックアウトができるようになっています。

lib-vm-template-02.png

 

古いバージョンのテンプレートには、新バージョンへのリンクがあります。

lib-vm-template-01.png

 

1. 仮想マシン テンプレートのチェックアウト。

ためしに、仮想マシン テンプレートを更新してみます。

テンプレートを選択して、「このテンプレートから仮想マシンをチェックアウト」をクリックします。

lib-vm-template-11.png

 

仮想マシン名を入力し、場所(仮想マシン フォルダ)を選択して「次へ」をクリックします。

lib-vm-template-12.png

 

クラスタ / リソースプール を選択して「次へ」をクリックします。

lib-vm-template-13.png

 

「チェックアウト後に仮想マシンをパワーオン」のチェックを入れて「完了」をクリックします。

lib-vm-template-14.png

 

仮想マシンが作成され「チェックアウト」された状態になりました。

パワーオン状態なので、この時点ではまだ「チェックイン」できません。

lib-vm-template-17.png

 

2. 仮想マシン(ゲスト OS)の更新。

起動された仮想マシンにアクセスして、ゲスト OS で何らかの更新をしておきます。

lib-vm-template-22.png

 

そして、仮想マシンを停止(ゲスト OS をシャットダウン)します。

※ゲスト OS 内部からのシャットダウンでも大丈夫です。

lib-vm-template-23.png

 

3. 仮想マシン テンプレートへのチェックイン。

チェックアウトで作成された仮想マシンには、水色の丸印がついています。

仮想マシンを停止した状態で、「テンプレートに仮想マシンをチェックイン」をクリックます。

lib-vm-template-31.png

 

「仮想マシンのチェックイン」画面で、チェックイン メモを何か入力して「チェックイン」をクリックします。

lib-vm-template-32.png

 

仮想マシンがテンプレートに変換(仮想マシン名も変更)され、

2世代前のテンプレート(元から存在していた、前バージョンのもの)は自動削除されます。

lib-vm-template-34.png

 

新しく作成された仮想マシン テンプレート「ol78-min-01 (4)」でも、

「サマリ」や「バージョン管理」タブの表示が更新されています。

lib-vm-template-35.png

 

これで、コンテンツ ライブラリの UI (でのテンプレートの右クリック)などから、

更新されたテンプレートから、仮想マシンが新規作成できるようになります。

lib-vm-template-36.png

 

参考: 仮想マシン テンプレートのバージョンを戻す。

仮想マシン テンプレートを、ひとつ前のバージョンに戻すことができます。

「・・・」→「このバージョンに戻す」から実行します。

lib-vm-template-41.png

 

「バージョンを戻す」画面で、「メモを元に戻す」に何か入力して「元に戻す」をクリックします。

lib-vm-template-42.png

 

ひとつ前のバージョンの仮想マシン テンプレート「ol78-min-01 (3)」から、あらたに「ol78-min-01 (5)」が作成されます。

このように、コンテンツ ライブラリで管理される「仮想マシン テンプレート」では、

同時に 2つまでの、実体となる仮想マシンが存在することになります。

lib-vm-template-43.png

 

ちなみに、前バージョンのテンプレート(の仮想マシン)は、

不要になったら「バージョンの削除」メニューから削除することもできます。

この例では「ol78-min-01 (5)」ではなく、古い「ol78-min-01 (4)」の方が削除されます。

lib-vm-template-45.png

 

仮想マシン テンプレート更新にかかわる手順を一般化するときに便利かなと思います。

 

以上、コンテンツ ライブラリで仮想マシンをチェックアウト / チェックインしてみる話でした。

Supervisor Cluster 名前空間を分けて同名 vSphere Pod を起動してみる。

$
0
0

通常の 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 でも確認できます。

vsphere-pod-02.png

 

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-04.png

 

vSphere Pod の実体は VM です。

vSphere では、フォルダ内では同名の VM は作成できませんが・・・

vsphere-pod-06.png

 

一方で、リソースプール内では、もともと同名の VM が作成可能でした。

vsphere-pod-07.png

 

そして「Namespaces」リソースプールの配下の「名前空間」でも、ちゃんと同名の Pod は起動できます。

従来からの vSphere の仕組みを、うまく利用しているのだなと思いました。

 

以上、重複する名前の vSphere Pod を起動してみる話でした。

vSphere Pod で Anti-Affinity を試してみる。

$
0
0

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 があります。

vsphere-pod-aa-01.png

 

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 です。

vsphere-pod-aa-02.png

 

2つめの vSphere Pod です。

vsphere-pod-aa-03.png

 

アンチ アフィニティへの定義変更。

アンチ アフィニティの方法については、下記の 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-aa-05.png

 

最終的に vSphere Pod は 2つとなり、別の ESXi で起動されたことが確認できます。

1つめの vSphere Pod です。

vsphere-pod-aa-07.png

 

もうひとつの vSphere Pod も、別の ESXi で起動されています。

vsphere-pod-aa-08.png

 

vSphere Pod 起動時の配置決定では DRS が利用されています。

しかし、vCenter 7.0b 時点では、vSphere Pod の配置制御を工夫したい場合には

アフィニティ ルールや DRS ではなく、Kubernetes 側の仕組みを利用するとよさそうです。

 

以上、vSphere Pod をアンチ アフィニティ配置してみる話でした。

VMware Photon OS on Azure #Part 4 – Public IP, Azure Image and Docker Container on Photon

$
0
0

For now, this is the last post in this series introducing VMware Photon OS on Azure. Testers often need an environment with newly spinned up Photon OS VMs and docker containers. On vSphere you deploy the ova template through the VMware Host Client. The study script in part2 spins up a Photon OS VM without external Azure connectivity, and part3 gives a Photon virtual hardware and command basics discovery perspective. In this part we will add external connectivity using Azure Powershell cmdlets. The middle part in this last post is about Azure images functionality, and we will run a first docker container.

Let's start with adding a public ip address to the virtual machine created in part2.

Add a public IP

On the Photon VM Properties overview, Azure Portal shows the settings of Virtual Machine, Networking, Size and Disk.

Photon1.pngTo add an external ip, first we must identify the network interface of the virtual machine.

In the following example, the network interface of the virtual machine is identified by name and by the private IP address parsing through all virtual machines' configuration by using get-aznetworkinterface. In a small environment this method is quite straight forward. In a restricted environment, add your NetworkSecurityGroup you are eligible to traverse as -ExpandResource parameter.

$vmName="photon"

$PrivateIPAddress="192.168.1.4"

$nic=get-aznetworkinterface | where-object {($_.VirtualMachine.id -eq (get-azvm -name $vmName).id) -and ($_.IpConfigurations.PrivateIpAddress -eq $PrivateIPAddress)}

The network interface is linked to a virtual network where the ip configuration is stored. The nic' ipconfiguration id is used to retrieve the virtual network and the subnet object. You need to identify the subnet name when you set on the same network interface the ip configuration for the public ip address.

$ipconfiguration = $nic.ipconfigurations | where-object { $_.Id -eq ((get-azvirtualnetwork).subnets.ipconfigurations.Id)[0]}

$vnet = get-azvirtualnetwork | where-object {$_.subnets.IpConfigurations.Id -eq $ipconfiguration.id}

$subnetobject=(get-azvirtualnetwork).subnets | where-object {$_.IpConfigurations.Id -eq $ipconfiguration.id}

$subnet = Get-AzVirtualNetworkSubnetConfig -Name $subnetobject.name -VirtualNetwork $vnet

 

In this example we haven't specified any Resource Group Name. We simply filter the Resource Group Name from the VM' network interface as well.

$resourcegroupname= $nic.ResourceGroupName

To allocate a new public IP Address use New-AzPublicIpAddress. In the following example I used a sku basic and a dynamic allocation method. That said, the public IP might change when the virtual machine is not running. For a static IP address allocation have a look to https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-addresses.

The retrieved ipconfiguration name and subnet name are used to set the network interface ip configuration for the public ip address. set-aznetworkinterface activates the values set.

$pip = New-AzPublicIpAddress -Name 'MyPublicIpName' -ResourceGroupName $nic.ResourceGroupName -Location $nic.Location -Sku 'Basic' -AllocationMethod 'Dynamic'

$nic | Set-AzNetworkInterfaceIpConfig -Name $ipconfiguration.name -Subnet $subnet -PublicIpAddress $pip

$nic | Set-AzNetworkInterface

 

On the Photon VM Properties Networking overview, Azure Portal shows the new public ip address.

Photon2.png

 

The extended study script is attached right to this blog post.

 

If you check the ip configuration on the Photon virtual machine you won't find the public ip address.

Photon3.png

Azure network interfaces are not the same as VMware virtual machine nic adapters. Think of it as a dynamic outbound network interface right on a vswitch. This is important to know as even with a 1:1 Azure network interface, provided by Azure Accelerated Networking, this still is the same. For additional information see https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-cli.

 

Due to the .vhd builtin Azure Linux VM Agent the Photon OS virtual machine interacts with Azure Fabric, so the Azure Portal shows up the Operating system, hostname and agent status. On the networkctl output we can see that a hv_netsvc driver provides network functionality. That driver is a kernel modules' part of the Linux Integration Services (LIS) for Hyper-V and Azure. Not Azure-endorsed os use those LIS drivers for Linux kernel interaction with the Azure fabric. On the VMware Photon OS downloading page you find the latest Azure vhd bits of Photon OS 3.0 Revision 2. It includes the kernel modules needed for Azure.

 

Browse through Azure Marketplace

You may were already hovering in Azure portal through the Azure Marketplace offerings. Linux on Azure is supported, see https://azure.microsoft.com/de-de/overview/linux-on-azure.

 

To determine offerings in Azure Powershell is simple. Here the VMware offerings with publisher names vmware-inc, bitnami or pivotal:

$publishers=get-azvmimagepublisher | where-object {($_.publishername -like "*vmware*") -or ($_.publishername -like "*bitnami*") -or ($_.publishername -like "*pivotal*")}

This oneliner shows up the listing with offerings.

$publishers | get-azvmimageoffer

 

Actually there is no Azure-endorsed preconfigured Photon OS image on the Azure Marketplace. For non-endorsed Linux distributions there are some installation notes, see https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-generic.

 

In the next part we will have a look to how to create a managed image of a VMware Photon OS release on an Azure subscription. I've written two helper scripts create-AzImage-PhotonOS.ps1 and create-AzVM_FromImage-PhotonOS.ps1 to make work a managed Photon OS image.

 

Create a Photon OS image on Azure

You may download the script from the attachment to this blog post.

How to use create-AzImage-PhotonOS.ps1:

create-AzImage-PhotonOS.ps1 -cred $(Get-credential -message 'Enter a username and password for Azure login.') -ResourceGroupName p1 -Location switzerlandnorth -StorageAccountName p1storage

Per default, the script asks for the Azure subscription credentials and location. The specified resource group name and the storage account name are created if necessary. It may take up to 25 minutes until the uploaded Azure image is created. Without further parameter the image created is from the photon-azure-3.0-9355405.vhd.

 

The script creates a temporary virtual machine of size Standard_E4s_v3 and installed from a sku 2019-datacenter-with-containers-smalldisk-g2. This allows to dynamically pre-store the specified VMware Photon OS bits, to upload them on a so called storage page blob account and to create the managed image with its virtual hardware HyperVGeneration V1 or V2 from the storage page blob account imported disk.

Here the coding description.

Line 1-107: Script comments and input parameters.

Location, Resource group name and Storage Account Name are mandatory parameters. Default settings can be changed for all other parameters storage account type, container name, hyper-v generation, the output image name and its internal disk name as well. SoftwareToProcess contains the download url to the VMware Photon OS Azure.vhd release.

Line 108-131: settings of the temporary virtual machine (do change wisely!)

Line 132-137: The variable adminrole value is used later to check if the script has been started with local administrative privileges. The variable Uri is needed to pass the Url decoded value of SoftwareToProcess to the temporary virtual machine.

Line 138-149: check and install Azure CLI locally. Administrative privileges are necessary!

Line 150-152: Check and install Azure Powershell locally. Administrative privileges are necessary!

Line 153-155: Azure login

Line 156-159: Save Azure context to a temporary file. The file copy will be processed for the Azure login inside the temporary virtual machine.

Line 160-164: Set the context to the subscription Id where Managed Disk exists and where VM will be created if necessary.

Line 165++: The scriptrun variable contains a scriptblock which will be transferred to and processed inside of the temporary virtual machine.

Line 166-185: Scriptblock content of check and install Azure CLI and of Azure Powershell.

Line 186-200: Scriptblock content of decode the Azure context file and import context.

Line 201-235: Scriptblock content of: The Photon Azure .vhd file is downloaded from the url, and extracted using tar and PS7zip. The script part checks if there is enough disk space on the disk specified in temporary vm settings.

Line 236-271: Scriptblock content of: Azure login and upload the extracted Photon azure.vhd file to the storage page blob account.

Line 272-278: create the resource group if it does not exist

Line 279-292: create the storage account if it does not exist. We must wait until the provisioning state is on succeeded.

Line 293-298: create storage container

Line 299-306: check if disk and VM was already created.

Line 307-317: create a network security group configuration to allow traffic for rdp.

Line 318-326: set virtual network, subnet for the temporary virtual machine.

Line 327-333: Populate temporary virtual machine' local admin credentials

Line 334-343: Create a public ip address, create a virtual network interface and associate it to the vm with the public ip and the network security group config

Line 344-362: create the virtual machine configuration

Line 363-367: create the virtual machine

Line 368-374: Check vm and remote install Az module on the temporary virtual machine

Line 375-395: Dynamically populate a script file with scriptblock content, encoded contextfile and additional variables sets.

Line 396-413: Process a block type storage upload of the scriptfile and inject-run the script on the temporary virtual machine. Afterwards, delete the locally stored script file.

Line 414-423: create a disk from the source uri where the processed Photon OS Azure .vhd has been stored.

Line 424-435: create the Azure image with the precreated disk as os disk.

Line 436-456: cleanup the temporary virtual machine and all temporary objects if the image has successfully been created.

 

On all resources on Azure portal you should see the image created. The naming helper ending _V1.vhd is related to the Hyper-v generation V1. You may restart the script to process V2 as well.

Photon4.png

With this, we can deploy virtual machines using the Azure image in an analogous way to vSphere vm templates.

For those who automate and standardize the creation of virtual machines might have a look to the Azure preview of Azure image builder and to Packer of Hashicorp. On vSphere you can use Packer as well.

 

 

 

Photon OS virtual machine provisioning using the Azure image

You may download the script from the attachment to this blog post.

How to use create-AzVM_FromImage-PhotonOS.ps1:

./create-AzVM_FromImage-PhotonOS.ps1 -cred $(Get-credential -message 'Enter a username and password for Azure login.') -Location switzerlandnorth -ResourceGroupNameImage p1 -ImageName photon-azure-3.0-9355405.vhd -ResourceGroupName photon20200919 -StorageAccountName photon20200919storage -VMName Photon3.0rev2

The script asks for the Azure subscription credentials and location. The specified image name must reside in the resource group specified . The virtual machine is created on the storage account provided. Specify the virtual machine name using the parameter VMName and the target resource group . The virtual machine size default offering setting is "Standard_B1ms" (1vCPU and 2GB Ram).

The parameter values of VMLocalAdminUser and VMLocalAdminPwd are login settings of the Photon OS virtual machine created. The default username is "LocalAdminUser" with default password "Secure2020123!". The values are case sensitive.

The virtual machine default networking value is a dynamically allocated private ip address in the subnet 192.168.1.0/24 and a dynamically allocated public ip address on the same network interface.

Use the additional parameters to deploy virtual machines with your settings.

Here the coding description.

Line 1-130: Script comments, input parameters and variables. The variable adminrole value is used later to check if the script has been started with local administrative privileges.

Line 131-142: check and install Azure CLI locally. Administrative privileges are necessary!

Line 143-145: Check and install Azure Powershell locally. Administrative privileges are necessary!

Line 146-149: Azure login

Line 150-154: Set the context to the subscription Id where Managed Disk exists and where VM will be created.

Line 155-162: Verify if virtual machine already exists

Line 163-170: Verify if image exists

Line 171-177: create the resource group if it does not exist

Line 178-191: create the storage account if it does not exist. We must wait until the provisioning state is on succeeded.

Line 192-197: create the storage container

Line 198-212: create a network security group to allow traffic for http and ssh. These are suggestions. Modify the settings to your need of the containers later.

Line 213-221: set the virtual network and subnet

Line 222-231: Create a public ip address, create a virtual network interface and associate it to the vm with the public ip and the network security group configuration

Line 232-242: populate the configuration and create the virtual machine

Line 243-245: set the virtual machine' boot diagnostics

 

Each provisioning now takes a couple of minutes to spin up a next Photon OS virtual machine. To login on the virtual machine you can use ssh and the Azure serial console as well.

In All resources on Azure portal you see the objects.

Photon5.png

If your virtual machine has been created with a Hyper-V generation V2 Photon OS Azure image, it is reflected on the virtual machine settings object "VM generation".

Photon6.png

 

Configure SSH

Per default, ssh is not configured for password authentication, so you might get the following error.

Photon7.png

Use the Azure serial console, and login with the credentials specified on provisioning. The administrator user is not root but got enough administrative privileges.

To configure sshd password authentication we must change the Passwordauthentication value in /etc/ssh/sshd_config. Try this:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.0

sudo systemctl stop sshd

sudo bash -c 'sed "s/PasswordAuthentication no/PasswordAuthentication yes/" /etc/ssh/sshd_config.0 > /etc/ssh/sshd_config'

sudo systemctl start sshd

 

Photon8.png

 

Now you can login using ssh.

Photon9.png

 

 

Run a container

We haven't configured any docker container yet. So let's create a first container with a webserver.

 

Execute the following commands.

# issue with iptables workaround

sudo ln -s /usr/bin/iptables-nft /usr/local/bin/iptables

sudo reboot

 

After the reboot, login again and execute the following commands.

sudo mkdir /sample

sudo touch /sample/Dockerfile

 

The docker container consists two components - Photon OS and the httpd webserver.

sudo vi /sample/Dockerfile

Copy the following content to the Dockerfile.

FROM photon:3.0-20200918

RUN tdnf install -y httpd

CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

And save the Dockerfile (:wq).

The photon image tag in the FROM instruction may be "latest". You can find all valid tags on https://hub.docker.com/_/photon.

The webserver httpd runs on Photon and is started as foreground process.

 

Proceed with the following commands

sudo /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT

sudo docker build /sample -t samplewebserver:v1

sudo docker run -dit -p 80:80 samplewebserver:v1

 

The result on your web browser http://<ip> is

Photon10.png

 

After a while, go and check the average CPU credits consumed. It may be surprising how incredibly low the consumption is, keeping in mind that the Standard_B1ms virtual hardware consists of 1vcpu.

Photon11.png

 

Cleanup

You can list all running docker containers with sudo docker ps -a

To stop the docker containers simply run sudo bash -c 'docker stop $(docker ps -a -q)'

To list all docker container images run sudo docker image ls

To remove all docker images run sudo bash -c 'docker rmi -f $(docker images -a -q)'

 

After the docker cleanup it shouldn't be any images anymore. In some cases you might need to cleanup the docker system. Run

sudo docker system prune -f

sudo docker volume prune -f

 

 

To cleanup the complete installation, delete the Azure resource group. In the example above the resource group name is photon20200919.

 

Lessons learned

I gained some jumpstart experience with Azure powershell as well as on Photon OS. The cloudnative operating system has many advantages, even if it does not belong to the Azure endorsed os. Photon is a core component of the VMware Tanzu platform. Tanzu Basic and all higher editions include PhotonOS, especially as Kubernetes node os.

photon20200919


Tanzu Kubernetes Cluster への接続。(実験編)

$
0
0

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」です。

tkc-access-00.png

 

Tanzu Kubernetes Cluster(TKC)は、スーパーバイザークラスタの名前空間「lab-ns-03」に作成ずみです。

TKC の名前は「tkg-cluster-41」で、制御プレーンの IP アドレスは「192.168.70.99」です。

tkc-access-01.png

 

あらかじめ、vCenter Single Sign-On には、ID ソースとして LDAP サーバを登録ずみです。

tkc-access-02.png

 

ID ソースのドメイン「go-lab.jp」からユーザ情報を取得できています。

tkc-access-03.png

 

方法1: vCenter Single Sign-On 認証で接続する。

ここでは、「k8s-infra-user @ go-lab.jp」という vCenter Single Sigh-On のユーザーで接続してみます。

 

まず、対象のユーザーには、スーパーバイザー クラスタの名前空間で「権限の追加」が必要です。

そして、kubectl で TKC に接続する際は、スーパーバイザー制御プレーン宛となります。

ちなみに、vCenter の管理者ユーザ(administrator@vsphere.local)であれば、

デフォルトでスーパーバイザー クラスタや TKC にアクセス可能です。

tkc-access-case-01.PNG

 

1-1: スーパーバイザー名前空間での権限の追加。

スーパーバイザー クラスタの名前空間「lab-ns-03」の、

「サマリ」→「権限」にある「権限の追加」をクリックします。

tkc-access-04.png

 

ID ソース、ユーザー(またはグループ)、ロールを選択して、「OK」をクリックします。

今回は、ユーザー(k8s-infra-user)を指定していますが、一般的にはグループを指定するはずです。

ロールでは、「編集可能」(edit) または、「表示可能」(view)が選択できます。

tkc-access-05.png

 

権限が追加されました。

tkc-access-06.png

 

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 の管理プレーン宛を指定します。

tkc-access-case-02.PNG

 

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 制御プレーン宛となります。

tkc-access-case-03.PNG

 

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 への接続はスーパーバイザー制御プレーン宛となります。

tkc-access-case-04a.png

 

方法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」ユーザーのみが追加されています。

tkc-access-09.png

 

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 への接続を試してみる話でした。

Using SCIM with OneLogin and Workspace ONE Access

$
0
0

For updates on this blog and other blogs: Follow @SteveIDM

 

I've had quite a few requests lately for assistance setting up SCIM capabilities with OneLogin and Workspace ONE.

 

In full disclosure, I've set this up in my lab but I've not done full end to end testing of all CRUD capabilities.

 

The one obvious difference in the setup and configuration with OneLogin over some of our other partners is the ability to support the Authorization Code Grant Flow.  Big Kudos to the OneLogin team.

 

Lets look at the high level steps:

  1. Create a directory instance in Workspace ONE Access
  2. Create a OneLogin Remote App Access Client.
  3. Configure VMware Workspace ONE application in OneLogin.

 

Create Directory Instance in Workspace ONE Access

In order to create a directory instance in Workspace ONE Access, we'll need to use the API because the type of directory required for this integration can not currently be done using the Admin Console. In the following steps we'll use Postman to run the necessary API calls.

  1. We will need an Oauth Token in order to use the API.  Please see my other blog on your options on getting an OAuth Token
  2. Open a new tab in Postman, Select POST and the method.
  3. For the URL, enter:https://[TENANTURL]SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
    https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs
  4. In the Authorization Tab, Select either BEARER Token or OAuth 2.0 depending on the option you chose in Step 1 to get a token. Select or Paste your Token.
  5. In the Headers Tab, Set the Content-Type to "application/vnd.vmware.horizon.manager.connector.management.directory.other+json"
  6. Click on the Body Tab
  7. Use the following as a sample and Click Send:
    {
    "type":"OTHER_DIRECTORY",  
    "domains":["onelogin.com"],    
    "name":"OneLogin Directory" 
    }
  8. In the Workspace ONE Admin Console, verify that the directory is created and is associated with the correct domain.
    Screen Shot 09-25-20 at 03.03 PM.PNG

Create a OneLogin Remote App Access Client

We will now create a OneLogin Application in Workspace ONE Access which will be used by OneLogin to create/update/delete users in Workspace ONE.

  1. In the Workspace ONE Admin Console, go to Catalog -> Webapps
  2. Click New (Top Left)
  3. Enter a Name ie. OneLogin SCIM
    Screen Shot 09-25-20 at 03.09 PM.PNG
  4. Click Next
  5. On the configuration page, you will need to enter:
    SettingValue
    Authentication TypeOpen ID Connect
    Target URLEnter your OneLogin Tenant ie. https://tenant.onelogin.com
    Redirect URLhttps://admin.us.onelogin.com/provisioning/oauth_redirect_uri
    Client IDEnter a value for the Client ID: ie. OneLoginSCIM
    Client SecretEnter a value for the Client Secret ie. Test12345
    Show in User PortalNO
    Screen Shot 09-25-20 at 03.11 PM.PNG
  6. Click Next
  7. Click Next for Access Policy
  8. Click Save

 

This wizard will create a new remote app access client that will be used by OneLogin. You can see the client which was created by going to Catalog -> Settings -> Remote App Access.

 

Warning: Do NOT edit the scopes. You will not be able to re-add the Admin scope if you do.

Screen Shot 09-25-20 at 03.20 PM.PNG

 

Configure VMware Workspace ONE application in OneLogin.

 

  1. In the OneLogin admin console, search for "VMware Workspace ONE" under Applications
    Screen Shot 09-25-20 at 03.24 PM.PNG
  2. Select and Click Save
  3. Click on Configuration on the left menu
  4. Under SCIM Base URL, enter: https://[tenant].vmwareidentity.com/SAAS/jersey/manager/api/scim
    ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim
  5. Under VMware Site, enter your tenant URL. This will be used as the Oauth Authorization Server URL.
    ie. https://dsas.vmwareidentity.com
  6. Under Client ID, enter the client ID you used in the previous step
  7. Under Client Secret, enter the secret you used in the previous step.
    Screen Shot 09-25-20 at 03.31 PM.PNG
  8. Click Save
  9. Go back to the Configuration Tab

    Before you Continue, you need to make sure your Policy in Workspace ONE Access will allow you to authenticate using System Domain credentials without using the backdoor.  You will need a policy similar to below. The Password (Local Directory) needs to be a fallback.
    Screen Shot 09-25-20 at 03.42 PM 001.PNG

  10. Under API Connection, Click Authenticate
    Screen Shot 09-25-20 at 03.32 PM.PNG
  11. In the pop up, click VMware Workspace ONE
    Screen Shot 09-25-20 at 03.33 PM.PNG
  12. When prompted to Authenticate, Select System Domain
    Screen Shot 09-25-20 at 03.39 PM.PNG
  13. Enter your Credentials
  14. You should be returned back to the One Login Portal with a Successful Authorization
    Screen Shot 09-25-20 at 03.40 PM.PNG
  15. Click on the Parameters Tab
  16. We will need to map the attributes appropriately that will be sent to Workspace ONE.

    In order to map the attributes correctly, we will need to understand how users are created in in OneLogin. Take a look at your users to ensure all the required attributes are set for all users that will be provisioned to Workspace ONE Access.  Attributes such as Username, External ID and User Principal Name are typically set if you have an external directory server. If you are creating users directly in OneLogin without a directory server you will need to select different attribute mappings.

  17. Map the attributes appropriately:
    VMware Workspace ONE FieldValue
    Distinguished NameDistinguished Name
    Email AddressEmail
    External IDIf ALL users are created in OneLogin from a directory server, select ExternalID
    If some users are created locally in OneLogin, select Internal ID.
    First NameFirst Name
    Last NameLast Name
    Name IDEmail
    SCIM Username

    If ALL users are created in OneLogin from a directory server, select Username

    If some users are created locally in OneLogin (without a username) , select Email

    User DomainEnter value used as the domain when creating the directory in Workspace ONE Access
    Screen Shot 09-25-20 at 03.59 PM.PNG
    User PrincipleName

    If ALL users are created in OneLogin from a directory server, select User Principal Name

     

     

    If some users are created locally in OneLogin, select Email

  18. Click Save
  19. Click Provisioning on the left menu, and enable the Provisioning Checkbox.
  20. Click Save
  21. Assign a user the application and verify it successfully provisions
    Screen Shot 09-25-20 at 04.12 PM.PNG

Integrating DUO with Workspace ONE Access

$
0
0

For updates on this blog and other blogs: Follow @SteveIDM

 

Workspace ONE Access will soon offer a native integration with DUO. This integration will not require the use of radius and/or the Workspace ONE Access connector.

 

This blog will outline the steps to setup and configure DUO and Workspace ONE Access.

 

Please remember, this integration is not yet generally available.

 

1. Create a Web SDK Application in DUO

  1. In your DUO admin console, go to Dashboard -> Applications -> Protect an Application
    Screen Shot 10-06-20 at 03.08 PM.PNG
  2. In the search box, enter "Web SDK" and Click Protect
    Screen Shot 10-06-20 at 03.18 PM.PNG
  3. Make note of your Integration Key, Secret Key and API Hostname
    Screen Shot 10-06-20 at 03.20 PM.PNG
  4. Scroll down to settings and update the name of this application.
    Screen Shot 10-06-20 at 03.22 PM.PNG
  5. Click Save

 

2. Enable the Workspace ONE Authentication Method

  1. Log into the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Authentication Methods
    Screen Shot 10-06-20 at 03.26 PM.PNG
  3. Click Edit for "DUO Security"
    Screen Shot 10-06-20 at 03.29 PM.PNG
  4. Enable the Adapter
  5. Paste your Integration Key.
  6. Paste your Secret Key
  7. Paste your API Host Name
  8. Select the correct username format. The only options currently available are username and email address.
  9. Select Save
  10. Your DUO Adapter should be enabled and ready to use.

 

3. Update your "Built-In" IDP in Workspace ONE Access

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Identity Providers
  3. Click on your "Built-In" Identity Provider that is already associated with your user directory.
  4. Scroll down to Authentication Methods and enable DUO Security
    Screen Shot 10-06-20 at 03.42 PM.PNG
  5. Click Save

 

4. Update your Policies

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Policies
  3. Edit your Default or Application Policy (depending on your requirements)
  4. Add DUO Security as a second factor of authentication.
    Screen Shot 10-06-20 at 03.47 PM.PNG
  5. Click Save
  6. Click Next and Save

 

Testing the DUO Flow:

 

  1. Log into your Workspace ONE Access Console (via incognito)
  2. Enter your Username/Password (as an End User)
    Screen Shot 10-06-20 at 03.50 PM.PNG
  3. Click on Start Setup
    Screen Shot 10-06-20 at 03.50 PM 001.PNG
  4. Select your device type and click Continue
    Screen Shot 10-06-20 at 03.51 PM 001.PNG
  5. Select the correct platform for your device and click Continue
    Screen Shot 10-06-20 at 03.52 PM.PNG
  6. Workspace ONE Access will Prompt you to install Duo Mobile. Once you have DUO Mobile Installed, Click "I have DUO Mobile"
    Screen Shot 10-06-20 at 03.53 PM.PNG
  7. In DUO Mobile, click the + sign and scan the barcode
    Screen Shot 10-06-20 at 03.55 PM.PNG
  8. Once activated, you will see a green check mark.
    Screen Shot 10-06-20 at 03.56 PM.PNG
  9. Click Continue
  10. When prompted, select "Send Me a Push"
    Screen Shot 10-06-20 at 03.57 PM.PNG
  11. On your device, click Approve.
    Screen Shot 10-06-20 at 03.58 PM.PNG

NSX-T 3.0 のシンプルな DFW ラボを構築する。

$
0
0

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-dfw-lab-01.png

 

NSX Manager の仮想アプライアンス(VM)は、すでにデプロイしてあります。

OVA ファイルは「nsx-unified-appliance-3.0.0.0.0.15945876-le.ova」です。

nsx-dfw-lab-02.png

 

なお、NSX-T の設定作業をするためにはライセンスの適用は必須です。

デプロイ直後の NSX Manger の VM を起動して、

評価ライセンスを適用してある状態です。

 

NSX Manager での vCenter 登録。

NSX-T に「コンピュート マネージャ」として vCenter を登録します。

これは、NSX-T の仮想スイッチで vDS を利用するために必要です。

 

「システム」→「ファブリック」→「コンピュート マネージャ」を開き、

「追加」をクリックして「コンピュート マネージャの作成」画面を表示します。

そして、下記を入力して「追加」をクリックします。

  • vCenter の「名前」(これは任意の文字列)
  • vCenter の「FQDN または IP アドレス」
  • vCenter の、ユーザー名と、パスワード

nsx-dfw-lab-04.png

 

画面に従って証明書のサムプリントを受け入れると、vCenter がコンピュート マネージャとして登録されます。

nsx-dfw-lab-06.png

 

これで、「システム」→「ファブリック」→「ノード」→

「ホスト トランスポート ノード」で vCenter を選択すると、クラスタと ESXi が表示されるようになります。

nsx-dfw-lab-07.png

 

ただしこの 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」を選択。

nsx-dfw-lab-09.png

 

画面下にスクロールして、下記を入力してから「追加」をクリックします。

  • uplink-1 → vDS の1つめのアップリンク名(例では dvUplink1)
  • uplink-2 → vDS の2つめのアップリンク名(例では dvUplink2)

nsx-dfw-lab-10.png

 

これで、VLAN セグメントを利用できるようになる、トランスポート ノード プロファイルが作成されました。

nsx-dfw-lab-11.png

 

「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、

クラスタ(ESXi ではなくその上の)を選択して、「NSX の設定」をクリックします。

「NSX のインストール」画面が表示されるので、先ほど作成したトランスポート ノード プロファイルを選択して、

「適用」をクリックします。

nsx-dfw-lab-14.png

 

これで少し待つと、クラスタ配下の ESXi が NSX のホスト トランスポート ノードとして設定された状態になります。

nsx-dfw-lab-16.png

 

NSX-T によるネットワークの準備。

このラボでは DFW だけを利用するため、NSX Edge はデプロイしていません。

そして、ルーティングのための Tier-0 / Tier-1 ゲートウェイや、Geneve のオーバーレイ セグメントも作成しません。

VLAN 接続するための「VLAN セグメント」のみ作成します。

 

Tier-0 ゲートウェイは、作成しません。

nsx-dfw-lab-17.png

 

そして Tier-1 ゲートウェイも作成しません。

nsx-dfw-lab-18.png

 

NSX-T では、vCenter でポートグループとして扱える「セグメント」を作成できます。

そして NSX-T の DFW は、この「セグメント」で作用します。

NSX-T のセグメントには、「オーバーレイ」と「VLAN」の 2種類がありますが、DFW はどちらでも利用できます。

そこで、ここでは「VLAN セグメント」のみを作成します。

 

「ネットワーク」→「セグメント」にある、「セグメント」タブで、「セグメントの追加」をクリックします。

そして下記を入力して、画面を下にスクロールします。

  • セグメント名を入力。ここでは seg-vlan-0006。
  • トランスポート ゾーンを選択。デフォルトで作成されている「nsx-vlan-transportzone | VLAN」を選択する。

nsx-dfw-lab-21.png

 

VLAN ID を入力し、「保存」をクリックします。

今回は、セグメント名からもわかるように VLAN ID 6 のセグメントを作成します。

ちなみに、この VLAN ID は(NSX 外部の)物理スイッチのトランク ポートでも設定しておく必要があります。

nsx-dfw-lab-23.png

 

このセグメントの設定を続行するかという確認メッセージは、「いいえ」で閉じます。

nsx-dfw-lab-24.png

 

これで、VLAN セグメントが作成されました。

ここで作成した、VLAN セグメント「seg-vlan-0006」は、

vCenter の vSphere Client などでは、ポートグループとして VM の vNIC に割り当てられます。

nsx-dfw-lab-26.png

 

これで、DFW を利用可能な、シンプルな構成のラボが構築できました。

つづく。

NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

$
0
0

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 によるものです。

dfw-01-00.png

 

vCenter(の vSphere Client)で vDS「vds-21」を確認すると、

「seg-vlan-0006」が表示されており、NSX の「N」マークがついています。

 

ちなみに、dvpg-vlan-0006 という NSX-T に関係しない、VLAN ID 6 の分散ポートグループも別途作成してあります。

※この分散ポートグループは次の投稿で利用します。

dfw-01-01.png

 

VM「vm01」の vNIC に、ポートグループとして NSX-T による VLAN セグメントを割り当てました。

なお、この VM の IP アドレスは 10.0.6.91 です。あとで、このアドレス宛に疎通確認します。

dfw-01-03.png

 

ESXi ホスト「192.168.10.21」で仮想スイッチの構成を確認すると、1つの vDS だけが構成されてます。

この vDS は NSX と統合されており、「NSX 仮想スイッチ」となっていることがわかります。

分散ポートグループやセグメントは、トポロジの図では実際に使用されているものだけが表示されています。

dfw-01-02.png

 

DFW ポリシー / ルールの作成。

NSX Manager で、DFW のポリシーとルールを作成します。

今回は、デフォルトで作成されているポリシーはそのままで、あえてポリシーを追加作成します。

そして、ルールの適用有無が分かりやすいように、すべての通信を許可 / 遮断するためのルールを、1つだけ作成します。

 

「セキュリティ」→「分散ファイアウォール」→「カテゴリ固有のルール」→「アプリケーション」を開きます。

デフォルト作成されるポリシー「Default Layer3 Section 」には、すべての通信を「許可」するルールが設定されているので、

今回の動作確認には特に影響しません。

 

この画面で「ポリシーの追加」をクリックすると「新規ポリシー」が作成されるので、

名前を「test-policy-01」に変更します。

dfw-01-11.png

 

追加された「test-policy-01」ポリシーを選択して、「ルールを追加」をクリックします。

dfw-01-14.png

 

「新規ルール」が作成されるので、「test-rule-01」に変更します。

ルールの「適用先」はデフォルトで「分散ファイアウォール」全体となっており、

NSX-T の オーバーレイ / VLAN セグメントに接続された VM に適用されます。

また、ルールの「送信元」、「宛先」、「サービス」は、いずれも「任意」になっているので、すべての通信が対象になります。

ただし、アクションは「許可」なので、このままでは通信の遮断はされません。

 

そして「発行」をクリックしてポリシー / ルールを保存しておきます。

dfw-01-16.png

 

ルールが保存され、このルールの ID は 3048 が採番されました。

このあと、このルールの設定を変更して、DFW の動作確認をします。

dfw-01-22.png

 

DFW ルールの動作確認。

それでは NSX 外部のマシンから、VLAN セグメントに接続されている vm01 宛に ping で疎通確認をしつつ、

DFW で通信を遮断してみます。

 

作成した DFW ルール「test-rule-01」のアクションを「許可」→「却下」に変更します。

※これはドロップより却下の方がデモ的に見栄えがよいため・・・

dfw-01-28.png

 

「発行」をクリックすると、ルールが適用されます。

この時点で vm01 宛に通信できる外部のマシンから ping を実行しつつ、「発行」をクリックします。

dfw-01-23.png

 

DFW のルールが作用して、外部の端末から vm01(10.0.6.91)への ping が通らなくなりました。

dfw-01-26.png

 

DFW ルール「test-rule-01」のアクションを「却下」→「許可」に戻して、「発行」をクリックすると・・・

dfw-01-29.png

 

外部の端末から、vm01 への ping が通るようになりました。

dfw-01-30.png

 

このように、オーバーレイ セグメントではなく、VLAN セグメントでも、NSX-T の DFW は動作します。

まずは、DFW が動作することの確認でした。

 

次は、VM の vNIC に「NSX の VLAN セグメント」ではなく「vDS の分散ポートグループ」を割り当てた環境で、

分散ファイアウォール ルールが動作しない様子を確認してみます。

つづく!

Viewing all 3135 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>