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
120
GitOpsで始めるクラウドリソース管理
nutslove
1
93
Thanos入門(Receiver構成)
nutslove
0
51
OpenTelemetryによるベンダーニュートラルな監視設定
nutslove
5
460
Grafana Lokiで始めるPodログ/k8s Events管理
nutslove
0
2.3k
Grafana Lokiで始めるログ管理
nutslove
7
9.9k
Istio入門
nutslove
18
8.3k
AMP, AMG, X-Ray等、AWSマネージドサービスを活用した監視環境構築
nutslove
2
1.3k
Other Decks in Technology
See All in Technology
データグループにおけるフロントエンド開発
lycorptech_jp
PRO
1
110
Operating Operator
shhnjk
1
590
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
2
16k
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
1
190
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
210
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
110
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
370
American airlines ®️ USA Contact Numbers: Complete 2025 Support Guide
airhelpsupport
0
390
freeeのアクセシビリティの現在地 / freee's Current Position on Accessibility
ymrl
2
200
面倒な作業はAIにおまかせ。Flutter開発をスマートに効率化
ruideengineer
0
260
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
9.4k
ビギナーであり続ける/beginning
ikuodanaka
3
760
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Music & Morning Musume
bryan
46
6.6k
Designing Experiences People Love
moore
142
24k
For a Future-Friendly Web
brad_frost
179
9.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Gamification - CAS2011
davidbonilla
81
5.4k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
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
ご清聴ありがとうございました。