<p>As the GCE Disk does not support <code>ReadWriteMany</code> , I have no way to apply change to Deployment but being stucked at <strong>ContainerCreating</strong> with <code>FailedAttachVolume</code> .</p>

<p>So here's my setting:</p>

<p><strong>1. PVC</strong></p>

<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql
spec:
  storageClassName: "standard"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
</code></pre>

<p><strong>2. Service</strong></p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
  selector:
    app: mysql
</code></pre>

<p><strong>3. Deployment</strong></p>

<pre><code>apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql/mysql-server
        name: mysql
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /mysql-data
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
</code></pre>

<p>Which these are all fine for creating the PVC, svc and deployment. Pod and container started successfully and worked as expected.</p>

<hr>

<p><strong>However when I tried to apply change by:</strong>
 <code>kubectl apply -f mysql_deployment.yaml</code> </p>

<p><strong>Firstly</strong>, the pods were sutcked with the existing one did not terminate and the new one would be creating forever.</p>

<pre><code>NAME             READY     STATUS              RESTARTS   AGE
mysql-nowhash    1/1       Running             0          2d
mysql-newhash    0/2       ContainerCreating   0          15m
</code></pre>

<p>Secondly from the gCloud console, inside the pod that was trying to create, I got two crucial error logs:</p>

<p><strong>1 of 2 FailedAttachVolume</strong></p>

<pre><code>Multi-Attach error for volume "pvc-&lt;hash&gt;" Volume is already exclusively attached to one node and can't be attached to another  FailedAttachVolume
</code></pre>

<p><strong>2 of 2 FailedMount</strong></p>

<pre><code>Unable to mount volumes for pod "&lt;pod name and hash&gt;": timeout expired waiting for volumes to attach/mount for pod "default"/"&lt;pod name and hash&gt;". list of unattached/unmounted volumes=[mysql-persistent-storage] 
</code></pre>

<p>What I could immediately think of is the <code>ReadWriteOnce</code> capability of gCloud PV. Coz the kubernetes engine would create a new pod before terminating the existing one. So under ReadWriteOnce it can never create a new pod and claim the existing pvc...</p>

<p>Any idea or should I use some other way to perform deployment updates?
appreciate for any contribution and suggestion =)</p>

<p>remark: my current work-around is to create an interim NFS pod to make it like a ReadWriteMany pvc, this worked but sounds stupid... requiring an additional storage i/o overhead to facilitate deployment update ?.. =P</p>

Michael Linus
<p>The reason is that if you are applying UpdateStrategy: RollingUpdate (as it is default) k8s waits for the new Container to become ready before shutting down the old one. You can change this behaviour by applying UpdateStrategy: Recreate </p>

<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy</a></p>
