ターゲットへのアクセス許可設定
実験作成後、VMSSに対する実験の場合と同様、ターゲットリソース（AKS）に対する実験のアクセス許可を付与します。
手順については、公式ドキュメントを参照ください。
ただし、アクセス許可先のメンバーを選択する際はデフォルトの「ユーザー、グループ、またはサービス プリンシパル」ではなく「マネージド ID」を指定して、対象の実験を選択します。
実験の実行
以上で実験を実行する準備が整いました。
それでは、いよいよ実験を開始してみましょう。［実験］ビューで実行したい実験をクリックし、［開始］、［OK］の順にクリックします。
実験結果の確認
今回の実験では3つあるフロントエンドのPodの1つを利用不可としたので、Podの状態遷移を確認します。
なお、事前に「kubectl get pods -w」などでPodの状態遷移を確認できるようにしておくことをお勧めします。
$ kubectl get pods -w NAME READY STATUS RESTARTS AGE azure-vote-back-59cb7dc555-sxzwg 1/1 Running 0 13h azure-vote-front-5f4d7db9c8-9bt8r 1/1 Running 0 13h azure-vote-front-5f4d7db9c8-fw8ff 1/1 Running 0 48s azure-vote-front-5f4d7db9c8-j92fp 1/1 Running 0 137m azure-vote-front-5f4d7db9c8-9bt8r 1/1 Running 0 13h azure-vote-front-5f4d7db9c8-9bt8r 1/1 Running 1 (1s ago) 13h azure-vote-front-5f4d7db9c8-9bt8r 1/1 Running 1 (9m30s ago) 13h azure-vote-front-5f4d7db9c8-9bt8r 1/1 Running 2 (1s ago) 13h
実験の実行により、azure-vote-front-5f4d7db9c8-9bt8rという名前のPodが利用不可の状態となり、異常終了した後に2回再起動されたことが分かります。
続いて、可用性テストの結果を確認します。
図中の「可用性の結果」のバーはHTTPリクエストの成否を示しています。
HTTP リクエストが1件失敗したものの、それ以外のHTTPリクエストは成功しており、「正常性判断の定義」の範囲だったことが確認できます。
また、図中の緑の点で示す散布図はレスポンスタイムを示しており、縦軸がレスポンスタイム（ms）、横軸が時間を示しています。
実験中はレスポンスタイムが遅くなるものの、こちらも「正常性判断の定義」の範囲だったことが確認できます。
当然ながら、今回の実験ではアラート通知は発生しなかったため、実験対象システムは今回の実験による障害に対して耐えることができるという結果が得られました。
まとめ
以上の通り、AKSに対してAzure Chaos Studioを利用したカオスエンジニアリング実験を実施することができました。
AKSに対する実験では、Chaos Meshの仕組みを利用します。本記事の例のようなPodの利用不可だけではなく、さまざまな障害を注入することができますので、改めて公式ドキュメントやChaos Meshのマニュアルも参考にしていただき、色々と実験を試してみていただけると嬉しいです。是非、一緒にAzure Chaos Studioを使いこなしていきましょう！
