Files
kubernetes/staging
Kubernetes Submit Queue 6fe7f9f4b7 Merge pull request #66391 from jennybuckley/dry-run-admission
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>.

Support dry run in admission plugins

**What this PR does / why we need it**:
Adds support for dry run to admission controllers as outlined by https://github.com/kubernetes/community/pull/2387

- [x] add IsDryRun() to admission.Attributes interface
- [x] add dry run support to NamespaceAutoProvision
- [x] add dry run support to ResourceQuota
- [x] add dry run support to EventRateLimit

The following is being done in a follow up PR:
- [x] add DryRun to ```admission.k8s.io/v1beta1.AdmissionReview```
- [x] add DryRunnable to ```admissionregistration.k8s.io/v1beta1.(Valid|Mut)atingWebhookConfiguration```
- [x] add dry run support to (Valid|Mut)atingAdmissionWebhook

/sig api-machinery

**Release note**:
```release-note
In clusters where the DryRun feature is enabled, dry-run requests will go through the normal admission chain. Because of this, ImagePolicyWebhook authors should especially make sure that their webhooks do not rely on side effects.
```

Here is a list of the admission controllers that were considered when making this PR:
- AlwaysAdmit: No side effects
- AlwaysPullImages: No side effects
- LimitPodHardAntiAffinityTopology: No side effects
- DefaultTolerationSeconds: No side effects
- AlwaysDeny: No side effects
- EventRateLimit: Has side possible effect of affecting the rate, skipping this entire plugin in dry-run case since it won't correspond to an actual write to etcd anyway
- DenyEscalatingExec: No side effects
- DenyExecOnPrivileged: Deprecated, and has no side effects
- ExtendedResourceToleration: No side effects
- OwnerReferencesPermissionEnforcement: No side effects
- ImagePolicyWebhook: No side effects* (*this uses a webhook but it is very specialized. It only sees pod container images, for the purpose of accepting or rejecting certain image sources, so it is very unlikely that it would rely on side effects.)
- LimitRanger: No side effects
- NamespaceAutoProvision: Has possible side effect of creating a namespace, skipping the create in the dry-run case
- NamespaceExists: No side effects
- NodeRestriction: No side effects
- PodNodeSelector: No side effects
- PodPreset: No side effects
- PodTolerationRestriction: No side effects
- Priority: No side effects
- ResourceQuota: Has side possible effect of taking up quota, will only check quota but skip changing quota in the dry-run case
- PodSecurityPolicy: No side effects
- SecurityContextDeny: No side effects
- ServiceAccount: No side effects
- PersistentVolumeLabel: No side effects
- PersistentVolumeClaimResize: No side effects
- DefaultStorageClass: No side effects
- StorageObjectInUseProtection: No side effects
- Initializers: No side effects
- NamespaceLifecycle: No side effects
- MutatingAdmissionWebhook: Same as below
- ValidatingAdmissionWebhook: Has possible side effects depending on if webhook authors depend on side effects and a reconciliation mechanism. To fix this we will expose whether or not a request is dry-run to webhooks through AdmissionReview, and require that all called webhooks understand the field by checking if DryRunnable true is specified in the webhook config. This will be done in a separate PR because it requires an api-change
2018-08-06 17:51:21 -07:00
..
2018-06-22 16:22:57 -07:00
2017-10-19 15:46:36 +01:00

External Repository Staging Area

This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.

Repositories currently staged here:

The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.

Using staged repositories from Kubernetes code

Kubernetes code uses the repositories in this directory via symlinks in the vendor/k8s.io directory into this staging area. For example, when Kubernetes code imports a package from the k8s.io/client-go repository, that import is resolved to staging/src/k8s.io/client-go relative to the project root:

// pkg/example/some_code.go
package example

import (
  "k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)

Once the change-over to external repositories is complete, these repositories will actually be vendored from k8s.io/<package-name>.