As you can see from my recent tweets, I have been spending some time with Kubernetes Cluster API (CAPI) and specifically Cluster API Provider vSphere (CAPV) and deploying upstream Kubernetes (K8s) running on VMware Cloud on AWS 🙂
Looks like this week’s theme for me will be:
🔸CAPI (K8s Cluster API)
🔹CAPV (K8s Cluster API Provider for vSphere)
🔸KIND (K8s in Docker)
🔹TKG (@VMwareTanzu K8s Grid)Already learned quite a bit in last 24hrs, huge thanks to @vmmannimal & @KendrickColeman for answering quest.
— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) March 2, 2020
Just deployed my first @VMwareTanzu K8s Grid Management and Workload Cluster (12-Node), using #CAPI via #CAPV all running on #VMWonAWS 🥳 pic.twitter.com/TI9AEbkBew
— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) March 2, 2020
After successfully deploying my first K8S Workload Cluster, I knew the first k8s application that I had to deploy on my shiny new K8s Cluster was Massimo Re Ferre' and Andrea Siviero famous "Yelb" application which I had demonstrated several years ago running on VMware PKS. In fact, I had even deployed it recently (late last year) in one of my Project Pacific cluster without any issue, so I was surprised when I ran into some challenges as you can see from the title of the blog post.
K8s development is not only active but it also moves at fairly rapid pace with quarterly releases. This can be a challenge if you are not keeping up to date with the latest K8s version and before you know it, the version you are running has been deprecated and it no longer functions the way you expect. In my situation, this is what happened and before K8s 1.16, the deployment of the Yelb application was working fine but as of K8s 1.16, there were some API depreciations and removals which now explains the breakages in deploying the Yelb application to a newer version of K8s, which as of writing this blog post I am using 1.17.3.
For someone who does not follow every single K8s release, it took me awhile to figure out what modifications were needed to resolve these issues and I have documented it here in case this benefits others.
The first issue that I ran into was the following:
no matches for kind "Deployment" in version "extensions/v1beta1"
This was an easy one after reading the 1.16 release notes, the use of "extensions/v1beta1" has been deprecated and simply needs to be replaced with "apps/v1"
The second issue that I ran into was not immediately clear on what fields it was expecting for "selector":
error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors, turn validation off with --validate=false
After a bit of searching around, I eventually found that the following snippet is now required for a Deployment Spec (replace X with the respective app label):
selector:
matchLabels:
app: X
Once these modifications were made, the Yelb application deployed successfully. For those NOT interested in the above details and just wish to deploy this K8s demo application, you can follow the instructions below which includes a modified version of yelb.yaml that you can apply directly.
Step 1 - Create yelb namespace:
kubectl create ns yelb
Step 2 - Deploy yelb application:
kubectl apply -f https://raw.githubusercontent.com/lamw/vmware-k8s-app-demo/master/yelb.yaml
Step 3 - Wait for all the pods to be running and then retrieve the ID for Yelb UI Pod
kubectl -n yelb get pods
Step 4 - Run the following command (substitute the ID in your environment) to retrieve the specific K8s node running the Yelb UI:
kubectl -n yelb describe pods yelb-ui-79c68df689-78z4g
Step 5 - Using a web browser from a system that has connectivity to the Pod network (load balancing is possible but this example is just directly accessing the K8s Node), navigate to http://[POD-IP]:30001 to access Yelb UI.
This helped me a lot