При развертывании Kubenetes Mongo данные теряются после перезапуска модуля

Недавно управляемый модуль в моем развертывании mongo на GKE был автоматически удален, и вместо него был создан новый. В результате все мои данные БД были потеряны.

Я указал PV для развертывания, и PVC тоже был привязан, и я использовал стандартный класс хранения (постоянный диск Google). Заявка на постоянный объем также не была удалена.

Вот изображение результата kubectl get pv: ПВХ

Мое развертывание mongo вместе с утверждением постоянного тома и развертыванием службы было создано с помощью инструмента kompose kubernets из файла docker-compose.yml для prisma 1 + mongodb развертывание.

Вот мои ямлы:

mongo-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose -f docker-compose.yml convert
    kompose.version: 1.21.0 (992df58d8)
  creationTimestamp: null
  labels:
    io.kompose.service: mongo
  name: mongo
  namespace: dbmode
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: mongo
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        kompose.cmd: kompose -f docker-compose.yml convert
        kompose.version: 1.21.0 (992df58d8)
      creationTimestamp: null
      labels:
        io.kompose.service: mongo
    spec:
      containers:
      - env:
        - name: MONGO_INITDB_ROOT_PASSWORD
          value: prisma
        - name: MONGO_INITDB_ROOT_USERNAME
          value: prisma
        image: mongo:3.6
        imagePullPolicy: ""
        name: mongo
        ports:
        - containerPort: 27017
        resources: {}
        volumeMounts:
        - mountPath: /var/lib/mongo
          name: mongo
      restartPolicy: Always
      serviceAccountName: ""
      volumes:
      - name: mongo
        persistentVolumeClaim:
          claimName: mongo
status: {}

mongo-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: mongo
  name: mongo
  namespace: dbmode
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
status: {}

mongo-service.yaml

apiVersion: v1
kind: Service
metadata:
  annotations:
    kompose.cmd: kompose -f docker-compose.yml convert
    kompose.version: 1.21.0 (992df58d8)
  creationTimestamp: null
  labels:
    io.kompose.service: mongo
  name: mongo
  namespace: dbmode
spec:
  ports:
  - name: "27017"
    port: 27017
    targetPort: 27017
  selector:
    io.kompose.service: mongo
status:
  loadBalancer: {}

Я попытался проверить содержимое, смонтированное в /var/lib/mongo, и все, что у меня было, это пустая lost+found/ папка, и я попытался выполнить поиск на постоянных дисках Google, но в корневом каталоге ничего не было, и я не знал, где еще искать.

Я предполагаю, что по какой-то причине развертывание mongo не извлекает из постоянного тома старые данные при запуске нового модуля, что вызывает крайнее недоумение.

У меня также есть другой проект Kubernetes, в котором произошло то же самое, за исключением того, что старый модуль все еще отображался, но имел статус evicted.


kubernetes kubernetes-pod google-kubernetes-engine persistent-volumes mongodb
person Jonathan Lynn    schedule 06.11.2020    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я попытался проверить содержимое, смонтированное в / var / lib / mongo, и все, что у меня было, было пустой папкой lost + found /,

Хорошо, но вы проверили, действительно ли там сохранялись данные до Pod перезапуска и потери данных? Я предполагаю, что он никогда не сохранял никаких данных в этом каталоге.

Я проверил изображение, которое вы использовали, запустив простой Pod:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-pod
    image: mongo:3.6

Когда вы подключаетесь к нему, запустив:

kubectl exec -ti my-pod -- /bin/bash

и проверьте файл конфигурации mongo по умолчанию:

root@my-pod:/var/lib# cat /etc/mongod.conf.orig
# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb # ????
  journal:
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

вы можете видеть среди прочего, что dbPath фактически установлен на /var/lib/mongodb, а НЕ на /var/lib/mongo.

Так что есть вероятность, что ваш mongo на самом деле сохранял какие-либо данные не в ваш PV, то есть в /var/lib/mongo каталог, где он был смонтирован, а в /var/lib/mongodb, как указано в его файле конфигурации.

Вы сможете легко проверить это, kubectl exec в свой запущенный модуль mongo:

kubectl exec -ti <mongo-pod-name> -- /bin/bash

и проверьте, где сохранены данные.

Если вы никоим образом не перезаписывали исходный файл конфигурации (например, предоставив ConfigMap), mongo должен сохранить свои данные в /var/lib/mongodb, и этот каталог, не являясь точкой монтирования для вашего тома, является частью Pod файловой системы и ее эфемерной .

Обновлять:

Вышеупомянутый /etc/mongod.conf.orig является всего лишь шаблоном, поэтому он не отражает фактическую примененную конфигурацию.

Если вы запустите:

kubectl logs your-mongo-pod

он покажет, где находится каталог данных:

$ kubectl logs my-pod 
2020-12-16T22:20:47.472+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=my-pod
2020-12-16T22:20:47.473+0000 I CONTROL  [initandlisten] db version v3.6.21
...

Как видим, данные сохраняются в /data/db:

dbpath=/data/db
person mario    schedule 07.11.2020
comment
Спасибо! Я подозревал, что данные на самом деле не сохраняются в PV. Однако я не нашел / var / lib / mongodb в моем работающем модуле, и даже после того, как я изменил yaml развертывания mongo, чтобы он указывал на / var / lib / mongodb для mountPath, каталог все еще содержал только папку lost + found / . Я также проверил место назначения журналов для mongodb, и там ничего не было - person Jonathan Lynn; 09.11.2020
comment
Я совершенно забыл, что мои данные mongodb сохранялись в папке / data / db. Спасибо за ваш ответ. Наконец-то я убедился, что мой постоянный том необходимо смонтировать в этом каталоге. Работает сейчас! - person Jonathan Lynn; 09.11.2020