K8S—Pod控制器

戚风要谦虚

已于 2024-02-28 17:01:46 修改

阅读量1.1k

点赞数 7

文章标签： kubernetes 容器云原生

于 2024-02-28 17:01:31 首次发布

本文链接：https://blog.csdn.net/qq_64441401/article/details/136346630

版权

②为什么要有volumeClainTemplate？

③服务发现：就是应用服务之间相互定位的过程。

④K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

4.3 安装CoreDNS，仅二进制部署环境需要安装CoreDNS

无状态应用（Stateless Applications）：

有状态应用（Stateful Applications）：

常规 Service 和无头服务（Headless Service）的区别：

4.4 DaemonSet

4.5 Job

4.6 CronJob

1.什么是POD控制器

Pod控制器是 Kubernetes 中用于管理和控制 Pod 的重要资源，包括 ReplicaSet 和 Deployment 等。它们通过定义 Pod 模板来创建和管理 Pod 副本，实现自动扩缩容、滚动更新、故障恢复等功能。Pod 控制器负责监控 Pod 的运行状态，确保其符合用户定义的规则和策略。

Pod 控制器是 Kubernetes 应用生命周期管理的关键组件，提供了丰富的功能和灵活的配置选项，帮助用户轻松管理和运维应用程序的 Pod 资源。在 Pod 控制器中，用户可以指定副本数量、滚动更新策略、健康检查等参数，以确保应用程序的高可用性、伸缩性和稳定性。

总的来说，Pod 控制器是 Kubernetes 中实现工作负载管理的中间层，保证 Pod 资源处于预期状态。当 Pod 出现故障时，Pod 控制器会尝试重启或重新创建 Pod 资源，根据配置的重启策略进行相应的处理。这样可以确保应用程序持续可用并按照用户期望的方式运行。

2.POD控制器有几种类型

ReplicaSet：用于创建指定数量的 Pod 副本，确保 Pod 数量符合预期状态。主要组成包括用户定义的副本数量、标签选择器和根据 Pod 模板创建新的 Pod 资源。虽然 ReplicaSet 不是直接使用的控制器，但通常与 Deployment 结合使用。
Deployment：在 ReplicaSet 的基础上，用于管理无状态应用程序，支持滚动更新、回滚功能，并提供声明式配置。Deployment 是目前应用最广泛的控制器，逐渐取代之前的 ReplicationController。
DaemonSet：确保集群中每个节点运行特定的 Pod 副本，通常用于实现系统级后台任务。适用于无状态服务和守护进程类应用。
StatefulSet：用于管理有状态应用程序，为每个 Pod 分配唯一标识符，确保状态的稳定性和持久性。
Job：执行一次性任务，任务完成后立即退出，不需要重启或重新创建。适用于一次性作业。
CronJob：用于周期性任务控制，按照预定的时间表周期性地执行任务，不需要持续后台运行。

3.POD与控制器之间的关系

Pod 控制器在 Kubernetes 集群中起着至关重要的作用，用于管理和运行容器化应用程序的 Pod 对象。Pod 通过标签选择器（label-selector）与控制器相关联，控制器负责监控、调度和维护一组 Pod，确保它们符合用户定义的期望状态。

Pod 控制器为用户提供了一种抽象层，通过控制器可以实现对应用程序的运维管理，包括但不限于：

伸缩：控制器可以根据用户定义的策略自动扩展或缩减 Pod 的数量，以应对流量变化或负载情况。
升级：控制器支持滚动升级功能，可以逐步替换旧版本的 Pod 为新版本，确保应用程序的平稳升级。
故障恢复：当 Pod 发生故障或所在节点不可用时，控制器会重新调度 Pod 到其他可用节点上，确保应用程序的高可靠性。
负载均衡：控制器可以结合服务发现机制实现负载均衡，确保请求能够均匀分布到各个 Pod 上。

Pod 控制器是 Kubernetes 中实现应用程序管理和运维的核心组件，通过控制器可以轻松实现对应用程序的自动化管理，减少人工干预，提高系统的稳定性和可靠性。

4.示例

4.1 Deployment

部署无状态应用：Deployment 控制器通常用于部署无状态应用程序，它通过管理 Pod 和 ReplicaSet 来确保应用程序的可用性和健康运行。
管理 Pod 和 ReplicaSet：Deployment 控制器负责创建并管理多个 Pod 的副本（ReplicaSet），以确保根据用户定义的副本数来维持应用程序的运行状态。
具有上线部署、副本设定、滚动升级、回滚等功能：Deployment 控制器提供了丰富的功能，包括支持灰度发布（rolling updates）、副本数量配置、滚动升级（rolling upgrades）以及回滚到先前版本等操作。
提供声明式更新：Deployment 控制器支持声明式配置更新，用户可以只更新一个新的容器镜像（image），而不必关心具体的升级操作步骤，简化了应用程序的更新流程。
应用场景：Deployment 控制器适用于部署需要水平扩展、自动恢复、灵活升级的应用场景，特别适合用于部署 Web 服务等无状态应用程序。

Deployment 控制器是 Kubernetes 中用于管理应用程序部署和更新的关键组件，通过 Deployment 控制器，用户可以方便地进行应用程序的部署、扩展、更新和回滚，提高了应用程序的可靠性和可管理性。

vim nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx	
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

kubectl create -f nginx-deployment.yaml

kubectl get pods,deploy,rs

#查看控制器配置

kubectl edit deployment/nginx-deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-04-19T08:13:50Z"
  generation: 1
  labels:
    app: nginx					#Deployment资源的标签
  name: nginx-deployment
  namespace: default
  resourceVersion: "167208"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
  uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
  progressDeadlineSeconds: 600
  replicas: 3					#期望的pod数量，默认是1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
      maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
    type: RollingUpdate			#滚动升级
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx				#Pod副本关联的标签
    spec:
      containers:
      - image: nginx:1.15.4				#镜像名称
        imagePullPolicy: IfNotPresent	#镜像拉取策略
        name: nginx
        ports:
        - containerPort: 80				#容器暴露的监听端口
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always				#容器重启策略
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
......

#查看历史版本

kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

4.2 SatefulSet

部署有状态应用：StatefulSet 适用于需要持久化数据和稳定标识的有状态应用，如数据库、消息队列等。
稳定的持久化存储：StatefulSet 可以通过 PersistentVolumeClaim（PVC）来实现稳定的持久化存储，确保 Pod 在重新调度后仍能访问相同的持久化数据。
稳定的网络标志：通过 Headless Service（无 Cluster IP 的 Service）来实现稳定的网络标志，确保 Pod 在重新调度后其 PodName 和 HostName 不变。
有序部署和扩展：StatefulSet 支持有序部署和扩展，即在部署或者扩展时，Pod 将按照定义的顺序依次进行，init containers 可以用于确保有序性。
有序收缩和删除：StatefulSet 还支持有序收缩和删除，即在收缩或删除时，Pod 也将按照相反的顺序依次进行。

StatefulSet 提供了一种解决有状态应用部署和管理中的一些复杂性的方法，使得在 Kubernetes 集群中部署和运行有状态应用更加可靠和稳定。

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

注意：

根据上面提到的应用场景，可以总结出 StatefulSet 在 Kubernetes 中的关键组成部分和作用：

Headless Service（无头服务）：
- 用于为 StatefulSet 中每个 Pod 资源生成可解析的 DNS 记录。
- 每个 Pod 都具有唯一的标识符，并且可以通过 DNS 进行发现和通信。
- 提供了稳定的网络标识和服务发现机制，适用于需要直接访问每个 Pod 的场景。
volumeClaimTemplates（存储卷申请模板）：
- 基于静态或动态 PV 供给方式为 StatefulSet 中的 Pod 资源提供专有的固定存储。
- 通过定义存储卷申请模板，可以确保每个 Pod 都拥有独立的持久化存储，避免数据丢失和混乱。
- 支持在 Pod 重启或迁移时保持数据的持久性和一致性。
StatefulSet：
- 用于管控管理 StatefulSet 中的 Pod 资源，确保这些资源按照指定的顺序和规则被创建、更新和删除。
- 提供了有状态应用的部署和管理能力，适用于需要稳定标识、顺序部署和有状态数据处理的场景。
- 与 Deployment 类似，但更适合管理有状态应用，如数据库、缓存等需要持久化存储和稳定标识的服务。

通过组合使用 Headless Service、volumeClaimTemplates 和 StatefulSet，可以有效地部署和管理有状态应用，确保数据的持久性、可靠性和稳定性，并提供强大的服务发现和通信机制，满足不同场景下对有状态应用的需求。

①为什么要有headless？

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

②为什么要有volumeClainTemplate？

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

③服务发现：就是应用服务之间相互定位的过程。

应用场景：

自动关联：Kubernetes 集群中的 Pod 可以通过 DNS 来解析 Service 的名称，无需手动配置 IP 地址，从而实现自动关联。
动态性强：由于 Pod 可能会在集群中的不同节点上飘移，使用 DNS 可以保证无论 Pod 在哪个节点上，都能够通过 Service 名称来访问其他服务。
更新发布频繁：由于互联网应用的小步快跑特点，Service 的更新和发布频繁，使用 DNS 可以确保服务在更新后仍然可以被其他服务发现和访问。
支持自动伸缩：Kubernetes 中的自动伸缩功能可以根据负载情况动态调整 Pod 的数量，而使用 DNS 可以确保新增或减少的 Pod 能够被自动发现并加入到服务发现机制中。

使用 DNS 服务进行服务发现可以极大地简化应用程序的部署和扩展，并且适应了动态性强、更新发布频繁和自动伸缩等场景的需求。

④K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

对于不同版本的 Kubernetes，有不同的 DNS 插件来实现服务发现功能：

SkyDNS：适用于 Kubernetes 1.3 之前的版本。SkyDNS 基于 etcd 存储 DNS 记录，通过 Go 语言实现，是早期 Kubernetes 版本中用于服务发现的默认插件。
kube-dns：适用于 Kubernetes 1.3 到 Kubernetes 1.11 的版本。kube-dns 包含 kube-dns、dns-masq 和 sidecar 三个组件，通过 etcd 存储 DNS 记录，并使用轻量级的 DNS 服务器 dns-masq 进行缓存。
CoreDNS：适用于 Kubernetes 1.11 版本及以后。CoreDNS 是一个功能强大且可扩展的 DNS 服务器，支持多种协议和后端存储，取代了 kube-dns 成为默认的 DNS 插件，具有更好的性能和可扩展性。

这些 DNS 插件都能够实现将 Service 的名称映射到 ClusterIP 地址，使得在 Kubernetes 集群中，应用服务可以通过使用 Service 的名称来发现和相互通信，而无需直接暴露 IP 地址或进行复杂的手动配置。这样便于管理和维护整个集群的服务发现机制。

4.3 安装CoreDNS，仅二进制部署环境需要安装CoreDNS

#上传 coredns.yaml 文件

kubectl create -f coredns.yaml

kubectl get pods -n kube-system

vim nginx-service.yaml

apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx

kubectl create -f nginx-service.yaml

kubectl get svc

vim pod6.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never
  
kubectl create -f pod6.yaml

#解析kubernetes和nginx-service名称

kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

#查看statefulset的定义

kubectl explain statefulset

kubectl explain statefulset.spec

KIND:     StatefulSet
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired identities of pods in this set.

     A StatefulSetSpec is the specification of a StatefulSet.

FIELDS:
   podManagementPolicy	<string>  #Pod管理策略
   replicas	<integer>    #副本数量
   revisionHistoryLimit	<integer>   #历史版本限制
   selector	<Object> -required-    #选择器，必选项
   serviceName	<string> -required-  #服务名称，必选项
   template	<Object> -required-    #模板，必选项
   updateStrategy	<Object>       #更新策略
   volumeClaimTemplates	<[]Object>   #存储卷申请模板，必选项

#清单定义StatefulSet
如上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。如下资源清单中的定义：

vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  labels:
    app: myapp-svc
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp-svc
  replicas: 3
  selector:
    matchLabels:
      app: myapp-pod
  template:
    metadata:
      labels:
        app: myapp-pod
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: myappdata
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: myappdata
	  annotations:          #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 2Gi

解析上例：由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。
#创建pv：stor01节点

mkdir -p /data/volumes/v{1,2,3,4,5}

vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)


systemctl restart rpcbind
systemctl restart nfs

exportfs -arv

showmount -e

#定义PV

vim pv-demo.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: stor01
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

kubectl apply -f pv-demo.yaml

kubectl get pv

#创建statefulset

kubectl apply -f stateful-demo.yaml 

kubectl get svc  #查看创建的无头服务myapp-svc

kubectl get sts    #查看statefulset

kubectl get pvc    #查看pvc绑定

kubectl get pv    #查看pv绑定

kubectl get pods   #查看Pod信息

kubectl delete -f stateful-demo.yaml

#当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭

kubectl get pods -w

#此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc

kubectl apply -f stateful-demo.yaml

kubectl get pvc

#滚动更新

#StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。

vim stateful-demo.yaml  		#修改image版本为v2
.....
image: ikubernetes/myapp:v2
....

kubectl apply -f stateful-demo.yaml

kubectl get pods -w   #查看滚动更新的过程

#在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的

kubectl exec -it myapp-0 /bin/sh

#从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：

(pod_name).(service_name).(namespace_name).svc.cluster.local

无状态应用（Stateless Applications）：

Deployment 视所有的 Pod 都是相同的，可以随意创建和销毁。
无需考虑执行顺序或特定节点上的运行。
可以随意扩展和缩减副本数量，适用于横向扩展。
适合处理请求和响应，对数据的持久性要求不高。

有状态应用（Stateful Applications）：

每个实例都有独特的特性和元数据，如 etcd、ZooKeeper 等。
实例之间存在差异，依赖外部存储，要求数据持久性和稳定性。
不同实例之间可能需要维护状态或连接关系。

常规 Service 和无头服务（Headless Service）的区别：

Service：为一组 Pod 提供统一的访问入口，提供负载均衡、服务发现和集群内通信。具有 ClusterIP，通过该 ClusterIP 可以访问 Service 提供的服务。
Headless Service：无头服务，不分配 ClusterIP，而是通过 DNS 记录直接暴露每个 Pod 的 IP 地址。适用于需要直接访问 Pod IP 或进行 Pod 级别的服务发现的场景，不提供负载均衡功能。

vim pod6.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never


vim sts.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:
  name: nginx-statefulset  
  namespace: default
spec:
  serviceName: nginx  
  replicas: 3  
  selector:
    matchLabels:  
       app: nginx
  template:  
    metadata:
      labels:
        app: nginx  
    spec:
      containers:
      - name: nginx
        image: nginx:latest  
        ports:
        - containerPort: 80  


kubectl apply -f sts.yaml

kubectl apply -f pod6.yaml

kubectl get pods,svc

kubectl exec -it dns-test sh

kubectl exec -it nginx-statefulset-0 bash

#扩展伸缩

kubectl scale sts myapp --replicas=4  #扩容副本增加到4个

kubectl get pods -w  #动态查看扩容

kubectl get pv  #查看pv绑定

kubectl patch sts myapp -p '{"spec":{"replicas":2}}'  #打补丁方式缩容

kubectl get pods -w  #动态查看缩容

4.4 DaemonSet

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

自动部署和回收：当新的节点加入集群时，DaemonSet 会为其创建相应的 Pod，而当节点从集群移除时，DaemonSet 也会回收相应的 Pod。
全局部署：DaemonSet 确保在整个集群范围内都有相同数量的 Pod 实例在运行，无论节点数量如何变化。
典型用途：DaemonSet 的典型应用场景包括运行集群存储 daemon、日志收集 daemon、监控 daemon 等，这些都是需要在每个节点上运行一个实例的应用程序。
应用场景：在 Agent 场景下，DaemonSet 特别适合用来部署运行在每个节点上的代理程序，例如服务发现代理、监控代理、日志收集代理等，确保在整个集群范围内都有这些代理程序的实例在运行。

vim ds.yaml 

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.15.4
        ports:
        - containerPort: 80

kubectl apply -f ds.yaml

#DaemonSet会在每个node节点都创建一个Pod

kubectl get pods

4.5 Job

Job：Job 是 Kubernetes 中用于运行一次性任务的控制器。它确保一个或多个 Pod 成功完成任务后终止，并且能够处理任务失败时的重试和并行处理等情况。

CronJob：CronJob 是基于时间表达式的定时任务控制器，允许用户在指定的时间间隔内运行 Job。通过 CronJob，用户可以轻松地设置定时任务，例如每天凌晨执行一次备份任务。

应用场景：Job 和 CronJob 在很多场景下非常有用，包括数据库迁移、批处理脚本的执行、安全扫描（如 kube-bench）、离线数据处理以及视频解码等业务需求。这些任务通常是一次性的、定时的或者需要在集群中定期执行的。

vim job.yaml

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

注意：

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

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

docker pull perl

kubectl apply -f job.yaml 

kubectl get pods

#结果输出到控制台

kubectl logs pi-bqtf7

#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
  
kubectl apply -f job-limit.yaml

kubectl get job,pods

kubectl describe job busybox

4.6 CronJob

CronJob 是一种周期性任务控制器，类似于 Linux 中的 Crontab，允许用户根据预定的时间表达式来执行作业。一些常见的应用场景包括发送通知、执行备份等需要定期执行的任务。

#每分钟打印hello

vim cronjob.yaml

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

注意：cronjob其它可用参数的配置

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

kubectl create -f cronjob.yaml 

kubectl get cronjob

kubectl get pods

戚风要谦虚

关注

7
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
K8S—Pod控制器

Pod控制器是 Kubernetes 中用于管理和控制 Pod 的重要资源，包括 ReplicaSet 和 Deployment 等。它们通过定义 Pod 模板来创建和管理 Pod 副本，实现自动扩缩容、滚动更新、故障恢复等功能。Pod 控制器负责监控 Pod 的运行状态，确保其符合用户定义的规则和策略。Pod 控制器是 Kubernetes 应用生命周期管理的关键组件，提供了丰富的功能和灵活的配置选项，帮助用户轻松管理和运维应用程序的 Pod 资源。
复制链接

扫一扫