使用 Istio Service Mesh 管理微服务

使用Istio Service Mash管理微服务

今天的文章经过Istio开源项目展现如何为Kubernetes管理的微服务提供可见性,弹性,安全性和控制。 html

服务是现代软件体系结构的核心。比起复杂庞大的总体,部署一系列模块化的小型(微型)服务可以使开发人员灵活地使用不一样的语言、技术并能放缓节奏,并会有更高的生产力和更快的速度,特别是对于大团队,效果会更好。然而,随着微服务的采用,因为大型系统中存在大量的服务,就会出现新的问题,那就须要为每一个服务处理一个复杂的问题,例如安全性,负载平衡,监控和速率限制。 node

Kubernetes和服务

Kubernetes 经过 Service 构造支持微服务架构。它容许开发人员将一组 Pod 的功能抽象出来,并经过定义良好的 API 将其展现给其余开发人员。它容许为这个抽象级别添加一个名称,并执行基本的L4负载平衡。可是它不能解决更高层次的问题,好比 L7 指标,流量分流,速率限制,断路等。 git

Istio团队在 GlueCon 2017大会上宣布,借助 Istio 经过 Service Mesh 框架从根本上解决了这些问题。开发人员能够实现微服务的核心逻辑,并让框架负责剩下的部分,如流量管理、服务发现、服务标识和安全以及策略实施。更好的是,对于现有的微服务,也能够这样作,而不用重写或从新编译它们的任何部分。Istio 使用 Envoy 做为其运行时代理组件,并提供一个容许全球跨领域政策执行和遥测收集的可扩展的中介层github

当前版本的Istio是面向Kubernetes用户的,而且能够经过几行命令的安装方式进行打包,从而为Kubernetes中的微服务提供可视性,弹性,安全性和控制力。json

在文章中,咱们将看到由4个独立的微服务组成的简单应用程序。咱们首先看看如何使用普通的Kubernetes部署应用程序。而后,咱们将在不改变任何应用程序代码的状况下将彻底相同的服务部署到Istio的群集中启用,并了解下咱们该如何观察指标。 后端

在后面的文章中,咱们将重点介绍更高级的功能,如HTTP请求路由,策略,身份和安全管理。api

示例应用程序:BookInfo

咱们将使用一个简单的应用程序 BookInfo ,显示商店书籍的信息,评论和评分。该应用程序由四个以不一样语言编写的微服务组成: 浏览器

<img src="1.png"/>安全

由于这些微服务的容器镜像均可以在 Docker Hub 中找到,因此咱们在Kubernetes中部署这个应用程序须要的就是 yaml 配置。
值得注意的是,这些服务对 Kubernetes 和 Istio 没有依赖关系,但作了一个有趣的案例研究。特别是评论服务的众多服务,语言和版本使其成为一个有趣的 Service Mesh 示例。关于这个 例子 的更多信息能够在这里找到。 服务器

在Kubernetes中运行Bookinfo应用程序

在这篇文章中,咱们将重点介绍应用的v1版本:

<img src="2.png"/>

使用Kubernetes进行部署很是简单,与部署其余服务无异。productpage 微服务的服务和部署资源以下所示:

apiVersion: v1
kind: Service
metadata:
 name: productpage
 labels:
   app: productpage
spec:
 type: NodePort
 ports:
 - port: 9080
   name: http
 selector:
   app: productpage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: productpage-v1
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: productpage
       track: stable
   spec:
     containers:
     - name: productpage
       image: istio/examples-bookinfo-productpage-v1
       imagePullPolicy: IfNotPresent
       ports:
       - containerPort: 9080

若是咱们想运行应用程序,咱们须要部署的另外两个服务是详细信息和评论 v1 。咱们目前不须要部署评级服务,由于评论服务 v1 不会使用它。其他的服务基本上与 productpage 遵循相同的模式。全部服务的yaml文件能够在这里 找到。

做为一个普通的Kubernetes应用程序运行服务:

kubectl apply -f bookinfo-v1.yaml

要从咱们须要的NodePort地址的群集外部访问应用程序productpage服务

export BOOKINFO_URL=$(kubectl get po -l app=productpage -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc productpage -o jsonpath={.spec.ports[0].nodePort})

咱们如今能够将浏览器指向http:// $ BOOKINFO_URL / productpage,并查看:

<img src="3.png"/>

使用 Istio 运行 Bookinfo 应用程序

如今咱们已经看到了这个应用程序,咱们稍微调整一下咱们的部署,使其与Istio一块儿工做。 咱们首先须要在咱们的集群中安装Istio 。要查想看全部的指标和启用追踪功能,咱们还能够安装可选的 Prometheus , Grafana 和 Zipkin 插件。 咱们如今能够删除之前的应用程序,并使用彻底相同的 yaml 文件再次启动 Bookinfo 应用程序,此次是 Istio :

kubectl delete -f bookinfo-v1.yaml
kubectl apply -f <(istioctl kube-inject -f bookinfo-v1.yaml)

须要注意,此次在建立部署以前咱们使用 istioctl kube-inject 命令修改bookinfo-v1.yaml 文件。在这里 它记录注入 Envoy sidecar 到 Kubernetes pods 。所以,全部微服务都与Envoy sidecar 一块儿打包,管理服务的传入和传出流量

在Istio服务网格中,就像在普通的 Kubernetes 中同样,咱们不会直接访问应用程序productpage,相反,咱们但愿在请求路径中使用 Envoy sidecar ,就像咱们处理内部请求同样,以便咱们可使用 Istio 的管理功能(版本路由,断路器,策略等)来控制对 productpage 的外部调用。Istio 的 Ingress 控制器便用于此目的。

要使用 Istio Ingress控制器,咱们须要为应用程序建立一个 Kubernetes Ingress 资源,并用 kubernetes.io/ingress.class 注释:“istio”,以下所示:

cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: bookinfo
 annotations:
   kubernetes.io/ingress.class: "istio"
spec:
 rules:
 - http:
     paths:
     - path: /productpage
       backend:
         serviceName: productpage
         servicePort: 9080
     - path: /login
       backend:
         serviceName: productpage
         servicePort: 9080
     - path: /logout
       backend:
         serviceName: productpage
         servicePort: 9080
EOF

Istio 和 Bookinfo app 的v1版本的结果部署以下所示:

<img src="4.png">

此次咱们将使用 Istio Ingress 控制器的 NodePort 地址访问应用程序:

export BOOKINFO_URL=$(kubectl get po -l istio=ingress -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc istio-ingress -o jsonpath={.spec.ports[0].nodePort})

如今咱们能够在 http:// $ BOOKINFO_URL / productpage 上看到页面,并再次看到正在运行的应用程序,并且与没有使用 Istio 的用户先前部署的应用应该没有什么不一样。可是,如今应用程序正在 Istio 服务网格中运行,咱们能够当即开始看到一些好处。

指标集合

咱们从 Istio 开箱便可获得的第一件事就是在 Prometheus 中收集指标。这些指标由 Envoy 中的 Istio 过滤器生成,根据默认规则(能够自定义)收集,而后发送给 Prometheus 。指标能够在 Grafana 的 Istio 视图中可视化。请注意,尽管 Prometheus 是现成的默认指标后端,但 Istio 容许您使用其余的,咱们将在之后的博客文章中演示。

为了演示,咱们将开始运行如下命令来在应用程序上生成一些负载:

wrk -t1 -c1 -d20s http:// $ BOOKINFO_URL / productpage

咱们得到 Grafana 的 NodePort URL:

export GRAFANA_URL=$(kubectl get po -l app=grafana -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc grafana -o jsonpath={.spec.ports[0].nodePort})

咱们如今能够在浏览器打开 http:// $ GRAFANA_URL / dashboard / db / istio-dashboard ,并检查每一个 Bookinfo 服务的各类性能指标:

<img src="5.png"/>

分布式跟踪

咱们从Istio得到的下一个功能是使用Zipkin进行跟踪。咱们得到它的NodePort URL:

export ZIPKIN_URL=$(kubectl get po -l app=zipkin -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc zipkin -o jsonpath={.spec.ports[0].nodePort})

如今咱们能够经过浏览器打开 http:// $ ZIPKIN_URL / 来查看经过Bookinfo服务的请求跨度跟踪。

<img src="6.png">

尽管 Envoy 代理将跟踪跨度发送到 Zipkin 开箱即用,为了充分利用其功能,应用程序须要 Zipkin 获取到并转发一些头部以将各个跨度绑定在一块儿。有关详细信息,请参阅zipkin-tracing

指标总体总结

Istio 提供的指标不只仅是一种便利。它们经过生成统一的度量标准来提供服务网格的一致视图。咱们没必要担忧协调各类代理运行时发出的不一样类型的指标,或者添加任意代理来收集传统的未配置的应用程序的指标。咱们也再也不须要依靠开发过程来正确地测试应用程序来生成度量标准。服务网格能够查看全部流量,甚至能够查看传统的“黑匣子”服务,并生成全部流量的度量标准。

概要

Google ,IBM 和 Lyft 自豪地宣布 Istio :一个开源项目,提供统一的链接,安全,管理和监控微服务的方。 目前的版本针对Kubernetes环境; 打算在将来几个月内为虚拟机和Cloud Foundry等其余环境增长支持。 Istio将流量管理添加到微服务中,并为增值功能(如安全性,监控,路由,链接管理和策略)创造了基础。 该软件使用来自Lyft的通过测试的特使代理构建,并提供对流量的可见性和控制,而不须要对应用程序代码进行任何更改。 Istio为CIO提供了强大的工具,能够在整个企业中实施安全性,政策和合规性要求。

做者:靳日阳,JFrog 研发工程师

具备多年软件开发经验;对Java主流技术、前沿框架都具备丰富的开发经验;擅长Linux服务器,对优化,部署等有深刻研究,熟悉Jenkins,持续集成及交付,DevOps等。欢迎转载,但转载请注明做者与出处。谢谢!