Конечные точки HTTPS для локальных адресов служебной службы kubernetes после завершения SSL

Question

У меня есть кластер k8s, который находится за балансировщиком нагрузки. Запрос на myapisite.com проходит через LB и маршрутизируется k8s для правильного развертывания, получая сертификат SSL от входа балансировщика нагрузки k8s, который затем направляется на вход службы, например так:

spec:
  rules:
  - host: myapisite.com
    http:
      paths:
      - backend:
          serviceName: ingress-605582265bdcdcee247c11ee5801957d
          servicePort: 80
        path: /
  tls:
  - hosts:
    - myapisite.com
    secretName: myapisitecert
status:
  loadBalancer: {}

Так что мой myapisite.com разрешает HTTPS правильно.

Моя проблема заключается в том, что, сохраняя вышеуказанную настройку (если это возможно), мне нужно иметь возможность перейти к локальным конечным точкам службы в том же пространстве имен по HTTPS, то есть из другого модуля, я должен быть в состоянии свернуть или wget следующее без ошибка сертификата:

https: \\ myapisite.namespace.svc.cluster.local

Даже если бы я был заинтересован в том, чтобы не прерывать SSL до уровня pod, создание записи SAN в сертификате для адреса.local не вариант, поэтому решение не является жизнеспособным.

Есть ли какой-то простой способ, которым я пропускаю, чтобы все локальные DNS доверяли k8s? Или какое-то другое решение, которое, мы надеемся, не является изобретением колеса? Я использую Kubernetes версии 1.11 с CoreDNS.

Спасибо, и заранее извините, если это глупый вопрос.

Answer 1

Если ваше приложение может прослушивать HTTP и HTTPS, вы можете настроить оба. Это означает, что вы сможете получить доступ через HTTP и HTTPS по своему усмотрению. Теперь то, как вы создаете и распространяете сертификат, - это отдельная история, но вы должны решить ее самостоятельно (возможно, используя свой собственный центр сертификации и храня сертификат / ключ в секрете). Если вы не хотите использовать что-то вроде Istio и его взаимную поддержку tls для защиты трафика между сервисами.

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