關於 consul是什麼 ，我們在網路上蒐集到這些相關的討論、資訊與評價

本篇文章是個經驗分享系列文，作者探討 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/

今天要分享的是來自 lambda 的團隊根據其多年 Kubernetes 的經驗分享，該篇文章篇長，閱讀可能需要15分鐘左右，這邊幫大家重點整理，有興趣的別錯過完整內容，我個人滿推薦細讀的

# 重點整理
1. 團隊一開始是透過 Ansible + Valut + Consul 來管理整個架構＋應用程式的部署。
2. 作者認為一個非常重要的東西就是， 想清楚你為什麼需要 Kubernetes，不要隨便盲目的使用
3. Kubernetes 的學習曲線非常高，除了 Kubernetes 本身之外，還有很多整合的東西都需要一起學習，譬如 Monitoring, Logging, CI/CD, Secret Management, Tracing 等，每個領域都不簡單
4. Kubernetes 的導入，並非只有營運團隊需要處理，實際上是整個產品團隊都會連帶影響，譬如對於開發者來說，本地開發要怎麼做，本地測試要怎麼做？
CI/CD 如果要考慮 Kuberntees，有哪些部分需要注意？ 應用程式如何打包與上版本？ 更新策略是什麼？
這中間有超多的議題需要整個團隊一起學習與克服，才能夠真正享受到 Kubernetes 帶來的好處
5. 轉移到 Kubernets 中間的過渡期很辛苦，同時維護兩種架構，這需要時間去處理，沒有辦法馬上完成，也不可能一步到位
6. 文章中也有提到作者團隊於各領域所採取的解決方案，這邊就大概列一下

Prometheus, Grafana Loki, Vault, Tekton, Argo Workflow, Telepresence, Skaffold, Kustomize, AWS, Kops

註: 我個人認為裡面最重要的一點就是第二點，任何領域都一定，不要盲目追求潮流，而是要有充分的理由去說服自己為什麼需要使用某產品。對我來說一個很重要的行動準則是，要先說服自己，才有辦法說服別人

https://lambda.grofers.com/learnings-from-two-years-of-kubernetes-in-production-b0ec21aa2814