共计 3554 个字符，预计需要花费 9 分钟才能阅读完成。
大家好，我是张晋涛。
群里有个小伙伴问了我上图中这个问题，如何度量滚动降级这个过程的工夫。
这个问题能够形象为一种通用需要，实用于多种场景。
- 比方你是 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，在之前的 K8S 生态周报 中我有屡次介绍它，Jaeger 是一款开源的，端对端的分布式 tracing 零碎。不过本文重点不是介绍它，所以咱们查看其文档，疾速的部署一个 Jaeger 即可。另一个 CNCF 的 sandbox 级别的我的项目是 OpenTelemetry 是一个云原生软件的可观测框架，咱们能够把它跟 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
NAME READY STATUS RESTARTS AGE
pod/jaeger-76c84457fb-89s5v 1/1 Running 0 64m
pod/kspan 1/1 Running 0 35m
pod/otel-agent-sqlk6 1/1 Running 0 59m
pod/otel-collector-69985cc444-bjb92 1/1 Running 0 56m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/jaeger-collector ClusterIP 10.96.47.12 <none> 14250/TCP 60m
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 39h
service/otel-collector ClusterIP 10.96.231.43 <none> 4317/TCP,14250/TCP,14268/TCP,9411/TCP,8888/TCP 59m
service/otlp-collector ClusterIP 10.96.79.181 <none> 55680/TCP 52m
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/otel-agent 1 1 1 1 1 <none> 59m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/jaeger 1/1 1 1 73m
deployment.apps/otel-collector 1/1 1 1 59m
NAME DESIRED CURRENT READY AGE
replicaset.apps/jaeger-6f77c67c44 0 0 0 73m
replicaset.apps/jaeger-76c84457fb 1 1 1 64m
replicaset.apps/otel-collector-69985cc444 1 1 1 59m上手实际
这里咱们先创立一个 namespace 用于测试：
➜ ~ kubectl create ns moelove
namespace/moelove created创立一个 Deployment
➜ ~ kubectl -n moelove create deployment redis --image=ghcr.io/moelove/redis:alpine
deployment.apps/redis created
➜ ~ kubectl -n moelove get pods
NAME READY STATUS RESTARTS AGE
redis-687967dbc5-xj2zs 1/1 Running 0 10s在 Jaeger 上进行查看：
点开看具体内容
能够看到，和此创立 deploy 无关的 event 均被归到了一起，在工夫线上能够看到其耗时等详细信息。
总结
本文介绍了如何联合 Jaeger 利用 tracing 的形式来采集 K8S 中的 events，以便更好的把握 K8S 集群中所有事件的耗时点，更易于找到优化的方向及度量后果。
欢送订阅我的文章公众号【MoeLove】