Spring Boot + k8s - autodiscovery solution

6/1/2021

Let's say I have such architecture based on Java Spring Boot + Kubernetes:

  • N pods with similar purpose (lets say: order-executors) - GROUP of pods
  • other pods with other business implementation

I want to create solution where: 1. One (central) pod can communicate with all/specific GROUP of pods to get some information about state of this pods (REST or any other way) 2. Some pods can of course be replicated i.e. x5 and central pod should communicate with all replicas

Is it possible with any technology? If every order-executor pod has k8s service - there is a way to communicate with all replicas of this pod to get some info about all of them? Central pod has only service url so it doesn't know which replica pod is on the other side.

Is there any solution to autodiscovery every pod on cluster and communicate with them without changing any configuration? Spring Cloud? Eureka? Consul?

P.S.

  • in my architecture there is also deployed etcd and rabbitmq. Maybe it can be used as part of solution?
-- cackoa
java
kubernetes
spring
spring-boot
spring-cloud

2 Answers

6/1/2021

I'm not familiar with java, but the concept is something I've done before. There are a few approaches you can do. One of them is using kubernetes events.

Your application should listen to kubernetes events (using a websocket). Whenever a pod with a specific label or labelset has been created, been removed or in terminating state, etc. You will get updates about their state, including the pod ip's. You then can do whatever you like in your application without having to contact the kubernetes api yourself in your application. You can even use a sidecar pod which listens to those events and write it to a file. By using shared volumes, your application can read that file and use the content of it.

-- Leroy
Source: StackOverflow

6/1/2021

You can use a "headless Service", one with clusterIP: none. The result of that is when you do an DNS lookup for the normal service DNS name, instead of a single A result with the magic proxy mesh IP, you'll get separate A responses for every pod that matches the selector and is ready (i.e. the IPs that would normally be the backend). You can also fetch these from the Kubernetes API via the Endpoints type (or EndpointSlices if you somehow need to support groups with thousands, but for just 5 it would be Endpoints) using the Kubernetes Java client library. In either case, then you have a list of IPs and the rest is up to you to figure out :)

-- coderanger
Source: StackOverflow