這篇文章是來自 Medium 的官方技術文章，稍微探討了一下其內部如何使用 Kubernetes 的，整體是偏向 high level 的角度，因此不會有太多細節

1. Production 環境是建立於 4 個 AZ 上
2. 使用 Terraform 以及其他內部自行搭建的軟體來管理
3. 使用 cluster-overprovisioner 來提早部署節點以因應服務資源的變動需求
4. 其他細節可以看文章內容

https://medium.engineering/kubernetes-infrastructure-at-medium-d9e2444932ef?gi=531e0733b35c

來自 Cloudflare 的技術文章，非常特別是文章進去有繁簡版本可以直接閱讀

文章摘要為
1. Cloudflare 以 Rust 重新打造名為 Pingora 的 HTTP Proxy
2. 效能比 Nginx 更好
3. 探討 Nginx 原生 worker(process) 運作模式的缺點以及為什麼「重複連線使用」的表現會非常差
4. Nginx 原生的模型不容易客製化功能，採用 Lua 效能不好且非靜態語言
5. 多方考量後決定自行打造一個屬於自己的 HTTP Proxy，採用 Thread 為基礎已達到共有效的共用資源。
6. 結果論: CPU 減少70%, 記憶體減少 67%




Ref: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/

過往本地開發家打包 Container Image 普遍採用 docker 的方式來打包，而本篇文章則是要介紹一個發展也很久的工具 Buildpacks，比較一下兩者的優缺點以及什麼情況下適合使用 Buildpacks


https://medium.com/itnext/replace-dockerfile-with-buildpacks-f7e435ad2bfc

隨者 Kubeval 本底開發效率降低後而生的新專案 Kubeconform，很多概念都源自於 Kubeval 但是解決諸如 CRD, wirldcard 資料夾等各種問題。


這年代專案來得快也去得也快...今天可以用的東西也許兩三年後就沒人維護了，沒有持續更新很容易就會握者一大堆死去專案, sad

https://github.com/yannh/kubeconform

Google SRE 團隊分享運行 SRE 20 年的 11 條經驗

對 Google 來說，20 年的時間有非常多的架構改變，最初每個 datacenter 大約只有數千台伺服器，其中透過 2.4G 頻寬的網路連結串連彼此。
如今資料中心的規模是過往的一千倍，網路的規模更是一萬倍。

因此該篇文章就細數這段改變以來所學到的經驗

節錄幾個有趣且常被忽略的點
1. Recovery mechanisms should be fully tested before an emergency

備援方案不是紙上談兵，沒有定期維護驗證過的備援方案跟我出嘴喊喊其實差不多


2. COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

溝通設備需要有備案，但是這些備案基本也與上述環環相扣，需要測試才算是真正的備案

3. A single global hardware version is a single point of failure

單一型號的硬體簡化了維運與操作，但是一旦該型號出現大問題，你就慘了
文章舉出 2020 內某網路裝置就出現這種問題

剩下的八個經驗就請自行閱讀囉

https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/

一張圖圖解 HAP, VPA, CA 以及 CPA 等四種 Kubernetes 內自動擴展機制的差異


https://hwchiu.medium.com/what-are-the-differences-between-vpa-hpa-ca-and-cpa-in-kubernetes-5f74c97001ed

https://github.com/cncf-tags/container-device-interface

CRI+CSI+CNI 還不夠，現在又來一個 CDI ...

Java 應用程式於 Kubernetes 內的效能問題

眾所皆知，於 Kubernetes 內部署 Java 應用程式很容易遇到關於 startup 階段資源調整的挑戰，應用程式起來時需要一些時間進行暖機來初始化所有資源，這其中應用程式就會落入容器已經部署但是容器還沒有準備好的階段。

Kubernetes 內提供 Startup/Readness 等相關 Probe 來處理不同階段的狀態處理，但是當應用程式配上 HPA 等機制來動態調整 Pod 數量時就可能會遇到「即時新增 Pod 來處理流量，結果新的 Pod 要花久時間才可以處理流量」的情況。

本篇文章作者提及數個關於 JVM 參數來最佳化啟動的時間，同時也提及 ReadyNow Profile log 如何一同協作處理。
以結果來說，整個暖機時間從 1000s 降到 180s，高達 81% 的降幅


Ref: https://medium.com/walmartglobaltech/pod-startup-time-improvements-e2f3fb79751d

這一兩年於 CNCF 領域中看到 Wasm(WebAssembly) 的消息愈來愈多，甚至於 CNCF landscape 中也有一頁介紹 Wasm 生態系的開源專案們(Languages, Runtimes, AI, Tooling, O11y, App framework...etc).

文章從最基礎先探討何謂 Wasm，最後也有介紹如果要於 k8s 生態系中去運行 Wasm 的話要怎麼去調整 CRI 那層的設定，內容雖然很長，但是閱讀完畢會對 Wasm 有更深一層的理解。

Ref: https://medium.com/@seifeddinerajhi/wasm-and-kubernetes-a-new-era-of-cloud-native-application-deployment-b3c59b39f640

Leveraging Cluster API for Production-Ready Multi-Regional Infrastructures

LINE (LY) 於 KubeCon/CloudNativeCon 2023 上的分享，算是基於 ClusterAPI 為基礎介紹內部如何達成控管 K8s Cluster 的生命週期，其中是以 CAPO, CABPK. CACPK 等不同 Cluster API Provider 來處理，分別呼叫 Openstack 以及透過 kubeadm 等工具來快速搭建一套 Cluster，整個邏輯與流程滿適合研究學習的，畢竟整體規模超過 1k cluster


https://static.sched.com/hosted_files/kccncna2023/18/leveraging_cluster_api_for_production_ready_multi_regional_infrastructure.pdf

Code-first vs. Product-first
雖說是多年之前的文章，但是不管什麼時候來看都覺得非常貼切，似乎是這個行業永遠不會消失的討論

文章中闡述目前開發者大抵制上可以分成兩種
1 程式品質優先
2 產品優先

程式品質優先主要著重於程式碼如何架構，採用何種工具框架與程式語言...等各種程式語言相關的考量，而產品優先者來說，也會在意這些程式碼等工具，但是這只是手段，最終還是產品本身能否解決問題，更喜歡看到產品上線後使用者的回饋與反應

作者自身的觀點則是偏向撰寫程式的目的不是為了寫出多漂亮多炫酷的程式碼，反而是解決問題才是重點，但是這並不代表為了解決問題就可以完全不考慮程式碼本身的品質與架構，而是取捨之間都要考慮「一個不能解決問題的產品，其程式本身鐵定不好」

以目前的 Cloud Native 生態來說似乎也會看到類似的概念，基底還沒有完成就著急的將所有各種新知都一路疊加上來，卻忽略自己當初到底想要解決什麼問題，譬如連一個 cluster 都還沒有，就開始考量如果有一百萬個 cluster 時要如何處理各種問題

https://thezbook.com/code-first-vs-product-first

Like LeetCode for Linux

一個適合系統管理員的練習網站，問題分成三個難度並且讓你去挑戰嘗試修復問題，拿來練習訓練彼此對系統熟練度似乎是個不錯的契機？

https://niravshah2705.medium.com/kubernetes-image-pull-optimisation-part-i-exploring-options-f79d79c3fe45

本篇文章探討 Kubernetes 目前內部是如何抓取 Container Image 以及實務上如果想要加速可以有哪些策略去執行。

根據作者團隊的統計結果，以 20 不同應用程式去計算，從 Pod 部署到容器正式提供服務，大概有 57% 的時間卡在抓取 Image，剩下的時間則是給 Probe, Mount Volume, Node Provisioing 等狀態去處理。

因此如果可以改善 Pulling Image 所需要的時間，就可以更有效去產生新的 Pod ，特別是當遇到 HPA 這種需要及時雨的情況。

雖說我們可以透過 ImagePullPolicy:IfNotPresent 來達到使用 local cache 的機制，但是作者提到很多時候新產生的 Pod 要跟舊 Pod 落在同一節點並不是可以保證的情況，因此如何提供更有效的 Image Cache 解決方式也是一個改善整體服務效率的環節。

文內提出不同種方式

1. 平行下載 Image: Kubernetes/Kubelet 預設是採取 Sequencial 的方式去下載 Image，因此新節點上線然後瞬間大量不同 image 服務部署上去時，大家就會輪番排隊，這部分可以透過 kubelet 的設定調整成支援平行處理。此外 kubernetes 1.27 後則支援可以調整最大平行數量來控制平行的行為
2. 透過 Lazy-Loading 的方式，一邊執行容器一邊下載容器： 這部分需要仰賴特別的 OCI 實作，文章提到 AWS 有開源 Seekable OCI 來支援此種操作，而 GKE 也有 GKE image straming 的技術可以達到一邊下載一邊執行
3. Pre-fetch images: 事先抓取好所有會用到的 Image，文章提到可以透過 kube-fledged 開源專案來動態執行，將所有可能會用到的 image 提早先抓到相關節點上
4. 透過 pull through cache 機制來避免每次抓取 Image 都要到外部服務(Quay, Dockerhub)。

Title: 調整資源需求卻不用重啟容器?
Source: https://medium.com/@seifeddinerajhi/the-new-in-place-kubernetes-pod-resource-resizing-feature-a-deep-dive-11b0ece334ef


Kubernetes 內的容器都可以透過 resource.request 以及 resource.limit 來調整 CPU,Memory 等資源設定的需求，而 Kubernetes 1.27 後則正式支援動態調整資源用量的機制，該機制狀態為 Alpha，因此 1.27 的使用者必須要修改 feature gate 來開啟該功能 InPlacePodVerticalScaling 。

該功能允許 Pod 的使用者去調整資源垂直用量調整的行為，目前允許兩種行為， “NotRequired” 以及 “RestartContainer”。 RestartContainer 的行為就是過往的行為，意味當修改 resource.request 或是 resource.limit 資源時會將 Container 重啟以套用新的設定，而 NotRequired 則是不會重啟 Container，能夠動態的修改需求而不影響容器，也就不會造成服務 downtime.

本功能的出現能夠對服務提供更好的資源控管，該功能從設定到啟動大概會需要幾十秒到一分鐘左右的設定時間，對於應用程式來說能夠更有效地去利用資源用量而非寫死一個固定值。此外若此功能逐漸穩定，似乎可以與 VPA 搭配來更有效的縮放資源讓應用程式適應情境並且控管資源成本。

Title: 如何透過兩個簡單步驟減少 Docker build 40% 所需時間
Source: https://medium.com/datamindedbe/how-we-reduced-our-docker-build-times-by-40-afea7b7f5fe7
容器化導入對開發團隊來說一個非常顯著的困境大概就是應用程式部署到環境的流程，為了讓開發者有更好的開發體驗以及減少不同工具帶來的問題，通常都會透過設定好的 CI/CD pipeline 來達到統一的方式，然而這個過程消耗的時間則取決於整個 pipeline 的設計。
對於開發者來說，若是每次測試都要等待數十分鐘，則會覺得浪費時間，有可能乾等或是切換到其他工作，前者虛度光陰後者則有可能會因為大量的 context switch 而導致疲累與無法專注。

因此如何有效改善 CI/CD pipeline 避免開發者等待太久進而降低開發者生產力則是一個不可避免的議題。

本篇文章主要探討如何用兩個概念來提昇 Docker build 的所需時間，其中第一個是牽扯到 buildkit 的用法，透過 buildx plugin 的導入來利用 buildkit 所帶來的各種功能，並且透過 remote cache 的方式來提升整個效率。第二個範例則是藉由新版 Dockerfile 所提供的新語法，改善 COPY 指令所帶來的消耗，過往 COPY 指令會基於前述 Layer 產生一個全新的 Layer，並且最後透過 DIFF 的方式來產生最終 image，而新版則提供 “–link” 的方式來改善實作，透過 link 的概念來實作 COPY 的行為，不需要維護不必要的 layer 進而提升整體建制時間，特別是當使用 multistage 為基礎去建制時會因為大量 COPY 而更有感。

Title: Kubernetes 1.27 引入 Memory Throttling 機制來減少應用程式 OOM 的次數
Source: https://kubernetes.io/blog/2023/05/05/qos-memory-resources/

Kubernetes 過往透過 resource.limit 來控管當 CPU 與 Memory 踩到上限時的保護，而兩者的差異在於 CPU 會被限速(Throttling) 而 Memory 則是會直接觸發 OOM(Out Of Memory) Killer 將應用程式直接砍掉。

而 Kubernetes v1.27 則正式引入全新的功能，該功能為 Alpha 階段，需要於 Kubelet 開啟 MemoryQoS 來使用。
MemoryQoS 的目的是基於 Cgroups v2 的功能提供一層全新的 QoS 保護，該保護會提供類似於 CPU Throttling 的效果，當 Memory 用量超過門檻後，kernel 會開始更積極的回收相關記憶體並且降低應用程式的使用速度避免該應用程式用到滿最後被 OOM 移除。

該功能的使用情境是譬如應用程式可能短時間內會大量使用 memory 且用量很有可能觸發到 OOM，當 OOM 發生時就會造成服務 downtime，而該功能希望能夠減緩消耗量來確保應用程式依然可以服務，並且待時間過後恢復到正常的 memory 使用量。

該門檻的計算方式相對複雜，同時不同 Pod QoS 會有不同設定，若 Pod 本身是 Guarantee 類別，其本身則不會有該門檻的設定，盡量讓應用程式能夠全速運轉。若為 Burstable 或是 BestEffort 兩種類型的 Pod，則會有不同的計算方式來計算該門檻。

官方文章有介紹更為詳細的計算方式以及原理介紹。

Title: Java 應用程式於 Kubernetes 內的 Memory 不如預期
Source: https://medium.com/nerds-malt/java-in-k8s-how-weve-reduced-memory-usage-without-changing-any-code-cbef5d740ad

本篇文章探討的是作者團隊將應用程式轉移到 Google Kubernetes Engine 上後開始遇到一些不好解釋的 memory 使用現象，舉例來說就是不同類型角度的記憶體曲線難以解釋成長
文章的圖表呈現三種曲線，分別是

Pod resource.limit: 也就是上限，只要踩到這個點就會觸發 OOM
Resident Set Size(RSS): 從 OS 角度觀看所使用的記憶體用量
JVM: 從 JVM 角度觀察到的記憶體使用量，包含 Heap, Metaspace 等
(1) 是用來避免記憶體使用過度的保護機制，而 (2)/(3) 則是應用程式運行期間產生的數值，令團隊感到難以解釋的就是 (2)/(3) 的使用量差距很大，幾乎快要到兩倍的差距，應用程式運行久了後 (2) 的數值會逐漸提高最後觸發 OOM，但是 (3) 的使用量一直都很低。

一種解法就是不停的加大 (1) 讓 OOM 的門檻更高，但是這樣的做法就是浪費系統資源，因為 JVM(3) 實際用的量就是不高，無限疊高門檻只是把問題轉移到成本上而已。
為了解決這個問題，作者團隊先重新檢視目前 JVM 的設定，包含

Heap Size (-Xmx)
Metaspace (-XX:MaxMetaspaceSize)
Thread Stackcs (-Xss)
DirectMemory (-XX:MaxDirectMemorySize)
CodeCache: (-XX:ReservedCodeCacheSize)
不同 GC 策略(G1/GC, Shenandoah …etc)
然而各種組合都沒有辦法解決 RSS 的記憶體逐漸提升且是 JVM 角度兩倍的問題，因此團隊花費數個月研究後決定轉往到另一個方向觀察，也就是記憶體配置。
從根本問題來看，OS 覺得 RSS 記憶體就是吃這麼大，而 JVM 覺得吃的不大，如果兩個系統都沒有出錯，說的也都是事實的話，那問題可能就會是記憶體配置的回收問題，因此
開始使用 jemalloc 來試試看。

有趣的是一但使用 jemalloc，上述的問題幾乎就不見了， RSS 的使用量大幅度下降，與 JVM 的用量更為貼近，似乎代表 jemalloc 更能有辦法將記憶體回收給 OS，有了這個發現
開始研究 jemalloc 與預設 glibc 實作的差異，想透過實作差異來理解整個問題的本質

jemalloc 相對於原始的malloc 來說更加強調破碎化的處理，所以作者團隊就從這邊出發開始理解底層是如何去要記憶體空間，以及釋放的邏輯，最後也找到一個有趣的參數去控管 Arena(一個底層內部控管記憶體分享的資料結構)的大小，根據該參數調整後就算是原先版本也可以得到較好的記憶體使用分配。
文章最後也有嘗試使用 TCMalloc 去進行分配，得到的結果與 jemalloc 近乎相同，都比預設的好上不少

全文內容頗長，對 java memory 有瞭解需求的也許可以參考看看

Title: 什麼是 Micro Frontend? 是一種解藥還是又一種 buzzword?
Source: https://newsletter.systemdesign.one/p/micro-frontends

近年微服務(Microservices)隨者容器化的發展幾乎已經變成軟體開發的一種常見模式，然而大部分的微服務都是聚焦於後端伺服器的開發，那前端的部分是否也會有類似的概念？
Mirco Frontend 一詞出現於 2016 年，主要目的是想要探討微服務的架構精神是否也可以運用於前端的架構中？
一個簡單的就是有無辦法講前端頁面中的元件依據功能，或是依據商業需求 (business domain) 拆分成不同的模組，而每個模組都可以有專門的團隊去進行開發與維護，最後的前端頁面則動態的將這些模組載入，因此實務上開發就不需要一組人馬一次搞定全部，而是可以達成像微服務精神一樣各自開發與部署，最後組合出完整的頁面。

然而只要是微服務就會有元件溝通問題，而前端架構中要動態載入這些不同模組大抵上就是 iframe, js, web component 等相關方式，因此文章中也有介紹不同方式的優缺點以及目前相關的框架。

然而微服務帶來的問題勢必也會於 Micro Frontend 身上看到，隨者元件拆分，整個專案變得更為複雜，同時同時載入這些是否會有效能上的問題？ 以及所有的 CSS 等相關風格是否一制可能都會導致實作上的困擾。

如同微服務一樣，這類型的架構都需要仔細專研並且確保有益處才需要真的導入，否則只會導入各種缺點卻又享受不到優點，最後就是拿磚砸自己的腳。

註: 下列文章列出近年來有公開宣稱使用 micro frontend 的公司
https://entando.com/page/en/7_successful_companies_using_micro_frontends_en_1

Title: 分散式系統的基本理論 CAP 的介紹
Source: https://www.educative.io/blog/what-is-cap-theorem#whatiscaptheorem


學習分散式系統的人都必須要理解的 CAP 定理，該定理描述的是 C(Consistent), A(Availability), P(Partition Tolerance) 三者並不可能同時滿足，因此會根據設計情況產生出
CA, CP, AP 等三種不同架構的設計。

Consistent: 講求的是一制性，要求分散式系統中任何時間點去詢問任何節點都可以問到一致的最新資料，所有資料都是一致的
Availability: 系統任何時間都要維持可用性，意味不論分散式環境中節點狀況如何，每個每個請求都可以得到一個非錯誤的回應，但是並沒有保證獲取的資料一定是最新的。
Partition tolerance: 當網路出現問題導致節點分區(分區意味節點之間沒有辦法透過網路溝通)，這種情況下整個系統依然要可以運作

根據定理，這三個特性沒有辦法同時滿足，因此設計系統時必定要有取捨。通常 CA 架構比較不會被討論是因為其捨棄了 P 的概念，沒有辦法處理網路的情況多半不會是分散式系統架構，更像是單節點的服務，因此更多的聚焦都是 AP 與 CP 兩種不同設計。

文章中雖然有依照資料庫類型去列舉是 AP 還是 CP，不過實務上的設計並不是如此的非黑即白，更多時候會有一些設定的彈性來處理 C&A 資料的關係，如果對於這類型有興趣也可以參考這篇文章
https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Title: Terraform/OpenTofu 分家後的開源貢獻體驗
Source: https://medium.com/@andrewhertog/contributing-to-terraform-vs-opentofu-26779d480c7f

如果有關注 IaC(infrastructure as a code) 的人可能最近幾個月有關注到 Terraform 因為授權改變而引發的一系列事件

Terraform 本身是由 HashiCorp 公司開發與維護，其架構與使用性吸引了大量的開發者與平台貢獻者，縱使有AWS CDK, Pulumi 等其他解決方案並存，Terraform 依舊還是所有人踏入 IaC 世界的首選。

然而從 Terraform v1.6 之後，這個選擇將會面臨兩個分歧點，該繼續使用由 HashiCorp 所維護的 Terraform 或是目前已經掛在 Linux Foundation 底下的分支 OpenTofu.

有鑒於 HashiCorp 於 1.6 版本後引入的授權機制，不少基於 Terraform 去搭建 SaaS 等商業收費的公司全部預料都將受到影響，公司的生財工具無法繼續免費使用而必須要開始付費給 HashiCorp, 因此便開始組隊，號召要求 HashiCorp 繼續保持開放開源免費。最後的結果就是 OpenTofu 這個完全基於 Terraform 1.5 分之出來的全新專案，並且未來將會完全獨立於 Terraform 的發展，功能/用法等未來應該會逐漸有更多的分歧

本篇文章是作者基於自己的貢獻經驗分享講相同的錯誤修正提交到 Terraform 與 OpenTofu 兩個不同社群的過程與體驗
以作者的經驗來說， terraform 的溝通緩慢不順且發生令人不能接受的事情（merge 不討論不通知，直接吃走 credit)
。而 OpenTofu 方面則有更多的討論與互動，對開源貢獻者來說體驗更好，也會更吸引開發者繼續貢獻與支持。

未來怎麼走不清楚，也不知道到底誰會贏誰，但是目前可以確定的是使用者當升級到1.6版本時勢必要開始思索授權是否會造成影響，以及 OpenTofu 是否可以變成替代品

Koordinator 是一套基於 QoS 的 Kubernetes scheduler 解決方案，目標是基於更細膩的 QoS 設定來處理服務部署與調度的問題。
預設的 Kubernetes Scheduler QoS 針對的比較是踢除時以及相關運算資源的比較，而 Koordinator 則加強關於資源部署的考量，譬如

考慮當前節點的資源用量
考慮 Colocation 的需求
提供基於 NUMA 需求的部署，讓應用程式可以更有效地去使用 CPU 資源
提供比社群版本更強大的 Descheduler

https://github.com/koordinator-sh/koordinator