[Kubernetes] ArgoCD

개념

Argo CD 란?

• Manifest(yaml) 파일의 변경 사항을 감시하며, 현재 배포된 환경의 상태와 Manifest(yaml) 파일에 정의된 상태를 동일하게 유지하는 역할을 수행한다.
• 한마디로 Argo CD는 쿠버네티스를 위한 CD 툴이라고 할 수 있다.
• GitOps는 DevOps의 실천 방법 중 하나로 애플리케이션의 배포와 운영에 관련된 모든 요소들을 Git에서 관리한다는 뜻이다.

컴포넌트

❯ kubectl get deploy
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-applicationset-controller   1/1     1            1           65s
argocd-dex-server                  1/1     1            1           65s
argocd-notifications-controller    1/1     1            1           65s
argocd-redis                       1/1     1            1           65s
argocd-repo-server                 1/1     1            1           65s
argocd-server                      1/1     1            1           65s

❯ kubectl get statefulset
NAME                            READY   AGE
argocd-application-controller   1/1     54m

API Server

• 웹UI/CLI에서 사용하는 API를 노출하는 gRPC/REST 서버이다.
• 다음과 같은 기능을 한다.
  • 애플리케이션 관리 및 상태 보고
  • 애플리케이션 작업 호출 (예: 동기화, 롤백, 사용자 정의 작업 등)
  • 레파지토리 및 클러스터 자격 증명 관리 (k8s secret으로 저장됨)
  • 외부 ID 공급자에 대한 인증 및 인가 위임
  • RBAC 시행
  • git 웹훅 이벤트용 리스너/포워더 기능

Repository Server

• 애플리케이션 매니패스트를 보관하는 git 레파지토리의 로컬 캐시를 유지 관리하는 내부 서비스이다.
• 다음 입력이 제공된 경우 쿠버네티스 매니패스트를 생성하고 반환하는 역할을 한다.
  • 저장소 URL
  • 리비전 (commit, tag, branch)
  • 애플리케이션 경로

Application Controller

• 실행 중인 애플리케이션을 지속적으로 모니터링하고 현재 라이브 상태를 원하는 대상 상태(repo에 지정된 대로)와 비교하는 쿠버네티스 컨트롤러입니다.
• OutOfSync 애플리케이션 상태를 감지하고 조치를 취합니다.
• argocd-application-controller는 argocd-repo-server를 사용하여 생성된 매니페스트를 가져오고 쿠버네티스 API 서버를 사용하여 실제 클러스터 상태를 가져온다

ETC

• notification controller (deployment)
  • ArgoCD 응용 프로그램을 지속적으로 모니터링하고 프로그램 상태의 중요한 변경 사항을 사용자에게 알릴 수 있도록 제공한다
• dex server (deployment)
  • GitHub, SAML 등과 같은 외부 ID 공급자에게 인증을 위임하는데 사용할 수 있다
• argocd-redis (deployment)
  • redis 없이 Argo CD를 실행했을 때 에러 발생
  • 그러나 자체 Redis를 사용하도록 선택할 수 있다

설치

https://github.com/argoproj/argo-cd/tree/master/manifests

https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/

Argo CD는 multi-tenant와 core 두 가지 설치 유형이 있다.

Multi-Tenant

멀티테넌트 설치는 ArgoCD를 설치하는 가장 일반적인 방법이다. end-user는 웹 UI 또는 argocd CLI를 사용하여 API 서버를 통해 Argo CD에 액세스할 수 있다.

두 가지 유형을 설치 매니페스트가 제공된다.

[Non High Avaliable]

• 프로덕션 용도로는 권장되지 않는다.
• 일반적으로 데모 및 테스트를 위한 기간동안 사용된다.
• install.yaml - 클러스터 관리자 액세스 권한이 있는 표준 Argo CD 설치. Argo CD가 설치된 클러스터에 애플리케이션을 배포하려는 경우 해당 매니페스트 사용. 자격증명이 있다면 외부 클러스터에 배포할 수도 있다.
• namespace-install.yaml - 네임스페이스 수준의 권한만 필요한 Argo CD 설치. Argo CD가 설치된 클러스터에 애플리케이션을 배포하지 않고, 자격증명에만 의존하는 경우 해당 매니페스트 사용.
  • Argo CD CRD는 namespace-install.yaml에 포함되지 않기 때문에 따로 설치해야 한다.

[High Available]

• 고가용성 설치는 프로덕션 용도로 권장된다.
• 동일한 구성 요소를 포함하지만 고가용성 및 복원력을 위해 조정되었다.
• ha/install.yaml - install.yaml과 동일하지만 지원되는 구성 요소에 대한 여러 replicas가 있다.
• ha/namespace-install.yaml - namespace-install.yaml과 동일하지만 지원되는 구성 요소에 대한 여러 replicas가 있다.

Core

Argo CD를 독립적으로 사용하고 멀티테넌시 기능이 필요하지 않은 클러스터 관리자에게 가장 적합하다.

이 설치에는 더 적은 수의 구성요소가 포함되며 설치가 더 쉽다. API 서버 또는 UI를 포함하지 않으며 각 구성 요소의 경량 버전을 설치한다. (ha 지원 안됨)

• 웹 UI는 argocd admin dashboard 명령어를 통해 사용할 수 있다.
• core-install.yaml

설치 방법

1. ArgoCD 설치

# ArgoCD 설치 - https://argo-cd.readthedocs.io/en/stable/getting_started/#1-install-argo-cd
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# ArgoCD CLI 설치
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64

2. 외부 접근 설정

Argo CD 설치 시, 기본적으로 외부 주소로 노출되지 않기 때문에 외부에서 접속할 수 있게 노트포트로 적용한다.

# NodePort
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "NodePort"}}'

# LoadBalancer
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

# Port Forwarding
kubectl port-forward svc/argocd-server -n argocd 8080:443

3. ArgoCD 로그인

# admin의 초기 비밀번호 조회
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

# 로그인 명령
argocd login <ARGOCD_SERVER>

# 비밀번호 변경
argocd account update-password

사용법

Repository 등록

1. Repository 등록

2. git 정보 입력

3. 등록이 완료 후 connection status가 succesful인지 확인

Application 등록

[Application이란?]

메니페스트에 의해 정의된 Kubernetes 리소스 그룹이며 CRD(Custom Resource Definition) 입니다.

$ kubectl get application -A

NAMESPACE   NAME      SYNC STATUS   HEALTH STATUS
argocd      gitbook   Synced        Healthy

application crd yaml

$ kubectl get application gitbook -n argocd -o yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  creationTimestamp: "2023-01-12T05:19:17Z"
  generation: 54
  name: gitbook
  namespace: argocd
  resourceVersion: "96960577"
  selfLink: /apis/argoproj.io/v1alpha1/namespaces/argocd/applications/gitbook
  uid: 5c67d1d4-e784-439c-a5da-871f2ce78847
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: .
    repoURL: 
    targetRevision: argocd
  syncPolicy:
    automated: {}
status:
  health:
    status: Healthy
  history:
  - deployStartedAt: "2023-01-12T05:21:33Z"
    deployedAt: "2023-01-12T05:21:34Z"
    id: 0
    revision: a8de2c5d4b2c144734600d960880c76ca3c515df
    source:
      path: .
      repoURL: 
      targetRevision: argocd
  - deployStartedAt: "2023-01-12T05:44:49Z"
    deployedAt: "2023-01-12T05:44:50Z"
    id: 1
    revision: 09597a73af8b2bb28aedc621628ac62fab98b3c8
    source:
      path: .
      repoURL: 
      targetRevision: argocd
  operationState:
    finishedAt: "2023-01-12T05:44:50Z"
    message: successfully synced (all tasks run)
    operation:
      initiatedBy:
        username: admin
      retry: {}
      sync:
        revision: 09597a73af8b2bb28aedc621628ac62fab98b3c8
        syncStrategy:
          apply: {}
    phase: Succeeded
    startedAt: "2023-01-12T05:44:49Z"
    syncResult:
      resources:
      - group: ""
        hookPhase: Running
        kind: Secret
        message: secret/regsecret configured
        name: regsecret
        namespace: argocd
        status: Synced
        syncPhase: Sync
        version: v1
      - group: ""
        hookPhase: Running
        kind: Service
        message: service/gitbook unchanged
        name: gitbook
        namespace: argocd
        status: Synced
        syncPhase: Sync
        version: v1
      - group: apps
        hookPhase: Running
        kind: Deployment
        message: deployment.apps/gitbook configured
        name: gitbook
        namespace: argocd
        status: Synced
        syncPhase: Sync
        version: v1
      revision: 09597a73af8b2bb28aedc621628ac62fab98b3c8
      source:
        path: .
        repoURL: 
        targetRevision: argocd
  reconciledAt: "2023-01-12T06:49:01Z"
  resources:
  - kind: Secret
    name: regsecret
    namespace: argocd
    status: Synced
    version: v1
  - health:
      status: Healthy
    kind: Service
    name: gitbook
    namespace: argocd
    status: Synced
    version: v1
  - group: apps
    health:
      status: Healthy
    kind: Deployment
    name: gitbook
    namespace: argocd
    status: Synced
    version: v1
  sourceType: Helm
  summary:
    images:
    - gitbook:latest
  sync:
    comparedTo:
      destination:
        namespace: argocd
        server: https://kubernetes.default.svc
      source:
        path: .
        repoURL: 
        targetRevision: argocd
    revision: 09597a73af8b2bb28aedc621628ac62fab98b3c8
    status: Synced

[Repository기반 Application 생성]

• 등록된 Repository를 기반으로 Application을 등록한다.
• Application 등록 메뉴얼 링크: https://argo-cd.readthedocs.io/en/stable/getting_started/#creating-apps-via-ui

1. 등록된 Repository에서 Create application 클릭

2. ArgoCD Application 정보 입력

• Name: 애플리케이션 이름
• Project:Argo CD의 CRD(Custom Resource Definition)
• Sync Policy
  • Manual: 수동으로 동기화 됨
  • Automatic: 자동으로 동기화 됨
    • prune(선택): argocd가 git을 감지하지 못할 경우 자동으로 리소스를 삭제하는 옵션
    • self heal(선택): 라이브 클러스터 상태가 git에 정의된 상태에서 벗어날 때 자동 동기화 설정 옵션

3. 배포할 리소스가 있는 git 정보 입력

• URL: git 주소
• Revision: 브랜치
• Path: 배포할 리소스가 존재하는 경로

4. 배포될 클러스터에 정보 입력

• Cluster URL: 기본 값은 Argo CD가 설치된 쿠버네티스 클러스터 내부
• Namespace: 리소스가 어떤 네임스페이스에 배포될 것인지 설정

5. 배포된 리소스들의 종류와 각 리소스의 상태를 한 눈에 확인

6. 코드가 변경될 때마다 동기화 되도록 설정

Project

• 공통으로 사용하는 설정을 관리하는 장점과 애플리케이션 권한을 제한하여 안정적으로 Argo CD를 운영할 수 있게 한다.
• default 프로젝트가 기본으로 생성된다 (모든 설정이 풀려있어 애플리케이션을 제한 없이 생성할 수 있다)
• 다음과 같은 주요 정보로 정의된다
  • sourceRepos - 프로젝트 내에서 애플리케이션이 매니패스트를 가져올 수 있는 레파지토리 목록
  • destinations - 프로젝트 내에서 애플리케이션이 배포할 수 있는 클러스터와 네임스페이스에 대한 목록
  • roles - 프로젝트 내 리소스에 대한 액세스 정의가 있는 엔티티 목록

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
  namespace: argocd
# Finalizer that ensures that project is not deleted until it is not referenced by any application
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Example Project
# Allow manifests to deploy from any Git repos
  sourceRepos:
  - '*'
# Only permit applications to deploy to the guestbook namespace in the same cluster
  destinations:
  - namespace: guestbook
    server: https://kubernetes.default.svc
# Deny all cluster-scoped resources from being created, except for Namespace
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
# Allow all namespaced-scoped resources to be created, except for ResourceQuota, LimitRange, NetworkPolicy
  namespaceResourceBlacklist:
  - group: ''
    kind: ResourceQuota
  - group: ''
    kind: LimitRange
  - group: ''
    kind: NetworkPolicy
# Deny all namespaced-scoped resources from being created, except for Deployment and StatefulSet
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: 'apps'
    kind: StatefulSet
  roles:
# A role which provides read-only access to all applications in the project
  - name: read-only
    description: Read-only privileges to my-project
    policies:
    - p, proj:my-project:read-only, applications, get, my-project/*, allow
    groups:
    - my-oidc-group
# A role which provides sync privileges to only the guestbook-dev application, e.g. to provide# sync privileges to a CI system
  - name: ci-role
    description: Sync privileges for guestbook-dev
    policies:
    - p, proj:my-project:ci-role, applications, sync, my-project/guestbook-dev, allow
# NOTE: JWT tokens can only be generated by the API server and the token is not persisted# anywhere by Argo CD. It can be prematurely revoked by removing the entry from this list.
    jwtTokens:
    - iat: 1535390316

[DESTINATIONS 설정]

• 프로젝트에 속한 애플리케이션이 어디 클러스터에 동기화 될 수 있는지를 설정한다.
• 별표(아스타)를 입력하면 모든 쿠버네티스 클러스터에 sync 하도록 설정된다.

[CLUSTER RESOURCE ALLOW LIST 설정]

• 동기화 할 쿠버네티스 네임스페이스와 리소스를 제한한다.
• 별표(아스타)를 입력하면 모든 쿠버네티스 리소스와 모든 네임스페이스에 sync 할 수 있도록 설정된다.

Application

Application은 쿠버네티스 클러스터에 배포될 특정 애플리케이션의 상태를 정의하고 관리하는 리소스입니다.

Application CRD는 다음과 같이 정의돼있으며 두 가지 주요 정보로 정의된다.

• source - git에서 원하는 상태에 대한 참조 (repository, revision, path, environment)
• destination - 대상 클러스터 및 네임스페이스에 대한 참조. 클러스터의 경우 서버 또는 이름 중 하나를 사용할 수 있다. (둘 다 사용하지는 못한다.)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

 

ApplicationSet

• ArgoCD v2.3 부터는 ApplicationSet 컨트롤러가 ArgoCD와 함께 번들로 제공된다.
• ApplicationSet 컨트롤러는 다음을 제공한다.
  • 단일 쿠버네티스 매니페스트를 사용하여 ArgoCD로 여러 쿠버네티스 클러스터를 대상으로 하는 기능
  • 단일 쿠버네티스 매니페스트를 사용하여 ArgoCD로 하나 또는 여러 git 레파지토리에서 여러 애플리케이션을 배포하는 기능
• Argo CD와 연결된 여러 개의 클러스터에 동일한 Application을 배포하는 경우, Argo CD에 이름만 다르고 내용은 같은 Application 3개를 추가해야 한다. 클러스터와 애플리케이션이 많아질수록 이런 단순 반복 잡업이 늘어나기 때문에, 자동화가 미덕인 DevOps의 철학과는 맞지 않는다. Argo CD에서 이런 문제를 해결할 수 있도록 제공하는 Custom Resource가 바로 ApplicationSet이다.
• ApplicationSet은 비슷한 구성의 Application을 하나의 Template으로 만든 뒤, 파라미터로부터 여러 개의 Application이 생성되는 일종의 Factory라고 볼 수 있다.
• Web UI에서는 ApplicationSet을 조회하거나 생성할 수 없다.

ApplicationSet resource

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - list:
      elements:
      - cluster: engineering-dev
        url: 
      - cluster: engineering-prod
        url: 
      - cluster: finance-preprod
        url: 
  template:
    metadata:
      name: '{{cluster}}-guestbook'
    spec:
      project: my-project
      source:
        repoURL: https://github.com/infra-team/cluster-deployments.git
        targetRevision: HEAD
        path: guestbook/{{cluster}}
      destination:
        server: '{{url}}'
        namespace: guestbook

• 크게 Generator와 Template 영역으로 구분되는 것을 알 수 있다.
• template은 기존 Application의 YAML 파일 양식과 동일한 대신, 일부 필드 값을 렌더링 가능하게 Parameter로 표현하였다.
• Generator는 Application 템플릿의 렌더링에 필요한 Parameter를 생성하는 역할을 담당한다. Argo CD v2.4.3 기준으로 8개 정도의 Generator를 지원하고 있다.
• 현재 ApplicationSet 컨트롤러에서 지원하는 여러 generator가 있다.
  • List generator - 고정된 리스트 기반의 파라미터를 생성한다. API서버를 노출해야 하므로 repo에 올릴 때 주의해야 한다.
  • Cluster generator - Argo CD 내에 정의된 클러스터 기반으로 클러스터 매개변수를 자동으로 생성한다.
  • Git generator - generator resource 내에 정의된 git 레파지토리 내에 포함된 파일 또는 폴더를 기반으로 매개변수를 생성한다.
    • JSON 값을 포함하는 파일은 템플릿 파라미터로 변환된다.
    • git 저장소의 개별 디렉토리 경로도 매개변수 값으로 사용할 수 있다.
  • Matrix generator - 두 개의 다른 generator에서 생성된 매개변수를 결합한다.

Parameter substitution into templates

어떤 generator를 사용하던 상관 없이, generator에 의해 생성된 매개변수는 ApplicationSet 리소스의 template: 섹션 내에서 {{parameter name}} 값으로 대체된다.

파라미터 대체 후 쿠버네티스 클러스터에 리소스가 배포된다:

1. ApplicationSet 컨트롤러는 generator 항목을 처리하여 템플릿 매개변수 세트를 생성한다.
2. 이러한 매개변수는 템플릿으로 대체된다.
3. 렌더링된 각 템플릿은 ArgoCD Application 리소스로 변환되어 생성된다.
4. 마지막으로, ArgoCD 컨트롤러는 이러한 Application 리소스에 대한 알림을 받고 이를 처리할 책임이 있다.

우리의 예에서 정의된 3개의 서로 다른 클러스터 (engineering-dev, engineering-prod, finance-preprod)를 사용하면 각 클러스터에 대해 하나씩 총 3개의 새로운 Argo CD Application 리소스가 생성된다.

# engineering-dev(1.2.3.4) 클러스터에 생성되는 애플리케이션 리소스
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: engineering-dev-guestbook
spec:
  source:
    repoURL: https://github.com/infra-team/cluster-deployments.git
    targetRevision: HEAD
    path: guestbook/engineering-dev
  destination:
    server: 
    namespace: guestbook

각 클러스터에 배포된 모습을 UI에서도 확인할 수 있다.

레파지토리 옵션

옵션	설명
lfs	Git Large File Storage의 약자로 큰 파일을 업로드하거나 다운로드할 때 사용하는 오픈소스 git extension
force HTTP basic auth	HTTP를 통해 저장소에 연결할 때 기본 인증을 강제로 사용할지 여부
proxy	repository(gitlab, github등)를 proxy server와 함께 사용할 경우 필요
skip server verification	https > root ca를 서버에서 검사하지 않겠다는 의미 ssh > StrictHostKeyChecking=no UserKnownHostsFile=/dev/null로 설정한다는 의미

애플리케이션 옵션

https://github.com/argoproj/argo-cd/blob/99d8024a2f8c2f786c774ec7bcc3b4d63e007860/pkg/apis/application/v1alpha1/types.go#L980

1. Deletion Finalizer

• 애플리케이션을 삭제할 때 해당 애플리케이션과 관련된 쿠버네티스 리소스의 finalizer 목록을 통해 삭제에 대한 의존성을 부여한다.
• 계단식 삭제를 하고 싶을 때 선택한다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ''
  finalizers:
    - resources-finalizer.argocd.argoproj.io

2. Sync Options

2.1. Validate

• 애플리케이션 매니페스트에 대한 YAML 스키마의 유효성 검사를 건너뛴다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - Validate=false

2.2. Selective Sync

auto sync를 사용하여 동기화할 때 ArgoCD는 Application의 모든 개체를 적용한다. 수천 개의 개체를 포함하는 경우 꽤 오랜 시간이 걸리고 API 서버에 과도한 부담을 준다. 동기화 되지 않은 리소스만 동기화하는 선택적 동기화 옵션이다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - ApplyOutOfSyncOnly=true

2.3. Resources Prune Deletion Propagation Policy

기본적으로 외부 리소스는 foreground 삭제 정책을 사용하여 제거된다.

• foreground cascading deletion
  • owner 개체가 deleting 상태가 되면 컨트롤러는 종속 개체를 삭제한다.
  • 모든 종속 개체를 삭제할 후 컨트롤러는 owner 개체를 삭제한다.
• background cascading deletion
  • owner 개체를 먼저 삭제하고, 컨트롤러는 백그라운드에서 종속 개체를 삭제한다.
  • 쿠버네티스는 기본적으로 background 삭제를 사용한다.
• orphaned dependents
  • owner 개체를 삭제할 때 남겨진 종속 항목을 orphan 개체라고 한다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - PrunePropagationPolicy=foreground

2.4. Prune

더이상 git에 추적되지 않는 리소스를 클러스터에서 삭제하도록 지정한다.

2.5. Prune Last

• 리소스 prune 기능이 최종적으로 발생하도록 한다.
• 동기화 작업의 마지막 단계에서 현재 배포된 버전에 없는 리소스를 제거한다.
• 대신 prune과 같이 사용해야지만 의미가 있다. prune last만 선택하고 prune은 선택하지 않으면 아무것도 달라지는 것이 없다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - PruneLast=true

2.6. Replace Resource Instead Of Applying Changes

• 기본적으로 Argo CD는 kubectl apply 를 실행하여 git에 저장된 구성을 저장한다.
• 리소스 사양이 너무 큰 경우에는 kubectl apply가 맞지 않을 수 있다. 이런 경우 해당 옵션을 사용한다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - Replace=true

2.7. Server-Side Apply

• 쿠버네티스의 Server-Side Apply 를 활성화 한다.
• 해당 옵션이 설정된 경우 Argo CD는 kubectl apply —server-side 명령을 사용하여 변경사항을 적용한다.
• Replace=true 가 ServerSideApply=true 보다 우선한다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - ServerSideApply=true

2.8. Fail the sync if a shared resource is found

클러스터에 이미 다른 애플리케이션이 배포한 리소스가 존재하면 동기화에 실패한다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    syncOptions:
    - FailOnSharedResource=true

2.9. Respect ignore difference configs

• 동기화 단계에서 spec.ignoreDifference 속성에서 만들어진 구성을 고려하도록 하는 데 사용된다.
• 해당 동기화 옵션은 리소스가 이미 클러스터에 생성된 경우에만 유효하다.
• 아래 예는 동기화 단계동안 spec.replicas 필드를 무시하도록 ArgoCD 애플리케이션을 구성하는 방법을 보여준다.

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  ignoreDifferences:
  - group: "apps"
    kind: "Deployment"
    jsonPointers:
    - /spec/replicas
  syncPolicy:
    syncOptions:
    - RespectIgnoreDifferences=true

2.10. Create Namespace

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: some-namespace
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

• spec.destination.namespace에 지정된 네임스페이스를 생성하도록 구성하는 방법을 보여준다.
• 해당 옵션을 활성화하지 않으면 네임스페이스가 존재하지 않는 경우 애플리케이션이 동기화되지 않는다.

2.11. Self Heal

동기화 정책이 자동으로 설정돼있더라도, 코드의 변경사항이 있을 경우에만 자동으로 동기화를 반영하고 클러스터의 상태가 깃의 상태와 다를때에는 자동 동기화를 실행하지 않습니다.

예를들어 코드에는 디폴로이먼트 레플리카가 1로 돼있는데 클러스터에서 2로 수정하면 레플리카의 갯수가 1로 줄어들지 않습니다.

그러나 SELF HEAL 옵션을 활성화하면 클러스터의 상태가 항상 깃과 같도록 유지하기 위해 일정 시간마다 비교하여 동기화합니다.

2.12. DryRun

실제로 동기화를 실행하지 않고 kubectl apply --dry-run을 수행하도록 지정한다.

2.13. Retry

값	설명
retry-backoff-duration	최초 retry 전까지 대기하는 시간, 기본은 초 단위지만 2m, 4h등으로 분,시,일 변경 가능 (string)
retry-backoff-factor	Backoff 발생시, 증가하는 duration의 배수를 의미하며 duration=1, factor=2인 경우, 1 → 2 → 4 → 8 → .. 와 같이 늘어남 (number)
retry-backoff-max-duration	Backoff로 대기할 수 있는 최대 시간. limit이 아무리 커도 대기시간이 maxDuration을 초과하면 워크플로는 종료됨
retry-limit	허용되는 최대 동기화 재시작 횟수

syncPolicy:
    syncOptions: []
    retry:
      limit: 2
      backoff:
        duration: 5s
        maxDuration: 3m0s
        factor: 2

3. Sync vs Refresh

종류	설명
Sync	현재 클러스터 상태와 git 레파지토리 상태를 동기화시킨다.
Refresh	소스 변경 여부를 확인하여 변경된 경우에만 메니페스트가 다시 렌더링된다.
Hard Refresh	argocd는 매니페스트를 캐싱하는데, 소스 변경 여부에 관계없이 캐시를 무효화하여 매니페스트를 다시 렌더링하도록 한다.

4. Strategy

종류	설명
hook	동기화를 위해 참조된 리소스를 제출한다. (기본 값)
apply	kubectl apply 를 통해 동기화를 수행하다.
force	kubectl apply에 --force 플래그를 제공하지 여부를 나타낸다. --force 플래그는 Patch시 충돌나고 5번 재시도 했을 때 리소스를 삭제하고 다시 만든다.

메니페스트 타입

타입	설명
Helm	헬름
Kustomize	쿠버네티스 리소스를 변경하지 않고 필드를 재정의하여 새로운 쿠버네티스 리소스를 생성하는 도구이다. helm은 템플릿에 정의된 필드 값만 수정할 수 있지만 kustomize는 새로운 필드를 삽입할 수도 있고 기존 필드 값을 변경할 수도 있다. helm은 버전 관리가 되지만 kustomize는 버전 관리가 없다. - name prefix, name sufix - kustomization.yaml에 들어갈 수 있는 필드값이다.
Directory	디렉토리 유형 애플리케이션은 .yml, .yaml, .json 파일에서 일반 매니페스트 파일을 로드한다. - recurse : 루트에 있는 파일 뿐 아니라 하위 디렉토리에 존재하는 파일도 추적하고 싶을 경우 활성화 - top level arguments : jsonnet(json을 확장한 템플릿 언어) 파일일 경우 사용 가능 - external variables : jsonnet(json을 확장한 템플릿 언어) 파일일 경우 사용 가능 - include : 특정 파일/디렉토리만 포함할 수 있다. argocd app set guestbook --directory-include "*.yaml" - exclude : 특정 파일/디렉토리를 제외할 수 있다. argocd app set guestbook --directory-exclude "config.yaml"