Linkerd 2.10—设置服务配置文件

简介: Linkerd 2.10—设置服务配置文件

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


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


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


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


您的 destination service 可能是ExternalName service。在这种情况下,请使用 spec.metadata.namespec.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 将其安装到集群上服务的命名空间中。

相关文章
|
7月前
|
Kubernetes Cloud Native 应用服务中间件
【云原生】使用k8s创建nginx服务—通过yaml文件svc类型暴露
【云原生】使用k8s创建nginx服务—通过yaml文件svc类型暴露
141 0
|
7天前
|
存储 NoSQL 应用服务中间件
Etcd+Confd实现Nginx配置文件自动管理
Etcd+Confd实现Nginx配置文件自动管理
|
9月前
|
缓存 负载均衡 网络协议
一文讲懂Nginx常用配置及和基本功能
一文讲懂Nginx常用配置及和基本功能
235 1
|
9月前
|
缓存 运维 安全
Nginx中的常用配置如何迁移到Istiogateway
本文提供了Nginx中常用配置的解释以及在Istiogateway中如何实现对应的功能。
274 0
|
数据采集 Java 应用服务中间件
1分钟系列-Filebeat 模块之 Nginx 配置使用
1分钟系列-Filebeat 模块之 Nginx 配置使用
|
存储 Kubernetes 前端开发
Kubernetes config 配置访问多集群
Kubernetes config 配置访问多集群
|
运维 API 容器
3.3. [kustz] 注入 ConfigMap 和 Secrets 到容器环境变量
3.3. [kustz] 注入 ConfigMap 和 Secrets 到容器环境变量
211 0
3.3. [kustz] 注入 ConfigMap 和 Secrets 到容器环境变量
|
Kubernetes 监控 应用服务中间件
Kubernetes Nginx 配置热加载
Kubernetes Nginx 配置热加载
564 1
|
NoSQL 测试技术 Redis
一日一技:优雅地加载Yaml配置文件
一日一技:优雅地加载Yaml配置文件
764 0
一日一技:优雅地加载Yaml配置文件
|
安全
Linkerd Service Mesh 服务配置文件规范
Linkerd Service Mesh 服务配置文件规范