Persistent Volume claims attached to deployment throws an error when deployment image is updated

2
votes

i have a deployment configuration that uses a persistent volume claim using a google compute engine disk.

I noticed that when i deploy which updates the image the cluster attempts to pull in the latest image but when doing that it gets stuck with container creating status with this error:

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'

I am using 1.8 kubernetes and currently what i did was to change my deployment strategy to recreate this works but takes a bit of time to update the pods .I would really love this to work using rolling update strategy .

1
kubernetesgoogle-kubernetes-engine
What error events do you see with kubectl describe pod tita-api-7569bd99d7-z44dg? - Robert
Updated the question with the exact response , pls check above - I.Tyger

1 Answers

0
votes

According to Saad-Ali comment on Jul 14th in this Kubernetes issue you must use: MaxSurge=0 and MaxUnavailable=1

“When doing rolling updates either:

i) Use the "Recreate" strategy, which ensures that old pods are killed before new pods are created (there was a bug #27362 where this doesn't work correctly in some cases that apperently was fixed a long time ago)

ii) Use the "RollingUpdate" strategy with MaxSurge=0 and MaxUnavailable=1.

If a strategy is not specified for a deployment, the default is RollingUpdate. Rolling update strategy has two parameters maxUnavailable and maxSurge; when not specified they default to 1 and 1 respectively. This means that during a rolling update it requires at least one pod from the old deployment to remain and permits an extra new pod (beyond the requested number of replicas) to be created. When this happens, if the new pod lands on a different node, since the old pod has the disk attached as read-write the new pod will fail to start.”