Kubernetes v1.36.3：修復 kubelet 記憶體洩漏與 DRA 排程計數錯誤
Kubernetes GitHub Releases · 2026-07-23
Kubernetes 專案於 2026-07-23 發布 v1.36.3，是 v1.36 分支自 v1.36.2 以來的例行修補版本。這次更新收錄六項臭蟲修復、一項失敗測試修正與一項建置變更，重點修正 kubelet 記憶體洩漏、DRA（Dynamic Resource Allocation）結構化配置器的計數錯誤，以及 server-side apply 的 422 迴歸問題。所有異動內容已同步寫入 CHANGELOG-1.36.md，並釋出對應版本的容器映像。
背景
值得注意的是，本次修復的多數問題並非陳年舊疾，而是 v1.36.0 自身引入的迴歸（regression）。v1.36 分支在推出新功能的同時，也在 kubelet、DRA 排程器與 API 機器層留下了非預期副作用，這讓 v1.36.3 更像是一次「補完」而非單純的例行維護。kubelet 的 context 洩漏與 server-side apply 的 422 錯誤，都只出現在 1.36 系列，1.35 及更早版本不受影響。一次 patch release 集中修掉三項同源迴歸，說明 1.36 主線這次的變更幅度確實較大。
核心改動
本次 Bug or Regression類別的修復涵蓋排程、節點與叢集生命週期三個層面，以下是主要項目：
- 修復 kubelet 因每次 Pod 同步都洩漏 context 所導致的記憶體洩漏（
#140066），此問題自 1.36 起出現。 - 修復 DRA 結構化配置器（structured allocator）在探索候選節點時計數錯誤：配置器可能在拒絕或回溯候選項後仍保留計數器，或遺失共享裝置的使用中標記導致重複扣款，最終讓本可排入的 Pod 被誤判為無資源可用（
#140663）。 - 修復 1.36 的 server-side apply 迴歸：修補 list 或 map 型別容器欄位時，原本應成功的 apply 請求會回傳
422 required錯誤（#140296）。 cri-api還原至 1.34 之前對KeyValuevalue 欄位的 JSON 編碼方式（#139965）。- 修復啟用
DRADeviceTaintRules特性時，DeviceTaintRules 存在且 ResourceSlices 變動會導致 kube-scheduler panic 或忽略新變更的問題（#139681）。 - kubeadm 三項修復：改善 etcd learner promotion 的容錯處理（
#139910）、join 階段抓取 kubeadm-config ConfigMap 改用完整逾時而非 350ms 短重試（#139808）、MemberPromote 在成員已是投票成員時跳過多餘的 etcd promote 呼叫（#138493）。 - kubelet 不再對缺少的可選容器註記輸出
V(4)等級的「Label not found」日誌（#140322）。
此外，Kubernetes 本身改用 Go 1.26.5 建置（#140581），依賴項目 sigs.k8s.io/structured-merge-diff/v6 也由 v6.3.2 升至 v6.3.3。
影響範圍
使用 DRA 且啟用 DRADeviceTaintRules 或依賴結構化配置器共享計數裝置的叢集，應優先升級以避免 Pod 被誤判為不可排程。長時間運行且觀察到 kubelet 記憶體持續成長的叢集，這版能直接緩解 context 洩漏問題。若叢集大量使用 server-side apply 修補 list/map 欄位，或用 kubeadm 管理 etcd learner 升級，同樣建議儘快升版；其餘變更多屬日誌雜訊與內部相依項目更新，對日常操作影響有限。
OpenTelemetry Go 編譯期插樁推出 v1：換一行建置指令拿到免改碼追蹤
OpenTelemetry Blog · 2026-07-16
OpenTelemetry 社群於 2026-07-16 在官方部落格宣布 OpenTelemetry Go Compile-Time Instrumentation 專案推出首個穩定版 v1.0.0。這個 SIG 由 Alibaba 與 Datadog 於 2025 年初共同發起，目標是為 Go 打造一套廠商中立的編譯期插樁方案。v1 代表這個專案第一次對外承諾穩定的行為與介面，而不再只是實驗性原型。
背景
Java、Python、Node.js、.NET 都能在應用程式啟動時掛上 agent、動態插入 OpenTelemetry 邏輯，但 Go 編譯成單一靜態執行檔，啟動後沒有可掛載的執行環境，長期只能靠手動插樁或跳出行程外部的 eBPF agent。這個專案改掛入 Go 標準工具鏈的 -toolexec 機制：在編譯應用程式碼、其依賴套件與標準函式庫的當下，由工具改寫並注入插樁邏輯，再交還給正常編譯流程繼續執行。因為插樁發生在編譯期，執行期不需要額外 agent 或 sidecar，這與需要跳出行程觀測的 eBPF 方案（OpenTelemetry eBPF Instrumentation，簡稱 OBI）是互補而非取代關係。
核心規格
專案提供指令列工具 otelc，包裝標準 Go 工具鏈；使用方式是把原本的 go build 換成 otelc go build，go 之後的參數原樣轉送給工具鏈，容器建置流程套用同樣替換即可。預設情況下 otelc 會自動掃描模組內受支援的函式庫並插樁，不需額外設定或修改程式碼：
# 原本
go build -o app ./cmd/app
# 換成
otelc go build -o app ./cmd/appv1 支援的插樁對象包含：
net/httpdatabase/sql- gRPC
- Redis
- Go runtime metrics
擴充機制採規則式（instrumentation-rule format），要支援新函式庫可依照專案 docs/instrument-guide.md 與 rules.md 定義的格式撰寫規則加入，不需修改工具本體，輸出的追蹤與指標也遵循目前的 OpenTelemetry 語意慣例。
影響範圍
公告將三種取得 Go 遙測的方式定位為互補選項：
| 方式 | 適用情境 | 是否需重新編譯 |
|---|---|---|
編譯期插樁（otelc） | 能重建二進位、要免改碼並涵蓋依賴與標準函式庫 | 需要 |
| eBPF（OBI） | 無法重建二進位、需跨語言的行程外觀測 | 不需要 |
| 手動插樁（Go API） | 自訂 span、業務語意化遙測 | 需要（改程式碼） |
v1 涵蓋的是核心的一小組常用函式庫，尚未觸及 Go 生態系的全部範圍，若依賴的函式庫暫無規則支援，可自行撰寫規則或搭配手動插樁補齊。專案後續會投入 OpenTelemetry Registry 做規則探索與分發、持續壓低建置與執行期成本。
Terraform Stacks 解析：用元件與部署模型取代手工複製的多環境設定
HashiCorp Blog · 2026-07-23
HashiCorp 於 2026-07-23 在官方部落格發布〈Terraform Stacks, explained〉，系統性說明建立在既有模組之上的 Terraform Stacks 抽象層。Stacks 的目標是自動化並最佳化「一組互相依賴的 Terraform 設定」的協調、部署與生命週期管理，鎖定需要跨帳號、跨環境、跨地區維運基礎設施的團隊。此功能目前於 HCP Terraform 與 Terraform Enterprise 2.0+ 提供正式生產環境支援，採用 Resources Under Management（RUM）計價模式。
背景
在 Stacks 出現之前，團隊要把同一套架構部署到多個帳號、環境或地區，通常得靠外部腳本或手動維護多份設定間的依賴關係，Terraform 本身沒有原生機制能「用不同輸入值，把同一份基礎設施重複部署很多次」。Stacks 把設定拆成元件（component）與部署（deployment）兩層：元件描述「要佈署什麼」，部署描述「佈署到哪裡、佈署幾次、用什麼輸入值」。兩者分離之後，同一組元件可以被套用到不同區域或帳號，而不必複製整份程式碼。
規格細節
元件用 .tfcomponent.hcl 定義，每個 component 區塊指向既有模組（source）並帶入 inputs 與 providers，團隊不需要重寫既有的 IaC 模組。部署則用 .tfdeploy.hcl 定義，deployment 區塊帶入該實例特有的輸入值：
component "cluster" {
source = "./eks"
inputs = { ... }
providers = { ... }
}
deployment "west-coast" {
inputs = {
aws_region = "us-west-1"
instance_count = 2
}
}多個部署可歸類進部署群組（deployment group），群組能設定自動核准規則（auto-approve check），例如條件式 condition = context.plan.changes.remove == 0 代表「不含資源刪除的變更自動核准」。另一項機制是延遲變更（deferred changes）：當規劃階段有太多未知值（常見於 Kubernetes 資源），Terraform 可先產生部分計畫，讓團隊選擇性套用，而非整包卡住無法推進。
影響範圍
Stacks 主打三類場景：把網路、儲存、運算等元件當成單一單位部署且自動處理依賴關係；用部署機制在多區域、多帳號重複套用同一組架構而不必複製程式碼；以及跨地區串接 Kubernetes 叢集與命名空間佈建。額外能力包含：
- Linked Stacks：讓拆分基礎元件與應用層的架構之間可以互相依賴。
- CLI 遷移工具：提供引導式流程把既有 workspace 轉為 Stacks，並非自動轉換。
- Self-hosted agents：支援在防火牆內的私有網路執行。
- 私有登錄整合：組織內可共用具版本號的複合式 Stack 設定。
- Terraform actions：佈建以外、由生命週期事件觸發的維運自動化。
- 統一 CLI：
terraform-stacks-cli已併入主線 Terraform CLI。
Custom deployment group 與 Linked Stacks 屬於 Premium／Enterprise 方案功能。HashiCorp 在文中強調 Stacks 並非黑盒：RUM 可視化儀表板會同時列出可計費的 Stack 資源，以及 Stack 與既有 workspace 的合併資源，方便對照計價明細。