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
490
エムスリーの Over 300 マイクロサービスを支えるマルチクラウドのネットワーク設計 / M3 cloud network infrastructure for over 1000 microservices
saiya_moebius
0
300
TypeScript の型システム / Type system of the TypeScript
saiya_moebius
10
3.2k
垂直スケールの果ての 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.4k
RDBMS in Action
saiya_moebius
56
23k
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
SRE×AIOpsを始めよう!GuardDutyによるお手軽脅威検出
amixedcolor
0
130
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
130
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
600
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.1k
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
360
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
490
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
140
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
2
520
サイバーセキュリティと認知バイアス:対策の隙を埋める心理学的アプローチ
shumei_ito
0
390
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Six Lessons from altMBA
skipperchong
27
3.5k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
RailsConf 2023
tenderlove
29
900
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
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