Mastering Kubernetes Networking: IP Types and Service Exposure Strategies

Preface

In a Kubernetes cluster, networking is a critical infrastructure that must ensure connectivity, efficient forwarding, and automated IP/Port allocation, while offering users a simple way to access applications.

Kubernetes Service Fundamentals

Kubernetes addresses service discovery and load balancing through CNI, Service, DNS, and Ingress. The Service object is the foundation of micro‑service communication, implemented by the kube-proxy component.

kube-proxy runs on each node, watches the API server for Service changes, and configures iptables rules to forward traffic. Services can be created using LabelSelector , Headless , or ExternalName , each receiving a virtual IP (ClusterIP) for internal access.

Kubernetes IP Types

NodeIP : The IP address of a physical or virtual node. External users can reach services via NodeIP:NodePort.

PodIP : The IP address assigned to each Pod (Docker container). It is a virtual L2 address, often changing, and is not reachable from outside the cluster.

ClusterIP : A virtual IP assigned to a Service, usable only within the cluster for Service‑to‑Service communication.

Relationship Diagram

The diagram illustrates external access via LoadBalancer (NodePort backend), direct NodePort access, internal ClusterIP routing, ExternalName DNS resolution, and Pod‑to‑Service communication.

Three Ways to Expose Services

NodePort

NodePort allocates a port (default >30000) on every node and forwards traffic to the corresponding PodIP via iptables. Advantages: simple to use. Drawbacks: SNAT hides client IP, creates a single point of traffic bottleneck, and large port ranges become hard to manage. NodePort is not recommended for production exposure.

LoadBalancer

LoadBalancer relies on cloud‑provider plugins (e.g., QingCloud LB, Alibaba Cloud SLB) that integrate with the cloud‑controller‑manager to automatically provision external load balancers and bind them to Service objects. This method avoids NodePort’s single‑point bottleneck but is limited to managed Kubernetes services on supported clouds.

Ingress

Ingress is not a native Service type; it is a set of rules that map external HTTP/HTTPS requests to internal Services based on hostnames or URL paths. An Ingress controller (e.g., NGINX Ingress Controller) watches these rules, generates the corresponding NGINX configuration, and reloads it.

Example Ingress manifest:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-myapp
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: "/"
        backend:
          serviceName: myapp
          servicePort: 80

QingCloud LB + Ingress Integration

QingCloud provides a LoadBalancer plugin that can be combined with Ingress to expose internal services. After enabling the project gateway in KubeSphere, the Ingress controller is automatically installed.

KubeSphere Project Gateway and Application Routing

The project gateway acts as the Ingress controller (a Layer‑7 load balancer). Application routing defines the Ingress rules.

Improvement Suggestions

Manually creating LB listeners and adding NodePort backends is cumbersome. Using the cloud‑controller‑manager (CCM) can automate listener creation, backend association, and public IP binding, reducing operational overhead.

CCM also ensures that each NodePort is automatically added to the listener backend, improving fault tolerance.

References

Expose services to the internet: https://docsv3.qingcloud.com/container/qke_plus/manual/service/lb_service/

Configure load balancer: https://docsv3.qingcloud.com/container/qke_plus/manual/service/ccm_config/

QingCloud CCM source: https://github.com/yunify/qingcloud-cloud-controller-manager

NGINX Ingress real‑IP guide: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-real-ip