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.
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
I need to protect, from a clueless operations team that works with K8S for less than a month. I will deploy with only one replica and add a NOTE section with a warning, hope they read it… I as able to implement this with jsPolicy on EKS but they are not allowing the installation of jsPolicy on the cluster.
Lets see how it goes… would be good if I could enforce a hard limit maxReplicas on a Deployment, but it seems a bit counter-intuitive.