Prometheus ServiceMonitor 无法发现指标问题排查与解决方案

December 9, 2025

字数: 715 · 阅读: 4 分钟 · 访问: -

问题现象在 Kubernetes 集群中部署了 kube-prometheus-stack 和 ingress-nginx 后，发现 Prometheus 无法抓取 ingress-nginx 的 metrics 指标： ✅ 在容器内可以直接访问 metrics 端点 ✅ ServiceMonitor 配置正确 ✅ Service 端口配置正确 ❌ Prometheus UI 的 Targets 页面找不到 ingress-nginx 相关目标 # 在 busybox 容器中测试 metrics 端点正常 kubectl run busybox --rm -it --image=busybox -- sh curl -sS ingress-nginx-controller-metrics.ingress-nginx:10254/metrics | grep nginx_ingress_controller # 输出正常，说明 metrics 端点工作正常问题原因 Prometheus Operator 使用标签选择器（Label Selector）来决定监控哪些 ServiceMonitor。默认情况下，kube-prometheus-stack 要求 ServiceMonitor 必须包含 release: kube-prometheus-stack 标签。查看 Prometheus 配置：

MySQL InnoDB 紧急修复指南

December 4, 2025

字数: 309 · 阅读: 2 分钟 · 访问: -

一、什么是 innodb_force_recovery？当 InnoDB 引擎因为损坏、undo/redo 异常、元数据不一致而无法启动时，你可以使用： innodb_force_recovery = <0~6> 让 MySQL “带病启动”，然后尽快把数据导出来。它不是修复器，它是：给你一次只启动、不执行危险操作的机会，让你把数据抢救出来。二、六个等级：从温柔到残酷 innodb_force_recovery 有 0–6 共七个值（0 为正常模式），越高越危险，越可能导致数据丢失。下面我做一份你可以直接贴到办公桌前的表：等级含义风险常见场景 0 正常无风险 MySQL 正常恢复或不需要强制 1 跳过后台清理（最安全）极低崩溃恢复失败、InnoDB 卡住 2 禁止主线程运行，跳过一些后台任务低 undo 回滚卡死 3 关闭 redo 日志应用（危险）中高 redo 损坏，无法启动 4 忽略 undo 日志（很危险）高 undo 损坏、无法回滚事务 5 禁止检查线程、跳过大部分恢复很高数据字典存在问题 6 跳过绝大多数 InnoDB 处理（灾难级）极高最后孤注一掷的方式请记住：3 以上就是“带血的刀”，必须谨慎。 6 是“最后的绝唱”。启动起来但不要对其做任何写入。三、什么时候该用？判断标准很简单如果你看到：

Docker Buildx v0.30.1 安装与使用全指南（2025 最新版）

November 28, 2025

字数: 300 · 阅读: 2 分钟 · 访问: -

容器世界日新月异，而镜像构建也在不断进化。从 Classic Builder 到 BuildKit，再到 Buildx，Docker 的构建体系已经彻底迈入现代时代。 Buildx v0.30.1 是当前官方最新稳定版，它为镜像构建带来了跨平台、加速、缓存、并行等“现代构建能力”。本文将从安装、启用、验证到多平台构建全面梳理 Buildx 的最佳实践。 🌟 1. 什么是 Docker Buildx？ Docker Buildx 是 Docker 官方基于 BuildKit 的新一代构建工具。相比传统 docker build，它拥有： ✅ 多平台构建（AMD64 / ARM64 / ARMv7 / PPC64） ✅ 完整的 BuildKit 支持 ✅ 构建缓存（local/registry/inline） ✅ 分布式构建驱动（container / kubernetes） ✅ 并行构建与更快速度 ✅ 导出 OCI 镜像格式 ✅ CI/CD 完整支持一句话： buildx 是以后构建 Docker 镜像的唯一正确方式。目前最新版本为 v0.30.1（2025）。 🌟 2. 检查你的 Docker 是否已内置 buildx Docker Desktop（Windows/macOS）自带 Buildx，你可以先试：

Docker Daemon 配置代理完整指南

November 28, 2025

字数: 209 · 阅读: 1 分钟 · 访问: -

1. 问题背景当 Docker daemon 需要访问外网资源（如 Docker Hub）时，但本地只能通过代理访问，直接运行 docker login 或 docker pull 会出现连接超时错误。这是因为设置在 shell 中的代理环境变量对 Docker daemon 服务无效。 Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 2. 解决方案 2.1. 第一步：创建 Docker daemon 配置目录 sudo mkdir -p /etc/systemd/system/docker.service.d 2.2. 第二步：编辑代理配置文件 sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf 在文件中添加以下内容： [Service] Environment="HTTP_PROXY=http://PROXY_HOST:PROXY_PORT" Environment="HTTPS_PROXY=http://PROXY_HOST:PROXY_PORT" Environment="NO_PROXY=localhost,127.0.0.1" 参数说明： HTTP_PROXY - HTTP 连接代理地址 HTTPS_PROXY - HTTPS 连接代理地址 NO_PROXY - 不经过代理的地址列表（本地地址无需代理） 2.

深入理解 Linux conntrack：原理、用途、调优与生产实践

November 26, 2025

字数: 470 · 阅读: 3 分钟 · 访问: -

一、什么是 conntrack？ conntrack（全称 Connection Tracking，连接跟踪）是 Linux 内核 Netfilter 框架中的一个核心子系统，用于跟踪和记录主机上所有网络连接的状态信息。它不是用户态程序，而是内核模块（nf_conntrack），为有状态防火墙、NAT（网络地址转换）、负载均衡等高级网络功能提供基础支持。简单来说： conntrack 让 Linux 能“记住”每一个网络连接，而不仅仅处理孤立的数据包。二、conntrack 能做什么？有什么用？ ✅ 核心能力功能说明有状态包过滤允许 iptables 基于连接状态（如 ESTABLISHED, NEW）做策略，例如：“只放行已建立连接的返回流量”。 NAT 支持实现 SNAT（源地址转换）和 DNAT（目标地址转换）的关键。没有 conntrack，NAT 无法知道如何将返回包正确转发回原始客户端。连接状态管理跟踪 TCP/UDP/ICMP 等协议的连接生命周期，自动清理超时连接。安全防护拦截不符合连接状态的异常包（如伪造的 RST 包）。 🌐 典型应用场景 Docker / Kubernetes 网络：容器端口映射（-p 8080:8080）依赖 DNAT + conntrack。云服务器 NAT 网关：私有网络访问公网需 SNAT。 Web 服务器防火墙：仅允许 80/443 入站，但放行所有出站响应。透明代理、LVS 负载均衡：依赖连接状态做流量调度。三、如何安装和使用 conntrack 工具？虽然 conntrack 内核模块默认随系统加载，但用户态工具需单独安装。 🔧 安装（以主流 Linux 发行版为例） # Ubuntu / Debian sudo apt install conntrack # CentOS / Rocky / AlmaLinux sudo yum install conntrack-tools # 或 sudo dnf install conntrack-tools 🛠️ 常用命令命令作用 conntrack -L 列出当前所有被跟踪的连接 conntrack -E 实时监控连接事件（新建、更新、销毁） conntrack -S 显示各 CPU 的 conntrack 统计信息 conntrack -C 显示当前 conntrack 表中的连接总数 conntrack -D -s 192.

Linux ip 命令完全指南

November 25, 2025

字数: 1396 · 阅读: 7 分钟 · 访问: -

目录简介基础语法命令分类详解日常运维操作故障排查实战最佳实践简介 ip 命令是 Linux 系统中用于网络配置和管理的现代化工具,属于 iproute2 工具包。它是传统 ifconfig、route、arp 等命令的替代品,功能更强大、更灵活。为什么使用 ip 命令? 功能全面: 统一管理网络接口、路由、隧道、策略路由等输出清晰: 结构化的输出格式,便于脚本解析持续维护: 活跃开发,支持最新的内核特性性能更好: 直接与内核 netlink 接口通信基础语法 ip [ OPTIONS ] OBJECT { COMMAND | help } 常用选项 (OPTIONS) -4 或 -6: 指定 IPv4 或 IPv6 -s: 显示统计信息 (statistics) -d: 显示详细信息 (details) -c: 彩色输出 -br: 简洁输出 (brief) -j: JSON 格式输出 -p: 美化输出 (pretty print) 对象类型 (OBJECT) 对象简写说明 link l 网络设备 (网卡) address addr/a IP 地址 route r 路由表 neighbor neigh/n ARP 或 NDISC 缓存 rule ru 路由策略 tunnel t IP 隧道 maddress maddr 组播地址 netns netns 网络命名空间命令分类详解 1.

Kubernetes 网络深度解析：从入门到实战

November 3, 2025

字数: 8371 · 阅读: 40 分钟 · 访问: -

从零开始理解 K8s 网络模型，深入 Flannel 和 Calico 原理，掌握网络故障排查与解决方案目录 Kubernetes 网络基础 Pod 间通信原理 Service 与 DNAT 机制 Flannel 网络方案详解 Calico 网络方案详解网络故障排查实战复杂场景解决方案 1. Kubernetes 网络基础 1.1 K8s 网络模型的三大原则 Kubernetes 采用扁平网络模型（Flat Network Model），核心原则： ✅ 原则 1：所有 Pod 可以在不使用 NAT 的情况下与其他 Pod 通信 ✅ 原则 2：所有节点可以在不使用 NAT 的情况下与所有 Pod 通信 ✅ 原则 3：Pod 看到的自己的 IP 和其他 Pod 看到的 IP 是同一个这意味着： Pod 之间是"直连"的（IP 层面）没有复杂的 NAT 转换网络拓扑清晰简单 1.2 网络组件架构 ┌─────────────────────────────────────────────────────┐ │ Application │ │ (你的应用) │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Service (ClusterIP) │ │ 虚拟 IP + 负载均衡 (kube-proxy) │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Pod Network (CNI) │ │ Flannel / Calico / Cilium 等 │ └──────────────────┬──────────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────────┐ │ Node Network │ │ 物理网络 / 云厂商 VPC │ └─────────────────────────────────────────────────────┘ 1.

OpenYurt 完整使用手册 - 从入门到实践

October 29, 2025

字数: 1743 · 阅读: 9 分钟 · 访问: -

目录什么是 OpenYurt 核心概念与架构环境准备快速开始集群部署详解边缘节点管理边缘应用部署进阶特性运维与监控故障排查最佳实践什么是 OpenYurt 简介 OpenYurt 是阿里云开源的边缘计算平台，基于原生 Kubernetes 构建，专门为边缘计算场景设计。它将 Kubernetes 的能力无缝延伸到边缘端，使云端和边缘能够协同工作。核心优势非侵入式：无需修改 Kubernetes 核心代码云边协同：支持云端统一管理边缘资源边缘自治：网络断连时边缘节点可独立运行原生兼容：完全兼容 Kubernetes API 和生态轻量化：针对边缘资源受限场景优化适用场景物联网 (IoT)：设备管理、数据采集 CDN 边缘节点：内容分发、边缘缓存智慧城市：交通监控、视频分析工业互联网：设备监控、生产管理 5G MEC：边缘计算、低延迟应用核心概念与架构整体架构 ┌─────────────────────────────────────────────────┐ │ Cloud (云端) │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ Kube-APIServer│ │ YurtHub │ │ │ └──────────────┘ │ (云端代理) │ │ │ ┌──────────────┐ └──────────────┘ │ │ │ YurtManager │ ┌──────────────┐ │ │ │ (控制器) │ │ YurtIoTDock │ │ │ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────────────┘ │ │ 不稳定网络 │ ┌─────────────────────────────────────────────────┐ │ Edge (边缘) │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ YurtHub │ │ Kubelet │ │ │ │ (边缘代理) │ └──────────────┘ │ │ │ (缓存/过滤) │ ┌──────────────┐ │ │ └──────────────┘ │ 容器运行时 │ │ │ └──────────────┘ │ └─────────────────────────────────────────────────┘ 核心组件 1.

Kubernetes 集群 DNS 解析与网络问题排查完整指南

October 28, 2025

字数: 1493 · 阅读: 8 分钟 · 访问: -

文章概述本文记录了一次完整的 Kubernetes 集群网络问题排查过程，从容器内 DNS 解析失败，到发现 RBAC 权限缺失，再到解决跨节点 Pod 网络不通的完整历程。适用于 Kubernetes 1.29 版本，使用 Flannel 作为 CNI 插件。目录问题现象排查思路问题一：kube-proxy RBAC 权限缺失问题二：flannel RBAC 权限缺失问题三：双 Pod CIDR 共存导致路由问题故障总结与预防 DNS 问题排查通用方法论问题现象环境信息 Kubernetes 版本: 1.29 网络插件: Flannel (VXLAN 模式) 集群规模: 5 节点（3 master + 2 GPU worker）故障时间: 已运行 n 天后突然出现初始症状容器内无法进行 DNS 解析和服务访问： # 在容器内测试 $ ping coredns.kube-system ping: bad address 'coredns.kube-system' $ nc -zv coredns.

Redis 参数配置详解与优化指南

October 17, 2025

字数: 2125 · 阅读: 10 分钟 · 访问: -

概述 Redis 作为高性能的内存数据库，其性能表现很大程度上取决于参数配置的合理性。本文将详细介绍 Redis 的核心参数，并针对不同的部署架构（单机、主从、哨兵、集群）提供优化配置建议。一、Redis 核心参数详解 1.1 基础配置参数 bind 说明：指定 Redis 监听的网络接口默认值：127.0.0.1 建议：生产环境建议绑定内网 IP，避免使用 0.0.0.0 bind 192.168.1.100 port 说明：Redis 监听端口默认值：6379 建议：可修改为非默认端口以提高安全性 port 6379 protected-mode 说明：保护模式，防止未授权访问默认值：yes 建议：生产环境必须开启，配合 requirepass 使用 protected-mode yes requirepass 说明：设置访问密码默认值：无建议：生产环境必须设置强密码 requirepass YourStrongPassword@2025 timeout 说明：客户端空闲多少秒后关闭连接，0 表示禁用默认值：0 建议：设置 300 秒，避免僵尸连接 timeout 300 tcp-keepalive 说明：TCP 连接保活时间（秒）默认值：300 建议：保持默认或设置为 60 tcp-keepalive 60 1.2 内存管理参数 maxmemory 说明：Redis 最大内存使用量默认值：0（不限制）建议：设置为物理内存的 60%-70%，留出空间给系统和持久化 maxmemory 4gb maxmemory-policy 说明：内存淘汰策略可选值： noeviction：不淘汰，写入失败（默认） allkeys-lru：对所有 key 使用 LRU 算法淘汰 volatile-lru：对设置了过期时间的 key 使用 LRU 淘汰 allkeys-random：随机淘汰所有 key volatile-random：随机淘汰有过期时间的 key volatile-ttl：淘汰即将过期的 key allkeys-lfu：对所有 key 使用 LFU 算法淘汰 volatile-lfu：对设置了过期时间的 key 使用 LFU 淘汰建议：根据业务场景选择，缓存场景推荐 allkeys-lru maxmemory-policy allkeys-lru maxmemory-samples 说明：LRU/LFU 算法采样数量默认值：5 建议：增加到 10 可提高准确性，但会增加 CPU 开销 maxmemory-samples 10 1.