기업 멀티테넌시 권장사항

Google Kubernetes Engine(GKE)의 멀티테넌시는 테넌트 간에 공유되는 하나 이상의 클러스터를 의미합니다. Kubernetes에서 테넌트는 다음 중 하나로 정의할 수 있습니다.

  • 하나 이상의 워크로드 개발 및 운영을 담당하는 팀
  • 하나 이상의 팀에서 운영될 수 있는 관련 워크로드 집합
  • 단일 워크로드(예: 배포)

클러스터 멀티테넌시는 비용을 줄이거나 전체 테넌트에 관리 정책을 일관되게 적용하기 위해 구현하는 경우가 많습니다. 하지만 GKE 클러스터 또는 연결된 GKE 리소스를 잘못 구성하면 비용을 절감하는 데 실패하고, 잘못된 정책을 적용하거나, 여러 테넌트의 워크로드 간에 파괴적인 상호작용이 발생할 수 있습니다.

이 가이드에서는 기업 조직에 여러 멀티 테넌트 클러스터를 안전하고 효율적으로 설정하기 위한 권장사항을 제공합니다.

가정 및 요구사항

이 가이드의 권장사항은 다음과 같은 가정과 요구사항이 있는 기업 환경의 멀티 테넌트 사용 사례를 기반으로 합니다.

  • 조직은 Kubernetes를 사용하여 컴퓨팅 및 관리 리소스를 공유하려는 테넌트(둘 이상의 애플리케이션/서비스팀)가 많은 단일 회사입니다.
  • 각 테넌트는 단일 워크로드를 개발하는 단일 팀입니다.
  • 애플리케이션/서비스팀 외에 플랫폼팀 구성원, 클러스터 관리자, 감사관 등 클러스터를 활용하고 관리하는 다른 팀도 있습니다.
  • 플랫폼팀은 클러스터를 소유하고 각 테넌트팀이 사용할 수 있는 리소스의 양을 정의합니다. 각 테넌트는 추가 리소스를 요청할 수 있습니다.
  • 각 테넌트팀은 플랫폼팀과 통신할 필요 없이 Kubernetes API를 통해 애플리케이션을 배포할 수 있어야 합니다.
  • 각 테넌트는 API 호출, 공유 데이터 소스와 같은 명시적 설계 결정을 통하는 경우를 제외하고 공유 클러스터의 다른 테넌트에 영향을 미쳐서는 안 됩니다.

이 설정은 멀티 테넌트 권장사항을 보여주는 모델로 사용할 수 있습니다. 이 설정이 모든 기업 조직을 완벽하게 설명하지는 않지만, 유사한 시나리오를 포괄하도록 간편하게 확장할 수 있습니다.

폴더, 프로젝트, 클러스터 설정

권장사항:

폴더 및 프로젝트 계층 구조 설정
IAM을 사용한 역할 할당
공유 VPC를 통해 네트워크 제어 중앙화
클러스터당 하나의 클러스터 관리 프로젝트 만들기
클러스터를 비공개로 설정
클러스터의 컨트롤 플레인이 리전에 있는지 확인
클러스터의 노드가 3개 이상의 영역에 걸쳐 있는지 확인
클러스터 노드 및 리소스 자동 확장
사용량이 많지 않은 시간에 유지보수 기간 예약
인그레스로 외부 애플리케이션 부하 분산기 설정

GKE에 멀티 테넌트 클러스터를 배포하는 기업 조직의 경우 간단한 단일 애플리케이션, 단일 팀 Kubernetes 배포에는 없는 복잡성을 관리하기 위해 다른 Google Cloud 시스템에 추가 구성이 필요합니다. 여기에는 조직 구조를 클라우드 ID 및 계정에 매핑하고 데이터베이스, 로깅 및 모니터링, 스토리지, 네트워킹과 같은 추가 Google Cloud 리소스를 관리하는 것 외에 관리상의 문제를 분리하는 프로젝트 구성도 포함됩니다.

폴더 및 프로젝트 계층 구조 설정

조직에서 Google Cloud 리소스를 관리하는 방법을 파악한 후 문제를 구분하려면 폴더 및 프로젝트를 사용하세요. 폴더를 사용하면 서로 다른 팀이 여러 프로젝트에 단계적으로 걸쳐 있는 정책을 설정할 수 있고, 프로젝트를 사용하면 환경(예: 프로덕션 및 스테이징)과 팀을 서로 구분할 수 있습니다. 예를 들어 대부분의 조직에는 네트워크 인프라를 관리하는 팀과 클러스터를 관리하는 팀이 있습니다. 각 기술은 자체적 수준의 전문성, 문제 해결, 액세스 권한이 필요한 별도의 스택으로 간주됩니다.

상위 폴더에는 최대 300개의 폴더를 포함할 수 있고, 폴더는 최대 10개 수준까지 중첩할 수 있습니다. 테넌트가 300개 이상 있으면 한도를 초과하지 않도록 테넌트를 중첩된 계층 구조로 정렬해도 됩니다. 폴더에 대한 자세한 내용은 폴더 만들기 및 관리를 참조하세요.

IAM을 사용한 역할 할당

IAM 정책을 통해 Google Cloud 리소스에 대한 액세스를 제어할 수 있습니다. 먼저 조직에 필요한 그룹과 작업 범위를 파악한 다음 적절한 IAM 역할을 그룹에 할당합니다.

Google 그룹스를 사용하여 사용자에게 맞는 IAM을 효율적으로 할당하고 관리할 수 있습니다.

네트워크 제어 중앙화

서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하려면 공유 VPC 네트워크를 사용하세요. 공유 VPC의 리소스는 내부 IP를 사용하여 프로젝트 경계를 넘어 안전하고 효율적으로 서로 통신할 수 있습니다. 각 공유 VPC 네트워크는 중앙 관리형 호스트 프로젝트에서 정의하고 소유하며 하나 이상의 서비스 프로젝트에서 사용할 수 있습니다.

공유 VPC와 IAM을 통해 네트워크 관리를 프로젝트 관리로부터 분리할 수 있습니다. 이 분리는 최소 권한 원칙을 구현하는 데 도움이 됩니다. 예를 들어 중앙 네트워크팀에서 참여 프로젝트에 대한 권한 없이 네트워크를 관리할 수 있습니다. 마찬가지로, 프로젝트 관리자는 공유 네트워크를 조작하기 위한 권한 없이 프로젝트 리소스를 관리할 수 있습니다.

공유 VPC를 설정할 때는 VPC에 서브넷과 서브넷의 보조 IP 범위를 구성해야 합니다. 서브넷 크기를 확인하려면 예상 테넌트 수, 실행할 것으로 예상되는 pod 및 서비스 수, 최대 및 평균 pod 크기를 알아야 합니다. 필요한 총 클러스터 용량을 계산하면 원하는 인스턴스 크기를 파악할 수 있으며, 이 크기에 따라 총 노드 수가 계산됩니다. 총 노드 수를 사용하면 소비되는 총 IP 공간을 계산할 수 있으며, 이 값에 따라 원하는 서브넷 크기가 계산됩니다.

다음은 네트워크를 설정할 때 고려해야 할 몇 가지 요소입니다.

  • 호스트 프로젝트에 연결할 수 있는 최대 서비스 프로젝트 수는 1,000개이고, 단일 조직의 최대 공유 VPC 호스트 프로젝트 수는 100개입니다.
  • 노드, pod, 서비스 IP 범위는 모두 고유해야 합니다. 기본 IP 주소 범위와 보조 IP 주소 범위가 겹치는 서브넷을 만들 수 없습니다.
  • 주어진 GKE 클러스터의 최대 pod 수와 최대 서비스 수는 클러스터의 보조 범위 크기에 따라 제한됩니다.
  • 클러스터의 최대 노드 수는 클러스터 서브넷의 기본 IP 주소 범위 및 클러스터의 pod 주소 범위의 크기에 따라 제한됩니다.
  • IP 주소를 보다 유연하고 세부적으로 관리하기 위해 노드에서 실행할 수 있는 최대 pod 수를 구성할 수 있습니다. 또한 노드당 포드 수를 줄이면 노드당 할당되는 CIDR 범위가 줄어들기 때문에 IP 주소가 더 적게 필요합니다.

클러스터의 서브넷 수를 계산할 때 GKE IPAM 계산기 오픈소스 도구를 사용하면 유용합니다. IP 주소 관리(IPAM)를 사용하면 IP 공간/서브넷을 효율적으로 사용할 수 있으며, 범위가 겹치는 경우를 방지하므로 중간에 연결을 차단할 수 있습니다. VPC 클러스터의 네트워크 범위에 대한 자세한 내용은 VPC 기반 클러스터 만들기를 참조하세요.

공유 클러스터 외부에서 실행되는 리소스(예: 전용 Compute Engine VM)의 격리를 강화해야 하는 테넌트는 네트워킹팀에서 실행하는 공유 VPC와 피어링되는 자체 VPC를 사용할 수 있습니다. 이렇게 하면 보안은 강화되지만, 복잡성이 증가하고 기타 수많은 제한사항이 적용될 수 있습니다. 피어링에 대한 자세한 내용은 VPC 네트워크 피어링 사용을 참조하세요. 아래 예시에서는 모든 테넌트에서 단일(환경별) 테넌트 VPC를 공유하도록 선택했습니다.

안정적이고 가용성이 높은 클러스터 만들기

다음 권장사항을 구현하여 고가용성 및 안정성을 고려한 클러스터 아키텍처를 설계하세요.

  • 프로젝트 수준 구성(예: IAM binding)이 다수의 클러스터에 부정적인 영향을 줄 수 있는 위험을 줄이고 할당량과 결제를 분리하는 데 도움이 되도록 클러스터당 하나의 클러스터 관리자 프로젝트를 만듭니다. 클러스터 관리자 프로젝트는 개별 테넌트가 Google Cloud 리소스를 관리하는 데 사용하는 테넌트 프로젝트와 별개입니다.
  • 프로덕션 클러스터를 비공개로 설정하여 노드에 대한 액세스를 중지하고 컨트롤 플레인에 대한 액세스를 관리합니다. 또한 개발 및 스테이징 환경에 비공개 클러스터를 사용하는 것이 좋습니다.
  • 멀티테넌시에 고가용성을 제공하려면 클러스터의 컨트롤 플레인이 리전에 있어야 합니다. 컨트롤 플레인에 장애가 발생하면 테넌트에 영향을 미칩니다. 리전 클러스터를 실행하면 비용이 발생한다는 점에 유의하시기 바랍니다. Autopilot 클러스터는 리전 클러스터로 사전 구성됩니다.
  • 클러스터의 노드는 영역 안정성을 달성하기 위해 3개 이상의 영역에 걸쳐 있어야 합니다. 동일한 리전의 영역 간 이그레스 비용에 대한 자세한 내용은 네트워크 가격 책정 문서를 참조하세요.
리전별 컨트롤 플레인이 3개 영역에서 실행되는 비공개 리전 클러스터
그림 3: 리전별 컨트롤 플레인이 3개 영역에서 실행되는 비공개 리전 클러스터

클러스터 노드 및 리소스 자동 확장

테넌트의 요구를 수용하려면 자동 확장을 사용 설정하여 클러스터의 노드를 자동으로 확장하세요.

자동 확장을 사용하면 다양한 테넌트에서 많은 워크로드를 네임스페이스에 배포할 때 또는 영역별 장애에 대응하기 위해 시스템이 정상적이고 응답 중인 것으로 나타납니다.

Autopilot 클러스터를 사용하면 워크로드 요구사항에 맞게 노드 풀이 자동으로 확장됩니다.

자동 확장을 사용 설정할 경우 예상 워크로드 크기에 따라 클러스터의 최소 및 최대 노드 수를 지정합니다. 최대 노드 수를 지정하면 클러스터가 실행되는 네임스페이스에 관계없이 클러스터의 모든 pod를 수용하기에 충분한 공간을 확보할 수 있습니다. 클러스터 자동 확장은 최소/최대 경계에 따라 노드 풀의 크기를 재조정하므로, 시스템 부하가 감소될 때는 운영 비용을 줄이고 사용 가능한 클러스터 리소스가 충분하지 않은 경우에는 pod가 대기 상태로 전환되지 않도록 합니다. 최대 노드 수를 확인하려면 각 테넌트에 필요한 최대 CPU 및 메모리 용량을 확인하고, 이 용량을 함께 추가하여 모든 테넌트가 한도에 도달했을 때 클러스터에서 처리할 수 있어야 하는 총 용량을 확보하도록 합니다. 그런 다음 최대 노드 수를 사용하여 인스턴스 크기와 개수를 선택할 수 있습니다. 이때 클러스터에서 사용 가능한 IP 서브넷 공간을 고려하세요.

pod 자동 확장을 사용하여 리소스 요구에 따라 pod를 자동으로 확장합니다. 수평형 포드 자동 확장 처리(HPA)는 CPU/메모리 사용률 또는 커스텀 측정항목을 기준으로 포드 복제본의 수를 조정합니다. 수직형 포드 자동 확장(VPA)을 사용하여 포드 리소스 수요를 자동으로 확장할 수 있습니다. 두 자동 확장 처리가 서로 경합할 수 있으므로 커스텀 측정항목을 사용할 수 없는 경우에는 HPA와 함께 사용해서는 안됩니다. 따라서 HPA로 시작하고 나중에 필요할 때 VPA를 설정합니다.

클러스터 크기 결정

클러스터 크기를 결정할 때 고려해야 할 몇 가지 중요한 요소는 다음과 같습니다.

  • 클러스터의 크기는 실행할 워크로드 유형에 따라 다릅니다. 워크로드의 밀도가 높아지면 비용 효율성이 높아지지만, 리소스 경합 가능성도 높아집니다.
  • 클러스터의 최소 크기는 클러스터가 걸쳐 있는 영역 수를 기준으로 정의됩니다. 즉, 영역 클러스터의 경우는 노드 1개, 리전 클러스터는 노드 3개로 정의됩니다.
  • 프로젝트의 경우, 영역당 클러스터는 최대 50개, 리전당 리전 클러스터는 최대 50개입니다.
  • 클러스터별로 클러스터당 노드는 최대 15,000개(GKE 버전 1.17까지는 5,000개), 노드 풀당 노드는 1,000개, 클러스터당 노드는 1,000개(GKE 인그레스 컨트롤러를 사용하는 경우), 노드당 포드는 256개(1.23.5-gke.1300 이전 버전의 GKE의 경우 110개), 클러스터당 포드는 150,000개, 클러스터당 컨테이너는 300,000개입니다. 자세한 내용은 할당량 및 한도 페이지를 참조하세요.

유지보수 기간 예약

클러스터/노드 업그레이드 및 유지보수 도중 발생하는 다운타임을 줄이려면 사용량이 많지 않은 시간 중에 유지보수 기간 일정을 예약하세요. 업그레이드 중 노드를 다시 만들기 위해 워크로드를 이동하면 일시적인 장애가 발생할 수 있습니다. 이러한 장애의 영향을 최소화하려면 사용량이 많지 않은 시간에 업그레이드 일정을 예약하고 가능하면 장애를 부분적으로 처리하도록 애플리케이션 배포를 설계합니다.

인그레스로 외부 애플리케이션 부하 분산기 설정

테넌트의 게시된 서비스 관리 및 이러한 서비스로 들어오는 트래픽 관리를 지원하려면 클러스터당 단일 인그레스를 허용하도록 HTTP(s) 부하 분산기를 만드세요. 여기서 각 테넌트의 서비스는 클러스터의 인그레스 리소스로 등록됩니다. Kubernetes 인그레스 리소스를 만들어 HTTP(S) 부하 분산기를 만들고 구성하면 트래픽이 서비스에 도달하는 방법과 트래픽이 테넌트의 애플리케이션으로 라우팅되는 방법을 정의할 수 있습니다. 서비스를 인그레스 리소스로 등록하면 서비스의 이름 지정 규칙은 단일 인그레스를 나타내도록 일관되게 유지됩니다(예: tenanta.example.com 및 tenantb.example.com).

멀티테넌시의 클러스터 보호

권장사항:

네트워크 정책에 따라 pod 통신 제어
GKE Sandbox로 워크로드 실행
정책 기반 허용 제어 설정
GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud 서비스에 대한 액세스 권한 부여
컨트롤 플레인에 대한 네트워크 액세스 제한

네트워크 정책에 따라 pod 통신 제어

각 클러스터의 네임스페이스에 있는 pod 간의 네트워크 통신을 제어하려면 테넌트의 요구사항에 따라 네트워크 정책을 만드세요. 우선 다른 테넌트의 애플리케이션을 호스팅하는 네임스페이스 간에 주고받는 트래픽을 차단해야 합니다. 클러스터 관리자는 deny-all 네트워크 정책을 적용하여 한 네임스페이스의 pod가 실수로 다른 네임스페이스의 서비스 또는 데이터베이스로 트래픽을 전송하지 않도록 모든 인그레스 트래픽을 거부할 수 있습니다.

예를 들어 다른 모든 네임스페이스에서 tenant-a 네임스페이스로의 인그레스를 제한하는 네트워크 정책은 다음과 같습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

GKE Sandbox로 워크로드 실행

신뢰할 수 없는 워크로드를 실행하는 클러스터는 다른 클러스터에 비해 보안 취약점에 더 많이 노출됩니다. GKE Sandbox를 사용하면 멀티 테넌트 환경의 워크로드 간 격리 경계를 강화할 수 있습니다. 보안 관리를 위해 GKE Sandbox로 시작한 후 정책 기반 허용 제어를 이용해서 차이를 메우는 것이 좋습니다.

GKE Sandbox는 오픈소스 컨테이너 샌드박스 프로젝트인 gVisor를 기반으로 하며 컨테이너와 호스트 OS 사이에 레이어를 추가하여 멀티 테넌트 워크로드를 추가로 격리합니다. 컨테이너 런타임은 노드에서 권한이 높은 사용자로 실행되는 경우가 많고 호스트 커널을 호출하는 대부분의 시스템에 액세스할 수 있습니다. 멀티 테넌트 클러스터에서는 악의적인 테넌트가 호스트 커널 및 다른 테넌트의 데이터에 액세스할 수 있습니다. GKE Sandbox는 호스트의 공격 노출 영역을 줄이고 악의적인 행위자의 움직임을 제한함으로써 컨테이너가 호스트와 직접 상호작용할 필요성을 줄여서 이러한 위협을 완화합니다.

GKE Sandbox는 컨테이너와 호스트 OS 사이에 다음 2가지 격리 경계를 제공합니다.

  • Go로 작성된 사용자 공간 커널로 시스템 호출을 처리하고 호스트 커널과의 상호작용을 제한합니다. 각 pod에는 자체 격리된 사용자 공간 커널이 있습니다.
  • 사용자 공간 커널은 네임스페이스 내부와 seccomp 필터링 시스템 호출 중에도 실행됩니다.

정책 기반 허용 제어 설정

보안 경계를 위반하는 포드가 클러스터에서 실행되지 않도록 방지하려면 허용 컨트롤러를 사용합니다. 허용 컨트롤러는 정의한 정책에 따라 포드 사양을 확인하고 해당 정책을 위반하는 포드가 클러스터에서 실행되지 않도록 할 수 있습니다.

GKE는 다음 유형의 허용 제어를 지원합니다.

GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud 서비스에 대한 액세스 권한 부여

워크로드에 Google Cloud 서비스에 대한 액세스 권한을 안전하게 부여하려면 클러스터에서 GKE용 워크로드 아이덴티티 제휴를 사용 설정합니다. GKE용 워크로드 아이덴티티 제휴는 Kubernetes 워크로드가 Google Cloud 서비스 액세스를 위해 사용하는 Kubernetes 서비스 계정을 관리자가 관리할 수 있게 도와줍니다. GKE용 워크로드 아이덴티티 제휴를 사용 설정해서 클러스터를 만들 경우 클러스터가 있는 프로젝트에 대해 ID 네임스페이스가 설정됩니다. ID 네임스페이스를 사용하면 클러스터에서 GKE 애플리케이션의 서비스 계정을 자동으로 인증할 수 있으며 인증은 Kubernetes 서비스 계정 이름을 테넌트 Kubernetes 서비스 계정의 IAM binding에 사용되는 가상 Google 서비스 계정 핸들에 매핑하는 방식으로 이루어집니다.

컨트롤 플레인에 대한 네트워크 액세스 제한

컨트롤 플레인을 보호하려면 승인된 네트워크에 대한 액세스를 제한하세요. GKE에서 승인된 네트워크를 사용 설정하면 최대 50개의 CIDR 범위를 승인하고 해당 범위의 IP 주소만 컨트롤 플레인에 액세스하도록 허용할 수 있습니다. GKE는 전송 계층 보안(TLS)과 인증을 사용하여 공개 인터넷에서 컨트롤 플레인 엔드포인트에 대한 보안 액세스를 제공합니다. 승인된 네트워크를 사용하면 액세스를 지정된 IP 주소 집합으로 제한할 수 있습니다.

테넌트 프로비저닝

권장사항:

테넌트 프로젝트 만들기
RBAC를 사용하여 테넌트 액세스 세분화
테넌트 간 격리를 위해 네임스페이스 만들기

테넌트 프로젝트 만들기

테넌트의 비클러스터 리소스를 호스팅하기 위해 각 테넌트의 서비스 프로젝트를 만듭니다. 이러한 서비스 프로젝트에는 테넌트 애플리케이션별 논리 리소스(예: 로그, 모니터링, 스토리지 버킷, 서비스 계정 등)가 포함됩니다. 모든 테넌트 서비스 프로젝트는 테넌트 호스트 프로젝트의 공유 VPC에 연결됩니다.

RBAC를 사용하여 테넌트 액세스 세분화

Kubernetes RBAC를 사용하여 테넌트의 클러스터 리소스에 대해 더 세분화된 액세스 권한을 정의합니다. IAM에서 처음 테넌트 그룹에 부여된 읽기 전용 액세스 권한 외에 각 테넌트 그룹의 네임스페이스 범위 Kubernetes RBAC 역할 및 결합을 정의합니다.

앞에서 두 가지 테넌트 그룹 즉, 테넌트 관리자와 테넌트 개발자를 식별했습니다. 이제 이러한 그룹에 대해 다음 RBAC 역할 및 액세스를 정의합니다.

그룹 Kubernetes
RBAC 역할		 설명
테넌트 관리자 네임스페이스 관리자

네임스페이스에 배포를 나열하고 감시할 수 있는 액세스 권한을 부여합니다.

테넌트 그룹에 사용자를 추가하고 삭제할 수 있는 액세스 권한을 부여합니다.
테넌트 개발자 네임스페이스 편집자,
네임스페이스 뷰어		 네임스페이스에서 pod, 배포, 서비스, configmap을 생성, 수정, 삭제할 수 있는 액세스 권한을 부여합니다.

테넌트 관리자는 Google Workspace 또는 Cloud ID 그룹에 네임스페이스 내부의 다양한 권한을 할당하는 RBAC 역할 및 결합을 만드는 것 외에 종종 각 그룹의 사용자를 관리할 수 있는 권한이 필요한 경우가 있습니다. 조직의 요구사항에 따라, 테넌트 관리자가 자체 그룹 멤버십을 관리할 수 있는 Google Workspace 또는 Cloud ID 권한을 위임받아 처리하거나 이러한 변경사항을 처리할 수 있는 Google Workspace 또는 Cloud ID 권한이 있는 조직 내 팀과 협업하여 이러한 사항을 처리할 수 있습니다.

네임스페이스와 함께 IAM 및 RBAC 권한을 사용하여 Google Cloud 콘솔에서 클러스터 리소스와의 사용자 상호작용을 제한할 수 있습니다. 자세한 내용은 액세스 권한을 사용 설정하고 네임스페이스별 클러스터 리소스 보기를 참조하세요.

Google 그룹스를 사용하여 권한 결합

클러스터에서 테넌트 권한을 효율적으로 관리하기 위해 RBAC 권한을 Google 그룹스에 결합할 수 있습니다. 이러한 그룹의 멤버십은 Google Workspace 관리자가 관리하므로 클러스터 관리자는 사용자에 대한 세부정보가 필요하지 않습니다.

예를 들어 이름이 tenant-admins@mydomain.com인 Google 그룹이 있고 admin1@mydomain.com이라는 사용자가 해당 그룹의 구성원인 경우 다음 결합은 사용자에게 tenant-a 네임스페이스에 대한 관리자 액세스 권한을 제공합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

네임스페이스 만들기

동일한 클러스터에 있는 테넌트 사이를 논리적으로 격리하려면 네임스페이스를 구현하세요. Kubernetes RBAC 프로세스의 일부로 클러스터 관리자는 각 테넌트 그룹의 네임스페이스를 만듭니다. 테넌트 관리자는 해당하는 각 테넌트 네임스페이스 내에서 사용자(테넌트 개발자)를 관리합니다. 그러면 테넌트 개발자가 클러스터 및 테넌트 전용 리소스를 사용하여 애플리케이션을 배포할 수 있습니다.

네임스페이스 한도 도달 방지

이론상 클러스터의 최대 네임스페이스 수는 10,000개이지만, 실제로는 다양한 요인으로 인해 이 한도에 도달하지 못할 수 있습니다. 예를 들어 최대 네임스페이스 수에 도달하기 전에 클러스터 전체 범위의 최대 pod 수(150,000개)와 노드 수(5,000개)에 도달할 수 있습니다. 보안 비밀 수와 같은 다른 요인으로 인해 유효 한도가 줄어들 수 있습니다. 따라서 초기에는 실험을 통해 사용 사례가 제대로 작동하는 경우를 제외하고, 한 번에 한 제약조건의 이론적 한도에만 도달하도록 시도하고 다른 한도에서는 대략 한 자릿수의 간격을 유지하는 것이 좋습니다. 단일 클러스터에서 사용하는 것보다 더 많은 리소스가 필요하다면 더 많은 클러스터를 만들어야 합니다. Kubernetes 확장성에 대한 자세한 내용은 Kubernetes 확장성 기준 문서를 참조하세요.

네임스페이스 이름 표준화

서로 다른 클러스터에서 호스팅되는 여러 환경에 간편하게 배포하기 위해, 사용하는 네임스페이스 이름 지정 규칙을 표준화합니다. 예를 들어 환경 이름(개발, 스테이징, 프로덕션)을 네임스페이스 이름에 연관시키지 말고 여러 환경을 아우르는 이름을 사용하세요. 그러면 여러 환경 간에 구성 파일을 변경하지 않아도 됩니다.

테넌트 워크로드의 서비스 계정 만들기

테넌트 네임스페이스의 각 고유한 워크로드에 대해 테넌트별 Google 서비스 계정을 만듭니다. 이렇게 하면 보안 기능이 제공되므로 테넌트는 각 네임스페이스에서 소유하고 있거나 배포하는 워크로드의 서비스 계정을 관리할 수 있습니다. 각 네임스페이스의 Kubernetes 서비스 계정은 GKE용 워크로드 아이덴티티 제휴를 사용해서 하나의 Google 서비스 계정에 매핑됩니다.

리소스 할당량 적용

클러스터를 공유하는 모든 테넌트가 클러스터 리소스에 공정하게 액세스하도록 하려면 리소스 할당량을 적용하세요. 각 테넌트에서 배포된 pod 수와 각 pod에 필요한 메모리와 CPU 용량을 기반으로 각 네임스페이스의 리소스 할당량을 만듭니다.

리소스 할당량의 예시는 다음과 같습니다. 여기서 tenant-a 네임스페이스의 pod는 최대 16개의 CPU와 64GB의 메모리를 요청할 수 있으며, CPU 및 메모리 용량의 최대 한도는 각각 32개, 72GB입니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

모니터링, 로깅 및 사용

권장사항:

사용량 측정항목 추적
테넌트별 로그 제공

사용량 측정항목 추적

클러스터에서 개별 네임스페이스와 라벨에 따라 비용 분석을 수행하려면 GKE 비용 할당을 사용 설정하면 됩니다. GKE 비용 할당은 클러스터 워크로드의 리소스 요청 및 리소스 사용량에 대한 정보를 추적하며, 네임스페이스 및 라벨을 기준으로 더 세부적으로 분류할 수 있습니다. GKE 비용 할당을 사용하면 클러스터를 공유하는 부서/팀 비용의 근사치를 산출하고, 개별 애플리케이션(또는 단일 애플리케이션의 구성요소)의 사용량 패턴을 파악하고, 클러스터 관리자가 사용량 급증 문제를 분류하도록 지원하고, 더 우수한 용량 계획 및 예산을 제공할 수 있습니다.

GKE 비용 할당을 사용 설정하면 GKE 워크로드의 클러스터 이름 및 네임스페이스가 BigQuery에 대한 결제 내보내기의 라벨 필드에 표시됩니다.

테넌트별 로그 제공

프로젝트 워크로드와 관련된 로그 데이터를 테넌트에게 제공하려면 Cloud Logging의 로그 라우터를 사용하세요. 테넌트별 로그를 만들려면 클러스터 관리자는 싱크를 만들어 로그 항목을 테넌트의 Google Cloud 프로젝트에서 생성된 로그 버킷으로 내보냅니다.

이러한 유형의 로그를 구성하는 방법에 대한 자세한 내용은 GKE의 멀티 테넌트 로깅을 참조하세요.

체크리스트 요약

다음 표는 기업 조직에서 멀티 테넌트 클러스터를 만드는 데 권장되는 작업을 요약한 것입니다.

지역 할 일 목록
조직 설정
ID 및 액세스 관리
네트워킹
고가용성 및 안정성
보안
로깅 및 모니터링

다음 단계