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

KUOKA Yusuke

July 11, 2018
Tweet

More Decks by KUOKA Yusuke

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. 11
    めでたしめでたし

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 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 full-size slide

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

    View full-size slide

  26. 27
    めでたしめでたし

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide