From bef91e9b26008a64a5b89f68da1e5f7f8b5bc91b Mon Sep 17 00:00:00 2001 From: Kenneth Owens Date: Fri, 2 Dec 2016 09:53:04 -0800 Subject: [PATCH] Changes cleanup instructions to account for both dynamic and manual provisioning Clarifies network discovery Adds statement about mutability of spec.template.containers --- .../basic-stateful-set.md | 26 ++++++++++++------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md index 45ff688d5a..64d86c1cca 100644 --- a/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/docs/tutorials/stateful-application/basic-stateful-set.md @@ -237,17 +237,19 @@ but the IP addresses associated with the Pods may have changed. In the cluster used for this tutorial, they have. This is why it is important not to configure other applications to connect to Pods in a StatefulSet by IP address. + If you need to find and connect to the active members of a StatefulSet, you should query the CNAME of the Headless Service -(e.g. `nginx.default.svc.cluster.local`). The SRV records associated with the +(`nginx.default.svc.cluster.local`). The SRV records associated with the CNAME will contain only the Pods in the StatefulSet that are Running and Ready. -Alternatively, if you only need a predefined set of addresses, for instance if -your application already implements connection logic that tests for -liveness and readiness, you should use the SRV records of the Pods in the -StatefulSet (e.g `web-0.nginx.default.svc.cluster.local`, -`web-1.nginx.default.svc.cluster.local`). +If your application already implements connection logic that tests for +liveness and readiness, you can use the SRV records of the Pods ( +`web-0.nginx.default.svc.cluster.local`, +`web-1.nginx.default.svc.cluster.local`), as they are stable, and your +application will be able to discover the Pods' addresses when they transition +to Running and Ready. #### Stable Storage @@ -435,7 +437,10 @@ the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. This feature can be used to facilitate upgrading the container images of Pods in a StatefulSet. -### Upgrading Container Images +### Updating Containers +As demonstrated in the [Scaling a StatefulSet](#scaling-a-statefulset) section, +the `replicas` field of a StatefulSet is mutable. The only other field of a +StatefulSet that can be updated is the `spec.template.containers` field. StatefulSet currently *does not* support automated image upgrade. However, you can update the `image` field of any container in the podTemplate and delete @@ -720,9 +725,10 @@ statefulset "web" deleted {% endcapture %} {% capture cleanup %} -Whether your cluster was configured to use dynamic provisioning or you used -manually provisioned volumes, you will need to manually delete the five 1 GiB -PersistentVolumes that were provisioned for this tutorial. +You will need to delete the persistent storage media for the PersistentVolumes +used in this tutorial. Follow the necessary steps, based on your environment, +storage configuration, and provisioning method, to ensure that all storage is +reclaimed. {% endcapture %} {% include templates/tutorial.md %} \ No newline at end of file