Google，IBM 和 Lyft 自豪地宣布 Istio 的第一个公开发布：一个开源项目，提供统一的连接，安全，管理和监控微服务的方。 我们目前的版本针对 Kubernetes 环境; 我们打算在未来几个月内为虚拟机和 Cloud Foundry 等其他环境增加支持。 Istio 将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础。 该软件使用来自 Lyft 的经过测试的特使代理构建，并提供对流量的可见性和控制，而不需要对应用程序代码进行任何更改。 Istio 为 CIO 提供了强大的工具，可以在整个企业中实施安全性，政策和合规性要求。
Istio 和 Service Mesh
Istio 是 Google、IBM 和 Lyft 联合开源的微服务 Service Mesh 框架，旨在解决大量微服务的发现、连接、管理、监控以及安全等问题。Istio 对应用是透明的，不需要改动任何服务代码就可以实现透明的服务治理。
Istio 的主要特性包括：
HTTP、gRPC 和 TCP 网络流量的自动负载均衡
丰富的路由规则，细粒度的网络流量行为控制
流量加密、服务间认证，以及强身份声明
全范围（ Fleet-wide ）策略执行
深度遥测和报告
Service Mesh
Service Mesh（服务网格）是一个用于保证服务间安全、快速、可靠通信的网络代理组件，是随着微服务和云原生应用兴起而诞生的基础设施层。它通常以轻量级网络代理的方式同应用部署在一起（比如 sidecar 方式，如下图所示）。Serivce Mesh 可以看作是一个位于 TCP/IP 之上的网络模型，抽象了服务间可靠通信的机制。但与 TCP 不同，它是面向应用的，为应用提供了统一的可视化和控制。
为了保证服务间通信的可靠性，Service Mesh 需要支持熔断机制、延迟感知的负载均衡、服务发现、重试等一些列的特性。
比如 Linkerd 处理一个请求的流程包括
查找动态路由确定请求的服务
查找该服务的实例
Linkerd 跟响应延迟等因素选择最优的实例
将请求转发给最优实例，记录延迟和响应情况
如果请求失败或实例实效，则转发给其他实例重试（需要是幂等请求）
如果请求超时，则直接失败，避免给后端增加更多的负载
记录请求的度量和分布式跟踪情况
为什么 Service Mesh 是必要的
将服务治理与实际服务解耦，避免微服务化过程中对应用的侵入
加速传统应用转型微服务或云原生应用
Service Mesh 并非一个全新的功能，而是将已存在于众多应用之中的相关功能分离出来，放到统一的组件来管理。特别是在微服务应用中，服务数量庞大，并且可能是基于不同的框架和语言构建，分离出来的 Service Mesh 组件更容易管理和协调它们。
Istio 原 理
Istio 从逻辑上可以分为数据平面和控制平面：
数据平面主要由一系列的智能代理（Envoy）组成，管理微服务之间的网络通信
控制平面负责管理和配置这些智能代理，并动态执行策略
Istio 架构可以如下图所示
主要由以下组件构成
Envoy ：Lyft 开源的高性能代理总线，支持动态服务发现、负载均衡、TLS 终止、HTTP/2 和 gPRC 代理、健康检查、性能测量等功能。Envoy 以 sidecar 的方式部署在相关的服务的 Pod 中。
Mixer：负责访问控制、执行策略并从 Envoy 代理中收集遥测数据。Mixer 支持灵活的插件模型，方便扩展（支持 GCP、AWS、Prometheus、Heapster 等多种后端）
Istio-Auth：提供服务间和终端用户的认证机制
Pilot：动态管理 Envoy 示例的生命周期，提供服务发现、流量管理、智能路由以及超时、熔断等弹性控制的功能。其与 Envoy 的关系如下图所示
在数据平面上，除了 Envoy，还可以选择使用 nginxmesh 和 linkerd 作为网络代理。比如，使用 nginxmesh 时，Istio的控制平面（Pilot、Mixer、Auth）保持不变，但用 Nginx Sidecar 取代 Envoy：
安 装
Istio 目前仅支持 Kubernetes，在部署 Istio 之前需要先部署好 Kubernetes 集群并配置好 kubectl 客户端。
下 载 Istio
curl -L https://git.io/getLatestIstio | sh -
cd istio-0.2.12/
cp bin/istioctl /usr/local/bin
部 署 Istio 服 务
两种方式（选择其一执行）
禁止 Auth：kubectl apply -f install/kubernetes/istio.yaml
启用 Auth：kubectl apply -f install/kubernetes/istio-auth.yaml
部署完成后，可以检查 isotio-system namespace 中的服务是否正常运行：
$ kubectl -n istio-system get pod
NAME READY STATUS RESTARTS AGE
istio-ca-5cd46b967c-q5th6 1/1 Running 0 3m
istio-egress-56c4d999bc-82js4 1/1 Running 0 3m
istio-ingress-5747bb855f-tv98x 1/1 Running 0 3m
istio-mixer-77487797f6-cwtqt 2/2 Running 0 3m
istio-pilot-86ddcb7ff5-t2zpk 1/1 Running 0 3m
部 署 Prometheus、Grafana 和 Zipkin 插 件
kubectl apply -f install/kubernetes/addons/grafana.yaml
kubectl apply -f install/kubernetes/addons/servicegraph.yaml
kubectl apply -f install/kubernetes/addons/zipkin.yaml
kubectl apply -f install/kubernetes/addons/prometheus.yaml
# kubectl apply -f install/kubernetes/addons/zipkin-to-stackdriver.yaml
等一会所有 Pod 启动后，可以通过 NodePort 或负载均衡服务的外网 IP 来访问这些服务。比如通过 NodePort 方式，先查询服务的 NodePort
$ kubectl -n istio-system get svc grafana -o jsonpath='{.spec.ports[0].nodePort}'
32070
$ kubectl -n istio-system get svc servicegraph -o jsonpath='{.spec.ports[0].nodePort}'
31072
$ kubectl -n istio-system get svc zipkin -o jsonpath='{.spec.ports[0].nodePort}'
30032
$ kubectl -n istio-system get svc prometheus -o jsonpath='{.spec.ports[0].nodePort}'
30890
通过 http://
通过 http://
通过 http://
通过 http://
部署 示 例 应 用
在部署应用时，需要通过 istioctl kube-inject 给 Pod 自动插入 Envoy 容器，即
wget https://raw.githubusercontent.com/istio/istio/master/blog/bookinfo-v1.yaml
# inject with istioctl
kubectl apply -f <(istioctl kube-inject -f bookinfo-v1.yaml)
# create ingress
cat <原始应用如下图所示
istioctl kube-inject 在原始应用的每个 Pod 中插入了一个 Envoy 容器
服务启动后，可以通过 Ingress 地址
http://
来访问 BookInfo 应用
$ kubectl describe ingress
Name: gateway
Namespace: default
Address: 192.168.0.77
Default backend: default-http-backend:80 (10.8.0.4:8080)
Rules:
Host Path Backends
---- ---- --------
*
/productpage productpage:9080 ()
/login productpage:9080 ()
/logout productpage:9080 ()
Annotations:
Events:
金 丝 雀 部 署
首先部署 v2 版本的应用，并配置默认路由到 v1 版本：
wget https://raw.githubusercontent.com/istio/istio/master/blog/bookinfo-ratings.yaml
kubectl apply -f <(istioctl kube-inject -f bookinfo-ratings.yaml)
wget https://raw.githubusercontent.com/istio/istio/master/blog/bookinfo-reviews-v2.yaml
kubectl apply -f <(istioctl kube-inject -f bookinfo-reviews-v2.yaml)
# create default route
cat <示例一：将 10% 请求发送到 v2 版本而其余 90% 发送到 v1 版本
cat <示例二：将特定用户的请求全部发到 v2 版本
cat <示例三：全部切换到 v2 版本
cat <示例四：限制并发访问
# configure a memquota handler with rate limits
cat <为了查看访问次数限制的效果，可以使用 wrk 给应用加一些压力：
export BOOKINFO_URL=$(kubectl get po -n istio-system -l istio=ingress -o jsonpath={.items[0].status.hostIP}):$(kubectl get svc -n istio-system istio-ingress -o jsonpath={.spec.ports[0].nodePort})
wrk -t1 -c1 -d20s http://$BOOKINFO_URL/productpage
参考文档：
https://istio.io/
A modern service mesh
- https://lyft.github.io/envoy/
https://github.com/nginmesh/nginmesh
WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?
- A SERVICE MESH FOR KUBERNETES
- Service Mesh Pattern
- Request Routing and Policy Management with the Istio Service Mesh
技术交流群：365534424
明晚九点|基于 Ansible API 的任务管理平台
主讲师：panda
前 douban 运维工程师，目前就职于创业公司。引入 douban 的运维平台思想，完成公司的自动化运维平台开发和建设。对运维工程师转运维研发的困惑和痛点深有感触，乐于分享自己转型中的五味杂陈。
主要内容：
1：中小公司对于 puppet/salt/ansible 选择之我见
2：Ansible 在生产环境中的常用场景
3：Playbook API实现任务管理平台思路、难点及实现
分享模式：网络直播
分享时间：12月14日（周四）