So if one of the pod goes down, everything goes down? #1483
-
I'm currently using an on-demand ec2 instance in aws to host a rabbitmq server. It's been great so far then I stumble upon this integration to kubernetes and decided to try it out. From my observation, regardless of how many I put in the replica when I create the instance, If I try to delete one of the pods, everything goes down even the admin site. Is this by design? Kinda hoping it will be similar to a regular deployments where the application will still be up only if there's at least one pod that's working |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
One Pod down does not cause the entire cluster to go down. It would be a pretty bad distributed data service if it did 😉 You have to make to be using Quorum Queues if you want to replicate your data inside the queues. Streams also replicate the data. There are a few use cases for classic queues, like single active consumer, but bear in mind that replicating data a.k.a. queue mirroring is deprecated in classic queues. One gotcha with Quorum Queues is the initial replication factor in environments that grow afterwards. If you have 1 replica, declare a quorum queues, and then scale your cluster to 3 replicas, your QQ will remain with just 1 replica, because, at declaration time, there was only one node available. You will have to grow the queue. In Kubernetes, you have to understand how things are wired underneath regarding networking. Why you observe the "admin site go down" depends entirely on how you access the management UI. If you are using |
Beta Was this translation helpful? Give feedback.
-
Questions like this (that make bold claims without providing any details, logs, metrics or other details) are next to impossible to answer. Kinda hoping that those seeking free support from OSS maintainers would at least bother a little bit to provide some relevant information. |
Beta Was this translation helpful? Give feedback.
One Pod down does not cause the entire cluster to go down. It would be a pretty bad distributed data service if it did 😉
You have to make to be using Quorum Queues if you want to replicate your data inside the queues. Streams also replicate the data. There are a few use cases for classic queues, like single active consumer, but bear in mind that replicating data a.k.a. queue mirroring is deprecated in classic queues.
One gotcha with Quorum Queues is the initial replication factor in environments that grow afterwards. If you have 1 replica, declare a quorum queues, and then scale your cluster to 3 replicas, your QQ will remain with just 1 replica, because, at declaration time, there was on…