我正在探索 K8S 的可能性，我想知道是否有任何方法可以在單個部署中為兩個或多個應用程式創建部署，所以它是事務性的 - 當部署后出現問題時，所有應用程式都會回滾。另外我想提一下，我并不是說帶有多個容器的 pod，因為額外的 side car 容器更適合一些橫切關注點，如監控、身份驗證（如 kerberos）等，但不建議將不同的應用程式放在單個 pod 中. 考慮到這一點，是否可以進行單一部署來生成 2 種以上的 pod？
uj5u.com熱心網友回復：
是否可以進行單個部署來生成 2 種以上的 pod？
不會。Deployment 只會創建一種 Pod。您可以更新 Deployment 的內容，它會逐漸將現有 Pod 替換為與更新后的 Pod 規范匹配的新 Pod。
沒有什么能阻止您創建多個部署，每種部署一個 Pod，這可能就是您在這里尋找的方法。
...當部署后出現問題時，所有應用程式都會回滾。
Core Kubernetes 本身沒有這種能力。事實上，除了容器未通過健康檢查或退出之外，它判斷出現問題的能力有些有限。
在@SYN 的回答中的各種工具中，我至少對 Helm 有一些經驗。從 DBMS 的意義上來說，它并不是“事務性”，但它確實能夠管理相關資源的集合（“圖表”的“發布”），并且能夠回滾整個如果需要，跨多個部署的發布版本。見helm rollback命令。
uj5u.com熱心網友回復：
舵
正如評論中所指出的，解決這個問題的一種方法是使用像 Helm 這樣的東西。
Helm 是某種客戶端（從 v3 開始。以前還涉及“tiller”，一個在您的 kubernetes 集群中運行的控制器：讓我們忘記那個/已棄用）。
Helm 使用“圖表”（或多或少：模板，您可以覆寫默認值）。
自定義
另一個類似于 Helm 的解決方案是 Kustomize。從純文本檔案（不是模板）作業，同時在將物件應用到 Kubernetes 集群之前輕松覆寫/自定義物件。
ArgoCD
雖然 Kustomize 和 Helm 都是獨立客戶端，但我們還可以提及 ArgoCD 等解決方案。
ArgoCD 控制器將在您的 Kubernetes 集群內運行，允許您創建“應用程式”物件。
這些應用程式由 ArgoCD 處理，推動作業負載的部署（這些應用程式的常見來源包括 Helm Charts、Git 存盤庫等）。
ArgoCD 的優勢在于他們的控制器可能（取決于您的配置）負責隨著時間的推移升級您的應用程式（例如：如果您的源是 git 存盤庫，分支 XXX，并且有人將更改推送到該分支：argocd 會應用那些漂亮的馬上）
運營商
盡管這些解決方案中的大多數幾乎不知道您的應用程式是如何運行的。假設您升級了由 Helm、Kustomize 或 ArgoCD 驅動的部署，并最終導致一些資料庫 pod 卡在 crashloopbackoff 中：盡管如此，您的應用程式 pod 仍會更新，不會自動回滾到以前的作業配置。
這為我們帶來了另一種將應用程式發送到 Kubernetes 的方式：運營商。
操作員知道您的作業負載的狀態，并且可能能夠修復常見錯誤（取決于它的編碼方式，......沒有魔法）。
操作員是一個應用程式（可以是 Go、Java、Python、Ansible 劇本……或任何與 Kubernetes 集群 API 通信的庫中的任何一個）
操作員不斷連接到您的 Kubernetes 集群 API。您通常會找到一些特定于您的操作員的 CustomResourceDefinition，允許您描述集群中某些組件的部署。（例如：elasticsearch 運算子引入了一個物件型別“ElasticSearch”和一些“Kibana”）
The operator watches for instances of the objects it managed (eg: ElasticSearch), eventually creating Deployment/StatefulSets/Services ... If someone deletes an object that was created by your operator, it would/should be re-created by that operator, in a timely manner (mileage may vary, depending on which operator we're talking about ...)
A perfect sample for operators would be something like OpenShift 4 (OKD4). A Kubernetes cluster that comes with 10s of operators (SDN, DNS, machine configurations, ingress controller, kubernetes API server, etcd database, ...). The whole cluster is an assembly of operators: upgrading your cluster, each of those would manage the upgrade of the corresponding services, in an orchestrated way, ... one after the other, ... if anything fails, you're still usually left with enough replicas running to troubleshoot the issue, ...
Depending on what you're looking for, each option has advantages and inconvenients. Now if you're looking for "single deployment that can produce 2 kind of pods", then ArgoCD or some home-grown operator would qualify.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/446648.html
標籤：Kubernetes 部署