1.4. 主な技術上の変更点


OpenShift Container Platform 4.14 では、次の注目すべき技術的な変更が導入されています。

追加のクラウドプロバイダー向けのクラウドコントローラーマネージャー

Kubernetes コミュニティーは、クラウドコントローラーマネージャーを使用することを優先して、基になるクラウドプラットフォームとやり取りするための Kubernetes コントローラーマネージャーの使用を非推奨にすることを計画しています。その結果、新しいクラウドプラットフォームの Kubernetes コントローラーマネージャーサポートを追加する計画はありません。

このリリースでは、Amazon Web Services と Microsoft Azure のクラウドコントローラーマネージャーの使用が一般提供されるようになりました。

クラウドコントローラーマネージャーの詳細は、Kubernetes Cloud Controller Manager のドキュメント を参照してください。

クラウドコントローラーマネージャーおよびクラウドノードマネージャーのデプロイメントおよびライフサイクルを管理するには、Cluster Cloud Controller Manager Operator を使用します。詳細は、Platform Operators リファレンスCluster Cloud Controller Manager Operator を参照してください。

Pod セキュリティーアドミッションの今後の限定的な適用

現在、Pod のセキュリティー違反は警告として表示され、監査ログに記録されますが、Pod が拒否されることはありません。

現在、OpenShift Container Platform の次のマイナーリリースでは、Pod のセキュリティーアドミッションに対するグローバルな制限付きの適用が計画されています。この制限付きの適用が有効になっている場合、Pod セキュリティー違反のある Pod は拒否されます。

この今後の変更に備えて、ワークロードが適用される Pod セキュリティーアドミッションプロファイルと一致していることを確認してください。グローバルまたはネームスペースレベルで定義された強制セキュリティー基準に従って設定されていないワークロードは拒否されます。restricted-v2 SCC は、制限付き Kubernetes の定義に従ってワークロードを許可します。

Pod のセキュリティー違反が発生している場合は、次のリソースを参照してください。

  • Pod のセキュリティー違反の原因となっているワークロードを見つける方法の詳細は、Pod のセキュリティー違反の特定 を参照してください。
  • Pod セキュリティーアドミッションラベルの同期のタイミングに関する詳細は、Pod セキュリティー標準との Security Context Constraint の同期 を参照してください。Pod セキュリティーアドミッションラベルは、次のような特定の状況では同期されません。

    • ワークロードは、openshift- で始まるシステム作成の namespace で実行されています。
    • ワークロードは、Pod コントローラーなしで直接作成された Pod で実行されています。
  • 必要に応じて、pod-security.kubernetes.io/enforce ラベルを設定して、namespace または Pod にカスタムアドミッションプロファイルを設定できます。

SSH キーの場所の変更

OpenShift Container Platform 4.14 では、RHEL 9.2 ベースの RHCOS が導入されています。この更新前は、SSH キーは RHCOS の /home/core/.ssh/authorized_keys にありました。この更新により、RHEL 9.2 ベースの RHCOS では SSH キーが /home/core/.ssh/authorized_keys.d/ignition に配置されます。

デフォルトの OpenSSH /etc/ssh/sshd_config サーバー設定ファイルをカスタマイズした場合は、こちらの Red Hat ナレッジベースの記事 に従ってファイルを更新する必要があります。

cert-manager Operator の一般提供

Red Hat OpenShift 1.11 の cert-manager Operator は、OpenShift Container Platform 4.14、OpenShift Container Platform 4.13、OpenShift Container Platform 4.12 で一般提供されるようになりました。

Open Virtual Network (OVN) 最適化によるスケーリングと安定性の向上

OpenShift Container Platform 4.14 では、Open Virtual Network Kubernetes (OVN-K) の最適化が導入されており、内部アーキテクチャーが変更されて運用遅延が短縮され、ネットワーキングコントロールプレーンのスケールとパフォーマンスに対する障壁が取り除かれています。ネットワークフローデータは、コントロールプレーンに情報を集中させるのではなく、クラスターノードにローカライズされるようになりました。これにより、操作遅延が短縮され、ワーカーノードとコントロールノード間のクラスター全体のトラフィックが削減されます。その結果、ノードが追加されるたびにネットワーク容量が追加され、大規模なクラスターが最適化されるため、クラスターネットワークのノード数は線形にスケールします。ネットワークフローはすべてのノードでローカライズされるため、コントロールプレーンノードの RAFT リーダー選出は必要なくなり、不安定性の主な原因が除去されました。ローカライズされたネットワークフローデータのさらなる利点は、ネットワーク上のノード損失の影響が障害が発生したノードに限定され、クラスターの残りのネットワークには影響を及ぼさないため、クラスターの障害シナリオに対する回復力が高まることです。詳細は、OVN-Kubernetes アーキテクチャー を参照してください。

Operator SDK 1.31.0

OpenShift Container Platform 4.14 は Operator SDK 1.31.0 をサポートします。この最新バージョンのインストール、または最新バージョンへの更新は、Operator SDK CLI のインストール を参照してください。

注記

Operator SDK 1.31.0 は Kubernetes 1.26 をサポートします。

Operator SDK 1.28.0 で以前に作成または保守された Operator プロジェクトがある場合は、Operator SDK 1.31.0 との互換性を維持するためにプロジェクトを更新します。

oc コマンドは、デフォルトで Podman 設定の場所から認証情報を保存および取得するようになりました。

以前は、レジストリー設定を使用する OpenShift CLI (oc) コマンド (oc adm releaseoc image コマンドなど) は、最初に ~/.docker/config.json などの Docker 設定ファイルの場所から認証情報を取得していました。Docker 設定の場所でレジストリーエントリーが見つからなかった場合、oc コマンドは、${XDG_RUNTIME_DIR}/containers/auth.json などの Podman 設定ファイルの場所から認証情報を取得しました。

このリリースでは、oc コマンドはデフォルトで最初に Podman 設定の場所から認証情報を取得するようになりました。Podman 設定の場所でレジストリーエントリーが見つからない場合、oc コマンドは Docker 設定の場所から認証情報を取得します。

さらに、oc registry login コマンドは、Docker 設定ファイルの場所ではなく、Podman 設定の場所に認証情報を保管するようになりました。

長時間実行される Pod リクエストは、CONNECT リクエストとして記録されるようになりました。

OpenShift Container Platform メトリクスでは、pod attachexeclogportforwardproxy のリクエストが CONNECT リクエストとして記録されるようになりました。

1.4.1. Open Virtual Network Infrastructure Controller のデフォルト範囲

この更新により、コントローラーはトランジットスイッチサブネットのデフォルトの IP アドレス範囲として 100.88.0.0/16 を使用します。実稼働インフラストラクチャーネットワークでは、この IP 範囲を使用しないでください。(OCPBUGS-20261)

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat