Observability
Maps pod-to-pod traffic, pod-to-Internet traffic, and even AWS IAM traffic, with zero-config.
The Otterize network mapper is a zero-config tool that aims to be lightweight and doesn't require you to adapt anything in your cluster. Its goal is to give you insights about traffic in your cluster without a complete overhaul or the need to adapt anything to it, unlike other solutions, which may require deploying a new CNI, a service mesh, and so on.
You can use the Otterize CLI to list the traffic by client, visualize the traffic, export the results as JSON or YAML, or reset the traffic the mapper remembers.
Example output after running otterize network-mapper visualize
on the Google Cloud microservices demo:
The same microservices demo in the Otterize Cloud access graph, as it appears when you choose to connect the network mapper to Otterize Cloud:
Example output after running otterize network-mapper list
on the Google Cloud microservices demo:
cartservice in namespace otterize-ecom-demo calls:
- redis-cart
checkoutservice in namespace otterize-ecom-demo calls:
- cartservice
- currencyservice
- emailservice
- paymentservice
- productcatalogservice
- shippingservice
frontend in namespace otterize-ecom-demo calls:
- adservice
- cartservice
- checkoutservice
- currencyservice
- productcatalogservice
- recommendationservice
- shippingservice
loadgenerator in namespace otterize-ecom-demo calls:
- frontend
recommendationservice in namespace otterize-ecom-demo calls:
- productcatalogservice
Try the quickstart to get a hands-on experience in 5 minutes.
Looking to map AWS traffic? Check out the AWS visibility tutorial.
helm repo add otterize https://helm.otterize.com
helm repo update
helm install network-mapper otterize/network-mapper -n otterize-system --create-namespace --wait
Mac
brew install otterize/otterize/otterize-cli
Linux 64-bit
wget https://get.otterize.com/otterize-cli/v1.0.10/otterize_linux_x86_64.tar.gz
tar xf otterize_linux_x86_64.tar.gz
sudo cp otterize /usr/local/bin
Windows
scoop bucket add otterize-cli https://github.com/otterize/scoop-otterize-cli
scoop update
scoop install otterize-cli
For more platforms, see the installation guide.
--set aws.visibility.enabled=true
. Label pods with network-mapper.otterize.com/aws-visibility: true
, and if connected to Otterize Cloud, the Cloud will combine the information to put together a map of accesses to AWS resources, which you can export as ClientIntents yamls for use with the Intents Operator.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.
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 netstat
or ss
. The IP addresses are used for the service identity resolving process, as above.
The Kafka watcher periodically examines logs of Kafka servers provided by the user through configuration, parses them and deduces topic-level access to Kafka from pods in the cluster.
The watcher is only able to parse Kafka logs when Kafka servers' Authorizer logger is configured to output logs to stdout
with DEBUG
level.
The Istio watcher, part of the Network mapper periodically queries for all pods with the security.istio.io/tlsMode
label, queries each pod's Istio sidecar for metrics about connections, and deduces connections with HTTP paths between pods covered by the Istio service mesh.
AWS IAM visibility consists of several components: a HTTP proxy that proxies AWS traffic for pods which you opt-in on using the label network-mapper.otterize.com/aws-visibility: true
, a webhook admission controller that patches Pods with that label as they are admitted to add a certificate for the HTTP proxy and direct DNS traffic for amazonaws.com to a DNS server belonging to the network mapper, and finally said DNS server which responds only to amazonaws.com requests and forwards the rest to the cluster's DNS server.
Service names are resolved in one of two ways:
otterize/service-name
label is present, that name is used.Deployment
named client
, which then creates and owns a ReplicaSet
,
which then creates and owns a Pod
, then the service name for that pod is client
- same as the name of the Deployment
.
The goal is to generate a mapping that speaks in the same language that dev teams use.The network mapper continuously builds a map of pod to pod communication in the cluster. The map can be exported at any time in either JSON or YAML formats with the Otterize CLI.
The YAML export is formatted as ClientIntents
Kubernetes resource files. Client intents files can be consumed by the Otterize intents operator to configure pod-to-pod access with network policies, or Kafka client access with Kafka ACLs and mTLS.
Explore our documentation site to learn how to:
To join the conversation, ask questions, and engage with other users, join the Otterize Slack!
The mapper reports anonymous usage information back to the Otterize team, to help the team understand how the software is used in the community and what aspects users find useful. No personal or organizational identifying information is transmitted in these metrics: they only reflect patterns of usage. You may opt out at any time through a single configuration flag.
To disable sending usage information:
--set global.telemetry.enabled=false
.OTTERIZE_TELEMETRY_ENABLED=false
.--telemetry-enabled=false
.If the telemetry
flag is omitted or set to true
, telemetry will be enabled: usage information will be reported.
Read more about it in the Usage telemetry Documentation