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 .

    FEATURE STATE: Kubernetes v1.12 [stable]

    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 reference documentation for kube-apiserver.

    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 reference documentation for kube-scheduler.

    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 the control plane component manifests are 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. nodeRegistration:
    4.   patches:
    5.     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 .
    • patchtype can be one of strategic, merge or json and these must match the patching formats supported by kubectl. The default patchtype is strategic.
    • suffix is an optional string that can be used to determine which patches are applied first alpha-numerically.

    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 KubeletConfiguration next to the ClusterConfiguration or InitConfiguration separated by --- within the same configuration file. This file can then be passed to kubeadm init.

    Note: kubeadm applies the same KubeletConfiguration to all nodes in the cluster. To apply node specific settings 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 more 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 .

    Note: kubeadm deploys kube-proxy as a DaemonSet, which means that the KubeProxyConfiguration would apply to all instances of kube-proxy in the cluster.