【问题标题】:kubectl apply --dry-run behaving weirdlykubectl apply --dry-run 行为怪异
【发布时间】:2019-06-02 03:21:14
【问题描述】:

我在使用 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 向我输出具有 OLD 规范的资源

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

根据文档:

--dry-run=false:如果为true,则只打印要发送的对象,不发送。

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

在 minikube、gke v1.10.0 上测试

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

【问题讨论】:

  • 是的,我能够重现这种行为并且同样感到惊讶。可能是一个错误,但至少它是糟糕的用户体验。我在 SIG CLI 频道中留下了评论,也许有人看过它并知道这是否是预期的。
  • 此外,create 并没有显示这种行为并且输出是预期的。我为它创建了一个 github 问题
  • 这是个好主意,也许可以通过问题链接更新您的问题? FWIW,我怀疑apply 的三向合并语义在这里显示了奇怪的副作用,但让我们看看;)
  • @MichaelHausenblas 我试图了解使用 -v=10 检查跟踪是如何发生的,但我无处可去

标签: kubernetes kubectl minikube kubernetes-apiserver


【解决方案1】:

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

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

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

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

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

【讨论】:

  • @MichaelHausenblas
【解决方案2】:

客户端使用的最新版本:

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

【讨论】:

    猜你喜欢
    • 2021-01-24
    • 2018-05-02
    • 2018-06-14
    • 2019-03-01
    • 2018-04-24
    • 2022-12-27
    • 2021-03-27
    • 2020-04-02
    • 1970-01-01
    相关资源
    最近更新 更多