Accessing svc.Spec.IPFamilies[0] without a bounds check panics when a
service reaches the controller with an empty IPFamilies field. This can
happen via watch events: the apiserver's defaultOnRead decorator populates
IPFamilies on GET/LIST but not on watch (cachingObject wrapping bypasses
the type assertion).
Restore the inference logic removed in #130101: fall back to ClusterIP
for headful services and pod IP for headless services.
Signed-off-by: Rahul <rahulbabu95@gmail.com>
On a remount (e.g. CSIDriver.spec.requiresRepublish=true), the volume is
already published and the pod is observing the existing bind mount.
Removing the mount dir on a NodePublish error left the pod with stale
contents that subsequent successful republishes could not repair.
Thread the reconciler's existing isRemount signal into MounterArgs so
volume plugins can distinguish an initial publish from a republish
(e.g. CSIDriver.spec.requiresRepublish=true). No behavior change.
Added podToVolumes reverse index to optimize DeletePod.
Currently we simply iterate through all the volumes and remove the pod
being deleted from there. This is inefficient and takes longer the
longer the volume list becomes.
Keeping a map pod -> volumes makes removing a pod fast. We can just jump
to the relevant volumes directly and remove the pod from there.
When calling ControllerSELinuxTranslator.Conflicts(), the SELinux label
is repeatedly split into []string to detect conflicts. This causes a huge
number of allocations when there are many comparisons.
This is now made more efficient by pre-parsing the SELinux label and
storing it in podInfo as [4]string for fast comparison when needed.
When collecting all matching devices for AllocationModeAll, the allocator did not record the source pool on the candidate device. Devices with consumed counters use that pool when checking shared counter availability, which caused kube-scheduler to panic.
Set the pool on all-devices candidates in the stable, incubating, and experimental allocators, and add a shared regression test for AllocationModeAll with consumed counters.
Automated cherry pick of #131950: PodStartSLIDuration should exclude init container runtime, image pulling time, stateful pods, not immediately schedulable pods
FetchInitConfigurationFromCluster always called SetAPIEndpointDynamicDefaults,
which invokes ChooseAPIServerBindAddress and requires a default route on the
host. Worker nodes joining the cluster don't need a LocalAPIEndpoint and may
legitimately have no default route, causing kubeadm join to fail with:
```
unable to fetch the kubeadm-config ConfigMap: unable to select an IP from
default routes.
```
Add a skipAPIEndpoint parameter to SetInitDynamicDefaults and pass
`!getAPIEndpoint` from FetchInitConfigurationFromCluster, so the endpoint
defaulter is bypassed when the caller did not request the endpoint (worker
join, non-control-plane reset/certs/upgrade paths).
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
Historicaly the kubeadm clients have used the 'admin.conf'
and 'super-admin.conf' directly, which makes all API calls
go trough the CPE (control plane endpoint). This can create
problems for scenarios when the LB is provisioned only after
'init' starts the kube-apiserver.
Instead of using the '.conf' as they are, modify them
in memory to point to the LAE (localAPIEndpoint).
This was already done by the WaitControlPlaneClient for
the WaitControlPlane phase, which required it. This separate
client is no longer needed.
However, do use a unmodified kubeconfig to the init phase
bootstrap-token since this is the phase that creates
the cluster-info CM and for that we need the original CPE
server address.
Periodic full-syncs are just reconcile loops just in case somehow
the dataplane has drifted, however, they have an important cost on large
clusters.
We can avoid to perform full-sync if kube-proxy is in the "largecluster"
mode, we are already doing some optimization, so it is reasonable to
avoid the penalty of a full sync for a "just in case" operation.
Signed-off-by: Antonio Ojea <aojea@google.com>
handleSchedulingFailure can refresh podInfo from the informer before AddUnschedulableIfNotPresent. A delete and recreate with the same name may change the Pod UID while inFlightPods still tracks the UID from Pop, so Done and queueing-hint lookups must use that in-flight UID.
Add an explicit in-flight UID parameter, thread it through queueing-hint lookups, cover the same-name recreation case with a regression test, and check the returned error in updated test call sites.
