[쿠버네티스] 클러스터 설계 전략(클러스터 어떻게 나눌까?)

Intro

최근에 컨테이너 서비스로의 마이그레이션 또는 신규 구축 사례가 늘고 있습니다. 자연스럽게 다양한 케이스의 쿠버네티스의 설계에 대한 고민을 하게 되었습니다. 그 와중에 훌륭하게 정리되어 있는 외국 블로그를 발견했고 이를 해석,요약 정리해보았습니다. (https://learnk8s.io/how-many-clusters#1-one-large-shared-cluster)
위 블로그에서 본문 내용과 그림을 발췌하였음을 알려드립니다

우선 결론 부터

클러스터 설계 전략을 크게 4가지로 나눌 수 있으며 이를 요약하면 아래 표와 같습니다.
어떤 전략을 사용해야하는지 답은 정해져 있지 않으며, 보안, 어프리케이션의 영향도 등을 고려하여 각 전략을 적절하게 결합한 형태로 사용해야 합니다.

어플리케이션 및 환경 별 매트릭스

일반적으로 어플리케이션을 구축할때 개발, 테스트, 운영 환경으로 나누며 각각 환경별 어플리케이션별로 구분을 할 수 가 있습니다. 따라서 아래 9개의 어플리케이션 인스턴스가 생성됩니다.

1. 개발-앱1
2. 개발-앱2
3. 개발-앱3
4. 테스트-앱1
5. 테스트-앱2
6. 테스트-앱3
7. 운영-앱1
8. 운영-앱2
9. 운영-앱3

1. 대규모 공유 클러스터

장점

1. 효율적인 리소스 사용
   • 클러스터당 마스터 노드가 3개가 필요하므로, 1개의 마스터노드가 3개면 된다
   • load balancer, ingress controller, auth, logging, monitoring 등 하나로 관리할 수 있다
2. 싸다
   • 위의 장점으로 리소스를 더 적게 사용할 수 있으므로 저렴하다
3. 관리가 쉽다
   • kubernetes 버전 업그레이드
   • CI/CD 파이프라인 설정
   • CNI 플러그인 설치
   • 사용자 인증 시스템 설정
   • ingress controller 설치 등

단점

1. 단일 실패 지점 (single failure point)

   • 쿠버네티스 업그레이드시에 예상치 못한 장애 발생 가능
   • 클러스터 구성요소가 예상대로 작동하지 않을 수 있음(CNI플러그인 등)
   • 클러스터 구성요소 중 하나에 잘못된 구성이 만들어짐
   • 인프라 장비 자체애 대한 중단이 발생 함

2. 보안에 취약할 수 있음

   • 여러 앱이 동일한 클러스터에서 실행되는 경우 하드웨어, 네트워크 및 OS를 공유 하고 있다는 것을 의미한다
   • 리눅스 컨테이너는 일종의 격리를 제공하지만 VM에서 제공하는 것 만큼 강력하지 않으며, 컨테이너 프로세스는 여전히 호스트OS에서 실행되늰 프로세스일 뿐이다. 따라서 앱이 원하지 않는 방식으로 서로 상호작용을 할 수 있다.
   • 클러스터내의 모든 워크로드는 DNS와 같은 클러스터 전체 서비스를 공유하므로 앱이 클러스터에 있는 다른 앱의 서비스를 검색할 수 있음, 따라서 어플리케이션 보안 요구사항에 따라서 문제가 될 수 도 있고 아닐 수도 있다.
   • 쿠버네티스는 PodSecurityPolicies와 NetworkPolicyes와 같은 보안 침해 방지를 위한 수단을 제공하고 있지만, 운영 경험을 요구하며 모든 보안 침해를 예방할 수는 없다.
   • 쿠버네티스틑 격리 및 보안이 아니라 공유를 위해 설계되었음을 기억하는 것이 중요한 포인트 임

3. 하드한 멀티 테넌시가 없다

   • 쿠버네티스 클러스터는 리소스를 공유하므로 서로 다른 앱이 서로에게 영향을 끼칠 수 있는 방법이 많이 존재함, 예를들어 CPU나 메모리와 같은 특정 공유 리소스를 독점하여 동일한 노드에서 실행 되는 다른 앱을 고갈 시킬 수 있다

4. 많은 사용자의 접근

   • 클러스터가 하나만 있는 경우 조직의 많은 사람들이 이 클러스터에 엑세스할 수 있어야 함 따라서, 많은 사람들이 시스템에 엑세스 할 수 있을 수록 무언가 잘못 건드를 위험이 있다 (휴먼 에러 발생 가능성 높아짐)
   • 클러스터 내에서 RBAC기반 역할을 제어할 수 있지만 권한 영역내에서 무언가를 위반 하는 것을 방지할 수 는 없다

5. 클러스터는 무한히 커질 수 없다

   • 클러스터는 약 5000개의 노드 150000개의 파드, 300000개의 컨테이너로 정의된다

소규모 일회성 클러스터

장점

1. 폭발 반경 감소

   • 클러스터가 중단되면 이 클러스터에서 실행되는 워크로드만 제한이 되며 모든 워크로드에는 영향을 받지 않는다

2. 격리

   • 개별 클러스터에서 실행되는 워크로드는 CPU,메모리,OS,Network또는 기타 서비스와 같은 리소스를 공유하지 않으므로 보안에 큰 이점이 될 수 있다

3. 소수의 사용자

   • 모든 클러스터가 작은 워크로드만 사용할 경우 이 클러스터에 엑세스할 수 있는 사람이 적으므로 휴먼에러의 가능성이 낮아진다

단점

1. 비효율 적인 리소스 사용
2. 비싸다
3. 복잡한관리

어플리케이션 당 클러스터

장점

1. 클러스터는 앱에 맞게 사용자 지정할 수 있음
   • 앱에 특정 요구 사항이 있는 경우 이러한 요구 사항은 다른 클러스터에 영향을 주지 않고 해당 클러스터에 설치할 수 있다(GPU작업자 노드, 특정 CNI플러그인, 서비스메시 등등)

단점

1. 같은 클러스터의 다른 환경
   • 다른 환경의 어플리케이션 인스턴스가 같은 클러스터에서 실행된다는 단점이 있음
   • 이는 개발 환경과 운영환경이 서로 영향을 미칠 수 있다는 것을 의미한다

환경 별 클러스터

장점

1. 운영환경의 격리가 가능함
2. 각 환경에 맞게 커스터 마이징 할 수 있다
3. 운영 환경 클러스터에서 작업할 필요가 없으므로 휴먼에러의 위험이 매우 적다

단점

1. 어플리케이션 간의 격리가 부족하다
   • 위에서 이미 언급 했듯이 OS, CPU, memory등 여러 서비스를 공유하므로 어플리케이션 끼리 영향을 미칠 수 있으며 보안에 문제가 생길 수 있다
2. 환경별로 모두 별도 구성해야함
   • 예를들어 GPU가 필요한경우 모든 환경에서 GPU를 사용해야 하므로 비용 효율적이지 못하다

결론

보안에 위반되지 않으며, 각 어플리케이션별 영향도, 비용 효율성을 파악하여 적절하게 결합하여 사용해야 한다.