Istio is a service mesh that supports running distributed microservice architectures. It’s a prominent vehicle that typically runs in Kubernetes to control inter-pod and inter-service traffic from Kubernetes workloads. For this, Istio uses Kubernetes Mutating Admission Webhooks for automatically injecting a sidecar proxy into pods. These proxy containers run next to the user containers in pods and intercept the network traffic of the pods.
The standard configuration of Istio and its sidecar proxies is to route traffic only within the service mesh. As a consequence, any egress traffic to services and endpoints external to Istio is blocked. However, Istio allows extending the service mesh by external services so that these external endpoints can be reached from the mesh. Dynatrace endpoints can be added to the mesh using this approach.
Bringing enterprise-class monitoring to Istio
Istio provides two ways to configure the system for controlling egress traffic.
- Exposing external services to Istio by defining
ServiceEntry
configurations—This option enables access to these external services from within the Istio-enabled pods and services. The traffic is then routed through the sidecar proxies. Service entries respect network protocols on different layers like TCP and HTTPS and allow the configuration of rules based on hostnames. - Bypassing Istio proxies for a specific range of IPs—When setting up Istio, you can define the IP ranges Istio should take care of. This way, you can also configure specific IP ranges the sidecar proxies should not intercept. This option requires updating the Istio deployment whenever the IPs of the external endpoints change.
Dynatrace customers can extend the list of endpoints for OneAgents running in their environments pretty flexibly by adding and removing ActiveGate nodes. Given the higher flexibility of service entries and the full-control over enabling/disabling routing to endpoints, we recommend using the ServiceEntry
approach for enabling egress traffic of the agents to the Dynatrace environment.
Please refer the documentation for Kubernetes and OpenShift for setting up the service entries for your Dynatrace environment.
Tracing requests with Dynatrace
OneAgents deployed to the worker nodes automatically injects code modules into containerized processes that are running in the pods. This works also for Istio-enabled environments.
This way, OneAgent not only provides full visibility into requests between services (tracing) but also code-level hotspot analytics and diagnostics with no code changes.
This allows us to integrate request tracing information with method hotspot information from the respective application runtimes and even connect method call graphs across traces.
What’s next
We plan to integrate Istio detection and configuration for OneAgent into the Dynatrace OneAgent Operator. The operator will automatically configure Istio virtual services via the ServiceEntry
approach described above so that you no longer need to add and maintain Dynatrace endpoints in Istio by hand. We will also introduce dedicated technology types for Istio so that Istio-related processes are grouped together and are better integrated with filters.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum