2. K8s 构建方式及代码生成器

1. kubernetes 构建方式

1.1 构建方式简介

Kubernetes构建方式可以分为3种：

本地环境构建（make, make all）
容器环境构建（make release, make quick-release）
Bazel环境构建（make bazel-build）
- Bazel 其实是一个构建工具，根maven、gradle这些构建工具类似。

在 kubernetes 的根目录下，有两个 Makefile 文件，分别是：

Makefile：顶层 Makefile 文件，描述了整个项目所有代码文件的编译顺序、编译规则及编译后的二进制输出等。
Makefile.generated_files：描述了代码生成的逻辑。

注意到，根目录下的这两个文件是一个软连接，连接到：

build/root/Makefile
build/root/Makefile.generated_files

1.1 构建方式 Makefile 过程分析

Makefile源码之代码生成器prerelease-lifecycle-gen

上图比较形象的把 Makefile 的各个依赖过程，以及主要的执行指令以流程图的方式展现出来。下面独立的方框是 prerelease-lifestyle-gen 代码生成器的构建过程，其他五个代码生成器的过程与这个相同，我就没有在画。可以对照这个流程图与后面的 Makefile 和构建脚本的源码一同分析。

2. 本地环境构建

本地环境构建比较简单，我这里在 ubuntu server 上执行的构建命令。这里 make 或者 make all 有一些可选的参数：

可以在 make 命令后面加 -n 参数，输出但不执行所有执行命令，这样可以展示更详细的构建过程。
如果需要单独构建某一个组件，则需要指定WHAT参数，例如：make WHAT=cmd/kubectl

下面是我直接 make all 的结果：

Copy to Clipboard

gsh@gsh-ubuntu:~/kubernetes-src/kubernetes-1.21.0$ make all
+++ [0508 09:14:34] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
Generating prerelease lifecycle code for 27 targets
+++ [0508 09:14:39] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/deepcopy-gen
Generating deepcopy code for 227 targets
+++ [0508 09:14:50] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/defaulter-gen
Generating defaulter code for 89 targets
+++ [0508 09:14:59] Building go targets for linux/amd64:
    ./vendor/k8s.io/code-generator/cmd/conversion-gen
Generating conversion code for 124 targets
+++ [0508 09:15:16] Building go targets for linux/amd64:
    ./vendor/k8s.io/kube-openapi/cmd/openapi-gen
Generating openapi code for KUBE
Generating openapi code for AGGREGATOR
Generating openapi code for APIEXTENSIONS
Generating openapi code for CODEGEN
Generating openapi code for SAMPLEAPISERVER
+++ [0508 09:15:30] Building go targets for linux/amd64:
    ./vendor/github.com/go-bindata/go-bindata/go-bindata
+++ [0508 09:15:31] Building go targets for linux/amd64:

...

执行 make 或 make all 命令，会编译 Kubernetes 的所有组件，组件二进制文件输出的相对路径是 _output/bin/。使用 make clean 会清理构建环境。

Copy to Clipboard

2.1 make all 源码分析（ Makefile 文件）

# 变量的初始化

Copy to Clipboard

# GOFLAGS 环境变量

Copy to Clipboard

注意：

GOFLAGS 变量表示：在执行 make all 或 make otherTargets 时，可以手动传入的编译时选项。例如：make all WHAT=cmd/kubelet GOFLAGS=-v 。就是在编译 go install 或 go test 添加的选项。

# make all 逻辑

Copy to Clipboard

# 定义 ALL_HELP_INFO 变量，其内容是 help 帮助信息
# 当使用 make help 时，target 为 all 的版主信息就是 ALL_HELP_INFO 变量的内容
define ALL_HELP_INFO
# Build code.
#
# Args:
#   WHAT: Directory names to build.  If any of these directories has a 'main'
#     package, the build will produce executable files under $(OUT_DIR)/bin.
#     If not specified, "everything" will be built.
#   GOFLAGS: Extra flags to pass to 'go' when building.
#   GOLDFLAGS: Extra linking flags passed to 'go' when building.
#   GOGCFLAGS: Additional go compile flags passed to 'go' when building.
#
# Example:
#   make
#   make all
#   make all WHAT=cmd/kubelet GOFLAGS=-v
#   make all GOLDFLAGS=""
#     Note: Specify GOLDFLAGS as an empty string for building unstripped binaries, which allows
#           you to use code debugging tools like delve. When GOLDFLAGS is unspecified, it defaults
#           to "-s -w" which strips debug information. Other flags that can be used for GOLDFLAGS 
#           are documented at https://golang.org/cmd/link/
endef

# 把 all 声明成 伪目标，也就是不会生成 target 文件
.PHONY: all
# PRINT_HELP 表示 如果是打印 帮助信息
ifeq ($(PRINT_HELP),y)
# 打印帮助信息
all:
	@echo "$$ALL_HELP_INFO"
else
# 开始编译，依赖 generated_files
# target generated_files 执行完后，执行 build.sh 脚本
all: generated_files
	hack/make-rules/build.sh $(WHAT)
endif

可以看到整个 makefile 文件的逻辑为：

首先定义 define 一个包含帮助信息的变量
如果 PRINT_HELP 变量为 y ，则直接打印帮助信息
如果 PRINT_HELP 不为 y ，则执行对应 target 的编译指令

注意：make all 的构建指令中，执行了 hack/make-rules/build.sh ，这个脚本在后面介绍。

其实 build.sh 就是编译的过程，并且传参就是需要编译的软件包，具体 build.sh 如何实现，在代码生成器 prerelease-lifecycle-gen 的源码分析中介绍。

# make generated_files 逻辑

Copy to Clipboard

这里 make all 执行的编译命令为：make -f Makefile.generated_files generated_files CALLED_FROM_MAIN_MAKEFILE=1 ，需要注意的是：

-f 指定了 make 使用的哪个 makefile，这里使用了另一个名字叫 Makefile.generated_files 的文件
指定了一个变量 CALLED_FROM_MAIN_MAKEFILE，这个变量表示，target generated_files 是从 main makefile 中调用的

2.2 make generated_files 源码分析（Makefile.generated_files文件）

Makefile.generated_files 文件是通过 Main Makefile 中的 target : generated_files 调用的，总体的依赖顺序为：

make all(Makefile) ->
make generated_files(Makefile) ->
make generated_files(Makefile.generated_files) ->
make {gen_prerelease_lifecycle gen_deepcopy gen_defaulter gen_conversion gen_openapi gen_bindata}(Makefile.generated_files)

# 变量的初始化

Copy to Clipboard

# 目标 generated_files 的逻辑

Copy to Clipboard

# 把 generated_files 设置成 伪目标，不会生成 target file
.PHONY: generated_files
# target generated_files 一共需要依赖6个target
generated_files: gen_prerelease_lifecycle gen_deepcopy gen_defaulter gen_conversion gen_openapi gen_bindata

# 设置了 kubernetes 整个项目中所用到的依赖文件，将所有依赖的库文件名及路径保存在文件 go-pkgdeps.mk 中
GO_PKGDEPS_FILE = go-pkgdeps.mk

# META_DIR 在 Main Makefile 中已经定义了，META_DIR := .make
# sinclude 函数表示导入另外的文件
# 这条命令也就是说，导入 .make/go-pkgdeps.mk 文件
sinclude $(META_DIR)/$(GO_PKGDEPS_FILE)

# 这里使用了 FORCE 关键字，来保证下面这一段每次都能够执行
# target 为 .make/go-pkgdeps.mk 文件，依赖 FORCE，FORCE 每次执行会更新，这里每次执行 make 时，都会重新生成 这个文件
$(META_DIR)/$(GO_PKGDEPS_FILE): FORCE
    # 如果 设置了 DBG_CODEGEN 则 打印一条信息
	if [[ "$(DBG_CODEGEN)" == 1 ]]; then          \
	    echo "DBG: calculating Go dependencies";  \
	fi
	# 执行命令 安装 go2make 软件包
	hack/run-in-gopath.sh go install ./hack/make-rules/helpers/go2make
	# 执行 go2make 命令，会生成一个  .make/go-pkgdeps.mk.tmp 文件
	# go2make工具会计算一组 Go 软件包的所有依赖关系并打印，将打印结果重定向到 .make/go-pkgdeps.mk.tmp 文件
	hack/run-in-gopath.sh go2make                       \
	    k8s.io/kubernetes/...                           \
	    --prune  k8s.io/kubernetes/staging              \
	    --prune  k8s.io/kubernetes/vendor               \
	    k8s.io/kubernetes/vendor/k8s.io/...             \
	    github.com/go-bindata/go-bindata/go-bindata/... \
	    > $@.tmp
	# 比较 .make/go-pkgdeps.mk.tmp 文件 和 .make/go-pkgdeps.mk 文件是否有区别
	# 如果 有差别。则将 .make/go-pkgdeps.mk.tmp 的内容拷贝到 .make/go-pkgdeps.mk 中
	if ! cmp -s $@.tmp $@; then                         \
	    if [[ "$(DBG_CODEGEN)" == 1 ]]; then            \
	        echo "DBG: $(GO_PKGDEPS_FILE) changed";     \
	    fi;                                             \
	    cat $@.tmp > $@;                                \
	fi
	# 如果没有差别，就删除 .make/go-pkgdeps.mk.bak
	rm -f $@.tmp

# 设置 FORCE 为伪目标，不生成 target 文件
.PHONY: FORCE
# 依赖为空、执行命令也为空的TARGET，则需要每次都重新生成
# 将 FORCE 置为空，不执行任何命令，但是每次编译时，所有依赖 FORCE 的 target 都会执行，因为 FORCE 更新了
FORCE:

注意点1：

这里用到了 go2make 这个软件包，这个软件包是 kubernetes 中自带的工具，目录在 hack/make-rules/helpers/go2make/ 。这个工具的主要功能就是计算一组 Go 软件包的所有依赖关系并打印。下面是我打印出的这个工具的帮助信息：

Copy to Clipboard

注意点2：

在执行 Go 的命令时，都必须使用 hack/run-in-gopath.sh 脚本来执行。因为要执行 Go 的工具，必须确保安装了 golang，并且设置了 GOPATH。这个脚本就是设置了一个临时的 Kubernetes GOPATH 并在其下运行任意命令。运行的格式为：hack / run-in-gopath.sh <命令>

下面是这个脚本的内容（这里 hack/lib/init.sh 脚本在附录中介绍）：

Copy to Clipboard

注意点3：

go2make 生成的文件在 KUBE_ROOT/.make/go-pkgdeps.mk，文件部分内容如下：

Copy to Clipboard

gsh@gsh-ubuntu:~/kubernetes-src/kubernetes-1.21.0/.make$ pwd
/home/gsh/kubernetes-src/kubernetes-1.21.0/.make
gsh@gsh-ubuntu:~/kubernetes-src/kubernetes-1.21.0/.make$ ls
all_go_dirs.mk  go-pkgdeps.mk  _output
gsh@gsh-ubuntu:~/kubernetes-src/kubernetes-1.21.0/.make$ cat go-pkgdeps.mk
GODEPS_k8s.io/kubernetes/build/pause/windows/wincat :=  \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/build/pause/windows/wincat/ \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/build/pause/windows/wincat/wincat.go
GODEPS_github.com/gogo/protobuf/proto :=  \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/ \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/clone.go \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/custom_gogo.go \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/decode.go \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/deprecated.go \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/discard.go \
  /home/gsh/kubernetes-src/kubernetes-1.21.0/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/gogo/protobuf/proto/duration.go \

...

总结：generated_files （Makefile.generated_files文件）目标的处理过程是:

先处理依赖的六个 target
然后利用 go2make 工具生成 .make/go-pkgdeps.mk 文件
将 go-pkgdeps.mk 文件直接引入

下面介绍这六个依赖的 target，分别是：

gen_prerelease_lifecycle
gen_deepcopy
gen_defaulter
gen_conversion
gen_openapi
gen_bindata

这六个依赖的 target 其实就是自动生成对应的文件。

2.3 代码生成器（Makefile.generated_files文件）

kubernetes 项目中一共有六个代码生成器，分别是：

conversion-gen : 自动生成 Convert 函数的代码生成器，用于资源对象的版本转换函数。
deepcopy-gen : 自动生成 DeepCopy 函数的代码生成器，用于资源对象的深复制函数
defaulter-gen : 自动生成 Defaulter 函数的代码生成器，用于资源对象的深复制函数
openapi-gen : 自动生成 OpenAPI 定义文件（OpenAPI Definition File）的代码生成器
prerelease-lifecycle-gen : 自动生成 api-status.csv文件的工具，将为所有 beta API 创建一个 zz_api_status.go文件，该文件指示种类、引入的版本、不推荐使用的版本、将删除的版本。
go-bindata : 是一个第三方工具。它能够将静态资源嵌入 Go 语言中，例如，在 Web 开发中将静态的 HTML、Javascript 等静态文件嵌入 Go 语言代码中并提供一些操作方法。

这些代码生成器工具，在 make all 编译后，都会生成在 _output/bin/ 目录下。这些文件都是 Makefile.generated_files文件中定义的 target 目标文件。

Tags：

代码生成器通过Tags（标签）来识别一个包是否需要生成代码及确定生成代码的方式，Kubernetes提供的Tags可以分为如下两种：

全局Tags：定义在每个包的 doc.go文件中，对整个包中的类型自动生成代码。例如：pkg/kubelet/apis/config/v1beta1/doc.go 文件中，标记了：// +k8s:deepcopy-gen=package 、// +k8s:defaulter-gen=TypeMeta 等等。
局部Tags：定义在 Go 语言的类型声明上方，只对指定的类型自动生成代码。例如：vendor/k8s.io/kubelet/config/v1beta1/types.go 文件中，在定义结构体上方，标记了：// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

Tags 格式：

Tags的规则被定义在注释中，通常为：

//+tag-name 或
//+tag-name=value

其中，tag-name 可以为各个代码生成器的名称，例如 deepcopy-gen、defaulter-gen 等，还可以为 groupName ， groupName 表示资源组名称，资源组名称一般使用域名形式命名。

Tags 位置：

Tags的位置，

局部 Tags 一般定义在类型声明的上方，但如果该类型有注释信息，则局部 Tags 的定义需要与类型声明的注释信息之间至少有一个空行。
全局 Tags 一般定义在 doc.go文件中。

下面就介绍一下各个生成器在编译时是如何生成的，如何运行的（Makefile.generated_files文件）。下面这幅图比较清楚的展示了 makefile 各个阶段的依赖关系，大家可以对照这幅图，来看下面的代码。

2.3.1. 寻找所有带有 // +k8s: 的Tags的文件列表

# 寻找带有 Tags 的文件列表

Copy to Clipboard

# ------------------寻找带有 Tags 的文件列表  -------------------------
#

# 这一段是为了判断是否需要更新缓存，缓存文件在 .make/all_go_dirs.mk
# 1. 如果缓存文件 .make/all_go_dirs.mk 不存在，则创建
# 2. 如果缓存文件存在，判断是否有比它更新的目录，以此判断是否需要更新缓存文件
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** finding all *.go dirs)
endif
# ALL_GO_DIRS 变量 保存了所有的 .go 文件的路径
# cache_go_dirs.sh 脚本是为了判断有没有比缓存文件更新的文件，如果有则更新缓存文件。
ALL_GO_DIRS := $(shell                                                   \
    hack/make-rules/helpers/cache_go_dirs.sh $(META_DIR)/all_go_dirs.mk  \
)
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** found $(shell echo $(ALL_GO_DIRS) | wc -w) *.go dirs)
endif

# 这一段代码是为了找到所有带 `+k8s:` Tags 的文件列表
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** finding all +k8s: tags)
endif
# ALL_K8S_TAG_FILES 变量保存了所有带 Tags 的文件列表
# find -maxdepth 1 表示最多搜索一级目录
# xargs 命令的作用，是将标准输入转为命令行参数。相当于把管道前的输出，加载 xargs 命令的最后作为参数
# xargs grep 找到带有 // +k8s: Tags 的文件
ALL_K8S_TAG_FILES := $(shell                             \
    find $(ALL_GO_DIRS) -maxdepth 1 -type f -name \*.go  \
        | xargs grep --color=never -l '^// *+k8s:'       \
)
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** found $(shell echo $(ALL_K8S_TAG_FILES) | wc -w) +k8s: tagged files)
endif

注意：

缓存文件为：.make/all_go_dirs.mk
上面用到了 hack/make-rules/helpers/cache_go_dirs.sh 这个脚本，主要作用是更新缓存文件的

下面就来看一下 cache_go_dirs.sh 这个脚本都做了些什么操作：

# cache_go_dirs.sh 脚本

Copy to Clipboard

#!/usr/bin/env bash

# 这个脚本有三个作用：
# 1. 查找，有没有比传入的 缓存文件 更新的 目录项
# 2. 如果没有，表示之前的构建操作与这一次构建没有区别，直接退出
# 3. 如果有，则更新缓存文件，将所有的包含 .go 文件的目录写入到 传入的缓存文件中
set -o errexit
set -o nounset
set -o pipefail

# ${1:-string} 表示 如果 $1 为空值，则使用 string 的值来填充，如果不为空，则不变。
# if 判断 传入的第一个参数是否为空，如果为空，打印 Usage 信息，并退出
if [[ -z "${1:-}" ]]; then
    echo "usage: $0 <cache-file>"
    exit 1
fi

# CACHE 为 传入的参数，shift命令用于对参数的移动(左移)
# shift 完后，$1 就变成了 原先的 $2
CACHE="$1"; shift

# 捕捉信号 HUP INT TERM ERR，如果捕捉到这几个信号，则执行 rm 删除操作
trap 'rm -f "${CACHE}"' HUP INT TERM ERR

# kfind 是一个查找函数，可以传入类型和名称等 find 选项，例如：kfind -type f -name foobar.go
# 查找出除了vendor目录中所有的go文件，并且把 开头是 ./staging/src 目录转成 vendor 目录
function kfind() {
    # find -H 选项表示 除了指定的路径外，不递归搜索其中的软连接的目录
    # -a(and),-o(or),!(not)  -prune(除了某个目录)
    # -not 内部，不要匹配 下划线 _ 开头的文件，不要匹配没有 以点 . 为后缀名字的文件
    # 搜索路径是 除了 ./vendor 目录下的其他目录
    # 最后 sed 将 ./staging/src 目录 转成 vendor 目录
    find -H .                      \
        $                         \
        -not \(                    \
            \(                     \
                -name '_*' -o      \
                -name '.[^.]*' -o  \
                -path './vendor'   \
            $ -prune              \
        \)                         \
        \)                         \
        "$@"                       \
        | sed 's|^./staging/src|vendor|'
}

# 下面代码段的主要功能：
# 1. 找到比 CACHE 文件更新的目录
# 2. 如果没有，表示这次构建完全和上次一样，没有任何区别，直接退出
# 3. 如果有比 CACHE 新的目录，那就继续执行后面的操作
# -f  文件是否是普通文件（不是目录、设备文件、链接文件）
# -n(not)  表示 CACHE 不为空
# 如果 传入的 CACHE 是普通文件，且不为空
if [[ -f "${CACHE}" && -n "${CACHE}" ]]; then
    # 使用上面 kfind 函数，查找出比 CACHE 文件新的 目录 ，并显示函数
    # wc -l 显示行数
    N=$(kfind -type d -newer "${CACHE}" -print -quit | wc -l)
    # 如果查出的 行数 为 0，则打印 CACHE 文件内容，并退出
    if [[ "${N}" == 0 ]]; then
        cat "${CACHE}"
        exit
    fi
fi

# 创建 缓存文件夹
mkdir -p "$(dirname "${CACHE}")"
# 使用 kfind 函数，查找所有 .go 文件路径
# 第一个 sed 找到最后一个 / 后的内容，也就是文件名，替换为空
# 第二个 sed 将开头的 ./ 替换为空
# LC_ALL=C 是为了去除所有本地化的设置，让命令能正确执行。 sort -u 去除重复行并进行排序
# tee命令用于读取标准输入的数据，并将其内容输出成文件
kfind -type f -name \*.go  \
    | sed 's|/[^/]*$||'    \
    | sed 's|^./||'        \
    | LC_ALL=C sort -u     \
    | tee "${CACHE}"

注意：

cache_go_dirs.sh 会生成传入参数的缓存文件，并且将所有包含 .go 文件的目录存入。下面就是缓存文件 .make/all_go_dirs.mk 截取的一段：

Copy to Clipboard

2.3.2. prerelease-lifecycle 代码生成器

# prerelease-lifecycle-gen 代码生成器

Copy to Clipboard

# --------------------- prerelease-lifecycle 代码生成器逻辑-------------------

# 使用 prerelease-lifecycle 代码生成器的 Tags 格式：
#     // +k8s:prerelease-lifecycle-gen=true

# 在每个 package 中生成的文件名称
# GENERATED_FILE_PREFIX 变量在 Main Makefile 中定义为 GENERATED_FILE_PREFIX := zz_generated.
# 所以 prerelease-lifecycle 生成器生成的文件名为 zz_generated.prerelease-lifecycle.go
PRERELEASE_LIFECYCLE_BASENAME := $(GENERATED_FILE_PREFIX)prerelease-lifecycle
PRERELEASE_LIFECYCLE_FILENAME := $(PRERELEASE_LIFECYCLE_BASENAME).go

# 使用 _output/bin/prerelease-lifecycle-gen 工具来生成代码
PRERELEASE_LIFECYCLE_GEN := $(BIN_DIR)/prerelease-lifecycle-gen

# 下面是找到所有 带有 Tags 为 +k8s:prerelease-lifecycle-gen=true 的package
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** finding all +k8s:prerelease-lifecycle-gen tags)
endif
# 从所有带 `// +k8s:` Tags 的文件列表 ALL_K8S_TAG_FILES 中，找到带 '+k8s:prerelease-lifecycle-gen=true' 的文件的目录列表
# xargs -n 参数指定每次将多少项，作为命令行参数。-n 1 表示将前面管道中的输出作为一次命令行参数
PRERELEASE_LIFECYCLE_DIRS := $(shell                                                 \
    grep --color=never -l '+k8s:prerelease-lifecycle-gen=true' $(ALL_K8S_TAG_FILES)  \
        | xargs -n1 dirname                                                          \
        | LC_ALL=C sort -u                                                           \
)
ifeq ($(DBG_MAKEFILE),1)
    $(warning ***** found $(shell echo $(PRERELEASE_LIFECYCLE_DIRS) | wc -w) +k8s:prerelease-lifecycle-gen tagged dirs)
endif

#  PRERELEASE_LIFECYCLE_FILES 表示在每一个 Tags 为 '+k8s:prerelease-lifecycle-gen=true' 的文件的目录后，添加自动生成的文件名，也就是自动生成文件的路径+名称
# $(addsuffix suffix,names…) 添加后缀，names 可以有多个，用空格分开，例如 $(addsuffix .c,foo bar) 结果为 foo.c bar.c
# PRERELEASE_LIFECYCLE_FILES 表示格式为：path/to/files/zz_generated.prerelease-lifecycle.go 的列表
PRERELEASE_LIFECYCLE_FILES := $(addsuffix /$(PRERELEASE_LIFECYCLE_FILENAME), $(PRERELEASE_LIFECYCLE_DIRS))

# 重置需要生成的软件包列表。
# 生成目录 .make/_output/bin/
$(shell mkdir -p $$(dirname $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN)))
# 并且删除 .make/_output/bin/prerelease-lifecycle-gen.todo 文件
# todo 文件，表示这个构建需要做的目标
$(shell rm -f $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo)

# target gen_prerelease_lifecycle 的主逻辑，依赖两个文件：
# 1. _output/bin/prerelease-lifecycle-gen
# 2. .make/_output/bin/prerelease-lifecycle-gen.todo （todo 文件其实就是需要生成代码的目录列表，统计一共生成了多少个文件）
.PHONY: gen_prerelease_lifecycle
gen_prerelease_lifecycle: $(PRERELEASE_LIFECYCLE_GEN) $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo
    # 判断 .make/_output/bin/prerelease-lifecycle-gen.todo   文件是否存在
	if [[ -s $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo ]]; then                 \
	    # paste 命令 把每个文件以列对列的方式，一列列地加以合并
	    # -s 表示 将文件粘贴成一行，-d, 表示使用逗号, 作为分隔符，例如：文件为 aaa\nbbb\n ，那paste结果为 aaa,bbb
	    # 单$表示引用makefile定义变量的值，双$$表示引用shell命令中定义的变量的值。
	    pkgs=$$(cat $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo | paste -sd, -);  \
	    if [[ "$(DBG_CODEGEN)" == 1 ]]; then                                       \
	        echo "DBG: running $(PRERELEASE_LIFECYCLE_GEN) for $$pkgs";            \
	    fi;                                                                        \
	    # 统计 prerelease-lifecycle-gen.todo 的行数
	    N=$$(cat $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo | wc -l);            \
	    echo "Generating prerelease lifecycle code for $$N targets";               \
	    # 这一步就是自动生成代码
	    # 利用 ./hack/run-in-gopath.sh 脚本 执行 代码生成工具 prerelease-lifecycle-gen 来生成代码，并且传入参数
	    # $@ 表示目标文件, $$@ 表示将 目标文件变量放入到 shell 中
	    ./hack/run-in-gopath.sh $(PRERELEASE_LIFECYCLE_GEN)                        \
	        --v $(KUBE_VERBOSE)                                                    \
	        --logtostderr                                                          \
	        -i "$$pkgs"                                                            \
	        -O $(PRERELEASE_LIFECYCLE_BASENAME)                                    \
	        "$$@";                                                                 \
	fi

# 这里的代码是自动生成所有的 path/to/files/zz_generated.prerelease-lifecycle 文件
# makefile 中的 fareach 函数 $(foreach <var>,<list>,<text> )
# 意思是，把参数<list>中的单词逐一取出放到参数<var>所指定的变量中，然后再执行<text>所包含的表达式
# makefile 中的 eval 函数，表示 作为makefile的一部分而被make解析和执行。
# 这段的意思就是，根据 PRERELEASE_LIFECYCLE_DIRS 目录中的每一项，都生成一个 path/to/zz_generated.prerelease-lifecycle.go 的target
# 在 Main Makefile 文件中定义了：PRJ_SRC_PATH := k8s.io/kubernetes
# 这个 target 依赖 GODEPS_k8s.io/kubernetes/path/to/file
$(foreach dir, $(PRERELEASE_LIFECYCLE_DIRS), $(eval                            \
    $(dir)/$(PRERELEASE_LIFECYCLE_FILENAME): $(GODEPS_$(PRJ_SRC_PATH)/$(dir))  \
))

# 为了生成 .make/_output/bin/prerelease-lifecycle-gen.todo 文件
# 定义了 target：.make/_output/bin/prerelease-lifecycle-gen.todo
# 依赖：所有的目标文件 path/to/file/zz_generated.prerelease-lifecycle
$(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo: $(PRERELEASE_LIFECYCLE_FILES)

# 生成所有的 path/to/file/zz_generated.prerelease-lifecycle 文件
# 依赖 _output/bin/prerelease-lifecycle-gen 文件
# 这里也就是生成所有的 zz_generated.prerelease-lifecycle 文件，并且将这些文件的目录组合成 k8s.io/kubernetes/path/to/file 写入 todo 文件
$(PRERELEASE_LIFECYCLE_FILES): $(PRERELEASE_LIFECYCLE_GEN)
	if [[ "$(DBG_CODEGEN)" == 1 ]]; then        \
	    echo "DBG: prerelease-lifecycle needed $(@D):";  \
	    ls -lf --full-time $@ $? || true;       \
	fi
	# $@ 表示目标文件集，而 $(@D) 就表示 $@ 的目录部分
	# 这句话就是将每一个需要生成代码的目录组合成 k8s.io/kubernetes/path/to/file 追加写入到 .make/_output/bin/prerelease-lifecycle-gen.todo 文件中
	echo $(PRJ_SRC_PATH)/$(@D) >> $(META_DIR)/$(PRERELEASE_LIFECYCLE_GEN).todo

# 编译并生成 prerelease-lifecycle 代码生成器工具
# 依赖：$(GODEPS_k8s.io/kubernetes/vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen) 我没有找到这个变量，那就依赖为空
$(PRERELEASE_LIFECYCLE_GEN): $(GODEPS_k8s.io/kubernetes/vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen)
	# 使用 hack/make-rules/build.sh 脚本来编译生成 prerelease-lifecycle-gen 代码生成器工具，编译的地址在 ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
	# 其实 这个目录应该是在 staging/src/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
	KUBE_BUILD_PLATFORMS="" hack/make-rules/build.sh ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen
	# 创建文件 _output/bin/prerelease-lifecycle-gen
	touch $@

注意1：

上面的逻辑中，生成了一个 .make/_output/bin/prerelease-lifecycle-gen.todo 文件，这个文件记录了在这次构件中，一共有哪些 package 需要使用 prerelease-lifecycle-gen 代码生成器自动生成代码的。生成的代码名称为：zz_generated.prerelease-lifecycle.go 。

下面我们看一下 prerelease-lifecycle-gen.todo 文件的内容：

Copy to Clipboard

[root@localhost kubernetes-1.21.0]# cat .make/_output/bin/prerelease-lifecycle-gen.todo
k8s.io/kubernetes/vendor/k8s.io/api/admission/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/admissionregistration/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/apps/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/apps/v1beta2
k8s.io/kubernetes/vendor/k8s.io/api/authentication/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/authorization/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/autoscaling/v2beta1
k8s.io/kubernetes/vendor/k8s.io/api/autoscaling/v2beta2
k8s.io/kubernetes/vendor/k8s.io/api/batch/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/certificates/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/coordination/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/discovery/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/events/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/extensions/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/flowcontrol/v1alpha1
k8s.io/kubernetes/vendor/k8s.io/api/flowcontrol/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/networking/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/node/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/policy/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/rbac/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/scheduling/v1beta1
k8s.io/kubernetes/vendor/k8s.io/api/storage/v1alpha1
k8s.io/kubernetes/vendor/k8s.io/api/storage/v1beta1
k8s.io/kubernetes/vendor/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/apis/audit/v1alpha1
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/apis/audit/v1beta1
k8s.io/kubernetes/vendor/k8s.io/kube-aggregator/pkg/apis/apiregistration/v1beta1

注意2：

在上面代码段最后，使用了编译 hack/make-rules/build.sh 脚本编译 prerelease-lifecycle-gen 代码生成器，传入参数 ./vendor/k8s.io/code-generator/cmd/prerelease-lifecycle-gen 。build.sh 脚本，我们在附录中分析。

下面简单介绍一下 prerelease-lifecycle-gen 代码生成器。

prerelease-lifecycle-gen 是一个自动生成 zz_generated.prerelease-lifecycle.go 文件的代码生成器。
zz_generated.prerelease-lifecycle.go 这个文件中主要包括一些 API prerelease-lifecycle 代码，我的理解就是 API 的生命周期，例如：对于 certificates/v1beta1 API，这个 API 接口是从哪一个版本中出现的，将要在哪个版本中丢弃。
生成 prerelease-lifecycle 相关函数时，其 Tags 形式可以为：
- // +k8s:prerelease-lifecycle-gen:deprecated=1.21 -> 表示生成的 APILifecycleDeprecated 函数返回的版本为 1.21
- // +k8s:prerelease-lifecycle-gen:replacement=<group>,<version>,<kind> -> 表示生成的 APILifecycleReplacement 函数返回 schema.GroupVersionKind 结构体
prerelease-lifecycle-gen 生成器一共有这几个函数：

函数名	Tags	说明
APILifecycleIntroduced()	k8s:prerelease-lifecycle-gen:introduced	返回这个 API 接口是从哪个版本开始的
APILifecycleDeprecated()	k8s:prerelease-lifecycle-gen:deprecated	返回这个 API 接口将在哪个版本丢弃，但 API 仍旧会提供服务
APILifecycleReplacement()	k8s:prerelease-lifecycle-gen:replacement=,,	表示这个 API 接口有更新，返回应该使用的类型结构
APILifecycleRemoved()	k8s:prerelease-lifecycle-gen:removed	返回这个 API 接口会在哪个把版本不再提供服务

prerelease-lifecycle-gen 的自动生成代码示例：

代码路径：vendor/k8s.io/api/networking/v1beta1/zz_generated.prerelease-lifecycle.go。代码为：

# zz_generated.prerelease-lifecycle.go

Copy to Clipboard

2.3.3. deepcopy-gen 代码生成器

上面介绍了 prerelease-lifecycle-gen 的 Makefile 构建方法，其他的五个代码生成器构建规则是相同的，都是这几个步骤。后面我不会再次分析makefile源码，而是简单介绍生成器的作用和功能。

deepcopy-gen 代码生成器：

deepcopy-gen 是一个自动生成 zz_generated.deepcopy.go 文件的代码生成器。
zz_generated.deepcopy.go 文件主要包括两个函数，DeepCopy() 和 DeepCopyInto()，功能就是深度拷贝，也就是生成一个相同的结构体，两个内存空间。
生成 deepcopy 函数时，其 Tags 形式可以为:
- +k8s:deepcopy-gen=true : 为单个类型生成DeepCopy相关函数
- +k8s:deepcopy-gen=package : 为整个包生成DeepCopy相关函数
- +k8s:deepcopy-gen=false : 为整个包生成DeepCopy相关函数时，可以忽略单个类型
deepcopy-gen 生成器生成的函数介绍：

函数	说明	Tags
DeepCopy()	复制接收者，并创建一个新的与接收者相同的深度拷贝返回	// +k8s:deepcopy-gen=true
DeepCopyInto(*type)	复制接收者，并创建一个新的与接收者相同的深度拷贝写入到函数参数中	// +k8s:deepcopy-gen=package
DeepCopyObject()	复制接收者，并创建一个新的runtime.Object	// +k8s:deepcopy-gen:interfaces=xxx/runtime.Object

deepcopy-gen 生成器自动生成代码文件示例：

代码路径：vendor/k8s.io/api/core/v1/zz_generated.deepcopy.go。代码为：

# zz_generated.deepcopy.go

Copy to Clipboard

2.3.4. defaulter-gen 代码生成器

defaulter-gen 代码生成器：

defaulter-gen 是一个自动生成 zz_generated.defaults.go 文件的代码生成器。
zz_generated.defaults.go 文件主要功能就是为资源对象生成默认值。每一个对象会生成一个专门的函数，xxxTypeDefaults() ，用于给对象幅默认值。
生成 Defaulter 函数时，其 Tags 形式可以为:
- +k8s:defaulter-gen=TypeMeta: 为拥有 TypeMeta 属性的类型生成Defaulter相关函数
- +k8s:defaulter-gen=ListMeta : 为拥有 ListMeta 属性的类型生成Defaulter相关函数
- +k8s:defaulter-gen=ObjectMeta : 为拥有 ObjectMeta 属性的类型生成Defaulter相关函数
- +k8s:defaulter-gen-input=path/to/package : 当前包会依赖于指定的路径包
defaulter-gen 生成器生成的函数介绍：

函数名	Tags	说明
RegisterDefaults()	k8s:defaulter-gen:TypeMeta	将该函数内的 Setxxx 方法注册到 runtime.schema 中，并且公开这个 schema
SetObjectDefaults_Xxxx	None	设置具体某个类型对象 Xxxx 的默认值

defaulter-gen 生成器自动生成代码文件示例：

代码路径：pkg/apis/batch/v1beta1/zz_generated.defaults.go。代码为：

# zz_generated.defaults.go

Copy to Clipboard

2.3.5. conversion-gen代码生成器

conversion-gen 代码生成器：

conversion-gen 是一个自动生成 zz_generated.conversion.go 文件的代码生成器。
zz_generated.conversion.go 文件主要功能就是为对象在内部和外部类型之间提供转换函数。每一个对象会生成一组转换的函数，例如：Convert_v1alpha1_PolicyList_To_audit_PolicyList() 和 Convert_audit_PolicyList_To_v1alpha1_PolicyList，PolicyList 是一种类型，conversion-gen为该类型生成了Convert函数。
生成 conversion 函数时，其 Tags 形式可以为:
- +k8s:conversion-gen= INTERNAL_TYPES_DIR : 为整个包生成Convert相关函数，INTERNAL_TYPES_DIR 用于定义包的导入路径，例如k8s.io/kubernetes/pkg/apis/abac。
- +k8s:conversion-gen-external-types= EXTERNAL_TYPES_DIR : 为整个包生成Convert相关函数且依赖其他包，EXTERNAL_TYPES_DIR 用于定义其他包的路径，例如k8s.io/api/autoscaling/v1。
conversion-gen 生成器生成的函数介绍：

函数名	Tags	说明
RegisterConversions()	// +k8s:conversion-gen-external-types= EXTERNAL_TYPES_DIR // +k8s:conversion-gen=INTERNAL_TYPES_DIR	将该函数内的 Convert 方法注册到 runtime.schema 中，并且公开这个 schema
Convert_v1alpha1_EventList_To_audit_EventList	None	从 v1alpha1_EventList 转换成 audit_EventList
Convert_audit_EventList_To_v1alpha1_EventList	None	从 audit_EventList 转换成 v1alpha1_EventList

conversion-gen 生成器自动生成代码文件示例：

代码路径：vendor/k8s.io/apiserver/pkg/apis/audit/v1alpha1/zz_generated.conversion.go。代码为：

# zz_generated.conversion.go

Copy to Clipboard

func RegisterConversions(s *runtime.Scheme) error {
    if err := s.AddGeneratedConversionFunc((*EventList)(nil), (*audit.EventList)(nil), func(a, b interface{}, scope conversion.Scope) error {
        return Convert_v1alpha1_EventList_To_audit_EventList(a.(*EventList), b.(*audit.EventList), scope)
    }); err != nil {
        return err
    }
    if err := s.AddGeneratedConversionFunc((*audit.EventList)(nil), (*EventList)(nil), func(a, b interface{}, scope conversion.Scope) error {
        return Convert_audit_EventList_To_v1alpha1_EventList(a.(*audit.EventList), b.(*EventList), scope)
    }); err != nil {
        return err
    }
    
    ...
}

//  内部调用了 autoConvert 方法
func Convert_v1alpha1_EventList_To_audit_EventList(in *EventList, out *audit.EventList, s conversion.Scope) error {
    return autoConvert_v1alpha1_EventList_To_audit_EventList(in, out, s)
}

func Convert_audit_EventList_To_v1alpha1_EventList(in *audit.EventList, out *EventList, s conversion.Scope) error {
    return autoConvert_audit_EventList_To_v1alpha1_EventList(in, out, s)
}

func autoConvert_audit_EventList_To_v1alpha1_EventList(in *audit.EventList, out *EventList, s conversion.Scope) error {
    out.ListMeta = in.ListMeta
    if in.Items != nil {
        in, out := &in.Items, &out.Items
        *out = make([]Event, len(*in))
        for i := range *in {
            if err := Convert_audit_Event_To_v1alpha1_Event(&(*in)[i], &(*out)[i], s); err != nil {
                return err
            }
        }
    } else {
        out.Items = nil
    }
    return nil
}

2.3.6. openapi-gen 代码生成器

openapi-gen 代码生成器：

openapi-gen 是一个自动生成 zz_generated.openapi.go 文件的代码生成器。
zz_generated.openapi.go 文件主要功能就是可以为其生成 OpenAPI 定义文件，该文件用于kube-apiserver服务上的OpenAPI规范的生成。函数名为：GetOpenAPIDefinitions() ，该函数会返回 map，key 表示 API ，value 表示定义这个 API 的函数。
生成 openapi 函数时，其 Tags 形式可以为:
- +k8s:openapi-gen=true : 为特定类型或包生成OpenAPI定义文件。
- +k8s:openapi-gen=false : 排除为特定类型或包生成OpenAPI定义文件。
openapi-gen 生成器生成的函数介绍：

函数名	Tags	说明
GetOpenAPIDefinitions()	// +k8s:openapi-gen=true	将该函数会返回一个 map ，是一个 API 的对应关系
schema_API_PATH()	None	返回这个 API 的详细定义，返回应该是一个 Json 对象这个函数可以为：schema_k8sio_api_autoscaling_v1_ContainerResourceMetricSource(ref) 对应的 API 接口为：k8s.io/api/autoscaling/v1.ContainerResourceMetricSource

函数名

# zz_generated.openapi.go

Copy to Clipboard

2.3.7. go-bindata 代码生成器

go-bindata 代码生成器：

go-bindata 是一个构建 go-bindata 二进制文件，并执行 go-bindata 代码生成器，为 translations 静态资源目录生成 pkg/kubectl/generated/bindata.go.tmp 文件。
go-bindata 的功能：把静态文件都打包到程序中。Golang 是可以把整个项目打包成一个可执行文件，但如果依赖一些静态资源，可以利用 go-bindata 将静态资源打包进可执行文件中。
使用 go-bindata 时，没有 Tags 。

3. 容器环境构建

Kubernetes提供了两种容器环境下的构建方式：

make release：构建所有的目标平台（Darwin、Linux、Windows），构建过程会比较久，并同时执行单元测试过程。
make quick-release：快速构建，只构建当前平台，并略过单元测试过程。

3.1 make quick-release 在 Makefile 的源码分析

# make quick-release 逻辑

Copy to Clipboard

注意1：

这里 make quick-release 的逻辑与 make all 的逻辑是相似的，就是最后的构建过程不同，这里主要是使用了 build/release.sh 脚本进行的编译。

注意2：

这里有几个环境变量用于控制编译过程：

KUBE_RELEASE_RUN_TESTS : 是否执行单元测试

KUBE_FASTBUILD : 快速构建，也就是跳过交叉编译

3.2 容器环境构建过程

容器环境的构建过程，主要是在 build/release.sh 脚本中定义，下面我们看一下脚本的具体内容：

Copy to Clipboard

从上面的代码中，可以看到 Kubernetes 容器环境构建过程分为几步:

容器构建环境的配置和验证(kube::build::verify_prereqs)
build image 构建镜像(kube::build::build_image)
具体构建方法(kube::build::run_build_command)
将文件从容器中拷贝到主机(kube::build::copy_output)
打包(kube::build::package_tarballs)

每个步骤的具体细节参考后面小节

3.2.1 步骤1-环境配置与验证

(kube::build::verify_prereqs) 进行构建环境的配置及验证。该过程会检查本机是否安装了Docker容器环境，而对于Darwin平台，该过程会检查本机是否安装了docker-machine环境。kube::build::verify_prereqs 方法在 build/common.sh ，其具体内容为：

Copy to Clipboard

# 拉取镜像的 project 名称
readonly KUBE_BUILD_IMAGE_REPO=kube-build
# 拉取镜像的 仓库
readonly KUBE_DOCKER_REGISTRY="${KUBE_DOCKER_REGISTRY:-k8s.gcr.io}"
readonly KUBE_BASE_IMAGE_REGISTRY="${KUBE_BASE_IMAGE_REGISTRY:-k8s.gcr.io/build-image}"

# KUBE_BUILD_IMAGE_CROSS_TAG 表示 要拉取 的基本镜像的 tag 名： v1.16.1-1
readonly KUBE_BUILD_IMAGE_CROSS_TAG="$(cat "${KUBE_ROOT}/build/build-image/cross/VERSION")"

# image 的版本号，我这里是 5 ，
readonly KUBE_BUILD_IMAGE_VERSION_BASE="$(cat "${KUBE_ROOT}/build/build-image/VERSION")"
readonly KUBE_BUILD_IMAGE_VERSION="${KUBE_BUILD_IMAGE_VERSION_BASE}-${KUBE_BUILD_IMAGE_CROSS_TAG}"

# 验证是否安装了 docker 环境
# 传入参数：是否 要求 有docker环境，默认 true
function kube::build::verify_prereqs() {
  local -r require_docker=${1:-true}
  kube::log::status "Verifying Prerequisites...."

# 确认 tar 命令
  kube::build::ensure_tar || return 1
  # 确认 rsync 命令
  kube::build::ensure_rsync || return 1
  # 如果必须要有 docker 运行环境
  if ${require_docker}; then
    # 确认 docker 环境
    kube::build::ensure_docker_in_path || return 1
    # 如果是 Darwin 系统
    if kube::build::is_osx; then
        # 检查 docker.sock
        kube::build::docker_available_on_osx || return 1
    fi
    # 检查 是否可以运行 docker 命令
    kube::util::ensure_docker_daemon_connectivity || return 1
    # 打印 docker Version 信息
    if (( KUBE_VERBOSE > 6 )); then
      kube::log::status "Docker Version:"
      "${DOCKER[@]}" version | kube::log::info_from_stdin
    fi
  fi

# 当前的 git 分支
  KUBE_GIT_BRANCH=$(git symbolic-ref --short -q HEAD 2>/dev/null || true)
  # 用 md5 命令 求 hash 值
  KUBE_ROOT_HASH=$(kube::build::short_hash "${HOSTNAME:-}:${KUBE_ROOT}:${KUBE_GIT_BRANCH}")
  # build 出 image 的 tag前缀 为 build-Hash值
  KUBE_BUILD_IMAGE_TAG_BASE="build-${KUBE_ROOT_HASH}"
  # KUBE_BUILD_IMAGE_VERSION 为 5-v1.16.1-1
  # build 出 image 的 整个 tag
  KUBE_BUILD_IMAGE_TAG="${KUBE_BUILD_IMAGE_TAG_BASE}-${KUBE_BUILD_IMAGE_VERSION}"
  # 需要拉取的镜像名称：kube-build:build-HASH-5-v1.16.1-1
  KUBE_BUILD_IMAGE="${KUBE_BUILD_IMAGE_REPO}:${KUBE_BUILD_IMAGE_TAG}"
  # 这里一共需要 三个容器来进行构建工作：
  # 1. BUILD 容器，构建容器
  # 2. RSYNC 容器，同步数据容器
  # 3. DATA 容器，存储容器
  # build container Name : kube-build-HASH-5-v1.16.1-1
  KUBE_BUILD_CONTAINER_NAME_BASE="kube-build-${KUBE_ROOT_HASH}"
  KUBE_BUILD_CONTAINER_NAME="${KUBE_BUILD_CONTAINER_NAME_BASE}-${KUBE_BUILD_IMAGE_VERSION}"
  # RSYNC container NAME: kube-rsync-build-HASH-5-v1.16.1-1
  KUBE_RSYNC_CONTAINER_NAME_BASE="kube-rsync-${KUBE_ROOT_HASH}"
  KUBE_RSYNC_CONTAINER_NAME="${KUBE_RSYNC_CONTAINER_NAME_BASE}-${KUBE_BUILD_IMAGE_VERSION}"
  # DATA container Name: kube-build-data-build-HASH-5-v1.16.1-1
  KUBE_DATA_CONTAINER_NAME_BASE="kube-build-data-${KUBE_ROOT_HASH}"
  KUBE_DATA_CONTAINER_NAME="${KUBE_DATA_CONTAINER_NAME_BASE}-${KUBE_BUILD_IMAGE_VERSION}"
  # DATA 容器挂载目录的路径
  DOCKER_MOUNT_ARGS=(--volumes-from "${KUBE_DATA_CONTAINER_NAME}")
  # 这个是 image 的 output 路径
  LOCAL_OUTPUT_BUILD_CONTEXT="${LOCAL_OUTPUT_IMAGE_STAGING}/${KUBE_BUILD_IMAGE}"

# 设置 git 相关的环境变量
  kube::version::get_version_vars
  # 将环境变量 保存在 指定的文件中
  kube::version::save_version_vars "${KUBE_ROOT}/.dockerized-kube-version-defs"

# Without this, the user's umask can leak through.
  umask 0022
}

根据 kube::build::verify_prereqs 的源码，可以看到这个函数的功能：

验证系统中有没有 tar、rsync、docker 的环境
设置相关的环境变量
将环境变量保存在文件中

在设置环境变量时，我们发现，设置了三个容器的名称，在容器环境构建过程中，主要是这三个容器镜像参与其中，分别：

build 容器（kube-cross）：即构建容器，在该容器中会对代码文件执行构建操作，完成后其会被删除。
data 容器：即存储容器，用于存放构建过程中所需的所有文件。
rsync 容器：即同步容器，用于在容器和主机之间传输数据，完成后其会被删除。

这里用到的基础镜像 kube-cross ，需要从 k8s.gcr.io 仓库拉取，我这里用了代理拉取。完整的基础镜像名称为： k8s.gcr.io/build-image/kube-cross:v1.16.1-1

3.2.2 步骤2-编译镜像

(kube::build::build_image) 主要是用来编译镜像，一共需要编译上面提到的三个镜像。该函数在 build/common.sh 源码如下：

Copy to Clipboard

# 这个是 image 的 output 路径
LOCAL_OUTPUT_BUILD_CONTEXT="${LOCAL_OUTPUT_IMAGE_STAGING}/${KUBE_BUILD_IMAGE}"

function kube::build::build_image() {
  # 创建 编译容器 的 Dockerfile 的目录, 目录为： _output/images/kube-build:build-HASH-5-v1.16.1-1
  mkdir -p "${LOCAL_OUTPUT_BUILD_CONTEXT}"
  # Make sure the context directory owned by the right user for syncing sources to container.
  # 修改 Dockerfile 所在的目录 的 属主和属组
  chown -R "${USER_ID}":"${GROUP_ID}" "${LOCAL_OUTPUT_BUILD_CONTEXT}"

# 将 时区文件 拷贝到 该目录中
  cp /etc/localtime "${LOCAL_OUTPUT_BUILD_CONTEXT}/"
  chmod u+w "${LOCAL_OUTPUT_BUILD_CONTEXT}/localtime"

# 拷贝 build/build-image/Dockerfile 文件 和 build/build-image/rsyncd.sh 脚本
  cp "${KUBE_ROOT}/build/build-image/Dockerfile" "${LOCAL_OUTPUT_BUILD_CONTEXT}/Dockerfile"
  cp "${KUBE_ROOT}/build/build-image/rsyncd.sh" "${LOCAL_OUTPUT_BUILD_CONTEXT}/"
  # dd 可从标准输入或文件中读取数据，根据指定的格式来转换数据，再输出到文件、设备或标准输出。
  # 参数：if=文件名：输入文件名； of=文件名：输出文件名 ；bs=bytes：同时设置读入/输出的块大小为bytes个字节 ； count=blocks：仅拷贝blocks个块，块大小等于ibs指定的字节数。
  # 生成随机的密码
  dd if=/dev/urandom bs=512 count=1 2>/dev/null | LC_ALL=C tr -dc 'A-Za-z0-9' | dd bs=32 count=1 2>/dev/null >"${LOCAL_OUTPUT_BUILD_CONTEXT}/rsyncd.password"
  chmod go= "${LOCAL_OUTPUT_BUILD_CONTEXT}/rsyncd.password"

# 使用 docker 命令 build image
  # 第一个参数：需要 build 的 image 名称
  # 第二个参数：Dockerfile 所在的目录
  # 第三个参数：-pull 参数，默认 true，表示是否下载最新的版本
  # 第四个参数：--build-args 参数，表示build时的环境变量
  # kube::build::docker_build 这个函数就是执行一个 docker build 命令
  # 完整的 docker build 命令为：docker build -t "${image}" "--pull=${pull}" "${build_args[@]}" "${context_dir}"
  kube::build::docker_build "${KUBE_BUILD_IMAGE}" "${LOCAL_OUTPUT_BUILD_CONTEXT}" 'false' "--build-arg=KUBE_BUILD_IMAGE_CROSS_TAG=${KUBE_BUILD_IMAGE_CROSS_TAG} --build-arg=KUBE_BASE_IMAGE_REGISTRY=${KUBE_BASE_IMAGE_REGISTRY}"

# Clean up old versions of everything
  # 清除  所有满足正则 的 container
  # 第一个参数，要清除的 container 名称的前缀
  # 第二个参数，要保留的 container 名称
  # 这里主要是清除 之前 编译构建的 BUILD、RSYNC、DATA cantainer
  kube::build::docker_delete_old_containers "${KUBE_BUILD_CONTAINER_NAME_BASE}" "${KUBE_BUILD_CONTAINER_NAME}"
  kube::build::docker_delete_old_containers "${KUBE_RSYNC_CONTAINER_NAME_BASE}" "${KUBE_RSYNC_CONTAINER_NAME}"
  kube::build::docker_delete_old_containers "${KUBE_DATA_CONTAINER_NAME_BASE}" "${KUBE_DATA_CONTAINER_NAME}"

# 删除所有与标签前缀匹配的 image（“当前”版本除外）
  kube::build::docker_delete_old_images "${KUBE_BUILD_IMAGE_REPO}" "${KUBE_BUILD_IMAGE_TAG_BASE}" "${KUBE_BUILD_IMAGE_TAG}"
  # 确保 DATA 容器运行
  kube::build::ensure_data_container
  # 将 本机的数据 拷贝到 容器中
  kube::build::sync_to_container
}

构建容器镜像的流程如下。

通过 mkdir 命令创建构建镜像的文件夹（即_output/images/…）。
通过 cp 命令复制构建镜像所需的相关文件，如Dockerfile文件和rsyncd同步脚本等。
通过 kube::build::docker_build 函数，构建容器镜像。
通过 kube::build::ensure_data_container 函数，运行存储容器并挂载Volume。
通过 kube::build::sync_to_container 函数，运行同步容器并挂载存储容器的 Volume，然后通过 rsync 命令同步 Kubernetes 源码到存储容器的 Volume。

3.2.3 步骤3-构建方法

此时，容器构建环境已经准备好，下面开始运行构建容器并在构建容器内部执行构建Kubernetes源码的操作，构建过程在 kube::build::run_build_command make cross。该函数位于：build/common.sh，代码示例如下：

Copy to Clipboard

#  <container name> <extra docker args> -- <command>
# 传入参数格式为：<container name> <extra docker args> -- <command>
function kube::build::run_build_command_ex() {
  # $# 表示参数的个数
  # 如果参数 == 0 报错
  [[ $# != 0 ]] || {
    echo "Invalid input - please specify a container name." >&2
    return 4
  }
  # 第一个参数为 容器的名称
  local container_name="${1}"
  shift

# 运行运行时的 选项
  # --name 容器的名称
  # --user 以哪个用户运行容器
  # --hostname 容器的hostname
  # --volumes-from 挂载目录
  local -a docker_run_opts=(
    "--name=${container_name}"
    "--user=$(id -u):$(id -g)"
    "--hostname=${HOSTNAME}"
    "${DOCKER_MOUNT_ARGS[@]}"
  )

local detach=false

# 此时已经取出了第一个参数 $1 ，并且 shift 后，$1 就为第二个桉树
  # $# 就为 总参数个数-1
  [[ $# != 0 ]] || {
    echo "Invalid input - please specify docker arguments followed by --." >&2
    return 4
  }
  # until 循环执行一系列命令直至条件为 true 时停止。
  # 此时 $1 为 第二个参数 extra docker args，也就是循环遍历所有的 选项
  until [ -z "${1-}" ]; do
    # 如果是  --  标识符，直接跳出
    if [[ "$1" == "--" ]]; then
      shift
      break
    fi
    # 否则，将选项添加进  docker_run_opts
    docker_run_opts+=("$1")
    if [[ "$1" == "-d" || "$1" == "--detach" ]]; then
      detach=true
    fi
    shift
  done

# 在 -- 标识符后，是编译的命令，如果没有 则报错
  [[ $# != 0 ]] || {
    echo "Invalid input - please specify a command to run." >&2
    return 4
  }

local -a cmd=()
  # 标准的 参数循环方法
  until [ -z "${1-}" ]; do
    cmd+=("$1")
    shift
  done

# 添加环境变量：
  docker_run_opts+=(
    --env "KUBE_FASTBUILD=${KUBE_FASTBUILD:-false}"
    --env "KUBE_BUILDER_OS=${OSTYPE:-notdetected}"
    --env "KUBE_VERBOSE=${KUBE_VERBOSE}"
    --env "KUBE_BUILD_WITH_COVERAGE=${KUBE_BUILD_WITH_COVERAGE:-}"
    --env "KUBE_BUILD_PLATFORMS=${KUBE_BUILD_PLATFORMS:-}"
    --env "GOFLAGS=${GOFLAGS:-}"
    --env "GOGCFLAGS=${GOGCFLAGS:-}"
    --env "SOURCE_DATE_EPOCH=${SOURCE_DATE_EPOCH:-}"
  )

# use GOLDFLAGS only if it is set explicitly.
  if [[ -v GOLDFLAGS ]]; then
    docker_run_opts+=(
      --env "GOLDFLAGS=${GOLDFLAGS:-}"
    )
  fi

if [[ -n "${DOCKER_CGROUP_PARENT:-}" ]]; then
    kube::log::status "Using ${DOCKER_CGROUP_PARENT} as container cgroup parent"
    docker_run_opts+=(--cgroup-parent "${DOCKER_CGROUP_PARENT}")
  fi
      
  if [[ -t 0 ]]; then
    docker_run_opts+=(--interactive --tty)
  elif [[ "${detach}" == false ]]; then
    docker_run_opts+=("--attach=stdout" "--attach=stderr")
  fi

# docker_cmd 是一个列表，里面包含了 docker run 的完整命令
  local -ra docker_cmd=(
    "${DOCKER[@]}" run "${docker_run_opts[@]}" "${KUBE_BUILD_IMAGE}")

# 删掉之前构建时的同名 container
  kube::build::destroy_container "${container_name}"
  
  # 执行构建操作的 具体命令
  # docekr_cmd 是 docker run 的完整命令，而 cmd 是 构建的命令，也就是 make cross
  "${docker_cmd[@]}" "${cmd[@]}"
  
  # 判断是否保留容器
  if [[ "${detach}" == false ]]; then
    kube::build::destroy_container "${container_name}"
  fi
}

通过 ${docker_cmd[＠]}""${cmd[＠]} 命令执行构建操作（即在容器内执行make cross命令）。容器内的构建过程与本地环境下的构建过程相同，故不再赘述。

3.2.4 步骤4-将文件从容器中拷贝到主机

(kube::build::copy_output)使用同步容器，将编译后的代码文件复制到主机上。该函数位于：build/common.sh，源码为：

Copy to Clipboard

根据 kube::build::copy_output 函数的源码，该函数的步骤为：

启动 RSYNCD 容器，并且获取该容器的 ip 地址，存储在 KUBE_RSYNC_ADDR 环境变量中。
使用 rsync 命令，对构建后的目录进行过滤，将需要的目录，从容器中拷贝到本地目录。
停止 RSYNCD 容器，并且 unset KUBE_RSYNC_ADDR 。

3.2.5 步骤5-打包

(kube::release::package_tarballs)函数用于打包，将二进制文件打包到 _output 目录中。最终，代码文件以 tar.gz 压缩包的形式输出至 _output/release-tars 文件夹。该函数位于：build/lib/release.sh，源码为：

Copy to Clipboard

打包很简单，就是利用 tar 命令对不同的目录分别进行打包操作。

4. Bazel环境构建

除了使用官方构建工具，Kubernetes 还支持 Bazel 构建。Bazel 是 Google 公司开源的一个自动化软件构建和测试工具。Bazel 使用分布式缓存和增量构建方法，使构建更加快速。其支持构建任务，包括运行编译器和链接器以生成可执行程序和库。Bazel 与 Make、Gradle 及 Maven 等构建工具类似，但Bazel在构建速度、可扩展性、灵活性及跨语言和对不同平台的支持上更加出色。

Bazel 优势：

高级别的构建语言：项目以BUILD语言进行描述。BUILD是一种简洁的文本格式，可描述多个小而互相关联的库、二进制程序和测试程序组成的项目。
支持多平台：相同的工具和BUILD文件可以为不同架构或平台构建软件。
再现性：在BUILD文件中，必须明确为每个库、测试程序、二进制文件指定其直接依赖。在修改源码文件后，Bazel使用这个依赖信息就可以知道哪些东西必须重新构建，哪些任务可以并行执行。这意味着所有的构建都是以增量的形式构建的并能够每次都生成相同的结果。
可扩展性强：Bazel可以处理大型程序的构建；在Google公司内，一个二进制程序通常有超过100KB的源码文件，在代码文件没有被改动的情况下，构建过程大约需要200ms。
构建速度快：支持增量编译。对依赖关系进行了优化，从而支持并发执行。

4.1 Bazel的工作原理

4.2 Bazel在kubernetes中的使用

Kubernetes 源码的根目录下有一个 WORKSPACE（工作区）文件，用于指定当前目录是 Bazel 的一个工作区域，该文件一般存放在项目根目录下。另外，项目中包含一个或多个 BUILD 文件，用于告诉 Bazel 如何进行构建。Bazel 工作原理大致分为3部分：

加载与 Target 相关的 BUILD 文件。
分析 BUILD 文件的内容，生成ActionGraph。
执行 Action Graph，最后产出 Outputs。

在 vendor/github.com/grpc-ecosystem/grpc-gateway/utilities/BUILD.bazel 文件中，定义如下：

Copy to Clipboard

BUILD文件内容如下。

load：需要使用哪个.bzl规则来编译当前Target。
go_library：设置构建规则。
- name：当前Target构建后的名称。
- src：当前Target下被构建的源码文件。
- deps：当前Target构建时依赖的静态库名称。

5. 附录

hackmake-rulesbuild.sh 脚本主要功能是：就是执行编译。

但其中具体的编译函数，位于 hack/lib/golang.sh ，golang.sh 脚本我截取了 platform 是本机的相关代码，下面看一下这两个脚本的内容：

# hackmake-rulesbuild.sh 脚本

Copy to Clipboard

# hack/lib/golang.sh 脚本

Copy to Clipboard

#!/usr/bin/env bash

# The golang package that we are building.
readonly KUBE_GO_PACKAGE=k8s.io/kubernetes
# 这里的 KUBE_GOPATH = _output/local/go
readonly KUBE_GOPATH="${KUBE_OUTPUT}/go"

# If we update this we should also update the set of platforms whose standard
# library is precompiled for in build/build-image/cross/Dockerfile
readonly KUBE_SUPPORTED_CLIENT_PLATFORMS=(
  linux/amd64
  linux/386
  linux/arm
  linux/arm64
  linux/s390x
  linux/ppc64le
  darwin/amd64
  darwin/arm64
  windows/amd64
  windows/386
)

# Which platforms we should compile test targets for.
# Not all client platforms need these tests
readonly KUBE_SUPPORTED_TEST_PLATFORMS=(
  linux/amd64
  linux/arm
  linux/arm64
  linux/s390x
  linux/ppc64le
  darwin/amd64
  darwin/arm64
  windows/amd64
)

# server 端所有的 targets，最后按空格为分隔符，打印出所有的targets
kube::golang::server_targets() {
  local targets=(
    cmd/kube-proxy
    cmd/kube-apiserver
    cmd/kube-controller-manager
    cmd/kubelet
    cmd/kubeadm
    cmd/kube-scheduler
    vendor/k8s.io/kube-aggregator
    vendor/k8s.io/apiextensions-apiserver
    cluster/gce/gci/mounter
  )
  echo "${targets[@]}"
}
# IFS 指定分隔符，read 指定 变量类型列表，<<< 直接传字符串 按空格解构成列表
# <<< 一般传递字符串，<< 一般用于追加文件，< 用于写入新文件
IFS=" " read -ra KUBE_SERVER_TARGETS <<< "$(kube::golang::server_targets)"
readonly KUBE_SERVER_TARGETS
# ${KUBE_SERVER_TARGETS[@]##*/} 将 KUBE_SERVER_TARGETS 列表的所有元素进行匹配，将所有满足 末尾是 / 的元素删除
# ${变量名##匹配规则} 从变量开头进行规则匹配，将符合数据最长的数据删除（贪婪匹配）
# KUBE_SERVER_BINARIES 表示 server 端需要编译的所有 二进制文件
# Server 端不支持 windows 操作系统
readonly KUBE_SERVER_BINARIES=("${KUBE_SERVER_TARGETS[@]##*/}")

# client 端所有的 targets
readonly KUBE_CLIENT_TARGETS=(
  cmd/kubectl
  cmd/kubectl-convert
)
# 同样 KUBE_CLIENT_BINARIES 表示 所有 client 端的 需要编译的二进制文件
# KUBE_CLIENT_BINARIES_WIN 表示 windows 版的 exe 文件
readonly KUBE_CLIENT_BINARIES=("${KUBE_CLIENT_TARGETS[@]##*/}")
readonly KUBE_CLIENT_BINARIES_WIN=("${KUBE_CLIENT_BINARIES[@]/%/.exe}")

# 客户端 有关测试 test 的所有 targets，最后按空格为分隔符，打印出所有的targets
kube::golang::test_targets() {
  local targets=(
    cmd/gendocs
    cmd/genkubedocs
    cmd/genman
    cmd/genyaml
    cmd/genswaggertypedocs
    cmd/linkcheck
    vendor/github.com/onsi/ginkgo/ginkgo
    test/e2e/e2e.test
    cluster/images/conformance/go-runner
  )
  echo "${targets[@]}"
}
# 同样 将所有的 测试 targets 传入 列表 KUBE_TEST_TARGETS
# 拿到 linux 版 KUBE_TEST_BINARIES 二进制文件，和 windows 版 KUBE_TEST_BINARIES_WIN exe 文件
IFS=" " read -ra KUBE_TEST_TARGETS <<< "$(kube::golang::test_targets)"
readonly KUBE_TEST_TARGETS
readonly KUBE_TEST_BINARIES=("${KUBE_TEST_TARGETS[@]##*/}")
readonly KUBE_TEST_BINARIES_WIN=("${KUBE_TEST_BINARIES[@]/%/.exe}")

# 服务端，可以直接跑在 k8s 上的 二进制测试工具
kube::golang::server_test_targets() {
  local targets=(
    cmd/kubemark
    vendor/github.com/onsi/ginkgo/ginkgo
  )

if [[ "${OSTYPE:-}" == "linux"* ]]; then
    targets+=( test/e2e_node/e2e_node.test )
  fi

echo "${targets[@]}"
}
# 操作同上
IFS=" " read -ra KUBE_TEST_SERVER_TARGETS <<< "$(kube::golang::server_test_targets)"
readonly KUBE_TEST_SERVER_TARGETS
readonly KUBE_TEST_SERVER_BINARIES=("${KUBE_TEST_SERVER_TARGETS[@]##*/}")
readonly KUBE_TEST_SERVER_PLATFORMS=("${KUBE_SERVER_PLATFORMS[@]:+"${KUBE_SERVER_PLATFORMS[@]}"}")

# 如果需要开启 并行模式编译，就需要 内存大于 20G
readonly KUBE_PARALLEL_BUILD_MEMORY=${KUBE_PARALLEL_BUILD_MEMORY:-20}

readonly KUBE_ALL_TARGETS=(
  "${KUBE_SERVER_TARGETS[@]}"
  "${KUBE_CLIENT_TARGETS[@]}"
  "${KUBE_TEST_TARGETS[@]}"
  "${KUBE_TEST_SERVER_TARGETS[@]}"
)
readonly KUBE_ALL_BINARIES=("${KUBE_ALL_TARGETS[@]##*/}")

readonly KUBE_STATIC_LIBRARIES=(
  kube-apiserver
  kube-controller-manager
  kube-scheduler
  kube-proxy
  kubeadm
  kubectl
)

# Fully-qualified package names that we want to instrument for coverage information.
# 所有 可以做 覆盖检测 的软件包列表，也就是 可以使用 go test 构建的软件包列表
readonly KUBE_COVERAGE_INSTRUMENTED_PACKAGES=(
  k8s.io/kubernetes/cmd/kube-apiserver
  k8s.io/kubernetes/cmd/kube-controller-manager
  k8s.io/kubernetes/cmd/kube-scheduler
  k8s.io/kubernetes/cmd/kube-proxy
  k8s.io/kubernetes/cmd/kubelet
)

#  使用 cgo
IFS=" " read -ra KUBE_CGO_OVERRIDES_LIST <<< "${KUBE_CGO_OVERRIDES:-}"
readonly KUBE_CGO_OVERRIDES_LIST

IFS=" " read -ra KUBE_STATIC_OVERRIDES_LIST <<< "${KUBE_STATIC_OVERRIDES:-}"
readonly KUBE_STATIC_OVERRIDES_LIST

# 判断是否是 静态链接库
kube::golang::is_statically_linked_library() {
  local e
  # Explicitly enable cgo when building kubectl for darwin from darwin.
  # 如果是 darwin 系统，并且 target 是 kubectl 那么就是 静态链接库，返回1
  [[ "$(go env GOHOSTOS)" == "darwin" && "$(go env GOOS)" == "darwin" &&
    "$1" == *"/kubectl" ]] && return 1
  # 后面代码段是判断，如果 target 有在 cgo 的列表中的，就是 静态链接库，返回1
  if [[ -n "${KUBE_CGO_OVERRIDES_LIST:+x}" ]]; then
    for e in "${KUBE_CGO_OVERRIDES_LIST[@]}"; do [[ "${1}" == *"/${e}" ]] && return 1; done;
  fi
  for e in "${KUBE_STATIC_LIBRARIES[@]}"; do [[ "${1}" == *"/${e}" ]] && return 0; done;
  if [[ -n "${KUBE_STATIC_OVERRIDES_LIST:+x}" ]]; then
    for e in "${KUBE_STATIC_OVERRIDES_LIST[@]}"; do [[ "${1}" == *"/${e}" ]] && return 0; done;
  fi
  return 1;
}

#  根据之前设置的 targets 列表，返回 完整的 带有域名的 package 名称
kube::golang::binaries_from_targets() {
  local target
  for target; do
    # 如果 是以 域名 开头，那就不需要在添加 kubernetes 域名
    # [[:alnum:]]		匹配任意字母数字字符0-9，A-Z，a-z
    # 也就是 匹配到 xxx.xxx/ 这种域名格式，就不需要添加
    if [[ "${target}" =~ ^([[:alnum:]]+".")+[[:alnum:]]+"/" ]]; then
      echo "${target}"
    else
      # KUBE_GO_PACKAGE=k8s.io/kubernetes 也就是添加 k8s 的域名
      echo "${KUBE_GO_PACKAGE}/${target}"
    fi
  done
}

# 判断本机的 系统信息
kube::golang::host_platform() {
  echo "$(go env GOHOSTOS)/$(go env GOHOSTARCH)"
}

# 获取平台名称 ($1)，并为该平台设置适当的 golang env变量。
kube::golang::set_platform_envs() {
  # 如果传入的参数 平台名称 为空，直接报错
  [[ -n ${1-} ]] || {
    kube::log::error_exit "!!! Internal error. No platform set in kube::golang::set_platform_envs"
  }

export GOOS=${platform%/*}
  export GOARCH=${platform##*/}

# 如果 传入的 platform 不是 本机的系统，设置交叉编译 CC 的变量，本机不设置
  if [[ $(kube::golang::host_platform) != "$platform" ]]; then
    case "${platform}" in
      "linux/amd64")
        export CGO_ENABLED=1
        export CC=${KUBE_LINUX_AMD64_CC:-x86_64-linux-gnu-gcc}
        ;;
      "linux/arm")
        export CGO_ENABLED=1
        export CC=${KUBE_LINUX_ARM_CC:-arm-linux-gnueabihf-gcc}
        ;;
      "linux/arm64")
        export CGO_ENABLED=1
        export CC=${KUBE_LINUX_ARM64_CC:-aarch64-linux-gnu-gcc}
        ;;
      "linux/ppc64le")
        export CGO_ENABLED=1
        export CC=${KUBE_LINUX_PPC64LE_CC:-powerpc64le-linux-gnu-gcc}
        ;;
      "linux/s390x")
        export CGO_ENABLED=1
        export CC=${KUBE_LINUX_S390X_CC:-s390x-linux-gnu-gcc}
        ;;
    esac
  fi

# 如果 交叉编译 允许，那么就开启 CGo
  ccenv=$(echo "$platform" | awk -F/ '{print "KUBE_" toupper($1) "_" toupper($2) "_CC"}')
  if [ -n "${!ccenv-}" ]; then 
    export CGO_ENABLED=1
    export CC="${!ccenv}"
  fi
}

kube::golang::unset_platform_envs() {
  unset GOOS
  unset GOARCH
  unset GOROOT
  unset CGO_ENABLED
  unset CC
}

# kube::golang::setup_env will check that the `go` commands is available in
# ${PATH}. It will also check that the Go version is good enough for the
# Kubernetes build.
#
# Inputs:
#   KUBE_EXTRA_GOPATH - If set, this is included in created GOPATH
#
# Outputs:
#   env-var GOPATH points to our local output dir
#   env-var GOBIN is unset (we want binaries in a predictable place)
#   env-var GO15VENDOREXPERIMENT=1
#   current directory is within GOPATH
kube::golang::setup_env() {
  kube::golang::verify_go_version

kube::golang::create_gopath_tree

export GOPATH="${KUBE_GOPATH}"
  export GOCACHE="${KUBE_GOPATH}/cache"

# Append KUBE_EXTRA_GOPATH to the GOPATH if it is defined.
  if [[ -n ${KUBE_EXTRA_GOPATH:-} ]]; then
    GOPATH="${GOPATH}:${KUBE_EXTRA_GOPATH}"
  fi

# Make sure our own Go binaries are in PATH.
  export PATH="${KUBE_GOPATH}/bin:${PATH}"

# Change directories so that we are within the GOPATH.  Some tools get really
  # upset if this is not true.  We use a whole fake GOPATH here to collect the
  # resultant binaries.  Go will not let us use GOBIN with `go install` and
  # cross-compiling, and `go install -o <file>` only works for a single pkg.
  local subdir
  subdir=$(kube::realpath . | sed "s|${KUBE_ROOT}||")
  cd "${KUBE_GOPATH}/src/${KUBE_GO_PACKAGE}/${subdir}" || return 1

# Set GOROOT so binaries that parse code can work properly.
  GOROOT=$(go env GOROOT)
  export GOROOT

# Unset GOBIN in case it already exists in the current session.
  unset GOBIN

# This seems to matter to some tools
  export GO15VENDOREXPERIMENT=1
}

# place_bins 函数将 二进制文件 从 $GOPATH/bin 目录 拷贝到 ${KUBE_OUTPUT_BINDIR}/${platform} 目录，也就是
# 理想情况下这一步是不需要的，可以直接将 GOBIN 设置成 KUBE_OUTPUT_BINDIR，但是交叉编译时这就不起作用
# go install 在普通编译时将 二进制文件放入到 GOBIN 中
# go install 在交叉编译时，将二进制文件放入到 platform_arch 目录中，例如 linux_amd64
kube::golang::place_bins() {
  # 获取 平台platform 的系统信息
  local host_platform
  host_platform=$(kube::golang::host_platform)

V=2 kube::log::status "Placing binaries"

local platform
  for platform in "${KUBE_CLIENT_PLATFORMS[@]}"; do
    # The substitution on platform_src below will replace all slashes with
    # underscores.  It'll transform darwin/amd64 -> darwin_amd64.
    # ${变量名//旧字符串/新字符串} 满足旧字符串规则的，全部替换成新字符串
    # 将 platform 中的 / 替换成 _ ，我这里本机 platform 为 linux/amd64，替换后为 linux_amd64
    local platform_src="/${platform//\//_}"
    # 如果 platform 是本机
    if [[ "${platform}" == "${host_platform}" ]]; then
      platform_src=""
      # 删除 THIS_PLATFORM_BIN="${KUBE_ROOT}/_output/bin"
      rm -f "${THIS_PLATFORM_BIN}"
      # KUBE_OUTPUT_BINPATH 为 ${KUBE_ROOT}/_output/local/bin
      # 建立软连接，源：${KUBE_ROOT}/_output/local/bin/linux/amd64 链接：${KUBE_ROOT}/_output/bin
      ln -s "${KUBE_OUTPUT_BINPATH}/${platform}" "${THIS_PLATFORM_BIN}"
    fi
    # 如果 platform 是本机，那么 full_binpath_src 为 _output/local/go/bin
    # 如果 platform 不是 本机，那么 full_binpath_src 为 _output/local/go/bin/linux_amd64
    local full_binpath_src="${KUBE_GOPATH}/bin${platform_src}"

if [[ -d "${full_binpath_src}" ]]; then
      # 创建 ${KUBE_ROOT}/_output/local/bin/linux/amd64
      mkdir -p "${KUBE_OUTPUT_BINPATH}/${platform}"
      # -exec: 对搜索到的文件执行特定的操作，格式为 -exec command {} \;
      # 注意： {} 表示find搜索到的所有的结果， 在命令最后 一定要加 \;
      # rsync是linux系统下的数据镜像备份工具。支持本地复制，或者与其他SSH、rsync主机同步。这里用来拷贝本地文件
      # 整条命令是 将 full_binpath_src 下的所有文件，拷贝到 ${KUBE_ROOT}/_output/local/bin/linux/amd64
      find "${full_binpath_src}" -maxdepth 1 -type f -exec \
        rsync -pc {} "${KUBE_OUTPUT_BINPATH}/${platform}" \;
    fi
  done
}

# 返回 output 的输出目录
kube::golang::outfile_for_binary() {
  local binary=$1
  local platform=$2
  # output_path = _output/local/bin
  local output_path="${KUBE_GOPATH}/bin"
  local bin
  bin=$(basename "${binary}")
  if [[ "${platform}" != "${host_platform}" ]]; then
    output_path="${output_path}/${platform//\//_}"
  fi
  if [[ ${GOOS} == "windows" ]]; then
    bin="${bin}.exe"
  fi
  # 最终返回的就是 _output/local/bin/platform/path
  # 例如 我本机的就是 _output/local/bin/linux/amd64
  echo "${output_path}/${bin}"
}

# is_instrumented_package 函数用来判断 target 是否可以进行 覆盖检测
# 传入参数：target 软件包
# 如果 target 可以 覆盖检测，返回1，否则返回0
kube::golang::is_instrumented_package() {
  # array_contains target, item1, item2, item3, ...  判断 target 是否在后面 item 中，如果在，返回0，否则返回1
  kube::util::array_contains "$1" "${KUBE_COVERAGE_INSTRUMENTED_PACKAGES[@]}"
  return $?
}

# path_for_coverage_dummy_test 函数 用来返回一个 用于单元测试的文件，也就是后缀为 _test，用于 测试
# 传入参数：某个target，也就是 package名称
kube::golang::path_for_coverage_dummy_test() {
  local package="$1"
  # KUBE_GOPATH = _output/local/go
  # 那么 path 就为：_output/local/go/src/path-to-package
  local path="${KUBE_GOPATH}/src/${package}"
  local name
  # name 表示 package 的 名称
  name=$(basename "${package}")
  # 返回 路径/zz_generated_${name}_test.go 测试文件完整路径
  echo "${path}/zz_generated_${name}_test.go"
}

# create_coverage_dummy_test 函数
# 传入参数：某个target，也就是 package名称
# 在给定软件包的源目录中的磁盘上创建一个虚拟单元测试。
# 运行时，此单元测试将调用软件包的标准入口点。
kube::golang::create_coverage_dummy_test() {
  local package="$1"
  local name
  # name 表示 package 的目录
  name="$(basename "${package}")"
  # path_for_coverage_dummy_test 函数 返回完整的测试文件的完整路径
  # 下面 cat 用于创建这个文件，并写入下面的内容
  cat <<EOF > "$(kube::golang::path_for_coverage_dummy_test "${package}")"
package main
import (
  "testing"
  "k8s.io/kubernetes/pkg/util/coverage"
)

func TestMain(m *testing.M) {
  // Get coverage running
  coverage.InitCoverage("${name}")

// Go!
  main()

// Make sure we actually write the profiling information to disk, if we make it here.
  // On long-running services, or anything that calls os.Exit(), this is insufficient,
  // so we also flush periodically with a default period of five seconds (configurable by
  // the KUBE_COVERAGE_FLUSH_INTERVAL environment variable).
  coverage.FlushCoverage()
}
EOF
}

# 删除 测试文件
# 传入参数：target名称
kube::golang::delete_coverage_dummy_test() {
  local package="$1"
  rm -f "$(kube::golang::path_for_coverage_dummy_test "${package}")"
}

# build_some_binaries 函数 是具体编译构建 target 的过程
# 传入： 要构建的kubernetes软件包列表，target 列表
# 预配置的变量：${build_args} 是 编译的参数； ${platform} 平台的系统信息
# 预配置的环境变量：${KUBE_BUILD_WITH_COVERAGE} 是否启用覆盖检测
# 如果禁用了覆盖率，则只需调用go install。 如果启用覆盖检测，则使用go test构建覆盖的二进制文件，临时生成所需的单元测试文件，然后对其进行清理。
kube::golang::build_some_binaries() {
  # 如果 开启了 覆盖检测
  if [[ -n "${KUBE_BUILD_WITH_COVERAGE:-}" ]]; then
    local -a uncovered=()
    # 遍历每一个 target
    for package in "$@"; do
      # 这里注意： shell 编程中，0是True，1是false
      # 这里判断如果 当前 package 是 可覆盖检测的，那么就进行 go test 编译
      if kube::golang::is_instrumented_package "${package}"; then
        V=2 kube::log::info "Building ${package} with coverage..."
        # create_coverage_dummy_test 函数 创建 该 package 的测试文件，并写入调用 main 函数的 测试内容
        kube::golang::create_coverage_dummy_test "${package}"
        # 将删除测试文件，添加到 trap 捕捉 EXIT 信号 的 操作指令中，
        kube::util::trap_add "kube::golang::delete_coverage_dummy_test \"${package}\"" EXIT
        # 执行 go test 进行 覆盖检测
        # 最后在退出时，trap 检测到 EXIT 信号，则执行 delete_coverage_dummy_test 函数，删除 测试文件
        go test -c -o "$(kube::golang::outfile_for_binary "${package}" "${platform}")" \
          -covermode count \
          -coverpkg k8s.io/...,k8s.io/kubernetes/vendor/k8s.io/... \
          "${build_args[@]}" \
          -tags coverage \
          "${package}"
      # 如果 当前的 package 是不可以覆盖检测，那么 添加到 uncovered 列表中
      else
        uncovered+=("${package}")
      fi
    done

# 这里就是 禁止 覆盖检测 编译的逻辑，直接使用 go install
    if [[ "${#uncovered[@]}" != 0 ]]; then
      V=2 kube::log::info "Building ${uncovered[*]} without coverage..."
      go install "${build_args[@]}" "${uncovered[@]}"
    else
      V=2 kube::log::info "Nothing to build without coverage."
    fi
   # 如果没有开启 覆盖检测，KUBE_BUILD_WITH_COVERAGE 为空，那么就直接 go install 进行编译
   else
    V=2 kube::log::info "Coverage is disabled."
    go install "${build_args[@]}" "$@"
   fi
}

# 根据不同的 platform 来编译二进制文件
kube::golang::build_binaries_for_platform() {
  # umask 0022 表示默认创建新文件权限为755 也就是 rxwr-xr-x
  umask 0022

local platform=$1

local -a statics=()
  local -a nonstatics=()
  local -a tests=()

V=2 kube::log::info "Env for ${platform}: GOOS=${GOOS-} GOARCH=${GOARCH-} GOROOT=${GOROOT-} CGO_ENABLED=${CGO_ENABLED-} CC=${CC-}"

# 遍历每一个 target 进行编译
  # 下面这个遍历时进行归类：
  # 1. .test 结尾：放入 tests 列表
  # 2. 静态链接库：放入 statics 列表
  # 3. 非静态链接库：放入 nonstatics 列表
  for binary in "${binaries[@]}"; do
    # 如果是以.test 结尾，只有两个 ： e2e.test 和  e2e_node.test
    # =~ 表示允许使用正则
    if [[ "${binary}" =~ ".test"$ ]]; then
      tests+=("${binary}")
    elif kube::golang::is_statically_linked_library "${binary}"; then
      statics+=("${binary}")
    else
      nonstatics+=("${binary}")
    fi
  done

local -a build_args
  # 编译 静态链接库
  if [[ "${#statics[@]}" != 0 ]]; then
    # 编译的参数，这里的参数，在 build_binaries 前面都已经设置过了
    build_args=(
      -installsuffix static
      ${goflags:+"${goflags[@]}"}
      -gcflags "${gogcflags:-}"
      -asmflags "${goasmflags:-}"
      -ldflags "${goldflags:-}"
      -tags "${gotags:-}"
    )
    # 开始执行编译函数 build_some_binaries
    CGO_ENABLED=0 kube::golang::build_some_binaries "${statics[@]}"
  fi

# 编译 非静态链接库 ，与静态链接库编译的区别就是，是否启用 cgo
  if [[ "${#nonstatics[@]}" != 0 ]]; then
    build_args=(
      ${goflags:+"${goflags[@]}"}
      -gcflags "${gogcflags:-}"
      -asmflags "${goasmflags:-}"
      -ldflags "${goldflags:-}"
      -tags "${gotags:-}"
    )
    kube::golang::build_some_binaries "${nonstatics[@]}"
  fi

# 编译.test ，直接用 go test 编译，并且执行测试文件
  for test in "${tests[@]:+${tests[@]}}"; do
    local outfile testpkg
    # outfile_for_binary 函数 返回 输出目录
    outfile=$(kube::golang::outfile_for_binary "${test}" "${platform}")
    testpkg=$(dirname "${test}")

mkdir -p "$(dirname "${outfile}")"
    go test -c \
      ${goflags:+"${goflags[@]}"} \
      -gcflags "${gogcflags:-}" \
      -asmflags "${goasmflags:-}" \
      -ldflags "${goldflags:-}" \
      -tags "${gotags:-}" \
      -o "${outfile}" \
      "${testpkg}"
  done
}

# 返回可以用的 物理内存
# 有三种方式：
# 1. /proc/meminfo 文件中的 MemAvailable 字段
# 2. /proc/meminfo 文件中的 MemTotal 字段
# 3. 如果是 docker 容器， sysctl -n hw.memsize 2>/dev/null
kube::golang::get_physmem() {
  local mem

# 查看 /proc/meminfo 文件中的 MemAvailable 字段，查看还有多少可用的内存
  if mem=$(grep MemAvailable /proc/meminfo | awk '{ print $2 }'); then
    echo $(( mem / 1048576 ))
    return
  fi

# Linux, in kb
  if mem=$(grep MemTotal /proc/meminfo | awk '{ print $2 }'); then
    echo $(( mem / 1048576 ))
    return
  fi

# 如果是 docker 容器，执行此命令查看
  if mem=$(sysctl -n hw.memsize 2>/dev/null); then
    echo $(( mem / 1073741824 ))
    return
  fi

# 如果都没有，那么 返回1，假设内存不足
  echo 1
}

# build_binaries 函数用于编译出 二进制文件
# 输入：targets and go flags 如果targets为空，表示编译所有
# KUBE_BUILD_PLATFORMS 环境变量：使用什么平台进行构建，默认是主机模式
kube::golang::build_binaries() {
  # Create a sub-shell so that we don't pollute the outer environment
  # 这里使用 () 来启动一个 sub-shell 来执行下面代码，以至于不会污染外部的环境变量
  (
    # setup_env 函数用于构建一个 可以使用的 Go 执行环境
    kube::golang::setup_env
    # 打印 info 消息
    V=2 kube::log::info "Go version: $(GOFLAGS='' go version)"

# 拿到 机器 的版本信息 linux/amd64
    local host_platform
    host_platform=$(kube::golang::host_platform)

# 设置 局部变量
    local goflags goldflags goasmflags gogcflags gotags

# 设置 编译时的标记选项
    # goldflags -s -w 选项来禁用符号表以及debug信息
    # kube::version::ldflags 函数 打印需要传递给 go build 的 -ldflags 参数的值
    goldflags="${GOLDFLAGS=-s -w -buildid=} $(kube::version::ldflags)"
    goasmflags="-trimpath=${KUBE_ROOT}"
    gogcflags="${GOGCFLAGS:-} -trimpath=${KUBE_ROOT}"

# extract tags if any specified in GOFLAGS
    # shellcheck disable=SC2001
    # 提取 在 GOFLAGS 中设置的 tag
    gotags="selinux,notest,$(echo "${GOFLAGS:-}" | sed -e 's|.*-tags=$[^-]*$.*|\1|')"

# targets 是一个列表
    local -a targets=()
    local arg

# 将传入的参数做判断，如果 以 - 开头，表示是 go flags，其他为 targets
    for arg; do
      if [[ "${arg}" == -* ]]; then
        # Assume arguments starting with a dash are flags to pass to go.
        goflags+=("${arg}")
      else
        targets+=("${arg}")
      fi
    done

# ${#targets[@]} 表示数组的元素个数
    # 如果传入的 targets 为空，则直接使用所有的 targets
    if [[ ${#targets[@]} -eq 0 ]]; then
      targets=("${KUBE_ALL_TARGETS[@]}")
    fi

local -a platforms
    # 读取 KUBE_BUILD_PLATFORMS  本机的系统版本信息
    IFS=" " read -ra platforms <<< "${KUBE_BUILD_PLATFORMS:-}"
    # 如果 没有 配置 KUBE_BUILD_PLATFORMS ，则直接 获取 本机的 系统信息
    if [[ ${#platforms[@]} -eq 0 ]]; then
      platforms=("${host_platform}")
    fi

local -a binaries
    # read -r 屏蔽转义字符\
    # kube::golang::binaries_from_targets 传入了 所有 targets 的元素
    # binaries 就是 包括域名的完整的 package 名称
    while IFS="" read -r binary; do binaries+=("$binary"); done < <(kube::golang::binaries_from_targets "${targets[@]}")

local parallel=false
    # 如果需要编译的平台 platforms 大于一个，就可以开启并行模式
    if [[ ${#platforms[@]} -gt 1 ]]; then
      local gigs
      # 获取 物理机的可用内存
      gigs=$(kube::golang::get_physmem)

# 这里判断是否可以开启 并行模式 编译，要求：可用内存大于等于20G
      # KUBE_PARALLEL_BUILD_MEMORY 默认是 20
      if [[ ${gigs} -ge ${KUBE_PARALLEL_BUILD_MEMORY} ]]; then
        kube::log::status "Multiple platforms requested and available ${gigs}G >= threshold ${KUBE_PARALLEL_BUILD_MEMORY}G, building platforms in parallel"
        parallel=true
      else
        kube::log::status "Multiple platforms requested, but available ${gigs}G < threshold ${KUBE_PARALLEL_BUILD_MEMORY}G, building platforms in serial"
        parallel=false
      fi
    fi

# 如果开启 并行模式
    if [[ "${parallel}" == "true" ]]; then
      kube::log::status "Building go targets for {${platforms[*]}} in parallel (output will appear in a burst when complete):" "${targets[@]}"
      local platform
      # 如果有多个 编译的平台，我这里就只有一个本机
      for platform in "${platforms[@]}"; do (
          # set_platform_envs 函数 根据不同的 platform 设置不同的 golang 环境
          kube::golang::set_platform_envs "${platform}"
          kube::log::status "${platform}: build started"

kube::golang::build_binaries_for_platform "${platform}"
          kube::log::status "${platform}: build finished"
        ) &> "/tmp//${platform//\//_}.build" &
      done

local fails=0
      for job in $(jobs -p); do
        wait "${job}" || (( fails+=1 ))
      done

for platform in "${platforms[@]}"; do
        cat "/tmp//${platform//\//_}.build"
      done

exit "${fails}"
    # 如果不开启 并行模式
    else
      for platform in "${platforms[@]}"; do
        kube::log::status "Building go targets for ${platform}:" "${targets[@]}"
        (
          kube::golang::set_platform_envs "${platform}"
          kube::golang::build_binaries_for_platform "${platform}"
        )
      done
    fi
  )
}

Post Views: 1,074

2. K8s 构建方式及代码生成器

1. kubernetes 构建方式

1.1 构建方式简介

1.1 构建方式 Makefile 过程分析

2. 本地环境构建

2.1 make all 源码分析（ Makefile 文件）

# 变量的初始化

# GOFLAGS 环境变量

# make all 逻辑

# make generated_files 逻辑

2.2 make generated_files 源码分析（Makefile.generated_files文件）

# 变量的初始化

# 目标 generated_files 的逻辑

2.3 代码生成器（Makefile.generated_files文件）

2.3.1. 寻找所有带有 // +k8s: 的Tags的文件列表

# 寻找带有 Tags 的文件列表

# cache_go_dirs.sh 脚本

2.3.2. prerelease-lifecycle 代码生成器

# prerelease-lifecycle-gen 代码生成器

# zz_generated.prerelease-lifecycle.go

2.3.3. deepcopy-gen 代码生成器

# zz_generated.deepcopy.go

2.3.4. defaulter-gen 代码生成器

# zz_generated.defaults.go

2.3.5. conversion-gen代码生成器

# zz_generated.conversion.go

2.3.6. openapi-gen 代码生成器

# zz_generated.openapi.go

2.3.7. go-bindata 代码生成器

3. 容器环境构建

3.1 make quick-release 在 Makefile 的源码分析

# make quick-release 逻辑

3.2 容器环境构建过程

3.2.1 步骤1-环境配置与验证

3.2.2 步骤2-编译镜像

3.2.3 步骤3-构建方法

3.2.4 步骤4-将文件从容器中拷贝到主机

3.2.5 步骤5-打包

4. Bazel环境构建

4.1 Bazel的工作原理

4.2 Bazel在kubernetes中的使用

5. 附录

# hackmake-rulesbuild.sh 脚本

# hack/lib/golang.sh 脚本

Share This Story, Choose Your Platform!

评论 取消回复

评论取消回复