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

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

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

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

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

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

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

リリース・タイムライン

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

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

Red Hat OpenShift on IBM Cloud バージョン 4.14のリリース履歴。
サポートされましたか? Red Hat OpenShift / Kubernetes バージョン リリース日 サポート終了日
サポート対象 4.14 / 1.27 2023 年 12 月 13 日 2026 年 1 月 8 日

更新の準備

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

マスターの前に行う更新

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

プライベート・サービス・エンドポイントを使用する VPC クラスターのクラスター・マスター・アクセスは、バージョン 4.13から大幅に変更されました。 このタイプのクラスターを更新する前に、以下の情報を確認し、クラスターをアップグレードする前にどのような変更を行う必要があるかを検討してください。 また、プライベート・サービス・エンドポイントのみを持つ新しい 4.14 クラスターを作成する前に、これを考慮してください。

マスターを Red Hat OpenShift にアップデートする前に行うべき変更 4.14
タイプ 説明
非サポート: 非推奨および廃止された OpenShift 機能 詳しくは、 OpenShift バージョン 4.14 の非推奨フィーチャーと削除されたフィーチャー および OpenShift Container Platform 4.14 で必要なアクションを確認してください。
OpenShift の既知の問題 詳しくは、 OpenShift バージョン 4.14 の既知の問題 で、必要なアクションを確認してください。
アップグレードには、 OpenShift クラスター・バージョンの現行性が必要です。 OpenShift クラスタのバージョンステータスが更新中を示している場合、クラスタマスターのアップグレードはキャンセルされます。 見る どしてOpenShiftクラスターのバージョンが最新ではないことを示しますか?詳細については。
変更されたVPCセキュリティグループに必要なルール クラスタのデフォルトの VPC セキュリティグループを変更している場合は、アップグレード前に、openvpn または Konnectivity ノードポートへの TCP トラフィックを一時的に許可するセキュリティグループルールを追加する必要があります。 デフォルトのVPCセキュリティグループに追加するルールは、 kube-<clusterID> セキュリティグループの既存のUDPルールと一致する必要があります。 このルールがない場合、ブロックされた TCP トラフィックがウェブフックの正常な動作を妨げ、クラスタが壊れてアップグレードが失敗する可能性があります。 セキュリティグループにルールを追加する方法については、 コンソールでのセキュリティグループルールの作成 または コマンドラインでのセキュリティグループルールの作成 を参照してください。
アップグレードには、 OpenShift クラスター・バージョンのアップグレード可能な状態を解決する必要があります。 OpenShift クラスタのバージョン Upgradeable ステータス条件がクラスタのアップグレード不可を示している場合、クラスタマスターのアップグレードはキャンセルされる可能性があります。 クラスターがアップグレード可能かどうかを判別するには、 クラスターの Upgradeable 状況の確認 を参照してください。 クラスターがアップグレード可能状況でない場合、条件情報は、アップグレードの前に従う必要がある指示を提供します。 詳しくは、「 管理者の確認応答の提供」を参照してください。
ポッド・セキュリティー許可ラベルの同期の変更 特権の高い名前空間 defaultkube-public、および kube-system は、ポッド・セキュリティー許可の適用から除外されます。 つまり、ポッド・セキュリティー許可ラベルの同期により、これらの名前空間で privileged ポッド・セキュリティー許可が確実に適用されるようになります。 security.openshift.io/scc.podSecurityLabelSync 名前空間ラベルの値を false に設定することで、他の名前空間のポッド・セキュリティー許可ラベルの同期を無効にすることができます。 詳しくは、 Understanding and managing pod security admissionを参照してください。
OpenVPN が Konnectivity に置き換えられました Konnectivity は、 OpenShift マスターからワーカー・ノードへの通信を保護するために使用される Kubernetes API サーバー・ネットワーク・プロキシーとしての OpenVPN に代わるものです。 OpenVPNて OpenShift のマスターノードとワーカーノード間の通信を安全に実装している場合は、Konnectivityをサポートするようにアプリケーションを更新してください。
クラシックインフラストラクチャ プライベートサービス エンドポイントの有効化 クラスタでプライベートサービスエンドポイントが有効になっている場合は、必要なアカウント要件が満たされていることを確認してください。 詳しくは、VRF およびサービス・エンドポイントの有効化を参照してください。
VPC クラスターに対するネットワーキングの変更 バージョン4.13以前では、VPCクラスタはContainer Registryのプライベート・クラウド・サービス・エンドポイントを通じてIBM Cloud Container Registryからイメージを取得します。 バージョン 4.14 以降では、イメージがプライベート・サービス・エンドポイントではなく VPE ゲートウェイを介してプルされるように、このネットワーク・パスが更新されます。 更新アクションについては、 VPC クラスターのネットワーキングの変更 を参照してください。
VPC バージョン 4.13 で導入されたプライベート・サービス・エンドポイントのみを使用する VPC クラスターのクラスター・アクセスの変更が元に戻されました。
  • 以前は、プライベートサービスエンドポイントのみを持つVPCクラスターで、 OpenShift コンソールからクラスターにアクセスしたり、terraformスクリプトを実行したり、 oc login コマンドで kubeconfig ファイルを作成したり、トークンを取得するためにoauthを必要とする同様のAPIコールを行う場合、プライベートサービスエンドポイントにアクセスしていました。プライベートサービスエンドポイントは、 https://cX00.private.us-south.containers.cloud.ibm.com:port という形式でした。 この設定では、 IBM Cloud プライベートネットワーク 166.8.0.0/14 へのアクセスのみが必要でした。
  • バージョン 4.13 で導入された変更点 : 4.13 において、 Red Hat OpenShift コンソールへのアクセス、 oc login コマンドの実行、または同様の API コールを行う際のデフォルトの動作が、VPC の VPE ゲートウェイを使用するように変更されました。
  • バージョン 4.14 では :VPE への変更が元に戻され、以前のデフォルトの動作が復元されました。 OpenShift コンソール/OAuthは、現在、プライベートサービスエンドポイント(https://cX00.private.us-south.containers.cloud.ibm.com:port )をデフォルトで使用しています。 クラスターの Oauth アクセス タイプを PSE または VPE のいずれかに設定できるようになりました。 4.13 バージョンと同じ動作を維持したい場合は、VPE ゲートウェイを使用するアクセスタイプを設定することができます。 詳細については、 VPC クラスターの OAuth アクセス タイプを設定する

クラスタの 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.14 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 の場合、条件情報には、アップグレード前に従う必要がある指示が記載されています。 詳しくは、「 管理者の確認応答の提供」を参照してください。

VPC クラスターのネットワーキングの変更

バージョン4.13以前では、VPCクラスタはContainer Registryのプライベート・クラウド・サービス・エンドポイントを通じてIBM Cloud Container Registryからイメージを取得します。 バージョン 4.14 以降では、イメージがプライベート・サービス・エンドポイントではなく VPE ゲートウェイを介してプルされるように、このネットワーク・パスが更新されます。 この変更は、VPC内のすべてのクラスタに影響します。VPC内の単一のクラスタをバージョン4.1414に作成または更新すると、そのVPC内のすべてのクラスタは、そのバージョンに関係なく、ネットワークパスが更新されます。 セキュリティグループ、ネットワーク ACL、およびネットワークポリシーのセットアップによっては、バージョン4.14 にアップデートした後も作業員がコンテナイメージを正常にプルできるようにするための変更が必要になる場合があります。

以下の図は、プライベート・サービス・エンドポイントの代わりにレジストリーに VPE ゲートウェイを使用する、バージョン 4.14の新規ネットワーク・パスを示しています。

VPE ゲートウェイ。
4.14 以降のクラスターのレジストリー用の VPE ゲートウェイ

ネットワーク・パスの更新により、バージョン 4.14 で実行する VPC クラスターを作成または更新すると、新しい VPE ゲートウェイが VPC に追加されます。 この VPE ゲートウェイは、特にIBM Cloud Container Registryからイメージを取得するために使用され、少なくとも 1 つのクラスターワーカーが存在する VPC 内の各ゾーンに対して 1 つの IP アドレスが割り当てられます。 すべての icr.io ドメイン・ネームを新しい VPE ゲートウェイ IP アドレスに解決する DNS エントリーが VPC 全体に追加されます。 ネットワーク・セキュリティー・コンポーネントの構成方法によっては、新しい VPE への接続が許可されていることを確認するためのアクションが必要になる場合があります。

必要な作業

VPC クラスターのワーカー・ノードが引き続き Container Registry からイメージをプルするようにするために必要な手順は、ネットワーク・セキュリティーのセットアップによって異なります。

  • すべてのセキュリティー・グループ、ネットワーク ACL、およびネットワーク・ポリシーにデフォルトのネットワーク・ルールを使用する場合は、アクションを実行する必要はありません。
  • VPC 内の特定の TCP 接続をブロックするカスタマイズされたネットワーク・セキュリティー・セットアップがある場合は、バージョン 4.14の新規クラスターに更新または作成する前に、追加のアクションを実行する必要があります。 以下のセクションで調整を行い、レジストリー用の新しい VPE ゲートウェイへの接続が許可されるようにします。

追加のステップを実行する必要があるかどうかに関係なく、バージョン 4.14 を実行していない VPC 内の他のクラスターを保持している場合は、それらのクラスターで クラスター・マスターをリフレッシュ する必要があります。 このリフレッシュにより、新しい VPE へのトラフィックが許可されるように、 non-4.14 クラスターに正しい更新が確実に適用されます。

カスタム・セキュリティー・グループがあります。 何を変更しますか?

バージョン 4.14でクラスターを更新または作成すると、必要な許可ルールが IBM管理の kube-<cluster_ID> クラスター・セキュリティー・グループに自動的に追加されます。 ただし、 kube-<cluster_ID> クラスター・セキュリティー・グループ・ルールを使用 しない VPC クラスターを作成した場合は、レジストリーの VPE ゲートウェイへのトラフィックを許可するために、以下のセキュリティー・グループ・ルールが実装されていることを確認する必要があります。 カスタム・セットアップでルールがまだ実装されていない場合は、 それらを追加 します。 これらの各ルールは、VPC 内のゾーンごとに作成する必要があり、そのゾーンの VPC アドレス接頭部の範囲全体を宛先 CIDR として指定する必要があります。 VPC 内の各ゾーンの VPC アドレス接頭部の範囲を確認するには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id> を実行します。

カスタムセキュリティグループに以下のルールを追加する。

バージョン 4.14で追加するアウトバウンド・セキュリティー・グループ・ルール
ルール・タイプ プロトコル 宛先の IP または CIDR 宛先ポート
アウトバウンド TCP VPC アドレス接頭部の範囲全体 443

これらのルールをより制限的にするには、VPE ゲートウェイで使用されるセキュリティー・グループに宛先を設定するか、正確な VPE ゲートウェイ予約済み IP アドレスを指定することができます。 VPC 内のすべてのクラスター・ワーカーが削除されると、これらの IP アドレスが変更される可能性があることに注意してください。

カスタム ACL があります。 何を変更しますか?

クラスター・ワーカーに適用される VPC ネットワーク ACL が、特定の Egress トラフィックと Ingress トラフィックのみを許可するようにカスタマイズされている場合は、VPE Gateway for Registry との間の接続を許可するために、以下の ACL ルールまたは同等のルールが実装されていることを確認してください。 ルールがまだ実装されていない場合は、 追加 してください。 これらの各ルールは、VPC 内のゾーンごとに作成する必要があり、ソース (アウトバウンド・ルールの場合) または宛先 (インバウンド・ルールの場合) としてゾーンの VPC アドレス接頭部範囲全体を指定する必要があります。 CIDR。 VPC 内の各ゾーンの VPC アドレス接頭部の範囲を確認するには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id> を実行します。 各ルールの優先度は、このトラフィックを拒否するルール (すべてのトラフィックを拒否するルールなど) よりも高くなければなりません。

カスタムACLに以下のルールを追加する。

バージョン 4.14で追加するアウトバウンドおよびインバウンド ACL ルール
ルール・タイプ プロトコル 送信元の IP または CIDR 送信元ポート 宛先の IP または CIDR 宛先ポート
アウトバウンド/許可 TCP VPC アドレス接頭部の範囲全体 任意 VPC アドレス接頭部の範囲全体 443
インバウンド/許可 TCP VPC アドレス接頭部の範囲全体 443 VPC アドレス接頭部の範囲全体 任意

カスタム・ネットワーク・ポリシーがあります。 何を変更しますか?

Calico ポリシーを使用してクラスター・ワーカーからのアウトバウンド接続を制限する場合は、以下のポリシー・ルールを追加して、VPE Gateway for Registry への接続を許可する必要があります。 このポリシーは、VPC 内のゾーンごとに作成する必要があり、そのゾーンの VPC アドレス接頭部の範囲全体を宛先 CIDR として指定する必要があります。 VPC 内の各ゾーンの VPC アドレス接頭部の範囲を確認するには、 ibmcloud is vpc-address-prefixes <vpc_name_or_id> を実行します。

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-vpe-gateway-registry
spec:
  egress:
  - action: Allow
    destination:
      nets:
      - <entire-vpc-address-prefix-range> # example: 10.245.0.0/16
      ports:
      - 443
    protocol: TCP
    source: {}
  order: 500
  selector: ibm.role == 'worker_private'
  types:
  - Egress