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

1. freee 株式会社 Kubernetesへのデプロイメント 〜進化の過程と展望〜 2018.07.11 Kubernetes Meetup Tokyo #12
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. スモールビジネスに携わる すべての人が「創造的な活動」に フォーカスできるよう