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

    (BZ#1821771)

  • 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.10 oc CLI を使用することです。OpenShift Container Platform 4.10 oc 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

    (BZ#2107674)

  • 切断された環境では、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 よりも優先しないようにします。

    1. 以下のコマンドを実行して seLinuxOptions ストラテジーを変更します。

      $ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "RunAsAny"}}'
    2. 以下のコマンドを実行して 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
    3. 以下のコマンドを実行して、sandboxed-containers-operator-sccseLinuxOptions ストラテジーを MustRunAs の元の値に戻します。

      $ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "MustRunAs"}}'
    4. 以下のコマンドを実行して、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

    (KATA-1373)

  • パイプラインメトリック API は、RHOSP 1.6 以降の必要な pipelinerun/taskrun ヒストグラムの値をサポートしません。その結果、Pipeline Details ページの Metrics タブは、誤った値を表示する代わりに削除されます。現在、この問題に対する回避策はありません (リンク: BZ#2074767)。
  • 一部の Alibabacloud サービスは、クラスターのすべてのリソースを指定されたリソースグループに配置していません。したがって、OpenShift Container Platform インストールプログラムによって作成された一部のリソースは、デフォルトのリソースグループに配置されます。現在、この問題に対する回避策はありません。(BZ#2096692)
  • 各クラスターノードを再起動した後、クラスター Operators networkkube-apiserver は、クラスターの各ノードを再起動した後に degraded 状態になり、クラスターが異常になります。現在、この問題に対する回避策はありません。(BZ#2102011)
  • install-config.yamlresourceGroupID が指定されている場合、ブートストラップリソースの削除時にエラーが表示され、OpenShift Container Platform のインストールが失敗します。この問題を回避するには、install-config.yamlresourceGroupID を指定しないでください。(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)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.