企业官网建设流程全解析

1. Kubernetes问答题深度解析（第二辑）

作为容器编排领域的事实标准，Kubernetes的复杂性常常让从业者感到困惑。去年我在某次技术面试中担任主考官时，发现超过60%的候选人在基础概念题上翻车。这个系列正是基于真实面试场景和运维实践中的高频问题整理而成，今天带来第二辑的15个核心问题解析，每个答案都附带场景化说明和底层原理图解。

2. 核心概念辨析

2.1 控制器类型与选举机制

问题：Deployment和StatefulSet的控制器在Pod管理上有何本质区别？

答案看似简单（"一个无状态一个有状态"），但实际差异体现在三个层面：

1. 身份标识：StatefulSet为每个Pod分配稳定标识（如web-0/web-1），这些标识会持久化到PVC中
2. 部署顺序：StatefulSet严格按序扩缩容（逆序终止），而Deployment是并行操作
3. 存储绑定：StatefulSet的每个Pod对应独立的PVC，Deployment的Pod共享同一PVC模板

生产经验：当你的应用需要稳定的网络标识或持久化存储时（如MySQL集群），StatefulSet是唯一选择。我曾见过团队用Deployment跑ZooKeeper导致数据混乱的惨案。

2.2 服务发现进阶场景

问题：ClusterIP类型的Service在DNS中的记录格式是什么？

答案示例：

<service-name>.<namespace>.svc.cluster.local

但实际场景中有三个关键细节：

1. 跨命名空间访问需要完整FQDN，同命名空间可省略后缀
2. Headless Service（clusterIP=None）会生成Pod级别的A记录
3. 通过CoreDNS的rewrite规则可以自定义域名后缀

排查案例：某次服务间调用超时，最终发现是开发者在代码里硬写了service-name.ns1这种不完整域名，导致解析到外部DNS。

3. 调度机制深度剖析

3.1 抢占式调度实战

问题：如何让高优先级Pod抢占节点资源？

标准答案涉及PriorityClass：

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false

但实际生效需要满足以下条件：

1. kube-scheduler需启用NonPreemptingPriority特性门控
2. 被抢占的Pod需满足优雅终止期（默认30秒）
3. 节点资源碎片可能导致抢占失败

血泪教训：线上环境慎用抢占功能！我们曾因PriorityClass配置错误导致关键业务Pod被意外驱逐。

3.2 拓扑分布约束

问题：如何确保Pod均匀分布在不同的可用区？

主流方案对比表：

配置示例：

topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule

4. 存储与网络疑难

4.1 PV回收策略陷阱

问题：Delete和Retain回收策略对数据安全的影响？

常见误解与事实：

• 误以为Delete策略会立即清除数据 → 实际依赖StorageClass的回收策略
• 忽略Retain策略需要手动清理 → 我见过某公司因此积累PB级僵尸卷

安全操作流程：

1. 确认PV状态变为Released
2. 手动删除后端存储（如AWS EBS卷）
3. 移除PV对象（kubectl delete pv）

4.2 NetworkPolicy生效条件

问题：为什么配置了NetworkPolicy却没有生效？

排查路线图：

1. 确认CNI插件支持NetworkPolicy（Calico/Weave等）
2. 检查kube-proxy是否在iptables模式
3. 验证命名空间标签匹配情况
4. 检查策略规则是否存在冲突

典型错误配置：

# 错误：缺少podSelector匹配 spec: ingress: - from: - namespaceSelector: {}

5. 运维监控实战

5.1 自定义指标HPA

问题：如何基于业务日志的错误率实现自动扩缩？

技术栈组合方案：

1. Fluentd/Promtail收集日志
2. Prometheus记录error_count指标
3. Prometheus Adapter转换指标格式
4. HPA配置示例：

metrics: - type: Pods pods: metric: name: error_per_second target: averageValue: 10 type: AverageValue

5.2 节点内存泄漏定位

问题：如何判断kubelet内存泄漏？

诊断命令组合：

# 实时监控 kubectl top node # 进程树分析 ps auxf | grep kubelet # 内存dump kubectl debug node/<name> -it --image=alpine

关键指标阈值：

• RSS持续超过1GB
• 每分钟增长超过5MB
• 容器运行时占用异常偏高

6. 安全加固要点

6.1 ServiceAccount提权风险

问题：如何防止default ServiceAccount被滥用？

防御措施组合拳：

1. 禁用自动挂载

   automountServiceAccountToken: false

2. 启用RBAC审计日志
3. 定期轮换Secret
4. 使用OPA/Gatekeeper添加约束

6.2 镜像漏洞扫描

问题：如何在CI/CD中集成镜像扫描？

工具链对比：

GitLab CI示例：

scan: image: aquasec/trivy:latest script: - trivy image --exit-code 1 --severity CRITICAL ${CI_REGISTRY_IMAGE}

7. 终极调试技巧

当遇到灵异问题时，我的三板斧：

1. 查看事件日志（时间排序很重要！）

   kubectl get events --sort-by=.metadata.creationTimestamp

2. 检查资源最终状态

   kubectl get <resource> -o yaml --show-managed-fields

3. 对比etcd中的原始数据

   etcdctl get /registry/pods/default/<pod-name>

记得某次排障发现Pod一直Pending，最终通过事件日志发现是有人误改了节点Taint。这种问题从Pod描述根本看不出来，必须看完整事件链。