大家好，我是张晋涛。

群里有个小同伴问了我上图中这个成绩，如何度量滚动晋级这个进程的时间。

这个成绩可以笼统为一种通用需求，适用于多种场景。

比如你是 Kubernetes 集群的管理员，你想度量这个进程中的耗时，以便发现优化点；

比如你是在做 CI/CD ，你想经过度量这个进程的耗时，来给出 CI/CD 进程的耗时；

现有方案

Kubernetes 曾经提供了很方便的办法来处置此成绩，也就是我回复中谈到的，经过 event 来度量即可。

比如，我们在 K8S 中，创立一个 deployment，看看这个进程中的 event 信息：

➜  ~ kubectl create ns moelove 

namespace/moelove created 

➜  ~ kubectl -n moelove create deployment redis --image=ghcr.io/moelove/redis:alpine 

deployment.apps/redis created 

➜  ~ kubectl -n moelove get deploy 

NAME    READY   UP-TO-DATE   AVAILABLE   AGE 

redis   1/1     1            1           16s 

➜  ~ kubectl -n moelove get events 

LAST SEEN   TYPE     REASON              OBJECT                        MESSAGE 

27s         Normal   Scheduled           pod/redis-687967dbc5-gsz5n    Successfully assigned moelove/redis-687967dbc5-gsz5n to kind-control-plane 

27s         Normal   Pulled              pod/redis-687967dbc5-gsz5n    Container image "ghcr.io/moelove/redis:alpine" already present on machine 

27s         Normal   Created             pod/redis-687967dbc5-gsz5n    Created container redis 

27s         Normal   Started             pod/redis-687967dbc5-gsz5n    Started container redis 

27s         Normal   SuccessfulCreate    replicaset/redis-687967dbc5   Created pod: redis-687967dbc5-gsz5n 

27s         Normal   ScalingReplicaSet   deployment/redis              Scaled up replica set redis-687967dbc5 to 1 

可以看到我们主要关注的一些事情均曾经有记载了。但是总不能每次都经过 kubectl 这么来看吧，有点糜费时间。

我之前的一种做法是在 K8S 中写了一个顺序，继续的监听&搜集 K8S 集群中的 event ，并将它写入到我另外开发的一套系统中停止存储和可视化。但这种办法需求做额外的开发也并不普适。这里我来引见另一个更优的处置方案。

更优雅的方案

K8S 中的这些事情，都对应着我们的一个操作，比如上文中是创立了一个 deployment ，它产生了几个 event ， 包括 Scheduled , Pulled ， Created 等。我们将其停止笼统，是不是和我们做的链路追辟（tracing）很像呢？

这里我们会用到一个 CNCF 的毕业项目 Jaeger[1] ，在之前的K8S生态周报 中我有屡次引见它，Jaeger 是一款开源的，端对端的散布式 tracing 系统。不过本文重点不是引见它，所以我们查看其文档，快速的部署一个 Jaeger 即可。另一个 CNCF 的 sandbox 级别的项目是 OpenTelemetry[2] 是一个云原生软件的可观测框架，我们可以把它跟 Jaeger 结合起来运用。不过本文的重点不是引见这俩项目，这里暂且略过。

接上去引见我们这篇文章的用到的主要项目，是来自 Weaveworks 开源的一个项目，名叫 kspan ，它的主要做法就是将 K8S 中的 event 作为 trace 系统中的 span 停止组织。

部署 kspan

--- 

apiVersion: v1 

kind: ServiceAccount 

metadata: 

  name: kspan 

--- 

apiVersion: rbac.authorization.k8s.io/v1 

kind: ClusterRoleBinding 

metadata: 

  creationTimestamp: null 

  name: kspan-admin 

roleRef: 

  apiGroup: rbac.authorization.k8s.io 

  kind: ClusterRole 

  name: cluster-admin 

subjects: 

- kind: ServiceAccount 

  name: kspan 

  namespace: default 

--- 

apiVersion: v1 

kind: Pod 

metadata: 

  labels: 

    run: kspan 

  name: kspan 

spec: 

  containers: 

  - image: docker.io/weaveworks/kspan:v0.0 

    name: kspan 

    resources: {} 

  dnsPolicy: ClusterFirst 

  restartPolicy: Always 

  serviceAccountName: kspan 

可以直接运用我这里提供的 YAML 停止部署测试， 但留意上述配置文件别用在消费环境下， RBAC 权限需求修正 。

它默许会运用 otlp-collector.default:55680 传递 span ，一切你需求确保有这个 svc 存在。以上一切内容部署完成后你大约会是这样：、

➜  ~ kubectl get all 

(责任编辑：admin)