@@ -14,7 +14,7 @@ weight: 30
14
14
<!-- overview -->
15
15
16
16
This page shows how to run a replicated stateful application using a
17
- [ StatefulSet ] ( /docs/concepts/workloads/controllers/ statefulset/ ) controller .
17
+ {{< glossary_tooltip term_id=" statefulset" >}} .
18
18
This application is a replicated MySQL database. The example topology has a
19
19
single primary server and multiple replicas, using asynchronous row-based
20
20
replication.
@@ -24,12 +24,10 @@ replication.
24
24
on general patterns for running stateful applications in Kubernetes.
25
25
{{< /note >}}
26
26
27
-
28
-
29
27
## {{% heading "prerequisites" %}}
30
28
31
29
32
- * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
30
+ * {{< include "task-tutorial-prereqs.md" >}}
33
31
* {{< include "default-storage-class-prereqs.md" >}}
34
32
* This tutorial assumes you are familiar with
35
33
[ PersistentVolumes] ( /docs/concepts/storage/persistent-volumes/ )
@@ -46,7 +44,7 @@ on general patterns for running stateful applications in Kubernetes.
46
44
## {{% heading "objectives" %}}
47
45
48
46
49
- * Deploy a replicated MySQL topology with a StatefulSet controller .
47
+ * Deploy a replicated MySQL topology with a StatefulSet.
50
48
* Send MySQL client traffic.
51
49
* Observe resistance to downtime.
52
50
* Scale the StatefulSet up and down.
@@ -60,7 +58,7 @@ on general patterns for running stateful applications in Kubernetes.
60
58
The example MySQL deployment consists of a ConfigMap, two Services,
61
59
and a StatefulSet.
62
60
63
- ### ConfigMap
61
+ ### Create a ConfigMap {#configmap}
64
62
65
63
Create the ConfigMap from the following YAML configuration file:
66
64
@@ -71,7 +69,7 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
71
69
```
72
70
73
71
This ConfigMap provides ` my.cnf ` overrides that let you independently control
74
- configuration on the primary MySQL server and replicas.
72
+ configuration on the primary MySQL server and its replicas.
75
73
In this case, you want the primary server to be able to serve replication logs to replicas
76
74
and you want replicas to reject any writes that don't come via replication.
77
75
@@ -80,7 +78,7 @@ portions to apply to different Pods.
80
78
Each Pod decides which portion to look at as it's initializing,
81
79
based on information provided by the StatefulSet controller.
82
80
83
- ### Services
81
+ ### Create Services {#services}
84
82
85
83
Create the Services from the following YAML configuration file:
86
84
@@ -90,23 +88,24 @@ Create the Services from the following YAML configuration file:
90
88
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
91
89
```
92
90
93
- The Headless Service provides a home for the DNS entries that the StatefulSet
94
- controller creates for each Pod that's part of the set.
95
- Because the Headless Service is named ` mysql ` , the Pods are accessible by
91
+ The headless Service provides a home for the DNS entries that the StatefulSet
92
+ {{< glossary_tooltip text="controllers" term_id="controller" >}} creates for each
93
+ Pod that's part of the set.
94
+ Because the headless Service is named ` mysql ` , the Pods are accessible by
96
95
resolving ` <pod-name>.mysql ` from within any other Pod in the same Kubernetes
97
96
cluster and namespace.
98
97
99
- The Client Service, called ` mysql-read ` , is a normal Service with its own
98
+ The client Service, called ` mysql-read ` , is a normal Service with its own
100
99
cluster IP that distributes connections across all MySQL Pods that report
101
100
being Ready. The set of potential endpoints includes the primary MySQL server and all
102
101
replicas.
103
102
104
- Note that only read queries can use the load-balanced Client Service.
103
+ Note that only read queries can use the load-balanced client Service.
105
104
Because there is only one primary MySQL server, clients should connect directly to the
106
- primary MySQL Pod (through its DNS entry within the Headless Service) to execute
105
+ primary MySQL Pod (through its DNS entry within the headless Service) to execute
107
106
writes.
108
107
109
- ### StatefulSet
108
+ ### Create the StatefulSet {#statefulset}
110
109
111
110
Finally, create the StatefulSet from the following YAML configuration file:
112
111
@@ -122,7 +121,7 @@ You can watch the startup progress by running:
122
121
kubectl get pods -l app=mysql --watch
123
122
```
124
123
125
- After a while, you should see all 3 Pods become Running:
124
+ After a while, you should see all 3 Pods become ` Running ` :
126
125
127
126
```
128
127
NAME READY STATUS RESTARTS AGE
@@ -132,8 +131,11 @@ mysql-2 2/2 Running 0 1m
132
131
```
133
132
134
133
Press ** Ctrl+C** to cancel the watch.
134
+
135
+ {{< note >}}
135
136
If you don't see any progress, make sure you have a dynamic PersistentVolume
136
- provisioner enabled as mentioned in the [ prerequisites] ( #before-you-begin ) .
137
+ provisioner enabled, as mentioned in the [ prerequisites] ( #before-you-begin ) .
138
+ {{< /note >}}
137
139
138
140
This manifest uses a variety of techniques for managing stateful Pods as part of
139
141
a StatefulSet. The next section highlights some of these techniques to explain
@@ -155,19 +157,18 @@ properties to perform orderly startup of MySQL replication.
155
157
### Generating configuration
156
158
157
159
Before starting any of the containers in the Pod spec, the Pod first runs any
158
- [ Init Containers ] ( /docs/concepts/workloads/pods/init-containers/ )
160
+ [ init containers ] ( /docs/concepts/workloads/pods/init-containers/ )
159
161
in the order defined.
160
162
161
- The first Init Container , named ` init-mysql ` , generates special MySQL config
163
+ The first init container , named ` init-mysql ` , generates special MySQL config
162
164
files based on the ordinal index.
163
165
164
166
The script determines its own ordinal index by extracting it from the end of
165
167
the Pod name, which is returned by the ` hostname ` command.
166
168
Then it saves the ordinal (with a numeric offset to avoid reserved values)
167
169
into a file called ` server-id.cnf ` in the MySQL ` conf.d ` directory.
168
170
This translates the unique, stable identity provided by the StatefulSet
169
- controller into the domain of MySQL server IDs, which require the same
170
- properties.
171
+ into the domain of MySQL server IDs, which require the same properties.
171
172
172
173
The script in the ` init-mysql ` container also applies either ` primary.cnf ` or
173
174
` replica.cnf ` from the ConfigMap by copying the contents into ` conf.d ` .
@@ -187,7 +188,7 @@ logs might not go all the way back to the beginning of time.
187
188
These conservative assumptions are the key to allow a running StatefulSet
188
189
to scale up and down over time, rather than being fixed at its initial size.
189
190
190
- The second Init Container , named ` clone-mysql ` , performs a clone operation on
191
+ The second init container , named ` clone-mysql ` , performs a clone operation on
191
192
a replica Pod the first time it starts up on an empty PersistentVolume.
192
193
That means it copies all existing data from another running Pod,
193
194
so its local state is consistent enough to begin replicating from the primary server.
@@ -202,7 +203,7 @@ Ready before starting Pod `N+1`.
202
203
203
204
### Starting replication
204
205
205
- After the Init Containers complete successfully, the regular containers run.
206
+ After the init containers complete successfully, the regular containers run.
206
207
The MySQL Pods consist of a ` mysql ` container that runs the actual ` mysqld `
207
208
server, and an ` xtrabackup ` container that acts as a
208
209
[ sidecar] ( https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns ) .
@@ -291,13 +292,13 @@ endpoint might be selected upon each connection attempt:
291
292
You can press ** Ctrl+C** when you want to stop the loop, but it's useful to keep
292
293
it running in another window so you can see the effects of the following steps.
293
294
294
- ## Simulating Pod and Node downtime
295
+ ## Simulate Pod and Node failure {#simulate-pod-and-node- downtime}
295
296
296
297
To demonstrate the increased availability of reading from the pool of replicas
297
298
instead of a single server, keep the ` SELECT @@server_id ` loop from above
298
299
running while you force a Pod out of the Ready state.
299
300
300
- ### Break the Readiness Probe
301
+ ### Break the Readiness probe
301
302
302
303
The [ readiness probe] ( /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes )
303
304
for the ` mysql ` container runs the command ` mysql -h 127.0.0.1 -e 'SELECT 1' `
@@ -371,14 +372,18 @@ NAME READY STATUS RESTARTS AGE IP NODE
371
372
mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-node-9l2t
372
373
```
373
374
374
- Then drain the Node by running the following command, which cordons it so
375
+ Then, drain the Node by running the following command, which cordons it so
375
376
no new Pods may schedule there, and then evicts any existing Pods.
376
377
Replace ` <node-name> ` with the name of the Node you found in the last step.
377
378
378
- This might impact other applications on the Node, so it's best to
379
- ** only do this in a test cluster** .
379
+ {{< caution >}}
380
+ Draining a Node can impact other workloads and applications
381
+ running on the same node. Only perform the following step in a test
382
+ cluster.
383
+ {{< /caution >}}
380
384
381
385
``` shell
386
+ # See above advice about impact on other workloads
382
387
kubectl drain < node-name> --force --delete-emptydir-data --ignore-daemonsets
383
388
```
384
389
@@ -413,8 +418,9 @@ kubectl uncordon <node-name>
413
418
414
419
## Scaling the number of replicas
415
420
416
- With MySQL replication, you can scale your read query capacity by adding replicas.
417
- With StatefulSet, you can do this with a single command:
421
+ When you use MySQL replication, you can scale your read query capacity by
422
+ adding replicas.
423
+ For a StatefulSet, you can achieve this with a single command:
418
424
419
425
``` shell
420
426
kubectl scale statefulset mysql --replicas=5
@@ -453,10 +459,13 @@ Scaling back down is also seamless:
453
459
kubectl scale statefulset mysql --replicas=3
454
460
```
455
461
456
- Note, however, that while scaling up creates new PersistentVolumeClaims
462
+ {{< note >}}
463
+ Although scaling up creates new PersistentVolumeClaims
457
464
automatically, scaling down does not automatically delete these PVCs.
465
+
458
466
This gives you the choice to keep those initialized PVCs around to make
459
467
scaling back up quicker, or to extract data before deleting them.
468
+ {{< /note >}}
460
469
461
470
You can see this by running:
462
471
0 commit comments