在该系列的第一篇文章中，主要介绍了Knative的基本概念及诞生背景，并提到Knative主要由Build、Serving和Eventing三大核心组件组成，本文将重点Build的使用方法。

具体来说，Build提供源码到容器镜像的构建能力；Serving提供Serverless应用或函数的部署能力，并通过istio实现服务管理，同时提供了容器扩缩容能力；Eventing：提供事件触发通道。

Knative的这三个组件提供了一套完善的Serverless方案，让开发者可以只关心自己的代码。提交代码以后，Build会将源码构建成镜像，Serving会自动实现应用部署，Eventing提供事件触发入口，接下来就可以访问到最新应用了。对使用者来说，从源码直接到应用，省去了中间复杂的环节。

Build完全基于Kubernetes，设计非常灵活，用户可以利用Build定制构建流程，虽然官方文档宣称现在Knaitve还不能提供完整的CI/CD方案，但是利用Build的灵活性完全可以实现CI平台搭建，这部分内容会在后面的实现中着重介绍。

本文，我们把Build组件拆开揉碎，全面分享给读者。如果现在手头刚好有一个K8s集群，可以跟着文档尝试操作，整个过程甚至不需要占用一杯咖啡的时间。

Build组件安装

Build可以作为一个独立组件单独安装，只需要在K8s的集群中执行以下命令即可：

   kubectl apply --filename https://github.com/knative/build/releases/download/v0.6.0/build.yaml

执行成功以后，可以通过以下命令查看：

kubectl get pods --namespace knative-build

可以看到，在knative-build的namespace下，新增了两个容器 build-controller和build-webhook，build-controller是Build核心模块，其基本业务流程是监控自己创建的CRD资源从而实现构建，build-webhook和大多数的webhook功能一样，通过webhook的方式对自己的api进行校验。

到这里恭喜你，Build组件已经安装成功了，接下来就可以利用它来进行构建。

build和buildtemplate

构建之前，我们需要先了解两个概念：build和buildtemplate。这里的build不是knative的Buid组件，而是Build组件通过CRD定义的一个资源文件，build通过自己定义资源文件去控制构建流程，所以说，Build完全基于K8s生态，只要有K8s集群就可以完成构建而不需要依赖其他外部组件，同时，yaml定义的资源文件也可以很轻易的移植到其他集群上去。

为了方便理解，我们先看一个build的yaml文件：

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: kaniko-build
spec:
  serviceAccountName: build-bot   //如果源码或者仓库为公开可以不用创建serviceAccount
  source:
    git:
      url: https://github.com/my-user/my-repo   //你的源码仓库地址
      revision: master                          //你的源码分支地址
  template:
    name: kaniko                                
    arguments:
    - name: IMAGE
      value: us.gcr.io/my-project/my-app         //构建成功以后镜像存放的镜像仓库地址

以下是其中的几个关键配置：

serviceAccountName	需要先创建一个serviceAccount资源，里边包含了构建过程中拉取代码或者pull/push镜像的认证信息，如果你的代码和镜像都放在一个公开的仓库里则可以不用定义这个资源。
source	source中指定了你的代码源，revision是代码的分支
template	使用的buildtemplate的名称，也是由build定义的一个CRD资源

如果想在自己的代码仓库尝试用build进行构建，只需要修改上面蓝色的部分即可。看起来，build.yaml非常简单，而且在yaml中也没有看到关于构建过程的体现，是因为在这个build.yaml里定义了一个buildtemplate，buildtemplate中定义了实际构建过程中的steps（关于steps的内容我们稍后会讲到），当我有多个代码库，或者代码库下有多个分支，抑或是代码想用不同的方式去构建，每次都要定义一个完整的build文件就显得非常麻烦，这个时候利用buildtemplate可以定义很多构建模板，然后只需要像上面的build.yaml一样简单指定代码仓库即可。那么，buildtemplate是必须的么？当然不是，我们可以直接把steps写在buid.yaml里，但是buildtemplate极大的提高了build的灵活性和可移植、可重用性。为了方便快速实现构建，knative的build-template代码库中已经预置了大量的buildtemplate，包括bazel，buildpacks，kaniko等近十个模板，这里我们先用Kaniko的build-template体验一下build的构建过程。

Kaniko是Google推出的构建工具，它基于Dockerfile进行构建但是却不需要docker daemon，我们先来看一下Kaniko的buildtemplate是什么样子。

apiVersion: build.knative.dev/v1alpha1
kind: BuildTemplate
metadata:
  name: kaniko
spec:
  parameters:
  - name: IMAGE
    description: The name of the image to push
  - name: DOCKERFILE
    description: Path to the Dockerfile to build.
    default: /workspace/Dockerfile
  steps:
  - name: build-and-push
    image: gcr.io/kaniko-project/executor
    args:
    - --dockerfile=${DOCKERFILE}
    - --destination=${IMAGE}
    env:
    - name: DOCKER_CONFIG
      value: /builder/home/.docker

buildtempate中也有几个关键配置：

steps	定义构建的步骤
builder	builders就是每个steps中定义的image，每个step中必须要定义一个builder，builder是steps具体的执行者，后续在到build的实现中我们可以看到为什么每个step一定要去指定一个image

kaniko的buildtemplate十分简单，只有一个step，然后传入两个参数DOCKERFILE和IMAGE即可，DOCKERFILE是工程中dockerfile所在的文件路径，IMAGE是要推送的镜像仓库地址。

这两个文件都准备好以后你只需要执行以下两条命令,一切顺利的话一段时间时候以后，你就可以在你的镜像仓库里看到你刚刚构建好的镜像了。

kubectl create -f kaniko.yaml
kubectl create -f build.yaml

如果只是想体验一次Build带来的基于原生K8S的快捷构建，到这里你的体验之旅就已经结束了，如果想问到底执行完以后发生了什么，那就再花点时间看看到底发生了什么？

Build构建实现

在上述步骤创建完build.yaml以后执行

kubectl get pod

我们发现多出了一个pod，用describe查看POD可以看到以下信息：

Name:               kaniko-build-pod-a4f897
Namespace:          default
Controlled By:      Build/kaniko-build
Init Containers:
build-step-credential-initializer:
Image:          gcr.io/knative-releases/github.com/knative/build/cmd/creds-init@sha256:101f537b53b895b28b84ac3c74ede7d250845e24c51c26516873d8ccb23168ce
	  .......
	  build-step-git-source-0:
	    Image:         gcr.io/knative-releases/github.com/knative/build/cmd/git-init@sha256:ce2c17308e9cb81992be153861c359a0c9e5f69c501a490633c8fe54ec992d53
	    Args:
	      -url
	      https://github.com/lihua871205/2048.git
	      -revision
	      master
	  ......
	  build-step-build-and-push:
	    Image:         gcr.io/kaniko-project/executor
	    Args:
	      --dockerfile=/workspace/Dockerfile
	      --destination=swr.cn-north-1.myhuaweicloud.com/l00283074/sample:latest
	  ......

POD里边包含三个Init Containers：build-step-credential-initializer， build-step-git-source-0以及build-step-build-and-push

build-step-credential-initializer：如果git和docker需要认证的对git和docker进行认证
build-step-git-source-0：负责将代码拉取到workspace下
build-step-build-and-push：是用户自己定义的构建step，它负责将源码构建成镜像

从这里，我们可能已经猜到build的构建实现，利用Init Containers的特性，build先将source中的配置生成一个默认的build-step-git-source-0接下来再将用户step中配置的信息依次解析成多个Init Containers，当POD运行的时候会依次执行所有的Init Containers从而实现代码获取，源码构建的流程。这也回答了上面的两个问题：

1、为什么每个step都要有一个builder？这是Init Containers的特性决定的，即使是Source这个步骤其实也是使用了Build-Controller内置的一个镜像；

2、为什么build非常灵活？用户可根据自己的场景，自己定制构建镜像，Build只提供构建流程，但是不提供构建实现，这也是为什么当前有这么多buildtemplate的原因。我们再回顾下Build的基本流程：

总结

Knative的Build利用init container实现了一个基于K8s生态的构建流程，用户可以自己定制构建场景，或者利用丰富的build-template实现构建，它可以作为一个独立的组件减少K8s构建的烦恼，更重要的是可以嵌入到serving中（偷偷预告一下后面的章节会讲到build如何和serving集成到一起）形成完整的Serverless生态，只有通过Build快捷地将源码变成镜像，才能让serving有源源不断的“粮草”大展身手。

相关文章：《Knative 系列（一）：基本概念和原理解读》

创作场景

Knative 系列（二）：兵马未动粮草先行之 Build 篇