Kubernetes こわくないよ！

Transcript

1. Kubernetes こわくないよ！ + Appendix: 実際あった しくじりエピソード web エンジニアが使う⾝近な k8s -

   September 2019 Seiya Yazaki 1

2. Who? ⽮崎 聖也 @saiya_moebius エムスリー株式会社 CTO サーバーサイドを中⼼としつつ⾊々やってきたエンジニア Java, Kotlin, Rails

   等 (⾔語として好きなのは C#) 最近主に書いているのは TypeScript, terraform クラウドでは AWS 経験が多かったが、最近は GCP も増えてきている こんなスライド書いていたり: Web アプリをとりあえず Kubernetes にデプロイするための知識 Spring Boot と⼀般ライブラリの折り合いのつけかた いまどきのコンパイラ・JIT の最適化と Escape Analysis 2

3. おことわり このスライドは、 Kubernetes こわくないよ！ というゆるーい話です。 AWS ECS や GKE 等の存在を知っている前提で書いています

   Kubernetes の具体的な使い⽅には踏み込みません 公式ドキュメントを⾒てもらうなり、実際に触ってもらうほうが速い Kubernetes のディープな話ではないです CRD (Custom Resource Definition) の実装とか⾒ていると⾯⽩いですが 3

4. 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

5. M3 US ⽀社のリニューアル案件にて 筆者が基盤整備したプロジェクトにて、 最初のプロトタイプは⼿慣れた AWS ECS で構築し 本実装は GKE

   で実装した 弊社の既存サービスでは AWS ECS 利⽤が多く、 ⼿慣れた ECS で建てるのが最速・安定の選択肢ではあった。 しかし、GCP 使っていこうぜ！というチーム内の声もあり、最終形では GKE に。 5

6. なぜ GKE ？ Firebase を使う都合で GCP に寄せたかったのもあるが、 それ以外にも GKE にして

   良くなること/なったこと が⾊々あった: Managed な Kubenetes (GKE) の良さがあった デプロイが楽になった クラスタのスケーリングがやりやすくなった クラウドベンダー依存を軽減できた 周辺ツールの発展やノウハウの可搬性を期待できる 以下、それぞれについて話します。 6

7. Managed な Kubernetes の良さ Kubernetes = 構築や運⽤が⼤変 というイメージがあったが、 運⽤性は ECS

   とさほど変わらなかった: 各種 k8s コンポーネントのログは Stackdriver Logs で⾒える Node に SSH ログインして⾊々することも普通に可能 gcloud beta compute ssh --tunnel-through-iap がオススメ GKE であれば、セットアップは ECS よりずっとラク。 K8s 基盤に何を使うか(GKE, AWS EKS, オンプレ k8s, ...)次第で 構築や運⽤の⼿間・特性が異なるので、世の中の体験記を⾒る際には留意が必要。 7

8. デプロイが楽に 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

9. クラスタのスケーリングがやりやすく Cluster Autoscaler がとても便利。最⼤・最⼩台数を指定するだけで良い。 「Node 不⾜で実⾏待ちの Pod がいれば Node を増やす」というだけのルールが

   (凝ったことをしなければ) ⼗分便利に機能する。 なので絶妙なチューニングなどをしなくても、適切な Node 台数に⾃然となる。 9

10. クラウドベンダー依存の軽減 3 ⼤クラウド(GCP, AWS, Azure)が managed service を提供している点が⼤きい。 もちろん DB

    等の都合もあるため完全なクラウドベンダー⾮依存は不可能だが、 使いたい DB 等があるクラウドに移るという考え⽅をしやすくなった。 利⽤技術が定まっていないプロジェクト初期から CI 周りを作り込んでも、 k8s を対象にしていれば無駄になりにくい、というメリットも。 ( 冒頭で紹介した US 事例では、ECS 向けに整備した CI を捨てて k8s 向けに再整備しまし た... ) 10

11. 周辺ツールの発展やノウハウの可搬性 K8s は今後のインフラの共通 API となりつつある Istio, Spinnaker, Knative などは k8s

    がメインターゲット or 必要条件 K8s の CRD (Custom Resource Definition) として提供されるツールも GCP Config Connector とか K8s が広まったことで、ノウハウのポータビリィが上がってきている 個⼈として k8s を学習するメリットが⾼い K8s 学習者が増えると、チーム・企業の k8s の導⼊障壁が下がる 導⼊が増えることで k8s 学習のメリットが⾼まり...以下ループ 11

12. Kubernetes 使ってみたくなってきたところで ⾃分のスライドのステマ → Web アプリをとりあえず Kubernetes にデプロイするための知識 12

13. Appendix: 実際あった しくじりエピソード 本番リリース直前に Node が減った...!? 事件はオフィスで起きてるんじゃない！ k8s クラスタで起きてるんだ！ GKE

    固有の話になってしまいますが、ご笑覧いただければ。 GKE 詳しい勢は途中でタネを察してしまうかもしれませんが黙っていてね！ ...以下、時間軸順... 13

14. 平和な dev 環境クラスタだった terraform で google_container_cluster , google_container_node_pool をセットアッ プした。

    特に凝ったことはしていない。 そして、dev 環境での開発も意外にすんなり進み始めた... 伏線: GKE の master の version up 中は何も操作できなかったが、それは普通の仕様だと思っ ていた。 14

15. 本番リリース直前に ある⽇⾒たら node 数不⾜で pod が起動できていない: GKE master の zone

    と同じ zone の VM は node として認識されている Master と異なる zone にある VM は node として認識されていない とりあえず cluster の node 数(VM 総数)を増やすことで回避したが... 単⼀ zone にしか node がないので、冗⻑性皆無 & SLA 保証外 他の zone の VM も課⾦はされているので、盛⼤に無駄なコスト これはアカン 15

16. 調べてみると 問題のノードでは kube-proxy が起動に失敗している。 ログをもとに絞り込んだところ、VM ⾃⾝の IP アドレスをインスタンスメタデータから取得す る処理で失敗しているようだ。 ソースコードも⾒てみたが、当該部分の処理の実体(GKE固有)は⾮

    OSS だった。 なぜ失敗するのかさっぱりわからず。 もはや何もわからないので、GCP のサポートケースを起票。 「そちらの作りが何か悪いのでは？」などなどの問答が発⽣... 16

17. このまま本番には出せないよね... 幸い US の開発チームは夜 (JST) に開発している。 昼 (JST) に cluster,

    node pool を消しては作り直しで試⾏錯誤: GKE / k8s バージョンを過去のものに戻す いろいろなバージョンを⼆分探索する 過去の terraform 設定に戻して⼆分探索する Node の OS 変えてみる ⼿当り次第⾊々オプションを変えてみる だがことごとく発症...!! 発症のトリガーすら分からず。 1 回のクラスタ作り直しに 45 min 程度かかるので無限に時間を⾷う...!! 17

18. そんなある⽇ 「(問題の事象⾃体はよくわからないけど) zonal cluster より regional cluster の⽅が推奨だよ」 by サポート

    リージョン クラスタを作成することで、クラスタの可⽤性と復元⼒を向上させることが できます。 と公式ページにも書いてあるぞ！ by サポート えっ、なんの話をしてるんだ...? 18

19. 設定項⽬⾒落とし インフラやミドルウエアのデフォルト値含めてすべての設定値は⼀通り最終チェックするのが 信条の筆者だったが...。 まさかの regional cluster 設定の存在を完全に忘れていた。 ( regional cluster:

    cluster の master を複数 zone に冗⻑化する構成 ) サポートありがとう。 19

20. 真の敗因 location = "us-west1" この terraform 記述( Optional )を冗⻑だと思って削ったのが敗因。 よく⾒ると

    zone (terraform デフォルト)ではなく region を指定しているのがポイント。 このように明⽰しないと zonal cluster になるので、この記述は消してはいけない。 20

21. 俺たちの戦いは始まったばかりだ！ というわけで regional cluster にしたところ問題事象が解消したのであった。 ちなみに master update 中も kubectl

    操作できるようになった。 Zonal cluster はやめよう。 21

22. Enjoy Kubernetes! エムスリーではエンジニア・SRE・チーム内 SRE などを募集しております！ ※ チーム内 SRE = プロダクトの仕様や実装にも介⼊しつつ⾜回りをやるロール

    もしご興味あれば、ぜひその旨アンケートにご記⼊ください！ ⽇経平均株価に⼊った翌週に急に SQL Injection とかのアクセスが来てびっくり 22