Automatic merge from submit-queue
dockertools: Don't use network plugin if net=host
I'm pretty sure this was just an oversight the first time around.
Before: `E0815 18:06:17.627468 976 docker_manager.go:350] NetworkPlugin kubenet failed on the status hook for pod 'sleep' - Unexpected command output Device "eth0" does not exist.`
After: No such logline is printed
The pod IP reported in `describe` is the same either way
cc @kubernetes/sig-node
Automatic merge from submit-queue
Gubernator bug fixes: mv and GCS bucket permissions
Fixed issue where results file was not moved correctly, and also the permissions issue with the GCS bucket.
Will rebase after #30414 is merged
@timstclair
Automatic merge from submit-queue
Fixes#30886
This PR fixes https://github.com/kubernetes/kubernetes/issues/30886
```
make WHAT=pkg/kubelet
+++ [0818 17:03:21] Generating bindata:
/Users/jscheuermann/inovex/workspace/kubernetes-clone/test/e2e/framework/gobindata_util.go
+++ [0818 17:03:22] Building the toolchain targets:
k8s.io/kubernetes/hack/cmd/teststale
+++ [0818 17:03:22] Building go targets for darwin/amd64:
pkg/kubelet
```
Automatic merge from submit-queue
Add a short `-n` for `kubectl --namespace`
fixes#24078
`--namespace` is a very common flag for nearly every `kubectl` command we have. We should claim `-n` for it.
Automatic merge from submit-queue
Node controller deletePod return true if there are pods pending deletion
Fixes https://github.com/kubernetes/kubernetes/issues/30536
If a node had a single pod in terminating state, and that node no longer reported healthy, the pod was never deleted by the node controller because it believed there were no pods remaining.
@smarterclayton @ncdc
Automatic merge from submit-queue
rkt: Do not error out when there are unrecognized lines in os-release
Also fix the error handling which will cause panic. Also fix the error handling which will cause panic.
cc @kubernetes/sig-rktnetes
```relnote
Moved init-container feature from alpha to beta.
In 1.3, an init container is specified with this annotation key
on the pod or pod template: `pods.alpha.kubernetes.io/init-containers`.
In 1.4, either that key or this key: pods.beta.kubernetes.io/init-containers`,
can be used.
When you GET an object, you will see both annotation keys with the same values.
You can safely roll back from 1.4 to 1.3, and things with init-containers
will still work (pods, deployments, etc).
If you are running 1.3, only use the alpha annotation, or it may be lost when
rolling forward.
The status has moved from annotation key
`pods.beta.kubernetes.io/init-container-statuses` to
`pods.beta.kubernetes.io/init-container-statuses`.
Any code that inspects this annotation should be changed to use the new key.
State of Initialization will continue to be reported in both pods.alpha.kubernetes.io/initialized
and in `podStatus.conditions.{status: "True", type: Initialized}`
```
Mini-design for this change:
Goals:
1. A user can create an object with the beta annotation
on 1.4, and it works. The fact that the annotation has beta
in it communicates to the user that the feature is beta,
and so the user should have confidence in using it. Preferably,
when the user gets the annotation back, he see the beta
annotation.
1) If someone had an existing alpha object in their apiserver,
such as a RS with a pod template with an init-containers
annotation on it, it should continue to work (init containers
run) when stack upgraded to 1.4.
2) If someone is using a chart or blog post that has alpha
annotation on it and they create it on a 1.4 cluster, it should
work.
3) If someone had something with an init container in 1.4
and they roll back stack to 1.3, it should not silently stop
working (init containers don't run anymore).
To meet all these, we mirror an absent beta label from the alpha
key and vice versa. If they are out of sync, we use the alpha
one. We do this in conversion since there was already logic there.
In 1.3 code, all annotations are preserved across a round trip
(v1 -> api -> v1), and the alpha annotation turns into the internal
field that kubelet uses.
In 1.4 code, the alpha annotation is always preserved across
a round trip, and a beta annotation is always set equal to
the alpha one, after a round trip.
Currently, the kubelet always sees the object after a round trip
when it GETs it. But, we don't want to rely on that behavior,
since it will break when fastpath is implemented.
So, we rely on this:
all objects either are created with an alpha annotation (1.3 or 1.4
code) or are created with a beta annotation under 1.4. In the later
case, they are round tripped at creation time, and so get both
annotations. So all subsequent GETs see both labels.
Add --bootstrap-kubeconfig flag to kubelet. If the flag is non-empty
and --kubeconfig doesn't exist, then the kubelet will use the bootstrap
kubeconfig to create rest client and generate certificate signing request
to request a client cert from API server.
Once succeeds, the result cert will be written down to
--cert-dir/kubelet-client.crt, and the kubeconfig will be populated with
certfile, keyfile path pointing to the result certificate file, key file.
(The key file is generated before creating the CSR).
Automatic merge from submit-queue
Add logging time series to benchmark test
This PR adds a new file benchmark_util.go which contains tool functions for benchmark (we can migrate benchmark related functions into it).
The PR logs time series data for density benchmark test.
So that at most one volume object will be created for every unique
host path. Also the volume's name is random generated UUID to avoid
collision since the mount point's name passed by kubelet is not
guaranteed to be unique when 'subpath' is specified.
Automatic merge from submit-queue
kubelet/api: split RuntimeService interface
Splits `RuntimeService` interface into smaller interfaces
to make testing easier and delineate the responsibilities.
Its a non-breaking change to the previous users of `api.RuntimeService`
Automatic merge from submit-queue
Federated secret controller
Federated secret controller uses the common set of libraries that are used in every federated controller
PR #30207 by @mwielgus is considered the baseline code for federated controllers and was used as the starting point of this PR
Automatic merge from submit-queue
prevent RC hotloop on denied pods
If a pod is rejected during creation, the RC controller hot-loops. This can happen most frequently due to insufficient quota.
Automatic merge from submit-queue
add --raw for kubectl get
Adds a `--raw` option to `kubectl get` that allow you specify your URI, but use the transport built by `kubectl`. This is especially useful when working with secured environments that require authentication and authorization to hit non-api endpoints. For example, `kubect get --raw /metrics` or if you want to debug a watch with a view at the exact data `kubectl get --raw '/api/v1/namespaces/one/replicationcontrollers?watch=true'`.
@kubernetes/kubectl
@fabianofranz fyi
Automatic merge from submit-queue
Support for preexisting replicas and estimated capacity in federated replicaset controller
With this PR the planer will be able to:
* Keep already existing replicas in their current clusters if rebalance = false and min/max boundaries are met.
* Limit the number of replicas in a cluster to the level that was measured by the count of running and unschedulable pods. And provide an estimate how much more pods would be nice to put in a cluster so that if they are scheduled we will be closer to the desired layout or to schedule the desired number of replicas at all.
cc: @quinton-hoole @jianhuiz @wojtek-t @kubernetes/sig-cluster-federation
Automatic merge from submit-queue
Add Events for operation_executor to show status of mounts, failed/successful to show in describe events
Fixes#27590
@saad-ali @pmorie @erinboyd
After talking with @pmorie last week about the above issue, I decided to poke around and see if I could remedy. The refactoring broke my previous UXP merged PR's that correctly showed failed mount errors in the describe events. However, Not sure I implemented correctly, but it tested out and seems to be working, let me know what I missed or if this is not the correct approach.
```
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
2m 2m 1 {default-scheduler } Normal Scheduled Successfully assigned nfs-bb-pod1 to 127.0.0.1
44s 44s 1 {kubelet 127.0.0.1} Warning FailedMount Unable to mount volumes for pod "nfs-bb-pod1_default(a94f64f1-37c9-11e6-9aa5-52540073d346)": timeout expired waiting for volumes to attach/mount for pod "nfs-bb-pod1"/"default". list of unattached/unmounted volumes=[nfsvol]
44s 44s 1 {kubelet 127.0.0.1} Warning FailedSync Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "nfs-bb-pod1"/"default". list of unattached/unmounted volumes=[nfsvol]
38s 38s 1 {kubelet } Warning FailedMount Unable to mount volumes for pod "a94f64f1-37c9-11e6-9aa5-52540073d346": Mount failed: exit status 32
Mounting arguments: nfs1.rhs:/opt/data99 /var/lib/kubelet/pods/a94f64f1-37c9-11e6-9aa5-52540073d346/volumes/kubernetes.io~nfs/nfsvol nfs []
Output: mount.nfs: Connection timed out
Resolution hint: Check and make sure the NFS Server exists (ensure that correct IPAddress/Hostname was given) and is available/reachable.
Also make sure firewall ports are open on both client and NFS Server (2049 v4 and 2049, 20048 and 111 for v3).
Use commands telnet <nfs server> <port> and showmount <nfs server> to help test connectivity.
```
Automatic merge from submit-queue
Fix pvc requests.storage validation
A `PersistentVolumeClaim` should not be able to request a negative amount of storage.
/cc @kubernetes/sig-storage @kubernetes/rh-cluster-infra @deads2k
