Kubernetes集群Pod控制器

前言

在 K8s 集群中，Pod 控制器是一种关键的组件，负责管理和控制Pod的生命周期。Pod 是 K8s 中最小的可部署单元，通常包含一个或多个容器，Pod 控制器则确保所需数量的 Pod 实例处于运行状态，并根据定义的规则进行自动扩展或缩减。本文将介绍 K8s 集群中 Pod 控制器的定义、类型以及 Pod 与控制器之间的关系。

目录

一、Pod 控制器介绍

1. 概述及作用

2. pod 控制器的类型

2.1 ReplicaSet

2.2 Deployment

2.3 DaemonSet

2.4 StatefulSet

2.5 Jop

2.6 CronJob

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

二、控制器管理 Pod 示例 

1. Deployment 部署无状态应用

2. SatefulSet 部署有状态应用 

2.1 SatefulSet 三个组件

2.2 实现 K8S 里 DNS 功能的插件

2.3 解析 kubernetes 和 nginx-service 名称

2.4 查看 statefulset 的定义

2.5 清单定义 StatefulSet

2.5.1 定义资源清单

2.5.2 创建 statefulset 

2.5.3 删除 statefulset 

2.6 滚动更新

3. DaemonSet 一次创建多节点 

三、总结

一、Pod 控制器介绍

1. 概述及作用

概述：

Pod 控制器是一种 K8s 对象，设计用于管理和维护 Pod 实例。它们不是直接操作 Pod，而是通过与 K8s API 交互来间接控制 Pod，从而保证即使面对节点故障、Pod 终止或其他意外情况，也能维持应用的高可用性和期望的部署配置。

作用：

自动扩缩容

  • 根据预设策略自动增加或减少Pod副本的数量，以应对负载变化或确保服务的高可用性。

自我修复

  • 当检测到Pod由于各种原因（如节点故障、容器崩溃）不再运行时，控制器会自动创建新的Pod副本以替换故障实例，保持预期的Pod数量和配置。

滚动更新

  • 在不中断服务的情况下，逐步将Pod升级到新版本的应用镜像，通过逐步替换旧Pod来平滑过渡。

版本控制

  • 管理应用的多个版本，允许快速回滚到之前的版本。

有序部署和管理

  • 对于有状态应用，如数据库，使用StatefulSet控制器来确保Pod按顺序创建和销毁，维护稳定的网络标识符和存储卷。

定时任务

  • CronJob控制器能够根据预定的计划时间自动创建Job来执行一次性任务，适用于定期执行的任务，如数据备份、报表生成等。

资源组织和命名空间管理

  • 帮助组织和隔离不同的应用或服务资源，便于团队协作和资源分配。

2. pod 控制器的类型

常见的 Pod 控制器类型包括 ReplicaSet、Deployment、DaemonSet、StatefulSet、Job 和 CronJob 等。

2.1 ReplicaSet

确保在任何给定时间都有指定数量的 Pod 副本在运行，确保 Pod 副本数量符合期望值，并且支持滚动式自动扩容和缩容功能。主要三个组件组成：

  • 用户期望的 pod 副本数量
  • 标签选择器，判断哪个 pod 归自己管理
  • 当现存的 pod 数量不足，会根据 pod 资源模板进行新建

2.2 Deployment

它建立在 ReplicaSet 之上，提供了额外的功能，如滚动更新、暂停/恢复更新、版本回滚等。

2.3 DaemonSet

确保每个节点上都运行着一个指定的 Pod 实例，比如日志收集、监控代理等。当有新的节点加入集群时，DaemonSet 会自动在新节点上创建 Pod；节点从集群移除时，对应的 Pod 也会被清理。

2.4 StatefulSet

管理有状态应用设计，如数据库、需要持久化存储和稳定的网络标识（如： CEPH）。StatefulSet 中的每个 Pod 都有唯一的、持久的标识符和稳定的存储卷。它确保 Pod 按顺序启动和关闭（理论上是倒序），且在重启后仍能访问相同的存储资源，这对于维护数据一致性至关重要。

2.5 Jop

用于运行完成特定次数后终止的 Pod，即执行一次性或批处理任务。只要完成就立即退出，不需要重启或重建。

2.6 CronJob

周期性任务控制，基于时间调度来定期执行 Job，类似于Linux的cron定时任务，不需要持续后台运行。

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

Controllers （控制器）是管理和运行容器的 Pod 对象的实体，在集群中，Pod 通过 Label Selector （标签与选择器）进行相关联。它们通过控制器来实现应用的运维任务，例如伸缩和升级。

可以理解为：Pod 与控制器之间是一种管理和被管理的关系，控制器利用 K8s 的标签系统来识别和控制其管理的 Pod 集合，从而实现了应用的自动化运维和高可用性。

二、控制器管理 Pod 示例 

1. Deployment 部署无状态应用

部署并维护一个由3个副本组成的 Nginx 服务，管理 Pod 和 ReplicaSet；应用场景：web服务。

① 定义 yaml 配置

[root@master01 controller]# vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx	
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14ports:- containerPort: 80

② 创建控制器

[root@master01 controller]# kubectl apply -f nginx-deployment.yaml

③ 获取集群中Pods、Deployments、以及 ReplicaSets 的信息

[root@master01 controller]# kubectl get pod,deploy,rs
NAME                                          READY   STATUS    RESTARTS   AGE
pod/nfs-client-provisioner-5f7484cd44-ls45v   1/1     Running   0          14h
pod/nginx-deployment-d9d8cf5c7-j2c8p          1/1     Running   0          50s
pod/nginx-deployment-d9d8cf5c7-mf578          1/1     Running   0          50s
pod/nginx-deployment-d9d8cf5c7-xqh57          1/1     Running   0          50s
NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment         3/3     3            3           50s
# READY: 表示期望的Pod副本中有多少是Ready状态。3/3意味着所有3个副本都已准备就绪，可以接收请求。
# UP-TO-DATE: 表示已经更新到最新配置的Pod副本数量，这里也是3，说明没有正在进行的更新操作或所有Pod都已经是最新配置。
# AVAILABLE: 表示当前可用的Pod副本数量，同样为3，说明服务完全可用。
# AGE: 显示了Deployment被创建的时间，这里是50秒。NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-d9d8cf5c7          3         3         3       50s
# DESIRED: 表示ReplicaSet期望维持的Pod副本数量，这里是3。
# CURRENT: 实际存在的Pod副本数量，也是3，符合期望。
# READY: 准备好提供服务的Pod副本数量，3个副本都已就绪。

④ 查看控制器配置

kubectl edit deployment/nginx-deploymentlabels:app: nginx			    # Deployment资源的标签replicas: 3				#期望的pod数量，默认是1rollingUpdate:maxSurge: 25%		    # 升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值maxUnavailable: 25%	# 升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值type: RollingUpdate		# 滚动升级spec:template:labels:app: nginx			# Pod副本关联的标签spec:containers:- image: nginx:1.14				#镜像名称imagePullPolicy: IfNotPresent	#镜像拉取策略ports:- containerPort: 80				#容器暴露的监听端口restartPolicy: Always				#容器重启策略

⑤ 查看历史版本

[root@master01 controller]# kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>

小结：

deployment 部署无状态应用的管理 ReplicaSet 和 Pod 并创建 Pod，主要维护 Pod 副本数量与期望值相同；创建和删除 Pod 时，并行执行，升级时也会创建一部分再删除一部分。

2. SatefulSet 部署有状态应用 

  • 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现；
  • 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即无头模式，利用 DNS 来解析 Service，没有Cluster IP的Service）来实现；
  • 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现；
  • 有序收缩，有序删除（即从N-1到0）。 

 常见的应用场景：数据库StatefulSets | Kubernetes

2.1 SatefulSet 三个组件

  • Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
  • volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
  • StatefulSet：用于管控Pod资源。

（1）为什么要有headless？

  • 在deployment中，每一个pod是没有名称，是随机字符串，是无序的；
  • 而statefulset中是要求有序的，每一个pod的名称必须是固定的；

当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。

为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

（2）为什么要有volumeClainTemplate？

大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点；

  • 在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷；
  • 而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

2.2 实现 K8S 里 DNS 功能的插件

skyDNS：Kubernetes 1.3之前的版本

kubeDNS：Kubernetes 1.3至Kubernetes 1.11

CoreDNS：Kubernetes 1.11开始至今

2.3 解析 kubernetes 和 nginx-service 名称

创建一个service，然后用dns去测试解析。

① 定义 nginx-svc yaml

[root@master01 controller]# vim nginx-service.yaml
apiVersion: v1  
kind: Service  
metadata:name: nginx-servicelabels:app: nginx  
spec:type: NodePort  ports:- port: 80targetPort: 80  selector:app: nginx

② 创建 nginx-svc

[root@master01 controller]# kubectl apply -f nginx-service.yaml 
service/nginx-service created[root@master01 controller]# kubectl get svc
nginx-service      NodePort    10.96.193.207   <none>        80:32037/TCP      7s

③ 定义一个dns-pod yaml

[root@master01 controller]# vim dns-test.yaml
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4  #一个小型的Unix工具集合，常用于测试和基础任务args:- /bin/sh- -c- sleep 36000          #让容器运行后休眠36000秒restartPolicy: Never     #指定了Pod的重启策略

④ 创建 pod

[root@master01 controller]# kubectl apply -f dns-test.yaml
[root@master01 controller]# kubectl get pod
NAME                                      READY   STATUS      RESTARTS   AGE
dns-test                                  1/1     Running     0          48s

⑤ 进入容器测试解析

[root@master01 controller]# 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.localName:      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.localName:      nginx-service
Address 1: 10.96.193.207 nginx-service.default.svc.cluster.local

2.4 查看 statefulset 的定义

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

2.5 清单定义 StatefulSet

如上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。定义了一个Kubernetes StatefulSet资源和一个Headless Service（无头服务），用于部署一个有状态应用：

2.5.1 定义资源清单
[root@master01 controller]# vim stateful-demo.yaml 
apiVersion: v1
kind: Service
metadata:name: myapp-svclabels:app: myapp-svc
spec:ports:- port: 80name: webclusterIP: None   #None表明这是一个无头服务，没有Cluster IP分配，直接返回关联Pod的IP列表selector:app: myapp-pod  #用于选择带有此标签的Pods，与后续的StatefulSet关联
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:       #为Pod定义标签，与selector匹配app: myapp-podtemplate:metadata:labels:app: myapp-podspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: myappdatamountPath: /usr/share/nginx/html #挂载卷myappdata到/usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: myappdataannotations:         
#动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: ["ReadWriteOnce"]  #定义访问模式resources:requests:storage: 2Gi

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

2.5.2 创建 statefulset 
[root@master01 controller]# kubectl apply -f stateful-demo.yaml查看创建的无头服务myapp-svc：
[root@master01 controller]# kubectl get svc
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE
kubernetes         ClusterIP   10.96.0.1       <none>        443/TCP           14d
myapp-svc          ClusterIP   None            <none>        80/TCP            32m查看statefulset：
[root@master01 controller]# kubectl get sts
NAME    READY   AGE
myapp   3/3     24m查看pvc绑定：
[root@master01 controller]# kubectl get pvc
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS              AGE
myappdata-myapp-0   Bound    pvc-d9b33a5b-076e-4a17-b457-03d7b50d08b7   2Gi        RWO            nfs-client-storageclass   25m
myappdata-myapp-1   Bound    pvc-4748da6b-1c81-45c0-9b50-a20898cc5f11   2Gi        RWO            nfs-client-storageclass   5m51s
myappdata-myapp-2   Bound    pvc-a4999f31-ab02-4640-913e-c6cf19ccf7a0   2Gi        RWO            nfs-client-storageclass   5m46s查看pv绑定：
[root@master01 controller]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS              REASON   AGE
pvc-4748da6b-1c81-45c0-9b50-a20898cc5f11   2Gi        RWO            Delete           Bound    default/myappdata-myapp-1   nfs-client-storageclass            8m14s
pvc-a4999f31-ab02-4640-913e-c6cf19ccf7a0   2Gi        RWO            Delete           Bound    default/myappdata-myapp-2   nfs-client-storageclass            8m9s
pvc-d9b33a5b-076e-4a17-b457-03d7b50d08b7   2Gi        RWO            Delete           Bound    default/myappdata-myapp-0   nfs-client-storageclass            8m26s查看Pod信息：
[root@master01 controller]# kubectl get pods
NAME                                      READY   STATUS    RESTARTS   AGE
myapp-0                                   1/1     Running   0          27m
myapp-1                                   1/1     Running   0          8m39s
myapp-2                                   1/1     Running   0          8m34s
2.5.3 删除 statefulset 

当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭（不过一般是同时删除）；然后再次创建，观察 pod 创建详情：

[root@master01 volumes]# kubectl get pod -w
NAME                                      READY   STATUS    RESTARTS   AGE
myapp-0                                   1/1     Running   0          32m
myapp-1                                   1/1     Running   0          12m
myapp-2                                   1/1     Running   0          12m
nfs-client-provisioner-5f7484cd44-ft5lv   1/1     Running   0          13m
myapp-1                                   1/1     Terminating   0          14m
myapp-2                                   1/1     Terminating   0          14m
myapp-0                                   1/1     Terminating   0          34m
myapp-1                                   0/1     Terminating   0          14m
myapp-2                                   0/1     Terminating   0          14m
myapp-0                                   0/1     Terminating   0          34m
myapp-1                                   0/1     Terminating   0          14m
myapp-1                                   0/1     Terminating   0          14m
myapp-2                                   0/1     Terminating   0          14m
myapp-2                                   0/1     Terminating   0          14m
myapp-0                                   0/1     Terminating   0          34m
myapp-0                                   0/1     Terminating   0          34m
myapp-0                                   0/1     Pending       0          0s
myapp-0                                   0/1     Pending       0          0s
myapp-0                                   0/1     ContainerCreating   0          0s
myapp-0                                   1/1     Running             0          2s
myapp-1                                   0/1     Pending             0          0s
myapp-1                                   0/1     Pending             0          0s
myapp-1                                   0/1     ContainerCreating   0          0s
myapp-1                                   1/1     Running             0          2s
myapp-2                                   0/1     Pending             0          0s
myapp-2                                   0/1     Pending             0          0s
myapp-2                                   0/1     ContainerCreating   0          0s
myapp-2                                   1/1     Running             0          2s

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

[root@master01 controller]# kubectl get pvc
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS              AGE
myappdata-myapp-0   Bound    pvc-d9b33a5b-076e-4a17-b457-03d7b50d08b7   2Gi        RWO            nfs-client-storageclass   36m
myappdata-myapp-1   Bound    pvc-4748da6b-1c81-45c0-9b50-a20898cc5f11   2Gi        RWO            nfs-client-storageclass   17m
myappdata-myapp-2   Bound    pvc-a4999f31-ab02-4640-913e-c6cf19ccf7a0   2Gi        RWO            nfs-client-storageclass   17m

2.6 滚动更新

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

① 修改 yaml 定义

[root@master01 controller]# vim stateful-demo.yaml
……image: nginx:1.18.0     # 原来是1.14
……

② 更新 svc yaml

[root@master01 controller]# kubectl apply -f stateful-demo.yaml

③ 查看滚动更新的过程

[root@master01 volumes]# kubectl get pod -w
NAME                                      READY   STATUS    RESTARTS   AGE
myapp-0                                   1/1     Running   0          12s
myapp-1                                   1/1     Running   0          9s
myapp-2                                   1/1     Running   0          7s
nfs-client-provisioner-5f7484cd44-ft5lv   1/1     Running   0          29m
myapp-2                                   1/1     Terminating   0          51s
myapp-2                                   0/1     Terminating   0          52s
myapp-2                                   0/1     Terminating   0          53s
myapp-2                                   0/1     Terminating   0          53s
myapp-2                                   0/1     Pending       0          0s
myapp-2                                   0/1     Pending       0          0s
myapp-2                                   0/1     ContainerCreating   0          0s
myapp-2                                   1/1     Running             0          2s
myapp-1                                   1/1     Terminating         0          57s
myapp-1                                   0/1     Terminating         0          58s
myapp-1                                   0/1     Terminating         0          59s
myapp-1                                   0/1     Terminating         0          59s
myapp-1                                   0/1     Pending             0          0s
myapp-1                                   0/1     Pending             0          0s
myapp-1                                   0/1     ContainerCreating   0          0s
myapp-1                                   1/1     Running             0          2s
myapp-0                                   1/1     Terminating         0          64s
myapp-0                                   0/1     Terminating         0          65s
myapp-0                                   0/1     Terminating         0          66s
myapp-0                                   0/1     Terminating         0          66s
myapp-0                                   0/1     Pending             0          0s
myapp-0                                   0/1     Pending             0          0s
myapp-0                                   0/1     ContainerCreating   0          0s
myapp-0                                   1/1     Running             0          2s

④ 进入 dns-test Pod中，每一个 pod 自己的名称都是可以被解析的

[root@master01 controller]# kubectl exec -it  dns-test sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # nslookup myapp-svc
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      myapp-svc
Address 1: 10.244.2.40 myapp-0.myapp-svc.default.svc.cluster.local
Address 2: 10.244.2.39 myapp-1.myapp-svc.default.svc.cluster.local
Address 3: 10.244.1.201 myapp-2.myapp-svc.default.svc.cluster.local
/ # nslookup  myapp-0.myapp-svc.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.40 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup  myapp-1.myapp-svc.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName:      myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.39 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup  myapp-2.myapp-svc.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

3. DaemonSet 一次创建多节点 

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

使用 DaemonSet 的一些典型用法：

  • 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
  • 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
  • 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

应用场景：Agent

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

示例：

[root@master01 data]# vim ds.yaml
apiVersion: apps/v1
kind: DaemonSet 
metadata:name: nginx-daemonsetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14ports:- containerPort: 80[root@master01 data]# kubectl apply -f ds.yamlDaemonSet会在每个node节点都创建一个Pod：
[root@master01 data]# kubectl get pod -o wide
nginx-daemonset-bqmtg                     1/1     Running   0          15s     10.244.1.202   node01   <none>           <none>
nginx-daemonset-n89xc                     1/1     Running   0          15s     10.244.2.42    node02   <none>           <none>

三、总结

1. Pod 控制器

① deployment 部署无状态应用的管理 RS 和 pod 创建 Pod ，主要是维护 pod 副本数量与期望状态相同；创建和删除 pod 时并行执行升级时是想创建一部分，再删除一部分；

② statefulset 部署有状态的应用，每个 pod 名称唯一且不变，每个 pod 拥有自己专属的持久化的存储（PVC 和 PV）在 k8s 集群内部可以通过{pod_name}.{service_name}.{namespace).svc.cluster.local 解析出 pod 的 IP（基于 headless service 和 coreDNS）创建和删除 pod 是有顺序的(串行执行的)，升级时串行执行的，会删除旧的 pod，再创建新 pod；删除和升级是逆序执行的（先从标识符最大的 n-1开始，一直到最小的0）；

③ Daemonset 理论上在 k8s 集群的所有 node 节点上创建相同的 pod（无论 node 节点什么时候加入到 k8s 集群），但是会收到 node 节点上污点影响；

④ 部署一次性任务的 pod，正常完成后容器立即退出并且不重启容器（restartpolicy 不设置Always），也不会重建，异常完成后重试任务，重建次数根据 backofflimit 配置指定（默认为6次）；

⑤ cronjob 周期性的部署任务的 pod，正常完成后容器会立即退出并不会重启容器（restartPolicy 不设置 Always)，也不会重键 pod schedule 配置周期的性的事件表（*****分时日月周）。

无状态：
1）deployment 认为所有的pod都是一样的
2）不用考虑顺序的要求
3）不用考虑在哪个node节点上运行
4）可以随意扩容和缩容 有状态
1）实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
2）实例之间不对等的关系，以及依靠外部存储的应用。常规service和无头服务区别
service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/847097.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Vuforia AR篇（五）— 地平面检测

Vuforia AR篇（五）— 地平面检测

目录 前言一、什么是地平面识别&#xff1f;二、使用步骤三、示例代码四、效果五、总结 前言 在增强现实&#xff08;AR&#xff09;应用程序的开发中&#xff0c;地平面识别是一项关键技术&#xff0c;它允许虚拟对象与现实世界的地面进行互动。Vuforia 是一个功能强大的 AR …
阅读更多...
Centos7安装Docker和DockerCompose

Centos7安装Docker和DockerCompose

1.CentOS安装Docker Docker CE 支持 64 位版本 CentOS 7&#xff0c;并且要求内核版本不低于 3.10&#xff0c; CentOS 7 满足最低内核的要求&#xff0c;所以我们在CentOS 7安装Docker。 1.1.卸载&#xff08;可选&#xff09; 如果之前安装过旧版本的Docker&#xff0c;可以…
阅读更多...
python项目中requirements.txt文件使用

python项目中requirements.txt文件使用

由于之前用的技术栈是java&#xff0c;后续项目中需要逐渐用起python&#xff0c;但是很多地方只会用&#xff0c;没太了解过本质作用是什么&#xff0c;这里总结下 requirements.txt 一.作用 requirements.txt 文件是 Python 项目中常见的文件&#xff0c;用于列出项目所需…
阅读更多...
【Linux】深入理解进程的优先级（Linux 2.6版本O(1)调度算法）

【Linux】深入理解进程的优先级（Linux 2.6版本O(1)调度算法）

进程的优先级 【前置知识】一、进程的优先级(一&#xff09;为什么要有优先级&#xff1f;&#xff08;二&#xff09;进程的优先级的范围 二、操作系统是如何实现进程的优先级&#xff1f;&#xff08;Linux内核2.6版本O(1)调度算法&#xff09; 【前置知识】 首先我们要了解…
阅读更多...
FFmpeg 中 Filters 使用文档介绍

FFmpeg 中 Filters 使用文档介绍

描述 这份文档描述了由libavfilter库提供的过滤器Filters、源sources和接收器sinks。 滤镜介绍 FFmpeg通过libavfilter库启用过滤功能。在libavfilter中，一个过滤器可以有多个输入和多个输出。为了说明可能的类型，我们考虑以下过滤器图： 这个过滤器图将输入流分成两个流，然…
阅读更多...
补上缺失的一环----一种数据库系统主动对外推送表的增删改实时变动数据的实践

补上缺失的一环----一种数据库系统主动对外推送表的增删改实时变动数据的实践

在实践中&#xff0c;一些应用程序或模块需要实时获取某些数据库表的增删改变动数据。 对此需求&#xff0c;常见的方案有: 1、应用程序通过轮循查询数据库方式获取数据库表的增删改变动数据. 2、应用程序在把数据写入数据库表之前&#xff0c;通过事件方式向外通知数据库表的增…
阅读更多...
OZON的选品工具，OZON选品工具推荐

OZON的选品工具，OZON选品工具推荐

在电商领域&#xff0c;选品一直是决定卖家成功与否的关键因素之一。随着OZON平台的崛起&#xff0c;越来越多的卖家开始关注并寻求有效的选品工具&#xff0c;以帮助他们在这个竞争激烈的市场中脱颖而出。本文将详细介绍OZON的选品工具&#xff0c;并推荐几款实用的辅助工具&a…
阅读更多...
redis之发布与订阅

redis之发布与订阅

华子目录 什么是发布与订阅&#xff1f;常用命令psubscribe pattern1 [pattern2...]subscribe channel1 [channel2...]publish channel messagepunsubscribe pattern1 [pattern2...]unsubscribe [channel1 [channel2...]]pubsub subcommand argument1 [argument2...] 示例1示例…
阅读更多...
ESP使用巴法云远程OTA（VScode + Platform io）

ESP使用巴法云远程OTA（VScode + Platform io）

ESP使用巴法云远程OTA&#xff08;Platform&#xff09; 什么是OTA&#xff1a; OTA&#xff08;Over-the-AirTechnology&#xff09;即空中下载技术&#xff0c;是通过移动通信的空中接口实现对移动终端设备及SIM卡数据进行远程管理的技术。OTA升级是物联网&#xff08;IOT&am…
阅读更多...
如何使用前端表格控件实现多数据源整合？

如何使用前端表格控件实现多数据源整合？

前言 作为表格产品的典型应用场景之一&#xff0c;几乎所有的行业都会存在类 Excel 报表开发这样的应用场景&#xff0c;而在这些应用场景中&#xff0c;经常会遇见下面的这些痛点&#xff1a; 报表数据往往来自多个不同的数据源&#xff0c;需要报表系统能够同时连接多个数据源…
阅读更多...
AI的制作思维导图

AI的制作思维导图

AI&#xff08;人工智能&#xff09;的实现通常涉及以下几个步骤&#xff1a; 1.问题定义&#xff1a;首先确定你想要解决的问题是什么&#xff0c;这将决定你需要设计什么样的系统。 2.数据收集&#xff1a;根据你的需求&#xff0c;收集相关的数据集来训练你的AI模型。数据的…
阅读更多...
x264 编码器中 PTS 与 DTS 原理分析

x264 编码器中 PTS 与 DTS 原理分析

DTS和PTS 解释 DTS：Decoding Time Stamp，这通常指的是解码时间戳，是视频帧或音频样本在解码器中解码的时间点。DTS用于确保视频帧或音频样本在正确的时间被解码，以保持视频和音频的同步。PTS：Presentation Time Stamp，是指显示时间戳，是视频帧或音频样本应该被显示给观众…
阅读更多...
Unity有限状态机实现怪物AI(代码框架思路)

Unity有限状态机实现怪物AI(代码框架思路)

目录 状态的枚举 状态基类 接口(规范不同对象的同一行为) 状态机类(作为媒介用于管理各个状态之间的转换) 附带一个攻击状态的子类脚本作为示例: 状态的枚举 首先最容易想到的是状态的枚举,比如说攻击状态、巡逻状态、追击状态等等,用枚举进行表示 public enum E_AI_State…
阅读更多...
前端工程化工具系列

前端工程化工具系列

所有和前端工程化工具的系列合集&#xff0c;快速提升开发效率。文档持续更新中&#xff0c;敬请期待&#xff5e;感兴趣的可收藏 前端工程化 这个专栏 已完成 前端工程化工具系列&#xff08;一&#xff09;—— ESLint(v9.4.0)&#xff1a;代码质量守护者 基础篇 前端工程化…
阅读更多...
AI技术从起源到革命性的未来

AI技术从起源到革命性的未来

在科技日新月异的今天&#xff0c;huizerc.com人工智能&#xff08;AI&#xff09;技术已成为推动社会进步的重要力量。从最初的概念提出&#xff0c;到如今的广泛应用&#xff0c;AI技术经历了漫长而曲折的发展历程。本文将深入探讨AI技术的起源、发展历程、当前应用以及未来展…
阅读更多...
Vue——模板引用(不建议使用，了解)

Vue——模板引用(不建议使用，了解)

文章目录 前言测试案例 前言 模板引用&#xff0c;在官方文档中也有很详细的描述。 虽然 Vue 的声明性渲染模型为你抽象了大部分对 DOM 的直接操作&#xff0c;但在某些情况下&#xff0c;我们仍然需要直接访问底层 DOM 元素。 个人理解为&#xff1a; 在vue中&#xff0c;依据…
阅读更多...
【数据库系统概论】程序题

【数据库系统概论】程序题

“学生管理数据库”包含以下三个表，即学生表Student、课程表Course和选课表SC，结构如下： Student（Sno，Sname，Ssex，Sage，Sdept）Course （Cno，Cname，Cpno，Ccredit）SC（Sno，Cno，Grade)其中，Sno为学号，Sname为学生姓名，Ssex为性别，Sage为年龄 系别：Cno为课程号…
阅读更多...
Milvus 基本操作

Milvus 基本操作

1、maven 依赖 <dependency><groupId>io.milvus</groupId><artifactId>milvus-sdk-java</artifactId><version>2.3.3</version><exclusions><exclusion><groupId>org.slf4j</groupId><artifactId>sl…
阅读更多...
STL容器--list

STL容器--list

1. list的介绍及使用 1.1 list的介绍 1. list是可以在常数范围内在任意位置进行插入和删除的序列式容器&#xff0c;并且该容器可以前后双向迭代。 2. list的底层是双向链表结构&#xff0c;双向链表中每个元素存储在互不相关的独立节点中&#xff0c;在节点中通过指针指其前…
阅读更多...
面试官：对于MQ中的消息丢失你是如何理解的？

面试官：对于MQ中的消息丢失你是如何理解的？

相信很多的小伙伴在面试的时候&#xff0c;涉及到MQ的面试题&#xff0c;消息丢失是必问面试题之一。那么对于消息丢失你又是如何理解的呢&#xff1f; 下面我们一起来看一下。 本文以 Kafka 举例说明 一、什么是消息丢失&#xff1f; 消息丢失的定义是&#xff1a;在消息传递…
阅读更多...
最新文章

Copyright @ 2022~2023