Связь между пространствами имен в GKE-входе - PullRequest
0 голосов
/ 07 апреля 2020

У нас есть два разных приложения, развернутых в двух разных пространствах имен в GKE, я пытаюсь представить эти приложения с помощью GKE Ingress, который находится в пространстве имен по умолчанию. У меня есть сертификаты SSL для этих приложений.

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

Обращаясь к проблеме github, нет # 17088 Я обнаружил, что в этом случае можно использовать вход Nginx, но мой вариант использования ограничивает использование Nginx или любого стороннего инструмента, следовательно, вы можете помочь мне найти решение или любую работу - для этого используется только вход GKE.


Я пробовал описанный выше тест-кейс, используя входной контроллер Nginx и Istio обслуживает меня sh. Хорошо работает с Nginx.

Но в случае Istio я могу поразить только одно приложение и получить ошибку 404 во втором приложении. Я имею в виду эту документацию для конфигурации нескольких хостов tls. Я создал два секрета: один - istio-ingressgateway-certs в обычном каталоге ingressgateway-certs, а другой - istio-ingressgateway-tmcoaching-certs в пользовательском каталоге с именем ingressgateway-tmcoaching-certs, а также обновил развертывание istio-ingressgateway, применив json файл, как указано в документации. Конфигурационные файлы:

Шлюз и Виртуальные службы приложений.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tm-coaching-vs
  namespace: tm-coaching
spec:
  hosts:
  - q-tm-coaching.q-appliedai.com
  gateways:
  - cross-namespace-gateway
  http:
  - match:
    - uri:
       exact: /
    route:
    - destination:
        host: demo-tm-coaching.tm-coaching.svc.cluster.local
        port:
          number: 81

---

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: case-doc-vs
  namespace: case-doc
spec:
  hosts:
  - case-doc.q-appliedai.com
  gateways:
  - cross-namespace-gateway
  http:
  - match:
    - uri:
        exact: /
    route:
    - destination:
        host: demo-case-doc.case-doc.svc.cluster.local
        port:
          number: 80

---

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cross-namespace-gateway
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: demo-case-doc
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - case-doc.q-appliedai.com
  - port:
      number: 443
      name: demo-tm-coaching
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-tmcoaching-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-tmcoaching-certs/tls.key
    hosts:
    - q-tm-coaching.q-appliedai.com

Коляска внедряется внутри pods

ankita_shinde@cloudshell:~/istio-tls-cross-namespace/istio-cross-namespace-codebase/istio-config (qp-ihg-rpa-2020-03)$ kubectl get pods -n case-doc -o=custom-columns=NameSpace:.metadata.namespace,NAME:.metadata.name,CONTAINERS:.spec.containers[*].name
NameSpace   NAME                             CONTAINERS
case-doc    demo-case-doc-55db5ddcf4-ppnrq   demo-case-doc,istio-proxy
ankita_shinde@cloudshell:~/istio-tls-cross-namespace/istio-cross-namespace-codebase/istio-config (qp-ihg-rpa-2020-03)$ kubectl get pods -n tm-coaching -o=custom-columns=NameSpace:.metadata.namespace,NAME:.metadata.name,CONTAINERS:.spec.containers[*].name
NameSpace     NAME                               CONTAINERS
tm-coaching   demo-tm-coaching-54bd45d68-lqh2l   demo-tm-coaching,istio-proxy

Журналы

[2020-04-15T19:33:24.369Z] "GET / HTTP/2" 404 - "-" "-" 0 0 0 - "10.128.15.226" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36" "0b41dd7b-7bbe-9db1-95b1-df47386c5e8b" "q-tm-coaching.q-appliedai.com" "-" - - 10.4.4.10:443 10.128.15.226:12688 case-doc.q-appliedai.com default
[2020-04-15T19:33:27.719Z] "GET / HTTP/2" 404 - "-" "-" 0 0 0 - "10.128.15.226" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36" "3e6a51b3-d370-946e-a90f-259f17c4cea7" "case-doc.q-appliedai.com" "-" - - 10.4.4.10:443 10.128.15.226:12688 case-doc.q-appliedai.com default

1 Ответ

0 голосов
/ 07 апреля 2020

К сожалению, нет возможности настроить GKE Ingress для поддержки служб в различных пространствах имен.

Пожалуйста, посмотрите ниже со ссылкой на страницу github ingress-gce.

Является ли пространство имен контроллеров Ingress?

Ingress является пространством имен, это означает, что 2 объекта Ingress могут иметь одинаковое имя в 2 пространствах имен, и должны указывать только на Services в своих собственных Пространство имен . Администратор может развернуть контроллер Ingress так, чтобы он удовлетворял только Ingress из заданного пространства имен, но по умолчанию контроллеры будут наблюдать весь кластер Kubernetes на предмет неудовлетворенного Ingress.

- Github.com : Kubernetes: Ingress-gce: пространство имен контроллеров входа

Кроме того, это подтверждается пользователем liggitt в проблеме github, которую вы включили в свой пост. :

Было бы хорошо иметь возможность обращаться к службам в любом пространстве имен.

Этого намеренно избегали. Перекрестные ссылки на пространства имен будут основным источником атак на повышение привилегий.

- https://github.com: проблемы Kubernetes: 17088

Возможные обходные пути:

  • Создание обоих Deployments в одном и том же пространстве имен.
  • Использование пользовательского Ingress контроллера, например, NGINX Ingress.
  • Используя услугу me sh, как Istio.
  • Создание 2 GKE Ingress ресурсов для каждого пространства имен (у каждого будет свой IP-адрес). 1

1 : Это создаст дополнительные расходы

Пожалуйста, дайте мне знать, если у вас есть вопросы по этому поводу.

Существует официальная документация о лучших практиках с пространствами имен: Cloud.google.com: Лучшие практики Kubernetes по организации с пространствами имен

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...