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

Transcript

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

   View Slide

2. View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. 11
    めでたしめでたし
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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?
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. 27
    めでたしめでたし
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide