SRE运维面试题全解析：从理论到实践（第三部分）

情境与背景

作为一名SRE工程师，面试是职业发展的重要环节。面试官通常会从系统知识、工具使用、问题解决能力等多个维度考察候选人。本文基于真实面试场景，整理了高频面试题，并提供结构化的解析，帮助你快速掌握核心知识点，从容应对面试挑战。

核心面试题解析

216. k8s网络flannel的通信过程是啥？vxlan的通信过程？

Why - 为什么这个问题重要？

Flannel是Kubernetes最常用的CNI插件之一，负责为Pod提供跨节点的网络通信能力。理解Flannel的通信过程和VXLAN技术原理，是设计和维护K8s网络架构的基础，也是高级DevOps/SRE工程师必备的核心知识。VXLAN是目前生产环境最常用的Flannel后端，其通过UDP封装实现三层网络上的二层扩展。

How - Flannel与VXLAN通信流程

flowchart TB
    A["Pod A 发送数据"] --> B["cni0 网桥"]
    B --> C["路由匹配"]
    C --> D["flannel.1 VTEP"]
    D --> E["VXLAN 封装"]
    E --> F["UDP/8472 隧道"]
    F --> G["目标节点 VTEP"]
    G --> H["解封装"]
    H --> I["cni0 网桥"]
    I --> J["Pod B 接收"]

    style A fill:#e3f2fd
    style D fill:#c8e6c9
    style F fill:#fff3e0
    style J fill:#c8e6c9

What - 通信过程详解

VXLAN封装结构

记忆口诀：Pod发包走cni0，路由匹配flannel.1，VTEP封装VXLAN，UDP8472穿隧道，目标解封装，cni0送到Pod。

面试标准答法（1分钟版）：Flannel的通信过程：Pod发送数据包时，通过veth Pair到cni0网桥，内核根据路由表将数据包交给flannel.1接口（VTEP设备）；VTEP根据目标IP查找ARP表获取目标VTEP MAC地址，然后将原始L2帧封装为VXLAN数据包；VXLAN通过UDP 8472端口在物理网络上建立隧道传输；目标节点VTEP收到后解封装，将原始帧交给cni0网桥，网桥通过veth Pair转发到目标Pod。VXLAN本质上是在三层网络上构建二层overlay网络，通过24bit VNI实现1600万虚拟网络隔离。

延伸阅读：想了解更多Flannel与VXLAN生产环境最佳实践？请参考 K8S网络Flannel与VXLAN详解：从原理到生产环境实践。

217. logstash和filebeat之间有啥区别？

Why - 为什么这个问题重要？

在ELK日志系统中，Filebeat和Logstash是最常用的两个组件。理解它们的定位、功能差异和使用场景，是构建高效日志收集架构的基础。Filebeat负责轻量级采集，Logstash负责复杂处理，两者是互补关系而非替代关系。

How - 组件定位与架构

flowchart LR
    A["日志源"] --> B["Filebeat"]
    B --> C["Kafka/Redis"]
    C --> D["Logstash"]
    D --> E["Elasticsearch"]
    E --> F["Kibana"]

    style B fill:#c8e6c9
    style D fill:#fff3e0

What - 核心区别对比

Filebeat优势场景

Logstash优势场景

记忆口诀：采集用Filebeat，处理用Logstash，量大轻量选Filebeat，复杂解析用Logstash。

面试标准答法（1分钟版）：Filebeat和Logstash是ELK栈的两个核心组件，定位不同：Filebeat是轻量级日志采集器，用Go编写，资源消耗低（单进程约40MB），负责从日志源采集数据、做初步过滤和多行合并，适合大规模部署在每台主机上；Logstash是重量级日志处理管道，用JVM运行，功能强大，支持丰富的Input/Filter/Output插件，能做复杂的数据解析、转换和富化，适合集中部署做复杂处理。生产环境的最佳实践是：Filebeat部署在日志源采集日志，通过Kafka解耦后，Logstash做集中处理和解析，最后写入Elasticsearch。

延伸阅读：想了解更多Filebeat与Logstash生产环境最佳实践？请参考 Filebeat与Logstash对比分析：ELK日志收集架构最佳实践。

218. 有一个节点notready，原因是啥？

Why - 为什么这个问题重要？

K8s节点NotReady是生产环境最常见的故障之一，直接影响Pod调度和业务可用性。节点NotReady意味着kubelet无法向API Server报告节点状态，导致该节点上的Pod无法被调度或面临被驱逐的风险。快速定位NotReady原因是SRE的核心技能。

How - 排查思路与流程

flowchart TB
    A["节点NotReady"] --> B["检查kubelet状态"]
    B --> C{"kubelet运行正常?"}
    C -->|否| D["启动/重启kubelet"]
    C -->|是| E["检查网络连通性"]
    E --> F{"API Server可达?"}
    F -->|否| G["检查网络插件"]
    F -->|是| H["检查资源状态"]
    G --> I["重启网络插件"]
    H --> J{"资源充足?"}
    J -->|否| K["扩容或驱逐Pod"]
    J -->|是| L["检查系统服务"]

    style A fill:#ffcdd2
    style D fill:#c8e6c9
    style I fill:#c8e6c9
    style K fill:#c8e6c9

What - 常见原因与解决方案

排查步骤详解

记忆口诀：节点NotReady先查kubelet，网络插件要确认，资源不足看磁盘，内核问题查dmesg，证书时间也要问。

面试标准答法（1分钟版）：节点NotReady的排查思路：先kubectl describe node看Events信息，同时检查kubelet进程状态和日志；常见原因包括：kubelet停止（systemctl restart kubelet）、网络插件异常（重启flanneld或calico-node）、节点资源耗尽（磁盘满或内存不足）、证书过期、swap未关闭等。生产环境应配置监控告警，在节点NotReady时及时发现，同时准备节点自动恢复脚本。

延伸阅读：想了解更多K8s节点NotReady故障排查？请参考 K8s节点NotReady故障排查与恢复：生产环境最佳实践。