cc @ironcladlou @bgrant0607

Whats the use case for restarting the pods without any changes to the spec?

Note that there wont be any way to rollback the change if pods started failing when they were restarted.

Whenever services get into some wedged or undesirable state (maxed out connections and are now stalled, bad internal state, etc.). It's usually one of the first troubleshooting steps if a service is seriously misbehaving.

If the first pod fails as it is restarted, I would expect it to cease continuing or continue retrying to start the pod.

Also, a rolling restart with no spec change reallocates pods across the
cluster.

However, I would also like the ability to do this without rescheduling the
pods. That could be a rolling label change, but may pick up new dynamic
config or clear the local file state.

On Wed, Sep 2, 2015 at 12:01 AM, Sam Ghods [email protected] wrote:

Whenever services get into some wedged or undesirable state (maxed out
connections and are now stalled, bad internal state, etc.). It's usually
one of the first troubleshooting steps if the service is seriously
misbehaving.

If the first pod fails as it is restarted, I would expect it to cease
continuing or continue retrying to start the pod.

—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment-136931790
.

Clayton Coleman | Lead Engineer, OpenShift

@smarterclayton Is that like my option 2 listed above? Though why would labels be changed?

Re. wedged: That's what liveness probes are for.

Re. rebalancing: see #12140

If we did support this, I'd lump it with #9043 -- the same mechanism is required.

I suppose this would more be for a situation where the pod is alive and responding to checks but still needs to be restarted. One example is a service with an in-memory cache or internal state that gets corrupted and needs to be cleared.

I feel like asking for an application to be restarted is a fairly common use case, but maybe I'm incorrect.

Corruption would just be one pod, which could just be killed and replaced by the RC.

The other case mentioned offline was to re-read configuration. That's dangerous to do implicitly, because restarts for any reason would cause containers to load the new configuration. It would be better to do a rolling update to push a new versioned config reference (e.g. in an env var) to the pods. This is similar to what motivated #1353.

@bgrant0607 have we decided that we don't want to do this?

@gmarek Nothing, for now. Too many things are underway already.

Can we have a post v1.1 milestone (or something) for the stuff that we deem important, but we lack people to fix them straight away?

I would be a fan of this feature as well, you don't want to be forced to switch tags for every minor update you want to roll out.

I'm a fan of this feature. Use case: Easily upgrade all the pods to use a newly-pushed docker image (with imagePullPolicy: Always). I currently use a bit of a hacky solution: Rolling-update with or without the :latest tag on the image name.

Another use case: Updating secrets.

I'd really like to see this feature. We run node apps on kubernetes and currently have certain use cases where we restart pods to clear in app pseudo caching.

Here's what I'm doing for now:

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

This deletes pods 10 at a time and works well in a replication controller set up. It does not address any concerns like pod allocation or new pods failing to start. It's a quick solution when needed.

I would really like to be able to do a rolling restart.
The main reason is we will feed ENV variables into pods using ConfigMap and then if we change config we need to restart the consumers of that ConfigMap.

Yes, there are a lot of cases when you really want to restart pod/container without changes inside...
Configs, cache, reconnect to external services, etc. I really hope the feature will be developed.

Small work around (I use deployments and I want to change configs without having real changes in image/pod):

• create configMap
• create deployment with ENV variable (you will use it as indicator for your deployment) in any container
• update configMap
• update deployment (change this ENV variable)

k8s will see that definition of the deployment has been changed and will start process of replacing pods
PS:
if someone has better solution, please share

Thank you @paunin

@paunin Thats exactly the case where we need it currently - We have to change ConfigMap values that are very important to the services and need to be rolled-out to the containers within minutes up to some hours. If no deployment happens in the meantime the containers will all fail at the same time and we will have partial downtime of at least some seconds

from (kinda-related #9043): a one-liner of @paunin's approach, where RESTART_ is the environment variable, and it's set to an ISO timestamp:

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

(note for some reason environment variables starting with _ just seem to disappear, and numeric env values cause errors, they need to be strings)

@paunin @rcoup We do something very similar nowadays, we have an env var literally called "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT".

It feels like the right solution here would enable you to restart a deployment, and reuse most of the deployment parameters for rollouts like MinReadyCount, while allowing for command-line overrides like increasing the parallelism for emergency situations where you need everything to bounce immediately.

any progress on this?

I feel like this addition is an unnecessary bloating of the CLI API. This can be easily achieved by updating deployment environment variable values as suggested by @paunin.

We would also like to see this for deployments maybe like kubectl restart deployment some-api

Kubernetes is allowed to restart Pods for all sorts of reasons, but the cluster admin isn't allowed to.
I understand the moral stand that 'turn it off and on again' may not be a desired way to operate... but I also think it should be ok to let those people who wish to, to restart a Deployment without resorting to the range of less appetizing tricks like:

• deleting pods
• dummy labels
• dummy environment variables
• dummy config maps mapped to environment variable
• rebooting the worker nodes
• cutting the power to the data centre 😄

'No, no, I'm not restarting anything, just correcting a typo in this label here' 😛

This feature will be useful in pair with kubectl apply: apply will update configs, including Replication Controllers, but pods won't be restarted.

So we need a method to restart these pods Blue-Green way.

@DmitryRomanenko how about switching from ReplicationControllers to Deployments? That will enable you to run updates of ReplicaSets (successor to ReplicationController).

@kargakis it's not possible: Deployments update only Replica Sets and Pods.
With kubectl apply we also update ConfigMaps, Services, etc.

@DmitryRomanenko if the issue is "I want to restart Pods when ConfigMap/Secret is updated" then possible solution is to have versions for your ConfigMap and Secrets, and make that version a part of your Deployment spec. So with kubectl applying the spec of Deployment is changed and Pods are recreated.
In other situations I don't see why Pods must be restarted (I mean Service/Ingress/etc update).

@tyranron, thanks! What is the best way to version ConfigMaps? Should I create new config map with a different name for new deployment?

@DmitryRomanenko you actually can, why not? But in this case you should take care about removing old ones. On the other hand it may be useful for rollback. But in most cases specifying version via labels is enough.

I do believe that the best solution here could be some kind of watcher or hash-sum checker on configmap object. Which should trigger related objects/pods restart(anything uses that configmap,secret). Not sure it's something accessible in k8s architecture though...

I also think that it's better to have control from configmap|secret object to trigger restart on changes or not.

@tyranron,

So with kubectl applying the spec of Deployment is changed and Pods are recreated.

Could you explain? Should I just use kubectl apply -f new_config.yml with updated deployments, and these deployments will be rolling-restarted?

@DmitryRomanenko yup, exactly.

@DmitryRomanenko with applying new specs you are updating Deployment, and on Deployment update restart is triggered if its spec was changed.

By default the restart strategy is RollingUpdate, but you can specify another one explicitly too.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

A small change to @rcoup's solution: make sure the date is evaluated within the shell:

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

/remove-lifecycle stale
/lifecycle frozen

Been using Swarm mode for some time which is considered less flexible than Kubernetes, I am able to restart service tasks (read: deployment pods), by simply doing a force update (with no change to the specs) as in docker service update --force <service-name>. I would expect Kubernetes to do this as well.
As for configmaps and secrets, swarm does not allow you to edit those, you need to rotate them instead. You do this by creating new configmaps/secrets, updating the service spec to use the new ones, then delete the older ones. I see this is typically what is recommended above by versioning your configmaps/secerts and updating the deployments that use them. To be honest, this behavior of rotation is one major reason I left swarm for! It is very inconvenient to have a local copy, update then create new resources and finally update the dependent resources. Add to that, secrets in swarm cannot be read from the api, you have to mount them inside any container (or exec inside a container that uses them), then cat their files.
On a related note, I used openshift for some time and I believe it auto-restarts pods on env/configmap/secret change? I stand corrected though.

should be app responsibility to watch filesystem for changes, as mentioned you can use checksums on the configmap/secret and force restarts that way

but if you don't want to change the config at all and just do a rolling restart with arbitrary pause, a simple pipeline does the job (this one sleeps 30seconds between terminated pod)

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

do note that if you press ctrl+c, it's not easy to restart where you left off

@so0k, alternative command:

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

Two and half years on and people are still crafting new workarounds, with dummy env vars, dumy labels, ConfigMap and Secret watcher sidecars, scaling to zero, and straight out rolling-update shell scripts to simulate the ability the trigger a rolling update. Is this still something cluster admins should not be allowed to do honestly, without the tricks?

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

Another trick is to intially run:

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

and then:

kubectl set image deployment/my-deployment mycontainer=myimage

It will actually be triggering the rolling-update but be sure you have also imagePullPolicy: "Always" set.

another trick I found, where you don't have to change the image name, is to change the value of a field that will trigger a rolling update, like terminationGracePeriodSeconds. You can do this using kubectl edit deployment your_deployment or kubectl apply -f your_deployment.yaml or using a patch like this:

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 deleting pods means downtime, even when running multiple instances. When someone runs a single pod with strategy.rollingUpdate.maxUnavailable = 0 a regular deployment first creates a new pod before it terminates the existing one. The kubectl patch deployment trick triggers this behavior, deleting pods doesn't. I'd really like a non-hacky way to trigger this behavior on demand.

For instance, when running images from hub.docker.com, the same tag can be patched for security updates. I'd really like to "pull the latest images", and perform a rolling update for any outdated image.

Rollout of ConfigMap/Secret updates is #22368
Easier rollout of new images is #1697
In-place rolling updates is #9043

Restart on image builds: https://github.com/GoogleCloudPlatform/freshpod
Helm summit presentation of a trick using a templated annotation to trigger deployment rollouts: https://www.youtube.com/watch?v=dSw0w1x96ak

@bgrant0607 I think the important use-case that is not covered by other tickets is this one: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment-136946912

@ghodss wrote:
I suppose this would more be for a situation where the pod is alive and responding to checks but still needs to be restarted. One example is a service with an in-memory cache or internal state that gets corrupted and needs to be cleared.

I feel like asking for an application to be restarted is a fairly common use case, but maybe I'm incorrect.

I'd like to force a rolling restart to clear all application state without manual tricks.

I've got a similar one-liner based on the approach that @rcoup and @paunin described, but it should work for the more general case. It relies on JSON output and uses jq for parsing. I have this loaded in to my bashrc as a function so I can call it anywhere

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 -
}

This allows me to just say: kubectl-restart my-deployment-name and it will "update" the RESTART_ env var in the first container to the current timestamp. I'm far from a jq expert so there may be a better way to do it, but basically it deletes the old RESTART_ env var from the output (if it exists) and then adds it back in there with the current time.

It does feel very weird to me that there is no native way to do this though... Certainly a room full of engineers would agree that the ability to "turn it off and back on again" is something we'd like to have.

That is a fine hack and all, but it has big downside. The next time you deploy, using kubectl apply -f, that component will get restarted if it has a RESTART_xxx env var even if nothing else changes. In other words, it causes spurious restarts on next deployment if it has ever been restarted between last deployment and this deployment. Not ideal...

That is why rolling-restart functionality should be baked into the Deployment controller, not built on top.

I wrote a bash function to accomplish the "patch deployment of terminationGracePeriodSeconds" strategy @whereisaaron quoted in his comment above (source: https://stackoverflow.com/a/40368520/90442).

# $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
}

Comment / update it via the gist here. I'll echo others' comments that it would be better if this wasn't necessary.

Just by way of a more specifically kube related justification, restart also allows the re-running of an init-container, which can be used to roll keys, update config, or whatever you use init containers for.

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

@gjcarneiro Did you have a RESTART_xxx env var in the configuration you applied, or not? If not, then I'd expect apply to ignore the extra env var in the live state.

cc @apelisse

@gjcarneiro Yeah, the problem with @mattdodge script is that it's using apply, so the change will be saved in the lastApplied annotation. The script could be fixed by using patch or another method to update the deployment.

Would love to have this feature. It seems very basic and needed.

No progress here nor on #22368, le sigh :-(

Can anyone recommend a quick and dirty solution to restart a DaemonSet after the mounted ConfigMap has been updated (name is still identical)?

@alcohol , check this one https://github.com/kubernetes/kubernetes/issues/13488#issuecomment-356892053

Thanks for the tip :-)

Openshift has the concept of deployment triggers, which trigger a rollout on image change, webhook or configuration change. It would be very good feature to have in Kubernetes. As well as manual rollouts of course.

Furthermore Docker repository has history so there is no reason why rollback couldn't work - pod spawned from .spec.template can use image-tag:@digest format when pulling images for containers. Rollback would use the digest ID of the previous rollout.

Not sure if I'm understanding correctly. Just in case this helps anybody.

It seems that if you update the value of a label under the pod > template > metadata, then a rolling update takes place after you kubectl apply -f file.yaml

So you can always have a label for your version and whenever you want to rolling update, change the version and apply the file.

Sure, downside is that next time you want to do a deploy, you do kubectl apply -f some.yaml, right? Normally, if nothing changes in some.yaml then nothing gets restarted, that's one of the nicest things about Kubernetes.

But imagine what happens after you change a label to restart a Deployment. At the next normal software deployment you do kubectl apply -f some.yaml as usual, but because the yaml file doesn't contain the same label, the Deployment will get needlessly restarted.

@gjcarneiro If you don't apply when you make a change, the kubectl.kubernetes.io/last-applied-configuration annotation will not get updated, so the next apply will not cause another restart.

I'm strongly in favour of adding a rolling restart command to kubectl, but in the meantime I'm using the following (based on solutions above):

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

Parameterize this and add it as a function in your .bashrc and it's a good interim solution.

Ah, cool, I didn't know that, thanks!

I don't need the bash alias, at my company we made my own web interface for managing Kubernetes using Python+aiohttp and it already uses patch. I thought about open sourcing it, just been lazy...

Looks like people are repeating the same workaround solutions in this thread - please read the full thread before posting here

@joelittlejohn I ran your macro and it DID trigger a reboot of my pods, but they all restarted at the same time. I thought this would trigger a rolling reboot, no?

@Macmee It depends on the configuration of your deployment. The above command just changes the deployment. The pods are then updated according to the roll out strategy defined by your deployment. This is just like any other change to the deployment.

The only way this will replace all pods at the same time is if your .spec.strategy.rollingUpdate.maxUnavailable allows it.

We also kind of need this feature. One use case also on our side is that we use spring-cloud-config-server backed by and scm, for our spring-boot app. When we change a configuration property, the the spring-boot app needs to be restarted to be able to fetch the new config change so we also need this kind graceful restart trigger without having to do a redeployment.

@japzio As suggested by Helm, a checksum of the configmap in the annotations is a good way to handle that case.

Has there been any update on this ? We're looking to have this feature too. @bgrant0607 @nikhiljindal

@bholagabbar-mt What is your use case?

cc @kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo The usecase for our systems is multifold.

1. Secrets updating - I'm sure you realise that there are many companies such as mine, that have build their own abstractions over kubernetes. We have our own container management system that is orchestrated over kubernetes. So the helm secret suggestion comment and others are not applicable. To reload secrets from ConfigMaps in the dev cluster, we have to force kill the pods, resulting in a few seconds of downtime. This should not be the case. This is a real usecase for rolling update.

2. This is a bit complicated, but the overall scope, as someone suggested, is to fix abnormal behaviour. We have 4-5 heavy Java apps running on the Play framework. We are encountering a situation where the memory consumption of our java pods linearly rises and then restarts the pods when the memory limit is reached. This is a documented Java issue with a stackoverflow issue and Kubernetes Issue associated to it. Rolling-restart of all the pods in a 3-4 hour period would reset the memory consumption and allow our apps to function smoothly without spikes.

Hopefully this was convincing enough and this feature can be taken up by someone for development ?

@bholagabbar-mt just change an environment variable and it'll trigger a rolling deploy:

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

@montanaflynn This is perfect. We integrated this change into our systems today itself and it runs fine. Thanks a ton!

cc @huzhengchuan

Another use-case for this: due to a security issue in containerd I'd like to restart all the pods. https://seclists.org/oss-sec/2019/q1/119 Either the cluster goes completely down, or it does a rolling restart. Having a restart command would make a huge difference!

update, workaround:

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 you are the best practices. add annotation:{creatTime: 12312312} in rancher!

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

seems to be minimal command that does the job for one deployment. It is example of use of imperative configuration.

cc @monopole @apelisse

~Two~ Three and a half years on and people are still crafting new workarounds, with dummy env vars, dummy labels, dummy annotations, ConfigMap and Secret watcher sidecars, scaling to zero, and straight out rolling-update shell scripts to simulate the ability the trigger a rolling update. Is this still something cluster admins should not be allowed to do honestly, without the tricks?

Rolling updates are still a pretty popular activity for something with apparently no use case 😄

long-term-issue (note to self)

1. I don't see a way to do this without letting imperative logic bleed into a declarative API, thereby, breaking our convention of keeping the APIs declarative and implementing imperative behavior in the controllers, and introducing incompatibilities with most CI/CD practices.
2. I could imagine an RollingRestart API and controller where the creation of a RollingRestart resource caused the controller to restart Pods 1 by 1 via eviction (thus respecting disruption budgets), but such a controller could be implemented as a CRD (i.e. I see know reason why we have to do this in tree).
3. The declarative approach, e.g. adding a lastRestartedAt=TIMESTAMP annotation doesn't seem like a hack to me.
4. If anyone would like to offer a declarative design and contribution to implement this feature (in tree or otherwise) please consider authoring a KEP PR against the enhancements repo. If a declarative, built in, implementation can be designed I'd be happy to review/shepard in workloads APIs. If a CRD controller like [2] is offered we could sponsor it in SIG Apps as an community sponsored extension.

The declarative approach, e.g. adding a lastRestartedAt=TIMESTAMP annotation doesn't seem like a hack to me.

It's not a hack, there should just be a shorthand command line for it.

Someone could build a krew plugin that sends the patch. kubectl restart-deployment <deployment_name>?

kubectl rollout restart that patches a deployment/daemonset/statefulset to trigger a fresh 'rollout'?

That is in line with @kow3ns's approach (3), and makes some sense since you can then watch/pause/resume the rollout you just started with the other kubectl rollout commands.

@whereisaaron I'll see if I can send a patch for that (pun not intended)

For rolling out new secrets and configmaps, my recommendation is still #22368: create new ones. That provides a means for both controlling the rollout and also rolling back. We just need to finish GC of old objects:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

Documenting and/or supporting (in kustomize, kubectl, or a kubectl plugin) the recommended way to do a rolling restart with the existing API is reasonable, though.

cc @monopole

As for new images, CI/CD or a controller that resolves tags to digest: #1697.

Moving unhappy pods was intended to be performed by the descheduler (https://github.com/kubernetes-incubator/descheduler) or something like it, that could consume container status, core metrics, and even custom metrics:

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

Also, official documentation on how to handle secrets and configmap: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

Rolling restart is very much needed . 1 example is we get all secrets from SSM from AWS. If we change some secret from SSM we would like to do a rolling restart so that the pods now pick up the latest when they boot. Also some times there are application issues which needs rolling restart till actual fix lands on production.

OK, kubectl rollout restart has merged!

That's great to hear after nearly 4 years, thanks!

I believe the merged PR only supports deployments, is that correct?

Some people in this issue have expressed the need for restarting daemonsets and statefulsets as well.

@apelisse is there also a way to do this via the sdk or just kubectl?

@e-nikolov What is the SDK?

I meant the Go client that can be used for talking to kubernetes from Go programs.

No, you would have to re-implement the (very simple) logic that is implemented in kubectl.

OK, kubectl rollout restart has merged!

What kubectl version will have it?

What kubectl version will have it?

Kubernetes 1.15

Our GKE cluster on "rapid" release channel has upgraded itself to Kubernetes 1.16 and now kubectl rollout restart has stopped working:

kubectl rollout restart deployment myapp
error: unknown command "restart deployment myapp"

@nikhiljindal asked a while ago about the use case for updating the deployments without any changes to the specs. Maybe we're doing it in a non-optimal way, but here it is: our pre-trained ML models are loaded into memory from Google Cloud Storage. When model files get updated on GCS, we want to rollout restart our K8S deployment, which pulls the models from GCS.

I appreciate we aren't able to roll back the deployment with previous model files easily, but that's the trade-off we adopted to bring models as close as possible to the app and avoid a network call (as some might suggest).

hey @dimileeh

Do you happen to know what version of kubectl you're using now? and what version you used before? I'd love to know if there was a regression, but at the same time I'd be surprised if the feature had entirely disappeared.

With regard to the GCS thing, and knowing very little about your use-case so sorry if it makes no sense: I would suggest that the gcs model get a different name every time they get modified (maybe suffix with their hash), and that the name would be included in the deployment. Updating the deployment to use the new files would automatically trigger a rollout. This give you the ability to roll-back to a previous deployment/model, have a better understanding of the changes happening to the models, etc.

hi @apelisse, thank you for your response!

When I run kubectl version from Google Cloud Terminal, I get the following:

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"}

When I tried to upgrade kubectl via gcloud components update, it said I'm already using the latest versions of all products. Therefore, I think my kubectl version stayed the same while the K8S cluster upgraded from 1.15 to 1.16.

The Kubenetes documentation 1.17, 1.16 and 1.15 has nothing about kubectl rollout restart feature. So I wonder if your valuable contribution could have disappeared from 1.16?

Thank you for your suggestion on model versioning, it makes perfect sense. We thought about that but then, since we retrain our models every day, we thought we'd start accumulating too many models (and they are quite heavy). Of course, we could use some script to clean up old versions after some time, but so far we've decided to keep it simple relying on kubectl rollout restart and not caring about model versioning :)

I can see the docs here:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-restart-em-

Ah, thank you, I was looking here:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

Thank you very much for that link, I’ll make sure it gets updated !

On Thu, Dec 19, 2019 at 12:40 PM Dmitri Lihhatsov notifications@github.com
wrote:

Ah, thank you, I was looking here:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHK3ZSA#issuecomment-567655624,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (I'll cherry-pick in relevant branches once this gets merged).

@dimileeh I think I figured out what's wrong with your kubectl version, we'll be working on it.

Yes, we also have use case of re-starting pod without code change, after updating the configmap. This is to update a ML model without re-deploying the service.

@anuragtr with latest versions you can run

kubectl rollout restart deploy NAME

I was using a custom command for that [1], glad it is now in the standard kubectl! Thanks

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

@anuragtr with latest versions you can run

kubectl rollout restart deploy NAME

@countrogue