필터#Kubernetes×

[Kubernetes] HPA(HorizontalPodAutoscaler) 개념 정리 및 실습

쿠버네티스로 서비스를 운영하다 보면 트래픽이 갑자기 몰리는 순간이 반드시 온다. 이럴 때마다 사람이 직접 파드 개수를 늘렸다 줄였다 하는 건 사실상 불가능하다. 이번 글에서는 이 문제를 자동으로 해결해주는 쿠버네티스 리소스인 HPA(Horizontal Pod Autoscaler) 를 개념부터 실습까지 정리해본다. HPA란? HPA는 CPU, 메모리 사용량 혹은 사용자 정의 메트릭(Custom Metrics)의 부하에 따라 파드의 개수를 자동으로 늘리거나 줄여주는(Scaling) 쿠버네티스 리소스다. 트래픽이 갑자기 늘어나면 파드를 추가로 띄워서 대응하고 (Scaleout) 트래픽이 줄어들면 불필요한 파드를 줄여서 자원 낭비를 막는다 (Scalein) 즉, 사람이 개입하지 않아도 부하에 맞춰 자원을 효율적으로 관리해주는 것이 HPA의 목적이다. Vertical Scaling vs Horizontal Scaling 오토스케일링은 크게 두 가지 방향으로 나눌 수 있다. Vertical (Scale up/down): 파드 개수는 그대로 두고, 파드 하나가 쓸 수 있는 자원(CPU, 메모리)을 늘리는 방식 Horizontal (Scale out/in): 파드 자체의 개수를 늘리거나 줄이는 방식 HPA는 이름 그대로 후자, Horizontal 방식이다. Vertical 방식은 파드를 재시작해야 하는 등 비활성화 구간이 생기기 쉬운 반면, Horizontal 방식은 파드를 추가/제거하는 방식이라 무중단으로 대응하기 좋다는 장점이 있다. 다만 DB처럼 상태를 갖는(stateful) 워크로드는 여러 개로 늘려도 유의미하지 않은 경우가 많아서, 상태 없는(stateless) 서비스에 주로 적합하다. 실습 환경 준비 먼저 실습용 디렉터리를 하나 만들어준다. bash mkdir hpa cd hpa 1. 리소스를 제한하는 파드 생성 HPA가 CPU 사용률을 기준으로 스케일링 여부를 판단하려면, 먼저 파드에 CPU/메모리 자원을 얼마나 할당할지(requests)와 최대 얼마까지 쓸 수 있는지(limits)를 정의해줘야 한다. bash vi res.yml yaml spec: containers: name: nginx image: nginx:latest resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" requests: 컨테이너 생성 시 최소한 보장받는 자원. 스케줄러가 파드를 배치할 노드를 고를 때 이 값을 기준으로 판단한다. limits: 컨테이너가 최대로 사용할 수 있는 자원. 이 값을 넘기면 제한이 걸린다. 이렇게 파드에 자원을 할당해두면, 파드에 부여된 리소스(CPU, RAM) 사용률이 특정 임계값 이상이거나 이하일 때 파드 개수를 자동으로 늘리거나 줄일 수 있게 된다. 다만 이걸 하려면 대상 파드의 자원 사용량을 실시간으로 모니터링해줄 메트릭 서버가 반드시 필요하다. 2. 메트릭 서버(Metrics Server) 설치 HPA는 파드의 CPU/메모리 사용량을 직접 측정하지 않는다. 클러스터 내에 별도로 떠 있는 메트릭 서버로부터 이 값을 가져와서 판단한다. 그래서 HPA를 쓰기 전에 메트릭 서버부터 설치해야 한다. 메트릭서버 매니페스트는 아래 깃허브에서 받을 수 있다. https://github.com/kubernetessigs/metricsserver bash curl Ls https://github.com/kubernetessigs/metricsserver/releases/latest/download/components.yaml o metric.yml 다운로드한 매니페스트를 열어서 몇 가지를 수정해줘야 한다. bash vi metric.yml 수정이 필요한 부분은 containers.args 쪽이다. yaml spec: containers: args: kubeletinsecuretls 추가 certdir=/tmp secureport=10250 kubeletpreferredaddresstypes=InternalIP 수정 kubeletusenodestatusport metricresolution=15s kubeletinsecuretls 옵션을 추가해서 kubelet과의 통신 시 TLS 인증서 검증을 생략하도록 한다. (사설/테스트 환경에서 인증서 문제로 메트릭 서버가 뜨지 않는 걸 방지하기 위함) kubeletpreferredaddresstypes 값에서 ,ExternalIP,Hostname을 삭제하고 InternalIP만 남겨서, 노드의 내부 IP로만 kubelet에 접근하도록 해준다. 수정이 끝났으면 클러스터에 적용한다. bash kubectl apply f metric.yml 3. 테스트용 Deployment / Service 배포 HPA로 스케일링을 테스트해볼 대상이 필요하다. nginx 기반의 간단한 Deployment와 Service를 하나 만들어준다. bash vi dep.yml yaml apiVersion: v1 kind: Service metadata: name: mysvc spec: selector: app: myweb ports: port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: mydep spec: replicas: 3 selector: matchLabels: app: myweb template: metadata: labels: app: myweb spec: containers: image: 61.254.18.30:5000/ipnginx name: mywebcon resources: requests: cpu: "10m" limits: cpu: "20m" CPU 사용률을 기준으로 스케일링을 확인할 것이기 때문에, 일부러 requests.cpu, limits.cpu 값을 아주 작게(10m, 20m) 잡았다. 이렇게 해야 약간의 부하만 줘도 사용률(%)이 쉽게 임계치를 넘어서 스케일링 동작을 눈으로 빠르게 확인할 수 있다. bash kubectl apply f dep.yml 배포 후 kubectl top pod로 각 파드의 실제 자원 사용량을 확인할 수 있다. 4. HPA 생성하기 — 명령어로 바로 생성 가장 간단하게는 kubectl autoscale 명령어로 바로 HPA를 만들 수 있다. bash kubectl autoscale deploy mydep min=1 max=5 cpupercent=50 CPU 사용량 임계치를 50%로 설정해서, 최소 1개 최대 5개 사이에서 파드 개수를 자동으로 조절하겠다는 의미다. 5. HPA를 매니페스트로 작성하기 위에서 명령어 한 줄로 만든 것과 동일한 설정을 매니페스트(YAML) 파일로도 작성할 수 있다. 실제 운영 환경에서는 이렇게 선언적으로 관리하는 걸 선호한다. bash vi as.yml yaml apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: hpanginx spec: maxReplicas: 5 minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: mydep 오토스케일링 대상 Deployment 이름 명시 targetCPUUtilizationPercentage: 50 scaleTargetRef에 스케일링 대상이 되는 Deployment를 지정해주고, targetCPUUtilizationPercentage로 임계치를, minReplicas/maxReplicas로 파드 개수의 하한선과 상한선을 정해주는 구조다. 6. 부하를 줘서 스케일 아웃 확인하기 이제 실제로 트래픽을 흉내 내서 HPA가 정말 동작하는지 확인해볼 차례다. 아래 명령어로 0.1초 간격으로 서비스에 계속 curl 요청을 날려서 부하를 준다. bash i=1; while true; do sleep 0.001; echo $((i++)) curl s ; done 여기서 IP는 kubectl get svc로 확인한 대상 서비스(예: mysvc)의 ClusterIP를 넣어주면 된다. 7. 결과 확인 부하를 주는 동안 다른 터미널에서 HPA와 파드 상태를 실시간으로 지켜보면 스케일 아웃이 일어나는 걸 확인할 수 있다. bash kubectl get hpa 현재 오토스케일링 설정이 어떻게 되어 있는지, 그리고 CPU 사용률이 임계치 대비 몇 %인지 확인할 수 있다. bash kubectl top pod watch 명령어와 함께 사용하면 파드 개수가 늘어나는 과정을 실시간으로 관찰할 수 있다. bash watch kubectl get hpa watch kubectl top pod 부하를 주기 시작하면 CPU 사용률이 임계치(50%)를 넘으면서, 처음 3개였던 파드가 최대 5개까지 늘어나는 것을 볼 수 있다. 8. 부하가 사라지면 다시 Scalein 반대로 부하 명령을 멈추면 어떻게 될까? CPU 사용률이 떨어지면서 HPA가 자동으로 파드 개수를 줄이기 시작한다. [이미지 삽입: 부하 종료 후 REPLICAS가 줄어드는 kubectl get hpa / kubectl top pod 캡처] 흥미로운 점은, 처음 Deployment 매니페스트에서 지정했던 replicas: 3과는 상관없이 HPA가 설정한 minReplicas 값인 1개까지 파드 수가 줄어든다는 것이다. HPA가 붙는 순간, 파드 개수의 기준은 Deployment의 replicas가 아니라 HPA의 minReplicas / maxReplicas가 된다는 걸 실습을 통해 확인할 수 있었다. 마무리 이번 실습으로 정리한 흐름을 요약하면 다음과 같다. 1. 파드에 requests/limits로 CPU·메모리 자원을 할당한다. 2. 메트릭 서버를 설치해서 파드의 실시간 자원 사용량을 수집할 수 있게 한다. 3. 스케일링 대상이 될 Deployment/Service를 배포한다. 4. kubectl autoscale 명령 또는 HPA 매니페스트로 오토스케일링 정책(최소/최대 개수, CPU 임계치)을 설정한다. 5. 부하를 줘서 Scaleout을, 부하를 멈춰서 Scalein을 눈으로 확인한다. HPA는 결국 "메트릭 서버가 수집한 지표"와 "내가 설정한 임계치"를 비교해서 파드 개수를 알아서 조절해주는 도구다. Deployment의 replicas는 초기값일 뿐, HPA가 붙는 순간부터는 HPA의 설정값이 우선한다는 점만 기억해두면 실무에서 헷갈릴 일이 없을 것 같다.

Sep 02, 2026kubernetes

[Kubernetes] Pod, 리소스, Ingress 정리

Pod란? 한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 단위 같은 Pod면 IP가 같다 같은 Pod 내 컨테이너들은 포트로 구분한다 Pod도 결국 컨테이너로 구성되어 있으며, 이 컨테이너를 실행하기 위해 docker, containerd, CRIO 같은 CRI(컨테이너 런타임)가 필요하다. 1\. kubeapiserver 내/외부의 모든 요청을 주고받는 서버. contoller나 scheduler,proxy의 주시대상. 호텔지배인. 2\. kubescheduler 생성될 리소스들을 어떤 노드에 '배치'할지 결정(스케쥴링) 호텔 로비 직원 3\. kubecontroller 다양한 리소스에 대한 여러가지 컨트롤러들이 존재한다. 원하는 상태(Desired state)에 현재 상태(current state)가 수렴하도록 지속적으로 모니터링. 문제가 생기면 고치거나 리소스를 재생성. ex) 하우스키퍼 4\. etcd 클러스터 및 모든 리소스에 대한 정보를 key:value 형태로 저장하는 일종의 데이터베이스. ex) 장부 모든 노드에 존재하는 컴포넌트 1\. kubelet 노드 관리자. 실질적으로 각 노드에 존재하는 리소스 관리 2\. kubeproxy 노드 안과 밖을 넘나드는 수직트래픽을 관리. 매니페스트 (yml 파일) 매니페스트란 내가 원하는 상태를 적어둔 명세서다. bash vi testpod.yml yml apiVersion: v1 kind: Pod metadata: name: test spec: containers: image: public.ecr.aws/docker/library/httpd:latest name: testcon bash kubectl apply f testpod.yml kubectl apply f는 docker compose up, docker stack deploy와 비슷하다. 내가 원하는 상태(Desired State)가 미리 정의된 매니페스트 파일을 구성해놓고 apply해서 반영한다. 매니페스트 수정 후 다시 apply하면 바로 변경사항을 반영시킬 수 있다. bash kubectl delete f testpod.yml 앞으로는 명령어로 직접 리소스를 생성하거나 지우지 말고 매니페스트 파일을 f 옵션을 통해 apply하거나 delete하도록 하자. label 중요 bash vi labels.yml yml apiVersion: v1 kind: Pod metadata: name: testlabelpod labels: app: myweb spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: testlabelcon label은 여러 개를 쓸 수 있다. bash kubectl apply f labels.yml 생성. bash kubectl describe pod testlabelpod 조회. label은 리소스를 컨트롤(원하는 상태, 현재 상태)하고 찾아가기 위한 용도다. 쿠버네티스의 다양한 리소스들 1\. pod 한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 배포 단위. 2\. replicaset Pod의 복제본 수를 유지해주는 리소스. 지정한 수만큼 Pod가 항상 실행되도록 보장한다. 3\. Deployment ReplicaSet을 관리하며 롤링 업데이트, 롤백 등을 지원하는 리소스. 실무에서 가장 많이 사용한다. 4\. namespace 클러스터 내에서 리소스를 논리적으로 분리하는 단위. 팀이나 프로젝트별로 격리된 환경을 만들 수 있다. 5\. Service (너무 중요!) 작은 로드밸런서라고도 할 수 있다. Pod에 접근하기 위한 고정된 엔드포인트를 제공하는 리소스이다. Pod는 재생성될 때마다 IP가 바뀌기 때문에 Service를 통해 안정적으로 접근한다. 서비스라는 리소스를 생성 시 하나의 접속지점이 생성된다. 이 서비스를 통해 모든 노드에 존재하는 pod에 트래픽을 인가할 수 있다. 인가하는 기준은 labels 를 통해 해당 pod를 특정하면 된다. 서비스는 다양한 종류(type)이 존재한다. 51. ClusterIP 타입 (svc의 default 타입) 클러스터 내부에서만 유효한 IP 내부 테스트 용도, 외부로 배포를 안하는 경우. 내부에 존재하는 서비스들끼리만 통신할 때. bash vi dep.yml yml apiVersion: apps/v1 kind: Deployment metadata: name: mydep spec: replicas: 3 selector: matchLabels: app: myweb template: metadata: labels: app: myweb spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: mywebcon bash kubectl apply f dep.yml svc를 연결할 deployment 생성. bash vi depsvc.yml 서비스 매니페스트 정의. yml apiVersion: v1 kind: Service metadata: name: svcmyweb spec: selector: app: myweb ports: port: 80 targetPort: 80 bash kubectl apply f depsvc.yml svc 생성. bash kubectl describe svc svcmyweb 자세한 정보 확인. Endpoint에 뜨는 pod들은 건강한 pod만 뜬다. 52. NodePort 타입 노드의 포트 서비스를 제공받는 사용자 입장에서 내부로 진입하여 pod에 접근하려면 노드 포트로 진입해야 한다. bash mkdir svc cd svc vi svcnodeport.yml yml apiVersion: v1 kind: Service metadata: name: svcdep spec: selector: app: mydep type: NodePort ports: nodePort: 30001 port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: mydep spec: replicas: 1 selector: matchLabels: app: mydep template: metadata: labels: app: mydep spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: depcon bash kubectl apply f svcnodeport.yml bash kubectl describe svc svcdep 3개의 포트(NodePort, Port, TargetPort)가 각각 어떤 대상인지 구분할 수 있어야 한다. Port 서비스 포트 TargetPort pod NodePort Node 외부에서 노드로 통신만 된다면 노드 포트를 통해 pod로 접속 가능하다. 어떤 노드로 들어가는지는 중요하지 않고, NodePort로 접근하면 동일한 공간(오버레이 네트워크가 구성된 podnetwork)으로 들어간다는 사실을 인지하자. pod가 어떤 노드에 존재하는지는 신경 쓸 필요도 없고 중요하지도 않다. pod가 worker1에 띄워져 있어도 worker2의 노드 포트를 통해 접근 가능하다. 53. LoadBalancer 타입 클러스터 관리자의 도움이 필요한 서비스 타입. 쿠버네티스 외부 네트워크 대역의 IP를 자동으로 할당하고 관리해 주는 사설 로드밸런서 관리자가 MetalLB다. EKS 같은 쿠버네티스 클러스터의 경우 클라우드 서비스 제공자(AWS)가 LB를 제공해줄 수 있지만, 온프레미스에 구성한 클러스터는 그렇지 않다. 따라서 svc를 LoadBalancer 타입으로 만들었을 때 누군가는 LB를 생성하면서 노드 대역대의 IP를 할당해줘야 한다. 그 기능을 활성화하기 위해 MetalLB가 필요하다. bash vi configmetal.yml LB가 생성됐을 때 뿌려줄 IP 범위 설정. yml apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: firstpool namespace: metallbsystem spec: addresses: 211.183.3.200211.183.3.240 안겹치게 수정. LB가 부여받을 IP 범위 apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallbsystem bash kubectl apply f configmetal.yml vi lbtom.yml yml apiVersion: v1 kind: Service metadata: name: svctom spec: selector: app: tom type: LoadBalancer ports: port: 80 targetPort: 8080 apiVersion: apps/v1 kind: Deployment metadata: name: deptom spec: replicas: 1 selector: matchLabels: app: tom template: metadata: labels: app: tom spec: containers: image: public.ecr.aws/docker/library/tomcat:10.1.40jre11 name: tomcon svc의 타입으로 LoadBalancer 타입을 지정해준다. nodePort는 삭제한다. bash kubectl apply f lbtom.yml 생성된 LB는 svc의 포트를 따라간다. Ingress (제일 중요!) path 기반 라우팅 (/board로 가면 board 앱으로, /login으로 가면 login 앱으로) 일반적인 svc는 path 기반 라우팅이 불가능하다. (LoadBalancer, NodePort, ClusterIP) 서비스는 한 종류의 라벨만 품을 수 있기 때문에 이런 한계가 발생한다. 합칠 수 없다 = 같은 주소가 될 수 없다. 여러 개의 컨테이너에 각 기능들을 구현하면 path로 라우팅이 가능해야 한다. 일반적인 svc는 path 기반 라우팅이 불가능하기 때문에 Ingress라는 리소스가 필요하다. Ingress를 구성하면 path 기반 라우팅이 가능하다. ex) www.naver.com/board 로 오면 svcboard라는 svc로 보내줘. ex) www.naver.com/login 으로 오면 svclogin이라는 svc로 보내줘. → 하나의 접속지점(www.naver.com)을 통해 여러 개의 svc를 구성할 수 있다. Ingress를 구성하기 위해서는 Ingress Controller가 필요하다. (AWS EKS에서는 Ingress Controller를 LoadBalancer Controller라고 부른다.) Ingress Controller 설치 bash vi deploy.yaml 필요한 부분 수정. (type 을 NodePort에서 LoadBalancer로 수정한다.) bash kubectl apply f deploy.yaml kubectl get svc n ingressnginx Ingress 매니페스트 작성 bash cp ../svc/ip.yml . vi ip.yml yml apiVersion: v1 kind: Service metadata: name: svcipnginx spec: selector: app: myipnginx ports: port: 80 targetPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: ipdep spec: replicas: 2 selector: matchLabels: app: myipnginx template: metadata: labels: app: myipnginx spec: containers: image: public.ecr.aws/docker/library/httpd:alpine name: ipcon bash kubectl apply f ip.yml kubectl describe svc svcipnginx 서비스가 정상인지 확인. bash vi ingip.yml yml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingip annotations: nginx.ingress.kubernetes.io/rewritetarget: / spec: ingressClassName: "nginx" rules: host: rapa.com http: paths: path: /httpd pathType: Prefix backend: service: name: svcipnginx port: number: 80 annotation : 추가적인 정보. labels와 비슷하지만 주로 부가적인 기능 명시. ingressClassName : ingresscontroller의 종류 중에 nginx 방식을 사용. rewritetarget: / → 비록 /httpd라는 경로로 들어왔더라도 실제 pod에서는 /라는 경로로 바꿔주는 기능. host : 영문주소. IP는 안됨. DNS 기능이 필요하다. 인증서가 있다면 https 통신도 가능하다. path : 한 종류의 앱. pathType: Prefix → /httpd로 접근하는 애들 전부. 서비스의 이름을 마치 주소처럼 사용하고 있다. bash kubectl apply f ingip.yml ingress를 describe 했을 때 endpoint들(pod들)이 잘 떠있는 것만 봐도 ingresssvcpod가 잘 연결되어 있는 걸 어느정도 확인할 수 있다. 원래는 DNS를 통해서 rapa.com에 해당하는 IP를 매핑시켜줘야 하지만, 미니 DNS인 /etc/hosts 파일을 사용하자. bash vi /etc/hosts Ingress 트래픽 흐름 쿠버네티스에서 외부 사용자가 도메인 이름(rapa.com)을 치고 들어와서 실제 앱(pod)까지 도달하는 ingress 트래픽 흐름. rapa.com → ingresscontroller의 svc ExternalIP(DNS) → ingress(path 기반 라우팅) → svc → pod

May 12, 2026kubernetes