库贝克特尔应用--干运行行为怪异

Question

我正面临着 kubectl 和 --dry-run 的奇怪行为。

为了简化起见，假设我有以下yaml文件：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginxsdf
        imagePullPolicy: Always
        name: nginx

例如修改映像或副本数量：

• kubectl apply -f Deployment.yaml -o yaml --dry-run输出我具有旧规范的资源

• kubectl apply -f Deployment.yaml -o yaml输出我具有新规范的资源

根据文档：

--

dry-run=false：如果为 true，则只打印要发送的对象，而不发送它。

但是，打印的对象是旧的，而不是将发送到 ApiServer

的对象

在 minikube， gke v1.10.0 上测试

与此同时，我为它打开了一个新的gitHub问题：

• https://github.com/kubernetes/kubernetes/issues/72644

Answer 1

我在 kubernetes 问题页面中得到了以下答案：

更新现有对象时，kubectl apply 不会发送整个对象，只会发送一个补丁。在干运行模式下打印现有对象或新对象并不完全正确......合并的结果是应该打印的内容。

为了使 kubectl 能够准确反映应用的结果，它需要让服务器端应用逻辑客户端，这是一个非目标。

当前的工作旨在将应用逻辑移动到服务器。作为其中的一部分，添加了在服务器端干运行的功能。 kubectl apply --server-dry-run将执行您想要的操作，打印应用合并的结果，而无需实际保留它。

@apelisse 我们可能应该更新应用标志帮助，并在使用 --dry-run 时打印警告，当通过应用更新对象时，记录 --dry-run 的限制并指导人们使用 --server-dry-run

Answer 2

最新版本的客户端使用：

kubectl apply -f Deployment.yaml --dry-run=server