cc @ironcladlou @ bgrant0607

仕様を変更せずにポッドを再起動するためのユースケースは何ですか？

再起動時にポッドに障害が発生し始めた場合、変更をロールバックする方法はないことに注意してください。

サービスが何らかのくさび状態または望ましくない状態になるときはいつでも（接続が最大になり、現在ストールしている、内部状態が悪いなど）。 これは通常、サービスが深刻な誤動作を起こしている場合の最初のトラブルシューティング手順の1つです。

最初のポッドが再起動時に失敗した場合、続行を停止するか、ポッドの開始を再試行し続けると思います。

また、仕様を変更せずにローリングリスタートすると、ポッドが
集まる。

ただし、スケジュールを変更せずにこれを実行できる機能も必要です。
ポッド。 それはローリングラベルの変更である可能性がありますが、新しいダイナミックを拾う可能性があります
ローカルファイルの状態を設定またはクリアします。

午前12:01水、2015年9月2日には、サムGhodsの[email protected]は書きました：

サービスが何らかのくさび状態または望ましくない状態になるときはいつでも（最大になります）
接続が停止し、内部状態が悪いなど）。 それは通常です
サービスが深刻な場合の最初のトラブルシューティング手順の1つ
不正行為。

再起動時に最初のポッドに障害が発生した場合、ポッドは停止すると予想されます
ポッドを開始するために続行するか、再試行を続行します。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
。

クレイトンコールマン| OpenShiftのリードエンジニア

@smarterclaytonそれは上記の私のオプション2のようなものですか？ なぜラベルが変更されるのでしょうか？

NS。 ウェッジ：それがライブネスプローブの目的です。

NS。 リバランス：＃12140を参照

これをサポートした場合は、＃9043でまとめます。同じメカニズムが必要です。

これは、ポッドが動作していてチェックに応答しているが、それでも再起動する必要がある状況の場合に当てはまると思います。 1つの例は、メモリ内キャッシュまたは内部状態が破損していて、クリアする必要があるサービスです。

アプリケーションの再起動を要求することはかなり一般的なユースケースのように感じますが、おそらく私は間違っています。

破損はただ1つのポッドであり、それはただ殺されてRCに置き換えられる可能性があります。

オフラインで言及されたもう1つのケースは、構成を再読み取りすることでした。 何らかの理由で再起動するとコンテナが新しい構成をロードするため、暗黙的に行うのは危険です。 ローリングアップデートを実行して、新しいバージョンの構成参照（env varなど）をポッドにプッシュすることをお勧めします。 これは、＃1353の動機に似ています。

@ bgrant0607これをしたくないと決めましたか？

@gmarek何も、今のところ。 すでに多くのことが進行中です。

重要と思われるものにpost v1.1マイルストーン（または何か）を設定できますが、すぐに修正できる人が不足していますか？

私もこの機能のファンです。ロールアウトするマイナーアップデートごとにタグを切り替える必要はありません。

私はこの機能のファンです。 ユースケース：すべてのポッドを簡単にアップグレードして、新しくプッシュされたDockerイメージ（ imagePullPolicy: Always ）を使用します。 私は現在、少しハッキーな解決策を使用しています。画像名に:latestタグを付けて、または付けずにローリングアップデートします。

別のユースケース：シークレットの更新。

この機能を本当に見たいです。 kubernetesでノードアプリを実行しており、現在、ポッドを再起動してアプリの疑似キャッシュをクリアする特定のユースケースがあります。

これが私が今していることです：

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

これにより、ポッド10が一度に削除され、レプリケーションコントローラーのセットアップで適切に機能します。 ポッドの割り当てや新しいポッドの起動の失敗などの懸念には対処していません。 必要なときにすばやく解決できます。

ローリングリスタートができるようになりたいです。
主な理由は、ConfigMapを使用してENV変数をポッドにフィードし、構成を変更した場合、そのConfigMapのコンシューマーを再起動する必要があるためです。

はい、内部を変更せずにポッド/コンテナを本当に再起動したい場合がたくさんあります...
設定、キャッシュ、外部サービスへの再接続など。この機能が開発されることを本当に望んでいます。

小さな回避策（デプロイメントを使用していて、イメージ/ポッドを実際に変更せずに構成を変更したい）：

• configMapを作成します
• 任意のコンテナーでENV変数（デプロイメントのインジケーターとして使用します）を使用してデプロイメントを作成します
• configMapを更新します
• 展開を更新します（このENV変数を変更します）

k8sは、デプロイの定義が変更されたことを確認し、ポッドを置き換えるプロセスを開始します
PS：
誰かがより良い解決策を持っているなら、共有してください

ありがとう@paunin

@pauninまさにそれが現在必要な場合です-サービスにとって非常に重要であり、数分から数時間以内にコンテナーにロールアウトする必要があるConfigMap値を変更する必要があります。 その間にデプロイが行われない場合、コンテナはすべて同時に失敗し、少なくとも数秒の部分的なダウンタイムが発生します

from（ kinda -related＃9043）： RESTART_は環境変数であり、ISOタイムスタンプに設定されています。

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

（何らかの理由で、 _始まる環境変数が消えたように見え、数値env valueはエラーを引き起こすため、文字列である必要があります）

@paunin @rcoup最近は非常によく似た処理を行っていますが、文字通り「DUMMY_VAR_FOR_NO_OP_DEPLOYMENT」と呼ばれるenv変数があります。

ここでの適切なソリューションにより、デプロイメントを再開し、MinReadyCountなどのロールアウトのデプロイメントパラメーターのほとんどを再利用できると同時に、すべてをすぐにバウンスする必要がある緊急事態の並列処理を増やすなどのコマンドラインオーバーライドが可能になると思われます。

これについて何か進展はありますか？

この追加は、CLIAPIの不必要な肥大化であるように感じます。 これは、@ pauninによって提案されているように、デプロイメント環境変数の値

kubectl restart deployment some-apiような展開でもこれを確認したいと思います

Kubernetesはさまざまな理由でポッドを再起動できますが、クラスター管理者は再起動できません。
「オフにしてから再びオンにする」という道徳的な立場は、操作するのに望ましい方法ではないかもしれないことを理解しています...しかし、希望する人々に、範囲に頼らずに展開を再開させることも問題ないと思います次のような食欲をそそるトリックの

• ポッドの削除
• ダミーラベル
• ダミー環境変数
• 環境変数にマップされたダミー構成マップ
• ワーカーノードの再起動
• データセンターへの電力を削減😄

「いいえ、いいえ、私は何も再開していません。ここでこのラベルのタイプミスを修正するだけです」😛

この機能は、 kubectl applyと組み合わせて使用​​すると便利です。 applyは、レプリケーションコントローラーを含む構成を更新しますが、ポッドは再起動されません。

したがって、これらのポッドを青緑の方法で再起動する方法が必要です。

@DmitryRomanenko ReplicationControllersからDeploymentsに切り替えるのはどうですか？ これにより、ReplicaSets（ReplicationControllerの後継）の更新を実行できるようになります。

@kargakisそれは不可能です：デプロイメントはレプリカセットとポッドのみを更新します。
kubectl applyを使用して、ConfigMaps、Servicesなども更新します。

@DmitryRomanenko問題が「ConfigMap / Secretが更新されたときにポッドを再起動したい」の場合、考えられる解決策は、ConfigMapとSecretsのバージョンを用意し、そのバージョンをデプロイメント仕様の一部にすることです。 したがって、 kubectl applyすると、Deploymentの仕様が変更され、ポッドが再作成されます。
他の状況では、ポッドを再起動する必要がある理由がわかりません（つまり、サービス/入力などの更新）。

@tyranron 、ありがとう！ ConfigMapをバージョン管理するための最良の方法は何ですか？ 新しい展開用に別の名前で新しい構成マップを作成する必要がありますか？

@DmitryRomanenkoあなたが実際にできる、なぜですか？ ただし、この場合、古いものを削除するように注意する必要があります。 一方、ロールバックには役立つ場合があります。 ただし、ほとんどの場合、ラベルを使用してバージョンを指定するだけで十分です。

ここでの最善の解決策は、 configmapオブジェクトに対するある種のウォッチャーまたはハッシュサムチェッカーである可能性があると私は信じています。 関連するオブジェクト/ポッドの再起動をトリガーする必要があります（すべてがそのconfigmap 、 secret ）。 k8sアーキテクチャでアクセスできるものかどうかはわかりませんが...

また、変更時に再起動をトリガーするには、 configmap|secretオブジェクトから制御する方がよいと思います。

@tyranron 、

そのため、kubectlを適用すると、Deploymentの仕様が変更され、ポッドが再作成されます。

説明してもらえますか？ 更新されたデプロイメントでkubectl apply -f new_config.ymlを使用するだけで、これらのデプロイメントはローリングリスタートされますか？

@DmitryRomanenkoうん、正確に。

@DmitryRomanenkoは、 Deploymentを

デフォルトでは、再起動戦略はRollingUpdateですが、別の戦略を明示的に指定することもできます。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

/lifecycle frozenコメントを使用して、問題が自動終了しないようにします。

この問題を今すぐ解決できる場合は、 /close 。

sig-testing、kubernetes / test-infra、および/または@fejtaフィードバックを送信します。
/ lifecycle stale

@rcoupのソリューションへの小さな変更： dateがシェル内で評価されていることを確認してください：

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/ remove-lifecyclestale
/ライフサイクル凍結

Kubernetesよりも柔軟性が低いと考えられるSwarmモードをしばらく使用していたので、 docker service update --force <service-name>ように強制更新（仕様を変更せずに）を実行するだけで、サービスタスク（読み取り：デプロイメントポッド）を再開できます。
configmapsとsecretsに関しては、swarmではそれらを編集できません。代わりにそれらをローテーションする必要があります。 これを行うには、新しいconfigmaps / secretsを作成し、新しいものを使用するようにサービススペックを更新してから、古いものを削除します。 これは通常、configmaps / secertsをバージョン管理し、それらを使用するデプロイメントを更新することにより、上記で推奨されているものだと思います。 正直なところ、この回転の振る舞いは、私が群れを残した主な理由の1つです。 ローカルコピーを作成し、更新してから新しいリソースを作成し、最後に依存リソースを更新するのは非常に不便です。 それに加えて、swarmのシークレットはAPIから読み取ることができません。それらを任意のコンテナー内にマウントし（またはそれらを使用するコンテナー内のexec）、次にファイルをcatマウントする必要があります。
関連するメモとして、私はしばらくの間openshiftを使用しましたが、env / configmap / secret changeでポッドを自動再起動すると思いますか？ しかし、私は正直に立っています。

configmap / secretでチェックサムを使用して、その方法で強制的に再起動できるように、ファイルシステムの変更を監視するのはアプリの責任である必要があります

ただし、構成をまったく変更せず、任意の一時停止でローリングリスタートを実行する場合は、単純なパイプラインがその役割を果たします（これは終了したポッド間で30秒間スリープします）

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

ctrl + cを押すと、中断したところから再開するのは簡単ではないことに注意してください

@ so0k 、代替コマンド：

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

2年半経った今でも、ダミーのenv変数、dumyラベル、ConfigMapとSecretウォッチャーのサイドカーを使用して新しい回避策を作成し、ゼロにスケーリングし、ローリング更新シェルスクリプトをまっすぐにして、ローリング更新をトリガーする機能をシミュレートしています。 これはまだ、トリックなしでクラスター管理者が正直に行うことを許可されるべきではないことですか？

27081＃33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

もう1つのトリックは、最初に実行することです。

kubectl set image deployment/my-deployment mycontainer=myimage:latest

その後：

kubectl set image deployment/my-deployment mycontainer=myimage

実際にはローリングアップデートがトリガーされますが、imagePullPolicy： "Always"も設定されていることを確認してください。

画像名を変更する必要がない、私が見つけたもう1つのトリックは、terminationGracePeriodSecondsのように、ローリング更新をトリガーするフィールドの値を変更することです。 これは、kubectl edit Deploymentyour_deploymentまたはkubectlapply -f your_deployment.yamlを使用するか、次のようなパッチを使用して実行できます。

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@ so0k @KIVagantポッドを削除すると、複数のインスタンスを実行している場合でもダウンタイムが発生します。 誰かがstrategy.rollingUpdate.maxUnavailable = 0単一のポッドを実行すると、通常の展開では、既存のポッドを終了する前に、最初に新しいポッドが作成されます。 kubectl patch deploymentトリックはこの動作をトリガーしますが、ポッドを削除してもトリガーされません。 この動作をオンデマンドでトリガーするための、ハッキングのない方法が本当に必要です。

たとえば、hub.docker.comからイメージを実行する場合、セキュリティ更新のために同じタグにパッチを適用できます。 本当に「最新の画像をプル」して、古い画像のローリングアップデートを実行したいと思います。

ConfigMap / Secretアップデートのロールアウトは＃22368です
新しい画像のより簡単な展開は＃1697です
インプレースローリングアップデートは＃9043です

イメージビルドで再起動します： https ：
テンプレート化されたアノテーションを使用してデプロイのロールアウトをトリガーするトリックのヘルムサミットプレゼンテーション： https ：

@ bgrant0607他のチケットでカバーされていない重要なユースケースはこれだと思います： https ：

@ghodssは書いた：
これは、ポッドが動作していてチェックに応答しているが、それでも再起動する必要がある状況の場合に当てはまると思います。 1つの例は、メモリ内キャッシュまたは内部状態が破損していて、クリアする必要があるサービスです。

アプリケーションの再起動を要求することはかなり一般的なユースケースのように感じますが、おそらく私は間違っています。

ローリングリスタートを強制して、手動のトリックなしですべてのアプリケーションの状態をクリアしたいと思います。

@rcoupと@pauninが説明したアプローチに基づいた同様のワンライナーがありますが、より一般的なケースでは機能するはずです。 JSON出力に依存し、解析にjqを使用します。 これを関数としてbashrcにロードしているので、どこからでも呼び出すことができます

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

これにより、 kubectl-restart my-deployment-nameとだけ言うことができ、最初のコンテナのRESTART_ env変数が現在のタイムスタンプに「更新」されます。 私はjqの専門家から遠く離れているので、もっと良い方法があるかもしれませんが、基本的には古いRESTART_ env varを出力から削除し（存在する場合）、そこに追加します。現在の時刻。

しかし、これを行うためのネイティブな方法がないことは私には非常に奇妙に感じます...確かにエンジニアでいっぱいの部屋は「それをオフにしてから再びオンにする」機能が私たちが望んでいるものであることに同意するでしょう。

これはすばらしいハックですが、大きな欠点があります。 次回kubectl apply -fを使用してデプロイするとき、RESTART_xxx env varがあれば、他に何も変更されていなくても、そのコンポーネントは再起動されます。 つまり、最後の展開とこの展開の間に再起動したことがある場合は、次の展開で誤った再起動が発生します。 理想的ではありません...

そのため、ローリングリスタート機能は、上に構築するのではなく、Deploymentコントローラーに組み込む必要があります。

上記のコメントで引用されている「 terminationGracePeriodSecondsパッチ展開」戦略@whereisaaronを実現するためにbash関数を作成しました（ソース：https：

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

ここのください。 これが必要でなければもっと良いだろうという他の人のコメントをエコーし​​ます。

より具体的にはkube関連の正当化として、再起動によりinit-containerの再実行も可能になります。これは、キーのロール、構成の更新、またはinitコンテナーの使用に使用できます。

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro適用した構成にRESTART_xxxenv varがありましたか？ そうでない場合は、ライブ状態で余分なenv変数を無視するように適用することを期待します。

cc @apelisse

@gjcarneiroええ、 @ mattdodgeスクリプトの問題は、

この機能が欲しいです。 それは非常に基本的で必要なようです。

ここでも＃22368でも進展はありません、le sigh :-(

マウントされたConfigMapが更新された後（名前は同じです）、DaemonSetを再起動するための迅速で汚い解決策を誰かが推奨できますか？

@alcohol 、これを確認してくださいhttps://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

ヒントをありがとう:-)

Openshiftには、イメージの変更、Webhook、または設定の変更時にロールアウトをトリガーするデプロイメントトリガーの概念があります。 Kubernetesにあると非常に良い機能になります。 もちろん、手動での展開も同様です。

さらに、Dockerリポジトリには履歴があるため、ロールバックが機能しなかった理由はありません。 .spec.templateから生成されたポッドは、コンテナーのイメージをプルするときにimage-tag:@digest形式を使用できます。 ロールバックは、前のロールアウトのダイジェストIDを使用します。

私が正しく理解しているかどうかわからない。 これが誰かを助ける場合に備えて。

ポッド>テンプレート>メタデータの下のラベルの値を更新すると、 kubectl apply -f file.yaml後にローリング更新が行われるようです

したがって、いつでもバージョンのラベルを付けることができ、ローリングアップデートが必要なときはいつでも、バージョンを変更してファイルを適用できます。

確かに、欠点は、次にデプロイを実行するときに、 kubectl apply -f some.yamlを実行することです。 通常、 some.yaml何も変更されない場合、何も再起動されません。これは、Kubernetesの最も優れた点の1つです。

ただし、ラベルを変更してデプロイメントを再開した後に何が起こるか想像してみてください。 次の通常のソフトウェアデプロイメントでは、通常どおりkubectl apply -f some.yamlを実行しますが、yamlファイルに同じラベルが含まれていないため、デプロイメントが不必要に再起動されます。

@gjcarneiro変更を加えたときにapply変更しないと、 kubectl.kubernetes.io/last-applied-configurationアノテーションは更新されないため、次のapplyによって再度再起動することはありません。

私はkubectlにローリングリスタートコマンドを追加することに強く賛成ですが、それまでの間、私は以下を使用しています（上記のソリューションに基づく）：

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

これをパラメータ化して、.bashrcの関数として追加すると、適切な暫定ソリューションになります。

ああ、かっこいい、知らなかった、ありがとう！

bashエイリアスは必要ありません。私の会社では、Python + aiohttpを使用してKubernetesを管理するための独自のWebインターフェイスを作成し、すでにパッチを使用しています。 私はそれをオープンソーシングすることを考えました、ただ怠惰でした...

人々はこのスレッドで同じ回避策を繰り返しているようです-ここに投稿する前にスレッド全体を読んでください

@joelittlejohnマクロを実行すると、ポッドの再起動がDIDでトリガーされましたが、すべて同時に再起動しました。 これでローリングリブートがトリガーされると思いましたね。

@Macmeeデプロイメントの構成によって異なります。 上記のコマンドは、デプロイメントを変更するだけです。 次に、展開で定義されたロールアウトstrategyに従って、ポッドが更新されます。 これは、デプロイメントに対する他の変更とまったく同じです。

これがすべてのポッドを同時に置き換える唯一の方法は、 .spec.strategy.rollingUpdate.maxUnavailable許可されている場合です。

この機能も必要です。 私たちの側でも1つのユースケースは、spring-bootアプリにscmでバックアップされたspring-cloud-config-serverを使用することです。 構成プロパティを変更する場合、新しい構成変更をフェッチできるようにするには、spring-bootアプリを再起動する必要があるため、再デプロイを行わずにこの種の正常な再起動トリガーも必要です。

@japzio Helmが提案しているように、アノテーション内のconfigmapのチェックサムは、その場合を処理するための良い方法です。

これに関する更新はありましたか？ この機能も検討しています。 @ bgrant0607 @nikhiljindal

@ bholagabbar-mtあなたのユースケースは何ですか？

cc @ kow3ns @janetkuo

@ bgrant0607 @ kow3ns当社のシステムのためのユースケース@janetkuoは多種多様です。

1. 秘密の更新-私のように、kubernetesを介して独自の抽象化を構築している企業がたくさんあることをご存知だと思います。 kubernetes上で調整された独自のコンテナ管理システムがあります。 したがって、舵取りの秘密の提案コメントなどは適用されません。 開発クラスターのConfigMapからシークレットを再ロードするには、ポッドを強制的に強制終了する必要があり、その結果、数秒のダウンタイムが発生します。 これは当てはまらないはずです。 これは、ローリングアップデートの実際のユースケースです。

2. これは少し複雑ですが、誰かが示唆したように、全体的な範囲は異常な動作を修正することです。 Playフレームワークで実行されている4〜5個の重いJavaアプリがあります。 Javaポッドのメモリ消費量が直線的に増加し、メモリ制限に達するとポッドを再起動するという状況が発生しています。 これは、との文書化されたJavaの問題ですstackoverflowの問題とKubernetes問題、それに関連します。 3〜4時間以内にすべてのポッドをローリング再起動すると、メモリ消費量がリセットされ、アプリがスパイクなしでスムーズに機能できるようになります。

うまくいけば、これは十分に説得力があり、この機能は開発のために誰かが利用することができますか？

@ bholagabbar-mtは環境変数を変更するだけで、ローリングデプロイがトリガーされます。

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynnこれは完璧です。 この変更を今日のシステム自体に統合しましたが、正常に動作します。 トンありがとう！

cc @huzhengchuan

これの別のユースケース：containerdのセキュリティ問題のため、すべてのポッドを再起動したいと思います。 https://seclists.org/oss-sec/2019/q1/119クラスターが完全にダウンするか、ローリングリスタートを実行します。 再起動コマンドがあると、大きな違いが生じます。

更新、回避策：

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfreshあなたがベストプラクティスです。 牧場主にannotation:{creatTime: 12312312}を追加してください！

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

1つの展開で機能する最小限のコマンドのようです。 これは、命令型構成の使用例です。

cc @monopole @apelisse

〜2〜 3年半経った今でも、ダミーのenv変数、ダミーのラベル、ダミーのアノテーション、ConfigMapとSecretウォッチャーのサイドカー、ゼロへのスケーリング、能力をシミュレートするためのローリング更新シェルスクリプトなど、新しい回避策を

ローリングアップデートは、明らかにユースケースがないものに対してはまだかなり人気のあるアクティビティです😄

長期的な問題（自己メモ）

1. 命令論理を宣言型APIにブリードさせずにこれを行う方法はわかりません。これにより、APIを宣言型に保ち、コントローラーに命令型の動作を実装するという慣習を破り、ほとんどのCI / CDプラクティスとの非互換性を導入します。
2. RollingRestart APIとコントローラーを想像できます。RollingRestartリソースを作成すると、コントローラーはエビクションを介してポッドを1つずつ再起動します（したがって、中断バジェットを尊重します）が、そのようなコントローラーはCRDとして実装できます（つまり、理由がわかります）これはツリーで行う必要があります）。
3. lastRestartedAt = TIMESTAMPアノテーションを追加するなどの宣言型アプローチは、私にはハックのようには思えません。
4. この機能を（ツリーまたはその他の方法で）実装するための宣言型の設計と貢献を提供したい場合は、拡張リポジトリに対してKEPPRを作成することを検討してください。 宣言型の組み込み実装を設計できる場合は、ワークロードAPIを確認/シェパードできれば幸いです。 [2]のようなCRDコントローラーが提供されている場合は、コミュニティが後援する拡張機能としてSIGAppsで後援することができます。

lastRestartedAt = TIMESTAMPアノテーションを追加するなどの宣言型アプローチは、私にはハックのようには思えません。

これはハックではありません。簡単なコマンドラインが必要です。

誰かがパッチを送信するkrewプラグインを作成する可能性があります。 kubectl restart-deployment <deployment_name> ？

kubectl rollout restartは、デプロイメント/デーモンセット/ステートフルセットにパッチを適用して、新しい「ロールアウト」をトリガーしますか？

これは@ kow3nsのアプローチ（3）とkubectl rolloutコマンドで開始したロールアウトを監視/一時停止/再開できるため、ある程度意味があります。

@whereisaaronそのパッチを送信できるかどうかを確認します（しゃれは意図されていません）

新しいシークレットと構成マップを展開する場合でも、私の推奨事項は＃22368です。新しいシークレットを作成します。 これは、ロールアウトの制御とロールバックの両方の手段を提供します。 古いオブジェクトのGCを終了する必要があります。
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

ただし、既存のAPIを使用してローリングリスタートを実行するための推奨される方法を文書化および/またはサポート（kustomize、kubectl、またはkubectlプラグイン）することは合理的です。

cc @monopole

新しい画像については、CI / CDまたはタグを解決してダイジェストするコントローラー：＃1697。

不幸なポッドの移動は、descheduler（https://github.com/kubernetes-incubator/descheduler）などによって実行されることを目的としており、コンテナーのステータス、コアメトリック、さらにはカスタムメトリックを消費する可能性があります。

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

また、シークレットとconfigmapの処理方法に関する公式ドキュメント： https ：//kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

ローリングリスタートは非常に必要です。 1つの例は、AWSのSSMからすべてのシークレットを取得することです。 SSMからシークレットを変更した場合は、ポッドが起動時に最新のものを取得するように、ローリングリスタートを実行します。 また、実際の修正が本番環境に到達するまで、ローリング再起動が必要なアプリケーションの問題が発生する場合もあります。

OK、 kubectl rollout restartがマージされました！

ほぼ4年後に聞いてうれしいです、ありがとう！

マージされたPRはデプロイメントのみをサポートすると思いますが、それは正しいですか？

この問題の一部の人々は、デーモンセットとステートフルセットも再起動する必要があると表明しています。

@apelisseは、SDKまたは単にkubectlを介してこれを行う方法もありますか？

@ e-nikolov SDKとは何ですか？

Goプログラムからkubernetesと通信するために使用できるGoクライアントを意味しました。

いいえ、kubectlに実装されている（非常に単純な）ロジックを再実装する必要があります。

OK、kubectlロールアウトの再起動がマージされました！

どのkubectlバージョンにそれがありますか？

どのkubectlバージョンにそれがありますか？

Kubernetes 1.15

「高速」リリースチャネル上のGKEクラスターがKubernetes1.16にアップグレードされ、 kubectl rollout restartが機能しなくなりました。

kubectlロールアウト再起動デプロイメントmyapp
エラー：不明なコマンド「restartdeploymentmyapp」

@nikhiljindalは、仕様を変更せずにデプロイメントを更新するためのユースケースについて少し前に質問しました。 最適ではない方法で行っている可能性がありますが、ここでは、事前にトレーニングされたMLモデルがGoogle CloudStorageからメモリに読み込まれます。 モデルファイルがGCSで更新されたら、GCSからモデルをプルするK8Sデプロイメントをロールアウトして再起動します。

以前のモデルファイルでデプロイを簡単にロールバックできないことを感謝しますが、これは、モデルをアプリにできるだけ近づけてネットワーク呼び出しを回避するために採用したトレードオフです（一部の人が示唆しているように）。

ねえ@dimileeh

現在使用しているkubectlのバージョンを知っていますか？ 以前に使用したバージョンは何ですか？ リグレッションがあったかどうか知りたいのですが、同時に機能が完全に消えてしまったら驚きます。

GCSのことに関しては、ユースケースについてほとんど知らないので、意味がない場合は申し訳ありません。gcsモデルは、変更されるたびに異なる名前（おそらくハッシュの接尾辞）を取得することをお勧めします。名前はデプロイメントに含まれます。 新しいファイルを使用するようにデプロイメントを更新すると、ロールアウトが自動的にトリガーされます。 これにより、以前のデプロイメント/モデルにロールバックしたり、モデルに発生した変更をよりよく理解したりすることができます。

こんにちは@apelisse 、ご回答ありがとうございます！

Google Cloud Terminalからkubectl versionを実行すると、次のようになります。

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

gcloud components updateを介してkubectlをアップグレードしようとすると、すでにすべての製品の最新バージョンを使用していると表示されました。 したがって、K8Sクラスターが1.15から1.16にアップグレードされている間、私のkubectlバージョンは同じままだったと思います。

Kubenetesのドキュメント1.17、1.16、および1.15には、 kubectl rollout restart機能については何もありません。 それで、あなたの貴重な貢献が1.16から消えたのではないかと思いますか？

モデルのバージョン管理についてご提案いただきありがとうございます。これは理にかなっています。 それについて考えましたが、毎日モデルを再トレーニングしているので、あまりにも多くのモデルを蓄積し始めると思いました（そしてそれらはかなり重いです）。 もちろん、スクリプトを使用してしばらくしてから古いバージョンをクリーンアップすることもできますが、これまでのところ、モデルのバージョン管理を気にせず、 kubectl rollout restart依存して単純にすることにしました:)

私はここでドキュメントを見ることができます：
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

ああ、ありがとう、私はここを見ていました：
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

そのリンクをありがとうございました、私はそれが更新されることを確認します！

12:40ドミトリLihhatsovの木、2019年12月19日には[email protected]
書きました：

ああ、ありがとう、私はここを見ていました：
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
。

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 （これがマージされたら、関連するブランチを選択します）。

@dimileeh私はあなたのkubectlバージョンの何が問題なのか理解したと思います。私たちはそれに取り組んでいきます。

はい、configmapを更新した後、コードを変更せずにポッドを再起動するユースケースもあります。 これは、サービスを再デプロイせずにMLモデルを更新するためです。

実行できる最新バージョンの@anuragtr

kubectl rollout restart deploy NAME

私はそのためにカスタムコマンドを使用していました[1]、それが標準のkubectlに含まれていることをうれしく思います！ ありがとう

[1] https://github.com/mauri870/kubectl-renew

実行できる最新バージョンの@anuragtr

kubectl rollout restart deploy NAME

@countrogue