AI 워크로드
OpenShift 컨테이너 플랫폼에서 AI 워크로드 실행
초록
1장. OpenShift Container Platform의 AI 워크로드 개요 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 훈련, 추론 및 데이터 과학 워크플로우 전반에서 인공 지능(AI) 워크로드를 실행하기 위한 안전하고 확장 가능한 기반을 제공합니다.
1.1. AI 워크로드를 실행하기 위한 연산자 링크 복사링크가 클립보드에 복사되었습니다!
Operator를 사용하면 OpenShift Container Platform에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행할 수 있습니다. Operators를 사용하면 OpenShift Container Platform을 애플리케이션의 핵심 플랫폼으로 계속 사용하면서 특정 AI/ML 요구 사항을 충족하는 맞춤형 환경을 구축할 수 있습니다.
OpenShift Container Platform은 AI 워크로드를 실행하는 데 도움이 되는 여러 연산자를 제공합니다.
- Kueue의 Red Hat 빌드
Kueue의 Red Hat 빌드를 사용하면 구조화된 대기열과 우선순위를 제공하여 작업 부하가 공정하고 효율적으로 처리되도록 할 수 있습니다. 적절한 우선순위가 없다면 중요한 작업은 지연되고, 덜 중요한 작업은 리소스를 차지하게 될 수 있습니다.
자세한 내용은 "Kueue의 Red Hat 빌드 소개"를 참조하세요.
- 리더 작업자 세트 운영자
Leader Worker Set Operator를 사용하면 리더와 워커 프로세스 간의 동기화를 통해 대규모 AI 추론 워크로드를 여러 노드에서 안정적으로 실행할 수 있습니다. 적절한 조정이 없다면 대규모 훈련이 실패하거나 중단될 수 있습니다.
자세한 내용은 "리더 워커 세트 연산자 개요"를 참조하세요.
2장. Kueue의 Red Hat 빌드 링크 복사링크가 클립보드에 복사되었습니다!
2.1. Kueue의 Red Hat 빌드 소개 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드는 작업에 대한 리소스 액세스를 관리하는 Kubernetes 기반 시스템입니다. Kueue의 Red Hat 빌드는 작업이 대기하는 시점, Pod를 생성하여 시작하도록 허용되는 시점, 또는 해당 작업에 대한 활성 Pod가 삭제되는 것을 의미하는 선점 되어야 하는 시점을 결정할 수 있습니다.
Kueue의 Red Hat 빌드 컨텍스트에서 작업은 완료될 때까지 실행되는 일회성 또는 주문형 작업으로 정의할 수 있습니다.
Kueue의 Red Hat 빌드는 Kueue 오픈 소스 프로젝트를 기반으로 합니다.
Kueue의 Red Hat 빌드는 이기종의 탄력적 리소스를 사용하는 환경과 호환됩니다. 즉, 환경에는 다양한 리소스 유형이 있으며, 이러한 리소스는 동적으로 확장될 수 있습니다.
Kueue의 Red Hat 빌드는 Kubernetes 클러스터의 기존 구성 요소를 대체하지 않고 대신 기존 Kubernetes API 서버, 스케줄러 및 클러스터 자동 확장 구성 요소와 통합됩니다.
Kueue의 Red Hat 빌드는 전부 또는 전무 의미론을 지원합니다. 즉, 모든 구성 요소를 갖춘 전체 작업이 클러스터에 허용되거나, 클러스터에 맞지 않으면 전체 작업이 거부됩니다.
2.1.1. 가상 사용자 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 워크플로의 Red Hat 빌드에는 다양한 페르소나가 존재합니다.
- 배치 관리자
- 배치 관리자는 클러스터 인프라를 관리하고 할당량과 대기열을 설정합니다.
- 배치 사용자
- 배치 사용자는 클러스터에서 작업을 실행합니다. 일괄 사용자의 예로는 연구자, AI/ML 엔지니어, 데이터 과학자 등이 있습니다.
- 사용자에게 서비스 제공
- 서비스 제공자는 클러스터에서 작업을 실행합니다. 예를 들어, 추론을 위해 훈련된 AI/ML 모델을 공개하는 것입니다.
- 플랫폼 개발자
- 플랫폼 개발자는 Kueue의 Red Hat 빌드를 다른 소프트웨어와 통합합니다. 그들은 또한 Kueue 오픈 소스 프로젝트에 기여할 수도 있습니다.
2.1.2. 워크플로 개요 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 워크플로의 Red Hat 빌드는 다음과 같이 개략적으로 설명할 수 있습니다.
-
배치 관리자는
ResourceFlavor,LocalQueue,ClusterQueue리소스를 생성하고 구성합니다. - 사용자 페르소나는 클러스터에서 작업을 생성합니다.
- Kubernetes API 서버는 작업 데이터를 검증하고 수락합니다.
-
Kueue의 Red Hat 빌드는 주문이나 할당량과 같은 구성된 옵션에 따라 작업을 허용합니다. 리소스 플레이버를 사용하여 작업에 친화성을 주입하고 각 작업에 해당하는
Workload객체를 생성합니다. - 해당 작업 유형에 적용되는 컨트롤러가 포드를 생성합니다.
- Kubernetes 스케줄러는 클러스터의 노드에 포드를 할당합니다.
- Kubernetes 클러스터 자동 확장기는 필요에 따라 더 많은 노드를 프로비저닝합니다.
2.2. 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드는 OpenShift Container Platform에서 지원되는 Operator로 출시되었습니다.
2.2.1. 호환 환경 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드를 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인하세요.
2.2.1.1. 지원되는 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 아키텍처에서 지원됩니다.
- ARM64
- 64-bit x86
- ppc64le(IBM Power®)
- s390x (IBM Z®)
2.2.1.2. 지원 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 플랫폼에서 지원됩니다.
- OpenShift Container Platform
- OpenShift Container Platform에서 호스팅되는 컨트롤 플레인
현재 Kueue의 Red Hat 빌드는 MicroShift(MicroShift)의 Red Hat 빌드에서 지원되지 않습니다.
2.2.2. Red Hat build of Kueue 버전 1.3.1 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat build of Kueue 버전 1.3.1은 OpenShift Container Platform 버전 4.18 이상에서 지원되는 일반적으로 사용 가능한 릴리스입니다. Red Hat build of Kue version 1.3은 Kue 버전 0.16.5를 사용합니다.
2.2.2.1. 해결된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- kue.x-k8s.io/queue-name은 존재하지 않는 큐를 나타냅니다.
kue.x-k8s.io/queue-name을 통해 존재하지 않는 LocalQueue를참조하는 버그를 수정하면 실행 중인 Pod가 종료되고 불가능한 스케줄링 게이트로 영구적으로 고정될 수 있습니다.
2.2.3. Red Hat build of Kue 버전 1.3 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat build of Kue version 1.3은 OpenShift Container Platform 버전 4.18 이상에서 지원되는 일반적으로 사용 가능한 릴리스입니다. Red Hat build of Kue version 1.3은 Kue 버전 0.16을 사용합니다.
2.2.3.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 리더 작업자 세트 운영자
- Red Hat build of Kueue 버전 1.3은 Leader Worker Set Operator와 Kueue의 Red Hat build of Kueue를 통합할 수 있도록 LeaderWorkerSets를 실행할 때 Kueue 스케줄링 및 리소스 관리 기능을 활용할 수 있습니다. 자세한 내용은 Leader Worker Set Operator 통합을 참조하십시오.
- JobSet Operator
- Red Hat build of Kueue 버전 1.3은 JobSet Operator를 통합하므로 JobSet Operator를 사용하여 HPC(고성 컴퓨팅) 및 AI 교육과 같은 대규모 조정된 워크로드를 관리하고 실행할 수 있습니다. 자세한 내용은 JobSet Operator 통합을 참조하십시오.
- Kueue API의 Red Hat 빌드 업스트림 진행에서
v1beta2로 진행 Red Hat build of Kueue 버전 1.3은 Red Hat build of Kueue API의
v1beta2버전을 제공합니다. 이번 업데이트에서는 API를v1로 업그레이드하는 최종 목표로 Kueue API의 Red Hat 빌드의 진화를 계속하고 있습니다.업그레이드 후 생성된 모든 새 Kueue 오브젝트는
v1beta2버전을 사용하여 저장됩니다. 이전 버전의 API,v1beta1은 더 이상 사용되지 않습니다. 필요한 경우v1beta1을 사용하여 오브젝트를 생성할 수 있습니다. 이러한 경우에는 사용 중단 메시지가 표시됩니다.그러나 기존 오브젝트는 쓰기 요청 중에 Kubernetes가 새 스토리지 버전으로 자동 해석됩니다. 즉, Red Hat build of Kueue API 오브젝트는 Topologies, ResourceFlavors 또는 장기 실행 워크로드와 같은 업데이트를 거의 받지 못하며 이전
v1beta1형식으로 무기한 유지될 수 있습니다.
2.2.3.2. 해결된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- 옵트인 네임스페이스에서만 작업 조정
OpenShift Container Platform을 사용하면 OpenShift Container Platform에서 관리하도록 구성되지 않은 네임스페이스에 있는
kue.x-k8s.io/queue-name레이블이 있는작업리소스를 조정할 수 있습니다. 이번 릴리스에서는 네임스페이스가managedJobsNamespaceSelector와 일치하지 않는 한 queue-name 라벨이 있는 작업도 무시되도록 이 동작을 업데이트하는 업스트림 작업이 진행 중입니다. 이러한 변경으로 인해 모든 통합에서 Red Hat의 Kueue 동작이 일관되게 유지됩니다.- OpenShift Container Platform 웹 콘솔에서
KueueCR 설명이 "사용할 수 없음"으로 표시됩니다. Kueue의 Red Hat 빌드를 설치한 후 Operator 세부 정보 뷰에서
KueueCR에 대한 설명은 "사용할 수 없음"으로 표시됩니다. 이 문제는 Kueue Operator 기능의 Red Hat 빌드에 영향을 미치거나 저하되지 않았습니다. 이번 릴리스에서는 "사용할 수 없음" 메시지가 더 이상 표시되지 않습니다.- LeaderWorkerSet 및 Jobset 검증 오류
현재 Leader Worker Set Operator 및 JobSet Operator는 Operand CR이 업데이트되고 전체 Kue 계층 구조(ResourceFlavor, ClusterQueue 및 LocalQueue)가 설정된 경우에만 검증됩니다. 모든 구성 오류는 LeaderWorkerSet 또는 JobSet 템플릿을 적용할 때만 표시됩니다.
2.2.3.3. 확인된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- LeaderWorkerSet Pod는 기본적으로 순차적으로 업데이트
Leader Worker Set Operator가 Kue 설치의 Red Hat 빌드와 통합되고 LeaderWorkerSet Pod 업데이트에 대한 롤아웃 전략 옵션을 사용하는 경우 OpenShift Container Platform의
MaxUnavailable기능 게이트가 기본적으로 비활성화되어 있음을 유의하십시오.LeaderWorkerSet Pod를 변경하면 롤링 업데이트가 트리거됩니다. 이 작업은 배포의 이전 Pod를 새 Pod로 점진적으로 교체하여 다운타임을 방지하기 위해 최대한 많은 Pod를 활성 상태로 유지합니다. OpenShift Container Platform 기본 설정인
MaxUnavailable이 비활성화되어 있는 경우 Pod가 한 번에 하나씩 업데이트됩니다.업데이트를 순차적으로 실행하는 대신 병렬로 업데이트를 실행하려면
MaxUnavailable기능 게이트를 활성화해야 합니다. 자세한 내용은 설치 및 롤아웃 전략에서 기능 세트 활성화를 참조하십시오.
2.2.4. Red Hat build of Kueue 버전 1.2 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat build of Kue version 1.2는 OpenShift Container Platform 버전 4.18 이상에서 지원되는 일반적으로 사용 가능한 릴리스입니다. Red Hat build of Kue version 1.2에서는 Kue 버전 0.14를 사용합니다.
2.2.4.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 보류 중인 워크로드 모니터링
-
Red Hat build of Kue version 1.2에서는 클러스터 대기열과 로컬 대기열에서 보류 중인 작업의 파이프라인을 모니터링하고 사용자가 작업 시작 시기를 추정할 수 있는
VisibilityOnDemand기능을 제공합니다. 자세한 내용은 보류 중인 워크로드 모니터링 을 참조하십시오.
2.2.4.2. 해결된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- Kueue의 Red Hat 빌드를 제거하면 사용자 정의 리소스가 제대로 삭제되지 않습니다.
OpenShift Container Platform 웹 콘솔에서 이 Operator 옵션에 대해 모든 피연산자 인스턴스 삭제 를 사용하여 Red Hat Build of Kueue Operator를 설치 제거한 후 Kueue 사용자 정의 리소스의 Red Hat 빌드가 삭제되었습니다. 이번 릴리스에서는 삭제로 간주되지 않습니다.
- 이전 버전의 Red Hat build of Kueue의 문서 오류
Kueue 사용자 정의 리소스 생성 에서 선택적 워크로드 유형
Pod,Deployment,StatefulSet이 생략되었습니다. 이제 포함되어 있습니다.- Red Hat build of Kueue 지표는 버전 1.1에서 Prometheus에 노출되지 않았습니다.
ServiceMonitor 및 RBAC 리소스가 Operator 설치의 일부로 성공적으로 생성된 경우에도 Prometheus가 Operator 컨트롤러에서 메트릭을 스크랩하지 않았습니다. 이로 인해 클러스터 모니터링 스택에서 Kueue 메트릭을 사용할 수 없었습니다.
설치 중에 추가된 지표 서비스는 잘못된 포트 참조로 구성되었으므로 Prometheus가 Kueue 끝점에서 메트릭을 스크랩하지 못합니다. 포트 이름이 올바른 포트 이름으로 업데이트되었습니다.
2.2.4.3. 확인된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- 옵트인 네임스페이스에서만 작업 조정
OpenShift Container Platform을 사용하면 OpenShift Container Platform에서 관리하도록 구성되지 않은 네임스페이스에 이러한 리소스가 있는
kue.x-k8s.io/queue-name레이블이 있는작업리소스를 조정할 수 있습니다. 이는 Pod, 배포 및 상태 저장 세트와 같은 기타 코어 통합 동작과 일치하지 않으며kueue.openshift.io/managed=true를 추가하여 OpenShift Container Platform에서 관리하도록 구성된 네임스페이스에 있는 경우에만 조정됩니다.- OpenShift Container Platform 웹 콘솔에서
KueueCR 설명이 "사용할 수 없음"으로 표시됩니다. Red Hat build of Kueue를 설치한 후 Operator 세부 정보 뷰에서
KueueCR에 대한 설명은 "사용할 수 없음"으로 표시됩니다. 이 문제는 Kueue Operator의 Red Hat 빌드에 영향을 미치거나 기능을 저하시키지 않습니다.
2.2.5. Kueue 버전 1.1의 Red Hat 빌드에 대한 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1의 Red Hat 빌드는 OpenShift Container Platform 버전 4.18 이상에서 지원되는 일반적으로 사용 가능한 릴리스입니다. Kueue 버전 1.1의 Red Hat 빌드는 Kueue 버전 0.12를 사용합니다.
클러스터에 이전에 설치된 Kueue의 Red Hat 빌드 버전이 있는 경우 Operator를 제거하고 수동으로 버전 1.1을 설치해야 합니다. 자세한 내용은 Kueue의 Red Hat 빌드 업그레이드를 참조하세요.
2.2.5.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 기본 로컬 대기열 구성
기본 로컬 대기열은
kueue.x-k8s.io/queue-name라벨이 없는 새로 생성된 작업에 대한 로컬 대기열 역할을 합니다. 기본 로컬 대기열을 생성한 후kueue.x-k8s.io/queue-name레이블이 없는 네임스페이스에서 생성된 모든 새 작업은 자동으로kueue.x-k8s.io/queue-name: 기본레이블을 갖도록 업데이트됩니다.(RFE-7615)
- 다중 아키텍처 및 호스팅 제어 평면 지원
이번 릴리스를 통해 Kueue의 Red Hat 빌드는 ARM64, 64비트 x86, ppc64le(IBM Power®), s390x(IBM Z®)를 비롯한 여러 아키텍처에서 지원되며, OpenShift Container Platform의 호스팅 제어 평면에서도 지원됩니다.
2.2.5.2. 해결된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- OpenShift Container Platform 웹 콘솔을 사용하여
Kueue사용자 정의 리소스를 만들 수 있습니다. 이 업데이트 이전에는 OpenShift Container Platform 웹 콘솔에서 폼 뷰를 사용하여
Kueue사용자 정의 리소스(CR)를 생성하려고 하면 웹 콘솔에 오류가 표시되고 리소스를 생성할 수 없습니다. 이 릴리스에서는KueueCR 템플릿에서 기본 네임스페이스가 제거되었습니다. 결과적으로 OpenShift Container Platform 웹 콘솔을 사용하여 양식 보기를 사용하여KueueCR을 만들 수 있습니다.
2.2.5.3. 확인된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- OpenShift Container Platform 웹 콘솔에서
KueueCR 설명이 "사용할 수 없음"으로 표시됩니다. Kueue의 Red Hat 빌드를 설치한 후, 운영자 세부 정보 보기에서
KueueCR에 대한 설명이 "사용할 수 없음"으로 표시됩니다. 이 문제는 Kueue Operator의 Red Hat 빌드에 영향을 미치거나 기능을 저하시키지 않습니다.- Kueue의 Red Hat 빌드를 제거하면 사용자 정의 리소스가 제대로 삭제되지 않습니다.
OpenShift Container Platform 웹 콘솔에서 '이 연산자의 모든 피연산자 인스턴스 삭제' 옵션을 사용하여 Kueue Operator의 Red Hat 빌드를 제거한 후에도 일부 Kueue 사용자 지정 리소스의 Red Hat 빌드가 완전히 삭제되지 않습니다. 이러한 리소스는 설치된 운영자 보기에서 리소스가 삭제되고 있음 상태로 볼 수 있습니다. 해결 방법으로, 리소스 종료자를 수동으로 삭제하여 완전히 제거할 수 있습니다.
2.2.6. Kueue 버전 1.0.1의 Red Hat 빌드에 대한 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.0.1의 Red Hat 빌드는 64비트 x86 아키텍처에서 OpenShift Container Platform 버전 4.18 및 4.19를 지원하는 패치 릴리스입니다.
Kueue 버전 1.0.1의 Red Hat 빌드는 Kueue 버전 0.11을 사용합니다.
2.2.6.1. Kueue 버전 1.0.1의 Red Hat 빌드 버그 수정 링크 복사링크가 클립보드에 복사되었습니다!
- 이전에는 Kueue의 Red Hat 빌드에 대한 리더 선거가 중단을 허용하도록 구성되지 않아 잦은 충돌이 발생했습니다. 이번 릴리스에서는 Kueue의 Red Hat 빌드에 대한 리더 선거 값이 OpenShift Container Platform에 권장되는 기간과 일치하도록 업데이트되었습니다. (OCPBUGS-58496)
-
이전에는
ReadyReplicas수가 조정자에 설정되지 않았기 때문에 Kueue Operator 상태의 Red Hat 빌드에서는 준비된 복제본이 없다고 보고했습니다. 이 릴리스에서는ReadyReplicas수가 배포에 대한 준비된 복제본 수를 기준으로 하며, 이를 통해kueue-controller-manager포드가 준비되면 OpenShift Container Platform 콘솔에서 Operator가 준비됨으로 표시됩니다. (OCPBUGS-59261) -
이전에는
Kueue사용자 정의 리소스(CR)가openshift-kueue-operator네임스페이스에서 삭제되었을 때kueue-manager-config구성 맵이 자동으로 삭제되지 않고 네임스페이스에 남아 있을 수 있었습니다. 이 릴리스에서는KueueCR이 삭제되면kueue-manager-config구성 맵,kueue-webhook-server-cert비밀,metrics-server-cert비밀이 자동으로 삭제됩니다. (OCPBUGS-62913)
2.2.7. Kueue 버전 1.0의 Red Hat 빌드에 대한 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.0의 Red Hat 빌드는 64비트 x86 아키텍처의 OpenShift Container Platform 버전 4.18 및 4.19에서 지원되는 일반적으로 사용 가능한 릴리스입니다. Kueue 버전 1.0의 Red Hat 빌드는 Kueue 버전 0.11을 사용합니다.
2.2.7.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- RBAC(역할 기반 액세스 제어)
- 역할 기반 액세스 제어(RBAC)를 사용하면 어떤 유형의 사용자가 어떤 유형의 Kueue 리소스의 Red Hat 빌드를 생성할 수 있는지 제어할 수 있습니다.
- 리소스 할당량 구성
- 클러스터 대기열, 리소스 플레이버, 로컬 대기열을 생성하여 리소스 할당량을 구성하면 사용자가 제출한 작업과 워크로드에서 사용하는 리소스 양을 제어할 수 있습니다.
- 작업 및 작업량 관리 제어
- 네임스페이스에 레이블을 지정하고 레이블 정책을 구성하면 Kueue의 Red Hat 빌드에서 어떤 작업과 워크로드를 관리할지 제어할 수 있습니다.
- 대기열 간에 대여 가능한 리소스 공유
- 코호트 구성, 공정한 공유, 갱 일정 설정을 통해 대기열 간에 사용되지 않는 대여 가능한 리소스를 공유할 수 있습니다.
2.2.7.2. 확인된 문제 링크 복사링크가 클립보드에 복사되었습니다!
- 모든 네임스페이스의 작업은
kueue.x-k8s.io/queue-name레이블이 있는 경우 조정됩니다. Kueue의 Red Hat 빌드는
managedJobsNamespaceSelector구성 필드를 사용하므로 관리자는 Kueue의 Red Hat 빌드에서 관리할 네임스페이스를 구성할 수 있습니다. Kueue의 Red Hat 빌드에서 관리되도록 네임스페이스를 수동으로 구성해야 하므로 시스템이나 타사 네임스페이스의 리소스는 Kueue의 Red Hat 빌드에서 영향을 받거나 관리되지 않습니다.Kueue 1.0의 Red Hat 빌드에서의 동작은 Kueue의 Red Hat 빌드에서 관리되도록 구성되지 않은 네임스페이스에 있는 리소스라도
kueue.x-k8s.io/queue-name레이블이 있는작업리소스를 조정할 수 있도록 합니다. 이는 포드, 배포, 상태 저장 세트와 같은 다른 핵심 통합의 동작과 일치하지 않습니다. 이러한 통합은 Kueue의 Red Hat 빌드에서 관리되도록 구성된 네임스페이스에 있는 경우에만 조정됩니다.- OpenShift Container Platform 웹 콘솔을 사용하여
Kueue사용자 정의 리소스를 생성할 수 없습니다. OpenShift Container Platform 웹 콘솔에서 양식 보기를 사용하여
Kueue사용자 정의 리소스(CR)를 생성하려고 하면 웹 콘솔에 오류가 표시되고 리소스를 생성할 수 없습니다. 해결 방법으로 YAML 뷰를 사용하여KueueCR을 대신 생성하세요.
2.3. Kueue의 Red Hat 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
OperatorHub에서 Kueue Operator의 Red Hat 빌드를 사용하여 Kueue의 Red Hat 빌드를 설치할 수 있습니다.
2.3.1. 호환 환경 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드를 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인하세요.
2.3.1.1. 지원되는 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 아키텍처에서 지원됩니다.
- ARM64
- 64-bit x86
- ppc64le(IBM Power®)
- s390x (IBM Z®)
2.3.1.2. 지원 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 플랫폼에서 지원됩니다.
- OpenShift Container Platform
- OpenShift Container Platform에서 호스팅되는 컨트롤 플레인
현재 Kueue의 Red Hat 빌드는 MicroShift(MicroShift)의 Red Hat 빌드에서 지원되지 않습니다.
2.3.2. Kueue Operator의 Red Hat 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔의 OperatorHub를 사용하여 OpenShift Container Platform 클러스터에 Kueue Operator의 Red Hat 빌드를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 대한 관리자 권한이 있습니다.
- OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- 클러스터에 Red Hat OpenShift용 cert-manager Operator를 설치하고 구성했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Kueue Operator의 Red Hat 빌드를 선택하고 설치를 클릭합니다.
이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.
이 옵션은 네임스페이스 오브젝트에서
openshift.io/cluster-monitoring: "true"레이블을 설정합니다. 클러스터 모니터링이openshift-kueue-operator네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.설치를 클릭합니다.
참고또는 YAML을 사용하여
Namespace오브젝트를 생성하는 경우openshift.io/cluster-monitoring: "true"라벨을 포함해야 합니다.+
apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-kueue-operator
검증
- Operators → Installed Operators 로 이동하여 Kueue Operator의 Red Hat 빌드가 Succeeded 상태 로 나열되어 있는지 확인합니다.
2.3.3. Kueue의 Red Hat 빌드 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
이전에 Kueue의 Red Hat 빌드를 설치한 경우 최신 버그 수정 및 기능 향상을 사용하려면 배포를 최신 버전으로 수동으로 업그레이드해야 합니다.
사전 요구 사항
- Kueue의 Red Hat 빌드의 이전 버전을 설치했습니다.
- 클러스터 관리자 권한으로 OpenShift Container Platform 웹 콘솔에 로그인했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 운영자 → 설치된 운영자를 클릭한 다음 목록에서 Kueue의 Red Hat 빌드를 선택합니다.
- 작업 드롭다운 메뉴에서 Operator 제거를 선택합니다.
Operator를 제거하시겠습니까? 대화 상자가 열립니다. 제거를 클릭합니다.
중요제거를 클릭하기 전에 이 연산자에 대한 모든 피연산자 인스턴스 삭제 확인란을 선택하면 다음을 포함하여 클러스터에서 모든 기존 리소스가 삭제됩니다.
-
쿠에우에CR - 사용자가 생성한 모든 클러스터 대기열, 로컬 대기열 또는 리소스 플레이버
생성된 리소스를 유지하려면 클러스터를 업그레이드할 때 이 상자를 선택하지 마세요.
-
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Kueue Operator의 Red Hat 빌드를 선택하고 설치를 클릭합니다.
검증
- Operator → 설치된 Operator 로 이동합니다.
- Kueue Operator의 Red Hat 빌드가 '성공' 상태 로 나열되어 있는지 확인하세요.
- 목록에서 운영자 이름 아래에 표시된 버전이 최신 버전인지 확인하세요.
2.3.4. Kueue 사용자 정의 리소스 만들기 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드를 설치한 후에는 Kueue 사용자 정의 리소스(CR)를 만들어 설치를 구성해야 합니다.
사전 요구 사항
다음 전제 조건을 모두 완료했는지 확인하세요.
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
클러스터 관리자 권한과
kueue-batch-admin-role역할이 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
- 제공된 API 테이블 열에서 Kueue를 클릭합니다. 이렇게 하면 운영자 세부 정보 페이지의 Kueue 탭으로 이동합니다.
- Kueue 만들기를 클릭하세요. 이렇게 하면 Kueue YAML 생성 보기로 이동합니다.
KueueCR에 대한 세부 정보를 입력하세요.예시
KueueCRapiVersion: kueue.openshift.io/v1 kind: Kueue metadata: labels: app.kubernetes.io/name: kueue-operator app.kubernetes.io/managed-by: kustomize name: cluster1 namespace: openshift-kueue-operator spec: managementState: Managed config: integrations: frameworks:2 - BatchJob preemption: preemptionPolicy: Classical3 # ...- 생성을 클릭합니다.
검증
-
KueueCR을 생성한 후 웹 콘솔에서 운영자 세부 정보 페이지로 이동하면 Kueues 목록에서 CR을 볼 수 있습니다. 선택 사항: OpenShift CLI(
oc)가 설치되어 있는 경우 다음 명령을 실행하고 출력을 관찰하여KueueCR이 성공적으로 생성되었는지 확인할 수 있습니다.$ oc get kueue출력 예
NAME AGE cluster 4m
2.3.5. Kueue의 Red Hat 빌드가 작업을 관리할 수 있도록 네임스페이스에 레이블을 지정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드는 옵트인 웹훅 메커니즘을 사용하여 정책이 대상으로 지정된 작업 및 네임스페이스에만 적용되도록 보장합니다.
Kueue의 Red Hat 빌드에서 작업을 관리할 네임스페이스에 kueue.openshift.io/managed=true 레이블을 지정해야 합니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
-
Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었으며
Kueue사용자 정의 리소스(CR)가 생성되었습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
다음 명령을 실행하여 네임스페이스에
kueue.openshift.io/managed=true레이블을 추가합니다.$ oc label namespace <namespace> kueue.openshift.io/managed=true
이 라벨을 추가하면 Kueue Operator의 Red Hat 빌드에 네임스페이스가 웹훅 입장 컨트롤러에 의해 관리된다는 것을 지시하게 됩니다. 결과적으로, 해당 네임스페이스 내의 Kueue 리소스의 모든 Red Hat 빌드는 적절하게 검증되고 변형됩니다.
2.4. 연결이 끊긴 환경에서 Kueue의 Red Hat 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 OpenShift Container Platform 클러스터에 Kueue의 Red Hat 빌드를 설치하려면 먼저 다음 단계를 완료하여 연결이 끊긴 환경에서 Operator Lifecycle Manager(OLM)를 활성화해야 합니다.
- OLM의 기본 원격 OperatorHub 소스를 비활성화합니다.
- 완전한 인터넷 액세스가 가능한 워크스테이션을 사용하여 OperatorHub 콘텐츠의 로컬 미러를 생성하고 미러 레지스트리로 내보냅니다.
- 기본 원격 소스가 아닌 미러 레지스트리의 로컬 소스에서 Operator를 설치하고 관리하도록 OLM을 구성합니다.
제한된 네트워크에서 OLM을 활성화한 후에는 제한되지 않은 워크스테이션을 계속 사용하여 최신 버전의 Operator가 출시될 때 로컬 OperatorHub 소스를 업데이트할 수 있습니다.
이러한 단계를 완료하는 방법에 대한 전체 설명서는 연결이 끊긴 환경에서 Operator Lifecycle Manager 사용에 대한 OpenShift Container Platform 설명서를 참조하세요.
2.4.1. 호환 환경 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드를 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인하세요.
2.4.1.1. 지원되는 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 아키텍처에서 지원됩니다.
- ARM64
- 64-bit x86
- ppc64le(IBM Power®)
- s390x (IBM Z®)
2.4.1.2. 지원 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 버전 1.1 이상의 Red Hat 빌드는 다음 플랫폼에서 지원됩니다.
- OpenShift Container Platform
- OpenShift Container Platform에서 호스팅되는 컨트롤 플레인
현재 Kueue의 Red Hat 빌드는 MicroShift(MicroShift)의 Red Hat 빌드에서 지원되지 않습니다.
2.4.2. Kueue Operator의 Red Hat 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔의 OperatorHub를 사용하여 OpenShift Container Platform 클러스터에 Kueue Operator의 Red Hat 빌드를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 대한 관리자 권한이 있습니다.
- OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- 클러스터에 Red Hat OpenShift용 cert-manager Operator를 설치하고 구성했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Kueue Operator의 Red Hat 빌드를 선택하고 설치를 클릭합니다.
이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.
이 옵션은 네임스페이스 오브젝트에서
openshift.io/cluster-monitoring: "true"레이블을 설정합니다. 클러스터 모니터링이openshift-kueue-operator네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.설치를 클릭합니다.
참고또는 YAML을 사용하여
Namespace오브젝트를 생성하는 경우openshift.io/cluster-monitoring: "true"라벨을 포함해야 합니다.+
apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-kueue-operator
검증
- Operators → Installed Operators 로 이동하여 Kueue Operator의 Red Hat 빌드가 Succeeded 상태 로 나열되어 있는지 확인합니다.
2.4.3. Kueue의 Red Hat 빌드 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
이전에 Kueue의 Red Hat 빌드를 설치한 경우 최신 버그 수정 및 기능 향상을 사용하려면 배포를 최신 버전으로 수동으로 업그레이드해야 합니다.
사전 요구 사항
- Kueue의 Red Hat 빌드의 이전 버전을 설치했습니다.
- 클러스터 관리자 권한으로 OpenShift Container Platform 웹 콘솔에 로그인했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 운영자 → 설치된 운영자를 클릭한 다음 목록에서 Kueue의 Red Hat 빌드를 선택합니다.
- 작업 드롭다운 메뉴에서 Operator 제거를 선택합니다.
Operator를 제거하시겠습니까? 대화 상자가 열립니다. 제거를 클릭합니다.
중요제거를 클릭하기 전에 이 연산자에 대한 모든 피연산자 인스턴스 삭제 확인란을 선택하면 다음을 포함하여 클러스터에서 모든 기존 리소스가 삭제됩니다.
-
쿠에우에CR - 사용자가 생성한 모든 클러스터 대기열, 로컬 대기열 또는 리소스 플레이버
생성된 리소스를 유지하려면 클러스터를 업그레이드할 때 이 상자를 선택하지 마세요.
-
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Kueue Operator의 Red Hat 빌드를 선택하고 설치를 클릭합니다.
검증
- Operator → 설치된 Operator 로 이동합니다.
- Kueue Operator의 Red Hat 빌드가 '성공' 상태 로 나열되어 있는지 확인하세요.
- 목록에서 운영자 이름 아래에 표시된 버전이 최신 버전인지 확인하세요.
2.4.4. Kueue 사용자 정의 리소스 만들기 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드를 설치한 후에는 Kueue 사용자 정의 리소스(CR)를 만들어 설치를 구성해야 합니다.
사전 요구 사항
다음 전제 조건을 모두 완료했는지 확인하세요.
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
클러스터 관리자 권한과
kueue-batch-admin-role역할이 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
- 제공된 API 테이블 열에서 Kueue를 클릭합니다. 이렇게 하면 운영자 세부 정보 페이지의 Kueue 탭으로 이동합니다.
- Kueue 만들기를 클릭하세요. 이렇게 하면 Kueue YAML 생성 보기로 이동합니다.
KueueCR에 대한 세부 정보를 입력하세요.예시
KueueCRapiVersion: kueue.openshift.io/v1 kind: Kueue metadata: labels: app.kubernetes.io/name: kueue-operator app.kubernetes.io/managed-by: kustomize name: cluster1 namespace: openshift-kueue-operator spec: managementState: Managed config: integrations: frameworks:2 - BatchJob preemption: preemptionPolicy: Classical3 # ...- 생성을 클릭합니다.
검증
-
KueueCR을 생성한 후 웹 콘솔에서 운영자 세부 정보 페이지로 이동하면 Kueues 목록에서 CR을 볼 수 있습니다. 선택 사항: OpenShift CLI(
oc)가 설치되어 있는 경우 다음 명령을 실행하고 출력을 관찰하여KueueCR이 성공적으로 생성되었는지 확인할 수 있습니다.$ oc get kueue출력 예
NAME AGE cluster 4m
2.4.5. Kueue의 Red Hat 빌드가 작업을 관리할 수 있도록 네임스페이스에 레이블을 지정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드는 옵트인 웹훅 메커니즘을 사용하여 정책이 대상으로 지정된 작업 및 네임스페이스에만 적용되도록 보장합니다.
Kueue의 Red Hat 빌드에서 작업을 관리할 네임스페이스에 kueue.openshift.io/managed=true 레이블을 지정해야 합니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
-
Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었으며
Kueue사용자 정의 리소스(CR)가 생성되었습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
다음 명령을 실행하여 네임스페이스에
kueue.openshift.io/managed=true레이블을 추가합니다.$ oc label namespace <namespace> kueue.openshift.io/managed=true
이 라벨을 추가하면 Kueue Operator의 Red Hat 빌드에 네임스페이스가 웹훅 입장 컨트롤러에 의해 관리된다는 것을 지시하게 됩니다. 결과적으로, 해당 네임스페이스 내의 Kueue 리소스의 모든 Red Hat 빌드는 적절하게 검증되고 변형됩니다.
2.5. Leader Worker Set Operator 통합 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 Kueue의 Red Hat 빌드와 통합할 수 있으므로 LeaderWorkerSets를 실행할 때 스케줄링 및 리소스 관리 기능을 활용할 수 있습니다.
Leader Worker Set Operator를 사용하면 다중 노드 AI/ML 추론 배포를 효율적으로 관리할 수 있습니다. Red Hat build of Kueue는 이러한 배포를 위한 스케줄링 및 리소스 관리 기능을 제공합니다. LeaderWorkerSet API를 실행하여 Pod 그룹을 복제 단위로 배포할 때 Leader Worker Set Operator를 구성할 수 있습니다.
2.5.1. Red Hat build of Kue를 사용하여 Leader Worker Set Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator와 함께 작동하도록 Red Hat build of Kue를 구성할 수 있습니다.
사전 요구 사항
- 소프트웨어 카탈로그에 Red Hat Build of Kue Operator를 사용하여 Red Hat build of Kueue를 설치했습니다.
- Leader Worker Set Operator 및 Operand를 소프트웨어 카탈로그에 설치했습니다.
-
클러스터 관리자 권한과
kueue-batch-admin-role역할이 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- 클러스터에 Red Hat OpenShift용 cert-manager Operator를 설치했습니다.
프로세스
다음 예와 같이 Kueue 클러스터 오브젝트의 Red Hat 빌드의
config.integrations.framework섹션에LeaderWorkerSet을 추가합니다.apiVersion: kueue.openshift.io/v1 kind: Kueue metadata: labels: app.kubernetes.io/name: kueue-operator app.kubernetes.io/managed-by: kustomize name: cluster namespace: openshift-kueue-operator spec: managementState: Managed config: integrations: frameworks: - BatchJob - LeaderWorkerSet
2.5.2. Red Hat build of Kueue를 사용하여 Leader Worker Set Operator 실행 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 기존 프레임워크에 추가하고 실행할 수 있습니다.
사전 요구 사항
- Red Hat Build of Kueue Operator를 사용한 Red Hat build of Kueue가 설치되어 있습니다.
- leader Worker Set Operator 및 Operand가 설치됩니다.
- cert-manager Operator for Red Hat OpenShift가 설치되어 있습니다.
-
LeaderWorkerSet이 생성되는네임스페이스는kueue.openshift.io/managed=true를 사용하여 레이블이 지정됩니다. 다음 오브젝트가 구성되었는지 확인합니다.
-
ClusterQueue -
ResourceFlavor -
LocalQueue -
네임스페이스
-
프로세스
leaderworkerset.yaml이라는 파일을 생성합니다.LeaderWorkerSet의 예apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: generation: 1 name: my-lws namespace: my-namespace spec: leaderWorkerTemplate: leaderTemplate: metadata: {} spec: containers: - image: nginxinc/nginx-unprivileged:1.27 name: leader resources: {} restartPolicy: RecreateGroupOnPodRestart size: 3 workerTemplate: metadata: {} spec: containers: - image: nginxinc/nginx-unprivileged:1.27 name: worker ports: - containerPort: 8080 protocol: TCP resources: {} networkConfig: subdomainPolicy: Shared replicas: 2 rolloutStrategy: rollingUpdateConfiguration: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate startupPolicy: LeaderCreatedLeaderWorkerSet구성의metadata.labels섹션에서 대상 로컬 큐를 지정합니다.metadata: labels: kueue.x-k8s.io/queue-name: user-queue다음 명령을 실행하여 리더 워커 세트 구성을 적용합니다.
$ oc apply -f leaderworkerset.yaml
2.6. JobSet Operator 통합 링크 복사링크가 클립보드에 복사되었습니다!
JobSet Operator를 Red Hat build of Kueue와 통합할 수 있으므로 JobSet Operator를 실행할 때 Kue의 Red Hat 빌드에서 제공하는 스케줄링 및 리소스 관리 기능을 활용할 수 있습니다.
JobSet Operator를 사용하여 HPC(고성능 컴퓨팅) 및 AI 교육과 같은 대규모 조정된 워크로드를 관리하고 실행할 수 있습니다.
JobSet Operator는 분산 배치 워크로드를 Kubernetes 작업 그룹으로 모델링합니다. 이를 통해 다양한 Pod 그룹(예: 리더, 작업자, 매개변수 서버 등)에 대해 다양한 Pod 템플릿을 쉽게 지정할 수 있습니다.
2.6.1. Red Hat build of Kueue를 사용하여 JobSet Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
JobSet Operator와 함께 작동하도록 Red Hat build of Kueue를 구성할 수 있습니다.
사전 요구 사항
- 소프트웨어 카탈로그에 Red Hat Build of Kue Operator를 사용하여 Red Hat build of Kueue를 설치했습니다.
- 소프트웨어 카탈로그에 JobSet Operator를 설치했습니다.
-
클러스터 관리자 권한과
kueue-batch-admin-role역할이 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- 클러스터에 Red Hat OpenShift용 cert-manager Operator를 설치했습니다.
프로세스
다음 예와 같이 Kueue 클러스터 오브젝트의 Red Hat 빌드의
config.integrations.frameworks섹션에JobSet을 추가합니다.apiVersion: kueue.openshift.io/v1 kind: Kueue metadata: name: cluster namespace: openshift-kueue-operator spec: managementState: Managed config: integrations: frameworks: - JobSet
2.6.2. Red Hat build of Kueue를 사용하여 JobSet Operator 실행 링크 복사링크가 클립보드에 복사되었습니다!
기존 프레임워크에 JobSet Operator를 추가하고 실행할 수 있습니다.
사전 요구 사항
- Red Hat Build of Kueue Operator를 사용한 Red Hat build of Kueue가 설치되어 있습니다.
- JobSet Operator가 설치되어 있습니다.
- cert-manager Operator for Red Hat OpenShift가 설치되어 있습니다.
-
JobSet이 생성될네임스페이스에는kueue.openshift.io/managed=true를 사용하여 레이블이 지정됩니다. 다음 오브젝트가 구성되었는지 확인합니다.
-
ClusterQueue -
ResourceFlavor -
LocalQueue -
네임스페이스
-
프로세스
jobset.yaml이라는 파일을 생성합니다.JobSet의 예apiVersion: jobset.x-k8s.io/v1alpha2 kind: JobSet metadata: name: jobset namespace: my-namespace spec: replicatedJobs: - name: workers replicas: 1 template: spec: parallelism: 3 completions: 3 backoffLimit: 1 template: spec: containers: - name: sleep image: busybox resources: requests: cpu: 200m memory: "200Mi" command: - sleep args: - 220s - name: driver template: spec: parallelism: 1 completions: 1 backoffLimit: 0 template: spec: containers: - name: sleep image: busybox resources: requests: cpu: 200m memory: "200Mi" command: - sleep args: - 220sJobSet구성의metadata.labels섹션에서 대상 로컬 큐를 지정합니다.metadata: labels: kueue.x-k8s.io/queue-name: <local-queue-name>다음 명령을 실행하여 JobSet 구성을 적용합니다.
$ oc apply -f jobset.yaml
2.7. 역할 기반 권한 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 Kueue 배포의 Red Hat 빌드에 대한 역할 기반 액세스 제어(RBAC)를 구성하는 방법에 대한 정보를 제공합니다. 이러한 RBAC 권한은 어떤 유형의 사용자가 어떤 유형의 Kueue 개체의 Red Hat 빌드를 생성할 수 있는지 결정합니다.
2.7.1. (Cluster)Roles 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드는 기본적으로 kueue-batch-admin-role 및 kueue-batch-user-role 클러스터 역할을 배포합니다.
- kueue-batch-admin-role
- 이 클러스터 역할에는 클러스터 대기열, 로컬 대기열, 워크로드 및 리소스 플레이버를 관리하는 권한이 포함됩니다.
- kueue-batch-user-role
- 이 클러스터 역할에는 작업을 관리하고 로컬 대기열과 작업 부하를 볼 수 있는 권한이 포함되어 있습니다.
2.7.2. 배치 관리자에 대한 권한 구성 링크 복사링크가 클립보드에 복사되었습니다!
kueue-batch-admin-role 클러스터 역할을 사용자 또는 사용자 그룹에 바인딩하여 배치 관리자의 권한을 구성할 수 있습니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
- 클러스터 관리자 권한이 있어야 합니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
YAML 파일로
ClusterRoleBinding객체를 만듭니다.ClusterRoleBinding오브젝트의 예apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kueue-admins1 subjects:2 - kind: User name: admin@example.com apiGroup: rbac.authorization.k8s.io roleRef:3 kind: ClusterRole name: kueue-batch-admin-role apiGroup: rbac.authorization.k8s.ioClusterRoleBinding객체를 적용합니다.$ oc apply -f <filename>.yaml
검증
다음 명령을 실행하고 출력에
kueue-batch-admin-role클러스터 역할에 대한 올바른 정보가 포함되어 있는지 확인하여ClusterRoleBinding개체가 올바르게 적용되었는지 확인할 수 있습니다.$ oc describe clusterrolebinding.rbac출력 예
... Name: kueue-batch-admin-role Labels: app.kubernetes.io/name=kueue Annotations: <none> Role: Kind: ClusterRole Name: kueue-batch-admin-role Subjects: Kind Name Namespace ---- ---- --------- User admin@example.com admin-namespace ...
2.7.3. 사용자 권한 구성 링크 복사링크가 클립보드에 복사되었습니다!
Kueue-batch-user-role 클러스터 역할을 사용자 또는 사용자 그룹에 바인딩하여 Kueue 사용자의 Red Hat 빌드에 대한 권한을 구성할 수 있습니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
- 클러스터 관리자 권한이 있어야 합니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
YAML 파일로
RoleBinding객체를 만듭니다.ClusterRoleBinding오브젝트의 예apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kueue-users1 namespace: user-namespace2 subjects:3 - kind: Group name: team-a@example.com apiGroup: rbac.authorization.k8s.io roleRef:4 kind: ClusterRole name: kueue-batch-user-role apiGroup: rbac.authorization.k8s.ioRoleBinding객체를 적용합니다.$ oc apply -f <filename>.yaml
검증
다음 명령을 실행하고 출력에
kueue-batch-user-role클러스터 역할에 대한 올바른 정보가 포함되어 있는지 확인하여RoleBinding개체가 올바르게 적용되었는지 확인할 수 있습니다.$ oc describe rolebinding.rbac출력 예
... Name: kueue-users Labels: app.kubernetes.io/name=kueue Annotations: <none> Role: Kind: ClusterRole Name: kueue-batch-user-role Subjects: Kind Name Namespace ---- ---- --------- Group team-a@example.com user-namespace ...
2.8. 할당량 구성 링크 복사링크가 클립보드에 복사되었습니다!
관리자는 Kueue의 Red Hat 빌드를 사용하여 할당량을 구성하여 사용자 작업 부하에 대한 리소스 할당과 시스템 처리량을 최적화할 수 있습니다. CPU, 메모리, Pod, GPU 등의 컴퓨팅 리소스에 대한 할당량을 구성할 수 있습니다.
다음 단계를 완료하여 Kueue의 Red Hat 빌드에서 할당량을 구성할 수 있습니다.
- 클러스터 대기열을 구성합니다.
- 리소스 플레이버를 구성합니다.
- 로컬 대기열을 구성합니다.
그러면 사용자는 자신의 작업 부하를 로컬 대기열에 제출할 수 있습니다.
2.8.1. 클러스터 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 큐는 CPU, 메모리, 포드 등의 리소스 풀을 관리하는 ClusterQueue 객체로 표현되는 클러스터 범위의 리소스입니다. 클러스터 대기열은 사용 한도, 리소스 플레이버에 대한 할당량, 소비 순서 및 공정한 공유 규칙을 정의하는 데 사용할 수 있습니다.
ResourceFlavor 개체가 구성될 때까지 클러스터 대기열을 사용할 수 없습니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
클러스터 관리자 권한 또는
kueue-batch-admin-role역할이 있습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
YAML 파일로
ClusterQueue객체를 만듭니다.단일 리소스 플레이버를 사용하는 기본
ClusterQueue객체의 예apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: cluster-queue spec: namespaceSelector: {}1 resourceGroups: - coveredResources: ["cpu", "memory", "pods", "foo.com/gpu"]2 flavors: - name: "default-flavor"3 resources:4 - name: "cpu" nominalQuota: 9 - name: "memory" nominalQuota: 36Gi - name: "pods" nominalQuota: 5 - name: "foo.com/gpu" nominalQuota: 100- 1
- 이 클러스터 대기열에 의해 관리되는 리소스를 사용할 수 있는 네임스페이스를 정의합니다. 예시에 표시된 빈
namespaceSelector는모든 네임스페이스가 이러한 리소스를 사용할 수 있음을 의미합니다. - 2
- 클러스터 대기열에 의해 관리되는 리소스 유형을 정의합니다. 이 예제
ClusterQueue객체는 CPU, 메모리, Pod 및 GPU 리소스를 관리합니다. - 3
- 나열된 리소스 유형에 적용되는 리소스 플레이버를 정의합니다. 이 예에서는
기본 플레이버리소스 플레이버가 CPU, 메모리, Pod 및 GPU 리소스에 적용됩니다. - 4
- 채용에 필요한 리소스 요구 사항을 정의합니다. 이 예제 클러스터 대기열은 다음 조건이 충족되는 경우에만 작업을 허용합니다.
- CPU 요청의 합은 9보다 작거나 같습니다.
- 메모리 요청의 합계는 36Gi 이하입니다.
- 포드의 총 개수는 5개 이하입니다.
- GPU 요청의 합계가 100 이하입니다.
다음 명령을 실행하여
ClusterQueue객체를 적용합니다.$ oc apply -f <filename>.yaml
2.8.2. 리소스 플레이버 구성 링크 복사링크가 클립보드에 복사되었습니다!
ClusterQueue 객체를 구성한 후 ResourceFlavor 객체를 구성할 수 있습니다.
클러스터의 리소스는 일반적으로 동질적이지 않습니다. 클러스터의 리소스가 동종인 경우 사용자 정의 리소스 플레이버에 레이블을 추가하는 대신 빈 ResourceFlavor를 사용할 수 있습니다.
사용자 정의 ResourceFlavor 객체를 사용하면 레이블, 오염, 허용을 통해 클러스터 노드와 연관된 다양한 리소스 변형을 표현할 수 있습니다. 그런 다음 워크로드를 특정 노드 유형과 연결하여 세분화된 리소스 관리를 활성화할 수 있습니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
클러스터 관리자 권한 또는
kueue-batch-admin-role역할이 있습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
YAML 파일로
ResourceFlavor객체를 만듭니다.빈
ResourceFlavor객체의 예apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata: name: default-flavor사용자 정의
ResourceFlavor객체의 예apiVersion: kueue.x-k8s.io/v1beta1 kind: ResourceFlavor metadata: name: "x86" spec: nodeLabels: cpu-arch: x86다음 명령을 실행하여
ResourceFlavor객체를 적용합니다.$ oc apply -f <filename>.yaml
2.8.3. 로컬 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
로컬 큐는 LocalQueue 객체로 표현되는 네임스페이스 객체로, 단일 네임스페이스에 속하는 밀접하게 관련된 워크로드를 그룹화합니다.
관리자는 LocalQueue 개체가 클러스터 대기열을 가리키도록 구성할 수 있습니다. 이는 LocalQueue 개체에 지정된 네임스페이스의 워크로드에 클러스터 대기열의 리소스를 할당합니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
클러스터 관리자 권한 또는
kueue-batch-admin-role역할이 있습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다. -
ClusterQueue객체를 생성했습니다.
프로세스
YAML 파일로
LocalQueue객체를 만듭니다.기본
LocalQueue객체의 예apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: namespace: team-namespace name: user-queue spec: clusterQueue: cluster-queue다음 명령을 실행하여
LocalQueue객체를 적용합니다.$ oc apply -f <filename>.yaml
2.8.4. 기본 로컬 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 각 작업에 명시적으로 레이블을 지정하지 않고도 선택한 네임스페이스의 모든 작업을 관리하여 클러스터의 할당량 적용을 개선할 수 있습니다. 기본 로컬 대기열을 생성하면 됩니다.
기본 로컬 대기열은 kueue.x-k8s.io/queue-name 라벨이 없는 새로 생성된 작업에 대한 로컬 대기열 역할을 합니다. 기본 로컬 대기열을 생성한 후 kueue.x-k8s.io/queue-name 레이블이 없는 네임스페이스에서 생성된 모든 새 작업은 자동으로 kueue.x-k8s.io/queue-name: 기본 레이블을 갖도록 업데이트됩니다.
기본 로컬 큐를 생성해도 네임스페이스의 기존 작업은 영향을 받지 않습니다. 기본 로컬 큐를 생성하기 전에 네임스페이스에 작업이 이미 존재하는 경우 해당 작업에 명시적으로 레이블을 지정하여 큐에 할당해야 합니다.
사전 요구 사항
- 클러스터에 Kueue 버전 1.1의 Red Hat 빌드를 설치했습니다.
-
클러스터 관리자 권한 또는
kueue-batch-admin-role역할이 있습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다. -
ClusterQueue객체를 생성했습니다.
프로세스
YAML 파일로
default라는 이름의LocalQueue객체를 만듭니다.기본
LocalQueue객체의 예apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: namespace: team-namespace name: default spec: clusterQueue: cluster-queue다음 명령을 실행하여
LocalQueue객체를 적용합니다.$ oc apply -f <filename>.yaml
검증
- 기본 로컬 큐와 동일한 네임스페이스에 작업을 생성합니다.
-
작업이
kueue.x-k8s.io/queue-name: 기본레이블로 업데이트되는 것을 확인합니다.
2.9. 작업 및 작업량 관리 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드는 사용자가 생성한 작업을 직접 조작하지 않습니다. 대신 Kueue는 작업의 리소스 요구 사항을 나타내는 작업 부하 객체를 관리합니다. Kueue의 Red Hat 빌드는 각 작업에 대한 작업 부하를 자동으로 생성하고 두 개체 간의 모든 결정과 상태를 동기화합니다.
2.9.1. Kueue의 Red Hat 빌드가 작업을 관리할 수 있도록 네임스페이스에 레이블을 지정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
Kueue Operator의 Red Hat 빌드는 옵트인 웹훅 메커니즘을 사용하여 정책이 대상으로 지정된 작업 및 네임스페이스에만 적용되도록 보장합니다.
Kueue의 Red Hat 빌드에서 작업을 관리할 네임스페이스에 kueue.openshift.io/managed=true 레이블을 지정해야 합니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
-
Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었으며
Kueue사용자 정의 리소스(CR)가 생성되었습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
다음 명령을 실행하여 네임스페이스에
kueue.openshift.io/managed=true레이블을 추가합니다.$ oc label namespace <namespace> kueue.openshift.io/managed=true
이 라벨을 추가하면 Kueue Operator의 Red Hat 빌드에 네임스페이스가 웹훅 입장 컨트롤러에 의해 관리된다는 것을 지시하게 됩니다. 결과적으로, 해당 네임스페이스 내의 Kueue 리소스의 모든 Red Hat 빌드는 적절하게 검증되고 변형됩니다.
2.9.2. 작업에 대한 레이블 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 사용자 정의 리소스(CR)의 spec.config.workloadManagement.labelPolicy 사양은 Kueue의 Red Hat 빌드에서 다양한 작업을 관리하거나 무시할지 여부를 결정하는 방법을 제어하는 선택적 필드입니다. 허용되는 값은 QueueName , None 및 비어 있음( "" )입니다.
labelPolicy 설정이 생략되거나 비어 있는 경우( "" ), 기본 정책은 Kueue의 Red Hat 빌드가 kueue.x-k8s.io/queue-name 레이블이 있는 작업을 관리하고 kueue.x-k8s.io/queue-name 레이블이 없는 작업을 무시한다는 것입니다. 이는 labelPolicy가 QueueName 으로 설정된 경우와 동일한 워크플로입니다.
labelPolicy 설정이 None 으로 설정된 경우 작업은 kueue.x-k8s.io/queue-name 레이블이 없더라도 Kueue의 Red Hat 빌드에 의해 관리됩니다.
workloadManagement 사양 구성 예시
apiVersion: kueue.openshift.io/v1
kind: Kueue
metadata:
labels:
app.kubernetes.io/name: kueue-operator
app.kubernetes.io/managed-by: kustomize
name: cluster
namespace: openshift-kueue-operator
spec:
config:
workloadManagement:
labelPolicy: QueueName
# ...
kueue.x-k8s.io/queue-name 레이블을 포함하는 사용자 생성 Job 객체의 예
apiVersion: batch/v1
kind: Job
metadata:
generateName: sample-job-
namespace: my-namespace
labels:
kueue.x-k8s.io/queue-name: user-queue
spec:
# ...
2.10. 보류 중인 워크로드 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat build of Kueue는 보류 중인 워크로드를 모니터링할 수 있는 VisibilityOnDemand 기능을 제공합니다. 워크로드는 완료까지 실행되는 애플리케이션입니다. 느슨하게 연결된 하나 이상의 Pod로 구성되며 전체적으로 작업을 완료할 수 있습니다. 워크로드는 Red Hat build of Kueue의 승인 단위입니다.
VisibilityOnDemand 기능을 사용하면 배치 관리자가 클러스터 대기열에서 보류 중인 작업의 파이프라인과 로컬 대기열 및 배치 사용자를 모니터링할 수 있으며 사용자가 작업 시작 시기를 추정할 수 있도록 지원합니다.
인바운드 요청 및 높은 요청 볼륨을 규제하고 보류 중인 워크로드를 볼 수 있는 사용자 권한을 제공할 수 있습니다.
2.10.1. API 우선 순위 및 공정성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat build of Kueue는 Kubernetes API Priority 및 Fairness (APF)를 사용하여 보류 중인 워크로드를 관리합니다. APF는 API 서버에 대한 인바운드 요청을 규제하기 위해 API 수준 정책을 정의할 수 있는 흐름 제어 메커니즘입니다. 이는 API 서버가 예기치 않게 높은 요청 볼륨으로 압도되지 않도록 보호하는 동시에, 최고 수준의 워크로드에 미치는 영향을 제한하지 못하도록 중요한 트래픽을 보호합니다.
2.10.2. 사용자 권한 제공 링크 복사링크가 클립보드에 복사되었습니다!
Kueue 배포 Red Hat 빌드 사용자의 RBAC(역할 기반 액세스 제어) 오브젝트를 구성할 수 있습니다. 이러한 객체는 어떤 유형의 사용자가 Kueue 객체의 Red Hat build 유형을 생성할 수 있는지 결정합니다.
특정 API에 액세스해야 하는 사용자에게 권한을 제공해야 합니다.
-
사용자가
ClusterQueue리소스에서 보류 중인 워크로드에 액세스해야 하는 경우 ClusterRolekueue-batch-admin-role을 참조하는ClusterRoleBinding스키마를 생성해야 합니다. -
사용자가
LocalQueue리소스에서 보류 중인 워크로드에 액세스해야 하는 경우 ClusterRolekue-batch-user-role을 참조하는RoleBinding스키마를 생성해야 합니다.
2.10.3. 필요에 따라 보류 중인 워크로드 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
보류 중인 워크로드의 모니터링을 테스트하려면 ClusterQueue 및 LocalQueue 리소스를 올바르게 구성해야 합니다. 그런 다음 해당 LocalQueue 에서 작업을 생성할 수 있습니다. Kueue는 작업에서 생성한 워크로드 오브젝트를 관리하므로 작업이 제출되고 ClusterQueue 를 포화 상태로 전환하면 보류 중인 워크로드 목록에 해당 워크로드를 볼 수 있습니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
-
Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었으며
Kueue사용자 정의 리소스(CR)가 생성되었습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다. -
OpenShift CLI(
oc)는 클러스터와 통신합니다.
다음 절차에서는 워크로드 모니터링을 설치 및 테스트하는 방법을 설명합니다.
프로세스
다음 명령을 실행하여 자산을 생성합니다.
cat <<EOF| oc create -f - --- apiVersion: kueue.x-k8s.io/v1beta2 kind: ResourceFlavor metadata: name: "default-flavor" --- apiVersion: kueue.x-k8s.io/v1beta2 kind: ClusterQueue metadata: name: "cluster-queue" spec: namespaceSelector: {} # match all. resourceGroups: - coveredResources: ["cpu", "memory"] flavors: - name: "default-flavor" resources: - name: "cpu" nominalQuota: 9 - name: "memory" nominalQuota: 36Gi --- apiVersion: kueue.x-k8s.io/v1beta2 kind: LocalQueue metadata: namespace: "default" name: "user-queue" spec: clusterQueue: "cluster-queue" --- EOF작업 매니페스트를 사용하여 다음 파일을 생성합니다.
cat >> job.yaml << EOF apiVersion: batch/v1 kind: Job metadata: generateName: sample-job- namespace: default labels: kueue.x-k8s.io/queue-name: user-queue spec: parallelism: 3 completions: 3 suspend: true template: spec: containers: - name: <example-job> image: registry.k8s.io/e2e-test-images/agnhost:2.53 command: [ "/bin/sh" ] args: [ "-c", "sleep 60" ] resources: requests: cpu: "1" memory: "200Mi" restartPolicy: Never EOF다음 명령을 실행하여 Kue에서 관리할 기본 네임스페이스에 레이블을 지정합니다.
$ oc label namespace default kueue.openshift.io/managed=true다음 명령을 실행하여 6개의 작업을 생성합니다.
for i in {1..6}; do oc create -f job.yaml; done이 예에서는
ClusterQueue리소스를 포화 상태로 만드는 작업 중 세 개가 보류 중이어야 합니다.
2.10.3.1. ClusterQueue에서 보류 중인 워크로드 보기 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 수준에서 보류 중인 모든 워크로드를 보기 위해 관리자는 Kue의 가시성 API의 ClusterQueue 오브젝트 가시성 끝점을 사용할 수 있습니다. 이 끝점은 해당 ClusterQueue 리소스에서 현재 승인을 기다리는 모든 워크로드 목록을 반환합니다.
프로세스
ClusterQueue에서 보류 중인 워크로드를 보려면 다음 명령을 실행합니다.$ oc get --raw "/apis/visibility.kueue.x-k8s.io/v1beta1/clusterqueues/cluster-queue/pendingworkloads"출력 예
{ "kind": "PendingWorkloadsSummary", "apiVersion": "visibility.kueue.x-k8s.io/v1beta1", "metadata": { "creationTimestamp": null }, "items": [ { "metadata": { "name": "job-sample-job-jrjfr-8d56e", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-jrjfr", "uid": "5863cf0e-b0e7-43bf-a445-f41fa1abedfa" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 0, "positionInLocalQueue": 0 }, { "metadata": { "name": "job-sample-job-jg9dw-5f1a3", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-jg9dw", "uid": "fd5d1796-f61d-402f-a4c8-cbda646e2676" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 1, "positionInLocalQueue": 1 }, { "metadata": { "name": "job-sample-job-t9b8m-4e770", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-t9b8m", "uid": "64c26c73-6334-4d13-a1a8-38d99196baa5" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 2, "positionInLocalQueue": 2 } ] }다음과 같은 선택적 쿼리 매개변수를 전달할 수 있습니다.
limit <integer>- 1000은 기본값입니다. 가져와야 하는 보류 중인 최대 워크로드 수를 지정합니다.
offset <integer>- 0은 기본값입니다. 0부터 시작하여 가져올 첫 번째 보류 중인 워크로드의 위치를 지정합니다.
ClusterQueue에서 위치 0부터 하나의 보류 중인 워크로드만 보려면 다음 명령을 실행합니다.$ oc get --raw "/apis/visibility.kueue.x-k8s.io/v1beta1/clusterqueues/cluster-queue/pendingworkloads?limit=1&offset=0"
2.10.3.2. LocalQueue에서 보류 중인 워크로드 보기 링크 복사링크가 클립보드에 복사되었습니다!
네임스페이스 내에서 특정 테넌트에서 제출한 보류 중인 워크로드를 보려면 사용자가 Kueue의 가시성 API의 LocalQueue 리소스 표시 끝점을 쿼리할 수 있습니다. 이는 해당 대기열에서 대기 중인 작업의 정렬된 목록을 제공합니다.
프로세스
LocalQueue에서 보류 중인 워크로드를 보려면 다음 명령을 실행합니다.$ oc get --raw /apis/visibility.kueue.x-k8s.io/v1beta2/namespaces/default/localqueues/user-queue/pendingworkloads출력 예
{ "kind": "PendingWorkloadsSummary", "apiVersion": "visibility.kueue.x-k8s.io/v1beta2", "metadata": { "creationTimestamp": null }, "items": [ { "metadata": { "name": "job-sample-job-jrjfr-8d56e", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-jrjfr", "uid": "5863cf0e-b0e7-43bf-a445-f41fa1abedfa" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 0, "positionInLocalQueue": 0 }, { "metadata": { "name": "job-sample-job-jg9dw-5f1a3", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-jg9dw", "uid": "fd5d1796-f61d-402f-a4c8-cbda646e2676" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 1, "positionInLocalQueue": 1 }, { "metadata": { "name": "job-sample-job-t9b8m-4e770", "namespace": "default", "creationTimestamp": "2023-12-05T15:42:03Z", "ownerReferences": [ { "apiVersion": "batch/v1", "kind": "Job", "name": "sample-job-t9b8m", "uid": "64c26c73-6334-4d13-a1a8-38d99196baa5" } ] }, "priority": 0, "localQueueName": "user-queue", "positionInClusterQueue": 2, "positionInLocalQueue": 2 } ] }다음과 같은 선택적 쿼리 매개변수를 전달할 수 있습니다.
limit <integer>- 1000은 기본값입니다. 가져와야 하는 보류 중인 최대 워크로드 수를 지정합니다.
offset <integer>- 0은 기본값입니다. 0부터 시작하여 가져올 첫 번째 보류 중인 워크로드의 위치를 지정합니다.
LocalQueue에서 위치 0부터 하나의 보류 중인 워크로드만 보려면 다음 명령을 실행합니다.
$ oc get --raw "/apis/visibility.kueue.x-k8s.io/v1beta2/namespaces/default/localqueues/user-queue/pendingworkloads?limit=1&offset=0"
2.10.4. 모니터링 설정 수정 링크 복사링크가 클립보드에 복사되었습니다!
사용자가 적시에 안정적인 방식으로 보류 중인 워크로드에 액세스하고 볼 수 있도록 조직의 요구 사항에 따라 모니터링 설정을 수정합니다.
다음 절차에서는 Kueue VisibilityOnDemand 기능의 Red Hat 빌드에 대한 리소스 흐름 제어를 수정하는 방법을 설명합니다. 작업 가시성 정보에 대한 동시 요청을 처리하는 시스템의 기능에 직접적인 영향을 미칩니다.
프로세스
다음 명령을 실행하여
Kueue의VisibilityOnDemand에 대한PriorityLevelConfiguration자산을 편집합니다.$ oc edit prioritylevelconfiguration kueue-visibilitykueue.openshift.io/allow-nominal-concurrency-shares-update값을true로 설정하여PriorityLevelConfiguration자산에서nominalConcurrencyShares필드를 수정합니다.nominalConcurrencyShares에 지정할 수 있는 가능한 값은0,2(기본값)에서5까지입니다. 허용되지 않는 값(값1또는5이상의 값)을 지정하는 경우 기본값2가 적용됩니다.다음 예제를 참조하십시오.
apiVersion: flowcontrol.apiserver.k8s.io/v1 kind: PriorityLevelConfiguration metadata: name: kueue-visibility annotations: kueue.openshift.io/allow-nominal-concurrency-shares-update: "false" spec: limited: borrowingLimitPercent: 0 lendablePercent: 90 limitResponse: queuing: handSize: 4 queueLengthLimit: 50 queues: 16 type: Queue nominalConcurrencyShares: 2 type: Limitedkueue.openshift.io/allow-nominal-concurrency-shares-update의 기본값은false입니다.nominalConcurrencyShares의 값을2이외의 값으로 변경하는 경우 먼저kueue.openshift.io/allow-nominal-concurrency-shares-update값을true로 변경해야 합니다. 그렇지 않으면nominalConcurrencyShares에 할당한 값이 적용되지 않습니다.다음 명령을 실행하여 값이 유지되는지 확인합니다.
$ oc get prioritylevelconfiguration kueue-visibility
2.11. 코호트 사용 링크 복사링크가 클립보드에 복사되었습니다!
코호트를 사용하여 클러스터 대기열을 그룹화하고 어떤 클러스터 대기열이 서로 빌릴 수 있는 리소스를 공유할 수 있는지 확인할 수 있습니다. 빌릴 수 있는 리소스는 코호트 내 모든 클러스터 대기열의 사용되지 않은 명목 할당량으로 정의됩니다.
코호트를 사용하면 활용 부족을 방지하고 공정한 공유 구성을 활성화하여 리소스 활용도를 최적화하는 데 도움이 될 수 있습니다. 또한 코호트는 관련 작업 부하나 각 팀에 대해 클러스터 대기열을 그룹화할 수 있으므로 팀 간 리소스 관리 및 할당을 단순화하는 데 도움이 될 수 있습니다. 또한 코호트를 사용하여 그룹 수준에서 리소스 할당량을 설정하여 클러스터 대기열 그룹이 사용할 수 있는 리소스에 대한 제한을 정의할 수 있습니다.
2.11.1. 클러스터 대기열 사양 내에서 코호트 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예와 같이 ClusterQueue 객체의 .spec.cohort 필드에 코호트 이름을 지정하여 코호트에 클러스터 대기열을 추가할 수 있습니다.
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
name: cluster-queue
spec:
# ...
cohort: example-cohort
# ...
일치하는 spec.cohort 가 있는 모든 클러스터 대기열은 동일한 코호트에 속합니다.
spec.cohort 필드가 생략되면 클러스터 대기열은 어떤 코호트에도 속하지 않으며 빌릴 수 있는 리소스에 액세스할 수 없습니다.
2.12. 공정한 공유 구성 링크 복사링크가 클립보드에 복사되었습니다!
공정한 공유는 집단의 세입자 간에 빌릴 수 있는 자원의 동등하거나 가중된 몫을 달성하기 위해 사용되는 선점 전략입니다. 빌릴 수 있는 리소스는 코호트 내 모든 클러스터 대기열의 사용되지 않은 명목 할당량입니다.
Kueue 사용자 정의 리소스(CR)에서 preemptionPolicy 값을 FairSharing 으로 설정하여 공정한 공유를 구성할 수 있습니다.
2.13. 갱 스케줄링 링크 복사링크가 클립보드에 복사되었습니다!
갱 스케줄링은 관련된 작업의 그룹이나 갱이 필요한 모든 리소스가 사용 가능할 때만 작업을 시작하도록 보장합니다. Kueue의 Red Hat 빌드는 OpenShift Container Platform 클러스터가 갱에서 관련된 모든 작업을 함께 시작하고 실행할 수 있는 용량을 보장할 때까지 작업을 일시 중단하여 갱 스케줄링을 지원합니다. 이것을 전부 아니면 전무 스케줄링이라고도 합니다.
GPU와 같이 비용이 많이 들고 제한된 리소스를 사용하는 경우 갱 스케줄링이 중요합니다. 갱 스케줄링을 사용하면 작업이 GPU를 사용하지 않고 클레임되는 것을 방지할 수 있으므로 GPU 활용도를 높이고 운영 비용을 절감할 수 있습니다. 갱 스케줄링은 리소스 분할 및 교착 상태와 같은 문제를 방지하는 데에도 도움이 될 수 있습니다.
2.13.1. 갱 스케줄링 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Kueue 사용자 정의 리소스(CR)에서 gangScheduling 사양을 수정하여 갱 스케줄링을 구성할 수 있습니다.
갱 스케줄링이 구성된 Kueue CR 예시
apiVersion: kueue.openshift.io/v1
kind: Kueue
metadata:
name: cluster
labels:
app.kubernetes.io/managed-by: kustomize
app.kubernetes.io/name: kueue-operator
namespace: openshift-kueue-operator
spec:
config:
gangScheduling:
policy: ByWorkload
byWorkload:
admission: Parallel
# ...
- 1
정책값을 설정하여 갱 스케줄링을 활성화하거나 비활성화할 수 있습니다. 가능한 값은ByWorkload,None또는 비어 있음("")입니다.ByWorkload-
정책값이ByWorkload로 설정되면 각 작업은 처리되어 단일 단위로 승인이 고려됩니다. 지정된 시간 내에 작업이 준비되지 않으면 전체 작업이 추방되고 나중에 다시 시도됩니다. 없음-
정책값이None으로 설정되면 갱 스케줄링이 비활성화됩니다. - 비어 있는 (
"") -
정책값이 비어 있거나""로 설정된 경우 Kueue Operator의 Red Hat 빌드는 갱 스케줄링에 대한 설정을 결정합니다. 현재 갱 스케줄링은 기본적으로 비활성화되어 있습니다.
- 2
정책값이ByWorkload로 설정된 경우 작업 허용 설정을 구성해야 합니다.입학사양에 가능한 값은Parallel,Sequential또는 비어 있음("")입니다.평행한-
입장값이Parallel로 설정된 경우 모든 작업의 포드가 언제든지 입장될 수 있습니다. 이로 인해 작업이 클러스터 용량을 놓고 경쟁하는 교착 상태가 발생할 수 있습니다. 교착 상태가 발생하면 다른 작업에서 포드를 성공적으로 스케줄링하면 현재 작업에서 포드를 스케줄링하는 것을 방해할 수 있습니다. 잇달아 일어나는-
입장값이Sequential로 설정된 경우 현재 처리 중인 작업의 Pod만 입장됩니다. 현재 작업의 모든 포드가 승인되고 준비가 되면 Kueue의 Red Hat 빌드가 다음 작업을 처리합니다. 클러스터에 여러 작업을 처리할 수 있는 충분한 용량이 있는 경우 순차적 처리를 수행하면 승인 속도가 느려질 수 있지만, 작업에 대한 모든 포드가 성공적으로 함께 예약될 가능성이 높아집니다. - 비어 있는 (
"") -
입학값이 비어 있거나""로 설정된 경우 Kueue Operator의 Red Hat 빌드가 작업 입학 설정을 결정합니다. 현재입장가치는 기본적으로Parallel로 설정되어 있습니다.
2.14. 할당량 제한이 있는 작업 실행 링크 복사링크가 클립보드에 복사되었습니다!
정의된 할당량 한도 내에서 리소스 할당을 관리하기 위해 Kueue의 Red Hat 빌드를 사용하여 Kubernetes 작업을 실행할 수 있습니다. 이를 통해 예측 가능한 리소스 가용성, 클러스터 안정성, 최적화된 성능을 보장할 수 있습니다.
2.14.1. 사용 가능한 로컬 대기열 식별 링크 복사링크가 클립보드에 복사되었습니다!
대기열에 작업을 제출하기 전에 로컬 대기열의 이름을 찾아야 합니다.
사전 요구 사항
- 클러스터 관리자가 OpenShift Container Platform 클러스터에 Kueue의 Red Hat 빌드를 설치하고 구성했습니다.
-
클러스터 관리자가 귀하에게
kueue-batch-user-role클러스터 역할을 할당했습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
네임스페이스에서 사용 가능한 로컬 큐를 나열하려면 다음 명령을 실행하세요.
$ oc -n <namespace> get localqueues출력 예
NAME CLUSTERQUEUE PENDING WORKLOADS user-queue cluster-queue 3
2.14.2. Kueue의 Red Hat 빌드로 실행할 작업 정의 링크 복사링크가 클립보드에 복사되었습니다!
Kueue의 Red Hat 빌드로 실행할 작업을 정의할 때 다음 기준을 충족하는지 확인하세요.
-
kueue.x-k8s.io/queue-name레이블을 사용하여 작업을 제출할 로컬 대기열을 지정합니다. - 각 작업 포드에 대한 리소스 요청을 포함합니다.
Kueue의 Red Hat 빌드는 작업을 일시 중단한 다음 리소스를 사용할 수 있게 되면 작업을 시작합니다. Kueue의 Red Hat 빌드는 작업과 일치하는 이름을 가진 Workload 객체로 표현되는 해당 작업 부하를 생성합니다.
사전 요구 사항
- 클러스터 관리자가 OpenShift Container Platform 클러스터에 Kueue의 Red Hat 빌드를 설치하고 구성했습니다.
-
클러스터 관리자가 귀하에게
kueue-batch-user-role클러스터 역할을 할당했습니다. -
OpenShift CLI(
oc)가 설치되어 있습니다. - 작업을 제출할 로컬 대기열의 이름을 식별했습니다.
프로세스
Job객체를 생성합니다.예시 작업
apiVersion: batch/v1 kind: Job1 metadata: generateName: sample-job-2 namespace: my-namespace labels: kueue.x-k8s.io/queue-name: user-queue3 spec: parallelism: 3 completions: 3 template: spec: containers: - name: dummy-job image: registry.k8s.io/e2e-test-images/agnhost:2.53 args: ["entrypoint-tester", "hello", "world"] resources:4 requests: cpu: 1 memory: "200Mi" restartPolicy: Never다음 명령을 실행하여 작업을 실행합니다.
$ oc create -f <filename>.yaml
검증
다음 명령을 실행하고 출력을 관찰하여 생성한 작업에 대해 포드가 실행 중인지 확인하세요.
$ oc get job <job-name>출력 예
NAME STATUS COMPLETIONS DURATION AGE sample-job-sk42x Suspended 0/1 2m12s다음 명령을 실행하고 출력을 관찰하여 해당 작업에 대한 워크로드가 네임스페이스에 생성되었는지 확인하세요.
$ oc -n <namespace> get workloads출력 예
NAME QUEUE RESERVED IN ADMITTED FINISHED AGE job-sample-job-sk42x-77c03 user-queue 3m8s
2.15. 지원 요청 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에 설명된 절차나 Kueue의 Red Hat 빌드 전반에 어려움이 있는 경우 Red Hat 고객 포털을 방문하세요.
고객 포털에서 다음을 수행할 수 있습니다.
- Red Hat 제품과 관련된 기사 및 솔루션에 대한 Red Hat 지식베이스를 검색하거나 살펴볼 수 있습니다.
- Red Hat 지원에 대한 지원 케이스 제출할 수 있습니다.
- 다른 제품 설명서에 액세스 가능합니다.
2.15.1. Red Hat 지식베이스 정보 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat 지식베이스는 Red Hat의 제품과 기술을 최대한 활용할 수 있도록 풍부한 콘텐츠를 제공합니다. Red Hat 지식베이스는 Red Hat 제품 설치, 설정 및 사용에 대한 기사, 제품 문서 및 동영상으로 구성되어 있습니다. 또한 알려진 문제에 대한 솔루션을 검색할 수 있으며, 간결한 근본 원인 설명 및 해결 단계를 제공합니다.
2.15.2. Red Hat 지원을 위한 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather CLI 명령을 사용하면 다음을 포함하여 디버깅 문제에 가장 필요할 것으로 예상되는 Kueue 인스턴스의 Red Hat 빌드에 대한 정보를 수집할 수 있습니다.
- 워크로드, 클러스터 대기열, 로컬 대기열, 리소스 플레이버, 승인 확인 및 해당 클러스터 리소스 정의(CRD)와 같은 Kueue 사용자 정의 리소스의 Red Hat 빌드
- 서비스
- endpoints[]
- 웹훅 구성
-
openshift-kueue-operator네임스페이스 및kueue-controller-manager포드의 로그
수집된 데이터는 기본적으로 현재 작업 디렉토리의 must-gather/ 라는 새 디렉토리에 기록됩니다.
사전 요구 사항
- Kueue Operator의 Red Hat 빌드가 클러스터에 설치되었습니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다.
프로세스
-
must-gather데이터를 저장하려는 디렉터리로 이동합니다. 다음 명령을 실행하여
반드시 수집해야 할데이터를 수집합니다.$ oc adm must-gather \ --image=registry.redhat.io/kueue/kueue-must-gather-rhel9:<version>여기서
<버전>은 Kueue의 Red Hat 빌드의 현재 버전입니다.-
작업 디렉토리에서 생성된
must-gather디렉토리에서 압축 파일을 만듭니다. 고유한필수 수집데이터에 대한 날짜와 클러스터 ID를 제공해야 합니다. 클러스터 ID를 찾는 방법에 대한 자세한 내용은 OpenShift 클러스터에서 클러스터 ID 또는 이름을 찾는 방법을 참조하세요. - 압축 파일을 Red Hat 고객 포털 의 고객 지원 페이지의 지원 케이스에 첨부합니다.
3장. 리더 작업자 세트 운영자 링크 복사링크가 클립보드에 복사되었습니다!
3.1. 리더 워커 세트 운영자 개요 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 사용하여 다중 노드 AI/ML 추론 배포를 효율적으로 관리하세요. 리더 워커 세트 오퍼레이터는 대규모 워크로드에 대한 확장, 복구 및 업데이트를 단순화하기 위해 파드 그룹을 하나의 단위로 처리합니다.
AI/ML 추론을 위해 대규모 언어 모델(LLM)을 사용하려면 상당한 컴퓨팅 리소스가 필요한 경우가 많으며, 일반적으로 작업 부하를 여러 노드에 분산해야 합니다. 이로 인해 배포가 복잡해지고 확장, 장애 복구, 효율적인 포드 배치와 관련된 문제가 발생할 수 있습니다.
리더 워커 세트 오퍼레이터는 포드 그룹을 하나의 조정된 단위로 처리하여 이러한 다중 노드 배포를 간소화합니다. 그룹 내 각 포드의 수명 주기를 관리하고, 전체 그룹을 확장하고, 일관성을 보장하기 위해 그룹 수준에서 업데이트와 장애 복구를 수행합니다.
3.1.1. 리더 워커 세트 연산자에 관하여 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 사용하여 Pod 그룹을 단일 관리 단위로 배포할 수 있습니다. 이를 통해 분할된 대규모 언어 모델(LLM)과 같은 대규모 AI/ML 추론 워크로드를 배포할 수 있습니다.
LeaderWorkerSet Operator는 LeaderWorkerSet 오픈 소스 프로젝트를 기반으로 합니다. LeaderWorkerSet 은 포드 그룹을 하나의 단위로 배포하는 데 사용할 수 있는 맞춤형 Kubernetes API입니다. 이 기능은 대규모 언어 모델(LLM)이 여러 노드에 분산되어 있는 인공 지능(AI) 및 머신 러닝(ML) 추론 워크로드에 유용합니다.
LeaderWorkerSet API를 사용하면 포드가 하나의 리더와 여러 워커로 구성된 단위로 그룹화되며, 모두 단일 엔터티로 함께 관리됩니다. 그룹 내의 각 포드는 고유한 포드 정체성을 갖습니다. 그룹 내의 포드는 병렬로 생성되며 동일한 수명 주기 단계를 공유합니다. 롤아웃, 롤링 업데이트, 포드 장애 재시작은 그룹으로 수행됩니다.
LeaderWorkerSet 구성에서는 그룹 크기와 그룹 복제본 수를 정의합니다. 필요한 경우 리더 및 작업자 포드에 대해 별도의 템플릿을 정의하여 역할별로 사용자 정의할 수 있습니다. 또한 토폴로지 인식 배치를 구성하여 동일 그룹의 포드가 동일한 토폴로지에 함께 배치되도록 할 수도 있습니다.
Leader Worker Set Operator를 설치하기 전에 먼저 Red Hat OpenShift용 cert-manager Operator를 설치해야 합니다. 이는 서비스를 구성하고 메트릭 수집을 관리하는 데 필요하기 때문입니다.
OpenShift Container Platform에서는 Prometheus를 통해 Leader Worker Set Operator에 대한 모니터링이 기본적으로 제공됩니다.
3.1.1.1. LeaderWorkerSet 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
LeaderWorkerSet 아키텍처를 검토하여 LeaderWorkerSet API가 어떻게 파드 그룹을 하나의 단위로 구성하고, 하나의 파드를 리더로, 나머지를 워커로 하여 분산 워크로드를 조정하는지 알아보세요.
다음 다이어그램은 LeaderWorkerSet 아키텍처를 설명합니다.
그림 3.1. 리더 워커 세트 아키텍처
LeaderWorkerSet API는 리더 상태 집합을 사용하여 포드 그룹의 배포 및 수명 주기를 관리합니다. 정의된 각 복제본에 대해 리더-워커 그룹이 생성됩니다.
각 리더-워커 그룹에는 리더 포드와 워커 상태 집합이 포함됩니다. 워커 상태 집합은 리더 포드가 소유하고 해당 리더 포드와 연관된 워커 포드 집합을 관리합니다. 지정된 크기는 각 리더-워커 그룹의 총 포드 수를 정의하며, 리더 포드도 해당 숫자에 포함됩니다.
3.2. 리더 워커 세트 운영자 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator 릴리스 노트를 검토하여 개발 과정을 추적하고 각 릴리스에서 새롭게 추가되거나 변경된 사항을 확인하십시오.
Leader Worker Set Operator를 사용하면 분산 추론 워크로드를 관리하고 대규모 추론 요청을 효율적으로 처리할 수 있습니다.
이 릴리스 노트는 Leader Worker Set Operator의 개발 과정을 추적합니다.
자세한 내용은 리더 워커 세트 연산자에 대한 정보를 참조하세요.
3.2.1. Leader Worker Set Operator 1.0.0 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator 1.0.0 릴리스 노트를 검토하여 이번 릴리스의 새로운 기능과 업데이트 사항을 확인하십시오.
출시 날짜: 2024년 9월 3일
Leader Worker Set Operator 1.0.0에 대한 다음 권고 사항이 제공됩니다.
3.2.1.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 이는 Leader Worker Set Operator의 최초 릴리스입니다.
3.3. Leader Worker Set Operator를 사용하여 분산 작업 부하 관리 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 사용하면 분산 추론 워크로드를 관리하고 대규모 추론 요청을 효율적으로 처리할 수 있습니다.
3.3.1. 리더 워커 세트 오퍼레이터 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 통해 Leader Worker Set Operator를 설치하면 분산 AI 워크로드 관리를 시작할 수 있습니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- cert-manager Operator for Red Hat OpenShift 1.14.0 이상을 설치했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Red Hat OpenShift용 cert-manager Operator가 설치되었는지 확인하세요.
리더 워커 세트 오퍼레이터를 설치합니다.
- Operators → OperatorHub로 이동합니다.
- 필터 상자에 Leader Worker Set Operator를 입력합니다.
- Leader Worker Set Operator를 선택하고 설치를 클릭합니다.
Operator 설치 페이지에서 다음을 수행합니다.
- 업데이트 채널은 stable-v1.0 으로 설정되어 Leader Worker Set Operator 1.0의 최신 안정 릴리스가 설치됩니다.
- 설치 모드에서 클러스터의 특정 네임스페이스를 선택합니다.
- 설치된 네임스페이스 에서 운영자가 권장하는 네임스페이스: openshift-lws-operator를 선택합니다.
업데이트 승인 에서 다음 업데이트 전략 중 하나를 선택하세요.
- 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
- 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
- 설치를 클릭합니다.
Leader Worker Set Operator에 대한 사용자 정의 리소스(CR)를 만듭니다.
- 설치된 운영자 → 리더 작업자 설정 운영자 로 이동합니다.
- 제공된 API 에서 LeaderWorkerSetOperator 창에서 인스턴스 만들기를 클릭합니다.
- 생성을 클릭합니다.
3.3.2. 리더 워커 세트 배치 링크 복사링크가 클립보드에 복사되었습니다!
Leader Worker Set Operator를 사용하면 노드 간에 분산된 작업 부하를 관리하는 데 도움이 되는 리더 워커 세트를 배포할 수 있습니다.
사전 요구 사항
- Leader Worker Set Operator를 설치했습니다.
프로세스
다음 명령을 실행하여 새 프로젝트를 만듭니다.
$ oc new-project my-namespaceleader-worker-set.yaml이라는 파일을 만듭니다.apiVersion: leaderworkerset.x-k8s.io/v1 kind: LeaderWorkerSet metadata: generation: 1 name: my-lws namespace: my-namespace spec: leaderWorkerTemplate: leaderTemplate: metadata: {} spec: containers: - image: nginxinc/nginx-unprivileged:1.27 name: leader resources: {} restartPolicy: RecreateGroupOnPodRestart size: 3 workerTemplate: metadata: {} spec: containers: - image: nginxinc/nginx-unprivileged:1.27 name: worker ports: - containerPort: 8080 protocol: TCP resources: {} networkConfig: subdomainPolicy: Shared replicas: 2 rolloutStrategy: rollingUpdateConfiguration: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate startupPolicy: LeaderCreated다음과 같습니다.
metadata.name- 리더 워커 세트 리소스의 이름을 지정합니다.
metadata.namespace- 리더 워커 세트가 실행될 네임스페이스를 지정합니다.
spec.leaderWorkerTemplate.leaderTemplate- 리더 파드에 사용할 파드 템플릿을 지정합니다.
spec.leaderWorkerTemplate.restartPolicy-
포드 장애 발생 시 재시작 정책을 지정합니다. 허용되는 값은 전체 그룹을 다시 시작하는
RecreateGroupOnPodRestart이고, 그룹을 다시 시작하지 않는None입니다. spec.leaderWorkerTemplate.size-
리더 파드를 포함하여 각 그룹에 대해 생성할 파드의 수를 지정합니다. 예를 들어, 값이
3이면 리더 포드 1개와 워커 포드 2개가 생성됩니다. 기본값은1입니다. spec.leaderWorkerTemplate.workerTemplate- 워커 파드에 사용할 파드 템플릿을 지정합니다.
spec.networkConfig.subdomainPolicy-
헤드리스 서비스를 생성할 때 사용할 정책을 지정합니다. 허용되는 값은
UniquePerReplica또는Shared입니다. 기본값은공유입니다. spec.replicas-
복제본 또는 리더-워커 그룹의 수를 지정합니다. 기본값은
1입니다. spec.rolloutStrategy.rollingUpdateConfiguration.maxSurge-
롤링 업데이트 중에
replicas값보다 더 많이 예약될 수 있는 최대 복제본 수를 지정합니다. 값은 정수나 백분율로 지정할 수 있습니다.
구성 가능한 모든 필드에 대한 자세한 내용은 LeaderWorkerSet API 업스트림 문서를 참조하세요.
다음 명령을 실행하여 리더 워커 세트 구성을 적용합니다.
$ oc apply -f leader-worker-set.yaml
검증
다음 명령을 실행하여 포드가 생성되었는지 확인하세요.
$ oc get pods -n my-namespace출력 예
NAME READY STATUS RESTARTS AGE my-lws-0 1/1 Running 0 4s my-lws-0-1 1/1 Running 0 3s my-lws-0-2 1/1 Running 0 3s my-lws-1 1/1 Running 0 7s my-lws-1-1 1/1 Running 0 6s my-lws-1-2 1/1 Running 0 6s-
my-lws-0은 첫 번째 그룹의 리더 포드입니다. -
my-lws-1은 두 번째 그룹의 리더 포드입니다.
-
다음 명령을 실행하여 상태 저장 세트를 검토하세요.
$ oc get statefulsets출력 예
NAME READY AGE my-lws 4/4 111s my-lws-0 2/2 57s my-lws-1 2/2 60s-
my-lws는 모든 리더-워커 그룹에 대한 리더 상태 저장 집합입니다. -
my-lws-0은 첫 번째 그룹에 대한 워커 상태 저장 세트입니다. -
my-lws-1은 두 번째 그룹에 대한 워커 상태 저장 세트입니다.
-
3.4. Leader Worker Set Operator 제거 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 리더 워커 세트 오퍼레이터가 더 이상 필요하지 않은 경우 오퍼레이터를 제거하고 관련 리소스를 삭제할 수 있습니다.
3.4.1. Leader Worker Set Operator 제거 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 더 이상 오퍼레이터가 필요하지 않은 경우 웹 콘솔을 사용하여 리더 워커 세트 오퍼레이터를 제거할 수 있습니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- Leader Worker Set Operator를 설치했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Operators → 설치된 Operator로 이동합니다.
-
프로젝트 드롭다운 목록에서
openshift-lws-operator를선택합니다. LeaderWorkerSetOperator인스턴스를 삭제합니다.- LeaderWorkerSetOperator를 클릭하고 LeaderWorkerSetOperator 탭을 선택합니다.
-
클러스터 항목 옆에 있는 옵션 메뉴
를 클릭하고 LeaderWorkerSetOperator 삭제 를 선택합니다.
- 확인 대화 상자에서 삭제를 클릭합니다.
Leader Worker Set Operator를 제거합니다.
- Operators → 설치된 Operator로 이동합니다.
-
Leader Worker Set Operator 항목 옆에 있는 옵션 메뉴
를 클릭하고 Operator 설치 제거를 클릭합니다.
- 확인 대화 상자에서 설치 제거를 클릭합니다.
3.4.2. Leader Worker Set Operator 리소스 제거 링크 복사링크가 클립보드에 복사되었습니다!
선택적으로, 리더 워커 세트 운영자를 제거한 후 사용자 지정 리소스(CR) 및 관련 네임스페이스를 제거할 수 있습니다. 이렇게 하면 남아있는 모든 리더 워커 세트 아티팩트가 정리됩니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- Leader Worker Set Operator를 제거했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
Leader Worker Set Operator가 설치될 때 생성된 CRD를 제거합니다.
- 관리 → 클러스터 리소스 정의로 이동합니다.
-
CRD를 필터링하려면 이름 필드에
LeaderWorkerSetOperator를입력합니다. -
LeaderWorkerSetOperator CRD 옆에 있는 옵션 메뉴
를 클릭하고 CustomResourceDefinition 삭제 를 선택합니다.
- 확인 대화 상자에서 삭제를 클릭합니다.
openshift-lws-operator네임스페이스를 삭제합니다.- 관리 → 네임스페이스로 이동합니다.
-
필터 상자에
openshift-lws-operator를입력합니다. -
openshift-lws-operator 항목 옆에 있는 옵션 메뉴
를 클릭하고 네임스페이스 삭제 를 선택합니다.
-
확인 대화 상자에
openshift-lws-operator를입력하고 삭제를 클릭합니다.
4장. JobSet Operator 링크 복사링크가 클립보드에 복사되었습니다!
4.1. JobSet Operator 개요 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 JobSet Operator를 사용하여 HPC(고성능 컴퓨팅) 및 AI 교육과 같은 대규모 조정된 워크로드를 관리하고 실행합니다. 다중 템플릿 작업 지원 및 안정적인 네트워킹과 같은 기능을 통해 신속하게 복구하고 리소스를 효율적으로 사용할 수 있습니다.
4.1.1. JobSet 연산자에 대하여 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform의 JobSet Operator를 사용하면 고성능 컴퓨팅(HPC)이나 인공 지능(AI) 교육과 같은 대규모의 분산되고 조정된 컴퓨팅 워크로드를 관리하고 자동 안정성, 조정 및 장애 복구를 얻을 수 있습니다.
JobSet Operator는 JobSet 오픈 소스 프로젝트를 기반으로 합니다.
JobSet Operator는 여러 작업 그룹을 하나의 조정된 단위로 관리하도록 설계되었습니다. 이 기능은 HPC나 대규모 AI 모델을 훈련하는 분야에서 특히 유용합니다. 이 분야에서는 여러 대의 머신을 몇 시간 또는 며칠 동안 실행해야 합니다.
JobSet 연산자를 사용하면 표준 OpenShift Container Platform 작업으로는 너무 크거나 복잡한 문제를 해결할 수 있습니다. JobSet Operator는 조정, 안정성, 복구를 제공합니다.
JobSet Operator는 IP 주소를 얻기 위해 안정적인 헤드리스 서비스를 자동으로 설정하여, 장애 발생 후 재시작 후에도 작업자가 서로를 찾아 통신할 수 있도록 합니다. 또한 자동적인 장애 복구 기능을 제공합니다. 대규모 훈련 작업의 작은 부분 하나가 실패하면, 운영자는 저장된 체크포인트에서 전체 작업자 그룹을 다시 시작하도록 구성할 수 있습니다. 이렇게 하면 시간과 컴퓨팅 비용이 절약됩니다.
JobSet Operator는 시작 제어 기능을 제공하여 종속성이 충족되도록 특정 시작 순서를 정의할 수 있습니다. 예를 들어, 작업자가 연결을 시도하기 전에 리더가 실행 중인지 확인합니다.
JobSet Operator를 사용하면 OpenShift Container Platform에서 대규모의 분산되고 조정된 컴퓨팅 작업을 보다 쉽게 관리할 수 있으며, 여러 개별 구성 요소를 하나의 탄력적이고 관리하기 쉬운 시스템으로 전환할 수 있습니다.
4.2. JobSet Operator 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 조정된 대규모 컴퓨팅 워크로드를 관리하는 JobSet Operator에 대한 개발, 기능 및 수정 사항을 추적합니다.
자세한 내용은 JobSet 연산자 정보를 참조하세요.
4.2.1. JobSet Operator 1.0 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
JobSet Operator 1.0의 초기 릴리스에 대한 새로운 기능 및 권고를 검토하십시오.
출시 날짜: 2026년 2월 12일
JobSet Operator 1.0에 다음 권고를 사용할 수 있습니다.
4.2.1.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 이는 JobSet Operator의 초기 사용 가능 릴리스입니다.
4.3. JobSet Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에 JobSet Operator를 설치하면 대규모의 조정된 컴퓨팅 워크로드를 관리하고 애플리케이션에 통합 API와 장애 복구 기능을 제공할 수 있습니다.
4.3.1. JobSet Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔을 사용하여 OpenShift Container Platform에 JobSet Operator를 설치하여 대규모의 조정된 컴퓨팅 작업 부하를 관리하기 시작합니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- cert-manager Operator for Red Hat OpenShift 1.14.0 이상을 설치했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Red Hat OpenShift용 cert-manager Operator가 설치되었는지 확인하세요.
JobSet Operator를 설치합니다.
- 생태계 → 소프트웨어 카탈로그 로 이동합니다.
-
openshift-operators프로젝트를 검색하여 선택하세요. - 필터 상자에 JobSet Operator를 입력합니다.
- JobSet Operator를 선택하고 설치를 클릭합니다.
Operator 설치 페이지에서 다음을 수행합니다.
- Update 채널은 JobSet Operator의 안정적인 최신 릴리스를 설치하는 stable-v1.0 으로 설정됩니다.
- 설치 모드에서 클러스터의 특정 네임스페이스를 선택합니다.
- 설치된 네임스페이스 에서 운영자가 권장하는 네임스페이스인 openshift-jobset-operator를 선택합니다.
업데이트 승인 에서 다음 업데이트 전략 중 하나를 선택하세요.
- 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
- 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
- 설치를 클릭합니다.
JobSet Operator에 대한 사용자 정의 리소스(CR)를 만듭니다.
- 설치된 운영자 → JobSet 운영자 로 이동합니다.
- 제공된 API 에서 JobSetOperator 창에서 인스턴스 만들기를 클릭합니다.
- 이름을 cluster 로 설정합니다.
- managementState를 Managed 로 설정합니다.
- 생성을 클릭합니다.
검증
다음 명령을 입력하여 JobSet Operator와 피연산자 포드가 실행 중인지 확인하세요.
$ oc get pod -n openshift-jobset-operator출력 예
NAME READY STATUS RESTARTS AGE jobset-controller-manager-5595547fb-b4g2x 1/1 Running 0 48s jobset-operator-596cb848c6-q2dmp 1/1 Running 0 2m33s
4.4. JobSet Operator를 사용하여 워크로드 관리 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 JobSet Operator를 사용하여 HPC(고성능 컴퓨팅) 및 AI 교육과 같은 대규모 조정된 워크로드를 관리하고 실행합니다. 다중 템플릿 작업 지원 및 안정적인 네트워킹과 같은 기능을 통해 신속하게 복구하고 리소스를 효율적으로 사용할 수 있습니다.
4.4.1. JobSet 배포 링크 복사링크가 클립보드에 복사되었습니다!
JobSet Operator를 사용하여 JobSet을 배포하여 대규모의 조정된 워크로드를 관리하고 실행할 수 있습니다.
사전 요구 사항
- JobSet Operator를 설치했습니다.
- 사용 가능한 NVIDIA GPU가 있는 클러스터가 있어야 합니다.
프로세스
다음 명령을 실행하여 새 프로젝트를 만듭니다.
$ oc new-project <my_namespace>jobset.yaml이라는 파일을 생성합니다.apiVersion: jobset.x-k8s.io/v1alpha2 kind: JobSet metadata: name: pytorch spec: replicatedJobs: - name: workers template: spec: parallelism: <pods_running_number> completions: <pods_finish_number> backoffLimit: 0 template: spec: imagePullSecrets: - name: my-registry-secret initContainers: - name: prepare image: docker.io/alpine/git:v2.52.0 args: ['clone', 'https://github.com/pytorch/examples'] volumeMounts: - name: workdir mountPath: /git containers: - name: pytorch image: docker.io/pytorch/pytorch:2.10.0-cuda13.0-cudnn9-runtime resources: limits: nvidia.com/gpu: "1" requests: nvidia.com/gpu: "1" ports: - containerPort: 4321 env: - name: MASTER_ADDR value: "pytorch-workers-0-0.pytorch" - name: MASTER_PORT value: "4321" - name: RANK valueFrom: fieldRef: fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] - name: PYTHONUNBUFFERED value: "0" command: - /bin/sh - -c - | cd examples/distributed/ddp-tutorial-series torchrun --nproc_per_node=1 --nnodes=3 --rdzv_id=100 --rdzv_backend=c10d --rdzv_endpoint=$MASTER_ADDR:$MASTER_PORT multinode.py 1000 100 volumeMounts: - name: workdir mountPath: /workspace volumes: - name: workdir emptyDir: {}다음과 같습니다.
<pods_running_number>- 동시에 실행되는 Pod 수를 지정합니다.
<pods_finish_number>- 작업을 완료하려면 성공적으로 완료해야 하는 총 Pod 수를 지정합니다.
다음 명령을 실행하여 JobSet 구성을 적용합니다.
$ oc apply -f jobset.yaml
검증
다음 명령을 실행하여 Pod가 시작되었는지 확인합니다.
$ oc get pods -n <my_namespace>출력 예
NAME READY STATUS RESTARTS AGE pytorch-workers-0-0-2lzwt 1/1 Running 0 2m17s pytorch-workers-0-1-g2lrv 1/1 Running 0 2m17s pytorch-workers-0-2-dpljq 1/1 Running 0 2m17s
4.4.2. JobSet 코디네이터 지정 링크 복사링크가 클립보드에 복사되었습니다!
JobSet Pod 간의 통신을 관리하려면 특정 JobSet 코디네이터 Pod를 할당할 수 있습니다. 이렇게 하면 분산 워크로드가 작업 동기화 및 데이터 교환에 대한 중앙 조정 지점으로 안정적인 네트워크 끝점을 참조할 수 있습니다.
사전 요구 사항
- JobSet Operator를 설치했습니다.
프로세스
다음 명령을 실행하여 새 네임스페이스를 생성합니다.
$ oc new-project <new_namespace>jobset-coordinator.yaml이라는 YAML 파일을 생성합니다.YAML 파일의 예
apiVersion: jobset.x-k8s.io/v1alpha2 kind: JobSet metadata: name: coordinator spec: coordinator: replicatedJob: driver jobIndex: 0 podIndex: 0 replicatedJobs: - name: workers template: spec: parallelism: <pods_running_number> completions: <pods_finish_number> backoffLimit: 0 template: spec: containers: - name: worker env: - name: COORDINATOR_ENDPOINT valueFrom: fieldRef: fieldPath: metadata.labels['jobset.sigs.k8s.io/coordinator'] image: quay.io/nginx/nginx-unprivileged:1.29-alpine command: [ "/bin/sh", "-c" ] args: - | while ! curl -s "${COORDINATOR_ENDPOINT}:8080" | grep Welcome; do sleep 3 done sleep 100 - name: driver template: spec: parallelism: <pods_running_number> completions: <pods_finish_number> backoffLimit: 0 template: spec: containers: - name: driver image: quay.io/nginx/nginx-unprivileged:1.29-alpine ports: - containerPort: 8080 protocol: TCP다음과 같습니다.
<pods_running_number>- 동시에 실행되는 Pod 수를 지정합니다.
<pods_finish_number>- 작업을 완료하려면 성공적으로 완료해야 하는 총 Pod 수를 지정합니다.
다음 명령을 실행하여
jobset-coordinator.yaml파일을 적용합니다.$ oc apply -f jobset-coordinator.yaml
검증
다음 명령을 실행하여 포드가 생성되었는지 확인하세요.
$ oc get pods -n <new_namespace>출력 예
NAME READY STATUS RESTARTS AGE coordinator-driver-0-0-svgk7 1/1 Running 0 67s coordinator-workers-0-0-57jvg 1/1 Running 0 67s coordinator-workers-0-1-mghvx 1/1 Running 0 67s coordinator-workers-0-2-7cnvv 1/1 Running 0 67s
4.4.3. JobSet Operator의 실패 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
하위 작업 실패에 대한 응답으로 워크로드 동작을 제어하려면 JobSet 실패 정책을 구성할 수 있습니다. 이를 통해 실패 이유 또는 영향을 받는 특정 복제 작업에 따라 전체 JobSet을 다시 시작하거나 실패와 같은 특정 작업을 정의할 수 있습니다.
4.4.3.1. 실패 정책 작업 링크 복사링크가 클립보드에 복사되었습니다!
작업 실패가 정의된 규칙과 일치하는 경우 이러한 작업을 사용할 수 있습니다.
| 동작 | 설명 |
|---|---|
|
| 전체 JobSet을 즉시 실패로 표시합니다. |
|
|
모든 하위 작업을 다시 생성하여 JobSet을 다시 시작합니다. 이 작업은 |
|
|
|
4.4.3.2. rule-targeting 속성 링크 복사링크가 클립보드에 복사되었습니다!
다음 속성을 사용하여 실패 규칙을 정의합니다.
| 속성 | 설명 |
|---|---|
|
| 규칙을 트리거하는 복제된 작업을 지정합니다. |
|
|
특정 작업 실패 이유를 기반으로 규칙을 트리거합니다. 유효한 값에는 |
4.4.3.3. 구성 예 링크 복사링크가 클립보드에 복사되었습니다!
이 구성은 리더 작업이 실패하면 JobSet을 실패로 표시합니다.
리더가 실패하면 작업 세트를 표시하는 YAML 파일의 예
apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
name: failjobset-action-example
spec:
failurePolicy:
maxRestarts: 3
rules:
- action: FailJobSet
targetReplicatedJobs:
- leader
replicatedJobs:
- name: leader
replicas: 1
template:
spec:
backoffLimit: 0
completions: 2
parallelism: 2
template:
spec:
containers:
- name: leader
image: docker.io/bash:latest
command:
- bash
- -xc
- |
echo "JOB_COMPLETION_INDEX=$JOB_COMPLETION_INDEX"
if [[ "$JOB_COMPLETION_INDEX" == "0" ]]; then
for i in $(seq 10 -1 1)
do
echo "Sleeping in $i"
sleep 1
done
exit 1
fi
for i in $(seq 1 1000)
do
echo "$i"
sleep 1
done
- name: workers
replicas: 1
template:
spec:
backoffLimit: 0
completions: 2
parallelism: 2
template:
spec:
containers:
- name: worker
image: docker.io/bash:latest
command:
- bash
- -xc
- |
sleep 1000
4.4.4. JobSet Operator에 대한 볼륨 클레임 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
여러 복제 작업에서 공유 PVC(영구 볼륨 클레임)를 자동으로 생성하고 관리하도록 JobSet을 구성할 수 있습니다. 이 기능은 데이터 세트, 모델 또는 체크포인트에 대한 공유 액세스 권한이 필요한 워크로드에 유용합니다.
사전 요구 사항
- 클러스터에 JobSet Operator가 설치되어 있어야 합니다.
- 기본 스토리지 클래스를 설정하거나 워크로드에 대한 스토리지 클래스를 선택했습니다.
프로세스
JobSet YAML 파일의
spec.volumeClaimPolicies섹션에 볼륨 템플릿을 정의합니다.apiVersion: jobset.x-k8s.io/v1alpha2 kind: JobSet metadata: name: <job_name> spec: volumeClaimPolicies: - templates: - metadata: name: <persistent_volume_claim_name_prefix> spec: accessModes: ["ReadWriteOnce"] storageClassName: mystorageclass resources: requests: storage: 1Gi retentionPolicy: whenDeleted: Retain다음과 같습니다.
<job_name>- 네임스페이스 내의 작업에 대한 고유 식별자를 지정합니다.
<persistent_volume_claim_name>-
PVC의 이름을 지정합니다. 여기에 사용된 이름은
volumeMounts이름으로도 사용됩니다. <persistent_volume_claim_name>-<job_name> 형식으로 이름으로 생성된 PVC를 마운트하는 Pod에 볼륨이자동으로 추가됩니다. <deletion_retention_policy>-
삭제 보존 정책을 지정합니다. 선택적으로 이 값을
Retain으로 설정하여 JobSet을 삭제한 후 데이터를 유지할 수 있습니다.
replicatedJobs구성에서 사용자가 정의한 템플릿 이름과 일치하는volumeMount를 추가합니다.apiVersion: jobset.x-k8s.io/v1alpha2 kind: JobSet metadata: name: <job_name> spec: replicatedJobs: - name: workers template: spec: parallelism: 2 completions: 2 backoffLimit: 0 template: spec: imagePullSecrets: - name: my-registry-secret initContainers: - name: prepare image: docker.io/alpine/git:v2.52.0 args: ['clone', 'https://github.com/pytorch/examples'] volumeMounts: - name: <persistent_volume_claim_name> mountPath: /git/checkpoint #...다음 명령을 실행하여 JobSet 구성을 적용합니다.
$ oc apply -f <jobset_yaml>
검증
이름 지정 규칙 <
claim_name>-<jobset_name>을 사용하여 PVC가 생성되었는지 확인합니다.$ oc get pvc출력 예
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE pvc-1 Bound pvc-385996a0-70af-4791-aa8e-9e6459e6b123 3Gi RWO file-storage 3d pvc-2 Bound pvc-8aeddd4d-aad5-4039-8d04-640a71c9a72d 12Gi RWO file-storage 3d pvc-3 Bound pvc-0050144d-940c-4c4e-a23a-2a660a5490eb 12Gi RWO file-storage 3d
4.5. JobSet Operator 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 클러스터에서 Operator 인스턴스 및 해당 리소스를 제거하여 JobSet Operator를 설치 제거합니다.
4.5.1. JobSet Operator 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 Operator 인스턴스를 제거하여 JobSet Operator를 설치 제거합니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- JobSet Operator를 설치했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Operators → 설치된 Operator로 이동합니다.
-
프로젝트 드롭다운 목록에서
openshift-js-operator를 선택합니다. JobSetOperator인스턴스를 삭제합니다.- JobSet Operator 를 클릭하고 JobSetOperator 탭을 선택합니다.
-
클러스터 항목 옆에 있는 옵션 메뉴
를 클릭하고 JobSetOperator 삭제 를 선택합니다.
- 확인 대화 상자에서 삭제를 클릭합니다.
JobSet Operator를 설치 제거합니다.
- Operators → 설치된 Operator로 이동합니다.
-
JobSet Operator 항목 옆에 있는 옵션 메뉴
를 클릭하고 Operator 설치 제거를 클릭합니다.
- 확인 대화 상자에서 설치 제거를 클릭합니다.
4.5.2. JobSet Operator 리소스 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
필요한 경우 JobSet Operator를 설치 제거한 후 클러스터에서 관련 리소스를 제거할 수 있습니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
- JobSet Operator를 설치 제거했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
JobSet Operator가 설치될 때 생성된 CRD를 제거합니다.
- 관리 → 클러스터 리소스 정의로 이동합니다.
-
Name 필드에
JobSetOperator를 입력하여 CRD를 필터링합니다. -
JobSetOperator CRD 옆에 있는 옵션 메뉴
를 클릭하고 CustomResourceDefinition 삭제 를 선택합니다.
- 확인 대화 상자에서 삭제를 클릭합니다.
openshift-jobset-operator네임스페이스를 삭제합니다.- 관리 → 네임스페이스로 이동합니다.
-
네임스페이스 목록에서 fine
openshift-jobset-operator -
openshift-jobset-operator 항목 옆에 있는 옵션 메뉴
를 클릭하고 네임스페이스 삭제 를 선택합니다.
-
확인 대화 상자에서
openshift-jobset-operator를 입력하고 삭제 를 클릭합니다.