Linkerd Service Mesh 服务配置文件规范

简介: Linkerd Service Mesh 服务配置文件规范

系列



中文手册(https://linkerd.hacker-linner.com)


Spec(规范)



服务配置文件规范必须包含以下顶级字段:


field value
routes route 对象的列表
retryBudget 定义此服务的最大重试率的 retry budget 对象


Route(路由)


route 对象必须包含以下字段:


field value
name 这条 route 的名称,因为它将出现在 route 标签中
condition 一个 request match 对象,用于定义请求是否与此 route 匹配
responseClasses (可选)response class 对象列表
isRetryable 表示对该 route 的请求始终可以安全重试,并且会导致 proxy 尽可能重试该 route 上失败的请求
timeout 发送请求后等待响应(包括重试)完成的最长时间


Request Match(请求匹配)



请求匹配对象必须恰好包含以下字段之一:


field value
pathRegex 匹配请求路径的正则表达式
method GET, POST, PUT, DELETE, OPTION, HEAD, TRACE 之一
all 必须全部匹配的 request match 对象列表
any request match 对象的列表,其中至少一个必须匹配
not 必须不匹配的 request match 对象


Request Match 使用示例


最简单的条件是路径正则表达式:


pathRegex: '/authors/\d+'


这是检查请求方法的条件:


method: POST


如果设置了多个条件字段,则必须满足所有条件。这等效于使用 all 条件:


all:
- pathRegex: '/authors/\d+'
- method: POST


可以使用 allanynot 组合条件:


any:
- all:
  - method: POST
  - pathRegex: '/authors/\d+'
- all:
  - not:
      method: DELETE
  - pathRegex: /info.txt


Response Class(响应类)


response class 对象必须包含以下字段:


field value
condition 一个 response match 对象,它定义一个 response 是否匹配这个 response class
isFailure 一个布尔值,用于定义这些 response 是否应归类为失败


Response Match(响应匹配)


response match 对象必须恰好包含以下字段之一:


field value
status 用于匹配响应状态代码的 status range 对象
all 必须全部匹配的 response match 对象列表
any response match 对象列表,其中至少一个必须匹配
not 必须不匹配的 response match 对象


Response Match 条件可以以类似于上面显示的 Request Match 使用示例 的方式组合


Status Range(状态范围)


status range 对象必须包含以下至少一个字段。只指定 minmax 中的一个将只匹配一个状态码。


field value
min 状态码必须大于或等于此值
max 状态码必须小于或等于此值


Retry Budget(重试预算)


retry budget 指定应发送到此服务的最大重试总次数原始请求量比率


field value
retryRatio 重试请求原始请求的最大比率
minRetriesPerSecond 除了 retryRatio 允许的重试次数外,允许每秒重试次数
ttl 指示在计算 retryRatio 时应考虑请求的时间


实战


  • 设置服务配置文件
  • 完整的 demo 演练
相关文章
|
8月前
|
负载均衡 Dubbo Java
Service Mesh 的基本模式
【5月更文挑战第16天】Service Mesh分为两种模式:Sidecar和第二代Service Mesh。
|
Rust Kubernetes 负载均衡
Service Mesh 体系解析
Service Mesh(服务网格)诞生于云原生生态领域的潮流中,虽然大家对这一技术生态充满不确定性,甚至难以接受,然而,如果我们消除外面的“杂声”,细心洞察里面的细节,或许能有不一样的收获,毕竟,所有新技术的出现是为了解决业务痛点,而非是为了一些没用意义的炒作。
375 0
|
Prometheus 负载均衡 Kubernetes
Service Mesh: Istio vs Linkerd
根据CNCF的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣,并且许多人已经在他们的生产中使用它们。近69%的人正在评估Istio,64%的人正在研究Linkerd。Linkerd是市场上第一个服务网格,但是Istio使服务网格更受欢迎。这两个项目都是最前沿的,而且竞争非常激烈,因此选择一个项目是一个艰难的选择。在此博客文章中,我们将了解有关Istio和Linkerd体系结构,其运动部件的更多信息,并比较其产品以帮助您做出明智的决定。
173 0
|
缓存 Kubernetes 数据库
【kubernetes】Service: 将外部服务定位为 Service
【kubernetes】Service: 将外部服务定位为 Service
138 0
|
Kubernetes 测试技术 应用服务中间件
Kubernetes的service mesh – 第五部分:DogFood环境,Ingress和Edge路由
概述 在这篇文章中,我们将向您展示如何使用Linkerd实现的Service Mesh来处理Kubernetes上的入口流量,在Service Mesh中的每个实例上分发流量。我们还将通过一个完整的例子来介绍Linkerd的高级路由功能:如何将特定的请求路由到较新版本的应用实例上,比如用于内部测试的、预发布的应用版本。
1365 0
|
负载均衡 监控 网络协议
Service Mesh之Sidecar
时间总是给你意外,在使用微服务架构吗?还在考虑使用哪种微服务架构呢?要准备大干一场,学习spring cloud吗? 还在纠结这些问题时,这些技术都将要被淘汰了,下一代微服务Service Mesh出现了
291 0
Service Mesh之Sidecar
|
Prometheus Kubernetes Cloud Native
快速上手 Linkerd v2 Service Mesh(服务网格)
快速上手 Linkerd v2 Service Mesh(服务网格)
270 0
|
分布式计算 运维 负载均衡
Service Mesh 的由来
Service Mesh 的由来
141 0
Service Mesh 的由来
|
Cloud Native 前端开发 Dubbo
到底谁才需要Service Mesh?(二)
到底谁才需要Service Mesh?(二)
139 0
到底谁才需要Service Mesh?(二)
|
监控 Cloud Native 网络协议
到底谁才需要Service Mesh?(一)
到底谁才需要Service Mesh?(一)
181 0
到底谁才需要Service Mesh?(一)

热门文章

最新文章

下一篇
开通oss服务