Kubernetes Services & Networking

Architecture Overview (Mental Model)

Traffic flow:

Browser
  ↓
Ingress
  ↓
Service
  ↓
Pod
  ↓
Container

Everything in this material builds around this flow.

---

MODULE 1 — Kubernetes Services & Networking

Why Services Exist

Pods:

• Have dynamic IPs
• Can be recreated at any time
• Must never be accessed directly

A Service provides:

• Stable IP
• Load balancing
• Pod discovery

---

Service Types

Type	Purpose	Production Usage
ClusterIP	Internal access	Most common
NodePort	Direct node access	Debug / learning
LoadBalancer	Cloud LB	External traffic

---

Project 1 — Service Traffic Flow

Step 1 — Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=SERVICE WORKS"
        ports:
        - containerPort: 8080

Apply:

kubectl apply -f deployment.yaml

---

Step 2 — ClusterIP Service

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

Apply:

kubectl apply -f service.yaml

Verify:

kubectl get svc
kubectl get endpoints web-svc

---

Step 3 — Access Inside Cluster

kubectl run tmp --rm -it --image=busybox -- sh
wget -qO- http://web-svc

---

Key Concepts Learned

• Services select Pods using labels
• Endpoints show real traffic targets
• Service failure usually means selector mismatch

---

MODULE 2 — Ingress (Real Production Entry)

Ingress provides:

• Single entry point
• Path-based routing
• Host-based routing
• SSL termination

---

Project 2 — Ingress Routing

Step 1 — Deploy Two Versions

Stable Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stable
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echo
      version: stable
  template:
    metadata:
      labels:
        app: echo
        version: stable
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=STABLE VERSION"
        ports:
        - containerPort: 8080

Canary Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
      version: canary
  template:
    metadata:
      labels:
        app: echo
        version: canary
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo:0.2.3
        args:
          - "-listen=:8080"
          - "-text=CANARY VERSION"
        ports:
        - containerPort: 8080

---

Step 2 — Services

apiVersion: v1
kind: Service
metadata:
  name: stable-svc
spec:
  selector:
    app: echo
    version: stable
  ports:
  - port: 80
    targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: canary-svc
spec:
  selector:
    app: echo
    version: canary
  ports:
  - port: 80
    targetPort: 8080

---

Step 3 — Ingress

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

---

Test

curl http://<INGRESS-IP>/
curl http://<INGRESS-IP>/canary

---

MODULE 3 — ConfigMaps & Secrets

Why Configuration Is External

Images must:

• Be immutable
• Work in all environments

Configuration must:

• Change without rebuilding images
• Be environment-specific

---

Project 3 — ConfigMap Injection

Step 1 — ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  MESSAGE: "CONFIGMAP VALUE"

---

Step 2 — Deployment Using ConfigMap

containers:
- name: app
  image: hashicorp/http-echo:0.2.3
  args:
    - "-listen=:8080"
    - "-text=$(MESSAGE)"
  env:
  - name: MESSAGE
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: MESSAGE

---

Update Config Live

kubectl edit configmap app-config
kubectl rollout restart deployment web

---

MODULE 4 — Resource Management

---

Requests vs Limits

Setting	Meaning
requests	Guaranteed
limits	Maximum allowed

---

Project 4 — OOM Kill Demo

resources:
  requests:
    memory: "32Mi"
    cpu: "50m"
  limits:
    memory: "64Mi"
    cpu: "100m"

Observe:

kubectl describe pod

---

MODULE 5 — Autoscaling (HPA)

---

Project 5 — CPU-Based Scaling

Step 1 — Enable Metrics

kubectl get apiservices | grep metrics

---

Step 2 — HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

---

Generate Load

while true; do wget -qO- http://web-svc; done

Watch:

kubectl get hpa
kubectl get pods

---

MODULE 6 — Logs & Troubleshooting

---

Debug Order

1. Pod status
2. Events
3. Logs
4. Resource usage
5. Service endpoints

---

Commands

kubectl get pods
kubectl describe pod <pod>
kubectl logs <pod>
kubectl get events --sort-by=.metadata.creationTimestamp

---

Incident Simulation

• Pod is Running
• Browser shows nothing
• Endpoint list is empty
• Fix selector

---

MODULE 7 — Security Basics

---

Minimal SecurityContext

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

---

Image Best Practices

• Never use latest
• Use fixed versions
• Use trusted registries

---

Final Integrated Project

Production Application Includes:

• Deployment with readiness probe
• ClusterIP Service
• Ingress routing
• ConfigMap
• Resource limits
• HPA
• Logs & events
• Secure container settings

This mirrors how Kubernetes is used in real companies.