Linkerd 2.10 系列

Linkerd 2.10 中文手册持续修正更新中：

Service profiles 为 Linkerd 提供
了关于服务以及如何处理服务请求的附加信息。

当 Linkerd proxy 接收到 HTTP（非 HTTPS）请求时，
会识别该请求的目标服务(destination service)。
如果存在该目标服务的服务配置文件，则该 service profile 用于
提供每个路由指标、重试 和 超时。

请求的 destination service 是通过选择存在的第一个 header 的值、
l5d-dst-override、:authority 和 Host 来计算的。
端口组件（如果包含并包含冒号）将被剥离。该值映射到完全限定的 DNS 名称。
当 destination service 与发送方或接收方命名空间中的服务配置文件名称匹配时，
Linkerd 将使用它来提供 per-route metrics、retries 和 timeouts。

有时您可能需要为驻留在您无法控制的命名空间中的服务定义服务配置文件。
为此，只需像以前一样创建一个服务配置文件，但将服务配置文件的命名空间编辑为调用该服务的
pod 的命名空间。当 Linkerd
代理对服务的请求时，源命名空间中的服务配置文件将优先于目标命名空间中的服务配置文件。

您的 destination service 可能是ExternalName
service。
在这种情况下，请使用 spec.metadata.name 和 spec.metadata.namespace
值来命名您的 ServiceProfile。例如，

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

使用名称 my-service.prod.svc.cluster.local 作为 ServiceProfile。

请注意，目前您无法在 Web 仪表板中查看针对此 ServiceProfile 中的路由收集的统计信息。
您可以使用 CLI 获取统计信息。

如需完整的演示演练，请查看 books demo。

有几种不同的方法可以使用 linkerd profile 来创建服务配置文件。`

与路由关联的请求将有一个 rt_route annotation。
要手动验证请求是否正确关联，请在您自己的部署上运行 tap：

linkerd viz tap -o wide <target> | grep req

输出将实时流式传输 deploy/webapp 正在接收的请求。 一个样本是：

req id=0:1 proxy=in  src=10.1.3.76:57152 dst=10.1.3.74:7000 tls=disabled :method=POST :authority=webapp.default:7000 :path=/books/2878/edit src_res=deploy/traffic src_ns=foobar dst_res=deploy/webapp dst_ns=default rt_route=POST /books/{id}/edit

相反，如果 rt_route 不存在，则请求 未 与任何路由相关联。尝试运行：

linkerd viz tap -o wide <target> | grep req | grep -v rt_route

Swagger

如果您的服务有 OpenAPI (Swagger)
规范，则可以使用 --open-api 标志从 OpenAPI 规范文件生成服务配置文件。

linkerd profile --open-api webapp.swagger webapp

这会从 webapp.swagger OpenAPI 规范文件为 webapp 服务生成一个服务配置文件。
生成的服务配置文件可以直接通过管道传输到 kubectl apply，并将安装到服务的命名空间中。

linkerd profile --open-api webapp.swagger webapp | kubectl apply -f -

Protobuf

如果您的服务具有 protobuf 格式，
则可以使用 --proto 标志生成服务配置文件。

linkerd profile --proto web.proto web-svc

这将从用于 web-svc 服务的 web.proto 格式文件生成服务配置文件。
生成的服务配置文件可以直接通过管道传输到 kubectl apply，并将安装到服务的命名空间中。

自动创建

没有 OpenAPI 规范或 protobuf 格式是很常见的。
您还可以通过观看实时流量生成服务配置文件。
这是基于点击数据，是了解服务配置文件可以为您做什么的好方法。
要开始此生成过程，您可以使用 --tap 标志：

linkerd viz profile -n emojivoto web-svc --tap deploy/web --tap-duration 10s

这将在该命令运行的10秒内从观察到的 deploy/web 流量中生成一个服务配置文件。
产生的服务配置文件可以直接通过管道传输到 kubectl apply，并将被安装到服务的命名空间中。

模板

除了自动创建服务配置文件的所有方法外，您还可以获得一个模板，允许您手动添加路由。要生成模板，请运行：

linkerd profile -n emojivoto web-svc --template

这会生成一个服务配置文件模板，其中包含可以手动更新的示例。
更新服务配置文件后，使用 kubectl apply 将其安装到集群上服务的命名空间中。

版权声明：本文为hacker-linner原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/hacker-linner/p/14949543.html