Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
Author: Antoine Pelisse (Google Cloud, @apelisse)
Declarative configuration management, also known as configuration-as-code, is
one of the key strengths of Kubernetes. It allows users to commit the desired state of
the cluster, and to keep track of the different versions, improve auditing and
automation through CI/CD pipelines. The Apply working-group
is working on fixing some of the gaps, and is happy to announce that Kubernetes
1.13 promoted server-side dry-run and kubectl diff
to beta. These
two features are big improvements for the Kubernetes declarative model.
A few pieces are still missing in order to have a seamless declarative experience with Kubernetes, and we tried to address some of these:
kubectl apply --dry-run
, but this runs a
local dry-run that doesn't talk to the server: it doesn't have server
validation and doesn't go through validating admission controllers. As an
example, Custom resource names are only validated on the server so a local
dry-run won't help.The working group has tried to address these problems.
APIServer dry-run was implemented to address these two problems:
While dynamic admission controllers are not supposed to have side-effects on each request, dry-run requests are only processed if all admission controllers explicitly announce that they don't have any dry-run side-effects.
Server-side dry-run is enabled through a feature-gate. Now that the feature is
Beta in 1.13, it should be enabled by default, but still can be enabled/disabled
using kube-apiserver --feature-gates DryRun=true
.
If you have dynamic admission controllers, you might have to fix them to:
sideEffects
field of the admissionregistration.k8s.io/v1beta1.Webhook
object to indicate that the object doesn't have side-effects on dry-run (or at all).You can trigger the feature from kubectl by using kubectl apply --server-dry-run
, which will decorate the request with the dryRun flag
and return the object as it would have been applied, or an error if it would
have failed.
APIServer dry-run is convenient because it lets you see how the object would be
processed, but it can be hard to identify exactly what changed if the object is
big. kubectl diff
does exactly what you want by showing the differences between
the current "live" object and the new "dry-run" object. It makes it very
convenient to focus on only the changes that are made to the object, how the
server has merged these and how the mutating webhooks affects the output.
kubectl diff
is meant to be as similar as possible to kubectl apply
:
kubectl diff -f some-resources.yaml
will show a diff for the resources in the yaml file. One can even use the diff program of their choice by using the KUBECTL_EXTERNAL_DIFF environment variable, for example:
KUBECTL_EXTERNAL_DIFF=meld kubectl diff -f some-resources.yaml
The working group is still busy trying to improve some of these things:
Note: The flagkubectl apply --server-dry-run
is deprecated in v1.18. Use the flag--dry-run=server
for using server-side dry-run inkubectl apply
and other subcommands.