k8s集群的pod控制器

1126秋刀鱼

已于 2024-06-03 14:37:14 修改

阅读量972

点赞数 30

文章标签： kubernetes 容器云原生

于 2024-06-03 01:00:41 首次发布

本文链接：https://blog.youkuaiyun.com/2301_81307988/article/details/139351281

版权

一个小补充：

：

Pod控制器及其功用

Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

pod控制器有多种类型

1、ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成：
（1）用户期望的pod副本数量
（2）标签选择器，判断哪个pod归自己管理
（3）当现存的pod数量不足，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

2、Deployment：（nginx web微服务）

工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。

3、DaemonSet：

用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性：服务是无状态的
服务必须是守护进程

4、StatefulSet：

管理有状态应用：需要存储实时的数据（mysql redis）

5、Job：（一次性任务）

只要完成就立即退出，不需要重启或重建

6、Cronjob：

周期性任务控制，不需要持续后台运行

二 Pod与控制器之间的关系

controllers：在集群上管理和运行容器的 pod 对象，控制器可以通过标签比pod相关联。
Pod 通过控制器实现应用的运维，如伸缩，升级等。

1、Deployment

部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级（1.kubectl set 2,kubectl edit deployment 进去直接修改 3. 通过修改网络插件nfs-celint-provisioner.yaml )、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务

示例：

查看控制器配置利用kubectl edit 在线修改编辑

补充：默认的升级过程为rollingUpdate是这个，如果是recreate，则先删除所有的旧pod 然后再去创建新的pod，会导致业务中断

举例说明更新

或者可以在线修改，例如：

2、SatefulSet

有序收缩，有序删除是从后往前

正常情况下，satefulset是串行创建pod，如果想修改，则修改成parallel

常用的应用场景：数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

三个组件

从上面的应用场景可以发现，StatefulSet由以下几个部分组成：
●Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
●volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
●StatefulSet：用于管控Pod资源。

为什么要有headless？

在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

为什么要有volumeClainTemplate？

大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
 
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

示例定义了一个 Headless Service 和一个 StatefulSet，用于部署一个名为 nginx 的应用。这个 StatefulSet 配置了 3 个副本，每个 Pod 都有一个名为 www 的 PVC，用于存储，并且使用了 nginx-slim 镜像。这个 StatefulSet 还设置了一个 Headless Service 来提供稳定的网络标识。

实现K8S里DNS功能的插件：

skyDNS：Kubernetes 1.3之前的版本
kubeDNS：Kubernetes 1.3至Kubernetes 1.11
CoreDNS：Kubernetes 1.11开始至今

举例说明先创建service clusterip为none 为无头模式

常规service和无头服务区别
service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: sts01
  name: sts01
  namespace: testapp
spec:
  serviceName: mysvc
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: soscscs/myapp:v1
        name: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 1Gi

由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，

需要先定义一个 Headless Service 资源，用于关联到每个 Pod 资源创建 DNS 资源记录。

接着定义了一个StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 1Gi 的专用存储卷

1、验证数据可以持久化

2、验证删除后名称不会改变，数据还会一直存在

3、验证扩容的创建过程是从小到大依次执行，并且自动创建pv

4,根据nds解析名字找到ip

5、验证滚动更新（倒叙），数据持久化还在

滚动更新为先删除1个pod 然后再创建一个新的pod ，倒叙从大到小更新

6、验证缩容的时候是倒序执行从大到小依次执行

验证缩容的时候pv和pvc不会删除

模拟只有一个pod了

模拟pod扩容副本数为2了现在是否会自动将pvc存储卷挂载到sts01-01中

7.如果要删除有状态的pod 官方建议先将pod缩容到0 再进行删除

总结statefulset的特点

1、statefulset用于部署有状态的应用（有实时数据需要存储的应用）

2、部署statefulset之前，需要先创建一个headless service（表示clusterip为node的特殊service类型），statefulset的配置清单模板需要去指定servicename为headless service的名称。

3、statefulset创建的pod名称是固定不变的，且唯一的

4、statefulset的资源配置模板可以设置pvc模板，指定storageclassname字段值，可以引用storageclass资源，调用存储卷插件，动态创建pv

5、statefulset管理的pod有滚动更新和扩容和缩容功能，扩容的时候为升序执行，滚动更新和缩容的时候为降序执行。

6、statefulset管理的pod可以在k8s集群的pod中，基于headless service以及coredns实现对pod名称解析出podIP

DaemonSet（工作负载）控制器

DaemonSet 是 Kubernetes 中的一种工作负载控制器，它确保在集群中的所有（或指定的）节点上运行一个 Pod 的副本。这使得 DaemonSet 成为运行集群级服务的理想选择，如日志收集、监控代理、存储守护进程等。

官方案例（监控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

关键特性

典型用例

应用场景

Agent：DaemonSet 常用于部署代理或守护进程，这些代理或守护进程作为集群的“代理”，执行特定的任务，如数据收集、服务代理等。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

我们看到DaemonSet会在每个node节点都创建一个Pod

Job

Job分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务
应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务

https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

应用场景

.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。

定义了一个名为 pi 的 Job，它将运行一个 Perl 容器来计算圆周率（π）。
.spec.template.spec 定义了 Pod 的规格，包括容器的名称、镜像和执行的命令。
restartPolicy: Never 表示 Pod 失败后不会重启。
backoffLimit: 4 表示 Job 在失败后最多重试 4 次

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

在所有node节点下载perl镜像，因为镜像比较大，所以建议提前下载好

使用 docker pull perl 命令提前拉取 Perl 镜像，以避免在 Job 执行时下载镜像导致延迟

master 节点

使用 kubectl apply -f job.yaml 命令创建 Job。这将在集群中启动一个 Pod 来执行计算圆周率的任务。

kubectl apply -f job.yaml
 
kubectl get pods

使用 kubectl get pods 命令查看 Pod 的状态。您可以看到 Pod pi-mql4l 已经成功完成

结果输出到控制台

kubectl logs pi-mql4l #结果输出到控制台

清除job资源

kubectl delete -f job.yaml

使用 kubectl delete -f job.yaml 命令删除 Job 和相关的 Pod 资源

设置 Job 的重试次数 (job-limit.yaml)

backoffLimit

vim job-limit.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2

创建一个新的 Job 配置文件，名为 busybox，它将运行一个 BusyBox 容器，执行一个失败的命令（exit 1）。

backoffLimit: 2 表示 Job 在失败后最多重试 2 次。

kubectl apply -f job-limit.yaml
 
kubectl get job,pods

kubectl describe job busybox

CronJob

官方文档链接

https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

应用场景

部署CronJob

如何在 Kubernetes 中创建一个 CronJob，该 CronJob 每分钟执行一次打印 "Hello" 的任务。

示例：每分钟打印hello

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

kubectl apply -f cronjob.yaml
 
kubectl get cronjob

查看执行的 Pod：

使用 kubectl get pods 命令查看由 CronJob 创建的 Pod。这些 Pod 通常会在任务完成后标记为 Completed。

kubectl get pods

使用 kubectl logs 命令查看特定 Pod 的日志输出。可以进入其中一个pod，可以看到打印的日期和 "Hello" 消息。

报错解决

#如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)

#解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

如果在查看日志时遇到权限问题，可以通过创建一个 clusterrolebinding 来授予 system:anonymous 用户 cluster-admin 权限。这通常不推荐，因为它会降低集群的安全性。在生产环境中，应该使用更细粒度的权限控制。

通过这些步骤，可以在 Kubernetes 中设置周期性任务，例如定期备份、日志清理或发送通知。CronJob 提供了一种简单的方式来自动化这些重复性任务。

cronjob其它可用参数的配置

cronjob其它可用参数的配置
 
spec:
  concurrencyPolicy: Allow			#要保留的失败的完成作业数（默认为1）
  schedule: '*/1 * * * *'			#作业时间表。在此示例中，作业将每分钟运行一次
  startingDeadlineSeconds: 15		#pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
  successfulJobsHistoryLimit: 3		#要保留的成功完成的作业数（默认为3）
  terminationGracePeriodSeconds: 30	#job存活时间 默认不设置为永久
  jobTemplate:						#作业模板。这类似于工作示例