概述 kubectl 是 Kubernetes 管理员最常用的工具，但大多数人只用了它 20% 的功能。每天敲几十遍 kubectl get pods -n production，却不知道一行别名就能省掉一半字符；遇到问题只知道 kubectl describe 和 kubectl logs，却不知道 krew 插件能一键排查网络、资源、证书问题。本文逐步梳理 kubectl 的生产力提升工具链，从别名到插件到交互式工具，让你的 K8s 日常操作效率翻倍。 参考来源：kubectl 官方文档、krew 官网 一、kubectl 别名配置 1.1 基础别名 # ~/.bashrc 或 ~/.zshrc # 基础缩写 alias k='kubectl' alias kg='kubectl get' alias kd='kubectl describe' alias kdel='kubectl delete' alias ke='kubectl exec' alias kl='kubectl logs' alias kf='kubectl apply -f' alias kdf='kubectl delete -f' alias kr='kubectl run' # 常用资源缩写 alias kgp='kubectl get pods' alias kgs='kubectl get svc' alias kgn='kubectl get nodes' alias kgd='kubectl get deployments' alias kgsec='kubectl get secrets' alias kgcm='kubectl get configmaps' alias kging='kubectl get ingress' alias kgns='kubectl get namespaces' alias kgpv='kubectl get pv' alias kgpvc='kubectl get pvc' alias kdsa='kubectl describe sa' # 宽输出 + 自定义列 alias kgpw='kubectl get pods -o wide' alias kgsw='kubectl get svc -o wide' alias kgnw='kubectl get nodes -o wide' # watch 模式 alias kgpw='watch -n 2 kubectl get pods -o wide' alias kgnw='watch -n 5 kubectl get nodes -o wide' # 所有命名空间 alias kgpa='kubectl get pods --all-namespaces' alias kgsa='kubectl get svc --all-namespaces' # YAML 输出 alias kgpy='kubectl get pods -o yaml' alias kgsy='kubectl get svc -o yaml' 1....

CI/CD 是现代软件交付的命脉。手动构建、手动部署不仅效率低下，更是事故的温床——“在我机器上能跑"的悲剧几乎都源于缺乏自动化流水线。GitHub Actions 作为 GitHub 原生的 CI/CD 平台，与代码仓库无缝集成，免费额度对开源项目友好，已成为最流行的 CI/CD 工具之一。从核心概念出发，结合 Go 项目和 Hugo 站点两个实战场景，完整讲解流水线设计。 参考来源：GitHub Actions 官方文档 一、GitHub Actions 核心概念 GitHub Actions 的架构围绕五个概念展开，理解它们的关系是设计流水线的基础： Workflow（工作流） │ ├── Job A（任务） │ ├── Step 1 → Action: checkout 代码 │ ├── Step 2 → Action: setup Go 环境 │ └── Step 3 → Shell: go test ./... │ └── Job B（任务） ├── Step 1 → Action: 下载构建产物 └── Step 2 → Shell: 部署到服务器 概念 说明 类比 Workflow 一个 ....

为什么选择 Loki 传统 ELK（Elasticsearch + Logstash + Kibana）方案虽然功能强大，但存在两个核心痛点： 存储成本高：Elasticsearch 将日志全文索引化，每条日志的索引膨胀可达原始数据的 3-5 倍 运维复杂：ES 集群扩缩容、分片再平衡、索引生命周期管理复杂，生产集群维护成本高 Loki 由 Grafana Labs 开源，设计理念是"像 Prometheus 那样做日志"。它只对日志的标签（Labels）做索引，不对日志正文建索引，通过 LogQL 进行全文检索。这种设计使存储成本降低 10 倍以上。 本文基于 Loki 3.x，参考 Loki 官方文档 Loki vs ELK 对比 维度 ELK (Elasticsearch) Loki 索引方式 全文倒排索引 仅索引标签，正文不索引 存储成本 高（索引膨胀 3-5x） 低（标签索引 + 压缩正文） 查询语言 Lucene Query / KQL LogQL（类 PromQL 语法） 扩展性 水平扩展，分片复杂 微服务模式，组件独立扩展 适用场景 全文检索、复杂分析 日志监控、指标化查询、与 Grafana 联动 资源消耗 高（JVM，内存大） 低（Go 编写，内存友好） Loki 并非要完全替代 ES。如果你的核心需求是全文检索和复杂文本分析，ES 仍是更好的选择。但对于 SRE 日志监控、指标告警、排障定位这类场景，Loki + Grafana 的组合在成本和效率上优势明显。...

在 Prometheus 生态中，Prometheus 负责根据告警规则产生告警，而 Alertmanager 负责告警的后续全生命周期管理：分组、路由、抑制、去重和通知发送。一个配置不当的 Alertmanager 会让值班人员在凌晨被海量重复告警淹没，而精心设计的路由与抑制策略能确保"正确的人、在正确的时间、收到正确的告警"。 参考来源：Prometheus 官方文档 — Alertmanager 一、Alertmanager 架构 Alertmanager 的处理流水线分为五个阶段： Prometheus 告警规则触发 │ ▼ ┌───────────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ 接收 Receive │ ──→ │ 分组 Group │ ──→ │ 路由 Route │ ──→ │ 抑制 Inhibit│ ──→ │ 去重 Dedup │ └───────────────┘ └───────────┘ └───────────┘ └───────────┘ └─────┬─────┘ │ ▼ ┌───────────────┐ │ 发送 Notify │ │ 邮件/微信/钉钉 │ └───────────────┘ 阶段 作用 关键配置 接收 接收来自 Prometheus 的告警 receivers 分组 将相同特征的告警合并为一批 group_by 路由 根据标签匹配决定告警去向 route、matchers 抑制 当某告警触发时，静默相关低优先级告警 inhibit_rules 去重 多个 Alertmanager 实例间的告警去重 HA 模式 + Gossip 发送 通过配置的渠道发送通知 webhook / email / 等 二、路由树设计 2....

方案架构 Exporter → Prometheus（存储） → Grafana（可视化） ↓ Alertmanager（告警分发） Docker Compose 部署 version: '3.8' services: prometheus: image: prom/prometheus:v2.52.0 ports: ["9090:9090"] volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./rules:/etc/prometheus/rules - prom_data:/prometheus command: - '--storage.tsdb.retention.time=30d' restart: unless-stopped grafana: image: grafana/grafana:10.4.2 ports: ["3000:3000"] volumes: [grafana_data:/var/lib/grafana] restart: unless-stopped alertmanager: image: prom/alertmanager:v0.27.0 ports: ["9093:9093"] volumes: [./alertmanager.yml:/etc/alertmanager/config.yml] restart: unless-stopped node-exporter: image: prom/node-exporter:v1.8.1 ports: ["9100:9100"] restart: unless-stopped volumes: prom_data: grafana_data: 核心配置 # prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s rule_files: - "rules/*.yml" alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] scrape_configs: - job_name: 'node' static_configs: - targets: ['node-exporter:9100'] 常用 PromQL # CPU 使用率 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) # 内存使用率 (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 # 磁盘使用率 (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 告警规则示例 groups: - name: host-alerts rules: - alert: HighCPU expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "CPU 使用率过高 ({{ $labels....

概述 日志是系统运维的眼睛。从内核消息到应用日志、从安全审计到性能分析，日志贯穿了故障排查的每个环节。现代 Linux 采用 journald 作为系统日志守护进程，配合 logrotate 进行日志轮转，构成了完整的日志管理基础设施。本文深入 journald 的原理与配置、journalctl 的高级查询技巧、日志轮转策略、远程日志收集方案以及实战分析案例。 journald 原理 架构概览 journald 是 systemd 的系统日志组件，取代了传统的 syslog（rsyslog）。它接收来自内核、系统服务和应用程序的日志，统一存储为结构化的二进制格式。 [内核日志] [systemd 服务] [应用程序] │ │ │ ▼ ▼ ▼ [kmsg] [sd_journal_print] [syslog()/stdout] │ │ │ └──────────┬───────┴──────────┬───────┘ ▼ ▼ [journald] [/dev/log] │ ┌──────────┼──────────┐ ▼ ▼ ▼ [持久日志] [运行时日志] [转发到 syslog] /var/log/ /run/log/ /var/log/ journal/ journal/ messages 日志存储模式 # 查看当前存储模式 $ cat /etc/systemd/journald.conf | grep Storage #Storage=auto # 三种模式： # auto（默认）: /var/log/journal 存在则持久化，否则仅内存 # persistent: 强制持久化（自动创建 /var/log/journal） # volatile: 仅内存（/run/log/journal） 模式 存储位置 重启后保留 适用场景 persistent /var/log/journal 是 生产环境 auto /var/log/journal 或 /run/log/journal 取决于目录 默认 volatile /run/log/journal 否 临时系统/安全要求 日志大小控制 # /etc/systemd/journald....

systemd 架构概述 systemd 是现代 Linux 发行版的事实标准 init 系统，从 2015 年起已取代 SysVinit 成为绝大多数主流发行版的默认 init。它不只是"启动服务的工具"，而是一个完整的系统和服务管理器。 核心 unit 类型 systemd 通过 unit（单元）来管理系统资源，每种 unit 类型对应一种资源： unit 类型 扩展名 作用 service .service 系统服务（守护进程） socket .socket IPC 套接字（支持套接字激活） timer .timer 定时任务（替代 cron） target .target 服务组（类似传统 runlevel） mount .mount 文件系统挂载点 device .device 内核设备 path .path 文件路径监控（文件出现时触发服务） slice .slice cgroup 资源分配层级 target 与传统 runlevel 的映射 # 查看当前默认 target systemctl get-default # 通常输出: multi-user.target（对应 runlevel 3，多用户命令行模式） # 切换到图形界面（对应 runlevel 5） sudo systemctl isolate graphical....

概述 很多团队对 Docker Compose 的认知停留在"本地开发环境编排工具"。但事实上，在中小规模生产场景（单节点或少量节点）下，Compose 依然是性价比极高的方案。它语法简洁、学习成本低、不需要一整套 K8s 集群运维能力，就能完成多服务编排、依赖管理、健康检查、资源限制等核心工作。 本文不重复 Compose 基础语法，而是聚焦生产环境中的真实痛点：服务依赖怎么管才不会启动雪崩、健康检查怎么写才靠谱、密钥怎么不硬编码进 compose 文件、日志怎么不把磁盘写满、什么时候该从 Compose 迁移到 K8s。 本文基于 Docker Compose V2（docker compose 子命令），V1（docker-compose 独立二进制）已停止维护。参考 Compose 规范 多服务编排 生产级 Compose 文件结构 一个典型的生产环境应用至少包含：应用服务、数据库、缓存、反向代理。下面是一个完整的 Web 应用编排示例： # docker-compose.yml name: myapp services: # ========== 反向代理 ========== nginx: image: nginx:1.25-alpine container_name: myapp-nginx restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./nginx/conf.d:/etc/nginx/conf.d:ro - cert_data:/etc/letsencrypt:ro - log_data:/var/log/nginx depends_on: web: condition: service_healthy networks: - frontend logging: driver: json-file options: max-size: "10m" max-file: "3" # ========== 应用服务 ========== web: build: context: ....

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 架构特点：...