Cloud Native 12 min read

Linkerd 2: Understand Service Mesh Terminology in 5 Minutes

This article explains core service‑mesh concepts—including API gateway, cluster, container, control and data planes, distributed tracing, egress, ESB, golden metrics, ingress, init containers, latency, Linkerd's architecture, load balancing, mTLS, multi‑cluster support, observability, reliability, sidecar proxies, and success rate—providing a concise reference for developers working with Kubernetes‑based meshes.

Hacker Afternoon Tea
Hacker Afternoon Tea
Hacker Afternoon Tea
Linkerd 2: Understand Service Mesh Terminology in 5 Minutes

API Gateway

API gateway

sits in front of applications to handle authentication, authorization, rate limiting and to provide a public access point. In contrast, a service mesh focuses on the operational logic between application components.

Cluster

In cloud‑native environments a cluster is a set of physical or virtual machines that form the hardware pool on which containers, orchestrated by systems such as Kubernetes, run. Each machine is called a node, and nodes are typically uniform, interchangeable and interconnected.

Container

A Container is a lightweight package of an application and its dependencies that runs in isolation on the host operating system ( OS) with strict resource limits. In a service‑mesh context, containers are promoted by Docker as lightweight alternatives to virtual machines ( VM), which in turn spurred the creation of orchestrators like Kubernetes that schedule containers across a cluster.

Control Plane

The control plane of a service mesh provides the commands and control signals required for the data plane to operate. It also offers an operator UI and API for configuring, monitoring and managing the mesh.

Data Plane

The data plane consists of the sidecar proxies that intercept mesh traffic. It is responsible for collecting metrics, observing traffic and enforcing policies.

Distributed Tracing

In microservice systems a single client request often triggers a chain of requests across multiple services. Distributed tracing records these requests for performance monitoring or debugging by instrumenting services to emit span data that is aggregated in a central store.

Egress

Within a Kubernetes cluster, egress refers to traffic leaving the cluster. Unlike ingress, there is no built‑in Kubernetes egress resource; egress control and monitoring are typically implemented at the networking/CNI layer or via an explicit egress proxy.

Enterprise Service Bus (ESB)

An ESB is an older architectural pattern for managing communication, data transformation, routing and queuing in SOA systems. Modern microservice applications often replace most ESB functionality with a service mesh such as Linkerd, gaining better separation of concerns and reduced single points of failure ( SPOF).

Golden Metrics

Golden metrics (or golden signals) are the core health indicators of an application: latency, traffic volume, error rate, and saturation. Linkerd 's golden metrics omit saturation.

Ingress

Ingress

runs inside a Kubernetes cluster and handles traffic entering the cluster from external sources. It is typically backed by an API gateway and differs from internal mesh traffic because it originates from customers or third parties.

Init Container

An Init Container runs at the start of a pod's lifecycle before the application containers. Common uses include rewriting network rules, collecting secrets, and copying files. Linkerd uses an init container to update network rules so that the Linkerd proxy container can bootstrap all TCP traffic for the pod; the init container then terminates.

Latency

Latency

measures the time an application takes to perform an action, such as handling a request. In service‑mesh terminology it is measured at the response level and is typically expressed as percentiles (p50, p95, p99, etc.).

Linkerd

Linkerd

was the first project to define the term “service mesh”. First released in 2016, it aims to be the fastest and most lightweight service mesh in the Kubernetes ecosystem and is a CNCF graduated project.

Load Balancing

Load balancing distributes work across equivalent endpoints. While Kubernetes provides connection‑level load balancing, Linkerd performs request‑level load balancing, allowing it to consider endpoint performance. It supports round‑robin, least‑loaded, and an EWMA (exponentially‑weighted moving average) latency‑aware algorithm that reacts quickly to changes in endpoint latency profiles.

Mutual TLS (mTLS)

Mutual TLS authenticates and encrypts connections between two endpoints by verifying both sides' identities, extending the standard TLS model which typically only verifies the server.

Multi‑Cluster

In Kubernetes, “multi‑cluster” refers to running an application across multiple clusters. Linkerd 's multi‑cluster feature provides seamless, secure cross‑cluster communication that remains transparent to the application, even over the public Internet.

Observability

Observability is the ability to understand system health and performance from generated data. In a service mesh it includes reporting golden metrics, service topology graphs, traffic sampling, and other mesh‑specific data.

Reliability

Reliability measures how well a system responds to failures. A service mesh can improve reliability by applying retries, timeouts, intelligent load balancing, and traffic shifting for fault‑tolerant microservice interactions.

Sidecar Proxy

A sidecar proxy is deployed alongside an application in the mesh (as a container in a Kubernetes pod). It intercepts inbound and outbound network calls and implements control‑plane logic. Linkerd uses a Rust‑based Linkerd2‑proxy, which is lighter and easier to operate than generic proxies such as Envoy or NGINX.

Success Rate

The Success rate is the percentage of requests that receive successful responses. For HTTP traffic, 2xx and 4xx responses are considered successful, while 5xx responses indicate failure. A high success rate signals normal application operation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

cloud nativeobservabilitykubernetesload balancingService MeshLinkerdmTLS
Hacker Afternoon Tea
Written by

Hacker Afternoon Tea

You might find something interesting here ^_^

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.