KEP-127: graduate to Beta for 1.30 #4439

giuseppe · 2024-01-25T08:44:59Z

Issue link: Support User Namespaces in pods #127

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

So it is rendered properly on github. Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

keps/sig-node/127-user-namespaces/kep.yaml

keps/prod-readiness/sig-node/127.yaml

thockin · 2024-01-31T00:54:47Z

FTR - Prs with no assignee often fall thru cracks. :(

rata · 2024-01-31T10:03:40Z

/assign @mrunalp @wojtek-t

@thockin thanks, let's see if this command works, then :)

haircommander · 2024-01-31T17:12:58Z

keps/sig-node/127-user-namespaces/README.md

+- Get review from VM container runtimes maintainers (not blocker, as VM runtimes should just ignore
+  the field, but nice to have)


@fidencio @littlejawa have you or anyone from kata community taken a look?

mrunalp · 2024-02-02T04:52:22Z

keps/sig-node/127-user-namespaces/README.md

+  - Detection: How can it be detected via metrics? Stated another way:
+    how can an operator troubleshoot without logging into a master or worker node?
+
+        In this case the Kubelet will fail to start with a clear error message.


Assuming this is through subuids binary don't we fallback to default range?

I think we should fallback to default ranges only if there is no kubelet user configured, or there is no getsubids binary present.

If the kubelet user is defined and we fail to read its configuration, an error should be reported.

mrunalp · 2024-02-02T04:53:55Z

keps/sig-node/127-user-namespaces/README.md

+If one API server is upgraded while others aren't, the pod will be accepted (if the apiserver is >=
+1.25). If it is scheduled to a node that the kubelet has the feature flag activated and the node
+meets the requirements to use user namespaces, then the pod will be created with the namespace. If
+it is scheduled to a node that has the feature disabled, it will be scheduled without the user


scheduled or created?

wojtek-t

@rata @giuseppe - please take a look at my comments from the PRR

wojtek-t · 2024-02-02T09:52:00Z

keps/sig-node/127-user-namespaces/README.md

- Should we allow any way for users to for "more" IDs mapped? If yes, how many more and how?
- Should we allow the user to ask for specific mappings?
- Get review from VM container runtimes maintainers
+- Gather and address feedback from the community


Should we resolve the remaining unresolved part in this KEP (being support for Windows and runtimes that don't support linux namespaces)?

Windows support was resolved several months ago. Windows maintainers commented that they don't want this feature in windows and it looked fine anyways from their point of view.

We will try to gather feedback from VM runtimes, yes

I'll try to update with the links later

"don't want this feature in windows"

Love it.

That SGTM - just please update the KEP to reflect it :)

wojtek-t · 2024-02-02T09:54:53Z

keps/sig-node/127-user-namespaces/README.md

@@ -678,7 +686,7 @@ well as the [existing list] of feature gates.
 -->

 - [x] Feature gate (also fill in values in `kep.yaml`)
-  - Feature gate name: UserNamespacesStatelessPodsSupport
+  - Feature gate name: UserNamespacesPodsSupport


Can't comment on unchanged lines, so commenting here:

Please fill-in Upgrade/Downgrade strategy

For version skew, can you please also refer to the case where kube-apiserver understands the new field (spec.hostUsers) and kubelet doesn't [and vice-versa]

"Old runtime and new kubelet" - the fact that we create the pod in host namespace is somewhat counter-intuitive - as an operator I would expect that if I turned on the FG it works and is not silently dropped. Can we at least emit some error / event / metric / sth - in that case?

"Are there any tests for feature enablement/disablement?"
Were those added? If not can you please prioritize and add sth like that explicitly as beta criteria?

The gate seems to actually be named "UserNamespacesSupport"

@wojtek-t for 1 and 2: https://github.com/kubernetes/enhancements/pull/4439/files#diff-a9ca9fbce1538447b92f03125ca2b8474e2d875071f1172d2afa0b1e8cadeabaL613-L633 What are you looking for from this section that isn't covered already?

Update/Downgrade is not filled in at all

For version skew I explicit wrote - please describe the case what happens if feature is enabled in kube-apiserver and not in kubelet and vice-versa.

Oh, that is one of the few section that doesn't have any comments, it is such a small text that I didn't see it! We will add it now, sorry!

wojtek-t · 2024-02-02T10:01:45Z

keps/sig-node/127-user-namespaces/README.md

@@ -753,6 +761,18 @@ This section must be completed when targeting beta to a release.

 ###### How can a rollout or rollback fail? Can it impact already running workloads?

+The rollout is just a feature flag on the kubelet and the kube-apiserver.
+
+If one API server is upgraded while others aren't, the pod will be accepted (if the apiserver is >=


I don't understand this sentence - it doesn't matter how many apiservers were upgraded, rather if the one I'm talking to now was, right?

Yes, sorry. This should be something like:

If one APIserver is upgraded while other's aren't and you are talking to a not upgraded APIServer...

wojtek-t · 2024-02-02T10:03:27Z

keps/sig-node/127-user-namespaces/README.md

+namespace.
+
+On a rollback, pods created while the feature was active (created with user namespaces) will have to
+be restarted to be re-created without user namespaces. Just a re-creation of the pod will do the


This is slightly misleading to me - what does "restarted" mean here?
If we recommend recreation, let's make that explicit and remove the reference to "restarting"

Good point!

wojtek-t · 2024-02-02T10:04:52Z

keps/sig-node/127-user-namespaces/README.md

+On Kubernetes side, the kubelet should start correctly.
+
+On the node runtime side, a pod created with pod.spec.HostUsers=false should be on RUNNING state if
+all node requirements are met.


I'm not a fan of this answer - if I'm managing 1000s of clusters, it's not something I can reasonably monitor. Can we rely on easier to monitor conditions - ideally some metrics?

We can add metrics to signal on the errors listed here in the KEP (in the section "What are other known failure modes?").

This can potentially cover a lot at the kubelet layer. But things like one of the the filesystems used by the pod doesn't support idmap mounts on the kernel running will not be possible to detect from the kubelet. The runtime will return a clear error on that case, that is shown to the user, but I don't think we can have a metric for that.

Does doing that sounds like a good plan for you?

I'm not convinced about this, though. All errors are returned to the user, so it's very visible if it fails. And having a proliferation of metrics can also harm, especially long-term. Do you think this is definitely a "yes, this metrics are useful" or do you have mixed feelings about it too?

Also, do you think this is needed for beta graduation or can be added while the feature is in beta and still disabled by default?

Sorry - let me clarify my concern as I think I wasn't clear enough.

For anything that returns a clear error to usage, we're good - I don't think we need anything else.

What I'm worried about is the fact of silently not fulfilling user intents.
If (as a I user) I'm requesting to run in user namespace (by setting the new podspec field) and my pod goes to RUNNING state, I expect it to be running in a user namespace. If it's running in a host namespace, it's a big problem and at the very least I would like to see that exposed in an easy to digest for the operator way (metric).

Okay, so forget those metrics, then :-)

If we do what we suggested here, that basically the pod with userns only will be created if the CRI runtime knows about userns (an error will be returned otherwise), will that do it?

wojtek-t · 2024-02-02T10:07:28Z

keps/sig-node/127-user-namespaces/README.md

@@ -803,6 +839,11 @@ logs or events for this purpose.

 ###### How can someone using this feature know that it is working for their instance?

+Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node
+that meets all the requirements.


How as an operator I can check if the node meets all the requirements?

I can add the link to the k8s doc if that helps: https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/#before-you-begin

wojtek-t · 2024-02-02T10:07:35Z

keps/sig-node/127-user-namespaces/README.md

+Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node
+that meets all the requirements.
+
+There are step-by-step examples in the Kubernetes documentation too.


I can add a link to this: https://kubernetes.io/docs/tasks/configure-pod-container/user-namespaces/

I didn't do it because links here can easily become stale over time.

keps/sig-node/127-user-namespaces/README.md

wojtek-t · 2024-02-02T10:12:34Z

keps/sig-node/127-user-namespaces/README.md

+    levels that could help debug the issue?
+    Not required until feature graduated to beta.
+
+        The error is returned on pod-creation, no need to search for logs.


Rather on an attempt to start the pod?

IIUC, Kubelet will get an error from the runtime and will propagate it to the pod, right?

Yes, exactly

Can you clarify in the text?

Oh, sorry. Added it now! Here and in the rest of the errors, that this is visible on the pod events.

wojtek-t · 2024-02-02T10:15:18Z

keps/sig-node/127-user-namespaces/README.md

+  - Testing: Are there any tests for failure mode? If not, describe why.
+
+        It is part of the system configuration.
+


This is great answer playbook entry - the best I've seen so far - thanks!

sftim · 2024-02-02T10:31:29Z

keps/sig-node/127-user-namespaces/README.md

@@ -803,6 +839,11 @@ logs or events for this purpose.

 ###### How can someone using this feature know that it is working for their instance?

+Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node


Suggested change

Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node

Check if any pod has the `.spec.ghstUsers` field set to false and is on RUNNING state on a node

sftim · 2024-02-02T10:32:03Z

keps/sig-node/127-user-namespaces/README.md

+  - Condition name:
+  - Other field:
+- [x] Other (treat as last resort)
+  - Details: check pods with pod.spec.HostUsers field set to false, and see if they are in RUNNING


Suggested change

- Details: check pods with pod.spec.HostUsers field set to false, and see if they are in RUNNING

- Details: check pods with `.spec.hostUsers` field set to false, and see if they are in RUNNING

sftim · 2024-02-02T10:33:24Z

keps/sig-node/127-user-namespaces/README.md

+  - Detection: How can it be detected via metrics? Stated another way:
+    how can an operator troubleshoot without logging into a master or worker node?
+
+        In this case the Kubelet will fail to start with a clear error message.


(nit)

Suggested change

In this case the Kubelet will fail to start with a clear error message.

In this case the kubelet will fail to start with a clear error message.

sftim · 2024-02-02T10:33:58Z

keps/sig-node/127-user-namespaces/README.md

+pod had to be unique for every pod in the cluster, easily reaching a limit when the cluster is "big
+enough" and the UID space runs out.  However, with idmap mounts the IDs assigned to a pod just needs
+to be unique within the node (and with 64k ranges we have 64k pods possible in the node, so not
+really an issue). IOW, by using idmap mounts, we changed the IDs limit to be node-scoped instead of


(nit)

Suggested change

really an issue). IOW, by using idmap mounts, we changed the IDs limit to be node-scoped instead of

really an issue). In other words: by using idmap mounts, we changed the IDs limit to be node-scoped instead of

sftim · 2024-02-02T10:36:21Z

keps/sig-node/127-user-namespaces/README.md

+There are no known use cases for longer mappings that we know of. The 16bit range (0-65535) is what
+is assumed by all POSIX tools that we are aware of. If the need arises, longer mapping can be
+considered in a future KEP.


no known use cases?

Two examples come to mind:

running a container tool inside a Pod, where that container tool wants to use a UID range

running an application inside a Pod where the application uses UIDs above 65535 by default; I've worked with some of these, usually avoiding the 0-65535 range to avoid the risk of conflict with a local system user.

The first example doesn't necessarily need bigger mappings.

We didn't hear of any such application that wasn't possible to configure it. The point stands: that is out of scope for this KEP, it can be worked on in a future KEP.

sftim · 2024-02-02T10:37:21Z

keps/sig-node/127-user-namespaces/README.md

+
+There are no known use cases for longer mappings that we know of. The 16bit range (0-65535) is what
+is assumed by all POSIX tools that we are aware of. If the need arises, longer mapping can be
+considered in a future KEP.

 ### Allow runtimes to pick the mapping?


(nit)

Suggested change

### Allow runtimes to pick the mapping?

### Allow runtimes to pick the mapping

Alternatives aren't questions, they're things we have ruled out and can provide a reason for that exclusion.

sftim · 2024-02-02T10:37:41Z

keps/sig-node/127-user-namespaces/README.md

@@ -1149,15 +1358,23 @@ KEPs can explore this path if they so want to.

 ### 64k mappings?


We should frame this as an alternative that we have ruled out.

rata · 2024-02-02T13:14:45Z

@wojtek-t thanks for the detailed review! I'm on my train to FOSDEM now, so I'm not sure I'll be able to answer all now

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

rata · 2024-02-07T15:13:46Z

@wojtek-t PTAL, updated the KEP

keps/sig-node/127-user-namespaces/README.md

wojtek-t · 2024-02-07T20:25:38Z

keps/sig-node/127-user-namespaces/README.md

+will be accepted (if the apiserver is >= 1.25). If it is scheduled to a node that the kubelet has
+the feature flag activated and the node meets the requirements to use user namespaces, then the
+pod will be created with the namespace. If it is scheduled to a node that has the feature disabled,
+it will be created without the user namespace.


I hope it's no longer true after our discussion - the pod should fail to start in the second case, right?

@wojtek-t No, this is still true. If the feature is disabled in the kubelet, the kubelet completely ignores that field. The pod will only fail if the kubelet has the feature activated and the container runtime doesn't support it.

I don't think the kubelet can act on a field that should only act if the feature is enabled. We use this a lot on the error cases mentioned in detail in some other section, where you can just disable the feature gate to stop any bleeding that there might be related to this.

wojtek-t · 2024-02-07T20:26:09Z

keps/sig-node/127-user-namespaces/README.md

@@ -753,6 +815,17 @@ This section must be completed when targeting beta to a release.

 ###### How can a rollout or rollback fail? Can it impact already running workloads?

+The rollout is just a feature flag on the kubelet and the kube-apiserver.
+
+If one APIserver is upgraded while other's aren't and you are talking to a not upgraded the pod


I would remove this first sentence - I don't think it matters really and it doesn't bring value.

Okay. Sorry, I thought it would help as context, as there are lot of keps that added a field already and we all rely on existing plumbing to handle this correctly. But removed :)

wojtek-t · 2024-02-07T20:26:46Z

keps/sig-node/127-user-namespaces/README.md

+it will be created without the user namespace.
+
+On a rollback, pods created while the feature was active (created with user namespaces) will have to
+be re-created without user namespaces.


... If those weren't recreated, they will continue to run in user namespace.

Added, thanks!

wojtek-t · 2024-02-07T20:28:44Z

keps/sig-node/127-user-namespaces/README.md

+
+On the node runtime side, a pod created with pod.spec.hostUsers=false should be on RUNNING state if
+all node requirements are met. If the CRI runtime or the handler do not support the feature, the kubelet
+returns an error.


This puts the pod into Failed state, right?

So the number of Failed pods is effectively what we can look at, right?

[Not a native metric, but something measurable]

I've added the following to clarify.

When a pod hits this error returned by the kubelet, the status in kubectl is shown as
ContainerCreating and the pod events shows:

Warning FailedCreatePodSandBox 12s (x23 over 5m6s) kubelet Failed to create pod sandbox: user namespaces is not supported by the runtime

The following kubelet metrics are useful to check:

kubelet_running_pods: Shows the actual number of pods running

kubelet_desired_pods: The number of pods the kubelet is trying to run

If these metrics are very different, it means there are desired pods that can't be set to running.
If that is the case, checking the pod events to see if they are failing for user namespaces reasons
(like the errors shown in this KEP) is advised, in which case it is recommended to rollback or
disable the feature gate.

wojtek-t · 2024-02-07T20:30:45Z

keps/sig-node/127-user-namespaces/README.md

@@ -803,6 +899,10 @@ logs or events for this purpose.

 ###### How can someone using this feature know that it is working for their instance?

+If the runtime doesn't support user namespaces an error is returned by the kubelet.


So the pod will effectively transition to Failed state, right?

Yes, there is a FailedCreatePodSandBox event. kubectl is shown as
ContainerCreating and the pod events shows:

Warning FailedCreatePodSandBox 12s (x23 over 5m6s) kubelet Failed to create pod sandbox: user namespaces is not supported by the runtime

keps/sig-node/127-user-namespaces/README.md

wojtek-t · 2024-02-07T20:31:27Z

keps/sig-node/127-user-namespaces/README.md

+    levels that could help debug the issue?
+    Not required until feature graduated to beta.
+
+        The error is returned on pod-creation, no need to search for logs.


Can you clarify in the text?

AkihiroSuda · 2024-02-08T08:44:47Z

keps/sig-node/127-user-namespaces/README.md

@@ -579,14 +628,11 @@ use container runtime versions that have the needed changes.

 ##### Beta


I think critest should be updated during Beta:

critest should cover UserNamespace kubernetes-sigs/cri-tools#1348

Added, thanks!

rata · 2024-02-08T15:23:01Z

@wojtek-t Fixed the latest review commets. PTAL! I've added it as a separate commit, so you can easily see the diff

Co-authored-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

wojtek-t · 2024-02-08T16:43:53Z

keps/sig-node/127-user-namespaces/README.md

+pod.spec.hostUsers and has the feature gate enabled.
+
+If the kube-apiserver doesn't support the feature at all (< 1.25), a pod with userns will be
+rejected.


This is not true - kube-apiserver is not rejecting the pod, but rather is silently dropping this field.

Also - this isn't only about the release <1.25, but rather also when the feature gate is disabled.

No, it is rejecting the pod. This is what happens when a field is known, for example:

$ kubectl apply -f mypod2.yaml Error from server (BadRequest): error when creating "mypod2.yaml": Pod in version "v1" cannot be handled as a Pod: strict decoding error: unknown field "spec.nonExistingField"

I added the pod.spec.nonExistingField: true to the pod.

Am I missing something? Or are we talking about different things?

Regarding the feature gate disabled, that is mentioned a few lines above: 3766329#diff-a9ca9fbce1538447b92f03125ca2b8474e2d875071f1172d2afa0b1e8cadeabaR684-R686

This is strange - the whole point of having the dropDisabledFields pattern is to handle and drop the field if the FG is disabled.
@liggitt - can you please shed some light on it?

For context, this is the apiserver as started with the local-up-cluster.sh

kubectl opts into strict mode, where unknown fields are flagged / rejected. kubectl apply ... --validate=false shows what normal API clients (like controllers) would experience, where unknown fields are just dropped.

emulating the behavior where unknown fields are dropped on create when a feature is disabled is the standard approach taken.

rarely, for a security-related feature, we will reject attempts to use the new security-related field if the feature is disabled rather than dropping the field. The only one I can remember off the top of my head was the windows hostProcess field

@liggitt does that mean that, then, this is handled as expected by the apiserver? We aren't doing anything special in the apiserver for this field (pod.spec.hostUsers) on the apiserver.

do we even need this sentence? 1.25 has been out of support for a while, and we'd also not support a 1.30->1.25 skew between kubelet and KAS

We aren't doing anything special in the apiserver for this field (pod.spec.hostUsers) on the apiserver.

Once you add the field, you need to start doing things with it in the apiserver when the feature is disabled (either drop the field data or reject the request)

Updated to specify the kube-apiserver will drop the field if it's unknown

how does it look @liggitt @wojtek-t

wojtek-t · 2024-02-08T16:44:17Z

keps/sig-node/127-user-namespaces/README.md

+If the kube-apiserver doesn't support the feature at all (< 1.25), a pod with userns will be
+rejected.
+
+If the kubelet doesn't support the feature (< 1.25), it will ignore the pod.spec.hostUsers field.


If Kubelet is on old version not knowing the field - this is fine.

I'm more interested what happens if Kubelet is new enough and understands this field (say even 1.30), but it has feature gate disabled?
Will it ignore the field completely? [this isn't expected]
Or rather, will it reject the pod because it can't fulfill it? - which is what I would expect.

We should reject the pod in that case.

The current proposal is that it will ignore it completely. So feature disabled and an old kubelet that doesn't even know about this field, behave the same way.

We can change it to reject the pod in that case too (it is trivial). I proposed it this way, so by disabling the feature gate you can really stop any bleeding related to user namespaces. It seems more risky in case there is some bug, IMHO.

We can change it to that if you prefer, of course. As I said, it is trivial to do that too.

I believe that we should reject (as I wrote above).

Perfect, changed the text to do that instead. Thanks! :)

wojtek-t · 2024-02-08T16:47:54Z

keps/sig-node/127-user-namespaces/README.md

+If it is scheduled to a node where the kubelet has the feature flag activated
+and the node meets the requirements to use user namespaces, then the pod will be
+created with the namespace. If it is scheduled to a node that has the feature
+disabled, it will be created without the user namespace.


Same comment as for version skew.

Fixed to that!

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Peter Hunt <pehunt@redhat.com>

wojtek-t · 2024-02-08T19:12:08Z

OK - with the recent changes, I'm fine with it from PRR pov.

/lgtm
/approve PRR

k8s-ci-robot · 2024-02-08T19:12:19Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: giuseppe, mrunalp, wojtek-t

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/prod-readiness/OWNERS~~ [wojtek-t]
~~keps/sig-node/OWNERS~~ [mrunalp]

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

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jan 25, 2024

k8s-ci-robot requested review from jeremyrickard and palnabarun January 25, 2024 08:45

k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/node Categorizes an issue or PR as relevant to SIG Node. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 25, 2024

giuseppe mentioned this pull request Jan 25, 2024

Support User Namespaces in pods #127

Open

26 tasks

rata added 2 commits January 25, 2024 09:51

KEP-127: Add pod range configuration

1e4a0dd

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

KEP-127: Fix feature gate name

739f80b

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

giuseppe force-pushed the rata/userns branch from 0a9ec5c to 697925c Compare January 25, 2024 08:52

rata added 4 commits January 25, 2024 22:18

KEP-127: Update PRR for beta

be037de

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

KEP-127: Define beta migration criteria

7ccceb4

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

KEP-127: Make implementation history a list

a4fa617

So it is rendered properly on github. Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

KEP-127: Expand implementation history

3cb883c

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

giuseppe force-pushed the rata/userns branch from 697925c to 5b870de Compare January 25, 2024 21:18

sftim reviewed Jan 26, 2024

View reviewed changes

keps/sig-node/127-user-namespaces/kep.yaml Outdated Show resolved Hide resolved

giuseppe force-pushed the rata/userns branch 2 times, most recently from 91377aa to d7e437c Compare January 26, 2024 14:46

rata reviewed Jan 27, 2024

View reviewed changes

keps/prod-readiness/sig-node/127.yaml Show resolved Hide resolved

thockin self-assigned this Jan 31, 2024

k8s-ci-robot assigned mrunalp and wojtek-t Jan 31, 2024

haircommander reviewed Jan 31, 2024

View reviewed changes

mrunalp reviewed Feb 2, 2024

View reviewed changes

wojtek-t reviewed Feb 2, 2024

View reviewed changes

sftim reviewed Feb 2, 2024

View reviewed changes

rata and others added 2 commits February 7, 2024 15:21

KEP-127: Update latest milestion to 1.30

41a25d5

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

kep-127: address some review comments

fc5ea6e

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>

giuseppe force-pushed the rata/userns branch from 2d8be39 to fc5ea6e Compare February 7, 2024 14:21

wojtek-t reviewed Feb 7, 2024

View reviewed changes

AkihiroSuda reviewed Feb 8, 2024

View reviewed changes

rata force-pushed the rata/userns branch from e3ffa7f to be418b6 Compare February 8, 2024 15:19

KEP-127: Address more review comments

3766329

Co-authored-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>

rata force-pushed the rata/userns branch from be418b6 to 3766329 Compare February 8, 2024 15:31

mrunalp approved these changes Feb 8, 2024

View reviewed changes

wojtek-t reviewed Feb 8, 2024

View reviewed changes

KEP-127: Note kube-apiserver will drop the field if unknown

b64d85b

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Signed-off-by: Peter Hunt <pehunt@redhat.com>

haircommander force-pushed the rata/userns branch from f688ef1 to b64d85b Compare February 8, 2024 18:32

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 8, 2024

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 8, 2024

k8s-ci-robot merged commit 07953da into kubernetes:master Feb 8, 2024
4 checks passed

k8s-ci-robot added this to the v1.30 milestone Feb 8, 2024

giuseppe mentioned this pull request Feb 9, 2024

KEP-127: require userns support from the CRI runtime before using it kubernetes/kubernetes#123216

Merged

rata mentioned this pull request Feb 17, 2024

cri: add user_namespace field to RuntimeHandlerFeatures kubernetes/kubernetes#123356

Merged

		- Get review from VM container runtimes maintainers (not blocker, as VM runtimes should just ignore
		the field, but nice to have)

		- Testing: Are there any tests for failure mode? If not, describe why.

		It is part of the system configuration.

		@@ -803,6 +839,11 @@ logs or events for this purpose.

		###### How can someone using this feature know that it is working for their instance?

		Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node

	Check if any pod has the pod.spec.HostUsers field set to false and is on RUNNING state on a node
	Check if any pod has the `.spec.ghstUsers` field set to false and is on RUNNING state on a node

	- Details: check pods with pod.spec.HostUsers field set to false, and see if they are in RUNNING
	- Details: check pods with `.spec.hostUsers` field set to false, and see if they are in RUNNING

	In this case the Kubelet will fail to start with a clear error message.
	In this case the kubelet will fail to start with a clear error message.

	really an issue). IOW, by using idmap mounts, we changed the IDs limit to be node-scoped instead of
	really an issue). In other words: by using idmap mounts, we changed the IDs limit to be node-scoped instead of

	### Allow runtimes to pick the mapping?
	### Allow runtimes to pick the mapping

		@@ -1149,15 +1358,23 @@ KEPs can explore this path if they so want to.

		### 64k mappings?

		@@ -803,6 +899,10 @@ logs or events for this purpose.

		###### How can someone using this feature know that it is working for their instance?

		If the runtime doesn't support user namespaces an error is returned by the kubelet.

		@@ -579,14 +628,11 @@ use container runtime versions that have the needed changes.

		##### Beta

KEP-127: graduate to Beta for 1.30 #4439

KEP-127: graduate to Beta for 1.30 #4439

Conversation

giuseppe commented Jan 25, 2024

thockin commented Jan 31, 2024

rata commented Jan 31, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wojtek-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rata commented Feb 2, 2024

rata commented Feb 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rata commented Feb 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rata Feb 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

liggitt Feb 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rata Feb 8, 2024 •

edited

Loading

liggitt Feb 8, 2024 •

edited

Loading