homeblogusing knative with zero yaml

Install and Use Knative with Zero YAML.


If you have some experience with Kubernetes, you will appreciate its power but also its complexity. A no-ops world with Kubernetes seems utopian. You wish there was something simpler, finally giving developers the power to self-service. Fortunately, Knative has been designed exactly with this purpose in mind: give developers a simple way to deploy and manage their services, abstracting away the more ops-y Kubernetes concepts such as pods, nodes and ingress.

Since you are busy pushing new releases to production and don’t have any time to waste, this article will try to present Knative to you using the path of least resistance. We’ll favor implicit defaults over completeness and imperative commands over yaml declarations.

Knative: A simpler way to deploy and manage services Knative: A simpler way to deploy and manage services

Knative provides two high-level abstractions Knative Serving is a set of components for deploying and managing revisions of stateless Web microservices. Think “one command to deploy an app and provide an url to access it”. This article will concentrate on the serving component. Knative Eventing is a framework for configuring event pipelines between various microservices. We will leave Knative Eventing out of scope for this article.

So let’s jump in.

Installing Knative

By far the easiest Knative installation method I found is to follow this excellent setup guide by Mete Atamel. It assumes GKE (Google Kubernetes Engine) but will also work on other K8S implementations.

After installing, make sure you check that everything is running properly by executing the following three commands:

You can also run the “./check-versions” script provided in the setup folder. This article was written using version 0.13 of Knative.

Knative CLI: kn

This article will use Knative CLI called kn for the experiments because it’s the easiest way to interact with Knative. It is of course also possible to interact with Knative using kubectl if you so prefer. Since I promised you “zero-yaml”, that is left as an exercise to the reader.

Let’s go ahead and deploy a sample “Hello World” application.

Deploying a Knative service

That’s impressive. We have deployed a web microservice with one command and we now have an URL we can use to access it: http://helloworld.default. (IP address replaced by a fake one to prevent misunderstandings). Note that xip.io is the “magic” DNS provider which is automatically configured during this demo setup. Xip resolves names with the pattern *.[ip].xip.io to IP address [ip].

Let’s “peek under the hood” on the Kubernetes level to see what is happening. Did Knative actually create a pod for us?

Hmm, we don’t have any pods running! How does our microservice work, then?

Let’s start a constantly-refreshed list of pods in one terminal:

Then hit our helloworld app with curl in another:

It worked, the app returned the string “Hello World!”. Our watch now shows a running pod:

So Knative started our service when we actually accessed it! And what’s more, if we wait another 60 seconds, the pod will disappear — Knative scales back to zero if the service is not used. This is an example of autoscaling from 0 to 1 and back to 0.

I hope this was useful to readers as an introduction to installing and running a “Hello World” example with Knative. Please tune into the rest of this series as I share more with readers on how to do Canary and Blue/Green deployments and more!


If you are interested in moving your CI/CD pipeline to Kubernetes, check out the Tekton blog by Eric Sorenson. Fun fact: Tekton originated from a third component of Knative, “Build”, which has since then moved away from Knative into the Tekton project.