Customizing components with the kubeadm API

    All of these options are possible via the kubeadm configuration API. For more details on each field in the configuration you can navigate to our API reference pages.

    Note: Customizing the CoreDNS deployment of kubeadm is currently not supported. You must manually patch the kube-system/coredns and recreate the CoreDNS Pods after that. Alternatively, you can skip the default CoreDNS deployment and deploy your own variant. For more details on that see .

    Note: To reconfigure a cluster that has already been created see Reconfiguring a kubeadm cluster.

    The kubeadm ClusterConfiguration object exposes a way for users to override the default flags passed to control plane components such as the APIServer, ControllerManager, Scheduler and Etcd. The components are defined using the following structures:

    • apiServer
    • controllerManager
    • scheduler

    These structures contain a common extraArgs field, that consists of key: value pairs. To override a flag for a control plane component:

    1. Add the appropriate extraArgs to your configuration.
    2. Add flags to the extraArgs field.
    3. Run kubeadm init with --config <YOUR CONFIG YAML>.

    Note: You can generate a ClusterConfiguration object with default values by running kubeadm config print init-defaults and saving the output to a file of your choice.

    Note: The ClusterConfiguration object is currently global in kubeadm clusters. This means that any flags that you add, will apply to all instances of the same component on different nodes. To apply individual configuration per component on different nodes you can use patches.

    Note: Duplicate flags (keys), or passing the same flag --foo multiple times, is currently not supported. To workaround that you must use .

    For details, see the .

    For details, see the .

    Example usage:

    1. apiVersion: kubeadm.k8s.io/v1beta3
    2. kind: ClusterConfiguration
    3. kubernetesVersion: v1.16.0
    4. controllerManager:
    5.   extraArgs:
    6.     cluster-signing-key-file: /home/johndoe/keys/ca.key
    7.     deployment-controller-sync-period: "50"

    For details, see the .

    Example usage:

    For details, see the .

    Example usage:

    2. etcd:
    3.   local:
    4.     extraArgs:
    5.       election-timeout: 1000

    FEATURE STATE: Kubernetes v1.22 [beta]

    Kubeadm allows you to pass a directory with patch files to InitConfiguration and JoinConfiguration on individual nodes. These patches can be used as the last customization step before component configuration is written to disk.

    You can pass this file to kubeadm init with --config <YOUR CONFIG YAML>:

    You can pass this file to kubeadm join with --config <YOUR CONFIG YAML>:

    1. apiVersion: kubeadm.k8s.io/v1beta3
    2. kind: JoinConfiguration
    3. patches:
    4.   directory: /home/user/somedir

    The directory must contain files named target[suffix][+patchtype].extension. For example, kube-apiserver0+merge.yaml or just etcd.json.

    • target can be one of kube-apiserver, kube-controller-manager, kube-scheduler, and kubeletconfiguration.
    • patchtype can be one of strategic, merge or json and these must match the patching formats . The default patchtype is strategic.
    • extension must be either json or yaml.

    Note: If you are using kubeadm upgrade to upgrade your kubeadm nodes you must again provide the same patches, so that the customization is preserved after upgrade. To do that you can use the --patches flag, which must point to the same directory. kubeadm upgrade currently does not support a configuration API structure that can be used for the same purpose.

    To customize the kubelet you can add a next to the ClusterConfiguration or InitConfiguration separated by --- within the same configuration file. This file can then be passed to kubeadm init and kubeadm will apply the same base KubeletConfiguration to all nodes in the cluster.

    For applying instance-specific configuration over the base KubeletConfiguration you can use the kubeletconfiguration patch target.

    Alternatively, you can use kubelet flags as overrides by passing them in the nodeRegistration.kubeletExtraArgs field supported by both InitConfiguration and JoinConfiguration. Some kubelet flags are deprecated, so check their status in the before using them.

    For additional details see Configuring each kubelet in your cluster using kubeadm

    To customize kube-proxy you can pass a KubeProxyConfiguration next your ClusterConfiguration or InitConfiguration to kubeadm init separated by .

    For more details you can navigate to our API reference pages.