We implemented a new KubeOneCluster API in v0.6.0 that replaced the old configuration API. As the new API introduces many breaking changes, you can not continue using old manifests as of v0.6.0. To continue using KubeOne, you have to migrate old manifests to new KubeOneCluster manifests.
The new API brings many possibilities and follows the Kubernetes API conventions. It allows us to improve the user experience and ensure we can provide the backwards compatibility policy.
To make migration to the new API easier, we implemented the
config migrate command that migrates
old configuration manifests to KubeOneCluster manifests.
This document shows how to use the
config migrate command and lists changes made in the new API.
Before you can use the
config migrate command you need to make sure that your manifests
are updated for KubeOne versions v0.4.0 or newer. If not, please see
the changelog to see what’s new and what
are required actions to migrate.
config migrate can automatically migrate your old manifests to new KubeOneCluster manifests.
The command takes path to the old configuration manifest and prints the converted manifest.
Once the manifest is migrated, it is validated against the new API to ensure that all fields are
correct and contain correct values.
kubeone config migrate config.yaml
config.yaml manifest that looks like the following one:
name: demo provider: name: aws hosts: - public_address: 126.96.36.199 private_address: 188.8.131.52 proxy: http_proxy: 184.108.40.206 https_proxy: 220.127.116.11 no_proxy: 18.104.22.168 features: pod_security_policy: enable: true
config migrate command will print manifest such as:
name: demo hosts: - publicAddress: 22.214.171.124 privateAddress: 126.96.36.199 proxy: http: 188.8.131.52 https: 184.108.40.206 noProxy: 220.127.116.11 features: podSecurityPolicy: enable: true apiVersion: kubeone.io/v1alpha1 kind: KubeOneCluster cloudProvider: name: aws
kind fields are not placed at the top automatically.
If you prefer, you can move them to the top manually.
The new API introduces many changes to ensure the API follows the Kubernetes API conventions and that we can provide as best as possible user experience.
The most important changes include:
kind fields must be added to the manifest. The
apiVersion tells KubeOne
what API version you are using. When we change the API in a backwards incompatible way, we introduce
a new API version along with an automatic migration path. That ensures you can continue using the
old API as long as it’s supported. To learn more for how long the old API versions are supported,
see the backwards compatibility policy.
apiVersion: kubeone.io/v1alpha1 kind: KubeOneCluster
The following changes are introduced at the root level:
apiserveris replaced with the
provideris renamed to
networkis renamed to
machine_controlleris renamed to
apiserver structure is replaced with the
apiEndpoint structure which contains the following fields:
host- address or hostname of the API endpoint (by default load balancer IP address or DNS),
port- port used to access the Kubernetes API (by default
All fields in the
hosts structure are renamed to use the camel case notation:
provider structure is renamed to
cloudProvider and the
cloud_config field is
cloudConfig (camel case notation).
network structure is renamed to
clusterNetwork. All fields are renamed to use the camel case
notation and a new field is added:
Fields in the
proxy structure are renamed:
All fields in the
features structure are renamed to use the camel case notation:
config field is renamed to
We’re now storing credentials for the
machine-controller and the external CCM at the root level,
credentials structure, instead of in
The following changes can affect using KubeOne as a Go library:
Featuresstructure are now pointers. All fields for enabling the feature are called
Enableand are type of
bool(previous pointer on
MachineControllerfield is now a pointer of
boolinstead of pointer on