Only create manifest files if they do not already exist

[rcythr]

FEATURE REQUEST

Currently the certs and kubeconfig phases will skip creation of files if they already exist, preserving user changes; however, control-plane and etcd phases always recreate the manifest files.

This creates problems for my workflow because I'm currently manually patching the generated manifests in order to fix the securityContext for selinux. I can skip the preflight check for these manifest files, but my files get replaced. I work around this currently with --skip-phases.

I feel this is unexpected behavior as it is inconsistent with the other phases. I propose that the control-plane and etcd phases have the same behavior as certs and kubeconfig phases with respect to treatment of existing files.

Versions

kubeadm version (use kubeadm version):

What happened?

When running kubeadm init phase control-plane or kubeadm init phase etcd local the manifest files are always regenerated.

What you expected to happen?

A log message would be printing whining about the files existence, but the existing files would not be replaced.

How to reproduce it (as minimally and precisely as possible)?

1. On a new machine
2. Place a valid manifest file in /etc/kubernetes/manifests/etcd.yaml or one of the other manifests.
3. Run kubeadm init phase control-plane or kubeadm init phase etcd local
4. Files have been recreated.

[rcythr]

This was a pretty quick change to make, I did it on my fork here (https://github.com/rcythr/kubernetes/compare/master...rcythr:dont_clobber_manifests)

If the maintainers like this change I'll open a PR for it.

[SataQiu]

/lifecycle active

[neolit123]

If the maintainers like this change I'll open a PR for it.

+1

[neolit123]

I work around this currently with --skip-phases.

just like to point out that calling the manifest/etcd phase, patching manifests and then calling init by skipping these phases is still a valid workflow. but the consistency of skipping already present files SGTM.

[fabriziopandini]

I'm not sure this is the right way to proceed, or at least I need to better understand how this will impact on upgrades (see comments on the PR)
Instead, IMO, we should proceed with #1379 for providing better support around user changes on manifests

[rcythr]

@fabriziopandini #1379 would be great! I agree it's a more strategic way to solve this problem.

Perhaps instead of preventing the recreation of manifests we should simply back them up? This would still be inconsistent with the other phases, but would be consistent with how the upgrade process handles the manifests.

[neolit123]

closing as the kustomize feature merged (alpha in 1.16)
kubernetes/enhancements#1159