ステートフルPodのマルチAZ化のために行ったこと

PodのAZ間分散方法、VictoriaMetricsのvmstorageをEFSでマルチAZ化した取り組みについてご紹介いたします。

1. 2 0 2 2 年 3 月 2 3 日 李 俊 起 ステートフルPodの マルチAZ化のために行ったこと
2. 自己紹介 い じゅんぎ 李 俊起 ・ KDDI株式会社/SRE ・ 運用自動化、運用共通機能提供 ・ 監視基盤をEKS上に構築するために奮闘中
3. 本日のアジェンダ ・ VictoriaMetｒicsについて ・ マルチAZ構成のために試したこと （Podのスケジューリング設定について） ・ まとめ
4. VictoriaMetｒicsとは ・ Prometheusメトリクスデータの長期保存/冗長化ツール ・ 書き込み、読み込み、データ保存等、機能ごとに コンポーネントが分かれているDistributed System
5. VictoriaMetricsのアーキテクチャ ・vminsert PrometheusのRemoteWrite APIを通じて メトリクスを各vmstorageに分散して格納する ・vmstorage Prometheusのデータが保存される領域 複数のvmstorageにデータを分割して格納 ≒RAID0(ストライピング) ・vmselect Grafana等よりPromQLを受け付けて 各vmstorageからデータを集計しマージする この部分をマルチAZ化したい ≒ PodをAZごとに分散させる
6. ワーカーノードをAZごとに配置して、Podを 各ワーカーノードにデプロイすればいいじゃん
7. Podのスケジューリング(配置)設定 ・ nodeSelector ・ node (Anti-)Affinity ・ Inter-pod (Anti-)Affinity ・ TopologySpreadConstraints
8. nodeSelector ・ nodeのラベルでpodを配置するnodeを選ぶ最もシンプルな方法 ・ 複雑な条件文は指定できない ・ podを分散する事はできない ※built-in node labels Well-Known Labels, Annotations and Taints | Kubernetes apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx nodeSelector: topology.kubernetes.io/zone: ap-northeast-1c
9. node (Anti-)Affinity ・ nodeのラベルでpodを配置するnodeを指定(除外)する 考え方はnodeSeletorと一緒 ・ 複雑な条件文が書ける ・ podを分散する事はできない apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - ap-northeast-1a
10. Inter-pod (Anti-)Affinity ・ podの配置状態を見てpodを配置するnodeを決定 ・ podを分散する事ができる ・ １つのnode上に2つ以上 同一podを配置できない (podAntiAffinityの場合) apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone 「labelSelector」のPodがある(ない) 「topologyKey」ドメイン(region,AZ等)の node上にpodをスケジューリングする
11. Inter-pod Anti-Affinityの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node
12. Inter-pod Anti-Affinityの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod 1つ目のpodはapp=nginxラベルを持つPodが まだ存在しないため、AZ-aとAZ-cのどちらか のnodeにPodがスケジューリングされる app=nginx Pod
13. Inter-pod Anti-Affinityの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod app=nginx Pod 2つ目のpodはAZ-aのnode上にすでに app=nginxラベルを持つPodが存在するため、 AZ-c上のnodeにPodがスケジューリングされる app=nginx Pod
14. Inter-pod Anti-Affinityの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod app=nginx Pod app=nginx Pod すでに各AZ上にPodが存在していて、 3つ目のPodはスケジューリングされない （Pending状態になる）
15. TopologySpreadConstraints ・ ドメイン(region,AZ等)間のPodの偏り(maxSkew)で podを配置するnodeを決定 ・ 最も柔軟な設定が可能 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: nginx 「topologyKey」に指定したドメイン間の pod数の差異を「maxSkew」 で指定した 数まで許容し、それを超えないように Podがスケジューリングされる
16. TopologySpreadConstraintsの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: nginx EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod 1つ目のpodはどこに配置されてもAZ間のPod数の 差異(maxSkew)は１なのでAZ-aとAZ-cのどちらか のnodeにPodがスケジューリングされる app=nginx Pod
17. TopologySpreadConstraintsの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: nginx EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod app=nginx Pod app=nginx Pod 2つ目のpodはAZ-a上に配置されたらAZ間のPod数 の差異(maxSkew)が２になってしまうため、 AZ-c上のnodeにPodがスケジューリングされる
18. TopologySpreadConstraintsの例 apiVersion: apps/v1 kind: Deployment ・ ・ spec: replicas: 3 ・ ・ template: metadata: labels: app: nginx spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: nginx EKS Cluster VPC Worker Node AZ-a subnet AZ-c subnet Worker Node app=nginx Pod app=nginx Pod app=nginx Pod app=nginx Pod 3つ目のpodもどこに配置されてもAZ間のPod数の 差異(maxSkew)は１なのでAZ-aとAZ-cのどちらか のnodeにPodがスケジューリングされる
19. これでマルチAZ化対応完了？ ・vmstorage Prometheusのデータが保存される領域 複数のvmstorageにデータを分割して格納 ≒RAID0(ストライピング) ※再掲 StatefulSet + EBSや TopologySpreadConstraints 等でAZを固定するとAZ障害で 片方のAZがダウンした時、 不完全なデータになる。
20. ・データ保存をマルチAZで使用可能な EFSにすることで、 AZを固定せず Deploymentでのデプロイが可能 ・１つのAZ(ワーカーノード)にPodが 集中する可能性はあるが、AZ障害時 に生きているAZ(ワーカーノード)で 新しいPodがEFSがマウントされた 状態で作成され、完全なデータで 継続的に監視ができる EKSクラスター AZ-a AZ-c POD Service(ELB) Service(ELB) Deployment POD EFS POD POD Deployment Deployment / EFSで解決
21. まとめ ・ ステートフルなPodのマルチAZ化には考慮が必要 ・ ステートレスなPodも負荷分散やダウンタイムが生じないよう、 TopologySpreadConstraints等で均等に分散 ※Podスケジューリングの詳細については以下で検索 Assigning Pods to Nodes | Kubernetes
22. ご清聴ありがとうございました。