Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# Definition

Let's look at a ReplicaSet named `go-demo-2.yml` based on the Pod we created in the previous chapter:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: go-demo-2
spec:
  replicas: 2
  selector:
    matchLabels:
      type: backend
      service: go-demo-2
  template:
    metadata:
      labels:
        type: backend
        service: go-demo-2
        db: mongo
        language: go
    spec:
      containers:
      - name: db
        image: mongo:3.3
      - name: api
        image: vfarcic/go-demo-2
        env:
        - name: DB
          value: localhost
        livenessProbe:
          httpGet:
            path: /demo/hello
            port: 8080

>**Note:** The `apiVersion`, `kind`, and `metadata` fields are mandatory with all Kubernetes objects. **ReplicaSet** is no exception because it's also a Kubernetes object.

* **Line 1:** We specify that the `apiVersion` is `apps/v1`. 

* **Lines 2--3:** The `kind` is `ReplicaSet` and `metadata` has the `name` key set to `go-demo-2`. We could have extended ReplicaSet `metadata` with labels. However, we've skipped that part since the labels only provide extra information. They do not affect the behavior of the ReplicaSet.

Since we’ve already explored the above three fields, we won’t dwell on them a lot. However, we should note that there is a fourth section called `spec` and it is mandatory. Let’s look at it in more detail in the line-by-line explanation below:

* **Line 5--6:** The first field we define in the `spec` section is `replicas`. It sets the desired number of replicas of the Pod. In this case, the ReplicaSet ensures that two Pods should run concurrently. If we do not specify the value of the `replicas`, it defaults to `1`.

* **Line 7:** The next `spec` section is the `selector`. We use it to select which Pods should be included in the ReplicaSet. It does not distinguish between the Pods created by a ReplicaSet or some other process. In other words, ReplicaSets and Pods are decoupled. If Pods that match the `selector` exist, ReplicaSet does nothing. If they don't match, it creates as many Pods to match the value of the `replicas` field. Not only does the ReplicaSet create the Pods that are missing, it also monitors the cluster and ensures that the desired number of `replicas` is (almost) always running. In case there are already more running Pods with the matching `selector`, some will be terminated to match the number set in `replicas`.

* **Lines 8--10:** We use `spec.selector.matchLabels` to specify a few labels. They must match the labels defined in `spec.template`. In our case, ReplicaSet will look for Pods with `type` set to `backend` and `service` set to `go-demo-2`. If Pods with those labels do not already exist, it'll create them using the `spec.template` section.

* **Lines 11--17:** The last section of the `spec` field is the `template`. It is the only required field in the `spec` and has the same schema as a Pod specification. At a minimum, the labels of the `spec.template.metadata.labels` section must match those specified in the `spec.selector.matchLabels`. We can set additional labels that will serve informational purposes only. ReplicaSet will make sure that the number of replicas matches the number of Pods with the same labels. In our case, we set `type` and `service` to the same values and add two additional ones (`db` and `language`).
It might sound confusing that the `spec.template.spec.containers` field is mandatory, so let's clear it out. ReplicaSet will look for Pods with matching labels created by other means. If we have already created a Pod with labels `type: backend` and `service: go-demo-2`, this ReplicaSet would find them and would not create a Pod defined in `spec.template`. The main purpose of that field is to ensure that the desired number of `replicas` is running. If they are created by other means, ReplicaSet will do nothing. Otherwise, it'll create them using the information in `spec.template`.

* **Lines 18--23:** Finally, the `spec.template.spec` section contains the same `containers` definition we used in the previous chapter. It defines a Pod with two containers (`db` and `api`).

In the previous chapter, we claimed that those two containers should not belong to the same Pod. The same is true for the containers in Pods managed by ReplicaSet. However, we haven't had the opportunity yet to explore ways to allow containers running in different Pods to communicate with each other. So, for now, we'll continue using the same *flawed Pod definition*.

# Creating the ReplicaSet

Let's create the ReplicaSet and experience its advantages:

Learn how to create and retrieve a ReplicaSet.

Creating ReplicaSets

Definition