首页 » 漏洞 » 使用Istio服务网格管理微服务

使用Istio服务网格管理微服务

 

今天的帖子由Istio团队展示如何为kubertnetes 的微服务提供可视化,弹性,安全和控制功能

服务化是现代软件架构的核心。部署一系列模块化的小型服务而非庞大的单体应用,可以给开发者更大的灵活性。开发者对不同模块可以使用不同的技术,不同的语言采用不同的版本,以实现更高的效率和速度,这一点对大型开发尤为重要。

采用微服务,新问题也随之而来。因为大型系统中会包含大量微服务。独立应用需要面对的问题,例如安全,负载均衡,监控,请求频率限定等在每个服务中都需要处理。

Kubernetes和服务

Kubernetes 通过服务构建支持微服务架构。 它允许开发者抽象出一系列的豆荚(pod),然后通过定义好的API 开放给其他开发者。它允许在这层抽象上赋予服务一个名字同时执行4层基础负载均衡。但它并不能解决高级问题,例如7层上的metrics,请求频率限定,通信分流,回路中断等等。

刚刚在gluecon 2017上发布的Istio,在根本上解决了这些问题。通过Istio, 开发者可以专注于微服务的核心逻辑,而让框架负责其他- 通信管理,服务发现,服务认证,安全和策略强化。更好的是,这些可以直接加到已有的微服务上而不必重写或重新编译。 Istio使用envoy 作为运行代理模块,提供可扩展的中间层,可以允许跨服务的策略实施和遥测metrics采集。

当前的Istio版本专门针对kubernets 用户,只需要安装几行代码就可以使kubernets微服务即刻获得可视化,弹性,安全管理和控制功能。

我们会在一系列的博客帖子中,讲解由四个微服务组成的简单应用。先来看怎样用单纯的kubernetes 来部署应用。接下来将要把同样的服务部署到Istio 集群而不需要更改任何应用代码,同时提供metrics。

在接下来的帖子中,我们会更关注更先进的功能例如HTTP 请求路由,策略,认证和安全管理。

应用范例: Bookinfo

Bookinfo是一个简单应用,其功能包括展示信息,检查和评价书店的书籍。这个应用由不同语言编写的4个微服务组成。

这些容器镜像都可以在Docker Hub上找到,在kubernetes上部署只需要配置yaml就可以了。

值得一提的是这些微服务并不依赖于kubernets 和Istio。 这些服务的数量,语言和版本的多样性使之成为一个理想的服务网格范例。

在kubernets 中运行Bookinfo

我们先关注这个应用的第一个版本

用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

另外两个微服务是Details 和 reviews-v1,使用productpage 同样的方式部署。 Ratings服务则暂时无需部署。

作为普通kubernets app 运行微服务:

kubectl apply -f bookinfo-v1.yaml

如果要从外部集群访问应用,需要提供productpage服务的Nodeport地址:

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

使用Istio 运行Bookinfo应用

现在稍微调整一下部署,把Istio用上。首先在集群中安装Istio,然后再安装Prometheus, Grafana, 和Zipkin. 我们现在可以把之前的版本删掉,用同样的yaml配置文件重启应用,不过加上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 加入到kubernets pod.最终结果就是微服务和Envoy sidecar打包在一起并管理整个服务的通信。

在Istio网格服务中不是直接访问应用,而是通过在访问路径中加入Envoy sideca,由Istio的管理功能来控制productpage的外部调用。 Istio 的 ingress controller 就是用于这个目的。

要使用ingress controller, 需要再kubernetes中为应用创建ingress resource.就象下面这样:

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 Ingress controller的 NodePort address:

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 访问productpage,对用户来说,这和之前没有Istio一样。

收集 metrics

Istio的另外一个功能是为普罗米修斯提供metrics。这些metrics由Envoy产生,根据定义好的规则(也可以客户化)收集并发送给普罗米修斯。这些metrics也可以用Grafana的Istio仪表盘来图形化展现。尽管普罗米修斯是缺省的监控工具,Istio也允许使用其他工具,这个在未来的博客中会提到。

下面,我们会运行一条命令来给应用加负载:

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

设置 Grafana’s 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-dashboar, 可以检查每个bookinfo服务的性能指标。

分布式跟踪

Istio的另一项功能是利用Zipkin进行跟踪。

设置: 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服务流程。

尽管envoy 代理会把所有跟踪记录发给Zipkin。应用还是需要把一些记录头标识发给zipkin, 以便把所有相关记录串起来。详细信息请参阅zipkin-tracing.

整体视图

Istio的metrics功能远不只是方便,它通过统一的metrics为服务网格 提供连贯一致的视图。这样我们不用再担心如何整合不同agent产生的metrics,不用再担心如何为传统app插入agent来收集metrics,也不用再担心如何在开发流程中控制应用产生metrics.服务网格会监控所有的通信,包括那些传统的黑盒子类的应用,并产生统一的metrics.

总结

以上这个例子展示了如何运行Istio支持的微服务。接下来的几周,我们将会继续展示Istio的功能,例如策略管理和http 请求路由。

Istio是整个大社区共同努力的成果,Google,IBM, Lyft都在致力于将Istio应用到大型而复杂的微服务部署中。

我们兴奋地看到各方合作者热情的参与,随着Istio越来越广泛的应用,社区期待各位更多的参与和贡献。

如果你正在或考虑在kubernetes中使用微服务架构,请试一下Istio. 你可以在Istio.io了解更多。告诉我们你的想法,最好是加入我们开发社区,让我们一起创造未来。

Istio 团队:Frank Budinsky,IBM 软件工程师,Andra Cismaru, Google 软件工程师, Israel Shalom Google 产品经理。

原文链接:使用Istio服务网格管理微服务,转载请注明来源!

0