Nginx значения восходящего сервера при обслуживании API с использованием docker -compose и kubernetes

Question

Я пытаюсь использовать docker -compose и kubernetes в качестве двух разных решений для настройки Django API, обслуживаемого Gunicorn (в качестве веб-сервера) и Nginx (в качестве обратного прокси-сервера). Вот ключевые файлы:

default.tmpl (nginx) - конвертируется в default.conf при заполнении переменной окружения:

upstream api {
    server ${UPSTREAM_SERVER};
}

server {
    listen 80;

    location / {
        proxy_pass http://api;
    }

    location /staticfiles {
        alias /app/static/;
    }
}

docker -compose .yaml:

version: '3'
services:
  api-gunicorn:
    build: ./api
    command: gunicorn --bind=0.0.0.0:8000 api.wsgi:application
    volumes:
      - ./api:/app

  api-proxy:
    build: ./api-proxy
    command: /bin/bash -c "envsubst < /etc/nginx/conf.d/default.tmpl > /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"
    environment:
      - UPSTREAM_SERVER=api-gunicorn:8000
    ports:
      - 80:80
    volumes:
      - ./api/static:/app/static
    depends_on:
      - api-gunicorn

api-deploy.yaml (kubernetes):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-myapp-api-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: myapp-api-proxy
  template:
    metadata:
      labels:
        app.kubernetes.io/name: myapp-api-proxy
    spec:
      containers:
        - name: myapp-api-gunicorn
          image: "helm-django_api-gunicorn:latest"
          imagePullPolicy: Never
          command:
            - "/bin/bash"
          args:
            - "-c"
            - "gunicorn --bind=0.0.0.0:8000 api.wsgi:application"
        - name: myapp-api-proxy
          image: "helm-django_api-proxy:latest"
          imagePullPolicy: Never
          command:
            - "/bin/bash"
          args:
            - "-c"
            - "envsubst < /etc/nginx/conf.d/default.tmpl > /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"
          env:
            - name: UPSTREAM_SERVER
              value: 127.0.0.1:8000
          volumeMounts:
            - mountPath: /app/static
              name: api-static-assets-on-host-mount
      volumes:
        - name: api-static-assets-on-host-mount
          hostPath:
            path: /Users/jonathan.metz/repos/personal/code-demos/kubernetes-demo/helm-django/api/static

Мой вопрос касается переменной среды UPSTREAM_SERVER.

Для docker-compose.yaml у меня сработали следующие значения:

• Установка в качестве имени службы gunicorn и порта, на котором она работает (в данном случае api-gunicorn:8000). Это лучший способ сделать это (и как я это сделал в файле docker -compose выше), потому что мне не нужно выставлять порт 8000 на хост-машине.
• Установка MY_IP_ADDRESS:8000 как описана в этом посте SO . Этот метод требует, чтобы я выставил порт 8000, что не идеально.

Для api-deployment.yaml у меня работало только следующее значение:

• Настройка это к localhost:8000. Внутри модуля все контейнеры могут связываться, используя localhost .

Существуют ли другие значения для UPSTREAM_SERVER, которые работают здесь, особенно в файле kubernetes? Я чувствую, что должен указывать на имя контейнера, и это должно сработать.

Answer 1

Вы можете создать службу для целевого контейнера myapp-api-gunicorn , но это откроет его вне pod:

apiVersion: v1
kind: Service
metadata:
  name: api-gunicorn-service
spec:
  selector:
    app.kubernetes.io/name: myapp-api-proxy
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 8000

You также может использовать поля имени хоста и субдомена внутри pod для использования полного доменного имени.

В настоящее время при создании модуля его именем хоста является значение metadata.name модуля.

Модуль Pod c имеет необязательное поле hostname, которое можно использовать для указания имени хоста модуля. Если указан, он имеет приоритет над именем модуля, чтобы быть именем хоста модуля. Например, если для модуля Pod с hostname установлено значение «my-host», для имени модуля Pod будет указано «my-host».

Модуль Pod c также имеет необязательный параметр subdomain поле, которое можно использовать для указания своего субдомена. Например, модуль с hostname, установленным на «foo» и subdomain, установленным на «bar», в пространстве имен «my-namespace», будет иметь полное доменное имя (FQDN) «foo.bar.my-namespace.svc.cluster-domain.example ”.

Также вот хорошая статья от Mirantis , в которой говорится о разоблачении нескольких контейнеров в капсуле