To deploy Linkerd's sidecar proxy for a running microservice, the proxy definition needs to be applied to the pod's resource definition. This configuration setup can be done through the Linkerd CLI (https://linkerd.io/2/architecture/#cli). The CLI is the recommended tool for installing the Linkerd control plane. Once the control plane has been deployed, deploying the Linkerd sidecar proxy to an application is simple, as is the case with Istio. Follow these steps:

1. Annotate the namespace, pod, or deployment with  linkerd.io/inject: enabled. 
2. The Linkerd sidecar will be injected automatically through the Kubernetes admission webhook controller.
3. If a particular pod doesn't need a sidecar, that pod can be annotated as linkerd.io/inject: disabled. 
4. To add Linkerd to a running microservice service, run the linkerd inject command.
5. This will add a linkerd-init and provision a sidecar proxy for every service pod that has been defined in the deployment YAML.
6. Deploying this configuration file through kubectl will trigger rolling updates and replace old pods with new ones.
7. The newly added pods can be viewed on the Linkerd dashboard.

In the next chapter, we will show you a step-by-step deployment of the Linkerd control and data plane.

For now, let's assume that Linkerd is already installed and that we've annotated the default namespace with linkerd.io/inject: enabled. Next, we need to deploy the application. During deployment, the Linkerd sidecar proxy will be injected automatically. Here is the code example:

$ kubectl annotate namespace default linkerd.io/inject=enabled

$ kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml

If you check the pod, you should see that the sidecar is injected automatically with 2/2 under the READY column:

$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
busybox   2/2     Running   0          9s

If you describe the busybox pod, you will see details about the Linkerd sidecar proxy.

Notice that the busybox pod has one init container called linkerd-init that puts entries in the iptables to route the traffic to the proxy. The busybox container and the sidecar proxy's linkerd-proxy containers are created with a distinction of (2/2) with proper command-line parameters. 

Let's look at what's within the busybox containers:

$ kubectl describe pod busybox
Name: busybox
Namespace: default
...
Containers:
 busybox:
 Container ID: docker://...
 Image: busybox:1.28
...
 linkerd-proxy:
 Container ID: docker://...
 Image: gcr.io/linkerd-io/proxy:stable-2.6.0
 ...
 LINKERD2_PROXY_CONTROL_LISTEN_ADDR: 0.0.0.0:4190
 LINKERD2_PROXY_ADMIN_LISTEN_ADDR: 0.0.0.0:4191
 LINKERD2_PROXY_OUTBOUND_LISTEN_ADDR: 127.0.0.1:4140
 LINKERD2_PROXY_INBOUND_LISTEN_ADDR: 0.0.0.0:4143
 LINKERD2_PROXY_DESTINATION_PROFILE_SUFFIXES: svc.cluster.local.
 LINKERD2_PROXY_INBOUND_ACCEPT_KEEPALIVE: 10000ms
 LINKERD2_PROXY_OUTBOUND_CONNECT_KEEPALIVE: 10000ms
 LINKERD2_PROXY_DESTINATION_CONTEXT: ns:$(_pod_ns)
...

Injecting a Linkerd sidecar proxy is enabled by default. Any changes that are made to the existing deployment are done through mutating the admission controller using linkerd.io/inject: disabled. Such calls to the admission controller will modify the busybox deployment to enable/disable the Linkerd sidecar proxy.

Injecting a Linkerd sidecar proxy is part of the control plane, which makes the process easy since all we have to do is annotate the namespace and automate proxy injections.

Moving forward, let's explore how Linkerd enables incoming traffic through the Kubernetes Ingress controller.