organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

– M. Conway

這裡是 WWW 第捌期，Wow Weihang Weekly 是一個毫無章法的個人週刊，出刊週期極不固定，從一週到五年都有可能。初期內容以軟體工程為主，等財富自由後會有更多雜食篇章。

My FOSS Story

這篇文章是 Rust 社群非常有名的 Andrew Gallant (@burntsushi) 所撰，講述了他自身與 FOSS 的糾葛。文章裡面許多篇幅在描述 FOSS 中的負面事情，不過這也是開源社群較少提及和處理的一塊。這篇文章也可以視為是 burntsushi 針對最近 Rust 社群最大的 web framework Actix 的作者退出開源界的有感而發。節錄一些我覺得可以帶著走的實用想法：

  • 設立界線：開源即政治，網路上就是有一堆酸民，就算沒有，也有太多太多 issue 和 PR 壓得我們喘不過氣，把開源工作和個人生活切割開來，設立界線和停損點，自己的活自己安排。
  • 遵循「比例原則」：如果提出一個問題卻僅寥寥幾行，就用寥寥幾行回覆吧。
  • 問題重現：良好的問題回報能搭配簡單重現方式最棒，如果沒辦法，那就帶著作者一起 debug 吧！

作者最後雖然表列許多負面行為，但也說了 FOSS 仍然有許多有趣的經驗和美好。信任為開源之本，希望這篇文章能帶給 FOSS 界打滾的我們更多啟發。

Uncharted territory – discovering vulnerabilities in public Helm Charts

⚠️⚠️⚠️ 你的 Helm chart 安全嗎 ⚠️⚠️⚠️

專門做各大語言的開源套件安全性檢驗的 Snyk，除了檢驗原有的 npm、PyPI 等套件，最近開始檢驗起 Helm 官方的 stable charts 中每個 image 是否有安全性漏洞，並出一份安全性報告。報告指出：

  • 277 個 stable chart 中，68% 有高度安全性漏洞，但 64% 可以透過升級 image 來解決漏洞
  • 最常見的風險有：out-of-bounds reads/writes、access restriction bypass、NULL pointer dereference（一和三 Rust 完美解決）
  • dduportal/bats:0.4.0 是最常用的 image，也擁有最多漏洞。postgres:9.6.2 第二。unguiculus/docker-python3-phantomjs-selenium:v1 第三。

此外，Snyk 同時開源了一支方便檢查 Helm chart image 安全性的 Helm plugin，非常方便，除了需要註冊 Snyk 帳號順便竊取電子郵件之外。

Architecting Kubernetes clusters — how many should you have?

本篇文章說明不同數量的 cluster 規劃之應用場景與優劣勢，文內附有許多連結，值得延伸閱讀。

  • 單一大型共用 cluster：所有不同環境的 app 都在同一個 cluster
    • ✅ 資源利用率高
    • ✅ 便宜
    • ✅ 管理容易：CI/CD 流程、升級 k8s
    • 👎 單點故障機率高：k8s 升級失敗、clsuter-wide 元件壞掉
    • 👎 安全性較差：物理隔離程度低，可以透過 PodSecurityPolicy 處理，但並非易事
    • 👎 無物理資源隔離：資源隔離只能透過 resource request limit、ResourceQuota 處理，同樣不好設定
    • 👎 多使用者：較不安全，須通過 RBAC 額外設定
    • 👎 Cluster 不能無限制增長：node 和 pod 還有 container 在 cluster 中都有一個理論上限值，需注意。
  • 多個小型單一用途 cluster：不同環境，不同 app 都各自獨立一個 cluster
    • ✅ 縮小爆破半徑：一個 cluster 掛了就是一個特定環境的 app 掛了而已
    • ✅ 獨立隔離：每個工作負載（workload）都是獨立的環境、OS、CPU、memory
    • ✅ 較少使用者：更容易管理 cluster 的 access control
    • 👎 資源利用率低
    • 👎 比較貴：data plane 和 control plane 都增加了
    • 👎 複雜的跨 cluster 權限管理
  • 一個 app 一個 cluster：每個 app 的不同環境（開發、正式、測試）都放在同一個 cluster
    • ✅ cluster 可以為 app 量身打造（e.g. MongodDB 就可以用 zfs 的 node）
    • 👎 不同環境在同一個 cluster：測試或開發環境如果有 bug，可能會導致正式環境崩壞
  • 一個環境一個 cluster：按照測試、開發、正式等環境建立不同的 cluster
    • ✅ 隔離「正式」環境（不必解釋）
    • ✅ 最小化正式環境的 access control：除了 CI/CD，原則上沒有人需要進入正式環境
    • 👎 APP 之間沒有隔離
    • 👎 環境沒有針對不同需求最佳化：例如有需要 GPU 的 app，那就每個環境都需要裝一個 GPU node

我個人看完的結論是

  1. 先學好各種 resource request limit 和 RBAC
  2. 把 service mesh、service discovery、API gateway 這些基礎設施搞好，讓 inter-cluster 溝通無障礙
  3. 從 Cluster per environment 開始搞起，有需求再特化出 app-specific cluster
  4. 永遠記得 Conway’s law