kubectl 推出状态 - 命令何时完成?

qkh*_*pro 2 kubernetes kubectl

目前我正在我的管道中使用它

kubectl apply -f deployment.yaml && kubectl rollout status -f deployment.yaml
Run Code Online (Sandbox Code Playgroud)

在 yaml 中使用这个

      readinessProbe:
        tcpSocket:
          port: 90
        initialDelaySeconds: 120
        periodSeconds: 10
        timeoutSeconds: 10
        failureThreshold: 1
        successThreshold: 1
      livenessProbe:
        tcpSocket:
          port: 90
        initialDelaySeconds: 120
        periodSeconds: 20
        timeoutSeconds: 2
        failureThreshold: 1
        successThreshold: 1
Run Code Online (Sandbox Code Playgroud)

对我来说,kubectl rollout 运行了很长时间,阻塞了部署管道。从文档中

默认情况下,“推出状态”将监视最新推出的状态,直到完成

我的问题:

1/ 哪些操作是有助于部署“直到完成”的部分(资源创建、资源拆卸?...)

2/ readinessProbe 和 livenessProbe 是否会影响部署时间

Dav*_*aze 7

其标准在源代码kubectl。如果满足以下条件,则部署“完成”:

\n
    \n
  • 还没有超时
  • \n
  • 其更新的副本数至少是其所需的副本数(每个新 Pod 均已创建)
  • \n
  • 它的当前副本数最多是其更新的副本数(每个旧 Pod 都已被销毁)
  • \n
  • 其可用副本数至少等于其更新副本数(每个新 Pod 都在运行)
  • \n
\n

您可以实时使用kubectl get deployment -w或观看实际发生的部署;kubectl get pod -wkubectl get -w选项监视给定的资源,并在它们发生更改时打印出新行。您将看到发生以下序列(使用默认部署设置,一次一个用于“小型”部署):

\n
    \n
  1. 创建了一个新的 Pod
  2. \n
  3. 新 Pod 通过探测器并准备就绪
  4. \n
  5. 旧 Pod 已终止
  6. \n
  7. 旧的 pod 实际退出并被删除
  8. \n
\n

因此,为了kubectl rollout status deployment/...完成,所有这些步骤都必须发生 \xe2\x80\x93 创建新的 pod,新的 pod 全部通过健康检查,为部署中的每个副本销毁旧的 pod \xe2\x80\x93。

\n

  • 很好的解释。此外,回答 OP 关于就绪性和活性探针的问题:就绪性探针确实会对部署推出时间产生影响。因为只有在就绪探测成功完成后,Pod 才被视为就绪。然而,livenessprobe 的目的是确定 pod 是否仍然健康。所以通常它不会影响推出时间。但是,如果在更新所有其他 Pod 之前 Pod 变得不健康,则会创建一个新的 Pod,从而影响整体部署时间 (2认同)