Skip to content
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

Cassandra-solo-service with clusterIP != None #650

Closed
rzmv opened this issue May 8, 2024 · 3 comments
Closed

Cassandra-solo-service with clusterIP != None #650

rzmv opened this issue May 8, 2024 · 3 comments
Labels
done Issues in the state 'done' enhancement New feature or request

Comments

@rzmv
Copy link

rzmv commented May 8, 2024

What is missing?

Ability to create cassandra-solo-service with a non None cluster IP address. Or is it possible? Or why is this not possible/bad practice?

Why is this needed?

In a 1-node Cassandra environment (test), it's easy to reconnect after a restart/failure. Because the ip remains the same.

@rzmv rzmv added the enhancement New feature or request label May 8, 2024
@burmanm
Copy link
Contributor

burmanm commented May 8, 2024

You should not trust the Pod IP to remain the same in a Kubernetes cluster due to the way the Pod IPs are allocated. You could however create an ingress with a static IP if that's the plan and just route that traffic to the pods.

Though I'm still wondering, why not just use the hostname inside Kubernetes if you're not connecting from outside?

@rzmv
Copy link
Author

rzmv commented May 8, 2024

@burmanm Do you mean the service hostname, like cassandra-solo-service..svc?

I use it, the use case: we have a lot of test k8s namespaces with single-node cassandra on board. And sometimes something happens, and the cassandra pods break. We test service with clusterIP (no None), and our app reconnects successfully, which does not happen with cluster IP = None.

Of course I can improve the app, but if it's just for testing, why shouldn't I use a service name and a clusterIP?

@rzmv rzmv closed this as completed May 13, 2024
@adejanovski adejanovski added done Issues in the state 'done' labels May 13, 2024
@burmanm
Copy link
Contributor

burmanm commented May 13, 2024

Well, I think the simplest way is to just create such service if the test requires it. Or, add a Endpoint to the existing service, so you can always find the IP address.

Additionally, in this test case, other options include using host networking (and using the node's IP) or adding the pod IP to the additional-seeds service's EndpointSlice (we don't remove it even if pod goes down).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
done Issues in the state 'done' enhancement New feature or request
Projects
No open projects
Archived in project
Development

No branches or pull requests

3 participants