眾所周知, Kubernetes(K8S)更適合運行無狀態應用, 但是除了無狀態應用. 我們還會有很多其他應用型別, 如: 有狀態應用, 批處理, 監控代理(每臺主機上都得跑), 更復雜的應用(如:hadoop 生態...). 那么這些應用可以在 K8S 上運行么? 如何配置?
其實, K8S 針對這些都有對應的不同的運行方式. 您要做的, 就是考慮您的應用程式型別會如何影響其運行方式.
Kubernetes 定義了適用于不同型別應用程式的不同型別的作業負載，要確定適合您的應用程式的作業負載，請根據如下思路來思考您的應用程式：
-
是為了完成任務，一個典型例子是一個應用程式，啟動時會跑一批資料，并在批處理執行完成后退出，該應用程式可能會定期運行(如每月)，對于這種型別的應用程式，合適的 Kubernetes (或 OpenShift) 容器平臺物件包括 Jobs 和 CronJob 物件，
-
長時間一直運行. 對于長時間運行的應用程式，可以撰寫 Deployment，(當然啦, 最好是無狀態的)
-
需要在每個節點上運行，某些型別的 Kubernetes 應用程式需要在群集中的每個主節點(master)或作業節點(worker)上運行，DNS 和監控的應用程式是需要在每個節點上連續運行的應用程式的典型例子，您可以將這種型別的應用程式作為 DaemonSet 運行，您還可以基于節點標簽(node labels)在部分符合條件的節點上運行 DaemonSet，
-
復雜的應用, 或需要全生命周期管理，當您要移交應用程式以便其他運維人員可以很方便地使用它時，請考慮創建一個Operator (類似 HELM Charts, 區別是 HELM 只負責安裝, Operator 除了安裝, 還多了全生命周期管理)，Operator 可讓您構建智能的應用，因此它可以自動處理備份和升級之類的事情，與 Operator Lifecycle Manager(Operator 生命周期管理器, 簡稱:OLM)結合使用，集群管理者可以將 Operator 暴露給特定的 namespace，以便集群中的用戶可以運行它們，示例有:
- 有身份或編號要求，應用程式可能具有身份要求或編號要求，例如，您可能需要運行該應用程式的不多不少剛好三個實體, 并且實體命名為
0，1和2，那么StatefulSet是適合于這種應用，StatefulSet 對于需要獨立存盤的應用程式（例如資料庫和 Zookeeper 群集）最有用，總結起來, 就是有狀態的應用就選擇 StatefulSet .
{% note success %}
??思考：
現在的趨勢是一些企業級的、復雜、高級的有狀態軟體開始偏向于采用 Operator 而不是 Helm，因為 Operator 提供更多「自愈」、「自洽」的能力，可以實作更高級、更高級別的自動化甚至是無人托管，
{% endnote %}
總結
| 應用型別 | K8S 資源型別 | 備注 |
|---|---|---|
| Job、批處理 | Jobs CronJob |
|
| 長時間運行的無狀態應用 | Deployment DeploymentConfig |
DeploymentConfig是OpenShift特有的 |
| 長時間運行的無狀態應用- 高可用 | Deployment里加ReplicaSet欄位 |
|
| 需要在每個節點上運行的應用 | DaemonSet |
|
| 復雜的應用, 或需要全生命周期管理的應用 | Operator |
Helm Charts也適用于安裝復雜應用 |
| 有狀態應用 | StatefulSet |
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/539172.html
標籤：其他