標題: 「以 vcluster+ArgoCD 打造一個多租戶的 Kubernetes 叢集」
類別: kubernetes
連結: https://blog.devops.dev/multi-tenancy-with-vcluster-794de061fff1

作者團隊想要透過一個 Kubernetes 叢集的 namespace 來提供多租戶的使用方式，簡單來說就是 “Namespace as a Service”。
這個問題之所以麻煩是因為既有的 Kubernetes Namespace 並不是一個真正的隔離機制，有很多內建如 clusterrole, PV, storageclass 等物件都是沒有 namespace 概念的而是整個叢集共享的。

作者先前嘗試使用 vcluster 這個技術於 Kubernetes 叢集中創建一個全新的 Kubernetes 叢集，並且讓租戶使用這個新創立的 vCluster 來使用就不用擔心跟既有 Kubernetes 會有資源物件上的衝突。

然而提供全新一套給 Kubernetes 叢集給租戶聽起來很彈性自由，但是實務上對開發者來說不一定很方便，畢竟開發者更專注的是應用程式的開發而並非 Kubernetes 的操作與管理，因此如何
1 基於 vCluster 的機制提供一套獨立的 Kubernetes 叢集
2 整合 GitOps 的方式讓開發者可以用熟悉的方式去管理與部署自己的應用程式

因此本篇文章後半部分就是探討如何整合 vCluster +ArgoCD 提供一個完全友善的開發環境，讓開發者可以更簡易的去測試自己的東西同時也不擔心會影響彼此

標題: 「75 個 Kubernetes 的相關面試問題與答案」
類別: kubernetes
連結: https://medium.com/@bubu.tripathy/top-75-kubernetes-questions-and-answers-d677a0b87d79

Kubernetes 幾乎已經成為 Container Orchestration 領域上的共識標準，因此很多團為都會嘗試使用 Kubernetes 來管理服務
然而導入 Kubernetes 其影響的並不單純只是維運人員，對於小團隊來說，開發者勢必也要理解 Kubernetes 的概念才有辦法整合整個開發流程並且提高效率

本篇文章列出了基本的 75 的 Kubernetes 的基本概念，大抵上都是基本問題，不會涉入到非常進階的使用情境分析，但是對於分辨是否對 Kubernetes 有基本理解來說是滿有用的
也許對於 Junior 的職缺可以考慮用這類型的問題來快速判斷是否對 Kubernetes 有些許經驗與理解

標題: 「EKS v1.25 到 v1.26 的升級經驗談」
類別: kubernetes
連結: https://marcincuber.medium.com/amazon-eks-upgrade-journey-from-1-25-to-1-26-electrifying-79b287084eef

本篇文章是個系列文，作者每次升級都會撰寫一篇文章探討升級要注意的事項已經升級過程，從 v1.20 一路到 v1.26 每次版本的升級都有詳細記錄

其中這次 v1.26 的升級有幾個事項要注意
1 Container Registry 的位置改變，從 v1.26 以後所有過往使用 k8s.gcr.io 的位置都會改到 registry.k8s.io
2 Kuberlet 使用的 CRI 版本將會從 v1alpha2 變成 v1 版本，這個部分需要考慮的就是底層使用的 CRI Runtime 是否支援 v1 版本，以 containerd 來說至少要升級到 1.6.0 的版本
3 過往如果對於 Pod 要 Mount Volume 有權限控管的時候都會透過 fsGroup 的選項來調整掛載後的權限，未來可以把這個功能轉交到 CSI Driver 去處理，這意味所有用到該 Volume 的 Pod 可以直接仰賴 CSI Driver 去處理而不用每個 Pod 裡面都去設定
4 API Server 提供內建的 Metrics 讓管理人員知道所有 feature tag 的始動與否
此外從 API 的角度來看
1 autoscaling/v2beta2 正式退役，之後請改用 v2 版本
2 flowcontrol.apiserver.k8s.io/v1beta1 正式退役，請改用 flowcontrol.apiserver.k8s.io/v1beat2.

至於對 EKS 的使用者來說，升級前起先升級 AWS CNI 的版本到 1.12 否則你升級 EKS 後就會看到各種 CNI Plugin 的問題

標題: 「給資深開發者有關微服務的十個面試問題」
類別: Others
連結: https://medium.com/javarevisited/top-10-microservices-problem-solving-questions-for-5-to-10-years-experienced-developers-3391e4f6b591

這篇文章作者列出了十個關於微服務相關的問題，目標受眾為5-10年左右的開發者，每個問題都有給予的答案方向，問題都滿有趣且實際的，譬如

1 假設你開發套需要處理訂單的微服務系統，因為某些架構因素導致服務掛點，你要如何確保當服務恢復後沒有任何一個訂單被丟失且都能夠被妥善的處理
2 假設你要開發一套處理使用者帳號認證的微服務系統架構，你要如何確保你可以處理大量的請求且同時保持高可用性
3 假設你要開發的微服務架構要處理付款相關議題，要如何確保該服務足夠安全且所有使用者資訊也都受到保護
4 假設你的服務都會與 message queue 互動並且有多個服務會從其拿訊息處理，假設當有一個服務掛點沒有辦法順利取出資訊處理，你會採取何種策略來找到 root cause 並且除錯？
文章內還有其他六個題目，推薦有興趣的人花點時間看完

標題: 「90天 Senior DevOps 工程師報到攻略」
類別: Others
連結: https://medium.com/@alexrozdolskiy/a-step-by-step-guide-for-your-first-90-days-as-a-senior-devops-engineer-90b043cd764b

作者認為當今天被基於 Senior DevOps/SRE 此職位招聘時，公司對該職位的一個期待就是「自行解決問題」
很多時候可能會發現團隊中並沒有給予你一個非常明確的工作方向與進度，而這時候就是要仰賴你自行的能力去規劃整個工作進度與方向
針對那些沒有計畫的團隊，作者這邊給出一了一個三階段，總共 90 天的完整計畫，希望透過這個計畫能夠讓你不辜負此職位並且有效的帶領團隊成長

前30天
這個階段的手動目標是了解當前所有環境與架構並且為了未來所有改進與改善打好基底，包含
1 釐清整個組織的分佈與情況，包含
1 是否有整個工程團隊的組織架構
2 瞭解所有工程團隊用到的技術架構，包含 Backend/Frontend/Mobile …etc
3 瞭解所有資料團隊用到的技術架構，包含 (ML/Analytics/ …etc)
4 …等
2 釐清當前團隊中 DevOps 職位所扮演的角色，包含
1 Goals/KPIs/ 是什麼及如何制定
2 資安與權限控管目前如何設定
3 瞭解 SDLC (軟體開發生命週期) 的一切，包含部署方式，部署環境，監控...等
3 透過手動的方式來融入整個環境
1 透過 PR 的方式修復一些小 bug
2 參考文件並且修復任何不足之處

當有了上述的基本認知後，接下來就要開始思考自己的招聘能夠為團隊帶來什麼？
1 這個職位的目的與方向
2 新職位？還是取代舊有人員？
3 有無 OKRs/KPIs 等規劃?
4 有無相關 Agile/Kanban 規劃使用?

文章後半部分還針對 30-60 天，60-90 天兩個階段去探討，我覺得文章內容除了就職者之外，團隊主管也可以參考一下新招聘的 DevOps 初期應該要做什麼？ 要如何幫助他們快速 onboard 來釐清一切並且對團隊帶來正面的改善

標題: 「為何我拒絕成為 Amazon 內的 Senior Software Engineer」
類別: Others
連結: https://medium.com/@jamesryebread/why-i-will-never-be-a-senior-software-engineer-at-amazon-6613c66c2a6e

本篇文章作者的標題聳動其實整體核心內容很簡單，就是 WLB(Work Life Balance) 的取捨。

入職時，人人都懷有胸有大志，想要努力成長升遷，成為傳說中的十倍工程師，想要一路往上爬最終成為所謂的 Principal Enginner 並且過著千萬年薪的生活
然而隨者時間推移與工作型態發展，作者開始理解到自己其實並不如自己想像的聰明，平凡如自己要如何與一堆天才與高手共同競爭？ 如果真的有此機會升遷到更高階的職位那整個競爭與評比的壓力只會更大而且完全沒有信心能夠於這種競爭下存活

此外容易被人忽略的一點就是職位愈高，責任愈大，除了如過往的開發工作外還會有更多的會議需要參與討論，整體工時可能就會達到每週 60 小時。
此外升遷除了個人能力表現外，當前從事專案的熱門與影響力也會是一個評比表現，所以很多時候不是你能力不夠，而是當下這個時間點你就是無緣升遷，除非換組織換專案或是哪天時來運轉專案變得很重要，否則就會跟多數的同袍一樣，卡在 L5 數年。

結論來說，作者理解到自己想要追求的生活是成為一個出色的工程師，正常上下班，可以享受自己的夜晚從事自己喜歡的事情，而不是為了更多薪資(可能沒多到可以向五斗米般折腰?) 而夜以繼日的瘋狂工作，生活平衡才是自己追求的工作型態。

看完這篇文章可以完全理解那種感覺，隨者個人責任的變化以及升遷還要考慮到影響力與專業度的，因此愈來愈多的會議需要參加甚至帶領會議，而且從自己的團隊到跨足多個團得的會議都要處理，甚至當公司夠大有跨時區的團隊的時後就會出現早上六點第一個會議，晚上九點最後一個會議這種忙碌人生

至於這樣的生活與薪資水平是不是值得追求也沒有一定的答案，不過每個人都適合去思考一下自己追求的生活是什麼型態

標題: 「網際網路之父 Vint Cerf 坦承當年設計 TCP/IP 的三大錯誤」
類別: Others
連結: https://spectrum.ieee.org/vint-cerf-mistakes

簡單來說，從現今往回過去看個三個設計不足的點分別是
1 覺得 32 Bit 應該就足夠整個網際網路使用
1 沒有花費更多心思去探討資安的部分
2 沒有足夠理解 WWW 對於全球帶來的影響

從現今 IPv4 (32Bit) 的設計來回顧當年 1973 的設定其實也有點說不過去，畢竟 Cerf 也提到當年如果你說你要用一個 3.4 * 10^38 的大小來設計一個不確定會不會成功的實驗實在是有些瘋狂。
然而隨者網際網路的蓬勃發展， IP 數量開始出現耗盡的問題進而促使 IPv6 的發展，而 IPv6 初版則是 1998 年，距離現今也大概 25 年左右了，然而 IPv6 的落地與應用與 IPv4 是截然不同方向，對於使用者與開發者來說你有多少日常生活會使用 IPv6 地址的? 但是對於基礎建設商來說可能就不是如此，譬如 Nokia 提到的這篇簡報[註一]就提到如何透過 IPv6 的方式來改善整個 5G 網路核心的功能並改善效能與延遲性。

文章內有提到 WWW 帶來的全球資訊量爆炸，資訊多到人們再也沒有辦法慢慢瀏覽找到需要的資訊，此困境最終促使搜尋引擎的出現，讓人們可以用更簡易的方式去搜尋到各式各樣的 WWW 網站來獲得所需要的資訊。

搜尋引擎與 WWW 的相互發展，搭配各種文章農場以及投放廣告，使用者愈來愈難透過搜尋引擎快速且精準地找到問題答案，特別是還有些網站會偽造文章更新日期來欺騙使用者點擊，常常以為是最近的文章結果點進去都是十年前的文章，這類型的干擾都使得搜尋引擎與找到答案之間的關係愈來愈薄落

從 1973 到 1992, 第一個搜尋引擎出現也過了將近 20 個年頭，而 30 年後 AI 也正在改變整個搜尋引擎的用法。

譬如去年推出轟動世界的 ChatGPT，其透過一個對話的方式讓你可以透過用詢問的方式來尋求答案，使用者只要專注於各種 prompt engineering (詠唱魔法) 想辦法問出正確的答案，而非像過往搜尋引擎一樣需要點擊各種結果並從中努力找到答案。
此外微軟推出的 Bing Chat 這個內建 GPT 模型的搜尋引擎，也提供了 AI 使用的一種想像方式，將搜尋引擎與 AI 整合讓使用者同時享有兩種功能並且根據需求決定要用何種方式來找尋答案

需求促使改變，而改變的同時也需要天時地利人和，每個元件都環環相扣，少了一個也許都沒有辦法促使這些科技更新與改善。
也許就如同我們開發設計專案架構一樣，好的架構與設計都是要根據需求逐步迭代而進步，想要一開始就設計一個萬無一失的協定與架構似乎都過於天馬行空，畢竟你永遠都無法料到什麼時候又會有一個殺手鐧的出現逼迫你改變。

標題: 「DevOps Certification Roadmap」
類別: Others
連結: https://medium.com/@AnnAfame/%EF%B8%8F-devops-certification-roadmap-%EF%B8%8F-75e38e9b8da1

本篇文章列舉了作者認為推薦或認為值得擁有的 DevOps 相關證照並且對於該證照給予一些介紹以及考取學習上的建議，包含了

選擇性
1 Red Hat Certified Engineer
2 Docker Certified Associate
3 Puppet Certified Professional
4 Certified Jenkins Engineer
5 Certified Prometheus Administrator
6 The Certified DevOps Professional
7 DevOps Institute Certified Agile Service Manager
推薦擁有
1 AWS Certified DevOps Engineer – Professional
2 Microsoft Certified DevOps Engineer Expert
3 Google Professional Cloud DevOps Engineer
4 Certified Kubernetes Administrator
5 HashiCorp Certified: Terraform Associate
6 Certified Kubernetes Security Specialist

證照到底值不值得花錢去考是個一直以來都存在的討論議題，到底履歷上這些證照是否可以加分眾說紛紜，我認為就跟 DevOps 的定義一樣， YMMV 沒有標準答案，有的面試官吃證照，認為有證照就有基本實力，相反的也會有面試官會認為證照都是背題目，實戰經驗才是重點。

我個人的角度來看，與其一直去思考證照能不能幫我找工作提高薪水，不如去轉個念去思考，證照就是我學玩某個技術後順便去考的，主軸還是學習與理解，加強自己技能樹的深度與廣度。
如果剛好有餘裕資金與時間，就可以順便考個證照看一下這些證照到底玩什麼把戲，順便確認一下是否還有什麼自己不熟悉的東西。

至於企業角度又是不同，特別是教育訓練下很多時候上面追求 KPI，學習一個技術很難寫報告，但是學玩技術又可以獲得證照則這個報告相對好寫，我想這也是這個證照領域歷久不衰的原因之一?

標題: 「fsync 的重要性，為什麼任何非拜占庭協定的應用程式沒有 fsync 都會有資料遺失的可能性」
類別: Others
連結: https://redpanda.com/blog/why-fsync-is-needed-for-data-safety-in-kafka-or-non-byzantine-protocols

本文是由 Redpanda 該廠商的所撰寫的技術文章，主要是探討 fsync 與分散式系統下的問題。

fsync 的概念就是確保應用程式寫入的資料必須要寫道硬碟才可返回，該方式提高資料保證性但是卻降低了效能。

然而隨者資料複製 (replication) 架構的崛起，愈多愈來的架構採取資料複製的方式，其將資料給存放到不同節點上並且同步資料，即使有任何節點斷電或是出問題也不影響整個資料的正確定。

也因為資料複製提供的資料一致性，使得很多實作方式就不考慮執行 fsync，只要每個節點都有辦法順利同步資料，那任何不使用 fsync 的節點若中途斷電或是損毀也都不影響全域的資料正確性。

然而作者指出這是一個誤解，事實上只要你不跑 fysnc，任何斷電損毀節點上的未同步資料都會導致全域的資料遺失
更重要的是大部分的複製協定只支援 fail-stop 這類型的錯誤，該錯誤的假設是你節點會損毀沒關係，但是節點重啟後必須要跟損毀前資料一致，而因為沒有執行 fsync 的操作，這類型的節點損毀一定會掉資料。

為了解決這問題，作者指出這問題對於 拜占庭協定來說其實不是問題，因為拜占庭協定最初的假設就是更糟糕的故障可能性，支援各式各樣的節點行為。
文章後半部分用一個方式來證明 “單一節點的未同步資料是如何導致全域資料遺失”

結論來說：
在資料複製的架構中，使用 fsync 是確保資料一致性和持久性的關鍵方式。本文章強調了一個常見的誤解，即僅通過複製就可以消除對 fsync 的需求，並且示範了在一個非拜占庭式協議的系統中，單節點上未同步的數據丟失仍然可能導致全域資料遺失。

標題: 「詳細理解 Kubernetes Scheduler 的實作過程」
類別: Kubernetes
連結: https://itnext.io/kubernetes-scheduler-deep-dive-fdfcb516be30

本篇文章用圖示的方式清楚的解釋整個 Scheduler 如何去幫 Pod 找到一個適合的 Node
從最初透過 kubectl apply -f 部署一個 deployment 開始，當 controller 產生對應的 Pod 並且將 Pod 標示為 Pending(etcd) 同時將一個該事件放到 Secheduler queue 開始

Scheduler 會經歷兩個階段，分別是 Scheduling 以及 Binding

Scheduling 代表的是哪個節點我應該要選擇
Binding 代表的是將最後的決策給寫入到 etcd

以 Scheduling 來說，又可以細分成兩個步驟
1. 透過 Predicate 的方式去過濾所有符合需求的節點
2. 透過 Priorities 的方式去對所有符合標準的節點進行排名

以使用者來說，可以透過下列的方式去影響 Scheduler 的
a. NodeSelector
b. Node Affinity
c. Pod (Anti)Affinify/
d. Taints/Tolerations
e. Topology Constraints
f. Scheduler Profiles

如果對 Scheduler 這個元件沒有概念的 k8s 使用者可以看看這篇簡單易懂的文章，幫忙快速理解一下整個運作流程

標題: 「跟 Kubernetes Ingress 說掰掰，快來看看 Gateway API」
類別: Kubernetes
連結: https://itnext.io/saying-goodbye-to-ingress-embracing-the-future-of-kubernetes-traffic-management-with-gateway-api-6584b7b8f913

本篇文章探討一個發展一段時間但是大部分人都不甚清楚的 Kubernetes 新標準， Gateway API。
首先 Gateway API 與 API Gateway 文字上只是單純倒轉的關係，但是兩個的概念是完全不同的，前者是 Kubernetes 內的 API 規範而後者更甚至普遍架構上的一種概念。

文章中快速地介紹下 Gateway API 的概念，其分層次的架構如何讓 Developer/Cluster Operator/Infrastructure Provider 三者不同身份能夠順利協同合作來處理網路流量

後半部分則是介紹知名的 eBPF CNI, Cilium 目前針對 Gateway API 的支援度並且簡單介紹一下。

Gateway API 可被視為是 Ingress 物件的下一代設計，不過就如同 Ingress 一樣，Kubernetes 本身維護 API 而由其他解決方案去實作，因此 Gateway API 目前的完整度我認為還沒有如同 Ingress 一樣，因此個人還是選擇先繼續使用 Ingress 或是 Traefik 等的方式來使用，但是對於 Gateway API 的概念還是很值得去研究理解一下

標題: 「ChatGPT? K8sGPT?」
類別: Kubernetes
連結: https://github.com/k8sgpt-ai/k8sgpt

搭上 ChatGPT 熱潮因應而出的 k8sGPT，該工具會去掃描你的 Kubernetes Cluster，接者診斷然後找出可能性的問題
該專案號稱該分析引擎是融入的 SRE 相關經驗，能夠找出最相關的資訊來幫助排錯

其官網有完整教學要怎麼整合，基本上還需要搭配一個 AI Backend，範例是採用 OpenAI，所以必須要先註冊帳號獲得相關的 Key 才可以順利使用這個工具

有興趣的人可以玩玩看，看看此類工具是否真的可以幫忙快速釐清問題減少查找時間

標題: 「深度理解 AWS 環境下 Kubernetes 的 OIDC/IRSA 認證授權機制」
類別: Kubernetes
連結: https://medium.com/@seifeddinerajhi/securing-aws-access-from-kubernetes-cluster-using-irsa-oidc-15e8305e6036

過往要於 Kubernetes 去存取 AWS 資源的時候最簡單的方式就是準備一組 AWS IAM 帳號的 Access ID 以及 Secret Key。
而本篇文章要介紹的則是一種更簡單更安全的做法，則是 AWS 於 2019 年於 EKS 上推出的做法，也就是標題所述的 IAM Roles for Service Accounts (IRSA)，其目的能夠讓運行的 K8s Pod 直接享用對應的 IAM Role 進而得到相關權限與操作。

從 Kubernetes 的角度來看， AWS 會透過一些機制使得 Kubernetes Service Account 與 AWS IAM 有個綁定的關係，使用該 Service Account 就可以獲得相對應的權限，而這些 Service Account 就可以給相關的 Pod 去載入。

如果你有注意到的話，有些開源專案的 Helm Chart 如果其應用想要存取 AWS 服務時，你可以透過 Service Account 走 IRSA 或是給予一組 Access ID/SecretKey 兩種做法，閲讀完本篇你就會更加理解整個 IRSA 的運作流程，之後設定的時候才懂每一個步驟在做什麼以及緣由

文章內簡述的過往沒有 EKS 時代時每個 User 是如何去獲得 IAM Role 的權限，而到了 Kubernetes Pod 的時代後又是如何實作的，文中有各式各樣的流程圖去解釋每個步驟，除了 Kubernetes 內的設定外，連 AWS 那端的設定也都介紹的很清楚，讓你可以真正的理解中間每個實作過程

我認為本篇的概念對於 AWS/EKS 的重度使用者來說非常有幫助，畢竟 IRSA 這東西很多時候大家就是看看網頁各種東西設定，發現 Pod 可以通就過去了，但是未來出問題的時候就要花很多時間去猜想有哪邊出錯，理解 IRSA 就可以更快速地去找到可能出錯的問題點加快除錯速度

標題: 「低成本為你的 k8s 打造 egress」
類別: Kubernetes
連結: https://johnlin.dev/static-egress-ip-for-kubernetesw-workloads/

大部分使用公有雲的玩家對於 Ingress 也就是封包如何進到容器內比較在意，但是對於 Egress 也就是封包要如何從 K8s 出去則無所謂，畢竟能出去即可。
不過對於某些應用場景對於封包的來源IP有一定限制時，這時候就要考慮如何搭建一個 egress 來處理。

簡單直白的說，所有從 K8s 出去的封包大部分環境下都會經過節點本身的 SNAT 處理，而特殊環境則要求所有出去的來源 IP 要可控管且數量限制(通常是資安要求)，同時考慮到節點本身可能還會動態增長，因此如何達成這個目的實際上就是容易思考難以實作。
畢竟 Kubernetes 內建沒有支援 Egress 的概念，往往都要仰賴如 istio 等 service mesh 等方式幫你把封包都導向某個特定節點再由該節點轉發出去

本篇文章則是土炮示範如何用 linux 最原生的 iptables + iproute 等工具幫你把封包一路轉發到一個固定節點，接者將這些設定方式都導入 DaemonSet，則未來所有加入到 k8s 叢集的節點都會自動將封包轉發到對應節點，並且由該節點進行 SNAT 轉發

標題: 「Grafana oncall 101」
類別: DevOps
連結: https://medium.com/@magstherdev/say-hello-to-grafana-oncall-e78f548b2227

OnCall 想必是各位 DevOps/SRE 都不太陌生的文化，而本篇作者要介紹的是由 Grafana Lab 所開發的 Oncall 平台，名稱就非常直觀地稱為「Grafana OnCall」

Grafana 這幾年致力於打造一個非常完善的 O11y 平台，已經不單純只是過往 Prometheus 的視覺化平台而已這麼單純而已，其生態性已經包含了整個 Metris/Logs/Tracing，而今天的 OnCall 則是將告警直接補完讓整個 Grafana 直接提供一條龍的服務

另外 Grafana 大部分的服務都有開源OSS版本也有 Grafana Cloud 的版本，因此下載使用時要注意自己選到的版本與服務，以免不小心就付費下去了。

本篇文章主要是
1. 介紹 OnCall 內的基本流程與大抵概念
2. 簡易範例示範搭建一個 OnCall 的整體流程

相對於其他成熟的付費方案如 PageDuty/Opsgenie 等， Grafana OnCall 提供了一個機會讓你自行管理這些規則與平台，不過實務上使用的成本與否則是需要仔細考慮，畢竟告警這種東西要非常小心，設定不良等導致亂打電話或是產生狼來的現象導致告警疲勞最後就會錯過真正的問題，
因此使用時還是要謹慎評估整體的使用體驗，$$ 並非唯一的考量

標題: 「GCP BigQeury 即將迎來收費方案的改變」
類別: Others
連結: https://medium.com/@andrew_72226/bigquery-new-price-model-c2dc03aa2048

如果你是 GCP BigQuery 的使用者，那千萬不能不注意七月份即將迎來的付費方案改變，首先 flat-rate 的收費方案將整個收回，而 GCP 則是推出全新的 autoscaling 方式來處理，如果你什麼都不處理繼續使用 on-demand 的計費方式的話那就準備看到 20% 左右的漲幅

本篇文章以兩個客戶的範例講解一下作者是如何幫客戶進行 BQ 方面的省錢，由於剩下不到十天 GCP 就要直接轉換付費方式了，所以有使用 BQ 且目前有購買各種 slot reservation/commitmnet 的人最好研究一下確認自己不會下個月突然看到帳單暴衝

標題: 「上個月釋出的 Terraform v1.5 功能介紹」
類別: Tools
連結: https://medium.com/@willguibr/terraform-1-5-import-and-automatic-code-generation-caa4debfef28

上週推出的 Terraform v1.5 帶來些許功能的演進，其中最令人注目的就是關於 Terraform Import 概念的演進。

過往為了幫助團隊可以將現有 Infra 給整合到 Terraform 中， Terraform 開發了 Terraform import 這個指令將當下存在的 infra 給匯入到 Terraform state 檔案中，避免需要重新創建的問題就可以使用 Terraform 來管理這些 Infra 資源。

為了使用 Terraform Import，開發人員需要自行撰寫相關的 Terraform Code 並且根據 State 檔案內的名稱來手動逐步 Import 一個又一個的資源

而 Terraform 1.5 正式面對這個問題，引入 Config-Driven 為導向的 Import 功能，Import 不再只是單純一個 CLI 工具的參數而是一個可以撰寫於 Terraform 程式碼中的區塊，其可以一口氣 Import 匯入 大量的現存資源甚至還可以根據這些資源自動幫你產生 Terraform Code，讓你可以更方便的使用 Terraform 來管理現存資源

有很常使用 Terraform Import 的朋友可以研究看看此 v1.5 所引入的功能，評估看看這功能是否能夠簡化當前工作並且帶來好處

標題: 「繪製架構圖常用的八種工具」
類別: Tools
連結: https://icepanel.medium.com/top-8-diagramming-tools-for-software-architecture-2fc61d095b93

本篇文章作者幫大家整理了八個用來繪製架構圖的軟體，有付費/免費，有開源，有網頁應用，也有桌面應用程式，包含了
1 Diagrams.net(Draw.io)
2 Lucidchart
3 Excalidraw
4 tldraw
5 Gliffy
6 OmniGraffle
7 Miro
8 CloudSkew

以我自己繪製架構圖的經驗來說，最長需要的大抵上就是
1 方塊之間的連線是否好處理，特別是當元件過多時這些連接線能否彈性設定
2 是否跨平台，跨電腦，以及檔案容易保存與否
3 當需要繪製雲端架構時，有沒有一些現成的 icon 可以直接使用，譬如 AWS 之前就有釋出所有元件對應的 icon，對於繪製 AWS 架構來說可以說非常好用

上述工具我自己使用過的有
1 Draw.io
2 Excalidraw
3 OmniGraffle

畫圖風格來說我認為 Excalidraw 的風格比較偏向手寫一點，特別是其文字的基本字型，有興趣的可以嘗試看看
OmniGraffle 畫圖體驗非常的好，不過本身需要付費，可以嘗試使用看看試用版再決定是否需要付費
至於 Draw.io 我覺得就堪用，要繪製，同時因為是基於網頁的使用，所以切換電腦也不影響太多
剩下的幾個軟體有機會都來試試看

標題: 「Sidecar-less Service Mesh, Istio Ambient 於 AKS 上的仔細分析」
類別: Network
連結: https://medium.com/att-israel/a-deep-dive-into-azure-kubernetes-service-and-istio-ambient-for-sidecar-less-microservices-dcab76d6ef5e

Service Mesh 最初之際以 Sidecare 的模式達到透明性，讓應用程式無感背後的實作與原理就可以想到受 service mesh 帶來的好處，而隨者時間發展，目前也有一些聲音想要探討基於 sidecare-less 的架構，其中以 Cillium 以及 Istio Ambient 兩個的解決方案相較成熟與發展

本篇文章就是基於剛發佈沒多久的 Istio Ambient，想要從 Data Plan 以及 Control Plan 去探討 Sidecar-less Istio Ambient 實際使用起來的效果，整個環境基於 AKS 去創立，文章實際上有兩個部分，非常詳細的去介紹整體觀察的結果

對於正在使用 istio 但是又好奇 istio Ambient sidecar-less 架構的朋友，推薦閱讀一下，即使自己目前沒有轉換的計畫也可以科普一下這類型專案的一些概念

標題: 「Kubernetes 還剩下多少日子？」
類別: Others
連結: https://medium.com/cts-technologies/are-kubernetes-days-numbered-a3c267e65ee9


本篇文章是一個探討文，主因是作者之前有一篇探討 「Terraform 還剩下多少日子」的文章底下有網友詢問那 Kubernetes? 是否其還有未來

作者前半篇簡單的篇幅介紹何謂 K8s 以及探討以 GCP 架構來說，目前有下列產品有提供基於 Container 的應用程式部署，包含
1. GKE Standard
2. GKE Autopilot
3. Cloud Run
4. App Engine Flex
5. GCE with Containers

前兩個都是 GKE 的服務，但是 Autopilot 又簡化了關於 OS 層級的管理，讓使用人員只需要專注於應用程式本身，不需要去考慮 OS 層級的資源損耗與花費

而 Cloud Run 本身則是基於 Knative 的實作來提供 Serverless 的服務，讓使用者也是可以無感的去使用這些容器服務

此外 Cloud Function(v2) 本身的設計又是基於 Cloud Run 之上去疊加的。

以管理性質來來看，產品的發展逐步讓使用者愈來愈看不到底層的設計，盡量專注於自己所在意的層級

GKE Standard -> GKE Autopilot -> Cloud Run -> Cloud Function

因此作者認為 Kubernetes 短期內沒有什麼機會會消失，但是雲端的發展會愈來愈趨向“更多管理服務”的方向發展，讓開發者不需要擁有太多知識才有辦法去使用這個強大的容器管理平台，反而可以花更多心力與心思專注於自己的應用與開發
整個容器管理的發展就會如同 VM 一樣，大家使用 GCE/EC2/Azure VM 都可以非常簡單使用而也沒有真的去擔心到底底層的硬體機器與 Hypervisor 是怎麼設計與運作的吧?

標題: 「K8s 1.27: 如何加速你 Pod Startup 的階段」
類別: Others
連結: https://kubernetes.io/blog/2023/05/15/speed-up-pod-startup/


本篇是官方部落格文章，而本篇內容主要是探討當今天 k8s 叢集量很大且瞬間有很多個 Pod 要被部署到同一個節點上時，要如何提升整體的 Startup 時間。
有部份提到的功能要到 1.27 才出現，甚至可能是 alphe 的設定。

1. 開啟 Parallel Container Image Pulls

預設情況下 kubelet 是採取依序下載的策略，這意味假設同時有多個 Pod Image 需要下載，那就會陷入排隊狀況，只有等待當前下載完成才會開始下載下一個 Image

此功能開啟後就可以讓 Kubelet 平行的去載多個 Container Image，藉此可以避免其他的 Pod都卡在等待時間

此外開啟此設定還要特別注意上限值問題，官方建議根據你遠方 Registry 的設定去調整到底 Kubelet 最多一次可以抓多少個 Container Image

以下就節錄大綱，詳細內容請點選文章閱讀

2. 提升 kubelet 與 API Server 溝通的瓶頸 (API Query-per-second)
3. 調整 Pod 的資源(limit) 用量 (memoryThrottlingFactor)
4. k8s 1.26 後還有新增一個新的 histogram metric, pod_start_sli_duration_seconds 可以用來幫助團隊來偵測這些啟動時間