IBM Cloud Docs
4.15 バージョン情報と更新アクション

4.15 バージョン情報と更新アクション

このバージョンは非推奨。 クラスタをできるだけ早く サポートされているバージョンに アップデートしてください。

Red Hat OpenShift on IBM Cloudのバージョン 4.15 に関する情報を確認します。 このバージョンは Kubernetes バージョン 1.28 に基づいている。

クラスターの更新に関する一般情報、または別のバージョンに関する情報をお探しですか? Red Hat Red Hat OpenShift on IBM Cloud のバージョン情報 およびバージョン 4.15 リリース・ノートを参照してください。

このバッジは、 Kubernetes バージョン 1.28 の認証 Red Hat OpenShift on IBM Cloud
Kubernetes バージョン 1.28 の認証バッジを示します。

Red Hat OpenShift on IBM Cloud は、CNCF ソフトウェア適合性認定プログラムに基づく、バージョン の認定 製品です。 Kubernetes 1.28 Kubernetes Kubernetes ® は、The Linux Foundation の米国およびその他の国における登録商標であり、The Linux Foundation のライセンスに従って使用されます。

リリース・タイムライン

次の表は、バージョン 4.15 のリリース予定スケジュールです。 この情報は、バージョンがサポート対象外になる可能性がある一般的な時間を見積もるなど、計画の目的に使用できます。

剣標 () の付いた日付は暫定的な日付であり、変更されることがあります。

Red Hat OpenShift on IBM Cloud バージョン 4.15のリリース履歴。
サポートされましたか? Red Hat OpenShift / Kubernetes バージョン リリース日 サポート終了日
サポート対象 4.15 / 1.28 2024 年 4 月 24 日 2026 年 1 月 8 日

更新の準備

クラスター をバージョン 4.15 に更新するときに必要になる可能性がある変更を確認します。 この情報は、更新時にデプロイ済みアプリに影響を与える可能性がある更新を要約しています。

バックアップおよびリストアの Helm チャートは、 Red Hat OpenShift on IBM Cloud 4.15 クラスターでサポートされています。 ただし、サポートされているのは COS 直接エンドポイントのみです。 例: s3.direct.us.cloud-object-storage.appdomain.cloud

マスターの前に行う更新

以下の表に、クラスターのマスターを更新する前に実行する必要がある操作を示します。

マスターを Red Hat OpenShift にアップデートする前に行うべき変更 4.15
タイプ 説明
非サポート: 非推奨および廃止された OpenShift 機能 詳しくは、 OpenShift バージョン 4.15 の非推奨フィーチャーと削除されたフィーチャー および OpenShift Container Platform 4.15への更新の準備 で、必要なアクションを確認してください。
OpenShift の既知の問題 詳しくは、 OpenShift バージョン 4.15 の既知の問題 で、必要なアクションを確認してください。
アップグレードには、 OpenShift クラスター・バージョンの現行性が必要です。 OpenShift クラスターのバージョン状況が、更新が既に進行中であることを示している場合、クラスター・マスターのアップグレードはキャンセルされます。 見る どしてOpenShiftクラスターのバージョンが最新ではないことを示す 詳細については。
アップグレードするには、 OpenShift クラスター・バージョンのアップグレード可能な状態を解決する必要があります。 OpenShift クラスタのバージョン Upgradeable ステータス条件が、クラスタのアップグレード不可を示している場合、クラスタマスターのアップグレードはキャンセルされます。 詳しくは、 Cannot complete cluster master upgrade メッセージが表示される理由 を参照してください。
VPCクラスタをバージョン4.15に作成または更新する際のVPEゲートウェイの変更 4.15クラスタの作成または4.15へのアップデートの際、VPCクラスタに使用されるVPEゲートウェイに重要な変更があります。 このような変化には対処が必要かもしれない。 変更を確認し、必要なアクションを決定するには、VPEゲートウェイの作成情報 を参照してください。

クラスタの Upgradeable ステータスを確認する

以下のコマンドを実行して、クラスタの Upgradeable ステータスを確認します。

oc get clusterversion version -o json | jq '.status.conditions[] | select(.type == "Upgradeable")'

Upgradeable 状況が False である場合の出力例。

{
  "lastTransitionTime": "2023-10-04T15:55:54Z",
  "message": "Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958395 for details and instructions.",
  "reason": "AdminAckRequired",
  "status": "False",
  "type": "Upgradeable"
}

Upgradeable 状況が False の場合、条件情報には、アップグレード前に従う必要がある指示が記載されています。 詳しくは、「 管理者の確認応答の提供」を参照してください。

バージョン 4.15 で作成された VPC クラスターの重要なネットワーキングの変更

バージョン 4.15以降、 Red Hat OpenShift on IBM Cloud では、Secure by Default Cluster VPC Networking という VPC クラスター用の新しいセキュリティー機能が導入されました。

概略すると、 Red Hat OpenShift on IBM Cloud VPC クラスターのセキュリティー体制は、すべてのアウトバウンド・トラフィックを許可し、必要に応じてトラフィックを選択的にブロックするメカニズムをユーザーに提供することから、クラスター機能にとって重要ではないすべてのトラフィックをブロックし、必要に応じてトラフィックを選択的に許可するメカニズムをユーザーに提供するように変更されました。

バージョン 4.15 以降の新しい Red Hat OpenShift on IBM Cloud VPC クラスターをプロビジョンする場合、デフォルトのプロビジョニング動作では、クラスターが機能するために必要なトラフィックのみが許可されます。 それ以外のアクセスは遮断される。 「Secure by Default Networking」を実装するために、デフォルトの VPC セキュリティー・グループ設定と、一般的な IBM サービス用の新しい仮想プライベート・エンドポイント (VPE) が変更されています。

「Secure by Default Networking」には、以下のような重要な注意事項があります。

  • VPC クラスターにのみ適用されます。 クラシック・クラスターは影響を受けません。

  • 既存のクラスターには影響しません。 VPC 内の既存のクラスターは、現在のように機能し続けます。

  • 新しくプロビジョンされた Red Hat OpenShift on IBM Cloud クラスター (バージョン 4.15) にのみ適用されます。 バージョン 4.15にアップグレードされた既存の Red Hat OpenShift on IBM Cloud クラスターのセキュリティー・グループ構成 (行ったカスタマイズを含む) は変更されません。

  • バージョン 4.15 以降で作成されたクラスターのデフォルトの動作では、Secure by Default アウトバウンド・トラフィック保護が有効になります。 ただし、UI、CLI、API、および Terraform の新規パラメーターでは、この機能を無効にすることができます。 クラスターの作成後に、アウトバウンド・トラフィック保護を有効または無効にすることもできます。

  • VPC でカスタム DNS リゾルバーを使用している場合、新しいバージョン 4.15 クラスターをプロビジョンすると、IKS 管理セキュリティー・グループ (kube-<clusterID>) 上のリゾルバー IP アドレスを介したトラフィックを許可するルールが自動的に追加されます。

デフォルトで作成されるセキュリティー・グループ、ルール、および VPE を含む、Secure by Default Cluster VPC ネットワーキングの概要については、 Understanding Secure by Default Cluster VPC Networking を参照してください。

どの接続が許可されているか。

デフォルトでセキュア・アウトバウンド・トラフィック保護が有効になっている VPC クラスターでは、以下の接続が許可されます。

  • VPE ゲートウェイを介して必要なコンテナー・イメージをプルするために、内部 IBM *.icr.io レジストリーにアクセスします。
  • VPE ゲートウェイを介したクラスター・マスターおよび Red Hat OpenShift on IBM Cloud API へのアクセス。
  • プライベート IBM ネットワークを介したロギングやモニタリングなど、その他の重要な IBM サービスへのアクセス。
  • IBM Cloud DNSにアクセスする。

どの接続がブロックされていますか?

デフォルトでブロックされている接続の以下の例を確認してください。 アプリが必要とするこれらの外部ソースまたはその他の外部ソースへのアウトバウンド・トラフィックを選択的に有効にすることができます。

  • quay.io や Docker Hub などのパブリック・レジストリーからイメージをプルしています。
  • Red Hat Marketplace および OperatorHubにアクセスします。
  • パブリック・ネットワークを介した任意のサービスへのアクセス。

ワーカーとマスターの間のバックアップ通信の変更点

VPC クラスター・ワーカーは、プライベート・ネットワークを使用してクラスター・マスターと通信します。 以前は、パブリック・サービス・エンドポイントが有効になっている VPC クラスターでは、プライベート・ネットワークがブロックまたは使用不可の場合、クラスター・ワーカーは、パブリック・ネットワークを使用してクラスター・マスターと通信するようにフォールバックできました。

Secure by Default アウトバウンド・トラフィック保護を使用するクラスターでは、クラスター・ワーカーからのパブリック・アウトバウンド・トラフィックがブロックされるため、パブリック・ネットワークへのフォールバックはオプションではありません。 このパブリック・ネットワーク・バックアップ・オプションを許可するために、アウトバウンド・トラフィック保護を無効にすることをお勧めします。ただし、より適切な方法があります。 代わりに、プライベート・ネットワークを介したワーカーとマスターの間の接続に一時的な問題がある場合は、その時点で、 kube-clusterID セキュリティー・グループに一時的なセキュリティー・グループ・ルールを追加して、クラスター・マスターの apiserver ポートへのアウトバウンド・トラフィックを許可することができます。 この方法では、すべてのトラフィックではなく、 apiserver のトラフィックのみを許可します。 後で問題が解決されたら、一時ルールを削除できます。

4.15 クラスターの作成後のアウトバウンド・トラフィックの許可

アウトバウンド・トラフィック保護を有効にしてバージョン 4.15 クラスターを作成した場合、外部ネットワーク接続を必要とする依存関係が原因で、アプリまたはサービスでダウン時間が発生する可能性があります。 アウトバウンド・トラフィックを選択的に有効にするか、すべてのアウトバウンド・トラフィックを許可するには、以下のオプションを確認してください。

詳しくは、 VPC クラスターでのアウトバウンド・トラフィック保護の管理 を参照してください。

VPEゲートウェイ作成情報

VPCクラスタがバージョン 4.15 で作成または更新されると、以下のVPEゲートウェイが存在しない場合は作成されます。

バージョン4.15におけるVPEゲートウェイの変更点
VPEのDNS名 サービス バージョン
s3.direct.<region>.cloud-object-storage.appdomain.cloud および *.s3.direct.<region>.cloud-object-storage.appdomain.cloud Cloud Object Storage バージョン 4.15 以降
config.direct.cloud-object-storage.cloud.ibm.com Cloud Object Storage 構成 バージョン 4.15 以降
<region>.private.iaas.cloud.ibm.com VPC インフラストラクチャー バージョン 4.15 以降
icr.io」と「*.icr.io* Container Registry バージョン 4.14 以降
api.<region>.containers.cloud.ibm.com* Red Hat OpenShift on IBM Cloud バージョン 4.14 以降
  • 4.15にアップデートされたクラスタでは、これらのVPE Gatewayはクラスタが4.14のときに作成されているので、すでに存在しているはずです。

これらのVPEゲートウェイは、VPC内のすべてのリソースで共有され、最初に作成されると、これらのサービスに関連するIPアドレスを変更し、アクセスを制限します。

VPC 内のリソースが、VPE ゲートウェイがまだ存在しないこれらのサービスのいずれかを使用している場合は、アップデートの前と、場合によってはアップデート中に、以下に説明するアクションを実行して、リソースが引き続きアクセスできるようにする必要があります。

新しい4.15クラスタを作成するか、既存の4.14クラスタのマスタをアップグレードするかによって、実行する手順は異なります。

  • 新しい4.15クラスタには、上記のSecure by Default設定が適用されます。
  • アップグレードされた既存の4.14クラスタは、引き続き古いセキュリティグループモデルを使用します。

バージョン4.15へのアップグレード時に作成されるVPEゲートウェイ

4.15用の3つの新しいVPEゲートウェイが、VPCにまだ存在していなければ作成される。 また、クラスターワーカーがいる各ゾーンのVPEゲートウェイには、ゾーンごとに1つのIPアドレスが追加されます。 これらのIPアドレスは、そのゾーンの既存のVPCサブネットの1つから取得される。

VPEゲートウェイは既存の'kube-<vpcID> セキュリティグループに入れられ、デフォルトではすべてのトラフィックを許可する。 このセキュリティグループを変更しない限り、新しいVPE Gatewayへのインバウンドアクセスを許可するルールを追加する必要はない。

kube-<vpcID> セキュリティ・グループを変更した場合は、これらのサービスを使用するVPC内のすべてのリソースが、このセキュリティ・グループへのインバウンド・アクセスを許可されていることを確認する必要があります。 また、サブネット上のネットワークACL、リソース自体のセキュリティグループ、またはカスタムVPCルートが、これらの新しいVPEゲートウェイへのアクセスをブロックしていないことを確認してください。

新しい4.15クラスタ作成時の新しいVPEゲートウェイ設定

VPEゲートウェイがまだVPCに存在しない場合は、5つの新しいVPEゲートウェイが作成される。 また、クラスタワーカーがいる各ゾーンのVPEゲートウェイには、ゾーンごとに1つのIPアドレスが追加されます。 これらのIPアドレスは、そのゾーンの既存のVPCサブネットの1つから取得される。

VPE ゲートウェイは新しい「kube-vpegw-<vpcID> セキュリティグループに入れられ、クラスタワーカーセキュリティグループ「kube-<clusterID> 新しい VPE ゲートウェイへのインバウンドトラフィックのみが許可されます。

クラスタを作成する前に、これらのエンドポイントにアクセスするVPC内のリソースについて、サブネット上のネットワークACL、リソース自体のセキュリティグループ、または新しいVPEゲートウェイへのアクセスをブロックするカスタムVPCルートがないことを確認してください。

クラスタが更新されたら、「kube-vpegw-<vpcID> セキュリティ・グループが作成されるのを確認してください。 作成後、必要なインバウンドルールを追加して、クラスタワーカーではないすべてのリソースが、作成される新しいVPEゲートウェイにアクセスできるようにします。 VPC内のすべてのクラスタワーカーは、クラスタの作成時に自動的に追加されるセキュリティグループルールによって、すでにこれらのVPEゲートウェイにアクセスできることに注意してください。

同様の使用例についての詳細は、VPCアプリケーションのトラブルシューティング を参照してください。

一般的な問題とトラブルシューティング