Как включить поддомен с помощью GKE - PullRequest
Новая
       12

Как включить поддомен с помощью GKE

0 голосов
/ 07 июня 2019

У меня другое развертывание Kubernetes в GKE, и я хотел бы получить к ним доступ из разных внешних поддоменов.

Я попытался создать 2 развертывания с поддоменом «sub1» и «sub2» и именем хоста «app», другое развертывание с именем хоста «app» и службой, предоставляющей его для IP-адреса XXX.XXX.XXX.XXX, настроенного в DNS. из app.mydomain.com

Я хотел бы получить доступ к 2 дочернему развертыванию с sub1.app.mydomain.com и sub2.app.mydomain.com

Это должно быть автоматическим, добавляя новое развертывание, я не могу изменять каждый раз записи DNS. Может быть, я неправильно подхожу к проблеме, я новичок в GKE, есть предложения? 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-host
spec:
  replicas: 1
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: my-host
        type: proxy
    spec:
      hostname: app
      containers:
        - image: nginx:alpine
          name: nginx
          ports:
            - name: nginx
              containerPort: 80
              hostPort: 80
      restartPolicy: Always
status: {}
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-subdomain-1
spec:
  replicas: 1
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: my-subdomain-1
        type: app
    spec:
      hostname: app
      subdomain: sub1
      containers:
        - image: nginx:alpine
          name: nginx
          ports:
            - name: nginx
              containerPort: 80
              hostPort: 80
      restartPolicy: Always
status: {}
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-subdomain-2
spec:
  replicas: 1
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: my-subdomain-2
        type: app
    spec:
      hostname: app
      subdomain: sub2
      containers:
        - image: nginx:alpine
          name: nginx
          ports:
            - name: nginx
              containerPort: 80
              hostPort: 80
      restartPolicy: Always
status: {}
---
apiVersion: v1
kind: Service
metadata:
  name: my-expose-dns
spec:
  ports:
    - port: 80
  selector:
    name: my-host
  type: LoadBalancer

Ответы [ 3 ]

1 голос
/ 07 июня 2019

решено!

Это правильная конфигурация nginx: 

server {
  listen       80;
  server_name ~^(?<subdomain>.*?)\.;
  resolver kube-dns.kube-system.svc.cluster.local valid=5s;

  location / {
      proxy_pass         http://$subdomain.my-internal-host.default.svc.cluster.local;
      root   /usr/share/nginx/html;
      index  index.html index.htm;
  }

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
      root   /usr/share/nginx/html;
  }
}
0 голосов
/ 07 июня 2019

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

Я почти решил использовать прокси nginx следующим образом: 

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    name: my-subdomain-1
    spec:
    replicas: 1
    strategy: {}
    template:
        metadata:
        creationTimestamp: null
        labels:
            name: my-subdomain-1
            type: app
        spec:
        hostname: sub1
        subdomain: my-internal-host
        containers:
            - image: nginx:alpine
            name: nginx
            ports:
                - name: nginx
                containerPort: 80
                hostPort: 80
        restartPolicy: Always
    status: {}
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    name: my-subdomain-2
    spec:
    replicas: 1
    strategy: {}
    template:
        metadata:
        creationTimestamp: null
        labels:
            name: my-subdomain-2
            type: app
        spec:
        hostname: sub2
        subdomain: my-internal-host
        containers:
            - image: nginx:alpine
            name: nginx
            ports:
                - name: nginx
                containerPort: 80
                hostPort: 80
        restartPolicy: Always
    status: {}
    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: nginx-config-dns-file
    data:
    nginx.conf: |
        server {
        listen       80;
        server_name ~^(?.*?)\.;

        location / {
            proxy_pass         http://$subdomain.my-internal-host;
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }
        }
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
    name: my-proxy
    spec:
    replicas: 1
    strategy: {}
    template:
        metadata:
        creationTimestamp: null
        labels:
            name: my-proxy
            type: app
        spec:
        subdomain: my-internal-host
        containers:
            - image: nginx:alpine
            name: nginx
            volumeMounts:
                - name: nginx-config-dns-file
                mountPath: /etc/nginx/conf.d/default.conf.test
                subPath: nginx.conf
            ports:
                - name: nginx
                containerPort: 80
                hostPort: 80
        volumes:
            - name: nginx-config-dns-file
            configMap:
                name: nginx-config-dns-file
        restartPolicy: Always
    status: {}
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: my-internal-host
    spec:
    selector:
        type: app
    clusterIP: None
    ports:
        - name: sk-port
        port: 80
        targetPort: 80
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: sk-expose-dns
    spec:
    ports:
        - port: 80
    selector:
        name: my-proxy
    type: LoadBalancer

Я понял, что мне нужна служба 'my-internal-host', чтобы все развертывания могли видеть друг друга внутренне. Теперь проблема заключается только в proxy_pass в nginx, если я изменю его на 'proxy_pass http://sub1.my -internal-host ;' это работает, но не с регулярным выражением var.

Проблема связана с распознавателем nginx.

0 голосов
/ 07 июня 2019

Вы хотите Вход .Доступно несколько вариантов (Istio, nginx, traefik и т. Д.).Мне нравится использовать nginx, и его очень легко устанавливать и использовать.Шаги установки можно найти по адресу kubernetes.github.io .

После установки Ingress Controller вы хотите убедиться, что вы предоставили его службе с типом = LoadBalancer.Затем, если вы используете Google Cloud DNS, установите для своего домена запись с подстановочными знаками с записью A, указывающей на внешний IP-адрес службы Ingress Controller.В вашем случае это будет * .app.mydomain.com.

Так что теперь весь ваш трафик на app.mydomain.com направляется на этот балансировщик нагрузки и обрабатывается вашим Ingress Controller, так что теперь вынеобходимо добавить объекты службы и входные данные для любой службы, которую вы хотите. 

apiVersion: v1
kind: Service
metadata:
  name: my-service1
spec:
  selector:
    app: my-app-1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: my-service2
spec:
  selector:
    app: my-app2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: sub1.app.mydomain.com
    http:
      paths:
      - backend:
          serviceName: my-service1
          servicePort: 80
  - host: sub2.app.mydomain.com
    http:
      paths:
      - backend:
          serviceName: my-service2
          servicePort: 80

Показанная маршрутизация основана на хосте, но вы с такой же легкостью могли бы обрабатывать эти службы как пути, так что весь трафик на app.mydomain.com / service1 перейдет в одно из ваших развертываний.

...