やあ、
ここに記載されているように間違った順序でそれを行って申し訳ありません： https ：
この問題に対処するために＃22439を実行しました（kubectl側）
必要なのは、単一のコマンドラインでデーモンセットを更新できるようにすることです。
基本的にそれは行うことと同等です：
kubectl delete -f dsfile --cascade=false
kubectl create -f dsfile
for pod in pods
kubectl delete pod
wait for delete
編集： @ bgrant0607は、
Seb-Solon
全てのコメント3件
15310は、サーバー側の更新オーケストレーションを含む、DaemonSetがベータ版からGAに移行するための要件をカバーしています。 私はむしろそれに力を入れたいのですが、それはトリッキーであり、1.3でそれに取り組む予定はありません。
クライアント側のソリューションに貢献したいのであれば、それは私たちが考えている長期的な方向性ではありませんが（＃12143）、新しいコマンドを導入するべきではありません。 代わりに、DaemonSet（および必要に応じてReplicaSetも）でkubectl rolling-update機能させる必要があります。
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/rollingupdate.go
rolling-updateはリソースタイプ（ replicationcontroller ）を指定しないため、デフォルトでrc想定する必要があります。 それ以外は、type / name構文を使用して、構文を他のコントローラータイプに自然に拡張できると思います。
例えば：
kubectl rolling-update daemonset/mydaemon --image=image:v2
ただし、コマンド自体を除いて、更新手順でコードを共有することは期待していません。
現在のrolling-updateコマンドは、新しいReplicationControllerを作成し、古いものを縮小しながら徐々に拡大します。 --image場合、名前を元のRCに戻すために、最後に「削除ダンス」を実行します。元のRCを削除し、同じ名前の別のRCを作成してから、新しいイメージをロールアウトするために使用される一時的なRC。
DaemonSetの場合、kubectlは逆のことを行います。つまり、元のDaemonSetを更新し、ポッドを1つずつ削除して、ポッドを置き換えます。 --imageが指定された場合、それは最後に実行されます。 新しいDaemonSet名が指定された場合（たとえば、 kubectl rolling-update daemonset/mydaemon-v1 -f mydaemon-v2.yaml ）、更新プロセスの最後に新しいDaemonSetが作成され、元の名前が削除されます。 DaemonSetがそれを適切に処理することを確認するか、新しいDaemonSetを作成する前に元のDaemonSetを削除する必要があります（＃7402の私の提案と同様）。
cc @mikedanese @davidopp @madhusudancs @janetkuo @kargakis @pwittrock @gmarek
bgrant0607
2016年04月29日
1.6には、DaemonSetのローリングアップグレードが含まれています。
kargakis
2017年03月20日
更新していただきありがとうございます！ 👍
Seb-Solon
2017年03月20日
関連する問題
montanaflynn
·
3コメント
pwittrock
·
3コメント
ddysher
·
3コメント
tbchj
·
3コメント
arun-gupta
·
3コメント
最も参考になるコメント
1.6には、DaemonSetのローリングアップグレードが含まれています。