This reverts commit 8597b343fa.
I wrote in the Kubernetes documentation:
In practice this means you need at least Linux 6.3, as tmpfs started
supporting idmap mounts in that version. This is usually needed as
several Kubernetes features use tmpfs (the service account token that is
mounted by default uses a tmpfs, Secrets use a tmpfs, etc.)
The check is wrong for several reasons:
* Pods can use userns before 6.3, they will just need to be
careful to not use a tmpfs (like a serviceaccount). MOST users
will probably need 6.3, but it is possible to use earlier kernel
versions. 5.19 probably works fine and with improvements in
the runtime 5.12 can probably be supported too.
* Several distros backport changes and the recommended way is
usually to try the syscall instead of testing kernel versions.
I expect support for simple fs like tmpfs will be backported
in several distros, but with this check it can generate confusion.
* Today a clear error is shown when the pod is created, so it's
unlikely a user will not understand why it fails.
* Returning an error if utilkernel fails to understand what
kernel version is running is also too strict (as we are
logging a warning even if it is not the expected version)
* We are switching to enabled by default, which will log a
warning on every user that runs on an older than 6.3 kernel,
adding noise to the logs.
For there reasons, let's just remove the hardcoded kernel version check.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
This reverts commit fd06dcd604.
The revert is not to make it a hard error again, this revert is needed
to revert cleanly the commit that added this as an error in the first
place.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
The conntrack reconciler maintains the consistency between the
conntrack table on each node and the desired state of Kubernetes UDP services.
A valid entry matches a service's ClusterIP, LoadBalancerIP, or ExternalIP and Service port,
or any ip matching a NodePort, and has a reverse source IP matching an active endpoint for
that service. Other entries are deleted.
Services without endpoints and traffic not handled by kube-proxy are ignored
Co-authored-by: Daman Arora <aroradaman@gmail.com>
Before, containers with the PostStart sleep lifecycle hook would cause
null pointer panics due to a typo in the field name being checked. This
commit fixes that.
The check also needs to be done on the oldPodSpec, rather than the
podSpec, so that existing workloads which use the zero value continue
functioning in the same way.
Added tests to check that if NodeRules, ClusterRoles, and NamespaceRoles
include `List`, it also include `Watch`.
Signed-off-by: Mitsuru Kariya <mitsuru.kariya@nttdata.com>
Starting from version 1.32, the client feature `WatchListClient` has been
set to `true` in `kube-controller-manager`.
(commit 06a15c5cf9)
As a result, when the `kube-controller-manager` executes the `List` method,
it utilizes `Watch`. However, there are some existing controller roles that
include `List` but do not include `Watch`. Therefore, when processes using
these controller roles execute the `List` method, `Watch` is executed first,
but due to permission errors, it falls back to `List`.
This PR adds `Watch` to the controller roles that include `List` but do not
include `Watch`.
The affected roles are as follows (prefixed with `system:controller:`):
- `cronjob-controller`
- `endpoint-controller`
- `endpointslice-controller`
- `endpointslicemirroring-controller`
- `horizontal-pod-autoscaler`
- `node-controller`
- `pod-garbage-collector`
- `storage-version-migrator-controller`
Signed-off-by: Mitsuru Kariya <mitsuru.kariya@nttdata.com>
