>
> Erick, even if we give service as a contact point datastax driver will
> calculate IPs of topology to connect the cluster. So I think as John
> proposed in answer to similar question, after driver initialization in case
> of total outage of Cassandra cluster, bouncing of application is the only
Erick, even if we give service as a contact point datastax driver will
calculate IPs of topology to connect the cluster. So I think as John
proposed in answer to similar question, after driver initialization in case
of total outage of Cassandra cluster, bouncing of application is the only
option.
Pushpendra,
I would recommend using an Ingress service like Envoy or Kong to manage
your communication. You get other things besides network connection
management such as security through mTLS. I wrote a short blog about this
which will be going up on New Stack hopefully soon.
Chris Bradford also
Use the service as contact points, not the IPs since they're ephemeral.
Even when all pods get replaced, they will still be accessible via the
service. Cheers!
>
Thank you John for mentioning the liveness probe. This is something I
didn't think about.
Regards,
Pushpendra
On Fri, Aug 7, 2020 at 8:50 AM John Sanda wrote:
> It is worth mentioning that depending on how you configure your client
> application deployment, you should not have to worry about bo
It is worth mentioning that depending on how you configure your client
application deployment, you should not have to worry about bouncing the
driver. If you add a liveness probe for your client deployment that relies
on the driver being able to connect to the cluster, then kubernetes will
restart
Hi Pushpendra
You should use the headless service, e.g.,
// Note that this code snippet is using v3.x of the driver.
// Assume the service is deployed in namespace dev and is
// named cassandra-service. The FQDN of the service would then
// be cassandra-service.dev.svc.cluster.local. If your clie
