Kubernetes v1.37(2026년 8월 26일 출시, 코드명 Garhwal)에서 HorizontalPodAutoscaler(HPA)의 스케일 투 제로가 Beta로 올라가 기본 활성화되었습니다. 이 글은 2026년 9월 2일 공식 블로그 글을 바탕으로, 워커를 0개까지 줄였다가 다시 켜는 원리와 설정 방법, 운영 전에 알아야 할 주의점을 정리합니다.위 그림은 이 글 전체의 구조입니다. 큐 길이 같은 외부 지표를 HPA가 읽어서 워커 Pod를 0개와 10개 사이로 조절합니다. 아래에서 각 단계를 차례로 풀어 설명합니다.왜 필요한가큐를 소비하는 워커나 배치 처리기는 일감이 없는 시간에도 최소 1개의 Pod를 띄워 두는 경우가 많습니다. 이 Pod가 전용 CPU나 GPU를 점유하고 있다면 놀고 있는 시간..
Docker BuildKit의 RUN --mount=type=cache는 빌드 사이에 pip 같은 패키지 캐시 디렉터리를 보존해, 의존성 파일이 바뀌어 레이어 캐시가 깨져도 이미 받은 패키지는 다시 내려받지 않게 해 줍니다. Docker 29.1.3, buildx v0.30.1, python:3.12-slim 기준으로 직접 빌드해 다운로드 횟수를 비교했습니다.아래 그림은 같은 변경(requirements.txt에 패키지 추가)에 대해 일반 RUN과 캐시 마운트 RUN이 어떻게 다르게 동작하는지 보여줍니다.왜 필요한가Docker 이미지는 Dockerfile 명령마다 레이어를 만들고, 입력이 같으면 그 레이어를 재사용합니다. 그래서 보통 COPY requirements.txt를 소스 복사보다 먼저 두어 의존..
Docker Compose의 depends_on은 기본값에서 컨테이너가 "시작"되기만 기다릴 뿐 서비스가 "준비"되었는지는 확인하지 않습니다. 이 글에서는 busybox로 8초 뒤에 포트를 여는 가짜 DB를 만들어 healthcheck와 condition: service_healthy 유무에 따라 app의 첫 접속이 어떻게 달라지는지 직접 실행해 비교하고, retries를 너무 작게 잡았을 때의 실패 양상까지 정리합니다. (Docker 29.1.3, Docker Compose v2.40.3 기준)아래 그림은 두 설정의 차이를 한 장으로 요약한 것입니다. 위쪽은 기본 depends_on에서 app이 db 컨테이너가 뜨자마자 접속해 실패하는 흐름이고, 아래쪽은 healthcheck가 healthy를 보고한 ..
Go로 만든 간단한 HTTP 서버를 Docker 이미지로 만들 때, Dockerfile 구성만 바꿔서 이미지 크기가 어떻게 달라지는지 직접 빌드해서 비교한 기록입니다. 단일 스테이지(1.3GB), 멀티스테이지 + alpine(24MB), 멀티스테이지 + distroless(12.7MB) 세 가지를 같은 소스로 빌드했고, 환경은 Docker 29.1.3, Go 1.22(arm64)입니다.왜 필요한가컴파일 언어는 빌드할 때 필요한 것(컴파일러, 소스, 패키지 캐시)과 실행할 때 필요한 것(바이너리 하나)이 완전히 다릅니다. 단일 Dockerfile로 빌드하면 컴파일러와 소스까지 최종 이미지에 그대로 남습니다. 그 결과 이미지가 커져 레지스트리 푸시와 노드의 이미지 pull이 느려지고, 쓰지도 않는 패키지가 ..
Kustomize로 base/overlay 구조를 정리하고 나면 자연스럽게 떠오르는 질문이 있습니다. "같은 걸 Helm으로 하면 뭐가 다른가?" 입니다. 이 글은 실제로 Helm 차트를 만들고 helm lint, helm template, helm install --dry-run을 로컬에서 실행한 결과를 바탕으로, Helm의 동작 방식과 Kustomize와의 실질적인 차이를 정리합니다. 환경은 Helm v4.1.4입니다.왜 필요한가YAML을 직접 관리하다 보면 두 가지 문제에 부딪힙니다. 첫째, 환경별로(dev/staging/prod) 값만 다르고 구조는 같은 매니페스트를 중복 작성하게 됩니다. 둘째, 다른 사람이 만든 애플리케이션(예: Redis, Prometheus)을 설치할 때 그 사람의 매니페스..
kubectl 1.34 기준으로 정리합니다(내장 Kustomize v5.7.1). dev/prod처럼 환경마다 살짝씩 다른 매니페스트를 관리할 때 YAML을 통째로 복붙하는 대신 쓰는 Kustomize를, base+overlay 예제를 직접 빌드해본 결과와 함께 정리합니다.왜 필요한가같은 애플리케이션이라도 dev는 레플리카 1개면 충분하고, prod는 3개는 떠 있어야 합니다. 이미지 태그도 dev는 최신, prod는 고정된 버전을 씁니다. 이걸 deployment-dev.yaml, deployment-prod.yaml처럼 파일을 통째로 복사해서 관리하면, 나중에 공통 부분(포트, 볼륨 마운트 등)을 고칠 때 두 파일을 다 고쳐야 하고 언젠가 하나를 빼먹게 됩니다.Kustomize는 이 문제를 "공통 부..
