Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kubeadm: Group centric component configs #85639

Merged
merged 1 commit into from Dec 4, 2019

Conversation

@rosti
Copy link
Member

rosti commented Nov 26, 2019

What type of PR is this?
/kind design

What this PR does / why we need it:

kubeadm's current implementation of component config support is "kind" centric.
This has its downsides. Namely:

  • Kind names and numbers can change between config versions.
    Newer kinds can be ignored. Therefore, detection of a version change is
    considerably harder.
  • A component config can have only one kind that is managed by kubeadm.

Thus a more appropriate way to identify component configs is required.

Probably the best solution identified so far is a config group.
A group name is unlikely to change between versions, while the kind names and
structure can.
Tracking component configs by group name allows us to:

  • Spot more easily config version changes and manage alternate versions.
  • Support more than one kind in a config group/version.
  • Abstract component configs by hiding their exact structure.

Hence, this change rips off the old kind based support for component configs
and replaces it with a group name based one. This also has the following
extra benefits:

  • More tests were added.
  • kubeadm now errors out if an unsupported version of a known component group
    is used.

Which issue(s) this PR fixes:

Refs:

Special notes for your reviewer:

This PR is part of the implementation of the new kubeadm component config management scheme KEP (see link below).

/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/priority important-soon
/assign @timothysc @fabriziopandini @neolit123 @ereslibre

Does this PR introduce a user-facing change?:

kubeadm now errors out whenever a not supported component config version is supplied for the kubelet and kube-proxy

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/kubeadm/20190925-component-configs.md
kubeadm's current implementation of component config support is "kind" centric.
This has its downsides. Namely:
- Kind names and numbers can change between config versions.
  Newer kinds can be ignored. Therefore, detection of a version change is
  considerably harder.
- A component config can have only one kind that is managed by kubeadm.
Thus a more appropriate way to identify component configs is required.

Probably the best solution identified so far is a config group.
A group name is unlikely to change between versions, while the kind names and
structure can.
Tracking component configs by group name allows us to:
- Spot more easily config version changes and manage alternate versions.
- Support more than one kind in a config group/version.
- Abstract component configs by hiding their exact structure.

Hence, this change rips off the old kind based support for component configs
and replaces it with a group name based one. This also has the following
extra benefits:
- More tests were added.
- kubeadm now errors out if an unsupported version of a known component group
  is used.

Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Nov 26, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rosti

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:

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

@rosti

This comment has been minimized.

Copy link
Member Author

rosti commented Nov 26, 2019

/hold
for discussion.

groups = append(groups, group)
}
sort.Strings(groups) // The sort is needed to make the output predictable
klog.Warningf("WARNING: kubeadm cannot validate component configs for API groups %v", groups)

This comment has been minimized.

Copy link
@neolit123

neolit123 Nov 26, 2019

Member

i think we saw this warning being printed in a lot of commands such as kubeadm config images.
should we change it to klog.V(...).Infof()?

This comment has been minimized.

Copy link
@rosti

rosti Nov 27, 2019

Author Member

I guess so. The code is executed whenever the config is loaded (which happens in almost all kubeadm commands). However it's good to see it as a warning only on kubeadm init/upgrade *.

@neolit123

This comment has been minimized.

Copy link
Member

neolit123 commented Nov 26, 2019

i'm +1 on this refactor. thanks @rosti

i envision the following split in the future:

  • kubelet, and control-plane component configs being managed by kubeadm in a similar way (as core components)
  • kube-proxy moving to addons.
@rosti

This comment has been minimized.

Copy link
Member Author

rosti commented Nov 27, 2019

i'm +1 on this refactor. thanks @rosti

i envision the following split in the future:

  • kubelet, and control-plane component configs being managed by kubeadm in a similar way (as core components)
  • kube-proxy moving to addons.

Exactly, that's my vision too.

@ereslibre

This comment has been minimized.

Copy link
Member

ereslibre commented Nov 27, 2019

On a first sight this SGTM. I plan to review this more thoroughly later today though.

Copy link
Member

ereslibre left a comment

LGTM, is a big chunk to review, but I'm +1 overall. A small comment for a tiny improvement.


// FromCluster loads a component from a config map in the cluster
func (h *handler) FromCluster(clientset clientset.Interface, clusterCfg *kubeadmapi.ClusterConfiguration) (kubeadmapi.ComponentConfig, error) {
return h.fromCluster(h, clientset, clusterCfg)

This comment has been minimized.

Copy link
@ereslibre

ereslibre Dec 2, 2019

Member

Can't we make fromCluster a handler method as well, so there's no need to pass h as argument?

This comment has been minimized.

Copy link
@ereslibre

ereslibre Dec 2, 2019

Member

I see why you did this on the non-public one... nevermind.

@ereslibre

This comment has been minimized.

Copy link
Member

ereslibre commented Dec 2, 2019

/lgtm
/hold
^ for other reviewers.

@k8s-ci-robot k8s-ci-robot added the lgtm label Dec 2, 2019
Copy link
Member

yastij left a comment

/lgtm

@neolit123

This comment has been minimized.

Copy link
Member

neolit123 commented Dec 3, 2019

/hold cancel
this PR received 3 +1s.

@k8s-ci-robot k8s-ci-robot merged commit 674695c into kubernetes:master Dec 4, 2019
15 checks passed
15 checks passed
cla/linuxfoundation rosti authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-dependencies Job succeeded.
Details
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-100-performance Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-kind Job succeeded.
Details
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce-big Job succeeded.
Details
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-node-e2e-containerd Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
tide In merge pool.
Details
@k8s-ci-robot k8s-ci-robot added this to the v1.18 milestone Dec 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.