What is Knative? Learn How To Install and Use Knative with Zero YAML

Blog post cover

Introduction

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:

>  kubectl get pods -n knative-serving
NAME                                READY   STATUS      RESTARTS   AGE
activator-869f6d4f9f-jxxfn          1/1     Running     0          118m
autoscaler-78994c9fdf-97c7k         1/1     Running     0          118m
controller-b94c5b667-cn2sm          1/1     Running     0          117m
default-domain-btzn4                0/1     Completed   0          117m
networking-istio-5847754959-p7g78   1/1     Running     0          117m
webhook-7cdb467d79-9mgf2            1/1     Running     0          117m

> kubectl get pods -n knative-eventing
NAME                                   READY   STATUS    RESTARTS   AGE
broker-controller-b85986f7d-8lzwn      1/1     Running   0          117m
eventing-controller-58b889c4b4-gdt67   1/1     Running   0          118m
eventing-webhook-5549c4b664-ltq69      1/1     Running   0          118m
imc-controller-64cfbf485d-7jz2j        1/1     Running   0          117m
imc-dispatcher-5fc7ccf7d8-6jbfr        1/1     Running   0          117m

> kubectl get pods -n knative-monitoring
NAME                                  READY   STATUS    RESTARTS   AGE
grafana-5cb855689f-frgfc              1/1     Running   0          113m
kube-state-metrics-5cb5c6986b-t7m7w   1/1     Running   0          113m
node-exporter-8tn78                   2/2     Running   0          113m
node-exporter-mz5kk                   2/2     Running   0          113m
node-exporter-wjfvd                   2/2     Running   0          113m
prometheus-system-0                   1/1     Running   0          113m
prometheus-system-1                   1/1     Running   0          113m

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

> kn service create helloworld --image gcr.io/knative-samples/helloworld-go
> kn service list
NAME         URL                                                 LATEST          AGE    CONDITIONS   READY   REASON
helloworld   http://helloworld.default.127.127.127.127.xip.io   helloworld-10   110m   3 OK / 3     True

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.127.127.127.127.xip.io (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?

> kubectl get pod
No resources found in default namespace.

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:

> watch kubectl get pod

Then hit our helloworld app with curl in another:

> curl http://helloworld.default.127.127.127.127.xip.io
Hello World!

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

> watch kubectl get pod
NAME                                        READY   STATUS    RESTARTS   AGE
helloworld-10-deployment-6844684bdf-zdgxb   2/2     Running   0          10s

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!

References:

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.

This educational content is brought to you by Relay.sh. Relay is an event-driven automation platform that pulls together all of the tools and technologies you need to effectively manage your DevOps environment.