Knative基本概念

Object

Knative offers a set of reusable components that focuses on solving many mundane but difficult tasks such as orchestrating source-to-container workflows, routing and managing traffic during deployment, auto-scaling your workloads, or binding running services to eventing ecosystems.

Serving : Scale to zero, request-driven compute model

Build : Cloud-native source to container orchestration

Events : Universal subscription, delivery and management of events

Serving

The Knative Serving project provides middleware primitives that enable:

• Rapid deployment of serverless containers

• Automatic scaling up and down to zero

• Routing and network programming for Istio components

• Point-in-time snapshots of deployed code and configurations

Knative Serving defines a set of objects as Kubernetes Custom Resource Definitions (CRDs). These objects are used to define and control how your serverless workload behaves on the cluster:

• Service: The service.serving.knative.dev resource automatically manages the whole lifecycle of your workload. It controls the creation of other objects to ensure that your app has a route, a configuration, and a new revision for each update of the service. Service can be defined to always route traffic to the latest revision or to a pinned revision.

• Route: The route.serving.knative.dev resource maps a network endpoint to a one or more revisions. You can manage the traffic in several ways, including fractional traffic and named routes.

• Configuration: The configuration.serving.knative.dev resource maintains the desired state for your deployment. It provides a clean separation between code and configuration and follows the Twelve-Factor App methodology. Modifying a configuration creates a new revision.

• Revision: The revision.serving.knative.dev resource is a point-in-time snapshot of the code and configuration for each modification made to the workload. Revisions are immutable objects and can be retained for as long as useful.

image

The primary resources in the Knative Serving API are Routes, Revisions, Configurations, and Services:

• A Route provides a named endpoint and a mechanism for routing traffic to

• Revisions, which are immutable snapshots of code + config, created by a

• Configuration, which acts as a stream of environments for Revisions.

• Service acts as a top-level container for managing the set of Routes and Configurations which implement a network service.

Route provides a network endpoint for a user's service

Revision is an immutable snapshot of code and configuration. Revisions are created by updates to a Configuration.

A Configuration describes the desired latest Revision state, and creates and tracks the status of Revisions as the desired state is updated. A configuration might include instructions on how to transform a source package (either git repo or archive) into a container by referencing a Build, or might simply reference a container image and associated execution metadata needed by the Revision.

A Service encapsulates a set of Routes and Configurations which together provide a software component. Service exists to provide a singular abstraction which can be access controlled, reasoned about, and which encapsulates software lifecycle decisions such as rollout policy and team resource ownership. Service acts only as an orchestrator of the underlying Routes and Configurations (much as a kubernetes Deployment orchestrates ReplicaSets), and its usage is optional but recommended.

The Service's controller will track the statuses of its owned Configuration and Route, reflecting their statuses and conditions as its own.

The owned Configurations' Ready conditions are surfaced as the Service's ConfigurationsReady condition. The owned Routes' Ready conditions are surfaced as the Service's RoutesReady condition.

Build

This repository contains a work-in-progress build system that is designed to address a common need for cloud native development.

While Knative builds are optimized for building, testing, and deploying source code, you are still responsible for developing the corresponding components that:

• Retrieve source code from repositories.

• Run multiple sequential jobs against a shared filesystem, for example:

  • Install dependencies.

  • Run unit and integration tests.

• Build container images.

• Push container images to an image registry, or deploy them to a cluster.

Key features of Knative Builds

• A Build can include multiple steps where each step specifies a Builder.

• A Builder is a type of container image that you create to accomplish any task, whether that's a single step in a process, or the whole process itself.

• The steps in a Build can push to a repository.

• A BuildTemplate can be used to defined reusable templates.

• The source in a Build can be defined to mount data to a Kubernetes Volume, and supports:

  • git repositories

  • Google Cloud Storage

  • An arbitrary container image

• Authenticate with ServiceAccount using Kubernetes Secrets.

Example:

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: example-build
spec:
  serviceAccountName: build-auth-example
  source:
    git:
      url: https://github.com/example/build-example.git
      revision: master
  steps:
  - name: ubuntu-example
    image: ubuntu
    args: ["ubuntu-build-example", "SECRETS-example.md"]
  steps:
  - image: gcr.io/example-builders/build-example
    args: ['echo', 'hello-example', 'build']

What is a Builder?
A Builder image is a special classification for images that run as a part of the Build CRD's steps:.
For example, in the following Build the images, gcr.io/cloud-builders/gcloud and gcr.io/cloud-builders/docker are "Builders".:

spec:
  steps:
  - image: gcr.io/cloud-builders/gcloud
    ...
  - image: gcr.io/cloud-builders/docker
    ...

https://github.com/googlecloudplatform/cloud-builders
https://github.com/googlecloudplatform/cloud-builders-community