0

In the Kubernetes world, a typical/classic pattern is using Deployment for Stateless Applications and using StatefulSet for a stateful application.

I am using a vendor product (Ping Access) which is meant to be a stateless application (it plays the role of a Proxy in front of other Ping products such as Ping Federate).

The github repo for Ping Cloud (where they run these components as containers) shows them running Ping Access (a stateless application) as a Stateful Set.

I am reaching out to their support team to understand why anyone would run a Stateless application as a StatefulSet.

Are there other examples of such usage (as this appears strange/bizarre IMHO)?

I also observed a scenario where a customer is using a StatefulApp (Ping Federate) as a regular deployment instead of hosting them as a StatefulSet.

The Ping Cloud repository does build and deploy Ping Federate as a StatefulSet.

Honestly, both these usages, running a stateless app as a StatefulSet (Ping Access) and running a stateful app as a deployment (Ping Federate) sound like classic anti-patterns.

Manglu
  • 10,744
  • 12
  • 44
  • 57
  • 1
    While I agree all of this sound weird, I want to point out that Statefulset serve a double purpose. The obvious feature is they provide storage to the pods, but the second one is they provide stable naming to pod replicas. Can it be that the Ping Cloud app needs stable naming for its replicas? – whites11 Jul 05 '22 at 07:07
  • what is the actual problem? This seems more like a discussion than Q/A. – The Fool Jul 05 '22 at 07:23
  • @TheFool, the usage sounded anti-pattern to me and I am trying to pre-empt problems rather than waiting for one to occur. Fritz provided some interesting insights in his response on when one may possibly use a StatefulSet for a stateless app. – Manglu Jul 06 '22 at 00:35

2 Answers2

2

Apart from the ability to attach dedicated Volumes to StatefulSets you get the following features of which some might be useful for stateless applications:

  • Ordered startup and shutdown of Pods with K8s doing them one by one in an ordered fashion.
  • Possibility to guarantee that not more than a single Pod is running at a time even during unscheduled Pod restarts.
  • Stable DNS names for Pods.

I can only speculate, why Ping Federate uses a StatefulSet. Possibly, it has to do with access limitations of the downstream services it connects to.

Fritz Duchardt
  • 11,026
  • 4
  • 41
  • 60
  • I honestly believe Ping Federate(PF) is a stateful application. Here is a response from the Ping Community (https://support.pingidentity.com/s/question/0D58Z00009ZGOL2SAP/is-ping-federate-a-stateful-or-a-stateless-application) that states PF is indeed a stateful application. So no qualms in deploying a StatefulApp using a Stateful Set. The query about Ping Access PA (which according to Ping is stateless) the usage of StatefulSet is dubious. None of the reasons that you had placed there per se is a requirement for Ping Access. I will probe further. – Manglu Jul 08 '22 at 01:18
1

The consumption of PingAccess is stateless, but the operation is very much stateful. Namely, the PingAccess admin console maintains a database for configuration, and part of that configuration includes clustered engine mapping and session keys.

Thus, if you were to take away the persistent volume, restarting the admin console would decouple all the engines in the cluster. Then the engines no longer receive configuration.. and web session keys would be mismatched.

The ping-cloud-base repo uses StatefulSet for engines not for persistent volumes, but for sts naming scheme. I personally disagree with this and recommend using Deployment for engines. The only downside is you then have to remove orphaned engines from the admin configuration. Orphaned engines meaning engine config that stays in the admin console db after the engine deployment is rolled/updated. These can be removed from the admin UI, or API. Pretty easy to script in a hook.

It would be ideal for an application that is not a datastore to run without persistent volume, but for the reasons mentioned above, the PingAccess admin console does require and act like a persistent datastore so I think StatefulSet is okay.

Finally, the Ping DevOps team focuses support on their helm chart (where engines are also deployments by default). I'd suspect the community and enterprise support is much larger there for folks deploying on their own. ping-cloud-base is a good place to pick up some hooks though.

Samir Gandhi
  • 11
  • 4