10

我正面临 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:如果为真,则只打印要发送的对象,不发送。

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

在 minikube 上测试,gke v1.10.0

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

4

2 回答 2

8

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

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

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

当前的努力旨在将应用逻辑移至服务器。作为其中的一部分,添加了空运行服务器端的能力。kubectl apply --server-dry-run会做你想做的事,打印应用合并的结果,而不是真正持久化它。

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

于 2019-01-07T16:05:24.193 回答
1

最新版本的客户端使用:

kubectl apply -f Deployment.yaml --dry-run=server
于 2021-11-17T18:25:30.097 回答