Run a Replicated Stateful Application [page]deterministic

tasksstorageschedulingobservability

This page shows how to run a replicated stateful application using a [statefulset](#gloss:statefulset). This application is a replicated MySQL database. The example topology has a single primary server and multiple replicas, using asynchronous row-based replication.

> Note: This is not a production configuration. MySQL settings remain on insecure defaults to keep the focus on general patterns for running stateful applications in Kubernetes.

This tutorial assumes you are familiar with [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), as well as other core concepts like [Pods](/docs/concepts/workloads/pods/), [Services](/docs/concepts/services-networking/service/), and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
Some familiarity with MySQL helps, but this tutorial aims to present general patterns that should be useful for other systems.
You are using the default namespace or another namespace that does not contain any conflicting objects.
You need to have a AMD64-compatible CPU.

Deploy a replicated MySQL topology with a StatefulSet.
Send MySQL client traffic.
Observe resistance to downtime.
Scale the StatefulSet up and down.

## Deploy MySQL

The example MySQL deployment consists of a ConfigMap, two Services, and a StatefulSet.

### Create a ConfigMap {#configmap}

Create the ConfigMap from the following YAML configuration file:

```shell kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml ```

This ConfigMap provides `my.cnf` overrides that let you independently control configuration on the primary MySQL server and its replicas. In this case, you want the primary server to be able to serve replication logs to replicas and you want replicas to reject any writes that don't come via replication.

There's nothing special about the ConfigMap itself that causes different portions to apply to different Pods. Each Pod decides which portion to look at as it's initializing, based on information provided by the StatefulSet controller.

### Create Services {#services}

Create the Services from the following YAML configuration file:

```shell kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml ```

The headless Service provides a home for the DNS entries that the StatefulSet [controllers](#gloss:controller) creates for each Pod that's part of the set. Because the headless Service is named `mysql`, the Pods are accessible by resolving `<pod-name>.mysql` from within any other Pod in the same Kubernetes cluster and namespace.

The client Service, called `mysql-read`, is a normal Service with its own cluster IP that distributes connections across all MySQL Pods that report being Ready. The set of potential endpoints includes the primary MySQL server and all replicas.

Note that only read queries can use the load-balanced client Service. Because there is only one primary MySQL server, clients should connect directly to the primary MySQL Pod (through its DNS entry within the headless Service) to execute writes.

### Create the StatefulSet {#statefulset}

Finally, create the StatefulSet from the following YAML configuration file:

```shell kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml ```

You can watch the startup progress by running:

```shell kubectl get pods -l app=mysql --watch ```

After a while, you should see all 3 Pods become `Running`:

``` NAME READY STATUS RESTARTS AGE mysql-0 2/2 Running 0 2m mysql-1 2/2 Running 0 1m mysql-2 2/2 Running 0 1m ```

Press Ctrl+C to cancel the watch.

> Note: If you don't see any progress, make sure you have a dynamic PersistentVolume provisioner enabled, as mentioned in the [prerequisites](#before-you-begin).

This manifest uses a variety of techniques fo …(trimmed)