Kloud Native Blog

What is distributed tracing?  Distributed tracing is a method for monitoring microservice applications. Using distributed tracing, we can follow the requests as they travel through the different pieces of the system being monitored.  Envoy generates a unique request ID and tracing information and stores it as part of HTTP headers whenever a request enters the service mesh. Any application can then forward these headers to other services to create a full trace through the system.  A distributed trace is a collection of spans. As requests flow through different system components, each component contributes a span. Each span has a name, start and finish timestamp, a set of key-value pairs called tags and logs, and a span context.  Tags get applied to the whole span, and we can use them for querying and filtering. Mesh Observability with Kiali  Kiali is a management console for Istio-based service mesh. It provides dashboards, observability and lets us operate the mesh with robust configur

Thanks to the sidecar deployment model where Envoy proxies run next to application instances and intercept the traffic, these proxies also collect metrics.  The metrics Envoy proxies collect and helping us get visibility into the state of your system. Gaining this visibility into our systems is critical because we need to understand what's happening and empower the operators to troubleshoot, maintain, and optimize applications.  Istio generates three types of telemetry to provide observability to services in the mesh:  • Metrics  • Distributed traces  • Access logs  Metrics  Istio generates metrics based on the four golden signals: latency, traffic, errors, and saturation.  Latency represents the time it takes to service a request. These metrics should be broken down into latency of successful requests (e.g., HTTP 200) and failed requests (e.g., HTTP 500).  Traffic measures how much demand gets placed on the system, and it's measured in system-specific metrics. For example, HTT

lstio is an open-source implementation of a service mesh. At a high level, Istio supports the following features:  1. Traffic management  Using configuration, we can control the flow of traffic between services. Setting up circuit breakers, timeouts, or retries can be done with a simple configuration change.  1. Observability  lstio gives us a better understanding of your services through tracing, monitoring, and logging, and it allows us to detect and fix issues quickly.  1. Security  lstio can manage authentication, authorization, and encryption of the communication at the proxy level. We can enforce policies across services with a quick configuration change.  lstio Components  lstio service mesh has two pieces: a data plane and a control plane.  When building distributed systems, separating the components into a control plane and a data plane is a common pattern. The components in the data plane are on the request path, while the control plane components help the data plane to do it

A service mesh is defined as a dedicated infrastructure layer for managing service-to-service communication to make it manageable, visible, and controlled. In some versions of the definition, you might also hear about how a service mesh can make the communication between services safe and reliable. If I had to describe service mesh with a more straightforward sentence, I would say that the service mesh is all about the communication between services.  But how does the service mesh help with communication? Let's think about the communication logic and where it usually lives. The communication logic is any code that handles the inbound or outbound requests, the retry logic, timeouts, or even perhaps traffic routing. In most cases, developers build this logic as part of the service. So anytime service A calls service B, the request goes through this communication code logic, which decides how to handle the request.  We mentioned that we might end up with a significant number of servic

Peer and Request Authentication  Istio provides two types of authentication: peer authentication and request authentication.  Peer authentication  Peer authentication is used for service-to-service authentication to verify the client that's making the connection.  When two services try to communicate, mutual TLS requires both to provide certificates so both parties know who they are talking to. If we want to enable strict mutual TLS between services, we can use the PeerAuthentication resource to set the mTLS mode to STRICT]  Using the PeerAuthentication resource, we can turn on mutual TLS (mTLS) across the mesh without making code changes.  However, Istio also supports a graceful mode where we can opt into mutual TLS one workload or namespace at the time. This mode is called permissive mode.  Permissive mode is enabled by default when you install Istio. With permissive mode enabled, if a client tries to connect to me via mutual TLS, I'll serve mutual TLS. If the client doesn

Mutual TLS  The communication between workloads in services goes through the Envoy proxies. When a workload sends a request to another workload using mTLS, Istio re-routes the traffic to the sidecar Envoy.  Once the mTLS connection is established, the request is forwarded from the client Envoy proxy to the server-side Envoy proxy. Then, the sidecar Envoy starts an mTLS handshake with the server-side Envoy. During the handshake, the caller does a secure naming check to verify the service account in the server certificate is authorized to run the target service. After the authorization on the server-side, the sidecar forwards the traffic to the workload.  We can change the mTLS behavior in the service's destination rule. The supported TLS modes are DISABLE (no TLS connection), SIMPLE (originate a TLS connection to the upstream endpoint), MUTUAL (uses mTLS by presenting client certificates for authentication), and ISTIO_MUTUAL (similar to MUTUAL, but uses Istio's automatically gen