pod가 실행되기 위해서는 cpu, memory 가 필요하며, 이는 pod가 실행되는 node의 리소스를 사용한다. 쿠버네티스는 각 pod가 얼만큼의 리소스(cpu, memory)가 필요한지에 따라, 실행될 node를 적절히 선택한다. 따라서 각 pod가 필요한 리소스를 적절하게 설정해줘야 효율적으로 node의 리소스를 활용할 수 있다.
여기서는 이처럼 pod가 필요한 리소스를 설정하고, 현재 사용되고 있는 리소스를 관리, 모니터링 할 수 있는 방법을 알아본다.
1. Pod가 필요한 cpu, 메모리 (Requests, Limits)
pod의 spec.containers[].resources 에 아래와 같은 4개 정보를 설정해야 한다. requests와 limits 이라는 항목이 있으며, 각각 cpu, memory 값을 설정할수 있다.
- limits.cpu
- limits.memory
- requests.cpu
- requests.memory
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"1-1) requests
pod가 실행되는데 최소한으로 필요한 cpu, memory 를 의미한다. node에 requests 보다 더 많은 cpu, memory 가 남아있을 경우에만 pod는 이 node에서 실행될수 있다. 만일 node에 남아있는 리소스가 requests보다 적다면 해당 pod는 이 node에서는 실행되지 않는다.
위의 yaml을 예로들면 pod에 2개의 container(app, log-aggregator) 가 있는데, app이라는 container를 실행하기 위해서는 node에 최소한 64Mi의 memory, 250m의 cpu가 남아있어야 한다는 의미이다.
여기서 memory와 cpu의 단위의 종류와 의미는 링크를 참고하자. 요약하면, memory 단위 Mi는 MiB를 의미하며, cpu 단위인 m은 1/1000 core 을 의미한다 (250m=0.25). MiB와 MB의 차이점은 링크를 참고하자.
엄밀하게 따지면 MiB와 MB는 다르지만 굉장히 정교한 SW가 아니라면 동일한 의미로 사용해도 크게 상관없을것이라고 생각한다. 둘중 어느것을 쓰느냐 보다는 통일해서 사용하는게 중요할 듯 하다.
1-2) limits
pod가 실행될때 사용할수 있는 최대 cpu, memory 값이다. requests는 node를 선택할때 사용되는 값이지만, limits는 실제 pod가 실행될때 사용되는 값이다. 기본적으로 각 pod는 limits 보다 많은 cpu, memory를 사용할 수 없다. 위의 yaml을 예로들면 app container는 최대 128Mi의 memory, 500m의 cpu를 사용할 수 있다.
만일 pod가 실행하면서 limits 보다 더 많은 리소스를 사용하면 어떻게 될까? 기본적으로 cpu는 throttling이 걸리고, memory는 pod가 종료된다. 다만, 공식문서를 확인해보면 항상 throttling이 걸리거나 종료되는것은 아니고, 만일 node 에 사용가능한 리소스가 있을 경우에는 적절하게 처리하는 경우도 있는것 같다.
2. 리소스 확인하기
2-1) pod의 requests, limits 값 확인하기
기본적으로 아래와 같이 pod의 yaml 파일의 내용으로 확인할 수 있다.
kubectl get po -o yaml [pod]
모든 pod의 값을 한번에 보고 싶을때는 어떻게 해야할까? custom-columns 옵션을 사용해서 모든 pod의 관련 필드정보를출력한다.
kubectl get po -o custom-columns="Name:metadata.name,CPU-Requet:spec.containers[*].resources.requests.cpu,CPU-limit:spec.containers[*].resources.limits.cpu,MEM-Request:spec.containers[*].resources.requests.memory,MEM-limit:spec.containers[*].resources.limits.memory"
2-2) node의 리소스 확인하기
아래는 kubectl describe node 명령을 실행하면 나오는 정보이다.
위쪽에 Allocatable 정보가 있다. node에서 시스템 데몬 등을 제외하고 pod에 할당할 수 있는 총 용량이다. cpu는 36(=36000m), memory는 약 214485600Ki, pod개수는 최대 110개까지 가능하다. 중간에는 현재 실행중인 pod의 정보를 확인할 수 있다. 총 11개의 pod가 실행되고 있고, 각 pod별 requests, limits 정보를 확인할 수 있다. 아래쪽에 summary 정보가 있는데, Requests 항목은 11개 pod의 requests값을 더한 값이다. 현재 해당 node의 cpu는 2%(950m), memory는 0% (630Mi)를 사용하고 있음을 알 수 있다.
3. 실제 사용하는 리소스 감시하기
위에서 설정한 requests, limits값은 실제 pod가 어느정도의 리소스를 사용하는지 알아야 최적화 할수 있다. pod의 실제 cpu, memory 사용율을 알기 위해서는 kubectl top 이라는 명령어를 활용한다.
3-1) kubectl top 설치하기
kubectl top 을 사용하기 위해서는, kubernetes-metrics-server를 설치해야 한다. 아래 명령어를 실행하면 kubectl top이 설치된다.
git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git
cd kubernetes-metrics-server/
kubectl create -f .3-2) cpu, memory 사용율 확인하기
설치후 아래 명령어를 입력하면 pod 및 node의 cpu, memory 사용율을 확인할 수 있다.
kubectl top node
kubectl top pod
4. 기타
4-1) OverCommit
node를 결정할때는 requests값을 사용하지만, 실제 실행될때는 limits 값을 사용한다. 이로 인해 (limits의 합) > (node의 Allocatable)이 되고 문제가 발생할 수 있다. 이를 overcommit 상태라고 한다.
4-2) LimitRange
namespace 별로 default requests, default limit, min/max limits 값 등을 설정할 수 있다.
기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 컴퓨팅 리소스로 실행된다. 리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스 별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다.
4-3) ResourceQuota
namespace 별로 사용 가능한 cpu, memory 를 제한할 수 있다.
여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때 한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용할 수 있다는 우려가 있다. 리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다. ResourceQuota 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있다.
4-4) best practice
링크는 구글 클라우드에서 작성한 쿠버네티스 best practice의 내용이다.
'IT > Kubernetes' 카테고리의 다른 글
| CKA (Certificate Kubernetes Administrator) 자격증 시험준비부터 합격까지 (0) | 2022.03.03 |
|---|---|
| kubernetes woker node 장애가 발생한다면 kubelet 을 살펴보자 (0) | 2022.02.23 |
| 쿠버네티스 pod가 실행되는 node 선택하기 (feat. nodeName, taint, affinity, toleration) (0) | 2022.01.20 |
| 쿠버네티스 ReplicaSet 사용법 (scale, 삭제, pod 제외) (0) | 2022.01.15 |
| 쿠버네티스에서 pod를 생성하는 3가지 방법 (run, create, apply) (0) | 2022.01.11 |