This project now lives at https://github.com/kinvolk/bootkube
Go
1,145
1,096 commits
updated Jun 30, 2021
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.
Bootkube has two main commands: render and start.
There is a third, experimental command recover which can help reboot a downed cluster (see below).
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.
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:
Namespace objects are created, in lexicographical order.CustomResourceDefinition objects are created, in lexicographical order.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/development.md for more information.
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.
bootkube is under the Apache 2.0 license. See the LICENSE file for details.
Latest release
Releases this year
417 followers · starred May 2016
268 followers · starred Mar 2018
112 followers · starred Sep 2016
249 followers · starred Jan 2018
This project now lives at https://github.com/kinvolk/bootkube
Go
1,145
1,096 commits
updated Jun 30, 2021
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.
Bootkube has two main commands: render and start.
There is a third, experimental command recover which can help reboot a downed cluster (see below).
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.
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:
Namespace objects are created, in lexicographical order.CustomResourceDefinition objects are created, in lexicographical order.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/development.md for more information.
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.
bootkube is under the Apache 2.0 license. See the LICENSE file for details.
Latest release
Releases this year
417 followers · starred May 2016
268 followers · starred Mar 2018
112 followers · starred Sep 2016
249 followers · starred Jan 2018