가상 머신은 OpenShift 가상화를 기반으로 실행되며 기본적으로 vCPU 및 메모리 요구 사항에 따라 예약되므로 기존 작업자 노드에 VM이 균형 있게 분산됩니다.
스케줄링 결정에는 더 많은 리소스가 필요하지만, 가독성을 위해 이 게시물의 대부분 예에서는 CPU와 메모리로 제한합니다.
VM은 요청된 리소스에 따라 균형을 이루지만, 활용도 관점에서 균형을 보면 상황이 달라집니다. 클러스터의 모든 VM은 요청된 리소스 관점에서 균형을 이루지만, 바쁜 VM은 노드 하위 집합을 독점하여 성능에 부정적인 영향을 미칠 수 있습니다.
이 시나리오는 아래 다이어그램에 나와 있습니다.
이 블로그 게시물에서는 활용도가 워크로드 성능에 영향을 미치는지 감지하는 방법과 상황을 개선하기 위해 취할 수 있는 단계에 대해 자세히 알아보겠습니다.
문제
OpenShift Virtualization에서는 다른 많은 가상화 플랫폼과 마찬가지로 효율적인 CPU 사용을 위해 CPU 오버커밋이 기본적으로 활성화되어 있습니다. CPU 오버커밋의 한 가지 단점은 동일한 CPU 코어를 사용하는 VM이 너무 많을 경우 CPU 리소스 경합이 발생할 수 있다는 것입니다.
크기가 동일한 4개의 VM(각각 4개의 vCPU)이 두 노드에 분산되어 있는 경우를 예로 들어 보겠습니다. VM의 크기는 동일하지만 리소스 사용률 은 서로 다릅니다 . 첫 번째 노드에서는 두 VM 모두 사용 중(높은 CPU 사용률)이고, 두 번째 노드에서는 두 VM 모두 유휴 상태(낮은 CPU 사용률)입니다. 이 경우, 첫 번째 노드의 VM은 CPU 경합으로 인해 성능 저하를 경험할 가능성이 높습니다.
리소스 요청 관점에서 볼 때, 모든 VM이 동일한 양의 CPU 리소스를 요청했기 때문에 클러스터는 균형을 이루고 있습니다.
성능 영향 관점에서 볼 때, 클러스터의 균형이 맞지 않습니다. 바쁜 VM이 리소스를 놓고 경쟁하고, 유휴 VM이 있는 노드에서는 CPU 리소스가 사용되지 않기 때문입니다.
이상적인 환경에서는 사용 가능한 모든 리소스를 활용하고 각 노드의 성능 영향을 최소화하기 위해 바쁜 VM을 두 노드에 분산해야 합니다.
작업 부하 성능 및 리소스 부족
작업 부하가 100% 용량으로 실행되더라도 항상 필요한 모든 리소스를 사용할 수 있는 한 반드시 문제가 되지는 않습니다.
하지만 워크로드에서 리소스 부족 현상이 발생하면 워크로드 성능에 부정적인 영향을 미치게 됩니다. 예를 들어, 메모리에는 처리할 데이터가 있지만 CPU 사용 시간이 부족하면 CPU 경합으로 인해 VM이 중단됩니다.
앞서 두 개의 유휴 VM이 단일 CPU 코어를 공유하는 예를 고려했을 때, VM이 유휴 상태이므로 CPU 경합이 발생하지 않을 가능성이 높습니다. 그러나 두 번째 노드에서 다른 두 개의 사용 중인 VM은 CPU 경합을 겪고 있을 가능성이 높으므로 성능이 최적화되지 않은 상태로 실행될 가능성이 높습니다.
참고로, 과도하게 할당된 시스템에서는 정의상 작업 부하가 항상 필요한 모든 리소스를 얻지 못할 것으로 예상되지만, 이러한 상황을 개선할 수 있는 기회가 있습니다.
사용률 측정은 워크로드가 최적의 성능으로 작동하는지 파악하는 데 도움이 되지 않습니다. 워크로드 집합이 소비하는 총 리소스 양을 기준으로 리밸런싱하는 대신, 워크로드 전체의 리소스 부족을 최소화하도록 리밸런싱해야 합니다.
해결책
OpenShift Descheduler Operator 에는 다양한 전략(프로파일)에 따라 클러스터를 재조정하는 도구가 이미 있습니다. 그러나 현재 Descheduler에는 리소스 부족을 고려하는 프로파일이 없습니다.
자원 부족 측정
Descheduler는 노드에서 워크로드를 제거하므로, 이 맥락에서 리소스 부족 현상이 심각한 노드를 파악해야 합니다. 워크로드를 제거하면 리소스 부족 현상이 줄어들고 결과적으로 워크로드 성능이 향상됩니다.
따라서 남은 질문은 시스템이 리소스 부족으로 인해 작업 부하가 성능에 가장 큰 영향을 미치는 노드를 어떻게 식별할 수 있는가입니다.
” PSI는 리소스 압력이 증가하는 상황을 실시간으로 파악할 수 있는 표준적인 방법을 처음으로 제공합니다 . ” 페이스북은 지난 몇 년간 개발하여 업스트림 리눅스 커널에 기여해 온 압력 정체 정보(PSI)Pressure Stall Information (PSI)를 이렇게 설명합니다 . 이 도구(또는 지표)는 프로세스의 CPU, 메모리, IO 부족을 노드 수준에서 누적적으로 측정할 수 있습니다. 따라서 프로세스가 정상 상태일 때 높은 사용률을 살펴보는 대신, 이 새로운 지표를 통해 프로세스에 문제가 발생하기 시작하는 시점을 파악할 수 있습니다.
이는 가상화 분야의 vCPU 대기 측정 지표 와 매우 유사하지만 , 일반적으로 모든 Linux 프로세스에서 사용할 수 있습니다.
몇 가지 연구 개발과 초기 조사를 거쳐 PSI는 우리의 사용 사례에 사용할 수 있는 귀중한 지표로 밝혀졌습니다.
Kubernetes 생태계에서 PSI는 이미 노드 내보내기를 통해 노출되어 있으며, 이를 통해 OpenShift Observability 스택 의 핵심 구성 요소인 Prometheus에 메트릭을 제공합니다 .
Descheduler – 바쁜 노드의 부담을 줄입니다.
OpenShift Descheduler Operator는 구성 가능한 간격으로 실행되는 프로파일을 사용하여 구성됩니다. 일반적으로 프로파일은 두 단계로 구성됩니다.
- 포드 스케줄링 해제를 위해 고려해야 할 노드를 선택하세요.
- 퇴거할 포드를 하나 이상 선택하세요
기존의 Long-Lifecycle 프로필은 과도하게 활용된 노드를 식별하고 VM 일정을 취소하여 클러스터의 모든 노드에 리소스 요청을 균등하게 분배함으로써 장기 실행 VM의 균형을 맞추는 데 이미 사용되고 있습니다.
본 연구 에서는 이 프로필을 확장하여 노드 수준 PSI 정보를 선택적으로 사용할 수 있도록 했습니다. 스케줄러 해제(descheduler)는 Prometheus에서 노드별 PSI 지표를 수집하여 노드를 과다 사용, 미달 사용, 또는 적정 사용으로 분류합니다. 과다 사용 또는 미달 사용 노드가 있는 경우, 스케줄러 해제는 Pod를 제거하여 가상 머신을 노드에서 마이그레이션합니다. 결과적으로 과다 사용 노드의 부하가 감소합니다.
압력이 충분히 낮아지면 실제로 해당 노드가 스케줄러에 의해 과소 활용되거나 적절하게 활용되는 것으로 분류될 수 있습니다. 이러한 현상의 발생 여부는 전체 클러스터 압력에 따라 달라집니다.
오늘날 추방할 포드를 선택하는 것은 단순히 kubelet의 추방 명령과 유사합니다 .
스케줄링 – 바쁜 노드를 더 많은 압력으로부터 보호
포드가 노드에서 추방되면, 즉 가상 머신이 노드에서 마이그레이션되면 해당 포드가 다시 바쁜 노드에 착륙하지 않도록 해야 합니다.
트라이마란(trimaran) 스케줄러 플러그인과 같은 기존 접근 방식은 쿠버네티스 스케줄러 확장에 의존했습니다. 저희의 목표 중 하나는 관측성 스택에 쿠버네티스 스케줄러의 새로운 직접 종속성을 추가하는 것을 피하는 것이었습니다. 따라서 트라이마란 접근 방식을 따르는 대신, 기존 스케줄링 메커니즘, 특히 특정 노드에서 파드를 분리하는 데 사용되는 테인트(Taint)를 활용하기로 했습니다 .
디스케줄러는 테인트를 활용합니다. 과도하게 사용 중인 노드를 식별하면, 디스케줄러는 해당 노드에 PreferNoSchedule 효과를 적용하여 가능한 경우 해당 노드에서 워크로드를 분산시킵니다. 노드가 더 이상 과도하게 사용 중이지 않으면 테인트가 제거되고 해당 노드는 다시 스케줄링에 사용 가능하게 됩니다.
요약
모든 조각을 하나로 합치면 최종 그림은 다음과 같습니다. Prometheus를 통해 PSI를 사용하여 측정한 노드 수준 압력을 사용하는 확장된 장기 수명 주기 프로필을 갖춘 수정된 OpenShift Descheduler Operator입니다.
우리는 이를 기존 LongLifecycle OpenShift Descheduler Operator 프로필의 확장으로 구현하기로 결정했습니다. 솔루션의 첫 번째 부분은 descheduler 프로필을 확장하는 것입니다.
- 노드가 특정 압력 임계값을 넘어서면 재균형을 시작합니다.
- 클러스터에 활용도가 낮은 노드가 있는 경우에만 재조정을 시도하십시오.
- 클러스터가 합리적으로 균형 잡혀 있고 예상 이득이 너무 낮은 경우 재조정을 중지합니다.
- 노드 압력을 노드 순위 지표로 사용
솔루션의 두 번째 부분은 과도하게 활용되는 노드를 보호하여 해당 노드에 새로운 작업 부하가 예약되는 것을 방지하는 것입니다.
검증 접근 방식
목적
우리의 목표는 새로운 프로필을 적용한 디스케줄러가 클러스터의 모든 노드에서 노드 수준 CPU 압력(PSI)을 평준화할 수 있는지 검증하여 작업 부하에 미치는 영향을 최소화하는 것이었습니다.
측정
아래에 사용된 메트릭은 커널 수준에서 PSI 메트릭이 활성화된 경우 기본적으로 모든 최신 node_exporter에서 내보내집니다. OpenShift에서는 이러한 메트릭이 기본적으로 비활성화되어 있으며, 작업자 및 제어 평면 노드 에 대해 다음 MachineConfigs를 사용하여 활성화되었습니다 .
베이스
노드 수준 CPU 압력은 다음 Prometheus 메트릭을 사용하여 측정되었습니다.
node_pressure_cpu_waiting_seconds_total
이 원시 지표는 사용할 수 없는 CPU를 기다리며 최소한 작업 부하가 중단된 시간(초)을 단조롭게 증가시키는 수치를 제공합니다.
절대적인 초 수보다 우리는 해당 기간 동안 리소스를 사용할 수 없었던 초의 백분율에 관심이 있습니다. 따라서 다음 사항에 관심이 있습니다.
rate(node_pressure_cpu_waiting_seconds_total[1m])
결과 값은 0과 1 사이의 숫자로, CPU를 사용할 수 없어 노드의 작업 부하 중 일부가 멈춰 있는 시간의 비율을 나타냅니다.
균형
압력 균형은 다음 공식을 사용하여 작업자 노드 간 CPU 압력의 표준 편차로 측정되었습니다.
stddev(sum by (instance) (rate(node_pressure_cpu_waiting_seconds_total[1m]) * on(instance) group_left(node) label_replace(kube_node_role{role="worker"}, 'instance', "$1", 'node', '(.+)')))환경
테스트 중에는 Red Hat Scalelab 환경이 사용되었으며 다음으로 구성되었습니다.
- 3개의 콘트롤 플레인 노드
- 10개의 워커 노드
관련된 모든 노드의 하드웨어는 동일했습니다.
$ oc describe worker d35-h24-000-r660 Name: d35-h24-000-r660 Roles: worker … Capacity: cpu: 112 devices.kubevirt.io/kvm: 1k devices.kubevirt.io/tun: 1k devices.kubevirt.io/vhost-net: 1k ephemeral-storage: 467566400Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 527841984Ki pods: 250 … System Info: Machine ID: … System UUID: … Boot ID: 590c18c0-32a4-4e6b-8a2c-c943459fafbd Kernel Version: 5.14.0-427.47.1.el9_4.x86_64 OS Image: Red Hat Enterprise Linux CoreOS 417.94.202412040832-0 Operating System: linux Architecture: amd64 Container Runtime Version: cri-o://1.30.8-3.rhaos4.17.git359f960.el9 Kubelet Version: v1.30.6 Kube-Proxy Version: v1.30.6 … $
테스트 시나리오
시나리오 1 – “새로운 노드”
이 시나리오는 다음과 같이 설명할 수 있습니다.
- 동일한 CPU 요청을 갖는 VM의 무작위 분포이지만 하나는 CPU 부하가 높고 다른 그룹은 CPU 부하가 낮습니다.
- 그런 다음 새로운 노드를 작업에 도입합니다.
- 마지막으로 재조정을 활성화합니다.
예상 결과
예상되는 결과는 노드 압력에 따라 균형 잡힌 클러스터입니다.
시나리오 2 – “극심한 불균형”
이 시나리오는 다음과 같이 설명할 수 있습니다.
- 균등하게 분할된 클러스터
- 동일한 CPU 요청을 갖는 VM, 한 파티션에 CPU 부하가 높은 VM, 다른 파티션에 CPU 부하가 낮은 VM
- 마지막으로 재조정을 활성화합니다.
이 시나리오는 다음 다이어그램에 설명되어 있습니다.
예상 결과
시나리오 1과 마찬가지로 노드 압력에 따라 균형 잡힌 클러스터가 예상됩니다.
평가
우리 솔루션의 평가는 다음의 업스트림 보고서 저장소를 사용하여 수행되었습니다: https://github.com/openshift-virtualization/descheduler-psi-evaluation
두 가지 시나리오를 포괄하는 테스트 스크립트는 https://github.com/openshift-virtualization/descheduler-psi-evaluation에서 제공되며, 다양한 환경에서 쉽게 재현할 수 있습니다.
첫 번째 단계는 클러스터가 필요한 모든 구성 요소로 올바르게 구성되었는지 확인하는 것입니다.
$ bash to.sh deploy
클러스터를 구성하기 위해 몇 가지 매니페스트를 적용하는 데 사용할 수 있습니다. 자세한 내용은 다음과 같습니다.
10-mc-psi-controlplane.yaml # to enable PSI at Kernel level for controlplane nodes 11-mc-psi-worker.yaml # to enable PSI at Kernel level for worker nodes 12-mc-schedstats-worker.yaml # to enable shedstat at Kernel level for worker nodes
그런 다음 필요한 연산자가 배포되고 구성됩니다.
20-namespaces.yaml # to create required namespaces 30-operatorgroup.yaml # to create operatorgroups 31-subscriptions.yaml # to create operator subscriptions 40-cnv-operator-cr.yaml # to configure OpenShift Virtualization (vanilla configuration) 41-descheduler-operator-cr.yaml # to configure Kube Descheduler Operator (custom) 50-desched-taint.yaml # custom component to taint nodes according to actual utilization
e2e 테스트는 다음을 사용하여 실행할 수 있습니다.
$ export TEST_SCENARIO=1 # or TEST_SCENARIO=2 to choose the desired test scenario $ bash to.sh apply $ bash e2e-test.sh
테스트 아티팩트
e2e 테스트는 두 개의 VirtualMachinePool에 적용됩니다. VirtualMachinePool은 지정된 수의 VirtualMachine 복제본이 언제든지 준비 상태에 있는지 확인합니다.
00-vms-no-load.yaml # a pool of idle VMs 01-vms-cpu-load.yaml # a pool of CPU intesive VMs
두 풀의 VM은 동일한 양의 CPU와 메모리를 요구하도록 구성됩니다.
무부하 풀의 VM은 완전히 유휴 상태이며, CPU 부하 풀의 VM은 OpenSSL 알고리즘 속도 측정을 연속 루프로 실행하여 CPU에 부하를 주도록 구성됩니다.
테스트 흐름
두 시나리오에 대한 일반적인 테스트 흐름은 다음 순서로 요약할 수 있습니다.
- 기존 VM 풀의 규모를 줄이고 스케줄러를 비활성화하여 깨끗한 환경을 확보합니다.
- 시나리오에 따라 부하 생성을 시작합니다.
- 특정 임계값에 도달할 때까지 부하를 확장합니다.
- 향후 참조를 위해 작업자 노드 전체의 CPU PSI 압력의 표준 편차를 저장합니다.
- Descheduler를 트리거하고 클러스터 재조정을 시작하기에 충분한 시간(10분)을 두었습니다.
- 작업자 노드 전체의 CPU PSI 압력 표준 편차가 불균형 초기 상황보다 낮은지 확인합니다.
- 클러스터가 수렴하고 균형 상태를 유지하는지 확인하기 위해 1시간 동안 클러스터를 계속 관찰합니다.
- 청소하세요.
테스트 결과
시나리오 #1
테스트는 09:45에 시작되어 CPU 집약형 풀과 무부하 풀에서 동일한 양의 VM을 점진적으로 생성했습니다.
실험실 내 10개의 워커 노드 중 3개의 노드가 초기에 오염되어 약 700개의 VM(350개는 부하 발생, 350개는 부하 없음)이 7개 노드에 균등하게 분산되었습니다. 초기에 오염된 3개의 노드에는 VM이 없었습니다.
노드당 CPU 집약적 VM 수
노드당 무부하 VM 수
오전 10시 2분경 평균 압력이 트리거 임계값에 도달했고, 부하 램프가 중단되었으며 시스템은 오전 10시 5분까지 3분간 안정되었습니다.
10시 5분에 마지막 세 개의 노드가 손상되지 않고 스케줄링이 가능해졌으며 스케줄 해제가 트리거되었습니다.
노드당 CPU 압력 및 stddev(파란색)
디스케줄러는 CPU 집약적 VM과 무부하 VM을 모두 트리 스페어 노드로 빠르게 마이그레이션하기 시작했습니다.
클러스터 내 마이그레이션 수
마이그레이션은 시스템이 균형 상태에 도달하고 다른 마이그레이션이 발생하지 않을 때까지 10시 17분까지 계속되었습니다.
전체적으로 스케줄러는 약 700개의 활성 VM에서 약 135개의 VM을 이동하기 위해 약 140개의 마이그레이션을 트리거했습니다.
이 시나리오에서는 활성 VM/마이그레이션 비율이 96%로 매우 좋습니다.
오전 10시 17분경 CPU 압력의 표준 편차는 0에 가까웠습니다. CPU 압력이 이제 10개의 활성 노드에 균등하게 분산되었기 때문입니다.
CPU 압력은 선형적 측정 기준이 아니므로 마지막 시점(10:17 이후)의 평균 CPU 압력은 여전히 0.6 정도였고, 10:02의 최고치는 약 0.7이었습니다.
총 350개의 CPU 집약적 VM이 있으며, 10:02 시점에는 7개의 워커 노드에서 평균 50개의 CPU를 실행했습니다. 테스트 종료 시점에는 10개의 노드에 분산되어 평균 35개의 CPU를 실행했습니다. 테스트 종료 시점의 평균 부하(각 노드당 평균 35개의 VM)가 09:57 시점의 램프 업 ⅔ 시점에 기록된 평균 부하와 매우 유사함을 명확히 알 수 있습니다. 7개의 활성 노드 각각에 약 35개의 CPU 집약적 VM이 실행되었습니다. 따라서 CPU 부하가 선형 지표는 아니지만, 재조정 후 예상 값에 도달했다는 결론을 쉽게 내릴 수 있습니다.
시나리오 #2
테스트는 오전 7시 35분에 시작되었습니다. 클러스터 워커 노드가 두 개의 파티션으로 나뉘었습니다. 노드의 절반은 차단되었지만 나머지 다섯 개는 여전히 스케줄링이 가능했습니다.
시스템 포드에서 발생하는 압력으로 인해, 과도한 부하로부터 보호하기 위해 두 노드에 테인터(소프트) 테인트를 적용했기 때문에 CPU를 많이 사용하는 VM은 처음에는 3개 노드에서만 확장되었습니다.
08:06에 3개의 작업자 노드에 걸쳐 약 250개의 CPU 집약적 VM이 분산되어 있었고 이는 충분한 평균 압력을 생성하고 중단을 막기에 충분했습니다.
시스템은 3분간 안정되었고, 오전 8시 9분경 봉쇄된 구역과 봉쇄되지 않은 구역의 경계가 뒤집혔습니다.
이제 나머지 절반의 노드에서 250개의 무부하 VM 세트가 시작되었습니다.
08:10에 클러스터가 완전히 불균형 상태입니다. 3개 노드에 CPU를 많이 사용하는 VM이 250개 있고, 다른 5개 노드에 부하가 없는 VM이 250개 있습니다. 다른 시스템 포드에서 발생한 오염으로 인해 2개 노드가 VM을 실행하지 않습니다.
오전 8시 12분경, 10개의 모든 워커 노드가 해제되어 스케줄링이 가능해졌습니다.
노드당 CPU 집약적 VM 수
노드당 무부하 VM 수
오전 8시 5분경 압력이 최고조에 달했습니다. 오전 9시 9분에 시작된 무부하 VM은 압력을 증가시키지 않았습니다.
오전 8시 14분경 스케줄러가 활성화되었고 CPU를 많이 사용하는 VM을 실행하지 않는 노드의 CPU 압력이 급격히 증가하는 것을 확인했습니다.
노드당 CPU 압력 및 stddev(파란색)
08:14에 스케줄러가 작업 중인 노드의 부하가 높은 파티션에서 CPU 사용량이 많은 VM만 다른 VM으로 마이그레이션하기 시작했습니다. 무부하 VM 그래프를 보면 08:12부터 08:28까지 무부하 VM이 전혀 마이그레이션되지 않았고, 이후 08:32경에야 밸런싱을 완료하기 위해 몇몇 무부하 VM만 마이그레이션되었음을 알 수 있습니다.
노드당 CPU 집약적 VM 그래프에서 처음에 로드된 노드는 각각 약 30개의 CPU 집약적 VM으로 끝났고, 다른 7개 노드는 각각 약 20개의 VM으로 끝났지만, 처음에 생성된 250개의 무부하 VM도 관리하고 있으며, 소수(<10)만 마이그레이션되었습니다.
클러스터 내 마이그레이션 수
시스템이 균형 상태에 도달한 08:34에 마이그레이션이 중단되었습니다.
전체적으로 스케줄러는 약 200개의 마이그레이션을 트리거했고, 밸런싱은 500개의 활성 VM에서 약 150개의 VM을 이동하는 데 필요했습니다.
이 경우 영향을 받는 VM/마이그레이션 비율은 약 75%로 낮았지만 클러스터의 균형이 매우 불균형했습니다.
08:32경 CPU 압력의 표준 편차는 0에 가까웠는데, CPU 압력이 이제 10개의 활성 노드에 균등하게 분산되었기 때문입니다.
이 시나리오에서도 CPU 압력이 선형적 지표가 아니라는 것을 명확히 알 수 있습니다. 즉, 각각 20~30개의 CPU를 많이 사용하는 VM을 실행하는 10개의 활성 작업자에 대한 평균 CPU 압력(08:32 이후)은 약 0.55입니다.
처음에 활성화된 3개의 노드는 07:42경에 평균 0.55의 압력을 보고했으며, 각각 평균적으로 CPU를 많이 사용하는 VM을 25개 실행하고 있었습니다. 따라서 이 시나리오에서도 재조정 후 CPU 압력이 평균적으로 다시 예상 값에 도달했으며 노드 간 표준 편차가 0에 가깝다는 결론을 쉽게 내릴 수 있습니다.
시도해 보세요 & 시작하기
이 블로그 게시물은 OpenShift Virtualization의 부하 인식 리밸런싱에 대한 개발자 프리뷰를 기반으로 합니다 . 최신 버전의 OpenShift Descheduler Operator가 포함된 OpenShift 4.17을 사용하면 이러한 결과를 여러분의 랩에서 재현하기에 충분합니다.
시작하는 데 필요한 필수 사항은 다음과 같습니다.
- PSI 메트릭을 노출하기 위해 MachineConfigPools를 재구성합니다.
- OpenShift Virtualization 및 Descheduler Operators 배포 및 구성
- 노드 컨테이너 구성 요소 배포
이러한 모든 단계는 다음을 실행하여 완료됩니다.
$ git clone https://github.com/openshift-virtualization/descheduler-psi-evaluation.git Cloning to 'descheduler-psi-evaluation'... … $ cd descheduler-psi-evaluation $ oc login … $ bash to.sh deploy … $
이제 모든 준비가 완료되었습니다. 모든 새 VM과 기존 VM은 60초마다 재조정됩니다.
결론
우리는 descheduler를 변경하고 압력에 따라 노드를 오염시키는 구성 요소를 포함시키면 바쁜 작업 부하가 균등하게 분산되고 개별 작업 부하에 대한 압력이 감소한다는 것을 검증할 수 있었습니다.
다음 단계
다음 단계는 다음과 같습니다.
- 노드 오염 구현 개선 및 병합
- 확장된 프로필을 GA로 전환하고 추가 확장 및 성능 평가 후 OpenShift의 일부로 제공합니다.
향후 주제
– 제한된 워크로드가 노드 부하에 미치는 영향에 대해 Kubernetes KEP 4205 에 피드백을 제공하세요 . 이 KEP를 발전시키는 데 참여하세요.
- PSI가 노드 압력 제거 에 어떻게 사용될 수 있는지 조사합니다.
- PSI가 적절한 규모의 작업 요청을 처리하는 데 도움이 될 수 있나요?
