问题案例展示

# 一、单选题

# Q1. 以下哪个命令通常用于查看服务器的硬件信息，如内存大小、CPU型号等？

选项	内容
A	lspci
B	lsblk
C	lshw
D ✅	dmidecode

✅ 正确答案：D. dmidecode

解析：

dmidecode：读取主板 DMI/SMBIOS 表，可获取 CPU 型号、内存大小、序列号等详细硬件信息，是查看硬件信息的首选命令。
lspci：列出所有 PCI 总线设备（如显卡、网卡），不包含内存/CPU详情。
lsblk：列出块设备（磁盘、分区），与硬件整体信息无关。
lshw：也能查看硬件信息，但需要额外安装，且 dmidecode 更标准。

# 常用示例
dmidecode -t memory    # 查看内存信息
dmidecode -t processor # 查看CPU信息
dmidecode -t bios      # 查看BIOS信息

1
2
3
4

# Q4. 使用Nginx作为API网关时，需要对特定的API接口进行限流。最合适的实现方式是：

选项	内容
A	使用limit_conn模块限制并发连接数
B ✅	使用limit_req模块限制请求频率
C	使用access模块设置访问控制列表
D	使用rewrite模块重写请求路径

✅ 正确答案：B. 使用limit_req模块限制请求频率

解析：

limit_req：基于令牌桶（漏桶）算法，限制单位时间内的请求速率，是 API 限流的标准做法。
limit_conn：限制并发连接数，而非请求频率，适用于限制同时在线连接，非限流首选。
access：用于 IP 白/黑名单控制，非限流。
rewrite：用于 URL 重写，与限流无关。

# 配置示例
http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
        }
    }
}

1
2
3
4
5
6
7
8
9
10

# Q5. 一个Pod配置了livenessProbe和readinessProbe，如果readinessProbe连续失败，Kubernetes会做什么？

选项	内容
A	重启容器
B ✅	将Pod从所有关联的Service的端点列表（Endpoints）中移除
C ❌	将Pod标记为Failed状态（原答案错误）
D	驱逐（Evict）该Pod

✅ 正确答案：B. 将Pod从所有关联的Service的端点列表（Endpoints）中移除

解析：

两种探针的作用不同，务必区分：

探针	失败后的行为
livenessProbe	重启容器（认为容器已死）
readinessProbe	从 Service Endpoints 中摘除（认为容器未就绪，不接流量）

readinessProbe 失败不会重启容器，也不会标记 Pod 为 Failed，只是让 Pod 暂时不接收流量，保护用户请求不打到未就绪的服务。

# Q9. 关于Linux系统启动流程，以下描述正确的是：

选项	内容
A ✅	GRUB第二阶段会直接加载内核并启动systemd
B	initramfs是一个临时的根文件系统，其重要作用之一是加载根文件系统所在存储的硬件驱动
C	UEFI会直接从第一个硬盘的MBR中读取引导程序
D	default.target是一个systemd服务，它定义了系统要启动的所有服务

✅ 正确答案：A

解析：

Linux 启动完整流程：

BIOS/UEFI → MBR/GPT → GRUB第一阶段 → GRUB第二阶段
→ 加载内核(vmlinuz) → 加载initramfs → 挂载真实根文件系统
→ 启动 /sbin/init (systemd) → default.target → 各服务启动

1
2
3

B 错误：initramfs 描述本身正确，但 A 也正确，而题目让选"正确的"，A 更直接准确。
C 错误：UEFI 不读 MBR，而是直接读取 EFI 分区中的 .efi 引导文件，MBR 是传统 BIOS 的方式。
D 错误：default.target 是一个 systemd target（目标单元），不是"服务"，它是一组服务的集合/依赖关系，通常链接到 multi-user.target 或 graphical.target。

# Q11. TCP三次握手过程中，客户端发送的第一个报文标志位是？

选项	内容
A ✅	SYN
B	SYN-ACK
C	ACK
D	FIN

✅ 正确答案：A. SYN

解析：

TCP 三次握手过程：

客户端                        服务端
  |  ——— SYN (seq=J) ———>     |   第一次：客户端发 SYN
  |  <—— SYN-ACK (seq=K,      |   第二次：服务端回 SYN-ACK
  |        ack=J+1) ———       |
  |  ——— ACK (ack=K+1) ——>    |   第三次：客户端发 ACK
  |                           |   连接建立

1
2
3
4
5
6

客户端第一个报文只设置 SYN 标志位，表示请求建立连接。

# Q12. 一个服务器的IP地址是192.168.1.100，子网掩码是255.255.255.0。那么此服务器所在的子网网络地址是？

选项	内容
A ✅	192.168.1.0
B	192.168.1.1
C	192.168.1.255
D	192.168.0.0

✅ 正确答案：A. 192.168.1.0

解析：

网络地址 = IP 地址 按位与（AND） 子网掩码：

IP:   192.168.1.100  →  11000000.10101000.00000001.01100100
掩码: 255.255.255.0  →  11111111.11111111.11111111.00000000
AND结果:             →  11000000.10101000.00000001.00000000
                     =  192.168.1.0  （网络地址）

1
2
3
4

192.168.1.255 是广播地址
192.168.1.1 通常是网关地址（主机地址）

# Q13. 一个TCP数据包从应用程序发出，经过网络栈，被加上各层头部。在TCP/IP四层模型中，这个封装过程的正确顺序是？

选项	内容
A	数据 → IP头 → TCP头 → 以太网头
B ✅	数据 → TCP头 → IP头 → 以太网头
C	数据 → 以太网头 → IP头 → TCP头
D	数据 → TCP头 → 以太网头 → IP头

✅ 正确答案：B. 数据 → TCP头 → IP头 → 以太网头

解析：

TCP/IP 四层封装（从上到下逐层加头）：

应用层     原始数据
传输层     [TCP头] + 数据          → 形成 Segment（段）
网络层     [IP头] + TCP段          → 形成 Packet（包）
链路层     [以太网头] + IP包 + FCS  → 形成 Frame（帧）

1
2
3
4

解封装时顺序相反（从下到上逐层去头）。

# Q14. 在Prometheus监控系统中，关于数据存储和保留，以下描述正确的是：

选项	内容
A	Prometheus默认将数据存储在内存中，重启后数据丢失
B ✅	可以通过配置remote_write将数据远程存储到其他系统中
C ❌	数据保留时间只能通过启动参数设置，不能动态修改（原答案错误）
D	Prometheus的本地存储适合长期保存大量历史数据

✅ 正确答案：B

解析：

A 错误：Prometheus 默认使用本地磁盘 TSDB 存储，重启后数据不丢失。
B 正确：remote_write 可将数据实时推送到 Thanos、VictoriaMetrics、InfluxDB 等远程存储，是生产环境长期存储的标准方案。
C 错误：保留时间可通过启动参数 --storage.tsdb.retention.time 设置，也可通过管理 API 动态调整。
D 错误：Prometheus 本地存储不适合大量历史数据（默认只保留15天），大规模历史数据需配合 Thanos/Cortex 等方案。

# 启动参数设置保留时间
prometheus --storage.tsdb.retention.time=30d

# remote_write 配置示例
remote_write:
  - url: "http://thanos-receive:19291/api/v1/receive"

1
2
3
4
5
6

# Q15. 以下哪项不是Prometheus监控系统的核心组件？

选项	内容
A ❌	Prometheus Server（原答案错误）
B	Alertmanager
C ✅	Grafana
D	Exporters

✅ 正确答案：C. Grafana

解析：

Prometheus 生态核心组件：

组件	是否核心	说明
Prometheus Server	✅ 是	数据抓取、存储、查询的核心
Alertmanager	✅ 是	告警去重、分组、路由、静默
Exporters	✅ 是	在目标端暴露监控指标（如 node_exporter）
Grafana	❌ 否	独立的可视化平台，并非 Prometheus 项目的组成部分

Grafana 是由 Grafana Labs 独立开发的可视化工具，虽然常与 Prometheus 搭配使用，但它可以对接几十种数据源，并不属于 Prometheus 本身。

# Q16. 客户端向本地DNS服务器发起域名查询，如果本地DNS服务器没有缓存，它会代表客户端向根域名服务器、顶级域服务器等一层层查询，直到拿到结果。这种查询方式属于？

选项	内容
A ✅	递归查询
B	迭代查询
C	反向查询
D ❌	区域传输（原答案错误）

✅ 正确答案：A. 递归查询

解析：

DNS 查询方式区别：

查询类型	说明	发生在哪里
递归查询	客户端委托本地DNS全权代理查询，等待最终结果	客户端 → 本地DNS
迭代查询	DNS服务器返回"下一步该问谁"，由查询方自己继续问	本地DNS → 根/TLD/权威DNS
反向查询	由IP地址反查域名（PTR记录）	-
区域传输	主DNS将区域数据同步到从DNS（AXFR/IXFR）	主从DNS之间

题目描述"本地DNS代替客户端去逐层查询"是从客户端视角看，属于递归查询。

# Q17. 在MySQL主从复制架构中，发现从库的复制延迟（Seconds_Behind_Master）持续增大。以下哪项是最不可能的原因？

选项	内容
A	从库的服务器硬件配置（如CPU、磁盘IO）低于主库
B	从库上运行了繁重的查询语句，消耗了大量资源
C	主库上进行了大量的事务写操作
D ✅	主从之间的网络带宽充足且延迟很低

✅ 正确答案：D

解析：

MySQL 复制延迟常见原因：

从库硬件差：SQL线程回放 binlog 速度跟不上 → 延迟增大 ✅（可能）
从库跑大查询：占用资源影响回放线程 → 延迟增大 ✅（可能）
主库大量写入：binlog 产生速度 > 从库回放速度 → 延迟增大 ✅（可能）
网络充足且延迟低：binlog 传输顺畅，不会导致延迟 ❌（最不可能）

# Q18. 一个进程在收到SIGTERM信号后，其子进程可能会变成：

选项	内容
A ❌	僵尸进程（Zombie）（原答案错误）
B ✅	孤儿进程（Orphan）
C	守护进程（Daemon）
D	僵死进程（Defunct）

✅ 正确答案：B. 孤儿进程（Orphan）

解析：

进程类型区分：

类型	产生原因	处理方式
孤儿进程	父进程先于子进程退出，子进程仍在运行	由 init/systemd（PID 1）接管
僵尸进程	子进程已退出，但父进程未调用 `wait()` 回收其退出状态	父进程调用 `wait()` 或父进程退出
守护进程	后台运行、脱离终端的服务进程	正常运行

父进程收到 SIGTERM 后退出，子进程失去父进程 → 孤儿进程，随后被 init 领养。

# Q20. 在分析系统性能时，vmstat 1命令输出中，us和sy列分别表示：

选项	内容
A ✅	用户态CPU时间、系统态CPU时间
B	等待I/O的CPU时间、空闲CPU时间
C	中断处理时间、上下文切换时间
D	内存交换时间、缓存使用时间

✅ 正确答案：A. 用户态CPU时间、系统态CPU时间

解析：

vmstat CPU 列含义：

列	含义
us	user，用户态程序占用的 CPU 百分比
sy	system，内核态（系统调用）占用的 CPU 百分比
id	idle，CPU 空闲百分比
wa	wait，等待 I/O 的 CPU 百分比
st	steal，被虚拟机 Hypervisor 偷走的 CPU 时间

# 二、多选题

# Q21. 你使用ss -tan命令检查服务器连接状态，发现大量连接处于CLOSE_WAIT状态。这通常表明什么问题？

✅ 正确答案：B + C（+ E）

选项	内容	是否正确
A	你的服务器是主动关闭连接的一方	❌
B	你的服务器是被动关闭连接的一方	✅
C	远端已经关闭了连接（发送了FIN），但你的服务器上的应用程序没有及时调用close()来关闭套接字	✅
D	这是正常的TCP状态，无需处理	❌
E	可能是应用程序存在Bug，导致连接泄露	✅

解析：

TCP 四次挥手中 CLOSE_WAIT 的位置：

客户端（主动关闭）          服务端（被动关闭，即你的服务器）
    |  ——— FIN ———>             |
    |  <—— ACK ———              |  服务端进入 CLOSE_WAIT
    |                           |  ← 应用程序应调用 close()
    |  <—— FIN ———              |  服务端发出 FIN，进入 LAST_ACK
    |  ——— ACK ———>             |

1
2
3
4
5
6

大量 CLOSE_WAIT 说明：服务端收到了对端的 FIN，发了 ACK，但应用程序迟迟没有调用 close()，通常是应用层 Bug（连接池未释放、代码逻辑缺陷等）。

# Q22. 关于进程、信号和权限，以下描述正确的有：

✅ 正确答案：C + D + E

选项	内容	是否正确
A	孤儿进程会被 init（或systemd）进程接管，并由其负责回收资源	❌（接管是对的，但 init 通过 wait() 来回收，表述"负责回收资源"有歧义，严格来说A不完全准确）
B	kill -9 发送的 SIGKILL 信号可以被进程捕获或忽略	❌（SIGKILL 和 SIGSTOP 是唯二不能被捕获/忽略/阻塞的信号）
C	设置了 Sticky Bit 的目录（如/tmp），允许任何用户在其中创建文件，但用户只能删除自己创建的文件	✅
D	sudo 的配置是通过 /etc/sudoers 文件管理的，编辑此文件推荐使用 visudo 命令	✅
E	僵尸进程通常是因为其父进程没有正确地调用 wait() 系列函数来读取子进程的退出状态	✅

# Q23. 以下哪些是应用层协议？

✅ 正确答案：A + B

选项	内容	层次
A	HTTP	✅ 应用层
B	DNS	✅ 应用层
C	TCP	❌ 传输层
D	UDP	❌ 传输层

（若有 SMTP、FTP、SSH 等选项也应选择）

# Q24. 在TCP三次握手过程中，以下描述正确的有？

✅ 正确答案：A + B + D + E

选项	内容	是否正确
A	客户端发送SYN报文，序列号为随机值J，进入SYN_SENT状态	✅
B	服务端收到SYN后，回复SYN-ACK报文，其确认号为J+1，序列号为随机值K，进入SYN_RCVD状态	✅
C	客户端收到SYN-ACK后，回复ACK报文，其确认号为K，序列号为J+1，连接建立	❌（确认号应为 K+1，原题C选项确认号写的是K，错误）
D	如果服务端未收到第三次握手的ACK，会一直停留在SYN_RCVD状态，形成半连接，过多此类连接可能导致SYN Flood攻击	✅
E	三次握手的根本目的是为了协商双方的初始序列号，并确认双方的收发能力正常	✅

# Q25. 可用于数据持久化的中间件有？

✅ 正确答案：A + B + C

选项	内容	是否正确
A	MySQL	✅ 关系型数据库，天然持久化
B	MongoDB	✅ 文档型数据库，天然持久化
C	Redis	✅ 支持 RDB/AOF 持久化机制
D	Kafka	❌ 消息队列，虽然消息落盘，但定位是消息流转而非数据持久化

# Q27. 关于Dockerfile最佳实践，以下说法正确的有？

✅ 正确答案：A + B + C

选项	内容	是否正确
A	使用多阶段构建减小镜像体积	✅
B	使用非root用户运行容器	✅
C	合并RUN指令减少镜像层数	✅
D	基础镜像的版本指定为latest	❌（强烈不推荐，latest 不稳定，应固定版本号）

解析：

# ✅ 好的实践示例
FROM golang:1.21 AS builder          # 多阶段构建：编译阶段
WORKDIR /app
COPY . .
RUN go build -o app .

FROM alpine:3.18                      # 多阶段构建：运行阶段（镜像更小）
RUN adduser -D appuser && \           # 合并 RUN + 非 root 用户
    apk add --no-cache ca-certificates
USER appuser                          # 使用非 root 用户
COPY --from=builder /app/app /app
CMD ["/app"]

1
2
3
4
5
6
7
8
9
10
11
12

# Q28. 可用于网络连通性测试的命令有？

✅ 正确答案：A + B + C + D（全选）

选项	命令	用途
A	ping	测试 ICMP 可达性和延迟
B	telnet	测试 TCP 端口连通性
C	nc（netcat）	测试 TCP/UDP 端口连通性，功能更强
D	traceroute	追踪路由路径，定位网络断点

# 三、填空题

# Q30. 为节点 node-4 添加污点 dedicated=infra:NoSchedule，写出 kubectl 命令：

kubectl taint nodes node-4 dedicated=infra:NoSchedule

解析： 污点格式为 key=value:Effect，Effect 有三种：NoSchedule（不调度）、PreferNoSchedule（尽量不调度）、NoExecute（不调度且驱逐已有 Pod）。

# Q31. 查看 Service web-svc 的 Endpoints，写出 kubectl 命令：

kubectl get endpoints web-svc
# 或
kubectl get ep web-svc

1
2
3

# Q32. 查看 ClusterRole admin 的权限规则，写出 kubectl 命令：

kubectl describe clusterrole admin

# Q33. 查看命名空间 kube-system 中 kubelet 相关 Pod 的实时资源使用情况，写出 kubectl 命令：

kubectl top pod -n kube-system
# 若要过滤 kubelet 相关：
kubectl top pod -n kube-system | grep kubelet

1
2
3

# Q34. 在命名空间 dev 中查看所有 Pod 的详细信息（包括所在节点），写出 kubectl 命令：

kubectl get pods -n dev -o wide

解析： -o wide 会额外显示 Pod IP 和所在节点（NODE 列）。

# Q35. 将 ClusterRole view 绑定给用户 tom，集群范围，资源类型是：

答案：ClusterRoleBinding

解析：

资源类型	作用范围
`RoleBinding`	命名空间级别
`ClusterRoleBinding`	集群级别（全局）

# 创建命令
kubectl create clusterrolebinding tom-view \
  --clusterrole=view \
  --user=tom

1
2
3
4

# Q36. 查看 Pod 失败的调度原因，写出 kubectl 命令：

kubectl describe pod <pod-name>

解析： describe 输出中的 Events 部分会显示调度失败原因，如资源不足、节点选择器不匹配、污点无容忍等。

# Q37. 当 Pod 一直处于 Pending，常见原因之一是：

答案：节点资源不足（CPU/内存不够），没有满足调度条件的节点

常见 Pending 原因汇总：

集群节点资源（CPU/内存）不足
节点有污点（Taint）但 Pod 没有对应容忍（Toleration）
Pod 的 nodeSelector 或 nodeAffinity 没有匹配的节点
PVC 无法绑定（StorageClass 不存在或无可用 PV）
镜像拉取策略或网络问题（通常是 ContainerCreating 而非 Pending）

# Q38. 强制删除命名空间 test 中一个卡在 Terminating 状态的 Pod nginx，写出 kubectl 命令：

kubectl delete pod nginx -n test --force --grace-period=0

解析： --force 强制删除，--grace-period=0 跳过优雅退出等待时间（0 秒）。

# Q39. 查看 Pod nginx 的 IP 地址，写出 kubectl 命令：

kubectl get pod nginx -o wide
# 或精确获取IP
kubectl get pod nginx -o jsonpath='{.status.podIP}'

1
2
3

# Q40. 当 PVC 请求的 StorageClass 不存在时，PVC 状态为：

答案：Pending

解析： PVC 状态流转：

Pending → Bound → Released → (Reclaimed)

当 StorageClass 不存在、没有满足条件的 PV、或动态供应失败时，PVC 一直处于 Pending 状态。

# Q41. 查看 kube-proxy 运行状态，所在命名空间是：

答案：kube-system

解析： Kubernetes 系统组件（kube-proxy、kube-dns/CoreDNS、kube-scheduler 等）均运行在 kube-system 命名空间下。

kubectl get pods -n kube-system | grep kube-proxy

# Q42. 从集群中移除节点 node-6（假设已 drain），写出命令：

kubectl delete node node-6

解析： 完整的节点下线流程：

# 1. 标记不可调度并驱逐 Pod
kubectl drain node-6 --ignore-daemonsets --delete-emptydir-data

# 2. 从集群移除节点
kubectl delete node node-6

# 3. （可选）在 node-6 上重置 kubeadm
kubeadm reset

1
2
3
4
5
6
7
8

# Q43. 将节点 node-1 设置为不可调度，并安全驱逐其上的 Pod（不含 DaemonSet），写出 kubectl 命令：

kubectl drain node-1 --ignore-daemonsets
# 若 Pod 使用了 emptyDir 需加：
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

1
2
3

解析： kubectl drain = cordon（标记 SchedulingDisabled）+ 驱逐所有可驱逐的 Pod。--ignore-daemonsets 表示忽略 DaemonSet 管理的 Pod（不驱逐）。

# Q44. PVC 处于已绑定状态时，其 STATUS 为：

答案：Bound

解析： PVC 与 PV 成功绑定后状态变为 Bound，此时 Pod 可以正常挂载使用该存储。

kubectl get pvc
# NAME    STATUS   VOLUME   CAPACITY   ...
# my-pvc  Bound    pv-001   10Gi       ...

1
2
3

# 四、知识点速查表

知识域	核心考点
Linux	dmidecode、启动流程、进程信号、Sticky Bit、vmstat
网络	TCP三次握手、四层封装、子网计算、DNS查询类型、CLOSE_WAIT
Kubernetes	探针区别、kubectl 命令、调度/污点/亲和、PVC状态、RBAC
Docker	Dockerfile 最佳实践、多阶段构建
Nginx	limit_req vs limit_conn
Prometheus	组件职责、存储机制、remote_write
MySQL	主从复制延迟排查

上次更新: 2026/05/16, 08:18:14

← 个人简历运维面试题二→