Kubermatic KubeOne

repository·main·Indexed 23 days ago

https://github.com/kubermatic/kubeone

An automation tool for deploying and managing highly available (HA) or single-master Kubernetes clusters across cloud providers, on-premise, edge, and IoT environments. KubeOne includes support for various Cloud Controller Managers (CCM) including AWS, Azure, GCP, DigitalOcean, Equinix Metal, Hetzner, Nutanix, OpenStack, and vSphere, as well as addons for Restic backups, Cluster Autoscaler, and CNI providers like Canal and Cilium.

Tokens
72.8K
Snippets
117
Records
516
Agent score
81%

What's inside KubeOne

  1. What is the Operating-system-manager addon?

    main

    The Operating-system-manager (OSM) addon is used to create and manage worker node configurations within a Kubernetes cluster. Its primary responsibility is managing the user-data for worker machines in the cluster.

    Migration Note: If you enable OSM on an existing cluster, existing worker machines will not be migrated automatically. To ensure machines consume configurations created by OSM, you must either:

    1. Manually update the MachineDeployments.
    2. Delete the existing machines to trigger replacement with OSM-managed configurations.
  2. Understand KubeOne API stability and lifecycle levels

    main

    KubeOne follows standard Kubernetes API lifecycle levels to communicate stability and support guarantees:

    LevelVersion PrefixDescriptionSupport/Deprecation Policy
    Alphav1alphaUnstable; not recommended for production. Can change or be dropped without notice.Can be deprecated at any time.
    Betav1betaPre-release; safe for operators. May contain bugs.Must be supported for at least 2 versions or 3 months (whichever is longer).
    Stablev1Stable and well-tested. Supported for many upcoming releases.Must be supported for at least 5 versions or 6 months (whichever is longer).
  3. Configure Addons in KubeOne

    main

    Addons allow you to extend your cluster with additional software. You can configure them via the Addons object by specifying a local directory path and a list of AddonRef entries.

    AddonRef

    An AddonRef can refer to either an internal KubeOne Addon or a HelmRelease.

    • addon: An internal KubeOne Addon configuration.
    • helmRelease: Configures Helm charts to reconcile. For each HelmRelease, KubeOne runs an operation equivalent to: helm upgrade --namespace <NAMESPACE> --install --create-namespace <RELEASE> <CHART> [--values=values-override.yaml]

    Addon Configuration

    Each Addon entry allows fine-grained control:

    • name (string, required): The name of the addon.
    • params (map[string]string): Parameters to be rendered using text/template. These override globalParams.
    • disableTemplating (bool): If true, disables templatization for the addon.
    • delete (bool): If true, ensures the named addon and all its contents are deleted.
  4. How the Cluster Autoscaler addon works

    main

    The Cluster Autoscaler addon automates the adjustment of your Kubernetes cluster size. It uses the Cluster-API provider to scale the number of replicas in a MachineDeployment object.

    Scaling Logic:

    • Scale Up: Triggered when pods fail to run due to insufficient resources.
    • Scale Down: Triggered when nodes are underutilized for an extended period (default is 10 minutes) and their pods can be rescheduled elsewhere.

    Key Distinction: Unlike traditional cloud Autoscaling Groups (ASGs), KubeOne uses the machine-controller to manage instances directly via Kubernetes objects. This allows you to manage, monitor, and perform rolling updates on worker nodes using standard kubectl or the Kubernetes API.

  5. Configure the CNI (Container Network Interface)

    main

    KubeOne supports multiple CNI providers. Only one CNI provider must be used at a time.

    Available providers in the cni configuration:

    • canal: Uses the Canal CNI plugin.
    • cilium: Uses the Cilium CNI plugin.
    • weaveNet: Uses the WeaveNet CNI plugin.
    • external: Uses an external CNI provider.
  6. CSI Driver deployment behavior for Kubernetes 1.23+

    main

    In v1.4.0-rc.1, KubeOne changes how CSI drivers are deployed based on the Kubernetes version:

    • For Kubernetes 1.23 or newer: KubeOne unconditionally deploys AWS, AzureDisk, AzureFile, and vSphere CSI drivers. This is because these providers have CSI migration enabled by default in Kubernetes 1.23.
    • For OpenStack: The CSI driver is unconditionally deployed because OpenStack has had CSI migration enabled by default since Kubernetes 1.18.
    • Other providers: DigitalOcean, Hetzner, Nutanix, and OpenStack Cinder CSI drivers are also unconditionally deployed.