0

My first thought was using the downward API, but that doesn't seem to expose the scale of a deployment / statefulset. I was hoping to be able to avoid adding it in as a separate environment variable manually, or having to rely on pods all discovering each other to determine the scale if possible.

Use-case: Deploying many pods for an application that connects to an external service. Said service does some form of consistent hashing (I believe is the right term?) for sending the data to clients, so clients that connect send an id number from 0 - N-1 and a total number of clients N. In this case, the deployment/statefulset scale would be N.

user7876637
  • 124
  • 4
  • 11

1 Answers1

2

You would definitely have to use a StatefulSet for this, and I don't think you can pull it from the DownwardAPI because the replica count isn't part of the pod spec (it's part of the statefulset spec). You could get the parent object name and then set up a service account to be able to query the API to get the replica count, but that seems like more work than putting the value in a label or env var.

coderanger
  • 52,400
  • 4
  • 52
  • 75
  • That's what I was afraid of :( I was hoping I just missed something obvious in the docs – user7876637 Jan 14 '19 at 00:25
  • With StatefulSet, you'll get consistent names in your pods (available inside as the hostname!), having a nice index number in it. So your pods could use this information. Without a StatefulSet, you wouldn't be able to generate a unique index number in your pods (you could use the pod name -> hostname, but that would be a string, not an index number, with a random string id). – Laszlo Valko Jan 14 '19 at 03:10
  • The more important reason to use a stateful set is you can assured you won't overprovision which could easily break the consistent hash. But yeah, you can get the current index by parsing the pod name, it's the total replicas that isn't available. – coderanger Jan 14 '19 at 08:09