1.8.10. Kube API Server


  • 今回のアップデート以前は、kube-apiserver-check-endpoints コンテナーが、ポート 17697 の check-endpoint サービス用に、有効期間がわずか 1 秒の TLS 証明書を生成していました。その結果、証明書は生成後ほぼ即座に期限切れとなっていました。これは、証明書の有効期間が 1 カ月だった以前の OpenShift Container Platform のバージョンとは異なっていました。今回のリリースにより、kube-apiserver-check-endpoints コンテナーが、適切な有効期間を持つ証明書を生成するようになりました。その結果、check-endpoint サービスの証明書が、以前のリリースと同様に、想定される期間にわたって有効な状態を維持するようになりました。OCPBUGS-105469
  • 今回のアップデート以前は、カスタムサービスアカウント発行者を使用してインストールされたクラスターには、最初の 24 時間の間、カスタム発行者とデフォルトの発行者の両方が含まれていました。その結果、サービスアカウントトークンには 2 つのオーディエンスが含まれるようになり、オーディエンスを明示的に指定しない限り、一部のアプリケーションはデプロイできなくなっていました。今回のリリースにより、インストール時に設定した場合、カスタム発行者のみが存在することになりました。これにより、サービスアカウントトークンには単一のオーディエンスが含まれるようになり、一部のアプリケーションを即座にデプロイできるようになりました。OCPBUGS-105469
  • 今回のアップデート以前は、Kube API サーバーの証明書ファイルが書き込み後にディスクへ即座にフラッシュされず、データがストレージに永続化されないままメモリー上に残る可能性がありました。その結果、シングルノードの OpenShift クラスターでは、グレースフルではないシャットダウンにより、すべての Kube API サーバー証明書が失われ、クラスターが起動できなくなる可能性があります。今回のリリースでは、証明書の書き込みは以前のデータが削除される前にディスクにフラッシュされるため、クラッシュ時のデータ消失に対する耐性が確保されます。これにより、予期せぬシャットダウンが発生したシングルノードの OpenShift クラスターは、Kube API サーバー証明書を失うリスクがなくなりました。OCPBUGS-105469
  • このアップデート以前は、手動認証情報モードで Hive または ACM を介して STS クラスターをデプロイする場合、kube-apiserver Operator は最初の改訂時に認証 CR からのカスタムサービスアカウント発行者を無視していました。その結果、kube-apiserver は 起動時にデフォルトの発行者を使用し、ブートストラップ後に正しい発行者で展開したため、トークンの有効期限切れと競合し、インストールタイムアウトが発生しました。今回のアップデートにより、Operator はレンダリングされた入力マニフェストからサービスアカウントの発行者を検出する方式に戻ります。その結果、Hive または ACM を使用する STS クラスターのインストールにおいて、サービスアカウントの発行者不一致が原因で発生するタイムアウトは発生しなくなりました。OCPBUGS-105469
  • 今回のアップデート以前は、kube-apiserver-to-kubelet-signer の CA 証明書の更新間隔が、有効期間が 365 日間であるにもかかわらず、誤って 30 日間に設定されていました。その結果、認証局 (CA) が毎月再生成され、不要な kube-apiserver の ロールアウトが引き起こされた。今回のアップデートにより、更新間隔は 292 日 (有効期間の 80%) に設定され、他の署名者と整合性が取れるようになりました。その結果、認証局が時期尚早に再生成されることがなくなり、不要なロールアウトも発生しなくなった。OCPBUGS-105469
  • 今回のアップデート以前は、Go OpenSSL Federal Information Processing Standards (FIPS) プロバイダーが同時リクエストによって libcrypto ライブラリーに過負荷をかける可能性がありました。その結果、プロセスが maxThreads の上限である 10,000 に達してクラッシュする可能性がありました。今回のリリースでは、Go OpenSSL FIPS プロバイダーが更新され、libcrypto ライブラリーへの同時要求数が CPU 数の 4 倍までに制限されるとともに、要求は軽量な Goroutine としてバッファリングされるようになりました。これにより、プロセスは maxThreads の制限を回避し、クラッシュしなくなりました。OCPBUGS-105469
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る