[ruuda]

> Have you considered alternative solutions?

How about, don't use Kubernetes? The lack of control over where the workload runs is a problem caused by Kubernetes. If you deploy an application as e.g. systemd services, you can pick the optimal host for the workload, and it will not suddenly jump around.

[indemnity]

> The lack of control over where the workload runs is a problem caused by Kubernetes.

Fine grained control over workload scheduling is one of the K8s core features?

Affinity, anti-affinity, priority classes, node selectors, scheduling gates - all of which affect scheduling for different use cases, and all under the operator's control.

[glennpratt]

Comparing systemd and Kubernetes for this scenario is like comparing an apple tree to a citrus grove.

You can specify just about anything, including exact nodes, for Kubernetes workloads.

This is just injecting some of that automatically.

I'm not knocking systemd, it's just not relevant.

[mystifyingpoi]

> The lack of control

This project literally sets the affinity. That's precisely the control you seem to negate.

[arccy]

k8s doesn't lack control, you can select individual nodes, AZs, regions, etc with the standard affinity settings.

[Spivak]

You need it to jump around because your RDS database might fail over to a different AZ.

Being able to move workloads around is kinda the point. The need exists irrespective of what you use to deploy your app.

[toredash]

The nice thing about this solution, its not limited to RDS. I used RDS as an example as many are familiar with it and are known to the fact that it will change AZ during maintenance events.

Any hostname for a service in AWS that can relocate to another AZ (for whatever reason), can use this.

[aduwah]

Mind you, that you are facing the same problem with any Autoscaling group that lives in multiple AZs. You don't need kubernetes for this

[toredash]

Agree, Kubernetes isn't for everyone. This solution came from an specific issue with a client which had ad hoc performance problems when a Pod was placed in the "in-correct" AZ. So this solution was created to place the Pods in the most optimal zone when they were created.

[kentm]

Sure, but there are scenarios and architectures where you do want the workload to jump around, but just to a subset of hosts matching certain criteria. Kubernetes does solve that problem.