Automated cherry pick of #125398: [scheduler] When the hostname and nodename of a node do not match, ensure that pods carrying PVs with nodeAffinity are scheduled correctly.
Introducing pdb to preemption had disrupted the orderliness of pods in the victims,
which would leads picking wrong victim node with higher priority pod on it.
Automated cherry pick of #127650: kubeadm: fix a bug where the RemoveMember function did not return the correct member list when the member to be removed did not exist
Automated cherry pick of #127491: kubeadm: check whether the peer URL for the added etcd member already exists when the MemberAddAsLearner/MemberAdd fails
The endpoints controller store the resource version of the previous
Endpoints objects to avoid issues related to stale information on the
cache.
However, there can be update operations that succeed without increasing
the resource version, causing the endpoints controller to declare stale
the existing Resource Version and stopping the Endpoints to be updated.
Co-Author-By: Quan Tian <quan.tian@broadcom.com>
Co-Author-By: Yang Yang <yyyng@amazon.com>
With https://github.com/kubernetes/kubernetes/pull/122079,
kubeadm now relies on `ttlSecondsAfterFinished` to clean
up `upgrade-health-check` once its pod reaches a terminal state.
However, there is a case where the pod won't reach a terminal state and
the job will not register a terminal state, hence no garbage collection.
For example, if the pause image is not present, `ErrImagePull` will make
the pod keep retrying to pull the image and the pod will never reach a
terminal state on its own. And the job will continue to wait for the pod
to reach a terminal state which will not happen.
So we need to set `activeDeadlineSeconds` to prevent the job from
waiting forever for the pod to reach a terminal state.
Without this, users invoking `kubeadm upgrade plan` need to cleanup the
job outside of kubeadm even if they ignore the preflight result because
the job still runs when the result is configured to be ignored via
`--ignore-prelight-errors=CreateJob` flag.
Since the timeout for the polling in the `CreateJob` step in kubeadm
is 15 seconds, we should set the `activeDeadlineSeconds` to the same
timeout.
The main sync loop should have created and started the container in one
step. If the init container is in the 'created' state, it's likely that
the container runtime failed to start it. To prevent the container from
getting stuck in the 'created' state, restart it.
This fixes a regression in the SidecarContainers feature by minimizing
the impact of the new code path. Use the old code path for pods without
restartable init containers, and apply the new code path only to pods
with restartable init containers.
