Mete Atamel

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.

Introduction

If you’ve heard of Cloud Run, you already know that it’s great for spinning public endpoints inside stateless containers to handle HTTP request/reply type of workloads. And the best part is that you only pay for the duration of the request!

However, HTTP request/reply handling is not the only use-case for Cloud Run. Combined with Cloud Pub/Sub, Cloud Run is very well suited for internal async worker type use-cases because:

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 my Hands on Knative series (part 1, part 2, part 3), I showed how to use Knative Serving, Eventing and Build on any Kubernetes cluster anywhere. This is great for portability but with that portability comes the overhead of creating and managing a Kubernetes cluster. Not to mention the complexity of Istio which is a dependency of Knative.

Google Kubernetes Engine (GKE) helps with managing the Kubernetes cluster a little but you still need to worry about all the bells and whistles of a Kubernetes cluster. Wouldn’t it be great to have the Knative Serving experience without having to worry about the underlying infrastructure? Well, you can with Cloud Run!

TL;DR: I recently went through the preparation and exam of Google Cloud’s Professional Cloud Architect Certification. It was great learning experience and I highly recommend it. You can register here to get certified yourself!

Why?

As you might know, I’m a Googler and a Developer Advocate for Google Cloud. Why do I want to be certified by Google Cloud when I already work at Google and know a great deal about Google Cloud? I had 2 main motivations:

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.

In my previous post, I talked about Knative Serving for rapid deployment and autoscaling of serverless containers. Knative Serving is great if you want your services to be synchronously triggered by HTTP calls. However, in the serverless microservices world, asynchronous triggers are more common and useful. That’s when Knative Eventing comes into play.

In this second part of Hands on Knative series, I want to introduce Knative Eventing and show some examples from my Knative Tutorial on how to integrate it with various services.

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.

The default metrics sent by Istio are useful to get an idea on how the traffic flows in your cluster. However, to understand how your application behaves, you also need application metrics.

Prometheus has client libraries that you can use to instrument your application and send those metrics. This is good but it raises some questions:

• Where do you collect those metrics?
• Do you use Istio’s Prometheus or set up your own Prometheus?
• If you use Istio’s Prometheus, what configuration do you need to get those metrics scraped?

Let’s try to answer these questions.

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.