In Kubernetes, a Service is a logical abstraction that defines a set of Pods and the policy by which to access them. Services provide stable networking endpoints for Pods, which may be ephemeral and have dynamic IP addresses, simplifying communication and load balancing.

Kubernetes offers multiple service types, each designed for specific use cases:

• Exposes the service on an internal IP accessible only within the cluster.
• Used for internal communication between components of an application.

1. Internal Access Only:
   • Accessible via ClusterIP or DNS (<service-name>.<namespace>.svc.cluster.local).
2. Traffic Routing:
   • Routes traffic to Pods using selectors and load balances using kube-proxy.
3. Dynamic IP Assignment:
   • Automatically assigned and remains stable during the Service's lifetime.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80          # Port accessible via the Service
      targetPort: 80    # Port where the container is listening

• Exposes the service externally on each node’s IP at a static port.
• Accessible via http://<NodeIP>:<NodePort>.

1. Port Range: Default range is 30000-32767.
2. Cluster-Wide Access: Available on all nodes, regardless of Pod location.
3. Traffic Routing: Routes traffic to the Service, which forwards it to Pods.

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
  namespace: default
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80          # ClusterIP service port
      targetPort: 80    # Pod's container port
      nodePort: 30080   # External node port (optional, auto-assigned if not specified)

A LoadBalancer service in Kubernetes is a Service type used to expose an application externally. It leverages the underlying cloud provider's load balancer to route traffic from an external IP address to the Kubernetes cluster. This is ideal for applications that need to be publicly accessible.

1. External Access:
   • Automatically provisions an external IP address.
   • Routes traffic from the external IP to the backend Pods.
2. Cloud Provider Dependency:
   • Available only in cloud environments that support external load balancers (e.g., AWS, Google Cloud, Azure).
3. Traffic Routing:
   • The cloud provider creates a load balancer.
   • Traffic is routed to the Kubernetes nodes, which forward it to the appropriate Pods based on the Service's configuration.
4. Ports:
   • Supports multiple ports for exposing different services.
   • Typically includes:
     • port: The port exposed by the LoadBalancer.
     • targetPort: The port on the Pods where the application is running.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - port: 80          # External LoadBalancer port
      targetPort: 80    # Pod's container port

A Headless Service is a special type of Service without a ClusterIP. It allows applications to access the individual Pods directly rather than routing through a load balancer or proxy.

1. No ClusterIP:
   • The clusterIP field is set to None, meaning Kubernetes does not assign a virtual IP for the Service.
   • Traffic is not routed through a load balancer or proxy.
2. Direct Pod Access:
   • Provides direct DNS-based discovery for individual Pods.
   • Each Pod gets its own DNS record.
3. Pod Discovery:
   • DNS queries return a list of Pod IPs instead of a single ClusterIP.
   • Useful for stateful workloads where each Pod has its own persistent data or role.
4. Selectors and Endpoints:
   • Works with selectors to match Pods, just like other Services.
   • Directly exposes the matching Pods' IPs as Endpoints.

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
    - port: 80          # Port for communication
      targetPort: 8080  # Pod's container port

• Services typically target Pods through label selectors.
• Kubernetes automatically creates and manages Endpoints, listing Pods that match the selector.

1. DNS-based Discovery: Services are accessible via DNS names like <service-name>.<namespace>.svc.cluster.local.
2. Environment Variables: Kubernetes injects environment variables with service details into Pods.

• port: The port on the Service accessible to clients.
• targetPort: The port on the Pods where traffic is forwarded.

• Ensures requests from a client are consistently routed to the same Pod (based on client IP or other criteria).
• Configured using the sessionAffinity field (None or ClientIP).

1. Load Balancing: Distribute traffic among multiple Pods.
2. Internal Communication: Facilitate communication between application components.
3. External Exposure: Use NodePort or LoadBalancer for public-facing applications.
4. Stateful Applications: Headless Services for databases or applications needing unique Pod identities.
5. Service Discovery: Enable DNS-based Pod discovery for clustered applications.

• An Ingress resource provides rules for routing HTTP/S traffic to Services.
• Useful for centralizing access to multiple backend services.

• Pods communicate using direct IPs, but Services abstract this by providing a stable endpoint.
• Ensures reliable communication even when Pods are recreated or rescheduled.

• Kubernetes supports microservices architectures with multiple Services.
• Each Service manages its own set of Pods and handles inter-service communication via DNS.