kubectl apply --dry-run 表现异常

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

- GalloCedrone

---

是的，我能够重现这种行为并感到同样惊讶。可能是一个bug，但至少它会影响用户体验。我在SIG CLI频道留了一条评论，也许有人会看看并知道这是否符合预期。 - Michael Hausenblas

此外，使用 create 方法时不会出现这种行为，输出结果也是预期的。我已经在 GitHub 上创建了一个问题报告。 - GalloCedrone

这是个好主意，也许你可以更新一下你的问题并附上一个链接？顺便说一句，我怀疑apply的三路合并语义在这里会产生奇怪的副作用，但我们拭目以待 ;) - Michael Hausenblas

@MichaelHausenblas 我尝试通过使用 -v=10 命令来检查跟踪信息以理解发生了什么，但是我没有任何进展。 - GalloCedrone

Answer 1

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

当更新现有对象时，kubectl apply不会发送整个对象，而只是一个补丁。在dry-run模式下打印现有对象或新对象都不完全正确...合并的结果应该被打印出来。

为了使 kubectl 能够准确地反映出 apply 的结果，它需要在客户端具备服务器端的 apply 逻辑，这不是一个目标。

目前的努力方向是将 apply 逻辑移动到服务器端。作为其中的一部分，已经添加了在服务器端进行 dry-run 的能力。`kubectl apply --server-dry-run` 将会做你想要的事情，打印出 apply 合并的结果，但不会实际持久化它。

@apelisse 我们可能需要更新 apply 的标志帮助，并在使用 `--dry-run` 更新对象时打印警告，以记录 `--dry-run` 的限制，并引导人们使用 `--server-dry-run`。

- GalloCedrone

---

@MichaelHausenblas - GalloCedrone

Answer 2

最新版本的客户端使用：

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

- Charles Gravlee