Kubernetes Controller

最新推荐文章于 2024-08-04 23:31:12 发布

万wu皆可爱

最新推荐文章于 2024-08-04 23:31:12 发布

阅读量833

点赞数

分类专栏： kubernetes从入门到进阶文章标签： kubernetes 运维 docker

本文链接：https://blog.csdn.net/m0_46090675/article/details/121955795

版权

kubernetes从入门到进阶专栏收录该内容

8 篇文章 1 订阅

订阅专栏

文章目录

一、什么是Controller
二、 Deployment控制器应用
三、Service
四、Statefulset
- 无状态应用
- 有状态应用
五、DaemonSet
六、 Job和CronJob
- 6.1 Job控制器
- 6.2 Cronjob控制器

一、什么是Controller

Controller是在集群上管理和运行容器的对象，Controller是实际存在的，Pod是虚拟机的

Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。

Pod和Controller的关系

Pod是通过Controller实现应用的运维，比如弹性伸缩，滚动升级等
Pod 和 Controller之间是通过label标签来建立关系，同时Controller又被称为控制器工作负载

二、 Deployment控制器应用

Deployment控制器可以部署无状态应用
管理Pod和ReplicaSet
部署，滚动升级等功能
应用场景：web服务，微服务

Deployment表示用户对K8S集群的一次更新操作。Deployment是一个比RS( Replica Set, RS) 应用模型更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧RS中的副本数减少到0的复合操作。

这样一个复合操作用一个RS是不好描述的，所以用一个更通用的Deployment来描述。以K8S的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。

Deploymet 部署应用

kubectl create deployment web --image=nginx

但是上述部署代码不是很好的进行复用，因为每次我们都需要重新输入代码，所以我们都是通过YAML进行配置
我们可以尝试使用上面的代码创建一个镜像【只是尝试，不会创建】

kubectl create deployment web --image=nginx --dry-run -o yaml > nginx.yaml

得到如下文件

[root@k8s-master ~]# cat nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

我们看到的 selector 和 label 就是我们Pod 和 Controller之间建立关系的桥梁
在这里插入图片描述

使用yaml 文件创建Pod

通过刚刚的代码，我们已经生成了YAML文件，下面我们就可以使用该配置文件快速创建Pod镜像了

kubectl apply -f nginx.yaml

[root@k8s-master ~]# kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
web-96d5df5c8-6mzxp   1/1     Running   0          38s

由于没有暴露端口，只能在集群内部进行访问，所以我们还需要对外暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1

–port：就是我们内部的端口号
–target-port：就是暴露外面访问的端口号
–name：名称
–type：类型

[root@k8s-master ~]# cat web1.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2021-12-15T11:49:17Z"
  labels:
    app: web
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
      f:spec:
        f:externalTrafficPolicy: {}
        f:ports:
          .: {}
          k:{"port":80,"protocol":"TCP"}:
            .: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
        f:selector:
          .: {}
          f:app: {}
        f:sessionAffinity: {}
        f:type: {}
    manager: kubectl-expose
    operation: Update
    time: "2021-12-15T11:49:17Z"
  name: web2
  namespace: default
  resourceVersion: "173489"
  uid: 92701e93-d90f-4d9c-be51-0fba0dd8f6ac
spec:
  clusterIP: 10.1.23.54
  clusterIPs:
  - 10.1.23.54
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30394
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

让其暴露端口

kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml

kubectl apply -f web1.yaml

[root@k8s-master ~]# kubectl get pods,svc
NAME                      READY   STATUS    RESTARTS   AGE
pod/web-96d5df5c8-2cfz9   1/1     Running   0          2m43s

NAME                 TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
service/kubernetes   ClusterIP   10.1.0.1      <none>        443/TCP        46h
service/web1         NodePort    10.1.20.137   <none>        80:32202/TCP   35s

升级回滚

升级：服务从低版本升级到高版本，nginx:1.18—nginx-1.20 这就叫应用的升级【升级可以保证服务不中断】
回滚：版本从高版本到底版本，这就叫应用的回滚
弹性伸缩：我们根据不同的业务场景，来改变Pod的数量对外提供服务，这就是弹性伸缩

例如我们部署nginx:1.18 然后创建三个副本，把它升级到1.20

[root@k8s-master ~]# cat nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 3 # 创建三个副本
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.18 # 指定版本号
        name: nginx
        resources: {}
status: {}

在这里插入图片描述
升级

kubectl set image deployment web nginx=nginx:1.20

查看，可以看到有一四个副本，一个正在创建，说明是不停服务的升级，当一个副本满足条件后，会替换旧的，依次创建新的，替换旧的

[root@k8s-master ~]# kubectl get pods
NAME                   READY   STATUS              RESTARTS   AGE
web-6695fcb7f9-jg9kk   0/1     ContainerCreating   0          15s
web-7989784f96-h9jmp   1/1     Running             0          26m
web-7989784f96-jqf2g   1/1     Running             0          27m
web-7989784f96-vxdgw   1/1     Running             0          26m

可以看到过程，升级过程始终保持四个，当升级结束后，又恢复到三个副本
在这里插入图片描述
查看docker镜像，可以看到新的1.20也被拉取下来

查看升级状态
kubectl rollout status deployment web

[root@k8s-master ~]# kubectl rollout status deployment web
deployment "web" successfully rolled out

查看历史版本
kubectl rollout history deployment web

[root@k8s-master ~]# kubectl rollout history deployment web
deployment.apps/web 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

应用回滚：一般情况下只需要回滚到上一个状态即可
kubectl rollout undo deployment web
同时我们还可以回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

弹性伸缩

弹性伸缩，也就是根据业务要求，通过命令一下创建多个副本

在这里插入图片描述

三、Service

Deployment 只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的Pod，IP也是不固定的。因此不能以确定的IP和端口号提供服务。

要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

在K8S集群中，微服务的负载均衡是由kube-proxy实现的。kube-proxy是k8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决反向代理的高可用问题。

Service存在的意义

Service是Kubernetes最核心概念，通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。

1. 防止Pod失联【服务发现】

因为Pod每次创建都对应一个IP地址，而这个IP地址是短暂的，每次随着Pod的更新都会变化，假设当我们的前端页面有多个Pod时候，同时后端也多个Pod，这个时候，他们之间的相互访问，就需要通过注册中心，拿到Pod的IP地址，然后去访问对应的Pod。Service就相当于注册中心，每个Pod创建，都先要到注册中心注册。

2. 定义Pod访问策略【负载均衡】

前端的Pod访问到后端的Pod，中间会通过Service一层，而Service在这里还能做负载均衡，负载均衡的策略有很多种实现策略，例如

随机
轮询
响应比

Pod和Service的关系

Pod 和 Service 之间还是根据 label 和 selector 建立关联的【和Controller一样】

在这里插入图片描述
我们在访问service的时候，其实也是需要有一个ip地址，这个ip肯定不是pod的ip地址，而是虚拟IP vip

Service常用类型

Service常用类型有三种

ClusterIp：集群内部访问
NodePort：对外访问应用使用
LoadBalancer：对外访问应用使用，公有云

root@k8s-master ~]# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
web-7989784f96-5bk4j   1/1     Running   0          80s
web-7989784f96-mv2dr   1/1     Running   0          80s

[root@k8s-master ~]# kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml
W1216 20:58:15.375212   92002 helpers.go:553] --dry-run is deprecated and can be replaced with --dry-run=client.


# servic.yaml文件如下
[root@k8s-master ~]# cat service.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
status:
  loadBalancer: {}

如果我们没有做设置的话，默认使用的是第一种方式 ClusterIp，也就是只能在集群内部使用，
我们可以先以它创建Pod测试

[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.1.0.1     <none>        443/TCP   2d23h
web          ClusterIP   10.1.9.114   <none>        80/TCP    12s

[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.1.0.1     <none>        443/TCP   2d23h
web          ClusterIP   10.1.9.114   <none>        80/TCP    12s

测试集群内部访问，可以返回nginx页面

[root@k8s-node1 ~]# curl 10.1.9.114
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

我们可以添加一个type字段，用来设置我们的service类型

[root@k8s-master ~]# cat service.yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {}

[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.1.0.1       <none>        443/TCP        2d23h
web          NodePort    10.1.216.155   <none>        80:31594/TCP   18s

然后我们就可以用10.1.216.155:31594 方式，在集群外部访问

四、Statefulset

Statefulset主要是用来部署有状态应用

对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

无状态应用

我们原来使用 deployment，部署的都是无状态的应用，那什么是无状态应用？

认为Pod都是一样的
没有顺序要求
不考虑应用在哪个node上运行
能够进行随意伸缩和扩展

有状态应用

上述的因素都需要考虑到

认为每个Pod独立的
Pod启动顺序
唯一的网络标识符，持久存储

有序，比如mysql中的主从
适合StatefulSet的业务包括数据库服务MySQL 和 PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务

StatefulSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。

使用StatefulSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。

[root@k8s-master ~]# cat service1.yaml 
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None # 必须为无头service
  selector:
    app: nginx

apiVersion: apps/v1
kind: StatefulSet  # 声明有状态
metadata:
  name: nginx-statefulset
  namespace: default
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
          - containerPort: 80

创建Pod

kubectl apply -f service1.yaml

在这里插入图片描述
特点：

每个pod都有唯一的名称
无头的service
只有StatefaulSet控制器依赖于service，其它的控制器不依赖
有状态集合控制器(存在主从的称为有状态集合)，按照规定的顺序依次进行更新和修改（后创建的先删除）同时有状态集合控制器需要依赖于service来管理集群的所有的Pod的网络
statefulset有状态集合创建的容器都会有自己唯一的编号；所有的编号从0开始，且编号没有办法更改。

这里有状态的约定，肯定不是简简单单通过名称来进行约定，而是更加复杂的操作,statefulset：根据主机名 + 按照一定规则生成域名

每个pod有唯一的主机名，并且有唯一的域名
格式：主机名称.service名称.名称空间.svc.cluster.local
举例：nginx-statefulset-0.default.svc.cluster.local

# 编写StatefaulSet配置清单
vim statefaulset.yaml

kind: Service
apiVersion: v1
metadata:
  name: nginx
spec:
  selector:
    app: statefulset
  ports:
    - port: 80            #宿主主机的端口80
      targetPort: 80    #容器内的端口80

---
kind: StatefulSet       # 定义资源类型
apiVersion: apps/v1     # api版本号
metadata:              # 定义基本信息
  name: nginx          # 资源名称
spec:
  selector:
    matchLabels:     # 选择标签
      app: statefulset    # 选择的标签名称 
  serviceName: nginx   # 一写上面的spec出现serviceName就说明上面要创建一个service
  template:
    metadata:
      labels:              #定义标签
        app: statefulset   # 定义标签的名称
    spec:                 # 声明下面要执行的操作
      containers:         # 定义容器
        - name: nginx     # 容器名称
          image: nginx    # 镜像名称
          
# 应用资源
[root@master-lm1 ~]# kubectl apply -f statefulset.yaml

# 查看pod资源信息(会看到有个nginx-0为第一个副本)
kubectl get pods

# 编辑statefuleset资源(进入编辑副本数)
kubectl edit statefulesets.apps nginx

# 查看更新pod的流程
kubectl get pods -w

#进入nginx-0容器内部
kubectl exec -it nginx-0 -- bash

# 查看资源信息
printenv

# 验证删除资源的时候后创建的资源先删除
kubectl delete -f statefulset.yaml

五、DaemonSet

DaemonSet 即后台支撑型服务，主要是用来部署守护进程

长期伺服型和批处理型的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类的Pod运行；而后台支撑型服务的核心关注点在K8S集群中的节点(物理机或虚拟机)，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点，也可能是通过 nodeSelector选定的一些特定节点。典型的后台支撑型服务包括：存储、日志和监控等。在每个节点上支撑K8S集群运行的服务。

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

[root@k8s-master ~]# cat service2.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ds-test
  namespace: default
  labels:
    app: filebeat

spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
    spec:
      containers:
        - name: logs
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: varlog
              mountPath: /tmp/log
      
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

运行

kubectl apply -f service3.yaml

在这里插入图片描述

总结：

Deployment控制器调度pod的时候是随机调度到某一个节点上的,它是随机的
DaemonSet控制器调度pod的时候不是随机的，daemonSet调度Pod的时候，每一个节点上有且只有一个Pod运行。如果删除某一个节点，则立即删除该节点上的Pod，如果新增一个节点，则立即创建一个Pod运行在该节点之上。
DaemonSet更新服务是一个一个去更新的，而deployment是随机去更新的

使用场景：
		1、收集日志
		2、监控
		3、存储

六、 Job和CronJob

一次性任务和定时任务

一次性任务：一次性执行完就结束
定时任务：周期性执行
Job是K8S中用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别就是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功行任务保证有N个任务全部成功；工作队列性任务根据应用确定的全局成功而标志成功。

6.1 Job控制器

每一个Job，有且只执行一次，执行完毕之后，容器进入Complate(完成)状态。
一个job一次只能管理一个pod

配置清单里没有定义'选择器',也没有定义'副本数量'，因为不能重复执行。

1、Kubernetes中的Job对象将创建一个或多个Pod，并确保指定数量的Pod可以成功执行到进程正常结束：
① 当Job创建的Pod执行成功并正常结束时，Job将记录成功结束的Pod数量
② 当成功结束的Pod达到指定的数量时，Job将完成执行
③ 删除Job对象时，将清理掉由Job创建的Pod

2、容器的重启策略：restartPolicy
 Always：    任何情况下都在重启
 OnFailure： 出现错误的情况下重启
 Never ：    任何情况下都不重启
 
 #注：Job没有Always这种重启策略(只能填其它两项)

apiVersion: batch/v1
kind: Job
metadata:
  name: test-job
spec:
  template:
    metadata:
      labels:
        app: job
    spec:
      restartPolicy: OnFailure   #容器的重启策略
      containers:
        - name: busybox
          image: busybox:1.28.3
          command:
            - "/bin/sh"
            - "-c"
            - "sleep 50"

            
# 应用资源
[root@k8s-master ~]# kubectl apply -f job.yaml 

# 查看资源运行详情(根据配置清单详解:超过50秒该容器的生命周期就结束)
[root@k8s-master ~]# kubectl get pods
test-job-b86wg   0/1     Completed          0          115s

[root@k8s-master ~]# kubectl get jobs.batch     # 查看控制器运行详情
NAME       COMPLETIONS   DURATION   AGE
test-job   1/1           68s        111s

6.2 Cronjob控制器

Cronjob控制器是管理job，也就是说每一个周期创建一个Job去执行任务。
配置清单里没有定义’选择器’,也没有定义’副本数量’，因为不能重复执行。

# 查看Cronjob控制器详细信息
[root@k8s-master ~]# kubectl explain cronjob

[root@k8s-master ~]# cat cronjob.yaml 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: test-cronjob
spec:
  jobTemplate:      # 定义job的模板
    metadata:
      labels:
        app: cronjob
    spec:
      template:     # 定义pod的模板
        metadata:
          labels:
            app: cronjob
        spec:
          restartPolicy: OnFailure  # 容器重启策略
          containers:
            - name: busybox
              image: busybox:1.28.3
              imagePullPolicy: IfNotPresent   # 镜像拉取策略
              command:
                - "/bin/sh"
                - "-c"
                - "sleep 50"
  schedule: '* * * * *'           # cron表达式，代表每分钟执行一次

[root@k8s-master ~]# 
# 查看cronjob控制器运行详情
[root@k8s-master ~]# kubectl get cronjobs.batch 
NAME           SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
test-cronjob   * * * * *   False     0        <none>          22s
名字       cronjob表达式  是否暂停 完成几个[root@k8s-master ~]# 
[root@k8s-master ~]# 
# 查看控制器 资源运行详细内容
[root@k8s-master ~]# kubectl describe cronjobs.batch test-cronjob 
Name:                          test-cronjob
Namespace:                     default
Labels:                        <none>
Annotations:                   <none>
Schedule:                      * * * * *
Concurrency Policy:            Allow
Suspend:                       False
Successful Job History Limit:  3
Failed Job History Limit:      1
Starting Deadline Seconds:     <unset>
Selector:                      <unset>
Parallelism:                   <unset>
Completions:                   <unset>
Pod Template:
  Labels:  app=cronjob
  Containers:
   busybox:
    Image:      busybox:1.28.3
    Port:       <none>
    Host Port:  <none>
    Command:
      /bin/sh
      -c
      sleep 50
    Environment:     <none>
    Mounts:          <none>
  Volumes:           <none>
Last Schedule Time:  Fri, 31 Dec 2021 20:17:00 +0800
Active Jobs:         test-cronjob-1640953020
Events:
  Type    Reason            Age   From                Message
  ----    ------            ----  ----                -------
  Normal  SuccessfulCreate  14s   cronjob-controller  Created job test-cronjob-1640953020
[root@k8s-master ~]# 
# 查看job控制器详情，会每分钟创建一个资源
[root@k8s-master ~]# kubectl get job.batch 
NAME                      COMPLETIONS   DURATION   AGE
test-cronjob-1640953140   1/1           51s        3m32s
test-cronjob-1640953200   1/1           51s        2m32s
test-cronjob-1640953260   1/1           52s        92s
test-cronjob-1640953320   0/1           32s        32s


# 查看pod的标签，根据后面标签的(uid)不同而区分,不会重复
[root@k8s-master ~]# kubectl get pod --show-labels 
NAME                            READY   STATUS      RESTARTS   AGE     LABELS
mysql-56f8cdb464-lrs2l          1/1     Running     0          22h     app=mysql,pod-template-hash=56f8cdb464
test-cronjob-1640953200-l2q6q   0/1     Completed   0          3m43s   app=cronjob,controller-uid=7040288c-485b-4820-9712-26921a8e2dbd,job-name=test-cronjob-1640953200
test-cronjob-1640953260-gc642   0/1     Completed   0          2m43s   app=cronjob,controller-uid=e054006f-9a6b-4f0b-b4e4-950f324b05d3,job-name=test-cronjob-1640953260
test-cronjob-1640953320-5vj4m   0/1     Completed   0          103s    app=cronjob,controller-uid=f189236c-2c7f-4539-9163-71eb6ccdd943,job-name=test-cronjob-1640953320
test-cronjob-1640953380-8jnb8   1/1     Running     0          42s     app=cronjob,controller-uid=fee3695a-9aff-4472-9592-3854ee5e9c04,job-name=test-cronjob-1640953380