At a high level, Linkerd consists of a control plane and a data plane.

The control plane is a set of services that provide overall control over Linkerd.

The data plane consists of micro-proxies running “alongside” each service instance as sidecars in pods. These agents automatically process all TCP traffic to and from the service and communicate with the control plane for configuration.

Linkerd also provides a CLI that can be used to interact with the control plane and data plane.

A series of

Chinese Handbook (hacker-linner.com)

CLI

The Linkerd CLI typically runs outside the cluster (for example, on your local machine) to interact with Linkerd.

Control plane

The Linkerd control plane is a set of services that run in a dedicated Kubernetes namespace (Linkerd by default). The control plane has several components listed as follows.

Target Service (Destination)

The data plane agent uses the Destination service to determine various aspects of its behavior. It is used to get service discovery information (that is, the location from which a particular request was sent and the TLS identity expected on the other end); Get policy information about what types of requests are allowed; Gets service profile information for notifying each routing metric, retry, and timeout; And more useful information.

Identity Services (IDENTITY)

The Identity service acts as a TLS certificate authority, accepting CSRS from agents and returning signed certificates. These certificates are issued at agent initialization and are used for agent-to-agent connections to implement mTLS.

Proxy Injector

Proxy Injector is a Kubernetes Admission Controller that receives a Webhook request every time a POD is created. This Injector checks resources for the Linkerd-specific annotation (Linkerd. IO/Inject: enabled). While the annotation exists, the Injector changed the POD specification and added the proxy-init and Linkerd-proxy containers and the associated startup time configuration to the POD.

Data plane

The Linkerd data plane contains ultralight micro-agents deployed as Sidecar containers within the application Pod. These agents transparently intercept TCP connections in and out of every POD, thanks to iptables rules made by Linkerd-init (or, by Linkerd’s CNI plug-in).

Agent (Linkerd2 – proxy)

Linkerd2-proxy is an ultra-light, transparent micro-proxy written in Rust. Linkerd2-proxy is designed specifically for service Mesh use cases, not as a generic proxy.

The functions of the proxy include:

  • HTTP,HTTP/2And anyTCPTransparent, zero-configuration proxy for the protocol.
  • HTTP 和 TCPAutomatic flowPrometheusExport indicators.
  • Transparent, zero configurationWebSocketThe agent.
  • Automatic, delay aware, no7Layer load balancing.
  • nonHTTPAutomatic flow control4Layer load balancing.
  • automaticTLS.
  • On-demand diagnosisTap API.
  • There’s more.

The proxy supports service discovery through DNS and the target gRPC API.

  • Github.com/linkerd/lin…

You can read more about these micro-agents here:

  • Why doesn’t Linkerd use Envoy
    • Linkerd. IO / 2020/12/03 /…
  • Linkerd’s most advanced Rust agent linkerd2-proxy
    • Linkerd. IO / 2020/07/23 /…

Linkerd init container

The Linkerd-init container is added to each grid POD as a Kubernetes Init container that runs before any other containers start. It uses iptables to proxy all TCP traffic, all traffic in and out of Pod.

  • Kubernetes. IO/docs/concep…