sig-cl/kubeadm/1739: update KEP for support of patching kubelet config

[neolit123]

• One-line PR description:

  • Generalize the KEP to not only target static pods for the
    control plane
  • Add "kubeletconfiguration" target

• Issue link:
  kubeadm: customization with patches #1739

• Other comments:
  NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: neolit123

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/sig-cluster-lifecycle/OWNERS [neolit123]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[neolit123]

discussed here:
kubernetes/kubeadm#1682

related to:
kubernetes/kubernetes#109886

/cc @pacoxu
/hold for review

[pacoxu]

The update LGTM.
My only concern is about how to make a new user notice this option and there is a patch for some components.

• the documentation
• maybe we can add some tips in the configmap/static-pod annotation like "kubeadm.kubernetes.io/patched.component=kube-apiserver".
• some logs during kubeadm init/join/upgrade process.

[neolit123]

I guess the presence of a --patches flag or the option in config is the main indicator that components are being patched. And the user technically owns / maintains these flags and the config, so they must know what they are passing to kubeadm.

the documentation

I plan to update this page:
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/control-plane-flags/

maybe we can add some tips in the configmap annotation like "kubeadm.kubernetes.io/patched.component=kube-apiserver".

Today we do not annotate static pods whether they are modified from kubeadm defaults. There is this extra customization layer due to extraArgs, volumes and mounts that applies over the defaults. We assume the config file is the source of truth and users will be able to trace back changes to it. Patches are also a customization layer and we assume that new users should look at the node config and see there is a patches directory.

I think such an annotation is doable, but its not clear to me whether it's going to be a net positive addition for us and the users.

some logs during kubeadm init/join/upgrade process.

Yes, logs already print that a patch folder is being processed and what patches were found there.

[pacoxu]

/lgtm

[neolit123]

i'm considering doing a POC PR first, before merging this update in case we see something has to be adjusted.

EDIT: POC is here:
kubernetes/kubernetes#110405

[neolit123]

the implementation seems OK. we just patch before writing the kubelet config to disk.
merging this proposal as is, but we can revisit if needed.

/hold cancel