Automatic merge from submit-queue
Fix for Premature iSCSI logout #39202.
**What this PR does / why we need it**:
Modifies the iSCSI volume plugin code to prevent premature iSCSI logouts and the establishment of multiple iSCSI connections to the same target in certain cases.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#39202, fixes#41041, fixes#40941
**Special notes for your reviewer**:
The existing iSCSI connections are now rescanned on every AttachDisk call to discover newly created LUNs.
The disk mount points now contain an additional directory in the path corresponding to the disk iface that is later used for iSCSI logout.
The device prefixes that are used to count the existing references to the portal-target pair now contain the whole path including the mount point until the lun index.
**Release note**:
```release-note
Fixed issues #39202, #41041 and #40941 that caused the iSCSI connections to be prematurely closed when deleting a pod with an iSCSI persistent volume attached and that prevented the use of newly created LUNs on targets with preestablished connections.
```
Automatic merge from submit-queue (batch tested with PRs 40297, 41285, 41211, 41243, 39735)
fix variables in openstack.go to keep camel casing and remove unused var
Automatic merge from submit-queue
Fix bug in status manager TerminatePod
In TerminatePod, we previously pass pod.Status to updateStatusInternal. This is a bug, since it is the original status that we are given. Not only does it skip updates made to container statuses, but in some cases it reverted the pod's status to an earlier version, since it was being passed a stale status initially.
This was the case in #40239 and #41095. As shown in #40239, the pod's status is set to running after it is set to failed, occasionally causing very long delays in pod deletion since we have to wait for this to be corrected.
This PR fixes the bug, adds some helpful debugging statements, and adds a unit test for TerminatePod (which for some reason didnt exist before?).
@kubernetes/sig-node-bugs @vish @Random-Liu
Automatic merge from submit-queue (batch tested with PRs 41378, 41413, 40743, 41155, 41385)
Expose the constants in pkg/controller/bootstrap and add a validate token function
**What this PR does / why we need it**: In order to hook up #36101 against kubeadm, we have to expose the constants and add a function to validate the token
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
cc @jbeda @mikedanese @pires @dmmcquay
Automatic merge from submit-queue (batch tested with PRs 41378, 41413, 40743, 41155, 41385)
Reconcile bootstrap clusterroles on server start
Currently, on server start, bootstrap roles and bindings are only created if there are no existing roles or rolebindings.
Instead, we should look at each bootstrap role and rolebinding, and ensure it exists and has required permissions and subjects at server start. This allows seamless upgrades to new versions that define roles for new controllers, or add permissions to existing roles.
```release-note
Default RBAC ClusterRole and ClusterRoleBinding objects are automatically updated at server start to add missing permissions and subjects (extra permissions and subjects are left in place). To prevent autoupdating a particular role or rolebinding, annotate it with `rbac.authorization.kubernetes.io/autoupdate=false`.
```
Automatic merge from submit-queue
Make EnableCRI default to true
This change makes kubelet to use the CRI implementation by default,
unless the users opt out explicitly by using --enable-cri=false.
For the rkt integration, the --enable-cri flag will have no effect
since rktnetes does not use CRI.
Also, mark the original --experimental-cri flag hidden and deprecated,
so that we can remove it in the next release. If both flags are specified,
the --enable-cri flag overrides the --experimental-cri flag.
Automatic merge from submit-queue
Make kubectl edit work with unstructured objects
Fixes https://github.com/kubernetes/kubernetes/issues/35993
1. First (before any other changes), added several test cases for complex edit scenarios:
- [x] ensure the edit loop bails out if given the same result that already caused errors
- [x] ensure an edited file with a syntax error is reopened preserving the input
- [x] ensure objects with existing "caused-by" annotations get updated with the current command
2. Refactored the edit code to prep for switching to unstructured:
- [x] made editFn operate on a slice of resource.Info objects passed as an arg, regardless of edit mode
- [x] simplified short-circuiting logic when re-editing a file containing an error
- [x] refactored how we build the various visitors (namespace enforcement, annotation application, patching, creating) so we could easily switch to just using a single visitor over a set of resource infos read from the updated input for all of them
3. Switched to using a resource builder to parse the stream of the user's edited output
- [x] improve the error message you get on syntax errors
- [x] preserve the user's input more faithfully (see how the captured testcase requests to the server changed to reflect exactly what the user edited)
- [x] stopped doing client-side conversion (means deprecating `--output-version`)
4. Switched edit to work with generic objects
- [x] use unstructured objects
- [x] fall back to generic json merge patch for unrecognized group/version/kinds
5. Added new test cases
- [x] schemaless objects falls back to generic json merge (covers TPR scenario)
- [x] edit unknown version of known kind (version "v0" of storageclass) falls back to generic json merge
```release-note
`kubectl edit` now edits objects exactly as they were retrieved from the API. This allows using `kubectl edit` with third-party resources and extension API servers. Because client-side conversion is no longer done, the `--output-version` option is deprecated for `kubectl edit`. To edit using a particular API version, fully-qualify the resource, version, and group used to fetch the object (for example, `job.v1.batch/myjob`)
```
Automatic merge from submit-queue
fix comment
**What this PR does / why we need it**:
fix comment
Thanks.
**Special notes for your reviewer**:
**Release note**:
```release-note
```
This change makes kubelet to use the CRI implementation by default,
unless the users opt out explicitly by using --enable-cri=false.
For the rkt integration, the --enable-cri flag will have no effect
since rktnetes does not use CRI.
Also, mark the original --experimental-cri flag hidden and deprecated,
so that we can remove it in the next release.
Automatic merge from submit-queue (batch tested with PRs 41382, 41407, 41409, 41296, 39636)
Update to use proxy subresource consistently
Proxy subresources have been in place since 1.2.0 and improve the ability to put policy in place around proxy access.
This PR updates the last few clients to use proxy subresources rather than the root proxy
mark --output-version as deprecated, add example for fully-qualifying version to edit
Add 'kubectl edit' testcase for editing schemaed and schemaless data together
Add 'kubectl edit' testcase for editing unknown version of known group/kind
edit: make editFn operate on arguments regardless of mode
edit: simplify short-circuiting logic when re-editing a file containing an error
edit: factor out visitor building
edit: use resource builder to get results from edited file
Add 'kubectl edit' testcase for saving a repeated error
Add 'kubectl edit' testcase for preserving an edited file with a syntax error
Add 'kubectl edit' testcase for recording command on list of objects
Automatic merge from submit-queue (batch tested with PRs 41299, 41325, 41386, 41329, 41418)
move metav1 conversions to metav1
Conversions for `metav1` types belong in metav1 and should be registered when you register the types.
@mikedanese @luxas I think this is what you just hit in your fresh scheme.
@smarterclayton @lavalamp double check the sanity, but I think this does what people expect.
Automatic merge from submit-queue (batch tested with PRs 41299, 41325, 41386, 41329, 41418)
stop senseless negotiation
Most client commands don't respect a negotiated version at all. If you request a particular version, then of course it should be respected, but if you have none to request, then the current negotiation step doesn't return anything useful so we may as well have nothing so we can at least detect the situation.
@jwforres @kubernetes/sig-cli-pr-reviews
Added a TODO to make the negotiate function useful. I think I'm inclined to remove it entirely unless someone can come up with a useful reason to have it.
Automatic merge from submit-queue (batch tested with PRs 41337, 41375, 41363, 41034, 41350)
use instance's Name to attach gce disk
**What this PR does / why we need it**:
fix#40427
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#40427
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 41357, 41178, 41280, 41184, 41278)
Switch RBAC subject apiVersion to apiGroup in v1beta1
Referencing a subject from an RBAC role binding, the API group and kind of the subject is needed to fully-qualify the reference.
The version is not, and adds complexity around re-writing the reference when returning the binding from different versions of the API, and when reconciling subjects.
This PR:
* v1beta1: change the subject `apiVersion` field to `apiGroup` (to match roleRef)
* v1alpha1: convert apiVersion to apiGroup for backwards compatibility
* all versions: add defaulting for the three allowed subject kinds
* all versions: add validation to the field so we can count on the data in etcd being good until we decide to relax the apiGroup restriction
```release-note
RBAC `v1beta1` RoleBinding/ClusterRoleBinding subjects changed `apiVersion` to `apiGroup` to fully-qualify a subject. ServiceAccount subjects default to an apiGroup of `""`, User and Group subjects default to an apiGroup of `"rbac.authorization.k8s.io"`.
```
@deads2k @kubernetes/sig-auth-api-reviews @kubernetes/sig-auth-pr-reviews
Automatic merge from submit-queue (batch tested with PRs 41115, 41212, 41346, 41340, 41172)
Enable PodTolerateNodeTaints predicate in DaemonSet controller
Ref #28687, this enables the PodTolerateNodeTaints predicate to the daemonset controller
cc @Random-Liu @dchen1107 @davidopp @mikedanese @kubernetes/sig-apps-pr-reviews @kubernetes/sig-node-pr-reviews @kargakis @lukaszo
```release-note
Make DaemonSet controller respect node taints and pod tolerations.
```
Automatic merge from submit-queue
fix service spec for kube api server
For the auto generated kube api-server service, the service spec re-uses the service port itself. The endpoint is created correctly using public port. Fix the service also because there are some plugin controllers that react to service spec itself.
Before fix:
```
sh-4.2# kubectl get endpoints
NAME ENDPOINTS AGE
kubernetes 172.17.0.2:8443,172.17.0.2:8053,172.17.0.2:8053 20h
sh-4.2# kubectl get services kubernetes -o json
...
...
"spec": {
"clusterIP": "172.30.0.1",
"ports": [
{
"name": "https",
"port": 443,
"protocol": "TCP",
"targetPort": 443 ## <--- same as port, even if the endpoint really means 8443
},
{
"name": "dns",
"port": 53,
"protocol": "UDP",
"targetPort": 8053
},
{
"name": "dns-tcp",
...
```
After fix:
```
"spec": {
"clusterIP": "172.30.0.1",
"ports": [
{
"name": "https",
"port": 443,
"protocol": "TCP",
"targetPort": 8443 # <-- fixed, now matches the endpoint object
},
{
"name": "dns",
"port": 53,
"protocol": "UDP",
"targetPort": 8053
},
{
"name": "dns-tcp",
``
Automatic merge from submit-queue
Added kubectl create role command
Added `kubectl create role` command.
Fixed part of #39596
**Release note**:
```
Added one new command `kubectl create role` to help user create a single role from command line.
```
Automatic merge from submit-queue (batch tested with PRs 41312, 41289)
resolve udevadm from PATH in cinder_util.go
**What this PR does / why we need it**:
When a cinder volume gets attached to a node, the cinder volume plugin calls `udevadm` with an absolute path `/usr/bin/udevadm`. This path is incorrect for recent versions of debian, ubuntu or the hyperkube image on gcr.io where `udevadm` is located at `/bin/udevadm` or `/sbin/udevadm`. A variant of the hyperkube image is used on CoreOS to run kubelet with rkt fly stage 1.
As a result of the failed `udevadm` exec, the `AttachDisk` function in `cinder_util.go` returns an error.
This PR removes the absolute path from the `udevadm` exec. As a result, `udevadm` is resolved by looking it up in `PATH`.
This is consistent with the gce volume plugin, which executes `udevadm` the same way.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#29832
**Special notes for your reviewer**:
**Release note**:
```release-note
```
