Google、IBM 和 Lyft 联合开源的微服务 Service Mesh 框架 Istio

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

Istio 和 Service Mesh

Istio 是 Google、IBM 和 Lyft 联合开源的微服务 框架，旨在解决大量微服务的发现、链接、管理、监控以及安全等问题。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://<kubernetes-ip>:32070/dashboard/db/istio-dashboard 访问  Grafana 服务

经过 http://<kubernetes-ip>:31072/dotviz 访问 ServiceGraph 服务，展现服务之间调用关系图

经过 http://<kubernetes-ip>:30032 访问 Zipkin 跟踪页面

经过 http://<kubernetes-ip>:30890 访问 Prometheus 页面

部署 示 例 应 用

在部署应用时，须要经过 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 <<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

原始应用以下图所示

istioctl kube-inject 在原始应用的每一个 Pod 中插入了一个 Envoy 容器

服务启动后，能够经过 Ingress 地址

http://<ingress-address>/productpage

来访问 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 (<none>)
        /login         productpage:9080 (<none>)
        /logout     productpage:9080 (<none>)
Annotations:
Events:    <none>

##金 丝 雀 部 署

首先部署 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 <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  route:
  - labels:
      version: v1
    weight: 100
EOF

示例一：将 10% 请求发送到 v2 版本而其他 90% 发送到 v1 版本

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  route:
  - labels:
      version: v2
    weight: 10
  - labels:
      version: v1
    weight: 90
EOF

示例二：将特定用户的请求所有发到 v2 版本

cat <<EOF | istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
 name: reviews-test-v2
spec:
 destination:
   name: reviews
 precedence: 2
 match:
   request:
     headers:
       cookie:
         regex: "^(.*?;)?(user=jason)(;.*)?$"
 route:
 - labels:
     version: v2
   weight: 100
EOF

示例三：所有切换到 v2 版本

cat <<EOF | istioctl replace -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  route:
  - labels:
      version: v2
    weight: 100
EOF

示例四：限制并发访问

# configure a memquota handler with rate limits
cat <<EOF | istioctl create -f -
apiVersion: "config.istio.io/v1alpha2"
kind: memquota
metadata:
 name: handler
 namespace: default
spec:
 quotas:
 - name: requestcount.quota.default
   maxAmount: 5000
   validDuration: 1s
   overrides:
   - dimensions:
       destination: ratings
     maxAmount: 1
     validDuration: 1s
EOF

# create quota instance that maps incoming attributes to quota dimensions, and createrule that uses it with the memquota handler
cat <<EOF | istioctl create -f -
apiVersion: "config.istio.io/v1alpha2"
kind: quota
metadata:
 name: requestcount
 namespace: default
spec:
 dimensions:
   source: source.labels["app"] | source.service | "unknown"
   sourceVersion: source.labels["version"] | "unknown"
   destination: destination.labels["app"] | destination.service | "unknown"
   destinationVersion: destination.labels["version"] | "unknown"
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
 name: quota
 namespace: default
spec:
 actions:
 - handler: handler.memquota
   instances:
   - requestcount.quota
EOF

为了查看访问次数限制的效果，能够使用 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日（周四）