一、源码文件位置

核心实现文件

• src/wal.c - WAL 主实现 (约 4700 行代码)
• src/pager.c - WAL 相关的 Pager 层逻辑

配套文件

• src/wal.h - WAL 接口定义
• src/os_unix.c / src/os_win.c - 平台特定的 WAL 实现

源码注释位置

文件开头部分 (行 1-250) 有详细的 WAL 格式说明文档

二、WAL 核心数据结构

2.1 WAL Header (32 字节)

struct {
  u32 magic;           /* 0: 0x377f0682 (小端) 或 0x377f0683 (大端) */
  u32 version;         /* 4: 文件格式版本，当前 3007000 */
  u32 pageSize;        /* 8: 数据库页面大小，如 1024、4096 等 */
  u32 ckptSeq;         /* 12: Checkpoint 序列号 */
  u32 salt1;           /* 16: Salt-1，随机整数，每次 checkpoint 递增 */
  u32 salt2;           /* 20: Salt-2，随机整数，每次 checkpoint 随机化 */
  u32 checksum1;       /* 24: 头部校验和 - 第一部分 */
  u32 checksum2;       /* 28: 头部校验和 - 第二部分 */
} WalIndexHdr;

属性说明：

• Magic Number: 0x377f0682 (小端序) 或 0x377f0683 (大端序)
• Frame Count: WAL 可包含任意数量的帧
• Salt Mechanism: 防止旧帧被误认为是新帧
• Checksum: 使用 Fibonnaci 反向权重算法

2.2 WAL Frame (24 字节 Header + PageData)

struct {
  u32 pageNum;         /* 0: 页面号 */
  u32 dbSize;          /* 4: Commit Marker 时显示数据库大小 (页面数) */
  u32 salt1;           /* 8: 从 WAL Header 拷贝 */
  u32 salt2;           /* 12: 从 WAL Header 拷贝 */
  u32 checksum1;       /* 16: 帧校验和 - 第一部分 */
  u32 checksum2;       /* 20: 帧校验和 - 第二部分 */
  u8 pageData[];       /* 24: 实际页面数据，大小为 pageSize */
} WalFrame;

有效帧验证条件：

1. salt1、salt2 与 Header 匹配
2. checksum1、checksum2 与实际数据一致

2.3 Wal 内部状态结构

struct Wal {
  sqlite3_vfs *pVfs;           /* VFS 模块 */
  sqlite3_file *pWalFd;        /* WAL 文件句柄 */
  sqlite3_file *pDbFd;         /* 数据库文件句柄 */
  int readLock;                /* Reader 锁 ID */
  int writeLock;               /* Writer 锁标志 */
  int ckptLock;                /* Checkpoint 锁标志 */
  int exclusiveMode;           /* 锁定模式 */
  WalIndexHdr hdr;             /* 本地 WAL Header 缓存 */
  u32 aWiData[WAL_NREADER];    /* 共享内存数据 */
  int syncHeader;              /* 是否同步 header */
  int padToSectorBoundary;     /* 是否对齐扇区边界 */
  i64 mxWalSize;               /* WAL 最大大小限制 */
  u32 iCallback;               /* 事务回调帧数 */
  u32 iReCksum;                /* 重计算的位置 */
};

2.4 WalCkptInfo (检查点信息)

struct WalCkptInfo {
  u32 nBackfill;                  /* 已刷入数据库的帧数 */
  u32 aReadMark[WAL_NREADER];     /* 读器标记 */
  u8 aLock[SQLITE_SHM_NLOCK];     /* 锁字节 */
  u32 nBackfillAttempted;           /* 尝试刷入的帧数 */
  u32 notUsed0;                     /* 预留字段 */
};

三、WAL 工作机制详解

3.1 写入流程

1. 打开 WAL 连接 → sqlite3WalOpen()
2. 开始写入事务 → sqlite3WalBeginWriteTransaction()
   - 获取 WAL_WRITE_LOCK (单 writer 锁)
   - 检查 WAL Header 一致性
3. 写入页面帧 → sqlite3WalFrames()
   - 计算 checksum
   - 追加写入到 WAL 文件末尾
   - 更新 wal-index 中的 frame 映射
4. Commit 提交 → FSync + 写 Commit Marker
5. 释放写锁 → sqlite3WalEndWriteTransaction()

核心代码片段：

int sqlite3WalBeginWriteTransaction(Wal *pWal) {
  /* 单 writer 锁，其他 writer 等待或返回 BUSY */
  rc = walLockExclusive(pWal, WAL_WRITE_LOCK, 1);
  
  /* 防止 WAL Header 被其他进程修改 */
  if (memcmp(&pWal->hdr, (void *)walIndexHdr(pWal), sizeof(WalIndexHdr)) != 0) {
    return SQLITE_BUSY_SNAPSHOT;
  }
  return SQLITE_OK;
}

3.2 读取流程

1. 开启读事务 → sqlite3WalBeginReadTransaction()
   - 获取 WAL_READ_LOCK(k)
   - 记录当前 mxFrame 作为快照
2. 查找页面 → sqlite3WalFindFrame()
   - 通过 wal-index 定位帧位置
   - 若找到有效帧则读取
   - 否则从数据库文件读取
3. 读取数据 → sqlite3WalReadFrame()
4. 释放读锁 → 释放 WAL_READ_LOCK(k)

Snapshot 读机制：

• Reader 记录 mxFrame (当前 WAL 中最大有效帧)
• 后续读取时忽略 mxFrame 之后的新帧
• 实现 快照隔离 (Snapshot Isolation)

3.3 Checkpoint 流程

PRAGMA wal_checkpoint;           -- PASSIVE 模式
PRAGMA wal_checkpoint(TRUNCATE); -- RESTART 模式
PRAGMA wal_checkpoint(FULL);     -- FULL 模式

4 种 Checkpoint 模式：

Checkpoint 执行步骤：

int sqlite3WalCheckpoint(Wal *pWal, int eMode) {
  // 1. 获取 checkpoint 锁
  walLockExclusive(pWal, WAL_CKPT_LOCK, 1);
  
  // 2. FULL/RESTART/TRUNCATE 模式获取 writer 锁
  walBusyLock(pWal, ..., WAL_WRITE_LOCK, 1);
  
  // 3. 读取 wal-index 头部信息
  walIndexReadHdr(pWal, &isChanged);
  
  // 4. 将 WAL 帧刷入数据库文件
  walCheckpoint(pWal, db, eMode2, ...);
  
  // 5. 释放所有锁
  walUnlockExclusive(pWal, WAL_CKPT_LOCK, 1);
}

四、文件系统布局

4.1 三文件设计

数据库目录结构：
.
├── mydb                     # 主数据库文件 (通用 header + 页数据)
├── mydb-wal                 # WAL 预写日志文件
└── mydb-shm                 # 共享内存索引文件 (wal-index)

关系说明：

• mydb: 数据库主体，包含 Schema 和用户数据
• mydb-wal: 预写日志，记录修改后的页面帧
• mydb-shm: 共享内存，提供快速查找 WAL 帧位置

4.2 共享内存 (wal-index) 结构

/* 第一部分：Header (136 字节) */
- WalIndexHdr (x2)  : 重复两个，增强可靠性
- WalCkptInfo       : Checkpoint 信息

/* 第二部分：Index Blocks (4096 条目/块) */
- Page Mapping: 帧号到页面号的映射
- Hash Table: 快速定位帧的哈希表

查找算法：

int sqlite3WalFindFrame(Wal *pWal, Pgno pgNo, int *piFrame) {
  // 1. 哈希表查找
  hashLoc = walHashLocation(pgNo);
  
  // 2. 从 wal-index 中定位帧
  for (每个 index block) {
    if (pgNo == pageMapping[i]) {
      *piFrame = i;
      return SQLITE_OK;
    }
  }
  return SQLITE_NOTFOUND;
}

五、并发控制机制

5.1 Lock 类型 (共享内存区域)

WAL_INDEX_LOCK_OFFSET = 120 字节

120: WAL_WRITE_LOCK      -- 写入锁 (单 writer)
121: WAL_CKPT_LOCK        -- Checkpoint 锁
122: WAL_RECOVER_LOCK     -- 崩溃恢复锁
123-127: WAL_READ_LOCK[0-4] -- Reader 锁 (最多 5 个并发 reader)

5.2 锁协议

Reader 协议：

1. 获取 WAL_READ_LOCK(k) (共享锁，非阻塞尝试)
2. 记录 mxFrame 到 aReadMark[k]
3. 读取数据 (忽略 aReadMark 之后的新帧)
4. 释放 WAL_READ_LOCK(k)

Writer 协议：

1. 获取 WAL_WRITE_LOCK (独占锁)
2. 等待所有 active reader 完成 (阻塞或 BUSY)
3. 写入帧到 WAL (追加写)
4. Commit: FSync + 释放 WAL_WRITE_LOCK

Checkpoint 协议：

1. 获取 WAL_CKPT_LOCK (独占锁)
2. FULL/RESTART/TRUNCATE: 额外获取 WAL_WRITE_LOCK
3. 等待所有 active reader 释放
4. 刷 WAL 帧到数据库
5. 更新 salt1/salt2, 释放所有锁

5.3 Reader 锁槽管理

#define WAL_NREADER  5  /* 最大 5 个 reader 锁槽 */

/* 槽分配算法 */
1. 新 reader 尝试：找到 aReadMark 中的最大空闲槽
2. 若所有槽被占用：等待最老 reader 完成
3. aReadMark[0]: 特殊槽，值为 0，表示不使用 WAL，直接读数据库
4. aReadMark[1-4]: 普通 reader 槽，存储 mxFrame 快照

六、Checksum 算法 (亮点)

6.1 算法特点

Fibonacci 反向权重校验和

void walChecksum(u8 *p, int nB, int bigEnd, u32 aCksum[2]) {
  u32 s0 = 0, s1 = 0;
  u32 *pU32 = (u32*)p;
  int n = nB >> 2;  /* 32 位整数数量 */
  
  for (int i = 0; i < n; i++) {
    u32 x = bigEnd ? sqlite3_getint32(pU32) : sqlite3_getlendo32(pU32);
    s0 += x + s1;
    s1 += s0;
  }
  
  aCksum[0] = s0;
  aCksum[1] = s1;
}

权重计算 (反向 Fibonacci):

• x[0] 权重：F(n-1)
• x[1] 权重：F(n-2)
• x[n-1] 权重：F(1) = 1

字节序选择：

• 0x377f0683 大端序 (网络字节序)
• 0x377f0682 小端序 (主机字节序)

6.2 验证流程

// 帧有效验证
if (frame.salt1 != header.salt1 || frame.salt2 != header.salt2) {
  return INVALID_FRAME;  /* 盐值不匹配，废弃 */
}

if (calculatedChecksum != frame.checksum) {
  return CORRUPT_FRAME;  /* 校验和失败，数据损坏 */
}

return VALID_FRAME;

七、WAL 设计优势与劣势

7.1 优势

7.2 劣势

7.3 适用场景

推荐 WAL 模式：

• 高并发读写场景
• 读多写少场景
• 需要快照隔离 (Serializable)
• 需要频繁查询

推荐使用传统 journal 模式：

• 只读数据库 (无并发写入)
• 单用户环境
• 极端内存受限

八、常见问题 (Q&A)

Q1: WAL 与传统 rollback journal 的区别？

A:

Q2: WAL 如何保证 crash recovery 后的数据一致性？

A: 三层保证机制：

1. Salt-1/2 匹配验证

   • 每 checkpoint 变化 salt 值
   • 防止旧帧被误认为是新帧

2. Checksum 验证

   • 使用 Fibonacci 反向权重算法
   • 验证帧的完整性和顺序

3. Commit Marker 标识

   • 每 64 帧记录 Commit Marker
   • 标识事务边界，确保原子性

恢复流程：

1. 读取 WAL Header 和 Frame
2. 验证 checksum + salt 一致性
3. 重放有效帧到数据库
4. 未完成事务的回滚

Q3: Checkpoint 何时触发？

A: 3 种触发方式：

1. 显式调用

   PRAGMA wal_checkpoint;
   

2. 自动触发 (每 1000 帧)

   PRAGMA wal_autocheckpoint = 1000;  -- 默认值
   

3. 客户端断开时触发

触发条件：

1. 显式 PRAGMA wal_checkpoint 调用
2. WAL 帧数达到 wal_autocheckpoint 阈值 (默认 1000 帧)
3. 最后一个客户端断开连接时

Q4: WAL 的内存锁机制如何工作？

A:

共享内存文件 (.db-shm) 布局

Offset 0-119: 未使用
Offset 120:   WAL_WRITE_LOCK (写入锁)
Offset 121:   WAL_CKPT_LOCK    (Checkpoint 锁)
Offset 122:   WAL_RECOVER_LOCK (崩溃恢复锁)
Offset 123-127: WAL_READ_LOCK[5] (读锁槽)

锁实现方式 (平台相关)：

• Unix: 通过 futex 实现
• Windows: 通过 CreateMutexA + WaitForSingleObject 实现
• 跨平台: SQLite 在 os_unix.c / os_win.c 中实现

关键点：

• 使用共享内存实现进程间协调
• 每个锁槽 1 字节，简化锁获取逻辑
• 支持最多 5 个并发 reader

Q5: 什么是 WAL 的 Snapshot Isolation?

A: 通过 aReadMark 实现快照隔离：

// Reader 获取快照
WalIndexHdr hdr;
memcpy(&hdr, walIndexHdr(pWal), sizeof(WalIndexHdr));
mxFrame = hdr.mxFrame;  /* 记录当前最大帧 */

// Reader 读取页面时
int frameNum;
if (walFindFrame(pWal, pgNo, &frameNum, mxFrame)) {
  /* 从 WAL 读取帧 (不超过 mxFrame) */
} else {
  /* 从数据库文件读取 */
}

// 保证一致性
/* 只要 reader 坚持使用原始 mxFrame，就不会看到新提交的数据 */

Snapshot 隔离保证：

• 每个 reader 看到一致的数据库视图
• 不会看到其他事务的未提交数据
• 同一时间点的所有读取看到相同数据

Q6: 为什么需要 salt1/salt2 机制？

A: 3 个原因：

1. 防止 WAL 复用时的混淆 - 防止旧帧被误认为是新帧
2. 防止 Checkpoint 中的竞争 - 确保 new 和 old 帧不会混合
3. 增强数据完整性 - 配合 checksum 确保数据一致性

Salt 变化规则：

salt1++   /* 递增，防止旧帧被复用 */
salt2 = random()  /* 随机化，防止旧帧被误认 */

验证检查：

if (frame.salt1 != hdr.salt1) return INVALID;
if (frame.salt2 != hdr.salt2) return INVALID;

Q7: 为什么 WAL 不会无限增长？

A: 通过 Checkpoint 机制：

/* WAL 生命周期 */
1. 写入帧到 WAL (增长)
2. Checkpoint 刷入数据库 (复用 WAL 空间)
3. 重置 mxFrame = 0，从新位置继续写入

/* 触发条件 */
- 自动：wal_autocheckpoint 帧数 (默认 1000)
- 手动：PRAGMA wal_checkpoint
- 清理：最后一个读者断开

Q8: WAL 中的 Hash 表如何工作？

A: 快速定位帧的 Page Mapping 机制：

/* WalIndexHashLoc (哈希位置) */
struct WalHashLoc {
  u32 iBucket;            /* 哈希桶 */
  u32 iPage;              /* 页面号 */
  u32 iFrame;             /* 帧位置 */
};

/* 查找算法 */
int sqlite3WalFindFrame(Wal *pWal, Pgno pgNo, int *piFrame) {
  /* 1. 计算哈希桶 */
  hash = walHash(pgNo, iChange);
  
  /* 2. 查找 frame 位置 */
  for (i = 0; i < HASH_NPAGE; i++) {
    if (pWal->aPageMapping[hash + i] == pgNo) {
      *piFrame = hash + i;
      return SQLITE_OK;
    }
  }
  return SQLITE_NOTFOUND;
}

关键特性：

• 4096 个条目 的哈希表
• 1 个 hash 桶，支持最多 4096 帧
• 线性查找，碰撞率较低

九、源码关键函数列表

9.1 生命周期管理

9.2 事务处理

9.3 读写操作

9.4 Checkpoint 操作

十、性能优化建议

10.1 参数调优

-- 1. 调整自动 checkpoint 阈值
PRAGMA wal_autocheckpoint = 10000;  -- 默认 1000，可根据场景调整

-- 2. 设置 WAL 文件大小限制 (MB)
PRAGMA wal_size_limit = 1024;  -- 最大 1GB

-- 3. 调整 checkpoint 模式
PRAGMA wal_checkpoint(TRUNCATE);  -- 最积极，立即截断

10.2 设计考量

高频写入场景：

• 调大 wal_autocheckpoint 减少 Checkpoint 频率
• 使用 RESTART 模式 checkpoint
• 增加 wal_max_size 避免频繁截断

高并发读场景：

• 保持默认 autocheckpoint (1000 帧)
• 启用 WAL 共享内存 (支持 5 个 reader)
• 避免使用 TRUNCATE 模式

内存受限场景：

• 使用 smaller wal_page_size (如 2KB)
• 减少 WAL_READER 数量 (最多 5 个)
• 启用 exclusive-mode 减少锁开销

十一、WAL 核心设计思想

11.1 设计哲学

1. Write-Ahead: 事务提交前先写日志 (原子性保障)
2. Copy-on-Write: 读取时复制数据到 WAL (多版本实现)
3. Lightweight: 无需复杂锁定，通过 shm 文件协调
4. Efficient Checkpoint: 批量刷回，避免随机写开销

11.2 关键创新

十二、调试与监控命令

-- 1. 查看当前 WAL 模式
PRAGMA journal_mode;           -- 返回 "wal"

-- 2. 查看 WAL 文件状态
PRAGMA wal_checkpoint;         -- PASSIVE 模式，输出 checkpoint 结果

-- 3. 强制 Checkpoint 并截断 WAL
PRAGMA wal_checkpoint(TRUNCATE);

-- 4. 查看 WAL 配置
PRAGMA wal_autocheckpoint;     -- 显示当前 autocheckpoint 阈值
PRAGMA wal_size_limit;         -- 显示当前 WAL 大小限制

-- 5. 生成 WAL 文件信息
PRAGMA integrity_check;        -- 检查数据库完整性
PRAGMA wal_checkpoint;         -- 检查 WAL 状态

监控指标

• WAL 文件大小 (总帧数)
• Checkpoint 频率
• 锁等待时间 (Writer 等待 Reader)
• 内存使用 (共享内存大小)
• 页面命中率 (从 WAL vs 从数据库)

十三、总结

WAL 的核心价值

1. 高并发: Reader/Writer 可并行执行，极大提升并发能力
2. 数据一致性: Salt + Checksum 双重保障，确保原子性
3. 灵活 checkpoint: 支持 4 种模式，适应不同场景需求
4. 轻量级锁机制: 通过 shm 文件实现，无需复杂内核锁
5. Crash Recovery 快速: 重放有效帧，无需复杂回滚

附录：常用命令参考

# 1. 编译 SQLite 源码
./configure --enable-wal
make -j$(nproc)

# 2. 运行测试
make test

# 3. 查看 WAL 源码结构
find src/wal*.c -type f | head -10

# 4. 生成 WAL 状态报告
./sqlite3 test.db "PRAGMA journal_mode=wal; PRAGMA wal_checkpoint; PRAGMA integrity_check;"

# 5. 分析 WAL 文件二进制格式
hexdump -C test.db-wal | head -50

# 6. 查看共享内存结构
ls -lh test.db-wal test.db-shm

文档生成时间: 2026-03-30
SQLite 源码版本: 查看 VERSION 文件
源码目录: /Volumes/790/Codes/sqlite/src/wal.c

快速查阅表

建议阅读顺序: WAL Header 设计 → 核心结构体 → Checkpoint 算法 → 查找算法 → 源码注释详解

The old table

CREATE TABLE "users" (
	"id"	INTEGER NOT NULL,
	"created_at"	INTEGER NOT NULL DEFAULT CURRENT_TIMESTAMP,
	"password"	TEXT NOT NULL,
	PRIMARY KEY("id" AUTOINCREMENT)
);

Rename table

ALTER TABLE "users" RENAME TO "users_old";

The new table

CREATE TABLE "users" (
	"id"	INTEGER NOT NULL,
	"created_at"	TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	"password"	TEXT NOT NULL,
	PRIMARY KEY("id" AUTOINCREMENT)
);

Migrate data from old table

INSERT INTO "users" (id, created_at, password)
SELECT
	id, created_at, password
FROM "users_old";

Delete old table

DROP TABLE "users_old";

Confirm data

Double check if the created_at type is TIMESTAMP

Notes

1. Backup data
2. Data check
3. If created_at is not timestamp style, need transform.

格式：

// kind（可选）：指定库类型，如 static（静态库）、dylib（动态库，默认值）。
// name：库的名称，例如 virt。
println!("cargo:rustc-link-lib={kind}={name}");

eg:

println!("cargo:rustc-link-lib=virt"); // 链接动态库 libvirt
println!("cargo:rustc-link-lib=static=foo"); // 链接静态库 libfoo.a

2. cargo:rustc-link-search 用于指定 Cargo 搜索库文件的路径。

格式：

// kind（可选）：路径类型，如 native（默认值）。
// path：库所在的路径。
println!("cargo:rustc-link-search={kind}={path}");

eg:

println!("cargo:rustc-link-search=/opt/homebrew/lib"); // 在该路径下搜索库
println!("cargo:rustc-link-search=native=/custom/path"); // 指定为 native 类型路径

3. cargo:rerun-if-changed 告诉 Cargo，当指定的文件改变时，重新运行 build.rs。

格式：

println!("cargo:rerun-if-changed={file}");

eg:

println!("cargo:rerun-if-changed=build.rs"); // 当 build.rs 发生改变时重新运行
println!("cargo:rerun-if-changed=src/lib.rs"); // 监视其他文件

4. cargo:rerun-if-env-changed 当指定的环境变量改变时，重新运行 build.rs。

eg:

println!("cargo:rerun-if-env-changed=MY_ENV_VAR");

5. pkg-config 或其他工具输出的指令 如果使用 pkg-config，它会自动输出 cargo:rustc-link-lib 和 cargo:rustc-link-search 的指令。例如：

fn main() {
    pkg_config::Config::new()
        .atleast_version("1.0")
        .probe("libvirt")
        .unwrap();
}

这个调用会检测 libvirt 是否存在，并自动生成指令。

如何确定你需要的指令？

1. 阅读库文档：查看你需要链接的 C/C++ 库的安装路径、库名称。
2. 查找库文件：检查系统中安装的库（如 libvirt），通过以下命令找到路径：

macOS/Linux:

pkg-config --libs --cflags libvirt

输出可能包含路径和库名称：

-L/opt/homebrew/lib -lvirt

对应 cargo:rustc-link-search 和 cargo:rustc-link-lib。

double check：

find /usr /opt/homebrew -name "libvirt*"

3. 调试构建脚本：运行 cargo build，观察报错提示。例如，如果提示 libvirt 未找到，检查是否需要调整库路径或库名称。

总之，需要通过调试和确认依赖信息逐步完善 build.rs 文件。

CIRD 是一个无类别域间路由的IP分配方法。

IP地址格式

有类地址

1. A类，IPv4地址有8个网络前缀位，可分配16777214个IP地址。如：192.0.0.1，其中192是网络地址，0.0.1是主机地址
2. B类，IPv4地址有16个网络前缀位，可分配65534个IP地址。如：192.168.0.1，其中192.168是网络地址，0.1是主机地址
3. C类，IPv4地址有24个网络前缀位，可分配254个IP地址。如：192.168.1.100，其中192.168.1是网络地址，100是主机地址

无类地址

该方式使用可变长度子网掩码（VLSM）来改变IP地址中网络地址和主机地址位之间的比率。子网掩码是一组标识符，通过将主机地址变为0，从IP地址返回网络地址的值。

VLSM序列允许网络管理员将IP地址空间分解位不同大小的子网，每个子网可以有灵活的主机数量和有限的IP地址数量。CIDR IP地址在普通IP地址的基础上加了一个后缀值，说明网络地址前缀位数。

如：192.168.0.0/24是一个IPv4 CIDR地址，其中前24位（192.168.0）是网络地址。

CIDR 优势

1. 减少IP地址浪费，如用户需要一个包含300个IP地址的网段，如果使用有类地址，需要分配一个B类(65534=256*256-2)地址，但是这会造成极大的资源浪费。如果使用CIDR的IP分配方式，如：192.168.0.0/23，则可以避免这类问题。具体的ip地址范围，可是使用ipcalc来查看对应的IP地址范围
2. 快速传输数据。因为CIDR策略可以有效的将IP地址组织成多个子网，子网存在与网路中的较小网络，减少了路由器的路由次数，进一步也就减少了数据拷贝的次数，因而效率更高。
3. 创建虚拟私有云（VPC）。允许用户在隔离且安全的环境中配置工作负载，但这种需求使用有类地址也可以做到。
4. 灵活创建超网。超网是一组具有相似网络前缀的子网，CIDR允许灵活创建超网，这在传统的掩码架构（即有类地址）中使不可能的。如：192.168.1/23与192.168.0/23，这种方式将255.255.254.0的子网掩码应用于IP地址，该IP地址将返回前23位作为网络地址，路由器只需要一个路由表条目即可管理子网设备之间的数据包。

CIDR 工作原理

CIDR允许网络路由器根据指定的子网将数据包路由到相应的设备。路由器不是根据类别对IP地址分类，而是检索CIDR后缀指定的网络和主机地址。

CIDR块

CIDR数据块是共享相同网络前缀和位数的IP地址集合。一个大数据块有更多IP地址和一个小后缀组成。如：

master CIDR Block: 10.10.0.0/16

subnet 1: 10.10.1.0/24
subnet 2: 10.10.2.0/24
subnet 3: 10.10.3.0/24
subnet 4: 10.10.4.0/24
subnet 5: 10.10.5.0/24
...

This operation will lead the kube cluster unavailable for some minutes. Take care.

Releated files and kube objects

1. /etc/kubernetes/manifest/kube-apiserver.yaml
2. kubectl -n kube-system edit svc/kube-dns
3. /var/lib/kubelet/config.yaml
4. kubectl -n kube-system edit cm kubelet-config

Update kube-apiserver manifest

# vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
spec:
  containers:
  - command:
    - kube-apiserver
...
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=100.96.0.0/12   # Change
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
...

Edit kube-dns service

# kubectl -n kube-system edit svc kube-dns
...
# in the service YAML, modify the 'strategy'. save and quit to apply the changes!
spec:
  clusterIP: 100.96.0.10 # Change
  clusterIPs:
  - 100.96.0.10 # Change
  internalTrafficPolicy: Cluster
...

Replace kube-dns

kubectl replace -f /tmp/kubectl-edit-3485293250.yaml --force 

# see the new IP address given to the service
kubectl -n kube-system get svc

controlplane $ kubectl -n kube-system get svc
NAME       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   100.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   6s

Update kubelet config

# vim /var/lib/kubelet/config.yaml 
# within the config.yaml file, change the clusterDNS value to 100.96.0.10
...
cgroupDriver: systemd
clusterDNS:
- 100.96.0.10 # Change
clusterDomain: cluster.local
...

Update kubelet-config configmap

# kubectl -n kube-system edit cm kubelet-config
# in the kubelet configMap, change the value for clusterDNS to 100.96.0.10
...
data:
  kubelet: |
...
    cgroupDriver: systemd
    clusterDNS:
    - 100.96.0.10 # Change
    clusterDomain: cluster.local
...

Update configmap, kubelet service

# apply the update to the kubelet configuration immediately on the node
kubeadm upgrade node phase kubelet-config
systemctl daemon-reload
systemctl restart kubelet

Verifing

# start a pod named 'netshoot' using the image 'nicolaka/netshoot' ensuring that the pod stays in a running state.
kubectl run netshoot --image=nicolaka/netshoot --command sleep --command "3600"

# login the checking pod container
kubectl exec netshoot -it -- /bin/bash

# cat the /etc/resolv.conf
cat /etc/resolv.conf

nslookup kubernetes.default

snapshot

# list the snapshots
qemu-img disk_image.qcow2 snapshot -l
# create snapshot
qemu-img disk_image.qcow2 snapshot -c snapshot_name
# apply a snapshot
qemu-img disk_image.qcow2 snapshot -a snapshot_name

1. 使用 API 对象应用策略
   • NetworkPolicy 用于限制工作负载的出入站流量
   • LimitRange 管理多个不同对象类别的资源分配约束
   • ResourceQuota 限制命名空间的资源消耗
2. 使用准入控制器应用策略 准入控制器允许在 API 服务器上，可以验证或变更 API 请求，某些准入控制器用于应用策略。例如：AlwaysPullImages 准入控制会将 Pod 中容器的镜像拉取策略设置为 Always
3. 使用 ValidatingAdmissionPolicy 应用策略 允许使用表达式语言 CEL 在 API 服务器中执行可配置的验证检查。如：ValidatingAdmissionPolicy 用于禁止使用 latest 镜像标签
4. 使用动态准入控制 提供给用户自定义准入控制的一种方式，用户可以自定义自己的准入控制，然后在运行时动态加载到 kube-apiserver 的准入控制验证或变更中。
   • kubewarden 基于 Wasm 的准入控制，允许用户通过自定义策略检查 kubernetes 对象，如 Pod，Deployment，Service 等的创建，更新和删除请求，并在请求被接受或拒绝时执行这些策略
   • kyverno 用于实施声明式的策略管理，允许 kubernetes 用户定义和实施基于资源的策略
   • OPA Gatekeeper 用于执行和管理策略
   • Polaris 提供对集群健康和最佳实践的自动化检查和建议，可以帮助用户识别和解决潜在的问题
5. 使用 kubelet 配置应用策略，kubernetes 允许每个节点上配置 kubelet，一些 kubelet 配置可以视为策略。
   • 进程 ID 限制和保留：限制或保留可分配的 PID
   • 节点资源管理器：为低延迟和高吞吐量的工作负载管理 CPU，内存和其他设备资源

LimitRange

默认情况下，kubernetes 集群上的容器运行使用的计算资源没有限制。使用命名空间资源配额，可以限制命名空间的资源使用上限；使用 LimitRange 可以限制一个 Pod 可以使用的资源上限和下限。LimitRange 提供限制能力包括：

1. 限制在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量
2. 限制在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小
3. 控制在一个命名空间中实施对一种资源的申请值和限制值的比例
4. 设置在一个命名空间中对计算资源的默认申请和限制值，并且自动的在运行时注入到多个 Container 中

资源限制和请求的约束

注意事项：

1. LimitRange 仅在 Pod 准入阶段进行，不对任何正在运行的 Pod 进行验证。如果添加 namespace resourceQuota 时已有对应运行的 Pod 且 Pod 添加了 resourceQuota，则 namespace 配额会更新已使用的配额。
2. 如果一个命名空间中存在多个 LimitRange，则应用哪个默认值是不确定的。

Pod 的 LimitRange 和准入检查

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
    - default:
        cpu: 500m # 如果没有定义containers[*].resources.limits.cpu，那将使用此值
      defaultRequest:
        cpu: 500m # 如没有定义containers[*].resources.requests.cpu，那将使用此值
      maxLimitRequestRatio:
        cpu: "10" # 表示对于非零的containers[*].resources.[limits/requests].cpu，每个容器的limits.cpu最大可以是requests.cpu的10倍
      max:
        cpu: "1" # 限制container.resource.cpu.limit的最大值为1000m
      min:
        cpu: 100m # 限制container.resource.cpu.limit的最小值为100m
      type: Container # 作用在containers上，包括initContainers

资源配额

通过ResourceQuota对象来定义，对每个命名空间的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源总上限。工作方式如下：

1. 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象
2. 当用户在命名空间下创建资源（如 Pod，Service 等）时，kubernetes 的配额系统会跟踪并确保资源用量不会超过 ResourceQuota 中定义的硬性资源限额
3. 如果资源创建或者更新违反了配额约束，则该请求会报 http 403 FORBIDDEN 的错误，并在消息中给出有可能违反的约束
4. 如果命名空间下的计算资源被配额被启用，则 Pod 的创建必须指定资源的 request 和 limit，否则无法创建 Pod。当然，如果使用了 LimitRanger 准入控制器，Pod 没有配置资源用量，则 LimitRanger 会为这些 Pod 设置默认值。

NOTES: 对于其他资源：ResourceQuota 可以工作，并且会忽略命名空间中的 Pod，而无需为该资源设置 limit/request 限额。这意味着，即便资源配额限制了此命名空间的临时存储，也可以创建没有 limit/request 临时存储的新 Pod。也可以使用 LimitRange 自动设置对这些资源的默认值。

启用资源配额

kube-apiserver --enable-admission-plugins=ResourceQuota，若命名空间中存在 ResourceQuota 对象，则该命名空间的资源配额就是开启的。

计算资源配额

扩展资源的配额

由于扩展资源不可超量分配，因此没有必要在配额中为同一扩展资源同时指定 requests 和 limits，对于扩展资源目前仅允许使用前缀为requests.的配额项。如：requests.nvidia.com/gpu: 4，限制请求的 GPU 用量为 4。

存储资源配额

用户可以对给定命名空间下的存储资源总量进行限制，还可以根据相关的 StorageClass 来限制存储资源的消耗。

在 v1.8 版本中，本地临时存储的配额支持已经是 alpha 功能：

NOTES: 如果所使用的是 CRI 容器运行时，容器日志会被记入临时存储配额。这可能会导致存储配额耗尽的 Pod 被意外地 evict 节点。

对象数量的配额

可以使用以下语法对所有标准的、命名空间域的资源类型进行配额限制：

• count/<resource>.<group> 用于非 core 组的资源
• count/<resource>用于 core 组的资源

也可以用于自定义资源，如：要对example.comAPI 组中的自定义资源widgets设置配额，count/widgets.example.com。

当使用count/*资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。如：集群中存在过多的 Secret 实际上会导致服务器无法启动；配置不当的 CronJob 在命名空间中创建太多 Job 而导致集群拒绝服务。

配额作用域

resourcequota.spec.scopeSelector,resourcequota.spec.scopes：每个配额仅会对作用域内的资源生效，配额机制仅统计所列举的作用域的交集中的资源用量。

当一个作用域被添加到配额中后，它会对作用域相关的资源数量作限制。如配额中制定了允许（作用域）集合之外的资源，会导致验证错误。

scopeSelector:
  matchExpressions:
    - scopeName: PriorityClass
      operator: In
      values:
        - middle

基于 PriorityClass 来设置资源配额

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high
value: 1000
description: A demo high priority.
---
apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
    - name: high-priority
      image: ubuntu
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo hello; sleep 10;done"]
      resources:
        requests:
          memory: "10Gi"
          cpu: "500m"
        limits:
          memory: "10Gi"
          cpu: "500m"
  priorityClassName: high

跨名字空间的 PodAffinity 配额

apiVersion: v1
kind: ResourceQuota
metadata:
  name: disable-cross-namespace-affinity
  namespace: foo-ns
spec:
  hard:
    pods: "0" # 禁用了该名字空间创建Pod
  scopeSelector:
    matchExpressions:
      - scopeName: CrossNamespacePodAffinity
        operator: Exists # 如果存在跨命名空间Pod亲和性功能，则应用该资源配额

禁止使用CrossNamespacePodAffinity或CrossNamespacePodAntiAffinity，可以配置kube-apiserver --admissiion-control-config-file=<下面的yaml>

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: "ResourceQuota"
    configuration:
      apiVersion: apiserver.config.k8s.io/v1
      kind: ResourceQuotaConfiguration
      limitedResources:
        - resource: pods
          matchScopes:
            - scopeName: CrossNamespacePodAffinity
              operator: Exists # 当存在跨命名空间Pod亲和性功能时应用资源配额的限制

进程 ID 约束与预留

kubernetes 允许用户限制一个 Pod 中可以使用的 PID 数目。用户也可以为每个节点预留一点数量的可分配的 PID，供操作系统和守护进程（非 Pod）使用。

PID 时节点上的一种基础资源。很容易就会在尚未超出其他资源约束的时候就已经触及任务个数上限，进而导致宿主机不稳定。

集群管理员需要一定的机制来确保集群中运行的 Pod 不会导致 PID 资源枯竭，甚至造成宿主机上的守护进程（如：kubelet 或 kube-proxy，以及容器运行时本身）无法正常运行。此外，确保 Pod 中的 PID 的个数受限对于保证其不会影响到同一节点上其他负载也很重要。

NOTES: 默认 PID 上限可能为 32768，用户可以通过修改/proc/sys/kernel/pid_max来扩大 PID 的上限。

节点级别 PID 限制

可以为 kubelet 使用--system-reserved和--kube-reserved命令行选项参数pid=<number>，分别对应整个操作系统和 kubernetes 系统守护进程所保留的 PID 数目。

Pod 级别的 PID 限制

也可以限制 POD 中的 PID 个数，在节点级别设置这一限制，而不是为特定的 Pod 来将其设置为资源限制，每个节点都可以有不同的 PID 限制设置。使用kubelet --pod-max-pids或者在 kubelet 配置文件中设置PodPidsLimit。

基于 PID 的 eviction

可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。可以针对不同的驱逐信号配置资源不足的处理。使用pid.available驱逐信号来配置 Pod 使用的 PID 个数的阈值，可以设置硬性的和软性的驱逐策略。不过即使使用硬性的驱逐策略，如果 PID 个数增长过快，节点仍然可能因为初级节点 PID 限制而进入一种不稳定状态。驱逐信号的取值时周期性计算的，而不是一直能够强制实施约束。

Pod 级别和节点级别的 PID 限制会设置硬性限制，一旦触及限制，工作负载会在尝试获得新的 PID 时遇到问题。这可能会也可能不会导致 Pod 被重新调度，取决于工作负载如何应对这类失败以及 Pod 的存货行和就绪态探测时如何配置的。可是，如果限制值被正确设置，用户可以确保其他 Pod 负载和系统进程不会因为某个 Pod 行为不正常而没有 PID 可用。

节点资源管理器

kubernetes 提供了一组资源管理器，用于直至延迟敏感的、高吞吐量的工作负载。资源管理器的目标时协调和优化节点资源，以支持对 CPU、设备和内存（hugepage）等资源有特殊需求的 Pod。

主管理器（Topology Manager），是一个 kubelet 组件，通过策略，协调全局的资源管理过程。

各个管理器的配置方式会在专项文档中详细阐述。

CPU 管理器

默认情况下，kubelet 使用[CFS 策略]来执行 Pod 的 CPU 约束。当节点上运行了很多 CPU 密集的 Pod 时，工作负载可能会迁移到不同的 CPU 核，这取决于调度时 Pod 是否被扼制，以及哪些 CPU 核是可用的。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。

然而，有些工作负载的性能明显地收到 CPU 缓存亲和性以及调度延迟的影响。对此 kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。

要配置 CPU 管理策略，可以通过kubelet --cpu-manager-policy或使用KubeletConfiguration中的cpuManagerPolicy字段来指定，支持 2 中策略：

1. none: 默认策略
2. static: 允许为节点上具有某些资源特征的 Pod 赋予增强的 CPU 亲和性和独占性。

CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过 kubelet 配置参数--cpu-manager-reconcile-period设置，如不指定，默认与--node-status-update-frequency的周期相同。

Static 策略的行为可以使用--cpu-manager-policy-options=key1=value1,key2=value2参数来微调。

除了顶级的 CPUManagerPolicyOptions feature gate，策略选项分为 2 组：alpha（默认隐藏）和 beta（默认可见）。分别由CPUManagerPolicyAlphaOptions和CPUManagerPolicyBetaOptionsfeature gate 来管控。

内存管理器

使用 NUMA（Non-Uniform Memory Access）为 Guaranteed QoS 类的 Pods 提供可保证的内存及 hugepage 分配能力。

内存管理器使用提示生成协议来为 Pod 生成最合适的 NUMA 亲和性配置。内存管理器将这类亲和性提示输入给中央管理器（Topology Manager）。基于所给的提示和 Topology Manager 的策略设置，Pod 或者会被某节点接受，或者被该节点拒绝。

此外，内存管理器还全包 Pod 所请求的内存是从尽量少的 NUMA 节点分配而来。

内存管理器仅使用与 Linux 主机。

设备管理器 TBD

RBAC

基于角色的访问控制，通过集群管理员指定用户拥有的权限，使用时经过授权模块赋予对应的权限。

支持权限的降级，但不支持权限的升级，如 RoleBinding（作用域为 namespace）可以绑定到 ClusterRole，但是不能将 ClusterRoleBinding（作用域为 cluster）绑定到 Role。

对于普通用户名或用户组的限制，其中前缀是system:为 kubernetes 系统保留的，禁止用户使用前缀为此的用户名称或组名称。

对于服务账户和服务账户组，分别需要包含system:serviceaccount:和system:serviceaccounts:前缀。

对于需要修改用户或组的 RoleBinding 或者 ClusterRoleBinding，系统不支持修改，需要删除后重新添加。

默认的 Roles 和 RoleBindings

对集群默认角色、名称、以及绑定关系的修改，都将可能导致集群无法工作，需要格外小心。

1. 集群中以system:为前缀的，用以标识对应资源是直接由集群控制面管理的。
2. 所有默认的 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults标签
3. 自动协商机制保证，每次集群启动时，kube-apiserver 都会更新默认 ClusterRole 以添加各类缺失的权限，并更新 ClusterRoleBinding 以添加各类缺失的主体，可修复一些不小心发生的修改，并有助于保证角色和角色绑定在新的发行版中保持最新状态。

kube-apiserver 发现角色

默认的角色绑定赋予所有人（包括匿名用户）可以访问对于被集群认为是安全公开的 API，如果要禁用匿名用户访问可以配置kube-apiserver --anonymous-auth=false。

默认的面向用户的角色

如cluster-admin是系统超级管理员角色，cluster-status是 ClusterRoleBinding 在集群范围内完成授权的角色，admin、edit、view是使用 RoleBinding 在特定名字空间内授予的角色

Core component roles

服务账户权限

默认的 RBAC 策略为控制面组件、节点和控制器授予权限，但不会对 kube-system 以外的服务账户授予权限，除了授予所有已认证用户的发现权限。

从最安全到最不安全的服务账户权限配置，推荐顺序如下：

1. 为特定应用的服务账户授予角色
2. 将角色授予某名字空间中的 default 服务账户，如果没有指定服务账户，将使用默认的 default 服务账户
3. 将角色授予名字空间中所有服务账户
4. 在集群范围内为所有服务账户授予一个受限角色（不推荐）
5. 授予超级用户访问权限给集群范围内的所有服务账户（强烈不推荐）

ABAC

基于属性的访问控制

使用 Node 授权

该方式是专门针对 kubelet 发出的 API 请求进行授权

准入控制器可以执行 Validating 和 Mutating 操作。准入控制器限制创建、删除、修改对象的请求，也可以阻止自定义 verbs，如通过 api 代理服务器连接到 Pod 的请求。准入控制器不能阻止 get、watch 或 list 对象的请求。

有 2 个特殊的准入控制器：MutatingAdmissionController 和 ValidatingAdmissionController，分别执行变更和验证准入控制 Webhook。

准入控制阶段

1. 运行 MutatingAdmissionControl
2. 运行 ValidatingAdmissionControl

某些 AdmissionController 即是 MutatingAdmissionController，又是 ValidatingAdmissionController。

如果某个请求在 2 个阶段的其中一个被拒绝，则整个请求立即被拒绝，并返回错误。

准入控制器有其他副作用，将相关资源作为请求处理的一部分进行变更。如增加资源配额。任何一个准入控制器都无法确定其他准入控制器的需求，只有当请求符合所有的准入控制器的要求，才会被 kube-apiserver 正确处理。

启用准入控制器

kube-apiserver --enable-admission-plugins=NamespaceLifeCycle,LimitRanger ...

关闭准入控制器

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

默认启用的准入控制器

• CertificateApproval
• CertificateSigning
• CertificateSubjectRestriction
• DefaultIngressClass
• DefaultTolerationSeconds
• LimitRanger
• MutatingAdmissionWebhook
• NamespaceLifeCycle
• PersistentVolumeClaimResize
• PodSecurity
• Priority
• ResourceQuota
• ServiceAccount
• StorageObjectInUseProtection
• TaintNodesByCondition
• ValidatingAdmissionPolicy
• ValidatingAdmissionWebhook

每个准入控制器的作用

• LimitRanger: 监测传入的请求，确保不会违反 Namespace 中 LimitRange 对象所设置的任何约束；还可以用于将默认资源配额应用到没有设定资源配额的 Pod
• NamespaceLifeCycle：会禁止在一个正在被删除的 Namespace 中创建新对象，并确保针对不存在的 Namespace 的请求被拒绝；会禁止删除系统中的保留命名空间：default,kube-system,kube-public

准入控制器列表 推荐的准入控制器

动态准入控制器

除了编译到 kube-apiserver 中的准入控制器，还支持在运行时动态使用的准入控制器。

准入 Webhook

是一种用于接受准入请求并对其进行处理的 HTTP 回调机制。可以定义 2 种类型的准入 Webhook：ValidatingAdmissionWebhook,MutatingAdmissionWebhook。其中 Mutating 性质的 Webhook 被先调用，然后执行 Validating 的 Webhook。

用户可以实现自己的准入 Webhook 动态加入到 kube-apiserver 的准入控制中。自定义准入 webhook

监控准入 Webhook

1. 哪个变更性质的 Webhook 改变了 API 请求中的对象
2. 变更性质的 Webhook 对对象做了那些修改
3. 哪些 Webhook 经常拒绝 API 请求，什么原因拒绝等等

指标信息示例

# HELP apiserver_admission_webhook_rejection_count [ALPHA] Admission webhook rejection count, identified by name and broken out for each admission type (validating or admit) and operation. Additional labels specify an error type (calling_webhook_error or apiserver_internal_error if an error occurred; no_error otherwise) and optionally a non-zero rejection code if the webhook rejects the request with an HTTP status code (honored by the apiserver when the code is greater or equal to 400). Codes greater than 600 are truncated to 600, to keep the metrics cardinality bounded.
# TYPE apiserver_admission_webhook_rejection_count counter
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="always-timeout-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="invalid-admission-response-webhook.example.com",operation="CREATE",rejection_code="0",type="validating"} 1
apiserver_admission_webhook_rejection_count{error_type="no_error",name="deny-unwanted-configmap-data.example.com",operation="CREATE",rejection_code="400",type="validating"} 13

自定义准入 Webhook 最佳实践与警告

1. 幂等性：变更性质的准入 webhook 多次执行都会与初次执行产生相同的结果。
2. 拦截对象的所有版本：.webhook[].matchPolicy = Equivalent匹配请求：matchPolicy
3. 可用性
4. 确保看到对象的最终状态
5. 避免自定义的 Webhook 出现死锁
6. 应尽可能避免副作用
7. 避免对 kube-system 命名空间进行操作

证书签名

etcd 不会保存签名请求，相应的会有以下几种状态：

1. 已签发的请求：会在 1 个小时后自动被垃圾回收器删除
2. 拒绝的请求：会在 1 个小时后自动被垃圾回收器删除
3. 失败的请求：会在 1 个小时后自动被垃圾回收器删除
4. 所有的请求：已签发证书会在失效以后自动被垃圾回收器删除

Signer

任何要在特定集群以外提供的签名者都应该提供关于签名者工作方式的信息。

1. 信任分发：信任锚点（CA 证书或证书包）
2. 许可的主体
3. 许可的 x509 扩展：包括 IP subjectAltNames，DNS subjectAltNames, Email subjectAltNames, URL subjectAltNames 等
4. 许可的/扩展的密钥用途
5. 过期时间/证书有效期：可以由签名者确定、管理员配置，或者 CSR 请求中spec.expirationSeconds字段指定
6. 允许/不允许 CA 位：若 CSR 包含一个签名者并不允许的 CA 证书时，相应的应对手段

内置的 Signer

1. kubernetes.io/kube-apiserver-client 签名的证书将被 kube-apiserver 视为客户端证书，不会被 kube-controller-manager 自动批准
2. kubernetes.io/kube-apiserver-client-kubelet 签名的证书将被 kube-apiserver 视为 kubelet 的客户端证书，可以被 kube-controller-manager 自动批准
3. kubernetes.io/kubelet-serving 签名的证书将被视为有效的 kubelet 服务端证书，不会被 kube-controller-manager 自动批准
4. kubernetes.io/legacy-unknown 不保证信任，kubernetes 的第三方组件发行版可能会使用它签署的客户端证书，稳定版的 CSR API（certificates.k8s.io/v1以及之后的版本）不允许将signerName设置为kubernetes.io/legacy-unknown，不会被 kube-controller-manager 自动批准

kube-controlelr-manager 为每个内置签名者实现了 control-plane 签名，所有这些故障仅在 kube-controller-manager 日志中报告。

除了上述信任的签名者前发的证书之外，kubernetes 集群不保证其他任何信任关系的建立。虽然某些发行版使用kubernetes.io/legacy-unknown作为客户端证书供 kube-apiserver 使用，但者并不是一个标准的做法（即某些发行版可能会有特定的配置，这跟 kubernetes 官方无关）。这些用法与 ServiceAccount 令牌密钥的.data[ca.crt]没有任何关。使用 CA bundles 的做法只能确保验证到 kube-apiserver 的连接，而且仅限于使用默认服务kubernetes.default.svc（即这些证书斤用于验证与默认服务 kube-apiserver 的连接，而不适用于其他服务或场景）。

自定义签名者

也可以使用自定义签名集成外部的第三方组件，如issuer.open-fictional.example/service-mesh。

签名

Control Plane 签名者

Control plane 实现了内置的所有签名者，作为 kube-controller-manager 的一部分。

NOTES: v1.18 之前，kube-controller-manager 签名所有标记为 approved 的 CSR。 spec.expirationSeconds是在 v1.22 中加入的，v1.22 的版本会忽略该字段。

API-based 签名者

签名完成之后，会将已签发的一个或多个 base64 编码的 pem 证书包含在 CRS 的status.certificate字段中，所有的 pem 块必须要有"CERTIFICATE"标签，编码数据必须符合RFC5280 第 4 节

ClusterTrustBundles

可是使用 2 种模式：signer-linked，signer-unlinked

如何签发证书

创建私钥

# 生成证书私钥
openssl genrsa -out myuser.key 2048
# 用私钥生成一个证书请求文件
openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

创建 CSR

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: <cat myuser.csr | base64 | tr -d "\n">
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # 一天，单位是秒
  usages:
  - client auth # 必须是如此
EOF

批准 CSR

# kubectl get csr
kubectl certificate approve myuser

获取证书

# kubectl get csr/myuser -o yaml
kubectl get csr myuser -o jsonpath='{.status.certificate}' | base64 -d > myuser.crt

创建角色和绑定角色

kubectl create role developer --verb=create --verb=get --resource=pods
kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser

添加到 kubeconfig

kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
kubectl config set-context myuser --cluster=kubernetes --user=myuser

至此用户可以使用该 kubeconfig 完成对集群的访问了

以下这些方式需要适当的被限制。

静态 Pod

每个节点上的 kubelet 会加载并直接管理集群中存储在指定目录中或从指定 URL 获取的静态 Pod 清单。kube-apiserver 不管理这些静态 Pod。对该位置具有写入权限的攻击者可以修改从该位置加载的静态 Pod 的配置，或引入新的静态 Pod。

静态 Pod 被限制访问 kube-apiserver 中的其他对象。如不能将静态 Pod 配置为从集群挂载 Secret。但是这些 Pod 可以执行其他安全敏感的操作，如使用hostPath直接挂载宿主机节点的文件目录.

默认情况下，kubelet 会创建一个 Mirror Pod，以便静态 Pod 在 kube-apiserver 中可见。但是如果攻击者在创建 Pod 时使用了无效的名字空间名称，则该 Pod 将在 kube-apiserver 中不可见，只能通过对受影响主机有访问权限的工具发现。

如果静态 Pod 无法通过准入控制，kubelet 不会将 Pod 注册到 kube-apiserver 中，但该 Pod 仍然在节点上运行。

Mitigations

1. 仅在节点需要时启用 kubelet 静态 Pod manifest 功能
2. 如果一个节点使用静态 Pod 功能，限制它的文件系统访问权限，即仅配置需要访问的目录或 URL
3. 限制对 kubelet 配置参数和文件的访问，以防止攻击者通过设置静态 Pod 访问的文件系统路径或 URL
4. 定期审计并集中报告所有对托管静态 Pod manifest 文件和 kubelet 配置文件的目录或 Web 存储位置的访问

kubelet API

kubelet 提供了一个 HTTP API，一般是 TCP:10250，在某些 kubernetes 发行版中，API 也可能暴露在 control-plane-panel 节点上。对 API 的直接访问允许公开有关运行在节点上的 Pod、这些 Pod 的日志以及在节点上运行每个容器中执行命令的信息。

具有对 Node 对象及子资源 RBAC 访问权限的集群用户，也可以访问 kubelet API，实际的访问权限取决于授予了哪些子资源的访问。[kubelet 鉴权]

对 kubelet API 的直接访问不受准入控制影响，也不会被审计日志记录。能直接访问此 API 的攻击者可能会绕过能检测或防止某些操作的控制机制。

kubelet API 可以配置为多种方式的验证，默认情况下，kubelet 的配置允许匿名访问。大多数 kubernetes 提供商将默认值更改为使用 webhook 和证书身份认证。这使得 control-plane-panel 能够确保调用者访问节点的 API 资源或子资源时经过授权的。但 control-plane-panel 不能确保默认的匿名访问也是如此。

Mitigations

1. 使用 RBAC 等机制限制对节点 API 对象的资源及子资源的访问。只有在需要时才授予此访问权限，如监控服务。
2. 限制对 kubelet 端口的访问，只允许指定和受信任的 IP 地址段访问该端口
3. 确保将[kubelet 身份认证]设置为 webhook 或证书模式
4. 确保集群上未启用不作身份认证的"只读"kubelet 端口

etcd API

etcd 监听的 TCP:2379，只有 kube-apiserver 和所使用的备份工具需要，对该 API 的直接访问允许公开或修改集群中保存的数据。

对 etcd API 的访问通常通过客户端证书身份认证来管理。由 etcd 信任的证书颁发机构颁发的任何证书都可以完全访问 etcd 中存储的数据。

对 etcd 的直接访问不受 kubernetes 准入控制的影响，也不会被 kubernetes 审计日志记录。具有对 API 服务器的 etcd 客户端证书私有的读取访问权限（或可以创建一个新的受信任的客户端证书）的攻击者可以通过访问集群 Secret 或修改访问规则来获得集群管理员权限。即使不提升 kubernetes RBAC 权限，可以修改 etcd 的攻击者也可以在集群内检索所有 API 对象或创建新的工作负载。

许多 kubernetes 提供商配置 etcd 为使用双向 TLS（客户端和服务器端需要互相验证对方的证书）。但这个特性目前 etcd API 鉴权还没有实现。任何具有 etcd 的客户端访问权限的证书都可以用于获得对 etcd 的完全访问权限。如用于健康检查的 etcd 客户端证书也可以授予完全读写访问权限。

Mitigations

1. 确保 etcd 所信任的证书颁发机构颁发的证书仅用于该服务的身份认证
2. 控制对 etcd 服务器证书的私钥以及 kube-apiserver 的客户端证书和密钥的访问
3. 限制对 etcd 的访问，仅限于受信任的 IP 地址段

容器运行时 socket

kubernetes 集群的每个节点上，与容器交互的访问都由容器运行时通过一个 unix socket 控制。具有此 socket 访问权限的攻击者可以启动新容器与正在运行的容器进行交互。

在集群层面，这种访问造成的影响取决于在受威胁节点上运行的容器是否可以访问 Secret 或其他机密信息，攻击者可以使用这些机密数据将权限提升到其他工作节点或 control-plane-panel 组件（如 kube-proxy，kube-scheduler 等）。

Mitigations

1. 确保严格控制对容器运行时 socket 所在文件系统的访问，尽可能仅限制为 root 用户
2. 使用 linux 内核的命名空间等机制将 kubelet 与节点上运行的其他组件隔离
3. 确保限制或禁止使用包含容器运行时 socket 的hostPath挂载，同时hostPath挂载必须设置为只读，以降低攻击者绕过文件系统目录限制的风险
4. 限制用户对节点的访问，特别是限制超级用户对节点的访问

X.509 客户端证书身份认证 (不推荐)

1. 客户端证书不能被单独撤销，直到证书过期
2. 如果证书需要被设置为无效，需要重新生成证书颁发机构的密钥，会导致集群不可用
3. 集群中没有客户端证书的永久记录，因此无法跟踪监控使用证书的用户
4. 用户客户端证书认证的私钥无法收到密码保护，任何能够读取包含密钥文件的人都可以使用
5. 使用客户端证书身份认证需要直接连接 kube-apiserver，没有中间跳板节点的话，可能会使网络结构变得复杂化，如网络拓扑可能需要重新规划，安全性也需要重新考虑，维护和管理负担，扩展性会变差
6. 客户端证书的 O（Organization）中嵌入了组数据，用户的组成员资格在证书的生命周期内无法更改，意味着一旦用户获得了 X.509 客户端证书，这个用户的组成员资格将在证书有效期内保持不变，换句话说，用户被分配到的组信息是固定的，无法通过更改证书来改变用户的组成员资格，这样做缺乏灵活性，权限管理复杂性会提升，安全性隐患，难以追踪和审计

静态 Token 文件 (不推荐)

1. 凭据信息被以明文形式保存在磁盘上，增加了安全性风险
2. 改变任何凭据都需要重启 kube-apiserver，引发可用性风险
3. 没有可用的机制能让用户轮换他们的凭据，如果要轮换凭据，集群管理员需要更改在磁盘上的 Token，然后在下发给用户
4. 没有锁定机制去阻止暴力攻击

引导 tokens (不推荐)

1. 它们固定了不适合一般使用的硬编码组成员资格，因此不适用于用户认证目的
2. 手动生成引导令牌可能导致弱令牌，攻击者可以猜测到，会带来安全风险
3. 没有锁定机制来防止暴力攻击，这使得攻击者容器猜测或破解令牌

ServiceAccount secret tokens (不推荐)

在 kubernetes < 1.23 版本中，是默认选项，供集群中的工作负载进行身份认证。但是这种方式正在被TokenRequest API令牌替换，官方也不建议在生产环境中使用

1. 不能设置过期时间，而是会在相关的服务账户被删除之前一直保持有效
2. 身份验证令牌对于在定义它们的命名空间中读取密钥的任何集群用户都是可见的
3. 服务账户无法被添加到任意组中，导致在使用时复杂化了 RBAC 管理

TokenRequest API tokens (不推荐)

可生成短期凭据，用于服务对 kube-apiserver 或第三方系统进行身份认证的有用工具，官方也不建议用于生产环境，因为没有可用的吊销方法，并且以安全的方式将凭据分发给用户可能也有挑战。

当使用 TokenRequest 令牌进行身份认证时，建议实现短期生命周期，以减少受到损害的令牌带来的影响。

OIDC 令牌身份认证 (推荐)

官方支持使用 OpenID Connect 令牌身份认证，将外部身份验证服务与 kube-apiserver 集成。使用 OIDC 时，需要考虑以下加固措施：

1. 安装在集群中以支持 OIDC 身份认证的软件应该与一般工作负载隔离，因为它将以高权限运行
2. 一些 kubernetes 托管服务对可以使用的 OIDC 提供者有限制
3. 与 TokenRequest 令牌一样，OIDC 令牌的生命周期应该较短，以减少受到损害的令牌产生的影响

Webhook token 身份认证 (中立)

是将外部身份认证服务提供者集成到 kubernetes 中的另一种选项。该服务可以集成在集群内部或外部运行，用于进行身份认证。该机制的使用性取决于用于身份认证服务的软件，并且有一些 kubernetes 特定的考虑因素。

要配置 webhook 身份验证，需要访问控制平面服务器的文件系统。这意味着除非供应商专门提供此功能，否则在托管 kubernetes 的供应商那里将无法使用。此外，为了支持这种访问，集群中安装的任何软件都应与一般的工作负载隔离。

认证代理服务 (推荐)

使用认证代理将外部身份认证系统集成到 kubernetes 集群中的另一种选项。通过这种机制，kubernetes 期望从代理接受请求，并在请求中设置特定的头部值，只是用于授权目的的用户名和组成员资格。这种机制也需要考虑一些特定的考虑因素。

1. 必须在代理和 kube-apiserver 之间使用 TLS 连接，以减轻流量拦截或嗅探攻击的风险，这确保了代理和 kube-apiserver 之间的通信时安全的
2. 需要注意能够修改请求头的攻击者可能会未经授权地访问 kubernetes 资源，因此重要的是确保请求头被正确的保护，并且不能被篡改。

其他的认证授权

Webhook 并不是一种特定的身份认证机制，而是一种用于集成外部身份认证提供者到 kubernetes 集群中的机制。通过 webhook，kubernetes 可以与外部的身份认证服务通信，以获取身份认证决策。这个外部的身份验证服务可以是在集群内部或外部运行的任何类型的服务，例如 OAuth 2.0 提供者，LDAP 等。

OAuth2.0 是一种授权框架，不是一种身份认证协议，主要用于用户授权。虽然 OAuth2.0 可以用于身份认证，但它通常与 OIDC 结合使用，以提供完整的身份认证和授权解决方案。OAuth2.0 与 Webhook 结合使用，以便将 OAuth2.0 或 OIDC 身份认证服务集成到 kubernetes 集群中。

LDAP（轻量级目录访问协议）是一种用于访问和维护分布式目录信息服务的开放标准协议。它通常用在网络中分布式存储组织的信息，例如用户信息、组织结构和网络资源等。

身份认证策略

kubernetes 通过身份认证插件利用客户端证书、持有者令牌或身份代理来认证 API 请求的身份。HTTP 请求发给 kube-apiserver 时，插件会将以下属性关联到请求本身：

1. 用户名
2. 用户 ID
3. 用户组：一组字符串，用来标明用户是哪些命名的用户组集合的成员，如系统组 system:masters（这个组的使用有一定的风险），这里只是为了说明
4. 附加字段：一组额外的 KV 映射，用来保存一些认证组件可能觉得有用的额外价值

所有属性值对于身份认证系统都是非透明的，只有被认证组件解释过之后才有意义，才会被 kubernetes 集群所识别。可以同时启用多种身份认证方法，并且通常至少会有 2 种：

1. 针对服务账号使用的令牌
2. 针对普通人类用户的身份认证

认证组件的执行顺序是不确定的，对于完成身份认证的用户，system:authenticated 组都会被添加到用户的组属性中。

X.509 客户端证书

通过 TLS 的非对称加密完成的双向身份认证，使用--client-ca-file=<client-ca-file>，参考证书管理

静态令牌

这种方式就跟我们不同服务之间内部交互，直接使用一个随机字符串去互相认证类似。目前令牌会长期有效，且 kube-apiserver 不重启的情况下无法更新令牌，使用--token-auth-file=<token-file>。当使用 HTTP 客户端执行身份认证时，http 请求需要携带一个Authorization: Bearer <token string>的头信息。

启动引导令牌

像执行 kubeadm join 中使用的 token 就是这个，这个主要用于平滑启动引导集群，这些令牌以 Secret 的形式保存在 kube-system 命名空间中，可以被动态管理和创建。TokenCleaner控制器能够在启动引导令牌过期时将其删除。

它也被设计成可通过 RBAC 策略，结合 kubelet TLS 启动引导系统进行工作。这个令牌被定义成一个特定的 Secret 类型bootstrap.kubernetes.io/token，并存在于 kube-system 命名空间中。这些 secret 会被 kube-apiserver 启动引导认证组件（Bootstrap Authenticator）读取，TokenCleaner能够删除过期的启动引导令牌，也被用来在节点发现的过程中使用的一个特殊的 ConfigMap 对象，BootstrapSigner控制器也会使用这个 ConfigMap。参考Bootstrap Tokens

服务账号令牌

可以被用在集群内部或者集群外部，token 数据可以被保存在 Secret 中，也可以不保存，如果挂载到 Pod 中的容器内可使用 volume 或者环境变量等方式（这种就需要用到 Secret 了），是一种自动启动的用户认证机制。该组件有 2 个参数可以设置：

1. --service-account-key-file=<X509 rsa 或 ecdsa私钥或公钥>，可以指定多个文件，若未指定默认使用--tls-private-key-file参数
2. --service-account-lookup如果启用，则从 kube-apiserver 删除的令牌会被回收

服务账号被认证通过后，所确定的用户名为system:serviceaccount:<namespace>:<服务账号名>，并被分配到用户组system:serviceaccounts和system:serviceaccounts:<namespace>

OIDC 令牌

这是一种比较广泛接受的用于各种不同服务之间共享账号信息的认证的方式，也被 kubernetes 官方推荐为一种作为集群外部使用的方式。一般要配合 OAuth2 的授权，完成用户身份认证。OpenID Connect。第三方组件有：

1. dex
2. keycloak
3. UAA
4. OpenUnion

也可以使用官方已经集成的 OIDC，可以直接使用 kubectl，对于用于而言，可以自己将 kubectl 配置的 OIDC 各项参数封装成一个 shell 脚本

webhook 令牌

这是一种回调机制，可以在启动 kube-apiserver 时添加参数，有--authentication-token-webhook-config-file,--authentication-token-webhook-cache-ttl,--authentication-token-webhook-version，也可以配置在 kubeconfig 中

身份认证代理

这是一种代理的方式，主要用户 HTTP 请求，需要设置一些请求头信息，--requestheader-username-headers,--requestheader-group-headers,--requestheader-extra-headers-prefix等，要使用这种方式，需要使用 TLS 加密，配置合适的 ca 证书，但是不应该在不同的上下文中复用 ca 证书。

匿名请求

如果用户没有经过身份认证，或者类似集群中的 kubelet 绕过了准入控制，这类请求会被标记为system:anonymous和对应的用户组system:unauthenticated

用户伪装

是一个可以用来伪装成集群中其他用户的手段，以完成一些该用户具有权限的操作。以下 HTTP 请求头用来执行伪装请求：

1. Impersonate-User 要伪装的用户名
2. Impersonate-Group 要伪装的用户组
3. Impersonate-Extra-<附加名称>
4. Impersonate-UID

有对应伪装权限的用户也可以使用 kubectl 加参数--as，--as-group来伪装目标用户执行该用户具有权限的操作。

client-go credentials 插件

这一特性的目的是便于客户端与 k8s.io/client-go 并不原生支持的身份认证协议（LDAP、Kerberos、OAuth2、SAML 等）集成。该插件实现特定于协议的逻辑，之后返回非透明的凭据供 webhook 组件进行身份认证，然后解析用户数据给集群。

为客户端提供的对身份验证信息的 API 访问

如果启用了此 API，可以使用SelfSubjectReviewAPI 对象来了解 kubernetes 集群如何映射用户身份验证信息从而识别为某客户端。可用于身份认证调试等目的。默认情况下，所有经过身份验证的用户都可以在 APISelfSubjectReview 特性被启用时创建 SelfSubjectReview 对象，这是由 system:basic-user 集群角色允许的操作。

基于 RBAC 的良好实践

1. 最小特权
   • 尽可能在命名空间级别分配权限，尽可能使用RoleBinding，而不是ClusterRoleBinding
   • 尽可能避免通过通配符设置权限
   • 尽可能不使用cluster-admin账号
   • 避免添加用户到system:masters组
2. 最大限度减少特权令牌的分发
   • 限制具有特权令牌 Pod 的节点数量
   • 避免将拥有特权令牌的 Pod 与其他不可信或公开的 Pod 在一个节点运行，可通过使用 Taint，Toleration，PodAffinity，PodAntiAffinity 来实现
3. 加固
   • 审查 system:unauthenticated 组的绑定，如果可能，将其删掉
   • 设置 automountServiceAccountToken: false 来避免服务账号令牌的默认自动挂载
4. 定期检查 RBAC 的配置是否有冗余条目和提权可能性是至关重要的。如果攻击者能够创建与已删除用户同名的服务账户，它们可以自动继承被铲除用户的所有权限，尤其是分配给该用户的权限
5. 警惕 RBAC 权限提升的风险，如 RoleBinding 转换为 ClusterRoleBinding 等行为
6. 限制 Secret 的访问与使用
7. 通过 Pod 安全性准入来尽可能规避工作负载类的控制器的创建产生的风险
8. 持久卷的创建，慎用 hostPath 卷，受信任的人可以用 PV，受约束的人应使用 PVC
   • 只允许需要此权限才能工作的用户以及信任的人员
   • kubernetes 控制平面组件，这些组件基于已配置为自动制备的 PVC 创建的 PV，通常由 kubernetes 提供商或某些 CSI 插件运行需要
9. 小心具有访问 Node 的 Proxy 子资源权限的 Pod 或用户
10. 尽量避免使用 esclate，拥有此权限的用户可提升自身的权限
11. 尽量避免使用 bind，拥有此权限的用户可以创建并绑定不具有权限的角色
12. 尽量避免使用 impersonate，此操作允许用户伪装并获得其他用户的权限
13. 小心使用 CSR 和证书颁发，CSR API 允许用户有 create CSR 和 update certificatesigningrequests/approval 的权限，有可能会特权提升
14. 令牌请求：拥有 serviceaccount/token 的 create 权限的用户可以创建 TokenRequest 来发布现有服务账户的令牌
15. 控制准入 Webhook：可以控制 validatingwebhookconfigurations 或 mutatingwebhookconfigurations 的用户可以控制能读取任何允许进入集群的对象的 webhook，并且在有变更 webhook 的情况下，还可以变更准入的对象。
16. 为所有 Pod 配置资源配额，以限制可以创建的 Pod 数量，来避免 RBAC 拒绝服务攻击的风险

1. Privileged 不受限制的策略，此类 Pod 权限较高，通常为一些系统级别或基础设施级别的工作负载

2. Baseline 限制性最弱的策略，禁止已知的特权提升

   1. HostProcess, windows related (v1.26 stable)

      • Restricted Fields
        1. spec.securityContext.windowsOptions.hostProcess
        2. spec.containers[*].securityContext.windowsOptions.hostProcess
        3. spec.initContainers[*].securityContext.windowsOptions.hostProcess
        4. spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
      • Allowed Values
        1. undefined/nil
        2. false

   2. Host Namespaces: Sharing the host namespaces must be disallowed.

      • Restricted Fields
        1. spec.hostNetwork
        2. spec.hostPID
        3. spec.hostIPC
      • Allowed Values
        1. undefined/nil
        2. false

   3. Privileged Containers: Privileged Pods disable most security mechanisms and must be disallowed.

      • Restricted Fields
        1. spec.containers[*].securityContext.privileged
        2. spec.initContainers[*].securityContext.privileged
        3. spec.ephemeralContainers[*].securityContext.privileged
      • Allowed Values
        1. undefined/nil
        2. false

   4. Capabilities: Adding additional capabilities beyond those listed below must be disallowed.

      • Restricted Fields
        1. spec.containers[*].securityContext.capabilities.add
        2. spec.initContainers[*].securityContext.capabilities.add
        3. spec.ephemeralContainers[*].securityContext.capabilities.add
      • Allowed Values
        • undefined/nil
        • AUDIT_WRITE 允许写入审计日志
        • CHOWN 允许容器更改文件所有者
        • DAC_OVERRIDE 允许容器忽略文件的 DAC 权限（Discretionary Access Controls）即，读、写、执行、特殊权限
        • FOWNER 允许容器更改文件所有者为任何用户
        • FSETID 允许容器设置文件的 Setuid 位或 Setgid 位
        • KILL 允许容器相其他进程发送信号
        • MKNOD 允许容器创建特殊文件节点
        • NET_BIND_SERVICE 允许容器绑定到低于 1024 的端口号
        • SETFCAP 允许容器设置文件的能力，如某个文件需要一些特权操作，但又不想以 root 用户身份执行
        • SETGID 允许容器设置有效的组 ID（宿主机）
        • SETPCAP 允许容器进程修改其进程的能力，如 Docker，Sandbox
        • SETUID 允许容器设置有效的用户 ID（宿主机）
        • SYS_CHROOT 允许容器使用 chroot 系统调用，即通过系统调用限制用户只能使用某个文件目录的能力

   5. HostPath Volumes: HostPath volumes must be forbidden.

      • Restricted Fields
        1. spec.volumes[*].hostPath
      • Allowed Values
        1. undefined/nil

   6. Hosts Ports: HostPorts should be disallowed entirely (recommended) or restricted to a known list

      • Restricted Fields
        1. spec.containers[*].ports[*].hostPort
        2. spec.initContainers[*].ports[*].hostPort
        3. spec.ephemeralContainers[*].ports[*].hostPort
      • Allowed Values
        1. undefined/nil
        2. [enforce,audit,warn]
        3. 0

   7. AppArmor: On supported hosts, the runtime/default AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.

      • Restricted Fields
        1. metadata.annotations[“container.apparmor.security.beta.kubernetes.io/*”]
      • Allowed Values
        1. undefined/nil
        2. runtime/default
        3. localhost/*

   8. SELinux: Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.

      • Restricted Fields
        1. spec.securityContext.seLinuxOptions.type
        2. spec.containers[*].securityContext.seLinuxOptions.type
        3. spec.initContainers[*].securityContext.seLinuxOptions.type
        4. spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
      • Allowed Values
        1. undefined/""
        2. container_t 容器的默认 SELinux 类型，允许主容器中的进程访问主容器中的资源，并收到 SELinux 策略的保护
        3. container_init_t 允许初始化容器中的进程访问初始化容器中的资源，并收到 SELinux 策略的保护
        4. container_kvm_t 允许容器内运行的虚拟机（如 KVM）的 SELinux 类型，并受到 SELinux 策略的保护
      • Restricted Fields
        1. spec.securityContext.seLinuxOptions.[user/role]
        2. spec.containers[*].securityContext.seLinuxOptions.[user/role]
        3. spec.initContainers[*].securityContext.seLinuxOptions.[user/role]
        4. spec.ephemeralContainers[*].securityContext.seLinuxOptions.[user/role]
      • Allowed Values
        1. undefined/""

   9. /proc Mount Type: The default /proc masks are set up to reduce attack surface, and should be required.

      • Restricted Fields
        1. spec.containers[*].securityContext.procMount
        2. spec.initContainers[*].securityContext.procMount
        3. spec.ephemeralContainers[*].securityContext.procMount
      • Allowed Values
        1. undefined/nil
        2. Default

   10. Seccomp: Seccomp profile must not be explicitly set to Unconfined

       • Restricted Fields
         1. spec.securityContext.seccompProfile.type
         2. spec.containers[*].securityContext.seccompProfile.type
         3. spec.initContainers[*].securityContext.seccompProfile.type
         4. spec.ephemeralContainers[*].securityContext.seccompProfile.type
       • Allowed Values
         1. undefined/nil
         2. RuntimeDefault
         3. Localhost

   11. Sysctls: Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed “safe” subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.

       • Restricted Fields
         1. spec.securityContext.sysctls[*].name
       • Allowed Values
         1. undefined/nil
         2. kernel.shm_rmid_forced 控制是否强制删除共享内存标识符
         3. net.ipv4.ip_local_port_range 控制本地端口范围
         4. net.ipv4.ip_unprivileged_port_start 指定非特权用户可用的本地端口起始范围
         5. net.ipv4.tcp_syncookies 控制是否启用 SYN cookie 机制来防范 SYN 攻击
         6. net.ipv4.ping_group_range 指定 ping 命令可用的 ICMP Echo 请求
         7. net.ipv4.ip_local_reserved_ports 指定保留的本地端口范围
         8. net.ipv4.tcp_keepalive_time 指定 TCP 连接的 FIN 超时时间，以秒为单位
         9. net.ipv4.tcp_fin_timeout 指定 TCP 连接的 FIN 超时时间，以秒为单位
         10. net.ipv4.tcp_keepalive_intvl 指定 TCP 连接的 keepalive 控制消息之间的间隔时间，以秒为单位
         11. net.ipv4.tcp_keepalive_probes 指定 TCP 连接在进行 keepalive 检测之前尝试的次数

3. Restricted 限制性最强的策略

   1. Volume Types: The restricted policy only permits the following volume types.
      • Restricted Fields
        1. spec.volumes[*]
      • Allowed Values: Non-Null value
        1. spec.volumes[*].configMap
        2. spec.volumes[*].csi
        3. spec.volumes[*].downwardAPI
        4. spec.volumes[*].emptyDir
        5. spec.volumes[*].ephemeral
        6. spec.volumes[*].persistentVolumeClaim
        7. spec.volumes[*].protected
        8. spec.volumes[*].secret
   2. Privilege Escalation: Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. linux only policy (spec.os.name != windows)
      • Restricted Fields
        1. spec.containers[*].securityContext.allowPrivilegeEscalation
        2. spec.initContainers[*].securityContext.allowPrivilegeEscalation
        3. spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
      • Allowed Values
        1. false
   3. Running as Non-root
      • Restricted Fields: Containers must be required to run as non-root users.
        1. spec.securityContext.runAsNonRoot
        2. spec.containers[*].securityContext.runAsNonRoot
        3. spec.initContainers[*].securityContext.runAsNonRoot
        4. spec.ephemeralContainers[*].securityContext.runAsNonRoot
      • Allowed Values
        1. true
      • Restricted Fields: Containers must not set runAsUser to 0
        1. spec.securityContext.runAsUser
        2. spec.containers[*].securityContext.runAsUser
        3. spec.initContainers[*].securityContext.runAsUser
        4. spec.ephemeralContainers[*].securityContext.runAsUser
      • Allowed Values
        1. any non-zero value
        2. undefined/null
   4. Seccomp: Seccomp profile must be explicitly set to one of the allowed values. Both the Unconfined profile and the absence of a profile are prohibited. linux only (spec.os.name != windows)
      • Restricted Fields
        1. spec.securityContext.seccompProfile.type
        2. spec.containers[*].securityContext.seccompProfile.type
        3. spec.initContainers[*].securityContext.seccompProfile.type
        4. spec.ephemeralContainers[*].securityContext.seccompProfile.type
      • Allowed Values
        1. RuntimeDefault
        2. Localhost
   5. Capabilities: Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability. linux only (spec.os.name != windows)
      • Restricted Fields
        1. spec.containers[*].securityContext.capabilities.drop
        2. spec.initContainers[*].securityContext.capabilities.drop
        3. spec.ephemeralContainers[*].securityContext.capabilities.drop
      • Allowed Values
        1. Any list of capabilities that includes ALL
      • Restricted Fields
        1. spec.containers[*].securityContext.capabilities.add
        2. spec.initContainers[*].securityContext.capabilities.add
        3. spec.ephemeralContainers[*].securityContext.capabilities.add
      • Allowed Values
        1. undefined/nil
        2. NET_BIND_SERVICE

为名字空间设置 Pod 安全性准入控制标签

1. enforce: 策略违例会导致 Pod 被拒绝，应用到 Pod 对象上
2. audit：策略违例会触发在审计日志中记录新事件时添加注解；但是 Pod 仍然是被接受的，应用到 Deployment，ReplicaSet 等控制器对象上
3. warn：策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的，应用到 Deployment，ReplicaSet 等控制器对象上

对应的标签

1. pod-security.kubernetes.io/<MODE>: <LEVEL> MODE: enforce,audit,warn LEVEL: privileged,baseline,restricted
2. pod-security.kubernetes.io/<MODE>-version: <VERSION> MODE: enforce,audit,warn VERSION: 合法的 kubernetes 小版本号或者latest

apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.29

    # 我们将这些标签设置为我们所 _期望_ 的 `enforce` 级别
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.29
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.29

准入豁免

1. Username：来自用户名一杯豁免的，已认证的（或伪装的）用户请求会被忽略
2. RuntimeClassName：指定了已豁免的 CRI 类名称的 Pod 和负载资源（Deployment，ReplicaSet 等）会被忽略
3. Namespace：位于北豁免的名字空间中的 Pod 和负载资源会被忽略

NOTE: 为用户提供豁免时，只会当该用户直接创建的 Pod 时对其实施安全策略的豁免。用户所创建的工作负载资源（控制器）不会被豁免。控制器服务账号（如：system:serviceaccount:kube-system:replicaset-controller）通常不应该被豁免，因为这类服务账号隐含着对所有能够创建对应工作负载资源的用户豁免。

策略检查时会对以下 Pod 字段的更新操作予以豁免，这意味着如果 Pod 更新请求进改变这些字段时，即使 Pod 违反了当前的策略级别，请求也不会被拒绝。

• 除了对 seccomp 或 AppArmor 注解之外的所有 Metadata 更新操作：
  • container.apparmor.security.beta.kubernetes.io/*
• 对 .spec.activeDeadlineSeconds的合法更新
• 对 .spec.tolerations的合法更新

Pod 安全级别的指标监控

• pod_security_evaluations_total: 表示易发生的策略评估的数量，不包括到处期间被忽略或豁免的请求
• pod_security_exemptions_total: 表示豁免请求的数量，不包括被忽略或超出范围的请求

set -g default-terminal "screen-256color"

set -g prefix C-z
unbind C-b
bind-key C-z send-prefix

unbind %
bind _ split-window -h

unbind '"'
bind - split-window -v

unbind r
bind r source-file ~/.tmux.conf \; display '~/.tmux.conf sourced'

bind -r Tab last-window         # move to last active window
bind-key -n M-h previous-window # select previous window
bind-key -n M-l next-window     # select next window

bind -r j resize-pane -D 5
bind -r k resize-pane -U 5
bind -r l resize-pane -R 5
bind -r h resize-pane -L 5

bind -r m resize-pane -Z

set -g mouse on

set-window-option -g mode-keys vi

bind-key -T copy-mode-vi 'v' send -X begin-selection # start selecting text with "v"
bind-key -T copy-mode-vi 'y' send -X copy-selection # copy text with "y"

unbind -T copy-mode-vi MouseDragEnd1Pane # don't exit copy mode when dragging with mouse

# remove delay for exiting insert mode with ESC in Neovim
set -sg escape-time 10

# tpm plugin
set -g @plugin 'tmux-plugins/tpm'

# list of tmux plugins
set -g @plugin 'christoomey/vim-tmux-navigator'
set -g @plugin 'tmux-plugins/tmux-resurrect' # persist tmux sessions after computer restart
set -g @plugin 'tmux-plugins/tmux-continuum' # automatically saves sessions for you every 15 minutes

set -g @plugin 'catppuccin/tmux'
set -g @plugin 'tmux-plugins/tmux-cpu'
set -g @plugin 'xamut/tmux-weather'
# set -g @plugin 'vascomfnunes/tmux-clima'
# set -g @plugin 'jamesoff/tmux-loadavg'

# ========= catppuccin/tmux configuration start =============
set -g @catppuccin_window_left_separator ""
set -g @catppuccin_window_right_separator " "
set -g @catppuccin_window_middle_separator " █"
set -g @catppuccin_window_number_position "right"

set -g @catppuccin_window_default_fill "number"
set -g @catppuccin_window_default_text "#W"

set -g @catppuccin_window_current_fill "number"
set -g @catppuccin_window_current_text "#W"

set -g @catppuccin_status_modules_left ""
set -g @catppuccin_status_modules_right "directory application weather date_time cpu session"
set -g @catppuccin_status_left_separator  " "
set -g @catppuccin_status_right_separator ""
set -g @catppuccin_status_fill "icon"
set -g @catppuccin_status_connect_separator "no"

set -g @catppuccin_directory_text "#{b:pane_current_path}"
# ========= catppuccin/tmux configuration end =============

set -g @resurrect-capture-pane-contents 'on'
set -g @continuum-restore 'on'

# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run '~/.tmux/plugins/tpm/tpm'

APF 可提升 apiserver 过载情况下的并发限制。以更细粒度的方式对请求进行分类（优先级配置）和隔离（每个优先级分配自定义并发限制），引入空间有限的排队机制（公平排队分发请求），可在非常短暂的突发情况下，保证 apiserver 不会拒绝任何请求。这种情况能够保证所有请求都可以得到 apiserver 的响应。

APF 在设计上期望能与标准控制器（如 Deployment 等？？？）一起协同工作，这类控制器在处理失效时能够执行指数型回退（指回退时间）。

APF 稳定版 v1 默认被启用，可通过--enable-priority-and-fairness开启或禁用 APF。

请求通过 FlowSchema 按照其属性分类，并分配优先级。每个优先级分配自定义并发限制（隔离）。公平排队算法可以防止来自不同 Flow 的请求相互饿死，该算法将请求排队，防止因低平均负载因通信量突增而导致请求失败。

基本概念

优先级

如果未启用 APF，apiserver 中的整体并发量将收到 kube-apiserver 的参数--max-requests-inflight和--max-mutating-requests-inflight的限制。启用 APF 后，将对这些参数定义的并发限制进行求和，然后将总和分配到一组可配置的优先级中。因为每个请求都会分配一个优先级，且每个优先级都有各自的并发限制，以此来达到即使异常的 Pod 向 apiserver 发送大量请求，也无法阻止诸如领导者选举或内置控制器的操作成功等高优先级的 http 请求。优先级的并发限制会被定期调整，允许利用率低的优先级将并发 seat 临时借给利用率高的优先级。

请求占用的 seat

有些请求占用一个 seat，有些请求占用多个 seat（可能附带其他请求）。对于后者 apiserver 将认为请求所返回的对象数量与所占用的 seat 成正比。即：如果一个请求返回一个 List 那么有可能这个请求会占用这个 List 长度的 seat。

watch 请求

APF 管理 watch 请求，要考虑除一个请求占用一个 seat 的情况。每当向 apiserver 发送通知创建/更新/删除一个对象时，正常都会以并发的方式发送所有相关的 watch 响应流，apiserver 估算要发送的通知数量，并调整写入请求占用的 seat 数以及额外工作继续占用的 seat 的时间。

排队

第一步：每个请求都被分配到某个 Flow（由对应的 FlowSchema 与 FlowDistinguisher）。FlowDistinguisher 可以是发出请求的用户、目标资源的名字空间或者为空等。apiserver 尝试为不同流中具有相同优先级的请求赋予近似相等的权重。第二步：apiserver 将请求分配到队列中，使用 shuffle-sharding 的技术，相对有效的利用队列隔离 low-intensity flows 与 high-intensity flows。

排队算法的细节可针对每个优先级进行调整，并允许管理员在内存占用、公平性、突发流量容忍度以及排队引发的额外延迟之间进行权衡。

豁免请求

某些特别重要的请求不受制于此特性施加的任何限制。这些豁免可防止不当的流控配置完全禁用 apiserver。

资源

PriorityLevelConfiguration

该对象定义可用的优先级，并按比例分配 kube-apiserver 定义的--max-request-inflight或--max-mutating-requests-inflight总并发量限制。所以对于管理员来说，可以通过设定这 2 个参数的具体数值，然后集群中定义的所有PriorityLevelConfiguration都会按照比例相应缩减对应的并发限额。

一个优先级可以借出的并发数（seat）界限以及可以借用的并发数（seat）界限在PriorityLevelConfiguration表现该优先级的额定限制。这些界限值 * 额定限制 / 100.0 并取整，被解析为绝对 seat 数量。即一个优先级的动态调整并发限制范围在“器额定限制的下限 - 其可借出的 seat 数”和“其额定限制的上限 + 其可以借用的 seat 数”之间。在每次调整时，通过每个优先级推导得出动态限制，具体过程为回收最近出现需求的所有接触的 seat，然后在刚刚描述的界限内共同公平地响应有关这些优先级最近的 seat 要求。如果用户想要对给定资源分别进行处理，需要自己创建对应的 FlowSchema 对象，分别匹配对应的 mutating 和 non-mutating。

当入站请求数量大于分配的PriorityLevelConfiguration中允许的并发量（seat）时，type=Reject表示多余的请求将立即以 HTTP 429 的错误拒绝，type=Queue表示对允许并发量的请求进行排队处理（应用不同优先级的并发数量和公平排队的技术来平衡请求的处理）。

公平排队算法支持通过排队配置对优先级的微调，增强建议

• queues 数值增大，能降低 flow 冲突概率，但是内存会增大，值为 1，则禁用公平排队逻辑
• queueLengthLimit 数值增大，能提高并发，但是增加了等待时间和内存用量
• handSize 允许调整过载情况下不同 flow 之间的冲突概率以及单个请求可用的整体并发性，较大使 2 个单独的 flow 发生碰撞的可能性变小（也就是一个操作可以饿死另一个，因为它占用了太久的 seat），更有可能的情况是少数 flow 可以调用 apiserver。较大的值还可能增加单个高并发 flow 的延迟时间。单个 flow 中可能排队的请求的最大数量为handSize*queueLengthLimit。

FlowSchema

用于对每个入站请求进行分类，并与一个PriorityLevelConfiguration相匹配。每个入站请求都会对FlowSchema测试是否匹配，首先从matchingPrecedence数值最低的匹配开始，然后依次进行，直到首个匹配出现。

确定请求与某个FlowSchema的rules的其中一条匹配的规则是：

1. 要求该条规则的subjects字段至少存在一个与该请求相匹配
2. 该条规则的resourceRules或nonResourceRules（取决于请求传入的是资源 URL 还是非资源 URL）字段至少存在一个与该请求匹配

对于subjects中的name字段和资源和非资源规则的verbs(如 GET,POST 等)、apiGroups、resources、namespaces和nonResourceURLS字段，可以指定通配符*来匹配任意值。

FlowSchema的distinguisherMethod.type字段决定了如何把与该模式匹配的请求分发到不同的 flow 中，如：

1. ByUser 一个用户将无法饿死其他容量的用户
2. ByNamespace 一个命名空间中的对象资源请求将无法饿死其他命名空间中的对象资源请求
3. 如果省略distinguisherMethod，这种情况将被视为与此FlowSchema相匹配的请求是单个 flow 的一部分。
4. …

默认值

kube-apiserver 会维护 2 种类型的 APF 配置对象：Mandatory 和 Suggested

健康检查豁免示例

apiVersion: flowcontrol.apiserver.k8s.io/v1beta3
kind: FlowSchema
metadata:
  name: health-for-strangers
spec:
  matchingPrecedence: 1000 # 最低匹配数值
  priorityLevelConfiguration:
    name: exempt # 优先级用于完全不受流控限制的请求
  rules:
    - nonResourceRules:
        - nonResourceURLs: # 针对URL
            - "/healthz"
            - "/livez"
            - "/readyz"
          verbs: # 对所有的HTTP（GET,POST,PUT...）的请求
            - "*"
      subjects:
        - kind: Group
          group:
            name: "system:unauthenticated"

稳定性提升

根据提供的指标配置 APF 监控

Pod 与容器日志

1. 所有容器相关的运行日志，都以 stdout 和 stderr 的方式输出，并对日志进行 rotate。默认情况下，如果容器重新启动，kubelet 会保留一个终止容器的日志，如果该容器被驱逐，所对应的日志也会跟随。kubelet 配置文件中，containerLogMaxSize(default 10Mi)，containerLogMaxFiles(default 5)。
2. 系统组件的日志
   1. kubelet：linux 默认写入journald，使用journalctl -u kubelet查看
   2. 其他组件如果是以容器的方式运行，如 kube-proxy 等一些系统 Pod，在/var/log/pods中，日志目录命名方式[namespace][podname][poduid]

集群级日志架构

kubernetes 没有提供原生日志解决方案，但用户可以选择一些方式：

1. 使用 DaemonSet 在每个节点部署日志代理
2. 使用 Sidecar 专门收集容器日志
3. 使用第三方后端记录日志

总之，日志的收集无论哪种方式怎么实现，都会有一定的损耗。

系统日志

Klog 示例

I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]

1. 结构化日志

   <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" <%+v>
   

2. 上下文日志，example
3. JSON 日志格式，--logging-format=json
4. 日志精细度级别，如-v=5,0 为 critical 事件
5. 日志位置，在容器中的日志：/var/log/<pods/containers/servicename>/**/*.log（logrotate）；不在容器中：写入 journald（系统日志工具）
6. 日志查询，需开启NodeLogQuery(feature gate)

系统组件指标

http 访问路径，/metrics/*；

启用隐藏指标：show-hidden-metrics-for-version

kube-scheduler

包含以下 label:

1. namespace
2. podname
3. pod.spec.nodeName
4. pod.spec.priority
5. pod.spec.scheduleName
6. pod.spec.resources.[*].[cpu|memory|volume]

指标顺序指定

--allow-label-value, --allow-metric-labels-manifest

Tracing Kubernetes 系统组件

1. [OpenTelemetry 协议]
2. w3c trace-context

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletTracing: true
tracing:
  # 默认值
  #endpoint: localhost:4317
  samplingRatePerMillion: 100 # 如引发性能问题，可适当调整数值或关闭该项

kubernetes 中的 proxy

1. kubectl proxy
2. apiserver proxy
3. kube proxy
   • 在每个节点上运行
   • 支持 UDP,TCP,SCTP
   • 提供负载均衡能力
   • 只用来访问 Service
4. A Proxy/Load-balancer in front of apiserver(s)
5. Cloud Load Balancers on external services

# Verify the boot mode
cat /sys/firmware/efi/fw_platform_size

fdisk /dev/vda
# Pick GPT partition
# /dev/vda1 512MB EFI system type: uefi
# /dev/vda2 512MB swap       type: swap
# /dev/vda3 63G Linux Filesystem

mkfs.ext4 /dev/vda3
mkswap /dev/vda2
mkfs.fat -F 32 /dev/vda1

mount /dev/vda3 /mnt
mount --mkdir /dev/vda1 /mnt/boot
swapon /dev/vda2

mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
echo "Server = https://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch" > /etc/pacman.d/mirrorlist

pacstrap -K /mnt base base-devel linux linux-firmware e2fsprogs dhcpcd networkmanager vim neovim man-db man-pages texinfo openssh git

genfstab -U /mnt >> /mnt/etc/fstab

arch-chroot /mnt
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
hwclock --systohc
vim /etc/locale.gen
locale-gen
cat > /etc/locale.conf <<EOF
LANG=en_US.UTF-8
EOF

cat > /etc/vconsole.conf <<EOF
KEYMAP=en
EOF
cat >> /etc/hostname <<EOF
archlinux
EOF
cat >> /etc/hosts <<EOF
127.0.0.1 localhost
::1         localhost
127.0.0.1   archlinux
EOF

# Ignore the warning or error, I did not dig into it.
mkinitcpio -P

# Set root passwd
passwd

# Install bootloader
pacman -S grub efibootmgr

mkdir /boot/grub
grub-install --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

exit
umount -R /mnt
reboot now

systemctl enable NetworkManager
systemctl start NetworkManager

systemctl enable sshd
systemctl start sshd

useradd -m -G wheel -s /bin/bash username
passwd username

echo "Server = https://mirrors.tuna.tsinghua.edu.cn/archlinuxarm/$arch/$repo" >> /etc/pacman.d/mirrorlist
pacman -Syyu

Some Useful References

• https://wiki.archlinux.org/title/Installation_guide
• https://github.com/prasanthrangan/hyprdots
• https://github.com/JaKooLit/Fedora-Hyprland
• https://github.com/JackMyers001/archiso-aarch64
• https://github.com/romkatv/powerlevel10k
• https://raspberry-hosting.com/en/faq/how-expand-arch-linux-root-partition

podAffinity是一类属性，使节点拥有吸引某一类 Pod 的能力，Taint 则相反，使节点能够排斥一类特定的 Pod，Toleration 则允许调度器将 Pod 调度到带有 Taint 的节点上。

Taint 与 Toleration 相互配合，可以有效避免将一类 Pod 调度到不适合的节点上。如：可以防止将不需要 GPU 能力的 Pod 调度到可提供 GPU 能力的节点上；集群默认的 master 节点有node-role.kubernetes.io/control-plane:NoSchedule这样的配置，才可以避免将 Pod 调度到 master 节点等等。

一些基本的操作指令：

# 给节点node1增加一个Taint，不允许被调度
kubectl taint nodes node1 key1=value1:NoSchedule

# 删除这个Taint
kubectl taint nodes node1 key1=value1:NoSchedule-

在 Pod 中设置 Toleration，使其可以被调度到对应的节点上：

tolerations:
  - key: "key1"
    operator: "Equal" # operator 默认值
    value: "value1"
    effect: "NoSchedule"
  - key: "key1"
    operator: "Exists" # 此时不能指定对应的value，如无特别说明，官方指定不能的情况，加上一般会报错，无法继续进行对应的操作
    effect: "NoSchedule"
  - key: "" # 此时可以被调度到任何具有`NoSchedule`效果的Taint所在的节点上
    operator: "Exists"
    effect: "NoSchedule" # effect也可以使用其他值，如PreferNoSchedule等
  - key: "key1"
    effect: "" # 可以与所有key1的效果匹配

effect 允许设置的值

高级用法

1. 可以通过自己实现一些准入控制器(AdmissionControllers)
2. 可以采用一些[插件]，运行ExtendedResourceToleration准入控制器,来实现对特定设备集群的管理

基于 Taint 的驱逐

当前内置的 Taint:

1. node.kubernetes.io/not-ready
2. node.kubernetes.io/unreachable
3. node.kubernetes.io/memory-pressure
4. node.kubernetes.io/disk-pressure
5. node.kubernetes.io/pid-pressure
6. node.kubernetes.io/network-unavailable
7. node.kubernetes.io/unschedulable
8. node.cloudprovider.kubernetes.io/uninitialized

DaemonSet 的特别说明

DaemonSet 控制器会自动为所有的 Pod 添加如下NoSchedule的 Toleration:

1. node.kubernetes.io/memory-pressure
2. node.kubernetes.io/disk-pressure
3. node.kubernetes.io/pid-pressure (v1.14+)
4. node.kubernetes.io/unschedulable (v1.10+)
5. node.kubernetes.io/network-unavailable (仅适用主机网络配置???)

针对以下 TaintNoExecute的 Toleration 将不会指定tolerationSeconds：

1. node.kubernetes.io/unreachable
2. node.kubernetes.io/not-ready

调度框架 [TBD]

动态资源分配 (alpha 特性)

feature-gate 需要被显示启用，可通过自己开发或者使用第三方插件来实现，目前(v1.29.3-)resource.k8s.io/v1alpha2API 组提供四种类型：

1. ResourceClass 定义资源驱动程序
2. ResourceClaim 定义资源申请
3. ResourceClaimTemplate
4. PodSchedulingContext

调度器性能调优

对于大规模的集群(可能有 50+节点)，有必要设置一个合适的percentageOfNodesToScore，让调度器快速做出响应，调度器覆盖所有节点的方式，当前的手段就是轮询遍历评估可调度性。更复杂的调度可能需要根据自己的架构特性来实现自定义调度器。

调度插件 – NodeResourcesFit

支持 2 种“bin packing”

1. MostAllocated 基于资源的利用率来为节点计分，优选分配比率较高的节点，可以设置weight来影响调度结果
2. RequestedToCapacityRatio 允许用户基于请求值与容量的比率，针对参与节点计分的每类资源设置权重

计分函数

shape:
  - utilization: 0 # 0%：节点评分为0
    score: 0
  - utilization: 100 # 100%：节点评分为10
    score: 10

节点容量分配的评分 [TBD]

Pod 优先级与抢占

PriorityClass

PriorityClass可以允许 Pod 有优先级的区别，优先级越高的 Pod 越容易被调度，越容易进入运行状态。PriorityClass对象对应的取值范围是从 -2,147,483,648 到 1,000,000,000（含）。更大的数字用于标识集群关键 Pod 的内置PriorityClass。使用PriorityClass需要了解的点：

1. PriorityClass提供globalDefault(表示这个值应用于没有priorityClassName的 Pod，且系统中只能有一个设置了该字段的PriorityClass，如果不存在设置了globalDefault的PriorityClass，则没有priorityClassName的 Pod 优先级为 0)与description(任意字符串)字段。
2. PriorityClass仅对新增的 Pod 有效，已存在的 Pod 不会因为PriorityClass的创建而提升优先级，即这类 Pod 优先级还是 0；如果删除了PriorityClass，则使用被删除的PriorityClass的 Pod 优先级保持不变，但是无法再创建已删除的PriorityClass的 Pod。

Non-preempting PriorityClass

配置了preemptingPolicy: Never的 Pod 将被放置在调度队列中较低优先级 Pod 之前，但它们不能抢占其他 Pod 的资源，等待调度的非抢占式 Pod 将留在队列中，直到有资源满足，才可以被调度。非抢占式的 Pod 如果调度失败，会以更低的频率被重试，从而允许其他较高优先级的 Pod 被调度。即无论是配置了优先级还是没有配置优先级的普通 Pod 都会被 back-off（重试）。preemptionPolicy默认为PreemptLowerPolicy，这允许这类 Pod 抢占较低优先级的 Pod（默认行为）。如果preemptionPolicy: Never，则该PriorityClass中的 Pod 将是非抢占式的。

总之，Pod 被调度的优先级顺序为：spec.priorityClassName > preemptingPolicy: Never > preemptingPolicy: PreemptLowerPriority(default，未设置也是它)

Preemption

Pod 被创建后，会进入 Pending 状态，如果没有找到足够的资源或者匹配的节点，则触发对 Pending 状态的 Pod 的抢占逻辑。也就是节点会优先部署高优先级的 Pod。同时因资源被抢占而未被调度的 Pod 会被设置nominatedNodeName字段，用于跟踪为该 Pod 保留的资源，用户可以据此判断有关集群中的抢占信息。同时被标记nominatedNodeName的 Pod 将来不一定会被部署到这个字段指定的节点，调度程序会在任何其他节点尝试，因此nominatedNodeName与nodeName并不总是相同，而且该 Pod 最终也有机会抢占另一个节点 Pod 所对应的资源。

因被抢占而被 kubelet 杀死的 Pod

会有一个体面终止期，这段时期从 Pod 被抢占开始到成功调度抢占的 Pod，因此用户可以根据实际需求适当调小低优先级 Pod 的体面终止时间，具体字段为：spec.terminationGracePeriodSeconds (default 30s)，如果超过这个时间，Pod 会被 kubelet 强制杀死。

支持 PodDisruptionBudget，但不保证

PodDisruptionBudget(PDB)允许设置多副本 Pod 所有者限制因自愿性质的干扰而同时终止的 Pod 数量。调度器在抢占 Pod 时对 PDB 的支持时尽力而为的，即会尽力去寻找符合 PDB 约束的牺牲者，如果没有找到，抢占还是会进行，并且即便是违反了 PDB 约束，也会删除优先级较低的 Pod。

与低优先级 Pod 之间的亲和性 [TBT]

处于 Pending 的 Pod 与节点上的一个或多个较低优先级的 Pod 具有亲和性，如果在一个目标节点上没有除去这些具有亲和性 Pod 的其他一些低优先级 Pod，则抢占不会发生。相反，如果在另一个节点上找到合适的 Pod，也无法保证处于 Pending 的 Pod 可以被调度。

也就是说这种情况下，处于 Pending 状态的 Pod 可能永远处于 Pending，尽管它具备较高的优先级。 官方给出的解决方案是仅针对同等或更高优先级的 Pod 设置 Pod 间亲和性。

跨节点抢占

本来节点 N 上有一个处于 Pending 的 Pod P，只有当另一个节点上的 Pod Q 具有反亲和性规则，且在同一可用区，这个时候才会发生跨节点抢占，当且仅当 Pod Q 被抢占时，但是目前的版本还未实现这一点。

截止(v1.29.3)官方还没有给出跨节点抢占合理的算法，未来可能会有。

总结

抢占如果要发生，必须要满足优先级要求，即被抢占资源的永远是那些具有低优先级的 Pod。

PriorityClass 与 QoS

Pod 的优先级与 QoS，二者并无直接关联，基于 QoS 类设置的 PriorityClass 没有默认限制。QoS 类可以被用来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 的驱逐进行排名：

1. 对紧俏资源的使用是否超过请求值
2. Pod 优先级：如果较低优先级的 Pod 资源使用量没有超过其配额时，kubelet 不会驱逐该 Pod，相反，如果优先级较高且资源用量超过其配额时，Pod 可能被驱逐
3. 相对于请求的资源使用量：当 Pod 资源使用量未超过其资源配额时，kubelet 不会驱逐该 Pod

节点压力驱逐

节点压力驱逐是 kubelet 主动终止 Pod 来释放节点资源(如 CPU，Memory，Volume，以及 fs 的 inode 等)的过程。压力驱逐期间 Pod 的状态会被 kubelet 标记为 Failed，节点压力驱逐是一个主动的过程。压力驱逐会排除设置的PodDisruptionBudget或者是 Pod 的terminationGracePeriodSeconds，对于软驱逐条件，会使用eviction-max-pod-grace-period，硬驱逐会立即杀死 Pod。

Pod 自我修复行为

1. 对于受如 Deployment，RS 等控制器干预的 Pod，控制器会自动创建新 Pod 来替换旧的 Pod
2. 对于创建的裸 Pod，kubelet 会尝试使用新的 Pod 来替换旧的，且这类裸 Pod 的优先级是会被 kubelet 纳入是否驱逐的因素

kubelet 的驱逐策略

1. 驱逐信号：linux 系统，kubelet 使用的驱逐信号：

每个信号支持百分比或具体数值，kubelet 使用百分比来确定驱逐条件。上述具体数值的获取都是由 cgroup 提供的。

2. 驱逐条件：节点上应该可用资源的最小值，格式：[eviction-signal][operator][quantity]，如：memory.available < 10%，memory.available < 1G

   • 硬驱逐条件，没有宽限期，立即驱逐，使用 eviction-hard 如：memory.available<100Mi，nodefs.available<10%
   • 软驱逐条件，过了宽限期才驱逐，使用 eviction-soft eviction-soft-grace-period eviction-max-pod-grace-period 如：

3. 驱逐检测间隔：housekeeping-interval（默认为 10s）评估驱逐条件

节点状态

kubelet 根据下表将驱逐信号映射为节点状态

此外，control-plane-panel 还将这些节点状态映射为其 Taint。kubelet 根据配置的 –node-status-update-frequency 更新节点条件，默认为 10s。

节点状态波动

要尽量避免节点状态波动，可以设置eviction-pressure-transition-period，该值指定了不同状态必须等待的时间，默认为 5m

主动回收节点资源

1. 专用 imagefs，如果有 nodefs 满足驱逐条件，kubelet 会收集死亡的 Pod 和容器；如果有 imagefs 满足驱逐条件，kubelet 将删除所有为使用的镜像
2. 没有专用的 imagefs，如果节点只有一个满足驱逐条件的 nodefs，kubelet 将首先对死亡的 Pod 和容器进行垃圾回收，然后删除未使用的镜像

Pod 的驱逐顺序

如果以上的步骤，无法降低对应节点资源的压力，kubelet 将开始驱逐 Pod，根据 Pod 资源使用量与优先级等情况，按以下顺序来驱逐 Pod：

1. 资源使用量超过其请求的 Pod，如BestEffort或Burstable，会根据各自的优先级，以及资源使用超过其请求的程度被驱逐
2. 资源使用量少于请求量的Guaranteed和Burstable根据其优先级最后被驱逐

Note: QoS 不适用于EphemeralVolume，如果节点在 DiskPressure 下，上述顺序不适用。

仅当 Guaranteed Pod 中所有容器都被指定了请求和限制并且二者相等时，才保证 Pod 不被驱逐。如果不足以缓解系统资源压力，尽管满足不被驱逐的条件，但是还是会驱逐优先级低的 Pod。

对于裸 Pod，如果希望免在资源压力下被驱逐，需要直接设置spec.priority字段，裸 Pod 不支持spec.priorityClassName。

当 kubelet 因 inode 或 进程 ID 不足而驱逐 Pod 时， 它使用 Pod 的相对优先级来确定驱逐顺序。

kubelet 根据节点是否具有专用的 imagefs 文件系统对 Pod 进行不同的排序：

• 有 imagefs，如果 nodefs 触发驱逐， kubelet 会根据 nodefs 使用情况（本地卷 + 所有容器的日志）对 Pod 进行排序。
• 没有 imagefs，如果 nodefs 触发驱逐， kubelet 会根据磁盘总用量（本地卷 + 日志和所有容器的可写层）对 Pod 进行排序。

最小驱逐回收

为 kubelet 配置--eviction-minimum-reclaim参数可免于在资源紧俏的情况下，kubelet 反复回收资源，多次驱逐

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "1Gi" #达到 1Gi 的条件
  imagefs.available: "100Gi" #达到 100Gi 的条件
evictionMinimumReclaim:
  memory.available: "0Mi"
  nodefs.available: "500Mi" #继续回收至少 500MiB,直到条件达到 1.5GiB
  imagefs.available: "2Gi" #继续回收至少 2GiB，直到条件达到 102GiB

节点内存不足时的行为

如果节点在 kubelet 能够回收内存之前遇到内存不足（OOM）事件， 则节点依赖[oom_killer]来响应。

kubelet 还将具有 system-node-critical 优先级 的任何 Pod 中的容器 oom_score_adj 值设为 -997。如：kube-scheduler，kube-apiserver，etcd 等组件。

这意味着低 QoS Pod 中相对于其调度请求消耗内存较多的容器，将首先被杀死。

最佳实践

1. 配置 kubelet 时预留一定内存给系统比如 10%，然后在加上驱逐阈值，比如 16G 的系统内存，如果驱逐阈值是 500M，则预留约 2.1G 给系统，避免系统奔溃
2. 为一些节点性质的 Pod，比如 DaemonSet 控制器相关的 Pod 设置比较高的优先级，避免被 kubelet 杀死

已知问题

1. kubelet 可能不会立即观察到内存压力，如果追求极端的利用率，可以使用--kernel-memcg-notification以便在超过条件时立即执行 Pod 驱逐，如果不追求极端的利用率，可以设置--kube-reserved于--system-reserved为系统预留一定量的内存
2. active_file 内存未被视为可用内存，可能导致 Pod 驱逐发生，截止(v1.29.3)这是一个已知的未解决的问题，可以通过为可能执行 I/O 密集型活动的容器设置相同的内存限制和内存请求来应对该行为，为此，将需要估计或测量该容器的最佳内存限制值

Eviction API 发起的驱逐

用户可以调用Eviction API发起驱逐，也可以通过kubectl drain发起驱逐。API 发起的驱逐遵循PodDisruptionBudget和terminationGracePeriodSeconds配置。

相关的 http 状态码

1. 200：允许驱逐
2. 429：Too Many Requests，当前不允许驱逐，可能因为不满足PodDisruptionBudget配置，可稍后尝试
3. 500：服务器配置错误，如多个PodDisruptionBudget引用同一个 Pod

解决驱逐被卡住

1. 暂停 Deployment 等控制器的自动化操作，可以设置如suspend字段
2. 不使用Eviction API，直接删除对应的 Pod，如调用kubectl delete

插件: https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources [oom_killer]: https://lwn.net/Articles/391222/

1. 过滤，根据 Pod 定义的条件，如"required"强制限制节点 label 匹配，以及限制 Pod 必须满足某些条件，对于podAffinity可以有多个labelSelector等条件，对于nodeAffinity只能是一个，但是可用多个matchExpressions等条件
2. 打分，根据 Pod 定义的nodeAffinity与podAffinity，以及nodeAntiAffinity，podAntiAffinity等"preferred"偏好条件，以及weight打分（weight 数值越高，Pod 越有可能被调度到对应条件的节点上）

可用的过滤条件

1. 节点标签：如 kubernetes.io/hostname, kubernetes.io/os
2. 节点隔离/限制：如NodeRestriction插件使用的带有node-restriction.kubernetes.io前缀的标签
3. .spec.affinity.nodeAffinity
4. .spec.affinity.podAffinity与.spec.afffinity.podAntiAffinity，以及.spec.affinity.podAffinity.[].topologyKey集群用来标识域的节点标签键
5. namespaceSelector (v1.29 alpha)
6. .spec.nodeName 有一些局限性，这个条件不稳定
   1. 如节点不存在，Pod 无法运行，在某些情况下可能被自动删除
   2. 在云环境中的节点名称并总不是可预测与稳定的
   3. 当然节点没有对应的资源运行该 Pod，仍然会失败，这个条件在非.spec.nodeName情况都满足，只不过非.spec.nodeName条件 Pod 部署不一定会失败，有可能是处于pending

可选的方式

1. requiredDuringSchedulingIgnoredDuringExecution 硬性条件，强制限制
2. preferredDuringSchedulingIgnoredDuringExecution 软性条件，偏好限制，有更好，没有也可以，该方式是一个数组，可以提供weight(越大越优先)来加强或减弱某个条件

可用的选项

1. nodeAffinity
   1. nodeSelectorTerms
2. podAffinity与podAntiAffinity
   1. matchLabelKeys
   2. mismatchLabelKeys
   3. topologyKey
   4. labelSelector
3. …

可用的操作符

调度方案

1. 逐个调度方案中设置nodeAffinity，需要在调度适配器启用NodeAffinity 插件

   apiVersion: kubescheduler.config.k8s.io/v1beta3
   kind: KubeSchedulerConfiguration
   
   profiles:
     - schedulerName: default-scheduler
     - schedulerName: foo-scheduler
       pluginConfig:
         - name: NodeAffinity
           args:
             addedAffinity:
               requiredDuringSchedulingIgnoredDuringExecution:
                 nodeSelectorTerms:
                   - matchExpressions:
                       - key: scheduler-profile
                         operator: In
                         values:
                           - foo
   

Pod 调度就绪状态 (v1.27 beta)

通过指定.spec.schedulingGates可以控制 Pod 何时准备好被考虑调度。如果 Pod 已经就绪，可以将对应的字段清空，然后对 Pod 执行更新操作。如果指定了该字段，有以下情况允许，更新对应字段：

1. 如果设置了该字段，在没有.spec.nodeSelector的情况下，可以允许更新此字段
2. 如果spec.affinity.nodeAffinity为 nil，则允许设置任意值
3. 如果NodeSelectorTerms之前没有设置，则现在允许设置；如果之前已经设置了，那么仅允许添加对应的条目，不允许更新之前已经存在的条目
4. 对于preferredDuringSchedulingIgnoredDuringExecution，所有更新现在都允许

可以使用scheduler_pending_pods{queue="gated"}查看调度的具体指标情况。需结合一些指标组件，如metric-server。

Pod 拓扑分布域

分布域是一个类似组的概念对集群中的节点进行分组，按区域划分，使整个大的集群有一定的抗风险与自愈能力。.spec.topologySpreadConstraints定义了对集群可用区使用的调度规则，使用该功能最重要的要求是如果集群自动为节点打的标签无法满足需求，用户需要自定义标签的时候，需要保证集群所有的 key 的一致性，否则调度结果可能会匪夷所思，排查也会很困难。

---
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # 配置一个拓扑分布约束
  topologySpreadConstraints: # 多个条目之间是逻辑与关系，默认无特别说明都是逻辑与
    - maxSkew: <integer>
      minDomains: <integer> # 可选；自从 v1.25 开始成为 Beta
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # 可选；自从 v1.27 开始成为 Beta
      nodeAffinityPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
      nodeTaintsPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
  ...

1. maxSkew 描述这些 Pod 可能被不均匀分布的程度，具体受制于
   1. whenUnsatisfiable: DoNotSchedule 描述可用区分布 Pod 数量最小值的差值
   2. whenUnsatisfiable: ScheduleAnyway 该调度器会更为偏向能够降低偏差值的拓扑域
2. minDomains 表示符合条件的域的最小数量
3. topologyKey 节点标签 key
4. whenUnsatisfiable: DoNotSchedule(default), ScheduleAnyway
5. labelSelector 用于查找匹配的 Pod
6. matchLabelKeys 用于选择需要计算分布方式的 Pod 集合，matchLabelKeys和labelSelector不允许有相同的 key
7. nodeAffinityPolicy: Honor, Ignore
8. nodeTaintsPolicy: Honor, Ignore

隐式约定

1. 只有与新来的 Pod 具有相同命名空间的 Pod 才能作为匹配候选者
2. 调度器会忽略没有任何 topologySpreadConstraints[*].topologyKey 的节点，意味着这些节点上的 Pod 不会影响maxSkew的计算
3. topologySpreadConstraints[*].labelSelector与 Pod 自身的标签不匹配，将不会改善集群的不平衡程度

集群级别的默认约束

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway
          defaultingType: List

为集群设置默认的拓扑约束，可以在以下条件满足时被应用到 Pod 上：

1. Pod 没有在其 .spec.topologySpreadConstraints 中定义任何约束
2. Pod 隶属于某个 Service、ReplicaSet、StatefulSet 或 ReplicationController

内置的默认约束 (v1.24 stable)

defaultConstraints: # 可以被用户覆写
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway

已知的局限 (截止 v1.29.3)

1. 当缩减某个控制器控制的 Pod 时，现阶段的方案无法保证 Pod 分布均衡
2. 具有污点的节点上匹配的 Pod 也会被统计
3. 任何情况下至少保证每个拓扑域(节点组)中至少有一个可用节点，否则调度可能会异常

Ignore the committed files

# Add the target files into .gitignore
echo <somefile or folder> >> .gitignore

# Remove the files from the git index (not the actual files in the working dir)
git rm -r --cached .

# Add these removals to the staging area
git add .

# Commit them
git commit -m "Clean up ignored files"

Rewrite email of the history

brew install git-filter-repo
git filter-repo --email-callback '
      if b"old_email@example.com" in email:
          return email.replace(b"old_email@example.com", b"new_email@example.com")
      else:
          return email
  ' --force

Volumes 用来保证在 k8s 集群中部署有存储需求应用的一类对象。

存储分类

1. 持久化存储
   1. 预先制备，可以根据卷模式，容量，类，回收策略，读写方式，挂载选项，以及一些 alpha 特性（吞吐量，io 等）等制备一批存储卷 PV
   2. 动态制备，需要自己开发或者使用第三方存储
2. 临时存储

卷类型

1. emptyDir 在 Pod 被指派到某节点时，此卷会被创建，最初是空的，不具备持久性
2. fc 光纤通道
3. . hostPath 即将容器中的卷映射到节点宿主系统，此操作有安全风险，因为可以指定宿主系统任意位置去挂载
4. iscsi 删除卷，数据会被保留，卷只是被卸载，缺点：不允许同时写入，只能由一个 Pod 读写
5. local 卷只能用作静态创建的持久卷，不支持动态配置，代表的是被挂载的本地存储设备，如磁盘，分区或者目录
6. nfs linux 提供的一种网络文件存储服务
7. …

卷模式 volumeMode

1. FileSystem (default) 文件系统
2. Block 块设备

存储容量

对于已经挂载 PV 的 PVC，是不允许执行容量变更的 (PVC 中的其他字段也不允许变更)

存储类 StorageClass

用于可自定义一些存储类，当没有给容器配置默认存储类的时候，系统中如果有默认存储类，则直接使用，如果集群中没有默认存储类，当添加了默认存储类的时候

回收策略

1. Retain (default) 当 Pod 被回收的时候，存储会处于 Released 的状态，等待管理员人工干预
2. Delete 当 Pod 被回收的时候，存储会自动被删除，需要用户自己实现删除策略，否则会删除失败 Failed
3. Recycle (rm -rf /thevolume/*) 简单擦除，v1.29，只有nfs和hostPath支持

访问方式

1. ReadWriteOnce (RWO) 卷可以被同一个节点以读写方式挂载
2. ReadOnlyMany (ROX) 卷可以被多个节点以只读方式挂载
3. ReadWriteMany (RWX) 卷可以被多个节点以读写方式挂载
4. ReadWriteOncePod (RWOP) (v1.29 stable) 卷可以被一个 Pod 以读写方式挂载

NOTE: 此处的访问方式，并不会实际保证限制对应的读写，读写的具体限制，还是要看使用什么样的存储与存储服务

挂载选项 mountOptions

volume.beta.kubernetes.io/mount-options 该注解将来可能会被彻底废弃

1. nfs linux 提供的一种网络文件存储服务
2. iscsi 同上
3. vsphereVolume
4. azureFile

节点亲和性

需要为local卷显示地设置spec.nodeAffinity

持久卷状态

1. Available 卷是一个空闲资源，尚未绑定到任何 PVC
2. Bound 卷已经绑定到某 PVC
3. Released 卷所绑定的 PVC 已经被删除，但是关联的存储资源尚未被回收
4. Failed 卷的自动回收操作失败

卷快照 VolumeSnapshots

卷快照为集群用户提供了一种标准的方式，来在指定时间点复制卷的内容，并且不需要创建全新的卷。比如对某个数据库做更新或删除的时候，可以在这操作之前对卷做一个快照。

• 制备方式，可以预制备，动态制备
• 删除方式，删除 VolumeSnapshots 会出发 VolumeSnapshotContent 一起删除
• VolumeSnapshotClass 可以根据一些参数（如回收策略，访问方式，driver 等）定义快照类对象

CSI 卷克隆

卷克隆会为卷副本拷贝原来的数据，需要使用dataSource或dataSourceRef来引用同一命名空间中现有的 PVC

跨命名空间使用卷

创建 ReferenceGrant 对象，声明from与to

Projected Volumes

1. secret
2. configMap
3. downwardAPI 用来在容器内部挂载 Pod 元数据信息
4. serviceAccountToken 服务账号令牌卷
5. clusterTrustBundle (v1.29 alpha) 是一个作用域为集群的对象，向集群内的对象分发 X.509 根证书

Volume Attributes Classes (v1.29 alpha)

可以配置一些存储设备的特性如：iops，throughput

临时卷

1. 类型
   1. emptyDir
   2. configMap,downwardAPI,secret
   3. CSI 临时卷
   4. 通用临时卷
2. 其生命周期跟随 Pod，即删除 Pod 该卷也会同步删除，不同于 Docker 中的卷

卷健康监控

需要启用CSIVolumeHealth，可以上报节点失效事件，支持节点卷健康检测

要 StatefulSet 控制器，需要一个无头服务clusterIP: None，可以为有状态服务提供 4 个特性

1. 稳定的网络标识
2. 稳定的持久化存储
3. 有序的扩容，Pod 副本数量将从 0 ～ N-1 有序部署，第 i 个 Pod 要想部署成功，比如要前 i-1 个 Pod 处于 Running 的状态
4. 有序的缩容，Pod 副本数量将从 N-1 ~ 0 有序缩容，第 i 个 Pod 要想被回收，必须要等到从 i+1 到 N-1 的 Pod 都被回收

有序的扩缩容

所有 StatefulSet 控制器创建的 Pod 都会按照序号从小到大扩容和从大到小缩容，如果过程中，之前创建或回收的 Pod 失败，则不会继续进行相应的扩容或缩容，必须要等到那个有问题的 Pod 状态为 Running 或者成功回收

稳定的网络标识

因为 Pod 的名称 ${podname}-{N} 是固定的，所以集群内部的 dns 插件，可以为这些 pod 提供稳定的域名解析，即使 Pod 回收后的重建，如：

1. web-0.nginx.default.svc.cluster.local
2. web-0.nginx

稳定的网络存储

也是因为 Pod 名称固定，所以对于 PVC 绑定的 PV，如果因为 Pod 删除后重建，还能够自动关联相同名称的 Pod

其他要点

1. spec.updateStrategy.rollingUpdate.maxUnavailable [1.24 alpha]（default 1）该字段用来控制更新期间最大不可用的 Pod 数量，默认为 1，可以是具体数字，可以是百分数10%，但是不能为 0
2. spec.minReadySeconds（单位：s，default: 0）最短就绪时间，可以根据自己的应用适当设置，否则也有可能会导致 Pod 无限等待，因为还有*Probe和容器启动“hook”等手段检测 Container 是否就绪
3. 如果 Pod 模版配置无法进入Running状态或Ready状态，需要管理员强制删除的时候，安全的做法是先将replicas=0副本数设置为 0，然后在执行强制删除，等到修复完毕 Pod 模版的时候，在更新replica

应用场景

1. 提供对存储在 Secret 中的敏感信息的只读访问
2. 授予跨名字空间访问的权限
3. Pod 需要与外部服务器通信
4. 使用imagePullSecret完成私有镜像仓库的身份认证
5. 外部服务需要与 kube-apiserver 通信，如 CI/CD
6. 集群上的第 3 方软件，该软件依赖不同 Pod 的 ServiceAccount

手动获取 ServiceAccount Token

1. TokenRequest API（推荐）
2. 以 Volume 的方式挂载（推荐）
3. ServiceAccount Token Secret （不推荐）这些 Token 不会过期，有安全隐患，LegacyServiceAccountTokenNoAutoGeneration默认启用

Secret 的应用

Secret 可以将少量敏感信息（大小不超过 1M）与应用分离，保存敏感信息的 k8s 对象，如密码，令牌或密钥等信息，可以通过文件的方式挂载到容器中使用，也可以通过环境变量的方式注入到容器中。ConfigMap 可用于保存一些配置文件（大小不超过 1M）。

1. 如容器启动注入环境变量
2. 向 Pod 提供 SSH 密钥或密码等信息
3. 从私有镜像仓库拉取镜像

Secret 的内置类型

以下类型的数据都是用 base64 编码，使用的时候都是自动解码，用户无需干预

1. Opaque 用户定义的任意数据
2. kubernetes.io/service-account-token ServiceAccount 的令牌
3. kubernetes.io/dockercfg ~/.docker/config.json 旧版
4. kubernetes.io/dockerconfigjson ~/.docker/config.json 新版
5. kubernetes.io/basic-auth 基本的身份验证
6. kubernetes.io/ssh-auth SSH 身份的认证的私钥凭据
7. kubernetes.io/tls 用于 TLS 客户端或服务器端的数据
8. bootstrap.kubernetes.io/token 启动引导令牌数据

Secret 的其他要点

1. 保持最少特权访问原则 kubernetes.io/enforce-mountable-secrets: "true"
2. 将 Secret 标记为不可更改 immutable: true

Secret 的替代方案

1. 可以使用 ServiceAccount 替代
2. 可是使用设备插件来替代
3. 对于身份验证，可以使用CertificateSigningRequest定制的签名验证来为 Pod 发放证书
4. 可以使用第三方工具，来提供机密数据

Secret 使用的良好实践

集群管理员

1. 配置静态加密，配置 kube-apiserver 使用EncryptionConfiguration对象对 Secret 进行对称加解密
2. 配置 Secret 资源的最小特权访问
   • 组件：限制仅最高特权的系统级组件可以访问，仅在组件的正常行为需要时才授予权限
   • 人员：限制对 Secret 的访问，仅允许集群管理员访问 etcd
   • 对访问 Secret 的用户或 Pod（因为用户可以通过 Pod 访问到 Secret）做记录
3. 在 ServiceAccount 上使用kubernetes.io/enforce-mountable-secrets注解来强制执行有关如何在 Pod 中使用 Secret 的特定规则
4. 改进 etcd 的管理策略，不在使用 etcd 所使用的持久存储时，考虑格式化对应的设备；在多个 etcd 实例之间使用 SSL/TLS 通信以保护传输中的 Secret
5. 配置对外部 Secret 的访问，可以使用第三方 Secret 的解决方案，然后配置 Pod 访问该数据

开发者

1. 限制特定容器集合才能访问 Secret，如果一个 Pod 中仅有一个容器需要访问 Secret，则可以 mount volume 或者使用环境变量的方式，避免其他容器访问该 Secret
2. 读取后保护 Secret 数据，应用程序必须避免以明文记录 Secret 数据，必须避免将这些数据传输给不受信任的一方
3. 避免共享 Secret manifest，提防 Secret manifest 中包含 base64 编码的数据

ConfigMap 的应用

ConfigMap 可以为应用提供配置文件信息，如

1. nginx 配置文件
2. 应用启动所需准备的配置文件

Secret 与 ConfigMap 的对比

相同之处：

1. 二者都可以通过环境变量的方式注入容器
2. 二者都可以通过文件的方式挂载到容器内部
3. 二者的大小限制都是不超过 1M
4. 都可以设置为immutable: true
5. 二者的访问都可以单独配置对应的权限
6. 对于以文件方式挂载，二者都支持热更新，但是如果使用了subPath则容器不会接收到更新，当然设置了immutable: true就不会有任何作用了

不同之处：

1. Secret 保存的都是通过 base64 编码或者其他加密方式经过处理的数据
2. ConfigMap 保存的数据是原始数据，没有对数据做任何加工处理
3. ConfigMap 需要保证数据信息是 KV 结构才能以环境变量的方式注入容器
4. Secret 需要自己设置对应的环境变量名称去注入到容器
5. Secret 可以使用定制的方式，对机密数据加密与解密
6. Secret 存储敏感信息，ConfigMap 存储非敏感信息

CronJob used for performing regular scheduled actions such as backups, report generation…

Schedule syntax

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
# │ │ │ │ │                                   OR sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

Deadline for delayed Job start

spec.startingDeadlineSeconds

• After missing the deadline, the CronJob skips that instance of the job (future occurrences are still scheduled)
• For Jobs that miss their configured deadline, Kubernetes treats theme as failed Jobs. No startingDeadlineSeconds, no deadline for this CronJob.
• If the spec.startingDeadlineSeconds field is set, the CronJobController measures the time between a Job is expected to be created and now. If the difference is higher than that limit, it will ship this execution.

注意：如果 startingDeadlineSeconds 的设置值低于 10 秒钟，CronJob 可能无法被调度。 这是因为 CronJob 控制器每 10 秒钟执行一次检查。

Concurrency policy

spec.concurrencyPolicy specifies how to treat concurrent executions of a Job that is created.

• Allow (default): allow concurrently run.
• Forbid: Do not allow concurrent runs.
• Replace: old and new Job may run at the same time, the new one will replace the old one.

Schedule suspension

spec.suspend = true for this case. When spec.suspend changes from true to false on an existing CronJob without a spec.startingDeadlineSeconds, the missed Jobs are scheduled immediately.

Jobs history limits

spec.successfulJobsHistoryLimit = 3, spec.failedJobsHistoryLimit = 1. These fields specify how many completed and failed jobs should be kept.

Time zones (v1.27 stable)

spec.timeZone instructs Kubernetes to interpret the schedule relative to Coordinated Universal Time.

CronJob limitations

• Unsupported TimeZone specification

  CRON_TZ or TZ is not officially supported, and starting with v1.29, Kubernetes will fail to create the resource with a validation error.

• Modify a CronJob

  Modify an existing CronJob will have no effect to existing Jobs, and new Jobs will take effect.

• Job creation

  The Jobs that user defined are idempotent. If the scheduled time from last time until now, the missed count > 100, then new Job will not be created from now.

1. 通常只启动一个 Pod，除非该 Pod 失败
2. 当 Pod 成功终止时，立即视 Job 为完成状态

关键指标：

• spec.completions = 1 默认值为 1
• spec.parallelism = 1 默认值为 1

并行的 Job

1. 具有确定完成计数的并行 Job
   • spec.completions > 0，可以设置或者不设置spec.parallelism，默认值为 1
   • Completed Job，当成功 (exitCode = 0) Pod 个数达到spec.completions
   • spec.completionMode = Indexed, Job index (0-spec.completions-1)
2. 带工作队列的并行 Job
   • No spec.completions, default is spec.parallelism >= 0，and must set spec.parallelism
   • Coordinated Pod，or specify Pod do which item(s)
   • Pod know its peer Pods are completed or not，to determine Job completed or not
   • No more new Pods, when Pod terminated successfully
   • Job completed when Pod (>=1 terminated) and other Pods terminated successfully
   • Pod exited successfully, no other Pod will keep doing this task and will be in exiting process.

控制并行：

spec.parallelism >= 0，如果为 0，则 Job 相当于启动之后立即被暂停。实际在任意状态运行的 Pod 个数可能比spec.parallelism略大或略小，原因如下：

• For fixed completion count Job，paralleled Pod number <= remaining completion count
• For work queue Job，有任何的 Job 成功结束之后，不会有新的 Pod 启动，对于已经运行的 Pod，允许执行完毕
• 如果 JobController 没来得及做出响应，或者 JobController 因为任何原因（如资源不足，缺少 ResourceQuota 或者没有权限）无法创建 Pod。则 Pod 个数可能比请求的数目小
• JobController 可能因为之前同一 Job 中 Pod 失败次数过多而压制新 Pod 的创建
• 当 Pod 处于体面终止进程中，需要一定时间才能停止

Job Completion Mode

spec.completions > 0 && spec.completionMode in (NonIndexed, Indexed)

• NonIndexed (default)
• Indexed, get this index value through four mechanisms
  1. Pod annotation batch.kubernetes.io/job-completion-index
  2. When PodIndexLabel (default enabled) feature gate enabled, Pod label batch.kubernetes.io/job-completion-index (>= v1.28).
  3. Pod hostname, $(job-name)-$(index). When use an IndexedJob in combination with a Service, Pods within the Job can use the deterministic hostnames to address each other via DNS. Job with Pod-to-Pod Communication
  4. For the containerized task, use environment variable JOB_COMPLETION_INDEX

Reference: http://kubernetes.io/docs/concepts/workloads/controllers/job/#completion-mode

Handing Pod and container failures

• User should handle spec.template.spec.restartPolicy = OnFailure, or set spec.template.spec.restartPolicy = Never
• User should handle temporary files, locks, incomplete output by yourself
• Each Pod failure is counted in spec.backoffLimit.
• Count Pod failure in spec.backoffLimitPerIndex
• Set spec.parallelism = 1 && spec.completions = 1 && spec.template.spec.restartPolicy = Never can not make sure the program run one time.
• User should handle currency for spec.parallelism > 1 && spec.completions > 1
• Feature gate PodDisruptionCondition and JobPodFailurePolicy enabled and spec.podFailurePolicy be set, JobController will not treat Pod with metadata.deletionTimestamp as a failure Pod, until the Pod terminated (.status.phase in Failure Success). Once the Pod terminated, the JobController evaluates .backoffLimit and .podFailurePolicy for relevant job, consider this now-terminated Pod failed or not.
• No above situation suited, JobController counts a terminating Pod as an immediate failure, even through that Pod terminates with phase = Succeed later.

Pod backoff failure policy

Set spec.backoffLimit = X, when Job retries count is X, the Job is marked failure. Default spec.backoffLimit = 6，backoff time (10s, 20s, 40s) until 6m.

• status.phase = Failed
• restartPolicy = OnFailure && status.phase in (Pending,Running)

Official suggestion: restartPolicy = "Never" and using a logging system to record logs.

Backoff limit per index

Feature gate JobBackoffLimitPerIndex should be enabled.

• Set spec.backoffLimitPerIndex for handling retries for Pod failure
• Failed Job index will be added in status.failedIndexes. Completed Job index will be added in status.completedIndex, regardless of backoffLimitPerIndex field
• A failing index Job does not interrupt execution of other indexes. If one index Job failed, the overall IndexedJob will be marked failed.
• JobController will terminate the entire job failed by setting spec.maxFailedIndexes, including the running Pods for that Job.

Pod failure policy

Feature gate JobPodFailurePolicy enabled, recommended PodDisruptionConditions enabled, supported in v1.29.

spec.podFailurePolicy enables k8s cluster to handle Pod failures based on the container exit codes and the Pod conditions.

A better control for handling Pod failures than the Pod backoff failure policy, based on spec.backoffLimit.

• For avoiding unnecessary Pod restarts
• Guarantee Job and ignore Pod failures caused by disruptions (eg. preemption, API-initiated eviction or taint-based eviction) so that don’t count spec.backoffLimit

Note: Because the Pod template specifies a restartPolicy: Never, the kubelet does not restart the main container in that particular Pod.

Ignore action for failed Pods with condition DisruptionTarget excludes Pod disruptions from being counted towards spec.backoffLimit

Note: If the Job failed, either by the Pod failure policy or Pod backoff failure policy, and the Job is running multiple Pods, Kubernetes terminates all the Pods in that Job that are still Pending or Running.

API requirements and semantics:

• Must define spec.template.spec.restartPolicy = Never for spec.podFailurePolicy
• spec.podFailurePolicy.rules are evaluated in order. Once a rule matches a Pod failure, the remaining rules are ignored.
• spec.podFailurePolicy.rules[*].onExitCodes.containerName available for both containers and initContainers
• spec.podFailurePolicy.rules[*].action
  • FailJob
  • Ignore: relevant with spec.backoffLimit
  • Count: relevant with spec.backoffLimit
  • FailIndex: relevant with backoff limit per index

Reference: http://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-failure-policy

Job termination and cleanup

• A Job will be interrupted with a Pod restartPolicy = Never or a Container exits in restartPolicy = OnFailure. Once spec.backoffLimit be satisfied, the entire Job will be marked as failed and any running Pods will be terminated.
• spec.activeDeadlineSeconds be satisfied, all of its running pods are terminated, and the Job status will because type: Failed with reason: DeadlineExceeded.
• spec.activeDeadlineSeconds takes precedence over spec.backoffLimit. Once the Job reaches the time limit (activeDeadlineSeconds), even if the backoffLimit is not yet reached.

Cleanup finished jobs automatically (v1.23 stable)

• TTL mechanism, spec.ttlSecondsAfterFinished for cleaning up finished Jobs (Completed, Failed), including all the cascading Objects, eg: Pods.

Note: If the Job do not be cleaned up, the cluster performance degradation or in worst case cause to go offline due to this degradation. Use LimitRanges and ResourceQuotas is a better way to avoid this.

Reference: http://kubernetes.io/docs/concepts/workloads/controllers/job/#ttl-mechanism-for-finished-jobs

Some examples:

• Specify this field in Job manifest
• Manually set this field of existing, already finished Jobs
• Use a mutating admission webhook to set this field dynamically at Job creation time. Cluster administrators use cases.
• Use a mutation admission webhook to set this field dynamically after the Job has finished, need to detect status of the Job.
• Write your own controller to manage the cleanup TTL for Jobs.

Caveats:

• Updating TTL for finished Jobs: K8s will not make sure the update for TTL with have been expired.
• Time skew: Known that clocks aren’t always correct, K8s Job use the timestamp for doing the clean up.

Job patterns

Usage cases: like emails to be sent, or notification to be pushed, or frames to be rendered, or files to be transcoded, ranges of keys in a NoSQL to scan…

Different patterns for parallel computation, each with strengths and weaknesses. The tradeoffs are:

• A single job for all work items is better for large numbers of items.
• Having each Pod process multiple work items is better for large numbers of items.
• Several approaches use a work queue.
• The job is associated with a headless Service.

Reference: http://kubernetes.io/docs/concepts/workloads/controllers/job/#job-patterns

Advanced Usage

• Suspending a job: spec.suspend = true (v1.24 stable)
• Mutable Scheduling Directives (v1.27 stable)
• Specifying your own Pod selector: spec.selector
• Job tracking with finalizers: batch.kubernetes.io/job-tracking (v1.26 stable)
• Elastic Indexed Jobs (v1.27 beta)
  • When feature gate ElasticIndexedJob disabled, spec.completions immutable
  • spec.parallelism
  • spec.completions
• Delayed creation of replacement pods (v1.29 beta)
  • Feature gate JobPodReplacementPolicy enabled by default
  • Use status.phase = Failed for delaying Pods creation of replacement, set spec.podReplacementPolicy = Failed
  • Without podFailurePolicy set, podReplacementPolicy selects the TerminatingOrFailed replacement policy: the control plane creates replacement Pods immediately upon Pod deletion (as soon as the control plane sees that a Pod for this Job has deletionTimestamp set).

Alternatives

• Bare Pods
• Replication Controller
• Single Job starts controller Pod

Job usage conclusion (personally)

用户需要自己处理一些如 lock，重试，标记，验证等业务逻辑，来安全的使用 Job，JobController 并不会减轻开发工作量，因为 JobController 中的 Pod 会因为很多原因重启或失败，比如 Node eviction，比如 livenessProbe。

JobController 的优势，在于可以可控制的扩缩并行任务数量

典型应用

1. 每个节点上运行的集群守护进程
2. 每个节点上运行的日志收集进程
3. 每个节点的监控守护进程，如 prometheus

即为每种类型的守护进程在所有节点上都启动一个 DaemonSet。或者为同一种守护进程部署多个 DaemonSet，每个具有不同的标识来区分不同类型资源的守护进程

如何调度 DaemonSet 控制的 Pods

通过spec.affinity.nodeAffinity来匹配目标 node，有以下 2 种

1. requiredDuringSchedulingIgnoredDuringExecution 强制要求必须满足条件
2. preferredDuringSchedulingIgnoredDuringExecution 提供一种优先选择的条件，如果不满足也可以被调度到对应的节点

Taints and tolerations Effect 说明

1. NoExecute
2. NoSchedule

Daemon Pod 通信

与 DaemonSet 中 Pod 通信模式：

1. Push
2. NodeIP 和已知端口，如 hostPort
3. DNS
4. Service

更新 DaemonSet

如果节点的标签被修改，DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不匹配的节点上运行的 Pod。可以修改 DaemonSet 创建的 Pod，但不是 Pod 所有的字段都可以修改，如果没有修改，当下次有新节点加入集群的时候，该节点的 Pod 会使用 DaemonSet 初始化时用的模版。

替代方案

1. init 脚本，也就是 linux 系统守护进程
2. bare Pod，直接创建 Pod，这样就会失去高可用特性
3. static Pod，通过在一个指定的、受 kubelet 监视的目录下编写文件来创建 Pod，将来可能会被废弃
4. Deployment，这是最常用的方式

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

port: 入站端口，targetPort：要访问的目标端口

EndpointSlice

• 会通过以 label (kubernetes.io/service-name: my-service) 的形式，将目标端点链接到 Service
• 如果包含至少 100 个端点，则创建新的 EndpointSlice，以相同的方式链接到对应的 Service
• 如果使用的是 Endpoints，会截断 1000 个以上的端点，并设置 annotations endpoints.kubernetes.io/over-capacity: truncated

应用协议

• SCTP
• TCP
• UDP

服务类型

• ClusterIP (default): available in cluster
• NodePort: available out of cluster, ClusterIP mode + Virtual IP mapping
• LoadBalancer: cloud provider
• ExternalName: for cluster used a dynamic external resource by ip or domain

type: ClusterIP

spec.clusterIP = None，Headless Service，也可以通过此字段指定自己的 IP

避免地址冲突：1. IP 地址分配追踪；2. Service 虚拟 IP 地址段，尽管如此，自己指定如果网段与 k8s 集群 IP 相同， clusterIP 仍有冲突风险，否则可避免此类风险

type: NodePort

• --service-node-port-range 可指定端口分配范围，默认值：30000-32767
• nodePort 默认从高位开始分配，用户可从低位指定端口

type: LoadBalancer

type: ExternalName

Headless Service

clusterIP = None, port 比如与 targetPort 匹配

服务发现

• 环境变量：${SVCNAME}_SERVICE_HOST:${SVCNAME}_SERVICE_PORT
• DNS
  • my-service.default.svc.cluster.local
  • _http._tcp.my-service.default.svc.cluster.local，具有 http 端口，协议为 TCP

虚拟 IP 寻址机制

• 流量策略

  spec.externalTrafficPolicy 控制 kubernetes 如何降流量路由到健康（“Ready”）的后端

Session affinity

• spec.sessionAffinity 可以使一个特定的 client 每次都能连接到同一个 Pod
• spec.sessionAffinityConfig.clientIP.timeoutSeconds (default 10800, 3 hours), 来设置 client 连接到同一个 Pod 的最大会话时间

外部 IP

spec.externalIPs 可以指定外部 IP 列表

Ingress

ingress-nginx 实现了 nginx 配置文件的动态加载与更新，解决了频繁更新 nginx 配置重载的问题

ingress-nginx-controller (v1.10.0)，需要指定 ingressClassName = nginx

原理

CoreDNS 插件将 svc 对应的名称映射成了 IP，并且将这个 IP 写入到 IPVS 内核模块中，实现 Service 相对稳定的网络标识

ipvsadm -Ln # 查看ip端口转发配置
iptables-save # iptables，ip端口转发配置

# bind-utils
#@10.96.0.10 为 kube-dns的ip
# -t tcp, -u udp
# A 查询域名解析为A的记录
dig -t A my-service.default.svc.cluster.local. @10.96.0.10

# 测试http服务
wget --spider --timeout=1 nginx

Pause 容器

每个 pod 都会有一个 pause 容器，完成对 pod 内容器的一些资源共享，主要有 2 个功能：

1. 初始化网络栈
2. 共享存储卷

initC (初始化容器)

initC 与 mainC 使用的字段一样，但是 initC 没有 lifecycle，readinessProbe, livenessProbe, startupProbe 每个 Pod 的 initC 可以是 0 个，理论上也可以是无数个, initC 是依次顺序完成初始化的，我们可以利用 initC 将一些任务分步实现，如:

1. initC1 可以执行 git clone
2. initC2 可以安装一些与 mainC 无关的软件，包括一些编译软件
3. initC3 可以完成对软件的构建，比如前端 webpack，后端可执行文件的编译
4. initC4 可以完成一些 delay 或 until 的前置条件，因为 mainC 要想启动，必须要等 initC 完成
5. initC5 可以运行在一个不同于 mainC 的文件系统视图，因此完成对 Secrets 的访问
6. initC6 可以安全地运行一些工具，来一定程度上提高 mainC 运行的安全性
7. … 等等

mainC (主容器)

每个 pod 必须至少有一个容器，否则 pod 无法存活，理论上来说每个 pod 的容器数量也可以是无数个，且所有的 mainC 都是同时执行的，mainC 中，有 hook，也有探针

• hook: exec,httpGet,tcpSocket

  • lifecycle.postHook
  • lifecycle.preStop

• 探针 probe

  • startupProbe: 启动探针
  • livenessProbe：存活探针
  • readinessProbe：就绪探针

Sidecar Container

不同于普通的 initC 按序启动，Sidecar Container 是活跃在整个 pod 的生命周期中的，也就是从 pause 容器完成初始化，一直到 pod 死亡，通过设置 restartPolicy=Always，可在 initContainers 添加一个 Sidecar Container，支持 *Probe 检测，支持 lifecycle.*，并共享容器的 CPU，Memory，网路与存储等资源，但是并不会影响 mainC，还有一点，就是因为 Sidecar 也属于 initC,所以 mainC 要想启动，同样要等 Sidecar 正常运行才行

• 日志采集
• 监控
• 数据同步

Ephemeral Container

主要用与调试容器，字段同 Container，不允许使用，ports,lifecycle,*Probe,resources，除此以外可以执行任意命令

Quality of Service Class

被用于 pod 的 evict 中，当一个 node 资源过载的时候，根据下面的顺序，依次 evict

• BestEffort: 优先被 evict，默认的 QoS
• Burstable: 仅次于 BestEffort
• Guaranteed: 最不容易被 evict

Downward API

用于将 pod 的一些 metadata.*，通过 volume 的方式映射到容器内部

Disruptions

非自愿干扰（Involuntary Disruptions）

1. 节点物理机的硬件故障
2. 集群管理员错误地删除实例
3. 云提供商或虚拟机管理程序中的故障导致虚拟机消失
4. 内核错误
5. 节点由于集群网络隔离从集群中消失
6. 由于节点资源不足导致 Pod 被驱逐

自愿干扰（Voluntary Disruptions）

1. 删除 Deployment 等控制器
2. 更新 Deployment 等控制器模版导致 Pod 重启
3. 直接删除 Pod
4. 排空(drain)节点进行修复或升级操作
5. 从集群中 drain 节点以缩小集群
6. 从节点中移除一个 Pod，以允许其他 Pod 使用该节点

可以创建PodDisruptionBudgets来一定程度上缓解自愿干扰，但是不能够保证，调度器只是尽力去做。

处理干扰 [TBD]

干扰预算 (PodDisruptionBudgets) [TBD]

干扰状况 [TBD]

Pod 开销

Pod 中的资源申请是包含容器运行时的开销的，关于容器运行时的开销，管理员可以在准入控制部分预先设置，也可以由具体的 Pod 指定。

还可以通过spec.overhead由 Pod 自己定义，这个字段的优先级更高。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: runc # 此处是部署kubernetes集群时设置的容器运行时
overhead:
  podFixed:
    memory: "120Mi"
    cpu: "250m"
---
apiVersion: v1
kind: Pod
...
spec:
  runtimeClassName: kata-fc # 如果不设置的话，集群会根据不同的容器运行时，设置相应的
  containers:
  - resources:
      limits:
        cpu: 500m
        memory: 100Mi
    ...
  - resources:
      limits:
        cpu: 1500m
        memory: 100Mi
    ...

如果.spec.runtimeClassName指定了上述定义的 kata-fc RuntimeClass，则 Pod 总的资源申请会包含上述overhead(因为容器运行时在内的一部分开销)，如下所示：

  Namespace    Name       CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
  ---------    ----       ------------  ----------   ---------------  -------------  ---
  default      test-pod   2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m

192.168.104.100 k8s-master01 m1
192.168.104.101 k8s-node01 n1
192.168.104.102 k8s-node02 n2

禁用网卡

# 永久禁用
nmcli device set enp0s2 managed no
# 永久启用
nmcli device set enp0s2 managed yes
nmcli connection modify enp0s2 connection.autoconnect yes

# 设置主机名以及hosts文件的相互解析
hostnamectl set-hostname k8s-master01

yum install -y conntrack ipvsadm ipset iptables curl sysstat libseccomp wget vim net-tools git

# 打开 /etc/chrony.conf
# 将当前的server区域都注视掉
pool ntp1.aliyun.com iburst
pool ntp2.aliyun.com iburst
pool ntp3.aliyun.com iburst
allow 192.168.104.0/24
local stratum 10

systemctl restart chronyd
systemctl enable chronyd

timedatectl set-timezone Asia/Shanghai
#将当前的 UTC 时间写入硬件时钟
timedatectl set-local-rtc 0
systemctl restart rsyslog
systemctl restart crond

# 设置防火墙为Iptables并设置空规则
systemctl stop firewalld && systemctl disable firewalld
yum install -y iptables-services && systemctl start iptables && systemctl enable iptables && iptables -F && service iptables save

# double check
systemctl status iptables
iptables -L # empty
cat /etc/sysconfig/iptables # empty

# 关闭SELINUX
swapoff -a && sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

# 调整内核参数，对于k8s
cat << EOF > /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
user.max_user_namespaces=28633
EOF
sysctl -p /etc/sysctl.d/99-kubernetes-cri.conf

# centos 9 没有postfix服务，有没有其他的邮件服务
# 关闭系统不需要的服务，如邮件服务 postfix，比较占资源
# systemctl stop postfix && systemctl disable postfix


# 日志服务配置
mkdir /var/log/journal # 持久化保存日志的目录
mkdir /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/99-prophet.conf <<EOF
[journal]
# 持久化保存到磁盘
Storage=persistent

# 压缩历史日志
Compress=yes

SyncIntervalSec=5m
RateLimitInterval=30s
RateLimitBurst=1000

# 最大占用空间
SystemMaxUse=10G

# 单日志文件最大 200M
SystemMaxFileSize=200M

# 日志保存时间 2 周
MaxRetentionSec=2week

# 不将日志发送到 syslog
ForwardToSyslog=no
EOF
systemctl restart systemd-journald