Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ステートフルPodのマルチAZ化のために行ったこと
Search
nutslove
March 23, 2022
Technology
2
940
ステートフルPodのマルチAZ化のために行ったこと
PodのAZ間分散方法、VictoriaMetricsのvmstorageをEFSでマルチAZ化した取り組みについてご紹介いたします。
nutslove
March 23, 2022
Tweet
Share
More Decks by nutslove
See All by nutslove
MCP入門
nutslove
2
110
GitOpsで始めるクラウドリソース管理
nutslove
1
88
Thanos入門(Receiver構成)
nutslove
0
50
OpenTelemetryによるベンダーニュートラルな監視設定
nutslove
5
460
Grafana Lokiで始めるPodログ/k8s Events管理
nutslove
0
2.3k
Grafana Lokiで始めるログ管理
nutslove
7
9.8k
Istio入門
nutslove
18
8.2k
AMP, AMG, X-Ray等、AWSマネージドサービスを活用した監視環境構築
nutslove
2
1.3k
Other Decks in Technology
See All in Technology
菸酒生在 LINE Taiwan 的後端雙刀流
line_developers_tw
PRO
0
910
初めてのAzure FunctionsをClaude Codeで作ってみた / My first Azure Functions using Claude Code
hideakiaoyagi
1
160
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
1
160
白金鉱業Meetup_Vol.19_PoCはデモで語れ!顧客の本音とインサイトを引き出すソリューション構築
brainpadpr
2
450
QAはソフトウェアエンジニアリングを学んで実践するのが大事なの
ymty
1
490
Amazon Q Developer for GitHubとAmplify Hosting でサクッとデジタル名刺を作ってみた
kmiya84377
0
3.5k
ハノーバーメッセ2025座談会.pdf
iotcomjpadmin
0
130
AWS全冠したので振りかえってみる
tajimon
0
150
2025/6/21 日本学術会議公開シンポジウム発表資料
keisuke198619
2
450
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
120
ObsidianをMCP連携させてみる
ttnyt8701
2
140
~宇宙最速~2025年AWS Summit レポート
satodesu
1
490
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Balancing Empowerment & Direction
lara
1
320
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Being A Developer After 40
akosma
90
590k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Navigating Team Friction
lara
187
15k
GraphQLとの向き合い方2022年版
quramy
46
14k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Practical Orchestrator
shlominoach
188
11k
Transcript
2 0 2 2 年 3 月 2 3 日
李 俊 起 ステートフルPodの マルチAZ化のために行ったこと
自己紹介 い じゅんぎ 李 俊起 ・ KDDI株式会社/SRE ・ 運用自動化、運用共通機能提供 ・
監視基盤をEKS上に構築するために奮闘中
本日のアジェンダ ・ VictoriaMetricsについて ・ マルチAZ構成のために試したこと (Podのスケジューリング設定について) ・ まとめ
VictoriaMetricsとは ・ Prometheusメトリクスデータの長期保存/冗長化ツール ・ 書き込み、読み込み、データ保存等、機能ごとに コンポーネントが分かれているDistributed System
VictoriaMetricsのアーキテクチャ ・vminsert PrometheusのRemoteWrite APIを通じて メトリクスを各vmstorageに分散して格納する ・vmstorage Prometheusのデータが保存される領域 複数のvmstorageにデータを分割して格納 ≒RAID0(ストライピング) ・vmselect
Grafana等よりPromQLを受け付けて 各vmstorageからデータを集計しマージする この部分をマルチAZ化したい ≒ PodをAZごとに分散させる
ワーカーノードをAZごとに配置して、Podを 各ワーカーノードにデプロイすればいいじゃん
Podのスケジューリング(配置)設定 ・ nodeSelector ・ node (Anti-)Affinity ・ Inter-pod (Anti-)Affinity ・
TopologySpreadConstraints
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
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
Inter-pod (Anti-)Affinity ・ podの配置状態を見てpodを配置するnodeを決定 ・ podを分散する事ができる ・ 1つの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をスケジューリングする
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
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
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
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状態になる)
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がスケジューリングされる
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)は1なのでAZ-aとAZ-cのどちらか のnodeにPodがスケジューリングされる app=nginx Pod
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)が2になってしまうため、 AZ-c上のnodeにPodがスケジューリングされる
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)は1なのでAZ-aとAZ-cのどちらか のnodeにPodがスケジューリングされる
これでマルチAZ化対応完了? ・vmstorage Prometheusのデータが保存される領域 複数のvmstorageにデータを分割して格納 ≒RAID0(ストライピング) ※再掲 StatefulSet + EBSや TopologySpreadConstraints
等でAZを固定するとAZ障害で 片方のAZがダウンした時、 不完全なデータになる。
・データ保存をマルチAZで使用可能な EFSにすることで、 AZを固定せず Deploymentでのデプロイが可能 ・1つのAZ(ワーカーノード)にPodが 集中する可能性はあるが、AZ障害時 に生きているAZ(ワーカーノード)で 新しいPodがEFSがマウントされた 状態で作成され、完全なデータで 継続的に監視ができる
EKSクラスター AZ-a AZ-c POD Service(ELB) Service(ELB) Deployment POD EFS POD POD Deployment Deployment / EFSで解決
まとめ ・ ステートフルなPodのマルチAZ化には考慮が必要 ・ ステートレスなPodも負荷分散やダウンタイムが生じないよう、 TopologySpreadConstraints等で均等に分散 ※Podスケジューリングの詳細については以下で検索 Assigning Pods to
Nodes | Kubernetes
ご清聴ありがとうございました。