<p><a href="https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes" rel="nofollow noreferrer">https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes</a></p>

<blockquote>
  <p>MongoDB database nodes are stateful. In the event that a container
  fails, and is rescheduled, it's undesirable for the data to be lost
  (it could be recovered from other nodes in the replica set, but that
  takes time). To solve this, features such as the Volume abstraction in
  Kubernetes can be used to map what would otherwise be an ephemeral
  MongoDB data directory in the container to a persistent location where
  the data survives container failure and rescheduling.</p>
</blockquote>

<p>Like @Tensibai indicated the issue is related to the replication. According to <a href="http://blog.kubernetes.io/2017/01/running-mongodb-on-kubernetes-with-statefulsets.html" rel="nofollow noreferrer">this blog</a> it could be solved as follows.</p>

<blockquote>
<pre><code> apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: mongo
spec:
  serviceName: "mongo"
  replicas: 3
  template:
    metadata:
      labels:
        role: mongo
        environment: test
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: mongo
          image: mongo
          command:
            - mongod
            - "--replSet"
            - rs0
            - "--smallfiles"
            - "--noprealloc"
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: mongo-persistent-storage
              mountPath: /data/db
        - name: mongo-sidecar
          image: cvallance/mongo-k8s-sidecar
          env:
            - name: MONGO_SIDECAR_POD_LABELS
              value: "role=mongo,environment=test"
  volumeClaimTemplates:
  - metadata:
      name: mongo-persistent-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: "fast"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Gi
</code></pre>
</blockquote>

CC BY-SA 3.0
2017-12-03T14:40:09.080Z
2017-12-03T14:40:09.080Z
030
<h2>I made these settings :</h2>

<pre><code>    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      labels:
        name: mongo-claim0
      name: mongo-claim0
      namespace: my-app
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi
    status: {}
</code></pre>

<hr>

<pre><code>apiVersion: v1
kind: ReplicationController
metadata:
  labels:
    name: mongo
  name: mongo-controller
  namespace: my-app
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: mongo
    spec:
      containers:
      - image: mongo
        name: mongo
        ports:
        - name: mongo
          containerPort: 27017
        volumeMounts:
        - mountPath: /data/db
          name: mongo-claim0
      restartPolicy: Always
      volumes:
      - name: mongo-claim0
        persistentVolumeClaim:
          claimName: mongo-claim0
</code></pre>

<hr>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: mongo
  namespace: my-app
  labels:
    name: mongo
spec:
  ports:
  - port: 27017
    targetPort: 27017
  selector:
    name: mongo
</code></pre>

<p>When I try to scale this pod, Minikube UI show :</p>

<blockquote>
  <p>mongo-controller-xr21r -> Waiting: CrashLoopBackOff Back-off
  restarting failed container Error syncing pod</p>
</blockquote>

<p>And I got an error on the new pod :</p>

<blockquote>
  <p>exception in initAndListen: 98 Unable to lock file:
  /data/db/mongod.lock Resource temporarily unavailable</p>
</blockquote>

<p>Could you help me to be able to scale a pod with a persistent storage ?</p>

CC BY-SA 3.0
2017-10-25T12:23:22.403Z
The problem is not scaling a pod, the problem is how mongodb works for replication, and it doesn't work with shared storage... (in brief this is unrelated to kubernetes, this is an architecture problem specific to mongodb)
Tensibai
CC BY-SA 3.0
2017-11-26T12:46:52.767Z
@Tensibai Please post this comment as an answer
030
<kubernetes><minikube>
How to replicate a mongodb pod with its persistent storage
Yolan Mazars
# How to replicate a mongodb pod with its persistent storage

(Asked by: username_0 on 2017-10-24)

I made these settings :
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      labels:
        name: mongo-claim0
      name: mongo-claim0
      namespace: my-app
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi
    status: {}


apiVersion: v1
kind: ReplicationController
metadata:
  labels:
    name: mongo
  name: mongo-controller
  namespace: my-app
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: mongo
    spec:
      containers:
      - image: mongo
        name: mongo
        ports:
        - name: mongo
          containerPort: 27017
        volumeMounts:
        - mountPath: /data/db
          name: mongo-claim0
      restartPolicy: Always
      volumes:
      - name: mongo-claim0
        persistentVolumeClaim:
          claimName: mongo-claim0


apiVersion: v1
kind: Service
metadata:
  name: mongo
  namespace: my-app
  labels:
    name: mongo
spec:
  ports:
  - port: 27017
    targetPort: 27017
  selector:
    name: mongo

When I try to scale this pod, Minikube UI show :

mongo-controller-xr21r -> Waiting: CrashLoopBackOff Back-off
  restarting failed container Error syncing pod

And I got an error on the new pod :

exception in initAndListen: 98 Unable to lock file:
  /data/db/mongod.lock Resource temporarily unavailable

Could you help me to be able to scale a pod with a persistent storage ?

**Tags:** kubernetes, minikube

> **Comments:**
> **username_1**: The problem is not scaling a pod, the problem is how mongodb works for replication, and it doesn't work with shared storage... (in brief this is unrelated to kubernetes, this is an architecture problem specific to mongodb)  
> **username_2**: @username_1 Please post this comment as an answer  

---

## 1 answers

### Answer by username_2 on 2017-12-03. Score: 2

https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes

MongoDB database nodes are stateful. In the event that a container
  fails, and is rescheduled, it's undesirable for the data to be lost
  (it could be recovered from other nodes in the replica set, but that
  takes time). To solve this, features such as the Volume abstraction in
  Kubernetes can be used to map what would otherwise be an ephemeral
  MongoDB data directory in the container to a persistent location where
  the data survives container failure and rescheduling.

Like @username_1 indicated the issue is related to the replication. According to this blog it could be solved as follows.

 apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: mongo
spec:
  serviceName: "mongo"
  replicas: 3
  template:
    metadata:
      labels:
        role: mongo
        environment: test
    spec:
      terminationGracePeriodSeconds: 10
      containers:
        - name: mongo
          image: mongo
          command:
            - mongod
            - "--replSet"
            - rs0
            - "--smallfiles"
            - "--noprealloc"
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: mongo-persistent-storage
              mountPath: /data/db
        - name: mongo-sidecar
          image: cvallance/mongo-k8s-sidecar
          env:
            - name: MONGO_SIDECAR_POD_LABELS
              value: "role=mongo,environment=test"
  volumeClaimTemplates:
  - metadata:
      name: mongo-persistent-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: "fast"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Gi


---

