AKS 25 -Kubernetes services

Q1: Why do we need a Service in Kubernetes?

A Service in Kubernetes provides a stable way to access pods deployed in the cluster. Pods are ephemeral: when a Pod goes down, it is recreated with a new IP address. If clients are given direct Pod IPs, they will often fail to connect after Pods restart due to changed IPs. Services solve this problem by abstracting Pod access behind a stable DNS name and virtual IP.

What problems do we face if there is no Service in Kubernetes?

**A:**  
Without Services:

- Clients would need to know the IP of every Pod, which can change at any time.
- If Pods die and restart (auto-healing), new Pods get new IPs; clients can't reach new Pods without manual updates.
- There's no built-in load balancing for distributing traffic across multiple Pod replicas.
- It's difficult to expose the application to users inside or outside the cluster network.

What are the main advantages of using a Service in Kubernetes?

**A:**  
1. **Load Balancing:** Services distribute traffic among the set of Pods they target, balancing client requests across all healthy replicas.
2. **Service Discovery:** Services allow clients to use a consistent DNS name regardless of which individual Pods serve the request. Services select Pods using labels and selectors rather than track changing IP addresses.
3. **Expose Applications:** Services control who can access the application—internally, within the cluster, within the organization, or publicly via the internet.

How does Service Discovery work in Kubernetes?

**A:**  
Kubernetes Services use labels and selectors to find and route traffic to target Pods. When a new Pod is created with the same labels (e.g., `app: payment`), the Service automatically includes it, as selectors are label-based, not IP-based. This mechanism seamlessly handles Pod IP churn.

What are the main types of Services in Kubernetes, and how are they used?

**A:**  
1. **ClusterIP (default):**  
   - Accessible only within the Kubernetes cluster.
   - Useful for internal communication between components.
2. **NodePort:**  
   - Exposes the Service on a static port on each cluster node.
   - Accessible from outside the cluster by using Node IP + NodePort.
   - Useful for access from within a private network or restricted environment.
3. **LoadBalancer:**  
   - Uses a cloud provider to provision a public load balancer.
   - Provides an external IP so users on the internet can access the application.
   - Common for production internet-facing applications.

Can you give real-world examples for when to use each Service type?

**A:**  
- **ClusterIP:** Internal APIs, databases accessed only from within the cluster.
- **NodePort:** Access for users inside a company (e.g., on a VPN or private network).
- **LoadBalancer:** Public-facing web apps such as `amazon.com`, `google.com`—anyone on the internet can access via public IP.

What is the relationship between Services, Deployments, and ReplicaSets in Kubernetes?

**A:**  
- **Deployment:** Manages the desired state and updates of Pods.
- **ReplicaSet:** Ensures the specified number of Pod replicas are running.
- **Pods:** The actual running instances of the application.
- **Service:** Provides stable networking and load balancing to the Pods, regardless of their dynamic IPs or scaling.

 How does Kubernetes ensure high availability and resiliency with Services?

**A:**  
Kubernetes manages Pod replicas with Deployments and ReplicaSets. When a Pod fails, it's automatically replaced. The Service, using label selectors, routes to available Pods, ensuring there's always a set of healthy Pods receiving traffic.

---

### Q10: If a Pod is recreated with a different IP, how does the Service continue to route traffic correctly?

**A:**  
The Service doesn't rely on fixed Pod IPs. It uses selectors to maintain a list of all Pods with certain labels. When a Pod is recreated, the new Pod has the same label. The Service's underlying proxy (kube-proxy) updates its backend list so traffic is sent to the current set of matching Pods.

What key components are involved in Service networking within Kubernetes?

**A:**  
- **kube-proxy:** Handles the actual routing of requests to backend Pods for the Service.
- **Cluster DNS:** Resolves Service names (e.g., `payment.default.svc.cluster.local`) to Service ClusterIPs.
- **Cloud Control Manager** (for LoadBalancer): Integrates with cloud providers to provision external load balancers.

Service Types Overview

1. ClusterIP (Default)

Characteristics:

• ✅ Internal cluster access only
• ❌ Not accessible from outside the cluster
• 🎯 Use case: Internal microservices communication

apiVersion: v1
kind: Service
metadata:
name: payments-service
spec:
type: ClusterIP
selector:
app: payments
ports:
– port: 80
targetPort: 8080

2. NodePort

Characteristics:

• ✅ Exposes service on each node’s IP at a static port (30000-32767)
• ⚠️ Port range is random and unpredictable
• ❌ Security concerns (opening firewall ports)
• ❌ Not suitable for production

apiVersion: v1
kind: Service
metadata:
name: payments-service
spec:
type: NodePort
selector:
app: payments
ports:
– port: 80
targetPort: 8080
nodePort: 32000 # Optional, auto-assigned if not specified

How it works:

1. KubeProxy allocates a port from the node port range
2. Updates IP tables routing rules
3. Forwards traffic from NodeIP:NodePort → Service → Pods

3. LoadBalancer

Characteristics:

• ✅ Creates an external IP address
• ✅ Managed by cloud providers (AWS, Azure, GCP)
• ⚠️ One external IP per service
• ❌ Expensive at scale (200-300 services = 200-300 IPs)

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

On-Premise Alternative: MetalLB – CNCF project for bare-metal load balancing