토스뱅크의 쿠버네티스 기반 CI/CD 환경

관련링크 : https://www.youtube.com/watch?v=gF1wfTCDyI8 

 

주요내용

 

개발 환경 : Testbed, Dev 환경으로 이루어져 있다.

Testbed : 아무런 트래픽 없음(형상조합을 위한 환경인듯)

Dev : 테스트 트래픽 발생

 

 

Live 환경 : 멀티클러스터, Active-Active 운영

DataCenter1에서 Version Blue, DataCenter2에서 Version Green을 운영하고 클러스터 Outside에서 트래픽을 조정하면서(데이터센터 자체의 로드벨런서, Gateway 등을 통해..) Blue/Green 혹은 Carany를 수행하는것으로 보임

 

 

GitOps를 사용하여 형상관리 중

CD : ArgoCD 가 Git Repository의 소스를 지속적으로 Sync 수행함

CI : Github

 

 

App of Apps Pattern(클러스터 Bootstraping) 적용

어플리케이션 및 구성요소의 개별적관리보다는 클러스터 구성요소 및 차트를 모두 비교하면서 자동화 하는 구조를 사용함

 

 

 

Dev, Production 등의 환경설정도 하나의 템플릿에서 Custom Resource를 참고하게 하여 단일 레포지토리 사용

 

시크릿 관리는 Vault로

 

 

토스 GitOps 구조 리뷰

 

장점
정돈된 App-of-Apps 차트 사용으로 가시성 향상
신규 클러스터 구성 속도 향상
서로 다른 클러스터의 예상치 못한 구성 차이 방지
히스토리 추적 가능

단점
쿠버네티스 세팅만으로 배포완료되지 않는 어플리케이션의 경우 배포 내용을 전부 레포지토리에 표현할 수 없음
- 해결방안 : 선언적으로 설정을 완료할 수 없는 스테이트풀 리소스는(Kafka나 Vault와 같은 Etcd에 저장되지 않고 스토리지에 저장이필요한) Bank Vaults나 Streams Kafka Operator처럼 별도 오퍼레이터 사용

 

---

참고 : App-of-Apps의 일반적인 구조

---

 

쿠버네티스의 Admission Controller로 OPA 모델 사용

에러방지를 위해 쿠버네티스 API 서버로 요청이 들어왔을때 해당 요청이 처리되기전 Admission Review 과정을 통해 특정 액션을 수행하는 구조(AWS의 Policy, Role 개념과 동일). Validating 액션 또는 Mutating 액션을 수행하는데 Validating은 특정 요청을 허가, Mutating은 Istio Sidecar injector 등과 같이 생성리소스를 변경하는 작업도 수행  

 

 

리소스에 정책을 매핑할 수 있음. 이는 Config 리소스로 메모리상에 올려 Tracing하도록 함

 

---

참고 : OPA란

OPA는 정책 및 데이터에 대한 질의를 평가하여 정책의 결정을 돌려준다. 여기에서 질의(Query)와 결정(Decision)은 json으로 표현하면 어떤 것이든 포함할 수 있으며 이에따라 매우 큰 확장성을 갖는다.

정책은 전용 언어(Rego)를 사용하여 기술하는데 도메인에 제한 받지 않는 (거의) 모든 종류의 정책의 기술이 가능하다.

질의의 예는 다음과 같다.

어떤 사용자가 어떤 리소스에 액세스할 수 있는가?
어떤 서브넷에 외부통신이 허용되는가?
어떤 클러스터로 워크로드를 배포해야 할 것인가?
어떤 레지스트리로부터 바이너리를 다운로드할 수 있는가?
어떤 OS 기능이 컨테이너와 함께 실행되는가?
어떤 시간에 시스템에 접근할 수 있는가?
결정도 단순 '예/아니오' 뿐 아니라 임의의 구조화된 데이터를 출력으로 사용할 수 있다.

데이터는 Json 형태로 저장되며 OPA 서버는 정책(Policy)을 기반으로 판단하는데 질의와 함께 이 데이터를 활용하여 결정을 만든다.

---

장점 
"설정 상"의 Know Issue 재발 방지

RBAC으로 개발자 권한을 제한해 생산성을 낮추지 않고 문제가 발생할 수 있는 특정부분 컨트롤 가능

단점 
발생할 수 있는 휴먼에러에 비해 Admission Controller 방식으로 막을 수 있는 범위가 제한적