K8S-Day6|易北河的个人博客

1. 什么是生命周期

Kubernetes（简称 K8S）中的“生命周期”指的是一个 Pod 或容器在系统中从创建到销毁的整个过程。Kubernetes 提供了两种主要的生命周期钩子（Lifecycle Hooks）来允许用户在特定阶段执行自定义操作：PostStart 和 PreStop。

生命周期阶段

创建阶段：
- PostStart：这个钩子在容器创建之后立即执行。它通常用于初始化任务，例如设置环境或启动服务。
运行阶段：
- 容器正常运行，处理请求或执行任务。
终止阶段：
- PreStop：这个钩子在容器终止之前执行。它通常用于优雅地关闭服务或清理资源。

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

在 Kubernetes 中，Pod 的生命周期主要包括以下几个阶段（Phase），每个阶段代表了 Pod 当前的状态和其所处的运行环境。以下是 Pod 生命周期的主要阶段及其含义：

1. Pending（挂起）

含义：Pod 已被 Kubernetes 系统接受，但其容器尚未被创建。
可能原因：
- 调度器还未找到合适的节点；
- 镜像拉取中；
- 资源不足（如 CPU、内存等）；
- PVC 尚未绑定 PV。

2. Running（运行中）

含义：Pod 已经被调度到某个节点上，并且所有容器都已被创建。
状态特征：
- 至少有一个容器正在运行；
- 或者容器已终止，但重启策略允许重新启动（如 CrashLoopBackOff）。

3. Succeeded（成功）

含义：Pod 中的所有容器都已成功执行完毕并退出。
常见场景：
- Job 完成任务后退出；
- InitContainer 执行完成。

4. Failed（失败）

含义：Pod 中至少有一个容器以非零状态退出或发生错误。
可能原因：
- 容器崩溃；
- 容器镜像不存在；
- 资源限制导致 OOMKilled；
- 容器启动命令执行失败。

5. Unknown（未知）

含义：由于某些原因（如与节点通信故障），Kubernetes 无法获取 Pod 的实际状态。
处理方式：通常需要检查节点状态或网络连接问题。

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

在 Kubernetes 中，postStart 和 preStop 是容器生命周期钩子（Lifecycle Hooks），用于在容器的特定阶段执行自定义操作。它们允许你在容器启动后或停止前运行一些命令或脚本。

一、作用

1. `postStart`

作用：在容器创建后立即执行。
适用场景：
- 初始化配置文件；
- 启动依赖服务；
- 写入日志或标记容器已启动；
- 执行健康检查准备脚本。
注意：此钩子与容器主进程是异步执行的，Kubernetes 不会等待 postStart 完成后再启动主进程。如果 postStart 失败，容器将被重启。

2. `preStop`

作用：在容器终止之前执行。
适用场景：
- 优雅关闭服务；
- 清理临时文件；
- 保存状态信息；
- 等待正在进行的任务完成；
- 通知其他系统该容器即将关闭。
注意：此钩子是同步的，Kubernetes 会等待 preStop 执行完毕或超时（默认 30 秒）后才真正终止容器。

二、配置方式

可以在 Pod 或 Deployment 的 YAML 文件中为容器配置这两个钩子。以下是示例：

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'Container started' > /tmp/lifecycle.log"]
      preStop:
        exec:
          command: ["sh", "-c", "echo 'Container stopping' >> /tmp/lifecycle.log"]
// ... existing code ...

三、详细说明

1. `postStart` 配置

exec：通过执行命令来触发操作。
示例：写入日志文件 /tmp/lifecycle.log。
其他支持的方式还包括 HTTP 请求、TCP 连接等。

2. `preStop` 配置

exec：同样通过执行命令来触发操作。
示例：在容器停止前追加日志信息到 /tmp/lifecycle.log。
也可以使用 HTTP 请求或 TCP 检查等方式。

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

在 Kubernetes 中，如果你想让容器在启动时执行某个命令，可以通过以下几种方式实现：

1. 使用 `command` 和 `args`（覆盖容器默认入口命令）

你可以在 Pod 或 Deployment 的 YAML 文件中使用 command 和 args 字段来指定容器启动时运行的命令和参数。

示例：启动容器时运行自定义命令

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: command-demo
spec:
  containers:
  - name: command-container
    image: busybox
    command: ["sh", "-c"]
    args:
      - echo "Hello from the container!"; sleep 10;
// ... existing code ...

在这个例子中：

command 替换了容器镜像中的默认入口命令（ENTRYPOINT）；
args 提供了命令的具体操作；
容器启动后会打印 "Hello from the container!" 并休眠 10 秒后退出。

2. 使用 `postStart` 生命周期钩子（在容器创建后异步执行）

如果你希望在容器创建之后异步执行某些操作（如写入日志、初始化配置），可以使用 postStart 钩子。

示例：使用 `postStart` 执行命令

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'Container started' > /tmp/lifecycle.log"]
// ... existing code ...

在 Dockerfile 中设置 `CMD` 或 `ENTRYPOINT`（构建镜像时指定）

如果你控制镜像的构建过程，可以在 Dockerfile 中通过 CMD 或 ENTRYPOINT 指定容器启动时运行的命令。

示例 Dockerfile：

FROM ubuntu
CMD ["echo", "Hello from CMD!"]

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

生命周期钩子（Lifecycle Hook）是 Kubernetes 提供的一种机制，用于在容器的特定生命周期阶段触发自定义操作。Kubernetes 提供了两个主要的生命周期钩子：

1. `postStart`（容器启动后）

作用：在容器创建后立即执行。
适用场景：
- 初始化配置文件；
- 启动依赖服务；
- 写入日志或标记容器已启动；
- 执行健康检查准备脚本。

注意：此钩子与容器主进程是异步执行的，Kubernetes 不会等待 postStart 完成后再启动主进程。如果 postStart 失败，容器将被重启。

2. `preStop`（容器终止前）

作用：在容器终止之前执行。
适用场景：
- 优雅关闭服务；
- 清理临时文件；
- 保存状态信息；
- 等待正在进行的任务完成；
- 通知其他系统该容器即将关闭。

注意：此钩子是同步的，Kubernetes 会等待 preStop 执行完毕或超时（默认 30 秒）后才真正终止容器。

生命周期钩子的典型使用场景

场景	钩子类型	描述
初始化操作	`postStart`	在容器启动后写入初始配置文件、启动辅助服务等。
调试用途	`postStart`	写入日志文件或标记容器状态，便于调试。
优雅关闭服务	`preStop`	在容器终止前执行清理逻辑，如关闭数据库连接、保存缓存数据等。
资源释放	`preStop`	确保服务完全停止后再释放资源，避免中断请求。
状态通知	`preStop`	在容器退出前发送通知到监控系统或日志中心。

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

在 Kubernetes 中，Job 是一种控制器（Controller），用于确保指定的 Pod 成功完成执行。与 Deployment 或 ReplicaSet 不同，Job 并不是为了维持 Pod 的长期运行，而是为了确保某个任务能够成功执行完毕。

一、Job 的作用

确保任务完成：创建一个或多个 Pod，并确保至少一个 Pod 成功退出。
失败重试机制：如果 Pod 失败，Job 控制器会根据配置重新启动新的 Pod。
并行处理：可以配置多个并行的 Pod 来加速任务完成。

二、Job 的典型使用场景

场景	描述
批处理任务	如数据迁移、日志归档、备份操作等一次性任务。
定时任务	结合 CronJob 实现周期性任务调度（如每日清理日志）。
计算密集型任务	如图像处理、视频编码、科学计算等需要大量资源但不需要长时间运行的任务。
测试环境初始化	在测试环境中部署测试数据或初始化脚本。
数据导入/导出	将数据从一个系统导入到另一个系统，例如将 CSV 数据导入数据库。

三、Job 的生命周期

创建阶段：
- Job 创建后，Kubernetes 会根据模板生成一个或多个 Pod。
执行阶段：
- 每个 Pod 执行其容器命令。
- 如果 Pod 成功退出（状态为 Completed），Job 完成。
失败重试阶段：
- 如果 Pod 失败（状态为 Error 或 CrashLoopBackOff），Job 控制器会根据 backoffLimit 设置决定是否重启新 Pod。
完成阶段：

当达到指定的成功次数（默认为 1）时，Job 标记为完成（Succeeded）。

四、Job 配置示例

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: job-container
        image: busybox
        command:
          - sh
          - -c
          - echo "Hello from the job!"; sleep 5;
      restartPolicy: OnFailure
  backoffLimit: 4
// ... existing code ...

在这个例子中：

command 指定了容器启动时要执行的命令；
restartPolicy: OnFailure 表示如果容器失败，Job 控制器将尝试重启新的 Pod；
backoffLimit: 4 表示最多重试 4 次，超过则标记为失败。

使用建议	说明
任务类型选择 Job	对于只需要执行一次、完成后即可销毁的任务。
使用 CronJob 实现定时任务	对于需要定期执行的任务（如日志清理、数据汇总）。
合理设置重试策略	`backoffLimit` 应根据任务重要性和失败概率进行调整。
避免长时间运行	如果任务需要长时间运行，应使用 Deployment 或 StatefulSet。
结合 ConfigMap/Secret 注入参数	动态配置任务参数，提升灵活性。
监控 Job 状态	使用 `kubectl get jobs` 和 `kubectl describe job <name>` 查看任务状态和日志。

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

在 Kubernetes 中，CronJob 是一种控制器（Controller），用于 周期性地运行任务。它是基于标准的 Unix cron 表达式来定义执行时间的，适用于定时备份、日志清理、数据同步等需要定期执行的任务。

一、CronJob 的作用

周期性执行任务：按照设定的时间间隔自动触发任务；
确保任务完成：每个调度周期生成一个 Job，并确保其成功执行；
失败重试机制：如果任务失败，可以配置重试次数；
并发控制：支持设置多个并发策略（如禁止并发、允许并发等）。

二、CronJob 时间表达式格式

Kubernetes CronJob 使用的是 5 字段的 cron 表达式，格式如下：

┌───────────── 分钟 (0 - 59)
│ ┌────────────── 小时 (0 - 23)
│ │ ┌─────────────── 日期 (1 - 31)
│ │ │ ┌──────────────── 月份 (1 - 12)
│ │ │ │ ┌───────────────── 星期几 (0 - 6)（星期天为 0）
│ │ │ │ │
* * * * *

四、常见时间表达式示例

表达式	含义
`/1 * * *`	每分钟执行一次
`0 /1 * *`	每小时整点执行一次
`0 2 * * *`	每天凌晨 2 点执行
`0 0 * * 0`	每周日凌晨 0 点执行
`0 0 1 * *`	每月 1 号凌晨 0 点执行
`0 0 1 1 *`	每年 1 月 1 日凌晨 0 点执行
`0 0/2 * * *`	每两小时执行一次
`/30 * * *`	每 30 分钟执行一次

五、CronJob 配置示例

以下是一个每天凌晨 2 点运行的 CronJob 示例：

// ... existing code ...
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-cleanup
spec:
  schedule: "0 2 * * *" # 每天凌晨 2 点执行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleanup-container
            image: my-cleanup-tool
            command:
              - /bin/sh
              - -c
              - clean_up_script.sh
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
// ... existing code ...

在这个示例中：

schedule: "0 2 * * *" 表示每天凌晨 2 点执行；
jobTemplate 定义了每次调度要执行的 Job；
restartPolicy: OnFailure 表示如果容器失败会自动重启；
successfulJobsHistoryLimit 和 failedJobsHistoryLimit 控制保留的历史任务数量。

8. 如何限制Job/CronJob的重试次数和并发执行策略

在 Kubernetes 中，Job 和 CronJob 提供了配置 重试次数 和 并发执行策略 的能力，以控制任务的失败处理机制和并行行为。

一、限制 Job/CronJob 的重试次数

Kubernetes 使用 .spec.backoffLimit 字段来控制一个任务的最大重试次数。如果任务失败，控制器会尝试重新创建 Pod 并再次执行任务，直到达到最大重试次数。

示例：设置 Job 最多重试 4 次

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
        - name: job-container
          image: busybox
          command:
            - sh
            - -c
            - echo "Hello from the job!"; exit 1 # 故意退出失败用于演示重试
      restartPolicy: OnFailure
  backoffLimit: 4 # 表示最多重试 4 次
// ... existing code ...

在这个例子中：

如果容器返回非 0 状态码（表示失败），Job 控制器将尝试重启新的 Pod；
最多重试 4 次，超过后标记为失败；
restartPolicy: OnFailure 表示只在失败时重试。

CronJob 设置重试次数方式相同：

// ... existing code ...
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-job
spec:
  schedule: "0 2 * * *" # 每天凌晨 2 点执行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job-container
              image: my-cleanup-tool
              command:
                - /bin/sh
                - -c
                - clean_up_script.sh
          restartPolicy: OnFailure
      backoffLimit: 3 # 失败最多重试 3 次
// ... existing code ...

二、控制并发执行策略

Kubernetes 提供 .spec.concurrencyPolicy 来控制多个任务实例是否可以同时运行。这对于定时任务尤其重要，避免多个实例同时运行导致冲突或资源争用。

可选的并发策略：

策略	描述
`Allow`	默认值，允许并发执行多个任务实例
`Forbid`	如果上一个任务还在运行，则跳过本次调度
`Replace`	如果上一个任务仍在运行，则终止它并启动新任务

示例：禁止 CronJob 并发执行

// ... existing code ...
spec:
  concurrencyPolicy: Forbid # 如果上一个任务还在运行，跳过本次调度
// ... existing code ...

示例：替换正在运行的任务

// ... existing code ...
spec:
  concurrencyPolicy: Replace # 终止旧任务，启动新任务
// ... existing code ...

9. 编写一个Job完成一次性任务（例如打印hello、备份文件等）

在 Kubernetes 中，Job 是一种控制器，用于确保一个或多个 Pod 成功完成执行。你可以使用 Job 来运行一次性任务，例如打印 "Hello World"、备份文件、清理日志等。

示例：编写一个打印 "Hello World" 的 Job

以下是一个简单的 YAML 文件，定义了一个 Job，它会启动一个容器并执行命令打印 "Hello from Kubernetes Job!"：

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: hello-job
spec:
  template:
    spec:
      containers:
        - name: hello
          image: busybox
          command:
            - sh
            - -c
            - echo "Hello from Kubernetes Job!"
      restartPolicy: OnFailure
  backoffLimit: 3  # 最多重试 3 次
// ... existing code ...

10. 编写一个CronJob，每分钟执行一次，并输出时间

在 Kubernetes 中，你可以使用 CronJob 来实现周期性任务。下面是一个完整的示例，展示如何创建一个 每分钟执行一次 的 CronJob，并输出当前时间。

示例：每分钟打印当前时间的 CronJob

// ... existing code ...
apiVersion: batch/v1
kind: CronJob
metadata:
  name: time-printer
spec:
  schedule: "*/1 * * * *"  # 每分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: time-container
              image: busybox
              command:
                - /bin/sh
                - -c
                - date; sleep 10  # 打印时间并休眠10秒
          restartPolicy: OnFailure
      backoffLimit: 3  # 最多重试3次
  concurrencyPolicy: Forbid  # 禁止并发执行
// ... existing code ...

字段说明：

字段	说明
`schedule: "/1 * * *"`	cron 表达式，表示每分钟运行一次
`command`	覆盖容器默认入口命令，这里用于执行 `date` 命令输出当前时间
`restartPolicy: OnFailure`	如果任务失败，Kubernetes 将尝试重启 Pod
`backoffLimit: 3`	最多重试 3 次，防止无限重试
`concurrencyPolicy: Forbid`	如果上一个任务仍在运行，则跳过本次调度

11. 如何查看Job的运行状态、日志

在 Kubernetes 中，查看 Job 的运行状态和日志 主要涉及以下几个命令和操作流程：

一、查看 Job 的运行状态

1. 查看所有 Job

kubectl get jobs

2. 查看 Job 的详细信息（包括失败原因）

kubectl describe job hello-job

输出中包含：

Job 的调度状态；
Pod 创建情况；
失败事件信息（如果有）；
并发策略、重试次数等配置信息。

二、查看 Job 的日志

1. 查看 Job 对应 Pod 的日志

首先获取 Pod 名称（见上一步），然后使用以下命令查看日志：

kubectl logs <pod-name>

2. 实时查看日志（类似 tail -f）

kubectl logs -f <pod-name>

三、查看 CronJob 的运行记录

CronJob 会定期触发 Job，你可以查看这些 Job 的历史执行记录：

1. 查看由 CronJob 触发的 Job 列表

kubectl get jobs

2. 查看特定 Job 的日志

kubectl logs <job-pod-name>

12. 如果Job失败，默认行为是怎样的

在 Kubernetes 中，如果一个 Job 执行失败，其默认行为取决于以下配置：

restartPolicy：定义 Pod 的重启策略；
backoffLimit：定义最大重试次数。

默认行为总结

1. 默认 `restartPolicy: Always`

如果你没有显式设置 restartPolicy，Kubernetes 默认使用 Always；
意味着只要容器退出（无论成功与否），kubelet 都会尝试重启该容器；
但 Job 控制器会根据任务完成情况控制是否继续创建新的 Pod。

2. 默认 `backoffLimit: 6`

.spec.backoffLimit 表示 Job 最大失败重试次数，默认为 6；
Job 控制器会在任务失败后不断尝试重新创建 Pod；
达到最大重试次数后仍未成功，则 Job 被标记为 Failed 状态。

13. 如何配置失败后不重试，或失败后重新创建

在 Kubernetes 中，你可以通过配置 Job 或 CronJob 的以下字段来控制失败后的行为：

不重试：设置 backoffLimit: 0 并使用 restartPolicy: Never
失败后重新创建：默认行为（基于 restartPolicy: Always 或 OnFailure）

一、配置 Job 失败后不重试

如果你希望 Job 在失败后不再尝试重启 Pod，可以设置如下参数：

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: no-retry-job
spec:
  template:
    spec:
      containers:
        - name: job-container
          image: busybox
          command:
            - sh
            - -c
            - echo "Starting job..."; exit 1 # 故意失败
      restartPolicy: Never  # 容器退出后不会重启
  backoffLimit: 0  # 达到最大重试次数后不再尝试
// ... existing code ...

字段说明：

restartPolicy: Never：容器执行完成后即使失败也不会重启；
backoffLimit: 0：Job 控制器不会尝试创建新的 Pod。

二、配置 Job/CronJob 失败后重新创建 Pod 执行任务

这是 Kubernetes 的默认行为。Job 控制器会在 Pod 失败后不断尝试创建新的 Pod，直到达到 .spec.backoffLimit 次数。

示例 YAML（Job）：

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: retry-job
spec:
  template:
    spec:
      containers:
        - name: job-container
          image: busybox
          command:
            - sh
            - -c
            - echo "Trying to run..."; exit 1 # 模拟失败任务
      restartPolicy: OnFailure  # 如果容器失败，kubelet 会重启容器
  backoffLimit: 3  # 最多重试 3 次
// ... existing code ...

字段说明：

restartPolicy: OnFailure：如果容器失败，kubelet 会重启该容器；
backoffLimit: 3：Job 控制器最多尝试 3 次重建 Pod；
concurrencyPolicy: Forbid（适用于 CronJob）：防止多个实例同时运行。

14. CronJob生成的Job名称是如何命名的

CronJob 控制器为每次调度创建的 Job 命名格式如下：

[cronjob-name]-[schedule-timestamp]

其中：

[cronjob-name]：你定义的 CronJob 名称；
[schedule-timestamp]：由控制器生成的时间戳，格式为 YYYYMMDDHHMM（年月日时分）；
时间戳基于 CronJob 的调度时间，不是 Pod 启动时间。

假设你定义了一个名为 daily-job 的 CronJob：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-job
spec:
  schedule: "0 2 * * *" # 每天凌晨 2 点执行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job-container
              image: my-tool
              command:
                - /bin/sh
                - -c
                - do-something.sh

yamldaily-job-2507141600
daily-job-2507141605
daily-job-2507141610

15. Job/CronJob如何设置资源限制

在 Kubernetes 中，为 Job 或 CronJob 设置资源限制（如 CPU 和内存）是确保任务稳定运行、防止资源争用的重要做法。你可以在 Pod 模板的容器定义中通过 .resources 字段来设置请求和限制。

一、Job 设置资源限制

// ... existing code ...
apiVersion: batch/v1
kind: Job
metadata:
  name: resource-limited-job
spec:
  template:
    spec:
      containers:
        - name: job-container
          image: busybox
          command:
            - sh
            - -c
            - echo "Running with resource limits"; sleep 10
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"
      restartPolicy: OnFailure
  backoffLimit: 3
// ... existing code ...

字段说明：

requests.memory/cpu：表示该容器启动和执行时所需的最小资源；
limits.memory/cpu：表示该容器最多可使用的资源上限；
如果节点上没有足够的资源满足请求，Pod 将处于 Pending 状态；
如果容器使用超过限制的资源（如内存），Kubernetes 会将其 OOMKilled 并重启。

16. 定义一个CronJob在凌晨3点执行备份脚本，记录日志，并上传到NFS

示例：CronJob YAML 配置文件

// ... existing code ...
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 3 * * *" # 每天凌晨 3 点执行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup-container
              image: alpine
              command:
                - /bin/sh
                - -c
                - |
                  echo "$(date): Starting backup..." >> /logs/backup.log
                  /scripts/backup.sh > /logs/backup-output.log 2>&1
                  cp /data/*.tar.gz /nfs/backup/
                  echo "$(date): Backup completed" >> /logs/backup.log
              volumeMounts:
                - name: logs
                  mountPath: /logs
                - name: backup-scripts
                  mountPath: /scripts
                - name: nfs-backup
                  mountPath: /nfs/backup
          restartPolicy: OnFailure
          volumes:
            - name: logs
              persistentVolumeClaim:
                claimName: logs-pvc
            - name: backup-scripts
              configMap:
                name: backup-scripts-cm
            - name: nfs-backup
              persistentVolumeClaim:
                claimName: nfs-backup-pvc
  backoffLimit: 3
  concurrencyPolicy: Forbid
// ... existing code ...

17. 什么是Namespace？使用它可以解决什么问题？

在 Kubernetes 中，Namespace（命名空间） 是一种将集群划分为多个虚拟子集群的机制。它并不是真正的“物理隔离”，而是为资源组织、访问控制和资源共享提供了一种逻辑上的分组方式。

什么是 Namespace？

定义：Namespace 是 Kubernetes 中用于对资源进行逻辑隔离的一种机制。
默认命名空间：如果你不指定命名空间，所有资源都部署在 default 命名空间下；
支持多租户管理：适用于多个团队、项目或环境共享同一个 Kubernetes 集群。

使用 Namespace 可以解决的问题

问题	解决方式
资源冲突	不同团队/项目使用相同名称的资源时不会冲突（如 `app` 可同时存在于 `team-a` 和 `team-b` 命名空间）
权限隔离	结合 RBAC（Role-Based Access Control），可限制某个用户或服务账户只能访问特定命名空间中的资源
资源配额管理	通过 `ResourceQuota` 控制每个命名空间的最大 CPU、内存、Pod 数量等资源消耗
网络策略隔离	可配置 NetworkPolicy，限制不同命名空间之间的通信
服务发现隔离	同一命名空间内的 Pod 可通过服务名直接访问；跨命名空间需使用 `<service>.<namespace>` 格式
多环境共存	可将开发（dev）、测试（test）、生产（prod）部署到不同命名空间中，避免相互干扰

18. 如何创建命名空间？如何在某个命名空间中创建Pod并管理？

1. 创建 Namespace

// ... existing code ...
apiVersion: v1
kind: Namespace
metadata:
  name: dev
// ... existing code ...

2. 在该命名空间中部署 Pod

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: dev
spec:
  containers:
    - name: app-container
      image: nginx
// ... existing code ...

19. 如何配置kubectl默认的命名空间？

在 Kubernetes 中，kubectl 默认使用的命名空间是 default。如果你希望更改默认命名空间，可以通过修改 当前上下文（context） 来实现。

方法一：临时切换当前命名空间（仅限本次使用）

你可以使用 -n 或 --namespace 参数临时指定命名空间：

kubectl get pods -n dev

这不会改变默认命名空间，只适用于当前命令。

方法二：永久更改当前上下文的默认命名空间

1. 查看当前上下文信息：

kubectl config current-context

2. 修改当前上下文的默认命名空间：

kubectl config set-context --current --namespace=dev

方法三：查看和管理多个上下文（适合多集群/环境）

1. 查看所有上下文：

kubectl config get-contexts

20. 使用命名空间将资源隔离（例如nginx-a、nginx-b分别部署在不同namespace中）

步骤一：创建命名空间

// ... existing code ...
apiVersion: v1
kind: Namespace
metadata:
  name: namespace-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace-b
// ... existing code ...

步骤二：在不同命名空间中部署 nginx

1. 在 `namespace-a` 部署 nginx-a

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: namespace-a
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: namespace-a
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
// ... existing code ...

2. 在 namespace-b 部署 nginx-b

// ... existing code ...
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: namespace-b
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: namespace-b
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
// ... existing code ...

21. 如何删除一个命名空间？会发生什么？

删除命名空间的命令

kubectl delete namespace <namespace-name>

删除命名空间会发生什么？

1. 命名空间状态变为 Terminating

命名空间不会立即消失；
状态会变为 Terminating，表示正在清理资源；
Kubernetes 会尝试删除该命名空间下的所有资源（Pod、Service、Deployment、PVC 等）；

2. 自动清理该命名空间下的所有资源

所有 Pod、Service、Deployment、StatefulSet、Job、CronJob 等都会被删除；
所有关联的 PVC 和 PV（如果配置了回收策略为 Delete）也将被删除；
RBAC 规则（Role、RoleBinding）也会被清除；
如果命名空间中运行着长期任务（如 CronJob），它们将被终止。

3. 命名空间最终从集群中移除

当所有资源都被成功删除后，命名空间将从集群中彻底移除；
若某些资源无法删除（如 API 资源卡住或控制器未响应），命名空间可能会长时间处于 Terminating 状态。

查看命名空间状态

你可以使用以下命令查看命名空间的状态：

kubectl get namespaces

1. 什么是生命周期

生命周期阶段

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

1. Pending（挂起）

2. Running（运行中）

3. Succeeded（成功）

4. Failed（失败）

5. Unknown（未知）

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

一、作用

1. postStart

2. preStop

二、配置方式

三、详细说明

1. postStart 配置

2. preStop 配置

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

1. 使用 command 和 args（覆盖容器默认入口命令）

示例：启动容器时运行自定义命令

2. 使用 postStart 生命周期钩子（在容器创建后异步执行）

示例：使用 postStart 执行命令

在 Dockerfile 中设置 CMD 或 ENTRYPOINT（构建镜像时指定）

示例 Dockerfile：

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

1. postStart（容器启动后）

2. preStop（容器终止前）

生命周期钩子的典型使用场景

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

一、Job 的作用

二、Job 的典型使用场景

三、Job 的生命周期

四、Job 配置示例

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

一、CronJob 的作用

二、CronJob 时间表达式格式

四、常见时间表达式示例

五、CronJob 配置示例

8. 如何限制Job/CronJob的重试次数和并发执行策略

一、限制 Job/CronJob 的重试次数

示例：设置 Job 最多重试 4 次

CronJob 设置重试次数方式相同：

二、控制并发执行策略

可选的并发策略：

示例：禁止 CronJob 并发执行

示例：替换正在运行的任务

9. 编写一个Job完成一次性任务（例如打印hello、备份文件等）

示例：编写一个打印 "Hello World" 的 Job

10. 编写一个CronJob，每分钟执行一次，并输出时间

示例：每分钟打印当前时间的 CronJob

字段说明：

11. 如何查看Job的运行状态、日志

一、查看 Job 的运行状态

1. 查看所有 Job

2. 查看 Job 的详细信息（包括失败原因）

二、查看 Job 的日志

1. 查看 Job 对应 Pod 的日志

2. 实时查看日志（类似 tail -f）

三、查看 CronJob 的运行记录

1. 查看由 CronJob 触发的 Job 列表

2. 查看特定 Job 的日志

12. 如果Job失败，默认行为是怎样的

默认行为总结

1. 默认 restartPolicy: Always

2. 默认 backoffLimit: 6

13. 如何配置失败后不重试，或失败后重新创建

一、配置 Job 失败后不重试

字段说明：

二、配置 Job/CronJob 失败后重新创建 Pod 执行任务

示例 YAML（Job）：

字段说明：

14. CronJob生成的Job名称是如何命名的

15. Job/CronJob如何设置资源限制

一、Job 设置资源限制

字段说明：

16. 定义一个CronJob在凌晨3点执行备份脚本，记录日志，并上传到NFS

示例：CronJob YAML 配置文件

相关资源定义

1. ConfigMap：备份脚本

2. PVC：日志和 NFS 存储

日志 PVC：

1. `postStart`

2. `preStop`

1. `postStart` 配置

2. `preStop` 配置

1. 使用 `command` 和 `args`（覆盖容器默认入口命令）

2. 使用 `postStart` 生命周期钩子（在容器创建后异步执行）

示例：使用 `postStart` 执行命令

在 Dockerfile 中设置 `CMD` 或 `ENTRYPOINT`（构建镜像时指定）

1. `postStart`（容器启动后）

2. `preStop`（容器终止前）

1. 默认 `restartPolicy: Always`

2. 默认 `backoffLimit: 6`

1. 在 `namespace-a` 部署 nginx-a