Развертывание приложения Django с PostgreSQL в кластер Google Cloud Kubernetes

Question

У меня возникают проблемы при попытке развернуть мою базу данных Django Application и PostgreSQL в кластере Google Cloud Kubernetes, который я уже настроил.

Я успешно создал контейнеры Docker для моей базы данных Django Application и PostgreSQL. Вот как выглядит мой файл docker-compose.yml:

version: '3'

services:
  db:
    image: postgres
    environment:
      - POSTGRES_USER=stefan_radonjic
      - POSTGRES_PASSWORD=cepajecar995
      - POSTGRES_DB=agent_technologies_db
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000 --settings=agents.config.docker-settings
    volumes: 
      - .:/agent-technologies
    ports: 
      - "8000:8000"
    links:
      - db
    depends_on:
      - db

Я уже собрал образы и попробовал команду sudo docker-compose up, и приложение работает отлично.

После успешной стыковки приложений Django и PostgreSQL я попытался настроить файлы Deployment / Service YML, необходимые для Kubernetes, но у меня возникли проблемы с этим. Например:

deploy-definition.yml - Файл для развертывания приложения Django:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: agent-technologies-deployment
      labels:
        app: agent-technologies
        tier: backend
    spec:
      template:
        metadata:
          name: agent-technologies-pod
          labels:
            app: agent-technologies
            tier: backend
        spec:
          containers:
            - name: 
              image:
              ports:
                - containerPort: 8000
        replicas:
        selector:
          matchLabels:
            tier: backend

Внутри списка контейнеров словарей я знаю, что мое имя контейнера должно быть web, но я не уверен, где находится изображение этого контейнера, поэтому я не знаю, что я должен указать в качестве изображения контейнера.

Другая проблема заключается в postgres / deploy-definition.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres-container
  template:
    metadata:
      labels:
        app: postgres-container
        tier: backend
    spec:
      containers:
        - name: postgres-container
          image: postgres:9.6.6
          env:
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: postgres-credentials
                  key: user

            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-credentials
                  key: password

            - name: POSTGRES_DB
              value: agent_technologies_db
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: postgres-volume-mount
              mountPath: /var/lib/postgresql/data

      volumes:
        - name: postgres-volume-mount
          persistentVolumeClaim:
            claimName: postgres-pvc

Я не понимаю, для чего volumeMounts и volumes, и если я даже правильно их указал.

Вот мой файл secret-definition.yml:

apiVersion: v1
kind: Secret
metadata:
  name: postgres-credentials
type: Opaque
data:
  user: stefan_radonjic
  passowrd: cepajecar995

Мой файл postgres / service-definition.yml:

apiVersion: v1
kind: Service
metadata:
  name: postgres-service
spec:
  selector:
    app: postgres-container
  ports:
    - protocol: TCP
      port: 5432
      targetPort: 5432

Мой файл postgres / volume-definition.yml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
  labels:
    type: local
spec:
  capacity:
    storage: 2Gi
  storageClassName: standard
  accessModes:
    - ReadWriteMany
  hostPath:
    path: /data/postgres-pv

И мой файл postgres / volume-претензия-definitono.yml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
  labels:
    type: local
spec:
  capacity:
    storage: 2Gi
  storageClassName: standard
  accessModes:
    - ReadWriteMany
  hostPath:
    path: /data/postgres-pv

И последнее, но не менее важное: мой файл service-definition.yml - для приложения Django

apiVersion: v1
kind: Service
metadata:
  name: agent-technologies-service
spec:
  selector:
    app: agent-technologies
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 8000
  type: NodePort

Помимо вопросов, которые я уже задавал выше, я также хочу спросить, правильно ли я делаю? Если нет, что я могу сделать, чтобы это исправить.

Answer 1

Внутри списка контейнеров словарей я знаю, что мое имя контейнера должно быть web, но я не уверен, где находится изображение этого контейнера, поэтому я не знаю, что я должен указать в качестве изображения контейнера.

• Имя контейнера локально для модуля (вы можете иметь несколько контейнеров, совместно использующих один модуль). Имя контейнера (в вашем случае web) для файлов, указанных при развертывании:

  # setting name of first container within pod to web
  spec:
    containers:
      - name: web
  

• Изображение для контейнера должно быть в некотором доступном реестре контейнера докера. Существует несколько вариантов размещения собственного реестра Docker для использования общедоступных. В любом случае вы должны быть в состоянии выдвинуть на этапе сборки этот реестр Docker-контейнеров (будь то Amazon ECR, Docker, Gitlab, self-hosted ...) и извлечь из этого реестра изнутри kubernetes (настройки безопасности, извлекать секреты). так далее...). В вашем файле docker-compose вы используете два контейнера. Для БД вы используете общедоступный образ postgres, а для веб-сайтов вы используете команду сборки, и образ хранится в локальном реестре докеров только на этом хосте (вы должны отправить его в общедоступный репозиторий, чтобы k8s мог извлекать его из него во время развертывания).

Я не понимаю, для чего используются VolumeMounts и volume, и если я даже правильно их указал.

• Короче говоря, тома предназначены для присоединения томов к контейнерам. В зависимости от вашего варианта использования и выбранной архитектуры существует несколько подходов к объемам, но в целом они сводятся к эфемерным, постоянным и постоянным. Ephemeral будет утерян при завершении или перезапуске контейнера, константы (например, из configMaps) используются для передачи файлов конфигурации в контейнеры, а постоянные наиболее интересны для приложений с состоянием (базы данных среди прочего). Тома можно указывать несколькими способами, у каждого тома должно быть имя (на которое ссылается volumeMount) и либо прямая спецификация тома, либо спецификация заявки на том (последняя рекомендуется для постоянного тома, поскольку вы можете воспользоваться преимуществами автоматической подготовки таким способом).
• VolumeMounts предназначены для определения места монтирования предварительно заданного тома в файловой системе контейнера. Они ссылаются на том для монтирования по имени, предоставляют точку монтирования в файловой системе контейнера с помощью mountPath и в некоторых случаях могут иметь подпути к конкретным файлам.
• В вашем примере вы привязали полученную объемную заявку к объему данных к пути данных postgres (/ var / lib / postgresql / data). Хотя вы используете класс хранения, который вы не указали, интересным моментом является то, что ваш постоянный том определяется как локальный путь на хосте. Это означает, что на каждом узле, у которого запущен этот модуль базы данных, вы в конечном итоге будете указывать / var / lib / postgresql / data контейнера базы данных этого модуля на / data / postgres-pv на этом конкретном узле. Это открывает вам следующую проблему: скажем, у вас есть 3 узла (A, B и C), и ваш модуль базы данных запущен на A, использует папку A / data / postgres-pv в качестве собственной / var / lib / postrgresql / data. И затем вы перезапускаете его, он завершается и переносится на узел B. Внезапно он использует локальную папку B / data / postgres-pv (пустую), и в результате вы получаете пустую базу данных. Если вы используете локальную файловую систему хоста для постоянства, вам нужно связать такие модули с узлами (или, что еще лучше, с привязкой). Из соображений производительности рекомендуется запускать тома базы данных локальной файловой системы, но модульные модули теряют способность легко перепланироваться. Другой подход состоит в том, чтобы иметь некоторый действительно постоянный том, который можно монтировать независимо от узла (например, Amazon EBS), и для него требуется другой PVC (или поставщик).

Помимо вопросов, которые я уже задавал выше, я также хочу спросить, правильно ли я делаю? Если нет, что я могу сделать, чтобы это исправить.

• Как указано выше, определите класс хранения и либо заблокируйте модуль db pod для конкретного узла, либо примените какое-либо динамическое предоставление, чтобы том следовал за расположением модуля на узлах.
• Oppiniated preference: не помещайте все в пространство имен по умолчанию, используйте отдельное пространство имен для обработки манифестов k8s, позже будет намного сложнее перемещать все и сложнее случайно удалить неправильную вещь ...
• Также личное предпочтение: база данных является приложением с сохранением состояния, и поэтому рекомендуется использовать набор состояний вместо развертывания.
• Существуют инструменты, которые помогут вам, когда вы начинаете создавать файлы docker-compose и хотите конвертировать в манифесты kubernetes, которые стоит проверить.
• Документация по kubernetes немного устарела, но довольно хороша, и вы можете прочитать там о томах и томах. Также есть активный слабый канал.
• Да, и издевайтесь над пользователем / паролем при размещении здесь файлов, теперь мы знаем о cepa ...
• Наконец, вы делаете большую работу!