Argo CD

**Argo CD

1.GitOps

1)정의

=>Pull Request를 이용한 운영

=>버전 제어나 CI/CD를 인프라 자동화에 적용하는 것

2)원칙

=>선언적 구성

- 엔지니어가 원하는 의도된 상태를 명시하지만 이를 위해 실행하기 위한 구체적인 행동은 명시하지 않음

- 컨테이너를 3개 만들어야 한다면 컨테이너를 3개 만들라고 명령을 내리는 것이 아니라 컨테이너를 3개 만들라고 선언만 하면 에이전트가 3이라는 숫자를 맞춰주는 방식

 

=>버전이 제어되는 불변적 저장소

- Git 과 같은 소스 제어 시스템을 사용하는 것을 권장

 

=>자동화된 배포

- 변경 사항이 버전 제어 시스템에 반영되면 어떠한 수동 작업도 수행하지 말아야 한다는 의미

- 설정이 업데이트된 이후에는 소프트웨어 에이전트가 새롭게 설정한 값이 제대로 반영되었는지 확인

 

=>소프트웨어 에이전트

 

=>폐쇄 루프

 

3)Kubernetes 와 GitOps

=>HTTP REST API

- HTTP REST API 관점에서 Kubernetes를 보면 REST API 엔드포인트와 상태를 저장하는 데이터베이스(etcd)를 가진 전형적인 애플리케이션

- 고가용성을 위한 웹 서버 레플리카를 두는 구조

 

4)명령형 API 와 선언형 API

=>명령형 API

- 네임스페이스 생성

kubectl create namespace test-namespace

 

kubectl get namespace test-namespace

 

- 구성 파일 이용

namespace.yaml 

 

apiVersion: v1

kind: Namespace

metadata:

  name: imperative-config

 

 

kubectl create -f namespace.yaml(구성 파일을 이용하는 명령형 API)

 

 

=>선언형 API

kubectl apply -f namespace.yaml(구성 파일을 이용하는 선언형 API)

- 이전 상태 와 비교해서 변경된 내용이 있으면 적용

 

2.Arge CD

1)개요

=>예전에는 애플리케이션은 개발, 테스트, staging, production으로 환경을 구분해서 동작

=>쿠버네티스에서는 이렇게 환경을 분리하고자 할 때 환경 별로 별도의 쿠버네티스 클러스터를 사용하던가 하나의 클러스터 안에 네임스페이스로 구분

=>네임스페이스를 분리하는 방식은 네임스페이스를 새로 만들고 애플리케이션을 구성하는데 필요한 모든 환경(Configmap, Secret, Ingress 등)을 추가

=>위와 같은 방식의 단점은 시간이 지나면서 구성 드리프트가 발생

개발 환경 클러스터 네임스페이스에만 최신 버전의 애플리케이션이 배포되거나 네트워크 정책과 같은 리소스를 수정하게 되면 나머지 다른 환경을 개발 환경 과 동일하게 맞추기 위해서 다른 부분을 확인해서 수동으로 변경을 해야 합니다.

=>위와 같은 부분을 단순화하기 위해서 Helm, Kustomize 와 같은 패키지 매니저를 사용해서 애플리케이션 리소스를 재활용하고 하나의 단일 지점처럼 관리

헬름을 사용하면 여러 버전을 만들고 각 환경에 맞는 원하는 버전을 배포할 수 있습니다.

이 방식은 이력을 추적하기 어렵고 관리의 복잡성이 증가

=>GitOps 접근 방식을 따르면 깃 레포지토리에 풀 리퀘스트 및 모든 변경인 원천 소스를 보관

컨트롤러를 이용해서 깃 레포지토리의 모든 구성을 자동으로 적용하는 방식을 이용하면 이전 방식의 단점을 보완

=>ArgoCD는 선언적인 쿠버네티스의 GitOps CD 도구

ArgoCD 안에 있는 애플리케이션 컨트롤러가 운영 중인 애플리케이션을 지속적으로 관찰하고 현재 애플리케이션 상태 와 원천 소스인 깃 레포지토리에 작성한 의도한 상태를 비교해서 변경 내용을 적용

=>사용 사례

- 배포 자동화: Git Commit 또는 CI 파이프라인이 동작하고 수동 동기화를 트리거 한 후 Argo CD 컨트롤러는 자동으로 클러스터를 Git Repository에 의도한 상태로 푸시를 하게 되는데 Argo 이벤트 자동화 프레임워크 나 수동적인 요청을 통해서 가능

- 관찰 가능성: Argo CD는 애플리케이션 상태가 깃에서 의도한 상태와 동기화 되어 있는지 식별할 수 있는 UI 와 CLI를 제공하고 Argo CD Notification 엔진을 제공

- 멀티테넌시: 인증을 위한 RBAC 정책을 이용해서 여러 클러스터를 관리하고 배포 가능

=>도구

- Argo CD

- Argo Rollouts

- Argo Events

- Argo Workflows

 

2)핵심 개념

=>조정

- 깃 레포지토리에 담긴 의도한 상태를 현재 상태의 클러스터 와 일치시켜야 하며 필요한 환경에 올바르게 전달하는 것

- 깃 레포지토리에 있는 헬름 차트를 쿠버네티스 yaml로 랜더링을 하고 클러스터의 의도한 상태와 비교하는데 이를 동기화 상태(sync status)라고 하는데 이 때 다르다고 판단되면 자동 혹은 수동으로 kubectl apply 사용해서 적용

- Argo CD는 helm install을 사용하지 않고 kubectl apply 명령을 사용

 

=>용어

- Application: 쿠버네티스 리소스 그룹

- Application Source Type: Helm, Kustomize 등

- Target State: 애플리케이션이 의도한 상태를 의미하며 원천 소스인 깃 레포지토리를 의미

- Live State: 애플리케이션의 현재 상태로 클러스터에 배포된 상태

- Sync State: 현재 상태와 타깃 상태가 일치하는지 확인

- Sync: 쿠버네티스 클러스터에 변화를 적용해 애플리케이션을 타깃 상태로 변경

- 동기화 동작 상태: 동기화 단계에서 작업이 실패인지 성공인지 여부를 확인

- 새로 고침: 깃 레포지토리의 최신 코드 와 현재 상태의 차이점을 비교

- 서비스 상태: 애플리케이션이 요청을 받을 수 있고 운영 중인 상태 인지

 

=>핵심 구성 요소

- API Server

웹 UI, CLI, Argo Event, CI/CD 시스템 같은 다른 시스템과 상호 작용을 위한 역할을 수행

 

- Repository Server

애플리케이션 매니페스트를 보관하는 git repository 로컬 캐시를 유지

 

- 애플리케이션 컨트롤러

애플리케이션의 상태를 지속적으로 확인하고 의도한 상태와 비교

사용자가 생성한 훅을 생명 주기 동안 실행

 

=>Argo CD의 핵심 오브젝트와 리소스

- 애플리케이션: Argo CD는 실제 쿠버네티스 클러스터에 배포하려는 애플리케이션의 인스턴스를 Application 이라고 합니다.

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

 

- AppProject: 애플리케이션을 논리적으로 그룹화

 

- 레포지토리 자격 증명: 실제 운영에서는 대부분 Private Repository를 사용하기 때문에 Argo CD가 해당 레포지토리에 접근하기 위해서는 접근 가능한 자격 증명이 필요한데 쿠버네티스의 Secret 과 ConfigMap을 이용해서 해결

 

aprVersion: v1

kind: Secret

metadata:

  name: private-repo

  namespace: argocd

  labels:

    argocd.argoproj.io/secret-type: repository

  stringData:

    url: git@github.com:argoproj/my-private-repository

    sshPrivateKey: | 

    키값

 

- 클러스터 자격 증명: Secret 가지고 만드는데 레포지토리 자격 증명 과 시크릿 유형이 다르기 때문에 label이 다름

aprVersion: v1

kind: Secret

metadata:

  name: mycluster-secret

  labels:

    argocd.argoproj.io/secret-type: cluster

  stringData:

    url: git@github.com:argoproj/my-private-repository

    sshPrivateKey: | 

    키값

 

=>헬름으로 Argo CD 실행

- 저장소 추가

helm repo add argo https://argoproj.github.io/argo-helm

 

helm repo update

 

- namespace 추가

kubectl create namespace argocd

 

- 설치

helm install argocd argo/argo-cd -n argocd

 

- 서비스 확인

kubectl get svc -n argocd

클러스터 IP로 포트가 개방됩니다.

외부에서 접속하려면 포트포워딩이나 서비스를 LoadBalancer 나 NodePort로 설정하면 됩니다.

 

- 서비스 변경: EC2에서 수행 중이라면 외부에서 접속하고자 하면 NodePort를 이용

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

 

- 초기 비밀번호 가져오기

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

 

- 서비스를 확인해서 External IP를 그리고 NodePort 인 경우는 NodePort 값을 확인

 

=>애플리케이션 배포: nginx 배포

- yaml 파일 생성

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: nginx

  namespace: argocd

spec:

  syncPolicy:

    automated:

      prune: true

      selfHeal: true

    syncOptions:

      - CreateNamespace=true

  destination:

    namespace: nginx

    server: https://kubernetes.default.svc

  project: default

  source:

    chart: nginx

    repoURL: https://charts.bitnami.com/bitnami

    targetRevision: 21.1.23

 

- 배포: kubectl apply -f yaml파일경로

 

=>yaml 파일을 만들지 않고 CLI를 이용해서 배포

- 로그인

argocd login localhost:8080

 

- 명령어

argocd app create nginx --repo https://charts.bitnami.com/bitnami --helm-chart nginx --revision 21.1.23 --dest-server https://kubernetes.default.svc --dest-namespace nginx

 

=>ArgoCD 오토 파일럿을 통해 Argo CD 운영

- 오토파일럿: 깃옵스 와 Argo CD를 쉽게 시작할 수 있도록 해주는 도구

- 깃옵스를 사용해 부트스트랩 Argo CD 애플리케이션을 생성하고 관리할 수 있음

- 깃허브 레포지토리를 짜여진 구조로 세팅해서 새로운 서비스를 추가하고 Argo CD 수명주기에 적용

- 재해 복구에 대비할 수 있고 필요한 모든 유틸리팅 와 애플리케이션에 대한 장애조치 클러스터를 부트스트랩함

- Argo CD 애플리케이션에 대한 시크릿 암호화도 지원

 

3.Argo CD 운영

1)kustomize 설치

=>git hub에 레포지토리를 생성

 

=>resources 디렉토리를 생성

 

=>resources 디렉토리에 네임스페이스 생성을 위한 yaml 파일을 생성하고 코드 작성

apiVersion: v1

kind: Namespace

metadata:

  name: argocd

 

=>루트 디렉토리에 kustomization.yaml 파일을 생성하고 작성

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

namespace: argocd

bases:

  - github.com/argoproj/argo-cd/manifests/ha/cluster-install?reg=v2.1.1

resources:

  - resources/namespace.yaml

 

=>Argo CD 자체 관리 기능 제공

- 클러스터에서 애플리케이션을 관리하는 것 처럼 자기 자신을 애플리케이션으로 관리할 수 있습니다.

- argo CD 애플리케이션은 세부분으로 만들어집니다.

destination 필드는 매니페스트가 적용되는 위치

project 필드는 구체적인 제한 요소(이 애플리케이션은 특정 클러스터 혹은 특정 네임스페이스에만 배포되어야 한다는 제한 요소)

source 필드는 리포지토리의 브랜치와 폴더를 모두 포함해 매니페스트가 존재하는 곳

- yaml 파일 생성

apiVersion: argoproj.io/v1beta1

kind: Application

metadata:

  name: argocd

spec:

  destination:

    namespace: argocd

    server: https://kubernetes.default.sv

  project: default

  source:

    path: 설치파일이 있는 경로(kustomize_installation)

    repoURL: 실제 git hub 경로(https://github.com/itggangpae/kustomize_installation.git)

    targetRevision: master

 

=>설정 변경

- Argo CD 버전 2.1 부터는 새로운 설정 값이 생겨 깃 레포지토리의 신규 업데이트를 확인하는 기본 주기를 변경할 수 있습니다.

- 기본적으로 180초로 설정되어 있음

- timeout.reconciliation 매개변수를 통해 확인 주기를 변경할 수 있습니다.

 

- 이런 확인 주기를 변경하고자 할 때는 resource 디렉토리 와 동일한 위치에 patches 디렉토리를 생성하고 argocd-cm.yaml 파일을 생성하고 작성

apiVersion: v1

kind: ConfigMap

metadata:

  name: argocd-cm

data:

  timeout.reconciliation: 300s

 

- kustomization.yaml 파일을 수정

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

namespace: argocd

bases:

  - github.com/argoproj/argo-cd/manifests/ha/cluster-install?reg=v2.1.1

resources:

  - resources/namespace.yaml

patchesStrategicMerge:

  - patches/argo-cm.yaml

 

- 저 파일을 읽어서 300초마다 한 번 씩 git을 조회

업데이트가 적용이 안될 때는

kubectl rollout restart -n argocd deployment argocd-repo-server

 

=>고가용성 설치

- 구조

API Server

 

Repository Server

 

ApplicationController

 

Redis Cache

 

Dex Server

 

- API Server

UI 또는 CLI 또는 curl 과 같이 사용자 지정 클라이언트로부터 들어오는 요청의 진입점(entry point)

 

API는 상태를 갖지 않으므로 부하에 따라 확장하거나 축소할 수 있습니다.

 

디플로이먼트의 레플리카 수를 변경하기만 하면 고가용성 설치가 가능

 

레플리카 이외에도 ARGOCD_API_SERVER_REPLICAS 환경 변수를 이용해서 현재 사용 중인 레플리카의 수와 동일하헤 맞출 수 있습니다.

이를 이용하면 무차별 패스워드 대입 공격에 대한 제한을 계산할 때 유용

이 값을 3으로 설정하면 30개의 요청이 왔을 때 3개의 인스턴스로 부하가 분산됨

 

argocd-server 디플로이먼트가 3개의 레플리카를 두도록 하는 방법

 

patches 디렉토리에 argocd-server-deployment.yaml 파일을 생성하고 작성

 

apiVersion: apps/v1

kind: Deployment

metadata:

  name: argocd-server

spec:

  replicas: 3

  template:

    spec:

      containers:

      - name: argocd-server

        env:

        - name: ARGOCD_API_SERVER_REPLICAS

          value: '3'

 

kustomization.yaml 파일을 수정

 

patchesStrategicMerge:

  - patches/argo-cm.yaml

  - patches/argocd-server-deployment.yaml

 

 

git hub에 푸시

 

- Repository Server

클러스터에 적용할 리소스를 생성하는 요소

보통은 간단한 매니페스트를 사용하지 않고 Helm, Kustomize 와 같은 템플릿 엔진을 사용

이 구성 요소는 이런 템플릿을 kubectl apply 명령에 적용할 수 있는 매니페스트로 변환시킵니다.

리포지토리 서버는 깃 리포지토리의 내용을 가져와서 헬름, Kustomize 등 어떤 템플릿 엔진을 사용할 지를 판단

템플릿 엔진이 무엇인지 확인 한 후 helm template 이나 kustomze build 명령을 실행해 최종 형태의 매니페스트를 생성

헬름의 경우는 외부 종속성을 가져오기 위해서 먼저 helm dep update 명령을 실행해야 할 수 도 있음

레포지토리 서버 애플리케이션에서는 많은 일 수행

여러 인스턴스를 실행하면 더 많은 매니페스트를 동시에 생성할 수 있습니다.

 

메모리 부족이나 CPU 스로트링으로 인해 컨테이너가 종료되지 않도록 충분히 리소스를 제공해주어야 합니다.

 

Argo CD로 배포되는 애플리케이션이 수천개라면 서버를 10개 이상 만들어야 하고 각 인스턴스에 4-5 개 정도의 CPU 그리고 8기가 이상의 메모리를 할당해야 합니다.

 

변경해야 할 중요 매개변수로는 템플릿 엔진의 제한 시간인데 Argo CD는 헬름이나 Kustomize 명령을 포크하고 이 작업에 대해 90초 제한 시간을 설정

가끔 kustomize가 큰 원격 베이스를 사용하거나 헬름이 kube-prometheus-stack 이나 Istio 와 큰 차트를 템플릿화 해야 하는 경우가 있는데 이런 경우 제한 시간에 걸려서 작업을 완료하지 못하는 경우가 있습니다.

ARGOCD_EXEC_TIMEOUT 환경 변수 사용

 

- patches 디렉토리가 있는 곳에 argocd-repo-server-deployment.yaml 파일을 생성하고 작성

apiVersion: apps/v1

kind: Deployment

metadata:

  name: argocd-repo-server

spec:

  replicas: 3

  template:

    spec:

      containers:

      - name: argocd-repo-server

        env:

        - name: "ARGOCD_EXEC_TIMEOUT"

          value: '3m'

 

kustomization.yaml 파일을 수정

 

patchesStrategicMerge:

  - patches/argo-cm.yaml

  - patches/argocd-server-deployment.yaml

  - patches/argocd-repo-server-deployment.yaml

 

- Application Controller

Argo CD가 애플리케이션을 설치할 클러스터가 9개이고 애플리케이션 컨트롤러가 3개이면 각 컨트롤러는 클러스터를 3개씩 담당

 

- patches 디렉토리가 있는 곳에 argocd-application-controller-statefulset.yaml 파일을 생성하고 작성

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: argocd-application-controller

spec:

  replicas: 3

  template:

    spec:

      containers:

      - name: argocd-application-controller

        env:

        - name: "ARGOCD_CONTROLLER_REPLICAS"

          value: '3'

 

kustomization.yaml 파일을 수정

 

patchesStrategicMerge:

  - patches/argo-cm.yaml

  - patches/argocd-server-deployment.yaml

  - patches/argocd-repo-server-deployment.yaml

  - patches/argocd-application-controller-statefulset.yaml

 

 

- 레디스 캐시

Redis는 Argo CD에서 일회성 캐시로 사용

레디스가 응답하지 않는 경우 그리고 오류가 발생하는 경우 와 설치되지 않은 경우에도 시스템은 동작하지만 성능에 영향을 미칠 수 있음

 

레디스는 선택적 구성 요소지만 사용하는 것을 적극 권장

이유는 깃 레포지토리에 생성된 매니페스트가 레디스 캐시에 보관되는데 레디스가 없다면 동기화 요청 때 마다 매니페스트를 다시 생성합니다.

캐시는 깃 레포지토리에 새로운 커밋이 있는 경우에만 삭제

캐시가 손실되면 모든 것을 다시 만들어야 하기 때문에 애플리케이션은 계속 작동하지만 성능이 저하됨

 

고가용성으로 사용하기 위해서는 레디스용 레플리카 3개를 가진 StatefulSet으로 구성합니다.

 

=>관찰 가능성 활성화

- 프로메테우스로 모니터링을 수행

- 컨테이너 오케스트레이션의 표준이 쿠버네티스 인 것 처럼 프로메테우스도 모니터링의 표준

- 프로메테우스가 CNCF의 두번째 프로젝트

- 프로메테우스가 설치되면 메트릭을 가져올 대상 엔드포인트가 어디인지 알려줘야 합니다.

커스텀 리소스 중에서 ServiceMonitor를 사용

- Argo CD에서는 애플리케이션 컨트롤러, API 서버, Repository Server 세가지 서비스가 스크랩되어야 합니다.

설치 방식은 https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/#prometheus-operator 에서 참고

디렉토리가 하나 제공되는데 그 디렉토리의 내용을 깃에 저장하고 가리키는 애플리케이션을 만들어서 실행하면 됩니다.

 

- 운영팀이 확인할 메트릭

OOMKilled: 메모리 부족에 의한 종료 현상

디플로이먼트나 스테이트풀셋의 레플리카 숫자를 증가

컨테이너의 CPU 와 메모리 리소스를 더 높게  할당

 

시스템 부하 메트릭

 

- 마이크로 서비스 팀이 확인할 메트릭

동기화 상태를 나타내는 메트릭

 

애플리케이션의 운영 상태를 나타내는 메트릭

 

 

=>사용자에게 통지

- Argo CD Notifications 설치해서 수행

- 이메일로 통지: https://blog.argoproj.io/notifications-for-argo-bb7338231604