35 posts tagged with "Kubernetes"

連結: 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) 如何真正有效的隔離這些租戶 如果有這方面的需求，可以先看看別的開源軟體怎麼實作，再來思考是否滿足需求，如果要自己實現，有哪些好的設計值得參考!

連結: https://github.com/kubernetes/kubernetes/issues/90066?fbclid=IwAR3d3oXBtTz2ChxmqXQmLGIrghUxN3Tz67EYWZiuzNfltqVedAlFheg3qLA

如果你機會跑過 kubernetes 1.18 版本，一定要試試看最基本的 kubectl get pods -o yaml，看看是不是內容裡面多出了非常多 f:{} 系列的檔案，導致整個 Yaml 變得非常冗長，閱讀不易，甚至想要抓取到最原始> 的內容都非常麻煩。 Kubernetes 官方 Github 上還有相關的 issue 再討論這個欄位，詢問是否有辦法能夠清除。不少人都提出了一些希望的用法來處理 Issue: https://github.com/kubernetes/kubernetes/issues/90066 目前看下來最簡單的做法還是透過 kubectl plugin, kubectl-neat 來幫忙完成，可以透過 krew 這個 kubectl 管理工具來安裝管理 https://github.com/itaysk/kubectl-neat 此工具可以將 Server 上得到 Yaml 的內容給整理最後得到最初的檔案 至於到底什麼是 managedFiles? 這個由欄位的出現是因為 1.18 以後，已經將 Server Side Apply 更新策略預設啟用而導致的，而 Server Side Apply 則是一種用來管理 Declarative 設定檔案的方式，對使用者來> 說基本上完全無感，因為一切都還是透過 kubectl apply 來使用，只是到底如何判斷 當前檔案內容與系統上內容誰先誰後，誰對誰錯，甚至當有人透過 kubectl edit 去編輯內容的時候，到底該怎麼更新。

連結: https://twitter.com/ibuildthecloud/status/1295810776179961856?fbclid=IwAR3zVNFSodC-PK7JBUDA63vNONwrovxJP7qBvaTtq735dWonROlD5xWN13s

想必大家應該都聽過 Operator 的概念，透過 CRD 自定義資源格式並且配上程式化的運作邏輯來控管相關資源的操作。甚至有廠商針對 Operator 的概念來設計一個 Framework 讓大家能夠更輕鬆或是有效率的撰寫屬> 於自己的 Operator。 然而 Operator 真的一定好嗎? 底下這則推文則是來自於 Darren Shepherd(CTO/Co-founder Rancher Lab ) 對於一篇由 RedHat 所發表關於 Operator 好處文章的反面看法。 其推文最後表示:「Right now invest your IT teams time in GitOps, not operators.」 快來看看 Darren 與其他網友針對這些議題的討論，並且分享看看你的想法

連結: https://www.hwchiu.com/docs/2020/cni-performance-2020

1. Kube-OVN 不但資源吃很多，效能還很不好
2. Canal/Calico/Flannel 三者的運算資源使用量都不多，且效能都很好
3. Kube-Router 的效能都很差，資源使用方便也不是特別出色
4. WeaveNet 與 Cilium 效能都不差，但是 Cilium 吃的效能很高，可說跟 Kube-OVN 同等級，而 WeaveNet 用到的資源少
5. 這次的實驗評比我認為其實能看到的東西有限，主要是不同的 CNI 所搭配的解決方案不同，目標要配合的情境也不同，雖然從圖表中可以看到 Kube-OVN 的綜合評比最差，但是其要用的場景本>身就不太一樣，單純用最原始的流量互打來判別優劣其實不太對
6. 如果今天要選擇網路 CNI 的時候，可以看到效能跟資源方面， Flannel/Calico/Canal 幾乎等級都差不多，而且 Calico 還支援加密與 Network Policy 等功能。
7. 此外，目前 Flannel 也從 Kubeadm 的官方教學頁面中移除，因為太多問題且維護者沒有要修復。所以我認為如果沒有特別使用情境需求的話，可以考慮使用 Calico.
8. Cilium 對於安全性以及 load-balancing 方面也有別的功能，就如同(5)點所提到，不同的場景有不同的需求，有些功能是獨占的。

連結: https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa

不知道大家是否都有使用 Network Policy 來設定 Kubernetes 內部的 ACL? 這邊有個叫做 OPA 的工具可以用幫你驗證你的 Network Policy 是否運作良好，甚至當有新的應用服務要部署的時候，也會確定是否有跟 Network Policy 衝突 有興趣的人可以研究看看