14. 파드의 컴퓨팅 리소스 관리

1. 파드 컨테이너의 리소스 요청

• 파드를 생성할 때 컨테이너가 필요로 하는 CPU와 메모리 양 제한을 지정할 수 있다
• 파드의 요청과 제한은 파드에 속한 컨테이너 요청과 제한의 합이다

 

1.1 리소스 요청을 갖는 파드 생성하기

# 리소스 요청을 갖는 파드
apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      requests:
        cpu: 200m
        memory: 10Mi

• 컨테이너 요청에 cpu 200m과 memory 10Mi를 지정했다
• cpu를 지정하지 않으면 이미 cpu자원이 많이 할당된 경우 자원을 전혀 할당받지 못할 수도 있다.

• 실습환경은 2코어 머신이므로 컨테이너에 1코어, 즉 50%가 할당된 걸 보여준다
• 컨테이너 스펙에 제한이 아닌 요청으로 200m지정했으므로 1코어가 할당될 수 있다.

 

1.2 리소스 요청이 스케줄링에 미치는 영향

 

• 스케줄러는 파드를 만들 노드를 정할 때 스펙의 요청보다 높은 자원을 가진 노드를 선별한다
• 스케줄러는 노드를 정할 때 각 노드에 배포된 파드의 리소스 요청 총량을 확인해서 노드를 정한다(실제사용량 X)

 

스케줄러가 파드를 위해 최적의 노드를 선택할 때 파드의 요청을 사용하는 방법

• 스케줄 가능한 노드 중 최적의 노드를 찾는 알고리즘 LeastRequestedPriority, MostRequestedPriority
• LeastRequestedPriority : 남은 리소스가 가장 큰 노드에 파드를 배정 => 고른 리소스 분배
• MostRequestedPriority : 남은 리소스가 가장 작은 노드에 파드를 배정 => 최적의 노드 수

 

노드의 용량 검사

$ kubectl describe nodes

Capacity
Allocatable

=> Capacity는 노드의 총리소스이며 실제 스케줄 가능 여부는 Allocatable로 결정한다.

 

 

 

 

 

• cpu 800m, memory 20Mi 파드를 하나 생성 후 정상적으로 running하는 모습 확인
• cpu 1, memory 20Mi 파드 추가 생성 요청 시 Pending상태에서 컨테이너가 정상 동작하지 않음
• describe 명령으로 requests-pod-3의 상태를 조회해보면 스케줄이 실패했음을 알 수 있다.
• 단, 지금까지 딱 cpu2개로 정확히 할당 가능한 만큼 요청을 했는데 실패한 이유가 있다

 

• 사용자 정의 파드 외에도 kube-system 파드가 자동으로 프로비저닝되어 노드의 자원을 사용하고 있었다.
• 두번째 파드를 삭제하면 스케줄러는 삭제를 통지받고 pending 상태의 파드를 스케줄링 할 수 있는지 다시 확인한다.

 

1.3 CPU 요청이 CPU 시간 공유에 미치는 영향

• 파드 A는 200m을, 파드 B는 1000m의 CPU요청량이 있고 이는 1:5 비율이다.
• 각자 최저 보장 자원을 받은 상태로 프로세스의 CPU사용률이 높아지면 유휴자원을 추가로 할당받는다
• 두 파드가 치열하게 경합할 경우 유휴자원은 요청량 비율료 1:5로 할당된다
• 만약 경쟁 상황이 아니면 파드 A가 유휴자원 100%를 할당 받을 수 있지만 파드B가 요청하면 바로 자원을 내준다.

 

1.4 사용자 정의 리소스의 정의와 요청

• k8s는 사용자 정의 리소스를 노드에 추가하고 파드의 리소스 요청으로 사용자 정의 리소스를 요청할 수 있다.
• 노드 오브젝트의 capacity필드에 값을 추가해 값을 인식할 수 있게 한다
• quantity는 정수여야 한다.
• 파드스펙에서 resources.requests필드로 지정할 수 있다.

 

2. 컨테이너에 사용 가능한 리소스 제한

2.1 컨테이너가 사용 가능한 리소스 양을 엄격한 제한으로 설정

줬다 뺏을 수 있는 CPU와 달리 메모리는 한번 주면 반납을 꼭 해야 재활용이 가능한 자원으로 컨테이너마다 메모리 제한이 필요하다.

 

 

리소스 제한을 갖는 파드 생성

# 리소스 요청을 갖는 파드
apiVersion: v1
kind: Pod
metadata:
  name: requests-pod
spec:
  containers:
  - image: busybox
    command: ["dd", "if=/dev/zero", "of=/dev/null"]
    name: main
    resources:
      limits:
        cpu: 1
        memory: 20Mi

 

 

리소스 제한 오버커밋

 

• 최소를 보장하는 리소스 요청과 달리 리소스 제한은 제한의 총량이 자원의 총량보다 많을 수 있다.
• 개별 컨테이너는 지정된 리소스 제한을 초과해 사용하려고 해도 종료될 수 있다.

 

2.2 리소스 제한 초과

• CPU는 제한이 있어도 성능과 연결될 뿐 실행에는 문제가 없다
• 반면, 메모리는 필요한 만큼 자원을 할당받지 못하면 프로세스가 제동작을 못하므로 프로세스가 종료된다(OOM)
• 파드의 재시작 정책이 Always 또는 OnFailure로 설정된 경우 프로세스는 다시 실행된다
• OOM으로 프로세스 재실행이 반복된다면 CrashLoopBackOff상태로 프로세스의 재실행 대기시간을 걸게 된다.

OOM으로 종료된 프로세스를 포함한 파드의 상태

 

 

 

2.3 컨테이너의 애플리케이션이 제한을 바라보는 방법

• top 명령을 통해 확인한 used, free값은 컨테이너 메모리가 아닌 노드 메모리를 바라본다.
• JVM -Xms 옵션을 설정하지 않은 경우 JVM은 노드 메모리를 기준으로 최대힙을 정하고, 애플리케이션 사용 시 컨테이너 메모리 제한을 초과해 컨테이너에 OOM이 발생할 수 있다.
• -Xms옵션을 설정해도 JVM의 오프 힙 메모리에는 영향을 미치지 않는다(JVM 10 이후 -XX+UseContainerSupport)

 

컨테이너는 노드의 모든 CPU 코어를 본다

• 컨테이너 CPU제한도 컨테이너가 사용할 수 있는 CPU시간 양을 상대적으로 제한할 뿐이다.
• 제한된 CPU코어를 사용하는 애플리케이션에 매우 많은 스레드가 생성되어 그 CPU를 경합할 경우 작업 수행과 메모리 반납이 지연되고 이는 시스템 장애로 이어질 수 있다.
• 애플리케이션이 컨테이너 CPU제한을 참조하도록 하기 위해 Downward API를 이용해 그 값을 구할 수 있다

 

3. 파드 QoS 클래스 이해

리소스 제한 총합은 전체 리소스보다 클 수 있고 서로 다른 애플리케이션이 실행될 때 이 값을 초과한 경우가 생길 수 있다. 이때 어떤 파드를 종료시키고 어떤 파드에게 리소스를 할당할지 결정하는 정책이 QoS(Quality of Service)다.

 

• BestEffort(최하위 우선순위)
• Burstable
• Guaranteed(최상위 우선순위)

 

3.1 파드의 QoS 클래스 정의

=> QoS클래스를 파드에 직접 설장하는 게 아닌 파드 컨테이너의 리소스 요청과 제한의 조합에서 파생된다.

 

BestEffort 클래스에 파드를 할당하기

• 우선순위가 제일 낮으며 아무런 리소스 요청과 제한이 없는 파드에 할당된다
• 최악의 경우 CPU를 전혀 할당받지 못한다.
• 다른 파드를 위해 즉시 메모리를 해제 후 종료될 수 있다
• 메모리 제한이 없으므로 여유가 있는 리소스 환경에서 가장 많이 자원을 활용한다

 

Guaranteed 클래스에 파드 할당하기

• 리소스 요청과 제한을 동일하게 설정한 경우 더많이도 못받지만 반드시 그 제한은 보장해준다
• 요청을 생략하면 제한과 동일하므로 제한만 설정해도 Guaranteed를 보장한다.
• 또한 한 파드에 속한 모든 컨테이너가 리소스 제한과 요청을 지정해야 한다.

 

Burstable QoS 클래스에 파드 할당하기

 

• BestEffort와 Guaranteed 사이에 Burstable가 있다.
• 리소스제한과 요청이 일치하지 않는 경우, 제한과 요청을 지정하지 않은 컨테이너를 포함한 파드인 경우
• Burstable 파드는 요청한 양만틈의 리소스를 얻지만 필요하면 추가 리소스를 할당받을 수 있다.

 

컨테이너 QoS 클래스 파악

 

 

다중 컨테이너 파드의 QoS 클래스 파악

 

 

다중 컨테이너 파드의 경우 만장일치인 경우만 그 정책대로 가고 한 컨테이너라도 정책이 다르면 Burstable다.

 

 

3.2 메모리가 부족할 때 어떤 프로세스가 종료되는지 이해

• 시스템이 오버커밋되면 QoS클래스는 어떤 컨테이너를 먼저 종료할지 결정하고 해제된 리소스를 높은 우선순위 파드에 준다.
• BestEffort를 먼저 종료하고 Burstable, 마지막으로 시스템 프로세스가 메모리를 필요로하면 Guaranteed 파드가 종료된다.

 

 

QoS 클래스가 우선순위를 정하는 방법 이해

 

 

• 기본적으로 클래스의 우선순위 대로 파드의 프로세스를 종료시킨 뒤 자원을 회수한다
• 동일한 클래스인 경우 프로세스의 OOM점수를 정하고 가장 높은 프로세스를 종료시킨다.
• 위 예시에서 OOM점수는 메모리 요청량 대비 메모리 사용량인 메모리 비율이 높은 파드B를 파드C보다 먼저 kill한 케이스다.

 

4. 네임스페이스별 파드에 대한 기본 요청과 제한 설정

4.1 LimitRange 리소스 소개

• 모든 컨테이너 시소스 요청과 제한을 설정하는 대신 LimitRange 리소스를 생성해 이를 수행할 수 있다.
• LimitRange는 컨테이너의 네임스페이스 별 리소스에 최소/최대 제한을 지정하고 명시하지 않으면 디폴트를 지정한다
• LimitRange는 LimitRanger 어드미션 컨트롤 플러그인에서 사용된다
• 파드 매니페스트가 API 서버에 게시되면 LimitRanger플로그인이 파드 스펙을 검증한다.

4.2 LimitRange 오브젝트 생성하기

# LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: poi-limit
spec:
  limits:
  - type: Pod
    min:
      cpu: 50m
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
  - type: Container
    defaultRequest:
      cpu: 100m
      memory: 10Mi
    default:
      cpu: 200m
      memory: 100Mi
    min:
      cpu: 50m
      memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
    maxLimitRequestRatio:
      cpu: 4
      memory: 10
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 10Gi

• 파드 단위로 리소스 제한을 설정한다
• 컨테이너의 기본 리소스 요청과 제한을 지정할 수 있다
• 컨테이너의 리소스를 제한하고, cpu와 memory의 비율로 제한을 설정할 수 있다.
• PVC가 요청하는 스토리지의 최대, 최소 용량을 제한할 수 있다.
• LimitRange는 기존 리소스의 제한을 검증하지 않고 이후 생성되는 리소스만 검증한다.
• LimitRange는 본인이 속한 네임스페이스에서만 동작한다.

 

4.3 강제 리소스 제한

$ kbc create -f pod.yaml
The Pod "poid" is invalid:
* spec.containers[0].resources.requests: Invalid value: "20Gi": must be less than or equal to memory limit
* spec.containers[0].resources.requests: Invalid value: "1": must be less than or equal to cpu limit

 

4.4 기본 리소스 요청과 제한 적용

$ kbc describe po poid

  Limits:
      cpu:     200m
      memory:  100Mi
    Requests:
      cpu:        100m
      memory:     10Mi
      
$ kbc create -f po poid -n poi
$ kbc describe po poid

• 파드 manifast에 리소스 요청과 제한을 지정하지 않아도 describe에 내용이 나온다.
• default 네임스페이스가 아닌 poi 네임스페이스에서는 요청과 제한에 대한 내용이 안나온다.

 

단, LimitRange는 생성되는 개별 파드나 컨테이너에만 적용된다. 즉, 제한에 걸리지 않는 파드가 계속 늘어나면 노드 또는 클러스터 전체 리소스는 한계치까지 사용될 수 있다

 

 

5. 네임스페이스의 사용 가능한 총 리소스 제한하기

5.1 ResourceQuota 오브젝트 소개

• 리소스쿼터 어드미션 컨트롤러 플러그인은 생성 중인 파드가 설정된 리소스쿼터를 초과하는지 확인한다
• LimitRange와 마찬가지로 기존 생성되어 있던 파드에 대해서는 적용되지 않는다
• 리소스쿼터는 네임스페이스에서 파드가 사용할 수 있는 컴퓨팅 리소스양와 PVC 스토리지 양을 제한한다.
• 또한 그 총 개수를 제한할 수 있다

 

CPU 및 메모리에 관한 리소스쿼터 생성

# CPU와 메모리에관한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: cpu-and-mem
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

• ResouceQuota는 네임스페이스 단위로 적용된다
• 네임스페이스에 속한 리소스의 총량에 대해 제한한다.

 

쿼터와 쿼터 사용량 검사

$ kbc describe quota

Name:            cpu-and-mem
Namespace:       default
Resource         Used   Hard
--------         ----   ----
limits.cpu       200m   600m
limits.memory    100Mi  500Mi
requests.cpu     100m   400m
requests.memory  10Mi   200Mi

 

=> describe quota를 입력하면 네임스페이스에 허용된 리소스양과 사용중인 리소스양을 확인할 수 있다.

 

리소스쿼터와 함께 LimitRange생성

=> LimitRange는 단독으로 만들고 적용할 수 있지만 ResourceQuota만 만든 네임스페이스에서 파드는 생성할 수 없다.

Error from server (Forbidden): error when creating "pod.yaml": pods "poid" is forbidden: failed quota: cpu-and-mem: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

 

 

 

5.2 퍼시스턴트 스토리지에 관한 쿼터 지정하기

# 스토리지에 대한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage
spec:
  hard:
    requests.storage: 500Gi
    ssd.storageclass.storage.k8s.io/requests.storage: 300Gi
    standard.storageclass.storage.k8s.io/requests.storage: 1Ti

• 네임스페이스의 모든 스토리지 양은 500Gi로 설정한다
• 각 PVC는 특정 스토리지클래스에 프로비저닝할 수 있으므로 각 스토리지 클래스 별로 스토리지 제한을 개별적으로 줄 수 있다.

 

5.3 생성 가능한 오브젝트 수 제한

apiVersion: v1
kind: ResourceQuota
metadata:
  name: objects
spec:
  hard:
    pods: 10
    replicationcontrollers: 5
    secrets: 10
    configmaps: 10
    persistentvolumeclaims: 4
    services: 5
    services.loadbalancers: 1
    services.nodeports: 2
    ssd.storageclass.storage.k8s.io/persistentvolumeclaims: 2

 

• 리소스쿼터는 네임스페이스 내 각 리소스의 개수를 제한할 수 있다
• 또한 리소스쿼터 자체에 대한 개수를 제한할 수 있다.

 

5.4 특정 파드 상태나 QoS 클래스에 대한 쿼터 지정

• 쿼터는 쿼터범위(BestEffort, NotBestEffort, Terminating, NotTerminating)로 지정해 사용할 수 있다.
• BestEffort는 파드의 QoS가 BestEffort인 파드에, NotBestEffort는 나머지 QoS 클래스를 가진 파드에 적용한다
• Terminating은 파드스펙에 activeDeadlineSeconds가 설정된 파드에 적용된다.
• 각 파드가 종료되고 실패로 표시되기 전에 얼마나 오래 실행할 수 있는지 지정할 수 있다.(activeDeadlineSeconds)

 

# BestEffort/NotTerminating 파드에 대한 리소스쿼터

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort-notterminating-pods
spec:
  scopes:
  - BestEffort
  - NotTerminating
  hard:
    pods: 4

 

scope가 BestEffort가 지정된 경우 리소스에 대한 제한은 지정할 수 없다.

 

 

6. 파드 리소스 사용량 모니터링

• 과도한 리소스 요청은 서비스 장애를 일으키고 과도한 리소스 제한은 리소스 낭비를 초래한다.
• 예상되는 부하 수준에서 컨테이너의 실제 리소스 사용량을 모니터링해 적정 요청, 제한을 찾아야 한다.

6.1 실제 리소스 사용량 수집과 검색

• cAdvisor 에이전트는 노드에서 실행되는 개별 컨테이너와 노드 전체의 리소스 사용 데이터를 수집한다.
• 전체 클러스터에서 이러한 통계를 주앙에서 수집하려면 힙스터라는 추가 구성요소를 실행해야 한다.(최신은 매트릭 서버)
• 힙스터는 노드 중 하나에서 파드로 실행되며 쿠버네티스 서비스를 통해 노출돼 IP로 접속이 가능하다.

# 매트릭 조회를 위해 필요한 리소스 매니페스트

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        image: k8s.gcr.io/metrics-server/metrics-server:v0.4.2
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

 

 

클러스터 노드의 CPU 및 메모리 사용량 표시

$ kbc top node

NAME                              CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
dkosv3-poi-cluster-ingress-5bzg   93m          2%     2786Mi          37%
dkosv3-poi-cluster-master-1       860m         22%    3705Mi          51%
dkosv3-poi-cluster-worker-47hn    112m         2%     3432Mi          46%
dkosv3-poi-cluster-worker-b7cl    119m         3%     3435Mi          46%
dkosv3-poi-cluster-worker-pbbl    259m         6%     3604Mi          48%

 

개별 파드의 CPU와 메모리 사용량 표시

$ kbc top pod --all-namespaces

NAMESPACE       NAME                                                  CPU(cores)   MEMORY(bytes)
default         demon-4sxsh                                           1m           244Mi
default         kubia-hostport                                        0m           8Mi
default         pod-add-settime-capability                            0m           0Mi
default         pod-as-user-guest                                     0m           0Mi
default         pod-drop-chown-capability                             0m           0Mi
default         pod-privileged                                        0m           0Mi
default         pod-with-host-network                                 0m           0Mi
default         pod-with-host-network-poi                             0m           0Mi
default         pod-with-host-pid-and-ipc                             0m           0Mi
default         pod-with-readonly-filesystem                          0m           0Mi
default         pod-with-shared-volume-fsgroup                        0m           1Mi
default         pod-with-shared-volume-fsgroup-poi                    0m           2Mi
default         poi-deployment-578dc868d9-cnjsj                       2m           134Mi
default         poi-deployment-578dc868d9-sckpm                       1m           138Mi
default         poi-deployment-578dc868d9-v9m74                       1m           133Mi
default         poid                                                  200m         61Mi
ingress-nginx   ingress-nginx-controller-poi-jrtrf                    3m           93Mi
kakao-system    fluentd-auditlog-pwcdq                                2m           89Mi

...

 

 

6.2 기간별 리소스 사용량 통계 저장 및 분석

• top 명령은 현재 리소스 사용량만 표시해서 기간 별 리소스 집계가 안된다
• 일반적으로 집계를 위해 저장은 인플럭스DB를, 시각화를 위해 그라파나를 사용한다