[k8s]파드 스케일링(1)

목표

https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits

안정적인 서비스

안정적인-의 기준 세우기

정밀한 스케일링을 위한 모니터링 + 실험 추가 필요

---

자원관리

resource

• limits : pod가 실행될때 사용할수 있는 최대 cpu, memory
  • Limit을 pod가 넘기면 cpu는 throttling이 걸리고, memory는 pod가 종료(oom)
    • oom이 자주 일어나는 서비스들의 노드 여분 리소스를 확인하면서 기존 설정된 memory limit에 대한 검토 필요
  • 실제 노드의 여분 리소스와 상관없이 limit 값으로 결정되기 때문에 아이디어스의 데브옵스팀은 cpu limit을 해제하는 방식 채택하기도 함 → 단, 이 때는 노드 리소스가 넉넉하거나 유연해야 안정성 확보 가능
• requests : pod가 실행되는데 최소한으로 필요한 cpu, memory
  • 파드를 넣을 노드를 결정 할 때 기준. 단, 실제 실행 될 때 limit 값을 사용하기 때문에 노드의 할당가능한 리소스보다 리밋의 합이 클 때 overcommit 상태가 됨 → 장애!

namespace resource

• limitrange :
  • 네임스페이스에서 파드 하나의 리소스 limit, request 구성
• resourcequota :
  • 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공
  • 유형별로 네임스페이스에서 만드는 오브젝트, 컴퓨팅 리소스양 제한

상태확인

kubectl describe node

• allocatable : 데몬 같은거 제외하고 pod에 할당 할 수 있는 총 용량
• 각 파드 별로 리퀘스트, 리밋 기준 얼마나 사용하고 있는지 볼 수 있음.

kubectl top node
kubectl top pod

• cpu, memory 만 알아보기

---

QoS

https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Quality of Service

파드의 우선순위. 노드에 메모리 자원이 부족해지면 어떤걸 먼저 아웃시키는가 에 대한 클래스

Kubelet에 기본적으로 노드 가용 메모리가 100mi 이하일 때 memory pressure가 발생하도록 설정되어있음.

memory pressure 발생하면,

• 해당 노드에서 실행 중인 모든 파드에 대해 우선순위를 매겨 가장 낮은 순서부터 다른 노드로 쫓아냄.
• 해당 노드에선 새로운 파드를 할당 받지 않음.

종류

• BestEffort : resources 항목을 아예 사용하지 않을 경우. limit, request 둘 다 x → 노드의 모든 자원 사용할 수도 있고, 전혀 사용하지 못할 수 도 있음
• Burstable : Request의 지정된 만큼 리소스를 보장받고 상황에 따라서는 limit까지 사용 가능
• Guaranteed : limit == request 일때. 자원 사용을 무조건 보장받음
• 우선순위 : Guaranteed > Burstable > BestEffort

---

스케일 인/아웃 테스트

kubectl 명령어 공식문서

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#autoscale

적용하기

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test-service
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-test-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

version : 2부터 다양한 메트릭 참조 가능, 1은 cpu만 가능

cpu utilization : request의 cpu 값이 기준

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test-service
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-test-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests
        target:
          type: AverageValue
          averageValue: "100"

http_requests : 각 Pod의 평균 요청 수가 100이 될 때마다 스케일 인/아웃이 발생

단, 이를 위해서는 메트릭 서버가 http_requests 메트릭을 수집하고 있어야함.

수집 중인 메트릭

kubectl get --raw "/apis/metrics.k8s.io/v1beta1" | jq

{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "nodes",
      "singularName": "",
      "namespaced": false,
      "kind": "NodeMetrics",
      "verbs": [
        "get",
        "list"
      ]
    },
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "PodMetrics",
      "verbs": [
        "get",
        "list"
      ]
    }
  ]
}

요약 : 리소스 메트릭만 수집중, 어플리케이션 래벨의 커스텀 메트릭 x

• NodeMetrics (nodes):
  • 클러스터의 각 노드(node)에 대한 메트릭을 수집합니다.
  • 메트릭 종류: 노드 수준의 메트릭 (CPU, 메모리 사용량 등)
  • 메트릭 접근 방법: get, list
• PodMetrics (pods):
  • 각 네임스페이스(namespace) 내의 파드(pod)에 대한 메트릭을 수집합니다.
  • 메트릭 종류: 파드 수준의 메트릭 (CPU, 메모리 사용량 등)
  • 메트릭 접근 방법: get, list

cpu 부하주기

명령어 :

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://<deployment 서비스 이름>:<파드 포트>; done"

테스트값 :

cpu utilization 10

스케일 아웃 까지 시간 : 부하 들어가고 1분이내

스케일 인 까지 시간 : 부하 주는 것 멈추고 2분 이내

HPA 확인

kubectl get hpa -w

참고문서

https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

https://no-easy-dev.tistory.com/entry/쿠버네티스-Pod-자원관리-QoS

https://velog.io/@hsshin0602/쿠버네티스-auto-scaling