Linkerd
Linkerd is a service mesh for Kubernetes. It places a small proxy beside selected workloads so you can observe, secure, and manage service-to-service traffic without changing application code.
itCloud native tools and technologies | OpenSkills.info
Intro
Linkerd
Linkerd is a service mesh for Kubernetes. A service mesh adds a dedicated infrastructure layer to communication between workloads. Linkerd uses that layer to report traffic behavior, encrypt connections between meshed pods, balance requests, and enforce traffic policy.
The central mental model is a proxy beside each meshed workload, guided by a shared control plane.
Kubernetes workload Kubernetes workload
application -> outbound proxy == mTLS ==> inbound proxy -> application
^ ^
| discovery, identity, |
| and policy |
+------ control plane -----+
The proxies form the data plane. They handle live traffic. The control plane supplies discovery, identity, and policy information. The Linkerd command-line interface, or CLI, helps you install, inspect, and troubleshoot both planes.
Why a service mesh exists
Distributed applications turn local function calls into network requests. Those requests can fail because a destination is unavailable, slow, overloaded, incorrectly addressed, or blocked by policy. Operators also need to know which workload called which destination and whether the request succeeded.
You can address each concern inside every application. That approach repeats client libraries, certificate handling, metrics, and policy logic across languages and teams. A service mesh moves common traffic behavior into infrastructure proxies. Applications continue to use normal Kubernetes Services while the proxies observe and manage connections.
This separation has a cost. Every meshed pod gains another container and every meshed connection passes through proxies. The mesh also introduces certificates, control-plane components, policy resources, metrics, and upgrade work. Adopt Linkerd when consistent traffic controls justify that operational responsibility.
Architecture
Linkerd has three visible operating surfaces: the CLI, the control plane, and the data plane.
The CLI
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://linkerd.io/docs/overview/
Supports
- Linkerd as a Kubernetes service mesh
- Control-plane and data-plane model
- Transparent per-workload proxies
- Open source and CNCF graduated project status
- https://linkerd.io/docs/reference/architecture/
Supports
- CLI, control-plane, and data-plane responsibilities
- Destination, identity, and proxy-injector component roles
- Inbound and outbound proxy responsibilities
- Native sidecar deployment and traffic redirection
- https://linkerd.io/docs/features/proxy-injection/
Supports
- Injection annotations and admission behavior
- Pod-template mutation and new-pod requirement
- https://linkerd.io/docs/tasks/adding-your-service/
Supports
- Incremental meshing workflow
- Injection and rollout verification
- https://linkerd.io/docs/features/telemetry/
Supports
- HTTP and TCP metric scopes
- Viz installation and observation surfaces
- Short bundled Prometheus retention
- https://linkerd.io/docs/tasks/exporting-metrics/
Supports
- Proxy metric export options
- Need for an external store for durable history
- Prometheus federation and direct scraping paths
- https://linkerd.io/docs/features/automatic-mtls/
Supports
- Automatic mTLS between meshed pods
- Unmeshed and skip-port coverage boundaries
- Trust-anchor expiration and rotation concerns
- https://linkerd.io/docs/features/protocol-detection/
Supports
- HTTP protocol detection and opaque TCP behavior
- Application TLS visibility boundary
- Service appProtocol and opaque-port configuration
- Skip-port behavior
- https://linkerd.io/docs/features/retries-and-timeouts/
Supports
- HTTP and gRPC timeout and retry controls
- Retry composition and security considerations
- https://linkerd.io/docs/reference/retries/
Supports
- Retry eligibility and retry budgets
- Retry amplification risk
- https://linkerd.io/docs/reference/authorization-policy/
Supports
- Default and dynamic authorization policy
- Server, HTTPRoute, authentication, and AuthorizationPolicy roles
- Audit and deny behavior
- https://linkerd.io/docs/tasks/install/
Supports
- Kubernetes and Gateway API requirements
- CLI and Helm installation choices
- Pre-install and post-install checks
- Edge artifacts and vendor stable distributions
- https://linkerd.io/docs/going-to-production/
Supports
- Production availability, identity, resource, and lifecycle planning
- Metrics and certificate management responsibilities
- https://linkerd.io/docs/tasks/validating-your-traffic/
Supports
- Verifying meshed connections and mTLS identities
- Traffic-oriented validation after injection
- https://github.com/sindresorhus/awesome
Supports
- Discovery path to the Awesome Kubernetes list
- https://github.com/ramitsurana/awesome-kubernetes
Supports
- Kubernetes ecosystem discovery source
- https://github.com/wmariuss/awesome-devops
Supports
- Discovery of Linkerd, Meshery, Prometheus, Grafana, and Flagger as relevant ecosystem projects
- https://prometheus.io/docs/introduction/overview/
Supports
- Prometheus time-series collection, querying, and alerting purpose
- https://grafana.com/orgs/linkerd
Supports
- Published Linkerd Grafana dashboard collection
- https://linkerd.io/docs/tasks/grafana/
Supports
- Grafana use with Linkerd metrics and dashboards
- https://docs.flagger.app/tutorials/linkerd-progressive-delivery
Supports
- Flagger can use Linkerd routing and metrics for progressive delivery
- https://meshery.io/extensions
Supports
- Meshery extension catalog and cloud-native infrastructure integrations
