The Problem: Pods are ephemeral. Their IPs change on restart. If your frontend Pod hardcodes the IP of a backend Pod, it breaks every time that backend restarts.

The Solution: A Service is an abstraction that provides a stable virtual IP (ClusterIP) and DNS name. It load-balances traffic to a set of Pods selected by label selectors.

• Label Selectors -- Services find Pods by matching labels (e.g., app: web)
• Endpoints -- Kubernetes automatically maintains a list of healthy Pod IPs that match the selector
• kube-proxy -- Runs on every node, programs iptables/IPVS rules to route Service IP traffic to Pod IPs
• Virtual IP -- The Service ClusterIP does not correspond to any real interface. It exists only in iptables rules

# The Endpoints object is auto-managed
$ kubectl get endpoints my-service

NAME         ENDPOINTS
my-service   10.244.1.5:8080,
             10.244.2.3:8080,
             10.244.3.7:8080

"Think of ClusterIP as your company's internal phone extension. Employees can call each other, but nobody outside the building can dial in."

• Default Service type (if you omit type:)
• Reachable only within the cluster
• Perfect for internal microservice communication
• Gets a stable virtual IP from the Service CIDR range

apiVersion: v1
kind: Service
metadata:
  name: backend-api
spec:
  type: ClusterIP  # default
  selector:
    app: backend
  ports:
    - port: 80        # Service port
      targetPort: 8080 # Pod port
      protocol: TCP

# From any Pod in the cluster:
$ curl http://backend-api.default.svc.cluster.local
{"status": "ok"}

"If ClusterIP is the internal extension, NodePort is like installing a public payphone on the outside wall of your building. Anyone who knows the building's address and the phone number can call in."

• Opens a specific port (30000-32767) on every node
• Traffic to <NodeIP>:<NodePort> is forwarded to the Service
• Automatically creates a ClusterIP too
• Not ideal for production (no single entry point)

apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080  # optional: auto-assigned if omitted

"Imagine a receptionist at the front desk of a large office building. Visitors arrive and say 'I need to see someone in Marketing.' The receptionist routes them to the right person -- without visitors needing to know specific room numbers."

• Provisions an external cloud load balancer (Azure LB, AWS ELB, GCP LB)
• Gets a public IP address automatically
• Builds on NodePort, which builds on ClusterIP
• The standard way to expose services to the internet

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

# After creation:
$ kubectl get svc web-public
NAME         TYPE           EXTERNAL-IP
web-public   LoadBalancer   20.50.100.25

When you create a LoadBalancer Service on AKS, Azure automatically provisions an Azure Load Balancer with a public IP.

• Standard LB -- default in AKS; supports availability zones
• Internal LB -- use annotation for private IP only
• Health probes auto-configured for the NodePort
• Integrated with Azure NSGs for security

# Internal LoadBalancer on Azure
apiVersion: v1
kind: Service
metadata:
  name: internal-api
  annotations:
    service.beta.kubernetes.io/
      azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - port: 443
      targetPort: 8443

"Every cluster has a phone book. When a Service is created, an entry is automatically added. Any Pod can look up any Service by name -- no hardcoded IPs needed."

• CoreDNS runs as a Deployment in kube-system
• Every Service gets a DNS A record automatically
• Format: <service>.<namespace>.svc.cluster.local
• Within the same namespace, just use the service name

# Full DNS name
backend-api.production.svc.cluster.local

# Within same namespace (short name)
backend-api

# Cross-namespace
backend-api.production

# SRV records for ports
_http._tcp.backend-api.production.svc.cluster.local

Every Pod's /etc/resolv.conf is automatically configured to use CoreDNS as its nameserver.

• Search domains are set so short names resolve correctly
• Same-namespace lookups: my-svc resolves
• Cross-namespace: my-svc.other-ns resolves
• External DNS: falls through to upstream nameservers

# Pod's /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local
       svc.cluster.local
       cluster.local
options ndots:5

# Quick DNS test
$ kubectl exec -it debug-pod -- nslookup backend-api
Server:    10.96.0.10
Address:   10.96.0.10#53

Name:   backend-api.default.svc.cluster.local
Address: 10.96.142.37

"Sometimes you do not want a load balancer in the middle. You want to know exactly who you are talking to -- like calling someone's direct line instead of going through the operator."

• Set clusterIP: None
• DNS returns the IPs of individual Pods instead of a single VIP
• No load balancing by kube-proxy
• Client decides which Pod to connect to

apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  clusterIP: None  # Headless!
  selector:
    app: postgres
  ports:
    - port: 5432

# DNS returns all Pod IPs
$ nslookup postgres
Name: postgres.default.svc.cluster.local
Address: 10.244.1.10
Address: 10.244.2.11
Address: 10.244.3.12

# StatefulSet pods get individual DNS:
# postgres-0.postgres.default.svc.cluster.local
# postgres-1.postgres.default.svc.cluster.local

Services can expose multiple ports. This is common for apps that serve HTTP on one port and metrics on another.

• Each port must have a unique name when multiple ports are defined
• Named ports in Pods let you change the actual port number without updating the Service
• SRV records use port names for discovery

apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: web-port  # named port
    - name: metrics
      port: 9090
      targetPort: metrics-port

"ExternalName is like a redirect sign on a door that says 'We moved to Building B.' It simply points you somewhere else."

• Maps a Service name to a DNS CNAME record
• No proxying, no ClusterIP, no selectors
• Useful for pointing to external databases or APIs
• Allows you to migrate services without changing application code

apiVersion: v1
kind: Service
metadata:
  name: my-database
spec:
  type: ExternalName
  externalName: db.prod.example.com

# From inside the cluster:
$ nslookup my-database
# Returns CNAME: db.prod.example.com

# App connects to "my-database" --
# later you can switch to an in-cluster
# DB without changing app config

"Think of Ingress as a smart receptionist who reads the visitor's badge and routes them to the right department -- all through a single front door."

• Ingress is a Kubernetes resource that defines HTTP/HTTPS routing rules
• Ingress Controller is the actual reverse proxy that implements those rules
• Route by hostname and/or URL path
• Handles TLS termination
• One load balancer, many services

Path-based routing sends different URL paths to different backend Services. This is the most common Ingress pattern.

• pathType: Prefix -- matches URL path prefixes
• pathType: Exact -- matches exact path only
• pathType: ImplementationSpecific -- up to the controller
• A defaultBackend catches unmatched requests

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
    - http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

Route traffic to different Services based on the hostname in the HTTP request. Perfect for multi-tenant setups or microservice architectures.

• Each host rule matches a specific domain
• Can combine host and path rules
• Requires DNS to point all domains to the Ingress Controller IP
• Wildcard hosts (*.example.com) are supported

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-host
spec:
  ingressClassName: nginx
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

Ingress can terminate TLS (HTTPS) so your backend Services only need to handle plain HTTP. The TLS certificate is stored as a Kubernetes Secret.

• Create a TLS Secret with your cert and key
• Reference it in the Ingress tls section
• Ingress Controller handles the encryption/decryption
• Use cert-manager for automatic Let's Encrypt certificates

# Create TLS secret
$ kubectl create secret tls my-tls \
    --cert=tls.crt --key=tls.key

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: my-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

Azure Application Gateway Ingress Controller (AGIC) turns Azure Application Gateway into the Ingress for your AKS cluster.

• L7 Load Balancing -- HTTP/HTTPS aware routing
• WAF v2 -- Protects against OWASP Top 10
• SSL offloading -- Integrate with Azure Key Vault for certs
• Autoscaling -- App Gateway scales independently
• Health probes -- Auto-configured from readiness probes

Kubernetes has three fundamental networking requirements:

1. Every Pod gets its own IP address -- no NAT between Pods
2. Pods on any node can communicate with Pods on any other node without NAT
3. Agents on a node (e.g., kubelet) can communicate with all Pods on that node

"Network Policies are like firewall rules for your Pods. By default, all doors are unlocked. Once you create a Network Policy, you start locking doors and only allowing specific visitors through."

• Namespace-scoped resources
• Select Pods using podSelector
• Control ingress (incoming) and egress (outgoing) traffic
• Additive -- if any policy allows the traffic, it is allowed
• Requires a CNI that supports it (Calico, Cilium, Azure NPM)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080

Controlling Outbound Traffic

Egress policies control where Pods can send traffic. Essential for preventing data exfiltration.

• Block outbound internet access from sensitive Pods
• Restrict database Pods to only accept connections from app Pods
• Allow DNS traffic (port 53) to CoreDNS -- otherwise DNS resolution breaks!

# Allow egress to specific namespace + DNS
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    # Allow DNS
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - port: 53
          protocol: UDP
    # Allow to database namespace
    - to:
        - namespaceSelector:
            matchLabels:
              tier: database