Max, That improvement automates the cluster discovery if both the cluster and thin clients are deployed *inside* of Kubernetes. That's my reading of the ticket's description. While you're referring to the case when the client is deployed outside of a K8S environment.
@Vladimir Pligin <vpli...@gridgain.com>, could you please join the thread. I've seen you joined the discussion in JIRA. - Denis On Wed, Aug 12, 2020 at 12:06 PM Max Timonin <timonin.ma...@gmail.com> wrote: > Hi, Igniters > > I'm now discovering the issue > https://issues.apache.org/jira/browse/IGNITE-13204 and wondering what is a > case that requires a client to be able to discover a cluster? > > I believe that discovery is a goal of kubernetes itself. We could assign a > DNS name for a Service [1] and then any request to the Service will be > forwarded to any of Ignite pods behind it. So there is no need to extract > pods IP to provide the connection. For example, I've configured a k8s > service with name "ignite" and port mapping 10800:9888. Then just connect > to it with sqlline by a string "ignite:9888". > > I think that it's OK that clients should be configured with those settings > as they aren't changed during cluster live. > > Also k8s provides SessionAffinity [2] to guarantee forwarding traffic from > one client to the same pod for every request. So there is no need to > provide IP for a specific pod if a state is required. > > Maybe I'm missing something about this feature? Could somebody provide more > details for this task? > > Below is the example config and connection string: > > apiVersion: v1 > kind: Service > metadata: > name: ignite > spec: > ports: > - port: 9888 > targetPort: 10800 > selector: > app: ignite > > ./bin/sqlline.sh --verbose=true -u jdbc:ignite:thin://ignite:9888 > 0: jdbc:ignite:thin://ignite:9888> > > [1] https://kubernetes.io/docs/concepts/services-networking/service/ > [2] > > https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-userspace >
