更优雅的 Kubernetes 集群事件度量方案

 

大家好，更优我是集群张晋涛。

群里有个小伙伴问了我上图中这个问题，事件如何度量滚动升级这个过程的度量时间。

这个问题可以抽象为一种通用需求，更优适用于多种场景。集群

比如你是事件 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 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 集群中所有事件的耗时点，更易于找到优化的方向及度量结果。