Google이 방금 Control Plane 경계를 이동했습니다

Source: Dev.to

• Need more capacity? Add a cluster. → 더 많은 용량이 필요하신가요? 클러스터를 추가하세요.
• Need workload isolation? Add a cluster. → 워크로드 격리가 필요하신가요? 클러스터를 추가하세요.
• Need regional separation? Add a cluster. → 지역 분리가 필요하신가요? 클러스터를 추가하세요.
• Need a dedicated GPU pool? Add a cluster. → 전용 GPU 풀이 필요하신가요? 클러스터를 추가하세요.

The cluster became the unit of scale because the control plane could not scale far enough to avoid making it one. → 클러스터는 제어 플레인이 충분히 확장되지 않아 이를 피할 수 없게 되면서 규모 단위가 되었습니다.

반대 베팅 – Google Cloud Next ’26

Google Cloud Next ’26에서 Google은 단일 Kubernetes‑준수 제어 플레인을 발표했으며, 이는 여러 지역에 걸쳐 256 000 노드를 포괄하고 백만 개 가속기를 통합된 용량 예비군으로 관리합니다.

더 큰 Kubernetes가 아니라 전혀 다른 아키텍처적 주장입니다.

주장: 이제 제어 플레인이 규모의 단위가 됩니다. 클러스터는 그렇지 않습니다.

대부분의 플랫폼 아키텍처는 이 가정을 중심으로 설계되지 않았습니다. 여전히 옛 경계에 기반해 운영되고 있으며, 바로 이 불일치가 이 글의 핵심 내용입니다.

클러스터‑경계 모델

모델이 등장했을 때는 의미가 있었었습니다:

• Kubernetes 컨트롤 플레인에는 실제 규모 제한이 있었습니다.
• 정책 적용은 클러스터‑스코프였습니다.
• 가시성은 클러스터‑로컬이었습니다.
• 용량 풀은 해당 컨트롤 플레인이 관리할 수 있는 노드 그룹에 물리적으로 연결되어 있었습니다.

이것은 즉각적인 문제를 해결했지만, 동시에 조용히 복합되는 다른 종류의 문제를 만들었습니다:

• 단편화된 용량 – 한 클러스터의 유휴 용량을 다른 클러스터에서 여유가 부족한 워크로드가 사용할 수 없었습니다.
• 중복된 정책 – 각 클러스터마다 자체 RBAC, 네트워크 정책, 입장 제어가 필요했습니다. 변경 사항은 모든 클러스터에 전파되어 구조적 편차가 발생했습니다.
• 분리된 가시성 – 메트릭과 로그가 클러스터‑로컬이었습니다. 시스템 전체 상태를 이해하려면 수십 개의 독립적인 소스에서 신호를 이어 붙여야 했습니다.
• 복합적인 운영 오버헤드 – 각 클러스터는 수명 주기 관리, 업그레이드, 장애 대응이 필요한 개별 객체였습니다.

산업계는 대안인 컨트롤 플레인 자체를 확장하는 것이 현실적인 옵션이 아니었기 때문에 클러스터를 계속 늘리는 것을 정상화했습니다. 지금까지는요.

GKE Hypercluster: 아키텍처 경계 발표

GKE Hypercluster는 용량 발표가 아닙니다. 아키텍처 경계 발표입니다:

단일 Kubernetes‑준수 제어 플레인이 여러 Google Cloud 지역에 걸쳐 256 000개의 노드를 관리하고, 분산 인프라를 통합된 용량 예비군으로 취급한다는 것은 경계가 어디에 있어야 하는지에 대한 주장입니다. 클러스터가 아니라 제어 플레인에 있습니다.

제어 플레인 경계

제어 플레인 경계는 스케줄링 권한, 정책 집행 및 용량 관리가 통합되는 논리적 경계입니다. 지난 10년 동안 그 경계는 필연적으로 클러스터에 있었습니다. Hypercluster는 Google이 그럴 필요가 없다는 신호입니다.

제어 플레인 경계가 클러스터‑스코프에서 플릿‑스코프로 바깥쪽으로 이동하면:

1. 용량 계획이 전 세계적으로 이루어집니다.
2. 정책이 클러스터가 아닌 제어 플레인의 관심사가 됩니다.
3. 스케줄링이 통합된 다지역 풀 전체에 대한 용량 오케스트레이션이 됩니다.
4. 장애 도메인이 재정의됩니다.

이는 GKE에만 국한된 개발이 아니라, 아키텍처 중심축이 어디로 이동하고 있는지에 대한 신호입니다.

오늘날에도 여전히 널리 쓰이는 네 가지 클러스터‑스코프 가정

1. 클러스터를 운영 경계로 – 런북, 업그레이드 주기, 인증서 교체 … 모두 클러스터 범위 내에서 이루어짐.
2. 클러스터를 정책 경계로 – RBAC, 네트워크 정책, 어드미션 웹훅 … 모두 클러스터 스코프에 적용되고, 플릿 내 모든 클러스터에 중복되며 시간이 지나면서 드리프트 발생.
3. 클러스터를 용량 경계로 – 클러스터 자동 스케일러, 노드 풀, 리소스 쿼터 … 모두 클러스터 내부에 정의됨. 클러스터 간 용량 인식을 위해서는 외부 도구나 수동 조정이 필요.
4. 클러스터를 장애 경계로 – 블라스트‑반경 가정 및 가용 영역 매핑이 클러스터를 자연스러운 장애 단위로 설정함.

이러한 가정은 제어 플레인이 이를 초과해 확장될 수 없을 때 올바른 아키텍처 선택이었지만, 제어 플레인 경계가 외부로 이동하면 아키텍처 부채가 된다.

제어 플레인 경계가 이동하면 무엇이 변하는가

• 용량 계획이 클러스터‑로컬이 아니다.

  • “이 클러스터는 얼마나 여유가 있는가?” 라는 질문은 틀렸다.
  • 올바른 질문은 “이 스케줄링 도메인에서 사용 가능한 용량은 얼마인가?” — 이는 지역 및 노드 유형을 넘을 수 있다.

• 정책이 기본적으로 클러스터‑스코프가 될 수 없다.

  • 운영 비용으로 받아들여졌던 정책 복제는 통합 스케줄링 도메인 전반에 걸친 설계 불일치가 된다.

• 장애 도메인이 클러스터 경계와 깔끔하게 정렬되지 않는다.

  • 제어‑플레인‑경계 규모에서의 블라스트‑반경 설계는 명시적인 아키텍처 결정이며, 클러스터‑토폴로지 기본값이 아니다.

• 관측성은 제어‑플레인‑전체 상태를 모델링해야 한다.

  • 클러스터‑로컬 메트릭은 로컬 상태를 설명한다. 플릿‑전체 스케줄링 결정은 플릿‑전체 가시성을 필요로 한다. 대시보드가 보여주는 것과 시스템이 실제로 수행하는 사이의 격차는 스케줄링 도메인이 확대될 때 의도적인 계측 없이 줄어들지 않는다.

• 스케줄링은 용량 오케스트레이션이 되며, 단순히 노드 배치가 아니다.

  • 클러스터‑스코프 쿠버네티스 스케줄링은 이진‑패킹 문제이다.
  • 제어‑플레인‑경계 스코프에서는 용량 할당 문제이다. 다른 사고 모델, 다른 도구, 다른 운영 규율이 필요하다.

이것이 쿠버네티스 운영이 분산 제어‑플레인 설계가 되는 지점이다. 그것이 실제 변화이며, 칩 수가 아니라는 점이다.

실제 요점

Hypercluster에서 제시한 헤드라인 수치는 백만 개의 칩입니다. 이것에 집중하는 것은 잘못된 접근입니다.

Google은 백만 개의 칩을 관리해야 한다고 말하는 것이 아닙니다. Google이 말하고자 하는 것은 다음 인프라 병목 현상은 컴퓨팅이 아니라, 컴퓨팅을 제어하는 컨트롤 플레인이다는 것입니다.

클러스터를 곱해서 확장하고 있는 팀들은 어제의 병목 현상을 해결하고 있는 겁니다. 기존 모델에 따라 추가되는 모든 클러스터는 마이그레이션 논의가 필요하게 될 것입니다.

제어 플레인 경계가 이동하고 있습니다

클러스터‑복제 아키텍처의 비용은 단순히 운영 오버헤드만이 아닙니다.
이는 산업계가 넘어가고 있는 경계 가정의 구조적 비용입니다.

제어‑플레인 경계는 GKE 기능이 아닙니다. 이는 분산 인프라스트럭처에서 다음 아키텍처 강제 요소입니다.

다른 사람들에게 중요한 아키텍처 질문은 Hypercluster를 채택할지 여부가 아니라, 여러분의 플랫폼 설계가 이미 변화하고 있는 경계 가정에 기반하고 있는가 입니다.

클러스터 복제가 옳았던 이유—당시

Kubernetes 클러스터 복제는 실수가 아니었습니다. 이는 실제 제약에 대한 올바른 아키텍처 대응이었습니다: 제어 플레인이 충분히 확장되지 않아 복제가 필요했습니다.

그 제약은 이제 직접적으로 도전받고 있습니다. 제어 플레인 경계—스케줄링 권한, 정책 집행 및 용량 관리가 통합되는 논리적 경계—는 클러스터 범위가 아니라 플릿 범위에 있어야 합니다. 구글은 Next ’26에서 이를 공개적으로 선언했습니다.

기존 가정들

대부분의 플랫폼 아키텍처는 여전히 클러스터를 그 경계로 설계되어 있습니다. 이러한 설계를 이끈 네 가지 가정은 다음과 같습니다:

• 클러스터를 운영 경계로
• 클러스터를 정책 경계로
• 클러스터를 용량 경계로
• 클러스터를 장애 경계로

이 가정들은 한계가 낮을 때는 옳았지만, 한계가 상승하면 아키텍처 부채가 됩니다.

“백만 칩” 이야기가 놓치는 것

백만 칩이라는 숫자가 핵심 이야기가 아닙니다. 핵심은 그것이 병목 현상이 어디로 이동하고 있는지를 시사한다는 점입니다. 10년 동안 팀들은 제어‑플레인 한계에 도달하지 않기 위해 클러스터를 추가했습니다. 그 한계는 단지 이동했을 뿐입니다.

핵심 질문은 여러분의 아키텍처가 제약을 위해 설계되었는가, 아니면 제약이 해결을 막고 있던 문제를 위해 설계되었는가 입니다.

결론

제어 플레인 경계가 이동했습니다. 대부분의 아키텍처는 아직 이동하지 않았습니다.

Originally published at rack2cloud.com.