計算巢支援對服務執行個體進行升級操作，服務商在修複之前版本服務存在問題，或有新功能發布時，發行就緒新版本的服務。新版本服務發布後，使用者可以按需將低版本服務建立的服務執行個體進行升級，升級後的服務執行個體可以使用新版本服務的功能。
服務升級原理
服務升級目前支援兩種升級方式資源棧升級和應用升級，下面分別介紹具體的實現原理。
資源棧升級
計算巢建立服務執行個體時，主要依賴服務範本（Ros模板）進行資源棧建立，進行服務升級時，資源棧升級會按要升級服務版本的Ros模板進行對應資源棧的更新，可以同時實現雲資源和軟體應用的升級。這種升級方式只需定義好不同版本的服務，升級時會對比兩個服務版本對應的Ros模板差異，進行對應的更新操作。
下面以一個例子來說明資源棧的升級過程，假設一個服務有兩個版本，版本1服務範本定義包括資源A、B、C，版本2服務範本定義包括資源A、B、D， 其中資源A的定義完全不變，資源B屬性發生變化，升級過程如下圖所示。
結合上圖，對資源棧升級規則進行總結如下：
新老模板中完全一致的資源，保持不變，例如資源A
新老模板資源名稱相同，但屬性發生變化的資源，進行更新操作，例如資源B
老模板存在，新模板不存在的資源，進行刪除操作，例如資源C
新模板中存在，老模板中不存在的資源，進行建立操作，例如資源D
應用升級
應用升級通過OOS來進行，是通過在服務執行個體ECS資源上執行指令碼命令，更換ECS鏡像、更換軟體包等方式進行升級，這種方式不是直接在資源棧上進行修改，而是以營運操作的方式，對服務執行個體中的軟體應用進行升級。該方式只適用於軟體應用的升級，且只適用於ECS部署情境，不適用ACK部署情境。
應用升級需要使用者對新老服務版本進行diff，配置要做的升級動作，通過在原有服務執行個體上執行配置好的OOS升級動作，達到升級的目的，這樣整體配置會複雜一些。
由於應用升級不是在資源棧上進行升級操作，資源棧對此並無感知，這時候在資源棧上執行其它更新操作，這個升級動作可能會被覆蓋。因此，應用升級目前不推薦使用，建議使用資源棧升級。
服務升級規則
升級時，要升級的版本要支援當前服務執行個體的服務版本進行升級才可以
低版本只能往高版本進行升級
服務商自己同帳號（發布服務帳號和建立服務執行個體帳號相同）測試時可以將其它版本升級到draft版本、beta版本
draft版本認為是最新版本，不能再向上升級
beta版本從邏輯上應該認為第二新的版本，可以升級到draft，發行版本也可以升級到beta版本
服務升級操作
服務執行個體升級支援單個升級和批量升級，具體操作參見 升級服務執行個體：
單個升級：在服務執行個體頁面進行升級操作
批量升級：在服務詳情頁面營運管理頁面進行升級
服務復原
服務復原可以認為是服務升級的反向操作，將服務執行個體從高版本復原到低版本，復原只支援復原到上一個版本，可以通過服務升級歷史查看可以復原到的版本。