Google Kubernetes Engine

컨테이너가 많아질수록 어떤 노드에 어떤 파드를 두고, 죽은 파드를 어떻게 복구하고, 트래픽을 어떻게 나눌지 수동으로 관리할 수 없습니다. Kubernetes를 직접 운영하면 그 제어면까지 같이 떠안게 됩니다. 서비스 수가 늘수록 배포 표준과 운영 규칙을 팀 단위로 맞추는 일도 급격히 어려워집니다.

컨테이너가 표준이 되면서 컨테이너를 어디에 둘지 사람 손으로 계속 정하는 방식은 한계가 왔습니다. Kubernetes는 그 조율을 표준화했고, GKE는 그 조율 계층을 관리형으로 제공하기 위해 나왔습니다. 플랫폼 팀이 공통 운영 기준을 만들고 제품 팀이 그 위에서 자율 배포하는 구조와도 잘 맞습니다.

GKE는 관리형 컨트롤 플레인을 제공하고, 워커 노드는 노드 풀로 묶습니다. 디플로이먼트(Deployment)가 배포 단위를 만들고 서비스(Service)와 인그레스(Ingress)가 트래픽을 연결하며, Autopilot은 노드 용량 관리까지 넘겨받습니다. HPA, PDB 같은 Kubernetes 패턴을 조합하면 가용성과 배포 안정성을 정책으로 고정할 수 있습니다.

GKE와 Cloud Run은 둘 다 컨테이너를 실행하지만, Cloud Run은 인프라를 감추고 HTTP 워크로드에 맞추는 반면 GKE는 스케줄링, 사이드카, StatefulSet 같은 Kubernetes 제어를 그대로 드러냅니다. 여러 서비스와 운영 규칙을 세밀하게 묶어야 하면 GKE, 단순한 컨테이너 배포면 Cloud Run이 맞습니다.

마이크로서비스, 카나리나 블루그린 배포, 상태를 가진 워크로드, Kubernetes 생태계 도구가 필요한 운영 환경에 적합합니다. 서비스 수가 적고 웹 요청만 받는다면 더 단순한 실행 계층이 충분합니다. 멀티팀 환경에서 공통 배포 플랫폼을 만들 때도 GKE의 효과가 큽니다.