CodeZine(コードジン)

特集ページ一覧

Kubernetesクラスターのノードにカオス挿入してみよう~Azure Kubernetes Serviceでカオスエンジニアリング

クラウドネイティブ時代の実践カオスエンジニアリング 第5回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

実験の計画

 実験の計画は下記の通りです。

実験の計画
# 項目 内容
1 定常状態 HTTPリクエストのレスポンスが200である
2 仮説 一台のノードが停止しても、サービスが復旧する
3 影響範囲の限定方法 停止するノードを指定する
4 異常終了時の復旧方法 Kubernetesの機能により、Podは停止したノードとは別のノードで起動する

仮説

 仮説としては、Kubernetesの仕組みから、ノードの停止が発生後Podは別のノードで起動され、比較的すぐにアクセスできるようになると予想します。

 そのうえで、「ノードの停止をAKS側で捕捉して、新しいノードを起動してくれるのか?」といった点が確認ポイントです。

AKS上での定常状態の確認

接続確認

 まず、curlコマンドやブラウザなどから、デプロイしたアプリケーションにアクセスできることを確認します。

> curl http://20.89.82.247/

StatusCode        : 200
StatusDescription : OK
...

Podが起動しているノードの確認

 下記のコマンドを実行し、Podが起動しているノードを確認します。

> kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP           NODE                                NOMINATED NODE   READINESS GATES
azure-vote-back-6c4dd64bdf-7gh9p    1/1     Running   0          55s   10.244.2.3   aks-nodepool1-67032099-vmss000002   <none>           <none>
azure-vote-front-85b4df594d-fhhzg   1/1     Running   0          55s   10.244.2.4   aks-nodepool1-67032099-vmss000002   <none>           <none>

 上記の例では、「aks-nodepool1-67032099-vmss000002」が該当します。

VMSSおよびノード名の確認

 Azure Portal上で、VMSSの名前を確認します。

 AKSを作成すると、自動で「MC_<リソースグループ名>_<クラスター名>_<リージョン>」といった名前のリソースグループが新しく作成されます。このリソースグループにあるVMSSの名前(aks-nodepool1-67032099-vmss)を控えておきます。

VMSS名の確認
VMSS名の確認

 また、VMSSのリソース(上図では「aks-nodepool1-67032099-vmss」)をクリックし、「インスタンス」画面にて、先ほどのノード名(aks-nodepool1-67032099-vmss000002)に対応するインスタンス名(aks-nodepool1-67032099-vmss_2)を控えておきます。

VMSSのインスタンス画面
VMSSのインスタンス画面

実験の準備

 今回の実験をChaos Toolkitで実現するため、下記のような実験ファイル(experiment.json)を作成します。

experiment.json
{
  "version": "1.0.0",
  "title": "...",
  "description": "...",
  "tags": ["azure", "kubernetes", "aks", "node"],
  "configuration": {
    "azure_subscription_id": "ca8d0c58-67f6-4afe-b5b9-eaa479cdab47"
  },
  "secrets": {
    "azure": {
      "client_id": "<CLIENT_ID>",
      "client_secret": "<CLIENT_SECRET>",
      "tenant_id": "<TENAMT_ID>",
      "azure_cloud": "AZURE_PUBLIC_CLOUD"
    }
  },
  "method": [
    {
      "name": "stop-vmss",
      "type": "action",
      "provider": {
        "type": "python",
        "module": "chaosazure.vmss.actions",
        "func": "stop_vmss",
        "arguments":{
          "filter": "where name=='aks-nodepool1-67032099-vmss'",
          "instance_criteria": [ { "name": "aks-nodepool1-67032099-vmss_2"} ]
        }
      }
    }
  ],
  "rollbacks": []
}

 steady-state-hypothesisやrollbacksを記述していないのは、ノード停止後の動作やAKS側でのノード停止への対処有無を確認したいためです。

 methodにはstop_vmssを設定しています。これは、冒頭の通り執筆時点ではAKSのアクション(stop_nodeなど)が動作しないためです。

 method.provider.arguments.filterにて対象のリソースを絞ることができますが、AKSのVMSSに対してはresourceGroupで絞ろうとするとリソースが見つからなくなってしまいます。このため、resourceGroupではなくname(VMSS名)を使って絞り込むことをお勧めします。

 また、第3回の「実験の実施」に記載の修正を忘れないようにしてください。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:クラウドネイティブ時代の実践カオスエンジニアリング

著者プロフィール

  • 石崎 奏(株式会社NTTデータ)(イシザキ ソウ)

     入社以来、NTTデータグループにおけるWindows/Linuxシステムの技術問合せ、トラブルシュート支援、アーキテクチャレビューに従事。現在は、Azureを中心としたクラウド技術者の能力開発や、グループ全体へのAzure活用支援にも携わる。 Twitter...

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5