将 Linkerd 的控制平面添加到您的集群不会改变您的应用程序的任何内容。为了让您的服务利用 Linkerd，它们需要通过将 Linkerd 的数据平面代理注入到它们的 pod 中来进行网格化(meshed)。
对于大多数应用程序，网格化服务就像添加 Kubernetes annotation 一样简单。但是，在启动时立即进行网络调用的服务可能需要处理启动竞争条件，而使用 MySQL、SMTP、Memcache 和类似协议的服务可能需要处理 server-speaks-first 协议。
继续阅读以了解更多信息！
使用注解(annotations)对服务进行网格化
对 Kubernetes resource 进行网格划分通常是通过使用 linkerd.io/inject: enabled 的 Kubernetes annotation 来注解资源或其命名空间来完成的。当资源被创建或更新时，这个注解会触发自动代理注入。
为方便起见，Linkerd 提供了一个 linkerd inject 文本转换命令，可以将此 annotation 添加到给定的 Kubernetes 清单中。当然，这些注解可以通过任何其他机制进行设置。
简单地添加注释不会自动对现有 pod 进行网格划分。设置注解后，您需要重新创建或更新任何资源（例如使用 kubectl rollout restart）以触发代理注入。（通常，可以执行rolling update 以将代理注入实时服务而不会中断。）
示例
要将 Linkerd 的数据平面代理添加到 Kubernetes 清单中定义的服务， 您可以在将清单应用到 Kubernetes 之前 使用 linkerd inject 添加注解(annotations)：
cat deployment.yml | linkerd inject - | kubectl apply -f -
此示例转换 deployment.yml 文件以在正确的位置 添加注入注解(injection annotations)，然后将其应用于集群。
验证数据平面 Pod 是否已注入
要验证您的服务是否已添加到网格中， 您可以查询 Kubernetes 以获取 pod 中的容器列表，并确保列出了代理：
kubectl -n MYNAMESPACE get po -o jsonpath='{.items[0].spec.containers[*].name}'
这里我们看一下 emojivoto 这个应用相关的信息：
kubectl -n emojivoto get po -o jsonpath='{.items[0].spec.containers[*].name}'
# 如果一切顺利，您将在输出中看到 `linkerd-proxy`，例如： linkerd-proxy emoji-svc
关于启动竞争条件(startup race conditions)的说明
虽然代理启动非常快，但 Kubernetes 不提供任何关于容器启动顺序的保证， 因此应用程序容器可能会在代理准备好之前启动。这意味着在应用程序启动时立即建立的任何连接都可能会失败，直到代理处于活动状态。
在很多情况下，这可以被忽略：理想情况下，应用程序将重试连接， 或者 Kubernetes 将在失败后重新启动容器，最终代理将准备就绪。或者，您可以使用 linkerd-await 延迟应用程序容器直到代理准备好， 或者设置一个 skip-outbound-ports 来绕过这些连接的代理。
关于 server-speaks-first 协议的说明
Linkerd 的协议检测通过查看客户端数据的 前几个字节来确定连接的协议。某些协议（例如 MySQL、SMTP 和其他服务器优先协议）不发送这些字节。在某些情况下，这可能需要额外的配置以避免在 建立第一个连接时出现 10 秒的延迟。
