-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are applications deployed highly available? #106
Comments
I haven't tested this (yet), but I think the app has settings for this? Under that App, resources, you can setup autoscaling and min/max pods. Are you looking for a pod on each node? that's a daemonset no? in K8s world that's typically setup because your app needs node information, not to be highly available. If you want HA, then the multiple pods option should cover it in K8s land. HTH |
It is possible to configure the pod affinity. But only by editing the CRD. It is not implemented in the UI yet. But this would be a nice feature. |
but why pod affinity, that's not the best HA solution. |
@jfmatth the problem with just adding more pods without affinity is, you are never sure where they are gonna be deployed. In the worst case, all pods are deployed on the same node. And if this particular node goes down, you will have a service interrupt until they are spun up on a different node (if there are enough resources left.) So having an affinity in place, distributes the pods as soon as possible. |
Not to be-labor the point, I still don't think affinity is the right solution to HA, which is what the user wanted. To your point, if all pods are deployed on the same node, then IMHO there are other issues with the cluster, but I've not worked in large clusters before so can't say for sure. Seems like using PA for HA isn't the right approach. |
Actually use case of Daemonset and what I am proposing are different... daemonsets could be log collectors and services like that which need to run on all nods... |
I can appreciate the use case, but for Kubero, it just seems too specific and fraught with complexity for a system that is trying to make pushing apps to K8s easy. I suspect if you need such consensus, you should build the app in a container, and deploy with Helm or something that is closer to the 'metal' than Kubero. But, I'm not the maintainer of Kubero, so he'll have to decide 😄 |
We can try with topologySpreadConstaints. |
Although as far as I understand from docs they are not, but it will be great if we could implement deploy as highly available system, which basically tries to create 3 copies of application with pod affinity to deploy on different nodes ensuring high availability
The text was updated successfully, but these errors were encountered: