Skip to content
This repository was archived by the owner on Jul 30, 2021. It is now read-only.

kubernetes-retired/bootkube

Folders and files

NameName
Last commit message
Last commit date

Latest commit

56216d7 · Jun 30, 2021
Jun 30, 2021
May 19, 2020
May 19, 2020
May 19, 2020
Dec 1, 2019
Aug 21, 2017
Oct 14, 2020
Apr 28, 2020
Apr 15, 2020
Oct 7, 2019
Jan 4, 2017
Jan 4, 2017
May 19, 2020
Mar 29, 2016
Feb 13, 2020
Oct 23, 2019
Jan 10, 2021
Nov 10, 2019
Nov 9, 2019
Nov 7, 2019
Nov 9, 2019
Dec 20, 2017
Apr 28, 2020
Apr 28, 2020

Repository files navigation

Bootkube

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

Guides

Usage

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

Example:

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

Example:

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.

Development

See Documentation/development.md 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

License

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