容器化部署

概述 你在一家智能制造公司干运维。工厂车间里有 200 台边缘网关，每台跑着数据采集和实时质检的服务。之前用裸 Docker 部署，每次更新都得写脚本逐台 SSH 上去拉镜像、重启容器。200 台机器跑一轮，半小时过去了，中间还经常有几台网络抖动导致更新失败。 你心想：这不就是 Kubernetes 要解决的问题吗？编排、调度、滚动更新、自愈——全都有了。但真去装 K8s 的时候傻眼了：车间网关用的是 ARM 架构的工控机，2 核 CPU、2G 内存，光 etcd 就吃掉 500M，kube-apiserver、kube-scheduler、kube-controller-manager 一堆组件跑起来，系统资源所剩无几。 这时候 K3s 登场了。它是 Rancher 开发的轻量级 Kubernetes 发行版，把所有控制面组件打包成一个 50MB 的二进制文件，内存占用不到 512M，支持 ARM64/x86_64，自带 containerd 运行时、Flannel 网络、CoreDNS、Traefik Ingress——开箱即用。在树莓派上都能跑起来，工控机更不在话下。 这篇文章聊聊 K3s 在边缘计算场景下的实战：从架构原理到集群搭建，从网络方案到边缘自治，从监控告警到故障排查。不是入门教程的复述，而是生产环境踩坑后的经验总结。 K3s 架构：为什么它能在 512M 内存上跑起来 和 K8s 的关键差异 K3s 不是 K8s 的阉割版——这个说法太粗暴了。它是一个为资源受限环境重新设计的 Kubernetes 发行版。核心区别在以下几方面： 特性 K8s K3s 二进制大小 ~300MB（多组件） ~50MB（单二进制） 最低内存 2GB 512MB 存储后端 etcd（必须） SQLite（默认）/ etcd / MySQL / PostgreSQL 运行时 需单独安装 containerd/Docker 内置 containerd 网络 CNI 需手动安装 内置 Flannel Ingress 需手动安装 内置 Traefik DNS 需手动安装 内置 CoreDNS Alpha/Beta 特性 全部包含 剔除 云厂商专用代码 全部包含 剔除 架构支持 x86_64 / ARM64 x86_64 / ARM64 / ARMv7 K3s 的核心设计哲学是：在边缘场景下，你需要的是 K8s 的编排能力，而不是它的全部复杂性。去掉 alpha/beta 特性和云厂商专用代码后，K3s 保留了 K8s 的核心 API 和功能——Pod、Deployment、Service、ConfigMap、HPA、CronJob 这些你日常用的资源全都在，kubectl 命令完全兼容。...

概述 先回答一个最基本的问题：Service Mesh 是干嘛的？ 一句话：它帮你管微服务之间通信的那些破事。 微服务架构下，服务 A 调服务 B，看似简单的 HTTP 请求，实际上要处理一堆问题：超时了怎么办？重试几次？要不要熔断？流量怎么灰度？证书怎么管？链路怎么追踪？ 传统做法是每个服务自己搞定——Java 用 Spring Cloud，Go 用 go-kit，Python 用一些库。问题是不同语言各搞各的，升级一次 SDK 全部重新编译部署，运维想统一管理根本不可能。 Service Mesh 的思路是把这些通信逻辑从业务代码里剥离出来，放到一个独立的代理层（Sidecar 或节点级代理）。业务代码只管发 HTTP 请求，代理负责重试、熔断、加密、追踪。开发爽了，运维也爽了。 Istio 是 Service Mesh 领域最主流的实现，由 Google、IBM、Lyft 联合开发，2017 年开源，现在是 CNCF 仅次于 Kubernetes 的第二大牌面项目。这篇文章带你从零跑通 Istio，覆盖架构原理、安装部署、流量管理、安全策略和可观测性。 架构全景：控制平面与数据平面 Istio 的架构很清晰，分成两块： 控制平面（Control Plane）：Istiod，负责管理和配置数据平面的代理。你可以理解为"大脑" 数据平面（Data Plane）：一组代理，拦截和处理所有微服务之间的网络通信。你可以理解为"手脚" 数据平面有两种模式，这是 Istio 最核心的设计选择。 Sidecar 模式：经典方案 Sidecar 模式从 Istio 1.0 就有，是最成熟的方案。每个 Pod 旁边塞一个 Envoy 代理容器，所有进出该 Pod 的流量都先经过 Envoy。 ┌─────────────────────────────────┐ │ Pod │ │ ┌───────────┐ ┌─────────────┐ │ │ │ 业务容器 │←→│ Envoy │ │ │ │ (App) │ │ Sidecar │ │ │ └───────────┘ └─────────────┘ │ └─────────────────────────────────┘ ↑ ↓ 入站流量 出站流量 优点：...

概述 Kubernetes 安全加固：RBAC、NetworkPolicy 与 Pod 安全策略是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Kubernetes 安全加固 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Kubernetes 安全加固能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Kubernetes 安全加固的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Kubernetes 安全加固的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Linux 命名空间与 cgroups：容器技术的底层基础是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要Linux 命名空间与 cgroups 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。Linux 命名空间与 cgroups能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 Linux 命名空间与 cgroups的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是Linux 命名空间与 cgroups的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 云原生安全实践：容器安全、镜像扫描与运行时防护是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要云原生安全实践 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。云原生安全实践能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 云原生安全实践的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是云原生安全实践的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

为什么需要 Helm 裸用 kubectl apply -f 管理 K8s 应用，在规模小时够用，但随着环境增多（dev/staging/prod）和服务增长，问题立刻暴露： 配置硬编码：每个环境一份 YAML，镜像 tag、副本数、资源限制全写死，改一个值要改十个文件 无版本管理：升级回滚靠手动记录，不知道上次部署了什么版本 无法复用：部署 Redis 和部署 MySQL 写两套完全不同的 YAML，无法模板化 Helm 是 K8s 的包管理器，把一组 K8s 资源打包成 Chart，通过 values.yaml 参数化配置，实现一份模板、多环境部署、版本化升级和一键回滚。 本文参考 Helm 官方文档 Helm Chart 目录结构 my-web-app/ ├── Chart.yaml # Chart 元信息（名称、版本、描述） ├── values.yaml # 默认配置值 ├── values-prod.yaml # 生产环境覆盖配置 ├── charts/ # 依赖的子 Chart ├── templates/ # K8s 资源模板 │ ├── _helpers.tpl # 命名模板（可复用的模板片段） │ ├── deployment.yaml # Deployment │ ├── service....

概述 Kubernetes 每年发布三个版本，每个版本的支持周期约为 14 个月。这意味着生产集群大约每 6-12 个月就需要进行一次版本升级。集群升级是 K8s 运维中最敏感的操作之一——既要紧跟社区获得安全补丁和新特性，又要确保升级过程中业务零中断、零故障。 我将从版本策略制定、升级前准备、升级执行流程、蓝绿/金丝雀策略、回滚机制到生产环境实战，系统性地讲解 Kubernetes 集群升级的完整方法论。 一、Kubernetes 版本策略 1.1 版本发布节奏 Kubernetes 每年发布三个小版本（约每 15 周一个），版本号的命名规则经历了从北欧神话地名到主题词的演变： 版本 代号 发布时间（约） 关键特性 v1.30 Uwubernetes 2024-04 结构化认证配置 v1.31 Ichigo 2024-08 AppArmor GA、动态资源分配 v1.32 Penelope 2024-12 用户命名空间 Beta v1.33 Patricia 2025-04 Sidecar Containers GA v1.34 衔尾蛇 2025-08 Kubelet 凭证提供者 v1.35 Timbernetes 2025-12 Pod 资源就地更新 GA、Gang 调度 v1.36 Haru 2026-04 User Namespaces GA、CEL 准入策略 v1.37 — 2026-08（预期） — 参考：Kubernetes Release History...

概述 Kubernetes 已成为云原生应用的标准运行平台，但其弹性与灵活性也带来了成本管理的巨大挑战。根据 Flexera 2024 云状态报告，企业平均有 32% 的云支出属于浪费，而 Kubernetes 集群的资源浪费尤为突出——一个缺乏治理的 K8s 集群，资源利用率往往低于 30%。 Kubernetes 成本优化不是一次性的配置调整，而是一个从资源治理、自动扩缩容、实例类型选择到 FinOps 文化建设的系统工程。从实际生产经验出发，给出一套可落地的 K8s 成本优化方法论。 Kubernetes 成本浪费的根源 资源配置的三大陷阱 在深入优化之前，必须先理解成本从哪里流失。K8s 的资源浪费主要来自三个层面： 浪费来源 表现 根因 影响占比 Requests 过高 节点 CPU/内存利用率低 开发按峰值而非实际需求配置 40-50% 无自动扩缩容 低峰期节点空跑 缺少 HPA/VPA/Cluster Autoscaler 20-30% 实例类型不当 全部使用按需实例 未利用 Spot/预留实例 15-25% 镜像冗余 大镜像拖慢部署、占用存储 缺少镜像优化和多阶段构建 5-10% 陷阱一：用峰值配置 Requests 这是最常见的浪费。开发团队为了保证服务"不出事"，倾向于把 Requests 设得很高。一个实际只需 200m CPU 的服务，Requests 被设为 1000m，导致节点只能调度少量 Pod，大量 CPU 资源闲置。 # 典型的过度配置 apiVersion: apps/v1 kind: Deployment metadata: name: api-service spec: template: spec: containers: - name: api resources: requests: cpu: "2000m" # 实际使用 200m，浪费 90% memory: "4Gi" # 实际使用 512Mi，浪费 87% limits: cpu: "4000m" memory: "8Gi" 陷阱二：缺少 LimitRange 和 ResourceQuota...

概述 当你的业务规模增长到单集群无法承载时，多集群就成为必然选择。可能的原因包括：单集群节点上限（5000 节点）、多地域部署、混合云策略、故障隔离、合规要求。但多集群带来的管理复杂度是指数级增长——应用如何跨集群部署、服务如何跨集群发现、配置如何同步、故障如何切换。 本文逐步梳理多集群的架构模式、主流管理工具对比，以及跨集群服务发现、CI/CD、容灾切换的实践方案。 本文基于 Kubernetes v1.30。多集群管理领域仍在快速演进，部分工具的成熟度需持续关注。 为什么需要多集群 单集群的瓶颈 瓶颈 说明 规模上限 K8s 单集群推荐上限 5000 节点、15 万 Pod、30 万容器 故障域 单集群 etcd 故障影响所有业务 升级风险 集群升级可能影响所有业务 多租户隔离 软隔离不如硬隔离 地域延迟 跨地域不能用一个集群 合规要求 数据不能跨地域/跨境 多集群的典型场景 场景 架构 目标 多地域容灾 每地域一个集群，DNS 全局负载均衡 RTO < 5min 混合云 云上 + 自建机房 弹性 + 合规 开发/测试/生产隔离 每环境一个集群 安全隔离 多租户硬隔离 每租户独立集群 安全合规 边缘计算 中心集群 + 边缘集群 低延迟 多集群架构模式 模式一：Hub-Spoke（中心辐射） ┌─────────┐ │ Hub │ ← 管理集群 │ Cluster │ └────┬────┘ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Spoke1│ │Spoke2│ │Spoke3│ ← 工作集群 └──────┘ └──────┘ └──────┘ 中心集群负责管理配置、分发应用、收集状态。工作集群只运行业务负载。这是最常见的多集群管理模式。...

概述 Kubernetes 集群的灾难恢复是运维中最容易被忽视的领域——直到灾难发生。etcd 损坏导致整个集群不可用、PV 数据误删无法恢复、集群升级失败无法回滚……这些场景没有备份就是灾难，有备份就是一次常规恢复。 详细梳理 K8s 灾难恢复的三个层次：etcd 备份恢复（集群元数据）、Velero 备份（K8s 资源）、PV 数据备份（持久化数据），以及跨集群恢复和恢复演练的实践。 本文基于 Kubernetes v1.30 和 Velero v1.14。参考 Kubernetes 灾难恢复文档 灾备基础概念 RTO 与 RPO 指标 全称 含义 目标 RTO Recovery Time Objective 恢复时间目标（多快恢复） < 30min RPO Recovery Point Objective 数据丢失目标（丢多少数据） < 5min 故障发生 恢复完成 |◄────── RTO ──────────►| | | |◄── RPO ──►| | | | | 最后一次备份 故障点 恢复点 备份层次 层次 备份对象 工具 RPO 恢复粒度 etcd 集群所有元数据 etcdctl snapshot 分钟级 整个集群 K8s 资源 Deployment/Service/ConfigMap 等 Velero 分钟级 命名空间/资源 PV 数据 持久化卷数据 Velero/Restic/Kasten 小时级 单个 PV 应用数据 数据库/对象存储 应用自身机制 秒级 应用级 灾备分类 类型 说明 适用场景 备份恢复 定期备份，故障时恢复 通用 活跃-备用 备集群 standby，故障切换 核心业务 活跃-活跃 多集群同时服务，故障切流 全球业务 混沌演练 模拟故障验证恢复能力 灾备成熟度 etcd 备份与恢复 为什么 etcd 备份最重要 etcd 是 K8s 的"大脑"——所有集群状态（Pod、Service、ConfigMap、Secret、Deployment 等）都存储在 etcd 中。etcd 损坏等于整个集群的数据丢失。没有 etcd 备份，其他备份都无意义。...