🥇Kubernetes: 시스템 리소스 관리를 구성하는 것이 왜 그렇게 중요한가요?

일반적으로 애플리케이션의 올바르고 안정적인 작동을 위해서는 항상 전용 리소스 풀을 애플리케이션에 제공해야 합니다. 하지만 여러 애플리케이션이 동일한 전원으로 실행되고 있다면 어떻게 될까요? 그들 각각에게 최소한의 필요한 자원을 제공하는 방법은 무엇입니까? 자원 소비를 어떻게 제한할 수 있나요? 노드 간에 로드를 올바르게 분배하는 방법은 무엇입니까? 애플리케이션 로드가 증가하는 경우 수평 확장 메커니즘이 작동하도록 하려면 어떻게 해야 합니까?

시스템에 존재하는 주요 리소스 유형부터 시작해야 합니다. 물론 이는 프로세서 시간과 RAM입니다. k8s 매니페스트에서 이러한 리소스 유형은 다음 단위로 측정됩니다.

CPU - 코어 내
RAM - 바이트 단위

또한 각 리소스에 대해 두 가지 유형의 요구 사항을 설정할 수 있습니다. 요청 и 제한. 요청 - 컨테이너(및 포드 전체)를 실행하기 위한 노드의 여유 리소스에 대한 최소 요구 사항을 설명하는 반면, 제한은 컨테이너에 사용 가능한 리소스에 대한 엄격한 제한을 설정합니다.

매니페스트가 두 유형을 모두 명시적으로 정의할 필요는 없지만 동작은 다음과 같다는 점을 이해하는 것이 중요합니다.

리소스의 제한만 명시적으로 지정된 경우 이 리소스에 대한 요청은 자동으로 제한과 동일한 값을 사용합니다(설명 엔터티를 호출하여 이를 확인할 수 있음). 저것들. 실제로 컨테이너는 실행하는 데 필요한 리소스 양과 동일한 양으로 제한됩니다.
리소스에 대해 요청만 명시적으로 지정된 경우 이 리소스에는 더 높은 제한이 설정되지 않습니다. 컨테이너는 노드 자체의 리소스에 의해서만 제한됩니다.

특정 컨테이너 수준뿐만 아니라 다음 엔터티를 사용하여 네임스페이스 수준에서도 리소스 관리를 구성할 수도 있습니다.

제한 범위 — 컨테이너/포드 수준의 제한 정책을 ns 단위로 설명하며 컨테이너/포드에 대한 기본 제한을 설명하고 명백히 뚱뚱한 컨테이너/포드(또는 그 반대) 생성을 방지하고 개수를 제한하는 데 필요합니다. 한도 및 요청 값의 가능한 차이를 결정합니다.
리소스할당량 — ns의 모든 컨테이너에 대한 일반적인 제한 정책을 설명하고 일반적으로 환경 간 리소스를 구분하는 데 사용됩니다(환경이 노드 수준에서 엄격하게 구분되지 않은 경우 유용함).

다음은 리소스 제한을 설정하는 매니페스트의 예입니다.

특정 컨테이너 수준에서:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
저것들. 이 경우 nginx로 컨테이너를 실행하려면 노드에 최소 1G의 여유 RAM과 0.2 CPU가 필요하며, 컨테이너는 최대 0.2 CPU와 노드에서 사용 가능한 모든 RAM을 사용할 수 있습니다.
정수 수준 ns에서:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
저것들. 기본 ns의 모든 요청 컨테이너 합계는 CPU의 경우 300m, OP의 경우 1G를 초과할 수 없으며 모든 제한의 합계는 CPU의 경우 700m, OP의 경우 2G입니다.
ns 단위의 컨테이너에 대한 기본 제한:
```
apiVersion: v1
kind: LimitRange
metadata:
  name: nxs-limit-per-container
spec:
 limits:
   - type: Container
     defaultRequest:
       cpu: 100m
       memory: 1Gi
     default:
       cpu: 1
       memory: 2Gi
     min:
       cpu: 50m
       memory: 500Mi
     max:
       cpu: 2
       memory: 4Gi
```
저것들. 모든 컨테이너의 기본 네임스페이스에서 요청은 CPU의 경우 100m, OP의 경우 1G로 설정되고 제한은 CPU 및 1G로 설정됩니다. 동시에 CPU(2m < x < 50) 및 RAM(2M < x < 500G)에 대한 요청/제한에서 가능한 값에도 제한이 설정됩니다.

포드 수준 제한사항 ns:

apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi

저것들. 기본 ns의 각 포드에는 vCPU 4개 및 1G로 제한됩니다.

이제 이러한 제한을 설정하면 어떤 이점을 얻을 수 있는지 말씀드리고 싶습니다.

노드 간 로드 밸런싱 메커니즘

아시다시피 k8s 구성 요소는 다음과 같은 노드 간 Pod 배포를 담당합니다. 스케줄러, 특정 알고리즘에 따라 작동합니다. 이 알고리즘은 시작할 최적의 노드를 선택할 때 두 단계를 거칩니다.

필터링
범위

저것들. 설명된 정책에 따라 초기에 노드는 세트를 기반으로 포드를 시작할 수 있도록 선택됩니다. 술어 (노드에 포드를 실행하기에 충분한 리소스가 있는지 확인하는 것 - PodFitsResources 포함) 그런 다음 각 노드에 대해 다음을 따릅니다. 우선순위 포인트가 부여되고(노드에 무료 리소스가 많을수록 더 많은 포인트가 할당됨 - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation 포함) 가장 많은 포인트가 있는 노드에서 포드가 시작됩니다(여러 노드가 동시에 이 조건을 충족하는 경우 무작위로 선택됩니다).

동시에, 노드의 사용 가능한 리소스를 평가할 때 스케줄러가 etcd에 저장된 데이터에 따라 안내된다는 점을 이해해야 합니다. 이 노드에서 실행되는 각 Pod의 요청/제한 리소스 양에 대한 것이지만 실제 리소스 소비에는 해당되지 않습니다. 이 정보는 명령 출력에서 얻을 수 있습니다. kubectl describe node $NODE예 :

# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods:         (9 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  ingress-nginx              nginx-ingress-controller-754b85bf44-qkt2t    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-flannel-26bl4                           150m (0%)     300m (1%)   64M (0%)         500M (1%)      233d
  kube-system                kube-proxy-exporter-cb629                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-proxy-x9fsc                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                nginx-proxy-k8s-worker-s1                    25m (0%)      300m (1%)   32M (0%)         512M (1%)      233d
  nxs-monitoring             alertmanager-main-1                          100m (0%)     100m (0%)   425Mi (1%)       25Mi (0%)      233d
  nxs-logging                filebeat-lmsmp                               100m (0%)     0 (0%)      100Mi (0%)       200Mi (0%)     233d
  nxs-monitoring             node-exporter-v4gdq                          112m (0%)     122m (0%)   200Mi (0%)       220Mi (0%)     233d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                487m (3%)          822m (5%)
  memory             15856217600 (2%)  749976320 (3%)
  ephemeral-storage  0 (0%)             0 (0%)

여기에서는 특정 노드에서 실행 중인 모든 포드와 각 포드가 요청하는 리소스를 볼 수 있습니다. 다음은 cronjob-cron-events-1573793820-xt6q9 포드가 시작될 때 스케줄러 로그의 모습입니다(이 정보는 시작 명령 인수 -v=10에서 10번째 로깅 수준을 설정할 때 스케줄러 로그에 나타납니다).

로그

I1115 07:57:21.637791       1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do                                                                             
I1115 07:57:21.639333       1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10

여기서는 처음에 스케줄러가 시작할 수 있는 3개의 노드 목록을 필터링하고 생성하는 것을 볼 수 있습니다(nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). 그런 다음 가장 적합한 노드를 결정하기 위해 이러한 각 노드에 대한 여러 매개변수(BalancedResourceAllocation, LeastResourceAllocation 포함)를 기반으로 점수를 계산합니다. 궁극적으로 포드는 포인트 수가 가장 많은 노드에 예약됩니다(여기서 동시에 두 개의 노드는 동일한 포인트 수 100037을 가지므로 nxs-k8s-s10이라는 임의의 노드가 선택됩니다).

출력: 노드가 제한이 설정되지 않은 포드를 실행하는 경우 k8s의 경우(리소스 소비 관점에서) 이는 이 노드에 그러한 포드가 전혀 없는 것과 동일합니다. 따라서 조건부로 과도한 프로세스(예: wowza)가 있는 포드가 있고 제한이 설정되지 않은 경우 이 포드가 실제로 노드의 모든 리소스를 소비하는 상황이 발생할 수 있지만 k8s의 경우 이 노드 언로드된 것으로 간주되며 순위를 매길 때(정확히 사용 가능한 리소스를 평가하는 포인트에서) 작업 포드가 없는 노드와 동일한 수의 포인트가 부여됩니다. 이로 인해 궁극적으로 노드 간 로드가 고르지 않게 분산될 수 있습니다.

포드의 퇴거

아시다시피 각 포드에는 3가지 QoS 클래스 중 하나가 할당됩니다.

보장 — 포드의 각 컨테이너에 대해 메모리 및 CPU에 대한 요청 및 제한이 지정되고 이 값이 일치해야 할 때 할당됩니다.
파열 가능 — 포드에 있는 하나 이상의 컨테이너에 요청과 제한이 있고 요청 < 제한이 있습니다.
최선의 노력 — 포드의 단일 컨테이너가 리소스 제한이 없는 경우

동시에 노드에 리소스(디스크, 메모리)가 부족하면 kubelet은 포드의 우선순위와 QoS 클래스를 고려하는 특정 알고리즘에 따라 포드의 순위를 매기고 제거하기 시작합니다. 예를 들어 RAM에 대해 이야기하는 경우 QoS 클래스를 기반으로 다음 원칙에 따라 포인트가 부여됩니다.

보장: -삼
최고의 노력: 1000
버스트 가능: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

저것들. 동일한 우선순위로 kubelet은 먼저 노드에서 최선의 QoS 클래스를 갖춘 포드를 제거합니다.

출력: 리소스가 부족한 경우 원하는 포드가 노드에서 제거될 가능성을 줄이려면 우선순위와 함께 요청/한도 설정도 처리해야 합니다.

애플리케이션 포드(HPA)의 수평 자동 확장을 위한 메커니즘

k8s 엔터티와 같이 리소스(시스템 - CPU/RAM 또는 사용자 - rps) 사용에 따라 Pod 수를 자동으로 늘리거나 줄이는 작업인 경우 고전력 증폭기 (수평형 포드 자동 크기 조정기). 그 알고리즘은 다음과 같습니다.

관찰된 리소스의 현재 판독값이 결정됩니다(currentMetricValue).
리소스에 대해 원하는 값이 결정되며(desiredMetricValue), 시스템 리소스에 대해 요청을 사용하여 설정됩니다.
현재 복제본 수가 결정됩니다(currentReplicas).
다음 공식은 원하는 복제본 수(desiredReplicas)를 계산합니다.
DesiredReplicas = [ currentReplicas * ( currentMetricValue / DesiredMetricValue )]

이 경우 계수(currentMetricValue/desiredMetricValue)가 1에 가까우면 스케일링이 발생하지 않습니다(이 경우 허용되는 오류는 직접 설정할 수 있으며 기본적으로 0.1입니다).

CPU 소비에 따라 복제본 수를 변경해야 하는 앱 테스트 애플리케이션(배포라고 설명됨)의 예를 사용하여 hpa가 작동하는 방식을 살펴보겠습니다.

애플리케이션 매니페스트

kind: Deployment
apiVersion: apps/v1beta2
metadata:
name: app-test
spec:
selector:
matchLabels:
app: app-test
replicas: 2
template:
metadata:
labels:
app: app-test
spec:
containers:
- name: nginx
image: registry.nixys.ru/generic-images/nginx
imagePullPolicy: Always
resources:
requests:
cpu: 60m
ports:
- name: http
containerPort: 80
- name: nginx-exporter
image: nginx/nginx-prometheus-exporter
resources:
requests:
cpu: 30m
ports:
- name: nginx-exporter
containerPort: 9113
args:
- -nginx.scrape-uri
- http://127.0.0.1:80/nginx-status

저것들. 애플리케이션 포드가 처음에 두 개의 인스턴스에서 시작되는 것을 볼 수 있습니다. 각 인스턴스에는 두 개의 nginx 및 nginx-exporter 컨테이너가 포함되어 있습니다. 요청 CPU용.

HPA 선언문

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: app-test-hpa
spec:
maxReplicas: 10
minReplicas: 2
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: app-test
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 30

저것들. 배포 앱 테스트를 모니터링하고 CPU 표시기를 기반으로 애플리케이션으로 Pod 수를 조정하는 hpa를 만들었습니다(Pod는 요청한 CPU의 30%를 소비해야 함). 2~10의 범위.

이제 난로 중 하나에 부하를 가할 경우 hpa 작동 메커니즘을 살펴보겠습니다.

 # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi

전체적으로 우리는 다음을 가지고 있습니다:

원하는 값(desiredMetricValue) - hpa 설정에 따르면 30%입니다.
현재 값(currentMetricValue) - 계산을 위해 컨트롤러 관리자는 리소스 소비의 평균 값을 % 단위로 계산합니다. 조건부로 다음을 수행합니다.
1. 메트릭 서버로부터 Pod 메트릭의 절대값을 수신합니다. 101m와 4m
2. 평균 절대값을 계산합니다. 즉, (101m + 4m) / 2 = 53m
3. 원하는 리소스 소비에 대한 절대값을 가져옵니다. (이를 위해 모든 컨테이너의 요청이 합산됩니다.) 60m + 30m = 90m
4. 요청 Pod를 기준으로 CPU 소비의 평균 비율을 계산합니다. 53m / 90m * 100% = 59%

이제 복제본 수를 변경해야 하는지 결정하는 데 필요한 모든 것이 준비되었습니다. 이를 위해 계수를 계산합니다.

ratio = 59% / 30% = 1.96

저것들. 복제본 수는 ~2배로 증가하여 [2 * 1.96] = 4가 되어야 합니다.

결론 : 보시다시피, 이 메커니즘이 작동하려면 관찰된 포드의 모든 컨테이너에 대한 요청이 있어야 한다는 필수 조건이 있습니다.

노드의 수평 자동 확장을 위한 메커니즘(Cluster Autoscaler)

부하 서지가 발생하는 동안 시스템에 미치는 부정적인 영향을 중화하려면 hpa를 구성하는 것만으로는 충분하지 않습니다. 예를 들어, hpa 컨트롤러 관리자의 설정에 따라 복제본 수를 2배로 늘려야 한다고 결정했지만 노드에는 이러한 수의 Pod를 실행할 수 있는 여유 리소스가 없습니다(즉, 노드는 리소스를 요청 포드에 요청함) 이러한 포드는 보류 중 상태로 전환됩니다.

이 경우 제공업체에 해당 IaaS/PaaS(예: GKE/GCE, AKS, EKS 등)가 있는 경우 다음과 같은 도구를 사용하세요. 노드 자동 크기 조정기. 클러스터 및 Pod에 리소스가 부족할 때 클러스터의 최대 및 최소 노드 수를 설정하고 (클라우드 공급자 API를 호출하여 노드를 주문/제거함으로써) 현재 노드 수를 자동으로 조정할 수 있습니다. 예약할 수 없습니다(보류 중 상태).

결론 : 노드를 자동 크기 조정하려면 k8s가 노드의 로드를 올바르게 평가하고 이에 따라 클러스터에 다음 포드를 시작할 리소스가 없다고 보고할 수 있도록 포드 컨테이너에 요청을 설정해야 합니다.

결론

애플리케이션이 성공적으로 실행되기 위해 컨테이너 리소스 제한을 설정해야 하는 것은 아니지만 다음과 같은 이유로 그렇게 하는 것이 더 좋습니다.

k8s 노드 간 로드 밸런싱 측면에서 스케줄러의 보다 정확한 작동을 위해
"포드 퇴거" 이벤트가 발생할 가능성을 줄이기 위해
HPA(애플리케이션 포드)의 수평 자동 확장이 작동하려면
클라우드 공급자를 위한 노드의 수평적 AutoScaling(Cluster AutoScaling)

블로그에서 다른 기사도 읽어보세요.

출처 : habr.com

Kubernetes: 시스템 리소스 관리를 설정하는 것이 왜 그렇게 중요한가요?

노드 간 로드 밸런싱 메커니즘

포드의 퇴거

애플리케이션 포드(HPA)의 수평 자동 확장을 위한 메커니즘

노드의 수평 자동 확장을 위한 메커니즘(Cluster Autoscaler)

결론

블로그에서 다른 기사도 읽어보세요.

코멘트를 추가 답장을 취소