在 Kubernetes 叢集中執行混沌實驗
設定許可權時，我們實際上唯一的限制是建立 RoleBinding 而不是 ClusterRoleBinding。這些許可權將被賦予該名稱空間內的 ServiceAccount。因此，我們將混沌工具包的能力限制在該名稱空間內，它將無法影響整個叢集。
未來，我們可能會探討更廣泛的許可權範圍，例如建立在整個叢集層級運作的實驗子集。但就目前而言，將許可權限制在特定名稱空間應該足夠了。如前所述，這些許可權將允許混沌工具包在特定名稱空間內執行幾乎所有操作。
現在，剩下的就是應用該定義並建立 ServiceAccount、Role 和 RoleBinding。
kubectl --namespace go-demo-8 apply --filename k8s/chaos/sa.yaml
現在，我們應該能夠在 Kubernetes 叢集中執行實驗。我們有了包含實驗定義的 ConfigMap，並且將 ServiceAccount 繫結到具有足夠許可權的 Role。
實驗執行型別
一般來說，我們可以透過兩種方式執行實驗。或者更具體地說，我們將探討兩種方式，儘管肯定還有其他方法。
我們可以透過按需執行實驗來執行一次性實驗。 我們可以說：「現在就執行該實驗」。我稱它們為「一次性」，因為此類別實驗不會重複發生。我們可以選擇何時執行它們，並且它們只會在執行時存在。我們將能夠監控進度並觀察正在發生的事情。我們可以手動執行這些實驗，或者可以將它們連線到我們的持續交付中。在後一種情況下，它們將成為我們管道的一部分，例如，每當我們佈署新版本時都會執行。
稍後，我們將探討如何建立定期執行的排程實驗。我們可能會選擇每隔幾分鐘、每隔幾小時、每天一次或根據我們定義的任何排程進行混沌工程。
執行一次性實驗
現在，我們將專注於我們將手動或透過管道或透過我們認為合適的任何其他方式執行的一次性實驗。
讓我們看一下另一個 Kubernetes YAML 檔案。
cat k8s/chaos/once.yaml
輸出如下：
apiVersion: batch/v1
kind: Job
metadata:
name: go-demo-8-chaos
spec:
activeDeadlineSeconds: 600
backoffLimit: 0
template:
metadata:
labels:
app: go-demo-8-chaos
annotations:
sidecar.istio.io/inject: "false"
spec:
serviceAccountName: chaostoolkit
restartPolicy: Never
containers:
- name: chaostoolkit
image: vfarcic/chaostoolkit:1.4.1-2
args:
- --verbose
- run
- /experiment/health-http.yaml
env:
- name: CHAOSTOOLKIT_IN_POD
value: "true"
volumeMounts:
- name: config
mountPath: /experiment
readOnly: true
resources:
limits:
cpu: 20m
memory: 64Mi
requests:
cpu: 20m
memory: 64Mi
volumes:
- name: config
configMap:
name: chaostoolkit-experiments
重要的是，我們定義了一個 Kubernetes Job。
「Job 建立一個或多個 Pod，並確保指定數量的 Pod 成功終止。隨著 Pod 成功完成，Job 會追蹤成功的完成次數。當達到指定數量的成功完成次數時，任務（Job）即完成。刪除 Job 將清除它建立的 Pod。」
從該描述（取自 Kubernetes 檔案）中，我們可以看到，Job 是一個很好的候選者，可以在執行一次的同時能夠追蹤狀態，尤其是其中程式的離開程式碼。如果我們將自己限制在核心 Kubernetes 元件中，當我們想要執行類別似實驗的事情時，Job 可能是我們可以使用的最合適的 Kubernetes 資源型別。
Job 中容器內的程式將啟動、執行和完成。與大多數其他 Kubernetes 資源不同，Job 在成功或 Pod 被刪除時不會重新啟動或重新建立。與佈署和 StatefulSets 相比，這是主要區別之一。
最重要的是，我們可以將 Job 組態為在失敗時不重新啟動。這就是我們在該定義中透過將 spec.template.spec.restartPolicy 設定為 Never 所做的。實驗可以成功或失敗，無論實驗結果如何，該 Job 建立的 Pod 只會執行一次。
該規範的大部分內容並不是很有趣。重要的是，我們將 serviceAccountName 設定為 chaostoolkit。這應該賦予 Job 足夠的許可權來執行我們需要它執行的任何操作。
我們只定義了一個容器。如果我們想執行多個實驗，我們可以有更多容器。但是，就我們的目的而言，一個容器應該足以演示定義為 Job 的實驗是如何工作的。
我鼓勵您建立自己的容器映像，其中包含混沌工具包、所需的外掛以及您可能需要的任何其他內容。但是，為了簡化事情，我們將使用我建立的容器映像（vfarcic/chaostoolkit）。我們稍後將討論該映像。
我們可以從 args 中看到，我們希望輸出是詳細的，並且它應該執行 /experiment/health-http.yaml 中定義的實驗。如果您想知道該檔案來自哪裡，簡短的答案是「來自 ConfigMap」。我們稍後會討論它。
然後，我們將環境變數 CHAOSTOOLKIT_IN_POD 設定為 true。混沌工具包在 Pod 內執行時可能需要略有不同的行為，因此我們使用該變數來確保它知道它在哪裡。
此外，我們還有 volumeMounts。我們將名為 config 的東西掛載為目錄 /experiment。該「東西」在 volumes 部分中定義，它參照了我們之前建立的 ConfigMap chaostoolkit-experiments。這樣，來自該 ConfigMap 的所有條目都將作為容器中 /experiment 目錄內的檔案提供。
最後，我們還定義了資源，以便 Kubernetes 知道我們正在請求多少記憶體和 CPU，以及限制應該是多少。
在我們繼續之前，讓我們快速看一下映像 vfarcic/chaostoolkit 的定義。
如果您是 Windows 使用者，則 open 命令可能無法使用。如果是這種情況，請從以下命令中複製網址，並將其貼上到您喜歡的瀏覽器中。
open "https://github.com/vfarcic/chaostoolkit-container-image"
該儲存函式庫只有 Dockerfile。開啟它，您將看到容器映像的定義。如下所示：
FROM python:3.8.1-alpine
LABEL maintainer="Viktor Farcic <viktor@farcic.com>"
RUN apk add --no-cache --virtual build-deps gcc g++ git libffi-dev linux-headers python3-dev musl-dev && \
pip install --no-cache-dir -q -U pip && \
pip install --no-cache-dir chaostoolkit && \
pip install --no-cache-dir chaostoolkit-kubernetes && \
pip install --no-cache-dir chaostoolkit-istio && \
pip install --no-cache-dir chaostoolkit-slack && \
pip install --no-cache-dir slackclient==1.3.2 && \
apk del build-deps
ENTRYPOINT ["/usr/local/bin/chaos"]
CMD ["--help"]
我會假設您已經熟悉 Dockerfile 格式，並且您知道它用於定義工具可以用來構建容器映像的指令。有很多構建器使用這樣的定義，Docker 和 Kaniko 是眾多構建器中的兩個。
如您所見，映像（Dockerfile）的定義相對簡單明瞭。它根據 python，因為這是混沌工具包的要求，它安裝了我們需要的 CLI 和外掛。入口點是 chaos 二進位檔案的路徑。預設情況下，如果我們不覆寫命令（CMD），它將輸出幫助。
現在我們已經探討了將執行實驗的 Job，我們準備應用它並檢視結果。
內容解密： 以上 YAML 檔案定義了一個 Kubernetes Job，用於執行混沌實驗。它使用 vfarcic/chaostoolkit 容器映像，並將 ConfigMap chaostoolkit-experiments 掛載到容器中，以便實驗定義檔案 health-http.yaml 可供容器存取。serviceAccountName 被設定為 chaostoolkit，以便 Job 擁有必要的許可權。restartPolicy 設定為 Never，確保 Pod 只執行一次，無論實驗結果如何。資源限制也已定義，以控制 Job 的 CPU 和記憶體使用量。
graph LR
subgraph Kubernetes Cluster
subgraph go-demo-8 Namespace
Job["go-demo-8-chaos"] --> Pod["chaostoolkit Pod"]
Pod --> ConfigMap["chaostoolkit-experiments"]
Pod --> ServiceAccount["chaostoolkit"]
ServiceAccount --> Role["chaostoolkit Role"]
end
end
內容解密： 此圖表展示了 Kubernetes 叢集中執行混沌實驗的元件關係。go-demo-8-chaos Job 在 go-demo-8 名稱空間中建立了一個 chaostoolkit Pod。該 Pod 使用 chaostoolkit-experiments ConfigMap 中的實驗定義，並利用 chaostoolkit ServiceAccount 的許可權執行實驗。ServiceAccount 與 chaostoolkit Role 繫結，賦予其在名稱空間內的操作許可權。
在 Kubernetes 叢集中執行混沌實驗
我們可以透過類別似於在本地端執行實驗的方式，在 Kubernetes 叢集中執行混沌實驗。現在，我們將探討如何在 Kubernetes 叢集中執行一次性（one-shot）和定期（scheduled）混沌實驗。
執行一次性實驗
一次性實驗適用於特定事件觸發的場景，例如新版本佈署後，或是作為排程演練的一部分。以下是如何在 Kubernetes 叢集中建立及執行一次性實驗：
kubectl --namespace go-demo-8 apply --filename k8s/chaos/once.yaml
這會建立一個名為 go-demo-8-chaos 的 Job。我們可以透過以下指令檢視該 Job 建立的 Pod：
kubectl --namespace go-demo-8 get pods --selector app=go-demo-8-chaos
Pod 執行完成後，狀態會顯示為 Completed。我們可以透過以下指令檢視 Pod 的日誌，確認實驗是否成功：
kubectl --namespace go-demo-8 logs --selector app=go-demo-8-chaos --tail -1
日誌輸出會包含實驗的詳細事件，與在本地端執行實驗的輸出類別似，但 Kubernetes 會新增時間戳記和日誌級別。實驗完成後，我們可以刪除 Job：
kubectl --namespace go-demo-8 delete --filename k8s/chaos/once.yaml
執行定期實驗
定期實驗適用於需要週期性執行混沌實驗的場景，例如每天的特定時間，或隨機時間。以下是如何建立定期執行的混沌實驗：
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: go-demo-8-chaos
spec:
concurrencyPolicy: Forbid
schedule: "*/5 * * * *"
jobTemplate:
# ... 與一次性實驗的 Job 定義類別似
這個 YAML 定義了一個 CronJob，它會根據設定的排程定期建立 Job。concurrencyPolicy: Forbid 確保一次只執行一個實驗。schedule: "*/5 * * * *" 表示每五分鐘執行一次實驗（實際應用中，頻率可能會更低，例如每小時或每天一次）。
jobTemplate 部分與一次性實驗的 Job 定義類別似，但新增了一個 results volume，用於儲存實驗的日誌檔案：
volumes:
- name: results
persistentVolumeClaim:
claimName: go-demo-8-chaos
--journal-path 引數設定日誌檔案的路徑為 /results/journal-health-http.json，由於 /results 目錄掛載到外部儲存，日誌檔案會被持久化儲存。
Mermaid 圖表 - CronJob 工作流程
graph LR
F[F]
A[CronJob] --> B{檢查排程}
B -- 符合排程 --> C[建立 Job]
B -- 不符合排程 --> D[等待]
C --> E[執行 Pod]
E --> F{實驗完成}
F -- 成功 --> G[儲存日誌]
F -- 失敗 --> H[記錄錯誤]
內容解密： 上圖展示了 CronJob 的工作流程。CronJob 會定期檢查排程，如果符合排程，則建立一個 Job。Job 會執行 Pod 進行實驗。實驗完成後，會儲存日誌或記錄錯誤。
結論
在 Kubernetes 叢集中執行混沌實驗可以透過 Job 和 CronJob 實作。一次性實驗適用於特定事件觸發的場景，而定期實驗適用於需要週期性執行實驗的場景。透過將實驗日誌儲存到外部儲存，我們可以方便地分析實驗結果。選擇哪種執行方式取決於具體的測試需求。 在 Kubernetes 叢集中執行混沌實驗時，我們可以透過 CronJob 定期執行實驗。CronJob 會根據設定的排程建立 Job，而 Job 則會建立 Pod 來執行實驗容器。
讓我們實際操作看看。首先，我們使用以下指令建立一個 CronJob：
kubectl --namespace go-demo-8 apply --filename k8s/chaos/periodic.yaml
接著，我們檢索 CronJob 並等待它執行 Job：
kubectl --namespace go-demo-8 get cronjobs
輸出結果如下：
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
go-demo-8-chaos */5 * * * * False 0 <none> 15s
如果 LAST SCHEDULE 顯示 <none>，請耐心等待，因為 Job 每五分鐘建立一次。持續執行上述指令，直到 LAST SCHEDULE 欄位顯示時間。
當 CronJob 建立 Job 後，我們可以檢索 Job：
kubectl --namespace go-demo-8 get jobs
輸出結果如下：
NAME COMPLETIONS DURATION AGE
go-demo-8-chaos-... 0/1 19s 19s
可以看到，目前只有一個 Job，因為時間不足以執行第二個。重要的是，這個 Job 是由 CronJob 建立的，而與尚未完成執行。持續執行上述指令，直到 COMPLETIONS 欄位顯示 1/1。
由於 Job 會建立 Pod，我們可以檢索所有在 go-demo-8 Namespace 中的 Pod：
kubectl --namespace go-demo-8 get pods
輸出結果如下：
NAME READY STATUS RESTARTS AGE
go-demo-8-... 2/2 Running 2 14m
go-demo-8-... 2/2 Running 0 30s
go-demo-8-chaos-... 0/1 Completed 0 82s
go-demo-8-db-... 2/2 Running 0 14m
repeater-... 2/2 Running 0 14m
repeater-... 2/2 Running 0 14m
我們可以看到應用程式的 Pod 都處於 Running 狀態，而 go-demo-8-chaos Pod 的 STATUS 為 Completed。由於 Job 會逐一在容器中啟動程式，並且在完成後不會重新啟動它們，因此 READY 欄位顯示 0/1。該 Pod 中的程式已完成，現在沒有任何容器正在執行。
實驗失敗處理
如果實驗失敗會發生什麼事？我們可以透過刪除 Deployment go-demo-8 來模擬實驗失敗。刪除 Deployment 後，應用程式的 Pod 將被終止，實驗將不可避免地失敗。
kubectl --namespace go-demo-8 delete deployment go-demo-8
刪除應用程式後，我們可以檢索由 CronJob 建立的實驗 Pod：
kubectl --namespace go-demo-8 get pods --selector app=go-demo-8-chaos
持續執行此指令，直到輸出類別似如下：
NAME READY STATUS RESTARTS AGE
go-demo-8-chaos-... 0/1 Completed 0 6m8s
go-demo-8-chaos-... 0/1 Error 0 67s
實驗失敗，因為我們刪除了它所針對的應用程式。容器內執行的程式失敗並傳回非零的離開程式碼。Kubernetes 將其視為錯誤。Pod 內容器中執行的程式並未成功終止；因此實驗失敗。
持續性儲存與報告生成
實驗日誌儲存在 PersistentVolume 中。要生成報告，我們可以建立一個附加相同儲存空間的新 Pod，並從中執行建立報告的程式。之後，我們可以將報告推播到易於存取的外部儲存空間，例如 Git 儲存函式庫、S3 儲存桶或 Artifactory 等。
以下指令可以確認 PersistentVolume 的存在：
kubectl get pv
傳送實驗通知
Chaos Toolkit 允許我們將通知傳送到不同的目標，例如 Slack 或任何 HTTP 端點。如果 Slack 不是您慣用的溝通工具，您可以將設定變更為使用其他工具，只要該目標可以接收 HTTP 請求即可。由於幾乎所有在本世紀設計的工具都透過 HTTP 公開 API，因此我們應該能夠將通知傳送到任何目標。問題在於我們是透過外掛程式（就像我們即將使用的外掛程式）還是透過 Chaos Toolkit 中提供的通用 HTTP 通知機制來執行此操作。
內容解密：
這段程式碼示範瞭如何在 Kubernetes 叢集中使用 CronJob 執行混沌實驗，並說明瞭如何處理實驗成功和失敗的情況。同時，也提到了如何使用 PersistentVolume 儲存實驗日誌，以及如何傳送實驗通知。透過這些技術，我們可以更好地管理和監控混沌實驗，並從中獲得有價值的資訊。
graph LR
C[C]
A[建立 CronJob] --> B(CronJob 執行)
B --> C{Job 建立}
C --成功--> D[Pod 執行程式]
D --> E[實驗成功]
C --失敗--> F[Pod 失敗]
F --> G[實驗失敗]
將混沌工程通知整合至 Slack
在建構可靠的 Kubernetes 應用程式時，混沌工程扮演著至關重要的角色。它讓我們可以主動模擬各種故障情境，驗證系統的韌性。而及時有效的通知機制，更是混沌工程不可或缺的一環，能讓我們迅速掌握實驗結果，及時應對潛在問題。本文將探討如何將混沌工程通知整合至 Slack，並分享一些我個人的實務經驗和技巧。
我將以 Chaos Toolkit 為例，示範如何在 Kubernetes 叢集中執行混沌實驗，並將實驗結果通知推播到 Slack。過程中，我會使用一些巧妙的技巧來處理敏感資訊，例如 Slack API token，確保安全性。
設定 Slack 通知
首先，我們需要設定 settings.yaml 檔案，其中包含 Slack 通知所需的組態資訊。這個檔案會以 Kubernetes ConfigMap 的形式儲存，方便管理和佈署。
apiVersion: v1
kind: ConfigMap
metadata:
name: chaostoolkit-settings
data:
settings.yaml: |
notifications:
- type: plugin
module: chaosslack.notification
token: xoxb-xxxxxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxxxxx
channel: tests
這個 ConfigMap 定義了一個名為 chaostoolkit-settings 的設定檔，其中 settings.yaml 存放了通知設定。請注意，我使用 xxxxxxxxxxxxx 隱藏了實際的 Slack API token，確保資訊安全。在實際應用中，您需要將其替換為您的 token。
Chaos Toolkit 預期 settings.yaml 檔案位於目前使用者的家目錄下的 .chaostoolkit/ 資料夾中。我們稍後會處理這個問題。目前，重要的是 ConfigMap 定義了 settings.yaml 檔案，其中包含我們傳送通知到 Slack 所需的一切。
settings.yaml 檔案中的通知區段指定我們要使用 chaosslack.notification 模組，該模組可透過 Slack 外掛程式取得，而該外掛程式已在我們先前探討的容器映像檔中提供。此外，我們還有 token 和 channel。前者用於驗證 Slack，而後者指定工作區內應該接收通知的頻道。
整合 ConfigMap 至 CronJob
接下來，我們需要將這個 ConfigMap 整合到我們的 CronJob 中，讓 Chaos Toolkit 能夠讀取設定。
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: go-demo-8-chaos
spec:
# ... 其他設定 ...
jobTemplate:
spec:
template:
spec:
containers:
- name: chaostoolkit
# ... 其他設定 ...
volumeMounts:
- name: settings
mountPath: /root/.chaostoolkit
readOnly: true
volumes:
- name: settings
configMap:
name: chaostoolkit-settings
我們在 CronJob 的 volumeMounts 區段中新增了一個名為 settings 的設定，將 chaostoolkit-settings ConfigMap 掛載到 /root/.chaostoolkit 目錄，這是 Chaos Toolkit 預期找到 settings.yaml 的位置。
驗證 Slack 通知
完成設定後，我們可以執行 CronJob，並觀察 Slack 頻道中的通知。如果一切順利，您應該會在每次實驗開始和結束時收到通知。
kubectl --namespace go-demo-8 apply --filename k8s/chaos/periodic-slack.yaml
過濾 Slack 通知
目前，我們會收到所有實驗的通知，無論實驗成功或失敗。在實際應用中，我們可能只想收到失敗實驗的通知。這需要修改 Chaos Toolkit 的實驗定義，加入條件判斷，例如：
{
"title": "檢查服務可用性",
"steady-state-hypothesis": {
"title": "服務應該正常回應",
"probes": [
{
"type": "probe",
"name": "HTTP 請求",
"provider": {
"type": "http",
"url": "http://example.com"
}
}
]
},
"method": [
{
"type": "action",
"name": "模擬網路延遲",
"provider": {
"type": "python",
"module": "chaosk8s.actions",
"func": "delay_network",
"arguments": {
"selector": {
"app": "my-app"
},
"delay": "5s"
}
}
}
],
"rollbacks": [],
"pauses": []
}
透過設定 steady-state-hypothesis，我們可以根據實驗結果決定是否傳送通知。
視覺化 Slack 通知流程
graph LR
A[Chaos Toolkit 實驗] --> B{實驗結果};
B -- 成功 --> C[Slack 通知 (成功)];
B -- 失敗 --> D[Slack 通知 (失敗)];
內容解密： 此流程圖展示了 Chaos Toolkit 實驗執行後，根據實驗結果傳送不同 Slack 通知訊息的流程。實驗成功則傳送成功通知，實驗失敗則傳送失敗通知。
本文詳細介紹瞭如何將混沌工程通知整合至 Slack，並分享了一些實務技巧，例如使用 ConfigMap 管理設定、過濾通知等。希望這些資訊能幫助您更好地實踐混沌工程，提升系統的可靠性和韌性。
只傳送重要的通知：聚焦失敗實驗的 Slack 通知策略
在混沌工程實驗中，持續收到每次實驗開始和結束的通知，無論成功或失敗，都可能造成資訊過載。過多的通知容易被忽略，反而可能錯過真正重要的訊息。因此，我更傾向只在發生嚴重問題時才收到通知，特別是需要採取行動的情況。
實驗成功的訊息，如果只是單純重複過去的成功模式，其價值有限。我認為「沒有訊息就是好訊息」。相對地，失敗的實驗則明確指出系統存在異常行為，需要我們介入並改善，以確保下次實驗成功。
根據這個理念，我們將修改 Chaos Toolkit 設定中的通知部分，使其僅在實驗失敗時傳送通知。如此一來，我們可以專注於處理問題，而不被大量的成功訊息淹沒。
以下是一個更新後的 YAML 範例：
apiVersion: v1
kind: ConfigMap
metadata:
name: chaostoolkit-settings
data:
settings.yaml: |
notifications:
- type: plugin
module: chaosslack.notification
token: xoxb-YOUR_TOKEN_HERE
channel: tests
events:
- discover-failed
- run-failed
- validate-failed
這個 ConfigMap 與之前的版本非常相似，主要區別在於新增的 events 部分。這裡指定了僅在特定事件發生時才傳送通知，也就是與失敗相關的事件：discover-failed（發現階段失敗）、run-failed（執行階段失敗）和 validate-failed（驗證階段失敗）。這三個事件涵蓋了 Chaos Toolkit 中所有可能的失敗場景，確保我們在任何錯誤發生時都能收到通知。
如果您想了解其他可用的事件型別，可以參考 Chaos Toolkit 官方檔案的「流程事件」部分。
為了確保修改的正確性，我們可以使用 diff 命令比較新舊設定檔的差異：
diff k8s/chaos/settings.yaml k8s/chaos/settings-failure.yaml
輸出結果顯示，除了新增的 events 部分外，其他設定保持不變。
接下來，如同之前操作，使用 kubectl 更新設定：
cat k8s/chaos/settings-failure.yaml | sed -e "s|@||g" | kubectl --namespace go-demo-8 apply --filename -
然後，我們可以透過以下指令觀察 Pod 狀態，等待 CronJob 啟動新的 Pod：
kubectl --namespace go-demo-8 get pods --selector app=go-demo-8-chaos
持續執行 kubectl get 指令，直到新的 Pod 啟動並完成實驗。實驗完成後，請檢查 Slack 訊息。如果沒有其他讀者的幹擾，您應該不會看到新的通知。這是因為實驗成功，而我們已設定 Chaos Toolkit 只在實驗失敗時傳送通知。
現在，讓我們模擬一個失敗的實驗，驗證通知機制是否正常運作。我們可以刪除應用程式的 Deployment，使實驗因無法確認應用程式健康狀態而失敗：
kubectl --namespace go-demo-8 delete deployment go-demo-8
刪除 Deployment 後，ReplicaSets 和 Pod 也會被終止。等待一段時間後，您應該會在 Slack 收到一條類別似圖 8-2 的通知，提示實驗失敗。
(Mermaid 圖表)
graph LR
D[D]
No[No]
Yes[Yes]
A[刪除 Deployment] --> B(終止 ReplicaSets)
B --> C(終止 Pods)
C --> D{實驗失敗?}
D -- Yes --> E[傳送 Slack 通知]
D -- No --> F[無通知]
從現在開始，我們只會在實驗失敗時收到通知，避免被無關緊要的成功訊息淹沒。雖然一開始看到成功的通知可能有用，但隨著時間推移，這些訊息的價值會降低，我們也容易開始忽略它們。因此，我們將 Chaos Toolkit 設定為只在實驗失敗時傳送通知，以便更有效地關注需要處理的問題。
清理環境
實驗完成後，我們可以刪除名稱空間 go-demo-8 來清理環境：
kubectl delete namespace go-demo-8
這將終止 demo 應用程式和 CronJob。如果您需要暫停實驗，也可以參考 Gist 中的說明來銷毀整個叢集。
執行隨機混沌實驗
前面我們探討瞭如何針對特定應用程式或條件執行混沌工程實驗，例如刪除應用程式例項、幹擾網路等。這些實驗雖然具有一定的隨機性，但仍然侷限於特定的應用程式或元件。
接下來，我們將進一步提升實驗的隨機性，不再侷限於特定元件，而是隨機影響不同的部分。這將為我們帶來更廣泛的洞察，幫助我們瞭解系統在面對各種隨機幹擾時的反應。為了實作這個目標，我們需要修改現有的實驗設定，使其不再侷限於單一應用程式。
