1.8. 既知の問題

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

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

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

## 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)

断続的に、一部のワーカーマシンが起動しないために、IBM Cloud VPC クラスターのインストールが失敗することがあります。むしろ、これらのワーカーマシンは Provisioned フェーズのままです。

この問題には回避策があります。最初のインストールを実行したホストから、失敗したマシンを削除し、インストールプログラムを再度実行します。

カタログソースの更新後、OLM がサブスクリプションステータスを更新するのに時間がかかります。これは、Topology Aware Lifecycle Manager (TALM) が修正が必要かどうかを判断したときに、サブスクリプションポリシーのステータスが準拠として表示され続ける可能性があることを意味します。その結果、サブスクリプションポリシーで指定された Operator はアップグレードされません。回避策として、次のように、カタログソースポリシーの spec セクションに status フィールドを含めます。

metadata:
  name: redhat-operators-disconnected
spec:
  displayName: disconnected-redhat-operators
  image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.11
status:
  connectionState:
    lastObservedState: READY

これにより、OLM が新しいインデックスイメージを取得して Pod を準備するまでの遅延が軽減され、カタログソースポリシーの修正が完了してからサブスクリプションステータスが更新されるまでの時間が短縮されます。問題が解決せず、サブスクリプションポリシーステータスの更新がまだ遅れている場合は、同じサブスクリプションポリシーで別の ClusterGroupUpdate CR を適用するか、別の名前で同じ ClusterGroupUpdate CR を適用できます。(OCPBUGS-2813)

ClusterGroupUpdate CR の開始時に、選択したすべてのクラスターが準拠している場合、TALM はポリシーの修正をスキップします。同じ ClusterGroupUpdate CR 内のカタログソースポリシーとサブスクリプションポリシーが変更された Operator の更新は完了しません。サブスクリプションポリシーは、カタログソースの変更が適用されるまで準拠の状態が続くためスキップされます。回避策として、次の例のように、common-subscription ポリシーの 1 つの CR に次の変更を追加します。

metadata.annotations.upgrade: "1"

これにより、ClusterGroupUpdate CR の開始前にポリシーが非準拠になります。(OCPBUGS-2812)

ACM がデプロイされたマルチクラスター環境で metal3 サービスがハブクラスターでのみ実行されている場合、BMCEventSubscription CR はスポーククラスターの Redfish サブスクリプションを作成できません。回避策としては、たとえば次のコマンドを実行し、Redfish API を直接呼び出してサブスクリプションを作成します。

curl -X POST -i --insecure -u "<BMC_username>:<BMC_password>" https://<BMC_IP>/redfish/v1/EventService/Subscriptions \
    -H 'Content-Type: application/json' \
    --data-raw '{
    "Protocol": "Redfish",
    "Context": "any string is valid",
    "Destination": "https://hw-event-proxy-openshift-bare-metal-events.apps.example.com/webhook",
    "EventTypes": ["Alert"]
    }'

201 Created レスポンスと、Redfish イベントサブスクリプションが正常に作成されたことを示す Location: /redfish/v1/EventService/Subscriptions/<sub_id> を含むヘッダーを受け取るはずです。(OCPBUGSM-43707)

GitOps ZTP メソッドを使用してクラスターを管理し、インストールが完了していないクラスターを削除すると、ハブクラスター上のクラスター namespace のクリーンアップが無期限にハングアップすることがあります。namespace の削除を完了するには、クラスター namespace の 2 つの CR から、baremetalhost.metal3.io ファイナライザーを削除します。

Platform Operator および RukPak の既知の問題:

外部クラウドプロバイダーを使用するクラスターは、ローテーション後に更新された認証情報の取得に失敗する可能性があります。その場合、次のプラットフォームが影響を受けます。

回避策として、次のコマンドを実行して openshift-cloud-controller-manager Pod を再起動します。

$ oc delete pods --all -n openshift-cloud-controller-manager

(OCPBUGS-5036)

OVN-Kubernetes ネットワークプロバイダーを使用するクラスターでコントロールプレーンマシンを交換すると、交換したマシンで OVN-Kubernetes に関連する Pod が起動しない場合があります。この状態が発生すると、新しいマシンにネットワーク接続がないため、etcd が古いマシンを置き換えることができなくなります。その結果、クラスターはその状態で停止し、パフォーマンスが低下する可能性があります。この動作は、手動またはコントロールプレーンマシンセットによってコントロールプレーンが置き換えられた場合に発生する可能性があります。

現在、この問題が発生した場合の解決策はありません。この問題を回避するため、クラスターが OVN-Kubernetes ネットワークプロバイダーを使用している場合は コントロールプレーンマシンセットを無効化 し、コントロールプレーンマシンを手動で置き換えないいようにしてください。(OCPBUGS-5306)

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

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

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