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.
39df946c06 was meant to enable stricter comment checking only for cmd/kubeadm
because the maintainers of that want that. However, the exclude rule didn't
capture all possible error texts and therefore some checks were enabled across
the entire code base.
The extended pattern is now based on the golangci-lint source code.
Also, the hint config didn't suppress any of these checks.
This commit does the following:
1. Add RuntimeClassInImageCriApi feature gate
2. Extend pkg/kubelet/container Image struct
3. Adds runtimeHandler string in the following CRI calls
i. ImageStatus
ii. PullImageRequest
iii. RemoveImage
Signed-off-by: kiashok <kiashok@microsoft.com>
And update most of the comments to refer to "nftables" rather than
"iptables" (even though it doesn't actually do any nftables updating
at this point).
For now the proxy also internally creates a
utiliptablestesting.FakeIPTables to keep the existing sync code
compiling.
(It is confusing, but allowed, to have distinct "KUBE-SERVICES" chains
in "nat" and "filter" in iptables, but in nftables the "type nat" and
"type filter" chains end up in the same table, so we'll need different
names for the two.)
Change the svcPortInfo and endpointInfo fields to string rather than
utiliptables.Chain, and various fixups from there.
Also use a proper set for activeNATChains, and fix the capitalization
of endpointInfo.chainName.
