制限、デフォルト設定、および使用要件

IBM Cloud Satellite® は、セキュリティー、利便性、および基本的な機能を確保するための使用上の要件、デフォルトのサービス設定、および制限を備えています。

ロケーション

IBM Cloud Satellite そのロケーションが管理されている IBM Cloud マルチゾーンメトロごとに、最大20か所のロケーションを作成できます。

名前
Satellite のロケーション名は先頭が文字でなければならず、文字、数字、ピリオド (.)、およびハイフン (-) を使用できます。35 文字以内でなければなりません。 同じ名前を複数のロケーションに繰り返し使用することはできず、同じ名前の別のロケーションを削除した場合でも同様です。
待ち時間
インフラストラクチャー・プロバイダーを選択するときには、遅延に関する以下の要件を考慮してください。 この遅延要件を満たしていない環境では、パフォーマンスが低下します。
  • IBM Cloud とその場所の間: 「 Satellite 」ロケーションのコントロールプレーンに接続するホストは、 Satellite ロケーションの管理が行われている「 IBM Cloud 」リージョンへの往復時間（RTT）が200ミリ秒以下（<= 200ms ）の低遅延接続を備えている必要があります。 レイテンシが高くなると、 Satellite のリンクスループット、 Satellite を有効にした IBM Cloud サービスのプロビジョニング時間、ホスト障害からの復旧時間などのパフォーマンスが低下します。また、極端な場合には、 Satellite のロケーション制御プレーンで実行されるリソース（ Red Hat OpenShift クラスタマスターなど）の可用性にも影響を及ぼします。 詳しくは、IBM Cloud と Satellite ロケーション・コントロール・プレーンのホストの間の待ち時間のテストを参照してください。
  • お住まいの地域内のホスト間 ： ホストインフラストラクチャの構成において、 Satellite ロケーションのコントロールプレーンワーカーノードとして使用されるホストと、クラスターや Satellite 対応の IBM Cloud サービス など、そのロケーション内のその他のリソースとして使用されるホストとの間で、往復時間（RTT）が100ミリ秒以下（<= 100ms ）の低遅延接続が確保されている必要があります。 例えば、AWS などのクラウド・プロバイダーでは、このセットアップは通常、Satellite ロケーション内のすべてのホストが同じクラウド・リージョン (us-east-1 など) からのものであることを意味します。 レイテンシが高くなると、プロビジョニングや復旧にかかる時間、クラスタ内で利用可能なワーカーノードの数、 Satellite が有効になっている IBM Cloud サービスの安定性、さらには極端な場合にはクラスタアプリケーションの可用性など、パフォーマンスが低下します。

ホスト

ホスト要件を参照してください。

クラウド・プロバイダー固有の構成については、以下のトピックを参照してください。

ワーカー・ノードのホスト
クラシック・インフラストラクチャーまたは 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 コネクターの以下の要件と制限事項を確認します。

構成

Satellite 構成の以下のアプリケーション構成要件を確認します。

Satellite 構成は、Red Hat CoreOS が有効になっているロケーションではサポートされません。

クラスター内の Kubernetes リソースを変更するための Satellite 構成アクセス権限
デフォルトでは、Satellite Config は、クラスター内で読み取りおよび変更できる Kubernetes リソースに制限されています。 Satellite 構成を使用して Kubernetes リソースを管理する各クラスターで、Satellite 構成アクセス権限を付与する必要があります。
以下のオプションから選択します。
  • --enable-admin-agent オプションを使用して コンソール または CLI でクラスターを作成する場合は、クラスター管理アクセス権限にオプトインします。 クラスターごとに oc login を一度実行するだけで管理者権限は同期されます。
  • クラスターの作成後にオプトインする場合、またはアクセス権限の有効範囲を設定する場合は、クラスターに対するアクセス権限を Satellite Config に付与するを参照してください。
Satellite Config および IBM Cloud IAM
Satellite Config リソース (構成、サブスクリプション、クラスター、またはクラスター・グループ) のアクセス・ポリシーのスコープを IBM Cloud リソース・グループに設定することはできません。Satellite Config は、組織を使用してユーザーを認証するオープン・ソース Razee プロジェクトを使用します。 組織はアカウント ID のみをサポートし、リソース・グループはサポートしません。
アクセス・ポリシーのスコープを特定の構成またはサブスクリプション・リソースに設定することはできません。 IBM Cloud IAM コンソールでポリシーを割り当てる場合は、構成またはサブスクリプションの**「リソース」**フィールドをブランクのままにします。 代わりに、アクセス・ポリシーの範囲にクラスター・グループを設定して、Satellite 構成リソースのデプロイ方法をより詳細に制御できます。
Satellite Config を使用してクラスター内で実行される Kubernetes リソースをユーザーが表示できるようにするには、適切な役割 (管理者、マネージャー、またはリーダー) を持つアクセス・ポリシーを IBM Cloud Satellite に割り当てる必要があります (特定のリソースまたはリソース・タイプにスコープは設定されません)。
ibmcloud oc cluster create satellite コマンドの --enable-admin-agent オプションを使用してコンソールまたは CLI で Satellite クラスターを作成するときに、Satellite Config 権限を有効にした後、クラスターのコンテキストを設定して権限を同期化する必要があります。 クラスターのコンテキストを設定するには、Red Hat OpenShift Web コンソールを起動するか、CLI で ibmcloud oc cluster config コマンドを実行します。 注: パブリック・クラウドの Red Hat OpenShift on IBM Cloud クラスターを Satellite Config で使用するために登録した場合は、権限を同期させるためにクラスター・コンテキストを設定する必要はありません。
Satellite Config の構成ファイル
  • アップロードできるのは、リリース・バージョンごとに Kubernetes リソースの個々の構成ファイルのみです。 1 つのディレクトリーまたは複数の異なる構成ファイルをアップロードすることはできません。
  • 構成ファイルは、マニフェストを YAML 形式で表現する必要があるなど、Kubernetes の要件に従います。

IBM Cloud サービス

IBM Cloud Satellite 1つのロケーションにつき、 IBM Cloud サービスのインスタンスを最大40個までサポートします。たとえば、 Red Hat OpenShift on IBM Cloud クラスターを最大40個まで作成できます。

Satellite で実行される各サポート対象サービスには、それぞれ固有の制限事項が設けられている場合があります。 制限事項を理解するには、サポートされるサービスの資料を確認してください。