矽谷牛的耕田筆記

https://github.com/dotnet/runtime/pull/115762#discussion_r2098573409 非常有趣的一個案例，裡面可以看到 1. 修復問題不會全面修正，講一個修一個 2. 修復問題考量的實作也是比較單純，需要reviewer 提及所有概念才會去實作 3. 底下的留言普遍都是認為這些反覆對話所花費的時間已經幣比自己寫還更花時間了… 繼續看下去😹😹

https://www.uber.com/en-TW/blog/migrating-ubers-compute-platform-to-kubernetes-a-technical-journey/ > Operating large clusters on Kubernetes posed challenges with managing the API server load to prevent bottlenecks, ensuring that the scheduler can handle the scale even with high pod churn, and dealing with fragmentation issues that arise from running large clusters with varied workloads. Large cluster 都必須要處理的 scheduler, high pod churn 還有可怕的 etcd fragmentations… > We had to make some optimizations and tune parameters to achieve these numbers. We tuned the QPS settings and parallelism in the controller manager and scheduler to handle high loads. We used API priority and fairness to limit expensive API calls like list and get. We switched from JSON to Proto encoding for better performance. Lastly, we modified the pod topology spread scheduler plugin for faster processing. APF 看來似乎是一個讓應用程式不要弄壞 cluster 的方向，降低 API 的忙碌，甚至連 Controller/Scheduler 都調整了

https://grafana.com/blog/2025/04/27/grafana-security-update-no-customer-impact-from-github-workflow-vulnerability/ Grafana 最近遇到關於 GitHub Action 中有一些漏洞，導致有人可以獲得一些 secret，不過團隊透過 alert 馬上觀察到這個現象並且趕緊修復

https://kubernetes.io/blog/2025/04/07/introducing-kube-scheduler-simulator/ 如果有想要自行開發 Kubernetes Scheduler 的團隊可以參考看看這個逐漸成熟的工具，透過 KWOK(Kubernetes WithOut Kubelet) 的方式來搭建環境 要特別注意的是，這種模擬的工具終究不能模擬真正的大流量，主軸是 scheduler 的演算法，主要是用來確認 scheduling decision 的抉擇，如果演算法的內容牽扯到大量線上即時狀況的話，那此工具也還是可能沒辦法幫忙模擬。

今日最大的 K8s 消息大概就是 Nginx CVE https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities 簡單來說，這是一個眾多 CVE 的組合 CVE-2025-1097 CVE-2025-1098 CVE-2025-24514 CVE-2025-1974 前述三者都是在鋪成這塊，包涵 CVE-2025-24514 -> nginx.ingress.kubernetes.io/auth-url: "http://example.com/#;\ninjection_point" (這種 annotation 就會被產生一些不合適的 nginx config) CVE-2025-1097 -> nginx.ingress.kubernetes.io/auth-tls-match-cn: xxxx (也是一樣會產生不合適的 nginx config) CVE-2025-1098 -> 從 ingress 物件內的 ing.UID 欄位又可以產生特定的 nginx config. 最後就是 Ngnix 內的 CVE-2025-1974，這塊使得前述 nginx 透過 nginx -t 執行前述 nginx config 測試時順帶執行一些指令，這樣就可以利用 nginx -t 去執行任何指令了

https://dev.to/sklarsa/how-to-add-kubernetes-powered-leader-election-to-your-go-apps-57jh 這主題滿少見的，探討如何用 k8s 內建的 lease 物件來幫你的應用程式撰寫簡易的 election 機制。 如果你是用 kubeadm 安裝的環境且走 HA 架構，內建的 controller/scheduler 裡面其實也是靠這些來完成相關選舉的

https://blog.cloudflare.com/multi-path-tcp-revolutionizing-connectivity-one-path-at-a-time/ Cloudflare 官方部落格撰寫的 MPTCP (Multi Path TCP) 的教學，相較於傳統 TCP 來說, MPTCP 透過不同的路徑同時傳送 TCP 封包，可以提升整體的 throughput 以及更好的可靠性(假如系統上有多張網卡，則可以同時一起傳輸） 文章內有更多的介紹，這篇文章寫得很清楚，雖然目前大部分環境實務上用不到，不過還是可以當作科普的方式來學習一些網路概念

https://thenewstack.io/year-in-review-containers-get-smaller-faster-more-secure/ 本篇文章大抵上整理了這一年容器的發展，其中比較有趣的應該是 networking 的部分。 過往都是採用 veth 的方式來處理所有的 container networking，而 Linux kernel 6.7 後則是正式支援 Netkit 這個基於 eBPF 框架的網路處理方式， 根據文章中的描述，其傳輸效能比傳統 veth 好非常多，更貼近實體機器的效能。 至於 Continaer Image 的打包，文章內提到幾個關鍵字 1. Distroless 2. Chainguard/Google 3. Ko (針對 golang 的容器化工具） 4. Apko 5. BuildPacks, BuildKit and Dagger, and Nix.

Title: OpenAI 服務重大停機事件後檢討 Source: https://status.openai.com/incidents/ctrsv3lwd797 摘要: 2024/12/11 OpenAI 發生了重大問題，15:16~19:38(PST) 中間各種服務都出現使用異常，本篇文章是關於針對該事件進行事後調查與分析的技術文章 OpenAI 的服務都是部署到 Kubernetes 環境中，而這次事件的原因就是因為部署一個 Telemetry 的服務到叢集中，基本上部署一個服務應該是不會有太多的影響，不過官方提到這次的部署，導致的現象是每個節點上的 Telemetry Pod 都會往 API Server 進行大量的互動，所以對 API Server 來說就會收到跟節點數量成正比的大流量。 以過往 OpenAI 的相關文件，其最大的 Cluster 是上千台節點，以這種規模下，整個 API Server 以及背後的 Control Plane 全部都被塞爆，導致其他正常的請求沒有辦法處理。 然而這個炸彈並沒有就此停住， Controller 沒有辦法順利地去更新 DNS/Endpoint 的紀錄，最終會導致所有想要透過 CoreDNS 詢問 DNS 的服務都會問不到，最終導致各種盧物都不能使用。 根據先前的文章，可以知道 OpenAI 有使用 Node Local DNS 來強化 Cache 的效果，所以文章內可以看到問題發生後， 20 分鐘內基本上都還可以使用 local 的 DNS，只是這些 stall 的紀錄都不是最新的，然後一旦等到資料過期後，問題就開始浮現． 所以這種問題從使用者的角度來看，就是會發生 DNS 解析不到，然後要一路追查才會發現是 CoreDNS 拿不到，原來是 Control Plane 出問題，最後才發現原來是 Telemetry Service 造成的。 後續的改進行為中，我覺得最值得注意的就是 "Decouple the Kubernetes data plane and control plane"， 如果有辦法可以讓 DNS 的行為可以從 Control Plane 中脫鉤，某程度來說會解放這一切，不過這中間又牽扯到 K8s service 的問題，只要你的 Pod 都還是動態 IP，沒有辦法自己額外註冊，那就還是要大量仰賴 CoreDNS K8s Plugin 去幫忙處理

https://atbug.com/patent-troll-targets-k8s-dsdn/ 滿有趣的一篇文章，大抵上就是某公司申請了一個 SDN 的架構，其中的分散式架構與 K8s 的設計類似，所以關於 k8s 架構以及 CNI 生態系用法可能會有相關的所屬之爭 然後 CNCF 官方還有一篇徵求各位提供證據的文章 https://www.cncf.io/blog/2024/11/13/announcing-the-inaugural-contest-for-the-cloud-native-heroes-challenge/ If you are aware of any publicly available materials (other than materials already listed in the “known references” tab of the contest information page) demonstrating that know-how regarding the invention described above already existed prior to June 13, 2013 (the priority date of the patent), please submit that evidence as “prior art” in this contest. 尋找 2013/06/13 以前的相關文件證明這些東西早於專利... 做夢都沒有想到，原來分散式架構可以被申請成專利並且被拿來這樣搞？？？

Title: Istio Ambient 正式版發佈 Source: https://www.cncf.io/blog/2024/11/07/fast-secure-and-simple-istios-ambient-mode-reaches-general-availability-in-v1-24/ 內容摘要 Istio 1.24 的 Ambient 模式在沒有 sidecar 的情況下實現了更高效率和以及架構簡化的流量控制，這對網格架構管理帶來重大改進。透過降低資源需求，Ambient 模式讓使用者能更靈活地部署並確保安全性和效能。 此模式的推出無疑提升了 Istio 在 Cloud Native 環境中的價值，是對雲端原生基礎設施的一次有力創新。

Title: Karpenter：改變我們 Kubernetes 的維運方式 Source: https://medium.com/adevinta-tech-blog/the-karpenter-effect-redefining-our-kubernetes-operations-80c7ba90a599 摘要: 這篇文章分享了 Adevinta 團隊在採用 AWS Karpenter 後，如何通過動態配置計算資源來改進 Kubernetes 的維運經驗。文章詳細探討了 Karpenter 如何通過自動調整資源分配，應對各種 Kubernetes 內的管理複雜度，同時提升系統靈活性和成本效益。 vinta 發現使用 Karpenter 後，資源配置時間減少了 75%，維運成本降低了 50%。 Karpenter 的動態資源調整功能，使得叢集在高峰期能夠靈活應對流量變化，平均提升了 30% 的資源利用率。文章還列舉了具體的應用場景，展示了 Karpenter 如何在實際操作中發揮作用，並強調了其對於大型 Kubernetes 環境的重要性。

Title: Plane 管理 100,000+ Docker 和 44,000 Kubernetes 部署的經驗談 Source: https://plane.so/blog/streamlining-self-hosting-managing-100k-docker-44000-kubernetes-deploys-ease Summary: 這篇文章分享了一家初創公司如何通過一系列實驗、失敗和教訓，成功地擴展 Docker 和 Kubernetes，以提供 Self-Hosted 服務的流程。 文章詳細描述了解決問題的四個階段的辛酸血淚， 此外，還介紹了一鍵安裝、Go Binary 和自己的CLI 等相關工具的開發是如何讓客戶能夠更有信心且穩定的維護 Self-Hosted 環境。文章強調，儘管使用 Self-Hosted 的使用者數量遠少於雲端服務的使用者，但這些技術措施使得初創公司能夠有效地管理超過 50,000 個活躍的 Self-Hosted 客戶。

Title: Google 如何改善 Kubernetes Pod 啟動時 CPU 的使用問題 Source: https://github.com/google/kube-startup-cpu-boost 主要觀點： - 部分應用程式可能因為框架或是程式語言的架構，導致 startup 時期需要更多的 CPU 來暖身 - 這導致應用程式很難去設定一個合理的 CPU 資源用量，給太多又浪費，給太少又會導致開機過慢 - Google 開發的這個控制器會嘗試啟動時期增加 CPU 資源用量，之後又會降到本來的階段，避免資源浪費 關鍵功能： - 仰賴 k8s 後期推出的 in-place resource resize 功能來達到動態增加 - 透過 mutating admission webhook 來動態修改 YAML 結論 - k8s 1.27 的動態調整 CPU 用量實務上可以解決很多問題，不過要一直修改各種 YAML 來描述資源，因此透過這些 webhook 來達到動態修改似乎是個趨勢？

Title: Istio DNS Proxy 提升 DNS 效能的能力 Source: https://medium.com/@espinaladrinaldi/how-istio-dns-proxy-improve-dns-performance-capabilities-to-resolve-dns-inter-mesh-cluster-or-546e03a44610 主要觀點： - 討論 Istio DNS Proxy 的工作原理，以及如何透過此工具改善 DNS 的效能 - 提供了實際上可以怎麼使用這個功能改善應用程式的 DNS 以及 Kubernetes 的 DNS 存取問題 關鍵功能： - 改善 DNS 查詢速度 - 提高 DNS 解析的可靠性 結論： - Istio DNS Proxy 提供類似 Cache 的功能來改善整個 DNS 的存取問題，同時透過 istio 的架構可以達到無侵入式的修改，讓 app 無感。

Kubecon China 2024 回顧 https://moelove.info/2024/09/03/Kubecon-China-2024-Recap/ KubeCon China 最近剛結束，本篇文章記錄與會人員這幾天會議中的經驗分享 1. Linus 本人認為 AI 的流行使得 NVIDIA 對於 Linux Kernel 內的開發與貢獻更加活躍 2. Istio 的發展，其中 Sidecar mode 與 Ambient mode 的對比很類似過往 VM & Container 的比較，都是資源耗損浪費為痛點出發去改變，Ambient Mode 減少資源浪費但時也會增加爆炸半徑，這與所有 Contianer 都共享主機 Kernel 是一樣的概念 3. Kubernetes Ingress NGINX 的發展，將逐漸轉往 Gateway API 的實作，並且移除各種內建 annoation 的用法，未來都將透過 Gateway API 來描述與操作

CRI-O 1.31 新功能介紹 https://www.cncf.io/blog/2024/09/12/whats-new-in-cri-o-1-31/ 隨者 Kubernetes 1.31 的發佈，其底下的 CRI-O 也正式推出 1.31 版本，而 1.31 有幾個重大改動 1. 底層 container 的實作從 runc 改成 crun， crun 相對於 runc 有更好的效能與資源使用效率，同時對於 contianer 啟動的速度也更快。 2. 支援 cosign 來搭配 Kuberneres namespace 達到更細部的簽章認證 3. 各種bug修復以及相關小功能的改變

K8s API Server 是如何與 Pod 處理相關的身份驗證 https://learnk8s.io/authentication-kubernetes 本篇文章非常詳細介紹 K8s API Server 是如何處理身份驗證的問題，這個領域包含兩個部分 1. Kubernetes 內部使用者 2. Kubernetes 外部使用者 (1) 的部分就是常見的 Service Account，文章中以 1.24 為分水嶺，分別介紹 a. 1.24 以前是如何透過 secret 的方式來提供 service account 的存取方式 b. 1.24 以後為了解決 secret 不會過期的問題(不夠安全) 而採取 volume projected 的方式來處理 (2) 的部分則是透過 static token file 作為範例來示範如何讓外部的使用者可以透過 curl 打 api-server 並且被辨認為特定的使用者，接者搭配 RBAC 的設定來給予特定的權限。 文章針對這些機制的來龍去脈解釋得非常清楚，能夠讓人更加理解這些機制的運作原理

Kubernetes 1.31 如何透過 consistent read 來提升整體效能 https://kubernetes.io/blog/2024/08/15/consistent-read-from-cache-beta/ Kubernetes 於 2024/08/13 釋出了 1.31 版本，其中一個進入到 Beta 階段的功能就是 consistent read。 這個功能對 Kubernetes 的使用者來說無感，但是對於 Kubernetes 的叢集管理人員來說則是一大福音，該功能改善了 Kubelet 與 API Server 存取的流程。 過往的 Kubelet 都會對 API Server 詢問所有 K8s 上的 Pod 資訊並且過濾到跟自己節點有關的 Pod，而理想狀況應該是只要詢問跟該節點有關的 Pod 就好。 為了達到這個理想機制， Kubernetes 內部針對 Cache 的部分進行調整與改善，引入了 etcd 的一些功能最終達成如標題所述的 consistent read 的功能， 根據官方測試，引入這個功能帶來了 1. 降低 etcd 的負擔與壓力 (25%) 2. 透過快取提升了 pod LIST 相關操作的存取速度 (提升3倍) 3. API Server 的 CPU 使用率下降 30%

架構轉移到 Event Driven 遇到的各種挫折 https://medium.com/@shiiyan/how-i-failed-in-event-driven-architecture-86eb493082fa 本篇文章分享的是作者嘗試導入 event driven 架構來改善目前環境的心路歷程。 以目前的環境下架構來說，作者觀察到有很多物件彼此之間都有關聯性，常常 A 更新後也要去更新B, 最後還會呼叫到物件 C 的更新。 於是作者就希望可以透過 event driven 的架構來簡化這些流程，讓彼此之間的關係不要強烈綁定，透過 events 去定義每個物件的概念，有事情就呼叫相關的event 來處理。 然而真的實作後，作者發現事情沒有這麼簡單，實務上的轉移遇到一堆問題，並沒有辦法直接轉換過去，更是有很多實作上的問題，包含 1. 單向溝通的限制，不同於過往緊密的實作限制，A 呼叫B, 但是 B 不方便把自己的結果退回去給A. 2. Event Chain 可能會很複雜，複雜的情況下若要保持先後順序又是一大挑戰 2. 因為都是event 非同步處理，所以偏向 eventually consistency 的架構 文章內有更多關於實作上的辛酸血淚