[k8s] gitops 전략

#Kubernetes

gitops는 git 기반으로 인프라 전체의 상황을 제어한다는 접근방법이다.
쿠버네티스를 사용할 경우에는 대부분 이 접근법을 기본으로 깔고 시작한다.

일단 이 전략에서 기본이 되는게 ArgoCD 같은 쿠버네티스 전용 yaml 배포 도구다.
본적이 없거나 잘 모른다면 별도 포스트를 참고한다.
https://blog.naver.com/sssang97/223112272539

저걸 사용해서 git 기반으로 쿠버네티스 리소스를 정의하고 수정-관리하는게 핵심 원리 중 하나다.

그림으로 표현하면 이렇다.
정확하게 따지면 ArgoCD가 github을 바라보는거긴 한데... 아무튼 순서와 흐름으로 보면 이렇다.

여기서 Github같은걸 단일 Truth 소스(SSOT)라고 부른다.
별 의미는 없는 설정놀이인데, 구성 파일을 단일 지점에서 중복되지 않게 관리한다는 측면을 부각하는 것이다.

앱 배포

단순한 인프라 차원의 변경사항은 그냥 infra 코드를 수정해서 ArgoCD를 타게 한다고 치자.
그러면 애플리케이션의 배포는 어떻게 하면 좋을까?

일단 기본적으로 쿠버네티스는 컨테이너 기반으로 배포를 수행하기 때문에, 아래와 같은 형태가 기본이 된다고 할 수 있다.
코드를 수정하면 Github Action 같은 파이프라인 도구를 사용해서 소스코드를 docker로 말아서, 도커 저장소에 push하는 것이다.

이미지 레지스트리는 docker 공식, AWS ECR, github 등등이 많은데, 요즘은 github에서 제공하는 ghcr가 핫한 것 같다. 저렴하고 호환성도 좋다나.

근데 이미지를 올렸다 치자. 그러면 이미지의 변경사항을 쿠버네티스에 어떻게 반영해야할까?
여기에는 관점에 따라 2가지 접근법이 있는듯하다.

이걸 Push 방식의 gitops라고 부른다.

Github Action 등의 CI 프로세스에서 도커 이미지를 푸시하고, 푸시가 끝나면 infra 코드의 도커 이미지 버전을 업데이트해서 새 변경사항이 배포되도록 유도하는 것이다.

근데 뭐... CI가 너무 많은 것을 제어한다는 점에서 보안적으로 좋지 않다는 시각도 있는듯하다.
그렇다면 다음 방법을 사용하면 된다.

이걸 Pull 방식의 gitops라고 부른다.

쿠버네티스 클러스터 내에서 직접 컨테이너 이미지의 변경을 직접 감시해서, 변경이 일어나면 배포를 수행하도록 하는 방법이다.
이런걸 해주는 도구로는 ArgoCD Image Update 등이 있다.

근데 뭐 상태관리가 무조건 컨테이너의 이미지 버전일 필요도 없고, 직접 만들어도 되긴 한다.

이걸 그림으로 표현하면 이런 식이 된다.

docker registry라는 상태를 중심으로 두고 CI와 CD가 독자적으로 동작하는게 다른 점이다.
그래서 보안적으로는 조금 더 나은 구성이라고 할 수 있다.

gitops라는 개념을 처음 제안한 weavework에서도 이러한 방법을 권장한다고 한다.