作者 | 王思宇(酒祝)
來源|
阿裡巴巴雲原生公衆号得益于 Kubernetes 面向終态的理念，雲原生架構天然具備高度自動化的能力。然而，面向終态的自動化是一把“雙刃劍”，它既為應用帶來了聲明式的部署能力，同時也潛在地會将一些誤操作行為被終态化放大。
是以，充分了解雲原生環境下那些潛在的影響應用安全的問題，提前掌握多方位的安全防護、攔截、限流、熔斷等技術手段來保障雲原生應用的運作時穩定性至關重要。
本文整理自作者阿裡雲容器服務技術專家，OpenKruise 作者 & 初創人員之一，Kubernetes、OAM 社群貢獻者王思宇（酒祝）于 1 月 19 日在阿裡雲開發者社群“周二開源日”的直播分享，介紹了雲原生環境下應用安全與可用性的“處處危機”，分享阿裡巴巴保障雲原生應用運作時穩定性經驗，并且詳細解讀了後續這些能力将如何通過 OpenKruise 賦能給開源。
點選回看完整視訊：
https://developer.aliyun.com/live/246065雲原生環境應用安全“危機”
1. 阿裡巴巴雲原生應用部署結構
這裡的雲原生應用部署結構是在阿裡巴巴原生環境最簡化的抽象圖，如下圖所示。
首先我們來看幾個 CRD。CloneSet CRD 可以了解成 deployment 的一個 workload，也就是給應用部署 Pod 的模闆。有了 CloneSet CRD 之後，不同的業務以及不同的應用會建立對應的 CloneSet，在 CloneSet 下面再建立對應的 Pod，以及對 Pod 做一些部署、釋出相關的管理。
除了 CloneSet 之外，還提供了 SidecarSet CRD，這個 CRD 做的事情是在業務 Pod 建立階段注入 SidecarSetCRD 中定義的 Sidecar 容器。也就是說，在 CloneSet 中業務隻需要定義 Pod 中的 app 容器，也就是業務容器。在 Pod 建立過程中，通過 SidecarSet 在其中定義業務中要注入哪些 sidecar 容器。
2. OpenKruise：阿裡巴巴應用部署基座
開源的 OpenKruise 是阿裡巴巴應用部署的基座。OpenKruise 提供了多種的 workload。其中包括：CloneSet、Advanced StatefulSet、SidecarSet、Advanced DaemonSet。
- CloneSet：是面向無狀态應用部署的工具，也是阿裡巴巴中使用規模最大的部分，絕大部分泛電商業務都是通過 CloneSet 來部署釋出，包括 UC 神馬、餓了麼、電商業務等。
- Advanced StatefulSet：針對一個原生 StatefulSet 相容的增強版本，是面向有狀态應用部署的工具，目前主要是用于中間件在雲原生環境的部署。
- SidecarSet：是在阿裡巴巴環境中 sidecar 生命周期管理的工具。阿裡巴巴的運維容器，以及阿裡内部的 Mesh 容器，都是通過 SidecarSet 定義、部署以及注入到業務 Pod 中的。
- Advanced DaemonSet：是針對原生 DaemonSet 相容增強版本。将主控端級别的守護程序部署到所有節點上，包括各種用于給業務容器配置網絡、存儲的基礎元件。
介紹完基礎環境之後，我們已經對雲原生部署結構有了一個基本的了解。下面，我們來了解在雲原生部署結構之下存在哪些雲原生應用安全危機。
3. 雲原生應用安全危機
1）workload 級聯删除
Workload 級聯删除，這一點不隻針對于 Kruise 的 CloneSet，對于 Deployment，對于原生的 StatefulSet 都存在類似的問題。指的是當我們删除一個 Workload 之後，假設使用采用預設删除，沒有使用 orphan 删除這種政策的話，底下的 Pod 都會被删掉，這裡存在一種誤删風險。也就是說，一旦某個 Deployment 被誤删，那麼它底下的所有 Pod 都會級聯被删掉，導緻整個應用不可用。如果有多個 Workload 被删掉，就可能導緻很多個業務出現不可用的情況，這是一個對可用性造成的風險。如下圖所示：
2）namespace 級聯删除
那麼我們再往上看，如果 Namespace 被删掉，那麼整個 Namespace 底下的所有資源，包括 Deployment、CloneSet 這些 Workload，也包括 Pod、Service 等所有資源都會被删除，這是一種很高的誤删風險。
3）CRD 級聯删除
如果有用 Helm 部署的同學可能會遇到過類似的情況，也就是如果你的 Helm 中包含了一些 CRD，這些 CRD 都被定義在 template 中， 那麼當 Helm uninstall 的時候，基本上這些 CRD 都會被 Helm 包級聯删除掉，包括有人手動誤删了某個 CRD，那麼 CRD 底下對應的 CR 都會被清理。這是一個很高的風險。
如果 CRD 是 CloneSet 這種 Workload 級别的 CRD，那麼一旦删除這個 CRD 之後，會導緻所有 CRD 底下的 CloneSet 的 CR 對象全部被删掉，進而導緻所有的業務 Pod 全部被删掉。也就是說，删除一個 Workload，隻是這個 Workload 底下的 Pod 被删掉；删除一個 Namespace 可能隻是 Namespace 底下的 Pod 被删掉。但如果像阿裡巴巴這種場景下，如果有人把 CloneSet 或者一些很關鍵的 CRD 删掉的話 ，其實很可能導緻整個叢集環境所有 NameSpace 底下的 Pod 都會被級聯删掉，或者說都會處于應用不可用的狀态，造成雲原生環境對于應用可用性的風險。如下圖所示：
從上文可以看出來，雲原生這種理念架構為我們帶來的好處是面向終态，也就是說我們定義終态，進而整個 Kubernetes 叢集就會向終态靠攏。而一旦出現一些誤操作導緻定義了一種錯誤的終态，那麼 Kubernetes 也會向錯誤的終态靠攏，導緻出現錯誤的結果，進而影響到整個應用的可用性。是以我們說，面向終态是一把“雙刃劍”。
4）并發 Pod 更新/驅逐/删除
除了幾種誤删的情況，還有更多針對可用性的風險。如下圖所示，假設左邊 CloneSetA 部署了兩個 Pod，這兩個 Pod 中又被 SidecarSet 注入了對應的 sidecar 容器。在這種情況下，如果通過 CloneSet 做應用釋出，假設說我們設定的 Max Available 是 50%，也就是說，兩個 Pod 是逐個更新，前一個更新完成，後一個才能開始更新，預設情況下這種釋出政策是沒有問題的。
但是如果 Pod 有多個 Owner，比如 CloneSet 是其中一個 Owner，CloneSet 對上面的 Pod 開始做原地更新，SidecarSet 對第二個 Pod 做 sidecar 的原地更新，那麼同一時刻可能這個應用的兩個 Pod 都在被更新。因為在 CloneSet 定義了 Max Unavailable 是 50%，從它的視角來看，隻要選取兩個 Pod 中的一個開始做更新。CloneSet 本身是無法感覺到其它控制器甚至其他人為的行為去對其它 Pod 做操作，缺乏全局視角，每一個控制器都認為自己在更新的 Pod 是符合更新政策，符合最大不可用測略。但當多個控制器同時開始工作的時候，可能會導緻整個應用 100% 不可用。
如上圖右邊的情況，CloneSetC 底下有 3 個 Pod，如果它開始做更新的時候隻更新其中一個 Pod，假設是重建更新，它會把舊版本 Pod 删掉，先建新版本 Pod。在這過程中，假設另外兩個 Pod 一個可能被 Kubelet，或者 kube-controller-manager 中的 node lifecycle controller 驅逐，這時候已經有兩個 Pod 不可用，已經超過 Workload 中定義的最大不可用釋出政策。在這個過程中，還可能有一些 Pod 被其他一些控制器其他有人工手動删除。種種可能性導緻一個 Workload 下 Pod 的不可用數量，很可能是超過本身 workload 中定義的不可用釋出政策的。
也就是說，在 Deployment 中定義了 Max Unavailable 是 25%，那麼 Deployment 在釋出的時候，從它自身角度來看保證 25% 的 Pod 在被釋出。其他 75% 的 Pod 并不保證完全可用，這 75% 的 Pod 可能被 Kubelet 驅逐、可能被人為手動删除、可能被 SidecarSet 外部熱更新等等，種種情況可能會導緻 Deployment 超過 50% 不可用，甚至更高，使整個應用受到影響。
雲原生應用安全防護實踐
針對以上種種危機，我們能采取怎麼樣的措施，保證原生環境下應用安全的可用性、安全性。下面介紹一些實踐的經驗。
1. 防護實踐 - 防級聯删除
由于級聯删除對應用可用性危害非常大，包括了删除 CRD 節點，删除 Namespace 節點，以及删除 Workload 節點。防級聯删除定義了針對多種資源，包括 CRD、Namespace、包括原生 Deployment 在内的各種 Workload 等，對這些資源提供了針對的 labels 定義。
下面是針對各種重要節點防級聯删除的語名：
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
labels:
policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: v1
kind: Namespace
metadata:
labels:
policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
policy.kruise.io/disable-cascading-deletion: true
---
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
metadata:
labels:
policy.kruise.io/disable-cascading-deletion: true labels 定義是關閉級聯删除，使用者的任何 CRD、Namespace、workload 裡帶有防級聯删除辨別之後，kruise 就會保證資源防級聯删除校驗。也就是說，當使用者删除一個 CRD 時，如果這個 CRD 裡帶有防級聯删除這個 label，那麼 kruise 就會去檢視 CRD 底下是否還有存量 CR，如果有存量 CR 那麼 kruise 會禁止 CRD 删除。
同理，在 Namespace 删除時，也會校驗 Namespace 底下是否還有存量的運作狀态的 Pod，如果有，會禁止使用者直接删除 Namespace。
對于 workload 邏輯相對簡單，就對于 Deployment、CloneSet、SidecarSet，當使用者去删除 workload 時，如果 workload 中使用者已經定義了防級聯删除的 label，那麼 kruise 會檢查 workload 的 replica 是否為 0，如果 replica 大于 0，那麼 kruise 是禁止使用者直接删除帶有防級聯删除辨別的 workload。也就是說，當一個存量 Deployment，如果 replicas 大于 0 的情況下，如果 Deployment 中存在帶有防級聯删除辨別，kruise 禁止使用者直接删除。
如果真的需要删除 Deployment 有兩種辦法：
- 第一，先把 replica 調為 “0”，這時底下 Pod 開始被删除，這時删除 Deployment 是沒問題的。
- 第二，可以把 Deployment 中防級聯删除辨別去掉。
以上是關于防級聯删除的介紹，大家應該将防級聯删除了解成安全防護最基礎的一個政策，因為級聯删除是 Kubernetes 中非常危險的一個面向終态的能力。
2. 防護實踐 – Pod 删除流控 & 熔斷
針對 Pod 删除流控 & 熔斷的政策，指的是使用者調用、或用控制器用 K8s 去做 Pod 驅逐時，一旦出現誤操作或者出現邏輯異常，很可能導緻在整個 K8s 叢集範圍内出現 Pod 大規模删除的情況。針對這種情況做了 Pod 删除留白政策，或者說是一個 CRD。這個 CRD 使用者可以定義在一個叢集中，不同的時間視窗内，最多有多少 Pod 允許被删除。
apiVersion: policy.kruise.io/v1alpha1
kind: PodDeletionFlowControl
metadata:
# ...
spec:
limitRules:
- interval: 10m
limit: 100
- interval: 1h
limit: 500
- interval: 24h
limit: 5000
whiteListSelector:
matchExpressions:
- key: xxx
operator: In
value: foo 如上面這個例子，10 分鐘之内最多允許 100 個 Pod 被删除，1 小時之内最多允許 500 個 Pod 被删除，24 小時内最多允許 5000 個 Pod 被删除。當然也可以定義一些白名單，比如有些測試應用，每天頻繁地巡檢、測試，頻繁删除會影響整個流控，可以提供一個白名單，符合白名單的應用不計算在視窗内。
除了白名單之外，可能 90% 的正常應用或者核心應用，是受到删除流控保護的。一旦存在規模性誤删除操作，就會被删除流控以及熔斷機制保護。包括在保護之後或者觸發門檻值之後，最好提供這種報警機制、監控機制，讓叢集的管理者能快速的感覺到線上出現的熔斷事件。還包括幫助管理者去判斷熔斷事件是一個正常的事件，還是一個異常的事件。
如果在這段時間内，需要存在很多删除請求，可以把對應政策值相應放大。如果真的是一些誤删除，攔截到之後，及時根據請求來源做溯源，及時在搜尋層面做熔斷，拒絕這些請求。
3. 防護實踐 - 應用次元不可用數量保護
對應用次元不可用數量保護，對于 K8s 原生，原生的 Kubernetes 提供了 PDB(PodDisruptionBudge) 政策，但是 PDB 隻能攔截 Pod eviction 驅逐操作，也就是 Pod 驅逐操作。
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: xxx
spec:
minAvailable: 2
selector:
matchLabels:
app: xxx 上面的這個例子，假設其中有 5 個 Pod，這時定義了 minAvailable=2，就保證最少有 2 個 Pod 處于可用。一旦有 3 個 Pod 不可用，還剩下 2 個 Pod 可用，這時候如果 Pod eviction 針對存量 2 個 Pod 做驅逐，這個時候 PDB 會保護 Pod 可用性，拒絕這次驅逐操作。但是相應的如果對存量 2 個 Pod 做删除或者原地更新，或者去做其他導緻 Pod 不可用的事情，PDB 是沒有辦法攔截，尤其是針對 Pod 删除請求，比 Pod 驅逐更為常見，但是 PDB 是沒辦法攔截删除等請求。
對于這些問題，阿裡巴巴做了 PodUnavailableBudget 攔截操作，也就是 PUB。這裡的 Unavailable 能做的操作就更多了，基本上所有可能導緻 Pod 不可用的操作，都在 PodUnavailableBudget 保護範圍内，包括了驅逐請求、Pod 删除請求，應用原地更新、Sidecar 原地更新、容器重新開機等，所有導緻應用不可用的操作都會被 PUB 攔截。
如下面這個例子：
apiVersion: policy.kruise.io/v1alpha1
kind: PodUnavailableBudget
spec:
#selector:
# app: xxx
targetRef:
apiVersion: apps.kruise.io
kind: CloneSet
name: app-xxx
maxUnavailable: 25%
# minAvailable: 15
status:
deletedPods:
pod-uid-xxx: "116894821"
unavailablePods:
pod-name-xxx: "116893007"
unavailableAllowed: 2
currentAvailable: 17
desiredAvailable: 15
totalReplicas: 20 定義了一個 PUB，這個 PUB 可以像原生 PDB 一樣寫一個 selector 範圍，也可以通過 targetRef 直接關聯到某一個 Workload，保護範圍就是在 Workload 底下的所有 Pod，同樣也可以定義最大不可用數量，以及最小可用數量。
假設對于 CloneSet 底下總共 20 個 Pod，當定義了 maxUnavailable：25% 時，一定要保證至少有 15 個 Pod 處于可用狀态。也就是說，PUB 會保證這 20 個 Pod 中最多有 5 個處于不可用狀态。回到我們之前在“危機”部分講到的一個例子，如果這 20 個 Pod 同時在被 Cloneset 釋出，以及被 Kubelet 驅逐，或是人工手動删除，一旦 Pod 不可用數量超過 5 個，不管是 Kubelet 對剩餘 15 個 Pod 做驅逐，還是人為手動删除剩餘的某些 Pod，這些操作都會被 PUB 所攔截，這種政策能完全保證應用在部署過程中的可用性。PUB 可以保護的範圍比 PDB 大很多，包括在實際使用過程中預期之外的一些删除請求、更新請求，進而保證整個應用在運作時的穩定性和可用性。
4. 防護實踐 - PUB/PDB 自動生成
對于真正的 Depoyment 應用開發者、運維人員來說，一般而言，隻需要定義自身 workload 中 template，業務方隻關心 Depoyment templatek 中業務的版本、環境變量、端口、提供的服務，但我們很難去強制每一個業務方在定義應用時，另外寫一個 PUB 或者 PDB 保護政策的 CR。那麼，我們怎樣對每一個應用提供自動保護呢？
在阿裡巴巴内部，我們針對每個 Workload 提供自動生成 PUB/PDB 的能力。比如說，如果使用者此時新建立了一個 Deployment，會通過控制器自動為該 Deployment 生成一個比對的 PUB。這個自動生成的功能即能支援原生 Deployment/StatefulSet，也支援 Kruise 的 CloneSet / Advanced StatefulSet / UnitedDeployment。第二，預設根據 strategy 中 maxUnavailable 政策。第三，允許 annotation 中單獨定義保護政策。如下面的語句所示：
apiVersion: apps
kind: Deployment
metadata:
name: deploy-foo
annotations:
policy.kruise.io/generate-pub: "true"
policy.kruise.io/generate-pub-maxUnavailable: "20%"
# policy.kruise.io/generate-pub-minAvailable: "80%"
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
# ...
---
# auto generate:
apiVersion: policy.kruise.io/v1alpha1
kind: PodUnavailableBudget
spec:
targetRef:
apiVersion: apps
kind: Deployment
name: deploy-foo
maxUnavailable: 20% 自動生成的 PUB/PDB 内部填寫的 maxUnavailable，既可以讓使用者在 kruise 中指定定義。比如使用者可以直接把 kruise.io/generate-pub:"true"，也可以 kruise.io/generate-pub-maxUnavailable:"20%"，可以讓使用者指定應用最多允許有多少個不可用。這是使用者指定的政策。
如果使用者沒有指定政策，會根據在釋出政策中存在的maxUnavailable生成 PUB。就是指在釋出的階段，有多少個不可用數量，做為應用運作時最大不可能數量。這是允許單獨定義政策。
OpenKruise 的新領域
1. OpenKruise 介紹
最後，和大家介紹上述開放的能力在 OpenKruise 新領域如何去開放，以及怎麼拓展對 OpenKruise 的認知。
OpenKruise是阿裡雲開源的 Kubernetes 擴充應用負載項目，本質上是圍繞 Kubernetes 雲原生應用去做一系列自動化能力的引擎，同時也是阿裡巴巴經濟體上雲全面使用的部署基座。
OpenKruise 的定位，做的不是一個完整的平台，更類似于是 Kubernetes 中一個拓展的産品。這個拓展的産品作為一個 add on 的元件，提供了一系列針對在 Kubernetes 中部署應用，以及後續保護防護應用可用、圍繞雲原生應用的一些自動化的能力，這些拓展能力或者增強能力，是原生 Kubernetes 所不具備，但也是迫切需要它所擁有這些能力，是阿裡巴巴内部在雲原生逐漸演進過程中去沉澱的一些通用能力。
目前，Kruise 提供了以下 workload 控制器：
- CloneSet：提供了更加高效、确定可控的應用管理和部署能力，支援優雅原地更新、指定删除、釋出順序可配置、并行/灰階釋出等豐富的政策，可以滿足更多樣化的應用場景。
- Advanced StatefulSet：基于原生 StatefulSet 之上的增強版本，預設行為與原生完全一緻，在此之外提供了原地更新、并行釋出(最大不可用)、釋出暫停等功能。
- SidecarSet：對 sidecar 容器做統一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器。
- UnitedDeployment：通過多個 subset workload 将應用部署到多個可用區。
- BroadcastJob：配置一個 job 在叢集中所有滿足條件的 Node 上都跑一個 Pod 任務。
- Advanced DaemonSet：基于原生 DaemonSet 之上的增強版本，預設行為與原生一緻，在此之外提供了灰階分批、按 Nodelabel 選擇、暫停、熱更新等釋出政策。
- AdvancedCronJob：一個擴充的 CronJob 控制器，目前 template 模闆支援配置使用 Job 或 BroadcastJob。
2. 原生 workload 能力缺陷
根據 Deployment 去 CloneSet、AdcancedStatefulSet 是因為原生 workload 能力缺陷有很多。大家可以看到，基本上從 Kubernetes 1.10 版本之後，其實其他的功能，包括 pod 裡面，它的字段還是在不斷豐富，包括更多的 pod 的能力支援、更多的政策等，但是對于 workload 層面，就是 deployment 和 StatefulSet 層面，已經不傾向于做任何改動。社群在這背後的考慮是因為在不同公司、不同業務場景下，應用部署釋出層面需求很多。
Kubernetes 原生提供的 Deployment，是面向一些最通用最基礎的一些環境，沒辦法用它去滿足所有的業務場景，但實際上社群是非常鼓勵有更高需求，更大更複雜場景規模需求的使用者，自行通過 CRD 去拓展編寫，利用更強大的 workload，來滿足不同的業務的場景需求。
3. OpenKruise與原生能力對比
橙色：開源中 / 綠色：已開源
那麼，對于這場景而言，Kruise 已經做了比較完備的一個無狀态以及有狀态應用的部署，通過上圖表格能看到 Kruise 提供的 workload 和原生 deployment、StatefulSet、DaemonSet 的對比。
4. OpenKruise 2021 規劃
如上圖所示，OpenKruise 是一個雲原生應用自動化引擎，目前提供的 workload 能力在應用部署，但不會僅局限于應用部署這一個領域的。
1）風險防控
在 2021 年上半年的規劃中，我們會針對上面講到的雲原生應用的風險和防控的政策，會通過 OpenKruise 輸出給社群。包括 CRD 删除防護、級聯删除防護、全局 Pod 删除流控、Pod 删除/驅逐/原地更新防護、自動為 workload 生成 PDB/PUB 等。
2）Kruise-daemo
除此之外之前 OpenKruise 隻是作為一個中心的控制器部署，下個版本中會提供一個 Kruise-daemon 通過 daemon set 部署到每個節點上，可以幫使用者去做一些鏡像預熱，釋出加速，容器重新開機 ，單機排程優化的一些政策。
3）ControllerMesh
ControllerMesh 是 OpenKruise 提供出來幫助使用者管理使用者叢集中其他運作時的一些控制器運作時的能力，通過流量控制等方式解決傳統控制器單住模式帶來的種種問題。
最後，在 OpenKruise 項目社群建設方面，已經在 2020 年 11 月 11 号經 CNCF 技術監督委員會全體成員投票，一緻同意正式進入 CNCF Sanbox，在整個過程中也得到了 CNCF 積極的回應，表示 OpenKruise 項目與 CNCF 倡導的理念很契合，鼓勵有更多像 OpenKruise 這樣能做一些通用化的，面向更複雜的場景，更大規模的一些這種自主的 Workload 能力的項目出現。
現在已經有很多公司在使用 OpenKruise 的這些能力，比如：
- 基于原地更新、灰階釋出等需求，攜程在生産環境使用CloneSet、AdvancedStatefulSet 來分别管理無狀态、有狀态應用的服務，單叢集 Kruise workload 數量達到萬級别。
- OPPO 公司不僅大規模使用了 OpenKruise，還在下遊配合其定制化的 Kubernetes 進一步加強了原地更新的能力，廣泛應用在多個業務的後端運作服務中，通過原地更新覆寫了 87% 左右的更新部署需求。
- 此外，國内的使用者還有蘇甯、鬥魚 TV、有贊、比心、Boss 直聘、申通、小紅書、VIPKID、掌門教育、杭銀消費、萬翼 科技、多點 Dmall、佐疆科技、享住智慧、艾佳生活、永輝科技中心、跟誰學，國外的使用者有 Lyft、Bringg、 Arkane Systems 等。
- Maintainer 5 位成員來自阿裡巴巴、騰訊、Lyft
- 51 位貢獻者
- 國内：阿裡雲、螞蟻集團、攜程、騰訊、拼多多...
- 國外：微軟、Lyft、Spectro Cloud、Dsicord...
- 2000+ GitHub Stars
- 300+ Forks
如果大家對 OpenKruise 項目感興趣，有任何希望交流的話題，歡迎大家通路
OpenKruise 官網、
GitHub，以及加入釘釘交流群：
“Kubernetes 與雲原生應用開源實踐大講堂”
4 場雲原生與 Kubernetes 技術前沿話題直播、70 節經典課程、3 本雲原生電子書，來“Kubernetes 與雲原生應用開源實踐大講堂”，和阿裡雲容器技術專家一起，将熱門的容器開源項目和前沿的雲原生應用落地實踐一網打盡！
點選直達“Kubernetes 與雲原生應用開源實踐大講堂”！