[
https://issues.apache.org/jira/browse/IGNITE-26892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-26892:
------------------------------------
Labels: iep-142 ignite-3 (was: ignite-3)
> Thin clients: improve DNS resolution logic
> ------------------------------------------
>
> Key: IGNITE-26892
> URL: https://issues.apache.org/jira/browse/IGNITE-26892
> Project: Ignite
> Issue Type: Epic
> Components: thin clients ai3
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Priority: Major
> Labels: iep-142, ignite-3
> Fix For: 3.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h1. Motivation
> As a user, I want to leverage DNS to keep the client connected to all cluster
> nodes, even in the face of topology changes.
> h1. Requirements
> 1. When a host name is provided in IgniteClientConfiguration#addresses, the
> client should resolve it and use all returned IPs as potential node addresses
> 2. Resolve all known host names again and connect to newly discovered
> addresses:
> - On any connection error (might indicate node failure)
> - On primary replica change (might indicate topology change)
> - On timer (to handle DNS caching)
> h1. Usage Examples
> h2. Kubernetes Headless Service
> K8s [headless
> service|https://kubernetes.io/docs/concepts/services-networking/service/#headless-services]
> approach is typically used for distributed systems (Redis, Cassandra, Kafka,
> etc).
> * One host name “my-db.default.svc.cluster.local” resolves to all pod
> addresses
> * Only “ready” pods are returned by default
> * If a node is not in the cluster yet, it is not “ready” (use REST API as a
> readiness probe)
> * Pods come and go, their IPs can change, K8s handles that
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
