這裡是 WWW 第拾柒期，Wow Weihang Weekly 是一個毫無章法的個人週刊，出刊週期極不固定，從一週到五年都有可能。初期內容以軟體工程為主，等財富自由後會有更多雜食篇章。
Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency / Henning Jacobs
如何設定 K8s Pod 的資源最低需求 containers.resources.requests 和最高限制 containers.resources.limits 一直是門藝術，最低需求影響 scheduler 如何安排 pod，最高限制，尤其是 memory，可能會有 OOM kill 把 pod 殺死。
@hjabocs 分享了幾個作法：
- 測來測去發現停用 CPU CFS 的 latency 最小
- 要記得你的 node 會被 system、kubelet，還有 container runtime 佔去部分資源 😨
- 用 Admission Controller 設定和 requests 一樣的 limit，防止 overcommit
- 知道你的 pod 的 container-aware limit，例如 JVM 就是 maxheap，node cluster 就是你設定的 process number
- 用他的本人寫的 K8s Resouce Report 來看冗余資源可以幫你省下多少美金
- 可以設定一些 priorityclass 很低的 pod 作為 buffer capacity，讓資源不足時他們可以先被踢掉應急，再慢慢等 Cluster autoscaler 來 privision 新 node
- 又在老王賣瓜推銷自己寫的 downscaler，離峰時間自動關機省錢
Rust Logo is a Bike Chainring!
關注 Rust 社群這麼久了，直到最近才意識到 Rust 的 Logo 其實是單車的大盤（踏板旁的齒盤），原意是 Rust 作者們常常騎單車，而且單車大盤通常都有點生鏽。身為單車愛好者怎能不愛 Rust ♥️
Cardinality is key
最近遇到了寫出很爛的 Prom Query 還有短時間發送太多 Query，導致整個 Prometheus 服務火爆炸開，當然，Prometheus 的 High Available 有很多種做法，例如導入 Thanos/Cortex，使用外部 storage 等等，不過根本下手，應該要改善 metrics 和 query 這層的效能，否則只是矇著眼騙自己。
這篇文章開頭就點出最重要的一句話： Prometheus 的效能幾乎皆取決於 label cardinality 。這裡的 cardinality 指的是唯一值的數量。
文中簡單計算了 label cardinality 多容易爆炸，假設我們有一個 Node.js 服務有 100 replicas， 會追蹤 heap 上新生，中生代等 12 種相關指標，若系統每 30 秒抓一次資料，拉三個小時的報表算起來就有 100 * 12 = 1200 個 series，也就是有 1200 * (60 * 60 * 3 / 30) = 432000 個資料點，聽起來不太多對吧，但通常一個 Prometheus 不會只看一個 metrics 也不只有一個服務，真實的爆炸程度超乎想像。
作者提供了一般性通則： 避免 cardinality 超過 10 的 label 。但這僅僅是通則，如果 replicas 數量不會太大，cardinality 超過 10 也可接受。
你會想說，媽的我不能追蹤這麼細，還要蒐集 metrics 幹啥吃？其實 nginx-ingress 團隊也因為 uri、remoteAddress 等 label cardinality 太爆炸而移除過於細緻的 label。
文末畫龍點睛的一句話，分享給大家細細品味：
Metrics giving you a high level view of your subsystems, logs the blow-by-blow of individual requests.