APIServer dry-run和kubectl diff
作者：Antoine Pelisse（Google Cloud，@apelisse）
声明式（Declarative）配置管理，也称为配置即代码（configuration-as-code），是Kubernetes的关键优势之一。它允许用户提交所需的集群状态，并跟踪不同的版本，通过CI/CD管道改进审计和自动化。Apply工作组正在努力修复一些差距，而很高兴地宣布Kubernetes 1.13将服务器端干运行（server-side dry-run）和kubectl diff升级到beta。这两个特性是Kubernetes声明模型的重大改进。
挑战
为了在Kubernetes保持无缝的声明体验，仍然缺少一些部分，我们试图解决其中的一些问题：
- 虽然编译器（compiler）和质量器（linter）可以很好地检测代码拉取请求中的错误，但Kubernetes配置文件缺少良好的验证。现有的解决方案是运行kubectl apply --dry-run，但这会运行本地（local）干运行而不与服务器通信：它没有服务器验证，也没有通过验证许可控制器（validating admission controller）。例如，自定义资源名称仅在服务器上验证，因此本地干运行无济于事。
- 由于多种原因，很难知道服务器将如何应用你的对象：
- 默认会将某些字段设置为潜在的意外值，
- 变异（mutating）webhook可能会设置字段或更改某些值，
- 修补（patch）和合并（merge）可能会在对象产生令人惊讶的效果和导致意外。例如，一旦合并，很难知道列表将如何排序。
工作组试图解决这些问题。
APIServer dry-run
实施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
接下来是什么
工作组仍在忙着改进其中一些事情：
- 服务器端应用试图通过向字段添加所有者语义来改进应用（apply）方案！它还将改善对CRD和工会的支持！
- diff中缺少某些kubectl apply可能很有用的功能，例如按标签过滤或显示已修剪资源的功能。
- 最终，kubectl diff将使用服务器端应用！