Service Mesh深度思考 | DreamMesh抛砖引玉(3)-艰难的过渡

ServiceMesh小数 发表了文章 • 0 个评论 • 473 次浏览 • 2018-04-11 15:10 • 来自相关话题

作者:

       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。

        博客链接:https://skyao.io



在上一篇中,我们讨论的话题是:如果没有做好Cloud Native的准备,该怎么上Service Mesh。本章继续讨论,假定Cloud Native已经准备好,看看Service Mesh的道路是否就一帆风顺。



问题所在


如何从非Service Mesh体系过渡到Service Mesh?


我们需要考虑的是:

即使一切准备就绪,对于一个有存量应用的系统而言,绝无可能将所有应用都一起改为Service Mesh,然后一夜之间上线。


必然会有一个中间过渡状态,一部分应用开始搬迁到 Service Mesh,一部分还停留在原有体系。


那么,在过渡阶段,Service Mesh 内的服务和 Service Mesh 外的服务在通讯时会遇到哪些问题?



场景分析


我们来看一个具体的例子,有三个服务,调用关系分别是 A->B->C,然后在最前面架设 API Gateway。非常典型的微服务体系:






这里可以是 spring cloud/dubbo/motan 等各种侵入式微服务架构,左边的注册中心/registry 的实现也可以有多种,服务间通讯的方式也不尽相同。但是,都不影响我们的讨论。


上图可以看到,在标准的微服务框架中,处理这样一个请求,调用方式是清晰明了的。


如果开始转向 Service Mesh 体系,无论是 Istio/Conduit,都会引入一个新的 K8S 体系。为了充分演示,我们选择将服务B转移到 Service Mesh。调用关系就一下变成复杂:






这里我们引入两个术语(TBD:应该是业界通用术语吧?待确认):


东西向通讯:指微服务间相互调用。

南北向通讯:指外界访问微服务体系,通常是通过API Gateway。


当B被迁移后,B原有的上游调用(A调用B)和下游调用(B调用C),虽然业务语意上依然还是东西向通讯,但是由于跨了体系导致原有的调用方式被打破。只能另想办法,目前看通常的做法都是改走南北向通讯。



影响


而这个改变会带来巨大的工作量:


   1. B的所有上游服务都要修改

原有的标准服务间通讯(通过sdk进行服务发现/负载均衡等)都废弃,需要改为对k8s体系入口如Ingress的调用。然后在Ingress这边也要做好对服务B的配置。

  2. B对所有下游服务的调用方式都要修改


同样,原有的标准服务间通讯都废弃,需要改为对API Gateway的调用。然后在API Gateway这边也要做好对下游服务的配置。


而通讯机制改变带来的工作量不是唯一的问题,还有一个内部服务对外暴露的问题:

在原有体系中,服务B和服务C都是内部服务,完全可以不对外暴露,API Gateway访问的只是服务A;

迁移之后,为了让服务B的上游服务能够访问到服务B,就不得不将服务B暴露出来;

同样,为了让服务B能够访问它的下游服务,就不得不将服务C暴露出来。

原体系中只有服务A对外暴露,现在服务B和服务C也不得不暴露。而对外暴露服务,就意味着必然还会有一堆相关的工作需要完成:

认证

授权

加密

……


而这些都意味着:工作量/复杂度/更多的开发测试上线。






后续影响

随着应用往 Service Mesh 体系的逐渐迁移,我们开始迁移服务C和服务A。


先看服务C迁移到来的变化:







此时服务B到服务C的调用从原来的走 API Gateway 改变为 Service Mesh 体系内的服务间调用。然后 API Gateway 不再需要调用服务C,可以去除和服务C相关的内容。


再看服务A的迁移:








此时服务B不再需要暴露,而服务A的暴露方式发生变化,另外服务A调用服务B的方式也有改变。


我们抛开细节,只看整体:在服务 A/B/C 迁移到 Service Mesh 体系的过程中,服务间调用方式和对外暴露方式的变化,带来了一系列的工作量。而耗费这些工作量的中间环节,在整体迁移完成之后都会消失。换言之,都是迫不得已的临时投入,对最后的系统不产生增益。


直白一点:在过渡阶段的这诸多折腾,只是完成了服务迁移,而不能带来任何收益。这一点,无疑是令人沮丧的。


问题本质

反思一下:为何服务只是体系间迁移一下,就需要增加这么多不带来实际收益的工作量和复杂度?到底我们上面这些折腾是在做什么?

很明显,在这个过程中,我们没有任何业务改动,三个服务的实现也没有发生任何变化。

那么,改变的东西是什么?


是服务间通讯:


迁移过程中,服务A/B/C之间的通讯在业务语意上虽然依然属于东西向的服务间通讯机制,但是在实现上,却不得不临时转为南北向的网关到服务的通讯机制。


这个转变是无奈的,两个体系之间存在以下问题导致无法继续走东西向服务间通讯机制:


1. 没有共同的registry,因此无法相互感知;

2. 没有可以直接连通的网络通道,原有的服务间通讯被迫走公开的API Gateway和Ingress通道;

3. 两个体系的服务间通讯机制也可能不同,导致迁移之后不得不重新实现服务间通讯机制;

4. API Gateway和Ingress对于服务暴露的方式也不尽相同,各种特性如认证/加密/服务路由等方式也很可能完全不同。

这就如同江河中的淡水鱼,如果要随波汇入大海,就必须要能适应海水。


然后我们的问题在于,在过渡阶段,不得不花费大量投入来的完成被两个体系分割的服务间通讯,增加了大量额外的工作。



后记

有没有办法解决这个问题,或者部分减轻工作量,为将来的 Service Mesh 转型做好准备?

后续章节会深入探讨这个话题,给出部分解决方案,也欢迎大家给出意见或者参与讨论。

有兴趣的朋友,请添加小数微信:xiaoshu062,加入service mesh内部讨论群。



讨论和反馈

冉启春:任何两个架构体系的迁移都是痛苦的

于文涛:运维团队负责容器化和k8s,基础架构部负责数据库拆分和分库分表以及底层中间件,业务平台部门参与微服务业务改造,其实路径没有统一的,得看不同团队的执行结果和如何协调了。谁强势先突破可能会有主导权。不过一般的路径是先底层后业务层。


  查看全部
作者:

       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。

        博客链接:https://skyao.io



在上一篇中,我们讨论的话题是:如果没有做好Cloud Native的准备,该怎么上Service Mesh。本章继续讨论,假定Cloud Native已经准备好,看看Service Mesh的道路是否就一帆风顺。



问题所在


如何从非Service Mesh体系过渡到Service Mesh?


我们需要考虑的是:

即使一切准备就绪,对于一个有存量应用的系统而言,绝无可能将所有应用都一起改为Service Mesh,然后一夜之间上线。


必然会有一个中间过渡状态,一部分应用开始搬迁到 Service Mesh,一部分还停留在原有体系。


那么,在过渡阶段,Service Mesh 内的服务和 Service Mesh 外的服务在通讯时会遇到哪些问题?



场景分析


我们来看一个具体的例子,有三个服务,调用关系分别是 A->B->C,然后在最前面架设 API Gateway。非常典型的微服务体系:

1.png


这里可以是 spring cloud/dubbo/motan 等各种侵入式微服务架构,左边的注册中心/registry 的实现也可以有多种,服务间通讯的方式也不尽相同。但是,都不影响我们的讨论。


上图可以看到,在标准的微服务框架中,处理这样一个请求,调用方式是清晰明了的。


如果开始转向 Service Mesh 体系,无论是 Istio/Conduit,都会引入一个新的 K8S 体系。为了充分演示,我们选择将服务B转移到 Service Mesh。调用关系就一下变成复杂:

2.png


这里我们引入两个术语(TBD:应该是业界通用术语吧?待确认):


东西向通讯:指微服务间相互调用。

南北向通讯:指外界访问微服务体系,通常是通过API Gateway。


当B被迁移后,B原有的上游调用(A调用B)和下游调用(B调用C),虽然业务语意上依然还是东西向通讯,但是由于跨了体系导致原有的调用方式被打破。只能另想办法,目前看通常的做法都是改走南北向通讯。



影响


而这个改变会带来巨大的工作量:


   1. B的所有上游服务都要修改

原有的标准服务间通讯(通过sdk进行服务发现/负载均衡等)都废弃,需要改为对k8s体系入口如Ingress的调用。然后在Ingress这边也要做好对服务B的配置。

  2. B对所有下游服务的调用方式都要修改


同样,原有的标准服务间通讯都废弃,需要改为对API Gateway的调用。然后在API Gateway这边也要做好对下游服务的配置。


而通讯机制改变带来的工作量不是唯一的问题,还有一个内部服务对外暴露的问题:

在原有体系中,服务B和服务C都是内部服务,完全可以不对外暴露,API Gateway访问的只是服务A;

迁移之后,为了让服务B的上游服务能够访问到服务B,就不得不将服务B暴露出来;

同样,为了让服务B能够访问它的下游服务,就不得不将服务C暴露出来。

原体系中只有服务A对外暴露,现在服务B和服务C也不得不暴露。而对外暴露服务,就意味着必然还会有一堆相关的工作需要完成:

认证

授权

加密

……


而这些都意味着:工作量/复杂度/更多的开发测试上线。






后续影响

随着应用往 Service Mesh 体系的逐渐迁移,我们开始迁移服务C和服务A。


先看服务C迁移到来的变化:

3.png



此时服务B到服务C的调用从原来的走 API Gateway 改变为 Service Mesh 体系内的服务间调用。然后 API Gateway 不再需要调用服务C,可以去除和服务C相关的内容。


再看服务A的迁移:


4.png



此时服务B不再需要暴露,而服务A的暴露方式发生变化,另外服务A调用服务B的方式也有改变。


我们抛开细节,只看整体:在服务 A/B/C 迁移到 Service Mesh 体系的过程中,服务间调用方式和对外暴露方式的变化,带来了一系列的工作量。而耗费这些工作量的中间环节,在整体迁移完成之后都会消失。换言之,都是迫不得已的临时投入,对最后的系统不产生增益。


直白一点:在过渡阶段的这诸多折腾,只是完成了服务迁移,而不能带来任何收益。这一点,无疑是令人沮丧的。


问题本质

反思一下:为何服务只是体系间迁移一下,就需要增加这么多不带来实际收益的工作量和复杂度?到底我们上面这些折腾是在做什么?

很明显,在这个过程中,我们没有任何业务改动,三个服务的实现也没有发生任何变化。

那么,改变的东西是什么?


是服务间通讯:


迁移过程中,服务A/B/C之间的通讯在业务语意上虽然依然属于东西向的服务间通讯机制,但是在实现上,却不得不临时转为南北向的网关到服务的通讯机制。


这个转变是无奈的,两个体系之间存在以下问题导致无法继续走东西向服务间通讯机制:


1. 没有共同的registry,因此无法相互感知;

2. 没有可以直接连通的网络通道,原有的服务间通讯被迫走公开的API Gateway和Ingress通道;

3. 两个体系的服务间通讯机制也可能不同,导致迁移之后不得不重新实现服务间通讯机制;

4. API Gateway和Ingress对于服务暴露的方式也不尽相同,各种特性如认证/加密/服务路由等方式也很可能完全不同。

这就如同江河中的淡水鱼,如果要随波汇入大海,就必须要能适应海水。


然后我们的问题在于,在过渡阶段,不得不花费大量投入来的完成被两个体系分割的服务间通讯,增加了大量额外的工作。



后记

有没有办法解决这个问题,或者部分减轻工作量,为将来的 Service Mesh 转型做好准备?

后续章节会深入探讨这个话题,给出部分解决方案,也欢迎大家给出意见或者参与讨论。

有兴趣的朋友,请添加小数微信:xiaoshu062,加入service mesh内部讨论群。



讨论和反馈

冉启春:任何两个架构体系的迁移都是痛苦的

于文涛:运维团队负责容器化和k8s,基础架构部负责数据库拆分和分库分表以及底层中间件,业务平台部门参与微服务业务改造,其实路径没有统一的,得看不同团队的执行结果和如何协调了。谁强势先突破可能会有主导权。不过一般的路径是先底层后业务层。


 

envoy的注入是怎么实现的?

回复

Envoy難易之相成也 回复了问题 • 1 人关注 • 1 个回复 • 450 次浏览 • 2018-04-04 17:21 • 来自相关话题

示例说明 | 想要正确使用Istio?这份sidecar说明书必不可少

Istio小数 发表了文章 • 0 个评论 • 653 次浏览 • 2018-04-03 10:49 • 来自相关话题

作者:宋净超(Jimmy Song),Kubernetes、Cloud Native布道者、开源爱好者,个人博客https://jimmysong.io



我们知道 Istio 通过向 Pod 中注入一个 sidecar 容器来将 Pod 纳入到 Istio service mesh 中的,那么这些 sidecar 容器的注入遵循什么样的规范,需要给每个 Pod 增加哪些配置信息才能纳入 Istio service mesh 中呢?这篇文章将给您答案。


本文同时归档到 kubernetes-handbook中(注1),更新请以handbook为准。



Pod Spec 中需满足的条件

为了成为 Service Mesh 中的一部分,kubernetes 集群中的每个 Pod 都必须满足如下条件,这些规范不是由 Istio 自动注入的,而需要 生成 kubernetes 应用部署的 YAML 文件时需要遵守的:
Service 关联:每个 pod 都必须只属于某一个 Kubernetes Service(注2) (当前不支持一个 pod 同时属于多个 service)。命名的端口:Service 的端口必须命名。端口的名字必须遵循如下格式 <protocol>[-<suffix>],可以是 http、http2、 grpc、 mongo、 或者 redis 作为 <protocol> ,这样才能使用 Istio 的路由功能。例如 name: http2-foo 和 name: http 都是有效的端口名称,而 name: http2foo 不是。如果端口的名称是不可识别的前缀或者未命名,那么该端口上的流量就会作为普通的 TCP 流量来处理(除非使用 Protocol: UDP 明确声明使用 UDP 端口)。带有 app label 的 Deployment:我们建议 kubernetes 的Deploymenet 资源的配置文件中为 Pod 明确指定 applabel。每个 Deployment 的配置中都需要有个与其他 Deployment 不同的含有意义的 app label。app label 用于在分布式追踪中添加上下文信息。Mesh 中的每个 pod 里都有一个 Sidecar:最后,Mesh 中的每个 pod 都必须运行与 Istio 兼容的 sidecar。以下部分介绍了将 sidecar 注入到 pod 中的两种方法:使用istioctl 命令行工具手动注入,或者使用 Istio Initializer 自动注入。注意 sidecar 不涉及到流量,因为它们与容器位于同一个 pod 中。



将普通应用添加到 Istio service mesh 中

Istio 官方的示例 Bookinfo(注3)中并没有讲解如何将服务集成 Istio,只给出了 YAML 配置文件,而其中需要注意哪些地方都没有说明,假如我们自己部署的服务如何使用 Istio 呢?现在我们有如下两个普通应用(代码在 GitHub 上),它们都不具备微服务的高级特性,比如限流和熔断等,通过将它们部署到 kubernetes 并使用 Istio 来管理:
k8s-app-monitor-test:用来暴露 json 格式的 metricsk8s-app-monitor-agent:访问上面那个应用暴露的 metrics 并生成监控图


这两个应用的 YAML 配置如下,其中包含了 Istio ingress 配置,并且符合 Istio 对 Pod 的 spec 配置所指定的规范。


k8s-app-monitor-istio-all-in-one.yaml文件


apiVersion: extensions/v1beta1kind: Deploymentmetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-agent  name: k8s-app-monitor-agentspec:

  replicas: 1

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: k8s-app-monitor-agent    spec:

      containers:

      - env:

        - name: SERVICE_NAME          value: k8s-app-monitor-test        image: jimmysong/k8s-app-monitor-agent:749f547        name: monitor-agent        ports:

        - containerPort: 8888

      restartPolicy: Always---apiVersion: v1kind: Servicemetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-agent  name: k8s-app-monitor-agentspec:

  ports:

  - name: "http"

    port: 8888

    targetPort: 8888

  selector:

    app: k8s-app-monitor-agent---apiVersion: extensions/v1beta1kind: Deploymentmetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-test  name: k8s-app-monitor-testspec:

  replicas: 1

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: k8s-app-monitor-test    spec:

      containers:

      - image: jimmysong/k8s-app-monitor-test:9c935dd        name: monitor-test        ports:

        - containerPort: 3000

      restartPolicy: Always---apiVersion: v1kind: Servicemetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-test  name: k8s-app-monitor-testspec:

  ports:

  - name: "http"

    port: 3000

    targetPort: 3000

  selector:

    app: k8s-app-monitor-test---## Istio ingressapiVersion: extensions/v1beta1kind: Ingressmetadata:

  name: k8s-app-monitor-agent-ingress  annotations:

    kubernetes.io/ingress.class: "istio"spec:

  rules:

  - http:

      paths:

      - path: /k8s-app-monitor-agent        backend:

          serviceName: k8s-app-monitor-agent          servicePort: 8888


其中有两点配置需要注意。


Deployment 和 Service 中的 label 名字必须包含 app,zipkin 中的 tracing 需要使用到这个标签才能追踪

Service 中的 ports 配置和必须包含一个名为 http 的 port,这样在 Istio ingress 中才能暴露该服务


注意:该 YAML 文件中 annotations 是因为我们一开始使用 docker-compose 部署在本地开发测试,后来再使用 kompose 将其转换为 kubernetes 可识别的 YAML 文件。

然后执行下面的命令就可以基于以上的 YAML 文件注入 sidecar 配置并部署到 kubernetes 集群中。


kubectl apply -n default -f <(istioctl kube-inject -f manifests/istio/k8s-app-monitor-istio-all-in-one.yaml)


如何在本地启动 kubernetes 集群进行测试可以参考 kubernetes-vagrant-centos-cluster 中的说明(注4)。



Sidecar 注入说明


手动注入需要修改控制器的配置文件,如 deployment。通过修改 deployment 文件中的 pod 模板规范可实现该deployment 下创建的所有 pod 都注入 sidecar。添加/更新/删除 sidecar 需要修改整个 deployment。


自动注入会在 pod 创建的时候注入 sidecar,无需更改控制器资源。Sidecar 可通过以下方式更新:


手动选择删除 pod

系统得进行 deployment 滚动更新


手动或者自动注入都使用同样的模板配置。自动注入会从 istio-system 命名空间下获取 istio-inject 的 ConfigMap。手动注入可以通过本地文件或者 Configmap 。



参考

Installing Istio Sidecar(注5)


注:

1、https://jimmysong.io/kubernetes-handbook/

2、https://kubernetes.io/docs/con ... vice/

3、https://istio.io/docs/guides/bookinfo.html

4、https://github.com/rootsongjc/ ... uster

5、https://istio.io/docs/setup/ku ... .html
  查看全部
作者:宋净超(Jimmy Song),Kubernetes、Cloud Native布道者、开源爱好者,个人博客https://jimmysong.io



我们知道 Istio 通过向 Pod 中注入一个 sidecar 容器来将 Pod 纳入到 Istio service mesh 中的,那么这些 sidecar 容器的注入遵循什么样的规范,需要给每个 Pod 增加哪些配置信息才能纳入 Istio service mesh 中呢?这篇文章将给您答案。


本文同时归档到 kubernetes-handbook中(注1),更新请以handbook为准。



Pod Spec 中需满足的条件

为了成为 Service Mesh 中的一部分,kubernetes 集群中的每个 Pod 都必须满足如下条件,这些规范不是由 Istio 自动注入的,而需要 生成 kubernetes 应用部署的 YAML 文件时需要遵守的:
  1. Service 关联:每个 pod 都必须只属于某一个 Kubernetes Service(注2) (当前不支持一个 pod 同时属于多个 service)。
  2. 命名的端口:Service 的端口必须命名。端口的名字必须遵循如下格式 <protocol>[-<suffix>],可以是 http、http2、 grpc、 mongo、 或者 redis 作为 <protocol> ,这样才能使用 Istio 的路由功能。例如 name: http2-foo 和 name: http 都是有效的端口名称,而 name: http2foo 不是。如果端口的名称是不可识别的前缀或者未命名,那么该端口上的流量就会作为普通的 TCP 流量来处理(除非使用 Protocol: UDP 明确声明使用 UDP 端口)。
  3. 带有 app label 的 Deployment:我们建议 kubernetes 的Deploymenet 资源的配置文件中为 Pod 明确指定 applabel。每个 Deployment 的配置中都需要有个与其他 Deployment 不同的含有意义的 app label。app label 用于在分布式追踪中添加上下文信息。
  4. Mesh 中的每个 pod 里都有一个 Sidecar:最后,Mesh 中的每个 pod 都必须运行与 Istio 兼容的 sidecar。以下部分介绍了将 sidecar 注入到 pod 中的两种方法:使用istioctl 命令行工具手动注入,或者使用 Istio Initializer 自动注入。注意 sidecar 不涉及到流量,因为它们与容器位于同一个 pod 中。




将普通应用添加到 Istio service mesh 中

Istio 官方的示例 Bookinfo(注3)中并没有讲解如何将服务集成 Istio,只给出了 YAML 配置文件,而其中需要注意哪些地方都没有说明,假如我们自己部署的服务如何使用 Istio 呢?现在我们有如下两个普通应用(代码在 GitHub 上),它们都不具备微服务的高级特性,比如限流和熔断等,通过将它们部署到 kubernetes 并使用 Istio 来管理:
  • k8s-app-monitor-test:用来暴露 json 格式的 metrics
  • k8s-app-monitor-agent:访问上面那个应用暴露的 metrics 并生成监控图



这两个应用的 YAML 配置如下,其中包含了 Istio ingress 配置,并且符合 Istio 对 Pod 的 spec 配置所指定的规范。


k8s-app-monitor-istio-all-in-one.yaml文件


apiVersion: extensions/v1beta1kind: Deploymentmetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-agent  name: k8s-app-monitor-agentspec:

  replicas: 1

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: k8s-app-monitor-agent    spec:

      containers:

      - env:

        - name: SERVICE_NAME          value: k8s-app-monitor-test        image: jimmysong/k8s-app-monitor-agent:749f547        name: monitor-agent        ports:

        - containerPort: 8888

      restartPolicy: Always---apiVersion: v1kind: Servicemetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-agent  name: k8s-app-monitor-agentspec:

  ports:

  - name: "http"

    port: 8888

    targetPort: 8888

  selector:

    app: k8s-app-monitor-agent---apiVersion: extensions/v1beta1kind: Deploymentmetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-test  name: k8s-app-monitor-testspec:

  replicas: 1

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: k8s-app-monitor-test    spec:

      containers:

      - image: jimmysong/k8s-app-monitor-test:9c935dd        name: monitor-test        ports:

        - containerPort: 3000

      restartPolicy: Always---apiVersion: v1kind: Servicemetadata:

  annotations:

    kompose.cmd: kompose convert -f docker-compose.yaml    kompose.version: 1.10.0 ()  creationTimestamp: null

  labels:

    app: k8s-app-monitor-test  name: k8s-app-monitor-testspec:

  ports:

  - name: "http"

    port: 3000

    targetPort: 3000

  selector:

    app: k8s-app-monitor-test---## Istio ingressapiVersion: extensions/v1beta1kind: Ingressmetadata:

  name: k8s-app-monitor-agent-ingress  annotations:

    kubernetes.io/ingress.class: "istio"spec:

  rules:

  - http:

      paths:

      - path: /k8s-app-monitor-agent        backend:

          serviceName: k8s-app-monitor-agent          servicePort: 8888


其中有两点配置需要注意。


Deployment 和 Service 中的 label 名字必须包含 app,zipkin 中的 tracing 需要使用到这个标签才能追踪

Service 中的 ports 配置和必须包含一个名为 http 的 port,这样在 Istio ingress 中才能暴露该服务


注意:该 YAML 文件中 annotations 是因为我们一开始使用 docker-compose 部署在本地开发测试,后来再使用 kompose 将其转换为 kubernetes 可识别的 YAML 文件。

然后执行下面的命令就可以基于以上的 YAML 文件注入 sidecar 配置并部署到 kubernetes 集群中。


kubectl apply -n default -f <(istioctl kube-inject -f manifests/istio/k8s-app-monitor-istio-all-in-one.yaml)


如何在本地启动 kubernetes 集群进行测试可以参考 kubernetes-vagrant-centos-cluster 中的说明(注4)。



Sidecar 注入说明


手动注入需要修改控制器的配置文件,如 deployment。通过修改 deployment 文件中的 pod 模板规范可实现该deployment 下创建的所有 pod 都注入 sidecar。添加/更新/删除 sidecar 需要修改整个 deployment。


自动注入会在 pod 创建的时候注入 sidecar,无需更改控制器资源。Sidecar 可通过以下方式更新:


手动选择删除 pod

系统得进行 deployment 滚动更新


手动或者自动注入都使用同样的模板配置。自动注入会从 istio-system 命名空间下获取 istio-inject 的 ConfigMap。手动注入可以通过本地文件或者 Configmap 。



参考

Installing Istio Sidecar(注5)


注:

1、https://jimmysong.io/kubernetes-handbook/

2、https://kubernetes.io/docs/con ... vice/

3、https://istio.io/docs/guides/bookinfo.html

4、https://github.com/rootsongjc/ ... uster

5、https://istio.io/docs/setup/ku ... .html
 

Service Mesh深度思考 | DreamMesh抛砖引玉(2)-CloudNative

ServiceMesh小数 发表了文章 • 0 个评论 • 433 次浏览 • 2018-03-30 10:55 • 来自相关话题

作者:
       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。
        博客链接:https://skyao.io
 
 
 
我对 Service Mesh 的第一个担忧,来自 Cloud Native。
 
 
Are You Ready?
 
作为 Cloud Native 的忠实拥护者,我从不怀疑 Cloud Native 的价值和前景。可以说,微服务/容器这些技术天然就适合走 Cloud Native 的道路。
 
但是,我担心的是:准备上 Service Mesh 的各位,是否都已经做到了 Ready for Cloud Native?
 

 
这真是一个尴尬的问题。
 
现实摆在眼前,根据我最近几个月跑过的企业客户(大大小小接近二十家)的实际情况看,可以说:情况非常不乐观。
 
备注: 这里只讨论普通企业用户,对于技术和管理都比较先进的互联网大公司来说,Cloud Native的普及情况要好很多。
 
这就引出了下面这个问题:
 
如果没有Cloud Native基础,那还能不能用Service Mesh?
 
 
 
发展路径
 
这里有三条发展路径可选:
 
1、先Cloud Native,再Service Mesh
 
理论上说,这是最合理的:先把底层基础设施铺好,再在其上构建上层业务应用。
 
具体说,就是先上云/容器/k8s,应用暂时维持原状。不管是单体应用,还是基于Dubbo/Spring Cloud等侵入式开发框架的微服务应用,先上云再说。更直白一点,上k8s。
 
等待Istio/Conduit成熟之后,再迁移到Service Mesh方案。
 
 
 2、先Service Mesh,再Cloud Native
 
这个方案理论上也是可行的:先用Service Mesh方案完成微服务体系建设,之后再迁移到k8s平台。
 
之所以说理论上没有问题,是指Service Mesh从设计理念上,对底层是不是容器并没有特别要求。无论是容器/虚拟机/物理机,Service Mesh都是可行的。
 
 
3、同时上 Service Mesh 加 Cloud Native
 
通常来说我们不赞成同时进行这两个技术变革,因为涉及到的内容实在太多,集中在一起,指望一口气吃成大胖子,容易被噎住。
 
但是不管怎么样这条路终究还是存在的,而且如果决心够大+愿意投入+高人护航,也不失是一个一次性彻底解决问题的方案,先列在这里。
 
 
 
何去何从
 
路径1和路径2,在讨论该如何选择之前,还有一个问题:就是路径2是不是真的可行?

 
青黄不接的尴尬

我们前面说道路径2理论上是可行的,但是目前的实际情况是真要选择就会发现:难。这要从目前市面上的 Service Mesh 产品谈起,按照我的划分方式,我将目前主流的四个 Service Mesh 产品划分为两代:
第一代 Service Mesh,包括 Linkerd 和 Envoy。
 
这两个产品目前都是 production ready,而且都和平台无关,对物理机/虚拟机/容器都可以支持。
第二代 Service Mesh,包括 Istio 和 Conduit
 
这两个产品目前都还在发展中,暂时都未能达到 production ready。
 
如果要在当前时刻进行 Service Mesh 的技术选型,我们就会发现这样一个尴尬的局面:
Istio 和 Conduit 还没有 production ready,上线不适合,只能继续等待。
 
Linkerd 和 Envoy 倒是可用,但是,在了解 Istio 和 Conduit 之后,又有多少人愿意在现在选择上 Linkerd 和 Envoy?
 
所谓青黄不接,便是如此。
 
在接下来的讨论中,我们假定大家都是在等待 Istio 和 Conduit。
 
我们回到前面的话题,限定 Istio 和 Conduit,如果选择路径2(先 Service Mesh,再 Cloud Native),会如何?
 
 
 
对平台的要求
  
Conduit

首先 Conduit 非常坚定执着的”Say No”了,官网非常清晰的表述:
 
Conduit is a next-generation ultralight service mesh for Kubernetes.
 
私底下和 William (小编注:Buoyant CEO)就此简单聊过,他给出来的回答很委婉也很实在:Conduit 总要从某个地方起步,K8S是目前最好选择。以后可以支持,但是肯定先 K8S 再说。考虑到 Conduit 和 Buoyant 公司的处境,尤其全公司才二十,我们不能要求太多。
 
可以明确的说,短期之内,起码2018年,Conduit 官方不会有对  K8S之外的支持。

 
Istio   

Isito 最早版本是只支持 K8S 的,后来陆续提供了对其他非 K8S 环境的支持,比如 Docker+Consul/Eureka 的方案,还有计划中但是还没有完成的 Cloud Fountry 和 Mesos 集成。
 
对于 VM,Istio 有提供一个 VM 解决方案,具体看见官方文档:
Integrating Virtual Machines集成虚拟机: 中文翻译版本
 
从文档上看是可以支持部分服务在 K8S 之外:
 
TBD: 需要继续调研看 Istio 是否可以在纯粹的  VM环境下运行,即完全脱离 K8S 和容器。
 
 
 
平台要求总结
 
Conduit 和 Istio(还有待最后确认)对容器/K8s/Cloud Native 都有要求,导致目前路径2(先 Service Mesh,再 Cloud Native)几乎没有无法实现,至少在不改动 Conduit 和 Istio 的情况下。
 
这就意味着,只能走路径1(先 Cloud Native,再 Service Mesh),也就回到了最早的问题: 做好了 Cloud Native 的准备吗?
 
 
 
后记
 
需要做一个市场调查,要有足够多的样本:
 
企业客户对微服务和容器,是打算先上容器/K8S再上微服务,还是希望可以直接在虚拟机/物理机上做微服务,后面再迁移到K8S?
 
有兴趣的朋友,添加小数微信:xiaoshu062,加入service mesh微信交流群,一起讨论~
 
 
 
讨论和反馈
 
在这篇博客文章编写前一天晚上,和来自 Google Istio 开发团队的Hu同学有过一次长时间的讨论。
 
在征得同意之后我将讨论内容整理如下。特别鸣谢Hu同学的指点:
 
Hu: 你好,这么晚还在工作?
 
敖小剑:正在整理思路。
 
Hu: 文章写的很好。
 
敖小剑:您客气了,还是你们产品做的好,istio我是报以厚望。
 
Hu:希望不要让大家失望,能够解决一些实际问题。
 
敖小剑:一起努力吧,就算有小的不足,也还是有机会改进的,istio的大方向我是非常认可的。
 
Hu:恩,现在是一个新时代的开始,cloud native是大势所趋,后面我们会看到更多有趣的技术出来。有什么想法和建议,也欢迎在istio的工作组里提。
 
敖小剑:我现在是一边等istio的production ready版本,一边着手准备,为落地可能遇到的问题或者需求预先研究一下。
 
国内可能情况和美国不太一样,目前国内企业,尤其传统形的企业,他们的技术基础非常糟糕,离cloud native差距很远。
 
但是他们又有强烈的意愿上微服务。
 
Hu:对,但这也是机遇。国内的企业软件市场还有很大空间。美国公司喜欢新技术,跟的比较紧。
 
敖小剑:我选择istio这种service mesh方案来推微服务落地,本意是降低微服务普及的门槛。
 
这样普通企业用户才有机会玩转微服务,毕竟这些公司连spring cloud都玩的很吃力。
 
现在的问题是,istio比较强调cloud native,而这些企业用户基本都没有准备好cloud native。
 
Hu:呵呵,我觉得你的想法很好,不过可能有点超前。据我所知,即使在很多互联网大企业, service mesh也没有完全落地。第一步可能还是docker化和普及kubernetes。
 
敖小剑:我刚才还在看如何在非k8s,非docker环境下跑istio。嗯,你的思路是先准备好路,再让istio这辆车上路?我的思路有点倾向于让service mesh这个车在没路的情况下也能跑起来。
 
Hu:我的意思是要看条件,可以把非K8S方案作为一个过渡。最终还是要迁移到kube和云上。
 
敖小剑:嗯,对的,我想增加一个过渡阶段。
 
Hu:都可以的,就看企业的自身条件了。Google这边是提供不同解决方案的,但最终目标还是希望客户迁移到云上。
 
敖小剑:cloud native条件不成熟的情况下,先过渡一下,把应用迁移到非docker条件下的istio,先完成微服务化。
 
两条路,一条先cloud native再service mesh,一条先service mesh再cloud native。
 
Hu:恩,我觉得都是可行的。如果是重IT的公司,建议直接cloudnative。
 
敖小剑:不同企业可能演进的速度和步骤不一样。微服务化更多是业务团队推动,cloud native通常是运维和基础架构团队。
 
Hu:我对国内情况不了解,只是个人看法,呵呵。其实可能最重要的还是普及devops的模式,人的问题解决了,别的都好办。
 
敖小剑:嗯,我个人的感觉是技术导向的互联网公司容易做到cloud native,他们走你说的路线比较合理。但是普通企业用户可能会选择先微服务化。
 
当然这个我还要继续调研和确认,比较我现在接触的样本也不够多。所以,多讨论多沟通,确认好实际需要再说。
 
我这段时间会陆陆续续把想法写出来,然后提交大家讨论。希望你多给意见。
 
Hu:好的。
 
在这篇博客文章发表收集到的讨论和评论反馈:
 
张琦:我们的经验,必定要走你说的路径2,servicemesh甚至要充当从传统应用到Cloudnative之间的桥梁。例如在逐渐微服务化的过程中 用mesh来接入原来的单体应用 然后再一点一点去拆;或者用mesh接入其他协议的遗留应用来做一下协议转换,我记得微博也有这种用法
 
崔秀龙:posta那篇微服务改造的文章还是很可以参考的
 
肖晟:没错,企业随着IT架构的演进,上面提到的遗留应用并不在少数。需要解决协议适配等问题,又不想受限于服务总线类流量中心的瓶颈,mesh是一种理想的解决之道;而想要上mesh,又可能推动其上cloudnative。所以从企业总体来说,这个演变很可能是混合的,不过从单应用来说会是分步的。
 
肖晟:另外在思考的一个问题是,在一个企业IT架构下,由于不同技术标准或安全需求等因素的影响,有没有可能同时存在两套或多套servicemesh。
 
备注: 这个话题后面会有专门的章节
崔秀龙:我觉得是两个必须:必须容器云,必须打SC。
 
宋净超:理想很丰满,现实很骨感啊。
 
崔秀龙:我个人的感觉是有了SM之后,微服务的定义就很清晰了。
 
宋净超:同意。
 
孟樊亮:迁移到k8s,感觉是服务注册/发现/互通只是第一步,后续的治理和运维才是无尽大坑。
 
于文涛:我们公司应该是偏第一种方案,先走容器化,k8s后微服务化。不过微服务和也其实在同时推进。
 
 
 
 
推荐阅读:

Service Mesh深度思考 | DreamMesh抛砖引玉(1)-序
Istio服务网格高级流量镜像,7种模式解决流量镜像难题
使用Istio简化微服务系列三:如何才能做“金丝雀部署”,并通过Istio增加流量?
在Kubernetes平台上,应对不同场景外部流量引入集群,这3种工具改如何选择?
 
 
  查看全部
作者:
       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。
        博客链接:https://skyao.io
 
 
 
我对 Service Mesh 的第一个担忧,来自 Cloud Native
 
 
Are You Ready?
 

作为 Cloud Native 的忠实拥护者,我从不怀疑 Cloud Native 的价值和前景。可以说,微服务/容器这些技术天然就适合走 Cloud Native 的道路。
 
但是,我担心的是:准备上 Service Mesh 的各位,是否都已经做到了 Ready for Cloud Native?
 

 
这真是一个尴尬的问题。
 
现实摆在眼前,根据我最近几个月跑过的企业客户(大大小小接近二十家)的实际情况看,可以说:情况非常不乐观。
 
备注: 这里只讨论普通企业用户,对于技术和管理都比较先进的互联网大公司来说,Cloud Native的普及情况要好很多。
 
这就引出了下面这个问题:
 
如果没有Cloud Native基础,那还能不能用Service Mesh?
 
 
 
发展路径

 
这里有三条发展路径可选:
 
1、先Cloud Native,再Service Mesh
 
理论上说,这是最合理的:先把底层基础设施铺好,再在其上构建上层业务应用。
 
具体说,就是先上云/容器/k8s,应用暂时维持原状。不管是单体应用,还是基于Dubbo/Spring Cloud等侵入式开发框架的微服务应用,先上云再说。更直白一点,上k8s。
 
等待Istio/Conduit成熟之后,再迁移到Service Mesh方案。
 
 
 2、先Service Mesh,再Cloud Native
 
这个方案理论上也是可行的:先用Service Mesh方案完成微服务体系建设,之后再迁移到k8s平台。
 
之所以说理论上没有问题,是指Service Mesh从设计理念上,对底层是不是容器并没有特别要求。无论是容器/虚拟机/物理机,Service Mesh都是可行的。
 
 
3、同时上 Service Mesh 加 Cloud Native
 
通常来说我们不赞成同时进行这两个技术变革,因为涉及到的内容实在太多,集中在一起,指望一口气吃成大胖子,容易被噎住。
 
但是不管怎么样这条路终究还是存在的,而且如果决心够大+愿意投入+高人护航,也不失是一个一次性彻底解决问题的方案,先列在这里。
 
 
 
何去何从

 
路径1和路径2,在讨论该如何选择之前,还有一个问题:就是路径2是不是真的可行?

 
青黄不接的尴尬


我们前面说道路径2理论上是可行的,但是目前的实际情况是真要选择就会发现:难。这要从目前市面上的 Service Mesh 产品谈起,按照我的划分方式,我将目前主流的四个 Service Mesh 产品划分为两代:
  • 第一代 Service Mesh,包括 Linkerd 和 Envoy。

 
这两个产品目前都是 production ready,而且都和平台无关,对物理机/虚拟机/容器都可以支持。
  • 第二代 Service Mesh,包括 Istio 和 Conduit

 
这两个产品目前都还在发展中,暂时都未能达到 production ready。
 
如果要在当前时刻进行 Service Mesh 的技术选型,我们就会发现这样一个尴尬的局面:
  • Istio 和 Conduit 还没有 production ready,上线不适合,只能继续等待。

 
  • Linkerd 和 Envoy 倒是可用,但是,在了解 Istio 和 Conduit 之后,又有多少人愿意在现在选择上 Linkerd 和 Envoy?

 
所谓青黄不接,便是如此。
 
在接下来的讨论中,我们假定大家都是在等待 Istio 和 Conduit。
 
我们回到前面的话题,限定 Istio 和 Conduit,如果选择路径2(先 Service Mesh,再 Cloud Native),会如何?
 
 
 
对平台的要求
  
Conduit

首先 Conduit 非常坚定执着的”Say No”了,官网非常清晰的表述:
 
Conduit is a next-generation ultralight service mesh for Kubernetes.
 
私底下和 William (小编注:Buoyant CEO)就此简单聊过,他给出来的回答很委婉也很实在:Conduit 总要从某个地方起步,K8S是目前最好选择。以后可以支持,但是肯定先 K8S 再说。考虑到 Conduit 和 Buoyant 公司的处境,尤其全公司才二十,我们不能要求太多。
 
可以明确的说,短期之内,起码2018年,Conduit 官方不会有对  K8S之外的支持。

 
Istio   

Isito 最早版本是只支持 K8S 的,后来陆续提供了对其他非 K8S 环境的支持,比如 Docker+Consul/Eureka 的方案,还有计划中但是还没有完成的 Cloud Fountry 和 Mesos 集成。
 
对于 VM,Istio 有提供一个 VM 解决方案,具体看见官方文档:
  • Integrating Virtual Machines
  • 集成虚拟机: 中文翻译版本

 
从文档上看是可以支持部分服务在 K8S 之外:
 
TBD: 需要继续调研看 Istio 是否可以在纯粹的  VM环境下运行,即完全脱离 K8S 和容器。
 
 
 
平台要求总结

 
Conduit 和 Istio(还有待最后确认)对容器/K8s/Cloud Native 都有要求,导致目前路径2(先 Service Mesh,再 Cloud Native)几乎没有无法实现,至少在不改动 Conduit 和 Istio 的情况下。
 
这就意味着,只能走路径1(先 Cloud Native,再 Service Mesh),也就回到了最早的问题: 做好了 Cloud Native 的准备吗?
 
 
 
后记
 
需要做一个市场调查,要有足够多的样本:
 
企业客户对微服务和容器,是打算先上容器/K8S再上微服务,还是希望可以直接在虚拟机/物理机上做微服务,后面再迁移到K8S?
 
有兴趣的朋友,添加小数微信:xiaoshu062,加入service mesh微信交流群,一起讨论~
 
 
 
讨论和反馈
 

在这篇博客文章编写前一天晚上,和来自 Google Istio 开发团队的Hu同学有过一次长时间的讨论。
 
在征得同意之后我将讨论内容整理如下。特别鸣谢Hu同学的指点:
 
Hu: 你好,这么晚还在工作?
 
敖小剑:正在整理思路。
 
Hu: 文章写的很好。
 
敖小剑:您客气了,还是你们产品做的好,istio我是报以厚望。
 
Hu:希望不要让大家失望,能够解决一些实际问题。
 
敖小剑:一起努力吧,就算有小的不足,也还是有机会改进的,istio的大方向我是非常认可的。
 
Hu:恩,现在是一个新时代的开始,cloud native是大势所趋,后面我们会看到更多有趣的技术出来。有什么想法和建议,也欢迎在istio的工作组里提。
 
敖小剑:我现在是一边等istio的production ready版本,一边着手准备,为落地可能遇到的问题或者需求预先研究一下。
 
国内可能情况和美国不太一样,目前国内企业,尤其传统形的企业,他们的技术基础非常糟糕,离cloud native差距很远。
 
但是他们又有强烈的意愿上微服务。
 
Hu:对,但这也是机遇。国内的企业软件市场还有很大空间。美国公司喜欢新技术,跟的比较紧。
 
敖小剑:我选择istio这种service mesh方案来推微服务落地,本意是降低微服务普及的门槛。
 
这样普通企业用户才有机会玩转微服务,毕竟这些公司连spring cloud都玩的很吃力。
 
现在的问题是,istio比较强调cloud native,而这些企业用户基本都没有准备好cloud native。
 
Hu:呵呵,我觉得你的想法很好,不过可能有点超前。据我所知,即使在很多互联网大企业, service mesh也没有完全落地。第一步可能还是docker化和普及kubernetes。
 
敖小剑:我刚才还在看如何在非k8s,非docker环境下跑istio。嗯,你的思路是先准备好路,再让istio这辆车上路?我的思路有点倾向于让service mesh这个车在没路的情况下也能跑起来。
 
Hu:我的意思是要看条件,可以把非K8S方案作为一个过渡。最终还是要迁移到kube和云上。
 
敖小剑:嗯,对的,我想增加一个过渡阶段。
 
Hu:都可以的,就看企业的自身条件了。Google这边是提供不同解决方案的,但最终目标还是希望客户迁移到云上。
 
敖小剑:cloud native条件不成熟的情况下,先过渡一下,把应用迁移到非docker条件下的istio,先完成微服务化。
 
两条路,一条先cloud native再service mesh,一条先service mesh再cloud native。
 
Hu:恩,我觉得都是可行的。如果是重IT的公司,建议直接cloudnative。
 
敖小剑:不同企业可能演进的速度和步骤不一样。微服务化更多是业务团队推动,cloud native通常是运维和基础架构团队。
 
Hu:我对国内情况不了解,只是个人看法,呵呵。其实可能最重要的还是普及devops的模式,人的问题解决了,别的都好办。
 
敖小剑:嗯,我个人的感觉是技术导向的互联网公司容易做到cloud native,他们走你说的路线比较合理。但是普通企业用户可能会选择先微服务化。
 
当然这个我还要继续调研和确认,比较我现在接触的样本也不够多。所以,多讨论多沟通,确认好实际需要再说。
 
我这段时间会陆陆续续把想法写出来,然后提交大家讨论。希望你多给意见。
 
Hu:好的。
 
在这篇博客文章发表收集到的讨论和评论反馈:
 
张琦:我们的经验,必定要走你说的路径2,servicemesh甚至要充当从传统应用到Cloudnative之间的桥梁。例如在逐渐微服务化的过程中 用mesh来接入原来的单体应用 然后再一点一点去拆;或者用mesh接入其他协议的遗留应用来做一下协议转换,我记得微博也有这种用法
 
崔秀龙:posta那篇微服务改造的文章还是很可以参考的
 
肖晟:没错,企业随着IT架构的演进,上面提到的遗留应用并不在少数。需要解决协议适配等问题,又不想受限于服务总线类流量中心的瓶颈,mesh是一种理想的解决之道;而想要上mesh,又可能推动其上cloudnative。所以从企业总体来说,这个演变很可能是混合的,不过从单应用来说会是分步的。
 
肖晟:另外在思考的一个问题是,在一个企业IT架构下,由于不同技术标准或安全需求等因素的影响,有没有可能同时存在两套或多套servicemesh。
 
备注: 这个话题后面会有专门的章节
崔秀龙:我觉得是两个必须:必须容器云,必须打SC。
 
宋净超:理想很丰满,现实很骨感啊。
 
崔秀龙:我个人的感觉是有了SM之后,微服务的定义就很清晰了。
 
宋净超:同意。
 
孟樊亮:迁移到k8s,感觉是服务注册/发现/互通只是第一步,后续的治理和运维才是无尽大坑。
 
于文涛:我们公司应该是偏第一种方案,先走容器化,k8s后微服务化。不过微服务和也其实在同时推进。
 
 
 
 
推荐阅读:

Service Mesh深度思考 | DreamMesh抛砖引玉(1)-序
Istio服务网格高级流量镜像,7种模式解决流量镜像难题
使用Istio简化微服务系列三:如何才能做“金丝雀部署”,并通过Istio增加流量?
在Kubernetes平台上,应对不同场景外部流量引入集群,这3种工具改如何选择?
 
 
 

Kubernetes NodePorts vs LoadBalancers vs Ingress,到底应该什么时候使用?

ServiceMesh小数 发表了文章 • 0 个评论 • 436 次浏览 • 2018-03-29 10:25 • 来自相关话题

作者:Sandeep Dinesh

翻译:狄卫华

原文:Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?

原文链接:https://medium.com/google-clou ... 849e0



最近有人向我了解 NodePorts ,LoadBalancers 和 Ingress 之间的区别是怎么样的。 它们都是将外部流量引入群集的方式,适用的场景却各不相同。 本文接下来我们将介绍它们的工作原理以及适用的相关场景。


注意:文中所述内容适用于 GKE (Google Kubernetes Engine 注1)。 如果你在其他云平台上运行使用步骤略有不同,比如 minikube 或其他相关软件。 我也不打算过多深入技术细节, 如果你有兴趣了解更多,Kubernetes 官方文档(注2)会提供更多的有用资源!



ClusterIP

ClusterIP 服务是 Kubernetes 默认的服务类型。 如果你在集群内部创建一个服务,则在集群内部的其他应用程序可以进行访问,但是不具备集群外部访问的能力。

ClusterIP 服务的 YAML 文件看起来像这样:


apiVersion: v1


kind: Service

metadata:  

  name: my-internal-service

selector:    

  app: my-app

spec:

  type: ClusterIP

  ports:  

  - name: http

    port: 80

    targetPort: 80

    protocol: TCP


如果不能从互联网访问 ClusterIP 服务,我为什么要谈论它呢?事实上,你可以通过 Kubernetes 代理进行访问。








感谢 Ahmet Alp Balkan(注3)提供的图表


启动 Kubernetes 代理:

$ kubectl proxy --port=8080

现在,可以通过 Kubernetes API 通过以下的模式来访问这个服务:


http://localhost:8080/api/v1/p ... t%3B/,


通过这种方式可以使用以下的地址来访问我们上述定义的服务:

http://localhost:8080/api/v1/p ... http/


何时使用这种访问方式?


有以下几种场景,你可以使用 Kubernetes 代理的方式来访问服务:

1. 调试服务或者某些情况下通过笔记本电脑直接连接服务

2. 允许内部的通信,显示内部的仪表盘(dashboards)等

因为此种方式需要作为一个授权用户运行 kubectl,因此不应该用来暴露服务至互联网访问或者用于生产环境。


NodePort

NodePort 服务通过外部访问服务的最基本的方式。顾名思义,NodePort 就是在所有的节点或者虚拟机上开放特定的端口,该端口的流量将被转发到对应的服务。
 





从技术上层面,这不能算是最准确的图表,但我认为它能够直观展示了 NodePort 的工作方式。

NodePort 服务的 YAML 文件看起来像这样:

apiVersion: v1

kind: Service

metadata:  

  name: my-nodeport-service

selector:    

  app: my-app

spec:

  type: NodePort

  ports:  

  - name: http

    port: 80

    targetPort: 80

    nodePort: 30036

    protocol: TCP

从根本上讲,NodePort 方式的服务与 ClusterIP 方式的服务有两个区别。第一,类型是 NodePort,这需要指定一个称作 nodePort 的附加端口,并在所有节点上打开对应的端口。如果我们不具体指定端口,集群会选择一个随机的端口。大多数的情况下,我们都可以让 Kubernetes 帮我们选择合适的端口。正如 thockin(注4) 所描述的那样,有许多相关的注意事项(caveats)关于那些端口可供我们使用。


何时使用这种访问方式?

NodePort 方式有许多缺点:

1. 每个服务占用一个端口
2. 可以使用的  30000-32767 范围端口 (译者注:可以通过api-server启动参数service-node-port-range,指定限制范围,默认为30000-32767)
3. 如果节点/虚拟机IP地址发生更改,需要进行相关处理


由于上述原因,我不建议在生产环境中使用直接暴露服务。 如果运行的服务不要求高可用或者非常关注成本,这种方法则比较适合。 很好的例子就是用于演示或临时使用的程序。



LoadBalancer

LoadBalancer 服务是暴露服务至互联网最标准的方式。在 GKE 上,这将启动一个网络负载均衡器(注5),它会提供一个 IP 地址,以将所有流量转发到服务。






感谢 Ahmet Alp Balkan提供图表

何时使用这种访问方式?这是公开服务的默认的方法。指定的端口上流量都将被转发到对应的服务,不经过过滤和其他路由等操作。这种方式意味着转发几乎任何类型的流量,如HTTP,TCP,UDP,Websockets,gRPC或其他。


这种方式最大的缺点是,负载均衡器公开的每个服务都将获取独立 IP 地址,而我们则必须为每个暴露的服务对应的负载均衡器支付相关费用,这可能会变得非常昂贵!




Ingress

和上述讨论的服务方式不同,Ingress 实际上并不是服务类型中的一种。相反,它位于多个服务的前端充当一个智能路由或者集群的入口点。

你可以使用 Ingress 做很多不同的事情,并且不同类型的 Ingress 控制也具备不同的能力。

GKE 默认的 Ingress 控制器将启动一个 HTTP(S) 的负载均衡器。则将使我们可以基于访问路径和子域名将流量路由到后端服务。例如,你可以将 `foo.yourdomain.com` 下的流量转发到 foo 服务,将`yourdomain.com/bar/` 路径下的流量转发到 bar 服务。







感谢 Ahmet Alp Balkan提供图表


在 GKE 上定义 L7层 HTTP 负载均衡器的 Ingress 对象定义的 YAML 看起来像这样:

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: my-ingress

spec:

  backend:

    serviceName: other

    servicePort: 8080

  rules:

  - host: foo.mydomain.com

    http:

      paths:

      - backend:

          serviceName: foo

          servicePort: 8080

  - host: mydomain.com

    http:

      paths:

      - path: /bar/*

        backend:

          serviceName: bar

          servicePort: 8080


何时使用这种方式?Ingress 方式可能是暴露服务的最强大的方式,但也最复杂。现在有不同类型的 Ingress 控制器,包括 Google 云 负载均衡器(注6), Nginx(注7), Contour(注8), Istio(注9)等。此外,还有 Ingress 控制器的许多插件,比如 cert-manager(注10)可以用来自动为服务提供 SSL 证书。


如果希望在同一个IP地址下暴露多个服务,并且它们都使用相同的 L7 协议(通常是HTTP),则 Ingress 方式最有用。 如果使用本地 GCP 集成,则只需支付一台负载平衡器费用,并且是“智能”性 Ingress ,可以获得许多开箱即用的功能(如SSL,Auth,路由等)。


资源:

Kubernetes:https://medium.com/tag/kubernetes?source=post

Microservices:https://medium.com/tag/microservices?source=post

Services:https://medium.com/tag/services?source=post

Load Balancing:https://medium.com/tag/load-balancing?source=post

Ingress:https://medium.com/tag/ingress?source=post





1、https://cloud.google.com/gke

2、https://kubernetes.io/docs/con ... vice/

3、https://medium.com/@ahmetb

4、(https://medium.com/@thockin)

5、https://cloud.google.com/compu ... work/

6、https://cloud.google.com/kuber ... ancer

7、https://github.com/kubernetes/ingress-nginx

8、https://github.com/heptio/contour

9、https://istio.io/docs/tasks/tr ... .html

10、https://github.com/jetstack/cert-manager
  查看全部
作者:Sandeep Dinesh

翻译:狄卫华

原文:Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?

原文链接:https://medium.com/google-clou ... 849e0



最近有人向我了解 NodePorts ,LoadBalancers 和 Ingress 之间的区别是怎么样的。 它们都是将外部流量引入群集的方式,适用的场景却各不相同。 本文接下来我们将介绍它们的工作原理以及适用的相关场景。


注意:文中所述内容适用于 GKE (Google Kubernetes Engine 注1)。 如果你在其他云平台上运行使用步骤略有不同,比如 minikube 或其他相关软件。 我也不打算过多深入技术细节, 如果你有兴趣了解更多,Kubernetes 官方文档(注2)会提供更多的有用资源!



ClusterIP

ClusterIP 服务是 Kubernetes 默认的服务类型。 如果你在集群内部创建一个服务,则在集群内部的其他应用程序可以进行访问,但是不具备集群外部访问的能力。

ClusterIP 服务的 YAML 文件看起来像这样:


apiVersion: v1


kind: Service

metadata:  

  name: my-internal-service

selector:    

  app: my-app

spec:

  type: ClusterIP

  ports:  

  - name: http

    port: 80

    targetPort: 80

    protocol: TCP


如果不能从互联网访问 ClusterIP 服务,我为什么要谈论它呢?事实上,你可以通过 Kubernetes 代理进行访问。


1.png



感谢 Ahmet Alp Balkan(注3)提供的图表


启动 Kubernetes 代理:

$ kubectl proxy --port=8080

现在,可以通过 Kubernetes API 通过以下的模式来访问这个服务:


http://localhost:8080/api/v1/p ... t%3B/


通过这种方式可以使用以下的地址来访问我们上述定义的服务:

http://localhost:8080/api/v1/p ... http/


何时使用这种访问方式?


有以下几种场景,你可以使用 Kubernetes 代理的方式来访问服务:

1. 调试服务或者某些情况下通过笔记本电脑直接连接服务

2. 允许内部的通信,显示内部的仪表盘(dashboards)等

因为此种方式需要作为一个授权用户运行 kubectl,因此不应该用来暴露服务至互联网访问或者用于生产环境。


NodePort

NodePort 服务通过外部访问服务的最基本的方式。顾名思义,NodePort 就是在所有的节点或者虚拟机上开放特定的端口,该端口的流量将被转发到对应的服务。
 
2.png


从技术上层面,这不能算是最准确的图表,但我认为它能够直观展示了 NodePort 的工作方式。

NodePort 服务的 YAML 文件看起来像这样:

apiVersion: v1

kind: Service

metadata:  

  name: my-nodeport-service

selector:    

  app: my-app

spec:

  type: NodePort

  ports:  

  - name: http

    port: 80

    targetPort: 80

    nodePort: 30036

    protocol: TCP

从根本上讲,NodePort 方式的服务与 ClusterIP 方式的服务有两个区别。第一,类型是 NodePort,这需要指定一个称作 nodePort 的附加端口,并在所有节点上打开对应的端口。如果我们不具体指定端口,集群会选择一个随机的端口。大多数的情况下,我们都可以让 Kubernetes 帮我们选择合适的端口。正如 thockin(注4) 所描述的那样,有许多相关的注意事项(caveats)关于那些端口可供我们使用。


何时使用这种访问方式?

NodePort 方式有许多缺点:

1. 每个服务占用一个端口
2. 可以使用的  30000-32767 范围端口 (译者注:可以通过api-server启动参数service-node-port-range,指定限制范围,默认为30000-32767)
3. 如果节点/虚拟机IP地址发生更改,需要进行相关处理


由于上述原因,我不建议在生产环境中使用直接暴露服务。 如果运行的服务不要求高可用或者非常关注成本,这种方法则比较适合。 很好的例子就是用于演示或临时使用的程序。



LoadBalancer

LoadBalancer 服务是暴露服务至互联网最标准的方式。在 GKE 上,这将启动一个网络负载均衡器(注5),它会提供一个 IP 地址,以将所有流量转发到服务。

3.png


感谢 Ahmet Alp Balkan提供图表

何时使用这种访问方式?这是公开服务的默认的方法。指定的端口上流量都将被转发到对应的服务,不经过过滤和其他路由等操作。这种方式意味着转发几乎任何类型的流量,如HTTP,TCP,UDP,Websockets,gRPC或其他。


这种方式最大的缺点是,负载均衡器公开的每个服务都将获取独立 IP 地址,而我们则必须为每个暴露的服务对应的负载均衡器支付相关费用,这可能会变得非常昂贵!




Ingress

和上述讨论的服务方式不同,Ingress 实际上并不是服务类型中的一种。相反,它位于多个服务的前端充当一个智能路由或者集群的入口点。

你可以使用 Ingress 做很多不同的事情,并且不同类型的 Ingress 控制也具备不同的能力。

GKE 默认的 Ingress 控制器将启动一个 HTTP(S) 的负载均衡器。则将使我们可以基于访问路径和子域名将流量路由到后端服务。例如,你可以将 `foo.yourdomain.com` 下的流量转发到 foo 服务,将`yourdomain.com/bar/` 路径下的流量转发到 bar 服务。


4.png


感谢 Ahmet Alp Balkan提供图表


在 GKE 上定义 L7层 HTTP 负载均衡器的 Ingress 对象定义的 YAML 看起来像这样:

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: my-ingress

spec:

  backend:

    serviceName: other

    servicePort: 8080

  rules:

  - host: foo.mydomain.com

    http:

      paths:

      - backend:

          serviceName: foo

          servicePort: 8080

  - host: mydomain.com

    http:

      paths:

      - path: /bar/*

        backend:

          serviceName: bar

          servicePort: 8080


何时使用这种方式?Ingress 方式可能是暴露服务的最强大的方式,但也最复杂。现在有不同类型的 Ingress 控制器,包括 Google 云 负载均衡器(注6), Nginx(注7), Contour(注8), Istio(注9)等。此外,还有 Ingress 控制器的许多插件,比如 cert-manager(注10)可以用来自动为服务提供 SSL 证书。


如果希望在同一个IP地址下暴露多个服务,并且它们都使用相同的 L7 协议(通常是HTTP),则 Ingress 方式最有用。 如果使用本地 GCP 集成,则只需支付一台负载平衡器费用,并且是“智能”性 Ingress ,可以获得许多开箱即用的功能(如SSL,Auth,路由等)。


资源:

Kubernetes:https://medium.com/tag/kubernetes?source=post

Microservices:https://medium.com/tag/microservices?source=post

Services:https://medium.com/tag/services?source=post

Load Balancing:https://medium.com/tag/load-balancing?source=post

Ingress:https://medium.com/tag/ingress?source=post





1、https://cloud.google.com/gke

2、https://kubernetes.io/docs/con ... vice/

3、https://medium.com/@ahmetb

4、(https://medium.com/@thockin)

5、https://cloud.google.com/compu ... work/

6、https://cloud.google.com/kuber ... ancer

7、https://github.com/kubernetes/ingress-nginx

8、https://github.com/heptio/contour

9、https://istio.io/docs/tasks/tr ... .html

10、https://github.com/jetstack/cert-manager
 

Istio服务网格高级流量镜像,7种模式解决流量镜像难题

Istio小数 发表了文章 • 0 个评论 • 305 次浏览 • 2018-03-28 10:41 • 来自相关话题

作者:Christian Posta

翻译:吕德路 (https://github.com/lvdelu)

原文:Advanced Traffic-shadowing Patterns for Microservices With Istio Service Mesh



导言:


微服务可以加快系统开发速度和降低时间成本(注1)。然而,不能天真地认为只进行快速开发和变更就足够了(注2)。

如何在微服务中降低开发和变更的风险,Istio Service Mesh 提供了一种有助于降低将变更带入生产风险的方法,即将生产流量镜像到测试群集或软件的新版本中,并在我们引导实时流量之前针对问题进行测试。

这使我们能够将实际的用例和模糊的使用情况发送到我们的代码中,而我们在非生产模拟中的测试可能不会被捕获到。


在我以前的文章中,我写了关于 Istio Service Mesh 有一个非常棒的功能对流量进行镜像(注3)。对于 Istio 和 Service Mesh,我确实有很多话要说(注4),所以请随时关注@christianposta(注5)参与并保持查看最新的文章。

今天的主要课程是:



流量镜像的难题

当我们将生产流量镜像到测试集群、或生产中的灰度集群时,我们将会面临一些挑战。

首先,
如何在不影响生产服务关键路径的情况下获得生产集群的流量?
 
是否需要过滤掉这些请求中的个人信息?如何让测试集群不干扰实时协作者服务?如果服务对数据进行了更改,如何隔离这些更改而不影响生产服务?


这些都是真正的挑战,或许会被用作不尝试流量镜像的理由。但恕我直言,镜像代表了安全发布中更重要、更强大的技术之一,所以让我们看看有哪些模式来解决这些问题。如下所示:
 
在不影响生产关键路径的前提下将生产流量镜像到测试集群将流量定义为流量镜像镜像之后的实时服务流量与测试群集流量对比为某些测试配置文件提供协作服务合成事务虚拟化测试集群的数据库实现测试集群的数据库

让我们继续深入研究。



在不影响生产关键路径的前提下将生产流量镜像到测试集群

这可以说是最重要的部分。如果,在不影响生产流量的情况下,不能可靠地将流量镜像到测试群集,那么就应该停止。 不能为我们的“奇思妙想”牺牲生产的可靠性和可用性。 


通常我们会使用代理来镜像此流量。 Envoy Proxy(注6)是一个可用于此操作的代理。 Istio 是一种服务网格,它使用 Envoy 作为启用此功能的默认代理。有关更多信息,请参阅 Istio 镜像任务。


所以基本上,服务网格(Istio)已经位于我们生产流量的关键路径,以实现弹性,安全性,策略规划,路由控制等之间,并且还可以将流量镜像到我们的测试集群。 


事实上,这就是我在上一篇博客中深入探讨的内容(注7)。 重要的是来自生产中的流量通过带外数据被异步镜像。 任何响应都会被忽略。






对于熟悉所谓“企业集成模式”的读者(谢谢 Gregor Hohpe!),你会注意到这种“镜像”的东西实际上是一种 flavor 或 EIP(注8)。



将流量定义为流量镜像

另一个重要的考虑是识别我们已经镜像的流量。 我们需要能够辨别出用于测试目的的实时生产流量。 使用 Istio / Envoy 时,被镜像的的流量会自动用额外的上下文进行标记。


例如,当 Istio 镜像流量时,它会追加(注9)-shdow 到主机或者权限头中。 对于某些实现来说,目前这是一个问题,因-shadow将被添加到主机的末尾,所以 foobar:8080 的 Host 头将以这样的头部结尾:foobar:8080-shadow,这在技术上并非有效 HTTP 1.X。


在 Envoy 中使用此修复程序后(注10),-shadow 后缀将被添加到主机名,以便 foobar:8080 变成 foobar-shadow:8080。









镜像之后的实时服务流量与测试群集流量对比

一旦依赖流量镜像就可以做一些有趣的事情,也许我们希望通过进入测试集群的流量和我们从生产实时看到的期望行为进行对比。

例如,我们可能希望将预期的请求结果或API合同中任何偏离的请求结果与向前和向后兼容性进行比较。我们可以插入一个负责这种类型的流量协调的代理,以及一个可以进行有趣比较的代理。Twitter Diffy(注11)是这些代理中的一个,它已经在 Twitter 应用到了生产(注12),并且其它地方也将会这么做。它基本上需要镜像流量(感谢 Istio 和 Envoy,我们已经做到了这一点),并调用实时服务和新服务并比较结果。它能够检测结果中的 “noise” 并忽略它(时间戳,单调增加计数器等),通过首先调用两个实时服务实例来检测 “noise",然后忽略那些用于测试服务调用的部分。






Diffy 还有一个非常棒的网页/仪表板,用于查看调用结果,它们的差异以及基于特定特征的过滤。 最后,Diffy 有一个很好的管理控制台,用于查看关于调用比较的指标和统计数据。







我在这里有一个演示(注13),非常感谢 Prashant Khanduri,Puneet Khanduri 和 Alex Soto。 在我制作过程中,留意观看此演示视频。



为某些测试配置文件提供协作服务

当我们部署一个新版本的服务并将流量镜像到测试集群时,我们需要注意对其他环境的影响。我们的服务通常需要与其他服务协作(查询数据,更新数据等)。如果与其他服务的协作仅仅是读取或 GET 请求,并且这些协作者能够承担额外的负载,这可能不成问题。但是,如果我们的服务在我们的协作者中改变了数据,我们需要确保这些调用指向测试流量而不是真正的生产流量。你可以为你的部署创建不同的安装配置,从而注入这些配置。


例如,我们注入了 test.prod.com,而不是 live.prod.com 作为下游服务。如果在 Kubernetes上部署,则可以使用不同的 maps(注14)配置来控制此功能。


另一个有趣的方法是使用诸如 Hoverfly(注15)或 Microcks(注16)之类的东西部署虚拟化测试流量。使用这些服务虚拟化工具,你可以策划预期的请求/响应对,并将值发生变化的流量导向这些返回预期响应的代理。








合成事务


在很多情况下,我们服务的新版本需要改变其本地数据存储中的数据。它可能会向协作者服务发出调用来改变数据,但也许我们不能(或不应该)使用先前的技术(服务虚拟化)来存储这些调用。


另一种方法是更明确地通过调用(比如在我们之前添加的镜像模式中我们添加了-shadow)来表明这些请求应该再一个“合成事务”结果中,即,这些不是真正的事务,并且再它们在请求结束时应该采取任何补偿来撤消他们。我们可以为我们的请求添加一个头文件,或者甚至可以使其成为请求主体的一部分,以表明某个事务是“合成的”。当我们这样做时,我们正在指示参与服务正常处理请求,包括所有数据操作,然后在提交之前回滚事务。请注意,这适用于事务性数据存储,但可能不适用于其他数据存储。在这些情况下,如果你已经有工作单元的概念,则可以将合成语义附加到该语义上。否则,最好不要试图通过合成事务来隔离和放弃更改。  








这种方法对于执行全路径请求很有用,包括数据存储,获得更好的时序保真度和双测试方法可能捕捉不到的数据干扰/不匹配问题。


这种方法的一大缺点是它按惯例实施,难以执行。 它可能与你拥有和控制的服务一起工作,但可能无法扩展到许多参与协作的合作者。 你不愿意试图在所有服务中强制执行这个约定,并且有一个单独的服务不能正确地实现这个回滚功能,然后把所有的东西混淆起来。 在严格控制和协调部署中使用此模式。



虚拟化测试集群的数据库


在针对镜像流量进行测试时,我们已经开始涉及与处理数据相关的问题。通常,如果你的测试集群使用数据存储,并且测试服务以某种形式更新/插入/变更数据,则需要隔离这些更改。当用信头或嵌入式标志等信号发送时,我们只是简单地回滚任何更改,但这并不总是个办法。


在镜像流量时处理数据问题的另一种方法是为测试群集使用可替代的数据存储。你可以使用一个空的数据存储并使用测试数据填充它,并针对该数据运行镜像流量。但是,如果你使用的是像 Diffy(上面提到的)之类的东西,则可能会在响应比较中收到大量误报,因为测试群集中的数据正在使用测试数据,而实时服务正在使用生产数据。处理这个问题的一个好方法就是虚拟化数据层。我们让测试集群使用一个与生产数据存储相同数据的数据存储。






当我们这样做时,我们可以获得生产数据的当前一致视图,也可以在不影响生产数据存储的情况下写入数据存储。 我们可以使用像 JBoss Teiid(注17)这样的工具轻松完成此操作。 Teiid 为所有类型的数据存储系统提供连接器,包括 RDBMS,No-SQL 系统,平面文件,hadoop,salesforce 等,并且可以为我们的测试集群虚拟化它们。 当你这样做时,任何时候变更的数据可以一次性写入数据库而服务无感知。 我有一系列博客讨论了这篇关于微服务迁移的博客文章(注18)。


实现测试集群的数据库

最后,另一种扩展先前数据虚拟化技术的方法是完全实现数据存储。这样,我们测试集群的数据存储基本上与生产集群的数据存储相同,并且通过流处理不断更新。工作方式是使用(CDC - 更改数据捕获)(注19)从生产数据库捕获更改,然后将这些更改发送到新数据库。一些数据存储允许将其作为内置的复制机制(想想 MySQL 的从节点或者其他),但很多时候这些是只读的。你可以使用像Debezium(注20)这样的更改数据捕获工具来构建简单的 CDC 系统,以便你的测试数据存储具有完全复制的生产数据库副本并且不受约束的使用它。 


Debezium 为不同的数据存储提供连接器(注21),并从这些数据库中获取更改事件(即读取事务日志)并将这些更改传送到 Apache Kafka(注22)。从那里,你可以使用任何流处理工具将这些流实现到你的测试数据库中。 FWIW,上面提到的 Teiid(注23)很快就会有这个功能。






此外,如果你已经拥有数据流管道,使用事件驱动架构或使用某种事件源数据机制,那么这个“实现”测试数据库将成为更好的选择。




总结

在实践中,将生产流量镜像到我们的测试群集(无论该群集是存在于生产环境还是非生产环境中)是降低新部署风险的非常有效的方法。 


多年来,推特和亚马逊这样的大型 webops 公司一直在这样做。 这种方法带来了一些挑战,但是上述模式中讨论的方法存在有效的解决方案。 


如果你认为我错过了某些东西,或者觉得有一个我没有涉及到的令人讨厌的问题,请与我联系,我会很乐意与你讨论并将其添加到此博客的更新中。 谢谢!





1、https://www.slideshare.net/cep ... -2017

2、 https://www.cnet.com/news/zuck ... more/

3、http://blog.christianposta.com ... ease/

4、http://blog.christianposta.com/

5、https://twitter.com/christianposta

6、https://www.envoyproxy.io/docs ... olicy

7、http://blog.christianposta.com ... ease/

8、http://www.enterpriseintegrati ... .html

9、https://www.envoyproxy.io/docs ... olicy

10、https://github.com/envoyproxy/envoy/pull/2600

11、https://github.com/twitter/diffy

12、https://blog.twitter.com/engin ... .html

13、https://github.com/christian-p ... me.md

14、https://kubernetes.io/docs/tas ... gmap/

15、https://hoverfly.io/

16、 http://microcks.github.io/

17、http://teiid.jboss.org/

18、 http://blog.christianposta.com ... -iii/

19、https://en.wikipedia.org/wiki/Change_data_capture

20、http://debezium.io/

21、http://debezium.io/docs/

22、http://kafka.apache.org/

23、http://teiid.jboss.org/ 



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,扫码报名!
 





  查看全部
作者:Christian Posta

翻译:吕德路 (https://github.com/lvdelu)

原文:Advanced Traffic-shadowing Patterns for Microservices With Istio Service Mesh



导言:


微服务可以加快系统开发速度和降低时间成本(注1)。然而,不能天真地认为只进行快速开发和变更就足够了(注2)。

如何在微服务中降低开发和变更的风险,Istio Service Mesh 提供了一种有助于降低将变更带入生产风险的方法,即将生产流量镜像到测试群集或软件的新版本中,并在我们引导实时流量之前针对问题进行测试。

这使我们能够将实际的用例和模糊的使用情况发送到我们的代码中,而我们在非生产模拟中的测试可能不会被捕获到。


在我以前的文章中,我写了关于 Istio Service Mesh 有一个非常棒的功能对流量进行镜像(注3)。对于 Istio 和 Service Mesh,我确实有很多话要说(注4),所以请随时关注@christianposta(注5)参与并保持查看最新的文章。

今天的主要课程是:



流量镜像的难题

当我们将生产流量镜像到测试集群、或生产中的灰度集群时,我们将会面临一些挑战。

首先,
  • 如何在不影响生产服务关键路径的情况下获得生产集群的流量?

 
  • 是否需要过滤掉这些请求中的个人信息?
  • 如何让测试集群不干扰实时协作者服务?
  • 如果服务对数据进行了更改,如何隔离这些更改而不影响生产服务?



这些都是真正的挑战,或许会被用作不尝试流量镜像的理由。但恕我直言,镜像代表了安全发布中更重要、更强大的技术之一,所以让我们看看有哪些模式来解决这些问题。如下所示:
 
  • 在不影响生产关键路径的前提下将生产流量镜像到测试集群
  • 将流量定义为流量镜像
  • 镜像之后的实时服务流量与测试群集流量对比
  • 为某些测试配置文件提供协作服务
  • 合成事务
  • 虚拟化测试集群的数据库
  • 实现测试集群的数据库


让我们继续深入研究。



在不影响生产关键路径的前提下将生产流量镜像到测试集群

这可以说是最重要的部分。如果,在不影响生产流量的情况下,不能可靠地将流量镜像到测试群集,那么就应该停止。 不能为我们的“奇思妙想”牺牲生产的可靠性和可用性。 


通常我们会使用代理来镜像此流量。 Envoy Proxy(注6)是一个可用于此操作的代理。 Istio 是一种服务网格,它使用 Envoy 作为启用此功能的默认代理。有关更多信息,请参阅 Istio 镜像任务。


所以基本上,服务网格(Istio)已经位于我们生产流量的关键路径,以实现弹性,安全性,策略规划,路由控制等之间,并且还可以将流量镜像到我们的测试集群。 


事实上,这就是我在上一篇博客中深入探讨的内容(注7)。 重要的是来自生产中的流量通过带外数据被异步镜像。 任何响应都会被忽略。

1.png


对于熟悉所谓“企业集成模式”的读者(谢谢 Gregor Hohpe!),你会注意到这种“镜像”的东西实际上是一种 flavor 或 EIP(注8)。



将流量定义为流量镜像

另一个重要的考虑是识别我们已经镜像的流量。 我们需要能够辨别出用于测试目的的实时生产流量。 使用 Istio / Envoy 时,被镜像的的流量会自动用额外的上下文进行标记。


例如,当 Istio 镜像流量时,它会追加(注9)-shdow 到主机或者权限头中。 对于某些实现来说,目前这是一个问题,因-shadow将被添加到主机的末尾,所以 foobar:8080 的 Host 头将以这样的头部结尾:foobar:8080-shadow,这在技术上并非有效 HTTP 1.X。


在 Envoy 中使用此修复程序后(注10),-shadow 后缀将被添加到主机名,以便 foobar:8080 变成 foobar-shadow:8080。


2.png




镜像之后的实时服务流量与测试群集流量对比

一旦依赖流量镜像就可以做一些有趣的事情,也许我们希望通过进入测试集群的流量和我们从生产实时看到的期望行为进行对比。

例如,我们可能希望将预期的请求结果或API合同中任何偏离的请求结果与向前和向后兼容性进行比较。我们可以插入一个负责这种类型的流量协调的代理,以及一个可以进行有趣比较的代理。Twitter Diffy(注11)是这些代理中的一个,它已经在 Twitter 应用到了生产(注12),并且其它地方也将会这么做。它基本上需要镜像流量(感谢 Istio 和 Envoy,我们已经做到了这一点),并调用实时服务和新服务并比较结果。它能够检测结果中的 “noise” 并忽略它(时间戳,单调增加计数器等),通过首先调用两个实时服务实例来检测 “noise",然后忽略那些用于测试服务调用的部分。

3.png


Diffy 还有一个非常棒的网页/仪表板,用于查看调用结果,它们的差异以及基于特定特征的过滤。 最后,Diffy 有一个很好的管理控制台,用于查看关于调用比较的指标和统计数据。

4.png



我在这里有一个演示(注13),非常感谢 Prashant Khanduri,Puneet Khanduri 和 Alex Soto。 在我制作过程中,留意观看此演示视频。



为某些测试配置文件提供协作服务

当我们部署一个新版本的服务并将流量镜像到测试集群时,我们需要注意对其他环境的影响。我们的服务通常需要与其他服务协作(查询数据,更新数据等)。如果与其他服务的协作仅仅是读取或 GET 请求,并且这些协作者能够承担额外的负载,这可能不成问题。但是,如果我们的服务在我们的协作者中改变了数据,我们需要确保这些调用指向测试流量而不是真正的生产流量。你可以为你的部署创建不同的安装配置,从而注入这些配置。


例如,我们注入了 test.prod.com,而不是 live.prod.com 作为下游服务。如果在 Kubernetes上部署,则可以使用不同的 maps(注14)配置来控制此功能。


另一个有趣的方法是使用诸如 Hoverfly(注15)或 Microcks(注16)之类的东西部署虚拟化测试流量。使用这些服务虚拟化工具,你可以策划预期的请求/响应对,并将值发生变化的流量导向这些返回预期响应的代理。

5.png




合成事务


在很多情况下,我们服务的新版本需要改变其本地数据存储中的数据。它可能会向协作者服务发出调用来改变数据,但也许我们不能(或不应该)使用先前的技术(服务虚拟化)来存储这些调用。


另一种方法是更明确地通过调用(比如在我们之前添加的镜像模式中我们添加了-shadow)来表明这些请求应该再一个“合成事务”结果中,即,这些不是真正的事务,并且再它们在请求结束时应该采取任何补偿来撤消他们。我们可以为我们的请求添加一个头文件,或者甚至可以使其成为请求主体的一部分,以表明某个事务是“合成的”。当我们这样做时,我们正在指示参与服务正常处理请求,包括所有数据操作,然后在提交之前回滚事务。请注意,这适用于事务性数据存储,但可能不适用于其他数据存储。在这些情况下,如果你已经有工作单元的概念,则可以将合成语义附加到该语义上。否则,最好不要试图通过合成事务来隔离和放弃更改。  


6.png



这种方法对于执行全路径请求很有用,包括数据存储,获得更好的时序保真度和双测试方法可能捕捉不到的数据干扰/不匹配问题。


这种方法的一大缺点是它按惯例实施,难以执行。 它可能与你拥有和控制的服务一起工作,但可能无法扩展到许多参与协作的合作者。 你不愿意试图在所有服务中强制执行这个约定,并且有一个单独的服务不能正确地实现这个回滚功能,然后把所有的东西混淆起来。 在严格控制和协调部署中使用此模式。



虚拟化测试集群的数据库


在针对镜像流量进行测试时,我们已经开始涉及与处理数据相关的问题。通常,如果你的测试集群使用数据存储,并且测试服务以某种形式更新/插入/变更数据,则需要隔离这些更改。当用信头或嵌入式标志等信号发送时,我们只是简单地回滚任何更改,但这并不总是个办法。


在镜像流量时处理数据问题的另一种方法是为测试群集使用可替代的数据存储。你可以使用一个空的数据存储并使用测试数据填充它,并针对该数据运行镜像流量。但是,如果你使用的是像 Diffy(上面提到的)之类的东西,则可能会在响应比较中收到大量误报,因为测试群集中的数据正在使用测试数据,而实时服务正在使用生产数据。处理这个问题的一个好方法就是虚拟化数据层。我们让测试集群使用一个与生产数据存储相同数据的数据存储。

7.png


当我们这样做时,我们可以获得生产数据的当前一致视图,也可以在不影响生产数据存储的情况下写入数据存储。 我们可以使用像 JBoss Teiid(注17)这样的工具轻松完成此操作。 Teiid 为所有类型的数据存储系统提供连接器,包括 RDBMS,No-SQL 系统,平面文件,hadoop,salesforce 等,并且可以为我们的测试集群虚拟化它们。 当你这样做时,任何时候变更的数据可以一次性写入数据库而服务无感知。 我有一系列博客讨论了这篇关于微服务迁移的博客文章(注18)。


实现测试集群的数据库

最后,另一种扩展先前数据虚拟化技术的方法是完全实现数据存储。这样,我们测试集群的数据存储基本上与生产集群的数据存储相同,并且通过流处理不断更新。工作方式是使用(CDC - 更改数据捕获)(注19)从生产数据库捕获更改,然后将这些更改发送到新数据库。一些数据存储允许将其作为内置的复制机制(想想 MySQL 的从节点或者其他),但很多时候这些是只读的。你可以使用像Debezium(注20)这样的更改数据捕获工具来构建简单的 CDC 系统,以便你的测试数据存储具有完全复制的生产数据库副本并且不受约束的使用它。 


Debezium 为不同的数据存储提供连接器(注21),并从这些数据库中获取更改事件(即读取事务日志)并将这些更改传送到 Apache Kafka(注22)。从那里,你可以使用任何流处理工具将这些流实现到你的测试数据库中。 FWIW,上面提到的 Teiid(注23)很快就会有这个功能。

8.png


此外,如果你已经拥有数据流管道,使用事件驱动架构或使用某种事件源数据机制,那么这个“实现”测试数据库将成为更好的选择。




总结

在实践中,将生产流量镜像到我们的测试群集(无论该群集是存在于生产环境还是非生产环境中)是降低新部署风险的非常有效的方法。 


多年来,推特和亚马逊这样的大型 webops 公司一直在这样做。 这种方法带来了一些挑战,但是上述模式中讨论的方法存在有效的解决方案。 


如果你认为我错过了某些东西,或者觉得有一个我没有涉及到的令人讨厌的问题,请与我联系,我会很乐意与你讨论并将其添加到此博客的更新中。 谢谢!





1、https://www.slideshare.net/cep ... -2017

2、 https://www.cnet.com/news/zuck ... more/

3、http://blog.christianposta.com ... ease/

4、http://blog.christianposta.com/

5、https://twitter.com/christianposta

6、https://www.envoyproxy.io/docs ... olicy

7、http://blog.christianposta.com ... ease/

8、http://www.enterpriseintegrati ... .html

9、https://www.envoyproxy.io/docs ... olicy

10、https://github.com/envoyproxy/envoy/pull/2600

11、https://github.com/twitter/diffy

12、https://blog.twitter.com/engin ... .html

13、https://github.com/christian-p ... me.md

14、https://kubernetes.io/docs/tas ... gmap/

15、https://hoverfly.io/

16、 http://microcks.github.io/

17、http://teiid.jboss.org/

18、 http://blog.christianposta.com ... -iii/

19、https://en.wikipedia.org/wiki/Change_data_capture

20、http://debezium.io/

21、http://debezium.io/docs/

22、http://kafka.apache.org/

23、http://teiid.jboss.org/ 



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,扫码报名!
 

promote.png

 

使用Istio简化微服务系列三:如何才能做“金丝雀部署”,并通过Istio增加流量?

Istio小数 发表了文章 • 0 个评论 • 384 次浏览 • 2018-03-27 10:10 • 来自相关话题

作者:Nithin Mallya

原文:Simplifying Microservices with Istio in Google Kubernetes Engine — Part III


我写的关于 Istio 的文章是 Istio 网站上文档的一部分。请阅读官方文档以了解更多信息。


在本系列的第一部分中(使用Istio简化微服务系列一:如何用Isito解决Spring Cloud Netflix部署微服务的挑战?),我们看到了如何使用 Istio 来简化我们的微服务之间的沟通。


在本系列的第二部分中(使用Istio简化微服务系列二:如何通过HTTPS与外部服务进行通信?),我们学会了使用 Istio egress rules 来控制服务网格之外的服务的访问。

在这一部分中,我们将看到如何才能做“金丝雀部署”(Canary Deployments),并通过 Istio 增加流量。


背景:

在过去的文章中,我详细解释了我们如何使用 Kubernetes 进行蓝/绿部署。这是一种部署技术,在此技术中,我们部署了与应用程序当前版本和新版本相同的生产环境。这项技术使我们能够执行零停机时间部署(Zero Downtime Deployments, 简称:ZDD),以确保我们的用户在切换到新版本时不受影响。有了这两个版本(当前版本和新版本)也使我们能够在新版本出现任何问题时进行回滚。


我们还需要的是能够将流量增加(或下降)到我们的应用程序的新版本,并监控它以确保没有负面影响。实现这一点的一种方法是使用“金丝雀部署”或“金丝雀”发行版。


一个不太有趣的事实:当矿工们带着金丝雀进入矿场时,任何有毒气体都会首先杀死金丝雀,并以此警告矿工们离开矿井。


同样地,在应用程序部署世界中,使用“金丝雀部署”,我们可以将应用程序的新版本部署到生产中,并只向这个新部署发送一小部分流量。这个新版本将与当前版本并行运行,并在我们将所有流量切换到新版本之前提醒我们注意任何问题。


例如:我们应用程序的 v1 可以占到90%的流量,而 v2 可以得到另外的10%。如果一切看起来都很好,我们可以将 v2 流量增加到25%,50%,最终达到100%。Istio Canary 部署的另一个优势是,我们可以根据请求中的自定义标头来增加流量。例如,在我们的应用程序的v2中设置了一个特定 cookie 头值的流量的10%。


注意:虽然“金丝雀部署”“可以”与 A/B 测试一起使用,以查看用户如何从业务度量的角度对新版本做出反应,但其背后的真正动机是确保应用程序从功能角度上满意地执行。此外,企业所有者可能希望在更长的时间内(例如:许多天甚至几周)进行 A/B 测试,而不是金丝雀码头可能采取的措施。因此,把它们分开是明智的。


Let's see it in action

从第一部分我们知道,我们的 PetService 与 PetDetailsService(v1) 和 PetMedicalHistoryService(v1) 进行了会谈。对 PetService的调用的输出如下:

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}

在上面的回复中,你会注意到 petBreed 说“狗”。然而,Maximus 是德国牧羊犬,这时候我们需要修改 PetDetailsService,以便正确返回品种。


因此,我们创建了 PetDetailsService 的 v2,它将返回“德国牧羊犬”。但是,我们希望确保在将所有流量驱动到 v2 之前,我们可以使用一小部分用户来测试这个服务的 v2。


在下面的图1中,我们看到流量被配置成这样,50%的请求将被定向到 v1 和50%到 v2,我们的 “金丝雀部署”。(它可以是任意数字,取决于变化的大小,并尽量减少负面影响)。







      图1:我们可以将 PetDetailsServic e的 v2 部署为金丝雀部署和匝道流量。


步骤

1、创建 PetDetails Service 的 v2 版本并像以前一样部署它。 (请参阅 petdetailservice / kube 文件夹下的 petinfo.yaml)

$ kubectl get pods

NAME                                         READY     STATUS    RESTARTS      AGE

petdetailsservice-v1-2831216563-qnl10        2/2        Running      0          19h

petdetailsservice-v2-2943472296-nhdxt       2/2       Running       0           2h

petmedicalhistoryservice-v1-28468096-hd7ld   2/2       Running      0          19h

petservice-v1-1652684438-3l112               2/2       Running      0      19h




2、创建一个RouteRule,将流量分成 petdetailsservice 的50%(v1)和50%(v2),如下所示:

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: petdetailsservice-default
spec:
  destination:
    name: petdetailsservice
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v2
    weight: 50
EOF

$ istioctl get routerule

NAME    KIND     NAMESPACE

petdetailsservice-default RouteRule.v1alpha2.config.istio.io default




3、现在,如果你访问 PetService,你应该看到替代请求分别返回“Dog”和“German Shepherd Dog”,如下所示:

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "German Shepherd Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}



It works!

这引出了一个问题:我们不能用 Kubernetes Canary Deployments 来做到这一点吗?简短的答案是肯定的。


然而,这样做的步骤更复杂,也有局限性:

你仍然需要创建 PetDetailsService  (v1和v2)的两个部署,但是你需要手动限制在部署过程中 v2 副本的数量,以维护 v1:v2 比。例如:你可以使用10个副本部署 v1,并将v2 部署到2个副本,以获得10:2的负载平衡,等等。


由于所有的 pod 无论版本是否相同,Kubernetes 集群中的流量负载平衡仍然受到随机性的影响。


基于业务量的自动伸缩 pods 也是有问题的,因为我们需要单独的 autoscale 的2个部署,它可以根据每个服务的流量负载分配来做出不同的行为。


如果我们想根据某些标准(如 request headers)仅允许某些用户使用/限制流量,则Kubernetes Canary Deployments可能无法实现此目标。


结论:你刚刚看到了创建一个“金丝雀部署”和增加 Istio 的流量是多么容易。马克西姆斯也很高兴!(小数:下图就是马克西姆斯...嗯...很帅气!)








资源:

1、Part I of this article series: https://medium.com/google-clou ... 922b8

2、Part II of this article series: https://medium.com/google-clou ... 33089

3、The Istio home page https://istio.io/

4、DevOxx Istio presentation by Ray Tsang: https://www.youtube.com/watch% ... D231s

5、Github link to this example: https://github.com/nmallya/istiodemo

6、All things Kubernetes: https://kubernetes.io/


ServiceMesh微信交流群:

添加微信xiaoshu062,备注:服务网格,即可加入Service Mesh微信交流群。


社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,扫码报名!
 





 
  查看全部
作者:Nithin Mallya

原文:Simplifying Microservices with Istio in Google Kubernetes Engine — Part III


我写的关于 Istio 的文章是 Istio 网站上文档的一部分。请阅读官方文档以了解更多信息。


在本系列的第一部分中(使用Istio简化微服务系列一:如何用Isito解决Spring Cloud Netflix部署微服务的挑战?),我们看到了如何使用 Istio 来简化我们的微服务之间的沟通。


在本系列的第二部分中(使用Istio简化微服务系列二:如何通过HTTPS与外部服务进行通信?),我们学会了使用 Istio egress rules 来控制服务网格之外的服务的访问。

在这一部分中,我们将看到如何才能做“金丝雀部署”(Canary Deployments),并通过 Istio 增加流量。


背景:

在过去的文章中,我详细解释了我们如何使用 Kubernetes 进行蓝/绿部署。这是一种部署技术,在此技术中,我们部署了与应用程序当前版本和新版本相同的生产环境。这项技术使我们能够执行零停机时间部署(Zero Downtime Deployments, 简称:ZDD),以确保我们的用户在切换到新版本时不受影响。有了这两个版本(当前版本和新版本)也使我们能够在新版本出现任何问题时进行回滚。


我们还需要的是能够将流量增加(或下降)到我们的应用程序的新版本,并监控它以确保没有负面影响。实现这一点的一种方法是使用“金丝雀部署”或“金丝雀”发行版。


一个不太有趣的事实:当矿工们带着金丝雀进入矿场时,任何有毒气体都会首先杀死金丝雀,并以此警告矿工们离开矿井。


同样地,在应用程序部署世界中,使用“金丝雀部署”,我们可以将应用程序的新版本部署到生产中,并只向这个新部署发送一小部分流量。这个新版本将与当前版本并行运行,并在我们将所有流量切换到新版本之前提醒我们注意任何问题。


例如:我们应用程序的 v1 可以占到90%的流量,而 v2 可以得到另外的10%。如果一切看起来都很好,我们可以将 v2 流量增加到25%,50%,最终达到100%。Istio Canary 部署的另一个优势是,我们可以根据请求中的自定义标头来增加流量。例如,在我们的应用程序的v2中设置了一个特定 cookie 头值的流量的10%。


注意:虽然“金丝雀部署”“可以”与 A/B 测试一起使用,以查看用户如何从业务度量的角度对新版本做出反应,但其背后的真正动机是确保应用程序从功能角度上满意地执行。此外,企业所有者可能希望在更长的时间内(例如:许多天甚至几周)进行 A/B 测试,而不是金丝雀码头可能采取的措施。因此,把它们分开是明智的。


Let's see it in action

从第一部分我们知道,我们的 PetService 与 PetDetailsService(v1) 和 PetMedicalHistoryService(v1) 进行了会谈。对 PetService的调用的输出如下:

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}

在上面的回复中,你会注意到 petBreed 说“狗”。然而,Maximus 是德国牧羊犬,这时候我们需要修改 PetDetailsService,以便正确返回品种。


因此,我们创建了 PetDetailsService 的 v2,它将返回“德国牧羊犬”。但是,我们希望确保在将所有流量驱动到 v2 之前,我们可以使用一小部分用户来测试这个服务的 v2。


在下面的图1中,我们看到流量被配置成这样,50%的请求将被定向到 v1 和50%到 v2,我们的 “金丝雀部署”。(它可以是任意数字,取决于变化的大小,并尽量减少负面影响)。


微信图片_20180327100820.jpg


      图1:我们可以将 PetDetailsServic e的 v2 部署为金丝雀部署和匝道流量。


步骤

1、创建 PetDetails Service 的 v2 版本并像以前一样部署它。 (请参阅 petdetailservice / kube 文件夹下的 petinfo.yaml)

$ kubectl get pods

NAME                                         READY     STATUS    RESTARTS      AGE

petdetailsservice-v1-2831216563-qnl10        2/2        Running      0          19h

petdetailsservice-v2-2943472296-nhdxt       2/2       Running       0           2h

petmedicalhistoryservice-v1-28468096-hd7ld   2/2       Running      0          19h

petservice-v1-1652684438-3l112               2/2       Running      0      19h




2、创建一个RouteRule,将流量分成 petdetailsservice 的50%(v1)和50%(v2),如下所示:

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: petdetailsservice-default
spec:
  destination:
    name: petdetailsservice
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v2
    weight: 50
EOF

$ istioctl get routerule

NAME    KIND     NAMESPACE

petdetailsservice-default RouteRule.v1alpha2.config.istio.io default




3、现在,如果你访问 PetService,你应该看到替代请求分别返回“Dog”和“German Shepherd Dog”,如下所示:

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}

$ curl http://108.59.82.93/pet/123

{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "German Shepherd Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}



It works!

这引出了一个问题:我们不能用 Kubernetes Canary Deployments 来做到这一点吗?简短的答案是肯定的。


然而,这样做的步骤更复杂,也有局限性:

你仍然需要创建 PetDetailsService  (v1和v2)的两个部署,但是你需要手动限制在部署过程中 v2 副本的数量,以维护 v1:v2 比。例如:你可以使用10个副本部署 v1,并将v2 部署到2个副本,以获得10:2的负载平衡,等等。


由于所有的 pod 无论版本是否相同,Kubernetes 集群中的流量负载平衡仍然受到随机性的影响。


基于业务量的自动伸缩 pods 也是有问题的,因为我们需要单独的 autoscale 的2个部署,它可以根据每个服务的流量负载分配来做出不同的行为。


如果我们想根据某些标准(如 request headers)仅允许某些用户使用/限制流量,则Kubernetes Canary Deployments可能无法实现此目标。


结论:你刚刚看到了创建一个“金丝雀部署”和增加 Istio 的流量是多么容易。马克西姆斯也很高兴!(小数:下图就是马克西姆斯...嗯...很帅气!)


1_6uuUOOk5AVyeQ8QTkMFrrg.jpeg



资源:

1、Part I of this article series: https://medium.com/google-clou ... 922b8

2、Part II of this article series: https://medium.com/google-clou ... 33089

3、The Istio home page https://istio.io/

4、DevOxx Istio presentation by Ray Tsang: https://www.youtube.com/watch% ... D231s

5、Github link to this example: https://github.com/nmallya/istiodemo

6、All things Kubernetes: https://kubernetes.io/


ServiceMesh微信交流群:

添加微信xiaoshu062,备注:服务网格,即可加入Service Mesh微信交流群。



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,扫码报名!
 

promote.png

 
 

下发规则到集群istio是通过是什么方式保障事务的一致性的?

Istiochym 回复了问题 • 2 人关注 • 2 个回复 • 225 次浏览 • 2018-03-25 17:26 • 来自相关话题

为什么我们需要Istio?四大组件助力Istio突围!

Istio小数 发表了文章 • 0 个评论 • 601 次浏览 • 2018-03-21 10:29 • 来自相关话题

作者:Grace@grapesfrog

翻译:宋净超(Jimmy Song)

     Kubernetes、Cloud Native布道者、开源爱好者,个人博客https://jimmysong.io

原文:Istio why do I need it?



我最近没有多少时间去玩 K8S,并且我承认在 Istio 到底给 K8S 带来了什么这个问题上我有点迷失了。这是否会增加更多的运营开销?它是否简化了我们通常需要做的事情?这些问题都浮现在我的脑海里。

我怀疑在发布了这些内容之后,我团队中比我更懂 K8S 的人可能会想找我谈谈,估计我会跟团队中的成员辩论,但那将是我最喜欢的对话。


那么 Istio 究竟是什么?

Istio 网站(注1)上说:

Istio 带给你:
 
HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。支持访问控制、速率限制和配额的可拔插策略层和配置 API。自动指标、日志和集群内所有流量的跟踪,包括集群入口和出口。通过集群中的服务之间的强身份断言来实现服务间的身份验证。


通过在整个环境中部署一个特殊的 sidecar 代理(辅助容器),你可以将 Istio 支持添加到服务中(这给我留下了深刻的印象,如果你想做到这一点,请参阅后面的内容)。安装了 sidecar 代理之后,(微)服务之间的所有网络通信都通过这个代理。此外,所有的网络通信都是使用 Istio 的控制平面功能进行配置和管理的。


Istio 是 Service Mesh(服务网格)。我认为的 service mesh 定义就是“它是一个专用的基础设施层,使得服务间的通信安全、高效和可靠”。


然而,如果像我一样,你从概念文档(注2)开始看的话,上面有这样的内容:“术语 service mesh 通常用于描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的大小和复杂程度不断增加,可能会变得难以理解和管理。可能出现包括服务发现、负载平衡、故障恢复、度量和监控,以及更复杂的需求,如A/B测试、金丝雀发布、速率限制、访问控制和端到端身份验证。Istio 提供了一个完整的解决方案,通过对整个服务网格提供行为分析和操作控制来满足微服务应用程序的各种需求。“


读完之后你可能会像我一样困惑!最后在网上查了一圈关于什么是服务网格之后,我终于搞明白了。我最后使用的可能是一个在所有搜索到的样本里一个非代表性的共识,但这是一个合理的选择。不过有个细节确实了,就是如何将它与 K8S 等编排工具分开。Istio 需要跟 K8S一起使用,没有 K8S 或其他容器编排工具的它就不存在了吗?它没有做编排,实际上它的是为解决管理基于微服务的解决方案中网络和操作复杂性而设计的。它涵盖的范围就像K8S一样!现在我真的需要继续这个帖子了。

所以我知道 Istio 是什么,给我们带来了什么,但它实际上解决了什么挑战呢?


从为什么使用 Istio 页面中(注3)可以看出,它在服务网络中统一提供了许多关键功能:


流量管理
 
可观察性强制策略服务身份标识和安全


对于我来说,要真正理解 Istio 的价值,所以我使用了 codelab(注四)。编写 code lab 的人真是太棒了!


Code lab 向我介绍了 Istio 控制平面的四个主要组件:
 
Pilot:处理代理 sidecar 的配置和编程。Mixer:为你的流量处理决策并收集遥测数据。Ingress:处理来自群集外部的传入请求。CA:证书颁发机构。


查看 Istio 架构概念(注5)页面了解这些组件如何协同工作的。

Code lab提供了路由规则(注6)——流量管理部分

我还尝试了 Istio.io 中的一些 task,因为我需要了解它如何处理那些领域的工作。

提示:如果你在完成 codelab 时也决定在四处看看,那么请将你的群集与应用程序一起启动并运行。无论如何,你会再次使用它。

所以我对它如何解决这些问题有了一个基本的了解,但是如果我使用像 GKE 这样的东西来托管K8S(你知道我会选它不是吗?)使用 Istio 是否合适?


注意:是的,这里有更多的细节,但我主要想弄明白为什么需要使用 Istio。



集群最终用户/开发人员访问

GKE 结合使用 IAM(注7) 和 RBAC(注8),是的,这里面有很多东西需要你了解。

要为你的集群用户授予比 Cloud IAM 更细粒度的权限,你可以使用 namespace 和 RBAC 来限制对特定 pod 的访问或排除对 secret 的访问。

Istio RBAC (注9)介绍了两个侧重于服务的角色
 
ServiceRole 定义用于访问网格中的服务的角色。ServiceRoleBinding 将角色授予主题(例如用户、组、服务)。

它们是 K8S 中的 CustomResourceDefinition(CRD)对象。但您仍然需要了解 IAM。


服务身份标识

GKE 可以使用 service account 来管理 GKE 上运行的应用程序(注10)可以使用哪些 GCP 服务。这些 service accout 的密钥使用 secret 存储。Pod 中运行的进程的身份标识是由 k8s service account (注11)与 RBAC 一起决定的。Istio 使用 istio-auth(注12),它使用双向 TLS 提供强大的服务间和最终用户身份验证,内置身份和凭证管理。Istio-auth 使用 k8s service account。

这些文档在解释其工作原理方面做得非常好,所以我只想在这里复制架构图的小图。详见这里。(注13)






 istio-auth架构的小图


Itsio 不提供任何使用 GCP service account 帮助。这还很早,但是它正在制定未来发展计划的路线图。

Istio-auth 很好,计划中的增强功能将值得等待。我对安全的复杂性感到厌烦,因为这不可避免地导致配置错误,所以我希望它与 service account 类型之间进行更加无缝的对齐!



网络控制


GKE(用于 K8S 版本1.7.6 +)使用 k8s网络策略(注14)来管理哪些 Pod 可以和服务通信。这是相对简单的配置。 Istio 也有网络策略,但他们不是你知道和喜欢的K8s策略,为什么会有这样的区别呢? 这篇文章(注15)很好地解释了这一点,所以我不会在这里重述,但是这个表格总结了不同之处以及为什么会有这样的不同。


项目 Istio策略 网络策略
层 Service(7层) Network(3、4层)
实现 Userspace Kernel
控制点 Pod Node

Istio 使用 envoy 作为 sidecar 代理。Envoy 在 OSI 模型的应用层运行,所以在第7层。我的这篇博客将为你详细解释。


你需要两种策略类型,这是纵深防御的方法。



多个集群

Istio 有个非常酷的功能是 mixer 适配器(注16)。简而言之,它可以从底层后端进行抽象以提供核心功能,例如日志记录、监控、配额、ACL 检查等。它公开了一个一致的 API,与使用的后端无关。就像 GCS 公开了一个 API,无论您使用什么存储类别!

我认为 mixer 适配器模型(注17)博客文章中的这张图片解释了 mixer 适配器中的全部要点。

有一个早期 demo(注18),我认为它是 Istio 最有用的特性之一,它实际上使用虚拟机来承载code lab 中使用的评分 dbase MySQL 数据库,并将其作为 GKE 集群所属网格的一部分。使用一个网格来管理它们!



流量管理

如果你使用了 codelab,你会看到使用 Istio 来引导使用路由规则的流量是多么容易。使用K8S,你还可以使用金丝雀部署进行流量管理,并以类似于 Istio 的方式将一定比例的流量引导至你应用的一个版本,但 Istio 在这种情况下更灵活,方法是允许你设置细粒度流量百分比并控制流量使用 code lab 中的其他标准。



服务发现

服务注册在 K8S 中完成。Istio 抽象出底层的服务发现机制,并将其转换为 envoy sidecar 可消费的标准格式。


审计记录和监控

如果是超出 GKE 提供的标准日志记录的话,可以将 GKE 与 StackDriver 日志记录(注19)集成来收集,在持久化存储中存储容器日志、系统日志和关于群集中的活动的事件,例如 Pod 的调度。还可以与 StackDriver Monitoring(注20)集成以收集系统度量指标(度量群集的基础设施,例如CPU或内存使用情况)和自定义指标(特定于应用程序的指标)。

 
Istio 利用 prometheus 与 grafana 一起作为仪表板进行记录和监控。我喜欢 service graph 配置(注21),它可以为你提供 service mesh 的图形表示。你也可以用 kibana 和 fluentd 来配合 Elasticsearch 使用。


那我需要Istio吗?

Istio 的流量管理非常棒,mixer 适配器模型可以轻松管理覆盖多个群集和虚拟机的网格。我喜欢 Istio 是因为它可以让你进中精力思考服务,而不是那么多的 pod 和节点,并不是说你不必担心这些,而是只关注服务就好了!


如果你需要管理一个分布式集群,那么 Istio 应该在你的选择列表里。如果您需要在流量管理方面有比 K8S 提供的更多的灵活性的化那么 Istio 也很值得关注。


如果你有足够的资源来处理处于发展早期的事物,那么尽早理解 Istio 是值得的。如果你已经在使用 K8S 的话那么 Istio 的学习曲线将很低。

记住它是一个建立在上层的东西,所以你仍然需要在 K8S 层做些事情,比如配置 K8S 网络策略来补充 Istio 网络策略。

Istio 还处于发展的早期阶段,所以它不会做你期望的所有事情,但我们希望它会。你将无法避免的在提供商 API 和 Istio 之间来回调用才能完成一个完整的工作,所以它不是你希望的那种一站式解决方案。


Dashboard 是可视化网格配置的一种很好的方式,因为编写 YAML 会让人很快疲惫!是的,你可以设置仪表板上的控制面板来可视化度量指标,但我希望看到它与 StackDriver 集成。


因此,在总体了解 Istio 之后,我实际上很喜欢它所承诺的内容。


注:

1、https://istio.io/

2、https://istio.io/docs/concepts ... .html

3、https://istio.io/docs/concepts ... .html

4、https://codelabs.developers.go ... /%230

5、https://istio.io/docs/concepts ... cture

6、https://istio.io/docs/concepts ... rules

7、https://cloud.google.com/kuber ... ation

8、https://cloud.google.com/kuber ... ntrol

9、https://istio.io/docs/concepts/security/rbac.html

10、https://cloud.google.com/kuber ... tform

11、https://kubernetes.io/docs/tas ... ount/

12、https://istio.io/docs/concepts ... .html

13、https://istio.io/docs/concepts ... .html

14、https://cloud.google.com/kuber ... olicy

15、https://istio.io/blog/2017/0.1 ... .html

16、https://istio.io/docs/concepts ... pters

17、https://istio.io/blog/2017/adapter-model.html

18、https://istio.io/docs/guides/integrating-vms.html

19、https://cloud.google.com/kuber ... gging

20、https://cloud.google.com/kuber ... oring

21、https://istio.io/docs/tasks/te ... .html



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,点击链接报名啦 查看全部
作者:Grace@grapesfrog

翻译:宋净超(Jimmy Song)

     Kubernetes、Cloud Native布道者、开源爱好者,个人博客https://jimmysong.io

原文:Istio why do I need it?



我最近没有多少时间去玩 K8S,并且我承认在 Istio 到底给 K8S 带来了什么这个问题上我有点迷失了。这是否会增加更多的运营开销?它是否简化了我们通常需要做的事情?这些问题都浮现在我的脑海里。

我怀疑在发布了这些内容之后,我团队中比我更懂 K8S 的人可能会想找我谈谈,估计我会跟团队中的成员辩论,但那将是我最喜欢的对话。


那么 Istio 究竟是什么?

Istio 网站(注1)上说:

Istio 带给你:
 
  • HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
  • 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
  • 支持访问控制、速率限制和配额的可拔插策略层和配置 API。
  • 自动指标、日志和集群内所有流量的跟踪,包括集群入口和出口。
  • 通过集群中的服务之间的强身份断言来实现服务间的身份验证。



通过在整个环境中部署一个特殊的 sidecar 代理(辅助容器),你可以将 Istio 支持添加到服务中(这给我留下了深刻的印象,如果你想做到这一点,请参阅后面的内容)。安装了 sidecar 代理之后,(微)服务之间的所有网络通信都通过这个代理。此外,所有的网络通信都是使用 Istio 的控制平面功能进行配置和管理的。


Istio 是 Service Mesh(服务网格)。我认为的 service mesh 定义就是“它是一个专用的基础设施层,使得服务间的通信安全、高效和可靠”。


然而,如果像我一样,你从概念文档(注2)开始看的话,上面有这样的内容:“术语 service mesh 通常用于描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的大小和复杂程度不断增加,可能会变得难以理解和管理。可能出现包括服务发现、负载平衡、故障恢复、度量和监控,以及更复杂的需求,如A/B测试、金丝雀发布、速率限制、访问控制和端到端身份验证。Istio 提供了一个完整的解决方案,通过对整个服务网格提供行为分析和操作控制来满足微服务应用程序的各种需求。“


读完之后你可能会像我一样困惑!最后在网上查了一圈关于什么是服务网格之后,我终于搞明白了。我最后使用的可能是一个在所有搜索到的样本里一个非代表性的共识,但这是一个合理的选择。不过有个细节确实了,就是如何将它与 K8S 等编排工具分开。Istio 需要跟 K8S一起使用,没有 K8S 或其他容器编排工具的它就不存在了吗?它没有做编排,实际上它的是为解决管理基于微服务的解决方案中网络和操作复杂性而设计的。它涵盖的范围就像K8S一样!现在我真的需要继续这个帖子了。

所以我知道 Istio 是什么,给我们带来了什么,但它实际上解决了什么挑战呢?


从为什么使用 Istio 页面中(注3)可以看出,它在服务网络中统一提供了许多关键功能:


流量管理
 
  • 可观察性
  • 强制策略
  • 服务身份标识和安全



对于我来说,要真正理解 Istio 的价值,所以我使用了 codelab(注四)。编写 code lab 的人真是太棒了!


Code lab 向我介绍了 Istio 控制平面的四个主要组件:
 
  • Pilot:处理代理 sidecar 的配置和编程。
  • Mixer:为你的流量处理决策并收集遥测数据。
  • Ingress:处理来自群集外部的传入请求。
  • CA:证书颁发机构。



查看 Istio 架构概念(注5)页面了解这些组件如何协同工作的。

Code lab提供了路由规则(注6)——流量管理部分

我还尝试了 Istio.io 中的一些 task,因为我需要了解它如何处理那些领域的工作。

提示:如果你在完成 codelab 时也决定在四处看看,那么请将你的群集与应用程序一起启动并运行。无论如何,你会再次使用它。

所以我对它如何解决这些问题有了一个基本的了解,但是如果我使用像 GKE 这样的东西来托管K8S(你知道我会选它不是吗?)使用 Istio 是否合适?


注意:是的,这里有更多的细节,但我主要想弄明白为什么需要使用 Istio。



集群最终用户/开发人员访问

GKE 结合使用 IAM(注7) 和 RBAC(注8),是的,这里面有很多东西需要你了解。

要为你的集群用户授予比 Cloud IAM 更细粒度的权限,你可以使用 namespace 和 RBAC 来限制对特定 pod 的访问或排除对 secret 的访问。

Istio RBAC (注9)介绍了两个侧重于服务的角色
 
  • ServiceRole 定义用于访问网格中的服务的角色。
  • ServiceRoleBinding 将角色授予主题(例如用户、组、服务)。


它们是 K8S 中的 CustomResourceDefinition(CRD)对象。但您仍然需要了解 IAM。


服务身份标识

GKE 可以使用 service account 来管理 GKE 上运行的应用程序(注10)可以使用哪些 GCP 服务。这些 service accout 的密钥使用 secret 存储。Pod 中运行的进程的身份标识是由 k8s service account (注11)与 RBAC 一起决定的。Istio 使用 istio-auth(注12),它使用双向 TLS 提供强大的服务间和最终用户身份验证,内置身份和凭证管理。Istio-auth 使用 k8s service account。

这些文档在解释其工作原理方面做得非常好,所以我只想在这里复制架构图的小图。详见这里。(注13)

微信图片_20180321102010.jpg


 istio-auth架构的小图


Itsio 不提供任何使用 GCP service account 帮助。这还很早,但是它正在制定未来发展计划的路线图。

Istio-auth 很好,计划中的增强功能将值得等待。我对安全的复杂性感到厌烦,因为这不可避免地导致配置错误,所以我希望它与 service account 类型之间进行更加无缝的对齐!



网络控制


GKE(用于 K8S 版本1.7.6 +)使用 k8s网络策略(注14)来管理哪些 Pod 可以和服务通信。这是相对简单的配置。 Istio 也有网络策略,但他们不是你知道和喜欢的K8s策略,为什么会有这样的区别呢? 这篇文章(注15)很好地解释了这一点,所以我不会在这里重述,但是这个表格总结了不同之处以及为什么会有这样的不同。


项目 Istio策略 网络策略
层 Service(7层) Network(3、4层)
实现 Userspace Kernel
控制点 Pod Node

Istio 使用 envoy 作为 sidecar 代理。Envoy 在 OSI 模型的应用层运行,所以在第7层。我的这篇博客将为你详细解释。


你需要两种策略类型,这是纵深防御的方法。



多个集群

Istio 有个非常酷的功能是 mixer 适配器(注16)。简而言之,它可以从底层后端进行抽象以提供核心功能,例如日志记录、监控、配额、ACL 检查等。它公开了一个一致的 API,与使用的后端无关。就像 GCS 公开了一个 API,无论您使用什么存储类别!

我认为 mixer 适配器模型(注17)博客文章中的这张图片解释了 mixer 适配器中的全部要点。

有一个早期 demo(注18),我认为它是 Istio 最有用的特性之一,它实际上使用虚拟机来承载code lab 中使用的评分 dbase MySQL 数据库,并将其作为 GKE 集群所属网格的一部分。使用一个网格来管理它们!



流量管理

如果你使用了 codelab,你会看到使用 Istio 来引导使用路由规则的流量是多么容易。使用K8S,你还可以使用金丝雀部署进行流量管理,并以类似于 Istio 的方式将一定比例的流量引导至你应用的一个版本,但 Istio 在这种情况下更灵活,方法是允许你设置细粒度流量百分比并控制流量使用 code lab 中的其他标准。



服务发现

服务注册在 K8S 中完成。Istio 抽象出底层的服务发现机制,并将其转换为 envoy sidecar 可消费的标准格式。


审计记录和监控

如果是超出 GKE 提供的标准日志记录的话,可以将 GKE 与 StackDriver 日志记录(注19)集成来收集,在持久化存储中存储容器日志、系统日志和关于群集中的活动的事件,例如 Pod 的调度。还可以与 StackDriver Monitoring(注20)集成以收集系统度量指标(度量群集的基础设施,例如CPU或内存使用情况)和自定义指标(特定于应用程序的指标)。

 
Istio 利用 prometheus 与 grafana 一起作为仪表板进行记录和监控。我喜欢 service graph 配置(注21),它可以为你提供 service mesh 的图形表示。你也可以用 kibana 和 fluentd 来配合 Elasticsearch 使用。


那我需要Istio吗?

Istio 的流量管理非常棒,mixer 适配器模型可以轻松管理覆盖多个群集和虚拟机的网格。我喜欢 Istio 是因为它可以让你进中精力思考服务,而不是那么多的 pod 和节点,并不是说你不必担心这些,而是只关注服务就好了!


如果你需要管理一个分布式集群,那么 Istio 应该在你的选择列表里。如果您需要在流量管理方面有比 K8S 提供的更多的灵活性的化那么 Istio 也很值得关注。


如果你有足够的资源来处理处于发展早期的事物,那么尽早理解 Istio 是值得的。如果你已经在使用 K8S 的话那么 Istio 的学习曲线将很低。

记住它是一个建立在上层的东西,所以你仍然需要在 K8S 层做些事情,比如配置 K8S 网络策略来补充 Istio 网络策略。

Istio 还处于发展的早期阶段,所以它不会做你期望的所有事情,但我们希望它会。你将无法避免的在提供商 API 和 Istio 之间来回调用才能完成一个完整的工作,所以它不是你希望的那种一站式解决方案。


Dashboard 是可视化网格配置的一种很好的方式,因为编写 YAML 会让人很快疲惫!是的,你可以设置仪表板上的控制面板来可视化度量指标,但我希望看到它与 StackDriver 集成。


因此,在总体了解 Istio 之后,我实际上很喜欢它所承诺的内容。


注:

1、https://istio.io/

2、https://istio.io/docs/concepts ... .html

3、https://istio.io/docs/concepts ... .html

4、https://codelabs.developers.go ... /%230

5、https://istio.io/docs/concepts ... cture

6、https://istio.io/docs/concepts ... rules

7、https://cloud.google.com/kuber ... ation

8、https://cloud.google.com/kuber ... ntrol

9、https://istio.io/docs/concepts/security/rbac.html

10、https://cloud.google.com/kuber ... tform

11、https://kubernetes.io/docs/tas ... ount/

12、https://istio.io/docs/concepts ... .html

13、https://istio.io/docs/concepts ... .html

14、https://cloud.google.com/kuber ... olicy

15、https://istio.io/blog/2017/0.1 ... .html

16、https://istio.io/docs/concepts ... pters

17、https://istio.io/blog/2017/adapter-model.html

18、https://istio.io/docs/guides/integrating-vms.html

19、https://cloud.google.com/kuber ... gging

20、https://cloud.google.com/kuber ... oring

21、https://istio.io/docs/tasks/te ... .html



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,点击链接报名啦

Service Mesh深度思考 | DreamMesh抛砖引玉(1)-序言

ServiceMesh小数 发表了文章 • 0 个评论 • 715 次浏览 • 2018-03-20 10:21 • 来自相关话题

 作者:
       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。博客链接:https://skyao.io



小数话:今天为大家整理了小剑老师的 Dream Mesh 系列文章,在之后的时间里,我们会依次为大家发送,对于该系列有兴趣的朋友,欢迎加入 service mesh 交流群(添加小数微信:xiaoshu062,备注:服务网格,即可),和小剑老师一起讨论关于 Dream Mesh 的相关内容~



前言

相信能看到这篇博客的同学,大体都知道过去几个月间,我在努力地研究 Service Mesh 并致力于在国内拓荒和布道。

坦言说:Service Mesh 的发展进程,当前还处于前景虽然一致看好,但是脚下的路还处于需要一步一步走的早期艰难阶段。由于 Istio 和 Conduit 的尚未成熟,造成目前 Service Mesh 青黄不接的尴尬局面。

近期在和很多朋友交流,也都谈到这个话题,着实有些无奈,只能静静的等待 Istio 和 Cconduit 的发展。好在这两个产品也很争气,近期都快速发出了新版本。


小编注:目前 Istio 是0.6版本(中文技术文档http://istio.doczh.cn/), Conduit 是 0.3.1版本(中文技术文档http://conduit.doczh.cn/)


然而 Service Mesh 的现状,它的不够成熟,终究还是引发了猜疑,不安和观望。







Doubt kills more dreams than failure ever has.

在猎鹰升空,马斯克“封神”的那周,我更能深刻体会这句话的内涵。



正视问题

过去的一个月间,我一直在认真的思考这样一个问题:

Service Mesh 真的能完美解决问题吗?

这里我们抛开前面所说的 Istio 或者 Conduit 暂未成熟的情况,毕竟在不远的未来即将可以被解决,不出意外会在2018年年中或者年底。


让我们设想:如果明天 Istio 或者 Conduit 发布出 Production Ready 的版本,是不是我们就可以欢欣鼓舞的直接将系统搬迁到 Service Mesh 上?


还差点什么?


我将会在稍后的系列文章中将我思考的问题逐个列出来,暂时会有下列内容:


1. Ready for Cloud Native?

我对 Service Mesh 的第一个担忧,来自 Cloud Native。

作为 Cloud Native 的忠实拥护者,我不怀疑 Cloud Native 的价值和前景。但是,我担心的是:准备上 Service Mesh 的各位,是否都已经做到了Ready for Cloud Native?


2. 如何从非 Service Mesh 体系过渡到 Service Mesh?

即使一切都 Ready,对于一个有存量应用的系统而言,绝无可能在一夜之间就将所有应用都改为 Service Mesh,然后一起上线。


必然会有一个中间过渡状态,一部分应用开始搬迁到 Service Mesh,大部分还停留在原有体系。那么,如何在过渡阶段让 Service Mesh 内的服务和Service Mesh 外的服务相互通讯?


3. 零侵入的代价

Service Mesh的一个突出优点就是对应用的侵入度非常低,低到可以”零侵入”。

然而,没有任何事情是可以十全十美的,零侵入带来的弊端:iptables 一刀切的方案有滥用嫌疑,为了不劫持某些网络访问又不得不增加配置去绕开。

是否考虑补充一个低侵入的方案?



4. 网络通讯方案

Service Mesh 解决服务间通讯的方式是基于网络层,HTTP1.1/HTTP2 和可能的 TCP,对于选择什么样的序列化方案和远程访问方案并未限制。

好处是我们可以自由的选择各种方案,坏处就是自由意味着自己做。

能否以类库或者最佳实践的方式给出适合 Service Mesh 时代的网络通讯方案?



5. 性能开销

我们反复谈到,Service Mesh 的核心在于将原有以类库方式提供的功能拆分到独立的 sidecar 进程中,以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处,但是这对性能会有什么影响?


6. 绕不开的Spring

对于 Java 企业应用,Spring 是无论如何绕不开的。然而目前我们没有看到Spring社区对 Service Mesh 的任何回应。因此,如何以正确的姿势在 Service Mesh 时代使用 Spring,需要自己探索。

理论上说,springboot on service mesh 有可能成为一个清爽的解决方案。然后路终究是要走一遍才知道是不是那么美好。



7. Spring Cloud 迁移之路

虽然 Service Mesh 号称下一代微服务,取代 Spring Cloud 是 Service Mesh 与生俱来的天然目标之一。

但是以目前市场形式,Spring Cloud 在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到 Service Mesh 之前加强 Spring Cloud,并为将来转入 Service Mesh 铺路,是一个艰难而极具价值的话题。



8. API gateway

Service Mesh 解决的是东西向服务间通讯的问题,我们来审视一下 API gateway 到微服务之间的南北向通讯: 服务发现,负载均衡,路由,灰度,安全,认证,加密,限流,熔断……几乎大部分的主要功能,在这两个方向上都高度重叠。


因此,是否该考虑提供一个统一的解决方案来处理?



9. 多集群/多机房的支持


如果有多集群/多机房的支持需求,该如何解决?

这个问题和前面列出的 service mesh 体系和非 service mesh 的并存问题,可能叠加:如何在多集群/多机房要求下实现 service mesh 体系和非 service mesh 的并存。


TBD:更多想法将稍后逐步列出,也欢迎在微信群中补充。



Dream Mesh

在经过一个月的冥思苦想和深度思考之后,我对上面列出的问题大致有了一些初步的想法和思路。


我个人心中理想的 Service Mesh 解决方案,希望是可以在 Istio 或者 Conduit 的基础上,进一步的扩展和完善,解决或者规避上述问题。


终极目标:让 Service Mesh 能够更加平稳的在普通企业落地。


这个美好的愿景,目前还只停留在我的脑海中,如梦境一般虚幻,又如梦境一般令人向往。

所以我将这个思路和解决方案,统称为”Dream Mesh“。

坦言说:Dream Mesh想法比较超前,规划也有点庞大,兼具高层架构和底层实现,极富挑战。

再一次用这张图片为自己打气,同时感谢太平洋对岸的埃隆·马斯克在这个关键的时间点上给了我更多的勇气。

诚邀在将 Dream Mesh 的规划和架构正式呈现出来之前,我会陆续将我目前的所思所想以文字的形式发表在我的博客上,然后会发起几轮内部讨论。之后修订/补充/完善,希望在四五月份的时候能给出一个成型的方案。

我真诚的邀请对此感兴趣的朋友参与讨论和交流,我会在近期陆续将我的想法和设想抛出来,希望能引出大家的更多更好的思路,正所谓:抛砖引玉。

没有什么事情是可以一个人闭门造车而独自琢磨出来的。

有兴趣参与讨论的同学,请直接在微信上联系小数:xiaoshu062,加入Service Mesh 交流群讨论。

十分期待。



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,点击链接报名啦
  查看全部

1.jpg

 作者:
       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。博客链接:https://skyao.io



小数话:今天为大家整理了小剑老师的 Dream Mesh 系列文章,在之后的时间里,我们会依次为大家发送,对于该系列有兴趣的朋友,欢迎加入 service mesh 交流群(添加小数微信:xiaoshu062,备注:服务网格,即可),和小剑老师一起讨论关于 Dream Mesh 的相关内容~



前言

相信能看到这篇博客的同学,大体都知道过去几个月间,我在努力地研究 Service Mesh 并致力于在国内拓荒和布道。

坦言说:Service Mesh 的发展进程,当前还处于前景虽然一致看好,但是脚下的路还处于需要一步一步走的早期艰难阶段。由于 Istio 和 Conduit 的尚未成熟,造成目前 Service Mesh 青黄不接的尴尬局面。

近期在和很多朋友交流,也都谈到这个话题,着实有些无奈,只能静静的等待 Istio 和 Cconduit 的发展。好在这两个产品也很争气,近期都快速发出了新版本。


小编注:目前 Istio 是0.6版本(中文技术文档http://istio.doczh.cn/), Conduit 是 0.3.1版本(中文技术文档http://conduit.doczh.cn/


然而 Service Mesh 的现状,它的不够成熟,终究还是引发了猜疑,不安和观望。


1.jpg


Doubt kills more dreams than failure ever has.

在猎鹰升空,马斯克“封神”的那周,我更能深刻体会这句话的内涵。



正视问题

过去的一个月间,我一直在认真的思考这样一个问题:

Service Mesh 真的能完美解决问题吗?

这里我们抛开前面所说的 Istio 或者 Conduit 暂未成熟的情况,毕竟在不远的未来即将可以被解决,不出意外会在2018年年中或者年底。


让我们设想:如果明天 Istio 或者 Conduit 发布出 Production Ready 的版本,是不是我们就可以欢欣鼓舞的直接将系统搬迁到 Service Mesh 上?


还差点什么?


我将会在稍后的系列文章中将我思考的问题逐个列出来,暂时会有下列内容:


1. Ready for Cloud Native?

我对 Service Mesh 的第一个担忧,来自 Cloud Native。

作为 Cloud Native 的忠实拥护者,我不怀疑 Cloud Native 的价值和前景。但是,我担心的是:准备上 Service Mesh 的各位,是否都已经做到了Ready for Cloud Native?


2. 如何从非 Service Mesh 体系过渡到 Service Mesh?

即使一切都 Ready,对于一个有存量应用的系统而言,绝无可能在一夜之间就将所有应用都改为 Service Mesh,然后一起上线。


必然会有一个中间过渡状态,一部分应用开始搬迁到 Service Mesh,大部分还停留在原有体系。那么,如何在过渡阶段让 Service Mesh 内的服务和Service Mesh 外的服务相互通讯?


3. 零侵入的代价

Service Mesh的一个突出优点就是对应用的侵入度非常低,低到可以”零侵入”。

然而,没有任何事情是可以十全十美的,零侵入带来的弊端:iptables 一刀切的方案有滥用嫌疑,为了不劫持某些网络访问又不得不增加配置去绕开。

是否考虑补充一个低侵入的方案?



4. 网络通讯方案

Service Mesh 解决服务间通讯的方式是基于网络层,HTTP1.1/HTTP2 和可能的 TCP,对于选择什么样的序列化方案和远程访问方案并未限制。

好处是我们可以自由的选择各种方案,坏处就是自由意味着自己做。

能否以类库或者最佳实践的方式给出适合 Service Mesh 时代的网络通讯方案?



5. 性能开销

我们反复谈到,Service Mesh 的核心在于将原有以类库方式提供的功能拆分到独立的 sidecar 进程中,以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处,但是这对性能会有什么影响?


6. 绕不开的Spring

对于 Java 企业应用,Spring 是无论如何绕不开的。然而目前我们没有看到Spring社区对 Service Mesh 的任何回应。因此,如何以正确的姿势在 Service Mesh 时代使用 Spring,需要自己探索。

理论上说,springboot on service mesh 有可能成为一个清爽的解决方案。然后路终究是要走一遍才知道是不是那么美好。



7. Spring Cloud 迁移之路

虽然 Service Mesh 号称下一代微服务,取代 Spring Cloud 是 Service Mesh 与生俱来的天然目标之一。

但是以目前市场形式,Spring Cloud 在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到 Service Mesh 之前加强 Spring Cloud,并为将来转入 Service Mesh 铺路,是一个艰难而极具价值的话题。



8. API gateway

Service Mesh 解决的是东西向服务间通讯的问题,我们来审视一下 API gateway 到微服务之间的南北向通讯: 服务发现,负载均衡,路由,灰度,安全,认证,加密,限流,熔断……几乎大部分的主要功能,在这两个方向上都高度重叠。


因此,是否该考虑提供一个统一的解决方案来处理?



9. 多集群/多机房的支持


如果有多集群/多机房的支持需求,该如何解决?

这个问题和前面列出的 service mesh 体系和非 service mesh 的并存问题,可能叠加:如何在多集群/多机房要求下实现 service mesh 体系和非 service mesh 的并存。


TBD:更多想法将稍后逐步列出,也欢迎在微信群中补充。



Dream Mesh

在经过一个月的冥思苦想和深度思考之后,我对上面列出的问题大致有了一些初步的想法和思路。


我个人心中理想的 Service Mesh 解决方案,希望是可以在 Istio 或者 Conduit 的基础上,进一步的扩展和完善,解决或者规避上述问题。


终极目标:让 Service Mesh 能够更加平稳的在普通企业落地。


这个美好的愿景,目前还只停留在我的脑海中,如梦境一般虚幻,又如梦境一般令人向往。

所以我将这个思路和解决方案,统称为”Dream Mesh“。

坦言说:Dream Mesh想法比较超前,规划也有点庞大,兼具高层架构和底层实现,极富挑战。

再一次用这张图片为自己打气,同时感谢太平洋对岸的埃隆·马斯克在这个关键的时间点上给了我更多的勇气。

诚邀在将 Dream Mesh 的规划和架构正式呈现出来之前,我会陆续将我目前的所思所想以文字的形式发表在我的博客上,然后会发起几轮内部讨论。之后修订/补充/完善,希望在四五月份的时候能给出一个成型的方案。

我真诚的邀请对此感兴趣的朋友参与讨论和交流,我会在近期陆续将我的想法和设想抛出来,希望能引出大家的更多更好的思路,正所谓:抛砖引玉。

没有什么事情是可以一个人闭门造车而独自琢磨出来的。

有兴趣参与讨论的同学,请直接在微信上联系小数:xiaoshu062,加入Service Mesh 交流群讨论。

十分期待。



社区活动:

3月31日(周六),数人云联合ServiceComb社区,并由ServiceMesh社区支持,开启meetup系列活动 Building Microservice 第2期 北京站 :微服务,从架构到发布,已经开始报名啦,点击链接报名啦