feat: Add serializeImagePulls kubelet config parameter

[nandorKollar]

Fixes #

Description

Enable parallel image pulls by allowing to modify serializeImagePulls (or in our case --serialize-image-pulls flag) config parameter. The default value is unchanged, which means that by default image pulls are serial, but this PR allows to change it via config at least for an AKS node class. This partially addresses #1260 , although image pulls are still serial, but there's a way to change it for a given AKS node class.

How was this change tested?

Ran make test, and created a cluster and verified that I can change this config on the node class.

Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: #
• No

Release Note

Add serializeImagePulls option kubelet config parameter. If not explicitly set, then default value is true, hence image pulls are serial (this matches with current kubelet default value).

[Homulvas]

Should this default to true instead? Since k8s 1.31 Parallel image pulls should be the default in AKS. This is currently not the case if NAP is used https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/availability-performance/container-image-pull-performance#serialized-and-parallel-image-pulls

[nandorKollar]

Should this default to true instead? Since k8s 1.31 Parallel image pulls should be the default in AKS. This is currently not the case if NAP is used https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/availability-performance/container-image-pull-performance#serialized-and-parallel-image-pulls

I personally don't mind setting the default to true, probably makes more sense (as AFAIK AKS is also puling images in parallel). @tallaxes what's your opinion? Would it make sense to expose this Kubelet parameter in AKSNodeClass? Should the default be aligned with AKS default: parallel image pulls?

[tallaxes]

Ideally this would match defaulting logic in AKS - which means it won't have CRD-level default (unless we make it an enum with additional value of "auto").

On NAP side, lack of proper defaulting is a bug that we are looking into. Would fixing NAP help, or is there an important use case for making this work on self-hosted?

[nandorKollar]

Ideally this would match defaulting logic in AKS - which means it won't have CRD-level default (unless we make it an enum with additional value of "auto").

On NAP side, lack of proper defaulting is a bug that we are looking into. Would fixing NAP help, or is there an important use case for making this work on self-hosted?

I'm also fine with defaulting this kubelet config to parallel image pulls, and offering no CRD level option to change it. Is NAP different regarding configs and features like this? I expected that most of the configs and features are supposed to be the same in both NAP and self-hosted version, or at least there're just minimal difference between the supported features and config options.

[tallaxes]

Is NAP different regarding configs and features like this? I expected that most of the configs and features are supposed to be the same in both NAP and self-hosted version, or at least there're just minimal difference between the supported features and config options.

We are making an effort to keep differences to a minimum, but with NAP delegating some of the node bootstrapping configuration (currently CSE) to AKS, there are more ways to lean into existing defaulting or configuration logic, without having to bring it over into Karpenter provider codebase. In the future, self-hosted may be able to benefit from the same mechanisms, but for now we need to manage these differences explicitly.