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
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:
k8s.io/apiextensions-apiserverk8s.io/apik8s.io/apimachineryk8s.io/apiserverk8s.io/client-gok8s.io/kube-aggregatork8s.io/code-generatork8s.io/metricsk8s.io/sample-apiserverk8s.io/sample-controller
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>.