K8s and Docker – use cases and differences

 

Both Kubernetes and Docker are used to deploy and manage containers.  Often Docker Containers run applications within Kubernetes (K8s) node clusters.  Usually the two are working together.

Docker is however, suitable for different use cases than K8s.  In general, Kubernetes, by default, works as a cluster of nodes where the containerized application (which could be a Docker container)  can be scaled as needed. Docker is a container runtime engine, deploying a single container to a single node, or deploying full-stack applications to a cluster (called a Docker Swarm if you want to use Docker and manage the containers at scale, and not use K8s).

The primary focus on Docker is developing, sharing and running individual containers, whereas Kubernetes is focused on containerized applications at scale.

 

Feature comparison: Kubernetes vs. Docker

FeatureKubernetesDocker
InstallationChallengingSimple
Learning curveSteepShallow
ScalingAutomaticManual
MonitoringBuilt-inRequires third-party tools
Load balancingManualAutomatic
CLI toolsBuilt-inBuilt-in
Runtime engineRequires third-party toolsBuilt-in
ClusteringBuilt-inMust be deployed in cluster mode (Docker Swarm)
Recommended node sizeUp to 500 nodesRecommended max of seven manager nodes for a swarm

 

Controllers and nodes

Although Docker doesn’t require the deployment of both controllers and nodes, if you plan on using Docker Swarm, you will have to use both a controller and multiple nodes.

Kubernetes, on the other hand, does require the use of both controllers and nodes. These controllers and nodes can be off-the-shelf servers in your data centre or hosted by third-party cloud vendors, such as AWS, Azure, Google Cloud, Rackspace and Linode.

Developer tools

Kubernetes and Docker contain all the tools you need to develop your containerized applications. Both depend on image registries (such as those hosted on the likes of Docker Hub) and use JSON-formatted manifests to layout portable, containerized applications. Both offer command-line interface tools for development, as well as several third-party GUI tools.

Kubernetes and Docker can be integrated into your current development tools, such as your favourite IDEs and versioning systems such as git.

Clusters

Both Kubernetes and Docker can make use of clusters. The difference is that Kubernetes requires a cluster, whereas a Docker Swarm is optional. This also highlights the biggest difference between Kubernetes and Docker: Kubernetes scales far easier and larger than Docker.

Persistent volumes

When you deploy a containerized application, chances are high that it’s going to depend on saved data. Kubernetes and Docker can make use of persistent volumes. These volumes save data outside of the container such that, should something happen to the running containers, the data is saved in its own persistent volume.

Persistent volumes also make it possible to share data between containers. For example, you could deploy a MySQL container using a persistent volume and have multiple containers connect to that database.

Containers and pods

Docker deploys containers, which are containerized applications and microservices. Kubernetes, on the other hand, actually wraps containers into pods, which are a higher-level structure that can contain multiple containers sharing the same resources. One should use caution not to deploy too many containers to a single pod, as those containers must scale together, which could lead to wasted resources.

Although Docker doesn’t work with pods, it is possible to deploy full-stack applications by way of individual but interconnected containers.

Networking

One area where Docker really shines is in networking. You can easily deploy a container with Docker and have it immediately and easily accessed from a network.

Kubernetes isolates pods from the outside world. Because of this, you must add an Ingress controller or Load Balancer to access those containerized applications from outside the cluster.

 

Source

Leave a Comment

Your email address will not be published.