標題: 「Istio 迎來 sidecar less 的架構，全新 ambient mesh 的宣布」
類別: Network
連結: https://istio.io/latest/blog/2022/introducing-ambient-mesh


Istio 於上週宣布其新架構的推出，Ambient Mesh 是基於 sidecarless 全新架構，有玩過 istio 的朋友一定都知道為了達成 istio 內各種如流量管理，mTLS等功能，實際上每個應用程式旁邊都會部署一個基於 envoy 的 sidecar 容器，該容器會無縫的截取相關網路流量並且進行後續處理來實作各式各樣功能。

還記得在數個月前當 cillium 宣布要以 eBPF 打造一個無 sidecar 的全新 service mesh 時就有很多討論，其中最大的就是 sidecar 是必要的，沒有辦法變成 node 層級的 agent 來處理各種 service mesh 需求。

而如今連 istio 自己都跳下來要嘗試進行 sidecarless 的修正，該架構主要會將整個架構分成兩個層級，分別處理 l4 與 l7 不同的流量，其架構也有些許不同。
lecel 4 會基於節點為單位的 agent 搭建一套 zero trut tunnel , 而 l7 的設計考量到 enovy 本身沒有多租戶的設計，擔心流量會互相吃掉影響，因此對應的 webproxy point 架構因應而生。

目前整體還是測試階段，團隊希望透過這個方式未來可以讓使用者有更平緩的導入過程同時也可以避免 sidecar 佔用過多系統資源

標題: 「用 YAML 控制 Netlink... YAML 工程師大躍進嗎」
類別: Network
連結: https://lpc.events/event/16/contributions/1347/attachments/1022/1982/YAML%20Neltink.pdf


本週於 Dublin 舉辦的 Linux Plumbers Conference 看到一個有趣的專案發想，該專案 YNL 的全名是 YAML Netlink，其目的是想要透過 YAML 的方式來控制 Netlink

Netlink 是目前 Linux Kernel 非常重要的系統，讓 User 與 Kernel 間可以透過其來交換各種網路相關訊息，從讀取到控制都應有盡有
而這個專案採取的方式是讓使用轉撰寫基於 YAML 格式的敘述，接者將其轉換成底層 Netlink 真正所用的協定格式並與 Kernel 互動

除了連結的投影片外，底下也有該場次的錄影分享
https://www.youtube.com/watch?v=9QkXIQXkaQk&t=2640s

標題: 「基於 ebpf 的輕量級微服務監控服務 」
類別: Network
連結: https://github.com/coroot/coroot

隨者 ebpf 的蓬勃發展，愈來愈多應用嘗試透過 ebpf 的概念來實作不需要動到應用程式的監控解決方式，老實說這方面的類型非常多，基本上都會包含譬如
1. 微服務之間的呼叫關係，這部分通常都會基於網路拓墣的概念去展現彼此之間的呼叫關係，能夠幫助管理員釐清整個網路流量走向
2. 微服務之間的流量分析，從基本的 L4 到 L7 等，能夠直接列出更詳細的封包內容
3. 內建 Tracing 概念來揭露單一流量橫跨不同微服務所花費的時間，能夠幫忙找尋可能的效能瓶頸
4. ...等

除了 ebpf 官網所列舉的各種服務外，本篇文章分享的是一個相對的輕量級解決方案，除了上述的基本功能外，其有針對 PostgreSQL 進行特別整合，能夠列出到底是哪些 Query 產生大量的資源消耗，同時針對 lock 等也可以列出更多幫助除錯的資訊

標題: 「一張幫助 SRE 快速理解所有大廠最新消息的整理網站」
類別: Other
連結: https://www.sreboard.com/


該網站簡單直白，自動幫你追蹤相關網站/社群/知名部落格等最新文章，譬如
1. Ansible
2. CNCF
3. AWS
4. Docker
5. GCP
6. ...等

我覺得如果可以培養成習慣，也許可以每天上班前快速的瀏覽一下有什麼最新消息直得注意也是一個不錯的方式

標題: 「幫助重構 Terraform 減少大量 move 語法的開源專案 tfautomv」
類別: Other
連結: https://github.com/padok-team/tfautomv


Terraform 自從 1.1 後有支援一個名為 move 的特殊語法，該語法的用途是當你今天需要因為團隊規模或是其他因素想要針對 Terraform 進行重構而提供的一種特別語法。
舉例來說，假設之前透過 Terraform 內創造一個 aws_instance.a 的物件，但是重構後需要將該名稱給換成 b，之前的命名不夠精準。
預設情況下直接改名稱， Terraform 會認為這兩個是不同的物件，因此會幫你把 aws_instance.a 給刪除，並且重新創建一個 aws_instance.b。
但是會想要進行重構的團隊鐵定不想要運行的架構整個被砍掉，所以透過這個新的 move 語法就能夠告知 Terraform 這兩個物件需要轉移，請把所有跟 aws_instance.a 有關的物件都視為 aws_instance.b
而本文介紹的專案 tfautomv，顧名思義， TerraForm Auto Move，就是要幫助開發者可以更輕鬆地去使用 move 語法來重構與調整整個 TF 資料夾與程式碼。
如果有重構需求的也許可以看看這個專案會不會有幫助

標題: 「從 GPU 使用者的角度來看，為什麼 AWS 與 GCP 大不同」
類別: Other
連結: https://freeman.vc/notes/aws-vs-gcp-reliability-is-wildly-different

這篇文章是作者要探討從 AWS/GCP 不同平台去要求 GPU 的心得，作者於兩週的時機陸陸續續地去要求 T4 GPU 卡，最終數量達到三千張。
文中唯一的圖片就是要求 GPU 的效能分析，主要是要探討要花費多少時間才可以獲得一張可用的 GPU 卡
圖中去觀察可以看得到
1. AWS 所需時間非常快且非常穩定，基本上就是一條直線
2. GCP 所需時間久且不穩定，時間跳來跳去

AWS 平均不到 15 秒，而 GCP 卻要 42 秒左右，此外從發生錯誤的角度來看，整個過程 AWS 只有發生一次錯誤，而 GCP 卻發生了 84 次的錯誤。
所以從整體結果來看，作者認為如果你今天有任何因為需求而即時加開 GPU 的可能性的話，實在想不到用 GCP 而不是 AWS 的理由
詳細介紹可以參閱全文

標題: 「以 Terrafrom 來控管 Grafana Alert」
類別: Other
連結: https://grafana.com/blog/2022/09/20/grafana-alerts-as-code-get-started-with-terraform-and-grafana-alerting/

通常使用 Grafana + Prometheus 組合包的人都會面臨一個問題，就是告警的部分到底要使用 Prometheus Alertmanager 還是 Grafana Alert，兩者各有各的好處以及優缺點
特別是當你 Grafana 整合 loki 同時處理 log 時就能夠透過 Grafana Alert 針對 log 訊息來觸發 alert，整體會更加靈活。

不過過往使用 Grafana Alert 的時候如何去維護這些設定檔案則是一個困難事情，雖然透過 YAML 可以很順利的將 Grafana 給搭建起來，但是對於其內部的設定還是仰賴手動設定來處理
而官方介紹的 Terraform provider 則是介紹如何透過 TF 來設定你的 Grafana Alert，如果可以順利整合到 TF 中，那透過 Git 管理搭配 CI/CD 來自動化管理 Grafana Alert 似乎就不是個問題，也許能夠減少更多手動設定的部分，有興趣的歡迎研究看看

標題: 「Terraform: Up & Running 書籍第三版簡單概述 」
類別: Other
連結: https://blog.gruntwork.io/terraform-up-running-3rd-edition-is-now-published-4b99804d922a

本文作者就是本文要探討書籍的作者，Terraform: Up & Running 該書籍收錄與整理了實務上 Terraform 會遇到的各種問題以及對應的解決方式，此外本篇文章也發布於 Gruntwork 上，而 Gruntwork 最著名的專案莫過於 Terragrunt 以及 Terratest，因此該團隊對於 Terrafrom 的開發與應用上並定累積了很多實務上的想法，這類型的想法也當然了變成上述兩套開源軟體開發的動力與目標。

本文簡單地從第三版的書籍中裡面挑選幾個常見的問題來介紹，包含
1. Validation: 如何透過 validation, precondition, postcondition 等功能來來進行部署前後的檢查
2. Refactoring: 如果需要針對 resrouce 重新命名與改變，新版要如何透過 move 來搬移這些資源
3. Static Analysis: 除了真正執行你的 TF code 來達到測試外，不執行的靜態測試有哪些工具可以執行，這類型的工具又有哪些的差異及特色
4. Policy Enforecement: 近幾年流行的 Policy as a code 要如何整合到 TF 環境中，如果團隊中針對 TF 部署的資源都有相關的 policy 要遵守，這類型的 policy 要如何整合到 TF 的開發與部署週期


文章中針對這幾個區塊有更詳細的介紹，包含每個問題以及相關解法，Terraform 重度使用者推薦看一下這系列文，甚至可以考慮購買一下原文書來閱讀

標題: 「ArgoCD v2.5 release preview 」
類別: CICD
連結: https://blog.argoproj.io/argo-cd-v2-5-release-candidate-e2121f2002ba


距離 2.4 正式釋出才短短四個多月，現在 ArgoCD 近日就推出了 2.5 的 preview 版本，這次的 2.5 版本除了基本的文件與臭蟲外，新增了高達 58 項的新功能與改正，這些功能包含
1. Beta Support for Server-Side Apply
1.22 所正式 GA 的 Server-Side Apply(SSA) 將被引入到 ArgoCD 的更新策略中，SSA 天生的特性使得其更適合去透過 dry-ryn 來預知錯誤同時更新檔案內的過程中還有機會可以減少步驟
2. API and CLI Support for ApplicationSets, and Advanced Templating
使用 API/CLI 的開發者目前都可以透過這些介面來操控 appset 這類型的資源，譬如指令 "argocd appset"，此外 appset 本身也強化其 template 的部分
4. New Project-Level Restrictions
部署資源到 Project 的時候現在加入 ! 這個反向指示的用法，可以針對如 cluster/namespace 的資源來達到更靈活的控管，譬如資源只能部署到特定 namespace 以外或是 cluster 以外

5. Better Network Security
目前預設情況下 ArgoCD Server 與內建的 Dex 之間的流量都預設加密，此外如果 CNI 有支援 NetworkPolicy 的話，其 ingress/egress 的規則也被重新改寫，新改寫的規則更加精準也嚴格，期盼能夠提升整體網路安全性。



有使用 ArgoCD 的讀者可以稍微看一下 release doc，有多餘機器的也可以嘗試使用看看 v2.5，看看是否有解決什麼目前 2.4 遇到的困境，有任何問題也都可以回饋給官方讓官方一起改進

標題: 「基於 Rust 開發的各種CLI替代工具」
類別: tools
連結: https://danielgafni.medium.com/the-modern-linux-cli-stack-46253688b53d

本文作者想要分享各種基於 Rust 開發的各種跨平台工具，這些工具與過往常用的工具比較起來到底哪些對於日常生產力有更好的提升與幫助

舉例來說，作者目前常用的組合技如下
shell: zsh
plugin manager: oh-my-zsh / antigen
prompt: powerlevel10k
terminal multiplexer: tmux

上述工具替換到 Rust 為主的新工具則有下列選擇

shell: nushell
prompt: starship
terminal multiplexer: zellij


文章後半段則針對 nushell, starship, zellij 等工具進行簡單介紹，此外還有一些強化工具，譬如 bat(cat強化版) 等


這類型的新工具目前看起來最大的改變就是視覺化的方式呈現，這部分則就很看人的使用情境，如果平常的使用很仰賴 | .... 等各種工具串接的話，也許這類型的視覺化就沒有太大誘因，此外另外一個特別的點是設定，文章有提到這類型的工具設定起來都愈來愈簡單，甚至可以透過 Yaml/Toml 等格式來設定

有興趣的就可以針對這類型工具去玩看看


https://medium.com/swlh/break-down-kubernetes-server-side-apply-5d59f6a14e26

https://danielgafni.medium.com/the-modern-linux-cli-stack-46253688b53d

標題: 「別人用 AWS 不代表你要用 AWS」
類別: usecases
連結: https://www.karlsutt.com/articles/you-should-not-be-using-aws/


本篇文章不是一個深度技術文，不過更像是一個文化潮流的省思文，文章中以 AWS 為範例去闡述現在的潮流就是「成功的人用，我也要用」的思維
文中提到「Just because Netflix, which accounts for about 15% of the global internet traffic, has built a complex architecture of custom software and microservices on top of a popular public cloud provider does not mean you absolutely, positively have to replicate their setup.」

想想你的應用規模跟架構，再想想 Netflix 跟你的差異，你真的覺得你需要一開始就打造跟 Netflix 一樣的底層架構嗎？

此外作者還提出一個迷思概念，很多使用最新技術的案例其實成功的原因不是「使用最新最潮的技術」，這些「最新最潮的技術」只是剛剛好被用到而已。
最後文末有三個概念提出分別是
1. Optimise for operational simplicity
2. Optimise for internal simplicity
3. Focus on delivering value to your users

有興趣的可以閱讀全文

標題: 「從 SRE 的觀點來看，如何打造一個對開發也對維運都有好處的軟體服務」
類別: usecases
連結: https://www.willett.io/posts/precepts/


作者汲取這多年來參與不同規模團隊合作下的經驗，思考如何打造出一個更適合維運的應用服務，這些經驗的目的並不是打造一個 100% 完美絕對穩到炸不會出包的服務，相反的
更注重於「如何透過 20% 的努力來獲得 80% 的可靠性，同時開發人員也不會覺得窒礙難行」

文章主要分成四大項，分別是
Coding
Merging
Deploying
Operating

每大項內又有幾個小項目分別舉例，這邊稍微汲取幾個範例與想法，作者的每一個想法不一定適合每個團隊，不過可以聽取看看不同人的想法來想想這些提到的優缺點目前團隊工作流程是否有出現？ 有的話應該要怎麼解決？或是現有的解決方式是否有改進的空間？

# Coding
No in-code fallbacks for configs -> 如果你的應用程式運行初期讀取不到任何應該要讀到的設定時，就應該儘早死去來達成 fail fast, fail early 的概念， config 往往會決定應用程式的行為，不會動或是缺少設定的話就及早自殺，讓整個問題可以更快被發現，最害怕的就是明明少了一個重要的 config 結果該 config 相關的程式碼要到重要時刻才會被執行到，然後整個爆炸時間點就被延後，最後還要花費更多的時間與精力去找問題發生點

Avoid state like the plagu -> 有狀態的程式其管理複雜度不是無狀態程式可以比擬的，就算有了各種容器管理機制整體複雜度還是非常高，能的話將這些狀態都送往 DB/Cache 去處理，盡可能打造一個好維護的無狀態程式

Never give up on local testing -> 相較於 CI 等自動化測試等流程來說，本地測試所需的時間其實更少，從消耗時間來看是能夠提升開發者生產速度的，然而本地測試相對麻煩的就是環境的建置，因此有機會的，可以嘗試透過容器化的方式來系統化建置測試環境，讓開發者都可以一邊開發一邊本地測試。


# Merging
For infra changes, make plans extremely obvious -> 想辦法讓任何 infra 的改變是顯而易見可預料的，譬如使用 Terraform 進行管理的團隊最好將 terraform plan 的結果整合到 CI 與 Review 的過程中，這樣大家都可以一目瞭然到底這次的修改會產生什麼樣的變化，同樣的對於 Helm 應用來說，可以透過第三方plugin, Helm diff 來幫你檢視一下當前版本與即將升級版本的差異，到底有哪些資源會被創立哪些資源會被移除。


# Operating

Use Helm -> 使用 Helm 或是其他如 kustomize, jsonnet...etc 等工具來管理 Kubernetes 檔案，非特殊情況不要一直透過 kubectl apply/edit/delete 等來管理應用程式的部署狀況，所有的部署情況都應該可以被追蹤與管理

Avoid operators and CRDs -> Kubernetes 好棒棒，但是對於開發者來說，從 Container 到 Kubernters 的鴻溝太大，這中間的學習過程一旦扯入了 CRD 就會有更多未知的事情發生，所以作者認為能的話盡量讓事情保持簡單，減少用 operators 等機制這些增加複雜性的東西

標題: 「由 Google 開發的 Kubernetes Queue 開源方案: Kueue」
類別: Kubernetes
連結: https://kubernetes.io/blog/2022/10/04/introducing-kueue/

本篇來自官方部落格的文章要介紹的是由 kubernetes-sig 底下所開發的專案, Kueue 是一套專門針對 Kubernetes Job 的 Queue 管理開源解決方案

Job queueing 是一個不論是地端或是雲端都可以用到的功能，將 Kubernetes Job 給進行佇列排程確保當前有限的系統資源可以依序的被這些 Job 存取
而 Kueue 則是基於 Job 這個運算單元上提供了 Job queueing 的功能，可以決定哪些 Job 要馬上執行，哪些要等待以及哪些資源要被這些 Job 給存取。

文章提到幾個 Job queueing 希望達到的功能有
1. 多租戶環境下希望每個租戶的能夠使用的資源是公平分配的，譬如不活躍租戶底下的資源可以暫時借給其他活躍的租戶去運行
2. Job 可以彈性的根據不同環境來配置不同的資源用量，譬如 spot/on-demand，或是有不同型號的 CPU/GPU 等
3. 能夠根據資源的配置而自動擴展

原生的 Kubernetes 的 Job/Cronjob 功能非常單純，所以需求都要仰賴其他解決方案，而 Kueue 認為這些解決方案的問題都是他們都必須要替換掉現存穩定的 kube-scheudler/job-controller，這些可能會造成
維運上的問題甚至是造成 job APIs 的複雜化，所以如果可以從原生內部直接支援，對於所有使用者來說則是會更好的使用方式


有興趣的可以閱讀全文來研究看看這個開發中的專案

標題: 「Istio Ambient Mesh 初體驗」
類別: Netowrks
連結: https://medium.com/@ridgway2/trying-istios-ambient-mesh-3497949aba46

不久前 Istio 宣佈一個基於 sidecarless 的全新實作專案 Ambient Mesh，而本篇文章就是嘗試玩看看 Ambient Mesh 的一些踩雷心得。

Ambient Mesh 的目標就是透過 Daemonset 來取代過往每個服務獨立配置一個 sidecare 的架構，透過該 daemonset 來處理所有的流量並提供過往的如 mTLS, traffic engineering 等功能。
從好處來想系統資源量會獲得大量的釋放，不需要為每個 sidecar 提供相對應的 CPU/Memory，但是單一節點是否會有額外的效能瓶頸以及 Signle Point of Failur 則是另外一個隱憂

該 Ambient Mesh 專案現階段還屬於開發測試中，所以單純玩玩還不要著急上到任何正式環境，有興趣的就多給一些時間並且長期關注即可

本篇文章提到如何透過 KIND 搭建一個測試環境，並且於該環境上去部署 Ambient Mesh 並且部署測試用服務
對於 Ambient Mesh 想要玩玩的也許可以參考這篇文章快速搭建環境，並且實際觀察一下系統差異以及針對兩種架構設計一致的實驗環境，這樣更可以比較出兩種的差異性

標題: 「SOPS 一套讓你肉眼即所得的 Secret 編輯器」
類別: Tools
連結: https://medium.com/4th-coffee/a-comprehensive-guide-to-sops-managing-your-secrets-like-a-visionary-not-a-functionary-9ceefee917d

不知道你是否曾經因為某些條件與情境，想要將一些機密資訊放到 git 等相關可以供團隊共同使用的環境下?
Kubernetes 中的 secret 物件可以透過 sealedsecret 的方式對齊加密，但是這類型的用法只限定於 Kubernetes 應用
想要更常態性的加解密支援可能就會出現如 Git-Crypt 這類型的專案，與 Git 整合透過 GPG Key 針對特定檔案加密，只有被設定相關 GPG 的使用者才有辦法解開這些內容來進行讀取。

這類型的工具操作通常加解密都需要兩個步驟
編輯檔案內容 -> 加密
解密->閱讀檔案內容

該兩步驟乍看之下沒有任何問題，但是對於某些極度資安管理的環境就有可能會有小漏洞，譬如某使用者閱讀完檔案內容後忘了加密回去，導致系統掃到某人資料夾下有些機密資訊，最後觸發相關安全性警告

而本文的 SOPS (Secret OPerationS) 就是由 Mozilla 所開發的替代工具，將上次兩個步驟給整合，是一個可以針對檔案內容去加解密的工具。
跟 Git-Crypt 直接將整個檔案進行加解密完全不同， SOPS 加解密的目標則是 YAML/Json 內的欄位，這意味對於使用者來說你可以明確知道該欄位的 Key 是什麼，而 Value 則會被進行加密處理。
整個使用邏輯非常簡單，當該檔案被 SOPS 進行加密後，接下來所有指令去閱讀檔案都會得到加密後的內容，只有透過 SOPS 的內建編輯器去讀取才可以得到解密的結果，這意味者就算將該檔案給放到 Git 上，使用者看到的是針對"Value"加密後的結果，相對 git-crypt 是整個檔案加密， SOPS 的方式會適當的揭露該檔案格式與用法(好壞不一定)。


此外 SOPS 除了基本的 GPG Key 加密方式外，還支援不同服務，如

1. AWS KMS
2. GCP KMS
3. Azure Key Vault
4. HashiCorp Vault

基本上三大公有雲外加知名度超高的 HashiCorp Vault 都有支援，所以如果環境中本來就有使用這些服務的話，使用者就可以更輕易去整合與管理使用的 Key
文章基本上就是介紹這個工具並且示範跟上述每個類別的使用方式與整合，如果對於這個專案覺得有點興趣的，可以快速看一下本篇文章該工具是什麼以及怎麼使用

標題: 「以 kube-bench/kubescape 為基準示範如何用逐步打造 DevSecOps 」
類別: Tools
連結: https://medium.com/@sdevsecops/how-to-implement-devsecops-in-a-kubernetes-cluster-environment-github-actions-and-azure-devops-522bdd121e34

這年頭除了 DevOps 外，愈來愈多的變形名詞被發明出來，當然每個名詞背後都有自己想要解決的問題，特別是當整個生態環境都往自動化與容器化發展後，整個 SDLC(Software Development Life Cycle) 也必須要因應而變，而其中 DevSecOps 這個名詞也是逐漸浮上檯面。
其中很多文章都會提到所謂的 Software Supply Chain，當整個環境架構整合到 Kubernetes 或是相關容器化平台時，整個軟體供應鏈的長度就愈來愈長，從應用程式本身的測試與編譯，到相關 Container Image 的建立，到相關 YAML/JSON 資源狀態的敘述與安裝最後到目標平台運行起應用程式。

每個階段除了基本目標外，還有如相依性軟體本身的安全性，平台面對使用者的權限操作等各種安全性議題要探討，所以要真正實作一個完整的 DevSecOps 沒有這麼簡單也不是一兩個工具就可以搞定的，就跟所有的架構開發一樣，都是由小出發，慢慢根據需求進行改良與調整。

本文前面探討了些關於安全的一些議題，提到了由 CIS 所制定的資安相關 benchmark，以及示範的相關工具，分別是 kube-bench 以及 kubescape，至於後半部分如何使用這套工具於
Github action 則不是太重要。

Kube-bench 則是一套以 go 撰寫且基於 K8s CIS benchmark 的掃描工具，該專案目前星星數也有5.3k左右，至少可以說明關注度不太低，至於該工具到底檢查哪些設定這部分則要直接去看 CIS Benchmark，該網站內有針對 kubernetes 去進行探討什麼樣的設定是安全，什麼樣是不安全。

kubescape 則是希望針對目標 kubernetes cluster 提供一套更為清晰的分析工具，包含
1. 運行的容器是否有潛藏的 vulnerability
2. 視覺化當前叢集中 RBAC 的設定
3. 相關資安設定是否符合標準

而實作方面可以針對當前運行的 kubernetes cluster 進行掃描分析，也可以針對如 YAML/HELM 等檔案進行掃描，然後根據如 NSA-CISA, MITRE ATT&CK 等框架的內容去判別哪些設定是不適當的，可能會有安全疑慮的。

透過這些工具能夠盡可能提早的於 CI/CD 階段先行找出一些不夠安全的設定，避免這些設定被套用到正式生產的 cluster 上

對於這兩套工具的可以花點時間研究看看是否能夠幫助團隊解決一些問題

標題: 「Kubernetes 1.25 簡單介紹 」
類別: Tools
連結: https://medium.com/@i191693/major-changes-in-kubernetes-version-1-25-f29974a7aa57

今年 8月23日釋出的 Kubernetes 1.25 除了眾多的 bug 修復外，也帶來了將近 40 項的改正，大部分都是一些功能的階段演進，譬如下列功能就正式進入到 Stable 階段
- Ephemeral Containers
- Local Ephemeral Storage resource Management
- CSI Ephemeral Volumes
- CSI Migration-Core
- CSI Migration-AWS
- CSI Migration-GCE
- DaemonSets Support MaxSurge
- cgroups version 2
- Pod Security Admission
- Add minReadySeconds to Statefulsets
- Identify windows pods at API admission level authoritatively
- Network Policy Port Range
- Graduate the kube-schedular ComponentConfig to GA


講到 CSI 也要特別注意所有 in-tree 的支援度，譬如這次就標示 GlusterFS 於 in-tree 的功能為 depreciated，這也意味如果本身沒有特別安裝 CSI Driver 的 GlusterFS 使用者不要貿然升級到未來幾個版本，不然可能一升級就發現儲存功能直接炸了。

另外講了很久的 PSP (Pod Security Policy) 自從 1.21 被標示為 depreciated 後正式於 1.25 正式移除， PSP 本身立意良好，無奈其架構與使用方式並不討喜，更麻煩的是每次 PSP 的更新都只會針對之後運行的 Pod 進行控管，並沒有辦法對已經運行的 Pod 去處理，這使得使用上帶來些許不便。
因此 1.25 移除的同時也將 Pod Security Admission 這個替代品提升為 stable 的階段，PSA 內建三種不同層級的設定，並且可以以 namespace 為單位去設定與控管，對於團隊來說可以減少各種重複的安全性設定，直接以 namespace 為基礎去處理。
除了 PSP 外，官網也推薦其他三種替代 PSP 的解決方案，如 Kubewarden, Kyverno 以及 OPA Gatekeeper

標題: 「kubeshark: 一套整合 chrome dev tool + tcpdump + wireshark 的 k8s 專屬工具 」
類別: Tools
連結: https://github.com/kubeshark/kubeshark

kubeshark 提供視覺化的方式去檢視 k8s 叢集中 Pod 相關的 API 流量，基本上看了 README 的範例大概就可以知道這個工具的用途了

如果整體的資源消耗不大同時使用簡單的話，也許對於開發者來說是一個福音，能夠用最簡易的方式去觀察與除錯想要對付的 Pod/Container

標題: 「Netflix 經驗分享: 從 cache 觀察到的效能問題」
類別: Tools
連結: https://netflixtechblog.com/seeing-through-hardware-counters-a-journey-to-threefold-performance-increase-2721924a2822


Netflix 官方不定時都會分享非常多有趣且技術深度足夠的文章，本篇文章主要是探討將機器強度給調整後整個系統效能卻不如預期增長然後除錯找到問題點的故事。


今日的主角是一個用 java 寫成的應用程式，透過 AWS 的 ASG (Auto Scaling Group) 根據 CPU 用量來動態調整服務的數量，同時前方透過 rounb-robin 的 load-balancer 來平均分散流量到後方。

該服務原本是部署到 m5.4xl (16 vCPU) 的機器上，根據需求調整到 m5.12xl (48 vCPU) 的機器人，本來預計整體的效能能夠如線性般的三倍成長，結果整體表現非常的糟。
從效能來看，整體 throughput 平均只有提升 25%，此外更糟糕的是整個 latency 卻提升了將近 50%

提升機器等級提供更多 CPU 結果 latency 大幅度增長，這個結果實在是非常奇怪，所以團隊馬上開始研究來探索到底發生什麼事情。

首先，由於所有的流量都是透過 load-balancer，所以本來也預期這個問題應該是所有節點都有的，結果又發生更神秘的狀況，只有大概 12% 的節點是如預期般成長，剩下 88% 的節點幾乎都有這種效能下降的情況。


團隊的第一步驟就是透過火焰圖來比較看不同表現結果的節點會有什麼差異，接者又從 JVM 出發去看看從 JVM 是否有什麼直得注意的現象。
團隊從 app, JVM 到 OS 層級都嘗試找尋問題，但是還沒有辦法得到一個非常篤定且合理的答案，這時候開始懷疑可能是更底層的問題造成的，因此這時候決定使用 PerfSpect 此工具來觀察不同節點的現象。

該工具列出兩個節點運行上有一個顯著的數值差異，CPI (Cycles Per Instruction) 有將近三倍的差異，此外也觀察到節點上 L1 Cache 關於 MACHINE_CLEARS 的執行次數也有四倍差異。

仔細研究後觀察到這些參數會跟一個名為 "false sharing" 的狀況所導致的，而 false sharing 的意思是當有兩個 Core 嘗試從一個相同的 L1 cahce line(類似 memory page) 上讀取一個不相干的變數時造成的效能減損。

每個 Core 基本上都有屬於自己的 private cache，兩個 core 所屬的 cache 是來自於相同的 memory page，這個限制使得各自 cache 必須要維持一致，也就是這個維持一致的要求導致了問題發生。
舉例來說當 Thread A 嘗試寫入一個 Red 變數到 cache line 中，這時候系統會將 Thread A 底下的 cache 標示為 "moodified"，同時將 Thread B 底下的 cache 標示為 "invalidated".

接者當 Thread B 嘗試讀取一個名為 blue 的變數，理想狀況來說，兩個 thread 用到的變數不同，所以其實 Thread B 直接讀取自己的 cache 結果論來說是沒有問題，但是因為共享 memory page 的原因，所以系統這時候會強迫同步彼此的 cache 得資料讓 Thread B 上的 cache 先更新接者才讀取。 就是這個舉動操作使得整個效能大幅度下降。

團隊接者使用 Intel vTune 的工具來進行更底層的分析來觀察這類型的 false sharing 問題到底發生到哪，最後得出一個結論

Cache line 的大小是 64 bytes，然而使用的 pointer 是 8 bytes，所以有 8/64(12.5%) 的機會是正常使用，而有 56/64(87%) 的機會會產生 false sharing 的情形，此外這個數字也跟前述的節點分佈比例也幾乎一樣。

文章內有針對這個 vTune 的工具以及分析有更清楚的介紹，後半部分還有另外一個 true sharing 的問題，同時文章內也都有介紹這兩個問題的解法以及最後修改後的效能增長。

有興趣的可以閱讀全文

標題: 「Syzygy-Ai 新創公司的技術發展之路」
類別: Usecase
連結: https://betterprogramming.pub/architecture-of-modern-startup-abaec235c2eb


本篇文章是由 Syzygy-Ai 的 CTO 分享的一篇技術文，探討該公司的技術架構是如何發展與演變的。
對於一個新創公司來說，當釐清公司的產品面貌後，接下來就是要選擇合適的技術架構，如何選擇技術架構不單是一個技術層面的問題，也是一個哲學問題。
隨者科技的發展，愈來愈多的程式語言，框架與相關函式庫被創造，這些工具可以讓開發者更加便利，但是這中間的學習曲線也是一個不能忽視的問題。
對於新創公司來說，選擇一個工具就要去思考該工具是不是初期使用？會不會太大材小用？這工具從團隊的角度來看，容易找到熟悉的開發者？還是學習曲線不高容易上手？
除了開發之外，考慮到測試，維運等各類用途，每個工具的選擇就是個艱難的決定。

從維運角度來看，最明顯也最常見的問題就是 kubernetes 萬用論，不論應用程式性質與用途，一切都上 kubernetes，很多時候可能一台 VM + Docker-compose 就可以搞定初期流量的架構，結果上了 kubernetes 發現有更多的眉眉角角需要人花時間去學習，反而使得有限的開發人力變得沒有辦法就新創的角度去挑戰市場。

除了基本的工具選擇外，團隊的開發流程也有很多東西直得探討，譬如 git 的管理方式，是要使用 PR-Based 的方式還是要使用 Trunk-Based？ 甚至不同的 git/github/gitlab flow 都有各自適合的場景。

作者從最初期不到 12 名工程師的團隊下出發，去探討要包含 前後端 + 手機端 的開發部署流程下是怎麼選擇工具，接者導入 docker-compose 協助 mobile 開發人員能夠更順利地進行開發測試並且將這些前置作業也整合到自動化測試中，逐漸完善整個流程。

隨者團隊擴張與架構發展，AWS 上的設定增多且繁瑣，愈來愈多 ”沒人知道這個設定是什麼時候為了什麼目的由誰設定的“ 設定出現，因此團隊就開始探索 IaC 的可能性，是否可以經由 IaC 補足當前這塊的不足
接下來就是因應各種需求而開始接觸各種新工具
1. Secret 的管理
2. Kuberentes
3. Helm Charts
4. Observability
5. Multi Cloud (Azure/GCP)
6. Staging/Production

本篇文章內文算長，但是滿寫實的描述從一個什麼都沒有的新創到有相對穩定產品過程中間的技術變化，這中間完全體現了沒有一個技術可以用一輩子，不同的環境下都有各自適合的工具，適時的淘汰與切換並不是什麼不好的事情。
此外這個內容也滿呼應這段時間一些團隊的心得，許多員工一加入就要大刀闊斧，什麼都想要用最新最潮的架構，一下 K8s，一下 Service Mesh，一下 eBPF，看不喜歡的東西就大喊我要 Rust 重寫，殊不知沒有辦法提出一個合理且現實的規劃，譬如導入工具解決什麼問題，會要花多少人日時間，帶來成效是什麼，畢竟商場上最重要的不是“滿足你個人的架構癖好”而是公司有辦法穩定營運發展與活下去。

標題: 「Helm 小技巧，如何參考 values 檔案中的其他變數」
類別: Tools
連結: https://medium.com/itnext/reference-other-values-in-helm-chart-values-file-19d44d9276c7

常玩 Kubernetes 的玩家鐵定對 Helm 這個套件管理並不陌生，透過 template + value 的方式讓使用者可以根據不同環境客製化不同的參數。

現實中有時候會遇到一種情況， value file 裡面有些欄位彼此其實有依賴性，譬如

host: xxxxx
APIv1: xxxxxx/v1
APIv2: xxxxxx/v2

直接寫的情況使用上完全沒問題，只是當未來要 host 的資料的時候就需要一次修改所有欄位，因此很多人會就嘗試是否可以透過

host: xxxxx
APIv1: {{ .values.host }}/v1
APIv2: {{ .values.host }}/v2

上述這種方式來參考其他檔案內的變數，然而 helm 的運作邏輯是不會針對 value 的檔案去執行 template 相關的渲染。
本篇文章就針對這個問題探討如何使用 helm 內建的 tpl 函式來處理，同時也介紹潛在的問題以及最後的解法