OpenStack Swift对象存储详解

一、Swift核心架构概览

Swift是OpenStack的分布式对象存储核心组件，为云平台提供高可用、可扩展、低成本的非结构化数据存储。由 Rackspace 开发并于 2010 年贡献给 OpenStack 社区，使用普通硬件即可构建 PB 级存储集群，无需 RAID，通过软件层面的一致性哈希与多副本机制保障数据安全。🗄️

架构全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

                     ┌──────────┐
                     │ Keystone │
                     └────┬─────┘
                          │ AUTH
                     ┌────▼─────┐
USER ──HTTP REST────►  PROXY   │
（PUT/GET/DELETE）    │ SERVER  │
                     └────┬─────┘
                          │ Ring Lookup
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
      ┌──────────┐ ┌──────────┐ ┌──────────┐
      │ACCOUNT   │ │CONTAINER │ │ OBJECT   │
      │ SERVER   │ │ SERVER   │ │ SERVER   │
      └────┬─────┘ └────┬─────┘ └────┬─────┘
           │            │            │
      ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
      │ SQLite  │ │ SQLite  │ │  XFS    │
      │ Account │ │Container│ │Object   │
      │   DB    │ │   DB    │ │  File   │
      └─────────┘ └─────────┘ └─────────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
       Replicator      Updater        Auditor
        (rsync)      (异步更新)      (完整性审计)

核心组件一览表

架构设计哲学 — 完全对称 + 最终一致性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

对象存储设计理念:

┌─────────────────────────────────────────────────────┐
│  控制路径 (Control Path)                              │
│  ├── Proxy Server → Ring 查询 → 路由请求               │
│  ├── Token 鉴权（Keystone 对接）                       │
│  └── 无状态设计，所有节点对等                           │
├─────────────────────────────────────────────────────┤
│  数据路径 (Data Path)                                 │
│  ├── 对象数据直接写入 Object Server                    │
│  ├── Replicator 后台异步同步副本                       │
│  ├── Updater 异步更新容器/账户列表                      │
│  └── Auditor 定期扫描修复                              │
├─────────────────────────────────────────────────────┤
│  CAP 理论定位: AP + 最终一致性                         │
│  ├── 可用性 (Availability): ✅ 高可用                  │
│  ├── 分区容忍 (Partition Tolerance): ✅ 支持            │
│  └── 一致性 (Consistency): 最终一致（R+W > N 保证）    │
└─────────────────────────────────────────────────────┘

关键设计理念: Swift 不追求强一致性，而是通过 Quorum 仲裁 + 后台守护进程实现最终一致性。副本写入不要求全部成功即可返回，不一致状态由 Replicator/Updater 从后台修复。这种设计使得 Swift 在普通硬件上支持无限水平扩展和高可用性。🚀

二、Account / Container / Object 三层数据模型 🧱

Swift 采用完全对称、面向资源的分层架构，数据模型共设三层逻辑隔离：

1
2
3

Account (账户/租户)
   └── Container (容器)
          └── Object (对象)

数据模型关键特性 🔑

1
2
3
4
5
6
7
8
9
10

对象名称 Flat Namespace:
  ┌─────────────────────────────────────┐
  │  /v1/AUTH_project/container/obj     │
  │      ↕          ↕        ↕          │
  │    Account    Container  Object     │
  │                                     │
  │  对象名称中的 '/' 仅是名字的一部分：    │
  │  container/photos/2026/01/photo.jpg │
  │          ↕ 无真实目录层级 ↕           │
  └─────────────────────────────────────┘

• Flat Namespace: 对象名支持 / 字符模拟目录层级，但无真正目录树结构
• 单对象限制: 最大 5GB，超出需使用 SLO（静态大对象）/ DLO（动态大对象）分段上传
• 元数据存储: 对象元数据存储在文件系统的 **xattr（扩展属性）**中，最大 4KB
• 多租户隔离: 每个账户独立 namespace，AUTH_<project_id> 为默认账户前缀

三种实体各自拥有独立 Ring 映射

1
2
3

account.ring.gz    →  Account Server 集群映射
container.ring.gz  →  Container Server 集群映射
object.ring.gz     →  Object Server 集群映射

三、核心组件深度解析 🧩

1️⃣ Proxy Server — 请求入口网关

Proxy Server 是 Swift 对外的唯一入口，所有客户端请求必经此处。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Proxy Server 请求处理流水线:

1. 接收 HTTP 请求 (PUT / GET / DELETE / HEAD)
2. Keystone Token 鉴权验证
3. 解析路径 → Account/Container/Object
4. 查询对应 Ring 获取目标节点列表
5. 并发转发请求到所有副本节点
6. 等待 Quorum（W 个写成功 / R 个读成功）
7. 聚合响应返回客户端

特性:
  ├── 流式传输：对象数据流式通过，不缓冲到磁盘
  ├── 无状态：无本地状态，可任意横向扩展
  ├── Handoff 支持：主节点失败自动路由到 Handoff 节点
  └── 存储策略感知：2.x+ 支持多 Ring 策略路由

Proxy Server 中间件链:

1
2
3
4
5
6
7
8

WSGI Pipeline 中的中间件（按顺序执行）:
  ├── healthcheck        → 健康检查端点
  ├── keystoneauth       → Token 鉴权
  ├── proxy-logging      → 访问日志
  ├── bulk              → 批量操作
  ├── tempurl            → 临时 URL
  ├── ratelimit          → 请求限速
  └── proxy-server       → 核心代理服务

2️⃣ Account / Container / Object Server — 存储节点三驾马车

Account Server:

1
2
3
4
5

职责:
  └── 管理账户元数据（容器列表 + 统计信息）
       ├── 使用 SQLite 存储
       ├── 记录各容器对象数量和总字节数
       └── 响应 HEAD 请求返回统计信息

Container Server:

1
2
3
4
5
6

职责:
  └── 管理容器元数据（对象列表 + 统计信息）
       ├── 使用 SQLite 存储
       ├── 维护对象列表（按名称排序）
       ├── 记录对象计数和总字节数
       └── 支持容器 ACL 访问控制

Object Server:

1
2
3
4
5
6
7
8
9
10
11
12

职责:
  └── 对象数据存储与检索
       ├── 以文件形式存储在 XFS 文件系统
       ├── 元数据存储在文件 xattr（扩展属性）
       ├── 基于时间戳的版本管理（Last-Write-Wins）
       ├── 墓碑文件（.ts）标记删除
       └── 支持对象分段上传的合并与读取

时间戳文件:
  ├── {TIMESTAMP}.DATA  → 对象数据文件
  ├── {TIMESTAMP}.META  → 元数据更新文件
  └── {TIMESTAMP}.TS    → 墓碑（0字节删除标记）

3️⃣ Replicator — 副本一致性守护者 🔄

Replicator 负责检测并修复副本不一致，采用 Push 推送模式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Replicator 工作循环:

  ┌─────────────────────────────────────┐
  │ 周期扫描本地所有分区文件              │
  │                                      │
  │ 对每个文件：                          │
  │  1. 查询 Ring 获取该分区的所有副本节点  │
  │  2. 通过 rsync 与远端节点比对          │
  │  3. 若本地文件更新 → push 到远端       │
  │  4. 若远端文件更新 → 本地会被覆盖       │
  │  5. 若本地有墓碑 → push 墓碑到远端      │
  │                                      │
  │ 同步对象：
  │  ├── rsync + hash 比对（对象文件）     │
  │  └── HTTP 或 rsync（SQLite 数据库）    │
  └─────────────────────────────────────┘

关键特性:

• Push 模式的理由: Object Server 只读写入的文件，不主动拉取，Replicator 作为 Push 端主动同步
• 数据库同步: 记录差异小于 1% 时使用 SQLite 差量同步，否则全量传输
• 同步范围: 对象文件、容器数据库、账户数据库

4️⃣ Updater — 异步更新队列 ⏰

当高负载或节点故障导致容器/账户更新失败时，Updater 将更新任务序列化到本地队列异步处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

处理流程:
  PUT 对象 → Proxy Server
       │
       ├── Object Server 写入成功 ✅
       │
       └── Container Server 更新失败 ❌（高负载/temporary unavailable）
                │
                ▼
          写入本地 async_pending 队列
                │
                ▼
           Updater 周期性重试
                │
                ▼
          容器列表最终更新 ✅

这就是最终一致性的主要来源：容器对象列表可能短暂滞后，Updater 保证最终收敛。

5️⃣ Auditor — 完整性审计 🔍

1
2
3
4
5
6
7
8
9
10

周期性扫描:
  ├── 对象审计: 读取文件内容，校验 xattr 元数据一致性
  ├── 容器审计: 校验 SQLite 数据库完整性
  └── 账户审计: 校验 SQLite 数据库完整性

发现问题:
  └── 将损坏文件移动到 /srv/node/{DEVICE}/quarantined/
       ├── 隔离文件不自动删除
       ├── Replicator 检测到缺失后从副本同步恢复
       └── 运维人员可分析隔离区的损坏文件

四、一致性哈希与 Ring 🎯

Ring — 最核心的数据结构

Ring 是 Swift 的灵魂，记录逻辑路径 → 物理位置的映射关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Ring 数据结构:

┌─────────────────────────────────────────┐
│              Ring 对象                   │
├─────────────────────────────────────────┤
│  devs: [                                 │
│    {id:0, zone:1, weight:100,           │
│     ip:"10.0.0.1", port:6200,           │
│     device:"sdb1"},                     │
│    {id:1, zone:2, weight:200, ...},     │
│    ...                                   │
│  ]                                       │
├─────────────────────────────────────────┤
│  _replica2part2dev_id: [                 │
│    [dev_id_A, dev_id_B, dev_id_C],  ← Partition 0 的 3 个副本
│    [dev_id_D, dev_id_E, dev_id_F],  ← Partition 1 的 3 个副本
│    ...                                   │
│  ]                                       │
├─────────────────────────────────────────┤
│  part_shift: 4           ← 分区移位位数  │
│  replica_count: 3        ← 副本数       │
│  part_power: 10          ← 总分区数 2^10│
└─────────────────────────────────────────┘

物理隔离层级（故障域）

1
2
3
4
5
6
7
8

Region (地理区域: 数据中心)
   └── Zone (硬件隔离: 机架/交换机)
        └── Node (服务器节点)
             └── Device (磁盘设备)

Swift 原则:
  同一 Partition 的 Replica 必须分布在不同 Zone 内
  确保任意 Zone 故障不影响所有副本

数据路由流程 🧭

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

对象路径: /v1/AUTH_acc/container/object
                  │
             计算 MD5 哈希
                  │
             取前 4 字节
                  │
        右移 part_shift 位
                  │
   ┌──────────────┴──────────────┐
   │     得到分区编号 Partition   │
   └──────────────┬──────────────┘
                  │
     _replica2part2dev_id[Partition]
                  │
   ┌──────────────┼──────────────┐
   ▼              ▼              ▼
 设备 A (Zone 1) 设备 B (Zone 2) 设备 C (Zone 3)
  ── 主副本 ──  ── 副本 ──  ── 副本 ──
                  │
   Proxy Server 将请求同时发往所有副本节点

虚拟节点（Partition）机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

物理节点与虚拟节点的关系:

   ┌─────────────────────────────────────────┐
   │  总分区数 = 2^part_power               │
   │                                        │
   │  每个物理节点包含 N 个虚拟分区:           │
   │    分区数 ≈ (节点权重 / 总权重) × 总分区数 │
   │                                        │
   │  增减节点的影响:                         │
   │    仅重新分配受影响的分区                │
   │    移动比例 ≈ 1 / 总节点数              │
   │    100 节点集群中仅移动 1% 数据          │
   └─────────────────────────────────────────┘

优势:
  ├── 数据自动均匀分布
  ├── 节点增减仅影响少数分区
  └── 权重支持异构磁盘（如 2TB 权重=100, 4TB 权重=200）

Ring 构建与维护命令 🔧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 1. 创建 Ring
swift-ring-builder OBJECT_BUILDER create PART_POWER REPLICAS MIN_PART_HOURS

# 参数:
#   PART_POWER     分区幂次，总分区数 = 2^PART_POWER（推荐 10~15）
#   REPLICAS       副本数（默认 3）
#   MIN_PART_HOURS 分区最小移动间隔（小时），防止 Rebalance 抖动


# 2. 添加设备
swift-ring-builder OBJECT_BUILDER add Z{ZONE}-{IP}:{PORT}/{DEVICE} WEIGHT

# 参数:
#   Z{ZONE}    故障域编号（如 z1, z2, z3）
#   {IP}       存储节点 IP
#   {PORT}     Object Server 端口（默认 6200）
#   {DEVICE}   磁盘设备名称（如 sdb1）
#   WEIGHT     设备权重（按磁盘容量比例）


# 3. 重新平衡（自动最小化数据移动）
swift-ring-builder OBJECT_BUILDER rebalance

# 4. 查看 Ring 信息
swift-ring-builder OBJECT_BUILDER


# 完整示例（3 节点，3 Zone，每节点 2 块磁盘）:
swift-ring-builder object.builder create 12 3 1
swift-ring-builder object.builder add z1-10.0.0.1:6200/sdb1 100
swift-ring-builder object.builder add z1-10.0.0.1:6200/sdc1 100
swift-ring-builder object.builder add z2-10.0.0.2:6200/sdb1 100
swift-ring-builder object.builder add z2-10.0.0.2:6200/sdc1 100
swift-ring-builder object.builder add z3-10.0.0.3:6200/sdb1 100
swift-ring-builder object.builder add z3-10.0.0.3:6200/sdc1 100
swift-ring-builder object.builder rebalance

五、数据冗余与一致性模型 🛡️

Quorum 仲裁协议

Swift 采用 Quorum 仲裁实现最终一致性：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

写入流程:
  PUT /v1/AUTH_acc/container/object
       │
       ├── 查询 Object Ring → 3 个目标节点（Zone 1, 2, 3）
       │
       ├── Proxy 并发向 3 个 Object Server 发送数据
       │
       ├── 等待至少 W 个成功响应（W=2）
       │
       └── 返回 201 Created 给客户端
                │
         ┌──────┴──────┐
         │             │
      ✅ 成功        ❌ < 2 个成功
                   └── 写入失败，返回 503

读取流程:
  GET /v1/AUTH_acc/container/object
       │
       ├── 查询 Object Ring → 3 个目标节点
       │
       ├── 向 3 个节点发送 GET 请求
       │
       ├── 默认: 等待 1 个成功即返回（R=1，弱一致性）
       │
       │  或使用 X-Newest: true:
       │  └── 对比多个副本的时间戳，返回最新版本（R=2，强一致性）
       │
       └── 返回对象数据 + 元数据

一致性保证: R + W > N（保证读写副本集有交集，避免读取到过期数据）

数据冗余保障机制 🏗️

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

多副本冗余分布:

  ┌── Region 1 ──────────────────────┐
  │  ┌── Zone 1 ──┐ ┌── Zone 2 ──┐  │
  │  │  Node 1     │ │  Node 2     │  │
  │  │  ┌──┐ ┌──┐│ │ ┌──┐ ┌──┐│  │
  │  │  │R1│ │D1││ │ │R2│ │D2││  │
  │  │  └──┘ └──┘│ │ └──┘ └──┘│  │
  │  └───────────┘ └───────────┘  │
  └───────────────────────────────┘
         │
  ┌── Region 2 ──────────────────────┐
  │  ┌── Zone 3 ──┐                  │
  │  │  Node 3     │                  │
  │  │  ┌──┐ ┌──┐│                  │
  │  │  │R3│ │D3││                  │
  │  │  └──┘ └──┘│                  │
  │  └───────────┘                   │
  └──────────────────────────────────┘

  R = 副本 (Replica), D = 非副本数据
  N=3, 跨 Region 分布: Region 1 放 2 副本, Region 2 放 1 副本

数据冗余措施一览:

Handoff 节点故障转移流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

主节点 A 不可用
     │
     ▼
Proxy 尝试写入 → 超时/连接失败
     │
     ▼
查询 Ring 中的 Handoff 节点列表
     │
     ▼
写入 Handoff 节点 H 成功 ✅
     │
     ▼
主节点 A 恢复
     │
     ▼
Replicator 检测到 H 上有 A 的数据
     │
     ▼
Replicator 将数据从 H 复制回 A
     │
     ▼
从 H 删除临时数据，恢复正常拓扑

六、数据存储结构详解 📁

磁盘目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/srv/node/{DEVICE}/
├── accounts/                    账户数据库
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               └── {ACCOUNT}.db  ← SQLite 数据库文件
│
├── containers/                  容器数据库
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               └── {CONTAINER}.db  ← SQLite 数据库文件
│
├── objects/                     对象数据
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               ├── {TIMESTAMP}.DATA   对象数据文件
│               ├── {TIMESTAMP}.META   元数据更新文件
│               └── {TIMESTAMP}.TS     墓碑文件（0字节）
│
├── async_pending/               异步待更新队列
│
├── quarantined/                 隔离目录（损坏数据）
│
└── tmp/                         临时写入目录

说明:
  {PARTITION}:   Ring 计算出的分区号
  {SUFFIX}:      Hash 值的后 3 位（目录散列，避免单目录文件过多）
  {HASH}:        MD5 哈希值
  {TIMESTAMP}:   Unix 时间戳（精确到微秒）

文件系统要求

xattr 存储内容:

1
2
3
4
5
6
7

user.swift.metadata:
  ├── name              对象名称
  ├── content-length    对象大小
  ├── content-type      MIME 类型
  ├── etag              MD5 校验值
  ├── x-object-meta-*   自定义元数据
  └── timestamp         写入时间戳

七、存储策略（Storage Policies, Swift 2.0+）🎯

Swift 2.x 版本引入存储策略机制，支持在 Container 级别指定不同策略：

1
2
3
4
5
6
7
8

# 查看可用策略
swift --os-storage-url <URL> stat

# 创建带策略的容器
openstack container create --STORAGE-POLICY gold-container gold-bucket

# 列出存储策略
swift-list-policies

策略类型

EC vs 副本对比:

1
2
3
4
5
6

3 副本方案:
  数据量: 100GB  实际占用: 300GB  可用率: 33%

EC (6+3) 方案:
  数据量: 100GB  实际占用: 150GB  可用率: 66%
  承受故障: 任意 3 块磁盘

多 Ring 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# /etc/swift/swift.conf
[storage-policy:0]
name = gold
policy_type = replication
default = yes
aliases = gold,3x

[storage-policy:1]
name = silver
policy_type = replication
aliases = silver,2x

[storage-policy:2]
name = archive
policy_type = erasure_coding
ec_type = liberasurecode_rs_vand
ec_num_data_fragments = 6
ec_num_parity_fragments = 3
ec_object_segment_size = 1048576

八、数据流详解 🌊

PUT 写入完整流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

客户端:
  PUT /v1/AUTH_acc/container/object
  └── Content-Length, Content-Type, ETag, X-Auth-Token

Proxy Server:
  ① 验证 Token（Keystone）
  ② 解析路径 → Account=acc, Container=container, Object=object
  ③ 查询 Object.Ring → 分区 1324 → [设备A Zone1, 设备B Zone2, 设备C Zone3]
  ④ 并发流式写入 3 个 Object Server（不缓冲）

Object Server (3 个节点并行):
  ① 接收数据流
  ② 写入 tmp/ 临时目录
  ③ 校验 ETag（MD5）一致性
  ④ 写入 XFS 持久化
  ⑤ 将元数据写入 xattr
  ⑥ 重命名到 objects/{PARTITION}/{SUFFIX}/{HASH}/{TIMESTAMP}.DATA

Proxy Server:
  ⑦ 等待 W=2 个节点成功 ✅
  ⑧ 返回 201 Created

后台 (异步):
  ⑨ 异步更新 Container 对象列表（若失败则 Updater 排队重试）

GET 读取完整流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

客户端:
  GET /v1/AUTH_acc/container/object
  └── X-Auth-Token

Proxy Server:
  ① 验证 Token（Keystone）
  ② 查询 Object.Ring → 分区 1324 → [设备A Zone1, 设备B Zone2, 设备C Zone3]
  ③ 并发向 3 个 Object Server 发起 GET

Object Server (3 个节点):
  ④ 查找 {PARTITION}/{SUFFIX}/{HASH}/{TIMESTAMP}.DATA
  ⑤ 验证 xattr 元数据完整性
  ⑥ 流式返回数据

Proxy Server:
  ⑦ 默认: 取最快返回的一个（R=1）
     或 X-Newest: 取时间戳最新的一个（R=2）
  ⑧ 流式传输给客户端（不缓冲到磁盘）

DELETE 删除流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

客户端:
  DELETE /v1/AUTH_acc/container/object

Proxy Server:
  ① 验证 Token → 查询 Ring → 路由到 3 个副本节点
  ② 并发发送 DELETE 请求

Object Server (3 个节点):
  ③ 不直接删除 .data 文件
  ④ 创建 {TIMESTAMP}.TS 墓碑文件（0字节）
  ⑤ 墓碑的 .ts 时间戳 > .data 文件时间戳

后续:
  ⑥ Replicator 将墓碑传播到所有副本
  ⑦ Auditor 日后扫描时清理旧 .data 文件
  ⑧ Container 对象列表中移除该对象

九、API 与常用操作 📋

RESTful API 端点

常用 Swift CLI 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

# ─── 账户操作 ───

# 查看账户信息
openstack container list
swift list

# ─── 容器操作 ───

# 创建容器
openstack container create <CONTAINER_NAME>
swift post <CONTAINER_NAME>

# 列出容器内容
openstack container show <CONTAINER_NAME>
swift list <CONTAINER_NAME>

# 删除容器（需先清空对象）
openstack container delete <CONTAINER_NAME>

# ─── 对象操作 ───

# 上传对象
openstack object create <CONTAINER_NAME> <LOCAL_FILE>
swift upload <CONTAINER_NAME> <LOCAL_FILE>
#                      ├── --OBJECT-NAME 指定远程对象名
#                      ├── --SEGMENT-SIZE 大对象分段大小（字节）
#                      ├── --SEGMENT-CONTAINER 分段存储容器
#                      └── --CHANGE-DIR 保持目录结构

# 下载对象
openstack object save <CONTAINER_NAME> <OBJECT_NAME>
swift download <CONTAINER_NAME> <OBJECT_NAME>

# 列出对象
openstack object list <CONTAINER_NAME>
swift list <CONTAINER_NAME>

# 删除对象
openstack object delete <CONTAINER_NAME> <OBJECT_NAME>
swift delete <CONTAINER_NAME> <OBJECT_NAME>

# 查看对象详情
openstack object show <CONTAINER_NAME> <OBJECT_NAME>

# 获取临时 URL（限时访问）
swift tempurl GET 3600 /v1/AUTH_acc/container/object <SECRET_KEY>

# ─── 大对象分段上传 ───

# 动态大对象 (DLO): 自动分段
swift upload --SEGMENT-SIZE 1073741824 --SEGMENT-CONTAINER seg-container \
  <CONTAINER_NAME> <LARGE_FILE>
#                      └── --SEGMENT-SIZE 分段大小（本例 1GB）

# 静态大对象 (SLO): 手动分段 + manifest
swift upload --USE-SLO --SEGMENT-SIZE 1073741824 \
  --SEGMENT-CONTAINER seg-container <CONTAINER_NAME> <LARGE_FILE>

TempURL（临时 URL 访问）

1
2
3
4
5
6
7
8
9
10
11
12
13

# 1. 设置密钥
swift post -m temp-url-key:SECRET_KEY

# 2. 生成临时 URL
swift tempurl GET 3600 /v1/AUTH_acc/container/object SECRET_KEY
#                      ├── GET/PUT  HTTP 方法
#                      ├── 3600    有效期（秒）
#                      └── 返回完整 URL（含签名参数）

# 3. 直接通过 URL 访问（无需 Token）
curl -X GET "<TEMP_URL>"

# 用途: CDN 回源、文件分享、第三方下载

ACL（访问控制列表）

1
2
3
4
5
6
7
8
9
10
11
12

# 设置容器 ACL 允许特定用户读
swift post <CONTAINER> -r <USER_ID>
#                      ├── -r 读权限
#                      └── -w 写权限

# 允许所有用户读（公开容器）
swift post <CONTAINER> -r ".r:*,.rlistings"
#                      ├── .r:* 允许所有 Referer 读取对象
#                      └── .rlistings 允许列出容器内容

# 移除 ACL
swift post <CONTAINER> -r ""

十、生产部署最佳实践 ✅

规模建议

十一、应用场景 🎯

与其他存储方案对比:

十二、版本演进趋势 🚀

💡 技术解析

• 术语: Consistent Hashing（一致性哈希） — 分布式系统中控制数据分布的核心算法。增删节点时仅需重新映射 1/N 的数据（N 为节点数），而非全量重新哈希。Swift 通过引入虚拟节点（Partition）进一步提高了平衡性和单调性。

• 术语: Ring — Swift 最核心的数据结构，存储逻辑路径（Account/Container/Object 名）到物理设备（磁盘 IP+端口）的映射。各实体类型有独立 Ring，通过 _replica2part2dev_id 二维数组和 part_shift 实现 O(1) 查找性能。

• 术语: Quorum（仲裁） — 分布式系统中通过多数派投票确保数据一致性的协议。Swift 的 N=3, W=2, R=1 配置下，读写副本集必然存在交集，保证至少有一个副本包含最新数据。条件 R+W > N 是 Quorum 的核心约束。

• 术语: Partition（虚拟节点） — 一致性哈希中引入的虚拟节点概念，是哈希空间中的固定粒度分区。每个物理设备承载多个 Partition，通过增加 Partition 数量（默认物理节点数 × 100）使数据分布更均匀，节点变动时仅影响 1% 的数据项。

• 术语: Handoff（故障转移节点） — 当主副本节点不可用时，Proxy Server 将数据写入临时 Handoff 节点的机制。Handoff 节点是 Ring 中的次优选择，待主节点恢复后由 Replicator 将数据同步回主节点。

• 术语: Tombstone（墓碑） — Swift 的删除标记文件（.ts），0 字节。删除对象时不直接删除数据文件，而是创建时间戳更新的墓碑文件。Replicator 将墓碑传播到所有副本，Auditor 后续清理旧数据文件。这种设计确保删除操作在最终一致性模型下被可靠传播。

• 术语: xattr（扩展属性） — Linux 文件系统的扩展属性机制（Extended Attributes），Swift 用它存储对象的元数据（名称、大小、ETag、Content-Type、自定义元数据等）。要求文件系统支持 xattr（XFS 原生支持，ext4 需 user_xattr 挂载选项）。

• 术语: Zone（故障域） — Swift 中最小物理隔离单元，一般对应一个独立机架。同 Zone 内可有一台或多台服务器。Ring 构建时保证同一 Partition 的 Replica 分布在不同的 Zone 中，确保任意单个机架故障不影响数据完整性。

• 术语: SLO/DLO（静态/动态大对象） — 支持超 5GB 对象的分段上传机制。DLO（动态大对象）使用 manifest 文件动态拼接分段，分段可独立管理。SLO（静态大对象）在 manifest 中固化分段列表（含 ETag），完整性校验更严格。

• 命令: swift-ring-builder — Swift 的 Ring 构建与管理工具。create 指定分区幂次/副本数/最小移动间隔；add 添加存储设备并指定 Zone/权重；rebalance 根据当前设备列表自动计算分区分配方案并最小化数据移动量。生成的 .ring.gz 文件需要分发到所有集群节点。

• 命令: swift upload — 上传对象到 Swift 容器，--OBJECT-NAME 自定义远程对象名，--SEGMENT-SIZE 设置分段大小（大对象自动分段），--CHANGE-DIR 上传时保持本地目录结构。自动基于文件内容计算 ETag（MD5）供完整性校验。

• 命令: swift tempurl — 生成带签名的临时 URL，允许限时免认证访问。GET/PUT 指定 HTTP 方法，`` 指定有效期（秒）。用于 CDN 回源、文件分享、第三方下载等场景。安全性依赖密钥保密性。

OpenStack架构详解：四大节点分工与多节点协同

OpenStack 是一个开源的云计算平台，采用分布式松耦合架构，由四大核心节点各司其职，通过消息总线与 API 协同工作。

一、四大节点核心分工

1. 控制节点（Controller Node）— 🧠 云大脑

集群的管理中枢，承载所有控制平面服务：

生产环境部署 3 个控制节点 组成 HA 集群，通过 Pacemaker + HAProxy 提供 VIP 与负载均衡。

2. 计算节点（Compute Node）— ❤️ 云心脏

虚拟机实例的实际运行场所：

• Nova-Compute：与底层 Hypervisor（KVM/libvirt）交互，管理实例的创建、迁移与终止
• Neutron-Agent：本地虚拟交换（Open vSwitch 网桥、iptables 规则）
• 跨主机 VM 通信通过 VXLAN/GRE 隧道 实现东西向流量直达

3. 网络节点（Network Node）— 🌐 云神经系统

负责南北向流量（外部网络访问）与网络服务：

• L3 Agent：虚拟路由、SNAT/DNAT、浮动 IP
• DHCP Agent：为租户子网动态分配 IP 地址
• Metadata Agent：实例元数据注入

演进趋势：OVN 集成 + DVR（分布式虚拟路由）正取代传统独立网络节点，将网络功能下沉到计算节点，消除单点瓶颈。

4. 存储节点（Storage Node）— 💾 云骨架

二、多节点协同工作流

以 创建一台虚拟机 为例展示完整协作链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

用户请求 (Horizon CLI)
    │
    ▼
┌──────────────────────────────────┐
│ ① Keystone (控制节点)           │
│    身份验证 + 权限校验           │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ② Nova-API (控制节点)           │
│    接收请求，查询服务目录         │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ③ Nova-Scheduler (控制节点)     │
│    过滤+权重算法选择最优计算节点  │
│    → 消息发布至 RabbitMQ         │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ④ Glance (控制节点)             │
│    提供镜像元数据                 │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑤ Neutron-Server (控制节点)     │
│    分配网络端口与 IP              │
│    → 通知网络节点 L3/DHCP Agent  │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑥ Cinder (存储节点)             │
│    创建卷并映射给计算节点（可选） │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑦ Nova-Compute (计算节点)       │
│    从 Glance 下载镜像             │
│    调用 KVM 创建虚拟机             │
│    OVS 接入租户网络               │
│    挂载 Cinder 卷                 │
└──────────────────────────────────┘

三大通信总线：

• RabbitMQ 🐇 — 各组件间的异步消息通信（Nova ↔ Neutron ↔ Cinder 等）
• MySQL（Galera Cluster） 🗄️ — 各组件状态数据的多主同步
• RESTful API 🌍 — 组件间的同步调用，Keystone 提供统一服务目录

三、多网络平面隔离

1

openstack server create --flavor M1.SMALL --image CIRROS --network DEMO-NET --nic NET-ID=XXXXXXXX VM1

多节点协作依赖相互隔离的物理或逻辑网络：

生产规范要求 Management 与 Data 网络物理分离，避免 VXLAN 隧道流量冲击控制平面的消息队列性能。

四、典型部署架构对比

五、技术解析

• 术语: DVR — 分布式虚拟路由技术，每个计算节点独立处理南北向流量，避免传统 L3 Agent 单点瓶颈
• 术语: OVN — Open Virtual Network，Neutron 的下一代后端，原生支持 L2/L3/NAT/ACL，消除 Neutron Agent 运维复杂度
• 术语: Galera Cluster — MySQL 多主同步集群，所有节点可读写，自动处理节点故障，防脑裂
• 术语: Kolla-Ansible — 基于 Docker 容器化部署 OpenStack 的工具，服务启动时间从 15 分钟缩短至 90 秒

六、最佳实践

1. 控制节点至少部署 3 台形成 HA 集群，避免单点故障
2. 生产环境优先使用 OVN + DVR 网络方案，提升网络吞吐与可靠性
3. 存储节点启用 Ceph EC（纠删码）实现数据容错，兼顾空间利用率
4. 使用 Kolla-Ansible 容器化部署，解决传统部署的依赖冲突问题
5. 监控体系采用 Prometheus + Grafana 采集基础设施指标，Ceilometer 记录业务层资源用量

OpenStack 概述

OpenStack 是一个开源的云计算管理平台项目，提供基础设施即服务（IaaS）解决方案，支持公有云、私有云和混合云的建设与管理。

一、起源

OpenStack 于 2010 年 7 月由 NASA 和 Rackspace 合作发起。

1. 背景

• NASA 贡献了其 Nebula 平台的代码，发展成为 Nova（计算组件），负责虚拟服务器部署和业务计算模块
• Rackspace 贡献了其 Cloud Files 平台的代码，发展成为 Swift（对象存储组件），负责分布式云存储模块

2. 发展里程碑

1
2
3
4

2010.07  NASA 与 Rackspace 联合宣布 OpenStack 项目
2010.10  发布首个版本 Austin（Nova + Swift）
2012.09  成立 OpenStack 基金会（非营利组织）
2020     宣布更名为 Open Infrastructure Foundation

• 项目以 Apache 许可证 2.0 授权发布
• 核心代码超过 1000 万行，由 8000+ 开发者贡献了 50 万+ 变更

二、版本演进

OpenStack 采用字母序单词作为版本代号，每半年发布一个新版本。2023 年起改为年份.序号命名格式。

早期版本（2010–2015）

近期版本（2023–至今）

三、核心价值

1. 开源

• 采用 Apache 2.0 许可证，代码完全免费开放
• 社区拥有来自 100+ 国家的数万名开发者和 500+ 企业（Intel、IBM、华为、Red Hat、Cisco 等）

2. 可扩展

• 采用水平扩展架构，无需专有硬件
• 支持从小型单节点到大规模数据中心的各种规模
• 支持 KVM、Xen、Hyper-V、Docker/LXC 等多种虚拟化技术

3. API 驱动

• 各服务之间通过统一 RESTful API 调用，实现系统松耦合
• 组件内部服务之间通过 AMQP（消息队列）交互
• 用户可通过 Web 界面（Horizon）、命令行工具或 RESTful API 管理云资源
• 插件架构：Neutron 支持多种网络后端，Cinder 支持多种存储后端

4. 核心组件一览

架构交互流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

用户 / Horizon / CLI / API 客户端
          ↕  RESTful API
     ┌──────────────────┐
     │   Keystone       │
     │  (身份认证)       │
     └──────────────────┘
          ↕  RESTful API
     ┌────┬────┬────┬────┐
     │Nova│Swift│Glance│Cinder│
     └─┬──┴─┬──┴─┬──┴─┬──┘
       │    │    │    │
     ┌─┴────┴────┴────┴─┐
     │  Neutron          │
     │  (网络服务)        │
     └───────────────────┘
          ↕  AMQP 消息队列
        服务内部通信

总结

OpenStack 始于 2010 年 NASA 与 Rackspace 的合作，历经 15 年发展为全球领先的开源 IaaS 平台，核心价值在于开源生态、水平可扩展、API 驱动的松耦合架构。

OpenStack Swift 对象存储服务概念

Swift 是 OpenStack 平台中的对象存储服务组件，提供高可用、分布式、最终一致性的非结构化数据存储能力，适合存储图片、视频、备份归档等海量数据🗄️。

一、三层数据模型

Swift 采用 Account → Container → Object 三层分层存储结构：

1

Account（账户/项目） → Container（容器） → Object（对象）

1
2

# RESTful API 访问路径格式
GET /V1/{ACCOUNT}/{CONTAINER}/{OBJECT}

⚠️ Swift 不是 POSIX 文件系统，不支持目录嵌套和原地重命名。路径中的 / 只是对象名称中的字符，用于伪目录模拟。

二、核心命令操作

1. 账户操作

1
2
3
4
5

# 查询账户信息
swift stat

# 列出账户下所有容器
swift list

2. 容器操作

1
2
3
4
5
6
7
8
9
10
11

# 创建容器
swift post CONTAINER_NAME

# 列出容器内容
swift list CONTAINER_NAME

# 设置容器读权限（公开访问）
swift post CONTAINER_NAME --read-acl ".R:*"

# 删除容器（需先清空内部对象）
swift delete CONTAINER_NAME

• --read-acl：设置读取权限，.r:* 表示允许所有用户读取
• --write-acl：设置写入权限

3. 对象操作

1
2
3
4
5
6
7
8
9
10
11

# 上传对象
swift upload CONTAINER_NAME LOCAL_FILE_PATH

# 下载对象
swift download CONTAINER_NAME OBJECT_NAME

# 下载到指定文件
swift download CONTAINER_NAME OBJECT_NAME --output LOCAL_PATH

# 删除对象
swift delete CONTAINER_NAME OBJECT_NAME

4. 分段上传（大文件）

1
2
3
4
5

# Swift 自动分段（大于 5GB 必须使用）
swift upload CONTAINER_NAME LARGE_FILE --segment-size 1073741824

# 手动指定分段大小（单位：字节）
swift upload CONTAINER_NAME LARGE_FILE --segment-size 536870912

• --segment-size：分段大小，单位为字节（如 536870912 = 512MB）
• Swift 自动创建 <container>_segments 容器存放分段数据

5. 对象版本控制

1
2
3
4
5
6
7
8

# 开启版本控制（设置历史版本存储容器）
swift post CONTAINER_NAME --history-location HISTORY_CONTAINER

# 上传新版本后，旧版本自动移至 HISTORY_CONTAINER
swift upload CONTAINER_NAME FILE

# 列出版本历史
swift list HISTORY_CONTAINER

• --history-location：指定存储旧版本的容器
• 每次上传同名对象，旧版本自动归档到历史容器

6. 临时 URL 访问

1
2
3
4
5

# 设置账户临时 URL 密钥
swift post --temp-url-key MY_SECRET_KEY

# 生成临时访问 URL（有效期 3600 秒）
swift tempurl GET 3600 /V1/AUTH_PROJECT_ID/CONTAINER/OBJECT MY_SECRET_KEY

• 适用于生成带时效的共享链接，无需暴露账户凭证
• 支持 GET / PUT / DELETE 操作

三、Ring 与一致性哈希

Swift 不依赖中心元数据服务器，通过 Ring（环） 数据结构实现数据路由🗺️：

1

Object名称 → MD5哈希 → Partition索引 → Ring映射 → 物理设备

一致性哈希优势：

• 新增/移除节点时仅需迁移约 1/N 的数据（N=设备总数）
• 去中心化设计，无单点瓶颈
• Proxy 节点通过 Ring 直接定位数据，无需查表

四、数据冗余与复制

副本与 Quorum 协议

Quorum 规则：W + R > N，确保读操作总能读到最新写入的副本。

副本分布策略

副本跨 Zone / Region 分布，确保物理隔离：

1
2
3

Region 1 ─── Zone A ─── Device 1 （副本 1）
          └── Zone B ─── Device 2 （副本 2）
Region 2 ─── Zone C ─── Device 3 （副本 3）

后台一致性守护进程🛡️

五、架构组件

请求处理流程

1
2

客户端请求 ➔ Proxy Server（鉴权 + 路由） ➔ Ring 查找设备
    ➔ 目标存储节点（Object/Container/Account Server） ➔ 返回结果

六、一致性模型与 CAP

Swift 遵循 AP（可用性 + 分区容忍性） 优先策略：

• 最终一致性：写操作在返回确认后，数据会异步传播到所有副本
• 强一致性读：可通过请求头 x-newest: true 强制读取最新副本
• 在 CAP 理论中，Swift 优先保障可用性和分区容忍性，牺牲强一致性

七、性能与限制

八、典型应用场景📂

生产最佳实践⚠️

• 生产环境建议 3 副本跨 3 个以上 Zone 部署，确保故障隔离
• 大文件（> 5GB）务必使用 分段上传，避免单点失败
• 定期监控 Auditor 日志，及时发现和处理静默数据损坏
• 使用 临时 URL 功能分发文件，避免暴露账户凭证
• 通过 ACL 控制 Container 访问权限，不支持单 Object ACL
• 合理设置 Partition 数量，过多增加复制开销，过少影响平衡性
• 关注 Replicator 执行周期，确保复制速度满足数据写入速率

云计算基础概念

一、IaaS / PaaS / SaaS 核心区别 📊

二、公有云 / 私有云 / 混合云 ☁️

三、典型场景 🎯

• IaaS：传统 IDC 迁移上云、大数据集群搭建、游戏渲染
• PaaS：Web/API 后端开发、微服务架构、Serverless 函数计算
• SaaS：企业办公、CRM、项目管理
• 公有云：初创快速启动、电商大促弹性扩容
• 私有云：金融/政务/医疗等强合规行业
• 混合云：核心数据留本地+峰值弹性上云（云爆发）

四、运维特点 🔧

核心趋势：IaaS → PaaS → SaaS，运维工作逐步转移给云厂商，企业角色从”修机器”转向”管资源、定策略” 🔄。

Kubernetes网络模型与实现详解 🌐

CNI 插件配置 🔌

Flannel 安装与配置 🚀

CNI（Container Network Interface） 是Kubernetes标准化的网络插件接口规范，负责容器网络接口的动态配置与管理，实现跨节点Pod间通信和网络资源分配。
安装命令：

1
2
3
4
5
6
7
8
9
10

# 下载 Flannel 配置文件
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# 拉取 Flannel 镜像
docker pull quay.io/coreos/flannel:v0.14.0
# 安装 Flannel
kubectl create -f kube-flannel.yml
# 查看 Flannel 状态
kubectl get pod -n kube-system
# 卸载 Flannel
kubectl delete -f kube-flannel.yml

关键配置参数：

• 网络配置："Network": "10.244.0.0/16" # Pod网络CIDR
• 后端类型："Type": "vxlan" # 虚拟可扩展局域网
• 部署方式：DaemonSet # 每个节点运行一个实例
• CNI 配置路径：/etc/cni/net.d/10-flannel.conflist

Calico 安装与配置 🐱

Calico 是高性能的CNI插件，提供网络策略、BGP路由和细粒度安全控制，支持大规模企业级Kubernetes集群。
安装命令：

1
2
3
4
5
6
7
8

# 下载 Calico 配置文件
wget https://docs.projectcalico.org/manifests/calico.yaml
# 安装 Calico
kubectl apply -f calico.yaml
# 查看 Calico 状态
kubectl get pod -n kube-system | grep calico
# 应用自定义配置
kubectl apply -f calico-installation.yaml

关键配置参数：

• CNI 网络配置："name": "k8s-pod-network" # 网络名称
• 支持网络策略功能 # Pod间访问控制
• etcd 配置（可选） # 分布式键值存储
• MTU 值可调整 # 最大传输单元

Service 类型配置 🌐

ClusterIP Service 🏠

ClusterIP 是Kubernetes默认的Service类型，为集群内部应用提供虚拟IP地址，实现Pod间负载均衡和服务发现。
创建命令：

1
2
3
4
5
6

# 创建 ClusterIP Service
kubectl create service clusterip my-service --tcp=80:80
# 通过 Deployment 暴露
kubectl expose deployment my-app --name=my-service --port=80 --target-port=8080
# 查看 Service
kubectl get services

配置文件示例：

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  type: ClusterIP # 集群内部访问类型
  selector:
    app: my-app # 选择器匹配Pod标签
  ports:
    - protocol: TCP
      port: 80 # Service端口
      targetPort: 8080 # Pod目标端口

NodePort Service 🚪

NodePort 通过每个节点的IP和固定端口向集群外部暴露服务，适合测试环境和小规模部署。
创建命令：

1
2
3
4
5
6

# 创建 NodePort Service
kubectl create service nodeport my-service --tcp=80:80 --node-port=30080
# 通过 Deployment 暴露为 NodePort
kubectl expose deployment my-app --name=my-nodeport-service --port=80 --target-port=8080 --type=NodePort
# 查看 Service
kubectl get services

配置文件示例：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort # 节点端口访问类型
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30080 # 节点端口（30000-32767）

LoadBalancer Service ⚖️

LoadBalancer 通过云提供商的负载均衡器向外部暴露服务，自动分配外部IP，适合生产环境。
创建命令：

1
2
3
4
5
6

# 创建 LoadBalancer Service
kubectl create service loadbalancer my-service --tcp=80:80
# 查看 LoadBalancer Service
kubectl get services
# 查看 LoadBalancer 的外部 IP
kubectl get service my-service -o wide

配置文件示例：

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  type: LoadBalancer # 负载均衡器类型
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Ingress Controller 配置 🛣️

NGINX Ingress Controller 安装 🎯

Ingress Controller 是Kubernetes的HTTP/HTTPS路由控制器，基于域名和路径规则将外部流量路由到内部Service，提供七层负载均衡。
安装命令：

1
2
3
4
5
6
7
8

# 安装 NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/cloud/deploy.yaml
# 或者使用官方 manifests
kubectl apply -f deployments/deployment/nginx-ingress.yaml
# 查看 Ingress Controller 状态
kubectl get pods -n ingress-nginx
# 查看 Ingress Controller Service
kubectl get svc -n ingress-nginx

Ingress 资源配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # URL重写规则
spec:
  ingressClassName: nginx # Ingress类名
  rules:
    - host: my-app.example.com # 域名
      http:
        paths:
          - path: / # 路径匹配
            pathType: Prefix # 前缀匹配类型
            backend:
              service:
                name: my-service # 后端Service名称
                port:
                  number: 80 # 后端Service端口

NGINX Ingress Controller Service 配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-lb
  namespace: kube-system
  labels:
    app: nginx-ingress-lb
spec:
  type: LoadBalancer # 负载均衡器类型
  ports:
    - port: 80 # HTTP端口
      targetPort: 80 # 容器端口
      protocol: TCP
      name: http
    - port: 443 # HTTPS端口
      targetPort: 443
      protocol: TCP
      name: https
  selector:
    app: nginx-ingress-lb # 选择器匹配Pod标签

通用管理命令 🛠️

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 查看所有 Service
kubectl get services --all-namespaces
# 查看 Service 详细信息
kubectl describe service my-service
# 查看 Service 端点
kubectl get endpoints
# 查看 Ingress 资源
kubectl get ingress --all-namespaces
# 查看 Ingress 详细信息
kubectl describe ingress my-ingress
# 查看 CNI 插件状态
kubectl get pods -n kube-system | grep -E 'flannel|calico'
# 查看节点网络状态
kubectl get nodes -o wide

注意事项 ⚠️

• 确保所有命令和配置文件准确无误
• 根据实际环境调整网络配置参数
• 定期检查网络组件状态，确保集群网络正常运行

声明式YAML管理 📄

YAML文件基本结构

YAML文件主要包含四个部分：

1. apiVersion：指定API版本
2. kind：资源类型（如Deployment、Service、Pod等）
3. metadata：元数据（名称、命名空间、标签等）
4. spec：资源规格配置

YAML语法规则

• 大小写敏感 ⚠️
• 使用缩进表示层级关系，不支持Tab键
• 缩进空格数目不重要，相同层级左对齐即可
• 使用#号表示注释 💬
• 符号字符后缩进一个空格（冒号、逗号、横杠等）

声明式管理命令

1
2
3

kubectl create -f XXXX.YAML  # 从YAML文件创建资源
kubectl apply -f XXXX.YAML  # 应用配置变更，支持更新
kubectl delete -f XXXX.YAML  # 根据YAML文件删除资源

kubectl常用命令 ⚡

基础命令

1
2
3
4
5
6
7

kubectl get pod  # 列出所有Pod
kubectl get pod -n NAMESPACE  # 列出指定命名空间的Pod
kubectl get pod -o wide  # 显示详细信息包括IP和节点
kubectl get all  # 列出所有资源
kubectl describe pod POD-NAME  # 显示Pod详细信息
kubectl logs POD-NAME  # 查看Pod日志
kubectl logs -f POD-NAME  # 实时跟踪日志输出

资源管理命令

1
2
3
4
5

kubectl create -f YAML-FILE  # 从文件创建资源
kubectl apply -f YAML-FILE  # 应用配置变更
kubectl delete -f YAML-FILE  # 删除文件中定义的资源
kubectl edit RESOURCE-TYPE RESOURCE-NAME  # 编辑资源配置
kubectl scale deployment DEPLOY-NAME --replicas=3  # 扩缩容到3个副本

部署管理命令

1
2
3
4

kubectl rollout status deployment/DEPLOY-NAME  # 查看部署状态
kubectl rollout history deployment/DEPLOY-NAME  # 查看部署历史
kubectl rollout undo deployment/DEPLOY-NAME  # 回滚到上一版本
kubectl set image deployment/DEPLOY-NAME CONTAINER-NAME=IMAGE:TAG  # 更新容器镜像

故障排查命令

1
2
3
4

kubectl exec -it POD-NAME -- bash  # 进入容器交互式shell
kubectl cp LOCAL-FILE POD-NAME:/path  # 在本地和容器间复制文件
kubectl top pod  # 查看Pod资源使用情况
kubectl top nodes  # 查看节点资源使用情况

Namespace隔离 🏗️

Namespace概念

Namespace是K8s中用于隔离和组织资源的机制，将物理集群划分为多个逻辑部分，每个部分有自己的一组资源 🔄

默认Namespace

• default：所有未指定Namespace的对象默认分配
• kube-system：K8s系统创建的资源 🖥️
• kube-public：可被所有人访问的资源 🌐
• kube-node-lease：节点心跳维护 💓

Namespace管理命令

1
2
3
4
5

kubectl create namespace NAMESPACE-NAME  # 创建命名空间
kubectl get namespace  # 列出所有命名空间
kubectl get ns  # 列出命名空间的简写形式
kubectl delete namespace NAMESPACE-NAME  # 删除命名空间
kubectl config set-context --current --namespace=NAMESPACE-NAME  # 设置当前上下文的默认命名空间

Namespace隔离特性

1. 资源对象隔离：Service、Deployment、Pod等资源在不同Namespace中相互隔离 📦
2. 资源配额隔离：可以限制不同Namespace的CPU、内存使用量 📊
3. 权限控制：通过RBAC对不同Namespace进行权限管理 🔐
4. 网络隔离：默认情况下不同Namespace的Pod可以互相访问，可通过NetworkPolicy实现网络隔离 🌐

网络隔离配置

通过NetworkPolicy实现Namespace间网络隔离：

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all # 拒绝所有网络流量
  namespace: target-ns # 应用到目标命名空间
spec:
  podSelector: {} # 选择所有Pod
  policyTypes:
    - Ingress # 入站流量
    - Egress # 出站流量
  ingress: [] # 空数组表示拒绝所有入站流量
  egress: [] # 空数组表示拒绝所有出站流量

资源配额管理

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota # 配额名称
  namespace: prod # 应用到生产环境命名空间
spec:
  hard: # 硬性限制
    requests.cpu: "1" # CPU请求总量不超过1核
    requests.memory: "1Gi" # 内存请求总量不超过1GB
    limits.cpu: "2" # CPU限制总量不超过2核
    limits.memory: "4Gi" # 内存限制总量不超过4GB
    pods: "10" # Pod数量不超过10个

实际应用场景

1. 按环境划分：dev、test、prod 🌍
2. 按团队划分：不同团队使用不同Namespace 👥
3. 按项目划分：每个项目独立Namespace 📁
4. 多租户隔离：实现资源隔离和权限控制 🏢

私有云 OpenStack 学习路径 🚀

学习私有云 OpenStack 通常建议按”基础概念 → 核心组件 → 架构部署 → 运维排错 → 性能调优”的顺序推进。

1. 第一阶段：云计算与 OpenStack 基础 ☁️

• 云计算基础：IaaS / PaaS / SaaS 区别，私有云 / 公有云 / 混合云概念，典型应用场景与运维特点
• OpenStack 概述：起源（NASA + Rackspace）、主要版本演进、核心价值（开源、可扩展、API 驱动）
• 架构与角色：控制节点、计算节点、网络节点、存储节点的分工，以及多节点协同方式

2. 第二阶段：核心组件（必备）⚙️

Keystone（认证）🔐

• 核心概念：User / Project / Role / Domain / Endpoint / Token
• 认证流程：用户凭据 → Token → 服务访问，理解 Keystone 作为”统一门卫”的角色

Nova（计算）💻

• 架构：nova-api / nova-scheduler / nova-conductor / nova-compute
• 虚拟化支持：KVM / QEMU / Xen 等，虚拟机生命周期与调度策略

Neutron（网络）🌐

• 网络模型：Provider Network / Self-Service Network / 路由器 / 安全组
• 插件架构：ML2 + Linux Bridge / Open vSwitch，理解 SDN 思想与虚拟网络实现

Glance（镜像）📦

• 镜像管理：镜像格式（QCOW2 / RAW / VMDK / ISO）、上传/下载/共享
• 后端存储：本地文件 / Swift / Ceph 等，镜像与后端存储解耦

3. 第三阶段：存储组件（常用）💾

Cinder（块存储）🔲

• 核心功能：为虚拟机提供持久化块存储（卷），创建/挂载/扩展/快照
• 常见后端：LVM / NFS / iSCSI / Ceph RBD / GlusterFS

Swift（对象存储）🗂️

• 核心概念：Account / Container / Object，一致性哈希与数据冗余
• 应用场景：备份归档、图片/视频、非结构化数据存储

4. 第四阶段：管理组件（常用）🎛️

Horizon（Web 界面）🖥️

• 功能：项目/用户/网络/存储/虚拟机的可视化管理与自助服务
• 定制：主题、品牌、功能模块扩展

Heat（编排）🔥

• 核心思想：基于 HOT 模板的基础设施即代码，自动化创建/更新/删除一组资源
• 与 AWS CloudFormation 兼容，理解 stack / resource / parameter

Ceilometer（监控计量）📊

• 数据采集：轮询（polling）与通知（notification），资源使用率与计费数据
• 与告警/计费系统集成，为性能调优和成本分析提供数据基础

5. 第五阶段：架构设计与部署（最低实践要求）🏗️

硬件规划（最低）🖥️

• 控制节点：4 核 CPU / 8 GB 内存 / 100 GB 磁盘 / 千兆网卡
• 计算节点：4 核 CPU（支持硬件虚拟化） / 8 GB 内存 / 100 GB 磁盘 / 千兆网卡
• 存储：可与计算节点合并或独立少量磁盘

网络架构（简化）🔗

• 最少：管理 + 数据 + 存储合一的物理网络，外加单独外部网络
• 生产建议：管理 / 数据 / 存储 / 外部多平面分离，Spine-Leaf 或三层架构

部署工具选择 🛠️

• DevStack：All-in-One 快速实验，适合学习与验证
• Kolla-Ansible：容器化生产部署，推荐用于真实私有云搭建
• TripleO / Packstack：裸机或传统部署方式，按需了解

6. 第六阶段：运维排错思路 🔧

日志与状态 📝

• 日志路径：/var/log/keystone、nova、neutron、glance、cinder 等
• 服务状态：openstack-status / openstack-service status / systemctl status

典型排错流程 🔍

• Keystone：5000/35357 端口、数据库连接、endpoint 配置、Apache 状态
• Nova：nova service-list、虚拟化支持、计算节点服务、调度器日志
• Neutron：neutron agent-list、插件配置、OVS/Bridge 状态、DHCP/L3 代理
• Cinder：cinder service-list、后端连接、卷组空间、日志中的错误信息

监控与备份 📈

• 资源监控：Prometheus + Grafana / Ceilometer，关注 API 响应时间、虚拟机启动时间、存储 I/O
• 备份恢复：数据库每日全量 + 增量、镜像定期备份、配置文件版本控制

7. 第七阶段：性能调优 ⚡

数据库与缓存 🗄️

• MariaDB：innodb_buffer_pool_size / innodb_log_file_size / max_allowed_packet 等参数调优
• Memcached：内存大小 / 最大连接数 / hash 算法调整

计算与调度 🔄

• Nova：CPU/内存超分比（cpu_allocation_ratio / ram_allocation_ratio）、缓存调度器、大页内存

存储与后端 💿

• Cinder：LVM 条带化、SSD 缓存、后端多路径与队列深度
• Ceph：OSD journal / op threads / disk threads 调优

网络与内核 🌐

• OVS：队列长度、DPDK 加速（OVS-DPDK）、VXLAN 封装优化
• 内核：TCP 参数（somaxconn / tcp_window_scaling / tcp_fastopen）、文件系统挂载选项（noatime/nodiratime）、swappiness 调整

应用层与监控闭环 🔄

• API 服务：Worker 数量 / 超时时间 / 连接池配置
• Django/Horizon：会话存储改为文件或缓存，减轻数据库压力
• 调优闭环：先建立性能基线，再用监控工具验证优化效果

8. 学习建议（精炼版）💡

1. 从 All-in-One 开始：先用 DevStack 或单节点 Kolla 跑通最小环境，再扩展多节点
2. 组件逐一实践：每学一个组件（Keystone/Nova/Neutron…）就完成一次部署和配置实验
3. 多看官方文档：OpenStack 官方文档和架构指南是最权威的参考
4. 主动制造故障：停服务、改错配置，练习排错和日志分析
5. 关注性能与监控：从一开始就接入 Prometheus + Grafana，养成”看指标再调参”的习惯
6. 逐步接近生产：从最低硬件与简单网络，演进到多平面网络、高可用控制面和 Ceph 后端

资源监控（Metrics Server）📈

安装和配置

• 准备工作：确保Kubernetes版本1.8及以上，API聚合层必须启用，Kubelet必须启用Webhook认证和授权 ⚙️
• 安装命令：
  • 下载部署文件：wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
  • 高可用版本：kubectl apply -f high-availability-1.21+.yaml
  • 国内镜像替换：将registry.k8s.io/metrics-server/metrics-server:v0.7.2替换为可用镜像地址 🌏

核心参数配置

1
2
3
4
5
6
7

args:
  - --kubelet-insecure-tls
  - --cert-dir=/tmp
  - --secure-port=10250
  - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
  - --kubelet-use-node-status-port
  - --metric-resolution=15s

使用命令

• 查看节点资源使用：kubectl top nodes
• 查看Pod资源使用：kubectl top pods -n <NAMESPACE>
• 验证安装：kubectl get pods -n kube-system | grep metrics-server

日志收集（EFK）📝

EFK架构

• Elasticsearch：分布式搜索和分析引擎，用于存储和索引日志数据 🔍
• Fluentd：日志收集器，作为DaemonSet部署在每个节点上，收集容器日志 🔄
• Kibana：可视化分析平台，提供日志查询和展示界面 📊

部署步骤

1. 创建命名空间：kubectl create namespace logging
2. 部署Elasticsearch：
   • 使用StatefulSet部署ES集群
   • 配置存储卷和环境变量 💾
3. 部署Fluentd：
   • 作为DaemonSet部署，确保每个节点都有实例
   • 配置RBAC权限访问Kubernetes API 🔐
4. 部署Kibana：
   • 使用Deployment部署
   • 配置Service和Ingress暴露服务 🌐

Fluentd配置要点

• 监听路径：/var/log/containers/*.log
• 输出目标：Elasticsearch集群
• 使用kubernetes插件增强日志信息

常见排查命令🔧

基础状态检查

• 查看Pod状态：kubectl get pods -n <NAMESPACE>
• 查看节点状态：kubectl get nodes
• 查看集群事件：kubectl get events --all-namespaces

详细信息查询

• 查看Pod详细信息：kubectl describe pod <POD-NAME> -n <NAMESPACE>
• 查看节点详细信息：kubectl describe node <NODE-NAME>
• 查看Service信息：kubectl describe svc <SERVICE-NAME> -n <NAMESPACE>

日志查看

• 查看容器日志：kubectl logs <POD-NAME> -c <CONTAINER-NAME> -n <NAMESPACE>
• 查看前一次日志：kubectl logs <POD-NAME> --previous
• 实时跟踪日志：kubectl logs -f <POD-NAME>

容器操作

• 进入容器：kubectl exec -it <POD-NAME> -n <NAMESPACE> -- /bin/bash
• 在容器中执行命令：kubectl exec <POD-NAME> -- <COMMAND>
• 文件拷贝：kubectl cp <LOCAL-FILE> <POD-NAME>:<PATH>

网络和存储排查

• 端口转发：kubectl port-forward <POD-NAME> <LOCAL-PORT>:<POD-PORT>
• 检查Endpoints：kubectl get endpoints <SERVICE-NAME> -n <NAMESPACE>
• 检查PVC状态：kubectl get pvc -n <NAMESPACE>

资源监控

• 查看资源使用情况：kubectl top nodes 和 kubectl top pods -n <NAMESPACE>
• 检查API服务器健康：kubectl get --raw=/healthz

常见问题排查

• Pod Pending：检查资源不足、节点Selector不匹配 ⏳
• CrashLoopBackOff：查看应用日志，检查启动命令 🔄
• ImagePullBackOff：检查镜像名称和认证配置 🐳
• Service无法访问：检查Endpoints和网络策略 🌐

Kubernetes安全基础 🛡️

RBAC（基于角色的访问控制）👥

RBAC是一种基于组织中个人用户角色来调节对计算机或网络资源访问的方法。RBAC授权使用rbac.authorization.k8s.io API组来驱动授权决策，允许您通过Kubernetes API动态配置策略。

RBAC核心对象

RBAC API声明了四种Kubernetes对象：

• Role: 定义在特定命名空间内的权限
• ClusterRole: 可在集群范围内使用的权限
• RoleBinding: 将Role绑定到用户、组或ServiceAccount
• ClusterRoleBinding: 将ClusterRole绑定到用户、组或ServiceAccount
  ServiceAccount与Role或ClusterRole绑定后，可以为Pod提供身份标识和访问权限。

Pod Security Policy（Pod安全策略）🚫

⚠️ 注意: PodSecurityPolicy已在Kubernetes v1.21中被弃用，并在v1.25中被移除。
取而代之的是Pod Security Admission（Pod安全准入控制器）或第三方准入插件来对Pod强制执行类似的限制。

Pod Security Admission（Pod安全准入）✅

Pod Security Admission根据Pod安全标准定义的三个级别，对Pod的安全上下文和其他相关字段设置要求。这是Kubernetes引入的一个功能，用于为Pod强制执行清晰一致的隔离级别。

三个安全级别

1. Privileged: 无限制，最宽松的安全策略
2. Baseline: 最小限度的限制，防止已知的权限提升
3. Restricted: 严格限制，最大程度的安全保障

NetworkPolicy（网络策略）🌐

如果您希望在IP地址或端口级别（OSI第3层或第4层）控制流量，NetworkPolicy允许您为集群内的流量以及Pod与外部世界之间的流量指定规则。

使用前提

您的集群必须使用支持NetworkPolicy执行的网络插件。

功能特性

NetworkPolicy是一组规则，用于确定Pod如何相互通信以及与外部服务通信。它提供了集群网络级别的安全控制，可以限制Pod之间的网络访问。

典型应用场景

• 限制Pod之间的网络通信
• 控制Pod与外部服务的访问
• 实现网络分段和隔离
• 防止横向移动攻击

注意事项 ⚠️

• 在生产环境中使用前，建议在测试环境充分验证
• 定期更新安全策略以应对新的安全威胁