![]() |
8 years ago | |
---|---|---|
.. | ||
build-image | 8 years ago | |
cni | 8 years ago | |
debian-iptables | 8 years ago | |
kube-dns | 8 years ago | |
pause | 8 years ago | |
OWNERS | 8 years ago | |
README.md | 8 years ago | |
common.sh | 8 years ago | |
copy-output.sh | 8 years ago | |
json-extractor.py | 8 years ago | |
make-build-image.sh | 8 years ago | |
make-clean.sh | 8 years ago | |
make-release-notes.sh | 8 years ago | |
push-ci-build.sh | 8 years ago | |
push-devel-build.sh | 8 years ago | |
push-federation-images.sh | 8 years ago | |
push-official-release.sh | 8 years ago | |
release.sh | 8 years ago | |
run.sh | 8 years ago | |
shell.sh | 8 years ago | |
util.sh | 8 years ago | |
versionize-docs.sh | 8 years ago |
Building Kubernetes is easy if you take advantage of the containerized build environment. This document will help guide you through understanding this build process.
make quick-release
from /tmp/
(See: #14773)You must install and configure Google Cloud SDK if you want to upload your release to Google Cloud Storage and may safely omit this otherwise.
While it is possible to build Kubernetes using a local golang installation, we have a build process that runs in a Docker container. This simplifies initial set up and provides for a very consistent build and test environment.
There is also early support for building Docker "run" containers
The following scripts are found in the build/
directory:
run.sh
: Run a command in a build docker container. Common invocations:
run.sh make
: Build just linux binaries in the container. Pass options and packages as necessary.run.sh make cross
: Build all binaries for all platformsrun.sh make test
: Run all unit testsrun.sh make test-integration
: Run integration testrun.sh make test-cmd
: Run CLI testscopy-output.sh
: This will copy the contents of _output/dockerized/bin
from any remote Docker container to the local _output/dockerized/bin
. Right now this is only necessary on Mac OS X with boot2docker
when your git repo isn't under /Users
.make-clean.sh
: Clean out the contents of _output/dockerized
and remove any local built container images.shell.sh
: Drop into a bash
shell in a build container with a snapshot of the current repo code.release.sh
: Build everything, test it, and (optionally) upload the results to a GCS bucket.The build/release.sh
script will build a release. It will build binaries, run tests, (optionally) build runtime Docker images and then (optionally) upload all build artifacts to a GCS bucket.
The main output is a tar file: kubernetes.tar.gz
. This includes:
kubectl
) for picking and running the right client binary based on platform.In addition, there are some other tar files that are created:
kubernetes-client-*.tar.gz
Client binaries for a specific platform.kubernetes-server-*.tar.gz
Server binaries for a specific platform.kubernetes-salt.tar.gz
The salt script/tree shared across multiple deployment scripts.The release utilities grab a set of environment variables to modify behavior. Arguably, these should be command line flags:
Env Variable | Default | Description |
---|---|---|
KUBE_SKIP_CONFIRMATIONS |
n |
If y then no questions are asked and the scripts just continue. |
KUBE_GCS_UPLOAD_RELEASE |
n |
Upload release artifacts to GCS |
KUBE_GCS_RELEASE_BUCKET |
kubernetes-releases-${project_hash} |
The bucket to upload releases to |
KUBE_GCS_RELEASE_PREFIX |
devel |
The path under the release bucket to put releases |
KUBE_GCS_MAKE_PUBLIC |
y |
Make GCS links readable from anywhere |
KUBE_GCS_NO_CACHING |
y |
Disable HTTP caching of GCS release artifacts. By default GCS will cache public objects for up to an hour. When doing "devel" releases this can cause problems. |
KUBE_GCS_DOCKER_REG_PREFIX |
docker-reg |
Experimental When uploading docker images, the bucket that backs the registry. |
The scripts directly under build/
are used to build and test. They will ensure that the kube-build
Docker image is built (based on build/build-image/Dockerfile
) and then execute the appropriate command in that container. If necessary (for Mac OS X), the scripts will also copy results out.
The kube-build
container image is built by first creating a "context" directory in _output/images/build-image
. It is done there instead of at the root of the Kubernetes repo to minimize the amount of data we need to package up when building the image.
Everything in build/build-image/
is meant to be run inside of the container. If it doesn't think it is running in the container it'll throw a warning. While you can run some of that stuff outside of the container, it wasn't built to do so.
When building final release tars, they are first staged into _output/release-stage
before being tar'd up and put into _output/release-tars
.
If you are behind a proxy, you need to export proxy settings for kubernetes build, the following environment variables should be defined.
export KUBERNETES_HTTP_PROXY=http://username:password@proxyaddr:proxyport
export KUBERNETES_HTTPS_PROXY=https://username:password@proxyaddr:proxyport
Optionally, you can specify addresses of no proxy for kubernetes build, for example
export KUBERNETES_NO_PROXY=127.0.0.1
If you are using sudo to make kubernetes build for example make quick-release, you need run sudo -E make quick-release
to pass the environment variables.
These are in no particular order
hack/
. How much do we support building outside of Docker and these scripts?