本文延續前一篇文章,作者探討十五種 Kubernetes 不該使用的部署與維運模式,總共三篇,每篇五種。
Using Kubectl as a debugging tool
作者認為一個良好的 Kubernetes 叢集必定要有一個相對應個可觀測性工具,包含 Metrics/Log/Tracing 等。對於一個維運人說來說,今天要處理事情時,第一件事情如果還是慢慢的用 kubectl 來執行 get, describe ,log 等指令找問題的話就太慢了,這類型的工具都應該只是輔助使用,真正還是要依賴有效的監控系統,不論是常見的系統指標,應用程式狀態甚至是應用程式獨特的指標等,將這些資訊整合到一個方便顯示的儀表板,甚至搭配對應的 Alert 功能來達到主動通知。
Misunderstanding Kubernetes network concepts
Kubernetes 內提供的網路功能很容易被搞混,Service(ClusterIP, NodePort, LoadBalancer) 與 Ingress 的差異到底是什麼,很多初次踏入 Kubernetes 的玩家沒有特別去理解差異,只知道應用程式部署後就可以通了。Service Mesh 這個概念作者也推薦去學習與瞭解,知道這個概念是什麼,以及想要什麼解決問題就好,因為並非不是每個叢集都真的需要一套 Service Mesh 的解決方案,但是理解這個概念未來就有能力知道什麼時候需要導入。
Using permanent staging environments instead of dynamic environments
對於應用程式開發者來說,如何於 Kubernetes 環境上測試新功能一直都是一個困難的問題。大部分的團隊中都會有 QA/Staging/Production/Dev(甚至更多)的環境,假設 Dev 環境可以供開發者測試,這些開發者要如何確保自己的修改沒有問題且通過整合測試。
一個常見的問題是假如多個開發者同事部署自己的程式碼到固定環境中,有可能會造成互相干擾,導致問題發生時沒有辦法正確的判別問題是誰產生的。
作者提到一種作法就是透過預借的概念,確保每個開發者使用叢集時都不會有他人干擾,然而這個問題也會引發其他問題,譬如開發者間要互相協調時間,同時每個人用完環境後都要還原成穩定的狀態,以免干擾下一位的使用。
作者推薦使用動態叢集的方式來進行測試,使用 Github PR 為範例,當 PR 開啟時,動態創建 Kubernetes 叢集供測試,當 PR 合併後就會將該 Cluster 給移除。透過這種範例每個開發者都可以有獨立的環境進行測試彼此不干擾,同時也會隨者程式碼的合併而自動回收環境,也不需要擔心環境污染問題。
Mixing production and non-production clusters
任何團隊一定要有正式生產環境的叢集跟其他叢集分隔開來,千萬不能使用 namespace 的方式於一個叢集中同時維護生產與非生產環境。譬如
1. 任何人操作 Kubernetes 都很容易失誤,譬如指令下錯,指向錯的物件。這類型的操作都有可能導致該叢集上生產環境被誤刪
2. namespace 的隔離性不好,實際上很多物件彼此還是可以互相存與溝通,這部分也有其他的隱憂
詳細原文可以參考下列連結。
https://medium.com/containers-101/kubernetes-deployment-antipatterns-part-2-2af25a710bc0
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
kubectl是什麼 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
本篇文章是個經驗分享系列文,作者探討 Kubernetes 內 15 種不被建議的部署策略與模式。
作者之前曾經撰寫過 Contianer 架構底下的部署模式探討,而本系列文(三篇)則是著重於如何將這些 containers 透過 Kubernetes 給部署到生產環境,總共會探討十五種不推薦的模式,接下來的三篇文章將會介紹各五種不好的模式。
Using containers with the latest tag in Kubernetes deployments
任何 container 的 image 都不應該使用 latest,因為 latest 本身沒有任何意義,這會使得維運人員沒有辦法掌握到底當前部署的版本是什麼,更嚴重的情況適當 latest 搭配 PullPolicy:Always 時會產生更為嚴重的問題。因為 Always 的策略導致每次 Pod 部署時都會重新抓取 image,所以一個 deployment 中,多個使用 latest tag 的 Pod 但是其實使用的 image hash 是不同的。
作者認為比較好的做法有
1. 所有 container image 都是不可修改的,一旦建立就禁止覆蓋,有任何改動就進版
2. 部署用的 image tag 使用有意義的版本名稱
補充: 實際上 pull image 也可以使用 sha256,譬如 "docker pull hwchiu/kubectl-tools@sha256:acfb56059e6d60bf4a57946663d16dda89e12bfb1f8d7556f277e2818680e4c8"
Baking the configuration inside container images
任何 contaienr image 建置的時候應該都要往通用的方向去設計,而不是參雜各種設定在裡面。著名的 12-factor app 裡面也有提到類似個概念,建置好的 image 應該要可以 build once, run everywhere,動態的方式傳入不同的設定檔案,而不是把任何跟環境有關的資訊都寫死
舉例來說,如果 image 內包含了下列設定(舉例,包含不限於)
1. 任何 IP 地址
2. 任何帳號密碼
3. 任何寫死的 URL
作者認為比較好的做法有
1. 透過動態載入的方式來設定運行時的設定,譬如Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper 等
2. 根據不同程式語言與框架甚至可以做到不需要重啟容器就可以載入新的設定
Coupling applications with Kubernetes features/services for no reason
作者認為除了很明確專門針對 Kubernetes 使用,或是用來控制 Kubernetes 的應用程式外,大部分的 應用程式包裝成 Container 時就不應該假設只能運行在 Kubernetes 內。作者列舉了幾個常見的使用範例,譬如
1. 從 K8s label/annotation 取得資訊
2. 查詢當前 Pod 運行的資訊
3. 呼叫其他 Kubernetes 服務(舉例,假設環境已經存在 Vault,因此直接呼叫 vault API 來取得資訊)
作者認為這類型的綁定都會使得該應用程式無法於沒有 Kubernetes 的環境運行,譬如就沒有辦法使用 Docker-compose 來進行本地開發與測試,這樣就沒有辦法滿足 12-factor 中的精神。
對於大部分的應用程式測試,除非其中有任何依賴性的服務是跟外部 Kubernetes 綁定,否則這些測試應該都要可以用 docker-compose 來叫起整個服務進行測試與處理。
服務需要使用的資訊應該是運行期間透過設定檔案,環境變數等塞入到 Container 內,這樣也呼應上述的不要將與環境有關的任何資訊都放入 image 內。
Mixing application deployment with infrastructure deployment (e.g. having
Terraform deploying apps with the Helm provider)
作者認為近年來伴隨者 IaC 概念的熱門,愈來愈多的團隊透過 Terraform/Pulumi 這類型的工具來部署架構,作者認為將部署架構與部署應用程式放到相同一個 Pipeline 則是一個非常不好的做法。
將基礎架構與應用程式同時放在相同 pipeline 可以降低彼此傳遞資訊的困難性,能夠一次部署就搞定全部,然而這種架構帶來的壞處有
1. 通常應用程式改動的頻率是遠大於基礎架構的改變,因此兩者綁在一起會浪費許多時間在架構上
假如部署基礎架構需要 25 分鐘而應用
https://codefresh.io/kubernete.../kubernetes-antipatterns-1/
kubectl是什麼 在 矽谷牛的耕田筆記 Facebook 的最佳解答
原文在這邊: https://www.teamblind.com/post/50-Reasons-Kubernetes-Sucks-S77O8VZ8
不知道大家看完有什麼想法
我個人認真看完後其實覺得真的是幹樵而已,可以單純當作幹話發洩文就好。有些理由沒什麼前後文,不知道想要表達什麼,有些感覺就是剛好自己踩到通點,基本上任何的軟體架構都可以有類似的議題
稍微看了一下
1. 難道你跑 openstack 就沒有這個感覺嗎? 我自己經驗是更痛苦
2. API 不相容這點我倒覺得還好,沒有遇到特別嚴重的,基本上 k8s 都會給予4-5個版本要使用者替換 apiVersion, 不看警告訊息無腦使用不能怪人
3. charts的問題應該是 Helm Charts 的問題,我倒覺得不是 k8s 自己的問題,不喜歡 charts 何不考慮 kustomize.
4,5 兩個應該是軟體發展一定會遇到的問題,任何系統遇到環境升級都是膽戰心驚吧?
9. 不確定是不是 kubectl 輸入到手酸XD,可以考慮 k9s?
10,11 最後談
13. 為什麼你會有一個兩年不升級的k8s叢集才是一個問題? 不如反過來問,如果你覺得兩年不升級沒問題,為什麼會突然想要升級
14. golang 中槍
19. 我覺得還是可以慢慢看,openstack 等VM為主題的 orchestration 實在是太不平易近人,學習曲線太高
...
32(a). 不太能理解 pause container 的問題是什麼XD,除非最小單位變成 Container 而不是 Pod,不然 Pause 的用途我還沒想到要怎麼取代
32(b). 完全同意, secret 帶來的好處只有透過編碼讓文件內容好處理,可以避掉一堆雙引號,分號等問題
10 跟 11 分別幹瞧了 overlay network 與 service mesh 兩個解決方案的痛點,我覺得很有趣的是這兩個點分別是從不同層面來解決問題。
早期大家碰到 Kubernetes 時都可能使用過 Flannel 這套 CNI,大部分情況下都是急於 VXLAN 來建置 overlay network,透過 UDP 標頭來重新包裝封包並且利用 Layer2,3,4 來重新搭建整個架構網路,是一個專注於底層網路L2-L4的解決方案
目前的 Service Mesh 的則是專注於 L7 的網路傳輸,期望能夠打造出一個串連不同 L7 應用程式的服務,譬如 HTTP,gRPC 等,讓這些應用程式的流量會根據不同 L7 的設定而有不同走法與走向。
只是為了轉發這些不同容器間的封包,最快速的做法就是大量利用已知的架構(iptables,route)等機制來控制各別網路連線,我覺得帶來的缺點就是架構非常龐大,規則非常複雜,大家除錯方式就是不停 restart/reboot,很少人真的能夠講清楚到底每個封包是怎麼被修改的
網路的世界真的非常有趣!