Kubeadm v1.8 Features: Self-Hosting, Extensibility, and Improvements

This is a much cleaner and safer way of performing an upgrade than the previous version. As with any type of upgrade or downgrade, it’s a good idea to backup your cluster first using your preferred solution. ## Self-hosting Self-hosting in this context refers to a specific way of setting up the control plane. The self-hosting concept was initially developed by CoreOS in their [bootkube](https://github.com/kubernetes-incubator/bootkube) project. The long-term goal is to move this functionality (currently in an alpha stage) to the generic kubeadm toolbox. Self-hosting means that the control plane components, the API Server, Controller Manager and Scheduler are workloads themselves in the cluster they run. This means the control plane components can be managed using Kubernetes primitives, which has numerous advantages. For instance, leader-elected components like the scheduler and controller-manager will automatically be run on all masters when HA is implemented if they are run in a DaemonSet. Rolling upgrades in Kubernetes can be used for upgrades of the control plane components, and next to no extra code has to be written for that to work; it’s one of Kubernetes’ built-in primitives! Self-hosting won’t be the default until v1.9.0, but users can easily test the feature in experimental clusters. If you test this feature, we’d love your feedback! You can test out self-hosting by enabling its feature gate: ``` $ kubeadm init --feature-gates=SelfHosting=true ``` ## Extensibility We’ve added some new extensibility features. You can delegate some tasks, like generating certificates or writing control plane arguments to kubeadm, but still drive the control plane bootstrap process yourself. Basically, you can let kubeadm do some parts and fill in yourself where you need customizations. Previously, you could only use kubeadm init to perform “the full meal deal.” The inclusion of the kubeadm alpha phase command supports our aim to make kubeadm more modular, letting you invoke atomic sub-steps of the bootstrap process. In v1.8.0, kubeadm alpha phase is just that: an alpha preview. We hope that we can graduate the command to beta as kubeadm phase in v1.9.0. We can’t wait for feedback from the community on how to better improve this feature! ## Improvements Along with our new kubeadm features, we’ve also made improvements to existing ones. The Bootstrap Token feature that makes `kubeadm join` so short and sweet has graduated from alpha to beta and gained even more security features. If you made customizations to your system in v1.6 or v1.7, you had to remember what those customizations were when you upgraded your cluster. No longer: beginning with v1.8.0, kubeadm uploads your configuration to a ConfigMap inside of the cluster, and later reads that configuration when upgrading for a seamless user experience. The first certificate rotation feature has graduated to beta in v1.8, which is great to see. Thanks to the [Auth Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-auth), the Kubernetes node component kubelet can now [rotate its client certificate](https://github.com/kubernetes/features/issues/266) automatically. We expect this area to improve continuously, and will continue to be a part of this cross-SIG effort to easily rotate all certificates in any cluster. Last but not least, kubeadm is more resilient now. kubeadm init will detect even more faulty environments earlier, and time out instead of waiting forever for the expected condition. ## The scope of kubeadm As there are so many different end-to-end installers for Kubernetes, there is some fragmentation in the ecosystem. With each new release of Kubernetes, these installers naturally become more divergent. This can create problems down the line if users rely on installer-specific variations and hooks that aren’t standardized in any way. Our goal from the beginning has been to make kubeadm a building block for deploying Kubernetes clusters and to provide kubeadm init and kubeadm join as best-practice “fast paths” for new Kubernetes users. Ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.

Kubeadm v1.8 introduces self-hosting, where control plane components run as workloads within the cluster, managed by Kubernetes primitives. This feature, currently in alpha, allows for easier upgrades and management. Extensibility is improved with the `kubeadm alpha phase` command, enabling users to customize the bootstrap process. Improvements include the graduation of Bootstrap Tokens to beta and the ability for kubeadm to upload and read configurations during upgrades. The first certificate rotation feature has graduated to beta, allowing kubelets to automatically rotate client certificates. Kubeadm is now more resilient, detecting faulty environments earlier. The goal of kubeadm is to serve as a building block for deploying Kubernetes clusters and providing best-practice fast paths for new users, thus easing the creation of conformant clusters.