Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

알려진 제한 사항

기여자

알려진 제한 사항은 이 제품 릴리스에서 지원하지 않거나 올바르게 상호 운용되지 않는 플랫폼, 장치 또는 기능을 식별합니다. 이러한 제한 사항을 주의 깊게 검토하십시오.

두 개의 Astra Control Center 인스턴스가 동일한 클러스터를 관리할 수 없습니다

다른 Astra Control Center 인스턴스에서 클러스터를 관리하려면 먼저 다음을 수행해야 합니다 "클러스터 관리를 취소합니다" 다른 인스턴스에서 관리하기 전에 관리되는 인스턴스에서 관리에서 클러스터를 제거한 후 다음 명령을 실행하여 클러스터가 관리되지 않는 상태인지 확인합니다.

oc get pods n -netapp-monitoring

해당 네임스페이스에서 실행 중인 포드가 없어야 합니다. 그렇지 않으면 네임스페이스가 존재하지 않아야 합니다. 둘 중 하나가 참인 경우 클러스터는 관리되지 않습니다.

Astra Control Center는 동일하게 이름이 지정된 두 클러스터를 관리할 수 없습니다

이미 있는 클러스터의 이름과 동일한 이름의 클러스터를 추가하려고 하면 작업이 실패합니다. 이 문제는 Kubernetes 구성 파일에서 클러스터 이름 기본값을 변경하지 않은 경우 표준 Kubernetes 환경에서 가장 자주 발생합니다.

해결 방법으로 다음을 수행합니다.

  1. 을 편집합니다 kubeadm-config 구성 맵:

    kubectl edit configmaps -n kube-system kubeadm-config
  2. 'clusterName' 필드 값을 Kubernetes(Kubernetes 기본 이름)에서 고유한 사용자 정의 이름으로 변경합니다.

  3. kubecononfig('.kubbe/config')를 편집합니다.

  4. 클러스터 이름을 Kubernetes에서 고유한 사용자 지정 이름으로 업데이트합니다(아래 예에서는 xyz-cluster 사용). 다음 예와 같이 클러스터 및 컨텍스트 섹션에서 모두 업데이트합니다.

    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: ExAmPLERb2tCcjZ5K3E2Njk4eQotLExAMpLEORCBDRVJUSUZJQ0FURS0txxxxXX==
        server: https://x.x.x.x:6443
      name: xyz-cluster
    contexts:
    - context:
        cluster: xyz-cluster
        namespace: default
        user: kubernetes-admin
      name: kubernetes-admin@kubernetes
    current-context: kubernetes-admin@kubernetes

네임스페이스 RBAC 제약 조건이 있는 사용자는 클러스터를 추가 및 관리할 수 있습니다

네임스페이스 RBAC 제약 조건이 있는 사용자는 클러스터를 추가하거나 관리할 수 없습니다. 현재 제한 사항으로 인해 Astra는 이러한 사용자가 클러스터 관리를 해제하는 것을 방지하지 않습니다.

네임스페이스 제약 조건이 있는 구성원은 관리자가 제약 조건에 네임스페이스를 추가할 때까지 복제되거나 복원된 앱에 액세스할 수 없습니다

모두 member 네임스페이스 이름/ID별 RBAC 제약 조건을 사용하는 사용자는 앱을 동일한 클러스터의 새 네임스페이스 또는 조직 계정의 다른 클러스터로 클론 복제 또는 복원할 수 있습니다. 그러나 동일한 사용자가 새 네임스페이스에서 복제되거나 복원된 앱에 액세스할 수 없습니다. 클론 또는 복구 작업에서 새 네임스페이스를 생성한 후 계정 관리자/소유자가 을 편집할 수 있습니다 member 영향을 받는 사용자가 새 네임스페이스에 대한 액세스 권한을 부여하도록 사용자 계정 및 역할 제약 조건을 업데이트합니다.

비커넥터 클러스터의 리소스에 대해 제한적인 역할 제약 조건을 무시할 수 있습니다

  • * 액세스 중인 리소스가 최신 Astra Connector가 설치된 클러스터에 속하는 경우 *: LDAP 그룹 멤버십을 통해 사용자에게 여러 역할이 할당되면 역할의 제약 조건이 결합됩니다. 예를 들어, 로컬 뷰어 역할이 있는 사용자가 구성원 역할에 바인딩된 세 그룹에 가입하면 사용자는 원래 리소스에 대한 뷰어 역할 액세스 권한뿐 아니라 그룹 구성원을 통해 얻은 리소스에 대한 구성원 역할 액세스 권한도 갖게 됩니다.

  • * 액세스 중인 리소스가 Astra Connector가 설치되지 않은 클러스터에 속하는 경우 *: LDAP 그룹 멤버십을 통해 사용자에게 여러 역할이 할당되는 경우 가장 허용 가능한 역할의 제약 조건만 적용됩니다.

단일 네임스페이스의 여러 응용 프로그램을 다른 네임스페이스로 집합적으로 복원할 수 없습니다

Astra Control에서 여러 애플리케이션 정의를 생성하여 단일 네임스페이스에서 여러 애플리케이션을 관리하는 경우 모든 애플리케이션을 다른 단일 네임스페이스로 복원할 수 없습니다. 각 애플리케이션을 별도의 네임스페이스로 복원해야 합니다.

Astra Control은 네임스페이스당 여러 스토리지 클래스를 사용하는 앱을 지원하지 않습니다

Astra Control은 네임스페이스당 단일 스토리지 클래스를 사용하는 앱을 지원합니다. 네임스페이스에 앱을 추가하는 경우 네임스페이스에서 다른 앱과 동일한 저장소 클래스가 앱에 있는지 확인합니다.

Astra Control은 클라우드 인스턴스에 대해 기본 버킷을 자동으로 할당하지 않습니다

Astra Control은 클라우드 인스턴스에 대해 기본 버킷을 자동으로 할당하지 않습니다. 클라우드 인스턴스의 기본 버킷을 수동으로 설정해야 합니다. 기본 버킷을 설정하지 않으면 두 클러스터 간에 애플리케이션 클론 작업을 수행할 수 없습니다.

pass-by-reference 연산자를 사용하여 설치된 앱의 클론이 실패할 수 있습니다

Astra Control은 네임스페이스 범위 연산자와 함께 설치된 앱을 지원합니다. 이러한 연산자는 일반적으로 "pass-by-reference" 아키텍처가 아니라 "pass-by-value"로 설계되었습니다. 다음은 이러한 패턴을 따르는 일부 운영자 앱에 대한 설명입니다.

  • "아파치 K8ssandra"

    참고 K8ssandra 의 경우 현재 위치 복원 작업이 지원됩니다. 새 네임스페이스 또는 클러스터에 대한 복원 작업을 수행하려면 응용 프로그램의 원래 인스턴스를 중단해야 합니다. 이는 이월된 피어 그룹 정보가 인스턴스 간 통신으로 이어지지 않도록 하기 위한 것입니다. 앱 복제는 지원되지 않습니다.
  • "젠킨스 CI"

  • "Percona XtraDB 클러스터"

Astra Control은 "pass-by-reference" 아키텍처(예: CockroachDB 운영자)로 설계된 운영자를 복제하지 못할 수 있습니다. 이러한 유형의 클론 복제 작업 중에 클론 복제 운영자는 클론 복제 프로세스의 일부로 고유한 새로운 암호가 있음에도 불구하고 소스 운영자의 Kubernetes 암호를 참조하려고 합니다. Astra Control이 소스 운영자의 Kubernetes 암호를 모르기 때문에 클론 작업이 실패할 수 있습니다.

참고 클론 작업 중에 IngressClass 리소스 또는 Webhook가 필요한 애플리케이션에는 대상 클러스터에 이미 정의된 리소스가 없어야 합니다.

인증서 관리자를 사용하는 앱의 데이터 이동 없는 복원 작업은 지원되지 않습니다

이 Astra Control Center 릴리스는 인증서 관리자와의 응용 프로그램 데이터 이동 없는 복원을 지원하지 않습니다. 복원 작업을 다른 네임스페이스로 복원하고 클론 작업을 지원합니다.

OLM 지원 및 클러스터 범위 운영자로 배포된 앱은 지원되지 않습니다

Astra Control Center는 클러스터 범위 운영자의 애플리케이션 관리 활동을 지원하지 않습니다.

Helm 2와 함께 배포된 앱은 지원되지 않습니다

Helm을 사용하여 앱을 배포하는 경우 Astra Control Center에 Helm 버전 3이 필요합니다. Helm 3으로 배포된 애플리케이션 관리 및 복제(또는 Helm 2에서 Helm 3으로 업그레이드)가 완벽하게 지원됩니다. 자세한 내용은 을 참조하십시오 "Astra Control Center 요구 사항".

특정 스냅샷 컨트롤러 버전을 사용하는 Kubernetes 1.25 이상 클러스터의 경우 스냅샷이 실패할 수 있습니다

버전 1.25 이상을 실행하는 Kubernetes 클러스터의 스냅샷은 버전 v1beta1 의 스냅샷 컨트롤러 API가 클러스터에 설치된 경우 실패할 수 있습니다.

이 문제를 해결하려면 기존 Kubernetes 1.25 이상 설치를 업그레이드할 때 다음을 수행하십시오.

Astra Control Center 인스턴스를 제거하는 동안 백업 및 스냅샷이 보존되지 않을 수 있습니다

평가 라이센스가 있는 경우 ASUP를 보내지 않을 경우 Astra Control Center에 장애가 발생할 경우 데이터 손실을 방지하기 위해 계정 ID를 저장해야 합니다.

ONTAP의 데이터 이동 없이 복원 작업 - NAS 이코노미 스토리지 클래스에 장애가 발생했습니다

응용 프로그램의 전체 복원을 수행하고(응용 프로그램을 원래 네임스페이스로 복원) 앱의 저장소 클래스는 을 사용합니다 ontap-nas-economy 드라이버, 스냅샷 디렉토리가 숨겨져 있지 않으면 복구 작업이 실패할 수 있습니다. 원래 위치로 복원하기 전에 의 지침을 따릅니다 "ONTAP - NAS - 경제성 작업을 위한 백업 및 복원 지원" 스냅샷 디렉토리를 숨깁니다.

LDAP 사용자 및 그룹 제한

Astra Control Center는 최대 5,000개의 원격 그룹과 10,000명의 원격 사용자를 지원합니다.

Astra Control은 뒤에 '\' 또는 후행 공백이 있는 RDN이 포함된 LDAP 엔티티(사용자 또는 그룹)를 지원하지 않습니다.

Astra Control Center의 S3 버킷은 가용 용량을 보고하지 않습니다

Astra Control Center에서 관리하는 앱을 백업 또는 클론 생성하기 전에 ONTAP 또는 StorageGRID 관리 시스템에서 버킷 정보를 확인하십시오.

Astra Control Center는 프록시 서버에 대해 입력한 세부 정보를 확인하지 않습니다

다음을 확인하십시오 "올바른 값을 입력하십시오" 연결 설정 시

Postgres POD에 대한 기존 연결로 인해 오류가 발생합니다

Postgres Pod에서 작업을 수행할 때 psql 명령을 사용하기 위해 POD 내에서 직접 연결하면 안 됩니다. Astra Control은 데이터베이스를 고정 및 고정 해제할 수 있도록 psql 액세스 권한이 필요합니다. 기존 접속이 있는 경우 스냅샷, 백업 또는 클론이 실패합니다.

활동 페이지에는 최대 100,000개의 이벤트가 표시됩니다

Astra Control Activity 페이지에는 최대 100,000개의 이벤트가 표시될 수 있습니다. 기록된 이벤트를 모두 보려면 를 사용하여 이벤트를 검색합니다 "Astra Control API를 참조하십시오".

SnapMirror는 스토리지 백엔드를 위해 NVMe over TCP를 사용하는 애플리케이션을 지원하지 않습니다

Astra Control Center는 TCP 프로토콜을 통해 NVMe를 사용하는 스토리지 백엔드에 대해 NetApp SnapMirror 복제를 지원하지 않습니다.

자세한 내용을 확인하십시오