Kubernetes服务网格（第10部分）：服务网格API

翻译人：Ksher，该成员来自云+社区翻译社

原文链接：https://dzone.com/articles/a-service-mesh-for-kubernetes-part-x-the-service-m

原文作者：Alex Leong

作为上个月发布的Linkerd 1.0的一部分，我们发现一些人已经开始注意Linkerd的服务网格API。随着1.0版本的发布，我们认为需要花些时间来解释这个API的作用，以及这对于Linkerd的未来意味着什么。我们还将展示这个API的即将发布的功能之一 —— 动态控制Linkerd的每项服务的通信策略。

Linkerd服务网格

今天早上云原生软件公司Buyant的CTO Oliver Gould 在 Gluecon 发表了题为“服务网格”的主题演讲 。在演讲中，他以Linkerd为例概述了服务网格的远景。尽管Linkerd经常被使用到构建Kubernetes的系统上用来提高弹性，但是服务网格的全部用途远不止于此 。正如威廉·摩根在他的博客文章“ 什么是服务网格？”中写道 ：

服务网格的明确目标是将让服务间通信移动到不可见的领域当中，隐秘的基础设施，成为生态系统中的首要成员，你在这里可以监控，管理和控制。

对于Linkerd来说，这意味着它的行为的每个方面不仅应该被检测和观察，而且在运行时也是 可控的。在理想情况下，这种变化通过一个统一的、设计良好的运行时API能够实现，而不是通过配置文件编辑和热加载。

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

Linkerd 1.0还引入了一种新的并且没有通过服务网格API公开的策略即每个服务的通信策略。在这篇文章中，我们将展示如何配置这个策略，并且将介绍把这种控件添加到Linkerd的服务网格API中所需的未来工作。

本文是关于Linkerd， Kubernetes和服务网格的系列文章中的一篇。本系列的其他部分包括：

1. Top-line service metrics
2. Pods are great, until they're not
3. Encrypting all the things
4. Continuous deployment via traffic shifting
5. Dogfood environments, ingress, and edge routing
6. Staging microservices without the tears
7. Distributed tracing made easy
8. Linkerd as an ingress controller
9. gRPC for fun and profit
10. Service Mesh API（本文）
11. Egress
12. Retry budgets, deadline propagation, and failing gracefully
13. Autoscaling by top-line metrics

通信策略

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这样的环境中，在这个环境中外部负载均衡器IPs是可用的并且没有使用CNI插件。这可能需要对其他环境做一些微小的调整-具体参见我们论坛发的Kubernetes的特点 如何使用Calico / Weave来配置像Minikube或CNI的环境。）

我们下一步将部署Linkerd服务网格。我们希望添加一个超时限定，以便我们可以中止（并且可能重新发送）时间过长的请求，但是我们遇到了一个问题。 world 这个服务很快，在不到100ms时就做出了回应，但hello服务却很慢，超过 500ms才有回应。如果我们设置超时只有 100ms的话，那么对world 服务的请求将会成功，但是对hello服务的请求将一定会超时。另一方面，如果我们设置的超时时间为 500ms 那么我们需要给world服务一个比它本身的超时的时间更长的时间，这样就可能会给我们的调用者带来问题。

为了给每个服务一个恰当的超时限定，我们可以使用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，我们就可以测试这两个hello 和 world服务的请求， 并确保两者都在超时之前运行。

$ 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）!!

（请注意，前几个请求会比较慢，因为它们必须建立连接并可能超时，后续的请求应该可以成功。）

我们还可以通过人为地增加hello 和world 服务的等待时间直到他们超时来检查是配置是否正确 。我们可以人工的增加hello 服务的启动延时600ms。设置hello服务的超时时间为600ms，那么这将会使hello服务在执行诸如调用world服务时的开销为零，因此这时任何请求都将会超时：

$ 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

同样，我们可以人为添加 100ms 的延迟给 world 服务，这将导致所有到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。一个统一的、一致的、设计良好的服务网格API对Linkerd的运行行为的全面控制是是我们将Linkerd作为云本地应用服务网格的核心。