Kubernetes Ingress理解确认及相关技术问题咨询

Hey there! Let me walk through your understanding of Kubernetes Ingress across two environments and clarify your questions clearly:

一、Cloud Infrastructure Environment #

Cloud providers typically offer a managed Ingress Controller as part of their Kubernetes service. This Controller runs within the provider's managed control plane (not as a visible Pod in your user-facing cluster, which is why kubectl get pods --all-namespaces won't show it).

Configuration Steps (Your Summary) #

• Create your application Deployment and expose it via a NodePort-type Service
• Set up a default-backend Service to handle requests that don't match any Ingress rules
• Define your Ingress rules with a YAML like this:

kind: Ingress
metadata:
  name: app-ingress
spec:
  backend:
    serviceName: default-svc
    servicePort: 80
  rules:
  - host: api.foo.com
    http:
      paths:
      - path: /v1/
        backend:
          serviceName: api-svc-v1
          servicePort: 80
      - path: /v2/
        backend:
          serviceName: api-svc-v2
          servicePort: 80

After submitting this to the API Server, the managed Ingress Controller watches for changes, updates its underlying /etc/nginx.conf, and the provider provisions an external LoadBalancer with a public IP (LB_IP) within a few minutes.

Testing Approach (Your Summary) #

• Requests to http://api.foo.com/ or the raw LB_IP root path get routed to the default service
• Requests to http://api.foo.com/v1 or http://<LB_IP>/v1 go to api-svc-v1; /v2 routes to api-svc-v2

Your Questions & Answers #

1. How can I view files under /etc/nginx if I can't see the Ingress Controller Pod?

Since the managed Controller is part of the cloud provider's control plane (not your cluster's worker nodes), you can't directly exec into it. Instead, use these practical workarounds:

• Check your cloud provider's logging service (e.g., AWS CloudWatch, GCP Cloud Logging) – most providers log Nginx activity, including config-related messages that can help you verify routing logic
• Use the provider's CLI or console to inspect Ingress resource details; many offer simplified views of the underlying routing rules and config snippets
• If you need full custom config control, you can deploy a self-managed Ingress Controller alongside the managed one (though this is rarely necessary unless you need specific Nginx settings the managed service doesn't support)

2. When the external LB_IP is created, do all domain registrars automatically update the DNS record for api.foo.com?

Absolutely not. The cloud provider only creates the LoadBalancer with its public IP – you must manually update your domain's DNS records via your registrar's control panel to point api.foo.com to this LB_IP. Kubernetes and cloud providers don't have permission to modify third-party DNS systems; this step is entirely in your hands.

二、Kubeadm-Selfhosted Kubernetes Environment #

Unlike managed cloud clusters, kubeadm clusters don't include a built-in Ingress Controller – you have to deploy one yourself.

Configuration Steps (Your Summary) #

1. Create your application Deployment and expose it via a NodePort-type Service
2. Set up a default-backend Service
3. Deploy the Nginx Ingress Controller using a YAML like this (note: this is a partial spec; you'd typically include metadata, replicas, and selectors in the full YAML):

spec:
  containers:
  - args:
    - /nginx-ingress-controller
    - "--default-backend-service=$(POD_NAMESPACE)/default-backend"
    image: "gcr.io/google_containers/nginx-ingress-controller:0.8.3"
    imagePullPolicy: Always
    livenessProbe:
      httpGet:
        path: /healthz
        port: 10254
        scheme: HTTP
      initialDelaySeconds: 10
      timeoutSeconds: 5
    name: nginx-ingress-controller
    readinessProbe:
      httpGet:
        path: /healthz
        port: 10254
        scheme: HTTP

You can verify the Controller is running with kubectl get pods, and exec into it directly to view /etc/nginx/nginx.conf.

4. Define your Ingress rules (note the rewrite-target annotation to handle path routing correctly):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/rewrite-target: /
  name: app-ingress
spec:
  rules:
  - host: testabc.com
    http:
      paths:
      - backend:
          serviceName: appsvc1
          servicePort: 80
        path: /app1
      - backend:
          serviceName: appsvc2
          servicePort: 80
        path: /app2

After submitting this, the Controller updates its Nginx config, but won't create a LoadBalancer automatically. Running kubectl get ingress will show IP=127.0.0.1 (a placeholder). You need to expose the Controller via a Service:

kind: Service
metadata:
  name: nginx-ingress
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 33200
    name: http
  selector:
    app: nginx-ingress-lb

Using type: LoadBalancer (if your environment supports it, e.g., with a cloud load balancer integration or tools like MetalLB) will provision an external IP.

Testing Approach (Your Summary) #

• Requests to http://testabc.com/ or the exposed NodePort/LoadBalancer IP root path route to the default service
• Requests to http://testabc.com/app1 or http://<NodeIP>:33200/app1 go to appsvc1; /app2 routes to appsvc2

Your Question & Answer #

3. If the Ingress Controller Pod runs on node3, how does it listen to the Ingress API on node1?

The Controller doesn't "listen directly to node1" – here's the actual flow:

• All Kubernetes API Server components (including the Ingress API) are part of the control plane. Every node in your cluster (including node3) is configured to communicate with the API Server via a stable internal endpoint (usually kubernetes.default.svc.cluster.local, a ClusterIP service that points to the control plane nodes).
• The Ingress Controller pod uses the cluster's default service account to authenticate with the API Server. It sets up a watch on all Ingress resources across the cluster.
• When you create/update an Ingress resource, the API Server sends an event to all registered watchers (like your Controller on node3). The Controller then pulls the updated resource definition and adjusts its Nginx config accordingly.
• The node where the API Server runs (node1) doesn't affect this communication – the cluster's internal network handles routing between the Controller pod and the API Server, regardless of their node locations.

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