Exploring a Pivotal Container Service Kubernetes Cluster

I’m going to deploy a Kubernetes cluster using the Pivotal Container Service (PKS) and explore the environment.

Read the rest of this entry »

Delete an orphaned PKS cluster

You may run into a situation where your PKS cluster is orphaned or you’re unable to delete it with the pks delete-cluster command. I’m going to show how to manually clean up the PKS cluster in the database.

Read the rest of this entry »

Cleaning up NSX-T resources from a PKS deployment

In the current release (1.0.x) of Pivotal Container Service (PKS), NSX-T resources are not cleaned up after deleting a Kubernetes cluster. In order to delete the PKS created resources out of NSX-T, you’ll need to run the nsx-cli.sh command like so:

./nsx-cli.sh cleanup <PKS_CLUSTER_UUID> <DRY_RUN>

Read the rest of this entry »

Deploying Kubernetes Clusters with vRealize Automation

I’m going to show how you can provision Kubernetes clusters using vRealize Automation (vRA). I’ll be using kubeadm to install the Kubernetes cluster and since kubeadm is in beta at the time of this posting and doesn’t support HA kube masters, the Kubernetes clusters will be more useful for sandbox type environments.

You’ll be able to select how many Kubernetes worker nodes you want and it will support scale out operations for the worker nodes. Scale in operations are possible, but you’d have to add additional functionality to do this. Currently I don’t have a need for this so I haven’t looked into it. As it stands, you could perform scale in operations and manually remove the longer existing Kubernetes worker nodes.

Read the rest of this entry »

Why you are sometimes unable to see vRO actions when creating vRA Property Definitions

A common question I get asked when working with customers is why are they unable to see recently created vRealize Orchestrator (vRO) action when creating vRealize Automation (vRA) Property Defintions. For example, let’s say I created the vRO action below:

The main things to notice are:

1. The action is called getNames and is under the io.orchestration package
2. The return type is Array/string

In my vRA Property Definition I’ll set the Data type to be a String and Display as to Dropdown as shown:

Now if I select set Values to External values (a vRO action) and press Select, I’ll be presented with a list of vRO actions:

Here we can see the same vRO action (getNames) we created in vRO:

Before displaying the Select Script Action screen above, vRA queried vRO for all actions that have a return type of Array/string. This is because in the Property Definition I’m going to be displaying a dropdown box of strings.

If I was to change the Property Definition to use a Data type of Integer:

and tried to use External values, I wouldn’t be able to see my vRO script action:

So as you can see your vRO action’s return type must match the data type defined in your Property Defintion otherwise you’ll be unable to see your vRO action.

Because vRA allows you to configure a global vRO server and vRO servers per tenant, sometimes users will create a vRO action on one vRO server, but their vRA tenant will be configured to be using a different vRO server. If you have ssh access to the vRO servers, you can confirm that you’re working with the correct vRO server by running the following command as you attempt to browse vRO actions from your Property Definition:

tail -F /var/log/vmware/vco/app-server/localhost_access_log.txt | grep getNames

If you’re on the correct server, you’ll see results such as these:

vra73a:/var/log/vmware/vco/app-server # tail -F localhost_access_log.txt | grep getNames
2017-12-07 03:55:28.677+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-1] “GET /vco/api/actions/com.vmware.o11n.plugin.dynamictypes.configuration/getNamespaceByName HTTP/1.1” 200 1011 194
2017-12-07 03:55:32.875+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-13] “GET /vco/api/actions/io.orchestration/getNames HTTP/1.1” 200 827 196