1. 将您的服务添加到 Linkerd

Linkerd控制平面添加到您的集群不会改变您的应用程序的任何内容。 为了让您的服务利用 Linkerd, 它们需要通过将 Linkerd数据平面代理注入它们的 pod 来进行 网格化

对于大多数应用程序,网格化服务就像 添加 Kubernetes annotation 一样简单。 但是,在启动时立即进行网络调用的服务可能需要处理启动竞争条件, 而使用 MySQLSMTPMemcache 和类似协议的服务可能需要处理 server-speaks-first 协议

继续阅读以了解更多信息!

使用 annotations 对服务进行网格化

Kubernetes resource 进行网格划分通常是通过使用 linkerd.io/inject: enabledKubernetes annotation 来注解资源或其命名空间来完成的。 当资源被创建或更新时,这个注解会触发自动代理注入。 (有关其工作原理的更多信息,请参阅代理注入页面。)

为方便起见,Linkerd 提供了一个 linkerd inject 文本转换命令,可以将此 annotation 添加到给定的 Kubernetes 清单中。 当然,这些注解可以通过任何其他机制进行设置。

示例

要将 Linkerd数据平面代理添加到 Kubernetes 清单中定义的服务, 您可以在将清单应用到 Kubernetes 之前 使用 linkerd inject 添加 annotations

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

此示例转换 deployment.yml 文件以在正确位置添加注入 annotations,然后将其应用于集群。

验证数据平面 Pod 是否已注入

要验证您的服务是否已添加到网格中, 您可以查询 Kubernetes 以获取 pod 中的容器列表,并确保列出了代理

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

如果一切顺利,您将在输出中看到 linkerd-proxy,例如:

MYCONTAINER linkerd-proxy

关于启动竞争条件的说明

虽然代理启动非常快,但 Kubernetes 不提供任何关于容器启动顺序的保证, 因此应用程序容器可能会在代理准备好之前启动。 这意味着在应用程序启动时立即建立的任何连接都可能会失败,直到代理处于活动状态。

在很多情况下,这可以被忽略:理想情况下,应用程序将重试连接, 或者 Kubernetes 将在失败后重新启动容器,最终代理将准备就绪。 或者,您可以使用 linkerd-await 延迟应用程序容器直到代理准备好, 或者设置一个 skip-outbound-ports annotation 来绕过这些连接的代理。

关于 server-speaks-first 协议的说明

Linkerdprotocol detection通过查看客户端数据的 前几个字节来确定连接的协议。某些协议(例如 MySQLSMTP 和其他服务器优先协议)不发送这些字节。 在某些情况下,这可能需要额外的配置以避免在 建立第一个连接时出现 10 秒的延迟。 有关详细信息,请参阅配置协议检测

更多阅读

有关注入命令如何工作以及可以设置的所有参数的更多信息,请参阅 linkerd inject reference page

有关自动注入如何工作的详细信息,请参阅proxy injection page