本篇文章是個經驗分享系列文，作者探討 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/
工具變數範例 在 Re: [請益] instrument varible工具變數問題- 看板Economics 的推薦與評價
※ 引述《cynthia1985 (cynthia1985)》之銘言：
: 一個統計上的問題
: 如果我今天要做一個題目為"是否義務教育長度對(潛在)所得有影響"----以美國為例
: 美國各州所規定的上學年齡和可離校年齡都不甚相同，有的規定5~18歲為義務教育;有的則是5~17或6~17
: 我看了一些論文她們都採用instrumnet method而非單純OLS
: 我知道IV method是當解釋變數和隨機干擾項變數相關時須採用
: 但......在這個例子中要怎麼知道他門相關並認定IV method比OLS好?
: 如果真的IV method是較好,那如何找適合的IV???
: (請舉適合的iv給我不要理論的東西)
: 看了一些書但是她們都還是講概念的東西所以不是很懂IV實際運用的方法
: 目前我有的一點idea是將regression model:
: 所得=性別+家庭背景+種族+義務教育長度+各州富有程度(地區)....
: 希望有很懂得人可以幫我解答~這答案對我而言非常重要~
: 謝謝先^^
首先先回答你問的IV method
為什麼我們不用OLS就好了要用IV呢
這是因為我們發現解釋變數(X)跟殘差項可能會相關
這樣推出來的迴歸係數估計式就不是一致性(consistent)的估計式了
至於理由 可以參考任何一本計量課本應該都會寫
雖然你說不要講理論
不過我覺得還是把一些該講的給講一講
就你說的例子來說好了
所得跟受教育年數的關係可能是有另外一個變數同時影響
也就是說可能所得越高跟受教育年數越長跟他們的能力有關
這時候你若是要用受教育年數來解釋所得高低的話就會有上述的問題
就必須要找替代的變數
這裡替代的變數(instrumental variables)有兩個要求
第一是與X的相關性要夠高，如此一來才能捕捉到X的大部分資訊
第二是這個變數必須是外生的，也就是不能跟殘差項有關
同時滿足這兩個要求的IV並不是很容易找
就你的例子來說
有人找到的IV是出生的月份，因為他們覺得出生月份會是外生的
但是出生月分確會影響到你的義務教育年數
因為都是9月入學但是有些州規定義務教育到滿16歲
所以到滿16歲生日那天他就可以選擇不用去上學了
(此篇是 Angrist and Krueger QJE, 1991 )
但是後來卻被另外一組人用隨機分配的出生資料給推翻掉
Bound, Jaeger, and Baker (JASA, 1995)
後來發現是因為生日和解釋變數(受教育年數)的相關係很低 (F值小於2)
所以表示IV的相關性很重要
我回答的好像還是很理論
但有兩個重點就是相關性(relevance)跟外生性(exogeneity)
至於怎麼找IV 就真的是藝術了
以上淺見
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.211.236
... <看更多>