一、ConfigMap

ConfigMap 是 Kubernetes 中的核心 API 对象，本质上是一种配置注入机制，核心作用是将应用的配置数据与容器镜像分离，实现“配置与代码解耦”。

在容器化应用中，若将配置直接写死在镜像里，每次修改配置都需要重新构建镜像、重新部署，不仅繁琐，还会降低镜像的可移植性。而 ConfigMap 可以将配置数据（如配置文件、环境变量、命令行参数等）单独存储，再通过多种方式注入到 Pod 内部，让应用直接使用。

简单来说，ConfigMap 就像一个“配置文件仓库”，让应用镜像保持“纯净”，配置修改可独立完成，大幅提升部署效率和可维护性。

二、Secret vs ConfigMap

Secret 和 ConfigMap 功能相似，都是用于存储应用配置并注入 Pod，但 Secret 专为敏感配置（如密码、Token、密钥等）设计，相比 ConfigMap 有两个核心优势，具体对比如下：

对比维度	ConfigMap	Secret
存储方式	明文存储（写入 etcd 时不加密）	默认 Base64 编码存储，可进一步加密后写入 etcd，避免裸数据泄露
访问控制	常规访问控制，无特殊精细化限制	支持 RBAC 角色权限控制，可精细化限制访问主体（非授权的 ServiceAccount、用户、Pod 无法访问）
适用场景	非敏感配置（如应用端口、日志级别、配置参数等）	敏感配置（如数据库密码、API Token、SSL 证书等）

注意：Base64 编码并非加密，只是编码转换，若需更高安全性，需结合 K8s 加密机制（如静态加密、外部密钥管理工具）对 Secret 进一步加密。

三、ResourceQuota

ResourceQuota（资源配额）是 K8s 中用于限制命名空间资源消耗的 API 对象，核心作用是为每个命名空间设置“资源使用上限”，避免单个命名空间过度消耗集群资源，导致其他命名空间应用不可用。

ResourceQuota 主要能限制两类资源：

1. 对象数量限制：限制命名空间中某类 K8s 对象的总数（如 Pod、Deployment、Service 的最大数量）；

2. 计算资源限制：限制命名空间中所有 Pod 可使用的计算资源总上限（如 CPU、内存的总用量）。

适用场景：多团队共享一个 K8s 集群时，通过 ResourceQuota 为每个团队的命名空间分配资源，实现资源隔离和公平使用。

四、Service Account

Service Account（服务账户）是为 Pod 内部的进程设计的“身份标识”，核心用途是方便 Pod 中的应用调用 Kubernetes API 或其他外部服务，实现 Pod 与集群组件的安全通信。

Service Account 的核心特性的如下：

1. 默认创建：每个命名空间都会自动创建一个default Service Account，若创建 Pod 时未指定 Service Account，Pod 会自动使用该命名空间的 default 账户；

2. 自动挂载凭证：Pod 启动后，K8s 会在 Pod 的 /var/run/secrets/kubernetes.io/serviceaccount/ 路径下，挂载该 Service Account 的 Token（身份凭证）和 CA 证书（用于验证 API Server 身份）；

3. Token 管理：Token Controller（令牌控制器）会监听 Service Account 的创建，自动为其创建 Secret（存储 Token），并维护 Token 与 API Server 的交互权限。

简单来说，Service Account 就是 Pod 的“身份证”，让 API Server 能识别 Pod 的身份，从而控制 Pod 对集群资源的访问权限。

五、Role vs ClusterRole

在 K8s 的 RBAC（基于角色的访问控制）机制中，Role 和 ClusterRole 是两个核心角色对象，用于定义“哪些操作被允许”，所有权限规则都是纯粹累加的（不存在“拒绝某操作”的规则），两者的核心区别在于作用域不同，具体对比如下：

特性	Role（角色）	ClusterRole（集群角色）
作用域	命名空间级（仅对所属命名空间生效）	集群级（对整个 K8s 集群生效）
创建要求	必须指定所属的命名空间（namespace）	无需指定命名空间，集群全局可见
可控制的资源	仅能控制所属命名空间内的资源（如该命名空间的 Pod、ConfigMap 等）	可控制集群级资源（如 Node）、所有命名空间的资源（如所有命名空间的 Pod），以及非资源对象（如权限验证）
适用场景	控制单个命名空间内的资源访问（如给团队 A 分配其命名空间的 Pod 查看权限）	控制集群全局资源、跨命名空间资源访问（如给管理员分配所有 Node 的管理权限）

补充：Role 和 ClusterRole 本身不直接赋予权限，需通过 RoleBinding（命名空间级绑定）或 ClusterRoleBinding（集群级绑定），将角色与用户、Service Account 绑定，才能让主体获得对应的权限。

六、NetworkPolicy

NetworkPolicy（网络策略）是 K8s 中用于控制 Pod 网络流量的 API 对象，核心作用是在 IP 地址或端口层面，限制 Pod 与其他网络实体的通信，实现 Pod 级别的网络隔离。

NetworkPolicy 的核心特性如下：

1. 应用中心型：以 Pod 为核心，只对与 Pod 相关的连接生效（一端或两端是 Pod），不影响非 Pod 之间的通信；

2. 流量控制维度：可通过“允许的 Pod、允许的命名空间、IP 组块”组合，控制 Pod 的入站（Ingress）和出站（Egress）流量；

3. 策略累加性：多个 NetworkPolicy 对同一个 Pod 生效时，不会产生冲突，Pod 允许的流量是所有策略允许范围的合集；

4. 隔离触发条件：Pod 本身是非隔离的（接受所有流量），只有当某个 NetworkPolicy 选中该 Pod 时，Pod 才会进入隔离状态，拒绝该策略未允许的流量。

七、跨 Namespace 的 Pod 访问控制

K8s 中，Pod 的访问控制核心依赖 NetworkPolicy，默认情况下，所有命名空间的 Pod 都是非隔离的，可相互访问；若需控制跨命名空间的 Pod 访问，需通过以下方式实现：

1. Pod 隔离触发：为目标 Pod（被访问方）创建 NetworkPolicy，通过 podSelector 选中该 Pod，此时 Pod 进入隔离状态，仅允许策略中明确放行的流量；

2. 跨命名空间放行：在 NetworkPolicy 的ingress.from（入站放行）中，通过 namespaceSelector 指定允许访问的命名空间（如放行“prod”命名空间的所有 Pod），或通过 podSelector + namespaceSelector 精准放行某个命名空间下的特定 Pod；

3. 权限兜底：若未在 NetworkPolicy 中明确放行某命名空间的 Pod，该命名空间的 Pod 无法访问目标 Pod；若需放行所有命名空间的 Pod，可在策略中不限制 namespaceSelector。

总结：跨命名空间 Pod 访问的核心是“通过 NetworkPolicy 选中目标 Pod，再精准放行来源命名空间/Pod”，实现命名空间间的网络隔离。

八、K8s 常规维护管理操作：

1. 查看 Pod 详情（含事件排查）：kubectl describe pod frontend（可通过输出末尾的 Events 查看 Pod 启动、运行中的异常事件）；

2. 查看 Pod 日志（排查应用异常）：kubectl logs frontend（可加 -f 参数实时跟踪日志，--previous 参数查看上一次启动的日志）；

3. 查看 Pod 资源用量：kubectl top pod frontend（需部署 metrics-server 组件，用于采集资源用量数据）；

4. 查看节点资源用量：kubectl top nodes（查看所有节点的 CPU、内存使用率，判断节点负载）；

5. 禁止 Pod 调度到节点（节点维护前操作）：kubectl cordon host1（标记节点为“不可调度”，已运行的 Pod 不受影响）；

6. 驱逐节点上的现有 Pod（节点维护）：kubectl drain master --ignore-daemonsets（驱逐节点上所有可迁移的 Pod，--ignore-daemonsets 忽略 DaemonSet 管理的 Pod，因其必须运行在所有节点上）。

九、K8s 版本升级：步骤+注意事项

K8s 版本升级需遵循“先控制平面（Master 节点），后数据平面（Node 节点）”的原则，避免集群异常，具体步骤和注意事项如下：

1. 升级核心步骤

1. 确定升级版本：确认目标版本（如 v1.28.0），确保版本间兼容（建议升级相邻小版本，不跨大版本）；

2. 禁止 Master 节点调度：kubectl cordon master，防止升级过程中 new Pod 调度到 Master 节点；

3. 驱逐 Master 节点现有 Pod：kubectl drain master --ignore-daemonsets，确保 Master 节点无运行中的业务 Pod；

4. 升级 kubeadm：在 Master 节点安装目标版本的 kubeadm（如 apt install kubeadm=1.28.0-00）；

5. 升级集群控制平面：kubeadm upgrade plan 查看可升级版本，确认无误后执行kubeadm upgrade apply v1.28.0；

6. 升级 kubelet 和 kubectl：在 Master 节点安装目标版本的 kubelet 和 kubectl（如 apt install kubelet=1.28.0-00 kubectl=1.28.0-00），重启 kubelet 服务（systemctl restart kubelet）；

7. 恢复 Master 节点调度：kubectl uncordon master，允许 Pod 重新调度到 Master 节点；

8. 重复步骤 2-7，依次升级所有 Node 节点（若集群有多个 Node）。

2. 升级注意事项

• 版本兼容：确认目标版本与集群中组件（如 Calico、metrics-server、Ingress Controller）兼容，避免组件不兼容导致集群异常；

• 数据备份：升级前备份 etcd 数据（集群核心数据存储），若升级失败可回滚；

• 锁版本：升级完成后，执行 apt-mark hold kubeadm kubelet kubectl 锁定版本，防止误升级；

• 分批升级：多 Node 集群建议分批升级 Node 节点，避免所有 Node 同时升级导致业务中断；

• 验证集群状态：升级完成后，执行 kubectl get nodes 查看所有节点状态（Ready），kubectl get pods --all-namespaces 查看核心组件（kube-apiserver、kube-controller-manager 等）运行正常。

十、ETCD

ETCD 是分布式键值存储系统，是 K8s 集群的核心数据存储组件，集群中所有关键数据（如 Pod 配置、Service 定义、RBAC 权限、Secret 等）都存储在 ETCD 中，相当于 K8s 集群的“大脑”。

ETCD 的稳定性直接决定集群的稳定性，因此日常运维中必须做好 ETCD 的备份与恢复操作。

1. ETCD 备份过程（核心操作）

1. 配置环境变量与连接参数：声明 ETCD 相关环境变量（如 ETCD endpoints、证书路径），让 etcdctl（ETCD 命令行工具）能合法、安全地连接到集群的 ETCD 服务； 示例（单节点 ETCD）：export ETCDCTL_API=3 ETCD_ENDPOINTS=https://127.0.0.1:2379 ETCD_CERT_FILE=/etc/kubernetes/pki/etcd/server.crt ETCD_KEY_FILE=/etc/kubernetes/pki/etcd/server.key ETCD_CA_FILE=/etc/kubernetes/pki/etcd/ca.crt

2. 执行备份操作：使用 etcdctl snapshot save 命令生成快照文件，指定备份路径和文件名； 示例：etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

3. 验证备份有效性：使用 etcdctl snapshot status 命令检查备份文件是否完整、可用； 示例：etcdctl snapshot status /backup/etcd-snapshot-20260203.db

2. ETCD 恢复过程（故障应急）

当 ETCD 数据损坏、丢失，或集群升级失败时，需通过备份文件恢复 ETCD，步骤如下：

1. 停止 kubelet 服务：ETCD 恢复期间，需停止 kubelet（避免 kubelet 频繁与 ETCD、API Server 交互）； 示例：systemctl stop kubelet

2. 停止 ETCD 服务：若 ETCD 是静态 Pod 部署（默认），需删除 ETCD 静态 Pod 配置，让其停止运行； 示例：rm -f /etc/kubernetes/manifests/etcd.yaml

3. 执行恢复操作：使用 etcdctl snapshot restore 命令，指定备份文件、ETCD 数据目录、集群名称等参数，恢复数据； 示例：etcdctl snapshot restore /backup/etcd-snapshot-20260203.db --data-dir=/var/lib/etcd-restore --name=master --initial-cluster=master=https://127.0.0.1:2380 --initial-cluster-token=etcd-cluster-token --initial-advertise-peer-urls=https://127.0.0.1:2380

4. 修改 ETCD 数据目录：将恢复后的 data-dir 替换原有 ETCD 数据目录（默认 /var/lib/etcd）； 示例：mv /var/lib/etcd /var/lib/etcd.bak && mv /var/lib/etcd-restore /var/lib/etcd

5. 重启 ETCD 和 kubelet：恢复 ETCD 静态 Pod 配置，重启 kubelet 服务； 示例：cp /etc/kubernetes/manifests/etcd.yaml.bak /etc/kubernetes/manifests/etcd.yaml && systemctl start kubelet

6. 验证恢复结果：检查 ETCD 健康状态（etcdctl endpoint health），查看集群核心组件是否正常运行。

十一、Kustomization

Kustomization 是 K8s 内置的配置管理工具，核心作用是通过“声明式”方式，对 K8s 资源配置文件进行定制、组合和复用，解决“多环境配置差异化”的问题（如开发、测试、生产环境的配置差异）。

Kustomize 的核心工作流程基于两个核心概念：

1. Bases（基准配置）：定义应用的基础配置（如 Deployment、Service 的通用配置），是所有环境的共用配置，无需修改；

2. Overlays（叠加配置）：针对不同环境（如 dev、prod），创建叠加配置，通过“补丁（Patch）”“生成器（Generator）”等方式，修改、补充基准配置（如修改生产环境的 Pod 副本数、调整资源限制）。

优势：无需修改基准配置文件，仅通过叠加配置实现多环境差异化，配置复用率高，且能清晰区分不同环境的配置差异，降低维护成本。

十二、CRD

CRD（Custom Resource Definition，自定义资源定义）是 K8s 中用于扩展 API 的核心机制，允许用户根据自身业务需求，创建自定义的资源类型（如 MyDatabase、MyWorkflow），就像使用 K8s 内置资源（Pod、Deployment）一样，通过 kubectl 命令进行创建、查看、删除等操作。

CRD 的重要意义

• 打破内置资源限制：K8s 内置资源无法满足所有业务场景（如数据库管理、机器学习工作流），CRD 允许用户扩展资源类型，适配自身业务；

• 统一管理界面：将复杂的业务配置封装为自定义资源，通过 K8s 原生方式管理，无需额外搭建管理平台；

• 实现自动化运维：结合 Operator（控制器），可监听自定义资源的状态变化，实现业务的全生命周期自动化管理（如创建自定义资源自动部署数据库、删除自定义资源自动清理环境）；

• 提升可扩展性：让 K8s 从“容器编排平台”升级为“通用的分布式系统管理平台”，适配更多行业场景（如金融、医疗、AI）。

十三、CRD 典型应用场景（附实例）

CRD 的核心价值是“适配自定义业务场景”，以下是最常见的 5 个应用场景，结合实例说明：

1. 机器学习工作流管理：创建自定义资源 TrainingJob，用于定义机器学习训练任务的配置（如镜像、数据路径、迭代次数），结合 Operator 自动启动训练 Pod、监控训练进度、保存训练结果；

2. CI/CD 流水线定义：创建自定义资源 CiPipeline，封装流水线的步骤（如代码拉取、构建、测试、部署），通过 Operator 自动执行流水线，实现 CI/CD 流程的标准化；

3. 数据库即服务（DBaaS）：创建自定义资源 MySQLInstance，定义数据库的规格（如版本、存储大小、副本数），Operator 监听该资源，自动部署 MySQL 集群、配置主从复制、实现故障自愈；

4. 自定义中间件管理：创建自定义资源 RabbitMQCluster，用于管理 RabbitMQ 集群，通过 Operator 实现集群的部署、扩容、缩容、备份等操作；

5. 特定领域应用管理：如金融行业的“交易任务”、医疗行业的“数据采集任务”，可通过 CRD 定义自定义资源，结合 Operator 实现任务的自动化调度和管理。

十四、CRD 完整创建和使用过程（附实操逻辑）

CRD 的使用分为“定义 CRD → 创建 CR → 管理/自动化 CR”三个步骤，全程基于 YAML 配置和 kubectl 命令，具体过程如下：

1. 定义并创建 CRD（注册自定义资源类型）

编写 CRD YAML 文件，核心指定以下参数，定义自定义资源的“规则”：

• group（组）：自定义资源的 API 组（如 example.com），用于区分不同的自定义资源；

• versions（版本）：自定义资源的 API 版本（如 v1），支持版本迭代；

• names（名称）：自定义资源的名称（单数、复数、简称），如单数 mydatabase、复数 mydatabases、简称 mdb；

• scope（作用域）：命名空间级（Namespaced）或集群级（Cluster）；

• openAPIV3Schema（字段结构）：定义自定义资源的字段（如 spec.image、spec.storage）、类型和校验规则。

编写完成后，执行 kubectl apply -f crd.yaml，K8s 会注册该自定义资源类型，此时可通过 kubectl api-resources 查看已注册的自定义资源。

2. 创建自定义资源（CR，实例化 CRD）

CR 是 CRD 的“实例”，基于已注册的 CRD，编写 CR YAML 文件，设置自定义字段的值（如数据库镜像、存储大小），示例如下：

执行 kubectl apply -f mydatabase-cr.yaml，即可创建 CR 实例，创建完成后，可通过 kubectl get mdb（mdb 是 CRD 的简称）查看实例状态，通过 kubectl describe mdb mydb-test 查看详情，与操作内置资源完全一致。

3. 管理/自动化 CR（全生命周期管控）

• 基础管理：直接通过 kubectl 命令进行编辑（kubectl edit mdb mydb-test）、删除（kubectl delete mdb mydb-test）等操作；

• 自动化管理（核心）：若需实现“创建 CR 自动部署数据库”“修改 CR 自动调整规格”等自动化操作，需开发 Operator（控制器）。Operator 会持续监听 CR 的状态变化，对比“期望状态”（CR 中定义的 spec）和“实际状态”，自动执行相关操作，实现 CR 的全生命周期管理。