基于Consul服务发现的istio

由于业务微服务先前的架构大量使用consul来做服务注册与发现,但是istio主流的方案中,业务还是走k8s基于DNS的服务发现。正好看到istio社区也号称能够基于consul;因此,基于consul做了一些POC,主要情况简单介绍一下。

现状与需求

当前业务方新开发的服务运行到k8s上,另外有一些旧服务运行在VM中(VM网络与办公网络三层可达,存在接口被人随意调用的风险)。希望能够降低服务部署的复杂度,同时当存在异常或瓶颈的时候能够快速感知到异常,定位问题。

因此,其服务治理的目标也比较明确:

  1. 网络安全,不允许接口被随意调用;
  2. VM+k8s容器通过一套平台,集中治理;
  3. 流量管控,需要做服务的蓝绿部署和灰度发布
  4. 可视化,监控。

大体分析一下:

  • 从功能方面来看

    基于istio的宣传,乍一看,以上功能都能够cover住。但是这里面仍存在风险点,比如VM+K8S融合部署、集中管控;基于consul的服务注册等。虽然社区号称istio具备这些能力,但是却未在这些点上深度发力(从发布包中可以看到主流方向还是基于纯k8s方向)。

  • 从服务注册方面来看

    假设使用consul作为服务发现工具,那么就相当于将vm和k8s pod都拉平来对待,似乎是一个方向。另一方面,现有服务已经在使用spring cloud + consul注册的机制,如果继续使用consul的话,现有代码不需要再做修改。

    另外,社区号称istio对consul服务发现的支持还不错,且在其release包中,自带了对应的安装部署的docker-compose文件。

所以,我决定重点POC一把基于consul做服务发现的istio的情况。

系统架构

基于Consul服务发现的istio

其架构如上图所示,各个微服务的功能如下:

  • api-server
    与后端的Etcd负责整个istio的配置持久化;
  • registrator
    负责监听主机上的docker daemon,一旦有container创建或者销毁就按照其label将其注册到consul,从而供pilot做发现;
  • pilot
    负责各个envoy的流量管控配置生成与下发;
  • zipkin
    收集各envoy上报的trace信息,并对外展示。

安装部署

涉及istio部署和示例服务bookinfo的部署。

istio部署

部署这块,相对来讲比较简单,其发布包里面自带了基于consul部署的docker-compose.yaml。里面的api-server版本都较旧,也说明了社区未在这方面有所更新,这里重点要说下遇到的对应问题以及其更改方法。

docker-compose.yaml 文件内容如下:

version: '2'
services:
  etcd:
    ......

  istio-apiserver:
    # 更改为当前最新版本的api-server
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.14.1 
    networks:
      istiomesh:
        ipv4_address: 172.28.0.13
        aliases:
          - apiserver
    ports:
      - "8080:8080"
    privileged: true
    environment:
      - SERVICE_IGNORE=1
    command: ["kube-apiserver", "--etcd-servers", "http://etcd:2379", "--service-cluster-ip-range", "10.99.0.0/16", "--insecure-port", "8080", "-v", "2", "--insecure-bind-address", "0.0.0.0"]

  consul:
    ......

  registrator:
    # 更新版本为master
    image: gliderlabs/registrator:master  
    networks:
      istiomesh:
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
    command: ["-internal", "-retry-attempts=-1", "consul://consul:8500"]

  pilot:
    ......

  zipkin:
    ......

如上文所注释,这里需要修改几个地方:

  1. 由于自带的api-server版本太老,部署的时候会出现一些问题,直接使用最新版本就行了;
  2. registrator的latest版本无法注册协议到consul的service meta中,需要更改为master版本;
  3. 另外,第一次运行由于api-server未能够先ready,pilot会挂掉,只需要重启一次就行了。

应用部署

[root@vm-1 consul]# pwd
/root/istio-1.1.6/samples/bookinfo/platform/consul
[root@vm-1 consul]# ls
bookinfo.sidecars.yaml  destination-rule-all.yaml    virtual-service-ratings-test-abort.yaml  virtual-service-reviews-test-v2.yaml
bookinfo.yaml           README.md                    virtual-service-ratings-test-delay.yaml  virtual-service-reviews-v2-v3.yaml
cleanup.sh              virtual-service-all-v1.yaml  virtual-service-reviews-50-v3.yaml       virtual-service-reviews-v3.yaml

相信看到这里,大家都明白为啥k8s是主流方向了。这里示例代码中每一个服务的运行实例都需要再手动部署一个sidecar,想想k8s上自动注入的便捷性,突然感觉回到了解放前。

运行起来之后,可以在consul看到下列服务;当然,consul的UI上面未能够展现出所有的tags信息。

基于Consul服务发现的istio

通过简单的访问productpage之后,我们可以在zipkin上看到对应的调用链信息视图。

基于Consul服务发现的istio

如果这过程中某些配置不正确,可以查看对应envoy的配置信息,基本就是进入到envoy对应的network namespace去执行 curl localhost:15000/help 获取各种配置信息(这块在上一篇中有具体的介绍,这里不再详说)。

关于部署就讲这么多,主要是通过这样一个过程让我们对基于consul服务发现的istio有一个更加直观的认识。下面我们就来吐槽!

原文 

http://ljchen.net/2019/06/02/基于consul服务发现的istio/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 基于Consul服务发现的istio

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址