Pod

Job

Job 概述

Job 用于执行有终止期限的一次性作业式任务，而非一直处于运行状态的服务进程；
Job 成功运行完毕后，Pod 会处于 Completed 状态

Job Explain

apiVersion: batch/v1  # API群组及版本
kind: Job  # 资源类型特有标识
metadata:
  name <string>  # 资源名称，在作用域中要唯一
  namespace <string>  # 名称空间；Job资源隶属名称空间级别
spec:
  selector <object> # 标签选择器，必须匹配template字段中Pod模板中的标签
  template <object>  # Pod模板对象
  completions <integer> # 期望的成功完成的作业次数，成功运行结束的Pod数量
  ttlSecondsAfterFinished  <integer> # 终止状态作业的生存时长，超期将被删除
  parallelism  <integer>  # 作业的最大并行度，默认为1
  backoffLimit <integer>  # 将作业标记为Failed之前的重试次数，默认为6
  activeDeadlineSeconds  <integer> # 作业启动后可处于活动状态的时长

Job Example

范例 - 1

yaml

job-demo.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    spec:
      containers:
      - name: myjob
        image: alpine:3.11
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh", "-c", "sleep 60"]
      restartPolicy: Never
  completions: 2 # 期望成功完成2次作业
  ttlSecondsAfterFinished: 3600
  backoffLimit: 3
  activeDeadlineSeconds: 300

验证

# kubectl apply -f job-demo.yaml 
job.batch/job-demo created


# 第一次作业运行中
# kubectl get job
NAME       COMPLETIONS   DURATION   AGE
job-demo   0/2           55s        55s
# kubectl get pod
NAME             READY   STATUS    RESTARTS   AGE
job-demo-hfqht   1/1     Running   0          10s



# 第一次作业运行完毕，第二次作业运行中
# kubectl get job
NAME       COMPLETIONS   DURATION   AGE
job-demo   1/2           69s        69s
# kubectl get pod
NAME             READY   STATUS      RESTARTS   AGE
job-demo-hfqht   0/1     Completed   0          72s
job-demo-nmcfr   1/1     Running     0          5s


# 两次作业全部运行完毕
# kubectl get job
NAME       COMPLETIONS   DURATION   AGE
job-demo   2/2           2m11s      2m57s
# kubectl get pod
NAME             READY   STATUS      RESTARTS   AGE
job-demo-hfqht   0/1     Completed   0          2m54s
job-demo-nmcfr   0/1     Completed   0          107s



# 删除cronjobs后，其关联的job也会删除
# kubectl delete job job-demo 
job.batch/job-demo "cronjob-demo" deleted
# kubectl get pod
No resources found in default namespace.

范例 - 2

yaml

job-para-demo.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: job-para-demo
spec:
  template:
    spec:
      containers:
      - name: myjob
        image: alpine:3.11
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh", "-c", "sleep 60"]
      restartPolicy: Never
  completions: 12 # 期望成功完成2次作业
  parallelism: 2 # 以两两一组的方式并行运行（12/2=6，大约需要60x6=360+秒完成）
  ttlSecondsAfterFinished: 3600
  backoffLimit: 3
  activeDeadlineSeconds: 1200

Test

# kubectl apply -f job-para-demo.yaml 
job.batch/job-para-demo created


# 并行2
# kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
job-para-demo-7qtd4   1/1     Running   0          7s
job-para-demo-b5v4s   1/1     Running   0          7s


# 期望完成12个，目前完成0个
# kubectl get jobs.batch job-para-demo 
NAME            COMPLETIONS   DURATION   AGE
job-para-demo   0/12          12s        12s



# kubectl describe jobs.batch job-para-demo 
...



# 期望完成12个，目前完成4个
# kubectl get jobs.batch job-para-demo 
NAME            COMPLETIONS   DURATION   AGE
job-para-demo   4/12          2m23s      2m23s


# 完成后pod会处于Completed状态
# kubectl get pod
NAME                  READY   STATUS      RESTARTS   AGE
job-para-demo-7qtd4   0/1     Completed   0          2m16s
job-para-demo-b5v4s   0/1     Completed   0          2m16s
job-para-demo-g8fsv   1/1     Running     0          4s
job-para-demo-msvgf   0/1     Completed   0          68s
job-para-demo-tjvnt   1/1     Running     0          3s
job-para-demo-vtjhq   0/1     Completed   0          67s


# 完成后的Completed状态会保留
# kubectl get pod
NAME                  READY   STATUS      RESTARTS   AGE
job-para-demo-7qtd4   0/1     Completed   0          20m
job-para-demo-b5v4s   0/1     Completed   0          20m
job-para-demo-g8fsv   0/1     Completed   0          18m
job-para-demo-klqkw   0/1     Completed   0          15m
job-para-demo-msvgf   0/1     Completed   0          19m
job-para-demo-p5grs   0/1     Completed   0          16m
job-para-demo-qvtr9   0/1     Completed   0          15m
job-para-demo-szg9c   0/1     Completed   0          17m
job-para-demo-tjvnt   0/1     Completed   0          18m
job-para-demo-vtjhq   0/1     Completed   0          19m
job-para-demo-vvntz   0/1     Completed   0          16m
job-para-demo-vxdwt   0/1     Completed   0          17m

Pod

Pod.spec

hostNetwork

使 Pod 共享宿主机的网络名称空间。
谨慎使用！因为此选项危险性很高，因此要在多租户环境中限制普通用户定义此功能
pod.spec.hostNetwork

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  hostNetwork: true # boolean 布尔值，true或false，默认false
  containers:
  - name: myapp
    image: ikubernetes/demoapp:v1.0 
    imagePullPolicy: IfNotPresent

范例-1

yaml

# vim myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  hostNetwork: true # 共享宿主机的网络名称空间
  containers:
  - name: myapp
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    env:
      - name: PORT
        value: "8080"

验证

# kubectl apply -f myapp.yaml 
pod/myapp created

# kubectl describe pod myapp 
Name:         myapp
Namespace:    default
Priority:     0
Node:         k8s-node-2/10.0.0.102
...
Containers:
  myapp:
    Container ID:   docker://40505748fd9540ad06c5d1b1e77a096e54c6421f7067f2f490ab6a1f9779786a
    Image:          ikubernetes/demoapp:v1.0
    Image ID:       docker-pullable://ikubernetes/demoapp@sha256:6698b205eb18fb0171398927f3a35fe27676c6bf5757ef57a35a4b055badf2c3
    Port:           <none>
    Host Port:      <none>
    State:          Running
...




# 共享宿主机的网络了，因此可以从宿主机的8080端口直接进行访问。
# kubectl exec myapp -- ss -ntl
State   Recv-Q   Send-Q     Local Address:Port      Peer Address:Port  Process  
LISTEN  0        128              0.0.0.0:8080            0.0.0.0:*              
LISTEN  0        4096       127.0.0.53%lo:53             0.0.0.0:*              
LISTEN  0        128              0.0.0.0:22             0.0.0.0:*              
...

# kubectl exec myapp -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:0d:63:cd brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.101/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe0d:63cd/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
...

hostPID

使 Pod 共享宿主机的PID名称空间。
谨慎使用！
pod.spec.hostPID

restartPolicy

定义 pod 的重启策略，可以是 Always、OnFailure、Never，默认为 Always

Pod 安全相关配置

securityContext

securityContext 是 Kubernetes 中定义 Pod 或 Container 权限和访问控制设置的核心字段。它决定了容器内的进程以什么用户身份运行、拥有哪些 Linux Capabilities（能力）、文件系统权限如何分配等。

Pod 级别 (全局基准，对所有容器生效):

设置在 spec.securityContext。
这些设置会应用到 Pod 内的所有容器（包括 Init Containers 和 Sidecars）。
特有字段: 只有 Pod 级别可以配置挂载卷的权限（如 fsGroup）和 sysctls。

容器级别 (特定覆盖，仅对特定容器生效):

设置在 spec.containers[].securityContext。
优先级更高: 如果同一个字段（如 runAsUser）在 Pod 和容器级别都设置了，容器级别的设置会覆盖 Pod 级别的设置。
特有字段: 只有容器级别可以配置 Capabilities（能力）和特权模式（Privileged）。

Pod 级别的 SecurityContext

Pod 级别的设置主要关注所有容器共享的属性以及存储卷的访问控制。下面是一些常用的字段：

fsGroup (FileSystem Group):

作用: Kubernetes 会自动将挂载的 Volume 中所有文件的所属组（Group ID）更改为这个 ID，并确保容器进程（如果属于该组）有读写权限。
场景: 多个容器共享一个存储卷时，确保它们都能读写文件。

runAsUser / runAsGroup:

作用: 指定 Pod 内所有容器进程运行的 UID 和 GID。
注意: 如果容器级别也定义了，则以此处为准。

runAsNonRoot:

Pod 自动扩缩容

Pod 扩容/缩容相关方法

HPA & VPA

自动扩容/缩容

Horizontal Pod Autoscaler（HPA）
Vertical Pod Autoscaler（VPA）

手动扩容/缩容

通过修改 yaml 文件中的 replicas 数量
在 dashboard 中更改 deployment 的 pod 值
通过 kubectl scale 命令
通过 kubectl edit 命令

PS

自动扩容可以根据 Pod 的负载(如CPU负载、内存使用率等) 来进行动态扩容和缩容
手动扩容虽然需手动执行，但也可以通过 kubectl scale 等命令写入计划任务中在业务高峰期/低谷期来进行动态扩容和缩容

测试使用的 yaml 文件

# cat nginx.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-deployment-label
  namespace: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment-label
  template:
    metadata:
      labels:
        app: nginx-deployment-label
    spec:
      restartPolicy: Always
      containers:
      - name: nginx-container
        image: nginx
        imagePullPolicy: Always
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        resources:
          requests:   
            cpu: 20m
            memory: 32Mi   
          limits:   
            cpu: 20m  
            memory: 64Mi

---

kind: Service
apiVersion: v1
metadata:
  labels:
    app: nginx-service
  name: nginx-service
  namespace: nginx
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 30003
  selector:
    app: nginx-deployment-label

Metrics-Server

https://github.com/kubernetes-sigs/metrics-server

PodDisruptionBudget

PodDisruptionBudget（Pod 稳定性预算）是 Kubernetes 中用来确保在进行节点维护或缩减时，Pod 的最小可用性的策略对象。它能够限制在一段时间内可中断的 Pod 的数量，以确保业务的稳定性。

主要组成部分：

minAvailable 和 maxUnavailable：
- minAvailable：指定了要保持可用的最小 Pod 数量。
- maxUnavailable：指定了允许不可用的最大 Pod 数量。
选择器（Selector）：
- PodDisruptionBudget 使用标签选择器来标识受影响的 Pod。

作用：

节点维护和缩减： 当节点需要维护、升级或者缩减时，PodDisruptionBudget 允许在这些过程中限制可以同时中断的 Pod 数量，以确保系统的稳定性和可用性。
可用性保证： 它允许你定义在任何时候所需的最小可用 Pod 数量，这样可以防止过多的 Pod 同时中断，从而保障服务的可用性。

使用场景：

无宕机服务更新： 在进行服务更新或者迁移时，可以使用 PodDisruptionBudget 来确保在更新的过程中，系统依然能够保持一定的可用性。
稳健性测试： 在进行系统测试或模拟故障的情况下，可以通过限制 PodDisruptionBudget 中允许的不可用 Pod 数量来测试系统对故障的响应能力。

PodDisruptionBudget 是确保系统稳定性的一个重要工具，它提供了对可中断 Pod 数量的控制和管理，以确保在维护和更新过程中保持服务的稳定性和可用性。

以下是一个 PodDisruptionBudget 的配置示例：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: example-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: example-app

这个示例创建了一个名为 example-pdb 的 PodDisruptionBudget。它的配置包括：

StatefulSet

StatefulSet 概述

StatefulSet 有状态集合，简称 sts，更适合运行有状态服务 Stateful service
StatefulSet 属于通用的有状态应用控制器
StatefulSet 强依赖于 Headless Service；即创建 StatefulSet 前需先创建无头服务
- 因为无头服务可以给每个 pod 定义一个唯一的 service 域名标识，pod间使用这个域名进行反向解析得到目标pod的IP，进而实现 pod 与 pod 间直接通信，而不再经由service调度
如果 StatefulSet 需要持久化存储，那么每个实例都需要有自己独立的持久化存储，并且只能是PVC格式
StatefulSet 的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

有状态服务

多个实例彼此间不可以互相取代则为有状态服务
有状态服务可以说是需要数据存储功能的服务、或者指多线程类型的服务，队列等。
状态的服务中的每个pod都有特定的名称和网络标识，比如pod名是由statefulSet名+有序的数字组成（0、1、2..）
- statefulset_name-mysql-0、statefulset_name-mysql-1、statefulset_name-mysql-2

常见的有状态服务：

MySQL、MongoDB、zookeeper、kafka 等…

StatefulSet 部署应用

顺序部署，假设三个副本，则 app-0 –> app-1 –> app-2

其他说明：

有的应用须严格按照先后顺序部署；例如：MySQL 集群，只能先部署主节点，再部署从节点，顺序不能颠倒。
有的应用部署时无需考虑部署的先后顺序；例如：zookeeper，因其内部自有leader选举协议，因此哪个节点先后启动都一样

StatefulSet 扩容应用

顺序扩容，例如：目前版本 app-0、app-1、app-2，再扩容两个应用则 app-3 –> app-4

StatefulSet 缩容应用

逆序缩容，例如：目前版本 app-0、app-1、app-2，缩容顺序为先删除app-2，再删除app-1

Pod 常见问题与解决方案

Pod 一直处于 Terminating 状态无法删除

Pod 卡在 Terminating 状态通常是因为某些资源（如存储卷 PVC）未能正确释放，或者节点通信出现了问题。

你可以尝试以下两种方法来解决这个问题。请按顺序操作：

方法一：强制删除 (最推荐)

这是最常用的方法，通过设置宽限期为 0 来强制立即删除 Pod。

请在终端执行以下命令：

kubectl delete pod alertmanager-0 -n monitoring --grace-period=0 --force

--grace-period=0：表示不等待容器优雅退出，立即终止。
--force：强制执行删除操作。

方法二：移除 Finalizers (如果方法一无效)

如果强制删除后 Pod 依然存在（通常是因为 Kubernetes 在等待某些清理工作完成，即 “Finalizers”），你可以手动修改 Pod 的元数据，移除这些阻塞项。

请执行以下命令：

kubectl patch pod alertmanager-0 -n monitoring -p '{"metadata":{"finalizers":null}}'

这会直接告诉 Kubernetes API Server 忽略剩余的清理步骤，直接移除该对象。

💡 为什么会这样？

alertmanager-0 通常是 StatefulSet 的一部分，它可能挂载了持久化存储（PVC）。

常见原因： 所在的节点 (k8s-worker-3) 可能出现了网络问题，或者存储系统未能成功卸载（Unmount）卷，导致 Kubelet 无法完成清理。
建议： 如果这种情况频繁发生，建议检查 k8s-worker-3 的节点状态 (kubectl get node) 以及存储插件的日志。

Pod 调度

Pod 调度策略

节点选择器

nodeSelector 是节点亲和性的一种简单形式，它要求 Pod 必须运行在带有特定标签的节点上。

操作与 YAML 配置示例：

第一步：给节点添加标签

# 语法：kubectl label nodes <节点名称> <键>=<值> <键>=<值> ...
kubectl label nodes worker-node-01 disktype=ssd env=prod

# 如果这个节点之前已经有了 disktype=hdd 的标签，想把它覆盖成 ssd，直接运行上面的命令会报错。需要加上 --overwrite 参数来强制覆盖：
kubectl label nodes worker-node-01 disktype=ssd --overwrite

# 查看节点的标签
kubectl get nodes --show-labels # 查看所有节点的所有标签 (信息较多)
kubectl get nodes -l disktype=ssd # 查看所有打上 disktype=ssd 标签的节点
kubectl get nodes -l "disktype=ssd,env=prod" # 查看所有打上 disktype=ssd 且 env=prod 标签的节点

# 删除节点的标签，在标签的 Key 后面加一个减号 -，就代表删除这个标签。
kubectl label nodes worker-node-01 env- # 删除 env 标签

第二步：创建 Pod 并指定 nodeSelector

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
  # nodeSelector
  nodeSelector:
    disktype: ssd
    env: prod

这个 Pod 会被调度到所有打上 disktype=ssd 且 env=prod 标签的节点上。

Pod 控制器

xxx

此处列出各种控制器中，Pod字段的定义位置。

=====================================================

CronJob 概述

CronJob 主要用于执行有终止期限的周期性作业式任务；
CronJob 与 Job 的关系类似于 Deployment 与 ReplicaSet 的关系，即 CronJob 调用 Job 来执行周期性任务

CronJob Explain

apiVersion: batch/v1  # API群组及版本
kind: CronJob  # 资源类型特有标识
metadata:
  name <string>  # 资源名称，在作用域中要唯一
  namespace <string>  # 名称空间；CronJob资源隶属名称空间级别
spec:
  jobTemplate  <Object>  # job作业模板，必选字段
    metadata <object>  # 模板元数据
    spec <object>  # 作业的期望状态
  schedule <string>  # 调度时间设定，必选字段
  concurrencyPolicy  <string> # 并发策略，可用值有Allow、Forbid和Replace
  failedJobsHistoryLimit <integer> # 失败作业的历史记录数，默认为1
  successfulJobsHistoryLimit  <integer> # 成功作业的历史记录数，默认为3
  startingDeadlineSeconds  <integer> # 因错过时间点而未执行的作业的可超期时长
  suspend  <boolean> # 是否挂起后续的作业，不影响当前作业，默认为false

CronJob Example

范例 - 1

yaml

cronjob-demo.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob-demo
  namespace: default
spec:
  schedule: "*/1 * * * *" # 每两分钟执行一次
  jobTemplate: # job的定义
    metadata: # job的模板
      labels:
        controller: cronjob-demo
    spec: # job的具体定义
      parallelism: 1
      completions: 1
      ttlSecondsAfterFinished: 600
      backoffLimit: 3
      activeDeadlineSeconds: 60
      template:
        spec:
          containers:
          - name: myjob
            image: alpine
            command:
            - /bin/sh
            - -c
            - date; echo Hello from CronJob, sleep a while...; sleep 60
          restartPolicy: OnFailure
  startingDeadlineSeconds: 300

验证

# kubectl apply -f cronjob-demo.yaml
cronjob.batch/cronjob-demo created


# 未达到定义的时间点，因此不会创建job
# kubectl get cronjob
NAME           SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob-demo   */1 * * * *   False     0        <none>          12s
# kubectl get job
No resources found in default namespace.
# kubectl get pod
No resources found in default namespace.


# 到定义的时间点，开始执行job
# kubectl get cronjob
NAME           SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob-demo   */1 * * * *   False     1        2s              47s
# kubectl get job
NAME                    COMPLETIONS   DURATION   AGE
cronjob-demo-27876414   0/1           4s         4s
# kubectl get pod
NAME                          READY   STATUS    RESTARTS   AGE
cronjob-demo-27876414-5hlmm   1/1     Running   0          14s


# job执行完毕
# kubectl get pod
NAME                          READY   STATUS              RESTARTS   AGE
cronjob-demo-27876416-bwnpx   0/1     Terminating         0          67s
cronjob-demo-27876417-n7c5x   0/1     ContainerCreating   0          7s


# 每间隔1分钟执行一次
# kubectl get job
NAME                    COMPLETIONS   DURATION   AGE
cronjob-demo-27876416   0/1           105s       105s
cronjob-demo-27876417   0/1           45s        45s
# kubectl get job
NAME                    COMPLETIONS   DURATION   AGE
cronjob-demo-27876417   0/1           82s        82s
cronjob-demo-27876418   0/1           22s        22s
# kubectl get job
NAME                    COMPLETIONS   DURATION   AGE
cronjob-demo-27876418   0/1           76s        76s
cronjob-demo-27876419   0/1           16s        16s


# 删除cronjobs后，其关联的job也会删除
# kubectl delete cronjobs.batch cronjob-demo 
cronjob.batch "cronjob-demo" deleted
# kubectl get job
No resources found in default namespace.
# kubectl get pod
No resources found in default namespace.

=====================================================

DaemonSet 概述

DaemonSet 守护进程集，简称ds

Pod 容器相关配置

最小的 Pod 配置文件

min-pod.yaml

apiVersion: v1           # 核心 API 组的版本。
kind: Pod                # 告诉 K8s 这是一个 Pod，而不是 Deployment 或 Service。
metadata:
  name: min-nginx        # Pod 的名字（在同一个 Namespace 下，这个名字必须唯一）。
spec:
  containers:            # 这是一个列表（注意前面的短横线 -），意味着一个 Pod 里可以跑多个容器。
  - name: nginx-c        # 容器的名字
    image: nginx:alpine  # 使用的镜像，如果不写版本号，默认会去拉取 latest，在生产环境中强烈不建议这样做。

其实也可以通过这个命令生成：kubectl run my-pod --image=nginx:alpine --dry-run=client -o yaml > min-nginx.yaml

Pod 中运行多个容器（Sidecar 模式）

在一个 Pod 中运行多个容器（Sidecar 模式）是 K8s 的核心特性之一。这种模式下，所有容器共享同一个网络命名空间（IP 和端口）以及存储卷。

Pod

Job

Job 概述

Job Explain

Job Example

范例 - 1

yaml

验证

范例 - 2

yaml

Test

Pod

Pod.spec

hostNetwork

范例-1

yaml

验证

hostPID

restartPolicy

Pod 安全相关配置

securityContext

Pod 级别的 SecurityContext

Pod 自动扩缩容

Pod 扩容/缩容相关方法

自动 扩容/缩容

手动 扩容/缩容

PS

测试使用的 yaml 文件

Metrics-Server

PodDisruptionBudget

主要组成部分：

作用：

使用场景：

StatefulSet

StatefulSet 概述

有状态服务

常见的有状态服务：

StatefulSet 部署应用

StatefulSet 扩容应用

StatefulSet 缩容应用

Pod 常见问题与解决方案

Pod 一直处于 Terminating 状态无法删除

方法一：强制删除 (最推荐)

方法二：移除 Finalizers (如果方法一无效)

💡 为什么会这样？

Pod 调度

Pod 调度策略

节点选择器

Pod 控制器

xxx

=====================================================

CronJob 概述

CronJob Explain

CronJob Example

范例 - 1

yaml

验证

=====================================================

DaemonSet 概述

Pod 容器相关配置

最小的 Pod 配置文件

Pod 中运行多个容器（Sidecar 模式）

自动扩容/缩容

手动扩容/缩容