What is the purpose of Kubernetes Service? What types are available? What are the differences between them?

A Kubernetes Service is an abstraction that defines access policies for a set of Pods. It provides stable network endpoints for Pods, ensuring service accessibility even if Pod IP addresses change.

Purpose of Service

1. Service Discovery: Service provides a unified access entry for a set of Pods. Clients do not need to know the specific Pod IP addresses.

2. Load Balancing: Service automatically distributes traffic to multiple backend Pods, implementing load balancing.

3. Stable Network Identity: Service has a fixed IP address and DNS name. Even if Pods are recreated, the Service address does not change.

Service Types

Kubernetes supports four Service types:

1. ClusterIP (default):

   • Exposes the service within the cluster
   • Can only be accessed from within the cluster
   • Suitable for communication between internal services

2. NodePort:

   • Opens a port on each Node
   • Can be accessed from outside via NodeIP:Port
   • Port range: 30000-32767

3. LoadBalancer:

   • Creates an external load balancer at the cloud provider
   • Automatically distributes traffic to NodePort
   • Requires cloud provider support

4. ExternalName:

   • Maps the service to an external DNS name
   • Does not create proxies or load balancers
   • Suitable for accessing external services

How Service Works

Service is implemented through kube-proxy:

1. iptables mode (default):

   • kube-proxy monitors API Server for Service and Endpoint changes
   • Uses iptables rules to forward traffic to backend Pods
   • Good performance, but there is latency when updating rules

2. IPVS mode:

   • Uses Linux IPVS (IP Virtual Server) to implement load balancing
   • Supports multiple load balancing algorithms (round-robin, least connections, etc.)
   • Higher performance, suitable for large-scale clusters

Service Selector

Service selects Pods to proxy through selector:

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Endpoint

The backend of Service is maintained by Endpoint objects. Endpoint contains the IP addresses and ports of all Pods that match the selector.

Service Without Selector

Service can be created without specifying a selector. In this case, you need to manually create Endpoint objects, used for:

• Accessing services outside the cluster
• Accessing services in other namespaces
• Accessing external databases, etc.

Best Practices

1. Use ClusterIP as the default type: Unless external access is needed, use ClusterIP to improve security.

2. Set sessionAffinity reasonably: For stateful applications, you can set sessionAffinity to ClientIP to implement session persistence.

3. Use Headless Service: For scenarios that require direct access to Pods (such as StatefulSet), you can use Headless Service (ClusterIP: None).

4. Monitor the health status of Service: Regularly check the status of Endpoints to ensure backend Pods are normal.

5. Use Ingress instead of LoadBalancer: For HTTP/HTTPS services, using Ingress provides more flexible management of routing and SSL.