This is a creation in Article, where the information may have evolved or changed.
Objective
Large software (linux,android etc) generally has its own construction system, k8s is no exception, this article briefly introduces k8s construction system
Build process
Release
Take Quick-release as an example, execute the following command at the command line
# make quick-release
Make to the quick-release target in the source root Makefile file, the action of the target is to execute the build/release.sh script
# kubernetes/Makefile.PHONY: release-skip-tests quick-releaseifeq ($(PRINT_HELP),y)release-skip-tests quick-release: @echo "$$RELEASE_SKIP_TESTS_HELP_INFO"elserelease-skip-tests quick-release: KUBE_RELEASE_RUN_TESTS = nrelease-skip-tests quick-release: KUBE_FASTBUILD = truerelease-skip-tests quick-release: build/release.sh <--- 执行 kubernetes/build/release.shendif
Release.sh split the build process into steps, each of which corresponds to a shell function
# kubernetes/build/release.sh...kube::build::verify_prereqskube::build::build_imagekube::build::run_build_command make cross...kube::build::copy_outputkube::release::package_tarballs
Verify_prereqs to examine the build environment, such as the lack of some tool software
Build_image Create the Docker image needed for the build???
Run_build_command make cross boot container, run make Cross
Copy_output, Package_tar processing the individual files generated by the build
The interesting thing here is that k8s is built using a Docker container, probably for cross-compiling.
Build image
Kube::build::build_image method constructs the base image, synchronizes the kubernetes source code to the data container (Volume container)
function Kube::build::build_image () {mkdir-p "${local_output_build_context}" # Make sure the CONTEXT direct Ory owned by the right user for syncing sources to container. Chown-r ${user_id}:${group_id} "${local_output_build_context}" Cp/etc/localtime "${local_output_build_context}/" # Prepare the image to build the required files CP build/build-image/dockerfile "${local_output_build_context}/dockerfile" CP build/build-image/ rsyncd.sh "${local_output_build_context}/" 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 "Kube::build::update_dockerfile Kube::build::set_proxy # Build Image kube::build::d ocker_build" ${ Kube_build_image} "" ${local_output_build_context} "' False ' ... # to build a data volume image, note that the word ensure-data volume mirroring is reusable kube::build::ensure _data_container # Synchronizing Kubernetes source code to data volume mirroring Kube::build::sync_to_container}
The following types of containers are used in the k8s build process:
- Data Volume Container: Stores k8s source code, and other containers--volume-from share data volumes when they start
- RSYNCD Container: Running the RSYNCD service (a file synchronization service), synchronizing k8s source code from host to data volume container
- Build container: Run Build command
Source Code Synchronization
As mentioned above, when the k8s is built, it starts a container to run the RSYNCD service, synchronizes the k8s source code to the data volume container, then where will the source code be synchronized?
# kubernete/build/common.shfunction kube::build::sync_to_container() { kube::log::status "Syncing sources to container" kube::build::start_rsyncd_container kube::build::rsync \ --delete \ --filter='H /.git' \ --filter='- /.make/' \ --filter='- /_tmp/' \ --filter='- /_output/' \ --filter='- /' \ --filter='H zz_generated.*' \ --filter='H generated.proto' \ "${KUBE_ROOT}/" "rsync://k8s@${KUBE_RSYNC_ADDR}/k8s/"}
The Kube::build::rsync method synchronizes the source code under the Kube_root directory to k8s@${kube_rsync_addr}/k8s/
View the Rsync profile to know the actual directory that corresponds to the k8s virtual directory
# kubernetes/build/build-image/rsyncd.sh...VOLUME=${HOME}cat <<EOF >"${CONFFILE}"pid file = ${PIDFILE}use chroot = nolog file = /dev/stdoutreverse lookup = nomunge symlinks = noport = 8730[k8s] numeric ids = true $USER_CONFIG hosts deny = * hosts allow = ${ALLOW} ${ALLOW_HOST-} auth users = k8s secrets file = ${SECRETS} read only = false path = ${VOLUME} <-- k8s 对应的路径 ${VOLUME} = ${HOME} filter = - /.make/ - /_tmp/EOF
This home variable generally points to the user's home directory, but from the Go Language Engineering directory structure, HOME should point to a directory similar to the $GOPATH/src/k8s.io/kubernetes, so experience and intuition tell us there must be somewhere to set the HOME variable, by searching the source generation Code, which confirms that it does.
# kubernetes/build/build-image/Dockerfile...ENV HOME /go/src/k8s.io/kubernetesWORKDIR ${HOME}...
Summarize
By analyzing the K8s building system, you can learn how big companies like Google plan large software engineering structures, build, publish