Search Results for: vSphere with Kubernetes

Getting started with VMware Pivotal Container Service (PKS) Part 1: Overview

03.23.2018 by William Lam // 17 Comments

This past week and half, I have been spending quite a bit of time familiarizing myself with the recently released VMware Pivotal Container Service solution, also referred to as VMware PKS for short (yes, that is a K not a C which is a nod to Google's container scheduler Kubernetes). VMware PKS is part of a project that I am currently working on and I figure I would share the process and steps I took to deploy VMware PKS in my own personal lab, in case other folks are interested in trying out this neat and powerful solution for deploying Cloud Native Apps using Kubernetes which was co-developed between VMware, Pivotal and Google.

If you would like to learn more about this first release of VMware PKS and the benefits it provides to both developers (consumers) and operators (admins/SRE) for Kubernetes infrastructure, check out this blog post here. Merlin Glynn, one of the Product Managers for PKS also did an awesome light board video overview of VMware PKS if you want the sparks notes version. If you simply want to give PKS a try without deploying anything, the CNA folks have also published a PKS HOL which can you find here. Another useful resource is the Getting Started with Kubernetes-as-a-Service post from Michael West who works in CNA team and built the PKS HOL.

This will be the first, in a series of articles outlining my VMware PKS deployment and configuration which hopefully can help benefit others as it took me several attempts while learning about the solution. Although the first few articles will include manual guidance, rest assure, there will be some cool automation towards the end but I figure that folks may want to go through this once by hand to get a good understanding on all the different components and how they interact with each other. Plus, some of the PKS-specific automation is still being worked on by the product team and hopefully I will be able to share some of that real soon.

If you missed any of the previous articles, you can find the complete list here:

[Read more...]

govcsim - Neat incubation project (vCenter Server & ESXi API based simulator)

04.21.2017 by William Lam // 12 Comments

I know many of my readers have inquired about VCSIM (vCenter Server Simulator) which was a really useful tool that served a variety of use cases, but unfortunately it had stopped working with the VCSA 6.0 release. VCSIM is another topic that is near and dear to me and it is something I continue to push and advocate for internally at VMware. Earlier this week, I came to learn about a cool new incubation project that Doug MacEachern had been working on for some time now. Doug is an awesome VMware developer working on the vSphere Integrated Containers (vIC) project and he is also well known for his active contributions to both govmomi (vSphere SDK for Go) and govc CLI.

As you can probably guess from the title, the name of the project is called govcsim and it is a vCenter Server and ESXi API based simulator written using govmomi. It creates a vCenter Server model with a datacenter, hosts, cluster, resource pools, networks and a datastore. The naming of the objects is similar to that of the original VCSIM mode that was included with the VCSA. The number of resources can be increased or decreased using the various resource type flags. Resources can also be created and removed using the API. Doug had developed the tool to provide an easy way for their team to test some of the work they are doing with vIC. The tool is still under incubation but continues to received enhancements. In fact, the other day when I had used it for the first time, I had found a couple of issues which Doug resolved immediately.

I got a chance to give govcsim a spin the other day and currently you can connect to it using govmomi, govc, pyvomi (vSphere SDK for Python) or rbvmomi (vSphere SDK for Ruby). It currently does not work with PowerCLI (connects but no inventory), I know this is something Doug is currently looking into. You might also be able to connect using other vSphere SDKs but these are the ones that Doug and I have tried so far.

[Read more...]

How to override the default CPU/Memory when deploying Photon Controller Management VM?

04.25.2016 by William Lam // 1 Comment

When installing Photon Controller, the resource configuration of the Management VM is sized dynamically as mentioned here based on the total available CPU, Memory and Storage on the physical ESXi host that it is being provisioned to. This is generally not a problem when deploying Photon Controller in Production with larger hosts but if you are trying to play with it in a home lab or a resource constrained environment, then this can be a challenge.

Currently, the minimal requirement to play with Photon Controller is a single physical or Nested ESXi VM that is configured with at least 4vCPU, 16GB of memory and 50GB of storage. The biggest constraint for most home labs is usually on memory. As an example, using the configuration above, the default size used for the Photon Controller Management VM is 2vCPU and 4GB of memory which is quite hefty for such a small environment. It potentially could get worse with slightly larger hosts and ultimately this impacts the amount of workload you can run on the ESXi host, especially if you only have one.

In talking to one of the Engineers on the Photon Controller team, I learned about a neat little capability that is currently only available in the Photon CLI which allows you to override the default CPU, Memory and Storage settings for the Photon Controller Management VM. The following three variables can be added to a deployment configuration YAML file which will override the default behavior.

UPDATE (06/02/16) - In v0.9 release of Photon Controller, the MANAGMENT_VM_MEMORY_GB_OVERWRITE variable has been renamed to MANAGEMENT_VM_MEMORY_MB_OVERWRITE. The rest should be the same.

MANAGEMENT_VM_CPU_COUNT_OVERWRITE - Number of vCPUs for the Management VM
MANAGEMENT_VM_MEMORY_GB_OVERWRITE - Amount of Memory for the Management VM (It is actually in MB even though variable says GB)
MANAGEMENT_VM_DISK_GB_OVERWRITE - Amount of storage for the Management VM (there seems to be a bug but property does not actually override the default storage configuration)

Note: One thing that I found while testing out this capability is that you MUST specify all three variables regardless if wish to override one or more resources. If you do not, you will see a strange 500 error code when running the CLI. I assume this is probably a bug and have already reported this to the Engineering team.

Below are the recommended instructions if you plan to override the default configuration for the Photon Controller Management VM.

Step 1 - Open a browser to the IP Address of your Photon Controller Installer VM and go through the wizard as you normally would, but DO NOT click on the Deploy button once you are done. Instead, click on the "Export Configuration" option and save your configuration to your desktop. You can then close the Photon Controller Installer UI window as we will not be using the UI to deploy.

Step 2 - Open the Photon Controller deployment configuration YAML file that you had just saved in the previous step using a text editor of your choice. There will be two modifications that we will need to make. The first is by adding the following three variables under the "metadata" section towards the top and replacing the values with the ones you wish to use. I recommend using 2vCPU/2GB of memory. For storage, there seems to be a bug in which the override does not work, but you STILL MUST specify it in the configuration file else the deployment will fail. Go ahead and leave it as the default 80.

MANAGEMENT_VM_CPU_COUNT_OVERWRITE: 2
MANAGEMENT_VM_MEMORY_GB_OVERWRITE: 2048
MANAGEMENT_VM_DISK_GB_OVERWRITE: 80

Step 3 - The second modification that we need to make to the YAML file is how the datastores are listed under the image_datastores property. In the UI, it stores this property as a collection. However, when using the Photon CLI, it expects it as a string. The fix is quite simple, you just need to change the following

from

deployment:
  image_datastores:
    - datastore1

deployment:
  image_datastores: datastore1

At this point, we are done modifying our YAML configuration file and we can save our changes and get ready to deploy.

Step 4 - You will need the Photon CLI for the remainder of the steps. If you have not downloaded the Photon CLI, take a look here for the details. Point the Photon CLI to the IP Address of your Photon Controller Installer VM by running the following command:

./photon target set http://192.168.1.250

Step 5 - We will now deploy Photon Controller using the CLI and overriding the default algorithm on how the Photon Controller Management VM is configured by running the following command and specifying the full path to your YAML file:

./photon system deploy esxcloud-installation-export-config-vghetto-sample.yaml

Once the deployment has started, you will be provided with a progress bar. If everything is successful, you should be able to login to your ESXi host using either the ESXi Embedded Host Client or vSphere C# Client and you should see that your Photon Controller Management VM has been deployed with the overrides you had specified earlier.

If you are new to Photon Controller, be sure to check out my blog series on test driving Photon Controller: