Kubernetes服务网格(第10部分):服务网格API

作为我们上个月发布的Linkerd1.0的一部分,我们已经悄悄地看到了很少有人注意的东西——Linkerd的服务网格API。随着1.0版本的发布,我们认为我们需要花些时间来解释这个API的作用,以及它对Linkerd的未来意味着什么。我们还将展示这个API的即将发布的一个功能——动态控制Linkerd的每项服务的通信策略。

Linkerd服务网格

今天早上在Gluecon,Buoyant CTO Oliver Gould发表了题为“The Service Mesh”的主题演讲 。在这个主题中,他概述了服务网格的视野,如Linkerd所示例。尽管Linkerd经常被添加到构建在Kubernetes上的增加弹性的系统上,但是服务网格的完整视野远不止于此 。正如William Morgan在他的博客文章"什么是服务网格?"表明的:

服务网格的明确目标是将服务通信从隐形的基础设施领域中转移到生态系统的重要一员 - 在这里可以对其进行监控,管理和控制。

对于Linkerd来说,这意味着它行为的每个方面不应该仅被检测和观察,而是在运行时同样可以控制。理想情况下,应该使用这种可更改性替换旧的版本,不是通过编辑配置文件和热重载,而是通过一个统一的,设计良好的运行时API来实现。

简言之,这就是Linkerd的服务网格API的目的。为此,我们引入了io.l5d.mesh解释器和 a new gRPC API for Namerd。这些功能一起提供了动态控制路由策略的能力,并形成了Linkerd服务网格API的核心。这是实现对Linkerd行为的每个方面提供统一的全球控制模式的最终目标的第一步。

Linkerd 1.0还引入了一种还没通过服务网格API揭露的新策略——每个服务通信的略。在这篇文章中,我们将展示如何配置这个策略,并且我们将介绍后续将此控件添加到Linkerd的服务网格API所需的工作。

本文是关于LinkerdKubernetes和服务网格的一系列文章之一 。本系列的其他部分包括:

  1. 顶级服务指标
  2. Pod很好,至少看上去如此
  3. 加密所有的东西
  4. 通过流量转移进行连续部署
  5. Dogfood环境,入口和边缘路由
  6. 没有痛苦的分期微服务
  7. 使分布式跟踪变得容易
  8. Linkerd作为入口控制器
  9. gRPC乐趣和盈利
  10. Service Mesh API(本文)
  11. 出口
  12. 重估预算,截止日期传播,和优雅失败
  13. 通过顶级指标自动缩放

通信策略

Linkerd的新的每项服务 通信政策 是一个经常要求的功能。通信策略涵盖了Linkerd如何代理请求的各个方面,包括:在超时之前我们应该等待服务处理请求多久?哪种请求可以安全重试?我们是否应该加密与TLS的通信,以及我们应该使用哪个证书?等等。

让我们来看看现在如何使用这个策略,以两个具有截然不同的延迟的服务为例。

从一个新的Kubernetes集群开始,让我们部署两个具有不同延迟的服务。我们以hello world从本系列的其他文章中部署我们熟悉的微服务,只需稍作调整:hello 服务将在配置中添加500ms人工延迟。

-name:service
image: buoyantio/helloworld:0.1.2
args:
- "-addr=:7777"
- "-text=Hello"
- "-target=world"
- "-latency=500ms"

使用以下命令将其部署到你的Kubernetes集群:

kubectl apply -f https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/hello-world-latency.yml

(注意,在这些博客文章的例子假设Kubernetes在像GKE这种外部负载均衡器IP可用并且不需要使用CNI插件的环境中运行,其他环境中微小的修正-见我们的 Flavors of Kubernetes forum posting 一文介绍如何使用Calico / Weave处理Minikube或用Calico/Weave配置CNI。)

我们下一步将部署Linkerd服务网格。我们希望添加一个超时,以便能中止(并可能重连)时间过长的请求,但是我们遇到了一个问题。该world 服务很快,响应时间在 100ms以内,但 hello 服务很慢,响应时间超过500ms。如果我们仅仅设置超时时间100ms,那么对world 服务的请求将会成功,但是对hello服务的请求将会超时。另一方面,如果我们设置超时时间超过 500ms 那么我们需要给worl服务一个比所需的更长的超时时间,这可能会给我们的调用者带来问题 。

为了给每个服务一个适当的超时时间,我们可以使用Linkerd 1.0为每个服务设置精确的新配置为每个服务设置一个单独的通信策略:

service:
kind: io.l5d.static
configs:
- prefix: /svc/hello
totalTimeoutMs: 600ms
- prefix: /svc/world
totalTimeoutMs: 100ms

该配置会建立以下超时:

我们可以使用这个命令来配置Linkerd服务网格:

kubectl apply -f https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/linkerd-latency.yml

一旦Kubernetes为Linkerd提供了一个外部的负载均衡 IP,我们就可以用它测试helloworld两个服务的请求,并确保两者在各自的超时时间内处理。

$ L5D_INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}")
$ curl $L5D_INGRESS_LB:4140 -H "Host: hello"
Hello (10.196.1.242) world (10.196.1.243)!!
$ curl $L5D_INGRESS_LB:4140 -H "Host: world"
world (10.196.1.243)!!

(注意,前几个请求会比较慢,因为它们必须建立连接并可能超时,后续请求都会成功。)

我们还可以手动地增加helloworld服务的等待时间直到他们超时为止来检查它们的超时时间。我们将将增加hello服务的手动延迟到600ms。考虑到hello 服务的超时时间是600ms这留给hello服务的开销为零,因此每个请求都该设置超时如下:

$ curl "$L5D_INGRESS_LB:4140/setLatency?latency=600ms" -X POST -H "Host: hello"
ok
$ curl $L5D_INGRESS_LB:4140 -H "Host: hello"
exceeded 600.milliseconds to unspecified while waiting for a response for the request, including retries (if applicable). Remote Info: Not Available

同样,我们可以 给 world 服务添加100ms人为延迟,这将导致所有请求到 world 服务违反100ms超时。

$ curl "$L5D_INGRESS_LB:4140/setLatency?latency=100ms" -X POST -H "Host: world"
ok
$ curl $L5D_INGRESS_LB:4140 -H "Host: world"
exceeded 100.milliseconds to unspecified while waiting for a response for the request, including retries (if applicable). Remote Info: Not Available

一切顺利!我们为每个服务设置了合适的超时时间,并且证明了这些超时有(或者)没有违反预期。

在这个例子中,我们只是配置超时,但是,正如你所期望的那样,可以使用相同的模式来配置任何类型的每项服务通信策略,包括响应分类重估预算

展望

在这篇文章中,我们已经看到了一个使用Linkerd的处理两个有很大不同预估延迟的服务的新的策略。每个服务通信策略的引入为Linkerd用户解决了一些直接的用例。但是我们在这里看到的仅仅是Linkerd中通信策略控制的开始——这个策略是从一开始就可以动态更新的,并且明确的目标是使其成为服务网格API的一部分。

在接下来的几个月中,我们将把这个通信策略和路由策略一起添加到Linkerd的服务网格API中。更长远来看,其他形式的策略(包括速率限制请求分支策略安全策略 )都在 Linkerd路线图上,并将形成更多Linkerd的服务网格API。Linkerd运行时行为的全面控制,是一个一致统一的,设计良好的服务网格API,是我们将Linkerd作为云本地应用服务网格的核心。

本文的版权归 lemoon1993 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PHP在线

mysql 分库分表

分表是分散数据库压力的好方法。 分表,最直白的意思,就是将一个表结构分为多个表,然后,可以再同一个库里,也可以放到不同的库。 当然,首先要知道什么情况下,才需要...

5266
来自专栏北京马哥教育

小技巧:显示数据库查询耗时,改善开发者习惯

我会分享一系列在我开发生涯中积累的有用且容易实现的小技巧,本文是此系列的第一篇。 ---- 很多原因都可能导致网站运行缓慢,但这其中最常见的就是在数据库查询耗时...

2986
来自专栏Java架构

如何通过 Java 线程堆栈来进行性能瓶颈分析?

3456
来自专栏HBStream流媒体与音视频技术

做了一个电驴 p2p资源搜索小软件

6287
来自专栏Web 开发

额,算是半个轻量级WEB开发软件-WebMatirx

Microsoft WebMatrix 是微软最新的 Web 开发工具,它包含了构建网站所需要的一切元素。您可以从开源 Web 项目或者内置的 Web 模板开始...

701
来自专栏Crossin的编程教室

一键下载:将知乎专栏导出成电子书

老是有同学问,学了 Python 基础后不知道可以做点什么来提高。今天就再用个小例子,给大家讲讲,通过 Python 和爬虫,可以完成怎样的小工具。

2891
来自专栏HappenLee的技术杂谈

分布式系统的烦恼------《Designing Data-Intensive Applications》读书笔记11

当我们在使用单机系统时,它通常以一种相当可预测的方式工作:要么它正常工作,要么不工作。

923
来自专栏杨建荣的学习笔记

数据库备份的动态调度设计和思路

总体来说,如果切入点是备份,其实直接接入celery不是一个很理想的方案,因为备份任务的执行时间一般都偏长,而且任务的执行结果很重要,如果没备份或者备份任务重复...

801
来自专栏张戈的专栏

php自动生成百度开放适配PC页-手机页pattern对应关系sitemap.xml

以前做百度开放适配一直是提交普通的 url 对应关系,这种方式有个缺点,就是必须每个页面的 url 关系都得兼顾,即有多少就得提交多少。 然而,很多网站并不是 ...

3429
来自专栏Thinks

SEO杂谈(2)

站点地图,作为补充,仅仅作为补充,不要把希望都寄托在他的身上,不过从实践来看,他一旦被搜索引擎认可,他确实是一个可以依赖的方法。

621

扫码关注云+社区

领取腾讯云代金券