When you have a StatefulSet or a Deployment you usually have means to provide commands that will be fed into a pod's container on its creation.
Is it possible, more arguments to be injected into the commands array as the deployment autoscales with say an HPA or remove certain if it downscales?
For example, here if you want to allow nsqlookupd to scale out (another deployment), then you'd have to register its new pod IPs into the command list of a nsqAdmin pod.
command:
- /nsqd
- -data-path
- /data
- -lookupd-tcp-address
- nsqlookupd-0.nsqlookupd:4160
- -lookupd-tcp-address
- nsqlookupd-1.nsqlookupd:4160
- -lookupd-tcp-address
- nsqlookupd-2.nsqlookupd:4160
...The situation is hypothetical, as you need to reach a crazy-high amount of queues I guess to have the need to extend beyond 3 nsqlookupd-s (NSQ's queue discovery svc) so for moderate loads, a fixed count of looupd-s will do. Even so, I wonder how such type of automated scaling in an extreme case that can be handled in Kubernetes.
Especially for event-driven systems, there must be use cases, this is the closest I could think of.
This question is more rather more about an option on how to scale certain services in Kubernetes. I think the best pattern for this is to have a Kubernetes Operator. Essentially, this would manage the lifecycle of your nsqd application. There are several operator tools that you can use to create your nsqd operator:
A good example of a scale-out operator is Srimzi which is Kafka operator for Kubernetes.
You can also find other well-known operators in the Operator Hub.