通過 Kasten K10 by Veeam 與 SUSE Rancher 實現雲原生應用災備遷移

語言: CN / TW / HK

時間 2022-09-22 17:47:19 Rancher

作者

Adam Bergh, Solutions Architect, Cloud Native Technical Partnerships, Kasten by Veeam

Terry Smith, Global Partner Solutions Director, SUSE

Gerson Guevara, IHV Solutions Architect, SUSE

1.簡介

1.1 用途

現在，企業逐漸轉向雲原生（例如使用容器化工作負載和 SUSE Rancher 等 Kubernetes 管理平臺）。企業的目標是提高靈活性、規模和彈性，來加速創新並快速適應動態環境。在這種永遠線上的 IT 環境中，應用程式的可移植性和資料保護就十分關鍵。

Kasten K10 by Veeam 資料管理平臺為企業運營團隊提供了一個易於使用、可擴充套件且安全的系統，用於雲原生應用程式的備份和恢復、災難恢復和遷移。

1.2 範圍

本指南概述了在 SUSE Rancher Kubernetes 環境中安裝和設定 Kasten K10 by Veeam，以及執行應用程式的簡單備份和恢復的步驟。

1.3 受眾

本文件適用於 IT 運營團隊、備份管理員、DevOps 和 DevSecOps 團隊，以及負責雲原生環境業務連續性、災難恢復、反勒索軟體、威脅控制以及應用程式遷移的其他人員。

2. 技術概述

Kasten K10 by Veeam 資料管理平臺與 SUSE Rancher 深度整合，並提供了跨 Kubernetes 發行版和雲平臺的生態系統支援，這為企業運營團隊提供了靈活的部署環境選項（本地、公有云和混合雲）。 K10 是由策略驅動並可擴充套件的，提供了很多企業功能，例如全域性一致性、資料庫整合、自動應用程式發現、多雲遷移和強大的 Web UI。

3. 先決條件

本指南涉及以下內容：

SUSE Rancher

本指南使用的是 Rancher 2.6，詳細資訊請參閱 SUSE Rancher 安裝指南：

http://rancher.com/docs/rancher/v2.6/en/installation/requirements/
由 SUSE Rancher 管理的 Kubernetes 叢集

請參閱 SUSE Rancher 支援矩陣：htt ps://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-6-3/
備份目標的儲存

外部備份儲存目標（例如 NFS 檔案伺服器或雲物件儲存）。本文件將使用與 S3 相容的外部物件儲存桶。
用於演示備份和恢復功能的使用者應用程式

例如，你可以使用 Helm Chart （ http://bitnami.com/stack/wordpress/helm ）輕鬆安裝 WordPress。

K10 可以安裝在各種不同的環境中。為了確保安裝順利，你可以使用 primer 工具來執行幾個實施前檢查（pre-flight check）。該工具在叢集的 pod 中執行，且會執行以下操作：

驗證 Kubernetes 設定是否滿足 K10 要求。
登記可用的 StorageClass。
如果存在 CSI provisioner，它還會對叢集的 CSI 功能和相關物件進行基本驗證。詳細資訊請參閱 CSI pre-flight： http://docs.kasten.io/latest /in stall/storage.html#csi-preflight

執行以下命令部署 primer 工具：

curl http://docs.kasten.io/tools/k10_primer.sh | bash

注意：

這將建立並清理 ServiceAccount 和 ClusterRoleBinding，以便對 Kubernetes 叢集執行健全性檢查。

4. 安裝 Kasten K10

可以在 SUSE Rancher 的 Apps & Marketplace 頁面中輕鬆部署 Kasten K10。

4.1 為 Kasten K10 應用程式建立一個新的名稱空間： http://rancher.com/docs/rancher/v2.6/en/project-admin/namespaces/

在 SUSE Rancher 的 UI 中，導航到 Clusters > Project/Namespaces：

為 Kasten K10 建立一個 “kasten-io” 名稱空間：

4.2 安裝 Kasten K10

在 SUSE Rancher UI 中導航到 Apps & Marketplace > Charts 並搜尋 “Kasten”：

選擇 K10 Chart 並單擊 Install：

在 Namespace 下拉框中選擇 “kasten-io” 名稱空間。你也可以選擇 Customize Helm options before install 來自定義部署（非必選）。有關詳細說明，請參閱 Helm 選項完整列表：http://docs.kasten.io/latest/install/advanced.html#complete-list-of-k10-helm-options

設定 Chart 值後，單擊 Next，然後單擊 Install。

4.3 驗證安裝

要驗證 Kasten K10 是否已正確安裝，請在 “kasten-io” 名稱空間中執行以下命令並檢視所有 K10 pod 的狀態：

kubectl get pods --namespace kasten-io --watch

Pod 需要幾分鐘後才能全部出現並顯示 “Running” 狀態：

kubectl get pods --namespace kasten-ioNAMESPACE NAME READY STATUS RESTARTS AGEkasten-io aggregatedapis-svc-b45d98bb5-w54pr 1/1 Running 0 1m26skasten-io auth-svc-8549fc9c59-9c9fb 1/1 Running 0 1m26skasten-io catalog-svc-f64666fdf-5t5tv 2/2 Running 0 1m26s...

注意：

如果 pod 卡在其他狀態，請參閱支援文件（

http://docs.kasten.io/latest/operating/support.html#support ）以進一步進行除錯。

5. 訪問 K10 儀表板

Kasten K10 儀表板預設不對外暴露。要建立連線，請執行以下 kubectl 命令：

kubectl --namespace kasten-io port-forward service/gateway 8080:8000

注意：

如果你安裝的 Kasten K10 的版本名稱不是 k10（通過安裝命令中的 --name 選項指定），請將上述 URL 中最後面的 k10 替換為你的版本名稱。修改後的 URL 的格式為

注意：

kubectl

許可權的情況下訪問儀表板，請參閱直接在

Google Cloud Console 中訪問 K10 儀表板： http://docs.kasten.io/latest/access/gcp_details/gcp_console_dashboard.html

如果要直接訪問（ http://docs.kasten.io/latest/access/authentication.html#id5 ） K10 儀表板，你需要正確配置身份驗證來保護訪問。有關詳細資訊，請參閱 Kubernetes 身份驗證： http://kubernetes.io/docs/reference/access-authn-authz/authentication/

在本指南中，我們概述了配置基本身份驗證和令牌身份驗證的步驟，你可以選擇其中一種身份驗證方法。

5.1 基本身份驗證

基本身份驗證（ http://docs.kasten.io/latest/accecess/authentication.html#id6 ）能讓你使用使用者名稱和密碼來保護對 K10 儀表板的訪問。

首先，使用線上工具（ http://www.htaccesstools.com/htpasswd-generator/ ）或系統上的 htpasswd 命令（大多數系統上都支援）生成 htpasswd （ http://httpd.apache.org/docs/2.4/programs/htpasswd.html ）憑證來啟用基本身份驗證。

生成後，你需要在 helm install 或 helm upgrade 命令中使用以下標誌來提供獲取的字串：

--set auth.basicAuth.enabled=true \

--set auth.basicAuth.htpasswd='example:$apr1$qrAVXu.v$Q8YVc50vtiS8KPmiyrkld0'

或者，你可以使用由 htpasswd 建立的檔案中包含的 secret。secret 必須位於 K10 名稱空間中，金鑰名為 “auth”，值為使用 htpasswd 生成的密碼：

--set auth.basicAuth.enabled=true \

--set auth.basicAuth.secretName=my-basic-auth-secret

5.2 令牌身份驗證

令牌身份驗證（ http://docs.kasten.io/latest/access/authentication.html#id7 ）能讓你使用任何可以被 Kubernetes 伺服器驗證的令牌。有關令牌身份驗證的更多資訊，請參閱：

獲取令牌： http://docs.kasten.io/latest/access/authentication.html#id8
身份驗證策略： http://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies

1. 在 helm install 或後續的 helm upgrade 命令中使用以下標誌，從而啟用令牌身份驗證：

--set auth.tokenAuth.enabled=true

2. 然後，提供要在訪問儀表板時使用的持有者令牌：

最常見的令牌型別是 ServiceAccount 持有者令牌。

1. 你可以使用 kubectl 從具有適當許可權的 ServiceAccount 中提取此類令牌。

獲取 SA secret：

sa_secret=$(kubectl get serviceaccount my-kasten-sa -o jsonpath="{.secrets[0].name}" --namespace kasten-io)

提取令牌：

kubectl get secret $sa_secret --namespace kasten-io -ojsonpath="{.data.token}{'\n'}" | base64 --decode

你也可以建立一個新的 ServiceAccount 來提取令牌：

kubectl create serviceaccount my-kasten-sa --namespace kasten-io

在這種情況下，你需要為該賬號建立角色繫結或叢集角色繫結，從而確保該賬號具有適當的 K10 許可權。如需詳細瞭解必要的 K10 許可權，請參閱授權： http://docs.kasten.io/latest/access/authorization.html#authz

5.3 Kasten K10 儀表板概覽

K10 儀表板分為幾個部分，如下所述。

提示：

首次訪問 K10 儀表板，或通過 Settings（

http://docs.kasten.io/latest/usage/overview.html#k10-settings ）頁面上的儀表板選項進行訪問時，你會看到 K10 儀表板的導覽。

K10 儀表板的上方會顯示當前對映到名稱空間的應用程式、系統中可能存在的策略以及叢集備份資料佔用情況的概覽：

在過濾具有狀態服務（定義為包含持久卷）的應用程式後，此介面將應用程式進一步分類為：

Unmanaged：沒有保護此物件的策略。
Non-compliant：具有應用於此物件的策略，但策略相關的操作失敗（原因可能是底層儲存緩慢、配置問題等）或尚未呼叫操作。
Compliant：這些物件具有策略並且遵守策略 SLA。

提示：

你可以通過單擊 Compliant、Non-Compliant 或 Unmanaged 按鈕來過濾檢視。

K10 將名稱空間等同於應用程式，因此更加易於使用並且與 Kubernetes 的最佳實踐保持一致，更容易使用 RBAC，並能映象最常見的應用程式部署模式。但是，你可以將策略定義為操作多個名稱空間（參見後文），或者僅對單個名稱空間中的應用程式的子集進行操作。

假設你已經安裝了應用程式，單擊儀表板上的 Applications 後你將看到以下檢視：

一個應用程式由多個 Kubernetes 資源和工作負載組成，其中包括 Deployment 和 Statefulset：

K10 策略能自動化你的資料管理工作流程，策略定義了要執行的操作（例如製作快照）、操作的執行頻率或計劃，以及如何選擇要管理的資源。

單擊主儀表板中的 Policies 後，你會發現安裝時沒有建立預設策略，但是你可以從此頁面或上文提及的 Applications 頁面中建立策略：

6. 建立 location 配置檔案

K10 可以在叢集內呼叫保護操作（例如快照）而無需額外的憑證。如果 K10 執行在主流的公有云中並且僅進行單叢集操作，這可能就足夠了。但是，對於大多數生產情況來說，這還不夠。在這種情況下，執行真正的備份、啟用跨叢集和跨雲應用程式遷移以及啟用災難恢復是必要的。

要啟用跨越叢集生命週期的操作，K10 需要配置為能訪問外部物件儲存或外部 NFS 檔案儲存，而這是通過 location 配置檔案實現的：

你可以單擊儀表板右上角的 Settings 圖示，或通過 CRD-based Profiles API（ http://docs.kasten.io/latest/api/profiles.html#api-profile ）來建立配置檔案。Location 配置檔案用於使用快照建立備份、跨叢集或跨雲平臺移動應用程式及其資料，並將備份匯出/匯入叢集。

要建立 location 配置檔案，單擊配置檔案頁面上的 New Profile：

在物件儲存位置進行匯出或匯入時，你需要選擇物件儲存提供程式、儲存桶的區域（如果在公共雲中使用）以及儲存桶名稱。如果該名稱的儲存桶不存在，則會建立該儲存桶。

如果使用了不受支援的雲廠商的 S3 相容物件儲存系統，則需要指定 S3 端點 URL，並且可能需要禁用 SSL 驗證。僅建議在測試場景下禁用 SSL 驗證。

注意：

選擇雲廠商（例如 AWS 或 Microsoft Azure）後，雲廠商對應的選項（例如 IAM Roles）則會顯示。

單擊 Validate and Save 後將建立配置檔案，然後會出現類似以下的配置檔案：

7. 建立策略

要使用 K10 來保護應用程式，你通常需要建立策略。你需要了解以下的三個概念：

快照和備份：你可能需要使用這兩種資料捕獲方式中的一種或兩種，具體取決於你的環境和要求。
計劃：你可以指定應用程式捕獲頻率和快照/備份保留時間。
選擇：確定受策略保護的應用程式。你還可以通過過濾資源來限制每個應用程式捕獲的內容。

本節將演示如何在 K10 策略中使用這些概念來保護應用程式。

K10 將應用程式定義為名稱空間中的 Kubernetes 資源的集合，這些資源與以下內容關聯：

工作負載（例如 ConfigMap 和 Secret）
應用程式使用的非名稱空間資源（例如 StorageClass）
Kubernetes 工作負載（包括 Deployment、StatefulSet、獨立的 pod 等）
Helm v3 提供的 Deployment 和版本資訊
所有持久儲存資源（例如 PersistentVolumeClaim 和 PersistentVolume）

你可以在策略頁面從零開始建立策略，但是，為應用程式定義策略的最簡單方法是單擊主儀表板中的 Applications，這樣就能檢視 Kubernetes 叢集中的所有應用程式：

要保護 Unmanaged 的應用程式，只需單擊 Create a Policy 以開啟 New Policy 對話方塊即可：

7.1 快照和備份

操作執行是所有策略的核心。你可以先選擇具有可選備份（稱為 export）的快照操作。詳細資訊請參閱 Kasten 文件中的快照和備份： http://docs.kasten.io/latest/usage/protect.html#snapshots-and-backups

7.1.1 快照

快照是 K10 中持久資料捕獲的基礎，它們通常用於應用程式使用的磁碟卷 (PVC/PV) 的上下文中，但也可以應用於應用程式級別的資料捕獲（例如使用 Kanister： http://docs.kasten.io/latest/kanister/kanister.html#kanister ）。

注意：

一些公有云廠商（包括 AWS、Azure 和 Google Cloud）實際上將快照儲存在物件儲存中，而且它們的保留與主卷的生命週期是分開的。但是，並非所有公有云都是這樣的，因此獨立備份更加安全。請查閱你的雲廠商的文件以獲取更多資訊。

在大多數儲存系統中，快照是非常高效的，而且對主要工作負載的效能影響非常低，不需要停機，支援快速恢復，並支援增量資料捕獲。

快照的儲存通常會受到限制，例如每個卷/儲存陣列的最大快照數量相對較低。最重要的是，快照並不都是持久的。如果發生災難性的儲存系統故障，你的快照和主要資料都會被破壞。此外，在一些儲存系統中，快照的生命週期與源卷是相關聯的。因此，如果卷被刪除，那麼所有關聯的快照都可能被自動回收。

提示：

強烈建議你備份應用程式的快照以確保永續性。

7.1.2 備份

備份能克服應用程式和卷快照的限制，其原理是通過將快照轉換為獨立於基礎設施的格式，在儲存到外部物件儲存或 NFS 卷之前對其進行重複資料刪除、壓縮和加密。

要將快照轉換為備份，請在策略建立期間啟用 Enable Backups via Snapshot Exports：

7.2 排程

K10 排程有四個組成部分：

操作頻率：執行主快照操作的頻率
匯出頻率：將快照匯出到備份的頻率
保留計劃：如何輪換和保留快照和備份
時間：執行主要快照操作的時間

7.2.1 操作頻率

快照的頻率可以設定為 Hourly、Daily、Weekly、Monthly、Yearly 或 On Demand。預設情況下，Hourly 快照會在整點執行，而 Weekly、Monthly 和 Yearly 快照會在 UTC 零點執行。

你還可以指定執行計劃操作的時間以及單個頻率內執行多個操作的子頻率。在保護 Kubernetes 物件或小型資料集時，按小時執行操作會非常有用。詳細資訊請參閱 Kasten 文件中的高階排程選項： http://docs.kasten.io/latest/usage/protect.html#advanced-schedule-options

警告：

請不要加緊底層儲存基礎設施或儲存 API 速率的限制。此外，子頻率與保留時間（如下所述）也是相互作用的。例如，如果你以 15 分鐘的間隔保留 24 小時的快照，那麼實際上只會保留 6 小時的快照。

7.2.2 匯出頻率

啟用 Enable Backups via Snapshot Exports 後，快照將作為備份匯出。預設情況下會匯出每個快照，但你可以通過選擇 Daily、Weekly、Monthly 或 Yearly 的匯出頻率將其限制為一個子集：

7.2.3 保留計劃

K10 能夠使用 GFS 保留方案（ http://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son ）來節省成本和確保合規性。如果你使用這個備份輪換方案，Hourly 快照和備份會每小時輪換一次，然後其中一個會逐漸輪換成 Daily 頻率；同理，Daily 快照和備份會每天輪換一次，然後其中一個會逐漸輪換成 Weekly 頻率，以此類推。你可以設定需要保留的 Hourly、Daily、Weekly、Monthly 和 Yearly 副本數，K10 將按照設定進行清理。

注意：

不支援為 On Demand 策略設定保留計劃。

預設情況下，備份保留計劃與快照保留計劃是相同的。你也可以設定不同的計劃。你可以建立保留有限快照數量的策略，從而在意外中斷時進行快速恢復，同時儲存大量備份。如果卷僅支援有限數量的快照，但需要大量備份保留數來實現合規性，這種單獨的保留計劃就非常有用。

通過將 k10.kasten.io/doNotRetire: "true" 標籤新增到為策略執行而建立的 RunAction（ http://docs.kasten.io/latest/api/actions.html#api-run-action ），你可以從保留計數中保留和省略策略建立的快照和備份。

注意：

策略的保留計劃不適用於手動執行策略（

http://docs.kasten.io/latest/usage/protect.html#manual-policy-runs ）生成的快照和備份。你需要清理手動執行策略期間建立的所有工件。

7.2.4 定時

預設情況下，設定為 Hourly 執行的操作會在整點執行，而其他頻率的操作會在 UTC 午夜執行。

你可以取消隱藏 Advanced Options，從而選擇在頻率間隔內執行操作的次數。例如，如果操作頻率是 Daily，你可以指定開始操作的具體小時和分鐘：

你還可以設定哪些快照和備份需要保留更長時間：

提示：

你可以選擇以本地時間或 UTC 時間來顯示和輸入時間，但所有時間都將轉換為 UTC，並且不會更改為夏令時。

7.3 選擇

在 K10 中，你可以通過名稱或標籤來指定要繫結到策略的應用程式。

7.3.1 應用程式名稱

在 K10 中，將策略應用於應用程式的最直接的方法是使用名稱（源自名稱空間名稱），你甚至可以為同一策略選擇多個應用程式名稱。

如果你需要跨相似應用程式的策略，請使用星號 ( * ) 萬用字元。例如，如果你指定了 mysql-* ，K10 將匹配所有名稱以 mysql- 開頭的應用程式。

注意：

對於需要跨所有應用程式的策略，請單獨使用星號萬用字元。

7.3.2 應用程式標籤

你還可以使用標籤將策略繫結到多個應用程式。例如，你可以保護所有使用 MongoDB 或使用 “gold” 標籤進行註釋的應用程式。名稱空間、deployment 和 statefulset 的標籤會被匹配。如果選擇了多個標籤，將執行並集（邏輯 OR），也就是讓所有應用程式至少匹配一個標籤。

標籤可用於建立前瞻性策略，因為此類策略將自動應用於後續帶有匹配標籤的任何應用程式。例如，如果你使用了 “heritage: Tiller”（Helm v2）或 “heritage: Helm”（Helm v3）標籤，由於標籤會應用於 Helm 包管理器建立的任何 Kubernetes 工作負載，因此選擇器會將策略應用於任何 Helm 新部署的應用程式。

7.3.3 其他資源

K10 還可以保護叢集級別的資源，而不針對具體應用程式。要使用此選項，請選擇 None：

有關保護叢集級別資源的更多資訊，請參閱叢集級別資源： http://docs.kasten.io/latest/usage/clusterscoped.html#clusterscoped

7.3.4 自定義

你可以通過以下方式進一步自定義 K10 應用程式保護策略

名稱空間排除： http://docs.kasten.io/latest/usage/protect.html#namespace-exclusion
例外： http://docs.kasten.io/latest/usage/protect.html#exceptions
資源過濾： http://docs.kasten.io/latest/usage/protect.html#resource-filtering

8. 使用策略

建立策略並導航回主儀表板後，你將看到選定的應用程式從 Unmanaged 切換到 Non-Compliant。也就是說，策略涵蓋了物件，但尚未執行任何操作。當快照和備份已執行且應用程式進入受保護狀態時，應用程式將切換到 Compliant 狀態。你還可以向下滾動頁面，從而檢視活動、每個快照所用的時間以及生成的工件。

注意：

你可以單擊進行中或已完成的 Job 來獲取更詳細的資訊。

8.1 手動執行策略

你可以通過單擊策略上的 run once 按鈕來手動執行策略。此操作建立的工件都不符合自動停用的條件，因此需要手動清理。

8.2 恢復現有應用程式

你可以通過 Applications 頁面來恢復應用程式。要恢復應用程式，單擊 Applications 卡片中的 restore 圖示：

注意：

雖然 UI 中使用了 “export” 術語，但是恢復備份不需要使用匯入策略。只要在將應用程式恢復到其他叢集時才需要匯入策略。

然後，可以選擇一個還原點。UI 中將它們區分為自動生成（使用備份策略）和手動生成。

還原點可能包括具有相同資料的快照（叢集本地）和備份（已匯出到叢集外）。當快照和備份都存在時，UI 能讓你選擇要用於恢復應用程式的例項：

選擇還原點後，一個側面板將會開啟，其中包含還原點的詳細資訊，你可以在開始恢復應用程式之前進行預覽：

單擊 Restore 時，系統會自動將整個應用程式堆疊重新建立到選定的名稱空間中，其中不僅包括與原始應用程式相關的資料，還包括版本化的容器映象。

注意：

恢復的 PersistentVolume 可能沒有原始 PersistentVolume 中的註釋。

恢復完成後，你可以返回應用程式並驗證它是否已恢復到獲取還原點時的狀態。

8.3 恢復已刪除的應用程式

恢復已刪除的應用程式的流程也差不多，但預設情況下，已刪除的應用程式不會顯示在 Applications 頁面上。因此，你需要過濾並選擇 Removed：

過濾器生效後，你會看到 K10 保護過但不再存在的應用程式。現在，你可以按照正常的恢復流程來恢復它們。

9. 總結

SUSE Rancher 讓企業能通過統一的安全、策略和使用者管理方法來簡化多叢集 Kubernetes 操作。而 Kasten K10 by Veeam 能使 Kubernetes 原生應用程式的備份和恢復、災難恢復和遷移變得簡單。SUSE 和 Veeam 共同為企業提供降低風險和加快雲原生實現所需的工具。

本指南講解了如何將 Kasten K10 無縫部署到 Rancher Kubernetes 環境中，如何建立策略驅動的備份，以及如何恢復應用程式。

如需瞭解更多資訊，請參閱：

使用 Kasten K10 by Veeam 和 SUSE Rancher 來保護雲原生工作負載： http://youtu.be/c_mSNy6Q9RU
Kasten K10 by Veeam 和 SUSE Rancher：企業 K8s 資料保護： http://www.suse.com/c/kasten-k10-by-veeam-and-suse-rancher-enterprise-k8s-data-protection/
使用 SUSE Rancher、Fleet 和 Kasten K10 部署多叢集 Day 2 操作： http://www.suse.com/c/deploying-multicluster-day-2-operations-with-suse-rancher-fleet-and-kasten-k10/
通過 2 個簡單步驟開始使用 SUSE Rancher： http://www.suse.com/products/suse-rancher/get-started/
免費下載 Kasten K10 並在最多 5 個節點上使用它： http://www.kasten.io/free-kubernetes
Kasten K10 文件：htt ps://docs.kasten.io/latest/index.html
Rancher 文件：ht tps://rancher.com/docs/rancher/v2.x/en/

About SUSE Rancher

Rancher是一個開源的企業級Kubernetes管理平臺，實現了Kubernetes叢集在混合雲+本地資料中心的集中部署與管理。Rancher一向因操作體驗的直觀、極簡備受使用者青睞，被Forrester評為“2020年多雲容器開發平臺領導廠商”以及“2018年全球容器管理平臺領導廠商”，被Gartner評為“2017年全球最酷的雲基礎設施供應商”。

目前Rancher在全球擁有超過三億的核心映象下載量，並擁有包括中國聯通、中國平安、中國人壽、上汽集團、三星、施耐德電氣、西門子、育碧遊戲、LINE、WWK保險集團、澳電訊公司、德國鐵路、廈門航空、新東方等全球著名企業在內的共40000家企業客戶。

2020年12月，SUSE完成收購RancherLabs，Rancher成為了SUSE “創新無處不在（Innovate Everywhere）”企業願景的關鍵組成部分。SUSE和Rancher共同為客戶提供了無與倫比的自由和所向披靡的創新能力，通過混合雲IT基礎架構、雲原生轉型和IT運維解決方案，簡化、現代化並加速企業數字化轉型，推動創新無處不在。

當前，SUSE及Rancher在中國大陸及港澳臺地區的業務，均由數碩軟體（北京）有限公司承載。SUSE在國內擁有優秀的研發團隊、技術支援團隊和銷售團隊，將結合Rancher領先的雲原生技術，為中國的企業客戶提供更加及時和可信賴的技術支撐及服務保障。

「其他文章」