kubernetes之Pod详解

2025-8-18

1、Pod结构

image-20250812141431146

每个Pod都可以包含一个或者多个容器，这些容器可以分为两类

  • 用户程序所在容器，数量可多可少
  • Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：

  1. 可以以它为依据，评估整个Pod的健康状态

  2. 可以在根容器上设置ip地址，其他容器以此ip（Pod IP）,以实现Pod内部的网络通信

pod之间的通讯采用虚拟二层网络技术来实现，本文采用的是Calico

2、Pod的配置

下面是Pod的资源清单：

 #查看一级属性
 [root@master ~]# kubectl explain pod
 ​
 #查看二级属性
 [root@master ~]# kubectl explain pod.metadata

在kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分

  • apiVersion <string> 版本，由kubernetes内部定义，版本号必须可以用kubectl api-versions查询到
  • kind <string> 类型，由kubernetes内部定义，版本号必须可以用kubectl api-resources查询到
  • metadata <Object> 元数据，主要是资源标识和说明，常见的有name、namespace、labels等
  • spec <Object> 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
  • status <Object> 状态信息，里面的内容不需要定义，由kubernetes自动生成

在上面的属性中，spec是接下来研究的重点，继续看下它的常见子属性：

  • containers <Object> 容器列表，用于定义容器的详细信息
  • nodeName <String> 根据nodeName的值将pod调度到指定的node节点上
  • nodeSelector <map> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
  • hostNetwork <boolean> 是否使用主机网络模式，默认为false，如果设置为true,表示使用宿主机网络
  • volumes <Object> 存储卷，用于定义Pod上面挂载的存储信息
  • restartPolicy <string> 重启策略，表示Pod在遇到故障的时候的处理策略
 #创建pod-base.yaml文件,内容如下
 ​
 apiVersion: v1           #版本
 kind: Pod               #类型
 metadata:               #元数据
  name: pod-base
  namespace: dev
  labels:
    user: heima
 spec:                   #描述
  containers:           #数组，代表可以有多个容器
  - name: nginx
    image: nginx:1.17.1
  - name: busybox
    image: busybox

 

2.1、镜像拉取

imagePollPolicy,用于设置镜像拉取策略，kubernetes支持配置三种拉取策略：

  • always：总是从远程仓库拉取镜像(一直远程下载)
  • ifNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取(本地有就本地，本地没有就远程)
  • Never: 只使用本地镜像，从不去远程仓库拉取，本地没有就报错(一直使用本地)

默认值说明：

如果镜像tag为具体版本号，默认策略是：ifNotPresent

如果镜像tag为：lastest(最终版本)，默认策略是always

 ......
 ​
 ​
 spec:                   #描述
  containers:           #数组，代表可以有多个容器
  - name: nginx
    image: nginx:1.17.1
    imagePullPolicy: always   #用于设置镜像的拉取策略

 

2.2、启动命令

command参数

用于在pod中的容器初始化完毕之后运行一个命令

 #进入pod中的容器，查看文件内容
 kubectl exec pod名称 -n 命令空间 -it -c 容器名称 /bin/bash 在容器内部执行命令
 ​
 [root@master ~]# kubectl exec nginx-7854ff8877-g8qjh -n test -it /bin/bash
 kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
 root@nginx-7854ff8877-g8qjh:/# ls
 bin boot dev docker-entrypoint.d docker-entrypoint.sh etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

args参数

kubernets中的command、args两项是为了覆盖dockerfile中ENTRYPOINT的功能

image-20250812165449169

 ......
 ​
 ​
 spec:                    
  containers:          
  - name: nginx
    image: nginx:1.17.1
    command             #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args               #容器的启动命令需要的参数列表

 

 

2.3、环境变量

env：环境变量，用于在pod中的容器设置环境变量

不推荐使用

 ......
 ​
 ​
 spec:                    
  containers:          
  - name: nginx
    image: nginx:1.17.1
    env                 #容器环境变量的配置

 

 

2.4、端口设置

 ......
 ​
 ​
 spec:                    
  containers:          
  - name: nginx
    image: nginx:1.17.1
    ports：                 #容器需要暴露的端口号列表

 

 

2.5、资源配额

容器中的程序要运行，肯定要占用一定资源的，比如CPU和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其他容器无法运行。针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制。这种机制主要通过resources选项实现，它有两个子选项：

  • limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启。
  • requ ests：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动

可以通过以上两个选项设置资源的上下限

 ......
 ​
 ​
 spec:                    
  containers:          
  - name: nginx
    image: nginx:1.17.1
    resources:             #资源配额
      limits:             #限制资源(上限)
        CPU: "2"           #CPU限制
        memory: "10Gi"     #内存限制
      limits:             #请求资源(下限)
        CPU: "1"           #CPU限制
        memory: "1Gi"     #内存限制

在这对cpu和memory的单位进行说明：

cpu: core数，可以为整数或小数

memory： 内存大小，可以使用Gi、Mi、G、M等形式

 

 

3、Pod的生命周期

生命周期： 将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程：

pod创建过程

  • 运行初始化容器（init container）过程
  • 运行主容器（main container）过程

容器启动后钩子（post start）、容器终止前钩子（pre stop）

容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

  • pod终止过程

image-20250812205943559

在整个生命周期中，pod会出现的五种状态（相位），分别如下：

  • 挂起(Pending)：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
  • 运行中(running)：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
  • 成功(Succeeded)：pod中的所有容器都已经成功终止并且不会被重启
  • 失败(Failed)：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
  • 未知(Unknown)：apiserver无法正常获取到pod对象的状态信息，通过由网络通信失败所导致

3.1、Pod的创建和终止

pod的创建

1、用户通过kubectl或者其他api客户端提交创建的pod信息给apiServer

2、apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端

3、apiServer开始反映etcd中的pod对象的变化，其他组件使用watch机制来跟踪检查apiServer上的变动

4、apiServer发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer

5、node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer

6、apiServer将接收到的pod状态信息存入etcd中

image-20250812211227199

pod的终止

1、用户向aipServer发送删除pod对象的命令

2、apiServer中的pod对象信息会随着时间的推移而更新，在宽限期内(默认30s)，pod被视为dead

3、将pod标记为terminating状态

4、kubelet在监控到pod对象转换为terminating状态的同时启动pod关闭过程

5、端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除

6、如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行

7、pod对象中的容器进程收到停止信号

8、宽限期结束后，若pod中还存在仍然运行的进程，那么pod对象会收到立即终止的信号。

9、kubelet请求apiService将此pod资源的宽限期设置为0 ，从而完成删除操作，此时pod对于用户已不见

3.2、初始化容器

初始化容器是在pod的主容器启动之前运行的容器，主要是做了一些主容器的前置工作，它具有两大特征：

初始化容器必须运行完成直至结束，若某一初始化容器运行失败，那么kubernetes需要重启它直到成功完成

初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行

初始化容器有很多的应用场景，下面列出的是最常见的几个：

  • 提供主容器镜像中不具备的工具程序或自定义代码
  • 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至依赖的条件得到满足

3.3、容器的探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。

如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题 “实例” 摘除，不承担业务流量，kubernetes提供 两种探针来实现容器探测，分别是：

  • liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是,k8s会重启容器。
  • readliness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量。
 livenessProbe决定是否重启容器，readinessProbe决定是否将请求转发给容器

上面两种探针目前均支持三种探测方式：

  • Exec命令：在容器中执行一次命令，如果命令执行的退出码为0，则认为程序正常
 --
  livenessProbe:
    exec：
      command：
      - cat
      - /tmp/healthy
 --
  • TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
--
livenessProbe:
tcpSocket:
port：8080
--
  •  HTTPGet：调用容器内web应用的URL，如果返回的状态码在200-399之间，则认为程序正常，否则不正常
--
livenessProbe:
httpGet:
path:/ #URI地址
port:80
--

 

 

3.4、重启策略

一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这就是由Pod的重启策略决定的，pod的重启策略有三种，分别如下：

  • Always：容器失效时，自动重启该容器，就也是默认值
  • OnFailure：容器终止运行且退出码不为0时重启
  • Nerver：不论状态为何，都不会重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由Kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

4、Pod调度

kubernetes提供了四大类调度方式：

  • 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算出来
  • 定向调度：NodeName、NodeSelector
  • 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
  • 污点（容忍）调度：Taints、Toleration

4.1、定向调度

定向调度，指的是利用在Pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制性的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

Nodename

NodeName用于强制约束将Pod调度到指定的Nmae的Node节点上。这种方式，其实是直接跳过Scheduler的的调度逻辑，直接写入PodList列表

NodeSelect

NodeSelector用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes的label-selector机制实现的，也就是说，在pod创建之前，schedule使用MatchNodeSelector调度策略进行label分配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

总结：

定向调度为强制调度，无论是否node存在

Nodename为指定Node调度

NodeSelector为指定标签的Node调度

4.2、亲和性调度

由于采用定向调度，遇到不满足条件的node，pod不会被运行，即使在集群中还有可用的Node列表也不行，这就限制了它的使用场景

基于上面问题，kubernetes提供了一种亲和性调度(Affinity)。它在NodeSelector的基础上进行扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活

Affinity主要分为三类：

  • nodeAffinity(node亲和性)：以node为目标，解决pod可以调度到哪些node的问题
  • podAffinity(pod亲和性)：以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题
  • podAntiAffinity(pod反亲和性)：以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题

关于亲和性(反亲和性)使用场景的说明：

亲和性：如果两个应用频繁交互，那么就有必须利用亲和性让两个应用的尽可能的接近，这样可以减少因网络通信而带来的性能损坏

反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性

4.3、污点和容忍

污点（Taints）

前面的调度方式都是站在Pod角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。

Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

污点的格式为：key=values:effcet,key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

  • PreferNoSchedule：Kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
  • NoSchedule：kubernetes将不会把pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
  • NoExecute：Kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离

image-20250816170952752

使用kubectl设置和去除污点的命令如下：

#设置污点
kubectl taint nodes node1 key=value:effect

#去除污点
kubectl taint nodes node1 key:effect-

#去除所有污点
kubectl taint nodes node1 key-

 

测试

 #为node1设置污点PreferNoSchedule
 [root@master ~]# kubectl taint nodes node1 tag=kervin24:PreferNoSchedule
 node/node1 tainted
 ​
 #为node1设置污点(取消PreferNoSchedule,设置NoSchedule)
 [root@master ~]# kubectl taint nodes node1 tag:PreferNoSchedule-
 node/node1 untainted
 [root@master ~]# kubectl taint nodes node1 tag=kervin24:NoSchedule
 node/node1 tainted
 ​
 #查看master上的taint设置,可以看到taints设置为了NoSchedule
 [root@master ~]# kubectl describe nodes master
 Name:               master
 Roles:             control-plane
 Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=master
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/control-plane=
                    node.kubernetes.io/exclude-from-external-load-balancers=
 Annotations:       kubeadm.alpha.kubernetes.io/cri-socket: unix:///var/run/cri-dockerd.sock
                    node.alpha.kubernetes.io/ttl: 0
                    projectcalico.org/IPv4Address: 192.168.80.10/24
                    projectcalico.org/IPv4IPIPTunnelAddr: 10.244.219.64
                    volumes.kubernetes.io/controller-managed-attach-detach: true
 CreationTimestamp: Fri, 08 Aug 2025 16:05:05 +0800
 Taints:             node-role.kubernetes.io/control-plane:NoSchedule
 Unschedulable:     false
 .....
 ......

使用kubeadm搭建的集群，默认就会给master节点添加一下污点标记，所以pod不会调度到master节点上去

 

容忍（Toleration）

上面介绍了污点的作用，我们可以node上添加污点用于拒绝pod调度上来，但是如果就是想要将一个pod调度到一个有污点的node上去，就需要使用容忍

image-20250816181221020

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

创建pod-toleration.yaml

 apiVersion: V1
 Kind: Pod
 metadata:
  name: pod-toleration
  namespace: dev
 spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    tolerations:               #添加容忍
    - key: "tag"               #要容忍的污点的key,空意味着匹配所有的键
      operator: "Equal"       #key-value的运算符，支持Equal和Exists操作符
      value: "heima"           #容忍的污点的value
      effect: "NoExecute"     #添加容忍的规则,这里必须和标记的污点规则相同
      tolerationSeconds       #容忍时间，当effect为NoExecute时生效，表示pod在Node上的停留时间

 

5、Pod控制器介绍

在kubernetes中，按照pod的创建方式可以将其分为两类：

  • 自主式pod：kubernetes直接创建出来的pod，这种pod删除后就没有了，不会重建
  • 控制器创建的pod：通过控制器创建的pod，这种pod删除了之后还会自动重建

什么是pod控制器

Pod控制器就是管理pod的中间层，使用了pod控制器后，我们只需要告诉pod控制器，想要多少个什么样的pod就可以了，它会创建出满足条件的pod并确保每一个pod处于用户期望的状态，如果pod在运行中出现故障，控制器就会基于指定策略重启动或者重创建pod

在kubernetes中，有很多类型的pod控制器，每种都有自己的合适场景，常见的有下面这些：

  • ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
  • ReplicaSet：保证指定数量的pod运行，并支持pod数量变更，镜像版本变更
  • Deployment：通过控制ReplicaSet来控制pod，并支持滚动升级，版本回退
  • Horizontal Pod Autoscaler：可以根据集群负载自动调整Pod的数量，实现削峰填谷
  • DatemonSet：在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务
  • Job：它创建出来的pod只要完成任务就立即退出，用于执行一次性任务
  • Cronjob：它创建的pod会周期性的执行，用于执行周期性任务
  • StatefulSet：管理有状态应用

5.1、Deployment

为了更好的解决服务编排的问题，Kubernetes在V1.2版本开始，引入了Deployment控制器，

值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet管理Pod，所以Deployment比ReplicaSet功能更加强大

image-20250816201600929

Deployment主要功能有下面几个：

  • 支持ReplicaSet的所有功能
  • 支持发布的停止、继续
  • 支持版本的滚动升级和版本回退

5.1.1、查看

 #查看deployment
 [root@master ~]# kubectl get deployment -n test -o wide
 NAME       READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES     SELECTOR
 nginx       1/1     1           1           5d22h   nginx       nginx       app=nginx
 redis       1/1     1           1           5d23h   redis       redis       app=redis
 wordpress   1/1     1           1           4d3h   wordpress   wordpress   app=wordpress
 ​
 #查看rs
 #发现rs的名称只是在原来deployment的名字后面添加了一个10位数的随机串
 [root@master ~]# kubectl get rs -n test -o wide
 NAME                   DESIRED   CURRENT   READY   AGE     CONTAINERS   IMAGES     SELECTOR
 nginx-7854ff8877       1         1         1       5d22h   nginx       nginx       app=nginx,pod-template-hash=7854ff8877
 redis-7c888f4788       1         1         1       5d23h   redis       redis       app=redis,pod-template-hash=7c888f4788
 wordpress-59866668f6   1         1         1       4d3h   wordpress   wordpress   app=wordpress,pod-template-hash=59866668f6
 ​
 #查看pod
 [root@master ~]# kubectl get pods -n test -o wide
 NAME                         READY   STATUS   RESTARTS   AGE   IP               NODE   NOMINATED NODE   READINESS GATES
 nginx-7854ff8877-cvkzx       1/1     Running   0         152m   10.244.166.165   node1   <none>           <none>
 redis-7c888f4788-rp97t       1/1     Running   0         152m   10.244.166.166   node1   <none>           <none>
 wordpress-59866668f6-xnpg6   1/1     Running   0         152m   10.244.166.164   node1   <none>           <none>

 

5.1.2、扩缩容

 #修改nginx的副本，为2
 [root@master ~]# kubectl scale deployment nginx --replicas=2 -n test
 deployment.apps/nginx scaled
 ​
 #发现，nginx新创建一个
 [root@master ~]# kubectl get pod -n test
 NAME                         READY   STATUS   RESTARTS   AGE
 nginx-7854ff8877-cvkzx       1/1     Running   0         3h21m
 nginx-7854ff8877-ftbb8       1/1     Running   0         13s
 redis-7c888f4788-rp97t       1/1     Running   0         3h21m
 wordpress-59866668f6-xnpg6   1/1     Running   0         3h21m
 ​
 #修改yaml文件形式，直接修改replicas的数量
 [root@master ~]# kubectl edit deployment nginx -n test
 ​
 #查看deployment信息
 [root@master ~]# kubectl describe deployment nginx -n test

image-20250816212206608

5.1.3、镜像更新

Deployment支持两种镜像更新的策略：重建更新和滚蛋更新(默认),可以通过strategy选项进行配置

strategy：指定新的pod提供旧的Pod策略，支持两个属性：
type：指定策略类型，支持两种策略
Recreate：在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate:滚蛋更新，就是先杀死一部分，就启动一部分，在更新的过程中，存在两个版本的Pod
RollingUpdateStrategy:maxUnavaible【用来指定在升级过程中不可用Pod的最大数量，默认25%】
maxSurge:【用来指定在升级过程中，可以超过期望的Pod的最大数量，默认25%】

image-20250816214100221

 #修改nginx版本
 [root@master ~]# kubectl set image deployment nginx nginx=nginx:1.16.0 -n test
 deployment.apps/nginx image updated
 ​
 #发现只有一部分nginx在更新【滚动更新--创建一部分，删除一部分】
 [root@master ~]# kubectl get pod -n test
 NAME                         READY   STATUS             RESTARTS   AGE
 nginx-766fdcb9b9-rbpcl       0/1     ContainerCreating   0         17s
 nginx-766fdcb9b9-v9h4j       0/1     ContainerCreating   0         17s
 nginx-766fdcb9b9-vkrmq       0/1     ContainerCreating   0         17s
 nginx-7854ff8877-7zzl7       1/1     Running             0         5m43s
 nginx-7854ff8877-cvkzx       1/1     Running             0         3h49m
 nginx-7854ff8877-kbrss       1/1     Running             0         5m43s
 nginx-7854ff8877-kmn64       1/1     Running             0         5m43s
 redis-7c888f4788-rp97t       1/1     Running             0         3h49m
 wordpress-59866668f6-xnpg6   1/1     Running             0         3h49m
 ​
 [root@master ~]# kubectl get pod -n test
 NAME                         READY   STATUS   RESTARTS   AGE
 nginx-766fdcb9b9-9fvkb       1/1     Running   0         59s
 nginx-766fdcb9b9-cm2zt       1/1     Running   0         63s
 nginx-766fdcb9b9-rbpcl       1/1     Running   0         99s
 nginx-766fdcb9b9-v9h4j       1/1     Running   0         99s
 nginx-766fdcb9b9-vkrmq       1/1     Running   0         99s
 redis-7c888f4788-rp97t       1/1     Running   0         3h50m
 wordpress-59866668f6-xnpg6   1/1     Running   0         3h50m

 

5.1.4、版本回退

deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能。下面具体来看，

kubectl rollout：版本升级相关功能，支持下面的选项：

  • status 显示当前升级状态
  • history 显示升级历史记录
  • pause 暂停版本升级过程
  • resume 继续已经暂停的版本升级过程
  • restart 重启版本升级过程
  • undo 回滚到上一个版本(可以使用--to-revision回滚到指定版本)
 #版本升级
 [root@master ~]# kubectl set image deployment nginx nginx=nginx:1.17.3 -n test
 deployment.apps/nginx image updated
 ​
 #查看版本升级状态
 [root@master ~]# kubectl rollout status deployment nginx -n test
 Waiting for deployment "nginx" rollout to finish: 3 out of 5 new replicas have been updated...
 ​
 #查看升级历史记录，这里五次记录说明有四次升级
 [root@master ~]# kubectl rollout history deployment nginx -n test
 deployment.apps/nginx
 REVISION CHANGE-CAUSE
 1         <none>
 2         <none>
 3         <none>
 4         <none>
 5         <none>
 ​
 #--to-revision=1版本回退到1版本，如果省略这个参数，代表回退到上个版本，即4版本
 [root@master ~]# kubectl rollout undo deployment nginx --to-revision=1 -n test
 deployment.apps/nginx rolled back
 ​
 #再次查看
 [root@master ~]# kubectl rollout history deployment nginx -n test
 deployment.apps/nginx
 REVISION CHANGE-CAUSE
 2         <none>
 3         <none>
 4         <none>
 5         <none>
 6         <none>
 ​
 #已经回退到最早版本
 [root@master ~]# kubectl get deployment   -n test -o wide
 NAME       READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES     SELECTOR
 nginx       5/5     5           5           6d21h   nginx       nginx       app=nginx
 redis       1/1     1           1           6d22h   redis       redis       app=redis
 wordpress   1/1     1           1           5d2h   wordpress   wordpress   app=wordpress

 

5.1.5、金丝雀发布

Deployment支持更新过程中的控制，如“暂停(pause)"或“继续(resume)”更新操作

比如有一批新的Pod资源创建完成之后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。

然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。

确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

5.2、Horizontal Pod Autoscaler（HPA）

kubernetes期望通过监测Pod的使用情况，实现pod数量的自动调整，于是就是产生了HPA这种控制器。

HPA可以获取每个pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现pod的数量的调整，通过追踪分析目标pod的负载变化情况，来确定是否需要针对性地调整目前pod的副本数

image-20250817204606026

5.2.1、安装metrics-server

下载github的yaml有点麻烦，暂略

5.3、DaemonSet（DS）

DaemonSet类型的控制器可以保证集群中的每一台(或指定)节点上都运行一个副本，一般适用于日志收集、节点监控等场景。

也就是说，如果一个pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类pod就适合使用DaemonSet类型的控制器创建

image-20250817222802119

DaemonSet控制器的特点：

  • 每当向集群中添加一个节点时，指定的pod副本也将添加到该节点上
  • 当节点从集群中移除时，pod也就被垃圾回收了

 

5.4、Job

Job,主要用于负责批量处理(一次要处理指定数量的任务)

Job特点如下：

  • 当Job创建的pod执行成功时，Job将记录成功结束的pod数量
  • 当成功结束的pod数量达到指定的数量时，Job将完成执行

image-20250817223554530

 

5.5、CronJob（CJ）

CronJob控制器资源为其管控对象，并借助它管理p od资源对象，Job控制器定义的作业任务在其控制器资源创建之后就会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作用计划的方式控制其运行时间点及重复运行的方式。也就是说CronJob可以在特定的时间点(反复的)去运行Job任务

image-20250818101917962

阅读剩余
版权声明：
作者：做个超努力的小奚&kervin24
个人博客站:http://www.kervin24.top
CSDN博客:https://blog.csdn.net/qq_52914969?type=blog
THE END
dockerkubernetes
kubernetes基础知识
<<上一篇
kubernetes之Service与ingress
下一篇>>
相关推荐
kubernetes之Service与ingress
kubernetes之Pod详解
kubernetes基础知识
Dockerfile脚本
Docker基本管理
Copyright © 2025 运维鹿 CoreNext Powered by WordPress
首页
留言