核心概念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 DashboardUI 界面或 Prometheus Grafana监控。四、 总结与协作流程 (举例创建一个 Pod)为了串联这些组件假设你执行命令 kubectl run nginx --imagenginxkubectl将请求发送给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 的 PhasePod 内部的容器也有自己的状态可以通过 kubectl describe pod 查看Waiting容器正在初始化。常见原因ImagePullBackOff镜像拉取失败、CrashLoopBackOff启动就挂一直重启。Running容器正在正常运行。Terminated容器已经执行完并退出。会记录 Exit Code0代表正常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. 深度对比面试核心差异表特性DeploymentStatefulSetDaemonSet应用类型无状态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自动匹配节点数除非设置 nodeSelector3. 面试常见问题 (FAQ)Q1: 为什么有了 ReplicaSet 还要 Deployment回答ReplicaSet 只负责维护副本数量不支持“版本管理”。Deployment 是更高级的控制器它通过管理多个 RS 来实现滚动更新创建新 RS逐步增加副本旧 RS 逐步减少副本和一键回滚保存了 RS 的历史版本。Q2: StatefulSet 的“稳定标识”体现在哪里回答主机名HostnamePod 重启后名字不变。DNS 域名配合 Headless Service可以通过 pod-name.svc-name 访问特定分片这对集群选主如 Zookeeper/ETCD至关重要。存储绑定Pod 即使漂移到其他节点依然能挂载回原来那个确定的 PersistentVolumePV。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 (默认类型)定义在集群内部自动分配一个虚拟 IPVIP。可见性仅集群内部可见。外部无法直接访问。场景微服务之间的内部调用。例如前端 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 EndpointSliceService 通过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生产级公网接入ExternalNameN/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一直Pending1️⃣资源不足节点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看Events90%的问题都能找到原因- nodeSelector/nodeAffinity- 污点和容忍- Pod亲和性/反亲和性- 资源配额- HPA/VPA- PodDisruptionBudget8、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 keyvalue: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看Events90%的问题都能找到原因网络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‑period0 --force参数强制删除。日常会先用kubectl get pods -n xxx先查到 pod 名字和命名空间如果 Pod 异常会用kubectl describe pod去看事件排查异常原因。面试延伸追问大概率会问Q为什么我删完 pod又出来一个新 pod口述因为 Pod 由 Deployment/StatefulSet 这类控制器管理控制器会维持设定副本数。删除 pod 只是销毁实例控制器检测副本不够就重新创建 pod要彻底移除需要删除上层 deployment 资源。Qpod 一直 Terminating 删不掉排查思路口述先用 describe pod 看事件看是什么原因无法终止检查节点状态是否正常节点是否失联可以执行强制删除命令如果强制删除还不行需要去对应节点排查容器、kubelet 服务。你的岗位是大模型技术支持不用深挖 k8s 底层原理记住命令、理解控制器会重建 Pod 这个核心坑点就足够。- kubectl常用命令- 故障排查方法- 日志收集- 监控方案- 备份恢复- 升级策略- RBAC- 安全加固