Kubernetes とは何ですか?

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

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

IBM Cloud Kubernetes Service クラスターを作成するにはどうすればよいですか?

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

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

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

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

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

IBM Cloud Kubernetes Service はどのように機能しますか?

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

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

IBM Cloud Kubernetes Service を使用するとよいのはなぜですか?

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

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

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

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 チュートリアルに取り組んでみてください。

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

IBM Cloud Kubernetes Service に含まれるクラスターはすべて、IBM が所有する IBM Cloud インフラストラクチャー・アカウントで、IBM が管理する専用 Kubernetes マスターによって制御されます。 Kubernetes マスター (すべてのマスター・コンポーネント、コンピュート・リソース、ネットワーキング・リソース、ストレージ・リソースを含む) は、IBM サイト信頼性エンジニア (SRE) によって継続的にモニターされます。 SRE は、最新のセキュリティー規格を適用し、悪意のあるアクティビティーを検出して対処し、IBM Cloud Kubernetes Service の信頼性と可用性を確保するための作業を行います。 クラスターのプロビジョン時に自動的にインストールされるアドオン (ロギング用の Fluentd など) は、IBM によって自動的に更新されます。 ただし、一部のアドオンの自動更新を無効にして、マスターおよびワーカー・ノードとは別に手動で更新することもできます。 詳しくは、クラスター・アドオンの更新を参照してください。

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

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

どのような種類のワークロードを IBM Cloud Kubernetes Serviceに移行できますか?

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

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

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

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

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

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

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

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

サーバーレス・アプリおよびジョブは、 IBM Cloud Code Engine サービスを使用して実行できます。 Code Engine は、イメージを作成することもできます。 Code Engine は、基盤となるテクノロジーを使用する必要がないように設計されています。 ただし、Kubernetes または Knative に基づく既存のツールがある場合は、それを Code Engine と一緒に使用することができます。 詳しくは、 Kubernetes を使用したアプリケーションとの対話を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

APIキーのローテーション方法については、「 リークが発生した場合、クラスタAPIキーをローテーションするにはどうすればよいですか 」を参照してください。

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

Kubernetes に脆弱性が見つかった場合、Kubernetes は、セキュリティー情報で CVE を発表してユーザーに通知し、脆弱性に対処するためにユーザーが実行する必要があるアクションについて説明します。 IBM Cloud Kubernetes Service ユーザーや IBM Cloud プラットフォームに影響のある Kubernetes のセキュリティー情報は、IBM Cloud のセキュリティー情報で公開されています。

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

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

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

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

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

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

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

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

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

Satellite クラスター

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラスターに 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 ks cluster create classic または ibmcloud ks 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 オープンソースおよびサードパーティに関する方針 をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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