1.9. 既知の問題

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

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

    警告

    認証されていないアクセスに依存するアプリケーションがある場合、認証されていないアクセスを取り消すと 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)
  • ユーザーによってプロビジョニングされるインフラストラクチャーで vSphere 上の仮想マシンの電源をオンにすると、ノードのスケールアッププロセスは予想通りに機能しない可能性があります。ハイパーバイザー設定の既知の問題により、ハイパーバイザー内にマシンが作成されますが、電源がオンになりません。マシンセットをスケールアップした後にノードが Provisioning 状態のままである場合、vSphere インスタンス自体で仮想マシンのステータスを調査できます。VMware コマンド govc tasks および govc events を使用して、仮想マシンのステータスを判別します。以下のようなエラーメッセージがあるかどうかを確認します。

    Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192).

    この VMware KBase の記事 にある手順に従って、問題の解決を試行できます。詳細は、Red Hat ナレッジベースのソリューションの「UPI vSphere Node scale-up doesn’t work as expected」を参照してください。(BZ#1918383)

  • ECKD タイプの DASD を VirtIO ブロックデバイスとして使用すると、IBM Z での RHEL KVM インストールへの RHCOS のインストールに失敗します。(BZ#1960485)
  • Open Virtual Network (OVN) のバグにより、Octavia ロードバランサーで永続的な接続の問題が発生します。Octavia ロードバランサーが作成されると、OVN はそれらを一部の Neutron サブネットにプラグインしない可能性があります。これらのロードバランサーは、Neutron サブネットの一部では到達できなくなる可能性があります。この問題は、Kuryr の設定時に各 OpenShift namespace に作成される Neutron サブネットに影響を与えます。その結果、この問題が発生すると、OpenShift Service オブジェクトを実装するロードバランサーが問題の影響を受ける OpenShift namespace から到達できなくなります。このバグにより、Kuryr SDN を使用する OpenShift Container Platform 4.8 デプロイメントの使用は、バグが修正されるまで OVN および OVN Octavia が設定された Red Hat OpenStack Platform (RHOSP) 16.1 では推奨されません。(BZ#1937392)
  • Console Operator は、コンソールのルート (console または downloads) のいずれかの componentRoutes 条件で Ingress リソースを適切に更新しません。(BZ#1954148)
  • OVN-Kubernetes ネットワークプロバイダーは、NodePort タイプサービスおよび LoadBalancer タイプサービスの externalTrafficPolicy 機能をサポートしていません。service.spec.externalTrafficPolicy フィールドは、サービスのトラフィックをノードローカルまたはクラスター全体のエンドポイントにルーティングするかどうかを決定します。現在、このようなトラフィックはデフォルトでクラスター全体のエンドポイントにルーティングされており、トラフィックをノードローカルエンドポイントに制限する方法はありません。この問題は、今後のリリースで解決される予定です。(BZ#1903408)
  • 現在、Kubernetes ポートの衝突の問題により、Pod が再デプロイされた後でも、Pod 間の通信が機能しなくなる可能性があります。詳細および回避策については、Red Hat ナレッジベースソリューションの「Port collisions between pod and cluster IPs on OpenShift 4 with OVN-Kubernetes」を参照してください。(BZ#1939676BZ#1939045)
  • OVN-Kubernetes ネットワークプロバイダーを使用し、コンピューティングノードが RHEL 7.9 を実行するクラスターの場合、OpenShift Container Platform 4.7 から OpenShift Container Platform 4.8 へのアップグレードは BZ#1976232 によってブロックされます。リリース 4.8 にアップグレードするには、このバグの修正が含まれる 4.8 パッチを待つ必要があります。(BZ#1976232)
  • OVN-Kubernetes ネットワークプロバイダーを使用し、OpenShift Container Platform 4.7 から OpenShift Container Platform 4.8 へアップグレードするクラスターの場合、OVN-Kubernetes のバグが原因で、Pod IP アドレスが古くなることがあります。このバグは、めったに発生しない競合状態です。その結果、4.8 リリースへのアップグレード中に、ノードはドレインに失敗し、一部の Operator は Degraded のステータスを報告します。回避策として、CrashLoopBackOff 状態のままでアップグレードを完了しなかった Pod を特定します。oc delete <pod-name> コマンドで各 Pod を削除します。(BZ#1974403)
  • kubeletconfig リソースの tlsSecurityProfile フィールドの説明 (例: oc explain コマンドを使用する場合など) には、TLS セキュリティープロファイルの正しい暗号が記載されていません。回避策として、影響を受けるノードの /etc/kubernetes/kubelet.conf ファイルで暗号の一覧を確認してください。(BZ#1971899)
  • 単一ノードで通常モードで CNF テストを実行する場合、クラスターの準備ができているかどうかを理解するためのロジックに詳細情報がありません。具体的には、SR-IOV ネットワークを作成しても、少なくとも 1 分経過するまで、ネットワーク接続定義は作成されません。すべての DPDK テストはカスケードで失敗します。-ginkgo.skip パラメーターを使用して、単一ノードのインストールに対して実行する場合は、DPDK 機能をスキップして通常モードで CNF テストを実行します。ディスカバリーモードで CNF テストを実行して、単一ノードのインストールに対してテストを実行します。(BZ#1970409)
  • 現在、CNF テストは、SR-IOV および DPDK テスト用の MLX NIC を使用したセキュアブートをサポートしていません。-ginkgo.skip パラメーターを使用して、通常モードでセキュアブートが有効な環境に対して実行する場合、SR-IOV 機能をスキップして CNF テストを実行できます。検出モードで実行することは、MLX カードを使用してセキュアブートが有効な環境に対してテストを実行する際の推奨される方法です。この問題は、今後のリリースで解決される予定です。(BZ#1975708)
  • ArgoCD Operator がサブスクライブされ、ArgoCD と AppProject が開始されると、より制限の厳しい OpenShift Container Platform 環境でイメージが機能しないため、guestbook という名前のサンプルアプリケーションの起動に失敗します。一時的な回避策として、ユーザーは以下の例をデプロイすることで、ArgoCD Operator が正しく機能することを確認できます。

    PROJ=younamespace
    cat > $PROJ-app.yaml <<EOF
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: simple-restricted-webserver
      namespace: $PROJ
    spec:
      destination:
        namespace: $PROJ
        server: https://kubernetes.default.svc
      project: default
      source:
        path: basic-nginx
        repoURL: 'https://github.com/opdev/argocd-example-restricted-apps.git'
        targetRevision: HEAD
    EOF
    oc create -f $PROJ-app.yaml

    詳細は、BZ#1812212 を参照してください。

  • 複数のタブでコンソールを開いている場合、Developer パースペクティブの一部のサイドバーのリンクがプロジェクトに直接リンクされず、選択されたプロジェクトで予期しない変更が生じます。この問題は、今後のリリースで解決される予定です。(BZ#1839101)
  • pathType: Prefix を使用すると、Ingress を使用したパススルールートの作成が失敗します。代わりに、pathTypeImplementationSpecific に設定し、path'' に設定することで、パススルールートを作成できます。

    Ingress YAML ファイルのサンプル

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: ingress7
      namespace: test-ingress
      annotations:
        route.openshift.io/termination: passthrough
    spec:
      rules:
      - host: <ingress-psql-example-test-ingress.apps>
        http:
          paths:
          - path: ''
            pathType: ImplementationSpecific
            backend:
              service:
                name: <ingress-psql-example>
                port:
                  number: 8080

    詳細は、BZ#1878685 を参照してください。

  • 現時点では、Search ページの Pipelines リソーステーブルは、Name フィルターを適用または削除した直後に更新されません。ただし、ページを更新して Pipelines セクションを展開すると、Name フィルターが適用されます。Name フィルターを削除すると同じ動作が確認されます。この問題は、今後のリリースで解決される予定です。(BZ#1901207)
  • ドキュメントには、Provisioning カスタムリソースの ProvisioningNetworkCIDR 値が記載されています。これにより、IPv6 プロビジョニングネットワークが dnsmasq によって /64 に制限されます。(BZ#1947293)
  • トラブルシューティングをサポートするために、インストーラーによってブートストラップの失敗で収集されたログに、コントロールプレーンとブートストラップホストの IP アドレスとルートが含まれるようになりました。(BZ#1956079)
  • 自己署名の Amazon Commercial Cloud Services クラスターを使用する場合には、内部イメージレジストリーからプルまたはこれにプッシュすることはできません。回避策として、configs.imageregistry/cluster リソースで spec.disableRedirecttrue に設定する必要があります。これにより、S3 ストレージから直接ではなく、イメージレジストリーからイメージレイヤーをプルできます。(BZ#1924568)
  • 以前のバージョンでは、OpenShift Container Platform Web コンソールで Bitbucket リポジトリーを使用してデプロイメント用に作成されたトポロジー URL は、スラッシュ文字を含むブランチ名が含まれている場合は機能しませんでした。これは Bitbucket API (BCLOUD-9969) の問題が原因でした。現在のリリースではこの問題は軽減されています。ブランチ名にスラッシュが含まれている場合、トポロジー URL はリポジトリーのデフォルトのブランチページを指します。この問題は OpenShift Container Platform の今後のリリースで修正されます。(BZ#1969535)
  • OpenShift Container Platform (OCP) バージョン 4.6 を Red Hat Virtualization (RHV) にインストールするには、RHV バージョン 4.4 が必要です。RHV 4.3 で以前のバージョンの OCP を実行している場合は、これを OCP バージョン 4.6 に更新しないでください。Red Hat は、RHV バージョン 4.3 での OCP バージョン 4.6 の実行をテストしていないため、この組み合わせをサポートしません。テスト済み統合の詳細は、「OpenShift Container Platform 4.x Tested Integrations (for x86_x64)」を参照してください。
  • operator-sdk pkgman-to-bundle コマンドは、--build-cmd フラグを指定して実行するとエラーを出して終了します。詳細は、(BZ#1967369) を参照してください。
  • 現時点で、Web コンソールのクイックスタートカードの前提条件は、一覧ではなく段落で表示されます。この問題は、今後のリリースで解決される予定です。(BZ#1905147)
  • OpenShift Container Platformのシングルノード構成では、リアルタイムカーネル(kernel-rt)を使用した場合、非リアルタイムカーネルを使用した場合に比べてPodの作成時間が2倍以上遅くなります。kernel-rtを使用した場合、ノードの再起動後のリカバリータイムが影響を受けるため、作成時間が遅いことで、サポートされるPodの最大数に影響が出ます。kernel-rtを使用している場合の回避策として、rcupdate.rcu_normal_after_boot=0のカーネル引数を指定して起動することで、影響を受けた回復時間を改善することができます。この場合、リアルタイムカーネルのバージョンは、kernel-rt-4.18.0-305.16.1.rt7.88.el8_4以降でなければなりません。この既知の問題は、OpenShift Container Platformのバージョン4.8.15以降に該当します。(BZ#1975356)
  • OpenShift Container Platformのシングルノードのリブートに続いて、すべての Pod が再起動します。これにより、大きな負荷が発生し、通常の Pod 作成時間が長くなります。これは、Container Network Interface (CNI)が pod add イベントを素早く処理できないために発生します。timed out waiting for OVS port binding エラーメッセージが表示されます。OpenShift Container Platform の単一ノードインスタンスは最終的は復帰しますが、想定よりも遅くなります。この既知の問題は、OpenShift Container Platformのバージョン4.8.15以降に該当します。(BZ#1986216)
  • OpenShift Container Platform 4.8 以前のデフォルトのロードバランシングアルゴリズムはleastconn でした。パススルーでないルートの場合、OpenShift Container Platform 4.8.0ではデフォルトがrandomに変更されました。randomに切り替えると、長時間のウェブソケット接続を使用する必要がある環境では、メモリ消費量が大幅に増加するため、互換性がありません。この大幅なメモリ消費を軽減するために、OpenShift Container Platform 4.8では、デフォルトのロードバランシングアルゴリズムがleastconnに戻されました。大幅なメモリ使用量を発生させないソリューションが開発されれば、OpenShift Container Platformの将来のリリースでデフォルトがrandomに変更される予定です。

    以下のコマンドを入力することで、デフォルトの設定を確認することができます。

    $ oc get deployment -n openshift-ingress router-default -o yaml | grep -A 2 ROUTER_LOAD_BALANCE_ALGORITHM
            - name: ROUTER_LOAD_BALANCE_ALGORITHM
              value: leastconn

    randomのオプションはまだ利用可能です。しかし、このアルゴリズムの選択の恩恵を受けたいルートは、以下のコマンドを入力して、ルートごとにアノテーションでそのオプションを明示的に設定する必要があります。

    $ oc annotate -n <NAMESPACE> route/<ROUTE-NAME> "haproxy.router.openshift.io/balance=random"

    (BZ#2017708)

  • RHCOS および Machine Config Operator(MCO)のイメージが OpenShift Container Platform 4.8.z リリースからそれ以降の 4.8.z リリースに変更されない場合、コントロールプレーンノードのアップグレードの終了前にアップグレードが完了とマークされます。これに従うと、アップグレードが実際に完了する前にクラスター上で操作を実行すると、アップグレードが失敗する可能性があります。回避策として、クラスターで追加の操作を実行する前に、更新がコントロールプレーンノードで完了されていることを確認します。oc get mcp/master コマンドを使用して、各プールのクラスターで利用可能な MCO が管理するノードのステータスを確認します。(BZ#2025396)