0%

[閱讀筆記] - Week 4

Kubernetes 多租戶實作的挑戰

Ref: https://faun.pub/kubernetes-multi-tenancy-a-best-practices-guide-88e37ef2b709?gi=6e43dc5ed7a

這邊跟大家分享一篇關於 Kubernetes 多租戶的相關文章,該文章中探討到底多租戶的定義,以及實現上的難易程度

  1. 多租戶可分成軟性與硬性兩種隔離, Kubernetes namespace 可以視為軟性隔離,而硬性隔離則是希望能夠更強力的隔離所有資源,文章中提到了 vClusters 的概念,連結放在最後
  2. 作者認為多租戶的 Kubernetes Cluster 實際上也會帶來一些限制,讓某些功能變得不方便使用。
    a. 基於 namespace 的租戶隔離方式就只能大家都同樣一個 k8s 版本,同時有一些支援 RBAC 設定的 Helm Chart 可能就不方便使用。
  3. 作者這邊反思提出一個問題,為什麼真的需要多租戶的 Kubernetes 叢集,不能夠用多個單一租戶的 Kubernetes 叢集來取代?
    a. 真的有這樣的實例,但是其實成本過高且沒效率。
    b. 如果公司內每個開發人員都需要一個自已的 k8s來操作測試,規模一大的話你每個月的成本非常可觀,因此如果可以有一個多租戶的 k8s,就可以解決這些問題
  4. 多租戶實作上的挑戰,作者這邊列出幾個問題,包含使用者管理,資源分配以及如何隔離
    a.基本上每個組織本身都已經有管理使用者的解決方案,譬如 AD/LDAP 等,如果要將這些使用者的認證授權與 kubernetes 整合,推薦使用 dex 這個支持 OpneID/OAtuth2 的解決方案,幫你將 Kubernetes 與外部資料系統整合
    b. 底層資源的共享,避免單一租戶過度使用導致其他租戶不能使用。資源包含了運算資源,網路頻寬等。作者列出透過 Resource Quotas 等可以幫忙限制運算資源,但是並沒有說出網路頻寬這部份該怎麼處理。這部份我認為需要導入更多的network qos解決方案來限制,應該會需要cni以及外部交換機路由器等來幫忙
    c. 最後則是互動上的隔離,要如何確保這些多租戶不會互相影響彼此,甚至攻擊彼此。這部份可能要從 NetworkPolicy 來處理網路流量,同時透過 vCluster的方式來提供相對於 namespace層級更強烈的隔離,確保彼此不會互相影響。
  5. 最後,作者列出了一些關於多租戶的可能解決方案,包含了 kiosk, loft等
    結論來說就是,今天你如果有多租戶的需求,請先問自己,你需要什麼等級的多租戶管理,再來則是三個重點問題要先想清楚,你要怎麼處理
    1) 如何管理使用者/租戶
    2) 系統資源要如何分配與限制
    3) 如何真正有效的隔離這些租戶
    如果有這方面的需求,可以先看看別的開源軟體怎麼實作,再來思考是否滿足需求,如果要自己實現,有哪些好的設計值得參考!

GitOps 到底解決了什麼問題

Ref: https://www.hwchiu.com/gitops-book-ch1.html

GitOps 的概念我認為還是目前還是相當新穎,但是有觀察到愈來愈多的工具在往這一塊發展,包含最近 Rancher 2.5 就推出自己的 GitOps 工具來滿足大規模邊緣環境部署。
這邊跟大家分享我最近看的一本關於 GitOps 的電子書,整本書篇幅不多,主要分成下列章節
What GitOps isWhy it was inventedWhat problems it solvesThe differences between the principal GitOps toolsImplementation challengesAlternatives to GitOpsThe future of the GitOps movement
我閱讀的同時也隨手記錄其重點,全部分成六篇短文並且記錄下來,接下來則會每天分享一篇跟大家一起學習 GitOps 的概念與玩法

SO_REUSEPORT 提昇 Nginx 效能

Ref: https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/

今天要來跟大家分享一個單一節點如何提高應用程式吞吐量與服務能力的方式
這個方式主要探討的是應用程式對於網路連線的 I/O 模型,試想一個常見的使用範例。
一個主要的 Process 會去聽取一個固定的 port number (ex port 80),並且通知後面眾多的 worker 來幫忙處理這些封包連線,而這些 worker 的工作就是處理連線。
整個架構中是一個 1 v.s N 的狀況, 一個負責 Listen ,N個負責處理連線內容
而今天要分享的則是想要讓架構變成 N v.s N 的狀況, 會有 N 個 Process, 每個 Process 配上一個 Worker。
而這 N個 process 同時共享一樣的 Port (ex, port 80)
這種情況下可以減少多個 worker 共享一個 listen socket 時的各種保護機制,取而代之的則是每個 listen socket 配上一個專屬的 worker 來處理。
要達成這樣的架構非常簡單,只要透過 SO_REUSEPORT 這個 socket option 告
訴 Kernel 當前這個 PORT 可以重複使用。
當封包送到 kernel 後則是由 kernel 幫你分配封包到所有使用相同地址的 Listen Socket (Process)
根據 nginx 官方文章的測試,這種架構下對於 RPS (Request per second) 有顯著的提升,有興趣的可以看看下列兩篇文章

本地開發 Kubernetes 的各種選擇

Ref: https://www.dex.dev/dex-videos/development-clusters

不知道大家第一次接觸 kubernetes 的時候都是使用哪套解決方案來打造你的 K8s 叢集? 亦或是作為一個開發者,你平常都怎麼架設 K8s 來本地測試?
這篇文章提到了作為一個 Local Kubernetes Cluster 幾個選擇,並且點出了三個需要解決的問題

  1. Container Registry, 作為一個開發環境,應該不會想要每次測試都要將 Container Image 給推到遠方,譬如 dockerHub, Quay,這樣整體效率低落
  2. Builder, 如何有效率的幫忙建置你的應用程式,並且與 Kubernete 整合,讓開發者可以更專心於本地開發,而不要擔心太多 k8s 之間的設定
    https://www.dex.dev/dex-videos/development-clusters
  3. Runtime, 底層使用哪套 Container Runtime, 譬如 docker/containerd/cri-o
    註: 我個人對第三點其實沒太多感覺,不覺得本地測試這個會影響太多
    後面列舉了當前知名的相關專案,譬如 KIND, K3D, MicroK8S, Minikube 以及 Docker for desktop. 並且簡單的比較了一下這些本地開發的差異。
    不知道大家平常本地開發時,都會用哪一套?
    我個人是比較常使用 KIND 來測試,畢竟輕量化且同時支援多節點,環境也乾淨,測試起來也方便。

Docker 網路模型介紹

Ref: https://www.hwchiu.com/docker-network-model.html

這邊來跟大家分享一下一些入門文章,主要會針對 Docker 的網路運作原理進行探討,這部分系列文章會比較入門,相對於過往動不動就 kernel 的文章比起來會平易近人許多
我認為學習 Docker 的網路模型還滿重要的,因為一旦學會這些運作原理以及概念,之後銜接到 Kubernetes 底層 CNI 的運作原理就會有覺得學起來不會太痛苦,因為滿多部分都是相同的原理與作法去實作的。
有興趣的人歡迎看看這篇文章,不吝指教

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程,歡迎有興趣的人參考並分享,裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外,歡迎按讚加入我個人的粉絲專頁,裡面會定期分享各式各樣的文章,有的是翻譯文章,也有部分是原創文章,主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來,裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Welcome to my other publishing channels