The point of this post is to show that knative is part of The Tanzu Application Platform, AKA TAP, and one can use knative outside of TAP, directly with the kn CLI, if desired. (Though, in the real world you would probably use the rest of TAP as well, but it’s modular so you don’t have to.)
In this post TAP has been deployed into a GKE cluster (yep, a GKE cluster). TAP includes knative, so in this post I’ll deploy a simple demo app into the GKE cluster and that deployment will be done via the knative CLI. Serverless here we come!
First, as I mentioned, I’ve got a Google Kubernetes Cluster.
$ k get nodes
NAME STATUS ROLES AGE VERSION
gke-gke-tap-1-default-pool-4e593ad2-9dk4 Ready <none> 4d2h v1.22.3-gke.700
gke-gke-tap-1-default-pool-4e593ad2-m8qs Ready <none> 4d2h v1.22.3-gke.700
gke-gke-tap-1-default-pool-8dc7b056-8g1l Ready <none> 4d2h v1.22.3-gke.700
gke-gke-tap-1-default-pool-8dc7b056-drtd Ready <none> 4d2h v1.22.3-gke.700
gke-gke-tap-1-default-pool-bb825ba8-3pgz Ready <none> 4d2h v1.22.3-gke.700
gke-gke-tap-1-default-pool-bb825ba8-6v55 Ready <none> 4d2h v1.22.3-gke.700
It has a bunch of nodes and is running the “full” TAP profile.
VMware Tanzu Application Platform is a modular, application-aware platform that provides a rich set of developer tooling and a prepaved path to production to build and deploy software quickly and securely on any compliant public cloud or on-premises Kubernetes cluster.
TAP is a set of modular components which extend Kubernetes, making it easier and more secure to use. It’s important to understand that underlying TAP is still Kubernetes–all the pieces of TAP are “native” Kubernetes which means they become part of the Kubernetes API. The way we interact with TAP is through the Kubernetes API, though that will often be hidden away by pipelines and developer inner loop tooling. (No one should have to use kubectl, but you can of course.)
For an example of extending Kubernetes, once you’ve deployed TAP you have an image resource, which, in plain old vanilla Kubernetes, doesn’t exist. (NOTE: I believe the power of Kubernetes is not so much in orchestrating containers, instead the fact that it is a platform to build other platforms on top of, which is precisely what TAP is…it’s even in the name!).
Below I have a couple of container images represented in Kubernetes for a demo application for Spring called Pet Clinic, which can be deployed via knative through TAP. knative is part of what VMware Tanzu calls Cloud Native Runtimes
Here I ask what Kubernetes knows about container images.
$ k get images
NAME IMAGE
pet-clinic-00001-cache-workload <registry>/tap-beta-4/supply-chain/pet-clinic-default@sha256:3b4ef38a43d464750d63ca0226c67ae59fdf990efe01c37ae88e8e10d2f574e8
pet-clinic-00002-cache-workload <registry>/tap-beta-4/supply-chain/pet-clinic-default@sha256:edfeabd87ee782f06510a0f1bc984a6134ae923121a6437cd5f401c59ff815de
NOTE: The images resource is provided by the Tanzu Build Service (also part of TAP), which itself is built on the open source projects kpack and Paketo and years of history and experience with Cloud Foundry and Buildpacks.
But that’s just an example of how we build a platform on Kubernetes, in this post I’ll try to stay focussed on knative.
Cloud Native Runtimes is VMware’s product to provide various ways of running applications in Kubernetes. Currently there is only the single runtime, knative, but more will be added over time.
So what’s knative? It’s an open source project that makes developers more productive by abstracting away some of the complexity of Kubernetes.
Knative components build on top of Kubernetes…by codifying the best practices shared by successful real-world implementations, Knative solves the “boring but difficult” parts of deploying and managing cloud native services so you don’t have to. - knative website
knative provides:
I’d like to look specifically at just running a serverless app in knative, which in this case is easily provided/installed into Kubernetes by TAP. (That said, eventing is clearly important to modern applications, so it’s important to keep in mind that knative satisfies that need as well.)
In our GKE cluster we have many packages from TAP installed, including knative, aka Cloud Native Runtimes. That means we can run serverless workloads!
$ tanzu package installed list --namespace tap-install
\ Retrieving installed packages...
NAME PACKAGE-NAME PACKAGE-VERSION STATUS
accelerator accelerator.apps.tanzu.vmware.com 1.0.0 Reconcile succeeded
api-portal api-portal.tanzu.vmware.com 1.0.8 Reconcile succeeded
appliveview run.appliveview.tanzu.vmware.com 1.0.1 Reconcile succeeded
appliveview-conventions build.appliveview.tanzu.vmware.com 1.0.1 Reconcile succeeded
buildservice buildservice.tanzu.vmware.com 1.4.2 Reconcile succeeded
cartographer cartographer.tanzu.vmware.com 0.1.0 Reconcile succeeded
cert-manager cert-manager.tanzu.vmware.com 1.5.3+tap.1 Reconcile succeeded
cnrs cnrs.tanzu.vmware.com 1.1.0 Reconcile succeeded
contour contour.tanzu.vmware.com 1.18.2+tap.1 Reconcile succeeded
conventions-controller controller.conventions.apps.tanzu.vmware.com 0.5.0 Reconcile succeeded
developer-conventions developer-conventions.tanzu.vmware.com 0.5.0-build.1 Reconcile succeeded
fluxcd-source-controller fluxcd.source.controller.tanzu.vmware.com 0.16.0 Reconcile succeeded
grype grype.scanning.apps.tanzu.vmware.com 1.0.0 Reconcile succeeded
image-policy-webhook image-policy-webhook.signing.apps.tanzu.vmware.com 1.0.0 Reconcile succeeded
learningcenter learningcenter.tanzu.vmware.com 0.1.0 Reconcile succeeded
learningcenter-workshops workshops.learningcenter.tanzu.vmware.com 0.1.0 Reconcile succeeded
metadata-store metadata-store.apps.tanzu.vmware.com 1.0.1 Reconcile succeeded
ootb-delivery-basic ootb-delivery-basic.tanzu.vmware.com 0.5.1 Reconcile succeeded
ootb-supply-chain-basic ootb-supply-chain-basic.tanzu.vmware.com 0.5.1 Reconcile succeeded
ootb-templates ootb-templates.tanzu.vmware.com 0.5.1 Reconcile succeeded
scanning scanning.apps.tanzu.vmware.com 1.0.0 Reconcile succeeded
service-bindings service-bindings.labs.vmware.com 0.6.0 Reconcile succeeded
services-toolkit services-toolkit.tanzu.vmware.com 0.5.0 Reconcile succeeded
source-controller controller.source.apps.tanzu.vmware.com 0.2.0 Reconcile succeeded
spring-boot-conventions spring-boot-conventions.tanzu.vmware.com 0.3.0 Reconcile succeeded
tap tap.tanzu.vmware.com 1.0.0 Reconcile succeeded
tap-gui tap-gui.tanzu.vmware.com 1.0.1 Reconcile succeeded
tap-telemetry tap-telemetry.tanzu.vmware.com 0.1.2 Reconcile succeeded
tekton-pipelines tekton.tanzu.vmware.com 0.30.0 Reconcile succeeded
That’s a lot of stuff. Those pieces are currently part of the Tanzu Application Platform. But lets just use a single piece: knative.
First I’ve got the kn CLI.
$ which kn
/usr/local/bin/kn
Next I’ll create a namespace (and switch to it).
$ kubectl create namespace cnr-demo
Then I’ll setup a reg secret because my registry requires authentication.
$ kubectl create secret docker-registry registry-credentials \
--docker-server=<redacted> \
--docker-email=<redacted> \
--docker-username=<redacted> \
--docker-password=<redacted>
Allow the namespace’s default SA to use it…
$ kubectl patch serviceaccount default -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}"
Now deploy a workload, pointing to an image that resides in the registry I previously setup secret credentials for.
$ kn service create hello-yeti -n cnr-demo \
--image <registry>/hello-yeti --env TARGET='hello-yeti'
Output:
$ kn service create hello-yeti -n cnr-demo --image <registry>/hello-yeti --env TARGET='hello-yeti'
Creating service 'hello-yeti' in namespace 'cnr-demo':
0.043s The Route is still working to reflect the latest desired specification.
0.091s ...
0.148s Configuration "hello-yeti" is waiting for a Revision to become ready.
5.639s ...
5.712s Ingress has not yet been reconciled.
5.756s Waiting for Envoys to receive Endpoints data.
6.108s Waiting for load balancer to be ready
6.329s Ready to serve.
Service 'hello-yeti' created to latest revision 'hello-yeti-00001' is available at URL:
http://hello-yeti.cnr-demo.example.com
Once that deploys there will be a pod running.
NOTE: The deployment will scale to zero if it’s not being used, something to remember.
$ k get pods
NAME READY STATUS RESTARTS AGE
hello-yeti-00001-deployment-6f49f84f5-z6lgq 2/2 Running 0 13s
List the knative deployments/services.
$ kn service list
NAME URL LATEST AGE CONDITIONS READY REASON
hello-yeti http://hello-yeti.cnr-demo.example.com hello-yeti-00001 3m48s 3 OK / 3 True
Curl the app.
NOTE: TAP also deploys an ingress controller for you. To connect to the knative service we’ll need the IP of the Kubernetes loadbalancer for the ingress service.
$ export LB=`kubectl get services -n tanzu-system-ingress envoy -o jsonpath="{.status.loadBalancer.ingress[0].ip}"`
$ curl -H "Host: hello-yeti.cnr-demo.example.com" $LB
Output:
$ curl -H "Host: hello-yeti.cnr-demo.example.com" $LB
______________
/ \
| hello from |
| cloud native |
| runtimes | .xMWxw.
\______________\ | wY Ym.
\| C , , O
\ ww /.
..x x..
.x wwwww x.
.x x.
x \ / x
Y Y Y Y
wwv x vww
\ /\ /
:www: :www:
If the application isn’t accessed for a while it’ll scale to zero.
$ k get pods
No resources found in cnr-demo namespace.
If we try to hit the URL again, the pods will be restarted automatically by knative.
So, that was pretty easy. Of course it’s a simple demo application which lives in an existing container image, but the point of this post was to illustrate that by deploying TAP we have access to knative, and we can even use knative outside of the TAP workflow if we want, or deploy it outside of TAP as well. knative is a major part of VMware Tanzu.
The Tanzu Application Platform gives you cutting edge tools like serverless via knative. Now, the point of TAP isn’t necessarily to just directly use knative like this, but I wanted to show that knative is indeed part, an integral part, of TAP, that you can use if you want to (by default most TAP demos will use knative) but you don’t have to use it.
Another thing to keep in mind in the context of this post, is exactly where did that hello-yeti container image come from? What if we want to deploy our own code? Not surprisingly, I’ll look into that in the next post in this series.
Thanks for reading!