Update content/en/docs/concepts/workloads/controllers/statefulset.md
Co-authored-by: Celeste Horgan <celeste@cncf.io>
This commit is contained in:
parent
efa6ab5347
commit
3e33f7fd7c
|
@ -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/).
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue