During Kubernetes upgrades, skip pre-pulling the kube-proxy image on nodes where kube-proxy is disabled.
In the reported case, cluster.proxy.disabled: true is set, kube-proxy is not rendered or running, and Cilium is running in kube-proxy replacement mode. However, the Kubernetes upgrade flow still pre-pulls the configured cluster.proxy.image value on control-plane nodes because the image field remains populated in the generated machine config.
This appears to be an unnecessary upgrade pre-pull only — not kube-proxy being deployed or started. The desired behavior is for upgrade image pre-pull logic to check whether kube-proxy is disabled and skip the kube-proxy image when disabled, rather than relying only on whether cluster.proxy.image exists.
Impact: Low severity; avoids unnecessary bandwidth/storage usage and confusing upgrade output for users running kube-proxy replacement.
During Kubernetes upgrades, skip pre-pulling the kube-proxy image on nodes where kube-proxy is disabled.
In the reported case, cluster.proxy.disabled: true is set, kube-proxy is not rendered or running, and Cilium is running in kube-proxy replacement mode. However, the Kubernetes upgrade flow still pre-pulls the configured cluster.proxy.image value on control-plane nodes because the image field remains populated in the generated machine config.
This appears to be an unnecessary upgrade pre-pull only — not kube-proxy being deployed or started. The desired behavior is for upgrade image pre-pull logic to check whether kube-proxy is disabled and skip the kube-proxy image when disabled, rather than relying only on whether cluster.proxy.image exists.
Impact: Low severity; avoids unnecessary bandwidth/storage usage and confusing upgrade output for users running kube-proxy replacement.