抄送@ironcladlou @bgrant0607

在不更改规范的情况下重新启动 Pod 的用例是什么？

请注意，如果 pod 在重新启动时开始失败，则没有任何方法可以回滚更改。

每当服务进入某种楔入或不良状态时（连接最大化并现在停止，内部状态不佳等）。 如果服务行为严重不正常，这通常是第一个故障排除步骤之一。

如果第一个 pod 在重新启动时失败，我希望它停止继续或继续重试以启动 pod。

此外，没有规范更改的滚动重启会在整个
簇。

但是，我也希望能够在不重新安排
豆荚。 这可能是滚动标签更改，但可能会带来新的动态
配置或清除本地文件状态。

2015 年 9 月 2 日星期三上午 12:01，Sam Ghods [email protected]写道：

每当服务进入某种楔入或不良状态（最大化
连接并且现在已停止、内部状态不佳等）。 通常是
如果服务严重，则首先进行故障排除的步骤之一
行为不端。

如果第一个 pod 在重新启动时失败，我希望它会停止
继续或继续重试以启动 pod。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

克莱顿科尔曼 | OpenShift 首席工程师

@smarterclayton像我上面列出的选项 2 吗？ 虽然为什么标签会改变？

关于。 楔形：这就是活性探针的用途。

关于。 重新平衡：见 #12140

如果我们确实支持这一点，我会将其与 #9043 混为一谈——需要相同的机制。

我想这更适用于 pod 处于活动状态并响应检查但仍需要重新启动的情况。 一个示例是具有内存缓存或内部状态的服务已损坏并需要清除。

我觉得要求重新启动应用程序是一个相当常见的用例，但也许我是不正确的。

腐败只是一个吊舱，它可以被 RC 杀死并取代。

离线提到的另一种情况是重新读取配置。 隐式这样做很危险，因为出于任何原因重新启动都会导致容器加载新配置。 最好进行滚动更新以将新版本的配置引用（例如在 env var 中）推送到 pod。 这类似于#1353 的动机。

@bgrant0607我们决定不想这样做了吗？

@gmarek 暂时没有。 太多的事情已经在进行中。

我们能否为我们认为重要的事情制定一个post v1.1里程碑（或其他什么），但我们缺乏立即修复它们的人？

我也会喜欢这个功能，你不想被迫为你想要推出的每个小更新切换标签。

我是这个功能的粉丝。 用例：轻松升级所有 pod 以使用新推送的 docker 镜像（使用imagePullPolicy: Always ）。 我目前使用了一些 hacky 解决方案：在图像名称上带有或不带有:latest标签的滚动更新。

另一个用例：更新机密。

我真的很想看到这个功能。 我们在 kubernetes 上运行节点应用程序，目前有一些用例，我们重新启动 pod 以清除应用程序伪缓存。

这是我现在正在做的事情：

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

这会一次删除 Pod 10，并且在复制控制器设置中运行良好。 它没有解决任何问题，例如 pod 分配或新 pod 无法启动。 这是在需要时的快速解决方案。

我真的很想能够进行滚动重启。
主要原因是我们将使用 ConfigMap 将 ENV 变量提供给 Pod，然后如果我们更改配置，我们需要重新启动该 ConfigMap 的使用者。

是的，在很多情况下，您真的想重新启动 pod/容器而不更改内部...
配置、缓存、重新连接到外部服务等。我真的希望能开发这个功能。

小工作（我使用部署，我想更改配置而不对图像/pod 进行真正的更改）：

• 创建配置映射
• 在任何容器中使用 ENV 变量创建部署（您将使用它作为部署的指示器）
• 更新配置映射
• 更新部署（更改此 ENV 变量）

k8s 将看到部署的定义已更改，并将开始更换 pod 的过程
PS：
如果有人有更好的解决方案，请分享

谢谢@paunin

@paunin这正是我们目前需要的情况 - 我们必须更改对服务非常重要的 ConfigMap 值，并且需要在几分钟到几小时内推出到容器中。 如果在此期间没有部署，容器将同时失败，我们将有至少几秒钟的部分停机时间

来自（有点相关的 #9043）： @paunin方法的RESTART_是环境变量，它被设置为 ISO 时间戳：

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

（注意，由于某些原因，以_开头的环境变量似乎消失了，而数字 env value会导致错误，它们需要是字符串）

@paunin @rcoup我们现在做了一些非常相似的事情，我们有一个字面称为“DUMMY_VAR_FOR_NO_OP_DEPLOYMENT”的环境变量。

感觉这里的正确解决方案将使您能够重新启动部署，并为 MinReadyCount 之类的部署重用大部分部署参数，同时允许命令行覆盖，例如在紧急情况下增加并行度，在这种情况下，您需要一切都立即反弹。

这方面有什么进展吗？

我觉得这个添加是 CLI API 不必要的膨胀。 这可以通过更新@paunin 建议的部署环境变量值来轻松实现。

我们也希望在部署中看到这个，可能像kubectl restart deployment some-api

Kubernetes 可以出于各种原因重启 Pod，但集群管理员不允许。
我理解“关闭并再次打开”的道德立场可能不是一种理想的操作方式......但我也认为让那些希望重新启动部署而不诉诸范围的人应该可以不那么开胃的技巧，例如：

• 删除豆荚
• 虚拟标签
• 虚拟环境变量
• 映射到环境变量的虚拟配置映射
• 重新启动工作节点
• 切断数据中心的电源😄

'不，不，我不会重新启动任何东西，只是在这里更正此标签中的错字' 😛

此功能与kubectl apply配对时很有用： apply将更新配置，包括复制控制器，但不会重新启动 pod。

所以我们需要一种方法以蓝绿方式重启这些 pod。

@DmitryRomanenko从 ReplicationControllers 切换到 Deployments 怎么样？ 这将使您能够运行 ReplicaSets（ReplicationController 的后继者）的更新。

@kargakis这是不可能的：部署仅更新副本集和 Pod。
使用kubectl apply我们还更新了 ConfigMaps、Services 等。

@DmitryRomanenko如果问题是“我想在 ConfigMap/Secret 更新时重新启动kubectl apply更改部署规范并重新创建 Pod。
在其他情况下，我不明白为什么必须重新启动 Pod（我的意思是服务/入口/等更新）。

@tyranron ，谢谢！ 版本ConfigMap的最佳方法是什么？ 我应该为新部署创建具有不同名称的新配置映射吗？

@DmitryRomanenko你真的可以，为什么不呢？ 但在这种情况下，您应该注意删除旧的。 另一方面，它可能对回滚有用。 但在大多数情况下，通过标签指定版本就足够了。

我确实相信这里最好的解决方案可能是configmap对象上的某种观察器或哈希和检查器。 这应该触发相关的对象/豆荚重启（任何使用configmap ， secret ）。 不确定它是否可以在k8s架构中访问...

我还认为最好控制configmap|secret对象以触发更改或不重新启动。

@暴龙，

因此，使用 kubectl 应用部署的规范已更改并重新创建 Pod。

你能解释一下吗？ 我是否应该只对更新的部署使用kubectl apply -f new_config.yml ，并且这些部署将滚动重启？

@DmitryRomanenko 是的，

@DmitryRomanenko应用您正在更新 Deployment 的新规范，如果其规范发生更改，则会触发 Deployment 更新重新启动。

默认情况下，重启策略是RollingUpdate ，但您也可以明确指定另一个。

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

使用/lifecycle frozen注释防止问题自动关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或@fejta发送反馈。
/生命周期陈旧

对@rcoup的解决方案的一个小改动：确保date在 shell 中被评估：

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/remove-lifecycle 陈旧
/生命周期冻结

使用 Swarm 模式已经有一段时间了，这被认为不如 Kubernetes 灵活，我能够重新启动服务任务（阅读：部署 Pod），只需像docker service update --force <service-name>一样执行强制更新（不更改规范）
至于 configmaps 和 secrets，swarm 不允许你编辑它们，你需要轮换它们。 为此，您可以创建新的配置映射/秘密，更新服务规范以使用新的，然后删除旧的。 我看到这通常是上面推荐的，方法是对您的 configmaps/secerts 进行版本控制并更新使用它们的部署。 老实说，这种轮换行为是我离开 swarm 的一个主要原因！ 有一个本地副本，更新然后创建新资源，最后更新依赖的资源是非常不方便的。 除此之外，swarm 中的秘密无法从 api 中读取，您必须将它们安装在任何容器中（或在使用它们的容器中执行），然后cat文件。
在相关说明中，我使用 openshift 有一段时间了，我相信它会在 env/configmap/secret 更改时自动重新启动 pod？ 不过我站得更正。

应该是应用程序负责监视文件系统的更改，如前所述，您可以在 configmap/secret 上使用校验和并以这种方式强制重新启动

但是，如果您根本不想更改配置而只是在任意暂停的情况下进行滚动重启，那么一个简单的管道就可以完成这项工作（这个管道在终止的 pod 之间休眠 30 秒）

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

请注意，如果按 ctrl+c，则不容易从上次中断的地方重新启动

@so0k ，替代命令：

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

两年半过去了，人们仍在制定新的解决方法，使用虚拟环境变量、虚拟标签、ConfigMap 和 Secret watcher sidecar，缩放为零，以及直接滚动更新 shell 脚本来模拟触发滚动更新的能力。 如果没有技巧，这仍然不应该允许集群管理员诚实地做吗？

27081 #33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

另一个技巧是最初运行：

kubectl set image deployment/my-deployment mycontainer=myimage:latest

进而：

kubectl set image deployment/my-deployment mycontainer=myimage

它实际上会触发滚动更新，但请确保您还设置了 imagePullPolicy:“Always”。

我发现的另一个技巧（您不必更改图像名称）是更改将触发滚动更新的字段的值，例如终止 GracePeriodSeconds。 您可以使用 kubectl edit deployment your_deployment 或 kubectl apply -f your_deployment.yaml 或使用如下补丁来执行此操作：

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@so0k @KIVagant删除 pod 意味着停机，即使在运行多个实例时也是如此。 当有人使用strategy.rollingUpdate.maxUnavailable = 0运行单个 pod 时，常规部署首先创建一个新 pod，然后终止现有的 pod。 kubectl patch deployment技巧会触发此行为，而删除 Pod 则不会。 我真的很喜欢一种非hacky的方式来按需触发这种行为。

例如，当从 hub.docker.com 运行图像时，可以修补相同的标签以进行安全更新。 我真的很想“拉取最新的图像”，并对任何过时的图像执行滚动更新。

ConfigMap/Secret 更新的推出是 #22368
更容易推出新图像是 #1697
就地滚动更新是 #9043

重新启动镜像构建： https :
Helm 峰会演示了使用模板化注释触发部署部署的技巧： https :

@bgrant0607我认为其他票证未涵盖的重要用例是这个： https :

@ghodss写道：
我想这更适用于 pod 处于活动状态并响应检查但仍需要重新启动的情况。 一个示例是具有内存缓存或内部状态的服务已损坏并需要清除。

我觉得要求重新启动应用程序是一个相当常见的用例，但也许我是不正确的。

我想强制滚动重启以清除所有应用程序状态，而无需手动操作。

基于@rcoup和@paunin描述的方法，我有一个类似的

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

这允许我说： kubectl-restart my-deployment-name并且它会将第一个容器中的RESTART_变量“更新”为当前时间戳。 我远不是 jq 专家，所以可能有更好的方法来做到这一点，但基本上它会从输出中删除旧的RESTART_ env var（如果存在），然后将其添加回那里当前时间。

我确实觉得很奇怪，但没有本地方法可以做到这一点......当然，一个充满工程师的房间会同意“关闭并重新打开”的能力是我们想要的东西。

这是一个很好的技巧，但它有很大的缺点。 下次使用kubectl apply -f部署时，如果该组件具有 RESTART_xxx 环境变量，即使没有其他任何更改，该组件也会重新启动。 换句话说，如果在上次部署和本次部署之间重新启动过，它会在下一次部署时导致虚假重新启动。 不理想...

这就是为什么滚动重启功能应该嵌入到部署控制器中，而不是构建在顶部。

我写了一个 bash 函数来完成上面他的评论中引用的“ terminationGracePeriodSeconds补丁部署”策略@whereisaaron （来源：https:

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

通过这里的

仅作为与 kube 相关的更具体的理由，restart 还允许重新运行 init-container，它可用于滚动密钥、更新配置或任何您使用 init 容器的目的。

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro您应用的配置中是否有 RESTART_xxx 环境

抄送@apelisse

@gjcarneiro是的， @mattdodge脚本的问题在于它正在使用 apply，因此更改将保存在 lastApplied 注释中。 可以通过使用补丁或其他方法来更新部署来修复脚本。

很想拥有这个功能。 它似乎非常基本和需要。

这里和 #22368 都没有进展，叹息 :-(

任何人都可以推荐一个快速而肮脏的解决方案来在安装的 ConfigMap 更新后重新启动 DaemonSet（名称仍然相同）？

@alcohol ，检查这个https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

谢谢你的提示 ：-）

Openshift 有部署触发器的概念，它会触发映像更改、Webhook 或配置更改的推出。 在 Kubernetes 中拥有这将是非常好的功能。 当然还有手动部署。

此外，Docker 存储库有历史记录，因此没有理由回滚无法工作 - 从.spec.template产生的 pod 在为容器提取图像时可以使用image-tag:@digest格式。 回滚将使用上一次推出的摘要 ID。

不确定我是否理解正确。 以防万一这对任何人都有帮助。

看来，如果你在 pod > template > metadata 下更新标签的值，那么在你kubectl apply -f file.yaml之后会发生滚动更新

因此，您始终可以为您的版本添加标签，并且无论何时您想要滚动更新，都可以更改版本并应用文件。

当然，缺点是下次你想做部署时，你做kubectl apply -f some.yaml ，对吧？ 通常，如果some.yaml没有任何变化，则不会重新启动，这是 Kubernetes 最好的事情之一。

但是想象一下在您更改标签以重新启动部署后会发生什么。 在下一次正常的软件部署中，您像往常一样执行kubectl apply -f some.yaml ，但由于 yaml 文件不包含相同的标签，因此部署将不必要地重新启动。

@gjcarneiro如果您在进行更改时没有apply ，则kubectl.kubernetes.io/last-applied-configuration注释将不会更新，因此下一个apply不会导致再次重新启动。

我强烈支持向 kubectl 添加滚动重启命令，但同时我正在使用以下内容（基于上述解决方案）：

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

将此参数化并将其作为函数添加到 .bashrc 中，这是一个很好的临时解决方案。

啊，酷，我不知道，谢谢！

我不需要 bash 别名，在我的公司，我们使用 Python+aiohttp 制作了自己的 Web 界面来管理 Kubernetes，并且它已经使用了补丁。 我想开源它，只是懒惰......

看起来人们在此线程中重复相同的解决方法 - 请在此处发布之前阅读完整的线程

@joelittlejohn我运行了你的宏，它确实触发了我的 pod 重新启动，但它们都同时重新启动。 我以为这会触发滚动重启，不是吗？

@Macmee这取决于您的部署配置。 上面的命令只是改变了部署。 然后根据部署定义的推出strategy更新 pod。 这就像部署的任何其他更改一样。

同时替换所有 pod 的唯一方法是您的.spec.strategy.rollingUpdate.maxUnavailable允许它。

我们也有点需要这个功能。 我们这边的一个用例是我们使用 spring-cloud-config-server 和 scm 支持，用于我们的 spring-boot 应用程序。 当我们更改配置属性时，需要重新启动 spring-boot 应用程序才能获取新的配置更改，因此我们还需要这种优雅的重启触发器而无需重新部署。

@japzio正如Helm所

是否有任何更新？ 我们也希望拥有此功能。 @bgrant0607 @nikhiljindal

@bholagabbar-mt 你的用例是什么？

抄送@kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo我们系统的用例是多方面的。

1. 秘密更新 - 我相信你已经意识到有很多像我这样的公司，已经在 kubernetes 上构建了自己的抽象。 我们有自己的容器管理系统，它是在 kubernetes 上编排的。 所以helm secret 建议评论等不适用。 要从开发集群中的 ConfigMaps 重新加载机密，我们必须强制杀死 pod，从而导致几秒钟的停机时间。 这不应该是这种情况。 这是滚动更新的真实用例。

2. 这有点复杂，但正如有人建议的那样，总体范围是修复异常行为。 我们有 4-5 个在 Play 框架上运行的重型 Java 应用程序。 我们遇到了这样一种情况，我们的 java pod 的内存消耗线性上升，然后在达到内存限制时重新启动 pod。 这是一个记录在案的 Java 问题，其中包含一个stackoverflow 问题和与之相关的

希望这足够令人信服，并且有人可以使用此功能进行开发？

@bholagabbar-mt 只需更改一个环境变量，它就会触发滚动部署：

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn这太完美了。 我们今天将这一变化集成到我们的系统中，并且运行良好。 万分感谢！

cc @huzhengchuan

另一个用例：由于 containerd 中的安全问题，我想重新启动所有 pod。 https://seclists.org/oss-sec/2019/q1/119要么集群完全关闭，要么滚动重启。 有一个重启命令会产生巨大的不同！

更新，解决方法：

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh你是最佳实践。 在牧场主中添加annotation:{creatTime: 12312312} ！

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

似乎是完成一次部署工作的最小命令。 它是使用命令式配置的示例。

抄送@monopole @apelisse

~两年~三年半过去了，人们仍在制定新的解决方法，包括虚拟环境变量、虚拟标签、虚拟注释、ConfigMap 和 Secret watcher sidecars，缩放到零，以及直接滚动更新 shell 脚本来模拟这种能力触发滚动更新。 如果没有技巧，这仍然不应该允许集群管理员诚实地做吗？

对于显然没有用例的东西来说，滚动更新仍然是一个非常受欢迎的活动 😄

长期问题（自我说明）

1. 我看不出有什么方法可以在不让命令式逻辑融入声明式 API 的情况下做到这一点，从而打破我们保持 API 声明式并在控制器中实现命令式行为的惯例，并引入与大多数 CI/CD 实践的不兼容。
2. 我可以想象一个 RollingRestart API 和控制器，其中 RollingRestart 资源的创建导致控制器通过逐出（因此尊重中断预算）重新启动 Pod 1，但这样的控制器可以作为 CRD 实现（即我知道原因我们必须在树中执行此操作）。
3. 声明性方法，例如添加 lastRestartedAt=TIMESTAMP 注释对我来说似乎不是一个黑客。
4. 如果有人想提供声明性设计和贡献来实现此功能（以树或其他方式），请考虑针对增强存储库编写 KEP PR。 如果可以设计声明性的、内置的实现，我很乐意在工作负载 API 中审查/指导。 如果提供了像 [2] 这样的 CRD 控制器，我们可以在 SIG Apps 中赞助它作为社区赞助的扩展。

声明性方法，例如添加 lastRestartedAt=TIMESTAMP 注释对我来说似乎不是一个黑客。

这不是黑客，应该只是一个简写的命令行。

有人可以构建一个发送补丁的krew插件。 kubectl restart-deployment <deployment_name> ?

kubectl rollout restart修补部署/守护进程集/状态集以触发新的“推出”？

这与@kow3ns的方法 (3) 一致，并且有一定道理，因为您可以观看/暂停/恢复您刚刚使用其他kubectl rollout命令开始的部署。

@whereisaaron我会看看我是否可以为此发送补丁（双关语不是故意的）

对于推出新的秘密和配置映射，我的建议仍然是#22368：创建新的。 这为控制推出和回滚提供了一种方法。 我们只需要完成旧对象的 GC：
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

不过，记录和/或支持（在 kustomize、kubectl 或 kubectl 插件中）使用现有 API 进行滚动重启的推荐方法是合理的。

抄送@monopole

至于新镜像，CI/CD 或解析标签以进行摘要的控制器：#1697。

移动不愉快的 Pod 是由 descheduler (https://github.com/kubernetes-incubator/descheduler) 或类似的东西来执行的，它可以消耗容器状态、核心指标，甚至自定义指标：

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

此外，关于如何处理机密和配置映射的官方文档： https ://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

滚动重启是非常需要的。 第一个示例是我们从 AWS 的 SSM 中获取所有机密。 如果我们从 SSM 中更改一些秘密，我们希望进行滚动重启，以便 pod 现在在启动时选择最新的。 有时也有应用程序问题需要滚动重启，直到实际修复登陆生产。

好的， kubectl rollout restart已经合并了！

在将近 4 年后听到这个消息真是太好了，谢谢！

我相信合并的 PR 只支持部署，对吗？

此问题中的一些人也表示需要重新启动守护进程集和状态集。

@apelisse有没有办法通过 sdk 或只是 kubectl 来做到这一点？

@e-nikolov SDK 是什么？

我指的是 Go 客户端，可用于从 Go 程序与 kubernetes 对话。

不，您必须重新实现在 kubectl 中实现的（非常简单的）逻辑。

OK，kubectl rollout restart 已经合并了！

什么kubectl版本会有它？

哪个 kubectl 版本会有它？

Kubernetes 1.15

我们在“快速”发布频道上的 GKE 集群已升级到 Kubernetes 1.16，现在kubectl rollout restart已停止工作：

kubectl rollout restart 部署 myapp
错误：未知命令“重新启动部署 myapp”

@nikhiljindal 不久前询问了在不更改规范的情况下更新部署的用例。 也许我们以一种非最优的方式来做这件事，但它是这样的：我们预先训练的 ML 模型从 Google Cloud Storage 加载到内存中。 当模型文件在 GCS 上更新时，我们希望重新启动我们的 K8S 部署，这会从 GCS 中提取模型。

我很感激我们无法轻松回滚以前的模型文件的部署，但这是我们采用的权衡使模型尽可能靠近应用程序并避免网络调用（如某些人可能建议的那样）。

嘿@dimileeh

你碰巧知道你现在使用的是什么版本的 kubectl 吗？ 你以前用过什么版本？ 我很想知道是否有回归，但同时如果该功能完全消失，我会感到惊讶。

关于 GCS 的事情，并且对您的用例知之甚少，如果它没有意义，那么抱歉：我建议 gcs 模型每次修改时都使用不同的名称（可能是其哈希后缀），并且该名称将包含在部署中。 更新部署以使用新文件将自动触发推出。 这使您能够回滚到以前的部署/模型，更好地了解模型发生的更改等。

嗨@apelisse ，感谢您的回复！

当我从 Google Cloud Terminal 运行kubectl version ，我得到以下信息：

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

当我尝试通过gcloud components update升级 kubectl 时，它说我已经在使用所有产品的最新版本。 因此，我认为我的 kubectl 版本保持不变，而 K8S 集群从 1.15 升级到 1.16。

Kubenetes 文档 1.17、1.16 和 1.15 没有关于kubectl rollout restart功能的内容。 所以我想知道你的宝贵贡献是否会从 1.16 中消失？

感谢您对模型版本控制的建议，这很有意义。 我们考虑过这一点，但后来，由于我们每天都重新训练我们的模型，我们认为我们会开始积累太多模型（而且它们非常繁重）。 当然，我们可以在一段时间后使用一些脚本来清理旧版本，但到目前为止，我们决定保持简单，依靠kubectl rollout restart而不关心模型版本控制 :)

我可以在这里看到文档：
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

啊，谢谢，我正在看：
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

非常感谢你的链接，我会确保它得到更新！

2019 年 12 月 19 日星期四下午 12:40 Dmitri Lihhatsov [email protected]
写道：

啊，谢谢，我正在看：
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63KLDNX56WWW63KDNNX520000000000000000000000000000002520000000000000000000000000000005同中
或退订
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 （一旦合并，我将在相关分支中挑选）。

@dimileeh我想我知道你的 kubectl 版本有什么问题，我们会努力解决的。

是的，我们也有在更新 configmap 后无需更改代码即可重新启动 pod 的用例。 这是为了在不重新部署服务的情况下更新 ML 模型。

@anuragtr带有您可以运行的最新版本

kubectl rollout restart deploy NAME

我正在为此使用自定义命令 [1]，很高兴它现在在标准 kubectl 中！ 谢谢

[1] https://github.com/mauri870/kubectl-renew

@anuragtr带有您可以运行的最新版本

kubectl rollout restart deploy NAME

@countrogue