回答:
単一のコンテナを再起動することは可能ですか
を介してkubectlではありませんが、クラスターの設定に応じて「チート」および「」を行うことができますdocker kill the-sha-goes-here。これにより、kubletは「失敗した」コンテナーを再起動します（もちろん、ポッドの再起動ポリシーはそれを行うべきであると想定しています）
ポッドを再起動する方法
それはポッドの作成方法によって異なりますが、指定したポッド名に基づいて、kubectl delete pod test-1495806908-xn5jnレプリカセットの監視下にあるように見えるため、kubernetesが代わりに新しいものを作成します（新しいポッドには別の名前なので、二度とkubectl get pods戻ることを期待しないでくださいtest-1495806908-xn5jn）
docker kill the-sha-goes-here、docker container restart the-sha-goes-here代わりになぜしないのですか？なぜkubeletそれを再起動することに頼るのですか？とにかく、本当の問題はdocker、コンテナーを強制終了するためにコマンドをどこで実行するかです。でcould-shell、dockerK8Sクラスタから容器を示していません！
ポッドを削除してKubernetesに再作成させるのではなく、特定のコンテナを再起動したい場合があります。
やってkubectl exec POD_NAME -c CONTAINER_NAME /sbin/killall5私のために働きました。
（コマンドを以下の推奨事項rebootに/sbin/killall5基づいてからに変更しました。）
reboot。/sbin/killall5代わりに実行するほうが運が良かった。これですべてのプロセスが終了し、コンテナが終了します。
kubectl exec POD_NAME -c CONTAINER_NAME /sbin/reboot魅力のように働きました
ポッドとコンテナはどちらも短命です。次のコマンドを使用して特定のコンテナを停止すると、k8sクラスタが新しいコンテナを再起動します。
kubectl exec -it [POD_NAME] -c [CONTAINER_NAME] -- /bin/sh -c "kill 1"
これSIGTERMにより、コンテナーで実行されているメインプロセスであるプロセス1に信号が送信されます。他のすべてのプロセスはプロセス1の子になり、プロセス1が終了した後に終了します。送信できる他のシグナルについては、killマンページを参照してください。
kubernetesを使用する理由は、コンテナを管理するため、ポッド内のコンテナのライフサイクルをそれほど気にする必要がないためです。
deploymentを使用する設定があるのでreplica set。を使用してポッドを削除できますkubectl delete pod test-1495806908-xn5jn。kubernetesは、ダウンタイムなしで2つのコンテナを持つ新しいポッドの作成を管理します。ポッド内の単一のコンテナを手動で再起動しようとすると、kubernetesの利点全体が無効になります。
上記の回答はすべて、ポッドの削除について言及していますが、同じサービスのポッドが多数ある場合、それらのポッドをそれぞれ削除するのは面倒です...
したがって、私は次の解決策を提案し、再起動します：
1）スケールをゼロに設定します。
kubectl scale deployment <<name>> --replicas=0 -n service
上記のコマンドは、すべてのポッドを次の名前で終了します <<name>>
2）ポッドを再度開始するには、レプリカを0より大きい値に設定します
kubectl scale deployment <<name>> --replicas=2 -n service
上記のコマンドは、2つのレプリカでポッドを再起動します。
kubectl patch deployment <deployment name> -p "{\"spec\": {\"template\": {\"metadata\": { \"labels\": { \"redeploy\": \"$(date +%s)\"}}}}}"代わりに使用してください。これによりデプロイメントが更新されるため、ローリング更新戦略に従ってデプロイメントによって管理されるすべてのポッドの再作成が開始されます。
非常に便利なコマンドラインを使用して、統合ポッドに新しいイメージを強制的に再デプロイします。
高山のコンテナはすべてPID 5で「維持」コマンドを実行していることに気付きました。したがって、SIGTERM信号を送信するとコンテナがダウンします。imagePullPolicyに設定されAlwaysていると、コンテナーを戻すときにkubeletが最新のイメージを再プルします。
kubectl exec -i [pod name] -c [container-name] -- kill -15 5
kill -15 5ていますが、killコマンドを実行して、シグナル "-15"をPID 5のプロセスに送信しています。これは、プロセスを終了させたいことをプロセスに伝える方法です（SIGTERM ）、開いているリソース（一時ファイル、dbトランザクションのロールバック、接続のクローズなど）をクリーンアップするのに時間がかかります。-9（SIGKILL）とは対照的に、プロセスをすぐに強制終了し、開いているリソースをクリーンアップできません。
kubectl exec -it POD_NAME -c CONTAINER_NAME bash - then kill 1
コンテナーがrootとして実行されていると仮定すると、これはお勧めできません。
私の場合、アプリケーション構成を変更したとき、サイドカーパターンで使用されていたコンテナーを再起動する必要があり、Dockerユーザーが所有するSpring BootアプリケーションのPIDを強制終了しました。
kubectl exec -it ${POD_NAME?} -c ${CONTAINER_NAME?} bash ...、コピー/貼り付けがはるかに簡単になります。