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.
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>
Recently I’ve had a few people ask how to add or update a custom property on an already deployed vRealize Automation (vRA) machine. Several people unregistered the machine using CloudClient, updated a blueprint with the new custom property and then bulk imported the machine back into vRA. It’s actually much easier than that.
I’ve been studying for the Certified Kubernetes Administrator exam and sometimes use kubeadm to spin up Kubernetes clusters. I wanted to look at the Kubernetes dashboard and found it wasn’t as easy as I hoped to get up and running. I’m going to describe how I was able to get it working. I’m using Kubernetes 1.9 and Calico as the overlay network.
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.
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:
- The action is called getNames and is under the io.orchestration package
- 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
I was trying use vRealize Orchestrator (vRO) 7.2 with vSphere 6.5 GA and U1 the other day and was receiving the following error when I selected vRO Servers under Inventory in the vSphere Web Client: