Kuberneteの運用を支えるGitOps

1freee 株式会社 
Kubernetes 運用を支えるGitOps 
renjikari

インフラエンジニア(学生アルバイト) -> 
アプリとインフラハイブリット ->  
2019年4月freeeに Eとして入社 
 
好き 
Docker/Kubernetes 
自動化 
I CON(人権ない) 
 
ボードゲームが好きです 
 
 
2
Fujiwara Shunki
@renjikari
藤原峻輝

Overview 
　06　まとめ 
　05　運用上課題、大変なところ 
　04　GitOps 実現方法とfreeeで具体例 
　03　GitOpsと  
　02　freeeとKubernetes 
　01　freeeについて

Kubernetesについて詳しい話 
 
AW EK 自体詳しい話 
 
マイクロサービス/サービスメッシュについて
話 
4
今日話さないこと

GitOpsというもへ興味 
 
K8sを本番環境で使うときに一考してくれた
ら嬉しい 
 
開発者が思い思いにkubectl applyする世界
が怖くなってきたころに思い出してくれたら 
5
今日持って帰って
ほしいこと

freee Kubernetes基盤本番に耐えうる運
用がされています 
 
最近freeeに入社してフラットな視点でみれ
る僕がそれら知見をできるだけ共有した
いと思っている 
 
ぶっちゃけKubernetes難しいで難しい問
題にぶち当たったとき解決一助になれ
たらうれしい 
6
僕モチベーション

01 freeeについて 
Section

9
スモールビジネスを、 
世界主役に。 
MI ION 
生産年齢人口が劇的に減少し、慢性的な人手不足となる日本で
労働生産性向上緊急課題となっています
freee 「人工知能」と「統合基幹業務システム」をクラウド技術を
活用し、業務効率化サポートを続けることで、中堅中小企業
バックオフィス業務効率化を目指しています

10
 
PRODUCTS
そ他インターナルなマ
イクロサービス多数

About Products 
❂ 納税する ↗ 育てる ↻ 運営する  ✩ じめる 
会社設立 freee 
開業 freee 
クラウド会計ソフト freee  
人事労務 freee 
(マイナンバー管理 freee 含む)  
クラウド申告 freee 
 
* 2017年8月より、クラウド給与計算ソフト freee 、機能を強化し、「人事労務 freee」というサービス名に変更しました。 
スモールビジネス創業からIPOまで一気通貫でサポートする7つプロダクト
2013.3リリース  2014.5リリース  2015.6リリース 
中小企業経理業務を効率
化。帳簿や決算書作成、請求
業務に対応。 
給与計算や年末調整、入社手
続きから勤怠管理まで労務労
務管理を大幅に効率化。 
会社設立に必要な書類を5分
で作成できる無料サービス。 
2016.10リリース2015.9リリース 2017.1リリース
低コストでマイナンバー収集、管
理、破棄までクラウド上で完結。 
個人事業開業手続きが無料、簡
単、最で完了する。 
税務申告書作成業務を効率化。
法人税・消費税・法定調書・申請
届出や電子申告にも対応。 
Webで申し込みでき、最短4営業日で発
行。創業時でも本人確認書類だけで審査
可能。

12
利用事業所数累計 
 
100万 
 
 
2014.3 2015.3 2016.3 2017.3 2018.3
800,000
600,000
300,000
65,000
1,000,0001,000,000

506人 
 
 
※アルバイト、契約社員、インターンを含む。業務委託、派遣、出向を含めると約700名
従業員数
「働きがいある会社」ランキング  
2019年　4位 
2018年　8位 
2017年 3位 
2016年 4位 
2015年 5位 
 
 
 
※2019年6月末時点

IPO準備・成長企業へ導入が加  
41%
資金調達 op100社  
freee 導入率 
※ 出典：entrepedia ベンチャーリスト
※ 資金調達額TOP100社：直近1年で1億円以上資金調達をした企業を対象に調査

OC保証: 
上場企業が自社財務報告がきちんとしていることを保証するも  
freee(会計ソフト) を利用する場合、freeeも監査対象になる 
OC1を取得していれ freeeが OC保証が満たされていると認められる 
 
相応セキュリティ対策が必要
例え DBに直接アクセスする場合 
認証、認可、履歴管理が必要 
EC2インスタンスからアクセスも
ecurityGroup などで明確に権限管理
できている必要がある

02 freeeとKubernetes 
Section

17
freee kubernetes 変遷 
● 2018.03 本番サービスがKubernetesに乗る
● 2018 Elastic Stack ログ＆監視基盤を整える
● 2019.03 AWS EKSに移行
● 2019.03 デプロイ方法を統一し、GitOpsを全面導入
● 2019.08 ログ＆監視をDatadogに移行
● 2019.10 デプロイ方法 GitOpsとyaml周り
ディレクトリ構を大幅にupdate

freee kubernetes on EK  
18
ELBやRDSなどマネージド
サービスと組み合わせている
 
Pod Pod
Proxy
Pod
AWS
ELB
サービスA 
EK CLuster 
Proxy
Pod
Node 
ユーザアクセス 
Pod Pod
Proxy
Pod
AWS
ELB
サービスB 
EK CLuster 
Proxy
Pod
Node 
ユーザアクセス 
AWS
RDS
AWS
RDS
AWS
ElastiCache
AWS
ElastiCache
Node Node

マルチテナントとシングルテナント 
20
K8s cluster
Product A
Service A-1
Service A-2
Service A-3
Product B
Service B-1
ServiceB-2
Service B-3
Product C
Service C-1
Service C-2
Service C-3
K8s cluster
Product A
Service A-1
Service A-2
Service A-3
K8s cluster
Product B
Service B-1
Service B-2
Service B-3
K8s cluster
Product C
Service C-1
Service C-2
Service C-3
● シングルテナント構成 
 
 
マルチテナント構成

マルチテナントとシングルテナント 
21
K8s cluster
Product A
Service A-1
Service A-2
Service A-3
Product B
Service B-1
ServiceB-2
Service B-3
Product C
Service C-1
Service C-2
Service C-3
K8s cluster
Product A
Service A-1
Service A-2
Service A-3
K8s cluster
Product B
Service B-1
Service B-2
Service B-3
K8s cluster
Product C
Service C-1
Service C-2
Service C-3
● シングルテナント構成 
 
 
マルチテナント構成

22
 
 
 
freee kubernetes シングルテナント！

23
シングルテナント構成 
● Blast radius(障害影響範囲)が小さい 
● セキュリティ境界線明確化 
● クラスタ全体に関係するアップデート作業が
しやすい 
 
 
マルチテナント構成 
● 利用料金が安い 
● 運用コストが安い(一個しかないから) 
 
 
freee kubernetes シングルテナント！ 
それぞれメリットとデメリットを解説

24
シングルテナント構成 
● Blast radius(障害影響範囲)が小さい 
● セキュリティ境界線明確化 
● クラスタ全体に関係するアップデート作業が
しやすい 
 
 
マルチテナント構成 
● 利用料金が安い 
● 運用コストが安い(一個しかないから) 
 
 
freee kubernetes シングルテナント！ 
それぞれメリットとデメリットを解説 
1クラスタあたり影響範囲が狭いで、開発者に
権限移譲できる。
それによって、運用コスト増大を防げる

25
freeeとkubernetes　まとめ 
● freeeで 1サービス 1環境=1クラスタ構成をとっている
○ 正確に同じチームが複数サービスを提供している場合統合している
● それによって開発チームに多く権限を移譲し、自律的な運用を目指
している
● 多数クラスタを管理しないといけなかったりチーム間スキル差と
いった問題も抱えている
○ より開発者が開発に集中できるような運用フローを考えないといけ
ない

GitOpsと from Weaveworks 
28
GitOps can be summarized as these two things:
● An operating model for Kubernetes and other cloud native technologies,
providing a set of best practices that unify deployment, management and
monitoring for containerized clusters and applications.
● A path towards a developer experience for managing applications; where
end-to-end CICD pipelines and git workflows are applied to both operations,
and development.
引用: https://www.weave.works/technologies/gitops/

GitOpsと from Weaveworks 
29
GitOps つまるところ以下 2つ要素からなっている:
● コンテナライズされたクラスターやアプリデプロイ,マネージメント,モニタリングを統
合するベストプラティスセットを提供するKubernetesやそ他クラウドネイティブ技
術へ運用モデル
● アプリケーションをマネージしてきた開発者経験へ道りであるend-to-end
CICDパイプラインや、git workflow 運用と開発どちらにも適応できる
引用: https://www.weave.works/technologies/gitops/

GitOpsと  
30
● 全てリソース変更や運用に対して、コマンドラインを用いず 
git経由から行うことでコードとして履歴管理をしようという思想 
● 開発者が今までやってきたようなアプリ運用プラクティスをすべて
コード管理されたリソースに使えるで  
● 不具合があっても原因追求が行えるうえ、ロールバックが容易

アプリ開発場合を考えてみる 
34
● Git(GitHub)を利用してバージョン管理する
● もとコードへ変更 PRを作ってレビュー => マージ
もしもGitを使わなかったら
● バージョンコントロールできない
● 不具合が発生したときに
○ 前バージョンに戻せない
○ 原因を追求できない

インフラやデプロイされたサービスについて 
考えてみる 
35
● Git(GitHub)を利用してバージョン管理する
● もと状態へ変更 PRを作ってレビュー => マージ
○ もと状態 = もとインフラ構成, デプロイされた状態
もしもGit(GitOps)を使わなかったら
● バージョンコントロールできない
● 不具合が発生したとき
○ 前バージョンに戻せない
○ 原因を追求できない

GitOpsと  
36
● (アプリケーションを含む)全てリソース変更や運用に対して、コマンド
ラインを用いずgit経由から行うことでコードとして履歴管理をしようという思
想
● 不具合があっても原因追求が行えるうえ、ロールバックが容易
● K8s 運用でそういった思想を使おう
○ K8s すべて設定がmanifestとしてコード化されているため

GitOps トレンド 
37
google トレンドを貼る

GitOps トレンド 
38
google トレンドを貼る

GitOpsってどうやる？
GitOpsなにが嬉しい？
40

04 GitOps 実現方法を紹介＆ 
freeeで具体例 
Section

42

GitOps実践ガイドライン (from Weaveworks) 
43
● コードとして記述できるも、すべてGitに保存しなけれならない。
Gitを真実 source of truthとして使用することにより、クラスタを監視
し、目標とする状態と比較することが可能になる。
● Kubernetes CLIツールである“kubectl”を直接使用しない
● オペレータパターンに従ってKubernetesコントローラを使用すること
引用:
https://www.infoq.com/jp/news/2018/11/gitops-weaveworks/

GitOpsをうたうツールたち 
44
● flux
● jenkins-x
● argo-cd
● werf
https://github.com/topics/gitops 
を参考にstar数1000以上もから、  
GitOpsを主題にしていそうなO を抜き出した (2019.11.23 現在)  
ロゴ
https://landscape.cncf.io/category=continuous-integration-delivery&format=card-mode&grouping=category 
https://github.com/flant/werf からそれぞれ引用

flux アーキテクチャ 
45
引用: https://github.com/fluxcd/flux

46

K8s 運用をGitOpsにすると何が嬉しいか 
47
● 集中した権限管理
● kubectlでdeployする必要がない安心感
● 実際に今動いているmanifestがコード上でバージョン管理される

K8s 運用をGitOpsにすると何が嬉しいか(1/3) 
集中した権限管理について
● GitHub上からKickされるCircleCIにさえ権限がついていれ人間につけ
る権限を細分化する必要がなくなる(正確に細分化する必要が薄くなる)

49
集中した権限管理について絵
cluster Aにread write  cluster Bにread write 
cluster Dにread write 
cluster Cにread only 
cluster をread only  clusterをread write 
※わかりやすさために一部正確性 
　が犠牲になっています 
複雑な権限管理  集中した権限管理

50
kubectlでdeployする必要がない安心感
● kubectlでデプロイすると...
○ お手製デプロイフロー
○ オペミス
○ デプロイ自体を管理、記録できない
■ デプロイ記録.xlsx

51
実際に今動いているmanifestがコード上でバージョン管理される
● Kubernetes 特徴である、宣言的なmanifest 記述という点が最大限生
かされる

freee K8s GitOps 構成 
52
② ①で作った各種yamlをGitHubにpush 
③P にてコメント 
`/clusterops deploy ${対象 cluster}` 
④circle ci がkickされる 
⑤circle ci上で helmfile syncコマンドを実行 
(同時にs3に必要なファイルもupload) ⑥helm chartに従って、 
　各種manifestがapplyされる 
①cluster.yamlやhelmfile、helm chartなど各種
yamlをgenerate

freee K8s GitOps 構成要素 
54
● EKS
● GitHub(+Git)
● CircleCI
● eksctl (aws EKS API)
● Helm
● Helmfile
● 自作ラッパーscript(clusteropsコマンド)
○ Helmfileやeksctlをラッパーしている

freee K8s GitOpsが担っていること 
55
● EKS clusterやアプリ helm chartなど yamlをtemplateから自動生成
● EKS cluster 作成
● EKS clusterへデプロイ
● EKS clusterごしにmigration taskなど task実行

56
yamlをgenerate

57
CircleCI
● GitHub上 PRにおけるコメントをトリガーとして、CIをキック
○ clusterops create_cluster ${対象クラスタ}
○ clusterops deploy ${対象クラスタ}
● PRコメントをトリガーすることで反映タイミングをコントロールするために
ChatOpsっぽくしている背景がある
freee K8s GitOps 構成要素を解説

58
eksctl
● AWS EKS API
● eksctl シンプルなEKS cluster作成ため CLI
○ AWS CloudFormationを使っている
● cluster作成に必要なリソースをyamlで統合的に宣言できる
freee K8s GitOps 構成要素を解説 
eksctl: https://github.com/weaveworks/eksctl 
ちなみにこれもWeaveworks/eksctl

59
Helm
● K8s clusterにinstallするもを管理できるパッケージマネージャー
● K8sオブジェクトを宣言するmanifestなど YAMLファイルをパッケージン
グしたファイル「Chart(設計図)」を「Release」することでK8s上で利用可能
にする
● よく使うも helm/stableとしてすでに用意されている
○ helm install <チャート名> ようにK8s Clusterにinstallできる

60
Helmfile
● Helm Chartをより使いやすくデプロイできる、Helm releasesを管理する
ツール
○ helm chartを自作した場合、それをhelmfile syncするだけですぐに
releaseが作成できる
○ 変数をvalues.yamlで管理しているstableなchart 場合、ど stableな
chartを使っているかを含めてfileに書ける

61
自作ラッパーscript(clusterops)
● Helmfileやeksctl(EKS Cluster 管理ため CLI)をさらにラッパーして
いる
● また、Kuberntes Cluster作成ため Cluster.yaml template作成や複
数クラスタ管理ためディレクトリ管理機能も一緒についている
● variantというOSSを利用して書いている
○ variant: https://github.com/mumoshu/variant

62
yamlをgenerate

63
③circle ci がkickされる 
④circle ci上で helmfile syncコマンドを実行 
yamlをgenerate 
$ bin/clusterops -v generate cluster  
--cluster-name integration-hoge-1  
--aws-account-name hoge 
 
↑generate ため  
　コマンド(例) 
→ 
generateしたとき directory
構成(例)

64
(同時にs3に必要なファイルもupload) ④helm chartに従って、 
yamlをgenerate 
deploy とき  
おおもとになる
helmfile 例

65
yamlをgenerate 
deploy とき  
おおもとになる
helmfile 例

66
yamlをgenerate 
アプリ個別  
helmfile 例

67
yamlをgenerate 
アプリ個別  
helmfile 例

68
yamlをgenerate

69
yamlをgenerate

70
/clusterops deploy ${対象 cluster} 
yamlをgenerate 
ちなみに
こ PR コメントでフローを見るとちょっとChat
Opsっぽさもありますが、
● すべてデプロイ情報まずGitにpushさ
れる
● K8s用 git repositoryとアプリ用 git
repository 完全に別れている
といったところからGitOpsという名前で呼んで
います

71
yamlをgenerate 
.circleci/config.ymlに記述したとおりに、
kickが走る。
④circle ci  
　kickされる

72
④helm chartに従って、 
yamlをgenerate 
⑤circle ci上で helmfile syncコマンドを
実行 
 
(create cluster とき eksctlを実行して
る)

73
yamlをgenerate

05 運用上課題、大変なところ 
Section

75
yamlをgenerate

freee K8s GitOps 構成要素 
76
● EKS
● GitHub(+Git)
● CircleCI
● eksctl (aws EKS API)
● Helm
● Helmfile
● 自作ラッパーscript(clusteropsコマンド)
○ Helmfileやeksctlをラッパーしている

課題 
77
● 複雑な構成でキャッチアップが大変。
○ 運用コストを開発者が払う構図になっている
● アンケートを取ったところ
○ 半数チームが統一化されたGitOpsで運用してる
○ 4割チームが半分くらい GitOps使ってて、半分くらい手動デプロイ(localか
らhelmfile sync)している
○ 1割チームがSRE GitOpsに乗っかれていない
● 自作にしろ、OSSをいれるにしろ、ネット上で簡単に情報が手に入らない。
最初オンボーディングやトラシューについて学んでもらうに課題があ
る

06 まとめと展望 
Section

まとめ+今後展望 
79
[まとめ]
freeeでできるだけ開発者に権限移譲をし、またすべてデプロイや変更
履歴を残すためにGitOpsを行っている
[展望]
もっと複雑性をさげてよりdeveloperがアプリ開発に集中するため仕組みを
つくっていきます！

スモールビジネスを、 
世界主役に。

Kuberneteの運用を支えるGitOps

More Related Content

Kuberneteの運用を支えるGitOps