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 演练
相关文章
|
2天前
|
运维 Kubernetes Linux
Kubernetes详解(七)——Service对象部署和应用
Kubernetes详解(七)——Service对象部署和应用
11 3
|
10月前
|
Rust Kubernetes 负载均衡
Service Mesh 体系解析
Service Mesh(服务网格)诞生于云原生生态领域的潮流中,虽然大家对这一技术生态充满不确定性,甚至难以接受,然而,如果我们消除外面的“杂声”,细心洞察里面的细节,或许能有不一样的收获,毕竟,所有新技术的出现是为了解决业务痛点,而非是为了一些没用意义的炒作。
313 0
|
10月前
|
Kubernetes 负载均衡 网络协议
Kubernetes Service解析
我们都知道,在K8S集群中,每个Pod都有自己的私有IP地址,并且这些IP地址不是固定的。这意味着其不依赖IP地址而存在。例如,当我们因某种业务需求,需要对容器进行更新操作,则容器很有可能在随后的启动运行过程中被分配到其他IP地址。此外,在K8S集群外部看不到该Pod。因此,Pod若单独运行于K8S体系中,在实际的业务场景中是不现实的,故我们需要通过其他的策略去解决,那么解决方案是什么? 由此,我们引入了Serivce这个概念以解决上述问题。
90 0
|
缓存 Kubernetes 数据库
【kubernetes】Service: 将外部服务定位为 Service
【kubernetes】Service: 将外部服务定位为 Service
81 0
|
负载均衡 监控 网络协议
Service Mesh之Sidecar
时间总是给你意外,在使用微服务架构吗?还在考虑使用哪种微服务架构呢?要准备大干一场,学习spring cloud吗? 还在纠结这些问题时,这些技术都将要被淘汰了,下一代微服务Service Mesh出现了
255 0
Service Mesh之Sidecar
|
Rust Prometheus Kubernetes
了解 Linkerd Service Mesh 架构
了解 Linkerd Service Mesh 架构
139 0
|
Kubernetes Perl 容器
Linkerd Service Mesh 授权策略(Server & ServerAuthorization)
Linkerd Service Mesh 授权策略(Server & ServerAuthorization)
112 0
|
Kubernetes Linux Docker
Kubernetes - Service 端口映射暴露配置
Kubernetes - Service 端口映射暴露配置
308 0
Kubernetes - Service 端口映射暴露配置
|
Cloud Native 前端开发 Dubbo
到底谁才需要Service Mesh?(二)
到底谁才需要Service Mesh?(二)
115 0
到底谁才需要Service Mesh?(二)
|
监控 Cloud Native 网络协议
到底谁才需要Service Mesh?(一)
到底谁才需要Service Mesh?(一)
142 0
到底谁才需要Service Mesh?(一)