在 Kubernetes 集群的运维过程中，网络问题是最常见也是最复杂的故障类型之一。本文将基于一个真实的生产环境案例，详细介绍如何系统性地排查和解决 K8s 网络问题，涵盖从基础网络连通性到 DNS 解析的完整故障链条。
案例背景 在一个运行 Kubernetes 1.29 的生产集群中，我们遇到了以下问题：
宿主机网络正常，可以访问外网 容器内无法访问外网 使用 Flannel 作为 CNI 网络插件 后续发现容器无法 ping 通 CoreDNS Service IP 通过深入排查，我们发现了一个有趣的现象：DNS 配置错误不仅影响域名解析，还会导致整个 Service 网络不可达。
第一部分：容器外网访问故障排查 1.1 基础网络连通性检查 当容器无法访问外网时，首先需要验证网络的分层连通性：
# 进入问题 Pod 测试网络 kubectl exec -it <pod-name> -- /bin/sh # 测试容器到节点网络 ping 10.244.0.1 # Pod 网关，通常是节点IP # 测试集群内部网络 nslookup kubernetes.default.svc.cluster.local # 测试外网IP连通性 ping 8.8.8.8 # 测试外网DNS解析 nslookup google.com 诊断要点：
如果 ping 节点 IP 不通：CNI 网络问题 如果 ping 外网 IP 不通：NAT/路由问题 如果 IP 通但 DNS 不通：DNS 配置问题 1.Linux 系统提供了丰富的网络工具来帮助管理员监控、诊断和排查网络问题。本文将详细介绍常用的网络工具使用方法，并提供实际的故障排查案例。
概述 网络故障排查是系统管理员的重要技能。掌握以下工具能够帮助快速定位和解决网络问题：
netstat：显示网络连接、路由表和网络接口信息 ss：现代化的 netstat 替代工具，性能更好 lsof：列出打开的文件和网络连接 tcpdump：网络数据包捕获和分析工具 ping/traceroute：网络连通性测试工具 nmap：网络扫描和端口检测工具 netstat 命令详解 基本语法 netstat [选项] 常用选项 选项 描述 -a 显示所有连接和监听端口 -t 显示 TCP 连接 -u 显示 UDP 连接 -n 以数字形式显示地址和端口 -l 只显示监听状态的端口 -p 显示进程 ID 和名称 -r 显示路由表 -i 显示网络接口统计 -s 显示网络统计信息 实用示例 1. 查看所有网络连接 # 显示所有 TCP 和 UDP 连接 netstat -an # 显示所有 TCP 连接，包含进程信息 netstat -antp # 显示所有 UDP 连接，包含进程信息 netstat -anup 2. 查看监听端口 # 查看所有监听端口 netstat -ln # 查看 TCP 监听端口 netstat -lnt # 查看 UDP 监听端口 netstat -lnu # 查看监听端口及对应进程 netstat -lntp 3.Systemd 是现代 Linux 系统的核心组件，负责系统初始化和服务管理。本文将全面介绍 Systemd 和 Systemctl 的使用方法，从基础操作到高级配置。
Systemd 简介 什么是 Systemd Systemd 是 Linux 系统的初始化系统和服务管理器，它替代了传统的 SysV init 系统。主要特点包括：
并行启动：提高系统启动速度 按需启动：只在需要时启动服务 依赖管理：自动处理服务间的依赖关系 统一管理：提供统一的服务管理接口 日志集成：集成了完整的日志系统 核心概念 Unit（单元）：Systemd 管理的基本对象，包括服务、挂载点、设备等 Service（服务）：最常见的 Unit 类型，用于管理后台进程 Target（目标）：类似于传统的运行级别，定义系统状态 Socket（套接字）：用于进程间通信的 Unit Unit 类型 类型 扩展名 描述 Service .service 系统服务 Target .target 多个 Unit 的组合 Socket .socket 套接字 Mount .mount 挂载点 Timer .timer 定时器 Path .path 路径监控 Systemctl 基础命令 服务控制命令 启动和停止服务 # 启动服务 systemctl start <service_name> systemctl start nginx # 停止服务 systemctl stop <service_name> systemctl stop nginx # 重启服务 systemctl restart <service_name> systemctl restart nginx # 重新加载配置（不重启服务） systemctl reload <service_name> systemctl reload nginx # 重新加载或重启（如果不支持 reload） systemctl reload-or-restart <service_name> 服务状态查询 # 查看服务状态 systemctl status <service_name> systemctl status nginx # 检查服务是否运行 systemctl is-active <service_name> # 检查服务是否启用 systemctl is-enabled <service_name> # 检查服务是否失败 systemctl is-failed <service_name> 开机启动管理 # 设置开机启动 systemctl enable <service_name> systemctl enable nginx # 取消开机启动 systemctl disable <service_name> systemctl disable nginx # 启用并立即启动 systemctl enable --now <service_name> # 禁用并立即停止 systemctl disable --now <service_name> # 屏蔽服务（完全禁用） systemctl mask <service_name> # 取消屏蔽 systemctl unmask <service_name> 系统管理命令 系统状态和信息 # 查看系统状态 systemctl status # 列出所有服务 systemctl list-units --type=service # 列出所有启用的服务 systemctl list-unit-files --type=service --state=enabled # 列出失败的服务 systemctl --failed # 查看启动时间 systemd-analyze # 查看启动时间详情 systemd-analyze blame # 查看启动链 systemd-analyze critical-chain 系统控制 # 重启系统 systemctl reboot # 关闭系统 systemctl poweroff # 挂起系统 systemctl suspend # 休眠系统 systemctl hibernate # 进入救援模式 systemctl rescue # 进入紧急模式 systemctl emergency 配置管理 # 重新加载 systemd 配置 systemctl daemon-reload # 重新执行所有生成器 systemctl daemon-reexec # 清理失效的符号链接 systemctl reset-failed 服务状态详解 服务状态类型 状态 描述 active (running) 服务正在运行 active (exited) 服务已成功执行并退出 active (waiting) 服务正在等待事件 inactive (dead) 服务未运行 activating 服务正在启动 deactivating 服务正在停止 failed 服务启动失败 启用状态类型 状态 描述 enabled 开机启动已启用 disabled 开机启动已禁用 static 服务不能被启用，只能被其他服务依赖 masked 服务被屏蔽，无法启动 indirect 服务被其他启用的服务间接启用 自定义服务配置 服务文件位置 # 系统服务目录（优先级高） /etc/systemd/system/ # 软件包安装的服务目录 /lib/systemd/system/ /usr/lib/systemd/system/ # 用户服务目录 ~/.一、MySQL 主从复制概述 MySQL 主从复制（Replication）是保障数据库 高可用、读写分离、数据冗余与灾备 的核心机制。 它的本质是：主库记录日志 → 从库拉取日志 → 从库重放日志，最终实现数据同步。
1.1 应用场景 读写分离：主库写、从库读，缓解单点压力 异地容灾：主库崩溃时，从库快速接管 数据备份：从库承担备份任务，减轻主库负担 数据分析：从库专门用于报表和数据分析 版本升级：通过主从复制实现平滑升级 1.2 MySQL 版本演进对比 特性 MySQL 5.6 MySQL 5.7 MySQL 8.0 GTID 基础支持 完善稳定 增强功能 多线程复制 基于库 基于事务组 基于写集合 Crash Safe 部分支持 完全支持 增强稳定性 在线DDL 有限支持 大幅改进 Instant DDL Clone插件 ❌ ❌ ✅ Redo Log 传统架构 优化改进 重新设计 复制过滤 基础功能 增强功能 更灵活 二、MySQL 5.7 主从复制核心特性 2.1 GTID（全局事务标识符） MySQL 5.7 中 GTID 已经非常成熟稳定，是生产环境的首选：
GTID 优势：MySQL 主从同步是保证数据高可用性的重要技术。当主从同步出现问题时，需要通过重新同步来修复。本文将详细介绍修复流程，明确标注每个命令的执行位置。
环境说明 主库服务器：10.244.1.10（Master） 从库服务器：从库IP（Slave） 数据库：mybook 同步方式：基于 GTID 的主从同步 第一步：主库操作 - 备份数据 1.1 登录主库服务器并执行备份 执行位置：主库服务器（10.244.1.10）
# 1. SSH 登录主库服务器 ssh root@10.244.1.10 # 2. 执行 mysqldump 备份命令 mysqldump --single-transaction \ --routines \ --triggers \ --master-data=2 \ --set-gtid-purged=ON \ --databases mybook \ -u root -p > /tmp/mybook_backup_$(date +%Y%m%d_%H%M%S).sql # 输入 MySQL root 密码后等待备份完成... 参数说明：
参数 说明 --single-transaction 保证备份的一致性，适用于 InnoDB 表 --routines 备份存储过程和函数 --triggers 备份触发器 --master-data=2 在备份文件中记录二进制日志位置信息（注释形式） --set-gtid-purged=ON 在备份文件中包含 GTID 信息 --databases mybook 指定要备份的数据库名称 -u root -p 使用 root 用户连接，提示输入密码 1.在 VMware Workstation 17 Pro 中设置共享主机网络并使用 192.168.9.0/24 网段，您可以通过以下步骤配置：
1. 使用自定义网络 1.1. 配置虚拟网络编辑器 打开 VMware Workstation 点击菜单栏 编辑 → 虚拟网络编辑器 如果需要管理员权限，点击 更改设置 1.2. 创建或修改网络 选择一个未使用的网络（如 VMnet8 或 VMnet2） 选择 NAT 模式（共享主机网络连接） 在 子网 IP 中设置为：192.168.9.0 子网掩码 设置为：255.255.255.0 取消勾选 使用本地 DHCP 服务将 IP 地址分配给虚拟机（如果您想手动分配IP） 1.3. 配置 NAT 设置 点击 NAT 设置 网关 IP 通常设置为：192.168.9.1 确认设置后点击 确定 1.4. 应用到虚拟机 选择您的虚拟机 右键点击 → 设置 选择 网络适配器 网络连接 选择您刚才配置的网络（如 VMnet8） 点击 确定 2. 虚拟机内部网络配置 启动虚拟机后，配置网络设置：1. MongoDB简介 1.1. 什么是MongoDB？ MongoDB是一个基于分布式文件存储的NoSQL数据库，由C++编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB的特点：
面向文档存储（Document-Oriented） 模式自由（Schema-Free） 支持动态查询 支持完全索引 支持复制和故障恢复 使用高效的二进制数据存储，包括大型对象（如视频等） 自动处理负载均衡 支持Python、PHP、Ruby、Java、C、C#、Javascript、Perl及C++语言的驱动程序 1.2. MongoDB vs 关系型数据库 特性 MongoDB 关系型数据库 数据模型 文档模型 关系模型 表结构 灵活的Schema 固定的Schema 查询语言 MongoDB查询语法 SQL 事务支持 支持ACID事务 强ACID事务 扩展方式 水平扩展 主要垂直扩展 存储格式 BSON 行列存储 2. 核心概念 2.1. 基本术语对比 关系型数据库 MongoDB 数据库 数据库(Database) 表(Table) 集合(Collection) 行(Row) 文档(Document) 列(Column) 字段(Field) 索引 索引 表连接 嵌入文档或引用 主键 主键（MongoDB提供了默认的_id字段） 2.2. BSON数据类型 MongoDB使用BSON（Binary JSON）格式存储数据，支持以下数据类型：
// 基本数据类型示例 { "name": "张三", // String "age": 25, // Number (Int32) "salary": 8500.1. 第一部分：基础概念 1.1. Q1: 什么是InnoDB Buffer Pool？它的作用是什么？ 回答： Buffer Pool是InnoDB存储引擎在内存中维护的一个缓存区域，主要作用包括：
数据缓存：缓存从磁盘读取的数据页和索引页 减少磁盘I/O：热数据保持在内存中，避免频繁磁盘访问 提升性能：内存访问速度比磁盘快几个数量级 缓冲写操作：通过脏页机制，批量写入磁盘 面试官点评：✅ 回答全面，涵盖了主要功能点
1.2. Q2: Buffer Pool的内部结构是怎样的？ 回答： Buffer Pool采用链表和哈希表的混合结构：
Buffer Pool 结构： ┌─────────────────┐ │ Hash Table │ ← 快速定位页面 ├─────────────────┤ │ LRU List │ ← 页面置换算法 │ ┌─ Young ────┐ │ │ │ (新/热数据) │ │ │ └─────────────┘ │ │ ┌─ Old ─────┐ │ │ │ (旧数据) │ │ │ └─────────────┘ │ ├─────────────────┤ │ Flush List │ ← 脏页管理 ├─────────────────┤ │ Free List │ ← 空闲页面 └─────────────────┘ 关键组件：1. 前言 InnoDB Buffer Pool 是 MySQL 性能优化中最关键的参数之一。设置得当，可以大幅提升数据库性能；设置不当，反而会拖累系统。本文将深入解析如何科学地设置 innodb_buffer_pool_size。
2. 什么是 Buffer Pool？ Buffer Pool 是 InnoDB 存储引擎在内存中维护的一个缓存区域，用于缓存：
数据页面：表中的行数据 索引页面：B+树索引结构 插入缓冲：辅助索引的插入操作 锁信息：行锁和表锁信息 3. 核心设置原则 3.1. 基础计算公式 # 通用公式 Buffer Pool Size = (Working Set Size × 1.2~1.5) + Growth Buffer # 详细计算 Working Set Size = 热数据大小 + 热索引大小 Growth Buffer = 预期1-2年的数据增长量 3.2. 系统内存分配规则 # 专用数据库服务器 Buffer Pool = 总内存 × 70%~80% # 混合应用服务器 Buffer Pool = 总内存 × 50%~60% # 容器化环境 Buffer Pool = 容器内存 × 60%~70% 4.1. 你遇到过这样的坑吗？ 某天你打开监控，看见：
Pod：mysql-prod-xxxx 内存使用率：96.25% 容器资源限制：8Gi innodb_buffer_pool_size：6Gi 你心想：6G + 一点点堆栈，不就够了？怎么可能用掉 96%？ 再一看：
SHOW PROCESSLIST; -- 200+ 个连接，全部 Sleep 状态，持续几千秒未释放 ✅ Bingo：连接相关的内存拖垮了你的数据库。
2. MySQL 总内存使用结构图 MySQL 启动后，内存分为两大部分：
MySQL 总内存 ≈ 全局共享内存（Global memory） + 每连接私有内存（Per-connection memory） 2.1. ️全局共享内存（常驻不变） 参数 功能 说明 innodb_buffer_pool_size 缓存数据页、索引页 5.7 和 8.0 核心参数 innodb_log_buffer_size redo log 写入缓冲 较小，一般 16~64MB key_buffer_size MyISAM 缓冲 只用于 MyISAM，InnoDB 忽略 query_cache_size 查询缓存 8.0 已移除，5.7 建议禁用 table_open_cache 打开表的缓存 每张表 8K~16K 内存不等 2.2. ️每连接私有内存（连接越多越恐怖） 每个连接都会分配一块独立的内存空间，用于执行语句的临时运算。