【Linux&Kubernetes】 必学知识点合集二
欢迎各位大佬互三学习！
目录
1. 什么是 K8s 的 Namespace？
2. 系统默认创建了哪几个 Namespace？
3. 什么是 Pod？
4. 解释 Pod 的生命周期
核心生命周期阶段
容器详细状态
5. Init 类型容器有什么特点，主要用途？
核心特点
主要用途
6. Sidecar 类型容器和 Init 容器的区别在哪？
7. 什么是静态 Pod？
8. 说明 K8s 控制器的作用？
9. 什么是 ReplicaSet，说明它的主要用途？
核心用途
10. Deployment 控制器是如何工作的，举例说明其常见用途？
工作原理
常见用途
11. 解释 DaemonSet，列举其使用场景
典型使用场景
12. 什么是 StatefulSet，其主要作用是什么？
核心作用
13. 说明 Job 与 CronJob 的功能
Job 功能
CronJob 功能
本文整理 K8s 入门核心基础概念，涵盖命名空间、Pod、各类控制器等高频知识点，内容简洁易懂，适合快速梳理和复习，也可作为入门笔记参考。
1. 什么是 K8s 的 Namespace？
Kubernetes 支持基于同一个物理集群创建多个虚拟集群，这些虚拟集群即为Namespace（命名空间）。所有命名空间共享物理集群的节点、CPU、内存等底层硬件资源，但在资源管理、权限控制、资源命名等层面相互独立，实现集群内的资源隔离与分组管理。
2. 系统默认创建了哪几个 Namespace？
K8s 集群初始化后会默认创建 4 个核心命名空间，各有专属用途：
- default：默认工作命名空间，无需手动创建即可直接部署 Pod，适用于测试或临时业务部署。
- kube-node-lease：存储与节点关联的 Lease（租约）对象，kubelet 通过该命名空间向控制面发送心跳（默认 10 秒 / 次），控制面据此检测节点故障。
- kube-public：所有客户端（含未认证客户端）均可读取，为集群级公共资源预留，存放集群初始化 ConfigMap、版本信息、公共证书等公共配置（公共属性为约定而非强制）。
- kube-system：存放 K8s 所有核心系统组件和必备插件，包括 kube-apiserver、kube-controller-manager 等控制面组件，以及 Calico/Flannel（网络）、CoreDNS（域名解析）、Metrics-server（监控）等插件，优先级极高，禁止随意修改该命名空间内资源。
3. 什么是 Pod？
Pod 是 Kubernetes 中最小的部署和工作单元，由一个或多个紧密耦合的容器组成。Pod 内的所有容器共享网络命名空间、存储卷、主机名等资源，且会被统一调度到同一个节点，实现一起启动、一起停止、一起销毁，解决容器间的紧密协作问题。
4. 解释 Pod 的生命周期
Pod 从创建到销毁会经历多个核心生命周期阶段，核心状态由 K8s 控制面维护，同时容器自身也有细分状态：
核心生命周期阶段
- Pending（挂起）：Pod 已被控制面（APIServer + Controller Manager）接受，但未完成节点调度；或调度完成后，正在拉取容器镜像、初始化存储 / 网络。
- Running（运行中）：Pod 已成功调度到节点，所有容器均已创建，且至少有一个容器处于运行、启动或重启状态。
- Succeeded（成功完成）：Pod 内所有容器均正常终止（退出码 0），且不会被重启，适用于一次性任务（如 Job 创建的 Pod）。
- Failed（失败）：Pod 内所有容器均已终止，且至少有一个容器非正常终止（退出码非 0），或容器启动失败（配置错误、依赖缺失、镜像拉取失败等）。
- Unknown（未知）：K8s 控制面无法获取 Pod 的状态信息，通常因节点故障、kubelet 与 APIServer 通信中断导致。
容器详细状态
- Waiting（等待）：容器处于启动前的准备阶段（如拉取镜像、等待依赖）。
- Running（运行）：容器正常运行中。
- Terminated（终止）：容器已停止运行，包含正常 / 非正常终止两种情况。
5. Init 类型容器有什么特点，主要用途？
Init 容器是 Pod 内的特殊前置容器，专为业务容器做初始化准备，核心特点和用途如下：
核心特点
- 执行时机：在所有业务容器启动前按定义顺序依次运行，全部执行成功后，业务容器才会启动。
- 运行规则：若 Init 容器执行失败，kubelet 会不断重启该 Init 容器直至成功；若 Pod 的
restartPolicy为Never，则 Init 容器失败后整个 Pod 直接标记为 Failed。 - 生命周期：一次性运行，任务完成后立即退出，不会长期驻留。
主要用途
为业务容器提供初始化能力，解决业务容器启动前的依赖问题，常见场景：
- 检查后端服务（如数据库、Redis）是否可用；
- 拉取业务配置、初始化存储目录；
- 执行预启动脚本、配置环境变量。
6. Sidecar 类型容器和 Init 容器的区别在哪？
Sidecar 容器与 Init 容器均为 Pod 内的辅助容器，但执行时机、生命周期、核心作用完全不同，核心区别如下：
| 特性 | Init 容器 | Sidecar 容器 |
|---|---|---|
| 执行时机 | 业务容器启动前运行 | 与业务容器并行启动 |
| 生命周期 | 一次性执行，完成后退出 | 长期运行，与业务容器生命周期绑定（业务容器销毁则 Sidecar 也销毁） |
| 核心作用 | 初始化、依赖检查、环境准备 | 增强业务容器能力，提供持续辅助服务 |
| 运行次数 | 仅运行一次（失败则重启） | 全程运行，随业务容器持续工作 |
典型示例：Init 容器检查数据库连通性，Sidecar 容器做日志收集、流量代理、服务监控。
7. 什么是静态 Pod？
静态 Pod 是由节点上的 kubelet 守护进程直接管理的 Pod，无需 K8s APIServer 监管，是一种特殊的 Pod 部署方式，核心特性：
- 管理主体：仅由所在节点的 kubelet 管理，APIServer 无法直接控制（如创建、删除、更新）。
- 节点绑定：静态 Pod永久绑定到指定节点，不会被调度到其他节点。
- 镜像 Pod（mirror Pod）：kubelet 会自动通过 APIServer 为静态 Pod 创建一个镜像 Pod，使静态 Pod 在 APIServer 中可见（可通过
kubectl get pod查看），但镜像 Pod 仅为状态同步，无法操作。 - 命名规则：静态 Pod 的名称会以所在节点的主机名作为后缀，便于识别。
8. 说明 K8s 控制器的作用？
K8s 控制器（Controller）是集群的核心管理组件，基于声明式 API工作，核心作用：持续监控集群的当前状态，与用户定义的期望状态进行对比，若存在差异，自动执行调谐操作（如创建、删除、更新 Pod），将集群状态逐步调整为期望状态，实现集群资源的自动化管理，无需人工干预。
简单来说：控制器的核心是保证 “实际状态”=“期望状态”。
9. 什么是 ReplicaSet，说明它的主要用途？
ReplicaSet 是 K8s 中用于管理 Pod 副本数量的核心控制器，是传统 ReplicationController 的升级版，功能更强大、语法更灵活。
核心用途
维护集群中指定数量的 Pod 副本始终处于运行状态，确保应用的高可用性：
- 若 Pod 因节点故障、容器崩溃等原因被销毁，ReplicaSet 会自动创建新的 Pod补充，保证副本数不低于期望数量；
- 若 Pod 数量超出期望数量，ReplicaSet 会自动删除多余的 Pod，实现数量精准控制；
- 支持基于标签选择器管理 Pod，仅管理匹配标签的 Pod，实现灵活的分组管理。
注意：ReplicaSet 仅负责 Pod 副本数量的维护，不支持应用的版本更新、回滚等高级功能，通常不会单独使用，而是作为Deployment 的底层组件被调用。
10. Deployment 控制器是如何工作的，举例说明其常见用途？
Deployment 是 K8s 中最常用的无状态应用管理控制器，基于分层管理思想工作，是 ReplicaSet 的上层封装，解决了 ReplicaSet 无法做版本管理的问题。
工作原理
Deployment 通过 Deployment → ReplicaSet → Pod 三层级关系实现应用的全生命周期管理：
- 用户通过 Deployment 定义应用的期望状态（如镜像版本、副本数、容器配置）；
- Deployment 自动创建ReplicaSet，由 ReplicaSet 负责维护 Pod 的副本数量；
- 当应用需要更新时，Deployment 会创建新的 ReplicaSet，逐步扩容新 ReplicaSet 的 Pod，同时缩容旧 ReplicaSet 的 Pod，实现滚动更新；若更新失败，可通过回滚操作恢复到旧的 ReplicaSet 版本。
常见用途
- 弹性扩缩容：通过修改 Deployment 的副本数，快速实现应用的水平扩容 / 缩容，应对业务流量变化；
- 版本更新：通过修改镜像版本，实现应用的滚动更新，更新过程中应用不中断，保证服务可用性；
- 版本回滚：若更新后的应用出现故障，可快速回滚到之前的稳定版本，降低故障影响；
- 批量重启 Pod：通过更新 Deployment 的注解（annotation），实现无感知的 Pod 批量重启，适用于配置刷新等场景。
示例：将应用镜像从v1.0更新为v2.0，Deployment 会创建新 ReplicaSet（对应 v2.0），逐步将 Pod 数从 0 扩容到 3，同时将旧 ReplicaSet（对应 v1.0）的 Pod 数从 3 缩容到 0，整个过程中始终有 3 个 Pod 运行，服务不中断。
11. 解释 DaemonSet，列举其使用场景
DaemonSet 是 K8s 中用于在节点上部署守护进程的控制器，核心特性：确保集群中全部节点或符合标签选择器的部分节点上，各运行一个且仅一个 Pod 副本。
- 当有新节点加入集群时，DaemonSet 会自动为该节点创建对应的 Pod；
- 当有节点从集群移除时，该节点上的 DaemonSet Pod 会被自动回收；
- 删除 DaemonSet 时，其创建的所有 Pod 会被一并删除。
典型使用场景
- 在每个节点上运行集群守护进程：如网络插件（Calico/Flannel）的节点代理、kube-proxy（服务转发）；
- 在每个节点上运行日志收集守护进程：如 Fluentd、Filebeat，收集节点上所有 Pod 的日志；
- 在每个节点上运行监控守护进程：如 Node Exporter，采集节点的 CPU、内存、磁盘等监控指标；
- 在每个节点上运行存储守护进程：如 CSI 节点插件，实现节点级的存储卷管理。
12. 什么是 StatefulSet，其主要作用是什么？
StatefulSet 是 K8s 中专门用于管理有状态应用的控制器，针对需要稳定标识、持久存储、有序操作的应用设计，与 Deployment（管理无状态应用）形成互补。
StatefulSet 管理的 Pod 基于相同的容器规约创建，但为每个 Pod 维护一个粘性的、永久不变的唯一 ID，Pod 的名称、网络标识、存储卷均与该 ID 绑定，即使 Pod 被重建、调度到其他节点，其 ID 和相关资源也不会改变。
核心作用
解决有状态应用的部署、管理难题，满足有状态应用的核心需求，适用于需要以下一个或多个特性的应用：
- 稳定的、唯一的网络标识符：Pod 拥有固定的 DNS 域名（如
app-0.xxx.svc、app-1.xxx.svc），而非随机生成的名称； - 稳定的、持久的存储：每个 Pod 绑定专属的持久化存储卷（PVC），Pod 重建后仍能挂载原存储卷，数据不丢失；
- 有序的、优雅的部署和缩放：按 Pod 的 ID 顺序（0→1→2…）依次创建 / 扩容，按逆序（2→1→0…）依次删除 / 缩容，确保应用集群的启动顺序符合依赖要求；
- 有序的、自动的滚动更新：按 ID 顺序依次更新 Pod，避免全量更新导致的集群不可用，适用于主从架构、集群架构的应用（如 MySQL 主从、Redis 集群、ZooKeeper 集群）。
13. 说明 Job 与 CronJob 的功能
Job 和 CronJob 均为 K8s 中用于管理一次性 / 周期性任务的控制器，适用于非长期运行的批处理任务，与管理常驻服务的 Deployment、DaemonSet 形成互补。
Job 功能
用于管理一次性批处理作业，核心关注任务是否成功结束（容器退出码为 0），不要求容器长期运行。
- 当 Job 创建的 Pod 全部正常终止（Succeeded），则 Job 完成；
- 若 Pod 执行失败，可通过配置
backoffLimit设置重试次数； - 支持并行执行多个 Pod（通过
parallelism配置并行数）。
典型使用场景：海量日志分析 / 清理、集群初始化操作、数据批量导入 / 导出、一次性计算任务。
CronJob 功能
基于时间调度规则的 Job 升级版，用于管理周期性、定时执行的批处理作业，本质是按时间规则自动创建并执行 Job。
- 通过Cron 表达式定义调度规则（分时日月周），如每天凌晨 1 点执行、每小时执行一次；
- 支持配置任务的超时时间、并发策略（是否允许任务并行执行）、历史任务保留数；
- 若某次调度的任务未执行（如节点故障），可配置是否补执行。
典型使用场景：数据库定时备份、日志定时清理、业务报表定时生成、集群定时运维检查、跨集群数据定时同步。
结语：以上 13 个概念是 K8s 入门的核心基础，理解这些概念能为后续学习服务发现、持久化存储、集群调度、监控运维等内容打下坚实基础。后续会持续更新 K8s 进阶知识点，欢迎关注～
本文地址：https://www.vps345.com/25438.html
