Kubernetes v1.36：暫停 Job 的 Pod 資源可變性晉升 Beta，佇列控制器可動態調整 GPU 配額
Kubernetes Blog · 2026-04-27
Kubernetes v1.36 將「暫停 Job 的可變 Pod 資源」（Mutable Pod Resources for Suspended Jobs）特性由 Alpha（v1.35 引入）晉升為 Beta，並在 v1.36 中透過 Feature Gate MutablePodResourcesForSuspendedJobs 預設啟用。
解決的問題
批次運算與機器學習訓練任務（Job）的資源需求往往在提交時難以確定。過去，Pod template 的資源規格（resources.requests/resources.limits）一旦設定即不可變更——若佇列控制器（如 Kueue）發現可用 GPU 少於申請數量，唯一選項是刪除並重建 Job，損失所有歷史狀態、標注與事件記錄。
API 變更
此特性不引入新 API 型別，僅放寬了現有 Job 與 Pod template 的驗證規則。可變更欄位：
spec.template.spec.containers[*].resources.requestsspec.template.spec.containers[*].resources.limitsspec.template.spec.initContainers[*].resources.requestsspec.template.spec.initContainers[*].resources.limits
變更條件：spec.suspend: true 且 status.active == 0（所有 Pod 已終止）。標準資源驗證（limits ≥ requests、擴充資源為整數等）依然適用。DRA 的 resourceClaimTemplates 仍為不可變。
佇列控制器工作流範例
訓練 Job 初始申請 4 個 GPU，Kueue 發現僅有 2 個可用時：
- 確保
spec.suspend: true且待所有 Pod 終止 - 以
kubectl patch或 server-side apply 更新resources.requests.example-hardware-vendor.com/gpu: "2" - 設置
spec.suspend: false讓 Job 以新資源規格繼續執行
為確保 Pod 在修改前完全終止，建議搭配 podReplacementPolicy: Failed，使替換 Pod 僅在前一個 Pod 完全終止後才創建。
原始來源：Kubernetes Blog — Mutable Pod Resources for Suspended Jobs
GitHub 用 eBPF 阻斷部署時的循環依賴：cgroup 網路過濾與 DNS 代理架構
GitHub Engineering Blog · 2026-04-16
GitHub 工程部落格揭示了使用 eBPF 解決「部署需要 GitHub，但 GitHub 故障時無法部署修復」這個循環依賴問題的技術架構。
問題分類
循環依賴分為三類：(1) 直接依賴——部署腳本在執行期間從 github.com 拉取資源；(2) 隱藏依賴——工具在更新檢查時悄悄呼叫 GitHub；(3) 傳遞依賴——內部服務間接透過 API 呼叫到 GitHub。第三類最難追蹤，因為它不在部署腳本本身，而是在被呼叫的內部服務鏈中。
eBPF 架構
系統使用兩種 eBPF 程式型別搭配作業：
BPF_PROG_TYPE_CGROUP_SKB（網路出口過濾）：在 cgroup 層面監控並阻擋目標為受限網域的外出封包；提取 DNS 交易 ID 並對應到發起行程。
BPF_PROG_TYPE_CGROUP_SOCK_ADDR（連線攔截）：在 socket 建立 syscall 前攔截；將 DNS 查詢（port 53）重新導向至 userspace DNS 代理；允許選擇性封鎖網域而不影響全局網路。
隔離機制
部署腳本被放入專屬的 Linux cgroup，eBPF 程式僅對該 cgroup 內的行程生效。使用 cilium/ebpf Go 函式庫載入與管理核心程式。userspace DNS 代理透過 eBPF Maps 與核心端通訊，評估網域黑名單並記錄完整稽核日誌（PID、/proc/{PID}/cmdline、被封鎖的網域與時間戳）。
成效
六個月上線後，系統可在部署腳本嘗試呼叫受限連線時主動偵測並通知，包含「哪條命令觸發了被封鎖的請求」——改變了過去只在實際故障時才發現循環依賴的模式。
原始來源：GitHub Engineering Blog — How GitHub uses eBPF to improve deployment safety
pip 26.1：dependency cooldown 機制、pylock.toml 實驗支援、移除 Python 3.9
pip 發布說明 · 2026-04-27
pip 26.1 於 2026 年 4 月 27 日發布，帶來供應鏈安全導向的 dependency cooldown 機制、標準化的 pylock.toml 鎖定檔實驗支援，並終止 Python 3.9 支援。
Dependency Cooldown
Dependency cooldown 是一種供應鏈攻擊緩解策略：在安裝套件時，若某個套件的最近一次發布時間距今不超過指定的 cooldown 期間，則發出警告或拒絕安裝。其理論依據是許多 npm/PyPI 供應鏈攻擊（如投毒攻擊）會在短時間內發布惡意版本——設置 cooldown 期間（如 3 天）可使自動化依賴更新流程在惡意版本廣泛傳播前有更多時間被偵測。--uploaded-prior-to 標誌現在接受 ISO 8601 duration 格式（如 P3D），允許指定「僅接受 N 天前發布的套件」。
pylock.toml 實驗支援
pip 26.1 實驗性地支援以 -r pylock.toml 讀取 PEP 751 定義的標準化鎖定檔格式 pylock.toml。PEP 751 定義了跨工具互通的鎖定檔結構（類似 Cargo.lock / poetry.lock 的標準化版本），旨在終結 requirements.txt/pip freeze、Poetry、PDM 等工具間鎖定檔格式不相容的問題。
解析器改進
複雜衝突場景的依賴解析速度提升；大型依賴樹的記憶體消耗降低；允許未釘版（unpinned）的要求項目使用來自 constraints 的雜湊值，擴大了雜湊驗證的適用範圍。
Breaking Change
終止 Python 3.9 支援（2025-10 已 EOL）。
Ubuntu 26.04 LTS 'Resolute Raccoon'：TPM 加密預設啟用、記憶體安全元件擴展
LWN.net / Canonical · 2026-04-23
Ubuntu 26.04 LTS（代號 Resolute Raccoon）於 2026 年 4 月 23 日正式發布，為五年長期支援版本，支援至 2031 年 4 月。本版的技術重心是 TPM 支援的全磁碟加密成為預設安裝選項，以及記憶體安全語言元件的系統性擴展。
TPM 加密
Ubuntu 26.04 將 TPM 2.0 支援的全磁碟加密（FDE）整合進安裝程式預設流程。與傳統 LUKS 密碼解鎖不同，TPM 加密將磁碟解密金鑰封存（sealed）於 TPM 的 PCR（Platform Configuration Registers）中——只有當開機環境（韌體、開機載入器、核心）的測量值與封存時一致時，TPM 才會釋放金鑰。這防止了硬碟被取出後在另一台機器上解密，或在開機載入器遭到竄改後仍能解鎖的攻擊向量。Ubuntu 的實作基於 secboot 函式庫，並透過 Snap 的 pc-gadget 管理 PCR 政策更新。
記憶體安全元件擴展
延續 Ubuntu 24.04 LTS 開始的記憶體安全語言採用路線，26.04 在以下系統元件中增加了 Rust 實作：netfilter 輔助工具部分路徑、systemd 的若干服務管理模組，以及 cups（列印系統）的 IPP 協定解析層。這些元件過去因 C 記憶體管理缺陷曾有 CVE 歷史，遷移目的是降低此類漏洞面。
核心版本
搭載 Linux 7.0 核心（Ubuntu 維護版本），包含 io_uring 效能改進、BPF 子系統更新，以及對 ARM64 SoC 的廣泛驅動支援。