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 のセキュリティー違反が発生している場合は、次のリソースを参照してください。

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.28.0 で以前に作成または保守された Operator プロジェクトがある場合は、Operator SDK 1.31.0 との互換性を維持するためにプロジェクトを更新します。

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

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

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

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