The apiserver owns and manages the kubernetes.default service.
It has 3 different options to reconcile the endpoints that belong to
that service:
- None: endpoints are handled by an external party.
- MasterCount: legacy, it reconciles based on the endpoints generated
and a flag specifying the number of master on the cluster.
- Lease: default since 1.11, each apiserver writes a lease in etcd
and renews periodically, the endpoints are generated based on the
existing leases.
It seems that when the default was set for the lease reconciler, the
controlplane code wasn't updated and kept using the master count
reconciler.
This also starts the deprecation of the master count reconciler in
favor of the lease reconciler.
PR #107663 changed the startup logic to always call `SetupContainerd`
which will generate a new containerd `/etc/containerd/config.toml` file.
This is not always desired since some jobs install containerd from
source and the containerd startup scripts
(https://github.com/containerd/containerd/blob/main/contrib/gce/configure.sh)
are responsible for generating the `/etc/containerd/config.toml` file.
By always calling `SetupContainerd`, the containerd configuration by
containerd's `configure.sh` will be overridden which breaks certain test
jobs, see https://github.com/kubernetes/kubernetes/issues/107830.
To fix this issue, only call `SetupContainerd` if
`/etc/profile.d/containerd_env.sh` does not exist. When containerd
`configure.sh` script will run, `/etc/profile.d/containerd_env.sh` will
be written, and as a result the k8s setup scripts should avoid
overriding the containerd configuration.
Signed-off-by: David Porter <david@porter.me>
Before this fix, hint permutations such as:
permutation: [{11 true} {0101 true}]
Could result in merged hints of:
mergedHint: {01 true}
This was possible because both hints in the permutation container a "preferred"
allocation (i.e. the full set of NUMA nodes set in the affinity bitmask are
*required* to satisfy the allocation). With this in place, the simplified logic
we had simply kept the merged hint as preferred as well.
However, what we really want is to ensure that the merged hint is only
preferred if *true* alignment of all resources is possible (i.e. if all hints
in the permutation are preferred AND their affinities are exactly equal).
The only exception to this is if *no* topology information is provided by a
given hint provider. In this case, we assume alignment doesn't matter and only
consider the resources that actually have hints provided for them.
This changes the semantics of permutations of the form:
permutation: [{111 true} {011 true}]
To now result in the merged hint of:
mergedHint: {011 false}
Instead of:
mergedHint: {011 true}
This is arguably how it should always have been though (because a hint should
not be preferred if true alignment isn't possible), and two tests have had to
change to accomodate these new semantics.
This commit changes the merge function to implement the updated logic, adds a
test to verify it is functioning correctly, and updates the two tests mentioned
above to adjust to the new semantics.
Signed-off-by: Kevin Klues <kklues@nvidia.com>
* Remove linter warnings.
* Cancel contexts to avoid leaks.
* Rename a few XXXThreadUnsafe to XXXLocked to
maintain consistency.
* A few are still called XXXThreadUnsafe mainly
because those are safe to be called from the
perspective that only one gorotuine will access
them - not really called under a lock.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Previously, if a request is clusterscoped, the context that
was returned has no namespace, ideally the context should
contain a metav1.NamespaceNone as the namespace even for
cluster scoped requests.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
