From d1b7a9fb4a2f5d5fe86e5c47f49e78caea77a541 Mon Sep 17 00:00:00 2001 From: Abhishek Gupta Date: Fri, 20 Mar 2015 15:28:57 -0700 Subject: [PATCH] Adding documentation for headless services --- docs/services.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/services.md b/docs/services.md index 42989d99e1e..86df68e670a 100644 --- a/docs/services.md +++ b/docs/services.md @@ -169,6 +169,22 @@ a name lookup for "my-service". `Pods` which exist in other `Namespaces` must qualify the name as "my-service.my-ns". The result of these name lookups is the virtual portal IP. +## Headless Services + +Users can create headless services by specifying "None" for the PortalIP. +For such services, an IP or DNS is not created and neither are service-specific +environment variables for the pods created. Additionally, the kube proxy does not +handle these services and there is no load balancing or proxying being done by the +platform for them. The endpoints_controller would still create endpoint records in +etcd for such services, which are also made available via the API. These services +also take advantage of any UI, readiness probes, etc. that are applicable for +services in general. + +The tradeoff for a developer would be whether to couple to the Kubernetes API or to +a particular discovery system. This API would not preclude the self-registration +approach, however, and adapters for other discovery systems could be built upon this +API, as well. + ## External Services For some parts of your application (e.g. frontends) you may want to expose a