k3s도 결국 Kubernetes 기반이라서 Deployment의 replica 자동 조절은 HPA로 처리하면 됨.
HPA는 Horizontal Pod Autoscaler의 약자임.
즉, CPU나 메모리 사용량을 기준으로 Pod 개수를 자동으로 늘리거나 줄이는 기능임.
예를 들어 현재 Pod가 2개인데 CPU 사용률이 계속 높으면 HPA가 Pod를 3개, 4개로 늘려줌.
반대로 사용량이 줄어들면 다시 Pod 수를 줄여줌.
1. Auto Scaling 구조
기본 구조는 이렇다.
Deployment
└─ ReplicaSet
└─ Pod 여러 개
HPA
└─ Deployment의 replica 수를 자동 조절Deployment는 Pod를 관리하고, HPA는 Deployment의 replica 수를 자동으로 변경함.
즉, HPA가 직접 Pod를 만드는 게 아니라 Deployment의 replica 값을 조절하는 방식임.
2. 먼저 metrics-server 확인 필요
HPA가 동작하려면 Kubernetes가 Pod의 CPU, 메모리 사용량을 볼 수 있어야 함.
그래서 먼저 아래 명령어가 되는지 확인해야 함.
kubectl top node
kubectl top pod -n 네임스페이스예시:
kubectl top pod -n ezaria-dev여기서 CPU, MEMORY 값이 정상적으로 나오면 HPA 설정 가능함.
안 나오면 metrics-server가 없거나 정상 동작하지 않는 상태임.
k3s는 기본적으로 metrics-server가 포함되는 경우가 많지만, 환경에 따라 꺼져 있거나 정상 동작하지 않을 수 있음.
3. 기존 Deployment에 resources 추가하기
HPA를 제대로 쓰려면 Deployment의 컨테이너에 resources 설정이 있어야 함.
예시:
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"의미는 이거임.
requests = 최소 보장 / 예약 리소스
limits = 최대 사용 가능 리소스CPU 기준으로 보면 다음과 같음.
cpu: 250m = 0.25 core
cpu: 1 = 1 core메모리 기준으로 보면 다음과 같음.
512Mi = 약 512MB
1Gi = 약 1GB즉 위 설정은 이런 의미임.
이 Pod는 CPU 0.25core, Memory 512Mi 정도는 필요함.
하지만 최대 CPU 1core, Memory 1Gi까지만 사용 가능함.4. 기존 Deployment 수정 예시
이미 Deployment가 있다면 아래 위치에 resources를 추가하면 됨.
spec.template.spec.containers.resources예시:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ezaria-api
namespace: ezaria-dev
spec:
replicas: 2
selector:
matchLabels:
app: ezaria-api
template:
metadata:
labels:
app: ezaria-api
spec:
containers:
- name: ezaria-api
image: registry.ezcaretech.com/ezaria/api:latest
ports:
- containerPort: 3000
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"적용:
kubectl apply -f deployment.yaml5. HPA 추가하기
기존 Deployment에 Auto Scaling을 붙이려면 HPA 리소스를 추가하면 됨.
CPU 기준 HPA 예시:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: ezaria-api-hpa
namespace: ezaria-dev
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: ezaria-api
minReplicas: 2
maxReplicas: 6
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70적용:
kubectl apply -f hpa.yaml확인:
kubectl get hpa -n ezaria-dev
kubectl describe hpa ezaria-api-hpa -n ezaria-dev6. HPA가 CPU 사용률 계산하는 방식
중요한 점이 있음.
HPA는 보통 limits.cpu 기준이 아니라 requests.cpu 기준으로 사용률을 계산함.
예를 들어 requests.cpu가 250m라고 가정함.
resources:
requests:
cpu: "250m"현재 Pod가 CPU 250m를 쓰고 있으면 다음과 같음.
250m / 250m = 100%현재 Pod가 CPU 500m를 쓰고 있으면 다음과 같음.
500m / 250m = 200%HPA 목표가 70%인데 실제 사용률이 200%면 replica를 늘림.
그래서 requests.cpu를 너무 낮게 잡으면 HPA가 과하게 늘어날 수 있음.
반대로 requests.cpu를 너무 높게 잡으면 실제로 바쁜데도 스케일 아웃이 잘 안 될 수 있음.
7. CPU와 Memory를 얼마나 줘야 하는지 결정하는 방법
처음부터 정확히 맞추기는 어려움.
그래서 보통은 관측 기반으로 정함.
먼저 현재 Pod 사용량을 확인함.
kubectl top pod -n ezaria-devPrometheus나 Grafana가 있다면 최근 1일 ~ 7일 정도의 CPU, Memory 사용량을 봄.
기준은 보통 이렇게 잡음.
requests.cpu = 평상시 사용량 또는 p50~p70 정도
limits.cpu = 순간 피크 대응 가능한 수준
requests.memory = 평상시 메모리 사용량보다 약간 높게
limits.memory = 피크 메모리 + 여유분예를 들어 API Pod가 평소에 이 정도 사용한다고 가정함.
CPU 평상시: 150m ~ 300m
CPU 피크: 700m
Memory 평상시: 400Mi ~ 600Mi
Memory 피크: 800Mi
그러면 아래처럼 줄 수 있음.
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"8. 실무 기준 예시
Node.js API 서버라면 시작값은 보통 이런 식으로 잡을 수 있음.
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"트래픽이 있고 메모리 사용량이 어느 정도 있는 API 서버라면 다음 정도로 시작 가능함.
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"Spring Boot처럼 기본 메모리 사용량이 큰 서버라면 다음 정도로 시작할 수 있음.
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2"
memory: "2Gi"다만 이건 정답이 아니라 시작점임.
실제 값은 운영 사용량을 보고 조정해야 함.
9. Memory 기준 HPA는 조심해야 함
CPU 기준 HPA는 비교적 자연스럽게 동작함.
트래픽이 늘면 CPU가 올라가고, replica가 늘어나면 CPU가 분산됨.
근데 Memory 기준 HPA는 조심해야 함.
메모리는 트래픽이 줄어도 바로 내려가지 않는 경우가 많음.
특히 Node.js, JVM, 캐시를 사용하는 앱은 메모리 사용량이 바로 줄지 않을 수 있음.
그래서 처음에는 CPU 기준 HPA부터 적용하는 게 안전함.
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70메모리 기준까지 같이 쓰고 싶으면 운영 데이터를 며칠 관측한 뒤 추가하는 게 좋음.
10. CPU limit도 너무 낮으면 문제 생김
CPU limit을 너무 낮게 잡으면 컨테이너가 죽지는 않음.
대신 throttling이 걸림.
즉, CPU를 더 쓰고 싶은데 제한 때문에 느려짐.
예를 들어 API 서버가 순간적으로 CPU를 1core까지 써야 하는데 limit이 500m면 응답 지연이 생길 수 있음.
그래서 CPU는 보통 아래처럼 잡는 편이 나음.
requests는 적정 수준으로 설정
limits는 피크 대응 가능하게 여유 있게 설정11. Memory limit은 신중하게 잡아야 함
Memory는 CPU랑 다름.
CPU limit 초과는 느려지는 정도지만, Memory limit 초과는 컨테이너가 죽을 수 있음.
memory limit 초과
→ OOMKilled
→ Pod 재시작그래서 memory limit은 너무 타이트하게 잡으면 안 됨.
예를 들어 평소 메모리가 700Mi까지 올라가는 서버인데 limit을 768Mi로 잡으면 위험함.
GC 타이밍이나 순간 피크 때문에 OOMKilled가 발생할 수 있음.
12. HPA 적용 후 확인할 것
HPA 적용 후 아래 명령어로 확인함.
kubectl get hpa -n ezaria-dev예시 출력:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
ezaria-api-hpa Deployment/ezaria-api 45%/70% 2 6 2여기서 45%/70%는 현재 CPU 사용률이 45%, 목표가 70%라는 뜻임.
상세 확인:
kubectl describe hpa ezaria-api-hpa -n ezaria-devDeployment replica 확인:
kubectl get deploy ezaria-api -n ezaria-devPod 확인:
kubectl get pod -n ezaria-dev -l app=ezaria-api13. 운영 적용 순서 추천
처음부터 빡세게 잡지 말고 아래 순서로 가는 게 좋음.
1. 현재 Pod CPU/Memory 사용량 확인
2. Deployment에 resources.requests/limits 추가
3. HPA는 CPU 기준으로만 먼저 적용
4. minReplicas는 현재 운영 replica 수와 동일하게 시작
5. maxReplicas는 노드 여유량 기준으로 제한
6. Grafana 또는 kubectl top으로 며칠 관측
7. requests/limits/HPA target 조정예를 들어 현재 운영 replica가 2개라면 아래 정도로 시작 가능함.
minReplicas: 2
maxReplicas: 6
averageUtilization: 70'TIL' 카테고리의 다른 글
| Terraform으로 AWS EC2 간단히 만들기 (0) | 2026.05.14 |
|---|---|
| [Terraform] 테라폼) 설치 방법 정리 (macOS, Linux, Windows) (0) | 2026.05.14 |
| DB 커넥션풀은 얼마나 해야할까? (0) | 2026.05.11 |
| Feature Flag란? (0) | 2026.05.11 |
| 네트워크 에러 Top 5 정리 (0) | 2026.05.08 |