skip to Main Content

Given that Kubernetes doesn’t offer full visibility into how services interact with each other I want to derive and map services automatically. For eg as shown in the below diagram, how can we derive that the payment service interacts with the cart service and cart service interacts with catalogue and redis.

So far what I had tried is,

  1. kubectl get services command – This command only gives the list of services but does not hint on any communication happening between the services.
  2. Tried Kubeview -> This plots only the deployment architecture and gives a graphical representation but mapping between various services is not derived.

So what is the easiest way to derive information about services interacting with each other and what could be the data source for this information in Kubernetes?

enter image description here

2

Answers


  1. You can consider linkerd or other similar tools which offer service Observability

    A service mesh like Linkerd is a tool for adding observability, security, and reliability features to “cloud native” applications by transparently inserting this functionality at the platform layer rather than the application layer.

    service-mesh

    For example, in below screenshot you can see how gate-way service interact with another service

    enter image description here

    It will also show how the request is going, amount of request with inbound and outbound

    enter image description here

    So in your case,if payment app is part of mesh you will able to see the inbound and outbound for the service along with requests info.

    linkerd-install-helm

    Service meshes have three main goals around interservice communication:

    • Connectivity
    • Security
    • Observability
    Login or Signup to reply.
  2. We faced this as well when we were building Otterize — we needed something to map "who is talking to who" in order to bootstrap our solution, but every tool seemed to be ill suited for the task of simply creating a "network map" without all sorts of stuff we didn’t want. We ended up rolling our own, and open sourced it: https://github.com/otterize/network-mapper .

    It’s based on combining information from DNS queries (actually just query responses) as well as detecting open connections, which gives you an IP-level network map, and then adding a simple resolution heuristic to derive a logical name-level map. You can read more details in this blog post, by one of the guys who built the tool: https://otterize.com/blog/kubernetes-traffic-discovery .

    Hope this helps!

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search