Automatic merge from submit-queue (batch tested with PRs 43505, 45168, 46439, 46677, 46623)
fix AWS tagging to add missing tags only
It seems that intention of original code was to build map of missing
tags and call AWS API to add just them, but due to typo full
set of tags was always (re)added
```release-note
NONE
```
Automatic merge from submit-queue
unit test for kubectl config set-cluster
**What this PR does / why we need it**:
unit test for create cluster
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
i want test secure mode,but CA path how set?
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Performance tests also cover configmaps now
Similar to secrets.
We should be able to get this in once https://github.com/kubernetes/kubernetes/pull/46470 is merged.
/cc @wojtek-t @gmarek
Automatic merge from submit-queue (batch tested with PRs 46686, 45049, 46323, 45708, 46487)
[Federation][kubefed]: Use StorageClassName for etcd pvc
This PR updates kubefed to use the StorageClassName field [added in 1.6](http://blog.kubernetes.io/2017/03/dynamic-provisioning-and-storage-classes-kubernetes.html
) for etcd's pvc to allow the user to specify which storage class they want to use. If no value is provided to ``kubefed init``, the field will not be set, and initialization of the pvc may fail on a cluster without a default storage class configured.
The alpha annotation that was previously used (``volume.alpha.kubernetes.io/storage-class``) was deprecated as of 1.4 according to the following blog post:
http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html
**Release note**:
```
'kubefed init' has been updated to support specification of the storage class (via --etcd-pv-storage-class) for the Persistent Volume Claim (PVC) used for etcd storage. If --etcd-pv-storage-class is not specified, the default storage class configured for the cluster will be used.
```
cc: @kubernetes/sig-federation-pr-reviews
Automatic merge from submit-queue (batch tested with PRs 46686, 45049, 46323, 45708, 46487)
Log an EBS vol's instance when attaching fails because VolumeInUse
Messages now look something like this:
E0427 15:44:37.617134 16932 attacher.go:73] Error attaching volume "vol-00095ddceae1a96ed": Error attaching EBS volume "vol-00095ddceae1a96ed" to instance "i-245203b7": VolumeInUse: vol-00095ddceae1a96ed is already attached to an instance
status code: 400, request id: f510c439-64fe-43ea-b3ef-f496a5cd0577. The volume is currently attached to instance "i-072d9328131bcd9cd"
weird that AWS doesn't bother to put that information in there for us (it does when you try to delete a vol that's in use)
```release-note
NONE
```
Automatic merge from submit-queue
Migrate kubelet to ConfigMapManager interface and use TTL-based caching manager
Fixes#41379
Sometime ago we moved to a secret manager interface for kubelet to manage secrets.
This PR's first commit moves config map management also to a similar interface.
The second commit adds TTL-based CachingConfigMapManager (similar to CachingSecretManager) and makes kubelet use it.
/cc @kubernetes/sig-node-pr-reviews @kubernetes/sig-scalability-misc @wojtek-t @dchen1107
This PR adds the new APIs to support storage capacity isolation as described in the proposal
https://github.com/kubernetes/community/pull/306
1. Add SizeLimit for emptyDir volume
2. Add scratch and overlay storage type used by container level or
node level
Automatic merge from submit-queue
Check volume's status before detaching volume
When volume's status is 'detaching', controllermanager will detach
it again and return err. It is necessary to check volume's status
before detaching volume.
same issue: #44536
Automatic merge from submit-queue (batch tested with PRs 46661, 46562, 46657, 46655, 46640)
Improve validation of active deadline seconds
**What this PR does / why we need it**:
Improve validation of active deadline seconds to not allow it to be larger than max uint32.
If users choose a value that is too large, the conversion of that value to a duration in seconds can cause an overflow. I see no practical benefit of having a value larger than uint32 at this time.
xref: https://bugzilla.redhat.com/show_bug.cgi?id=1456156
**Release note**:
```release-note
Restrict active deadline seconds max allowed value to be maximum uint32
```
