1.4. 主な技術上の変更点
OpenShift Container Platform 4.13 では、主に以下のような技術的な変更点が加えられています。
追加のクラウドプロバイダー向けのクラウドコントローラーマネージャー
Kubernetes コミュニティーは、クラウドコントローラーマネージャーを使用することを優先して、基になるクラウドプラットフォームとやり取りするための Kubernetes コントローラーマネージャーの使用を非推奨にすることを計画しています。その結果、新しいクラウドプラットフォームの Kubernetes コントローラーマネージャーサポートを追加する計画はありません。
OpenShift Container Platform のこのリリースで追加された Nutanix 実装は、クラウドコントローラーマネージャーを使用します。さらに、このリリースでは、VMware vSphere のクラウドコントローラーマネージャーを使用する一般提供が導入されました。
クラウドコントローラーマネージャーの詳細は、Kubernetes Cloud Controller Manager のドキュメント を参照してください。
クラウドコントローラーマネージャーおよびクラウドノードマネージャーのデプロイメントおよびライフサイクルを管理するには、Cluster Cloud Controller Manager Operator を使用します。
詳細は、Platform Operators リファレンス のCluster Cloud Controller Manager Operator を参照してください。
MCD による一時停止されたプール上の kubelet CA 証明書の同期
これまで、Machine Config Operator (MCO) は、マシン設定の通常更新の一環として、kubelet クライアント認証局 (CA) 証明書 (/etc/kubernetes/kubelet-ca.crt
) を更新していました。OpenShift Container Platform 4.13 以降、kubelet-ca.crt
はマシン設定の通常更新の一環として更新されなくなりました。この変更により、証明書が変更されるたびに、Machine Config Daemon (MCD) が自動的に kubelet-ca.crt
を最新の状態に保ちます。
マシン設定プールが一時停止されている場合、MCD は新しくローテーションされた証明書を該当するノードにプッシュできるようになりました。以前のバージョンと同様に、証明書への変更を含むレンダリングされた新しいマシン設定がプールに対して生成されます。プールは、更新が必要であることを示します。この条件は、この製品の将来のリリースで削除される予定です。ただし、証明書は個別に更新されるため、これ以上更新がない場合はプールを一時停止したままにしても安全です。
ノードには常に最新の kubelet-ca.crt
が必要であるため、MachineConfigControllerPausedPoolKubeletCA
アラートが削除されました。
SSH キーの場所の変更
OpenShift Container Platform 4.13 では、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 ナレッジベースの記事 に従ってファイルを更新する必要があります。
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 にカスタムアドミッションプロファイルを設定できます。
oc-mirror プラグインが OpenShift API エンドポイントからグラフデータコンテナーイメージを取得
oc-mirror OpenShift CLI (oc
) プラグインは、GitHub からグラフデータリポジトリー全体をダウンロードするのではなく、OpenShift API エンドポイントからグラフデータ tarball をダウンロードするようになりました。このデータを外部ベンダーではなく Red Hat から取得することは、外部コンテンツに対して厳しいセキュリティーとコンプライアンスの制限があるユーザーに適しています。
oc-mirror プラグインがダウンロードするデータから、グラフデータリポジトリー内にあるが OpenShift Update Service には必要ないコンテンツが除外されるようになりました。コンテナーも UBI ではなく UBI Micro をベースイメージとして使用するため、コンテナーイメージは以前よりも大幅に小さくなります。
これらの変更は、oc-mirror プラグインのユーザーワークフローには影響しません。
グラフデータコンテナーイメージの Dockerfile を OpenShift API エンドポイントから取得
Dockerfile を使用して OpenShift Update Service のグラフデータコンテナーイメージを作成する場合は、グラフデータの tarball が GitHub ではなく OpenShift API エンドポイントからダウンロードされることに注意してください。
詳細は、OpenShift Update Service グラフデータコンテナーイメージの作成 を参照してください。
vSphere の user-provisioned infrastructure で nodeip-configuration サービスが有効
OpenShift Container Platform 4.13 では、nodeip-configuration
サービスが vSphere の user-provisioned infrastructure で有効になりました。このサービスは、ノードの起動時に OpenShift Container Platform が Kubernetes API サーバーとの通信に使用するネットワークインターフェイスコントローラー (NIC) を決定します。まれに、アップグレード後にサービスが間違ったノード IP を選択することがあります。このような場合は、NODEIP_HINT
機能を使用して元のノード IP を復元できます。ネットワーク問題のトラブルシューティング を参照してください。
Operator SDK 1.28
OpenShift Container Platform 4.13 は Operator SDK 1.28 をサポートします。この最新バージョンのインストール、または最新バージョンへの更新は、Operator SDK CLI のインストール を参照してください。
Operator SDK 1.28 は Kubernetes 1.26 をサポートします。
以前に Operator SDK 1.25 で作成または管理されている Operator プロジェクトがある場合は、Operator SDK 1.28 との互換性を維持するためにプロジェクトを更新してください。
RHEL 9.2 ベースの RHCOS におけるディスク順序付け動作の変更
OpenShift Container Platform 4.13 では、RHEL 9.2 ベースの RHCOS が導入されています。今回の更新により、シンボリックディスク名が再起動後に変更される可能性があります。その結果、インストール後に設定ファイルを適用する場合、またはサービス作成時に /dev/sda
などのシンボリック名を使用するディスクを参照するノードをプロビジョニングする場合に、問題が発生する可能性があります。この問題の影響は、設定しているコンポーネントにより異なります。ディスク参照を含め、デバイスには dev/disk/by-id
など特定の命名スキームを使用することが推奨されます。
この変更により、モニタリングで各ノードのインストールデバイスに関する情報が収集される場合、既存の自動化ワークフローの調整が必要になる可能性があります。
詳細は、RHEL ドキュメント を参照してください。
ホストされたコントロールプレーンのバックアップ、復元、障害復旧に関するドキュメントの移動
OpenShift Container Platform 4.13 のドキュメントでは、ホストされたクラスター上で etcd をバックアップおよび復元する手順と、AWS リージョン内のホストされたクラスターを復元する手順が、「バックアップと復元」セクションから「ホストされたコントロールプレーン'セクションに移動されました。内容に変更はありません。