Controlling the services created for ElasticSearch in Kubernetes

I'm currently trying to use Elasticsearch with Consul, and there's an issue relating to the services that are created using the operator pattern.

elastic-search-es-default         ClusterIP   None            <none>        9200/TCP   24m
elastic-search-es-http            ClusterIP   xx.xx.xx.xx     <none>        9200/TCP   24m
elastic-search-es-internal-http   ClusterIP   xx.xx.xx.xx     <none>        9200/TCP   24m
elastic-search-es-transport       ClusterIP   None            <none>        9300/TCP   24m

Consul randomly picks one of these services and connects to it, but that's then causing routing issues for anything that wants to connect (for example the licensing requests that operator makes).

Is it possible to just have one service rather than multiple services being created? If not, is it possible to set up each of these services on a different port?

This is proving to be quite complex to resolve and any help would be appreciated.

Consul randomly picks one of these services and connects to it

I'm curious, what kind of problem do you want to solve with the addition of Consul to ES?
Is it not possible to give a specific service to Consul?

Is it possible to just have one service rather than multiple services being created? If not, is it possible to set up each of these services on a different port?

No, these services are managed by ECK and cannot be modified.

It looks like Consul only accepts a one to one relationship between pods and services (I'm not sure how sensible an idea that is), and from what I can tell there is no way to specify which service relates to which pod, but I have an open ticket with Consul asking if there is any way to resolve this.

The idea is to use Consul service discovery for use across multiple clusters, and the service mesh to provide secure communication between services. I was planning on using FileBeat to send messages to Elasticsearch from multiple clusters, and also from legacy applications outside of Kubernetes. Ideally I would use the Gateway API provided by Consul to provide access to any services we want to make available outside of the cluster.

I don't think you need service mesh for this :

  • an ingress can expose your logstash or Elasticsearch endpoint to anyone outside the cluster who wanna send data. If no idea, I would recommend Traefik proxy from Containous.

  • in most of ingress manager you can choose to decode traffic when it enters the cluster or (what you want) when it gives it to the pod (generally it's something like scheme: https, termination: passthrough, depending of your ingress manager)

  • If you wanna encryption for all the communication in the cluster, you should do it via your SDN (calico, flannel...) by working on OSI lvl 2, most of them offers it via a vxlan configuration.
    Let me explain: your SDN will have a data plane on each node (like bird & felix for calico) to ensure the traffic work well, and will use it for the encryption. But a service mesh will add a sidecar for each pod managed (except maesh which has one per node), so you add a lot of "pods in the middle" that may slow down or cause outages.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.