【专题05】Kubernetes面试题（50题）
核心概念（15题）
1、K8s架构和组件
Kubernetes (通常简称为 K8s) 是一个开源的容器编排引擎，用于自动化部署、扩展和管理容器化应用程序。
K8s 采用主从架构 (Master-Worker Architecture)，整个集群主要由两部分组成：
控制平面 (Control Plane)：也就是 Master 节点，负责整个集群的管理和决策（“大脑”）。
工作节点 (Worker Node)：负责运行实际的应用容器（“手脚”）。
以下是详细的架构图解与组件说明：
一、 控制平面 (Control Plane / Master)
控制平面负责维护集群的期望状态（Desired State），如运行什么应用、使用多少副本等。
1. kube-apiserver (API 服务器)
角色：集群的统一入口和中心枢纽。
功能：
提供 RESTful API 接口，供用户（kubectl）、UI、其他组件进行通信。
所有组件之间的通信都必须通过 API Server，组件之间不直接通信。
负责认证（Authentication）、授权（Authorization）和准入控制（Admission Control）。
只有它能直接与 etcd 数据库交互。
2. etcd (存储系统)
角色：集群的数据库（Source of Truth）。
功能：
一个高可用的分布式键值（Key-Value）存储系统。
保存集群所有的配置信息、状态数据和元数据。
注意：etcd 是 K8s 中唯一有状态的组件，必须做好备份。
3. kube-scheduler (调度器)
角色：负责资源的调度分配。
功能：
监听新创建的 Pod（尚未分配节点）。
根据预选策略（Filtering，如资源是否足够）和优选策略（Scoring，如负载均衡、亲和性），选择一个最合适的 Node 节点。
将 Pod 绑定到选定的 Node 上。
4. kube-controller-manager (控制器管理器)
角色：负责集群的状态维护（自动驾驶）。
功能：
内部包含多个控制器（如 Node Controller, ReplicaSet Controller, Endpoint Controller 等）。
核心逻辑：通过控制循环（Reconciliation Loop）不断比较当前状态（Current State）和期望状态（Desired State）。如果状态不一致，它会尝试进行修正（例如：如果一个 Pod 挂了，ReplicaSet 控制器会请求创建一个新的）。
5. cloud-controller-manager (云控制器管理器 - 可选)
角色：与云服务提供商（AWS, Azure, GCP, Aliyun等）交互的接口。
功能：如果你在云上运行 K8s，它负责管理云资源，如创建云负载均衡器（Load Balancer）、管理云硬盘存储卷等。
二、 工作节点 (Worker Node)
工作节点受 Master 管理，负责实际运行容器负载。
1. kubelet
角色：节点上的代理人/管家。
功能：
主要负责维护Pod 的生命周期。
接收 API Server 发来的指令（PodSpec），调用容器运行时（Runtime）来启动、停止容器。
定期向 Master 汇报节点资源使用情况和健康状态。
执行健康检查（Liveness/Readiness Probes）。
2. kube-proxy
角色：负责网络通信和负载均衡。
功能：
维护节点上的网络规则（通常使用 iptables 或 IPVS）。
实现 Service 的概念，将发往 Service 的流量转发到后端的具体 Pod 上。
处理集群内部和外部的网络访问。
3. Container Runtime (容器运行时)
角色：真正运行容器的软件。
功能：
负责拉取镜像、创建和运行容器。
K8s 通过CRI(Container Runtime Interface) 接口与运行时交互。
常见实现：containerd,CRI-O, Docker Engine (旧版本)。
三、 关键插件 (Add-ons)
虽然不属于核心二进制文件，但对集群正常工作至关重要。
CoreDNS：
负责集群内的 DNS 解析。让 Pod 可以通过服务名（Service Name）而不是 IP 地址访问其他服务。
CNI 插件 (Container Network Interface)：
负责配置 Pod 的网络接口，分配 IP 地址，实现 Pod 互通。
常见插件：Calico, Flannel, Cilium。
Ingress Controller：
管理集群外部访问集群内部 HTTP/HTTPS 服务的规则（如 Nginx Ingress）。
Dashboard / Monitoring：
如 Kubernetes Dashboard（UI 界面）或 Prometheus + Grafana（监控）。
四、 总结与协作流程 (举例：创建一个 Pod)
为了串联这些组件，假设你执行命令 kubectl run nginx --image=nginx：
kubectl将请求发送给API Server。
API Server验证请求并将数据存入etcd。
Scheduler发现有一个新 Pod 没地儿去，经过计算，决定把它调度到 Node-A，并将结果告知API Server（更新 etcd）。
Node-A 上的kubelet监听到自己被分配了任务。
kubelet指挥Container Runtime(如 containerd) 拉取 Nginx 镜像并启动容器。
kubelet将 Pod 运行状态汇报给API Server。
kube-proxy设置网络规则，确保如果创建了 Service，流量能找到这个 Pod。
简单类比
Master=总指挥部
API Server = 接待员/传令兵
etcd = 档案室
Scheduler = 人力资源/排班经理
Controller Manager = 督查员（确保持续合规）
Worker Node=干活的工人
Kubelet = 工头（接任务，管工人）
Runtime = 具体的工人（搬砖）
Kube-proxy = 交通指挥（管路）
2、Pod生命周期
Pod 的生命周期（Lifecycle）是指一个 Pod 从被创建、调度、运行，直到最后终止（完成或失败）的全过程。
理解 Pod 生命周期对于故障排查（为什么 Pod 处于 Pending？为什么一直 Restart？）和应用配置（如何优雅停机？如何做健康检查？）至关重要。
以下是 Pod 生命周期的核心内容详解：
一、 Pod 的五大核心阶段 (Phase)
当你执行 kubectl get pods 时，STATUS 列显示的就是 Pod 的当前阶段（Phase）。
阶段 (Phase)
含义
常见原因
Pending (挂起)
Pod 已被 API Server 接受，但尚未被调度到节点，或镜像正在下载中。
资源不足、污点(Taint)不匹配、镜像拉取慢、PVC 未绑定。
Running (运行中)
Pod 已绑定到节点，所有容器已创建。至少有一个容器正在运行、启动或重启。
正常工作状态。
Succeeded (成功)
Pod 中的所有容器都已成功终止（退出码为 0），且不会再重启。
Job 任务执行完成。
Failed (失败)
所有容器都已终止，但至少有一个容器是以失败状态（非 0 退出码）退出的。
程序崩溃、配置错误。
Unknown (未知)
Master 无法获取 Pod 的状态。
通常是 Node 节点与 Master 网络断连，或 Node 宕机。
二、 Pod 生命周期的详细流程
一个 Pod 从生到死，通常经历以下详细步骤：
1. 初始化容器 (Init Containers)
什么是它：在主应用容器启动之前运行的容器。
特点：
总是串行执行（运行完一个才运行下一个）。
必须成功退出（Exit 0），否则 Pod 会卡住或重启。
用途：等待数据库 Ready、下载配置文件、注册服务中心等。
2. 主容器启动与钩子 (Hooks)
一旦 Init Containers 全部成功，主容器（Main Containers）开始并行启动。
PostStart Hook：
容器创建后立即执行。
注意：它和容器 ENTRYPOINT 是异步的，无法保证先后顺序。如果 Hook 失败，容器会被杀死。
3. 健康检查 (Probes) - 非常重要
K8s 通过探针（Probes）来感知容器的状态。
Startup Probe (启动探针)：
问：“应用程序启动了吗？”
作用：主要用于启动慢的遗留应用。如果配置了它，在它成功之前，其他探针都会被禁用。如果失败，容器被重启。
Liveness Probe (存活探针)：
问：“你还活着吗？”
作用：检测程序是否死锁或崩溃。如果检测失败，K8s 会重启该容器。
Readiness Probe (就绪探针)：
问：“可以给你发流量了吗？”
作用：检测应用是否准备好处理请求。如果检测失败，K8s 会将该 Pod 的 IP 从 Service 的后端列表中摘除（不重启容器，只是切断流量）。
4. 终止过程 (Termination)
当用户删除 Pod 时，K8s 会追求“优雅停机”：
设置状态：Pod 被标记为 Terminating 状态。
切断流量：Endpoint 控制器将 Pod 从 Service 的列表中移除。
执行 PreStop Hook：如果配置了 preStop（如 sleep 10 或发送清理脚本），会先执行它。这是应用做“临终遗言”的机会。
发送 SIGTERM 信号：K8s 向容器主进程（PID 1）发送 SIGTERM 信号，通知应用“请尽快保存数据并退出”。
宽限期 (Grace Period)：默认 30 秒。K8s 等待容器自行退出。
发送 SIGKILL 信号：如果宽限期过了容器还没停，K8s 会发送 SIGKILL 强制杀死进程。
三、 重启策略 (RestartPolicy)
Pod 的 spec.restartPolicy 决定了当容器退出时，K8s 怎么处理。
Always (默认)：无论容器是正常退出还是失败退出，kubelet 都会自动重启它。（适用于 Deployments, StatefulSets）。
OnFailure：只有当容器以非 0 状态码（失败）退出时，才重启。（适用于 CronJob, Job）。
Never：不管怎样都不重启。（适用于一次性任务，失败了就失败了）。
四、 容器状态 (Container States)
除了 Pod 的 Phase，Pod 内部的容器也有自己的状态，可以通过 kubectl describe pod 查看：
Waiting：容器正在初始化。
常见原因：ImagePullBackOff（镜像拉取失败）、CrashLoopBackOff（启动就挂，一直重启）。
Running：容器正在正常运行。
Terminated：容器已经执行完并退出。
会记录 Exit Code（0代表正常，1/137/255等代表错误）。
五、 常见故障排查图解
了解生命周期后，看错误状态就能秒懂：
ImagePullBackOff / ErrImagePull:
阶段：Waiting
原因：镜像名错了、镜像仓库认证失败、网络不通。
CrashLoopBackOff:
阶段：Running -> Terminated -> Waiting (循环)
原因：应用程序代码报错、缺环境变量、Liveness 探针失败导致无限重启。
Pod 一直 Pending:
原因：集群资源不足（CPU/内存不够）、没有满足调度条件的 Node。
Pod 一直 Terminating:
原因：PreStop 脚本卡死、节点磁盘挂载无法卸载、Finalizers 阻止删除。
总结
Pod 的一生可以用这句顺口溜概括：
"调度挂起(Pending) -> 初始化(Init) -> 启动(Start) -> 探针检测(Probes) -> 提供服务(Ready) -> 优雅退出(Terminating)"
3、Deployment/ReplicaSet/StatefulSet/DaemonSet区别
在 Kubernetes (K8s) 面试中，这四个资源对象（Workload Resources）是核心考点。它们都是为了管理 Pod 而设计的，但针对的应用场景截然不同。
以下是针对面试整理的详细对比和核心差异：
1. 核心定义与职责
ReplicaSet (RS)
职责：确保在任何时间点，集群中都有指定数量的 Pod 副本在运行。
面试重点：它主要通过 selector 监控 Pod 状态。它并不直接处理“发布”或“更新”的高级逻辑。现在很少直接创建 RS，而是通过 Deployment 来管理。
Deployment
职责：为 Pod 和 ReplicaSet 提供声明式的更新能力。
面试重点：它是最常用的对象，用于无状态服务（Stateless）。
支持**滚动更新（Rolling Update）**和回滚（Rollback）。
管理的是 ReplicaSet，每更新一次版本，都会创建一个新的 RS。
StatefulSet (STS)
职责：用于管理有状态服务（Stateful）。
面试重点：它给 Pod 提供了稳定的标识（名字、网络、存储）。
Pod 名字是固定的（如 web-0, web-1），不会像 Deployment 那样随机生成哈希后缀。
支持稳定的持久化存储（每个 Pod 绑定一个独立的 PV/PVC）。
DaemonSet (DS)
职责：确保在每一个（或指定的）Node上都运行一个 Pod 副本。
面试重点：当有新节点加入集群时，DS 会自动在该节点创建 Pod；当节点被移除，Pod 也会被回收。常用于基础设施类服务。
2. 深度对比（面试核心差异表）
特性
Deployment
StatefulSet
DaemonSet
应用类型
无状态（Web应用、API）
有状态（数据库、Redis、ZK）
守护进程（日志、监控、网络）
Pod 名称
随机哈希后缀（如 web-abcd-123）
固定索引后缀（如 web-0, web-1）
随机或固定（通常不关注）
启动/删除顺序
并行，无序
有序（0到N-1启动，N-1到0删除）
随节点加入/退出而定
网络标识
不固定，Pod 重启后 IP 变化
固定，通过 Headless Service 生成固定 DNS
不固定
存储
共享存储或临时存储
独立存储（每个 Pod 都有自己的磁盘）
通常挂载宿主机路径（HostPath）
副本数
用户指定（replicas: N）
用户指定（replicas: N）
自动匹配节点数（除非设置 nodeSelector）
3. 面试常见问题 (FAQ)
Q1: 为什么有了 ReplicaSet 还要 Deployment？
回答：ReplicaSet 只负责维护副本数量，不支持“版本管理”。Deployment 是更高级的控制器，它通过管理多个 RS 来实现滚动更新（创建新 RS，逐步增加副本；旧 RS 逐步减少副本）和一键回滚（保存了 RS 的历史版本）。
Q2: StatefulSet 的“稳定标识”体现在哪里？
回答：
主机名（Hostname）：Pod 重启后名字不变。
DNS 域名：配合 Headless Service，可以通过 pod-name.svc-name 访问特定分片，这对集群选主（如 Zookeeper/ETCD）至关重要。
存储绑定：Pod 即使漂移到其他节点，依然能挂载回原来那个确定的 PersistentVolume（PV）。
Q3: DaemonSet 的典型使用场景有哪些？
回答：
日志收集：如 Fluentd 或 Logstash 在每台机器收集日志。
监控 Agent：如 Prometheus Node Exporter 监控机器性能。
网络插件：如 Calico 或 Flannel 的守护进程。
Q4: 如果在 StatefulSet 中删除了一个 Pod，会发生什么？
回答：控制器会自动创建一个同名的新 Pod，并尝试挂载原本属于该索引（Index）的 PVC。这保证了数据的连续性。
Q5: 怎么控制 DaemonSet 只在特定的节点上运行？
回答：通过 nodeSelector 或 nodeAffinity（节点亲和性）。此外，DaemonSet 也会尊重节点的 Taints（污点），除非 Pod 设置了相应的 Tolerations（容忍度）。
4. 总结建议（背诵口诀）
Deployment：起无状态 Web，要滚动更新，它是最常用的。
StatefulSet：起数据库/中间件，要有序、有固定名字、有独立磁盘。
DaemonSet：搞基建，一节点一个，日志监控少不了。
ReplicaSet：底层劳力，Deployment 的小弟，一般不直接碰。
3、Service类型
在 Kubernetes 面试中，Service (Svc)是解决 Pod “易失性”（IP 经常变）和“负载均衡”的核心组件。面试官通常会考察你对不同 Service 类型的理解以及它们各自的应用场景。
以下是针对面试整理的 Kubernetes Service 类型详解：
1. 四种核心 Service 类型
ClusterIP (默认类型)
定义：在集群内部自动分配一个虚拟 IP（VIP）。
可见性：仅集群内部可见。外部无法直接访问。
场景：微服务之间的内部调用。例如：前端 Pod 访问后端 API Pod。
面试点：它是最常用的类型。如果不指定 type，默认就是它。
NodePort
定义：在**每个 Node（节点）**上开放一个静态端口（默认范围：30000-32767）。
访问方式：通过任意 NodeIP:NodePort 访问。
原理：NodePort 会在底层自动创建一个 ClusterIP。流量流程：外部请求 -> NodeIP:NodePort -> Service (ClusterIP) -> Pod。
场景：测试环境、没有云厂商负载均衡器时简单暴露服务。
LoadBalancer
定义：使用云提供商（如 AWS、阿里云、GCP）的负载均衡器。
访问方式：云厂商会分配一个外部公网 IP。
原理：它是 NodePort 的增强版。它会自动创建 NodePort 和 ClusterIP。
场景：生产环境直接面向公网流量的入口。
ExternalName
定义：将 Service 映射到一个外部域名（通过 CNAME 记录）。
特殊性：它不涉及选择器（Selector），也不转发流量，只在 DNS 层做跳转。[2]
场景：在集群内访问集群外的数据库（如 RDS 域名）或第三方服务，方便统一配置。
2. 特殊形态：Headless Service (无头服务)
这也是面试的高频加分项：
如何定义：设置 clusterIP: None。[5]
特点：K8s 不会为它分配 VIP。当你解析该 Service 的 DNS 时，返回的是后端所有 Pod 的具体 IP 列表，而不是一个统一的 VIP。
应用场景：StatefulSet必备。用于有状态服务（如数据库集群），需要直接与特定的 Pod 节点通信，或者由客户端自己实现负载均衡。
3. Service 的核心机制（底层原理）
面试官可能会追问：“Service 是如何实现负载均衡的？”
kube-proxy：每台节点上运行的组件，负责维护网络规则。
转发模式：
IPtables 模式（最常用）：利用 Linux 内核的 Netfilter 实现。性能较好，但规则多时（数千个服务）会变慢。
IPVS 模式：基于内核 IPVS。在大规模集群下性能更高，支持更多的负载均衡算法（如最少连接）。
Endpoints & EndpointSlice：
Service 通过Selector找到 Pod。
符合条件的 Pod IP 会记录在Endpoints对象中。
在 1.21+ 版本后，EndpointSlice解决了 Endpoints 对象过大导致的性能性能瓶颈。
4. 常见面试对比：Service vs Ingress
这是最容易混淆的一点：
Service (L4)：工作在传输层（TCP/UDP）。它只能基于 IP 和端口转发。如果要暴露 100 个服务，LoadBalancer 类型需要 100 个外网 IP。
Ingress (L7)：工作在应用层（HTTP/HTTPS）。它像一个“智能网关”，可以根据域名和路径（Path）转发流量到不同的 Service。
比喻：Service 是房间的门牌号，Ingress 是大楼的前台。
5. 面试总结表
类型
暴露范围
自动创建
核心用途
ClusterIP
集群内
无
内部微服务通信
NodePort
集群外
ClusterIP
简单暴露、非云环境
LoadBalancer
集群外
NodePort + ClusterIP
生产级公网接入
ExternalName
N/A
无
访问外部域名
Headless
集群内
无 (不分配 IP)
StatefulSet、服务发现
面试话术示例：
“在项目中，我们内部服务调用默认使用ClusterIP保证安全和效率；对于需要对外的 Web 服务，我们通常配合Ingress使用，而 Ingress 的后端通常挂载一个NodePort或ClusterIP类型的 Service。如果是部署 Redis 这种有状态集群，我们会用到Headless Service来获取稳定的 Pod DNS 地址。”
4、ConfigMap/Secret
- Label和Selector
- Namespace
- 资源限制
调度（10题）
1、调度器工作原理
🌟 调度器是啥？
简单说，kube-scheduler就是K8s的"快递小哥"，专门负责把你的Pod（最小部署单元）送到最合适的节点上。它不直接创建Pod，而是"安排"Pod去哪里运行。
📌 为什么Pod会Pending？（调度失败原因）
当Pod处于Pending状态，说明：
Kubernetes已经接受了你的Pod创建请求
但调度器还没找到合适的节点放它
简单说："快递小哥还没找到收货地址"😅
🔍 调度器的"工作流程"（分步图解）
1️⃣ 任务开始：创建Pod
你用kubectl或CI/CD发了个创建Pod的请求
API Server把Pod信息存到etcd（集群的"数据库"）
调度器通过watch机制发现这个"新订单"
2️⃣ 两阶段调度：预选+优选
这是调度器的核心！就像你找房子，先筛掉不符合条件的，再比较哪个最好。
🛠️ 预选阶段（Filtering）：筛掉不合适节点
调度器根据Pod要求（CPU/内存/亲和性/污点等）过滤节点
例如：如果Pod需要GPU，就筛掉没有GPU的节点
这阶段会筛掉不满足条件的节点，剩下"候选名单"
🌟 优选阶段（Scoring）：给节点打分
对剩下的节点进行打分（0-100分）
打分标准包括：资源使用率、亲和性、拓扑分布等
例如：资源使用率低的节点得分更高
3️⃣ 绑定阶段：确定最终位置
选中得分最高的节点
创建"Pod-Node绑定"（把节点信息写进etcd）
节点上的kubelet发现这个Pod，开始拉镜像、启动容器
💡 调度器的"聪明之处"
1️⃣ 调度插件系统（超强大！）
K8s调度器不是"死板"的，它支持插件：
预选插件：过滤节点（如NodeAffinity）
优选插件：给节点打分（如NodeResourcesBalancedAllocation）
甚至可以自定义插件，满足特殊需求！
2️⃣ 1.30版本新特性：AI驱动调度
K8s 1.30引入了AI预测能力：
分析历史数据，预测Pod资源需求
预判节点未来资源变化
适合AI训练等动态资源需求场景
🛠️ 调度器常见问题解决
❓ 为什么Pod一直Pending？
1️⃣资源不足：节点CPU/内存不够
解决：
kubectl top nodes查看资源，或减少Pod请求2️⃣污点问题：节点有污点(taint)，Pod没匹配容忍度(tolerations)
解决：
kubectl describe nodes | grep Taints查看，或添加tolerations3️⃣存储问题：PVC需要特定存储类
解决：
kubectl get storageclass查看，修改PVC配置🔍 诊断Pending状态的"三步法"
kubectl describe pod your-pod-name（关键！）重点看Events部分（通常会告诉你原因）
根据错误信息对症下药（别瞎猜！）
💡 一句话总结
K8s调度器 = 精准匹配系统
它通过"预选→优选→绑定"三步，把Pod送到最适合的节点上，让集群资源利用最大化！下次看到Pod Pending，别慌！先
kubectl describe，看Events，90%的问题都能找到原因
- nodeSelector/nodeAffinity
- 污点和容忍
- Pod亲和性/反亲和性
- 资源配额
- HPA/VPA
- PodDisruptionBudget
8、Kubernetes中Pod的Pending状态
📊 状态流程图
┌─────────────┐
│ Created │ Pod被创建
└──────┬──────┘
▼
┌─────────────┐
│ Pending │ ← 等待调度/资源/条件满足
└──────┬──────┘
▼
┌─────────────┐
│ContainerCreating│ 拉取镜像/创建容器
└──────┬──────┘
▼
┌─────────────┐
│ Running │ 正常运行
└─────────────┘2、🧐 什么是Pending状态？
当你的Pod处于Pending状态时，意味着：
Kubernetes已经接受了你的Pod创建请求
但一个或多个容器还没准备好（还没被调度到节点上运行）
说人话：系统"收下"了你的请求，但还没找到合适的"位置"放它
🔍 常见原因（附解决方案）
1️⃣ 资源不足（最常见！）
📌 现象：节点CPU/内存不够用
- 💡 解决：检查资源使用情况
1kubectl top nodes # 查看节点资源使用 2kubectl describe node <node-name> # 查看节点详细资源💡 临时方案：减少Pod的资源请求
2️⃣ 节点污点问题（超常见！）
📌 现象：节点有污点(taint)，但Pod不匹配容忍度(tolerations)
- 💡 解决：
1kubectl describe nodes | grep Taints # 查看节点污点 2kubectl taint nodes node-name key=value:Effect- # 删除污点3️⃣ 镜像问题
📌 现象：镜像拉取失败（地址错误/需要认证）
💡 解决：检查镜像名称、仓库权限
4️⃣ 存储问题（PVC Pending）
📌 现象：PersistentVolumeClaim一直Pending
- 💡 解决：
1kubectl get storageclass # 查看可用存储类 2kubectl patch pvc pvc-name -p '{"spec":{"storageClassName":"new-storage-class"}}' # 更改存储类🛠️ 诊断Pending状态的三步法
1️⃣查看Pod详情（关键！）
1kubectl describe pod your-pod-name -n your-namespace2️⃣重点看Events部分（通常会告诉你原因）
1Events: 2 Type Reason Age From Message 3 ---- ------ ---- ---- ------- 4 Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 3 Insufficient cpu.3️⃣根据错误信息对症下药（别瞎猜！）
💡 举个真实案例
上周我朋友的Nacos部署PVC一直Pending，原因很简单：
他用的是默认的存储类，但集群里没有这个存储类
解决方案：
kubectl get storageclass看到有standard，然后修改PVC配置为storageClassName: standard🌟 一句话总结
Pod Pending = "我找不到地方放你"，不是K8s坏了，而是"你要求太高了/节点没空了/我找不到路了"！
下次遇到Pending，别慌！先
kubectl describe，看Events，90%的问题都能找到原因～
网络（10题）
- Pod网络模型
- Service实现原理
- Ingress Controller
- NetworkPolicy
- DNS服务发现
- 跨集群通信
存储（5题）
- PV/PVC
- StorageClass
- 动态供给
- 常见存储方案
运维（10题）
1、如何删掉一个pod
面试官：怎么删除 k8s 里面一个 pod？
口述版本：
普通删除 Pod 用
kubectl delete pod pod名称 -n 命名空间。这里有个关键点，如果这个 Pod 是 Deployment 管理的，直接删 Pod，控制器会自动拉起新 Pod，实现自愈，Pod 会重建。想要彻底移除服务，需要删除对应的 Deployment 资源。
如果 Pod 卡在 Terminating 状态删不掉，就加上
--grace‑period=0 --force参数强制删除。日常会先用
kubectl get pods -n xxx先查到 pod 名字和命名空间；如果 Pod 异常，会用kubectl describe pod去看事件，排查异常原因。面试延伸追问大概率会问：
Q：为什么我删完 pod，又出来一个新 pod？
口述：因为 Pod 由 Deployment/StatefulSet 这类控制器管理，控制器会维持设定副本数。删除 pod 只是销毁实例，控制器检测副本不够，就重新创建 pod；要彻底移除，需要删除上层 deployment 资源。
Q：pod 一直 Terminating 删不掉，排查思路？
口述：
先用 describe pod 看事件，看是什么原因无法终止；
检查节点状态是否正常，节点是否失联；
可以执行强制删除命令；
如果强制删除还不行，需要去对应节点排查容器、kubelet 服务。
你的岗位是大模型技术支持，不用深挖 k8s 底层原理，记住命令、理解控制器会重建 Pod 这个核心坑点就足够。