1.什么是生命周期

对于K8s来说，生命周期是一个 Pod 从被创建 (Pending) 到运行 (Running) 再到被删除的整个过程。

2.Pod的生命周期有哪些阶段？每个阶段代表什么

Pod生命周期分为以下几个阶段：

1. Pending（等待中）：Pod被创建但还未被调度到节点上运行。在这个阶段，Pod可能还在下载容器镜像，或者等待其他资源的创建。
2. Running（运行中）：Pod已被调度并在节点上运行。在这个阶段，Pod中的容器正在执行，可能有一些初始化活动，例如启动应用程序或处理请求。
3. Succeeded（成功）：Pod中的所有容器已成功地完成了它们的任务并退出。例如，一个批处理任务完成后可以进入这个状态。
4. Failed（失败）：Pod中的容器出现错误或者非正常情况退出。例如，容器内部发生错误或者某些依赖资源无法访问。
5. Unknown（未知）：Pod的状态无法确定。可能是因为无法与Pod所在的节点通信。

3.容器中postStart 和 preStop 有什么作用？如何配置

容器生命周期钩子（Container Lifecycle Hooks）监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数。而 PostStart 和 PreStop 是两个钩子函数。

postStart：该钩子在容器被创建后立刻触发，通知容器它已经被创建。

preStop ：在容器被终止之前执行。当 Kubernetes 决定要删除一个 Pod 时（例如，部署更新、节点排空、缩容等），会先执行这个钩子。

配置

Pod 定义的 spec.containers 部分，为每个容器添加 lifecycle 字段来配置钩子。每个钩子都可以通过两种方式来定义其行为：

• exec: 在容器内执行一个命令。
• httpGet: 向容器内的某个端点发送一个 HTTP GET 请求。

exec模式

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo-exec
spec:
  containers:
  - name: nginx
    image: nginx
    lifecycle:
      postStart:
        exec:
          # 容器启动后，创建一个表示“已启动”的文件
          command: ["/bin/sh", "-c", "echo 'Nginx started!' > /usr/share/nginx/html/status.html"]
      preStop:
        exec:
          # 容器停止前，执行 Nginx 的优雅关闭命令
          # 这会让 Nginx 完成现有请求再退出
          command: ["nginx", "-s", "quit"]
 

如果命令退出时返回码为0，判定为执行成功。

httpGet模式

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo-http
spec:
  containers:
  - name: my-app
    image: my-custom-app-image
    ports:
    - containerPort: 8080
    lifecycle:
      postStart:
        httpGet:
          # 假设应用启动后，需要调用 /warm-up 来加载缓存
          path: /warm-up
          port: 8080
          scheme: HTTP
      preStop:
        httpGet:
          # 假设调用 /shutdown 会让应用开始优雅关闭流程
          path: /shutdown
          port: 8080
          scheme: HTTP

对容器中的指定端点执行HTTP GET请求，如果响应的状态码大于等于200且小于400，判定为执行成功。

4.如何配置容器启动执行某个命令

command

command 字段用于定义容器启动时要执行的命令，并覆盖镜像中默认的启动命令。

vim pod-example1.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: pod-example1
  name: pod-example1
spec:
  containers:
  - image: centos:7
    name: test
    command: ["echo", "Hello, World!"]

一次性容器，执行完command里面的“hello ， World！”后会退出

args

args 字段用于指定容器启动时的命令参数

vim pod-example2.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: pod-example2
  name: pod-example2
spec:
  containers:
  - image: centos:7
    name: test
    command: ["echo"]
    args: ["Hello", "World!"]

5.什么是生命周期钩子（Lifecycle Hook）？适合在哪些场景使用

容器生命周期钩子（Container Lifecycle Hooks）监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数。

Hook 类型

应用场景

postStart

- 通知注册中心上线 - 初始化缓存 - 自定义日志记录

preStop

- 通知下游服务断开连接 - 等待请求处理完毕 - 注销注册中心

6.什么是Job？什么场景下使用

Job负责在Kubernetes集群中运行独立的任务，并确保任务成功完成。与其他控制器（如ReplicaSet和Deployment）不同，Job关注的是执行一次性任务而不是保持指定数量的实例运行。

Job 非常适合那些一次性、有始有终的任务。只要你的需求不是“持续运行”，而是“做完某件事就结束”，那么 就可以使用Job

1. 数据处理和批处理任务

需要定期或不定期地处理一批数据。比如，从数据库中导出数据，进行转换，然后加载到另一个系统（ETL 流程）；或者对上传的视频进行转码；或者生成一份复杂的月度财务报告。

2. 数据库迁移

发布一个新版本的应用时，通常需要先更新数据库的表结构（Schema）。这个更新操作只需要在新版本上线前执行一次。

3. 备份和恢复

需要对数据库或持久化存储进行一次性的手动备份，或者从一个备份文件中恢复数据。

4. 测试

在 CI/CD 流程中，你需要为新构建的应用镜像运行一套完整的集成测试或端到端测试。

7.什么是CronJob？如何定义时间表达式

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

CronJob 的时间表达式遵循标准的 Cron 格式。这是一个由 5 个字段组成的字符串，中间用空格分隔，每个字段代表一个时间单位。

格式: 分 时 日 月 周

┌───────────── 分钟 (0 - 59)
│ ┌───────────── 小时 (0 - 23)
│ │ ┌───────────── 日 (1 - 31)
│ │ │ ┌───────────── 月 (1 - 12)
│ │ │ │ ┌───────────── 周 (0 - 6) (0和7都代表周日, 也可以用Sun,Mon,Tue...)
│ │ │ │ │
│ │ │ │ │
* * * * *

常见时间表达式示例

• 每天凌晨 2:30 执行:
• 30 2 * * *
• 每隔 5 分钟执行一次:
• */5 * * * *
• 每个工作日（周一到周五）的下午 5 点执行:
• 0 17 * * 1-5
• 每月 1 号的午夜零点执行:
• 0 0 1 * *
• 每个周六和周日的上午 10 点执行:
• 0 10 * * 6,7
• 8.如何限制Job/CronJob的重试次数和并发执行策略spec.backoffLimit这个字段定义了一个 Job 在被标记为 Failed 状态之前，可以容忍的失败 Pod 的最大数量。apiVersion: batch/v1 kind: Job metadata: name: falling-job-example spec: # 设置重试上限 backoffLimit: 4 template: spec: containers: - name: worker image: busybox # 模拟一个会失败的命令 command: ["/bin/sh", "-c", "echo 'Attempting task...'; exit 1"] # Job 的 Pod 重启策略必须是 OnFailure 或 Never restartPolicy: OnFailure并发控制分为两种情况：单个 Job 内部的并行度和 CronJob 任务之间的并发策略。spec.parallelism 单个 Job 的并行度 (parallelism).这个字段定义了在任何时刻，最多可以有多少个 Pod 同时运行。通常与 spec.completions 配合使用：Job 需要的总成功 Pod 数量。apiVersion: batch/v1 kind: Job metadata: name: parallel-job-example spec: # 总共需要 10 个 pod 成功完成 completions: 10 # 最多同时运行 2 个 Pod parallelism: 2 template: spec: containers: - name: worker image: busybox command: ["/bin/sh", "-c", "echo 'Processing item...'; sleep 5; echo 'Done.'"] restartPolicy: OnFailurespec.concurrencyPolicy对于 CronJob，可能会出现一种情况：上一个定时任务（Job）还没执行完，下一个定时任务的时间点又到了。concurrencyPolicy 就是用来定义此时应该如何处理的策略。策略值含义适用场景Allow (默认)允许允许并发运行多个 Job。即使上一个没跑完，新的时间点到了也会创建新的 Job。适合那些互相独立、执行时间短的任务。Forbid禁止禁止并发。如果上一个 Job 还在运行，那么新的 Job 不会被创建，这次调度将被跳过。适合那些执行时间长、且不希望有多个实例同时运行的任务（如数据库全量备份）。Replace替换替换旧的。如果上一个 Job 还在运行，新的时间点到了，CronJob 会先删除正在运行的旧 Job，然后再创建新的 Job。适合那些你只关心最新一次任务执行的场景。策略值含义适用场景Allow (默认)允许允许并发运行多个 Job。即使上一个没跑完，新的时间点到了也会创建新的 Job。适合那些互相独立、执行时间短的任务。Forbid禁止禁止并发。如果上一个 Job 还在运行，那么新的 Job 不会被创建，这次调度将被跳过。适合那些执行时间长、且不希望有多个实例同时运行的任务（如数据库全量备份）。Replace替换替换旧的。如果上一个 Job 还在运行，新的时间点到了，CronJob 会先删除正在运行的旧 Job，然后再创建新的 Job。适合那些你只关心最新一次任务执行的场景。apiVersion: batch/v1 kind: CronJob metadata: name: backup-cronjob spec: schedule: "*/1 * * * *" # 每分钟触发一次 # 关键配置：设置并发策略为“禁止” concurrencyPolicy: Forbid jobTemplate: spec: template: spec: containers: - name: backup-worker image: busybox # 模拟一个需要 90 秒才能完成的任务 command: ["/bin/sh", "-c", "echo 'Starting backup...'; sleep 90; echo 'Backup complete.'"] restartPolicy: OnFailure9.编写一个Job完成一次性任务（例如打印hello、备份文件等）# cat hello-world-job.yaml apiVersion: batch/v1 kind: Job metadata: name: hello-world-job spec: template: spec: containers: - name: hello-container image: busybox:1.28 command: ["/bin/sh", "-c", "echo 'Hello World!'; echo 'Task complate.'"] # 重启策略 # OnFailure: 只有当容器原因错误退出时， Job才会创建新 Pod 来重试 # Never: 无论成功或失败，都不创建新 Pod restartPolicy: OnFailure # 重试限制 backoffLimit: 3查看 Job 状态:kubectl get job hello-world-job你会看到类似输出，COMPLETIONS 显示 1/1，表示任务已成功完成。NAME STATUS COMPLETIONS DURATION AGE hello-world-job Complete 1/1 29s 59s查看 Pod: Job 会创建一个 Pod 来执行任务。这个 Pod 在任务完成后会处于 Completed 状态。kubectl get pods --selector=job-name=hello-world-job NAME READY STATUS RESTARTS AGE hello-world-job-22jj2 0/1 Completed 0 116s查看任务输出 (日志):# kubectl logs -l job-name=hello-world-job Hello World! Task complate.10.编写一个CronJob，每分钟执行一次，并输出时间apiVersion: batch/v1 kind: CronJob metadata: name: time-job-cronjob spec: # 时间表 schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: time-log-container image: busybox:1.28 args: - /bin/sh - -c - date; echo "Cronjob executed at this time." restartPolicy: OnFailure # 历史记录限制 successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 1查看 CronJob 状态:NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE time-job-cronjob */1 * * * * False 0 53s 4m32s等待并观察 Job 的创建:等一分钟左右，CronJob 就会自动创建一个 Job。kubectl get jobs --watch NAME STATUS COMPLETIONS DURATION AGE time-job-cronjob-29202447 Complete 1/1 5s 24s time-job-cronjob-29202448 Running 0/1 0s time-job-cronjob-29202448 Running 0/1 0s 0s time-job-cronjob-29202448 Running 0/1 4s 4s time-job-cronjob-29202448 Complete 1/1 4s 4s查看任务输出 (日志):你可以查看任何一个由 CronJob 创建的 Pod 的日志。最简单的方法是找到最新的那个 Pod。# 1. 找到最新的 Pod LATEST_POD=$(kubectl get pods --selector=job-name --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1:].metadata.name}') # 2. 查看该 Pod 的日志 kubectl logs $LATEST_POD每次更新Pod，时间都会刷新Thu Jul 10 11:32:01 UTC 2025 Cronjob executed at this time.11.如何查看Job的运行状态、日志(前面的题有说)查看 Job 状态:kubectl get job hello-world-job你会看到类似输出，COMPLETIONS 显示 1/1，表示任务已成功完成。NAME STATUS COMPLETIONS DURATION AGE hello-world-job Complete 1/1 29s 59s查看 Pod: Job 会创建一个 Pod 来执行任务。这个 Pod 在任务完成后会处于 Completed 状态。kubectl get pods --selector=job-name=hello-world-job NAME READY STATUS RESTARTS AGE hello-world-job-22jj2 0/1 Completed 0 116s查看任务输出 (日志):# kubectl logs -l job-name=hello-world-job Hello World! Task complate.12.如果Job失败，默认行为是怎样的如果pod 里面执行的是 非 0的退出码，job就会失败设置一个非0退出码的jobapiVersion: batch/v1 kind: Job metadata: name: perpetually-failing-job spec: # 我们没有设置 backoffLimit，所以它会使用默认值 6 # backoffLimit: 6 (default) template: spec: containers: - name: failing-worker image: busybox # 这个命令会立即失败 command: ["/bin/sh", "-c", "echo 'Task is about to fail...'; exit 1"] restartPolicy: OnFailurekubectl get pods --watch NAME READY STATUS RESTARTS AGE perpetually-failing-job-2xwq4 0/1 CrashLoopBackOff 2 (25s ago) 99s perpetually-failing-job-2xwq4 0/1 Error 3 (27s ago) 101s perpetually-failing-job-2xwq4 0/1 CrashLoopBackOff 3 (16s ago) 116s可以看到 Kubernetes 每隔一段时间（延迟会越来越长）就创建一个新的 Pod，而旧的 Pod 状态会变为 Error。13.如何配置失败后不重试，或失败后重新创建通过配置spec.backoffLimitl backoffLimit 字段定义了 Job 在被标记为 Failed 之前可以容忍的失败 Pod 数量。将其设置为 0 意味着不允许有任何失败的 Pod。因此，只要第一个 Pod 失败，Job 就会立即停止并被标记为 Failed。而如果设置 > 0 它会通过创建新 Pod的方式进行重试，直到成功或达到 backoffLimit 上限。 apiVersion: batch/v1 kind: Job metadata: name: falling-job-example spec: # 设置重试上限 backoffLimit: 4 template: spec: containers: - name: worker image: busybox # 模拟一个会失败的命令 command: ["/bin/sh", "-c", "echo 'Attempting task...'; exit 1"] # Job 的 Pod 重启策略必须是 OnFailure 或 Never restartPolicy: OnFailure前面设置的yaml，这里的重试次数为414.CronJob生成的Job名称是如何命名的<CronJob 的名称>-<随机数字>kubectl get jobs NAME STATUS COMPLETIONS DURATION AGE time-test-29202500 Complete 1/1 34s 41stime-job-cronjob 就是之前yaml里面设置的名字metadata: name: time-job-cronjob15.Job/CronJob如何设置资源限制在 Pod 模板中为容器定义 resources 字段。在 Kubernetes 中，资源限制分为两种：
• requests (请求资源):
• CPU: Pod 启动时，节点上必须有这么多空闲的 CPU 资源可供分配。这可以看作是为 Pod 预留的、保证可用的最小资源量。
• Memory: 同理，节点上必须有这么多空闲内存。
• 作用: 主要影响 Pod 的调度。如果集群中没有节点能满足 requests 的要求，Pod 将会一直处于 Pending 状态，无法运行。
• limits (限制资源):
• CPU: 容器能使用的 CPU 上限。如果它试图使用超过这个限制的 CPU，系统会对其进行节流 (throttling)，即强制降低其 CPU 使用率。
• Memory: 容器能使用的内存上限。如果它试图使用超过这个限制的内存，容器会被系统强制终止 (OOMKilled - Out Of Memory Killed)，Pod 会失败。
• 作用: 主要影响 Pod 的运行时行为，防止单个 Pod 耗尽节点资源。
• Job 模板apiVersion: batch/v1 kind: Job metadata: name: pi-calculation-job spec: template: spec: containers: - name: pi-calculator image: perl:5.34 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] resources: requests: # 请求 0.5 个 CPU核心 (500 millicores) cpu: "500m" # 请求 128 Mebibytes 内存 memory: "128Mi" limits: # 限制最多使用 1 个 CPU核心 (1000 millicores) cpu: "1" # 限制最多使用 256 Mebibytes 内存 memory: "256Mi" restartPolicy: OnFailureCronJob模板apiVersion: batch/v1 kind: CronJob metadata: name: backup-cronjob-with-limits spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: backup-worker image: busybox args: - /bin/sh - -c - date; echo "Running backup..."; sleep 10 resources: requests: # 这是一个轻量级任务，请求少量资源 cpu: "100m" # 0.1 CPU memory: "64Mi" limits: # 限制也较低，防止意外消耗 cpu: "200m" # 0.2 CPU memory: "128Mi" restartPolicy: OnFailure16.定义一个CronJob在凌晨3点执行备份脚本，记录日志，并上传到NFS1: 创建 PVCapiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-backup-pvc spec: storageClassName: nfs-client accessModes: - ReadWriteMany resources: requests: storage: 10Gi查看状态是否为bound# kubectl get pvc nfs-backup-pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE nfs-backup-pvc Bound pvc-fd4341c6-b40c-48b2-b05c-713be53de37c 10Gi RWX nfs-client 6m32s2: 创建备份脚本 (ConfigMap)apiVersion: v1 kind: ConfigMap metadata: name: backup-script-cm data: backup.sh: | #!/bin/sh set -e SOURCE_DIR="/source-data" DEST_DIR="/backup-storage" BACKUP_FILENAME="backup-$(date +%Y-%m-%d_%H-%M-%S).tar.gz" echo "==============================================" echo "Backup job started at $(date)" echo "Creating archive..." tar -zcf "${DEST_DIR}/${BACKUP_FILENAME}" -C "${SOURCE_DIR}" . echo "Archive created successfully!" ls -lh "${DEST_DIR}/${BACKUP_FILENAME}" echo "Backup job finished at $(date)" echo "===========================================3: 定义并创建 CronJobapiVersion: batch/v1 kind: CronJob metadata: name: daily-backup-job spec: schedule: "0 3 * * *" jobTemplate: spec: template: spec: containers: - name: backup-runner image: ubuntu:20.04 command: ["/bin/sh", "/scripts/backup.sh"] volumeMounts: - name: script-volume mountPath: /scripts - name: nfs-backup-volume mountPath: /backup-storage - name: source-data-volume mountPath: /source-data readOnly: true volumes: - name: script-volume configMap: name: backup-script-cm defaultMode: 0755 - name: nfs-backup-volume persistentVolumeClaim: # 核心：这里只认 PVC 的名字 claimName: nfs-backup-pvc - name: source-data-volume persistentVolumeClaim: # 指定备份的地方 claimName: app-pvc restartPolicy: OnFailurekubectl get cronjob NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE daily-backup-job 0 3 * * * False 0 7m32s17.什么是Namespace？使用它可以解决什么问题？在Kubernetes中，Namespace可以看作是一个虚拟的集群，它将物理集群划分为多个逻辑部分。每个Namespace都有自己的资源集合，这些资源是相互隔离的，互不干扰。Namespace的用途
• 资源隔离：命名空间可以将集群中的资源划分为多个虚拟的集群，每个命名空间可以拥有自己的资源，如Pods、Services、Deployments等，从而实现资源隔离，大部分资源都是有命名空间属性(少部分资源是全局的)。
• 权限控制：通过RBAC（基于角色的访问控制），可以为不同的命名空间设置不同的访问权限，限制用户的操作范围。
• 组织管理：命名空间可以帮助组织管理资源，不同的团队或项目可以工作在不同的命名空间中，而不会相互干扰。
• 资源配额：可以为命名空间设置资源配额（ResourceQuotas），限制命名空间内可以创建的资源数量，避免单个用户或团队占用过多资源。
• 18.如何创建命名空间？如何在某个命名空间中创建Pod并管理？创建命名空间使用 kubectl命令直接创建# 创建一个名为 'dev' 的命名空间 kubectl create namespace dev使用 YAML 文件定义创建一个名为 namespace-dev.yaml 的文件:apiVersion: v1 kind: Namespace metadata: name: dev # 添加标签 labels: team: backend environment: development应用这个 YAML 文件来创建 Namespace:kubectl apply -f namespace-dev.yaml在某个命名空间中创建 Pod使用 kubectl run命令# 在 'dev' 命名空间中创建一个名为 'nginx-pod' 的 Pod kubectl run nginx-pod --image=nginx -n dev使用 YAML 文件定义 (推荐)apiVersion: v1 kind: Pod metadata: # 指定命名空间 namespace: dev name: nginx-pod-in-yaml labels: app: nginx spec: containers: - name: nginx-container image: nginx:1.25 ports: - containerPort: 80管理特定命名空间中的 Pod
• 查看 Pod 列表:
• kubectl get pods -n dev输出会显示 dev 命名空间下的所有 Pod。
• 查看 Pod 详细信息:
• kubectl describe pod nginx-pod-in-yaml -n dev
• 查看 Pod 日志:
• kubectl logs nginx-pod-in-yaml -n dev
• 进入 Pod 容器:
• kubectl exec -it nginx-pod-in-yaml -n dev -- /bin/bash
• 删除 Pod:
• kubectl delete pod nginx-pod-in-yaml -n dev # 或者通过 YAML 文件删除 kubectl delete -f nginx-pod-dev.yaml19.如何配置kubectl默认的命名空间设置默认namespace：kubectl config set-context --current --namespace=20.使用命名空间将资源隔离（例如nginx-a、nginx-b分别部署在不同namespace中）创建两个命名空间# 创建 namespace-a kubectl create namespace ns-a # 创建 namespace-b kubectl create namespace ns-bkubectl get ns NAME STATUS AGE ns-a Active 67s ns-b Active 67s在每个命名空间中部署独立的 Nginx# nginx-a.yaml apiVersion: v1 kind: Pod metadata: name: nginx-a namespace: ns-a # 指定命名空间 spec: containers: - name: nginx image: nginx# nginx-b.yaml apiVersion: v1 kind: Pod metadata: name: nginx-b namespace: ns-b # 指定命名空间 spec: containers: - name: nginx image: nginxkubectl get pods -n ns-a NAME READY STATUS RESTARTS AGE nginx-a 1/1 Running 0 75s kubectl get pods -n ns-b NAME READY STATUS RESTARTS AGE nginx-b 1/1 Running 0 33s 21.如何删除一个命名空间？会发生什么？当执行删除命令后，Kubernetes 会异步执行以下操作：触发删除流程
• Kubernetes 的命名空间控制器（Namespace Controller）会检测到删除请求。
• 该命名空间的状态会立即变为 Terminating（可通过 kubectl get ns 查看）。
• 清理命名空间内的所有资源
• 自动级联删除：命名空间内的所有资源（Pods、Services、Deployments、ConfigMaps 等）会被自动删除，无需手动逐个删除。
• 删除顺序：Kubernetes 会根据资源的依赖关系按顺序删除。
• 最终删除命名空间本身
• 当所有资源清理完成后，命名空间才会从集群中彻底移除。
• 如果某些资源无法删除（例如卡在终止状态），命名空间会一直处于 Terminating 状态。