Kubernetes v1.36 Memory QoS：以 cgroup v2 memory.min/low 實現分層記憶體保護
Kubernetes Blog (Qi Wang, Sohan Kunkerkar / Red Hat) · 2026-04-29
Kubernetes v1.36 在 MemoryQoS 功能上引入 TieredReservation 策略，透過 cgroup v2 的 memory.min 與 memory.low 為不同 QoS class 的 Pod 提供差異化記憶體保護。功能狀態：Alpha（功能閘道 MemoryQoS，需 cgroup v2）。
cgroup v2 記憶體介面對應
| 介面 | 語義 | v1.36 變更 |
|---|---|---|
| memory.max | 硬性上限（OOM 觸發） | 不變 |
| memory.min | 核心絕不回收此記憶體 | 新增：僅 Guaranteed Pod 啟用 |
| memory.low | 核心盡量避免回收 | 新增：僅 Burstable Pod 啟用 |
| memory.high | 節流閾值 | 不變（由 throttlingFactor 控制） |
memoryReservationPolicy 選項
- None（預設）：不寫入
memory.min/memory.low，僅保留memory.high節流 - TieredReservation：依 QoS class 套用分層保護
QoS class 對應
| QoS Class | memory.min | memory.low |
|---|---|---|
| Guaranteed | = requests.memory（硬保護） | 不設定 |
| Burstable | 不設定 | = requests.memory（軟保護） |
| BestEffort | 不設定 | 不設定 |
memory.min 語義：核心在任何情況下都不回收此記憶體；若無法履行保護，觸發 OOM killer 殺掉其他 process。memory.low 語義：核心通常避免回收，但在系統層級 OOM 威脅時可能回收，屬於軟保護。
cgroup 階層約束
cgroup v2 要求父 cgroup 的 memory.min ≥ 子 cgroup 的 memory.min 總和。kubelet 在 kubepods 根 cgroup 設置 memory.min = 所有 Guaranteed + Burstable Pod requests 總和，在 Burstable QoS cgroup 設置 memory.low = 所有 Burstable Pod requests 總和。
可觀測性指標（Alpha）
# kubelet /metrics 端點
kubelet_memory_qos_node_memory_min_bytes # Guaranteed Pod 的 memory.min 總量
kubelet_memory_qos_node_memory_low_bytes # Burstable Pod 的 memory.low 總量核心版本需求
核心 < 5.9 存在 memory.high 節流的 livelock bug。v1.36 在啟動時檢查核心版本並記錄警告，但不阻止功能啟用。
原始來源：Kubernetes Blog — Kubernetes v1.36: Tiered Memory Protection with Memory QoS
CNCF 專案 AI 使用現況：133 人調查揭示採用率高、治理政策缺失的落差
CNCF TAG Developer Experience · 2026-04-29
CNCF TAG Developer Experience 對近 100 個雲端原生專案的 133 位貢獻者進行調查，記錄 AI 工具在開源基礎設施開發中的實際使用狀況。
主要發現
- 近半數受訪者在 IDE 或 CLI 中直接使用 AI 助理，Claude Code 與 GitHub Copilot 為最主流工具，僅約 10% 仍使用基本聊天機器人
- AI 最有價值的應用：程式碼撰寫與重構、文件改善、除錯、理解陌生程式碼庫、PR 分析
- 約三分之二的受訪者表示不知道是否存在 AI 使用指引，或確認沒有正式政策；大多數專案沒有公開記錄 AI 使用規範
- 約三分之一允許自由使用 AI，不到 4% 明確禁止
- 維護者主要對 AI 生成程式碼套用標準審查流程，而非特殊過濾
- 超過半數認為 AI 輔助貢獻應始終要求正式揭露
主要疑慮
受訪者的主要疑慮集中在安全漏洞、授權合規（AI 訓練資料的著作權不確定性）以及低品質的批量提交。
這份調查呈現了一個典型的技術採用超前治理的情況：工具已普及，但圍繞這些工具的流程、政策與問責機制仍在追趕中。
Fedora Linux 44：GNOME 50、Plasma 6.6、GCC 16.1 預釋版與 Sealed Atomic Desktop
Fedora Magazine · 2026-04-28
Fedora Linux 44 於 2026 年 4 月 28 日正式發布，帶來多項桌面、工具鏈與容器化系統的重要更新。
GNOME 50
Workstation 版本搭載 GNOME 50，改進項目涵蓋無障礙功能、色彩管理、遠端桌面能力，以及 Document Viewer、File Manager、Calendar 應用程式的增強。新增原生家長控制功能，可透過設定介面設定螢幕時間限制與就寢時間排程。
KDE Plasma 6.6
KDE 版本搭載 Plasma 6.6，引入全新的 Plasma Login Manager 與 Plasma Setup 工具，建立「從首次開機起更具凝聚力的整合體驗」，簡化系統初始化流程。
GCC 16.1（預釋版）
此版本包含 GCC 16.1 預釋版，是 Fedora 慣例提供工具鏈早期測試機會的延續——讓開發者在官方發布前發現並回報問題。
Sealed Atomic Desktop
新增 Sealed Fedora Atomic Desktop 可啟動容器映像（bootable container images），Silverblue 使用者可透過 rebase 命令升級至 Fedora 44：
rpm-ostree rebase ostree-image-signed:docker://quay.io/fedora/fedora-silverblue:44其他版本
Fedora Asahi Remix 44 同步發布，提供 Apple Silicon Mac 支援。完整的版本間變更清單記錄於官方 Release Notes，涵蓋桌面使用者、開發者與系統管理員。
原始來源：Fedora Magazine — The Fedora Linux 44 Release is Here!、What's New in Fedora Workstation 44
HashiCorp Vault SSH Secrets Engine：憑證式短命 SSH 存取與 Boundary 即時注入
HashiCorp Blog · 2026-04-29
HashiCorp 更新了大規模 SSH 存取管理的架構指引，以 Vault SSH Secrets Engine 作為 SSH CA，搭配 Boundary 提供即時憑證注入。
憑證生成流程
- 使用者透過身分提供者（IdP）向 Vault 驗證
- 提交 SSH 公鑰供 Vault 簽章
- Vault 回傳限時憑證（預設有效期 30 分鐘）
- 使用者以簽章憑證連線目標主機
- 主機驗證憑證是否由受信任的 CA 公鑰簽署
存取控制
Vault 策略決定角色授權：管理員（administrator role）可簽章自身金鑰，但被拒絕使用其他團隊的角色。AuthorizedPrincipalsFile 機制提供 principal-to-user 映射，確保憑證僅對每台主機上的授權 Linux 帳號有效。
安全特性
- 短命憑證（30 分鐘）自動到期，無需手動撤銷
- Vault CA 私鑰不分發至主機——主機只需 CA 公鑰
- 所有簽章請求產生完整稽核軌跡
- 支援 dev/test/production 跨環境隔離 CA
Boundary 整合
搭配 HashiCorp Boundary 的即時憑證注入（just-in-time credential injection）允許無密碼 SSH 存取：Boundary 在需要時自動向 Vault 請求憑證，消除使用者手動複製 token 的流程。
原始來源：HashiCorp Blog — Managing SSH access at scale with HashiCorp Vault