標題: 「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 函式來處理，同時也介紹潛在的問題以及最後的解法

標題: 「網路技術文，探討 Kubenet, Azure CNI 與 Azure CNI(Overlay) 的差異」
類別: Networking
連結: https://medium.com/@inder-devops/aks-networking-deep-dive-kubenet-vs-azure-cni-vs-azure-cni-overlay-a51709171ce9

作為一個 AKS (Azure Kubernetes Service) 的使用者，創建時可能都會觀察到有所謂的 network model 可以選擇，而這個 network model 實際上就是對應到 Kubernetes CNI 的範疇，預設情況下是採用 kubenet 這套解決方案來處理 CNI 的需求。

本篇文章首先先以簡單的概念描述 Azure 的網路概念，與多數的 Cloud Provider 一樣，基本上都會有所謂的 VPC + Subnet 的概念，同時因應 (Kubernetes Service) 都可能配置的 NodePool 來探討一下這些 IP 的基本關係。
接者從 Kubernetes 出發，探討所謂的 PodCIDR, ServiceCIDR 這些實際上跟 Kubernetes 有直接相關的 IP 分配與使用
有了上述的基本概念後再來看接下來的 Kubenet/Azure CNI 的比較才會有更深的體悟實際上的差異是什麼

以下簡單記錄一下每個 CNI 的特性
Kubenet
1 Nodes 會從 Azure virtual network subnet 獲取 IP
2 Pod 會獲得一個全新的虛擬網段，該網段由 kubenet 維護
3 Pod 如果要對外存取服務，需要透過 SNAT 來進行轉換，且轉換後的 source IP都是 Node IP
Azure CNI
1 Node 會從 Azure virtual network subnet 獲取 IP
2 Pod 與 Node 一樣，會從一樣的 Azure virtual network subnet 獲取 IP
1 為了實作此功能，每個節點除了主要 IP 外，還會掛載更多網卡來處理 Node 上 Pod 的IP與相關存取
3 Cluster 上 Pod 的數量規模會取決於當前 Azure virtual network subnet 分配的網段大小，太小則沒有辦法分配適當的 IP 給 Pod

Azure CNI Overlay
1 運作模式類似於 Kubenet， Pod 都會用新創的虛擬 IP
2 效能相對於 Kubenet 更好

從功能面來看 Azure CNI 與 AWS CNI 類似，都是以 VPC 的角度打出一個大一統的網路平面來給所有的 k8s node, k8s pod 去使用，好處就是 IP 攤平的情況下減少溝通成本同時也能夠透過既有的 network firewall 等進行處理與觀察，但是壞處就是 IP 分配數量直接影響 Pod 的數量，這變成架構設計時就要先想好到底要如何分配

詳細比較圖文可參考內文

標題: 「CNCF 2022 專案回顧」
類別: Networking
連結: https://medium.com/dev-genius/cncf-2022-graduated-projects-year-end-review-part-one-95d27c77983c

2022 依然是 Cloud Native 生態系蓬勃發展的一年，以 CNCF 所託管的 157 個專案中，就有超過來自 189 個國家共 178,000 的貢獻者。
同時，直到 2023 年底，CNCF 中共有 20 個畢業專案，畢業的意思就是該專案已經足夠穩定，有來自不同地方的貢獻者共同維護該專案生態系同時該專案也被證明能夠於正式部署環境使用的。
作者特別整理這些畢業的專案，本篇文章只是上篇，因此只有收錄十個畢業專案
對於使用者來說，選擇畢業專案除了技術上的考量，有時候也是一個政治上的考量，基於 CNCF 的畢業標準作為背書來表示為什麼要使用此專案相對於其他的專案會更有說服力，畢竟使用開源專案除了功能面之外，生態系的活躍也是後續維護與找尋臭蟲的一個重要關鍵點。

目前畢業的 20 個專案分別有
1 ArgoCD
2 Containerd
3 CoreDNS
4 Envoy
5 etcd
6 fluentd
7 flux
8 Harbor
9 Helm
10 Jaeger
11 Kubernetes
12 Linked
13 Open Policy Agent
14 Prometheus
15 Rook
16 Spiffe
17 Spire
18 TUF
19 TiKV
20 Vitess

因此本篇專案就是針對前 10 個進行簡單介紹，從分類來說大抵上可以看成
GitOps -> Argo/Flux
Observability -> Fluentd, Jaeger
Container Related -> Containerd, Harbor
Networking -> Envoy, CoreDNS
DB -> etcd
K8s Application Management -> Helm

標題: 「ssh-tunnel 詳細教學」
類別: tools
連結: https://iximiuz.com/en/posts/ssh-tunnels/

ssh 對許多人來說並不陌生，但是對於一些稍微繁雜的環境很多時候就會使用 ssh tunnel 來進行一些反向代理或是不同的處理，複雜的可能還會搭配 .ssh/config 來簡化多節點的跳躍與存取。
此外也有部分人會使用如 sshuttle 之類的工具來簡化操作讓一切更為簡單

而本篇文章則是專注於 ssh tunnel 的介紹，其介紹非常詳細，從指令的用法到圖解整個運作與流程都包含，對於 ssh tunnel 不熟或是想要複習的讀者非常推薦閱讀這一篇文章，能夠幫助你重新理解 ssh tunnel 的流程與用法

標題: 「ssh-jump 教學」
類別: tools
連結: https://www.tecmint.com/access-linux-server-using-a-jump-host

上週分享了關於 ssh tunnel 的用法，而本篇文章介紹的則是另外一個常用功能, SSH Jump Server。

基於安全與其他考量，很多時候目標伺服器本身都沒有辦法直接存取，都會透過 bastion host/jump server 的概念來保護，因此如何快速的存取後端被保護的 server 則是一個需求。
從概念上來看非常簡單，就是先從使用者的電腦存取到 jump server 接者再從 jump server 存取到後端的伺服器。而 SSH 的指令中可以透過 -J 的方式來描述要如何存取 jump server。

當基本 ssh 沒問題的時後，可能就會開始考慮 SCP 與 SSH Tunnel 等相關用法該怎麼整合到 Jump Server 中，為了避免整個指令愈來愈龐大與難以管理，這時候都會推薦透過 ssh config 的方式來設定每個 host 存取的方式
文章中有介紹如何透過 ssh config 來描述 jump server 的用法，可以針對不同的機器採用不同的 username/key 等方式分別認證

標題: 「Chick-fil-A Edge 端 Kubernetes 多年經驗回顧」
類別: usecase
連結: https://medium.com/chick-fil-atech/enterprise-restaurant-compute-f5e2fd63d20f

Chick-flt-A 於 2018 年的時候的有發表過一篇如何於分店都透過少量機器搭建一台地端的 Kubernetes 叢集來提供服務，而這些概念也實實在在地跑了四年，

整個專案名稱為 Restaurant Edge Compute platform，其目的是希望為每一個餐廳打造一個穩健的平台讓 DevOps 團隊能夠順利的去管理與部署各種應用程式來幫助餐廳的營運，從供應鏈，餐廳管理到面對客服的服務

打造平台前首先必定要執行的就是審視當前的工具，團隊發現大部分的工具都是跟 Cloud 息息相關，反而有資源考量的 Edge 端沒有太多的關注點，此外有些商業工具不是沒有辦法大規模部署(上千k8s叢集)不然就是對方的授權模式與公司需求不和，因此最後的決定就是由 Chick-flit-A 自己動手來管理與維護這些 k8s 叢集。

#硬體
最初的設計是使用 Intel NUCs 作為餐廳內的小型伺服器，以三台 NUCs 為基準搭建一個 k8s 叢集來提供基本的 HA 概念，而這個設計直到現在依然繼續採用
#OS
最初的設計是透過 Ubuntu 作為基底 OS 並且搭配一些 script 來處理自動化的部分，此外希望可以達到一個隨插即用的等級，也就是 Intel NUCs 送到餐廳後就可以無腦開機自動設定完畢，不希望餐廳內還有任何手動設定的步驟。
#Kuberentes
一切的設計與操作都希望跟者業界標準去執行，因此團隊選擇了由 Rancher 所開發與維護的 K3s 作為 Kubernetes 版本，同時因為需求是地端而非雲端上面的各種整合功能，k3s 的設計恰恰的符合需求，因此團隊目前沒有任何計畫去改用其他的 k8s 版本

文章後面還有介紹很多如 GitOps/RollOut/API...等各種議題的反思與學習

標題: 「手把手教你系統設計」
類別: others
連結: https://www.hiredintech.com/system-design

今天介紹的這個網站是一個非常適合練習與學習系統設計的網站，該網站探討了系統設計於實務上的範疇，搭配些許影片進行一系列的介紹，此外除了基本的系統設計外，也探討了 Scalability 這個非常重要的概念，特別是若要設計一個有此特性的系統時有哪些點需要考慮
最後以搭建一個簡易版本的 Twitter 為範例開始逐步探討，包含
1 釐清問題與需求
2 High-Level 設計
3 Low-Level 的潛在問題
4 其他如 DB, Traffic 等延伸議題

對於想要練習系統設計相關題目的人非常值得花點時間跑完該網站

標題: 「Podman v4.4.0 將逐漸拋棄CNI作為其底層網路架構」
類別: tools
連結: https://github.com/containers/podman/releases/tag/v4.4.0

Podman 本週正式釋出其 v4.4.0 版本，其 release note 裡面有一個改動非常有趣
「CNI is being deprecated from Podman and support will be dropped at a future date. Netavark is now advised and is the default network backend for Podman.」

簡單來說，過去 Podman 使用的是 CNI 的架構來為其 container 提供網路功能，而從這個版本開始就正式標示為 deprecated 的版本並且於未來的版本將不再繼續支援
由於 Podman 本身就是一個本地開發測試用的軟體，同時本身也沒有透過 CRI 介面去支援 Kubernetes，因此這個改動對於 Kubernetes 本身沒有任何影響，單純是 Podman 自己生態系的改動。

取而代之的則是由另外一個專門為了 Podman 生態而開發的底層網路架構, Netavark(https://github.com/containers/netavark)。

其官網敘述非常直白
「Netavark is a rust based network stack for containers. It is being designed to work with Podman but is also applicable for other OCI container management applications.」
基於 Rust 開發並且以 Podman 為主不過其他 OCI 相容的容器也可以使用。

至於為什麼 Podman 要切換過去，我認為主要有以下幾個原因
1 CNI 的發展目的更適合 Kubernetes 這種多節點的叢集架構，Podman 的目標則是單一節點上的容器管理系統
2 隨者使用者的使用環境愈來愈複雜，CNI 有時候很難輕易地達成環境架設，特別是想要讓容器運行到多層網路之中，譬如多網卡等情境，可以弄但是就麻煩
3 CNI 是純框架設計，功能全部仰賴各種 Plugin，如 Flannel,Calico,Cilium…etc，所以各種功能都還要仰賴第三方 Plugin 去實作，不然就需要自己完整實作一套 CNI Plugin

相對於 CNI 來說 Netavark 的特色有
1 不仰賴各種 Plugin，本身就將過往所有網路功能都直接實作掉，也意味者所有的網路功能都直接實作於 Netavark 中，沒有其他 Plugin 的需求
2 不同於 CNI 各種串接來串接去的 Plugin 方式， Netavark 單一工具的執行方式其實可以用更短的時間去設定完成整個容器網路，對於單一節點的應用上可以榨取更多時間


如果本身是一個 Podman 愛好者的話，可以花些時間去看一下 Netavark 以及其 DNS 夥伴 Aardvark 的相關文章以方便未來更加了解 Podman 的使用與除錯

標題: 「利用 ChatGPT 來提高團隊 Kubernetes 除錯效率」
類別: tools
連結: https://medium.com/dev-genius/k8s-chatgpt-bot-for-intelligent-troubleshooting-36e0a4a071c5


隨者 ChatGPT 最近的爆紅，愈來愈多行業與領域都嘗試透過 ChatGPT 來提升整體效率，雖然有使用過的人就知道很多時候 ChatGPT 沒有辦法就問題給予非常精準的答案甚至給予錯誤的答案，但是大部分時候都可以幫忙省去 Google 的時間

今天這篇文章作者想要分享一個透過 ChatGPT 來查詢 K8s issue 的小專案，該專案中 ChatGPT 會搭配 AlertManager 一同使用，將 Alertmanager 送來的錯誤訊息轉送到 ChatGPT 中讓其提供一些基本的概念以及除錯方式，最後將這個專案給整合到 Slack 中。

雖然該專案不一定可以輕易導入，但是可以看到愈來愈多人用不同的方式來使用 ChatGPT，花點時間玩看看這個工具，看看如何可以用其為自己的日常工作提供不同面向的變化吧

標題: 「讓 ChatGPT 考看看 AWS 證照?」
類別: others
連結: https://medium.com/@miguelsalva/chatgpt-goes-certified-aws-82747a2e4619

隨者 ChatGPT 的橫空出世，作者想要試試看這類型的服務是否有辦法通過各種 AWS 的相關證照，由於考試規則的限制與規範，並沒有辦法直接將 ChatGPT 套用到正式考試中，因此作者就透過 AWS 所公開的示範考試題目來逐一測試 ChatGPT

作者總共嘗試了 12 個不同的 AWS 證照，包含
1 CLF-C01: AWS Certified Cloud Practitioner
2 SAA-C03: AWS Certified Solutions Architect — Associate
3 DVA-C01: AWS Certified Developer — Associate
4 SOA-C02: AWS Certified SysOps Administrator — Associate
5 SAP-C02: AWS Certified Solutions Architect — Professional
6 DOP-001: AWS Certified DevOps Engineer — Professional
7 ANS-C01: AWS Certified Advanced Networking — Specialty
8 DAS-C01: AWS Certified Data Analytics — Specialty
9 DBS-C01: AWS Certified Database — Specialty
10 MLS-C01: AWS Certified Machine Learning — Specialty
11 SCS-C01: AWS Certified Security — Specialty
12 PAS-C01: AWS Certified: SAP on AWS — Specialty

每個證照都列出考試分數(滿分1000)以及通過的門檻分數。 最後 ChatGPT 順利的通過四個 Pass(No 1,3,4,11) ，其中有三個 Fail (2, 8, 12)的分數差一點就可以通過了。

根據證照的難易度來看的話， ChatGPT 通過了基礎等級的認證，兩張 Associate 的相關證照，一個 Specialty 等級的證照，而沒有通過半張 Professional 等級的證照

從這個角度來看，繼續追求證照作為條件的市場會不會受到影響?

標題: 「Tinder 為何以及如何打造屬於自己的 API GW」
類別: usecase
連結: https://medium.com/tinder/how-we-built-the-tinder-api-gateway-831c6ca5ceca

這篇Medium上的文章講述了Tinder是如何建立其API Gateway的，為了解決之前客戶端直接向Tinder的主應用伺服器發送請求的問題，Tinder創建了自己的API Gateway，API Gateway採用了微服務架構，這使得Tinder可以更輕鬆地管理其API Gateway，並支持更快的開發和部署。

Tinder的API Gateway是由Java撰寫，並使用Netflix的Zuul框架構建。Zuul是一個網關服務，允許開發人員建立反向代理和路由器，這些路由器可以將請求路由到網絡上的其他服務。Zuul還提供了一些內置的功能，如路由、過濾和反向代理，這些功能使Tinder可以更輕鬆地管理其API Gateway。

Tinder的API Gateway還具有一些特殊的功能，如基於用戶的路由、可靠的請求/回應記錄和指標追蹤等。基於用戶的路由允許Tinder根據用戶屬性（例如，使用語言、地理位置等）將請求路由到相應的伺服器。請求/回應記錄可以使開發人員更輕鬆地追蹤數據，並定位潛在的問題。指標追蹤允許Tinder監控API Gateway的性能和可用性。

總之，這篇文章介紹了Tinder是如何建立其API Gateway的過程和一些特殊功能，API Gateway的構建使Tinder可以更輕鬆地管理其API，實現更快、更安全和更有效的API管理和開發。閱讀這篇文章可以讓讀者對於如何構建API Gateway有更深入的了解，同時可以學習到一些關於微服務架構的知識。

標題: 「Tinder 如何打造一個專屬團隊使用的設計系統平台 Obsidian」
類別: usecase
連結: https://medium.com/tinder/building-obsidian-tinders-design-system-e127770d8e3f

這篇文章講述了Tinder是如何建立其設計系統 "Obsidian" 的，以及如何將其整合到Tinder應用程式中。 Obsidian旨在提供一組統一的設計樣式和元素，以使Tinder應用程式的開發更加一致和高效。

文章開始介紹了Tinder設計團隊如何決定建立設計系統。在Tinder快速發展的初期，Tinder的設計並不一致，這導致開發人員和設計師之間的困難以及更多的維護問題。為了解決這些問題，Tinder決定建立一個設計系統，這樣所有人都可以使用同一套設計樣式和元素進行開發。

接下來，文章介紹了Obsidian的幾個核心要素，包括顏色、圖標、字體、排版、按鈕等。這些要素都是Tinder開發人員在開發Tinder應用程式時需要考慮的重要因素。

此外，文章還介紹了如何使用Obsidian來開發Tinder應用程式。Tinder使用React Native來開發其應用程式，因此，Obsidian也需要與React Native進行整合。為此，Tinder設計團隊開發了一個名為 "Rally" 的React Native元件庫，這個元件庫包含了許多Obsidian中的設計元素，並且可以與React Native一起使用。

總之，這篇文章介紹了Tinder是如何建立其設計系統 "Obsidian" 的，以及如何將其整合到Tinder應用程式中。 Obsidian提供了一組統一的設計樣式和元素，使Tinder開發人員可以更加一致和高效地進行開發。通過使用Obsidian，Tinder能夠更好地管理其應用程式的設計和開發，並提供一致性的用戶體驗。

標題: 「Kubernetes 網路除錯之旅」
類別: network
連結: https://www.hwchiu.com/k8s-network-debug.html

許久沒寫原創文章，因此最近就將去年於 LINE & CNTUG #49 Meetup 的分享內容給文字化。

本篇文章嘗試用簡易的方式去介紹 Kubernetes 內的網路複雜性，強調簡單易用的網路功能背後是有多少複雜元件牽扯其中，因此要除錯網路問題沒有想像中的這麼簡單。

為了讓整體網路除錯更有效率與系統性，文章內闡述了一種網路思維來面對網路問題
1 分析網路流向，是東西向還是南北向
2 釐清問題發生點，到底問題是發生於哪個層級中

有了上述思路後，搭配畫圖的方式將整個架構圖勾勒出來，並且逐一檢查縮小問題發生點，最後找出真正造成網路不通的元兇。

標題: 「kubecolor，色彩化 kubectl 的輸出讓你更快辨識常見欄位」
類別: Tools
連結: https://blog.devgenius.io/k8s-kubecolor-introduction-3d650effc36f

今天分享的是一個小工具，本質上就是 kubectl 只是對於輸出結果進行色彩化的改造，讓原本預設全部都一樣顏色的指令輸出加上不同顏色
舉例來說透過 kubectl describe pod 觀看資訊時，不同的顏色使得觀看整個結果時會更加順眼與有效率，可以清楚的知道哪些字是“key"哪些是”value"，特別是要找尋特定 key 的時候我的經驗會比純黑白來得有效率一點，最簡單的用法其實可以直接透過 alias 取代 kubectl，因此實務使用上也不會有任何新指令的學習，有興趣的人都可以試試看

標題: 「完整介紹 Terragrunt，讓你理解其角色與用途 」
類別: Tools
連結: https://blog.devops.dev/a-complete-overview-of-terragrunt-fbebb53fbd42

隨者 IaC 概念的普及，愈來愈多團隊使用 Terraform 來管理自身架構，除了基本撰寫 TF 檔案外，使用官方 Module 或是自行撰寫 Module 都可以大幅簡化重複的程式碼來達到 DRY 的概念。
然而某些情況下，想要將一整套應用服務部署到不同環境時，甚至是不同 cloud providers 的時候就會開始思考整個資料夾的結構要怎麼設計， Terraform Module 要怎麼設計與使用才可以盡可能地減少重複程式碼。

舉例來說，很多時候會透過
1. Module 描述很多底層元件與部署
2. Main.tf 去呼叫各個 module 來組合出一個完整應用

如果想要將 main.tf 給部署到不同環境，不同地區等的時候，最直接的方法就是將 main.tf 給複製多份搭配不同變數即可
然而這種情況下對於要維護 main.tf(甚至有多個*.tf) 檔案的話就會變得稍微麻煩。
有些人會透過 soft-link 的方式確保多個資料夾共享一份檔案來簡化維護而有些則是會用其他工具來幫助管理 Terraform，而本篇的 Terragrunt 則是後者工具中非常知名的一個解決方案。

Terragrunt 算是一個 Terrafrom Wrapper，因此能夠以更上層的角度去幫忙管理與呼叫你的 TF Code，文章開頭就直接闡明使用 Terragrunt 的幾個理由，包括

1. Keep your backend configuration DRY
2. Keep your Terraform CLI arguments DRY
3. Execute Terraform commands on multiple modules at once
4. Execute custom code before or after running Terraform.
5. Wo rk with multiple cloud accounts

(1) 的情境是當你環境愈來愈多時，每個 TF 應用你都會撰寫 backend 來確保 TF code 可以被多人共享與協同合作，而 backend 要避免路徑重複以免互相蓋來蓋去造成問題。基本上這個問題只要仔細與小心，每次創建新資料夾時都有準確去修改就可以解決這個問題，只是通常隨者架構愈來愈龐大，參與的人愈來愈多，有時候就會發生人為錯誤，創建資料夾直接複製其他的檔案忘了改，或是路徑沒有按照規則去撰寫。
Terragrunt 提供了一些方式去簡化操作，規劃一次後續使用就無需擔心一切都會自動被處理好

其餘的好處文章內都有詳細介紹用法與情境，對這套工具不熟悉的可以看看這篇文章，非常詳細的講述整個概念

標題: 「Reddit 於 3/14 升級 Kubernetes 失敗的報告總結」
類別: Usecase
連結: https://www.reddit.com/r/RedditEng/comments/11xx5o0/you_broke_reddit_the_piday_outage/?rdt=39706

整篇文章滿長的，以敘述為主然後帶出一些關鍵點，這邊幫忙節錄幾個重點，有興趣的可以閱讀全文


1. Reddit 從 2009 就開始導入雲端架構，並且非常早期就使用 Kubernetes
2. 歷史包袱導致架構中的 Kubernetes 都採用不同的方式建置與維護，譬如有一批就是使用 Kubeadm
3. 團隊有進行 Kubernetes 的升級演練，即使遇到問題也有順利解決並且紀錄
4. 升級時間定於 03/14/2023 19:00 UTC (Kubernetes 1.23 -> 1.24)
5. 升級後兩分鐘發現系統問題，網站無法使用，第一件觀察到的事情就是 Monitoring 上面完全收不到任何 Metrics，沒有 Metrics 就如同瞎子摸象很難馬上知道發生什麼事情
6. 有發現一些 DNS 的問題，但是這問題是首次遇見，先前各種測試升級都沒有遇到
7. 部署失敗想嘗試執行 Plan A，就是馬上退版，但是 Kubernetes 並沒有提供 Downgrade 的方式，畢竟每次升級都會有些許的 Scheme 與 API 版本修正，唯一的降板方式就是需要透過整個狀態的備份與還原
8. 團隊有開發專屬的備份與還原應用程式，不過該程式只有餘測試環境中反覆測試，並沒有真的對 Production 環境測試，因此對於要不要運行這個備份程式其實團隊是有信心疑慮的，也不確定跑下去要花少時間，這段時間整個網站停機要多久。因此決定先行繼續研究問題嘗試修復
9. 花了將近兩個多小時觀察到各種現象然後沒有辦法解決，於是決定備份還原
10. 事後檢查原因是因為 Calico 沒有辦法正確部署相關的 Routing 規則，原因是因為 Calico 用來尋找節點的 nodeSelector 於 K8s 1.24 被改變了
11. 前面提到，該 K8s 是由 Kubeadm 建造的，請閱讀下列連結中關於 "node-role.kubernetes.io/master" 的段落 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade


如果要更精簡的說法就是
Kubeadm 從 1.23 -> 1.24 的升級有改變其 control plan 的預設 label，這會使得所有相依這個 label 的服務出現問題

標題: 「少少幾行設定就解決了 Kubernetes 那 gRPC 服務的 scaling 問題」
類別: network
連結: https://medium.com/jamf-engineering/how-three-lines-of-configuration-solved-our-grpc-scaling-issues-in-kubernetes-ca1ff13f7f06

本篇文章主要是探討 gRPC 於 Kubernetes 內因為負載平衡所導致的流量分配問題。
作者團隊中於 Kubernetes 中部署 gRPC 服務，由於 Kubernetes 內建的 Load-Balancing 是基於 L4 去處理，而 gPRC 則是基於 HTTP/2。
其中最大的問題是 HTTP/2 的一個精神就是基於一條 TCP 連線來傳送各種訊息，這種狀況遇到 Kubernetes L4 Load-Balancer 就會發生負載平衡根本發生不了。

試想一下今天 Kubernetes 中有兩個 gRPC Client 以及兩個 gRPC Server，今天所有的 Client 與 Server 都已經順利建立好 TCP 連線來處理後續 gRPC 訊息。

今天 gRPC Client 因為效能問題於是動態調整 Pod 的大小，從兩個變成四個，因此這種狀況下就會變成 4個 gRPC client 面對 2個 gRPC server。
一切運作正常直到 gRPC server 負荷不了，因此也自動調整 Pod 大小變成 四個 gRPC server。
這時候問題就來了，由於 TCP 連線已經建立完畢，所以先前的四個 gRPC client 還是會繼續把流量送給前面兩個 gRPC server，後面兩個新增的 gRPC server 則是不會接送到任何流量。

為了讓流量可以順利平均分攤，只好透過一些組合來重新調整 Pod 的數量最終達到流量分攤。

作者最後發現 gRPC 的 Server 有提供連線相關的設定，其中最重要的兩個設定分別是
MAX_CONNECTION_AGE
以及
MAX_CONNECTION_AGE_GRACE

其中官方關於 MAX_CONNECTION_AGE 的一個節錄也提到該選項的用法
This option can force the client to periodically reconnect to a L4 LB which allows spreading load more quickly.

對於 gRPC 效能與流量用法有興趣的人務必好好研究這個用法

標題: 「移轉 Legacy Application 到 Kubernetes 需要理解的四種 Pattern」
類別: Kubernetes
連結: https://itnext.io/4-container-design-patterns-for-kubernetes-a8593028b4cd

本篇文章作者描述將過往應用程式轉移到 Kubernetes 內很常遇到的問題，譬如
1. 輸出一律寫到檔案而非 Stdout
2. 不支援 Prometheus 因此沒辦法整合到 Monitoring 系統
3. 只能支援 HTTP 連線
... 等

大部分這些情況都可以透過修改程式碼的方式來完成，然而既然被稱為 Legacy 應用程式就有很大的機會這些應用程式現在屬於一種難以撼動的狀況，可能現有的人已經不熟當初的架構與程式語言，更別說要對其進行修改測試與發佈。

對於新專案來說這種情況不會發生，但是對於要將舊有服務導入到 Kubernetes 的情境中則並不是不可能發生，因此這時候如果可以擅用 Container 與 Pod 的特性來補足這些功能同時又不需要修改程式碼則是一個值得探討的方向

作者用非常淺顯易懂的方式來描述四種 Kubernetes 內很常見的設計模式，包含
1. Init Container
2. Sidecar
3. Ambassador
4. Adapter

如何利用這四種不同的模式來解決各種 Legacy 應用程式可能會遇到的問題，有興趣的可以稍微複習一下這些名詞與概念

標題: 「以 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 提供一個完全友善的開發環境，讓開發者可以更簡易的去測試自己的東西同時也不擔心會影響彼此