Knative Fundamentals and basic Concepts (Part 1)

Knative Fundamentals and basic Concepts (Part 1)

Knative is an open-source project based on Kubernetes platform that creates, deploys, and manages modern Serverless workload.

One of the objectives of Knative is to help cloud service providers and enterprise platform providers offer service experiences associated with Serverless to any cloud developers or operators. Knative utilizes the concept of Kubernetes to build functions and applications, using Istio to implement network routing in a cluster and to enter external connection of services. This allows developers to develop and to build program with ease. Currently Knative components focus on solving many ordinary but difficult problems as follows:

  • Orchestrating source-to-URL Workflows on Kubernetes
  • Using Blue/Green Deployment to route and manage traffic.
  • Scaling and sizing workloads automatically whenever required.
  • Binding running services with eventing ecosystems.
  • Utilizing source code to create program or functions
  • Allowing zero-downtime upgrade of applications
  • Automatically increasing or decreasing application or function instances.
  • Triggering function calls through HTTP request.
  • Creating events for functions, applications, and containers.

When designing Knative, developers considered different scenarios for different users:

While Knative contains the features provided by Kubernetes and Istio, it also has three components for a complete serverless platform. The following paragraph will describe it in detail.

Knative Components and Concepts

For now, Knative comprises the following components to handle different requests. This paragraph will describe the details of the components.


Build is a self-defined resource in Kubernetes. It offers Build API object to deal with pluggable model for building container from source code, which is based on Google’s container builder service. It not only allows developers to define container sources to package, such as Git, and Registry (ex: Docker hub), but also enables Buildpacks to be a plugin to use. Furthermore, it facilitates Knative to have flexible scalability. In addition to Buildpacks, you can also use Google Container Builder, Bazel, Kaniko, and Jib as plug-ins.

The following describes the features of Knative Build:

  • A Build consists of multiple steps; each step will specify a Builder.
  • A builder is a container image, which can be created to accomplish any tasks, such as a single step of the workflow, or the workflow.
  • The steps of a Build can push to a repository.
  • A BuildTemplate can be used to define reusable template.
  • You can define source in a Build to mount the files or project to Kubernetes Volume (mounted as /workspace). Right now, it supports:
    • Git repository
    • Google Cloud Storage
    • Any container image files
  • You can Authenticate identity by using Kubernetes Secrets with Service Account.

The step here can be considered as init-container of Kubernetes. A Build example including multiple steps and Git repo, is used to authenticate users’ identity as follows:

apiVersion: kind: Build metadata: name: example-build spec: serviceAccountName: build-auth-example source: git: url: revision: master steps: - name: ubuntu-example image: ubuntu args: ["ubuntu-build-example", ""] steps: - image: args: ['echo', 'hello-example', 'build']


Serving is designed based on Kubernetes and Istio. It implements the middleware primitives to achieve the automatic workflow from container to function execution. It also supports rapidly deployed container, automatic scaling up and down to zero, routing and network programming for Istio components, and point-in-time snapshots of deployed code and configurations. Additionally, it delivers zero-downtime upgrade, blue/green deployment, partial load tests, and source code rollback features.

According to the above figure, you can understand that serving utilizes Kubernetes Custom Resource Definitions (CRDs) to add a set of APIs to define and control serverless behavior on Kubernetes. The primary resources in the Knative Serving API are listed below:

  • Service: Use to automatically manage the workload lifecycle, and provide single point control, which ensures the applications and functions to have a route, a configuration, and a revision for each update of service. Services can be defined to always route traffic to the latest revision, or to a pinned revision.
apiVersion: kind: Service metadata: name: service-example spec: runLatest: configuration: revisionTemplate: spec: container: image: env: - name: TARGET value: "Go Sample v1"
  • Route: Map the network endpoint to one or multiple revisions, and use many different ways to manage the traffic, such as fractional traffic and named routes.
apiVersion: kind: Route metadata: name: route-example spec: traffic: - configurationName: stock-configuration-example percent: 100
  • Configuration:Maintain required state for deployment. It provides a separation between source code and configuration, and follows the Twelve-Factor App method. If configuration is modified, it will create a new revision.
apiVersion: kind: Configuration metadata: name: configuration-example spec: revisionTemplate: metadata: labels: container spec: container: image: env: - name: RESOURCE value: stock readinessProbe: httpGet: path: / initialDelaySeconds: 3 periodSeconds: 3
  • Revision:Record a point-in-time snapshots of the code and configuration for each modification made to the workload. Revisions are immutable objects; they will be retained as long as they are useful.
apiVersion: kind: Revision metadata: labels: helloworld-go name: revision-example namespace: default spec: concurrencyModel: Multi container: env: - name: TARGET value: Go Sample v1 image: generation: 1 servingState: Active

Written By 白凱仁 迎棧科技資深工程師


Select list(s)*