![[k8s] GKE 운영 1년 회고: 성공 사례와 놓쳤던 실수들](https://blog.pswq.net/wp-content/uploads/2026/07/gke-operations-1-year-retrospective-successes-and-mistakes-thumbnail.jpg)
목차
- 1. 왜 GKE 운영 회고가 중요했는가
- 2. GKE를 쉽게 설명하면 뭐가 좋은가
- 3. 1년 운영하면서 성공했던 선택들
- 3-1. Node Pool을 역할별로 분리한 것
- 3-2. 배포 파이프라인을 일찍 표준화한 것
- 3-3. 관측성부터 깔고 간 것
- 4. 실전 구현: 제가 정착시킨 기본 운영 방식
- 4-1. 클러스터 접속과 기본 점검
- 4-2. 애플리케이션 배포 매니페스트 예시
- 4-3. Ingress 구성 예시
- 5. 놓쳤던 실수들: 문서에선 잘 안 보이던 운영 함정
- 5-1. 리소스 요청치 없이 시작한 실수
- 5-2. 권한 모델을 늦게 정리한 실수
- 5-3. 로그는 쌓이는데 분석 기준이 없던 실수
- 6. ⚠️ 트러블슈팅: 실제로 시간을 잡아먹었던 문제들
- 6-1. 파드는 정상인데 서비스가 안 열리던 문제
- 6-2. 오토스케일링이 기대처럼 안 움직이던 문제
- 6-3. 비용이 천천히 새던 문제
- 7. 검증과 결과: 운영이 안정됐다고 느낀 기준
- 7-1. 운영 방식 비교 표
- 8. 자주 묻는 질문과 운영 팁
- 8-1. GKE가 있으면 Kubernetes 운영이 쉬워지나요?
- 8-2. 처음부터 완벽한 구조를 만들어야 하나요?
- 8-3. 어떤 지표부터 봐야 하나요?
- 9. 마무리: GKE 운영 경험에서 남은 교훈
[k8s] GKE 운영 1년 회고: 성공 사례와 놓쳤던 실수들
GKE 운영 회고를 한 번 정리해봐야겠다고 마음먹은 이유가 있습니다. Kubernetes(쿠버네티스) 자체는 이제 낯설지 않은 기술이 됐는데, 막상 Google Kubernetes Engine(구글 쿠버네티스 엔진, GKE)를 1년 정도 운영해보면 문서에서 보이던 장점과 실제 운영에서 체감하는 포인트가 꽤 다르거든요. 저도 처음엔 “관리형 Kubernetes면 운영 부담이 확 줄겠지?”라고 생각했었는데, 실제로 써보니까 줄어드는 부담도 분명 있었고, 대신 다른 종류의 실수가 새로 생기더라고요. 이번 글은 그런 관점에서 정리한 GKE 운영 회고입니다.
특히 홈랩과 회사 환경을 오가며 느낀 점이 비슷했습니다. 클러스터를 만드는 건 빠른데, 클라우드 운영의 난이도는 배포 그 자체보다 권한, 네트워크, 비용, 관측성 같은 주변 요소에서 올라가더라고요. 혹시 지금 GKE를 막 도입하셨거나, 이미 운영 중인데 “왜 자꾸 예상 밖의 이슈가 생기지?” 싶으셨다면 이 글이 꽤 현실적인 체크리스트가 될 겁니다.
GKE 클러스터, 로드밸런서, Ingress(인그레스, 외부 트래픽 진입점), 모니터링 구성까지 한눈에 보이는 아키텍처 예시입니다.
1. 왜 GKE 운영 회고가 중요했는가
제가 느낀 가장 큰 차이는 이겁니다. 쿠버네티스를 설치하는 능력과 쿠버네티스를 안정적으로 운영하는 능력은 완전히 다르다는 점입니다. 온프레미스에서는 제어권이 많아서 불편해도 원인을 깊게 파고들 수 있었는데, GKE 같은 관리형 서비스에서는 편한 대신 추상화가 한 겹 더 들어갑니다. 이게 장점이자 함정이더라고요.
쉽게 말해, GKE는 컨트롤 플레인(control plane, 클러스터 제어 영역)을 많이 대신 관리해주니까 운영 진입 장벽은 낮아집니다. 근데 워크로드(workload, 실제 애플리케이션 실행 단위), 노드(node, 컨테이너가 올라가는 서버 자원), 네트워크 정책, 비용 구조는 결국 우리가 책임져야 합니다. 그래서 GKE 운영 경험은 “쿠버네티스를 얼마나 아느냐”보다 “어디까지 자동화에 기대고, 어디서부터 운영 원칙을 세우느냐”가 더 중요했습니다.
2. GKE를 쉽게 설명하면 뭐가 좋은가
처음 접하시는 분 기준으로 아주 단순하게 설명해보면 이렇습니다.
- Kubernetes(쿠버네티스): 컨테이너를 여러 대 서버에 나눠 안정적으로 배포하고 관리하는 플랫폼입니다.
- GKE: 그 Kubernetes를 Google Cloud에서 관리형으로 제공하는 서비스입니다.
- Ingress(인그레스): 외부에서 들어오는 HTTP/HTTPS 요청을 내부 서비스로 연결하는 관문입니다.
- Node Pool(노드 풀): 비슷한 성격의 노드들을 묶어서 운영하는 단위입니다.
- HPA(Horizontal Pod Autoscaler, 수평 자동 확장): 트래픽이나 리소스 사용량에 따라 Pod(파드, 컨테이너 실행 단위) 수를 자동으로 늘리거나 줄입니다.
제가 직접 해보니 GKE의 진짜 장점은 “초기 구축이 편하다”보다 기본기 있는 팀이 운영 표준을 빠르게 정착시키기 좋다는 데 있었어요. 클러스터 생성, 로드밸런서 연동, IAM(아이엠, 권한 관리), 모니터링 연계 같은 기본 골격이 잘 맞물리거든요. 반대로 기본 원칙 없이 시작하면 편한 만큼 더 빨리 꼬입니다. 이거 진짜 그렇더라고요.
3. 1년 운영하면서 성공했던 선택들
3-1. Node Pool을 역할별로 분리한 것
처음엔 하나의 노드 풀로 다 돌려도 되겠지 싶었습니다. 근데 배치 작업(batch job)과 사용자 트래픽을 받는 웹 서비스가 한곳에 섞이니까 스케줄링이 생각보다 지저분해졌습니다. 이후엔 역할별로 나눴어요.
- 웹 애플리케이션용 노드 풀
- 배치 작업용 노드 풀
- 운영 도구용 노드 풀
이렇게 나누니까 자원 격리(resource isolation, 리소스 분리)가 쉬워졌고, 장애 분석도 빨라졌어요. “어디가 문제인지”가 훨씬 선명해집니다.
3-2. 배포 파이프라인을 일찍 표준화한 것
CI/CD(지속적 통합/지속적 배포) 흐름을 초기에 통일한 것도 컸습니다. 이미지 태그 규칙, 배포 순서, 롤백 기준을 정해두면 사람마다 다르게 배포하는 사고를 많이 줄일 수 있어요. 사실 장애 중 꽤 많은 비율이 기술 난이도보다 절차 부재에서 나오거든요.
3-3. 관측성부터 깔고 간 것
Logging(로깅, 로그 수집), Monitoring(모니터링, 지표 수집), Alerting(알림, 이상 징후 통지)을 초반에 정리해둔 게 운영 피로도를 크게 낮췄습니다. 처음엔 귀찮아도, 나중에 장애가 터지면 그 투자금이 그대로 돌아옵니다. 드디어 됐다 싶었던 순간이 이런 데서 나왔습니다.
4. 실전 구현: 제가 정착시킨 기본 운영 방식
여기서는 아주 복잡한 구조보다, 운영하면서 무난하게 오래 버틴 기본 틀을 예시로 보여드리겠습니다. 환경마다 다르겠지만 시작점으로는 충분합니다.
- 클러스터와 기본 네임스페이스(namespace, 리소스 논리 분리 공간)를 나눕니다.
- 워크로드 특성에 따라 노드 풀을 분리합니다.
- Ingress와 TLS(전송 구간 암호화)를 표준화합니다.
- 리소스 요청치(requests)와 제한치(limits)를 반드시 넣습니다.
- 배포 전에 헬스 체크와 롤링 업데이트 기준을 검증합니다.
4-1. 클러스터 접속과 기본 점검
gcloud container clusters get-credentials my-gke-cluster --region asia-northeast3 --project my-project
kubectl get nodes
kubectl get ns
kubectl get pods -A이 단계는 별거 아닌 것 같아도 중요해요. 저도 초반엔 권한이 안 맞아서 접속은 되는데 일부 리소스가 안 보이는 상황을 겪었거든요. 접속 직후엔 노드 상태, 네임스페이스 목록, 전체 파드 상태를 한 번에 보는 습관을 들였습니다.
4-2. 애플리케이션 배포 매니페스트 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
namespace: prod
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: gcr.io/my-project/web-app:stable
ports:
- containerPort: 8080
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
name: web-app
namespace: prod
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080여기서 중요한 포인트! requests/limits를 빼먹으면 초반에는 멀쩡해 보여도 운영이 길어질수록 스케줄링 품질이 흔들립니다. 그리고 readiness probe(레디니스 프로브, 트래픽 받을 준비 확인)와 liveness probe(라이브니스 프로브, 살아있는지 확인)는 꼭 분리해서 생각하시는 게 좋습니다. 저도 처음엔 둘을 비슷하게 봤는데, 장애 대응할 때 차이가 꽤 커요.
4-3. Ingress 구성 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-app-ingress
namespace: prod
annotations:
kubernetes.io/ingress.class: "gce"
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-app
port:
number: 80실제로 써보니까 Ingress는 단순히 외부 공개용 설정 파일이 아니라, 운영 책임 경계가 모이는 지점이더라고요. 인증서, 경로 라우팅, 헬스 체크, 방화벽, DNS까지 다 엮이거든요.
배포된 애플리케이션이 Service와 Ingress를 통해 외부 요청을 받는 구조를 시각화한 예시입니다.
5. 놓쳤던 실수들: 문서에선 잘 안 보이던 운영 함정
5-1. 리소스 요청치 없이 시작한 실수
이건 정말 많이들 겪습니다. 초반 테스트에서는 다 잘 돼요. 그래서 “일단 배포부터 하자” 하고 requests/limits를 뒤로 미루기 쉽습니다. 저도 그랬습니다 ㅎㅎ 근데 운영 기간이 길어지면 특정 워크로드가 노드를 잠식하고, 다른 서비스의 응답성이 흔들립니다.
해결 방법은 단순해요. 처음부터 보수적인 기본값이라도 넣고 시작하는 겁니다. 완벽한 값이 아니어도 괜찮습니다. 없는 것보다 훨씬 낫거든요.
5-2. 권한 모델을 늦게 정리한 실수
IAM과 Kubernetes RBAC(Role-Based Access Control, 역할 기반 접근 제어)를 뒤늦게 정리하면 운영자가 늘수록 위험이 커집니다. 특히 누가 클러스터 관리자 권한을 갖는지, 누가 배포만 할 수 있는지, 누가 시크릿(secret, 민감 정보)을 볼 수 있는지 기준이 애매하면 사고가 나더라고요.
처음엔 저도 “팀이 작으니까 일단 넓게 열자”라고 생각했었는데, 이게 나중에 회수 비용이 더 커요. 최소 권한(least privilege, 필요한 최소 권한만 부여) 원칙은 빨리 적용할수록 편합니다.
5-3. 로그는 쌓이는데 분석 기준이 없던 실수
로그를 모으는 것과 로그를 운영에 쓰는 건 달라요. 에러 레벨 구분, 요청 ID(request ID, 요청 추적 식별자), 배포 버전 정보가 없으면 로그가 많아도 분석 속도가 안 나옵니다. 처음엔 이게 뭔가 싶었는데, 결국 로그 포맷 표준화가 먼저였습니다.
6. ⚠️ 트러블슈팅: 실제로 시간을 잡아먹었던 문제들
6-1. 파드는 정상인데 서비스가 안 열리던 문제
가장 당황스러운 유형 중 하나입니다. kubectl get pods에서는 정상으로 보이는데, 외부에서는 접속이 안 됩니다. 이런 경우 저는 아래 순서로 확인했습니다.
- Pod readiness 상태 확인
- Service selector가 Deployment label과 일치하는지 확인
- Ingress backend 연결 상태 확인
- DNS 반영 여부 확인
- 방화벽/헬스 체크 정책 확인
kubectl get pods -n prod
kubectl describe service web-app -n prod
kubectl describe ingress web-app-ingress -n prod
kubectl get endpoints web-app -n prod실제로는 selector 오타나 readiness 실패가 생각보다 많았어요. 겉으로는 작은 실수인데 장애 체감은 크게 오더라고요.
6-2. 오토스케일링이 기대처럼 안 움직이던 문제
HPA를 걸어두면 자동으로 다 해결될 거라 기대하기 쉽습니다. 근데 메트릭(metric, 측정 지표) 기준이 애매하거나 애플리케이션이 스케일 아웃(scale-out, 인스턴스 수 확장)에 적합하지 않으면 기대만큼 반응하지 않더라고요. CPU만 보고 확장하면 실제 병목이 I/O나 DB 연결 수에 있을 수도 있거든요.
그래서 저는 확장 정책을 신뢰하기 전에 병목 지점을 먼저 확인하는 쪽으로 바꿨어요. 이건 GKE라서가 아니라 Kubernetes 운영 전반의 교훈이었습니다.
6-3. 비용이 천천히 새던 문제
운영 초반엔 성능과 안정성에 집중하느라 비용은 뒤로 밀리기 쉽습니다. 저도 그랬고요. 그런데 사용하지 않는 로드밸런서, 과하게 큰 노드, 낮과 밤 차이가 큰 서비스의 고정 리소스가 비용을 서서히 끌어올립니다.
해결 포인트는 세 가지였습니다.
- 유휴 리소스 정기 점검
- 환경별 리소스 상한선 정의
- 노드 풀 목적 분리와 요청치 재조정
비용은 어느 날 갑자기 터지지 않고 조용히 새는 경우가 많아요. 그래서 월말보다 주 단위 점검이 더 효과적이더라고요.
7. 검증과 결과: 운영이 안정됐다고 느낀 기준
제가 1년쯤 지나서 “이제 좀 운영 체계가 잡혔다”라고 느낀 기준은 화려한 대시보드가 아니었습니다. 아래 같은 변화가 보이면 꽤 건강한 상태예요.
- 배포 실패 원인을 팀원들이 비슷한 순서로 추적할 수 있음
- 장애가 나도 어느 레이어에서 막혔는지 빠르게 좁혀짐
- 리소스 사용량과 트래픽 패턴의 관계가 보임
- 온콜(on-call, 장애 대응 대기) 피로도가 줄어듦
- 신규 서비스 온보딩 시간이 짧아짐
결국 좋은 운영은 “문제가 아예 없는 상태”가 아니라 문제가 생겨도 예측 가능한 방식으로 다루는 상태에 가깝습니다. 이 부분은 GKE 운영 회고를 쓰면서도 다시 느꼈네요.
CPU, 메모리, 파드 수, 배포 상태를 함께 보는 운영 대시보드 예시입니다.
7-1. 운영 방식 비교 표
| 항목 | 초기 운영 방식 | 1년 후 정착 방식 |
|---|---|---|
| 노드 구성 | 단일 노드 풀 중심 | 워크로드별 노드 풀 분리 |
| 배포 기준 | 서비스별 제각각 | 공통 매니페스트와 파이프라인 사용 |
| 권한 관리 | 넓은 권한 부여 | 최소 권한 원칙 적용 |
| 관측성 | 로그 중심 확인 | 로그, 메트릭, 알림 기준 통합 |
| 비용 관리 | 월말 점검 | 주 단위 점검과 리소스 재조정 |
8. 자주 묻는 질문과 운영 팁
8-1. GKE가 있으면 Kubernetes 운영이 쉬워지나요?
네, 분명 쉬워지는 부분이 있어요. 다만 운영 책임이 사라지는 건 아닙니다. 제어 영역 일부를 대신 관리해줄 뿐, 애플리케이션 특성, 네트워크 설계, 비용 최적화는 여전히 팀의 몫입니다.
8-2. 처음부터 완벽한 구조를 만들어야 하나요?
아닙니다. 오히려 처음부터 너무 크게 설계하면 유지가 어려워요. 제가 추천하는 건 작지만 일관된 표준입니다. 네임스페이스 규칙, 배포 형식, 리소스 요청치, 로그 포맷 이 정도만 먼저 맞춰도 훨씬 낫습니다.
8-3. 어떤 지표부터 봐야 하나요?
가장 먼저는 CPU, 메모리, 재시작 횟수, readiness 실패, 배포 이벤트입니다. 그 다음에 애플리케이션 응답 시간과 에러율을 연결해서 보시면 돼요. 인프라 지표와 서비스 지표를 따로 보면 원인 파악이 늦어지더라고요.
운영 표준, 권한, 관측성, 비용 점검 항목을 한 장으로 요약한 체크리스트 이미지입니다.
9. 마무리: GKE 운영 경험에서 남은 교훈
이번 GKE 운영 회고를 정리하면서 다시 느낀 건, 결국 운영의 품질은 특정 기능 하나보다 작은 원칙들을 얼마나 꾸준히 지키느냐에 달려 있다는 점이었습니다. 클러스터를 잘 만드는 것보다, 문제를 빨리 좁히고 반복 실수를 줄이는 구조를 만드는 게 훨씬 중요했어요.
제가 직접 해보니 성공 사례는 대부분 화려하지 않았습니다. 노드 풀을 분리하고, 리소스 요청치를 넣고, 권한을 조이고, 로그 기준을 맞추는 식의 기본기였어요. 반대로 놓쳤던 실수들도 대단한 기술적 난제가 아니라 “나중에 하자”라고 미뤘던 운영 습관에서 시작됐습니다. 사실 이게 제일 무섭거든요.
혹시 지금 Google Kubernetes Engine을 도입하려고 하시거나, 이미 쓰고 있는데 운영이 어수선하다고 느끼신다면 먼저 화려한 도구보다 배포 표준화, 권한 모델, 관측성, 비용 점검 루틴부터 다시 보시는 걸 추천드립니다. 다음 글에서는 GKE 환경에서 Ingress와 내부 서비스 분리 전략, 그리고 운영용 대시보드 구성 기준도 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 Kubernetes 기본 운영 원칙과 함께 보시면 더 이해가 쉬우실 겁니다.
🎉 한 줄로 정리하면 이렇습니다. GKE는 편한 플랫폼이지만, 편하다고 해서 운영 원칙까지 대신 만들어주지는 않습니다. 이 부분만 초반에 잡아두시면 1년 뒤 회고가 훨씬 덜 아프실 겁니다.
![[k8s] GKE WireGuard 보안 취약점 분석: 매니지드 쿠버네티스 보안 강화 전략](https://blog.pswq.net/wp-content/uploads/2026/05/gke-wireguard-security-vulnerability-analysis-thumbnail.jpg)
