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.
API Gateway
API gatewaysits 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
Ingressruns 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
Latencymeasures 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
Linkerdwas 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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
