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

Kubernetesへのデプロイメント 〜進化の過程と展望〜 後半パート

Kubernetesへのデプロイメント 〜進化の過程と展望〜 後半パート

「Kubernetes Meetup Tokyo #12 」(https://k8sjp.connpass.com/event/90631/) のトーク「Kubernetesへのデプロイメント〜進化の過程と展望〜 」の後半パートです。

前半はこちら: https://speakerdeck.com/atk/kuberneteshefalsedepuroimento-jin-hua-falseguo-cheng-tozhan-wang-qian-ban-pato

#k8sjp

8e045bf747ca7a90b1d955dc30217271?s=128

KUOKA Yusuke

July 11, 2018
Tweet

Transcript

  1. freee 株式会社 Kubernetesへのデプロイメント 〜進化の過程と展望〜 2018.07.11 Kubernetes Meetup Tokyo #12

  2. None
  3. 3 課題 - 汎用的なCI/CDシステムとkubectlでデプロイメントパイプライ ンを組むのは大変 - フルスクラッチで開発したくはない 対応 - できるだけツールに任せられるところは任せよう

    - ツールの一例として、既存Charts込みでHelmを採用 おさらい
  4. 4 満足いくChartがない問題 - 何がカスタマイズできるのか出来ないのか - chartがメンテナンスされない問題 - chartが大幅に変更されてしまうかもしれない問題 - そもそもchartが存在しない問題

    Chartかくのツライ問題 - 自分たちでつくるの? 課題への対応
  5. 5 • 自分たちでfork・メンテ・Upstreamする • なければつくる ◦ freeeがコントリビュートしたもの auditbeat, heartbeat, aws-es-proxy,

    apm-server, metricbeat[coming soon!], … 満足いくChartがない
  6. 6 自分のアプリ用にchartを作るか? - つくらなければならないわけではない - helm chart/templateをアプリ毎にいちいち書いてられない Chartつくるの大変

  7. 7 デプロイパターン毎に一つ汎用Chartをつくっておく - Deployment用に一つ汎用Chart helm upgrade --install ./mycharts/app --set image=myimage

    --set iam-role=myrole --set secret.env.FOO=BAR --set secret.file."/path/to/file"="myfile" 汎用Chartパターン
  8. 8 Chart Best Practicesと、公式Chartsでよく見られるパターンに則 ると、どれもほとんど同じChartになる = そのChartから作られるK8Sオブジェクトの殆どの部分がカスタ マイズできる(resources, annotations, labels,

    volumes, volumeMounts, affinity, image, command, args ,...) ポイント
  9. 9 - 他のツール・テンプレートを使う - kustomize話題ですね - helm pluginsやrelease履歴などの便利機能はなくなりますが、 使ってないならいいでしょう -

    それでもあくまでHelmにこだわりたい場合 - Helm v3以後に代替テンプレートエンジン実装(!) 対応できない場合は…
  10. 10 Chartがない、あるけどメンテナンスされてない・仕様がわからない ・仕様が変わる - 自分たちでコントリビュートする Chartづくりが面倒 - 汎用Chartパターンをつくれば繰り返し作業は最小 - そもそもHelmにこだわってないなら他のツールと併用すれば

    よい めでたしめでたし Helmの課題・対応
  11. 11 めでたしめでたし

  12. 12 - kubectl (apply, apply --prune, etc) - helm -

    kapitan - keel - skaffold - deis(fork→hephy) - kustomize(new!) - ※それぞれスコープとスイートスポットが異なる Helm以外のツール
  13. 13 - helmと併用しなければならないツールが増えてき たときにどうするか? 乱立するツール

  14. 14 1. インフラ的なチームがお守りする 2. 完全に権限委譲する 3. Helmを強制する 選択肢s

  15. 15 インフラ的なチームがお守りする • 人間は最高の汎用コンピュータ • でも採用追いつかない・・ 選択肢1

  16. 16 権限委譲する • 全体最適が・・ ◦ コピペで増殖する少しずつ違うCircleCIパイプライン、 Makefile、・・・ 選択肢2

  17. 17 Helmを強制する • 強制されたツールにオーナーシップを持てるか? • helmが後でそのツールとの統合を追加して、併用しなくて良くな る可能性にかける ◦ 選択肢1とどう違うのか? 選択肢3

  18. 18 どう立ち向かうか?

  19. 19 Inversion of Control • ソフトウェアの世界で太古の昔から言われてきたInversion of Control(制御の反転)という考え方 ◦ 具体例としてのDependency

    Injection(依存オブジェクト注入) のほうが知られてる? 選択肢4
  20. 20 - プラットフォームチーム&サービスチーム - Control: Platform team controls Service team

    that controls app deployments プラットフォームチームがデプロイメントを制御する - Inversion of Control: Platform team builds a framework that controls deployments. Service team injects anything necessary サービスチームがデプロイメントを制御する - これを可能にするフレームワーク What to Control?
  21. 21 - K8S APIというインタフェウースを介して、具体的なデプロイ自動 化はサービスチームが行う - 素朴にみえるが、これも立派なフレームワーク フレームワークの一例

  22. 22 - CI/CDパイプラインに、チーム/プロジェクト/サブプロジェクト/環 境毎に異なる設定値やツールをDIする - 同じCI/CDパイプラインが、異なるチーム間でつかいまわせ る! - 裏を返すと、アプリチームは自由にデプロイメントに利用する ツールを選択できる(特定チームがおすすめするツールをただ

    利用する、わからないことはただ聞く、からの脱却または自立 ツールをDIする
  23. 23 インターフェース例: appctl - appctlというcliアプリが必ずプロジェクトルートにあること - ./appctl plan --env stagingで変更チェック

    - 変更あればexit status 2を返すこと - ./appctl apply --env stagingでDesired Stateを変更 実装例
  24. 24 appctlがあれば・・・ - CI/CDパイプラインからは以下のように呼び出す - ./appctl plan --env staging -

    ./appctl apply --env staging 実装例
  25. 25 #!/usr/bin/env var parameters: - name: env default: "staging" tasks:

    - name: plan script: | kustomize build overlays/{{ get "env" }} > compiled.yaml ./kubediff compiled.yaml - name: apply script: | kustomize build overlays/{{ get "env" }} | kubectl apply -f - 実装例
  26. 26 - CI/CDパイプラインに各チームが好きなデプロイメントツールを DIする - オーナーシップを持てる範囲が広がる IoCまとめ

  27. 27 めでたしめでたし

  28. 28 - Tiller廃止→RBAC利用可 - LuaでHelmプラグイン、LuaでHelper関数、Luaでイ ベントフック(独自テンプレートエンジンなどつくれ る) - ベターHelmとして期待 Helm

    v3への期待
  29. 29 - Spinnaker - CircleCI, ConcurseCI, Jenkins(Blue Ocean)のようなパイプライ ンが一級市民のCIシステム -

    CorefreshのようなKubernetesデプロイパイプライン専門の SaaS - など 予想される展開
  30. 30 - CD/CDシステムが増えてきたときにどうするか? - 選択肢1: インフラ的なチームがお守りする? - 選択肢2: 完全に権限委譲する? -

    選択肢3: 特定のCI/CDシステムを強制する - どこかで見たことある・・・ 乱立するCI/CD
  31. 31 • 始まり:Kubernetesとkubectl、helmという定番ツールで知見・実績を貯める(freeeはい まここ) ◦ SREヨットがリード • 移行期:LinuxやKubernetesより上のレイヤーで、サービスチームが自由にツールを 選び始めても運用がまわる ◦

    サービスヨットがリード、SREヨットはフレームワーク開発(Hiring! • 成熟期:組織の成長、OSSへのお返し ◦ ヨットの枠をこえ、Kubernetesやサービスのオーナーシップよりもっと高次の課題解 決へ 今後の展望
  32. スモールビジネスに携わる すべての人が「創造的な活動」に フォーカスできるよう