回顧 2023 年 Kubernetes 環境下的各種 Vulnerabilities

https://www.armosec.io/blog/kubernetes-vulnerabilities-2023/


根據統計，2019到2023 這幾年來看， Kubernetes 相關的 Vulnerabilities 數量幾乎翻了一倍，去年大概有 60 多條左右
這些 Vulnerabilities 大致上可以分成 Kubernetes 本身的問題以及相關生態系整合的問題，其中
1. Kubernetes 本身大概 11%
2. Cilium: 9%
3. ArgoCD 12%
4. Kyverno: 11%
5. KubePi: 6%
6. Others: 51%

作者從中整理了這些漏洞並且分類，可以分成下列幾項
1. Users can escalate into admin privileges by creating pods or persistent volumes on Windows nodes.
2. Users can launch containers and bypass the mountable secrets policy.
3. Users are able to bypass container image restrictions.
4. Pods can bypass the enforcement of the seccomp (secure computing mode) profile.
5. This entails improper privilege management in SUSE Rancher.
6. This entails improper authentication in Capsule Proxy, which leads to privilege escalation.

後兩者與特定工具有關，其餘前面四個類別也都有對應的 CVE 紀錄，總結來說隨者 Kubernetes 的應用愈來愈廣泛，資安的重視程度也要隨之提升，對團隊來說除了資安管控外，如何讓管理與開發不同的團隊能夠一起合作來提升資安風險也是另外一個重點，畢竟過多的限制有時候會對開發人員帶來過多的不便。

使用 SimKube 這套工具來模擬與回放 Kubernetes Cluster 的各種事件

https://thenewstack.io/simulate-kubernetes-cluster-behavior-with-simkube/


隨者 Kubernetes 落地的普及，也有不少團隊與工具探討如何用簡易的方式去模擬 Kubernetes 讓開發團隊能夠有更方便的方式去評估應用程式的效果與效能
譬如 KWOK (Kubernetes Without Kubelet), KubeMark, Virtual Kubelet, KCP 以及本篇文章探討的 SimKube

SimKube 希望能夠於目標 K8s 上去記錄與收集相關事件，並且於模擬叢集上去回放與模擬這些行為，特別是問題發生時，能夠將這些事件重新回放讓團隊有機會去檢視真正的問題原因
作者舉例 SimKube 的一個使用情境就是去評估 Scheduler 的運作行為，看看哪種演算法與參數最後調度出來的結果是最適合的，透過這類型的模擬工具可以讓開發人員不需要有一個很龐大的實際叢集來測試，反之透過一台筆電上就可以去模擬這些行為。

https://www.cncf.io/blog/2024/01/12/root-cause-chronicles-connection-collapse/

P90 Latency 飆高的除錯經驗談


作者於本篇文章探討一個 event 發生時的除錯情況，該 event 發生來自於 Application P90 的 Latency 過高，該 Latency 大約為 9.2 秒左右，這使得所有 client 產生 timeout 然後功能都無法正常使用，接者 user 開始各種抱怨網頁無法瀏覽，訂單無法查閱等嚴重事項。

團隊接收到問題後，就開始排查各種可能性，首先透過 Prometheus + Grafana 觀察 Latency 飆高附近的其他資料，譬如 ops/sec 的資料，但是整體數值預期內，沒有特別明顯的問題，此外同步觀察由 Loki 部署的 Logging 服務，也沒有看到任何的有用的錯誤訊息，觀察問題的同時，先嘗試同步透過修改前端的 timeout 來暫緩使用者的問題。

接下來開始觀察整個流程中是否有哪些元件最近有進版升級過，會不會是什麼新引入的 Bug 所導致，不幸的是兩天內都沒有任何新版本上線，最後先透過 Kiali 服務來觀測叢集中所有被 istio 掌控的流量走向，觀察到流量與特定的服務有關，最後就開始請開發人員加入戰情室一同研究。
最終各種合作除錯下，找到問題點是後方 Database MySQL 的 maxconnection 踩到上限，因此所有新的連線都沒有辦法被處理，全部卡在等待，因此部分連線請求就開始失敗，然後一路回傳回去。

團隊針對這次的事件也學習到相關經驗，並且列出下列改善的方向
1. 前端的程式碼針對 timeout 的部分可以有更多調整，秒數可以拉大一些
2. 最前線處理使用者問題的工程師基本上對於整個 end-to-end 的架構都不理解，因此回報問題時沒有辦法提供太精準的細節
3. Istio 搭配的 Kiali 沒辦法顯示 External Service 的資訊，這使得判讀時會產生混淆
4. MySQL 沒有送出對應的 alert 來告警 connection 快滿或是已經滿的情況
5. database 的調整需要改善，最初採用預設值但是明顯不夠用

https://www.cncf.io/blog/2024/01/18/new-year-new-skills-kick-off-2024-with-cncf

CNCF 官方簡述過去針對使用者調查的清單中顯示，回應者普遍對 CNCF 這領域有更多技術需求，特別是技術人員的能力培養，因此 CNCF 本身今年針對這些訓練課程以及相關證照都有些許展望
訓練部分
1. Cloud Native Fuzzing Fundamentals
2. Etecting Cloud Rintime Threats with Falco
上述兩個課程主要都是跟資安相關，隨者愈來愈多的架構導入與整合，資安的重視程度愈來愈高，因此需求人才也多

證照部分也提供了兩個新的證照
1. Certified Argo Project Assciate (CAPA)
2. Cilium Certified Associate (CCA)

這兩個證照與專案有非常密切的關聯性，其中 CAPA 涵蓋的是整個 Argo 生態系，這包含了 Argo CD, Argo Rollout, Argo Workfow 以及 Argo Events。後者則是基於 eBPF 的 CNI 專案 Cilium

此外去年九月開始所推行的 Istio Certifited Associate (ICA) 與相關訓練課程也是目前很多環境都需要的一個技術，隨者 istio 專案的畢業，估計今年會採用 istio 的使用者數量會增加，而隨之而來的複雜性則不可避免，如何掌握更多知識以便未來有能力除錯則是每個導入 istio 的使用者都需要注意的。

使用 kdump + crash 揭露 Kernel Crash 的原因

https://medium.com/@idan7h/demystifying-kernel-dumps-on-openshift-96177579f8f2

本篇文章雖然是說基於 openshift 去搭建，不過重點都是 Linux 節點本身，因此上層是用麼方式搭建 Kubernetes 完全不影響。
對於 Kubernetes 維運來說，若問題是跟 Pod 有關時，大部分都會從 K8s API 出發去檢視各種資源的狀態來評斷問題，但有時候問題可能會是跟節點有關，這種情況下要除錯就相對麻煩，畢竟要直接進入到節點本身去存取與除錯，此外當節點本身因為 kernel crash 導致整個掛點不能使用時就更麻煩，雖然重啟節點之後就可以重新加入回 K8s 內繼續服務，但是要如何找出根本原因並且避免則是麻煩的事情。

文章內提及可以使用 kernel dump (kdump) 的方式讓 kernel 預留部分 memory 來紀錄當 kenrel crash 時當下 kernel 的狀態，並且之後使用 crash 這種工具來檢視紀錄並嘗試從中找到導致 kernel crash 的原因。
文章內也有提及可以透過某些 /proc 底下得參數來主動觸發 kdump 藉此熟悉與練習相關工具的使用。

7 個 Diagrams as Code 的工具
https://medium.com/@icepanel/top-7-diagrams-as-code-tools-for-software-architecture-1a9dd0df1815


不論是微服務, Kubernetes 或是分散式架構的崛起，如今的軟體設計架構愈來愈追求各種高可用性與效能，整個系統架構設計上趨向複雜，已經不是過往單體式應用程式可以用一兩句話就描述清楚的架構，因此系統架構設計與 review 時如何能夠清楚地將架構展示出來讓眾人有一個共同的概念去檢視就是一個所有簡報者都必須要準備的素材。

文章列出七種不同可以讓你以程式碼的方式去描繪各式各樣 Diagrams 的工具，這些工具有的會使用自行撰寫的語言(DSL)，有的則是基於 YAML 等各種格式，再搭配工具就可以將描述檔案給轉換為最後的架構圖，採用 As Code 的好處就是這些架構都可以透過 git 等版本控制的方式來控管，這樣工程師就可以用習慣的方式去保存這些版本的演進，而減少看到各種投影片的 v1, v2, v3 等，同時共同協作上也不會有各種一份檔案到處轉送，最後合併上又遇到各種版本不一致的問題。

從 DB Read 學習 Disk, FS 到 DB table 的互動流程

https://medium.com/@hnasr/following-a-database-read-to-the-metal-a187541333c2


本篇文章從 database read operation 出發，探討一個 DB read 實際上可能會發生的操作，包含
1. DB Table 的大小設計
2. DB Table 的 Cache 關係
3. DB Table 與 OS File System 的關係
4. OS File System 的 Page Cache
5. OS File System 與 Disk 的 Page 關係

這中間流程會有各種不同稱為 page 的術語，從 Disk, OS 到 Table 都有各自的 page，而其大小可能會有 4KB, 8KB, 32 KB 等都不同，所以這些不同大小的 Page 彼此之間是如何運作的，本文章就以比較淺白的方式去解釋流程，理解這些流程對於理解 DB 與儲存設備之間的參數調教會提供一些幫助，以至於不會亂槍打鳥

這兩日最大消息大概就是 nginx 的紛爭了，從這篇文章來看是一位自從 F5 收購後繼續無償幫 nginx 開源版本貢獻與維護的貢獻者因為與 F5 內部有些紛爭，最後這名貢獻者發起了 freenginx 的專案來繼續維持一個開源且免費的 nginx 版本

https://mailman.nginx.org/pipermail/nginx/2024-February/GPXQY27UA5SJJZ2Y6JWTRWJB2TKPTJR7.html

各種適用 Kubernetes 的 IDE


本篇文章列舉幾個對使用者相對友善的 Kubernetes IDE，這類型的工具目的都是提供一個好操作且視覺化的方式讓使用者可以去管理 Kubernetes 叢集。
相較於傳統使用 Kubectl 指令來管理，該指令需要使用者對指令有很好的熟悉程度，甚至很多時候還要使用各種指令組合才有辦法拼湊出 cluster 層級的資料，因此都會看到各種 -o json | jq, -o custom-colume 等各種輸出格式轉換並且搭配後續轉換。
而 dashboard 的目的就是簡化這些操作。

另外要特別注意的是，所有專案的使用是否都有 License(授權) 的條款，很多專案對個人免費，但是對於企業內的使用者都是要額外收費的，很多專案只是一開始沒有很嚴格的取締，但是並不代表往後不會突然收集資料直接索取應該有的授權費用，譬如 docker desktop 其實就是一個很常見的範例。

文內列舉的包含
1. Seabird
2. JET Pilot
3. Headlamp
4. OpenLens -> 大家比較熟悉的可能是 Lens 這個專案名稱，但是 Lens 本身使用上就有 License 的問題要注意，免費版本只有針對個人以及營收小於 10M 的企業而已，其餘情況理論上都是要購買 Lens Pro Enterprise 等相關授權。因此 OpenLens 這個選項才會出現在這邊，也許功能面上會比 Lens 少，但是授權問題會比較簡單。
5. Monokle
6. PyCharm K8s Plugin
7. K9s
8. Kubenav
9. Rancher -> 這個比較不能算單純 IDE，比較像是 K8s 管理工具並且附加的管理介面

https://medium.com/@seifeddinerajhi/explore-user-friendly-desktop-kubernetes-open-source-ides-5315516b0752

https://medium.com/@.anders/learnings-from-our-8-years-of-kubernetes-in-production-two-major-cluster-crashes-ditching-self-0257c09d36cd
本篇文章講述了將 Kubernetes 運行到正式環境 8 年來的心路歷程，最初使用時是於 AWS 上採取自建 Kubernetes 的環境，因為那時候根本沒有 AKS/EKS/GKE 等管理平台，所以可以說採用的時機點是非常早期，團隊於 2018 年開始將環境逐漸遷移到團隊比較熟悉的 Azure 上的 AKS。

這八年來不論是自己管理或是 AKS 的相關經驗學習如下

問題點: Cluster Crash
1. Root CA certificate, etcd/API server certificate 過期導致整個 Cluster 重建，雖然有各種 YAML/Helm 可以重組應用程式，但是卻沒有任何東西去紀錄 Cluster 建立的過程與設定檔案，這使得團隊花了幾天的時間才將整個環境重新打造並上線
2. 上述 Cluster 的重建過程中，使用了 kube-aws 這個專案來幫忙建置與管理，然而該專案那個時期有一個 bug 存在，沒有辦法正確的設定 etcd certificate 的有效期間，於是預設值又是一年，因此一年以後 cluster 又不能動了，不過這時因為有更多的經驗與知識，花了比較少的時間去修復問題，而且不需要整個 cluster 去重建。

上述經驗給團隊帶來的經驗有
1. Kubernetes 很複雜，沒有想像這麼簡單，不是隨時把一個人丟進去就可以學會使用 kubernetes，更別論 debugging 等需要更深入了解的操作
2. Certificate 很重要
3. 統一集中管理 Helm Chart
4. 要有 DR 計畫，更重要的是要測試過這些計畫，而且是時時刻刻都要測試，確保這些工具不會因為版本更新或是等相關架構改變而失效
5. Secret 等相關內容的備份
6. Vendor-Agnostic vs "Go All In"： 最初搬移到 AKS 時，為了有招一日可能要搬移到其他的環境，所以很多服務組件都採取使用 open source 自架服務，譬如 container registry, security scanning, auth 等。 團隊最後還是全面切入到 Azure 的服務
，因為發現從開發體驗，維運複雜度，甚至成本來看，其實都更加划算與有感提升
7. 巔峰流量前就要先行 scaling，雖然有各種自動 scale 的機制來調整數量，但是團隊發現這速度太慢，無法應付瞬間高峰的流量。

文章後半部分還有關於 Observability, Security 等相關內容的

淺談 K8s 中那些完全感知不到的 OOM 事件
https://medium.com/itnext/kubernetes-silent-pod-killer-104e7c8054d9


Kubernetes 中的最小部署單元都是 Container，而 Container 大部分情況下都會只跑一隻主要 process 來處理相關請求，因此當該 Process 被 OOM Killed 後都可以於 Kubernetes 的相關 event 或是 metrics 中去觀察到這現象來除錯。

但是假如 Container 中有其他 process，也就是 pid 不是1 的那些 process 被 OOM Killed 的話會怎樣？
從 OS 的角度來說是可以從 kernel log 找到相關事件，但是對 Kubernetes 則是完全無感的，所以你單純從 Kubernetes 的角度出發就沒有辦法收集到任何相關資料，除錯上也就會比較沒有頭緒。

該問題直到 Kubernetes v1.28 並且啟用 cgroup v2 的 grouping 功能，當 container 內有任何 process 被 OOM Killed 後，就會誅九族連帶 main process 一起被砍掉，最後就可以從 Kubernetes 的角度去觀察到這些事件。

至於 Kubernetes v1.28 以前，基本上沒有任何方式可以去觀察與監控這類型事件，只能從
contianer 內自行去監控並且處理。

又一個基於 ebpf 的效能監測工具，這次是由 netflix 所推出的 bpftop，不過監測目標倒不是普通的應用程式，而是所有 ebpf 應用程式，所以才會看到第二欄的 Type 都是針對 ebpf 的各種類型

所者現在愈來愈多 ebpf 的應用程式被掛到環境，特別是 k8s 生態系中，也許這類型的工具可以用來幫助管理員釐清每個 ebpf 的效率問題

不過前提可能是管理員要先懂 ebpf 而不是單純 YAML engineer

https://github.com/Netflix/bpftop

10 個微服務架構下的 anti-pattern
https://medium.com/statuspal/6-best-open-source-status-page-alternatives-for-2024-b68e5a967cc1


微服務架構的構思非常好，希望透過解隅的方式將服務給拆解來達到更彈性且更容易擴充的架構，同時每個服務都可以採用不同的程式語言，中間透過定義好的介面溝通即可。

然而微服務架構下若服務本身的設計不適當，反而會適得其反，使得整個架構變得更難用，因此本篇文章就列舉十個微服務下要避免的架構模式。

1. Monolith in Microservices
2. Chatty Microservices
3. Distributed Monolith
4. Over-Microservices
5. Violating Single Responsibility
6. Spaghetti Architecture
7. Distributed Data Inconsistency
8. Tight Coupling
9. Lack of Observability
10. Ignoring Human Costs

如何於 Kubernetes 打造多階級的 namespace 來更好管理多用戶
https://medium.com/faun/hierarchical-namespaces-in-kubernetes-5b07ea2c3e65
Kubernetes 內建 namespace 的機制來提供輕量級虛擬化，雖然沒有辦法達到如 VM 架構下去隔絕網路流量與相關系統資源用量，但是目前能夠提供
1. 系統 Quota
2. Label/Annotation 供第三方服務使用(如 Istio...etc)
3. 獨立的 RBAC

妥善設計下，可以透過這些機制去管理不同使用者的使用情境，使用者可能是
1. 一個團隊
2. 一個產品
3. 一個部門
4. ...等

隨者使用者數量增大，不可避免的就是 namespace 相關的設定會愈來愈多，同時有很多設定可能本身其實邏輯上是有依賴性的，譬如某個部門底下的團隊的產品，其 Quota 設定上應該會有所規範。這一切的邏輯都可以透過妥善的設定與設計去處理，只是要花不少時間與心力去處理。

本篇文章介紹的 HNC(Hierarchical Namespaces Controller) 是一個第三方服務，能夠將這些 namespace 給串成一個 tree 的架構來達到多節層的管理，來達到
1. 更有邏輯的去管理不同 namespace
2. 自動傳遞相關設定 (parent to child)
3. 簡化 RBAC 的設定

以 Raft 而非 Zookeeper 來搭建的 Kafka Cluster

https://medium.com/itnext/kafka-cluster-without-zookeeper-ca40d5f22304

Kafka 過去安裝需要搭配 zookeepr 來處理
1. Service Discovery
2. Leader Election
3. Broker Discovery
4. Configuration Management
5. ...等

而 3.3 版本後已經內建使用 KRaft 演算法(基於 Raft 改善)來處理分散式的架構，這也意味整個安裝過程不再需要 zookpeer，因此本篇文章就是基於這個概念來分享其架構以及安裝使用過程。

如何使用 eBPF 來偵測到 Kafka 叢集的效能問題

https://blog.allegro.tech/2024/03/kafka-performance-analysis.html


文章探討團隊使用 Kafka 的效能問題，團隊的 Kafka 每秒大概會有 300k 的訊息產生，同時有 1M 訊息被處理。
大部分情況下，所有的 request 都可以 ms 等級內解決，但是系統卻有長尾效應，P99 的結果大概要 1 秒鐘，而 P999 則需要 3 秒鐘。

整篇文章則是探討整個除錯過程，包含從初期的 tcpdump 去分析，後期導入 eBPF 針對更細部的去分析，最終找到問題跟節點上的檔案系統 (ext4) 有關，特別是某些操作會花費過多的時間去等待 lock 導致整個時間被拉長。

文章內最直得學習的就是如何導入 eBPF 這類型的工具來幫忙偵測這類型問題，而不是像過往一樣不知道如何下手

不常見但是可以幫助開發效率的 Git 指令與功能
https://martinheinz.dev/blog/109


本篇文章介紹一些自從 2010 後所被開發出來的 Git 指令。
大部分開發者慣用的指令幾乎都是都是早期版本就有的指令，包含 chcckout, stash 等，而隨者 git 後期的開發，實際上有愈來愈多的指令與功能被開發出來改善效率，譬如文章中介紹的
1. switch
2. restore
3. sparse-checkout
4. worktree
5. bisect

這些指令都有適合的情境，譬如同時有多個 branch 需要開發，或是一個 monorepo 的檔案過大，每次 checkout 都要花費大量時間等，因此花一些時間研究一下這些新的指令說不定可以加速日常工作流程

大名鼎鼎的 Brendan Gregg 最近發佈了一篇文章提及系統上應該要有的除錯工具，從 CPU, Memory, Disk 到 Network 應有盡有

這些工具可以從下面的 package 安裝，文章內有更詳細每個 package 會提供哪些工具，以及大概可以處理什麼樣的資訊

procps, util-linux, sysstat, iproute2, numactl tcpdump, linux-tools-common, bpfcc-tools, bpftrace, trace-cmd, nicstat, ethtool, tiptop, cpuid, msr-tools


https://www.brendangregg.com/blog/2024-03-24/linux-crisis-tools.html

Kubernetes 內各種 GC 介紹

https://medium.com/overcast-blog/kubernetes-garbage-collection-a-practical-guide-22a5c7125257


寫應用程式的都聽過 Garbage Collection(GC) 的行為，而 Kubernetes 也是有類似這種行為的操作，目的都是清除用不到的資源，避免系統資源超載甚至影響整體效能。
文章提及三種相關的 GC，分別是
1. Container Image Garbage Collection (節點上的 Container Image 用量超過硬碟用量，需要 GC 移除以免之後踩到 Disk Pressue 導致 Node NotReady)
2. Evicted Pod Garbage Collection (觸發 Evicted 而被移動的 Pod 雖然會消失，但是對 etcd 來說還是會有一個狀態為 evicted 狀態的 Pod，可以從 etcd 中釋放用不到的資源)
3. Orphaned Resource Garbage Collection (Kubernetes 內的狀態很多有相關依賴性，有些會透過 owner reference 來連結這些物件，某些情況下可能資源刪除沒有完整，導致有一些資源其實已經用不到，但是當初其老爸被刪除的時候沒有把這些產物給一起刪除，最後就是 etcd 記錄了一些用不到的物件)

除了概念介紹外，也有分別介紹每個類別的實作方式。

Kubernetes 節點效能調校分享
https://medium.com/overcast-blog/kernel-tuning-and-optimization-for-kubernetes-a-guide-a3bdc8f7d255


本文章主要探討若要讓 Kubernetes 節點能夠有更好的效能，要如何從 Kernel 方面去針對 網路/檔案系統/記憶體/CPU/行程排程 等這些方面去設定 Kernel 參數，並且每個參數所帶來的效果有哪些，此外也有提到設定的前提是要先有足夠的指標監控系統，透過系統長期觀察每個參數帶來的效果才算是有效的調整，否則如無頭蒼蠅般的設定並不算是真正的瞭解系統。
文章內列舉的參數包含
1. net.core.somaxconn
2. net.ipv4.tcp_max_syn_backlog
3. net.ipv4.ip_loacl_port_range
4. vm.swappiness
5. vm.overcommit_memory
6. vm.dirty_background_ratio
7. vm.dirty_ratio
8. fs.file-max
9. fs.inotify.max_user_watches
10. kernel.sched_migration_cost_ns
11. kernel.sched_autogroup_enabled

此外 k8s 過往是不支援 swap 的，需要 1.22(alpha), 1.28(beta) 後的版本才可以開啟 SWAP，文章中提到的 CPU Affinity/Management 的 YAML 我自己看起來是完全達不到 CPU affinity 的用途，畢竟該功能需要仰賴 Guarantee QoS 的 Pod 且 CPU StaticManager 要有開啟才有辦法，否則預設情況下 Container 的 CPU 是無法由固定 CPU 處理的。

Title:
Netflix 分享跨地區的網路效能除錯經驗
Source:
https://medium.com/@netflixtechblog/investigation-of-a-cross-regional-network-performance-issue-422d6218fdf1


Netflix 團隊中遇到一個跨地區的網路問題，Client Application 團隊初期覺得是網路問題，因此請網路團隊幫忙除錯，網路團隊藉由錄製封包等行為觀察出下列現象
1. Client 已非常固定的時間，啟動 30 秒後就會自己發送 FIN 去關閉連線
2. 檢查 Client & Server 的封包，發現 Server 回傳的封包都有順利送到，沒有任何 Packet Loss 的現象

由上述觀察，網路團隊認為問題應該是 Client Application 本身，因為是 Client Application 自己關閉網路連線的，但是檢查了一下，發現
1. Client Version
2. Server Version
3. Network Infra
上述三個版本短期內都沒有變動，甚至 Server 還是一年多前的版本，然後有觀察到 Client 內有設定一個 Timeout 30 秒的時間，若時間內沒有辦法收完資料就會關閉連線。

最後團隊開始懷疑這個問題是由 Kernel 導致的，經過一連串的實驗與觀察，最後發現這個問題真的跟 Kernel 升級有關，使用舊版本 6.5.13 的時候， Client 只要 22 秒就可以送完資料，但是升級到 6.6.10 的時候則需要 39 秒，就會超過 timeout 導致斷線。

文章最後有詳細解釋原因，主要是跟 TCP Receive Windows 的計算方式改變有關，有興趣的可以閱讀全文