Change:
is useful for incrementally deploying a new replication controller. But if you have an existing replication controller and want to do a rolling restart of all the pods that it manages, you are forced to do a no-op update to an RC with a new name and the same spec. It would be useful to be able to do a rolling restart without needing to change the RC or to give the RC spec, so anyone with access to kubectl could easily initiate a restart without worrying about having the spec locally, making sure it's the same/up to date, etc. This could work in a few different ways: new command, that takes an RC name and incrementally deletes all the pods controlled by the RC and allows the RC to recreate them. as 1, but instead of deleting each pod, the command iterates through the pods and issues some kind of "restart" command to each pod incrementally (does this exist? is this a pattern we prefer?). The advantage of this one is that the pods wouldn't get unnecessarily rebalanced to other machines. with a flag that lets you specify an old RC only, and it follows the logic of either 1 or 2. with a flag that lets you specify an old RC only, and it auto-generates a new RC based on the old one and proceeds with normal rolling update logic. All of the above options would need the MaxSurge and MaxUnavailable options recently introduced (see ) along with readiness checks along the way to make sure that the restarting is done without taking down all the pods.
cc 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. , Sam Ghods wrote:
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 If we did support this, I'd lump it with -- 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 .
have we decided that we don't want to do this?
Nothing, for now. Too many things are underway already.
Can we have a 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 ). I currently use a bit of a hacky solution: Rolling-update with or without the 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: 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
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 ): a one-liner of approach, where is the environment variable, and it's set to an ISO timestamp: (note for some reason environment variables starting with value`s cause errors, they need to be strings)
We do something very similar nowadays, we have an env var literally called "DUMMYVARFORNOOP_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 .
We would also like to see this for deployments maybe like
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 : will update configs, including Replication Controllers, but pods won't be restarted. So we need a method to restart these pods Blue-Green way.
how about switching from ReplicationControllers to Deployments? That will enable you to run updates of ReplicaSets (successor to ReplicationController).
it's not possible: Deployments update only Replica Sets and Pods. With we also update ConfigMaps, Services, etc.
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 ing 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).
thanks! What is the best way to version s? Should I create new config map with a different name for new deployment?
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 object. Which should trigger related objects/pods restart(anything uses that ,). Not sure it's something accessible in architecture though... I also think that it's better to have control from object to trigger restart on changes or not.
Could you explain? Should I just use with updated deployments, and these deployments will be rolling-restarted?
yup, exactly.
with applying new specs you are , and on Deployment update restart is triggered if its spec was changed. By default the restart strategy is , but you can specify another one explicitly too.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
A small change to : make sure the is evaluated within the shell:
/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 . 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 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) do note that if you press ctrl+c, it's not easy to restart where you left off
alternative command:
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?
deleting pods means downtime, even when running multiple instances. When someone runs a single pod with a regular deployment first creates a new pod before it terminates the existing one. The 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 , 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 Easier rollout of new images is In-place rolling updates is Restart on image builds: Helm summit presentation of a trick using a templated annotation to trigger deployment rollouts:
I think the important use-case that is not covered by other tickets is this one: 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 and 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 This allows me to just say: and it will "update" the 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 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 , 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 " strategy quoted in his above (source: ). Comment / update it via the . 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.
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
Yeah, the problem with 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 , 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)?
, check this one
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 can use 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 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 , right? Normally, if nothing changes in 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 as usual, but because the yaml file doesn't contain the same label, the Deployment will get needlessly restarted.
If you don't when you make a change, the annotation will not get updated, so the next 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): 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
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?
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 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 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.
As , 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.
What is your use case? cc
The usecase for our systems is multifold. 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 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. 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 and 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 ?
just change an environment variable and it'll trigger a rolling deploy:
This is perfect. We integrated this change into our systems today itself and it runs fine. Thanks a ton!
cc
Another use-case for this: due to a security issue in containerd I'd like to restart all the pods. Either the cluster goes completely down, or it does a rolling restart. Having a restart command would make a huge difference! update, workaround:
you are the best practices. add 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
Rolling updates are still a pretty popular activity for something with apparently no use case
long-term-issue (note to self)
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. 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). declarative approach, e.g. adding a lastRestartedAt=TIMESTAMP annotation doesn't seem like a hack to me. 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 . 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.
It's not a hack, there should just be a shorthand command line for it.
Someone could build a plugin that sends the patch. ?
that patches a deployment/daemonset/statefulset to trigger a fresh 'rollout'? That is in line with approach (3), and makes some sense since you can then watch/pause/resume the rollout you just started with the other commands.
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 : 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: 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
As for new images, CI/CD or a controller that resolves tags to digest: .
Moving unhappy pods was intended to be performed by the descheduler () or something like it, that could consume container status, core metrics, and even custom metrics:
Also, official documentation on how to handle secrets and configmap:
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, 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.
is there also a way to do this via the sdk or just kubectl?
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.
What version will have it?
Kubernetes 1.15
Our GKE cluster on "rapid" release channel has upgraded itself to Kubernetes 1.16 and now has stopped working: 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 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 thank you for your response! When I run from Google Cloud Terminal, I get the following: When I tried to upgrade kubectl via , 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 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 and not caring about model versioning :)
I can see the docs here: https://v1-
Ah, thank you, I was looking here: https://v1-
Thank you very much for that link, I’ll make sure it gets updated ! Dmitri Lihhatsov <:
PTAL (I'll cherry-pick in relevant branches once this gets merged).
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.
with latest versions you can run
I was using a custom command for that [1], glad it is now in the standard kubectl! Thanks [1]
As i understand now if i have a newer docker image tagged as :latest and a deployment using the image tagged :latest, with the and specified in the container template it is possible to restart the pods and they will pull the newer image. But if the image is still the same, will still restart the pods of the deployment. IS THERE a way to ask Kubernetes to check if the image has really changed and restart pods ONLY if the image differs from that one used in the pods? I am migrating services that are managed by docker-compose, and currently i run and it restarts a service (using :latest tagged image) only if another version of the image (still tagged as :latest) is available now.
I believe you may misunderstand how kubernetes and this latest tag concept works. Simply put, if you use a dynamic tag (like latest) that can have multiple different images at any given time, you can never guarantee you are always using the same version of that tag (aka the same image). Kubernetes doesn’t do a “lookup” like you seem to assume to check what sha sum the current t deployment needs to pull from your container registry. This all is possible whether or not you have image pull policy set. An example of it helps, is let’s say you have 3 nodes and a deployment of your “widgets” service that has 3 replicas specified and let’s say your image pull policy is always. Let’s say you trigger an update to your service (although I do not know how since your image tag didn’t change. So let’s say you do something silly which I’ve seen before like set the current date into an annotation). The second this triggers on the first node it will try to bring up a new pod with your latest latest, but before that gets healthy let’s say your CI system or your dev pushed a new latest. Then after this your first pod got healthy and a new pod on the second node tried to come up. This one would now be using the newer latest. TL;DR: Do not use latest tag for anything ever for the most part. It’s really bad practice. All registries I know of have a feature you can enable which disallows pushing over an existing tag exactly for this reason. It’s bad. There are simple use cases for latest (Eg useful for internal ci images and tooling and can be useful in docker files) but you should understand when you use and not use them. Deploying something into kubernetes with a latest tag is generally viewed as “doing something wrong/funny” in my experience.
thanks, your explanation helped me a lot and the example is something i could not see before. Actually what i do is using :develop and :master tagging of docker images built against the corresponding git branches and deploy them to dev and staging environments as soon as possible. As my dev and staging environments are hosted on a single host i did not worry much. After reading many discussions on :latest tags and Kubernetes i finally agree to drop using :latest tagging with Kubernetes even for dev and staging environments. It was simple to use with docker-compose but not ok with Kubernetes. I have two related questions now and i would appreciate any leads. It might seem off topic but i believe these are the issues blocking people to drop using :latest tags. would be the best way to trigger deployments' updates? Instead of the cron job i have now that does and . I have a feeling it is too much coupling to make the build system to trigger updates to the cluster. I prefer the cluster to check for updates available but may be i am wrong here. to clean old docker images in private docker registry? Now i have :develop and :master tags only and no need to make cleaning. But with proper tagging i will have to keep only the latest :develop-timestamp-or-hash image and delete all older images. This really adds me headache as i try to have minimum possibilities of running out of disk space.
You should google this problem for your registry provider (eg: "Automatically delete old images on REGISTRYPROVIDER" or perhaps "Delete untagged images on REGISTRYPROVIDER") Each registry tends to have their own API and/or tools to handle this. AWS, for example, has a built-in which you can configure to automatically delete images without requiring much effort on your part. In the past on "simpler" registries I've been known to write simple scripts to query the old images and delete them. Good luck!

Discussion:
restartLong = templates.LongDesc(` Restart a resource. <del> A deployment with the "RolloutStrategy" will be rolling restarted.`) </del> <ins> Resource will be rollout restarted.`) </ins> restartExample = templates.Examples(` # Restart a deployment <del> kubectl rollout restart deployment/nginx`) </del> <ins> kubectl rollout restart deployment/nginx # Restart a daemonset kubectl rollout restart daemonset/abc`) </ins> ) // NewRolloutRestartOptions returns an initialized RestartOptions instance

func NewCmdRolloutRestart(f cmdutil.Factory, streams genericclioptions.IOStreams) *cobra.Command { o := NewRolloutRestartOptions(streams) <del> validArgs := []string{"deployment"} </del> <ins> validArgs := []string{"deployment", "daemonset", "statefulset"} </ins> cmd := &cobra.Command{ Use:                   "restart RESOURCE",

obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1beta1.SchemeGroupVersion), obj) <ins> case *extensionsv1beta1.DaemonSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(extensionsv1beta1.SchemeGroupVersion), obj) case *appsv1.DaemonSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1.SchemeGroupVersion), obj) case *appsv1beta2.DaemonSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1beta2.SchemeGroupVersion), obj) case *appsv1.StatefulSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1.SchemeGroupVersion), obj) case *appsv1beta1.StatefulSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1beta1.SchemeGroupVersion), obj) case *appsv1beta2.StatefulSet: if obj.Spec.Template.ObjectMeta.Annotations == nil { obj.Spec.Template.ObjectMeta.Annotations = make(map[string]string) } obj.Spec.Template.ObjectMeta.Annotations["kubectl.kubernetes.io/restartedAt"] = time.Now().Format(time.RFC3339) return runtime.Encode(scheme.Codecs.LegacyCodec(appsv1beta2.SchemeGroupVersion), obj) </ins> default: return nil, fmt.Errorf("restarting is not supported") }

kubectl set resources daemonsets/bind "${kube_flags[@]}" --limits=cpu=200m,memory=512Mi kube::test::get_object_assert 'daemonsets bind' "{{${template_generation_field}}}" '4' <ins> # Rollout restart should change generation kubectl rollout restart daemonset/bind "${kube_flags[@]}" kube::test::get_object_assert 'daemonsets bind' "{{${template_generation_field}}}" '5' </ins> # Clean up kubectl delete -f hack/testdata/rollingupdate-daemonset.yaml "${kube_flags[@]}"

# TODO: test robust scaling in an e2e. wait-for-pods-with-label "app=nginx-statefulset" "nginx-0" <ins> # Rollout restart should change generation kubectl rollout restart statefulset nginx "${kube_flags[@]}" kube::test::get_object_assert 'statefulset nginx' "{{$statefulset_observed_generation}}" '3' </ins> ### Clean up kubectl delete -f hack/testdata/rollingupdate-statefulset.yaml "${kube_flags[@]}" # Post-condition: no pods from statefulset controller