1.8. 既知の問題

OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。

OpenShift Container Platform 4.1 から 4.14 にアップグレードされたクラスターのクラスター管理者の場合は、認証されていないアクセスを取り消すか、許可し続けることができます。認証なしのアクセスが必要な理由が特に無い限り、無効にしてください。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。

以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。

(BZ#1821771)

インストールプログラムが Google Cloud Platform (GCP) サービスアカウントに関連付けられているすべてのプロジェクトを取得できない場合、インストールは失敗し、context deadline exceeded というエラーメッセージが表示されます。

この現象は、次の条件が満たされる場合に発生します。

次の既知の問題は、リリース候補 3 または 4 を使用して OpenShift Container Platform デプロイメントを早期アクセスバージョンの 4.14 に更新したユーザーに適用されます。

ノード識別機能の導入後、root として実行されていた一部の Pod は、特権なしで実行されるように更新されます。OpenShift Container Platform 4.14 の早期アクセスバージョンに更新したユーザーの場合、4.14 の正式バージョンにアップグレードしようとすると進まない可能性があります。このシナリオでは、Network Operator は DaemonSet "/openshift-network-node-identity/network-node-identity" update is rolling を報告し、更新の問題を示します。

回避策として、oc delete --force=true -n openshift-network-node-identity --all pods コマンドを実行して、openshift-network-node-identify namespace 内のすべての Pod を削除できます。このコマンドを実行すると、更新が続行されます。

早期アクセスの詳細は、candidate-4.14 チャネル を参照してください。

OpenShift Container Platform 4.14 では、すべてのノードが、デフォルトの RHEL 9 設定に合わせた内部リソース管理に Linux コントロールグループバージョン 2 (cgroup v2) を使用します。ただし、クラスターにパフォーマンスプロファイルを適用する場合、パフォーマンスプロファイルに関連付けられた低遅延チューニング機能は、cgroup v2 をサポートしません。

その結果、パフォーマンスプロファイルを適用すると、クラスター内のすべてのノードが再起動され、cgroup v1 設定に戻ります。この再起動には、パフォーマンスプロファイルの対象になっていないコントロールプレーンノードとワーカーノードが含まれます。

クラスター内のすべてのノードを cgroups v2 設定に戻すには、Node リソースを編集する必要があります。詳細は、Linux cgroup v2 の設定 を参照してください。最後のパフォーマンスプロファイルを削除しても、クラスターを cgroups v2 設定に戻すことはできません。(OCPBUGS-16976)

現在、Kubernetes の問題により、CPU マネージャーは、ノードに許可された最後の Pod から利用可能な CPU リソースのプールに CPU リソースを戻すことができません。これらのリソースは、後続の Pod がノードに許可された場合は割り当てることができます。ただし、これが最後の Pod となり、CPU マネージャーは再びこの Pod のリソースを使用可能なプールに戻すことができなくなります。

この問題は、CPU 負荷分散機能に影響を与えます。これらの機能は、CPU マネージャーが使用可能なプールに CPU を解放することに依存しているためです。その結果、保証されていない Pod は、少ない CPU 数で実行される可能性があります。回避策として、影響を受けるノード上で best-effort CPU マネージャーポリシーを使用して、Pod をスケジュールします。この Pod は許可された最後の Pod となり、リソースが使用可能なプールに適切に解放されるようにします。(OCPBUGS-17792)

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

これらの問題を解決するには、デュアルスタックネットワーク用の DNS の設定 のガイドラインに従って DNS サーバー設定を指定します。(OCPBUGS-22753、OCPBUGS-23234)

OpenShift Container Platform の Hosted Control Plane では、次の Operator とコンポーネントはテストされていません (OCPSTRAT-605)。

vSphere でのエージェントベースのインストールは、ノードテイントの削除に失敗したために失敗します。これにより、インストールが保留状態のままになります。シングルノードの OpenShift クラスターは影響を受けません。この問題を回避するには、次のコマンドを実行してノードテイントを手動で削除します。

$ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-

(OCPBUGS-20049)

このリリースではテクノロジープレビュー機能である Azure 機密仮想マシンには、使用上の既知の問題があります。コントロールプレーンのプロビジョニングプロセスが 30 分後にタイムアウトになるため、この機能を使用するように設定されたクラスターのインストールは失敗します。

この問題が発生した場合は、openshift-install create cluster コマンドを 2 回目として実行し、インストールを完了できます。

この問題を回避するには、マシンセットを使用して既存のクラスターで Confidential VM を有効にします。(OCPBUGS-18488)

グランドマスタークロック (T-GM) として設定されている Intel Westport Channel e810 NIC の Global Navigation Satellite System (GNSS) モジュールは、GPS FIX 状態と、GNSS モジュールと GNSS コンステレーション衛生間の GNSS オフセットを報告できます。

現在の T-GM 実装では、GNSS オフセットおよび GPS FIX 値を読み取るために、ubxtool CLI を使用して ublox モジュールをプローブすることはしません。代わりに、gpsd サービスを使用して GPS FIX 情報を読み取ります。これは、ubxtool CLI の現在の実装では応答を受信するのに 2 秒かかり、呼び出しごとに CPU 使用率が 3 倍に増加するためです。(OCPBUGS-17422)

コントロールプレーンノードにスケジュールされている Microsoft Azure File NFS ボリュームを含む Pod を作成すると、マウントが拒否されます。

この問題を回避するには、コントロールプレーンノードがスケジュール可能で、Pod がワーカーノードで実行できる場合は、nodeSelector または Affinity を使用してワーカーノードで Pod をスケジュールします。(OCPBUGS-18581)

現在、OpenShift Container Platform 4.14 の HAProxy バージョン 2.6.13 への更新により、再暗号化トラフィックの P99 レイテンシーが増加します。これは、Ingress トラフィックの量により、IngressController カスタムリソース (CR) の HAProxy コンポーネントにかなりの負荷がかかる場合に発生します。全体的なスループットは、レイテンシーの増加の影響を受けず、一貫したままになります。

デフォルトの IngressController CR は、4 つの HAProxy スレッドで設定されています。Ingress トラフィック (特に再暗号化トラフィック) が多い状況で、P99 レイテンシーの上昇が発生した場合は、HAProxy スレッドの数を増やしてレイテンシーを減らすことを推奨します。(OCPBUGS-18936)

機能が無効になっているシングルノード OpenShift では、openshift-controller-manager-operator が継続的に再起動される可能性があります。回避策として、ビルド機能を有効にするか、builds.config.openshift.io CRD を手動で作成します。

builds.config.openshift.io CRD を手動で作成するには、次の手順を実行します。

(OCPBUGS-21778)

OpenShift Container Platform 4.14.2 より前のバージョン 4.14 で Azure AD Workload Identity を使用する Microsoft Azure クラスターには、既知の問題があります。eastus リージョンにおける新しい Azure ストレージアカウントのデフォルトのセキュリティー設定を最近変更したことで、そのリージョンでの Azure AD Workload Identity を使用するクラスターのインストールが阻止されます。現時点では、他のリージョンは影響を受けていないようですが、将来的に影響を受ける可能性があります。

この問題は OpenShift Container Platform 4.14.2 で解決されています。

この問題を回避するには、短期認証情報を使用するように Azure クラスターを設定する の手順で ccoctl azure create-all を実行する前に、パブリックアクセスを許可するストレージアカウントを手動で作成します。

以下の手順を実行します。

(OCPBUGS-22651)

静的 IP アドレス指定と Tang 暗号化を使用して OpenShift Container Platform クラスターをインストールする場合、ノードはネットワーク設定なしで起動します。この状況により、ノードは Tang サーバーにアクセスできなくなり、インストールが失敗します。この状況に対処するには、各ノードのネットワーク設定を ip インストーラー引数として設定する必要があります。