인프런 워밍업 클럽 4기 DevOps - 2주차 발자국

이번 주는 쿠버네티스의 핵심 리소스들을 학습하면서, 기존에 사용하던 ECS와 비교하면서 강의를 들었던 것 같습니다. 기능 자체는 대부분 유사하지만, 쿠버네티스는 선언적 구성과 리소스 중심의 구조 덕분에 운영과 관리가 더 유연하다는 느낌을 받았습니다.

ECS와 비교하며 새로웠던 점

Deployment

• ECS도 무중단 배포 지원함. minimumHealthyPercent, maximumPercent 값을 통해 배포 중 유지할 작업 수, 동시에 추가할 작업 수를 조절할 수 있음

• 쿠버네티스는 RollingUpdate 전략에서 maxSurge, maxUnavailable 설정으로 배포 중 새 Pod 생성 수와 동시에 중단 가능한 기존 Pod 수를 정밀하게 제어할 수 있음

   

Probe (헬스 체크)  

• ECS는 ALB 헬스 체크 위주. 태스크 내 애플리케이션 상태까지 세분화된 제어는 어려움.  

• 쿠버네티스는 startupProbe, readinessProbe, livenessProbe로 상태별 헬스 체크 분리 가능.  

• readinessProbe로 준비 안 된 Pod은 서비스에서 제외시켜 트래픽 유입 차단 가능.  

• 앱 기동 지연이나 일시적 장애 등 다양한 상황에 유연하게 대응 가능함.

ConfigMap / Secret  

• ECS도 환경 변수, Secrets Manager, SSM Parameter Store 등을 통한 설정 주입 가능.  

• 쿠버네티스는 설정(ConfigMap)과 민감 정보(Secret)를 리소스로 분리해 명시적으로 관리.  

• 환경 변수뿐 아니라 파일로도 마운트 가능해서 설정 주입 방식이 유연함.  

• 설정 재사용성과 형상 관리 측면에서 이점 있음.

HPA (Auto Scaling)  

• ECS도 CPU/Memory 기준 오토 스케일링 지원하고, CloudWatch 기반 커스텀 메트릭 확장 가능.  

• 쿠버네티스는 YAML로 선언하고, 애플리케이션 중심 메트릭(HPA + Metrics Server, Prometheus 등) 연동 쉬움.  

   

PVC (스토리지)  

• ECS에서는 EFS를 직접 마운트해서 사용했지만, 쿠버네티스는 PVC(PersistentVolumeClaim)를 통해 스토리지 요청과 실제 볼륨을 분리해 구성할 수 있다는 개념이 흥미로움

다음 주차도 화이팅!