제한사항, 기본 설정 및 사용 요구사항

IBM Cloud Satellite®에는 보안, 편의성 및 기본 기능을 보장하기 위한 사용 요구사항, 기본 서비스 설정 및 제한사항이 있습니다.

위치

IBM Cloud Satellite 해당 위치가 관리되는 ‘ IBM Cloud ’ 멀티존 메트로당 최대 20개의 위치를 생성할 수 있습니다.

이름
Satellite 위치 이름은 문자로 시작해야 하며 문자, 숫자, 마침표(.) 및 하이픈(-) 을 포함할 수 있고 35자 이하여야 합니다. 이름이 같은 또 다른 위치를 삭제한 경우에도 여러 위치에 같은 이름을 사용하지 마십시오.
대기 시간
인프라 제공자를 선택할 때 다음과 같은 대기 시간 요구사항을 고려하십시오. 대기 시간 요구사항을 충족하지 않는 환경에서는 성능이 저하됩니다.
  • IBM Cloud 와 해당 위치 간: Satellite 위치의 제어 평면에 연결하려는 호스트는, Satellite 위치가 관리되는 IBM Cloud 리전까지의 왕복 시간(RTT)이 200밀리초 이하(<= 200ms)인 저지연 연결을 갖추고 있어야 합니다. 지연 시간이 길어지면 Satellite 링크 처리량, Satellite 가 활성화된 IBM Cloud 서비스 프로비저닝 시간, 호스트 장애 복구 시간 등의 성능이 저하되며, 극단적인 경우에는 Red Hat OpenShift 클러스터 마스터와 같이 Satellite 위치 제어 플레인에서 실행되는 리소스의 가용성까지 영향을 미칩니다. 자세한 정보는 IBM Cloud 및 Satellite 위치 제어 플레인 호스트 간의 대기 시간 테스트를 참조하십시오.
  • 사용자 위치 내 호스트 간: 호스트 인프라 구성 시, Satellite 위치 제어 플레인 워커 노드에 사용되는 호스트와 해당 위치의 클러스터나 Satellite 가 활성화된 IBM Cloud 서비스와 같은 기타 리소스에 사용되는 호스트 간 왕복 시간(RTT)이 100밀리초 이하(<= 100ms)인 저지연 연결이 보장되어야 합니다. 예를 들면, AWS와 같은 클라우드 제공자에서 이 설정은 일반적으로 Satellite 위치에 있는 모든 호스트가 동일한 클라우드 지역(예: us-east-1)의 호스트임을 의미합니다. 지연 시간이 길어지면 프로비저닝 및 복구 시간, 클러스터 내 사용 가능한 워커 노드 수, ‘ Satellite ’ 기능이 활성화된 ‘ IBM Cloud ’ 서비스의 안정성, 그리고 극단적인 경우에는 클러스터 애플리케이션의 가용성까지 포함한 전반적인 성능이 저하됩니다.

호스트

호스트 요구사항을 참조하십시오.

클라우드 제공자 특정 구성의 경우 다음 주제를 참조하십시오.

작업자 노드 호스트
Classic 또는 VPC 인프라의 Red Hat OpenShift on IBM Cloud 클러스터에 있는 작업자 노드는 Satellite 클러스터에서 사용하도록 용도를 변경할 수 없습니다.

클러스터

클러스터, 스토리지, 네트워킹 및 호스트에 대한 자세한 내용은 Red Hat OpenShift on IBM Cloud 문서의 ‘ Satellite 클러스터의 한계 ’ 섹션을 참조하십시오.

  • Red Hat OpenShift on IBM Cloud 위치에 작성된 Satellite 클러스터
  • 클러스터에서 실행되는 앱의 데이터를 Kubernetes 지속적 볼륨에 저장
  • Kubernetes 로드 밸런서와 같은 클러스터 네트워킹
  • 호스트를 클러스터의 작업자 노드로 사용

커넥터

Satellite 커넥터에 대한 다음 요구사항 및 제한사항을 검토하십시오.

Config

Satellite Config에 대한 다음 애플리케이션 구성 요구사항을 검토하십시오.

Red Hat CoreOS가 사용으로 설정된 위치에서는 Satellite Config가 지원되지 않습니다.

클러스터 내의 Kubernetes 리소스를 수정하기 위한 Satellite Config 액세스 권한
기본적으로, Satellite Config가 클러스터에서 읽고 수정할 수 있는 Kubernetes 리소스는 제한되어 있습니다. 사용자는 Satellite Config를 사용하여 Kubernetes 리소스를 관리할 각 클러스터에서 Satellite Config에 액세스 권한을 부여해야 합니다.
다음 옵션 중에서 선택하십시오.
  • 콘솔 또는 CLI에서 --enable-admin-agent 옵션을 사용하여 클러스터를 작성할 때 클러스터 관리자 액세스 권한을 선택하십시오. 관리자 권한을 동기화하려면 각 클러스터에서 한 번의 oc login을 수행해야 합니다.
  • 클러스터를 작성한 다음 옵트 인하거나 액세스 범위를 지정하려면 Satellite Config에 클러스터에 대한 액세스 권한 부여를 참조하십시오.
Satellite Config 및 IBM Cloud IAM
Satellite Config 리소스(구성, 구독, 클러스터 또는 클러스터 그룹)에 대한 액세스 정책의 범위를 IBM Cloud 리소스 그룹으로 지정할 수 없습니다. Satellite Config는 조직을 사용하여 사용자를 인증하는 오픈 소스 Razee 프로젝트를 사용합니다. 조직은 리소스 그룹을 지원하지 않으며, 계정 ID만 지원합니다.
액세스 정책의 범위를 특정 구성 또는 구독 리소스로 지정할 수는 없습니다. IBM Cloud IAM 콘솔에서 정책을 지정할 때는 구성 또는 구독에 대해 리소스 필드를 공백으로 두십시오. 대신, 액세스 정책의 범위를 클러스터 그룹으로 지정하여 Satellite Config 리소스가 배치되는 방식에 대한 제어 수준을 높일 수 있습니다.
사용자가 Satellite Config로 클러스터에서 실행되는 Kubernetes 리소스를 볼 수 있도록 하려면 적절한 역할(관리자(Administrator), 관리자(Manager) 또는 독자)이 있는(그리고 특정 리소스 또는 리소스 유형으로 범위 지정되지 않은) 액세스 정책을 IBM Cloud Satellite에 지정해야 합니다.
콘솔 또는 ibmcloud oc cluster create satellite 명령에 --enable-admin-agent 옵션을 사용하여 Satellite 클러스터를 작성할 때 Satellite 구성 권한을 사용으로 설정한 후 권한을 동기화하도록 클러스터의 컨텍스트를 설정해야 합니다. Red Hat OpenShift 웹 콘솔을 실행하거나 CLI에서 ibmcloud oc cluster config 명령을 실행하여 클러스터 컨텍스트를 설정할 수 있습니다. 주: Red Hat OpenShift on IBM Cloud Config에 사용할 퍼블릭 클라우드에 Satellite 클러스터를 등록한 경우 권한을 동기화하도록 클러스터 컨텍스트를 설정할 필요가 없습니다.
Satellite Config의 구성 파일
  • 릴리스 버전별로 하나의 Kubernetes 리소스 구성 파일만 업로드할 수 있습니다. 디렉토리 또는 여러 구성 파일을 업로드할 수는 없습니다.
  • 구성 파일에는 Manifest가 YAML 형식으로 표현되어야 하는 등의 Kubernetes 요구사항이 적용됩니다.

IBM Cloud 서비스

IBM Cloud Satellite 위치당 최대 40개의 ‘ IBM Cloud ’ 서비스 인스턴스를 지원하며, 이는 최대 40개의 ‘ Red Hat OpenShift on IBM Cloud ’ 클러스터에 해당합니다.

지원되는 각 서비스는 ‘ Satellite ’에서 실행될 때 고유한 제한 사항이 있을 수 있습니다. 지원되는 서비스의 문서를 확인하여 제한사항을 이해하십시오.