第1章 岗位能力画像与简历优化模板
本节目标：帮助面试者建立Kubernetes交付工程师的完整能力模型，并掌握简历优化的核心方法——从关键词提炼到成果量化，让简历在大厂筛选中脱颖而出。
一、岗位能力画像
K8s交付工程师需同时掌握基础设施与应用交付两个层面能力。以下表格归纳了各维度的核心知识与典型面试提问方向：
| 能力维度 | 核心知识点 | 面试高频点 |
|---|---|---|
| K8s核心原理 | Pod调度、控制器、Service、Ingress、RBAC | 调度策略、控制器选型、网络策略 |
| 容器与运行时 | Docker/containerd、镜像构建、资源限制 | 多阶段构建、cgroup、OOM排查 |
| 网络与存储 | CNI插件、PV/PVC、StorageClass | Calico vs Flannel、动态存储供应 |
| CI/CD 管道 | GitOps、Helm、ArgoCD/Jenkins | 声明式发布、回滚策略、多环境管理 |
| 监控与排障 | Prometheus/Grafana、ELK、kubectl debug | 告警规则设计、Pod日志采集、网络抓包 |
| 安全与合规 | PodSecurityPolicy、网络策略、镜像扫描 | 最小权限原则、Seccomp/AppArmor |
二、简历优化模板
大厂简历筛选平均用时 6-10秒，必须用关键词和量化成果快速吸引面试官。
简历结构建议：个人信息 → 技术摘要（3-5行关键词群） → 工作经历（每段3-5条成果） → 项目经验（选2个核心项目） → 技能清单。
🔑 关键词清单（按优先级排序）
- Kubernetes (K8s) 集群管理
- Docker / containerd
- Helm Charts / Kustomize
- GitOps (ArgoCD / Flux)
- CI/CD (Jenkins / GitHub Actions)
- Prometheus + Grafana
- Ingress / Service Mesh (Istio)
- PV/PVC / CSI 驱动
- RBAC / NetworkPolicy
- 故障排查 (kubectl debug / sysdig)
📊 成果量化句式（参考模板）
| 场景 | 量化句式示例 |
|---|---|
| 集群规模 | 管理 200+ 节点、3000+ Pod 的生产K8s集群，99.99% 可用性。 |
| 上线效率 | 设计GitOps流水线，将发布频率从每周2次提升至每日15次，回滚时间缩短至30秒。 |
| 故障恢复 | 优化Headless Service与Liveness探针，故障自愈率从60%提升到95%，MTTR降低70%。 |
| 成本优化 | 通过HPA+Cluster Autoscaler，集群资源利用率提高40%，年度云成本节省￥120万。 |
三、面试问答实战卡片
面试问题1：请描述Kubernetes的调度过程，以及如何保证Pod被调度到合适的节点？
考察点：是否理解调度器原理（过滤→打分）、常用调度策略（亲和性、污点容忍）。
回答框架：概要调度三个阶段 → 过滤（节点选择） → 打分（加权计算） → 绑定 → 强调自定义调度能力。
示例回答：“调度器先通过预选过滤掉不满足nodeSelector、资源剩余等条件的节点，再根据优选策略如LeastRequestedPriority打分，得分最高的节点被绑定。我还用过PodAffinity实现同可用区部署，Taints确保关键Pod独占GPU节点。”
可能追问：1) 调度失败时如何排查？ 2) 如何实现自定义调度器？ 3) 节点资源碎片如何避免？
避坑提醒：不要只背概念，最好结合生产案例（如“某次因节点资源碎片导致调度失败，通过descheduler重新平衡”）。
面试问题2：GitOps是什么？你如何设计一个生产级的GitOps交付流程？
考察点：对声明式部署的理解、工具选型（ArgoCD/Flux）、多环境管理、安全实践。
回答框架：GitOps核心原则 → 仓库结构（env基线与overlay） → 工具选型（ArgoCD） → 自动同步与Webhook → 回滚策略。
示例回答：“我使用ArgoCD实现GitOps，仓库按dev/staging/prod分层，每个环境一个Kustomize overlay。应用版本变更通过PR触发，自动同步至集群。若发布失败，使用ArgoCD的rollback一键恢复到上一个已部署版本，MTTR小于30秒。”
可能追问：1) 如何确保数据库变更与应用同步？ 2) 多集群GitOps如何管理？ 3) 如何处理密钥（Sealed Secrets / External Secrets）？
避坑提醒：不要只答“用ArgoCD就完了”，要说出仓库结构设计、权限控制、以及和CI流水线的配合。
面试问题3：Pod一直处于CrashLoopBackOff状态，你会如何排查并修复？
考察点：故障排查思路、日志获取、资源限制理解、OOM/健康检查失败判断。
回答框架：描述现象 → kubectl describe pod定位事件 → 查看日志（kubectl logs --previous） → 检查资源限制（OOMKilled） → 检查Liveness/Readiness配置。
示例回答：“先用kubectl describe pod看Events，发现是OOMKilled。修改resources.limits.memory后仍崩溃，再查日志发现应用内存泄漏。临时方案提高limits到8Gi，长期方案修复代码并发布新版本。”
可能追问：1) Liveness探测失败和OOM有什么区别？ 2) 如何通过Prometheus监控Pod的持续重启？ 3) InitContainer在CrashLoop时如何辅助诊断？
避坑提醒：不要只背命令，要展示逻辑链条：从现象到根因，以及临时止血 vs 根治方案的思考。