From 0f8593d1b72c81286a82386352f17a61e6316acd Mon Sep 17 00:00:00 2001 From: jay vyas Date: Thu, 9 Jul 2020 17:47:08 -0400 Subject: [PATCH 1/4] Update statefulset.md --- .../en/docs/concepts/workloads/controllers/statefulset.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 4f8429d668..0611f6a9a4 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -141,6 +141,12 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. +Note initial availability of stable DNS name's responsiveness: The initial reachability of a Pod via its DNS +depends on the settings of your DNS provider. It may be 30 seconds before the DNS name for your Pod +is reachable from another Pod in your cluster. For StatefulSets which need to come online via a quorum +in a very short (< 30s) time period, consider tuning your DNS settings +or another mechanism (such as querying the Kubernetes endpoints directly for IP addresses). + As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) responsible for the network identity of the pods. From 167746be6ff3e777bc1c48bded45939e7e6ca77c Mon Sep 17 00:00:00 2001 From: jay vyas Date: Sun, 12 Jul 2020 08:20:25 -0400 Subject: [PATCH 2/4] Update content/en/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: Tim Bannister --- .../workloads/controllers/statefulset.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 0611f6a9a4..0938bd73e6 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -141,11 +141,16 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. -Note initial availability of stable DNS name's responsiveness: The initial reachability of a Pod via its DNS -depends on the settings of your DNS provider. It may be 30 seconds before the DNS name for your Pod -is reachable from another Pod in your cluster. For StatefulSets which need to come online via a quorum -in a very short (< 30s) time period, consider tuning your DNS settings -or another mechanism (such as querying the Kubernetes endpoints directly for IP addresses). +{{< note >}} +Depending on how DNS is configured in your cluster, you may not be able to look up the DNS +name for a newly-run Pod immediately. This behavior can occur when other clients in the +cluster have already sent queries for the hostname of the Pod before it was created. +Negative caching (normal in DNS) means that the results of previous failed lookups are +remembered and reused, even after the Pod is running, for at least a few seconds. + +If you need to discover Pods promptly after they are created, consider querying the +Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. +{{< /note >}} As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) @@ -285,4 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template. * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). - From efa6ab534775cd441c277d1b154d064fd179df0f Mon Sep 17 00:00:00 2001 From: jay vyas Date: Wed, 15 Jul 2020 12:39:52 -0400 Subject: [PATCH 3/4] Update statefulset.md --- .../en/docs/concepts/workloads/controllers/statefulset.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index 0938bd73e6..f1846181a0 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -148,8 +148,11 @@ cluster have already sent queries for the hostname of the Pod before it was crea Negative caching (normal in DNS) means that the results of previous failed lookups are remembered and reused, even after the Pod is running, for at least a few seconds. -If you need to discover Pods promptly after they are created, consider querying the -Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. +If you need to discover Pods promptly after they are created, you have a few options: + +- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. +- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds). + {{< /note >}} As mentioned in the [limitations](#limitations) section, you are responsible for From 3e33f7fd7cbb2b03df402c5bbca6c3bc0beaf5cf Mon Sep 17 00:00:00 2001 From: jay vyas Date: Wed, 15 Jul 2020 19:59:52 -0400 Subject: [PATCH 4/4] Update content/en/docs/concepts/workloads/controllers/statefulset.md Co-authored-by: Celeste Horgan --- content/en/docs/concepts/workloads/controllers/statefulset.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index f1846181a0..aff9e7b9f9 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -141,7 +141,6 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form: `$(podname).$(governing service domain)`, where the governing service is defined by the `serviceName` field on the StatefulSet. -{{< note >}} Depending on how DNS is configured in your cluster, you may not be able to look up the DNS name for a newly-run Pod immediately. This behavior can occur when other clients in the cluster have already sent queries for the hostname of the Pod before it was created. @@ -153,7 +152,6 @@ If you need to discover Pods promptly after they are created, you have a few opt - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. - Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds). -{{< /note >}} As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) @@ -292,4 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template. * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/). * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/). -