全栈工程师开发手册 （作者：栾鹏）
一站式云原生机器学习平台
前言：cube是开源的云原生机器学习平台，目前包含特征平台，支持在/离线特征；数据源管理，支持结构数据和媒体标注数据管理；在线开发，在线的vscode/jupyter代码开发；在线镜像调试，支持免dockerfile，增量构建；任务流编排，在线拖拉拽；开放的模板框架，支持tf/pytorch/spark/ray/horovod/kaldi等分布式训练任务；task的单节点debug，分布式任务的批量优先级调度，聚合日志；任务运行资源监控，报警；定时调度，支持补录，忽略，重试，依赖，并发限制，定时任务算力的智能修正；nni，katib，ray的超参搜索；多集群多资源组，算力统筹，联邦调度；tf/pytorch/onnx模型的推理服务，serverless流量管控，tensorrt gpu推理加速，依据gpu利用率/qps等指标的 hpa能力，虚拟化gpu，虚拟显存等服务化能力。 目前开源到github：/tencentmusic/cube-studio
serving环节
在开源的kubeflow框架中，模型服务化，是通过kfserving crd，然后业务配置自己的kfserving，来实现tf、pytorch、xgb等框架模型的服务接口。上下层架构如下图：
要了解kfserving的serverless框架需要由下至上了解k8s，服务网格，serverless，和kfserving。
ServiceMesh
Service Mesh 有如下几个特点：
应用程序间通信的中间层轻量级网络代理应用程序无感知解耦应用程序的重试/超时、监控、追踪和服务发现
目前两款流行的 Service Mesh 开源软件Istio和Linkerd，都可以直接在 Kubernetes 中集成。kubeflow平台底层依赖istio作为服务网格层。istio的流量代理是使用Envoy，包括sidecar和gateway。控制平面集成了认证，负载均衡，ab测试，监控等一系列流量管控功能。
下面我们来了解一下istio的相关概念和原理。
istio crd
先来了解一下istio中定义的各种crd，istio就是通过这些crd来实现对流量管理的配置。
虚拟服务（Virtual Service）
如果没有虚拟服务，Envoy对指定服务下的pod进行轮训转发。这是最简单的负载均衡策略。
istio通过自定义crd（working.istio.io）提供了多种路由规则，Envoy根据虚拟服务规则将请求路由到不同的服务，这样sidecar可以做更多像网关的工作。
working.istio.io（路由规则）：
virtualservices的配置中包含很多流量控制参数，下面是主要的几个控制字段。
Fault：注入故障Match：过滤流量。支持的匹配方法Host （location）、Uri、SchemeRoute、 - Method、Headers、Port、queryParams。更多的方法，可以参考官方解释Route：路由的目的地。目标地址：可以是同一服务的不同版本，也可以是完全不同的服务。1、Host 目标服务(k8s service+Consul service+ServiceEntry) 2、Subset 目标子网（下面会讲）Redirect：重定向Rewrite：修改流量corsPolicy：跨域策略Timeout：超时判断Retries：重试Headers：操作表头Mirror：复写请求，不等响应mirrorPercent：复写比例
可以配置一个虚拟服务处理特定命名空间中的所有服务。
机器学习平台中，系统创建的虚拟服务主要为notebook代理和系统组件代理
网关
istio通过k8s自定义资源working.istio.io用来实现网关策略。先来区分一下istio中的网关和网格。
网关：独立 Envoy 容器进行流量控制，不是sidecar形式存在。仅控制流量出入网格，没有路由能力，没有目的地，需要虚拟服务绑定网关。网格：sidecar形式，是伴随在业务容器旁边的，envoy代理流量。
working.istio.io
Selector：字段控制哪些网关控制器使用这个网关策略
Servers字段：
Hosts：允许的host，可以是虚拟服务(ns1/)，k8s-服务(namespace/*)，dns(xx.xx.xx)Port：监听端口Tls：允许的协议defaultEndpoint： 默认转发地 unix:///path/to/socket或127.0.0.1:PORT
可以看出，要么gateways直接将流量转发到k8s的服务上面，要么需要虚拟服务来接收流量，然后按路由规则处理。
virtualservice与gateway的绑定
虚拟服务添加的时候可以通过Gateways字段来添加绑定的gateway。
Spec:Gateways:knative-serving/cluster-local-gatewayknative-serving/knative-ingress-gatewayHosts:mnist-service-83e0-predictor-default.pengluanmnist-service-83e0-predictor-default.mnist-service-83e0-predictor-default.pengluan.svcmnist-service-83e0-predictor-default.pengluan.svc.cluster.localHttp:Headers:...
添加以后也可以通过kubectl查看每个虚拟服务对应的gateway
istio网关控制器
网关控制器是真正用来接收入口流量，然后按照gateways里面的配置进行转发的。
注意：gateway和网关控制器可以不在同一个命名空间。
Kubeflow机器学习平台使用了4类gateways控制器：
istio-system命名空间下（自定义网关服务，相同镜像，不同命令，处理访问各自域的流量）
kfserving-ingressgateway：kfserving的入口网关，是模型服务化时，流量的入口网关
cluster-local-gateway：集群内部相互访问的网关
istio-ingressgateway：istio自带的入口网关
istio-egressgateway：出口网关，控制哪些服务可以访问外部网格（安全考虑）
Kubeflow平台系统自带的Gateway实例
knative-ingress-gateway -n knative-serving 应用在kfserving-ingressgateway控制器上（istio-system命名空间），控制访问Knative命名空间容器的流量。Knative-serving空间中config-istio的configmap配置了这个信息供其他模块用，如果修改需一并修改
cluster-local-gateway -n knative-serving 应用在cluster-local-gateway控制器上（istio-system命名空间）
kubeflow-gateway –n kubeflow 应用在ingressgateway控制器上（istio-system命名空间）,代理kubeflow控制组件的访问
可以通过kubectl的describe命令自己查看：
目标规则
istio通过自定义资源working.istio.io来显示目标子网划分。
我们可以按上面的结构来理解istio是如何将k8s中的pod进行子网划分的。在平时使用的k8s中，一个服务下面就是一个子网，均衡策略就是随机负载。目标规则通过label和负载均衡策略将他们重新组织。这样当虚拟服务是将流量转发到目标子网时，也就能进入到对应的pod的sidecar中。
istio数据面
上面了解了配置以后，下面就是如何去管理和实施这些配置。先来看具体根据配置实施流量控制的数据面。
proxy（数据面）
istio 的sidecar（istio-proxy）是开源项目envoy的扩展版。Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是istio架构中唯一的数据面组件， Envoy 提供了动态服务发现、负载均衡、TLS , HTTP/2 及gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。
也就是说真正的流量就是都是经过数据面进入业务容器的。
istio控制面
控制面的pod部署在istio-system中，主要有下面10个组件，在了解的过程中，也可以根据pod的真实运行情况来对照了解。
Pilot（规则下发）
主要功能：服务发现、下发规则，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理规则，也包括认证授权等安全规则，proxy接收指令完成业务功能。
过程：Pilot将VirtualService表达的各种规则转换成Envoy可识别的格式，通过标准的XDS 协议发送给Envoy，指导Envoy完成功作，Envoy根据该路由规则进行流量转发。在通信上， Envoy 通过grpc流式订阅 Pilot 的配置资源。
Policy（Mixer镜像，策略执行）
Policy用于向Envoy(sidecar)提供准入策略控制，黑白名单控制，速率限制等相关策略。Envoy发起每个请求前都需要对Policy服务进行Check请求内容。为防止性能短板，或者访问延迟，可以裁剪一些功能如速率限制，全局配额等，或者禁用Mixer的Policy(–set mixer.enabled=false)。注意：不要直接关闭，不然会让每个请求都失败。禁用Policy的话，需要重新编辑整个服务网格的配置，并且重启pilot 容器)
数据面在转发服务的请求前调用istio-policy 的check接口检查是否允许访问， Mixer 根据配置将请求转发到对应的Adapter 做对应检查，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制。
Pilot和Policy的区别：
Pilot 管理的是配置数据，在配置改变时和数据面交互即可。
Policy是每个请求前都进行交互。（当然，在实现上通过在Mixer 和Proxy 上使用缓存机制，可保证不用每次进行数据面请求时都和Mixer 交互）
Telemetry（Mixer镜像，数据采集）
Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询。该组件挂掉将导致各监控运维插件无法采集到数据。同时，该组件在高并发情境下，会承受较大负荷，建议设置为多实例，增强可靠性
Envoy每次请求接收后会向Mixer Telemetry上报本次请求的基本信息，如调用是否成功、返回状态码、耗时数据。
暴露9091、9093、15004、42422端口：
9093端口是Mixer组件本身的prometheus暴露的端口42422是所有 Mixer 生成的网格指标
当网格中的两个服务间有调用发生时，服务的代理Envoy 就会上报遥测数据给istio-telemetry服务组件，istio-telemetry 服务组件则根据配置将生成访问Metric等数据分发给后端的遥测服务（prometheus）。数据面代理通过Report 接口上报数据时访问数据会被批量上报。
Citadel（安全控制）
服务列表中的istio-citadel 是Istio 的核心安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。Citadel 一直监听Kube-apiserver ，以Secret 的形式为每个服务都生成证书密钥，并在Pod 创建时挂载到Pod 上，代理容器使用这些文件来做服务身份认证，进而代理两端服务实现双向TLS认证、通道加密、访问授权等安全功能，这样用户就不用在代码里面维护证书密钥了。如下图 所示，frontend 服务对forecast 服务的访问用到了HTTP 方式，通过配置即可对服务增加认证功能， 双方的Envoy 会建立双向认证的TLS 通道，从而在服务间启用双向认证的HTTPS 。
galley（配置管理）
istio-galley 并不直接向数据面提供业务能力，而是在控制面上向其他组件提供支持。Galley 作为负责配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的Pilot和Mixer服务使用，这样其他管理面组件只用和Galley 打交道，从而与底层平台解耦。在新的版本中Galley的作用越来越核心。
istio-sidecar-injector
istio-sidecar-injector 是负责自动注入的组件，只要开启了自动注入，在Pod 创建时就会自动调用istio-sidecar-injector 向Pod 中注入Sidecar 容器。
在Kubernetes环境下，根据自动注入配置， Kube-apiserver 在拦截到Pod 创建的请求时，会调用自动注入服务istio-sidecar-injector生成Sidecar 容器的描述并将其插入原Pod的定义中，这样，在创建的Pod 内除了包括业务容器，还包括Sidecar 容器。这个注入过程对用户透明，用户使用原方式创建工作负载。
istio-ingressgateway（Ambassador）
Ambassador 对外提供统一服务的网关(API Gateway)，它是一个 Kubernetes 原生的微服务 API 网关，它部署在网络边缘，将传入网络的流量路由到相应的内部服务（也被称为“南北”流量）。
istio-ingressgateway 就是入口处的Gateway ，从网格外访问网格内的服务就是通过这个Gateway 进行的。istio-ingressgateway 比较特别， 是一个Loadbalancer 类型的Service,不同于其他服务组件只有一两个端口,istio-ingressgateway 开放了一组端口，这些就是网格内服务的外部访问端口.如下图 所示，网格入口网关istio-ingressgateway 的负载和网格内的Sidecar 是同样的执行体，也和网格内的其他Sidecar 一样从Pilot处接收流量规则并执行。 。Istio 通过一个特有的资源对象Gateway 来配置对外的协议、端口等。
istio-egressgateway
出口网关，控制哪些服务可以访问外部网格（安全考虑）
Kiali
Istio中可视化操作。服务拓扑图、分布式跟踪、指标度量收集和图标、配置校验、健康检查和显示、服务发现
覆盖指标：
所有网格点出入流量：总流量数、错误率和请求响应时间网格健康状况sidecar级别指标服务级别指标（服务的延迟、流量、错误和饱和情况）控制平面指标（Pilot、Galley、Mixer组件本身）
istio整体架构和功能
Serverless
Serverless有以下几个特点：
Serverless意味无维护，Serverless不代表完全去除服务器，而是代表去除有关对服务器运行状态的关心和担心，它们是否在工作，应用是否跑起来正常运行等等。Serverless代表的是你不要关心运营维护问题。有了Serverless，可以几乎无需Devops了。
Serverless中的服务或功能代表的只是微功能或微服务，Serverless是思维方式的转变，从过去：“构建一个框架运行在一台服务器上，对多个事件进行响应。”变为：“构建或使用一个微服务或微功能来响应一个事件。”，你可以使用 django or node.js 和express等实现，但是serverless本身超越这些框架概念。框架变得也不那么重要了。
Serverless必要性
常见问题：
不使用的模型，或者使用少的模型，跟常规模型在一起会长期占用内存。流量不分流到的模型所在机器，没必要占用资源模型加载期间大量占用io和cpu资源
knative-serving
knative
knative的优势：
便利性：Knative 以 Kubernetes 作为其底层框架，因此无论是线上还是线下，任何 Kubernetes 集群，无论是云上 Kubernetes 服务还是自建 Kubernetes 集群，都能通过 - 安装 knative 插件快速的搭建 serverless 平台。
标准化：Knative 联合 CNCF，把所有事件标准化，统一为 CloudEvent，提供事件的跨 - 平台，同时让函数和具体的调用方能够解耦。
服务间解耦：使用 Knative 使得应用不在与底层依赖服务强绑定，可以跨云实现业务互通成熟的生态：Knative 基于 Kubernetes 体系构建，与 kubernetes 生态结合更紧密；自动伸缩：监控应用的请求，并自动扩缩容, 借助于istio(ambassador,gloo等)天生支持蓝绿发布、回滚功能，方便应用发布流程。
Knative serving
knative serving部署在knative-serving的Namespace
serving-core核心组件：
Activator：激活器负责接收和缓冲非活动修订的请求，并向autoscaler报告指标。Autoscaler：自动缩放器接收请求指标并调整处理流量负载所需的Pod数量Controller：根据crd，部署实际的资源。根据serving-knative，部署config和route，根据config配置rev，根据rev配置deployment和缩放器KPAWebhook：拦截所有Kubernetes API调用以及所有CRD插入和更新。它设置默认值，拒绝不一致和无效的对象，并验证和更改Kubernetes API调用。拦截资源变动通知
应用结构：
通过k8s提供了流量版本和流量代理的自定义资源类型。
configurations.serving.knative.devrevisions.serving.knative.devroutes.serving.knative.devservices.serving.knative.dev
Serving.serving.knative.dev/v1（用来创建config和route的）
Label向下传递给route和config。注意config传递给rev是通过Template。Template也就是config的TemplateTraffic也就是route的TrafficStatus也就是route和config的StatusConfiguration.serving.knative.dev/v1
Label标记绑定的route和serviceTemplate 表示rev的模板Route. serving.knative.dev/v1
Label标记绑定的服务，其他控制器会通过label来操作的(比如用来生成Statue-URL)，Traffic标记config/rev对应的流量比例（代码修改数字，进行灰度）Statue-URL：域名revisions.serving.knative.dev
Label标记哪个ksvc/route/configuration/configurationGenerationAnnotations标记pod控制信息Containers 标记pod模板Service Account NameTimeout SecondsContainer ConcurrencyStatus- Image Digest：对应images.cache的Imageimages.caching.internal.knative.dev
label标记哪个ksvc/rev/revisionUID/configuration/configurationGenerationUid唯一标识Image：image@sha256Service Account Name 拉取秘钥Route会生成访问该模型服务的url，相关配置文件包括config-domain、 config-istio、 config-network。
Autoscaler（自动伸缩器）和 Activator（激活器）
auto scaler在knative serving中的位置如下，auto scaler的配置在名为config-autoscaler的Configmap中。
涉及组件：
1、Queue Proxy： sidecar数据容器，测量/限制/上报 并发性/请求负载
2、Autoscaler：独立的控制容器
PodAutoscaler reconciler：正确获取对PodAutoscalers的任何更改，反馈下面两个Collector：从应用程序实例上的队列代理收集度量Decider：获得所有可用指标，并决定应将应用程序部署扩展到多少个Pod
3、Activator：缓冲请求并向autoscaler报告指标。零实例时添加数据路径，非过载时，删除数据路径， Websocket连接autoscaler，最大程度减少时延。
激活算法：
Stable Mode（稳定模式）：根据每个pod在60秒窗口内的平均并发来计算Panic Mode （恐慌模式）： 6秒的紧急窗口，并发2倍，进入紧张模式，60s内不紧张恢复稳定模式
knative如何将对版本的管理与istio结合起来使用的呢？
Knative 默认会为每一个 Service 生成一个域名，并且 Istio Gateway 要根据域名判断当前的请求应该转发给哪个 Knative Service。Knative 默认使用的主域名是 (配置文件中默认配置)。要修改根域名或者根据不同label设置不同根域名，可以使用修改configmap配置config-domain、config-network、config-istio。ksvc生成的域名方法多种多样，基本能产生你想要的域名效果。ksvc的域名产生后，我们访问的还是只有网关。有两种方式：
1、手动配置http header的location字段，与服务网关的真实域名并不一致。不同的请求虽然进了同一个网关，但是因为location字段不同，因为能被识别转发到不同的ksvc上
# 在访问时指定Hostcurl -H "Host: " http://xx.xx.xx.xx/
2、第2中方法就是在我们配置域名解析的时候使用泛域名解析，将*. 的所有域名都配置到同一个网关上。这样用户就可以直接使用真实的域名去访问了。
另外还有基于路径的访问方式，根据path前缀进行转发。不过需要特别注意，一定要服务的所有接口，包括静态文件下载的接口，都要是这个前缀才行。kubeflow项目下的pipeline、katib、jupyter这些产品都可以在启动时配置访问前缀，所以可以使用前缀匹配。一般的开源产品是不支持。
kfserving
kfserving在协议层上标准化了访问。通过不同框架的镜像来提供对不同框架模型的真实加载和预测。官方提供了一下几种
TensorFlow: 镜像由于TensorFlow官网提供PyTorch: 镜像由KFServing制作, 代码逻辑位于此SKLearn: 同上XGBoost: 同上TensorRT: 镜像由NVIDIA提供
哪种框架在什么操作时默认使用什么镜像、绑定哪个网关、如何日志采集都是在configmap inferenceservice-config中配置的。
inferenceservices.
kubeflow官方提供了一个自定义资源inferenceservices.，用来让开发者部署一个kfserving。
示例格式如下
apiVersion: "/v1alpha2"kind: "InferenceService"metadata:name: "mnist"namespace: "kubeflow"spec:default: # 版本控制predictor: # 预测minReplicas: 1serviceAccountName: k8s-satensorflow:storageUri: "gs://${BUCKET}/my-model/export" # 只需提供模型位置transformer: minReplicas: 1custom:container:image: xxxxxx # 将上述的前处理程序打包的imagesname: kfserving-container
创建以后，组件kfserving-controller-manager监听inferenceservices，并根据configmap来控制knative serving。进而控制routes、configurations、revisions，形成标准协议的域名接口。这些服务化的镜像一般提供http和grpc两种协议的访问。
流量流向
我们可以自己来定义镜像来进行处理。流量流向如下图，这是一个典型的灰度发布场景, 一个默认环境, 一个灰度环境, 由KNative的来控制流量。
seldon
Seldon 提供在Kubernetes上对机器学习模型的部署
指标监控
kubeflow监控在架构上就是服务网格的指标监控。覆盖下面层次
网关的流量指标：ingress服务网格的流量指标： Kiali分布式追踪：zipkin、jaeger日志：EFK性能指标：prometheus/grafana
性能指标
目前云原生市场最主流的监控解决方案是prometheus套件。
具体详细的内容介绍和部署都可以参考
/tencentmusic/cube-studio
网关流量指标
在服务网格中网关流量与网格流量都会被统计到kiali中。一般是用来把控入口全流量。当然你也可以使用ingress自带的流量统计。目前ingress-nginx或者其他的ingress方案都带有统计接口，兼容prometheus。可以在grafana方便的查看入口流量。配置部署可以参考：/tencentmusic/cube-studio
服务网格流量指标
istio自带组件kiali能查看内部服务之间的流量情况，但是前提是要把pod加入到网格中。并且我们需要配置采集启动，这样才能将网格的数据搜集上来。
网格指标采集结构如下图所示。mixer定义了网格代理到采集系统之间的协议，但并没有写死mixer的后端监控数据的存储。使用者可以根据自己的监控系统与mixer进行对接。这样istio只做数据采集，监控系统的整体架构还是保留原有体系。
要想跟踪流量，形成指标，并采集到监控系统。istio通过一批crd来配置管理服务网格的采集监控。
1、在sidecar处，代理容器要知道把流量转化为什么指标，怎么的流量转化为怎样的指标。一般情况我们通过metrics. config.istio.io这个自定义对象来进行配置，某个指标的产生。配置示例如下
dimensions:source: source.service | "unknown"destination: destination.service | "unknown"message: '"twice the fun!"'monitored_resource_type: '"UNSPECIFIED"'
2、Adapter API处理，形成Infra Backends的后端接口。比如我们使用prometheus作为监控系统，istio提供了
prometheus.config.istio.io用来配置对接prometheus是，metric api的格式。示例如下
metrics:- name: double_request_count # Prometheus 指标名称instance_name: doublerequestcount.metric.istio-system # Mixer Instance 名称（全限定名称）kind: COUNTERlabel_names:- source- destination- message
3、将形成的metric与metric api进行绑定
actions:- handler: doublehandler.prometheusinstances:- doublerequestcount.metric
这样sidecar就知道如何将流量转化为metric，并且形成对应的metric api
kubeflow平台自带的指标
可以通过kubectl查看istio的指标，流量，实验，吞吐，连接数基本都包含。
kubectl get metrics.config.istio.io --all-namespacesNAMESPACENAME AGEistio-system requestcount 5d6histio-system requestduration 5d6histio-system requestsize 5d6histio-system responsesize 5d6histio-system tcpbytereceived 5d6histio-system tcpbytesent 5d6histio-system tcpconnectionsclosed 5d6histio-system tcpconnectionsopened 5d6h
knative在创建ksvc的时候也会自动metric
kubectl get metrics.autoscaling.internal.knative.dev --all-namespacesNAMESPACE NAME READY REASONdihelloworld-go-x9tqz True
knative的metrics示例如下：
value: "1"dimensions:reporter: conditional((context.reporter.kind | "inbound") == "outbound", "source", "destination")source_workload: source.workload.name | "unknown"source_workload_namespace: source.workload.namespace | "unknown"source_principal: source.principal | "unknown"source_app: source.labels["app"] | "unknown"source_version: source.labels["version"] | "unknown"destination_workload: destination.workload.name | "unknown"destination_workload_namespace: destination.workload.namespace | "unknown"destination_principal: destination.principal | "unknown"destination_app: destination.labels["app"] | "unknown"destination_version: destination.labels["version"] | "unknown"destination_service: destination.service.host | "unknown"
日志采集
日志就采用业界的统一方案EFK（elasticsearch/fluentd/kibana）就可以。这个已经相对很成熟，这里不做详细介绍。
需要注意的是，日志采集一般统一配置采集/var/log/containers目录下面，这是docker的默认容器日志目录。但是需要注意这个目录下面都是软链，软链目的地/var/log/pods/，因为我们使用的k8s，容器是在pod中的。而/var/log/pods/下面的pod 日志，这个目录下面的也都是软链接，链接到真是的docker 存储空间。这样在配置fluentd时需要注意要配置真实的存储目录。
/var/log/containers链接/var/log/pods/
/var/log/pods/链接/data/docker/真正的docker数据存储空间。
服务网格的日志采集，istio也是通过自定义资源的来配置采集什么数据。跟指标相似，istio配置logentries. config.istio.io定义日志采集的内容和变换格式，如果输出到标准输出，则通过stdios.config.istio.io定义日志采集输出，通过rules. config.istio.io将logentrie和输出进行绑定。
当然怎么采集或者是否有其他的采集方案，完全可以独立。
链路追踪
istio本身包含了tracing服务网格链路追踪的方案，使用jaeger作为框架。但是你完全可以使用自己的框架，只要sidecar支持产生该框架的跟踪信号。然后将框架的服务地址添加到istio-sidecar-injector配置文件中，这样sidecar启动的时候就知道将跟踪信号发送到哪里。我们使用zipkin作为链路跟踪框架。跟踪架构如下图所示。
其中左边部分代表了客户端分别为：
InstrumentedClient：使用了Zipkin客户端工具的服务调用方InstrumentedServer：使用了Zipkin客户端工具的服务提供方Non-InstrumentedServer：未使用Trace工具的服务提供方，当然还可能存在未使用工具的调用方
总结：一个调用链路是贯穿InstrumentedClient->InstrumentedServer的，每经过一个服务都会以Span的形式通过Transport把经过自身的请求上报的Zipkin服务端中
右边线框内代表了Zipkin的服务端，其中各组件的功能如下：
UI：提供web页面，用来展示Zipkin中的调用链和系统依赖关系等Collector：对各个客户端暴露，负责接受调用数据，支持HTTP、MQ等Storage：负责与各个存储适配后存储数据，支持内存，MySQL，ES等API：为web界面提供查询存储中的数据的接口
在ui界面上，我们可以全局查看整个链路调用关系。
也可以进入某一个请求响应，查看每一步的访问详情
zipkin也属于kubeflow项目外架构，详情页可以在互联网上了解。
