KEP-2033: KubeletInUserNamespace: postpone beta to v1.36

[AkihiroSuda]

• One-line PR description: postpone beta to v1.36

• Issue link: sig-node: Kubelet-in-UserNS, aka Rootless mode #2033

• Other comments:
  KEP-2033: promote KubeletInUserNamespace feature to beta kubernetes#134639 was approved and got the lgtm label, however, it was not merged in v1.35.

[SergeyKanzhelev]

/lgtm
/approve

since it just missed a deadline a little, I suggest we go ahead with this KEP in 1.36

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: AkihiroSuda, SergeyKanzhelev
Once this PR has been reviewed and has the lgtm label, please assign mrunalp for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• keps/sig-node/OWNERS

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

[SergeyKanzhelev]

hm, actually, let's take this chance to review API.

/lgtm cancel

Please update the KEP to change the name of a field in NodeStatus the same way it changed in code PR. Let's take this chance to review API ahead of coding stage.

As per kubernetes/kubernetes#134639 (comment) adding @thockin here to help review the API.

/assign @thockin

[AkihiroSuda]

Please update the KEP to change the name of a field in NodeStatus the same way it changed in code PR.

Done

[SergeyKanzhelev]

Right now the KEP suggested this node status field to address the PRR questions (mostly) regarding transparency for end user.

I like the idea of a strongly typed field. However we may need to think and address the following:

1. Will users want to taint or select based on this information? If so, why not express it as a taint or label.
2. Is this field mutable or node must be re-created in a different state?
3. is boolean value enough long term? Do we envision more modes of operation to expose?

[AkihiroSuda]

1. Will users want to taint or select based on this information? If so, why not express it as a taint or label.

Yes, label seems to make a sense here.
e.g.,

kubernetes.io/running-in-user-namespace: "true"

2. Is this field mutable or node must be re-created in a different state?

Must be re-created.

3. is boolean value enough long term? Do we envision more modes of operation to expose?

Additional labels can be added on demand

[AkihiroSuda]

Updated the PR to use a label.

[AkihiroSuda]

@SergeyKanzhelev For consistency with os and arch labels, NodeSystemInfo.RunningInUserNamespace should be kept too, or just a label suffices?