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
910
ステートフル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
73
GitOpsで始めるクラウドリソース管理
nutslove
1
73
Thanos入門(Receiver構成)
nutslove
0
39
OpenTelemetryによるベンダーニュートラルな監視設定
nutslove
5
440
Grafana Lokiで始めるPodログ/k8s Events管理
nutslove
0
2.2k
Grafana Lokiで始めるログ管理
nutslove
7
9.4k
Istio入門
nutslove
18
8.1k
AMP, AMG, X-Ray等、AWSマネージドサービスを活用した監視環境構築
nutslove
2
1.2k
Other Decks in Technology
See All in Technology
問 1:以下のコンパイラを証明せよ(予告編) #kernelvm / Kernel VM Study Kansai 11th
ytaka23
3
410
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
1.9k
AWSを利用する上で知っておきたい名前解決の話
nagisa53
6
770
社内 Web システムのフロントエンド技術刷新: React Router v7 vs. TanStack Router
musasabibyun
0
110
AndroidアプリエンジニアもMCPを触ろう
kgmyshin
2
630
大規模サーバーレスプロジェクトのリアルな零れ話
maimyyym
3
190
Dataverseの検索列について
miyakemito
1
180
OPENLOGI Company Profile
hr01
0
63k
Databricksで完全履修!オールインワンレイクハウスは実在した!
akuwano
0
150
LLMの開発と社会実装の今と未来 / AI Builders' Community (ABC) vol.2
pfn
PRO
1
110
Azure Maps Visual in PowerBIで分析しよう
nakasho
0
210
2025-04-14 Data & Analytics 井戸端会議 Multi tenant log platform with Iceberg
kamijin_fanta
1
180
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
33k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
780
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
A designer walks into a library…
pauljervisheath
205
24k
Music & Morning Musume
bryan
47
6.5k
The Cost Of JavaScript in 2023
addyosmani
49
7.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building an army of robots
kneath
305
45k
Fireside Chat
paigeccino
37
3.4k
Facilitating Awesome Meetings
lara
54
6.3k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Building Adaptive Systems
keathley
41
2.5k
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
ご清聴ありがとうございました。