本篇文章是個經驗分享系列文,作者探討 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/
k8s pod重啟 在 矽谷牛的耕田筆記 Facebook 的精選貼文
這是一篇幻想文,幻想如果你可以重新設計 Kubernetes,你會希望有什麼樣的改動。也因為是幻想文,所以以下所提的東西不一定真的可以實作,也沒有考慮實作上可能會有什麼困難。原文非常的長,所以這邊就稍微列出一些內容
# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜,從 MetalLB 的開發經驗來看,幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速,一些不相容的修改也很難除錯,往往導致這些整合應用程式一起壞掉。
此外,作者使用 GKE 的經驗讓他覺得就算是這些k8s專家,也很難大規模環境中平安順利的使用 k8s.
作者認為 k8s 就像是管理平台內的 c++,功能非常強大,什麼都可以做,但是它會一直傷害你,直到你奉獻餘生該領域內。
作者期盼有一天,可以出現一個像是 go 語言的管理平台,簡單,優雅,容易學習
接下來就來看一下如果時光倒流,作者會希望 k8s 有哪些功能
# Mutable Pod
不像其他的資源一樣, Pod 這個資源基本上是不能修改的,有任何的更動都需要先刪除,後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說,我透過 kubectl edit 修改了 Pod Image,然後只要透過 SIGTERM 送給 Runc 底層容器,然後當該 Container 被重啟,就會使用新的設定。這一切的發生都在同一個 Pod 的資源內,而不是重新產生一個新的 Pod
# Version control all the things
當 Pod 可以修正後,下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化
為了實現這個功能,可能每個節點上面也要去紀錄過往的所有 image 版本資訊,並且加上 GC 等概念來清除過期或是太舊的內容
# Replace Deployment with PinnedDeployment
相對於 Deployment, PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。
舉例來說,我今天要將 Nginx 從 1.16 升級到 1.17,我可以透過 PinnedDeployment 去部署 Nginx,其中 1.16 佔了 60% ,而新版本 1.17 佔了 40%。
當一切轉移都沒有問題後,可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。
# IPv6 only, mostly
作者期望能的話,想要把 k8s networking 內的東西全部移除,什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。
k8s 全面配置 IPv6,而且也只有 IPv6,通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6,這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故,所有的存取都採用 Routing 的方式,封裝之類的玩法也不需要了。
文章內還提了很多東西,譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上,可以怎麼做,如何設計 NAT64 等,算是非常有趣的想法
# Security is yes
作者認為安全性方面要最大強化,預設情況下要開啟 AppArmor, seccomp profile 等控管機制,同時也要全面禁止用 Root 來運行容器, 基本上就是用非常嚴格的方式來設定安全性方面的規則。
目前 Kubernetes 內的資源, Pod Security Policy 非常類似作者想要完成的東西,通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。
# gVisor? Firecracker?
從安全性考量出發,是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc,同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境
# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine,也許就會像是將 kubevirt 變成一個內建的功能,讓 kubernetes 更加靈活的使用
除了上面之外,文章內還有許多其他的想法,但是內容都滿長的,如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/
k8s pod重啟 在 Kubernetes基础:重启pod的方法 - CSDN博客 的相關結果
Kubernetes 没有提供诸如docker restart类似的命令用于重启容器那样重启pod的命令,一般会结合restartPolicy进行自动重启,这篇文章整理一下偶尔需要 ... ... <看更多>
k8s pod重啟 在 Pod 的生命周期 的相關結果
在Pod 运行期间, kubelet 能够重启容器以处理一些失效场景。 在Pod 内部,Kubernetes 跟踪不同容器的状态 并确定使Pod 重新变得健康所需要采取的动作。 ... <看更多>
k8s pod重啟 在 重启Kubernetes Pod的几种方式 的相關結果
在使用docker 的过程中,我们可以使用docker restart {container_id}来重启容器,但是在kubernetes 中并没有重启命令(没有kubectl restart ... ... <看更多>