Containers

Knative 0.8.0 and Build Deprecation

Knative 0.8.0 came out a couple of weeks ago with a number of fixes and improvements. One of the biggest changes in 0.8.0 is that Knative Build is now deprecated according to docs:

Knative Installation docs also only include Knative Serving and Eventing without mentioning Build:

kubectl apply   
\-f https://github.com/knative/serving/releases/download/v0.8.0/serving.yaml \\  
\-f https://github.com/knative/eventing/releases/download/v0.8.0/release.yaml \\  
\-f https://github.com/knative/serving/releases/download/v0.8.0/monitoring.yaml

Good to know but there’s no explanation on why Knative Build was deprecated and any guidance on what is the replacement, if any. After a little bit of research, I have more information on deprecation and also a migration path that I’d like to share in this post.

When I talk about Knative, I often get questions on how to migrate an app from Kubernetes Deployment (sometimes with Istio) to Knative and what are the differences between the two setups.

First of all, everything you can do with a Knative Service, you can probably do with a pure Kubernetes + Istio setup and the right configuration. However, it’ll be much harder to get right. The whole point of Knative is to simplify and abstract away the details of Kubernetes and Istio for you.

As you might have heard, Knative 0.7 was out last week. One of the notable changes in this release is that Knative Serving API progressed from v1alpha to v1beta. While you can still use the old v1alpha1 API, if you want to update to v1beta, you need to rewrite your Knative service definition files. The new API also allows named revisions, silent latest deploys and a better traffic splitting configuration. In this post, I want to outline some of these changes.

I previously talked about Knative Build and how it enables you to go from source code to a container image in a repository. You can write your Build from scratch or you can rely on many of the BuildTemplates Knative already provides. For example, in my Knative Tutorial, I show how to install Kaniko BuildTemplate and use Kaniko to build container images.

You normally need to write a Dockerfile, so Knative Build (or Kaniko to be more precise) knows how to build the container image. Wouldn’t it be great if there was a an automatic way to build your app without having to define a Dockerfile ? Well, there is!

In Part 1, I talked about Knative Serving for rapid deployment and autoscaling of serverless containers. In Part 2, I talked about how to connect services in a loosely coupled way with Knative Eventing.

In third and last part of the series, I want to talk about Knative Build and show a few examples from my Knative Tutorial.

What is Knative Build?

Knative Build basically allows you to go from source code to a container image in a registry. For example, you can write a build to obtain your source code from a repository, build a container image, push that image to a registry and then run that image, all within the Kubernetes cluster.

I’ve been looking into Knative recently. In this 3-part blog series, I want to explain my learnings and show some hands on examples from the Knative Tutorial that I published on GitHub.

What is Knative anyway?

Knative is a collection of open source building blocks for serverless containers running on Kubernetes.

At this point, you might be wondering: “Kubernetes, serverless, what’s going on?” But, when you think about it, it makes sense. Kubernetes is hugely popular container management platform. Serverless is how application developers want to run their code. Knative brings the two worlds together with a set of building blocks.

When learning a new technology like Istio, it’s always a good idea to take a look at sample apps. Istio repo has a few sample apps but they fall short in various ways. BookInfo is covered in the docs and it is a good first step. However, it is too verbose with too many services for me and the docs seem to focus on managing the BookInfo app, rather than building it from ground up. There’s a smaller helloworld sample but it’s more about autoscaling than anything else.

Last week, I was in one of my favorite cities, Rome, for Codemotion conference. There are many cities to see in the world and normally, I do not like to revisit cities that I’ve been before. However, Rome is a great exception. It was my fifth visit there over the years and it was still as exciting as the first time. I also found out that Google has a small office in Rome, so I paid a quick visit next morning before attending the conference.