토스의 쿠버네티스 환경구성
Table of contents
이 포스트는 토스ㅣSLASH 21 - 실수 없이 안전하게 쿠버네티스 운영하기 유튜브 영상을 참고하여 본인의 의견이 첨가된 내용으로 포스팅을 재구성한 글임을 미리 밝혀 둡니다. 만약 토스 관계자분께서 해당 포스팅의 게재를 원치 않으시거나 수정이 필요하다고 판단되면 이메일로 연락 부탁드립니다.
본 내용은 kubernetes, argocd, helmchart에 대한 지식이 없다면 이해하기 힘들 수 있습니다. 본 포스팅에서 해당 개념을 따로 설명을 드리지 않습니다.
개요
본 내용은 네트워크와 모니터링 같은 기능적인 운영보다는 쿠버네티스를 관리하는 엔지니어가 어떻게 하면 안전하게 실수하지 않고 편하게 작업할 수 있는지 환경 구성에 관련된 내용이다.
쿠버네티스에서 컨테이너는 격리의 이점을 통해 높은 보안성을 가진다 생각하지만, 네트워크 내에 얽힌 수많은 서비스의 복잡도는 가시성을 떨어트리기에 휴먼에러, 혹은 보안 구멍이 생길 기회를 제공한다. 만약 가시성이 잘 확보되어 있지 않고 안전대가 잘 마련되어 있지 않다면 간단한 설정 변경으로도 예상치 못한 장애가 일어날 수 있다. 본인은 실수하지 않을 확신이 있더라도 모든 구성원이 이를 보장하는 것은 아니므로 구조적으로 보완이 필요하다.
그래서 토스에서는
- 쿠버네티스 리소스 가시성을 확보하기 위한 방법
- 휴먼에러 방지를 위한 GitOps 패턴과 OPA(Open Policy Agent) 도입에 관련된 내용
에 관련된 내용을 집중적으로 다룬다.
토스의 쿠버네티스 클러스터
토스는 3개 클러스터로 운영하고 있다.
Testbed Cluster
아무 트래픽이 없는 TestBed 클러스터이다.
쿠버네티스 초심자를 위하여 마음껏 올려보고 삭제해 보라고 만들어 놓은 환경인 것 같다. 혹은 개발 환경에서 다른 서비스와 상호작용하기 전 쿠버네티스 문법 오류가 있는지, 동작은 제대로 하는지 자유롭게 혼자 테스트하기 위한 용도의 클러스터로 추정된다. 마음대로 올리고 삭제 해도 문제가 없는 클러스터라고 보면 된다.
Dev Cluster
개발 테스트 목적의 클러스터, 라이브 환경으로 가기 전 테스트 목적으로 운영되는 클러스터이다.
운영 환경에서 발생되는 다양한 문제를 사전에 발견하기 위함으로 운영하는듯하다. Testbed 클러스터와는 다르게 이때는 다른 서비스와 상호작용을 할 수 있기 때문에 라이브 환경에 올리기 전 실제 서비스와 동일한 환경으로 테스트를 할 수 있다는 장점이 있다.
Live Cluster
운영 환경의 클러스터이다. 특이한 점은 Live(부분)과 Live(전체)로 나누어져 있는데 이중화 구조를 통해 라이브 환경에 점진적으로 적용을 을 한다고 소개한다.
active-acitve 이중화 구조로 운영하고 있다고 소개한다. 쿠버네티스 클러스터 상단 트래픽을 조절하여 운영한다고 하는데, 구체적으로 어떻게 조절하고 있는지에 대한 설명이 나와있지 않다.
추측하자면 Route53을 통해 특정 도메인으로 트래픽이 전달되면 완전히 동일한 구조의 클러스터인 live A 클러스터와 live B 클러스터를 서로 스위치 하여 트래픽을 전달하는 것으로 추정된다.
위에서 설명한 점진적 라이브 환경으로 적용한다는 의미는, 아마 live A 클러스터에 먼저 적용 후 이상이 없다고 판단될 시 live B 클러스터에 적용하는듯하다.
마치 쿠버네티스 롤링 업데이트처럼 무중단 업데이트 구현을 클러스터 내부에서 구현하는 것이 아닌 완전히 격리된 클러스터에서 구현하는 것으로 보이며 이는 통째로 특정 가용영역의 장애가 발생하거나 특정 클라우드에서 장애 발생시 안전장치로 동일한 환경의 클러스터가 존재하기에 무중단 서비스를 운영하기 위함으로 추측된다. ( 비용이 많이 발생할 텐데 역시 돈을 잘 버나보다. )
멀티 클러스터의 문제점
여러개의 클러스터를 운영하다보면 가장 흔히 발생되는 문제점은 각각의 클러스터의 버전이 달라지는 문제다. 크게는 엔진의 버전 부터 작게는 istio, 프로메테우스 같은 내부 서비스의 버전이 달라질 경우 예상치 못한 문제가 발생할 수 있다.
토스틑 이러한 멀리클러스터 형상 관리를 위해 GitOps 를 통한 가시성 확보 와 명확한 형상 관리로 이러한 사이드 이펙트를 해결했다고 소개한다.
GitOps 배포
토스에서는 GitOps 패턴을 도입하여 ArgoCD를 통해 배포를 진행한다. 이때 helmchart를 이용한다고 밝히고 있다. helmchart는 쿠버네티스에 서비스를 배포할 때 수많은 yaml 정보를 한 번에 통합 관리할 수 있는 도구라고 보면 된다.
근데 여기서 의문점이 github를 사용한다고 되어 있다. github는 공개된 repository 서버이다. 물론 비용을 지불하면 비공개 repository를 사용할 수 있다. 그렇다고 하더라도 회사 코드를 외부 서비스에 직접 올리는 경우는 잘 없다. (그럴 일은 없겠지만 막말로 github에서 코드를 몰래 읽어볼 수도 있는 거니까..) 일반적으로 토스 같은 규모라면 내부에서 직접 설치한 git 서비스를 사용할 줄 알았다. 아마 예시용으로 github 이라 올린 것 같다.
argocd 에서 사용하는 예시 문법을 보여 주는데, destination 에는 배포 위치를 지정하고, source 에는 helmchart 위치를 나타낸다.
이때 애플리케이션 리소스를 배포하는 단계와 템플릿을 실제로 적용하는 단계가 분리된다고 설명한다. 말이 어려운데, 쉽게 설명하자면 실제 서비스 코드가 포함되어 있는 git을 push 하면 이를 컨테이너로 빌드 하여 컨테이너 이미지 저장소에 저장하는 것과, 실제로 클러스터에 컨테이너 이미지를 배포하는 것을 분리했다는 의미로 파악된다. 모든 과정을 자동화 하는건 리스트가 있으므로 해당 방법으로 더블체크를 한다고 설명한다.
다음장은 git 코드상에서 쿠버네티스 리소스 관리에 큰 도움이 되었던 App-of-Apps 구조에 대해 설명한다.
App-of-Apps 구조
App-of-Apps 구조가 무엇일까 궁금하긴 했는데 특별한 내용은 아니었고, 각 클러스터의 환경을 하나의 repository 안에 구성한다는 의미였다.
helmchart를 사용하셨던 분들이라면 위 이미지를 보고 어떻게 운영되는지 한 번에 감이 올 것이다. 쉽게 설명하면, 각 클러스터에서 어떤 버전을 운영할지 관련 정보들을 위와 같은 방법으로 관리해서 운영한다는 의미이다.
추가적으로 git에 시크릿 정보를 올리게 되면 보안상 문제가 되니 Vault 를 사용중이라 밝히고 있다. 그리고 해당 구조를 도입함으로써 얻은 장점과 단점을 소개하고 있다.
장점
- 정돈된 App-ofApps 차트 사용으로 가시성 향상
- 신규 클러스터 구성속도 향상
- 서로 다른 클러스터의 예상치 못한 구성 차이 방지
- 히스토리 추적 가능
단점
- 쿠버네티스 배포로 초기세팅이 불가능한 서비스를 표현할 수 없는 점 : ex) kafka, Vault
단점을 어떻게 극복했는지 소개하는데, Bank-Vaults 나 Strimzi-Kafka-Operator처럼 쿠버네티스 배포 라이프 사이클에 맞추어 관련 절차를 자동으로 처리할 수 있도록 돕는 오퍼레이터를 사용하여 해결했다고 언급하고 있다. 단 관련 내용을 상세히 언급하지 않아 정확히 어떻게 해결했는지 알 수 없었다. 나도 해당 부분엔 지식이 없어 추정이 불가 했다. 이 부분은 학습을 통해 이후 포스팅에 추가할 예정이다.
다음파트는 OPA이다. 이를 이용하여 휴먼 에러를 추가로 방지했다고 소개하는데 개인적으로 정말 궁금한 파트였다.
OPA로 휴먼 에러 방지하기
OPA는 Rego 라는 자체 정의 언어를 이용하여 특정 정책을 설정하고, 디시전 메이킹(의사결정)을 수행하는 컴포넌트라 소개하고 있다. OPA는 오픈소스로, 쿠버네티스 내에서 특정 컴포넌트 역할을 대체할수 있다.
Admission Controller
Admission Controller란, 쿠버네티스 컴포넌트중 하나로 쿠버네티스 API 서버로 요청이 들어왔을 때 해당 요청이 처리되기 전 admissionreview 과정을 통해 특정 액션을 수행하는 컨트롤러를 말한다. 크게 Mutating Admission Controller 와 Validating Admission Controller 두가지가 있다.
Validating Admission Controller는, 특정 API 요청을 허가하는 역할을 하며 Mutating Admission Controller는 istio의 sidecar injector 혹은 EKS의 identity webhook 처럼 생성 리소스를 변경하는 작업까지 수행해 준다. 그리고 단일 요청에 의해 다수의 Mutating Admission Controller와 Validating Admission Controller가 있다면 모든 Mutating Admission Review 가 끝나고 Validating Admission Controller에게 생성할 수 있는지 없는지 검증 받는다.
여기서 좀더 이해를 돕기 위해 예시를 설명 해 준다.
일반적으로 쿠버네티스에 명령하는 경우 ( Validating Admission Controller를 사용하지 않는 경우 )
- 개발자는 kubectl 을 통해 create pod 를 명령을 날린다.
- 쿠버네티스 API 서버에서 개발자의 권한을 확인한다.
- 인증된 개발자라면 요청을 수행후 원하는 POD 을 생성한다.
Validating Admission Controller가 있는 경우
- 개발자는 kubectl 을 통해 create pod 를 명령을 날린다.
- 쿠버네티스 API 서버는 admission controller 에게 validate를 요청한다.
- admission controller는 그 의사결정한 내용을 API 서버에게 응답한다.
- API 서버는 요청 응답을 보고 상황에 따라 pod 을 생성하거나 요청을 반려하게 된다.
이중 Validating Admission Controller가 하는 역할을 OPA에게 위임한다고 밝히고 있다.
정리하자면, 쿠버네티스 사용자가 특정 명령의 권한이 있다고 하더라도 해당 명령을 무조건 실행하는 것이 아닌 OPA 를 통해 더블체크를 하여 안전장치를 마련한다 라고 이해하면 된다.
이게 왜 필요한지 쉽게 설명하자면, create pod 이라는 권한이 있는 사용자라고 할지라도 모든 컨테이머 이미지를 생성할수 있다면 이미 Deprecated 된 컨테이너 이미지를 올릴수도 있기 때문이다. 좀더 꼼꼼하게 체크하는 용도라고 생각하면 된다.
OPA 적용
OPA 를 쿠버네티스에서 적용하기 위해선 OPA 게이트키퍼 라는 컨트롤러를 쿠버네티스에 설치하면 ConstraintTemplete 라는 커스텀 리소스를 통해 정책을 적용할 수 있다. 예시는 다음과 같습니다.
OPA 를 통하면 특정 컨테이너의 삭제를 차단하는등 상세한 정책을 손쉽게 적용할 수 있으므로, 휴먼 에러를 방지할 수 있다. 이중 신박한 기능을 소개 했는데, 예를들어 pod 마다 내부에서 사용하는 포트번호가 전부 제각각인 경우가 많다. 이때 svc 생성시 target port를 지정할 때 잘못된 pod 의 port 를 지정하면 엉뚱한 곳에서 시간을 헤맬 수 있다. 이것도 OPA로 해결이 가능하다고 소개하고 있다. 바로 Config 라는 리소스를 사용하면 OPA 가 메모리상에 추적할 리소스 타입을 지정할 수 있다.
다음과 같은 config 를 적용하면 OPA는 클러스터상의 모든 svc 를 추적하여 정책내에서 서비스를 참조할수 있게 된다. 신박한 기능인것 같다. 해당 부분을 나중에 꼭 적용 해 보아야 겠다.
OPA 적용시 장점
- 설정상의 known issue 재발 방지
- RBAC 권한으로 개발자 권한을 제한해 생산성을 낮추지 않고, 문제가 발생할 수 있는 특정 부분 컨트롤 가능
특히 두번째 장점이 매우 막강한듯 하다. RBAC 으로 사용자 권한을 제한하는게 생각보다 보통 스트레스가 아니다.
OPA 적용시 단점
- 발생할 수 있는 휴먼 에러에 비해 Admission Controller 방식으로 막을 수 있는 범위가 제한적
정책 설정으로 모든 경우의 수를 다 막을수 없다는 이야기인듯 하다.