3 ms·

> 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 Kubernete

by ruuda 1y 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.

arccy 1y ago
k8s doesn't lack control, you can select individual nodes, AZs, regions, etc with the standard affinity settings.
mystifyingpoi 1y ago
> The lack of control This project literally sets the affinity. That's precisely the control you seem to negate.
toredash 1y ago
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.
glennpratt 1y ago
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.
Spivak 1y ago
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 1y ago
  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 1y ago
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
indemnity 1y ago
> 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.
kentm 1y ago
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.

by ruuda 1y ago

arccy 1y ago

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

mystifyingpoi 1y ago

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

toredash 1y ago

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.

glennpratt 1y ago

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.

Spivak 1y ago

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 1y ago
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 1y ago

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

indemnity 1y ago

> 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.

kentm 1y ago

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.