This page covers how to customize the components that kubeadm deploys. For control plane components you can use flags in the ClusterConfiguration
structure or patches per-node. For the kubelet and kube-proxy you can use KubeletConfiguration
and KubeProxyConfiguration
, accordingly.
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.
kube-system/coredns
ConfigMap 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 Using init phases with kubeadm. Kubernetes v1.12 [stable]
ClusterConfiguration
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
etcd
These structures contain a common extraArgs
field, that consists of key: value
pairs. To override a flag for a control plane component:
extraArgs
to your configuration.extraArgs
field.kubeadm init
with --config <YOUR CONFIG YAML>
.ClusterConfiguration
object with default values by running kubeadm config print init-defaults
and saving the output to a file of your choice. 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. --foo
multiple times, is currently not supported. To workaround that you must use patches. For details, see the reference documentation for kube-apiserver.
Example usage:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
extraArgs:
anonymous-auth: "false"
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
For details, see the reference documentation for kube-controller-manager.
Example usage:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
deployment-controller-sync-period: "50"
For details, see the reference documentation for kube-scheduler.
Example usage:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
extraArgs:
config: /etc/kubernetes/scheduler-config.yaml
extraVolumes:
- name: schedulerconfig
hostPath: /home/johndoe/schedconfig.yaml
mountPath: /etc/kubernetes/scheduler-config.yaml
readOnly: true
pathType: "File"
For details, see the etcd server documentation.
Example usage:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
local:
extraArgs:
election-timeout: 1000
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>
:
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
patches:
directory: /home/user/somedir
kubeadm init
you can pass a file containing both a ClusterConfiguration
and InitConfiguration
separated by ---
. You can pass this file to kubeadm join
with --config <YOUR CONFIG YAML>
:
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
patches:
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 etcd
.patchtype
can be one of strategic
, merge
or json
and these must match the patching formats supported by kubectl. The default patchtype
is strategic
.extension
must be either json
or yaml
.suffix
is an optional string that can be used to determine which patches are applied first alpha-numerically.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
.
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 kubelet reference documentation 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 API reference pages.
KubeProxyConfiguration
would apply to all instances of kube-proxy in the cluster.
© 2022 The Kubernetes Authors
Documentation Distributed under CC BY 4.0.
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/control-plane-flags/