Skip to content
bootkube - Launch a self-hosted Kubernetes cluster
Go Shell Ruby Groovy HCL Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
Documentation Merge pull request #1045 from andrewrynhard/go-modules Nov 10, 2019
build chore: update import paths Nov 9, 2019
e2e chore: update import paths Nov 9, 2019
hack replaces node-role with node to have kubelet labeling work Nov 11, 2019
image image/checkpoint: remove unused manifests Aug 21, 2017
pkg Merge pull request #1061 from rmenn/f_update_coredns Nov 12, 2019
scripts vendor: pin transitive dependencies Feb 27, 2019
vendor chore: run go mod vendor Oct 7, 2019
.gitignore gitignore: ignore hack/e2e litter Jan 24, 2018
.travis.yml chore: move to go modules Oct 7, 2019
LICENSE Use official kubernetes documents Jan 4, 2017
OWNERS_ALIASES Create OWNERS_ALIASES Oct 23, 2019 chore: update import paths Nov 9, 2019 chore: update import paths Nov 9, 2019
bill-of-materials.json chore: update import paths Nov 9, 2019 Update Dec 20, 2017
go.mod updates client-go and necessary changes Nov 11, 2019
go.sum updates client-go and necessary changes Nov 11, 2019


Build Status GoDoc Go Report Card

Bootkube is a tool for launching self-hosted Kubernetes clusters.

When launched, bootkube will deploy a temporary Kubernetes control-plane (api-server, scheduler, controller-manager), which operates long enough to bootstrap a replacement self-hosted control-plane.

Additionally, bootkube can be used to generate all of the necessary assets for use in bootstrapping a new cluster. These assets can then be modified to support any additional configuration options.

Details of self-hosting



Bootkube has two main commands: render and start.

There is a third, experimental command recover which can help reboot a downed cluster (see below).

Render assets

Bootkube can be used to render all of the assets necessary for bootstrapping a self-hosted Kubernetes cluster. This includes generation of TLS assets, Kubernetes object manifests, and a kubeconfig to connect to the bootstrapped cluster.

To see available options, run:

bootkube render --help


bootkube render --asset-dir=my-cluster

The resulting assets can be inspected / modified in the generated asset-dir.

Start bootkube

To start bootkube use the start subcommand.

To see available options, run:

bootkube start --help


bootkube start --asset-dir=my-cluster

When bootkube start is creating Kubernetes resources from manifests, the following order is used:

  1. Any Namespace objects are created, in lexicographical order.
  2. Any CustomResourceDefinition objects are created, in lexicographical order.
  3. Any remaining resources are created, in lexicographical order.

Recover a downed cluster

In the case of a partial or total control plane outage (i.e. due to lost master nodes) an experimental recover command can extract and write manifests from a backup location. These manifests can then be used by the start command to reboot the cluster. Currently recovery from a running apiserver, an external running etcd cluster, or an etcd backup taken from the self hosted etcd cluster are the methods.

For more details and examples see disaster recovery documentation.


See Documentation/ for more information.

Getting Involved

Want to contribute to bootkube? Have Questions? We are looking for active participation from the community

You can find us at the #bootkube channel on Kubernetes slack.

Related Links


bootkube is under the Apache 2.0 license. See the LICENSE file for details.

You can’t perform that action at this time.