I'm not sure what you mean by inside/outside of kubernetes. Service name is visible within k8s environment. I've described a case with connection from another pod that is part of k8s cluster.
To provide connection outside of Kubernetes one should configure Ingress [1]. It will have a fixed address assigned by a cluster administrator. Any request outside of k8s to the Ingress will be proxied inside k8s env to the Service and then to a pod automatically without need to provide any IP addresses in a client configuration. [1] https://kubernetes.io/docs/concepts/services-networking/ingress/ On Thu, Aug 13, 2020 at 1:39 AM Denis Magda <dma...@apache.org> wrote: > 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 > > >
