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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

3 課題 - 汎用的なCI/CDシステムとkubectlでデプロイメントパイプラインを組むのは大変 - フルスクラッチで開発したくはない対応 - できるだけツールに任せられるところは任せよう - ツールの一例として、既存Charts込みでHelmを採用おさらい

Slide 4

Slide 4 text

4 満足いくChartがない問題 - 何がカスタマイズできるのか出来ないのか - chartがメンテナンスされない問題 - chartが大幅に変更されてしまうかもしれない問題 - そもそもchartが存在しない問題 Chartかくのツライ問題 - 自分たちでつくるの？課題への対応

Slide 5

Slide 5 text

5 ● 自分たちでfork・メンテ・Upstreamする ● なければつくる ○ freeeがコントリビュートしたもの auditbeat, heartbeat, aws-es-proxy, apm-server, metricbeat[coming soon!], … 満足いくChartがない

Slide 6

Slide 6 text

6 自分のアプリ用にchartを作るか？ - つくらなければならないわけではない - helm chart/templateをアプリ毎にいちいち書いてられない Chartつくるの大変

Slide 7

Slide 7 text

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パターン

Slide 8

Slide 8 text

8 Chart Best Practicesと、公式Chartsでよく見られるパターンに則ると、どれもほとんど同じChartになる = そのChartから作られるK8Sオブジェクトの殆どの部分がカスタマイズできる(resources, annotations, labels, volumes, volumeMounts, affinity, image, command, args ,...) ポイント

Slide 9

Slide 9 text

9 - 他のツール・テンプレートを使う - kustomize話題ですね - helm pluginsやrelease履歴などの便利機能はなくなりますが、使ってないならいいでしょう - それでもあくまでHelmにこだわりたい場合 - Helm v3以後に代替テンプレートエンジン実装（！）対応できない場合は…

Slide 10

Slide 10 text

10 Chartがない、あるけどメンテナンスされてない・仕様がわからない・仕様が変わる - 自分たちでコントリビュートする Chartづくりが面倒 - 汎用Chartパターンをつくれば繰り返し作業は最小 - そもそもHelmにこだわってないなら他のツールと併用すればよいめでたしめでたし Helmの課題・対応

Slide 11

Slide 11 text

11 めでたしめでたし

Slide 12

Slide 12 text

12 - kubectl (apply, apply --prune, etc) - helm - kapitan - keel - skaffold - deis(fork→hephy) - kustomize(new!) - ※それぞれスコープとスイートスポットが異なる Helm以外のツール

Slide 13

Slide 13 text

13 - helmと併用しなければならないツールが増えてきたときにどうするか？乱立するツール

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

18 どう立ち向かうか?

Slide 19

Slide 19 text

19 Inversion of Control ● ソフトウェアの世界で太古の昔から言われてきたInversion of Control(制御の反転)という考え方 ○ 具体例としてのDependency Injection（依存オブジェクト注入）のほうが知られてる？選択肢4

Slide 20

Slide 20 text

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?

Slide 21

Slide 21 text

21 - K8S APIというインタフェウースを介して、具体的なデプロイ自動化はサービスチームが行う - 素朴にみえるが、これも立派なフレームワークフレームワークの一例

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 インターフェース例: appctl - appctlというcliアプリが必ずプロジェクトルートにあること - ./appctl plan --env stagingで変更チェック - 変更あればexit status 2を返すこと - ./appctl apply --env stagingでDesired Stateを変更実装例

Slide 24

Slide 24 text

24 appctlがあれば・・・ - CI/CDパイプラインからは以下のように呼び出す - ./appctl plan --env staging - ./appctl apply --env staging 実装例

Slide 25

Slide 25 text

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 - 実装例

Slide 26

Slide 26 text

26 - CI/CDパイプラインに各チームが好きなデプロイメントツールを DIする - オーナーシップを持てる範囲が広がる IoCまとめ

Slide 27

Slide 27 text

27 めでたしめでたし

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 - Spinnaker - CircleCI, ConcurseCI, Jenkins(Blue Ocean)のようなパイプラインが一級市民のCIシステム - CorefreshのようなKubernetesデプロイパイプライン専門の SaaS - など予想される展開

Slide 30

Slide 30 text

30 - CD/CDシステムが増えてきたときにどうするか？ - 選択肢1: インフラ的なチームがお守りする？ - 選択肢2: 完全に権限委譲する？ - 選択肢3: 特定のCI/CDシステムを強制する - どこかで見たことある・・・乱立するCI/CD

Slide 31

Slide 31 text

31 ● 始まり：Kubernetesとkubectl、helmという定番ツールで知見・実績を貯める（freeeはいまここ） ○ SREヨットがリード ● 移行期：LinuxやKubernetesより上のレイヤーで、サービスチームが自由にツールを選び始めても運用がまわる ○ サービスヨットがリード、SREヨットはフレームワーク開発（Hiring! ● 成熟期：組織の成長、OSSへのお返し ○ ヨットの枠をこえ、Kubernetesやサービスのオーナーシップよりもっと高次の課題解決へ今後の展望

Slide 32

Slide 32 text

スモールビジネスに携わるすべての人が「創造的な活動」にフォーカスできるよう