【编者的话】今天的帖子由Istio团队展示如何为Kubernetes的微服务提供可视化，弹性，安全和控制功能。
本文讲的是使用Istio服务网格管理微服务服务化是现代软件架构的核心。部署一系列模块化的小型服务而非庞大的单体应用，可以给开发者更大的灵活性。开发者对不同模块可以使用不同的技术，不同的语言采用不同的版本，以实现更高的效率和速度，这一点对大型开发尤为重要。
采用微服务，新问题也随之而来。因为大型系统中会包含大量微服务。独立应用需要面对的问题，例如安全，负载均衡，监控，请求频率限定等在每个服务中都需要处理。
刚刚在gluecon 2017上发布的 Istio ，在根本上解决了这些问题。通过Istio, 开发者可以专注于微服务的核心逻辑，而让框架负责其他- 通信管理，服务发现，服务认证，安全和策略强化。更好的是，这些可以直接加到已有的微服务上而不必重写或重新编译。 Istio使用 Envoy 作为运行代理模块，提供 可扩展的中间层 ，可以允许跨服务的策略实施和遥测metrics采集。
当前的Istio版本专门针对Kubernetes用户，只需要安装几行代码就可以使Kubernetes微服务即刻获得可视化，弹性，安全管理和控制功能。
我们会在一系列的博客帖子中，讲解由四个微服务组成的简单应用。先来看怎样用单纯的Kubernetes来部署应用。接下来将要把同样的服务部署到Istio集群而不需要更改任何应用代码，同时提供metrics。
在接下来的帖子中，我们会更关注更先进的功能例如HTTP 请求路由，策略，认证和安全管理。
这些容器镜像都可以在Docker Hub上找到，在Kubernetes上部署只需要配置yaml就可以了。
值得一提的是这些微服务并不依赖于Kubernetes和Istio。 这些服务的数量，语言和版本的多样性使之成为一个理想的服务网格范例。关于此示例的更多信息，请参见 此处 。
用Kubernetes部署和部署其它服务没有什么不同。
ProductPage 微服务的配置文件如下：
另外两个微服务是Details和reviews-v1，使用productpage同样的方式部署。 Ratings服务则暂时无需部署。所有服务的yaml文件可以在 这里 找到。
作为普通Kubernetes app运行微服务：
如果要从外部集群访问应用，需要提供productpage服务的Nodeport地址：
现在可以通过链接地址用浏览器访问应用了： http://$BOOKINFO_URL/productpage。
请注意，在部署之前，我们用istioctl kube-inject命令更改了bookinfo-v1.yaml。它会把Envoy sidecar加入到Kubernetes pod，最终结果就是微服务和Envoy sidecar打包在一起并管理整个服务的通信。
在Istio网格服务中不是直接访问应用，而是通过在访问路径中加入Envoy sideca，由Istio的管理功能来控制productpage的外部调用。 Istio的 ingress controller就是用于这个目的。
要使用ingress controller，需要在Kubernetes中为应用创建 ingress resource ，就象下面这样：
使用Istio和v1版本的bookinfo应用程序生成的部署如下所示：
设置Istio Ingress controller的NodePort address：
现在我们可以通过链接 http://$BOOKINFO_URL/productpage访问productpage，对用户来说，这和之前没有Istio一样。
下面，我们会运行一条命令来给应用加负载：
设置Grafana’s NodePort URL：
打开链接 http://$GRAFANA_URL/dashboard/db/istio-dashboar， 可以检查每个bookinfo服务的性能指标。
通过链接http://$ZIPKIN_URL/ 可以跟踪整个bookinfo服务流程。
尽管Envoy代理会把所有跟踪记录发给Zipkin。应用还是需要把一些记录头标识发给Zipkin，以便把所有相关记录串起来。详细信息请参阅 zipkin-tracing 。
Istio是整个大社区共同努力的成果，Google、IBM、Lyft都在致力于将Istio应用到大型而复杂的微服务部署中。
我们兴奋地看到各方合作者热情的参与，随着Istio越来越广泛的应用，社区期待各位更多的参与和贡献。
如果你正在或考虑在Kubernetes中使用微服务架构，请试一下Istio。你可以在 Istio.io 了解更多。告诉我们你的想法，最好是 加入 我们开发社区，让我们一起创造未来。
Istio团队：Frank Budinsky，IBM 软件工程师，Andra Cismaru，Google软件工程师， Israel Shalom Google 产品经理。
本文讲的是使用Istio服务网格管理微服务服务化是现代软件架构的核心。部署一系列模块化的小型服务而非庞大的单体应用，可以给开发者更大的灵活性。开发者对不同模块可以使用不同的技术，不同的语言采用不同的版本，以实现更高的效率和速度，这一点对大型开发尤为重要。
采用微服务，新问题也随之而来。因为大型系统中会包含大量微服务。独立应用需要面对的问题，例如安全，负载均衡，监控，请求频率限定等在每个服务中都需要处理。
Kubernetes和服务
Kubernetes通过 服务 构建支持微服务架构。 它允许开发者抽象出一系列的 Pods ，然后通过定义好的API开放给其他开发者。它允许在这层抽象上赋予服务一个名字同时执行4层基础负载均衡。但它并不能解决高级问题，例如7层上的metrics，请求频率限定，通信分流，回路中断等等。刚刚在gluecon 2017上发布的 Istio ，在根本上解决了这些问题。通过Istio, 开发者可以专注于微服务的核心逻辑，而让框架负责其他- 通信管理，服务发现，服务认证，安全和策略强化。更好的是，这些可以直接加到已有的微服务上而不必重写或重新编译。 Istio使用 Envoy 作为运行代理模块，提供 可扩展的中间层 ，可以允许跨服务的策略实施和遥测metrics采集。
当前的Istio版本专门针对Kubernetes用户，只需要安装几行代码就可以使Kubernetes微服务即刻获得可视化，弹性，安全管理和控制功能。
我们会在一系列的博客帖子中，讲解由四个微服务组成的简单应用。先来看怎样用单纯的Kubernetes来部署应用。接下来将要把同样的服务部署到Istio集群而不需要更改任何应用代码，同时提供metrics。
在接下来的帖子中，我们会更关注更先进的功能例如HTTP 请求路由，策略，认证和安全管理。
应用范例： Bookinfo
Bookinfo是一个简单应用，其功能包括展示信息，检查和评价书店的书籍。这个应用由不同语言编写的4个微服务组成。
这些容器镜像都可以在Docker Hub上找到，在Kubernetes上部署只需要配置yaml就可以了。
值得一提的是这些微服务并不依赖于Kubernetes和Istio。 这些服务的数量，语言和版本的多样性使之成为一个理想的服务网格范例。关于此示例的更多信息，请参见 此处 。
在Kubernetes中运行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服务则暂时无需部署。所有服务的yaml文件可以在 这里 找到。
作为普通Kubernetes 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加入到Kubernetes 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和v1版本的bookinfo应用程序生成的部署如下所示：
设置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进行跟踪。我们获得它的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服务流程。
尽管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 产品经理。
原文链接：Managing microservices with the Istio service mesh（翻译：杨川）
原文发布时间为：2017-10-08
本文作者：jerryyang
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：使用Istio服务网格管理微服务
