標題: 「2021年回顧，因為 DB 的效能的爭論所以我女友跟我分手了....」 類別: usecase 連結: https://ottertune.com/blog/2021-databases-retrospective/

摘要:

2021 對於 DB 行業來說發生了許多風風雨雨，作者列出幾個觀察到的現象並且給予一些評論

「Dominance of PostgreSQL」 愈多愈多的人開發一個新的應用程式時首選都是 PostgreSQL 這個穩定可信賴且一直不停加入新功能的資料庫。 2010 年時 PostgreSQL 的開發團隊決定採取更為激進的方式來每年都要釋出一個主要版本的演進，其相容性的能力使得 PostgreSQL 能夠跟很多系統整合。 譬如前端介面如 Amazon Aurora, YugaByte, Yellowbrick 甚至 Google 都於 2021/10 宣布要讓 Cloud Spanner 支援 PostgreSQL

作者也嘗試從 Database Subreddit 上去爬文搜尋，基於過去一年所有發文去統計每個資料庫的出現次數，以結論來看 PostgreSQL -> MySQL -> MongoDB -> Oracle -> SQLite 等 這個過程不是非常嚴謹的統計分析，只是一個簡單的方式去觀察該論壇上大家都喜歡討論什麼資料庫而已。

「Benchmark Violence」 Benchmark 一直以來都是各個廠商展示軍火的地方，想辦法利用這些數據去說服大眾自己才是最棒的，作者列出去年三個激烈的 benchmark 討論

1. Databricks vs. Snowflake
2. Rockset vs. Apache Druid vs. ClickHouse
3. ClickHouse vs. TimescaleDB

作者也有參與上述血流成河的 Benchmark 的戰場，但是這些爭論的過程中作者失去了不少朋友，甚至連女朋友也一起離開了，作者回過頭來看這一切都 不值得，此外由於現在雲端的 DBMS 也有許多可最佳化的參數，要直接去比較彼此的優劣其實沒有這麼簡單。

後面還有「Big Data, Big Money」以及「In Memoriam」 兩個不同的議題，有興趣的可以點選全文閱讀

標題: 「使用 OpenKruise v1.0 提供更進階的 workload 部署與升級」 類別: tool 連結: https://www.cncf.io/blog/2021/12/23/openkruise-v1-0-reaching-new-peaks-of-application-automation/

Openkruise 1.0 版本釋出，該專案是 CNCF 沙盒層級的專案，主要是由阿里巴巴開發與維護，不久前的 Kubeconf 中阿里巴巴的議題也有 分享到有將此專案部署到期內部的 Kubernetes 管理平台

該專案主要是強化 Kubernetes 內應用程式的自動化，包含部署，升級，維運等面向，此外其架構是基於 Operator 去設計的，因此任何的 Kubernetes 叢集都可以安裝這個功能。 相對於原生的 Deployment 等部署方式， Openkruise 提供了

1. 強化 workloads 的部署方式，包含支援原地更新，金絲雀等不同的升級策略。
2. Sidecar 容器的管理，可以更方便地去定義想要自動掛到不同 workloads 上的 sidecar 容器。
3. 提供更多方便維運的功能，譬如可以針對 container 進行重啟，可以針對不同節點進行先行下載 container image，將一個應用程式給部署到多個 namespace 甚至還可以 去定義 Pod 裏面所有 containers 的啟動優先順序，如果 Pod 內的容器彼此之間有依賴性時就可以透過這個功能讓整個啟動過程更加順暢。

有興趣的可以研究看看此專案

標題: 「透過 Kubefarm 來自動化幫實體機器打造基於 Kubernetes in Kubernetes 的 Kubernetes 環境」 類別: Kubernetes 連結: https://kubernetes.io/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/

摘要: 本篇文章要介紹 Kubefarm 這個專案，該專案的目的是希望能夠於大量的實體機器上去創建各式各樣的 Kubernetes 叢集供不同團隊使用 為了讓整體的運作更加自動化，作者先行介紹何謂 Kubernetes in Kubernetes 這個專案，如何透過 Kubeadm 的方式於一個現存的 Kubernetes 專案 去部署 control-plane 並且透過這個 control-plane 去控管其他的 kubernetes 叢集，基本上達到的效果就如同各種 kubernetes service 服務一樣，使用者完全看不到 control-plane 的元件。

雖然透過這個方式可以很輕鬆地去創建新的 Kubernetes 叢集來使用，但是使用上覺得還是不夠方便，特別是這些實體機器還是會有不少手動的過程要處理， 為了讓整體流程更加自動化，作者團隊又基於 Kubernetes in Kubernetes 這個專案為基礎再開發更上層的專案，稱為 Kubefarm，一個如農場般可以快速於實體機器創建各式各樣 kubernetes 叢集的解決方案

Kubefarm 由三個專案組成，分別是 Kubernetes in Kubernetes, LTSP (PXE-Server) 以及 Dnsmasq-Controller 透過這三者專案的結合，實體機器會自動取得 DHCP 的 IP 地址並且透過 PXE 系統自動化安裝 OS，待一切都安裝完畢後又會自動地加入到現存的 Kubernetes 叢集中

整篇文章滿長的，是一過非常有趣的用法與研究，如果團隊是大量實體非虛擬化機器的讀者可以研究看看別人遇到什麼問題以及透過何種思路去解決的。

標題: 「Meta 如何打造一個供多團隊使用的 SLI/SLO 設定與觀測平台」 類別: usecase 連結: https://engineering.fb.com/2021/12/13/production-engineering/slick/

本篇文章是 Meta 公司的技術分享文，探討內部如何搭建一個觀測 SLO 的大平台，讓不同的應用程式團隊都可以更方便地去觀察是否有達到其設定的 SLO。

文章內容有點長，這邊稍微節錄一些重點，非常推薦大家花點時間看完全文

1. Meta 的產品多，同時規模又大，背後又有數千的工程師不停地部署新版本，因此維運團隊必須要有一個好的方式來維運這些服務，包含預期狀態，當前狀態以及有能力去分析問題。
2. 團隊決定從 SLI/SLO 為基準點去設定預期狀態以及量測所有服務的效能。
3. 團隊決定打造一個名為 SLICK 的系統來視覺化與控管所有服務的 SLI/SLO
4. 沒有 SLICK 以前，每個服務的團隊都有各自的處理與儲存方式，所以都要花費很多時間去研究每個開發團隊的文件與用法，整體工作效率會下降
5. 過去的系統也沒有維護超過一週以上的資料，所以後續團隊也沒有辦法針對這些部分去分析。

透過 SLICK 可以讓整個 Meta 達到

1. 每個服務都可以用一個統一的方式去定義 SLO
2. 可以維持資料長達兩年且資料的細度達到每分鐘等級
3. 有個標準化的視覺方式來呈現 SLI/SLO
4. 定期地將當前服務狀態發送到內部群組，讓團隊可以用這些報告來檢視服務的穩定度並進行改善

文章後半部分包含

1. SLICK 用法介紹，包含 UI 的呈現樣子，定期的報告內容以及相關的 CLI 介紹
2. SLICK 的架構，團隊是如何設計 SLICK 這個服務，用到哪些元件以及這些元件之間個溝通流向
3. 兩個使用 SLICK 來改善穩定度的案例，這兩個案例都有簡單的去識別化，主要是介紹這些團隊發生什麼問題，如何透過 SLICK 來改善以及改善後的效能。

標題: 「多年工作經驗總是搞砸電話面試， why ?」 類別: 其他 連結: https://kevin.burke.dev/kevin/phone-screens-broken/

本篇是一個面試經驗探討文，作者闡述自己雖然已經有十年多的工作經驗，但是部分面試工作上還是沒有很辦法的去展現自己的能力 特別是那些用電話面試的經驗，而此文就是關於電話面試的小小抱怨文

滿多的電話面試都會搭配 Coderpad 這個網站來要求面試者線上進行程式撰寫，而該網站就要求你使用線上編輯器並且將所有的程式碼都統一到一個檔案中 ，同時也不一定有辦法去撰寫相關的測試規則，這對於作者來說非常不喜歡。 作者平常習慣開啟多個視窗進行開發，一邊撰寫程式一邊透過測試來驗證當前撰寫的程式是否往正確的方向前進，同時也花費大量時間去調整自己喜歡的工具來輔助所有 程式碼的撰寫。而上述所有習慣都沒有辦法於 Coderpad 的單一編輯器上去完成。 此外面試過程中還會被問各種問題，譬如為什麼這個變數這樣命名，為什麼blablabla... 對於作者來說，有些概念要到快完成時才會最佳化，就很明顯不符合電話面試這種要一次完美的特色。

最後作者也分享了一下關於電話面試的問題想法，相較於問一些實際上工作根本用不到的演算法問題，不如問一些更貼切真正工作會用到的經驗與概念，譬如

1. 給面試者看一段 opensource 專案產生的 stack trace, 問問面試者能不能從這個 trace 看得出來大概可能是什麼問題
2. 如果你開啟一個 database transaction 過久，有可能會發生什麼問題?
3. 寫檔案到硬碟如果每次都只有寫一個 byte, 這可能會帶什麼樣的壞處?
4. 給定一個函數，請面試者描述會如何針對這個函式去寫測試案例

這讓我想到多年前也有接過電話面試直接問我 Linux 用幾個bit實作權限，但是面試官本身也非這個專頁，是哪個權限也沒辦法回答，也不能給清楚的 context，就如同教科書一樣一個問題一個答案，沒辦法針對面試者的疑問去解惑...

連結: https://medium.com/kudos-engineering/increasing-resilience-in-kubernetes-b6ddc9fecf80

今天這篇文章作者跟大家分享一些如何加強 Kubernetes 服務穩定的方式，這篇文章這邊做個簡單摘要一下 發生問題: 作者的 k8s 是基於 Google Kubernetes Service (GKE)的叢集，運作過程中有時候會發現部分節點當掉，最後導致部分的服務不能正確使用。這邊作者團隊從兩個角度出發去改善

1. 研究為什麼節點會一直當掉，與 Google Supporte Team 來回信件最後有找到問題點
2. 強化 Kubernetes 服務的韌性，就算有部分節點壞掉也要讓服務能夠繼續運行 ，本文主要的一些觀點也都是基於這邊發展 強化方式
3. 修正 Deployment 的數量，並且加上 Anti-Affinity，讓這些 Deployment 的副本能夠散落到不同的節點上，避免所有 Pod 都塞到同個節點，最後該節點出問題導致 Pod 全部出問題。
4. 所有需要被 Service 存取的服務都加上 Readess Probe 來確保這些服務都準備好後才會收到服務，避免一些請求被送過來確又不能正確處理
5. 加入 Pre-Stop 的使用，再裡面透過 sleep 10的方式，讓 Pod 要被刪除能夠將手上的封包請求給處理完畢 (請看註解補充) 註: 我個人認為第三點其實不太需要，比較漂亮的作法應該是實作 Singal Handler 去處理 SIGTERM 的訊號，收到此訊號後就不要再接受任何 Request 並且把剩下的工作處理完畢，當然如果這部份處理的時間過長，超過預設的 GracePeriod (30sec)，就會被 SIGKILL 給強制刪除。 要解決這個問題可能就要從應用程式下手去看如何改善，或是透過修改 Pod Spec 來提昇 GracePeriodTemination 的長短

連結: https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts

今天跟大家分享一個 UDP 於 Linux Kernel 內的 Race Condition 問題。這問題我以前於 Linux Kernel 3.14 也有採過一樣的雷，但是到今日都還沒有一個很漂亮的解決方案，這邊就快速的跟大家介紹一下這個問題> 是什麼，以及跟 k8s 有什麼關係

發生前提

1. 使用 UDP 這種沒有重送機制的協定
2. Kernel 有開啟 conntrack 此功能

發生條件

相同的 Client 短時間內透過 UDP (也許是不同 thread) 送出兩個 UDP 封包到外面，對於 Linux Kernel 來說，會希望透過 conntrack 來追蹤每一條連線，但是底層建立的時候會有一些會有一些機制，因此當兩個封 包同時進入的時候，有可能就會因為先後順序導致第二個封包被丟棄

可能發生問題

DNS 的請求封包預設情況下會同時透過 UDP 送出 A & AAAA 兩個封包，而這兩個封包如果很巧的採到這個情況，然後你的 A 封包就沒有辦法順利解出 DNS，最後就要等五秒的 timeout 來重新發送 下偏這篇文章就是 weave works 遇到 DNS 5秒 timeout 的問題，然後仔細的將我上面所寫的總結給解釋清楚，每一個步驟發生什麼事情，什麼是 conntrack 以及暫時的 workaround 是什麼 之後會在跟大家分享目前一些解決方法怎麼做

連結: https://itnext.io/how-to-set-kubernetes-resource-requests-and-limits-a-saga-to-improve-cluster-stability-and-a7b1800ecff1

今天這篇文章探討的則是 resources 底下的 request/limit 問題。 本文作者之前遇到一個非常規律的服務警告問題，花了非常多時間與步驟去查詢，最後才發現是 Pod 裡面 Resource 的設定不夠嚴謹與完善。 舉例來說， resources: limit: cpu: 1000m request: cpu: 100m 今天假設有一個服務描述，我對 cpu 的最低要求是 0.1顆，但是極限是 1顆 且有一個節點本身有 3 顆 CPU，這種情況下，我們對該服務設定多副本運行(10個). 那根據 request 的要求，10個副本頂多只需要 1 顆 cpu，所以非常輕鬆的可以將 10 個服務運行起來，但是如何今天遇到尖峰流量 ，每個 pod 都瘋狂使用 CPU會發生什麼事情？ 每個副本的極限都是 1 顆，因此 10 個副本就可以衝到 10 顆 CPU..而系統上只有 3顆，這就會造成 CPU 完全不夠使用，最後導致每個應用程式都在搶 CPU 使用，如果沒有特別設定相關的 nice 值來處理，可能會造 成關鍵 process 無法回應(案例中就是kubelet)。 這案例中 limit/request = 10x，作者認為這數字太大，它覺得合理的大概是 2x ~ 5x，並且最重要的是要定期去檢視系統上資源的用量， limit 要設定的合理，如果本身有很大量需求，建議還要搭配 node select, affinity/anti-affinity 讓每個 pod 最好找到適合的配置方式，然後也要避免尖峰流量到來時，系統資源被吃光甚至影響到 kubelet/kube-proxy 等底層服務的運作。

連結: https://medium.com/flant-com/cleaning-up-container-images-with-werf-ec35b5d46569

不知道大家有沒有遇過本地儲存空間滿了，再也抓不了 docker image 的慘痛經驗呢？ 本文就想要探討的是遠方 Container Image 上的管理問題，隨者時間演進，愈來愈多的版本產生，那作為管理者，我們要怎麼去> 看待這些 image，放任他們無限擴張嘛？ 這些資源背後都代表一個儲存空間，也就意味額外的成本開銷。 作者想要解決的問題是，如何設計一套自動機制去刪除用不到的 image tag，保留會用到的，為了解決這個問題，要先定義什麼叫做 "用得到的 image tag". 本文列舉了四種需要保留 image tag的情況 1) Production 環境正在使用的 image tag, 如果刪除了，遇到 ImagePullPolicy:Always 的情況那可真的麻煩了 2) 遇到緊急情況，應用程式需要退版，因此保留的 image tag 可不能只有當前版本，過往穩定版本也都要保留 3) 從開發角度來看需要的 image tag, 譬如我們開了一個 PR，這個 PR 有一個對應的 image tag, 再這個 PR 還沒有結束前，這個 image tag 應該都要保留讓開發者去驗證與使用 4) 最後則是特定版本號或是code name等專屬名稱 作者使用 werf 這套 k8s 建置佈署工具來幫忙，這工具除了常見的 build/deploy 外，還可以刪除遠方的 container image。 因此作者整合一套演算法，將其與 werf 整合，讓整個 CI/CD 的過程中能夠自動去產生新 的 image，並且根據需求去移除用不到的 image. 有興趣的記得點選下列原文來學習更多

連結: https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

不知道大家有沒有聽過 Open Policy Agent (OPA) 這個 CNCF 專案? 有滿多專案的背後都使用基於 OPA 的語言 Rego 來描述各式各樣的 Policy，譬如可以使用 conftest 來幫你的 kubernetes yaml 檢查語意是否有符合事先設定的 Policy。 本篇文章則是跟大家分享如何使用 OPA 來針對 Ingress 資源進行相關防呆與除錯，一個最基本的範例就是如何避免有多個 Ingress 使用相同的 hostname 卻指向不同的 backend service. 過往可能都是靠人工去維護 ，確保沒有一致的名稱，但是透過 OPA 的概念我們可以再佈署 Ingress 到 Kubernetes 前先進行一次動態的比對，確保當前設定符合所有 Policy，得到所謂的 Approved 後才能夠佈署進去。 有興趣的人可以看看這篇文章，甚至學習一下 OPA 的使用方式