Kubernetes上的服务网格 Istio - 分布式追踪篇

微服务架构将复杂系统切分若干小服务，每个服务可以被独立地开发、部署和伸缩；微服务架构和容器（Docker/Kubernetes）是天作之合，可以进一步简化微服务交付，加强整体系统的弹性和健壮性。然而由大量的微服务构成的分布式应用架构也会增加运维、调试、和安全管理的复杂性。为了解决上述挑战，Spring Cloud和Dubbo/EDAS等微服务框架将服务治理能力内置在编程框架中。

2017年5月，Google、IBM和Lyft发布了开源服务网格框架Istio，提供微服务的连接、管理、监控和安全保护。Istio提供了一个服务间通信的基础设施层，解耦了应用逻辑和服务访问中版本管理、安全防护、故障转移、监控遥测等切面的问题。

Istio为希腊语，意思是“启航”，虽然是一个非常年轻的项目却得到了极大的关注，其生态发展非常迅猛。我们今天先关注一下在其分布式服务追踪（Distributed Tracing）相关的进展。

本文参考了 Istio 官方文档内容 https://istio.io/docs/tasks/telemetry/distributed-tracing.html

安装 Istio

配置 Kubernetes 集群

我们可以使用Minikube或者阿里云容器服务Kubernetes集群进行验证。

Minikube的安装方式请参见Minikube - Kubernetes本地实验环境

由于我们将采用 Initializers 方式进行部署，需要运行如下命令开启相应的 Initializers 准入控制插件。

minikube start \
    --memory 4096 \
    --registry-mirror=https://registry.docker-cn.com \
    --extra-config=apiserver.Admission.PluginNames="Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota"

阿里云容器服务在1.8+版本以上的Kubernetes集群已经内置开启了 Initializers 插件，无需额外的配置工作。

注：由于部署Istio之后会为每个Pod注入sidecar，来接管服务通信，建议在独立的测试环境中进行验证。

需要根据集群管理页面信息，配置相应的连接信息

下载 Istio 发行版

在 Istio releases页面 获取最新的安装包，解压到本地，或者执行如下命令

curl -L https://git.io/getLatestIstio | sh -

执行如下命令

# 切换工作目录到 Istio
cd istio-0.3.0
# 添加 istioctl client 到 PATH 环境变量
export PATH=$PWD/bin:$PATH

部署 Istio

# 部署 Istio 系统组件
kubectl apply -f install/kubernetes/istio.yaml
# 部署 Istio initializer 插件
kubectl apply -f install/kubernetes/istio-initializer.yaml

部署完毕后，可以用如下命令来验证 Istio 组件是否成功部署

$ kubectl get svc,pod  -n istio-system
NAME                TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                            AGE
svc/istio-ingress   LoadBalancer   10.0.0.241   <pending>     80:31411/TCP,443:31972/TCP                                         22m
svc/istio-mixer     ClusterIP      10.0.0.146   <none>        9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP   22m
svc/istio-pilot     ClusterIP      10.0.0.253   <none>        15003/TCP,443/TCP                                                  22m

NAME                                    READY     STATUS    RESTARTS   AGE
po/istio-ca-76dddbd695-jzgq4            1/1       Running   0          22m
po/istio-ingress-85fb769c4d-8jr4r       1/1       Running   0          22m
po/istio-initializer-7fcb8b7454-f68h8   1/1       Running   0          10s
po/istio-mixer-587fd4bbdb-wpbfr         3/3       Running   0          22m
po/istio-pilot-7db8db896c-wdmhp         2/2       Running   0          22m

等待所有的 Pod 进入运行状态，Istio 就已经部署完成了。

分布式服务追踪

部署测试应用BookInfo

参照 BookInfo指南，部署应用。该应用由若干个微服务组成，每个微服务都通过容器方式进行部署。

执行 如下命令

kubectl apply -f samples/bookinfo/kube/bookinfo.yaml

MiniKube 环境下执行如下命令获取相应的访问地址

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

阿里云Kubernetes集群已经为每个集群配置了SLB和Ingress

$ kubectl get ingress -o wide
NAME      HOSTS     ADDRESS          PORTS     AGE
gateway   *         112.74.xxx.xxx   80        2m

我们可以通过如下的方法来获得相应的地址

export GATEWAY_URL=$(kubectl get ingress -o wide -o jsonpath={.items[0].status.loadBalancer.ingress[0].ip})

当如下命令

curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage

返回 200 时，就表示应用已经成功部署，可以通过浏览器打开 http://${GATEWAY_URL}/productpage 来访问应用了

部署分布式服务追踪

分布式追踪系统可以帮助观察服务间调用链，是诊断性能问题、分析系统故障的利器。

Istio 生态实现了对不同的分布式追踪系统的支持，包括Zipkin和Jaeger

Istio v0.3 提供了对Jaeger良好支持，测试方法如下

kubectl apply -n istio-system -f https://raw.githubusercontent.com/jaegertracing/jaeger-kubernetes/master/all-in-one/jaeger-all-in-one-template.yml

部署完成之后，我们可以通过端口映射来访问Jaeger 控制面板:

kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686:16686 &

通过浏览器打开 http://localhost:16686

多访问几次测试应用，我们可以清楚的看到服务的调用链，

Istio分布式追踪实现

Istio服务网格的核心是Envoy，是一个高性能的开源L7代理和通信总线。在Istio中，每个微服务都被注入了Envoy Sidecar，该实例负责处理所有传入和传出的网络流量。因此，每个Envoy Sidecar都可以监控所有的服务间API调用，并记录每次服务调用所需的时间以及是否成功完成。

每当微服务发起外部调用时，客户端Envoy会创建一个新的span。一个span代表一组微服务之间的完整交互过程，从请求者（客户端）发出请求开始到接收到服务方的响应为止。

在服务交互过程中，客户端会记录请求的发起时间和响应的接收时间，服务器端Envoy会记录请求的接收时间和响应的返回时间。

每个Envoy都会将自己的span视图信息发布到分布式追踪系统。当一个微服务处理请求时，可能需要调用其他微服务，从而导致因果关联的span的创建，形成完整的trace。这就需要由应用来从请求消息中收集和转发下列 Header

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context

在通信链路中的Envoy，可以截取、处理、转发相应的Header。

    Client Tracer                                              Server Tracer
┌──────────────────┐                                       ┌──────────────────┐
│                  │                                       │                  │
│   TraceContext   │           Http Request Headers        │   TraceContext   │
│ ┌──────────────┐ │          ┌───────────────────┐        │ ┌──────────────┐ │
│ │ TraceId      │ │          │ X─B3─TraceId      │        │ │ TraceId      │ │
│ │              │ │          │                   │        │ │              │ │
│ │ ParentSpanId │ │ Extract  │ X─B3─ParentSpanId │ Inject │ │ ParentSpanId │ │
│ │              ├─┼─────────>│                   ├────────┼>│              │ │
│ │ SpanId       │ │          │ X─B3─SpanId       │        │ │ SpanId       │ │
│ │              │ │          │                   │        │ │              │ │
│ │ Sampled      │ │          │ X─B3─Sampled      │        │ │ Sampled      │ │
│ └──────────────┘ │          └───────────────────┘        │ └──────────────┘ │
│                  │                                       │                  │
└──────────────────┘                                       └──────────────────┘

具体代码请参见 Istio 文档 https://istio.io/docs/tasks/telemetry/distributed-tracing.html

总结

Istio 借助良好的扩展机制和强大的生态正在加速 Service Mesh的应用和普及。除上文之外还有 Weave Scope， Istio Dashboard 和 Istio-Analytics 项目提供丰富的调用链路可视化和分析能力。

阿里云容器服务提供了托管的Kubernetes集群支持，了解更多阿里云容器服务内容， 请访问https://www.aliyun.com/product/containerservice