Часть проблемы решена @Ben. Я бы предостерег от использования внешнего источника с открытым исходным кодом, поскольку вам может не понравиться создавать зависимость от этой очень важной функции. Требуется дать дополнительное разрешение!
Вам понадобится виртуальный частный ip, и это достигается за счет внутренней аннотации балансировщика нагрузки, и это работает. Я недавно задокументировал конец end tls / ssl с внутренним балансировщиком нагрузки и могу найти его в https://blogs.aspnet4you.com/2019/01/06/end-to-end-tlsssl-offloading-with-application-gateway-and-kubernetes-ingress/.
Имейте в виду, что мое решение работало отлично, пока я не удалил надстройку маршрутизации приложений http. Зачем? Дополнение поставляется с Azure Dns (общедоступным) и общедоступным балансировщиком нагрузки. Оба из них были удалены навсегда, когда я удалил надстройку, но удаление сломало запись DNS, связанную с vip внутреннего балансировщика нагрузки. Я не собирался удалять зону DNS. Моя попытка создать новую зону DNS и добавить запись A с частным IP не сработала. Кубернетес не может решить fqdn. Пробовал с Azure Private DNS, но он также не может решить! Моя попытка использовать configmap с kube-dns не сработала, и это нарушило разрешение dns других вещей, если я включил апстрим! Итак, расследование продолжается!
Мне бы очень хотелось услышать, как вы решили проблему fqdn.
Что касается оптимизма, я думаю, что пользовательский DNS-сервер на базе виртуальной машины может быть хорошим вариантом, и вы, вероятно, выбрали бы его для гибридного решения.