Linkerd 2.10 系列
- 快速上手 Linkerd v2.10 Service Mesh
- 腾讯云 K8S 集群实战 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 应用
- 详细了解 Linkerd 2.10 基础功能，一起步入 Service Mesh 微服务架构时代
- 将您的服务添加到 Linkerd
- 自动化的金丝雀发布
- 自动轮换控制平面 TLS 与 Webhook TLS 凭证
- 如何配置外部 Prometheus 实例
- 配置代理并发
- 配置重试
- 配置超时
- 控制平面调试端点
- 使用 Kustomize 自定义 Linkerd 的配置
- 使用 Linkerd 进行分布式跟踪
- 调试 502s
- 使用每个路由指标调试 HTTP 应用程序
- 使用请求跟踪调试 gRPC 应用程序
- 导出指标
- 暴露 Dashboard
- 生成您自己的 mTLS 根证书
- 获取每条路由指标
- 混沌工程之注入故障
- 优雅的 Pod 关闭
- Ingress 流量
- 安装多集群组件
- 安装 Linkerd
- 使用 Helm 安装 Linkerd
- Linkerd 和 Pod 安全策略 (PSP)
- 手动轮换控制平面 TLS 凭证
- 修改代理日志级别
- 多集群通信
- 将 GitOps 与 Linkerd 和 Argo CD 结合使用
- 使用 Debug Sidecar，注入调试容器来捕获网络数据包
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 将其安装到集群上服务的命名空间中。