[발표자료 다운로드] 쿠버네티스 클러스터 분리 vs 네임스페이스 분리 — 선택 기준

업무 분리 방식은 취향이 아니라 비용·운영·개발 비교와 클러스터 필수 기준으로 결정된다. 이 발표자료는 그 비교와 기준을 플랫폼 담당자와 의사결정권자가 함께 읽을 수 있도록 장표로 정리했다.

전체 23장, PDF 로 23쪽이다. 1부는 격리 수준과 구조 차이, 2부는 세 관점의 장단점과 종합 평가, 3부는 워커 분리 방법과 관리 한도, 4부는 클러스터 필수 기준과 판단 흐름, 권장 운영 모델을 다룬다.

플랫폼 표준 수립이나 신규 업무 수용 검토 회의 자료로 그대로 쓸 수 있도록 원본 구성 그대로 공개한다.

분리 방식 비교의 출발점은 쿠버네티스를 운영하는 값이 어디서 생기는지 아는 것이다. 클러스터를 하나 더 만들 때마다 그 값이 한 번 더 붙는다.

이 영상은 클러스터 한 벌을 운영하는 값이 어디서 생기는지를 먼저 짚는다.

영상에서 다루는 순서는 다음과 같다.

• 서버 운영에서 클러스터 운영으로 바뀌는 일
• 분산 시스템의 복잡함과 줄어드는 일, 늘어나는 일
• 쿠버네티스가 대신하는 여덟 가지 자동 기능
• 보안 운영이 담당자에게 기대는 이유
• 서비스 규모에 따른 도입 판단과 세 가지 확인 질문

플랫폼 팀이 신규 업무를 받을 때 반복해서 나오는 질문 순서로 장표를 배치했다.

1. 네임스페이스만으로 업무를 안전하게 나눌 수 있는가
2. 클러스터 분리와 네임스페이스 분리는 비용이 얼마나 다른가
3. 공유 마스터 구성의 운영상 약점은 무엇인가
4. 클러스터를 나누지 않고 실행 노드만 따로 둘 수 있는가
5. 한 클러스터는 노드 몇 대까지 관리할 수 있는가
6. 어떤 업무는 반드시 클러스터를 나눠야 하는가

네임스페이스는 이름 공간과 권한을 나눌 뿐 커널을 나누지 않는다. 같은 노드에 뜬 다른 네임스페이스 파드와 커널을 공유하므로, 커널 취약점 하나면 그 선은 의미를 잃는다.

리눅스 커널 네임스페이스는 프로세스·네트워크를 컨테이너 단위로 가르는 기능이고, 쿠버네티스 네임스페이스는 이름과 권한을 묶는 API 단위다. 커널 쪽은 리눅스 네임스페이스 설명에서 볼 수 있다.

그래서 격리 수준을 고르는 기준은 기술이 아니라 신뢰 경계다. 나누려는 대상이 같은 회사의 다른 팀이면 네임스페이스로 충분하다. 서로 모르는 고객끼리라면 최소한 노드를 나누고, 규제가 걸리면 클러스터까지 간다. 네 단계는 아래로 갈수록 확실해지고 아래로 갈수록 비싸다.

▲ 격리 수준은 네임스페이스·노드·샌드박스 런타임·클러스터 순으로 강해지고 비용도 같은 순서로 오른다 (발표자료 4쪽)

자사 업무가 네 단계 중 어디에 속하는지는 누구와 누구 사이에 선을 긋는가를 먼저 적으면 정해진다.

제품마다 클러스터를 두면 컨트롤 플레인과 관측·인증, 업그레이드 일정이 제품 수만큼 복제된다. 클러스터 하나에 노드 풀을 나눠 두면 공통 기반은 한 벌로 남고, 자원 다툼과 배치 격리 요구는 대부분 여기서 해결된다.

▲ 제품마다 클러스터를 두는 대신 한 클러스터 안에서 노드 풀로 제품을 가르면 공통 기반은 한 벌로 남는다 (발표자료 5쪽)

그래도 클러스터를 나눠야 하는 경우는 세 가지로 좁혀진다. 컨트롤 플레인 장애를 함께 겪으면 안 되는 등급 차이, 규제로 인프라 자체를 갈라야 하는 요구, 신뢰 경계가 다른 조직이 섞이는 상황이다. 이 셋에 해당하지 않으면 노드 분리로 시작하고, 부족해질 때 클러스터를 나눈다.

클러스터 분리는 업무마다 마스터 3대와 공통 구성요소, 워커를 따로 두고, 네임스페이스 분리는 마스터 한 벌을 함께 쓰면서 네임스페이스로 업무를 나눈다. 업무가 늘 때 전자는 마스터와 Ingress·모니터링·로깅이 함께 늘고, 후자는 한 벌로 유지된다.

▲ 클러스터를 나누면 마스터와 공통 구성요소가 업무 수만큼 늘고 네임스페이스로 나누면 한 벌로 유지된다 (발표자료 6쪽)

분리 단위도 다르다. 클러스터 분리는 물리 경계로 나누고, 네임스페이스 분리는 권한·네트워크·자원 한도라는 정책 경계로 나눈다.

네임스페이스 분리는 마스터와 공통 구성요소를 한 벌로 줄여 클러스터 수에 비례하던 고정 비용을 업무 수와 무관하게 만든다. 피크 시간이 다른 업무끼리 워커를 나눠 쓰므로 한 업무의 빈 자원을 다른 업무가 재사용한다.

▲ 네임스페이스 분리는 클러스터 수에 비례하던 고정 비용을 업무 수와 무관한 한 벌로 줄인다 (발표자료 8쪽)

클러스터 분리는 클러스터마다 여유 자원을 따로 남기고, 클러스터 단위 구독·라이선스도 클러스터 수만큼 늘어난다. 대신 업무별 비용이 명확히 나뉜다. 네임스페이스 분리는 이 구분을 라벨과 사용량 측정으로 따로 만들어야 한다.

줄어든 반복 작업도 사라지지 않고 공용 클러스터를 맡은 플랫폼 팀의 상시 운영 공수로 옮겨 가므로 인력 계획에 함께 적는다.

네임스페이스 분리는 업그레이드·보안 패치·관제를 한 번에 처리하지만, 컨트롤 플레인 장애나 업그레이드 실패가 모든 업무에 함께 미친다. 두 사실을 같이 봐야 판단이 기울지 않는다.

▲ 네임스페이스 분리는 업그레이드를 한 번에 끝내지만 컨트롤 플레인 장애는 모든 업무에 함께 미친다 (발표자료 9쪽)

클러스터 분리는 장애 영향이 그 클러스터 안으로 한정되고 업무별로 업그레이드 일정을 따로 잡을 수 있다. 그 대가로 업그레이드·인증서 갱신·etcd 백업을 클러스터 수만큼 반복하고, 관제와 정책이 흩어져 업무마다 운영 수준이 달라진다. 공유 마스터를 택했다면 업그레이드 전에 입주 업무 전체의 호환성을 확인하는 절차를 표준으로 둔다.

정책 변경도 같다. 공용 Admission 정책은 선택자에 걸린 모든 워크로드에 한꺼번에 적용되므로 개발 클러스터에서 먼저 검증한다.

네임스페이스 분리는 네임스페이스와 Quota, 권한을 만들면 바로 새 개발 환경을 내준다. CI/CD·GitOps·레지스트리가 하나로 통일되고, 서비스 간 호출은 클러스터 내부 DNS 로 끝난다.

▲ 네임스페이스 분리는 새 개발 환경을 즉시 내주지만 CRD·Operator 를 직접 설치하려는 제품은 제약을 받는다 (발표자료 10쪽)

반면 CRD·Operator·Admission Webhook 을 업무팀이 임의로 설치할 수 없고, 쿠버네티스 버전과 공통 구성요소 버전도 고를 수 없다. 이런 설치가 필요한 제품이 클러스터 분리를 검토할 대표적인 경우다.

세 관점을 여덟 항목으로 모으면 다섯 항목에서 네임스페이스 분리가, 세 항목에서 클러스터 분리가 유리하다.

▲ 여덟 개 비교 항목 중 다섯 항목에서 네임스페이스 분리가 유리하다 (발표자료 11쪽)

결론은 장애 격리와 버전 자유도가 꼭 필요한 업무만 클러스터를 나누면 된다는 것이다.

마스터를 함께 써도 노드 라벨과 Taint 를 조합하면 업무별 전용 노드 풀을 만들어 실행 노드를 따로 둘 수 있다. 라벨과 Node Affinity 는 파드가 갈 노드를 고르는 쪽이고, Taint 와 Toleration 은 노드가 다른 업무 파드를 거르는 쪽이다.

▲ 노드 라벨과 Taint 를 함께 걸면 클러스터를 나누지 않고도 업무별 전용 노드 풀이 생긴다 (발표자료 13쪽)

구성 예로 공유 마스터 3대 아래에 일반 업무용 공용 워커 풀, 민감정보 업무용 전용 풀, AI 추론용 GPU 풀을 둘 수 있다. 전용 풀에는 dedicated=biz-a:NoSchedule 같은 Taint 를 걸고, 해당 업무 파드에만 Toleration 과 nodeSelector 를 준다.

네임스페이스는 이름만 나눠서는 격리되지 않는다. 파드 간 통신과 자원 경쟁이 그대로 남으므로 생성 시점에 여섯 가지를 정책으로 함께 걸어야 업무 간 간섭이 막힌다.

▲ 네임스페이스는 생성 시점에 자원 장치 셋과 보안 장치 셋을 함께 걸어야 업무 간 간섭이 막힌다 (발표자료 14쪽)

특히 NetworkPolicy 는 기본 차단으로 시작해 필요한 통신만 열고, RBAC 은 업무팀에 자기 네임스페이스 권한만 준다. 사람이 매번 걸면 빠지는 곳이 생기므로 생성 템플릿과 Admission 정책으로 자동 적용한다.

기본 차단에서 시작해 통신을 여는 과정은 네임스페이스 기반 통신 제한 실습에서 따라 해 볼 수 있다.

쿠버네티스 공식 문서(v1.37)가 제시하는 클러스터 하나의 상한은 노드 5,000대, 노드당 파드 110개, 전체 파드 15만 개, 전체 컨테이너 30만 개다. 그러나 실제 운영 한도는 이 숫자가 아니라 마스터 사양과 etcd·API 서버 부하가 먼저 정한다.

▲ 공식 상한은 노드 5,000대지만 실제 한도는 etcd·API 서버 부하와 마스터 사양이 먼저 정한다 (발표자료 15쪽)

먼저 닿는 병목은 세 곳이다. etcd 는 오브젝트가 늘며 쓰기 지연이 커지고, API 서버에는 요청이 한곳으로 몰리며, 파드 IP 대역과 관제 애드온도 한도를 올려야 한다.

상용 배포판 시험값으로 보면 마스터 3대 구성에서 워커 252대까지 마스터 한 대당 16 vCPU·64GB 로 운영된다.

▲ 워커 252대까지 마스터 한 대당 16 vCPU·64GB 로 운영되고 장애 대비 여유분을 더해 산정해야 한다 (발표자료 16쪽)

OVN-Kubernetes 네트워크를 쓰는 252대 구성은 24 vCPU·128GB 가 필요하다. 마스터 3대 중 1대가 내려가면 남은 2대에 부하가 몰리므로 여유분을 더해 산정하고. 수백 대 규모는 한 클러스터로 운영할 수 있고, 그 이상에서는 상한보다 업그레이드 시간이 먼저 부담이 된다.

가장 큰 이유는 운영 인력과 비용이 클러스터 수에 비례해 늘기 때문이다. 버전 업그레이드, 인증서 갱신, etcd 백업·복구 시험, 관제·로그 연동, 정책 배포는 클러스터로 나누면 클러스터 수만큼, 공유하면 한 번이다.

▲ 기업이 네임스페이스를 택하는 가장 큰 이유는 반복 작업과 인력이 클러스터 수에 비례해 늘기 때문이다 (발표자료 18쪽)

여기에 표준을 한곳에서 강제해 업무별 편차를 없애는 효과가 붙는다. 새 업무는 네임스페이스·Quota·권한 배정만으로 시작하고, 서비스 간 호출은 내부 통신과 공용 API 게이트웨이로 단순해진다.

그렇다고 모든 업무를 네임스페이스로 받을 수는 없다. 아래 여덟 가지 중 하나라도 해당하면 클러스터를 나눈다. 네임스페이스 정책으로는 대신할 수 없는 경계이기 때문이다.

▲ 여덟 가지 필수 기준 중 하나라도 해당하면 네임스페이스 정책으로 대신할 수 없으므로 클러스터를 나눈다 (발표자료 19쪽)

마지막 환경 기준은 업그레이드를 미리 검증하려면 거의 모든 기업에 해당하므로, 최소 단위는 운영·개발 두 벌이다.

규제 축은 공공 부문에서 자주 걸린다. 국가 클라우드 컴퓨팅 보안 가이드라인은 컨테이너 기술 스택을 관리 노드·컨테이너 노드·레지스트리 3계층으로 나눠 13개 보안기준과 30개 점검항목을 둔다.

반대로 같은 보안 등급·같은 망에서 네임스페이스 권한만으로 구축되는 업무는 공용 클러스터로 충분하다. 성능 간섭은 Quota 와 전용 노드 풀로 해결된다.

▲ 같은 보안 등급·같은 망에서 네임스페이스 권한만 쓰는 업무는 공용 클러스터로 충분하다 (발표자료 20쪽)

판단은 여섯 질문으로 한다. 공용 클러스터와 같은 망·같은 보안 등급인가, CRD·Operator 설치 없이 배포되는가, 공용 클러스터 업그레이드 일정을 따를 수 있는가, 피크 부하를 Quota·전용 노드로 막을 수 있는가, 공용 관제·GitOps 표준을 따를 수 있는가, 컨트롤 플레인 장애 때 함께 멈춰도 되는가. 여섯 질문에 모두 예라면 네임스페이스로 받고, 하나라도 아니오면 다음 판단 흐름에 따라 단계를 올린다.

두 기준을 하나로 묶으면 3단계 흐름이 된다. 기본은 네임스페이스이고, 성능 간섭·민감정보·GPU 사용 중 하나라도 해당하면 전용 노드 풀로, 클러스터 필수 기준에 해당하면 별도 클러스터로 올린다.

▲ 기본은 네임스페이스이고 조건에 해당할 때만 전용 노드 풀과 별도 클러스터로 한 단계씩 올린다 (발표자료 21쪽)

단계를 올릴 때는 세 원칙을 지킨다. 판단 항목과 근거를 수용 방식 결정서로 남기고, 별도 클러스터도 공용 관제·로그·GitOps 표준을 따르며, 사업 변경이나 규모 증가 때 단계를 다시 판단한다. 별도 클러스터가 늘수록 고정 비용과 반복 작업이 되살아나므로 3단계는 예외 승인 대상으로 작게 유지한다.

결정서가 남으면 담당자가 바뀌어도 같은 판단이 나오고, 다음 검토에서 같은 논의를 되풀이하지 않는다.

권장 모델은 공용 클러스터를 운영·개발 두 벌로 두고 업무는 네임스페이스로 받는 것이다. 예외 클러스터는 필수 기준에 해당할 때 예외 승인과 운영 인력 계획을 받아 만든다.

▲ 공용 클러스터를 운영·개발 두 벌로 두고 업무는 네임스페이스로 받으며 예외 클러스터도 같은 표준을 따른다 (발표자료 22쪽)

필수 표준은 여섯 가지다. 서비스ID-환경 형식의 명명과 소유 부서·등급 라벨, NetworkPolicy 기본 차단, ResourceQuota·LimitRange 필수, Pod Security restricted, Admission 정책으로 위반 배포 거부, GitOps 배포와 공용 관제 연동이다. 예외 클러스터도 같은 관제·배포 표준을 따라야 운영이 다시 흩어지지 않는다.

업무 분리의 기본값은 네임스페이스이고, 클러스터는 정책으로 대신할 수 없는 경계가 있을 때만 나눈다.

쿠버네티스 네임스페이스만으로 업무를 안전하게 나눌 수 있는가

같은 회사의 다른 팀처럼 서로 신뢰하는 업무라면 충분하다. 다만 네임스페이스는 커널을 나누지 않으므로 보안 경계가 아니며, ResourceQuota·LimitRange·PriorityClass·NetworkPolicy·RBAC·Pod Security 를 생성 시점에 함께 적용해야 업무 간 간섭이 막힌다.

클러스터 분리와 네임스페이스 분리는 비용이 어떻게 다른가

클러스터 분리는 마스터 3대와 Ingress·모니터링·로깅 같은 공통 구성요소, 구독·라이선스가 클러스터 수만큼 늘어난다. 네임스페이스 분리는 이 고정 비용이 업무 수와 무관하게 한 벌이고 워커도 통합해 쓰지만, 업무별 비용 배분은 라벨과 사용량 측정으로 따로 구성해야 한다.

공유 마스터 구성의 가장 큰 약점은 무엇인가

컨트롤 플레인 장애나 업그레이드 실패가 입주한 모든 업무에 함께 미친다는 점이다. 그래서 마스터 3대 HA 를 전제로 하고, 업그레이드 전에 입주 업무 전체의 호환성을 확인하며, 개발·검증 클러스터에서 업그레이드를 먼저 검증한다.

클러스터를 나누지 않고 실행 노드만 분리할 수 있는가

있다. 노드 라벨과 Node Affinity 로 업무 파드가 갈 노드를 지정하고, Taint 와 Toleration 으로 다른 업무 파드의 진입을 막으면 업무별 전용 노드 풀이 된다. 민감정보 업무나 GPU 추론 업무를 이 방식으로 분리한다.

쿠버네티스 클러스터 하나는 노드 몇 대까지 관리할 수 있는가

공식 상한은 노드 5,000대, 노드당 파드 110개, 전체 파드 15만 개다. 실제 한도는 마스터 사양과 etcd·API 서버 부하가 먼저 정하며, 상용 배포판 시험값으로 워커 252대까지 마스터 한 대당 16 vCPU·64GB 로 운영된다.

어떤 업무는 반드시 클러스터를 나눠야 하는가

규제상 망 분리, 다른 데이터센터나 DR 사이트 배치, 공용 장애를 허용할 수 없는 최상위 등급, 클러스터 범위 권한이 필요한 제품, 버전이 고정된 제품, 규모 한계 근접, 외부 사업자의 전체 운영, 운영·개발 환경 분리의 여덟 가지 중 하나라도 해당하는 업무다.

권장하는 쿠버네티스 업무 분리 운영 모델은 무엇인가

공용 클러스터를 운영·개발 두 벌로 두고 업무는 네임스페이스로 받는다. 필수 기준에 해당하는 업무만 예외 승인을 거쳐 별도 클러스터로 만들고, 예외 클러스터도 공용 관제·로그·GitOps 배포 표준을 똑같이 따르게 한다.

쿠버네티스 업무 분리 구조를 설계할 때 함께 읽을 자료다.

• 쿠버네티스 (Kubernetes) 란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 인프라 설계 — 컨트롤 플레인에서 고가용성까지
• 쿠버네티스 보안 4C 모델과 대응 방안
• 쿠버네티스 접근 제어와 인증서 관리
• 쿠버네티스 네트워킹과 CNI — Calico·Cilium·Flannel 비교
• 쿠버네티스 업그레이드가 어려운 이유 — 의존성·백업·버전 관리
• Line과 Yahoo — 15명으로 쿠버네티스 4만 노드와 1,300 클러스터를 운영하는 법
• 카카오 쿠버네티스 구축 사례: 온프레미스에 클러스터 7천·노드 12만 대
• Adobe GitOps 플랫폼 확장 전략 — 쿠버네티스 클러스터 360개 운영
• Kubernetes 공식 문서 — Multi-tenancy

클러스터 분리와 네임스페이스 분리를 비용·운영·개발 세 관점에서 비교하고 클러스터 필수 기준과 판단 흐름까지 담은 발표자료 23장을 23쪽 PDF 로 공개한다. 플랫폼 표준 검토나 신규 업무 수용 회의 자료로 자유롭게 쓸 수 있다.

아래 버튼에서 발표자료 PDF 를 바로 내려받을 수 있다.