소개
스케줄러는 Pod 를 배치하기 위해 리소스 요청량이 필요하고, kubelet 은 리소스 제한을 적용하며, HorizontalPodAutoscaler 는 메트릭과 의미 있는 사용률 기준값을 필요로 합니다. 이러한 제어 기능이 하나의 용량 관리 작업 흐름을 구성합니다.
이 실습에서는 요청량과 제한을 구성하고, 실시간 사용량을 확인하며, HPA 를 생성하고, 부하를 발생시킨 뒤, 복제본 수의 변화를 관찰합니다.
이 설정들은 서로 연결된 의존 관계를 이룹니다. CPU 요청량이 기준값을 설정하고, metrics-server 가 최근 사용량을 보고하며, HPA 가 두 값을 비교하여 복제본 수를 변경할지 결정합니다. 요청량을 생략하면 백분율 기반 CPU 사용률을 의미 있게 계산할 수 없습니다.
요청량 및 제한 설정
이 단계에서는 리소스를 명시적으로 지정하여 Kubernetes HPA 예제를 배포합니다.
**요청량 (request)**은 스케줄링에 사용되며 오토스케일링 계산의 기준이 되는 리소스 양입니다. **제한 (limit)**은 컨테이너에 적용되는 최대 사용량입니다. CPU 는 코어 또는 밀리코어 단위를 사용하며 (100m은 0.1 코어), 메모리는 Mi와 같은 바이트 단위를 사용합니다.
cd /home/labex/project/resource-autoscaling
kubectl create namespace practice-capacity
kubectl create deployment cpu-demo -n practice-capacity --image=registry.k8s.io/hpa-example:latest --replicas=1
생성된 Deployment 에 리소스 계약을 추가합니다. kubectl set resources는 Pod 템플릿을 수정하므로 롤아웃이 실행됩니다.
kubectl set resources deployment/cpu-demo -n practice-capacity --requests=cpu=100m,memory=32Mi --limits=cpu=200m,memory=64Mi
kubectl expose deployment cpu-demo -n practice-capacity --port=80 --target-port=80
kubectl rollout status deployment/cpu-demo -n practice-capacity --timeout=60s
kubectl get deployment cpu-demo -n practice-capacity -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'
100m은 CPU 코어 하나의 10 분의 1 을 의미합니다. 요청량은 스케줄링과 사용률 계산에 영향을 주며, 제한은 컨테이너의 리소스 소비량을 제한합니다.
JSONPath 출력에는 requests와 limits가 모두 포함되어야 합니다. 제한만 선언하면 HPA 의 사용률 계산 기준이 제공되지 않습니다.
deployment "cpu-demo" successfully rolled out
{"limits":{"cpu":"200m","memory":"64Mi"},"requests":{"cpu":"100m","memory":"32Mi"}}
JSON 은 키를 다른 순서로 출력할 수 있습니다. 한 줄에서 키의 위치가 아니라 네 가지 값이 모두 존재하는지 확인하세요.
리소스 메트릭 확인
이 단계에서는 준비된 메트릭 파이프라인이 정상적으로 작동하는지 확인하고 사용량을 살펴봅니다.
kubectl top은 운영체제의 top 명령과 비슷한 방식으로 최근 사용량을 보여 주는 스냅샷 도구입니다. 구성된 요청량이나 제한은 표시하지 않으며, 이러한 값은 워크로드 사양에 계속 포함되어 있습니다.
cd /home/labex/project/resource-autoscaling
kubectl get deployment metrics-server -n kube-system
for attempt in $(seq 1 18); do
if kubectl top nodes >/dev/null 2>&1 && kubectl top pods -n practice-capacity --containers >/dev/null 2>&1; then
break
fi
echo "Waiting for the first metrics sample (${attempt}/18)..."
sleep 5
done
kubectl top nodes
kubectl top pods -n practice-capacity --containers
kubectl top은 리소스 요청량이 아니라 최근 메트릭을 읽습니다. 메트릭이 표시되기까지 약간의 시간이 걸릴 수 있으므로, 새 Pod 에 아직 샘플이 없다면 몇 초 후 다시 시도하세요.
위의 반복문이 재시도를 대신 수행합니다. 최대 18 번까지 조용히 확인하고, 각 시도 사이에 5 초씩 기다린 다음 샘플을 사용할 수 있게 되면 두 개의 top 명령을 화면에 출력합니다. 확인 과정에서 >/dev/null은 일반 출력을 버리고, 2>&1은 오류 출력을 같은 위치로 보냅니다. 따라서 예상되는“아직 메트릭이 준비되지 않음”메시지가 터미널에 표시되지 않습니다. 최근 사용량을 수집하는 파이프라인에서는 이러한 지연이 정상이며, Pod 에 문제가 발생했다는 뜻이 아닙니다.
노드와 Pod 의 값은 환경에 따라 달라지므로 정확한 수치보다 CPU 와 메모리 열이 표시되는지에 집중하세요. 하나의 Pod 에 컨테이너가 여러 개 포함된 경우 --containers를 사용하면 컨테이너별 사용량을 구분할 수 있습니다.
테스트 환경에서는 다음과 같은 노드 테이블과 컨테이너별 테이블이 출력되었습니다.
NAME CPU(cores) CPU(%) MEMORY(bytes) MEMORY(%)
labex-v135 182m 9% 1602Mi 44%
POD NAME CPU(cores) MEMORY(bytes)
cpu-demo-... hpa-example 1m 9Mi
실제 값은 측정 결과이므로 위와 다르게 나타나는 것이 정상입니다.
HorizontalPodAutoscaler 생성
이 단계에서는 CPU 평균 사용률 목표를 30% 로 설정하고 복제본 수를 1 개에서 4 개 사이로 조정합니다.
CPU 요청량이 100m일 때 30% 목표는 Pod 하나당 평균 CPU 사용량 약 30m에 해당합니다. HPA 는 Deployment 가 원하는 복제본 수를 조정하지만 min=1보다 낮추거나 max=4보다 높이지는 않습니다.
cd /home/labex/project/resource-autoscaling
kubectl autoscale deployment cpu-demo -n practice-capacity --cpu=30% --min=1 --max=4
kubectl get hpa cpu-demo -n practice-capacity
kubectl describe hpa cpu-demo -n practice-capacity
사용률은 CPU 요청량 100m을 기준으로 측정됩니다. 이 요청량이 없으면 백분율 기반 CPU 목표를 계산할 기준값이 없습니다.
현재 kubectl autoscale 문법에서는 --cpu=30%처럼 백분율을 명시적으로 작성합니다. 이는 Kubernetes 1.35 에서 더 이상 사용하지 않도록 안내되는 기존 --cpu-percent 플래그를 대체합니다.
처음 몇 초 동안은 새 메트릭 샘플이 수집되는 동안 TARGETS 열에 <unknown>이 표시될 수 있습니다. describe hpa 명령을 사용하면 컨트롤러가 사용할 수 있는 메트릭을 확보했는지 판단하는 데 도움이 되는 조건과 이벤트를 확인할 수 있습니다.
따라서 다음과 같은 초기 테이블이 표시되어도 오류를 의미하지 않습니다.
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: <unknown>/30% 1 4 0
컨트롤러의 다음 동기화가 완료되면 <unknown>이 측정된 백분율로 바뀌고, REPLICAS에는 Deployment 의 실제 복제본 수가 반영됩니다.
부하 생성 및 스케일링 관찰
이 단계에서는 최대 60 초 동안 Service 에 반복적으로 요청을 보내는 임시 클라이언트를 실행합니다.
BusyBox 의 timeout 명령은 중첩된 요청 반복문을 60 초 동안 실행합니다. while 반복문은 CPU 를 많이 사용하는 데모 엔드포인트를 계속 호출하고, >/dev/null은 응답 본문을 버려 터미널을 읽기 쉽게 유지합니다. 제한 시간에 도달하면 일반적으로 0 이 아닌 상태 코드가 반환되므로 || true를 사용해 계획된 종료를 정상 완료로 처리합니다.
cd /home/labex/project/resource-autoscaling
kubectl run load-generator -n practice-capacity --image=busybox:1.36 --image-pull-policy=IfNotPresent --restart=Never --rm -i -- sh -c 'timeout 60 sh -c "while true; do wget -qO- http://cpu-demo >/dev/null; done" || true'
kubectl get hpa cpu-demo -n practice-capacity
kubectl get deployment cpu-demo -n practice-capacity
HPA 는 비동기적으로 반응하므로 클라이언트가 종료된 뒤에도 복제본 수가 계속 변경될 수 있습니다. 즉시 스케일링이 발생할 것이라고 가정하지 말고 HPA 의 조건과 이벤트를 확인하세요.
첫 번째 테이블에서 스케일링이 아직 나타나지 않으면 kubectl get hpa cpu-demo -n practice-capacity -w를 잠시 실행한 뒤 변경 사항을 확인하고 Ctrl+C를 누르세요. -w는 업데이트를 감시할 뿐 HPA 를 수정하지 않습니다. 메트릭 제어 루프는 비동기적으로 동작하므로 정확한 처리 시간은 검증 기준에 포함되지 않습니다.
테스트 실행에서는 HPA 가 목표를 초과한 사용량을 확인하고 Deployment 를 준비 상태의 복제본 2 개로 늘렸습니다.
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
cpu-demo Deployment/cpu-demo cpu: 55%/30% 1 4 2
NAME READY UP-TO-DATE AVAILABLE
cpu-demo 2/2 2 2
정확한 사용률과 복제본 수는 다를 수 있습니다. 중요한 점은 현재 사용률 55%가 목표 30%를 초과했기 때문에 원하는 용량이 증가했으며, 그 범위가 1~4 개 제한 안에 있었다는 것입니다.
요약
요청량, 제한, 실시간 메트릭, 사용률 목표, HPA 결정을 하나의 흐름으로 연결했습니다. 용량 관리는 피드백 루프입니다. 기준값을 선언하고, 사용량을 관찰하며, 범위를 정의하고, 컨트롤러의 조건을 확인해야 합니다.
