GKE是否有类似AKS HTTP路由的自动生成通用域名方案？

Great question! I’ve tackled similar IaC automation hurdles for GKE dev/test/staging environments before, so let’s break down how to replicate that AKS-style auto-generated domain functionality without the overhead of static custom domains and manual DNS setup.

Core Approach #

GKE doesn’t have a direct equivalent to AKS’s HTTP Application Routing plugin, but we can build the same workflow using Cloud DNS + ExternalDNS + IaC tooling (like Terraform or Helm). This setup automatically creates and cleans up DNS records tied to your Ingress resources, perfect for ephemeral environments.

Step 1: Set Up a Shared or Environment-Specific Cloud DNS Zone #

First, you’ll need a base domain (e.g., gke-mycompany.com) configured as a Cloud DNS managed zone. For IaC, you can:

• Create a single shared zone for all environments, then use subdomains like dev.gke-mycompany.com, test.gke-mycompany.com
• Or dynamically create a dedicated zone per environment when spinning up a cluster (ideal for isolation)

Either way, your IaC tool (Terraform, for example) can handle this creation/destruction alongside your cluster.

Step 2: Deploy ExternalDNS to Your GKE Cluster #

ExternalDNS is a CNCF tool that automatically syncs Kubernetes Ingress/Service hostnames to Cloud DNS. It’s the backbone of this auto-domain workflow:

1. Grant Permissions: Use GKE’s Workload Identity (recommended over service account keys) to give ExternalDNS permission to edit Cloud DNS records.

   • Create a Cloud IAM service account with the roles/dns.admin role
   • Bind it to the Kubernetes service account that ExternalDNS will use:

     gcloud iam service-accounts add-iam-policy-binding \
       dns-admin-sa@your-gcp-project.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:your-gcp-project.svc.id.goog[external-dns/external-dns]"
     

2. Install ExternalDNS via Helm:

   helm repo add external-dns https://kubernetes-sigs.github.io/external-dns/
   helm install external-dns external-dns/external-dns \
     --namespace external-dns \
     --create-namespace \
     --set provider=google \
     --set google.project=your-gcp-project \
     --set policy=sync \
     --set sources=ingress \
     --set serviceAccount.annotations."iam.gke.io/gcp-service-account"=dns-admin-sa@your-gcp-project.iam.gserviceaccount.com
   

Step 3: Auto-Generate Domains for Your Ingress Resources #

Once ExternalDNS is running, simply add an annotation to your Ingress manifests to define the auto-generated hostname. For IaC/Helm deployments, you can dynamically inject environment or app-specific values:

Example Ingress YAML (with Helm templating):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Release.Name }}-ingress
  annotations:
    external-dns.alpha.kubernetes.io/hostname: {{ .Release.Name }}.{{ .Values.environment }}.gke-mycompany.com
    kubernetes.io/ingress.class: gce # Use "gke" for GKE Ingress
spec:
  rules:
  - host: {{ .Release.Name }}.{{ .Values.environment }}.gke-mycompany.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: {{ .Release.Name }}-service
            port:
              number: 80

ExternalDNS will detect the hostname, fetch the Ingress’s external IP, and automatically create an A/AAAA record in your Cloud DNS zone. When you delete the Ingress (or the entire cluster), it’ll clean up the DNS record too.

Step 4: Simplify with NIP.IO (No Cloud DNS Required) #

If you don’t want to manage a custom domain at all, use nip.io—a free wildcard DNS service that maps any [anything].[ip].nip.io domain to the specified IP. For dev/test environments with ephemeral clusters:

• Set your Ingress hostname to my-app.dev.{{ .Values.ingressIp }}.nip.io
• No Cloud DNS setup needed; the domain works immediately as long as the Ingress IP is valid

This is perfect for short-lived clusters where you don’t want to tie up domain resources.

Integrating with Your IaC Workflow #

All of these steps can be baked into your existing cluster deployment pipeline:

1. Terraform creates the Cloud DNS zone (if using custom domains)
2. Terraform/Helm deploys ExternalDNS with proper permissions
3. Your app deployment Helm chart injects environment-specific hostnames into Ingress manifests
4. When destroying the cluster, Terraform deletes the DNS zone (if environment-specific) and ExternalDNS cleans up any remaining records

This eliminates manual DNS configuration entirely and gives you the flexibility you need for ephemeral environments.

内容的提问来源于stack exchange，提问作者Bora Özkan