2

k8s の抽象化として Knative を使用する Cloud run on gke を使用してサービスをデプロイしました。MaxRevisionTimeoutSecondsknative のデフォルト設定ではデフォルトは 600 に設定されていますが、このPRによればこれはカスタマイズ可能です。

Knative の公式ドキュメントには何も見つかりませんでした。誰か助けてくれませんか?

更新：

knative のソース コードとドキュメントをもう少し掘り下げた後。MaxRevisionTimeoutSecondsで定義されているようですresource=ConfigMap/config-defaults。そのため、カスタム値で更新する必要があります。

このことから、asと呼ばれるものを使用して ConfigMap リソースを変更できるように見えますがoperator、おそらく gcp がオペレーターを使用して Knative コンポーネントをインストールしないため、機能しませんでした。とにかく、私はオペレーターをインストールしresource=knativeserving、config-defaults を上書きしていました。しかし、これもサービスを再デプロイしようとしたときに機能しませんでした。

次の解決策は、 を使用して config-defaults を直接編集することkubectl editです。私もこれをやろうとしましたが、奇妙な動作に遭遇しました。以前は変更された値を確認していたときに YAML ファイルを編集した後kubectl describe、変更された値が表示されることもあれば、古い値が表示されることもあり、YAML の特定のキーと値のペアが表示されないこともあります。また、この編集を行った後にサービスを再デプロイしようとしても機能しません。

誰かがこれで私を助けることができれば、それは本当に素晴らしいことです.

4

1 に答える 1

2

MaxRevisionTimeoutSecondsTimeoutSeconds各リビジョンの最大値を適用するクラスタ グローバル設定です。この値が存在するのは、クラスター管理者が単一の HTTP 要求がシステム内に存在できる時間の上限を設定できるようにするためです。上限を知っておくと、HTTP ルーティング コンポーネントでグレースフル シャットダウン設定を構成して、アップグレード中に要求がドロップされないようにするときに役立ちます。

Cloud Run on GKE がこれらの構成をオーバーライドして、基盤となる Istio および Knative コンポーネントを予測可能なスケジュールでアップグレードできるようにしている可能性があります。(10% のアップグレード予算があり、コンポーネントの排出に 10 分かかる場合、追加のスケジュール設定、イメージの取得、起動時間を考慮すると、最小アップグレード時間はおそらく約 110 分になります。)

于 2020-06-14T14:27:07.640 に答える