Skip to content

Commit 78959d1

Browse files
authored
Merge pull request #37258 from mariuskimmina/patch-2
Update statefulset.md - Matching lowercase c in Controller to the rest of the documentation
2 parents b4c4cbd + 0fead5c commit 78959d1

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

content/en/docs/concepts/workloads/controllers/statefulset.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -148,7 +148,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
148148

149149
## Pod Identity
150150

151-
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
151+
StatefulSet Pods have a unique identity that consists of an ordinal, a
152152
stable network identity, and stable storage. The identity sticks to the Pod,
153153
regardless of which node it's (re)scheduled on.
154154

@@ -214,7 +214,7 @@ This must be done manually.
214214

215215
### Pod Name Label
216216

217-
When the StatefulSet {{< glossary_tooltip term_id="controller" >}} creates a Pod,
217+
When the StatefulSet {{<glossary_tooltip text="controller" term_id="controller">}} creates a Pod,
218218
it adds a label, `statefulset.kubernetes.io/pod-name`, that is set to the name of
219219
the Pod. This label allows you to attach a Service to a specific Pod in
220220
the StatefulSet.
@@ -274,7 +274,7 @@ annotations for the Pods in a StatefulSet. There are two possible values:
274274
create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
275275

276276
`RollingUpdate`
277-
: The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
277+
: The `RollingUpdate` update strategy implements automated, rolling updates for the Pods in a
278278
StatefulSet. This is the default update strategy.
279279

280280
## Rolling Updates
@@ -416,7 +416,7 @@ owner reference has been updated appropriate to the policy. If a condemned Pod i
416416
force-deleted while the controller is down, the owner reference may or may not have been
417417
set up, depending on when the controller crashed. It may take several reconcile loops to
418418
update the owner references, so some condemned Pods may have set up owner references and
419-
other may not. For this reason we recommend waiting for the controller to come back up,
419+
others may not. For this reason we recommend waiting for the controller to come back up,
420420
which will verify owner references before terminating Pods. If that is not possible, the
421421
operator should verify the owner references on PVCs to ensure the expected objects are
422422
deleted when Pods are force-deleted.

0 commit comments

Comments
 (0)