排查路径 kubectl get pods → 看状态 kubectl describe pod → 看 Events kubectl logs → 看日志 常见 Pod 状态 状态 含义 常见原因 Pending 未调度 资源不足、调度约束 CrashLoopBackOff 崩溃重启 应用异常、配置错误 ImagePullBackOff 镜像拉取失败 镜像不存在、认证失败 OOMKilled 内存溢出 内存限制过低 CrashLoopBackOff 排查 最常见故障，排查步骤： # 查看上次崩溃日志 kubectl logs <pod> --previous # 查看退出码 kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}' 退出码含义： 137：OOMKilled → 增加 resources.limits.memory 1：应用错误 → 查应用日志 126/127：命令不存在或权限问题 ImagePullBackOff 排查 kubectl describe pod <pod> | grep -A5 Events 常见原因：镜像名拼写错误、仓库需认证、网络不通。...

为什么要调优 Linux 网络栈 Linux 内核默认的网络参数是为通用场景设计的，保守而安全。但在高并发 Web 服务、大规模负载均衡器、CDN 节点等场景下，默认值会成为瓶颈。典型症状包括： dmesg 出现 nf_conntrack: table full, dropping packet ss -s 显示大量 TIME-WAIT 连接 压测时 CPU 没跑满但吞吐量上不去 网卡 PPS（包每秒）远低于硬件能力 这些问题大多源于内核网络参数未调优。从协议栈参数、conntrack、网卡多队列、拥塞控制四个层面详细梳理。 内核网络参数的完整说明可参考 kernel.org 文档，本文涉及的参数在 Documentation/networking/ip-sysctl.txt 中有详细定义。 TCP/IP 协议栈关键内核参数 所有参数通过 sysctl 或 /proc/sys/net/ 查看和修改。以下参数均在 net.ipv4 命名空间下。 连接队列参数 # 查看当前值 sysctl net.ipv4.tcp_max_syn_backlog sysctl net.core.somaxconn sysctl net.core.netdev_max_backlog somaxconn — 监听套接字的全连接队列上限： # 默认值通常为 128 或 4096（取决于内核版本） # 高并发场景建议设置为 65535 net.core.somaxconn = 65535 全连接队列存放已完成三次握手但尚未被 accept() 取走的连接。队列满后新连接被丢弃，客户端看到连接超时。注意：应用层面的 listen(fd, backlog) 的 backlog 值不能超过 somaxconn，实际取两者最小值。...

概述 代码质量问题越早发现，修复成本越低。在提交阶段拦截比在 CI 阶段拦截快，在 CI 阶段拦截比在生产环境出问题后修复快。Git Hooks 提供了在提交和推送的关键节点自动执行检查的能力——格式化代码、运行 lint、验证提交信息、执行测试。从 Git Hooks 原理到工具链实践，构建一套从本地到 CI 的代码质量自动化体系。 参考来源：Git Hooks 官方文档、pre-commit 官网 一、Git Hooks 体系 1.1 Hooks 概览 Git Hooks 是 Git 在特定操作（如 commit、push、merge）发生时自动执行的脚本，存放在 .git/hooks/ 目录中： Hook 名称 触发时机 常见用途 是否可跳过 pre-commit commit 执行前 代码格式化、lint 检查 --no-verify prepare-commit-msg 编辑提交信息前 自动生成提交信息模板 - commit-msg 提交信息写入后 验证提交信息格式 --no-verify post-commit commit 完成后 通知、统计 否 pre-push push 执行前 运行测试、防止推送到 protected 分支 --no-verify pre-merge-commit merge 完成前 合并前检查 - post-merge merge 完成后 恢复依赖、更新子模块 否 pre-rebase rebase 执行前 防止 rebase 已推送的提交 - post-checkout 切换分支后 恢复环境 否 1....

概述 Linux 系统的启动是一个精密编排的多阶段过程，从固件加电自检到内核加载、再到用户空间服务启动，每个阶段都有其特定职责。理解完整的启动流程不仅有助于排查启动故障，还能进行启动性能优化。从固件层出发，逐层解析 BIOS/UEFI、GRUB2、initramfs、内核初始化、systemd 启动流程，并覆盖启动优化和内核崩溃恢复。 启动流程概览 [电源开启] │ ▼ [1. 固件阶段] BIOS / UEFI │ POST (加电自检) │ 硬件初始化 │ 查找启动设备 ▼ [2. 引导阶段] GRUB2 │ 加载 GRUB 到内存 │ 读取 grub.cfg │ 加载内核和 initramfs ▼ [3. 内核阶段] Linux Kernel │ 内核解压并初始化 │ 硬件检测和驱动加载 │ 挂载 initramfs │ 启动 init (systemd) ▼ [4. 用户空间阶段] systemd │ 读取 default.target │ 按依赖顺序启动服务 │ 启动登录服务 ▼ [5. 登录阶段] │ getty / display-manager │ 用户认证 │ Shell 启动 ▼ [系统就绪] BIOS 与 UEFI BIOS vs UEFI 特性 BIOS UEFI 启动模式 Legacy UEFI 固件接口 16位 32/64位 分区表 MBR (≤2TB) GPT (>2TB) 启动代码 512字节MBR EFI分区 启动速度 慢 快 网络功能 无 有（PXE/HTTP启动） 安全启动 不支持 支持 分辨率 文本模式 图形模式 BIOS 启动流程 1....

概述 Kubernetes 默认配置的安全性可以用一个词概括：开放。默认 ServiceAccount 拥有集群内几乎所有 API 的访问权限（取决于版本和 PSP 配置），Pod 以 root 用户运行，容器可以挂载宿主机文件系统，网络全通。这种"默认开放"的设计降低了上手门槛，但在生产环境中是巨大的安全隐患。 从 RBAC 权限模型、ServiceAccount 管理、Pod 安全标准、SecurityContext、网络策略到审计日志，详细梳理 K8s 安全加固的实践方法。 本文基于 Kubernetes v1.30。参考 Kubernetes 安全文档 RBAC 权限模型 RBAC 四个核心对象 对象 作用域 功能 Role 命名空间 定义命名空间内的权限 ClusterRole 集群 定义集群范围或命名空间内的权限 RoleBinding 命名空间 将 Role/ClusterRole 绑定到用户/组/SA ClusterRoleBinding 集群 将 ClusterRole 绑定到用户/组/SA 核心关系： 用户/组/ServiceAccount ──Binding──→ Role/ClusterRole ──包含──→ 权限规则 Role 与 ClusterRole # Role：命名空间级别的权限，只影响指定 namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: pod-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["configmaps"] verbs: ["get"] resourceNames: ["app-config"] # 限制只能访问特定 ConfigMap # ClusterRole：集群级别的权限 apiVersion: rbac....

概述 Kubernetes 调度器是控制平面中最核心的组件之一——它决定每个 Pod 运行在哪个节点上。调度质量直接影响集群的资源利用率、应用性能和可靠性。理解调度器的工作原理，是做好 K8s 生产运维的基本功。 从调度流程、过滤打分机制、亲和性、污点容忍、优先级抢占到自定义调度器，详细梳理调度器的原理与调优实践。 本文基于 Kubernetes v1.30。参考 Kubernetes 调度器文档 调度流程 整体流程 Pod 创建 → API Server → etcd → 调度器 Watch → 调度决策 → 绑定到节点 → kubelet 创建容器 调度器的核心工作分为两个阶段： 1. 过滤（Filter）：排除不满足条件的节点 → 候选节点集 2. 打分（Score）：对候选节点打分 → 选择最高分节点 详细调度流程 ┌──────────────┐ │ Pod 入队 │ └──────┬───────┘ ▼ ┌──────────────┐ │ 调度周期开始 │ └──────┬───────┘ ▼ ┌────────────────────────┐ │ 扩展点：PreFilter │ ← 预过滤（检查 Pod 是否可调度） └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：Filter │ ← 过滤不满足条件的节点 │ （排除不可行节点） │ └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：PostFilter │ ← 过滤后无节点？（触发抢占） └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：Score │ ← 对候选节点打分 │ （选择最优节点） │ └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：Reserve │ ← 预留资源 └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：Permit │ ← 允许/延迟/拒绝 └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：PreBind │ ← 绑定前处理 └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：Bind │ ← 绑定到节点 └────────────┬────────────┘ ▼ ┌────────────────────────┐ │ 扩展点：PostBind │ ← 绑定后处理 └────────────────────────┘ 调度队列 调度器内部维护三个队列：...

概述 软件包管理是 Linux 系统运维的基础。Debian 系使用 apt/dpkg，Red Hat 系使用 yum/dnf/rpm。理解两套包管理体系的原理和用法，掌握仓库管理、依赖解析、包构建、版本锁定和离线安装，是高效运维的前提。本文系统对比两大体系，并深入实践包构建和镜像源优化。 apt/dpkg 体系 体系架构 apt (高级前端) │ ├── apt-get → 包安装/卸载/更新 ├── apt-cache → 包查询/搜索 └── apt → 综合命令（交互友好） │ dpkg (底层工具) │ ├── dpkg → .deb 包安装/卸载 ├── dpkg-deb → .deb 包操作 └── dpkg-query → 包查询 │ aptitude (替代前端，可选) apt vs apt-get # apt 是 apt-get 和 apt-cache 的综合，输出更友好 # 常用对照: # 安装 $ apt install nginx # 新（推荐交互使用） $ apt-get install nginx # 旧（推荐脚本使用） # 搜索 $ apt search nginx $ apt-cache search nginx # 查看包信息 $ apt show nginx $ apt-cache show nginx # 更新索引 $ apt update $ apt-get update # 升级 $ apt upgrade # 升级已安装的包（不删除） $ apt full-upgrade # 升级（可删除包以解决依赖） $ apt-get dist-upgrade # 等同 full-upgrade 在脚本中建议使用 apt-get/apt-cache，因为其输出格式稳定；交互操作使用 apt 更友好。...

概述 错误预算（Error Budget）是 SRE 体系中最精妙的机制设计。它把"稳定性 vs 迭代速度"这个长期依赖口水战的矛盾，转化为一个可量化的工程决策框架：你的系统有一个"不可用额度"，花完了就得停下来修。 但实践中，很多团队定义了 SLO 和错误预算之后，就止步于仪表盘上展示一个百分比数字。预算耗尽时该怎么办？快耗尽时要采取什么行动？预算富裕时可以做什么？这些关键问题如果没有明确的策略，错误预算就只是一个好看的数字，而非真正驱动行为的工具。 详细梳理错误预算的消耗状态模型、每种状态对应的行动纲领、发布冻结的标准与流程、预算滚存与重置策略、跨团队协调机制，并配以实战案例。 本文假设读者已了解 SLI/SLO/错误预算的基本概念。如需补充，可参考 Google SRE Book - Embracing Risk 和本站 SRE核心理念：SLI、SLO与错误预算。 一、错误预算的工程本质 不只是"还剩多少额度" 很多人把错误预算理解为"这个月还能宕机多少分钟"。这只是表面理解。错误预算的工程本质是： 错误预算是创新速度与系统稳定性之间的自动调节阀。 它回答了一个在所有工程团队都存在但很难回答的问题：我们现在应该更激进地发布新功能，还是应该停下来提升稳定性？ 预算充裕 → 系统足够稳定，可以承担更多变更风险 → 加速发布 预告耗尽 → 系统已经接近可靠性边界 → 减速发布，专注稳定性 这个调节是自动的、基于数据的、不依赖个人判断和政治博弈的。 错误预算的计算 SLO = 99.9%（30天窗口） 错误预算 = (1 - SLO) × 时间窗口 = 0.1% × 43200 分钟 = 43.2 分钟/月 已消耗预算 = 实际不可用时间 剩余预算 = 43.2 - 已消耗时间 预算消耗率 = 已消耗预算 / 总预算 但"不可用"的判定不只是"服务完全宕机"。任何 SLI 违规都消耗预算：...

概述 很多团队在实践 SRE 时遇到的第一个困境是：知道 SLO 是什么，但不知道怎么设。要么照搬 Google 的 99.99%，要么随便拍一个 99.9%——然后发现这个数字既不反映用户体验，也无法驱动工程决策。 好的 SLO 不是拍脑袋拍出来的，而是从业务目标出发，经过用户旅程分析、指标选择、数值校准、多层级设计、定期评审等一系列工程方法推导出来的。详细梳理 SLO 设计的完整方法论，帮助你建立从"业务目标"到"技术指标"的完整映射链路。 本文假设读者已了解 SLI/SLO 的基本概念。如需补充，可参考 Google SRE Workbook - Service Level Objectives 和本站 SRE核心理念：SLI、SLO与错误预算。 一、SLO 设计金字塔 SLO 设计不是孤立的技术活动，而是从上到下的分层推导过程： ┌─────────────┐ │ 业务目标 │ "我们的服务需要做到什么程度？" └──────┬──────┘ │ ┌──────▼──────┐ │ 用户体验 │ "用户关心什么？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLI 定义 │ "我们怎么衡量用户体验？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLO 目标值 │ "这个指标要做到多少？" └──────┬──────┘ │ ┌──────▼──────┐ │ 告警与行动 │ "不达标时怎么办？" └─────────────┘ 第一层：业务目标 一切 SLO 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...

手动登录云控制台创建服务器、数据库、网络——这种方式在资源少时还能勉强应付，一旦环境变复杂，就会出现"改不动、删不清、说不明"的困境。基础设施即代码（Infrastructure as Code, IaC）用代码描述基础设施，让资源的创建、修改和销毁变得可版本化、可审查、可复用。Terraform 是目前最主流的 IaC 工具，从理念到实战全面梳理。 参考来源：Terraform 官方文档 一、IaC 理念：声明式 vs 命令式 IaC 的核心思想是：用代码文件描述基础设施的期望状态，由工具自动驱动实际状态向期望状态收敛。 在 IaC 领域，存在两种截然不同的范式： 维度 声明式（Declarative） 命令式（Imperative） 核心理念 描述"要什么"（期望状态） 描述"怎么做"（操作步骤） 代表工具 Terraform、CloudFormation、Pulumi Ansible（部分）、Shell 脚本、AWS CLI 幂等性 天然幂等，重复执行结果一致 需自行保证幂等性 状态感知 工具追踪当前状态，自动计算差异 无状态感知，按步骤执行 可读性 接近配置文件，易于理解 接近编程逻辑，灵活但复杂 Terraform 采用声明式范式。你只需声明"我需要 3 台 EC2、1 个 RDS、1 个 VPC"，Terraform 会自动对比当前状态和期望状态的差异，生成并执行变更计划。 声明式的核心优势：幂等性。无论执行多少次 terraform apply，最终状态一致。这意味着你可以把基础设施代码纳入 Git 版本控制，通过 PR 审查变更，实现基础设施的"代码化治理"。 二、Terraform 核心概念 Terraform 的运作围绕四个核心概念展开： 开发者编写 .tf 文件 │ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Provider │ ←──→ │ Resource │ │ State │ │ 云厂商插件 │ │ 资源声明 │ │ 状态文件 │ └──────────────┘ └──────────────┘ └──────────────┘ │ ▼ ┌──────────────┐ │ Module │ │ 模块化复用 │ └──────────────┘ 2....