Singleton Pod

Is there a native way to enforce a Pod to only have one replica, that does not require implementation of a webhook?

In other words is there a way to restrict scaling of a replicaset? Or should this pod be deployed outside a replicaSet and enforce with RBAC rules.

What would be considered the best practice to implement a Singleton Pattern?

There is no such concept - a Deployment or ReplicaSet of size 1 is what you want.

My assumption is that you’re just trying to take advantage of Kubernetes for rescheduling a single pod should it crash. You don’t want replicas because multiple copies would break something.

Kubernetes isn’t really designed for the behavior you want to enforce. Some options include:

  • Using a StatefulSet and build your container to crash if the pod ordinal is not 0, before running your application
  • Using policy enforcement operators like kyverno, OPA gatekeeper, or jsPolicy to enforce this rule

There’s caveats to this when you start to consider what upgrading that application looks like as well that you need to test an plan for.

I would recommend avoiding this idea all together if you can though.

Thank you both for your replies.

I would love to avoid this, it is completely unnatural behavior. However the application breaks if there is more than one replica, this is a middleware solution (Camunda BPMN engine) that is integrated with a SSO solution using SAML. When we had more than one replica the login authentication would loop infinitely, because it would send requests to multiple pods.

I had implemented a sticky session that worked very well and resolved the problem using nginx ingress controller, however the operations team on my organization now does not want to allow the installation of this nginx ingress controller on higher environments… tst, int, dlt, acc, trn, prd.

I think the only practical solution will be to prevent the Deployment to be scaled, only the service account will be able to do that.

Indeed using Kyverno also works but again the same problem with the operations team. I think I will have to restrict permission to just the service account that does the deployment.

Yes, it is already an assumed risk that when the cluster upgrades there may be downtime. I will try to prevent this by putting in place a PDB.

Public administration organizations are a bit paranoid and cripple all software :frowning:

From whom do you need to protect it? Do you have people or systems randomly scaling other people’s deployments?

Look into the lease API as a way to interlock?

1 Like