1.8. 既知の問題
-
libreswan
の動作のリグレッションにより、IPsec が有効になっている一部のノードが、同じクラスター内の他のノード上の Pod との通信を失う原因となりました。この問題を解決するには、クラスターの IPsec を無効にすることを検討してください。(OCPBUGS-42952)
OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。
OpenShift Container Platform 4.1 から 4.14 にアップグレードされたクラスターのクラスター管理者の場合は、認証されていないアクセスを取り消すか、許可し続けることができます。認証なしのアクセスが必要な理由が特に無い限り、無効にしてください。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。
警告認証されていないアクセスに依存するアプリケーションがある場合、認証されていないアクセスを取り消すと HTTP
403
エラーが生じる可能性があります。以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。
-
cluster-status-binding
-
discovery
-
system:basic-user
-
system:discovery
-
system:openshift:discovery
-
-
oc annotate
コマンドは、等号 (=
) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patch
またはoc edit
を使用してアノテーションを追加します。(BZ#1917280) インストールプログラムが Google Cloud Platform (GCP) サービスアカウントに関連付けられているすべてのプロジェクトを取得できない場合、インストールは失敗し、
context deadline exceeded
というエラーメッセージが表示されます。この現象は、次の条件が満たされる場合に発生します。
- サービスアカウントが、過剰な数のプロジェクトにアクセスできる場合。
インストールプログラムが、次のいずれかのコマンドで実行される場合。
openshift-install create install-config
Error message
FATAL failed to fetch Install Config: failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded
FATAL failed to fetch Install Config: failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のインストール設定ファイル (
install-config.yaml
) を使用しないopenshift-install create cluster
Error message
FATAL failed to fetch Metadata: failed to fetch dependency of "Metadata": failed to fetch dependency of "Cluster ID": failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded
FATAL failed to fetch Metadata: failed to fetch dependency of "Metadata": failed to fetch dependency of "Cluster ID": failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": failed to get projects: context deadline exceeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のインストール設定ファイルを使用、または使用しない
openshift-install create manifests
Error message
ERROR failed to fetch Master Machines: failed to load asset "Install Config": failed to create install config: platform.gcp.project: Internal error: context deadline exceeded
ERROR failed to fetch Master Machines: failed to load asset "Install Config": failed to create install config: platform.gcp.project: Internal error: context deadline exceeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 回避策として、インストール設定ファイルがある場合は、使用する特定のプロジェクト ID (
platform.gcp.projectID
) でそれを更新します。それ以外の場合は、インストール設定ファイルを手動で作成し、特定のプロジェクト ID を入力します。ファイルを指定して、インストールプログラムを再度実行します。(OCPBUGS-15238)
- 大規模なコンピュートノードでは起動に失敗します。(OCPBUGS-20075)
-
IBM Power® 上に
OVNKubernetes
のネットワークタイプを持つクラスターをデプロイすると、カーネルスタックのオーバーフローが原因で、コンピュートノードが再起動する可能性があります。回避策として、ネットワークタイプをOpenShiftSDN
としてクラスターをデプロイできます。(RHEL-3901) 次の既知の問題は、リリース候補 3 または 4 を使用して OpenShift Container Platform デプロイメントを早期アクセスバージョンの 4.14 に更新したユーザーに適用されます。
ノード識別機能の導入後、root として実行されていた一部の Pod は、特権なしで実行されるように更新されます。OpenShift Container Platform 4.14 の早期アクセスバージョンに更新したユーザーの場合、4.14 の正式バージョンにアップグレードしようとすると進まない可能性があります。このシナリオでは、Network Operator は
DaemonSet "/openshift-network-node-identity/network-node-identity" update is rolling
を報告し、更新の問題を示します。回避策として、
oc delete --force=true -n openshift-network-node-identity --all pods
コマンドを実行して、openshift-network-node-identify
namespace 内のすべての Pod を削除できます。このコマンドを実行すると、更新が続行されます。早期アクセスの詳細は、candidate-4.14 チャネル を参照してください。
-
ユーザーは現在、
openshift-multus
namespace のcni-sysctl-allowlist
config map を更新して、interface-specific
の安全な sysctl リストを変更できません。回避策として、手動または DaemonSet を使用して、ノード上の/etc/cni/tuning/allowlist.conf
ファイルを変更できます。(OCPBUGS-11046) OpenShift Container Platform 4.14 では、すべてのノードが、デフォルトの RHEL 9 設定に合わせた内部リソース管理に Linux コントロールグループバージョン 2 (cgroup v2) を使用します。ただし、クラスターにパフォーマンスプロファイルを適用する場合、パフォーマンスプロファイルに関連付けられた低遅延チューニング機能は、cgroup v2 をサポートしません。
その結果、パフォーマンスプロファイルを適用すると、クラスター内のすべてのノードが再起動され、cgroup v1 設定に戻ります。この再起動には、パフォーマンスプロファイルの対象になっていないコントロールプレーンノードとワーカーノードが含まれます。
クラスター内のすべてのノードを cgroups v2 設定に戻すには、
Node
リソースを編集する必要があります。詳細は、Linux cgroup v2 の設定 を参照してください。最後のパフォーマンスプロファイルを削除しても、クラスターを cgroups v2 設定に戻すことはできません。(OCPBUGS-16976)-
OpenShift Container Platform 4.14 を使用してインストールされたクラスターでは、AWS
M4
およびC4
インスタンスが適切に起動できない場合があります。現在のところ回避策はありません。(OCPBUGS-17154) - このリリースには、インストーラーがプロビジョニングしたインフラストラクチャーを使用して Alibaba Cloud にクラスターをインストールできない既知の問題があります。Alibaba Cloud へのクラスターのインストールは、このリリースではテクノロジープレビュー機能になります。(OCPBUGS-20552)
- ルートボリュームのアベイラビリティーゾーンがあり、4.14 にアップグレードする RHOSP で実行されているクラスターの場合、コントロールプレーンマシンセットを有効にする前に、コントロールプレーンマシンを 1 つのサーバーグループに統合する必要があります。必要な変更を加えるには、knowledge base article の手順に従ってください。(OCPBUGS-13300)
- 少なくとも 1 つのゾーンで設定されたコンピュートゾーンがあり、バージョン 4.14 にアップグレード可能な RHOSP 上で実行されているクラスターの場合、ルートボリュームも少なくとも 1 つのゾーンで設定する必要があります。この設定変更が行われない場合、クラスター用のコントロールプレーンマシンセットを生成できません。必要な変更を加えるには、knowledge base article の手順に従ってください。(OCPBUGS-15997)
-
現時点で、SR-IOV ネットワークデバイスを使用する Pod を削除するとエラーが発生する可能性があります。このエラーは、ネットワークインターフェイスの名前が変更されると、以前の名前が代替名リストに追加されるという RHEL 9 の変更によって発生します。その結果、SR-IOV Virtual Function (VF) にアタッチされた Pod が削除されると、VF は元の名前 (
ensf0v2
など) ではなく、予期しない新しい名前 (dev69
など) でプールに戻ります。このエラーは重大なエラーではありませんが、システムが自動修復する際に、Multus および SR-IOV ログにエラーが表示される場合があります。このエラーにより、Pod の削除に数秒かかる場合があります。(OCPBUGS-11281, OCPBUGS-18822, RHEL-5988) -
RHEL 5.14.0-284.28.1.el9_2
以降、特定の MAC アドレスを使用して SR-IOV Virtual Function を設定すると、i40e ドライバーで設定エラーが発生する可能性があります。その結果、Intel 7xx シリーズ NIC に接続の問題が発生する可能性があります。回避策として、Pod リソースのmetadata.annotations
フィールドに MAC アドレスを指定しないようにします。代わりに、ドライバーが Virtual Function に割り当てるデフォルトのアドレスを使用してください。(RHEL-7168, OCPBUGS-19536, OCPBUGS-19407, OCPBUGS-18873) -
現在、
Tuned
リソースのprofile
フィールドで、名前にスラッシュが含まれる設定 (ボンディングデバイスなど) のsysctl
値を定義すると、機能しない可能性があります。sysctl
オプション名にスラッシュが含まれる値は、/proc
ファイルシステムに正しくマップされません。回避策として、必要な値を使用して設定ファイルを/etc/sysctl.d
ノードディレクトリーに配置するMachineConfig
リソースを作成します。(RHEL-3707) 現在、Kubernetes の問題により、CPU マネージャーは、ノードに許可された最後の Pod から利用可能な CPU リソースのプールに CPU リソースを戻すことができません。これらのリソースは、後続の Pod がノードに許可された場合は割り当てることができます。ただし、これが最後の Pod となり、CPU マネージャーは再びこの Pod のリソースを使用可能なプールに戻すことができなくなります。
この問題は、CPU 負荷分散機能に影響を与えます。これらの機能は、CPU マネージャーが使用可能なプールに CPU を解放することに依存しているためです。その結果、保証されていない Pod は、少ない CPU 数で実行される可能性があります。回避策として、影響を受けるノード上で
best-effort
CPU マネージャーポリシーを使用して、Pod をスケジュールします。この Pod は許可された最後の Pod となり、リソースが使用可能なプールに適切に解放されるようにします。(OCPBUGS-17792)- 現在、Machine Config Operator (MCO) がワーカープールとカスタムプールのマシン設定を処理する方法が原因で、MCO はカスタムプールに間違った cgroup バージョン引数を適用する可能性があります。その結果、カスタムプール内のノードに間違った cgroup カーネル引数が設定され、予測できない動作が発生する可能性があります。回避策として、ワーカーおよびコントロールプレーンプールのみに cgroup バージョンのカーネル引数を指定します。(OCPBUGS-19352)
-
現在、物理ネットワークデバイスへの
udev
ルールの適用と、すべてのネットワークデバイスへのデフォルトの 1 秒あたりのリクエスト (RPS) マスクの適用との間で競合状態が発生しているため、一部の物理ネットワークデバイスは間違った RPS マスク設定を備えている可能性があります。その結果、RPS マスク設定が正しくない物理ネットワークデバイスに、パフォーマンスの低下による影響が及ぶ可能性があります。今後の z-stream リリースには、この問題の修正が含まれる予定です。(OCPBUGS-21845) - 従来の Single Root I/O Virtualization (SR-IOV) の Broadcom ネットワークインターフェイスコントローラーは、SRIOV VLAN の quality of service (QoS) および tag protocol identifier (TPID) 設定をサポートしていません。これは、Broadcom BCM57414、Broadcom BCM57508、および Broadcom BCM57504 に影響します。(RHEL-9881)
デュアルスタックネットワークを使用する環境でホステッドクラスターを作成すると、次の DNS 関連の問題が発生する可能性があります。
-
service-ca-operator
Pod のCrashLoopBackOff
状態: Pod が Hosted Control Plane 経由で Kubernetes API サーバーに到達しようとすると、kube-system
namespace のデータプレーンプロキシーがリクエストを解決できないため、Pod はサーバーに到達できません。この問題は、HAProxy セットアップでフロントエンドが IP アドレスを使用し、バックエンドが Pod が解決できない DNS 名を使用するために発生します。 -
Pod が
ContainerCreating
状態でスタックする: この問題は、openshift-service-ca-operator
が DNS Pod が DNS 解決に必要とするmetrics-tls
シークレットを生成できないために発生します。その結果、Pod は Kubernetes API サーバーを解決できません。
これらの問題を解決するには、デュアルスタックネットワーク用の DNS の設定 のガイドラインに従って DNS サーバー設定を指定します。(OCPBUGS-22753, OCPBUGS-23234)
-
OpenShift Container Platform の Hosted Control Plane では、次の Operator とコンポーネントはテストされていません (OCPSTRAT-605)。
- Performance Addon Operator
- OpenShift sandboxed containers
- Red Hat OpenShift GitOps
- Red Hat OpenShift Service Mesh
- Red Hat OpenShift Pipelines
- Red Hat OpenShift Dev Spaces
- Red Hat のシングルサインオンテクノロジー
- OpenShift Container Platform Web コンソールの Web ターミナル
- Migration toolkit for applications
- OpenShift Container Platform の Hosted Control Plane では、ホスト型クラスターへの File Integrity Operator のインストールが失敗します。(OCPBUGS-3410)
- OpenShift Container Platform の Hosted Control Plane では、Vertical Pod Autoscaler Operator をホスト型クラスターにインストールできません。(PODAUTO-65)
- ベアメタルおよび OpenShift Virtualization プラットフォーム上の OpenShift Container Platform の Hosted Control Plane では、自動修復機能が無効になっています。(OCPBUGS-20028)
- OpenShift Container Platform の Hosted Control Plane では、AWS Secrets Manager または AWS Systems Manager Parameter Store での Secrets Store CSI Driver Operator の使用がサポートされていません。(OCPBUGS-18711)
-
OpenShift Container Platform の Hosted Control Plane では、
default
、kube-system
、およびkube-public
namespace が Pod のセキュリティーアドミッションから適切に除外されません。(OCPBUGS-22379) - OpenShift Virtualization 上の Hosted Control Plane では、再起動後にワーカーノードがネットワーク接続を失う可能性があります。(OCPBUGS-23208)
- OpenShift Container Platform の Hosted Control Plane では、HyperShift Operator は Operator の初期化中にリリースメタデータを 1 回しか抽出しません。管理クラスターに変更を加えたり、ホストされたクラスターを作成したりしても、HyperShift Operator はリリースメタデータを更新しません。回避策として、Pod のデプロイメントを削除して HyperShift Operator を再起動します。(OCPBUGS-29110)
-
OpenShift Container Platform の Hosted Control Plane では、非接続環境で
ImageDigestMirrorSet
オブジェクトとImageContentSourcePolicy
オブジェクトのカスタムリソース定義 (CRD) を同時に作成すると、HyperShift Operator がImageContentSourcePolicy
CRD を無視して、ImageDigestMirrorSet
CRD のみのオブジェクトを作成します。回避策として、ImageDigestMirrorSet
CRD にImageContentSourcePolicies
オブジェクト設定をコピーします。(OCPBUGS-29466) -
OpenShift Container Platform の Hosted Control Plane では、非接続環境でホストされたクラスターを作成するときに、
HostedCluster
リソースでhypershift.openshift.io/control-plane-operator-image
アノテーションを明示的に設定しないと、ホストされたクラスターのデプロイメントがエラーで失敗します。(OCPBUGS-29494) vSphere でのエージェントベースのインストールは、ノードテイントの削除に失敗したために失敗します。これにより、インストールが保留状態のままになります。シングルノードの OpenShift クラスターは影響を受けません。この問題を回避するには、次のコマンドを実行してノードテイントを手動で削除します。
oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-
$ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
このリリースではテクノロジープレビュー機能である Azure 機密仮想マシンには、使用上の既知の問題があります。platform-managed key (PMK) または customer-managed key (CMK) を使用して、マネージドディスクと Azure VM Guest State (VMGS) Blob を暗号化するようにクラスターを設定することは、サポートされていません。この問題を回避するには、
securityEncryptionType
パラメーターの値をVMGuestStateOnly
に設定して、VMGS Blob の暗号化のみを有効にします。(OCPBUGS-18379) このリリースではテクノロジープレビュー機能である Azure 機密仮想マシンには、使用上の既知の問題があります。コントロールプレーンのプロビジョニングプロセスが 30 分後にタイムアウトになるため、この機能を使用するように設定されたクラスターのインストールは失敗します。
この問題が発生した場合は、
openshift-install create cluster
コマンドを 2 回目として実行し、インストールを完了できます。この問題を回避するには、マシンセットを使用して既存のクラスターで Confidential VM を有効にします。(OCPBUGS-18488)
- ベアメタルプラットフォーム上で OpenShift Container Platform の Hosted Control Plane を実行する場合、ワーカーノードに障害が発生すると、他のエージェントが使用可能な場合でも、別のノードがホスト型クラスターに自動的に追加されません。回避策として、障害が発生したワーカーノードに関連付けられたマシンを手動で削除します。(MGMT-15939)
-
ソースカタログにはアーキテクチャー固有の
opm
バイナリーがバンドルされているため、そのアーキテクチャーからミラーリングを実行する必要があります。たとえば、ppc64le カタログをミラーリングしている場合は、ppc64le アーキテクチャーで実行されているシステムから oc-mirror を実行する必要があります。(OCPBUGS-22264) -
複数の OpenShift Container Platform グループが同じ LDAP グループを指している場合、1 つの OpenShift Container Platform グループのみが同期されます。
oc adm groups sync
コマンドは、複数のグループが同じ LDAP グループを指している場合、マッピングの対象となるのが 1 つのグループのみであることを示す警告を出力します。(OCPBUGS-11123) -
セキュアブートが無効になっているノード上で、
bootMode
をUEFISecureBoot
に設定して OpenShift Container Platform をインストールすると、インストールが失敗します。セキュアブートを有効にして OpenShift Container Platform をインストールしようとすると、通常どおり続行されます。(OCPBUGS-19884) -
OpenShift Container Platform 4.14 では、Ignition バージョン 3.4 の
MachineConfig
オブジェクトが、CrashLoopBackOff
エラーでapi-collector
Pod のスキャンに失敗し、Compliance Operator が想定どおりに動作しなくなる可能性があります。(OCPBUGS-18025) - OpenShift Container Platform 4.14 では、プライマリーネットワークインターフェイスではないネットワークインターフェイスへの IPv6 egress IP の割り当ては、サポートされていません。これは既知の問題であり、OpenShift Container Platform の今後のバージョンで修正される予定です。(OCPBUGS-17637)
- Run Once Duration Override Operator (RODOO) は、HyperShift Operator によって管理されるクラスターにはインストールできません。(OCPBUGS-17533)
-
OpenShift Container Platform クラスターで CNF 遅延テストを実行すると、
oslat
テストで 20 マイクロ秒を超える結果が返されることがあります。これにより、oslat
テストが失敗します。(RHEL-9279) -
リアルタイムカーネルで
preempt-rt
パッチを使用し、ネットワーク割り込みの SMP アフィニティーを更新すると、対応する IRQ スレッドはすぐには更新を受信しません。代わりに、次の割り込みを受信したときに更新が有効になり、その後スレッドが正しいコアに移行されます。(RHEL-9148) -
高解像度タイマーに依存してスレッドをウェイクアップする低遅延アプリケーションでは、想定よりも長いウェイクアップ遅延が発生する可能性があります。想定されるウェイクアップ遅延は 20 μs 未満ですが、
cyclictest
ツールを長時間 (24 時間以上) 実行すると、これを超える遅延が発生することがあります。テストの結果、99.999999% 以上のサンプルで、ウェイクアップ遅延が 20μs 未満であることが示されました。(RHELPLAN-138733) グランドマスタークロック (T-GM) として設定されている Intel Westport Channel e810 NIC の Global Navigation Satellite System (GNSS) モジュールは、GPS
FIX
状態と、GNSS モジュールと GNSS コンステレーション衛生間の GNSS オフセットを報告できます。現在の T-GM 実装では、GNSS オフセットおよび GPS
FIX
値を読み取るために、ubxtool
CLI を使用してublox
モジュールをプローブすることはしません。代わりに、gpsd
サービスを使用して GPSFIX
情報を読み取ります。これは、ubxtool
CLI の現在の実装では応答を受信するのに 2 秒かかり、呼び出しごとに CPU 使用率が 3 倍に増加するためです。(OCPBUGS-17422)- GNSS からクロック供給される PTP グランドマスタークロックでは、GNSS 信号が失われると、Digital Phase Locked Loop (DPLL) クロック状態が 2 つの方法に変更される可能性があります。つまり、ロック解除に移行するか、ホールドオーバー状態に移行するかのいずれかになります。現在、ドライバーはデフォルトで DPLL 状態をロック解除に移行します。ホールドオーバー状態機能を処理し、どのステートマシン処理を使用するかを設定するためのアップストリームの変更が現在開発中です。(RHELPLAN-164754)
- DPLL サブシステムと DPLL サポートは現在、Intel Westport Channel e810 NIC Ice ドライバーでは有効になっていません。(RHELPLAN-165955)
-
現在のグランドマスタークロック (T-GM) 実装には、バックアップ NMEA センテンスジェネレーターなしで、GNSS から提供される単一の NMEA センテンスジェネレーターがあります。NMEA センテンスが e810 NIC に向かう途中で失われた場合、T-GM はネットワーク同期チェーン内のデバイスを同期できず、PTP Operator はエラーを報告します。修正案は、NMEA 文字列が失われたときに
FREERUN
イベントを報告することです。(OCPBUGS-19838) -
現在、コンテナーの cgroup 階層のセットアップの違いにより、
crun
OCI ランタイムとPerformanceProfile
設定を使用するコンテナーでは、パフォーマンスの低下が発生します。回避策として、runc
OCI コンテナーランタイムを使用します。runc
コンテナーランタイムは、コンテナーの起動中、シャットダウン操作中、exec
プローブ中のパフォーマンスが低下しますが、crun
コンテナーランタイムとrunc
コンテナーランタイムは機能的には同じものです。今後の z-stream リリースには、この問題の修正が含まれる予定です。(OCPBUGS-20492) -
実行時に IPsec を有効および無効にした後に、
an unknown error has occurred: MultipleErrors
というエラーメッセージを表示して、クラスターが健全でない状態となる既知の問題があります。(OCPBUGS-19408) コントロールプレーンノードにスケジュールされている Microsoft Azure File NFS ボリュームを含む Pod を作成すると、マウントが拒否されます。
この問題を回避するには、コントロールプレーンノードがスケジュール可能で、Pod がワーカーノードで実行できる場合は、
nodeSelector
または Affinity を使用してワーカーノードで Pod をスケジュールします。(OCPBUGS-18581)- RHOSP 17.1 で実行され、ネットワーク機能仮想化 (NFV) を使用するクラスターの場合、RHOSP の既知の問題により、クラスターのデプロイメントが正常に行われません。この問題に対する回避策はありません。Red Hat サポートに連絡して、ホットフィックスをリクエストしてください。(BZ#2228643)
- RHOSP 17.1 での Kuryr インストールはサポートされていません。
現在、OpenShift Container Platform 4.14 の HAProxy バージョン 2.6.13 への更新により、再暗号化トラフィックの P99 レイテンシーが増加します。これは、Ingress トラフィックの量により、
IngressController
カスタムリソース (CR) の HAProxy コンポーネントにかなりの負荷がかかる場合に発生します。全体的なスループットは、レイテンシーの増加の影響を受けず、一貫したままになります。デフォルトの
IngressController
CR は、4 つの HAProxy スレッドで設定されています。Ingress トラフィック (特に再暗号化トラフィック) が多い状況で、P99 レイテンシーの上昇が発生した場合は、HAProxy スレッドの数を増やしてレイテンシーを減らすことを推奨します。(OCPBUGS-18936)-
4.14 上のシングルノード OpenShift および Google Cloud Platform (GCP) では、Cloud Network Config Controller (CNCC) が
CrashLoopBackOff
状態になるという既知の問題があります。これは、CNCC が GCP 内部ロードバランサーアドレスに到達しようとする初期化時に発生し、結果として生じるヘアピントラフィックが GCP 上の OVN-Kubernetes 共有ゲートウェイモードで正しく阻止されず、ドロップされてしまいます。このような場合、Cluster Network Operator はProgressing=true
ステータスを表示します。現在、この問題に対する回避策はありません。(OCPBUGS-20554) - CPU が保証されており、割り込み要求 (IRQ) の負荷分散が無効になっているシングルノード OpenShift では、コンテナーの起動時に大きなレイテンシースパイクが発生する可能性があります。(OCPBUGS-22901)
- 多数の Pod があり、その一部に CPU 制限が設定されているアプリケーションをデプロイすると、デプロイが失敗する可能性があります。回避策は、アプリケーションを再デプロイすることです。(RHEL-7232)
機能が無効になっているシングルノード OpenShift では、
openshift-controller-manager-operator
が継続的に再起動される可能性があります。回避策として、ビルド機能を有効にするか、builds.config.openshift.io
CRD を手動で作成します。builds.config.openshift.io
CRD を手動で作成するには、次の手順を実行します。次のコマンドを実行して、リリースマニフェストを展開します。
oc adm release extract --to manifests
$ oc adm release extract --to manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow manifests
ディレクトリーおよびサブディレクトリー内でbuilds.config.openshift.io
を検索します。grep -r builds.config.openshift.io manifests
$ grep -r builds.config.openshift.io manifests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 予想される出力
manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml: name: builds.config.openshift.io
manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml: name: builds.config.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 0000_10_openshift-controller-manager-operator_01_build.crd.yaml
で指定された設定を適用します。oc apply -f manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml
$ oc apply -f manifests/0000_10_openshift-controller-manager-operator_01_build.crd.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- Microsoft Azure Stack Hub 上の OpenShift Container Platform のこのバージョンにクラスターをインストールしたり、クラスターを更新したりできない既知の問題があります。詳細と回避策は、こちらの Red Hat ナレッジベースの記事 を参照してください。(OCPBUGS-20548)
OpenShift Container Platform 4.14.2 より前のバージョン 4.14 で Azure AD Workload Identity を使用する Microsoft Azure クラスターには、既知の問題があります。
eastus
リージョンにおける新しい Azure ストレージアカウントのデフォルトのセキュリティー設定を最近変更したことで、そのリージョンでの Azure AD Workload Identity を使用するクラスターのインストールが阻止されます。現時点では、他のリージョンは影響を受けていないようですが、将来的に影響を受ける可能性があります。この問題は OpenShift Container Platform 4.14.2 で解決されています。
この問題を回避するには、短期認証情報を使用するように Azure クラスターを設定する の手順で
ccoctl azure create-all
を実行する前に、パブリックアクセスを許可するストレージアカウントを手動で作成します。以下の手順を実行します。
次の Azure CLI コマンドを実行して、ストレージアカウントのリソースグループを作成します。
az group create --name <oidc_resource_group_name> --location <azure_region>
$ az group create --name <oidc_resource_group_name> --location <azure_region>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の Azure CLI コマンドを実行して、パブリックアクセスを許可するストレージアカウントを作成します。
az storage account create --name <storage_account_name> --resource-group <oidc_resource_group_name> --location <azure_region> --sku Standard_LRS --kind StorageV2 --allow-blob-public-access true
$ az storage account create --name <storage_account_name> --resource-group <oidc_resource_group_name> --location <azure_region> --sku Standard_LRS --kind StorageV2 --allow-blob-public-access true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
ccoctl
ツールを使用してすべてのCredentialsRequest
オブジェクトを処理する場合は、前の手順で作成したリソースを指定する必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
静的 IP アドレス指定と Tang 暗号化を使用して OpenShift Container Platform クラスターをインストールする場合、ノードはネットワーク設定なしで起動します。この状況により、ノードは Tang サーバーにアクセスできなくなり、インストールが失敗します。この状況に対処するには、各ノードのネットワーク設定を
ip
インストーラー引数として設定する必要があります。インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストール前に次の手順を実行して、各ノードの
IP
インストーラー引数としてネットワーク設定を指定します。- マニフェストを作成します。
各ノードについて、アノテーションを使用して
BareMetalHost
カスタムリソースを変更し、ネットワーク設定を含めます。以下に例を示します。cd ~/clusterconfigs/openshift vim openshift-worker-0.yaml
$ cd ~/clusterconfigs/openshift $ vim openshift-worker-0.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow ip
設定は、次のように置き換えます。- 1
<static_ip>
は、ノードの静的 IP アドレスに置き換えます (例:192.168.1.100
)- 2
<gateway>
は、ネットワークのゲートウェイの IP アドレスに置き換えます (例:192.168.1.1
)- 3
<netmask>
は、ネットワークマスクに置き換えます (例:255.255.255.0
)- 4
<hostname_1>
は、ノードのホスト名に置き換えます (例:node1.example.com
)- 5
<interface>
は、ネットワークインターフェイスの名前に置き換えます (例:eth0
)- 6
<fqdn>
は、ノードの完全修飾ドメイン名に置き換えます。- 7
<role>
は、ノードのロールを反映するworker
またはmaster
に置き換えます。- 8
<bmc_ip>
は、必要に応じて BMC IP アドレスと BMC のプロトコルとパスに置き換えます。
-
ファイルを
clusterconfigs/openshift
ディレクトリーに保存します。 - クラスターを作成します。
Assisted Installer を使用してインストールする場合は、インストール前に API を使用して各ノードのインストーラー引数を変更し、ネットワーク設定を
IP
インストーラー引数として追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以前のネットワーク設定の場合は、次のように置き換えます。
詳細とサポートは、Red Hat Support チームにお問い合わせください。
- このリリースには、Web Terminal Operator をインストールした後に、Web Terminal Operator にアクセスできなくなるという既知の問題があります。この問題は、今後の OpenShift Container Platform リリースで修正される予定です。(OCPBUGS-14463)
-
Cluster Network Operator をバージョン 4.13 から 4.14 にアップグレードする場合、既知の問題が発生します。新しい OVN Kubernetes 相互接続マルチゾーンアーキテクチャーへの変換により、パケットドロップが発生し、短時間のネットワーク停止が発生する可能性があります。
routingViaHost
がtrue
に設定されたローカルゲートウェイモードの East/West トラフィックに影響があります。(OCPBUGS-38891) -
OpenShift Container Platform 4.14 の HAProxy には、無効な
Transfer-Encoding
ヘッダーを送信するアプリケーションに関する既知の問題があります。この問題により、これらの無効なヘッダーを送信するルートを公開すると、Pod への外部アクセスが失われます。詳細は、この Red Hat ナレッジベースの記事 の情報を参照してください。(OCPBUGS-43095)