GitOps_Kubernetes

Presentation: GitOps Kubernetes
Speaker: Kazufumi Saito(@capsmalt), Soto Sugita(@sotoiwa)
Location: IBM Cloud Community Summit2019

Transcript

1. IBM Cloud Community Summit 2019 Kazufumi Saito @capsmalt Soto Sugita @sotoiwa Kubernetesアプリケーション運⽤基礎
2. @capsmalt 2 Kazufumi Saito @capsmalt Soto Sugita @sotoiwa IBM Japan IBM Japan Systems Engineering
3. @capsmalt 3 共通点 1 Raspberry Pi で K8s Cluster 斎藤家 杉⽥家
4. @capsmalt 4 共通点 2 家族まで Kubernetes...K8s...K8s... 斎藤家 杉⽥家
5. @capsmalt 5
6. @capsmalt 6
7. @capsmalt 7 Why? Kubernetes
8. @capsmalt 8
9. @capsmalt 9 Party
10. @capsmalt 10
11. @capsmalt 11 Why? Kubernetes
12. @capsmalt 12 Declarative
13. @capsmalt 13 Declarative (宣⾔的)
14. @capsmalt 14 Worker Node (OS: Ubuntu) kubectl apply –f deploy-nginx.yaml nginx:1.15.12
15. @capsmalt 15 kubectl apply –f deploy-nginx.yaml Worker Node (OS: Ubuntu) レプリカ数を指定 (replicas: 2) nginx:1.15.12
16. @capsmalt 16 kubectl apply –f deploy-nginx.yaml Worker Node (OS: Ubuntu) イメージタグ(バージョン)を変更 nginx:1.15.8
17. @capsmalt 17 kubectl apply –f deploy-nginx.yaml Worker Node (OS: Ubuntu) イメージタグ(バージョン)を変更 nginx:1.15.8
18. @capsmalt 18 Worker Node (OS: Ubuntu) Kubernetes 管理下のコンテナ環境 Worker Node (OS: Ubuntu) Worker Node (OS: Ubuntu) Kubernetes クラスター 複数Nodeで Kubernetesクラスターを構成 コンテナ 正確にはPodですが，説明簡略化のためコンテナとします。
19. @capsmalt 19 Worker Node (OS: Ubuntu) Worker Node (OS: Ubuntu) Worker Node (OS: Ubuntu) Kubernetes クラスター あるコンテナに問題があれば，別Nodeで新コンテナとして動作 Kubernetes 管理下のコンテナ環境 コンテナ 正確にはPodですが，説明簡略化のためコンテナとします。
20. @capsmalt 20 Worker Node (OS: Ubuntu) Worker Node (OS: Ubuntu) Worker Node (OS: Ubuntu) Kubernetes クラスター あるNodeに問題があれば，別Nodeで新コンテナとして動作 Kubernetes 管理下のコンテナ環境 コンテナ 正確にはPodですが，説明簡略化のためコンテナとします。
21. @capsmalt 21 Declarative (宣⾔的) あるべき姿 (レプリカ数=2) を宣⾔しておけば， Kubernetes Controllerが， 宣⾔された状態 に近づけてくれる
22. @capsmalt 22 Worker Node (OS: Ubuntu) nginx:1.15.8 node:10.15.3 kubectl apply –f xxx.yaml
23. @capsmalt 23 Worker Node (OS: Ubuntu) nginx:1.15.8 node:10.15.3 kubectl apply –f xxx.yaml
24. @capsmalt 24 Worker Node (OS: Ubuntu) nginx:1.15.8 node:10.15.3 kubectl apply –f xxx.yaml Kubernetes クラスター上の アプリケーション や 構成 をリポジトリ管理する
25. @capsmalt 25 Worker Node (OS: Ubuntu) nginx:1.15.8 node:10.15.3 kubectl apply –f xxx.yaml もしK8sクラスターが壊れても・・・
26. @capsmalt 26 Worker Node (OS: Ubuntu) nginx:1.15.8 node:10.15.3 kubectl apply –f xxx.yaml リポジトリに “正しい構成” があるから， それを反映させればOK 復活︕
27. @capsmalt 27 Kubernetesやっていく上で知っておいた⽅が良いコト 1. K8sクラスターの運⽤ 2. K8s上アプリの運⽤
28. @capsmalt 28 Kubernetesやっていく上で知っておいた⽅が良いコト 1. K8sクラスターの運⽤ 2. K8s上アプリの運⽤
29. @capsmalt 29 Kubernetesやっていく上で知っておいた⽅が良いコト 1. K8sクラスターの運⽤ 2. K8s上アプリの運⽤ (本⽇は，アプリデプロイ)
30. @capsmalt 30 CI/CD Overview Code Build Test Release Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery
31. @capsmalt 31 CI/CD Overview - Kubernetes Code Build Test Release Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery Dev, Stage Production
32. @capsmalt 32 CI/CD Overview - Kubernetes Code Build Test Release Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml
33. @capsmalt 33 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml CI Pipeline CD Pipeline Build Test Release CIツールが命令して 処理を流す(⾃動化) 例えば Jenkins CI と CD を両⽅やるケース (=CIOps)
34. @capsmalt 34 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml Production Dev, Stage Registry CD のフェーズ
35. @capsmalt 35 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml Production Dev, Stage Registry CD のフェーズ 打ちっぱなし ならOKな気がする
36. @capsmalt 36 何かが気になる・・
37. @capsmalt 37 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml Production Dev, Stage Registry ・CIツール⽤のSecret(Registry) ・Service Accountにパッチ ・etc. クレデンシャル情報の管理 (セキュリティリスク)
38. @capsmalt 38 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml Production Dev, Stage Registry 全てのデプロイ先を考慮した 設定やパイプラインが必要 デプロイ先ごとに異なるマニフェストファイルを作成して・・・ Dev2 たくさんのyaml
39. @capsmalt 39 CI/CD Overview - Kubernetes Code Unit Integration CI Pipeline CD Pipeline Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI: Continuous Integration CD: Continuous Delivery kubectl apply -f xxx-stg.yaml kubectl apply -f xxx-prd.yaml Production Dev, Stage Registry イマのK8sクラスターの状態は 本当にあるべき姿なのか︖ パイプラインの中で実⾏したマニフェストファイルはどれ︖︖ 誰かが勝⼿に kubectl set/edit/applyしてない︖︖ kubectl set xxx kubectl edit xxx 失敗 直接イメージ変更
40. @capsmalt 40 GitOps
41. @capsmalt 41 What is GitOps ・「Weaveworks」社によって提唱された CD (Continuous Delivery) の⼿法 ・アプリコードとマニフェストは別に管理する (CI と CD を分離) ・全てのオペレーションは，Gitで⾏う (Pull Requestを起点にする) ・Gitリポジトリ上のK8sマニフェストと実際のK8sクラスターの構成を⼀致させる (GitOps OperatorがK8sコントローラとして担う)
42. @capsmalt 42 GitOps Overview - Kubernetes Code Build Test Release Unit Integration Hook Commit PR Package Dev, Stage Production ERROR Review Develop LGTM! Registry CI マニフェストファイルのアプリ更新 (e.g. イメージタグ更新) PR K8sマニフェスト
43. @capsmalt 43 GitOps やってみた
44. 44 デモ環境 Developer Travis CI App Repo IBM Cloud Container Registry IBM Cloud Kubernetes Service Manifest Repo Weave Flux GitHub Sync Build Commit Push Watch Pull
45. 45 デモ① • Kubernetesクラスター上で動くチャットボットをGitOpsをつかってリリース - マニフェストは⼿動で更新することもできるが，⾃動化した⽅がベター - CIツールが⾃動的にマニフェストを更新してプルリクエストを作成 Cluster Developer CI Tool App Repo Image Registry 1. Pull Requestのマージ 2. イメージのビルドとPush Manifest Repo GitOps operator 3. Pull Requestの⾃動作成 5. イメージの デプロイ 4. マニフェストの更新の検知 6. Pull 4. Pull Requestのマージ
46. 46 デモ② • GitOpsとChatOpsを使い，カナリアリリースを⾏う • カナリアリリースとは • 新しい機能を⼀部のユーザー（カナリア）へ先⾏してリリース • リリースのスピード感と，不具合による影響の低減を両⽴するためのリリース⽅法 v1 v2 80% 20% ⼀定の割合のユーザーを 新しいバージョンへ振り分け v1 v2 特定のユーザーを 新しいバージョンへ振り分け Beta版テストに 同意したユーザーなど 今回のデモでは 振り分けにIstio を使ってます
47. 47 デモ② • 評価が良ければ全体へ公開 • 問題が発⽣したらロールバック（カナリアをクローズ） Manifest Repo IBM Cloud Kubernetes Service GitOps Operator chatbot 1. 対応を bot と会話 2. botがリポ ジトリを更新 3. Operatorが クラスターを 更新 ChatOps GitOps 1. 対応を bot と会話
48. 48 以下は⼩話
49. 49 代表的なGitOpsツール • Weave Flux - helmに対応 - イメージの更新を検知する機能がある - 削除には未対応 - どちらかと⾔えばクラスター全体の設定を管理するイメージ • Argo CD - Web UIがある - いろいろなフォーマットに対応 • helm，ksonnet，kustomizeなど - 削除にも対応 - どちらかといえば個々のアプリケーション単位で管理するイメージ • 他にも・・・ - Spinnaker，Jenkins X - kubectl diff，kubectl applyを使って⾃前スクリプトで実装することも可能
50. 50 Cluster Weave FluxのAuto Deploy機能 • Weave Fluxがイメージレジストリを監視し，新しいイメージが登録されたら，⾃動的に クラスターにデプロイし，マニフェストも更新してリポジトリに登録する • アプリ毎に有効/無効が選択可能 Developer CI Tool App Repo Image Registry 1. Pull Requestのマージ 2. イメージのビルドとPush Manifest Repo Weave Flux 3. 新しいイメージの検知 5. イメージの デプロイ 4. マニフェストの更新 6. Pull
51. 51 GipOpsをやる上での考慮点 • 使⽤するツールの選定 - Weave Flux，Argo CD，Jenkins X，SpinnakerなどのGitOpsツール - 差分検知を⾏うkubediffや，kubectl applyを使って作り込むことも可能 • レプリカ数 - Horizontal Pod Autoscaler(HPA)を利⽤している場合は注意が必要 • 機密情報 - SecretをGit管理するのは適切ではない - SealedSecretやクラウドが提供するKMSを利⽤して保護する • リソースの削除や名前変更 - 削除には未対応 - GitOpsツールによって対応しているものもある - 変更できないリソースや属性に注意 - 名前を変えてしまうと重複してしまったり・・・ • 環境毎にブランチ／ディレクトリ／リポジトリをどのように分けるのか，リポジトリの運⽤とクラス ターへのデプロイ戦略をよく考える必要がある
52. 52 ChatOps︓ビジネスチャットの普及 • 先進的なWeb企業を筆頭に，社内コミュニケーションの中⼼がビジネスチャットへと移りつつある - 即時性 - テーマを絞った議論が⾏いやすい • 例えばSlackだとテーマ別に「チャネル」を⽤意することで興味のある⼈が集まる - 会話の履歴を共有しやすい • もうなるべくメールは開きたくない - SlackでできることはSlackでやりたい Software Design 2016年1⽉号
53. 53 ChatOpsとは • DevOpsツールや運⽤ツールの情報をチャットに集約し，チャットをインターフェースとして各種の操 作を可能にすることで，システムの開発や運⽤の効率化や⾃動化を⽬指すプラクティス chatbot &
54. 54 ChatOpsの適⽤レベル 適⽤前︓ 臨機応変に直接， ⼈同⼠でコミュ ニケーション レベル１: Slackを使うよう になる。重⼤情 報専⽤のチャネ ルを作る。コラ ボレーション ツールで作業を 可視化するよう になる。 レベル2a︓ モニタリング ツールがコラボ レーションツー ルへ通知を⾏う ようになる • イベントの⾃動通 知，インシデント の解決時に通知 レベル2b: ⼿動でコラボ レーションツー ルからモニタリ ングツールの情 報を参照できる ようになる • 構成管理DB （CMDB）の検索， チケットシステム の検索，メトリッ クの検索 レベル3: コラボレーショ ンツール経由で モニタリング ツール同⼠が⾃ 動で連携するよ うになる • チケットやイベン トのステータスの 更新，runbookを実 ⾏して応答を表⽰ レベル4 Botが⼈間やツー ルとコラボレー ションツール内 でやり取りする ようになる • 会話をチケットシ ステムへ繋ぐ， キーワードをモニ ターして更新を返 す，ナレッジベー スの更新など レベル5︓ 認知機能のある 賢いBotになる • 履歴やナレッジを 元にした解決策の 提⽰を⾏う
55. 55 ChatOpsとGitOpsのすすめ • ChatOpsとGitOpsは相性が良い - テキスト処理とGitリポジトリへの操作というお決まりのパターンの操作だけでアプリのデプロイや設定変更ができる • 普段アプリを開発しない⼈にもおすすめのチャットボット開発 - チャットのUIを利⽤するため，UIの開発の必要がなく，処理の内容に集中できる - チャットボットフレームワークを利⽤し，⾃動化したい処理⾃体はシェルスクリプトでも記載可能 • いろいろなところで動かせるチャットボット - Kubernetes上で動くPodとして - Serverless - Cloud FoundryやHerokuなどのPaaS - VMやベアメタル chatbot レンジャー
56. 56 おうちKubernetesクラスター • ラズパイでKubernetesクラスタを構築する - https://qiita.com/sotoiwa/items/e350579d4c81c4a65260
57. 57 CKA/CKAD • Certified Kubernetes Administrator (CKA) 受験ログ - https://qiita.com/sotoiwa/items/3509ca3d18d1bed00dee • Certified Kubernetes Application Developer (CKAD) 受験ログ - https://qiita.com/sotoiwa/items/70cf93ebe2718a3be6b3
58. 58 CNCFグッズ
59. 59 以下はバックアップ資料
60. 60 GitOps︓Kubernetesを使い始めて感じた悩み・・・ • Kubernetesでは1つのアプリをデプロイするのに⼤量の yaml（Kubernetesマニフェスト）が必要 • yamlを書いてkubectl applyしたけど，このyamlはどこで 管理しよう︖ • アプリのソースコードと⼀緒にyamlをGitリポジトリで管 理しよう︕ • CIツール（Jenkinsなど）からアプリをデプロイできるよ うにしよう︕ kind: PersistentVolume kind: PersistentVolumeClaim kind: ConfigMap kind: Secret kind: Ingress kind: Service kind: Deployment apiVersion: apps/v1 metadata: name: liberty spec: selector: matchLabels: app: liberty replicas: 1 ・・・
61. 61 CIOps（ ≠ GitOps）では解決しない悩み • CIツールが直接Kubernetesへアプリをデプロイする - だれかが⼿動で設定変更しているかもしれない - リポジトリのマニフェストがクラスターに適⽤済みかわからない →リポジトリのマニフェスト＝クラスターの状態を保証できない - CIツールが強⼒な権限を持っていてセキュリティリスクとなる - マニフェストを少し変更しただけなのに，アプリのビルドが⾛る Developer CI Tool App & Manifest Repo Image Registry Cluster RW RO RW RO RW RW CI/CD
62. 62 GitOps︓Weaveworks社が提唱するKubernetesにおけるContinuous Deliveryのプラクティス • CIとCDを分離する - アプリのリポジトリとマニフェストのリポジトリを分ける - GitOps operatorがリポジトリのマニフェストとクラスターの状態を⼀致させる（Gitリポジトリが正） - ⼿動/CIツールによるkubectl apply（アプリの変更）は⾏わない - 変更はGit上でPull requestオペレーションにより⾏う - CIツールはクラスターへのwrite権限を持たない - マニフェストの変更ではアプリのビルドは⾛らない Developer CI Tool App Repo Image Registry Cluster RW RO RW RO RW Manifest Repo RW GitOps operator RO RW CI CD
63. 63 デモ準備 • Slack - #ise-devops-demoチャンネルを開く • ターミナル - Kialiをポートフォワードする - 正常リクエスト - エラーリクエスト - チャットボットリポジトリ - Webアプリリポジトリ • ブラウザ - Chromeをデフォルトブラウザにする - リポジトリ - Kialiをいい感じに表⽰しておく - Webアプリ開いとく
64. Happy Kubernetes Life !! Happy Kubernetes Life !! 64