gke и автоматически созданный домен для включения HTTP-маршрутизации

Question

Мне нужно использовать домен для кластера GKE для доступа к входу в кластер и приложения, аналогично HTTP-надстройке azure AKS, которая предоставляет общий созданный домен (а не пользовательский домен)https://docs.microsoft.com/en-us/azure/aks/http-application-routing Есть ли какое-либо решение в облаке Google?

Наш процесс создания / удаления GKE является частью инструментов IaC, и мы автоматизируем кластер и развертывание нашего приложения для разработки / тестирования / тестирования. А создание универсального домена и привязка управляемой зоны DNS к ресурсам кластера дает нам большую гибкость. В противном случае нам придется создать собственный домен и управляемую зону DNS, которые будут статичными и внесут ненужную сложность в инструменты подготовки.

Answer 1

В gke нет общих параметров домена, поэтому мне нужно приобрести домен и обновить NS в соответствии с созданной управляемой зоной DNS NS, и они будут автоматически синхронизированы, когда я обновлю вход в gke с помощью

Я могу сказать, что решаю эту проблему с помощью этих шагов,

1- Создайте управляемую зону, имя которой принадлежит собственному домену, и убедитесь, что у нее есть разрешение на доступ к домену из созданных вами зон DNS. Имеется в виду предоставление доступа к проекту Google, в котором существует ваша зона DNS.

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

      gcloud container clusters create “external-dns” \
    —num-nodes 1 \
    —scopes “https://www.googleapis.com/auth/ndev.clouddns.readwrite

Создайте зону DNS, которая будет содержать управляемые записи DNS.

      $ gcloud dns managed-zones create “xxx.test-dev” \
    —dns-name “xxx.test.dev.” \
    —description “Automatically managed zone by kubernetes.io/external-dns test.dev domain name”

2- Пожалуйста, разверните ресурсы на gke, имя которого external-dns

      https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/gke.md#deploy-externaldns

И проверьте журналы с помощью

      kubectl logs $(kubectl get pods --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep dns)

Или же

      kubectl logs $(kubectl get pods --no-headers -o custom-columns=":metadata.name" | grep dns)

И если вы видите что-то вроде все идет гладко

      time="2021-01-20T11:37:46Z" level=info msg="Add records: xxx.test.dev. A [34.89.xx.xx] 300"
time="2021-01-20T11:37:46Z" level=info msg="Add records: xxx.test.dev. TXT [\"heritage=external-dns,external-dns/owner=my-identifier,external-dns/resource=ingress/default/ingress-test\"] 300"
time="2021-01-20T11:38:47Z" level=info msg="All records are already up to date"

Обратите внимание, что запись TXT создана вместе с записью A. Запись TXT означает, что соответствующая запись A управляется ExternalDNS. Это делает ExternalDNS безопасным для работы в средах, где есть другие записи, управляемые другими средствами. Давайте проверим, можем ли мы разрешить это DNS-имя. Сначала мы спросим серверы имен, назначенные вашей зоне.

      $ dig +short @ns-cloud-e1.googledomains.com. xxx.test.dev.
104.155.xx.xx

И вы можете проверить правильность IP-адреса домена или наличие проблемы

      host https://xxx.test.dev/        
Host https://xxx.test.dev/ not found: 3(NXDOMAIN)

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

      host xxx.test.dev
xxx.test.dev has address 35.197.xx.xx

Answer 2

GCP не реализовал такие ресурсы, однако эту операцию можно автоматизировать с помощью одного из доступных API-интерфейсов Cloud DNS 1 , например, ResourceRecordSets 2 для настройки записей A в ManagedZone, которую вы хотите назначить хосту, записав эту конфигурацию в сценарии после Ingress. создание контроллера.

Например, получение IP-адреса, выделенного входному контроллеру, с помощью команды, подобной kubectl describe ing <ingress-name> |grep “Address:” |awk ‘{print $2}’чем использование информации об IP для создания тела запроса API 3 .