From 15f1eeeb6358c45150582181f5c914ac5d104a2b Mon Sep 17 00:00:00 2001 From: tamilselvan1102 Date: Mon, 1 Apr 2024 14:29:44 +0530 Subject: [PATCH 1/2] Explaination about headless service --- .../en/docs/concepts/services-networking/service.md | 10 ++++++++++ .../docs/reference/labels-annotations-taints/_index.md | 3 ++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index cf2a04c82a..cbd3c32351 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -859,6 +859,16 @@ these Services, and there is no load balancing or proxying done by the platform for them. How DNS is automatically configured depends on whether the Service has selectors defined: +A headless Service allows a client to connect to whichever Pod it prefers, directly. Services that are headless don't +configure routes and packet forwarding using +[virtual IP addresses and proxies](/docs/reference/networking/virtual-ips/); instead, headless Services report the +endpoint IP addresses of the individual pods via internal DNS records, served through the cluster's +[DNS service](/docs/concepts/services-networking/dns-pod-service/). +To define a headless Service, you make a Service with `.spec.type` set to ClusterIP (which is also the default for `type`), +and you additionally set `.spec.clusterIP` to None. + +The string value None is a special case and is not the same as leaving the `.spec.clusterIP` field unset. + ### With selectors For headless Services that define selectors, the endpoints controller creates diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index 6382daa7fe..ad6ee70446 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -1001,9 +1001,10 @@ Type: Label Example: `service.kubernetes.io/headless: ""` -Used on: Service +Used on: Endpoints The control plane adds this label to an Endpoints object when the owning Service is headless. +To learn more, read [Headless Services](/docs/concepts/services-networking/service/#headless-services). ### service.kubernetes.io/topology-aware-hints (deprecated) {#servicekubernetesiotopology-aware-hints} From 83af5acf8f5263f3ecc6badbfbca81016e56311d Mon Sep 17 00:00:00 2001 From: tamilselvan1102 Date: Thu, 4 Apr 2024 09:49:21 +0530 Subject: [PATCH 2/2] moved one line down --- content/en/docs/concepts/services-networking/service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index cbd3c32351..1e32c22448 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -855,9 +855,7 @@ You can use a headless Service to interface with other service discovery mechani without being tied to Kubernetes' implementation. For headless Services, a cluster IP is not allocated, kube-proxy does not handle -these Services, and there is no load balancing or proxying done by the platform -for them. How DNS is automatically configured depends on whether the Service has -selectors defined: +these Services, and there is no load balancing or proxying done by the platform for them. A headless Service allows a client to connect to whichever Pod it prefers, directly. Services that are headless don't configure routes and packet forwarding using @@ -869,6 +867,8 @@ and you additionally set `.spec.clusterIP` to None. The string value None is a special case and is not the same as leaving the `.spec.clusterIP` field unset. +How DNS is automatically configured depends on whether the Service has selectors defined: + ### With selectors For headless Services that define selectors, the endpoints controller creates