컨테이너 기반 애플리케이션의 성능을 개선하는 한 가지 방법은 노드를 추가하거나 CPU 또는 메모리와 같은 리소스를 노드에 추가하여 클러스터 리소스를 늘리는 것입니다. 그러나 이 방법은 비용이 많이 듭니다. 성능이 향상되도록 클러스터 노드를 조정하면 비용 효율적인 방식으로 워크로드의 리소스 사용률을 최적화하는 데 도움이 됩니다. 이 문서에서는 Performance Tuning Operator를 사용하여 워커 노드를 조정하여 Google Distributed Cloud의 워크로드 성능을 최적화하는 방법을 설명합니다.
기본 하드웨어 및 소프트웨어를 최대한 활용하기 위해 다음과 같은 노드 설정을 조정하면 다양한 유형의 애플리케이션, 특히 고성능 애플리케이션에서 이점을 얻을 수 있습니다.
- 성능에 민감한 워크로드용 전용 CPU
- 표준 Kubernetes 데몬 및 서비스를 위해 예약된 CPU
- 1GiB(기비바이트) 또는 2MiB(메비바이트) hugepage로 증가된 메모리 페이지 크기
- 멀티코어 프로세서 및 NUMA와 같은 시스템 아키텍처를 기반으로 하는 워크로드 배포
Performance Tuning Operator를 사용하면 성능 구성을 적용하는 Kubernetes 커스텀 리소스를 만들어 노드 수준의 성능 설정을 구성할 수 있습니다. 다음과 같은 이점이 있습니다.
단일 통합 구성 인터페이스: Performance Tuning Operator로 노드 선택기를 사용하여 워커 노드에 적용할 수 있는 하나 이상의
PerformanceTuningProfile매니페스트를 업데이트합니다. 여러 구성 및 정책 설정으로 각 노드를 개별적으로 구성할 필요가 없습니다. 이 접근 방식을 사용하면 노드 수준 및 컨테이너 수준 구성을 단일 통합 방법으로 관리할 수 있습니다.지속성 및 안정성: 또한 Kubernetes가 고가용성 아키텍처에서 제공하는 모든 안정성을 누릴 수 있습니다.
PerformanceTuningProfile커스텀 리소스는 언제든지 업데이트할 수 있으며 업그레이드와 같은 주요 클러스터 작업 전반에서 설정을 유지할 수 있습니다.
Performance Tuning Operator는 다음과 같은 성능 관련 Kubernetes 및 운영체제(OS) 기능 및 도구를 조정합니다.
충돌을 방지하기 위해 Performance Tuning Operator를 사용할 때는 앞서 언급한 Kubernetes 및 OS 도구와 기능을 독립적으로 사용하지 않는 것이 좋습니다.
전제 조건 및 제한사항
Performance Tuning Operator를 사용할 때의 기본 요건 및 제한사항은 다음과 같습니다.
Red Hat Enterprise Linux(RHEL)만 해당: Performance Tuning Operator는 지원되는 버전의 RHEL만 실행하는 노드에서 지원됩니다.
워커 노드가 있는 사용자 또는 하이브리드 클러스터: Performance Tuning Operator는 사용자 또는 하이브리드 클러스터의 워커 노드에서만 사용이 지원됩니다. Performance Tuning Operator를 사용하여 컨트롤 플레인 노드를 조정하는 것은 지원되지 않습니다. Performance Tuning Operator는 노드 선택기를 사용하여 조정 프로필을 적용하는 방법을 결정합니다. 조정 프로필이 워커 노드에만 적용되도록 하려면 각 프로필 커스텀 리소스의
nodeSelector에 표준 워커 노드 라벨node-role.kubernetes.io/worker: ""가 포함되어야 합니다. 조정 프로필의nodeSelector가 컨트롤 플레인 노드의 라벨과 일치하면 노드는 조정되지 않고 오류 조건이 설정됩니다. 오류 조건에 대한 자세한 내용은 상태 확인을 참조하세요. Performance Tuning Operator를 설치하고 조정 프로필을 적용하기 전에 클러스터가 올바르게 작동하는지 확인합니다.TuneD 2.22.0: Performance Tuning Operator를 사용하려면 조정하려는 워커 노드에 TuneD 버전 2.22.0이 사전 설치되어 있어야 합니다. 설치 안내를 포함한 TuneD에 대한 자세한 내용은 Red Hat Enterprise Linux 문서의 TuneD 시작하기를 참조하세요. Performance Tuning Operator는
cpu-partitioning프로필과 함께 TuneD를 사용합니다. 이 프로필이 없는 경우 다음 명령어를 사용하여 설치할 수 있습니다.dnf install -y tuned-profiles-cpu-partitioning워크로드 리소스 요구사항: 성능 조정을 최대한 활용하려면 워크로드에 대한 메모리 및 CPU 요구사항(리소스 요청 및 한도)을 잘 이해하고 있어야 합니다.
사용 가능한 노드 리소스: 노드의 CPU 및 메모리 리소스를 확인합니다. 노드의 자세한 CPU 및 메모리 정보는 각각
/proc/cpuinfo및/proc/meminfo파일에서 가져올 수 있습니다.kubectl get nodes를 사용하여 포드에 사용할 수 있는 워커 노드의 컴퓨팅 및 메모리 리소스 양(status.allocatable)도 가져올 수 있습니다.드레이닝 필요: 조정 프로세스 중에 Performance Tuning Operator는 먼저 노드를 드레이닝한 후 조정 프로필을 적용합니다. 따라서 성능 조정 중 노드에서
NotReady상태가 보고될 수 있습니다. 워크로드 비가용성을 최소화하려면 일괄 업데이트 대신 순차적 업데이트 전략(spec.updateStrategy.type: rolling)을 사용하는 것이 좋습니다.재부팅 필요: 노드 조정 변경사항을 적용하기 위해 Performance Tuning Operator가 조정 프로필을 적용한 후 노드를 재부팅합니다.
Performance Tuning Operator 설치
Performance Tuning Operator는 주로 프로필 설정을 기반으로 노드를 조정하기 위해 서로 상호작용하는 두 개의 컨트롤러(Deployment 및 DaemonSet)로 구성됩니다.
Performance Tuning Operator는 기본적으로 Google Distributed Cloud에 설치되지 않습니다. Cloud Storage에서 Performance Tuning Operator 매니페스트를 다운로드하고 kubectl apply를 사용하여 클러스터에 Performance Tuning Operator 리소스를 만듭니다.
클러스터에서 성능 조정을 기본값으로 사용 설정하려면 다음 안내를 따르세요.
관리자 워크스테이션에
performance-tuning디렉터리를 만듭니다.performance-tuning디렉터리의 Cloud Storage 출시 버킷에서 최신 Performance Tuning Operator 패키지를 다운로드합니다.gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive다운로드한 파일에는
performance-tuning-operatorDeployment 및nodeconfig-controller-managerDaemonSet의 매니페스트가 포함되어 있습니다. 역할 기반 액세스 제어(RBAC) 및 동적 허용 제어와 같은 관련 함수의 매니페스트도 포함됩니다.루트 사용자가 모든 Performance Tuning Operator 매니페스트를 사용자(또는 하이브리드) 클러스터에 재귀적으로 적용합니다.
kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIGDeployment 및 DaemonSet가 생성되어 실행된 이후의 유일한 상호작용은
PerformanceTuningProfile매니페스트를 수정하고 적용하는 것뿐입니다.
워크로드의 리소스 요구사항 검토
노드를 조정하려면 먼저 워크로드의 컴퓨팅 및 메모리 리소스 요구사항을 이해해야 합니다. 워커 노드에 리소스가 충분한 경우 보장된 서비스 품질(QoS) 클래스에서 워크로드에 보장된 메모리(표준 및 hugepage)를 제공하도록 노드를 조정할 수 있습니다.
Kubernetes는 연결된 컨테이너에 지정된 리소스 제약조건에 따라 각 포드에 QoS 클래스를 할당합니다. 그런 다음 Kubernetes는 QoS 클래스를 사용하여 포드 및 컨테이너를 예약하고 워크로드에 리소스를 할당하는 방법을 결정합니다. 워크로드에 대한 노드 조정을 최대한 활용하려면 워크로드에 CPU 또는 메모리 리소스 요청 또는 한도 설정이 있어야 합니다.
보장된 QoS 클래스가 할당되려면 포드에서 다음 요구사항을 충족해야 합니다.
- 포드의 각 컨테이너:
- 메모리 리소스 요청(
spec.containers[].resources.requests.memory) 및 한도(spec.containers[].resources.limits.memory)의 값을 모두 지정합니다. - 메모리 한도 값은 메모리 요청 값과 같아야 합니다.
- CPU 리소스 요청(
spec.containers[].resources.requests.cpu)과 한도(spec.containers[].resources.limits.cpu)의 값을 모두 지정합니다. - CPU 한도 값은 CPU 요청 값과 동일해야 합니다.
- 메모리 리소스 요청(
다음 포드 사양 예시는 보장된 QoS 클래스 요구사항을 충족하는 CPU 리소스 설정을 보여줍니다.
spec:
containers:
- name: sample-app
image: images.my-company.example/app:v4
resources:
requests:
memory: "128Mi"
cpu: "2"
limits:
memory: "128Mi"
cpu: "2"
...
kubectl get pods를 사용하여 포드 세부정보를 가져올 때 다음 예시와 같이 status 섹션에 할당된 QoS 클래스가 포함되어야 합니다.
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2023-09-22T21:05:23Z"
generateName: my-deployment-6fdd69987d-
labels:
app: metrics
department: sales
pod-template-hash: 6fdd69987d
name: my-deployment-6fdd69987d-7kv42
namespace: default
...
spec:
containers:
...
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2023-09-22T21:05:23Z"
status: "True"
type: Initialized
...
qosClass: BestEffort
startTime: "2023-09-22T21:05:23Z"
QoS 클래스에 대한 자세한 내용은 Kubernetes 문서의 포드 서비스 품질 클래스를 참조하세요. QoS 클래스가 할당되도록 포드와 컨테이너를 구성하는 방법은 포드 서비스 품질 구성을 참조하세요.
CPU 요구사항
노드를 조정할 때 kubelet 및 컨테이너 런타임과 같은 Kubernetes 시스템 데몬을 실행하기 위해 예약된 CPU 코어(spec.cpu.reservedCPUs) 집합을 지정할 수 있습니다. 이 동일한 예약된 CPU 집합에서 sshd 및 udev와 같은 운영체제 데몬을 실행합니다. 나머지 CPU 코어는 격리된 상태로 할당됩니다. 격리된 CPU는 다른 애플리케이션의 간섭이나 네트워크 또는 기타 기기의 중단 없이 전용 CPU 시간이 필요한 CPU의 제약을 받는 애플리케이션에 사용됩니다.
워커 노드의 격리된 CPU에서 포드를 예약하려면 다음 안내를 따르세요.
보장된 서비스 품질(QoS)을 위해 포드를 구성합니다.
CPU 요구사항 및 한도는 정수로 지정해야 합니다. 포드 사양에서
cpu: 0.5또는cpu: 250m(250 밀리코어)과 같은 부분 CPU 리소스를 지정하는 경우 예약을 보장할 수 없습니다.
메모리 요구사항
Performance Tuning Operator로 노드를 조정할 때 hugepage를 만들어 머신의 비균일 메모리 액세스(NUMA) 노드와 연결할 수 있습니다. 포드 및 노드 설정에 따라 포드는 NUMA 노드 어피니티를 사용하여 예약할 수 있습니다.
성능 조정 프로필 만들기
Performance Tuning Operator를 설치한 후 워크로드를 실행하는 클러스터와만 상호작용합니다. PerformanceTuningProfile 커스텀 리소스는 관리자 클러스터가 아닌 사용자 클러스터 또는 하이브리드 클러스터에서 직접 만듭니다. 각 PerformanceTuningProfile 리소스에는 노드에 적용되는 성능 구성을 지정하는 매개변수 집합이 포함되어 있습니다.
리소스의 nodeSelector에 따라 조정 프로필이 적용되는 노드가 결정됩니다. 노드에 프로필을 적용하려면 해당 키-값 쌍 라벨을 노드에 배치합니다. 조정 프로필은 nodeSelector 필드에 지정된 모든 라벨이 있는 노드에 적용됩니다.
한 클러스터에 여러 PerformanceTuningProfile 리소스를 만들 수 있습니다. 지정된 노드와 일치하는 프로필이 두 개 이상 있으면 PerformanceTuningProfile 커스텀 리소스의 status에 오류 조건이 설정됩니다. status 섹션에 대한 자세한 내용은 상태 확인을 참조하세요.
PerformanceTuningProfile 커스텀 리소스의 네임스페이스를 kube-system으로 설정합니다.
하나 이상의 워커 노드를 미세 조정하려면 다음 안내를 따르세요.
PerformanceTuningProfile매니페스트를 수정합니다.매니페스트의 각 필드에 대한 정보와 샘플 매니페스트는
PerformanceTuningProfile리소스 참조를 확인하세요.(선택사항) 프로필을 적용할 워커 노드에서
spec.nodeSelector키-값 쌍과 일치하는 라벨을 추가합니다.PerformanceTuningProfile커스텀 리소스에spec.nodeSelector키-값 쌍이 지정되지 않은 경우 모든 워커 노드에 프로필이 적용됩니다.클러스터에 매니페스트를 적용합니다.
kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG다음을 바꿉니다.
PROFILE_MANIFEST:PerformanceTuningProfile커스텀 리소스의 매니페스트 파일 경로KUBECONFIG: 클러스터 kubeconfig 파일 경로
조정 프로필 삭제
노드를 조정되지 않은 원래 상태로 재설정하려면 다음 안내를 따르세요.
클러스터에서
PerformanceTuningProfile커스텀 리소스를 삭제합니다.조정 프로필에서 노드가 선택되지 않도록 노드의 라벨을 다시 업데이트하거나 삭제합니다.
노드와 연결된 조정 프로필이 여러 개 있는 경우 필요에 따라 이전 단계를 반복합니다.
조정 프로필 일시중지
클러스터에서 유지보수를 수행해야 하는 경우 PerformanceTuningProfile 커스텀 리소스를 수정하여 조정을 일시적으로 중지할 수 있습니다. 클러스터 업그레이드와 같은 중요한 클러스터 작업을 수행하기 전에는 조정을 일시중지하는 것이 좋습니다.
실패한 프로필 적용 역시 조정을 일시중지할 수 있는 사례입니다. 조정 프로세스가 실패하면 컨트롤러가 계속 노드 조정을 시도하여 노드가 반복적으로 재부팅될 수 있습니다. 노드 상태가 준비됨 상태와 아직 준비되지 않음 상태 간에 전환되는 경우 손상된 상태에서 복구할 수 있도록 조정을 일시중지합니다.
조정을 일시중지하려면 다음 안내를 따르세요.
PerformanceTuningProfile커스텀 리소스 매니페스트를 수정하여spec.paused를true로 설정합니다.리소스를 업데이트하려면
kubectl apply을 사용합니다.
성능 조정이 일시중지되면 Performance Tuning Operator 컨트롤러가 모든 작업을 중지합니다. 일시중지하면 Performance Tuning Operator 컨트롤러 작업이 Google Distributed Cloud 컨트롤러 작업과 충돌할 위험이 없습니다.
PerformanceTuningProfile 리소스 참조
이 섹션에서는 PerformanceTuningProfile 커스텀 리소스의 각 필드를 설명합니다. 이 리소스는 하나 이상의 클러스터 노드에 대한 조정 프로필을 생성하는 데 사용됩니다. 리소스의 모든 필드는 프로필을 만든 후에 변경할 수 있습니다. 프로필은 kube-system 네임스페이스에 있어야 합니다.
CPU 코어가 8개 있는 노드에 대한 다음 numa 샘플 프로필 매니페스트는 다음 리소스 할당을 지정합니다.
4개의 CPU 코어(
0-3)가 Kubernetes 시스템 오버헤드에 예약됩니다.4개의 CPU 코어(
4-7)는 워크로드 전용으로 확보됩니다.노드 메모리는 기본적으로 표준 4‐Ki 페이지 대신 2-MiB 페이지로 분할됩니다.
크기가 1GiB인 메모리 10페이지가 NUMA 노드 0에서 사용하도록 확보됩니다.
크기가 2MiB인 메모리 5페이지는 NUMA 노드 1에서 사용하도록 확보됩니다.
토폴로지 관리자는 워크로드 예약을 위해 최선의 정책을 사용합니다.
apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
name: numa
namespace: kube-system
spec:
cpu:
isolatedCPUs: 4-7
reservedCPUs: 0-3
defaultHugepagesSize: 2M
nodeSelector:
app: database
node-role.kubernetes.io/worker: ""
pages:
- count: 10
numaNode: 0
size: 1G
- count: 5
numaNode: 1
size: 2M
topologyManagerPolicy: best-effort
클러스터의 anthos.gke.io 그룹에서 관련 PerformanceTuningProfile 커스텀 리소스 정의를 가져올 수 있습니다. 커스텀 리소스 정의는 미리보기 기능 주석이 자체 관리형 클러스터 리소스에 추가되면 설치됩니다.
CPU 구성
| 속성 | 설명 |
|---|---|
cpu.reservedCPUs |
필수 항목. 변경 가능합니다. 문자열. 이 필드는 kubelet, 컨테이너 런타임, 노드 문제 감지기와 같이 Kubernetes 시스템 데몬을 위해 예약할 CPU 코어 집합을 정의합니다. 이러한 CPU 코어는 sshd 및 udev와 같은 운영체제(OS) 시스템 데몬에도 사용됩니다.
|
cpu.isolatedCPUs |
선택사항. 변경 가능합니다. 문자열. cpu.isolatedCPUs 필드는 성능에 민감한 애플리케이션에만 사용되는 CPU 집합을 정의합니다. CPU 관리자가 Kubernetes 서비스 품질(QoS) 클래스에 따라 예약되지 않은 CPU에서만 컨테이너를 예약합니다.
격리된 CPU에서 워크로드를 실행하려면 보장된 QoS 클래스로 포드를 구성하고 포드 또는 컨테이너에 CPU 리소스를 할당합니다.
보장된 포드를 예약하기 위해서는 부분 CPU 리소스(cpu: "0.5")가 아닌 정수 CPU 단위를 지정해야 합니다.
apiVersion: v1 kind: Pod ... spec: containers: ... resources: limits: cpu: "1" requests: cpu: "1" ... 격리된 CPU를 워크로드에 맞춰 극대화하면 최고의 성능상 이점을 얻을 수 있습니다. 이 필드는 CPU 번호 목록 또는 CPU 번호 범위를 사용합니다.
CPU 목록이 |
cpu.balanceIsolated |
선택사항. 변경 가능합니다. 부울. 기본값: true 이 필드는 격리된 CPU 집합이 CPU에서의 워크로드 자동 부하 분산에 적합한지 여부를 지정합니다. 이 필드를 false로 설정하면 워크로드가 CPU 간에 부하를 분산하도록 특정 CPU에 각 스레드를 명시적으로 할당해야 합니다. 명시적인 CPU 할당을 사용하면 보장된 워크로드에 대해 가장 예측 가능한 성능을 얻을 수 있지만, 워크로드가 더 복잡해집니다. |
cpu.globallyEnableIRQLoadBalancing |
필수 항목. 변경 가능합니다. 부울. 기본값: true 이 필드는 격리된 CPU 집합에 대해 중단 요청(IRQ) 부하 분산을 사용 설정할지 여부를 지정합니다. |
메모리 구성
| 속성 | 설명 |
|---|---|
defaultHugePageSize |
선택사항. 변경 가능합니다. 열거: 1G 또는 2M입니다.
이 필드는 커널 부팅 매개변수의 기본 hugepage 크기를 정의합니다.
hugepage는 메모리가 파편화되기 전 부팅 시에 할당됩니다.
hugepage 기본 크기를 1G로 설정하면 노드에서 2M 관련 폴더가 모두 삭제된다는 점에 유의해야 합니다. 기본 hugepage 크기가 1G이면 노드에서 2M hugepage를 구성할 수 없습니다.
|
pages |
선택사항. 변경 가능합니다. 정수. 이 필드는 부팅 시 만들 hugepage 수를 지정합니다. 이 필드에는 페이지 배열이 허용됩니다. hugepage를 지정하기 전에 노드에 사용 가능한 메모리를 확인하세요. hugepage를 필요 이상으로 요청하지 말고 hugepage에 모든 메모리를 예약하지 마세요. 워크로드에도 표준 메모리가 필요합니다. |
노드 선택
| 속성 | 설명 |
|---|---|
nodeSelector |
필수 항목. 변경 가능합니다. 이 필드에는 항상 Kubernetes 워커 노드 라벨인 node-role.kubernetes.io/worker:""가 필요합니다. 이를 통해 워커 노드에서만 성능 조정이 수행됩니다. 이 필드는 선택적 노드 라벨을 키-값 쌍으로 사용합니다. 키-값 쌍 라벨은 라벨이 일치하는 특정 워커 노드를 선택하는 데 사용됩니다. nodeSelector 라벨이 워커 노드의 라벨과 일치하면 성능 프로필이 해당 노드에 적용됩니다. 프로필에 키-값 라벨을 지정하지 않으면 클러스터의 모든 워커 노드에 적용됩니다.
예를 들어 다음 ... spec: nodeSelector: app: database node-role.kubernetes.io/worker: "" ... |
Kubelet 구성
| 속성 | 설명 |
|---|---|
topologyManagerPolicy |
선택사항. 변경 가능합니다. 열거: none, best-effort, restricted 또는 single-numa-node입니다. 기본값: best-effort
이 필드는 할당된 서비스 품질(QoS) 클래스를 기준으로 워크로드에 리소스를 할당하는 데 사용되는 Kubernetes 토폴로지 관리자 정책을 지정합니다. QoS 클래스가 할당되는 방법에 대한 자세한 내용은 포드 서비스 품질 구성을 참조하세요.
|
프로필 작업
| 속성 | 설명 |
|---|---|
paused |
선택사항. 변경 가능합니다. 부울. paused를 true로 설정하여 DaemonSet 컨트롤러가 선택한 노드를 일시적으로 조정하지 못하게 합니다. |
updateStrategy |
선택사항. 변경 가능합니다. 선택한 노드에 조정 구성 변경사항을 적용하기 위한 전략을 지정합니다. |
updateStrategy.rollingUpdateMaxUnavailalble |
선택사항. 변경 가능합니다. 정수. 기본값: 1 동시에 조정할 수 있는 최대 노드 수를 지정합니다. 이 필드는 type이 rolling으로 설정된 경우에만 적용됩니다. |
updateStrategy.type |
선택사항. 변경 가능합니다. 열거: batch 또는 rolling입니다.
기본값: rolling 선택한 노드에 프로필 업데이트를 적용하는 방법을 지정합니다. 선택한 모든 노드에 업데이트를 동시에 적용하려면 type을 batch로 설정합니다. 기본적으로 업데이트는 개별 노드에 한 번에 하나씩 순차적으로 출시됩니다. |
상태 확인
PerformanceTuningProfile 커스텀 리소스가 생성되거나 업데이트된 후 컨트롤러가 리소스에 제공된 구성에 따라 선택된 노드를 조정합니다. PerformanceTuningProfile의 상태를 확인하기 위해 Status에 다음 필드가 노출됩니다.
| 속성 | 설명 |
|---|---|
conditions |
조건은 프로필 리소스의 현재 상태에 대한 최근 관찰 결과를 나타냅니다. |
conditions.lastTransitionTime |
항상 반환됩니다. 문자열(날짜-시간 형식)입니다. 조건이 특정 상태에서 다른 상태로 전환된 마지막 시간입니다. 이 시간은 일반적으로 기본 조건이 변경된 시점을 나타냅니다. 이 시간을 알 수 없는 경우에는 시간이 API 필드가 변경된 시점을 나타냅니다. |
conditions.message |
선택사항. 문자열. 전환에 대한 세부정보를 나타내는 인간이 읽을 수 있는 메시지입니다. 이 필드는 비어 있을 수 있습니다. |
conditions.observedGeneration |
선택사항. 정수. 설정된 경우 이 필드는 조건이 설정된 기준인 metadata.generation을 나타냅니다. 예를 들어 metadata.generation이 12이지만 status.condition[x].observedGeneration이 9이면 인스턴스의 현재 상태와 관련된 조건이 최신이 아닙니다. |
conditions.reason |
필수 항목. 문자열. 마지막 조건 전환의 이유입니다. |
conditions.status |
필수 항목. 조건의 상태: True, False 또는 Unknown입니다. |
conditions.type |
필수 항목. Type은 Stalled 또는 Reconciling 조건 유형입니다. |
readyNodes |
조정 프로필이 성공적으로 적용된 노드 수입니다. |
reconcilingNodes |
nodeconfig-controller-manager DaemonSet에서 최신 조정 프로필로 조정 중인 선택한(또는 이전에 선택한) 노드 수입니다. |
selectedNodes |
선택된 노드 수입니다. 즉, 이 PerformanceTuningProfile 커스텀 리소스의 노드 선택기와 일치하는 노드 수입니다. |