구성 컨트롤러 확장성 가이드라인

이 페이지에서는 구성 컨트롤러 인스턴스에서 구성 관리 아키텍처를 계획하고 서비스 수준 목표(SLO) 내에서 Google Cloud 리소스 생성 및 관리를 유지하는 데 도움이 되는 권장사항을 제공합니다.

확장성 목표

구성 컨트롤러 확장성 대상은 Google에서 테스트하고 구성 동기화 GitOps를 사용하여 테스트된 리소스 그룹입니다. 이러한 대상을 사용하여 구성 관리 아키텍처를 계획할 수 있습니다.

이러한 대상은 엄격한 제한이 아닙니다. 한 리소스 종류의 양을 늘려도 구성 컨트롤러 인스턴스를 사용할 수 없게 되는 것은 아니지만, 동일한 구성 컨트롤러 인스턴스에서 배포할 수 있는 다른 리소스 종류의 총 양을 줄일 수 있습니다.

이 페이지의 표는 참조용이며 전체 목록이 아닙니다.

단일 네임스페이스

다음 예시에서는 클러스터에 하나의 구성 커넥터 네임스페이스가 있는 구성 컨트롤러 인스턴스를 보여줍니다. 구성 커넥터는 해당 네임스페이스에서 다음 수의 리소스를 만들고 관리할 수 있습니다.

리소스 유형

추천 한도

SQLInstance

450

SQLDatabase

2,250

SQLUser

2,500

StorageBucket

5,000

ContainerCluster

50

ContainerNodepool

200

IAMServiceAccount

2,500

IAMPartialPolicy

7,500

여러 네임스페이스

다음 예시에서는 클러스터의 구성 커넥터 네임스페이스 50개가 있는 구성 컨트롤러 인스턴스를 보여줍니다. 구성 커넥터는 각 네임스페이스에 다음과 같은 수의 리소스를 만들고 관리할 수 있습니다.

리소스 유형

추천 한도

SQLInstance

9

SQLDatabase 45
SQLUser 45
StorageBucket 100
ContainerCluster 1
ContainerNodepool 4
IAMServiceAccount 50
IAMPartialPolicy 150

구성 커넥터 네임스페이스

구성 컨트롤러는 기본적으로 구성 커넥터 네임스페이스 모드를 사용합니다. 다음 표는 단일 구성 커넥터 인스턴스에 포함될 수 있는 구성 커넥터 네임스페이스 수의 예시를 보여줍니다.

--cluster-ipv4-cidr-block

노드 수

구성 커넥터 네임스페이스 수

/18

64

600

/19

32

300

/20(기본값 및 권장)

16

120

/21

8

60

확장성 목표 확인

다음 리소스를 사용하여 확장성 목표에 도달했는지 확인할 수 있습니다.

Google Cloud API 할당량

Google Cloud 콘솔에서 Google Cloud API 할당량을 확인할 수 있습니다. 일부 할당량이 한도에 가까워지면 Google Cloud 프로젝트별로 API 할당량 샤딩을 고려하세요. 할당량 측정항목의 모니터링 및 알림에 대한 자세한 내용은 할당량 측정항목 모니터링 및 알림을 참조하세요.

구성 커넥터 메모리 사용

GKE 모니터링 대시보드에서 구성 커넥터 메모리 사용을 확인할 수 있습니다. 구성 커넥터의 메모리 사용량이 한도에 가까워지면 네임스페이스별 샤딩을 고려하세요.

구성 컨트롤러 확장

확장성 목표를 달성한 경우 구성 컨트롤러 인스턴스를 추가로 확장하는 것이 좋습니다. 이 섹션에서는 구성 컨트롤러 인스턴스를 확장하는 데 사용할 수 있는 다양한 방법을 간략하게 설명합니다.

네임스페이스별 샤딩

단일 구성 커넥터 네임스페이스로 확장성 목표에 도달하면 네임스페이스의 리소스를 관리하도록 구성 커넥터를 구성할 수 있습니다.

각 네임스페이스는 자체 서비스 계정 및 운영자 워크로드를 사용하여 구성 커넥터가 규모에 맞게 리소스를 관리할 수 있게 해줍니다. 하나의 구성 커넥터 인스턴스를 사용해서 여러 Google Cloud 프로젝트를 관리하는 경우 하나의 구성 커넥터 네임스페이스를 사용하여 각 Google Cloud 프로젝트를 관리할 수 있습니다.

Google Cloud 프로젝트별 API 할당량 샤딩

Google Cloud API 할당량에 도달하여 확장성 목표에 도달하면 서로 다른 Google Cloud 프로젝트가 소유한 IAM 서비스 계정을 서로 다른 네임스페이스에 결합하여 구성 커넥터가 네임스페이스 모드로 설치된 다른 네임스페이스에 연결할 수 있습니다. 그런 다음 리소스를 여러 프로젝트로 분할할 수 있습니다.

구성 커넥터 인스턴스로 샤딩

여러 구성 커넥터 네임스페이스로 확장성 목표에 도달하면 하나 이상의 구성 컨트롤러 인스턴스를 만들고 사용할 수 있습니다. 구성 컨트롤러 인스턴스를 두 개 이상 사용하면 조직 내 다양한 개발 환경, 애플리케이션팀 또는 GitOps 디렉터리 등으로 리소스 구성 관리를 샤딩할 수 있습니다.

기타 확장성 고려사항

Google Cloud API 할당량

API 할당량 한도를 초과했음을 나타내는 오류가 발생하면 동일 프로젝트에서 동일한 종류의 구성 커넥터 리소스를 너무 많이 만들었을 수 있습니다. 이러한 리소스는 구성 커넥터의 조정 전략으로 인해 동일한 API 엔드포인트에 너무 많은 API 요청을 생성할 수 있습니다.

이 문제를 해결하려면 Google Cloud 프로젝트로 API 할당량을 샤딩하거나 더 높은 할당량 한도를 요청하면 됩니다.

GKE 제한사항

구성 컨트롤러는 GKE 위에 빌드되므로 GKE에서 고려해야 할 제한사항이 있습니다. 다음 섹션에서는 구성 컨트롤러와 관련된 구체적인 고려사항을 설명합니다. 대규모 GKE 클러스터의 일반 한도 및 권장사항에 대한 자세한 내용은 대규모 GKE 클러스터 계획을 참조하세요.

Kubernetes 서비스 계정 한도

단일 GKE 클러스터에서 생성된 Kubernetes 서비스 계정(KSA)의 수는 3,000개를 초과할 수 없으며, 만일 초과할 경우 gke-metadata-server 포드 비정상 종료 문제가 발생할 수 있습니다.

구성 커넥터 네임스페이스를 추가할 때마다 Kubernetes 서비스 계정도 생성됩니다.

GKE 제어 영역 성능 문제

구성 컨트롤러 인스턴스에 구성 커넥터 네임스페이스가 너무 많으면 GKE 클러스터의 제어 영역에 성능 문제가 발생할 수 있습니다. 구성 커넥터 네임스페이스 수를 클러스터당 500개 미만으로 제한해야 합니다.

구성 커넥터 네임스페이스를 추가할 때마다 컨트롤러 포드도 생성됩니다.

다음 단계