サービスの制限と利用枠
クラスターに適用されるサービスの制限やクォータを確認し、必要に応じて調整可能な制限について理解しましょう。
IBM Cloud Kubernetes Service の以下のいずれかの制限に達することが予想される場合は、IBM サポートに連絡し、サポート・チケットにクラスター ID、新しい上限数、リージョン、インフラストラクチャー・プロバイダーを記入してください。
サービスとクォータの制限
使用するインフラストラクチャー・プロバイダーに関係なく、IBM Cloud Kubernetes Service では、サービスに関する以下の制限と上限数がすべてのクラスターに適用されます。 クラシック・クラスターと VPC クラスターの制限も適用されることに留意してください。
IBM Cloud アカウント内のクラスター関連リソースの上限数を表示するには、ibmcloud ks quota ls コマンドを使用します。
| カテゴリ | 説明 |
|---|---|
| API レート制限 | 固有の各ソース IP アドレスから、IBM Cloud Kubernetes Service API に対して 10 秒ごとに 200 個の要求。 |
| アプリのデプロイメント | クラスターにデプロイするアプリ、およびクラスターと統合するサービスは、ワーカー・ノードのオペレーティング・システムで実行できるものでなければなりません。 |
| Calico ネットワーク・プラグイン | Calico のプラグイン、コンポーネント、またはデフォルトの Calico 設定の変更はサポートされていません。 例えば、新しい Calico プラグイン・バージョンをデプロイしたり、Calico コンポーネント、デフォルトの IPPool リソース、または Calico ノードのデーモン・セットまたはデプロイメントを変更したりしないでください。 代わりに、Calico NetworkPolicy または GlobalNetworkPolicy の作成、
Calico MTU の変更または Calico CNI のポート・マップ・プラグインの無効化の資料の説明に従うことができます。 |
| クラスターのクォータ | 1 リージョン、1 インフラストラクチャー・プロバイダーにつき 100 個を超えてはいけません。 ただし、2024 年 1 月 1 日の時点で、割り当て量は 100 に達する前に増分的に増加します。 これより多いリソースが必要な場合は、IBM サポートにお問い合わせください。
サポート依頼の際には、対象となるリージョンおよびインフラストラクチャ・プロバイダーの新しいクォータ上限を明記してください。 割り当て量をリストするには、 ibmcloud quota ls を実行します。 |
| Kubernetes | Kubernetes プロジェクトの制限事項を必ず確認してください。 |
| KMS プロバイダー | IBM® Key Protect for IBM Cloud® インスタンスへの接続を許可されている IP アドレスをカスタマイズすることはサポートされません。 |
| Kubernetes ポッド・ログ | 個々のアプリ・ポッドのログを確認するには、コマンド・ラインを使用して kubectl logs <pod name> を実行します。 Kubernetes ダッシュボードを使用してポッドのログのストリーミングをしないでください。Kubernetes ダッシュボードへのアクセスが中断される可能性があります。 |
| ロード・バランサー | Kubernetes SCTP プロトコル は、 Kubernetes コミュニティー・リリースで一般提供されていますが、このプロトコルを使用するロード・バランサーの作成は、 IBM Cloud Kubernetes Service クラスターではサポートされていません。 |
| オペレーティング・システム | ワーカー・ノードは、サポートされるオペレーティング・システムのいずれかを実行する必要があります。 異なるタイプのオペレーティング・システムを実行するワーカー・ノードを使用してクラスターを作成することはできません。 詳しくは、 Kubernetes バージョン情報 を参照してください。 |
| ポッドのインスタンス | ワーカー・ノードごとに 110 個のポッドを実行できます。 CPU コアを 11 個以上搭載したワーカー・ノードでは、1 コアあたり 10 個のポッドをサポートできますが、ポッド数には 1 ワーカー・ノードあたり最大 250 個という制限があります。 ポッドの数には、ワーカー・ノードで実行される kube-system ポッドと ibm-system ポッドが含まれます。 パフォーマンスを高めるために、コンピュート・コアごとに実行するポッドの数を制限して、ワーカー・ノードを過剰に使用しないようにすることを検討してください。
例えば、b3c.4x16 フレーバーのワーカー・ノードでは、ワーカー・ノードの合計容量の 75% 以下を使用する、コアあたり 10 個のポッドを実行できます。 |
| ワーカー・ノードのクォータ | 2024年1月1日以前に作成されたアカウントは、最大500ワーカーノード。 その日以降に作成されたアカウントについては、より低いクォータが一定期間続いた後、最大クォータは200となります。 割り当て量は、クラスター インフラストラクチャー・プロバイダー ごとに適用されます。 これより多いリソースが必要な場合は、
IBM サポートにお問い合わせください。 サポート依頼の際には、対象となるリージョンおよびインフラストラクチャ・プロバイダーの新しいクォータ上限を明記してください。 実行済みのクォータの一覧を表示するには、 ibmcloud ks quota ls を実行します。 |
| ワーカー・プールのサイズ | クラスタには、常に少なくとも1つのノードが存在する必要があります。 ワーカー・ノードのクォータによって、1 クラスターあたりのワーカー・プール数と 1 ワーカー・プールあたりのワーカー・ノード数は制限されます。 例えば、1 リージョンあたり 500 台というデフォルトのワーカー・ノード・クォータでは、クラスターが 1 つしか存在しないリージョンに、ワーカー・ノード 1 台のワーカー・プールを最大 500 個作成できます。 また、クラスターが 1 つしか存在しないリージョンに、ワーカー・プールを 1 個作成し、ワーカー・ノードを最大 500 台含めることもできます。 |
| Red Hat Enterprise Linux CoreOS ワーカー・ノード | クラスタに追加できるゾーンの最大数は12です。 例えば、3つのゾーンを持つ3つのRHCOSワーカープールは、そのクラスタのクォータの9/12を占めます。 |
| ワーカー・ノードの数 | クラスタは最大500ワーカーノードを持つことができます。 |
| クラスター命名 | Ingress のサブドメインと証明書が正しく登録されるようにするには、クラスターの名前の最初の 24 文字が異なっている必要があります。 自動化やテストなどの目的で、7 日以内に最初の 24 文字が 5 回以上同じ名前のクラスターを作成して削除すると、証明書の重複レート制限の暗号化に到達する可能性があります。 |
| リソース・グループ | クラスターは 1 つのリソース・グループにしか作成できず、作成後にリソース・グループを変更することはできません。 誤ったリソース・グループにクラスターを作成した場合、クラスターを削除してから、正しいリソース・グループにクラスターを再作成する必要があります。 また、ibmcloud ks cluster service bind コマンドを使用して IBM Cloud サービスと統合する必要がある場合は、このサービスがクラスターと同じリソース・グループにある必要があります。
IBM Cloud Container Registry のようにリソースグループを使用しないサービスや、 IBM Cloud Logs のようにサービスバインディングを必要としないサービスは、クラスターが別のリソースグループにある場合でも正常に動作します。 |
クラシック・クラスターの制限
IBM Cloud Kubernetes Service のクラシック・インフラストラクチャー・クラスターは、以下の制限付きでリリースされます。
コンピュート
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| 予約済みインスタンス | 予約済み容量と予約済みインスタンスはサポートされません。 |
| ワーカー・ノードのフレーバー | ワーカーノードは、特定の種類のコンピューティングリソースで利用可能です。 |
| ワーカー・ノードのホスト・アクセス | セキュリティーのため、ワーカー・ノードのコンピュート・ホストに SSH で接続することはできません。 |
ネットワーキング
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| Ingress ALB |
|
| Istio マネージド・アドオン | Istio アドオンの制限を参照してください。 |
| ネットワーク・ロード・バランサー (NLB) |
|
| VLAN 1 つのあたりのサブネット数 | 各 VLAN のサブネット数の上限は 40 個です。 |
ストレージ
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| ボリュームのインスタンス | アカウントごとに合計 250 個の IBM Cloud インフラストラクチャー・ファイルとブロック・ストレージ・ボリュームを作成できます。 この容量を超えてマウントすると、永続ボリュームのプロビジョニング時に「 out of capacity 」というメッセージが表示される場合があります。 その他のFAQについては、 ファイル および ブロックストレージ のドキュメントを参照してください。 さらにボリュームをマウントする場合は、 IBM サポートにお問い合わせください。 サポート・チケットに、アカウント ID
と、必要とするファイル・ストレージまたはブロック・ストレージのボリュームの新しいクォータを記入してください。 |
| Portworx | Portworx の制限を確認してください。 |
クラシック・ユーザー・アクセス
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| IP アドレスのアクセス | IPアドレスによるアクセスを有効にすることで特定のユーザーのアクセスを制限することは、 IBM Cloud Kubernetes Service ではサポートされていません。 ユーザーアクセスを制限したい場合、またはユーザーがアクセスできるサービスやVPCを制限したい場合は、 コンテキストベースの制限 を検討してください。 |
VPC クラスターの制限
IBM Cloud Kubernetes Service の VPC クラスターは、以下の制限付きでリリースされます。 また、基礎的な VPC クォータ、VPC 制限、VPC サービスの制限、通常のサービスの制限がすべて適用されます。
コンピュート
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| VPCごとのクラスタ | VPCはそれぞれ25クラスタまでに制限されています。 |
| 暗号化 | ワーカー・ノードの 2 次ディスクの保存データは、基礎の VPC インフラストラクチャー・プロバイダーによってデフォルトで暗号化されます。 ただし、基礎の仮想サーバー・インスタンスに独自の暗号化を持ち込むことはできません。 |
| ロケーション | VPCクラスターは、 特定のマルチゾーンリージョン でのみ利用可能です。 |
| Virtual Private Cloud | 制限と、クォータを参照してください。 |
| VPCリソースクォータ | VPCは、 vCPU, メモリ、GPU、インスタンス・ストレージ、および最適化されたインスタンス・ストレージ・リソースのクォータをアカウントごとに管理します。 パブリックインフラ上で仮想サーバーインスタンス（VSI）ワーカーノードをプロビジョニングする場合、これらのリソースは VPC アカウントクォータにカウントされます。 クォータの上限に達すると、ワーカーノードのプロビジョニングは失敗します。 現在のクォータと使用量を表示するには、 VPCリソース・メトリクスの表示を参照してください。 クォータ増量をご希望の場合は、VPCにサポートケースをご請求ください。 詳細については、「 VPC クォータ 」を参照してください。
注 ：このクォータ管理は、現在、パブリックインフラストラクチャ上のVSIワーカーノードにのみ適用されます。専用ホストおよびベアメタルワーカーノードのクォータ管理については、引き続き IBM Cloud Kubernetes Service が行います。 |
| ワーカー・ノードのフレーバー | ワーカーノードの仮想マシンおよびベアメタルワーカーでは、特定のフレーバーのみが利用可能です。 |
| ワーカー・ノードのホスト・アクセス | セキュリティーのため、ワーカー・ノードのコンピュート・ホストに SSH で接続することはできません。 |
| ワーカー・ノードの更新 | VPC ワーカーの更新処理は、ワーカーの種類によって異なります。 VPC ベアメタル環境をご利用の場合、 ibmcloud ks worker reload コマンドを使用してリロードを実行できます。 VPC 仮想サーバーインスタンスのワーカーについては、 ibmcloud ks worker replace コマンドを使用してください。 複数のワーカー・ノードを同時に置換すると、それらのノードは 1 つずつではなく、同時に削除されて置換されます。
ワーカー・ノードを置換する前に、ワークロードのスケジュールを変更するための十分な容量がクラスター内にあることを確認してください。 |
ネットワーキング
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| アプリの URL の長さ | DNS 解決は、クラスターの仮想プライベート・エンドポイント (VPE) で管理されますが、ここで解決できる URL は最大 130 文字です。 Ingress サブドメインなど、URL を使用してクラスター内のアプリを公開する場合は、URL が 130 文字以下であることを確認してください。 |
| Istio マネージド・アドオン | Istio アドオンの制限を参照してください。 |
| ネットワーク速度 | VPC プロファイルのネットワーク速度は、ワーカー・ノードのインターフェースの速度を表しています。 VPCインスタンスで利用可能な帯域幅は、ストレージとネットワークトラフィックの間で共有されます。 デフォルトでは、ストレージの割り当ては最大帯域幅の25%です。 以下の表に示すネットワーク速度は、デフォルトの25%のストレージ帯域幅割り当てを差し引いた後の、単一のネットワークインターフェイスを持つワーカーが利用可能なネットワーク帯域幅です。 |
| NodePort | NodePort を使用してアプリにアクセスできるのは、例えば VPN 接続などを使用して、プライベート VPC ネットワークに接続している場合だけです。 インターネットからアプリにアクセスするには、代わりに VPC ロード・バランサー・サービスまたは Ingress サービスを使用する必要があります。 |
| ポッドのネットワーク | VPC のアクセス制御リスト (ACL) は、サブネットのレベルでクラスターの送受信トラフィックをフィルタリングし、セキュリティー・グループは、ワーカー・ノードのレベルでクラスターの送受信トラフィックをフィルタリングします。 クラスター内部のトラフィックをポッド間のレベルで制御するために、VPC のセキュリティー・グループや ACL を使用することはできません。 代わりに、IP in IP カプセル化を使用するポッド・レベルのネットワーク・トラフィックを制御可能な Calico と Kubernetes のネットワーク・ポリシーを使用してください。 |
| Subnets |
|
| VPC ロード・バランサー | VPC ロード・バランサーの制限を参照してください。 |
ストレージ
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| Block Storage for VPC クラスター・アドオン | Block Storage for VPC クラスター・アドオンは、VPC クラスターではデフォルトで有効になっています。 ただし、このアドオンは、 UBUNTU_18_S390X ワーカー・ノードを持つクラスターでは現在サポートされていません。 UBUNTU_18_S390X ワーカー・ノードを使用する VPC クラスターを作成すると、アドオン・ポッドは Pending 状態のままになります。
ibmcloud ks cluster addon disable コマンドを実行して、アドオンを無効にすることができます。 |
| プロファイル・サイズに対するストレージ・クラス | 詳しくは、 使用可能なボリューム・プロファイル を参照してください。 |
| サポートされるタイプ |
Block Storage for VPC、IBM Cloud Object Storage、および Cloud Databases のみセットアップできます。
|
| ボリューム接続 | ボリューム接続の制限を参照してください。 |
| Portworx | Portworx の制限を確認してください。 |
| Block Storage for VPC | VPC クラスターのデフォルトのストレージクラスは変更できません。 ただし、 独自のストレージ・クラスを作成 できます。 |
VPCユーザーアクセス
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| IP アドレスのアクセス | IPアドレスによるアクセスを有効にすることで特定のユーザーのアクセスを制限することは、 IBM Cloud Kubernetes Service ではサポートされていません。 ユーザーアクセスを制限したい場合、またはユーザーがアクセスできるサービスやVPCを制限したい場合は、 コンテキストベースの制限 を検討してください。 |