이 글은 개인 GCP 계정으로 K8s/GKE/GitHub Actions/ArgoCD 를 직접 띄워본 인프라 학습 시리즈 중 (4-1) Kubernetes 클러스터를 GKE 에 연결하는 단계 의 기록이다. 회사 시스템과 무관한 개인 학습 트랙이고, 콘솔의 옵션을 어떻게 선택했고 왜 그렇게 선택했는지를 본문 안에 명시한다. 시리즈 전체 맥락은 opener 글 참고.
이 글의 목적
이 글의 목적은 Kubernetes 클러스터를 Google Kubernetes Engine(GKE)에 연결하는 방법을 단계별로 설명하는 것입니다. 이를 통해 클라우드 컴퓨팅 환경에서 Kubernetes를 설정하고 활용하는 데 필요한 기본적인 지식을 얻을 수 있습니다.
한눈에 보기
GKE에서 Kubernetes 환경을 설정하는 단계를 제시합니다. GKE에서는 Kubernetes Engine API 활성화부터 클러스터 생성, 그리고 최종적으로 클러스터에 접속하는 방법까지 다룹니다.
이 단계의 목적: GKE에서 작업 가능한 환경을 구성한다.
- GKE에서 작업 가능한 환경을 구성한다.
- GKE 시작하기https://cloud.google.com 으로 접속한다.
Meet your business challenges head on with cloud computing services from Google, including data management, hybrid & multi-cloud, and AI & ML.
cloud.google.com
- 우측 상단의 Console 버튼을 클릭한다.
- Kubernetes Engine 버튼을 클릭한다.
- Kubernetes Engine API를 검색해서 Enable(활성화) 버튼을 클릭 한다.
- Manage 버튼을 클릭한다. 혹은 Console 화면으로 돌아가서 다시 Kubernetes Engine을 클릭한다
- Cluster 만들기 Create 버튼을 클릭한다.
- Name을 입력하고 Region을 선택한다. asia-northeast3: 서울
Next 버튼을 클릭한다.
- Next 버튼을 클릭한다.
- Access using DNS를 선택한다.
- Enable Dataplane V2 observability를 선택다. 설명: 모니터링 옵션
Next 버튼을 클릭한다.
- Advanced settings에서 Automation만 아래와 같이 설정한다.
- Create cluster 버튼을 클릭한다.
- MacOS에서 원격 접속하기
- 접속 성공!
클러스터 만들 때 선택했던 옵션과 이유
처음 GKE 콘솔에서 클러스터를 만들 때 화면의 옵션이 많아 보였지만, 의식적으로 선택한 건 두 가지뿐이고 나머지는 GCP 추천값을 그대로 따라갔다. 직접 띄워보며 정리한 본인 학습 노트라 “왜 그렇게 골랐는지” 가 다음 글의 결정으로 이어진다.
의식적으로 선택한 것
- Region: asia-northeast3 (서울) — 한국에 거주하면서 로컬 터미널로
kubectl명령을 보내는 패턴이라 latency 가 가장 자연스러운 선택이었다. us-central1 같은 free tier 가 있다는 정보도 봤지만, 응답 속도가 학습 만족감에 큰 영향을 줄 것 같아 서울로 고정. - Autopilot 모드 — yaml 만 던지면 알아서 노드 풀을 만들어주는 게 학습 초입에서 가장 편했다. 처음부터 노드 풀·autoscaling·머신 타입 선택까지 들어가면 K8s 자체 학습 시간이 부족할 것 같아 Autopilot 으로 시작.
GCP 기본 추천 그대로 둔 것
- Access using DNS — 콘솔 추천이라 그대로 선택. 명확한 이유 없이.
- Enable Dataplane V2 observability — 추천이라 켰는데, 나중에 모니터링 비용이 의외로 쌓이는 항목 중 하나라는 걸 알게 됐다 ((4-3) 비용 최적화 편 참고).
- Advanced settings → Automation — 디폴트 그대로.
흔한 함정
- Kubernetes Engine API를 활성화하지 않으면 클러스터를 만들 수 없습니다.
- 지역(Region) 선택을 잘못하면 나중에 원하는 성능을 내지 못할 수 있습니다.
다시 시작한다면 바꿀 것
7편 시리즈를 모두 끝낸 뒤의 회고:
- 처음부터 Standard 클러스터로 시작했을 것 — Autopilot 의 학습 편의성은 인정하지만, 며칠 돌려보면 비용이 명확히 더 크다. 같은 시간을 들이는 거라면 처음부터 노드 풀·머신 타입 결정을 학습 안에 포함시키는 게 K8s 운영에 더 가까운 경험이 됐을 것 같다. (4-3) 편에서 결국 Standard 로 전환한 결정이 이 회고의 결론.
- Dataplane V2 observability 는 끄는 옵션 검토 — 학습 환경에서는 모니터링 비용이 본 비용보다 의외로 큰 비중을 차지했다. 끄고 필요할 때만 켜는 게 비용 면에서 더 합리적.
- Region 은 그대로 서울 유지 — latency 효과는 명확했다. free tier 매력보다 응답 속도의 가치가 컸음.
다음 단계
ArgoCD 연동을 통해 자동 배포 파이프라인을 구성합니다.
GKE 인프라 학습 시리즈 (요약본)
- GKE 인프라 학습 시리즈 시작 (개요·계획)
- (4-1) K8S를 GKE와 연결 (현재 글)
- GKE에 직접 띄우고 비용 줄이기 (API 서버·K8s 실행·비용 최적화)
- (6) GitHub Actions
- (7) ArgoCD
- 도메인 발급 및 GKE와의 연결
📚 이 시리즈는 네이버 블로그 원본 10편을 요약·정리한 것입니다. 세부 절차를 순서대로 따라 하려면 → 네이버 블로그 원본 시리즈
답글 남기기