デプロイメントイメージが更新されると、デプロイメントに添付された永続的なボリュームクレームがエラーをスローする

Question

Googleコンピューティングエンジンディスクを使用した永続的なボリュームクレームを使用するデプロイメント構成があります。

私は私がイメージを更新する展開するときにクラスタが最新の画像で引っ張るしようとしたが、それはコンテナがこのエラーで状態を作成して立ち往生することをやったときに気づい：

Error from server (BadRequest): container "tita-api" in pod "tita-api-7569bd99d7-z44dg" is waiting to start: ContainerCreating. Checking further i saw the disk resource is used by another node . AttachVolume.Attach failed for volume "app-pv" : googleapi: Error 400: The disk resource 'projects/tita-canary/zones/us-central1-a/disks/app-disk' is already being used by 'projects/tita-canary/zones/us-central1-a/instances/gke-tita-staging-default-pool-2cae0006-sxgk'

私は1.8 kubernetesを使用しています現時点では、この作業を再現するための展開戦略を変更することでしたが、ポッドを更新するのに少し時間がかかりました。ローリングアップデート戦略を使用して作業することが本当に大好きです。

Answer 1

このKubernetes issueで7月14日にサアド・アリのコメントによると、あなたが使用する必要があります：MaxSurge=0とMaxUnavailable=1

「ローリングアップデートを行うときに、次のいずれか

i）が使用する 『ことを保証し再作成』戦略を、新しいポッドが作成される前に、古いポッドが殺されている（これはapperently長い時間前に固定されたいくつかのケースでは正しく動作しないバグ＃27362があった）

II）MaxSurge=0で「RollingUpdate」戦略を使用し、 MaxUnavailable=1。

配備に戦略が指定されていない場合、デフォルトは[RollingUpdate]です。ローリング更新戦略には、maxUnavailableとmaxSurgeという2つのパラメータがあります。指定されていない場合は、それぞれデフォルトで1と1になります。つまり、ローリング更新中には、古いデプロイメントのポッドが少なくとも1つ残っている必要があり、追加の新しいポッド（要求された数のレプリカを超える）を作成できるようになります。この場合、新しいポッドが別のノードにある場合、古いポッドにはディスクが読み書き可能な状態で接続されているため、新しいポッドは起動しません。 "