[Litmus Portal]GUIのみでカオスエンジニアリングを始めてみる
Motivation
2020/11 リリースの v1.11 にて litmus portal が beta となったので、如何に簡単に ChaosEngineering を始められるかを、Litmus Portal を中心に体験してみる。
そもそも Litmus とは、という方は別途ハンズオン含めて Litmus についてまとめた記事を用意しています。
What's Litmus Portal
Litmus Portal は、Litmus Chaos の統合ダッシュボードであり、下記のような機能を持っている。
- Chaos Experiments のカタログである ChaosHub
- プライベート Git リポジトリも扱えるローカルな ChaosHub である MyHub
- Chaos Experiments を管理、監視、実行するワークフロー管理機能
- Chaos Experiments の実行結果を、テスト通過率、Resilience Score として表示するダッシュボード
Install Litmus Portal
クラスタの構築
kind create cluster
Litmus Portal のデプロイ
❯ kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/v1.11.x/litmus-portal/cluster-k8s-manifest.yml
namespace/litmus created
configmap/litmus-portal-admin-config created
deployment.apps/litmusportal-frontend created
service/litmusportal-frontend-service created
serviceaccount/litmus-server-account created
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRole is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRole
clusterrole.rbac.authorization.k8s.io/litmus-server created
Warning: rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding is deprecated in v1.17+, unavailable in v1.22+; use rbac.authorization.k8s.io/v1 ClusterRoleBinding
clusterrolebinding.rbac.authorization.k8s.io/litmus-server-rb created
deployment.apps/litmusportal-server created
service/litmusportal-server-service created
deployment.apps/mongo created
persistentvolumeclaim/mongo-pv-claim created
service/mongo-service created
Pod の起動を確認
❯ k get po -n litmus
NAME READY STATUS RESTARTS AGE
litmusportal-frontend-f489946cd-cpn7n 1/1 Running 1 2m13s
litmusportal-server-6967dc6576-q7k2k 2/2 Running 0 2m14s
mongo-6dfb66559b-fz79k 1/1 Running 0 2m13s
Litmus Portal へのアクセス
NodePort で Litmus Portal へのアクセスを待受しているので、ブラウザからの接続確認のために port-forward を実施
❯ k port-forward -n litmus svc/litmusportal-frontend-service 9091
Forwarding from 127.0.0.1:9091 -> 8080
Forwarding from [::1]:9091 -> 8080
Handling connection for 9091
Handling connection for 9091
Kubernetes マークをフラスコに入れたひよこが出てくれば Litmus Portal が動作しています。
デフォルトのクレデンシャルは、username: admin 、 password: litmus となっています。
ログインすると、プロジェクト名やユーザ情報を聞かれるので登録します。
この時点で Pod を見ると、argo-server、chaos-operator、subscriber、workflow-controller という Pod が新たに動作していました。
❯ k get po
NAME READY STATUS RESTARTS AGE
argo-server-cd89c4579-jdc9d 1/1 Running 0 60s
chaos-operator-ce-6d5789468f-9qsk7 1/1 Running 0 60s
litmusportal-frontend-f489946cd-cpn7n 1/1 Running 1 20m
litmusportal-server-6967dc6576-q7k2k 2/2 Running 0 20m
mongo-6dfb66559b-fz79k 1/1 Running 0 20m
subscriber-5fcb6f4d84-2p44g 1/1 Running 0 59s
workflow-controller-5f8d8c5646-wr7wn 1/1 Running 0 60s
Chaos Workflow の作成と実行
諸々の情報入力を終えると、おしゃれなダッシュボードが出てきます。このダッシュボードを Litmus Portal と呼んでいて、さらに自分専用の ChaosHub である MyHub を内包しています。
画面左上の緑ボタンから、すでに定義済みの workflow を試してみます。
ChaosHub でも見られる、汎用的な Chaos Experiments が表示されます。ここでは pod-delete を選択してみます。
少し情報量が少ないですが、どのような Chaos Experiment かの概要をここで確認し、テンプレートをスケジュールすることができます。
今から作成する workflow をどの kubernetes 上で実行するかを選択できます。
ここでは、Litmus が動作する Self Cluster を選択します。
先程 pod-delete を選びましたが、workflow についてまた聞かれるようです。
試しに、create your own workflow を選択します。
litmus namespace にて、pod-delete Chaos Experiment を使用する workflow を作成していきます。
少しややこしいのが、ここで指定する namespace は workflow が作成される namespace であり、Chaos Experiments 適用先の namespace ではないことです。この次のページで後者は出てきます。
pod-delete Chaos Experiment のパラメタを設定していきます。
主に Chaos Experiments を適用したいリソースのセレクタ指定と、何秒間実施するかなどの Chaos Experiment ごとの環境変数を指定します。
Chaos Experiments を適用する先の適当な Pod として Nginx を立てておきます。
❯ k create deployment nginx --image nginx -n default
deployment.apps/nginx created
❯ k get po -n default
NAME READY STATUS RESTARTS AGE
nginx-6799fc88d8-8pzq5 1/1 Running 0 6s
ようやく半分まできました。新しい概念が多く出てくるので心が折られそうになってきます。
ここで、workflow のチューニングを行えます。
何やら Workflow リソースが定義されており、3 つのステップで構成されているので詳細をみてみます。
.spec.template は大きく 2 つの部分で構成されています。
- .spec.templates.steps: workflow にて実施するテンプレート群
- .spec.templates.container: template の実態であるコンテナ定義
templates:
- name: custom-chaos
steps:
- - name: install-chaos-experiments
template: install-chaos-experiments
- - name: pod-delete
template: pod-delete
- - name: revert-chaos
template: revert-chaos
- name: install-chaos-experiments
container:
args:
- kubectl apply -f
https://github.com/litmuschaos/chaos-charts/raw/master/charts/generic/pod-delete/experiment.yaml
-n {{workflow.parameters.adminModeNamespace}} | sleep 30
command:
- sh
- -c
image: lachlanevenson/k8s-kubectl
- name: pod-delete
inputs:
artifacts:
- name: pod-delete
path: /tmp/chaosengine-pod-delete.yaml
raw:
data: |
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: pod-delete
namespace: "{{workflow.parameters.adminModeNamespace}}"
spec:
appinfo:
appns: default
applabel: app=nginx
appkind: deployment
annotationCheck: "false"
engineState: active
chaosServiceAccount: litmus-admin
monitoring: false
jobCleanUpPolicy: delete
experiments:
- name: pod-delete
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: "30"
- name: CHAOS_INTERVAL
value: "10"
- name: FORCE
value: "false"
container:
args:
- -file=/tmp/chaosengine-pod-delete.yaml
- -saveName=/tmp/engine-name
image: litmuschaos/litmus-checker:latest
- name: revert-chaos
container:
args:
- kubectl delete chaosengines --all -n
{{workflow.parameters.adminModeNamespace}}
command:
- sh
- -c
image: lachlanevenson/k8s-kubectl
workflow にて実施するテンプレート群
.spec.template.steps 内に、いわゆるワークフローが下記の 3 つで構成されています。
- install-chaos-experiments
- pod-delete
- revert-chaos
templates:
- name: custom-chaos
steps:
- - name: install-chaos-experiments
template: install-chaos-experiments
- - name: pod-delete
template: pod-delete
- - name: revert-chaos
template: revert-chaos
template の実態であるコンテナ定義
pod-delete Chaos Experiment を github から持ってきてクラスタにデプロイする、という操作をステップ 1 のコンテナとして実行しています。
Workflow 内に任意のイメージとコマンドを使えるということになります。
ここで private なリポジトリの認証情報など必要になってくる際に、workflow をどのクラスタで実行するか、中央集中型の Chaos Engineering Server にするかという部分が効いてくるのかな、という推測ができます。
- name: install-chaos-experiments
container:
args:
- kubectl apply -f
https://github.com/litmuschaos/chaos-charts/raw/master/charts/generic/pod-delete/experiment.yaml
-n {{workflow.parameters.adminModeNamespace}} | sleep 30
command:
- sh
- -c
image: lachlanevenson/k8s-kubectl
定義した workflow を今スケジュールしてみます。
はじめての workflow を作ることができました。
Terminal からも workflow リソースが確認できます。
❯ k get workflow -A
NAMESPACE NAME STATUS AGE
litmus custom-chaos-workflow-1610421847 Running 9s
Chaos Workflow の実行結果確認
このあと、最初のダッシュボード画面に戻り、workflow が成功したかどうかを確認できます。
何回かテストで失敗させたものも含んでいますが、1 つ Succeeded となっています。
また、該当の workflow のハンバーガーメニューから、"show workflow"を見ると、workflow 内で実施している内容が可視化されて見えます。
argo などと連携して shift-left する場合は、この辺りを運用者が見て Chaos Experiment もしくはターゲットのアプリケーションを修正していく、という運用フローを推測していますが未調査です。
ポータルのホームに戻ると、test の成功率なども表示され、開発向けクラスタのテストやプロダクションクラスタにて失敗するようになったテストがないかを確認できて便利そうです。
"Resilience Score"という数値(たぶんテストのパス率と同義)が時系列のグラフで表示され、SLO の指標としても検討できそうです。
まとめ
Litmus Chaos の統合ダッシュボードである Litmus Portal の１部分である chaos workflow の実行を試した。
既に YAML を書かずに、カオスエンジニアリングを試せる状態まで Litmus Chaos が進んでいることがわかった。
ChaosHub による Chaos Experiments を広く共有できる強みに加え、ワークフロー定義を基に開発のライフサイクルに付け加えてぽちぽちで運用を始められる手軽さが Litmus Chaos の強みに見える。
Litmus Portal はまだ途上であり、workflow の edit 機能がないなどプロダクションで担ぐというよりは、開発環境のテスト向けに試行を初めてみるくらいの温度感が良さそうに見える。
コミュニティによると、workflow の edit 機能も 2021/1 月 3 週目に予定されている 1.12.1 のリリースにて追加される見込み。
実際に実行した Chaos Experiment の結果詳細や、個人的に注目の機能である MyHub を別途まとめようと思う。
余談: Argo 側での見え方
下記のポートフォワードを行い、ブラウザで localhost:2746 にアクセスすると argo が表示される。
❯ k port-forward -n litmus svc/argo-server 2746
Forwarding from 127.0.0.1:2746 -> 2746
Forwarding from [::1]:2746 -> 2746
先ほど、litmus portal 上で作成した workflow が argo の workflow として管理できていることを確認できる。
argo 側で、この workflow を resubmit することで、下記のように再実行されることも確認できる。
どちらでも見れてすごい、という気持ちになりそうになるが、そもそもの Litmus における workflow リソースをよくよく見ると argo の CRD を用いていることがわかる。
そのため、どちらでも見れるのは、Litmus Portal が argo の Workflow リソースを表示してくれる機能を持っていると言い換えることができる。
かなり argo に依存する機能になる？ようにも見えるので、今後の方向性を引き続きウォッチしてみる。
❯ k get workflow custom-chaos-workflow-1610421847 -oyaml | head -n2
apiVersion: argoproj.io/v1alpha1
kind: Workflow
Discussion