kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #37258 from mariuskimmina/patch-2 

Update statefulset.md - Matching lowercase c in Controller to the rest of the documentation
This commit is contained in:
Kubernetes Prow Robot 2022-10-23 19:22:26 -07:00 committed by GitHub
parent b4c4cbd5d0 0fead5cf46
commit 78959d1a12
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
content/en/docs/concepts/workloads/controllers/statefulset.md
View File

@ -148,7 +148,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
## Pod Identity
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
StatefulSet Pods have a unique identity that consists of an ordinal, a
stable network identity, and stable storage. The identity sticks to the Pod,
regardless of which node it's (re)scheduled on.
@ -214,7 +214,7 @@ This must be done manually.
### Pod Name Label
When the StatefulSet {{< glossary_tooltip term_id="controller" >}} creates a Pod,
When the StatefulSet {{<glossary_tooltip text="controller" term_id="controller">}} creates a Pod,
it adds a label, `statefulset.kubernetes.io/pod-name`, that is set to the name of
the Pod. This label allows you to attach a Service to a specific Pod in
the StatefulSet.
@ -274,7 +274,7 @@ annotations for the Pods in a StatefulSet. There are two possible values:
create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
`RollingUpdate`
: The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
: The `RollingUpdate` update strategy implements automated, rolling updates for the Pods in a
StatefulSet. This is the default update strategy.
## Rolling Updates
@ -416,7 +416,7 @@ owner reference has been updated appropriate to the policy. If a condemned Pod i
force-deleted while the controller is down, the owner reference may or may not have been
set up, depending on when the controller crashed. It may take several reconcile loops to
update the owner references, so some condemned Pods may have set up owner references and
other may not. For this reason we recommend waiting for the controller to come back up,
others may not. For this reason we recommend waiting for the controller to come back up,
which will verify owner references before terminating Pods. If that is not possible, the
operator should verify the owner references on PVCs to ensure the expected objects are
deleted when Pods are force-deleted.