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
Kubernetes こわくないよ!
Search
saiya_moebius
September 09, 2019
Technology
1
5.7k
Kubernetes こわくないよ!
Kubernetes を気負わずに導入した話 + ちょっとしたハマりごとエピソードです。
#m3k8s
https://m3-engineer.connpass.com/event/143295/
saiya_moebius
September 09, 2019
Tweet
Share
More Decks by saiya_moebius
See All by saiya_moebius
async 完全理解 - 全ての async は Promise に通ず / Guide to async, await
saiya_moebius
1
520
エムスリーの Over 300 マイクロサービスを支えるマルチクラウドのネットワーク設計 / M3 cloud network infrastructure for over 1000 microservices
saiya_moebius
0
320
TypeScript の型システム / Type system of the TypeScript
saiya_moebius
10
3.2k
垂直スケールの果ての db.r4.16xlarge で得た教訓 / What happened on vertically scaled 16xlarge DB
saiya_moebius
4
4k
DNS を 15 分で雑に知る / grasp DNS in 15 minutes
saiya_moebius
0
140
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study
saiya_moebius
10
6.6k
RDBMS in Action
saiya_moebius
56
25k
Compiler/JIT optimizations & escape analysis
saiya_moebius
2
400
How to setup Gradle to improve legacy Java system
saiya_moebius
1
2.7k
Other Decks in Technology
See All in Technology
4/16/25 - SFJug - Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
1
100
AI Agentを「期待通り」に動かすために:設計アプローチの模索と現在地
kworkdev
PRO
2
440
SREからゼロイチプロダクト開発へ ー越境する打席の立ち方と期待への応え方ー / Product Engineering Night #8
itkq
2
670
Spring Bootで実装とインフラをこれでもかと分離するための試み
shintanimoto
7
810
AI AgentOps LT大会(2025/04/16) Algomatic伊藤発表資料
kosukeito
0
140
バックオフィス向け toB SaaS バクラクにおけるレコメンド技術活用 / recommender-systems-in-layerx-bakuraku
yuya4
6
530
LangfuseでAIエージェントの 可観測性を高めよう!/Enhancing AI Agent Observability with Langfuse!
jnymyk
1
220
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
460
IVRyにおけるNLP活用と NLP2025の関連論文紹介
keisukeosone
0
200
日経電子版 for Android の技術的課題と取り組み(令和最新版)/android-20250423
nikkei_engineer_recruiting
0
250
Would you THINK such a demonstration interesting ?
shumpei3
1
220
Devinで模索する AIファースト開発〜ゼロベースから始めるDevOpsの進化〜
potix2
PRO
7
3.3k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
Site-Speed That Sticks
csswizardry
5
490
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.6k
Designing for humans not robots
tammielis
252
25k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
4 Signs Your Business is Dying
shpigford
183
22k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
670
A better future with KSS
kneath
239
17k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Transcript
Kubernetes こわくないよ! + Appendix: 実際あった しくじりエピソード web エンジニアが使う⾝近な k8s -
September 2019 Seiya Yazaki 1
Who? ⽮崎 聖也 @saiya_moebius エムスリー株式会社 CTO サーバーサイドを中⼼としつつ⾊々やってきたエンジニア Java, Kotlin, Rails
等 (⾔語として好きなのは C#) 最近主に書いているのは TypeScript, terraform クラウドでは AWS 経験が多かったが、最近は GCP も増えてきている こんなスライド書いていたり: Web アプリをとりあえず Kubernetes にデプロイするための知識 Spring Boot と⼀般ライブラリの折り合いのつけかた いまどきのコンパイラ・JIT の最適化と Escape Analysis 2
おことわり このスライドは、 Kubernetes こわくないよ! というゆるーい話です。 AWS ECS や GKE 等の存在を知っている前提で書いています
Kubernetes の具体的な使い⽅には踏み込みません 公式ドキュメントを⾒てもらうなり、実際に触ってもらうほうが速い Kubernetes のディープな話ではないです CRD (Custom Resource Definition) の実装とか⾒ていると⾯⽩いですが 3
Kuberntes の使う前のイメージ kubernetes-failure-stories Kubernetes is a fairly complex system with
many moving parts. apiVersion: apps/v1beta1 等をよく⾒るが、 beta って... 内部コンポーネント多すぎ感 Kubernetes The Hard Way をやれば分かるというが... コンテナ基盤にパワーを割ける組織・プロジェクトならともかく、 web サービス開発の⽚⼿間でやるなら AWS ECS 辺りがいいのでは、というイメージだっ た。 4
M3 US ⽀社のリニューアル案件にて 筆者が基盤整備したプロジェクトにて、 最初のプロトタイプは⼿慣れた AWS ECS で構築し 本実装は GKE
で実装した 弊社の既存サービスでは AWS ECS 利⽤が多く、 ⼿慣れた ECS で建てるのが最速・安定の選択肢ではあった。 しかし、GCP 使っていこうぜ!というチーム内の声もあり、最終形では GKE に。 5
なぜ GKE ? Firebase を使う都合で GCP に寄せたかったのもあるが、 それ以外にも GKE にして
良くなること/なったこと が⾊々あった: Managed な Kubenetes (GKE) の良さがあった デプロイが楽になった クラスタのスケーリングがやりやすくなった クラウドベンダー依存を軽減できた 周辺ツールの発展やノウハウの可搬性を期待できる 以下、それぞれについて話します。 6
Managed な Kubernetes の良さ Kubernetes = 構築や運⽤が⼤変 というイメージがあったが、 運⽤性は ECS
とさほど変わらなかった: 各種 k8s コンポーネントのログは Stackdriver Logs で⾒える Node に SSH ログインして⾊々することも普通に可能 gcloud beta compute ssh --tunnel-through-iap がオススメ GKE であれば、セットアップは ECS よりずっとラク。 K8s 基盤に何を使うか(GKE, AWS EKS, オンプレ k8s, ...)次第で 構築や運⽤の⼿間・特性が異なるので、世の中の体験記を⾒る際には留意が必要。 7
デプロイが楽に K8s になることで、アプリケーションのデプロイがシンプル・⾃然な形になった。 ECS の頃は... デプロイ時の task definition JSON の⽣成が⾯倒
IAM Role などのインフラ由来の情報と、docker image の tag といったアプリ由来 の情報が混在 Load Balancer や SSM secret といった ECS の外のリソースの扱いが厄介 アプリを CI で deploy するだけなのに terraform も実⾏する必要あったり K8s になることで... web アプリを作る・改修する際には k8s の yaml をいじるだけで良くなった ネットワークやクラスタ⾃体はめったにいじらないので、普段は k8s の yaml をい じるだけで良い Ingress (LB) や Secret も k8s の yaml で⼀貫して管理できる 8
クラスタのスケーリングがやりやすく Cluster Autoscaler がとても便利。最⼤・最⼩台数を指定するだけで良い。 「Node 不⾜で実⾏待ちの Pod がいれば Node を増やす」というだけのルールが
(凝ったことをしなければ) ⼗分便利に機能する。 なので絶妙なチューニングなどをしなくても、適切な Node 台数に⾃然となる。 9
クラウドベンダー依存の軽減 3 ⼤クラウド(GCP, AWS, Azure)が managed service を提供している点が⼤きい。 もちろん DB
等の都合もあるため完全なクラウドベンダー⾮依存は不可能だが、 使いたい DB 等があるクラウドに移るという考え⽅をしやすくなった。 利⽤技術が定まっていないプロジェクト初期から CI 周りを作り込んでも、 k8s を対象にしていれば無駄になりにくい、というメリットも。 ( 冒頭で紹介した US 事例では、ECS 向けに整備した CI を捨てて k8s 向けに再整備しまし た... ) 10
周辺ツールの発展やノウハウの可搬性 K8s は今後のインフラの共通 API となりつつある Istio, Spinnaker, Knative などは k8s
がメインターゲット or 必要条件 K8s の CRD (Custom Resource Definition) として提供されるツールも GCP Config Connector とか K8s が広まったことで、ノウハウのポータビリィが上がってきている 個⼈として k8s を学習するメリットが⾼い K8s 学習者が増えると、チーム・企業の k8s の導⼊障壁が下がる 導⼊が増えることで k8s 学習のメリットが⾼まり...以下ループ 11
Kubernetes 使ってみたくなってきたところで ⾃分のスライドのステマ → Web アプリをとりあえず Kubernetes にデプロイするための知識 12
Appendix: 実際あった しくじりエピソード 本番リリース直前に Node が減った...!? 事件はオフィスで起きてるんじゃない! k8s クラスタで起きてるんだ! GKE
固有の話になってしまいますが、ご笑覧いただければ。 GKE 詳しい勢は途中でタネを察してしまうかもしれませんが黙っていてね! ...以下、時間軸順... 13
平和な dev 環境クラスタだった terraform で google_container_cluster , google_container_node_pool をセットアッ プした。
特に凝ったことはしていない。 そして、dev 環境での開発も意外にすんなり進み始めた... 伏線: GKE の master の version up 中は何も操作できなかったが、それは普通の仕様だと思っ ていた。 14
本番リリース直前に ある⽇⾒たら node 数不⾜で pod が起動できていない: GKE master の zone
と同じ zone の VM は node として認識されている Master と異なる zone にある VM は node として認識されていない とりあえず cluster の node 数(VM 総数)を増やすことで回避したが... 単⼀ zone にしか node がないので、冗⻑性皆無 & SLA 保証外 他の zone の VM も課⾦はされているので、盛⼤に無駄なコスト これはアカン 15
調べてみると 問題のノードでは kube-proxy が起動に失敗している。 ログをもとに絞り込んだところ、VM ⾃⾝の IP アドレスをインスタンスメタデータから取得す る処理で失敗しているようだ。 ソースコードも⾒てみたが、当該部分の処理の実体(GKE固有)は⾮
OSS だった。 なぜ失敗するのかさっぱりわからず。 もはや何もわからないので、GCP のサポートケースを起票。 「そちらの作りが何か悪いのでは?」などなどの問答が発⽣... 16
このまま本番には出せないよね... 幸い US の開発チームは夜 (JST) に開発している。 昼 (JST) に cluster,
node pool を消しては作り直しで試⾏錯誤: GKE / k8s バージョンを過去のものに戻す いろいろなバージョンを⼆分探索する 過去の terraform 設定に戻して⼆分探索する Node の OS 変えてみる ⼿当り次第⾊々オプションを変えてみる だがことごとく発症...!! 発症のトリガーすら分からず。 1 回のクラスタ作り直しに 45 min 程度かかるので無限に時間を⾷う...!! 17
そんなある⽇ 「(問題の事象⾃体はよくわからないけど) zonal cluster より regional cluster の⽅が推奨だよ」 by サポート
リージョン クラスタを作成することで、クラスタの可⽤性と復元⼒を向上させることが できます。 と公式ページにも書いてあるぞ! by サポート えっ、なんの話をしてるんだ...? 18
設定項⽬⾒落とし インフラやミドルウエアのデフォルト値含めてすべての設定値は⼀通り最終チェックするのが 信条の筆者だったが...。 まさかの regional cluster 設定の存在を完全に忘れていた。 ( regional cluster:
cluster の master を複数 zone に冗⻑化する構成 ) サポートありがとう。 19
真の敗因 location = "us-west1" この terraform 記述( Optional )を冗⻑だと思って削ったのが敗因。 よく⾒ると
zone (terraform デフォルト)ではなく region を指定しているのがポイント。 このように明⽰しないと zonal cluster になるので、この記述は消してはいけない。 20
俺たちの戦いは始まったばかりだ! というわけで regional cluster にしたところ問題事象が解消したのであった。 ちなみに master update 中も kubectl
操作できるようになった。 Zonal cluster はやめよう。 21
Enjoy Kubernetes! エムスリーではエンジニア・SRE・チーム内 SRE などを募集しております! ※ チーム内 SRE = プロダクトの仕様や実装にも介⼊しつつ⾜回りをやるロール
もしご興味あれば、ぜひその旨アンケートにご記⼊ください! ⽇経平均株価に⼊った翌週に急に SQL Injection とかのアクセスが来てびっくり 22