私も不思議に思っていますが、ROKSを操作するたびに、このエラーが定番になっている気がします（笑）。

別の検証課題に対応するため、IBM Cloud上にバージョン4.14のROKS for VPCのClusterを新規作成しました。
しかし、構築直後で一切操作を行っていない状態にもかかわらず、Ingressのステータスが図のとおりCriticalとなっています。

この状態でも OpenShift Web Console やアプリケーションの利用に問題はありませんが、Ingress が Critical のままなのは解消すべきと感じました。
以前、Public Endpoint利用時にも同様の事象を何度か経験しており、対応方法は別の記事にまとめています。
今回はPrivate Endpointのみの構成で、新たな設定変更が必要、本記事で紹介します。

まずは、参考にした IBM Cloud のドキュメントはこちらです：
https://cloud.ibm.com/docs/openshift?topic=openshift-ts-ingress-erriodeg

Key Stepとしては、以下はoc get clusteroperator ingressのCMD出力です：CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)

SSH Terminal

helen@IBM-xxxx:~$ oc get clusteroperator ingress
oc get clusteroperator ingress

NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
ingress   4.14.51   True        False         True       8h      The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)

こちらのCanaryCheckとは、Cluster内の任意のWorker NodeからIngress経由でトラフィックを送信し、応答があるかどうかでClusterの正常性を判断する、ヘルスチェックの仕組みの一つです。

Networkingの画面で、各ClusterのComponentが利用しているSecurity Groupの名前を確認可能です。
‐　黄色部分のがWorker Node用のSecurity Groupです。
‐　赤い部分のがLoad Balancer用のSecurity Groupです。

この二つのSecurity GroupのInbount RuleとOutboundRuleを確認して見ると、Worker Node用のSecurity Group kube-d14h8ajt0svik67qc3t0には、Load Balancerへの通信を許可するRuleが設定されていないことが分かりました。下記のように追加しました。 kube-d14h8ajt0svik67qc3t0のCreate outbound rule画面で、
‐　TCP：TCMP-TCP-UDPを選択します。
‐　Destination Type：Security Groupを選択して、Load Balancer用のSecurity Group kub-r022-ccccbe9ab-df69-4df1-82c3-xxxを選択します。
‐　Source Type：　Any

5分程度を待ちまして、Ingressの状態がHealthyのようになりました。
以上です。