Kubernetes is a powerful tool. It can help you manage complex applications and provide you with the ability to easily automate tasks involved in managing them. In this course, we will start exploring Kubernetes from a beginner's standpoint. We will discuss what Kubernetes is and what it does, and we will work with some of the basic functionality of Kubernetes hands-on. We will build a simple Kubernetes cluster. We will also deploy a sample microservice application to the cluster in order to explore how Kubernetes can help easily manage such applications.

A Practical Guide to Kubernetes

# Looking into the Definition

Moving to the backend API...

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
  name: go-demo-2-api
spec:
  replicas: 3
  selector:
    matchLabels:
      type: api
      service: go-demo-2
  template:
    metadata:
      labels:
        type: api
        service: go-demo-2
        language: go
    spec:
      containers:
      - name: api
        image: vfarcic/go-demo-2
        env:
        - name: DB
          value: go-demo-2-db
        readinessProbe:
          httpGet:
            path: /demo/hello
            port: 8080
          periodSeconds: 1
        livenessProbe:
          httpGet:
            path: /demo/hello
            port: 8080

Just as with the database, this ReplicaSet should be familiar since it's very similar to the one we used before. We'll comment only on the differences.

* **Line 6:** The number of `replicas` is set to `3`. That solves one of the main problems we had with the previous ReplicaSets that defined Pods with both containers. Now the number of replicas can differ, and we have one Pod for the database, and three for the backend API.

* **Line 14:** In the `labels` section, `type` label is set to `api` so that both the ReplicaSet and the (soon to come) Service can distinguish the Pods from those created for the database.

* **Line 22-23:** We have the environment variable `DB` set to `go-demo-2-db`. The code behind the `vfarcic/go-demo-2` image is written in a way that the connection to the database is established by reading that variable. In this case, we can say that it will try to connect to the database running on the DNS `go-demo-2-db`. If you go back to the database Service definition, you'll notice that its name is `go-demo-2-db` as well. If everything works correctly, we should expect that the DNS was created with the Service and that it'll forward requests to the database.

# The readinessProbe
The `readinessProbe` should be used as an indication that the service is ready to serve requests. When combined with `Services` construct, only containers with the `readinessProbe` state set to `Success` will receive requests. 

In earlier Kubernetes versions it used `userspace` proxy mode. Its advantage is that the proxy would retry failed requests to another Pod. With the shift to the `iptables` mode, that feature is lost. However, `iptables` are much faster and more reliable, so the loss of the retry mechanism is well compensated. That does not mean that the requests are sent to Pods "blindly". The lack of the retry mechanism is mitigated with `readinessProbe`, which we added to the ReplicaSet.


The `readinessProbe` has the same fields as the `livenessProbe`. We used the same values for both, except for the `periodSeconds`, where instead of relying on the default value of `10`, we set it to `1`. 

While `livenessProbe` is used to determine whether a Pod is alive or it should be replaced by a new one, the `readinessProbe` is used by the `iptables`. A Pod that does not pass the `readinessProbe` will be excluded and will not receive requests. In theory, requests might be still sent to a faulty Pod, between two iterations. Still, such requests will be small in number since the `iptables` will change as soon as the next probe responds with HTTP code less than `200`, or equal or greater than `400`.

# Creating the ReplicaSet
Let's create the ReplicaSet.

In this lesson, we will create API Pods using ReplicaSet and establish communication by creating Service.

Creating the Split API Pods

Looking into the Definition