Tidy whitespace
This commit is contained in:
@@ -13,13 +13,12 @@ weight: 10
|
|||||||
|
|
||||||
<!-- overview -->
|
<!-- overview -->
|
||||||
This tutorial provides an introduction to managing applications with
|
This tutorial provides an introduction to managing applications with
|
||||||
[StatefulSets](/docs/concepts/workloads/controllers/statefulset/). It
|
[StatefulSets](/docs/concepts/workloads/controllers/statefulset/). It
|
||||||
demonstrates how to create, delete, scale, and update the Pods of StatefulSets.
|
demonstrates how to create, delete, scale, and update the Pods of StatefulSets.
|
||||||
|
|
||||||
|
|
||||||
## {{% heading "prerequisites" %}}
|
## {{% heading "prerequisites" %}}
|
||||||
|
|
||||||
Before you begin this tutorial, you should familiarize yourself with the
|
Before you begin this tutorial, you should familiarize yourself with the
|
||||||
following Kubernetes concepts.
|
following Kubernetes concepts.
|
||||||
|
|
||||||
* [Pods](/docs/concepts/workloads/pods/)
|
* [Pods](/docs/concepts/workloads/pods/)
|
||||||
@@ -30,18 +29,17 @@ following Kubernetes concepts.
|
|||||||
* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
* [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
||||||
* [kubectl CLI](/docs/user-guide/kubectl/)
|
* [kubectl CLI](/docs/user-guide/kubectl/)
|
||||||
|
|
||||||
This tutorial assumes that your cluster is configured to dynamically provision
|
This tutorial assumes that your cluster is configured to dynamically provision
|
||||||
PersistentVolumes. If your cluster is not configured to do so, you
|
PersistentVolumes. If your cluster is not configured to do so, you
|
||||||
will have to manually provision two 1 GiB volumes prior to starting this
|
will have to manually provision two 1 GiB volumes prior to starting this
|
||||||
tutorial.
|
tutorial.
|
||||||
|
|
||||||
|
|
||||||
## {{% heading "objectives" %}}
|
## {{% heading "objectives" %}}
|
||||||
|
|
||||||
StatefulSets are intended to be used with stateful applications and distributed
|
StatefulSets are intended to be used with stateful applications and distributed
|
||||||
systems. However, the administration of stateful applications and
|
systems. However, the administration of stateful applications and
|
||||||
distributed systems on Kubernetes is a broad, complex topic. In order to
|
distributed systems on Kubernetes is a broad, complex topic. In order to
|
||||||
demonstrate the basic features of a StatefulSet, and not to conflate the former
|
demonstrate the basic features of a StatefulSet, and not to conflate the former
|
||||||
topic with the latter, you will deploy a simple web application using a StatefulSet.
|
topic with the latter, you will deploy a simple web application using a StatefulSet.
|
||||||
|
|
||||||
After this tutorial, you will be familiar with the following.
|
After this tutorial, you will be familiar with the following.
|
||||||
@@ -52,29 +50,29 @@ After this tutorial, you will be familiar with the following.
|
|||||||
* How to scale a StatefulSet
|
* How to scale a StatefulSet
|
||||||
* How to update a StatefulSet's Pods
|
* How to update a StatefulSet's Pods
|
||||||
|
|
||||||
|
|
||||||
<!-- lessoncontent -->
|
<!-- lessoncontent -->
|
||||||
## Creating a StatefulSet
|
|
||||||
|
|
||||||
Begin by creating a StatefulSet using the example below. It is similar to the
|
## Creating a StatefulSet
|
||||||
|
|
||||||
|
Begin by creating a StatefulSet using the example below. It is similar to the
|
||||||
example presented in the
|
example presented in the
|
||||||
[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept.
|
[StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept.
|
||||||
It creates a [Headless Service](/docs/concepts/services-networking/service/#headless-services),
|
It creates a [Headless Service](/docs/concepts/services-networking/service/#headless-services),
|
||||||
`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`.
|
`nginx`, to publish the IP addresses of Pods in the StatefulSet, `web`.
|
||||||
|
|
||||||
{{< codenew file="application/web/web.yaml" >}}
|
{{< codenew file="application/web/web.yaml" >}}
|
||||||
|
|
||||||
Download the example above, and save it to a file named `web.yaml`
|
Download the example above, and save it to a file named `web.yaml`
|
||||||
|
|
||||||
You will need to use two terminal windows. In the first terminal, use
|
You will need to use two terminal windows. In the first terminal, use
|
||||||
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation
|
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the creation
|
||||||
of the StatefulSet's Pods.
|
of the StatefulSet's Pods.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pods -w -l app=nginx
|
kubectl get pods -w -l app=nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
In the second terminal, use
|
In the second terminal, use
|
||||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to create the
|
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) to create the
|
||||||
Headless Service and StatefulSet defined in `web.yaml`.
|
Headless Service and StatefulSet defined in `web.yaml`.
|
||||||
|
|
||||||
@@ -84,8 +82,8 @@ service/nginx created
|
|||||||
statefulset.apps/web created
|
statefulset.apps/web created
|
||||||
```
|
```
|
||||||
|
|
||||||
The command above creates two Pods, each running an
|
The command above creates two Pods, each running an
|
||||||
[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service and the
|
[NGINX](https://www.nginx.com) webserver. Get the `nginx` Service and the
|
||||||
`web` StatefulSet to verify that they were created successfully.
|
`web` StatefulSet to verify that they were created successfully.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -100,9 +98,9 @@ web 2 1 20s
|
|||||||
|
|
||||||
### Ordered Pod Creation
|
### Ordered Pod Creation
|
||||||
|
|
||||||
For a StatefulSet with N replicas, when Pods are being deployed, they are
|
For a StatefulSet with N replicas, when Pods are being deployed, they are
|
||||||
created sequentially, in order from {0..N-1}. Examine the output of the
|
created sequentially, in order from {0..N-1}. Examine the output of the
|
||||||
`kubectl get` command in the first terminal. Eventually, the output will
|
`kubectl get` command in the first terminal. Eventually, the output will
|
||||||
look like the example below.
|
look like the example below.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -118,8 +116,8 @@ web-1 0/1 ContainerCreating 0 0s
|
|||||||
web-1 1/1 Running 0 18s
|
web-1 1/1 Running 0 18s
|
||||||
```
|
```
|
||||||
|
|
||||||
Notice that the `web-1` Pod is not launched until the `web-0` Pod is
|
Notice that the `web-1` Pod is not launched until the `web-0` Pod is
|
||||||
[Running and Ready](/docs/user-guide/pod-states).
|
[Running and Ready](/docs/user-guide/pod-states).
|
||||||
|
|
||||||
## Pods in a StatefulSet
|
## Pods in a StatefulSet
|
||||||
|
|
||||||
@@ -137,18 +135,18 @@ web-1 1/1 Running 0 1m
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/)
|
||||||
concept, the Pods in a StatefulSet have a sticky, unique identity. This identity
|
concept, the Pods in a StatefulSet have a sticky, unique identity. This identity
|
||||||
is based on a unique ordinal index that is assigned to each Pod by the
|
is based on a unique ordinal index that is assigned to each Pod by the
|
||||||
StatefulSet controller. The Pods' names take the form
|
StatefulSet controller. The Pods' names take the form
|
||||||
`<statefulset name>-<ordinal index>`. Since the `web` StatefulSet has two
|
`<statefulset name>-<ordinal index>`. Since the `web` StatefulSet has two
|
||||||
replicas, it creates two Pods, `web-0` and `web-1`.
|
replicas, it creates two Pods, `web-0` and `web-1`.
|
||||||
|
|
||||||
### Using Stable Network Identities
|
### Using Stable Network Identities
|
||||||
|
|
||||||
Each Pod has a stable hostname based on its ordinal index. Use
|
Each Pod has a stable hostname based on its ordinal index. Use
|
||||||
[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the
|
[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) to execute the
|
||||||
`hostname` command in each Pod.
|
`hostname` command in each Pod.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
||||||
@@ -156,9 +154,9 @@ web-0
|
|||||||
web-1
|
web-1
|
||||||
```
|
```
|
||||||
|
|
||||||
Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute
|
Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute
|
||||||
a container that provides the `nslookup` command from the `dnsutils` package.
|
a container that provides the `nslookup` command from the `dnsutils` package.
|
||||||
Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS
|
Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS
|
||||||
addresses.
|
addresses.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -178,17 +176,17 @@ Name: web-1.nginx
|
|||||||
Address 1: 10.244.2.6
|
Address 1: 10.244.2.6
|
||||||
```
|
```
|
||||||
|
|
||||||
The CNAME of the headless service points to SRV records (one for each Pod that
|
The CNAME of the headless service points to SRV records (one for each Pod that
|
||||||
is Running and Ready). The SRV records point to A record entries that
|
is Running and Ready). The SRV records point to A record entries that
|
||||||
contain the Pods' IP addresses.
|
contain the Pods' IP addresses.
|
||||||
|
|
||||||
In one terminal, watch the StatefulSet's Pods.
|
In one terminal, watch the StatefulSet's Pods.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pod -w -l app=nginx
|
kubectl get pod -w -l app=nginx
|
||||||
```
|
```
|
||||||
In a second terminal, use
|
In a second terminal, use
|
||||||
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all
|
[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete all
|
||||||
the Pods in the StatefulSet.
|
the Pods in the StatefulSet.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -197,7 +195,7 @@ pod "web-0" deleted
|
|||||||
pod "web-1" deleted
|
pod "web-1" deleted
|
||||||
```
|
```
|
||||||
|
|
||||||
Wait for the StatefulSet to restart them, and for both Pods to transition to
|
Wait for the StatefulSet to restart them, and for both Pods to transition to
|
||||||
Running and Ready.
|
Running and Ready.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -212,7 +210,7 @@ web-1 0/1 ContainerCreating 0 0s
|
|||||||
web-1 1/1 Running 0 34s
|
web-1 1/1 Running 0 34s
|
||||||
```
|
```
|
||||||
|
|
||||||
Use `kubectl exec` and `kubectl run` to view the Pods hostnames and in-cluster
|
Use `kubectl exec` and `kubectl run` to view the Pods hostnames and in-cluster
|
||||||
DNS entries.
|
DNS entries.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -220,7 +218,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
|
|||||||
web-0
|
web-0
|
||||||
web-1
|
web-1
|
||||||
|
|
||||||
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
|
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh
|
||||||
nslookup web-0.nginx
|
nslookup web-0.nginx
|
||||||
Server: 10.0.0.10
|
Server: 10.0.0.10
|
||||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||||
@@ -236,23 +234,23 @@ Name: web-1.nginx
|
|||||||
Address 1: 10.244.2.8
|
Address 1: 10.244.2.8
|
||||||
```
|
```
|
||||||
|
|
||||||
The Pods' ordinals, hostnames, SRV records, and A record names have not changed,
|
The Pods' ordinals, hostnames, SRV records, and A record names have not changed,
|
||||||
but the IP addresses associated with the Pods may have changed. In the cluster
|
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
|
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.
|
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
|
If you need to find and connect to the active members of a StatefulSet, you
|
||||||
should query the CNAME of the Headless Service
|
should query the CNAME of the Headless Service
|
||||||
(`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
|
CNAME will contain only the Pods in the StatefulSet that are Running and
|
||||||
Ready.
|
Ready.
|
||||||
|
|
||||||
If your application already implements connection logic that tests for
|
If your application already implements connection logic that tests for
|
||||||
liveness and readiness, you can use the SRV records of the Pods (
|
liveness and readiness, you can use the SRV records of the Pods (
|
||||||
`web-0.nginx.default.svc.cluster.local`,
|
`web-0.nginx.default.svc.cluster.local`,
|
||||||
`web-1.nginx.default.svc.cluster.local`), as they are stable, and your
|
`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
|
application will be able to discover the Pods' addresses when they transition
|
||||||
to Running and Ready.
|
to Running and Ready.
|
||||||
|
|
||||||
### Writing to Stable Storage
|
### Writing to Stable Storage
|
||||||
@@ -265,16 +263,16 @@ NAME STATUS VOLUME CAPACITY ACCE
|
|||||||
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
|
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
|
||||||
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
|
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
|
||||||
```
|
```
|
||||||
The StatefulSet controller created two PersistentVolumeClaims that are
|
The StatefulSet controller created two PersistentVolumeClaims that are
|
||||||
bound to two [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). As the cluster used in this tutorial is configured to dynamically provision
|
bound to two [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). As the cluster used in this tutorial is configured to dynamically provision
|
||||||
PersistentVolumes, the PersistentVolumes were created and bound automatically.
|
PersistentVolumes, the PersistentVolumes were created and bound automatically.
|
||||||
|
|
||||||
The NGINX webservers, by default, will serve an index file at
|
The NGINX webservers, by default, will serve an index file at
|
||||||
`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the
|
`/usr/share/nginx/html/index.html`. The `volumeMounts` field in the
|
||||||
StatefulSets `spec` ensures that the `/usr/share/nginx/html` directory is
|
StatefulSets `spec` ensures that the `/usr/share/nginx/html` directory is
|
||||||
backed by a PersistentVolume.
|
backed by a PersistentVolume.
|
||||||
|
|
||||||
Write the Pods' hostnames to their `index.html` files and verify that the NGINX
|
Write the Pods' hostnames to their `index.html` files and verify that the NGINX
|
||||||
webservers serve the hostnames.
|
webservers serve the hostnames.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -310,7 +308,7 @@ kubectl delete pod -l app=nginx
|
|||||||
pod "web-0" deleted
|
pod "web-0" deleted
|
||||||
pod "web-1" deleted
|
pod "web-1" deleted
|
||||||
```
|
```
|
||||||
Examine the output of the `kubectl get` command in the first terminal, and wait
|
Examine the output of the `kubectl get` command in the first terminal, and wait
|
||||||
for all of the Pods to transition to Running and Ready.
|
for all of the Pods to transition to Running and Ready.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -333,14 +331,14 @@ web-0
|
|||||||
web-1
|
web-1
|
||||||
```
|
```
|
||||||
|
|
||||||
Even though `web-0` and `web-1` were rescheduled, they continue to serve their
|
Even though `web-0` and `web-1` were rescheduled, they continue to serve their
|
||||||
hostnames because the PersistentVolumes associated with their
|
hostnames because the PersistentVolumes associated with their
|
||||||
PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what
|
PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what
|
||||||
node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be
|
node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be
|
||||||
mounted to the appropriate mount points.
|
mounted to the appropriate mount points.
|
||||||
|
|
||||||
## Scaling a StatefulSet
|
## Scaling a StatefulSet
|
||||||
Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
|
Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
|
||||||
This is accomplished by updating the `replicas` field. You can use either
|
This is accomplished by updating the `replicas` field. You can use either
|
||||||
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) or
|
[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) or
|
||||||
[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) to scale a StatefulSet.
|
[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) to scale a StatefulSet.
|
||||||
@@ -353,7 +351,7 @@ In one terminal window, watch the Pods in the StatefulSet.
|
|||||||
kubectl get pods -w -l app=nginx
|
kubectl get pods -w -l app=nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
In another terminal window, use `kubectl scale` to scale the number of replicas
|
In another terminal window, use `kubectl scale` to scale the number of replicas
|
||||||
to 5.
|
to 5.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -361,7 +359,7 @@ kubectl scale sts web --replicas=5
|
|||||||
statefulset.apps/web scaled
|
statefulset.apps/web scaled
|
||||||
```
|
```
|
||||||
|
|
||||||
Examine the output of the `kubectl get` command in the first terminal, and wait
|
Examine the output of the `kubectl get` command in the first terminal, and wait
|
||||||
for the three additional Pods to transition to Running and Ready.
|
for the three additional Pods to transition to Running and Ready.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -386,8 +384,8 @@ web-4 1/1 Running 0 19s
|
|||||||
|
|
||||||
The StatefulSet controller scaled the number of replicas. As with
|
The StatefulSet controller scaled the number of replicas. As with
|
||||||
[StatefulSet creation](#ordered-pod-creation), the StatefulSet controller
|
[StatefulSet creation](#ordered-pod-creation), the StatefulSet controller
|
||||||
created each Pod sequentially with respect to its ordinal index, and it
|
created each Pod sequentially with respect to its ordinal index, and it
|
||||||
waited for each Pod's predecessor to be Running and Ready before launching the
|
waited for each Pod's predecessor to be Running and Ready before launching the
|
||||||
subsequent Pod.
|
subsequent Pod.
|
||||||
|
|
||||||
### Scaling Down
|
### Scaling Down
|
||||||
@@ -398,7 +396,7 @@ In one terminal, watch the StatefulSet's Pods.
|
|||||||
kubectl get pods -w -l app=nginx
|
kubectl get pods -w -l app=nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
In another terminal, use `kubectl patch` to scale the StatefulSet back down to
|
In another terminal, use `kubectl patch` to scale the StatefulSet back down to
|
||||||
three replicas.
|
three replicas.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -426,11 +424,11 @@ web-3 1/1 Terminating 0 42s
|
|||||||
|
|
||||||
### Ordered Pod Termination
|
### Ordered Pod Termination
|
||||||
|
|
||||||
The controller deleted one Pod at a time, in reverse order with respect to its
|
The controller deleted one Pod at a time, in reverse order with respect to its
|
||||||
ordinal index, and it waited for each to be completely shutdown before
|
ordinal index, and it waited for each to be completely shutdown before
|
||||||
deleting the next.
|
deleting the next.
|
||||||
|
|
||||||
Get the StatefulSet's PersistentVolumeClaims.
|
Get the StatefulSet's PersistentVolumeClaims.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl get pvc -l app=nginx
|
kubectl get pvc -l app=nginx
|
||||||
@@ -443,23 +441,23 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
There are still five PersistentVolumeClaims and five PersistentVolumes.
|
There are still five PersistentVolumeClaims and five PersistentVolumes.
|
||||||
When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down.
|
When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when the StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down.
|
||||||
|
|
||||||
## Updating StatefulSets
|
## Updating StatefulSets
|
||||||
|
|
||||||
In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The
|
In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The
|
||||||
strategy used is determined by the `spec.updateStrategy` field of the
|
strategy used is determined by the `spec.updateStrategy` field of the
|
||||||
StatefulSet API Object. This feature can be used to upgrade the container
|
StatefulSet API Object. This feature can be used to upgrade the container
|
||||||
images, resource requests and/or limits, labels, and annotations of the Pods in a
|
images, resource requests and/or limits, labels, and annotations of the Pods in a
|
||||||
StatefulSet. There are two valid update strategies, `RollingUpdate` and
|
StatefulSet. There are two valid update strategies, `RollingUpdate` and
|
||||||
`OnDelete`.
|
`OnDelete`.
|
||||||
|
|
||||||
`RollingUpdate` update strategy is the default for StatefulSets.
|
`RollingUpdate` update strategy is the default for StatefulSets.
|
||||||
|
|
||||||
### Rolling Update
|
### Rolling Update
|
||||||
|
|
||||||
The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in
|
The `RollingUpdate` update strategy will update all Pods in a StatefulSet, in
|
||||||
reverse ordinal order, while respecting the StatefulSet guarantees.
|
reverse ordinal order, while respecting the StatefulSet guarantees.
|
||||||
|
|
||||||
Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy.
|
Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy.
|
||||||
@@ -469,7 +467,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda
|
|||||||
statefulset.apps/web patched
|
statefulset.apps/web patched
|
||||||
```
|
```
|
||||||
|
|
||||||
In one terminal window, patch the `web` StatefulSet to change the container
|
In one terminal window, patch the `web` StatefulSet to change the container
|
||||||
image again.
|
image again.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -515,15 +513,15 @@ web-0 0/1 ContainerCreating 0 0s
|
|||||||
web-0 1/1 Running 0 10s
|
web-0 1/1 Running 0 10s
|
||||||
```
|
```
|
||||||
|
|
||||||
The Pods in the StatefulSet are updated in reverse ordinal order. The
|
The Pods in the StatefulSet are updated in reverse ordinal order. The
|
||||||
StatefulSet controller terminates each Pod, and waits for it to transition to Running and
|
StatefulSet controller terminates each Pod, and waits for it to transition to Running and
|
||||||
Ready prior to updating the next Pod. Note that, even though the StatefulSet
|
Ready prior to updating the next Pod. Note that, even though the StatefulSet
|
||||||
controller will not proceed to update the next Pod until its ordinal successor
|
controller will not proceed to update the next Pod until its ordinal successor
|
||||||
is Running and Ready, it will restore any Pod that fails during the update to
|
is Running and Ready, it will restore any Pod that fails during the update to
|
||||||
its current version. Pods that have already received the update will be
|
its current version. Pods that have already received the update will be
|
||||||
restored to the updated version, and Pods that have not yet received the
|
restored to the updated version, and Pods that have not yet received the
|
||||||
update will be restored to the previous version. In this way, the controller
|
update will be restored to the previous version. In this way, the controller
|
||||||
attempts to continue to keep the application healthy and the update consistent
|
attempts to continue to keep the application healthy and the update consistent
|
||||||
in the presence of intermittent failures.
|
in the presence of intermittent failures.
|
||||||
|
|
||||||
Get the Pods to view their container images.
|
Get the Pods to view their container images.
|
||||||
@@ -538,13 +536,13 @@ k8s.gcr.io/nginx-slim:0.8
|
|||||||
|
|
||||||
All the Pods in the StatefulSet are now running the previous container image.
|
All the Pods in the StatefulSet are now running the previous container image.
|
||||||
|
|
||||||
**Tip** You can also use `kubectl rollout status sts/<name>` to view
|
**Tip** You can also use `kubectl rollout status sts/<name>` to view
|
||||||
the status of a rolling update.
|
the status of a rolling update.
|
||||||
|
|
||||||
#### Staging an Update
|
#### Staging an Update
|
||||||
You can stage an update to a StatefulSet by using the `partition` parameter of
|
You can stage an update to a StatefulSet by using the `partition` parameter of
|
||||||
the `RollingUpdate` update strategy. A staged update will keep all of the Pods
|
the `RollingUpdate` update strategy. A staged update will keep all of the Pods
|
||||||
in the StatefulSet at the current version while allowing mutations to the
|
in the StatefulSet at the current version while allowing mutations to the
|
||||||
StatefulSet's `.spec.template`.
|
StatefulSet's `.spec.template`.
|
||||||
|
|
||||||
Patch the `web` StatefulSet to add a partition to the `updateStrategy` field.
|
Patch the `web` StatefulSet to add a partition to the `updateStrategy` field.
|
||||||
@@ -587,13 +585,13 @@ k8s.gcr.io/nginx-slim:0.8
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
Notice that, even though the update strategy is `RollingUpdate` the StatefulSet
|
Notice that, even though the update strategy is `RollingUpdate` the StatefulSet
|
||||||
controller restored the Pod with its original container. This is because the
|
controller restored the Pod with its original container. This is because the
|
||||||
ordinal of the Pod is less than the `partition` specified by the
|
ordinal of the Pod is less than the `partition` specified by the
|
||||||
`updateStrategy`.
|
`updateStrategy`.
|
||||||
|
|
||||||
#### Rolling Out a Canary
|
#### Rolling Out a Canary
|
||||||
You can roll out a canary to test a modification by decrementing the `partition`
|
You can roll out a canary to test a modification by decrementing the `partition`
|
||||||
you specified [above](#staging-an-update).
|
you specified [above](#staging-an-update).
|
||||||
|
|
||||||
Patch the StatefulSet to decrement the partition.
|
Patch the StatefulSet to decrement the partition.
|
||||||
@@ -622,8 +620,8 @@ k8s.gcr.io/nginx-slim:0.7
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
When you changed the `partition`, the StatefulSet controller automatically
|
When you changed the `partition`, the StatefulSet controller automatically
|
||||||
updated the `web-2` Pod because the Pod's ordinal was greater than or equal to
|
updated the `web-2` Pod because the Pod's ordinal was greater than or equal to
|
||||||
the `partition`.
|
the `partition`.
|
||||||
|
|
||||||
Delete the `web-1` Pod.
|
Delete the `web-1` Pod.
|
||||||
@@ -657,19 +655,19 @@ kubectl get po web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}
|
|||||||
k8s.gcr.io/nginx-slim:0.8
|
k8s.gcr.io/nginx-slim:0.8
|
||||||
|
|
||||||
```
|
```
|
||||||
`web-1` was restored to its original configuration because the Pod's ordinal
|
`web-1` was restored to its original configuration because the Pod's ordinal
|
||||||
was less than the partition. When a partition is specified, all Pods with an
|
was less than the partition. When a partition is specified, all Pods with an
|
||||||
ordinal that is greater than or equal to the partition will be updated when the
|
ordinal that is greater than or equal to the partition will be updated when the
|
||||||
StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less
|
StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less
|
||||||
than the partition is deleted or otherwise terminated, it will be restored to
|
than the partition is deleted or otherwise terminated, it will be restored to
|
||||||
its original configuration.
|
its original configuration.
|
||||||
|
|
||||||
#### Phased Roll Outs
|
#### Phased Roll Outs
|
||||||
You can perform a phased roll out (e.g. a linear, geometric, or exponential
|
You can perform a phased roll out (e.g. a linear, geometric, or exponential
|
||||||
roll out) using a partitioned rolling update in a similar manner to how you
|
roll out) using a partitioned rolling update in a similar manner to how you
|
||||||
rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set
|
rolled out a [canary](#rolling-out-a-canary). To perform a phased roll out, set
|
||||||
the `partition` to the ordinal at which you want the controller to pause the
|
the `partition` to the ordinal at which you want the controller to pause the
|
||||||
update.
|
update.
|
||||||
|
|
||||||
The partition is currently set to `2`. Set the partition to `0`.
|
The partition is currently set to `2`. Set the partition to `0`.
|
||||||
|
|
||||||
@@ -709,22 +707,22 @@ k8s.gcr.io/nginx-slim:0.7
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
By moving the `partition` to `0`, you allowed the StatefulSet controller to
|
By moving the `partition` to `0`, you allowed the StatefulSet controller to
|
||||||
continue the update process.
|
continue the update process.
|
||||||
|
|
||||||
### On Delete
|
### On Delete
|
||||||
|
|
||||||
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior,
|
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior,
|
||||||
When you select this update strategy, the StatefulSet controller will not
|
When you select this update strategy, the StatefulSet controller will not
|
||||||
automatically update Pods when a modification is made to the StatefulSet's
|
automatically update Pods when a modification is made to the StatefulSet's
|
||||||
`.spec.template` field. This strategy can be selected by setting the
|
`.spec.template` field. This strategy can be selected by setting the
|
||||||
`.spec.template.updateStrategy.type` to `OnDelete`.
|
`.spec.template.updateStrategy.type` to `OnDelete`.
|
||||||
|
|
||||||
|
|
||||||
## Deleting StatefulSets
|
## Deleting StatefulSets
|
||||||
|
|
||||||
StatefulSet supports both Non-Cascading and Cascading deletion. In a
|
StatefulSet supports both Non-Cascading and Cascading deletion. In a
|
||||||
Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are
|
Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are
|
||||||
deleted.
|
deleted.
|
||||||
|
|
||||||
### Non-Cascading Delete
|
### Non-Cascading Delete
|
||||||
@@ -735,9 +733,9 @@ In one terminal window, watch the Pods in the StatefulSet.
|
|||||||
kubectl get pods -w -l app=nginx
|
kubectl get pods -w -l app=nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the
|
Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the
|
||||||
StatefulSet. Make sure to supply the `--cascade=false` parameter to the
|
StatefulSet. Make sure to supply the `--cascade=false` parameter to the
|
||||||
command. This parameter tells Kubernetes to only delete the StatefulSet, and to
|
command. This parameter tells Kubernetes to only delete the StatefulSet, and to
|
||||||
not delete any of its Pods.
|
not delete any of its Pods.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -781,7 +779,7 @@ kubectl get pods -w -l app=nginx
|
|||||||
```
|
```
|
||||||
|
|
||||||
In a second terminal, recreate the StatefulSet. Note that, unless
|
In a second terminal, recreate the StatefulSet. Note that, unless
|
||||||
you deleted the `nginx` Service ( which you should not have ), you will see
|
you deleted the `nginx` Service ( which you should not have ), you will see
|
||||||
an error indicating that the Service already exists.
|
an error indicating that the Service already exists.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -791,7 +789,7 @@ service/nginx unchanged
|
|||||||
```
|
```
|
||||||
|
|
||||||
Ignore the error. It only indicates that an attempt was made to create the nginx
|
Ignore the error. It only indicates that an attempt was made to create the nginx
|
||||||
Headless Service even though that Service already exists.
|
Headless Service even though that Service already exists.
|
||||||
|
|
||||||
Examine the output of the `kubectl get` command running in the first terminal.
|
Examine the output of the `kubectl get` command running in the first terminal.
|
||||||
|
|
||||||
@@ -811,14 +809,14 @@ web-2 0/1 Terminating 0 3m
|
|||||||
web-2 0/1 Terminating 0 3m
|
web-2 0/1 Terminating 0 3m
|
||||||
```
|
```
|
||||||
|
|
||||||
When the `web` StatefulSet was recreated, it first relaunched `web-0`.
|
When the `web` StatefulSet was recreated, it first relaunched `web-0`.
|
||||||
Since `web-1` was already Running and Ready, when `web-0` transitioned to
|
Since `web-1` was already Running and Ready, when `web-0` transitioned to
|
||||||
Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet
|
Running and Ready, it simply adopted this Pod. Since you recreated the StatefulSet
|
||||||
with `replicas` equal to 2, once `web-0` had been recreated, and once
|
with `replicas` equal to 2, once `web-0` had been recreated, and once
|
||||||
`web-1` had been determined to already be Running and Ready, `web-2` was
|
`web-1` had been determined to already be Running and Ready, `web-2` was
|
||||||
terminated.
|
terminated.
|
||||||
|
|
||||||
Let's take another look at the contents of the `index.html` file served by the
|
Let's take another look at the contents of the `index.html` file served by the
|
||||||
Pods' webservers.
|
Pods' webservers.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -827,10 +825,10 @@ web-0
|
|||||||
web-1
|
web-1
|
||||||
```
|
```
|
||||||
|
|
||||||
Even though you deleted both the StatefulSet and the `web-0` Pod, it still
|
Even though you deleted both the StatefulSet and the `web-0` Pod, it still
|
||||||
serves the hostname originally entered into its `index.html` file. This is
|
serves the hostname originally entered into its `index.html` file. This is
|
||||||
because the StatefulSet never deletes the PersistentVolumes associated with a
|
because the StatefulSet never deletes the PersistentVolumes associated with a
|
||||||
Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original
|
Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original
|
||||||
PersistentVolume was remounted.
|
PersistentVolume was remounted.
|
||||||
|
|
||||||
### Cascading Delete
|
### Cascading Delete
|
||||||
@@ -841,14 +839,14 @@ In one terminal window, watch the Pods in the StatefulSet.
|
|||||||
kubectl get pods -w -l app=nginx
|
kubectl get pods -w -l app=nginx
|
||||||
```
|
```
|
||||||
|
|
||||||
In another terminal, delete the StatefulSet again. This time, omit the
|
In another terminal, delete the StatefulSet again. This time, omit the
|
||||||
`--cascade=false` parameter.
|
`--cascade=false` parameter.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl delete statefulset web
|
kubectl delete statefulset web
|
||||||
statefulset.apps "web" deleted
|
statefulset.apps "web" deleted
|
||||||
```
|
```
|
||||||
Examine the output of the `kubectl get` command running in the first terminal,
|
Examine the output of the `kubectl get` command running in the first terminal,
|
||||||
and wait for all of the Pods to transition to Terminating.
|
and wait for all of the Pods to transition to Terminating.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -868,12 +866,12 @@ web-1 0/1 Terminating 0 29m
|
|||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
As you saw in the [Scaling Down](#scaling-down) section, the Pods
|
As you saw in the [Scaling Down](#scaling-down) section, the Pods
|
||||||
are terminated one at a time, with respect to the reverse order of their ordinal
|
are terminated one at a time, with respect to the reverse order of their ordinal
|
||||||
indices. Before terminating a Pod, the StatefulSet controller waits for
|
indices. Before terminating a Pod, the StatefulSet controller waits for
|
||||||
the Pod's successor to be completely terminated.
|
the Pod's successor to be completely terminated.
|
||||||
|
|
||||||
Note that, while a cascading delete will delete the StatefulSet and its Pods,
|
Note that, while a cascading delete will delete the StatefulSet and its Pods,
|
||||||
it will not delete the Headless Service associated with the StatefulSet. You
|
it will not delete the Headless Service associated with the StatefulSet. You
|
||||||
must delete the `nginx` Service manually.
|
must delete the `nginx` Service manually.
|
||||||
|
|
||||||
@@ -890,7 +888,7 @@ service/nginx created
|
|||||||
statefulset.apps/web created
|
statefulset.apps/web created
|
||||||
```
|
```
|
||||||
|
|
||||||
When all of the StatefulSet's Pods transition to Running and Ready, retrieve
|
When all of the StatefulSet's Pods transition to Running and Ready, retrieve
|
||||||
the contents of their `index.html` files.
|
the contents of their `index.html` files.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -899,8 +897,8 @@ web-0
|
|||||||
web-1
|
web-1
|
||||||
```
|
```
|
||||||
|
|
||||||
Even though you completely deleted the StatefulSet, and all of its Pods, the
|
Even though you completely deleted the StatefulSet, and all of its Pods, the
|
||||||
Pods are recreated with their PersistentVolumes mounted, and `web-0` and
|
Pods are recreated with their PersistentVolumes mounted, and `web-0` and
|
||||||
`web-1` will still serve their hostnames.
|
`web-1` will still serve their hostnames.
|
||||||
|
|
||||||
Finally delete the `web` StatefulSet and the `nginx` service.
|
Finally delete the `web` StatefulSet and the `nginx` service.
|
||||||
@@ -915,29 +913,29 @@ statefulset "web" deleted
|
|||||||
|
|
||||||
## Pod Management Policy
|
## Pod Management Policy
|
||||||
|
|
||||||
For some distributed systems, the StatefulSet ordering guarantees are
|
For some distributed systems, the StatefulSet ordering guarantees are
|
||||||
unnecessary and/or undesirable. These systems require only uniqueness and
|
unnecessary and/or undesirable. These systems require only uniqueness and
|
||||||
identity. To address this, in Kubernetes 1.7, we introduced
|
identity. To address this, in Kubernetes 1.7, we introduced
|
||||||
`.spec.podManagementPolicy` to the StatefulSet API Object.
|
`.spec.podManagementPolicy` to the StatefulSet API Object.
|
||||||
|
|
||||||
### OrderedReady Pod Management
|
### OrderedReady Pod Management
|
||||||
|
|
||||||
`OrderedReady` pod management is the default for StatefulSets. It tells the
|
`OrderedReady` pod management is the default for StatefulSets. It tells the
|
||||||
StatefulSet controller to respect the ordering guarantees demonstrated
|
StatefulSet controller to respect the ordering guarantees demonstrated
|
||||||
above.
|
above.
|
||||||
|
|
||||||
### Parallel Pod Management
|
### Parallel Pod Management
|
||||||
|
|
||||||
`Parallel` pod management tells the StatefulSet controller to launch or
|
`Parallel` pod management tells the StatefulSet controller to launch or
|
||||||
terminate all Pods in parallel, and not to wait for Pods to become Running
|
terminate all Pods in parallel, and not to wait for Pods to become Running
|
||||||
and Ready or completely terminated prior to launching or terminating another
|
and Ready or completely terminated prior to launching or terminating another
|
||||||
Pod.
|
Pod.
|
||||||
|
|
||||||
{{< codenew file="application/web/web-parallel.yaml" >}}
|
{{< codenew file="application/web/web-parallel.yaml" >}}
|
||||||
|
|
||||||
Download the example above, and save it to a file named `web-parallel.yaml`
|
Download the example above, and save it to a file named `web-parallel.yaml`
|
||||||
|
|
||||||
This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy`
|
This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy`
|
||||||
of the `web` StatefulSet is set to `Parallel`.
|
of the `web` StatefulSet is set to `Parallel`.
|
||||||
|
|
||||||
In one terminal, watch the Pods in the StatefulSet.
|
In one terminal, watch the Pods in the StatefulSet.
|
||||||
@@ -971,7 +969,7 @@ web-1 1/1 Running 0 10s
|
|||||||
|
|
||||||
The StatefulSet controller launched both `web-0` and `web-1` at the same time.
|
The StatefulSet controller launched both `web-0` and `web-1` at the same time.
|
||||||
|
|
||||||
Keep the second terminal open, and, in another terminal window scale the
|
Keep the second terminal open, and, in another terminal window scale the
|
||||||
StatefulSet.
|
StatefulSet.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -991,7 +989,7 @@ web-3 1/1 Running 0 26s
|
|||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
The StatefulSet controller launched two new Pods, and it did not wait for
|
The StatefulSet controller launched two new Pods, and it did not wait for
|
||||||
the first to become Running and Ready prior to launching the second.
|
the first to become Running and Ready prior to launching the second.
|
||||||
|
|
||||||
Keep this terminal open, and in another terminal delete the `web` StatefulSet.
|
Keep this terminal open, and in another terminal delete the `web` StatefulSet.
|
||||||
@@ -1028,10 +1026,10 @@ web-3 0/1 Terminating 0 9m
|
|||||||
web-3 0/1 Terminating 0 9m
|
web-3 0/1 Terminating 0 9m
|
||||||
```
|
```
|
||||||
|
|
||||||
The StatefulSet controller deletes all Pods concurrently, it does not wait for
|
The StatefulSet controller deletes all Pods concurrently, it does not wait for
|
||||||
a Pod's ordinal successor to terminate prior to deleting that Pod.
|
a Pod's ordinal successor to terminate prior to deleting that Pod.
|
||||||
|
|
||||||
Close the terminal where the `kubectl get` command is running and delete the `nginx`
|
Close the terminal where the `kubectl get` command is running and delete the `nginx`
|
||||||
Service.
|
Service.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
@@ -1042,9 +1040,6 @@ kubectl delete svc nginx
|
|||||||
## {{% heading "cleanup" %}}
|
## {{% heading "cleanup" %}}
|
||||||
|
|
||||||
You will need to delete the persistent storage media for the PersistentVolumes
|
You will need to delete the persistent storage media for the PersistentVolumes
|
||||||
used in this tutorial. Follow the necessary steps, based on your environment,
|
used in this tutorial. Follow the necessary steps, based on your environment,
|
||||||
storage configuration, and provisioning method, to ensure that all storage is
|
storage configuration, and provisioning method, to ensure that all storage is
|
||||||
reclaimed.
|
reclaimed.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user