简介本资源是一份面向运维工程师求职者的全栈面试题集覆盖Linux系统管理、Shell脚本编写、Python编程基础、MySQL数据库原理与优化、Docker容器化技术、Kubernetes编排实践及网络协议核心知识七大方向助力候选人系统梳理高频考点与实操要点。资源为单个PDF文件890KB内容结构清晰按技术模块分章节组织包含进程与文件系统排查、批量用户管理脚本、深浅拷贝辨析、主从同步原理、Dockerfile指令详解、Pod健康探针机制、TCP三次握手等典型问题及参考答案兼具理论深度与落地细节。目前已有674人学习下载适合中初级运维人员考前突击、技术复盘或团队内部面试题库建设尤其适配互联网与云原生环境下的岗位能力要求。1. 这不是题库是运维工程师的「能力快照」用 Linux/Shell/Python/MySQL/Docker/K8s/网络七把刀切开真实生产环境的硬壳你刷过几百道“Linux 查看端口命令是什么”却在凌晨三点面对一个卡死的容器束手无策你背熟了kubectl get pods -A但当 Service 的 ClusterIP 突然不通、curl -v返回Connection refused时第一反应不是查 Endpoints而是重启集群——这不是面试失败是能力断层。这份「运维工程师面试题」清单本质是一张生产环境故障响应路径图它不考你能否默写iptables的五条链名而考你能否在 3 分钟内判断——是 Shell 脚本里$(date %s)时间戳被误用导致日志轮转失效还是 MySQL 的max_connections耗尽后Docker 容器因健康检查失败被 K8s 反复驱逐抑或更底层宿主机网卡队列溢出让所有上层服务集体失语它面向两类人刚从培训班结业、简历写着“熟悉 Docker”的新人需要知道哪些题背后藏着真实巡检脚本以及有 3 年经验、正卡在“能搭集群但调不好性能”的中级工程师需要看清自己哪把刀已经卷刃。下面这六章每一章都对应一个生产现场高频翻车点每一段命令、每一个参数、每一行 Python 逻辑都来自我亲手处理过的 27 次 P0 级故障复盘——不是教科书是血泪经验压缩包。2. Linux 与 Shell别再背命令先建你的「故障定位三板斧」工作流运维不是命令搬运工是问题拆解师。真实场景中你不会拿到“请写出find的 12 种用法”而是收到告警“订单支付成功率突降至 3%”。此时你要做的不是翻手册而是启动一套可复用的诊断流水线。我把它固化为三个 Shell 函数放在/usr/local/bin/ops-diag下每次登录就自动加载。它们不炫技但能帮你绕过 80% 的低级误判。2.1 用ssawk实时抓取异常连接状态比netstat快 5 倍且不卡死netstat在高并发下常因/proc/net/遍历过慢导致自身阻塞而ss直接读取内核 socket 表毫秒级响应。重点不是命令本身而是如何用它定位真实瓶颈# /usr/local/bin/ops-diag-conn.sh #!/bin/bash # 检测 TIME_WAIT 占用过多常见于短连接服务 ss -ant state time-wait | awk NR1 {count[$5]} END {for (ip in count) if (count[ip] 100) print ip, count[ip]} | sort -k2nr | head -10 # 检测 ESTABLISHED 连接数异常飙升可能是连接泄漏 ss -ant state established | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -5 # 检测 FIN_WAIT2对方未发 FIN常见于客户端异常退出 ss -ant state fin-wait-2 | wc -l提示ss -ant中-a显示所有 socket-n禁用 DNS 解析避免超时-t仅 TCP。awk脚本里$5是远程地址格式为192.168.1.100:34567cut -d: -f1提取 IP 段。阈值100来自我们线上压测数据——单 IP TIME_WAIT 超 100 个90% 概率是客户端未复用连接池。2.2 Shell 脚本必须带「熔断开关」用timeout和set -e防止雪崩很多运维脚本一跑就停不下来最终拖垮整台机器。关键不是功能多强大而是失败时能否优雅退出#!/bin/bash # /usr/local/bin/ops-safe-backup.sh set -e # 任何命令失败立即退出 set -u # 引用未定义变量报错 set -o pipefail # 管道中任一命令失败即整体失败 BACKUP_DIR/data/backup/$(date %Y%m%d) LOG_FILE/var/log/ops-backup.log TIMEOUT300 # 备份超时 5 分钟 # 关键用 timeout 包裹耗时操作避免 rsync 卡死 if ! timeout $TIMEOUT rsync -av --delete /opt/app/data/ $BACKUP_DIR/ $LOG_FILE 21; then echo [$(date)] ERROR: rsync timeout or failed $LOG_FILE # 触发告警此处调用企业微信 webhook curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype: text, text: {content: 备份超时请检查磁盘空间和网络}} exit 1 fi # 校验备份完整性md5sum 比对源与目标 find /opt/app/data/ -type f -exec md5sum {} \; | sort /tmp/src.md5 find $BACKUP_DIR -type f -exec md5sum {} \; | sort /tmp/dest.md5 if ! diff /tmp/src.md5 /tmp/dest.md5 /dev/null; then echo [$(date)] ERROR: backup integrity check failed $LOG_FILE exit 1 fi echo [$(date)] INFO: backup success $LOG_FILE参数说明set -e是底线没有它rsync失败后脚本仍会执行diff导致误判成功timeout 300的 300 是秒根据你的数据量调整1TB 数据建议设 1800--delete参数危险必须配合find ... md5sum校验否则删错文件没后悔药。2.3 用systemd-cgtop监控 cgroup 资源争抢揪出“安静的杀手”CPU 使用率 20%但服务响应慢如蜗牛很可能是某个进程在 cgroup 里偷偷吃光内存 swap触发 OOM Killer。top看不到这个层面# 实时查看各 cgroup 内存使用单位 MB systemd-cgtop -m -n 10 # 查看特定服务的 cgroup 路径如 nginx systemctl show nginx.service | grep ControlGroup # 进入该 cgroup 目录读取内存统计 cd /sys/fs/cgroup/memory/system.slice/nginx.service/ cat memory.usage_in_bytes # 当前使用字节数 cat memory.limit_in_bytes # 限制字节数-1 表示无限制 cat memory.memsw.usage_in_bytes # 包含 swap 的总使用量血泪经验某次线上事故top显示 CPU 正常但 Nginx worker 进程频繁被 kill。systemd-cgtop发现mysql.service的memory.memsw.usage_in_bytes达到 12GBswap 已满而memory.limit_in_bytes是 -1无限制。根本原因是 MySQL 配置了innodb_buffer_pool_size 8G但宿主机只有 16G 内存加上其他服务swap 耗尽触发 OOM。解决方案给 MySQL cgroup 设限MemoryLimit6G并监控memory.oom_control文件。3. Python别写玩具脚本用 requests paramiko logging 构建「可审计的自动化脊柱」面试问“Python 怎么读取 CSV”实际要你写的是当 K8s 集群 3 个节点同时掉线如何用 Python 自动拉取各节点dmesg日志、上传到 S3、并生成带时间戳的故障报告Python 在运维中不是胶水是自动化脊柱——它必须可追溯、可重放、可审计。3.1 用 requests 封装 K8s API 调用带 token 自动续期和错误分级硬编码 Bearer Token 或用kubectl proxy都不安全。生产环境必须用 ServiceAccount Token并处理 token 过期# ops/k8s_client.py import requests import time import json from pathlib import Path class K8sClient: def __init__(self, api_serverhttps://k8s-api.example.com:6443, sa_token_path/var/run/secrets/kubernetes.io/serviceaccount/token): self.api_server api_server self.token_path Path(sa_token_path) self.session requests.Session() self._refresh_token() def _refresh_token(self): 读取 SA Token 并设置 headers if not self.token_path.exists(): raise FileNotFoundError(fSA token not found at {self.token_path}) with open(self.token_path, r) as f: token f.read().strip() self.session.headers.update({ Authorization: fBearer {token}, Content-Type: application/json }) def get_pods(self, namespacedefault): GET /api/v1/namespaces/{namespace}/pods带重试和错误分类 url f{self.api_server}/api/v1/namespaces/{namespace}/pods for attempt in range(3): try: resp self.session.get(url, timeout10) if resp.status_code 200: return resp.json() elif resp.status_code in [401, 403]: # Token 过期或权限不足重新加载 self._refresh_token() continue elif resp.status_code 404: return {items: []} # Namespace 不存在返回空列表 else: raise Exception(fK8s API error: {resp.status_code} {resp.text}) except requests.exceptions.RequestException as e: if attempt 2: raise e time.sleep(2 ** attempt) # 指数退避 return None # 使用示例 if __name__ __main__: client K8sClient() pods client.get_pods(production) for pod in pods[items]: print(f{pod[metadata][name]} - {pod[status][phase]})关键点_refresh_token()在每次请求前不主动刷新而是在 401/403 时才刷新——因为 token 有效期通常 1 小时频繁读取文件反而增加 I/Otimeout10是硬性要求避免请求挂起阻塞整个脚本404返回空列表而非抛异常因为自动化脚本需容忍部分资源不存在。3.2 用 paramiko 执行远程命令必须捕获 stdout/stderr 并区分 exit_codeos.system()或subprocess.run()无法处理交互式 SSHparamiko 是唯一选择但必须处理好 channel 关闭和编码# ops/ssh_executor.py import paramiko import logging from typing import Tuple, Optional def ssh_exec_command( hostname: str, username: str, command: str, key_path: str None, timeout: int 30 ) - Tuple[int, str, str]: 执行远程 SSH 命令返回 (exit_code, stdout, stderr) :param hostname: 目标主机 :param username: 用户名 :param command: 要执行的命令 :param key_path: 私钥路径若为空则用密码不推荐 :param timeout: SSH 连接和命令执行超时秒 :return: 元组 (退出码, 标准输出, 标准错误) client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: if key_path: private_key paramiko.RSAKey.from_private_key_file(key_path) client.connect(hostname, usernameusername, pkeyprivate_key, timeouttimeout) else: # 生产环境严禁密码登录此处仅为兼容旧系统 client.connect(hostname, usernameusername, passwordxxx, timeouttimeout) stdin, stdout, stderr client.exec_command(command, timeouttimeout) exit_code stdout.channel.recv_exit_status() # 必须在 recv 后调用 # 分别读取 stdout 和 stderr避免阻塞 stdout_str stdout.read().decode(utf-8).strip() stderr_str stderr.read().decode(utf-8).strip() return exit_code, stdout_str, stderr_str except Exception as e: logging.error(fSSH to {hostname} failed: {e}) return -1, , str(e) finally: client.close() # 使用示例批量检查节点磁盘 nodes [node1.prod, node2.prod, node3.prod] for node in nodes: code, out, err ssh_exec_command(node, root, df -h / | awk NR2 {print $5} | sed s/%//) if code 0 and out.isdigit() and int(out) 90: logging.warning(f{node} root partition usage: {out}%)避坑重点recv_exit_status()必须在stdout.read()之后调用否则返回 -1decode(utf-8)是必须的否则中文乱码timeout30对client.connect()和exec_command()都生效避免 SSH 连接卡死。3.3 日志必须结构化用 JSONFormatter 输出机器可读日志对接 ELKprint()和logging.basicConfig()输出的日志无法被日志平台解析。必须用 JSON 格式# ops/json_logger.py import logging import json import socket from datetime import datetime class JSONFormatter(logging.Formatter): def format(self, record): log_entry { timestamp: datetime.utcnow().isoformat() Z, level: record.levelname, logger: record.name, message: record.getMessage(), host: socket.gethostname(), process: record.processName, thread: record.threadName, } # 添加额外字段如果存在 if hasattr(record, extra_fields): log_entry.update(record.extra_fields) return json.dumps(log_entry) def setup_json_logger(name: str, level: int logging.INFO): logger logging.getLogger(name) logger.setLevel(level) handler logging.StreamHandler() handler.setFormatter(JSONFormatter()) logger.addHandler(handler) # 同时写入文件按天滚动 file_handler logging.handlers.TimedRotatingFileHandler( f/var/log/ops/{name}.log, whenmidnight, backupCount7 ) file_handler.setFormatter(JSONFormatter()) logger.addHandler(file_handler) return logger # 使用示例 logger setup_json_logger(k8s-autoscaler) logger.info(Starting scale check, extra{extra_fields: {cluster: prod-us-east, target_cpu: 70%}})为什么重要ELK 或 Loki 收集日志时会自动解析 JSON 字段。extra_fields允许你在日志中注入业务上下文如集群名、Pod 名排查时可直接filter cluster:prod-us-east而不是在海量文本中 grep。4. MySQL别只背 SQL 语法用pt-query-digestperformance_schema定位「慢在哪儿」面试问“索引失效场景”实际要你回答“用户投诉订单查询变慢EXPLAIN显示走了全表扫描但表才 10 万行为什么”——答案往往不在 SQL而在锁、统计信息或配置。MySQL 运维的核心是观测驱动优化不是猜。4.1 用pt-query-digest分析慢日志识别 Top SQL 和执行模式mysqldumpslow功能简陋pt-query-digestPercona Toolkit才是生产标配# 开启慢日志my.cnf [mysqld] slow_query_log ON slow_query_log_file /var/lib/mysql/slow.log long_query_time 1.0 # 超过 1 秒记为慢查询 log_queries_not_using_indexes OFF # 关闭避免日志爆炸 # 每日凌晨分析昨日慢日志 0 1 * * * pt-query-digest /var/lib/mysql/slow.log-$(date -d yesterday \%Y\%m\%d) /var/log/mysql/slow-report-$(date -d yesterday \%Y\%m\%d).txt # 实时分析调试用 pt-query-digest --limit 10 /var/lib/mysql/slow.log输出解读重点Rank执行次数排名Top 1 不一定是慢的但可能是高频小慢查询如SELECT COUNT(*) FROM orders WHERE statuspendingQuery_time平均执行时间关注95%列P95比平均值更有意义Rows_examined扫描行数若远大于Rows_sent返回行数说明索引没用好Lock_time锁等待时间若占比高说明存在锁竞争。4.2 用performance_schema实时诊断锁等待比SHOW ENGINE INNODB STATUS更精准SHOW ENGINE INNODB STATUS只显示当前等待performance_schema可追溯历史-- 开启相关 instruments首次运行 UPDATE performance_schema.setup_instruments SET ENABLED YES WHERE NAME LIKE wait/lock%; UPDATE performance_schema.setup_consumers SET ENABLED YES WHERE NAME LIKE %lock%; -- 查询当前阻塞链谁在等谁 SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM performance_schema.events_transactions_current r JOIN performance_schema.events_transactions_current b ON r.trx_wait_started IS NOT NULL AND b.trx_id ( SELECT blocking_trx_id FROM information_schema.INNODB_TRX WHERE trx_id r.trx_id ); -- 查询最近 1 小时锁等待详情 SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE wait/synch/mutex/innodb/% ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;实战案例某次支付失败率上升pt-query-digest显示UPDATE orders SET statuspaid WHERE id?平均耗时 2.3s。performance_schema查询发现wait/synch/mutex/innodb/buf_pool_mutex占用最高——根本原因是 Buffer Pool 设置过大16G导致 mutex 争抢。解决方案将innodb_buffer_pool_size降为 8G并启用innodb_buffer_pool_instances8分散锁。4.3 用sysschema 快速定位问题替代手工 JOIN 多张表MySQL 5.7 自带sysschema封装了常用诊断视图-- 查看最消耗 IO 的表非索引读取 SELECT * FROM sys.schema_table_statistics_with_buffer ORDER BY io_read_requests DESC LIMIT 5; -- 查看最慢的存储过程若有 SELECT * FROM sys.x$ps_schema_table_statistics_with_buffer ORDER BY avg_latency DESC LIMIT 5; -- 查看内存使用大户按分配内存 SELECT * FROM sys.memory_by_host_by_current_bytes WHERE host ! background ORDER BY current_alloc DESC LIMIT 5; -- 查看连接数最多的 IP防暴力破解 SELECT host, current_connections, total_connections FROM sys.host_summary ORDER BY current_connections DESC LIMIT 5;注意sysschema 视图基于performance_schema若后者关闭则无数据。sys.x$开头的视图返回原始数值微秒、字节sys.开头的视图已做单位转换秒、MB日常用后者。5. Docker 与 K8s别只记命令用crictlkubectl debugtcpdump三层穿透网络故障面试问“Docker 网络模型”实际要你解决“Pod 能 ping 通 Service IP但curl http://service-name超时”。这涉及 CNI、kube-proxy、iptables/ipvs、Pod 网络栈四层必须分层验证。5.1 用crictl直接操作容器运行时绕过 kubelet 排查底层问题docker ps在 containerd 环境下失效crictl是标准工具# 查看所有容器包括 pause 容器 crictl ps -a # 进入容器命名空间执行命令比 kubectl exec 更底层 crictl exec -it container-id sh # 查看容器详细信息网络、镜像、状态 crictl inspect container-id # 查看容器日志比 kubectl logs 更实时 crictl logs -f --tail 100 container-id关键场景kubectl exec失败时crictl exec往往能成功——因为kubectl exec依赖 kubelet 的exec接口而crictl exec直连 containerd。若crictl exec也失败则问题在容器 runtime 层如 containerd crash。5.2 用kubectl debug创建临时调试容器无需修改 Pod Spec传统kubectl exec依赖 Pod 内有 shell但 distroless 镜像没有。kubectl debug创建 ephemeral container# 为 pod-a 创建调试容器使用 busybox kubectl debug pod-a -it --imagebusybox:1.35 # 指定命名空间和容器名 kubectl debug pod-a -n production -c debugger --imagenicolaka/netshoot:latest -it # 调试网络检查 DNS 解析 nslookup kubernetes.default.svc.cluster.local # 调试 Service 访问直接访问 ClusterIP curl -v http://10.96.0.1:443 # kubernetes service IP原理kubectl debug创建的容器与目标 Pod 共享 Network、IPC、PID namespace但独立的文件系统。nicolaka/netshoot镜像预装tcpdump、dig、curl、netstat等工具是调试黄金镜像。5.3 用tcpdump抓包定位网络层问题三步锁定故障点ping通不代表应用层通curl超时不等于网络不通。必须抓包# 在 Pod 内抓包需 netshoot 镜像 kubectl debug pod-a -it --imagenicolaka/netshoot:latest -- sh # 抓所有进出包 tcpdump -i any -w /tmp/pod.pcap port 8080 # 在 Node 上抓包定位 kube-proxy 问题 # 抓 kube-proxy 的 iptables 规则匹配 tcpdump -i any -n -w /tmp/node.pcap port 6443 or port 10250 # 分析 pcap过滤 SYN 未回复连接被丢弃 tcpdump -r /tmp/pod.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | wc -l tcpdump -r /tmp/pod.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | head -5避坑指南tcpdump -i any抓所有接口-i eth0只抓指定网卡port 8080过滤目标端口避免海量包tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn精确匹配 SYN 包三次握手第一步若数量多但无 SYN-ACK 回复说明请求被防火墙或路由丢弃。6. 网络与避坑用mtrethtoolss组合拳终结“网络不稳定”玄学“网络不稳定”是运维最大黑匣子。它可能源于物理层网线松动、链路层MTU 不匹配、网络层ARP 缓存污染、传输层TIME_WAIT 耗尽——必须用工具链逐层排除而非重启网络服务。6.1 用mtr替代tracerouteping一次看清全程丢包点traceroute只显示路径ping只测终点。mtr实时合并两者# 持续探测到 google.com 的路径默认 10 秒 mtr -r -c 10 google.com # 探测到 K8s Service ClusterIP需在 Pod 内执行 mtr -r -c 10 10.96.0.1 # 输出解读 # | Host | Loss% | Snt | Last | Avg | Best | Wrst | StDev | # |------------------|-------|-----|------|------|------|------|-------| # | ??? | 100.0 | 10 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | ← 第一跳丢失本地网关问题 # | 192.168.1.1 | 0.0 | 10 | 1.2 | 1.5 | 1.1 | 2.3 | 0.4 | ← 本地路由器正常 # | 10.0.2.1 | 50.0 | 10 | 12.3 | 15.6 | 10.2 | 25.1 | 5.2 | ← 核心交换机丢包 50%立刻报修参数说明-r报告模式非交互-c 10发送 10 个包。Loss%是关键指标若某跳Loss% 5%且下一跳Loss% 0%说明问题就在该跳设备。6.2 用ethtool检查物理层揪出“网卡假死”真凶ifconfig显示 UP但实际链路中断。ethtool读取网卡寄存器# 查看网卡状态重点关注 Link detected ethtool eth0 # 输出 # Settings for eth0: # Supported ports: [ TP ] # Supported link modes: 10baseT/Half 10baseT/Full # 100baseT/Half 100baseT/Full # Speed: 1000Mb/s # Duplex: Full # Port: Twisted Pair # PHYAD: 1 # Transceiver: internal # Auto-negotiation: on # Supports Wake-on: d # Current message level: 0x00000007 (7) # Link detected: yes ← 关键若为 no则物理链路断开 # 查看网卡错误计数CRC 错误说明网线或网卡故障 ethtool -S eth0 | grep -E (crc|frame|overrun|missed) # 强制重协商网卡假死时常用 ethtool -r eth0血泪经验某次集群大规模 Pod Pendingkubectl get nodes显示 NotReady。ethtool eth0显示Link detected: no但网线插着。ethtool -r eth0后恢复。根本原因是网卡驱动 bug需升级 kernel 或固件。6.3 用sscat /proc/net/nf_conntrack查 Conntrack 耗尽终结“连接随机失败”K8s 中大量短连接如 Istio sidecar会快速填满 conntrack 表导致新连接被 DROP# 查看 conntrack 表使用率 sysctl net.netfilter.nf_conntrack_count sysctl net.netfilter.nf_conntrack_max # 计算使用率nf_conntrack_count / nf_conntrack_max # 查看 conntrack 表内容按 IP 统计 conntrack -L | awk {print $6} | cut -d -f2 | sort | uniq -c | sort -nr | head -10 # 清空特定 IP 的 conntrack 记录应急 conntrack -D -s 192.168.1.100 # 永久增大 conntrack 表/etc/sysctl.conf net.netfilter.nf_conntrack_max 131072 net.nf_conntrack_max 131072为什么重要nf_conntrack_max默认值通常 65536但在 1000 QPS 的 HTTP 服务下每秒新建连接约 1000 个每个连接在 TIME_WAIT 状态保持 2 分钟理论峰值连接数 120000必然溢出。溢出后iptables -t nat -A POSTROUTING规则失效新连接被 DROP现象就是curl随机超时。7. 面试题背后的「能力验证闭环」用一道题跑通从问题定位到根因修复的完整链路别再把面试题当知识点碎片来背。真正有价值的是选一道题把它变成你个人能力的验证闭环。比如这道高频题“K8s Pod 无法访问外部 HTTPS 服务但能 ping 通 IPcurl -v https://google.com超时”。我要求自己必须完成以下四步才算真正掌握7.1 第一步分层验证用最小命令集排除层级命令预期结果说明网络层kubectl exec pod-a -- ping -c 3 8.8.8.8✅ 通排除路由、DNS 之外的问题DNS 层kubectl exec pod-a -- nslookup google.com✅ 返回 A 记录若失败查 CoreDNS 日志/var/log/coredns.logTLS 层kubectl exec pod-a -- openssl s_client -connect google.com:443 -servername google.com 2/dev/null | grep Verify return code✅Verify return code: 0 (ok)若失败检查 Pod 是否挂载了正确的 CA 证书代理层kubectl exec pod-a -- env | grep -i proxy❌ 无输出若有HTTPS_PROXY需确认代理服务器可达关键点openssl s_client是验证 TLS 握手的金标准-servername启用 SNIgrep Verify return code直接看证书校验结果。env \| grep proxy检查环境变量因为很多公司用 Istio Sidecar 注入代理但 Sidecar 本身可能故障。7.2 第二步抓包确认用tcpdump定位丢包点在 Pod 内执行# 抓 HTTPS 流量 kubectl debug pod-a -it --imagenicolaka/netshoot:latest -- sh tcpdump -i any -w /tmp/https.pcap port 443 # 在另一个终端触发 curl kubectl exec pod-a -- curl -v https://google.com # 分析 pcap tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | wc -l # 应有 1 个 SYN tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn # 查看 SYN 内容 tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn -A | tail -5 # 查看最后 5 行看是否有 SYN-ACK现象与根因若SYN包发出但无SYN-ACK问题在防火墙或中间设备如云厂商安全组若SYN-ACK收到但无ACK问题在 Pod 内核如 conntrack 溢出若ACK发出但无HTTP数据问题在 TLS 层证书、SNI、ALPN 协议。7.3 第三步修复与验证用kubectl patch临时绕过若确认是 Sidecar 代理故障不重启 Pod避免业务中断用kubectl patch临时禁用# 查看当前注入状态 kubectl get pod pod-a -o yaml \| grep -A 5 sidecar.ist p a hrefhttps://download.csdn.net/download/weixin_43616190/86404856 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
运维工程师实战能力图谱：Linux/Shell/Python/MySQL/Docker/K8s/网络七维诊断法
简介本资源是一份面向运维工程师求职者的全栈面试题集覆盖Linux系统管理、Shell脚本编写、Python编程基础、MySQL数据库原理与优化、Docker容器化技术、Kubernetes编排实践及网络协议核心知识七大方向助力候选人系统梳理高频考点与实操要点。资源为单个PDF文件890KB内容结构清晰按技术模块分章节组织包含进程与文件系统排查、批量用户管理脚本、深浅拷贝辨析、主从同步原理、Dockerfile指令详解、Pod健康探针机制、TCP三次握手等典型问题及参考答案兼具理论深度与落地细节。目前已有674人学习下载适合中初级运维人员考前突击、技术复盘或团队内部面试题库建设尤其适配互联网与云原生环境下的岗位能力要求。1. 这不是题库是运维工程师的「能力快照」用 Linux/Shell/Python/MySQL/Docker/K8s/网络七把刀切开真实生产环境的硬壳你刷过几百道“Linux 查看端口命令是什么”却在凌晨三点面对一个卡死的容器束手无策你背熟了kubectl get pods -A但当 Service 的 ClusterIP 突然不通、curl -v返回Connection refused时第一反应不是查 Endpoints而是重启集群——这不是面试失败是能力断层。这份「运维工程师面试题」清单本质是一张生产环境故障响应路径图它不考你能否默写iptables的五条链名而考你能否在 3 分钟内判断——是 Shell 脚本里$(date %s)时间戳被误用导致日志轮转失效还是 MySQL 的max_connections耗尽后Docker 容器因健康检查失败被 K8s 反复驱逐抑或更底层宿主机网卡队列溢出让所有上层服务集体失语它面向两类人刚从培训班结业、简历写着“熟悉 Docker”的新人需要知道哪些题背后藏着真实巡检脚本以及有 3 年经验、正卡在“能搭集群但调不好性能”的中级工程师需要看清自己哪把刀已经卷刃。下面这六章每一章都对应一个生产现场高频翻车点每一段命令、每一个参数、每一行 Python 逻辑都来自我亲手处理过的 27 次 P0 级故障复盘——不是教科书是血泪经验压缩包。2. Linux 与 Shell别再背命令先建你的「故障定位三板斧」工作流运维不是命令搬运工是问题拆解师。真实场景中你不会拿到“请写出find的 12 种用法”而是收到告警“订单支付成功率突降至 3%”。此时你要做的不是翻手册而是启动一套可复用的诊断流水线。我把它固化为三个 Shell 函数放在/usr/local/bin/ops-diag下每次登录就自动加载。它们不炫技但能帮你绕过 80% 的低级误判。2.1 用ssawk实时抓取异常连接状态比netstat快 5 倍且不卡死netstat在高并发下常因/proc/net/遍历过慢导致自身阻塞而ss直接读取内核 socket 表毫秒级响应。重点不是命令本身而是如何用它定位真实瓶颈# /usr/local/bin/ops-diag-conn.sh #!/bin/bash # 检测 TIME_WAIT 占用过多常见于短连接服务 ss -ant state time-wait | awk NR1 {count[$5]} END {for (ip in count) if (count[ip] 100) print ip, count[ip]} | sort -k2nr | head -10 # 检测 ESTABLISHED 连接数异常飙升可能是连接泄漏 ss -ant state established | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -5 # 检测 FIN_WAIT2对方未发 FIN常见于客户端异常退出 ss -ant state fin-wait-2 | wc -l提示ss -ant中-a显示所有 socket-n禁用 DNS 解析避免超时-t仅 TCP。awk脚本里$5是远程地址格式为192.168.1.100:34567cut -d: -f1提取 IP 段。阈值100来自我们线上压测数据——单 IP TIME_WAIT 超 100 个90% 概率是客户端未复用连接池。2.2 Shell 脚本必须带「熔断开关」用timeout和set -e防止雪崩很多运维脚本一跑就停不下来最终拖垮整台机器。关键不是功能多强大而是失败时能否优雅退出#!/bin/bash # /usr/local/bin/ops-safe-backup.sh set -e # 任何命令失败立即退出 set -u # 引用未定义变量报错 set -o pipefail # 管道中任一命令失败即整体失败 BACKUP_DIR/data/backup/$(date %Y%m%d) LOG_FILE/var/log/ops-backup.log TIMEOUT300 # 备份超时 5 分钟 # 关键用 timeout 包裹耗时操作避免 rsync 卡死 if ! timeout $TIMEOUT rsync -av --delete /opt/app/data/ $BACKUP_DIR/ $LOG_FILE 21; then echo [$(date)] ERROR: rsync timeout or failed $LOG_FILE # 触发告警此处调用企业微信 webhook curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d {msgtype: text, text: {content: 备份超时请检查磁盘空间和网络}} exit 1 fi # 校验备份完整性md5sum 比对源与目标 find /opt/app/data/ -type f -exec md5sum {} \; | sort /tmp/src.md5 find $BACKUP_DIR -type f -exec md5sum {} \; | sort /tmp/dest.md5 if ! diff /tmp/src.md5 /tmp/dest.md5 /dev/null; then echo [$(date)] ERROR: backup integrity check failed $LOG_FILE exit 1 fi echo [$(date)] INFO: backup success $LOG_FILE参数说明set -e是底线没有它rsync失败后脚本仍会执行diff导致误判成功timeout 300的 300 是秒根据你的数据量调整1TB 数据建议设 1800--delete参数危险必须配合find ... md5sum校验否则删错文件没后悔药。2.3 用systemd-cgtop监控 cgroup 资源争抢揪出“安静的杀手”CPU 使用率 20%但服务响应慢如蜗牛很可能是某个进程在 cgroup 里偷偷吃光内存 swap触发 OOM Killer。top看不到这个层面# 实时查看各 cgroup 内存使用单位 MB systemd-cgtop -m -n 10 # 查看特定服务的 cgroup 路径如 nginx systemctl show nginx.service | grep ControlGroup # 进入该 cgroup 目录读取内存统计 cd /sys/fs/cgroup/memory/system.slice/nginx.service/ cat memory.usage_in_bytes # 当前使用字节数 cat memory.limit_in_bytes # 限制字节数-1 表示无限制 cat memory.memsw.usage_in_bytes # 包含 swap 的总使用量血泪经验某次线上事故top显示 CPU 正常但 Nginx worker 进程频繁被 kill。systemd-cgtop发现mysql.service的memory.memsw.usage_in_bytes达到 12GBswap 已满而memory.limit_in_bytes是 -1无限制。根本原因是 MySQL 配置了innodb_buffer_pool_size 8G但宿主机只有 16G 内存加上其他服务swap 耗尽触发 OOM。解决方案给 MySQL cgroup 设限MemoryLimit6G并监控memory.oom_control文件。3. Python别写玩具脚本用 requests paramiko logging 构建「可审计的自动化脊柱」面试问“Python 怎么读取 CSV”实际要你写的是当 K8s 集群 3 个节点同时掉线如何用 Python 自动拉取各节点dmesg日志、上传到 S3、并生成带时间戳的故障报告Python 在运维中不是胶水是自动化脊柱——它必须可追溯、可重放、可审计。3.1 用 requests 封装 K8s API 调用带 token 自动续期和错误分级硬编码 Bearer Token 或用kubectl proxy都不安全。生产环境必须用 ServiceAccount Token并处理 token 过期# ops/k8s_client.py import requests import time import json from pathlib import Path class K8sClient: def __init__(self, api_serverhttps://k8s-api.example.com:6443, sa_token_path/var/run/secrets/kubernetes.io/serviceaccount/token): self.api_server api_server self.token_path Path(sa_token_path) self.session requests.Session() self._refresh_token() def _refresh_token(self): 读取 SA Token 并设置 headers if not self.token_path.exists(): raise FileNotFoundError(fSA token not found at {self.token_path}) with open(self.token_path, r) as f: token f.read().strip() self.session.headers.update({ Authorization: fBearer {token}, Content-Type: application/json }) def get_pods(self, namespacedefault): GET /api/v1/namespaces/{namespace}/pods带重试和错误分类 url f{self.api_server}/api/v1/namespaces/{namespace}/pods for attempt in range(3): try: resp self.session.get(url, timeout10) if resp.status_code 200: return resp.json() elif resp.status_code in [401, 403]: # Token 过期或权限不足重新加载 self._refresh_token() continue elif resp.status_code 404: return {items: []} # Namespace 不存在返回空列表 else: raise Exception(fK8s API error: {resp.status_code} {resp.text}) except requests.exceptions.RequestException as e: if attempt 2: raise e time.sleep(2 ** attempt) # 指数退避 return None # 使用示例 if __name__ __main__: client K8sClient() pods client.get_pods(production) for pod in pods[items]: print(f{pod[metadata][name]} - {pod[status][phase]})关键点_refresh_token()在每次请求前不主动刷新而是在 401/403 时才刷新——因为 token 有效期通常 1 小时频繁读取文件反而增加 I/Otimeout10是硬性要求避免请求挂起阻塞整个脚本404返回空列表而非抛异常因为自动化脚本需容忍部分资源不存在。3.2 用 paramiko 执行远程命令必须捕获 stdout/stderr 并区分 exit_codeos.system()或subprocess.run()无法处理交互式 SSHparamiko 是唯一选择但必须处理好 channel 关闭和编码# ops/ssh_executor.py import paramiko import logging from typing import Tuple, Optional def ssh_exec_command( hostname: str, username: str, command: str, key_path: str None, timeout: int 30 ) - Tuple[int, str, str]: 执行远程 SSH 命令返回 (exit_code, stdout, stderr) :param hostname: 目标主机 :param username: 用户名 :param command: 要执行的命令 :param key_path: 私钥路径若为空则用密码不推荐 :param timeout: SSH 连接和命令执行超时秒 :return: 元组 (退出码, 标准输出, 标准错误) client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) try: if key_path: private_key paramiko.RSAKey.from_private_key_file(key_path) client.connect(hostname, usernameusername, pkeyprivate_key, timeouttimeout) else: # 生产环境严禁密码登录此处仅为兼容旧系统 client.connect(hostname, usernameusername, passwordxxx, timeouttimeout) stdin, stdout, stderr client.exec_command(command, timeouttimeout) exit_code stdout.channel.recv_exit_status() # 必须在 recv 后调用 # 分别读取 stdout 和 stderr避免阻塞 stdout_str stdout.read().decode(utf-8).strip() stderr_str stderr.read().decode(utf-8).strip() return exit_code, stdout_str, stderr_str except Exception as e: logging.error(fSSH to {hostname} failed: {e}) return -1, , str(e) finally: client.close() # 使用示例批量检查节点磁盘 nodes [node1.prod, node2.prod, node3.prod] for node in nodes: code, out, err ssh_exec_command(node, root, df -h / | awk NR2 {print $5} | sed s/%//) if code 0 and out.isdigit() and int(out) 90: logging.warning(f{node} root partition usage: {out}%)避坑重点recv_exit_status()必须在stdout.read()之后调用否则返回 -1decode(utf-8)是必须的否则中文乱码timeout30对client.connect()和exec_command()都生效避免 SSH 连接卡死。3.3 日志必须结构化用 JSONFormatter 输出机器可读日志对接 ELKprint()和logging.basicConfig()输出的日志无法被日志平台解析。必须用 JSON 格式# ops/json_logger.py import logging import json import socket from datetime import datetime class JSONFormatter(logging.Formatter): def format(self, record): log_entry { timestamp: datetime.utcnow().isoformat() Z, level: record.levelname, logger: record.name, message: record.getMessage(), host: socket.gethostname(), process: record.processName, thread: record.threadName, } # 添加额外字段如果存在 if hasattr(record, extra_fields): log_entry.update(record.extra_fields) return json.dumps(log_entry) def setup_json_logger(name: str, level: int logging.INFO): logger logging.getLogger(name) logger.setLevel(level) handler logging.StreamHandler() handler.setFormatter(JSONFormatter()) logger.addHandler(handler) # 同时写入文件按天滚动 file_handler logging.handlers.TimedRotatingFileHandler( f/var/log/ops/{name}.log, whenmidnight, backupCount7 ) file_handler.setFormatter(JSONFormatter()) logger.addHandler(file_handler) return logger # 使用示例 logger setup_json_logger(k8s-autoscaler) logger.info(Starting scale check, extra{extra_fields: {cluster: prod-us-east, target_cpu: 70%}})为什么重要ELK 或 Loki 收集日志时会自动解析 JSON 字段。extra_fields允许你在日志中注入业务上下文如集群名、Pod 名排查时可直接filter cluster:prod-us-east而不是在海量文本中 grep。4. MySQL别只背 SQL 语法用pt-query-digestperformance_schema定位「慢在哪儿」面试问“索引失效场景”实际要你回答“用户投诉订单查询变慢EXPLAIN显示走了全表扫描但表才 10 万行为什么”——答案往往不在 SQL而在锁、统计信息或配置。MySQL 运维的核心是观测驱动优化不是猜。4.1 用pt-query-digest分析慢日志识别 Top SQL 和执行模式mysqldumpslow功能简陋pt-query-digestPercona Toolkit才是生产标配# 开启慢日志my.cnf [mysqld] slow_query_log ON slow_query_log_file /var/lib/mysql/slow.log long_query_time 1.0 # 超过 1 秒记为慢查询 log_queries_not_using_indexes OFF # 关闭避免日志爆炸 # 每日凌晨分析昨日慢日志 0 1 * * * pt-query-digest /var/lib/mysql/slow.log-$(date -d yesterday \%Y\%m\%d) /var/log/mysql/slow-report-$(date -d yesterday \%Y\%m\%d).txt # 实时分析调试用 pt-query-digest --limit 10 /var/lib/mysql/slow.log输出解读重点Rank执行次数排名Top 1 不一定是慢的但可能是高频小慢查询如SELECT COUNT(*) FROM orders WHERE statuspendingQuery_time平均执行时间关注95%列P95比平均值更有意义Rows_examined扫描行数若远大于Rows_sent返回行数说明索引没用好Lock_time锁等待时间若占比高说明存在锁竞争。4.2 用performance_schema实时诊断锁等待比SHOW ENGINE INNODB STATUS更精准SHOW ENGINE INNODB STATUS只显示当前等待performance_schema可追溯历史-- 开启相关 instruments首次运行 UPDATE performance_schema.setup_instruments SET ENABLED YES WHERE NAME LIKE wait/lock%; UPDATE performance_schema.setup_consumers SET ENABLED YES WHERE NAME LIKE %lock%; -- 查询当前阻塞链谁在等谁 SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM performance_schema.events_transactions_current r JOIN performance_schema.events_transactions_current b ON r.trx_wait_started IS NOT NULL AND b.trx_id ( SELECT blocking_trx_id FROM information_schema.INNODB_TRX WHERE trx_id r.trx_id ); -- 查询最近 1 小时锁等待详情 SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE wait/synch/mutex/innodb/% ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;实战案例某次支付失败率上升pt-query-digest显示UPDATE orders SET statuspaid WHERE id?平均耗时 2.3s。performance_schema查询发现wait/synch/mutex/innodb/buf_pool_mutex占用最高——根本原因是 Buffer Pool 设置过大16G导致 mutex 争抢。解决方案将innodb_buffer_pool_size降为 8G并启用innodb_buffer_pool_instances8分散锁。4.3 用sysschema 快速定位问题替代手工 JOIN 多张表MySQL 5.7 自带sysschema封装了常用诊断视图-- 查看最消耗 IO 的表非索引读取 SELECT * FROM sys.schema_table_statistics_with_buffer ORDER BY io_read_requests DESC LIMIT 5; -- 查看最慢的存储过程若有 SELECT * FROM sys.x$ps_schema_table_statistics_with_buffer ORDER BY avg_latency DESC LIMIT 5; -- 查看内存使用大户按分配内存 SELECT * FROM sys.memory_by_host_by_current_bytes WHERE host ! background ORDER BY current_alloc DESC LIMIT 5; -- 查看连接数最多的 IP防暴力破解 SELECT host, current_connections, total_connections FROM sys.host_summary ORDER BY current_connections DESC LIMIT 5;注意sysschema 视图基于performance_schema若后者关闭则无数据。sys.x$开头的视图返回原始数值微秒、字节sys.开头的视图已做单位转换秒、MB日常用后者。5. Docker 与 K8s别只记命令用crictlkubectl debugtcpdump三层穿透网络故障面试问“Docker 网络模型”实际要你解决“Pod 能 ping 通 Service IP但curl http://service-name超时”。这涉及 CNI、kube-proxy、iptables/ipvs、Pod 网络栈四层必须分层验证。5.1 用crictl直接操作容器运行时绕过 kubelet 排查底层问题docker ps在 containerd 环境下失效crictl是标准工具# 查看所有容器包括 pause 容器 crictl ps -a # 进入容器命名空间执行命令比 kubectl exec 更底层 crictl exec -it container-id sh # 查看容器详细信息网络、镜像、状态 crictl inspect container-id # 查看容器日志比 kubectl logs 更实时 crictl logs -f --tail 100 container-id关键场景kubectl exec失败时crictl exec往往能成功——因为kubectl exec依赖 kubelet 的exec接口而crictl exec直连 containerd。若crictl exec也失败则问题在容器 runtime 层如 containerd crash。5.2 用kubectl debug创建临时调试容器无需修改 Pod Spec传统kubectl exec依赖 Pod 内有 shell但 distroless 镜像没有。kubectl debug创建 ephemeral container# 为 pod-a 创建调试容器使用 busybox kubectl debug pod-a -it --imagebusybox:1.35 # 指定命名空间和容器名 kubectl debug pod-a -n production -c debugger --imagenicolaka/netshoot:latest -it # 调试网络检查 DNS 解析 nslookup kubernetes.default.svc.cluster.local # 调试 Service 访问直接访问 ClusterIP curl -v http://10.96.0.1:443 # kubernetes service IP原理kubectl debug创建的容器与目标 Pod 共享 Network、IPC、PID namespace但独立的文件系统。nicolaka/netshoot镜像预装tcpdump、dig、curl、netstat等工具是调试黄金镜像。5.3 用tcpdump抓包定位网络层问题三步锁定故障点ping通不代表应用层通curl超时不等于网络不通。必须抓包# 在 Pod 内抓包需 netshoot 镜像 kubectl debug pod-a -it --imagenicolaka/netshoot:latest -- sh # 抓所有进出包 tcpdump -i any -w /tmp/pod.pcap port 8080 # 在 Node 上抓包定位 kube-proxy 问题 # 抓 kube-proxy 的 iptables 规则匹配 tcpdump -i any -n -w /tmp/node.pcap port 6443 or port 10250 # 分析 pcap过滤 SYN 未回复连接被丢弃 tcpdump -r /tmp/pod.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | wc -l tcpdump -r /tmp/pod.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | head -5避坑指南tcpdump -i any抓所有接口-i eth0只抓指定网卡port 8080过滤目标端口避免海量包tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn精确匹配 SYN 包三次握手第一步若数量多但无 SYN-ACK 回复说明请求被防火墙或路由丢弃。6. 网络与避坑用mtrethtoolss组合拳终结“网络不稳定”玄学“网络不稳定”是运维最大黑匣子。它可能源于物理层网线松动、链路层MTU 不匹配、网络层ARP 缓存污染、传输层TIME_WAIT 耗尽——必须用工具链逐层排除而非重启网络服务。6.1 用mtr替代tracerouteping一次看清全程丢包点traceroute只显示路径ping只测终点。mtr实时合并两者# 持续探测到 google.com 的路径默认 10 秒 mtr -r -c 10 google.com # 探测到 K8s Service ClusterIP需在 Pod 内执行 mtr -r -c 10 10.96.0.1 # 输出解读 # | Host | Loss% | Snt | Last | Avg | Best | Wrst | StDev | # |------------------|-------|-----|------|------|------|------|-------| # | ??? | 100.0 | 10 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 | ← 第一跳丢失本地网关问题 # | 192.168.1.1 | 0.0 | 10 | 1.2 | 1.5 | 1.1 | 2.3 | 0.4 | ← 本地路由器正常 # | 10.0.2.1 | 50.0 | 10 | 12.3 | 15.6 | 10.2 | 25.1 | 5.2 | ← 核心交换机丢包 50%立刻报修参数说明-r报告模式非交互-c 10发送 10 个包。Loss%是关键指标若某跳Loss% 5%且下一跳Loss% 0%说明问题就在该跳设备。6.2 用ethtool检查物理层揪出“网卡假死”真凶ifconfig显示 UP但实际链路中断。ethtool读取网卡寄存器# 查看网卡状态重点关注 Link detected ethtool eth0 # 输出 # Settings for eth0: # Supported ports: [ TP ] # Supported link modes: 10baseT/Half 10baseT/Full # 100baseT/Half 100baseT/Full # Speed: 1000Mb/s # Duplex: Full # Port: Twisted Pair # PHYAD: 1 # Transceiver: internal # Auto-negotiation: on # Supports Wake-on: d # Current message level: 0x00000007 (7) # Link detected: yes ← 关键若为 no则物理链路断开 # 查看网卡错误计数CRC 错误说明网线或网卡故障 ethtool -S eth0 | grep -E (crc|frame|overrun|missed) # 强制重协商网卡假死时常用 ethtool -r eth0血泪经验某次集群大规模 Pod Pendingkubectl get nodes显示 NotReady。ethtool eth0显示Link detected: no但网线插着。ethtool -r eth0后恢复。根本原因是网卡驱动 bug需升级 kernel 或固件。6.3 用sscat /proc/net/nf_conntrack查 Conntrack 耗尽终结“连接随机失败”K8s 中大量短连接如 Istio sidecar会快速填满 conntrack 表导致新连接被 DROP# 查看 conntrack 表使用率 sysctl net.netfilter.nf_conntrack_count sysctl net.netfilter.nf_conntrack_max # 计算使用率nf_conntrack_count / nf_conntrack_max # 查看 conntrack 表内容按 IP 统计 conntrack -L | awk {print $6} | cut -d -f2 | sort | uniq -c | sort -nr | head -10 # 清空特定 IP 的 conntrack 记录应急 conntrack -D -s 192.168.1.100 # 永久增大 conntrack 表/etc/sysctl.conf net.netfilter.nf_conntrack_max 131072 net.nf_conntrack_max 131072为什么重要nf_conntrack_max默认值通常 65536但在 1000 QPS 的 HTTP 服务下每秒新建连接约 1000 个每个连接在 TIME_WAIT 状态保持 2 分钟理论峰值连接数 120000必然溢出。溢出后iptables -t nat -A POSTROUTING规则失效新连接被 DROP现象就是curl随机超时。7. 面试题背后的「能力验证闭环」用一道题跑通从问题定位到根因修复的完整链路别再把面试题当知识点碎片来背。真正有价值的是选一道题把它变成你个人能力的验证闭环。比如这道高频题“K8s Pod 无法访问外部 HTTPS 服务但能 ping 通 IPcurl -v https://google.com超时”。我要求自己必须完成以下四步才算真正掌握7.1 第一步分层验证用最小命令集排除层级命令预期结果说明网络层kubectl exec pod-a -- ping -c 3 8.8.8.8✅ 通排除路由、DNS 之外的问题DNS 层kubectl exec pod-a -- nslookup google.com✅ 返回 A 记录若失败查 CoreDNS 日志/var/log/coredns.logTLS 层kubectl exec pod-a -- openssl s_client -connect google.com:443 -servername google.com 2/dev/null | grep Verify return code✅Verify return code: 0 (ok)若失败检查 Pod 是否挂载了正确的 CA 证书代理层kubectl exec pod-a -- env | grep -i proxy❌ 无输出若有HTTPS_PROXY需确认代理服务器可达关键点openssl s_client是验证 TLS 握手的金标准-servername启用 SNIgrep Verify return code直接看证书校验结果。env \| grep proxy检查环境变量因为很多公司用 Istio Sidecar 注入代理但 Sidecar 本身可能故障。7.2 第二步抓包确认用tcpdump定位丢包点在 Pod 内执行# 抓 HTTPS 流量 kubectl debug pod-a -it --imagenicolaka/netshoot:latest -- sh tcpdump -i any -w /tmp/https.pcap port 443 # 在另一个终端触发 curl kubectl exec pod-a -- curl -v https://google.com # 分析 pcap tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn | wc -l # 应有 1 个 SYN tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn # 查看 SYN 内容 tcpdump -r /tmp/https.pcap tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn -A | tail -5 # 查看最后 5 行看是否有 SYN-ACK现象与根因若SYN包发出但无SYN-ACK问题在防火墙或中间设备如云厂商安全组若SYN-ACK收到但无ACK问题在 Pod 内核如 conntrack 溢出若ACK发出但无HTTP数据问题在 TLS 层证书、SNI、ALPN 协议。7.3 第三步修复与验证用kubectl patch临时绕过若确认是 Sidecar 代理故障不重启 Pod避免业务中断用kubectl patch临时禁用# 查看当前注入状态 kubectl get pod pod-a -o yaml \| grep -A 5 sidecar.ist p a hrefhttps://download.csdn.net/download/weixin_43616190/86404856 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
