32 posts tagged with "Kubernetes"

標題: 「使用 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 叢集中

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

連結: https://matduggan.com/mistakes/

本文是作者踩過的各種 Infrastructure 雷，希望讀者能夠避免這些雷。

總共有幾大類，分別

1. Don't migrate an application from the datacenter to the cloud
2. Don't write your own secrets system
3. Don't run your own Kubernetes cluster
4. Don't Design for Multiple Cloud Providers
5. Don't let alerts grow unbounded
6. Don't write internal cli tools in python

其中第六點簡短扼要，大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」

這讓我想到你的 Python 跟我的 Python 每次都不一樣，有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....

連結: 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://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://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 的使用方式

連結: 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 來測試，畢竟輕量化且同時支援多節點，環境也乾淨，測試起來也方便。

連結: 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 與其他網友針對這些議題的討論，並且分享看看你的想法