Как настроить вход для развертывания сервисов на поддоменах без создания нового loadbalancer - PullRequest
Новая
       7

Как настроить вход для развертывания сервисов на поддоменах без создания нового loadbalancer

0 голосов
/ 11 марта 2020

Я новичок в Kubernetes, и у меня есть приложение, развернутое через GKE на mydomain.com, и теперь я хочу добавить еще один сервис, который должен быть доступен на api.mydomain.com без добавления нового дорогостоящего балансировщика нагрузки. Как должен выглядеть новый входной файл для api.mydomain? Я прочитал документацию, но не могу понять, как это сделать.

Это мой первый сервис, работающий на mydomain.com:

kind: Service
apiVersion: v1
metadata:
  name: app-service
spec:
  selector:
    app: app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "ip"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    acme.cert-manager.io/http01-edit-in-place: "true"
    kubernetes.io/tls-acme: "true"
spec:
  rules:
  - host: mydomain.com
    http:
      paths:
      - backend:
          serviceName: app-service
          servicePort: 80
  tls:
  - hosts:
    - mydomain.com
    secretName: my-certs

Я пытался использовать ту же конфигурацию для субдомена api.mydomain.com, но это не работает. 

kind: Service
apiVersion: v1
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "ip"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    acme.cert-manager.io/http01-edit-in-place: "true"
    kubernetes.io/tls-acme: "true"
spec:
  rules:
  - host: api.mydomain.com
    http:
      paths:
      - backend:
          serviceName: api-service
          servicePort: 80
  tls:
  - hosts:
    - api.mydomain.com
    secretName: my-certs-api

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

Ответы [ 3 ]

1 голос
/ 12 марта 2020

Попробуйте "nginx" ingress.class. Конфиг должен быть похож на следующий (я удалил часть tls это).

Nginx Входной контроллер довольно прост и функционален. 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: double-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
#    nginx.ingress.kubernetes.io/rewrite-target: /$2  ### you can use it to route different paths to different services under the same host
spec:
  rules:
  - host: mydomain.com
    http:
      paths:
      - path: /
#      - path: /doc/common(/|$)(.*)    ### if you are using rewrite
        backend:
          serviceName: app-service
          servicePort: 80

  - host: api.mydomain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: api-service
          servicePort: 80
  tls:
  - hosts:
    - api.mydomain.com
    secretName: my-certs-api

Надеюсь, это поможет!

1 голос
/ 11 марта 2020

Обычно вы используете Ingress-gce, отличный от Ingress-gce. ingress- nginx очень распространен и с ним легко начать работу, но есть много вариантов, поэтому я рекомендую вам изучить их и выбрать, какой из них лучше всего подходит для вашего варианта использования.

0 голосов
/ 18 марта 2020

Насколько я понимаю, вы пытаетесь создать один балансировщик нагрузки HTTP с одним публичным c IP-адресом для двух разных доменов.

Это возможно при использовании стандартного входного контроллера GKE GCE L7 хотя бы для протокола HTTP (см. Пример ниже).

Пожалуйста, также найдите страницу документации об использовании нескольких сертификатов SSL с входом GCE L7.

Пример:
(mydomain.com заменен на example.com, , потому что ... тело ответа не может содержать его.) 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: app-service
          servicePort: 80
  - host: api.example.com
    http:
      paths:
      - backend:
          serviceName: api-service
          servicePort: 80

Применение этого yaml к кластеру GKE приводит к созданию одного HTTP-балансировщика нагрузки со следующими правилами хоста и пути: 

http://example.com:80/* -> app-service:80 (if app-service health-check passed)
http://example.com:80/* -> default-backend:80 (return 404) (if app-service heath-check fails and default-backend health-check passed)
http://api.example.com:80/* -> api-service:80 (if app-service health-check passed)
http://api.example.com:80/* -> default-backend:80 (return 404) (if api-service heath-check fails and default-backend health-check passed)
http://lb.ip.address:80 -> default-backend:80 (return 404) (if  default-backend health-check passed)

HTTP LB returns 502 if all backends' health-checks are failed.
...