[k8s] 쿠버네티스 resource 관리

배포 전략 (Deployment Strategies)

Rolling Update (기본 전략)

• 원리: 구버전 Pod를 하나씩 제거함과 동시에 신버전 Pod를 하나씩 생성하여 교체
• 특징: 추가 자원이 거의 들지 않지만, 배포 중에는 구버전과 신버전이 공존
• 실습 포인트: maxSurge(동시 생성 허용량)와 maxUnavailable(동시 삭제 허용량) 값을 통해 배포 속도를 조절 kubectl rollout undo로 즉시 이전 버전 복구가 가능
•  
• kubectl rollout undo deploy nginx-deploy

 

  1. Blue/Green Update

• 원리: 신버전(Green)을 구버전(Blue)과 동일한 규모로 미리 다 띄워놓고, 서비스(LoadBalancer)의 selector를 수정해 트래픽을 한꺼번에 전환
• 특징: 버전 간 혼선이 없고 롤백이 매우 빠르지만, 자원이 평소의 2배가 필요
• 실습 포인트: Service YAML의 selector 라벨(version: blue → green)만 바꿔서 순식간에 서비스 주체를 바꾸는 것이 핵심

2. Canary Update

• 원리: 신버전을 1~2개만 먼저 띄워 전체 트래픽의 일부만 유입시켜 테스트한 후, 문제가 없으면 점진적으로 늘림
• 특징: 실사용자 환경에서 위험성을 최소화하며 테스트
• 실습 포인트: 동일한 app: nginx 라벨을 가진 두 개의 Deployment(stable, canary)를 띄우고, 서비스가 라벨을 통해 두 그룹의 Pod 모두에게 트래픽을 나누어 보내게 만듬

---

오토스케일링 (Autoscaling)

부하량에 따라 Pod의 개수를 자동으로 늘리거나 줄여 자원 효율성을 높이는 기술

 

HPA (Horizontal Pod Autoscaler)

• 핵심 조건: 반드시 Metrics Server가 설치되어 있어야 Pod의 상태(CPU/Memory)를 체크할 수 있
• 동작: kubectl top pods로 확인되는 실시간 사용량이 설정한 목표치(예: CPU 50%)를 넘으면 replicas를 자동으로 증가

• # metrics server install
  kubectl create -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
  # metrics server 확인
  kubectl get apiserver v1beta1.metrics.k8s.io

• # autoscale 설정
  kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

• kubectl run -i --tty load-generator --rm \
  --image=busybox --restart=Never \
  -- /bin/sh \
  -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
  If you don't see a command prompt, try pressing enter.
  OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!OK!
  OK!OK!OK!OK!OK!OK!OK!OK!OK!....
  
  # 실행해둔 상태로 terminal 새로 열고 pod 개수 확인
  watch -n 1 kubectl get deploy, pod
  
  # 실행했던 내용 ctrl+c로 종료하고 scale-in 확인

 

Quota

1. 주요 역할 및 특징

• 자원 독점 방지: 특정 네임스페이스가 클러스터의 CPU나 메모리를 과도하게 점유하는 것을 막음
• 범위: 개별 Pod가 아닌 네임스페이스 전체의 합계를 기준으로 제한
• 강제성: 설정된 할당량을 초과하는 리소스 생성 요청이 들어오면, 쿠버네티스 API 서버는 해당 요청을 거부(Forbidden)

2. 제한할 수 있는 항목 (Hard Limit)

• 컴퓨팅 리소스: 모든 Pod의 requests.cpu, limits.memory 등의 총합.
• 객체 개수: 네임스페이스 내에 생성할 수 있는 services, pods, replicationcontrollers 등의 최대 개수

# limit-01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: demo-01
spec:
  containers:
  - name: demo-01
    image: polinux/stress
    resources:
      requests:
        memory: "300Mi"
      limits:
        memory: "600Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "650M", "--vm-hang","1"]

이건 pod에서 limit를 제한  / quota아님

# resource.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: memory-limit
  namespace: ns-quota
spec:
  hard:
    requests.memory: 1Gi
    limits.memory: 2Gi
    services: 3

quota 만듦 네임스페이스에 있는 pod의 메모리 총 2gb가 넘으면 안됌 

kubectl apply -f rs.yaml
replicaset.apps/demo-02 created

kubectl get pod -n ns-quota
No resources found in ns-quota namespace.

kubectl get rs -n ns-quota
NAME      DESIRED   CURRENT   READY   AGE
demo-02   3         0         0       25s

현재 pod가 3개 생성되고 있고 memory가 1gb씩 담당하고 있기 때문에 형성이 안됨 

 

kubectl apply -f rs.yaml
replicaset.apps/demo-02 configured

kubectl get rs,pod -n ns-quota
NAME                      DESIRED   CURRENT   READY   AGE
replicaset.apps/demo-02   3         1         1       19m

NAME                READY   STATUS    RESTARTS   AGE
pod/demo-02-bq2ng   1/1     Running   0          8s

 

메모리를 하나에 600mb 할당하니 돌아간다