Automation – Page 202

Quick Tip - Automate the enabling of the Customer Experience Improvement Program (vTelemetry) in VCSA

09.16.2014 by William Lam // 4 Comments

The VMware Customer Experience Improvement Program is a new feature that was introduced with the latest release of vCenter Server 5.5 Update 2 (vCenter Server for Windows & the VCSA). This feature provides the following per the documentation:

If you choose to participate in the Customer Experience Improvement Program (Program), VMware receives anonymous information to improve the quality, reliability, and functionality of VMware products and services. VMware wants to understand better your vSphere deployment and business needs, and improve VMware response to customer requirements. You can choose to participate in the Program for vSphere at any time.

In my opinion, this has been needed for quite some time now. If you have ever installed any consumer based software, there is usually an option that allows customers to provide basic telemetry data back to the vendor so that they can better understand how the product is being used and more importantly leverage that data to help improve the product and features future.

The process of collecting basic telemetry (sometimes also known as phone home) is not a new concept in the Enterprise. In fact, for those of you who manage a storage array, this has been a standard practice for many many years now where every night, the storage array sends back a variety of telemetry data that may include performance information, utilization, logs, etc. to the vendors HQ. This data is then analyzed and the vendor maybe able to sport trends of a potential issue and proactively alert customers to take action before a problem even arises. Michael White has also recently written about the topic here which I recommend a read as well.

There are four categories of data that is being collected:

esxcfg-info.xml
Extension.json
AboutInfo.json
performance-stats.txt

If you wish to learn more about what is being collected and how to view the data before it is sent, please take a look at the documentation here.

One thing I had noticed when deploying the latest VCSA 5.5 Update 2 is that there is now an option to enable the Customer Experience Improvement Program and of course I was interested in automating this configuration as part of my VCSA deployment script.

Taking a look at the logs, I found that there is a new option that has been introduce in /usr/sbin/vpxd_servicecfg called telemtry:

Telemetry data collection modes:
read         : read and return the current status of the collector
enable       : enables the telemetry data collection
disable      : disables the telemetry data collection

To enable the Customer Experience Improvement Program as part of the VCSA setup, you must enable it after vpxd (vCenter Server) has started. Here is the modified VCSA configuration shell script:

#!/bin/bash

echo "Accepting EULA ..."
/usr/sbin/vpxd_servicecfg eula accept

echo "Configuring Embedded DB ..."
/usr/sbin/vpxd_servicecfg db write embedded

echo "Configuring SSO ..."
/usr/sbin/vpxd_servicecfg sso write embedded

echo "Starting VCSA ..."
/usr/sbin/vpxd_servicecfg service start

echo "Configuring VC Telemetry ..."
/usr/sbin/vpxd_servicecfg telemetry enable

If you decide not to enable this feature during the initial deployment or if you have upgraded from an existing vCenter Server, this feature can also be enabled after the fact. To do so, you will need to login to your vCenter Server using the vSphere Web Client and under the Settings tab of your vCenter Server, there is an option to enable or disable the Customer Experience Improvement Program

Note: When enabling or disabling the Customer Experience Improvement Program, a restart of vCenter Server is not necessary.

Hopefully customers will see the benefit and value in joining the VMware Customer Experience Improvement Program and over time, I think you will start to see some really neat benefits for those who participate in this program.

How to deploy a Kubernetes Cluster on vSphere?

09.05.2014 by William Lam // 18 Comments

In the previous article, we walked through the installation of govmomi which is the vSphere SDK for Go and govc which is a command-line interface that uses the SDK to expose vSphere functionality which is used in the Kubernetes vSphere Provider. Now that we have all the prerequisites installed, we are now ready to deploy a Kubernetes Cluster onto a vSphere based infrastructure.

UPDATE (10/26/15) - It looks like the instructions on setting up a Kubernetes Cluster has since changed and I have updated the instructions below. One of the main changes is instead of building from source we are just downloading the Kubernetes binaries.

tep 1 - You will need to download the latest Kubernetes binary (kubernetes.tar.gz) which can be found here. At the time of updating this article, the latest is v1.2.0-alpha2.

Step 2 - Go ahead and extract the contents of kubernetes.tar.gz file by running the following command:

tar -zxvf kubernetes.tar.gz

Step 2 - Download the Kubernetes VMDK using either "wget" or "curl" depending on what is available on your system. Since I am on a Mac, it only has curl by default. Here are the two commands depending on the which download utility you have access to:

wget https://storage.googleapis.com/govmomi/vmdk/kube.vmdk.gz{,.md5}
curl -O https://storage.googleapis.com/govmomi/vmdk/kube.vmdk.gz{,.md5}

Once the download has completed, you should now see two files in your working directory: kube.vmdk.gz and kube.vmdk.gz.md5

Step 3 - Next we need to un-compress the VMDK by running the following command:

gzip -d kube.vmdk.gz

Step 4 - Once the VMDK has been extracted, we will need to upload it to a vSphere datastore. Before doing so, we need to set a couple of environmental variables that provide connection details to your vSphere environment. Below are the commands to set the environmental variables, you will need to replace the information from your own environment.

export GOVC_URL='https://[USERNAME]:[PASSWORD]@[ESXI-HOSTNAME-IP]/sdk'
export GOVC_DATASTORE='[DATASTORE-NAME]'
export GOVC_DATACENTER='[DATACENTER-NAME]'
export GOVC_RESOURCE_POOL='*/Resources'
export GOVC_GUEST_LOGIN='kube:kube'
export GOVC_INSECURE=true

You can leave the last three variables as-is. The GOVC_RESOURCE_POOL defines the full path to root Resource Pool on an ESXi host which will always exists and for vCenter Server, it is the name of the vSphere Cluster or Resource Pool the GOVC_GUEST_LOGIN is the credentials to the Kubernetes Master/Node VMs which are defaulted in the VMDK that was downloaded. The last variable GOVC_INSECURE is if you have an ESXi or vCenter Server using self-signed SSL Certificate, you will need to ensure this variable is set.

To upload the kube.vmdk to the vSphere Datastore and under the kube directory which will be created for you, you will run the following command:

govc datastore.import kube.vmdk kube

Step 5 - We now have our base kube.vmdk uploaded to our ESXi host and before we are ready to deploy our Kubernetes Cluster, we need to set the provider by running the following command:

export KUBERNETES_PROVIDER=vsphere

Step 6 - We are now ready to deploy the Kubernetes Cluster which consists of Kubernetes Master and 4 Kubernetes Minions and they will be derived from the kube.vmdk that we just uploaded. To do so, you will run the following command:

kubernetes/cluster/kube-up.sh

Note: If you see a message about "Docker failed to install on kubernetes-minion-N" it is possible that this related to a timing issue in which the Minion may not be up when the Master is checking. You can verify this by running the next command, else you can follow the instructions to bring down the Kubernetes Cluster and re-creating it.

Step 7 - In the previous step, we deployed the Kubernetes Cluster and you will see the assigned IP Addresses for the Master/Minions along with the credentials (auto-generated) for the Docker Containers. We can confirm that the everything was created successfully by checking the number of running Minions by running the following command:

cluster/kubecfg.sh list minions

Step 8 - Once we have confirmed we have 4 running Minions, we can now deploy a Docker Container onto our Kubernetes Cluster. Here is an example of deploying 2 nginx mapping from port 8080 to 80 instances by running the following command:

cluster/kubecfg.sh -p 8080:80 run dockerfile/nginx 2 myNginx

Step 9 - We should expect to see two "Pods" for the nginx instances we have instantiated and we can do so by running the following command:

cluster/kubecfg.sh list pods

Here are some additional commands to stop and remove the Pods:

cluster/kubecfg.sh stop myNginx
cluster/kubecfg.sh rm myNginx

You can also bring down the Kubernetes Cluster (which will destroy the Master/Minion VMs) by running the following command:

cluster/kube-down.sh

Hopefully this gave you a good introduction to the new Kuberenetes vSphere Provider and I would like to re-iterate that this is still being actively developed on and the current build is an Alpha release. If you have any feedback/requests or would like to contribute, be sure to check out the Kubernetes and govmomi Github repository and post your issues/pull requests.

govmomi (vSphere SDK for Go), govc CLI & Kubernetes on vSphere

09.04.2014 by William Lam // 15 Comments

One of the exciting announcements that was made last week at VMworld was the joint partnership between Docker, Google, Pivotal and VMware. Paul Strong (Office of the CTO) wrote a great blog post Better Together – Containers are a Natural Part of the Software-Defined Data Center where he goes into more details about the partnership. The really neat part of the announcement which I think some people may have missed is that this was more than just an announcement. There are actually active projects currently being worked on, most notably a working prototype for a Kubernetes vSphere Provider.

For those of you who are not familiar with Kubernetes, it is an open-source project that was started by Google which provides Container Cluster Management. You can think of Kubernetes as a placement engine/scheduler for Containers, similar to how vSphere DRS is responsible for scheduling Virtual Machines. The Kubernetes vSphere Provider allows you to run a Kubernetes Cluster on top of a vSphere based infrastructure and provides a platform for scheduling Docker Containers running on top of vSphere.

Kubernetes is completely written in Go (short for Golang), a programming language developed by Google. To be able to easily integrate with Kubernetes, a Go library needed to be written for the vSphere API and hence govmomi was born! Similar to pyvmomi and rbvmomi which are vSphere SDKs for Python and Ruby respectively, govomimi is the vSphere SDK equivalent for Go. The govmomi project is an open source project lead by VMware and you can find the Github repository at https://github.com/vmware/govmomi.

In addition to govmomi, I also learned about a neat little CLI that was built on top of the SDK called govc (currently an Alpha release) which provides a simplified command-line interface to a vSphere environment leveraging govmomi. You can find the source code under the govmomi Github repository https://github.com/vmware/govmomi/tree/master/govc. The Kubernetes vSphere Providers leverages govc to be able to orchestrate the deployment of a Kubernetes Cluster on top of vSphere leveraging the vSphere API.

To use govc, you will need to ensure you have Go 1.2+ installed on your system. Here are the steps on installing Go and govc

Step 1 - Download the latest Go package installer for your OS here and once you have Go installed, you can verify that everything is working by running the following command:

go version

Step 2 - Setup your build environment by running the following commands:

export GOPATH=$HOME/src/go
mkdir -p $GOPATH
export PATH=$PATH:$GOPATH/bin

Step 3 - Check out govc source code by running the following command:

go get github.com/vmware/govmomi/govc

At this point, govc has been installed. You can now connect to either a vCenter Server or ESXi host. The easiest way is to specify the vSphere API endpoint and credentials is by setting a couple of environmental variables, so you do not have to specify it on the command-line.

Step 4 - Run the following command and specify the username, password and either the hostname or IP Address of your vCenter Server or ESXi host:

export GOVC_URL='https://[USERNAME]:[PASSWORD]@[ESXI-OR-VCENTER-HOSTNAME-OR-IP]/sdk'

Step 5 - To verify that everything is working, you can run the following command to query the endpoint you have connected to:

govc about

If everything was successful, you should see some basic information about the vSphere API endpoint you have connected to. In the example above, I am connected to a VCSA (vCenter Server Appliance). The govc CLI is quite similar to RVC with commands broken up into various namespaces. However, one feature that is not there today is the ability to tab complete the commands which is something I just love about RVC!

You can also just run "govc" and it will provide a list of available commands:

You can get more details about each command by specifying --help command, here is an example of the host.info

To get information about one of my ESXi hosts, I need to specify --host.ip option along with the IP:

As you can see from the screenshot above, some basic information is displayed about my ESXi host which is running on a Mac Mini. If you would like to learn more about govc, I highly recommend you check out the govc repository on Github which has additional documentation. You can also file any bugs or feature requests you would like to see on the project page.

At this point you are now ready to proceed to the next steps which is to setup Kuberentes and deploy a Kubernetes Cluster onto your vSphere environment. Unfortunately I ran into a problem while going through the Kubernetes deployment and I did not know where to go next and decided to file a Github issue here. To my surprise, I immediately got a response back from the VMware Engineers who are working on the project. I had a couple of email exchanges with the team to debug the problem. It looks like we found the culprit and I was able to get Kubernetes up and running. There are a couple of minor caveats which I will explain in more detail in Part 2 of this post and walk you through the steps of deploying a Kubernetes Cluster running on top of vSphere.