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

# Kubernetes Deployments compared to Docker Swarm stacks

If you have already used Docker Swarm, the logic behind Kubernetes Deployments should be familiar. Both serve the same purpose and can be used to deploy new applications or update those that are already running inside a cluster. In both cases, we can easily deploy new releases without any downtime (when application architecture permits that).



# Comparing definitions
Let's look at the way we define objects in both Kubernetes and Docker Swarm.
## Kubernetes

An example of a Kubernetes Deployment and Service definition is as follows:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-2-db
spec:
  selector:
    matchLabels:
      type: db
      service: go-demo-2
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        type: db
        service: go-demo-2
        vendor: MongoLabs
    spec:
      containers:
      - name: db
        image: mongo:3.3
        ports:
        - containerPort: 27017

---

apiVersion: v1
kind: Service
metadata:
  name: go-demo-2-db
spec:
  ports:
  - port: 27017
  selector:
    type: db
    service: go-demo-2

---

apiVersion: apps/v1beta2
kind: Deployment
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

---

apiVersion: v1
kind: Service
metadata:
  name: go-demo-2-api
spec:
  type: NodePort
  ports:
  - port: 8080
  selector:
    type: api
    service: go-demo-2

## Docker Swarm
An equivalent Docker Swarm stack definition is as follows:

version: "3"
services:
  api:
    image: vfarcic/go-demo-2
    environment:
      - DB=db
    ports:
      - 8080
    deploy:
      replicas: 3
  db:
    image: mongo:3.3

Both definitions provide, more or less, the same functionality.

It is evident that a Kubernetes Deployment requires a much longer definition with more complex syntax. It is worth noting that Swarm's equivalent to `readinessProbe` and `livenessProbe` is not present in the stack because it is defined as a `HEALTHCHECK` inside the Dockerfile. Still, even if we remove them, a Kubernetes Deployment remains longer and more complicated.

> **Note:** When comparing only the differences in the ways to define objects, Docker Swarm is a clear winner. 

# Comparing functionality
Let’s see what we can conclude about the differences in Kubernetes’ and Docker Swarm’s functionality:

## Creating objects
Creating objects is reasonably straightforward. Both `kubectl create` and `docker stack deploy` will deploy new releases without any downtime. In case of Kubernetes, new containers or Pods will be created and, in parallel, the old ones will be terminated. So far, both solutions are similar.

## Deployment status
One of the main differences is what happens in case of a failure. A Kubernetes Deployment will not perform any corrective action in case of a failure. It will stop the update, leaving a combination of new and old Pods running in parallel. On the other hand, Docker Swarm can be configured to roll back automatically. That might seem like another win for Docker Swarm. 

However, Kubernetes has something Swarm doesn’t. We can use the `kubectl rollout status` command to determine whether the update was a success or failure.In case the update is a failure, we can also `undo` the `rollout`. Even though we need a few commands to accomplish the same result, that might fare better when updates are automated. Knowing whether an update succeeded or failed allows us to not only execute a subsequent rollback action, but also notify someone that there is a problem.

> **Note:** Both approaches have their pros and cons. Docker Swarm’s automated rollback is better suited in some cases, and Kubernetes update status works better in others. The methods are different and there is no clear winner, so we’ll proclaim it a tie.

## Rolling back
Kubernetes Deployments can record history. We can use the `kubectl rollout history` command to inspect past rollouts. When updates are working as expected, `history` is not very useful. But, when things go wrong, it might provide additional insight. That can be combined with the ability to roll back to a specific revision, not necessarily just the previous one. However, most of the time, we roll back to the previous version. The ability to go back further in time is not very useful. Even when such a need arises, both products can do that.

The difference is that Kubernetes Deployments allow us to go to a specific revision (e.g., if we’re on revision five, we can roll back to revision two). With Docker Swarm, we’d have to issue a new update (e.g., update the image to the tag 2.0). Since containers are immutable, the result is the same, so the difference is only in the syntax behind a rollback.



> **Note:**  The ability to rollback to a specific version or a tag exists in both products. We can argue which syntax is more straightforward or more useful. The differences are minor and we'll proclaim that there is no winner for that functionality. It's another **tie**.

## Updating multiple Deployments
Since almost everything in Kubernetes is based on label selectors, it has a feature that Docker Swarm doesn’t. We can update multiple Deployments at the same time. We can, for example, issue an update (`kubetl set image`) that uses filters to find all Mongo databases and upgrade them to a newer release. It is a feature that would require a few lines of bash scripting with Docker Swarm.

However, while the ability to update all Deployments that match specific labels might sound like a useful feature, it often isn’t. More often than not, such actions can produce undesirable effects. If, for example, we have five backend applications that use Mongo databases (one for each), we’d probably want to upgrade them in a more controlled fashion. Teams behind those services would probably want to test each of those upgrades. We probably wouldn’t wait until all are finished but upgrade a single database when the team in charge of it feels confident.


> **Note:** There are cases when updating multiple objects is useful, so we must give this one to Kubernetes. It is a minor win, but it still counts.

# Conclusion

Don’t make a decision based on the differences between Kubernetes Deployments and Docker Swarm stacks.Definition syntax is where Swarm has a clear win, while on the functional front, Kubernetes has a tiny edge over Swarm.

In any case, Kubernetes has much more to offer, and any conclusion based on such a limited comparison scope is bound to be incomplete. We have only scratched the surface so far. Stay tuned for more.



Compare Kubernetes Deployments with Docker Swarm stacks.

Comparison with Docker Swarm

Kubernetes Deployments compared to Docker Swarm stacks