Kubeadm Improvements, Scope, and Future Plans

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 performs the actions necessary to get a minimum viable cluster up and running. It only cares about bootstrapping, not about provisioning machines, by design. Likewise, installing various nice-to-have addons by default like the [Kubernetes Dashboard](https://github.com/kubernetes/dashboard), some monitoring solution, cloud provider-specific addons, etc. is not in scope. Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, that installs the software the end user needs. ## v1.9.0 and beyond What’s in store for the future of kubeadm? #### Planned features We plan to address high availability (replicated etcd and multiple, redundant API servers and other control plane components) as an alpha feature in v1.9.0. This has been a regular request from our user base. Also, we want to make self-hosting the default way to deploy your control plane: Kubernetes becomes much easier to manage if we can rely on Kubernetes' own tools to manage the cluster components. #### Promoting kubeadm adoption and getting involved The [kubeadm adoption working group](https://github.com/kubernetes/community/tree/master/wg-kubeadm-adoption) is an ongoing effort between SIG Cluster Lifecycle and other parties in the Kubernetes ecosystem. This working group focuses on making kubeadm more extensible in order to promote adoption of it for other end-to-end installers in the community. Everyone is welcome to join. So far, we’re glad to announce that [kubespray](https://github.com/kubernetes-incubator/kubespray) started using kubeadm under the hood, and gained new features at the same time! We’re excited to see others follow and make the ecosystem stronger.

Kubeadm v1.8 introduces automatic client certificate rotation for kubelets and improved resilience. Kubeadm aims to provide a foundation for Kubernetes deployments, focusing on bootstrapping a minimum viable cluster. It does not handle machine provisioning or installing add-ons, instead encouraging higher-level tools to build upon it. Future plans for kubeadm include introducing high availability as an alpha feature in v1.9.0 and making self-hosting the default deployment method. The kubeadm adoption working group encourages the use of kubeadm in other installers to strengthen the Kubernetes ecosystem, with kubespray already adopting it.