Restart Kubernetes deployments using HTTP requests

In a previous post I introduced go-to-exec, an open-source program that lets you execute terminal commands using HTTP requests.

The problem I faced some days ago is:

How can I restart a Kubernetes deployment using an HTTP request?

DISCLAIMER: the following solution is to be used ONLY inside a private/protected network, as it does not provide authentication. If you want to expose go-to-exec on the public internet, you NEED to protect the access with an authentication layer, e.g. oauth2-proxy.

The concept

The final flow

From a pure CLI perspective, we want to run the command:

kubectl rollout restart deployment/my-deployment-name

This will trigger a rollout restart of all pods of the specified deployment (we can do the same for a StatefulSet!).

So, how to expose this to be triggered using an HTTP request?

The request

A very basic go-to-exec configuration could be:

Once set up, we can trigger a restart with:

curl "http://localhost:7055/restart/deployment/my-deployment-name"

# Or

curl "http://localhost:7055/restart/statefulset/my-statefulset-name"

The Kubernetes resources

You can see the full example at: https://github.com/cmaster11/go-to-exec/blob/main/examples/k8s-restart-helper.yaml

To deploy a full working set up we’ll need:

• A service account, to allow us to use kubectl from inside our Kubernetes cluster.
• A deployment, to run our go-to-exec instances.
• A service, to access our go-to-exec instances.
• An ingress, to be able to execute HTTP requests and target our go-to-exec service.

Once deployed (following this example), we could trigger a rollout with:

curl "https://myhost.mydomain.com/restart/deployment/my-deployment-name"

Service account

Our ServiceAccount can be defined with:

Deployment

Our Deployment manifest can be:

Service

Our Service definition is pretty straightforward:

Ingress

NOTE: this is the part where you’re exposing go-to-exec to the world and, unless you're just testing for fun, you NEED to have a front-end authentication proxy/gateway (if you're targeting the public internet), for safety reasons.

The Ingress resource greatly depends on the type of ingress controller you're using, but the most basic format would be:

Conclusion

As previously mentioned, once you deploy these Kubernetes resources, you will be able to trigger a rollout restart with

curl "https://myhost.mydomain.com/restart/deployment/my-deployment-name"

One potential use-case for this approach is:

• You receive an alert (e.g. using Notify17), which tells you that one of your pods/deployments is stuck (e.g. cannot reconnect to your database!).
• You can then trigger a notification action, which will invoke the go-to-exec rollout restart command.

I hope you can find this approach useful to remotely administer some Kubernetes resources!