K8s 的核心概念讲一下。
五个经典回答示范
我按资源对象讲：Pod——最小调度单元，一个或多个共享网络与存储的容器；Deployment——声明副本数与升级策略，管理 Pod 的控制器；Service——稳定访问入口，通过标签选择器聚合 Pod，kube-proxy 实现转发；Ingress——七层入口做路由与 TLS；ConfigMap/Secret——配置与敏感信息挂载进 Pod。调度核心：调度器按资源请求与亲和性选节点。
我讲一次部署实践：Web 服务上 K8s。要点：requests/limits 合理设置（requests 决定调度密度、limits 防失控），CPU limit 压太低会 throttle 导致延迟毛刺——这是我们踩过的坑，改用只设 requests 的 Burstable 模式；探针三件套——liveness 防僵死、readiness 控制流量摘除、startup 保护慢启动应用；滚动更新参数——maxSurge/maxUnavailable 控制发布节奏。发布从停机变更成无感滚动。
资深视角：K8s 的价值是声明式与自愈。三个深层理解：一，期望状态模型——你声明『要 5 个副本』，系统持续纠偏（挂了拉起、节点宕机漂移重建），运维从过程脚本转向状态声明；二，一切皆 API 对象——理解了这个就能举一反三：CRD 让 K8s 成为平台底座，Operator 把运维知识代码化；三，复杂性预算——K8s 引入的运维成本不低，小团队要评估：业务规模是否需要这套调度与自愈，直接 Docker Compose 可能是更优解。
追问『Service 几种类型』：ClusterIP 集群内、NodePort 暴露端口、LoadBalancer 云负载均衡、Ingress 是七层路由的另一种思路；『Pod 之间怎么通信』：同 Pod 共享网络命名空间走 localhost、跨 Pod 走 CNI 网络平面、跨节点靠 Overlay 或路由；『怎么排查 Pod 起不来』：kubectl describe 看事件链——镜像拉取失败、资源不足、探针失败各有对应事件关键字。
『K8s 就是高级点的 Docker，会 kubectl apply 就算会了，出问题 describe 看一眼，不行删了 Pod 重建，反正会自动拉起来。』——点评：把自愈当万能——Pod 反复重启说明声明有错，删了重建只是让错误循环；不理解调度、探针、资源模型，K8s 的故障比裸机更难排查。
- 打开 模拟练习，选择「运维/DBA」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。