External-to-Service — NodePort, LoadBalancer, and Ingress

External traffic to a Service uses one of three patterns: NodePort, LoadBalancer, or Ingress. The pattern matches the traffic profile; the operational discipline is the same. This lesson walks the three patterns, the traffic flow, the failure modes, and the operational patterns.

The NodePort pattern

The NodePort pattern:

apiVersion: v1
kind: Service
metadata:
  name: billing
spec:
  type: NodePort
  selector:
    app: billing
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

The NodePort pattern exposes the Service on a port on every node. The external traffic is directed to the node’s IP and the NodePort.

flowchart LR
    A[External client] -->|node-1:30080| B[NodePort]
    B -->|kube-proxy| C[Backend Pod]

The NodePort pattern is the simplest. The external traffic is directed to the node; the kube-proxy forwards the traffic to the backend Pod.

The NodePort pattern’s failure modes:

• Node failure: the traffic is lost when the node fails. The external traffic is directed to the node’s IP; the node is not available.
• Port conflict: the NodePort is fixed (30000-32767). The cluster operator must ensure the ports are not conflicting.
• No TLS: the NodePort is unencrypted. The external traffic is in plaintext.

The NodePort pattern is appropriate for development and testing. The production pattern is the LoadBalancer.

The LoadBalancer pattern

The LoadBalancer pattern:

apiVersion: v1
kind: Service
metadata:
  name: billing
spec:
  type: LoadBalancer
  selector:
    app: billing
  ports:
    - port: 80
      targetPort: 8080

The LoadBalancer pattern allocates a cloud provider’s load balancer for the Service. The external traffic is directed to the load balancer; the load balancer forwards the traffic to the backend Pods.

flowchart LR
    A[External client] -->|cloud LB| B[LoadBalancer]
    B -->|kube-proxy| C[Backend Pod 1]
    B -->|kube-proxy| D[Backend Pod 2]
    B -->|kube-proxy| E[Backend Pod 3]

The LoadBalancer pattern is the cloud-managed pattern. The cloud provider’s load balancer is the external endpoint; the load balancer forwards the traffic to the backend Pods.

The LoadBalancer pattern’s failure modes:

• Cloud provider failure: the cloud provider’s load balancer is unavailable. The external traffic is lost.
• Cost: the cloud provider’s load balancer is expensive. The cost is per-Service.
• No TLS: the LoadBalancer is unencrypted. The external traffic is in plaintext.

The LoadBalancer pattern is the production pattern for cloud-managed clusters. The cost is high; the pattern is appropriate for production.

The Ingress pattern

The Ingress pattern:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: billing
spec:
  rules:
    - host: billing.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: billing
                port:
                  number: 80

The Ingress pattern exposes the Service via the Ingress controller. The Ingress controller is the cluster’s HTTP load balancer.

flowchart LR
    A[External client] -->|HTTPS| B[Ingress controller]
    B -->|host: billing.example.com| C[Service: billing]
    C -->|kube-proxy| D[Backend Pod 1]
    C -->|kube-proxy| E[Backend Pod 2]

The Ingress pattern is the production pattern for HTTP traffic. The Ingress controller is the cluster’s HTTP load balancer; the controller forwards the traffic to the backend Pods.

The Ingress pattern’s advantages:

• TLS termination: the Ingress controller terminates the TLS. The external traffic is encrypted.
• Host-based routing: the Ingress controller routes based on the host. The cluster can serve multiple Services on the same IP.
• Path-based routing: the Ingress controller routes based on the path. The cluster can serve multiple Services on the same host.
• Cost: the Ingress controller is a single load balancer. The cost is low.

The Ingress pattern’s failure modes:

• Ingress controller failure: the Ingress controller is unavailable. The external traffic is lost.
• TLS errors: the TLS certificate is invalid. The external traffic is rejected.

The Ingress pattern is the production pattern for HTTP traffic. The pattern is appropriate for production.

The traffic flow

The traffic flow for external traffic:

sequenceDiagram
    autonumber
    participant EC as External client
    participant LB as LoadBalancer
    participant IC as Ingress controller
    participant KP as kube-proxy
    participant P as Pod

    EC->>LB: HTTPS request
    LB->>IC: forward to Ingress controller
    IC->>IC: terminate TLS
    IC->>IC: route based on host/path
    IC->>KP: forward to Service
    KP->>P: forward to backend Pod
    P->>P: handle request
    P->>KP: response
    KP->>IC: response
    IC->>LB: response
    LB->>EC: response

The traffic flow is the cluster’s external access. The External client sends the request; the load balancer forwards the request; the Ingress controller terminates the TLS; the kube-proxy forwards the traffic to the backend Pod.

The three patterns compared

The three patterns:

The production rule is to use the Ingress pattern for HTTP traffic; the LoadBalancer pattern for non-HTTP traffic; the NodePort for development.

The external access’s security

The external access’s security:

• TLS: the external traffic should be encrypted. The Ingress controller terminates the TLS.
• Authentication: the external traffic should be authenticated. The Ingress controller or the Service enforces the authentication.
• Authorization: the external traffic should be authorized. The Ingress controller or the Service enforces the authorization.
• Network policy: the external traffic should be restricted to the necessary ports. The NetworkPolicy enforces the restriction.

The production rule is to apply the security controls to the external access. The Ingress controller is the cluster’s primary security gate.

The external access’s monitoring

The external access’s monitoring:

groups:
  - name: ingress
    rules:
      - alert: Ingress5xxRate
        expr: |
          rate(
            nginx_ingress_controller_requests{status=~"5.."}[5m]
          ) > 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Ingress 5xx rate high"
          description: "Ingress {{ $labels.ingress }} has a 5xx rate of {{ $value }} per second over the last 5 minutes."

The alert fires when the Ingress’s 5xx rate is high. The alert is the operator’s signal that the Ingress controller is failing.

Quiz

Production discipline

• The external access has three patterns. The NodePort is for development; the LoadBalancer is for cloud-managed; the Ingress is for HTTP.
• Use the Ingress pattern for HTTP traffic. The Ingress pattern is the production pattern for HTTP traffic.
• Use the LoadBalancer pattern for non-HTTP traffic. The LoadBalancer pattern is the production pattern for non-HTTP traffic.
• Apply the security controls to the external access. The TLS, authentication, authorization, and network policy are the security controls.
• Audit the external access at every release. The external access’s configuration should be version- controlled; the audit catches the failures.
• Monitor the external access’s metrics. The Ingress controller’s metrics expose the external access health.
• Test the external access in non-production. A staging cluster that mirrors production is the right place to test the external access.
• Document the external access’s design. The external access is the cluster’s gateway; the documentation is the cluster’s networking reference.