This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
sole discretion of GitLab Inc.
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | devops data stores | - |
Cells ADR 003: 한 개의 GKE 클러스터 당 한 개의 셀
맥락
이 이슈에서는 다음과 같은 사항에 대해 논의했습니다.
- 여러 셀을 하나의 GKE 클러스터에 두어야 하는지, 아니면 단일하게 유지해야 하는지
- 셀이 하나의 GKE 클러스터에서 실행되어야 하는지, 아니면 여러 클러스터에서 실행되어야 하는지
결정
셀 당 하나의 GKE 클러스터를 유지하기로 결정했습니다. 이 결정의 배경에는 단순함이 있습니다: Cells 도구는 기존의 전용 도구를 활용하게 될 것이며, 전용 도구는 다시 GitLab Environment Toolkit (GET)을 사용하여 참조 아키텍처를 배포합니다. 참조 아키텍처 중 어느 것도 단일 GitLab 인스턴스를 여러 GKE 클러스터에 걸쳐 실행하는 것을 지원하지 않습니다.
ADR 002에서 한 GCP 프로젝트 당 하나의 셀을 유지하기로 한 결정과 위에서 한 선택은 여러 GKE 클러스터가 단일 셀을 제공하게 하는 가능성을 배제합니다.
결과
한 개의 GKE 클러스터 당 한 개의 셀을 유지하는 것은 셀의 프로비저닝 및 관리를 더 쉽게 만들 것입니다. GKE 클러스터 간에 복잡한 라우팅 논리를 구축할 필요가 없기 때문입니다.
클러스터 당 노드 제한(현재 15000)에 도달할 경우, 여러 클러스터에 작업 부하를 분산시킬 수 있는 대신 노드를 수직으로 확장해야 할 것입니다. 그러나 현재 GitLab.com의 프로덕션 설정은 약 300개의 노드만 사용하고 있으므로, 이러한 상황은 꽤 오랜 기간 동안 또는 절대로 발생하지 않을 것으로 예상됩니다.
대안
위에서 논의된 대안은 GET에 상당한 구조적인 변화가 필요할 것이며, 기존 도구를 간단히 사용하지 않는 것이 더 효율적이며(및 덜 방해적일 수 있음) 전반적인 Cells 인프라 철학과는 어긋날 수 있습니다.