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.6k
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
480
エムスリーの Over 300 マイクロサービスを支えるマルチクラウドのネットワーク設計 / M3 cloud network infrastructure for over 1000 microservices
saiya_moebius
0
290
TypeScript の型システム / Type system of the TypeScript
saiya_moebius
10
3.1k
垂直スケールの果ての db.r4.16xlarge で得た教訓 / What happened on vertically scaled 16xlarge DB
saiya_moebius
4
3.9k
DNS を 15 分で雑に知る / grasp DNS in 15 minutes
saiya_moebius
0
120
分散トレーシングの技術選定・OSS 貢献, Stackdriver Trace での性能可視化・改善 / Distributed Tracing case study
saiya_moebius
10
6.3k
RDBMS in Action
saiya_moebius
56
22k
Compiler/JIT optimizations & escape analysis
saiya_moebius
2
350
How to setup Gradle to improve legacy Java system
saiya_moebius
1
2.6k
Other Decks in Technology
See All in Technology
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
170
バクラクにおける可観測性向上の取り組み
yuu26
3
410
フルカイテン株式会社 採用資料
fullkaiten
0
36k
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
3
270
生成AIと知識グラフの相互利用に基づく文書解析
koujikozaki
1
140
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
【若手エンジニア応援LT会】AWSで繋がり、共に成長! ~コミュニティ活動と新人教育への挑戦~
kazushi_ohata
0
180
事業者間調整の行間を読む 調整の具体事例
sugiim
0
1.4k
10分でわかるfreeeのQA
freee
1
3.4k
初心者に Vue.js を 教えるには
tsukuha
5
390
pandasはPolarsに性能面で追いつき追い越せるのか
vaaaaanquish
4
4.5k
Autify Company Deck
autifyhq
1
39k
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
334
57k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Gamification - CAS2011
davidbonilla
80
5k
We Have a Design System, Now What?
morganepeng
50
7.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Building an army of robots
kneath
302
42k
A designer walks into a library…
pauljervisheath
202
24k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
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