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
790
ステートフルPodのマルチAZ化のために行ったこと
PodのAZ間分散方法、VictoriaMetricsのvmstorageをEFSでマルチAZ化した取り組みについてご紹介いたします。
nutslove
March 23, 2022
Tweet
Share
More Decks by nutslove
See All by nutslove
OpenTelemetryによるベンダーニュートラルな監視設定
nutslove
4
380
Grafana Lokiで始めるPodログ/k8s Events管理
nutslove
0
1.8k
Grafana Lokiで始めるログ管理
nutslove
6
7.5k
Istio入門
nutslove
17
7.8k
AMP, AMG, X-Ray等、AWSマネージドサービスを活用した監視環境構築
nutslove
2
1.1k
Other Decks in Technology
See All in Technology
Can We Measure Developer Productivity?
ewolff
1
150
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
250
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.8k
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
190
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
2
430
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
380
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
7
820
[FOSS4G 2024 Japan LT] LLMを使ってGISデータ解析を自動化したい!
nssv
1
210
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
Embracing the Ebb and Flow
colly
84
4.5k
Done Done
chrislema
181
16k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Become a Pro
speakerdeck
PRO
25
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
ご清聴ありがとうございました。