Kubernetes とは何ですか?

Kubernetes は、コンテナー化されたワークロードやサービスを複数のホストにわたって管理するためのオープン・ソース・プラットフォームです。手作業による介入をまったく、あるいはほとんど必要とせずに、コンテナー化アプリのデプロイ、自動化、モニター、スケーリングを行える管理ツールを備えています。 マイクロサービスを構成するすべてのコンテナーは、管理と検出を簡単にするための論理的なユニットであるポッドにグループ分けされます。 これらのポッドを実行するコンピュート・ホストは、ポータブルで拡張性に優れ、障害発生時の自己修復機能を備えた Kubernetes クラスターで管理されます。

Kubernetesについて詳しくは、 Kubernetes の資料を参照してください。

Red Hat OpenShift on IBM Cloud クラスターを作成するにはどうすればよいですか?

Red Hat OpenShift on IBM Cloud クラスターを作成するには、まず、基本クラスター・セットアップのチュートリアルに従うか、独自のクラスター環境を設計するかを決定します。

チュートリアルを実行します

まず、 「始めに」 資料を確認してから、 使用可能なチュートリアルのいずれかを選択します。

独自のクラスター環境を設計したい

まず、 始めに の資料を確認してから、 クラスター環境戦略を作成します。

Red Hat OpenShift on IBM Cloud はどのように機能しますか?

Red Hat OpenShift on IBM Cloud を利用すると、Red Hat OpenShift で独自の IBM Cloud クラスターを作成してコンテナー化アプリをデプロイおよび管理できます。 コンテナー化アプリは、ワーカー・ノードと呼ばれる IBM Cloud インフラストラクチャーのコンピュート・ホスト上でホストされます。 コンピュートホストは、リソースが共有型または専用型の仮想マシンとして、あるいはGPUやソフトウェア定義ストレージ（SDS）の利用に最適化されたベアメタルマシンとしてプロビジョニングすることができます。 ワーカー・ノードは、IBM が構成、モニター、および管理する、高可用性の Red Hat OpenShift マスターによって制御されます。 クラスター・インフラストラクチャーのリソースの操作には IBM Cloud Kubernetes Service の API または CLI を、デプロイメントとサービスの管理には Kubernetes の API または CLI を使用できます。

クラスター・リソースのセットアップ方法について詳しくは、サービス・アーキテクチャーを参照してください。 機能と利点のリストを確認するには、利点とサービス・オファリングを参照してください。

Red Hat OpenShift on IBM Cloud を使用するとよいのはなぜですか?

Red Hat OpenShift on IBM Cloud は、Red Hat OpenShift、AI、IoT、DevOps、セキュリティー、データ分析に関連するクラウド・サービスにバインド可能なアプリを迅速にデリバリーできるように、強力なツール、直感的なユーザー・エクスペリエンス、組み込みのセキュリティーを提供するマネージド IBM Watson® オファリングです。 Kubernetes の認定プロバイダーである Red Hat OpenShift on IBM Cloud は、インテリジェントなスケジューリング、自己修復、水平スケーリング、サービスディスカバリおよびロードバランシング、自動ロールアウトおよびロールバック、ならびにシークレットおよび構成管理をサポートしています。 また、このサービスは、シンプルなクラスター管理、コンテナー・セキュリティーおよび分離ポリシーに関連する拡張機能、独自のクラスターを設計する機能、一貫性のあるデプロイメントを行うための統合運用ツールを備えています。

機能と利点の概要については、サービスを使用する利点を参照してください。

クラスターには、どのコンテナー・プラットフォームを使用できますか?

IBM Cloud では、IBM バージョンのコミュニティー Kubernetes と Red Hat OpenShift on IBM Cloud という 2 種類のコンテナー管理プラットフォームから、コンテナー化したワークロードのためのクラスターを作成できます。 選択したコンテナー・プラットフォームは、クラスター・マスターおよびワーカー・ノードにインストールされます。 後にバージョンの更新を実行できますが、以前のバージョンにロールバックしたり、別のコンテナー・プラットフォームに切り替えたりすることはできません。 複数のコンテナー・プラットフォームを使用する場合は、それぞれに別個のクラスターを作成します。

詳しくは、Red Hat OpenShift クラスターとコミュニティー Kubernetes クラスターの比較を参照してください。

Kubernetes

KubernetesUbuntu オペレーティングシステム上で動作するコンテナ化されたアプリケーションの自動化、スケーリング、および管理に利用できる、本番環境向けのオープンソースのコンテナオーケストレーションプラットフォームです。 IBM Cloud Kubernetes Service バージョンを使用すると、コミュニティーでベータ以上と見なされているコミュニティー Kubernetes API 機能にアクセスできます。 変更される可能性のある Kubernetes のアルファ機能は、通常、デフォルトでは有効になっていません。 Kubernetes を使用すると、シークレット、デプロイメント、サービスなどのさまざまなリソースを組み合わせて、高可用性コンテナー化アプリを安全に作成および管理できます。

Red Hat OpenShift

Red Hat OpenShift on IBM Cloud これは、 Kubernetes を基盤とするプラットフォームであり、 Red Hat Enterprise Linux オペレーティングシステム上で動作するコンテナ化されたアプリケーションのデリバリープロセスを加速させるために特別に設計されています。 オンプレミスとオフプレミスのクラウド間で既存の Red Hat OpenShift ワークロードを調整およびスケーリングして、複数クラウドのシナリオで同じように機能するポータブルなハイブリッド・ソリューションを実現できます。 手始めとして、Red Hat OpenShift on IBM Cloud チュートリアルに取り組んでみてください。

このサービスにはマネージドの Red Hat OpenShift マスターおよびワーカー・ノードは付属していますか?

Red Hat OpenShift on IBM Cloud に含まれるクラスターはすべて、IBM が所有する Red Hat OpenShift インフラストラクチャー・アカウントで、IBM が管理する専用 IBM Cloud マスターによって制御されます。 Red Hat OpenShift マスター (すべてのマスター・コンポーネント、コンピュート・リソース、ネットワーキング・リソース、ストレージ・リソースを含む) は、IBM サイト信頼性エンジニア (SRE) によって継続的にモニターされます。 SRE は、最新のセキュリティー規格を適用し、悪意のあるアクティビティーを検出して対処し、Red Hat OpenShift on IBM Cloud の信頼性と可用性を確保するための作業を行います。

Red Hat OpenShift は、定期的にメジャー、マイナー、またはパッチの更新をリリースしています。 これらの更新は、Red Hat OpenShift API サーバーのバージョンや Red Hat OpenShift マスター内の他のコンポーネントに影響を与える可能性があります。 パッチ・バージョンの更新は IBM によって自動的に実行されますが、マスターのメジャー・バージョンとマイナー・バージョンの更新はお客様が行う必要があります。 詳しくは、マスターの更新を参照してください。

標準クラスターのワーカー・ノードは、IBM Cloud インフラストラクチャー・アカウントにプロビジョンされます。 ワーカー・ノードはユーザー・アカウントに専用のものです。このためユーザーは、ワーカー・ノードの OS および Red Hat OpenShift on IBM Cloud コンポーネントに最新のセキュリティー更新とパッチが適用されるように、ワーカー・ノードに対するタイムリーな更新を要求する責任があります。 セキュリティー更新およびパッチは、IBM サイト信頼性エンジニア (SRE) から提供されます。SRE は、脆弱性およびセキュリティー・コンプライアンス上の問題を検出するために、お客様のワーカー・ノードにインストールされている Linux イメージを継続的にモニターしています。 詳しくは、ワーカー・ノードの更新を参照してください。

Red Hat OpenShift on IBM Cloudにはどのような種類のワークロードを移行できますか?

ユーザーが通常、さまざまな種類のクラウドに移行するワークロードの例については、「 ワークロードを IBM Cloud に移行する 」を参照してください。 　両方の環境でクラスターが実行されるハイブリッド・アプローチを選択することもできます。

インフラストラクチャーのデプロイメントを自動化できますか?

複数のクラスター、パブリック環境とプライベート環境、または複数のクラウド・プロバイダーでアプリを実行する場合は、これらの環境を横断してデプロイメント戦略をどのように成功させるかが課題となります。

オープンソースの Terraform ツールを使用して、Kubernetes クラスターを含めた IBM Cloud インフラストラクチャーのプロビジョニングを自動化できます。 このチュートリアルに従って、 単一ゾーンおよび複数ゾーンの Kubernetes クラスターと OpenShift クラスターを作成します。 クラスターを作成した後に、Red Hat OpenShift on IBM Cloud クラスター自動スケーリング機能をセットアップすることで、ワークロードのリソース要求に応じて、ワーカー・プールによってワーカー・ノードがスケールアップおよびスケールダウンされるように設定できます。

どのようなアプリを実行できますか? 既存のアプリを移動できますか、それとも新しいアプリを開発する必要がありますか?

コンテナー化アプリは、クラスター・バージョンの サポートされているオペレーティング・システム のいずれかで実行できる必要があります。 アプリのステートフル性も考慮してください。 Red Hat OpenShift on IBM Cloud で実行できるアプリの種類について詳しくは、アプリ・デプロイメントの計画を参照してください。

既にアプリがある場合は、そのアプリを Red Hat OpenShift on IBM Cloud にマイグレーションできます。 新規アプリを開発する場合は、ステートレスなクラウド・ネイティブ・アプリを開発するためのガイドラインを参照してください。

サーバーレス・アプリは使用できますか?

サーバーレス・アプリおよびジョブは、IBM Cloud Code Engine サービスを使用して実行できます。Code Engine は、イメージを作成することもできます。

アプリをクラスターに移動する前に、どのようなスキルを持っている必要がありますか?

Red Hat OpenShift は、クラスター管理者とアプリ開発者という 2 人の主要な個人に対して機能を提供するために設計されています。 各個人は、異なる技術スキルを使用してアプリを正常に実行し、クラスターにデプロイします。

クラスタ管理者の主な業務と必要な技術的知識にはどのようなものがありますか？

クラスター管理者は、クラスターの IBM Cloud インフラストラクチャーのセットアップ、操作、保護、および管理を担当します。 標準的なタスクは、以下のとおりです。

• ワークロードに十分な容量を提供できるよう、クラスターのサイズを設定します。
• 高可用性、災害復旧、および会社のコンプライアンスの規格を満たすよう、クラスターを設計します。
• コンピュート・リソース、ネットワーク、およびデータを保護するためにユーザー許可をセットアップし、クラスター内の操作を制限することで、クラスターを保護します。
• ネットワーク・セキュリティー、ネットワーク・セグメンテーション、ネットワーク・コンプライアンスを確保できるよう、インフラストラクチャー・コンポーネント間のネットワーク通信を計画および管理します。
• データの常駐およびデータの保護の要件を満たすよう、永続ストレージ・オプションを計画します。

クラスター管理者には、コンピュート、ネットワーク、ストレージ、セキュリティー、およびコンプライアンスなど、幅広い知識が必要です。 標準的な会社では、この知識はシステム・エンジニア、システム管理者、ネットワーク・エンジニア、ネットワーク設計者、IT マネージャー、セキュリティー・スペシャリスト、およびコンプライアンス・スペシャリストなど、複数のスペシャリスト間で分散されています。 クラスター管理の役割を会社内の複数の個人に割り当てて、クラスターを正常に運用するために必要な知識を得ることを検討してください。

アプリ開発者の主な業務内容と技術スキルにはどのようなものがありますか？

開発者は、Red Hat OpenShift クラスター内のクラウド・ネイティブのコンテナー化アプリを設計、作成、保護、デプロイ、テスト、実行、およびモニターします。 これらのアプリを作成・実行するには、マイクロサービスの概念、 12ファクター・アプリ ガイドライン、 Docker およびコンテナ化の原則、ならびに Red Hat OpenShift のデプロイオプション について理解している必要があります。

Red Hat OpenShift および Red Hat OpenShift on IBM Cloud では、アプリの公開とアプリの非公開化、永続ストレージの追加、他のサービスの統合、および ワークロードの保護と機密データの保護を行う方法について、複数のオプションが提供されています。 アプリを Red Hat OpenShift on IBM Cloud のクラスターに移行する前に、サポートされているオペレーティングシステム上でアプリをコンテナ化されたアプリとして実行できること、および Red Hat OpenShift と Red Hat OpenShift on IBM Cloud がワークロードに必要な機能を提供していることを確認してください。

クラスタ管理者と開発者は互いに連携しているのでしょうか？

はい。 クラスター管理者と開発者は、クラスター管理者がワークロード要件を理解してクラスターにこの機能を提供し、開発者がアプリ開発プロセスで考慮する必要がある使用可能な制限、統合、およびセキュリティー原則について把握できるように、頻繁に対話する必要があります。

どのような方法でクラスターを保護できますか?

Red Hat OpenShift on IBM Cloud の組み込みセキュリティー機能を使用して、クラスター内のコンポーネント、データ、アプリ・デプロイメントを保護し、セキュリティー・コンプライアンスとデータ保全性を確保できます。 これらの機能を使用して、Red Hat OpenShift API サーバー、etcd データ・ストア、ワーカー・ノード、ネットワーク、ストレージ、イメージ、デプロイメントを悪意のある攻撃から保護できます。 また、ロギングおよびモニタリングのための組み込みのツールを利用して、悪意のある攻撃や不審な使用パターンを検出することもできます。

クラスターのコンポーネント、および各コンポーネントのセキュリティー規格を満たす方法について詳しくは、Red Hat OpenShift on IBM Cloud のセキュリティーを参照してください。

クラスター・ユーザーには、どのようなアクセス・ポリシーを付与しますか?

Red Hat OpenShift on IBM Cloud では、Cloud Identity and Access Management (IAM) を使用して、IAM プラットフォーム・アクセス役割によってクラスター・リソースへのアクセス権限を付与するか、IAM サービス・アクセス役割によって Kubernetes 役割ベース・アクセス制御 (RBAC) ポリシーを割り当てます。 アクセスポリシーの種類に関する詳細については、「 ユーザーに適したアクセスポリシーと役割の選択 」を参照してください。

クラスタAPIキーが漏れた場合、どのようにローテーションすればよいですか？

APIキーのローテーション方法については、「 クラスタAPIキーが漏れた場合のローテーション方法 」を参照してください。

クラスターに影響を与えるセキュリティー情報のリストはどこにありますか?

Red Hat OpenShift で脆弱性が検出された場合、Red Hat OpenShift は、ユーザーに通知し、脆弱性を修復するためにユーザーが実行する必要があるアクションを説明するために、セキュリティー情報の CVE をリリースします。Red Hat OpenShift「セキュリティー情報」ページでは、Red Hat OpenShift on IBM Cloud ユーザーまたは IBM Cloud プラットフォームに影響を与える IBM Cloud セキュリティー情報 を公開しています。

一部の CVE では、Red Hat OpenShift on IBM Cloud 内の定期的なクラスター更新プロセスの一部としてインストールできる、バージョンの最新パッチ更新が必要になります。 悪意のある攻撃からクラスターを保護するために、時機を逃さずセキュリティー・パッチを適用してください。 セキュリティパッチに含まれる内容に関する詳細については、 バージョン変更履歴 を参照してください。

このサービスはベア・メタルと GPU をサポートしていますか?

特定の VPC ワーカー・ノード・フレーバーでは、GPU サポートが提供されます。 詳しくは、 VPC フレーバー を参照してください。

はい。ワーカー・ノードを単一テナントの物理ベア・メタル・サーバーとしてプロビジョンできます。 ベア・メタル・サーバーは、データ、GPU、AI などのワークロードで高性能を発揮します。 また、すべてのハードウェア・リソースがお客様のワークロード専用になるので、「ノイジー・ネイバー」に関する問題がありません。

利用可能なベアメタル・フレーバーの詳細や、ベアメタルと仮想マシンの違いについては、 計画ガイド を参照してください。

作成できるクラスターの最小サイズはどれくらいですか？

最小限のクラスタを実行するだけでは、サポートを受けるためのサービス・レベル・アグリーメント（SLA）を満たしていないことに注意してください。 また、Ingress などの一部のサービスでは、高可用性のワーカー・ノードのセットアップが必要であることに注意してください。 ワーカー・プールに 2 つのノードしかないクラスターでは、これらのサービスやアプリを実行できない可能性があります。 詳しくは、 高可用性のためのクラスターの計画 を参照してください。

クラシック・クラスターまたは VPC クラスター

クラスターには、常に少なくとも 2 つのワーカー・ノードが必要です。 なお、ワーカーノードが0個のクラスターを作成することはできません。また、ワーカーノードの電源を切ったり、課金を一時停止したりすることもできません。

Satellite クラスター

クラスターは、単一レプリカ・トポロジー (つまり、1 つのワーカー・ノードのみ) を使用して作成できます。 単一レプリカ・トポロジーを使用して Satellite クラスターを作成する場合、後でワーカー・ノードを追加することはできないことに注意してください。

このサービスはどのバージョンに対応していますか？

Red Hat OpenShift on IBM Cloud は、 Red Hat OpenShiftの複数のバージョンを同時にサポートします。 新しいバージョン（n）がリリースされた場合、それより最大2つ前のバージョンまで（ n-2 ）がサポート対象となります。 最新バージョンから 2 つより前のバージョン (n-3) は、まず非推奨になり、その後サポートされなくなります。

サポート対象のバージョンや、あるバージョンから別のバージョンへ移行するために必要な更新手順の詳細については、『 Red Hat OpenShift on IBM Cloud 』のバージョン情報 をご覧ください。

サービスはどのワーカー・ノードのオペレーティング・システムをサポートしますか?

サポートされるワーカー・ノード運用システムのクラスター・バージョン別のリストについては、 Red Hat OpenShift on IBM Cloud バージョン情報 を参照してください。

このサービスはどの地域で利用できますか?

Red Hat OpenShift on IBM Cloud は世界中で利用できます。 Red Hat OpenShift on IBM Cloud のサポート対象となるすべてのリージョンでクラスターを作成できます。

サポートされているリージョンについて詳しくは、ロケーションを参照してください。

このサービスは高い可用性を備えていますか?

はい。 デフォルトで、Red Hat OpenShift on IBM Cloud は、サービスの高可用性 (HA) を向上させるために、レプリカ、アンチアフィニティー、およびその他のオプションを使用して、クラスター・マスターなどの多数のコンポーネントをセットアップします。 クラスターのワーカー・ノード、ストレージ、ネットワーキング、ワークロードを可用性の高いアーキテクチャーを使って構成すると、冗長性と耐障害性を高めることができます。 デフォルトのセットアップとHAを増やすためのオプションの概要については、 高可用性クラスタ戦略の作成 を参照してください。

最新の HA のサービス・レベル・アグリーメント (SLA) のご利用条件については、IBM Cloud のサービスのご利用条件に関する情報を参照してください。 一般的に、SLA の可用性のご利用条件では、HA アーキテクチャーでインフラストラクチャー・リソースを構成するときに、それらのリソースを 3 つの異なるアベイラビリティー・ゾーンに均等に分散させる必要があります。 例えば、SLA の条件に基づいて HA の範囲を完全にカバーするには、合計 6 つ以上のワーカー・ノードを持つ複数ゾーン・クラスターをセットアップする必要があります。各ゾーンに 2 つのワーカー・ノードがあり、それらは 3 つのゾーンに均等に分散されます。

マルチゾーンクラスターはどのように機能するのか？

リージョン間で複数のクラスターを構築したい場合はどうすればよいですか？

複数のクラスターは、1 つの地理位置情報に属する複数のリージョン (米国南部と米国東部など) にセットアップすることも、複数の地理位置情報のリージョン (米国南部と中欧など) にセットアップすることもできます。 どちらのセットアップもアプリの可用性のレベルは同じですが、データ共有とデータ複製については複雑さが増します。 ほとんどの場合は、同じ地理位置情報の地域内で十分です。 しかし、世界中にユーザーがいる場合は、ユーザーがアプリに要求を送信する際に長い待ち時間にならないように、ユーザーがいるクラスターをセットアップすることをお勧めします。

複数のクラスタ間でワークロードの負荷分散を行うには、どのような選択肢がありますか？

複数のクラスター間でワークロードのロード・バランシングを行うには、Ingress、ルーター、ネットワーク・ロード・バランサー (NLB) のいずれかを使用してアプリをパブリック・ネットワークに公開する必要があります。 ルーター・サービスおよび NLB には、アプリへのアクセスに使用できるパブリック IP アドレスが割り当てられます。

アプリ間でワークロードのロード・バランシングを行うには、ルーター・サービスおよび NLB のパブリック IP アドレスを CIS グローバル・ロード・バランサーまたは独自のグローバル・ロード・バランサーに追加します。

プライベートネットワーク上のワークロードの負荷分散を行いたい場合はどうすればよいでしょうか？

IBM Cloud は、プライベート・ネットワーク上でグローバル・ロード・バランサー・サービスを提供しません。 ただし、サポートされている VPN オプションのいずれかを使用して、オンプレミスのネットワークでお客様がホストしているプライベート・ロード・バランサーにクラスターを接続することはできます。 Ingress、 ルーター、ネットワーク・ロード・バランサー (NLB) のいずれかを使用して、アプリをプライベート・ネットワークに公開し、VPN 設定でプライベート IP アドレスを使用してアプリをオンプレミスのネットワークに接続してください。

マスターおよびワーカー・ノードは高可用性ですか?

Red Hat OpenShift on IBM Cloud のアーキテクチャーとインフラストラクチャーは、信頼性を確保し、処理待ち時間を短く、サービスの実行可能時間を最大にするように設計されています。 デフォルトでは、Red Hat OpenShift on IBM Cloud のすべてのクラスターに、複数の Red Hat OpenShift マスター・インスタンスがセットアップされます。これにより、1 つ以上の Red Hat OpenShift マスター・インスタンスが使用不可になっても、クラスター・リソースの可用性と利用可能性を確保できます。

クラスターの可用性をさらに高め、アプリのダウン時間を回避するために、リージョンの複数のゾーンに複数のワーカー・ノードを置いてワークロードを分散させることができます。 この構成は「マルチゾーン・クラスター」と呼ばれ、ワーカーノードやゾーン全体が利用できない場合でも、アプリへのアクセスを確保します。

リージョン全体の障害に備えるため、複数のクラスターを作成し、それらを IBM Cloud の各リージョンに分散させてください。 それらのクラスターに対するネットワーク・ロード・バランサー (NLB) をセットアップすることで、クラスターのリージョン間ロード・バランシングとリージョン間ネットワーキングを実現できます。

障害発生時にもデータを使用できるようにするには、必ず永続ストレージにデータを保管してください。

クラスターの高可用性を実現する方法について詳しくは、Red Hat OpenShift on IBM Cloud の高可用性を参照してください。

アプリはゾーン間で自動的に分散されますか？

アプリのセットアップ方法によります。 可用性の高いデプロイメントの計画と、可用性の高い永続ストレージの計画を参照してください。

ワーカーノードは暗号化されていますか？

ワーカー・ノードの 2 次ディスクは暗号化されます。 詳しくは、クラスターの暗号化の概要を参照してください。 ワーカー・プールを作成した後に、ワーカー・ノード・フレーバーの名前に .encrypted が付いている (b3c.4x16.encrypted など) ことに気付くはずです。

サービスはどのようなコンプライアンス標準を満たしていますか?

IBM Cloud は、データ、金融、医療、保険、プライバシー、セキュリティー、テクノロジーなどに関する多くの国際的なコンプライアンス標準を遵守するように構築されています。 詳しくは、IBM Cloud のコンプライアンスに関する情報を参照してください。

詳細なシステム要件を確認するには、 Red Hat OpenShift on IBM Cloud のソフトウェア製品互換性レポートを実行してください。 コンプライアンスは、クラスター・ワーカー・ノード、ネットワーキング、ストレージ・リソースの基盤となる インフラストラクチャー・プロバイダーによって異なることに注意してください。

クラシック・インフラストラクチャー: Red Hat OpenShift on IBM Cloud は、以下のセキュリティ基準に準拠した管理機能を実装しています：

• EU - 米国間のプライバシー・シールドおよびスイス - 米国間のプライバシー・シールド・フレームワーク
• 医療保険の相互運用性と説明責任に関する法令 (HIPAA)
• 受託会社の内部統制基準 (SOC 1 Type 2、SOC 2 Type 2)
• 国際保証業務基準 3402 (ISAE 3402)、受託業務に係る内部統制の保証報告書
• 国際標準化機構 (ISO 27001、ISO 27017、ISO 27018)
• クレジット・カード業界のデータ・セキュリティー基準 (PCI DSS)

VPC インフラストラクチャ ： Red Hat OpenShift on IBM Cloud は、以下のセキュリティ基準に準拠した管理措置を実施しています：

• EU - 米国間のプライバシー・シールドおよびスイス - 米国間のプライバシー・シールド・フレームワーク
• 医療保険の相互運用性と説明責任に関する法令 (HIPAA)
• 国際保証業務基準 3402 (ISAE 3402)、受託業務に係る内部統制の保証報告書

Satellite: IBM Cloud Satellite の資料 を参照してください。

クラスターで他の IBM Cloud サービスを使用できますか?

IBM Cloud のプラットフォームおよびインフラストラクチャー・サービスとサード・パーティー・ベンダーのサービスを Red Hat OpenShift on IBM Cloud クラスターに追加して、自動化を実現したり、セキュリティーを強化したり、クラスターのモニター機能とロギング機能を拡張したりできます。

サポートされるサービスのリストについては、サービスの統合を参照してください。

クラスターに Cloud Pak をインストールするにはどうすればよいですか？

Cloud Pak は IBM Cloud カタログに組み込まれているので、すべての Cloud Pak コンポーネントを、既存または新規の Red Hat OpenShift クラスターに素早く構成してインストールできます。 Cloud Pak をインストールすると、 Cloud Pak に Schematics がプロビジョニングされ、 Schematics ワークスペースが自動的に作成されます。 このワークスペースを後から使用して、Cloud Pak インストールに関する情報にアクセスできます。 Cloud Pak のサービスには、Cloud Pak の URL からアクセスします。 詳細については、Cloud Pakのドキュメントを参照してください。

Cloud Pak に付属している Red Hat OpenShift の使用権をクラスターに使用することはできますか?

はい。ただし、Cloud Pak に含まれている使用権で実行できる特定のワーカー・ノード・フレーバーに OpenShift Container Platform がインストールされている場合に限られます。 ご利用可能な特典を確認するには、こちらにログインしてください IBM Passport Advantage。 IBM Cloud ID が IBM パスポート・アドバンテージ ID と一致していなければならないことに注意してください。

--entitlement ocp_entitled コンソールで「 Cloud Pak 」の権限を使用するか、または ibmcloud oc cluster create classic または ibmcloud oc worker-pool create classic CLIコマンドで、クラスタまたはワーカープールを作成できます。 必ず、使用権のあるワーカー・ノード数とフレーバーを正確に指定してください。

使用権を超えないようにしてください。 他のクラウド・プロバイダーや他の環境でも OpenShift Container Platform の使用権を使用できることを忘れないでください。 後で請求に関する問題が起きないように、使用権のあるものだけを使用していることを確認してください。 例えば、CPU 4 個とメモリー 16 GB のワーカー・ノード 2 台に対する OCP ライセンスの使用権がある場合に、CPU 4 個とメモリー 16 GB のワーカー・ノード 2 台からなるワーカー・プールを作成したとします。 ライセンス全体を使用したため、他のワーカー・プール、クラウド・プロバイダー、または環境に同じライセンスを使用することはできません。

同じ Red Hat OpenShift on IBM Cloud クラスターに複数の Cloud Pak をインストールできますか?

はい。ただし、各 Cloud Pak が実行に十分なコンピュート・リソースを持つように、さらにワーカー・ノードを追加する必要がある場合があります。 また、 Cloud Pak for Dataなどのクラスターごとに同じ Cloud Pak のインスタンスを 1 つだけインストールすることも、 Cloud Pak for Automationなどの同じクラスター内の異なるプロジェクトに複数のインスタンスをインストールすることもできます。 サイジング情報については、 Cloud Pak の資料を参照してください。

Cloud Pak には何が含まれていますか?

Cloud Pak は、企業のユース・ケースに合うようにソフトウェアをバンドルとしてまとめ、ライセンスを交付し、最適な動作を行うようにコンテナー化したものです。例えば、一貫したデプロイメント、アクセス制御、請求処理が可能になります。 ワークロードに合わせて、ソフトウェアの仮想プロセッサコアの最適な組み合わせを選択することで、Cloud Paksの一部を必要な時に柔軟に利用できます。 また、仮想プロセッサー・コアの組み合わせは、ワークロードの進化に応じて変更することもできます。

Cloud Pak に応じて、ライセンス交付を受けた IBM ソフトウェアとオープンソース・ソフトウェアが一緒にバンドルされ、統合された管理エクスペリエンスで、ロギング、モニター、セキュリティー、およびアクセスの機能を利用できます。

• IBM 製品 ：Cloud Paksは、 IBM Marketplace から提供されるライセンス済みの IBM ソフトウェアおよびミドルウェアの機能を拡張し、これらの製品をお客様のクラスターと統合することで、ハイブリッドクラウドワークロードの近代化、最適化、および実行を実現します。
• オープンソースのソフトウェア: Cloud Pak には、クラウド・ネイティブでポータブルなハイブリッド・クラウド・ソリューションを提供するために、オープンソースのコンポーネントが含まれているものもあります。 一般に、オープンソースのソフトウェアはマネージドではないため、お客様がコンポーネントを最新かつ安全な状態に維持する必要があります。 しかし、Cloud Pak では、Cloud Pak コンポーネントのライフサイクル全体の管理、およびコンポーネントで実行するワークロードの管理を一貫した方法で行うことができます。 このオープンソースソフトウェアは Cloud Pak にバンドルされているため、 IBM によるサポートや、アクセス制御や課金などの IBM Cloud の特定機能との連携といったメリットを享受できます。

各 Cloud Pak の構成要素については、『 Cloud Pak 』のドキュメントを参照してください。

Cloud Pak を使用するために他に知っておくべきことは何ですか?

Cloud Pak をセットアップするときに、Red Hat OpenShift 固有のリソース (セキュリティー・コンテキスト制約など) を操作する必要がある場合があります。 oc get scc など、これらのリソースを操作する際は、必ず oc CLI または kubectl バージョン 1.12 CLI を使用してください。 バージョン 1.11 の kubectl CLI には、Red Hat OpenShift 固有のリソースに対してコマンド (kubectl get scc など) を実行するとエラーが生成されるというバグがあります。

クラスターで現在使用しているサード・パーティーのオープンソース・ツールは IBM でサポートされているのでしょうか?

IBM オープンソースおよびサードパーティに関する方針 をご覧ください。

課金されるものは何ですか? クラスターのコストを見積もって抑制することはできますか?

クラスターのコストの管理を参照してください。

クラスターを前のバージョンにダウングレードできますか?

いいえ。クラスターを前のバージョンにダウングレードすることはできません。

現在のクラスターを別のアカウントに移動できますか?

いいえ、作成されたアカウントとは別のアカウントにクラスターを移動することはできません。

どうすればクラスターをサポート対象の状態に維持できますか?

• クラスターが常にサポートされる Red Hat OpenShift バージョンを実行していることを確認します。
• 新しい Red Hat OpenShift マイナー・バージョンがリリースされると、すぐに旧バージョンは非推奨になり、その後にサポート対象外になります。

詳しくは、マスターの更新およびワーカー・ノードを参照してください。

サポートされないオペレーティング・システムをクラスターが実行している場合、どの操作がブロックされますか?

オペレーティング・システムがサポートされていない場合、以下の操作はブロックされます。

• ワーカー再ロード
• ワーカーの更新なしの置換
• ワーカーを更新に置換
• ワーカー更新
• ワーカー・プール作成 (サポートされない OS を使用)
• ワーカー・プールの再バランス
• ワーカー・プールのサイズ変更 (スケールアップ)
• ワーカー・プール・ゾーンの追加
• インスタンス・グループのサイズ変更 (パッチ)
• autoscaler 削除ワーカー (v2/autoscalerRemoveWorker)

機密コンテナの価格は？

IBM は、機密容器に対して追加料金を請求しない。 標準 IBM Cloud 料金でVSIとして開始される各秘密ポッドのサービスおよび標準VSI料金のコストは変わらない。

機密コンテナ用のCVM（podvm ）を自分で作ることはできますか？

はい。 ConfigMap は、設定したコンフィデンシャル仮想マシン（CVM）を指すように設定できます。 IBM は、自分で作るためのサポートは提供していない。 IBM サポートでは解決できない問題が発生する可能性があります。

機密コンテナの受託者として何を使うべきか？

開発には、 VM 上の Docker / Podman でシンプルなトラスティーを走らせれば十分だ。 これらのコンテナは、 OpenShift で直接設定することもできる。 しかし、トラスティは環境のセキュリティの証明者であるため、信頼されていないはずの OpenShift クラスタ内でトラスティを使用しないでください。

本番環境では、インテル® トラスト・オーソリティを使用し、インテル® トラスト・オーソリティを使用するように INITDATA を設定します。 セキュリティ・グループ、セキュア・バイ・デフォルト OpenShift パーミッションなど、クラスターがインテルと通信できるようにする必要があります。

機密コンテナのサポートはどこで受けられますか？

OpenShift Red Hat OpenShift on IBM Cloud の Sandboxed Containers Operator は、 と の両方でサポートされています。 Red Hat IBM 両方のサービスに対して標準的なサポートチャネルを使用する。 OpenShift が IBM Cloud を通してライセンスされている場合は、 IBM までご連絡ください。 Red Hat から OpenShift のライセンスをお持ちの場合は、 Red Hat までご連絡ください。

ワーカーノードあたりいくつのピアポッドを実行できますか？

ワーカーノードごとに実行できるピアポッドの数は、複数の制限によって制御されます：

1. PEERPODS_LIMIT_PER_NODE の設定に従います： peer-pods-cm ConfigMap のこの設定可能な制限は、ワーカーノードごとにスケジュールできるピアポッドVSIの最大数を制御します。 デフォルト値は10です。 この値を増やすことはできるが、以下の他の制約も考慮しなければならない。

2. Kubernetes ポッド数制限： Kubernetes は、 vCPUs の数に基づいて、ノードあたりのポッド数の合計を制限します（ vCPU あたり 10 ポッド）。 例えば、 16x64 ワーカーノードは最大110ポッドをサポートできる。 各ピアポッドはワーカーノード上の Kubernetes ポッドコンストラクトによってバックアップされているため、実際のワークロードが別のVSIで実行されていても、この制限が適用されます。

3. ワーカーノードのCPUとメモリ：各ピアポッドは、 Kubernetes ポッド構築のために、ワーカーノードで約 250m CPU と 120Mi メモリを消費します。 ワーカーノードが、希望する数のピアポッドをサポートするのに十分なCPUとメモリを備えていることを確認する必要があります。

PEERPODS_LIMIT_PER_NODE ：

1. openshift-sandboxed-containers-operator 名前空間の peer-pods-cm ConfigMap を更新する。 詳細については、 機密コンテナの作成を 参照のこと。

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'
   

2. Cloud API Adapter デーモンセットを再起動します。

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. 新しいリミットが適用されていることを確認する。

   oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
   

最適な PEERPODS_LIMIT_PER_NODE 値を計算するときは、ワーカーノードのプロファイルを考慮してください。 たとえば、 16x64 ワーカーノード（16 vCPUs ）では、CPUだけに基づく理論上の最大値は、ノードあたり約24のピアポッドになります（ピアポッドあたり 250m CPUを想定し、他のシステムプロセスを考慮）。 しかし、 Kubernetes、1ノードあたり110ポッドというポッド数制限の制約もあります。

Insufficient kata.peerpods.io/vm エラーとはどういう意味ですか？

ピア・ポッドのスケジューリング時に以下のようなエラーが発生した場合：

Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.

このエラーは、ワーカーノードが PEERPODS_LIMIT_PER_NODE の上限に達したことを示しています。 kata.peerpods.io/vm リソースは、各ワーカーノードで利用可能なピアポッドスロットの数を表します。

この問題を解決するには:

1. 電流の上限と配分を確認する。

   oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}'
   

2. 現在稼働しているピアポッドの数を確認します。

   oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l
   

3. ワーカー・ノードあたりいくつのピア・ポッドを実行できますか 」の説明に従って、 PEERPODS_LIMIT_PER_NODE の値を増やしてください。

4. あるいは、クラスタにワーカーノードを追加して総容量を増やすこともできます。

機密コンテナは、NIST 800-53 R5 のような特定のセキュリティ基準を満たすことができるか

OpenShift Sandboxed Containers Operator 1.12.1 にアップグレードした後、なぜ IAM 認証エラーが発生するのでしょうか？

OpenShift Sandboxed Containers Operator をバージョン 1.12.1 にアップグレードした後、Cloud API Adapter (CAA) のログに次のようなエラーが表示される場合があります

cloud-api-adaptor: cluster error with:
 Unauthorized
further details:
 {
    "StatusCode": 401,
    "Result": {
        "code": "A0007",
        "description": "You do not have the correct permissions to perform this action..."
    }
}

このエラーが発生するのは、バージョン 1.12.1 において、 IBM Cloud のIKSクラスターサービスAPIからクラスターのセキュリティグループを自動的に取得するという新しい要件が導入されたためです。 IBMCLOUD_IAM_PROFILE_ID を使用して認証を行う場合（コンピュートリソースの識別情報）、IAM プロファイルには、クラスタサービス API をクエリするために必要な権限が設定されていない可能性があります。

この問題を解決するには、次のいずれかの方法を選択してください

1. IAMの権限を追加で付与する （推奨）：IAMプロファイルを更新し、IKSクラスタサービスAPIに対する権限、具体的には GetClusterTypeSecurityGroups() を呼び出す権限を含めるようにします。 必要な権限を追加するには、 IBM Cloud の管理者にお問い合わせください。

2. セキュリティグループ ID を明示的に設定する ： peer-pods-cm （ ConfigMap ）で環境変数 IBMCLOUD_VPC_SG_ID を設定し、クラスタのセキュリティグループの自動検索を無効にします：

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'
   

   次に、Cloud API Adapter のデーモンセットを再起動します：

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. APIキー認証を使用する ： IBMCLOUD_IAM_PROFILE_ID 認証から、通常はより広範な権限を持つ IBMCLOUD_API_KEY 認証に切り替えます。 IAMプロファイルを使用する代わりに、 peer-pods-secret のシークレットを自身のAPIキーで更新してください。

バージョン 1.12.1 での変更点の詳細については、 アップストリームのcloud-api-adaptorのコミット dde66055 を参照してください。

具体的な安全保障上の利益については、 IBM チームにお問い合わせください。

VPCワーカーノードのデフォルトタイムゾーンは？

2026 年 1 月 27 日にリリースされた パッチ バージョン 4.16.56_1602 以降、VPC クラスタの今後のすべてのパッチは、ワーカー ノードのローカル時刻を UTC に設定します。