This document is supposed to answer some commonly asked questions about KubeOne,
what it does, and how it works. If you have any question not covered here,
please create a new GitHub issue, contact us on the
#kubeone channel on Kubernetes Slack or on our community forums.
Kubermatic KubeOne is a tool that automates cluster operations on all your cloud, on-prem, edge, and IoT environments.
KubeOne only supports versions supported by the upstream support policy. While older versions might work, we can’t guarantee that and we strongly advise that you use only officially supported versions.
KubeOne is supposed to work on any cloud provider, on-prem and bare-metal. However, to utilize all KubeOne features, such as Terraform integration and managing worker nodes using Kubermatic machine-controller and Cluster-API, the provider needs to be supported by KubeOne.
Currently we support AWS, DigitalOcean, Google Compute Engine (GCE), Hetzner, Packet, OpenStack, VMware vSphere and Azure.
Yes. We officially support VMware vSphere and OpenStack.
No, it’s up to the operator to setup the needed infrastructure and provide the needed parameters to KubeOne.
To make this task easier, we provide Terraform scripts and integration for all supported providers. The Terraform scripts can be used to create the needed infrastructure, and then using the Terraform integration, all needed parameters can be sourced directly from the Terraform output.
This decision was based on that fact that we didn’t want to limit operators how the infrastructure can be configured and what infrastructure providers can be used. There are many possible setups and officially supporting each setup isn’t possible in most of cases. Operators are free to define infrastructure how they prefer and then use KubeOne to provision the cluster.
KubeOne uses kubeadm to provision and upgrade the Kubernetes clusters. The worker nodes are managed by the Cluster-API and Kubermatic machine-controller. KubeOne also supports provisioning worker nodes using kubeadm, but the infrastructure for nodes needs to be created and managed by the operator.
KubeOne takes care of installing Docker and all needed dependencies for Kubernetes and kubeadm. After the cluster is provisioned, KubeOne deploys the CNI plugin, Kubermatic machine-controller, and other needed components.
You can opt out of deploying machine-controller by setting
Yes, KubeOne can provision and upgrade the worker nodes using kubeadm. The infrastructure (e.g. instances) needs to be managed by the operator.
We recommend using machine-controller to manage worker nodes, however, this can be useful in cases when machine-controller doesn’t support the provider, for example when using bare-metal.
All commands are executed over SSH. Because we don’t take care of the infrastructure, it’s impossible to use cloud-config. Components, such as CNI and machine-controller are deployed using the controller-runtime client library.
Check the following document to find out how KubeOne uses SSH and what are SSH requirements.
KubeOne can deploy Canal and WeaveNet CNI plugins out-of-box, with support
for allowing operators to deploy CNI plugin of their choice using the
external CNI option.
It is only possible to upgrade from one minor to the next minor version (n+1). For example, if you want to upgrade from Kubernetes 1.13 to Kubernetes 1.15, you’d need to upgrade to 1.14 and then to 1.15.
Please check our contributing guide.