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.8k
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
550
エムスリーの Over 300 マイクロサービスを支えるマルチクラウドのネットワーク設計 / M3 cloud network infrastructure for over 1000 microservices
saiya_moebius
0
350
TypeScript の型システム / Type system of the TypeScript
saiya_moebius
10
3.3k
垂直スケールの果ての db.r4.16xlarge で得た教訓 / What happened on vertically scaled 16xlarge DB
saiya_moebius
4
4.1k
DNS を 15 分で雑に知る / grasp DNS in 15 minutes
saiya_moebius
0
150
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study
saiya_moebius
10
6.7k
RDBMS in Action
saiya_moebius
56
26k
Compiler/JIT optimizations & escape analysis
saiya_moebius
2
440
How to setup Gradle to improve legacy Java system
saiya_moebius
1
2.8k
Other Decks in Technology
See All in Technology
AIでテストプロセス自動化に挑戦する
sakatakazunori
1
640
本当にわかりやすいAIエージェント入門
segavvy
9
5.2k
Maintainer Meetupで「生の声」を聞く ~講演だけじゃないKubeCon
logica0419
0
140
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
6
930
P2P通信の標準化 WebRTCを知ろう
faithandbrave
6
2k
claude codeでPrompt Engineering
iori0311
0
290
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
7k
LIXIL基幹システム刷新に立ち向かう技術的アプローチについて
tsukuha
1
1k
エンジニアリングマネージャー“お悩み相談”パネルセッション
ar_tama
1
550
An introduction to Claude Code SDK
choplin
3
3.1k
Talk to Someone At Delta Airlines™️ USA Contact Numbers
travelcarecenter
0
170
分散トレーシングによる コネクティッドカーのデータ処理見える化の試み
thatsdone
0
130
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Producing Creativity
orderedlist
PRO
346
40k
Designing for humans not robots
tammielis
253
25k
The Language of Interfaces
destraynor
158
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.3k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
Become a Pro
speakerdeck
PRO
29
5.4k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Statistics for Hackers
jakevdp
799
220k
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