cube studio开源一站式云原生机器学习平台-架构（三）

全栈工程师开发手册 （作者：栾鹏）
一站式云原生机器学习平台

---

前言：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：https://github.com/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（virtualservices.networking.istio.io）提供了多种路由规则，Envoy根据虚拟服务规则将请求路由到不同的服务，这样sidecar可以做更多像网关的工作。

virtualservices.networking.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自定义资源gateways.networking.istio.io用来实现网关策略。先来区分一下istio中的网关和网格。

• 网关：独立 Envoy 容器进行流量控制，不是sidecar形式存在。仅控制流量出入网格，没有路由能力，没有目的地，需要虚拟服务绑定网关。
• 网格：sidecar形式，是伴随在业务容器旁边的，envoy代理流量。

gateways.networking.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-gateway
    knative-serving/knative-ingress-gateway
  Hosts:
    mnist-service-83e0-predictor-default.pengluan
    mnist-service-83e0-predictor-default.pengluan.example.com
    mnist-service-83e0-predictor-default.pengluan.svc
    mnist-service-83e0-predictor-default.pengluan.svc.cluster.local
  Http:
    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通过自定义资源destinationrules.networking.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和缩放器KPA
• Webhook：拦截所有Kubernetes API调用以及所有CRD插入和更新。它设置默认值，拒绝不一致和无效的对象，并验证和更改Kubernetes API调用。拦截资源变动通知

应用结构：

通过k8s提供了流量版本和流量代理的自定义资源类型。

• configurations.serving.knative.dev
• revisions.serving.knative.dev
• routes.serving.knative.dev
• services.serving.knative.dev

Serving.serving.knative.dev/v1（用来创建config和route的）

• Label向下传递给route和config。注意config传递给rev是通过Template。
• Template也就是config的Template
• Traffic也就是route的Traffic
• Status也就是route和config的Status

Configuration.serving.knative.dev/v1

• Label标记绑定的route和service
• Template 表示rev的模板

Route. serving.knative.dev/v1

• Label标记绑定的服务，其他控制器会通过label来操作的(比如用来生成Statue-URL)，
• Traffic标记config/rev对应的流量比例（代码修改数字，进行灰度）
• Statue-URL：域名

revisions.serving.knative.dev

• Label标记哪个ksvc/route/configuration/configurationGeneration
• Annotations标记pod控制信息
• Containers 标记pod模板
• Service Account Name
• Timeout Seconds
• Container Concurrency
• Status- Image Digest：对应images.cache的Image

images.caching.internal.knative.dev

• label标记哪个ksvc/rev/revisionUID/configuration/configurationGeneration
  Uid唯一标识
• Image：image@sha256
• Service 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 默认使用的主域名是 example.com(配置文件中默认配置)。要修改根域名或者根据不同label设置不同根域名，可以使用修改configmap配置config-domain、config-network、config-istio。ksvc生成的域名方法多种多样，基本能产生你想要的域名效果。ksvc的域名产生后，我们访问的还是只有网关。有两种方式：

1、手动配置http header的location字段，与服务网关的真实域名并不一致。不同的请求虽然进了同一个网关，但是因为location字段不同，因为能被识别转发到不同的ksvc上

# 在访问时指定Host
curl -H "Host: hello.example.com" http://xx.xx.xx.xx/

2、第2中方法就是在我们配置域名解析的时候使用泛域名解析，将*. example.com的所有域名都配置到同一个网关上。这样用户就可以直接使用真实的域名去访问了。

另外还有基于路径的访问方式，根据path前缀进行转发。不过需要特别注意，一定要服务的所有接口，包括静态文件下载的接口，都要是这个前缀才行。kubeflow项目下的pipeline、katib、jupyter这些产品都可以在启动时配置访问前缀，所以可以使用前缀匹配。一般的开源产品是不支持。

kfserving

kfserving在协议层上标准化了访问。通过不同框架的镜像来提供对不同框架模型的真实加载和预测。官方提供了一下几种

• TensorFlow: 镜像由于TensorFlow官网提供
• PyTorch: 镜像由KFServing制作, 代码逻辑位于此
• SKLearn: 同上
• XGBoost: 同上
• TensorRT: 镜像由NVIDIA提供

哪种框架在什么操作时默认使用什么镜像、绑定哪个网关、如何日志采集都是在configmap inferenceservice-config中配置的。

inferenceservices.serving.kubeflow.org

kubeflow官方提供了一个自定义资源inferenceservices.serving.kubeflow.org，用来让开发者部署一个kfserving。

示例格式如下

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "mnist"
  namespace: "kubeflow"
spec:
  default:  # 版本控制
    predictor:  # 预测
      minReplicas: 1
      serviceAccountName: k8s-sa
      tensorflow:
        storageUri: "gs://${BUCKET}/my-model/export" # 只需提供模型位置
    transformer: 
      minReplicas: 1
      custom:
        container:
          image: xxxxxx # 将上述的前处理程序打包的images
          name: 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套件。

具体详细的内容介绍和部署都可以参考
https://github.com/tencentmusic/cube-studio

网关流量指标

在服务网格中网关流量与网格流量都会被统计到kiali中。一般是用来把控入口全流量。当然你也可以使用ingress自带的流量统计。目前ingress-nginx或者其他的ingress方案都带有统计接口，兼容prometheus。可以在grafana方便的查看入口流量。配置部署可以参考：github.com/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: COUNTER
  label_names:
  - source
  - destination
  - message

3、将形成的metric与metric api进行绑定

actions:
- handler: doublehandler.prometheus
  instances:
  - doublerequestcount.metric

这样sidecar就知道如何将流量转化为metric，并且形成对应的metric api

kubeflow平台自带的指标

可以通过kubectl查看istio的指标，流量，实验，吞吐，连接数基本都包含。

kubectl get metrics.config.istio.io --all-namespaces
NAMESPACE      NAME                   AGE
istio-system   requestcount           5d6h
istio-system   requestduration        5d6h
istio-system   requestsize            5d6h
istio-system   responsesize           5d6h
istio-system   tcpbytereceived        5d6h
istio-system   tcpbytesent            5d6h
istio-system   tcpconnectionsclosed   5d6h
istio-system   tcpconnectionsopened   5d6h

knative在创建ksvc的时候也会自动metric

kubectl get metrics.autoscaling.internal.knative.dev --all-namespaces
NAMESPACE   NAME                  READY   REASON
di          helloworld-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项目外架构，详情页可以在互联网上了解。