Merge pull request #35776 from jimmycuadra/petset-rename-docs-examples

Automatic merge from submit-queue

Rename PetSet to StatefulSet in docs and examples.

**What this PR does / why we need it**: Addresses some of the pre-code-freeze changes for implementing the PetSet --> StatefulSet rename. (#35534)

**Special notes for your reviewer**: This PR only changes docs and examples, as #35731 hasn't been merged yet and I don't want to create merge conflicts. I'll open another PR for any remaining code changes needed after that PR is merged. /cc @erictune @janetkuo @chrislovecnm

docs/design/indexed-job.md

@@ -481,7 +481,7 @@ The multiple substitution approach:
 for very large jobs, the work-queue style or another type of controller, such as
 map-reduce or spark, may be a better fit.)
 - Drawback: is a form of server-side templating, which we want in Kubernetes but
-have not fully designed (see the [PetSets proposal](https://github.com/kubernetes/kubernetes/pull/18016/files?short_path=61f4179#diff-61f41798f4bced6e42e45731c1494cee)).
+have not fully designed (see the [StatefulSets proposal](https://github.com/kubernetes/kubernetes/pull/18016/files?short_path=61f4179#diff-61f41798f4bced6e42e45731c1494cee)).
 
 The index-only approach:
 
@@ -874,24 +874,24 @@ admission time; it will need to understand indexes.
 previous container failures.
 - modify the job template, affecting all indexes.
 
-#### Comparison to PetSets
+#### Comparison to StatefulSets (previously named PetSets)
 
-The *Index substitution-only* option corresponds roughly to PetSet Proposal 1b.
-The `perCompletionArgs` approach is similar to PetSet Proposal 1e, but more
+The *Index substitution-only* option corresponds roughly to StatefulSet Proposal 1b.
+The `perCompletionArgs` approach is similar to StatefulSet Proposal 1e, but more
 restrictive and thus less verbose.
 
-It would be easier for users if Indexed Job and PetSet are similar where
-possible. However, PetSet differs in several key respects:
+It would be easier for users if Indexed Job and StatefulSet are similar where
+possible. However, StatefulSet differs in several key respects:
 
-- PetSet is for ones to tens of instances.  Indexed job should work with tens of
+- StatefulSet is for ones to tens of instances.  Indexed job should work with tens of
 thousands of instances.
-- When you have few instances, you may want to given them pet names. When you
-have many instances, you that many instances, integer indexes make more sense.
+- When you have few instances, you may want to give them names. When you have many instances,
+integer indexes make more sense.
 - When you have thousands of instances, storing the work-list in the JobSpec
-is verbose.  For PetSet, this is less of a problem.
-- PetSets (apparently) need to differ in more fields than indexed Jobs.
+is verbose.  For StatefulSet, this is less of a problem.
+- StatefulSets (apparently) need to differ in more fields than indexed Jobs.
 
-This differs from PetSet in that PetSet uses names and not indexes. PetSet is
+This differs from StatefulSet in that StatefulSet uses names and not indexes. StatefulSet is
 intended to support ones to tens of things.
 
 

docs/devel/updating-docs-for-feature-changes.md

@@ -11,7 +11,7 @@ Anyone making user facing changes to kubernetes.  This is especially important f
 ### When making Api changes
 
 *e.g. adding Deployments*
-* Always make sure docs for downstream effects are updated *(PetSet -> PVC, Deployment -> ReplicationController)*
+* Always make sure docs for downstream effects are updated *(StatefulSet -> PVC, Deployment -> ReplicationController)*
 * Add or update the corresponding *[Glossary](http://kubernetes.io/docs/reference/)* item
 * Verify the guides / walkthroughs do not require any changes:
   * **If your change will be recommended over the approaches shown in these guides, then they must be updated to reflect your change**

docs/proposals/image-provenance.md

@@ -165,7 +165,7 @@ due to a CVE that just came out (fictional scenario).  In this scenario:
   up and not scale down the old one.
 - an existing replicaSet will be unable to create Pods that replace ones which are terminated.  If this is due to
   slow loss of nodes, then there should be time to react before significant loss of capacity.
-- For non-replicated things (size 1 ReplicaSet, PetSet), a single node failure may disable it.
+- For non-replicated things (size 1 ReplicaSet, StatefulSet), a single node failure may disable it.
 - a node rolling update will eventually check for liveness of replacements, and would be throttled if
   in the case when the image was no longer allowed and so replacements could not be started.
 - rapid node restarts will cause existing pod objects to be restarted by kubelet.

docs/proposals/synchronous-garbage-collection.md

@@ -158,7 +158,7 @@ Finalizer breaks an assumption that many Kubernetes components have: a deletion
 
 **Replication controller manager**, **Job controller**, and **ReplicaSet controller** ignore pods in terminated phase, so pods with pending finalizers will not block these controllers.
 
-**PetSet controller** will be blocked by a pod with pending finalizers, so synchronous GC might slow down its progress.
+**StatefulSet controller** will be blocked by a pod with pending finalizers, so synchronous GC might slow down its progress.
 
 **kubectl**: synchronous GC can simplify the **kubectl delete** reapers. Let's take the `deployment reaper` as an example, since it's the most complicated one. Currently, the reaper finds all `RS` with matching labels, scales them down, polls until `RS.Status.Replica` reaches 0, deletes the `RS`es, and finally deletes the `deployment`. If using synchronous GC, `kubectl delete deployment` is as easy as sending a synchronous GC delete request for the deployment, and polls until the deployment is deleted from the key-value store.
 

docs/proposals/templates.md

@@ -11,7 +11,7 @@ There are two main motivators for Template functionality in Kubernetes:  Control
 Today the replication controller defines a PodTemplate which allows it to instantiate multiple pods with identical characteristics.
 This is useful but limited.  Stateful applications have a need to instantiate multiple instances of a more sophisticated topology
 than just a single pod (e.g. they also need Volume definitions).  A Template concept would allow a Controller to stamp out multiple
-instances of a given Template definition.  This capability would be immediately useful to the [PetSet](https://github.com/kubernetes/kubernetes/pull/18016) proposal.
+instances of a given Template definition.  This capability would be immediately useful to the [StatefulSet](https://github.com/kubernetes/kubernetes/pull/18016) proposal.
 
 Similarly the [Service Catalog proposal](https://github.com/kubernetes/kubernetes/pull/17543) could leverage template instantiation as a mechanism for claiming service instances.
 
@@ -47,7 +47,7 @@ values are appropriate for a deployer to tune or what the parameters control.
 * Providing a library of predefined application definitions that users can select from
 * Enabling the creation of user interfaces that can guide an application deployer through the deployment process with descriptive help about the configuration value decisions they are making, and useful default values where appropriate
 * Exporting a set of objects in a namespace as a template so the topology can be inspected/visualized or recreated in another environment
-* Controllers that need to instantiate multiple instances of identical objects (e.g. PetSets).
+* Controllers that need to instantiate multiple instances of identical objects (e.g. StatefulSets).
 
 
 ### Use cases for parameters within templates
@@ -65,7 +65,7 @@ values are appropriate for a deployer to tune or what the parameters control.
   a pod as a TLS cert).
 * Provide guidance to users for parameters such as default values, descriptions, and whether or not a particular parameter value
   is required or can be left blank.
-* Parameterize the replica count of a deployment or [PetSet](https://github.com/kubernetes/kubernetes/pull/18016)
+* Parameterize the replica count of a deployment or [StatefulSet](https://github.com/kubernetes/kubernetes/pull/18016)
 * Parameterize part of the labels and selector for a DaemonSet
 * Parameterize quota/limit values for a pod
 * Parameterize a secret value so a user can provide a custom password or other secret at deployment time