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和服务网格的系列文章中的一篇。本系列的其他部分包括:
- Top-line service metrics
- Pods are great, until they're not
- Encrypting all the things
- Continuous deployment via traffic shifting
- Dogfood environments, ingress, and edge routing
- Staging microservices without the tears
- Distributed tracing made easy
- Linkerd as an ingress controller
- gRPC for fun and profit
- Service Mesh API(本文)
- Egress
- Retry budgets, deadline propagation, and failing gracefully
- 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作为云本地应用服务网格的核心。
- BZOJ 1257: [CQOI2007]余数之和sum【神奇的做法,思维题】
- 洛谷 P1019 单词接龙【经典DFS,温习搜索】
- MVCforum 支持多国语言
- BZOJ 1012: [JSOI2008]最大数maxnumber【线段树单点更新求最值,单调队列,多解】
- BZOJ 1303: [CQOI2009]中位数图【前缀和】
- 高斯消元模版
- HDU 1728 逃离迷宫(DFS经典题,比赛手残写废题)
- 洛谷 P1219 八皇后【经典DFS,温习搜索】
- KVM基于内核的虚拟机概念理解与客户机浅析
- 洛谷 P1972 [SDOI2009]HH的项链【莫队算法学习】
- BZOJ 2257: [Jsoi2009]瓶子和燃料【数论:裴蜀定理】
- 在 EF 5 中跟踪SQL和缓存数据
- hihoCoder #1015 : KMP算法【KMP裸题,板子】
- 对X86汇编的理解与入门
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- 在linux下玩转带有超时时间的connect函数
- Linux/CentOS服务器安全配置通用指南
- 详解centos7中配置keepalived日志为别的路径
- jointplot快速探究两组变量的分布及关系
- linux中alarm函数的实例讲解
- 如何给Linux虚拟机连上WiFi详解
- Linux系统查看CPU、机器型号、内存等信息
- 实战基本的Linux sed命令示例代码
- 在Linux中如何查看可用的网络接口详解
- Linux程序运行时加载动态库失败的解决方法
- Linux/CentOS系统同步网络时间的2种方法详解
- Linux 常用命令之Linux more命令使用方法
- Ubuntu下VIM配置成C++开发编辑器
- Ubuntu环境下使用G++编译CPP文件
- Linux下Tomcat的几种运行方式讲解