標題: 「探討微服務架構下如何透過設計模式來打造一個可觀察性(Observability)的系統」
類別: others
連結: https://learncsdesign.medium.com/microservices-observability-design-patterns-bdfa5807f81e

大多數人過往探討到監控服務時，直覺性都會想到透過 Prometheus + Grafana 來達到 monitoring 的功能，然而現在更多人推崇使用 Observability 這個詞來概括所有跟維運監控有關的概念。
最常見的幾個小分類包含
1. Metrics
2. Tracing
3. Logs

而本文作者則用六個類別來概括可觀察性，分別是
1. Health check API
2. Log aggregaion
3. Distributed tracing
4. Exception tracking
5. Application metrics
6. Audit logging

作者針對這六個項目都依序下列流程介紹，包含
1. 簡單概念介紹
2. 架構與流程圖
3. 常見專案

作者除了這篇文章之外，還有關於微服務架構的系列文，其連結都在本文底下，內容包括如
1. Service Discovery
2. Security
3. Cross-Cutting
4. External API
5. Data
....

有興趣的歡迎閱讀全文瞭解更多

標題: 「Loft Vcluster 正式提供 ClusterAPI 來提供統一方式打造多租戶的 k8s 叢集」
類別: Kubernetes
連結: https://www.businesswire.com/news/home/20220512005260/en/Loft-Labs-Simplifies-Virtual-Kubernetes-Cluster-Management-with-New-Open-Source-Project

隨者 Kubernetes 的普及，愈來愈多的使用情境都嘗試轉移到 Kubernetes 上，然而對於一個分散式基礎架構來說，如何有效率的使用底層資源來滿足上層應用一直都是不可避免的問題。

然而對於 Kubernetes 來說，如何達到真正的多租戶應用一直以來都是個難題，內建的 namespace 概念是基於 k8s 物件的方式來達到輕量級隔離，某些內容如 PV 等甚至根本沒有 namespace 的概念。
相較於 namespace 這種輕量級方式，另外一個重量級的則是直接給每個租戶一套全新的 k8s 叢集，
概念簡單，直接用不同的 k8s 來隔離最輕鬆，然而講的容易實作麻煩，要管理這些 k8s 實務上要處理的事情多更多，特別是當租戶數量超過一百以上時，要同時管理維護與升級這些 k8s 叢集真的會想死

兩者中間的一個折衷方案則是透過 Kubernetes 管理 Kubernetes，目前知名的專案就屬本文的 vcluster，而該專案最近又釋出了一個全新專案，該專案實作了 Kubernetes ClusterAPI，讓使用者可以透過 ClusterAPI 這個標準直接管理由 Loft 創建的 vcluster。

對於開發者來說就可以透過同一個管理方式來創建各種支援 clusterAPI 的叢集，不論是不同公有雲的叢集，或是某些地端廠商發行版，甚至是本文提到的 vcluster

有使用過 vcluster 的使用者可以研究看看此專案，看看使用 clusterAPI 是否可以讓本來的管理工作流程更為簡單順利

標題: 「Airbnb 是如何因應業務型態來動態調整 Kubernetes 叢集大小的?」
類別: Kubernetes
連結: https://medium.com/airbnb-engineering/dynamic-kubernetes-cluster-scaling-at-airbnb-d79ae3afa132

本篇文章是 Airbnb 的技術分享文，主要是探討過去四年來， Airbnb 是如何將內部服務逐漸轉移到 Kubernetes 上，並著重於如何動態的去調整 Kuberentes 叢集的大小。

對於 Airbnb 來說，如何有效地根據當前流量來動態的調整運算資源大小一直都是內部非常重視的一點，導入 Kubernetes 前， Airbnb 主要的資源都是透過 EC2 VM 來運行，而如何將這些服務逐漸地轉移到 Kubernetes 上同時又要能夠動態調整大小則是一個長期抗戰的目標。

Airbnb 將這個過程分成三個階段，以下分別節錄一些重點


Stage 1: Homogenous Clusters, Manual Scaling

過去使用 EC2 來部署服務時，團隊主要是透過手動的方式調整叢集數量來確保能夠應付當前業務流量，比較大的問題是這些當流量退去後這些資源常常沒有被回收，導致資源與金錢浪費。

所以第一階段就是先搭建簡單的 Kubernetes 叢集，根據不同的使用情境配置出不同的 Kubernetes 叢集，同時第一階段只運行 stateless 相關服務，同時基於 Kubernetes 的設計，讓每個節點運行適當的 Pod 數量以減少資源浪費。

此階段下，有任何叢集的擴充都還是基於手動操作，根據需求來進行叢集的調整。

Stage 2: Multiple Cluster Types, Independently Autoscaled

第二階段中，開始導入各式各樣不同的業務情境與相關服務，這使得底層需要的 Kubernetes 都會有些許不同的設定與資源，因此團隊從中開始打造一個抽象層，透過抽象層去描述需要的 Kubernetes 叢集設定與資源，包含實體機器的類型與相關軟體設定。

隨者使用情境的類型增加，團隊內的 Kubernetes 叢集也更多了，而第一階段採取的「手動」調整大小明顯無法處理這些需求，因此團隊開始導入 Kubernetes Cluster Autoscaler 來嘗試自動化 Kubernetes 的叢集調整。

相較於人工手動觀察與調整，透過自動化的 Cluster Autoscaler 幫助 Airbnb 省下大概 5% 的雲端成本，同時也減少很多維運上的操作需求

Stage 3: Heterogeneous Clusters, Autoscaled

當 Airbnb 幾乎將所有業務都轉移到 Kubernetes 後，此時的叢集類型已經超過 30 多種，部署的叢集數量更是破百，整體規模的成長使得 Kubernetes 的管理愈來愈麻煩
舉例來說，當 Kubernetes 要升級的時候，每個要求的類型(30+) 都要獨立測試過，確認每個類型都不會被影響才可以順利往上升級。

所以第三階段的目的就是希望保有過往的彈性下，同時降低複雜性，其中採取的方式希望能夠創造一個服務各種不同業務需求的 Kuternetes 叢集。

而團隊發現到現有的 Cluster Autoscaler 使用上有些限制使得沒有辦法很順利地達到團隊需求

因此文章後半部分主要詳細介紹團隊是如何開發 Cluster Autoscaler 並且積極的與社群互動來確保自己開發的新功能是能夠讓其他使用者一起受益，而非只有 Airbnb 自己有辦法使用。

有興趣的可以點進去閱讀全文

標題: 「一個名為 comcast 的網路模擬小工具」
類別: Networks
連結: https://github.com/tylertreat/comcast

今天介紹的是一個很有趣的網路工具，該工具是用來模擬不同環境下可能的網路條件，譬如封包掉落率，Latency 以及整體頻寬。

這樣一個看起來不太複雜且多年沒有維護(上次 release 是 2015)的工具竟然會有將近 8.4k 的星星數，我想最大的理由應該就是這工具的名稱實在太貼切了...

Comcast 是美國這邊知名的網路供應商，就我個人經驗來看，很常遇到封包被丟，網路維修等各種問題...

標題: 「探討 Linux 系統下 Cache 與 Buffer 的差異」
類別: Linux
連結: https://medium.com/geekculture/linux-memory-buffer-vs-cache-44d8a187f310

作者開頭就列出關於 Linux 底下 Buffer 與 Cache 的常見說法

Buffer: 「是一個為了底層硬碟的暫時儲存設備，會將要寫入到硬碟的資料給快取起來，Kernel 接著可以根據需求來最佳化寫入到硬碟的時機，譬如將多個小寫入給合併成一個大寫入」

Cache: 「是一個為了從硬碟讀取檔案的快取，譬如對一個檔案多次讀取，後續的讀取就可以以更快速的速度從 Cache 中讀取資料，不需要每次都跑到硬碟去讀」

作者根據這的定義問出了一個問題，為什麼 Buffer 不能夠快取從資料讀取的資料？ 反過來看為什麼 Cache 不能夠去處理要寫入的資料？

從 "free" 這個指令的輸出訊息中，可以看到 buffer/cache 這兩個概念被放一起，兩者是以總和為單位去看待的。
根據 free man 的說明

buffers: 被 Kernel buffers 所使用的記憶體 (Buffers in /proc/meninfo)
cache: 被 Page Cache /Slabs 所使用的記憶體 (Cached, SReclaimable in /proc/meminfo)

可以看到實際上這些數值都是從 /proc 這個特殊的檔案入口讀取出來的，這時候如果去翻 proc 的介紹，來仔細看這些定義

Buffers:
Relatively temporary storage for raw disk blocks that shouldn't get tremendously large (20MB or so).

Cache:
In-memory cache for files read from the disk (the page cache). Doesn't include SwapCached.

從這邊來看，其實 Buffers 似乎強調的是 Raw Disk，而 Cache 則是從硬碟中去讀取資料。
因此作者接下來就執行兩個實驗，透過 dd, vmstat 等指令去驗證

1. 使用 dd 去寫入檔案
2. 使用 dd 從 disk 讀取區塊

從上述的實驗中可以觀察到
1. 使用 dd 去寫入檔案時， Cache 的使用記憶體數量逐漸上升，這意味其實寫入檔案其實也有快取的概念，而系統上的 Cache 實際上介入
2. 使用 dd 從硬碟讀取區塊時， Buffer 與 Cache 的記憶體使用量都有上升，但是 Buffer 的成長量非常明顯，與 Cache 不是同個數量級的。這也意味者從硬碟直接讀取區塊時， Buffer 會參與並且作為快取的角色來加速整個讀取。

根據這兩個實驗，作者給出的觀察是
Buffer: 當寫入硬碟或是從硬碟讀取時， Buffer 會作為快取來幫忙
Cache: 當寫入檔案或是從檔案讀取時， Cache 會作為快取(Page Cache)來幫忙

標題: 「就是一份唸書的書單」
類別: others
連結: https://github.com/charlax/professional-programming

今天分享的是一個類似 awesome-xxxx 系列的 git 專案，該專案收集了不同領域值得閱讀的書籍與文章
範圍非常廣，從程式語言到容器技術到系統架構概念全都包

閒來無事也許可以當一個唸書清單?

標題: 「如何測量與提升開發者的生產力」
類別: others
連結: https://medium.com/@bijit211987/how-to-measure-and-improve-developer-productivity-694607f501bc

本篇文章想探討的是一個數十年以來一直被研究探討的問題，如何有效地去評測一個開發者的生產力？
對於管理人員來說，有時候都會希望能夠有一個完美的指標可以用來評估當前團隊以及個人的生產力，特別是近年因為遠端工作興起，團隊可能散落世界各地，橫跨不同時區，這種情況下要如何保有過往的開發生產力與效率則是每個團隊都會面對的問題。

作者認為這生產力指標是一個重要但是極度困難的工作，畢竟開發團隊工作牽涉到如
1. 撰寫新功能
2. 修 bug
3. 重構，提升維護性
4. 撰寫測試
5. ...等
這些不同面向都很難有一個單一指標去衡量一個開發者的生產力，舉例來說
用想都覺得很不合理的 LOC(程式碼行數) 對應到上面五個類別就完全不同，新功能會有最多的程式碼行數，修 bug 可能很困難，結果只有改一行，重構更可能減少程式碼行數？
這種情況下用單一指標來評斷生產力與否完全沒有道理。
除了這類型的指標外，作者提到還有很多類似的指標
1. 工作多少小時. (很有可能出現很多人發呆衝時數)
2. 發現多少 Bug (是真的有聽過規定要每週驗多少 bug 的指標...)
3. 解決多少 Ticket
4. ... 等

文章中作者從幾個不同面向去提供思考，譬如
1. Git-Based 的指標，包含程式碼改動頻率，多少程式碼有經過 code review
2. SPACE 框架，基於多個指標如 (S)atisfaction, (P)erformance, (A)ctivity, (C)ommunication/Collaboration 以及 (E)fficiency
3. OKR 系統

對於如何測量生產力有興趣的可以參閱看看作者的一些觀點

標題: 「Linux 5.19 竟然是由 Apple M2 MBA 釋出的」
類別: others
連結: https://twitter.com/asahilinux/status/1553968394734813184?s=21&t=GMOBjwW_tzPQJ_j8mm7GZg

最近 Linux Kernel 5.19 的釋出如火如荼的進行，其中最有趣的是 Linus Torvalds 是使用 Apple M2 來運行 test build, boots 以及 release 相關操作

同時該推特帳號 Asahi Linux 本身就是一個能夠於 M1 上運行的 Linux 發行版本，不知道是不是暗示 Linus 本身是於 M2 晶片上運行 Asahi Linux 來發行 Linux 5.19 ?

標題: 「如何一直不停的於 SRE 之路上學習」
類別: others
連結: https://medium.com/async-software/how-i-learned-and-still-learn-site-reliability-engineering-dd6ad32c4285

作者認為身為一個應用程式的開發者，如果對於如何將應用程式給部署到正式環境的細節有一些粗略瞭解，對於 DevOps 的領域也能夠有所一些涉獵時，其實對於整個團隊來說會使得合作更加協同，譬如說應用程式開發者就會知道可能需要準備 Health Check 的 API，針對維運監控方面也會知道如何準備適當的 Metrics API。

所以作者就從幾個不同角度列出一些學習的相關資源，從 DevOps 的概念出發學習，接者是相關的技術探討

# 書籍
1. 第一本推薦的書籍是由 Google 所維護的 SRE 書籍， Site Reliability Engineering。
該書籍涵蓋了如何建置，部署，監控以及維護如此龐大的 Google 架構。
2. 作者推薦的另外一本書籍則是非常著名的鳳凰專案，跟者故事主角一同面對一個要轉型的企業，同時自己也可以順便思考到底本書想傳遞的 DevOps 概念是什麼

此外還有其他兩本包括 Continuous Delivery 以及 Continuous Architecture in Practice 這兩本探討 CD 以及 DevOps 與敏捷文化下的軟體架構設計

# 學習平台與網站
1. A Cloud Guru 是一個可以用來學習如 AWS, Azure, Terraform, K8s, Linux, Ansible 以及 GCP 的線上網站
2. 一個開源的 Git 專案， (MichaelCade/0DaysOfDevOps)，該專案紀錄如何從頭到尾用 90 天的時間去認識 DevOps 這個文化與技術，
3. The Delivery Hero Reliability Manifesto，該網站整理了很多關於 Delivery Hero 的技術文章，包含實務上的技術分享以及經驗累積的一些實戰經驗等。
4. DevOpsCube 則是收集了很多關於 Kubernetes, Jenkins, Container 等技術的相關實戰文章

對這些有興趣的人可以加入到書籤的待讀清單中

標題: 「善用 ephemeral container 來加強 K8s Pod 的除錯技巧」
類別: Kubernetes
連結: https://betterprogramming.pub/debugging-kubernetes-pods-deep-dive-d6b2814cd8ce

過往大家除錯 Kubernetes Pod 時很常會使用 kubectl exec 的方式進入到容器中去執行相關指令，但是這個方式很常遇到該容器沒有相關的工具而無法進行，當問題容器是第三方服務是更不太可能重新去建置這些容器來加入想要使用的工具。此外也有可能遇到部分操作需要權限，這情況通常都需要修改 YAML 重新產生一個 Pod

所以本篇文章會著重於另一個除錯的方式，也就是透過掛載一個 Ephemeral containers 的方式到現有的 Pod 上面，該 Contianer 可以安裝各式各樣的工具，同時動態共享如
1. Network namespace
2. Process namespace
3. Volume

有了上次的共享資源，我們就可以使用該容器來針對服務進行除錯同時又不需要去修改與動到任何既有服務的設定。

本文使用 KIND 架設一個示範用的 k8s 叢集並且使用 kubectl debug 的方式來示範如何掛載這類型的容器來達到除錯的效果。

如果對於除錯有苦手的一定要試試看這個方式

標題: 「不同公司針對 oncall 類別的津貼補償調查」
類別: others
連結: https://blog.pragmaticengineer.com/oncall-compensation/

本篇文章不是一個技術文，但是卻可能跟各位息息相關。
假設身處一個需要輪班的職位，你覺得公司是否應該要針對輪班這件事情有額外津貼喔？ 有的話要如何處理？
是問題發生才算加班還是半夜不睡覺進入stand by 模式也要算加班？
面試被告知需要輪班的話，你會針對整體薪水的部分提出什麼樣的補償？

文章幫你收集了各公司對於 oncall 的額外津貼與相關補償，有興趣的不妨參考看看，瞭解一下目前大部分的公司都怎麼處理這一塊以及當自己遇到的時候會希望怎麼樣處理/被處理

標題: 「以 KEDA 與 K6 來示範如何基於 Ingress 與 Prometheus 流量來自動擴張 Pod 數量」
類別: kubernetes
連結: https://blog.cloudacode.com/how-to-autoscale-kubernetes-pods-based-on-ingress-request-prometheus-keda-and-k6-84ae4250a9f3

KEDA 全名是 Kubernetes Event-Driver Autoscaler, 由於原生的 HPA 只能夠基於 CPU 等指標來進行自動擴展，而 KEDA 希望能夠更加強化這個機制讓整體叢集更加好用，因此其底層銜接 Kubernetes Deployment 等各種 workloads，而上層則是透過銜接各式各樣的 event。 這意味者你就有機會基於不同的事件來跳整 deployment 的數量。
而本篇文章是基於 KEDA 為基準，想要使用基於 nginx-ingress 的效能指標來動態調整 Deployment 的數量，而為了讓 KEDA 可以接受這些 Event, nginx-ingres 則是會透過 promethues 的方式將其資料給分享出去。

整個 demo 流程中最後使用 k6 來產生 HTTP 的流量，透過這些打到 nginx-ingress 的流量才使得 prometheus 得到最新的效能指標，最後觸發 KEDA 來動態調整 Pod 的數量

標題: 「八個你可能不知道的 git 小技巧」
類別: others
連結: https://betterprogramming.pub/8-advanced-git-commands-university-wont-teach-you-fe63b483d34b

本篇文章介紹了八個可以提升生產力的 Git 小技巧，譬如說
1. 身處 A branch 但是可以直接觀察該檔案於不同 branch 的內容
2. 清除本地那些已經被合併的 branch
3. 從歷史所有 commit 中搜尋特定字串的位置
4. 開啟自動拼字錯誤，不小心手殘打錯的指令也可以幫你校正回來
...等

文章並不長但是每個用法都有介紹一下概念以及如何使用與設定，有興趣的可以參考參考

標題: 「十個 Terraform 相關的小工具」
類別: Terraform
連結: https://shahneil.medium.com/10-best-terraform-tools-that-you-need-in-2022-e6b6d55bc071

這篇文章收集了作者認為有趣且有用的 Terraform 小工具，譬如
1. Inframap -> 根據你的 HCL code 或是 tfstate 來產生關聯圖，將所有資源彼此之間的依賴性以視覺化的方式呈現，對於需要接手專案的入門者來說也許是一個快速理解當前專案大方向的好工具
2. Terraformer -> 逆向的 Terraform，從現有的基礎架構反向產生對應的 TF/JSON 以及 tfstate。對於現存不方便改動的架構，似乎採用這個方式也能夠快速的將其套上 Terraform 的皮?
3. Terrakube -> 一套類似於 Terraform Enterprise 的開源專案，設計初期就是針對 Kubernetes 的運行環境去設定，簡單來說就是可以讓你於 Kubernetes 內部署一套類似 Terraform Enterprise 的架構供團隊使用
4. TFsec -> 一套針對安全性的靜態檢查工具，幫忙檢查相關語法同時針對創立的架構給予一些安全性上的建議

文章中還有其他六個工具，長期使用 Terraform 的使用者可以參考看看

標題: 「事故反思與 Postmortem 的實踐方式」
類別: Others
連結: https://blog.pragmaticengineer.com/postmortem-best-practices/

讀過 Google SRE 相關書籍的都會對 Postmortem 這個事後檢討的機制並不陌生，Google 強調 Postmortem 一個很大的精神是不究責，不去探討是誰造成該問題，相反的是去找出問題所在並且建立更完善的流程來確保該問題不會二次出現。

然而就跟 DevOps/SRE 這個詞一樣，每個團隊每個公司的解讀方式都不同，最後的實作方式都不同，不過這也是完全可預期的結果，畢竟每個團隊的組成與運作方式都不同，但是最重要的都是要打造一個不咎責，對事不對人的咎責文化。

本篇文章有點長，主要分成五個面向去探討，包含

Common incident handling practices across the industry.
Incident review best practices
Incident review practices of tomorrow.
What tech can learn from incident handling in other industries.
Incident review/postmortem examples and templates
想要打造一個良好的維運團隊，postmortem 是個不可或缺的流程，有興趣的歡迎花點時間閱讀本文

標題: 「事故反思與 Postmortem 的實踐方式」
類別: Others
連結: https://blog.pragmaticengineer.com/postmortem-best-practices/

讀過 Google SRE 相關書籍的都會對 Postmortem 這個事後檢討的機制並不陌生，Google 強調 Postmortem 一個很大的精神是不究責，不去探討是誰造成該問題，相反的是去找出問題所在並且建立更完善的流程來確保該問題不會二次出現。

然而就跟 DevOps/SRE 這個詞一樣，每個團隊每個公司的解讀方式都不同，最後的實作方式都不同，不過這也是完全可預期的結果，畢竟每個團隊的組成與運作方式都不同，但是最重要的都是要打造一個不咎責，對事不對人的咎責文化。

本篇文章有點長，主要分成五個面向去探討，包含
1. Common incident handling practices across the industry.
2. Incident review best practices
3. Incident review practices of tomorrow.
4. What tech can learn from incident handling in other industries.
5. Incident review/postmortem examples and templates

想要打造一個良好的維運團隊，postmortem 是個不可或缺的流程，有興趣的歡迎花點時間閱讀本文

標題: 「Uber 如何使用 gRPC 打造內部的推播平台」
類別: Usecase
連結: https://www.uber.com/en-GB/blog/ubers-next-gen-push-platform-on-grpc/

本篇文章是 Uber 官方的技術部落格，主要探討的是 Uber 如何將既有輪詢為主的操作模式轉移到推送為主的操作模式，這類型的改動目的是提升使用者(消費者/司機)的應用程式體驗。

以技術層面來說，就是將基於 HTTP1.1 的 Server Sent Events(SSE) 系統給轉移到基於 gRPC 的系統，本篇文章分成
1. 緣由，現有困境
2. 轉移方式
3. 學習以及未來展望

前半部分 Uber 先介紹當前的 SSE 架構，該架構的全名為 Reat-Time Asynchoronouse MEsssaging Network, 大概就是即時非同步訊息網路，簡稱拉麵(RAMEN). 文章簡單敘述 RAMEN 的架構，包含如何使用 Redis, Cassandra, Zookeepr 以及從 Client(網頁，手機) 與 Server 不同角度是怎麼看帶 RAMEN 系統。

然而 RAMEN 有一些極限是團隊想要改善的，包含
1. RAMEN 底層是基於 text-based 的傳輸，所以對於要傳送影片，聲音等非純文字檔案就不夠有效率，需要進行一些轉換。
2. SSE 的架構是個單方向的連線傳輸，該架構下某些狀態訊息的傳輸要等到最多 30 秒才可以確認，這對於很即時的應用來說是極為不便的
3. ACK 的傳輸目前也是不夠有效率，一種改善方式就是採用雙向連接，但是這意味整體 Connection 數量就會變成兩倍，底層架構要維護的連線數量會直接翻倍

當前 RAMEN 實務上可以運行，但是上述的一些問題使得團隊想要嘗試改善，最後就決定整體轉換到基於 QUIC/HTTP3 的 gRPC 協定。
對於團隊來說最大的吸引點是 天生連線就是雙向溝通，這意味 Client/Server 可以更即時的交換彼此的訊息。

後半部分都在描述一些轉移的過程以及新的架構方式
最後則是列出幾個轉移過程中的學習重點，如
1. Concurrency Issues
2. Message Flow Control
3. Graceful Shutdown Handling
4. Handling Missing Callbacks
5. Payload Compression -> 這個議題我覺得很有趣，因為 Uber 使用遍布全球，不是每個使用者都有良好的手機網路，內部發現對於使用 3G 網路的使用者來說，抓一個超過 1MB 的檔案就要花費快一分鐘，整個使用者體驗非常差，透過 Gzip 的壓縮能夠把時間減少到剩下五秒左右，使用者體驗大幅度上升


對於該架構轉換有興趣的可以看看本文

標題: 「Azure 服務炸給你看...」
類別: Usecase
連結: https://status.azure.com/en-gb/status

昨天開始 Azure 的服務就各種不穩，追根究底原因是底層 Ubuntu 上新版套件 systemd-resolved(https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119) 出現問題，該套件負責的則是系統上的 DNS 解析功能，所以受影響的機器其 DNS 解析就一起出包。
當 OS 出包，各種往上疊加的應用就一起出包，如 AKS...等

雖然容器化跟 YAML 好棒棒，但是平時還是要跟 OS 當好朋友，遇到問題時才看得懂到底發生什麼事情，以及自己如果要先行處理的話可以怎麼處理，畢竟不是所有系統的東西都可以用 YAML 搞定的。

標題: 「十本推薦閱讀的 DevOps 相關書籍」
類別: Usecase
連結: https://medium.com/@bestarion/10-books-make-you-become-a-perfect-devops-engineer-fcb1b83a079

作者列舉了九本(雖然標題寫10本..)其認為對於 DevOps 職涯發展有幫助的相關書籍，每本書籍都有列出其大綱，作者，相關重點以及購買連結，其中最知名的鳳凰專案也當然不會被錯過。
1. The DevOps Handbook
2. The Phoenix Project
3. DevOps for Developers
4. The Unicorn Project
5. Effective DevOps
6. Continuous Delivery
7. The DevOps Adoption Playbook
8. Accelerate
9. Infrastructure as Code: Managing Servers in the Cloud

標題: 「Kubernetes 1.25 改動差異」
類別: Kubernetes
連結: https://www.cncf.io/blog/2022/09/02/kubernetes-version-1-25-everything-you-should-know/

今年八月份是 kubernetes 1.25 的正式發行，除了帥氣的小 logo 外也帶來非常多的改動，這些改動大部分都是既有功能的狀態轉移，譬如從 alpha/beta 等版本轉移到 stable，一下就幫大家節錄一下這次的改版有哪些值得注意的新功能，節錄中就不特別針對新功能還是狀態轉移進行區別。


# Apps
1. StatefulSet 新增一個參數，minReadySeconds，該參數用來提供一個額外的緩衝區間讓 Container 可以有更好的方式去處理需要過長的啟動時間
2. Cronjob 未來設定時可以特別使用 TimeZone 的選項來描述該時間對應的時區，而不用全部依賴叢集內 Controller 的時區

# Auth
1. PodSecurityPolicy 自從 1.21 被標示為即將捨棄，1.25 則是正式捨棄
2. 支援自動處理 KMS(Key Management Service ) 上的 Key rotate

# Network
1. NetworkPolicy 中可以透過 endPort 這個欄位來描述一個範圍的 Pod，不論是 Ingress 或是 Egress 現在就可以透過 endPort 一次描述一個區間，而不需要像過往一樣每個 Port 分開寫
2. 過往創建 Cluster 的時候可以指定 Service IP 的範圍，而所有自動創建的 Service 都會使用這個區間的 IP，如果有特別需求時使用者是可以手動指定想要用的 IP，現在透過 ServiceIPStaticSubrange 這個新的欄位可以讓使用者更順利地去手動設定想要的 ServiceIP 同時也可以確保自動設定的 Service IP 不會與手動的重疊已產生IP重複問題

# Node
1. 前幾篇文章介紹的除錯方式， Ephemeral Containers 如今也正式進入到 stable 階段，這個方式我認為未來是除錯路上必備的技能之一
2. cgroups v2 的整合也到了尾聲， 1.25 正式宣告為 stable 版本，不過我對於 cgroup, cgroup v2 的看法大概是其實真的花時間去理解這些的使用者根本沒多少，其改動到底有影響什麼大部分應該都沒有感覺
3. liveness 中的新欄位 terminationGracePeriodSeconds 也正式到 stable 階段了。

# Storage
1. In-Tree Storage diver 到 CSI 的轉移繼續往前推進，其中包含已經移除，即將移除以及相關正式轉移的相關儲存方案，如下
Depreciation: GlusterFS, Portworx
Removal: The Flocker, Quobyte, and StorageOS
Migration to CSI plugin: AWS EBS, GCE PD, vSphere
2. 未來將可以動態的去修改預設的 storageclass 名稱，而非只能使用 cluster 創建時的預設名稱而已

文章中還有其他的小改動，有興趣的可以去觀看

標題: 「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 佔用過多系統資源