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 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 設定の場所に認証情報を保管するようになりました。
長時間実行される Pod リクエストは、CONNECT リクエストとして記録されるようになりました。
OpenShift Container Platform メトリクスでは、pod attach
、exec
、log
、portforward
、proxy
のリクエストが CONNECT
リクエストとして記録されるようになりました。
1.4.1. Open Virtual Network Infrastructure Controller のデフォルト範囲
この更新により、コントローラーはトランジットスイッチサブネットのデフォルトの IP アドレス範囲として 100.88.0.0/16
を使用します。実稼働インフラストラクチャーネットワークでは、この IP 範囲を使用しないでください。(OCPBUGS-20261)