Kubernetesを最大限に活かすためのGitOps入門

Kubernetes環境でCI/CDを実現する「GitOps」について。
@さくらの夕べ Docker/Kubernetesナイト

お受けした質問の一部はこちらのツイートに紐づく形で回答しています→https://twitter.com/amaya382/status/1140575485878886400

1. Kubernetesを 最⼤限に活かすためのGitOps⼊⾨ @さくらの⼣べ Docker/Kubernetesナイト 技術本部 伊藤⻯⼀ (@amaya382) 2019/6/17
2. ⾃⼰紹介 伊藤⻯⼀ • しごと • 所属: 技術本部 アプリケーショングループ • 新規プロジェクト×2でKubernetesを導⼊中 • 1つはAPIサーバのデプロイ先、バッチ処理実⾏環境として • 1つはスケーラブルなデータ処理基盤として • こじん • Twitter: @amaya382 • Kubernetesに関する同⼈誌を書いたり • 技術書典7もKubernetes関係で模索中 2
3. 対象者とゴール 前提 • k8s・CI/CDの基本的な概念をある程度理解している 対象者 • k8s上にアプリをデプロイするベストプラクティスを知りたい⼈ ゴール • GitOpsの概念を知る • 既存のCI/CDとの違い • GitOps導⼊に必要な諸々を知る • あわよくば、 「kubectlで⼿動デプロイするのは⼩学⽣までだよねーwww」 ぐらいの⼼意気を⼿に⼊れる 3
4. GitOpsの概要とゴール k8s環境を前提としたCI/CDの戦略 • 原典: https://www.weave.works/technologies/gitops/ 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • デプロイ状態の確認を容易に • 開発だけでなく、運⽤作業もGitの操作で統⼀ 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 4 例えば… Git Revertでサービス巻き戻し
5. GitOpsの概要とゴール k8s環境を前提としたCI/CDの戦略 • 原典: https://www.weave.works/technologies/gitops/ 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • デプロイ状態の確認を容易に • 開発だけでなく、運⽤作業もGitの操作で統⼀ 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 5 CIの権限は最低限に
6. GitOpsを従来のCI/CDと⽐較する 6
7. CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI
   (Continuous
   Integration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD
   (Continuous
   Delivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 7 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy
8. CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI
   (Continuous
   Integration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD
   (Continuous
   Delivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 8 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy CI
9. CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI
   (Continuous
   Integration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD
   (Continuous
   Delivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 9 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy CD
10. k8s環境へアプリデプロイ kubectl applyコマンド • いい感じに新規作成または部分更新してくれる • ただし、⼿動では 「apply漏れ」・「デプロイ先間違い」・「権限管理問題」等が発⽣ 10 Apply 開発環境で 試してみよう ？ ？ 環境
11. k8s環境へアプリデプロイ kubectl applyコマンド • いい感じに新規作成または部分更新してくれる • ただし、⼿動では 「apply漏れ」・「デプロイ先間違い」・「権限管理問題」等が発⽣ 11 Apply ？ ？ 環境 本番 本番環境だった！！
12. k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 12 Apply 開発環境 本番環境 Apply
13. k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 13 Apply 開発環境 本番環境 Apply 変更をデプロイするだけ 状態を管理できるわけではない
14. k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 14 Apply 開発環境 本番環境 Apply 誰も触れない秘伝のタレ
15. k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 15 Apply 開発環境 本番環境 Apply ⾼セキュリティリスク
16. GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 16 Single
    Source
    of
    Truth (Manifestファイル群) SSoTと同期 • アプリAを2つ • アプリBを4つ • GET /users はアプリAへ • POST /comments はアプリBへ • ロードバランサが必要
17. Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 17 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール
18. Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 18 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) CI Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール
19. Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 19 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) CD アプリソースコード CIツール CDツール
20. Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 20 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール CD CI
21. Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 21 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール デプロイ実⾏
22. Docker Registry GitOpsの全体像 22 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 1. コードをPush
23. Docker Registry GitOpsの全体像 23 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 2. CI動作開始
24. Docker Registry GitOpsの全体像 24 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 3. ビルド成果物 をアップロード
25. Docker Registry GitOpsの全体像 25 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 4. 更新を反映する PRを作成
26. Docker Registry GitOpsの全体像 26 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 5. 更新を確認・承認
27. Docker Registry GitOpsの全体像 27 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 6. SSoTが更新
28. Docker Registry GitOpsの全体像 28 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 7. SSoTが更新を検知・反映
29. GitOpsの全体像 Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • コードベースでリソース管理できるk8sと相性 CIとCDの分離 • CI • テストやビルドに注⼒ • Push型 • 実⾏環境への権限は不要 • CD • デプロイに注⼒ • Pull型 • ⾃⾝の実⾏環境への権限のみ持つ 29 apiVersion: apps/v1 kind: Deployment metadata: labels: app: debugkit name: debugkit spec: replicas: 1 selector: matchLabels: app: debugkit template: metadata: labels: app: debugkit spec: containers: - image: amaya382/k8s-debugkit name: k8s-debugkit
30. GitOpsの全体像 Single
    Source
    of
    Truthとして、サービスの状態を1つのGitリポジトリで持つ • コードベースでリソース管理できるk8sと相性 CIとCDの分離 • CI • テストやビルドに注⼒ • Push型 • 実⾏環境への権限は不要 • CD • デプロイに注⼒ • Pull型 • ⾃⾝の実⾏環境への権限のみ持つ 30 CI CD
31. 実際に使うには 31
32. どうやって導⼊するん？ • 「ツール選択」 • 「アプリとManifest⽤Gitリポジトリの作成」 • 「Manifest作成」 • 「アプリ側の準備 (CI)」 • 「k8s側の準備 (CD)」 32
33. どうやって導⼊するん？ 「ツール選択」 Gitリポジトリ • GitHub/GitHubEnterprise/GitLab/Bitbucket/GitBucket/... • 選ぶポイント:
    どれを使ってもGitOpsには⼤差なし、よく使ってるやつでok CI • CircleCI/TravisCI/Jenkins/Drone/ConcourceCI/... • 選ぶポイント:
    どれを使ってもGitOpsには⼤差なし、よく使ってるやつでok • (GitリポジトリやDockerRegistryのCIでも可) 33
34. どうやって導⼊するん？ 「ツール選択」 CD • WeaveFlux/ArgoCD/JenkinsX/... • 選ぶポイント: GitOpsに対応していること、対応しているテンプレートエンジン、権限管理、対応して いるデプロイ⽅法 (e.g.,
    Blue-Green)、UIやCLIの使いやすさ Manifestテンプレートエンジン • Helm/kustomize/... • 選ぶポイント:
    対応しているCDツール、扱いやすさ • ※ksonnetは開発中⽌の⾒込みなので注意 • ※Helm3は未知数 34
35. どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごとのリポジトリ • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートを利⽤ • e.g.,
    接続先DB、レプリカ数 35 アプリソースコード Single
    Source
    of
    Truth (Manifestファイル群)
36. どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごと • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートを利⽤ • e.g.,
    接続先DB、レプリカ数 36 アプリソースコード Single
    Source
    of
    Truth (Manifestファイル群) apiVersion: apps/v1 kind: Deployment metadata: labels: app: debugkit name: debugkit spec: replicas: 1 selector: matchLabels: app: debugkit template: metadata: labels: app: debugkit spec: containers: - image: amaya382/k8s-debugkit name: k8s-debugkit
37. どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごとのリポジトリ • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートエンジンを利⽤ • e.g.,
    接続先DB、レプリカ数 37 アプリソースコード Single
    Source
    of
    Truth (Manifestファイル群)
38. どうやって導⼊するん？ 「アプリ側の準備 (CI)」 • 各アプリのDockerImageをDockerRegistryにプッシュ • 同時に、「新しいDockerImageを利⽤するManifest」の プルリクエストをManifestリポジトリに作成 38 Docker Registry Single
    Source
    of
    Truth (Manifestファイル群) デ プ ロ イ要 求 (PR作 成 ) アプリイメージ更新 CIツール CI設定
39. どうやって導⼊するん？ 「k8s側の準備 (CD)」 • クラスタ別にCDツールをインストール • Manifestリポジトリを利⽤するCD設定を追加 39 環境ごとにPullすることで 最低限の権限で動作 Single
    Source
    of
    Truth (Manifestファイル群) CDツール CDツール 開発環境 本番環境 CD設定 CD設定
40. どんな感じにサイクル回すん？ アプリ単体の更新 1. 開発者が各アプリリポジトリに変更をPush (実際にはプルリクエストを経由) 2. CIが動作 1. ビルドし、DockerImageをDockerRegistryへPush 2. 新しいDockerImageを使うように変更するプルリクエストを作成 3. 運⽤者がプルリクエストを確認・承認 4. SSoTが更新される 5. CDがSSoTの変化を検知・反映 40 従来のデプロイ作業を プルリクエスト承認で⾏う
41. Docker Registry どんな感じにサイクル回すん？ 41 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 1. コードをPush ⼈⼿ ⾃動
42. Docker Registry どんな感じにサイクル回すん？ 42 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 2. CI動作開始 2-2. 更新を反映する PRを作成 ⼈⼿ ⾃動 2-1. ビルド成果物 をアップロード PR
43. Docker Registry どんな感じにサイクル回すん？ 43 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 3. 更新を確認・承認 ⼈⼿ ⾃動 PR
44. Docker Registry どんな感じにサイクル回すん？ 44 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 4. SSoTが更新 ⼈⼿ ⾃動
45. Docker Registry どんな感じにサイクル回すん？ 45 Single
    Source
    of
    Truth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 5. SSoTが更新を検知・反映 ⼈⼿ ⾃動
46. どんな感じにサイクル回すん？ サービス構成の更新 1. 開発者がManifestリポジトリを更新するプルリクエストを作成 2. 運⽤者がプルリクエストを確認・承認 3. SSoTが更新される 4. CDがSSoTの変化を検知・反映 46
47. どんな感じにサイクル回すん？ 47 Single
    Source
    of
    Truth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 1. サービス構成を 変更するPRを作成 ⼈⼿ ⾃動 PR
48. どんな感じにサイクル回すん？ 48 Single
    Source
    of
    Truth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 2. 更新を確認・承認 ⼈⼿ ⾃動 PR
49. どんな感じにサイクル回すん？ 49 Single
    Source
    of
    Truth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 3. SSoTが更新 ⼈⼿ ⾃動
50. どんな感じにサイクル回すん？ 50 Single
    Source
    of
    Truth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 4. SSoTが更新を検知・反映 ⼈⼿ ⾃動
51. 残る課題 • 全体が揃うと⼀気に動き出すモデルなので、 最初のセットアップがやや⼤変 • 適切なブランチ戦略が必要 • どのような変更をどの環境への変更としたいか • サービスによりその戦略は異なる • e.g., • 似たようなプロダクション環境が⼤量に必要になる場合 • バージョンごとにプロダクション環境を維持し続けていく場合 51
52. まとめ DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 How • Single
    Source
    of
    Truthとして、デプロイ状態を1つのGitリポジトリで管理 • 関⼼ (CI/CD) の分離 Result • 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • Gitリポジトリの状態 == デプロイの状態 • 開発だけでなく、運⽤作業もGitの操作で統⼀ • 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 52 運⽤者(Ops) 開発者(Dev)
53. ベストプラクティス・ Pitfall集 CDツールって1箇所に設置すれば集中管理できて楽じゃん！ • 別クラスタの稼働状況に依存させるべきではない 別クラスタへのアクセス権限をもたせるべきではない • 環境ごとに設置し、Pull型を維持すべき k8s外のリソースは？ • 考慮されていないので難しい • k8s上のCDツールではk8s外リソースのデプロイを管理しないほうが良い • e.g.,
    TerraformでSaaSのRDBを構築 • Manifestにはサービスへのアクセス情報だけ保持 (e.g.,
    Headless
    Service) • ≒k8s内のServiceDiscovery対象には⼊れておく 53
54. ベストプラクティス・ Pitfall集 あれ？反映できてない？ • 即座に更新されるリソース・されないリソース • e.g.,
    環境変数の更新→Podを再起動しないと反映されない • CDツールが判断して全てを適切に更新してくれるのが理想 • ⚠更新ポリシーに注意する必要がある (模索中) 複数アプリの場合、Manifestの更新がバラバラになりそうだけど…？ • そもそもアプリ側がバラバラにデプロイできるように設計するべき • e.g.,
    API互換性の管理はURLの /v1/
    とか 54
55. ベストプラクティス・ Pitfall集 Helmでデプロイまでできるよね？ • 「どのHelmパッケージがデプロイされているのか」を別途管理しなければならな くなってしまう • GitOpsでは、Helmはテンプレートエンジンとしてのみ使う • なのでTiller
    (2.x系にあるk8s内部に設置するリソース)は不要 CredentialsをGitリポジトリに含めるとかありえん！！！ • せやな！！！ • SealedSecret • https://github.com/bitnami-labs/sealed-secrets • Credentialsを暗号化した状態でManifestリポジトリに含める k8s側で⾃動的に復号される 55
56. ベストプラクティス・ Pitfall集 IstioやPrometheus、Exporterみたいなやつらの管理は？ • 例えばCDツールにはbootstrap問題 • 上記のような場合は別リポジトリに切り出し Manifest書くの⼤変そう… • kubectlのcreate
    dry-runやget
    exportでテンプレート作成 • 公式API
    Docが便利 • https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/ 56
57. 参考⽂献 • GitOps • https://www.weave.works/technologies/gitops/ • GitOpsではじめるKubernetes CI/CD Pipeline • https://www.slideshare.net/linecorp/gitopskubernetes-cicd-pipeline • Kubernetesで作るコンテナベースCI★CDの⼣べ/ochacafe#1 • https://speakerdeck.com/hhiroshell/ochacafe-number-1 57