Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

7장. 확인된 문제

이 섹션에서는 Red Hat OpenShift AI 2.25의 알려진 문제와 이러한 문제를 해결하는 알려진 방법에 대해 설명합니다.

RHAIENG-1139 - 여러 네임스페이스에서 동일한 이름으로 L#187aStackDistribution을 배포할 수 없습니다

다른 네임 스페이스에서 동일한 이름으로 두 개의 L#178a StackDistribution 리소스를 생성하면 두 번째 리소스의 ReplicaSet이 L appreciatea Stack Pod를 시작하지 못합니다. 네임스페이스 간에 중복 이름을 사용하는 경우 L#178a Stack Operator는 보안 제약 조건을 올바르게 할당하지 않습니다.

해결방법
모든 네임스페이스에서 각 L#178a StackDistribution 에 고유한 이름을 사용합니다. 예를 들어 프로젝트 이름을 포함하거나 llama-stack-distribution-209342 와 같은 접미사를 추가합니다.

RHAIENG-1624 - 연결이 끊긴 클러스터에서 API 시간 초과 포함

연결이 끊긴 클러스터에서 포함된 기본 포함 모델(기본 포함 모델ibm-granite/granite-embedding-125m-english)을 사용할 때 포함 API 호출이 시간 초과될 수 있습니다.

해결방법

L#178a StackDistribution 사용자 정의 리소스에 다음 환경 변수를 추가하여 포함된 모델을 오프라인으로 사용합니다. 

- name: SENTENCE_TRANSFORMERS_HOME
  value: /opt/app-root/src/.cache/huggingface/hub
- name: HF_HUB_OFFLINE
  value: "1"
- name: TRANSFORMERS_OFFLINE
  value: "1"
- name: HF_DATASETS_OFFLINE
  value: "1"

RHOAIENG-34923 - hapyterLab에서 파이프라인을 실행할 때 런타임 구성이 누락됨

프로젝트의 첫 번째 활성 워크벤치의 파이프라인을 실행할 때 Elyra 파이프라인 편집기에 런타임 구성이 표시되지 않을 수 있습니다. 이는 초기 워크벤치 세션에 대한 구성이 채워지지 않았기 때문에 발생합니다.

해결방법
워크벤치를 다시 시작합니다. 다시 시작한 후 파이프라인 실행에 런타임 구성을 사용할 수 있게 됩니다.

RHAIENG-35055 - OpenShift AI 2.24에서 업그레이드한 후 모델 카탈로그가 초기화되지 않음

OpenShift AI 2.24에서 업그레이드한 후 모델 카탈로그를 초기화 및 로드하지 못할 수 있습니다. OpenShift AI 대시보드에는 모델 카탈로그 오류에 대한 요청 액세스 권한이 표시됩니다.

해결방법

다음 명령을 실행하여 기존 모델 카탈로그 ConfigMap 및 배포를 삭제합니다. 

$ oc delete configmap model-catalog-sources -n rhoai-model-registries --ignore-not-found
$ oc delete deployment model-catalog -n rhoai-model-registries --ignore-not-found

RHAIENG-35529 - 외부 Argo 워크플로우를 사용할 때 Data Science Pipelines Operator의 조정 문제

기존 외부 Argo 워크플로우 설치를 삭제하기 전에 포함된 Argo Workflows 컨트롤러(argoWorkflowsControllers: Managed)를 활성화하면 워크플로우 컨트롤러가 시작되지 않고 DSPO(Data Science Pipelines Operator)에서 사용자 정의 리소스를 올바르게 조정하지 못할 수 있습니다.

해결방법
포함된 Argo Workflows 컨트롤러를 활성화하기 전에 클러스터에서 기존 외부 Argo Workflows 인스턴스를 삭제합니다.

RHAIENG-36756 - 연결이 없는 경우 모델 배포 중에 기존 클러스터 스토리지 옵션이 누락됨

정의된 데이터 연결 없이 프로젝트에서 모델 배포를 생성할 때 PVC(영구 볼륨 클레임)를 사용할 수 있는 경우에도 기존 클러스터 스토리지 옵션이 표시되지 않습니다. 따라서 모델 스토리지에 대한 기존 PVC를 선택할 수 없습니다.

해결방법
프로젝트에 하나 이상의 유형 URI 연결을 생성합니다. 그런 다음 기존 클러스터 스토리지 옵션을 사용할 수 있게 됩니다.

RHOAIENG-36817 - 모델 서버 크기가 small으로 설정된 경우 Inference 서버가 실패합니다.

대시보드를 통해 유추 서비스를 생성할 때 작은 모델 서버 크기를 선택하면 후속 유추 요청이 실패합니다. 결과적으로 유추 서비스 자체의 배포가 성공하지만 추론 요청은 시간 초과 오류와 함께 실패합니다.

해결방법
이 문제를 해결하려면 드롭다운에서 모델 서버 크기를 선택합니다.

RHOAIENG-33995 - Phi 및 Mistral 모델에 대한 추론 서비스 배포 실패

openshift-container-platform 4.19가 있는 IBM Power 클러스터에서 vLLM 런타임을 사용하여 Phi 및 Mistral 모델에 대한 유추 서비스 생성은 CPU 백엔드와 관련된 오류로 인해 실패합니다. 결과적으로 이러한 모델의 배포가 영향을 받아 서비스 생성에 실패합니다.

해결방법
이 문제를 해결하려면 CPU 및 Phi 모델에 대해 활성화된 경우 제공 런타임에서 sliding_window 메커니즘을 비활성화합니다. Sliding 창은 현재 V1에서 지원되지 않습니다.

RHOAIENG-33795 - IBM Z의 Triton Inference Server에 대한 gRPC 엔드 포인트 확인에 필요한 수동 경로 생성

gRPC 끝점을 사용하여 Triton Inference 서버를 확인하는 경우 경로가 자동으로 생성되지 않습니다. 이는 Operator가 현재 기본적으로 REST에 대한 에지 종료 경로를 생성하기 때문에 발생합니다.

해결방법

이 문제를 해결하려면 IBM Z의 Triton Inference Server의 gRPC 끝점 확인에 수동 경로 생성이 필요합니다.

  1. 모델 배포 Pod가 실행 중이면 다음 콘텐츠를 사용하여 YAML 파일에 에지 종료 Route 오브젝트를 정의합니다. 

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: <grpc-route-name>                  # e.g. triton-grpc
  namespace: <model-deployment-namespace>  # namespace where your model is deployed
  labels:
    inferenceservice-name: <inference-service-name>
  annotations:
    haproxy.router.openshift.io/timeout: 30s
spec:
  host: <custom-hostname>                  # e.g. triton-grpc.<apps-domain>
  to:
    kind: Service
    name: <service-name>                   # name of the predictor service (e.g. triton-predictor)
    weight: 100
  port:
    targetPort: grpc                       # must match the gRPC port exposed by the service
  tls:
    termination: edge
  wildcardPolicy: None

  2. Route 오브젝트를 생성합니다. 

    oc apply -f <route-file-name>.yaml

  3. 유추 요청을 보내려면 다음 명령을 입력합니다. 

    grpcurl -cacert <ca_cert_file>\
    1 
    
  -protoset triton_desc.pb \
  -d '{
    "model_name": "<model_name>",
    "inputs": [
      {
        "name": "<input_tensor_name>",
        "shape": [<shape>],
        "datatype": "<data_type>",
        "contents": {
          "<datatype_specific_contents>": [<input_data_values>]
        }
      }
    ],
    "outputs": [
      {
        "name": "<output_tensor_name>"
      }
    ]
  }' \
  <grpc_route_host>:443 \
  inference.GRPCInferenceService/ModelInfer
    1
    <ca_cert_file>은 클러스터 라우터 CA 인증서의 경로입니다(예: router-ca.crt).
참고

<triton_protoset_file>은 protobuf 설명자 파일로 컴파일됩니다. protoc -I. --descriptor_set_out=triton_desc.pb --include_imports grpc_service.proto 로 생성할 수 있습니다.

triton-inference-service GitHub 페이지에서 grpc_service.proto 및 model_config.proto 파일을 다운로드합니다.

RHOAIENG-33697 - 상태가 "시작되지 않은 경우 모델을 편집하거나 삭제할 수 없음

NVIDIA NIM 또는 단일 모델 제공 플랫폼에 모델을 배포할 때 작업 메뉴의 편집 및 삭제 옵션은 시작 또는 보류 중 상태의 모델에 사용할 수 없습니다. 이러한 옵션은 모델이 성공적으로 배포된 후에만 사용할 수 있습니다.

해결방법
모델이 Started 상태가 될 때까지 기다린 후 모델을 변경하거나 삭제합니다.

RHOAIENG-33645 - LM-Eval Tier1 테스트 실패

이전 버전의 trustyai-service-operator 를 사용하는 경우 confirm_run_unsafe_code 가 인수로 전달되지 않기 때문에 LM-Eval Tier1 테스트에는 오류가 발생할 수 있습니다.

해결방법
최신 버전의 trustyai-service-operator 를 사용하고 AllowCodeExecution 가 활성화되어 있는지 확인합니다.

RHOAIENG-29729 - 업그레이드 후 재시작 루프에 모델 레지스트리 Operator

모델 레지스트리 구성 요소가 활성화된 상태에서 OpenShift AI 버전 2.22 이하에서 버전 2.23 이상으로 업그레이드한 후 모델 레지스트리 Operator가 재시작 루프에 들어갈 수 있습니다. 이는 model-registry-operator-controller-manager Pod의 관리자 컨테이너에 대한 메모리 제한이 부족하기 때문입니다.

해결방법

이 문제를 해결하려면 model-registry-operator-controller-manager 배포에 대한 조정을 트리거해야 합니다. 배포에 opendatahub.io/managed='true' 주석을 추가하면 이 작업이 수행되고 올바른 메모리 제한을 적용합니다. 다음 명령을 실행하여 주석을 추가할 수 있습니다. 

oc annotate deployment model-registry-operator-controller-manager -n redhat-ods-applications opendatahub.io/managed='true' --overwrite
참고

이 명령은 model-registry-operator-controller-manager 배포에서 사용자 지정 값을 덮어씁니다. 사용자 지정 배포 값에 대한 자세한 내용은 구성 요소 배포 리소스 사용자 지정을 참조하십시오.

배포가 업데이트되고 메모리 제한이 128Mi에서 256Mi로 증가하면 컨테이너 메모리 사용량이 안정화되고 재시작 루프가 중지됩니다.

RHOAIENG-31238 - DSCInitialization을 생성할 때 새로운 관찰 기능 스택 활성화

DSCInitialization 리소스를 제거하고 OpenShift AI 콘솔 양식 보기를 사용하여 새 리소스를 생성하면 기술 프리뷰 관찰 기능을 사용할 수 있습니다. 이로 인해 DSCInitialization 리소스를 다시 생성할 때 원하지 않는 관찰 기능이 배포됩니다.

해결방법

이 문제를 해결하려면 양식 보기를 사용하여 DSCInitiliazation 리소스를 다시 생성할 때 "metrics" 및 "traces" 필드를 수동으로 제거합니다.

기술 프리뷰 관찰 기능을 사용하려면 필요하지 않습니다.

RHOAIG-32145 - 4.17 이전 버전에서 L dismia Stack Operator 배포 실패

4.17 이전 버전을 실행하는 OpenShift 클러스터에 OpenShift AI를 설치할 때 통합 L declarationa Stack Operator(llamastackoperator)가 배포되지 않을 수 있습니다.

L#178a Stack Operator에는 Kubernetes 버전 1.32 이상이 필요하지만 OpenShift 4.15는 Kubernetes 1.28을 사용합니다. 이 버전 격차는 Kubernetes 1.32에 도입된 지원되지 않는 선택 가능한 필드로 인해 CRD(사용자 정의 리소스 정의)를 적용할 때 스키마 유효성 검사 실패가 발생할 수 있습니다.

해결방법
버전 4.17 이상을 실행하는 OpenShift 클러스터에 OpenShift AI를 설치합니다.

RHOAIENG-32242 - OpenShift 버전 4.15 및 4.16용 NetworkPolicies 생성 실패

버전 4.15 또는 4.16을 실행하는 OpenShift 클러스터에 OpenShift AI를 설치할 때 특정 NetworkPolicy 리소스의 배포가 실패할 수 있습니다. 이는 llamastackoperator 또는 관련 구성 요소가 redhat-ods-applications 와 같은 보호된 네임스페이스에서 NetworkPolicy 를 생성하려고 할 때 발생할 수 있습니다. 승인 Webhook networkpolicies-validation.managed.openshift.io 에서는 cluster-admin 사용자의 경우에도 특정 네임스페이스 및 리소스에 대한 수정을 제한할 수 있습니다. 이 제한은 자체 관리 및 Red Hat 관리 OpenShift 환경에 모두 적용할 수 있습니다.

해결방법
버전 4.17 이상을 실행하는 OpenShift 클러스터에 OpenShift AI를 배포합니다. Webhook 제한이 적용되는 클러스터의 경우 OpenShift 관리자 또는 Red Hat 지원팀에 문의하여 대체 배포 패턴을 확인하거나 영향을 받는 네임스페이스에 대한 승인된 변경 사항을 결정합니다.

RHOAIENG-32599 - IBM Z 클러스터에서 유추 서비스 생성 실패

IBM Z 클러스터에서 vLLM 런타임을 사용하여 유추 서비스를 생성하려고 하면 다음 오류와 함께 실패합니다. ValueError: 'aimv2'는 이미 Transformers 구성에서 사용 중인 다른 이름을 선택합니다.

해결방법
없음.

RHOAIG-29731 - OpenShift 4.19를 사용하는 IBM Power 클러스터에서 Inference 서비스 생성이 실패합니다.

OpenShift Container Platform 버전 4.19의 IBM Power 클러스터에서 vLLM 런타임을 사용하여 유추 서비스를 생성하려고 하면 NUMA(Non-Uniform Memory Access)와 관련된 오류로 인해 실패합니다.

해결방법
유추 서비스를 생성할 때 환경 변수 VLLM_CPU_OMP_THREADS_BIND 를 all 로 설정합니다.

RHOAIENG-292 - 사용 통계 디렉토리 액세스로 인해 IBM Z에서 권한 오류를 기록합니다.

IBM Z 아키텍처에서 vLLM을 실행하면 유추 서비스가 성공적으로 시작되지만 사용량 통계 보고와 관련된 백그라운드 스레드에 오류를 기록합니다. 이는 서비스가 액세스 권한이 없는 제한된 위치(/.config)에 사용 데이터를 쓰려고 하기 때문에 발생합니다.

로그에 다음 오류가 표시됩니다. 

Exception in thread Thread-2 (_report_usage_worker):
Traceback (most recent call last):
 ...
PermissionError: [Error 13] Permission denied: '/.config'
해결방법
이 오류를 방지하고 사용량 통계 로깅을 표시하지 않으려면 유추 서비스 배포에서 VLLM_NO_USAGE_STATS=1 환경 변수를 설정합니다. 이렇게 하면 자동 사용 보고가 비활성화되므로 시스템 디렉터리에 쓰기 시 권한 문제가 발생하지 않습니다.

RHOAIENG-28910 - 관리되지 않는 KServe 리소스는 2.16에서 2.19 이상으로 업그레이드한 후 삭제됩니다.

OpenShift AI 2.16에서 2.25로 업그레이드하는 동안 소유자 참조가 관련 KServe 관련 리소스에서 완전히 제거되기 전에 FeatureTracker CR(사용자 정의 리소스)이 삭제됩니다. 결과적으로 Red Hat OpenShift AI Operator가 Managed 상태로 처음 생성한 리소스가 DataScienceCluster (DSC) 사용자 정의 리소스(CR)에서 의도치 않게 제거될 수 있었습니다. 이 문제로 인해 리소스가 수동으로 복원될 때까지 모델 서비스 기능이 중단될 수 있습니다.

2.16에서 Unmanaged 로 변경된 경우 2.25에서 다음 리소스가 삭제될 수 있습니다.

Expand
유형네임스페이스이름

KnativeServing

knative-serving

knative-serving

ServiceMeshMember

knative-serving

default

게이트웨이

istio-system

kserve-local-gateway

게이트웨이

knative-serving

knative-ingress-gateway

게이트웨이

knative-serving

knative-local-gateway

해결방법

OpenShift AI 2.16에서 2.25로 이미 업그레이드한 경우 다음 작업 중 하나를 수행합니다.

  • 기존 백업이 있는 경우 FeatureTracker CR에 대한 소유자 참조 없이 삭제된 리소스를 수동으로 다시 생성합니다.

  • 기존 백업이 없는 경우 Operator를 사용하여 삭제된 리소스를 다시 생성할 수 있습니다.

    1. 이미 다시 생성한 모든 리소스를 백업하십시오.

    2. DSC에서 spec.components.kserve.serving.managementState 를 Managed 로 설정한 다음 Operator에서 리소스를 다시 생성할 수 있도록 변경 사항을 저장합니다.

      Operator가 리소스를 다시 생성할 때까지 기다립니다.

    3. DSC에서 spec.components.kserve.serving.managementState 를 다시 Unmanaged 로 설정한 다음 변경 사항을 저장합니다.
    4. 재생성된 KnativeServing,ServiceMeshMember 및 Gateway CRs 리소스에 대한 이전 사용자 정의 변경 사항을 다시 적용합니다.

아직 업그레이드하지 않은 경우 이 문제를 방지하기 위해 업그레이드하기 전에 다음 작업을 수행합니다.

  1. DSC에서 spec.components.kserve.serving.managementState 를 Unmanaged 로 설정합니다.
  2. 위 표에 나열된 영향을 받는 KnativeServing,ServiceMeshMember 및 게이트웨이 리소스에 대해 FeatureTracker 소유자 참조를 삭제하여 CR을 편집합니다. 이 편집에서는 FeatureTracker 에 대한 리소스의 종속성을 제거하고 업그레이드 프로세스 중에 리소스 삭제를 방지합니다.

RHOAIG-245 - 처음 시작한 후 워크벤치에 런타임 이미지가 존재하지 않음

런타임 이미지 목록이 네임스페이스에서 첫 번째 실행 중인 워크벤치 인스턴스를 올바르게 채우지 않으므로 Elyra 파이프라인 편집기에서 선택할 수 있는 이미지가 표시되지 않습니다.

해결방법
워크벤치를 다시 시작합니다. 워크벤치를 다시 시작한 후 런타임 이미지 목록에 Elyra 파이프라인 편집기의 워크벤치와 선택 상자가 모두 채워집니다.

RHOAIENG-24786 - 연결이 끊긴 환경에서 Authorino Operator를 기술 프리뷰에서 Stable로 업그레이드하지 못했습니다.

연결이 끊긴 환경에서는 Red Hat Authorino Operator를 Technical Preview에서 Stable로 업그레이드하면 authconfig-migrator-qqttz Pod의 오류와 함께 실패합니다.

해결방법
  1. Red Hat Authorino Operator를 tech-preview-v1 업데이트 채널(v1.1.2)의 최신 버전으로 업데이트합니다.

  2. 다음 스크립트를 실행합니다. 

    #!/bin/bash
set -xe

# delete the migrator job
oc delete job -n openshift-operators authconfig-migrator || true

# run the migrator script
authconfigs=$(oc get authconfigs -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' --no-headers)

if [[ ! -z "${authconfigs}" ]]; then
    while IFS=" " read -r namespace name; do
        oc get authconfig "$name" -n "$namespace" -o yaml > "/tmp/${name}.${namespace}.authconfig.yaml"
        oc apply -f "/tmp/${name}.${namespace}.authconfig.yaml"
    done <<< "${authconfigs}"
fi

oc patch crds authconfigs.authorino.kuadrant.io --type=merge --subresource status --patch '{"status":{"storedVersions":["v1beta2"]}}'
  3. stable 업데이트 채널을 사용하도록 Red Hat Authorino Operator 서브스크립션을 업데이트합니다.
  4. Authorino 1.2.1의 업데이트 옵션을 선택합니다.

RHOAIENG-20209 - 요청된 리소스가 임계값을 초과하면 경고 메시지가 표시되지 않음

분산 워크로드 프로젝트 메트릭 을 클릭하고 요청 리소스 섹션을 보면 차트에 요청된 리소스 값과 각 리소스(CPU 및 메모리)에 대한 총 공유 할당량 값이 표시됩니다. 그러나 모든 프로젝트의 Requested by all projects 값이 해당 리소스에 대한 Warning 임계값 을 초과하면 예상되는 경고 메시지가 표시되지 않습니다.

해결방법
없음.

SRVKS-1301 (이전에는 RHOAIENG-18590)로 문서화되어 있음 - KServe를 비활성화하고 활성화한 후 KnativeServing 리소스가 실패합니다.

DataScienceCluster에서 kserve 구성 요소를 비활성화하고 활성화하면 KnativeServing 리소스가 실패할 수 있습니다.

해결방법

Knative와 관련된 모든 ValidatingWebhookConfiguration 및 MutatingWebhookConfiguration Webhook를 삭제합니다.

  1. Webhook를 가져옵니다. 

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
  2. KServe가 비활성화되어 있는지 확인합니다.

  3. Webhook를 가져옵니다. 

    oc get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
  4. Webhook를 삭제합니다.
  5. KServe를 활성화합니다.
  6. KServe Pod가 성공적으로 생성할 수 있고 knative-serving 네임스페이스의 Pod가 활성 상태이고 작동하는지 확인합니다.

RHOAIENG-16247 - OpenShift AI 대시보드에서 실행이 시작될 때 Elyra 파이프라인 실행 출력을 덮어씁니다.

Elyra에서 파이프라인을 생성하고 실행하면 파이프라인 실행에 의해 생성된 출력은 오브젝트 스토리지의 bucket-name/pipeline-name-timestamp 폴더에 저장됩니다.

Elyra에서 파이프라인이 생성되고 OpenShift AI 대시보드에서 파이프라인 실행이 시작되면 타임스탬프 값이 업데이트되지 않습니다. 이로 인해 파이프라인 실행이 동일한 파이프라인 실행의 이전 파이프라인 실행으로 생성된 파일을 덮어쓸 수 있습니다.

runid 는 항상 오브젝트 스토리지에 사용되는 폴더에 추가되므로 이 문제는 OpenShift AI 대시보드를 사용하여 컴파일 및 가져온 파이프라인에 영향을 미치지 않습니다. 데이터 사이언스 파이프라인에 사용되는 저장 위치에 대한 자세한 내용은 데이터 사이언스 파이프라인 을 사용하여 데이터 저장 을 참조하십시오.

해결방법
Elyra 파이프라인에 파일을 저장할 때 각 파이프라인 실행 시 다른 하위 폴더 이름을 사용합니다.

OCPBUGS-49422 - AMD GPU 및 AMD ROCm 워크벤치 이미지는 연결이 끊긴 환경에서 지원되지 않습니다.

이번 OpenShift AI 릴리스는 AMD GPU Operator를 설치하려면 GPU 드라이버 컴파일에 필요한 종속성을 가져오기 위해 인터넷 액세스가 필요하기 때문에 연결이 끊긴 환경에서 AMD GPU 및 AMD ROCm 워크벤치 이미지를 지원하지 않습니다.

해결방법
없음.

RHOAIENG-12516 - 의도하지 않은 릴리스 채널에서 빠른 릴리스를 사용할 수 있습니다.

스트림 이미지 전달 프로세스의 알려진 문제로 인해 현재 의도하지 않은 스트리밍 채널(예: stable , stable -x.y )에서 빠른 릴리스를 사용할 수 있습니다. 정확한 릴리스 유형, 채널 및 지원 라이프사이클 정보는 Red Hat OpenShift AI Self - Managed 라이프 사이클 페이지의 라이프 사이클 표를 참조하십시오.

해결방법
없음.

RHOAIENG-8294 - OpenShift AI 2.8을 버전 2.10 이상으로 업그레이드할 때 CodeFlare 오류

OpenShift AI 2.8을 버전 2.10 이상으로 업그레이드하려고 하면 AppWrapper CRD(사용자 정의 리소스 정의) 버전과 일치하지 않기 때문에 CodeFlare 구성 요소에 대해 다음 오류 메시지가 표시됩니다. 

ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
해결방법

  1. 기존 AppWrapper CRD를 삭제합니다. 

    $ oc delete crd appwrappers.workload.codeflare.dev

  2. 약 20초 동안 기다린 다음 다음 예와 같이 새 AppWrapper CRD가 자동으로 적용되었는지 확인합니다. 

    $ oc get crd appwrappers.workload.codeflare.dev
NAME                                 CREATED AT
appwrappers.workload.codeflare.dev   2024-11-22T18:35:04Z

RHOAIENG-7716 - 파이프라인 조건 그룹 상태가 업데이트되지 않음

루프(dsl.ParallelFor) 또는 조건 그룹(dsl.lf)이 있는 파이프라인을 실행하면 파이프라인 실행이 완료된 후에도 UI에 루프 및 그룹에 대한 Running 상태가 표시됩니다.

해결방법

하위 작업이 활성 상태로 유지되지 않았는지 확인하여 파이프라인이 여전히 실행 중인지 확인할 수 있습니다.

  1. OpenShift AI 대시보드에서 Data Science Pipelines Runs 를 클릭합니다.
  2. 프로젝트 목록에서 데이터 사이언스 프로젝트를 클릭합니다.
  3. 실행 탭에서 상태를 확인할 파이프라인 실행을 클릭합니다.

  4. 조건 그룹을 확장하고 하위 작업을 클릭합니다.

    하위 작업에 대한 정보가 포함된 패널이 표시됩니다.

  5. 패널에서 Task 세부 정보 탭을 클릭합니다.

    Status 필드에 하위 작업에 대한 올바른 상태가 표시됩니다.

RHOAIENG-6409 - 성공적인 실행을 위해 파이프라인 로그에 매개변수 오류를 저장할 수 없습니다

데이터 사이언스 파이프라인 2.0을 사용하여 파이프라인을 두 번 이상 실행하면 파이프라인 실행을 위해 매개변수 오류가 파이프라인 로그에 표시될 수 없습니다. 이러한 오류는 무시해도 됩니다.

해결방법
없음.

RHOAIENG-3025 - OVMS 예상 디렉터리 레이아웃 KServe StoragePuller 레이아웃

OVMS(OpenVINO Model Server) 런타임을 사용하여 단일 모델 제공 플랫폼(KServe 사용)에 모델을 배포할 때 OVMS에서 예상되는 디렉터리 레이아웃과 KServe에서 사용하는 모델 가져오기 논리의 디렉터리 레이아웃이 일치하지 않습니다. 특히 OVMS에서는 모델 파일이 /< mnt>/models/1/ 디렉터리에 있어야 하지만 KServe는 이를 /<mnt>/models/ 디렉터리에 배치합니다.

해결방법

다음 작업을 수행합니다.

  1. S3 호환 스토리지 버킷에서 모델 파일을 1/ 이라는 디렉터리에 배치합니다(예: /< s3_storage_bucket>/models/1/<model_files > ).

  2. OVMS 런타임을 사용하여 단일 모델 제공 플랫폼에 모델을 배포하려면 다음 옵션 중 하나를 선택하여 모델 파일의 경로를 지정합니다.

    • OpenShift AI 대시보드를 사용하여 모델을 배포하는 경우 데이터 연결의 경로 필드에서 /<s3_storage_bucket>/models/ 형식을 사용하여 모델 파일의 경로를 지정합니다. 1/ 디렉터리를 경로의 일부로 지정하지 마십시오.
    • 모델을 배포하기 위해 자체 InferenceService 사용자 지정 리소스를 생성하는 경우 storageURI 필드의 값을 /<s3_storage_bucket>/models/ 로 구성합니다. 1/ 디렉터리를 경로의 일부로 지정하지 마십시오.

KServe는 지정한 경로의 하위 디렉터리에서 모델 파일을 가져옵니다. 이 경우 KServe는 S3 호환 스토리지의 /<s3_storage_bucket>/models/1/ 디렉토리에서 모델 파일을 올바르게 가져옵니다.

RHOAIENG-3018 - KServe의 OVMS는 대시보드에 올바른 끝점을 노출하지 않습니다.

OVMS(OpenVINO Model Server) 런타임을 사용하여 단일 모델 제공 플랫폼에 모델을 배포할 때 배포된 모델의 유추 끝점 필드에 표시된 URL이 완료되지 않습니다.

해결방법
모델에 쿼리를 보내려면 /v2/models/_<model-name>_/infer 문자열을 URL 끝에 추가해야 합니다. _<model-name>_ 을 배포된 모델의 이름으로 바꿉니다.

RHOAIENG-2602 - "상세 응답 시간" 서버 메트릭 그래프는 ModelMesh pod 재시작으로 인해 여러 행을 보여줍니다.

평균 응답 시간 서버 지표 그래프는 ModelMesh Pod가 다시 시작되면 여러 행을 보여줍니다.

해결방법
없음.

RHOAIENG-2228 - 간격이 15초로 설정될 때 성능 메트릭 그래프가 지속적으로 변경됩니다.

모델 지표 화면의 끝점 성능 탭에서 새로 고침 간격을 15초로 설정하고 시간 범위를 1시간으로 설정하면 그래프 결과가 지속적으로 변경됩니다.

해결방법
없음.

RHOAIENG-2183 - 끝점 성능 그래프에 잘못된 레이블이 표시될 수 있습니다.

모델 지표 화면의 끝점 성능 탭에서 그래프 툴팁에 잘못된 레이블이 표시될 수 있습니다.

해결방법
없음.

RHOAIENG-131 - gRPC 끝점이 Loaded로 보고한 후 제대로 응답하지 않음

수많은 InferenceService 인스턴스가 생성되고 요청을 지시하면 SMCP(Service Mesh Control Plane)가 응답하지 않습니다. InferenceService 인스턴스의 상태는 Loaded 이지만 gRPC 끝점에 대한 호출은 오류와 함께 반환됩니다.

해결방법
ServiceMeshControlPlane 사용자 정의 리소스(CR)를 편집하여 Istio 송신 및 인그레스 Pod의 메모리 제한을 늘립니다.

RHOAIENG-1619 (이전에는 DATA-SCIENCE-PIPELINES-165)로 문서화되어 있습니다. S3 버킷을 쓸 수 없는 경우 오류 메시지

데이터 연결을 설정하고 S3 버킷을 쓸 수 없으며 파이프라인을 업로드하려고 하면 파이프라인을 저장할 수 없음 이라는 오류 메시지가 도움이 되지 않습니다.

해결방법
데이터 연결 인증 정보가 올바르고 사용자가 지정한 버킷에 대한 쓰기 액세스 권한이 있는지 확인합니다.

RHOAIENG-1207 (이전에는 ODH-DASHBOARD-1758) - cnfTB 사용자 정의 서비스 런타임을 여러 번 중복된 오류

model-serving 런타임을 여러 번 복제하면 Serving 런타임 이름 "<name>"과 함께 중복이 실패합니다.

해결방법
metadata.name 필드를 고유한 값으로 변경합니다.

RHOAIENG-133 - 기존 워크벤치는 워크벤치 다시 시작한 후 Elyra 파이프라인을 실행할 수 없습니다.

Elyra tellpyterLab 확장을 사용하여 duepyterLab 내에서 데이터 사이언스 파이프라인을 생성 및 실행하고 작업벤치 내에서 워크벤치 이미지를 생성한 후 파이프라인 서버를 구성하면 워크벤치를 다시 시작한 후에도 파이프라인을 실행할 수 없습니다.

해결방법
  1. 실행 중인 워크벤치를 중지합니다.
  2. 워크벤치를 편집하여 약간의 수정을 수행합니다. 예를 들어 새 더미 환경 변수를 추가하거나 불필요한 기존 환경 변수를 삭제합니다. 변경 사항을 저장하십시오.
  3. 워크벤치를 다시 시작합니다.
  4. sendpyterLab의 왼쪽 사이드바에서 런타임을 클릭합니다.
  5. 기본 런타임이 선택되어 있는지 확인합니다.

RHODS-12798 - Pod 실패, "unable to init seccomp" 오류

seccomp 메모리 누수를 도입한 알려진 커널 버그로 인해 Pod는 Running 상태 대신 CreateContainerError 상태 또는 Pending 상태로 인해 실패합니다. Pod가 실패한 네임스페이스에서 이벤트를 확인하거나 oc describe pod 명령을 실행하면 다음 오류가 표시됩니다. 

runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524
해결방법
Red Hat 지식베이스 솔루션 Pod에 설명된 대로 net.core.bpf_jit_limit 값을 늘리면 OpenShift 4에서 seccomp 필터를 kernel: errno 524로 로드하는 동안 오류가 발생했습니다.

KUBEFLOW-177 - OAuth 프록시에 의해 전달되지 않은 애플리케이션의 전달자 토큰

내부 인증 메커니즘이 전달자 토큰을 기반으로 하는 경우 애플리케이션을 사용자 지정 워크벤치 이미지로 사용할 수 없습니다. OAuth-proxy 구성은 헤더에서 전달자 토큰을 제거하며 애플리케이션이 제대로 작동할 수 없습니다.

해결방법
없음.

KUBEFLOW-157 - OpenShift AI 대시보드에서 이미 로그아웃한 경우 duepyterLab에서 로깅이 작동하지 않음

CryostatpyterLab에서 로그아웃하기 전에 OpenShift AI 대시보드에서 로그아웃하는 경우 teachingpyterLab에서 로그아웃하는 데 성공하지 못합니다. 예를 들어, sendpyter 노트북의 URL을 알고 있으면 브라우저에서 이 URL을 다시 열 수 있습니다.

해결방법
OpenShift AI 대시보드에서 로그아웃하기 전에 sendpyterLab에서 로그아웃합니다.

RHODS-7718 - 대시보드 권한이 없는 사용자는 실행 중인 워크벤치를 무기한 계속 사용할 수 있습니다.

Red Hat OpenShift AI 관리자가 사용자의 권한을 취소하면 사용자는 실행 중인 워크벤치를 무기한 계속 사용할 수 있습니다.

해결방법
OpenShift AI 관리자가 사용자의 권한을 취소하는 경우 관리자는 해당 사용자의 실행 중인 워크벤치도 중지해야 합니다.

RHOAIENG-1152 (이전에는 RHODS-6356)로 문서화되어 있음 - 대시보드에 로그인하지 않은 사용자가 basic-workbench 생성 프로세스가 실패합니다.

기본 워크벤치에 대한 대시보드의 관리 페이지에는 OpenShift의 사용자 그룹 및 관리자 그룹에 속하는 사용자가 표시됩니다. 그러나 관리자가 대시보드에 로그인하지 않은 사용자를 대신하여 기본 워크벤치를 시작하려고 하면 기본 워크벤치 생성 프로세스가 실패하고 다음 오류 메시지가 표시됩니다. 

Request invalid against a username that does not exist.
해결방법
관련 사용자가 대시보드에 로그인하도록 요청합니다.

RHODS-5543 - NVIDIA GPU Operator를 사용할 때 필요한 것보다 더 많은 노드가 노드 자동 스케일러에 의해 생성됩니다.

사용 가능한 리소스가 부족하여 Pod를 예약할 수 없는 경우 노드 자동 스케일러는 새 노드를 생성합니다. 새로 생성된 노드가 관련 GPU 워크로드를 수신할 때까지 지연이 발생합니다. 결과적으로 Pod를 예약할 수 없으며 노드 자동 스케일러는 GPU 워크로드를 수신할 준비가 될 때까지 추가 새 노드를 지속적으로 생성합니다. 이 문제에 대한 자세한 내용은 Red Hat Knowledgebase 솔루션에서 NVIDIA GPU Operator를 사용할 때 노드 자동 스케일러에서 필요한 것보다 많은 노드를 참조하십시오.

해결방법
machineset.spec.template.spec.metadata 에 cluster-api/accelerator 레이블을 적용합니다. 이로 인해 자동 스케일러는 GPU 드라이버가 배포될 때까지 해당 노드를 준비되지 않은 것으로 간주합니다.

RHODS-4799 - Tensorboard를 보려면 수동 단계가 필요합니다.

사용자에게 TensorFlow 또는 PyTorch 워크벤치 이미지가 있고 TensorBoard를 사용하여 데이터를 표시하려는 경우 워크벤치 환경에 환경 변수를 추가하고 해당 변수를 코드에서 사용하려면 수동 단계가 필요합니다.

해결방법

기본 워크벤치를 시작할 때 다음 코드를 사용하여 TENSORBOARD_PROXY_URL 환경 변수의 값을 설정하여 OpenShift AI 사용자 ID를 사용합니다. 

import os
os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"

RHODS-4718 - Intel® oneAPI AI Analytics Toolkits 빠른 시작은 존재하지 않는 샘플 노트북을 참조합니다.

대시보드의 리소스 페이지에 있는 Intel® oneAPI AI Analytics Toolkits 빠른 시작에는 사용자가 명령 단계의 일부로 샘플 노트북을 로드해야 하지만, 연결된 리포지토리에 없는 노트북을 나타냅니다.

해결방법
없음.

RHODS-3984 - 노트북 선택 시 표시되는 잘못된 패키지 버전

OpenShift AI 인터페이스에서 노트북 시작 서버 페이지에 는 oneAPI AI Analytics Toolkit 노트북 이미지에 포함된 sendpyterLab 및 Notebook 패키지의 잘못된 버전 번호가 표시됩니다. 페이지에 이 이미지에서 사용하는 Python 버전에 잘못된 값이 표시될 수도 있습니다.

해결방법
oneAPI AI Analytics Toolkit 노트북 서버를 시작할 때, 노트북 서버에 어떤 Python 패키지가 설치되어 있는지, 그리고 노트북 셀에서 !pip list 명령을 실행하여 어떤 버전의 패키지인지 확인할 수 있습니다.

RHOAING-1147 (이전에는 RHODS-2881) - 대시보드의 작업이 명확하게 표시되지 않음

비활성화된 애플리케이션 라이센스를 다시 무효화하고 비활성화된 애플리케이션 타일을 제거하는 대시보드 작업은 사용자에게 명확하게 표시되지 않습니다. 이러한 작업은 사용자가 애플리케이션 타일의 Disabled 레이블을 클릭하면 표시됩니다. 따라서 의도한 워크플로우가 사용자에게 명확하지 않을 수 있습니다.

해결방법
없음.

RHODS-2096 - OpenShift AI에서 IBM Cryostat Studio를 사용할 수 없음

IBM Cryostat Studio는 OpenShift Dedicated 4.9 이상에 OpenShift AI를 설치할 때 이러한 OpenShift Dedicated 버전과 호환되지 않기 때문에 사용할 수 없습니다.

해결방법
OpenShift Dedicated 4.9 이상에서 Cryostat Studio를 수동으로 구성하는 방법에 대한 지원이 필요한 경우 Red Hat 고객 포털에 문의하십시오.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동