Kubernetesで実行されている一連のポッドを更新するにはどうすればよいですか？
Kubernetesクラスターのレプリケーションコントローラーによって制御される一連のポッドを更新する好ましい方法は何ですか（たとえば、コードを変更して、基になるDockerイメージをDockerハブにプッシュした後）？
私は2つの方法を見ることができます：
- レプリケーションコントローラの手動での削除と再作成
kubectl rolling-updateの使用
rolling-updateを使用して、レプリケーションコントローラの名前を変更する必要があります。レプリケーションコントローラーの定義をYAMLファイルに保存し、手動で生成していないため、ファイルを変更してコード更新をプッシュする必要があると、レプリケーションコントローラーの2つの名前（コントローラーAとコントローラーBなど）を交互に変更するなどの悪い習慣が生じるようです。名前の競合を避けてください。
より良い方法は何ですか？
更新：kubectl rolling-updateは非推奨になり、置換コマンドはkubectl rolloutです。また、ローリングアップデートはクライアントではなくサーバー側で実行されるため、元の回答を書いたため、Deploymentリソースが追加されており、ReplicaSetsよりも優れた選択肢です。
kubectl rolling-updateを使用してください。最近、「単純なローリング更新」を実行する機能を追加しました。これにより、名前を変更せずにレプリケーションコントローラのイメージを更新します。これは、kubectl help rolling-update出力に表示される最後の例です。
// Update the pods of frontend by just changing the image, and keeping the old name
$ kubectl rolling-update frontend --image=image:v2
このコマンドは回復もサポートします。更新をキャンセルして後で再起動すると、中断したところから再開します。舞台裏で新しいレプリケーションコントローラーを作成しますが、更新の最後に、新しいレプリケーションコントローラーは古いレプリケーションコントローラーの名前を使用するため、まったく新しいレプリケーションコントローラーに切り替えるのではなく、純粋な更新のように見えます。
The following explanations are fromKubernetes In Action 's book
レプリケーションコントローラの削除と再作成手動
ローリング更新を手動で行うはlaboriousおよびerror-prone。レプリカの数によっては、更新プロセスを実行するために、適切な順序で12個以上のコマンドを実行する必要があります。幸運にも、Kubernetesでは、 1つのコマンドでローリング更新を実行します。
Kubectlrolling-updateの使用
ReplicationControllersを使用してローリング更新を手動で実行する代わりに、kubectlで更新を実行できます。 kubectlを使用して更新を実行するとプロセスがはるかに簡単になりますが、これは現在、アプリを更新する古い方法です。
このように更新を実行するのは、命令型であるため、それほどうまくいかない場合があります。どのようにKubernetesがシステムの望ましい状態を伝え、Kubernetesがそれを実行するための最良の方法を考え出すことによって、その状態を独自に達成するかについてです。
アプリを宣言的に更新するためにDeploymentsを使用する--THE BEST ALTERNATIVE--
Deploymentは、アプリケーションをデプロイして宣言的に更新することを目的とした高レベルのリソースであり、どちらも低レベルの概念と見なされるReplicationControllerまたはReplicaSetを介して行うのではありません。
低レベルの構成の代わりにDeploymentを使用すると、単一のDeploymentリソースを通じて目的の状態を定義し、Kubernetesに残りの処理を任せるため、アプリの更新がはるかに簡単になります。
もう1つ、ロールバック展開のため、ロールアウトが可能です。