大家好，我是张锦涛。群里有个朋友问我上图的问题，滚动升级过程的时间怎么测。这个问题可以抽象成一个通用的需求，适用于很多场景。例如，如果你是一个Kubernetes集群的管理员，你想要衡量耗时的过程，以便找到优化点；例如，如果你在做CI/CD，你想通过测量耗时过程来给CI/CD过程Time-consuming；现有的解决方案Kubernetes已经提供了一种非常方便的方式来解决这个问题，这就是我在回复中提到的，可以通过事件来衡量。Forexample,wecreateadeploymentinK8S,andlookattheeventinformationinthisprocess:?~kubectlcreatensmoelovenamespace/moelovecreated?~kubectl-nmoelovecreatedeploymentredis--image=ghcr.io/moelove/redis:alpinedeployment.apps/rediscreated?~kubectl-nmoelovegetdeployNAMEREADYUP-TO-DATEAVAILABLEAGEredis1/11116s?~kubectl-nmoelovegeteventsLASTSEENTYPEREASONOBJECTMESSAGE27sNormalScheduledpod/redis-687967dbc5-gsz5nSuccessfullyassignedmoelove/redis-687967dbc5-gsz5ntokind-control-plane27sNormalPulledpod/redis-687967dbc5-gsz5nContainerimage"ghcr.io/moelove/redis:alpine"alreadypresentonmachine27sNormalCreatedpod/redis-687967dbc5-gsz5nCreatedcontainerredis27sNormalStartedpod/redis-687967dbc5-gsz5nStartedcontainerredis27sNormalSuccessfulCreatereplicaset/redis-687967dbc5Createdpod:redis-687967dbc5-gsz5n27sNormalScalingReplicaSetdeployment/redisScaledupreplicasetredis-687967dbc5to1可以看到我们主要关注的一些事件均已经有记录了。Butyoucan’tlookatitthroughkubectleverytime,it’sawasteoftime.我之前的一个做法是在K8S中写一个程序，持续监控&收集K8S集群中的事件，写到我开发的另一个系统中，用于存储和可视化。但这种方法需要额外的开发，并不通用。这里我介绍另一种更好的解决方案。更优雅的解决方案K8S中的这些事件都对应着我们的一个操作。比如上面创建了一个deployment，它会产生几个事件，包括Scheduled、Pulled、Created等，我们抽象出来，是不是和我们做的linktracing类似？这里我们将使用CNCF的毕业设计Jaeger[1]。我在之前的K8S生态周刊中已经多次介绍过。Jaeger是一个开源的端到端分布式跟踪系统。不过本文的重点不是介绍它，大家可以查看它的文档，快速部署一个Jaeger。另一个CNCF沙箱级项目是OpenTelemetry[2]，这是一个用于云原生软件的可观察框架，我们可以将其与Jaeger相结合。不过本文的重点不是介绍这两个项目，这里暂时略过。接下来介绍一下本文使用的主要项目，是来自Weaveworks的开源项目kspan。它的主要方法是将K8S中的事件组织成trace系统中的span。部署kspan---apiVersion:v1kind:ServiceAccountmetadata:name:kspan---apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:creationTimestamp:nullname:kspan-adminroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:cluster-adminsubjects:-kind:ServiceAccountname:kspannamespace:default---apiVersion:v1kind:Podmetadata:labels:run:kspanname:kspanspec:containers:-image:docker.io/weaveworks/kspan:v0.0name:kspanresources:{}dnsPolicy:ClusterFirstrestartPolicy:AlwaysserviceAccountName:kspan可以直接使用我这里提供的YAML进行部署测试，但是请注意以上配置文件不要在生产环境中使用，需要修改RBAC权限。默认情况下，它将通过otlp-collector.default:55680传递跨度，您需要确保此svc存在。以上所有内容部署完成后你大概会是这样：、?~kubectlgetallNAMEREADYSTATUSRESTARTSAGEpod/jaeger-76c84457fb-89s5v1/1Running064mpod/kspan1/1Running035mpod/otel-agent-sqlk61/1Running059mpod/otel-collector-69985cc444-bjb921/1Running056mNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEservice/jaeger-collectorClusterIP10.96.47.12
