Services and Networking

After this lesson, you will be able to: Distinguish Service types (ClusterIP, NodePort, LoadBalancer) and configure Ingress to route external traffic to services by hostname/path.

Services route traffic INSIDE the cluster. Ingress is how requests from the INTERNET reach the right Service. This lesson covers both.

Prerequisites:Deployments in Depth

Service types: pick the right one

ClusterIP (default): an IP inside the cluster only. Service-to-service traffic. The right choice 95% of the time. NodePort: opens a port (30000-32767) on EVERY node. Mostly used for local dev / kind clusters. LoadBalancer: provisions a cloud LB (AWS ALB, GCP LB) and points it at the Service. ONE per public endpoint. Expensive at scale. ExternalName: a DNS CNAME alias to an external host. Used to abstract third-party endpoints behind a friendly internal name.

Service YAML for the common cases

ClusterIP for internal; LoadBalancer for one-off public exposure.

sql

# Internal service
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  type: ClusterIP
  selector: { app: api }
  ports:
    - port: 80          # what callers connect to
      targetPort: 8000  # what the Pod listens on
---
# Public service via cloud LB
apiVersion: v1
kind: Service
metadata:
  name: web-public
spec:
  type: LoadBalancer
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 3000
# After applying, kubectl get svc shows an EXTERNAL-IP (your public LB).

Why Ingress, when LoadBalancer 'just works'

One LoadBalancer per public endpoint = expensive (each is a real cloud LB). Ingress is a Kubernetes object that says 'route traffic from a single LB to many Services based on hostname or path'. One LB at the edge + an Ingress controller (nginx-ingress, traefik, AWS ALB controller) + N Ingress objects = many public endpoints, one bill. Modern alternative: Gateway API (the next-gen replacement; still gaining adoption).

Ingress YAML

Routes example.com to web, api.example.com to api.

tsx

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts: [example.com, api.example.com]
      secretName: app-tls
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }

Common mistakes only experienced engineers avoid

One LoadBalancer Service per app. The cloud bill balloons. Use Ingress. Forgetting the `ingressClassName`. Without it, no controller picks up the Ingress. Skipping cert-manager. Manual TLS renewal in K8s is a maintenance nightmare. Hostname mismatch in TLS section vs rules. Cert request fails. Routing by IP. Stick to hostname or path; IP routing is brittle.

Quick Check

You want to host 5 apps on different domains in your cluster with HTTPS. What's the right shape?

Pick the cost-effective architecture.

5 LoadBalancer Services + 5 manual cert renewals1 Ingress controller + 1 LoadBalancer + 5 Ingress objects + cert-manager for auto-TLS5 NodePort Services + reverse proxy on each nodeClusterIP only with no external access

←Deployments in Depth

Back to Kubernetes

Persistent Storage→