Infra/Kubernetes

쿠버네티스를 활용한 네이티브 데브옵스 - 5장 리소스 관리하기

wave35 2024. 10. 5. 22:53

5.1 리소스 이해하기 

- 쿠버네티스는 파드는 크게 CPU, Memory 두 종류의 리소스를 관리할 수 있다.

 

5.1.1 리소스 단위

- CPU 리소스를 할당할 때 사용하는 단위 중 하나가 "millicore"이다.

- 1m 는 CPU 리소스의 1/1000 단위로 표현한 것이다. ( 10m = 1/100 )

spec:
  containers:
  - name: demo
    image: cloudnatived/demo:hello
    ports:
    - containserPort: 8888
    resources:
      requests:
        memory: "10Mi"
        cpu: "100m"

 

5.1.3 리소스 상한

- 사용할 수 있는 충분한 용량의 노드가 없으면, 파드는 대기 상태로 기다린다.

- k8s는 리소스 오버커밋을 허용한다. 리소스가 초과될 수도 있다. 

- 이 때문에 리소스가 부족한 상태에서는 상한 리소스가 초과하지 않아도 컨테이가 종료될 수 있다.

 

 

5.2 컨테이너 생명 주기 관리

5.2.1 활성 프로브 ( Liveness Probe )

- k8s는 컨테이너가 살아있는지 확인하는 health check container를 지정할 수 있다.

- 예시로, httpGet프로브는 /healthz의 8888포트로 요청한다. 2xx, 3xx면 활성상태로 판단한다.

- 다른 값이나, 응답하지 않으면 container가 죽은 것으로 판단하여 재실행한다.

- 아래예시의 httpGet말고도 tcpSocket등 다른 종류의 프로브도 있다.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8888
  initialDelaySeconds: 3
  periodSeconds: 3

 

5.2.2 프로브 딜레이와 주기

- 활성 프로브를 실행하기 전까지 얼마나 기다리는지 initalDelaySeconds를 통해 지정한다.

 

5.2.5 준비성 프로브 ( Readiness Probe )

- 애플리케이션이 트래픽을 받을 준비가 되었는지를 확인한다.
- 준비성 프로브가 실패하면, 서비스 트래픽을 차단한다. 즉, 해당 컨테이너는 외부 요청을 받지못한다.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8888
  initialDelaySeconds: 3
  periodSeconds: 3

 

5.2.6 파일 기반 준비성 프로브

- 특정 경로의 파일의 존재 여부를 통해 트래픽을 받을 준비가 되었는지를 판단하는 방식이다.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/ready
  initialDelaySeconds: 5
  periodSeconds: 10

 

 

5.3 네임스페이스 사용하기

- 클러스터를 원하는 목적에 따라 세부공간으로 나눌 수 있다.

# namespace 생성
kubectl get namespace

# pod namespace의 파드 목록 확인
kubectl get pods --namespace prod

 

5.3.3 서비스 주소

- k8s에서 서비스 간 통신은 서비스 DNS를 통해 가능하다.

- 아래 예시는 prod 네임스페이스에 있는 demo라는 서비스와 통신한다.

# <서비스이름>.<네임스페이스>.svc.cluster.local
curl http://demo.prod.svc.cluster.local

 

5.3.4 리소스쿼터 ( ResourceQuota )

- namespace에서도 리소스 사용을 제한할 수 있다.

- namespace에 ResourceQuota를 생성한다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: demo-resourcequota
spec:
  hard:
    pods: "100" # 실행가능 파드갯수 제한

 

 

 

5.4 클러스터 비용 최적화하기

Vertical Pod Autoscaler (VPA)

  • k8s의 deployment를 관찰하여 사용 양에 따라 자동으로 파드의 리소스 요청을 조정한다.
  • 실제로 파드를 수정하지 않고, 제안만하는 dry-run mode가 더 유용하다.

 

리소스 최적화

- 디플로이먼트 최적화

  • 업데이트시에 중단시간, 트래픽등을 고려하여 Replica 갯수를 설정한다.

- 파드 최적화

  • 리소스 모니터링 툴을 통해 얼마나 사용하는지 확인한 후, 사용량보다 좀 더 높게 설정한다.

- 노드 최적화

  • 권장방법은 노드가 파드 5개실행 할 수 있을 만큼하며 낭비되는 리소스 비율을 약 10% 미만으로 유지
  • k8s의 기본 파드 상한값은 노드당 110개

- 스토리지 최적화

- 사용하지 않는 리소스 정리

- 여유 용량 파악하기

- AWS 예약 인스턴스 사용하기

- AWS 선점형(spot) 인스턴스 사용하기

- 워크로드 균형 있게 유지