dry-run diff

虽然编译器（compiler）和质量器（linter）可以很好地检测代码拉取请求中的错误，但Kubernetes配置文件缺少良好的验证。现有的解决方案是运行kubectl apply –dry-run，但这会运行本地（local）干运行而不与服务器通信：它没有服务器验证，也没有通过验证许可控制器（validating admission controller）。例如，自定义资源名称仅在服务器上验证，因此本地干运行无济于事。

实施APIServer dry-run来解决这两个问题：

它允许对apiserver的个别请求标记为“dry-run”，
apiserver保证干运行请求不会被持久存储，
请求仍然作为典型请求处理：字段是默认的，对象是经过验证的，它通过验证准入链（validation admission chain），并通过变异准入链（mutating admission chain），然后最终的对象像往常一样返回给用户，没有被持久存储。
虽然动态准入控制器（dynamic admission controller）不应对每个请求产生副作用，但只有当所有准入控制器（admission controller）明确宣布它们没有任何干运行副作用时，才会处理干运行请求。

如何启用它
通过功能门（feature-gate）启用服务器端干运行。现在该功能在1.13中是Beta，默认情况下应该启用，但仍然可以使用kube-apiserver –feature-gates DryRun=true启用/禁用功能。

如果你有动态准入控制器，则可能必须将它们修复为：

当webhook请求中指定dry-run参数时，删除任何副作用，
在admissionregistration.k8s.io/v1beta1.Webhook对象的sideEffects字段中指定，指示该对象在干运行上没有副作用。
如何使用它
你可以使用kubectl apply –server-dry-run在kubectl触发该功能，它将使用dryRun标志装饰请求，并返回应用的对象，如果失败则返回错误。

Kubectl diff
APIServer dry-run很方便，因为它可以让你看到如何处理对象，但如果对象很大，很难准确识别出改变了什么。kubectl diff可以满足这方面的需要，通过显示当前“实时”对象与新“干运行”对象之间的差异。只关注对对象所做的更改，服务器如何合并这些更改，以及变异webhook如何影响输出，这非常方便。

如何使用它
kubectl diff希望与kubectl apply尽可能相似：kubectl diff -f some-resources.yaml将显示yaml文件中资源的差异。甚至可以使用KUBECTL_EXTERNAL_DIFF环境变量来使用他们选择的diff程序，例如：

KUBECTL_EXTERNAL_DIFF=meld kubectl diff -f some-resources.yaml

https://segmentfault.com/a/1190000017963633