Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fix test images
These commits fix volume_io tests for iSCSI and Ceph RBD. Both server images were quite old (Fedora 22), so I updated them to ~~something more stable (CentOS 7) and to newer Ceph (Jewel, 10.2.7).~~ something newer (Fedora 26).
The most important fix is that the test volumes have 120 MB so volume_io test can actually run - the tests put 100MB file to the volume to check its persistence.
When mount containers in #53440 are merged I'll try to run the tests regularly with every PR (or merge) so we catch regressions quickly.
```release-note
NONE
```
/sig testing
/sig storage
/assign @jeffvance
Fixes: #56725
- create 120MB volume instead of 1MB for volume_io tests
- rebase to Fedora 26
- added compatibility with ext4 and older ceph clients
- unify CephFS and Ceph RBD images.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
fix README for admission webhook test image
This README is copied from somewhere else and it's out of date.
**Release note**:
```release-note
NONE
```
This is the 2nd attempt. The previous was reverted while we figured out
the regional mirrors (oops).
New plan: k8s.gcr.io is a read-only facade that auto-detects your source
region (us, eu, or asia for now) and pulls from the closest. To publish
an image, push k8s-staging.gcr.io and it will be synced to the regionals
automatically (similar to today). For now the staging is an alias to
gcr.io/google_containers (the legacy URL).
When we move off of google-owned projects (working on it), then we just
do a one-time sync, and change the google-internal config, and nobody
outside should notice.
We can, in parallel, change the auto-sync into a manual sync - send a PR
to "promote" something from staging, and a bot activates it. Nice and
visible, easy to keep track of.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fixes for HostIPC tests to work when Docker has SELinux support enabled.
**What this PR does / why we need it**:
Fixes for HostIPC tests to work when Docker has SELinux support enabled.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
N/A
**Special notes for your reviewer**:
The core of the matter is to use `ipcs` from util-linux rather than the one from busybox. The typical SELinux policy has enough to allow Docker containers (running under svirt_lxc_net_t SELinux type) to access IPC information by reading the contents of the files under /proc/sysvipc/, but not by using the shmctl etc. syscalls.
The `ipcs` implementation in busybox will use `shmctl(0, SHM_INFO, ...)` to detect whether it can read IPC info (see source code [here](https://git.busybox.net/busybox/tree/util-linux/ipcs.c?h=1_28_0#n138)), while the one in util-linux will prefer to read from the /proc files directly if they are available (see source code [here](https://github.com/karelzak/util-linux/blob/v2.27.1/sys-utils/ipcutils.c#L108)).
It turns out the SELinux policy doesn't allow the shmctl syscalls in an unprivileged container, while access to it through the /proc interface is fine. (One could argue this is a bug in the SELinux policy, but getting it fixed on stable OSs is hard, and it's not that hard for us to test it with an util-linux `ipcs`, so I propose we do so.)
This PR also contains a refactor of the code setting IpcMode, since setting it in the "common options" function is misleading, as on containers other than the sandbox, it ends up always getting overwritten, so let's only set it to "host" in the Sandbox.
It also has a minor fix for the `ipcmk` call, since support for size suffix was only introduced in recent versions of it.
**Release note**:
```release-note
NONE
```
This container will be used to exercise the HostIPC functionality in
e2e-node tests.
The version of `ipcs` shipped in busybox performs operations that get
blocked by SELinux on hosts where it is enabled. The version of `ipcs`
in util-linux does not perform those operations, rather it checks
whether the /proc files it needs are available and proceeds to reading
from them directly.
Using `ipcs` from util-linux makes these tests pass, even when running
under SELinux enabled, so let's use them here.
Tested: On a host where Docker with SELinux enabled:
- Checked that `ipcs` from busybox does not work:
$ docker run busybox ipcs -m
kernel not configured for shared memory
- Checked that the one from this container does work:
$ docker run gcr.io/kubernetes-e2e-test-images/ipc-utils-amd64:1.0 ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
Automatic merge from submit-queue (batch tested with PRs 52748, 56623). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Add brackets around IPv6 addrs in e2e test IP:port endpoints
There are several locations in the e2e tests where endpoints of the
form IPv6:port use IPv6 addresses directly, without surrounding brackets.
Brackets are required around IPv6 addresses in this case, in order to
distinguish the colons in the IPv6 address from the colon immediately
preceding the port.
Also, wherever the curl command might be used with an IPv6 address
surrounded in brackets, the "-g" argument is added to the curl
command line arguments so that the brackets can be interpreted
correctly.
fixes#52746
**What this PR does / why we need it**:
This PR adds brackets around IPv6 addresses when they appear as part of an IPv6-addr:port endpoint
in the e2e tests. This is needed because any connections that attempt to use IPv6-addr:port
endpoint without brackets surrounding the IPv6-addr will fail.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#52746
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
AdmissionResponse allows mutating webhook to send apiserver a json patch
to mutate the object.
This reflects the imperative nature of AdmissionReview. It adds
AdmissionRequest and AdmissionResponse in place of status/spec.
The AdmissionResponse the allows the mutating webhook
to send back a json path with the mutated version of the requested
object.
Fixed the integration test to clean up properly.
Switched test image to 1.8v5 to reflect API changes.
Make sure to cache test framework client for cleaup test code.
Switched to pointer for patch type.
Factored in @liggitt's feedback.
Factored in @lavalamp's feedback.
There are several locations in the e2e tests where endpoints of the
form IP:port use IPv6 addresses directly, without surrounding brackets.
Brackets are required around IPv6 addresses in this case, in order to
distinguish the colons in the IPv6 address from the colon immediately
preceding the port.
Also, wherever the curl command might be used with an IPv6 address
surrounded in brackets, the "-g" argument is added to the curl
command line arguments so that the brackets can be interpreted
correctly.
fixes#52746
Automatic merge from submit-queue
Multiarch support for pets images
**What this PR does / why we need it**:
This PR is for multiarch support for pets image
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#52133
**Special notes for your reviewer**:
Copied over the `contrib/pets/peer-finder` as this one is heavily used in many docker images under `test/images`. After this PR I'll submit the PR in contrib project to remove it.
**Release note**:
```NONE
```
Automatic merge from submit-queue
bump QEMU version to v2.9.1
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
xref #38067
**Special notes for your reviewer**:
/assign @luxas
**Release note**:
```release-note
update QEMU version to v2.9.1
```
Automatic merge from submit-queue (batch tested with PRs 50485, 49951, 50508, 50511, 50506)
Multiarch nonewprivs test image
**What this PR does / why we need it**:
This PR is for converting nonewprivs image which pushed very recently part of https://github.com/kubernetes/kubernetes/pull/47019.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
Fixes#50498
**Special notes for your reviewer**:
**Release note**:
```NONE```
Automatic merge from submit-queue (batch tested with PRs 49651, 49707, 49662, 47019, 49747)
Add support for `no_new_privs` via AllowPrivilegeEscalation
**What this PR does / why we need it**:
Implements kubernetes/community#639
Fixes#38417
Adds `AllowPrivilegeEscalation` and `DefaultAllowPrivilegeEscalation` to `PodSecurityPolicy`.
Adds `AllowPrivilegeEscalation` to container `SecurityContext`.
Adds the proposed behavior to `kuberuntime`, `dockershim`, and `rkt`. Adds a bunch of unit tests to ensure the desired default behavior and that when `DefaultAllowPrivilegeEscalation` is explicitly set.
Tests pass locally with docker and rkt runtimes. There are also a few integration tests with a `setuid` binary for sanity.
**Release note**:
```release-note
Adds AllowPrivilegeEscalation to control whether a process can gain more privileges than it's parent process
```
Automatic merge from submit-queue (batch tested with PRs 48914, 48535, 49099, 48935, 48871)
Adopt debian-base as baseimage
**What this PR does / why we need it**:
Based on discussion from - https://github.com/kubernetes/kubernetes/pull/44910/files#r125150263
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#49169
**Special notes for your reviewer**:
**Release note**:
```NONE
```
Automatic merge from submit-queue (batch tested with PRs 48231, 47377, 48797, 49020, 49033)
Update yaml and json with multi arch test images
**What this PR does / why we need it**:
This PR is for updating the yaml and json files under test/images folder with multi arch images
**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**:
**Release note**:
```NONE
```
Automatic merge from submit-queue
Enable "kick the tires" support for Nvidia GPUs in COS
This PR provides an installation daemonset that will install Nvidia CUDA drivers on Google Container Optimized OS (COS).
User space libraries and debug utilities from the Nvidia driver installation are made available on the host in a special directory on the host -
* `/home/kubernetes/bin/nvidia/lib` for libraries
* `/home/kubernetes/bin/nvidia/bin` for debug utilities
Containers that run CUDA applications on COS are expected to consume the libraries and debug utilities (if necessary) from the host directories using `HostPath` volumes.
Note: This solution requires updating Pod Spec across distros. This is a known issue and will be addressed in the future. Until then CUDA workloads will not be portable.
This PR updates the COS base image version to m59. This is coupled with this PR for the following reasons:
1. Driver installation requires disabling a kernel feature in COS.
2. The kernel API for disabling this interface changed across COS versions
3. If the COS image update is not handled in this PR, then a subsequent COS image update will break GPU integration and will require an update to the installation scripts in this PR.
4. Instead of having to post `3` PRs, one each for adding the basic installer, updating COS to m59, and then updating the installer again, this PR combines all the changes to reduce review overhead and latency, and additional noise that will be created when GPU tests break.
**Try out this PR**
1. Get Quota for GPUs in any region
2. `export `KUBE_GCE_ZONE=<zone-with-gpus>` KUBE_NODE_OS_DISTRIBUTION=gci`
3. `NODE_ACCELERATORS="type=nvidia-tesla-k80,count=1" cluster/kube-up.sh`
4. `kubectl create -f cluster/gce/gci/nvidia-gpus/cos-installer-daemonset.yaml`
5. Run your CUDA app in a pod.
**Another option is to run a e2e manually to try out this PR**
1. Get Quota for GPUs in any region
2. export `KUBE_GCE_ZONE=<zone-with-gpus>` KUBE_NODE_OS_DISTRIBUTION=gci
3. `NODE_ACCELERATORS="type=nvidia-tesla-k80,count=1"`
4. `go run hack/e2e.go -- --up`
5. `hack/ginkgo-e2e.sh --ginkgo.focus="\[Feature:GPU\]"`
The e2e will install the drivers automatically using the daemonset and then run test workloads to validate driver integration.
TODO:
- [x] Update COS image version to m59 release.
- [x] Remove sleep from the install script and add it to the daemonset
- [x] Add an e2e that will run the daemonset and run a sample CUDA app on COS clusters.
- [x] Setup a test project with necessary quota to run GPU tests against HEAD to start with https://github.com/kubernetes/test-infra/pull/2759
- [x] Update node e2e serial configs to install nvidia drivers on COS by default
Packaged the script as a docker container stored in gcr.io/google-containers
A daemonset deployment is included to make it easy to consume the installer
A cluster e2e has been added to test the installation daemonset along with verifying installation
by using a sample CUDA application.
Node e2e for GPUs updated to avoid running on nodes without GPU devices.
Signed-off-by: Vishnu kannan <vishnuk@google.com>
Automatic merge from submit-queue (batch tested with PRs 43726, 43643)
Make a smaller redis image for testing, based on Alpine.
**What this PR does / why we need it**:
This shrinks gcr.io/google_containers/redis from 400MB to 5MB, which should reduce flakes.
**Which issue this PR fixes**:
fixes#43631
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
test/images/mount-tester: ensure exec binary is o+rx
The `mount-tester` image is currently used as a base layer for other
test images (like `mounttest-user`) which perform uid/gid changes.
However, the binary built in here just follows local umask, and currently is
```
-rwxr-x--- 1 root root 2052704 May 19 2016 mt
```
This commit adds an explicit chmod on the binary to make sure uid/gid
tests can still run it as "others".
The `mount-tester` image is currently used as a base layer for other
test images (like `mounttest-user`) which perform uid/gid changes.
However, the binary built in here just follows local umask, and currently is
```
-rwxr-x--- 1 root root 2052704 May 19 2016 mt
```
This commit adds an explicit chmod on the binary to make sure uid/gid
tests can still run it as "others".
Automatic merge from submit-queue
Move b.gcr.io/k8s_authenticated_test to gcr.io/k8s-authenticated-test
**What this PR does / why we need it**:
Per https://cloud.google.com/container-registry/docs/support/deprecation-notices, b.gcr.io access will be deprecated soon.
I've already mirrored the repo to the location specified in this PR.
Automatic merge from submit-queue
Remove all MAINTAINER statements in the codebase as they are deprecated
**What this PR does / why we need it**:
ref: https://github.com/docker/docker/pull/25466
**Release note**:
```release-note
Remove all MAINTAINER statements in Dockerfiles in the codebase as they are deprecated by docker
```
@ixdy @thockin (who else should be notified?)
Automatic merge from submit-queue (batch tested with PRs 36626, 37294, 37463, 37943, 36541)
Use tmpfs for gluster-server container volumes.
Gluster server needs a filesystem that supports extended attributes for its data. Some distros (Debian, Ubuntu) ship Docker that runs containers on aufs, which does not support extended attributes and therefore Gluster server fails there.
We can use tmpfs for Gluster server data volumes. ~~This expects that host's /tmp is tmpfs, which is true for Debian, Ubuntu, RHEL, CentOS and Fedora.~~
I reworked it to mount tmpfs inside the container, the server pod is privileged.
And *after* this PR is merged and new Gluster server container image is pushed we need to bump the image version in https://github.com/kubernetes/kubernetes/blob/master/test/e2e/volumes.go#L407
Edit: I also fixed Gluster server Dockerfile, it was not working at all.
Gluster server needs a filesystem that supports extended attributes for its
data. Some distros (Debian, Ubuntu) ship Docker that runs containers on aufs,
which does not support extended attributes and therefore Gluster server fails
there.
We can use tmpfs for Gluster server data volumes instead of a directory inside
the container.
Automatic merge from submit-queue
Fixed gcloud command in logs-generator makefile
I grepped through the code looking for `gcloud` and `push` commands and only found one Makefile missing the `--`. I added it.
fixes#33765🐛
Automatic merge from submit-queue
test-images: server address is now configurable
This commit perform changes discussed in #32128
Should be merged before #35301
cc: @pskrzyns
We can then avoid the following warning:
```
WARNING: The '--' argument must be specified between gcloud specific args on the left and DOCKER_ARGS on the right. IMPORTANT: previously, commands allowed the omission of the --, and unparsed arguments were treated as implementation args. This usage is being deprecated and will be removed in March 2017.
This will be strictly enforced in March 2017. Use 'gcloud beta docker' to see new behavior.
```
Signed-off-by: Jess Frazelle <acidburn@google.com>
Automatic merge from submit-queue
Use ubuntu-slim to reduce size of the iperf:e2e image
from
```
gcr.io/google_containers/iperf e2e 8b3cc7064090 5 weeks ago 737.9 MB
```
to
```
gcr.io/google_containers/iperf e2e 204325491636 33 seconds ago 61.09 MB
```
related to https://github.com/kubernetes/kubernetes/pull/25784#issuecomment-221706886
ping @bprashanth
Automatic merge from submit-queue
IPerf container to support network perfomance testing
Simple iperf container.
Issue:
We want to run iperf from the e2e tests for a network baseline, but there are no gcr images for this.
Solution:
Curate our own iperf container from source in kubernetes and copy it as a top level microservice. So long as these are injected into GCR, we can then run this container from the e2e tests.
cc @sig-testing this can be used along side #22869
- document needed packages in hostexec image
- add RunHostCmdOrDie
- kube-proxy e2e: port from ssh to hostexec
- use preset NodeName to schedule test pods to different nodes
- parallel launch of pods
- port from ssh to hostexec
- add timeout because nc might block on udp
- delete test container without grace period
- PrivilegedPod e2e: port from ssh to hostexec
- NodePort e2e: port from ssh to hostexec
- cluster/mesos/docker: Enable privileged pods
Since this is a container service port anyways, "insecure" is a bit of
a red herring. There's no real security relevance to the incoming port
numbers for the NFS server pod.
This lets us get rid of the examples/nfs/exporter Docker build
(@jsafrane's personal image).
A lot of packages use StringSet, but they don't use anything else from
the util package. Moving StringSet into another package will shrink
their dependency trees significantly.
From RFC 3530:
During the grace period, the server must reject READ and WRITE operations
and non-reclaim locking requests (i.e., other LOCK and OPEN operations)
with an error of NFS4ERR_GRACE.
That basically means that all open() calls from clients are blocked until the
grace period is over (90 seconds by default).
We want the grace period as low as possible to speed up the tests. '10'
seconds were tested on Fedora 21 and Ubuntu 15.04 as the hosts.
The test image is rebased to Fedora in order to get 'rpc.nfsd -G <n>' option,
Ubuntu does not support it.
jennybuckley