Reconfiguring a kubeadm cluster [page]deterministic

kubeadm does not support automated ways of reconfiguring components that were deployed on managed nodes. One way of automating this would be by using a custom [operator](/docs/concepts/extend-kubernetes/operator/).

To modify the components configuration you must manually edit associated cluster objects and files on disk.

This guide shows the correct sequence of steps that need to be performed to achieve kubeadm cluster reconfiguration.

##

• You need a cluster that was deployed using kubeadm
• Have administrator credentials (`/etc/kubernetes/admin.conf`) and network connectivity to a running kube-apiserver in the cluster from a host that has kubectl installed
• Have a text editor installed on all hosts

## Reconfiguring the cluster

kubeadm writes a set of cluster wide component configuration options in ConfigMaps and other objects. These objects must be manually edited. The command `kubectl edit` can be used for that.

The `kubectl edit` command will open a text editor where you can edit and save the object directly.

You can use the environment variables `KUBECONFIG` and `KUBE_EDITOR` to specify the location of the kubectl consumed kubeconfig file and preferred text editor.

For example: ``` KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit <parameters> ```

> Note: Upon saving any changes to these cluster objects, components running on nodes may not be automatically updated. The steps below instruct you on how to perform that manually.

> Warning: Component configuration in ConfigMaps is stored as unstructured data (YAML string). This means that validation will not be performed upon updating the contents of a ConfigMap. You have to be careful to follow the documented API format for a particular component configuration and avoid introducing typos and YAML indentation mistakes.

### Applying cluster configuration changes

#### Updating the `ClusterConfiguration`

During cluster creation and upgrade, kubeadm writes its [`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta4/) in a ConfigMap called `kubeadm-config` in the `kube-system` namespace.

To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command:

```shell kubectl edit cm -n kube-system kubeadm-config ```

The configuration is located under the `data.ClusterConfiguration` key.

> Note: The `ClusterConfiguration` includes a variety of options that affect the configuration of individual components such as kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd and kube-proxy. Changes to the configuration must be reflected on node components manually.

#### Reflecting `ClusterConfiguration` changes on control plane nodes

kubeadm manages the control plane components as static Pod manifests located in the directory `/etc/kubernetes/manifests`. Any changes to the `ClusterConfiguration` under the `apiServer`, `controllerManager`, `scheduler` or `etcd` keys must be reflected in the associated files in the manifests directory on a control plane node.

Such changes may include: - `extraArgs` - requires updating the list of flags passed to a component container - `extraVolumes` - requires updating the volume mounts for a component container - `*SANs` - requires writing new certificates with updated Subject Alternative Names

Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`.

To write new certificates you can use: ```shell kubeadm init phase certs <component-name> --config <config-file> ```

To write new manifest files in `/etc/kubernetes/manifests` you can use:

```shell # For Kubernetes control plane components kubeadm init phase control-plane <component-name> --config <config-file> # For local etcd kubeadm init phase etcd local --config <config-file> ```

The `<config-file>` contents must match the updated `ClusterConfiguration`. The `<component-name>` value must be a name of a Kubernetes control plane c …(trimmed)