1.8. 既知の問題
OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。
OpenShift Container Platform 4.1 から 4.11 にアップグレードされたクラスターのクラスター管理者の場合、認証されていないアクセスを無効にするか、これを引き続き許可することができます。認証なしのアクセスが必要な理由が特に無い限り、無効にしてください。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。
警告認証されていないアクセスに依存するアプリケーションがある場合、認証されていないアクセスを取り消すと HTTP
403
エラーが生じる可能性があります。以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。
## 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
このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。
-
cluster-status-binding
-
discovery
-
system:basic-user
-
system:discovery
-
system:openshift:discovery
-
-
oc annotate
コマンドは、等号 (=
) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patch
またはoc edit
を使用してアノテーションを追加します。(BZ#1917280) - モニタリングスタックで、ユーザー定義アラート専用の Alertmanager インスタンスを有効にしてデプロイした場合、OpenShift Container Platform Web コンソールの Developer パースペクティブでアラートを消音することはできません。この問題は、4.11.8 で修正されました。(BZ#2100860)
-
新しくインストールされた OpenShift Container Platform 4.11 クラスターでは、プラットフォームモニタリングアラートに
openshift_io_alert_source="platform"
ラベルがありません。この問題は、以前のマイナーバージョンからアップグレードされたクラスターには影響しません。現在、この問題に対する回避策はありません。(BZ#2103127) - Red Hat OpenStack Platform (RHOSP) では、ポートプールが同時に実行されるさまざまな一括ポート作成要求で設定されると、潜在的な問題が発生する場合があります。これらの一括要求時に、いずれかの IP アドレスの IP の割り当てに失敗すると、Neutron は全ポートの操作を再試行します。この問題は以前のエラータで解決されました。ただし、ポートプールバッチに小さい値を設定して、大量のポート作成要求を回避することができます。(BZ#2024690)
- oc-mirror CLI プラグインは、バージョン 4.9 よりも前の OpenShift Container Platform カタログをミラーリングできません。(BZ#2097210)
-
イメージセット設定の
archiveSize
値がコンテナーイメージサイズよりも小さい場合に、oc-mirror CLI プラグインはターゲットミラーレジストリーに設定されたイメージをアップロードできず、カタログディレクトリーが複数のアーカイブにまたがる可能性があります。(BZ#2106461) OpenShift Container Platform 4.11 では、MetalLB Operator スコープが namespace からクラスターに変更され、これにより、以前のバージョンからアップグレードに失敗します。
回避策として、以前のバージョンの MetalLB Operator を削除します。MetalLB カスタムリソースの namespace またはインスタンスを削除し、新規 Operator バージョンをデプロイしないでください。これにより、MetalLB が動作して設定されます。
詳細は、Upgrading the MetalLB Operator を参照してください。(BZ#2100180)
-
双方向転送検出 (BFD) プロファイルを削除し、ボーダーゲートウェイプロトコル (BGP) ピアリソースに追加された
bfdProfile
を削除しても、BFD は無効になりません。代わりに、BGP ピアはデフォルトの BFD プロファイルの使用を開始します。BGP ピアリソースから BFD をディセーブルにするには、BGP ピア設定を削除し、BFD プロファイルなしで再作成します。(BZ#2050824) -
Go 1.18 ライブラリーで信頼できない証明書を処理するための変更により、OpenShift Container Platform 4.11 の OpenShift CLI (
oc
) は macOS で適切に機能しません。この変更により、oc login
およびその他のoc
コマンドは、MacOS で実行しても、certificate is not trusted
エラーで失敗することがあります。Go 1.18 でエラー処理が適切に修正されるまで (Go の問題 #52010 で追跡)、回避策は代わりに OpenShift Container Platform 4.10oc
CLI を使用することです。OpenShift Container Platform 4.10oc
CLI を OpenShift Container Platform 4.11 クラスターで使用する場合、oc serviceaccounts get-token <service_account>
コマンドを使用してトークンを取得することはできなくなりました。(BZ#2097830) (BZ#2109799) -
プロジェクトの開発者カタログを拡張する Add Helm Chart Repositories フォームには、現在既知の問題があります。クイックスタート ガイドでは、目的の namespace に
ProjectHelmChartRepository
CR を追加できると説明されていますが、これを実行するには kubeadmin からのパーミッションが必要である点については言及されていません。(BZ#2054197) -
現在、既知の問題があります。TLS 検証を使用する
ProjectHelmChartRepository
カスタムリソース (CR) のインスタンスを作成する場合、リポジトリーをリスト表示して Helm 関連の操作を実行することはできません。現在、この問題に対する回避策はありません。(HELM-343) ベアメタル IBM Power で OpenShift Container Platform を実行している場合、Petitboot ブートローダーが、一部の RHCOS ライブイメージのブート設定を入力できないという既知の問題があります。このような場合、RHCOS をインストールするために PXE でノードを起動した後、想定されたライブイメージディスクの設定が表示されないことがあります。
回避策として、Petitboot シェルから
kexec
を使用して手動で起動できます。ライブイメージを保存しているディスク (この例では
nvme0n1p3
) を特定し、以下のコマンドを実行します。# cd /var/petitboot/mnt/dev/nvme0n1p3/ostree/rhcos-*/ # kexec -l vmlinuz-*.ppc64le -i initramfs-*.img -c "ignition.firstboot rd.neednet=1 ip=dhcp $(grep options /var/petitboot/mnt/dev/nvme0n1p3/loader/entries/ostree-1-rhcos.conf | sed 's,^options ,,')" && kexec -e
- 切断された環境では、SRO はメインレジストリーから DTK を取得しようとしません。代わりにミラーレジストリーから取得します。(BZ#2102724)
-
プロセスカウンターは、
phc2sys
が実行されていないインターフェイス上のphc2sys
プロセスに関する誤った情報を表示します。現在、この問題に対する回避策はありません。(OCPBUGSM-46005) - デュアル NIC PTP 設定を持つノードのネットワークインターフェイスコントローラー (NIC) がシャットダウンされると、両方の PTP インターフェイスに対して障害イベントが生成されます。現在、この問題に対する回避策はありません。(OCPBUGSM-46004)
- ローバンドシステムでは、グランドマスタークロックが数時間切断されてから復旧した後、システムクロックは PTP の通常クロックと同期しません。現在、この問題に対する回避策はありません。(OCPBUGSM-45173)
-
以前は、OVN-Kubernetes クラスターネットワークプロバイダーを使用していて、
type=LoadBalancer
のサービスがinternalTrafficPolicy=cluster
セットで設定されている場合、ホストルーティングテーブルに使用に適したルートが含まれていても、すべてのトラフィックがデフォルトのゲートウェイにルーティングされていました。現在は、常にデフォルトのゲートウェイを使用するのではなく、最適なルートが使用されるようになりました。(BZ#2060159) -
OVN クラスターに 75 を超えるワーカーノードがある場合、2000 以上のサービスとルートオブジェクトを同時に作成すると、同時に作成された Pod が
ContainerCreating
ステータスでハングする可能性があります。この問題が発生した場合、oc describe pod <podname> コマンドを入力すると、`FailedCreatePodSandBox…failed to configure pod interface: timed out waiting for OVS port binding (ovn-installed)' の警告とともにイベントが表示されます。現在、この問題に対する回避策はありません。(BZ#2084062) -
現在、OVN-Kubernetes には、
NetworkManager
サービスが再起動するたびに、ノードがネットワーク接続を失い、回復する必要があるという既知の問題があります。(BZ#2074009) -
デフォルトの SCC (Security Context Constraints) により、汎用一時ボリュームを使用する Pod が
Pending
状態のままになる可能性があります。カスタム SCC を作成して、この問題を回避することができます。詳細は、Pods with Generic Ephemeral Volumes fail with SCC errors を参照してください。回避策については、Allowing the use of generic ephemeral volumes を参照してください。(BZ#2100429) OpenShift サンドボックスコンテナーがある場合、クラスターのアップグレード時に Machine Config Operator (MCO) Pod が
CrashLoopBackOff
状態に遷移し、Pod のopenshift.io/scc
アノテーションにデフォルト値のhostmount-anyuid
ではなくsandboxed-containers-operator-scc
が表示される問題が発生する可能性があります。この場合は、
sandboxed-containers-operator-scc
SCC のseLinuxOptions
ストラテジーを一時的に制限の少ないRunAsAny
に変更し、承認プロセスがhostmount-anyuid
SCC よりも優先しないようにします。以下のコマンドを実行して
seLinuxOptions
ストラテジーを変更します。$ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "RunAsAny"}}'
以下のコマンドを実行して MCO Pod を再起動します。
$ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=0
$ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=1
以下のコマンドを実行して、
sandboxed-containers-operator-scc
のseLinuxOptions
ストラテジーをMustRunAs
の元の値に戻します。$ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "MustRunAs"}}'
以下のコマンドを実行して、
hostmount-anyuid
SCC が MCO Pod に適用されていることを確認します。$ oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o yaml | grep scc openshift.io/scc: hostmount-anyuid
-
パイプラインメトリック API は、RHOSP 1.6 以降の必要な
pipelinerun/taskrun
ヒストグラムの値をサポートしません。その結果、PipelineDetails ページの Metrics タブは、誤った値を表示する代わりに削除されます。現在、この問題に対する回避策はありません (リンク: BZ#2074767)。 - 一部の Alibabacloud サービスは、クラスターのすべてのリソースを指定されたリソースグループに配置していません。したがって、OpenShift Container Platform インストールプログラムによって作成された一部のリソースは、デフォルトのリソースグループに配置されます。現在、この問題に対する回避策はありません。(BZ#2096692)
-
各クラスターノードを再起動した後、クラスター Operators
network
とkube-apiserver
は、クラスターの各ノードを再起動した後にdegraded
状態になり、クラスターが異常になります。現在、この問題に対する回避策はありません。(BZ#2102011) -
install-config.yaml
にresourceGroupID
が指定されている場合、ブートストラップリソースの削除時にエラーが表示され、OpenShift Container Platform のインストールが失敗します。この問題を回避するには、install-config.yaml
でresourceGroupID
を指定しないでください。(BZ#2100746) -
RHEL コンピュートノードでのスケールアップには、既知の問題があります。新しいノードは
Ready
になる可能性がありますが、Ingress Pod はこれらのノードでRunning
に変わることができず、スケールアップは成功しません。回避策として、RHCOS ノードでのスケールアップは機能します。(BZ#2056387) -
Google Cloud Platform (GCP) で
machine
セットを作成した後、capg-controller-manager
マシンがProvisioning
で停止します。現在、この問題に対する回避策はありません。(BZ#2107999) -
Nutanix には、クラスターによって作成された永続ボリューム (PV) が
destroy cluster
コマンドによってクリーンアップされないという既知の問題があります。この問題の回避策として、PV を手動でクリーンアップする必要があります。(BZ#2108700) - Prism Central 2022.x で 4096 ビットの証明書を使用すると、Nutanix のインストールに失敗するという既知の問題があります。代わりに、2048 ビットの証明書を使用します。(KCS)
-
現在、不正な構文または値を使用して
egressqos
を作成および編集すると、成功するという既知の問題があります。egressqos
の誤った値は正常に作成されません。現在、この問題に対する回避策はありません。(BZ#2097579) -
一部のイメージインデックスに古いイメージが含まれているため、
oc adm catalog mirror
およびoc image mirror
を実行すると、error: unable to retrieve source image
エラーが発生する場合があります。一時的な回避策として、--skip-missing
オプションを使用してエラーを回避し、イメージインデックスのダウンロードを続行できます。詳細は、Service Mesh Operator mirroring failed を参照してください。 - 仮想機能 (VF) がすでに存在する場合、Physical Fundtion (PF) で macvlan を作成することはできません。この問題は、Intel E810 NIC に影響します。(BZ#2120585)
-
ZTP 経由でデプロイされたクラスターに準拠していないポリシーがあり、
ClusterGroupUpdates
オブジェクトが存在しない場合は、TALM Pod を再起動する必要があります。TALM を再起動すると、適切なClusterGroupUpdates
オブジェクトが作成され、ポリシーへの準拠が強制されます。(OCPBUGS-4065) -
現在、VMware vSphere に OpenShift Container Platform クラスターをインストールする目的でインストールプログラムを macOS で実行する場合、
x509: certificate is not standards compliant
として出力される証明書コンプライアンスの問題が存在します。この問題は、コンパイラーが新しくサポートされた macOS 証明書規格を認識しないというgolang
コンパイラーの既知の問題に関連しています。この問題に対する回避策はありません。(OSDOCS-5694) - 現在、非常に多くのファイルを含む永続ボリューム (PV) を使用すると、Pod が起動しないか、起動に過度に時間がかかる場合があります。詳細は、ナレッジベースアーティクル を参照してください。(BZ1987112)