文章

K8s 存储体系：三层抽象 Kubernetes 存储体系通过三层抽象解耦了存储使用方与提供方，这是理解容器持久化存储的核心。根据 K8s 存储文档，三层结构如下： ┌──────────────────────────────────────────────────────┐ │ Pod (使用方) │ │ volumeMounts → volumes │ ├──────────────────────────────────────────────────────┤ │ PVC (声明) — 用户申请存储 │ │ "我需要 10Gi RWO 的存储" │ ├──────────────────────────────────────────────────────┤ │ StorageClass (动态供给) — 存储模板 │ │ "使用 ceph-rbd 驱动，reclaim: Retain" │ ├──────────────────────────────────────────────────────┤ │ PV (物理资源) — 实际存储 │ │ "10.0.0.5:/data/pvc-xxx (NFS)" │ └──────────────────────────────────────────────────────┘ PV（PersistentVolume） PV 是集群级资源，代表物理存储的抽象。PV 可以由管理员手动创建，也可通过 StorageClass 自动供给： apiVersion: v1 kind: PersistentVolume metadata: name: pv-nfs-data spec: capacity: storage: 50Gi accessModes: - ReadWriteMany # 多节点读写 persistentVolumeReclaimPolicy: Retain nfs: server: 10....

概述 在监控系统领域，Zabbix 和 Prometheus 是两座大山。Zabbix 从传统运维时代走来，在物理机/虚拟机环境中叱咤风云近二十五年；Prometheus 则在云原生时代崛起，成为 Kubernetes 生态的事实标准。很多团队在做监控选型时都会面临一个问题：到底该选 Zabbix 还是 Prometheus？ 答案不是非此即彼。很多成熟团队在实际生产中同时运行两套系统——Zabbix 负责基础设施层（网络、硬件、操作系统），Prometheus 负责应用层和云原生层。从架构、数据模型、告警、生态、适用场景等维度全面对比两者，帮你做出合理的选型决策。 参考来源：Zabbix 官方文档、Prometheus 官方文档 一、架构对比 1.1 Zabbix 架构 Zabbix 采用经典的 C/S 架构，核心组件包括 Server、Database、Web Frontend 和 Agent。 ┌──────────────────────────────────────────────────────────┐ │ Zabbix 架构 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Agent │ │ SNMP │ │ JMX │ ← 被监控端 │ │ │ (主动/被动)│ │ 设备 │ │ Java │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Zabbix Server│ ← 采集引擎 + 告警引擎 │ │ │ (C 语言) │ │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Database │ ← MySQL/PostgreSQL │ │ │ (关系型) │ │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Web Frontend│ ← PHP 前端 │ │ │ (Dashboard) │ │ │ └─────────────┘ │ │ │ │ ┌──────────────┐ │ │ │ Zabbix Proxy │ ← 分布式采集代理（可选） │ │ │ (区域汇聚) │ │ │ └──────────────┘ │ └──────────────────────────────────────────────────────────┘ Zabbix 架构特点：...

Requests 与 Limits 的语义 Kubernetes 中每个容器可以配置 CPU 和 Memory 的 requests 与 limits。很多开发者分不清二者的区别，导致 Pod 频繁被驱逐或 OOMKilled。 apiVersion: v1 kind: Pod metadata: name: api-server spec: containers: - name: app image: myapp:latest resources: requests: cpu: "250m" # 0.25 核 memory: "256Mi" limits: cpu: "500m" # 0.5 核 memory: "512Mi" 核心区别 维度 Requests Limits 作用阶段 调度时 运行时 含义 Pod 需要的最小资源保证 Pod 能使用的最大资源上限 调度器行为 调度器根据 requests 判断节点是否有足够资源 调度器不关心 limits 运行时行为 cgroups 中的保障份额 CPU 被节流（throttle），Memory 触发 OOMKilled 是否可超卖 可以（节点上所有 Pod 的 limits 之和可超过节点容量） 不建议超卖 Memory 简单理解：...

概述 性能诊断是 SRE 的核心技能。Linux 提供了丰富的性能分析工具，从简单的 top 到强大的 perf/eBPF，每个工具都有其适用场景。掌握这些工具的使用时机和方法，是快速定位性能瓶颈的关键。本文按 CPU、内存、IO、网络和综合工具五大维度，逐步梳理 Linux 性能诊断工具集，并提供使用场景速查表和实战案例。 负载监控工具 top：经典进程监控 $ top # 顶部摘要信息 top - 15:30:00 up 30 days, 3:21, 3 users, load average: 1.23, 0.98, 0.85 Tasks: 234 total, 1 running, 233 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.3 us, 3.4 sy, 0.0 ni, 83.3 id, 0.5 wa, 0.0 hi, 0.5 si, 0.0 st MiB Mem : 32000.0 total, 5000.0 free, 15000.0 used, 12000.0 buff/cache MiB Swap: 4096....

前言 Shell 脚本是运维工程师最常用的自动化工具。本文记录几个实战中常用的脚本模式。 日志定期清理 服务器日志堆积是常见问题，以下脚本按保留天数自动清理： #!/bin/bash # clean_logs.sh - 日志清理脚本 LOG_DIR="/var/log/app" KEEP_DAYS=30 find "$LOG_DIR" -name "*.log" -type f -mtime +${KEEP_DAYS} -exec gzip {} \; find "$LOG_DIR" -name "*.gz" -type f -mtime +${KEEP_DAYS} -delete echo "$(date): 日志清理完成，保留 ${KEEP_DAYS} 天" 配合 crontab 每天执行： 0 2 * * * /opt/scripts/clean_logs.sh >> /var/log/clean_logs.log 2>&1 批量主机健康检查 通过 SSH 批量检查多台服务器状态： #!/bin/bash # health_check.sh - 批量健康检查 HOSTS=("web-01" "web-02" "db-01" "cache-01") THRESHOLD=80 for host in "${HOSTS[@]}"; do echo "--- ${host} ---" ssh "$host" " echo \"CPU: \$(top -bn1 | grep 'Cpu' | awk '{print \$2}')%\" echo \"MEM: \$(free | awk '/Mem/{printf \"%....

概述 文件系统是操作系统与存储设备之间的桥梁，直接影响数据可靠性、I/O 性能和运维复杂度。Linux 支持多种文件系统，每种都有其设计取舍。本文对比 ext4、xfs、btrfs、zfs 四大主流文件系统，深入挂载参数优化、IO 调度器选择、journal 模式、fsync 性能等核心主题，并提供生产环境的选型建议和调优方案。 文件系统对比 核心特性一览 特性 ext4 xfs btrfs zfs 最大文件 16TB 8EB 16EB 16EB 最大卷 1EB 8EB 16EB 256ZB 日志 是 是 是（CoW） 是（CoW/ZIL） 快照 否 否 是 是 压缩 否 否 是 是 去重 否 否 是（实验） 是 校验和 否 否 是 是 子卷 否 否 是 是 RAID 否 否 是 是（原生） 在线扩容 是 是 是 是 在线缩容 否 否 是 否 CoW 部分 否 是 是 开发方 Linux 社区 SGI → Red Hat Oracle OpenZFS ext4：稳定可靠的传统选择 ext4 是 ext3 的改进版，自 2008 年进入主线内核，是 Ubuntu、Debian 等发行版的默认文件系统。...

概述 Bash 是运维世界使用最广泛的脚本语言——几乎每台 Linux 服务器都自带解释器，无需安装任何运行时。但 Bash 也是最容易写出"能跑但不能信赖"脚本的语言：没有类型检查、错误默认静默、变量不加引号就分词、管道中的失败被吞掉。一个线上故障的根因往往就是某个 Bash 脚本没做错误处理。本文逐步梳理生产级 Bash 脚本的编写规范，让你写出的脚本不只是"能跑"，而是"可信赖"。 参考来源：Google Shell Style Guide、ShellCheck 一、脚本骨架：set -euo pipefail 1.1 三行头 每个生产级 Bash 脚本的开头应该是这样的： #!/usr/bin/env bash set -euo pipefail 这三行做的事情： 选项 作用 不加的后果 -e (errexit) 命令失败时立即退出 错误被忽略，脚本继续执行，可能导致灾难性后果 -u (nounset) 使用未定义变量时报错 拼写错误的变量名静默返回空字符串 -o pipefail 管道中任一命令失败则整体失败 管道中前面的命令失败被忽略，只看最后一个命令的退出码 一个经典反面案例： #!/bin/bash # 没有任何安全设置 cd /nonexistent/directory # 失败，但脚本继续 rm -rf * # 在当前目录执行了！灾难 加上 set -euo pipefail 后： #!/usr/bin/env bash set -euo pipefail cd /nonexistent/directory # 失败，脚本立即退出 rm -rf * # 永远不会执行到这里 1....

概述 Linux 内核通过 /proc/sys/ 和 sysctl 接口暴露了数千个可调参数，涵盖网络、内存、文件系统、安全等各个方面。合理调整这些参数可以显著提升系统性能和稳定性，但盲目调参也可能适得其反。本文逐步梳理 sysctl 体系，按网络、文件描述符、内存、安全四大维度展开，并提供生产环境调优模板和参数验证方法。 sysctl 体系 参数查看与修改 # 查看所有参数 $ sysctl -a # 查看特定参数 $ sysctl net.ipv4.tcp_max_syn_backlog $ sysctl vm.swappiness # 临时修改（重启失效） $ sysctl -w vm.swappiness=10 # 从文件加载 $ sysctl -p /etc/sysctl.d/99-custom.conf # 永久生效：写入配置文件 # /etc/sysctl.conf — 传统配置文件 # /etc/sysctl.d/*.conf — 推荐方式（按字母序加载） 配置文件加载顺序 /etc/sysctl.d/ 下按文件名字母序加载： 00-default.conf → 默认值 50-network.conf → 网络参数 99-custom.conf → 自定义参数（最后加载，覆盖前面） 最后加载 /etc/sysctl.conf（如果存在） 参数命名空间 kernel.* — 内核通用参数 vm.* — 虚拟内存参数 fs.* — 文件系统参数 net....

前言 一台默认安装的 Linux 服务器，暴露的攻击面远超想象：多余的 RPM 包、开放的网络服务、宽松的 SSH 配置、未启用的审计系统。安全加固不是一次性操作，而是一套从安装到运行的全生命周期清单。本文按 CIS Benchmark 框架梳理加固要点，每一步都给出可直接执行的配置。 系统最小化安装原则 包管理裁剪 最小化安装的核心思路：只装需要的，不装可能需要的。 # 安装时选择 Minimal Install（RHEL 系）或 minimal image（Debian 系） # 安装后审计已安装的包组，移除不需要的 yum grouplist # RHEL/CentOS dnf group list # Fedora/RHEL 8+ # 移除不需要的包组 dnf group remove "GNOME Desktop" "Graphical Administration Tools" # 审计已安装的包，按大小排序 rpm -qa --queryformat '%{SIZE} %{NAME}\n' | sort -rn | head -30 # 移除已知不需要的包 dnf remove -y ypbind rsh-server ypserv telnet-server talk-server Debian/Ubuntu 系： # 查看手动安装的包（可安全移除的候选） apt-mark showmanual # 移除不需要的服务包 apt purge -y rsh-client rsh-redone-server telnetd tftpd xinetd 服务裁剪 安装后审计运行中的服务，关闭一切非必要服务：...

概述 SSH（Secure Shell）是 Linux 运维的核心通道，也是攻击者的主要目标。一个配置不当的 SSH 服务可能导致服务器被完全接管。从认证机制、服务端硬化、跳板机架构、隧道技术、审计日志到暴力破解防护，全面覆盖 SSH 安全的好的实践。 密钥认证 生成密钥对 # 生成 Ed25519 密钥（推荐） $ ssh-keygen -t ed25519 -C "admin@sre.wang" -f ~/.ssh/id_ed25519 # 生成 RSA 密钥（兼容性需求，至少 4096 位） $ ssh-keygen -t rsa -b 4096 -C "admin@sre.wang" -f ~/.ssh/id_rsa # 生成带密码保护的密钥 $ ssh-keygen -t ed25519 -N "strong-passphrase" -f ~/.ssh/id_ed25519 # 查看密钥指纹 $ ssh-keygen -lf ~/.ssh/id_ed25519.pub 256 SHA256:abc123... admin@sre.wang (ED25519) 密钥算法对比 算法 密钥长度 安全性 性能 推荐 Ed25519 256 位 极高 极快 首选 RSA-4096 4096 位 高 中 兼容场景 RSA-2048 2048 位 中 快 不推荐 ECDSA 256/384/521 高 快 有争议（NIST 曲线） DSA 1024 位 低 - 已废弃 部署公钥 # 方式 1：ssh-copy-id（推荐） $ ssh-copy-id -i ~/....