Linkerd 2.10 (Step by Step) (I) Adding your service to Linkerd

[[405467]]

In order for your services to take advantage of Linkerd, they also need to be meshed by injecting Linkerd's data plane proxy into their service's pods.

The Linkerd 2.10 Chinese manual is being continuously revised and updated:

https://linkerd.hacker-linner.com/

Linkerd 2.10 Series

• Quick Start with Linkerd v2 Service Mesh
• Tencent Cloud K8S Cluster Practice Service Mesh—Linkerd2 & Traefik2 Deployment of emojivoto Application
• Learn more about the basic features of Linkerd 2.10 and step into the era of Service Mesh microservice architecture

Adding Linkerd's control plane to your cluster doesn't change anything about your applications. In order for your services to take advantage of Linkerd, they need to be meshed by injecting Linkerd's data plane proxy into their pods.

For most applications, meshing a service is as simple as adding a Kubernetes annotation. However, services that make network calls immediately upon startup may need to deal with startup race conditions, and services that use MySQL, SMTP, Memcache, and similar protocols may need to deal with server-speaks-first protocols.

Keep reading to find out more!

Meshing services using annotations

Meshing a Kubernetes resource is typically done by annotating the resource or its namespace with the linkerd.io/inject: enabled Kubernetes annotation. This annotation triggers automatic proxy injection when the resource is created or updated.

For convenience, Linkerd provides a linkerd inject text transformation command that adds this annotation to a given Kubernetes manifest. Of course, these annotations can be set via any other mechanism.

Simply adding the annotation does not automatically mesh existing pods. After setting the annotation, you will need to recreate or update any resources (for example using kubectl rollout restart ) to trigger the proxy injection. (Typically, a rolling update can be performed to inject the proxy into a live service without disruption.)

Example

To add Linkerd's data plane proxy to a service defined in a Kubernetes manifest, you can use linkerd inject to add annotations before applying the manifest to Kubernetes:

 cat deployment.yml | linkerd inject - | kubectl apply -f -

This example transforms the deployment.yml file to add injection annotations in the correct location and then applies it to the cluster.

Verify that the data plane Pod has been injected

To verify that your service was added to the mesh, you can query Kubernetes to get a list of the containers in the pod and ensure that the proxy is listed:

 kubectl -n MYNAMESPACE get po -o jsonpath= '{.items[0].spec.containers[*].name}'  

Here we take a look at the information related to the emojivoto app:

 kubectl -n emojivoto get po -o jsonpath= '{.items[0].spec.containers[*].name}'  

 # If all goes well, you will see `linkerd-proxy` in the output, for example: linkerd-proxy emoji-svc

Notes on startup race conditions

While the proxy starts very quickly, Kubernetes does not provide any guarantees about the order in which containers are started, so the application container may start before the proxy is ready. This means that any connections established immediately when the application starts may fail until the proxy is active.

In many cases this can be ignored: ideally the application will retry the connection, or Kubernetes will restart the container after a failure, and eventually the proxy will be ready. Alternatively, you can use linkerd-await to delay the application container until the proxy is ready, or set a skip-outbound-ports to bypass the proxy for these connections.

A note about the server-speaks-first protocol

Linkerd's protocol detection determines the protocol of the connection by looking at the first few bytes of the client data. Some protocols (such as MySQL, SMTP, and other server-first protocols) do not send these bytes. In some cases, this may require additional configuration to avoid a 10 second delay when establishing the first connection.