The Otterize network mapper creates a map of in-cluster traffic by (1) capturing DNS traffic and (2) inspecting active connections in the same manner
netstat does, then resolving the IP addresses participating in connections to the Pods, and crawling up the ownership of the Pod until it reaches the root object. See Service identities to learn more on how service name resolving happens. The network mapper continues building the network map as long as it's deployed.
You can then use the Otterize CLI to list the traffic by client, reset the traffic the mapper remembers, or export it as JSON or YAML, which serves as ClientIntents Kubernetes resources). ClientIntents can be consumed by the Otterize intents operator to apply network policies or Kafka ACLs to your cluster, implementing intent-based access control.
To get started, follow the quick hands-on tutorial or the quick, more visual tutorial. Here's an example output for running the network mapper following the example:
cartservice in namespace otterize-ecom-demo calls:
checkoutservice in namespace otterize-ecom-demo calls:
frontend in namespace otterize-ecom-demo calls:
loadgenerator in namespace otterize-ecom-demo calls:
recommendationservice in namespace otterize-ecom-demo calls:
How does the network mapper work?
- Sniffer - the sniffer is deployed to each node using a DaemonSet, and is responsible for capturing node-local DNS traffic and inspecting open connections.
- Mapper - the mapper is deployed once, and resolves service names using the Kubernetes API with traffic information reported by the sniffers.
DNS is a common network protocol used for service discovery. When a pod (
checkoutservice) tries to connect to a Kubernetes service
orderservice) or another pod, a DNS query is sent out. The network mapper watches DNS responses and extracts the IP addresses, which are used for the service identity resolving process.
Active TCP connections
DNS responses will only appear when new connections are opened. To handle long-lived connections, the network mapper also queries open TCP connections in a manner similar to
ss. The IP addresses are used for the service identity resolving process, as above.
Deploying the network mapper
To deploy the network mapper, use the Helm chart.
You can override the service name the network mapper uses when it computes the service name using a pod annotation.
|Otterize-wide override for this service's name.||See Service identities|