Kubernetes 1.0 發展之路回顧

https://itnext.io/kubernetes-the-road-to-1-0-525a9420fdf0


今年是 Kubernetes 發展十週年，世界各地都有相關的慶祝活動，本篇文章作者作為當初 Google 內部 Kuberetnes 開發人員之一，就以自己的記憶跟大家回顧 Kubernetes 誕生期間的種種發展。

1. 網路上最常見到的說法是 Google 內部 Borg 專案為 Kubernetes 的前身，但是作者認為更精準的說法應該是 Omega 才對， Omega 作為 Borg 的繼任者，改善更多使用上與操作上的問題，最後才順水推舟將一切好的設計保留到 Kubernetes 上。
2. Labels/Annotation 等概念設計都不是 Borg 一開始就有的，都是內部使用者回饋出來的機制，內部使用者希望透過一些方式以邏輯的方式分類物件，最終才產生這些設計
3. 最早期是採用 Task 來描述運算資源，後期才改為 Pod
4. 初期沒有 Kubelet 的設計，都是由 Kube-Proxy 直接跟 etcd 溝通取得相關計算
5. 節點最早期稱為 minion，後期才改名為 Node
6. ...等，文章內還有許多發展初期的討論

今天 CloudSummit 2024 的分享
https://speakerdeck.com/hwchiu/exploring-the-gradually-lost-technical-skills-in-the-cloud-native-era

祝大家成長路上，能夠保持技術初心，一邊學習實作一邊學習應用，避免真的變成 YAML Engineer

K8s 從 cgroupv1 升級到 cgroupb2 的踩雷經驗
https://zouyee.medium.com/a-tragedy-caused-by-a-single-kubernetes-command-7b6126b06513

隨者 CentOS EOF 的到來，團隊決定轉移整個 OS 的同時順便將 Cgroup v1 給轉移到 Cgroup v2，然而轉移過去時，過去用來收集 CPU 使用情況的參數 "-enable_laod_reader" 則會使得 kubelet panic，沒有辦法正常運作。

本篇文章主要著重於
1. Container Metrics 如何被產生
2. Kubernetes 如何監控 Container Metrics
3. CPU Load 是如何被計算的

文章開頭先簡介 CAdvisor 的概念，透過程式碼解術 "-enable_load_reader" 該參數是如何影響 CAdvisor 要不要收集 CPU 的指標。
此外，自從 K8s 1.19 後， CAdvisor 已經被內建於 Kubelet 內，所以使用者也都不需要自行安裝，

當 CAdvisor 要收集 CPU Load Average 時，會透過 netlink 的方式去跟 kernel 溝通來獲取資訊，使用的指令是 "CGROUPSTATS_CMD_GET"，結果底層的實作只有
支援 cgroup v1 的類型，遇到 v2 就會回傳 EINVAL 的錯誤。

作者諮詢過 cgroup2 的維護者，其推薦改使用 PSI 的指標來獲得 CPU 的資訊，不在需要透過 CAdvisor 的方式來獲取 CPU 的資訊，文章內也有附上其他相關 ｉｓｓｕｅ．

圖解 JuiceFS 創建 Pod 過程中 CSI 的流程
https://arthurchiao.art/blog/k8s-juicefs-csi-workflow-zh/

JuiceFS 是一個以 Object Storage 為基底並且提供 Filesystem 介面供使用者操作的檔案系統，文章內先簡述 JuiceFS 的架構，以及這類型的服務搭配 Kubernetes CSI 的操作概念，以 JuiceFS 來說則是會以 Fuse 為基底，並且透過 sidecar 或是 agent 的方式來動態的將遠方的空間掛載到目標 Pod 節點上。

文章後半部分透過操作來仔細解釋所有流程，搭配各種 log 來觀察 kubelet, CSI, Agent 等元件的互動流程。

為什麼會有想要取代 Helm 後繼方案

https://itnext.io/finally-a-viable-helm-replacement-388d538f9e1f


Helm 作為 Kubernetes 內最成熟且最多人使用的應用程式打包與發佈框架，這邊的應用程式代表的是用一堆 YAML 來描述的應用程式。

Helm 透過
1. 支援不同版本的設定與打包
2. 從早期的 www server 到後來的 OCI Server，有不同的方式可以發佈與讓人下載各種打包好的 Helm Chart (一整包 YAML)
3. 透過 Template 的方式讓使用者可以客製化 YAML 的內容，減少重複撰寫同時又可以滿足各種使用情境

Helm 有很多好處，但是使用上也有很多限制與問題，譬如
1. 部署狀況不明確，需要使用者自己去除錯
2. 沒有明確的 dry-run 模式，只能透過產生 YAML 去判別
3. Template 的撰寫很複雜，寫得過於複雜雖然功能強大，但是維護上又很困難

諸多特性讓很多 Helm 的使用者又愛又恨
此外 Helm 目前最大的隱憂也就是 Maintainer 的數量以及相關 feature 的演進速度已經逐漸放慢，整個專案的發展進入停滯的狀況。

因此目前也有不少專案開始嘗試重新設計，希望可以吸取 Helm 的經驗重新打造一個更適合的 K8s 應用程式打包框架。
本篇文章介紹的 Werf 就是一個對 Helm 完全相容的新框架，該框架嘗試基於 Helm 的經驗並且解決各種已知問題，譬如部署下去還會自動收集當前部署狀態，並且回傳相關 log 讓使用者可以知道部署狀況，並且也有自動 rollback 的機制。

Google & Amazon 對於 CI/CD 的設計經驗談
https://carloarg02.medium.com/how-amazon-and-google-view-ci-cd-in-an-entirely-different-way-824b9c36777e


作者過去 20 多年內，先後待過 Amazon, Google, Amazon(回鍋) 內關於 CI/CD 的相關部門。
作者透過自身的經驗觀察到這兩家大公司對於 CI/CD 的設計哲學是截然不同的，而這個截然不同主要體現於
1. Pre-Summit: 程式合併前的各種操作
2. Post-Summit: 程式合併後的各種操作

以經驗來看， Google 的 Pre-Summit 做得非常完善，而 Amazon 則是 Post-Summit 更為完善。

作者認為造成這兩種近乎對立截然不同的結果的成因在於程式碼的架構。
Google 採取的是超級 monorepo，全公司的程式碼都放到一個共同的 Git Repo，所有改進都會曠日廢時，以作者當年的經驗來說，部署一個應用程式到 Production 可能是幾天後。但是也因為這種框架，使得 Google 非常專注設計 Local Dev Environment 的設計，所有開發者都要有辦法能夠於本地進行完整的 E2E 測試，確保測試完畢後才有機會合併到最終的 Repo.

與之相反的是 Amazon 則是各種 microrepo 的概念，應用程式散落到不同的 Git repo 中，每個都有自己獨立的開發與部署流程，彼此之間互相不干擾，因此 Production 的部署也不會被其他人影響，速度很快，但是相反的是 Pre-Summit 前的操作則是因為整個 E2E 牽扯過多的 Repo，導致設計上變得困難。

作者以自身的經驗來想，並沒有覺得兩個解決方案是絕對勝利的，畢竟 Google & Amazon 兩者也都走到了今天，公司也還在繼續成長茁壯，軟體的發展也是一直持續前進，與其說某種架構是絕對正確的，不如說每個環境有適合的架構。

從 mongodb 轉移到 PostgreSQL 的心路歷程
https://medium.com/@tony.infisical/the-great-migration-from-mongodb-to-postgresql-fa3978bc143b

本篇文章作者描述團隊從 MongoDB 轉移到 PostgreSQL 的整個心路歷程。

團隊初期追求的是快速搭建環境確認商業模式可行，所以一開始透過 MongoDB 以及 Moongose ORM 來建置整個 DB 系統。

然而隨著環境上的使用者愈來愈多，使用情境逐漸變得複雜，有愈來愈多功能限制使得團隊感覺綁手綁腳，譬如
1. 沒有 transaction 的概念
2. 沒有關聯性資料庫的相關功能，如 CASCADE 搭配刪除的機制去清理
3. 因為授權機制的改變，大部分的 Cloud Provider 都沒有支援 mongoDB
4. 技術缺乏，大部分的工程師都更熟悉 SQL 類型的操作與部署

因為這些考量所以團隊決定進行資料庫架構轉移，包含
1. 架構評估
2. 效能評估
3. 資料轉移的步驟

其中如何把MongoDB 的資料轉移到 PostgeeSQL scheme 則是最困難的部分。
詳細的轉移步驟與流程請參閱內文

架構轉移到 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 的架構

文章內有更多關於實作上的辛酸血淚

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%

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 的設定來給予特定的權限。

文章針對這些機制的來龍去脈解釋得非常清楚，能夠讓人更加理解這些機制的運作原理

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修復以及相關小功能的改變

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 來描述與操作

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 無感。

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: 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: 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: 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 環境中的價值，是對雲端原生基礎設施的一次有力創新。

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: 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://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.

https://blog.cloudflare.com/multi-path-tcp-revolutionizing-connectivity-one-path-at-a-time/

Cloudflare 官方部落格撰寫的 MPTCP (Multi Path TCP) 的教學，相較於傳統 TCP 來說, MPTCP 透過不同的路徑同時傳送 TCP 封包，可以提升整體的 throughput 以及更好的可靠性(假如系統上有多張網卡，則可以同時一起傳輸）

文章內有更多的介紹，這篇文章寫得很清楚，雖然目前大部分環境實務上用不到，不過還是可以當作科普的方式來學習一些網路概念