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