欢迎来到我的博客 👋

Cloudflare + Hugo + Decap CMS 搭建静态博客 这篇文章记录一下我的轻量级博客方案： Hugo + GitHub + Cloudflare Pages + Decap CMS 它不需要 PHP、MySQL，也不需要自己维护服务器，但依然可以拥有类似 WordPress 的网页后台，用浏览器直接发布 Markdown 文章。 一、整体架构 最终结构如下： 浏览器 │ ▼ Cloudflare │ ▼ Hugo 静态网站 ▲ │ 自动构建 GitHub ▲ │ Decap CMS │ ▼ /admin/ 后台 文章保存到 GitHub，Cloudflare 检测到提交后自动执行 Hugo 构建并发布。 二、本地创建 Hugo 博客 安装 Hugo Extended 后创建站点： hugo new site blog cd blog 添加主题，例如 PaperMod： ...

一、为什么需要这次实验？ 本篇解决监控平台的下一层问题：指标是否真的被发现并采集？报警表达式何时生效？告警最终是否抵达 Alertmanager？ 实验目标： 区分 Service、ServiceMonitor、Target、PrometheusRule、Alertmanager 的职责； 在 demo 命名空间部署独立的可控 /metrics 测试端点（不修改正在使用的 nginx-demo）； 在 monitoring 命名空间通过 ServiceMonitor 跨命名空间发现测试服务； 验证 Targets UP、自定义指标、PrometheusRule 的 Pending → Firing → Resolved； 了解告警规则与 Alertmanager 路由、通知之间的区别； 保存可复现的验收命令、截图及清理方式。 状态说明：以下是已编写并完成本地 YAML/脚本检查的可执行实验方案，不是对当前集群实时完成情况的断言。项目中的 #05 应在实际验证后再将 draft 改为 false。 二、当前实验环境 项目 环境信息 Kubernetes v1.28.15 管理节点 h11（192.168.6.11） 应用节点 h12，nativeopslab.io/role=app 可观测性节点 h15，nativeopslab.io/role=observability 监控命名空间 monitoring 已有 Demo demo/nginx-demo，已有 2 个运行副本（此前验收） 新建实验服务 demo/nativeopslab-metrics-demo，HTTP 9105 Prometheus / Grafana / Alertmanager 核心组件在 h15，已有 PVC Bound Helm Release monitoring（按此前部署记录） Chart 版本 此系列文档以 kube-prometheus-stack 65.8.1 为配置参考；以现场 helm list -n monitoring 为准 本篇不执行 Helm 升级，不改变 OpenEBS PVC，不删除已经运行的监控 Pod。 ...

一、为什么监控平台需要持久化？ kubectl get pods 看起来一切正常，并不等于监控系统具备可靠性。尤其是第一次用 Helm 安装 kube-prometheus-stack 时，常见三个问题： Prometheus 重建后历史时序数据消失：因为使用了临时存储，或者新的实例没有挂载原来的 PVC。 Grafana 修改的配置与自建 Dashboard 丢失：Grafana 默认数据库文件需要持久化存储，不能只依靠 Pod 文件系统。 Alertmanager 静默记录丢失：告警路由配置可来自 Secret，但 Silences 等运行状态仍需存储。 所以本篇目标不是简单“让 Pod Running”，而是建立一套 Helm 配置有版本、核心服务可控调度、PVC 可检查、Pod 重建后数据可验证 的可复现流程。 特别注意：持久化 ≠ 跨节点高可用。openebs-hostpath 属于本地存储：Pod 在同一节点重建可重新挂载原数据，但节点磁盘故障、误删 PVC/PV 或重建节点可能导致数据丢失。本文方案定位为单节点实验室监控持久化，不是多副本生产存储方案。 二、实验环境和目标架构 节点 地址 角色 h11 192.168.6.11 Kubernetes control-plane、执行 Helm 和 kubectl h12 192.168.6.12 业务工作节点 h13 192.168.6.13 Storage/Stateful 工作节点 h14 192.168.6.14 NFS Server + 工作节点 h15 192.168.6.15 Observability 工作节点 h16 192.168.6.16 集群外实验和访问测试客户端 本篇规划： ...

一、为什么 CPU 不高，服务器仍可能很慢？ 运维中经常遇到三种看似矛盾的现象： 一个进程显示 CPU 100%，但服务器整体 CPU 使用率并不高。 Load Average 很高，而 top 中的 CPU 空闲比例仍然很大。 CPU 不忙，应用响应却很慢，磁盘延迟、等待队列或其他依赖可能成为瓶颈。 这些现象并不矛盾，因为 CPU 使用率、Load Average 和磁盘 I/O 延迟测量的是不同事情。 本文沿用 NativeOpsLab 的三组实验： 实验 研究问题 核心工具 Day 8 / #001 单核 100%，是否等于整机 CPU 满载？ stress-ng、mpstat、pidstat Day 9 / #002 Load 高但 CPU 不高，为什么？ uptime、vmstat、mpstat、ps Day 10 / #003 CPU 不忙，如何判断是否是磁盘 I/O 问题？ fio、iostat、vmstat、pidstat 最终目标不是背几个命令，而是能通过指标判断：任务究竟在执行、排队，还是等待其他资源。 二、实验环境和安全边界 本系列使用 NativeOpsLab 的集群外实验机 h16（Rocky Linux 9），不在 Kubernetes 控制面 h11，也不在承载服务的 h12～h15 上制造压力。 ...

一、为什么 Kubernetes 需要监控平台？ kubectl get pods 能显示当前状态，但无法回答以下问题：过去一小时 CPU 为什么升高？哪个节点内存持续减少？Pod 为什么重启？一次故障发生前有哪些异常信号？告警是否真的进入通知处理链路？ 这次部署三大核心组件： Prometheus：定时抓取、保存时序指标，并通过 PromQL 查询。 Grafana：用 Dashboard 呈现节点、Pod、容器等指标。 Alertmanager：接收 Prometheus 产生的告警，执行分组、去重、静默与路由；没有配置接收渠道时，不等于已经能发邮件或消息。 通过 kube-prometheus-stack Helm Chart，一次安装 Prometheus Operator、Prometheus、Alertmanager、Grafana、kube-state-metrics、node-exporter，以及相关 ServiceMonitor、PrometheusRule 和 Dashboard。 二、实验环境与部署规划 主机 地址 角色 h11 192.168.6.11 Kubernetes control-plane / 运维入口 h12 192.168.6.12 App Worker；Nginx Demo 已部署 h13 192.168.6.13 Storage / Stateful Worker h14 192.168.6.14 NFS Server + Worker h15 192.168.6.15 Observability Worker；放置主要监控实例 h16 192.168.6.16 集群外测试与压测客户端 Kubernetes：v1.28.15 CNI：Cilium / Hubble 存储：openebs-hostpath（默认，ReadWriteOnce、WaitForFirstConsumer） Namespace：monitoring Helm Release：monitoring 本文固定 Chart：kube-prometheus-stack 65.8.1 选择此固定版本用于旧版本 Kubernetes 实验室，而不是无条件安装最新 Chart。这个 Chart 的 Chart.yaml 声明 kubeVersion: ">=1.19.0-0"；版本约束满足不等于所有镜像、CRD 和监控目标都已经通过现场验收。 ...

如果把服务器比作高速公路，正常用户就是有序通行的汽车；DDoS 攻击则像大量车辆同时涌向收费站，把道路、收费窗口甚至整座城市的入口堵住。 这时，IPTables 就像服务器上的交通警察：可以识别异常状态、限制部分来源的通行速度，并对可疑连接采取丢弃措施。 但交警也有能力边界：如果城市外的高速入口已经被堵死，收费站再严格也无法恢复上游道路的通行能力。这就是主机防火墙和 CDN / 云端 DDoS 清洗之间的区别。 这篇文章以 Linux 服务器为例，介绍 IPTables 的防护思路、可在实验机验证的规则，以及上线前必须考虑的误伤、IPv6、持久化和回滚问题。 实验与生产边界：以下 IPTables 配置仅供独立测试环境演练。不要直接复制到正在运行 firewalld、nftables 或 Kubernetes 网络组件的生产宿主机。规则顺序、现有防火墙策略和管理入口不同，都可能导致业务中断。 一、先搞清楚：我们在防哪种 DDoS？ 攻击类型 常见现象 主机侧能做什么 更合适的防护层 SYN Flood 大量 TCP 建连请求，连接状态异常 针对 SYN 报文限速、观察内核统计 L3/L4 边缘清洗与主机协同 UDP Flood UDP 报文激增，带宽或处理能力被占满 关闭非必要端口、按业务限速 上游运营商、云端清洗 HTTP CC 大量看似正常的 HTTP 请求，接口耗时上升 监控连接与流量，但不能精确识别 URL 请求 Nginx、WAF、CDN、应用层限流 连接耗尽 某些来源建立大量并发连接 connlimit、连接数监控 代理层和主机层联合控制 关键区别：IPTables 主要看到 IP、端口、TCP 标志与连接状态；真正的 HTTP 请求路径、Cookie、用户行为通常应在 Nginx 或 WAF 层判断。 二、动手之前：先确认系统现状 以 Rocky Linux 9 / RHEL 9 系列为例，建议先检查系统实际使用哪套防火墙： ...

在 Linux 运维工作中，命令记得多并不等于排障快。真正重要的是：知道什么时候运行哪条命令、该看输出中的什么指标，以及怎样避免把排查操作变成新的故障。 这篇文章保留八大常见分类，补充现代 Linux 系统里更实用的命令和生产环境注意事项。命令以 Rocky Linux 9 为主要示例，同时说明 Ubuntu/Debian 的差异；涉及故障的演示均明确区分“已验证的实验”和“模拟排查场景”。 使用范围： Rocky Linux 9 / RHEL 系、Ubuntu Server 等采用 systemd 的现代 Linux。部分命令依赖额外安装的软件包。在生产系统执行停止服务、删除文件、升级软件、修改时间、网络或权限之前，请先评估影响、备份并准备回滚方案。 一、系统信息查看命令 这类命令适合登录服务器后的第一轮巡检：先搞清楚“这是什么机器、什么系统、负载和资源是什么状态”。 1. 系统版本、内核与硬件 命令 作用 重点 uname -a 显示内核、架构等综合信息 排查内核/驱动兼容性 uname -r 只查看运行中的内核版本 与已安装内核区分 cat /etc/os-release 查看发行版与版本 Rocky / Ubuntu 不同命令路径 hostnamectl 查看主机名、系统与内核 systemd 环境推荐 hostname 当前主机名 只读操作 lscpu CPU 架构与逻辑 CPU 核心数、虚拟化信息 nproc 当前进程可用的处理器数量 结合 CPU 配额判断 systemd-detect-virt 判断虚拟化或容器环境 KVM / VMware / container 等 who、w 当前登录用户与活动 排查异常会话 uname -r cat /etc/os-release hostnamectl lscpu | head -n 30 nproc 主机名修改： hostname newname 在不少系统上只是临时设置；现代系统优先使用 hostnamectl set-hostname newname。在 Kubernetes 节点上修改主机名之前必须评估 kubelet、证书与 Node 身份的影响，不要直接照搬。 ...

在 Kubernetes 中部署应用时，我们经常会使用下面的命令检查运行状态： kubectl get pods 看到： NAME READY STATUS RESTARTS nginx-demo-xxxxxxxxxx-xxxxx 1/1 Running 0 很多人可能会认为： Pod 已经 Running，服务应该可以访问了。 但实际上，Pod Running 只能说明 Pod 已经进入运行阶段，并不能保证业务能够正常响应，更不意味着集群外部的客户端能够访问应用。 一个从 Kubernetes 集群外部发起的 HTTP 请求，可能涉及： DNS 域名解析 Linux 路由与 ARP LoadBalancer IP Cilium Ingress / Envoy Kubernetes Service EndpointSlice Pod 网络 应用监听端口 NetworkPolicy 任何一个环节出现问题，都可能导致访问失败。 最近我在重建 NativeOpsLab Kubernetes 实验室时，部署了一个 Nginx Demo，并使用 Cilium Ingress 将应用发布到局域网。 这次实验最终成功完成了集群外访问验收。 本文将结合真实实验结果，记录完整访问过程，并整理一套可以复用的 Kubernetes 网络排查方法。 实验说明： 本次没有实际发生外部访问失败。文中的故障现象、HTTP 错误码及对应解决思路属于排查参考，真实实验结果以命令输出和截图为准。 一、实验环境介绍 这次实验运行在 Rocky Linux 9 和 Kubernetes v1.28.15 环境中。 ...

做运维时，经常遇到这样的需求： 每天凌晨自动重启 Tomcat、Nginx 等服务 定时重启测试机或实验环境 使用脚本执行定期维护任务 不同操作系统如何统一管理计划任务？ 其实，Windows 和 Linux 都有自带的任务调度工具，不需要额外安装软件。 01. Windows：任务计划程序 Windows 可以通过 Task Scheduler（任务计划程序）实现。 ① 每天凌晨 2 点重启 Tomcat 服务 创建 restart_service.bat： @echo off net stop Tomcat net start Tomcat 注意：Tomcat 必须替换为实际的 Windows 服务名称。 打开任务计划程序： 创建任务 → 触发器 → 每天 02:00 → 操作 → 启动程序 选择刚创建的批处理文件，并设置具有服务管理权限的账户，必要时勾选“使用最高权限运行”。 ② 每天凌晨 3 点重启 Windows 同样创建计划任务： 程序：shutdown.exe 参数：/r /t 0 其中： /r：重启计算机 /t 0：不等待，立即执行 保存后，Windows 就会按照计划执行重启。 02. Linux：使用 Crontab 在 Rocky Linux、Ubuntu 等 Linux 发行版中，可以通过 Cron 管理定时任务。 ...

之前为了学习 Linux、Kubernetes、DevOps，我折腾过不少虚拟机。 但虚拟机越开越多，就会遇到一个问题： 有没有办法用一台自己的小主机，长期运行一套完整的 Linux 实验环境？ 我的选择是： 迷你主机 + Rocky Linux 9 + KVM。 不需要购买昂贵的服务器，也不用每次做实验都申请云服务器。 从 Linux 系统管理，到 Kubernetes 集群，再到 Jenkins、GitLab、Harbor、Argo CD，都可以在自己的局域网里逐步搭建。 这篇记录一下我的实际环境，以及从零部署的关键步骤。 01. 先看看这台迷你主机的配置 宿主机名是 ATK。我刚在机器上重新执行了 lscpu、free -h、virsh list --all，下面这些不是示意配置，而是实际截图。 CPU：Intel Core i5-12500H，12 核 / 16 线程 内存：64 GB 级别，Linux 显示总量约 62 GiB 系统：Rocky Linux 9（此前安装环境记录；本组截图未直接显示发行版版本） 虚拟化：KVM / QEMU / libvirt 网络：Linux Bridge br0（此前实验环境采用的网络模式） 管理：SSH + virsh ...