Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes こわくないよ!

saiya_moebius
September 09, 2019

Kubernetes こわくないよ!

Kubernetes を気負わずに導入した話 + ちょっとしたハマりごとエピソードです。

#m3k8s https://m3-engineer.connpass.com/event/143295/

saiya_moebius

September 09, 2019
Tweet

More Decks by saiya_moebius

Other Decks in Technology

Transcript

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

    View full-size slide

  2. Who?
    ⽮崎 聖也 @saiya_moebius
    エムスリー株式会社 CTO
    サーバーサイドを中⼼としつつ⾊々やってきたエンジニア
    Java, Kotlin, Rails 等 (⾔語として好きなのは C#)
    最近主に書いているのは TypeScript, terraform
    クラウドでは AWS 経験が多かったが、最近は GCP も増えてきている
    こんなスライド書いていたり:
    Web アプリをとりあえず Kubernetes にデプロイするための知識
    Spring Boot と⼀般ライブラリの折り合いのつけかた
    いまどきのコンパイラ・JIT の最適化と Escape Analysis 2

    View full-size slide

  3. おことわり
    このスライドは、 Kubernetes
    こわくないよ! というゆるーい話です。
    AWS ECS や GKE 等の存在を知っている前提で書いています
    Kubernetes の具体的な使い⽅には踏み込みません
    公式ドキュメントを⾒てもらうなり、実際に触ってもらうほうが速い
    Kubernetes のディープな話ではないです
    CRD (Custom Resource Definition) の実装とか⾒ていると⾯⽩いですが
    3

    View full-size slide

  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

    View full-size slide

  5. M3 US ⽀社のリニューアル案件にて
    筆者が基盤整備したプロジェクトにて、
    最初のプロトタイプは⼿慣れた AWS ECS で構築し
    本実装は GKE で実装した
    弊社の既存サービスでは AWS ECS 利⽤が多く、
    ⼿慣れた ECS で建てるのが最速・安定の選択肢ではあった。
    しかし、GCP 使っていこうぜ!というチーム内の声もあり、最終形では GKE に。
    5

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  9. クラスタのスケーリングがやりやすく
    Cluster Autoscaler がとても便利。最⼤・最⼩台数を指定するだけで良い。
    「Node 不⾜で実⾏待ちの Pod がいれば Node を増やす」というだけのルールが
    (凝ったことをしなければ) ⼗分便利に機能する。
    なので絶妙なチューニングなどをしなくても、適切な Node 台数に⾃然となる。
    9

    View full-size slide

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

    View full-size slide

  11. 周辺ツールの発展やノウハウの可搬性
    K8s は今後のインフラの共通 API となりつつある
    Istio, Spinnaker, Knative などは k8s がメインターゲット or 必要条件
    K8s の CRD (Custom Resource Definition) として提供されるツールも
    GCP Config Connector とか
    K8s が広まったことで、ノウハウのポータビリィが上がってきている
    個⼈として k8s を学習するメリットが⾼い
    K8s 学習者が増えると、チーム・企業の k8s の導⼊障壁が下がる
    導⼊が増えることで k8s 学習のメリットが⾼まり...以下ループ
    11

    View full-size slide

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

    View full-size slide

  13. Appendix: 実際あった しくじりエピソード
    本番リリース直前に Node が減った...!?
    事件はオフィスで起きてるんじゃない! k8s クラスタで起きてるんだ!
    GKE 固有の話になってしまいますが、ご笑覧いただければ。
    GKE 詳しい勢は途中でタネを察してしまうかもしれませんが黙っていてね!
    ...以下、時間軸順...
    13

    View full-size slide

  14. 平和な dev 環境クラスタだった
    terraform で google_container_cluster
    , google_container_node_pool
    をセットアッ
    プした。
    特に凝ったことはしていない。
    そして、dev 環境での開発も意外にすんなり進み始めた...
    伏線: GKE の master の version up 中は何も操作できなかったが、それは普通の仕様だと思っ
    ていた。
    14

    View full-size slide

  15. 本番リリース直前に
    ある⽇⾒たら node 数不⾜で pod が起動できていない:
    GKE master の zone と同じ zone の VM は node として認識されている
    Master と異なる zone にある VM は node として認識されていない
    とりあえず cluster の node 数(VM 総数)を増やすことで回避したが...
    単⼀ zone にしか node がないので、冗⻑性皆無 & SLA 保証外
    他の zone の VM も課⾦はされているので、盛⼤に無駄なコスト
    これはアカン
    15

    View full-size slide

  16. 調べてみると
    問題のノードでは kube-proxy
    が起動に失敗している。
    ログをもとに絞り込んだところ、VM ⾃⾝の IP アドレスをインスタンスメタデータから取得す
    る処理で失敗しているようだ。
    ソースコードも⾒てみたが、当該部分の処理の実体(GKE固有)は⾮ OSS だった。
    なぜ失敗するのかさっぱりわからず。
    もはや何もわからないので、GCP のサポートケースを起票。
    「そちらの作りが何か悪いのでは?」などなどの問答が発⽣...
    16

    View full-size slide

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

    View full-size slide

  18. そんなある⽇
    「(問題の事象⾃体はよくわからないけど)
    zonal cluster より regional cluster の⽅が推奨だよ」 by サポート
    リージョン クラスタを作成することで、クラスタの可⽤性と復元⼒を向上させることが
    できます。
    と公式ページにも書いてあるぞ! by サポート
    えっ、なんの話をしてるんだ...?
    18

    View full-size slide

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

    View full-size slide

  20. 真の敗因
    location = "us-west1"
    この terraform 記述( Optional
    )を冗⻑だと思って削ったのが敗因。
    よく⾒ると zone (terraform デフォルト)ではなく region を指定しているのがポイント。
    このように明⽰しないと zonal cluster になるので、この記述は消してはいけない。
    20

    View full-size slide

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

    View full-size slide

  22. Enjoy Kubernetes!
    エムスリーではエンジニア・SRE・チーム内 SRE などを募集しております!

    チーム内 SRE = プロダクトの仕様や実装にも介⼊しつつ⾜回りをやるロール
    もしご興味あれば、ぜひその旨アンケートにご記⼊ください!
    ⽇経平均株価に⼊った翌週に急に SQL Injection とかのアクセスが来てびっくり
    22

    View full-size slide