Comment by ruuda
9 hours ago
> 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.
> 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.
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.
> The lack of control
This project literally sets the affinity. That's precisely the control you seem to negate.
k8s doesn't lack control, you can select individual nodes, AZs, regions, etc with the standard affinity settings.
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
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.
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.
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.
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.