APIServer dry-run and kubectl diff

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: While compilers and linters do a good job to detect errors in pull-requests for code, a good validation is missing for Kubernetes configuration files. The existing solution is to run 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. It can be difficult to know how your object is going to be applied by the server for multiple reasons:Defaulting will set some fields to potentially unexpected values,Mutating webhooks might set fields or clobber/change some values. Patch and merges can have surprising effects and result in unexpected objects.

For example, it can be hard to know how lists are going to be ordered once merged.

Source: kubernetes.io