Splitting the Pod and Establishing communication through Services

Looking into the definition#

Let’s take a look at a ReplicaSet definition go-demo-2-db-rs.yml for a Pod with only the database.

We’ll comment only on the things that changed.

Since this ReplicaSet defines only the database, we reduced the number of replicas to 1. Truth be told, MongoDB should be scaled as well, but that’s out of the scope of this chapter. For now, we’ll pretend that one replica of a database is enough.

Since selector labels need to be unique, we changed them slightly. The service is still go-demo-2, but the type was changed to db.

The rest of the definition is the same except that the containers now contain only mongo. We’ll define the API in a separate ReplicaSet.

Creating the ReplicaSet#

Let’s create the ReplicaSet before we move to the Service that will reference its Pod.

One object was created, three are left to go.

Creating the service#

The next one is the Service go-demo-2-db-svc.yml for the Pod we just created through the ReplicaSet.

This Service definition does not contain anything new.

• There is no type, so it’ll default to ClusterIP.
• Since there is no reason for anyone outside the cluster to communicate with the database, there’s no need to expose it using the NodePort type.
• We also skipped specifying the NodePort, since only internal communication within the cluster is allowed.
• The same is true for the protocol. TCP is all we need, and it happens to be the default one.
• Finally, the selector labels are the same as the labels that define the Pod.

Let’s create the Service.

We are finished with the database. The ReplicaSet will make sure that the Pod is (almost) always up-and-running and the Service will allow other Pods to communicate with it through a fixed DNS.

Try it yourself#

The list of all the commands used in this lesson is given below.