SLASH 21 - 실수 없이 안전하게 쿠버네티스 운영하기

토스·토스 SLASH 21 2021·2021년

AI 요약

토스 서버 플랫폼 팀의 김영록 엔지니어가 '실수 없이 안전하게 쿠버네티스 운영하기'를 다룬다. 기능적 운영이 아니라, 새 팀원도 안전하게 작업할 수 있는 환경을 어떻게 구성하는지에 초점을 맞춘다. 핵심 도구는 GitOps와 OPA다.

핵심 포인트

멀티 클러스터의 형상 드리프트를 막기 위해 ArgoCD 기반 GitOps를 도입하고, Git을 '의도된 배포 상태'의 단일 진실 소스로 삼아 대부분 Auto-Sync 없이 운영하며, App of Apps로 클러스터 단위 형상을 관리한다
시크릿은 HashiCorp Vault와 커스텀 오퍼레이터(VaultSecret)로 Git에 노출 없이 쿠버네티스 Secret을 생성해 GitOps를 완성하고, 히스토리 추적으로 커뮤니케이션 비용을 크게 줄였다
휴먼 에러는 OPA 어드미션 컨트롤러로 막는데, Rego 정책과 OPA Gatekeeper·ConstraintTemplate으로 레지스트리 제한·삭제 방지를 걸고, sync(Config)로 다른 리소스를 참조하는 상태 기반 정책까지 적용한다

왜 읽나멀티 클러스터 쿠버네티스를 운영하며 형상 관리와 휴먼 에러 방지를 체계화하려는 DevOps·플랫폼 엔지니어에게 실전 패턴을 준다.

챕터별 상세

010:00 – 4:47

안전한 쿠버네티스 운영 — GitOps와 ArgoCD

토스 서버 플랫폼 팀의 김영록 엔지니어가 '실수 없이 안전하게 쿠버네티스 운영하기'를 연다. 이 세션은 네트워크나 모니터링 같은 기능적 운영이 아니라, 엔지니어가 어떻게 하면 더 안전하게 실수 없이 작업할 수 있는지 그 환경 구성에 초점을 맞춘다. 컨테이너는 격리로 높은 보안성을 가진다고 여겨지지만, 클러스터 내 얽힌 수많은 서비스의 복잡도가 오히려 가시성을 떨어뜨려 휴먼 에러나 보안 구멍의 기회를 만든다. 본인은 실수하지 않더라도 새 팀원은 계속 생기므로 '실수하지 않기를 바라는 것'에는 늘 비용이 따른다. 그래서 토스는 가시성과 휴먼 에러 방지를 위해 GitOps와 OPA(Open Policy Agent) 두 가지를 도입했다. 토스는 테스트베드·데브·라이브 세 종류의 클러스터를 운영하며, Istio 버전 업그레이드처럼 테스트베드 → 개발환경에서 검증한 뒤 라이브에 점진 적용한다.

토스는 멀티 데이터센터·멀티 클러스터를 액티브-액티브로 운영해 트래픽 조절로 사이드 이펙트를 손쉽게 제거하지만, 인프라 튜닝·벤치마킹이 쉬운 만큼 양쪽 클러스터의 ArgoCD·Prometheus 설정이 서로 달라지는 형상 드리프트가 생기곤 한다. 계열사 인프라까지 더해지며 효율적인 멀티 클러스터 형상 관리가 절실해졌고, 그 해법이 GitOps다. GitOps는 애플리케이션을 단일 진실 소스로 보고 생성·삭제·수정 등 배포 관점의 모든 작업을 Git을 통해 적용한다는 의미다. 토스는 오픈소스 ArgoCD를 사용하는데, Git의 쿠버네티스 배포 정보(Helm 차트, Kustomize 등)를 커스텀 리소스로 표현하고 실제 배포 상태와 동기화하는 오퍼레이터 패턴 도구로, API 서버·Repository 서버·Controller 서버 세 컴포넌트로 구성된다.

ArgoCD의 핵심은 Application 커스텀 리소스다. 클러스터·네임스페이스 쌍으로 배포 위치를 나타내는 Destination과, 차트 생성에 필요한 정보를 담은 Source 필드를 가진다. 중요한 점은 Application이 '현재 상태'가 아니라 '의도된 상태'를 표현한다는 것이다. Auto-Sync를 켜지 않으면 커스텀 리소스 배포 단계와 템플릿 적용 단계가 분리돼 변경사항을 Git 템플릿과 클러스터 양쪽에서 체크할 수 있다. 토스는 대부분 Auto-Sync를 쓰지 않고, 형상이 달라지면 작업자가 빠르게 맞추는 것을 원칙으로 삼아 Git을 '의도된 배포 상태'의 단일 진실 소스로 간주해 더 안전한 관리를 한다. 나아가 App of Apps 구조를 쓴다. 차트 단위가 아니라 클러스터 단위 형상을 체크하기 위해 특정 클러스터에 배포되는 모든 차트를 부트스트랩하는 상위 차트를 두고, 이 차트 하나가 각 차트의 Application 리소스를 ArgoCD에 넣어 준다. Values 파일을 여러 개 두어 dev·live 클러스터별 형상을 하나의 레포지토리에서 추적·공유하며, 실제로는 계열사·클러스터 단위로 더 고도화해 운영한다.

모든 리소스를 Git에 올리면 쿠버네티스 시크릿까지 노출해야 하는 보안 이슈가 생긴다. 토스는 이미 HashiCorp Vault를 보유하고 있어 이를 활용했다. Kubebuilder로 간단한 오퍼레이터와 VaultSecret 커스텀 리소스를 만들어, 특정 경로가 주어지면 오퍼레이터가 그 경로의 시크릿을 Vault에서 읽어 같은 이름의 쿠버네티스 Secret을 생성하게 했다. 이로써 Git에 시크릿 값을 노출하지 않고 GitOps를 구현했다. GitOps 운영 결과 통합 차트로 인프라 가시성이 크게 높아졌고, 신규 클러스터 세팅이 빨라졌으며, 같은 경로의 차트를 재사용해 예상치 못한 구성 차이를 방지했다. 가장 도움이 된 것은 히스토리 추적으로 커뮤니케이션 비용을 크게 줄인 점이다. 단점은 Vault처럼 첫 배포 이후 별도 절차가 필요한 애플리케이션은 Helm 차트만으로 모든 배포 내용을 표현할 수 없다는 점인데, Bank-Vaults나 Strimzi Kafka 오퍼레이터처럼 라이프사이클에 맞춰 절차를 자동 처리하는 오퍼레이터로 보완했다.

발표 후반은 휴먼 에러 방지를 위해 도입한 OPA(Open Policy Agent)다. OPA는 Rego라는 자체 언어로 특정 정책을 설정하고 의사결정을 수행하는 컴포넌트로, 여기서는 쿠버네티스 에러 방지에 한정해 다룬다. 쿠버네티스에서 OPA는 일반적으로 어드미션 컨트롤러로 쓴다. 어드미션 컨트롤러는 API 서버로 요청이 들어왔을 때 처리 전 어드미션 리뷰 과정에서 특정 액션을 수행하는데, 리소스를 변형하는 Mutating과 요청 허가 여부를 검증하는 Validating 두 가지가 있고 둘 다 있으면 Mutating 뒤 Validating이 동작한다. 개발자가 kubectl로 파드 생성을 날리면, Validating 어드미션 컨트롤러가 등록돼 있을 때 요청이 먼저 컨트롤러를 거쳐 OPA 서버로 넘어가고 정책에 따라 파드를 생성하거나 반려한다.

구체적인 Rego 예시로 특정 도커 레지스트리 사용을 막는 정책을 든다. 다만 Rego 코드만으로는 단순 스크립트라, 실제 파드 요청에 어드미션 컨트롤러로 적용해야 한다. 토스는 OPA Gatekeeper를 클러스터에 설치하고 ConstraintTemplate 커스텀 리소스로 정책을 적용했다. 예컨대 PreventDelete 같은 ConstraintTemplate으로 Istio 컨트롤 플레인 삭제를 막는 식으로, 단일 오브젝트에 네임·라벨 기반 조건을 자유롭게 걸 수 있다. 더 까다로운 케이스로, Istio VirtualService가 적용되지 않은 포트를 가리키면 라우팅 이슈가 생기는데 이는 Gatekeeper가 스테이트리스해서 생기는 문제다. 이는 sync(Config) 커스텀 리소스로 OPA가 메모리상에서 추적할 리소스 타입을 지정해 해결한다. 클러스터의 모든 서비스를 추적하게 하면 정책 내에서 다른 리소스를 참조하는 정책도 만들 수 있어, 포트 관련 정책을 적용하고 위반 변경을 모두 반려할 수 있다. OPA의 장점은 개발자 권한 제어 없이 방수턱처럼 문제를 해결해 생산성에 피해를 주지 않는다는 점이고, 단점은 해결 범위가 제한적이라는 것이다. 손쉬운 환경 구성과 장애 방지에 도움이 되길 바란다며 마무리한다.