I'm a kubernetes beginner and I found that headless service is generally recommended for stateful applications, so I'm wondering why it can't be used in stateless again? Is it bad that requests should be faster if they go directly to the Pod and not through the Service?

CodePudding user response：

1. First of all Headless services are vaguely used to access all the pod replicas directly instead of using the Services.
2. In the case of deployment(Stateless services) the pods are interchangeable because if the pod needs to reschedule it wont maintain the same id as the previous pod.
3. Whereas the Statefulsets maintain a unique ID for each pod. Statefulsets provide 2 unique identities for each pod. First Network Identity which helps us to give the same DNS name to the pod regardless of numerous restarts and second is the Storage Identity, it will also remain the same regardless of the restarts. So, statefulset won’t use the shared volume.
4. An IP address is not assigned to a headless service. Internally, it builds the required endpoints for DNS-named pod exposure.

Conclusion: Pods having a distinct identity are required for stateful applications (hostname). To communicate one pod with other pods a StatefulSet requires a Headless Service. A service with a service IP is a headless service. As a result, it immediately returns the IPs of our related pods. This enables us to communicate with the pods directly instead of using a proxy. Whereas in stateless applications a Service is required to interact with other pods.

For more detailed information refer to this article

CodePudding user response：

A regular Service provides you with a single, stable, IP address to access any of the replicas associated to the Service. Given that the application is really stateless, it does not matter which replica you talk to, so the "hiding" behind a single IP.

This relieves you of the responsibility of load balancing: You can just use the very same IP every time and don't have to handle added replicas, removed replicas or repeated DNS lookups.

If you would use a headless service for a stateless application, which is of course possible, you would have to handle all that or risk that the replicas do not deliver scaling and/or high-availability as intended. In fact a headless service shuffles the order of returned records when performing a DNS looup to help clients with the load balancing, if they can't handle it themself. But you have to perform regular DNS lookups for headless services to learn about added and/or removed instances, which is not the case for a regular service with a service IP.