AKS环境下内部Ingress部署及前后端服务通信配置问询

Absolutely, your plan is totally feasible—in fact, it’s a go-to pattern in AKS for keeping backend services hidden from the public internet while still leveraging Ingress features like SSL offloading and path routing. Let’s break this down step by step:

Setting up a separate Ingress (or reusing your existing Nginx Ingress Controller with a second internal-facing Service) is a clean way to isolate backend services from the public web. Here’s how to implement it:

Step 1: Create an Internal Load Balancer Service for Nginx Ingress #

Instead of spinning up a whole new Ingress Controller, reuse your existing one by adding a second Service configured for internal Azure LB access:

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-internal
  namespace: ingress-nginx
  annotations:
    # This tells Azure to create an internal LB (no public IP)
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    # Optional: Restrict to a specific VNet subnet if needed
    # service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "your-internal-subnet-name"
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https

Step 2: Define a Backend Ingress Resource #

Create an Ingress for your backend services, using the same Nginx controller class, and configure rules for internal access only:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-ingress
  namespace: your-backend-namespace
  annotations:
    # Reuse your existing Nginx configs here
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/auth-type: "basic" # Example: add auth if needed
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - backend.yourdomain.com
      secretName: your-shared-ssl-secret # Reuse your existing SSL cert
  rules:
    - host: backend.yourdomain.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 80

This Ingress will only be reachable via the internal LB (within your Azure VNet), so public internet traffic can’t reach your backend services.

You absolutely can reuse Nginx’s SSL offloading and routing rules while skipping the internal LB hop—since both frontend and backend are in the same AKS cluster, traffic can stay entirely within the cluster network.

The Optimal Approach: CoreDNS Customization #

Edit your cluster’s CoreDNS ConfigMap to map your backend domain directly to the Nginx Ingress Controller’s ClusterIP. This lets frontend pods resolve the backend domain to the controller’s internal cluster address, bypassing the LB entirely:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
    Corefile: |
      .:53 {
          errors
          health
          kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
          }
          # Add your custom domain mapping here
          hosts {
              <INGRESS_CONTROLLER_CLUSTER_IP> backend.yourdomain.com
              fallthrough
          }
          forward . /etc/resolv.conf
          cache 30
          loop
          reload
          loadbalance
      }

Replace <INGRESS_CONTROLLER_CLUSTER_IP> with the ClusterIP of your existing Nginx Ingress Controller (get it with kubectl get svc nginx-ingress-controller -n ingress-nginx).

Now, when your frontend pods call backend.yourdomain.com, traffic flows directly:
Frontend Pod → Nginx Ingress Controller Pod → Backend Pod
No LB involved, but you still get all the benefits of Nginx’s SSL handling and routing rules.

Alternative: Direct ClusterIP Access #

If you don’t want to modify CoreDNS, you can hardcode the Ingress Controller’s ClusterIP in your frontend config (e.g., https://<CLUSTER_IP>/api). Just make sure to add the Host: backend.yourdomain.com header to requests so Nginx knows which backend route to use.

• Cluster-internal traffic (Frontend → Backend): Use CoreDNS to map backend.yourdomain.com to the Nginx Ingress Controller’s ClusterIP. This is the most efficient and clean option.
• VNet-wide traffic (other Azure VMs/apps → Backend): Set up an Azure Private DNS Zone to map backend.yourdomain.com to the internal LB’s IP. This lets all resources in your VNet access the backend.
• Public traffic (Internet → Frontend): Keep your existing setup—bind your frontend domain to the public LB’s IP as you already do.

内容的提问来源于stack exchange，提问作者luke77