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

Updating a single-replica MongoDB cannot demonstrate true power behind Deployments. We need a scalable Service. It's not that MongoDB cannot be scaled (it can), but it's not as straightforward as an application that was designed to be scalable. We'll jump to the second application in the stack and create a Deployment of the ReplicaSet that will create Pods based on the `go-demo-2` image.


> **Note:** Zero-downtime Deployment is a prerequisite for higher frequency releases.

# Looking into the definition
Let's take a look at the Deployment definition of the API `go-demo-api`.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-2-api
spec:
  replicas: 3
  selector:
    matchLabels:
      type: api
      service: go-demo-2
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  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

We'll skip explaining `apiVersion`, `kind`, and `metadata`, since they always follow the same pattern.

* **Lines 5--7:** The `spec` section has a few fields we haven’t seen before and some we are familiar with. The `replicas` and the `selector` are the same as the ones we used in the ReplicaSet from the previous chapter.

* **Line 11:** The `minReadySeconds` defines the minimum number of seconds before Kubernetes starts considering the Pods healthy. We set the value of this field to `1` second. The default value is `0`, meaning that the Pods will be considered available as soon as they are ready and, when specified, `livenessProbe` returns OK. If in doubt, omit this field and let its value stay `0`.. We have defined it mostly for demonstration purposes.

* **Line 13:** The next field is `revisionHistoryLimit`. It defines the number of old ReplicaSets we can roll back. Like most fields, it is set to the default value `10`. We change it to 5 and, as a result, we’ll be able to roll back to any of the previous five ReplicaSets.

* **Line 14:** The `strategy` can be either the `RollingUpdate` or the `Recreate` type. The latter will terminate all the existing Pods before an update. `Recreate` resembles the processes we used in the past when the typical strategy for deploying a new release was first to stop the existing one and then put a new one in its place. This approach inevitably leads to downtime. The only case when this strategy is useful is when applications are _not_ designed for two releases to coexist. Unfortunately, that’s still more common than it should be. If you’re in doubt about whether your application is like that, ask yourself the following question. Would there be an adverse effect if two different versions of an application are running in parallel? If that’s the case, a `Recreate` strategy might be a good choice. Reminder: We cannot accomplish zero-downtime Deployments.
# Deployment strategies
Let’s look into the details of the `Recreate` and `RollingUpdate` strategies.

## The `Recreate` strategy

The `Recreate` strategy is much better suited to our single-replica database. We should have set up the native database replication (not the same as the Kubernetes ReplicaSet object), but that is out of the scope of this chapter.

If we’re running the database as a single replica, we must have mounted a network drive volume. That allows us to avoid data loss when updating it or in case of a failure. Since most databases (MongoDB included) cannot have multiple instances writing to the same data files, terminating the old release before creating a new one is a good strategy when replication is absent. We’ll apply it later on in the course.

## The `RollingUpdate` strategy

The `RollingUpdate` strategy is the default type for a good reason. It allows us to deploy new releases without downtime. It creates a new ReplicaSet with zero replicas and, depending on other parameters, increases the replicas of the new one and decreases those from the old one. The process is finished when the replicas of the new ReplicaSet entirely replace those from the old one.

When `RollingUpdate` is the strategy of choice, it can be fine-tuned with the `maxSurge` and `maxUnavailable` fields. The former defines the maximum number of Pods that can exceed the desired number (set using `replicas`). It can be set to an absolute number (e.g., `2`) or a percentage (e.g., `35%`). The total number of Pods will never exceed the desired number (set using `replicas`) and the `maxSurge` combined. The default value is `25%`.

The `maxUnavailable` field defines the maximum number of Pods that are not operational. If, for example, the number of replicas is set to `15` and this field is set to `4`, the minimum number of Pods that would run at any given moment would be `11`. Just as the `maxSurge` field, this one also defaults to `25%`. If this field is not specified, there will always be at least `75%` of the desired Pods.

In most cases, the default values of the Deployment specific fields are a good option. We changed the default settings only as a way to demonstrate better all the options we can use. We'll remove them from most of the Deployment definitions that follow.

# The `template`
The `template` is the same `PodTemplate` we used before. A best practice is to be explicit with image tags like we did when we set `mongo:3.3`. However, that might not always be the best strategy with the images we're building. Given we use the right practices, we can rely on `latest` tags being stable. Even if we discover they're not, we can remedy that quickly by creating a new `latest` tag. However, we cannot expect the same from third-party images. They must always be tagged to a specific version.

> **Note:** Never deploy third-party images based on `latest` tags. By being explicit with the release, we have more control on what's running in production, as well as the next upgrade should be.

We won't always use `latest` for our Services, only for the initial Deployments. Assuming that we are doing our best to maintain the `latest` tag stable and production-ready, it is useful when setting up the cluster for the first time. After that, each new release will be with a specific tag. Our automated continuous Deployment pipeline will do that for us in one of the next chapters.



Learn the definition of a zero-downtime Deployment.

Defining a Zero-Downtime Deployment