Argo CD Deep Dive

2
Profile:
2019.4にfreee入社
以来ずっとSREやってます
主にKubernetesの構築運用設計やってます
like:
ゲーム
ボードゲーム
リアル脱出ゲーム
trend:
藤原峻輝
SRE
shunki fujiwara @renjikari
プロフィール画像の
トリミング方法

01 はじめに
02 Argo CDとArgo Family
03 コンセプト
04 アーキテクチャ詳解
05 Syncしたときの挙動をコ
ードベースで追ってみる
Agenda

5
今日の話の対象者
Deep Diveと銘うちましたが、前提知識は少なめにK8sについてある程度の知識を持っていれば理
解できるsessionにします。
すでにArgo CDを利用している人にはより詳細な挙動についての解説
そうでない人にも(GitOpsの実装の一つとしての)Argo CDのコンセプトやアーキテクチャについて
解説します

6
今日話さないこと
● argocdに関連する拡張ツール群↓に一応いまあるやつまとめてみました(抜け漏れ勘弁)
● argocd-notifications
○ https://github.com/argoproj-labs/argocd-notifications
● applicationset
○ https://github.com/argoproj-labs/applicationset
○ https://qiita.com/shmurata/items/a6ee4193e2d2c8a2d34c
○ Kind: Applicationを管理するもの
● argocd-operator
○ https://github.com/argoproj-labs/argocd-operator
○ argocd clusterの管理をしてくれるoperator
● argocd-image-updater
○ https://github.com/argoproj-labs/argocd-image-updater
○ まだ若いv0.11.0のとまだサポートされてないパターンある
● Argo CD以外のArgo projects
○ さわりだけ話すけどほぼ話さない

今日のコンセプトは・・・

公式ドキュメントより詳しく

01 はじめに
02 Argo CDとそのコンセプト
03 Argo Familiy
04 アーキテクチャ詳解
05 Syncしたときの挙動をコ
ードベースで追ってみる
Agenda

Argo CDはKubernetes向けの宣言的なGitOpsツール
です。

11
Argo CDはKubernetes向けの宣言的なGitOpsツールです。
アプリケーションの定義/config/environmentは宣言的でバージョンコントロールできるべきです。
Argo CDではApplicationのデプロイやライフサイクルを自動的で監査可能で理解しやすいようにマ
ネージメントしてくれます。
Argo CD

12
Argo CDはKubernetes向けの宣言的なGitOpsツールです。
ArgoCDはGitOps patternを使っています。
GitOps pattern: Git repositoryをapplicationの定義のソースとするやり方
Weaveworks社が提唱しました
GitOps

13
ざっくりした図でArgo CDの流れを把握しまし
ょう(公式のアーキテクチャ図を拝借)
1. Argo CD clusterはK8s上で動いている
2. Argo CDはAPI/Repository/Contollerでできて
いる
3. gitをはじめとするいろんなサービスと連携で
きそう
4. Argo CD clusterから各K8s clusterにデプロイ
している
アーキテクチャ from 公式

14
Argo CDのコアコンセプト
Argo CDではいくつかのK8sリソース、及びGitOpsのための概念とプロセスでコンセプトが実現さ
れています。
なかでも、今回のDeepなDiveに関連するコアなもののみ公式から抜粋 + 補足していきます
● リソース
○ Application/Project
○ API Server
○ Application Controler
○ Repository Server
● 概念
○ Live State
○ Target State
● プロセス
○ Sync
○ Refresh

15
Application/project
● application
○ CRDによって定義されるresouce①
○ 一つのK8s resourceのまとまり。1serviceを1applicationとするのがわかりやすそう
● project
○ CRDによって定義されるresouce②
○ applicationの論理的なgroup
○ 権限(認可)の管理に利用できる
○ projectの中でmanifest deploy先のK8s clusterを指定する。
○ freeeでは基本的に1project = 1K8s clusterの運用をしている
○ appは1つのprojectに所属する
○ projectは複数のappに所属されうる

16
Live State/Target State/Sync/Refresh
LiveState: 現在の実際のstate
Target State: codeで定義されたmanifestのstate. redisにcache可能
Sync: Target StateをK8sにapply(deploy)する
Refresh: Target Stateを最新に更新する

17
API Server
API ServerはgRPC/RESTを受けるserverで、web UI, CLI, その他の外部システムなどからリクエス
トを受け付けます。
● Kind: Deployment
● application の管理とstatus管理
● applicationのoperationのinvoke(発火)
○ sync/rollback/user-defined actions
● repositoryとcluster credentialの管理
● 外部のidentity providersとの認証認可の権限移譲
○ ex) freeeではgithubのteamsでログインできて、権限管理もそれに紐付いている)
● RBAC
● Git webhook events

18
Application Controler
applicationのlive stateとtarget stateの比較を行い、OutOfSyncの状態を検知できます
live stateはK8s APIを叩いて現在の状態を取得します。TargetStateはargocd-repo-serverを使って
manifestをgenerateして取得します
また、lifecycle eventの発火にも責任をもっています(PreSync, Sync, PostSync)

19
Repository Server
repo サーバはgit repositoryから取ってきたapplication manifestsのlocal cacheとして機能していま
す。
以下の要素が入力されればK8s Manifestsを(tepmlateからの場合は生成して)returnしてくれます
- repository URL
- revision (commit, tag, branch)
- application path
- template specific settings: parameters, ksonnet environments, helm values.yaml

20
かなりざっくりした図でArgo CDの流れを把握
しましょう(公式のアーキテクチャ図を拝借)
1. Argo CD clusterはK8s上で動いている
2. Argo CDはAPI/Repository/Contollerでできて
いる
3. gitをはじめとするいろんなサービスと連携で
きそう
4. Argo CD clusterから各K8s clusterにデプロイ
している

22
Argo Workflow:
● Kubernetes-nativeなワークフローエンジン
● DAG(有向非巡回グラフ)も扱える
Argo Rollouts
● Canary release/Blue Green Deployなどのdeployment戦略を可能に
Argo Events
● event関連のツール
● 外部で起きたeventを監視したりあるいはwebhookなどで通知を受けてなにかを実行できる
Argo Family

24
この図、結構ざっくり目
● それぞれの矢印がどこを指してるのかざっ
くりしてる
● Argo CDの中でどんなことが行われているか
省略されている

詳細な図を作ってみました

26
変更箇所
● 外部からのアクセスがどのリソースに来て
いるかをはっきりさせた
● Argo CD内のリクエストの流れの例を書いて
みた
アーキテクチャ詳解図

27
● API Serverが外部からのリクエストを受ける
● 図には書きませんでしたが、その他のgit以
外の連携ツールからの通信もAPI Serverが受
ける
クローズアップ①

28
● Sync
○ UI/CLIからsyncのコマンドが発行される
○ argo-cd serverがsyncされるように
applicationのstateを変更
○ それをapplication Contollerが監視
○ App Clusterにdeploy
クローズアップ②

29
● Refresh(の1パターン)
○ Application ControllerがTarget Stateの
revisionの差分チェック
○ Repository ServiceにManifest要求
○ Repository Serviceがgitからcode とって
きてGenerate Manifestする
クローズアップ③

31
● 先ほど紹介したこの図を実際にAPI callから
コードレベルで追ってみます
● というか実際にはコード読んでこの図を作
りました
○ 詳細なDocないので
Sync時の動作をコードで追う

32
WebUIでSyncボタンを押すとこんな感じでPostを投げています
https://localhost:8080/api/v1/applications/guestbook/sync
ちなみに環境はEKSの検証用クラスタにArgo CDクラスタを作ってportforwardingしています。
Sync時の動作をコードで追う①
APIサーバにリクエストを投げる

33
https://localhost:8080/swagger-ui#operation/ApplicationService_Sync
のようにするとAPI referenceにアクセスできる
Sync時の動作をコードで追う②
APIリファレンス

34
ここからコードの中身ですが一旦API Serverの整理をします
argo-cdの中でAPI Serverのコードはここです
またendpointはすべてprotocol buffersによって生成されています。
ただしクラスター外部からの通信を受け取ることがあるため、ほとんどのendpointでgrpc-gatewayによるhttp ->
gRPCのreverce proxyが設定されています
https://github.com/argoproj/argo-
cd/blob/513d8a4ae07e65e9590783007153043e78cfbeb6/server/application/application.proto#L306
Sync時の動作をコードで追う③
API endpoint

36
cd/blob/513d8a4ae07e65e9590783007153043e78cfbeb6/pkg/apiclient/application/application.pb.gw.go#L816
func request_ApplicationService_Sync_0(...)からclient.syncで
↓
https://github.com/argoproj/argo-cd/blob/master/pkg/apiclient/application/application.pb.go ファイルの
func (c *applicationServiceClient) Sync
↓
func _ApplicationService_Sync_Handlerがよばれ
↓
最終的に
srv.(ApplicationServiceServer).Sync(ctx, req.(*ApplicationSyncRequest)) が呼ばれる
このSyncはユーザが定義した(protobufによって生成されたものでない) func (s *Server) Sync(...)
cd/blob/6262a8c750b27b254c330f9882ff26af7aac672c/server/application/application.go#L1346
Sync時の動作をコードで追う③
grpc gateway ~ sync用function

37
func (s *Server) Sync
↓
argo.goの
func SetAppOperation()
https://github.com/argoproj/argo-cd/blob/6262a8c750b27b254c330f9882ff26af7aac672c/util/argo/argo.go#L448
↓
func (c *applications) Update()
cd/blob/6262a8c750b27b254c330f9882ff26af7aac672c/pkg/client/clientset/versioned/typed/application/v1alpha1/app
lication.go#L109
このUpdateでK8s上のkind:Applicationsをupdateしている
Sync時の動作をコードで追う④
func Sync 〜リソースの変更まで

38
● 今話したのは図のWEBUI ~ Update Stateの
ところ
● Application controllerが実際にsyncするのは
別のコード体系なのでそちらをみていく

39
❯ k get -o yaml application guestbook
apiVersion: argoproj.io/v1alpha1
kind: Application
status:
health:
status: Missing
operationState:
finishedAt: "2021-11-02T18:36:14Z"
message: successfully synced (no more tasks)
operation:
initiatedBy:
username: admin
retry: {}
sync:
dryRun: true
resources:
- kind: Service
name: guestbook-ui
namespace: default
revision: 53e28ff20cc530b9ada2173fbbd64d48338583ba
syncStrategy:
hook: {}
phase: Succeeded
startedAt: "2021-11-02T18:36:14Z"
syncResult:
resources:
- group: ""
hookPhase: Succeeded
kind: Service
message: service/guestbook-ui configured (dry run)
name: guestbook-ui
namespace: default
status: Synced
syncPhase: Sync
version: v1
source:
path: guestbook
repoURL: https://github.com/argoproj/argocd-example-apps.git
application詳解
reconciledAt: "2021-11-03T17:56:05Z"
resources:
- health:
status: Healthy
kind: Service
name: guestbook-ui
namespace: default
status: Synced
version: v1
- group: apps
health:
status: Missing
kind: Deployment
name: guestbook-ui
namespace: default
status: OutOfSync
version: v1
sourceType: Directory
summary: {}
sync:
comparedTo:
destination:
namespace: default
server: https://kubernetes.default.svc
source:
path: guestbook
repoURL: https://github.com/argoproj/argocd-example-apps.git
status: OutOfSync

40
application ControllerはContainer起動時にrunされたときからgo routineでinformerを動かしている
cd/blob/8a6b759c4a8705f30aafa1081e5068819f2abce7/controller/appcontroller.go#L598
func (ctrl *ApplicationController) Run()
informerは k8s.io/client-go/tools/cache で提供されていて、CustomControllerからK8sのリソースに関するeventを
watchできる
informer.AddEventHandler() でfuncを定義していてその中でresouceのadd/update時に次のスライドで説明する
queueにkeyを追加する部分がある
Sync時の動作をコードで追う⑤
application controllerのreconcile roopその1

41
application ControllerはContainer起動時にrunされたときからgo routineでoperationをキュー管理している
func (ctrl *ApplicationController) Run()
ApplicationControllerはapplication get listを行うためのinterfaceやapplicationのstate, stateのCacheなどを持つ構造体
application controllerのreconcile roopその2

42
● syncする場合はprocessAppOperationQueueItem() によって、operationQueueから実際にOperationを取得して
○ https://github.com/argoproj/argo-
● processRequestedAppOperation()にてrequest
● ↑のfuncでSyncAppStateを実行する
cd/blob/8a6b759c4a8705f30aafa1081e5068819f2abce7/controller/sync.go#L46
○ Syncのコマンドだが、実際の実行はargoproj/gitops-engineにまかせている
■ https://github.com/argoproj/gitops-
engine/blob/2565df31d16fd28d34a442072cbb7bcbb7415d33/pkg/sync/sync_context.go#L368
application controllerのOperation実行

43
最後にsetOperationState() などでstate更新を行いlogを出力して一連の流れが完了
Sync時の動作をコードで追う⑥
application controllerのSync後の後処理

44
● Application Controllerの挙動を話した
● application controllerは自発的にmonitorする
のでendpointをもっていない
○ コード上もないし、k get svcしても
application controllerが利用するserviceは
ない
● 今回の話はあくまでSync(すでにrefreshは行
われている想定)
● refreshは自動でn分に一回実行したり、
UI/CLIから明示的にrefreshしたりできる。
● Syncと似たようなQueueで管理されている

46
Argo CDの公式ドキュメントを読んでも詳細なところがわからない部分が多かったのでコードを読
みながら図を書いてみました。CNDTドリブンでしたが実業務にも役立ちそうな話があったのでよ
きでした。
application contollerまわりはコードを読んだだけでは思想を理解しづらい部分があってチームメイ
トに教えてもらいました。:kansha: KubernetesのCustomContollerとしての実装なのでそこと関連
付けられるとコードが読みやすかったです。
実はdex-server(login時の認証まわり)についてなどは省くなどしていて実際にはもっと複雑な図に
なります。
また、redis周りの利用(あるいはどういったものをmemoryに持っていてどういったものをredisに投
げているのかという分類)は読む時間がなかったので、いつか時間があったら再度まとめてみようか
と思っています。
まとめ

Argo CD Deep Dive

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Argo CD Deep Dive

Similar a Argo CD Deep Dive (7)

Último

Último (7)

Argo CD Deep Dive

Notas del editor