SpringCloud應用在Kubernetes上的方法是什么

本篇內容主要講解“SpringCloud應用在Kubernetes上的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“SpringCloud應用在Kubernetes上的方法是什么”吧!

從應用的部署變更層次來看，可以分為以下三層：

所以對應了以下的回滾場景：

• 回滾應用內的配置，適用于由于應用配置變更導致的問題，此時如果應用能夠實現動態的配置加載，通過回滾配置就能實現業務恢復的目的，否則需要重啟應用；

• 回滾應用代碼的版本，適用于代碼修改導致的問題。此時需要回滾代碼的版本（鏡像），重啟應用；

• 回滾應用的工作負載與運維配置（基礎設施層）。

應用內配置回滾

應用內的配置通常與應用系統需要或業務邏輯配置有關，如配置數據庫的連接信息，業務規則配置等，配置的變更也很容易造成線上系統的問題，一般的做法是通過 configmap 或 properties 配置文件來實現，這種情況下很難做到動態推送和回滾的能力，因為回滾需要保存不同版本的配置。

通過 分布配置管理（ACM）（EDAS 默認支持）很容易實現配置的集中管理，回滾和灰度，分布式推送，審計等功能。可以在 ACM 或 EDAS 的控制臺上實現一鍵回滾，如下圖所示：

應用代碼回滾

Deployment 是一種常見部署的應用的 workload，回滾代碼其實對應了回滾對應代碼版本的鏡像，其實就是對應就是 Deployment 的回滾，Kubernetes 可以通過以下方式支持 Deployment 的回滾。

Deployment 回滾

在一個標準的 Kubernetes 體系下，如果出現新版本的 pod 不能正常工作，需要將 deployment 回滾到歷史版本，Kubernetes 提供了原生的支持；其原理是在默認情況下，Kubernetes 會將歷史記錄保留在系統中，直接使用使用 rollout 命令回滾即可，如下：

• 回滾到上一個版本

kubectl rollout undo deployment.v1.apps/{deployment.name}

• 回滾到指定的版本：可以通過kubectl rollout history查看歷史的版本

kubectl rollout history  deployment.v1.apps/{deployment.name}

• 可以通過以下命令回滾到指定的版本

kubectl rollout undo deployment.v1.apps/{deployment.name} --to-revision={version}

EDAS 中應用回滾

而在 EDAS 中，結合了原生的能力做了更豐富的白屏的體驗，我們就發布過程中和發布完成后兩個場景分別描述。

發布過程中回滾

發布過程中回滾是指在應用發布過程中，就發現了問題，需要將應用回滾到前一個版本。此時的操作就是中斷發布流程，將已經升級完成后或正在升級的服務器回滾到前一個版本。

EDAS 在每次變更時候，可以直接中斷發布流程，一鍵回滾。如下圖所示:

另外，EDAS 發布系統提供單批，分批，金絲雀灰度等多種發布形式，在分批和金絲雀灰度的發布的時候，EDAS 還提供不同批次的監控信息，如系統指標，應用指標，應用異常檢測等能力，提供快速發現問題能力，如果存在問題，可以立即進行回滾。如下圖所示：

我們推薦的方式也是在發布過程中盡量使用分批和金絲雀的能力，以將發布引起的不可用降至最小。

發布完成后回滾

發布后回滾是指一次部署過程已經完成，包含部署成功或失敗。這個時候，可以通過部署歷史的版本來實現回滾的功能。EDAS 默認會存儲最多十個部署過的版本，如下圖所示：

通過以上的功能，基本上可以覆蓋應用在上線過程中需要回滾的場景。減少由于系統發布出問題，造成系統功能使用上的影響。

應用自動回滾

從上面的介紹，可以看到回滾的操作都是人工進行的，其實在一些場景里，可以根據一些監控指標，如CPU，load，內存等維度，快速發現問題，就能做到自動回滾，可以能夠更快地恢復系統。在 Kubernetes 的體系中，Flagger就是能夠實現自動回滾的一個很好的工具。

應用工作負載和運維配置回滾

上面介紹了應用內配置和應用代碼回滾的方式，在常見的變更中，還存在工作負載及運維配置的變更，如更改工作負載的類型，變更 JVM 參數，日志配置， 彈性伸縮等。其中 JVM 參數等通常可以隨 Deployment 進行回滾，但是類似 Kubernetes service，日志，彈性伸縮規則等這些基礎設施和運維相關的能力回滾就很難做到了。需要將應用的代碼，工作負載，運維配置等實現配置化來實現回滾的能力。

這里推薦阿里巴巴與微軟聯合提出的 OAM（Open Application Model）的規范，它定義了應用的統一交付模型。

在 OAM 中，一個應用程序包含以下幾個核心的理念：

• Component：是指應用中的組件，可以是應用運行所依賴的服務如 MySQL 數據庫等，也可以是應用的本身，如 Spring cloud 的服務提供者。可以通過 Component 的定義規范來編寫一個組件；

• Trait：是指應用的運維特征，描述了應用部署在具體環境中的運維特征，比如彈性伸縮規則和 Ingress 配置等，這些運維特征會應用到具體的組件上；

• Applicationconfiguration：是將 Components 和 traits 組裝成一個真正能運行起來應用的定義。這個配置文件就是 OAM 規范中的一個聲明式 API，通過它就能實例化出對應的，真實運行的應用。

一個 OAM 的應用例子如下：

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: springcloud-provider-deployment
  annotations:
    version: v1.0.0
    description: "Description of this deployment"
spec:
  components:
    - componentName: springcloud-provider-component
      parameterValues:
        - name: PARAMETER_NAME
          value: SUPPLIED_VALUE
        - name: ANOTHER_PARAMETER
          value: "AnotherValue"
      traits:
        - name: manualscaler.core.oam.dev
          version: v1
          spec:
            replicaCount: 3
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: example-vpc-network

通過 OAM 的 ApplicationConfiguration 這份配置，就能描述線上真正運行的應用，結合能將配置版本化的系統，如 Git，ACM 等，采用對應的 ApplicationConfiguration 的版本，就能實現應用的一鍵回滾。EDAS 里就是通過 OAM 規范來管理 Kubernetes 的應用，結合 OAM 聲明式 API 的方式，EDAS 里將會實現多種應用回滾的場景，為線上業務保駕護航。

到此，相信大家對“SpringCloud應用在Kubernetes上的方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！