AKSでアプリを安全に稼働させるために考えたこと

オーバービュー

マルチテナントなkubernetes上で障害が起きてもメンテナンスのときでも落ちないようにするためには何が必要なのか考えてみた。

考える必要があるレイヤー

コントロールプレーン
ノードプール
Pod

それぞれ障害対策とメンテナンス対策が必要になる

コントロールプレーンのメンテナンス

コントロールプレーンのバージョンアップ
- クラスタのblue/greenデプロイ
- in-placeアップグレード
- インプレースアップグレードは問題が起きたら戻せないので採用しない
AzureDiskやEBS等のストレージを利用している場合はクラスタスワップできないので使わせないのが○
- どうしてもという場合は別の計画停止してもよいクラスタに隔離する
- Veleroを使って対象のPV/PVCだけGitOpsの管理外でコピーする
ストレージ使いたい場合はRWX対応のストレージを使わせるのが○
切り替え先クラスタ上で少ない手順でアプリを構築できる必要がある
- GitOpsの導入は不可欠
- StorageClassを使う場合はVeleroを使って対象のPV/PVCだけGitOpsの管理外でコピーするのが○
切り替え方式
1. アプリケーションゲートウェイ等を外部に置き、バックエンドプールにingressのIPを設定する
2. DNSで切り替える

NodePoolのメンテナンス

AKSにおいてNodeの管理はNodePoolを使って行われる。
AKSのNodeはシステムノードプールとユーザーノードプールがある
デフォルトではシステムノードプールのみ存在する。
ユーザーノードプールを追加し、テイントをつけたシステムノードプールを作成するのが○
- CriticalAddonsOnly=true:NoSchedule をつける
アプリ側にはPodDisruptionBadgetを忘れずに設定させる
- まとめてEvictionになる数を制限できる
アップグレード
- –max-surgeオプション=33%としておくとノードプールの1/3ずつアップグレードしていってくれるらしい
- ドレイン操作と新規Node追加、旧Nodeの削除をまとめてやってくれるらしいので便利。
ドレイン
- NodePoolを削除すると勝手にドレインされる。
- アプリ側にはSIGTERMシグナルを受けてgracefulにコンテナが落ちるようにしてもらう必要がある

Podのメンテナンス

kubernetesの領分なので気にする必要はなさそう。
DeploymentのUpdateStrategy等を気にしておけば○

コントロールプレーンの対障害性

リージョン障害
- バックアップクラスタを別リージョンに構築。
- メンテナンスの時の切り替え先クラスタをバックアップクラスタとして利用するのも○
AZ障害
- az aks create時に–uptime-slaオプションをつけるとゾーン冗長になるらしい

NodePoolの対障害性

リージョン障害
- バックアップクラスタで対応
AZ障害
- NodePool起動時にZoneを指定可能

Podの対障害性

レプリカ数を増やす
Statelessな作りにする
- SessionをRedisに保存する等
- AzureDisk等のRWOなストレージは使用しない

コメントを残すコメントをキャンセル