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

Introduce controller aliases for KCM and CCM #115813

Merged
merged 9 commits into from
Jun 22, 2023

Conversation

atiratree
Copy link
Member

@atiratree atiratree commented Feb 15, 2023

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

There are many inconsistencies in the naming of KCM and CCM controllers. We would like to have consistent naming of controllers now when we switch to contextual logging . This is important for

  • more readable logging where each line has a familiar component prefix
  • makes names consistent across all controllers
  • the same name can be referenced when using CLI help / docs / in initiliazers

This PR introduces aliases for estabilished controllers like podgc. User has two options when specifying --controllers flag:

  • use the new name pod-garbage-collector-controller
  • use the old podgc name (alias) which will internally resolve to pod-garbage-collector-controller

a followup will look into modifying each controller to pick up the new names for:

  • integration with contextual logging where a logger will automatically obtain a component prefix for its component
  • logging should use a canonical controller name when referencing a controller (Eg. Starting X, Shutting down X)
  • this also can be done for running_managed_controllers metric (ControllerStarted, ControllerStopped)
  • logging of WaitForNamedCacheSync
  • controller events

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

for more details please see this discussion: https://groups.google.com/a/kubernetes.io/g/dev/c/I9l8SSM599s/m/PtzEMIS8BAAJ

Does this PR introduce a user-facing change?

kube-controller-manager and cloud-controller-manager have changed the name of controllers that can be turned off/on that are passed to the `--controllers` flag (eg `pod-garbage-collector-controller` ). The old names (eg `podgc`) are also accepted and aliased to the new names 

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


@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. area/cloudprovider sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Feb 15, 2023
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/controllermanager.go Outdated Show resolved Hide resolved
cmd/kube-controller-manager/app/options/options.go Outdated Show resolved Hide resolved
@atiratree atiratree changed the title Controller aliases Introduce controller aliases for KCM and CCM Feb 15, 2023
@@ -3,6 +3,7 @@ rules:
allowedPrefixes:
- k8s.io/kubernetes/cmd/kube-controller-manager/app/options
- k8s.io/kubernetes/cmd/kube-controller-manager/app/config
- k8s.io/kubernetes/cmd/kube-controller-manager/app/names
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For nodeipam controller. Should be safe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cmd/kube-controller-manager/app/names/controller_names.go Outdated Show resolved Hide resolved

import cpnames "k8s.io/cloud-provider/app/names"

// canonical controller names
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this explain where these names are used (command-line invocations, events, contextual logging...?), and the policy around changing them (I think the policy will be "don't")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea, I have added a documentation for these names inside both of the names packages

// "node-controller" is the shared identity of all node controllers, including node, node lifecycle, and node ipam.
// See https://github.com/kubernetes/kubernetes/pull/72764#issuecomment-453300990 for more context.
InitContext: app.ControllerInitContext{
ClientName: "node-controller",
},
Constructor: nodeIpamController.StartNodeIpamControllerWrapper,
}
controllerAliases["nodeipam"] = kcmnames.NodeIpamControllerName
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a little strange to use the kcmnames.NodeIpamControllerName for the name but define the alias locally here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this in a way that the old name belonged to CCM when the aliases did not exist yet. Theoretically it could have been a different name from KCM.

  • due to import restrictions I am not defining it in CCMControllerAliases
  • all the nodeipam controller relevant bits are in CCM main package so it is in a relevant place

I suppose I could also import and use the KCMControllerAliases, if we don't want to have a lonely string around.

"k8s.io/cloud-provider/options"
"k8s.io/component-base/cli"
cliflag "k8s.io/component-base/cli/flag"
_ "k8s.io/component-base/metrics/prometheus/clientgo" // load all the prometheus client-go plugins
_ "k8s.io/component-base/metrics/prometheus/version" // for version metric registration
"k8s.io/klog/v2"
kcmnames "k8s.io/kubernetes/cmd/kube-controller-manager/app/names"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure we don't want references to k8s.io/kubernetes/cmd/kube-controller-manager from cloud-controller-manager... should the nodeipam name be in k8s.io/cloud-provider/app/names instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to have the controller name defined in the same place/module where the controller lives. And the nodeipam controller lives in KCM and is imported by CCM

nodeipamcontrolleroptions "k8s.io/kubernetes/cmd/kube-controller-manager/app/options"
nodeipamcontroller "k8s.io/kubernetes/pkg/controller/nodeipam"
nodeipamconfig "k8s.io/kubernetes/pkg/controller/nodeipam/config"

KCM imports CCM controllers/options/names as well. We prevent circular dependency by choosing the relevant packages for nodeipam controller and only importing them in the main package of CCM

- k8s.io/kubernetes/cmd/kube-controller-manager/app/options

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure if anyone uses CCM from K/K. It seems that it was some step in Cloud Provider Extraction/Migration that is not-used anymore.

@cheftako and @nckturner, do you know the exact context about this CCM implementation and if anyone uses it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No one (afaik) uses the cloud-controller-manager binary thats built from the cmd/cloud-controller-manager, but everyone uses the cloud-provider library in staging.

Copy link
Member Author

@atiratree atiratree Apr 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to deprecate or remove the support for the binary and the relevant code in parallel with this PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can propose it in a PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am proposing a deprecation in #117564 - more details in the PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So are we OK with this because it is going away?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some extra content: cmd/cloud-controller-manager previously stays as an example for new incoming cloud providers. Do we still plan to have a way to educate the incoming cloud provider if this is removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please correct me if I am wrong, but I do not see an issue with the imports as I mentioned in the earlier comment, even if the example CCM does not go away.

We can start with the deprecation and have some time to discuss where to move it before the removal. We can also keep the README in cmd/cloud-controller-manager and reference the new location after that.

// 1. use of shortcuts should be avoided
// 2. kubernetes resources should be written together without a dash ("-")
const (
ServiceAccountTokenControllerName = "serviceaccount-token-controller"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: is it stuttery to end every constant with Name when we're already in a package called names?

can we do anything in a unit test to enforce consistency on these names (all lowercase, - instead of _, end in -controller, etc)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for both

I have updated controllermanager_test to enforce the consistency via a regex. Should I also limit the length of the controller name as we do in DNS1123 validations? Not sure if that is useful.

}

func TestControllerNamesDeclaration(t *testing.T) {
declaredControllers := sets.New(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this set of all declared controller names live in the names package?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to keep one source of truth for this set, which would be KnownControllers. This is just to test that this source is well defined. I do not see a benefit of exposing additional set (source) in the names package at this moment.

@atiratree
Copy link
Member Author

attachdetach unit test failed which should not be affected by these changes
/test pull-kubernetes-unit

@sftim
Copy link
Contributor

sftim commented Feb 17, 2023

Ideally: add a list of old and new name mappings (adding these to a new page within https://k8s.io/docs/reference/)

@atiratree
Copy link
Member Author

I am not sure if it is necessary to advertise these mappings that much (as a new page). Can we rather enhance existing kube-controller-manager page and inject a note there mentioning the aliases behaviour with a link to 1.26 doc for the old names? (they can be found in the help for --controllers flag)

Nevertheless I can open a doc PR once this one gets resolved and continue the discussion there.

@sftim
Copy link
Contributor

sftim commented Feb 17, 2023

Editing the existing (auto generated) page means editing the generator code, which may not be simpler. Of course the help for --controllers gets copied there automatically.

@cici37
Copy link
Contributor

cici37 commented Feb 21, 2023

/triage accepted

1 similar comment
@cici37
Copy link
Contributor

cici37 commented Feb 23, 2023

/triage accepted

@k8s-ci-robot k8s-ci-robot added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Feb 23, 2023
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 13, 2023
@atiratree
Copy link
Member Author

manually rebased - needed to fix an error for the tests

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 15, 2023
@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 19, 2023
@atiratree
Copy link
Member Author

observed flake #114852
/test pull-kubernetes-unit

Copy link
Contributor

@soltysh soltysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 22, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 99586855218ffbf9bb158fb4805c2ea758c5cb68

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: atiratree, soltysh, thockin

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

@atiratree
Copy link
Member Author

I have opened a followup to this PR #120371 which tries to encapsulate the controllers as suggested by @thockin in #115813 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/cloudprovider cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/backlog Higher priority than priority/awaiting-more-evidence. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet