. Let us now go back to the world of Kubernetes and containers and try to deploy this setup.

In the Kubernetes world, each of these instances, including the master and slaves are a POD part of a

deployment.

2.

In step 1, we want the master to come up first and then the slaves. And in case of the slaves we want slave 1

to come up first,

3.

perform initial clone of data from the master, and we want slave 2 to come up next and clone data from

slave 1.

4.

5. With deployments you can’t guarantee that order.

6. With deployments all pods part of the deployment come up at the same time.

7. So the first step can’t be implemented with a Deployment.

8. As we have seen while working with deployments the pods come up with random names.

9. So that won’t help us here. Even if we decide to designate one of these pods as the master,

10. and use it’s name to configure the slaves,

if that POD crashes and the deployment creates a new pod in it’s place, it’s going to come up with a

completely new pod name.

11.

12. And now the slaves are pointing to an address that does not exist.

13. And because of all of these, the remaining steps can’t be executed.