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

# Looking into the definition

Let's see the definition of the backend API `go-demo-2-api-rs.yml`. 

apiVersion: apps/v1
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.

* **Lines 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.

# `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 was 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. However, 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 have 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 an HTTP code less than `200` or equal to or greater than `400`.

# Creating the ReplicaSet


Learn to create API Pods using ReplicaSet and establish communication by creating a Service.

Creating the Split API Pods

Looking into the definition