servicemesh | 伪架构师

在 Linkerd2 中进行流量拆分

Fri, 12 Jul 2019 11:40:31 +0800

最新发布的 Linkerd 2.4，加入了对流量拆分的支持。

安装最新版本之后，可以看到这个流量拆分功能所使用的 API 资源并非来自 Linkerd，而是 SMI 规范的一部分。

$ curl -sL https://run.linkerd.io/install | sh
...
$ kubectl api-resources | grep -i split
trafficsplits ts split.smi-spec.io true TrafficSplit

和 Istio 的 Service + Selector 的拆分方式不同，Linkerd 其实没有什么特别的上游定义方式，简单的定义独立的 Service 即可。例如我们要从 flaskapp 服务分流到 v1 和 v2 两个版本，在 Istio 中，需要定义一个 flaskapp 服务，然后使用标签，在 Service 的标签子集中，选择两组 Subset 作为目的地。而在 Linkerd/SMI 中，就需要分别定义三个服务了，例如 flaskapp、flaskapp-v1、flaskapp-v2。下面简单操练一下。

$ wget https://raw.githubusercontent.com/fleeto/istio-for-beginner/master/code/flaskapp/flaskapp.istio.yaml
$ linkerd inject flaskapp.istio.yaml | kubectl apply -f -
...
$ wget https://raw.githubusercontent.com/fleeto/istio-for-beginner/master/code/sleep/sleep.yaml
$ linkerd inject sleep.yaml | kubectl apply -f -
...

分别安装了两个版本的 flaskapp，和一个版本的 sleep 服务之后。再创建两个 flaskapp 的分版本服务。

apiVersion: v1
kind: Service
metadata:
  name: flaskapp-v1
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
    version: v1
  ports:
    - name: http
      port: 80
      targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: flaskapp-v2
  labels:
    app: flaskapp
spec:
  selector:
    app: flaskapp
    version: v2
  ports:
    - name: http
      port: 80
      targetPort: 80

创建两个服务之后，就可以尝试拆分了，同样是一个 YAML：

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: flask-split
spec:
  service: flaskapp
  backends:
  - service: flaskapp-v1
    weight: 1
  - service: flaskapp-v2
    weight: 500m

注意这里的定义和 Istio 也稍有不同，使用权重而非百分比进行分流。

可以在 Sleep 中进行测试：

$ for i in {1..1000}; do curl -sSL http://flaskapp/env/version | grep v1; done | wc -l
660

可以看到，按照我们的权重分配，成功进行了分流。但是目前在 SMI 中并没有看到条件选择的相关内容，因此目前的功能还比较初级。可以通过 Flagger 的加持，实现更加复杂的功能。

Envoy 和 Istio 的 6.18

Wed, 19 Jun 2019 18:24:32 +0800

地球对面的时间比我们这里晚一点，我们的 618 已经开始返场了，他们还在 618。

服务网格方面，在这一天有了两个发布：

Envoy Mobile

Envoy Mobile 是一个库，目的是可以直接将 Envoy 的功能封装到移动应用之中，

跨平台的底层网络支持：HTTP/2、QUIC、gRPC、推送、流、重试和超时策略等底层网络技术的实现以及跨平台都是需要付出大量努力来完成的事情，Evnoy Mobile 试图在客户端以一致的跨平台的方式提供这所有功能。
xDS 支持：Envoy 的最深套路就是 xDS 了，Envoy 一旦潜入移动应用，就可以通过 xDS 的方式，在服务端对客户端的网络行为作出控制。
API 的高级支持：用注解方式为 API 提供缓存、优先级等支持

这个项目还非常早期，但是我觉得非常有意思，强悍的 Envoy 用这种方式为移动应用提供了一个可控的网络抽象的能力，目前已经提供了 Java、Swift、OC 等支持，这会不会成为一种新的边缘能力？

Istio 1.2

补丁版本，没啥好说。

参考链接

https://docs.google.com/document/d/1N0ZFJktK8m01uqqgfDRVB9mpC1iEn9dqkQaa_yMn_kE/edit#
https://istio.io/about/notes/1.2/
https://eng.lyft.com/announcing-envoy-mobile-5c2067d9ade0

SMI：推动服务网格社区举步前行

Tue, 11 Jun 2019 07:48:13 +0800

原文：Moving the Service-mesh Community Forward

作者：Christian Posta

在运行一个服务式架构的应用时，往往会面临服务间通信的挑战，服务网格技术正是为此而生。Kubernetes 和容器技术对工作负载的在大量服务器上的部署和进行提供了一个漂亮的抽象，服务网格做的也是类似的工作：他对网络进行抽象，让运维和开发人员能够通过请求路由、可观察性以及策略实施等方式对其进行控制。服务网格带来了各种可能。

唯一的问题是，就算 Kubernetes 提供了有力的 API 来对底层基础设施进行抽象，从而进行工作负载的调度，可惜的是这其中没有一点能够落地的 API 能够提供服务网格所需要的能力。

KubeCon EU 2019 上发布的服务网格接口（SMI）正试图填补这一空白。在此声明：我为 Solo.io 工作，它是 SMI 的创建者之一，并是一个原有统一服务网格产品的主导者。

SMI 规范还很稚嫩，目前正在尝试对运行在 Kubernetes 基础之上的服务网格所需的 API 和能力进行统一（这种尝试也有助于为 Kubernetes 之外运行的统一服务网格奠定一个基础）。

这一举措对服务网格社区来说，带来不少直接利益：

服务网格的实现可能很复杂；将独立于实现的 API 暴露出来，让系统整体更易理解。
这一社区充满变化，专注于能力，并通过标准接口来使用服务网格，降低了对特定实现的依赖；对最终用户来说，这是一个很好的启动方式。
服务网格提供了一组强大的功能用来定义和处理规则（对网络进行编程）；需要有些东西来对这些能力进行编排。不管是厂商提供还是自行实现，将网络编程为特定的实现，这会将你绑定到这一实现，某种程度上也让你的实现变得更加复杂。
在底层（像服务网格这样）为稳定性奠定基础，给未来的创新打开了新的可能，也给整个生态带来了新的机会。

最小公分母

社区里有些家伙对这类方法的可行性表示怀疑，反对的声音至关重要。例如我非常尊重的 Tim Hockin，他提到 SMI 方法有可能成为一种最小公分母，对谁都没好处。

服务网格的能力范围还在扩张之中（目前不同的服务网格实现会有不同的特性），但是 Istio、Linkerd、Consul、App Mesh 等产品在某种程度上还是殊途同归的：

流量路由功能（路由权重、在七层上提供请求级匹配等）满足了金丝雀发布等功能需求。这项能力的诉求是减小变更的影响范围
- 目前版本的 Istio 和 App Mesh 都已经提供这一功能，Consule 和 Consul 也会很快跟进。
顶端指标收集，例如延迟分布、吞吐量、出错率等
- Istio、App Mesh 和 Linkerd 都提供这一能力，Consul 会在近期提供易于配置的（指标收集）功能。
基于服务身份的策略功能
- Istio 和 Consol 已有这部分功能，Linkerd 和 App Mesh 会在近期加入。

语义差别不大

目前 Istio 的各种特性最为成熟，但是有很多其他的实现也正在跟进。事实上各种实现都很相似，关键的差异是易用性、用户体验、管理能力、集成能力等。而关键的问题：“服务网格应该有什么功能？”，各家的答案差别不大。如果 Istio、Linkerd、Consul、App Mesh 以及其它有兴趣在这一方向发展的厂商和社区能够提供支持，把这些差别不大的功能，做成一套 API 并不会难于登天。

无处不在的 Envoy proxy

服务网格的讨论中，还有一个很重要的情况就是通用数据平面的同化趋势。4 个著名的服务网格产品中，有 3 个使用的是 Envoy，并且还有其他服务网格供应商看起来也准备在 Envoy 的基础之上构建产品。我发现每个实现的控制面可能有些不同，但是内部的网络 API 都是继承自 Envoy，在同一个数据平面之下，一个跨服务网格的通用抽象也不算是不可思议。正如 Tim 所说，最大的麻烦来自于实现上的分歧。在这种情况下，其实这些产品并非天差地别。即使是控制平面本身，其实现也没有那么大的区别。

基于已有实现

最后，SMI 来自于现存的服务网格产品。它不是凭空想象，也没有财团驱动，更不是由没有经验的团队造出的空中楼阁。恰恰相反，这一社区目前的贡献来自于真实存在的、在生产环境中部署的服务网格实现。从各个发起者的经验来说，做出一套脚踏实地的 API 并不会耸人听闻。

厂商主导的 SMI

另外来自 Zack Butcher 的意见也很醒目：SMI 由卖东西的厂商领导，调性不好。他特别提出：

Here's the next sniff test: who's backing the project? Are they users of service meshes trying to drive a standard, or are they vendors (trying to sell me something)? What are their motives, and do they align with giving me, a user, a more usable mesh? 7 pic.twitter.com/Fch2IfFVCM
— Zack Butcher (@ZackButcher) June 9, 2019

他们的动机是什么？是给我——一个用户，一个更可用的服务网格？

SMI 规范的发起者之一，Brendan Burns 有个有趣的回应：

The current state of the art in service mesh where you have to lock yourself into an implementation is bad.

Further, no one can build shared tools for all service meshes which is worse.

And no one can build Helm charts that include service mesh apis w/o chosing an impl.
— brendandburns (@brendandburns) June 8, 2019

从目前服务网格的情况看来，把自己锁定在单一实现上是不好的。更进一步，没有人能够为所有服务网格构建共享工具。除非选择一个实现，否则没有人能构建一个包含服务网格 API 的 Helm Chart。

我所在的 Solo.io，我们乐于看到单一的服务网格界面的出现，这是因为我们始终尝试为客户解决：

不确定选择哪个网格
想要在网格之上构建产品，但是希望在这一动荡的领域中保护投入
希望服务网格的管理能有更好的用户体验
希望将南北流量和东西向的网格进行集成
希望得到厂商的帮助，但是…
无法确信任何网格厂商的动机

我们的客户和潜在和客户对于 SMI 的聚合是持肯定态度的，这一新生事物能够帮助他们应对上述这些问题。

另外企业们发现，在满足其最终需求的情况下，存在竞争的多个公益炕上是很有价值的。正如我熟悉的 Java 和 Java EE 一样。标准化的 API 让企业能够参与并在这些讨论中获益。

胜者为王

关于 SMI，最后一个要探讨的想法是：类似容器编排战争的结果，单一厂商或者单一网格产品会成为唯一的赢家。如果预期是这种结局，又希望现在就用上服务网格，SMI 就成为一种有效的防御措施，防止踏入错误阵营无法回头。

在我看来，真实情况是我们会面对多网格产品并存的情况，我们需要以某种方式进行统一（能力层次、集成方式或者管理方式，或者几个方法的结合）。

例如我们的客户中的真实用例，他们在自有部署中使用 Istio 提供开发支持，但是其他团队使用的是 AWS，也使用了 AWS 的 App Mesh。他们有切实的需求，想要在这些网格的基础之上进行抽象并构建工具。如果出现了一个社区领导的抽象，他们就会使用并从中获得价值（至少是不用自己做了）。

推动服务网格社区举步前行

目前来说，社区中的健康争论是必要的，以此可以发现问题、机遇和目标，从而帮助我们进一步的探索，为最终用户和平台构建者提供服务网格的强大功能。服务网格展现了有力的应用网络能力，但今时今日，终点还遥遥无期。

类比容器和编排系统，Kubernetes 让容器变无聊了，服务网格最终也会让应用网络变得无聊。服务网格在加高堆栈的同时，会给用户、社区以及相关厂商带来价值。如果服务网格生态系统进入了寡头局面，这也很棒，我们会面向单一 API 来构建系统；如若不然（我认为这更有可能），我们最好一同努力，摒弃实现差异，努力找出服务网格应该提供的重要功能。

意外：Servicemesh Interface（SMI）

Tue, 21 May 2019 23:08:25 +0800

在今天的 Kubecon（2019.05.21）上，微软宣布了一个新名词：Service Mesh Interface，简称 SMI，是一个运行于 Kubernetes 之上的服务网格规范，定义了一个能够被多个厂商实现的通用标准，其中包含了能够满足绝大多数通用需求的基本特性。

设计重点

Kubernetes 服务网格的标准接口。
实现最通用的服务网格用例支持。
能够支持新晋厂商加入的兼容能力。
建立有创新空间的生态系统，促进服务网格技术的发展。

规范内容

SMI 中定义了一组描述能力很有限的对象，用于进行服务网格的控制。的确如前文所说的设计重点一样，仅考虑了最核心（也就是最少）的功能支持，以兼容目前和未来的可能有的网格产品。

流量规范

这一组 API 对 HTTP 和 TCP 服务自身进行了定义，例如：

apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
  methods:
  - GET
- name: health
  pathRegex: "/ping"
  methods: ["*"]
---
apiVersion: specs.smi-spec.io/v1alpha1
kind: TCPRoute
metadata:
  name: tcp-route

观察这一段代码样本，其 HTTP 部分，对服务端的路径、动作都做能做出详细的定义。未来这里还将加入对 Header 和 gRPC 的支持，SMI 发起者们认为这是一个很方便利用 OpenAPI 等工具自动生成的部分。它是一个基础，可以用于访问控制、频率限制等高级功能。

访问控制

SMI 提供了一个很简单的访问控制功能，同样是使用 CRD 的方式，例如下面的代码：

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
 name: path-specific
 namespace: default
destination:
 kind: ServiceAccount
 name: service-a
 namespace: default
 port: 8080
specs:
- kind: HTTPRouteGroup
  name: the-routes
  matches:
    - metrics
sources:
- kind: ServiceAccount
  name: prometheus
  namespace: default

这里可以看到，利用 sources 和 destination，对服务的访问能力进行了限制。这两个定义来看，只能包含网格内调用，尚无对 Ingress/Egress 流量的支持。

流量拆分

前面提到，流量拆分是在流量规范的基础上定义的，因此其定义相对简单：

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: foobar-rollout
spec:
  service: foobar
  backends:
  - service: foobar-v1
    weight: 1
  - service: foobar-v2
    weight: 0m

这里的服务定义和 Istio 不同，这个对象的候选访问目标，是选择条件重叠的一组独立服务。典型工作流：

名为 foobar-v1 的 Deployment，标签为 app: foobar version: v1。
服务 foobar，选择器定义为 app: foobar。
服务 foobar-v1，选择标准为 app:foobar 且 version: v1。
客户端使用 foobar 的 FQDN 来完成访问。

要调整流量分拆，只需调整 backends 中不同后端服务的权重即可。

流量监控

指标数据的核心分为两个对象种类：resource 和 edge，resource 代表 pod、namespace、node 等对象，而 edge 则描述了流量的方向。

apiVersion: metrics.smi-spec.io/v1alpha1
kind: TrafficMetrics
# See ObjectReference v1 core for full spec
resource:
  name: foo-775b9cbd88-ntxsl
  namespace: foobar
  kind: Pod
edge:
  direction: to
  resource:
    name: baz-577db7d977-lsk2q
    namespace: foobar
    kind: Pod
timestamp: 2019-04-08T22:25:55Z
window: 30s
metrics:
- name: p99_response_latency
  unit: seconds
  value: 10m
- name: p90_response_latency
  unit: seconds
  value: 10m
- name: p50_response_latency
  unit: seconds
  value: 10m
- name: success_count
  value: 100
- name: failure_count
  value: 100

监控资源除了满足 Prometheus 等监控系统的使用之外，还能对服务拓扑、集群资源监控以及金丝雀发布等功能提供数据支持。

参与厂商

下图是这一新组织的合作方（没有 Google 好奇怪）：

其中多数厂商大家都非常熟悉了，有几个补充一下：

Solo.io：产品面很广，除了 Service Mesh 方面大有名气的 SuperGloo 和 Service Mesh hub 之外，还有远程调试、混沌工程、unikernels 以及微服务网关等几个产品。
Mesery 和 Kinvolk：近期都发表了 Istio vs Linkerd 的性能测试报告。
Canonical：Ubuntu 母公司。
Kubecost：对 Kubernetes 集群进行成本分析。

Solo.io 的 Service Mesh Hub 和 SuperGloo 已经更新，宣布对 SMI 的支持。

根据 Github 的数据，目前贡献前两名分别是 Buoyant 和 HashiCorp。

读后感

在去年 InfoQ 的《Service Mesh2018年度总结》一文中有这么一段话：

Service Mesh 这一技术的广阔前景，加上 Istio 的疲弱表现，吸引了更多对此技术具有强烈需求或相关技术储备的竞争者出现，除了 AWS 、 F5 这样的公有云方案，以及 Consul、Kong 等同类软件解决方案，还出现了 Solo.io 这样的更加激进的跨云方案加入战团。 Service Mesh技术的浪潮已将业界席卷其中，然而这一年来，角逐者有增无减，2019 年里，Istio 仍是关键——除非 Istio 能够做出符合顶尖项目的水准，否则，Service Mesh 技术很可能会以多极化、市场细分的形式落地。

好像我们猜到了开头，猜错了结局？

参考

Istio 和 Linkerd 的性能测试分析

Sun, 19 May 2019 13:29:38 +0800

原文：Performance Benchmark Analysis of Istio and Linkerd

作者：Thilo Fromm

动机

过去几年里，服务网格在 Kubernetes 生态中迅速成长。Service Mesh 的价值难以抗拒，然而对摩拳擦掌的用户来说，另一个基础问题就是：成本怎样？

成本有很多种，可不仅仅是学习新技术时的投入。在这一篇报告中，我们选择了一个易于量化的方面：在一定规模的服务中的资源消耗和性能影响。要进行这个测量，我们设计一系列测试场景，针对候选产品进行测试。我们的的候选包括 Istio（来自 Google 和 IBM 的 Istio 以及 Linkerd（CNCF 项目）。

Buoyant 是 Linkerd 的首创者，他们和我们取得联系，目的是获得一个 Istio 和 Linkerd 的客观评判。这给我们一个深入服务网格技术的机会，欣然从命。

Kinvolk 目前有客户正在尝试 Istio。我们的使命是在云原生世界中促进开源技术的发展，这也是我们呈现这一对比报告的根本原因。

下面使用的测试方案也已经开放给开源社区，地址是 https://github.com/kinvolk/service-mesh-benchmark。

目标

研究过程中我们有三个目标：

提供一个可重现的测试框架，任何人都可以下载和使用。
识别最能反应服务网格运行成本的场景和指标。
根据业界在性能测试方面的最佳实践，例如控制编译来源，处理 Coordinated Omission（CO），来对流行服务网格进行评估。

场景

我们的目标是在常规大负载集群的操作环境下，理解服务网格的性能表现。这意味着在产生压力的时候，集群应用还有能力在已定时间范围内给出响应。在系统受到压力的时候，用户访问该集群所服务的页面，还能够在一个可忍受的范围内提供服务。在真实世界中，延迟增大到一定程度之后，就会采取措施进行扩容了。

在本文的测试中，测试负载（每秒 HTTP 请求）的水平是这样设置的——在给应用和服务网格施加压力的时候，运行其上的流量还在一个可控范围之内。

指标

RPS、用户体验和 CO

测试中使用一个恒定的请求速率（RPS）发送 hTTP 请求，我们对响应延迟进行测量，来确定服务网格的总体性能。同样的 RPS 也会施加到一个无服务网格的集群上，以此结果来描述集群和应用的性能基线。

我们的测试过程很注重 CO，在以 UX 为中心的视角下的一个重要因素。负载生成器只会在前一个请求完成之后才发起新请求，而不是为了满足 RPS 要求，不顾之前的请求直接按照时间点发起心情求。

比如说如果我们要做一个 10 RPS 的延迟测试，我们每隔 100 毫秒就发出一个新请求，也就是一个 10 Hz 的速率。但是如果负载生成器在等待一个耗时超出 100 毫秒的请求的结束的话，那么这个 RPS 最多只能到 9。单一请求造成了高延迟，后续的请求也会受到拖累——处理的并不慢，只是开始得晚了。这种行为有两个缺点：第一个就是刚提到的，单一的高延迟请求造成后续请求的延迟；第二就是请求的发生过程被暂停，不符合 RPS 要求。在真实情况下，高延迟问题很可能因为用户蜂拥而至，产生大量积压。

我们使用 wrk2 来生成负载并在客户端测量延迟。wrk2（Gil Tene）是流行的 http 压测工具 wrk（Will Glozer）的 Fork。wrk2 提供了 RPS 参数，可以用指定速率来生成负载，它通过在发起请求的时间点上测试延迟的方式来消除 CO 问题，还会尝试在请求迟发的情况下以双倍速率生成请求的方式来追赶进度。wrk2 还包含了 Gil Tene 的 HDR 直方图功能，提供了无损精确性的记录。越长的执行时间会有越高的精确度，这样后几个百分位的数据精度更高，也是我们更感兴趣的区域。

为了完成这个测试，我们对 wrk2 的功能做了扩展，加入了多服务器地址和多 HTTP 资源路径的支持。我们不想将这个功能独立 Fork 出来，而是会和上游合作加入我们的变更。

性能

为了评估性能，我们可以研究一下延迟的分布（直方图），尤其是尾部的最后几个百分位的延迟。这反映了我们本次测试在 UE 上的焦点：一个典型的页面或者服务，需要不止一个请求来完成动作。如果一个请求延迟了，整个动作都会变慢。单一请求的 p99 在更复杂的操作中会有很大影响，例如浏览器访问一个页面，获取页面中的资源并进行顺序渲染——这就是我们看重 p99 的原因。

资源消耗

使用服务网格会让集群消耗更多资源，和业务逻辑发生争用。为了更好地理解这一效果，我们同时衡量了服务网格控制平面和应用 Sidecar 中的 CPU 和内存消耗。在测试期间，会用一个较高频率在容器级别收集 CPU 使用率和内存用量，每次运行中会选择组件的最大资源消耗，得出所有运行中的中位数并用于出具结果。

我们注意到，内存消耗在测试结束时达到高峰。这个情况是合理的，根据上面的讨论，wrk2 用固定频率发起请求，当延迟超过一个阈值时，负载就会开始堆积，所以内存一旦分配就一直要到测试结束才会释放。CPU 使用率也会全程持续走高。

测试环境

集群

我们使用了自动部署的测试集群，方便测试过程的启动和结束，也更加容易进行统计，生成可靠的数据。

在这个服务网格性能测试过程中，我们使用了一个 5 节点的集群，每个节点使用 24核/48线程的 AMD EPYC CPU，主频为 2.4GHz，64G 内存。我们的工具可以使用可配置的节点数量，可以用不同的配置重新运行。

负载的生成和延迟的测量都在集群内完成。为了消除噪音和 Ingress Gateway 的数据污染，我们把测试聚焦在应用之间的服务网格。负载生成器作为一个 Pod 部署在集群中，我们保留一个节点，用于负载生成和指标测量，在其它四个节点运行一定数量的应用实例。为了合理的统计分布，我们每次运行都会随机选择一个节点来运行负载生成器。

每次运行之前，会随机选择一个节点专门用于生成负载。其它节点运行应用负责承担负载。

为了完成这次测试，我们选择 Packet 作为我们的 IaaS 供应商，工作节点我们选择了 c2.medium。Packet 提供了裸金属服务器，这样就让我们避免了虚拟化环境中常见的干扰问题。

应用

根据前面的讨论，我们选择 wrk2 生成负载，并对这一工具进行了定制，可以同时访问多个 HTTP 端点。

我们用来运行测试的目标应用是 Linkerd 的演示应用 Emojivoto，这个应用自身跟 Linkerd/服务网格的功能并无相关，Emojivoto 使用一个名为 web-svc（type: load-balancer）的 HTTP 微服务作为前端。web-svc 使用 gRPC 和 emoji-svc（提供表情符）以及 voting-svc（提供可控的投票）后端进行通信。这个应用简单清晰，包含了测试所需的云原生应用的所有要素，因此我们选择它作为测试应用。

Emojivoto 应用包含了三个微服务。

然而只用一个应用进行服务网格测试，是很不现实的，真实世界中的服务网格，应该有复杂的多应用的部署。为了在保持简单的情况下更加仿真，我们用可部署的份数来部署 Emojivoto 应用，每个应用的名字中都加入序号。例如 web-svc-1、emoji-svc-1、voting-svc-1 以及 web-svc-2、emoji-svc-2、voting-svc-2。我们的负载均衡会将请求分发给所有这些 App，观察固定的 RPS。

循环利用 YAML，并在名字中加入序号，部署多套应用。

运行测试和统计的稳健性

因为我们使用的是 Packet 提供的公共数据中心来运行我们的测试，所以也不能选择特定的服务器来进行部署。服务器的年龄和他的部件（内存、CPU 等），数据中心中的相对位置（同一个机架、房间、安全区），以及节点之间的物理连接，这些情况都会对测试的原始数据产生影响。其它服务器和我们的测试无关，但是在同一个数据中心内，共享同样的物理网络资源，也是可能对测试造成干扰的，最终会产生不可靠的测试数据。我们的每个数据点都有足够的统计分布样本，这样在进行对比的时候就能消除同一网络内外部因素造成的影响——例如 Istio 和 Linkerd 的延迟以及资源消耗方面的对比。我们还使用了不同数据中心的多个集群进行了测试，这也让我们对测试数据的可靠性信心大增。

为了得到足够的统计分布，我们会每个测试都会运行两次，以得出平均值和标准差，我们在两个集群上同时独立部署，防止遭遇低档硬件或者故障网络，或有服务器被放置在数据中心的角落。

典型的性能测试一般有几个步骤，这些步骤会在两个集群上同时运行，来消除上面提到的隐患。

测试之前，重启所有工作节点。
在两个集群的 istio-stock、istio-tuned、linkerd、bare 命名空间中，分别：
1. 安装服务网格（当然，不包含 bare）。
2. 部署 emojivoto 应用。
3. 部署负载生成器 Job。
4. 等 Job 结束，每 30 秒拉取一次资源消耗数据。
5. 拉取测试结果日志，其中包含了延迟指标。
6. 删除敷在生成 Job 以及 emojivoto。
7. 删除服务网格。
8. 回到第一步，测试下一个服务网格（顺序为：Linkerd->Istio->Bare）。
9. 在所有的 4 个测试结束之后，再运行第二次，以满足统计需要。

重现性

w我们使用的是 Kinvolk 最近发布的 Kubernetes 发行版：Lokomotive。用于集群部署以及用于测试的代码都是开源的，保存在 Github 上。允许重新进行测试，也希望能够从其它用户那里得到改进。

测试的运行和观测

我们在 bare（无服务网格）、istio-stock（无微调）、istio-tuned 以及 Linkerd 上，用 500 的 RPS 运行 30 分钟。在两个集群上各运行两次，每种数据就有了 4 个样本。测试集群分布在两个不同地理区域的不同的数据中心，一个是 Packet 的 Sunnyvale 数据中心，另一个是纽约的 Parsippany 数据中心。

服务网格的版本

Istio：stock 和 tuned

我们用 Istio 1.1.6 运行这一测试，stock 运行的是根据安装文档进行部署的版本，tuned 版本则移除了内存限制，禁用了部分 Istio 组件，执行了不少推荐的微调。尤其是我们禁用了 Mixer、Policy、Tracing、Gateways 以及 Prometheus。

Linkerd

我们使用的是 Linkerd 的 Linkerd2-edge-19.5.2。我们使用的是 Linkerd 的标准配置，没有进行任何调整。

测试服务网格的上限

在使用稳定吞吐量开始长期运行之前，我们用一个较短的测试来确定服务网格吞吐量和延迟的范围。我们的目标是找到一个负载点，在这个点上，网格还能够用可接受的性能来处理流量。

为了我们的测试，我们运行了 30 个 Emojivoto 应用，也就是 90 个微服务，平均下来每个节点有 7.5 个应用 22 个微服务。我们用多个 RPS 各运行 10 分钟，来确定前面所说的负载点。

测试运行时间

我们最有兴趣的是尾部的百分位，因此测试的运行时间就很有影响了。越长的运行时间，在 99.9999 百分位和 100 百分位上的延迟就会越高。为了模拟用户涌入造成的高峰、以及新计算资源加入后的恢复，我们决定了 30 分钟的运行时间。注意，我们认为在多数环境里，尤其是自动伸缩的环境中，新资源的加入周期应该远低于 30 分钟；我们还认为，一个健壮的应用环境中，30 分钟足以应对扩容方面的意外。

第一次测试：500 RPS，30 分钟

这次测试运行超过 30 分钟，500 RPS。

延迟分布

我们在对数中观察到裸金属案例运行中，出现了很大的错误——可能是 Packet 的问题。这个情况在 99.9 和 99.999 上尤其明显，然而其他的数据点还是证明了整体趋势。我们看到 Linkerd 在这方面是胜出的，Istio 的缺省配置和微调配置相差不大，接下来看看资源消耗。

内存和 CPU

我们在 4 个独立测试运行的过程中，测量了内存分配和 CPU 使用率，在这 4 个样本中，使用了中位数以及最高最低值。Linkerd 控制平面内存消耗的异常点是由 linkerd-prometheus 容器造成的，它消耗了 Linkerd 平面其他组件内存的两倍。

而 Istio 中，我们看到了几次控制平面容器（Pilot 及其代理）消失的情况。我们不明白其中的原因，也没有深究，也没有把消失的容器计入结果。

第二次测试：600 RPS，30 分钟

这次测试运行超过 30 分钟，600 RPS。

延迟分布

我们再次观测到了裸金属测试中的抖动；然而其影响比 500 RPS 的时候更小。我们逼近了 Linkerd 的可接受响应时间的上限，在 100 百分位上的是 3 秒钟的延迟。

Istio 轻松的把延迟时间推到了分钟级（别忘了 Y 轴是对数），我们还看到了大量的 Socket/HTTP 错误，占了大概 1%-5.2%，中位数在 3.6%。我们要指出，Istio 的 RPS 承受范围在 565 和 571 之间，中位数是 568。Istio 在本次测试中没能达到 600 RPS。

上图的对比不太公平——我们看到的是 Linkerd 在 600 RPS 时候的表现，而 Istio 的是 570 RPS——但我们还是看得出，Istio 这里的资源需求。我们再次观察到 Istio 容器消失的情况，同样做了忽略处理。

结论

与裸金属相比，在常规条件下，Linkerd 和 Istio 的开销都算是可以接受的。当进入高负载状态时，相对于 Istio，Linkerd 能够提供更高的 RPS，并且使用更少的资源。

下一步

基于上面测试的观察，我们认为我们建立了一个良好的测试基础。未来的测试会进行更多的尝试，包括增强现有的测试，以及扩展测试场景。

我们认为把负载生成器限制在一个 Pod 中是一个最大的限制。这限制了负载的生成能力。如果突破了这一限制，我们就有能力进行更多样的测试方法。然而在多个 Pod 中并列运行，又带来了结果合并的问题。

后记

以下内容纯属个人胡言乱语

也不知道为啥，连续冒出几个性能测试来，与性能相比，更重要的是靠谱和有用好吗。Istio 还是 Linkerd，能长点心么。

参考资料

https://linkerd.io/2019/05/18/linkerd-benchmarks/

服务网格——模式还是技术？

Thu, 16 Aug 2018 10:27:43 +0800

原文：Service Mesh – A New Pattern, Not A New Technology?

原作者：Marco Palladino

Service Mesh 是什么？从何而来？

近几个月，你会注意到围绕服务网格以及未来软件架构的业内讨论如火如荼。这些讨论围绕着几个供应商，呈现出一种部落战争的态势。这种党争虽然司空见惯，但是其中一些共同话题还是很有意义的——例如企业中 API 应用的快速转型，以及服务网格对流量拓扑的意义。

服务 API 最初用于在组织边界提供访问内部系统的接口，供外部开发人员访问；这种情况并未持续很久，很快，服务 API 就变成将内部系统连接在一起的粘合剂。而微服务架构的发展，带来了一个无法回避的后果：数据中心内的内部通信持续增长。服务网格适时出现，提供了一种面向现有技术的部署框架，可能成为应对东西向流量增长问题的一个解决方案。

作为 Kong 的 CTO，我也很热衷于参加这些对话，我注意到对服务网格的认知有一个普遍误解。为了消除误会，升级对话，首先我想要明确提出：服务网格是一种模式，而非技术。

服务网格是一种模式，而非技术

微服务是模式而非技术，服务网格也是一样。这两种概念的区别貌似很难理解。如果我们从 OOP 的角度来看，模式描述的是接口，不是实现。

服务网格这样的部署模式能够利用 Sidecar 增强东西向的流量管理，能给微服务提供强大支援。既然已经对单体应用进行了解耦，并用微服务构建了新的应用，我们的流量模型中，内部流量就会与日俱增。数据中心内，东西向的流量增长原因是我们将单体应用中的函数调用换成了网络调用，这意味着我们的微服务必须融入网络，互相消费。然而地球人都知道——网络靠不住。

面对日益增长的东西向流量，服务网格通过新的部署架构进行应对。传统的南北向通信中，100 毫秒的延迟虽不够理想，但也在可接受范围之内；但在东西向通信中，这就无法忍受了。这是因为服务间的相互调用会使延迟倍增，跨越多个服务的 API 调用和返回，会造成延迟时间的大幅增加。

为了降低延迟，引入了独立运行的 Sidecar，这种代理服务器会伴随微服务进程一起运行，用来移除多余的网络跳跃。Sidecar 在请求的执行路径上担任数据平面的角色，并且避免了单点失败，从而提供了更好的应用弹性。然而，每个微服务进程都配合一个代理进程，势必会造成资源的损耗，但同时他也降低了资源耗尽的肯能性。

经过细致观察不难发现，服务网格中的很多功能，都已经在多年前的 API 管理产品中实现了。比如可观测、网络故障处理和健康检查等功能都是 API 管理的基本配置。这些特性并不新鲜，但服务网格作为一种新的模式，用新思路来完成了这些功能。

传统 API 管理方案瞠目其后

微服务和容器大潮迫使人们更多的关注轻量级进程，服务网格提供的轻量级进程，同时承担了代理和反向代理的角色，伴随微服务进程一同运行。为什么传统的 API 管理方案不采用这种新的部署方案？这是因为他们生于单体时代。这些早于 Docker 和 Kubernetes 面世的 API 管理系统本身就是单体应用，并不适用于新兴的容器生态圈。传统 API 管理方案往往具有重量级的运行时和低下的性能，这些问题在过去的边缘 API 用例中尚可承受，但是对于微服务体系来说，东西向调用量越多，中间环节的延迟就越大。究其根本，传统 API 管理方案的重量大、难度高以及速度慢的缺点是难以满足微服务世界的要求的。

开发人员了解了这些，传统的 API 管理方案引入了称之为 “microgateway”（微型网关）的技术，用来处理东西向的流量，并且避免重写现存的臃肿的单体网关方案。问题是这些所谓的微型网关虽然自身变轻了，但还是要依赖传统方案伴行，用于提供策略实施等能力。这不仅是留下陈旧组件的问题，还意味着增加了延迟。如此种种，服务网格就令人耳目一新了——对手太旧了。

结语

传统的 API 管理方案在南北向流量管理中耕耘多年，服务网格的功能相对来说并不新鲜。多数网络方面以及观测方面的能力对东西向和南北向的流量都是通用的，服务网格让我们有机会运行轻量快速的 Sidecar 代理来完成这些通用功能，改变的是部署模式，不是底层功能。

传统 API 管理方案的功能是服务网格功能的超级，某种意义上来说，普及了可靠性、服务发现和观测能力。服务网格是一种部署模式，用轻量级的方式获得同样的功能。业界经常混淆——有时还加重了这种混淆——很多服务网格方面的讨论，都混淆了特定部署模板和底层技术的界限。

Istio 大入门 - Ingress

Sat, 11 Aug 2018 14:44:26 +0800

本文涉及细节较多，需读者对 Docker、Kubernetes 以及 Istio 有一定了解和实践经验，否则可能难于操作。

Istio 从 v1alpha3 开始，用 Ingress Gateway 组件替代了符合 Kubernetes 规范的 Ingress Controller，因此对入站流量具有了更大的控制能力，但是用法也有了较大不同。

安装：在使用 Helm 进行 Istio 部署的时候，需要使用下面的设置来启用 Ingress Gateway：

gateways:
  enabled: true
  istio-ingressgateway:
    enabled: true

基本概念

VirtualService 是流量控制的核心组件，起着承上（Gateway）启下（DestinationRule）的作用。这三种对象在本文中涉及的主要职责：

Gateway 对象：
- 选择 Gateway Ingress Controller。
- 设置端点开放方式：域名、端口、入站协议等。
DestinationRule：
- 定义负载均衡行为。
- 定义服务版本子集。
VirtualService：
- 根据 Gateway 选择服务版本。

根据 VirtualService 对象文档中的说明，VirtaulService 对象中的 gateways 字段的类型为 string[]，包括一或多个字符串值。如果省略该字段内容，会隐式的赋值为 ["mesh"]，mesh 网关指代所有的网格内通信。如果要对外提供服务，就需要定义 Gateway 对象，并在 gateways 字段中进行赋值。

注意，一旦在 gateways 中填写了非缺省的对象名称，要继续对内部通信进行流量控制，必须显式的将内置的 mesh 对象名称也加入到列表之中。

准备工作

环境准备

安装和部署 Kubernetes 以及 Istio，并启用 Ingress Gateway 支持。
将备用的两个域名（假设为 flask.example2.com 以及 flask.example1.com）指向 istio-ingressgateway 服务的外部 IP。
为测试域名生成 HTTPS 证书。

域名准备

工作负载

首先编写一个基于 Flask 的 Python 脚本，并打入镜像，脚本功能很简单，显示环境变量中的 “VERSION”。
接下来编写 Dockerfile，安装 Python3、Flask，并进行构建和推送。
编写 Kubernetes 工作负载文件，常见的 Deployment + Service 模式。
在 Kubernetes 上运行工作负载。

以上涉及代码可以在页面尾部获取。

目标规则定义

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: flask
spec:
  host: flask
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

这里根据工作负载中的标签，将 flask 服务拆分为 v1 和 v2 两个版本。

在外网开放服务

这里我们设计，将所有外网请求经过 flask.example1.com 路由到 v2 版本上。

首先要编写一个 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - flask.example1.com
        - flask.example2.com

这里定义了一个 Gateway，其中要求 80 端口响应两个域名的请求。接下来定义一个 VirtualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
    name: flask
spec:
    hosts:
    - "flask.example1.com"
    gateways:
    - flask-gateway
    http:
    - route:
        - destination:
            host: flask
            subset: v2

然后使用 curl 进行访问：curl http://flask.example1.com 会发现返回了字符串 “v2”，证明我们的定义生效了，该域名指向了 v2 服务。

再用 curl 访问第二个域名 curl http://flask.example2.com，会看到返回了 404，这是因为我们的 Gateway 虽然接收了请求，但是并没有服务路由完成这一请求。那么可以再定义一个 VirtualService，让 flask.example2.com 域名指向 v1：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
    name: flask1
spec:
    hosts:
    - "flask.example2.com"
    gateways:
    - flask-gateway
    http:
    - route:
        - destination:
            host: flask
            subset: v1

再次使用 curl http://flask.example2.com，访问，会看到返回结果变成了 v1，证明我们的服务定义生效了。

将一个域名服务升级为 tls

随意修改一个需求，要求开放 flask.example2.com 为 http，而 flask.example1.com 升级为 https，既然涉及 https，就要用到证书，官方文档（中文版哦）陈述如下：

具体说来就是使用 kubectl 命令在命名空间 istio-system 中创建一个 secret 对象，命名为 istio-ingressgateway-certs。Istio 网关会自动载入这个 secret。这里的 secret 必须在 istio-system 命名空间中，并且命名为 istio-ingressgateway-certs，否则就不会被正确载入，也就无法 Istio gateway 中使用了。

接着是使用命令为 flask.example1.com 的证书创建 Secret：

$ kubectl create -n istio-system secret tls \
    istio-ingressgateway-certs \
    --key key.pem --cert cert.pem

最后修改我们的 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - flask.example2.com
    - port:
        number: 443
        name: https-rocks
        protocol: HTTPS
      tls:
        mode: SIMPLE
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key
      hosts:
        - flask.example1.com

然后再次使用 curl 分别访问 https://flask.example1.com/version 以及 http://flask.example2.com/version，会发现返回了预期结果，而一旦错用 http 和 https，就会出现异常，这是因为我们的 Gateway 限制了端口。

这里如此操作的原因可以在他的部署中找到：

$ kubectl get deployment istio-ingressgateway \
    -o yaml -n istio-system

返回的 YAML 中会有这么一段

...
- mountPath: /etc/istio/ingressgateway-ca-certs
    name: ingressgateway-ca-certs
    readOnly: true
...
volumes:
- name: ingressgateway-certs
secret:
    defaultMode: 420
    optional: true
    secretName: istio-ingressgateway-certs
...

上方代码可以看到，Ingress Gateway 中用可选方式加载了一个名称为 istio-ingressgateway-certs 的 Secret，并 Mount 到了 /etc/istio/ingressgateway-ca-certs 目录之中，这就是上文中要求我们固定 Secret 名称和命名空间的原因。众所周知，tls 类型的 Secret 加载后会成为 tls.key 和 tls.crt 两个文件，因此在我们的 Gateway 定义中就使用了 /etc/istio/ingressgateway-certs/tls.crt 这样的文件名。

所有域名都升级为 tls

根据上一节的描写，不难发现按照官方文档，一个 Gateway 是无法处理两个域名的 https 的：

tls secret 只能包含一个证书对。
泛域名证书可以完成这一任务，但因为 Envoy 的限制，这里无法同时使用两个泛域名。

讨论到这里就很明显了，关键在于如何加载多个证书对，可以修改前面所说的加载指令为加载多个 Secret，或者干脆换成 Configmap，当然这样会引起服务中断，Configmap 用于存放证书也略显粗糙——好在我们还可以换用 Generic 类型的证书，这里我们可以删除原有 Secret 重新创建：

kubectl delete secret istio-ingressgateway-certs \
    -n istio-system

kubectl create secret generic  \
    istio-ingressgateway-certs \
    -n istio-system \
    --from-file=rocks-crt.pem \
    --from-file=rocks-key.pem \
    --from-file=xyz-crt.pem \
    --from-file=xyz-key.pem

接下来改造我们的 Gateway 定义：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: flask-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https-rocks
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/rocks-crt.pem
      privateKey: /etc/istio/ingressgateway-certs/rocks-key.pem
    hosts:
    - "flask.example1.com"
  - port:
      number: 443
      name: https-xyz
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/xyz-crt.pem
      privateKey: /etc/istio/ingressgateway-certs/xyz-key.pem
    hosts:
    - "flask.example2.com"

这样一来，我们开放了两个 HTTPS 端口，各自使用不同的证书，分别都可以通过 curl 命令获得正确结果了。

补充

tls.mode 实际还支持双向和透传两种方式，都可以在流量控制参考中找到相关内容。

涉及链接

Istio 流量控制参考：https://istio.io/docs/reference/config/istio.networking.v1alpha3/
用 HTTPS 加密 Gateway：https://istio.io/zh/docs/tasks/traffic-management/secure-ingress/

代码

Python 脚本

#!/usr/bin/env python3
# -*- coding: UTF-8 -*-

from flask import Flask
import os

app = Flask(__name__)

@app.route("/")
def hello_world():
    return "Hello, World!"

@app.route("/version")
def getversion():
    return os.getenv("VERSION")
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Dockerfile

FROM alpine
RUN  apk add --update --no-cache python3 && \
  mkdir /web && \
  pip3 install Flask
COPY server.py /web
CMD "/web/server.py"

Kubernetes 工作负载

apiVersion: v1
kind: Service
metadata:
  name: flask
  labels:
    app: flask
spec:
  ports:
    - name: http
      port: 80
  selector:
    app: flask
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flask-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flask
        version: v1
    spec:
      containers:
        - image: 'abc:25000/python-flask-server:v2'
          imagePullPolicy: IfNotPresent
          name: flask
          env:
            - name: VERSION
              value: v1
          ports:
            - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flask-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: flask
        version: v2
    spec:
      containers:
        - image: 'abc:25000/python-flask-server:v2'
          imagePullPolicy: IfNotPresent
          name: flask
          env:
            - name: VERSION
              value: v2
          ports:
            - containerPort: 80

Consul vs Istio

Wed, 11 Jul 2018 19:40:12 +0800

原文：Consul vs Istio

Istio 是一个开源平台，可以为微服务提供连接、管理和加密功能。

要启用 Istio 的全部功能，必须部署多个服务。控制面包括了 Pilot、Mixer 以及 Citadel 这几个必要组件，数据面的 Envoy Sidecar 也是必不可少的。另外 Istio 需要第三方的服务发现支持，例如 Kubernetes、Consul、Eureka 或者其他别的什么。最后 Istio 需要一个外部系统用来进行存储，通常是 ETCD。换句话说，Istio 需要至少三个独立的服务，以及至少一个分布式系统才算完整。

Istio 在七层提供了基于路径的路由、流量整形、负载均衡以及遥测功能。Istio 还基于服务认证功能提供了访问控制的支持，能使用七层和四层的属性对访问、路由进行控制。

Consul 是一个单一的二进制文件，同时提供了服务器和客户端的能力，并自带全部的服务发现、配置、TLS、认证等功能。无需安装额外的系统即可使用，同时还为 Vault 之类的外部系统提供了可选支持，从而进行功能扩展。这一架构让 Consul 能够轻松的安装在任何平台上，也包括物理机。

Consule 是一个基于 Agent 的模型，集群中的每个节点都需要运行一个 Consul 客户端。客户端软件管理一个本地缓存，缓存的数据来源于服务器。无需任何外部通信，所有的加密服务通信 API 都能在几毫秒的时间内进行响应。这样我们的连接过程发生在边缘，无需和中央服务器进行通信。Istio 将请求流入位于中央的 Mixer 服务，而数据的推送过程又必须由 Pilot 完成。这种机制极大的降低了 Istio 的稳定性，而 Consul 却能够在边缘高效的完成数据更新的分发以及其他工作。

Consul 的数据面是可插接的。它包含了一个内置的代理服务器，这一服务牺牲了较多性能，换来易用性的提升。用户也可以使用 Envoy 这样的第三方代理。不同的任务会有各自合适的代理，Consul 就提供了这种能力，从而能够支持复杂多样的应用部署。

除了第三方代理支持，应用可以直接和 Connect 协议进行集成。这样一来，引入 Connect 的开销就可以忽略不计了。任何其他的 Connect 支持的应用，不管使用代理或者 Connect 原生方式，都具备互联互通的能力。

Consul 只在四层实现了认证和鉴权——TLS 连接是否能够建立。我们认为服务认证应该留在四层，七层要做的事情是路由、遥测等事情。我们鼓励用户借助我们的可插接数据面，为集群所需要的七层功能选择合适的代理服务器。Consul 会在未来加入更多七层特性。

Consul 实现了自动的 TLS 认证管理，并且提供了完整的轮转支持。即使是一个大型的 Consul 集群中，也能够在无中断的情况下实现自动轮转。认证管理系统也是可插接的，目前通过代码集成在 Consul 中，很快我们会将其剥离成为外部插件。这就 Consul 就有了和任意 PKI 方案协同工作的能力。

因为 Consul 的服务连接能力（”Connect“）是内置的，他也具备和 Consul 一样的稳定性。2014 年以来，Consule 就在大型企业的生产环境中工作，目前已经有单集群部署 50000 节点的规模。

这一比较基于我们自己对 Istio 的有限认识，以及和 Istio 用户的交流。如果读者认为其中有不实之处，请点击 Edit this page 提交修改建议。我们会尽快对读者意见进行审核和更新，希望以此来保证本文的准确性。

Conduit 0.5 发布 —— 以及 R.I.P. Conduit

Sat, 07 Jul 2018 09:20:04 +0800

7 月 6 日，Linkerd 博客再次更新，宣布 Conduit 0.5 发布：在翻炒了无数次 Prometheus 支持的冷饭之后，终于发布了新的功能 —— TLS 支持。

紧接着一个更加重磅的消息：0.5 将是 Conduit 最后一个版本，未来将作为 Linkerd 2.0 的基础继续存在 - Conduit 的 Github 项目将会转移为 Linkerd2。

回想一下，2017 年 12 月 5 日发布到现在的两百多天里，一共发布了 13 个版本、9 篇文档以及 12 篇博客。大致完成了 Conduit 问世之初的承诺：轻量、快速以及 Service Mesh 该有的种种功能；然而很可惜，第一篇 Conduit 博客中还提到了一点：“Conduit is not Linkerd 2.0. ”。这一次“战略性转移”，也印证了之前大家的担心——如果自身投入不足，又不能有效持续制造焦点、获取社区的持续关注和支持，先驱就变成先烈了。

Service Mesh 的鏖战尚未开始，已经有人出局了，R.I.P. Conduit。

HTTP Egress 流量的监控和访问策略管理

Sat, 23 Jun 2018 10:48:57 +0800

原文：Monitoring and Access Policies for HTTP Egress Traffic

作者：VADIM EISENBERG 和 RONEN SCHAFFER

Istio 的主要功能就是在服务网格内部管理微服务之间的通信，除此之外，Istio 还能对 Ingress（从外部进入网格）和 Egress（从网格发出到外部）流量进行管理。不管是网格内部流量，还是 Ingress 或者 Egress 流量，Istio 都能够在其中进行访问策略的控制，并完成遥测数据的聚合工作。

本文中我们会展示如何使用 Istio 在 HTTP Egress 流量中实施监控和访问策略控制。文中谈到的内容针对 Istio 0.8.0 及以上是有效的。

用例

假设一个组织正在运行的应用需要处理来自于 cnn.com 的内容。这些应用已经被解构为部署在 Istio 服务网格中的微服务。这些应用要获取 cnn.com 多个频道的内容：edition.cnn.com/politics、edition.cnn.com/sport 以及 edition.cnn.com/health。目前已经配置 Istio 使其允许访问 edition.cnn.com，一切运行良好。然而在某一天，他们决定限制政治方面的内容，技术上讲，就是要阻止对 edition.cnn.com/politics 的访问，继续允许对 edition.cnn.com/sport 以及 edition.cnn.com/health 的访问。对 edition.cnn.com/politics 的访问需要在应用程序、命名空间以及用户的不同粒度上进行访问控制。

要实现这个目标，运维人员需要监控对外部服务的访问，并分析 Istio 日志来确保对 edition.cnn.com/politics 的访问都是经过授权的。另外他们还要配置 Istio，让 Istio 自动阻止对 edition.cnn.com/politics 的（未授权）访问。

该组织决定防止对新策略发生篡改，通过技术手段执行策略，防止恶意应用访问受限内容。

开始之前

依照配置 Egress Gateway，使用 Egress Gateway 执行 TLS 访问任务中的步骤，不要执行清理操作。完成之后，就可在网格之内使用安装了 curl 的容器来访问 edition.cnn.com/politics 了。下面的内容中，我们假设名为 SOURCE_POD 的环境变量中包含了 Pod 名称。

配置监控和访问策略

既然要用安全方式来完成任务，就需要通过 egress gateway 来进行 egress 传输，这部分内容在配置 Egress Gateway 中有详细描述。这里所谓的安全方式指的是防止恶意应用绕过 Istio 监控和策略管理进行未经授权的访问。

我们的场景中，该组织执行了上一节“开始之前”的步骤。这个步骤完成后，开放了对 edition.cnn.com 的访问，并且配置了响应的 Egress Gateway。现在可以对 edition.cnn.com 进行监控和策略进行配置了。

日志

首先配置一下对 *.cnn.com 的记录。创建一个 logentry 和两个 stdio 类型的 handler，其中一个用 error 级别的日志来记录受限的访问，另外一个用 info 级别来记录所有到 *.cnn.com 的访问。接下来创建 rules 把 logentry 定向到 handler 上。对 *.cnn.com/politics 的访问会被指派给受限访问的规则，剩余的访问则会被另一条规则接收。要理解 Istio 的 logentries、rules 以及 handlers，可以阅读 Istio Adaper Model 一文。下面的示意图中包含了刚才讲到的这些实体和依赖关系：

创建 logentries、rules 以及 handlers：

# egress 访问的日志条目
apiVersion: "config.istio.io/v1alpha2"
kind: logentry
metadata:
name: egress-access
namespace: istio-system
spec:
severity: '"info"'
timestamp: request.time
variables:
destination: request.host | "unknown"
path: request.path | "unknown"
source: source.labels["app"] | source.service | "unknown"
sourceNamespace: source.namespace | "unknown"
user: source.user | "unknown"
responseCode: response.code | 0
responseSize: response.size | 0
monitored_resource_type: '"UNSPECIFIED"'
---
# Handler for error egress access entries
apiVersion: "config.istio.io/v1alpha2"
kind: stdio
metadata:
name: egress-error-logger
namespace: istio-system
spec:
severity_levels:
info: 2 # 输出级别为 error
outputAsJson: true
---
# 访问 *.cnn.com/politics 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-politics
namespace: istio-system
spec:
match: request.host.endsWith("cnn.com") && request.path.startsWith("/politics")
actions:
- handler: egress-error-logger.stdio
instances:
- egress-access.logentry
---
# Info 级别的 Egress 日志
apiVersion: "config.istio.io/v1alpha2"
kind: stdio
metadata:
name: egress-access-logger
namespace: istio-system
spec:
severity_levels:
info: 0 # 输出为 Info 级别
outputAsJson: true
---
# 访问 *.cnn.com 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com")
actions:
- handler: egress-access-logger.stdio
instances:
- egress-access.logentry

分别向 edition.cnn.com/politics、edition.cnn.com/sport 发送请求，所有请求都应该返回 200 OK。

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

查询 Mixer 的日志，查看日志中出现的请求信息：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

返回如下信息：

{"level":"info","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"error","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"error","time":"2018-06-18T13:22:58.317448Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":200,"responseSize":150448,"source":"sleep","user":"unknown"}
{"level":"info","time":"2018-06-18T13:22:59.354943Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":332218,"source":"sleep","user":"unknown"}

会看到关于三个请求的四条日志。三个 info 级别的条目是关于 edition.cnn.com 的，一条 error 级别的条目就是关于 edition.cnn.com/politics 的访问。服务网格的运维人员能看到所有的访问情况，并且也能通过对 error 日志的搜索来查找受限访问。这是在禁止访问之前的第一个监控措施，把所有受限访问都作为错误记录下来，在某些情况下，这就足够安全了。

利用路由进行访问控制

在启动对 edition.cnn.com 的访问日志之后，自动启动了一个访问策略，只允许访问 /health 和 /sport URL。这样简单的策略控制可以用 Istio 路由来实现。

重新定义 edition.cnn.com 的 VirtualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
  - mesh
  port: 80
route:
- destination:
    host: istio-egressgateway.istio-system.svc.cluster.local
    port:
      number: 443
  weight: 100
- match:
- gateways:
  - istio-egressgateway
  port: 443
  uri:
    regex: "^.health|^.sport"
route:
- destination:
    host: edition.cnn.com
    port:
      number: 443
  weight: 100

注意这里加入了一个针对 uri 的 match 条件，会检查 URL 路径是不是 /health 或者 /sport。另外还要注意的是，这个条件是加入到 VirtualService 的 istio-egressgateway 部分，egress gateway 是一个需要注意安全的组件（参见 Egress Gateway 的安全考量），应该慎重对待其安全性，防止影响后续的策略实施过程。

再次发送之前的三个 HTTP 请求：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

会看到 edition.cnn.com/politics 返回了 404 Not Found，edition.cnn.com/sport 和 edition.cnn.com/health 都返回了 200。

VirtualService 的传播和生效可能需要几秒钟的等待。

查询 Mixer 日志，看看刚才发生的请求在日志中的体现：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

得到结果如下：

{"level":"info","time":"2018-06-19T12:39:48.050666Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":0,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"error","time":"2018-06-19T12:39:48.050666Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":0,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"info","time":"2018-06-19T12:39:48.091268Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":334027,"source":"sleep","sourceNamespace":"default","user":"unknown"}
{"level":"info","time":"2018-06-19T12:39:48.063812Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","responseCode":200,"responseSize":355267,"source":"sleep","sourceNamespace":"default","user":"unknown"}

这里还能看到 edition.cnn.com/politics 的访问日志，只不过这次的 responseCode 是 404。

使用 Istio 路由之后，我们成功的实现了初步的访问控制，但是如果是更复杂的需要，这种程度还是不够的。例如希望允许特定条件下对 edition.cnn.com/politics 的访问，这需要一些更复杂的策略，只判断 URL 是不够的。这就需要 Istio Mixer Adapter，（例如白名单和黑名单）的协助，来协助控制对 URL 路径的允许和禁止行为。借 [Policy Rules] 的帮助，这样就可以使用 Istio expression language 来实现复杂条件的定义，完成包含逻辑控制在内的复杂限制了。这些规则可以在日志和策略检查之间进行复用。另外还可以使用 Istio RBAC进行更复杂的控制。

还有一个额外的需要就是和远程访问策略系统进行集成。如果用例中设计的组织已经有使用一些认证和访问管理系统，可能会需要配置 Istio 从这些系统中获取访问策略方面的信息。可以通过实现 Istio Mixer Adapter 的方式来进行集成。

取消掉前面我们使用路由规则实现的访问控制，接下来使用 Mixer 策略来实现。

用之前的 Configure an Egress Gateway 中的版本替换 edition.cnn.com 的 VertualService：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-through-egress-gateway
spec:
hosts:
- edition.cnn.com
gateways:
- istio-egressgateway
- mesh
http:
- match:
- gateways:
  - mesh
  port: 80
route:
- destination:
    host: istio-egressgateway.istio-system.svc.cluster.local
    port:
      number: 443
  weight: 100
- match:
- gateways:
  - istio-egressgateway
  port: 443
route:
- destination:
    host: edition.cnn.com
    port:
      number: 443
  weight: 100

再次发送之前的三个到 cnn.com 的请求，这里会看到三个 200 的成功返回：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

VirtualService 的传播和生效可能需要几秒钟的等待。

使用 Mixer 策略进行访问控制

这一步中，我们使用 Listchecker adapter，这是白名单的一个变体。用一个静态 URL 列表定义一个 listentry，然后在 listchecker 中用 overrides 字段进行检查。如果有外部的认证和访问管理系统，可以使用 providerurl 字段取而代之。下面图示显示了更新之后的对象关系。注意这里复用了同样的策略，handle-cnn-access 对日志和访问策略同样生效。

定义 path-checker 以及 request-path：

apiVersion: "config.istio.io/v1alpha2"
kind: listchecker
metadata:
name: path-checker
namespace: istio-system
spec:
overrides: ["/health", "/sport"]  # 提供一个静态列表
blacklist: false
---
apiVersion: "config.istio.io/v1alpha2"
kind: listentry
metadata:
name: request-path
namespace: istio-system
spec:
value: request.path

修改 handle-cnn-access 规则，要求将 request-path 发送给 path-checker：

# 访问 cnn.com egress 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com")
actions:
- handler: egress-access-logger.stdio
instances:
  - egress-access.logentry
- handler: path-checker.listchecker
instances:
  - request-path.listentry

再次执行 curl 指令，发现 edition.cnn.com/politics 返回了 404：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

使用 Mixer 策略进行访问控制（续）

在前面我们配置了日志和访问控制之后，新增一个需要就是允许在 policics 命名空间内的应用能够访问 cnn.com 的所有内容，并且不受监控。接下来我们在 Istio 中进行配置，完成这一要求。

创建 polictics 命名空间

$ kubectl create namespace politics
namespace "politics" created

在 polictics 命名空间中启动 sleep。

如果使用了自动注入 Sidecar，执行：$ kubectl apply -n politics -f samples/sleep/sleep.yaml，否则，就需要进行注入了：kubectl apply -n politics -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)。

预备使用 policics 命名空间中的 sleep pod 来发送请求，这里定义一个环境变量来保存 Pod 名称。
```
export SOURCE_POD_IN_POLITICS=$(kubectl get pod -n politics -l app=sleep -o jsonpath={.items..metadata.name})
```

这次从新的 Pod（$SOURCE_POD_IN_POLITICS）中发送刚才的请求。因为我们还没有给新的命名空间中的应用设置例外，edition.cnn.com/politics 还是返回了 404。

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

查询 Mixer 日志，会看到来自 politics 命名空间的访问记录：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn | tail -4

查询结果：

{"level":"info","time":"2018-06-19T17:37:14.639102Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":76,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"error","time":"2018-06-19T17:37:14.639102Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","responseCode":404,"responseSize":76,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"info","time":"2018-06-19T17:37:14.653225Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/sport","responseCode":200,"responseSize":356349,"source":"sleep","sourceNamespace":"politics","user":"unknown"}
{"level":"info","time":"2018-06-19T17:37:14.767923Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/health","responseCode":200,"responseSize":334027,"source":"sleep","sourceNamespace":"politics","user":"unknown"}

上面的输出中可以看到 sourceNamespace 的值为 politics。

重新定义 handle-cnn-access 以及 handle-politics 策略，为新的命名空间定义例外的日志和访问策略。

apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-politics
namespace: istio-system
spec:
match: request.host.endsWith("cnn.com") && request.path.startsWith("/politics") && source.namespace != "politics"
actions:
- handler: egress-error-logger.stdio
instances:
- egress-access.logentry
---
# 访问 egress cnn.com 的规则
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
name: handle-cnn-access
namespace: istio-system
spec:
match: request.host.endsWith(".cnn.com") && source.namespace != "politics"
actions:
- handler: egress-access-logger.stdio
instances:
  - egress-access.logentry
- handler: path-checker.listchecker
instances:
  - request-path.listentry

在 $SOURCE_POD 中重复执行测试：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200

$SOURCE_POD 是在 default 命名空间的，所以对 edition.cnn.com/politics 的访问会被拒绝。

在 $SOURCE_POD_IN_POLITICS 中重复执行测试：

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

现在所有访问都可以通过了。

查看 Mixer 日志，会发现看不到 sourceNamespace 为 politics 的条目了：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer-type=telemetry -o jsonpath='{.items[0].metadata.name}') mixer | grep egress-access | grep cnn

Dashboard

让运维人员能够可视化的进行 egress 流量监控，也能增强安全性。

浏览使用 Grafana 进行指标可视化任务，完成其中的步骤 1-3。

从 $SOURCE_POD 发送到 cnn.com 的请求：

$ kubectl exec -it $SOURCE_POD -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
404
200
200

因为 $SOURCE_POD 是存在于 default 命名空间中的，所以对 edition.cnn.com/politics 的访问会被拒绝。

从 $SOURCE_POD_IN_POLITICS 发送到 cnn.com 的请求：

$ kubectl exec -it $SOURCE_POD_IN_POLITICS -n politics -c sleep -- bash -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
200
200
200

滚动 Dashboard 到 HTTP 服务部分的 istio-egressgateway.istio-system.svc.cluster.local 一节。会看到大致如下的显示：

在左侧 Requests by Source, Version and Response Code 中，会看到 default 命名空间中的 unknown 版本的 sleep 应用收到的 404 返回码。运维人员可以据此发现试图访问受控目标的应用。还可以看到在 polictics 命名空间中 sleep 应用收到的 200 返回码，这样也就知道了对受控外部资源的有效访问情况。

和 HTTPS egress 控制的比较

这个用例中，应用使用的是 HTTP 和 Istio Egress Gateway 结合提供 TLS 的。换个方式，应用可以自行发送 TLS 请求给 edition.cnn.com，本节中我们会对两种方式的优劣进行一些比较。

HTTP 方式中，请求在本地是明文传输，经由 Sidecar 转发给 Egress Gateway 的。如果 Istio 使用双向 TLS 部署，Sidecar 代理和 Egress Gateway 之间的通信就是加密的。Egress Gateway 解密信息，查看 URL 路径，HTTP 方法和 Header，上报监控数据、执行前置检查。如果请求没有被拒绝，Egress Gateway 就会为外部目标执行 TLS 封装，这样请求就会被再次加密，以密文形式发送给外部目标。下图演示了这种方式中的网络流向。图中 Gateway 方块中的 HTTP 标志，代表报文在 Gateway 解密之后变成明文的阶段。

这种方式的缺陷在于，请求在本机是明文传输的，可能会违反某些组织的安全需要。有些 SDK 的外部服务 URL 包含协议部分都是硬编码的，因此发送 HTTP 请求是不可能的。这种办法的好处是可以获取 HTTP 头、方法以及 URL 路径，并可以据此制定规则。

在 HTTPS 形式下，从应用到外部目标的请求是端到端加密的。下图演示了这种方式的数据流。在 Gateway 中见到的报文，同样还是 HTTPS。

端到端的 HTTPS 可能是更好的一种加密方式。然而因为流量是加密通过 Istio 代理和 Egress Gateway 的，因此只能看到源和目的的 IP 以及 SNI。在 Istio 开通双向 TLS 的情况下，源身份也是可知的。Gateway 无法获知 HTTP 头、方法以及 URL 路径，因此基于 HTTP 信息的策略就无法实现了。我们的用例中要求可以访问 edition.cnn.com。如果 Istio 中启用了双向 TLS，组织可以设置部分应用允许访问 edition.cnn.com。然而却无法允许或禁止访问特定的 URL。对 /politics 的允许或者禁止，在这种上下文中都是无法实现的。

我们认为，这样讲解之后，用户就可以对这两种方法进行优劣势的评估，进而做出合适的选择。

结论

本文中我们展示了 Istio 用 HTTP 访问 Egress 时的监控和策略。其中的监控过程，可以配置日志适配器结合 Istio Dashboard 来完成。而访问策略可以通过配置 VirtualService 或者配置多种策略适配器来完成。我们演示了一个简单的策略，只允许某些 URL 的访问。我们另外还展示了稍微复杂一些的策略，通过放行指定命名空间中的指定应用，来做出例外。最后，我们比较了两种 HTTPS 过程的优劣，同时也就有不同的控制能力。

清理

执行配置 Egress Gateway 任务中的清理任务。

删除日志和策略配置：

kubectl delete logentry egress-access -n istio-system
kubectl delete stdio egress-error-logger -n istio-system
kubectl delete stdio egress-access-logger -n istio-system
kubectl delete rule handle-politics -n istio-system
kubectl delete rule handle-cnn-access -n istio-system
kubectl delete -n istio-system listchecker path-checker
kubectl delete -n istio-system listentry request-path

删除 politics 命名空间
执行使用 Grafana 进行指标可视化任务中的清理环节。

Istio 的软性多租户支持

Fri, 15 Jun 2018 15:20:36 +0800

原文：Istio Soft Multi-tenancy Support

作者：John Joyce, Rich Curran

多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。Kubernetes 多租户工作组致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。

软性多租户

文中提到的“软性多租户”的定义指的是单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。集群管理员对所有 Istio 控制面都有控制和监控的能力，而租户管理员仅能得到指定 Istio 的控制权。使用 Kubernetes 的命名空间和 RBAC 来完成不同租户的隔离。

这种模式的一个用例就是企业内部共享的基础设施中，虽然预计不会发生恶意行为，但租户之间的清晰隔离仍然是很有必要的。

在文章最尾部会对 Istio 未来的多租户模型进行一些描述。

注意：这里仅就在有限多租户环境中部署 Istio 做一些概要描述。当官方多租户支持实现之后，会在文档中具体呈现。

部署

多个 Istio 控制面

要部署多个 Istio 控制面，首先要在 Istio 清单文件中对所有的 namespace 引用进行替换。以 istio.yaml （v0.8 中应该是 istio-demo.yaml）为例：如果需要两个租户级的 Istio 控制面，那么第一个租户可以使用 istio.yaml 中的缺省命名空间也就是 istio-system；而第二个租户就要生成一个新的 Yaml 文件，并在其中使用不同的命名空间。例如使用下面的命令创建一个使用 istio-system1 命名空间的 Yaml 文件：

cat istio.yaml | sed s/istio-system/istio-system1/g > istio-system1.yaml

Istio Yaml 文件包含了 Istio 控制面的部署细节，包含组成控制面的 Pod（Mixer、Pilot、Ingress 以及 CA）。部署这两个控制面 Yaml 文件：

kubectl apply -f @install/kubernetes/istio.yaml@
kubectl apply -f @install/kubernetes/istio-system1.yaml@

会在两个命名空间生成两个 Istio 控制面

$ kubectl get pods --all-namespaces
NAMESPACE       NAME                                       READY     STATUS    RESTARTS   AGE
istio-system    istio-ca-ffbb75c6f-98w6x                   1/1       Running   0          15d
istio-system    istio-ingress-68d65fc5c6-dnvfl             1/1       Running   0          15d
istio-system    istio-mixer-5b9f8dffb5-8875r               3/3       Running   0          15d
istio-system    istio-pilot-678fc976c8-b8tv6               2/2       Running   0          15d
istio-system1   istio-ca-5f496fdbcd-lqhlk                  1/1       Running   0          15d
istio-system1   istio-ingress-68d65fc5c6-2vldg             1/1       Running   0          15d
istio-system1   istio-mixer-7d4f7b9968-66z44               3/3       Running   0          15d
istio-system1   istio-pilot-5bb6b7669c-779vb               2/2       Running   0          15d

如果需要 Istio Sidecar 注入组件以及遥测组件，也需要根据租户的命名空间定义，修改所需的 Yaml 文件。

需要由集群管理员、而不是租户自己的管理员来加载这两组 Yaml 文件。另外，要把租户管理员的操作权限限制在各自的命名空间内，还需要额外的 RBAC 配置。

区分通用资源和命名空间资源

Istio 仓库中的清单文件中会创建两种资源，一种是能够被所有 Istio 控制面访问的通用资源，另一种是每个控制平面一份的专属资源。上面所说的在 Yaml 文件中替换 istio-system 命名空间的方法自然是很简单的，更好的一种方法就是把 Yaml 文件拆分为两块，一块是所有租户共享的通用部分；另一块就是租户自有的部分。根据 CRD 资源定义（Custom Resource Definitions）中的说法，角色和角色绑定资源需要从 Istio 文件中进行剥离。另外，清单文件中提供的角色和角色绑定的定义可能不适合多租户环境，还需要进一步的细化和定制。

Istio 控制面的 Kubernetes RBAC 设置

租户管理员应该被限制在单独的 Istio 命名空间中，要完成这个限制，集群管理员需要创建一个清单，其中至少要包含一个 Role 和 RoleBinding 的定义，类似下面的文件所示。例子中定义了一个租户管理员，命名为 sales-admin，他被限制在命名空间 istio-system 之中。完整的清单中可能要在 Role 中包含更多的 apiGroups 条目，来定义租户管理员的资源访问能力。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: istio-system1
  name: ns-access-for-sales-admin-istio-system1
rules:
- apiGroups: [""] # "" 代表核心 API 资源组
  resources: ["*"]
  verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: access-all-istio-system1
  namespace: istio-system1
subjects:
- kind: User
  name: sales-admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: ns-access-for-sales-admin-istio-system1
  apiGroup: rbac.authorization.k8s.io

关注特定命名空间进行服务发现

除了创建 RBAC 规则来限制租户管理员只能访问指定 Istio 控制平面之外，Istio 清单还需要为 Istio Pilot 指定一个用于应用程序的命名空间，以便生成 xDS 缓存。Pilot 组件提供了命令行参数 --appNamespace, ns-1 可以完成这一任务。ns-1 就是租户用来部署自己应用的命名空间。istio-system1.yaml 中包含的相关代码大致如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: istio-pilot
  namespace: istio-system1
  annotations:
    sidecar.istio.io/inject: "false"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        istio: pilot
    spec:
      serviceAccountName: istio-pilot-service-account
      containers:
      - name: discovery
        image: docker.io/<user ID>/pilot:<tag>
        imagePullPolicy: IfNotPresent
        args: ["discovery", "-v", "2", "--admission-service", "istio-pilot", "--appNamespace", "ns-1"]
        ports:
        - containerPort: 8080
        - containerPort: 443

在特定命名空间中部署租户应用

现在集群管理员已经给租户创建了命名空间（istio-system1），并且对 Istio Pilot 的服务发现进行了配置，要求它关注应用的命名空间（ns-1），创建应用的 Yaml 文件，将其部署到租户的专属命名空间中：

apiVersion: v1
kind: Namespace
metadata:
  name: ns-1

然后把每个资源的命名空间都指定到 ns-1，例如：

apiVersion: v1
kind: Service
metadata:
  name: details
  labels:
    app: details
  namespace: ns-1

虽然没有展示出来，但是应用的命名空间也应该有 RBAC 设置，用来对特定资源进行访问控制。集群管理员和租户管理员都有权完成这种 RBAC 限制。

在多租户环境中使用 `istioctl`

定义路由规则或者目标策略时，要确认 istioctl 命令是针对专有的 Istio 控制面所在的命名空间运行的。另外规则自身的定义也要限制在租户的命名空间里，这样才能保证规则在租户自己的网格中生效。-i 选项用来在 Istio 控制面所属的命名空间中创建（get 和 describe 也一样）规则。-n 参数会限制规则的所在范围是租户的网格，取值就是租户应用所在的命名空间。如果 Yaml 文件中的资源已经指定了范围，-n 参数会被跳过。

例如下面的命令会创建到 istio-system1 命名空间的路由规则：

istioctl –i istio-system1 create -n ns-1 -f route_rule_v2.yaml

用下面的命令可以查看：

$ istioctl -i istio-system1 -n ns-1 get routerule
NAME                  KIND                                  NAMESPACE
details-Default       RouteRule.v1alpha2.config.istio.io    ns-1
productpage-default   RouteRule.v1alpha2.config.istio.io    ns-1
ratings-default       RouteRule.v1alpha2.config.istio.io    ns-1
reviews-default       RouteRule.v1alpha2.config.istio.io    ns-1

Multiple Istio control planes 中讲述了更多多租户环境下命名空间的相关问题。

测试结果

根据前文的介绍，一个集群管理员能够创建一个受限于 RBAC 和命名空间的环境，租户管理员能在其中进行部署。

完成部署后，租户管理员就可以访问指定的 Istio 控制平面的 Pod 了。

$ kubectl get pods -n istio-system
NAME                                      READY     STATUS    RESTARTS   AGE
grafana-78d649479f-8pqk9                  1/1       Running   0          1d
istio-ca-ffbb75c6f-98w6x                  1/1       Running   0          1d
istio-ingress-68d65fc5c6-dnvfl            1/1       Running   0          1d
istio-mixer-5b9f8dffb5-8875r              3/3       Running   0          1d
istio-pilot-678fc976c8-b8tv6              2/2       Running   0          1d
istio-sidecar-injector-7587bd559d-5tgk6   1/1       Running   0          1d
prometheus-cf8456855-hdcq7                1/1       Running   0          1d
servicegraph-75ff8f7c95-wcjs7             1/1       Running   0          1d

然而无法访问全部命名空间的 Pod：

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list pods at the cluster scope

访问其他租户的命名空间也是不可以的：

$ kubectl get pods -n istio-system1
Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list pods in the namespace "istio-system1"

租户管理员能够在租户指定的应用命名空间中进行应用部署。例如可以修改一下 Bookinfo 的 Yaml 然后部署到租户的命名空间 ns-0 中，然后租户管理员就可以在这一命名空间中列出 Pod 了：

$ kubectl get pods -n ns-0
NAME                              READY     STATUS    RESTARTS   AGE
details-v1-64b86cd49-b7rkr        2/2       Running   0          1d
productpage-v1-84f77f8747-rf2mt   2/2       Running   0          1d
ratings-v1-5f46655b57-5b4c5       2/2       Running   0          1d
reviews-v1-ff6bdb95b-pm5lb        2/2       Running   0          1d
reviews-v2-5799558d68-b989t       2/2       Running   0          1d
reviews-v3-58ff7d665b-lw5j9       2/2       Running   0          1d

同样也是不能访问其他租户的应用程序命名空间：

$ kubectl get pods -n ns-1
Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list pods in the namespace "ns-1"

如果部署了遥测组件, 例如 prometheus（限制在 Istio 的 namespace），其中获得的统计结果展示的也只是租户应用命名空间的私有数据。

结语

上面的一些尝试表明 Istio 有足够的能力和安全性，符合少量多租户的用例需求。另外也很明显的，Istio 和 Kubernetes 无法提供足够的能力和安全性来满足其他的用例，尤其是在租户之间要求完全的安全性和隔离的要求的用例。如果容器技术例如 Kubernetes 能够提供更好的安全模型以及隔离能力，我们才能进一步的增强这方面的支持，Istio 的支持并不是很重要。

问题

一个租户的 CA(Certificate Authority) 和 Mixer 的 Pod 中产生的 Log 包含了另一个租户的控制面的 info 信息。

其他多租户模型的挑战

还有其他值得考虑的多租户部署模型：

一个网格中运行多个应用程序，每个租户一个应用。集群管理员能控制和监控网格范围内的所有应用，租户管理员只能控制一个特定应用。
单独的 Istio 控制平面控制多个网格，每个租户一个网格。集群管理员控制和监控整个 Istio 控制面以及所有网格，租户管理员只能控制特定的网格。
一个云环境（集群控制），多个 Kubernetes 控制面（租户控制）

这些选项，有的需要改写代码才能支持，有的无法满足用户要求。

目前的 Istio 能力不适合第一种方案，这是因为其 RBAC 能力无法覆盖这种租户操作。另外在当前的网格模型中，Istio 的配置信息需要传递给 Envoy 代理服务器，多个租户在同一网格内共存的做法非常不安全。

再看看第二个方式，目前的 Istio 假设每个 Istio 控制面对应一个网格。要支持这种模型需要大量改写。这种情况需要更好的对资源的范围限制进行调整，同时根据命名空间进行安全限制，此外还需要调整 Istio 的 RBAC 模型。这种模式未来可能会支持，但目前来说是不可能的。

第三个方式对多数案例都是不合适的，毕竟多数集群管理员倾向于将同一个 Kubernetes 控制面作为 PaaS 提供给他们的租户。

未来

很明显，单一 Istio 控制面控制多个网格可能是下一个功能。还有可能就是在同一个网格中支持多个租户，并提供某种程度的隔离和安全保障。要完成这样的能力，就需要像 Kubernetes 中对命名空间的额操作那样，在一个单独的控制平面中进行分区，社区中发出了这篇文档来定义其他的用例，以及要支持这些用例所需要的 Istio 功能。

参考

视频：Kubernetes 多租户支持 Multi-Tenancy Support & Security Modeling with RBAC and Namespaces, 以及幻灯片.
Kubecon 讨论，关于对”协同软性多租户“的支持 Building for Trust: How to Secure Your Kubernetes.
Kubernetes RBAC 文档以及命名空间文档.
Kubecon 幻灯片 Multi-tenancy Deep Dive.
Google 文档 Multi-tenancy models for Kubernetes. (需要授权)
Cloud Foundry 提出的文档：Multi-cloud and Multi-tenancy
Istio Auto Multi-Tenancy 101

Istio 安全设置笔记

Mon, 11 Jun 2018 00:05:25 +0800

Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。

Istio 的安全功能主要分为三个部分的实现：

双向 TLS 支持。
基于黑白名单的访问控制。
基于角色的访问控制。
JWT 认证支持。

首先回顾一下 Istio 网格中的服务通信过程：

利用自动或者手工注入，把 Envoy Proxy 注入到每个服务 Pod 中，用 Sidecar 的方式运行。
Pod 初始化过程里，使用 iptables 劫持所在 Pod 的出入流量。
服务间的通信，从原来的直接通信，转换为现在的 Envoy 之间通信，Envoy 在这里同时作为客户端和服务端负载均衡组件。
Envoy 的工作过程中，可能会和 Mixer、Pilot 以及 Citadel 等组件发生互动。

双向 TLS 支持

双向 TLS 支持主要针对的是通信方面，把明文传输的服务通信，通过转换为 Envoy 之间的加密通信。这一安全设置较为基础，可以在全局、Namespace 或者单个服务的范围内生效。

这一功能主要通过两个 Istio CRD 对象来完成：

Policy

例如 Basic Authentication Policy 中的一个样例，用于给单个服务设置 mtls：

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "example-2"
spec:
  targets:
  - name: httpbin
  peers:
  - mtls:

其中 target 是可选项，如果去掉的话，作用域将扩展到整个 Namespace。

DestinationRule

同样的一个例子里面的目标规则如下：

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "example-2"
spec:
  host: httpbin.bar.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE
    portLevelSettings:
    - port:
        number: 1234
      tls:
        mode: ISTIO_MUTUAL

这个也很容易理解，这一规则用于指派对该地址的访问方式：

tls.mode = DISABLE，这个服务缺省是不开启 tls 支持的，如果取值 ISTIO_MUTUAL，则代表这个地址（服务）的所有端口都开启 TLS。
port...ISTIO_MUTUAL，只针对这一个端口启用 mTLS 支持。

创建 Policy 之后，Citadel 会生成证书文件，并传递给 Envoy，我们可以在 Envoy 容器（kube-proxy）的 /etc/certs/ 目录中看到这几个 *.pem 文件。如果使用 openssl x509 -text -noout 查看 cert-chain.pem 的证书内容，会看到 spiffe 编码的 ServiceAccount 内容来作为 SAN：

 X509v3 Subject Alternative Name:
            URI:spiffe://cluster.local/ns/default/sa/default

规则生效之后，原有的服务间调用是没有差异的，但是如果在网格之外，就必须 https，结合上面谈到的证书来访问目标服务才能完成访问。

另外这里也提供了外部 CA 的支持，可以使用已有的证书体系来替换网格内的自签发体系。

基于黑白名单的访问控制

黑名单

下面的例子来自官方，禁止 Reviews 的 v3 版本访问 Ratings 服务。

首先使用 denier 适配器定义一个拒绝响应

apiVersion: "config.istio.io/v1alpha2"
kind: denier
metadata:
  name: denyreviewsv3handler
spec:
  status:
    code: 7
    message: Not allowed

这里不需要额外属性输入，因此采用了 checknothing 模板：

apiVersion: "config.istio.io/v1alpha2"
kind: checknothing
metadata:
  name: denyreviewsv3request
spec:

最后使用 rule 对象把这两者联系起来，并配合一个表达式来使之生效：

apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: denyreviewsv3
spec:
  match: destination.labels["app"] == "ratings" && source.labels["app"]=="reviews" && source.labels["version"] == "v3"
  actions:
  - handler: denyreviewsv3handler.denier
    instances: [ denyreviewsv3request.checknothing ]

白名单

官方案例设置了一个允许 v2 和 v3 版本访问 ratings 服务的白名单。

白名单适配器要使用的是 listchecker，提供了一个允许访问的数组。

apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
  name: whitelist
spec:
  # providerUrl: 可以从外部 URL 获取列表内容
  overrides: ["v1", "v2"]  # 静态列表
  blacklist: false

需要使用一个模板将 Pod 标签转换为 listchecker 的版本列表。

apiVersion: config.istio.io/v1alpha2
kind: listentry
metadata:
  name: appversion
spec:
  value: source.labels["version"]

最后使用 Rule 进行连接：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: checkversion
spec:
  match: destination.labels["app"] == "ratings"
  actions:
  - handler: whitelist.listchecker
    instances:
    - appversion.listentry

注意：如果开启了 mTLS，可以使用 source.user == "cluster.local/ns/default/sa/bookinfo-productpage" 的形式来匹配 ServiceAccount。

RBAC

Helm 安装时，需要设置 global.rbacEnabled: true。

RBAC 提供较细粒度的访问控制。另外其中所使用的 ServiceRole 和 ServiceRoleBinding 也更直观、更加易于管理。

例如来自官方 Task 的 ServiceRole 定义，这个角色允许对指定服务进行只读访问：

apiVersion: "config.istio.io/v1alpha2"
kind: ServiceRole
metadata:
  name: productpage-viewer
  namespace: default
spec:
  rules:
  - services: ["productpage.default.svc.cluster.local"]
    methods: ["GET"]

如果在 Namespace 级别进行设置，则可以这样：

...
  rules:
  - services: ["*"]
    methods: ["GET"]
    constraints:
    - key: "app"
      values: ["productpage"]
...

和 Kubernetes 的 Rolebinding 类似，把用户和角色绑定起来，才能最后生效。

例如：

  - user: alice@yahoo.com

或者

  - properties:
      service: "reviews"
      namespace: "abc"

subject 的内容，同样属于 Adapter 模型的实现范围，因此其可选项目仍然是由 Template 的输入产生的。具体样例可以参考 bookinfo 的 rbac 样板

JWT 认证

没有外部认证的需求，因此就先不理了 lol。

参考链接：

安全任务：https://istio.io/docs/tasks/security
Istio RBAC 参考：https://istio.io/docs/reference/config/istio.rbac.v1alpha1/
Istio Adapters 参考：https://istio.io/docs/reference/config/policy-and-telemetry/adapters/
Bookinfo 示例：https://github.com/istio/istio/blob/release-0.8/samples/bookinfo/kube/

在 Istio 中使用 Opentracing Baggage 进行传播和路由

Fri, 08 Jun 2018 12:25:23 +0800

原文：Istio Routing using OpenTracing Baggage/Distributed Context Propagation

作者：Pavol Loffay

现代服务网格架构提供了很多的新功能，基础设施相关的依赖部分被逐步从代码中移除，极大的降低了编码工作量。除此之外，这一架构的智能路由功能还把金丝雀发布以及类似功能大大的简化了。

接下来的内容会探讨一下，Istio 路由规则是如何使用 Opentracing Baggage 的。

想像一个场景，这个场景中我们需要通过 User-Agent Header 来鉴别 Safari 用户，并把它们重定向到服务的一个特定版本去。这是一个典型的金丝雀场景：新版本发布时，首先开放给一部分用户。然而很明显只有第一个服务能够接收到 User-Agent 头，如果路由规则中涉及到调用关系图中位置较低（靠后）的服务，就不得不把这个 Header 信息传播给所有途中经过的服务。这是一个分布式上下文传播的典型用例，很多跟踪系统都有这个功能。我们接下来会看看 Jaeger 的 OpenTracing 实现。

Baggage 条目是字符串组成的键值对，和 Span/SpanContext 互相关联，在一个 Trace 的范围内，会在所有的下游 Span 中进行传播。

如果你的网格中使用的是 OpenTracing，那么就已经有这个功能了；如果不是，那就有点不幸了：需要通过其他的跟踪 Header 来传递 User-Agent 值了，这样就需要修途经的所有服务。

Istio 缺省使用的 B3 传播是没有提供 Baggage 头的。但是可以用 Brave（Zipkin 的 Java 客户端）来配置 Baggage 支持。一般会使用 baggage-key:value 的格式。Jaeger 实现了一个 B3 解码器，也用同样的格式来处理 Baggage。可以在这里查看 B3 Baggage 实现的进度。

Demo

可以在当前的活动 Span 中这样设置 Baggage：

tracer.activeSpan().setBaggageItem("user-agent", userAgent);

这必须在第一个服务中完成。最后一个需要完成的任务就是定义一个识别 Baggage Header 的路由。下面的路由定义会查看请求是否包含了带有 user-agent:Safari 条目的 Baggage，如果有，就进行转发：

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: recommendation-safari
spec:
  destination:
    namespace: tutorial
    name: recommendation
  precedence: 2
  match:
    request:
      headers:
        baggage-user-agent:
          regex: ".*Safari.*"  
  route:
  - labels:
      version: v2

如果是新版本的 Istio（0.8.0 以后）：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-safari
spec:
  hosts:
  - recommendation
  http:
  - match:
    - headers:
        baggage-user-agent:
          regex: ".*Safari.*"
    route:
     - destination:
        host: recommendation
        subset: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: recommendation-destination
spec:
  host: recommendation
  subsets:
  - name: v2
    labels:
      version: v2

现在所有的配置都已经完成，Safari 用户会被重定向到推荐的 v2 服务。

下面的视频进行了使用 OpenTracing Baggage 进行路由的演示，参见 Redhat 的 Istio Tutorial

Service Mesh 安全：用 Istio 应对攻击

Thu, 07 Jun 2018 10:10:21 +0800

原文：Service Mesh Security: Addressing Attack Vectors with Istio

作者： Zach Jory

把单体应用拆分为微服务之后，会得到不少好处，例如稳定性的提高、持续运行时间的增长以及更好的故障隔离等。然而把大应用拆分为小服务的过程中，也会引入一个风险就是——可能的受攻击面积变大了。从前单体应用中通过函数调用完成的通信，现在都要通过网络完成。提高安全性从而避免这个问题带来的安全影响，是微服务之路上必须要着重考虑的问题。

Aspen Mesh 的基础是一个开源软件：Istio，他的关键能力之一就是为微服务提供安全性和策略控制方面的支持。Istio 为 Service Mesh 增加了很多安全特性，但是这并不是说微服务的安全工作就结束了。网络安全策略也是需要着重考虑的问题（推荐阅读：In the land of microservices, the network is the king(maker)），结合网络策略，可以检测和应对针对服务网格基础设施的攻击，从而解决各种安全威胁。

后面的内容将会看看 Istio 所能够解决的问题，其中包含边缘通信的流量控制、网格内通信加密以及 7 层策略控制等。

边缘通信安全

针对不当进入网格的流量，Istio 加入了一个用来进行监控和防范的安全层。Istio 以 Ingress Controller 的形式和 Kubernetes 进行了集成，并完成了 Ingress 的负载均衡任务。用户可以用 Ingress Rule 的方式加入安全控制。可以通过监控来了解进入网格的流量，并通过路由规则来管理非法的边缘通信。

要保证只有认证用户通过，Istio 的 RBAC（基于角色的访问控制）提供了有弹性的、可定制的访问控制，这种能力在网格内提供了 namespace、service 以及服务方法一级的控制能力。RBAC 引擎监控和跟进 RBAC 策略的变更，在运行时根据 RBAC 策略，根据请求的上下文对请求进行鉴权，最后返回鉴权结果。

通信加密

边缘通信的安全是个好的开始，但是如果有恶意份子突破了边缘之后，Istio 还为服务之间的通信提供了双向 TLS 认证能力。网格能够对请求和响应进行自动的加密和解密，开发人员就无需在此投入精力了。这个功能还通过对连接的优先复用，减少了连接过程中的运算消耗。

除了客户端和服务器之间的认证和鉴权能力之外，还让用户能够理解和管理服务间的通信和加密。Istio 把证书和密钥自动分发给服务，代理使用这些输入来给流量进行加密（提供双向 TLS），并周期性的进行证书轮转，从而降低证书暴露造成的威胁。可以利用 TLS 来确认 Istio 中的通信双方的服务实例都是合法的，从而防止中间人攻击。

Istio 使用 Citadel 来进行密钥管理和认证控制，简化了 TLS 过程。他让用户能够保护流量，同时给每个服务提供基于身份的验证和授权功能。

策略控制和执行

Istio 给用户在应用级执行策略的能力。对于服务路由、重试、断路以及安全来说，在这一层进行控制是非常恰当的。Istio 为用户提供了黑白名单功能来来对服务进行准入的控制。

Istio Mixer 可以把扩展集成进系统，用户用标准化的表达式语言来来声明网络以及服务行为方面的约束策略。这样做的好处是，可以用通用 API 在服务边缘来缓存策略的决策结果，如果下游的策略系统出现故障，网络还能保持运行。

Istio 解决了一些微服务特定的关键问题。例如只允许被批准的服务间通信，加密通信防止通信过程中的入侵，执行应用范围内的策略等。当然还有很多其他方式可以实现这些能力，Mesh 的好处在于将这些能力融会贯通，让用户使用一致的稳定的方式来完成这些任务。

Aspen Mesh 中正在做一些新的功能，在 Istio 中为用户提供更好的安全能力。近期我们会在博客上发点东西，所以请关注 Aspen Mesh 博客。

Conduit 0.4.2 发布

Tue, 05 Jun 2018 10:04:16 +0800

Conduit 0.4.2 是生产就绪之路上的重要一步。这个版本为代理服务器的长期运行做出了很多修复和提高，并提供了更多的遥测功能。同时也为未来的双向 TLS 版本打好了基础。

生产就绪
- 代理服务器会丢弃 10 分钟未更新的指标，以防长期运行过程中造成的额外的内存增长。
- 新增了一个约束，限制一个节点能够路由的服务数量，缺省为 100。这样在代理服务器长期运行的时候，可以在容量到达上限的时候，丢弃闲置最久的客户端，从而达到节约资源的目的。
- 代理服务器现在能够正确的处理 HTTP/2 请求的取消。
- 修复连接错误时候的请求处理。
- 正确处理 DNS 的 TTL。
- conduit inject 现在可以处理 statefulset 对象了。
遥测
- 新版本的 conduit stat 现在支持所有的 Kubernetes 资源，能够展示一个命名空间内所有对象的流量统计。
- Conduit Web UI 提供了命名空间概述的展示。
- 修复了 Tap 功能的一个 Bug，这个 Bug 让代理服务器无法同时响应多个 Tap 请求。
- 修复了故障状态下，无法报告某些 TCP 流的问题。
- 加入了首字节响应时间的指标。
内部
- 环境配置加入了对友好的时间格式的支持（例如 10s）。
- 控制面使用 Kubernetes 1.10.2 客户端。
- 更丰富的 Debug 日志，包含了 Socket 和 Stream 的元数据。
- 为 TLS 支持对代理做出大量改进。

非常感谢 @carllhw、@kichristensen 和 @sfroment 做出的贡献。

从 0.4.1 升级

从 0.4.1 升级时，建议首先升级控制面，然后再升级注入。

Istio 0.8 的 Helm Chart 解析

Mon, 04 Jun 2018 09:39:10 +0800

儿童节期间，拖拉了一个多月的 Istio 0.8 正式发布了，这可能是 Istio 1.0 之前的最后一个 LTS 版本，意义重大。

新版本中，原来的 Kubernetes 安装文件 install/kubernetes/istio.yaml，变成了 install/kubernetes/istio-demo.yaml，是的，你没看错，这个 LTS 的安装文件名字叫 demo。查看了一下文档，大概察觉到不靠谱的 Istio 发布组的意图了：这个项目的组件相对比较复杂，原有的一些选项是靠 ConfigMap 以及 istioctl 分别调整的，现在通过重新设计的 Helm Chart，安装选项用 values.yml 或者 helm 命令行的方式来进行集中管理了。下面就由看看 Istio 的 Helm Chart 的安装部署及其结构。

使用 Helm 安装 Istio

安装包内的 Helm 目录中包含了 Istio 的 Chart，官方提供了两种方法：

用 Helm 生成 istio.yaml，然后自行安装。
用 Tiller 直接安装。

很明显，两种方法并没有什么本质区别。例如第一个命令：

helm template install/kubernetes/helm/istio \
    --name istio --namespace  \
    istio-system > $HOME/istio.yaml

这里说的是使用 install/kubernetes/helm/istio 目录中的 Chart 进行渲染，生成的内容保存到 $HOME/istio.yaml 文件之中。而第二个命令

helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

只是设置了 Chart 中的一个变量 sidecarInjectorWebhook.enabled 为 False。从而禁止自动注入属性生效。

我们照猫画虎，看看命令二的结果提交到 Kubernetes 中会发生什么事情。

helm template install/kubernetes/helm/istio --name istio \
--namespace istio-system --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

kubectl create namespace istio-system
kubectl create -f $HOME/istio.yaml

根据不同的网络情况，可能需要几分钟的等待，最后会看到这些 Pod 在运行：

istio-citadel-ff5696f6f-h4rdz
istio-cleanup-old-ca-rp5p6
istio-egressgateway-58d98d898c-5jnpz
istio-ingress-6fb78f687f-wsl5q
istio-ingressgateway-6bc7c7c4bc-hhrh7
istio-mixer-post-install-d2kl5
istio-pilot-6c5c6b586c-dqv2w
istio-policy-5c7fbb4b9f-xmv6f
istio-statsd-prom-bridge-6dbb7dcc7f-27tx7
istio-telemetry-54b5bf4847-9gpr7
prometheus-586d95b8d9-gb846

过去的 istio-ca 现已更名 istio-citadel。
istio-cleanup-old-ca 是一个 job，用于清理过去的 Istio 遗留下来的 CA 部署（包括 sa、deploy 以及 svc 三个对象）。
istio-mixer-post-install 同样也是一个 job，和上面的 Job 一样，简单的调用 kubectl 创建第三方资源，从而避免了之前的 CDR 需要重复创建的尴尬状况。
egressgateway、ingress 以及 ingressgateway，可以看出边缘部分的变动很大，以后会另行发文。
和从前不同，缺省已经打开了监控界面。

Helm Chart 的安装配置

下面的配置项目，都可以使用 helm 的 --set key=value 来设置，可以重复使用，用来设置多个值。

选项	说明	缺省值
global.hub	绝大部分镜像所在的镜像库地址	`docker.io/istionightly`
global.tag	Istio 使用的绝大部分镜像的 Tag	`circleci-nightly`
global.proxy.image	指定 Proxy 的镜像名称	`proxyv2`
global.imagePullPolicy	镜像拉取策略	`IfNotPresent`
global.controlPlaneSecurityEnabled	控制面是否启动 mTLS	`false`
global.mtls.enabled	服务间是否缺省启用 mTLS	`false`
global.mtls.mtlsExcludedServices	禁用 mTLS 的 FQDN 列表	`- kubernetes.default.svc.cluster.local`
global.rbacEnabled	是否创建 RBAC 规则	`true`
global.refreshInterval	Mesh 发现间隔	`10s`
global.arch.amd64	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
global.arch.s390x	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
global.arch.ppc64le	amd64 架构中的调度策略，0：never；1: least preferred；2：no preference；3：most preferred	`2`
galley.enabled	是否安装 Galley 用于进行服务端的配置验证，需要 1.9 版本以上的 Kubernetes	`false`

上面的内容来自官方文档，其实这是不符合实际情况的（Istio 用户的日常）。在 install/kubernetes/helm/istio/values.yaml 中，包含这一发行版本中的所有的缺省值。可以直接修改或者新建 values.yaml，并在 helm 命令行使用 -f my-values.yaml 参数来生成自行定制的 istio.yaml

解读 Istio Helm Chart 中的模块

打开 Istio 的 Chart 之后，发现其中并没有任何组件的内容，只有两个 Configmap 对象的模板。其安装主体再次很非主流的通过依赖 Chart 的方式实现了完全的模块化。因此这个 Chart 的主体，实际上是 requirements.yaml，打开这个文件，会看到规规矩矩的列出很多模块，例如：

  - name: sidecarInjectorWebhook
    version: 0.8.0
    # repository: file://../sidecarInjectorWebhook
    condition: sidecarInjectorWebhook.enabled

这表明在 sidecarInjectorWebhook 取值为 enabled 的时候，就渲染这一模板。因此这里可以看做是模块的启用停用的控制点。这里列出的模块包括：

模块	描述
egressgateway	外发流量网关
galley	在 K8S 服务端验证 Istio 的 CRD 资源的合法性
grafana	Dashboard
ingress	Ingress Controller
ingressgateway	Ingress Gateway
mixer	Mixer
pilot	Pilot
prometheus	Prometheus
security	安全相关内容
servicegraph	调用关系图
sidecarInjectorWebhook	自动注入
tracing	Zipkin Jeager 的跟踪服务

下面逐一做一下简要说明

egressgateway

外发通信的网关。

他的设置保存在 values.yaml 的 egressgateway 一节中（都是保存在同名分支下，后面不再重复）。部署内容包括：

Deployment 和 Service：一个 proxy。
HPA
RBAC 相关内容

可定制项目包括：

服务端口和类型
HPA 实例数量上下限
资源限制

galley

之前的 istio 版本中，只能通过 istioctl 验证 Istio 相关 CRD 的有效性，这个模块提供一个在服务端验证 CRD 的方法，他的部署内容包含：

Deployement 和 Service。
RBAC 相关
用于 CRD 校验的 ValidatingWebhookConfiguration 对象。

校验目标包含 Pilot（例如 destinationpolicies 和 routerules）和 Mixer（例如 memquotas 和 prometheuses）两类 CRD。

grafana

一个带有 Istio 定制 Dashboard 的 Grafana 封装。

实际上将其镜像中的 Dashboard 复制出来就可以在其他 Grafana 实例上运行了。

定制内容的 grafana.ingress.* 中包含 Ingress 的配置，用于外网访问。

ingress

Istio 的 Ingress Controller

具体部署内容和 egresscontroller 基本一致。

ingressgateway

0.8.0 新增功能，为 Ingress 通信提供 Istio rules/destination 等特性。

部署内容和 ingress 类似。

mixer

Mixer 负责的是遥测和前置检查，他的 Chart 相对比较复杂，部署内容包括：

和前面的版本不同，Mixer 的部署分成了两个部分，分别是 Policy 和 Telemetry 两个 Deployment 对象。
Service 也同样分成两个，其中 telemetry service 多了一个 prometheus 端口
crds.yaml 中包含了 mixer 所支持的所有 crd 定义（例如 memquotas 和 prometheuses）。
create-custom-resources-job.yaml 中包含了用于创建 crd 的 Job 对象。

pilot

Pilot 承上启下，负责服务发现和向 Proxy 下发配置。除了常规的 Deployment 和 Service 之外，还包含了 crds.yaml，用于声明 CRD 资源类型（例如 destinationpolicies 和 routerules）。

prometheus

这个组件跟前面的 Grafana 类似，也是一个预定义的镜像。这个模板中的 Configmap 就是 Prometheus 的抓取配置，可以直接用到其他的 Prometheus 实例之中。

security

旧版本中的 Istio-ca

Security 部分的部署内容包括：

RBAC
Job：使用 kubectl 清理旧版本 istio-ca 实例。
Deployment，原 CA。
Service：开放两个端口，分别服务于 http 和 gRPC。

servicegraph

Service Graph 支持，和 Grafana 基本一致。

sidecarInjectorWebhook

这一部分的功能是自动为 K8S 对象注入 Envoy。主要包含：

Deployment 和 Service
RBAC 相关
一个 MutatingWebhookConfiguration 对象，会监听 Pod 的创建事件，用于自动注入。

tracing

Jeager 的跟踪支持，总体情况跟 Prometheus 和 Grafana 等监控组件类似，配置项和暴露服务方面稍有区别：

配置中包含 Jaeger 的环境变量的控制。
开启 jaeger 开关，会启用 Jaeger 的几个服务端口。

Conduit 0.4.0：流量都去哪了？

Sat, 21 Apr 2018 18:49:25 +0800

原文：Conduit 0.4.0: Where’s my traffic?

本周早些时候我们发布了 Conduit v0.4.0，这一版本在基于 Prometheus 的遥测系统方面，有了很大进步；同时还给微服务的除错提供了新的工具。

安装后的一分钟里，Conduit 给每个 Kubernetes 部署都提供了一个预配置的 Grafana Dashboard。这些 Dashboard 不只是成功率、请求量以及每服务延迟等常见指标，他还将每个指标按照依赖关系进行了分解。这样你就可以在不修改应用的情况下，轻松地回答“这个服务的流量是从哪里来的？”或者 “Foo 调用 Bar 的成功率如何”之类的问题了。

我的流量呢？

在一个微服务形态的应用中，运行中的服务之间的依赖关系是很重要的问题。每服务成功率固然重要，流入服务的请求来自何处同样是不可忽视的问题，更不必说依赖服务的故障情况了。通常这些问题都是最难回答的，但是现在我们有了 Conduit 的帮助，就有机会对这些问题进行简化了。

为了达成这一目标，0.4.0 中我们把 Conduit 的遥测系统中指标的获取改为拉取方式来实现。这一过程中我们还把 Conduit 的 Rust 代理进行了改进，他的指标中描述了所有请求的源、目的以及健康状况。拉取方式获取指标，降低了代理的复杂度，更加贴近 Prometheus 的生态情况。

这样，Conduit 的遥测系统现在非常稳定。能深入到 Kubernetes 中任何两个 Deployment、Pod 或者命名空间之间的请求频率、成功率以及延迟等指标。还可以使用 Prometheus 进行各种查询。当然了，我们还把所有的这些集成到了 CLI 工具中，微服务中的 “TOP” 命令，想过么？

动手环节

我们现在来运行一个简单的例子（要看完整的安装介绍，请参考 Conduit 起步指南）。

首先安装 Conduit CLI：

curl https://run.conduit.io/install | sh

然后在 Kubernetes 中安装 Conduit：

conduit install | kubectl apply -f -

最后，安装 emojivoto 演示应用，并且将其加入 Conduit Mesh：

curl https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml | conduit inject - | kubectl apply -f -

演示应用中包含了一个 vote-bot 服务，不断地在产生流量。这个基于 AI 的机器人在为他最喜欢的表情进行投票，他会变得越来越精明。所以为了安全起见，我们建议你不要让他长期运行。

让我们看看如何用 Conduit 在演示应用中获取流量走向：

先看看 Web 服务（确切的说是 Web Deployment）在做什么：

$ conduit stat -n emojivoto deployment web
NAME  MESHED  SUCCESS     RPS    LATENCY_P50  LATENCY_P95  LATENCY_P99
web      1/1   90.00%  2.0rps            2ms          4ms          9ms

voting 服务只有一个调用者，就是 web 服务。所以通过跟踪 Web 的依赖项，我们有了第一个需要监测的目标：voting 服务在被 web 服务调用的时候，有 83% 的成功率，这样我们就可以看看日志、跟踪或进行其他深入观察。

这只是 Conduit 众多功能中的一个例子。如果想要进一步探索，可以看看所有命名空间的成功率；各个命名空间以及每个 Deployment 调用某一命名空间的成功率；甚至是 Conduit 组件自身的成功率。

在 https://youtu.be/R5UDKgX72tg 还有我们录制的一个关于 Conduit 0.4 的视频。

下一步

我们的未来版本，会把指标和遥测能力扩展到其他的 Kubernetes 对象，例如 Pod 和 RS。另外我们还会把 conduit tap 命令也应用到这些对象上，让 stat 和 tap 完美配合。我们可能还会逐步为 Conduit 加入更多命令，来增强 Conduit 的遥测能力，敬请期待！

Conduit v0.2.0 发布

Thu, 01 Feb 2018 18:27:52 +0800

原文：Announcing Conduit support for HTTP/1.x and TCP

里程碑版本，这次发布中新增了对 HTTP/1.x 和 TCP 支持，这样就可以为绝大多数运行在 Kubernetes 上的应用提供支持了。

数据面
- Conduit 现在为包括 HTTP/1.x 和 HTTP/2 在内的所有 TCP 流量提供透明代理。
控制台界面
- 强化了 tap 命令的错误处理能力。
- tap 也提供了对 HTTP/1.x 的支持。
Dashboard
- 界面进行了小幅更新。
- 可以在 Dashboard 边栏搜索 Deployment。

预告

Conduit 将会为绝大多数协议提供自动支持，然而使用 WebSockets、HTTP 隧道/代理或者 MySQL、SMTP 等协议，需要一些额外配置，文档（注 1）中会有详细说明。
Conduit 还不支持外部 DNS。这一缺憾将在未来版本提供支持。
目前 Conduit 的遥测管线无法扩展到某些节点，后续版本会解决这个问题。
Conduit 还是 Alpha 阶段，请提交 Issue 或 PR 来支持我们（注 2）！

引用：

https://conduit.io/adding-your-service/#protocol-support
https://github.com/runconduit/conduit/issues/new

Conduit 登场

Wed, 06 Dec 2017 09:46:58 +0800

原文：Introducing Conduit

今天我们要介绍 Conduit，面向 Kubernetes 的新的开源 Service Mesh。

Conduit 横空出世，目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面，用 Go 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。更重要的是，Conduit 将会完全吸收过去 18 个月中，我们在 Linkerd 的生产级 Service Mesh 中积累沉淀的真实经验。

为什么要做一个 Conduit？Linkerd 是世界上最多生产级部署的 Service Mesh。这一产品创造了 “Service Mesh” 这一词汇，在软件基础设施中成功的开辟了新的领域，为遍及全球的企业客户（例如 Salesforce、Paypal、Expedia、AOL 以及 Monzo）承载了数以万亿计的请求。这一段时间里，我们和客户以及用户们甘苦与共——我们一起开会，设计交叉路线图，凌晨三点起床救火。开源的基础设施和现实世界的对撞中，我们学到了弥足珍贵的经验和教训。

这中间有个突出的问题就是，Linkerd 的部署模型太重了。虽然 Linkerd 的各个组件，例如 Finagle、Netty、Scala 以及 JVM，都是被广泛采用千锤百炼的，有了这些组件的帮助，在有足够 CPU 和内存支持的情况下，Linkerd 能够达到非常高的负载能力；然而设计过程中鲜有考虑在有限的资源情况下，基于 sidecar 模式的 Kubernetes 部署方式。所以今年年初，我们自问：有了 18 个月的生产级 Service Mesh 的经验，如果要做出一个功能完备又可以在低资源环境下运行的 Service Mesh，我们会怎么做？

答案就是 Conduit。和 Linkerd 类似，Conduit 是让微服务安全可靠的下一代 Service Mesh。他能透明的管理服务之间的通信，自动提供可测性、可靠性、安全性和弹性的支持。还是跟 Linkerd 相仿，他的数据平面是在应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器。然而和 Linkerd 不同的是，Conduit 的设计更加倾向于 Kubernetes 中的低资源部署。

Conduit 为什么伟大（hhhhh）：

轻量高速：Conduit 代理只需要不到 10 MB 实际内存（RSS），p99 延迟在分毫秒以内。
安全：Rust 的内存使用相当安全，同时还缺省使用了 TLS，Conduit 的安全性与生俱来。
最小化：Conduit 的特性集被设计为尽量的最小化和可编排，便于使用 gRPC 插件进行定制。
易用性：内置有聚合的服务指标，强大的客户端工具（想想看，微服务界的 tcpdump），Conduit 为运维人员提供了新的强大的工具来对付生产环境的微服务。

过去半年中我们一直在努力的构建 Conduit。我们聘请了 Phil、Carl、Sean 以及 Brain 这样的高手；向 Tokio 和 Tower 这样的核心技术投资，让 Conduit 又快又安全。最重要的是，我们决心用 Conduit 解决在 Linkerd 社区遇到的实际问题。

Linkerd 怎么办？

简单说说，Linkerd 是世界上最广泛在生产环境进行使用的 Service Mesh，他会长期存在，我们会持续的进行开发、管理并提供商业支持；我们会保证我们的 Linkerd 用户的幸福感。

Conduit 不是 Linkerd 2.0。Conduit 面向的是非常特定的环境 —— Kubernetes，而不准备像 Linkerd 一样做出众多的集成支持。我们的大量用户在使用 ECS、Consul、Mesos、ZooKeeper、Nomad、Rancher 或者混合的多环境系统，Linkerd 是目前的最好选择，我们会持续投入进行改善。

现在开始！

我们刚刚发布了 Conduit 0.1。来跳坑吧！目前这是个 Alpha 版本，所以理直气壮的仅提供 HTTP/2 的支持（是的，HTTP/1.1 都不支持）。我们希望我们的早期用户能够尽早接触 Conduit，并从中获得反馈。

接下来的几个月中，我们会积极工作，推进 Conduit 的生产化进程，预计来年初面世的 0.2 中，会加入 HTTP/1.1 和 TCP 的支持（路线图）。这一产品的进展和目标会非常公开。最后，我们还会提供 Conduit 的商业支持，如果有兴趣的话可以联系我们。

想要了解更多？可以订阅我们的发布通知邮件列表，加入 Linkerd 的 Slack 频道，或者 Follow @runconduit。

Conduit 是基于 Apache 2.0 协议的开源软件。

istio 三日谈之二路由规则

Fri, 28 Jul 2017 17:35:28 +0800

路由控制是 istio 的最常用功能了，经过前面的准备，我们已经基本可以进行这些内容的尝试了。

注意下面的路由规则都忽略了对来源的过滤，会显得比较呆板或者说没用，但是在加入过滤条件之后，就完全不可同日而语了。具体的过滤规则的写法可以参考官方文档或者 istio 中的 bookinfo 实例。

创建 frontend-v2

为了展示路由分配的能力，我们首先创建一个名为frontend-v2的Deployment，这个deploy跟之前的 v1 共享同一个 PVC，也就是共享同一套页面。利用环境变量来控制输出。

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: frontend-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: frontend
        version: "2"
    spec:
      containers:
      - name: php
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
        env:
        - name: "SERVICE_VERSION"
          value: "2"
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1

同前面的 v1 一样，这个Deployment也需要使用istioctl kube-inject进行注入，最后使用kubectl apply -f 运行。

流量分配

首先创建如下路由规则

default.yaml

type: route-rule
name: frontend-default
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: "2"
    weight: 100

destination：必须是服务的 fqdn
precedence：整数，优先级，越大越先
route：数组
- tag：Pod 的标签选择器。
- weigh: 整数，权重，分配到当前路由的比率。

创建之后，使用istioctl create -f default.yaml，创建这一规则。接下来我们使用kubectl exec -it进入 tool pod 进行测试：

$ curl svc-frontend/index.php

-----------------------------
From: frontend-797054967-r12m5
Version: 1

返回内容表明这一服务调用的是最初的 v1 版本的 frontend。

接下来修改 default.yaml 的version "1"为version "2"，然后用istioctl replace -f default.yaml更新路由规则。再次验证：

$ curl svc-frontend/index.php

-----------------------------
From: frontend-v2-90739004-xpmrn
Version: 2

这里可以看到，这一响应来自于 v2 版本的 Pod，并且返回的版本号也是 2。

然后我们再次修改路由规则，测试一下路由分配：

type: route-rule
name: frontend-default
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: "2"
    weight: 10
  - tags:
      version: "1"
    weight: 90

根据上面的路由规则，对 svc-frontend 这一服务的访问，应该有 10% 流量分给版本 2，其余的 90% 分配给了版本 1。我们在 tool pod 中使用如下脚本测试这一分配：

#!/bin/bash
for i in {1..100}
do
  curl -s svc-frontend/index.php | grep Version
done

执行效果：

$  ./curl.batch.sh  | grep 2 | wc -l
10

可以看到，完全符合之前我们的路由设置。

超时策略

为了保障服务质量，我们有时会要求对某些服务的返回时间进行限制

前面提到，我们生成了一个delay.php，用于进行延时测试，文件内容如下：

<?php
header("Content-type: text/plain");
sleep(4);
echo "\n-----------------------------\n";
echo "\nFrom: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

正常执行time curl -s svc-frontend/delay.php，会返回如下结果：

-----------------------------
From: frontend-797054967-r12m5
Version: 1

real    0m4.025s
user    0m0.005s
sys     0m0.004s

我们在这里加入一个策略，两秒超时：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpReqTimeout:
    simpleTimeout:
      timeout: 2s

再次测试，则会返回超时的结果：

upstream request timeout
real    0m2.015s
user    0m0.006s
sys     0m0.003s

重试策略

在服务超时的时候，我们可能会希望请求自动重试。

这一测试要求保留前面的超时策略，以便形成失败结果：

策略文件如下：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpReqRetries:
    simpleRetry:
      attempts: 3
      perTryTimeout: 2s

这里表示每次尝试的超时时间是两秒，重试三次。使用 curl 测试：

$ time curl -s svc-frontend/delay.php
upstream request timeout
real    0m8.136s
user    0m0.005s
sys     0m0.006s

时间为 8 秒，相当于四次超时的时间。

Rewrite

和反向代理的情况类似，有时我们需要对进入服务的 URL 进行重写，下面的路由策略会将 /front 替换为 / 进行访问：

type: route-rule
name: front-timeout
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  match:
    httpHeaders:
      uri:
        prefix: "/front/"
  rewrite:
    uri: "/"
  route:
  - tags:
      version: "1"

注意这里对uri的操作，是使用 rewrite 中的 uri 替换 match 中的 uri，二者的对应关系是强制的。

在 tool 里面进行测试访问：

$ curl http://svc-frontend/front/index.php
-----------------------------

From: frontend-797054967-r12m5
Version: 1

故障注入

微服务测试过程中，能够自动生成一些错误，无疑是个很有帮助的事情。目前 istio 支持两种故障的模拟：时延和中断

时延

下面的规则会为每个对该服务的请求都生成 7 秒的时延：

type: route-rule
name: fdelay
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpFault:
    delay:
      percent: 100
      fixedDelay: 7s

percent: 产生时延的比例
fixedDelay: 时间

使用 curl 验证，可以看到的确多出了 7 秒的处理时间。

$ time curl -s http://svc-frontend/index.php
-----------------------------

From: frontend-797054967-r12m5
Version: 1

real    0m7.028s
user    0m0.007s
sys     0m0.003s

中断

这一功能可以模拟服务中断的情景，下面的 yaml 定义了该服务 100% 会返回 403 错误。

type: route-rule
name: fdelay
spec:
  destination: svc-frontend.default.svc.cluster.local
  precedence: 9
  route:
  - tags:
      version: "1"
  httpFault:
    abort:
      percent: 100
      httpStatus: 403

curl 的验证结果如下：

$  curl -v svc-frontend/error.php
* Connected to svc-frontend (10.100.186.68) port 80 (#0)
> GET /error.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: svc-frontend
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< date: Fri, 28 Jul 2017 01:27:52 GMT
* Server envoy is not blacklisted
< server: envoy
< content-length: 0
<
* Connection #0 to host svc-frontend left intact

istio 三日谈之一，环境准备

Fri, 28 Jul 2017 07:00:12 +0800

笔者尝试在一个准生产环境下，利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇，将一些主要的坑和环境准备工作。

内容较多，因此无法写成手把手教程，希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个：

istio/mixer:0.1.6
pilot:0.1.6
proxy_debug:0.1.6
istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题，官方在源码中提供了很方便的工具，用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件：

./updateVersion.sh \
	-p 10.211.55.86:5000/istio,0.1.6 \
	-c 10.211.55.86:5000/istio,0.1.6 \
	-x 10.211.55.86:5000/istio,0.1.6

这一脚本在源码的 install 目录下。

Kubernetes 环境

这里我们使用的集群大概情况是：

1.7.1 版本的 Kubernetes
开启了 RBAC
预备使用的命名空间为：default
PVC 自动供给
无互联网连接
具有自己的私库

启动 istio

RBAC 相关

首先，install 目录中提供的 rbac 文件授权范围不足，所以需要手工编辑istio-rbac-beta.yaml，把其中的几个 RoleBinding，改为 ClusterRoleBinding。

kubectl create \
	-f istio-rbac-beta.yaml

另外缺省的 ClusterRole 中缺乏对 Namespace 的权限，新版本已经修正，目前版本仍需添加：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: istio-pilot
rules:
- apiGroups: ["istio.io"]
  resources: ["istioconfigs", "istioconfigs.istio.io"]
  verbs: ["*"]
- apiGroups: ["extensions"]
  resources: ["thirdpartyresources", "thirdpartyresources.extensions", "ingresses", "ingresses/status"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["configmaps", "endpoints", "pods", "services"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces", "nodes", "secrets"]
  verbs: ["get", "list", "watch"]

启动 istio 组件

kubectl create \
	-f istio.yaml \

创建 PVC

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: frontend-v1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

准备工作负载

这里我们使用官方的 PHP + Apache 镜像作为工作负载来进行下面的测试，例如我们准备好的 YAML 如下：

Deployment：

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: frontend
  labels:
    name: frontend
    version: "1"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: frontend
        version: "1"
    spec:
      containers:
      - name: php
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
        env:
        - name: "SERVICE_VERSION"
          value: "1"      
     	volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1

服务定义：

kind: Service
apiVersion: v1
metadata:
  name: svc-frontend
  labels:
    name: frontend
    version: "1"
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32010  
  selector:
    name: frontend

在 Web 目录中我们随便做了个index.php，用来展示当前所在 Pod 和环境变量中的服务版本号，备用。

Tips：一般这类测试，我都懒得重新做一个 Docker 镜像，一般是另外用一个 Pod 挂载同一个 PVC，直接编辑页面文件，或者使用kubectl cp命令进行拷贝。

index.php

<?php
header("Content-type: text/plain");
echo "From: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

delay.php


<?php
header("Content-type: text/plain");
sleep(4);
echo "\n-----------------------------\n";
echo "\nFrom: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

运行成功后，访问该服务的 nodePort，会看到相应的输出内容。

istio 的注入

首先用kubectl delete -f删除上文的服务和 Deployment。

上面为了测试方便，给 Service 使用了 NodePort 类型，这里我们去掉这一服务的 NodePort，用 ClusterIP 的形式运行：

spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: frontend

接下来进行注入操作

istioctl kube-inject -f frontend-v1.yaml > frontend-v1-istio.yaml

观察注入操作会发现，其中多了一个 Sidecar Container（下面的 Image 节内容已经被我修改为本地私库）：

    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    image: 10.211.55.86:5000/istio/proxy_debug:0.1.6
    imagePullPolicy: Always
    name: proxy
    resources: {}
    securityContext:
      runAsUser: 1337

另外还在pod.beta.kubernetes.io/init-containers注解中进行了初始化：

[{
  "args": ["-p", "15001", "-u", "1337"],
  "image": "10.211.55.86:5000/istio/init:0.1",
  "imagePullPolicy": "Always",
  "name": "init",
  "securityContext": {
    "capabilities": {
      "add": ["NET_ADMIN"]
    }
  }
}, {
  "args": ["-c", "sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%t && ulimit -c unlimited"],
  "command": ["/bin/sh"],
  "image": "10.211.55.86:5000/alpine",
  "imagePullPolicy": "Always",
  "name": "enable-core-dump",
  "securityContext": {
    "privileged": true
  }
}]

可以看到上面一共涉及三个镜像：

docker.io/istio/proxy_debug:0.1
docker.io/istio/init:0.1
alpine

经过一番折腾：

原有 YAML
注入，生成新的 YAML
替换新 YAML 中的镜像地址

就把原有的容器应用封装成新的 istio 支持的微服务了。

准备测试素材

另外我们需要准备一个工具服务，用于在 shell 中进行测试：

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: tool
  labels:
    name: tool
    version: "1"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: tool
        version: "1"
    spec:
      containers:
      - name: tool
        image: 10.211.55.86:5000/php:7.1.7-apache
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: wwwroot
          mountPath: /var/www/html
      volumes:
      - name: wwwroot
        persistentVolumeClaim:
          claimName: frontend-v1
---
kind: Service
apiVersion: v1
metadata:
  name: tool
  labels:
    name: tool
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: tool

同样的，这里也需要执行istioctl kube-inject进行注入，运行之后，就得到一个运行于集群内部的 Linux Shell，istio 中的路由策略经常是客户端和服务器协同完成的，因此上客户和服务器的 Deployment 都需要进行注入操作。

Linkerd + Namerd，实现 Kubernetes 集群的灰度发布

Tue, 14 Feb 2017 06:42:02 +0800

主要内容源于 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ，砍掉了 Jenkins 等附加部分，更换了更加易于理解的示例应用，以保证主干突出。

Kubernetes 所提供的 rolling-update 功能提供了一种渐进式的更新过程，然而其滚动过程并不容易控制，对于灰度发布的需要来说，仍稍显不足，这里介绍一种利用 Linkerd 方案进行流量切换的思路。

官网介绍：linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications。

本文从实际操作入手，上线两个版本的简单应用，利用这一组合完成流量的切换和测试过程。

测试目标

同时上线两个版本的应用。两个应用均可工作，利用不同输出进行区分。
动态调整分配给两个版本的流量。
利用 CURL 进行流量分配的测试。

准备工作

这里利用一个 1.2 以上版本的 Kubernetes 集群进行演示：

API Server / Registry：10.211.55.62
Node：10.211.66.63

另外因某些原因，需要有能力获取 Dockerhub 的镜像。

例子程序很简单，用一个 PHP 文件显示环境变量中的内容：

<?php
echo getenv("VAR_LABEL");

Docker file 继承自 dustise/lamp:latest，文件内容如下：

FROM dustise/lamp
COPY index.php /web/codebase

利用 Docker build 创建镜像，这里命名为 lamp:gray，备用。

创建工作负载

做一个简单的 yaml 文件来加载蓝绿两组应用，名字、环境变量和端口三个位置需要更改：

---
kind: ReplicationController
apiVersion: v1
metadata:
  name: green
# 此处省略若干
        env:
        - name: VAR_LABEL
          value: 'green'
---
kind: Service
apiVersion: v1

# 此处省略若干

  type: NodePort
  ports:
  - protocol: TCP
    nodePort: 32001
    port: 80
    targetPort: 80
    name: http
  selector:
    name: green

利用 kubectl create -f green.yaml （以及 blue.yaml ）之后，可以利用 curl 或者浏览器检查运行情况，如果正常，两个端口的访问应该分别会返回 green 和 blue ，这里的端口命名很重要，这一名称会被后面的规则引用到。

注意，这里 NodePort 并非必须，仅为测试方便。

运行 Namerd

此处 yaml 主要来自于官网 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/namerd.yml 为适应本地环境，将原有 Loadbalancer 类型的服务改为 NodePort

略微做一下讲解。

整个 yaml 由四部分组成：

ThirdPartyResource

这部分被用于做 Namerd 的存储后端。

Configmap

作为 Namerd 的配置，其中定义了这样几个内容（详情可参见 https://linkerd.io/config/0.8.5/namerd/index.html#introduction）：

管理端口 9990
storage：存储定义，通过 8001 端口同 Kube Api Server 通信，完成在 ThrdPartyResource 中的访问（8001 端口由 kubectl proxy 指令开通）
namer：定义服务发现能力由 Kubernetes 提供。
interface 部分则是定义了两种支持协议。其中 HTTP Controller 可以接收 namerctl 的控制指令。

RC

这部分不新鲜，除了 namerd 之外，还利用 kubectl proxy 提供通信端口给 namerd，颇有蛇足之嫌。正确的打开方式应该是直接和 Kube API Server 进行通信。

Service

这里注意服务类型的变更（ LoadBalancer -> NodePort ），需要暴露 4180 和 9990 两个端口，分别作为控制端口和界面端口。

利用 kubectl 启用之后，就可以在指定的端口查看管理界面了。此时的管理界面没有做任何配置，因此比较单薄。

添加规则

下面来安装 namerd 的控制工具，namerctl

go get -u github.com/buoyantio/namerctl
go install github.com/buoyantio/namerctl

接下来创建一条规则：

/host=>/#/io.l5d.k8s/default/http;
/http/*/*/*=>8*/host/blue&2*/host/green;

这段代码表示该服务同时连接 blue 和 green 两个后端服务，按照 ⁸⁰⁄₂₀ 的比例进行流量分配。

namerctl dtab create [file name] --base-url，这里 base-url 取值就是我们给 namerd 设置的 Nodeport。

接下来就能够看到管理界面上显示出新的规则了。

运行 Linkerd

这里同样基于官方的 https://raw.githubusercontent.com/BuoyantIO/linkerd-examples/master/k8s-daemonset/k8s/linkerd-namerd.yml

需要注意的是，官方给出的 yaml 文件中有一处 bug，使得这个 yaml 只能在缺省的 namespace 和 domain suffix 下运行。需要纠正对 namerd 的访问方式，删除 Namerd 后面的 default.svc.cloud.local 即可。

同样的，他的服务端口和管理端口都应该改用 NodePort 方式进行暴露。

运行后，同样可以看到 Linkerd 的管理界面。

测试

下面可以做一个简单的测试，来证明流量分配的有效性：

for ((i=1;i<=300;i++)); do curl -s "http://10.211.55.63:30001/";echo ""; done | grep -i blue| wc -l

可以看到，随着循环次数的增加，其结果越来越趋近于 ⁸⁰⁄₂₀ 的分配比例。

接下来，我们修改上面的 dtab 为如下内容：

/host=>/#/io.l5d.k8s/default/http;
/http/*/*/*=>8*/host/blue&8*/host/green;

重新进行测试，就可以看到，流量分配已经发生了变化。另外，还可以在 Linkerd 的管理界面上看到网络流量的变化情况。

结语

这一组合基本能够满足流量渐变分配的功能需求，同时也有如豆瓣这样的大厂使用，但他的 dtab 还是个相对复杂的东西，如果在生产上进行使用，还是需要进一步的学习。

另外，按照其文档中所陈述的功能范围内容来看，仅用来做流量分配还是颇有点大材小用的味道，从个人来说，我倾向于一些更轻量级的解决方法。

servicemesh | 伪架构师

在 Linkerd2 中进行流量拆分

Envoy 和 Istio 的 6.18

Envoy Mobile

Istio 1.2

参考链接

SMI：推动服务网格社区举步前行

最小公分母

语义差别不大

无处不在的 Envoy proxy

基于已有实现

厂商主导的 SMI

胜者为王

推动服务网格社区举步前行

意外：Servicemesh Interface（SMI）

设计重点

规范内容

流量规范

访问控制

流量拆分

流量监控

参与厂商

读后感

参考

Istio 和 Linkerd 的性能测试分析

动机

目标

场景

指标

RPS、用户体验和 CO

性能

资源消耗

测试环境

集群

应用

运行测试和统计的稳健性

重现性

测试的运行和观测

服务网格的版本

Istio：stock 和 tuned

Linkerd

测试服务网格的上限

测试运行时间

第一次测试：500 RPS，30 分钟

延迟分布

内存和 CPU

第二次测试：600 RPS，30 分钟

延迟分布

结论

下一步

后记

参考资料

服务网格——模式还是技术？

Service Mesh 是什么？从何而来？

服务网格是一种模式，而非技术

传统 API 管理方案瞠目其后

结语

Istio 大入门 - Ingress

基本概念

准备工作

环境准备

域名准备

工作负载

目标规则定义

在外网开放服务

将一个域名服务升级为 tls

所有域名都升级为 tls

补充

涉及链接

代码

Python 脚本

Dockerfile

Kubernetes 工作负载

Consul vs Istio

Conduit 0.5 发布 —— 以及 R.I.P. Conduit

HTTP Egress 流量的监控和访问策略管理

用例

相关任务

开始之前

配置监控和访问策略

在多租户环境中使用 `istioctl`

istio 三日谈之二路由规则