Automatic merge from submit-queue
allow handler to join after the informer has started
This allows an event handler to join after a SharedInformer has started. It can't add any indexes, but it can add its reaction functions.
This works by
1. stopping the flow of events from the reflector (thus stopping updates to our store)
1. registering the new handler
1. sending synthetic "add" events to the new handler only
1. unblocking the flow of events
It would be possible to
1. block
1. list
1. add recorder
1. unblock
1. play list to as-yet unregistered handler
1. block
1. remove recorder
1. play recording
1. add new handler
1. unblock
But that is considerably more complicated. I'd rather not start there since this ought to be the exception rather than the rule.
@wojtek-t who requested this power in the initial review
@smarterclayton @liggitt I think this resolves our all-in-one ordering problem.
@hongchaodeng since this came up on the call
Automatic merge from submit-queue
dedup workqueue requeuing
Updates `workqueue.AddAfter` to only perform the add for the earliest requested requeue operation. An earlier time inserts in the earlier slot and removes the old one. A later time is ignored.
When using this conjunction with an `AddRateLimited` method, you get charged for the additional retry even though you're only queue once.
This keeps requeues from multiplying for every add.
@liggitt
Automatic merge from submit-queue
cacher: replace usable lock with conditional variable
Perviously we use a rwlock to indicate the ready information of the cacher. I feel it is not straightforward. Also it requires a few comments to explain. The pull request tries to replace the lock with a conditional variable for readability reason.
/cc @lavalamp @wojtek-t
Automatic merge from submit-queue
kubectl: ignore only update conflicts in the scaler
@kubernetes/kubectl is there any reason to retry any other errors?
* rolling.go (has all the logic for rolling deployments)
* recreate.go (has all the logic for recreate deployments)
* sync.go (has all the logic for getting and scaling replica sets)
* rollback.go (has all the logic for rolling back a deployment)
* util.go (contains all the utilities used throughout the controller)
Leave back at deployment_controller.go all the necessary bits for
creating, setting up, and running the controller loop.
Also add package documentation.
Automatic merge from submit-queue
Reorganize volume controllers and manager
* Move both PV and attach/detach volume controllers to `controllers/volume` (closes#26222)
* Rename `kubelet/volume` to `kubelet/volumemanager`
* Add/update OWNER files
Automatic merge from submit-queue
Add MinReadySeconds to rolling updater
Add MinReadySeconds support to RollingUpdater that allows to specify the number of seconds to wait on top of the pod is "ready" because its readiness probe passed.
Automatic merge from submit-queue
Use `CreatedByAnnotation` constant
A nit but didn't want the strings to get out of sync.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Automatic merge from submit-queue
Add additional testing scenarios for compute resource requests=0
I was asked about the qos tier of a pod that specified
`--requests=cpu=0,memory=0 --limits=cpu=100m,memory=1Gi`
and in just investigating current behavior, realized we should have an explicit test case to ensure that 0 values are preserved in defaulting passes, and that this is still a burstable pod (but the lowest for that tier as it related to eviction)
/cc @vishh
This commit includes a proposal and a Go file to re-define the container
runtime interface.
Note that this is an experimental interface and is expected to go through
multiple revisions once developers start implementing against it. As stated in
the proposal, there are also individual issues to carry discussions of
specific features.
Automatic merge from submit-queue
Update "kubectl get all" to display resource type as part of name
fixes#23838
release-note-none
When running "kubectl get all", or printing any output with mixed resource kinds, an additional column is added to the output with each resource's kind:
`kubectl get all --all-namespaces`
```
NAMESPACE NAME DESIRED CURRENT AGE
default rc/docker-registry-1 1 1 23h
testproject rc/node-1 0 0 2d
NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default svc/docker-registry 172.30.36.42 <none> 5000/TCP 23h
default svc/kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP 7d
testproject svc/ruby-ex 172.30.187.128 <none> 8080/TCP 6d
NAMESPACE NAME READY STATUS RESTARTS AGE
default po/docker-registry-1-cpf8o 1/1 Running 1 23h
```
[]()
Automatic merge from submit-queue
kubectl: don't display an empty list when trying to get a single resource that isn't found
Return immediately when attempting to get a singular resource that isn't found, so that we avoid
printing out a List if the output format is something like json or yaml.
Before:
```
$ kubectl get pod/foo -o yaml
apiVersion: v1
items: []
kind: List
metadata: {}
pods "foo" not found
```
After:
```
$ kubectl get pod/foo -o yaml
pods "foo" not found
```
Fixes#28243
@kubernetes/kubectl @kubernetes/rh-ux @smarterclayton @liggitt @deads2k @metral
Automatic merge from submit-queue
Allow specifying secret data using strings
This PR allows specifying non-binary data values in `Secret` objects as `"stringData":{"key":"string value"}`, in addition to the existing base64 []byte serializations in the `data` field.
On write, the keys and values in the `stringData` field are merged to the `data` map, overwriting any values already present in the `data` map. The move is one-way, the `stringData` field is never output when reading from the API.
A Secret could be created like this:
```
{
"kind":"Secret",
"apiVersion":"v1",
"metadata":{"name":"mysecret"},
"data":{
"image":"<base64-encoded-jpg>"
},
"stringData":{
"username": "myuser",
"password": "mypassword"
}
}
```
and when read from the API would look like this:
```
{
"kind":"Secret",
"apiVersion":"v1",
"metadata":{"name":"mysecret",...},
"data":{
"image":"<base64-encoded-jpg>"
"username": "bXl1c2Vy",
"password": "bXlwYXNzd29yZA=="
}
}
```
Automatic merge from submit-queue
Should set default value for --service-node-port-range flag before verifying
For the flag `--service-node-port-range` of kube-apiserver, we know that it defaults to `30000-32767` if not specified. But if we only pass the flag `--kubernetes-service-node-port` with a valid value between `30000-32767` when starting kube-apiserver, a fatal error will occurs as the last below. It means that service port range is not 30000-32767 but empty. The log is from code [DefaultAndValidateRunOptions-->ValidateRunOptions-->verifyServiceNodePort](https://github.com/xiangpengzhao/kubernetes/blob/master/pkg/genericapiserver/genericapiserver.go#L580) where the flags are verified.
After tracing the apiserver related code, we can find the call stack:
```
func main() {
......
s := options.NewAPIServer()
......
app.Run(s)
......
}
```
In the `app.Run`, it calls [genericapiserver.DefaultAndValidateRunOptions(s.ServerRunOptions)](https://github.com/xiangpengzhao/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L80). But the `--kubernetes-service-node-port` hasn't been defaulted before there, so it's empty. It's then defaulted in `app.Run`-->[master.New](https://github.com/xiangpengzhao/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L276)-->[genericapiserver.New](https://github.com/xiangpengzhao/kubernetes/blob/master/pkg/master/master.go#L179)-->[setDefaults](https://github.com/xiangpengzhao/kubernetes/blob/master/pkg/genericapiserver/genericapiserver.go#L338)-->[defaultServiceNodePortRange](https://github.com/xiangpengzhao/kubernetes/blob/master/pkg/genericapiserver/genericapiserver.go#L281).
So, we have to set default value for `--kubernetes-service-node-port` in [NewServerRunOptions](https://github.com/xiangpengzhao/kubernetes/blob/master/pkg/genericapiserver/options/server_run_options.go#L105), as is done for `--secure-port` and/or `--insecure-port`. The `NewServerRunOptions` will be called in options.[NewAPIServer](https://github.com/xiangpengzhao/kubernetes/blob/master/cmd/kube-apiserver/app/options/options.go#L50)().
Hope that I have described the issue clearly. Thanks!
```
root@vm:~# kube-apiserver --etcd-servers=http://172.16.1.11:4001 --service-cluster-ip-range=192.168.122.0/24 --insecure-bind-address=0.0.0.0 --logtostderr=false --log-dir=/home/paas/zxp/log/kube --v=10 --kubernetes-service-node-port=30001 &
[2] 24629
root@vm:~# F0627 23:46:37.308726 24629 genericapiserver.go:580] Kubernetes service port range doesn't contain 30001
goroutine 1 [running]:
k8s.io/kubernetes/vendor/github.com/golang/glog.stacks(0x44f2500, 0x0, 0x0, 0x0)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:766 +0xb8
k8s.io/kubernetes/vendor/github.com/golang/glog.(*loggingT).output(0x44d2020, 0xc800000003, 0xc820238000, 0x438c73b, 0x13, 0x244, 0x0)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:717 +0x259
k8s.io/kubernetes/vendor/github.com/golang/glog.(*loggingT).printf(0x44d2020, 0xc800000003, 0x3223dc0, 0x33, 0xc8204c4cc8, 0x2, 0x2)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:655 +0x1d4
k8s.io/kubernetes/vendor/github.com/golang/glog.Fatalf(0x3223dc0, 0x33, 0xc8204c4cc8, 0x2, 0x2)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/vendor/github.com/golang/glog/glog.go:1145 +0x5d
k8s.io/kubernetes/pkg/genericapiserver.verifyServiceNodePort(0xc8202a8400)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/pkg/genericapiserver/genericapiserver.go:580 +0x1d5
k8s.io/kubernetes/pkg/genericapiserver.ValidateRunOptions(0xc8202a8400)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/pkg/genericapiserver/genericapiserver.go:605 +0x2f
k8s.io/kubernetes/pkg/genericapiserver.DefaultAndValidateRunOptions(0xc8202a8400)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/pkg/genericapiserver/genericapiserver.go:612 +0x4e
k8s.io/kubernetes/cmd/kube-apiserver/app.Run(0xc820224fc0, 0x0, 0x0)
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/cmd/kube-apiserver/app/server.go:80 +0x70
main.main()
/home/paas/zxp/code/k8s/fork/kubernetes/_output/local/go/src/k8s.io/kubernetes/cmd/kube-apiserver/apiserver.go:50 +0x121
[2]+ Exit 255 kube-apiserver --etcd-servers=http://172.16.1.11:4001 --service-cluster-ip-range=192.168.122.0/24 --insecure-bind-address=0.0.0.0 --logtostderr=false --log-dir=/home/paas/zxp/log/kube --v=10 --kubernetes-service-node-port=30001
root@vm:~#
```
Automatic merge from submit-queue
Implement custom help command for kubectl
```release-note
* kubectl help now provides "Did you mean this?" suggestions for typo/invalid command names.
```
Custom implementation of help command allows to print `Did you mean this?` with
suggestions, which is missed in embed help command from github.com/spf13/cobra
Also, it can be extended with different search features. At this patch, help
command searches query in short descriptions of commands in case of mismatch
with commands names.
fixes#25234
Own implemenation of help command allows to print `Did you mean this?` with
suggestions, which is missed in embed help command from github.com/spf13/cobra
Also, it can be extended with different search features. At this patch, help
command search query in short descriptions of commands in case of mismatch
with commands names.
fixes#25234
Automatic merge from submit-queue
oidc auth plugin: don't hard fail if provider is unavailable
When using OpenID Connect authentication, don't cause the API
server to fail if the provider is unavailable. This allows
installations to run OpenID Connect providers after starting the
API server, a common case when the provider is running on the
cluster itself.
Errors are now deferred to the authenticate method.
cc @sym3tri @erictune @aaronlevy @kubernetes/sig-auth
Automatic merge from submit-queue
[kubelet] Allow opting out of automatic cloud provider detection in kubelet. By default kubelet will auto-detect cloud providers
fixes#28231
Xiang Li