This commit defines the ClusterTrustBundlePEM projected volume types.
These types have been renamed from the KEP (PEMTrustAnchors) in order to
leave open the possibility of a similar projection drawing from a
yet-to-exist namespaced-scoped TrustBundle object, which came up during
KEP discussion.
* Add the projection field to internal and v1 APIs.
* Add validation to ensure that usages of the project must specify a
name and path.
* Add TODO covering admission control to forbid mirror pods from using
the projection.
Part of KEP-3257.
The logging instrumentation for contextual logging that was added for 1.29
slowed down the scheduler (i.e. logging verbosity <= 3) by a significant
percentage (-28.66% for SchedulingBasic/5000Nodes at -v3) if (and only if!)
contextual logging was enabled.
Retrieving the logger from the context causes no measurable slowdown, it's only
the various WithName/WithValues calls which cause this.
By being more careful about when to use those, the performance impact can be
avoided:
- At -v3 or lower, only `WithValues("pod")` is used once per scheduling cycle.
This has the intended effect that all log messages for the cycle include the
pod information. Once contextual logging is GA, "pod" key/value pairs can
be removed from all log calls.
- At -v4 or higher, richer log entries get produced where `WithValues` is also
used for the node (when applicable) and `WithName` is used for the current
operation and plugin.
With these changes, enabling contextual logging causes no measurable slowdown
at -v3 or lower. At -v4, the slowdown depends on the test case (-30.51%
throughput for SchedulingBasic/5000Nodes, no change for
SchedulingCSIPVs/5000Nodes). For some unknown reason (measuring bias?),
SchedulingCSIPVs/500Nodes has a ~3& *higher* throughput with contextual
logging.
I am having difficulties convincing myself if this is better or worse.
I didn't implement this originally because I didn't want to store nodes that
we weren't sure we've configured. However: if EnsureLoadBalancer fails we
should retry the call from the service controller. Doing it like this might
save us one update call from the node controller side for calls which have
already started executing from the service controller's side...is this really
that expensive at this point though? Is it really that dangerous to not do
either, given that we retry failed calls? Ahhhhh!!! Opinions, please! Help, please!
kube-dns as an alternative DNS addon to CoreDNS hasn't been supported
since 1.22 when kubeadm's v1beta3 API was added.
Remove the related tests from the e2e_kubeadm test framework.
Add Azure to the list of providers that support accessing nodes
using SSH.
Note: This will require a follow up PR adding the required
environment variables, AZURE_SSH_KEY, KUBE_SSH_BASTION to the test
configuration.
Add a test that checks if the CRB (kubeadm:cluster-admins)
used for binding admin.conf file users (part of the
kubeadm:cluster-admins Group) to the "cluster-admins"
ClusterRole exists in kubeadm clusters.
It does that only for versions newer than the version
when this feature was added.
not all rules that use OldSelf are transition rules, and this flag was used to check for oldSelf usage anyway, not specifically whether the rule was a transition rule
