Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Adds Support for Node Resource IPv6 Addressing
**What this PR does / why we need it**:
This PR adds support for the following:
1. A node resource to be assigned an IPv6 address.
2. Expands IPv4/v6 address validation checks.
**Which issue this PR fixes**:
Fixes Issue #44848 (in combination with PR #45116).
**Special notes for your reviewer**:
This PR is part of a larger effort, Issue #1443 to add IPv6 support to k8s.
**Release note**:
```
NONE
```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
hyperkube: add cloud-controller-manager
**What this PR does / why we need it**:
Adds `cloud-controller-manager` to `hyperkube`. (fix#55732)
This is useful as a number of deployment tools run all of the kubernetes components from the `hyperkube` image/binary. It also makes testing easier as a single binary/image can be built and pushed quickly.
This PR follows the same pattern of the other kubernetes binaries being available as part of `hyperkube`.
(This PR also makes an error condition appropriately fatal.)
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: n/a
**Special notes for your reviewer**: n/a
**Release note**:
```release-note
hyperkube: add cloud-controller-manager
```
/sig cluster-lifecycle
/area cloudprovider
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Introduce new `VolumeAttachment` API Object
**What this PR does / why we need it**:
Introduce a new `VolumeAttachment` API Object. This object will be used by the CSI volume plugin to enable external attachers (see design [here](https://github.com/kubernetes/community/pull/1258). In the future, existing volume plugins can be refactored to use this object as well.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: Part of issue https://github.com/kubernetes/features/issues/178
**Special notes for your reviewer**:
None
**Release note**:
```release-note
NONE
```
Move the namespace selector code to package webhook/namespace
Move the conversion related code to package to webhook/versioned
Move errors related code to package webhook/errors
Move admission review related code to package webhook/request
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fix cross-compliation of mount_exec.go
Added dummy implementation for non-linux platforms
Fixes: #55711
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fix prometheus-to-sd sidecar in metadata proxy
Ref https://github.com/kubernetes/kubernetes/issues/55695#issuecomment-344300188
This is making 2 changes:
- restoring resource requests and limits of the metadata-proxy sidecar as it was before, and remove them for prom-to-sd sidecar (best effort) like at everywhere else
- pass pod name and namespace args to prom-to-sd sidecar (because just noticed)
/cc @ihmccreery @loburm @crassirostris - Does this make sense?
Introduce the v1alpha1 version to the Kubernetes storage API. And add a
new VolumeAttachment object to that version. This object will initially
be used only by the new CSI Volume Plugin. Eventually existing volume
plugins can be refactored to use it too.
Moved client and kubeconfig related code to webhook/config;
Moved the rule matcher to webhook/rules;
Left TODOs saying we are going to move some other common utilities;
Other code is moved to webhook/validation.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Webhook e2e test: fail open and fail closed
**What this PR does / why we need it**:
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Ref: https://github.com/kubernetes/features/issues/492
**Special notes for your reviewer**: ~depends on #55127~ (merged)
@kubernetes/sig-api-machinery-api-reviews
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Use results of kube-controller-manager leader election in addon manager
**What this PR does / why we need it**:
This adds leader election-like mechanism to addon manager. Currently, in a multi-master setup, upgrading one master will trigger a fight between addon managers on different masters, each forcing its own versions of addons. This leads to pod unavailability until all masters are upgraded to new version.
To avoid implementing leader election in bash, results of leader election in kube-controller-manager are used. Long term, addon manager probably should be rewritten in a real prgramming language (probably Go), and then, real leader election should be implemented there.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
I don't think there was an issue for this specifically, but this PR is related to https://github.com/kubernetes/kubernetes/issues/473
**Special notes for your reviewer**:
**Release note**:
```release-note
Addon manager supports HA masters.
```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
dockershim: remove corrupt checkpoints immediately upon detection
Fixes https://github.com/kubernetes/kubernetes/issues/55620
The current checkpoint abstraction leaks the handling of corrupt checkpoints to the user.
If the user does a `GetCheckpoint()` and the checkpoint is corrupt, the corrupt checkpoint is returned to the user (why??) with an error indicating the corruption. It is then up to the user to detect the corruption via the error msg and call `RemoveCheckpoint()` to remove the corrupted checkpoint.
The checkpoint abstraction should not expose corruption to the user. If it is corrupt, it is as good as not found to the user. The checkpoint code should handle cleanup of corrupt entries and report "not found" to the user.
@derekwaynecarr @eparis @dcbw @freehan
Shyam Jeedigunta