WilliamLam.com

How to access the Kubernetes Dashboard UI for a VMware PKS Managed K8S Cluster?

by // Leave a Comment

As some of you may have noticed I have been spending some time working with VMware PKS and Google's Kubernetes (K8S). In fact, I have an entire blog series which you can find below if you are interested.

While consuming one of my PKS managed K8S Cluster, I wanted to access the built-in K8S Web UI Dashboard (which is installed by default as part of the K8S setup by PKS) but I was not able to find a way to access it. After speaking with Michael West, who works in our CNABU, I found out that the K8S Dashboard currently does not support OAuth Tokens which prevents us from easily accessing the UI. However, there is a workaround which involves using an SSH tunnel and leveraging K8S proxy to proxy the Dashboard UI to the K8S Master Node which we can then access from our desktop machine.

Step 1 - We need to configure port forwarding using an SSH Tunnel, depending on the OS type that you wish to connect to the Dashboard UI, take a look at the specific steps below.

Windows - You can use any number of SSH Clients, I normally use Putty. Enter the username/hostname as you normally would but before connecting, expand Connection->SSH->Tunnels and add a new forwarded port with source port being 8001 and destination being localhost:8001. Once you have completed this step, you can connect like you normally would.


MacOS/Linux - You can simply use the built-in ssh client and run the following:

ssh root@pks-client -L 8001:127.0.0.1:8001 -N

Note: If the system that you are trying to access the Dashboard UI also has kubectl installed, then an SSH tunnel is not required and you can simply go straight to Step 2.

Step 2 - Once you have successfully SSH'ed to your PKS Client VM, you can then run the following command to start the K8S proxy:

kubectl proxy


Step 3 - To access the K8S Dashboard, open a browser and connect to http://localhost:8001/ui which should take you to login page. From here, you will need a copy of the specific K8S Cluster configuration file (stored in ~/.kube/config which can be pulled using pks get-credentials [NAME-OF-PKS-CLUSTER]) and provide that as shown in the screenshot below to login to dashboard.


After signing in with the K8S Configuration file, you should be taken the dashboard for your specific K8S Cluster. If you do not see any of your pods, make sure to toggle the Namespace from the system "Default". Below is a screenshot of my K8S Cluster which was deployed with our Yelb application as shown in Part 6 of my VMware PKS series.

Getting started with VMware Pivotal Container Service (PKS) Part 6: Kubernetes Go!

by // 8 Comments

In this article, we will walk through the two workflows, one from the perspective of the Cloud/Platform Operator and how to create a new PKS Cluster to how it will be consumed by the Developer which is simply accessing the Kubernetes API endpoint and does not have to know anything about how it was provisioned or even access to the underlying PKS infrastructure. I think most of you have probably been waiting for this part of the series to see PKS in action and demonstrate how easy it is to manage and consume K8S Clusters.

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

[Read more...]

Converting a vSphere Content Library from Subscriber to a Publisher?

by // 6 Comments

This is a blog post on some old Content Library research which I had looked into several months back for a customer inquiry and realized I never got a chance to write about. When you create a Subscriber Content Library (CL) which synchronize content from a Published CL, the Subscriber CL is basically in read-only mode. Not only can you not edit or modify the content, but the CL itself is also locked as a Subscriber forever. Why might this be a concern or an issue?

Consider the following scenario, where you have a single master CL that contains all the images you wish to distribute amongst your remote sites as efficiently as possible and ideally leveraging CL's built-in replication mechanism. Lets say the master CL is in Palo Alto and you have several vCenter Servers that can be configured as Subscriber CLs in Cork, Ireland. Instead of having configuring each Subscriber to pull remotely from PA, why not replicate that to a single Subscriber located in Ireland and re-publish that content locally to the remainder CL? The ideal workflow would look something like the diagram below.

However, today you can not simply convert a Subscriber CL to also become a Publisher CL. The only option that I could think of without relying on something like externally replicating a CL is to create an additional Published CL from the Subscriber CL. The idea is you would clone from your Subscriber CL in the same vCenter Server to a new Publisher CL and then that CL can then be used by the other local Subscriber CL as depicted in the diagram below.

This functionality currently does not exist in the vSphere Web/Flex Client, however it can be automated using the Content Library REST APIs. I had created a Content Library PowerCLI Module a few months back and one of the functions that would be useful for this workflow is the Copy-ContentLibrary.

The function is pretty straight forward to use, it accepts the name of a source CL that has already been configured as a Subscriber CL and the name of a new Published CL that you have created but is empty.


After that, the contents of the source CL will be copied into the destination CL as shown in the screenshot below.


Depending on the size of your CL, this can take some time but once it has completed, you should that your Published CL is now populated with content from your source CL.

The PowerCLI function also does a few additional things such as checking if a file already exists and will skip the file and move on to help with the copy.


If your intention is to only replicate from your master CL and then create a local publisher CL, there is an additional flag that you can set to $true called -DeleteSourceFile which will delete the files from the Subscriber CL. This is useful if you only have a single Datastore in which both the Subscriber and Publisher CL is storing, which means after the CL copy, you would be consuming 2x the storage as everything has been duplicated. For this particular customer, they only required an initial sync to populate content in their EMEA office and after that, they would be managing it local and not require additional replications from their master CL.