乐趣区

关于kubernetes:更优雅的-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 , PulledCreated 等。咱们将其进行形象,是不是和咱们做的链路追踪(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】

退出移动版