Skip to content

Latest commit

 

History

History
114 lines (85 loc) · 5.53 KB

frequently_asked_questions.md

File metadata and controls

114 lines (85 loc) · 5.53 KB
Raw

Frequently Asked Questions

This document lists 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 or contact us on the mailing list or on the #kubeone channel on Kubernetes Slack.

What is KubeOne?

KubeOne is a CLI and a Go library for installing, maintaining and upgrading Kubernetes 1.13+ clusters.

What cloud providers KubeOne does support?

KubeOne is supposed to work on any cloud provider, on-prem and bare-metal cluster, as long as there is no need for additional configuration. However, to utilize all features of KubeOne, such as Terraform integration and creating worker nodes, KubeOne and Kubermatic machine-controller need to support that provider.

Currently we support AWS, DigitalOcean, Google Compute Engine (GCE), Hetzner, Packet, OpenStack, VMware vSphere and Azure.

Are on-prem and bare metal clusters supported?

Yes. We officially support VMware vSphere and OpenStack.

Does KubeOne handles the infrastructure and cloud resources?

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 that operators can use to create the needed infrastructure. Using the Terraform integration operator can source information about the infrastructure 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 resources can be used. There are many possible setups and supporting each of them in most of cases isn't possible. Operators are free to define infrastructure how they prefer and then use KubeOne to provision the cluster. We're open to feedback, so if you have any suggestion or idea ping us on the mailing list or on the #kubeone channel on Kubernetes Slack.

How KubeOne works?

KubeOne uses kubeadm to provision and upgrade Kubernetes control plane nodes. The worker nodes are provisioned and managed using the Kubermatic machine-controller. KubeOne takes care of installing Docker and all needed dependencies for Kubernetes and kubeadm. After the cluster is provisioned, KubeOne deploys the Canal CNI plugin and Kubermatic machine-controller.

How are commands executed on nodes?

All commands are executed over SSH. Because we don't take care of the infrastructure, it makes almost impossible to use cloud-config. Addons (Canal and machine-controller) are deployed using Go and the controller-runtime client library.

Can I deploy other CNI plugin then Canal?

This is currently not possible, however we're researching about switching to WeaveNet or providing option to choose the CNI plugin.

Can I deploy other controller than machine-controller or decide not to deploy and machine-controller?

You can opt out deploying machine-controller by setting machine_controller.Deploy to false. In that case you can't deploy worker nodes using KubeOne.

Can I use KubeOne to create Kubernetes clusters older than 1.13?

No. Due to breaking changes and the new features available only in kubeadm 1.13+, we decided to support only Kubernetes 1.13+ clusters.

Can I use KubeOne to upgrade Kubernetes 1.12 or older cluster to 1.13+?

No. Due to breaking changes in the upgrade process, we only support upgrading from Kubernetes 1.13 to newer.

How many versions can I upgrade at the same time?

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.

I'd like to contribute to KubeOne! Where can I start?

Please check our contributing guide.