第1章 Hosted Control Plane のリリースノート

以前は、ホストされたクラスターのコントロールプレーンで実行される Operator のプロキシーが、データプレーンで実行される konnectivity エージェント Pod のプロキシー設定によって実行されていました。アプリケーションプロトコルに基づいてプロキシーが必要かどうかを区別することはできませんでした。

OpenShift Container Platform との互換性を保つために、HTTPS または HTTP 経由の IDP 通信はプロキシーする必要がありますが、LDAP 通信はプロキシーする必要ありません。このタイプのプロキシーでは、トラフィックが Konnectivity エージェントに到達するまでに宛先 IP アドレスのみ使用可能になるため、ホスト名に依存する NO_PROXY エントリーも無視されます。

このリリースでは、ホステッドクラスターでのプロキシーはコントロールプレーンで konnectivity-https-proxy および konnectivity-socks5-proxy を介して呼び出され、Konnectivity エージェントからのプロキシートラフィックが停止されます。その結果、LDAP サーバー宛のトラフィックはプロキシーされなくなります。その他の HTTPS または HTTPS トラフィックは正しくプロキシーされます。ホスト名を指定すると、NO_PROXY 設定が適用されます。(OCPBUGS-37052)

以前は、IDP 通信のプロキシーが Konnectivity エージェントで行われていました。トラフィックが Konnectivity に到達するまでに、そのプロトコルとホスト名が利用できなくなっていました。その結果、OAUTH サーバー Pod のプロキシーが正しく実行されていませんでした。プロキシーを必要とするプロトコル (http/s) とプロキシーを必要としないプロトコル (ldap://) が区別されていませんでした。さらに、HostedCluster.spec.configuration.proxy 仕様で設定されている no_proxy 変数が考慮されませんでした。

このリリースでは、OAUTH サーバーの Konnectivity サイドカーでプロキシーを設定することにより、no_proxy 設定を考慮しながら、トラフィックを適切にルーティングできるようになりました。その結果、ホストされたクラスターにプロキシーが設定されている場合、OAUTH サーバーがアイデンティティープロバイダーと適切に通信できるようになりました。(OCPBUGS-36932)

ノードプールが 0 ワーカーにスケールダウンされても、コンソールのホストのリストには、Ready 状態のノードが表示されます。ノードの数は、次の 2 つの方法で確認できます。

デュアルスタックネットワークを使用する環境でホステッドクラスターを作成すると、次の DNS 関連の問題が発生する可能性があります。

ホステッドクラスターをそのマネージドクラスターと同じ namespace に作成した場合、マネージドホステッドクラスターをデタッチすると、ホステッドクラスターが含まれるマネージドクラスター namespace 内のすべてが削除されます。次の状況では、マネージドクラスターと同じ namespace にホステッドクラスターが作成される可能性があります。