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/).
 
-