Pod 是 Kubernetes 集群中的最小管理单元，其中包含一个或多个应用容器，它们在 Pod 内共享网络配置和存储卷配置。可被看作面向应用的“逻辑主机”，是 Kubernetes 中核心的资源对象。

1. Pod 定义详解

yaml 格式的 Pod 配置文件的标准示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: string
  namespace: strinig
  labels:
  - name: string
  annotations:
  - name: string
spec:
  containers:
  - name: string
    image: string
    imagePullPolicy: [Always | Never | IfNotPresent]
    command: [string]
    args: [string]
    workingDir: string
    volumeMounts:
    - name: string
      mountPath: string
      readOnly: boolean
    ports:
    - name: string
      containerPort: int
      hostPort: int
      protocol: string
    env:
    - name: string
      value: string
    resources:
      limits:
        cpu: string
        memory: string
      requests:
        cpu: string
        memory: string
    livenessProbe:
      exec:
        command: [string]
      httpGet:
        path: string
        port: number
        host: string
        scheme: string
        httpHeaders:
        - name: string
          value: string
      tcpSocket:
        port: number
      initialDelaySeconds: 0
      timeoutSeconds: 0
      periodSeconds: 0
      successThreshold: 0
      failureThreshold: 0
    securityContext:
      privileged: false
  restartPolicy: [Always | Never | OnFailure]
  nodeSelector: object
  imagePullSecrets:
  - name: string
  hostNetwork: false
  volumes:
  - name: string
    emptyDir: {}
    hostPath:
      path: string
    secret:
      secretName: string
      items:
      - key: string
        path: string
    configMap:
      name: string
      items:
      - key: string
        path: string

apiVersion: v1
kind: Pod
metadata:
  name: string
  namespace: strinig
  labels:
  - name: string
  annotations:
  - name: string
spec:
  containers:
  - name: string
    image: string
    imagePullPolicy: [Always | Never | IfNotPresent]
    command: [string]
    args: [string]
    workingDir: string
    volumeMounts:
    - name: string
      mountPath: string
      readOnly: boolean
    ports:
    - name: string
      containerPort: int
      hostPort: int
      protocol: string
    env:
    - name: string
      value: string
    resources:
      limits:
        cpu: string
        memory: string
      requests:
        cpu: string
        memory: string
    livenessProbe:
      exec:
        command: [string]
      httpGet:
        path: string
        port: number
        host: string
        scheme: string
        httpHeaders:
        - name: string
          value: string
      tcpSocket:
        port: number
      initialDelaySeconds: 0
      timeoutSeconds: 0
      periodSeconds: 0
      successThreshold: 0
      failureThreshold: 0
    securityContext:
      privileged: false
  restartPolicy: [Always | Never | OnFailure]
  nodeSelector: object
  imagePullSecrets:
  - name: string
  hostNetwork: false
  volumes:
  - name: string
    emptyDir: {}
    hostPath:
      path: string
    secret:
      secretName: string
      items:
      - key: string
        path: string
    configMap:
      name: string
      items:
      - key: string
        path: string

上述 yaml 文件中各字段的详细说明见下表：

2. Pod 的基本用法

Pod 可以由一个或多个容器组成，在下面的示例中，名为“frontend”的 Pod 只由一个容器组成：

# frontend-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    name: frontend
spec:
  containers:
  - name: frontend
    image: php:8.2-fpm
    ports:
    - containerPort: 80

# frontend-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    name: frontend
spec:
  containers:
  - name: frontend
    image: php:8.2-fpm
    ports:
    - containerPort: 80

另外一种场景是，当 frontend 和 redis 这两个容器应用为紧耦合的关系，并组合为一个整体对外提供服务时，应将这两个容器封装为一个 Pod 。

# frontend-localredis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis-php
  labels:
    name: redis-php
spec:
  containers:
  - name: frontend
    image: php:8.2-fpm
    ports:
    - containerPort: 80
  - name: redis
    image: redis
    ports:
    - containerPort: 6379

# 属于同一个 Pod 的多个容器应用之间在相互访问时仅需通过 localhost 就可以通信

# frontend-localredis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis-php
  labels:
    name: redis-php
spec:
  containers:
  - name: frontend
    image: php:8.2-fpm
    ports:
    - containerPort: 80
  - name: redis
    image: redis
    ports:
    - containerPort: 6379

# 属于同一个 Pod 的多个容器应用之间在相互访问时仅需通过 localhost 就可以通信

创建上述两个 pod：

kubectl apply -f frontend-pod.yaml
kubectl apply -f frontend-localredis-pod.yaml

kubectl apply -f frontend-pod.yaml
kubectl apply -f frontend-localredis-pod.yaml

查看已创建的 pod：

kubectl get pods
kubectl get pods -o wide

# 查看 pod 详细信息
kubectl describe pod redis-php

kubectl get pods
kubectl get pods -o wide

# 查看 pod 详细信息
kubectl describe pod redis-php

删除 pod：

kubectl delete pod <pod_name>

kubectl delete pod <pod_name>

注意：同一个 pod 内的容器可以共享网络与存储资源。

3. Pod 的类型

pod 的类型分为普通 pod 和静态 pod 两大类，其中普通 pod 又分为裸部署 pod 和被控制器管理的 pod。

• 普通 pod：创建 pod 的请求是提交给 Api server 的。
  • 裸部署 pod：资源清单里指定的 kind 就是 Pod ，与任何控制器资源都无关，没有自愈等由控制器实现的相关功能。
  • 被控制器管理的 pod：可通过控制器实现自愈或者自己定制的相关功能。
• 静态 pod：直接通过配置文件或 HTTP 的方式交给 kubelet 创建的 pod ，不通过 API Server 创建。

创建静态 pod 有两种方式：

• 基于本地配置文件
• 基于网络上的配置文件

基于本地配置文件：

需要在 kubelet 的主配置文件中设置 staticPodPath (在比较旧的 Kubernetes 版本中也可以通过命令行参数 -pod-manifest-pth 进行配置，该命令行参数将被逐渐奔用），指定 kubelet 需要监控的配置文件所在的目录，kubelet 会定期扫描该目录，并根据该目录下的 .yaml 或 json 文件创建静态 Pod。（注意：kubelet 在扫描文件时会忽略以“.”开头的隐藏文件。）
kubelet 的默认 staticPodPath 为 /etc/kubernetes/manifests ，如果想修改为其他路径可修改该字段为 staticPodPath: /xxxx。在配置文件中如果该字段不存在，可以手动添加该字段，后重启  kubelet。

基于网络上的配置文件：

基本同上，只需将 staticPodPath 指向一个 URL 路径，例如：staticPodPath: http://example.com/static-pods。

4. Pod 的启动退出流程简述

• 创建pause基础容器，提供共享名称空间。
• 串行初始化容器，初始化容器运行成功后运行业务容器。
• 启动业务容器，启动那一刻会同时运行主容器上定义的 Poststart 钩子事件。
• startupProbe 健康状态监测，判断容器是否启动成功。
• 持续健康检测 livenessProbe、readnessProbe。
• 结束时，在容器结束之前会先执行 Prestop 钩子事件，然后才终止容器。

5. Pod 的生命周期管理

5.1. Pod 运行的各个阶段（Phase）

Pod 在创建之后，首先进入 Pending 阶段；然后等到至少一个容器正常启动就进入 Running 阶段；如果全部容器都运行完成并成功结束，则进人 Succeeded 阶段；如果有部分容器运行失败，则进人 Failed 阶段。在 Pod 生命周期内的各个阶段，Kubernetes 会持续监控其中每个容器的状态，并根据重启策略和健康检查策略进行相应操作。

5.2. Pod 的各种状态（Conditions）

Conditions 是一组更细粒度的状态，描述 Pod 是否满足某些关键条件。每个条件包含：

• type（类型）
• status（True/False/Unknown）
• lastProbeTime（上一次探测 Pod 状态的时间戳）
• lastTransitionTime（Pod 从上一个状态转换到当前状态的时间戳）
• reason（原因）
• message（详细信息）

常见的条件类型：

查看 Pod 状态示例：

kubectl -n kube-flannel get pod kube-flannel-ds-956vj -o yaml

apiVersion: v1
kind: Pod
...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:20:49Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2025-07-14T02:08:31Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:21:02Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:21:02Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2025-07-14T02:07:40Z"
    status: "True"
    type: PodScheduled

kubectl -n kube-flannel get pod kube-flannel-ds-956vj -o yaml

apiVersion: v1
kind: Pod
...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:20:49Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2025-07-14T02:08:31Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:21:02Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2025-08-06T00:21:02Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2025-07-14T02:07:40Z"
    status: "True"
    type: PodScheduled

5.3. 容器的状态（ContainerStatuses）

ContainerStatuses 描述 Pod 中每个容器的详细状态，包括：

• state：容器的当前状态（Waiting、Running 或 Terminated）。
  • Waiting（等待中），容器尚未启动，可能原因：
    • ImagePullBackOff：镜像拉取失败。
    • CrashLoopBackOff：容器崩溃后等待重启。
    • ContainerCreating：容器正在创建（如挂载卷未就绪）。
  • Running（运行中），容器正在运行。
  • Terminated（已终止），表示容器运行结束。
• lastState：容器上一次的状态（用于排查崩溃或重启问题）。
• restartCount：容器重启次数。

可通过 kubectl describe pod <pod_name> 命令查看容器详细信息。

5.4. Events（事件）

Events 记录 Pod 生命周期中的关键事件（如调度失败、镜像拉取错误等），可通过 kubectl describe pod <pod-name> 查看：

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10s   default-scheduler  Successfully assigned default/mypod to node-1
  Normal  Pulling    8s    kubelet            Pulling image "nginx"
  Warning Failed     5s    kubelet            Failed to pull image "nginx:404"

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10s   default-scheduler  Successfully assigned default/mypod to node-1
  Normal  Pulling    8s    kubelet            Pulling image "nginx"
  Warning Failed     5s    kubelet            Failed to pull image "nginx:404"

常见事件：

• Scheduled：Pod 已调度到节点。
• Pulling/Pulled：拉取镜像中/成功。
• Created/Started：容器创建/启动。
• Failed/BackOff：容器启动失败或崩溃。
• Evicted：表示 Pod 被驱逐（Evicted）或驱逐出节点。当 Pod 被驱逐时，它的状态会变为 “Evicted”，这通常发生在节点资源不足或节点发生故障时。
• OOMkilled：在 Kubernetes 中，如果一个容器被 OOM Killer 终止，容器的状态会被标记为 “OOMkilled”。
  • 系统级别的 OOM：系统内存不足，杀进程的范围是系统中所有的进程。
  • k8s 级别的 OOM：针对某个 Pod，该 pod 的容器对内存的使用达到 limits 的限定。

5.5. Pod 的重启策略

Pod 的重启策略应用于 Pod 内所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。Pod 的重启策略包括 Always、OnFailure 和 Never，默认为 Always。

• Always：当容器失效时，由 kubelet 自动重启该容器。
• OnFailure：当容器终止运行且退出码不为0时，由 kubelet 自动重启该容器。
• Never：不论容器处于哪种运行状态，kubelet 都不会重启该容器。

Pod 的重启策略与控制方式息息相关，控制器对 Pod 的重启策略要求如下：

• Deployment、ReplicationController (RC)、DaemonSet 和 StatefulSet：必须被设置为“Always”，需要保证该容器持续运行。
• Job：OnFailure 或 Never，确保容器执行完成后不再重启。
• 静态 pod：不允许设置 estartPolicy，在静态 pod 失效是会由 kubelet 自动重启。

5.6. Pod 终止和垃圾清理

在 Kubernetes 中，Pod 的终止和垃圾清理是一个系统化的过程，涉及优雅终止（Graceful Termination）、资源释放、垃圾回收机制等。

Pod 的终止流程：

• 触发终止
  • 用户删除：通过 kubectl delete pod 或 API 请求删除。
  • 系统驱逐：因资源不足、节点维护等被 kubelet 驱逐。
  • 优先级抢占：高优先级 Pod 抢占低优先级 Pod 的资源。
• 优雅终止（Graceful Termination）
  • API Server 标记 Pod 为“Terminating”。
  • kubelet 探测到 Pod 状态为“Terminating”则向容器发送 SIGTERM 信号。
    • 默认等待时间：30 秒（可通过 spec.terminationGracePeriodSeconds 修改）。
  • 强制终止
    • 如果容器在优雅终止期内未退出，kubelet 发送 SIGKILL 强制终止。
  • 清理容器和网络资源
    • 删除容器运行时（Docker/Containerd）中的容器实例。
    • 释放 Pod 占用的网络接口（如 CNI 插件管理的 IP 地址）。

垃圾回收（Garbage Collection）：

• 垃圾回收类型

• 配置示例

# kubelet 参数（通常在 /var/lib/kubelet/config.yaml 中配置）
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "10%"
imageGCHighThresholdPercent: 85  # 磁盘使用率超过 85% 时触发镜像清理
containerGCHighThreshold: 80     # 保留最多 80 个停止的容器

# kubelet 参数（通常在 /var/lib/kubelet/config.yaml 中配置）
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "10%"
imageGCHighThresholdPercent: 85  # 磁盘使用率超过 85% 时触发镜像清理
containerGCHighThreshold: 80     # 保留最多 80 个停止的容器

6. 容器的探针和健康检查机制

容器探针(Probe)是Kubernetes中用于检测容器健康状况的机制，它通过定期执行诊断来评估容器的运行状态。

6.1. 探针类型

• Liveness Probe (存活探针)
  • 作用：检测容器是否正在运行。
  • 失败后果：kubelet 会杀死容器并根据重启策略决定是否重启。如果未配置该探针，则 kubelet 会认为探针返回的值永远为 Success。
• Readiness Probe (就绪探针)
  • 作用：检测容器服务是否处于 Ready 状态，只有处于 Ready 状态的 Pod 才能接收请求。
  • 失败后果：从 Service 的端点列表中移除该 Pod，停止向其发送流量。就绪探针也是定期触发的，存在于整个 Pod 生命周期。如果未配置该探针，则 kubelet 会认为探针返回的值永远为 Success。
• Startup Probe (启动探针)
  • 作用：检测容器应用是否已启动。
  • 失败后果：在启动探针成功前，其他探针不会执行，如果启动探针检测失败，kubelet 会杀死容器并根据重启策略决定是否重启。如果未配置该探针，则 kubelet 会认为探针返回的值永远为 Success。

6.2. 探针检查方式

上述三种探针都可以配置以下几种检查方式：

• exec：在容器内执行指定命令，返回0表示成功。
• tcpSocket：对指定端口进行 TCP 检查，如果能建立 TCP 连接表示成功。
• httpGet：对指定路径和端口发送HTTP GET请求，状态码2xx或3xx表示成功。

每种探针都可以配置如下字段：

• initialDelaySeconds：容器启动后等待多少秒开始探测，默认值为 0，最小值为 0。
• periodSeconds：执行探测的频率(秒)，默认值为 10，最小值为 1。
• timeoutSeconds：探测超时时间(秒)，当发生超时时则认为探针失败。默认值为 1，最小值为 1。
• successThreshold：探测连续成功多少次才认为成功，默认值为 1，最小值为 1。LivenessProbe 和 StartupProbe 该值必须被设置为 1。
• failureThreshold：探测连续失败多少次才认为失败，默认值为 3，最小值为 1。

配置示例：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: my-app:v1
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 1
      failureThreshold: 3
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      # 在下面的配置中，探测时间间隔 periodSeconds 被设置为 10s，失败次数 failureThreshold 被设置为 30 次，表示允许容器在 300s 内完成启动。这通常用来保护需要启动时间很长的容器。如果容器在 300s 后仍未启动，则探测启动失败，kubelet 会杀掉该容器，并根据重启策略决定是否重启。
      failureThreshold: 30
      periodSeconds: 10

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: my-app:v1
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 1
      failureThreshold: 3
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      # 在下面的配置中，探测时间间隔 periodSeconds 被设置为 10s，失败次数 failureThreshold 被设置为 30 次，表示允许容器在 300s 内完成启动。这通常用来保护需要启动时间很长的容器。如果容器在 300s 后仍未启动，则探测启动失败，kubelet 会杀掉该容器，并根据重启策略决定是否重启。
      failureThreshold: 30
      periodSeconds: 10

7. Pause 容器

Pause容器（Pause Container）是 Kubernetes 集群中一个特殊的辅助容器，主要用于为 Pod 提供共享的基础设施（如网络命名空间）。

核心功能：

• 共享网络命名空间：Pod中的多个容器共享同一个网络栈（相同的IP和端口空间），这是通过Pause容器实现的。Pause容器启动后，会创建网络命名空间，其他容器通过Join方式共享该空间，使它们可以通过localhost直接通信。
• 充当PID 1进程：在Linux中，PID 1进程负责管理孤儿进程并避免僵尸进程。Pause容器作为Pod的“根容器”（PID 1），确保其他容器进程被正确回收。

使用 Pause 容器的优点：

• 解耦Pod生命周期与业务容器：如果业务容器崩溃重启，Pod的网络命名空间不会因此销毁（因为Pause容器仍在运行），确保Pod网络稳定性。
• 简化设计：通过一个轻量级、稳定的中间层管理共享资源，避免每个容器重复实现命名空间逻辑。

结构示例：

一个包含Nginx和Sidecar容器的Pod，实际结构如下：

Pod (IP: 10.1.0.3)
│
├── Pause容器（维护网络命名空间）
├── Nginx容器（共享Pause容器的网络）
└── Sidecar容器（共享Pause容器的网络）

Pod (IP: 10.1.0.3)
│
├── Pause容器（维护网络命名空间）
├── Nginx容器（共享Pause容器的网络）
└── Sidecar容器（共享Pause容器的网络）

Nginx和Sidecar通过localhost直接通信，因为它们在同一个网络命名空间中。

查看 Pause 容器：

• 执行kubectl describe pod <pod-name>时，可以看到 Pause 容器的信息。通过容器运行时管理工具也能查看到它（名称包含pause）。

8. Init 容器

8.1. Init 容器概述

初始化容器（Init Container）是在Pod的主容器启动之前运行的专用容器，用于执行初始化任务。它们与常规容器类似，但具有以下特点：

• 先于应用容器启动：必须成功完成才会启动主容器。
• 顺序执行：按照定义的顺序依次运行，并且只有前一个初始化容器运行成功才会运行行一个初始化容器。
• 一次性：运行完成后即终止，不会持续运行。不支持健康检查机制，应为必须在初始化容器运行成功后才能启动普通容器。

系统会在 Pod 的状态信息的 initContainerStatuses 字段中显示初始化容器的运行状态信息。

8.2. Init 容器使用场景

在很多应用场景中，应用容器在启动之前都可能需要进行一些初始化操作，例如：

• 等待其他关联组件正确运行(例如数据库或某个后台服务)。
• 预先基于环境变量或配置模板生成应用所需的配置文件。
• 从远程数据库中获取本地所需配置，或者将自身注册到某个中央数据库中。
• 下载相关依赖包，或者对系统进行一些预配置操作。
• 以更高的权限调整内核参数。

8.3. Init 容器基本配置示例

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

在初始化容器中也可以设置资源限制、Volume 等等。但对资源限制的设置与应用容器略有不同，如下所述：

• 如果有多个初始化容器定义了资源请求或资源限制，则取最大的值作为所有初如化容器的资源请求值或资源限制值。
• Pod 的有效(effective)资源请求值或资源限制值取以下二者中的较大值：①所有应用容器的资源请求值或资源限制值之和；②初始化容器的有效资源请求值或资源限制值。
• 初始化容器终止后，其请求(request)和限制(limit)的CPU、内存资源会立即释放，只有应用容器的资源需求会被计入Pod的总资源需求。所以调度器在分配节点时，会考虑所有初始化容器和应用容器的资源请求中的最大值（即有效值），但运行后只保留常规容器的资源占用。

8.4. 将初始化容器作为长时间运行的边车容器

9. 钩子函数

9.1. 基本概念

PostStart 和 PreStop 是 Kubernetes 为容器提供的两种生命周期钩子（Lifecycle Hooks），允许在容器生命周期的特定时刻执行自定义操作。

对比概览：

注意：如果一些初始化工作一定要在业务容器运行前运行，那就用 initcontainers 来执行，如果这些初始化工作没有要求必须在业务容器运行前运行，则可以使用 PostStart 来执行。

9.2. PostStart 钩子

配置方式：

# 示例1：Exec方式（执行命令）
lifecycle:
  postStart:
    exec:
      command:
        - "/bin/sh"
        - "-c"
        - "echo 'Container started' > /tmp/start.log"
        
# 示例2：HTTP方式（发送请求）
lifecycle:
  postStart:
    httpGet:
      path: /initialize
      port: 8080
      httpHeaders:
      - name: X-Custom-Header
        value: Initialization

# 示例1：Exec方式（执行命令）
lifecycle:
  postStart:
    exec:
      command:
        - "/bin/sh"
        - "-c"
        - "echo 'Container started' > /tmp/start.log"
        
# 示例2：HTTP方式（发送请求）
lifecycle:
  postStart:
    httpGet:
      path: /initialize
      port: 8080
      httpHeaders:
      - name: X-Custom-Header
        value: Initialization

9.3. PreStop 钩子

配置方式：

# 示例1：Exec方式
lifecycle:
  preStop:
    exec:
      command:
        - "/bin/sh"
        - "-c"
        - "sleep 10 && nginx -s quit"
        
# 示例2：HTTP方式
lifecycle:
  preStop:
    httpGet:
      path: /graceful-shutdown
      port: 8080

# 示例1：Exec方式
lifecycle:
  preStop:
    exec:
      command:
        - "/bin/sh"
        - "-c"
        - "sleep 10 && nginx -s quit"
        
# 示例2：HTTP方式
lifecycle:
  preStop:
    httpGet:
      path: /graceful-shutdown
      port: 8080

注意：当 Pod 开始终止时，Kubernetes 会执行 preStop 钩子。钩子有一个超时时间（默认为 30 秒，可通过 terminationGracePeriodSeconds 调整）。如果钩子在超时时间内没有成功完成，Kubernetes 会终止 Pod，而不再继续等待钩子完成。

9.3. 完整配置示例

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: main-container
    image: nginx:1.19
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Start at $(date)' >> /var/log/lifecycle.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; echo 'Stop at $(date)' >> /var/log/lifecycle.log"]
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: main-container
    image: nginx:1.19
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Start at $(date)' >> /var/log/lifecycle.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; echo 'Stop at $(date)' >> /var/log/lifecycle.log"]
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}

10. 在容器内获取 Pod 信息