Automatic merge from submit-queue
include metadata in third party resource list serialization
Third party resource listing does not include important metadata such as resourceVersion and apiVersion. This commit includes the missing metadata and also replaces the string templating with an anonymous struct.
Automatic merge from submit-queue
Make kubelet continue cleanup when there is noncritical error.
Fix https://github.com/kubernetes/kubernetes/issues/29078.
Even though there is error when cleaning up pod directory or bandwidth limits, kubelet could continue cleanup the following stuff.
However, when runtime cache or runtime returns error, cleanup should fail, because the following cleanup relies on the `runningPod`.
@yujuhong
/cc @kubernetes/sig-node
Automatic merge from submit-queue
Type define note "errNotAcceptable" should be "errUnsupportedMediaType"
In file "pkg\apiserver\errors.go", line 129:
"// errNotAcceptable indicates Content-Type is not recognized"
Here "errNotAcceptable" shuould be "errUnsupportedMediaType", thus consistent with line 131:
"type errUnsupportedMediaType struct"
This could result in the network plugin not retrieving the pod ip in a
call to SyncPod when using the `exec` network plugin.
The CNI and kubenet network plugins ignore the name/namespace arguments,
so they are not impacted by this bug.
I verified the second included test failed prior to correcting the
argument order.
Fixes#29161
Automatic merge from submit-queue
Return (bool, error) in Authorizer.Authorize()
Before this change, Authorize() method was just returning an error, regardless of whether the user is unauthorized or whether there is some other unrelated error. Returning boolean with information about user authorization and error (which should be unrelated to the authorization) separately will make it easier to debug.
Fixes#27974
Automatic merge from submit-queue
Do not skip check for cgroup creation in the systemd mount
As soon as libcontainer dependency is update in #28410, we can skip check for cgroup creation in the systemd mount. As the latest version of libcontainer should create cgroups in the sytemd mount aswell.
This is tied to the upstream issue: #27204
@vishh PTAL
Remove an unused logic. Also this prevents the KillPod() from failing
when the service file doesn't exist. E.g., it can be removed by garbage
collection in a rare case:
1, There are already more than `gcPolicy.MaxContainers` containers running
on the host.
2, The new pod(A) starts to run but doesn't enter 'RUNNING' state yet.
3, GC is triggered, and it sees the pod(A) is in an inactive state (not running),
and the it needs to remove the pod to force the `gcPolicy.MaxContainers`.
4, GC fails to remove the pod because `rkt rm` fails when the pod is running,
but it removes the service file anyway.
5, Follow up KillPod() call will fail because it cannot find the service file
on disk.
Also this is possible only when the pod has been in prepared state for longer
than 1 min, which sounds like another issue.
Automatic merge from submit-queue
Do not query the metadata server to find out if running on GCE. Retry metadata server query for gcr if running on gce.
Retry the logic for determining is gcr is enabled to workaround metadata unavailability.
Note: This patch does not retry fetching registry credentials.
Automatic merge from submit-queue
Apiserver ServeHTTP() modify
In File "pkg\apiserver\watch.go", line 123:
"// Serve serves a series of encoded events via HTTP with Transfer-Encoding: chunked"
Here "Serve" should be "ServeHTTP" because the func name is ServeHTTP:
"func (s *WatchServer) ServeHTTP(w http.ResponseWriter, req *http.Request)"
Automatic merge from submit-queue
Make sure --record=false is acknowledged when passed to commands
```release-note
Change setting "kubectl --record=false" to stop updating the change-cause when a previous change-cause is found.
```
Ensures that when `--record=false` is explicity set that no `ChangeCauseAnnotation`s are set on the object. Previously, if `--record=true` was used then all following actions triggered a `ChangeCauseAnnotation` even if `--record=false` was set, due to the prior `ChangeCauseAnnotation` existing.
Reference to bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1351127
[]()
Automatic merge from submit-queue
kubectl apply add --overwrite flag
```release-note
Add "kubectl --overwrite" flag to automatically resolve conflicts between the modified and live configuration using values from the modified configuration.
```
fixes#17238
This PR just add the `--overwrite` flag, pkg/strategicpatch has already support overwrite. @bgrant0607 @jackgr ptal.
This commit ensures that `flockerMounter.updateDatasetPrimary` does not leak
running `time.Ticker` instances. Upon termination of the consuming
routine, we stop the tickers.
Before this change, Authorize() method was just returning an error,
regardless of whether the user is unauthorized or whether there
is some other unrelated error. Returning boolean with information
about user authorization and error (which should be unrelated to
the authorization) separately will make it easier to debug.
Fixes#27974
Automatic merge from submit-queue
Fix port range checking, port should not be greater than 65535.
When passing flag `--proxy-port-range` to kube-proxy with an invalid range which is greater than 65535, the proxy doesn't exit. That's not what we want.
Should we fix this in v1.3?
/cc @thockin @mikedanese @resouer
Before fixing:
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599 &
[6] 6671
root@vm:/home/paas/zxp# ps -ef | grep kube-proxy
root 6671 13507 0 03:48 pts/1 00:00:00 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599
```
After:
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599 &
[6] 6725
root@vm:/home/paas/zxp# invalid argument "65536-65599" for --proxy-port-range=65536-65599: "65536-65599" is not a valid port range: the port range cannot be greater than 65535: 65536-65599
..............
[6]+ Exit 2 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=65536-65599
```
```
root@vm:/home/paas/zxp# kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=6000-65599 &
[6] 6732
root@vm:/home/paas/zxp# invalid argument "6000-65599" for --proxy-port-range=6000-65599: "6000-65599" is not a valid port range: the port range cannot be greater than 65535: 6000-65599
..............
[6]+ Exit 2 kube-proxy --master=172.16.1.11:8080 --logtostderr=false --log-dir=/home/user/log/kube --proxy-port-range=6000-65599
```
Automatic merge from submit-queue
Custom conversions between RCs/RSs
Needed for building storages that still need to work with RCs but also want to facilitate RSs.
cc: @deads2k @smarterclayton @liggitt
Automatic merge from submit-queue
authorize based on user.Info
Update the `authorization.Attributes` to use the `user.Info` instead of discrete getters for each piece.
@kubernetes/sig-auth
Automatic merge from submit-queue
List all nodes and occupy cidr map before starting allocations
Manually tested by starting a 200 node cluster with frequent controller manager restarts.
Fixes https://github.com/kubernetes/kubernetes/issues/29058
Automatic merge from submit-queue
Fix GPU resource validation
This fixes scheduling of pods with GPU resources. The change was never upstreamed during the 1.3 beta period, as it got lost in the noise of other changes in our fork. Ooops. I'll submit a cherry-pick request for 1.3.1 as soon as this lands in master.
Because of defaulting, requests are always set if limits are. Thus, the check can never succeed. Instead, make sure that the two values are equal.
Also, remove a few other error messages and remove unnecessary Sprintf calls.
Automatic merge from submit-queue
rkt: Copy the /etc/hosts /etc/resolv.conf into pod dir before mounting.
rkt: Copy the /etc/hosts /etc/resolv.conf into pod dir before mounting.
This enables the container to modify the /etc/hosts/ /etc/resolv.conf without changing the host's ones.
With this PR, we now match the docker's behavior.
Fix https://github.com/kubernetes/kubernetes/issues/29022
cc @kubernetes/sig-rktnetes @quentin-m
