Kubernetes Services & Networking

Source: Dev.to

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

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 the Cluster

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

Key Concepts Learned

• Services select Pods using labels.
• Endpoints show the real traffic targets.
• Service failure usually means a 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

Stable Service

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

Canary Service

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:///
curl http:///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

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

Common Commands

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

Incident Simulation

• Pod is Running
• Browser shows nothing
• Endpoint list is empty
• Fix: correct the 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.