Distroless base image 的好壞處

https://medium.com/@8grams/distroless-using-minimal-container-image-for-kubernetes-workload-9b143f83bd10

容器化的世界中一個非常重要的議題就是底層 image 的選擇，本篇文章仔細介紹 Distroless 的優缺點，其特性就是盡量減少無關之元件，相關特性有

1. OS 不提供任何 package manager
2. 只安裝真正需要的東西，不需要的都不安裝
3. 由於安裝的東西非常少，所以安全性方面會相對安全，需要專注處理資安/CVE的元件比較少
4. 連基本的 shell 存取都不安裝，因此發生問題時攻擊方也不能進入shell去執行相關指令

文章內有舉出幾個跟 Alpine 的比較，但是比較可惜的是沒有提到 Alpine 早年的各種 DNS 雷包問題

如何於 Kubernetes 實作 Topology-Aware Routing 讓彼此關聯服務的延遲性更低

https://medium.com/itnext/controlling-kubernetes-traffic-with-topology-aware-routing-9b1d51a43bd7

Kubernetes 於 1.23 後就正式 Beta 名為 Topology Aware Hints(已於 1.27 改名為 Topology Aware Routing) 的功能，以 ClusterIP 類型來說，目前有 InternalTrafficPolicy 可以設定成 Cluster/Local 兩者類型，然而這兩種類別不夠細膩。
本功能的目的是希望能夠以 Topology 作為轉發目標的選擇，這部分對於雲端使用者來說尤為重要，特別是某些雲端業者會針對跨 AZ(Available Zone)的流量進行收費，因此如果可以透過此功能去確保勁量將流量打到同 AZ 內的服務的話，不但可以省錢同時也可以有更低的 Latency。
至於 Topology 的定義則是由 label 去定義的，所以地端使用者也可以自行基於 Rack, Room…等實體類型去定義所謂的 Topology，透過此機制來調整轉發的選擇。
另外該機制本身也有所謂的檢查機制，若檢查機制沒有通過，則封包轉發就會退回最預設的模式，所以也不用擔心封包會因此被丟掉。

Cloudflare 探討轉移到 tcmalloc 對 Multithreading 應用程式記憶體控管帶來的好處

https://blog.cloudflare.com/the-effect-of-switching-to-tcmalloc-on-rocksdb-memory-use/

本篇文章探討了 Cloudflare 觀察到應用程式進行架構轉移後造成的記憶體用量暴增的情況，文章非常仔細的探討 Glibc Malloc 的實作原理，從 Arena, Chunk 等邏輯講解得非常清楚，也點出為什麼 Malloc 對於 Multithread 情境下很容易造成記憶體破碎的情形，最終導致浪費一堆用不到的記憶體(跟 OS 要一堆記憶體，實際上用到的非常少，更多記憶體就是被要來浪費，但是又沒有辦法歸還給 OS)

後半部分則是從 tcmalloc 出發介紹架構，其設計本身就是對 Multithread 的架構設計，因此使用上更能夠重複使用記憶體避免浪費，藉由簡單的切換就能夠讓應用程式
所需要的記憶體數量大幅減少，以 Cloudflare 的應用程式來說，整整減少了 2.5 倍。

Kubernetes 1.28 swap 支援進入 Beta 階段
https://kubernetes.io/blog/2023/08/24/swap-linux-beta/

由於 Memory Limit 實作的複雜度， Kubernetes 一開始就要求所有節點不能開啟 swap 這種使用硬碟空間暫代 Memory 的機制，然而某些使用情境下還是會希望有 swap 的支援，譬如
1. cgroupv2 實作更多關於 memory 的控制，然而部分的控制需要搭配 swap 才可以使用
2. 一些長期運行的 Java 應用程式可以透過 swap 獲得更好的效能
3. 對於某些會瞬間要暴增 memory 用量的應用程式，透過 swap 可以短暫提供足夠的 memory 來使用而不需要透過 resource 給予過多用不到的容量
4. ...etc

因此 1.22 後正式推出 alphe 階段的 swap 支援，而 1.28 則經歷不少功能改善與問題修復，正式邁入 beta 支援。
支援 swap 的精神就如同 Kubernetes 的一貫設計一樣，提供工具與方式，讓平台使用人員自己抉擇要不要使用，而非強硬寫死禁止使用。

五個分散式架構下的設計模式
https://www.educative.io/blog/distributed-system-design-patterns#load-balance

本文探討分散式架構下常見的幾種設計模式，每個設計模式都有期優缺點以及適合的場景，因此理解這些集結眾人之力的設計模式更多時候是學習眾人的經驗，減少踩雷的冤枉路，但是也要避免盡信書相信硬要把某設計模式套用到眼下所有情境。

文章介紹的五種設計模式分別為
1. Command and Query Responsibility Segrgation (CQRS)
Command 代表會改變系統狀態但是不會得到回傳的操作，而 Query 則是不會改變狀態但是會得到回傳值得操作。
大抵上可想像成讀寫分離的架構，其可以簡化整個系統的操作，但是讀寫之間的操作則可能會因為要更多來來回回而提高 latency

2. Two-Phase Commit
詳見: https://rickhw.github.io/2020/05/16/DistributedSystems/Distributed-Transactions/#Two-Phase-Commit-2PC
3. Saga
一種採用 Event-Bus 來交換訊息的非同步架構，可用來解決分散式架構下每個服務之間交易資料一制性問題的一種方式。
詳見 https://medium.com/程式愛好者/微服務-如何確定資料一致性-2adab03fdc7f

4. Replicated Load-Balanced Services
5. Sharded Services

其餘就詳見本文與其他網路資源

K8s log 消失於 Elasticsearch 的經驗談
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/


EFK 是個非常常見的 log 處理組合，其架構下日誌的處理流程相對清楚，但是問題發生時並不好處理與除錯，以作者團隊來說，總是會發生掉 log 的情況，大概會有幾秒鐘的 log 都消失，因此本篇文章就是探討這問題的發生原因以及如何避免

文章大抵上分成三段
1. 探討常見 container runtime (Docker, Containerd, CRI-O) 是如何處理應用程式的 log
2. 探討 kubelet 是如何搭配上述 container runtime 去處理 log 的
3. 探討問題的原因本質， 到底 Fluentd 發生什麼問題

(1):
Docker 與 Containerd/CRI-O 處理 log 的方式截然不同， Docker 提供各式各樣的 logging driver 來處理大小與 rotation 的規定，而 CRI-O 這類型的本身沒有這些參數與處理，全部仰賴上層呼叫者，也就是 kubelet 去自行處理

(2):
Kubelet 底層會透過 symlink 的方式來設定一個當前 log 的檔案，該檔案則會指向目前最新的 log 內容，譬如
/var/log/containers/*.log -> /var/log/pods/$pod_id/$latest.log

symlink 本身不會注意到 rotate 的情況，這意味當一直關注 "/var/log/containers/*.log" 時，若目標檔案發生 log rotate 後，原先檔案的後半部分還沒有讀取到就會因為 log rotate 而沒有辦法順利讀取了

(3):
Fluentd 預設的 k8s log parser 之前會踩到上次的問題，一直關注 "/var/log/containers/*.log" 檔案，當 Pod 快速產生大量 log 內容並且觸發 log rotate 時， fluentd
還沒有讀取完全全部內容並且轉送出去，這時候檔案就被 rotate 因此就會發生掉 log 的內容

該 k8s log parser 後來有修正問題來處理，因此使用較新版本的 fluentd 就不會有這個問題

五個提升 Kubernetes 資安的小概念與步驟
https://blog.palark.com/kubernetes-security-best-practices/

根據 VMWare 以及 Dynatrace 於 2023 的使用者調查報告， Kubernetes 叢集的落地數量於雲端與私有地端都是逐年增加的趨勢，任何使用情境與規模都慢慢地轉往 Kubernetes 環境，同時根據 Red Hats 的 2023 Kubernetes Security 報告也顯示， 有 90% 的受訪者於過去一年內都有遇到 Security 的相關案例，且有 67% 的受訪者因為 Security 的關係目前正在趨緩全面導入 Kubernetes 的節奏

Kubernetes 本身是一個強大的平台，然而 Security 的導入並非一日工程，本身就是一個逐步提升與改善的流程，團隊開發者與應用程式開發人員需要互助慢慢協調找到一個彼此都舒適的節奏來調整所有流程，從 YAML 的撰寫到後期存取平台除錯等，每個環節其實與資安息息相關。

以 Security 來說，目前最知名的範本就是由非營利組織 CIS 所推行的 Kubernetes CIS Benchmark，也有相關的開源專案如 Kube-becnh, Kubeescape 等工具去實作 CIS Benchmark 來檢查你的 Cluster 並且提供相關報導。此外一個名為 PCI SSC(Payment Card Industry Security Standards Council) 的組織也發布了一個關於容器調度平台應該要注意的資安條件，該組織的組成來自 VISA, MasterCard 等金流相關的應用，因此資安方面也是極度重視。

文章內從五大點列出 Kubernetes 要著重的點，每個點都有很多細節探討，譬如
1. Proper Configuration of Kubernetes Clusters
2. Image Scanning
3. Networkg Security
4. Controlling Running Application
5. Auditing and Event Logging

簡述 Consistent Hashing 的概念與應用
https://www.toptal.com/big-data/consistent-hashing

Consistent Hashing 是一種基於分散式架構下的 Hash 演算法，主要應用於動態環境中，將 Hash 的請求或是資料給分散到不同節點(伺服器)上，但是當節點數量有任何增減時又要確保 Hash 的功能不會變影響。
舉例來說，假設本來系統有三台機器負責處理 Hash 後的結果，因此 Hash 演算法會使用 Mod 的概念將所有資料給分散於三台機器上

Value. Hash(Value). Mod 3
abc -> 13 -> 1
def -> 12 -> 0
geh -> 11 -> 2

假設今天因為流量等各種變化使得機器的數量變成 4 台，那這樣 Mod 的概念是否要改成 (Mod 4)? 若不改則新的機器就沒有辦法接收資料處理，若改成 Mod 4 則所有資料對應的機器都會改變
這樣會造成大量的 cache miss 最後影響整個系統效能。
Consistent Hashing 的目的是改善這個流程，當有任何節點更動時，目前既有的資料只有少部分會需要更動，其餘無關的都可以繼續保留本來的規則，而整體規劃都會牽扯到一個環，用環的概念來區分每筆資料應該由誰去處理，以及當節點數量增減之時該如何處置

三個 Kubernetes Nginx Ingress Controller 的 CVE
https://thehackernews.com/2023/10/urgent-new-security-flaws-discovered-in.html

Nginx Ingress Controller 最近有三個相關的 CVE 可以讓攻擊者有機會透過 Nginx Controller 來獲取叢集內其他的 secret 物件
這三個 CVE 一個是關於 Ingress 物件中 Path 的驗證問題，另外兩個則是跟 annotation 有關

目前的修復方式是將 NGINX 升級到 1.19 版本以後並且運行的時候加上 “–enable-annotation-validation” 的參數加入對 annotation 的驗證
若有要使用 NGINX 的情況則要注意下是否會踩到這些 CVE

Doordash 探討導入 Microservice 遇到的種種挑戰
https://blog.quastor.org/p/scaling-microservices-doordash

Microservice 出發點非常好，透過將元件分開並且獨立擴展讓整個系統可以更有效地去根據需求擴展，然而 Doordash 將服務轉移到 Microservice 的過程中則是遇到了各式各樣的問題
，而這些問題幾乎是所有 microserviec 架構下都會遇到的問題，包含

Cascading failures
Retry Storms
Death Spirals
Metasable Failures
這類型的錯誤幾乎都是因為現在服務之間的溝通從本來 Process 的溝通轉變為跨網路的服務呼叫，只要彼此之間因為網路或是各種原因出現短暫問題，就可能導致相關的服務依序出現錯誤
雖說透過 Retry 機制似乎可以解決，但是沒有妥善處理這些 Retry 的流量可能會使得系統更加惡化

因此其內部也透過 Circuit Braking, Load Shedding 以及 Auto-scaling 等機制來進行管理

最後也提到如何使用 https://github.com/fluxninja/aperture 這套開源專案來根據流量以及服務狀況來進行服務存取控制

Hashicorp Vault 因為授權問題而產生分歧
https://wiki.lfedge.org/display/OH/OpenBao+%28Hashicorp+Vault+Fork+effort%29+FAQ


Hashicorp 之前的授權更改於整個開源圈造成一股議論，最後社群直接 Fork Terraform 並且捐贈至 Linux Foundation 來進行社群運營，並且命名為 OpenTofu

如今 Hashicorp Vault 也發生一樣的命運，社群不滿授權機制，因此又 Fork Vault 並且一樣捐贈至 Linux Foundation 底下去進行發展，這次的名稱叫做 OpenBao

先撇開整個社群之間紛紛擾擾的貢獻議題，我更好奇的是
一下豆腐，一下包子...下一個是油條還是飯糰？

Kubernetres v1.28 non-graceful shutdown 探討
https://medium.com/@anavsaraf/kubernetes-planternetes-v1-28-non-graceful-node-shutdown-feature-8608d5073519

Kubernetes 於 1.24 推出， 1.26 轉往 Beta 的Non-GracefulNode Shutdown 功能 功能正式於 1.28 轉入穩定版本，該功能的目的是提供一種更好的機制去處理未預期節點狀況下的 Pod 生命週期。

該功能的誕生是希望能夠有效處理當 Kubernetes 節點不預期掛掉時發生的管理問題
以 StatefulSet 的應用程式來說，其本身因為講求狀態，所以必須要避免任何時間點有兩個重複的 Pod 出現，因此若需要更新其流程預設都是先砍掉舊的，然後重新部署新的。

但是對於非預期關機的節點(斷電，硬體壞掉等情境)來說，由於 Kubelet 沒有辦法正確回報狀況，所以這類型的 Pod 就會長時間處於 Terminating 的狀況，沒有辦法順利被回收，因此新的 Pod 就沒有辦法被創建起來。

此外 Volume 的部分也會因為 kubelet 卡住的關係，導致 Volume 沒有辦法順利的 detach，因此非預期的節點關機對於 stateful 的應用程式來說會有兩個痛點
1. Pod 卡在 Terminating ，新的 Pod 長不出來
2. Volume 卡住，無法順利 detach，新的 Pod 也用不了

於是 non-graceful shoutdown 的功能被引入 Kubernetes 希望能夠針對上述情境提供解法
目前的解法是需要人工介入，當節點發生問題時，只要快速地對該節點加上一個
node.kubernetes.io/out-of-service 的 Taint(NoSchedule or NoExecute)，內建的 Controller 就會立即的強制移除相關的 Pod 並且執行 Volume Detach 的動作來釋放相關資源，讓 stateful 的應用程式可以更快的於新節點重新部署來提供服務

如何於 Kubernetes 內動態掛上一個除錯專用容器
https://medium.com/datamindedbe/debugging-running-pods-on-kubernetes-2ba160c47ef5

Kubernetes 管理人員通常要對 Pod 進行除錯時，很常會使用 kubectl exec 等指令直接跳到 Pod 裡面去檢查當前的運行狀況。
kubectl exec 可以說是每個 Kubernetes 玩家都必定會且非常被大量使用的指令，但是該指令實際上會有一些限制

進去後的身份與指令實際上是仰賴於最初運行的容器狀態
由於上述的限制，所以到底有哪些指令可以運行非常仰賴當初打包 Image 使用的基底與指令，譬如使用 alpine 與 scratch 可以使用的指令與安裝方式就有非常大的不同，甚至有些環境連基本的 shell 都沒有，這種情況下除錯
此外現在愈來愈多的容器會以 non-root 的方式去執行，但是除錯的除錯的時候就是需要使用 root 來進行一些指令操作除錯，因此 kubect exec 這種直接繼承本來使用者身份的方式對於除錯來說稍嫌無力
為了解決這個問題， Kubernetes 官方提供了 kubectl debug 的指令，該指令可以動態的創建一個暫時 Container，並且將該 Container 掛載到任何選擇的 Pod 來進行除錯，該短暫 Container 可以共享既有的 Process namespace, network namespace 等，同時其所運行的 userID, groupID 則不受本來運行之限制，且該短暫 Container 的 Image 也可以自行選擇，所以就可以掛上自己常用的除錯 Container 來除錯。
該指令目前的缺陷就是預設的情況下無法共享 mount namespace，因此如果除錯的過成需要去觀看檔案系統的話，這方式會有點無力，因此文章提到可透過 patch 的方式動態的去修改 Pod spec，將 volumeMount 的資訊填上，該流程也被第三方包成一個 superdebug 的指令

此外還有其他工具如 kpexec 等都是想要強化既有 kubectl exec 的缺陷與限制

Container Runtime 抓取 Container Image 的過程介紹
https://itnext.io/exploring-oci-container-registries-by-use-case-pull-a-public-image-from-kubernetes-3d2d4267201c


過往使用 Container runtime (Docker, Containerd, CRI-O) 時，大家總是會學習到 Contianer Image 本身有快取的機制，能夠透過快取機制減少不必要的檔案抓取。此外 Kubernetes 內也有提供 ImagePullPolicy 等機制來設定抓取 Image 的策略。
本篇文章稍微探討了一下抓取 Image 中間的過程，包含

先從遠方 Repository 伺服器獲得該 Image 的一個小ID
確認本地有沒有該 ID 的 Image，有的話就代表本地擁有，不需要重複抓
若本地沒有，就代表需要抓取該 Image
接者就會去抓取該 Image 的第二層資料，該資料內會提供該 Image 用到的所有 layer 資訊
接下來每個 layer 獨自判別，若該 Layer 本地已經有快取，那就使用本地資料，否則從遠方抓取
從這個流程來看，本地沒有 Image 去遠方抓取並不代表是真的要去遠方抓取，若 Image Layer 本地已經有的情況下，部分 Layer 的抓取也是可以加速的，這意味如果以後要提高 Image 抓取的內容，除了探討 Image 本身的設定外，也許 Image Layer 的部分也值得研究看看，是否可以透過這些機制來降低每次抓取新版所需要的資料量與時間。

如何於 Bash 環境中產生有結構的 log
https://medium.com/picus-security-engineering/structured-logging-in-shell-scripting-dd657970cd5d

本篇文章作者探討如何使用 tail + bash redirection 等的方式來改善 bash script，讓檔案的輸出更有結構且能夠將個人的除錯 log 與指令的輸出有一個比較好的結構去分離，甚至可以加上不同的 log level，同時這些 log 可同時存放於檔案與 stdout 中。

為了讓 bash 運行過程的輸出可以同時寫到檔案與 stdout，作者於檔案內透過 tail 與 exec 的方式，後者會將該 script 內所有的 stdout/stderr 都導向特定檔案，同時透過 tail 的方式將檔案讀出給轉向 stdout 讓指令呼叫者也可以觀察到 log 的輸出。
有了基本機制後就是撰寫各種 wrapper function 來處理自己輸出的檔案格式。

如何透過幾種常見的 Image Cache 工具來加速 Kubernetes 內抓取 Image 的速度

https://medium.com/itnext/improve-container-image-availability-and-speed-with-caching-in-kubernetes-870fa7bfa1ed


Kubernetes 內應用程式從部署到真正運行中間所消耗的時間，有一段是仰賴於節點要花多少時間去抓取 Image，對於大小只有幾百甚至幾十MB 的應用程式來說
抓取 Image 的時間都非常的快，但是當有 Image 本身大小達到GB等級，同時節點上同時有多個 Pod 同時下載，這時候若超出平行下載限制時就會發生排隊等待的現象
最後就會導致部分應用程式花過長的時間才起來

這些流程對於更新應用程式來說也許不算什麼，畢竟既有的服務還在運作，但是對於節點掛掉或是 drain 的過程來說就會有比較大的影響，因為當下沒有服務正在運行，因此要如何更快速的
讓 Pod 被叫起來是一個值得關注的議題

本篇文章專注於如何加速 Image 下載的流程，介紹了下列幾個開源專案，每個專案都用不同的方式與架構來加速，包含
1. Kube-fledged
2. kube-image-keeper (kuik):
3. kubernetes-image-puller
4. Tugger

概念上大同小異，但是實作方式與目的都有些許不同

回顧 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 藉此熟悉與練習相關工具的使用。