# Kubernetes Service Types

This document explains the different Kubernetes Service types, their purpose, and how to use them on an **E2E Kubernetes Cluster**.

## 1. ClusterIP Service

### What is ClusterIP?

**ClusterIP** is the default Kubernetes Service type. It exposes an application **only inside the Kubernetes cluster**.

The service is assigned a **stable internal IP address and DNS name**, which other services within the cluster can use to communicate.

### Why Use ClusterIP?

- Enables internal communication between services
- Prevents external access to Pods
- Provides service discovery using Kubernetes DNS
- Recommended for backend and internal APIs

### When to Use ClusterIP?

Use ClusterIP when:

- A frontend service communicates with a backend service
- Microservices need internal communication
- The application should not be exposed publicly

### Example: ClusterIP Service

```yaml
apiVersion: v1
kind: Service
metadata:
  name: backend-clusterip
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 80
```

Apply the manifest:

```bash
kubectl apply -f cluster-ip.yaml
```

Verify the service:

```bash
kubectl get svc
```

{/* TODO: Add screenshot of kubectl get svc showing ClusterIP service */}

Access from within the cluster:

```
http://backend-clusterip
```

## 2. NodePort Service

### What is NodePort?

**NodePort** exposes a service on a **static port on every worker node**.

Traffic sent to `<Node-IP>:<NodePort>` is forwarded to the service and then routed to the backend Pods.

### Why Use NodePort?

- Provides simple external access without a load balancer
- Useful for testing and debugging
- Works in environments without cloud load balancers

### When to Use NodePort?

Use NodePort when:

- Quick external access is required
- Testing or troubleshooting applications
- Production-grade load balancing is not required

> **Note:** NodePort is not recommended for production workloads.

### Example: NodePort Service

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080
```

Apply the manifest:

```bash
kubectl apply -f node-port.yaml
```

Verify the service:

```bash
kubectl get svc
```

{/* TODO: Add screenshot of kubectl get svc showing NodePort service */}

> **Note:** E2E Kubernetes worker nodes do not have public IP addresses by default. NodePort access is typically not available.

## 3. LoadBalancer Service

### What is LoadBalancer?

**LoadBalancer** exposes an application using a **cloud-managed load balancer**.

On E2E Kubernetes, this automatically:

- Provisions a cloud load balancer
- Assigns a public IP address
- Routes traffic to healthy Pods

### Why Use a LoadBalancer?

- Production-ready external access
- Automatic traffic distribution
- High availability
- Integrates with cloud networking and firewall rules

### When to Use a LoadBalancer?

Use LoadBalancer when:

- The application must be accessible from the internet
- Running production workloads
- A stable public IP address is required

### Example: LoadBalancer Service

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: frontendapp
  ports:
    - port: 80
      targetPort: 80
```

Apply the manifest:

```bash
kubectl apply -f loadbalancer.yaml
```

Check the assigned external IP:

```bash
kubectl get svc
```

{/* TODO: Add screenshot of kubectl get svc showing EXTERNAL-IP in Pending state */}

## Assigning an External IP for LoadBalancer Service on E2E Kubernetes

E2E Kubernetes implements `LoadBalancer` Services with [MetalLB](https://metallb.universe.org/). MetalLB hands out external IPs from a **pool of reserved IPs** attached to your cluster. You manage that pool from the E2E Dashboard.

The key consequence is:

- If the pool has a **free IP**, MetalLB assigns it to a new LoadBalancer Service **automatically and immediately** - no per-service action is needed.
- The `EXTERNAL-IP` stays in the `Pending` state **only when the pool has no free IP** (none reserved yet, or all reserved IPs are already in use). In that case the Service emits an event like `AllocationFailed ... no available IPs`.

So the task is not to assign an IP to a specific Service - it is to make sure the cluster's IP pool always has at least as many free IPs as you have LoadBalancer Services.

### Reserve IPs for the Cluster Pool from the E2E Dashboard

1. Log in to the [E2E Cloud Dashboard](https://myaccount.e2enetworks.com).
2. Navigate to **Kubernetes** and select your cluster.
3. Open the **LB-IP-Pool** section.
4. Click **Reserve New Service IP**.
5. Select an available IP address.
6. Click **Attach IP** to add the IP to the cluster's MetalLB pool.

Once an IP is in the pool, MetalLB assigns it to a LoadBalancer Service that needs one. If a LoadBalancer Service was already `Pending`, it picks up the newly reserved IP within a few seconds - no need to recreate it.

### Important Notes

- Each **LoadBalancer Service** consumes **one** IP from the pool.
- To run _N_ LoadBalancer Services simultaneously, reserve at least _N_ IPs into the pool. Reserving a single IP and creating a second LoadBalancer Service leaves the second one `Pending` with an `AllocationFailed` event.
- Ingress controllers and Gateways (NGINX Ingress, Istio ingress gateway, Envoy Gateway, etc.) are themselves exposed through a LoadBalancer Service, so each one also consumes a pool IP. A single shared Ingress/Gateway is the most IP-efficient way to expose many applications.

### Verify External IP Assignment

Run the following command:

```bash
kubectl get svc
```

The `EXTERNAL-IP` field should display the assigned IP address. If it shows `<pending>`, inspect the Service events to confirm whether the pool is exhausted:

```bash
kubectl describe svc <service-name>
```

### Access the Application

```
http://<External-IP>
```

## Why LoadBalancer Alone Is Not Sufficient

A LoadBalancer Service:

- Exposes one service per public IP address
- Supports basic TCP and HTTP traffic forwarding
- Does not provide advanced routing capabilities

### Limitations of Using Only LoadBalancer

- No support for host-based or path-based routing
- No centralized TLS certificate management
- No advanced traffic control such as canary deployments, blue-green deployments, or rate limiting

For these reasons, a LoadBalancer Service is typically used as a **foundation for external connectivity**, rather than a complete traffic management solution.

For more reference, see the [Kubernetes Services documentation](https://kubernetes.io/docs/concepts/services-networking/service/).

## Next Steps: Ingress and Gateway API

In the next sections, explore [NGINX Ingress Controller](/docs/myaccount/kubernetes/guides/nginx-ingress-controller/) and [Kubernetes Gateway API](/docs/myaccount/kubernetes/guides/gateway-api/), which build on top of the LoadBalancer and provide advanced routing, TLS termination, and traffic management capabilities for applications running on E2E Kubernetes.

---