1.5. 既知の問題
- 安全ではない sysctl を OpenShift Container Platform 4.1 で使用することはできません。(BZ#1690754)
- インスタンスが (ユーザーの削除によるか、またはある cloud-provider のイベントによって) クラウドプロバイダーから削除され、machine-object が何らかの理由により再び調整される場合、machine-controller はインスタンスが存在しなくなったと判別し、そのインスタンスの作成を試行する可能性があります。これは文書化されていない動作であり、ワークフローに関連してこの動作に信頼することはできません。この操作は、node-health-checker などを含め、現在または今後のコンポーネントに干渉する可能性があります。(BZ#1712068)
- シェルの置換を使用して環境変数を設定するビルドは失敗する可能性があります。(BZ#1712245)
-
machine-object を直接に、または所有する machine-set のスケールダウンによって削除する場合、関連付けられているノードが (クラスター管理者などによって) すでに削除されている場合、machine-controller はサポートするクラウドインスタンスの削除に失敗し、machine-object は
deletingステータスのままになります。(BZ#1713061) -
JBoss EAPイメージでのJolokiaのクエリーは、空の証明書がクライアントに提示されることにより失敗します。JolokiaSSL クライアント認証が失敗し、(有効にされている場合は) ユーザー名とパスワードのチャレンジが必要になる場合があります。(BZ#1708640) -
TokenRequestAPI は OpenShift Container Platform 4.1 で利用できません。ServiceAccountTokenVolumeProjectionボリュームの要求は OpenShift Container Platform 4.1 では実行できません。kubelet はServiceAccountTokenVolumeProjectionが使用される場合にエラーを出します。(BZ#1695196) -
Elasticsearch CRD インスタンスの
es nodeCountは 3 つのノードでデプロイされている場合にはスケールアップできません。スケーリングは 1、2、4、5 または 6 つの Elasticsearch CRD インスタンスでデプロイされている場合には正常に機能します。(BZ#1712955) - OperatorHub から作成される Elasticsearch インスタンスは、制限が指定されていない場合でも CPU の制限が 1 に設定された状態でデプロイされます。(BZ#1710657)
-
AWS のインストール後に
openshiftClustIDタグは表示されません。(BZ#1685089) -
scc(CRD) リソースは
oc patchおよびoc editコマンドを使用してアップグレードできません。そのため、ステラテジーに基づくマージも失敗します。(BZ#1707679) - OpenShift Container Platform 4.1 レジストリーサービスは、ポート 443 ではなく、ポート 5000 を使用します。(BZ#1701422)
- AWS 環境での Machineset のスケーリングは、要求されたリソースが選択されたアベイラビリティーゾーンで使用できない場合に失敗する可能性があります。(BZ#1713157)
-
カスタム PKI の Ingress ワイルドカード証明書を設定した後に
OAuthエンドポイントを使用するとログインエラーが生じます。(BZ#1712525) - OpenShift Container Platform 4.1 での Source-to-Image (S2I) ビルドは完了までに長い時間がかかる可能性があります。これは、OpenShift Container Platform 4.1 では以前のバージョンの OpenShift Container Platform とは異なり、イメージのビルドに共有イメージのキャッシュを使用しないためです。(BZ#1685352)
-
cloud-credential-operatorは、メモリーの制限により、多くのプロジェクトや namespace を含むクラスターでクラッシュする可能性があります。(BZ#1711402) -
Marketplace はクラスターのアップグレードの実行後は
opsrcを検知できません。そのため、cscパッケージは空になり、packagemanifestsをダウンロードできません。Marketplace は同期を再度開始する約 1 時間後にこの問題を修復します。(BZ#1695550) -
OpenShift Container Platform 4.1 では、
oc versionのチェック時にocおよびopenshift-installのバージョンにダーティーなGitTreeState:が含まれる可能性があります。(BZ#1715001) -
AWS 環境では、マスターノードが停止すると、Pod が
Pendingステータスのままになるためにkubeapiserverをデプロイできません。(BZ#1713292) -
AWS のすべての m4 インスタンスは、
microcode_ctlが更新されないために Broadwell CPU モデル 79 (タイプ m4) を使用した検証に失敗します (CVE-2019-1109)。(BZ#1710981) - 新規 ElasticSearch デプロイメントの作成は、別の ElasticSearch デプロイメントが削除 (deleting) 状態のままであると実行できません。(BZ#1711044)
- OpenShift Container Platform 4.1 Web コンソールで Open Java Console リンクを使用することはできません。(BZ#1713656)
-
openshift-cluster-node-tuning-operatorは数日間のアップタイムの後に多数のシークレットを生成する可能性があります。(BZ#1714484) - メモリー使用状況についての自動スケーリングは予想通りに機能しません。リソースの検索中にメモリーベースの自動スケーリング用の HPA を作成すると失敗します。(BZ#1707785)
-
更新を正常に実行した後に、
oc get clusterversionは更新を適用できなかったことを報告する可能性があります。(BZ#1711964) -
インストーラーは FATAL イベントに直面すると、
0戻りコードを返す可能性があります。 サービスカタログを無効にした後に、クラスターでプロジェクトを削除しようとすると「Terminating (終了)」の状態になる可能性があります。これは、サービスカタログ API サービスが正しく削除されないことによって生じ、削除でハングします。サービスカタログは、
kubernetes-incubator/service-catalogファイナライザーを持つサービスインスタンスリソースを適切にクリーンアップしません。そのため、namespace コントローラーは namespace (プロジェクト) の削除を終了できません。サービスカタログに変更が加えられ、サービスカタログを無効にした後はその API サービスの削除を試行しなくなったため、ハングしなくなりました。サービスカタログの削除後にプロジェクトが「Terminating (終了)」状態になった場合、クラスター管理者は以下の回避策を使用できます。
サービスカタログを使用してデプロイされた既存のサービスを保持する場合は、関連するサービスバインディングリソースで使用されるシークレットの
ownerReferencesフィールドを手動で削除する必要があります。これを実行しない場合、API サービスの削除時にサービスバインディングと共にシークレットが削除され、アプリケーションはサービスにアクセスできなくなる可能性があります。注記既存のサービスを保持する必要がない場合は、この手順を省略できます。
API サービスを手動で削除します。
$ oc delete apiservice v1beta1.servicecatalog.k8s.io
この回避策を実装したら、問題なくプロジェクトの削除を継続できます。(BZ#1746174)
